Aplikativni softver

1. Fakultet za informatiku i menadžment Univerzitet Singidunum www.fim.singidunum.ac.yu Aplikativni softver 2008/2009. Violeta Tomašević vitomasevic@singidunum.ac.yu

2. Literatura • www.crnarupa.singidunum.ac.yu • Shari L. Pfleeger, Joanne M. Atlee, Softversko inženjerstvo:teorija i praksa, prevod Računarski fakultet, Beograd, 2006. • Martin Flowler, UML ukratko, prevod Mikro knjiga, 2004. Aplikativni softver Formiranje ocene

3. Aplikativni softver Ciljevi kursa SW SW SW SW • 2) Da studenti: • ovladaju osnovama raznih tehnika koje se koriste za razvoj web aplikacija • 1) Da studenti: • sagledaju kompleksnost procesa razvoja softvera • nauče kako da priđu problemu koga rešavaju sa inženjerskog aspekta • nauče kako se ocenjuje kvalitet softverskog proizvoda • detaljnije upoznaju načine modelovanja procesa razvoja softvera

4. Aplikativni softver Sadržaj kursa

5. Ako postoji potreba REŠENJE APLIKATIVNI SOFTVER Aplikativni softver Uvod Analiza sistema je razlaganje problema na delove, tj. potprobleme (PP) koje možemo da razumemo i koje možemo da rešimo. Veze između potproblema su izuzetno važne, jer mogu biti ključni faktor u nalaženju rešenja složenog problema. PROBLEM PP2 PP1 PP3 R2 Sinteza rešenja je sklapanje parcijalnih rešenja (R) u cilju nalaženja kompletnog rešenja problema. R1 R3 REŠENJE

6. Word proc. Graphics Spreadsh. Web app. Databases Games Aplikativni softver Assembler Debugger Compilers File Mng. OS Utilities Sistemski softver Računarski hardver Aplikativni softver Pojam aplikativnog softvera Aplikativni softver čine programi napravljeni za specifičnu svrhu i nisu u direktnoj vezi sa hardverom. Pri svom izvršavanju oslanjaju se na sistemski softver, posebno na operativni sistem. Obično se kupuju odvojeno od računarskog hardvera. Sistemski softver obuhvata programe na niskom nivou (low-level) koji služe za kontrolu operacija nad računarskom opremom. U nekim slučajevima nema jasne granice između sistemskog i aplikativnog softvera. Na primer, nema saglasnosti oko toga da li je Internet Explorer web browser deo Windows OS ili nije.

7. Haker Ume da napiše kod koji nešto radi. Ume da proizvede sveobuhvatan stabilan i razumljiv kod koji se lako održava i koji efikasno radi ono zbog čega je napravljen. Taj kod predstavlja visoko kvalitetan softver. Softverski inženjer Aplikativni softver Izazovi pri izradi softvera (1) Svaki problem se može rešiti na više načina. Oni se razlikuju po efikasnosti, preciznosti, mogućnosti modifikovanja, korisnosti, razumljivosti i drugim osobinama. Stoga pisanje softvera zahteva znanje, ali i domišljatost i veštinu.

8. Aplikativni softver Izazovi pri izradi softvera (2) I pored toga što proizvođači teže softveru bez mana, u stvarnosti mnogi softverski proizvodi sadrže nedostatke. O čemu treba voditi računa? • Neočekivana upotreba sistema • usled zloupotrebe • usled nestručnog rukovanja • Tržište diktira brz razvoj softvera • brza isporuka ostavlja malo vremena za testiranje, pa su greške češće • ponekad je teže ispraviti uočene nedostatke, nego napisati kompletan novi softver • Kvalitet je neophodan • što je nedostatak duže neotkriven, njegovo otklanjanje više košta (troškovi ispravljanja greške u fazi analize su 10 puta manji od troškova nakon isporuke).

9. Aplikativni softver Šta je dobar softver? Kvalitet softvera zavisi od konteksta posmatranja. Na primer, nedostaci koji se tolerišu u softveru za obradu teskta, ne mogu se prihvatiti u sistemima gde je faktor bezbednosti izuzetno bitan. • Kvalitet softvera mora se posmatrati na više načina: • Kvalitet proizvoda • Kvalitet postupka izrade proizvoda • Kvalitet proizvoda u kontekstu poslovnog okruženja u kome će se koristiti

10. Aplikativni softver Kvalitet proizvoda Karakteristike proizvoda koje određuju kvalitet zavise od toga ko analizira softver Korisnik smatra da je softver kvalitetan ako radi na odgovarajući način, lako se uči i koristi. Korisnik meri: tip i broj otkaza. Projektant razmatra interne karakteristike proizvoda i procenjuje nedostatke. Projektant meri: broj nedostataka u zahtevima, projektu i kodu. Modeli kvaliteta dovode u vezu spoljni pogled korisnika i unutrašnji pogled programera na softver.

11. Aplikativni softver Boehm-ov model kvaliteta (1) Boehm-ov model kvaliteta (Boehm i dr., 1978.) je jedan od najpoznatijih modela. On predstavlja hijerarhiju karakteristika od kojih svaka doprinosi ukupnom kvalitetu. U model su uključena očekivanja kako korisnika, tako i programera. • Po ovom modelu, kvalitetan softver je onaj koji: • radi ono što korisnik od njega traži, • ispravno i efikasno koristi računarske resurse, • jednostavan je za učenje i korišćenje, • dobro je projektovan, dobro kodiran i lako se testira i održava.

12. Aplikativni softver Boehm-ov model kvaliteta (2) Nezavisnost od uređaja Samosadrživost Prenosivost Tačnost Potpunost Pouzdanost Robustnost/integritet Efikasnost Doslednost Opšta korisnost Osnovni naručilac Odgovornost Ljudsko inženjerstvo Efikasnost uređaja Pristupačnost Mogućnost testiranja Komunikativnost Samoopisivost Mogućnost održavanja Razumljivost Strukturisanost Sažetost Mogućnost izmene Čitljivost Proširivost

13. Aplikativni softver Kvalitet procesa Kvalitet procesa razvoja softvera je jednako važan kao i kvalitet proizvoda. Ako neka od aktivnosti krene u pogrešnom smeru, to može da pogorša kvalitet proizvoda. Zbog toga se radi modelovanje postupka koje omogućava lakšu analizu postupka i nalaženje načina za njegovo poboljšanje. • Pitanja koja treba postaviti u procesu razvoja: • Gde i kada ćemo verovatno naći neku vrstu nedostatka? • Kako možemo što ranije da pronađemo nedostatke u procesu razvoja? • Kako možemo da ugradimo toleranciju na greške, da bi smanjili verovatnoću da nedostatak pređe u otkaz? • Da li postoje alternativne aktivnosti koje mogu da načine proces efikasnijim, uz osiguranje kvaliteta?

14. Aplikativni softver Kvalitet u kontekstu poslovanja Kvalitet sa aspekta poslovanja se posmatra u zavisnosti od proizvoda i usluga koje pruža poslovni sistem čiji je softver sastavni deo. Pri tome se analizira poslovna vrednost proizvoda. Tehnička vrednost proizvoda Povratak investicije Poslovna vrednost proizvoda ........ Kraći put do kupca Kvalitet procesa Kvalitet proizvoda Produktivnost

15. Aplikativni softver Učesnici u razvoju softvera Kupacje kompanija, organizacija ili pojedinac koji finansira razvoj softverskog sistema. Projektantje kompanija, organizacija ili pojedinac koji pravi softverski sistem za kupca. Ugovorna obaveza Kupac Ima potrebu Korisnikje jedan ili više pojedinaca koji će stvarno koristiti sistem. Softverski sistem Ima potrebu Projektant Kupac Učesnici u projektu mogu istovremeno da imaju više uloga. Na primer, ako neki sektor u kompaniji razvija sam softver za svoje potrebe, on je istovremeno i kupac i korisnik i projektant.

16. Aplikativni softver Faze u razvoju softvera (1) • Analiza i definisanje zahteva. U ovoj fazi se u saradnji sa kupcem utvrđuju zahtevi koji opisuju sistem. Pri njihovom definisanju uzimaju se u obzir entiteti, aktivnosti i ograničenja koja postoje u sistemu, kao i interakcija sistema sa okruženjem. • Projektovanje (dizajn) sistema. U cilju zadovoljenja definisanih zahteva, generiše se projekat sistema koji opisuje finkcionalnost sistema i njegov izgled sa stanovišta kupca. Projekat obično sadrži snimke ekrana, izveštaje koji će se generisati, interakciju sistema sa korisnikom, itd. • Projektovanje programa. Kada kupac odobri projekat sistema, generišu se pojedinačni podprojekti pogodni za programsku realizaciju. • Implementacija (pisanje) programa.

17. Aplikativni softver Faze u razvoju softvera (2) • Testiranje modula. Nakon pisanja programa, najpre se testiraju individualni delovi koda, tj. pojedinačni moduli. • Testiranje integrisanog sistema. Moduli se povezuju u celinu i testira se da li moduli dobro rade u spezi sa drugim modulima. • Završno testiranje sistema. Proverava se da sistem služi svojoj nameni, tj. da li zadovoljava postavljene zahteve. • Isporuka sistema. • Održavanje. Tokom upotrebe sistema mogu se uočiti razni problemi koje treba rešavati. Proces razvoja softvera je svaki opis razvoja softvera koji sadrži neke od nabrojanih faza, organizovanih tako da proizvode proveren kod.

18. Aplikativni softver Modeli procesa razvoja softvera (1) MODEL PROCESA RAZVOJA SPECIFIKACIJA ZAHTEVA ISPORUČENI PROIZVOD • Razlozi za modelovanje procesa • Kada grupa opiše primenjivani proces projektovanja, opis postaje zajedničko shvatanje aktivnosti, resursa i ograničenja uključenih u razvoj softvera. • Modelovanje pomaže u nalaženju nedoslednosti, viškova i izostavljenih elemenata u samom procesu, što poboljšava efikasnost procesa. • Model treba da odražava ciljeve razvoja. Nakon izrade modela projektni tim ocenjuje aktivnosti sa aspekta njihove usklađenosti sa postavljenim ciljevima. • Svaki proces mora biti napravljen prema situaciji u kojoj će se primenjivati. Modelovanje procesa pomaže da projektni tim utvrdi mesta na kojima su potreba prilagođavanja.

19. Aplikativni softver Modeli procesa razvoja softvera (2) • Kaskadni model (model vodopada) • V model • Fazni razvoj (inkrementalni i iterativni) • Prototipski model • Model specifikacije rada • Transformacioni model • Spiralni model • Agilne metode (ekstremno programiranje)

20. Aplikativni softver Kaskadni model (1) Kaskadni model ili model vodopada (Royce, 1970.) predstavlja veoma visok nivo apstrakcije razvojnog procesa čije su faze kaskadno prikazane. ANALIZA ZAHTEVA • Osobine modela • Jedna faza razvoja treba da se u potpunosti okonča pre početka sledeće faze. PROJEKTOVANJE KODIRANJE • Za svaku aktivnost procesa definišu se kritične tačke i međuproizvodi, što olakšava praćenje stepena gotovosti projekta. TESTIRANJE OPERATIVNI RAD I ODRŽAVANJE

21. Aplikativni softver Kaskadni model (2) • Prednosti modela • Jednostavnost koja olakšava pružanje objašnjenja kupcima. • Dobijanje pune funkcionalnosti sistema. • Eksplicitno ukazivanje na međuproizvode koji su neophodni za započinjanje sledeće faze. • Pogodan za slučaj kada je neophodno odjednom zameniti stari sistem. • Nedostaci modela • Ne odražava povratne sprege koje zbog grešaka i nepreciznosti zahteva postoje u stvarnosti. • Sistem je obično preveliki da se uradi u jednoj iteraciji. • Nije pogodan kod znatnih izmena zahteva.

22. Aplikativni softver V model (1) V model (nemačko Ministarstvo odbrane, 1992.) je modifikovani kaskadni model koji pokazuje odnos testiranja i faza analize i projektovanja, čineći eksplicitnim neke povratne sprege koje su skrivene u kaskadnom modelu. ANALIZA ZAHTEVA OPERATIVNI RAD I ODRŽAVANJE Validacija zahteva ZAVRŠNO TESTIRANJE PROJEKTOVANJE SISTEMA TESTIRANJE SISTEMA Verifikacija projekta PROJEKTOVANJE PROGRAMA TESTIRANJE DELOVA I INTEGRACIJE KODIRANJE

23. Aplikativni softver V model (2) V model se prvenstveno bavi aktivnostima i ispravnim radom sistema, za razliku od kaskadnog modela koji je usredsređen na dokumente i međuproizvode. Kako se koristi V model? • Testiranje delova, testiranje sistema pri integraciji i testiranje sistema bave se ispravnošću programa i mogu se koristiti za verifikovanje dizajna programa. • Završni test služi za validaciju zahteva, tj. proveru da li su svi zahtevi potpuno implementirani. • Ako se pronađu problemi tokom verifikacije ili validacije, aktivnosti sa leve strane V modela mogu se ponoviti radi popravke i poboljšanja zahteva, dizajna ili koda, pre nego što se ponove testiranja na desnoj strani modela.

24. Aplikativni softver Fazni razvoj (1) Fazni razvoj je način projektovanja softvera koji omogućava isporučivanje sistema u delovima, tako da je korisnicima na raspolaganju jedan deo funkcija, dok je ostatak funkcija još u razvoju. Zato obično postoje dva sistema koji uporedo funkcionišu: produkcioni i razvojni sistem. Razvojni sistemi Izrada verzije 1 Izrada verzije 2 Izrada verzije 3 PROJEKTNI TIM Vreme Produkcioni sistemi KORISNICI Upotreba verzije 1 Upotreba verzije 2 Upotreba verzije 3 Produkcioni sistem je onaj koji trenutno koriste naručilac i korisnik. Razvojni sistem predstavlja sledeću verziju koja se priprema da zameni postojeći produkcioni sistem. Sistemi se obično nazivaju prema rednom broju njihove verzije. Tako, projektni tim uvek radi na verziji n+1, dok je verzija n u fazi operativnog korišćenja.

25. Aplikativni softver Fazni razvoj (2) Inkrementalni razvoj podrazumeva da se sistem u skladu sa specifikacijom zahteva deli na podsisteme prema funkcijama. Verzije se definišu kao funkcionalni podsistemi, tako da se svakoj novoj verziji priključuju nove funkcije. Sistem se nadograđuje do potpune funkcionalnosti. Iterativni razvoj takođe podrazumeva podelu sistema na podsisteme prema funkcijama, ali se potpun sistem isporučuje u svim verzijama, s tim što se u svakoj novoj verziji menjaju funkcije svakog podsistema. Svaka sledeća verzija unapređuje prethodnu.

26. Aplikativni softver Fazni razvoj (3) • Pogodnosti inkrementalnog razvoja • Operativni podskup funkcija po zahtevima korisnika može biti vrlo brzo isporučen. • Projektni tim može da ima relativno mali broj ljudi. • Progres na projektu je vidljiv (nije samo u okviru dokumenata). • Mogućnost odziva od strane korisnika kroz ceo ciklus razvoja vodi ka stabilnijim međurezultatima i sistemu uopšte. • Pogodnosti iterativnog razvoja • Obuka može da počne sa prvom verzijom, što je dobro, jer praćenje izvršavanja nekih funkcija može da sugeriše poboljšanja u kasnijim verzijama. • Na tržište može da se izađe vrlo rano, ako se radi o funkcionalnostima koje nikada ranije nisu bile nuđene. • Česte verzije omogućavaju brzo otkanjanje nepredviđenih problema. • Projektni tim može da se usredsredi na različite oblasti usavršavanja u različitim verzijama (na pr. korisnički interfejs, performanse sistema itd.).

27. Aplikativni softver Prototipski model (1) Prototipski model se zasniva na izradi prototipova. Ovaj model omogućava da se kompletan sistem ili delovi sistema brzo konstruišu radi razjašnjenja ili boljeg razumevanja otvorenih pitanja, sve sa ciljem smanjenja rizika i neodređenosti prilikom projektovanja sistema. LISTA REVIZIJA LISTA REVIZIJA LISTA REVIZIJA revizija prototipa pogled korisnika ili naručioca PROTOTIPSKI ZAHTEVI PROTOTIPSKI PROJEKAT PROTOTIPSKI SISTEM TEST ISPORUČENI SISTEM ZAHTEVI SISTEMA (nekada neformalni ili nekompletni) Prototip je delimično razvijen proizvod koji omogućava naručiocima i projektantima da ispitaju neke aspekte predloženog sistema i odluče da li je on pogodan i potreban u sklopu gotovog proizvoda.

28. Aplikativni softver Prototipski model (2) REVIZIJA REVIZIJA REVIZIJA ZAHTEVI SISTEMA ISPORUČENI SISTEM ZAHTEVI PROJEKAT SISTEM TEST • Definisanje skupa zahteva od strane naručioca i korisnika. • Ispitivanje alternativa (analize mogućih ekrana, tabela i dr. izlaza iz sistema). • Revizija zahteva prema željama naručioca i korisnika. • Prelazak na fazu projektovanja. • Istraživanje varijanti u projektovanju. • Revidiranje inicialnog dizajna dok svi učesnici ne budu zadovoljni. • Ako se pri razmatranju varijanti dizajna naiđe na probleme koji potiču od zahteva, vraća se na ponovnu specifikaciju zahteva. • Kodiranje sistema uz razmatranje varijanti sa mogućim iteracijama kroz zahteve i dizajn. PRIMER RAZVOJA SISTEMA

29. Aplikativni softver Model specifikacije rada Model specifikacije rada (Zave, 1984.) omogućava projektnom timu i naručiocu da u ranim fazama projektovanja ispitaju zahteve sistema i njihove implikacije, i po potrebi ih koriguju. Zahtevi se pre početka projektovanja ocenjuju ili izvršavaju na način koji pokazuje prirodu sistema, koristeći programske pakete. Tako se izbegavaju problemi u kasnijim fazama koji mogu da nastanu usled neodređenosti vezane za zahteve sistema. Ovaj model, za razliku od tradicionalnih modela, objedinjuje funkcionalnost i dizajn i time spaja potrebe naručioca sa implementacijom. Izvršiti i revidirati SPECIFIKACIJA RADA (orijentisana ka problemu) TRANSFORMISANA SPECIFIKACIJA (orijentisana ka implementaciji) TEST ISPORUČENI SISTEM ZAHTEVI SISTEMA

30. Aplikativni softver Transformacioni model Transformacioni model (Balzer, 1981.) pokušava da redukuje mogućnost greške primenom niza transformacija kojima se specifikacija zahteva pretvara u sistem koji može da se isporuči. Sekvence transformacija i odluka se čuvaju kao formalni zapis u okviru dizajna. Poređenje sa zahtevima; ažurirati ako je potrebno FORMALNI ZAPIS O RAZVOJU Niz transformacija sa obrazloženjima TRANSFORMACIJA N ......... FORMALNA SPECIFIKACIJA TRANSFORMACIJA 2 TEST TRANSFORMACIJA 1 ISPORUČENI SISTEM ZAHTEVI SISTEMA Transformacioni model veoma mnogo obećava. Glavna smetnja da bude šire prihvaćen je neophodnost formalne specifikacije da bi transformacije mogle nad njom da se izvršavaju.

31. Aplikativni softver Spiralni model (1) Spiralni model (Boehm, 1988.) posmatra razvoj softvera u svetlu prisutnih rizika tako što kombinuje aktivnosti razvoja sa upravljanjem rizicima. Na taj način se postižu manji rizici, a i njihova kontrola je olakšana. Po spiralnom modelu, proces razvoja softvera se odvija u 4 iteracije: 1. Opis funkcionisanja sistema na visokom nivou apstrakcije Zahtevi i plan razvoja Dokument “Principi rada” 2. Definisanje skupa zahteva Validacija zahteva Validacija i verifikacija dizajna 3. Generisanje dizajna sistema 4. Testiranje Testiranje U svakoj iteraciji, radi se analiza rizika koja identifikuje rizike i određuje različite varijante sa aspekta zahteva i ograničenja za njihovo minimiziranje. Zatim se izradom prototipova verifikuju izvodljivost i pogodnost varijanti pre nego što se odabere odgovarajuća.

32. Aplikativni softver Spiralni model (2) Određivanje ciljeva, varijanti i ograničenja Ocenjivanje varijanti i rizika Analiza rizika 4 Organičenja 4 Analiza rizika 3 Organičenja 3 Analiza rizika 2 Organičenja 2 Varijante 4 Prototip 4 Prototip 3 Varijante 3 Varijante 2 Analiza rizika 1 Organičenja 1 Prototip 2 Prototip 1 Varijante 1 start Zahtevi, plan razvoja Pricipi rada Zahtevi prema softveru Detaljni dizajn Dizajn softvera Plan razvoja Validacija zahteva Plan integracije i testiranje Validacija i verifikacija dizajna Kodiranje Razvoj i testiranje Plan Plan implementacije Testiranje

33. Aplikativni softver Agilne metode (1) Agilne metode (Agile Alliance, 2001.) su nastale kao otpor mnogim ranijim modelima razvojnog procesa koji su pokušavali da nametnu neki oblik discipline vezane za osmišljavanje softvera, dokumentovanje, razvoj i testiranje. Ideja je da se naglasi uloga fleksibilnosti u spretnom brzom razvoju softvera. 4 principa agilnog razvoja Umesto planiranja i praćenja plana, važnije je odgovarati na promene, jer se ne mogu svi zahtevi predvideti na početku razvoja. Za uspešnost projekta najvažniji su kvalitet ljudi koji na njemu rade i kvalitet njihove saradnje. Postupci i alati imaju sporedni značaj. Zajednički rad sa naručiocem je vrlo važan, jer se tako naručilac uključuje u ključne aspekte razvoja. Bolje je uložiti vreme u izradu softvera koji radi, nego u izradu sveobuhvatne dokumentacije.

34. Aplikativni softver Agilne metode (2) Primeri agilnih procesa • Ekstremno programiranje, XP (eXtreme Programming), (Beck, 1999.) predstavlja skup tehnika za omogućavanje kreativnosti projektnog tima uz minimizovanje prekomernog administriranja. • Crystal(Cockburn, 2002.) predstavlja skup pristupa zasnovanih na činjenici da svaki projekat zahteva različit skup dogovora i metodologija. Stoga je najvažnije naći način za jednostavnu i kompaktnu organizaciju projektnog tima kako bi razvojni proces bio brži i efikasniji. • Scrum(Object Technology, Schwaber & Bedle, 2002.) je model koji se zasniva na iterativnom razvoju, gde se svaka 30-dnevna iteracija naziva “sprint”, a služi za implementiranje zaostalih zahteva najvišeg prioriteta. Više samoorganizovanih i autonomnih timova paralelno implementira delove proizvoda. Koordinacija se vrši na kratkim dnevnim sastancima (scrum). • Adaptivni razvoj softvera, ASD (Adaptive Software Development) (Highsmith & Bayer, 2000.) se zasniva na šest osnovnih principa: fokusiranju tj. postavljanju ciljeva, opisu na bazi svojstava, iterativnosti, poštovanju utvrđenog vremena isporuke, prihvatanju rizika i tretiranju izmena kao prilagođavanje sistema, a ne kao grešaka.

35. Aplikativni softver Ekstremno programiranje (1) Karakteristike agilnosti Komunikacija Povratna sprega Jednostavnost Odvažnost • Komunikacija podrazumeva neprestanu razmenu informacija između naručioca i projektnog tima. • Jednostavnostohrabruje projektni tim da odabere najjednostavniji dizajn ili implementaciju koji odgovaraju potrebama naručioca. • Odvažnostje posvećenost blagovremenim i čestim isporukama funkcija. • Povratne spregese ugrađuju u različite aktivnosti tokom procesa razvoja.

36. Aplikativni softver Ekstremno programiranje (2) Programiranje u paru. Igra planiranja. Generišu se mape svih budućih verzija (šta sadrže i rokovi isporuke). Kolektivna svojina. Svaki učesnik može da izmeni bilo koji deo sistema, dok je on u fazi razvoja. Male verzije. Funkcije su dekomponovane na male delove koji se isporučuju, a zatim proširuju. Koriste se inkrementalni i iterativni ciklusi. Neprekidna integracija.Rade se dnevne ili satne isporuke. Naglasak na malim inkrementima poboljšanja. Metafora. Pojektni tim se usaglašava oko zajedničke vizije rada sistema. Faktori XP-a Jednostavan dizajn.Tretiraju se samo aktuelne potrebe. Održiv korak.Umorni ljudi više greše. Sugeriše se 40 sati nedeljno rada. Ako to nije dovoljno, nešto nije u redu (rokovi ili resursi). Testovi pre kodiranja. Funkcionalne testove definiše naručilac, a izvršava tim. Testove delova realizuje tim radi verifikacije. Naručilac raspoloživ na terenu. Prerađivanje koda. Promena zahteva primorava tim da preispita postojeća rešenja. Ovo je najveći problem. Standardi kodiranja. Insistira se na njima zbog boljeg razumevanja u timu.

37. Aplikativni softver Alati i tehnike za modelovanje • Izbor alata i tehnika za modelovanje zavisi od sadržaja modela. Postoje različite vrste notacija koje se mogu koristiti: • tekstualne, u kojima se procesi iskazuju kao funkcije, • grafičke, u kojima se procesi prikazuju u formi hijerarhije pravougaonika i strelica, • kombinovane, koje kombinuju slike, tekst i grafički prikaz sa tabelama. • Poželjne osobine alata i tehnika za modelovanje (Curtis, Kellner & Over, 1992.): • Da ljudima olakšaju razumevanje i međusobnu komunikaciju. • Da pruže podršku poboljšanju procesa. Tehnika treba da identifikuje komponente razvoja i održavanja, omogući višekratnu upotrebljivost procesa i podprocesa, kao i poređenje alternativa. • Da pruže podršku upravljanju procesom. Tehnika treba da omogući planiranje i prognoziranje, nadgledanje i upravljanje procesom, kao i merenje ključnih karakteristika procesa. • Da obezbede automatsko vođenje tokom izvršavanja procesa. Tehnika treba da definiše okruženje za razvoj softvera, obezbedi smernice i sugestije i sačuva višekratno upotrebljive reprezentacije procesa za kasniju upotrebu. • Da pruže podršku automatskom izvršavanju procesa. Tehnika treba da automatizuje proces u celosti ili delimično.