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. 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. Ë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), në nivelin e njësisë dhe në nivelin e sistemit (ndonjëherë referuar si fund-ne-fund testimi i fundit), 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).

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.

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), menaxhimi i konfigurimit janë pjesë të rëndësishme të një procesi të përgjithshëm të inxhinierisë softuerike.

## Motivimi 
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, shih për shembull rastet e Boeing 737 ose rastet e nxitimit të paqëllimtë 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ë). 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. 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)). 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.
** CISQ raporton mbi koston e vlerësimeve të cilësisë së dobët një ndikim të:
*** 2.08 trilion dollarë në 2020
*** 2.84 trilion dollarë në 2018 
** 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:
*** 3.86 milionë dollarë

## Përkufizimet 
### ISO 
Cilësia e softuerit është "aftësia e një produkti softuerik për t'iu përshtatur kërkesave". ndërsa për të tjerët mund të jetë sinonim i krijimit të klientit ose vlerës  apo edhe nivelit të defektit. 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.

### ASQ 
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ë.

### NIST 
Software Assurance (SA) mbulon si pronën ashtu edhe procesin për ta arritur atë:

* 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 
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." ''*

### Të tjera të përgjithshme dhe historike 
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.''

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

* 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".
* 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. 

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. 

### Kuptime dhe polemika të tjera 
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 ose Kontrollin e Cilësisë  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.  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]."

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.

### Analiza e bazuar në kod 
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 shenjat strukturat e kontrollit (Kompleksiteti) dhe objektet.

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 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, 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 
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 
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  (Praktikat më të mira të kodimit)

### Siguria 
Cilësia e softuerit përfshin sigurinë e softuerit. Shumë dobësi sigurie rezultojnë nga kodimi i dobët dhe praktikat arkitekturore të tilla si injeksioni SQL ose skriptimi në faqe. Këto janë të dokumentuara mirë në listat e mbajtura nga CWE, dhe SEI/Computer Emergency Center (CERT) në Universitetin Carnegie Mellon. 
* Praktikat e Sigurta të Arkitekturës së Aplikimit
* 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.)
* Praktika të sigurta dhe të mira programimi  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.

### Madhësia 
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ë.

### Identifikimi i gabimeve kritike të programimit 
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.

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 
Propozimet më të reja për modelet e cilësisë si Squale dhe Quamoco 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ë
* 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 
* Udhëzimet e cilësisë së sistemit operativ Android, duke përfshirë listat kontrolluese për ndërfaqen e përdoruesit, sigurinë, etj. korrik 2021
* Shoqata e Menaxherëve Detarë në Teknologjinë e Informacionit dhe Komunikimit (AMMITEC). Udhëzimet për cilësinë e softuerit detar. shtator 2017
* Capers Jones dhe Olivier Bonsignour, "The Economics of Software Quality", Addison-Wesley Professional, botimi i parë, 31 dhjetor 2011, 
* CAT Lab - Laboratori i mjeteve të analizës së kodit CNES (në GitHub)
* Girish Suryanarayana, Procesi i softuerit kundrejt cilësisë së dizajnit: tërheqje e luftës? 
* Ho-Won Jung, Seung-Gweon Kim dhe Chang-Sin Chung. Matja e cilësisë së produktit të softuerit: Një studim i ISO/IEC 9126. *IEEE Software*, 21(5):10–13, shtator/tetor 2004.
* Organizata Ndërkombëtare për Standardizim. *Inxhinieri Softuerësh—Cilësia e produktit—Pjesa 1: Modeli i cilësisë*. ISO, Gjenevë, Zvicër, 2001. ISO/IEC 9126-1:2001(E).
* Matja e cilësisë së produktit të softuerit: Seria ISO 25000 dhe CMMI (faqe SEI)
* *MSQF - Një kornizë e cilësisë së softuerit të bazuar në matje,* Biblioteka e Universitetit Cornell
* Omar Alshathry, Helge Janicke, "Optimizing Software Quality Assurance", compsacw, f.&nbsp;87–92, 2010 Punëtoritë e Konferencës së 34-të Vjetore të IEEE për Programet kompjuterike dhe Aplikacionet, 2010.
* Robert L. Glass. *Softuer me cilësi të ndërtimit*. Prentice Hall, Upper Saddle River, NJ, 1992.
* Roland Petrasch, " Përkufizimi i 'Cilësisë së Softuerit': Një Qasje Praktike ", ISSRE, 1999
* Profesionist i cilësisë së softuerit, Shoqëria Amerikane për Cilësinë (ASQ)
* Journal Quality Software nga Springer Nature
* Stephen H. Kan. *Metrikat dhe modelet në inxhinierinë e cilësisë së softuerit*. Addison-Wesley, Boston, MA, botimi i dytë, 2002.
* Stefan Wagner. Kontrolli i cilësisë së produktit të softuerit. Springer, 2013

 

## Referime 
**Shenime**

## Bibliografia 
* 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. .
* Spinellis, D. (2006), Cilësia e kodit, Addison Wesley
## Lidhje të jashtme 
* Kur kodi është mbret: Përvetësimi i përsosmërisë së softuerit të automobilave  (McKinsey, 2021)
* Cilësia e softuerit të sistemit të integruar: Pse është kaq shpesh e tmerrshme?  Çfarë mund të bëjmë për këtë?  (nga Philip Koopman)
* Standardet e Cilësisë së Kodit nga CISQ ™
* Blog i CISQ: https://blog.it-cisq.org
* Udhëzues për sigurimin e cilësisë së softuerit  (ESA)
* Udhëzues për aplikimin e standardeve të inxhinierisë softuerike ESA në projekte të vogla softuerike (ESA)
* Një përmbledhje e Shërbimeve të Sigurimit të Produkteve të Softuerit ESA  (NASA/ESA)
* Qasja jonë ndaj cilësisë në Volkswagen Software Dev Center Lisbonë
* Udhëzuesit e stilit të Google
* Sigurimi i cilësisë së produktit në Google (2011)
* Sigurimi i softuerit të NASA-s
* Grupi i Cilësisë së Softuerit NIST
* Pikat e automatizuara të funksionit OMG/CISQ (ISO/IEC 19515)
* Standardi i automatizuar i borxhit teknik OMG
* Sigurimi i automatizuar i cilësisë (artikulluar në IREB nga Harry Sneed)
* Testimi i strukturuar: Një Metodologji Testimi Duke përdorur Metrikën e Kompleksitetit Ciklomatik (1996)
* Analizimi i cilësisë së aplikacionit duke përdorur mjetet e analizës së kodit (Microsoft, Documentation, Visual Studio, 2016)

***Redaktuar në gjuhën shqipe nga Gjergj M. Çuni, student i shkencave kompjuterike në FShMN. Dhjetor, 2024.***