Uloga disciplinovanog pristupa

Objavljeno:

19.08.2012.

Kategorija:

Softverski Zahtevi



"The most important single aspect of software development is to be clear about what you are trying to build."

— Bjarne Stroustrup


Disciplinovani pristup

Primena discipline u analizi i specifikaciji softverskih zahteva se odnosi na slučajne poteškoće. Danas je prisutan generalni dogovor oko željenog pristupa kvalitetnom razvoju softvera, ali to polje nije dovoljno zrelo da taj pristup bude standardizovan. Bilo kako bilo, korisno je ispitati karakteristike idealizovanih procesa i njihovih produkta da bi se razumelo u čemu je trenutni pristup slab i koji trendovi imaju budućnost. U globalu, kompletan pristup zahtevima bi trebalo da definiše:


  • Proces: Delimično uređena sekvenca aktivnosti, ulaznih i izlaznih parametara za svaku aktivnost; koji radni produkt je proizveden u svakoj aktivnosti i koja vrsta ljudi bi trebalo da ga pravi.

  • Produkt: Radni produkti koje treba proizvesti i za svaki od njih potrebne informacije da bi se proizveli, informacije koje sadrži, očekivane posmatrače i prihvatljive kriterijume koje produkt mora da sadrži.


Trenutno ne postoji mnogo ujednačenosti oko dekompozcijie faze zahteva ili oko terminologije aktivnosti kod različitih autora. Uglavnom, ova faza se sastoji od dve konceptualno različite i preklapajuće aktivnosti, u smislu pvra dva cilja zahteva


  • Analiza problema: Cilj analize problema je da se precizno razume šta je problem koji treba da se reši. Ona sadrži identifikaciju tačne svrhe sistema, njegove korisnike, ograničenja prihvatljivih rešenja i moguće trgovine među ograničenjima u konfliktu.

  • Specifikacija zahteva: Cilj specifikacije zahteva je da se napravi dokument Specifikacija zahteva za softverom (SRS) koja tačno opisuje šta treba da se napravi. SRS obuhvata rezultate Analize problema i karakteriše skup prihvatljivih rešenja problema.


U praksi, razlika između ovih aktivnosti je pre konceptualna nego vremenska. Kada su obe faze potrebne, developer obično prelazi sa jedne na drugu. Kada su se problemi dobro razumeli, analiza praktično ne postoji, a kad su model sistema i dokumentacija standardizovani ili bazirani na postojećoj specifikaciji, dokumentacija diktira analizu.


Analiza problema

Analiza problema je obavezno neformalna jer ne postoji efketna zaokružena procedura koja garantuje uspeh. Radi se o prikupljanju informacija, sravnjivanju i strukutrnom procesu kroz koji se pokušava razumevanje svih različitih delova problema i njihovih odnosa. Teškoća da se razvije efetkno razumevanje velikih, kompleksnih softverskih problema je bila razlog da se alanliza struktuira i šifrira. Ili bar to pokuša.


Osnovni izazovi analize problema su:


  • - Kako prikupiti kompletan skup zahteva od klijenta ili iz drugih izvora?

  • - Kako razložiti problem u intelektualno shvatljive delove?

  • - Kako organizovati informacije da bi bile razumljive?

  • - Kako komunicirati o problemima sa drugim učesnicima?

  • - Kako razrešiti konfliktne potrebe korisnika?

  • - Kako znati kada je dosta?


Specifikacija zahteva – SRS (engl: Software Requirements Specification)

Za uspešan razvoj, efektivnost zahteva zvisi od toga koliko će SRS uhvatiti rezultate analize i koliko će specifikacija biti korisna. Nema smisla razvijati ono što nije efektivno iskomunicirano sa klijentima, dizajnerima, onima koji primenjuju, testerima i onima koji održavaju, a što je sistem veći i kompleksniji to uloga specifikacije postaje važnija. Ovo je posledica činjenice da SRS igra mnogo uloga


  • - SRS je primarni dokument za dogovor između developera i klijenta oko toga šta tačno treba da se napravi. To je dokument koji kontroliše klijent ili njegov zastupnik i često se koristi kao baza za ugovor.

  • - SRS je rezultat analize problema. Služi kao osnova da se odredi da li su zahtevi kompletni i da li još nešto treba da se analizira. Dokumentovanje analize dozvoljava da se pitanja o problemima postavljaju samo jednom u toku razvoja.

  • - SRS definiše koje osobine sistem mora da ima i ograničenja dizajna i implementacije, a definiše da li postoji sloboda u dizajnu ili ne. Pomaže da se obezbedi da se odluke o zahtevima donesu isključivo za vreme faze zahteva, a nikako za vreme programiranja.

  • - SRS je osnova za procenu cene i rokova. U pitanju je primarni alat menadžmentu za praćenje progresa razvoja i odlučivanja šta još treba da bude urađeno.

  • - SRS je baza za planiranje testiranja i osnovno je sredstvo šefu testiranja za određivanje prhvatljivog ponašanja softvera.

  • - SRS obezbeđuje standardnu definiciju očekivanog ponašanja za službu održavanja sistema i koristi se za dokumentovanje promena u inžinjerstvu.


Za disciplinovan razvoj softvera, SRS je primarna tehnička specifikacija softvera i glavni je dokument za kontrolu, koordinaciju i dokaz o razumevanju problema i sistema koji treba da se napravi.




FB Komentari: