Zašto su zahtevi teški - suštinske poteškoće

Objavljeno:

27.05.2012.

Kategorija:

Softverski Zahtevi



"The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification."

— Fred Brooks


Suštinske pošteškoće

Čak i kada detaljni ciljevi izgledaju prilično jasno, zašto toliko truda pri razvoju ne može da ih ispuni? Kratak odgovor bi bio da je ispunjenje zajedničkih ciljeva u praksi teško ostvarivo. Da bismo razumeli zašto, osvrnimo se na neke aspekte zbog kojih je teško praviti softverske sisteme i na razliku koja se pravi između suštinske problematike – one koja je ugrađena u problem i slučajne problematike – one koja je rezultat nesavršene prakse. Iako su zahtevi suštinski teški, ne postoji sumnja da se poteškoće umnožavaju neadekvatnom izradom.


Sledeće poteškoće postoje u svakom od ciljeva zahteva:


Razumevanje

Ljudi ne znaju šta žele od softvera. To ne znači da ljudi nemaju generalnu predstavu o onome čemu softver treba da služi. Više se radi o tome da oni ne počinju sa detaljnim razumevanjem koje funkcije pripadaju softveru, koji izlaz mora da se dobije za svaki postojeći ulaz, koliko treba da traju operacije, kako će jedna odluka uticati na druge itd. Zaista, ukoliko sistem nije prosta rekonstrukcija starog sistema, tako detaljno razumevanje ne može ni biti ostvareno. Mnoge odluke u vezi sa ponašanjem sistema će zavisiti od još nedonesenih i očekivanja će se menjati kako problem (i očekivani troškovi alternativnih rešenja) bude posjatajao razumljiviji. Da bi se kreirao efikasan dizajn i razvio tačan kôd potrebno je precizno i veoma detaljno razumevanje očekivanog ponašanja


Komunikacija

Softverski zahtevi su teški za efektivnu komunikaciju. Konceptualne strukture softverskih sistema su kompleksne, proizvoljne i teške za vizualizaciju. Veliki softverski sistemi koji se danas grade su među najkompleksnijim ljudskim ostvarenjima ikad pokušanim, a njihova kompleksnost je proizvoljna u smislu da su u pitanju ostavenja ljudskih odluka i predkonstrukcije pre nego odraz opipljivih osobina. Da stvar bude gora, većina konceptualnih struktura u softveru nema razumljivih analogona u fizičkom svetu, što ih čini još težim za vizualizaciju.


U praksi, razumevanje je teško ostvarivo zbog svih ovih ograničenja. Najbolje je da se radi sa običnim, predvidivim strutkurama jer možemo da razumemo samo ograničan broj inforamcija u jednom trenutku, a najveću količinu informacija možemo da razumemo tek kada ih vizualizujemo. Zato je zadatak razumevanja i prenošenja softverskih zahteva suštinski težak.


Suštinska teškoća komunikacije je pojačana različitošću potreba i čitalaca specifikacije zahteva. Idealna tehnička specifikacija je napisana za određenu vrstu čitaoca. Tačnost i razumljivost dokumenta zavisi od pretpostavki o uobičajenoj tehničkoj potkovanosti i upotrebi jezika. Takva uobičajenost ne postoji za mnoge različte grupe (na primer mušterije, inženjeri ili menadžeri) koje treba da koriste specifikaciju softverskih zahteva.


Kontrola

Suštinske poteškoće su prisutne i u kontroli razvoja softvera. Proizvoljnost i nevidljiva struktura softvera čini teškim da se uoči koji zahtevi mogu biti lako ostvareni a koji će probiti budžet i troškove ukoliko budu u potpunosti ispunjeni. Nizak nivo planiranja softvera je postao kliše, a softverski zahtevi su jedina osnova za planiranje i praćenje ostvarenja plana.


Mogućnost stalne izmene softvera čini kontrolu još težom! Od svih problema koji opsedaju softverske menadžere, malo ih je tako teških kao što je nošenje sa stalnim izmenama zahteva. Česte i proizvoljne promene za većinu sistema ostaju sastavni deo životnog ciklusa i posle početka upotrebe. Stalne promene čine izuzetno teškim razvoj stabilnih specifikacija, efektivnog planiranja i kontrolu troškova, a za developere je najkritičniji problem kako da se ophode prema promena softverskih zahteva.


Nerazdvojni odnosi

U potrazi za rešenjima tekućih problema, suočeni smo sa dodatnom poteškoćom da stavke ne mogu lako da se razdvoje i da se sa njima postupa korak po korak. Na primer, developeri su pokušavali da problemu promena zahteva pristupe tako što su zamrzavali zahteve pre početka dizajna, što se u praksi pokazalo nemogućim za razumevanje problema pošto klijent do kraja ne zna šta hoće dok to i ne vidi. Iz sličnih razloga, za različite svrhe i čitaoce se pišu posebne specifikacije, zbog čega se dešava da je potrebno napraviti čitav sistem specifikacija namenjen samo klijentima, potpuno drugi sistem tehničkih zahteva za interne potrebe razvojnog tima, itd. Bilo kako bilo ovakvo rešenje drastično povećava kompleksnost, ostavlja ogroman prostor za proizvoljnost i nedoslednost, a teškoće koje nastaju prilikom dodatnih izmena se umnožavaju.


Navedene stvari predstavljaju samo primer odnosa ugrađenih u različite aspekte problema sa zahtevima. Mnogo različitih strana zainteresovanih za zahteve sistema, mnogo različitih uloga koje one igraju u sistemu i međusobni uticaj konceptualnih struktura softvera utiču na zavisnost među odnosima i povećavaju konflikte među ograničenjima na svim mogućim nivoima.


Posledice su dvostruke. Prvo, ograničeni smo u primeni najefektivnije stragegije za reševanje kompleskih problema – podeli i vladaj. Ukoliko se problem posmatra izolovano, rešenje će verovatno prouzrokovati dodatne poteškoće. Za većinu poteškoća pri zahtevima efektivna rešenja moraju simultano da se odnose na više od jednog problema. Drugo, razvoj praktičnih rešenja zahteva komplikovane razmene. Kada različiti problemi imaju konflikte u ograničenjima, moraju se praviti kompromisi. Zato što razmene rezultuju različitim dobicima ili gubicima aktera uključenih u razmenu, efektivni kompromisi zahtevaju pregovore. Ove teme će biti detaljnije prodiskutovane kasnije.



FB Komentari: