Programski inženiring (Software Engeneering)

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? Dejansko stanje – posledica programskega NEINŽENIRINGA!!! sprememba Stopnja napak Čas Idealna krivulja

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).

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.

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

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

Atributi kakovosti SW

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.

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

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…)

Večplastnost programskega inženirstva

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

Ž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)

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

Faze življenjskega cikla 1. 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

Faze življenjskega cikla 1. 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: KAJ POTREBUJEMO oz. kaj naj bi grajeni programski sistem zagotavljal

Faze življenjskega cikla 2. 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 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

Faze življenjskega cikla 2. 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

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

Faze življenjskega cikla 4. 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

Faze življenjskega cikla 5. 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

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

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

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

Implementacija (NAREDI) Testiranje (PREIZKUSI) Uporaba in vzdrževanje 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

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)

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

Spiralni model analiza tveganja p r o t o t i p i 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

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

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)

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

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 diagrami in diagrami prehajanja stanj

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

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

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

CASE repozitorij mehanizem za hranjenje in organizacijo vseh informacij o programskem sistemu: informacije o problemu, 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, ..

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

Kategorije CASE Upper CASE (front-end CASE) Lower CASE (back-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

Nekatera orodja CASE Integracija CASE in RAD 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

Mal’ za šalo, mal’ za res alias ‘Ž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.