Cilësia e softuerit. Cilësia e softuerit: Standardet dhe Vlerësimi

17.07.2019 Windows 8

Pak më shumë se një vit më parë, një artikull im me titull "Parimet e menaxhimit të cilësisë së softuerit" u botua në revistën Open Systems. Versioni në internet është i disponueshëm këtu: http://www.osp.ru/os/2008/06/5344965/ . Para botimit, versioni origjinal i artikullit u rishikua shumë nga redaktorët, si rezultat i të cilit përmasat e tij u ulën me 2 herë, dhe teksti, duke përfshirë titullin, gjithashtu u rrah me lopatë. Tani vendosa të publikoj versionin e përditësuar të autorit në blogun tim, duke bërë shtesa të vogla atje. Artikulli nuk është në formatin e blogut, por më tepër për një botim shkencor ose edukativ, ndaj na falni.

Tema e cilësisë së softuerit përmendet shpesh në literaturën dhe artikujt në gjuhën ruse, por rrallëherë shkon përtej fjalimeve të gjata ose bisedave për testimin. Qëllimi i këtij artikulli është të japë një pamje holistike të problemit të cilësisë së softuerit (SW) dhe parimeve bazë të menaxhimit të cilësisë së softuerit. Artikulli përcakton konceptin e cilësisë së softuerit, përshkruan një qasje që thjeshton detyrën e analizës së cilësisë, ofron një përmbledhje të shkurtër të metodave të njohura për përmirësimin e cilësisë.

I. Koncepti i cilësisë së softuerit

Përcaktimi i cilësisë së një produkti softuer
Sipas GOST R ISO 9000-2001, cilësia është "shkalla e përputhshmërisë së karakteristikave të qenësishme (të një produkti) me kërkesat". Ky është një përkufizim i përgjithshëm. Nëse transferohet fjalë për fjalë në fushën e zhvillimit të softuerit (SW), atëherë mund të mos interpretohet mjaft saktë. Fakti është se zhvillimi i kërkesave, në kuptimin që ky term kuptohet për fushën e softuerit, është një pjesë integrale e procesit të zhvillimit të softuerit. Cilësia e kërkesave për një produkt softuer (SP) ndikon drejtpërdrejt në cilësinë e vetë softuerit. Me fjalë të tjera, nëse kërkesat për produktet softuerike janë të cilësisë së dobët, atëherë vetë produkti, i zhvilluar sipas këtyre kërkesave, do të jetë gjithashtu i cilësisë së dobët, edhe në rastin e një përputhje të përsosur.

Nëse fjala "kërkesa" në përkufizimin e GOST zëvendësohet me fjalët "qëllimet e projektit" (këtu, një projekt nënkupton procesin e zhvillimit të një produkti specifik softueri ose zgjerimin e funksionalitetit të një produkti ekzistues), atëherë gjithçka bie në vend. Më tej në artikull, me cilësinë e softuerit do të nënkuptojmë sa vijon:

Vini re se ky përkufizim nuk zbatohet për çështjet e kostos. Qëllimet e një projekti të zhvillimit të softuerit përcaktohen kryesisht nga qëllimet e biznesit dhe kufizimet ekzistuese.

Kriteret e cilësisë së PP
Cilësia e PP është një koncept kompleks dhe i shumëanshëm. Në përgjithësi, cilësia është një funksion i variablave të mëposhtëm:

Funksionaliteti (sa i dobishëm është softueri për përdoruesit);
Cilësia e ndërfaqes së përdoruesit (lehtësia e përdorimit, lehtësia e të mësuarit);
Besueshmëria (mungesa e defekteve në softuer, rezistenca ndaj dështimeve);
Performanca, konsumi i burimeve, kërkesat mjedisore;
Cilësia e mbështetjes së informacionit (dokumentacioni);
Mirëmbajtja (cilësia e arkitekturës dhe kodit, cilësia e brendshme);
+ mundësisht kritere të tjera.

Variantet e tjera të listës së kritereve të cilësisë mund të gjenden, për shembull, në , . Kompania e zhvillimit përcakton (duhet të përcaktojë) standardet e saj të cilësisë për çdo kriter për çdo projekt softuerësh. Kur vlerësoni cilësinë, është e nevojshme të jeni në gjendje të kuantizoni secilin nga kriteret.

Ndikimi i aktiviteteve të ciklit jetësor në cilësinë e produkteve softuerike
Merrni parasysh aktivitetet tipike të ciklit jetësor të projektit të softuerit dhe ndikimin e tyre në kriteret e cilësisë të listuara më sipër. Në tabelën më poshtë, simboli * do të thotë që ky aktivitet (rresht) ndikon qartë në këtë kriter të cilësisë (kolona):

Pika kryesore për të cilën do të doja të tërhiqja vëmendjen këtu është si vijon: cilësia e produktit përfundimtar ndikohet nga të gjitha fazat dhe aktivitetet e projektit, pa përjashtim - nga më të hershmet deri tek më të fundit. Kështu, sa mirë dhe cilësisht punojmë në secilën fazë të projektit (dhe jo vetëm, për shembull, në fazën e testimit), varet nga cilësia e produktit të zhvilluar. Ose me fjalë të tjera, cilësia e procesit të zhvillimit përcakton cilësinë e produktit që zhvillohet, d.m.th. Cilësia e produktit është e pandashme nga cilësia e procesit, dhe për të përmirësuar cilësinë e një produkti softuer, është e nevojshme të përmirësohet cilësia e procesit të zhvillimit të këtij produkti softuer.

Koncepti i përgjithësuar i një defekti
Do të ishte e përshtatshme të futej dhe të përdorej një kriter i caktuar i përgjithësuar i cilësisë për analizën e cilësisë në vend të disa kritereve të ndryshme. Një kriter i tillë është koncepti i përgjithësuar i një defekti:

Kështu, do të quajmë defekt çdo devijim nga standardi i cilësisë për cilindo nga kriteret e mësipërme. Për shembull, mungesa e funksionalitetit ose funksionaliteti shtesë është një defekt. Një ndërfaqe e papërshtatshme është një defekt. Kodi i dizajnuar keq ose i çrregullt që ndikon negativisht në mirëmbajtjen është një defekt. Performanca e papranueshme është një defekt. Funksionimi i gabuar i programit (“bug”, sjellje e gabuar) është një rast i veçantë i një defekti. Një gabim drejtshkrimor në dokumentacionin e përdoruesit është gjithashtu një defekt.

Defektet mund të klasifikohen, për shembull, sipas parametrave të mëposhtëm:

Lloji i defektit (i përcaktuar nga faza e zhvillimit ose aktiviteti në të cilin është paraqitur);

Kriticiteti i defektit (sa kritike është prania e tij në softuer);

Përparësia e defektit (sa e rëndësishme është rregullimi i tij);

Kompleksiteti i defektit (sa e vështirë është ta rregullosh atë);

Me një matje të tillë të përgjithësuar të kundërt të cilësisë, bëhet më e lehtë për të vlerësuar dhe analizuar cilësinë e softuerit të zhvilluar, si dhe cilësinë e procesit tonë të zhvillimit në përgjithësi. Mund të numërojmë numrin e defekteve ose shumën e peshave të tyre (sipas disa parametrave), mund të vlerësojmë dendësinë e defekteve për njësi vëllimi të produktit, të analizojmë se cilat faza të procesit janë më problematike për ne, etj. Tani lufta për cilësi nuk është gjë tjetër veçse lufta kundër defekteve.

II. Menaxhimi i cilësisë së produkteve softuerike

Qasja tradicionale ndaj cilësisë së produktit softuer
Duke prezantuar konceptin e përgjithësuar të një defekti, mund të vizatoni një grafik që përshkruan ndryshimin në numrin e defekteve në një projekt me kalimin e kohës (Fig. 1). Për thjeshtësi, merrni parasysh modelin e ujëvarës së ciklit jetësor të projektit. Në qasjen tradicionale ndaj cilësisë së PCB-ve, ku theksi vihet në testimin rigoroz, ky orar mund të duket kështu.

Oriz. 1. Ndryshimi i numrit të defekteve në projekt me kalimin e kohës me qasjen tradicionale të menaxhimit të cilësisë dhe me ciklin jetësor të ujëvarës.

Këtu, vija e sipërme e kuqe përfaqëson numrin e defekteve të paraqitura në momentin aktual (duhet sqaruar se kjo linjë është imagjinare, pasi nuk do të mund të llogarisim me saktësi numrin total të defekteve derisa t'i gjejmë të gjitha). Vija e poshtme jeshile tregon numrin e defekteve të gjetura dhe të rregulluara në kohën aktuale (këtu supozojmë se defektet rregullohen pothuajse menjëherë pasi janë gjetur). Dallimi midis vijave të kuqe dhe jeshile në çdo moment në kohë përfaqëson numrin e defekteve aktualisht të pranishme. Ne jemi më të interesuar se cili do të jetë ky ndryshim në fund të projektit. Sa më i vogël të jetë, aq më mirë doli produkti ynë. Për sa i përket cilësisë, cikli i jetës në këtë figurë paraqitet si një konkurrencë midis proceseve të paraqitjes dhe korrigjimit të defekteve.

Efikasiteti i gjetjes së defekteve
Konsideroni një nga fazat që synojnë gjetjen dhe rregullimin e defekteve, për shembull, fazën e testimit të sistemit. Gjatë kësaj faze, zbulohen një numër i caktuar defektesh D të gjetura, ndërsa në të njëjtën kohë, një numër i caktuar defektesh mbeten të pagjetura në fund të fazës D të humbur (Fig. 2). Numri total i defekteve që kaluan nëpër fazë do të jetë i barabartë me D të gjetur + D të humbura.

Oriz. 2. Ndryshimi i numrit të defekteve gjatë një faze.

Le ta quajmë raportin e defekteve të gjetura me numrin e tyre të përgjithshëm, të shprehur në përqindje, efikasitetin e kërkimit të defekteve (EPD%):

EPD% = .

Për çdo fazë gjatë së cilës defektet gjenden dhe korrigjohen, në një proces të maturuar dhe gjëra të tjera janë të barabarta, kjo vlerë duhet të pritet të jetë afërsisht konstante. Ky fakt bën të mundur përcaktimin sasior të nivelit të cilësisë (të shprehur në numrin e defekteve që nuk janë gjetur) për projektin aktual dhe për projektet e planifikuara.

Efikasiteti i gjetjes së defekteve mund të konsiderohet si për fazat dhe aktivitetet individuale, ashtu edhe për të gjithë ciklin jetësor të zhvillimit. Në të njëjtën kohë, efikasiteti i fazave individuale përcakton efikasitetin për të gjithë ciklin e jetës. Çdo fazë e kërkimit të defekteve mund të konsiderohet si një lloj filtri që ruan një pjesë të caktuar të defekteve, dhe të gjithë ciklin jetësor, si një sistem filtrash, . Nëse në fazat e hershme të ciklit jetësor ka filtra të këqij që lejojnë të kalojnë shumë defekte, atëherë këto defekte grumbullohen dhe për t'i filtruar mirë, në fund të ciklit jetësor (faza e testimit) do të na duhet një shumë e mirë. filtër.

Kostoja e rregullimit të defekteve
Defektet jo vetëm që priren të grumbullohen me kalimin e kohës nëse nuk ndërmerren veprime të hershme për t'i korrigjuar ato. Por dihet gjithashtu se sa më gjatë të jetë një defekt në një projekt, aq më i kushtueshëm është ta rregullosh atë (d.m.th., sa më kërkon kohë), dhe varësia shpesh është eksponenciale. Për modelin e ciklit jetësor të ujëvarës, kjo varësi ilustrohet mirë nga grafiku i mëposhtëm (Fig. 3).

Oriz. 3. Ndryshimi në koston e rregullimit të defekteve me kalimin e kohës (cikli jetësor i ujëvarës).

Për modelin iterativ të ciklit jetësor, fotografia do të jetë e ngjashme (Fig. 4), vetëm etiketat do të ndryshojnë dhe shkalla e boshtit Y për lloje të ndryshme defektesh (për shembull, për kërkesat dhe defektet e projektimit, shkalla do të të jetë më i madh se sa për defektet e kodimit).

Oriz. 4. Ndryshimi në koston e rregullimit të defekteve me kalimin e kohës (cikli jetësor iterativ).

Qasje e integruar për menaxhimin e cilësisë
Kështu, rezulton se mbështetja vetëm në një testim, megjithëse shumë të plotë, nuk do të zgjidhë problemin e cilësisë. Nëse nuk merrni asnjë masë për të luftuar defektet deri në fazën e testimit, atëherë me fillimin e testimit, projekti mund të grumbullojë aq shumë defekte sa që do të jetë një detyrë e pamundur për t'i zgjidhur ato.

Prandaj, defektet duhet të kërkohen dhe korrigjohen vazhdimisht, gjatë gjithë ciklit jetësor të projektit, duke filluar nga fazat më të hershme, dhe jo vetëm në fund gjatë fazës së testimit. Përafërsisht, në fund të projektit në fazën e testimit, tashmë është tepër vonë për të kërkuar defekte: nëse ka shumë prej tyre, atëherë asnjë sasi e testimit nuk do të ndihmojë në shndërrimin e një produkti me cilësi të ulët në një cilësi të lartë. një.

Qasja e dytë që mund dhe duhet të zbatohet paralelisht është parandalimi ose shmangia e defekteve, , .

Le të shqyrtojmë se si do të ndryshojë grafiku i varësisë së numrit të defekteve në kohë kur aplikohet një qasje e integruar për menaxhimin e cilësisë (Fig. 5). Zbatimi i teknikave të gjetjes së defekteve gjatë gjithë ciklit jetësor të një projekti e ngre kurbën e defekteve të gjetura lart. Dhe aplikimi i metodave të parandalimit të defekteve ul kurbën e defekteve të paraqitura poshtë. Kështu, numri i defekteve të pazbuluara gjatë gjithë ciklit jetësor zvogëlohet dhe si rezultat zvogëlohet numri i defekteve të pazbuluara në fund të projektit.

Oriz. 5. Ndryshimi i numrit të defekteve në projekt me kalimin e kohës me një qasje të integruar për menaxhimin e cilësisë.

Metodat e kërkimit të defekteve
Metodat e kërkimit të defekteve mund të klasifikohen sipas kritereve të mëposhtme:

statike dhe dinamike;
manual dhe i automatizuar.

Kështu, mund të dallohen 4 kategori metodash:

Analiza manuale e objekteve:
Kontroll automatik statik:
Testimi i automatizuar:
Testimi manual:

Secila nga metodat e mësipërme ka të mirat dhe të këqijat e saj. Disa lloje defektesh kapen më mirë nga disa metoda, disa nga të tjerat. Prandaj, një strategji efektive e kërkimit të defekteve do të jetë aplikimi i një kombinimi të disa metodave të ndryshme. Çdo metodë kërkimi, varësisht se sa mirë zbatohet dhe zbatohet në kushte specifike, do të ketë nivelin e vet të efikasitetit, të shprehur në përqindje. Në librin e S. McConnell "Perfect Code" mund të gjeni një tabelë me vlera të përafërta për efikasitetin e gjetjes së defekteve për metoda të ndryshme (shih një kopje të kësaj tabele më poshtë). Ju lutemi vini re se sipas këtyre të dhënave, testimi ka një efikasitet relativisht të ulët në gjetjen e defekteve (25%-40%), dhe për ta bërë atë të lartë, është e nevojshme të rritet kostoja e procesit të testimit me disa herë (efektshmëria i testimit beta me numrin e testuesve > 1000 është rreth 75 %).

Metoda e kërkimit	EPD%	Metoda e kërkimit	EPD%
Rishikim joformal i dizajnit (projekt teknik)	35%	Testimi i një funksioni të ri (komponenti)	30%
Inspektimet formale të projektimit (projektimi teknik)	55%	Testimi i integrimit	35%
Rishikimi jozyrtar i kodit	25%	Testimi i regresionit	25%
Inspektimet e kodit formal	60%	Testimi i sistemit	40%
Modelimi dhe Prototipizim	65%	Testimi beta (<10 тестеров)	35%
Testimi i njësisë	30%	Testimi beta (> 1000 testues)	75%

Metodat e parandalimit të defekteve
Nuk do të kishim nevojë për metodat e mësipërme për gjetjen e defekteve nëse do të mësonim se si të zhvillojmë softuer pa defekte fare. Vështirë se është e mundur të arrihet kjo, por ia vlen të përpiqeni të zvogëloni numrin e defekteve të paraqitura. Metodat për parandalimin e defekteve përfshijnë si më poshtë:

Prototipi është krijimi dhe testimi i një modeli të lirë të sistemit që po zhvillohet për të testuar karakteristikat e tij dhe për të identifikuar supozimet dhe vendimet e pasakta që mund të çojnë në defekte serioze (dhe ripunim) gjatë zhvillimit.

Përdorimi i standardeve për të gjitha llojet e produkteve të prodhuara gjatë zhvillimit të softuerit (kërkesat, arkitektura, kodi, dokumentacioni i ndryshëm, etj.). Standardet strikte të njohura botërisht minimizojnë keqkuptimet e mundshme midis njerëzve kur punojnë me këto produkte (kur lexuesi i produktit nuk ka lexuar atë që krijuesi i produktit ka pasur parasysh) dhe, si rezultat, parandalon shfaqjen e defekteve që lidhen me këtë.

Aplikimi i një qasjeje përbërëse (ose modulare). Zbatimi i duhur i qasjes së komponentëve në ndërtimin e sistemeve softuerike redukton kompleksitetin e tyre, dhe për rrjedhojë ngushton hapësirën e defekteve të mundshme.

Përdorimi i zgjidhjeve dhe komponentëve të dëshmuar të gatshëm (të vetë ose të blerë), në cilësinë e lartë për të cilat jemi të sigurt. Sa më pak të kemi për të zhvilluar zgjidhje të reja tona, aq më pak gabime bëjmë.

Rifaktorimi i kodit - bërja e kodit të duket e mirë është një mënyrë e mirë për të parandaluar defektet e ardhshme të mirëmbajtjes që priren të shfaqen kur modifikoni seksione të errëta dhe të dizajnuara keq të kodit.

Zhvillimi paraprak i rasteve të testimit (përpara fazës së kodimit) ju lejon të kuptoni më mirë kërkesat për sistemin që po zhvillohet dhe ta dizajnoni më mirë atë. Një rast i veçantë i kësaj qasjeje është Test-Driven Development, në të cilin testet e njësisë zhvillohen jo pas, por para kodimit.

Analiza e rregullt e shkaqeve të defekteve më serioze dhe kërkimi i mënyrave për eliminimin e këtyre shkaqeve. Kjo mund të ndodhë në takimet periodike të ekipit të zhvillimit, ose mund të bëhet për çdo defekt të madh të gjetur gjatë testimit të sistemit ose pas zbatimit. Rezultati i një analize të tillë duhet të jetë modifikime në procesin e zhvillimit që synojnë eliminimin e shkaqeve të defekteve ose, së paku, të kontribuojnë në zbulimin e hershëm të këtyre defekteve.

Idetë tuaja?

Këtu vlen të përmendet edhe faktori njerëzor. Asnjë metodë nuk mund të zëvendësojë profesionalizmin dhe përvojën e zhvilluesve dhe menaxherëve. Profesionistët e vërtetë me përvojë priren të bëjnë më pak gabime dhe përdorimi i përvojës së tyre jep një fillim të mirë për zhvillimin e cilësisë. Nëse ekipi përbëhet kryesisht nga zhvillues të rinj të papërvojë, atëherë duhet të keni parasysh mundësinë e kryerjes së trajnimeve speciale për ta.

Menaxhimi i cilësisë në ciklin jetësor iterativ
Konsideroni, për shembull, një cikël jetësor përsëritës të përbërë nga 5 përsëritje, secila prej të cilave mund të shihet si një cikël i vogël por i plotë i jetës së ujëvarës (Fig. 6).

Oriz. 6. Ndryshimi i numrit të defekteve në projekt me kalimin e kohës gjatë ciklit jetësor iterativ.

Le të supozojmë se efikasiteti i kërkimit të defekteve të secilit prej cikleve të ujëvarës është 50%, dhe i njëjti numër defektesh paraqitet në çdo përsëritje. Le të llogarisim me formulën EPD%, e cila do të jetë e barabartë me efikasitetin e kërkimit të defekteve në një cikël përsëritës që përbëhet nga pesë përsëritje të njëpasnjëshme. Pas përsëritjes së parë, ky efikasitet do të jetë i barabartë me 50%; pas 2 - 62,5%; pas datës 3 - 70,8%; pas datës 4 - 76,6%; pas 5-të të kërkimit të defektit, efikasiteti i të 5 përsëritjeve do të jetë i barabartë me 80.6%.

Ky shembull është idealizuar dhe në jetën reale, efikasiteti i gjetjes së defekteve në përsëritje të ndryshme ka të ngjarë të jetë i ndryshëm. Kjo është për shkak të heterogjenitetit të aktiviteteve në përsëritje të ndryshme. Por në çdo rast, ka një përparim të qartë në cilësi përpara një cikli të thjeshtë jetësor të ujëvarës. Ky efekt shpjegohet shumë thjesht: në çdo përsëritje të mëvonshme, ne gjejmë defekte jo vetëm të përsëritjes aktuale, por edhe defektet e mbetura të përsëritjeve të mëparshme. Si rezultat, efikasiteti i përgjithshëm i gjetjes së defekteve rritet.

Kështu, rezulton se përmirësimi i cilësisë mund të arrihet jo vetëm duke futur metoda shtesë të zbulimit të hershëm të defekteve (si inspektimet, rishikimet, etj.), por edhe duke kaluar nga një ujëvarë në një cikël jetësor të zhvillimit të softuerit përsëritës. Për më tepër, teorikisht, sa më shumë përsëritje, aq më e mirë është cilësia. Testimi në përsëritjet fillestare mund të mendohet si kërkim i defekteve në fillim të ciklit jetësor.

Kostoja e cilësisë së softuerit
Mund të duket se aplikimi i shumë metodave të ndryshme për të përmirësuar cilësinë e softuerit do të rrisë koston e zhvillimit të softuerit. Kjo mund të jetë e vërtetë në afat të shkurtër (derisa procesi i përdorimit të tyre të stabilizohet) ose nëse metodat nuk përdoren si duhet. Në terma afatgjatë, përdorimi i integruar i metodave të përmirësimit të cilësisë jo vetëm që nuk rrit koston e zhvillimit, por mund të ulë edhe koston e tij. Le të shohim pse ndodh kjo.

Së pari, siç u përmend më lart, sa më herët të gjendet një defekt, aq më lirë është ta rregulloni atë. Prandaj, aplikimi efektiv i metodave të zbulimit të hershëm të defekteve ndihmon në uljen e kostos së projektit.

Së dyti, metodat e kërkimit të defekteve të diskutuara më sipër, përveç efikasitetit, karakterizohen edhe nga një shpejtësi mesatare e gjetjes së defekteve. Sipas statistikave, për shembull nga , ky tregues për metodat e testimit është disa herë më i keq se sa për metodat e zbulimit të hershëm të defekteve. Kjo do të thotë që duke shpenzuar kohë duke kërkuar defekte në fazat e hershme, ne kursejmë më shumë kohë në testimin e ardhshëm.

S. McConnell argumenton se "përmirësimi i cilësisë së sistemit ul koston e zhvillimit të tij"; “Rregullimi i defektit (në fazat e mëvonshme) është në fakt faza më e shtrenjtë dhe më e kushtueshme e zhvillimit të softuerit.”

Procesi i Menaxhimit të Cilësisë
Për të menaxhuar cilësinë, nuk mjafton thjesht përdorimi i metodave të ndryshme për ta përmirësuar atë. Nevojitet aplikimi sistematik i tyre i ndërgjegjshëm, i cili do të bëhej pjesë integrale e procesit të zhvillimit të softuerit të orientuar drejt cilësisë.

Është e nevojshme të kontrollohet vazhdimisht cilësia e softuerit të zhvilluar përmes matjeve të cilësisë, si dhe kontrolli i cilësisë së nën-proceseve individuale që përbëjnë të gjithë procesin e zhvillimit.

Metodat që funksionuan mirë dje mund të jenë humbje kohe sot. Çdo projekt mund të ketë specifikat e veta, duke kërkuar një grup të ndryshëm metodash për përmirësimin e cilësisë. Nëse nuk monitoroni vazhdimisht efektivitetin e metodave, atëherë me kalimin e kohës mund të përkeqësohet ndjeshëm.

Menaxhimi i cilësisë është gjithashtu një kërkim i vazhdueshëm i mënyrave për të përmirësuar procesin e zhvillimit në mënyrë që të zvogëlohet numri i defekteve të paraqitura dhe të rritet efikasiteti i metodave të gjetjes së defekteve.

konkluzioni
Le të përmbledhim të gjitha sa më sipër. Cilësia e softuerit përcaktohet kryesisht nga procesi i zhvillimit të këtij softueri. Vetëm një proces i pjekur, i qëndrueshëm, i orientuar drejt cilësisë është i aftë të prodhojë produkte softuerësh me një nivel cilësie të parashikueshme dhe të kontrollueshme. Një proces i tillë duhet të bazohet në parimet bazë të menaxhimit të cilësisë së softuerit:

kërkimi dhe korrigjimi i vazhdueshëm i defekteve gjatë gjithë ciklit jetësor të zhvillimit, duke filluar nga fazat më të hershme;

aplikimi sistematik i metodave të parandalimit të defekteve;

kontroll i vazhdueshëm i cilësisë së softuerit të zhvilluar dhe procesit të zhvillimit;

përmirësimi i vazhdueshëm i procesit të zhvillimit me qëllim të përmirësimit të cilësisë.

Letërsia

1. Humphrey, Watts S., Një disiplinë për inxhinierinë e softuerit, ISBN 0-201-54610-8. E drejta e autorit 1995 nga Addison-Wesley.
2. McConnell S., Kodi i përsosur. Klasa master / Per. nga anglishtja. -M.: Shtëpia botuese dhe tregtare "Edicioni Rus"; Shën Petersburg: Peter, 2005.
3. Humphrey, Watts S., Introduction to Team Software Process, ISBN 0-201-47719-X. E drejta e autorit 2005 nga Addison Wesley Longman, Inc.
4. Humphrey, Watts S., PSP: një proces vetë-përmirësimi për inxhinierët e softuerit, ISBN 0-321-30549-3. E drejta e autorit 2005 Pearson Education Inc.
5. Ambler S., Teknologjitë fleksibël: programim ekstrem dhe proces i unifikuar i zhvillimit. Biblioteka e programuesit. Per. nga anglishtja. – Shën Petersburg: Peter, 2005.
6. P. Kroll, F. Kratchen, Procesi i Unifikuar Racional - është e lehtë. Udhëzues RUP për praktikuesit. Per. nga anglishtja. –M.: KUDITS-OBRAZ, 2004.
7. Torres R.J., Një udhëzues praktik për hartimin dhe zhvillimin e ndërfaqes së përdoruesit. Per nga anglishtja. -M.: Shtëpia Botuese Williams, 2002.
8. Bobrovsky S., Inxhinieri softuerike. Teknologjitë e Pentagonit në shërbim të programuesve rusë. – Shën Petersburg: Peter, 2003.
9. E. Hunt, D. Thomas, Programues Pragmatik. Rruga nga nxënësi në mjeshtër. Per. nga anglishtja. -M.: Shtëpia botuese "Lori", 2004.
10. Fowler M., Rifaktorimi: përmirësimi i kodit ekzistues. Per. nga anglishtja. - Shën Petersburg: Symbol-Plus, 2005.
11. Beck K., Programimi ekstrem. Per. nga anglishtja. – Shën Petersburg: Peter, 2002.
12. K. Beck, Programimi ekstrem: Zhvillimi i drejtuar nga testi. Biblioteka e programuesit. Per. nga anglishtja. – Shën Petersburg: Peter, 2003.
13. GOST R ISO 9000-2001, http://bib-gost.narod.ru/kazestvo/_gost_r_iso_9000_2001.zip
14. Royce Walker, Menaxhimi i procesit të zhvillimit të softuerit. Per. nga anglishtja. –M.: Shtëpia Botuese Lori, 2007.
15. Tian, Jeff, Inxhinieri e Cilësisë së Softuerit, ISBN 0-471-71345-7. E drejta e autorit 2005 nga IEEE Computer Society. Metodologjitë Disiplinat përkatëse

Cilësia e softuerit- karakteristikat e softuerit (SW) si shkalla e përputhshmërisë së tij me kërkesat. Në të njëjtën kohë, kërkesat mund të interpretohen mjaft gjerësisht, gjë që krijon një sërë përkufizimesh të pavarura të konceptit. Përkufizimi më i përdorur është ISO 9001, sipas të cilit cilësia është "shkalla në të cilën karakteristikat e qenësishme përputhen me kërkesat".

Cilësia e kodit burimor

Cilësia e kodit mund të përcaktohet me kritere të ndryshme. Disa prej tyre kanë rëndësi vetëm nga pikëpamja njerëzore. Për shembull, mënyra se si është formatuar teksti i programit është krejtësisht i parëndësishëm për kompjuterin, por mund të ketë një rëndësi të madhe për mirëmbajtjen e mëvonshme. Shumë nga standardet ekzistuese të kodimit, të cilat përcaktojnë konventa specifike për gjuhën e përdorur dhe vendosin një sërë rregullash që përmirësojnë lexueshmërinë e kodit, synojnë të lehtësojnë mirëmbajtjen e softuerit në të ardhmen, duke përfshirë korrigjimin dhe përditësimin. Ekzistojnë kritere të tjera që përcaktojnë nëse kodi është i shkruar "mirë", siç është strukturimi - shkalla në të cilën kodi ndahet logjikisht në një numër blloqesh të menaxhueshme.

Lexueshmëria e kodit
Lehtësia e mirëmbajtjes, testimit, korrigjimit, rregullimeve të gabimeve, ndryshimeve dhe transportueshmërisë
Kompleksitet i ulët i kodit
Përdorimi i ulët i burimeve: memoria dhe koha e procesorit
Trajtimi i saktë i përjashtimeve
Pak paralajmërime gjatë përpilimit dhe lidhjes

Teknika për përmirësimin e cilësisë së kodit: rifaktorimi.

Faktorët e Cilësisë

Një faktor i cilësisë së softuerit është një kërkesë jofunksionale për një program që zakonisht nuk përshkruhet në një kontratë me klientin, por megjithatë është një kërkesë e dëshirueshme që përmirëson cilësinë e programit.

Disa nga faktorët e cilësisë:

Kuptueshmëria Qëllimi i softuerit duhet të jetë i qartë nga vetë programi dhe nga dokumentacioni. plotësia Të gjitha pjesët e nevojshme të programit duhet të paraqiten dhe të zbatohen plotësisht. shkurtësi Nuk ka informacion të tepërt, dublikatë. Pjesët e përsëritura të kodit duhet të shndërrohen në një thirrje për një procedurë të zakonshme. E njëjta gjë vlen edhe për dokumentacionin. transportueshmëri Lehtësia e përshtatjes së programit në një mjedis të ndryshëm: një arkitekturë, platformë, sistem operativ tjetër ose version i tij. qëndrueshmëri Të njëjtat konventa, formate dhe konventa duhet të përdoren gjatë gjithë programit dhe dokumentacionit. mirëmbajtja Sa e vështirë është të ndryshosh një program për të përmbushur kërkesat e reja. Kjo kërkesë specifikon gjithashtu se programi duhet të jetë i dokumentuar mirë, jo shumë i turbullt dhe të ketë hapësirë për rritje në përdorimin e burimeve (memorie, procesor). testueshmëria Nëse programi ju lejon të kontrolloni karakteristikat e pranimit, nëse mbështetet aftësia për të matur performancën. lehtësia e përdorimit Thjeshtësia dhe lehtësia e përdorimit të programit. Kjo kërkesë vlen kryesisht për ndërfaqen e përdoruesit. besueshmëria mungesa e dështimeve dhe dështimeve në punën e programeve, si dhe lehtësia e rregullimit të defekteve dhe gabimeve: efikasiteti i strukturuar Sa racionalisht i trajton programi burimet (memoria, procesori) kur kryen detyrat e tij. sigurinë

Perspektiva e përdoruesit

Përveç një pamje teknike të cilësisë së softuerit, ekziston edhe një vlerësim i cilësisë nga këndvështrimi i përdoruesit. Termi "përdorshmëri" përdoret ndonjëherë për këtë aspekt të cilësisë. Është mjaft e vështirë për të marrë një rezultat të përdorshmërisë për një produkt të caktuar softuer. Pyetjet më të rëndësishme që ndikojnë në vlerësim janë:

A është ndërfaqja e përdoruesit intuitive?
Sa e lehtë është të kryhen operacione të thjeshta dhe të shpeshta?
Sa të lehta janë operacionet komplekse?
A prodhon programi mesazhe të qarta gabimi?
A sillet programi gjithmonë siç pritej?
A disponohet dokumentacioni dhe sa i plotë është ai?
A është ndërfaqja e përdoruesit vetë-përshkruese/vetë-dokumentuese?
A janë gjithmonë të pranueshme vonesat e përgjigjes së programit?

Shiko gjithashtu

Lidhjet

Zhvillimi i Softuerit
I njohur shifrat
Procesi
Konceptet
Drejtimet
Modelet zhvillimin
Modele të tjera
Të tjera

Fondacioni Wikimedia. 2010 .

Shihni se çfarë është "Cilësia e softuerit" në fjalorë të tjerë:

Aftësia e një produkti softuer për të vërtetuar specifikimet e tij, me kusht që specifikimi të jetë i orientuar drejt karakteristikave që dëshiron përdoruesi. Shihni gjithashtu: Cilësia e softuerit Software Financial ... ... Fjalori financiar

Kur Grace Hopper po punonte me kompjuterin Harvard Mark II në Universitetin e Harvardit, kolegët e saj zbuluan këtë nishan të mbërthyer në stafetë dhe kështu ndërhynte në funksionimin e pajisjes, pas së cilës ajo vuri në dukje se ata po "debugonin" (debugonin) sistemin. ... ... Wikipedia

Zhvillimi i softuerit Procesi i zhvillimit të softuerit Hapat e procesit Analiza e projektimit Dokument programimi ... Wikipedia

Zhvillimi i softuerit (inxhinieria softuerike angleze, zhvillimi i softuerit) është një lloj aktiviteti (profesioni) dhe një proces që synon krijimin dhe ruajtjen e shëndetit, cilësisë dhe besueshmërisë së softuerit duke përdorur ... Wikipedia

- "Kriza softuerike" është një term i përdorur dikur në shkencën kompjuterike për të përshkruar pasojat e rritjes së shpejtë të fuqisë kompjuterike të kompjuterëve dhe kompleksitetin e problemeve që mund të zgjidhen me ndihmën e tyre. Në thelb, kjo është ... ... Wikipedia

Airbus A 380 i ri përdor mjaft softuer për të krijuar një kabinë moderne. Metoda e inxhinierisë së softuerit bëri të mundur krijimin e softuerit të avionëve të përshkruar nga miliona rreshta ... Wikipedia

Aftësia e softuerit për të ekzekutuar në platforma të ndryshme harduerike ose nën sisteme të ndryshme operative. Sinonimet: Transportueshmëria e softuerit Shihni gjithashtu: Cilësia e softuerit Sisteme të hapura… … Fjalori financiar

Karakteristikat e një produkti softuer që: lejojnë minimizimin e përpjekjeve të përdoruesve në përgatitjen e të dhënave fillestare, përdorimin e produktit softuer dhe vlerësimin e rezultateve të marra, dhe gjithashtu lejojnë të ngjallin emocione pozitive ... ... Fjalori financiar

Karakteristikat e një produkti softuerik që lejojnë minimizimin e përpjekjeve për të bërë ndryshime në të: për të eliminuar gabimet; ose të modifikohet për të përmbushur nevojat në ndryshim të përdoruesve. Shihni gjithashtu: Cilësia e softuerit ... ... Fjalori financiar

Aftësia e një produkti softuerik për të kryer një sërë funksionesh: të përcaktuara në përshkrimin e tij të jashtëm; dhe të kënaqë nevojat e specifikuara ose të nënkuptuara të përdoruesve. Sinonimet: ndërveprueshmëria e softuerit Shihni gjithashtu: Cilësia… … Fjalori financiar

libra

Perfect Code: A Practical Guide to Software Development, McConnell S. Për më shumë se 10 vjet, botimi i parë i këtij libri është konsideruar si një nga udhëzuesit më të mirë praktik të programimit. Ky libër tani është përditësuar plotësisht për të pasqyruar tendencat dhe teknologjitë aktuale...

Qasje ndaj cilësisë së softuerit

Le të klasifikojmë qasje të ndryshme ndaj cilësisë së softuerit duke përdorur dy dimensione.

Dimensioni i parë është i orientuar nga produkti ose procesi. Për të përmirësuar cilësinë e softuerit, mund të përqendroheni në cilësinë e vetë produktit, për shembull, duke e bërë atë më miqësor për përdoruesit. Një qasje alternative është përmirësimi i procesit të zhvillimit, duke supozuar se sa më i mirë të jetë procesi, aq më i mirë është cilësia e softuerit.

Dimensioni i dytë lidhet ose me konformitetin ose me përmirësimin. Pajtueshmëria kuptohet si pajtueshmëri me një standard të caktuar. Përmirësimi synon të kalojë drejt metodave dhe praktikave më të mira për të përmirësuar cilësinë.

ISO 9126 është një standard i cilësisë së produktit që përcakton atributet dhe karakteristikat e cilësisë, duke përfshirë masat për të përcaktuar sasinë e këtyre karakteristikave;

"përmirësimi i praktikës", për shembull, është përmirësimi i menaxhimit të konfigurimit të softuerit, inspektimeve, testimeve etj.;

ISO 9000 është një grup standardesh që deklarojnë kërkesat për sistemet e cilësisë. Nga pikëpamja e zhvillimit të softuerit, "Udhëzimet për aplikimin e ISO 9001 në zhvillimin, shpërndarjen dhe mirëmbajtjen e softuerit" janë më të dobishmet;

Metodat për përmirësimin e procesit të zhvillimit të softuerit ofrojnë disa shkallë nivelesh dhe kërkesash përputhshmërie, sipas të cilave mund të përcaktohet vendi i një kompanie kompjuterike në këtë shkallë. Dy metodat më të njohura dhe më të njohura janë:

Modeli i pjekurisë së procesit të zhvillimit të softuerit - Modeli i maturimit të aftësive për softuer (CMM), i propozuar nga Instituti i Inxhinierisë së Softuerit (SEI);

identifikimi i mundësive dhe përmirësimi i procesit të zhvillimit të softuerit. ISO/IEC 15504 Përmirësimi i procesit të softuerit dhe përcaktimi i aftësisë (SPICE).

Dy supozime kryesore qëndrojnë në themel të arritjes së cilësisë.

Cilësia fillon me plotësimin e nevojave të zhvilluesve.
Cilësia vërtetohet nga kënaqësia e përdoruesit.

Qasjet për arritjen e cilësisë janë si më poshtë:

cilësia arrihet me ndihmën e zhvilluesve të kualifikuar, respektimin e saktë të proceseve dhe qasjet e suksesshme teknologjike;
cilësia arrihet duke kuptuar plotësisht të gjitha veprimet dhe ndryshimet. Asnjë rresht i vetëm në program nuk duhet të shtohet apo ndryshohet pa kuptuar plotësisht se çfarë, pse dhe si po bëhet;
cilësia arrihet me testim të plotë të programit përpara se ai të jetë i disponueshëm për përdoruesit;
arritja e cilësisë duhet të planifikohet;
Arritja e cilësisë është përgjegjësi e çdo zhvilluesi.

Karakteristikat e cilësisë së softuerit

Aktualisht, nuk ka kritere të pranuara përgjithësisht për cilësinë e softuerit.

ISO 9000-3, pika 6.4.1

Përkufizimi klasik i cilësisë është se produkti softuer i zhvilluar konfirmon specifikimin e tij, ndërsa specifikimi duhet të fokusohet në karakteristikat që klienti dëshiron të marrë.

Standardet moderne sqarojnë konceptin e cilësisë, duke prezantuar një sërë veçorish dhe karakteristikash që ndikojnë në aftësinë e tij për të përmbushur nevojat e specifikuara të përdoruesve. Le të rendisim një numër karakteristikash të tilla [Zhogolev 1996].

Funksionaliteti (përshtatshmëria, saktësia, ndërveprueshmëria, qëndrueshmëria, siguria). Funksionaliteti është aftësia e një produkti softuer për të kryer një sërë funksionesh që plotësojnë nevojat e specifikuara ose të nënkuptuara të përdoruesve. Grupi i funksioneve të tilla përcaktohet në përshkrimin e jashtëm të produktit softuer.

Besueshmëria (plotësia, qëndrueshmëria, rikuperimi).

Komoditeti (kuptueshmëria, efikasiteti i zhvillimit, ergonomia). Komoditeti janë karakteristikat e një produkti softuer që minimizon përpjekjet e përdoruesit në përgatitjen e të dhënave fillestare, përdorimin e produktit softuer dhe vlerësimin e rezultateve të marra, si dhe evokimin e emocioneve pozitive për një përdorues specifik ose të nënkuptuar.

Efikasiteti (përsa i përket kohës dhe burimeve). Efikasiteti është raporti i nivelit të shërbimeve të ofruara nga produkti softuer ndaj përdoruesit në kushte të caktuara, me sasinë e burimeve të përdorura.

Mirëmbajtja (lehtësia e analizës, ndryshueshmëria, qëndrueshmëria, verifikueshmëria). Mirëmbajtja janë karakteristikat e një produkti softuer që minimizon përpjekjen për të bërë ndryshime për të eliminuar gabimet në të dhe për ta modifikuar atë në përputhje me nevojat në ndryshim të përdoruesit.

Transportueshmëria (përshtatshmëria, fleksibiliteti i instalimit, pajtueshmëria me standardet dhe rregulloret, këmbyeshmëria). Transportueshmëria është aftësia e një produkti softuer për t'u bartur nga një mjedis në tjetrin, veçanërisht nga një arkitekturë harduerike në tjetrën.

Cilësi e mirë (organizim racional, mendim). Le të hedhim një vështrim më të afërt në dy karakteristikat më interesante.

Besueshmëria është aftësia e një programi për të kryer funksione të caktuara pa dështuar në kushte të caktuara për një periudhë të caktuar kohe me një probabilitet mjaft të lartë. Një produkt softuer i besueshëm nuk përjashton praninë e gabimeve në të. Është e rëndësishme këtu që gabimet në zbatimin praktik në kushte të caktuara shfaqen mjaft rrallë. Shkalla e besueshmërisë karakterizohet nga probabiliteti që një produkt softuer të funksionojë pa dështim për një periudhë të caktuar kohe.

Ekzistojnë metodat e mëposhtme për të siguruar besueshmërinë:

paralajmërim për gabime;
vetë-zbulimi i gabimit;
vetë-korrigjimi i gabimeve;
sigurimi i tolerancës ndaj gabimeve.

E mira e programit qëndron në faktin se programi është i organizuar në mënyrë të arsyeshme dhe racionale, me një organizim mjaftueshëm të menduar të flukseve të kontrollit dhe flukseve të informacionit dhe nuk është shumë i ndërlikuar. Koncepti i faktorit të cilësisë u prezantua nga Pottosin [Pottosin 1997] për të vlerësuar meritat e brendshme të një programi nga një këndvështrim teknik. Pottosin prezanton katër klasa të kritereve të cilësisë për programet.

Kriteret sasiore që lidhen me mënyra të ndryshme të vlerësimit (metrikave) të kompleksitetit të programeve. Le të tregojmë shembuj të karakteristikave numerike.

Masat Halsted [Halsted 1981], të cilat përfshijnë një numër formulash që vlerësojnë gjatësinë, vëllimin, nivelin dhe përmbajtjen intelektuale të programeve.

Vlerësimi i kompleksitetit të grafikut të kontrollit të programit. Një fragment programi mund të vlerësohet nga numri ciklomatik i grafikut të tij të kontrollit, i cili është i barabartë me m - n + 2, ku m është numri i harqeve, an është numri i kulmeve të grafikut të kontrollit. Besohet se numri ciklomatik nuk duhet të kalojë 10.

Vlerësimi i ndarjes modulare të programit. Një vlerësim i tillë duhet të përbëhet nga shumë kritere. Për shembull, kompleksiteti i një moduli vlerësohet nga tërësia e kompleksitetit të procedurave të përcaktuara në të dhe kompleksiteti i lidhjeve të modulit me module të tjera për importimin dhe eksportimin e entiteteve të përcaktuara.

Kriteret gjenetike që lidhen me origjinën e programit dhe disiplinën e krijimit të tij.

Kriteret strukturore që lidhen me vlerësimin e organizimit të menaxhimit në program dhe pasqyrimin e organizimit të menaxhimit në tekstin e programit.

Kriteret pragmatike që lidhen me vlerësimin se si teksti i programit korrespondon me qëllimin e programit. Është formuluar një listë eksesesh që nuk duhet të jenë në programe të mira, për shembull, teprica llogaritëse.

Vlerësimi i cilësisë së procesit të zhvillimit

Duke kërkuar efikasitet dhe fleksibilitet nga i njëjti program -

është si të kërkosh një grua simpatike dhe modeste.

Me sa duket, duhet të ndalemi në një nga dy gjërat.

D. Weinberg

Në fillim të këtij seksioni, ne vumë re se ekzistojnë dy qasje që mund të përdoren për të vlerësuar cilësinë e një produkti softuer.

Vlerësoni cilësinë e produktit përfundimtar.
Vlerësoni cilësinë e procesit të zhvillimit.

Ju mund të vlerësoni cilësinë e produktit përfundimtar duke testuar dhe funksionuar. Për këtë duhet të ndahet kohë pas përfundimit të punës kryesore në program. Por qasja e dytë duhet të bëhet pjesë e strategjisë afatgjatë të kompanisë.

Modeli i maturimit të procesit të zhvillimit të softuerit

Modeli përcakton pesë nivele të pjekurisë organizative (http://www.sei.cmu.edu/cmm).

Niveli i parë. Në këtë nivel, procesi i zhvillimit karakterizohet nga mungesa virtuale e proceseve të menaxhimit. Suksesi i projektit varet nga përpjekjet individuale, cilësitë personale dhe madje edhe heroizmi i pjesëmarrësve të projektit.

Niveli i përsëritshëm. Në këtë nivel maturimi, kompania duhet të ketë në vend proceset bazë të menaxhimit për të gjurmuar koston, orarin e projektit dhe funksionalitetin. Niveli karakterizohet nga fakti se menaxhimi i projektit bazohet në përvojën e akumuluar dhe sukseset e arritura më parë do të përsëriten në aplikacione të ngjashme.

Niveli i caktuar. Procesi i zhvillimit të softuerit (si në nivelin e aktiviteteve menaxheriale ashtu edhe në atë inxhinierike) është i dokumentuar, i standardizuar dhe i integruar në nivelin e të gjithë organizatës. Procesi nuk varet nga cilësitë individuale të zhvilluesve individualë dhe nuk mund të rrëshqasë në nivele më të ulëta në situata krize.

niveli i menaxhuar. Kompania vendos tregues të detajuar sasior për procesin e zhvillimit dhe cilësinë e produktit. Si procesi i zhvillimit ashtu edhe produktet janë të kuptueshme dhe të kontrollueshme.

niveli i optimizimit. Përmirësimi i vazhdueshëm i procesit të zhvillimit bazuar në analizën e rezultateve aktuale të procesit dhe aplikimin e ideve dhe teknologjive inovative.

Identifikimi i mundësive dhe përmirësimi i procesit të zhvillimit të softuerit

Ky model është shumë afër modelit të pjekurisë, por nivelet e aftësisë mund të aplikohen jo vetëm për organizatën në tërësi, por edhe për proceset individuale. Modelet e këtij lloji shpesh quhen të vazhdueshme. Në modelet e vazhdueshme, një proces mund të jetë në një nivel të ulët maturimi dhe një tjetër në një nivel të lartë maturimi. Standardi përcakton gjashtë nivele të pjekurisë së procesit.

Niveli 0: Procesi nuk po funksionon.

Niveli 1. Procesi në vazhdim.

Niveli 2. Procesi i menaxhuar.

Niveli 3. Procesi i vendosur.

Niveli 4. Procesi i parashikueshëm.

Niveli 5. Procesi i optimizimit.

Gjatë vlerësimit dhe përmirësimit të cilësisë së proceseve, kryhen detyrat [Terekhov, Tunon 1999] të përshkruara më poshtë.

Krahasimi i procesit të zhvillimit të softuerit që ekziston në një organizatë të caktuar me modelin e përshkruar në standard. Analiza e rezultateve bën të mundur përcaktimin e pikave të forta dhe të dobëta të procesit, rreziqet e brendshme të tij.

Vlerësimi i mundësisë së përmirësimit të këtij procesi bazuar në identifikimin e mundësive aktuale.

Zbatimi teknik i detyrave të vendosura në bazë të qëllimeve të formuluara për përmirësimin e procesit. Pas kësaj, i gjithë cikli i punës fillon përsëri.

Për rolin e Ministrisë së Mbrojtjes

Vini re se, historikisht, u krijuan modele për vlerësimin e cilësisë së procesit të zhvillimit për të marrë procedura të arsyeshme vlerësimi dhe zhvillimin e mëvonshëm të proceseve teknologjike në ato organizata që pretendojnë të marrin urdhra për zhvillimin e projekteve me rëndësi të mbrojtjes. Modelet janë të zbatueshme për kompanitë që zhvillojnë sisteme komplekse dhe në kohë reale. Këto janë sisteme me një cikël të gjatë jete, ku defektet e softuerit mund të jenë kritike.

Softuer "mjaft i mirë".

Dje në Seattle pasi Bill Gates përmendi lëshimin e versionit beta

Programi i ri i Microsoft-it u godit nga një tërmet.

Përdoruesit po presin me tmerr njoftimin e publikimit të versionit përfundimtar të produktit.

Softueri mjaft i mirë është promovuar nga Edward Yordon [Yordon 2001]. Theksojmë se ai e zbaton këtë koncept për "projektet e këqija" që janë të kufizuara nga kufizime të rënda në kohë, buxhet dhe burime njerëzore (shih seksionin 1.6). Në shumicën e projekteve të pashpresë, klienti mund të jetë i kënaqur me një sistem që është mjaft i lirë, performon mjaft mirë, ka veçoritë e duhura, është mjaftueshëm i qëndrueshëm dhe do të jetë gati mjaft shpejt. Në fakt, këto karakteristika mund të konsiderohen si përkufizimi i softuerit "mjaft të mirë".

Rezulton se edhe softueri "mjaft i mirë" është i vështirë për t'u krijuar. Këtu është një pjesë e grupit të arsyeve që e shpjegojnë këtë [Yordon 2001].

Shpeshherë cilësia kërkohet të përcaktohet vetëm në terma të defekteve (gabimeve). Nga këndvështrimi i përdoruesit, aspekte të tilla si gatishmëria për një datë të caktuar janë po aq të rëndësishme.

Supozohet se një numër i vogël gabimesh është i barabartë me një cilësi më të mirë, dhe përdoruesi preferon këtë cilësi. Megjithatë, ndonjëherë përdoruesi është i gatshëm të bëjë kompromis dhe të durojë disa gabime në këmbim të punës më të shpejtë.

Injorimi i faktorëve të tillë si morali i ekipit të zhvillimit dhe kushtet e përshtatshme të punës.

James Bach rendit parakushtet e mëposhtme për krijimin e softuerit "mjaft të mirë":

strategjia utilitare - arti i analizës sasiore dhe maksimizimi i fitimit neto në situata të pasigurta;
strategjia evolucionare - konsiderohet jo vetëm në lidhje me ciklin jetësor të projektit, por edhe në lidhje me njerëzit, proceset dhe burimet;
skuadrat heroike nuk janë programues të fuqishëm të shkëlqyer, por specialistë të zakonshëm të aftë të aftë për bashkëpunim efektiv;
infrastruktura dinamike - e kundërta e burokracisë dhe dominimit të politikës;
proceset dinamike - procese që mbështesin punën në një mjedis evolucionar.

Fatkeqësisht, softueri "mjaft i mirë" rrallë është mjaft i mirë. Niklaus Wirth vëren se kjo është "pasojë e shfaqjes së trishtuar të shpirtit të kohës sonë, në të cilën krenaria personale për punën e dikujt zhduket". Sipas tij, "nuk mund të pritet punë cilësore nëse nuk i jepet plotësisht asaj, nëse nuk ka kënaqësi personale, për më tepër, kënaqësi prej saj".

Një vëzhgim interesant se disa kompani tentojnë të ulin nivelin intelektual të përdoruesve të produkteve të tyre është bërë nga shumë programues. Është jashtëzakonisht fitimprurëse për kompanitë që të merren me njerëz, aftësitë teknike të të cilëve nuk lejojnë të përcaktojnë aspektet reale (për shembull, cilësia, kompleksiteti, vlera) e produktit softuer. Duke u fshehur pas "thjeshtimit" të punës dhe rritjes së disponueshmërisë së kompjuterëve për përdoruesit, kompanitë vazhdimisht e mbingarkojnë dhe e ndërlikojnë softuerin në atë mënyrë që përdoruesi ta ketë jashtëzakonisht të vështirë të kuptojë se si funksionon realisht dhe të bëhet profesionist.

Standardizimi i teknologjisë së informacionit

Një standard është një përkufizim i pranuar përgjithësisht i një komponenti hardware ose softuerësh që rezulton nga një marrëveshje. Një profil është një grup standardesh ligjore dhe/ose faktike të fokusuara në një detyrë specifike [Kozlov 1999].

Standardet mund të klasifikohen si më poshtë:

sipas llojit të cilësimit të kërkesës:
vendosja e kërkesave për objektin;
vendosjen e kërkesave për procesin;
sipas shkallës:
ndërkombëtare;
shteti;
industria;
ndërmarrjet;
sipas shkallës së regjistrimit ligjor:
pranuar ligjërisht;
në fakt funksionon.

Procesi i standardizimit të teknologjisë së informacionit mbështetet nga tre grupe kryesore të organizatave. Organizatat ndërkombëtare që janë pjesë e strukturës së OKB-së. Organizata Ndërkombëtare për Standardizim (ISO) është një organizatë ndërkombëtare për standardizimin.

Rreth ISO

Në vitin 1947, përfaqësuesit e 25 vendeve vendosën të krijojnë një organizatë, detyra kryesore e së cilës do të ishte koordinimi i zhvillimit dhe unifikimit të standardeve ndërkombëtare. Organizata e re u quajt Organizata Ndërkombëtare për Standardizim (ISO). Mospërputhja midis emrit të plotë dhe shkurtesës është për faktin se "ISO" është një parashtesë greke që do të thotë "e barabartë".

Komisioni Ndërkombëtar Elektroteknik (IEC) - Komisioni Ndërkombëtar Elektroteknik.

Unioni Ndërkombëtar i Telekomunikacionit-Telecommunications (ITU-T) - Unioni ndërkombëtar i telekomunikacionit - telekomunikacioni. Deri në vitin 1993, kjo organizatë quhej Komiteti Konsultativ Ndërkombëtar i Telegrafit dhe Telefonisë - një komitet ndërkombëtar këshillues për telefoninë dhe telegrafinë.

Organizatat industriale profesionale ose administrative.

Instituti i Inxhinierëve Elektrikë dhe Elektronikë (IEEE) - Instituti i Inxhinierëve Elektrikë dhe Elektronikë.

Bordi i Aktiviteteve në Internet (IAB) është bordi drejtues për aktivitetet e internetit.

konsorciume industriale.

Grupi i Menaxhimit të Objekteve (OMG) - grupi i menaxhimit të objekteve.

X/Open është një konsorcium i organizuar nga një grup shitësish kompjuterësh.

Open Software Foundation (OSF) është një fondacion me burim të hapur.

Në vitin 1987, ISO dhe IEC shkrinë aktivitetet e tyre në fushën e standardizimit të teknologjisë së informacionit dhe krijuan një organ të vetëm - Komiteti i Përbashkët Teknik 1 (JTC1) - komiteti i përbashkët teknik 1. Ky komitet është krijuar për të formuar një sistem standardesh bazë në fushën e teknologjia e informacionit.

Problemi kryesor në menaxhimin e cilësisë është fakti se përkufizimi i cilësisë është shumë i paqartë dhe i paqartë. Kjo për shkak se termi cilësi zakonisht keqkuptohet. Ka disa arsye për këtë konfuzion...

Le të përpiqemi t'u përgjigjemi pyetjeve:

Pamje popullore e cilësisë
konkluzionet

Çfarë është cilësia e softuerit?

Në numrin tonë të parë, ne do të përpiqemi të përcaktojmë termat cilësi dhe cilësi të softuerit.

Problemi kryesor në menaxhimin e cilësisë është fakti se përkufizimi i cilësisë është shumë i paqartë dhe i paqartë. Kjo për shkak se termi cilësi zakonisht keqkuptohet. Ky konfuzion mund të jetë për shkak të disa arsyeve.

Së pari, cilësia nuk është një ide apo koncept i vetëm, por një koncept shumëdimensional dhe i larmishëm.

Së dyti, për çdo koncept dhe përkufizim ka disa nivele abstraksioni, për shembull, kur njerëzit flasin për cilësinë, një pjesë e kupton këtë si shumë të gjerë dhe të paqartë, ndërsa tjetra mund t'i referohet një përkufizimi dhe kuptimi specifik.

Së treti, termi cilësi është një pjesë integrale e komunikimit tonë të përditshëm, por përdorimi i zakonshëm dhe profesional mund të jetë shumë i ndryshëm.

Pamje popullore e cilësisë

Mendimi i pranuar përgjithësisht për cilësinë është se ajo është diçka e paprekshme dhe "e paprekshme" - mund të ketë mosmarrëveshje dhe diskutime për të, mund të kritikohet dhe lavdërohet, por është e pamundur të peshohet dhe matet cilësia. Shprehje të tilla si "cilësi e mirë" dhe "cilësi e keqe" shërbejnë si një shembull i qartë se si njerëzit flasin për diçka të paqartë për ta, diçka që ata nuk mund ta karakterizojnë dhe përcaktojnë qartë. Kjo pikëpamje pasqyron faktin që njerëzit e perceptojnë dhe interpretojnë cilësinë ndryshe. Kuptohet që cilësia nuk mund të kontrollohet dhe menaxhohet dhe aq më tepër nuk mund të matet. Kjo pikëpamje është në kontrast të fortë me qasjen profesionale ndaj menaxhimit të cilësisë - cilësia është një vlerë e mirëpërcaktuar që mund të matet dhe kontrollohet, mund të menaxhohet dhe përmirësohet.

Një tjetër mendim popullor është se cilësia është e lidhur pazgjidhshmërisht me luksin, klasin e parë dhe shijen e mirë. Një produkt i shtrenjtë, i menduar mirë dhe teknikisht më i sofistikuar shihet si një garanci e cilësisë së lartë sesa alternativat më të lira. Sipas kësaj logjike, Cadillac është një makinë cilësore, por Chevrolet jo, pavarësisht nga besueshmëria dhe numri i avarive; ose një sistem HI-FI është një sistem cilësor, por një radio e zakonshme jo. Sipas kësaj qasjeje, cilësia kufizohet në një klasë të caktuar produktesh të shtrenjta me funksionalitet të ndërlikuar dhe produkte klasore. E thënë thjesht, nuk ka gjasa që një produkt i lirë të klasifikohet si një produkt cilësor.

Qasje profesionale ndaj cilësisë

Fatkeqësisht, një paraqitje e tillë e paqartë dhe e paqartë nuk mund të përdoret për të përmirësuar proceset e zhvillimit të softuerit. Prandaj, është e nevojshme të jepet një përkufizim i qartë dhe i lehtë për t'u punuar. Në vitin 1979 Crosby e përkufizoi cilësinë si "përputhje me kërkesat", ndërsa Juran dhe Gryna në 1970 e përkufizuan cilësinë si "përshtatshmëri për përdorim". Këto dy përkufizime janë të lidhura ngushtë dhe pajtohen plotësisht, siç do të shohim më vonë.

"Pajtueshmëria me kërkesat" sugjeron që kërkesat duhet të përcaktohen aq qartë sa nuk mund të keqkuptohen dhe interpretohen gabimisht. Më vonë, gjatë fazës së zhvillimit, bëhen matje të rregullta të produktit të zhvilluar për të përcaktuar pajtueshmërinë me kërkesat. Çdo mospërputhje duhet të konsiderohet si defekt - mungesë cilësie. Për shembull, një specifikim për një model specifik të radiostacionit mund të kërkojë aftësinë për të marrë një frekuencë specifike të valëve të radios në një distancë prej më shumë se 30 kilometra nga burimi i transmetimit. Nëse radiostacioni nuk është në gjendje të përmbushë këtë kërkesë, ai nuk i plotëson kërkesat e cilësisë dhe duhet të njihet si i papërdorshëm dhe i cilësisë së dobët. Bazuar në të njëjtat parime, nëse Cadillac plotëson të gjitha kërkesat për makinat Cadillac, atëherë kjo është një makinë cilësore. Nëse Chevrolet plotëson të gjitha kërkesat për makinat Chevrolet, atëherë kjo është gjithashtu një makinë cilësore. Këto dy makina mund të jenë krejtësisht të ndryshme në stil, shpejtësi dhe ekonomi, por nëse të dyja maten me grupet e tyre standarde, atëherë të dyja do të jenë makineri cilësore.

Përkufizimi "Përshtatshmëri për përdorim" merr parasysh kërkesat dhe pritshmëritë e përdoruesve fundorë të produktit, të cilët presin që produkti ose shërbimi i ofruar të jetë i përshtatshëm për nevojat e tyre. Megjithatë, përdorues të ndryshëm mund ta përdorin produktin në mënyra të ndryshme, që do të thotë se produkti duhet të ketë sa më shumë raste të ndryshme përdorimi. Sipas përkufizimit të Juran, çdo rast përdorimi është një karakteristikë e cilësisë dhe të gjitha ato mund të kategorizohen si parametra të përdorshmërisë.

Këto dy përkufizime të cilësisë (“përshtatja me kërkesat” dhe “përshtatshmëria për përdorim”) janë në thelb të njëjta. Dallimi është se opsioni "përshtatshmëri për përdorim" tregon rolin e rëndësishëm të kërkesave dhe pritshmërive të klientëve. Roli cilësor i klientit nuk mund të mbivlerësohet kurrë. Nga pikëpamja e klientit, cilësia e produktit që ai ka blerë përbëhet nga shumë faktorë të ndryshëm, si: çmimi, performanca, besueshmëria, etj.

Vetëm klienti juaj mund t'ju tregojë për cilësinë, sepse kjo është e vetmja gjë që ata blejnë vërtet. Klienti nuk e blen produktin. Ai blen garancinë tuaj se të gjitha pritjet e tij për produktin do të realizohen.

Guaspari "E di kur e shoh"

konkluzionet

Le të përpiqemi përsëri të përcaktojmë cilësinë nga këndvështrimi i klientit ose përdoruesit të produktit.

Cilësia është përshtatshmëri për përdorim. A bën ky produkt atë që kam nevojë, a ma lehtëson punën, a mund ta përdor ashtu siç dua.

Tani le të shohim këndvështrimin e zhvilluesit.

Cilësia është konformiteti me kërkesat e specifikuara dhe të mbledhura nëse ky produkt bën gjithçka që është e specifikuar në kërkesat.

Problemi është se kërkesat e specifikuara dhe të mbledhura zakonisht janë vetëm një pjesë e të gjitha kërkesave dhe pritjeve aktuale të klientit. Ku është përkufizimi i saktë i cilësisë?

Cilësia është përputhja me kërkesat reale, të qarta dhe të nënkuptuara. Shumë shpesh, kërkesat e nënkuptuara janë aq të dukshme për klientin ose përdoruesin, saqë ai as nuk supozon se ato janë të panjohura për zhvilluesit. Për shembull, le të kthehemi te makinat tona - klienti mund të përshkruajë në detaje kërkesat për dizajnin, parametrat e motorit, dizajnin e brendshëm, ngjyrën e trupit, por askund nuk tregojnë se gomat duhet të jenë të rrumbullakëta dhe xhami i përparmë duhet të jetë transparent.

Klienti do të jetë i kënaqur vetëm kur produkti i blerë plotëson plotësisht kërkesat e tij reale dhe jetike, të specifikuara dhe jo.

Cilësia e softuerit është shkalla në të cilën softueri ka një kombinim të dëshiruar të veçorive.

Cilësia e softuerit është një grup karakteristikash të softuerit që lidhen me aftësinë e tij për të kënaqur nevojat e deklaruara dhe të nënkuptuara.

Karakteristikat e cilësisë së softuerit

Funksionaliteti(Funksionaliteti) - përcaktohet nga aftësia e softuerit për të zgjidhur probleme që korrespondojnë me nevojat fikse dhe të pritshme të përdoruesit, në kushte të caktuara të përdorimit të softuerit. ato. kjo karakteristikë siguron që softueri të funksionojë siç duhet dhe saktë, të jetë i ndërveprueshëm, të jetë në përputhje me standardet e industrisë dhe të mbrohet nga aksesi i paautorizuar.

Besueshmëria(Besueshmëria) - aftësia e softuerit për të kryer detyrat e kërkuara në kushte të caktuara për një periudhë të caktuar kohe ose një numër të caktuar operacionesh. Karakteristikat e kësaj karakteristike janë tërësia dhe integriteti i të gjithë sistemit, aftësia për të rikuperuar në mënyrë të pavarur dhe të saktë nga dështimet, toleranca e gabimeve.

Komoditeti i përdorimit(Përdorshmëria) - aftësia për të kuptuar lehtësisht, studiuar, përdorur dhe softuer tërheqës për përdoruesin.

Efikasiteti(Efiçenca) - aftësia e softuerit për të siguruar nivelin e kërkuar të performancës në përputhje me burimet e alokuara, kohën dhe kushtet e tjera të specifikuara.

Lehtësia e mirëmbajtjes(Maintainability) - lehtësia me të cilën softueri mund të analizohet, testohet, ndryshohet për të rregulluar defektet, për të zbatuar kërkesa të reja, për të lehtësuar mirëmbajtjen e mëtejshme dhe për t'u përshtatur me mjedisin e përmendur.

Transportueshmëria(Portability) - karakterizon softuerin për sa i përket lehtësisë së transferimit nga një mjedis (softuer/hardware) në tjetrin.

Modeli i cilësisë së softuerit

Aktualisht më i zakonshmi dhe më i përdoruri modeli i cilësisë së softuerit me shtresa, paraqitur në grupin e standardeve ISO 9126. E theksuar në nivelin më të lartë 6 karakteristikat kryesore të cilësisë së softuerit, secila prej të cilave përcaktohet nga një grup atributesh që kanë metrikë përkatëse për vlerësimin e mëvonshëm ( shih fig. një).

Fig.1 - Modeli i cilësisë së softuerit (ISO 9126-1)

29. Karakteristikat e cilësisë së softuerit (gost).

GOST ISO 9126-93

Cilësia e softuerit mund të vlerësohet nga karakteristikat e mëposhtme:

4.1 Funksionaliteti(Funksionaliteti) Një grup atributesh që lidhen me natyrën e një grupi funksionesh dhe vetitë e tyre specifike. Funksionet janë ato që përmbushin nevojat e deklaruara ose të nënkuptuara: Shënime

1 Ky grup atributesh karakterizon atë që softueri bën për të kënaqur nevojat, ndërsa grupet e tjera kryesisht përshkruajnë kur dhe si bëhet.

4.2 Besueshmëria(Besueshmëria) Një grup atributesh që lidhen me aftësinë e softuerit për të ruajtur nivelin e tij të performancës në kushte të caktuara për një periudhë të caktuar kohe. Shënime 1 Softueri nuk konsumohet dhe nuk vjetërohet. Kufizimet e besueshmërisë vijnë nga gabimet në kërkesa, projektim dhe zbatim. Dështimet për shkak të këtyre gabimeve varen nga mënyra se si përdoret softueri dhe nga versionet e softuerit të zgjedhur më parë. SHËNIM 2 Në përkufizimin e ISO 8402, "besueshmëria" është "aftësia e një elementi për të kryer një funksion të kërkuar". Në këtë Standard Ndërkombëtar, aftësia është vetëm një nga karakteristikat e cilësisë së softuerit. Prandaj, përkufizimi i besueshmërisë është zgjeruar për të "ruajtur nivelin e performancës" në vend të "kryerjes së funksionit të kërkuar" (shih gjithashtu 3.4).

4.3 Prakticiteti(Përdorshmëria) Një grup atributesh që lidhen me sasinë e punës së kërkuar për përdorim dhe vlerësimin individual të një përdorimi të tillë nga një gamë e caktuar ose e synuar përdoruesish. Shënimi 1 i hyrjes: "Përdoruesit" mund të interpretohen si shumica e përdoruesve të drejtpërdrejtë të softuerit interaktiv. Gama e përdoruesve mund të përfshijë operatorët, përdoruesit përfundimtarë dhe përdoruesit indirekt në të cilët

të prekura nga ky softuer ose që varen nga përdorimi i tij. Përdorshmëria duhet të merret parasysh në të gjitha kushtet e operimit të përdoruesit që mund të ndikojnë në softuerin, duke përfshirë përgatitjen për përdorim dhe vlerësimin e rezultateve.

SHËNIM 2 Përdorueshmëria, e përcaktuar në këtë Standard Ndërkombëtar si një grup specifik i atributeve të produktit softuer, ndryshon nga përkufizimi i ergonomisë, ku karakteristika të tjera si efikasiteti dhe joefikasiteti konsiderohen si pjesë e përdorshmërisë.

4.4 Efikasiteti(Efiçenca) Një grup atributesh që lidhen me marrëdhënien midis nivelit të performancës së softuerit dhe sasisë së burimeve të përdorura në kushte të caktuara. SHËNIM Burimet mund të përfshijnë produkte të tjera softuerike, harduer, materiale (p.sh. letër printimi, disqe) dhe shërbime të personelit operativ, mirëmbajtjes ose mirëmbajtjes.

4.5 Mirëmbajtja(Mbajtueshmëria) Një grup atributesh që lidhen me sasinë e punës që kërkohet për të kryer ndryshime (modifikime) specifike. SHËNIM Modifikimi mund të përfshijë korrigjime, përmirësime ose përshtatje të softuerit ndaj ndryshimeve në mjedis, kërkesat dhe kushtet e funksionimit.

4.6 Lëvizshmëria(Portueshmëria) Një grup atributesh që lidhen me aftësinë e softuerit për t'u transferuar nga një mjedis në tjetrin. SHËNIM Mjedisi mund të përfshijë mjedisin organizativ, teknik ose softuerik.