Programsko Inženjerstvo - Prvi Kolokvij Memo PDF

PROGRAMSKO INŽENJERSTVO PRVI KOLOKVIJ MEMO Bruno Bilandžić [email protected] 19. studenog 2020. Sadržaj 1. Predavanje - Uvod u programsko inženjerstvo...................................................................... 1 1.1 Programsko inženjers...

PROGRAMSKO INŽENJERSTVO PRVI KOLOKVIJ MEMO Bruno Bilandžić [email protected] 19. studenog 2020. Sadržaj 1. Predavanje - Uvod u programsko inženjerstvo...................................................................... 1 1.1 Programsko inženjerstvo............................................................................................ 1 1.2 Softverski produkti..................................................................................................... 1 1.3 Karakteriskike kvalitetnog softvera........................................................................... 1 1.4 Osnovne karakteristike programskog inženjerstva.................................................... 1 2. Predavanje - Softverski procesi............................................................................................. 2 2.1 Planirani i agilni procesi............................................................................................ 2 2.2 Modeli softverskih procela........................................................................................ 2 2.3 Vodopadni model....................................................................................................... 2 2.3.1 Faze vodopadnog modela.................................................................................... 2 2.3.2 Prednosti vodopadnog modela............................................................................. 3 2.3.3 Problemi vodopadnog modela............................................................................. 3 2.4 Inkrementalni razvoj.................................................................................................. 3 2.4.1 Prednosti inkrementalnog razvoja........................................................................ 4 2.4.2 Nedostatci inkrementalnog razvoja...................................................................... 4 2.5 Integracija i konfiguriranje komponenti.................................................................... 5 2.6 Procesne aktivnosti.................................................................................................... 6 2.6.1 Specifikacija softverskih zahtjeva........................................................................ 6 2.6.2 Dizajn i implementacija softvera......................................................................... 7 2.6.2.1 Aktivnosti procesa dizajna............................................................................ 7 2.6.2.2 Implementacija sustava................................................................................. 8 2.6.3 Validacija softvera............................................................................................... 8 3. Predavanje - Agilni razvoj softvera....................................................................................... 9 3.1 Osnovne karakteristike agilnih metoda...................................................................... 9 3.2 Nedostaci agilnih metoda........................................................................................... 9 3.3 Tehnike Agilnog razvoja............................................................................................ 9 3.3.1 Ekstremno programiranje..................................................................................... 9 3.4 Scrum....................................................................................................................... 10 3.4.1 Sprint.................................................................................................................. 11 3.4.2 Prednosti Scruma............................................................................................... 11 4. Predavanje - Specifikacija zahtjeva..................................................................................... 12 4.1 Vrste zahtjeva........................................................................................................... 12 4.1.1 Funkcionalni zahtjevi......................................................................................... 12 4.1.2 Ne-funkcionalni zahtjevi.................................................................................... 12  4.1.2.1 Klasifikacija ne-funkcionalnih zahtjeva..................................................... 13 4.2 Proces prikupljanja zahtjeva.................................................................................... 13 4.2.1 Studija izvedivosti.............................................................................................. 14 4.2.2 Iznošenje zahtjeva.............................................................................................. 14 4.2.3 Proces opisa i analize zahtjeva........................................................................... 15 4.2.3.1 Otkrivanje zahtjeva..................................................................................... 15 4.2.3.1.1 Razgovori............................................................................................... 15 4.2.3.1.2 Etnografija.............................................................................................. 16 4.2.3.1.3 Priče i scenariji....................................................................................... 16 4.2.3.2 Use-Case..................................................................................................... 16 4.3 Dokument specifikacije zahtjeva............................................................................. 17 4.3.1 Specifikacija zahtjeva........................................................................................ 17 4.3.2 Zahtjevi i dizajn................................................................................................. 17 4.3.3 Načini pisanja specifikacije zahtjeva................................................................. 17 4.3.4 Korisnici dokumenta specifikacije zahtjeva...................................................... 18 4.3.5 IEEE struktura dokumenta specifikacije zahtjeva............................................. 19 4.3.6 Specifikacija pisana prirodnim jezikom............................................................. 19 4.3.7 Specifikacija korištenjem strukturiranog jezika................................................. 20 4.4 Validacija zahtjeva................................................................................................... 20 4.4.1 Tehnike validacije.............................................................................................. 21 4.5 Upravljanje zahtjevima............................................................................................ 21 4.5.1 Plan upravljanja zahtjevima............................................................................... 21 4.5.2 Upravljanje promjenama zahtjeva..................................................................... 21 5. Predavanje - Modeliranje sustava........................................................................................ 23 5.1 Modeliranje sustava................................................................................................. 23 5.2 Vrste UML dijagrama.............................................................................................. 23 5.3 Podjela modela......................................................................................................... 23 5.4 Kontekstni modeli.................................................................................................... 23 5.4.1 Procesna perspektiva.......................................................................................... 24 5.4.2 UML dijagram aktivnosti................................................................................... 24 5.5 Interakcijski modeli................................................................................................. 25 5.5.1 Use case modeliranje......................................................................................... 25 5.5.2 Slijedni dijagram................................................................................................ 26 5.6 Strukturni modeli..................................................................................................... 27 5.6.1 Dijagram klasa................................................................................................... 27  5.7 Modeli ponašanja..................................................................................................... 27 Slike Slika 2-1 Vodopadni model softverskih procesa....................................................................... 2 Slika 2-2 Inkremetalni razvoj softvera....................................................................................... 4 Slika 2-3 Integriranje i konfiguracija komponenti..................................................................... 5 Slika 2-4 Proces specifikacije zahtjeva...................................................................................... 6 Slika 2-5 Osnovni model procesa dizajna.................................................................................. 7 Slika 3-1 Inačice ekstremnog programirajnja XP.................................................................... 10 Slika 3-2 Inačice Scrum metode.............................................................................................. 11 Slika 4-1 Proces prikupljanja zahtjeva..................................................................................... 14 Slika 4-2 Otkrivanje i specifikacija zahtjeva........................................................................... 15 Slika 4-3 Načini pisanja specifikacije zahtjeva....................................................................... 17 Slika 4-4 Korisnici dokumenta specifikacije zahtjeva............................................................. 18 Slika 4-5 IEEE struktura dokumenta specifikacije zahtjeva.................................................... 19 Slika 5-1 Model konteksta....................................................................................................... 24 Slika 5-2 Dijagram aktivnosti.................................................................................................. 25 Slika 5-3 Use case modeliranje................................................................................................ 26 Slika 5-4 Slijedni dijagram...................................................................................................... 27 1. Predavanje - Uvod u programsko inženjerstvo 1.1 Programsko inženjerstvo Inženjerska disciplina koja se bavi svim aspektima razvoja softvera, tj. bavi se teorijom, metodama i alatima za profesionalan razvoj softvera. 1.2 Softverski produkti Generički: Samostalni sustavi dostupni u javnoj prodaji (PC softver poput programa za obradu slika, softver za upravljanje projektom, programi za obradu teksta, tablica, …) Organizacija koja razvija program kontrolira i njegovu specifikaciju, prodaje se velikom broju različitih korisnika –(engl. ComercialOfTheShelf-COTS) Po narudžbi(eng. Custom): Kupac koji naručuje program definira njegovu specifikaciju i njen je vlasnik. Program za kontrolu zračnog prometa, program za upravljanje financijama, … 1.3 Karakteriskike kvalitetnog softvera Softver bi trebao omogućiti korisniku traženu funkcionalnost i performanse, a pri tome bi ga trebalo biti lako održavati, biti pouzdani prihvatljiv. Održavanje-Program bi trebao biti pisan tako da ga se lako može mijenjati u skladu s korisničkim zahtjevima. Pouzdanost -Ne smije uzrokovati fizičke i/ili ekonomsku štetu u slučaju pada sustava. Efikasnost-Ne smije prekomjerno koristiti resurse (procesor, memorija) i odziv mora biti što brži. Prihvatljivost i iskoristivost (engl. acceptability& usability) -Proizvod mora biti prihvaćen od strane korisnika. 1.4 Osnovne karakteristike programskog inženjerstva Specifikacija –što sustav treba raditi i o kojim ograničenjima treba voditi računa pri razvoju. Razvoj –produkcija specificiranog softvera. Validacija –provjera da softver radi ono što je kupac naručio. Održavanje –promjena softvera u skladu s promjenom zahtjeva tržišta. 1 2. Predavanje - Softverski procesi 2.1 Planirani i agilni procesi Planirani procesi (engl. plane based) su procesi kod kojih su sve procesne aktivnosti planirane unaprijed i napredak se mjeri u odnosu na ovaj plan. Kod agilnih procesa planiranje je inkrementalno i jednostavnije je promijeniti proces kako bi zadovoljio promjenu korisničkih zahtjeva. 2.2 Modeli softverskih procela Vodopadni model Planirani model sa strogo odvojenim fazama specifikacije i razvoja. Inkrementalni razvoj Specifikacija, razvoj i validacija se preklapaju. Može biti planiran ili agilan. Integracija i konfiguriranje komponenti Sustav se sklapa od postojećih komponenti. Može biti planirano ili agilno. 2.3 Vodopadni model Slika 2-1 Vodopadni model softverskih procesa 2.3.1 Faze vodopadnog modela Analiza i definiranje zahtjeva 2 U suradnji s korisnicima određuju se usluge koje će nuditi sustav, njegova ograničenja i ciljevi. Dizajn sustava i softvera Uspostavlja se arhitektura sustava, identificiraju se osnovne apstrakcije u sustavu i njihove veze. Implementacija i jedinično testiranje Iz definirane arhitekture sustava se piše i testira kod. Integracija i testiranje sustava Individualni dijelovi koda se spajaju i testira se sustav kao cjelina kako bi se ustanovilo zadovoljava li korisničke zahtjeve. Rad i održavanje Najčešće najduža faza životnog ciklusa. Sustav se pušta u rad, ispravljaju greške koje nisu otkrivene u ranijim fazama, sustav se poboljšava i po potrebi dodaju nove funkcionalnosti. 2.3.2 Prednosti vodopadnog modela Planiranje Vrlo striktno planiranje se obavlja na početku procesa pa je moguće procijeniti kada će projekt biti gotov, koliki će biti trošak, … Zahtjevi S obzirom da su svi zahtjevi poznati na početku moguće je pojednostavniti dizajn. Dokumentacija Postoji detaljna dokumentacija , tj. rezultat svake faze je jedan ili više "potpisanih" dokumenata. 2.3.3 Problemi vodopadnog modela Nemogućnost da se prihvati promjena kada se započne s procesom. Faza treba biti gotova prije nego se pređe na iduću. 2.4 Inkrementalni razvoj Razvoj i isporuka sustava su podijeljeni u niz inkrementa od kojih svaki isporučuje neku od zadanih funkcionalnosti. Svi zahtjevi dobivaju prioritet i oni s najvećim se uključuju u početne inkremente. Jednom kada se krene u razvoj inkrementa ne smiju s mijenjati njegovi zahtjevi, ali se to može raditi za sljedeće inkremente. Procjenu svakog inkrementa radi kupac/korisnik sustava. 3  Slika 2-2 Inkremetalni razvoj softvera 2.4.1 Prednosti inkrementalnog razvoja Brža isporuka i primjena najvažnijih funkcionalnosti. Korisnici mogu koristiti (i zarađivati) softver prije nego bi to mogli korištenjem vodopadnog modela. Korisnik može dati svoje mišljenje o sustavu na osnovu onoga što je napravljeno. Početni inkrementi služe kao prototip koji iznosi na vidjelo zahtjeve za kasnije inkremente. Potrebna analiza i dokumentacija koju treba ponovno napraviti ili prepraviti kod promjene zahtjeva je znatno manja nego kod vodopadnog modela. Umanjuje se rizik od potpunog promašaja projekta. Zahtjevi s najvišim prioritetom se najviše testiraju. 2.4.2 Nedostatci inkrementalnog razvoja Loša vidljivost procesa. Menadžeri trebaju redovne isporuke kako bi mjerili projekt. Ukoliko se sustav razvija brzo ne isplati se stvarati dokumentaciju za svaku verziju sustava. U osnovi iterativnog procesa je da se specifikacija razvija zajedno sa softverom. To je baš suprotno od klasičnog modela nabave u većini organizacija, gdje je potpuna specifikacija dio ugovora za razvoj sustava. Većina sustava zahtjeva niz osnovnih funkcionalnosti koje koriste različiti dijelovi sustava. Kako zahtjevi nisu detaljno definirani dok određeni inkrement ne treba implementirati, može biti problem identificirati zajedničke elemente potrebne svim inkrementima. Struktura sustava opada kako se radi više izmjena, tj. dodaju novi inkrementi. Zbog toga je potrebno trošiti vrijeme i novac na procjenjivanje koda (engl. refactoring) i neophodne izmjene kako bi daljnji rad bio moguć. 4 2.5 Integracija i konfiguriranje komponenti Kada ljudi koji rade na projektu znaju da postoji dizajn ili algoritam ili kod sličan onome što im treba. Oni ga pronađu i uključe u svoj sustav. Ovaj pristup se počeo sve više koristiti s pojavom standarda za izradu komponenti, a danas je standardan način za izradu različitih poslovnih sustava. Slika 2-3 Integriranje i konfiguracija komponenti Otkrivanje i procjena komponenti - Traže se komponente za implementaciju zahtjeva iz specifikacije i procjenjuju da se vidi u kojoj mjeri odgovaraju onome što se traži. Izmjena zahtjeva – Analiziraju se zahtjevi i informacije o pronađenim komponentama, te se zahtjevi modificiraju kako bi im odgovarali. Konfiguracija aplikacijskog sustava – Ukoliko je pronađen sličan sustav konfigurira se da odgovara korisničkim zahtjevima. Prilagodba postojećih i razvoj novih komponenti – Radi se prilagodba pronađenih komponenti, te se po potrebi razvijaju nove. Integracija sustava – Sve komponente se integriraju u funkcionalan sustav. Prednosti: Brža izrada softvera jer se ne troši toliko vremena na razvoj, a time se smanjuje cijena i rizik. Nedostatci: Kompromisi na zahtjevima mogu uzrokovati da funkcionalnosti sustava ne odgovaraju kupcu. Nove verzije komponenti ne ovise o onome tko ih koristi. Postoje tri osnovne vrste softverskih komponenti koje se mogu koristiti u ovom procesu: 1. Web servisi koji se razvijaju prema određenim standardima i dostupni su za udaljene pozive. 2. Kolekcije objekata u obliku paketa koje se integriraju s platformom poput.NET ili J2EE. 3. Samostalni softverski sustavi (COTS) koji se podese za rad u određenoj okolini. 5 2.6 Procesne aktivnosti 2.6.1 Specifikacija softverskih zahtjeva Proces u kojem se utvrđuje: koje usluge treba pružiti sustav koja su njegova ograničenja u radu (npr. broj korisnika koji mogu istovremeno pristupiti nekom podatku) i razvoju Procesi specifikacije softvera: Studija izvedivosti (engl. feasibilitystudy) –Je li isplativo raditi sustav? Opis i analiza zahtjeva–Što zainteresirane strane (engl. steakholders) zahtijevaju i traže od sustava? Specifikacija zahtjeva –Detaljan opis zahtjeva. Validacija zahtjeva –Provjera ispravnosti zahtjeva. Slika 2-4 Proces specifikacije zahtjeva Studija izvedivosti – Radi se procjena: mogu li se zadovoljiti korisničke potrebe korištenjem dostupne tehnologije (hardvera i softvera); hoće li sustav biti isplativ s poslovne strane i može li se napraviti u okviru dostupnog budžeta. Studija izvedivosti bi trebala biti brza i jeftina, a rezultat bi trebao odrediti ima li ići smisla dalje s detaljnijom analizom. 6 Opis i analiza zahtjeva "Otkrivaju" se zahtjevi sustava i to promatranjem postojećeg sustava, razgovorom s naručiteljem i korisnicima Može uključivati razvoj jednog ili više modela ili prototipova sustava. Specifikacija zahtjeva Zapisivanje svih prikupljenih informacija ozahtjevima sustava u formalnom obliku. Validacija zahtjeva Provjerava se koliko su zapisani zahtjevi realni, konzistentni i potpuni. Za vrijeme ove faze otkrivaju se i ispravljaju greške u specifikaciji. 2.6.2 Dizajn i implementacija softvera Proces konverzije specifikacije u sustav koji obavlja svoju funkciju. Dizajn softvera: struktura programa koji će se realizirati, sučelja među komponenta, algoritama koji se koriste, organizacije podataka, … Implementacija Pretvorba ove strukture u izvršni program. 2.6.2.1 Aktivnosti procesa dizajna Slika 2-5 Osnovni model procesa dizajna Dizajn arhitekture identifikacija osnovne strukture sustava, glavne komponente (pod-sustavi, moduli), njihove veze i distribucija. Dizajn sučelja 7  definiraju se sučelja među komponentama sustava. Dizajn komponenti Analizira se svaka komponenta sustava i određuje na koji će način raditi. Dizajn baze podataka detaljan dizajn organizacije podataka u sustavu, te na koji će način oni biti predstavljeni u bazi podataka. 2.6.2.2 Implementacija sustava Programiranje individualna aktivnost i ne postoje standardni procesi; Uklanjanje grešaka Aktivnost pronalaženja i ispravljanja grešaka u napisanom kodu. 2.6.3 Validacija softvera Uključuje proces provjere i testiranja. 8 3. Predavanje - Agilni razvoj softvera 3.1 Osnovne karakteristike agilnih metoda Fokus je na kodiranju, a ne dizajnu i pisanju dokumentacije; Baziraju se na iterativnom pristupu razvoja softvera; Namijenjene su brzoj isporuci funkcionalnog softvera, te brzim izmjenama postojećeg kako bi se prilagodio zahtjevima tržišta. U velikoj mjeri se oslanjaju na razne alate (npr. autom. test.) 3.2 Nedostaci agilnih metoda Može biti teško zadržati interes korisnika koji uključen u proces. Osobine članova tima ne moraju biti prikladne za grupni rad koji podrazumijevaju agilne metode. Ukoliko ima više zainteresiranih strana može biti teško odrediti prioritet pojedinih zahtjeva. Održavanje jednostavnosti može zahtijevati dodatni rad, što nekada nije jednostavno zbog rokova. Problem je sastavljanje ugovora kao kod drugih inkrementnih metoda. 3.3 Tehnike Agilnog razvoja 3.3.1 Ekstremno programiranje Nove verzije se mogu isporučivati nekoliko puta dnevno; Inkrementi se isporučuju korisniku svaka 2 tjedna; Prvo se razvija test pa se tek onda kodira; Svi testovi se ponovno pokreću za svaku verziju i ona se prihvaća tek kada se svi izvrše uspješno. 9  Slika 3-1 Inačice ekstremnog programirajnja XP 3.4 Scrum Općenita agilna metoda s naglaskom na upravljanje iterativnim razvojem. U Scrumu postoje tri faze: Inicijalna faza je okvirna faza planiranja, gdje se identificiraju generalni ciljevi projekta i dizajnira arhitektura softvera. Nakon toga slijedi niz sprintova, a svaki od njih razvija jedan inkrement sustava. Faza zatvaranja projekta, objedinjuje projekt, producira/dovršava se potrebna korisnička dokumentacija (npr. upute, pomoć u programu) i radi se procjena što se naučilo u projektu. 10  Slika 3-2 Inačice Scrum metode 3.4.1 Sprint Sprintovi su fiksne dužine, 2-4 tjedna. Početna točka planiranja je popis zadataka koje još treba obaviti na projektu (engl. backlog). U fazi odabira članovi razvojnog tima u suradnji s korisnikom biraju funkcionalnosti koje će se razviti u sprintu. Jednom kada se dogovore funkcionalnosti, članovi tima sami raspodjele uloge u timu i kreće razvoj. U tijeku ove faze tim se izolira od korisnika i organizacije, a sva se komunikacija prema vani ide preko Scrum mastera. Scrum master treba štititi razvojni tim od bilo kakvih vanjskih utjecaja i smetnji. Na kraju sprinta napravljeni posao se kontrolira i prezentira svim zainteresiranim stranama. Nakon toga kreće novi sprint. 3.4.2 Prednosti Scruma Produkt se dijeli u niz manjih jasnih zadataka. Nejasni zahtjevi ne zadržavaju napredak. Cijeli tim ima uvid u projekt i kao posljedica toga komunikacija unutar tima je olakšana. Korisnicima se na vrijeme isporučuju inkrementi, na osnovu kojih mogu dati komentare o radu softvera. Uspostavlja se povjerenje između kupca i razvojnog tima i stvara se pozitivna okolina u kojoj svi očekuju uspjeh projekta. 11 4. Predavanje - Specifikacija zahtjeva Proces utvrđivanja (pronalaženja, analize, dokumentiranja, provjere) usluga koje korisnik zahtjeva od sustava te ograničenja pod kojima taj sustav mora raditi se naziva specifikacija zahtjeva. Korisnički zahtjevi - pišu se za korisnika i opisani su na način da ih razumije korisnik. Treba opisati korištenjem prirodnog jezika, tablica, dijagrama a trebaju biti takvi da ih razumiju svi korisnici. Zahtjevi sustava - namijenjeni su razvojnom timu. To je dokument sa detaljnim opisom svih funkcija, usluga i ograničenja sustava, u potpunosti strukturiran. Može se koristiti za potpisivanje ugovora. 4.1 Vrste zahtjeva Funkcionalni zahtjevi Popis usluga koje pruža sustav, kako sustav treba reagirati na određene ulaze, te kako se sustav ponaša u određenoj situaciji, u nekim slučajevima u funkcionalnim zahtjevima može pisati i što sustav ne bi trebao raditi. Ne-funkcionalni zahtjevi Ograničenja na usluge ili funkcionalnosti sustava (vremenska ograničenja, ograničenja razvojnih procesa, standarda, performanse, …) Zahtjevi domene Ograničenja iz područja domene koja utječu na rad sustava. 4.1.1 Funkcionalni zahtjevi Opisuju što bi sustav trebao raditi, tj. opisuju funkcionalnosti ili usluge sustava. Mogu biti vrlo apstraktne izjave koje opisuju što sustav treba raditi ili u detalje opisivati usluge koje će pružiti taj sustav ovisno o tome kome su namijenjeni. Ovise o vrsti softvera, korisnicima i tipu sustava na kojem se softver koristi. U principu zahtjevi bi trebali biti: Potpuni –Trebaju uključiti opis svih zahtijeva koje su naveli korisnici. Konzistentni–Ne smije biti konflikta ili kontradikcija kod opisa sustava. 4.1.2 Ne-funkcionalni zahtjevi To nisu zahtjevi koji su direktno povezani s funkcionalnošću sustava, oni se odnose na: svojstva i ograničenja sustava npr. pouzdanost, brzina izvršavanja, zahtjevi za pohranom, ograničenja U/I uređaja ili prezentacije podataka na sučeljima u sustavu, … korištenje određenog CASE sustava, programskog jezika ili razvojne metode. 12 Jedan ne-funkcionalni zahtjev, poput sigurnosti, može generirati čitav niz povezanih funkcionalnih zahtjeva. 4.1.2.1 Klasifikacija ne-funkcionalnih zahtjeva Zahtjevi aplikacije Zahtjev da se aplikacija ponaša na određeni način (npr. brzina izvođenja, pouzdanost, …) Organizacijski zahtjevi zahtjevi koji su posljedica organizacijske politike i procedura (npr. procesi koji se standardno koriste, implementacijski zahtjevi, …) Vanjski zahtjevi Zahtjevi koji se javljaju se kao posljedica faktora van samog sustava (npr. zakonski okviri, suradnja s drugim sustavima, etički zahtjevi, …) 4.2 Proces prikupljanja zahtjeva Međutim postoji niz uobičajenih aktivnosti koje se najčešće provode, a to su: Studija izvedivosti (engl. Feasibilitystudy) Iznošenje zahtjeva (engl. Requirementselicitation) Analiza zahtjeva Validacija zahtjeva Upravljanje zahtjevima. U praksi proces prikupljanja zahtjeva je iterativan i sve ove aktivnosti se preklapaju. 13  Slika 4-1 Proces prikupljanja zahtjeva 4.2.1 Studija izvedivosti Vrlo kratka studija koja provjerava: Doprinosi li sustav organizacijskim ciljevima? Može li se realizirati korištenjem postojeće tehnologije i okviru proračuna? Može li se integrirati s postojećim sustavima? 4.2.2 Iznošenje zahtjeva Uključuje rad tehničkog osoblja s korisnicima kako bi prikupili što više znanja o domeni aplikacije, uslugama koje bi trebao pružiti sustav i ograničenjima u radu sustava. Može uključivati različite zainteresirane strane: krajnje korisnike, menadžere, inženjere uključene u održavanje, eksperte iz te domene, sindikate, … 14 4.2.3 Proces opisa i analize zahtjeva Slika 4-2 Otkrivanje i specifikacija zahtjeva 1) Otkrivanje zahtjeva U suradnji s zainteresiranim stranama (otkriva i zahtjeve domene). 2) Klasifikacija i organizacija zahtjeva Grupiraju se povezani zahtjevi i organiziraju u koherentne skupine. 3) Postavljanje prioriteta i pregovaranje Postavljanje prioriteta (mora imati, trebao bi imat, bilo bi dobro), te rješavanje konfliktnih zahtjeva. 4)Dokumentiranje zahtjeva Svi zahtjevi se dokumentiraju i služe kao ulazni podaci za sljedeću fazu spirale. Slika 4-1 4.2.3.1 Otkrivanje zahtjeva Načini otkrivanja zahtjeva: Razgovori (intervjui) Etnografija Scenariji. 4.2.3.1.1 Razgovori Zatvoreni razgovori –odgovara se na predefinirani niz pitanja (koristi se u slučaju kad se već zna o čemu se radi jer je ranije rađena slična aplikacija) Otvoreni razgovori –ne postoje pre-definirana pitanja, već se u razgovoru s zainteresiranim stranama istražuje problem. 15 4.2.3.1.2 Etnografija Etnografija je promatračka tehnika koja se koristi za bolje razumijevanje socijalnih i organizacijskih zahtjeva. Analitičar postaje dio radne okoline u kojoj će se koristiti sustav –promatra ljude na njihovom radnom mjestu. Prednosti: Pomaže analitičaru otkriti implicitne zahtjeve sustava koji predstavljaju stvarne a ne formalne procese. Ljudi ne moraju objasniti što rade. Promatraju se važni socijalni i organizacijski faktori. Nedostatak: daje prikaz radnih procesa u trenutku promatranja, ali ne može identificirati nove zahtjeve. 4.2.3.1.3 Priče i scenariji Scenariji su primjeri iz stvarnog korištenja sustava koji opisuju kako se sustav može koristiti. Svaki scenarij obično pokriva jedan ili mali dio mogućih interakcija. Scenarij počinje s uvodom u interakciju i tijekom tog procesa se dodaju detalji kako bi se stvorila potpuna slika interakcije. Trebali bi uključiti: Opis početne situacije, Opis normalnog tijeka događaja, Opis što može krenuti loše, Informacije o drugim istovremenim aktivnostima, Opis stanja sustava kad scenarij završi. 4.2.3.2 Use-Case UML tehnika bazirana na scenarijima koja u svom najjednostavnijem obliku identificira aktere/sudionike koji su u interakciji sa sustavom. Pri tome svaki use-case bi uz grafički prikaz trebao imati i tekstualni opis, kako bi se objasnila pojedina funkcionalnost. Niz use-caseova bi trebao opisati sve moguće interakcije sa sustavom. Uz use-case može se koristiti i slijedni dijagram kako bi se opisao vremenski slijed obrade događaja u sustavu. Scenariji i use-caseovi su vrlo efikasna tehnika za otkrivanje zahtjeva od onih zainteresiranih strana koje rade direktno sa sustavom. Međutim nije tako efikasna za otkrivanje ograničenja, ne-funkcionalnih zahtjeva ili zahtjeva domene. 16 4.3 Dokument specifikacije zahtjeva Dokument specifikacije zahtjeva je službena izjava što se traži od razvojnog tima. Treba uključivati i definiciju korisničkih zahtjeva izahtjeva sustava. To NIJE dokument dizajna i koliko god je to moguće trebao bi opisivati ŠTOsustav treba raditi, a ne i KAKO. 4.3.1 Specifikacija zahtjeva Proces zapisivanja korisničkih zahtjeva i zahtjeva sustava u dokument specifikacije zahtjeva. Korisnički zahtjevi moraju biti razumljivi krajnjim korisnicima i kupcima koji nemaju tehničku pozadinu. Zahtjevi sustava su detaljniji zahtjevi i mogu uključivati više tehničkih informacija. Zahtjevi mogu biti dio ugovora za razvoj sustava Stoga je važno da su što potpuniji. 4.3.2 Zahtjevi i dizajn U teoriji, zahtjevi bi trebali navesti ŠTO sustav treba raditi, a dizajn bi trebao opisati KAKO to sustav ostvaruje. U praksi, zahtjevi i dizajn su nerazdvojni: Za strukturiranje zahtjeva može biti potrebna arhitektura sustava; Sustav može međusobno djelovati s drugim sustavima koji utječu na njegov dizajn; Korištenje posebnog dizajna da bi se zadovoljilo ne-funkcionalne zahtjeve može biti uvjet domene. 4.3.3 Načini pisanja specifikacije zahtjeva Slika 4-3 Načini pisanja specifikacije zahtjeva 17 4.3.4 Korisnici dokumenta specifikacije zahtjeva Slika 4-4 Korisnici dokumenta specifikacije zahtjeva 18 4.3.5 IEEE struktura dokumenta specifikacije zahtjeva Slika 4-5 IEEE struktura dokumenta specifikacije zahtjeva 4.3.6 Specifikacija pisana prirodnim jezikom Jedan od osnovnih načina pisanja zahtjeva jer je izražajan, intuitivan i univerzalan. Zahtjevi su napisani kao rečenica prirodnog jezika koje se po potrebi mogu nadopuniti dijagramima i tablicama. Potencijalno je nejasan, dvosmislen i razumijevanje ovisi o prethodnom znanju čitatelja. Upute: 1) Postaviti standardni format i koristiti ga za sve zahtjeve (može biti excel ili word predložak, use casedijagrami). 2) Koristiti jezik na konzistentan način. Koristiti: 19  “mora” za glavne zahtjeve, “trebalo bi / bilo bi dobro”za zahtjeve koje nisu osnovne funkcionalnosti. 3) Podebljati ili posebno istaknuti glavne dijelove zahtjeva. 4) Ne koristiti računalni žargon. 5) Uključiti objašnjenje (opravdanje) zašto je zahtjev potreban. Problemi Nedovoljno jasan opis Teško je biti precizan bez da se dokument učini teškim za čitanje. Miješanje zahtjeva Funkcionalni i ne-funkcionalni zahtjevi imaju tendenciju da se miješaju. Integracija zahtjeva Nekoliko različitih zahtjeva se može izraziti zajedno. 4.3.7 Specifikacija korištenjem strukturiranog jezika Pristup pisanja zahtjeva gdje je sloboda pisca zahtjeva ograničena i zahtjevi su napisani na standardan način. Mana je ograničena terminologija, a prednost što se zadržava izražajnost prirodnog jezika, ali je nametnut stupanj uniformnosti. Specifikacija bazirana na formi: 1) Definicija funkcije ili entiteta 2) Opis ulaznih podataka i tko/što ih generira 3) Opis izlaznih podataka i gdje idu 4) Informacije o podacima koji su potrebni za izračunavanje i drugim subjektima koji se koriste 5) Opis akcija koje treba poduzeti 6) Pre i post uvjeti (ako je potrebno) 7) Nuspojave (ako ih ima) u funkciji 4.4 Validacija zahtjeva Za vrijeme procesa validacije zahtjeva provode se različite provjere: Valjanost – pruža li sustav funkcionalnosti koje na najbolji način podržavaju korisničke potrebe Konzistentnost – Jesu li neki zahtjevi konfliktni? Ne smije biti kontradiktornih zahtjeva niti se isti zahtjevi smiju ponavljati. 20 Potpunost – Jesu li sve funkcije koje zahtjeva korisnik uključene? Jesu li zahtjevi potpuni? Realnost – Jesu li zahtjevi realni -mogu se ostvariti zadanom tehnologijom i s dostupnim budžetom? Provjerljivost – Mogu li se zahtjevi provjeriti/testirati? 4.4.1 Tehnike validacije Postoje brojne tehnike validacije koje se mogu koristiti pojedinačno ili u kombinaciji: Kontrola zahtjeva –Kontrolni tim sistematično pregledava zahtjeve. Prototipiranje – Korištenje prototipa sustava kako bi se sustav predstavio krajnjim korisnicima i kupcima. Oni mogu eksperimentirati sa sustavom da vide odgovara li njihovim potrebama. Stvaranje test caseova – Svaki zahtjev treba biti napisan tako da se može provjeriti, pa se prave se testovi zahtjeva da se vidi daje li zadani ulaz očekivani izlaz (vrlo često otkriva probleme u zahtjevima). 4.5 Upravljanje zahtjevima Upravljanje zahtjeva podrazumijeva proces upravljanja promjenama zahtjeva za vrijeme prikupljanja zahtjeva, te za vrijeme razvoja sustava. Pratiti individualne zahtjeve i veze među zahtjevima kako bi se mogao procijeniti utjecaj promjena. Uspostaviti formalni proces predlaganja promjena i krenuti s njim čim se izda prva verzija dokumenta. 4.5.1 Plan upravljanja zahtjevima Kako bi se olakšao proces upravljanja zahtjevima za vrijeme procesa prikupljanja zahtjeva potrebno jevoditi računa o: Identifikaciji zahtjeva –Svakizahtjev mora imati jedinstvenuidentifikaciju. Procesu upravljanja promjenom –Predefinirani niz aktivnosti koje procjenjuju utjecaj i trošak promjena. Politika praćenja veza među zahtjevima –Nakoji način čuvati informacije o vezama između pojedinih zahtjeva. Korištenje alata –CASE alat koji će se koristiti za upravljanje promjenama zahtjeva (može biti nekakav sustav po narudžbi, tablice, jednostavne baze podataka). 4.5.2 Upravljanje promjenama zahtjeva Osnovne faze su: Analiza problema – raspraviti u čemu je problem zahtjeva i predložiti izmjenu; Analiza promjene i njen trošak – procijeniti efekt promjene na druge zahtjeve; 21  Promjena implementacije – promijeniti specifikaciju zahtjeva i druge dokumente u skladu s promjenom. 22 5. Predavanje - Modeliranje sustava 5.1 Modeliranje sustava Modeliranje sustava je proces razvoja apstraktnih modela sustava. Pri tome svaki model prezentira drugačiji pogled ili perspektivu sustava. Predstavlja sustav koristeći nekakav grafički zapis, koji se danas gotovo uvijek temelji na Unificiranom jeziku za modeliranje(engl. UnifiedModelingLanguage-UML). Modeliranje sustava pomaže : analitičarima da bolje shvate funkcionalnosti sustava, u komunikaciji s korisnicima. 5.2 Vrste UML dijagrama Dijagrami aktivnosti - prikazuju aktivnosti uključene u proces ili obradu podataka. Use-case dijagrami - prikazuju interakciju između sustava i njegove okoline. Slijedni dijagrami - prikazuju interakciju između aktera i sustava te između komponenti sustava. Dijagrami klasa -koji prikazuju klase objekata u sustavu i povezanost između tih klasa. Dijagrami stanja -prikazuju kako sustav reagira na unutarnje i vanjske događaje. 5.3 Podjela modela Različiti modeli prezentiraju sustav iz različitih perspektiva: Vanjska perspektiva - modelira se kontekst ili okolina sustava. Interakcijska perspektiva - modelira se međudjelovanje između sustava i njegove okoline, odnosno između komponenti sustava. Strukturna perspektiva - modelira se organizacija sustava ili struktura podataka koji se obrađuju u sustavu. Perspektiva ponašanja - modelira se dinamičko ponašanje sustava i kako on reagira na događaje. 5.4 Kontekstni modeli Kontekstni modeli se koriste za ilustraciju radne okoline (konteksta sustava) - oni prikazuju što se nalazi izvan granica sustava, njegov odnos s drugim sustavima. 23  Slika 5-1 Model konteksta 5.4.1 Procesna perspektiva Kontekstni modeli jednostavno prikazuju druge sustave u radnoj okolini, a ne kako se sustav koji se razvija koristi u toj okolini. Zbog toga se kontekstni modeli često koriste u kombinaciji s drugim modelima kao što su modeli poslovnih procesa, tj. procesni modeli. Procesni modeli prikazuju na koji način se sustav koji se razvija koristi u širim poslovnim procesima. Mogu se koristiti i modeli toka podataka kako bi se prokazali procesi zajedno s tokom podataka od jednog procesa prema drugom. Za definiranje modela poslovnih procesa koriste se UML dijagrami aktivnosti. 5.4.2 UML dijagram aktivnosti Dijagram aktivnosti prikazuje aktivnosti koje čine proces sustava kao i tok kontrole s jedne aktivnosti na drugu. Početak procesa se kreće od ispunjenog kruga, a kraj je puni krug u drugom krugu. Pravokutnici s zaobljenim kutovima predstavljaju aktivnosti, tj. pod-procese koji se moraju provesti. Strelice predstavljaju tijek rada iz jedne aktivnosti u drugu. Pune crte se koriste za označavanje koordinaciju aktivnosti.  Kada tijek iz više od jedne aktivnosti vodi u punu crtu, tada sve te aktivnosti moraju biti izvršene, prije nego se aktivnost nastavi.  Kada tok iz pune crte vodi u više aktivnosti one se izvršavaju paralelno. 24  Slika 5-2 Dijagram aktivnosti 5.5 Interakcijski modeli Svi sustavi uključuju interakciju neke vrste. Interakcija s korisnikom (što uključuje korisničke ulaze i izlaze); Važno je jer pomaže da se identificiraju korisnički zahtjevi Interakcija između sustava koji se razvija i drugih sustava; Ističe koji se komunikacijski problemi mogu javiti. Interakcija između komponenti sustava. Pomaže razumjeti hoće li predložena struktura sustava zadovoljiti tražene performanse i ovisnosti. Korištenje UML use-casei slijednih dijagrama se može koristiti za modeliranje interakcija. 5.5.1 Use case modeliranje Svaki use-casepredstavlja zadatak koji uključuje vanjsku interakciju sa sustavom. Akteri u use-caseovima mogu biti ljudi ili drugi sustavi. Predstavljaju se u obliku dijagrama, kao pregled sustava, te u detaljnijem tekstualnom obliku. 25  Slika 5-3 Use case modeliranje 5.5.2 Slijedni dijagram Slijedni dijagrami su dio UML-a i koriste se za modeliranje interakcija između aktera i objekata unutar sustava. Slijedni dijagram pokazuje slijed interakcija koje se odvijaju tijekom određenog use-casea ili use-case instance. Objekti i aktori se prikazuju na vrhu dijagrama s isprekidanom crtom okomito od njih. Interakcije između objekata su označene strelicama. 26  Slika 5-4 Slijedni dijagram 5.6 Strukturni modeli Strukturni modeli softvera prikazuju organizaciju sustava u smislu komponenti koje čine taj sustav, kao i veze među tim komponentama. Strukturni modeli mogu biti statički modeli koji prikazuju strukturu dizajna sustava ili dinamički modeli, koji prikazuju organizaciju sustava u trenutku izvršavanja. Strukturni modeli sustava se mogu napraviti i kada se raspravlja i projektira arhitektura sustava. 5.6.1 Dijagram klasa Dijagrami klasa se koriste pri razvoju objektno-orijentiranog modela sustava kao prikaz klasa u sustavu i povezanost između tim klasama. Klasa predstavlja općenito definiciju nekog od objekata sustava. Veze među klasama ukazuju da postoji nekakav odnos između tih klasa. 5.7 Modeli ponašanja Modeli ponašanja su modeli dinamičkog ponašanja sustava za vrijeme izvođenja. Oni pokazuju što se događa ili ono što bi se trebalo dogoditi kada sustav reagira na podražaj iz okoline. Razlikuju se dvije vrste podražaja: 27  Podaci – u sustav stižu neki podaci i sustav ih treba obraditi. Događaji - neki dogodi se neki događaj i sustav treba reagirati na njega.U nekim slučajevima događaji mogu biti povezani s podacima, iako to nije uvijek slučaj. 28