Prije nešto više od godinu dana u časopisu Open Systems objavljen je moj članak pod naslovom “Principi upravljanja kvalitetom softvera”. Online verzija je dostupna ovdje: http://www.osp.ru/os/2008/06/5344965/. Prije objavljivanja, urednici su uvelike revidirali originalnu verziju članka, zbog čega je njegova veličina smanjena za faktor 2, a tekst, uključujući i naslov, također je uvelike revidiran. Sada sam odlučio objaviti autorovu ažuriranu verziju na svom blogu, uz neke male dodatke. Članak nije u blog formatu, već radije za naučnu ili obrazovnu publikaciju, pa mi oprostite.
Tema kvaliteta softvera se prilično često spominje u literaturi i člancima na ruskom jeziku, ali rijetko ide dalje od dugih govora ili razgovora o testiranju. Svrha ovog članka je pružiti holističko razumijevanje problema kvaliteta softvera i osnovnih principa upravljanja kvalitetom softvera. Članak definiše pojam kvaliteta softvera, opisuje pristup koji pojednostavljuje zadatak analize kvaliteta i daje kratak pregled poznatih metoda za poboljšanje kvaliteta.
I. Koncept kvaliteta softvera
Utvrđivanje kvaliteta softverskog proizvoda
Prema GOST R ISO 9000-2001, kvalitet je „stepen u kojem inherentne karakteristike (proizvoda) ispunjavaju zahteve“. Ovo je opća definicija. Ako se doslovno prenese na područje razvoja softvera, onda možda neće biti sasvim ispravno protumačeno. Činjenica je da je razvoj zahtjeva, u smislu da se ovaj termin podrazumijeva za oblast softvera, sastavni dio procesa razvoja softvera. Kvalitet zahtjeva za softverski proizvod (SP) direktno utiče na kvalitet samog softvera. Drugim riječima, ako su zahtjevi za softverski proizvod lošeg kvaliteta, onda će i sam proizvod, razvijen prema ovim zahtjevima, također biti lošeg kvaliteta, čak iu slučaju savršenog usklađenja.
Ako se riječ "zahtjevi" u GOST definiciji zamijeni riječima "projektni ciljevi" (ovdje pod projektom podrazumijevamo proces razvoja određenog softverskog proizvoda ili proširenja funkcionalnosti postojećeg proizvoda), onda sve dolazi na svoje mjesto. Dalje u članku ćemo pod kvalitetom softvera podrazumijevati sljedeće:
Napominjem da se ova definicija ne bavi pitanjima troškova. Ciljevi projekta razvoja softvera određeni su prvenstveno poslovnim ciljevima i postojećim ograničenjima.
Kriteriji kvaliteta PP
Kvalitet softvera je složen i višestruki koncept. Općenito, kvaliteta je funkcija sljedećih varijabli:
- Funkcionalnost (koliko je softver koristan za korisnika);
- Kvaliteta korisničkog sučelja (lakoća korištenja, lakoća učenja);
- Pouzdanost (bez grešaka u softveru, otpornost na kvarove);
- Produktivnost, potrošnja resursa, ekološki zahtjevi;
- Kvalitet informacione podrške (dokumentacija);
- Održivost (kvalitet arhitekture i koda, interni kvalitet);
- + možda drugi kriterijumi.
Druge opcije za listu kriterija kvalitete mogu se naći, na primjer, u,. Razvojna kompanija definiše (treba da definiše) svoje standarde kvaliteta za svaki kriterijum za svaki softverski projekat. Prilikom ocjenjivanja kvaliteta potrebno je moći kvantificirati svaki od kriterija.
Utjecaj aktivnosti životnog ciklusa na kvalitet softvera
Pogledajmo tipične aktivnosti u životnom ciklusu softverskog projekta i njihov uticaj na gore navedene kriterijume kvaliteta. U tabeli ispod, simbol * znači da data aktivnost (red) jasno utiče na dati kriterijum kvaliteta (kolona):
Glavna stvar na koju bih ovdje skrenuo pažnju je sljedeće: na kvalitetu finalnog proizvoda utiču sve faze i aktivnosti projekta, bez izuzetka, od najranijih do najnovijih. Dakle, koliko dobro i efikasno radimo u svakoj fazi projekta (a ne samo, na primjer, u fazi testiranja) ovisi o tome koliko će proizvod koji se razvija biti kvalitetan. Ili drugim riječima, kvalitet procesa razvoja određuje kvalitet proizvoda koji se razvija, tj. Kvalitet proizvoda je neodvojiv od kvaliteta procesa, a da bi se poboljšao kvalitet softvera potrebno je poboljšati kvalitet procesa razvoja ovog softvera.
Generalizirani koncept defekta
Bilo bi zgodno uvesti i koristiti određeni generalizovani kriterijum kvaliteta za analizu kvaliteta umesto nekoliko izolovanih kriterijuma. Ovaj kriterij je generalizirani koncept defekta:
Defekti se mogu klasificirati, na primjer, prema sljedećim parametrima:
Vrsta defekta (određena razvojnom fazom ili aktivnošću u kojoj je uveden);
Kritičnost defekta (koliko je kritično njegovo prisustvo u softveru);
Prioritet kvara (koliko je važno popraviti ga);
Složenost kvara (koliko je radno intenzivno da se popravi);
Sa takvim generalizovanim inverznim indikatorom kvaliteta postaje lakše proceniti i analizirati kvalitet softvera koji se razvija, kao i kvalitet našeg razvojnog procesa uopšte. Možemo prebrojati broj nedostataka ili zbir njihovih težina (po nekom parametru), možemo procijeniti gustinu defekata po jedinici volumena proizvoda, analizirati koje faze procesa su za nas najproblematičnije itd. Sada borba za kvalitet nije ništa drugo do borba protiv nedostataka.
II. Upravljanje kvalitetom softverskih proizvoda
Tradicionalni pristup kvaliteti softverskih proizvoda
Nakon što smo uveli generalizovani koncept defekta, možemo nacrtati graf koji prikazuje promenu broja defekata u projektu tokom vremena (slika 1). Radi jednostavnosti, razmotrimo vodopadni model životnog ciklusa projekta. U tradicionalnom pristupu kvalitetu PCB-a, gdje je naglasak na temeljnom testiranju, ovaj grafikon bi mogao izgledati ovako.
Rice. 1. Promjena broja nedostataka u projektu tokom vremena sa tradicionalnim pristupom upravljanju kvalitetom i sa vodopadnim životnim ciklusom.
Ovdje gornja crvena linija prikazuje broj defekata uvedenih u trenutnom trenutku (treba pojasniti da je ova linija zamišljena, jer nećemo moći precizno izbrojati ukupan broj nedostataka dok ih sve ne pronađemo). Donja zelena linija prikazuje broj otkrivenih i ispravljenih nedostataka u trenutnom trenutku (ovdje pretpostavljamo da se nedostaci ispravljaju gotovo odmah nakon što su pronađeni). Razlika između crvene i zelene linije u svakom trenutku prikazuje broj trenutno prisutnih kvarova. Najviše nas zanima kolika će biti ta razlika na kraju projekta. Što je manji, to je bolji kvalitet našeg proizvoda. Iz perspektive kvaliteta, životni ciklus na ovoj slici je predstavljen kao nadmetanje između procesa uvođenja i ispravljanja nedostataka.
Efikasnost pronalaženja kvarova
Razmotrimo jednu od faza usmjerenih na pronalaženje i ispravljanje nedostataka, na primjer, fazu testiranja sistema. U ovoj fazi se otkrije određeni broj pronađenih defekata D, dok u isto vrijeme određeni broj defekata ostaje neotkriven na kraju D propuštene faze (slika 2). Ukupan broj defekata koji su prošli kroz fazu će biti jednak D pronađeno + D propušteno.
Rice. 2. Promjena broja kvarova tokom jedne faze.
Nazovimo omjer pronađenih kvarova i njihovog ukupnog broja, izražen kao postotak, efikasnost pretraživanja kvarova (EDE%):
| EPD% = . |
Učinkovitost detekcije defekata može se razmatrati kako za pojedinačne faze i aktivnosti, tako i za cijeli životni ciklus razvoja. Istovremeno, efikasnost pojedinih faza određuje efikasnost za ceo životni ciklus. Svaka faza traženja nedostataka može se smatrati svojevrsnim filterom koji zadržava određeni dio kvarova, a cijeli životni ciklus kao sistem filtera. Ako u ranim fazama životnog ciklusa postoje loši filteri koji prolaze kroz mnoge nedostatke, onda se ti nedostaci akumuliraju, a da bismo ih dobro filtrirali, na kraju životnog ciklusa (faza testiranja) trebat će nam vrlo dobar filter.
Troškovi otklanjanja kvarova
Nedostaci ne samo da imaju tendenciju da se akumuliraju tokom vremena ako se ne preduzmu rane mjere za njihovo uklanjanje. Ali takođe je dobro poznata činjenica da što duže postoji nedostatak u projektu, to je skuplje njegovo otklanjanje (tj. radno intenzivnije), a zavisnost je često eksponencijalna. Za model životnog ciklusa vodopada, ova zavisnost je dobro ilustrirana sljedećim grafikonom (slika 3).
Rice. 3. Promjena cijene otklanjanja kvarova tokom vremena (životni ciklus vodopada).
Za iterativni model životnog ciklusa, slika će biti slična (slika 4), samo će se oznake promijeniti, a razmjer Y osi će se promijeniti za različite vrste defekata (na primjer, za zahtjeve i nedostatke dizajna, skala će biti veći nego za defekte kodiranja).
Rice. 4. Promjena cijene otklanjanja nedostataka tokom vremena (iterativni životni ciklus).
Integrisani pristup upravljanju kvalitetom
Stoga se ispostavlja da oslanjanje samo na samo testiranje, čak i ako je vrlo temeljito, ne može riješiti problem kvalitete. Ako ne preduzmete nikakve mjere za suzbijanje nedostataka do faze testiranja, tada do trenutka kada testiranje počne, projekt je možda akumulirao toliko nedostataka da će njihovo uklanjanje biti nemoguć zadatak.
Stoga se nedostaci moraju stalno tražiti i ispravljati, tokom cijelog životnog ciklusa projekta, počevši od najranijih faza, a ne samo na kraju tokom faze testiranja. Grubo govoreći, na kraju projekta u fazi testiranja prekasno je tražiti nedostatke: ako ih se nakupilo puno, onda nikakvo testiranje neće pomoći da se nekvalitetni proizvod pretvori u visokokvalitetan.
Drugi pristup, koji se može i treba primjenjivati paralelno, je prevencija ili izbjegavanje nedostataka , , .
Razmotrimo kako se grafik broja nedostataka u odnosu na vrijeme mijenja kada se primjenjuje integrirani pristup upravljanju kvalitetom (slika 5). Korištenje metoda detekcije defekata tokom cijelog životnog ciklusa projekta podiže krivulju otkrivenih defekata prema gore. A korištenje metoda prevencije defekata spušta krivulju unesenih defekata naniže. Tako se smanjuje broj neotkrivenih nedostataka tokom životnog ciklusa, a kao rezultat toga, smanjuje se broj neotkrivenih nedostataka na kraju projekta.
Rice. 5. Promjena broja nedostataka u projektu tokom vremena uz integrirani pristup upravljanju kvalitetom.
Metode pretraživanja grešaka
Metode otkrivanja kvarova mogu se klasificirati prema sljedećim kriterijima:
- statički i dinamički;
- ručno i automatizovano.
Dakle, mogu se razlikovati četiri kategorije metoda:
Ručna analiza artefakata:
Lične recenzije, ;
Formalne inspekcije , , ;
Grupne recenzije (prolaz);
Programiranje u paru, grupni dizajn;
Automatska statička provjera:
Kompilacija (pored očiglednih nedostataka, kompajler može pronaći implicitna upozorenja – ne treba ih zanemariti);
Automatska statička analiza koda pomoću posebnih analizatora;
Automatska provjera usklađenosti sa prihvaćenim standardom i stilom koda;
Automatsko testiranje:
Jedinično testiranje (testiranje jedinica) , , ;
Automatsko funkcionalno (kompleksno) testiranje;
Automatsko GUI testiranje;
Testiranje performansi; testiranje na stres;
Korištenje tvrdnji;
Ručno testiranje:
Ručno testiranje integracije;
Ručno testiranje sistema;
Uporedno testiranje;
Verifikacija ;
Praćenje korak po korak;
Svaka od navedenih metoda ima svoje prednosti i nedostatke. Neke vrste defekata bolje je uhvatiti jednom metodom, a neke drugom. Stoga će efikasna strategija za pronalaženje nedostataka biti korištenje kombinacije nekoliko heterogenih metoda. Svaki metod pretrage, u zavisnosti od toga koliko je dobro implementiran i primenjen u određenim uslovima, imaće svoj nivo efikasnosti, izražen u procentima. U knjizi S. McConnell-a "Perfect Code" možete pronaći tabelu približne efikasnosti detekcije defekta za različite metode (pogledajte kopiju ove tabele ispod). Napominjemo da prema ovim podacima testiranje ima relativno nisku efikasnost u pronalaženju nedostataka (25%-40%), a da bi ono bilo visoko, potrebno je višestruko povećati trošak procesa testiranja (efikasnost beta testiranje sa brojem testera >1000 je oko 75 %).
| Metoda pretrage | EPD% | Metoda pretrage | EPD% |
| Neformalni pregled dizajna | 35% | Testiranje nove funkcije (komponente) | 30% |
| Formalni projektantski (tehnički) pregledi | 55% | Integracijsko testiranje | 35% |
| Neformalni pregled koda | 25% | Regresijsko testiranje | 25% |
| Recenzije formalnog koda | 60% | Testiranje sistema | 40% |
| Modeliranje i izrada prototipa | 65% | Beta testiranje (<10 тестеров) | 35% |
| Jedinično testiranje | 30% | Beta testiranje (>1000 testera) | 75% |
Metode prevencije defekata
Ne bi nam bile potrebne gore navedene metode za pronalaženje nedostataka ako bismo naučili da razvijamo softver bez kvarova. Malo je vjerojatno da će se to postići, ali vrijedi pokušati smanjiti broj unesenih nedostataka. Metode za sprječavanje kvarova uključuju sljedeće:
Izrada prototipa je kreiranje i testiranje jeftinog modela sistema koji se razvija kako bi se testirale njegove karakteristike i identifikovale pogrešne pretpostavke i rješenja koja bi mogla dovesti do ozbiljnih nedostataka (i dorade) tokom razvoja.
Upotreba standarda za sve vrste proizvoda proizvedenih tokom razvoja softvera (zahtjevi, arhitektura, kod, razna dokumentacija itd.). Strogi, univerzalno prihvaćeni standardi pomažu da se minimiziraju mogući nesporazumi među ljudima pri radu sa ovim proizvodima (kada čitalac proizvoda nije pročitao šta je kreator proizvoda imao na umu) i, kao rezultat, sprečavaju pojavu nedostataka povezanih s tim.
Primjena komponentnog (ili modularnog) pristupa. Pravilna upotreba komponentnog pristupa pri izgradnji softverskih sistema smanjuje njihovu složenost i, posljedično, sužava prostor mogućih nedostataka.
Koristeći gotova, provjerena rješenja i komponente (vlastite ili kupljene), u čiji visok kvalitet smo uvjereni. Što manje moramo da razvijamo nova sopstvena rešenja, činimo manje grešaka.
Refaktoriranje koda - dovođenje koda u odgovarajući oblik je dobar način da se spriječi budući defekti održavanja, koji će se vrlo vjerovatno pojaviti prilikom modifikacije nerazumljivih, loše dizajniranih dijelova koda.
Preliminarni razvoj test slučajeva (prije faze kodiranja) omogućava vam da bolje razumijete zahtjeve za sistem koji se razvija i bolje ga dizajnirate. Poseban slučaj ovog pristupa je razvoj vođen testom, u kojem se testovi jedinica razvijaju ne nakon, već prije kodiranja.
Redovna analiza uzroka najozbiljnijih kvarova i traženje načina za otklanjanje ovih uzroka. Ovo se može dogoditi na periodičnim sastancima razvojnog tima, ili se može učiniti za svaki veći defekt koji se nađe tokom testiranja sistema ili faza nakon implementacije. Rezultat takve analize treba da budu modifikacije procesa razvoja koje imaju za cilj eliminisanje uzroka nedostataka ili, u najmanju ruku, olakšavanje ranijeg otkrivanja takvih nedostataka.
Koje su vaše ideje?
Ljudski faktor je takođe vredan pomena. Nijedna metoda ne može zamijeniti profesionalizam i iskustvo programera i menadžera. Pravi iskusni profesionalci u pravilu manje griješe, a korištenje njihovog iskustva predstavlja dobru osnovu za kvalitetan razvoj. Ako se tim sastoji prvenstveno od mladih, neiskusnih programera, onda biste trebali razmotriti mogućnost provođenja posebne obuke za njih.
Upravljanje kvalitetom u iterativnom životnom ciklusu
Razmotrimo, na primjer, iterativni životni ciklus koji se sastoji od 5 iteracija, od kojih se svaka može smatrati malim ali potpunim životnim ciklusom vodopada (slika 6).
Rice. 6. Promjena broja nedostataka u projektu tokom vremena tokom iterativnog životnog ciklusa.
Pretpostavimo da je efikasnost pronalaženja defekata svake vodopadne petlje 50%, a isti broj defekata se uvodi na svakoj iteraciji. Izračunajmo koristeći EPD% formulu, koja će biti jednaka efikasnosti traženja nedostataka u iterativnom ciklusu koji se sastoji od pet uzastopnih iteracija. Nakon 1. iteracije, ova efikasnost će biti 50%; nakon 2. – 62,5%; nakon 3. – 70,8%; nakon 4. – 76,6%; nakon 5., efikasnost traženja nedostataka svih 5 iteracija će biti jednaka 80,6%.
Ovaj primjer je idealiziran, a u stvarnom životu, efikasnost pronalaženja nedostataka na različitim iteracijama će se najvjerovatnije razlikovati. To je zbog heterogenosti aktivnosti u različitim iteracijama. Ali u svakom slučaju, postoji jasan napredak u kvaliteti prije jednostavnog životnog ciklusa vodopada. Ovaj efekat se može objasniti vrlo jednostavno: pri svakoj sledećoj iteraciji nalazimo nedostatke ne samo trenutne iteracije, već i preostale nedostatke prethodnih iteracija. Kao rezultat, povećava se ukupna efikasnost detekcije kvarova.
Dakle, ispada da se poboljšanje kvaliteta može postići ne samo uvođenjem dodatnih metoda za rano otkrivanje nedostataka (kao što su inspekcije, pregledi, itd.), već i prelaskom sa vodopada na iterativni životni ciklus razvoja softvera. Štaviše, teoretski, što je više iteracija, to je bolji kvalitet. Testiranje u početnim iteracijama može se smatrati pronalaženjem nedostataka u ranoj fazi životnog ciklusa.
Cijena kvaliteta softvera
Može se činiti da će korištenje mnogo različitih metoda za poboljšanje kvaliteta softvera povećati troškove razvoja softvera. Ovo može biti tačno u kratkom roku (dok se proces njihove upotrebe ne stabilizuje) ili ako se metode koriste pogrešno. Dugoročno, integrisana upotreba metoda poboljšanja kvaliteta ne samo da ne povećava troškove razvoja, već može i smanjiti njegovu cenu. Hajde da vidimo zašto se to dešava.
Prvo, kao što je gore spomenuto, što se prije pronađe kvar, to je jeftinije popraviti ga. Stoga, efikasna upotreba metoda ranog otkrivanja kvarova pomaže u smanjenju troškova projekta.
Drugo, metode traženja defekata o kojima smo gore govorili, pored efikasnosti, karakteriše i prosečna brzina pronalaženja nedostataka. Prema statističkim podacima, na primjer iz, ovaj pokazatelj za metode ispitivanja je nekoliko puta lošiji nego za metode ranog otkrivanja nedostataka. To znači da trošenjem vremena na pronalaženje nedostataka u ranim fazama, štedimo više vremena na budućim testiranjima.
S. McConnell tvrdi da „povećanje kvaliteta sistema smanjuje troškove njegovog razvoja“, jer “Uklanjanje nedostataka (u kasnim fazama) je zapravo najskuplja i najdugotrajnija faza razvoja softvera.”
Proces upravljanja kvalitetom
Da bi se upravljalo kvalitetom, nije dovoljno jednostavno koristiti različite metode za poboljšanje kvaliteta. Neophodna je njihova svjesna, sistematska primjena, koja bi postala sastavni dio procesa razvoja softvera usmjerenog na kvalitet.
Neophodno je stalno pratiti kvalitet softvera koji se razvija kroz metriku kvaliteta, kao i kontrolu kvaliteta pojedinih podprocesa koji čine čitav razvojni proces.
Metode koje su dobro funkcionirale jučer mogu danas biti gubljenje vremena. Svaki projekat može imati svoje specifičnosti, zahtijevajući drugačiji skup metoda poboljšanja kvaliteta. Ako se efikasnost metoda ne prati stalno, onda se s vremenom može značajno pogoršati.
Upravljanje kvalitetom je i stalna potraga za načinima poboljšanja procesa razvoja kako bi se smanjio broj unesenih nedostataka i povećala efikasnost metoda otkrivanja nedostataka.
Zaključak
Hajde da sumiramo sve navedeno. Kvalitet softvera je prvenstveno određen procesom razvoja ovog softvera. Samo zreo, stabilan, kvalitetno orijentisan proces je u stanju da proizvede softverske proizvode sa predvidljivim nivoima kvaliteta koji se mogu kontrolisati. Takav proces treba da se zasniva na osnovnim principima upravljanja kvalitetom softvera:
stalno traženje i ispravljanje nedostataka tokom čitavog životnog ciklusa razvoja, počevši od najranijih faza;
sistematska primjena metoda prevencije kvarova;
stalna kontrola kvaliteta razvijenog softvera i procesa razvoja;
kontinuirano unapređenje procesa razvoja u cilju poboljšanja kvaliteta.
1. Humphrey, Watts S., Disciplina za softversko inženjerstvo, ISBN 0-201-54610-8. Autorska prava 1995. Addison-Wesley.
2. McConnell S., Savršen kod. Master class / Transl. sa engleskog –M.: Izdavačko-trgovinska kuća “Rusko izdanje”; Sankt Peterburg: Petar, 2005.
3. Humphrey, Watts S., Uvod u timski softverski proces, ISBN 0-201-47719-X. Autorsko pravo 2005. od Addison Wesley Longman, Inc.
4. Humphrey, Watts S., PSP: proces samopoboljšanja za softverske inženjere, ISBN 0-321-30549-3. Autorsko pravo 2005 Pearson Education, Inc.
5. Ambler S., Agilne tehnologije: ekstremno programiranje i unificirani razvojni proces. Programerska biblioteka. Per. sa engleskog –SPb.: Petar, 2005.
6. Kroll P., Kratchen F., Rational Unified Process - to je lako. Vodič za praktičare za RUP. Per. sa engleskog – M.: KUDIT-OBRAZ, 2004.
7. R. J. Torres, Praktični vodič za dizajn i razvoj korisničkog interfejsa. Prevod sa engleskog –M.: Izdavačka kuća Williams, 2002.
8. Bobrovsky S., Softversko inženjerstvo. Tehnologije Pentagona u službi ruskih programera. –SPb.: Petar, 2003.
9. Hunt E., Thomas D., Pragmatic Programmer. Put od šegrta do majstora. Per. sa engleskog –M.: Izdavačka kuća “Lori”, 2004.
10. Fowler M., Refaktoring: poboljšanje postojećeg koda. Per. sa engleskog – Sankt Peterburg: Symbol-Plus, 2005.
11. Beck K., Ekstremno programiranje. Per. sa engleskog –SPb.: Petar, 2002.
12. Beck K., Ekstremno programiranje: Test Driven Development. Programerska biblioteka. Per. sa engleskog –SPb.: Petar, 2003.
13. GOST R ISO 9000-2001, http://bib-gost.narod.ru/kazestvo/_gost_r_iso_9000_2001.zip
14. Royce Walker, Upravljanje procesom razvoja softvera. Per. sa engleskog –M.: Izdavačka kuća “Lori”, 2007.
15. Tian, Jeff, Inženjering kvaliteta softvera, ISBN 0-471-71345-7. Autorsko pravo 2005. od strane IEEE Computer Society.
Kvalitet softvera- karakteristike softvera (softvera) kao stepen njegove usklađenosti sa zahtjevima. Istovremeno, zahtjevi se mogu tumačiti prilično široko, što dovodi do niza nezavisnih definicija pojma. Najčešće korištena definicija je ISO 9001, prema kojoj je kvalitet „stepen do kojeg inherentne karakteristike ispunjavaju zahtjeve“.
Kvalitet izvornog koda
Kvalitet koda se može odrediti različitim kriterijima. Neki od njih su značajni samo iz ljudske perspektive. Na primjer, način na koji je tekst programa formatiran je potpuno nevažno za računar, ali može imati ozbiljne implikacije za kasnije održavanje. Mnogi postojeći standardi kodiranja, koji definišu konvencije specifične za jezik i postavljaju niz pravila koja poboljšavaju čitljivost koda, imaju za cilj da olakšaju buduće održavanje softvera, uključujući otklanjanje grešaka i ažuriranje. Postoje i drugi kriterijumi koji određuju da li je kod „dobro“ napisan, na primer, kao što je strukturiranost – stepen do kojeg je kod logički podeljen na niz blokova kojima se može upravljati.
- Čitljivost koda
- Jednostavnost podrške, testiranja, otklanjanja grešaka, ispravljanja grešaka, modifikacije i prenosivosti
- Niska složenost koda
- Niska upotreba resursa: memorija i CPU vrijeme
- Ispravno rukovanje izuzetkom
- Nekoliko upozorenja tokom kompilacije i povezivanja
Metode za poboljšanje kvaliteta koda: refaktoring.
Faktori kvaliteta
Faktor kvaliteta softvera je nefunkcionalni zahtjev za program koji obično nije opisan u ugovoru s kupcem, ali je ipak poželjan zahtjev koji poboljšava kvalitetu programa.
Neki od faktora kvaliteta su:
Razumljivost Svrha softvera treba da bude jasna iz samog programa i dokumentacije. Kompletnost Svi potrebni dijelovi programa moraju biti predstavljeni i u potpunosti implementirani. kratkoća Odsustvo nepotrebnih, duplih informacija. Ponavljane dijelove koda treba pretvoriti u uobičajeni poziv procedure. Isto važi i za dokumentaciju. prenosivost Lakoća prilagođavanja programa drugom okruženju: drugoj arhitekturi, platformi, operativnom sistemu ili njegovoj verziji. Konzistentnost Iste konvencije, formati i notacije moraju se koristiti u cijelom programu i dokumentaciji. mogućnost održavanja Koliko je teško promijeniti program da bi se zadovoljili novi zahtjevi. Ovaj zahtev takođe navodi da program mora biti dobro dokumentovan, da ne bude previše zbunjujući i da ima prostora za povećanje upotrebe resursa (memorija, procesor). mogućnost testiranja Da li vam program omogućava da provjerite karakteristike prihvatljivosti, da li je podržana mogućnost mjerenja performansi. jednostavnost korištenja Jednostavnost i lakoća korištenja programa. Ovaj zahtjev se prvenstveno odnosi na korisnički interfejs. pouzdanost, odsustvo kvarova i kvarova u radu programa, kao i lakoća ispravljanja nedostataka i grešaka: strukturirana efikasnost Kako racionalno program tretira resurse (memoriju, procesor) prilikom obavljanja svojih zadataka. sigurnost
Sa stanovišta korisnika
Pored tehničkog pogleda na kvalitet softvera, postoji i procjena kvaliteta iz perspektive korisnika. Termin "upotrebljivost" se ponekad koristi za ovaj aspekt kvaliteta. Prilično je teško dobiti ocjenu upotrebljivosti za dati softverski proizvod. Najvažnija pitanja koja utiču na procjenu:
- Da li je korisnički interfejs intuitivan?
- Koliko je lako izvoditi jednostavne, česte operacije?
- Koliko je lako izvesti složene operacije?
- Da li program proizvodi jasne poruke o grešci?
- Da li se program uvijek ponaša prema očekivanjima?
- Postoji li dokumentacija i koliko je kompletna?
- Da li je korisničko sučelje samoopisno/samodokumentirajuće?
- Da li su kašnjenja odgovora programa uvijek prihvatljiva?
vidi takođe
Linkovi
| Razvoj softvera | |
|---|---|
| Famous figure |
|
| Proces | |
| Koncepti | |
| Upute | |
| Modeli razvoj |
|
| Ostali modeli | |
| Ostalo | |
Wikimedia fondacija. 2010.
Pogledajte šta je “Kvalitet softvera” u drugim rječnicima:
Sposobnost softverskog proizvoda da potvrdi svoju specifikaciju, pod uslovom da je specifikacija fokusirana na karakteristike koje korisnik želi. Vidi također: Kvalitet softvera Softver Finansijski… … Financial Dictionary
Dok je Grejs Hoper radila na računaru Harvard Mark II na Univerzitetu Harvard, njene kolege su otkrile da se ovaj moljac zaglavio u releju i na taj način ometa rad uređaja, nakon čega je primetila da "otklanjaju greške" u sistemu.... . Wikipedia
Razvoj softvera Proces razvoja softvera Koraci procesa Analiza Dizajn Programski dokument ... Wikipedia
Razvoj softvera (eng. software engineering, software development) je vrsta djelatnosti (profesije) i proces koji ima za cilj kreiranje i održavanje funkcionalnosti, kvaliteta i pouzdanosti softvera korištenjem... Wikipedia
- „Softverska kriza“ je termin koji se nekada koristio u računarstvu da opiše posledice brzog rasta računarske snage računara i složenost problema koji se uz njihovu pomoć mogu rešiti. U suštini, ovo je... ... Wikipedia
Novi Airbus A 380 koristi dosta softvera za kreiranje moderne kabine u avionu. Metoda softverskog inženjeringa omogućila je stvaranje softvera za avione opisanog u milionima redova... Wikipedia
Sposobnost softvera da radi na različitim hardverskim platformama ili operativnim sistemima. Sinonimi: Prenosivost softvera Vidi takođe: Kvalitet softvera Otvoreni sistemi... ... Financial Dictionary
Karakteristike softverskog proizvoda koje: omogućavaju vam da minimizirate napore korisnika da pripremite početne podatke, koristite softverski proizvod i procijenite dobivene rezultate, a također vam omogućavaju da izazovete pozitivne emocije... ... Financial Dictionary
Karakteristike softverskog proizvoda koje omogućavaju minimiziranje napora da se izvrše njegove promjene: da se eliminišu greške; ili za modifikaciju kako bi se zadovoljile promjenjive potrebe korisnika. Vidi također: Kvalitet softvera ... ... Financial Dictionary
Sposobnost softverskog proizvoda da izvrši skup funkcija: definisanih u njegovom eksternom opisu; i zadovoljavanje specificiranih ili podrazumijevanih potreba korisnika. Sinonimi: Interoperabilnost softvera Vidi također: Kvalitet...... Financial Dictionary
Knjige
- Code Perfect: Praktični vodič za razvoj softvera, S. McConnell Više od 10 godina, prvo izdanje ove knjige se smatra jednim od najboljih praktičnih vodiča za programiranje. Sada je ova knjiga potpuno ažurirana uzimajući u obzir savremene trendove i tehnologije...
Pristupi kvaliteti softvera
Hajde da klasifikujemo različite pristupe kvalitetu softvera koristeći dve dimenzije.
Prva dimenzija je ili proizvod ili proces. Da biste poboljšali kvalitetu softvera, možete se fokusirati na kvalitet samog proizvoda, na primjer, čineći ga lakšim za korisnika. Alternativni pristup je poboljšanje procesa razvoja, uz pretpostavku da što je proces bolji, to je bolji kvalitet softvera.
Druga dimenzija se odnosi ili na usklađenost ili na poboljšanje. Pod usklađenošću podrazumijevamo usklađenost sa bilo kojim standardom. Poboljšanje ima za cilj prelazak na bolje metode i bolje prakse za poboljšanje kvaliteta.
ISO 9126 je standard kvaliteta proizvoda koji definiše atribute i karakteristike kvaliteta, uključujući merenja za kvantifikaciju ovih karakteristika;
"poboljšana praksa" je, na primjer, poboljšano upravljanje konfiguracijom softvera, inspekcija, testiranje, itd.;
ISO 9000 je skup standarda koji deklarišu zahteve za sisteme kvaliteta. Iz perspektive razvoja softvera, najkorisnije su Smjernice za primjenu ISO 9001 u razvoju, isporuci i održavanju softvera;
Metode za poboljšanje procesa razvoja softvera obezbjeđuju skalu nivoa i zahtjeva usklađenosti prema kojima se kompjuterska kompanija može postaviti na tu ljestvicu. Dvije najpoznatije i najpopularnije metode su:
Model zrelosti procesa razvoja softvera - Capability Maturity Model for Software (CMM), koji je predložio Institut za softversko inženjerstvo (SEI);
identifikovanje mogućnosti i poboljšanje procesa kreiranja softvera. ISO/IEC 15504 Poboljšanje softverskog procesa i određivanje sposobnosti (SPICE).
Dvije kritičke izjave su u osnovi postizanja kvaliteta.
- Kvalitet počinje zadovoljavanjem potreba programera.
- Kvalitet je dokazan zadovoljavanjem potreba korisnika.
Pristupi postizanju kvaliteta su:
- kvalitet se postiže uz pomoć kvalifikovanih programera, striktnog pridržavanja procesa i uspešnih tehnoloških pristupa;
- kvalitet se postiže potpunim razumijevanjem svih radnji i promjena. Niti jedan red u programu ne treba dodati ili promijeniti bez potpunog razumijevanja šta, zašto i kako se to radi;
- kvalitet se postiže temeljnim testiranjem programa prije nego što bude stavljen na raspolaganje korisniku;
- postizanje kvaliteta mora biti planirano;
- Postizanje kvaliteta je odgovornost svakog programera.
Karakteristike kvaliteta softvera
Trenutno ne postoje opšteprihvaćeni kriterijumi za kvalitet softvera.
Standard ISO 9000-3, tačka 6.4.1
Klasična definicija kvaliteta je da razvijeni softverski proizvod potvrđuje svoju specifikaciju, a specifikacija treba da bude orijentisana na karakteristike koje klijent želi.
Savremeni standardi pojašnjavaju pojam kvaliteta uvođenjem skupa karakteristika i karakteristika koje utiču na njegovu sposobnost da zadovolji određene potrebe korisnika. Navedimo nekoliko takvih karakteristika [Zhogolev 1996].
Funkcionalnost (prikladnost, tačnost, interoperabilnost, konzistentnost, sigurnost). Funkcionalnost je sposobnost softverskog proizvoda da izvrši skup funkcija koje zadovoljavaju određene ili implicirane potrebe korisnika. Skup takvih funkcija definiran je u eksternom opisu softverskog proizvoda.
Pouzdanost (potpunost, stabilnost, mogućnost povrata).
Pogodnost (razumljivost, jednostavnost upotrebe, ergonomija). Pogodnost je karakteristika softverskog proizvoda koja omogućava minimiziranje napora korisnika da pripremi inicijalne podatke, koristi softverski proizvod i evaluira dobijene rezultate, kao i izazove pozitivne emocije kod određenog ili implicitnog korisnika.
Efikasnost (u smislu vremena i resursa). Efikasnost je odnos nivoa usluga koje softverski proizvod pruža korisniku pod datim uslovima i količine upotrebljenih resursa.
Održivost (lakoća analize, promjenjivost, stabilnost, provjerljivost). Održivost je karakteristika softverskog proizvoda koja minimizira napor potreban za unošenje promjena kako bi se uklonile greške u njemu i modificirao u skladu s promjenjivim potrebama korisnika.
Prenosivost (prilagodljivost, fleksibilnost instalacije, usklađenost sa standardima i pravilima, zamjenjivost). Prenosivost je sposobnost softverskog proizvoda da se prenese iz jednog okruženja u drugo, posebno iz jedne hardverske arhitekture u drugu.
Dobar kvalitet (racionalna organizacija, promišljenost). Pogledajmo bliže dvije najzanimljivije karakteristike.
Pouzdanost je sposobnost programa da obavlja određene funkcije bez otkaza pod datim uslovima u datom vremenskom periodu sa dovoljno velikom vjerovatnoćom. Pouzdan softverski proizvod ne isključuje prisustvo grešaka u njemu. Ovdje je važno da se greške u praktičnoj primjeni u datim uslovima javljaju prilično rijetko. Stepen pouzdanosti karakteriše vjerovatnoća da softverski proizvod radi bez kvara u određenom vremenskom periodu.
Postoje sljedeći pristupi za osiguravanje pouzdanosti:
- prevencija grešaka;
- samootkrivanje grešaka;
- samoispravljanje grešaka;
- osiguravanje tolerancije greške.
Dobrota programa je u tome što je program razumno i racionalno organizovan, sa prilično promišljenom organizacijom kontrolnih tokova i tokova informacija i nije preterano komplikovan. Koncept faktora kvaliteta uveo je Pottosin [Pottosin 1997] kako bi se sa tehničke strane procijenile interne prednosti implementacije programa. Pottosin uvodi četiri klase kriterijuma kvaliteta za programe.
Kvantitativni kriterijumi povezani sa različitim metodama procene (metrike) složenosti programa. Navedimo primjere numeričkih karakteristika.
Halstead mjere [Halstead 1981], koje uključuju niz formula za procjenu dužine, obima, nivoa i intelektualnog sadržaja programa.
Procjena složenosti kontrolnog grafa programa. Fragment programa se može procijeniti ciklomatskim brojem njegovog kontrolnog grafa, koji je jednak m - n + 2, gdje je m broj lukova, an broj vrhova kontrolnog grafa. Smatra se da ciklomatski broj ne bi trebao biti veći od 10.
Evaluacija modularizacije programa. Takva procjena treba da se sastoji od mnogo kriterija. Na primjer, složenost modula se ocjenjuje ukupnom složenošću procedura definiranih u njemu i složenošću veza modula sa drugim modulima za uvoz i izvoz definiranih entiteta.
Genetski kriterijumi povezani sa nastankom programa i disciplinom njegovog kreiranja.
Strukturni kriterijumi koji se odnose na ocjenu upravljačke organizacije u programu i odraz upravljačke organizacije u tekstu programa.
Pragmatični kriterijumi koji se odnose na procenu u kojoj meri tekst programa ispunjava svrhu programa. Formulira se lista ekscesa koji ne bi trebali postojati u dobrim programima, na primjer, računska redundantnost.
Procjena kvaliteta procesa razvoja
Zahtevati i efikasnost i fleksibilnost od istog programa
to je kao da tražite šarmantnu i skromnu ženu.
Očigledno, trebali bismo se zaustaviti na jednoj od dvije stvari.
D. Weinberg
Na početku ovog odeljka napomenuli smo da postoje dva pristupa koja se mogu koristiti za procenu kvaliteta softverskog proizvoda.
- Procijenite kvalitetu finalnog proizvoda.
- Procijenite kvalitet procesa razvoja.
Kvaliteta finalnog proizvoda može se ocijeniti testiranjem i radom. Za to treba izdvojiti vrijeme nakon završetka glavnog rada na programu. Ali drugi pristup bi trebao postati dio dugoročne strategije kompanije.
Model zrelosti procesa razvoja softvera
Model definiše pet nivoa organizacijske zrelosti (http://www.sei.cmu.edu/cmm).
Prvi nivo. Na ovom nivou, proces razvoja karakteriše virtuelno odsustvo procesa upravljanja. Uspjeh projekta zavisi od individualnih napora, ličnih kvaliteta, pa čak i herojstva učesnika projekta.
Ponovljivi nivo. Na ovom nivou zrelosti, kompanija treba da ima uspostavljene osnovne procese upravljanja za praćenje troškova projekta, rasporeda i funkcionalnosti. Nivo karakteriše činjenica da se upravljanje projektima zasniva na akumuliranom iskustvu i da će se prethodno postignuti uspjesi ponoviti u sličnim aplikacijama.
Određeni nivo. Proces razvoja softvera (kako na nivou menadžmenta tako i na nivou inženjeringa) je dokumentovan, standardizovan i integrisan u celoj organizaciji. Proces prestaje da zavisi od individualnih kvaliteta individualnih programera i ne može kliziti na niže nivoe u kriznim situacijama.
Managed level. Kompanija postavlja detaljne kvantitativne pokazatelje za razvojni proces i kvalitet proizvoda. I proces razvoja i proizvodi su razumljivi i kontrolisani.
Optimizirajući nivo. Kontinuirano unapređenje razvojnog procesa na osnovu analize dosadašnjih rezultata procesa i primjene inovativnih ideja i tehnologija.
Identificiranje mogućnosti i poboljšanje procesa kreiranja softvera
Ovaj model je veoma blizak modelu zrelosti, ali nivoi sposobnosti se mogu primeniti ne samo na organizaciju u celini, već i na pojedinačne procese. Modeli ovog tipa se često nazivaju kontinuiranim. U kontinuiranim modelima, jedan proces može biti na niskom nivou zrelosti, a drugi na visokom nivou zrelosti. Standard definiše šest nivoa zrelosti procesa.
Nivo 0: Proces se ne pokreće.
Nivo 1. Izvršni proces.
Nivo 2. Upravljani proces.
Nivo 3. Uspostavljen proces.
Nivo 4: Predvidljiv proces.
Nivo 5. Proces optimizacije.
Prilikom procjene i poboljšanja kvaliteta procesa, izvršavaju se zadaci opisani u nastavku [Terehov, Tuñon 1999].
Poređenje procesa razvoja softvera koji postoji u datoj organizaciji sa modelom opisanim u standardu. Analiza rezultata omogućava utvrđivanje snaga i slabosti procesa, njegovih unutrašnjih rizika.
Procjena mogućnosti poboljšanja datog procesa na osnovu identifikacije trenutnih sposobnosti.
Tehnička realizacija postavljenih zadataka na osnovu formulisanih ciljeva unapređenja procesa. Nakon toga, cijeli ciklus rada počinje iznova.
O ulozi Ministarstva odbrane
Napominjemo da su istorijski modeli za procenu kvaliteta procesa razvoja kreirani sa ciljem dobijanja razumnih procedura za procenu i naknadni razvoj tehnoloških procesa u onim organizacijama koje apliciraju za narudžbine za izradu projekata od odbrambenog značaja. Modeli su primenljivi na kompanije koje razvijaju složene sisteme u realnom vremenu. To su sistemi sa dugim životnim ciklusom, gdje defekti u softveru mogu biti kritični.
Softver "dovoljno dobar".
Jučer u Seattleu nakon što je Bill Gates spomenuo izlazak beta verzije
Novi Microsoftov program pogodio je zemljotres.
Korisnici sa užasom čekaju najavu izlaska konačne verzije proizvoda.
Promotor "dovoljno dobrog" softvera je Edward Yordon [Yordon 2001]. Naglašavamo da on primjenjuje ovaj koncept na „izgubljene projekte“, koji su vezani strogim ograničenjima u pogledu vremena, budžeta i ljudskih resursa (vidi Odjeljak 1.6). U većini beznadežnih projekata, kupac može biti zadovoljan sistemom koji je dovoljno jeftin, dovoljno radi, ima potrebne mogućnosti, dovoljno je robustan i uskoro će biti spreman. U stvari, ove karakteristike se mogu smatrati definicijom "dovoljno dobrog" softvera.
Ispostavilo se da je čak i „dovoljno dobar“ softver teško kreirati. Predstavimo neke od ukupnosti razloga koji ovo objašnjavaju [Yordon 2001].
Često pokušavaju da definišu kvalitet samo u smislu nedostataka (greške). Sa stanovišta korisnika, aspekti poput spremnosti za određeni datum nisu ništa manje važni.
Pretpostavka je da je manje grešaka jednako boljem kvalitetu, a korisnik preferira taj kvalitet. Međutim, ponekad je korisnik spreman da pravi kompromise i prihvati neke greške u zamenu za brže obavljanje posla.
Ignoriranje faktora kao što su moral razvojnog tima i adekvatni uslovi rada.
James Bach ističe sljedeće neophodne uslove za stvaranje "dovoljno dobrog" softvera:
- utilitarna strategija - umjetnost kvantitativne analize i maksimiziranja neto dobiti u neizvjesnim situacijama;
- evoluciona strategija - razmatrana ne samo u odnosu na životni ciklus projekta, već i na ljude, procese i resurse;
- herojski timovi nisu moćni briljantni programeri, već obični vešti stručnjaci sposobni za efektivnu saradnju;
- dinamična infrastruktura je suprotnost birokratiji i dominaciji politike;
- dinamički procesi - procesi koji podržavaju rad u evolutivnom okruženju.
Nažalost, "dovoljno dobar" softver rijetko je zaista dovoljno dobar. Niklaus Wirth napominje da je to "posledica tužne manifestacije duha našeg vremena, u kojem nestaje lični ponos na svoj rad". Prema njegovom mišljenju, „ne možete očekivati kvalitetan rad ako mu se ne posvetite u potpunosti, ako nema ličnog zadovoljstva, štaviše, zadovoljstva od njega“.
Zanimljivo zapažanje da neke kompanije nastoje sniziti intelektualni nivo korisnika svojih proizvoda iznijeli su mnogi programeri. Za kompanije je izuzetno korisno da imaju posla s ljudima čije im tehničke kvalifikacije ne dozvoljavaju da odrede stvarne aspekte (na primjer, kvalitet, složenost, vrijednost) softverskog proizvoda. Pod plaštom "pojednostavljivanja" rada i pristupačnosti računara korisnicima, kompanije stalno preopterećuju i komplikuju softver na način da je korisniku izuzetno teško da shvati kako on zapravo funkcioniše i postane profesionalac.
Standardizacija informacionih tehnologija
Standard je općeprihvaćena definicija komponente hardvera ili softvera koja proizlazi iz sporazuma. Profil je skup pravnih i/ili faktičkih standarda usmjerenih na obavljanje određenog zadatka [Kozlov 1999].
Standardi se mogu klasifikovati na sledeći način:
- prema vrsti uspostavljanja zahtjeva:
- utvrđivanje uslova za objekat;
- utvrđivanje zahtjeva procesa;
- po mjerilu:
- međunarodni;
- vlada;
- industrija;
- preduzeća;
- po stepenu pravne registracije:
- legalno prihvaćen;
- stvarno operativni.
Proces standardizacije informacionih tehnologija podržavaju tri glavne grupe organizacija. Međunarodne organizacije koje su dio UN-a. Međunarodna organizacija za standardizaciju (ISO) je međunarodna organizacija za standardizaciju.
O ISO-u
Godine 1947. predstavnici 25 zemalja odlučili su da osnuju organizaciju čiji bi glavni zadatak bio da koordinira razvoj i ujednači međunarodne standarde. Nova organizacija je dobila naziv Međunarodna organizacija za standardizaciju (ISO). Nesklad između punog imena i skraćenice objašnjava se činjenicom da je "ISO" grčki prefiks koji znači "jednak".
Međunarodna elektrotehnička komisija (IEC) - međunarodna elektrotehnička komisija.
Međunarodna telekomunikacijska unija-Telekomunikacije (ITU-T) - međunarodna telekomunikacijska unija - telekomunikacije. Do 1993. godine ova organizacija se zvala International Telegraph and Telephone Consultative Committee - međunarodni savjetodavni komitet za telefoniju i telegrafiju.
Industrijske profesionalne ili administrativne organizacije.
Institut elektrotehničkih i elektronskih inženjera (IEEE) - Institut inženjera elektrotehnike i elektronike.
Internet Activity Board (IAB) je odbor koji upravlja internet aktivnostima.
Industrijski konzorciji.
Grupa za upravljanje objektima (OMG) - grupa za upravljanje objektima.
X/Open je konzorcij koji organizira grupa dobavljača računarske opreme.
Open Software Foundation (OSF) je fondacija otvorenog softvera.
ISO i IEC su 1987. godine objedinili svoje aktivnosti u oblasti standardizacije informacionih tehnologija i formirali jedinstveno telo - Zajednički tehnički komitet 1 (JTC1), koji je namenjen formiranju sistema osnovnih standarda u oblasti informacionih tehnologija.
Glavni problem u upravljanju kvalitetom je činjenica da je definicija kvaliteta previše nejasna i dvosmislena. To je zato što se pojam kvaliteta obično pogrešno razumije. Ova zabuna može biti uzrokovana nekoliko razloga...
Pokušajmo odgovoriti na pitanja:
- Popularan pogled na kvalitet
- zaključci
Šta je kvalitet softvera?
U našoj prvoj epizodi pokušaćemo da definišemo pojmove kvaliteta i kvaliteta softvera.
Glavni problem u upravljanju kvalitetom je činjenica da je definicija kvaliteta previše nejasna i dvosmislena. To je zato što se pojam kvaliteta obično pogrešno razumije. Ova zabuna može biti uzrokovana nekoliko razloga.
Prvo, kvalitet nije jedna ideja ili koncept, već višedimenzionalan i raznolik koncept.
Sekunda, za bilo koji pojam i definiciju postoji nekoliko nivoa apstrakcije, na primjer, kada ljudi govore o kvaliteti, jedan dio to razumije u vrlo širokom i nejasnom smislu, dok se drugi može odnositi na određenu definiciju i značenje.
Treće, pojam kvaliteta je sastavni dio naše svakodnevne komunikacije, ali uobičajena i profesionalna upotreba može biti prilično različita.
Popularan pogled na kvalitet
Općeprihvaćeno gledište o kvalitetu je da je to nešto nematerijalno i „neopipljivo“ – o tome se mogu raspravljati i raspravljati, može se kritikovati i hvaliti, ali je nemoguće izmjeriti i izmjeriti kvalitet. Izrazi kao što su “dobar kvalitet” i “loš kvalitet” jasan su primjer kako ljudi govore o nečemu što im je nejasno, nečemu što ne mogu jasno okarakterizirati i definirati. Ovo gledište odražava činjenicu da ljudi različito percipiraju i tumače kvalitet. Podrazumijeva se da se kvalitetom ne može kontrolisati i upravljati, a još više se ne može kvantificirati. Ovaj pogled je u oštroj suprotnosti sa profesionalnim pristupom upravljanju kvalitetom – kvalitet je jasno definisana veličina koja se može meriti i kontrolisati, njome se može upravljati i poboljšati.
Drugo popularno mišljenje je da je kvalitet neraskidivo povezan sa luksuzom, prvoklasnim i delikatnim ukusom. Skup, dobro osmišljen i tehnički složeniji proizvod smatra se garancijom najviše kvalitete od jeftinijih analoga. Slijedeći ovu logiku, Cadillac je kvalitetan automobil, ali Chevrolet nije, uprkos svojoj pouzdanosti i broju kvarova; ili HI-FI sistem je sistem visokog kvaliteta, ali običan radio nije. Prema ovom pristupu, kvalitet je ograničen na određenu klasu skupih proizvoda sa zamršenom funkcionalnošću i klasom proizvoda. Jednostavno rečeno, malo je vjerovatno da će jeftin proizvod biti klasifikovan kao kvalitetan proizvod.
Profesionalni pristup kvalitetu
Nažalost, takav nejasan i nejasan pogled ne može se koristiti za poboljšanje procesa razvoja softvera. Stoga je neophodno dati jasnu i izvodljivu definiciju. Crosby je 1979. definirao kvalitetu kao "usklađenost sa zahtjevima", a Juran i Gryna 1970. definirali su kvalitetu kao "prikladnost za upotrebu". Ove dvije definicije su usko povezane i savršeno se uklapaju, kao što ćemo vidjeti kasnije.
"usklađenost sa zahtjevima" pretpostavlja da zahtjevi moraju biti tako jasno definirani da ne mogu biti pogrešno shvaćeni ili protumačeni. Kasnije, tokom faze razvoja, vrše se redovna mjerenja razvijenog proizvoda kako bi se utvrdila usklađenost sa zahtjevima. Svaka neslaganja treba smatrati nedostatkom – nedostatkom kvaliteta. Na primjer, specifikacija za određeni model radija može zahtijevati mogućnost primanja određene frekvencije radio valova na udaljenosti većoj od 30 kilometara od izvora emitiranja. Ako radio stanica ne može ispuniti ovaj zahtjev, ne ispunjava zahtjeve kvaliteta i mora se smatrati neupotrebljivom i nekvalitetnom. Na osnovu istih principa, ako Cadillac ispunjava sve uslove za Cadillac automobile, onda je to kvalitetan automobil. Ako Chevrolet ispunjava sve uslove za Chevrolet automobile, onda je to i kvalitetan automobil. Ova dva automobila mogu biti potpuno različita po stilu, brzini i ekonomičnosti, ali ako se oba mjere prema njihovim standardnim standardima, onda su oba kvalitetna automobila.
Definicija "Prikladnost za upotrebu" uzima u obzir zahtjeve i očekivanja krajnjih korisnika proizvoda, koji očekuju da će proizvod ili usluga odgovarati njihovim potrebama. Međutim, različiti korisnici mogu koristiti proizvod na različite načine, što znači da proizvod treba imati što više različitih slučajeva upotrebe. Prema Juranovoj definiciji, svaki slučaj upotrebe je karakteristika kvaliteta i svi se mogu svrstati u kategorije kao parametri upotrebljivosti.
Ove dvije definicije kvaliteta (“usklađenost” i “prikladnost za svrhu”) su u suštini iste. Razlika je u tome što "prikladnost za upotrebu" ukazuje na to da zahtjevi i očekivanja kupaca igraju važnu ulogu. Uloga kupca u odnosu na kvalitetu nikada se ne može precijeniti. Sa stanovišta kupca, kvalitet proizvoda koji je kupio sastoji se od mnogo različitih faktora, kao što su cijena, performanse, pouzdanost itd.
O kvalitetu vam može reći samo vaš kupac, jer to je jedino što zaista kupuje. Kupac ne kupuje proizvod. On kupuje vašu garanciju da će sva njegova očekivanja od proizvoda biti ispunjena.
Guaspari "Znam to kad vidim"
zaključci
Pokušajmo ponovo definirati kvalitetu sa stanovišta kupca ili korisnika proizvoda.
Kvalitet je pogodan za upotrebu. Da li ovaj proizvod radi ono što mi treba, da li mi olakšava posao, mogu li ga koristiti na način koji mi odgovara.
Sada pogledajmo gledište programera.
Kvalitet je usklađenost sa specificiranim i prikupljenim zahtjevima Da li proizvod radi sve što kaže da treba?
Problem je što su navedeni i prikupljeni zahtjevi obično samo dio svih stvarnih zahtjeva i očekivanja kupca. Gdje je tačna definicija kvaliteta?
Kvalitet je usklađenost sa stvarnim zahtjevima, eksplicitnim i implicitnim. Vrlo često su implicitni zahtjevi toliko očigledni kupcu ili korisniku da on ni ne pretpostavlja da su nepoznati programerima. Na primjer, vratimo se našim automobilima - kupac može detaljno opisati zahtjeve za dizajnom, parametre motora, dizajn interijera, boju karoserije, ali nigdje nije navedeno da gume moraju biti okrugle, a vjetrobransko staklo providno.
Kupac će biti zadovoljan samo kada kupljeni proizvod u potpunosti zadovolji njegove stvarne i vitalne zahtjeve, bez obzira da li su navedeni ili ne.
Kvalitet softvera je stepen do kojeg softver ima potrebnu kombinaciju svojstava.
Kvalitet softvera je skup karakteristika softvera koji se odnose na njegovu sposobnost da zadovolji navedene i predviđene potrebe.
Karakteristike kvaliteta softvera
Funkcionalnost(Funkcionalnost) - određuje se sposobnošću softvera da riješi probleme koji odgovaraju evidentiranim i očekivanim potrebama korisnika, pod datim uslovima korištenja softvera. One. Ova karakteristika osigurava da softver radi ispravno i precizno, da je interoperabilan, da ispunjava industrijske standarde i da je zaštićen od neovlaštenog pristupa.
Pouzdanost Pouzdanost – sposobnost softvera da izvrši tražene zadatke pod određenim uslovima tokom određenog vremenskog perioda ili određenog broja operacija. Atributi ove karakteristike su kompletnost i integritet čitavog sistema, sposobnost samostalnog i pravilnog oporavka od kvarova i tolerancija grešaka.
Jednostavnost upotrebe(Upotrebljivost) - mogućnost lakog razumijevanja, proučavanja, korištenja i atraktivnosti softvera za korisnika.
Efikasnost(Efikasnost) – sposobnost softvera da obezbedi potreban nivo performansi u skladu sa dodeljenim resursima, vremenom i drugim određenim uslovima.
Jednostavnost održavanja(Održavanje) - lakoća sa kojom se softver može analizirati, testirati, mijenjati kako bi ispravio nedostatke, implementirao nove zahtjeve, olakšao dalje održavanje i prilagodio se datom okruženju.
Prenosivost(Prenosivost) – karakteriše softver u smislu lakoće njegovog transfera iz jednog okruženja (softver/hardver) u drugo.
Model kvaliteta softvera
Trenutno najčešći i korišteni model kvaliteta softvera na više nivoa, predstavljen u skupu standarda ISO 9126. Istaknuto na najvišem nivou 6 glavnih karakteristika kvaliteta softvera, od kojih je svaki definiran skupom atributa koji imaju odgovarajuće metrike za naknadnu evaluaciju ( vidi sl. 1).
Slika 1 – Model kvaliteta softvera (ISO 9126-1)
29. Karakteristike kvaliteta softvera (GOST).
GOST ISO 9126-93
Kvalitet softvera može se ocijeniti prema sljedećim karakteristikama:
4.1 Funkcionalnost(Funkcionalnost) Skup atributa koji se odnose na suštinu skupa funkcija i njihova specifična svojstva. Funkcije su one koje ispunjavaju navedene ili predviđene potrebe: Napomene
1 Ovaj skup atributa karakteriše šta softver radi da bi zadovoljio neku potrebu, dok drugi skupovi prvenstveno karakterišu kada i kako se izvodi.
4.2 Pouzdanost Pouzdanost Skup atributa koji se odnose na sposobnost softvera da održi svoj nivo performansi pod određenim uslovima tokom određenog vremenskog perioda. Napomene 1 Nema habanja ili starenja softvera. Ograničenja u pouzdanosti nastaju zbog grešaka u zahtjevima, dizajnu i implementaciji. Kvarovi zbog ovih grešaka zavise od načina na koji se softver koristi i prethodno odabranih verzija softvera. NAPOMENA 2 ISO 8402 definira "pouzdanost" kao "sposobnost elementa da izvrši traženu funkciju." U ovom standardu funkcionalnost je samo jedna od karakteristika kvaliteta softvera. Stoga je definicija pouzdanosti proširena na „održavanje nivoa performansi“ umjesto „izvršavanja tražene funkcije“ (vidi također 3.4).
4.3 Praktičnost(Upotrebljivost) Skup atributa koji se odnose na obim posla koji je potreban za korištenje i individualnu procjenu takve upotrebe od strane određenog ili predviđenog raspona korisnika. Napomene 1 „Korisnici“ se mogu tumačiti kao većina direktnih korisnika interaktivnog softvera. Korisnici mogu uključivati operatere, krajnje korisnike i indirektne korisnike koji
na koje utiče ovaj softver ili koji zavise od njegove upotrebe. Praktičnost se mora uzeti u obzir u različitim radnim uslovima korisnika koji mogu uticati na softver, uključujući pripremu za upotrebu i evaluaciju rezultata.
2 Upotrebljivost, definisana u ovom standardu kao specifičan skup atributa softverskog proizvoda, razlikuje se od definicije sa ergonomske tačke gledišta, gde se druge karakteristike kao što su efikasnost i neefikasnost smatraju komponentama upotrebljivosti.
4.4 Efikasnost(Efikasnosti) Skup atributa koji se odnose na odnos između nivoa kvaliteta rada softvera i količine resursa koji se koriste pod određenim uslovima. NAPOMENA Resursi mogu uključivati druge softverske proizvode, hardver, materijale (na primjer, papir za štampanje, diskete) i usluge osoblja za rad, održavanje ili održavanje.
4.5 Održavanje(Održivost) Skup atributa koji se odnosi na količinu posla potrebnog za izvođenje specifičnih promjena (modifikacija). NAPOMENA Promena može uključivati ispravke, poboljšanja ili prilagođavanje softvera promenama u okruženju, zahtevima i uslovima rada.
4.6 Mobilnost(Prenosivost) Skup atributa koji se odnose na sposobnost softvera da se prenese iz jednog okruženja u drugo. NAPOMENA Okruženje može uključivati organizaciono, tehničko ili softversko okruženje.
