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. 
 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ë.  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.W. E. Deming, "Dalja nga kriza: cilësia, produktiviteti dhe pozicioni konkurrues". Cambridge University Press, 1988.

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.

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

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

 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. 

 Matja 
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. 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. 

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.
 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 
 Trajtimi i gabimeve dhe përjashtimeve

 Mirëmbajtja 
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, 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. 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. ISBN 0071267824.
 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.

Category:Të menduarit e sistemeve
Cilësia
Category:Kodi burimor