Wikipedia

Cilësia e programit

Kur bëhet fjale per kontekstin e inxhinierisë së softuerit, cilësia e softuerit i referohet dy nocioneve të lidhura, por të dallueshme:

  • Cilësia funksionale e softuerit pasqyron se sa mirë përputhet ose pershtatet me një dizajn të caktuar, bazuar në kërkesat ose specifikimet funksionale.[1] Ky atribut mund të përshkruhet gjithashtu si përshtatshmëria për qëllimin e një softueri ose si diferencohet me konkurrentët në treg si një produkt i vlefshëm.[2] Është shkalla në të cilën është prodhuar softueri i duhur.
  • Cilësia strukturore e softuerit i referohet mënyrës sesi ai plotëson kërkesat jofunksionale që mbështesin përmbushjen e kërkesave funksionale, të tilla si qëndrueshmëria ose mirëmbajtja e saj. Ka shumë më tepër të bëjë me shkallën në të cilën softueri funksionon sipas nevojës se tij.

Ka disa nga shume aspekte të cilësisë strukturore te cilat mund të vlerësohen vetëm në mënyrë statike përmes analizës së strukturës së brendshme të softuerit pra kodit burimor të tij (shiko Metrikat e softuerit),[3] në nivelin e njësisë dhe në nivelin e sistemit (ndonjëherë referuar si fund-ne-fund testimi i fundit[4]), i cili në fakt tregon se si arkitektura e tij i përmbahet parimeve të shëndosha të arkitekturës së softuerit të përshkruara në një punim mbi temën nga Grupi i Menaxhimit të Objekteve shkurtimisht si (OMG).[5]

Disa cilësi strukturore, të tilla si përdorshmëria, mund të vlerësohen vetëm në mënyrë dinamike (përdoruesit ose të tjerët që veprojnë në emër të tyre ndërveprojnë me softuerin ose, të paktën, disa prototip ose zbatim të pjesshëm; edhe ndërveprimi me një version model të bërë në karton përfaqëson një test dinamik sepse një version i tillë mund të konsiderohet prototip). Aspekte të tjera, të tilla si besueshmëria, mund të përfshijnë jo vetëm softuerin, por edhe harduerin themelor, prandaj, ai mund të vlerësohet si në mënyrë statike ashtu edhe dinamike (testi i stresit).

Përdorimi i testeve të automatizuara dhe funksioneve të fitnesit mund të ndihmojë në ruajtjen e disa prej atributeve të lidhura me cilësinë e softuerit.[6]

Cilësia funksionale zakonisht vlerësohet në mënyrë dinamike, por është gjithashtu e mundur të përdoren teste statike (të tilla si rishikimet e softuerit).

Struktura, klasifikimi dhe terminologjia e atributeve dhe metrikave të zbatueshme për menaxhimin e cilësisë së softuerit janë nxjerrë ose nxjerrë nga ISO 9126-3 dhe modeli pasues i cilësisë ISO/IEC 25000:2005. Fokusi kryesor është në cilësinë e brendshme të strukturës. Nënkategoritë janë krijuar për të trajtuar fusha specifike si arkitektura e aplikacioneve të biznesit dhe karakteristikat teknike si qasja dhe manipulimi i të dhënave ose nocioni i transaksioneve.

Madhësia e matjes së cilësisë së softuerit përcakton se në çfarë niveli një program apo sistem i softuerit vlerësohet në secilën nga këto pesë dimensione. Një masë e përmbledhur e cilësisë së softuerit mund të llogaritet përmes një skeme vlerësimi cilësore apo quantitative, ose një kombinim i të dyjave, dhe pastaj një sistem peshe që reflekton prioritetet. Ky shikim i cilësisë së softuerit, i vendosur në një vijë të drejtë, plotësohet nga analiza e "gabimeve kritike të programimit", të cilat nën rrethana të caktuara mund të shkaktojnë ndërprerje katastrofike apo ulje të performancës që e bëjnë një sistem të papërshtatshëm për përdorim, pavarësisht nga vlerësimi bazuar në matjet e përmbledhura. Gabimet e tilla të programimit që ndodhin në nivelin e sistemit përfaqësojnë deri në 90 përqind të çështjeve në prodhim, ndërsa në nivelin e njësisë, edhe pse shumë më të shumta, gabimet e programimit përbëjnë më pak se 10 përqind të çështjeve në prodhim (shih gjithashtu Rregulli nëntë-nëntë). Si pasojë, cilësia e kodit pa kontekstin e sistemit tërësor, siç e përshkroi W. Edwards Deming, ka vlerë të kufizuar.

Për të parë, eksploruar, analizuar dhe komunikuar matjet e cilësisë së softuerit, konceptet dhe teknikat e vizualizimit të informacionit ofrojnë mjete vizuale, ndërvepruese të dobishme, në veçanti, nëse disa masa të cilësisë së softuerit duhet të lidhen me njëri-tjetrin ose me komponentët e një softueri ose sistemi. Për shembull, hartat e softuerit përfaqësojnë një qasje të specializuar që "mund të shprehë dhe kombinojë informacionin rreth zhvillimit të softuerit, cilësisë së softuerit dhe dinamikës së sistemit".

Cilësia e softuerit gjithashtu luan një rol në fazën e lëshimit të një projekti softuerësh. Në mënyrë të veçantë, cilësia dhe vendosja e proceseve të lëshimit (gjithashtu proceset patch),[7][8] menaxhimi i konfigurimit[9] janë pjesë të rëndësishme të një procesi të përgjithshëm të inxhinierisë softuerike.[10][11][12]

Motivimi

Redakto

Cilësia e softuerit motivohet nga të paktën dy këndvështrime kryesore:

  • Menaxhimi i rrezikut : Dështimi i softuerit ka shkaktuar më shumë se shqetësim. Gabimet e softuerit mund të shkaktojnë vdekje njerëzore (shih për shembull: Lista e gabimeve të softuerit). Shkaqet kanë variuar nga ndërfaqet e përdoruesit të dizajnuara keq deri te gabimet e drejtpërdrejta të programimit,[13][14][15] shih për shembull rastet e Boeing 737 ose rastet e nxitimit të paqëllimtë[16][17] ose rastet Therac-25. Kjo rezultoi në kërkesa për zhvillimin e disa llojeve të softuerit, veçanërisht dhe historikisht për softuerët e integruar në pajisje mjekësore dhe pajisje të tjera që rregullojnë infrastrukturat kritike: "[Inxhinierët që shkruajnë softuer të integruar] shohin programet Java duke ngecur për një të tretën e sekondës për të kryer mbeturina mbledhin dhe përditësojnë ndërfaqen e përdoruesit, dhe ata parashikojnë aeroplanët që bien nga qielli." Në Shtetet e Bashkuara, brenda Administratës Federale të Aviacionit (FAA), Shërbimi i Certifikimit të Avionëve FAA ofron programe softuerike, politika, udhëzime dhe trajnime, fokus në softuer dhe Hardware Elektronik Kompleks që ka një efekt në produktin në ajër (një "produkt" është një avion, një motor ose një helikë).[18] Standardet e certifikimit si DO-178C, ISO 26262, IEC 62304, etj. ofrojnë udhëzime.
  • Menaxhimi i kostos : Si në çdo fushë tjetër të inxhinierisë, një produkt ose shërbim softuerësh i drejtuar nga cilësia e mirë e softuerit kushton më pak për t'u mirëmbajtur, është më i lehtë për t'u kuptuar dhe mund të ndryshojë me kosto më efektive në përgjigje të nevojave urgjente të biznesit.[19] Të dhënat e industrisë tregojnë se cilësia e dobët strukturore e aplikacioneve në aplikacionet kryesore të biznesit (si planifikimi i burimeve të ndërmarrjes (ERP), menaxhimi i marrëdhënieve me klientët (CRM) ose sistemet e mëdha të përpunimit të transaksioneve në shërbimet financiare) rezulton në kosto, tejkalime të planit dhe krijon mbeturina në formën e ripunim (shih Muda (termi japonez)).[20][21][22] Për më tepër, cilësia e dobët strukturore është e lidhur ngushtë me ndërprerjet e biznesit me ndikim të lartë për shkak të të dhënave të korruptuara, ndërprerjeve të aplikacioneve, shkeljeve të sigurisë dhe problemeve të performancës.[23]
    • CISQ raporton mbi koston e vlerësimeve të cilësisë së dobët një ndikim të:
    • Raporti i kostos së një shkeljeje të të dhënave të IBM 2020 vlerëson se kostot mesatare globale të një shkeljeje të të dhënave:[26][27]
      • 3.86 milionë dollarë

Përkufizimet

Redakto

ISO

Redakto

Cilësia e softuerit është "aftësia e një produkti softuerik për t'iu përshtatur kërkesave".[28][29] ndërsa për të tjerët mund të jetë sinonim i krijimit të klientit ose vlerës [30][31] apo edhe nivelit të defektit.[32] Matjet e cilësisë së softuerit mund të ndahen në tre pjesë: cilësia e procesit, cilësia e produktit që përfshin vetitë e brendshme dhe të jashtme dhe së fundi, cilësia në përdorim, që është efekti i softuerit.[33]

ASQ

Redakto

ASQ përdor përkufizimin e dhene i cilii është: Cilësia e softuerit përshkruan atributet e dëshirueshme të produkteve softuerike. Ekzistojnë dy qasje kryesore: menaxhimi i defekteve dhe atributet e cilësisë.[34]

NIST

Redakto

Software Assurance (SA) mbulon si pronën ashtu edhe procesin për ta arritur atë:[35]

  • Besimi [e justifikueshme] se softueri është i lirë nga dobësitë, ose i projektuar qëllimisht në softuer ose i futur aksidentalisht në çdo kohë gjatë ciklit të tij jetësor dhe se softueri funksionon në mënyrën e synuar
  • Një grup i planifikuar dhe sistematik i aktiviteteve që sigurojnë që proceset dhe produktet e ciklit jetësor të softuerit të jenë në përputhje me kërkesat, standardet dhe procedurat

PMI

Redakto

Udhëzuesi i Institutit të Menaxhimit të Projekteve (PMI) "Zgjerimi i Softuerit" i PMBOK nuk e përcakton vetë "Cilësinë e Softuerit", por e definon Sigurimin e Cilësisë së Softuerit (SQA) si "një proces të vazhdueshëm që auditon proceset e tjera të softuerit për të siguruar që ato po ndiqen (përfshin, për shembull, një plan menaxhimi të cilësisë së softuerit)." Ndërsa, Kontrolli i Cilësisë së Softuerit (SCQ) nënkupton "aplikimin e metodave, mjeteve dhe teknikave për të siguruar që produktet e punës plotësojnë kërkesat për cilësi për një softuer në zhvillim ose modifikim." [36]

Të tjera të përgjithshme dhe historike

Redakto

Përkufizimi i parë i historisë së cilësisë që kujton është nga Shewhart në fillim të shekullit të 20-të (d.m.th rreth viteve 1901): "Ka dy aspekte të përbashkëta të cilësisë: njëri prej tyre ka të bëjë me konsiderimin e cilësisë së një sendi si një realitet objektiv i pavarur nga ekzistenca e Njeriu tjetri ka të bëjë me atë që ne mendojmë, ndjejmë ose ndjejmë si rezultat i realitetit objektiv.[37]

Kitchenham dhe Pfleeger, duke raportuar më tej mësimet e David Garvin, identifikojnë 5 këndvështrime të ndryshme mbi cilësinë e softuerit:[38][39]

  • Perspektiva transcendentale merret me aspektin metafizik të cilësisë. Në këtë këndvështrim të cilësisë, është "diçka drejt së cilës ne përpiqemi si ideal, por mund të mos e zbatojmë kurrë plotësisht". Vështirë se mund të përkufizohet, por është e ngjashme me atë që një gjykatës federal komentoi dikur për turpësinë: "E di kur e shoh".[40]
  • Perspektiva e përdoruesit ka të bëjë me përshtatshmërinë e produktit për një kontekst të caktuar përdorimi. Ndërsa pamja transcendentale është eterike, pamja e përdoruesit është më konkrete, e bazuar në karakteristikat e produktit që plotësojnë nevojat e përdoruesit. [41]
  • Perspektiva e prodhimit përfaqëson cilësinë si përputhje me kërkesat. Ky aspekt i cilësisë theksohet nga standarde të tilla si ISO 9001, i cili përcakton cilësinë si "shkalla në të cilën një grup karakteristikash të qenësishme përmbush kërkesat" (ISO/IEC 9001 ).
  • Perspektiva e produktit nënkupton që cilësia mund të vlerësohet duke matur karakteristikat e qenësishme të produktit.
  • Perspektiva përfundimtare e cilësisë është e bazuar në vlerë. [30] Kjo perspektivë pranon se perspektivat e ndryshme të cilësisë mund të kenë rëndësi ose vlerë të ndryshme për aktorë të ndryshëm. 

Problemi i natyrshëm në përpjekjet për të përcaktuar cilësinë e një produkti, pothuajse çdo produkti, u deklarua nga mjeshtri Walter A. Shewhart. Vështirësia në përcaktimin e cilësisë është të përkthehen nevojat e ardhshme të përdoruesit në karakteristika të matshme, në mënyrë që një produkt të mund të dizajnohet dhe të dalë që të japë kënaqësi me një çmim që përdoruesi do të paguajë. Kjo nuk është e lehtë dhe sapo dikush ndihet mjaft i suksesshëm në përpjekje, ai zbulon se nevojat e konsumatorit kanë ndryshuar, konkurrentët kanë hyrë në vend, etj.[42]

Cilësia është një përcaktim i klientit, jo një përcaktim i inxhinierit, jo një përcaktim marketingu, as një përcaktim i përgjithshëm i menaxhimit. Ai bazohet në përvojën aktuale të klientit me produktin ose shërbimin, e matur kundrejt kërkesave të tij ose të saj -- të deklaruara ose të padeklaruara, të vetëdijshme ose thjesht të ndjeshme, teknikisht operacionale ose tërësisht subjektive -- dhe që përfaqëson gjithmonë një objektiv të lëvizshëm në një treg konkurrues.[43]

Fjala cilësi ka shumë kuptime. Dy nga këto kuptime dominojnë përdorimin e fjalës: 1. Cilësia përbëhet nga ato veçori të produktit që plotësojnë nevojat e klientëve dhe në këtë mënyrë ofrojnë kënaqësinë e produktit. 2. Cilësia përbëhet nga liria nga mangësitë. Megjithatë, në një manual si ky është e përshtatshme të standardizohet një përkufizim i shkurtër i fjalës cilësi si "përshtatshmëri për përdorim".[44]

Tom DeMarco ka propozuar që "cilësia e një produkti është një funksion i asaj se sa e ndryshon botën për mirë". Kjo mund të interpretohet si kuptim që cilësia funksionale dhe kënaqësia e përdoruesit janë më të rëndësishme se cilësia strukturore në përcaktimin e cilësisë së softuerit.

Një përkufizim tjetër, i shpikur nga Gerald Weinberg në Menaxhimin e Softuerit të Cilësisë: Mendimi i Sistemeve, është "Cilësia është vlerë për dikë". [43] [44]

Kuptime dhe polemika të tjera

Redakto

Një nga sfidat në përcaktimin e cilësisë është se "të gjithë mendojnë se e kuptojnë atë" dhe përkufizime të tjera të cilësisë së softuerit mund të bazohen në zgjerimin e përshkrimeve të ndryshme të konceptit të cilësisë që përdoret në biznes.

Cilësia e softuerit gjithashtu shpesh ngatërrohet me Sigurimin e Cilësisë ose Menaxhimin e Zgjidhjes së Problemeve[45] ose Kontrollin e Cilësisë [46] ose DevOps. Ai përputhet me fushat e përmendura më parë (shih gjithashtu përkufizimet e PMI), por është i veçantë pasi nuk fokusohet vetëm në testim, por edhe në procese, menaxhim, përmirësime, vlerësime, etj. [46]

Matja

Redakto

Megjithëse konceptet e paraqitura në këtë seksion janë të zbatueshme si për cilësinë e softuerit strukturor ashtu edhe për atë funksional, matja e kësaj të fundit kryhet në thelb përmes testimit të softuerit.[47] Testimi nuk mjafton: Sipas një studimi, "programuesit individualë janë më pak se 50% efikas në gjetjen e gabimeve në softuerin e tyre. Dhe shumica e formave të testimit janë vetëm 35% efikase. Kjo e bën të vështirë përcaktimin e cilësisë së [softuerit]."[48]

Skeda:SoftwareQualityCharacteristicAttributeRelationship.png
Marrëdhënia ndërmjet karakteristikave të dëshirueshme të softuerit (djathtas) dhe atributeve të matshme (left)

Matja e cilësisë së softuerit ka të bëjë me përcaktimin sasior në çfarë mase një sistem ose softuer zotëron karakteristika të dëshirueshme. Kjo mund të kryhet përmes mjeteve cilësore ose sasiore ose një përzierje e të dyjave. Në të dyja rastet, për secilën karakteristikë të dëshirueshme, ekzistojnë një sërë atributesh të matshme, ekzistenca e të cilave në një pjesë të softuerit ose sistemit priret të lidhet dhe të shoqërohet me këtë karakteristikë. Për shembull, një atribut i lidhur me transportueshmërinë është numri i deklaratave të varura nga objektivi në një program. Më saktësisht, duke përdorur qasjen e vendosjes së funksionit të cilësisë, këto atribute të matshme janë "si" që duhet të zbatohen për të mundësuar "çfarë" në përkufizimin e cilësisë së softuerit më sipër.

Struktura, klasifikimi dhe terminologjia e atributeve dhe metrikave të zbatueshme për menaxhimin e cilësisë së softuerit janë nxjerrë ose nxjerrë nga ISO 9126-3 dhe modeli pasues i cilësisë ISO/IEC 25000:2005. Fokusi kryesor është në cilësinë e brendshme të strukturës. Nënkategoritë janë krijuar për të trajtuar fusha specifike si arkitektura e aplikacioneve të biznesit dhe karakteristikat teknike si qasja dhe manipulimi i të dhënave ose nocioni i transaksioneve.

Pema e varësisë midis karakteristikave të cilësisë së softuerit dhe atributeve të tyre të matshme paraqitet në diagramin në të djathtë, ku secila nga 5 karakteristikat që kanë rëndësi për përdoruesin (djathtas) ose pronarin e sistemit të biznesit varet nga atributet e matshme (majtas):

  • Praktikat e Arkitekturës së Aplikimit
  • Praktikat e kodimit
  • Kompleksiteti i aplikimit
  • Dokumentacioni
  • Transportueshmëri
  • Vëllimi teknik dhe funksional

Korrelacionet midis gabimeve të programimit dhe defekteve të prodhimit zbulojnë se gabimet e kodit bazë përbëjnë 92 përqind të gabimeve totale në kodin burimor. Këto probleme të shumta të nivelit të kodit përfundimisht llogariten për vetëm 10 përqind të defekteve në prodhim. Praktikat e këqija të inxhinierisë softuerike në nivelet e arkitekturës përbëjnë vetëm 8 për qind të defekteve totale, por konsumojnë mbi gjysmën e përpjekjes së shpenzuar për rregullimin e problemeve dhe çojnë në 90 për qind të çështjeve serioze të besueshmërisë, sigurisë dhe efikasitetit në prodhim.[49][50]

Analiza e bazuar në kod

Redakto

Shumë nga masat ekzistuese të softuerit numërojnë elementë strukturorë të aplikacionit që rezultojnë nga analizimi i kodit burimor për instruksione të tilla individuale[51] shenjat[52] strukturat e kontrollit (Kompleksiteti) dhe objektet.[53]

Matja e cilësisë së softuerit ka të bëjë me përcaktimin sasior të nivelit të një sistemi ose softueri përgjatë këtyre dimensioneve. Analiza mund të kryhet duke përdorur një qasje cilësore ose sasiore ose një përzierje të të dyjave për të ofruar një pamje të përgjithshme [duke përdorur për shembull mesataren e ponderuar(at) që pasqyrojnë rëndësinë relative ndërmjet faktorëve që maten].

Kjo pikëpamje e cilësisë së softuerit në një vazhdimësi lineare duhet të plotësohet me identifikimin e Gabimeve Kritike të Programimit diskrete. Këto dobësi mund të mos dështojnë në një rast testimi, por ato janë rezultat i praktikave të këqija që në rrethana specifike mund të çojnë në ndërprerje katastrofike, degradime të performancës, shkelje të sigurisë, të dhëna të korruptuara dhe një mori problemesh të tjera[54] që e bëjnë një sistem të caktuar de facto i papërshtatshëm për përdorim pavarësisht nga vlerësimi i tij i bazuar në matjet e grumbulluara. Një shembull i mirënjohur i cenueshmërisë është Common Weakness Enumeration,[55] një depo dobësish në kodin burimor që i bën aplikacionet të ekspozuara ndaj shkeljeve të sigurisë.

Matja e karakteristikave kritike të aplikacionit përfshin matjen e atributeve strukturore të arkitekturës së aplikacionit, kodimit dhe dokumentacionit në linjë, siç tregohet në foton e mësipërme. Kështu, çdo karakteristikë ndikohet nga atribute në nivele të shumta të abstraksionit në aplikim dhe të gjitha këto duhet të përfshihen në llogaritjen e masës së karakteristikës nëse do të jetë një parashikues i vlefshëm i rezultateve cilësore që ndikojnë në biznes. Qasja me shtresa për llogaritjen e masave karakteristike të paraqitura në figurën e mësipërme u propozua për herë të parë nga Boehm dhe kolegët e tij në TRW (Boehm, 1978) dhe është qasja e marrë në standardet e serive ISO 9126 dhe 25000. Këto atribute mund të maten nga rezultatet e analizuara të një analize statike të kodit burimor të aplikacionit. Edhe karakteristikat dinamike të aplikacioneve si besueshmëria dhe efikasiteti i performancës i kanë rrënjët e tyre shkakësore në strukturën statike të aplikacionit.

Analiza dhe matja e cilësisë strukturore kryhet nëpërmjet analizës së kodit burimor, arkitekturës, kornizës së softuerit, skemës së bazës së të dhënave në raport me parimet dhe standardet që së bashku përcaktojnë arkitekturën konceptuale dhe logjike të një sistemi. Kjo është e dallueshme nga analiza bazë, lokale, e kodit në nivel përbërës, e kryer zakonisht nga mjetet e zhvillimit, të cilat kryesisht kanë të bëjnë me konsideratat e zbatimit dhe janë thelbësore gjatë aktiviteteve të korrigjimit dhe testimit .

Besueshmëria

Redakto

Shkaqet kryesore të besueshmërisë së dobët gjenden në një kombinim të mospërputhjes me praktikat e mira arkitekturore dhe të kodimit. Kjo mospërputhje mund të zbulohet duke matur atributet e cilësisë statike të një aplikacioni. Vlerësimi i atributeve statike që qëndrojnë në themel të besueshmërisë së një aplikacioni siguron një vlerësim të nivelit të rrezikut të biznesit dhe gjasave të dështimeve dhe defekteve të mundshme të aplikacionit që aplikacioni do të përjetojë kur të vihet në funksion.

Vlerësimi i besueshmërisë kërkon kontrolle të të paktën praktikave më të mira të inxhinierisë softuerike dhe atributeve teknike të mëposhtme:

  • Praktikat e Arkitekturës së Aplikimit
  • Praktikat e kodimit
  • Kompleksiteti i algoritmeve
  • Kompleksiteti i praktikave të programimit
  • Pajtueshmëria me praktikat më të mira të programimit të orientuar drejt objektit dhe të strukturuar (kur është e aplikueshme)
  • Raporti i ripërdorimit të komponentit ose modelit
  • Programim i pistë
  • Trajtimi i gabimeve dhe përjashtimeve (për të gjitha shtresat - GUI, Logic & Data)
  • Pajtueshmëria e dizajnit me shumë shtresa
  • Menaxhimi i kufijve të burimeve
  • Softueri shmang modelet që do të çojnë në sjellje të papritura
  • Softueri menaxhon integritetin dhe qëndrueshmërinë e të dhënave
  • Niveli i kompleksitetit të transaksionit

Në varësi të arkitekturës së aplikacionit dhe komponentëve të palëve të treta të përdorura (të tilla si bibliotekat e jashtme ose kornizat), kontrollet me porosi duhet të përcaktohen përgjatë vijave të nxjerra nga lista e mësipërme e praktikave më të mira për të siguruar një vlerësim më të mirë të besueshmërisë së softuerit të dorëzuar.

Efikasiteti

Redakto

Ashtu si me Besueshmërinë, shkaqet e joefikasitetit të performancës shpesh gjenden në shkeljet e praktikës së mirë arkitekturore dhe të kodimit, të cilat mund të zbulohen duke matur atributet e cilësisë statike të një aplikacioni. Këto atribute statike parashikojnë pengesa të mundshme të performancës operacionale dhe probleme të shkallëzimit të ardhshëm, veçanërisht për aplikacionet që kërkojnë shpejtësi të lartë ekzekutimi për trajtimin e algoritmeve komplekse ose vëllime të mëdha të dhënash.

Vlerësimi i efikasitetit të performancës kërkon kontrollimin e të paktën praktikave më të mira të inxhinierisë softuerike dhe atributeve teknike të mëposhtme:

  • Praktikat e Arkitekturës së Aplikimit
  • Ndërveprimet e duhura me burime të shtrenjta dhe/ose të largëta
  • Performanca e aksesit të të dhënave dhe menaxhimi i të dhënave
  • Menaxhimi i memories, rrjetit dhe hapësirës në disk
  • Pajtueshmëria me praktikat e kodimit [56] (Praktikat më të mira të kodimit)

Siguria

Redakto

Cilësia e softuerit përfshin sigurinë e softuerit.[57] Shumë dobësi sigurie rezultojnë nga kodimi i dobët dhe praktikat arkitekturore të tilla si injeksioni SQL ose skriptimi në faqe.[58][59] Këto janë të dokumentuara mirë në listat e mbajtura nga CWE,[60] dhe SEI/Computer Emergency Center (CERT) në Universitetin Carnegie Mellon. [56]

Vlerësimi i sigurisë kërkon të paktën kontrollimin e praktikave më të mira të inxhinierisë softuerike dhe atributeve teknike:

  • Zbatimi, Menaxhimi i një procesi zhvillimi të vetëdijshëm për sigurinë dhe forcimi, p.sh. Cikli i Jetës së Zhvillimit të Sigurisë (Microsoft) ose Korniza e Sigurt Inxhinierike e IBM.[61]
  • Praktikat e Sigurta të Arkitekturës së Aplikimit[62][63]
  • Pajtueshmëria e dizajnit me shumë shtresa
  • Praktikat më të mira të sigurisë (Vleresimi i hyrjes, injektimi SQL, skriptimet në faqe, kontrolli i aksesit etj.)[64][65]
  • Praktika të sigurta dhe të mira programimi [56]
  • Trajtimi i gabimeve dhe përjashtimeve

Mirëmbajtja

Redakto

Mirëmbajtja përfshin konceptet e modularitetit, kuptueshmërisë, ndryshueshmërisë, testueshmërisë, ripërdorueshmërisë dhe transferueshmërisë nga një ekip zhvillimi në tjetrin. Këto nuk marrin formën e çështjeve kritike në nivelin e kodit. Përkundrazi, mirëmbajtja e dobët është zakonisht rezultat i mijëra shkeljeve të vogla me praktikat më të mira në dokumentacion, strategjinë e shmangies së kompleksitetit dhe praktikat bazë të programimit që bëjnë dallimin midis kodit të pastër dhe të lehtë për t'u lexuar kundrejt kodit të paorganizuar dhe të vështirë për t'u lexuar..

Vlerësimi i mirëmbajtjes kërkon kontrollimin e praktikave më të mira të inxhinierisë softuerike dhe atributeve teknike të mëposhtme:

  • Praktikat e Arkitekturës së Aplikimit
  • Dokumentacioni i arkitekturës, programeve dhe kodit të ngulitur në kodin burimor
  • Lexueshmëria e kodit
  • Kodi mban erë
  • Niveli i kompleksitetit të transaksioneve
  • Kompleksiteti i algoritmeve
  • Kompleksiteti i praktikave të programimit
  • Pajtueshmëria me praktikat më të mira të programimit të orientuar drejt objektit dhe të strukturuar (kur është e aplikueshme)
  • Raporti i ripërdorimit të komponentit ose modelit
  • Niveli i kontrolluar i kodimit dinamik
  • Raporti i bashkimit
  • Programim i pistë
  • Dokumentacioni
  • Hardware, OS, Middleware, komponentët e softuerit dhe pavarësia e bazës së të dhënave
  • Pajtueshmëria e dizajnit me shumë shtresa
  • Transportueshmëri
  • Praktikat e programimit (niveli i kodit)
  • Kod dhe funksione të reduktuara dublikatë
  • Pastërtia e organizimit të skedarit të kodit burimor

Mirëmbajtja është e lidhur ngushtë me konceptin e Ward Cunningham për borxhin teknik, i cili është një shprehje e kostove që rezultojnë nga mungesa e mirëmbajtjes. Arsyet pse mirëmbajtja është e ulët mund të klasifikohen si të pamatur kundrejt maturisë dhe të qëllimshme kundër paqëllimshme,[66][67] dhe shpesh e kanë origjinën në paaftësinë e zhvilluesve, mungesën e kohës dhe qëllimeve, pakujdesinë e tyre dhe mospërputhjet në koston e krijimit. dhe përfiton nga dokumentacioni dhe, në veçanti, kodi burimor i mirëmbajtur.[68]

Madhësia

Redakto

Matja e madhësisë së softuerit kërkon që i gjithë kodi burimor të mblidhet saktë, duke përfshirë skriptet e strukturës së bazës së të dhënave, kodin burimor të manipulimit të të dhënave, titujt e komponentëve, skedarët e konfigurimit etj. Në thelb ekzistojnë dy lloje të madhësive të softuerit që duhen matur, madhësia teknike (gjurma) dhe madhësia funksionale:

  • Ka disa metoda teknike të përcaktimit të madhësisë së softuerit që janë përshkruar gjerësisht. Metoda më e zakonshme e madhësisë teknike është numri i linjave të kodit (#LOC) për teknologji, numri i skedarëve, funksioneve, klasave, tabelave, etj., nga të cilat mund të llogariten Pikat e Funksionit të kundërt;
  • Më e zakonshme për matjen e madhësisë funksionale është analiza e pikës së funksionit. Analiza e pikës së funksionit mat madhësinë e softuerit të dorëzuar nga këndvështrimi i përdoruesit. Madhësia e pikës së funksionit bëhet në bazë të kërkesave të përdoruesit dhe ofron një paraqitje të saktë të madhësisë për zhvilluesin/vlerësuesin dhe vlerën (funksionaliteti që do të dorëzohet) dhe pasqyron funksionalitetin e biznesit që i dorëzohet klientit. Metoda përfshin identifikimin dhe peshimin e hyrjeve, daljeve dhe ruajtjes së të dhënave të njohura nga përdoruesi. Vlera e madhësisë është më pas e disponueshme për t'u përdorur në lidhje me masat e shumta për të përcaktuar sasinë dhe për të vlerësuar ofrimin dhe performancën e softuerit (kosto e zhvillimit për pikë funksioni; defekte të dorëzuara për pikë funksioni; pikë funksioni për muaj stafi.).

Standardi i madhësisë së analizës së pikës së funksionit mbështetet nga Grupi Ndërkombëtar i Përdoruesve të Pikave të Funksionit (IFPUG). Mund të aplikohet në fillim të ciklit jetësor të zhvillimit të softuerit dhe nuk varet nga linja kodi si metoda disi e pasaktë Backfiring. Metoda është agnostike e teknologjisë dhe mund të përdoret për analiza krahasuese në të gjithë organizatat dhe industritë.

Që nga fillimi i Analizës së Pikës së Funksionit, disa variacione kanë evoluar dhe familja e teknikave funksionale të përmasave është zgjeruar për të përfshirë masa të tilla të përmasave si COSMIC, NESMA, Pikat e Përdorimit të Rastit, FP Lite, FP-të e hershme dhe të shpejta dhe së fundmi Pikat e tregimit. Function Point ka një histori të saktësisë statistikore dhe është përdorur si një njësi e zakonshme e matjes së punës në menaxhimin e zhvillimit të aplikacioneve të shumta (ADM) ose angazhimet e jashtme, duke shërbyer si "monedhë" me të cilën ofrohen shërbimet dhe matet performanca.

Një kufizim i zakonshëm i metodologjisë së Pikës së Funksionit është se ai është një proces manual dhe për këtë arsye mund të jetë intensiv i punës dhe i kushtueshëm në iniciativa në shkallë të gjerë si zhvillimi i aplikacioneve ose angazhimet e kontraktimit. Ky aspekt negativ i aplikimit të metodologjisë mund të jetë ajo që i motivoi udhëheqësit e industrisë së TI-së për të formuar Konsorciumin për Cilësinë e Softuerit të TI-së të fokusuar në prezantimin e një standardi të llogaritshëm metrikë për automatizimin e matjes së madhësisë së softuerit ndërkohë që IFPUG vazhdon të promovojë një qasje manuale pasi shumica e aktivitetit të saj mbështetet. në çertifikatat e sporteleve FP.

CISQ përcakton madhësinë si për të vlerësuar madhësinë e softuerit për të mbështetur vlerësimin e kostos, ndjekjen e progresit ose aktivitete të tjera të lidhura me menaxhimin e projektit të softuerit. Përdoren dy standarde: Pikat e automatizuara të funksionit për të matur madhësinë funksionale të softuerit dhe Pikat e automatizuara të përmirësimit për të matur madhësinë e kodit funksional dhe jofunksional në një masë.[69]

Identifikimi i gabimeve kritike të programimit

Redakto

Gabimet kritike të programimit janë praktika të këqija specifike arkitekturore dhe/ose koduese që rezultojnë në rrezikun më të lartë, të menjëhershëm ose afatgjatë të ndërprerjes së biznesit.[70]

Këto janë mjaft shpesh të lidhura me teknologjinë dhe varen shumë nga konteksti, objektivat e biznesit dhe rreziqet. Disa mund të konsiderojnë respektimin e konventave të emërtimit, ndërsa të tjerët – ata që përgatitin terrenin për një transferim njohurish për shembull – do ta konsiderojnë atë si absolutisht kritik.

Gabimet kritike të programimit mund të klasifikohen gjithashtu sipas karakteristikave të CISQ. Shembulli bazë më poshtë:

  • Besueshmëria
    • Shmangni modelet e softuerit që do të çojnë në sjellje të papritura (ndryshore e pa inicializuar, tregues null, etj.)
    • Metodat, procedurat dhe funksionet që bëjnë Fut, Përditëso, Fshi, Krijo Tabelën ose Zgjidh duhet të përfshijnë menaxhimin e gabimeve
    • Funksionet me shumë fije duhet të bëhen të sigurta në lidhje me fijet, për shembull klasat e veprimit të servleteve ose struteve nuk duhet të kenë fusha statike instance/jo-finale
  • Efikasiteti
    • Siguroni centralizimin e kërkesave të klientëve (në hyrje dhe të dhëna) për të reduktuar trafikun e rrjetit
    • Shmangni pyetjet SQL që nuk përdorin një indeks kundrejt tabelave të mëdha në një lak
  • Siguria
    • Shmangni fushat në klasat servlet që nuk janë statike përfundimtare
    • Shmangni aksesin e të dhënave pa përfshirë menaxhimin e gabimeve
    • Kontrolloni kodet e kthimit të kontrollit dhe zbatoni mekanizmat e trajtimit të gabimeve
    • Siguroni vërtetimin e hyrjes për të shmangur të metat e skriptimit të tërthortë në faqe ose të metat e injektimit SQL
  • Mirëmbajtja
    • Pemët e trashëguara të thella dhe foleja duhet të shmangen për të përmirësuar kuptueshmërinë
    • Modulet duhet të lidhen lirshëm (fanout, ndërmjetës) për të shmangur përhapjen e modifikimeve

Zbatoni konventat homogjene të emërtimit

Modele cilësore të funksionalizuara

Redakto

Propozimet më të reja për modelet e cilësisë si Squale dhe Quamoco[71] përhapin një integrim të drejtpërdrejtë të përkufizimit të atributeve të cilësisë dhe matjes. Duke zbërthyer atributet e cilësisë apo edhe duke përcaktuar shtresa shtesë, atributet komplekse, abstrakte të cilësisë (si besueshmëria ose mirëmbajtja) bëhen më të menaxhueshme dhe më të matshme. Këto modele cilësore janë aplikuar në kontekste industriale, por nuk kanë marrë miratim të gjerë.

Shiko më shumë

Redakto
  • Aksesueshmëria
  • Disponueshmëria
  • Praktikat më të mira të kodimit
  • Konventat e kodimit
  • Kohezioni dhe bashkimi
  • Defekt kompjuterik
  • Kompleksiteti ciklomatik
  • Kriticiteti i defektit
  • Besueshmëria
  • GQM
  • ISO/IEC 9126
  • Përmirësimi i procesit të softuerit dhe përcaktimi i aftësive - ISO/IEC 15504
  • Stili i programimit
  • Cilësia: kontrolli i cilësisë, menaxhimi total i cilësisë.
  • Menaxhimi i kërkesave
  • Fushëveprimi (menaxhimi i projektit)
  • Siguria
  • Inxhinieri sigurie
  • Arkitektura e softuerit
  • Defekt i softuerit
  • Sigurimi i cilësisë së softuerit
  • Kontrolli i cilësisë së softuerit
  • Metrika e softuerit
  • Ripërdorimi i softuerit
  • Standardi i softuerit
  • Testimi i softuerit
  • Analiza statike e programit
  • Testueshmëria

Lexim të mëtejshëm

Redakto


Referencat

Redakto

Shenime

  1. ^ "Learning from history: The case of Software Requirements Engineering – Requirements Engineering Magazine". Learning from history: The case of Software Requirements Engineering – Requirements Engineering Magazine (në anglisht). Marrë më 2021-02-25.
  2. ^ Pressman, Roger S. (2005). Software Engineering: A Practitioner's Approach (bot. Sixth International). McGraw-Hill Education. fq. 388. ISBN 0071267824. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  3. ^ "About the Automated Source Code Quality Measures Specification Version 1.0". www.omg.org. Marrë më 2021-02-25. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  4. ^ "How to Perform End-to-End Testing". smartbear.com. Marrë më 2021-02-25. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  5. ^ "How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations" (PDF). Arkivuar (PDF) nga origjinali më 2013-12-28. Marrë më 2013-10-18. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  6. ^ Fundamentals of Software Architecture: An Engineering Approach. O'Reilly Media. 2020. ISBN 978-1492043454. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  7. ^ "IIA - Global Technology Audit Guide: IT Change Management: Critical for Organizational Success". na.theiia.org. Marrë më 2021-02-26. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  8. ^ Boursier, Jérôme (2018-01-11). "Meltdown and Spectre fallout: patching problems persist". Malwarebytes Labs (në anglishte amerikane). Marrë më 2021-02-26.
  9. ^ "Best practices for software updates - Configuration Manager". docs.microsoft.com (në anglishte amerikane). Marrë më 2021-02-26.
  10. ^ Wright, Hyrum K. (2009-08-25). "Release engineering processes, models, and metrics". Proceedings of the doctoral symposium for ESEC/FSE on Doctoral symposium. ESEC/FSE Doctoral Symposium '09. Amsterdam, the Netherlands: Association for Computing Machinery. fq. 27–28. doi:10.1145/1595782.1595793. ISBN 978-1-60558-731-8. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  11. ^ van der Hoek, André; Hall, Richard S.; Heimbigner, Dennis; Wolf, Alexander L. (nëntor 1997). "Software release management". ACM SIGSOFT Software Engineering Notes (në anglisht). 22 (6): 159–175. doi:10.1145/267896.267909. ISSN 0163-5948.{{cite journal}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  12. ^ Sutton, Mike; Moore, Tym (2008-07-30). "7 Ways to Improve Your Software Release Management". CIO (në anglisht). Marrë më 2021-02-26.
  13. ^ Clark, Mitchell (2021-02-24). "iRobot says it'll be a few weeks until it can clean up its latest Roomba software update mess". The Verge (në anglisht). Marrë më 2021-02-25.
  14. ^ "Top 25 Software Errors". www.sans.org. Marrë më 2021-02-25. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  15. ^ "'Turn it Off and On Again Every 149 Hours' Is a Concerning Remedy for a $300 Million Airbus Plane's Software Bug". Gizmodo (në anglishte amerikane). 30 korrik 2019. Marrë më 2021-02-25.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  16. ^ "MISRA C, Toyota and the Death of Task X". Marrë më 2021-02-25. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  17. ^ "An Update on Toyota and Unintended Acceleration « Barr Code". embeddedgurus.com. Marrë më 2021-02-25. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  18. ^ "Aircraft Certification Software and Airborne Electronic Hardware". Arkivuar nga origjinali më 4 tetor 2014. Marrë më 28 shtator 2014. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  19. ^ "The Cost of Poor Software Quality in the US: A 2020 Report | CISQ - Consortium for Information & Software Quality". www.it-cisq.org. Marrë më 2021-02-25. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  20. ^ "What is Waste? | Agile Alliance". Agile Alliance | (në anglishte amerikane). 20 prill 2016. Marrë më 2021-02-25.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  21. ^ Matteson, Scott (janar 26, 2018). "Report: Software failure caused $1.7 trillion in financial losses in 2017". TechRepublic (në anglisht). Marrë më 2021-02-25.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  22. ^ Cohane, Ryan (2017-11-16). "Financial Cost of Software Bugs". Medium (në anglisht). Marrë më 2021-02-25.
  23. ^ Eloff, Jan; Bella, Madeleine Bihina (2018), "Software Failures: An Overview", Software Failure Investigation (në anglisht), Cham: Springer International Publishing, fq. 7–24, doi:10.1007/978-3-319-61334-5_2, ISBN 978-3-319-61333-8, marrë më 2021-02-25
  24. ^ "Poor software quality cost businesses $2 trillion last year and put security at risk". CIO Dive (në anglishte amerikane). Marrë më 2021-02-26.
  25. ^ "Synopsys-Sponsored CISQ Research Estimates Cost of Poor Software Quality in the US $2.08 Trillion in 2020". finance.yahoo.com (në anglishte amerikane). Marrë më 2021-02-26.
  26. ^ "What Does a Data Breach Cost in 2020?". Digital Guardian. 2020-08-06. Marrë më 2021-03-08. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  27. ^ "Cost of a Data Breach Report 2020 | IBM". www.ibm.com. 2020. Marrë më 2021-03-08. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  28. ^ "ISO - ISO 9000 family — Quality management". ISO (në anglisht). Marrë më 2021-02-24.
  29. ^ "ISO/IEC/IEEE 24765:2017". ISO (në anglisht). Marrë më 2021-02-24.
  30. ^ a b "Mastering automotive software". www.mckinsey.com. Marrë më 2021-02-25. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  31. ^ "ISO/IEC 25010:2011". ISO (në anglisht). Marrë më 2021-02-24.
  32. ^ Wallace, D.R. (2002). "Practical software reliability modeling". Proceedings 26th Annual NASA Goddard Software Engineering Workshop. Greenbelt, MD, USA: IEEE Comput. Soc. fq. 147–155. doi:10.1109/SEW.2001.992668. ISBN 978-0-7695-1456-7. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  33. ^ "ISO/IEC 25023:2016". ISO (në anglisht). Marrë më 2023-11-06.
  34. ^ "What is Software Quality? | ASQ". asq.org. Marrë më 2021-02-24. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  35. ^ "SAMATE - Software Assurance Metrics And Tool Evaluation project main page". NIST. 3 shkurt 2021. Marrë më 2021-02-26. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  36. ^ Software extension to the PMBOK guide. Project Management Institute (bot. 5th). Newtown Square, Pennsylvania. 2013. ISBN 978-1-62825-041-1. OCLC 959513383. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Mungon shtëpia botuese te vendodhja (lidhja) Mirëmbajtja CS1: Është përdorur gabimisht parametri i të tjerëve (lidhja)
  37. ^ Shewart, Walter A. (2015). Economioc control of quality of manufactured product. [Place of publication not identified]: Martino Fine Books. ISBN 978-1-61427-811-5. OCLC 1108913766. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  38. ^ Kitchenham, B.; Pfleeger, S. L. (janar 1996). "Software quality: the elusive target [special issues section]". IEEE Software. 13 (1): 12–21. doi:10.1109/52.476281. ISSN 1937-4194. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  39. ^ Garvin, David A. (1988). Managing quality : the strategic and competitive edge. New York: Free Press. ISBN 0-02-911380-6. OCLC 16005388. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  40. ^ Kan, Stephen H. (2003). Metrics and models in software quality engineering (bot. 2nd). Boston: Addison-Wesley. ISBN 0-201-72915-6. OCLC 50149641. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  41. ^ Gabim referencash: Etiketë <ref> e pavlefshme; asnjë tekst nuk u dha për refs e quajtura Kitchenham1996
  42. ^ W. E. Deming, "Dalja nga kriza: cilësia, produktiviteti dhe pozicioni konkurrues". Cambridge University Press, 1988.
  43. ^ a b Weinberg, Gerald M. (1991). Quality software management: Volume 1, Systems Thinking. New York, N.Y.: Dorset House. ISBN 0-932633-22-6. OCLC 23870230. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  44. ^ a b Weinberg, Gerald M. (1993). Quality software management: Volume 2, First-Order Measurement. New York, N.Y.: Dorset House. ISBN 0-932633-22-6. OCLC 23870230. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  45. ^ "SUP.9 – Problem Resolution Management - Kugler Maag Cie". www.kuglermaag.com. Marrë më 2021-02-25. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  46. ^ a b Hoipt (2019-11-29). "Organizations often use the terms 'Quality Assurance' (QA) vs 'Quality Control' (QC)…". Medium (në anglisht). Marrë më 2021-02-25.
  47. ^ Wallace, D.; Watson, A. H.; Mccabe, T. J. (1996-08-01). "Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric". NIST (në anglisht).
  48. ^ Bellairs, Richard. "What Is Code Quality? And How to Improve Code Quality". Perforce Software (në anglisht). Marrë më 2021-02-28.
  49. ^ "OMG Whitepaper | CISQ - Consortium for Information & Software Quality". www.it-cisq.org. Marrë më 2021-02-26. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  50. ^ "How to Deliver Resilient, Secure, Efficient and Agile IT Systems in Line with CISQ Recommendations - Whitepaper | Object Management Group" (PDF). Arkivuar (PDF) nga origjinali më 2013-12-28. Marrë më 2013-10-18. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  51. ^ "Software Size Measurement: A Framework for Counting Source Statements". resources.sei.cmu.edu (në anglisht). 31 gusht 1992. Marrë më 2021-02-24.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  52. ^ Halstead, Maurice H. (1977). Elements of Software Science (Operating and programming systems series). USA: Elsevier Science Inc. ISBN 978-0-444-00205-1. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  53. ^ Chidamber, S. R.; Kemerer, C. F. (qershor 1994). "A metrics suite for object oriented design". IEEE Transactions on Software Engineering. 20 (6): 476–493. doi:10.1109/32.295895. ISSN 1939-3520. {{cite journal}}: |hdl-access= ka nevojë për |hdl= (Ndihmë!); Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  54. ^ Nygard, Michael (2007). Release It!. an O'Reilly Media Company Safari (bot. 1st). Pragmatic Bookshelf. ISBN 978-0978739218. OCLC 1102387436. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  55. ^ "CWE - Common Weakness Enumeration". cwe.mitre.org. Arkivuar nga origjinali më 2016-05-10. Marrë më 2016-05-20. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  56. ^ a b c "SEI CERT Coding Standards - CERT Secure Coding - Confluence". wiki.sei.cmu.edu. Marrë më 2021-02-24. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  57. ^ "Code quality and code security: How are they related? | Synopsys". Software Integrity Blog (në anglishte amerikane). 2019-05-24. Marrë më 2021-03-09.
  58. ^ "Cost of a Data Breach Report 2020 | IBM". www.ibm.com. 2020. Marrë më 2021-03-09. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  59. ^ "Key Takeaways from the 2020 Cost of a Data Breach Report". Bluefin (në anglishte amerikane). 2020-08-27. Marrë më 2021-03-09.
  60. ^ "CWE - Common Weakness Enumeration". Cwe.mitre.org. Arkivuar nga origjinali më 2013-10-14. Marrë më 2013-10-18. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  61. ^ Security in Development: The IBM Secure Engineering Framework | IBM Redbooks (në anglishte amerikane). 2016-09-30.
  62. ^ Enterprise Security Architecture Using IBM Tivoli Security Solutions | IBM Redbooks (në anglishte amerikane). 2016-09-30.
  63. ^ "Secure Architecture Design Definitions | CISA". us-cert.cisa.gov. Marrë më 2021-03-09. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  64. ^ "OWASP Foundation | Open Source Foundation for Application Security". owasp.org (në anglisht). Marrë më 2021-02-24.
  65. ^ "CWE's Top 25". Sans.org. Marrë më 2013-10-18. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  66. ^ Fowler, Martin (tetor 14, 2009). "TechnicalDebtQuadrant". Arkivuar nga origjinali më shkurt 2, 2013. Marrë më shkurt 4, 2013. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  67. ^ "Code quality: a concern for businesses, bottom lines, and empathetic programmers". Stack Overflow. 2021-10-18. Marrë më 2023-12-05. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  68. ^ Prause, Christian; Durdik, Zoya (qershor 3, 2012). "Architectural design and documentation: Waste in agile development?". 2012 International Conference on Software and System Process (ICSSP). IEEE Computer Society. fq. 130–134. doi:10.1109/ICSSP.2012.6225956. ISBN 978-1-4673-2352-9. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  69. ^ "Software Sizing Standards | CISQ - Consortium for Information & Software Quality". www.it-cisq.org. Marrë më 2021-01-28. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  70. ^ "Why Software fails". IEEE Spectrum: Technology, Engineering, and Science News (në anglisht). 2 shtator 2005. Marrë më 2021-03-20.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  71. ^ Wagner, Stefan; Goeb, Andreas; Heinemann, Lars; Kläs, Michael; Lampasona, Constanza; Lochmann, Klaus; Mayr, Alois; Plösch, Reinhold; Seidl, Andreas (2015). "Operationalised product quality models and assessment: The Quamoco approach" (PDF). Information and Software Technology. 62: 101–123. arXiv:1611.09230. doi:10.1016/j.infsof.2015.02.009. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  72. ^ Suryanarayana, Girish (2015). "Software Process versus Design Quality: Tug of War?". IEEE Software. 32 (4): 7–11. doi:10.1109/MS.2015.87. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  73. ^ "Software Quality Professional | ASQ". asq.org. Marrë më 2021-01-28. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  74. ^ "Software Quality Journal". Springer (në anglisht). Marrë më 2021-01-28.

Bibliografia

Redakto
  • Albrecht, A. J. (1979), Matja e produktivitetit të zhvillimit të aplikacioneve. Në punimet e Simpoziumit të Përbashkët SHARE/GUIDE IBM Applications Development., IBM
  • Ben-Menachem, M.; Marliss, G. S. (1997), Cilësia e softuerit, prodhimi i softuerit praktik dhe konsistent, Thomson Computer Press
  • Boehm, B.; Brown, J.R.; Kaspar, H.; Lipow, M.; MacLeod, G.J.; Merritt, M.J. (1978), Karakteristikat e cilësisë së softuerit, Hollanda e Veriut.
  • Chidamber, S.; Kemerer, C. (1994), Një Suite Metrike për Dizajn të Orientuar në Objekte. IEEE Transactions on Software Engineering, 20 (6), fq. 476–493
  • Ebert, Christof; Dumke, Reiner, Software Measurement: Establish - Extract - Evaluate - Execute, Kindle Edition, f.91
  • Garmus, D.; Herron, D. (2001), Analiza e Pikës së Funksionit, Addison Wesley
  • Halstead, M.E. (1977), Elements of Software Science, Elsevier North-Holland
  • Hamill, M.; Goseva-Popstojanova, K. (2009), Gabimet e zakonshme në të dhënat e gabimeve dhe dështimeve të softuerit. IEEE Transactions of Software Engineering, 35 (4), fq. 484–496
  • Jackson, D.J. (2009), Një rrugë e drejtpërdrejtë drejt softuerit të besueshëm. Komunikimet e ACM, 52 (4).
  • Martin, R. (2001), Menaxhimi i dobësive në sistemet e rrjetit, IEEE Computer.
  • McCabe, T. (Dhjetor 1976), Një masë kompleksiteti. Transaksionet IEEE në Inxhinieri Softuerësh
  • McConnell, Steve (1993), Code Complete (First ed.), Microsoft Press
  • Nygard, M.T. (2007), Lëshojeni! Dizajnimi dhe vendosja e softuerit të gatshëm për prodhim, programuesit pragmatikë.
  • Park, R.E. (1992), Matja e madhësisë së softuerit: Një kornizë për numërimin e deklaratave të burimit. (CMU/SEI-92-TR-020)., Instituti i Inxhinierisë Softuerike, Universiteti Carnegie Mellon
  • Pressman, Roger S. (2005). Inxhinieria e Softuerit: Qasja e një praktikuesi (redaktimi i gjashtë ndërkombëtar). Edukimi McGraw-Hill. ISBN 0071267824.
  • Spinellis, D. (2006), Cilësia e kodit, Addison Wesley

Lidhje të jashtme

Redakto
Marrë nga "https://sq.wikipedia.org/w/index.php?title=Cilësia_e_programit&oldid=2730341"