Upload
ariana-snider
View
65
Download
0
Embed Size (px)
DESCRIPTION
PROCESI INŽENJERSTVA ZAHTJEVA (ili kako generirati specifikaciju) Generičke aktivnosti u programskom inženjerstvu: Specifikacija (temeljem analize zahtjeva) Razvoj i oblikovanje Validacija i verifikacija Evolucija. PROCESI INŽENJERSTVA ZAHTJEVA - PowerPoint PPT Presentation
Citation preview
1
PROCESI INŽENJERSTVA ZAHTJEVA(ili kako generirati specifikaciju)
Generičke aktivnosti u programskom inženjerstvu:• Specifikacija (temeljem analize zahtjeva)• Razvoj i oblikovanje• Validacija i verifikacija• Evolucija
2
PROCESI INŽENJERSTVA ZAHTJEVA
Proces u općem smislu je strukturiran (organiziran) skup aktivnosti koji vodi nekom cilju.
Proces inženjerstva zahtjeva je skup aktivnosti koje generiraju i dokumentiraju zahtjeve.
U ovoj prezentaciji naglasak je na:
• Opisu temeljnih aktivnosti u procesima zahtjeva i njihovih odnosa.
• Upoznavanje s tehnikama za izlučivanje i analizu zahtjeva.
• Opisu validacije zahtjeva i uloge recenzenta.
• Analizi upravljanja zahtjevima (engl. requirements management).
3
PROCESI I MODELI INŽENJERSTVA ZAHTJEVA
Procesi koji su u uporabi u inženjerstvu zahtjeva razlikuju se ovisno o domeni primjene, ljudskim resursima i organizaciji koja oblikuje zahtjeve.
Nema jedinstvenog procesa inženjerstva zahtjeva!
U okviru svakog procesa postoje:
generičke aktivnosti inženjerstva zahtjeva
(različito od generičkih aktivnosti programskog inženjerstva)
• Studija izvedivosti (engl. feasibility study)
• Izlučivanje (otkrivanje) zahtjeva (engl. requirements elicitation), analiza i specifikacija.
• Validacija zahtjeva
• Upravljanje promjenama u zahtjevima
4
PROCESI I MODELI INŽENJERSTVA ZAHTJEVA
Procesi inženjerstva zahtjeva mogu se predstaviti modelima koji
opisuju kako se ti procesi provode.
Dva su uobičajena modela procesa inženjerstva zahtjeva:
• klasični
• spiralni
5
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
KLASIČNI MODEL PROCESA INŽENJERSTVA ZAHTJEVA
Aktivnosti
Produkti
Studija izvedivosti
Izlučivanje i analiza
Specifikacija zahtjeva
Validacija zahtjeva
Dokument zahtjeva
Korisnički zahtjevi i zahtjevi sustava
Modeli sustava iteracije
iteracije
6
Requirementsspecification
Requirementsvalidation
Requirementselicitation
System requirementsspecification and
modeling
Systemrequirements
elicitation
User requirementsspecification
Userrequirements
elicitation
Business requirementsspecification
Prototyping
Feasibilitystudy
Reviews
System requirementsdocument
SPIRALNI MODEL PROCESA INŽENJERSTVA ZAHTJEVA
Izlučivanje Validacija
Specifikacija
Izrada prototipa
Revizije
Zahtjevi sustava i modeliranje.
Korisnički zahtjevi.
Poslovni zahtjevi.
Izlučivanje zahtjeva sustava
Izlučivanje korisničkih zahtjeva.
Studija izvedivosti
Konačan dokument zahtjeva
7
Spiralni model inženjerstva zahtjeva
• Tro-stupanjska aktivnost (specifikacija, validacija, izlučivanje).
• Promatra proces inženjerstva zahtjeva kroz iteracije ciklusa svih njegovih generičkih aktivnosti
• To je razlika u odnosu prema klasičnom modelu, gdje se ne ponavlja cijeli ciklus!
• U svakoj iteraciji je različit intenzitet aktivnosti. U ranim iteracijama fokus na razumijevanju poslovnog modela, u kasnijima modeliranje sustava.
• Zahtjevi se u pojedinim iteracijama specificiraju s različitom razinom detalja.
8
DETALJAN PRIKAZ GENERIČKIH AKTIVNOSTI U PROCESU INŽENJERSTVA ZAJTHEVA
• Studija izvedivosti
• Izlučivanje, analiza i specifikacija zahtjeva (ovo je najznačajniji dio)
• Validacija zahtjeva
• Upravljanje promjenama u zahtjevima
9
STUDIJA IZVEDIVOSTI (engl. feasibility study)
Studija izvedivosti na početku procesa inženjerstva zahtjeva određuje da li se predloženi sustav isplati (tj. da li je vrijedan uloženih sredstava). Ulazna informacija je preliminaran skup zahtjeva poslovnog procesa.
To je kratka fokusirana studija koja u pisanom dokumentu provjerava i odgovara na pitanja:
• Da li sustav doprinosi ciljevima organizacije u koju se uvodi?
• Da li se sustav može izvesti postojećom tehnologijom i predviđenim sredstvima?
• Da li se predloženi sustav može integrirati s postojećim sustavima organizacije u koju se uvodi?
10
PROVEDBA STUDIJE IZVEDIVOSTI
Temelji se na određivanju koje informacije su potrebne za studiju, prikupljanje informacija i pisanju izvješća.
Pitanja za ljude u organizaciji:
• Što ako se sustav ne implementira?
• Koji su trenutni problemi procesa organizacije?
• Kako bi predloženi sustav pomogao u poboljšanju procesa?
• Koji se problemi mogu očekivati pri integraciji novoga sustava?
• Da li je potrebna nova tehnologija ili nove vještine?
• Koje dodatne resurse organizacije traži implementacija novoga sustava?
11
DETALJAN PRIKAZ GENERIČKIH AKTIVNOSTI U PROCESU INŽENJERSTVA ZAJTHEVA
• Studija izvedivosti
• Izlučivanje, analiza i specifikacija zahtjeva (ovo je najznačajniji dio)
• Validacija zahtjeva
• Upravljanje promjenama u zahtjevima
12
IZLUČIVANJE I ANALIZA ZAHTJEVA(najznačajnija aktivnost u procesu inženjerstva zahtjeva)
• Općenito (dionici, problemi, modeli, aktivnosti, pogledi).
• Metode u izlučivanju i analizi zahtjeva:
• Intervjuiranje kao metoda izlučivanja.
• Scenarij kao metoda izlučivanja.
• Izlučivanje i specificiranje zahtjeva obrascima uporabe (UML “use_cases”).
• Specificiranje dinamičkih interakcija u sustavu (UML sekvencijski dijagrami).
13
OPĆENITO O IZLUČIVANJU I ANALIZI ZAHTJEVA
Poznato i kao izlučivanje (engl. elicitation) zahtjeva ili otkrivanje (engl. discovery) zahtjeva.
• Uključuje stručno tehnički obrazovano osoblje koje u zajedničkom radu s kupcima razjašnjava domenu primjene, definira usluge koje sustav treba pružiti, te određuje ograničenja u radu sustava.
• Može uključivati: krajnje korisnike sustava, rukovoditelje, inženjere uključene u održavanje sustava, eksperte domene primjene, predstavnike sindikata i sl.
• Svi se oni nazivaju dionici (engl. stakeholders).
14
Requirementsclassification and
organisation
Requirementsprioritization and
negotiation
Requirementsdocumentation
Requirementsdiscovery
SPIRALNI MODEL IZLUČIVANJA I ANALIZE ZAHTJEVA
Početak:
Izlučivanje (otkrivanje) zahtjeva
Klasifikacija i organizacija zahtjeva
Ustanovljavanje prioriteta i pregovaranje
Dokumentiranje zahtjeva
15
AKTIVNOSTI U SPIRALI IZLUČIVANJA I ANALIZE ZAHTJEVA
Izlučivanje (otkrivanje) zahtjeva
Interakcija s dionicima s ciljem otkrivanja njihovih zahtjeva. Zahtjevi domene primjene se također definiraju na ovom stupnju. Izvori informacija su dokumenti, dionici, slični sustavi.
Klasifikacija i organizacija zahtjeva
Grupiraju se srodni zahtjevi i organiziraju u koherentne grozdove (klastere).
Ustanovljavanje prioriteta i pregovaranje
Zahtjevi se razvrstavaju po prioritetima i razrješavaju se konflikti.
Dokumentiranje zahtjeva
Zahtjevi se dokumentiraju (formalnim i neformalnim dokumentima) i ubacuju u sljedeći ciklus spirale.
16
PROBLEMI U IZLUČIVANJU I ANALIZI ZAHTJEVA
• Dionici ne znaju što stvarno žele (teško artikuliraju zahtjeve, ili su zahtjevi nerealni s obzirom na cijenu).
• Dionici izražavaju zahtjeve na različite, njima specifične načine (posjeduju implicitno znanje o svojem radu - domeni).
• Različiti dionici mogu imati konfliktne zahtjeve i izražene na različite načine.
• Organizacijski i politički faktori mogu utjecati na zahtjeve (npr. rukovoditelj traži da uvedeni sustav ima značajke koje povećavaju njegov utjecaj u organizaciji).
• Zbog dinamike ekonomskog i poslovnog okruženja zahtjevi se mijenjaju za vrijeme procesa analize.
• Uz promjenu poslovnog okruženja pojavljuju se novi dionici s novim, specifičnim zahtjevima.
17
PRIMJER različitih dionika za npr. Sustav bankomata:
• Bankovni klijenti
• Predstavnici drugih banaka
• Bankovni rukovoditelji (engl. manager)
• Šalterski službenici
• Administratori baza podataka
• Rukovoditelji sigurnosti
• Marketing odjel
• Inženjeri održavanja sustava (sklopovlja i programske potpore)
• Regulatorna tijela za bankarstvo
18
POGLEDI (engl. viewpoints)Različiti dionici imaju različitu perspektivu i fokus na zahtjeve.
Pogledi su način strukturiranja zahtjeva tako da oslikavaju perspektivu i fokus različitih dionika.
Ova više-perspektivna analiza omogućuje razrješavanje konflikata.
Tipovi pogleda
Pogledi interakcije (Ljudi i drugi sustavi koji izravno komuniciraju sa sustavom. Primjer bankomata: klijenti i korisnička baza podataka).
Indirektni pogledi (Dionici koji ne koriste sustav izravno, ali utječu na zahtjeve. Primjer bankomata: rukovoditelji i osoblje zaduženo za sigurnost).
Pogledi domene primjene (Karakteristike domene i ograničenja koja utječu na zahtjeve. Primjer bankomata: standardi u komunikaciji između banaka).
19
Articleproviders
FinanceLibrarymanager
Librarystaff
Users
InteractorIndirect
All VPs
Classificationsystem
UIstandards
Domain
ExternalStaffStudents CataloguersSystem
managers
POGLEDI U PRIMJERU SUSTAVA KNJIŽNICE
(ranije naveden hipotetski sustav LIBSYS)
Svi pogledi
Indirektni InterakcijaDomena primjene
20
METODE U IZLUČIVANJU I ANALIZI ZAHTJEVA
• Intervjuiranje
• Scenarij
• Obrasci uporabe (engl. use case)
• Dijagrami interakcija (sekvencijski dijagrami)
21
INTERVJUIRANJE kao metoda izlučivanja zahtjeva
U formalnom i neformalnom intervjuiranju tim zadužen za inženjerstvo zahtjeva ispituje dionike o sustavu koji trenutno koriste te o novo predloženom sustavu.
TIPOVI INTERVJUA:
Zatvoreni intervju u kojem se odgovara na skup prije definiranih pitanja.
Otvoreni intervju u kojem ne postoje definirana pitanja, već se niz pitanja otvara i raspravlja s dionicima.
U praksi intervjui ne daju dobre rezultate za zahtjeve domene primjene jer inženjeri zahtjeva ne razumiju specifičnu terminologiju domene, a eksperti domene toliko poznaju te zahtjeve da ih ne artikuliraju (misle da su svima razumljivi sami po sebi).
22
SCENARIJI kao metoda izlučivanja zahtjeva
Scenariji su primjeri iz stvarnog života o načinu korištenja sustava. Tijekom izlučivanja zahtjeva dionici diskutiraju i kritiziraju scenarij.
Scenariji trebaju sadržavati:
• Opis početne situacije.
• Opis normalnog (standardnog) tijeka događaja.
• Opis što se eventualno može dogoditi krivo.
• Informaciju o paralelnim aktivnostima.
• Opis stanja gdje scenarij završava.
23
Primjer scenarija za sustav LIBSYS (1):
Početno stanje
• Korisnik se prijavio ("logirao") u LIBSYS sustav, i locirao časopis u kojem se nalazi željeni članak.
Normalan rad
• Korisnik selektira članak za kopiranje. Sustav traži od korisnika informaciju o njegovim pravima (tip pretplate) ili načinu plaćanja. Opcije plaćanja su kreditna kartica ili račun organizacije koja ima pretplatu.
• Sustav traži da korisnik potpiše formular o pravima na kopiranje i ostalim detaljima transakcije. To se upisuje u LIBSYS.
• Formular o pravima na kopiranje se provjerava, i ako je OK članak u PDF formatu se prosljeđuje do korisničkog računala u sklopu LIBSYS sustava. Korisnik treba odabrati pisač i kopija članka se ispisuje. Ukoliko je članak tipa “samo za ispis”, članak se briše s korisničkog računala nakon što korisnik potvrdi da je ispis završen.
24
Primjer scenarija za sustav LIBSYS (2):
Što može poći po krivu
• Korisnik nije ispravno popunio formular o pravima na kopiranje. Formular se mora ponovo dati korisniku na ispravak. Ako je ponovljeni formular krivo ispunjen, zahtjev korisnika se odbacuje.
• Sustav može odbaciti način plaćanja i zahtjev se odbacuje.
• Prijenos članka na korisnikovo računalo nije ispravno izveden. Prijenos se ponavlja ili dok korisnik ne prekine transakciju.
• Članak nije moguće ispisati. Ako članak nije tipa “za ispis” drži ga se u radnom prostoru LIBSYS sustava, a u suprotnom članak se izbriše i korisniku se naplaćuje cijena članka.
Paralelne aktivnosti
• Prijenos i obrada zahtjeva drugih korisnika LIBSYS sustava.
Završno stanje
• Korisnik i dalje na sustavu. Ako je članak “za ispis”, briše se.
25
METODE U IZLUČIVANJU I ANALIZI ZAHTJEVA
• Intervjuiranje
• Scenarij
• Obrasci uporabe (engl. use case)
• Dijagrami interakcija (Sekvencijski dijagrami)
26
METODA IZLUČIVANJA ZAHTJEVA OBRASCIMA UPORABE (engl. use cases)
Obrasci uporabe predstavljaju metodu preuzetu iz UML standarda. Temeljeni su na ideji scenarija. Skup obrazaca uporabe opisuje sve moguće interakcije sustava.
Uz obrasce uporabe, dodatno se mogu koristiti i drugi dijagrami iz UML sustava (npr. sekvencijski dijagrami kako bi se detaljno opisao dinamički tijek događaja.
U nastavku, koristit će se prezentacija:
Introduction to UML: Use CasesCris KobrynCo-Chair UML Revision Task ForceNovember 2000
Što je modeliranje obrascima uporabe?
• Model obrazaca uporabe je pogled koji ističe ponašanje sustava kako ga vide vanjski korisnici.
• Model obrazaca uporabe razdjeljuje funkcionalnost sustava u transakcije (“obrasce uporabe”) razumljive korisnicima (“aktorima”).
• Tri temeljna elementa u modelima obrazaca uporabe su: obrasci uporabe (engl. use cases), aktori i odnosi (relacije, engl. relations) među njima.
27
Modeliranje obrascima uporabe: jezgreni elementi
28
Konstrukt Opis Sintaksa
Obrazac uporabe (use case)
Akcija (uključujući varijante) koje sustav ili drugi entitet obavlja u interakciji s aktorima sustava.
Aktor (actor)
Koherentan skup uloga koje imaju korisnici u interakciji s obrascima uporabe.
Granica sustava (system boundary)
Predstavlja granicu između fizikalnog sustava i različitih aktora koji su u interakciji s fizikalnim sustavom.
UseCaseNam e
ActorNam e
Naziv akcije
Ime aktora
Modeliranje obrascima uporabe: jezgreni odnosi
29
Konstrukt Opis Sintaksa
Pridruživanje (association)
Sudjelovanje aktora u obrascu uporabe, tj. komunikacija instancije aktora i instancije obrasca uporabe.
Proširenje (opcionalno, specifično) (extend)
Odnos od proširene uporabe do osnovne uporabe (engl. base case). Specificira kako se ponašanje za proširen obrazac uporabe može umetnuti u ponašanje definirano osnovnim obrascem uporabe.
Generalizacija (generalization)
Oznaka za odnos između općeg i specifičnog (aktora ili obrasca uporabe).
<<extend>>
Modeliranje obrascima uporabe: jezgreni odnosi
30
Construct Description Syntax
Uključivanje u cjelosti (include)
Odnos (relacija) od osnovnog obrasca do uključenog obrasca. Specificira ponašanje uključenog obrasca u odnosu na osnovni obrazac uporabe. Osnovni obrazac sadrži ponašanje definirano u drugom obrascu.
<<include>>
(crtkana ili puna strelica često nisu u konzistentnoj uporabi, u kolegiju se neće inzistirati na razlici)
Dijagram obrazaca uporabe (engl. use case)
• Pokazuje obrasce uporabe, aktore i njihove odnose.• Detalji unutar dijagrama obrazaca uporabe mogu se
predstaviti tekstom ili dodatnim dijagramima interakcije između elemenata sustava.
• Vrste obrazaca uporabe:– Dijagram – temeljni i najznačajniji– Tekstovni opis – često kao dodatak uz dijagram
31
Dijagram obrazaca uporabe (samo koncepti)
32
Fig. 3-44, UML Notation Guide
Customer
Supervisor
SalespersonPlace
Establishcredit
Check
Telephone Catalog
F ill orde rs
Shipping Clerk
status
order
Granica sustava
Aktori
Obrazac uporabe
Odnosi
Relacije u obrascima uporabe (obratiti pažnju na smjer strelica)
33
Fig. 3-45, UML Notation Guide
additional requests :
OrderProduct
SupplyArrange
«include»«include»«include»
RequestCatalog
«extend»Extension points
PaymentCustomer Data
after creation of the order
Place Order
1 * the salesperson asks forthe catalog
Točke proširenja
Naruči
Naruči proizvod Uredi plaćanjeDobavi podatke o kupcu
Zahtijeva katalog
Place Order uključuje ova ponašanja u cijelosti
proširenje akcije
34
Spojnica u obrascima uporabe može opcijski imati višestrukost (engl. multiplicity values) na svakom kraju.
Na slici klijent može imati najviše jednu isplatu u jednom času, ali banka može imati po volji brojnost transakcija (klijenata koji istovremeno obavljaju isplatu).
nula ili jedan nula ili više
jedan
VIŠESTRUKOST (brojnost) u obrascima uporabe
isplata
Odnosi između aktora
35Fig. 3-46, UML Notation Guide
EstablishCredit
PlaceOrder
Salesperson
Supervisor
1 *
1 *
Generalizacija (dopušta se i između obrazaca uporabe)
višeProdavatelj
Nadzornik
Naruči
Odobri kredit
Tekstovni obrazac uporabe – Npr. promjena avio leta
36
Aktori: putnik, baza računa klijenta (s planom puta), rezervacijski sustav avio kompanije, sučelje prijave (engl. booking system)
Preduvjeti: Putnik se prijavio na sustav i odabrao opciju “promjena leta”.
Temeljni tijek transakcija Sustav dohvaća putnikov bankovni račun i plan puta iz baze. Sustav pita putnika da odabere dio plana puta koji želi mijenjati; putnik odabire segment puta. Sustav pita putnika za novu odlaznu i dolaznu destinaciju; putnik daje traženu informaciju. Ako je let moguć, tada … … Sustav prikazuje sažetak transakcije..
Alternativni tijek transakcija Ako let nije moguć, tada …
Kada modelirati obrascima uporabe
• Obrascima uporabe modelirati korisničke zahtjeve.• Obrascima uporabe modelirati scenarije ispitivanja sustava
(engl. test scenarios).
• Ako se koristi metoda oblikovanja programske potpore zasnovana na obrascima uporabe– Započne se s obrascima uporabe i iz njih se izvedu
strukturni i ponašajni (engl. behavioral) modeli sustava.• Ako se ne koristi metoda oblikovanja programske potpore
zasnovana na obrascima uporabe– Mora se osigurati da su obrasci uporabe sustava
konzistentni sa strukturnim i ponašajnim modelima.
37
38
Preporuke u oblikovanju obrazaca uporabe
• Svaki obrazac uporabe mora sadržavati značajan dio uporabe sustava i biti razumljiv ekspertima domene i programerima.
• Ako se obrasci uporabe definiraju tekstom, sve imenice i glagole trebaju se koristiti razumljivo i konzistentno kako bi se kasnije mogli definirati ostali (UML) dijagrami.
• Ako su obrasci uporabe uključeni u bazni obrazac, koristi <include>. Važno je napomenuti da se uključeni obrazac ne mora nužno izvesti.
• Ako su obrasci uporabe kompletirani a postoje opcije u obliku dodatnih obrazaca koji se izvode pod točno određenim uvjetima, koristi <extend>.
• Dijagram obrazaca uporabe treba sadržavati obrasce uporabe jednake apstraktne razine.
• Uključiti samo zaista potrebne aktore.
• Veliki broj obrazaca uporabe treba organizirati u posebne odvojene dijagrame i pakete.
Primjer: Upravljanje ljudskim resursima - dijagram
39
Online HR System
LocateEm ployees
UpdateEm ployee
Profile
Update Benefits
Access TravelSystem
Access PayRecords
Em ployee
M anager
Healthcare Plan System
{if currentMonth = O ct.}
{readOnly}
Insurance P lan System
“on-line” sustav za upravljanje ljudskim resursima
Zaposlenik
Upravitelj
Zdravstveni plan
Plan osiguranja
Osvježi pogodnosti
Istaknuti obrazac je:
Primjer: Upravljanje ljudskim resursima Akcija - “osvježi pogodnosti”
40
Update M edicalP lan
Update DentalP lan
Update Benefits______________Extension pointsbenefit options:
after required enrollm ents
UpdateInsurance P lan
Em ployee
<<include>> <<include>> <<include>>
ElectReim bursem entfor Healthcare
Elect StockPurchase
<<extend>>em ployee requestsstock purchase option
<<extend>>em ployee requestsreim bursem ent option
extensioncondition
extension pointname andlocation
Točka proširenja
Uvjet proširenja
Osvježi pogodnosti
Zaposlenik
Opcija kupnje dionica
Nadoknada troškova
Osvježi plan osiguranja
Osvježi zubnu zaštituOsvježi plan zdravstvene zaštite
Tekstovni opis: “Osvježi pogodnosti” (engl. Update Benefits) obrazac uporabe
41
Aktori: zaposlenik, baza računa zaposlenika, sustav zdravstvene zaštite, sustav (zdravstvenog) osiguranja.
Preduvjeti: Zaposlenik se prijavio na sustav i odabrao opciju: ‘update benefits’.
Temeljni slijed: Sustav dohvaća zaposlenikov račun iz baze. Sustav traži da zaposlenik odabere tip plana zdravstvene zaštite; include Update Medical Plan. Sustav traži da zaposlenik odabere tip plana zubne zaštite; include Update Dental Plan. …
Alternativni slijed: Ako tip plana zdravstvene zaštite kojeg je zaposlenik odabrao nije ponuđen u njegom mjestu stanovanja, sustav traži odabir drugog plana zaštite.
42
Medical clinic diagram
Točka proširenja
činovnik
Sustav za određivanje termina
Odgoda plaćanjaPlati račun
Zatraži lijek
Dogovori pregled
Otkaži pregled
Provjeri karton pacijenta
Uoči generalizaciju između obrazaca
43
ZAKLJUČCI o UML obrascima uporabe kao metodi izlučivanja i analize zahtjeva
• UML dijagrami i tekstualni opisi obrazaca uporabe modeliraju funkcionalne zahtjeve sustava s aspekta korisnika.
• Temeljeni su na ideji scenarija.
• Služe za izlučivanje zahtjeva prema pogledu interakcije.
• Pogodni su za modeliranje velikih i složenih programskih produkata.
• Jednostavni su za razumijevanje ali posjeduju i napredne značajke za ekspertne analitičare, arhitekte i programere.
• Specificiraju sustave neovisno o načinu implementacije.
• Mali skup konstrukcija obrazaca uporabe (10% do 20%) koristi se u 80% do 90% mjesta u sustavu.
44
METODE U IZLUČIVANJU I ANALIZI ZAHTJEVA
• Intervjuiranje
• Scenarij
• Obrasci uporabe (engl. use case)
• Dijagrami interakcija (Sekvencijski dijagrami)
45
METODA IZLUČIVANJA ZAHTJEVA MODELIRANJEM DINAMIČKIH INTERAKCIJA U
SUSTAVU(modeliranje ponašanja, engl. behavioral modeling)
• Obrasci uporabe specificiraju individualne interakcije u sustavu.
• Dodatne informacije u inženjerstvu zahtjeva slijede iz UML dinamičkih dijagrama interakcije koji pokazuju aktore involvirane u interakciji, entitete (objekte, instancije) s kojima su u interakciji i operacije pridružene tim objektima.
• Dijagrami interakcija: sekvencijski i kolaboracijski.
Izvor: G. Overgaard, B. Selic, C. Bock, OMG, 2000.
46
Što su interakcije?
• To je skup komunikacija između instancija elemenata sustava.
Kada modelirati interakcije?
• Želimo specificirati kakvo je međudjelovanje između elemenata sustava.
• Želimo identificirati sučelja.
• Postoji potreba za raspodjelom zahtjeva.
47
(nisu temeljni u inženjerstvu zahtjeva)
48
Preporuke za modeliranje interakcija:
• Postavi kontekst interakcija (instancije elemenata).
• Uključi samo relevantna obilježja elemenata.
• Slijed događaja izrazi s lijeva na desno i odozgo prema dolje.
• Postavi aktivne instancije u gornji lijevi ugao dijagrama.
• Postavi pasivne instancije u donji desni ugao.
• Uporabi sekvencijske dijagrame da bi se pokazao eksplicitan redoslijed pobuda.
• Obvezno uporabi sekvencijske dijagrame u modeliranju sustava za rad u stvarnom vremenu.
49
(životna crta)
(tu je entitet aktivan)
(pobuda)
(povratna poruka)
(stvaranje)
(brisanje)
Temeljni dijelovi
Simboli entiteta sustava
50
Sekvencijski dijagram
• To je oblik interakcijskog dijagrama koji prikazuje entitete (objekte, elemente) s pridruženim životnim crtama u smjeru odozgo prema dolje.
• Interakcije u vremenu su prikazane kao poruke predstavljene strelicama od izvorne do ciljne životne crte.
• Sekvencijski dijagrami su pogodni za prikaz koji entiteti komuniciraju s drugim entitetima i koje poruke izazivaju tu komunikaciju.
• Sekvencijski dijagrami nisu pogodni za prikaz složene proceduralne logike.
51
Elementi sekvencijskog dijagrama
Životna crta (engl. lifeline)Životna crta predstavlja individualnog sudionika u sekvencijskom dijagramu. Životna crta uobičajeno ima pridruženi pravokutnik s imenom entiteta (elementa).
52
Elementi sekvencijskog dijagrama
Ponekad će sekvencijski dijagram sadržavati životnu crtu s aktorom kao simbolom entiteta/elementa. To je čest slučaj kada obrazac uporabe posjeduje pridruženi sekvencijski dijagram. Granični elementi i elementi upravljanja mogu također imati životne crte.
53
Elementi sekvencijskog dijagramaPoruka (engl. message):Poruke se prikazuju kao strelice. Poruke mogu biti cjelovite, izgubljene ili nađene, zatim sinkrone ili asinkrone, te pozivi ili signali. Na slici je prva poruka sinkrona s implicitnom povratnom porukom (puna strelica). Druga poruka je asinkrona (crtana strelica). Treća poruka je asinkrona povratna (crtkana linija).
(Kod sinkrone poruke pošiljatelj čeka na rezultat)
54
Elementi sekvencijskog dijagramaPoruka samom sebi (engl. self-message):Poruka prema samome sebi može predstavljati rekurzivan poziv operacije, ili poziv jedne procedure drugoj, gdje obje procedure pripadaju istom entitetu.
Poruka samom sebi : (različite procedure, funkcije, metode u objektu).
Rekurzija: (ista procedura, funkcija, metoda poziva se više puta).
55
Elementi sekvencijskog dijagramaIzgubljene i nađene poruke (engl. lost and found messages):Izgubljene poruke su one koje su poslane ali nisu stigle do primatelja ili one koje idu do primatelja koji nije prikazan na tom dijagramu. Nađene poruke su one koje dolaze od nepoznatog pošiljatelja ili od pošiljatelja koji nije prikazan na tom dijagramu. Označuju se grafičkim simbolom krajnjeg elementa.
56
Elementi sekvencijskog dijagramaPočetak i kraj životne crte (engl. lifeline start and end):Životna crta može se stvoriti i uništiti tijekom predstavljenog vremenskog perioda. Slika prikazuje entitet Child koji se stvori i uništi od strane entiteta Parent nakon nekog vremena.
57
Elementi sekvencijskog dijagramaTrajanje i vremenska ograničenjaTemeljno, poruka se prikazuje kao horizontalna linija. Padajuća linija prikazuje vremensko trajanje.
(>10ms od slanja do primanja,
npr. spora komunikacija).
58
Elementi sekvencijskog dijagrama
Petlja u sekvencijskom dijagramu Zatvoreni pravokutnik predstavlja poruke koje se ponavljaju n puta.
59
Elementi sekvencijskog dijagramaInvarijante stanjaInvarijanta stanja je ograničenje koje mora biti istinito za vrijeme izvođenja. Pokazuje se kao pravokutnik sa polukružnim krajevima.
60
prethodnik uvjet oznaka sekvence pov. vrijed. ime poruke lista arg.
Elementi sekvencijskog dijagrama: Oznake na strelicama
61
Raniji primjer: Tekstovni obrazac uporabe – promjena avio leta
Aktori: putnik, baza računa klijenta (s planom puta), rezervacijski sustav avio kompanije, sučelje prijave (engl. booking system)
Preduvjeti: Putnik se prijavio na sustav i odabrao opciju “promjena leta”.
Temeljni tijek transakcija Sustav dohvaća putnikov bankovni račun i plan puta iz baze. Sustav pita putnika da odabere dio plana puta koji želi mijenjati; putnik odabire segment puta. Sustav pita putnika za novi odlaznu i dolaznu destinaciju; putnik daje traženu informaciju. Ako je let moguć, tada … … Sustav prikazuje sažetak transakcije..
Alternativni tijek transakcija Ako let nije moguć, tada …
62
63
Primjer: Rezervacija hotela. Entitet koji inicira sekvenciju poruka je Reservation window.
Sekv. dijag. može uključiti i dodatni tekstovni opis
64
Primjer: Medicinska sestra (engl. nurse) traži dijagnostički test
Dvije asinkrone poruke od Nurse: 1) Traži MedicalLab da rezervira dan za test i 2) traži InsuranceCompany da odobri test. Redoslijed slanja i primanja ovih poruka je nebitan. Ako InsuranceCompany odobri test, Nurse će planirati test na dan koji odredi MedicalLab.
65
User
item:Article
copyrightForm:Form
request
complete
myWorkspace:Workspace
myPrinter:Printer
request
return
copyright OK
deliver
article OK
print send
confirminform
delete
LIBSYS - dodatni dijagram sekvenci za ispis članka
(Asinkrone povratne poruke nisu označene sukladno ranijim razmatranjima. To je dokaz da ni UML dijagrami nisu do kraja shvaćeni (Sommerville?) kao obvezujući standard.)
66
DETALJAN PRIKAZ GENERIČKIH AKTIVNOSTI U PROCESU INŽENJERSTVA ZAHTJEVA
• Studija izvedivosti
• Izlučivanje, analiza i specifikacija zahtjeva (ovo je najznačajniji dio)
• Validacija zahtjeva
• Upravljanje promjenama u zahtjevima
67
VALIDACIJA ZAHTJEVA
• Cilj validacije je pokazati da zahtjevi odgovaraju željama naručitelja.
• Naknadno ispravljanje pogreške u zahtjevima može biti 100 puta skuplje od ispravljanje pogreške u implementaciji.
TEHNIKE VALIDACIJE:
• Recenzija zahtjeva (sistematska ručna analiza zahtjeva).
• Izrada prototipa (provjera zahtjeva na izvedenom sustavu).
• Generiranje ispitnih slučaja (razvoj ispitnih sekvenci za provjeru zahtjeva).
68
ŠTO SE U ZAHTJEVIMA PROVJERAVA?
• VALJANOST - da li sustav osigurava funkcije koje podupiru potrebe korisnika?
• KONZISTENCIJA - da li postoji konflikt u zahtjevima?
• KOMPLETNOST - da li sustav uključuje sve funkcije koje je korisnik tražio?
• REALNOST - da li se sve funkcije mogu implementirati uz danu tehnologiju i proračun?
• PROVJERLJIVOST - da li se svi zahtjevi mogu provjeriti?
• RAZUMLJIVOST - da li je dokument jasno napisan?
• SLIJEDIVOST - da li je naveden izvor dokumenta?
• PRILAGODLJIVOST - mogu li se zahtjevi mijenjati bez velikog utjecaja na druge zahtjeve?
69
DETALJAN PRIKAZ GENERIČKIH AKTIVNOSTI U PROCESU INŽENJERSTVA ZAHTJEVA
• Studija izvedivosti
• Izlučivanje, analiza i specifikacija zahtjeva (ovo je najznačajniji dio)
• Validacija zahtjeva
• Upravljanje promjenama u zahtjevima
70
UPRAVLJANJE PROMJENAMA U ZAHTJEVIMA
Promjene nastupaju zbog promijenjenog modela poslovanja, boljeg razumijevanja procesa tijekom razvoja ili konfliktnih zahtjeva u različitim pogledima.
EVOLUCIJA ZAHTJEVA:
Time
Changedunderstanding
of problem
Initialunderstanding
of problem
Changedrequirements
Initialrequirements
Početno razumijevanje problema
Početni zahtjevi
Promijenjeno razumijevanje problema
Promijenjeni zahtjevi
VRIJEME
71
KLASIFIKACIJA PROMJENA ZAHTJEVA
• Okolinom promijenjeni zahtjevi - promjena zbog promjene okoline u kojoj organizacija posluje (npr. bolnica mijenja financijski model pokrivanja usluga).
• Novonastali zahtjevi - zahtjevi koji se pojavljuju kako kupac sve bolje razumije sustav koji se oblikuje
• Posljedični zahtjevi - zahtjevi koji nastaju nakon uvođenja sustava u eksploataciju, a rezultat su promjena procesa rada u organizaciji nastalih upravo uvođenjem novoga sustava
• Zahtjevi kompatibilnosti - zahtjevi koji ovise o procesima drugih sustava u organizaciji; ako se ti sustavi mijenjaju to traži promjenu zahtjeva i novo uvedeni sustav
72
UTJECAJ SOCIJALNIH I ORGANIZACIJSKIH ČIMBENIKA U INŽENJERSTVU ZAHTJEVA
• Programski produkti se uvijek koriste u socijalnom i organizacijskom kontekstu. To može uvelike utjecati i čak dominirati nad zahtjevima sustava.
• Socijalni i organizacijski čimbenici nisu jedinstven pogled, već utjecaj na sve poglede.
• Oblikovanje programske potpore mora to uvažiti, ali trenutno ne postoji sistematski postupak kako se to može uključiti u analizu zahtjeva.
• Ne postoje jednostavni modeli za opis obavljanja nekog posla. Ako i postoje, to su modeli zasnovani na prošlim a ne obrascima ponašanja na novom poslu. Potrebna je znanost o tome kako se poslovi stvarno obavljaju.
• Djelomično se tome može doskočiti izradom prototipa, te praćenjem rada na njemu.
73
ETNOGRAFIJA• To je znanost koja istražuje kako ljudi stvarno rade, a ne kako bi
definicija poslovnog procesa to propisivala.
• Koristi se za izlučivanje zahtjeva uzimajući u obzir aktivnosti drugih sustavom involviranih ljudi.
• Ne može otkriti sve domenske zahtjeve
Ethnographicanalysis
Debriefingmeetings
Focusedethnography
Prototypeevaluation
Generic systemdevelopment
Systemprotoyping
Fokusirana etnografija (etnografija + prototip):
kooperativni sastanciEtnografska analiza Saslušanja
Fokusirana etnografija
Evaluacija prototipa
Generički razvoj sustava Izrada prototipa
Cilj je da broj iteracija rafiniranja prototipa bude što manji!
74
ZAKLJUČCI
• Proces inženjerstva zahtjeva uključuje studiju izvedivosti, izlučivanje zahtjeva, analizu i specifikaciju, validaciju zahtjeva i rukovanje (upravljanje promjenama) zahtjevima.
• Izlučivanje, analiza i specifikacija zahtjeva je iterativan proces koji uključuje razumijevanje domene primjene, prikupljanje, klasifikaciju, strukturiranje, sastavljanje prioriteta i dokumentiranje zahtjeva.
• Validacija zahtjeva bavi se valjanošću, konzistentnošću, kompletnošću, realizmom u izvedbi i provjerljivošću.
• Sustavi imaju više dionika s različitim zahtjevima.
• Rukovanje zahtjevima uključuje planiranje i upravljanje promjenama u zahtjevima.
• Promjene načina poslovanja nužno mijenjaju zahtjeve.
• Socijalni i organizacijski čimbenici utječu na zahtjeve sustava.