109.451.880 pregleda lekcija
26.973 pregleda lekcija danas
490.649 pokretanja testova
1.538.118 pregleda pdf dokumenata
109.451.880 pregleda lekcija
26.973 pregleda lekcija danas
490.649 pokretanja testova
1.538.118 pregleda pdf dokumenata
U ovoj lekciji obradjivaćemo:
Slika 1.
Za većinu inženjerskih profesija, termin specifikacija odnosi se na dodelu numeričkih vrednosti ili ograničenja ciljevima dizajna proizvoda. Tipičan fizički sistem ima relativno mali broj ovih vrednosti. Tipičan softver ima veliki broj zahteva. Software requirements specification tipično se odnosi na kreiranje dokumenta ili elektronskog zapisa, koji se sistematično revidira, evaluira i poboljšava. Za kompleksne sisteme, kreiraju se i do tri dokumenta:
Requirements Specification obuhvata:
Dokument sistemske definicije je dokument za snimanje sistemskih zahteva. Alternativni nazivi su user requirements document ili concept of operations.
Definiše sistemske zahteve visokog nivoa, kao i sveobuhvatne ciljeve sistema u pozadini, radno okruženje, stavke o ograničenjima, pretpostavkama, nefunkcionalnim zahtevima. Može da uključi konceptualni model radi ilustracije konteksta sistema, kao i entitete, podatke, informacije i dijagrame. Standard IEEE Std 1362, Concept of Operations Document, daje uputstvo za pripremu ovog dokumenta.
Sistemi sa velikim softverskim i nesoftverskim komponentama (npr. moderan avion) imaju odvojene opise sistemskih zahteva od opisa softverskih zahteva. Na taj način specifikuju se sistemski zahtevi, dok se softverski zahtevi izvode iz sistemskih zahteva, pa se onda specificiraju zahtevi za softverske komponente. Strogo posmatrajući specifikacija sistemskih zahteva je aktivnost sistemskog inženjerstva, a ne softverskog inženjerstva.
Softverska specifikacija zahteva postavlja osnovu za kreiranje ugovora šta softverski proizvod treba da radi i šta nije predvidjeno da radi. Podrazumeva uključivanje i veza sa marketing službom. Radi razumljivosti netehničkim licima software requirements specification dokument često se nadopunjuje sa software requirements definition dokumentom. Softverska specifikacija zahteva podrazumeva rigoroznu proveru zahteva pre samog početka dizajna i izbegavanja kasnijeg redizajna. Obezbedjuje realističnu procenu troškova, rizika i rokova.
Slika 2.
Takođe, obezbedjuje osnovne informacije za transfer softverskog proizvoda novim korisnicima ili instalacije na novim mašinama. Često se piše koristeći formalne ili semi-formalne opise i notacije, izbor zavisi od potrebe preciznijeg opisa, što je važno kod bezbedonosnih softvera.
Softverska specifikacija zahteva dokument biće šire objašnjen u narednim lekcijama.
Podsetimo se još jednom šeme oblasti Software Requirements, (slika 3).
Slika 3. Podoblasti Software Requirements
Dokumenti iz tačke 5 predmet su validacije i verifikacije. Zahtevi se validiraju da bi se osiguralo da je softver inženjer razumeo zahteve i da bi se verifikovalo da dokument zahteva zadovoljava standard kompanije, da je razumljiv, konzistentan i kompletan. Više učesnika treba da revidira dokument, uključujući predstavnike kupaca i razvojnog sektora. Dokumenta zahteva su tema istog software configuration management-a kao i ostali ishodi procesa životnog ciklusa softvera. Uobičajeno je da se napravi raspored validacije u vidu definisanje više tačaka u procesu uzimanja zahteva. Cilj je otkriti probleme pre nego što se rasporede resursi u cilju njihovog zadovoljenja. Validacija zahteva je proces ispitivanja dokumenta zahteva da bi se osiguralo da definiše ispravan softver (onaj koji očekuje korisnik).
Validacija zahteva obuhvata:
Najčešći način validacije je inspekcija ili revidiranje dokumenta zahteva. Grupa revizora pregleda dokumente u potrazi za greškama, pogrešnim pretpostavkama, odstupanjima od uobičajene prakse i sl. Sastav grupe je takodje veoma važan, najmanje jedan predstavnik kupaca treba da bude uključen. Kreirase se čeklista po kojoj se vrši validacija.
Pregled može biti konstituisan sa ciljem kompletiranja:
IEEE Std 1028 obezbeđuje uputstvo za sprovodjenje ovakvih pregleda.
Prototyping je najčešći način za validaciju interpretacije softverskih zahteva od strane softver inženjera. Postoji više prototipskih tehnika i više tačaka u procesu gde je prikladna prototipska validacija. Prednost prototipa je što olakšavaju interpretaciju pretpostavki softver inženjera i daju koristnu povratnu inforamciju, npr. user interface se bolje razume kroz animacioni prototip nego kroz tekstualni opis.
Slika 4.
Postoje i nedostaci protitipa:
Mnogi stoga preporučuju da se vrsta prototipa realizuje ne preko softvera već npr. flip-chart-a.
Prototipovi mogu biti skupi za realizaciju, ali ako štede resurse u pokušajima zadovoljavanja odredjenih zahteva, svakako su troškovi opravdani.
Model Validation podrazumeva validaciju kvaliteta modela razvijenog tokom analize. Npr., u objektnom modelu poželjno je uraditi statičku analizu u cilju provere komunikacionih veza izmedju objekata.
Jedna od osobina softverskih zahteva je da bude moguće validirati da li ih finalni proizvod zadovoljava. Zahtevi koji se ne mogu validirati ostaju samo želje. Potrebno je isplanirati kako se verifikuje svaki zahtev, a jedan od načina je dizajniranje testa prihvatljivosti (acceptance tests). Dizajniranje testa prihvatljivosti može biti teško za nefunkcionalne zahteve i da bi bili validirani, moraju se analizirati do tačke gde mogu biti izraženi kvantitativno.
Proces prikupljanja zahteva proširuje se na ceo životni ciklus softvera. Upravljanje promenama i upravljanje zahtevima u stanju koje vodi do ispravne proizvodnje softvera ili već izgradjenog softvera, ključ je uspeha procesa softverskog inženjerstva. Tu se javlja se i najveći problem, jer nema svaka organizacija kulturu dokumentacije i upravljanja zahtevima. Često se u nedostatku resursa i vremena pregled dokumentacije zahteva zanemaruje. Dokumenta zahteva i upravljanje promenama su ključ uspeha svakog procesa uzimanja zahteva.
Praktična razmatranja obuhvataju:
U praksi je gotovo nemoguće implementirati proces prikupljanja zahteva kao linearan, deterministički proces gde se zahtevi izvlače, definišu, alociraju i predaju razvojnom timu. Perfektno shvatanje i razumevanje zahteva kada su u pitanju veliki projekti je teško izvodljivo. Zahtevi se iteriraju do nivoa kvaliteta i detalja koji su dovoljni za propuštanje na fazu dizajna. Neki zahtevi se izdvajaju kao osnovni i razmatraju do potpunog razumevanja, zbog rizika skupe ponove izvedbe, ako se problem pojavi kasnije tokom procesa izrade. U većini slučajeva razumevanje zahteva se stalno evaluira tokom dizajna i razvoja softvera.
Slika 5.
Revizija zahteva kasnije tokom životnog ciklusa je važan faktor. Značajna mera promena zahteva će se desiti, nekada zbog grešaka tokom analize, ali najviše zbog promena u okruženju.
Predstavlja centralno mesto za upravljanje zahtevima. Predstavlja opis uloge promena zahteva, procedura i analize koji se moraju primeniti za predložene promene. Ovaj proces najviše je vezan za oblast Software Configuration Management, što je posebna oblast u disciplini Softverskog inženjerstva.
Zahtevi se ne sastoje samo od specifikacija, već i od informacija koje pomažu da se upravljaju i interpretiraju zahtevi. Ovo uključuje i različite dimenzije klasifikacije (kao što je opisano u klasifikaciji zahteva) i verifikacionog metoda i prihvatanja test plana. Može da uključi i dodatne informacije, kao što su izvor svakog zahteva, istoriju promena i dr. Svaki zahtev treba da ima identifikator koji ga jednoznačno identifikuje.
Praćenje zahteva se bavi utvrdjivanjem izvora zahteva i predvidjanja efekata zahteva. Praćenje je fundamentalno za primenu analize kada se promeni zahtev. Zahtevi se često prosledjuju napred (onima koji ih kompletiraju - razvojni tim) i nazad (onima koji ih iniciraju). Često praćenje zahteva za tipičan projekat rezultuje formiranjem Directed Acyclic Graph (DAG) zahteva.
Često su nam potrebne i praktične merljive brojke zahteva za dati softverski proizvod. Brojevi se koriste i radi utvrdjivanja veličine promena u zahtevima, kao i proceni troškova razvoja ili odredjenog taska za održavanje. Jedna od tehnika za evaluaciju veličine zahteva je Functional Size Measurement (FSM). IEEE Std 14143.1 definiše koncept za FSM.
Reference
Copyright © LINK group. Sva prava zadržana.
office@link.co.rs, +381.11.7856 140, +381.11.7856 100
Cara Dušana 34, 11080 Zemun, Beograd, Srbija
Powered by LINK CMS.