Metodologija razvoja softvera Osnovne akademske studije Softversko inenjerstvo

Metodologija razvoja softvera Osnovne akademske studije: Softversko inženjerstvo i informacione tehnologije Predmetni nastavnik: Prof. dr Branko Perišić

Inženjerstvo softvera �Inženjerstvo problema; – obrazovanje za rešavanje ◦ ingeniosus – vešt; ◦ in geniosus – u nepoznatom; �Softver ◦ Proizvod �Klase softverskih sistema; �Opšti zahtevi prema softverskom proizvodu; �Softverski proizvod ◦ Proces: �Aspekti: apstrakcije, predstavljanje, metode, alati, dejstva, komunikacija; �Aktivnosti: razvoj, kontrola, upravljanje, rad; 4. 3. 2021. Prof. dr Branko Perišić 2

Programiranje : Inženjerstvo softvera Programiranje Inženjerstvo softvera PSW -Upravljanje softverskim projektom

Upravljanje PSW -Upravljanje softverskim projektom

Projektovanje softvera ? ? PSW -Upravljanje softverskim projektom

Osnovi Softverskog inženjerstva - 0 AGILE OMG OPEN SOURCE zajednica SEI ACM Softversko inženjerstvo Internet IEEE MICROSOFT ISO IBM SWEBOK Savremeno okruženje discipline softverskog inženjerstva

Osnovi Softverskog inženjerstva - 1 U cilju analize uspešnosti 1994. g. istraživanje Standish Group obuhvatilo je 350 kompanija i preko 8000 njihovih softverskih projekata. Rezultati: · 31% projekata nikada nije završeno · u velikim kompanijama samo je 9% projekata isporučeno na vreme i u granicama planiranog budžeta · u malim kompanijama 16% projekata isporučeno na vreme i u granicama planiranog budžeta

Osnovi Softverskog inženjerstva - 2 1995. g. obavljeno je istraživanje uzroka prethodnih rezultata. Prvih 8 razloga obuhvataju: 1. nekompletna specifikacija zahteva (13, 1%) 2. nedovoljno uključivanje korisnika (12, 4%) 3. nedostatak resursa (10, 6%) 4. nerealna očekivanja ( 9, 9%) 5. nedostatak podrške rukovodstva ( 9, 3%) 6. izmena zahteva i specifikacija ( 8, 7%) 7. odsustvo planiranja ( 8, 1%) 8. kada je završen sistem nije više bio potreban ( 7, 5%)

Diskretni sistem automatskog upravljanja

Osnovi Softverskog inženjerstva - 4

Faktori koji su izmenili softversko inženjerstvo (Wasserman 1996) Desktop Computing Object technology waterfall life cycle model? Shift in economics User interfaces Promen e u SE Networking Time to market

Odnos proces - proizvod INŽENJERSKA AKTIVNOST PROCES PROIZVO D

Odnos proces - proizvod INŽENJERSKA AKTIVNOST PROCES PROIZVO D

Odnos proces - proizvod

4. 3. 2021. Prof. dr Branko Perišić 23

Softverski proizvod – 1. Softverski proizvod Klase softverskih sistema Opšti zahtevi prema softverskom proizvodu

KLASE SOFTVERSKIH SISTEMA ODNOSI PREMA OKRUŽENJU INTERNE KARAKTERISTIKE BATCH AVIO SAOBRAĆAJ TABLE DRIVEN INTERAKTIVNI REAKTIVNI GENERIČKA OBLAST PRIMENE PROCCESS DRIVEN KOMUNIKACIONI SISTEMI REAL TIME SADRŽANI (EMBEDED) KNOWLEDGE BASED DISTRIBUIRANI OPERATIVNI SISTEMI ZA RUKOVANJE BAZAMA PODATAKA KONKURENTNI CASE, CAD, CAM ALATI MREŽNI 4. 3. 2021. Prof. dr Branko Perišić 25

Softverski proizvod – 2. Softverski proizvod Klase softverskih sistema Opšti zahtevi prema softverskom proizvodu

OPŠTI ZAHTEVI PREMA SOFTVERSKOM PROIZVODU DOSTUPNOST (ACCESSABILITY) PRENOSIVOST (PORTABILITY) ADAPTIVNOST (ADAPTIBILITY) ZAŠTITA (PROTECTION) RASPOLOŽIVOST (AVAILABILITY) KOMPATIBILNOST (COMPATIBILITY) BEZBEDNOST (SAFETY) SIGURNOST (SECURITY) POUZDANOST (RELIABILITY) KOREKTNOST (CORRECTNESS) ROBUSTNOST (ROBUSTNESS) OTPORNOST NA GREŠKE (FAULT TOLERANCY) INTEGRITET (INTEGRITY) PONOVNA ISKORISTIVOST (REUSABILITY) OPERATIVNOST (INTEROPERABILITY) MOGUĆNOST TESTIRANJA (TESTABILITY) MOGUĆNOST ODRŽAVANJA (MAINTAINABILITY) MOGUĆNOST KORIŠĆENJA (USABILITY) PERFORMANSA (PERFORMANCE) EFIKASNOST (EFFICIENCY) 4. 3. 2021. Prof. dr Branko Perišić 27

Odnos proces - proizvod INŽENJERSKA AKTIVNOST PROCES PROIZVO D

Proces – 1.

Proces – 2. 1. Propisuje sve glavne aktivnosti. 2. Poseduje skup vodećih principa koji definišu vodećih principa ciljeve pojedinačnih aktivnosti. 3. Aktivnosti su organizovane u nizove (sekvence). sekvence 4. Svaka aktivnost u procesu ima kriterijum za kriterijum pokretanje i završetak. 5. Koristi resurse u skladu sa postavljenim ograničenjima i daje prelazne i/ili konačnu formu prelazne konačnu proizvoda 6. Može posedovati unutrašnju stukturu.

RAZVOJ (zahtevi, analiza, specifikacija dizajna, implementacija, testiranje) A S P E K T I 1 A K T I V N O S T I 2 9 8 3 KONTROLA 6 4 (potvrda kvaliteta, konfigurisanje, validacija i verifikacija) 7 UPRAVLJANJE 10 (planiranje projekta, alokacija resursa, procena troškova, Ugovaranje, . . . ) 5 RAD (obuka, prelazak, operativni rad, gašenje) APSTRAKCIJE KOMUNIKACIJE PREDSTAVLJANJE METODE DEJSTVA ALATI 4. 3. 2021. Prof. dr Branko Perišić 31

APSTRAKCIJE: OBUHVATAJU FUNDAMENTALNE PRINCIPE I FORMALNE MODELE • MODELI PROCESA RAZVOJA SOFTVERA (VODOPAD, MODELI PROCESA RAZVOJA SOFTVERA SPIRALNI, . . IZRADA PROTOTIPA I SL. ) PREDSTAVLJAJU MODELE EVOLUCIJE SOFTVERA; • KONAČNI AUTOMATI i NI AUTOMATI PETRIJEVE MREŽE PREDSTAVLJAJU PETRIJEVE MREŽE MODELE ZA ISKAZIVANJE SEKVENCIJALNE i KONKURENTNE MODELE OBRADE; • 4. 3. 2021. Prof. dr Branko Perišić 32

PRETSTAVLJANJE: OBUHVATA NOTACIONE ASPEKTE I JEZIKE JAVA • PROGRAMSKI JEZIK (IMPLEMENTACIONA JEZIK NOTACIJA) • 4. 3. 2021. Prof. dr Branko Perišić 33

METODE: OBUHVATAJU Formalne metode, metodologije i tekuću praksu q DOKAZ KOREKTNOSTI PROGRAMA - (Formalni metod verifikacije); q OBJEKTNO ORIJENTISANI DIZAJN - (OOD) (Metodologija projektovanja); q OBJEKTNO ORIJENTISANO 4. 3. 2021. Prof. dr Branko Perišić 34

ALATI: OBUHVATAJU POJEDINAČNE SOFTVERSKE ALATE KAO I INTEGRISANE SKUPOVE ALATA (UKLJUČIVO I HARDVERSKA SRETSTVA) Ø 4. 3. 2021. Prof. dr Branko Perišić 35

DEJSTVA: OBUHVATAJU MERENJA, ANALIZU i EVALUACIJU SOFTVERSKIH PROCESA, UTICAJ SOFTVERA NA ORGANIZACIONE SISTEME, MERE i STANDARDE. v PREDMET MERENJA (Šta se meri? ); v SOFTVERSKE METRIKE (Čime se iskazuje? ); v ALATI ZA MERENJE (Čime se meri? ); v 4. 3. 2021. Prof. dr Branko Perišić 36

KOMUNIKACIJA: o PISANA KOMUNIKACIJA; o GOVORNA KOMUNIKACIJA; o DOKUMENTACIJA: § ON-LINE (Help, Kontekstna pomoć); ON-LINE § OFF-LINE (Uputstva, Priručnici); OFF-LINE § IN-LINE (Komentari u programu); IN-LINE § TUTORIAL (Asistencija pri ovladavanju upotrebom). 4. 3. 2021. Prof. dr Branko Perišić 37

Konačni model proces – proizvod AKTIVNOS TI Klase softverskih sistema ASPEK TI Opšti zahtevi prema softverskom proizvodu

Modeli životnog ciklusa softvera – 1. SOFTVERSKI PROCES SE OBIČNO ISKAZUJE U FORMI MODELA ŽIVOTNOG CIKLUSA SOFTVERSKOG PROIZVODA Životni ciklus softverskog proizvoda Životni ciklus obuhvata put od njegovog put konceptualnog specificiranja, preko konceptualnog specificiranja implementacije, implementacije isporuke, isporuke korišćenja, korišćenja održavanja i izvođenja iz održavanja migracija do migracija eksploatacije.

“Modeli životnog ciklusa” (2) �Modeli oslonjeni na jednu verziju softverskog proizvoda �Inkrementalni modeli ◦ Jedna verzija uz izradu prototipa �Iterativni modeli – više verzija

Inkrementalno - Iterativno Zvuči slično i nekada se poistovećuju � Očigledne razlike: � ◦ ◦ � Inkrementalno: dopunjava proizvod u svakoj fazi Iterativno: prerađuje proizvod u svakoj fazi Neki od modela se mogu koristiti na oba načina

Primer: Izgradnja kuće �Inkrementalno: Početi sa skromnom verzijom kuće a zatim dodavati i unapređivati prostorije i opremu. �Iterativno: U svakoj iteraciji, kuća se preprojektuje i ponovo gradi. � Velika razlika: U inkrementalno zidanoj kući može se svo vreme živeti! U iterativno zidanoj stalno se selite iz stare u novu kuću.

Rizik? Koji rizik? �Glavni prostor rizika pretstavlja činjenica da obim i težina posla nisu dovoljno dobro shvaćeni na početku. �Ovo je tzv. fenomen “kvarnih problema”.

“Kvarni problemi” �Večina projekata razvoja softvera imaju osobinu “kvarnih problema”, što znači: “problema koje je moguće potpuno shvatiti tek nakon što su prvi put rešeni” (naravno loše) �Ne pretstavlja ekskluzivnu karakteristiku jedino softvera!

Neki koreni kvarnosti �Rizik: Kupac neznajući tačno šta on/ona želi; menja očekivanja kako projekat napreduje. �Rizik: Osoblje sa nedovoljnim iskustvom u domenu: problema ili tenika odabranih za implementaciju.

Klasifikacija rizika �Rizik performanse: Projekat može da ne dostigne postavljene zahteve ili bude na neki drugi način neprihvatljiv za korisnika. �Rizik cene: Može prekoračiti budžet. �Rizik podrške: Softver može biti neprilagodljiv, bez mogućnosti održavanja Klasifikacija uticaja rizika ili proširivanja. – Zanemariv �Vreme isporuke: Projekat može biti isporučen prekasno. – Marginalan – Kritičan – Katastrofalan

Načini rukovanja rizicima �Rizici se ne mogu eliminisati; njima se mora upravljati! ◦ Uradite to u fazi analize zahteva pre otpočinjanja faze dizajna. ◦ Koristite alate za praćenje zahteva, odgovornosti, implementacije, itd. ◦ Izradite male prototipove sa ciljem testiranja i demonstriranja koncepata i proverite pristup pre izgradnje celokupnog projekta. ◦ Koristite prototipove i komponente u fazi integracije.

Model sa kontrolisanim iteracijama �Svaki glavni ciklus prolazi kroz četiri faze ◦ Priprema: Pregovaranje i definisanje proizvoda u ovoj iteraciji ◦ Elaboracija: Dizajn ◦ Konstrukcija: Kreiranje potpuno funkcionalnog proizvoida ◦ Tranzicija: Isporučivanje proizvoda u skladu sa specifikacijom � Sledeća faza započinje pre kraja prethodne (npr. kada je prethodna 80% završena).

RUP (Rational Unified Process) (a form of controlled iteration) Tokovi posla procesa Phases Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Prateći tok posla Configuration Mgmt Management Environment Preliminary Iteration(s) #1 #2 #n #n+1 #n+2 Iter. #m #m+1 Iteracije unutar faza

Time-Box pristup (može se koristiti kod iterativnih ili inkrementalnih metoda) �Analiza zahteva �Inicijalni dizajn �while( not done ) { } Razvoj verzije unutar ograničenog vremena Isporuka kupcu Pribavljanje povratnih informacija Planiranje sledeće verzije

Scrum Model (inkrementalni model, uključuje neke aspekte strukture tima i procesa) Start Mala grupa je odgovorna za hvatanje lopte i njeno prenošenje do gola. Cilj Pogledati: http: //www. cetus-links. org/oo_ooa_ood_methods. html

Razlozi za primenu Scrum Modela �Projekat razvoja softvera je nekada teško razbiti na jasne i čiste faze kao što to sugeriše spiralni model. �Scrum može biti “prava stvar” za kvarne probleme, budući da tim može brzo reagovati na nove informacije.

Neki principi Scrum Modela � Neophodno je uvek imati proizvod koji je teoretski moguće isporučiti: “gotovost” se može objaviti u bilo kom trenutku. � Gradite u ranoj fazi, gradite često. � Kontinuirano testirajte proizvod u fazi izgradnje. � Pretpostavite da se zahtevi mogu promeniti; Budite u stanju prihvatiti promene koje diktira tržište u fazi razvoja. � Mali timovi rade paralelno sa ciljem maksimiziranja komunikacije i minimiziranja preklapanja.

Korišćenje iteracija u Scrum-u http: //www. controlchaos. com/scrumwp. htm � Svaka iteracija poseduje sve standardne faze modela vodopada ali se svaka iteracija odnosi samo na jedan podskup funkcija. � Ukupan element primopredaje u sklopu projekta se razbija na, po prioritetima klasifikovane, podsisteme sa jasno definisanim interfejsima. � U sklopu početne iteracije testira se izvodivost podsistema i dostižnost tehnologije. � Naredne iteracije mogu zahtevati dodatne resurse za projekat ako se isporuka ubrzava. � Prateći procesi u sklopu razvoja su definisani i linearni.

Extremno Programiranje (XP) (cf. http: //www. extremeprogramming. org/rules. html) � Korisničke priče (stories) (nešto kao slučajevi korišćenja) piše korisnik sistema. � Složene priče se dekomponuju na jednostavnije (struktura posla -WBS). � Koriste se za procenu potrebnog napora. � Koriste se kao podloga za test prihvatanja. � Formira se plan isporuke kojim se specificira koje će priče biti podržane u kojoj faznoj isporuci. � Ne ustručavajte se da menjate ono što ne funkcioniše.

Extremno Programiranje (XP) � Svakoj faznoj isporuci prethodi sastanak na kome se planira isporuka. � Svaki dan započinje sa sastankom “s nogu” na kome se iznose problemi i dileme. � Kupac je uvek na raspolaganju.

Extremno Programiranje (XP) � Celokupan kod prolazi kroz jedinično testiranje, pri čemu se testovi formiraju pre dizajna (testdriven design). � Refactorisanje se stalno radi. � Integraciju obavlja jedan par projektanata. � Integracija se radi često. � Optimizacija se radi poslednja. � Testovi prihvatanja se često rade.

Keller-ov “Uzradi sam” - model životnog ciklusa softvera komplet za konstrukciju Requirements Elicitation Requirements Analysis Requirements Specification Risk Analysis Cost Analysis System Design Prototype Validate Program Design Simulate Verify Detailed Design Implement Integration Test Design Review Code Walkthrough Unit Test Document Integrate Fix Errors Acceptance Test Port Train Evaluate Configure Maintain Party

Pritisci na SE Funkcionalnost Trošak Kompatibilnost Kapacitet Raspoloživost Sigurnost Otpornost na SE greške Performansa Tehnologije Propusnost Zaštita

Inženjerstvo softvera ?