Ohjelmistotuotanto historiallinen perspektiivi 25.11.2013 JOTU2013/K.Systä 1
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 25.11.2013 JOTU2013/K.Systä 2
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. 25.11.2013 JOTU2013/K.Systä 3
Tentit 10.12.2013 27.01.2014 25.11.2013 JOTU2013/K.Systä 4
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. 25.11.2013 JOTU2013/K.Systä 5
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 25.11.2013 JOTU2013/K.Systä 6
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 25.11.2013 JOTU2013/K.Systä 7
Formaalit menetelmät http://formalmethods.wikia.com/wiki/formal_methods: Formal methods are mathematical techniques for developing computer-based software and hardware systems. Esimerkki Z-kielestä (http://images4.wikia.nocookie.net/formalmethods/images/4 /4e/Zbook.pdf) Aika erilainen tapa kuvata vaatimuksia kuin käyttötapaukset? 25.11.2013 JOTU2013/K.Systä 8
Lähestymistapojen eroista AddBirthday??? Ask? BirthDayBook JOTU2013/K.Systä 9 25.11.2013
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); (http://www2.sys-con.com/itsg/virtualcd/java/archives/0701/amsterdam/index.html) 25.11.2013 JOTU2013/K.Systä 10
Mitä on ohjelmistotuotanto? Vaatimusmäärittelyä Asiakas Taitavaa ohjelmointia Elinkaarimallit Yhteispeliä, yhteistä peliä Algoritmit Tietorakenteet Ohjelmointikielet Arkkitehtuurit Laadunvarmistusta Projektinhallinta Kehittäjä Testaus Validointi 26.8.2013 TIE-02300/Kari Systä 11
Laajempi tapa ajatella Käyttäjät Vaatimusmäärittelyä Maksajat Taitavaa ohjelmointia Yhteispeliä, yhteistä peliä Ylläpitäjät Laadunvarmistusta Kehittäjät 26.8.2013 TIE-02300/Kari Systä 12
Barry Boehm: Making difference in the Software Century IEEE Computer March 2008 (http://sunset.usc.edu/csse/techrpts/2008/usc-csse-2008-800/usc-csse-2008-800.pdf) 26.8.2013 TIE-02300/Kari Systä 13
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ä 26.8.2013 TIE-02300/Kari Systä 14
Softan onnistumis-% on kuitenkin huonompi 60 50 40 30 20 Onnistunut Epäonnistunut Haasteellinen 10 0 2000 2002 2004 2006 2008 Lähde: The Standish Group. Chaos Summary for 2010 [WWW]. 2010. Saatavissa: http://insyght.com.au/special/2010chaossummary.pdf. (Uudelleen visualisoitu Erkka Vastamaan diplomityössä) 26.8.2013 TIE-02300/Kari Systä 15
Ohjelmistotuotannon kehityskohteet Vaatimusmäärittelyä Taitavaa ohjelmointia Yhteispeliä, yhteistä peliä Laadunvarmistusta Ohjelmointi Tekniikat Työn koordinointi Asiakas/ vaatimukset Prosessit 26.8.2013 TIE-02300/Kari Systä 16
Prosessit 26.8.2013 TIE-02300/Kari Systä 17
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 26.8.2013 TIE-02300/Kari Systä 18
Prosessit - RUP 26.8.2013 TIE-02300/Kari Systä 19
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. 26.8.2013 TIE-02300/Kari Systä 20
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). 26.8.2013 TIE-02300/Kari Systä 21
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 17.8.2010 22
17.8.2010 23 CMMI: Constellations Source: CMMI v1.2 Overview
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 17.8.2010 24
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 5 17.8.2010 25
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. 26.8.2013 TIE-02300/Kari Systä 26
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. 26.8.2013 TIE-02300/Kari Systä 27
Prosessit sutjakka (Lean) Poppendieck, M., Lean Software Development. IEEE 29th International Conference on Software Engineering (ICSE'07 Companion), 2007. s. 165 166. 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. 26.8.2013 TIE-02300/Kari Systä 28
XP (Extreme programming) Pariohjelmointi Testivetoinen kehitys http://www.extremeprogramming.org/ 26.8.2013 TIE-02300/Kari Systä 29
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 http://www.kanbanblog.com/explained/ 26.8.2013 TIE-02300/Kari Systä 30
http://en.wikipedia.org/wiki/kanban_board 26.8.2013 TIE-02300/Kari Systä 31
http://leansoftwareengineering.com/2007/ 10/27/kanban-bootstrap/ 26.8.2013 TIE-02300/Kari Systä 32
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 26.8.2013 TIE-02300/Kari Systä 33
Ohjelmointi laajemmin Koodari Arkkitehti Testaaja 26.8.2013 TIE-02300/Kari Systä 34
Itsestään selvyyksiä ei ole vaikka niitä oletetaan (http://www.realfarmacy.com/autistic-second-grader-makes-the-rest-of-us-look-silly/) 26.8.2013 TIE-02300/Kari Systä 35
Hopealuotia etsimässä Fred Brooks: "No Silver Bullet Essence and Accidents of Software Engineering". IEEE Computer 20 (4): 10 19. 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 26.8.2013 TIE-02300/Kari Systä 36
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 26.8.2013 TIE-02300/Kari Systä 37