Ohjelmistotuotanto historiallinen perspektiivi JOTU2013/K.Systä 1

Transkriptio

1 Ohjelmistotuotanto historiallinen perspektiivi JOTU2013/K.Systä 1

2 Alustava luentoaikataulu 26.8: Johdanto + historiaa, mitä on ohjelmistotuotanto 2.9: Ohjelmistojen roolista ja ohjelmistotyön määrästä, ohjelmistotyypit 9.9: Miten ohjelmistotyö organisoidaan (vaihejako ja prosessi-mallit) 16.9: vaatimusmäärittelyt 23.9: projektitoiminta 30.9: Yleiset notaatiot erityisesti UML 7.10: Esimerkkiprojekti (vierailuluento esillä ihan oikea projekti) 21.10: Asiakasroolista 28.10: Käyttäjä ja käyttäjäkokemus ohjelmistoprojektissa (Kati Kuusinen) 4.11: Tiedon mallintaminen 11.11: Ohjelmisto osana laitetta 1 (Marko Leppänen) 18.11: IPR, sopimukset, avoin lähdekoodi 25.11: Mitä on ohjelmistuotanto (historiaperspektiivi, kertausta) 2.12: Kertausta, tentiin valmistautuminen JOTU2013/K.Systä 2

3 Nootti Tämän luennon kalvot ovat tenttimateriaalia vain siltä osin kun ne on esitetty jo aikaisemmin tai koskevat kirjan niitä osia jotka koskevat tätä kurssia (kts 2.12 luento) Saattavat toki auttaa ymmärtämään JOTU2013/K.Systä 3

4 Tentit JOTU2013/K.Systä 4

5 Ohjelmistotuotanto Software engineering Engineering (American Engineers' Council for Professional Development) The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation or safety to life and property JOTU2013/K.Systä 5

6 Perinteinen insinöörityö vs ohjelmistotuotanto Fysiikka, statiikka, lujuuslaskenta => silta Fysiikka, teoreettinen sähkötekniikka, elektroniikka => analoginen radio Käyttötapaukset UML-kaaviot Iteraatiot/Sprintit Hillitön koodaaminen Toimiva softa Notaatiot, käytännöt, nyrkkisäännöt, kokemus, intuitio => toimiva softa JOTU2013/K.Systä 6

7 Koulukunnat Formalistit Matemaattisen tarkka määrittely Systemaattiset askeleet kohti suoritettavaa ohjelmaa Jokaisen askeleen oikeellisuus voidaan todistaa matemaattisesti Ohjelman ominaisuudet voidaan todistaa Käytännön ihmiset Johtaminen ja organisointi Tekniset ratkaisut JOTU2013/K.Systä 7

8 Formaalit menetelmät Formal methods are mathematical techniques for developing computer-based software and hardware systems. Esimerkki Z-kielestä ( /4e/Zbook.pdf) Aika erilainen tapa kuvata vaatimuksia kuin käyttötapaukset? JOTU2013/K.Systä 8

9 Lähestymistapojen eroista AddBirthday??? Ask? BirthDayBook JOTU2013/K.Systä

10 Formaalien menetelmien merkityksestä Pääasiallinen sovelluskohde on kriittiset järjestelmät Toiveet läpilyönnistä olleet liian optimistisia Vaikuttanut paljon mm. ohjelmointikieliin Esimerkki Java:n assertio TransactionEntry te =(TransactionEntry) assoc.getentry(key); if (te == null) { te = new TransactionEntry(key, dur); assoc.put(key, te); } else { } assert te.getstate() == te.removed; te.recreate(dur, session); ( JOTU2013/K.Systä 10

11 Mitä on ohjelmistotuotanto? Vaatimusmäärittelyä Asiakas Taitavaa ohjelmointia Elinkaarimallit Yhteispeliä, yhteistä peliä Algoritmit Tietorakenteet Ohjelmointikielet Arkkitehtuurit Laadunvarmistusta Projektinhallinta Kehittäjä Testaus Validointi TIE-02300/Kari Systä 11

12 Laajempi tapa ajatella Käyttäjät Vaatimusmäärittelyä Maksajat Taitavaa ohjelmointia Yhteispeliä, yhteistä peliä Ylläpitäjät Laadunvarmistusta Kehittäjät TIE-02300/Kari Systä 12

13 Barry Boehm: Making difference in the Software Century IEEE Computer March 2008 ( TIE-02300/Kari Systä 13

14 Miksi siis softan tekeminen on niin vaikeaa? (Verrataan talon rakentamiseen) Ohjelmisto Ei tiedetä mitä tehdään (vaatimukset epäselviä) Vaatimukset muuttuvat tai sitten ollaan suosiolla ketteriä Osaamisongelmat kaikki haluaa sen parhaan koodarin Aikataulu ja budjettiongelmat Laatuongelmat Yhdessä tekeminen vaikeaa Talo Kaikilla on joku käsitys siitä millainen on talo. On valmiita malleja. Vaatimukset helppo erotella ja vaiheistaa (tontti. tapetit) kaikki haluaa sen parhaan timpurin Ovat ongelmallisia jos uudenlainen tai muuten outo talo Laatuongelmat Esimerkiksi: huoneita voi tehdä rinnakkain ja ovi pysyy koko ajan sovitussa paikassa Taloa koskevat luonnonlait selvillä TIE-02300/Kari Systä 14

15 Softan onnistumis-% on kuitenkin huonompi Onnistunut Epäonnistunut Haasteellinen Lähde: The Standish Group. Chaos Summary for 2010 [WWW] Saatavissa: (Uudelleen visualisoitu Erkka Vastamaan diplomityössä) TIE-02300/Kari Systä 15

16 Ohjelmistotuotannon kehityskohteet Vaatimusmäärittelyä Taitavaa ohjelmointia Yhteispeliä, yhteistä peliä Laadunvarmistusta Ohjelmointi Tekniikat Työn koordinointi Asiakas/ vaatimukset Prosessit TIE-02300/Kari Systä 16

17 Prosessit TIE-02300/Kari Systä 17

18 Prosessit - trendit Vesiputous Seuraava vaihe on helppo jos edellinen on tehty kunnolla Hyvin määritelty on puoliksi tehty Pyritään minimoimaan muutosvaatimuksia Iteratiiviset (esim Spiral Barry Boehm) Oppimisen hyödyntäminen Riskien hallinnan parantaminen Vaatimusten tarkentaminen ja aikaisempi asiakaspalaute Testauksen aikaisempi aloittaminen Itsepetoksen välttäminen Asiakkaan luottamuksen säilyttäminen TIE-02300/Kari Systä 18

19 Prosessit - RUP TIE-02300/Kari Systä 19

20 RUP (Rational Unified Process) RUP (Rational Unified Process) on 1990-luvulla Rationalyrityksessä kehitetty laaja ohjelmistokehityksen prosessikehikko, joka on räätälöitävissä moniin eri tarkoituksiin. IBM RUP on tavattoman laaja kokonaisuus. Esimerkiksi erilaisia rooleja ja tärkeitä käsitteitä on yhteensä yli 100, eikä ole tarkoituskaan, että sen kaikkia piirteitä käytetään projektimallissa TIE-02300/Kari Systä 20

21 Kypsyystasot: Prosessit - CMM Taso 1: Initial Process: ei mitään vaatimuksia. Taso 2: Repeatable Process: toistettava prosessi eli projektissa onnistuminen voidaan toistaa, jos on tehty samantyyppisiä aikaisemmin. Taso 3: Defined Process: prosessi on määritelty oman organisaation tarpeista lähtien, sitä noudatetaan, ja sitä pyritään tehostamaan. Taso 4: Quantitatively Managed Process: prosessia mitataan ja mittaustuloksia käytetään sen parantamiseen. Taso 5: Optimizing Process: tietoa kerätään automaattisesti ja sitä käytetään prosessin optimoimiseksi. CMM-mallia kehitettiin aktiivisesti vuoteen 1997 asti. Malli hajosi vähitellen moniin osamalleihin, kuten ohjelmistokehityksen CMM-malliin, ylläpidon CMM-malliin, koulutuksen CMM-malliin jne. SEI päätti yhdistää kaikki mallit yhteiseen kehikkoon, ja näin syntyi CMMI (Capability Maturity Model Integration) TIE-02300/Kari Systä 21

22 Kehittämisen apuvälineitä CMMI Kaksi versiota staged representation (näyttää päällisin puolin vanhalta CMM:ltä) On kuitenkin muuttunut paljon => paljon väärinkäsityksiä continuous representation SPICE (eli ISO 15504) vastaa lähestymistavaltaan ja sisällöltään CMMI:n continuous representation -mallia

23 CMMI: Constellations Source: CMMI v1.2 Overview

24 Continous representation -malli Arviointi tehdään prosessialueittain Kullekin alueelle on määritelty kypsyystasot Capability Level 0: Incomplete Capability Level 1: Performed Capability Level 2: Managed Capability Level 3: Defined Capability Level 4: Quantitatively Managed Capability Level 5: Optimizing

25 CMMI: Core Process Areas (Core PA's) Abbre Name Category Mat. Level REQM Requirements Management Engineering 2 PMC Project Monitoring and Control Project Management 2 PP Project Planning Project Management 2 CM Configuration Management Support 2 MA Measurement and Analysis Support 2 PPQA Process and Product Quality Assurance Support 2 OPD Organizational Process Definition Process Management 3 OPF Organizational Process Focus Process Management 3 OT Organizational Training Process Management 3 IPM Integrated Project Management Project Management 3 RSKM Risk Management Project Management 3 DAR Decision Analysis and Resolution Support 3 OPP Organizational Process Performance Process Management 4 QPM Quantitative Project Management Project Management 4 OID Organizational Innovation and Depl. Process Management 5 CAR Causal Analysis and Resolution Support

26 Prosessit ketteryys (XP, Scrum, ja Kanban) Osaa alan ihmisiä alkoi prosessi-keskeisyys rasittaa ja syntyi manifesti: Me etsimme parempia keinoja ohjelmistojen kehittämiseen tekemällä sitä itse ja auttamalla siinä muita. Tässä työssämme olemme päätyneet arvostamaan Yksilöitä ja vuorovaikutusta enemmän kuin prosesseja ja työkaluja Toimivaa sovellusta enemmän kuin kokonaisvaltaista dokumentaatiota Asiakasyhteistyötä enemmän kuin sopimusneuvotteluita Muutokseen reagoimista enemmän kuin suunnitelman noudattamista. Vaikka oikeallakin puolella on arvoa, me arvostamme vasemmalla olevia asioita enemmän TIE-02300/Kari Systä 26

27 Ketteryys ovat sekä sisäistä että ulkoista Ketteryydellä on paljon yhteistä iteratiivisuuden kanssa, mutta manifestin arvot ovat tärkeitä Ketteryys on sisäinen toimintatapa, mutta sen lisäksi myös tapa kommunikoida asiakkaan kanssa TIE-02300/Kari Systä 27

28 Prosessit sutjakka (Lean) Poppendieck, M., Lean Software Development. IEEE 29th International Conference on Software Engineering (ICSE'07 Companion), s Seuraavat kaksi näyttävät olevan keskeisimpien joukossa: Eliminoi hukka (eliminate waste): hukkaa on kaikki, mikä ei tuota asiakkaalle lisäarvoa. Myös varastoon tehty työ on "hukkaa". Ihmiskeskeisyys (center on the people who add value): keskity ihmisiin, jotka tuottavat lisäarvon, ei siis niinkään johtoportaaseen vaan ruohonjuuritason tekijöihin. Tähän liittyy arvostus, tehokas kommunikointi, hyvä työilmapiiri sekä jatkuva koulutus ja toiminnan tehostaminen TIE-02300/Kari Systä 28

29 XP (Extreme programming) Pariohjelmointi Testivetoinen kehitys TIE-02300/Kari Systä 29

30 Kanban Hyvin pienen byrogratian prosessi Neljä periaatetta Visualisoi työnkulku (Kanban Board) Rajoita työn alla olevien asioiden määrä Siirrä työt sarakkeesta toiseen Monitoroi, sovita, paranna TIE-02300/Kari Systä 30

31 TIE-02300/Kari Systä 31

32 10/27/kanban-bootstrap/ TIE-02300/Kari Systä 32

33 Ohjelmoinnin kummallisuudesta Jos ohjelmoijat ei osaa, asiakkaan tarpeiden ymmärtäminen ei auta Jos ohjelmoijat ei osaa, ohjelma ei toimi oikein Jos ohjelmoijat ei osaa, aikataulut ja budjetit ei pidä Paljon puhutaan siitä kuinka erilaiset työkalut ja ohjelmointikielet tehostaa koodin tuottamista, mutta ihmisten osaaminen ratkaisee enemmän: Ohjelmointi Sovellusalue Ohjelmointikieli Ohjelmoinnin oppiminen Joillekin ihmisille luontaista Kokemus auttaa TIE-02300/Kari Systä 33

34 Ohjelmointi laajemmin Koodari Arkkitehti Testaaja TIE-02300/Kari Systä 34

35 Itsestään selvyyksiä ei ole vaikka niitä oletetaan ( TIE-02300/Kari Systä 35

36 Hopealuotia etsimässä Fred Brooks: "No Silver Bullet Essence and Accidents of Software Engineering". IEEE Computer 20 (4): Vaikeudet Monimutkaisuus (ei toistoa/toistettavuutta) Mukautuvuus (softan oletetaan sopeutuvan) Muutettavuus (helpoin osa muuttaa) Näkymättömyys (ei voi osoittaa, kosketella) Ratkaisuja historiasta Korkean tason ohjelmointikielet Osituskäyttö (tämä on tosi historiallista) Ohjelmointiympäristöt TIE-02300/Kari Systä 36

37 Hopealuotiehdokkaita Ada ja muut vastaavat ohjelmointikielihankkeet Olio-ohjelmointi Tekoäly Expertti-järjestelmät Automaattinen ohjelmointi Graafinen/visuaalinen ohjelmointi Ohjelmien verifiointi Työkalut ja ympäristöt Osto rakentamisen sijaan (edes komponentteja) Nopea prototypointi Inkrementaalinen kehitys TIE-02300/Kari Systä 37