Ovde govorimo o iskustvima kod izgradnje sistema kvaliteta prema zahtevima standarda ISO 9001 i primeni stečenog iskustva na razvoju softvera.
Ideje su usklađene sa zahtevima standarda ISO 9001 Sistemi kvaliteta – Model za osiguranje kvaliteta u ideji, razvoju, proizvodnji, ugradnji i održavanju tj. tačkom 4.4. Upravljanje idejom (Design control), kao i ISO 9000-3:1997(E) Guidelines for the applicaion of ISO 9001:1994 to the development, supply, installation and maintenance of computer software.
Cilj ovladavanja razvojem softvera je da se razvojne aktivnosti obavljaju pod kontrolisanim uslovima, na organizovan način, brzo i ekonomično, a da konačni proizvod u celini zadovolji zahteve koji su unapred definisani od strane naručioca.
Razvoj softvera (u širem smislu) delimo i pratimo kroz sledeće faze:
1. postavljanje strategije sistema,
2. analiza sistema ili dela sistema za koji se izrađuje softver,
3. dizajn (oblikovanje) sistema,
4. izgradnja (programiranje) sistema s uporednom izgradnjom dokumentacije,
5. prelaz na novi sistem i
6. produkcija s novim sistemom.
Za složene i dugotrajne projekte potrebno je osigurati:
Napomena: Razvojni projekat se odnosi na jednu ili više faza iz navedene podele.
U užem smislu razvoj softvera je analiza, dizajn i programiranje. Na žalost u pojedinim slučajevima je to samo programiranje!
Polazi se od strateške odrednice da je za uspešnu realizaciju projekta potrebno uključiti kupca kao ravnopravnog partnera i zajedno sa njim definisati ciljeve projekta.
Pored navedenog potrebno je definisati nosioce posla (radni tim) od strane naručioca i izvođača.
U definiciji ciljeva uključen je naručilac sa timom određenim za realizaciju projekta i izvođač sa vođom projekta i sopstvenim timom.
Vođa projekta sa strane naručioca je ključna osoba koja se imenuje u samom početku projekta i na njoj počiva uspešnost realizacije projekta.
Poželjne karakteristike vođe projekta su:
Naručilac i izvođač moraju da sagledaju i druge aspekte projekta da bi mogli da planiraju sve faze u životnom ciklusu razvoja softvera.
Bitni faktori koje treba prepoznati na vreme (pre potpisivanja ugovora) i voditi računa o njima su:
Sagledavanjem svih navedenih faktora postavlja se projektni zadatak.
Projektni zadatak treba da postavi naručilac posla.
U praksi naručilac često nema dovoljno znanja i/ili iskustva da postavi projektni zadatak pa su zato moguće i alternativne kombinacije u postavljanju zadatka; npr. naručilac-izvođač ili treća strana angažovana od naručioca (konsultant).
Osnovni dokument koji nastane kao rezultat rada na projektnom zadatku je plan realizacije projekta.
Plan realizacije projekta obuhvata:
Vođa projekta zajedno sa rukovodstvom izrađuje plan realizacije projekta i procenjuje potrebne resurse.
Ove dve aktivnosti su u međusobnoj korelaciji pošto bez jasno definisanih faza i koraka u izvršenju projektnih zadatka nije moguće predvideti sve potrebne resurse; i obrnuto.
Bez poznavanja raspoloživih resursa nemoguće je napraviti plan realizacije projekta.
Plan realizacije projekta donosi se i prati po fazama (vidi poglavlje: Faze razvoja softvera sa definisanim ulazima i izlazima).
Potrebni preduslovi:
Ad 1. jasna organizaciona sruktura sa definisanim odgovornostima i obavezama.
Postoje bogata iskustva u realizaciji razvojnih projekata kroz hijerarhijsko-funkcionalnu organizacionu šemu, pa do, u novije vreme, projektne organizacije poslova.
Organizaciona struktura i opis poslova definisani su u pravilniku QRG SW 00 01,
Ad 2. izabrana metodologija kao referentna osnovica – od koje se polazi i prilagođava način koristi se često metodologija pod nazivom ORACLE CASE*Method koju je inicijalno razvio Richard Barker.
Ad 3. tehnologija kojom gradimo proizvod.
Smatra se da je izbor tehnologije manji problem.
Većina današnjih projektantsko-programerskih alata podržava sve napredne koncepte u razvoju softvera (zajednički repozitorijum, objektno programiranje, nekoliko priznatih metodologija, RAD, generatori koda u više programskih jezika i sl.).
Tu je i veliki broj raznorodnih nezavisnih proizvođača softvera koji imaju alate za unapređenje kvaliteta razvoja softvera (debugging, generisanje testnih podataka i testiranje na zadane uslove, pisanje jasnog koda i sl.)
Za obavljanje ostalih aktivnosti kao što su svakodnevni kancelarijski poslovi, međusobna komunikacija, planiranje posla i slično koriste se Microsoftovi proizvodi: MS Office, MS Project, MS Exchange itd.
Ad 4. kvalifikovani izvršioci
Zadnji, ujedno i najvažniji (pred)uslov za razvoj kvalitetnog softvera jeste kvalitetan kadar.
Samo se od iskusnih ljudi koji se stalno usavršavaju i unapređuju može tražiti i očekivati uspešna realizacija složenih razvojnih projekata.
Jedan od najznačajnijih elemenata u planiranju ostvarenja svakog projekta je na vreme uočiti i organizovati posao po fazama.
Pored navedenog važno je uočiti, definisati i kontrolisati aktivnosti (detaljno u ISO 9000-3 tačka 4.4. Design control):
Ulazi za razvojnu fazu – svi zadaci (ulazi) moraju biti jasno definisani i dokumentovani i to na način da se rešenje (izlazi) može proveriti.
Mora biti omogućeno da se nekompletni, dvosmisleni ili oprečni zahtevi razreše sa osobom odgovornom za donošenje takvih zahteva (ISO 9000-3 t.4.4.4).
Izlazi iz razvojne faze – svi zadaci (izlazi) moraju biti definisani, dokumentovani i obavljeni prema unapred dogovorenoj specifikaciji (ISO 9000-3 t.4.4.5).
Postupci provere svake faze – mora postojati plan po kojem se proveravaju izlazi iz prethodne faze i usaglašavanje izlaza sa ulazima u narednu fazu.
Preglede je potrebno obavljati u predviđenim rokovima (kontrolne tačke) a rezultate pregleda koristiti za usklađenje zahteva unutar faze i usklađenjem izlaza i ulaza među fazama.
O svim aktivnostima potrebno je voditi zapise (ISO 9000-3 t.4.4.6).
Treba pomenuti još i:
U razvoju softvera različite metodologije predviđaju različite podele posla po fazama.
Recimo kod izgradnje sistema kvaliteta gde se koristila ORACLE CASE metodologija dobili smo odgovarajuća dokumentacija (poslovnik, postupke i uputstva) koja proizilazi iz nje, a to su:
Strategija – Ulaz u ovu fazu je projektni zadatak
Svaki poslovni sistem je jedinstven pa iz toga proizilazi da su rezultati srateške studije jedinstveni i specifični u posmatranom sistemu.
U uputstvu QIN SW 04 06 date su smernice (mogući sadržaj) strateške studije.
Analiza – Opisano u postupku Projektovanje softvera – QPR SW 04 03.
Dizajn – Opisano u postupku Projektovanje softvera – QPR SW 04 03.
Izgradnja – Opisano u postupku Programiranje softvera – QPR SW 04 04.
Dokumentacija – U celokupnom procesu rada stvara se tehnička dokumentacija koja opisuje sistem.
Tehnička dokumentacija je namenjena onima koji održavaju sistem i može je upotrebljavati samo osposobljeni tim koji je upoznat sa metodologijom rada i razvojnim alatima.
U ovoj fazi se piše korisnička dokumentacija bilo u obliku priručnika, bilo u obliku on-line promoći.
Pregledi ulaza i izlaza po ovoj fazi dati su u postupcima:
Prelaz – Opisano u postupku – Uvođenje softvera – QPR SW 04 02.
Produkcija – Opisano u postupku – Održavanje softvera – QPR SW 04 01
Ocena je specifična i primerena svakoj fazi iz životnog ciklusa razvoja softvera.
Osnovna pitanja na koje treba dati odgovor kod ocenjivanja svake faze su:
Smisao takvih akcija jeste potvrditi ili promeniti ciljeve postavljene u projektnom zadatku i revidirati planove realizacije projekta.
Pošto analiza rezultata rada tj. ocena izlaza iz pojedinih faza dodatno povećava troškove projekta, zato se ona retko sprovodi pa su česta iznenađenja sa konačnim rezultatima projekta.
Takođe je problem u tome što naručilac često nije stručan ili nije voljan da angažuje eksterne stručnjake za obavljanje takvog posla.
Ništa bolja situacija nije ni kod potvrde i overe softverskog proizvoda.
Zbog čestog nedostatka vremena (čitaj novca) ovim aktivnostima se često posvećuje formalna pažnja i to, nažalost, u trenutku dada je proizvod skoro gotov.
Redovnim sprovođenjem procesa potvrde i overe dobijamo odgovore na pitanja:
U svakoj razvojnoj fazi, prema unapred utvrđenim planovima tj. dogovorom između naručilaca i izvođača (vođa projekta) određuje se sadržaj, način i nivo detaljnosti potvrde i overe softverskog proizvoda.
Vođa projekta je zadužen da organizuje proces potvrde i overe softverskog proizvoda u saradnji sa razvojnim timom.
On je odgovoran da se aktivnosti obavljaju u skladu sa postavljenim planovima i dokumentovano, te da se uočeni nedostaci bilo u procesu rada ili na proizvodu uklone.
Takođe je dužnost vođe da uključi naručioca u proces overe softverskog proizvoda. Naručilac se uključuje u proces preko zajedničkog tima ili osoba izabranih za overu proizvoda.
Proces potvrde i overe se izvodi kroz devet koraka koji su detaljno opisani u uputstvu – Plan testiranja softvera – QIN SW 04 05.
Postupci se mogu iterativno ponavljati dok se ne dobije potvrda da zadovoljava dogovorenu specifikaciju ili propisane standarde (kriterijumi prihvatljivosti).
Promene zamisli tj. promena projektnog zadatka takođe je vezana za model životnog ciklusa razvoja softvera.
Model delimo u dve celine, a to su:
Što ranije dođe do promena specifikacija po kojima se započelo raditi to su posledice i uticaji na izgradnju sistema manji.
U delu fizičke izgradnje sistema naoko male promene ponekad prouzrokuju značajne troškove u razvoju softvera.
Ova celina se sastoji od tri faze, a to su:
1. Faza strategije je pravo vreme kada se moraju uočiti, profilisati i definisati sve želje korisnika.
Ovde su promene u zamisli prirodne i poželjne (borba mišljenja). Posledica je dobro ili loše definisan projektni zadatak od kojeg sve počinje.
2. U fazi analize sistema (pre detaljne analize) može doći do izmena nekih od zahteva, ali je bitno da se poštuju osnovni zahtevi iz projektnog zadatka.
Promene mogu biti dvosmerne, od strane naručilaca ili od strane projektanta.
Ugovorom treba predvideti takve promene.
3. U fazi dizajna bitno je onemogućiti ili minimalizirati dodatne zahteve za promenama na softverskom proizvodu.
Naknane zahteve treba predvideti ugovorom ili su stvar nove narudžbine tj. novog ugovora.
Fizička izgradnja sistema se sastoji od:
Po završetku faze dizajna moraju postojati detaljni planovi koji definišu rokove završetka preostalih faza sistema i samog sistema.
Treba predvideti potrebne resurse kod prelaza na novi sistem i probleme produkcije sistema i sl.
Moguće su promene takvih planova, ali ne promene arhitekture sistema.
Sve ove mogućnosti treba predvideti ugovorom ili su stva nove narudžbe tj. novog ugovora.