Programski inženiring

1. Programski inženiring (Software Engeneering)

2. Dejansko stanje – posledica programskega NEINŽENIRINGA!!! sprememba Stopnja napak Idealna krivulja Čas Programsko inženirstvo Kaj je SWE? (a spet teorija) Zakaj SWE? (kako bi bilo, če bi se temu izognili) SWE da ali ne? Izhodišče: ali ti je všeč, da je SW tako buggy in hkrati tako drag?

3. Programsko inženirstvo(software engineering – SWE) D E F I N I C I J E (opredelitev) • Boehm:SWE je praktična uporaba računalništva, informatike, managementa in drugih znanosti za analizo, načrtovanje, konstrukcijo in vzdrževanje programske opreme in pridružene dokumentacije • Dennis: SWE je uporaba principov, veščin in umetnosti pri načrtovanju in konstruiranju programov in programskih sistemov. • Parnas: SWE je programiranje, če je izpolnjen vsaj en od naslednjih dveh pogojev: • V razvoj programa je vključena več kot ena oseba • Proizvedena bo več kot ena verzija programa • Fairley:SWE je tehnološka in managerska disciplina, ki se ukvarja s sistematično proizvodnjo in vzdrževanjem programskih izdelkov, ki so razviti in prilagojeni pravočasno in sicer v okviru načrtovanega proračuna (stroškov).

4. Programsko inženirstvo (nad.) D E F I N I C I J E (opredelitev) • Pomberger & Blaschek: SWE se praktična uporaba znanosti za ekonomično produkcijo in uporabo visoko kakovostne programske opreme. • ‘Po domače’: SWE uporaba tehničnih in ne-tehničnih znanj pri razvoju, obratovanju in vzdrževanju programske opreme, s katero so zadovoljni uporabniki in razvijalci. • Okolje programskega inženirstva • sistem računalnikov, podporne programske opreme, pripomočkov, procedur in podpornega osebje, ki razvijalcem programske opreme zagotavlja potrebne pogoje, avtomatizacijo procesov, metodologije in orodja.

5. Problemi razvoja velikih programskih sistemov • Pravilnost oz. nepredvidljiva kakovost končnega produkta • Učinkovitost oz nizka produktivnost osebja in skupin • Obvladovanje kompleksnosti sistema • Zanesljivost sistema • Fleksibilnost sistema • Slaba / pomanjkljiva dokumentacija • Slabo vodenje / organizacija projektov • Predolgi razvojni cikli • Pomanjkanje kadra za razvoj programske opreme • Visoki stroški razvoja • Visoki stroški vzdrževanja POSLEDICE • Astronomska cena programskih rešitev • Nezadovoljni uporabniki • Nezadovoljni razvijalci

6. Vzroki za probleme pri razvoju SW • Proces razvoja je v teoriji in praksi še vedno relativno slabo opredeljen (?ali pa enostavno ne poznamo teorije?) • Uporaba zastarelih/ lastnih improviziranih metod razvijanja IS • Nezadostna uporaba računalniške podpore pri razvijanju IS • Pomanjkljivo metodološko znanje razvijalcev IS • Nezadostno upoštevanje dejstva, da informacijski procesi in sistemi za različne ravni in načine upravljanja zahtevajo različne metode njihovega razvijanja

7. Atributi kakovosti SW

8. Glavni vzroki za (ne)uspeh SW • Zahteve uporabnikov so napačno ali le delno zbrane; • Zahteve uporabnikov se prepogosto spreminjajo; • Uporabniki niso pripravljeni dajati zadostne resurse projektom IT; • Uporabniki ne želijo sodelovati z razvijalci • Uporabniki imajo nerealna pričakovanja • Sistem ni več pomoč / benefikacija za uporabnike; • Razvijalci ‘niso kos’ svoji nalogi.

9. Dobri načrti so delo dobrih načrtovalcev • Najeti najboljše načrtovalce • Načrtovalcem zagotoviti permanentno izobraževanje in ispopolnjevanje; • Podpirati izmenjavo informacij in znanj ter interakcijo med načrtovalci; • Motivirati načrtovalce (odstraniti ovire) in usmeriti njihove napore v produktivno delo; • Ponuditi dobro delovno okolje • Uskladiti cilje posameznikov z strategijo in cilji organizacije • Dati poudarek na timskem delu

10. Mere za zagotavljanje kakovosti SW • Konstruktivne • Dosledna uporaba metod v vseh fazah razvojnega procesa • Uporaba ustreznega razvojnega orodja • Razvoj SW na osnovi visoko kakovostnih pol-produktov • Dosledno pisanje/vzdrževanje razvojne dokumentacije • Analitične • Statična analiza programa • Dinamična analiza programa • Sistematično izbiranje testnih primerov • Konsistentno beleženje rezultatov analiz • Organizacijske • Nenehno (permanentno) izobraževanje razvijalcev • Institucionalizacija zagotavljanja kakovosti (uvedba standardov ISO, ANSI, IEEE…)

11. Večplastnost programskega inženirstva

12. Življenjski cikel programske opreme(SDLC - System Development Life Cycle)

13. Življenjski cikel • prične se z zasnovo in konča z vzdrževanjem pri uporabniku • razvojni proces razčlenimo na zaporedje medsebojno odvisnih aktivnosti, ki temeljijo na začetnih potrebah po izdelavi uporabnega produkta • zakaj “cikel" - vsak razviti produkt generira nove potrebe • Definicija (standard ANSI/IEEE Std 792-1983): • življenjski cikel programske opreme = nabor diskretnih aktivnosti v času razvoja programske opreme in programskih sistemov • faza življenjskega cikla = čas izvajanja posameznih aktivnosti (tudi sama aktivnost)

14. Problem Problem Delovanje in vzdrževanje Analiza zahtev Specifikacija(opredelitev) sistema Testiranje sistema Implementacija in testiranje komponent Načrtovanje sistema in komponent Faze življenjskega cikla programske opreme

15. Faze življenjskega cikla1. analiza zahtev vključuje: analiziranje programskega problema (funkcionalen opis) in specifikacije želenega obnašanja grajenega sistema (funkcionalne zahteve in specifikacije) rezultat: Software Requirements Specifications oz. Specifikacije Zahtev Programske Opreme SZPO opisuje: funkcionalne zahteve, značilnosti strojnega okolja, obliko uporabniških vmesnikov in performančne cilje oz. zahtevane zmogljivosti

16. Faze življenjskega cikla1. analiza zahtev (nad.) aktivnosti faze analize ločimo v 2 skupini: • analiza problema • rezultat = popolno razumevanje problemskega področja • opis produkta • rezultat = skladen in kompleten dokument programskih specifikacij aktivnosti obeh skupin ne izvajamo zaporedno, temveč sočasno • v tej fazi odgovorimo na vprašanje: KAJPOTREBUJEMO oz. kaj naj bi grajeni programski sistem zagotavljal

17. Faze življenjskega cikla2. načrtovanje vključuje: • preliminarno načrtovanje – dekompozicija(razčenitev) programskega sistema v njegove dejanske konsistentne komponente in interaktivna razgradnja teh komponent v vedno manjše podkomponente, dokler niso dovolj majhne, da jih lahko ljudje brez težav razumejo vsak modul je dokumentiran - opisani so vhodi, izhodi in funkcije. • podrobno načrtovanje – za vsak modul definiramo in dokumentiramo algoritme • podrobno načrtovanje – za vsak modul definiramo in dokumentiramo algoritme • rezultati: • modularna razgradnja • definicija strukture podatkov • definicija formata datotek • opis pomembnejših algoritmov • v tej fazi odgovorimo na vprašanje: KAKO oz. kako bomo zadovoljili identificirane zahteve oz. obnašanje sistema

18. Faze življenjskega cikla2. načrtovanje (nad.) rezultat: • modularna razgradnja • definicija strukture podatkov • definicija formata datotek • opis pomembnejših algoritmov v tej fazi odgovorimo na vprašanje: KAKO oz. kako bomo zadovoljili identificirane zahteve oz. obnašanje sistema

19. Faze življenjskega cikla3. implementacija izvedemo kodiranje • transformacija algoritmov v računalniku razumljiv jezik • testiramo in čistimo napake vsakega modula, specificiranega pri načrtovanju

20. Faze življenjskega cikla4. testiranje in integracija testiranje posameznih modulov • osredotočimo na del programa, da lažje ugotovimo in odstranimo napake • kontroliramo tudi obnašanje modula glede na podane specifikacije (funkcionalno testiranje) integracijsko testiranje • že stestirane module integriramo oz. povežemo (združimo) v enotno programsko strukturo ter jih testiramo (testiranje programskih komponent) sistemsko testiranje • preverimo, ali se celoten programski sistem, postavljen v določeno strojno okolje, obnaša ustrezno podanim specifikacijam zahtev programske opreme

21. Faze življenjskega cikla5. prenos v ciljno okolje / uporaba • izročimo programsko in pripadajočo strojno opremo • začne se uporaba sistema 6. vzdrževanje • neprestano iskanje napak in njihovo odstranjevanje • razširitev sistema 7. umik iz uporabe

22. Modeli življenjskega cikla Klasični pristopi: • SLAM-DUNK model • BAROČNI model • KASKADNI model • KASKADNI model, razširjen s prototipno komponento • SPIRALNI model Objektni pristopi: • Unified Process

23. Slam- dunk model • najbanalnejši in najpogosteje uporabljen model • izrazito negativen primer • na začetku se začne tudi kodiranje • filozofija uporabnika metode: preprosteje je kodirati, odkrivati in popravljati napake kot pa izgubljati čas z "znanostjo" - psihološko ozadje • občutek, da lahko brez natančne razgradnje pristopimo k realizaciji, saj imamo "vse v glavi" • takšne projekte imenujemo tudi "kmalu bo gotovo", zanje pa je značilno, da vedno zamujajo ali pa nikoli niso gotovi

24. Baročni model • vnaša disciplino v prej opisan "slam-dunk" model • bistvo modela: predhodna faza se konča pred naslednjo fazo - ta model lahko imenujemo tudi "etapni model" • baročni model uzakonjuje pretirano disciplino • zahteve so vedno spreminjajoče =>paradoks, faza analize se nikoli ne konča • v realni okvir lahko ta proces spravimo le tako, da se fazi analize in snovanja delno prekrivata • baročni model enostavno ne deluje, ker razvoj programske opreme ni determinističen proces • ta model je prispeval k razvoju realnejšega "kaskadnega" modela

25. Kaskadni model Analiza (KAJ?) Načrtovanje (KAKO?) Implementacija (NAREDI) Testiranje (PREIZKUSI) Prenos v ciljno okolje Pomanjkljivost: predolg čas porabljen od začetka do implementacije. Rešitev – uporaba prototipov Uporaba in vzdrževanje

26. Prototipiranje Cilji prototipiranja: • oddaljiti se od stroge zaporednosti • pospešiti odzivni čas • zmanjšati tveganje za stranko in razvijalca • cenenost in hitrost • nepopolno, vendar da nazorne rezultate Prototip - delna implementacija sistema, narejena s primarnim namenom, da omogoči uporabniku, stranki ali razvijalcu čim lažjo seznanitev s problemom ali njegovo rešitvijo. (A. Davis)

27. Metodi prototipiranja • metoda zavračanja (throw-away) • ustrezna za raziskovalne in eksperimentalne prototipe • zgradimo hiter in robusten(quick-and-dirty) prototip, ki ga predstavimo uporabnikom z namenom, da skupaj z njimi: • ugotovimo izvedljivost želja(zahtev) • potrdimo potrebnost oz. nujnost posameznih funkcij • odkrijemo manjkajoče (nepodane) zahteve • raziščemo možnosti razvoja ustreznega uporabniškega vmesnika. • po pridobitvi vsega potrebnega znanja o problemu in o rešitvah prototip zavržemo in začnemo razvijati sistem • razvojna metoda(evolutionary) • ustrezna za razvojne prototipe • sistematičen pristop pri izgradnji, prototip preraste v sam sistem

28. Spiralni model ovrednoti alternative, identificiraj in zmanjšaj tveganja določi cilje, alternative, omejitve analiza tveganja p r o t o t i p i principi načrt zahtev zahteve sistemsko podrobno načrtovanje načrt razvoja načrtovanje načrt izvedbe implement test & instalacija načrtovanje naslednje faze razvoj& verifikacija izdelka

29. Analiza spiralnega modela • omogoča boljšo oceno tveganja • mešanica čistega strukturiranega in fleksibilnega prototipnega modela • podpira hitre odzive in zagotavlja kakovost

30. Preverjanje rezultatov VALIDACIJA • preverjanje ustreznosti programskega izdelka • Ali gradim pravi produkt? VERIFIKACIJA • preverjanje pravilnosti programskega izdelka • Ali gradim produkt pravilno? Dokaz pomena sprotnega preverjanja Razmerje stroškov za odpravljanje napake, ki je odkrita v fazi analize zahtev : v fazi vzdrževanja = 1 : 200 Značilno za XP (eXtreme programming)

31. Dva inženirska pristopa • RAZVOJNO INŽENIRSTVO • proizvede nov sistem in izhaja iz začetnih postavk ter danosti • OBRNJENO INŽENIRSTVO • izhaja iz sistema, ki obstaja in deluje • proces razstavitve in analize obstoječega fizičnega podatkovnega in procesnega modela IS in njegova vnovična obnovljena ali spremenjena izgradnja • vzroki: uvedba sodobnejše tehnologije ali spremenjene zahteve uporabnikov • uporaba: za vzdrževanje, izboljševanje, spreminjanje ali ažuriranje informacijskega sistema ali za celotno zamenjavo z novim sistemom

32. Vidiki razvoja programskih rešitev Procesni vidik => Diagram toka podatkov (DFD) • opisuje transformacije nad podatki • poenostavljena notacija: Vhod --> Proces --> Izhod • obravnava procesno obnašanje sistema - kako sistem pretvori vhode v izhode Podatkovni (informacijski) vidik => Entitetno relacijski diagrami (ERD) in podatkovni slovarji • opisuje obliko informacij, ki jih mora sistem procesirati • nakazuje medsebojne relacije med informacijskimi enotami • nanaša se na strukturo in uporabo podatkov v sistemu Dogodkovni vidik • opisuje obnašanje sistema v realnem času • nanaša se na dinamično obnašanje sistema => kako si dogodki sledijo v časovnem zaporedju • kontrolni diagramiin diagrami prehajanja stanj

33. Orodja CASE Computer Aided Software Engineering • CASE - tehnologija avtomatizacije razvoja in vdrževanja programske opreme oz. sistemov • Osnovna ideja: s povezovanjem in avtomatizacijo vseh faz življenjskega cikla programskih sistemov zagotoviti popolnoma integrirana orodja, ki bodo zmanjšala trud, potreben za razvoj in vzdrževanje programske opreme

34. Pridobitve CASE • praktičnost strukturnih in objektnih tehnik • vsiljuje programsko/informacijsko inženirstvo • izboljšana kvaliteta programske opreme (avtomatske kontrole, preverjanja) • praktičnost prototipiranja • lažje, enostavnejše vzdrževanje • skrajšan čas razvoja • razvijalci se lahko osredotočijo na kreativni del razvoja • ponovna uporaba programskih komponent

35. Funkcije CASE • Diagramska orodja// risanje diagramov, kreiranje grafičnih specifikacij • Oblikovalniki // za kreiranje obrazcev, poročil, specifikacij, preprostih prototipov • Podatkovni slovarji • Preverjanje specifikacij // avtomatsko odkrivanje nepopolnih, sintaktično nepravilnih in nekonsistentnih specifikacij • Generatorji kode// generiranje izvedljive kode avtomatično (direktno) iz grafičnih specifikacij sistema • Generatorji dokumentacije // za pridobivanje tehnične in uporabniške dokumentacije, ki jo zahtevajo razvojne tehnike

36. CASE repozitorij mehanizem za hranjenje in organizacijo vseh informacij o programskem sistemu: • informacije oproblemu, ki ga rešujemo • inf. o problemskem področju oz. domeni • inf. o procesu, ki ga uporabljamo • podatkovne in procesni modeli • prototipi • resursi projekta in zgodovina, • organizacijski kontekst ... • omogoča praktično uporabo koncepta ponovne uporabnosti (reusability) => dvig produktivnosti// ne gre le za ponovno uporabo izvorne kode modulov, temveč tudi projektnih planov, prototipnih modelov, specifikacij, ..

37. Cilji CASE Spremeniti način gradnje programskih sistemov Zagotoviti: 1. Interaktivno razvojno okolje//hitri odzivni časi, namenskimi resursi in zgodnje preverjanje/iskanje/ izločanje napak 2. Avtomatizacijo mnogih opravil razvoja in vzdrževanja 3. Vizualno programiranje// zmogljiv uporabniški vmesnika Končni cilj CASE tehnologije: s pomočjo integriranih programskih orodij avtomatizirati celoten življenjski cikel programske opreme

38. Kategorije CASE • Upper CASE (front-end CASE) • zgodnje faze življenjskega cikla (analiza in načrtovanje) • Lower CASE (back-end CASE) • kasnejše faze življenjskega cikla (implementacija in vzdrževanje) • Integrirana (integrated) CASE

39. Nekatera orodja CASE • POSE (Picture Oriented Software Engineering) • PowerDesigner • Oracle Designer • Rational ROSE • Popkin System Architect • CA Cool • Case Studio • DBDesigner Integracija CASE in RAD • Microsoft Visual Studio (Enterprise) • IBM VisualAge • Borland Enterprise Studio Rapid Application Development

40. Mal’ za šalo, mal’ za resalias ‘Življenje nekega programa’ • Programer je napisal in oddal program, za katerega verjame, da je brez napak. • Program je testiran, najdenih 20 napak. • Programer popravi 10 napak in pojasni ekipi za testiranje, da preostalih 10 napak niso pravi ‘hrošči’. • Ekipa za testiranje ugotovi, da 5 popravkov ne deluje in odkrije 15 novih hroščev. • Dokler ne ponorijo v prodaji in marketingu, se ponavlja naslednja zgodba: • Preberi točko 3. • Preberi točko 4. • Zaradi pritiska s strani komercialistov in marketinga (najava novega produkta se je zanašala na veliko preoptimističen terminski načrt projekta), program dajo v uporabo. • Uporabniki najdejo 137 novih hroščev. • Originalnega programerja (po tem ko je dobil plačilo za svojo ‘umetnijo’) ni nikjer. • Na novo zbrana programerska ekipa odpravi skoraj vseh 137 hroščev, vendar najde 468 novih. • Originalni programer pošlje (slabo plačani) ekipi za testiranje kartici iz Dominikanske Republike in Jamajke. Celotna ekipa za testiranje da odpoved. • S strani konkurenčen firme pride do sovražnega prevzema podjetja. Novi lastniki poberejo ves profit od zadnje verzije programa, ki je imela 783 hroščev. • Novi CIO pride v nadzorni odbor. Najame programerja, ki naj ponovno naredi (zlepi) program iz ostankov starega. • Programer napiše in odda program, za katerega verjame, da je brez napak. • Vrni se na točko 2.