ducin blog®:
kako to rade pravi majstori

Kako do kvalitetnog softvera?

Svako ko se iole ozbiljno bavio razvojem software-a, iskusio je frustraciju koju skoro savaki takav pokušaj nosi sa sobom. Paralisanost, osećaj beskorisnosti, odsustvo motivacije, dezorijentisanost,... jednom reči potpuno ludilo. Onaj ko tvrdi da bar jednom nije doživeo neko od ovih psihička stanja, ili je dobar lažov, ili se nikada nije bavio razvojem software-a(ne računam množenje dve matrice u Pascal-u).

No Silver Bullet

Zašto je tako teško napraviti kvalitetan software? Ne samo da je postupak razvoja inherentno složen. On i dodatno može da bude otežan primenom, ili bolje reći neprimenom adekvatnih tehnika i alata. Za prvi problem, za sada, rešenje ne postoji. Šta više, postoji pretpostavka da uopšte i ne može da bude rešen(hint:No Silver Bullet). Dok svaki programer ne dobije spinalni implant i mogućnost da svoje misli materijalizuje kao gotovu aplikaciju, ostaje nam da se pozabavimo drugim problemom.

Pitanje koje alatke(čitaj programski jezik i IDE), ostaviću za neki drugi put. Da skratim muke. Svako treba da koristi onaj alat koji najbolje poznaje. Tačka. Što se tiče drugog aspekta ove priče, tu postoji prostor za značajna poboljšanja. Međutim, problem je što većina programera nikada nije ni čula za nešto što se zove Application Lifecycle ili Software Development Process. Onima koji su i čuli, ne pada na pamet da promene svoje loše programerske navike. Uobičajeni pristup je da se novi projeka počinje momentalnim pokretanjem editora i prelaskom na kodiranje. Proces razvoja postaje Chaotic Application Development. Rezultat je bugovit i generalno nekvalitetan software. Software koji ne ispunjava zahteve korisnika i u krajnjem slučaju nema nikakvu upotrebnu vrednost.

Application Lifecycle

Da bi se u čitavu zbrku uveo kakav takav red potreban je proces. Proces kroz koji prolazi aplikacija u toku razvoja. Drugačije rečeno, dobro utvrđen niz koraka i aktivnosti koje treba primeniti. Rezultat takvog jednog postupka treba da bude kvalitetan i pouzdan proizvod. Ovo ne mora da bude neki formalan proces kao što je Microsoft Solution Framework ili Rational Unified Process. To može da bude i neki uobičajeni postupak, koji se do sada pokazao kao dobra proaksa.

Faze razvoja

Koraci i potrebne radnje jednog procesa obično su grupisane u veće celine, faze razvoja. Ovako, faze definišu životni vek, tj. lifecycle aplikacije. Primeri nekih od faza su:

• planiranje,
• analiza,
• dizajn,
• implementacija,
• kodiranje,
• testiranje,
• održavanje,
• podrška...

Već iz samih naziva može dosta toga da se nasluti(ko je rekao waterfall). Ovde se dolazi i do onog najbitnijeg u celoj priči. Većina softwareskih projekata je neuspešna ili nikada i ne ugleda svetlost dana, upravo šzato to su neke ili skoro sve od ovih faza potpuno zanemarene. Razlog je obično nedovoljno iskustvo, nedostatak vremena ili novca, ili jednostavno nespremnost da se uvedu novine u proces razvoja. Čitav proces, u manjoj ili većoj meri, svodi se na fazu implementacije.

Requirements Specification

Bez obzira na konkretan proces koji se primenjuje, najbitnija faza razvoja je faza analize i specifikacije zahteva. Tokom ove faze, na osnovu postojećih poslovnih procesa ili načina rada određuju se zahtevi koje aplikacija treba da ispuni. Kao rezultat postupka nastaje specifikacija zahteva(Software Requirements Specification). Specifikacija zahteva dalje "vozi" čitav proces razvoja. Tako ona određuje dizajn, implementaciju, test primere... Za svaki deo dizajna, koda ili testa može da se utvrdi na koji zahtev se odnosi. Ova karakteristika zove se requirrment traceability.

Zanemarivanjem ove faze ugrožava se čitav dalji razvoj. Kao posledica javljaju se sledeći "simptomi":

• Odsustvo komunikacije među članovima razvojnog tima. Svako u glavi ima sopstvenu sliku onoga što se pravi. Članovi tima, računaju na telepatske sposobnosti svojih kolega. Ovakav pristup se u praksi pokazao kao krajnje neefikasan.
• Odsustvo komunikacije prema kupcima i korisnicima aplikacije. Akcenat se takođe stavlja na telepatske veštine. Ponekad i na intelektualnu inferiornost krajnjih korisnika. Rezultat je da razvojni tim ne rešava problem koji kupci imaju. Obično rešava problem koji uopšte ne postoji.

Kao rezultat svega dolazi do kašnjenja i produžetka razvoja u beskonačnost. Aplikacija koja se razvija nema trašene funkcije, već ima gomilu nepotrebnih funkcija. Ovaj scenario zvuči jako poznato. Postoji velika šansa da se nekada desio baš Vama. Rešenje problema je precizno definisanje zahteva.

Postavlja se pitanje kako uspešno definisati i upravljati zahtevima. Kao primedbe obično se čuju sledeći komentari: "Ko još ima vremena da piše 500 stranica zahteva?"; "Ili, još gore, da čita sve te gluposti?"; "U našem timu odavno smo odustali od pisanja zahteva. Korisnici i onako ne znaju šta žele"; "Ono što mi radimo najbolje je za naše kupce."

Use Case Approach

Pristup koji u poslednje vreme sve više dobija na popularnosti je pisanje Use Case-ova. Ovo je efikasan alat, koji uspostavlja dobru komunikaciju među svim učesnicima u procesu razvoja. Ali nešto detaljnije o specifikaciji zahteva i Use Case-ima u nekom od narednih tekstova. U međuvremenu, samo ću podstaći na razmišljanje. Za specifikaciju prosečne aplikacije potrebno je ne više od 20-30 Use Case-a. Teško je zamisliti projekat koji ih ima stotinu. O mogućnostima primene Test Driven Development-a da i ne govorim. ...izgleda da sam pronašao svoj srebrni metak