Uvod u softversko inenjerstvo Software engineering Poetci 1968. je pojam prvi put upotrebljen na NATO konferenciji Razlog? projekti koji su viestruko premaili planirane trokove i rokove. Zakljuak tehnike individualnog programiranja se ne mogu uspeno preslikati na velike programe gde uestvuje veliki broj programera Reenje potreba za sloenijim metodama razvoja softvera, koje bi bile u stanju da kontroliu kompleksnost velikog softverskog projekta. ta pokazuju istraivanja? FAQs about software engineering ta je softver ili softverski proizvod? ta je softversko inenjerstvo? Kakva je razlika izmeu softverskog inenjerstva i raunarskih nauka? Kakva je razlika izmeu softverskog inenjerstva i sistemskog inenjerstva? ta je softverski proces? ta je model softverskog procesa? ta je metoda razvoja softvera? Koliki su trokovi softverskog proizvoda? ta su CASE alati? ta su atributi dobrog softvera? Softverski proizvod ili softver Softverski proizvod je skup raunarskih programa i pripadajude dokumentacije, koji je stvoren zato da bi se prodao.

Treba da ima sledede atribute kvaliteta: Mogunost odravanja. Menjanje u skladu s promenjenim potrebama korisnika. Pouzdanost i sigurnost. Softver se mora ponaati na predvidiv nain. Efikasnost. Softver mora imati zadovoljavajude performanse i koristiti hardverske resurse na tedljiv nain. Upotrebljivost. Softver treba da radi ono ta korisnici od njega oekuju, a korisniki interfejs treba da bude zadovoljavajudi, i za njega mora postojati dokumentacija. Softverski proizvod moe biti razvijen za odreenog klijenta ili za trite generalno. Softverski proizvod moe biti: Generiki razvijen sa namerom da se proda velikom broju razliitih klijenata, npr. Excel, Word... Narueni (bespoke, custom) razvijen za odreenog klijenta prema zahtevanoj specifikaciji, npr. control systems for electronic devices, systems written to support a particular business process air traffic control systems. Softversko inenjerstvo Dakle, softversko inenjerstvo se bavi modelima, metodama i alatima koji su nam potrebni da bi na to jeftiniji nain mogli proizvoditi to kvalitetniji softver. Software engineering IEEE Definition Primena sistematinog i ogranizovanog pristupa razvoju, funkcionisanju i odravanju softvera, to predstavlja primenu inenjerstva na softver. (IEEE Std 610-1990.) Input: opis problema od strane klijenta Output: softverski sistem kao dugorono reenje klijentovog zahteva. Softverski inenjeri Nisu samo programeri koji slede instrukcije, ved... Razlika izmeu softverskog inenjerstva i raunarskih nauka? Softverski proces je skup aktivnosti i pripadajudih rezultata iji je cilj razvoj ili evolucija softvera.

Osnovne aktivnosti softverskog procesa su: specifikacija, dizajniranje, implementacija, verifikacija, validacija i odravanje. Generike aktivnosti u svim softverskim procesima su: specifikacija softvera ta bi sistem trebao da radi (funkcionalnosti softvera) i koja ogranienja moraju biti ispotovana. razvoj softvera produkcija softvera prema zadatoj specifikaciji validacija softvera provera valjanosti (da li je to ono to je naruilac posla traio) odravanje softvera dorada programa prema izmenama u zahtevima naruioca. Model softverskog procesa Pojednostavljen prikaz softverskog procesa, posmatran iz odreene perspektive. ili Model je prikaz softverskog procesa, kojim se odreuje poeljni nain odvijanja i medusobnog povezivanja aktivnosti. Primeri perspektiva: tok procesa (workflow) prikazuje redosled aktivnosti Na primer, model moe zahtevati sekvencijalno ili simultano odvijanje aktivnosti. tok podataka (Data-flow) prikazuje tok informacija uloge/akcije (Role/action) prikazuje ta ko radi Metoda razvoja softvera Metoda razvoja softvera je konkretizacija odabranog modela za softverski proces. Metoda uvodi specifinu terminologiju, deli osnovne aktivnosti u pod-aktivnosti itd. Trokovi softverskog proizvoda

Potpuna cena razvoja softvera ima raspodelu kao na slici: Trokovi variraju zavisno od vrste sistema koji se razvija, kao i zahteva po pitanju performansi i pouzdanosti. CASE alati (Computer Aided Software Engineering) CASE alati su softverski paketi koji daju automatizovanu podrku za pojedine aktivnosti unutar softverskog procesa. Alati su napravljeni u skladu sa odreenom metodom razvoja softvera, implementiraju pravila iz te metode, sadre editore za odgovarajude dijagrame i slue za izradu odgovarajude dokumentacije. CASE alati namenjeni za podrku analize i razvoja se nazivaju - upper-CASE alati jer podravaju rane faze. CASE alati koji podravaju implementaciju i testiranje kao to su debuggers, program analysis systems, test case generators, program editors se nazivaju lower-CASE alati. Atributi dobrog softvera

Maintainab ility mogudno st odravanj a

Dependabil ity pouzdano st

Usability upotreblji vost

Efficiency efikasnost

Softver bi trebao da prui zahtevanu funkcionalnost i performanse korisniku u zavisnosti od znaaja okruenju. Primeri: a banking system must be secure, an interactive game must be responsive, a telephone switching system must be reliable, etc. Generalno atributi dobrog software-a su

Inenjerstvo zahtijeva (Requirements engineering)

Softverski proces je skup aktivnosti i pripadajudih rezultata iji je cilj razvoj ili evolucija softvera. Osnovne aktivnosti softverskog procesa su: specifikacija zahtijeva, razvoj, validacija evolucija Specifikacija zahtijeva Specifikacija je proces evidentiranja zahtijeva Zahtijev definie TA sistem treba da radi a ne KAKO Zahtijev moe biti opisan na visokom nivou apstrakcije (bez detalja, uopten) ili kao detaljni funkcionalni zahtijev. Vrste zahtijeva: korisniki sistemski funkcionalni nefunkcionalni Slededi korak u procesu razvoja softvera Ininjerstvo zahtijeva (requirement engineering RE) RE je proces koji se sastoji od izdvajanja (otkrivanja), analize, dokumentovanja i validacije prikupljenih zahtijeva. Svaki proces razvoja softvera mora obuhvatiti ininjerstvo zahtijeva. Zato ininjerstvo zahtijeva? Prednosti dokumentovanja zahtijeva Opisuju se funkcionalnosti sistema za korisnike ( ne za programere) Smanjuje se mogudnost greaka u razvoju Izjene zahtijeva su vrlo skupe i kotaju:

3 x vie u toku faze dizajna 5-10 x vie u fazi implementacije 10-100 x vie kada je sistem implementiran. [kompletan kod je zavren] Zato ininjerstvo zahtijeva? 2/3 greaka u softverskim sistemima nastaje u toku faze ninjerstav zahtijeva. Pailjivo definisanje zahtijeva ne znai da nede biti kasnijih izmjena U prosjeku 25% izmjena u razoju softvera odnosi se na izmjenu zahtijeva. U sluaju da je projekat zavren ovo bi znailo 70-80% izmjena u svim ostalim fazama razvoja. Vano je planirati tako da se uzimaju u obzir mogude izmjene zahtijeva. Ininjerstvo zahtijeva (RE) RE obuhvata pet aktivnosti: Studija izvodljivosti (Feasibility study) Izdvajanje (otkrivanje) zahtijeva i analiza Specifikacija zahtijeva Validacija zahtijeva Dokumentovanje zahtijeva 1. Studija izvodljivosti (1) Predlae nain rjeavanja problema u okviru datih ogranienja Radi se timski (obino traje 2-3 nedelje) Obrauje komercijalnu stranu, a ne tehniku Ciljevi: utvrivanje tanih potreba korisnika analiza mogudih rjeenja identifikacija najpovoljnijeg rjeenja utvrivanje projektnih zahtijeva

1. Studija izvodljivosti (2) Deinie: potrebnu opremu potrebne ulaze oekivane izlaze Analizira: uklapanje u organizaciju sistema oekivanu dobit (cost-benefit) Obuhvadena podruja: operativna izvodljivost tehnika izvodljivost ekonomska izvodljivost (opravdanost) Aktivnosti u ininjerstvu zahtijeva (RE)

Feasibility study

Requirements elicitation and analysis

Requir ements specification Requirements validation

Feasibility report System models User and system requirements

Requirements document Aktivnost 2 - Spiralni proces Koraci u izdvajanju (otkrivanju) zahtijeva

Requirements validation Domain understanding

Requir ements definition and specification

Prioritization

Process entry

Requirements collection

Conflict resolution

Classification Koraci spiralnog procesa Otkrivanje (prepoznavanje) zahtijeva Interakcija sa nosiocima projekta u pronalaenju njihovih zahtijeva.

Klasifikacija i organizacija zahtijeva Grupiu srodne zahtijeve i organizuju ih u koherentne grupe.

Prioritetnost i pregovori Prioritetnost zahtijeva reava konflikte izmeu zahtijeva

Dokumentacija zahtijeva Zahtijevi su dokumentovani i ubaeni u slededi krug spirale.

2. Izdvajanje (otkrivanje) prikupljenih zahtijeva (1) Korisniki zahtijevi Prvi pokuaj da se zahtijevi opiu Definiu funkcije i ogranienja sistema Predstavlaju se dijagramima i/ili tekstom Razumljivi su svima

Sistemski zahtievi Detaljno definiu f-je i ogranienja sistema Koriste ih dizajneri i programeri Precizno opisuju sve sluajeve ponaanja Predstavlaju se tekstualno, tabelarno, grafiki ili pomodu neke formalne specifikacije (razumiljivo malom broju strunjaka). 2. Izdvajanje (otkrivanje) prikupljenih zahtijeva (2) Funkcionalni zahtijevi Definiu funkcije sistema (funkcionalnost za korisnike) ta bi sistem trebao da radi a ta ne u odreenim siituacijama. Ne-funkcionalni zahtijevi Ogranienja funkcija sitema Primjer ogranienja: Vremensko ogrnienje, implementacija u odreenom programskom jeziku (CASE, language, development method), primjena specifinih standarda i sl. Domenski zahtijevi Potiu od ogranienja domena za koji se aplikacija razvija Mogu biti funkcionalni i ne-funkcionalni Primjeri: Mediciina, bibliotekarstvo, hemija itd. Napomena: Mogu postojati korisniki i sistemski funkcionalni i ne-funkcionalni zahtijevi. Ne funkcionalni zahtijevi Ne funkcionalni zahtijevi mogu biti vaniji za procjenu uspjeha u razvoju softverskog sistema. Mogu biti kategorisani kao: Zahtijevi vezani za ponaanje sistema Primjer: brzina rada, pouzdanost, lakoda koridenja Organizacioni zahtijevi Primjer: zahtijevi za implementaciju, isporuku i sl.

Spoljanji zahtijevi Primjer: Interoperabilnost, zakonski propisi, standardi i sl. Validacija zahtijeva Valjanost. Da li sistem obavlja funkcije sa najboljom podrkom koja je korisnicima potrebna? Konzistencija. Da li postoje bilo kakvi koflikti meu zahtijevima? Kompletnost. Da li su ukljuene sve funkcije koje su potebne korisniku? Realnost. Da li zahtijevi mogu biti implementirani usled zbog dostupnog budeta i tehnologije? Proverenost. Da li zahtijevi mogu biti provjereni?

Tehnike validacije zahtijeva Provjera zahtijeva Sistematsko runo analiziranje zahtijeva Prototipovi Koriste se izvrni modeli sistema da se provjere zahtevi. Generisanje test-sluaja Razvijanje testova za zahtijeve. Pregled i provjera zahtijeva Redovni pregled zahtijeva se odvija u toku formulisanja definicija zahtijeva. Oba klijenta i ugovarai bi trebali da budu ukljueni u pregled. Pregledi mogu biti formalni (sa kompletnom dokmentacijom ili informativno) Dobra komunikacija izmedju kreatora, kupaca i korisnika moe rijeiti probleme u ranoj fazi. ta se provjerava? Da li se zahtijevi zaista mogu testirati? Da li su zahtijevi pravilno shvadeni? Mogu li se zahtijevi promijeniti bez velikih uticaja na druge zahteve? Menadment zahtijevima U gotovo svim sistemima, zahtijevi se menjaju. Razlozi za to su:

ljudi vremenom bolje razumiju ta zapravo ele da im softver radi; organizacija koja kupuje sistem se neprestano mijenja; modifikacije se deavaju na hardveru, softveru i okruenju. Proces upravljanja promjenama u zahtijevima se naziva upravljanje ili menadment zahtijevima. Zahtijevi i dizajn sistema Zahtijevi opisuju ta sistem treba da radi a ne kako. U praksi zahtijevi definiu dizajn sistema. Arhitektura sistema mora biti dizajnirana u skladu sa zahtijevima; Sistem moe biti povezan sa drugim sistemom koji generie zahtijeve. Dizajn sistema zavisi od domena u kojem se sistem razvija. Kako se zahtijevi predstavljaju Zahtijevi se sakupljaju i zapisuju u prirodnom jeziku. Prirodni jezik nije pogodan za predstavljanje zahtijeva. Problemi sa prirodnim jezikom esto zahtijevi ne mogu biti dovoljno jasno opisani (dvosmislenost) mogude je istu stvar opisati (i protumaiti) na razliite naine nije pogodan za opis sistemskih zahtijeva Alternative prirodnom jeziku Struktuirani prirodni jezik Jezici za opis dizajna sistema (design description language) Grafika notacija Matematika specifikacija Alternative prirodnom jeziku Struktuirani prirodni jezik Svi zahtijevi piu se na standardan nain.

Koriste se predefinisani templejti Terminologija je uglavnom limitirana standardima. U SI postoje meunarodni standardi za pisanje dokumentacije vrednovanje softvera (provjera kvaliteta) testiranje i sl. Meunarodni standardi ISO/IEC 14102 Software Engineering ISO standardi programskih jezika ISO/IEC standardi baza podataka IEEE standardi otvorenih sistema ISO i DoD standardi zatite ISO, X/Open i OSF standardi za grafiku ISO, ANSI i IEEE komunikacioni standardi IEEE standardi softverskog inenjerstva IEEE 1012-1986 Software Verification & Validiation Plans IEEE 828-1990 Softvare Configuration Management Plan IEEE 1058.1-1987 Software Project Management Plan IEEE 830-1993 Software Requirements Specification IEEE 982.2-1988 IEEE Guide for The Use of IEEE Standard Dictionary of Measures to Produce Relible Softvare IEEE standardi softverskog inenjerstva IEEE 730-1989 Software Quality Assurance Plans IEEE P1233 Guide to Developing System Requirements Specifications IEEE 1016.1-1993 Software Design Document IEEE 1044.1 Severity Clasification

IEEE 1008-1987 Road Map for Unit Testing ANSI/IEEE 829-1991 Software Test Documentation IEEE 1219-1992 Software Maintanance Specifikacija pomodu formi Definicija funkcije ili entiteta. Opis ulaznih parametara i odakle potiu. Opis izlaznih parametara i emu su namijenjeni. Navoenje ostalih entiteta (ukoliko su potrebni). Pred i post uslovi (ukoliko postoje). Specifikacija pomodu formi Tabelarna specifikacija Koristi se kao dodatak prirodnom jeziku. Posebno korisno kada treba definisati vie mogudih tokova (akcija sistema) u zavisnosti od ulaznih parametara. Tabelarna specifikacija Grafiki modeli UML dijagrami UML dijagrami su iroko prihvaden nain za predstavljanje specifikacija sistema Postoji veliki broj razliitih UML modela kojima je mogude opisati sistem sa razliitih aspekata. U okviru specifikacije zahtijeva koriste se: Use case dijagrami ili Dijagrami aktivnosti Napomena: Nije potrebno koristiti oba UML dijagrama - u zavisnosti od prirode sistema treba izabrati dijagram. Pojedini sluajevi koridenja mogu se detaljnije opisati pomodu dijagrama aktivnosti. Sequence diagrams These show the sequence of events that take place during some user interaction with a system. You read them from top to bottom to see the order of the actions that take place.

Cash withdrawal from an ATM Validate card; Handle request; Complete transaction. Dijagram sekvenciATM Card PIN request PIN Option menu invalid card Wit hdraw reques t Amount request Amount Debit (amount) ins ufficient cas h Card Card removed Cas h Cas h removed Receipt Complete transaction Debit res ponse Balance reques t Balance Handle reques t Validate card Databas e

Card number Card OK

Use case dijagram

Specifikacija interfejsa Sistemi su u interakciji sa drugim sistemima putem interfejsa. Zahtijevi mogu da sadre specifikaciju interfejsa . Koriste se jezici za opis dizajna sistema. Opis interfejsa Krajnji rezultat ininjerstva zahtijeva Krajnji rezultat RE je specifikacija sistema (software requirement document - SRS) Sastoji se iz:

Specifikacije korisnikih zahtijeva Specifikacije sistemskih zahtijeva Specifikacije modela sistema Faze razvoja softverskog sistema Specifikacija zahtijeva definie problem koji treba rijeiti. Nakon analize i specifikacije zahtijeva slijedi dizajniranje sistema. Softverski dizajn je kreativni proces pretvaranja problema u rjeenje. Opis rjeenja se takoe naziva dizajn. Priroda rjeenja moe da se mijenja i u toku opisa ili implementacije sistema. Konceptualni i tehniki dizajn Dizajn je iterativni proces koji iz dva dijela. Prvo se formira konceptualni dizajn ili dizajn sistema koji opisuje korisniku ta de sistem da radi. Poto klijent odobri konceptualni dizajn, vri se prevoenje u mnogo detaljniji dokument tehniki dizajn. Tehniki dizajn omogudava sistemskim ininjerima i programerima da utvrde karakteristike sistema (koji softver i hardver de se koristiti za rjeavanje problema). Dobar konceptualni dizajn Pisan jezikom klijenta Ne sadri tehnike izraze Opisuje funkcije sistema Ne zavisi od implementacije Povezan sa dokumentima specifikacije zahtjeva Omogudava klijentu da shvati to de sistem da radi Objanjava vidljive, spoljanje karakteristike sistema. Dobar tehniki dizajn Opisuje: Konfiguraciju hardvera

Hijerarhiju i funkcije softverskih komponenti Korisniki interfejs Ulaze i izlaze sistema Mrenu arhitekturu Strukturu i tokove podataka Tehnike modelovanja sistema (1) Izdvojidemo najede koridenje savremene tehnike za modelovanje sistema. To su: Modeli konteksta Modeli ponaanja Modeli podataka Objektni modeli CASE (Computer-Aided System/Software Engineering )

Primer:Sistem za galeriju

Dijagram konteksta(prikazuje granice sistema)

Dijagram dekompozicije kompleksnog sistema

2. Modeli ponaanja (1) Vedina poslovnih sistema je zasnovana na podacima (data-driven) i njima se upravlja na osnovu unetih podataka. Najede je za poslovne sisteme dovoljno samo napraviti dijagram toka podataka, da bi se prikazalo ponaanje sistema. Nasuprot tome, sistemi za rad u realnom vremenu su esto voeni dogaajima (event-driven) i za njih je najpogodniji model stanja koji prikazuje ponaanje sistema za razliite dogaaje. Objektni modeli (1) Objektno orijentisano modelovanje deo objektno orijentisanog razvoja sistema gdje se objektno-orijentirana strategija protee kroz razvojni proces: Objektno-orijentisana analiza Objektno-orijentisani dizajn

Objektno-orijentisano programiranje Objektno orjentisana anliza i dizajn sistema Metoda je prikladna za dizajn sistema koji rade u realnom vremenu. Metoda podrava klase, objekte, nasljeivanje, slanje poruka. Faze metode su: Identifikacija objekata i klasa Identifikacija semantike objekata (interfejs objekata, ponaanje objekata) Logiki dizajn (relacije klasa i objekata) Implementacija UML (http://www.uml.org) UML je grafiki jezik za: vizualizaciju UML je vizuelni, grafiki jezik; specifikaciju pomodu UML jezika formiraju se precizni, nedvosmisleni i potpuni modeli;

konstrukciju pomodu jezika UML konstruie se softverski sistem koji se posle moe implementirati; dokumentovanje pomodu jezika UML mogu se dokumentovati zahtijevi, arhitektura, projekat, izvorni kod itd. UML je standardni vizuelni jezik za modelovanje dominantno, ali ne iskljuivo, sloenih softverskih sistema.koji je postavljen kao standard od OMG (Object Management Group http://www.omg.org). ta je cilj UML jezika ? UML je razvijen sa ciljem da pojednostavi veliki broj OO razvojnih metoda. UML se koristi za modelovanje softverskih sistema naroito onih koji se zasnivaju na OO metodologiji.

Generalni ciljevi kojima UML jezik tei: stvaranje jezika za modelovanje kojim je mogude razvijati i razmjenjivati modele sa odreenim znaenjem. nezavisnost od programskih jezika i razvojnih procesa pruanje formalne osnove za razumijevanje jezika za modelovanje ta je cilj UML jezika ? (2) podsticanje razvoja OO programskih jezika podrka apstraktnih razvojnih pojmova kao to su saradnja, okvirni rad, uzorci i komponente (collaborations, frameworks, patterns, and components) integrisanje i razvijanje praktinim iskustvom. Ko su korisnici UML-a? Korisnici UML-a su: Sistem-analitiari i krajnji korisnici specificiraju zahtijevanu strukturu i ponaanje sistema Rukovodioci projekta voenje i usmjeravanje kadrova i upravljanje resursima Projektanti projektuju sistem na osnovu zahtijeva Razvojni ininjeri - transformiu projekat u izvrni kod Kontrolori kvaliteta provjeravaju strukturu i ponaanje sistema

Klasifikacija UML dijagrama

UML pogledi na arhitekturu sistema (4+1 Arhitectural Views)

UML 9 osnovnih dijagrama

statiki aspekt sistema dinamiki aspekt sistema aspekt implementacije sistema

Modeli za softverski proces Uesnici u razvoju softverskog procesa Broj osoba koje rade na razvoju sotfvera zavisi od veliine i sloenosti projekta, ali ... Uesnici u razvoju softverskog procesa ULOGE: Kupac kompanija koja plada za softverski sistem koji se razvija Korisnik stvarno radi na sistemu Razvojni tim pravi softverski sistem za kupca tj. naruioca sastoji se od softverskih inenjera, ali svaki od njih moe da se specijalizuje za poseban aspekt razvojnog procesa.

ivotni ciklus softvera (Software lifecycle) Proces razvoja softvera se moe predstaviti nizom koraka poev od formulisanja osnovnih koncepata, preko implementacije do isporuke i odravanja, i naziva se

ivotni ciklus softvera Analiza zahteva i specifikacija Projektovanje Implementacija Testiranje Integracija Isporuka Odravanje Svaka faza ivotnog ciklusa ima sopstvene aktivnosti i resurse. ivotni ciklus softvera - praktini opis -

Projekat zapoinje klijentovim zahtevima za novi sistem. Kreira se Funkcionalna specifikacija za klijenta. Ovim se navodi ta sistem treba da radi, ali ne i kako de to raditi. To je lista zahteva koju sistem mora zadovoljavati. Jednom, kada klijent prihvati Funkcionalnu specifikaciju, kreira se Specifikacija dizajna. Ovim se definie kako de sistem biti razvijen. Softver se razvija prema Specifikaciji dizajna. Softver se testira da se proveri da li odgovara Specifikaciji dizajna. Softver se testira prema Funkcionalnoj specifikaciji. Da li zadovoljava sve zahteve? Jedanput kada se testiranje uspeno zavri, softver se isporuuje i instalira. Sofver se zatim odrava prema povremenim zahtevima klijenata. ivotni ciklus softvera ukljuuje sledede procedure: Definisanje ciljeva Odreivanje glavnih ishoda tj. rezultata projekta. Analiza zahteva i specifikacija, tj. Prikupljanje, pregled i formulisanje klijentskih zahteva i procena mogudih ogranienja. Generalni dizajn Generalni zahtevi u pogledu arhitekture aplikacije. Detaljni dizajn, precizira definiciju svake komponente aplikacije. Programiranje je implementacija pomodu nekog programskog jezika u cilju kreiranja funkcija bududeg sistema, koje su definisane tokom faze dizajna. Testiranje modula aplikacije, individualno testiranje svakog modula aplikacije da se osigura da su kreirani prema poetnoj specifikaciji. Integracija, osigurava da se razliiti moduli integriu u jednu aplikaciju. Beta testiranje (ili debugging), proverava da li softver odgovara na poetne zahteve. Documentacija dokumentuje neophodne informacije za korisnike softvera i bududi razvoj. Implementacija Odravanje, sve korekcije (korektivno odravanje) i manji softverski update (tekude odravanje) lanovi razvojnog tima

lanovi razvojnog tima Analitiar zahteva komunicira sa kupcem, da bi se ono to kupac hode razloilo na pojedinane zahteve. Kada zahtevi postanu dokumentovani, analitiar radi sa projektantima na generisanju opisa funkcija sistema. Dalje, programeri piu kod koji implementira ono to je formulisano u zahtevima. Testni inenjeri rade na otkrivanju greaka koje previde programeri. Kada razvojni tim bude zadovoljan sa kvalitetom sistema, tim za testiranje i kupac zajedno rade na verifikovanju celokupnog sistema u odnosu na postavljene zahteve. Instruktori obuavaju korisnike za operativno koridenje sistema. Modeli softverskog procesa

Model za softverski proces je idealizovani prikaz softverskog procesa, kojim se odreduje poeljni nain odvijanja i medusobnog povezivanja osnovnih aktivnosti. Na primer, model moe zahtevati sekvencijalno odnosno simultano odvijanje aktivnosti. Razliiti pristupi u ivotnom ciklusu softvera su potrebni i svaki pristup je pogodan za odreenu primenu. Primeri modela: Model vodopada (Waterfall Model ) Softverski proces je gradjen kao niz vremenski odvojenih aktivnosti. Prednosti modela vodopada:Implementacija Analiza i zahtevi

Projektovanje

Model omoguduje lako pradenje stanja u kome se softverski proces nalazi. Model je dobro prihvaden od rukovodstva. Mane modela vodopada su sledede Faze je u praksi teko razdvojiti, pa dolazi do naknadnog otkrivanja greaka i vradanja u prethodne faze. Zbog tendencije da se zbog potovanja rokova u odredenom trenutku zamrzne pojedina faza, moe se desiti da je sistem u trenutku putanja u rad ved neauran i zastareo. Model treba koristiti za velike sisteme gde postoje jasni zahtevi. Model evolucijskog razvoja ili Prototipski modelTestiranje

Na osnovu priblinog opisa problema razvija se polazna verzija sistema koja se pokazuje korisniku. Na osnovu korisnikovih primedbi, ta polazna verzija se poboljava, opet pokazuje, itd. Nakon dovoljnog broja iteracija dobija se konana verzija sistema. Unutar svake iteracije, osnovne aktivnosti se obavljaju simultano i ne razdvajaju se. Prednosti modela evolucijskog razvoja Model proizvodi brz odgovor na zahteve korisnika. Postoji mogudnost da se specifikacija postepeno razvija u skladu sa sve boljim korisnikovim razumevanjem problema. Mane modela evolucijskog razvoja Proces nije transparentan za rukovodstvo, tj. oni ne mogu oceniti koji deo posla je obavljen i kada de sistem biti zavren. Konani sistem je obino je loe strukturiran zbog stalnih promena, i nepogodan za odravanje. Zahtevaju se posebni alati i natproseni softverski inenjeri. Model se uspeno koristi za razvoj malih sistema sa kratkim ivotnim vekom, pogotovo za sisteme sa nejasnim zahtevima. Model orijentisan ka ponovnoj upotrebi (reuse-oriented development) Model polazi od pretpostavke da ved postoje gotove i upotrebljive softverske celine ili delovi ranije razvijenih sistema.

Novi sistem treba u to vedoj meri realizovati spajanjem postojedih delova.

Specifikacija zahteva

Analiza raspoloivih delova

Modifikacija zahteva

Projektovanje sistema uz viestruku upotrebu delova

Implementacija i integracija

Verifikacija i validacija sistema

Prednosti modela Smanjuje se koliina softvera koga stvarno treba razviti, ime se smanjuje vreme, troak i rizik. Stavlja se oslonac na proverene i dobro testirane delove softvera. Mane modela Zbog kompromisa u specifikaciji mogude je da sistem nede u potpunosti odgovoriti stvarnim potrebama korisnika. Delimino je izgubljena kontrola nad evolucijom sistema, bududi da ne upravljamo razvojem novih verzija koridenih delova. Oekuje se da de ovaj model postati prevladavajudi u 21. veku, jer je broj gotovih reenja sve vedi, a korisnici imaju sve manje vremena za ekanje reenja. Model inkrementalnog razvoja

Definii okvirne zahteve

Rasporedi zahteve na inkremente

Projektuj arhitekturu sistema

Specificiraj, projektuj i implementiraj novi inkrement

Verifikuj i validiraj novi inkrement Sistem je nedovren

Integrii novi inkrement

Krajnji sistem

Hibrid modela vodopada i modela evolucijskog razvoja. Sistem se opet razvija u nizu iteracija, ali pojedina iteracija ne dorauje ved realizovani deo sistema, ved mu dodaje sasvim novi deo - inkrement. Razvoj jednog inkrementa u okviru jedne iteracije odvija se po bilo kom modelu - na primer vodopad. Prednosti modela Proces je prilino transparentan za rukovodstvo, jer je vidljivo do kog smo inkrementa doli. Korisnici ne moraju dugo ekati da bi dobili prvi inkrement koji zadovoljava njihove potrebe. Razvoj sledi prioritete. Mane modela Ponekad je teko podeliti korisnike zahteve u smislene inkremente. Bududi da celokupni zahtevi nisu dovoljno razradjeni na poetku, teko je odrediti zajednike module koji su potrebni raznim inkrementima i koji bi morali biti implementirani u prvom inkrementu. Ovo je vrlo upotrebljiv model koji se intenzivno koristi u praksi, na primer u varijanti extreme programming. Agilne metode (Agile methods) Disciplina za nain kako se sofver dokumentuje, razvija, testira itd. Karakteristika: fleksibilnost Treba brzo odgovoriti zahtevima trita Mogudnost dodavanja i menjanja zahteva u kasnim fazama ivotnog ciklusa Agilne metode su najpogodnije za male/srednje poslovne sisteme "Agilne metode" razvoja softvera skraduju vreme ivotnog ciklusa softvera (ime se ubrzava razvoj softvera), tako to se prvo razvija prototip, a zatim integrie funkcionalnost. Na ovaj nain se brzo odgovara na zahteve naruioca posla. Agilni manifest: Pojedinci imaju vedu vanost od procesa i alata. Timovi se samoorganizuju i komuniciraju direktno licem u lice, a ne preko dokumentacije.

Uloiti vreme u izradu softvera, umesto u izradu dokumentacije. Primarno merilo uspeha je stepen do koga softver radi ispravno. Zajedniki rad sa naruiocem u kljunim aspektima razvojnog procesa. Cilj je odgovoriti na promene, a ne na planiranje i pradenje plana, jer je nemogude da se svi zahtevi predvide na poetku razvojnog procesa. Ekstremno programiranje - XP (eXtreme Programming) Skup tehnika za nivelisanje kreativnosti projektnog tima uz minimizaciju prekomernog administriranja. best-known agile method Karakteristike XP Nove verzije mogu biti napravljene vie puta dnevno Inkrementi se daju kupcu svakih 15 dana Svi testovi moraju biti uradjeni za svaku verziju i verzija se prihvata samo ako su svi testovi bili uspeni Upravljanje softverskim projektom (software project management) potrebno je zato da bi se softver razvio na vreme i u okvirima planiranih trokova. Posao upravljanja softverskim projektom obavlja softverski manader. Osobine softverskog projekta razlikuje se od klasinog tehnikog projekta u slededem: Proizvod je neopipljiv. Teko je videti rezultat i proceniti koliki deo posla je obavljen. Nema standardnog procesa. Postoje razne metode i alati, ali se ne zna ta je najpogodnije u datim okolnostima. Projekt je obino neponovljiv. Stara iskustva obino nisu primenjiva. Pojavljuju se nepredvidjeni problemi. Tehnologija se brzo menja. Zbog ovih osobina, upravljanje softverskim projektom je izuzetno teak manderski zadatak i zahteva izuzetno dobrog manadera. Poslovi softverskog manadera Izmeu ostalog ukljuuju sledede:

pisanje predloga projekta, procenjivanje trokova projekta, planiranje i pradenje projekta, izbor i ocenjivanje saradnika, pisanje izvetaja i prezentovanje. Planiranje i pradenje projekta Uvod. definiranje ciljeva i ogranienja. Organizacija. Rasporedjivanje ljudi i drugih resursa na aktivnosti. Analiza rizika. Opisivanje mogudih rizika i strategija smanjenja rizika. Resursi. Hardverski i softverski zahtevi. Podela poslova. Aktivnosti, ogranienja, zadaci. Raspored rada. Definisanje trajanja aktivnosti, njihova medjuzavisnost, alokacija zadataka. Mehanizmi izvetavanja. Pradenje izvrenja aktivnosti, izvetaji rukovodstva. Upravljanje rizicima Rizini inioci po Boehmu: Manjak osoblja Nerealni rokovi i budeti Razvoj pogrenih softverskih funkcija Razvoj pogrenog korisnikog interfejsa Pozladivanje (dodavanje vie nego to je potrebno) Neprekidni niz izmena u zahtevima Nedostatak performansi u realnom vremenu

Zahtevi i specifikacije Zahtevi i specifikacije

poetna faza softverskog procesa. Analiziraju se zahtevi bududeg sistema. Rezultat je dokument o zahtevima, koji opisuje ta sistem treba da radi. ta je zahtev Zahtev moe biti opisan na visokom nivou apstrakcije (bez detalja, uopten) ili kao detaljni funkcionalni zahtev. Zahtevi mogu imati dvojnu ulogu: 1. osnova ugovaranje novog posla (tada moraju biti razumljivi za interpetaciju) 2. osnova samog ugovora (tada moraju biti detaljno opisani)

Apstrakcija zahteva (primer Davis) Vrste zahteva Primer Korisniki zahtev LIBSYS sistem treba da vodi evidenciju o svim zahtevima za dobijanje licence za tampanje udbenika u celoj zemlji. Sistemski zahtevi Svi formulari za zahteve LIBSYS sistemu moraju biti indeksirani po autoru, naslovu i dobavljau. Zahtevi koji se upuduju LIBSYS sistemu se moraju uvati pet godina od datuma prijema. Funkcionalni i nefunkcionalni zahtevi Funkcionalni zahtevi Opisuju ta sistem treba da obezbedi, kako sistem treba da reaguje na odgovarajude ulaze i kako sistem treba da se ponaa u specifinim situacijama. Nekada ovi zahtevi opisuju i ta sistem ne bi smeo da radi.

Nefunkcionalni zahtevi

ogranienja funkcionalnosti sistema, npr. vremenska ogranienja i ogranienja usled standarda. Najede se odnose na sistem kao celinu, a ne na pojedinu funkciju.

A library system that provides a single interface to a number of databases of articles in different libraries. Users can search for, download and print these articles for personal study. The user shall be able to search either all of the initial set of databases or select a subset from it. The system shall provide appropriate viewers for the user to read documents in the document store.

Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the accounts permanent storage area. Problemi u zahtevima Problemi nastaju kada zahtevi nisu dovoljno dobro opisani. Dvosmisleni zahtevi se mogu interperetirati na razliite naine od strane korisnika i softverskih inenjera. Razmotrite termin appropriate viewers iz 2. zahteva. Korisniko vienje preglednici za svaki razliiti tip dokumenta; Vienje inenjera obezbediti tekstualni preglednik sa prikazom sadraja fajlova. Kompletnost i konzistentnost zahteva U principu, zahtevi treba da zadovolje i kompletnost i konzistentnost.

Kompletnost Treba da sadre opise svih zahtevanih specifinosti. Konzistentnost Ne sme da postoji kontradiktornost u opisima zahteva. U praksi je gotovo nemogude proizvesti kompletan i konzistentan dokument o zahtevima. Nefunkcionalni zahtevi - Primeri The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.

Ovaj zahtev ne govori nita u vezi funkcionalnosti sistema i jasno identifikuje sistemski zahtev, a ne funkcijski. Ovaj zahtev je ukljuen da bi se izbegli problemi rada sa razliitim browserima. The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95External requirement. Ovaj zahtev navodi das sistem mora biti razvijen prema standardnom procesu kompanije. Evidentiranje zahteva = razumevanje osnovnih problema i potreba naruioca Primer sistema: Generisanje platnih listida Mogudi zahtevi: Listide treba izdavati na 15 dana Direktna uplata depozita za radnike sa odreenom visinom plate Pristup sistemu za obraun plate sa vie razliitih lokacija u okviru kompanije Obavezan prikaz opisa naina prorauna plate na samom listidu Itd... Traimo zahteve koji identifikuju: Kljune entitete (npr. Radnik je osoba koju plada kompanija) Entitete koji namedu ogranienja (npr. Radnik ne moe biti pladen za vie od 40 sati nedeljno) Odnose meu entitetima (npr. Radnika X nadgleda radnik Y i svaki radnik ima nekog nadreenog radnika) VANO Zahtevi ne odreuju nain implementacije sistema. To jest, zahtevi su okrenuti naruiocu i problemu, a ne reenju ili implementaciji. ZAKLJUAK: Zahtevi oznaavaju kakvo ponaanje naruilac eli, bez opisa kako de to ponaanje biti ostvareno. U toku ove faze pravi se odluka koje zahteve de softverski sistem da ispuni

(nasuprot zahtevima koji realizuju hardverski ureaji, drugi softverski sistemi, operateri ili korisnici). Izvrilac: analitiar sistema Specifikacija: Proces evidentiranja zahteva Aktivnost specifikacije se moe podeliti u podaktivnosti: Studija izvodljivosti. Procenjuje se da li se uocene potrebe korisnika mogu zadovoljiti uz pomod dostupnih hardverskih i softverskih tehnologija, da li bi predloeni sistem bio isplativ u poslovnom smislu, i da li sistem moe biti razvijen s raspoloivim budetom. Prikupljanje i analiza zahteva. Prikupljaju se zahtevi, tako to se posmatraju postojedi sistemi, analiziraju radni procesi, intervjuiu bududi korisnici i njihovi rukovodioci, itd. Na taj nain stvaraju se modeli sistema, a ponekad i prototipovi, sve u cilju boljeg razumevanja sistema kog treba kreirati. Utvrivanje zahteva. Informacije skupljene analizom pretvaraju se u tekstove koji definiu zahteve. Postoje dva nivoa u opisivanju zahteva: korisniki zahtevi i zahtevi za sistem. Validacija zahteva. Proverava se da li su zahtevi realni (mogu da se ostvare raspoloivom tehnologijom i budetom), konzistentni (nisu u meusobnom konfliktu), i potpuni (ukljuene su sve potrebne funkcije i ogranienja). Nain odvijanja pod-aktivnosti Rezultat specifikacije su dokumenti koji opisuju zahteve. Korisniki zahtevi. To je manje precizan tekst u prirodnom jeziku. Prilagoden je krajnjim korisnicima. Sistemski zahtevi. Re je o detaljnom i preciznom opisu funkcija sistema i ogranienja. Moe sluiti kao temelj ugovora izmedu kupca i razvijaa softvera. Slui softverskim inenjerima kao polazite za dizajniranje. Pisan je u donekle strukturiranom prirodnom jeziku. Modeli sistema. To su dijagrami koji opisuju ponaanje sistema na nain koji je precizniji od prirodnog jezika. Nastaju tokom analize zahtjeva kao sredstvo komunikacije izmedu razvijaa softvera i bududih korisnika. Dokument o zahtevima. Re je o konanom rezultatu specifikacije, dobijenom kao unija svih prethodno opisanih dokumenata. Nain odvijanja pod-aktivnosti

Korisniki zahtevi 1. Softver mora da prui naine predstavljanja i pristupa eksternim fajlovima kreiranim drugim alatima. Sistemski zahtevi 1.1.Korisniku treba pruiti mogudnost definisanja tipa eksternih fajlova. 1.2. Svaki tip eksternog fajla moe imati dodeljen alat kojim se otvara. 1.3. Svaki tip eksternog fajla se moe predstaviti specijalnom ikonom na ekranu.

Razlika izmedju definicije i specifikacije zahteva

Definicija zahteva: namenjena poslovnom auditorijumu (kupci, korisnici) Osnova ugovora ta treba isporuiti kupcu piu je naruilac i analitiar

Specifikacija zahteva: Namenjena tehnikom auditorijumu (projektanti) Referencira samo one entitete kojima moe da se pristupi iz sistema posredstvom interfejsa Pie je analitiar

Doprinos procesu evidentiranja zahteva daju slededi subjekti: Klijenti koji finansiraju razvoj softvera Kupci, koji kupuju softver Korisnici, oni koji poznaju postojedi i koji de koristiti bududi sistem Eksperti iz date oblasti primene Pravnici i revizori, koji poznaju propise potrebne za dati sistem Softverski inenjeri Dopunska sredstva: Raspoloiva dokumentacija Posmatranje postojedeg sistema Intervjuisanje korisnika Uenje od korisnika Kako korisnici i projektanti vide jedni druge Vienje projektanta Korisnici ne znaju ta hode Sve hode odmah Nisu sposobni da objasne ta im treba Nisu radi da prave kompromise Ne ele da preuzmu odgovornost za sistem Ne umeju da dodele prioritete svojim potrebama Ne mogu da prate rokove

Vienje korisnika Projektanti ne razumeju operativne potrebe Ne mogu jasno da prevedu navedene potrebe u sistem Stavljaju veliki naglasak na tehnika pitanja Projektanti uvek kasne Uvek premauju budet Sve vreme govore ne Hode da nam kau kako da radimo svoj posao Modeliranje sistema Modeli predstavljaju vaan most izmedu specifikacije i dizajniranja sistema. Daje pojednostavljenu sliku sistema. Model posmatra sistem iz neke odredjene perspektive, pa istie neke njegove osobine a zanemaruje druge. Najvanije perspektive su: Kontekst. Odreduje se granica izmedu sistema i njegove okoline. Ponaanje. Promatraju se transformacije podataka, reakcije sistema na dogadaje, i promene njegovih stanja. Struktura. Modelira se arhitektura samog sistema ili gradja podataka koje on obradjuje. Da bi dobili celovitu sliku o sistemu, moramo imati nekoliko komplementarnih modela koji ga posmatraju. Modeli u fazi definisanja i specifikovanja zahteva Model toka podataka za koji se koristi UML Use-case dijagram - kontekst Model entiteta, veza i atributa - struktura Class diagram Dinamiki model ponaanje Dijagram sekvenci (sequence diagram) Dijagram sluajeva koridenja Modeluju samo funkcionalnost sistema koju moe da inicira neki od uesnika iz okruenja. Sistem za biblioteku granice sistema prikazane

uesnici akteri sluajevi koridenja

UML Use-case

Model entiteta, veza i atributa

posmatra sistem iz perspektive strukture i opisuje grau podataka. Navode se entiteti, veze medu entitetima i atributi Opisuje se i funkcionalnost veza (1:1, 1:n, m:n). Dijagram klasa Class diagram Predstavlja entitete i meusobne odnose

Model ponaanja objekata

Dijagram sekvence- Sequence diagrams pokazuje veze izmeu klasa koje se uspostavljaju time to objekti jedne klase pokredu operacije druge klase. Trag dogaaja je grafiki opis niza dogaaja koji se razmenjuju izmeu entiteta u stvarnosti.

Vodoravna linija dogaaj ili interakcija meu entitetima Vreme tee odozgo na dole. Dogaaj iznad se desio pre. Jedan graf = jedno ponaanje Korisnik napre pristupa katalogu biblioteke da vidi da li je odreeni dokument dostupan u elektronskom obliku, Zatim trai da mu se taj elektronski dokument dostavi preko mree. Zbog zatite autorskih prava, od korisnika se zahteva da prihvati ugovor o licenciranju. Mreni server na kraju alje dokument u kompresovanom obliku.

Dizajniranje sistema Nakon faze analize zahteva dobijaju se dva dokumenta: Jedan za klijenta, gde su obuhvadene njegove potrebe Drugi za dizajnere u kome se problem objanjava tehnikom terminologijom. Slededi korak u razvoju je prevoenje tih elja u reenje: Dizajn koji de zadovoljiti potrebe klijenta ta je to dizajn? To je kreativni proces pretvaranja PROBLEMA u REENJE Opis reenja se takoe naziva dizajn. Dizajn sistema obuhvata: precizni opis grae sistema, delova od kojih se on sastoji, interfejsa izmeu delova, korisnikog interfejsa.

Dizajniranje sistema je iterativni postupak, tj. do dizajna se dolazi postepenim profinjavanjem i razradom kroz vie iteracija. Poslednja iteracija dizajniranja se obino preklapa sa implementacijom. Primer: Gradnja nove kude Brani par eli novu kudu. Zahtevi: Jedna spavada soba za njih Jedna spavada soba za goste Dve deje spavade sobe Grejanje za zimu i hlaenje leti Vodovodna i elektrina instalacija Ureen park oko kude, itd. Reenje Arhitekta uzima u obzir zahteve i dizajnira kudu, zatim daje konkretno reenje npr. Kudu sa tri spavade sobe na spratu i jednom u prizemlju itd... Realnost je da arhitekta moe da prui veliki broj reenja i da sva reenja zadovoljavaju postavljene zahteve. Softverski dizajn Na slian nain specifikacija zahteva definie problem, a zatim dolazi reenje problema. U mnogim sluajevima je broj reenja neogranien. Pod-aktivnosti dizajniranja sistema Dekompozicija vedih delova sistema u manje Dizajniranje se u velikoj meri svodi na dekompoziciju vedih delova u manje. Najpre kod dizajniranja arhitekture se ceo sistem razloi na pod-sisteme, a kasnije kod dizajniranja delova, svaki pod-sistem dalje razlaemo na svoje module i tako dalje. Dekompozicija se uglavnom obavlja nekim od dva pristupa:

Funkcionalni pristup. Sistem se dizajnira sa stanovita funkcija (procesa). Rezultat je hijerarhijski sistem koji je lako implementirati u klasinim programskim jezicima. Objektni pristup. Sistem se dizajnira kao skup objekata koji medjusobno komuniciraju. Znai, delovi su objekti odnosno klase. Graa sistema obino nije hijerarhijska, a moe se posmatrati iz perspektive nasleivanja, agregacije, odnosno koridenja operacija meu klasama. Sistem se direktno moe implementirati u objektno-orijentisanim programskim jezicima. Dizajniranje arhitekture sistema ARHITEKTURA povezuje sposobnosti sistema navedene u specifikaciji zahteva sa sistemskim komponentama koje de ih implementirati. Komponente su obino moduli, a arhitektura opisuje i njihove meusobne veze. Sistem se dekomponuje na nekoliko pod-sistema, od kojih svaki obavlja odreeni skup zadataka. Okvirno se odreuje nain komunikacije pod-sistema i nain njihove kontrole. Pod-sistemi i odnosi meu njima Pod-sistem je relativno samostalna celina, ije funkcionisanje uglavnom ne zavisi od drugih podsistema. Pod-sistem je sastavljen od svojih delova (moduli, objekti, . . . ) i ima definisan interfejs za komunikaciju s drugim pod-sistemima. Pod-sistemi i odnosi meu njima Vrlo je vano odrediti odnose izmeu pod-sistema. Postoje dve razliite vrste odnosa pod-sistema: meusobna komunikacija i meusobna kontrola. U sklopu dizajniranja arhitekture se pojavljuju dve pod-aktivnosti: Strukturiranje sistema. Sistem se rastavlja na pod-sisteme. Utvruje se komunikacija izmeu pod-sistema, tj. razmena podataka. Modeliranje kontrole. Odreuje se tok kontrole izmedu pod-sistema, tj. ko nad kim upravlja. Strukturiranje sistema Rezultat strukturiranja je blok dijagram, gde su blokovi pod-sistemi, a strelice oznaavaju komunikaciju. Postoji vie modela strukture koji su se pokazali upotrebljivi za razne sisteme. Model s repozitorijumom

Svi zajedniki podaci uvaju se u sredinjoj bazi podataka (repozitoriju), kome pristupaju svi podsistemi. Komunikacija izmedu pod-sistema se odvija tako da jedan zapie podatke u bazu, a drugi proita te podatke. Ovo je uobiajena struktura za sisteme koji rade s velikim koliinama podataka (informacioni sistem banke ili preduzeda) Model klijent-server Sistem se sastoji od slededih delova: serveri: pod-sistemi koji nude usluge drugim pod-sistemima, klijenti: pod-sistemi koji trae usluge ponuene od servera mrea: omoguduje komunikaciju klijenata i servera. Model klijent-server Ovo je uobiajena struktura za mreno-orijentisane sisteme. Prilog prikazuje zamiljenu multimedijsku biblioteku. Prednosti modela klijent-server: omoguduje distribuciju sistema na mreu raunara; omoguduje lako dodavanje novog servera; Mane modela klijent-server: svaki server se mora sam brinuti za administriranje svojih podataka; svaki klijent mora znati koje usluge se nalaze na kom serveru.