1 / 74

PROCESI INŽENJERSTVA ZAHTJEVA (ili kako generirati specifikaciju)

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

ariana-snider
Télécharger la présentation

PROCESI INŽENJERSTVA ZAHTJEVA (ili kako generirati specifikaciju)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. KLASIČNI MODEL PROCESA INŽENJERSTVA ZAHTJEVA Izlučivanje i analiza Aktivnosti Studija izvedivosti Specifikacija zahtjeva Validacija zahtjeva iteracije Modeli sustava iteracije Produkti Dokument zahtjeva Korisnički zahtjevi i zahtjevi sustava

  6. SPIRALNI MODEL PROCESA INŽENJERSTVA ZAHTJEVA Zahtjevi sustava i modeliranje. Korisnički zahtjevi. Poslovni zahtjevi. Izlučivanje zahtjeva sustava Izlučivanje korisničkih zahtjeva. Specifikacija Studija izvedivosti Izrada prototipa Revizije Izlučivanje Validacija Konačan dokument zahtjeva

  7. Spiralni model inženjerstva zahtjeva • Tro-stupanjska aktivnost (specifikacija, validacija, izlučivanje). • Promatra proces inženjerstva zahtjeva kroz iteracije ciklusasvih 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 izvedivostina 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,prikupljanjeinformacija ipisanju 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). • Metodeu izlučivanju i analizi zahtjeva: • Intervjuiranje kao metoda izlučivanja. • Scenarijkao 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. SPIRALNI MODEL IZLUČIVANJA I ANALIZE ZAHTJEVA Klasifikacija i organizacija zahtjeva Ustanovljavanje prioriteta i pregovaranje Početak: Izlučivanje (otkrivanje) zahtjeva 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 dionicis 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. POGLEDI U PRIMJERU SUSTAVA KNJIŽNICE (ranije naveden hipotetski sustav LIBSYS) Svi pogledi Domena primjene Indirektni Interakcija

  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 intervjuu kojem se odgovara na skup prije definiranih pitanja. Otvoreni intervjuu 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 uporabepredstavljaju 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 dijagramikako bi se detaljno opisao dinamički tijek događaja. • U nastavku, koristit će se prezentacija: • Introduction to UML: Use Cases • Cris Kobryn • Co-Chair UML Revision Task ForceNovember 2000

  27. Š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.

  28. Modeliranje obrascima uporabe: jezgreni elementi Naziv akcije Ime aktora

  29. Modeliranje obrascima uporabe: jezgreni odnosi <<extend>>

  30. Modeliranje obrascima uporabe: jezgreni odnosi <<include>> (crtkana ili puna strelica često nisu u konzistentnoj uporabi, u kolegiju se neće inzistirati na razlici)

  31. 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

  32. Dijagram obrazaca uporabe (samo koncepti) Aktori Granica sustava Odnosi Obrazac uporabe Fig. 3-44, UML Notation Guide

  33. Relacije u obrascima uporabe (obratiti pažnju na smjer strelica) Dobavi podatke o kupcu Naruči proizvod Uredi plaćanje Place Order uključuje ova ponašanja u cijelosti Naruči Točke proširenja Zahtijeva katalog Fig. 3-45, UML Notation Guide proširenje akcije

  34. VIŠESTRUKOST (brojnost) u obrascima uporabe 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 isplata jedan

  35. Odnosi između aktora više Prodavatelj Naruči Generalizacija (dopušta se i između obrazaca uporabe) Odobri kredit Nadzornik Fig. 3-46, UML Notation Guide

  36. Tekstovni obrazac uporabe – Npr. 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 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 …

  37. Kada modelirati obrascima uporabe • Obrascima uporabe modelirati korisničkezahtjeve. • 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.

  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.

  39. Primjer: Upravljanje ljudskim resursima - dijagram Istaknuti obrazac je: Osvježi pogodnosti Upravitelj Zdravstveni plan Zaposlenik Plan osiguranja “on-line” sustav za upravljanje ljudskim resursima

  40. Primjer: Upravljanje ljudskim resursima Akcija -“osvježi pogodnosti” Osvježi zubnu zaštitu Osvježi plan zdravstvene zaštite Osvježi plan osiguranja Osvježi pogodnosti Točka proširenja Zaposlenik Uvjet proširenja Opcija kupnje dionica Nadoknada troškova

  41. Tekstovni opis: “Osvježi pogodnosti” (engl. UpdateBenefits)obrazac uporabe • 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 Otkaži pregled Dogovori pregled Sustav za određivanje termina Zatraži lijek Provjeri karton pacijenta Plati račun Odgoda plaćanja činovnik Točka proširenja 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 interakcijekoji pokazuju aktoreinvolvirane u interakciji, entitete (objekte, instancije) s kojima su u interakciji i operacijepridružene tim objektima. • Dijagrami interakcija: sekvencijskii 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. Temeljni dijelovi Simboli entiteta sustava (životna crta) (pobuda) (tu je entitet aktivan) (povratna poruka) (brisanje) (stvaranje)

  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.

More Related