ducin blog®:
kako to rade pravi majstori

Ima li programera u avionu

Teško da bi Vaš software mogao da se "vrti" u nekom od Sikorsky helikoptera. Još su manje šanse da Vas uposle da pišete software za medicinski uređaj (ko je rekao pacemaker). Da li treba da pominjem posledice eventualnog "unhandled exception-a"...

Ukoliko ipak želite da zante nešto o ovome, za početak, pogledajte ovde i ovde.

IEEE standard 830

O formalnoj verifikaciji i sličnim tehnikama ne mogu da Vas naučim. Međutim, mogu da Vam kažem šta je dobra inženjnerska praksa kada je u pitanju software. I ne samo praksa, već i standard i regulativa koji se odnose na mission critical aplikacije.

Ono što se nameće kao preduslov za primenu bilo kog standarda su dobro utvrđeni procesi razvoja i upravljanja zahtevima. O zahtevima je bilo reči, kao i o procesu razvoja. Međutim, dobra volja, često nije dovoljna. Prvi problem nastupa kada treba da se odredi šta su to zahtevi za jednu aplikaciju. Posebno, šta treba da sadrži dokument specifikacije zahteva.

Standard koji se posebno odnosi na zahteve i SRS je IEEE 830 standard. Po pitanju SRS-a, standard kaže sledeće:

• The SRS writer(s) should avoid placing either design or project requirements in the SRS.
• The SRS should not describe any design or implementation details.These should be described in the design stage of the project.
• The SRS should address the software product, not the process of producing the software product.

Implementing th IEEE  Software Engineering Standards

Kao što se vidi, mnogo jelakše definisati šta SRS ne treba da sadrži nego šta treba. Sličan pristup ima i autor knjige Implementing the IEEE Software Engineering Standards :

An SRS should not describe the software project or the software design. It should specify what the software shall do, not how the software shall do it, and not what the project team shall do.This is often a stumbling block for inexperienced SRS writers

Osim toga, dobar SRS dokument treba da ispuni nekoliko karakteristika: Da bude Korektan, Nedvosmislen, Kompletan i Konzistentan. Pojmove ne treba dodatno objašnjavati obzirom da su u velikoj meri sami po sebi jasni.

Bez obzira da li pišete software koji mora da zadovolji određenu regulativu, standardi mogu da budu od velike koristi. Nešto od onoga što je uslov za mission critical aplikacije svakako može da bude od koristi u svakodnevnom radu. Malo discipline ne može da škodi. U koliko Vas interesuje nešto više o  inženjerskim standardima svakako prelistajte Implementing the IEEE Software Engineering Standards.

Eric Sink on Requirements

 Eric je u svom poslednjem članku Requirements pokušao, da na veoma iscrpan način objasni šta su to zahtevi. Međutim, ovakav pristup boluje od "dečije bolesti". Onima koji ne znaju šta su to zahtevi, neće biti ništa jasnije kada pročitaju tekst. Jednostavno nema rešenja. Moraćete sami da naučite i to na teži način.

Ni sam Erick ne krije da dugo nije znao šta su to zahtevi. Ali to ni po čemu nije čudno. Pretpostavljam da danas 90% programera ne zna to isto. Ono što se provlačo kroz tekst je utisak nekoga ko je saznao "veliku tajnu".  Ne mogu da Vam otkrijem jednačinu svemira, ali  mogu da Vam kažem da se razvoj ne svodi na IDE i besomučno kodiranje.

Najzanimljiviji deo teksta je onaj u kome Eric opisuje nezgodnu situaciju sa jednim od svojih prethodnih šefova. Ako Vam situacija izgleda krajnje glupo, zapitajte se, sigurno ste se i Vi našli u sličnoj situaciji. Međutim, u svetu u kome vladaju arogancija i sujeta (mislim na programerski svet), ovo nije retka pojava. I sam sam bio akter bar dve slične situacije. Zato, kada sledeći put poželite da nekome razbijete glavau, prvim tuipim predmetom koji Vam padne pod ruku, zastanite. Možda ipak niste u prau.

Software Requirements

Kao što sam već govorio, većina softverskih projekata osuđena je na neuspeh. Najčešći razlog je loš postupak upravljanja zahtevima. Neretko se dešava da su zahtevi potpuno zanemareni. O tome kakve posledice to ima, bilo je reči. Stoga, danas, nešto više reči o zahtevima.

Software Requirements Specification

Bez obzira da li pravite operatini sistem, CAD aplikaciju, tekst procesor ili neki drugi software, nameću se iste potrebe. Prvo, treba precizno utvrditi zahteve, a onda i obezbediti proces upravljanja zahtevima. Kao krajnji rezultat ovih aktivnosti treba da se dobije specifikacija zahteva, tj. Software Requirements Specification. Pored same aplikacije koja se razvija, ovo je najvažnija komponenta čitavog projekta.Dokument specifikacije zahteva može da se čuva u bilo kojoj formi. Na papiru, kao tekstualni dokument, u obliku tabele ili u relacionoj bazi. Ipak, najbolje je da se za te potrebe koristi neki specijalizovani alat.

Kakvi sve zahtevi postoje

Postoji više tipova zahteva. Generalno, svaki zahtev može da se svrsta u jednu od dve kategorije: funkcionalni i nefunkcoinalni. Funkcionalni zahtevi, predstavljaju svaku funkciju sistema. Ove funkcije mogu da koriste kajnji korsnici ili pak drugi sistemi i podsistemi. Neki od primera su: proveri stanje na računu, podigni novac, pijavi ispit, štampaj račun, prosledi fakturu itd... Ono što ih karakteriše je specifičan oblik "glagol-imenica". Na taj način uvek ih je lako prepoznati.

Nefunkcionalni zahtevi opisuju karakteristike koje sistem treba da ima. Karakteristike mogu da se svrstaju u neku od sledećih kategorija: prenosivost, skalabilnost, bezbednost, privatnost, autentikacija, enkripcija, opterećenje... Neki od primera su sledeći: "Sistem mora da podrži minimum 100 istovremenih korisnika"; "Sistem treba da opsluži najamnje 1000 konkurentnih zahteva u sekundi"; "Svi lični podatci korsnika treba da se čuvaju u kriptovanoj formi" itd.

Zahtevi/Dizajn/Implementacija

Sistem može da se posmatra na više načina. Sa aspekta korisnika, projektanta, programera... Zahtevi predstavljaju sistema na konceptualnom nivou, odnosno onako kako ga korisnik vidi. Kao skup funkcija koje mu stoje na raspolaganjju. Dizajn je pogled na sistem iz ugla projektanta, tj. sistem na logičkom nivou. Skup objekata i akcija koje ti objekti obavljaju. Implementacija prikazuje sistem onako kako ga vidi programer. Skup klasa, funkcija, paketa, komponenata...

Svaki nivo može da se posmatra kao zaseban sloj sistema. Sloj zahteva je iznad sloja dizajna, koji je opet iznad sloja implementacije. Sloj na višem nivou potpuno određuje sloj na nižem. Sa druge strane sloj na nižem nivou ni na koji način ne sme da određuje sloj na višem nivou. To za posledicu ima da dizajn i implementacija ni na koji način ne smeju da utiču na zahteve. Rešenje je da se zahtevi predstave jezikom korsinika, te da se izostave bilo kakvi tehnički termini. Slede dva primera:

• Primer 1: Korsnik od sistema zahteva rasploživi iznos za trošenje. Sistem prikazuje stanje kojim korisnik raspolaže na računu.
• Primer 2: Korisnik bira odgovarajuću opciju padajućeg menija, desnim klikom miša. Zahtev se prosleđuje do SQL servera koji čuva informacije o računima korisnika. Poziva se uskladištena procedura....

Prethodna dva primera predstavljaju dve očigledne suprotnosti. Prvi primer je odličan primer jednog funkcionalnog zahteva. Korišćen je samo rečnik korisnika. Ne pretpostavlja se ništa o načinu na koji korisnik stupa u interakciju sa sitemom. Pritiskom na neki od tastera ATM-a, ili izborom opcije na touch-screenu. O tome da li se stanje prikazuje na ekranu ili se štampa račun. Ne govori se ništa ni o tome kako su realizovane ove funkcije. Korisnika ne interesuje način na koji sistem funkcioniše Interesuje ga samo krajnji benefit, informacija o raspoloživom stanju.

Drugi primer je potpuna suprotnost. Ovde su napravljene sve greške, koje je bilo moguće napraviti. Pretpostavlja se da sistem koristi grafički interfejs i padajuće menije. Da se u interakciji sa sistemom korsnik služi mišem. Nameđe se ograničenje da se podatci o korisniku čuvaju u bazi podataka, te da postoji poseban server za tu namenu. Pominju se i uskladištene procedure... Na ovaj način zahtevi su "zaprljani" pretpostavkama o dizajnu i implementaciji. To dovodi do toga da korisnik ne razume opisane funkcija sistema, pa ni ne učustvuju u procesu. Sistem, sa druge strane, postaje potpuno nefleksibilan i ograničen nametnutim rešenjima.

Wearing multiple hats

Za "zamenu šešira" ne postoji neki adekvatan prevod na naš jezik. Bilo kako bilo, sposobnost da menjate šešir na svojoj glavi može da bude presudna u procesu razvoja. O čemu se zapravo radi. U kontekstu ove priče, to znači da prilikom pisanja zahteva treba da nosite šešir krajnjeg korsnika aplikacije. Pitanje je ŠTA, a ne KAKO. Tajna je u veštini da mentalni kontekst prilagodite trenutnoj fazi razvoja. Kao što zante, context switch je jako skupa operacija. Posebno kada je procesor sačinjen od ćelija sive mase.

Dobra vest je da sa stavljanjem programerskog šešira retko ko ima problema.

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