Johdatus ohjelmistotuotantoon Luento nro 3, 8.9.2014 Kari Systä 8.9.2014 JOTU/K.Systä 1
Viikkoharjoitusryhmät Tiistai klo 10-12 ilm. 22/28, oli 16. Tiistai klo 12-14 ilm. 28/28, oli 21. Keskiviikko klo 10-12 ilm. 23/28, oli 19. Keskiviikko klo 12-14 ilm. 28/28, oli 29 (salissa oli toki tyhjää vielä). Keskiviikko klo 14-16 ilm. 28/28, oli 25. Keskiviikko klo 16-18 ilm. 28/28, oli 16. Torstai klo 12-14 ilm. 28/28, oli 22. Torstai klo 14-16 ilm. 28/28, oli 22. Torstai klo 16-18 ilm. 17/28, oli 14. 8.9.2014 JOTU/K.Systä 2
Harjoitustyöstä Ajankohtaisesti tällä viikolla Ryhmät kasattu 62 ryhmää Tehtävänannot annettu Sähköpostin piti tulla Varatkaa palaveri asiakkaan (ja assarin) kanssa IDLE:ssä Lähettäkää alustavat asiakasvaatimukset assarille ja toimittajaryhmälle http://www.cs.tut.fi/kurssit/tie-02300/harjoitustyo/ Assarit kiinnitetään tänään 8.9.2014 JOTU/K.Systä 3
Alustava luentoaikataulu 25.8: Johdanto + historiaa, mitä on ohjelmistotuotanto 1.9: Ohjelmistojen roolista ja ohjelmistotyön määrästä, ohjelmistotyypit 8.9: Miten ohjelmistotyö organisoidaan (vaihejako ja prosessi-mallit) 15.9: vaatimusmäärittelyt 22.9: projektitoiminta 29.9:???Yleiset notaatiot erityisesti UML 7.10: Esimerkkiprojekti (mahdollisesti vierailuluento) 21.10: Asiakasroolista 28.10: Käyttäjä ja käyttäjäkokemus ohjelmistoprojektissa 4.11: Tiedon mallintaminen 11.11: Ohjelmisto osana laitetta 1 18.11: Ohjelmisto osana laitetta 2 25.11: IPR, sopimukset, open source 2.12: Kertausta 8.9.2014 JOTU/K.Systä 4
Sananen kirjasta 1-2 5 3,8 Tällä kurssilla sillä tasolla jolla kaikkien pitäisi ymmärtää Tarkemmin kurssilla TIE-21100/6 Luku 1: Johdanto 1.1 Ohjelmistotuotanto 1.2 Ohjelmistojen yleisiä ominaisuuksia 1.3 Joitakin esimerkkijärjestelmiä 1.4 Ohjelmistokehitys projektina 1.4.1 Projekti asiakkaan kannalta 1.4.2 Projekti toimittajan kannalta 1.4.3 Hajautettu ohjelmistokehitys Luku 2: Ohjelmistoprojektimallit 2.1 Osa-alueet 2.2 Hankkeet ja projektit asiakasyrityksen kannalta 2.2.1 Yritysarkkitehtuuri 2.2.2 Hankkeet ja projektit 2.2.3 Perinteiset projektimallit 2.3 Vesiputousmalli 2.4 Protoilu 2.5 Iteratiivisuus 2.6 Esimerkki iteratiivisesta menetelmästä: RUP. 2.7 Ketteryys. 2.8 Scrum 8.9.2014 JOTU/K.Systä 5
Oppimistavoiteet Jonkinlainen käsitys siitä mitä ohjelmistotuotantoprosessi on? Mitä ja miksi on ketteryys? Miksi asiakasta kiinnostaa millainen prosessi on käytössä? 8.9.2014 JOTU/K.Systä 6
KERRATAANPA VÄHÄN 8.9.2014 JOTU/K.Systä 7
Mitä on ohjelmistotuotanto? Vaatimusmäärittelyä Asiakas Taitavaa ohjelmointia Elinkaarimallit Yhteispeliä, yhteistä peliä Algoritmit Tietorakenteet Ohjelmointikielet Arkkitehtuurit Laadunvarmistusta Projektinhallinta Kehittäjä Testaus Validointi 24.8.2014 TIE-02300/Kari Systä 8
Miksi ohjelmien tekeminen on niin vaikeaa? Ohjelmisto on abstrakti Tekijöiden ja asiakkaiden välillä ei välttämättä ole sama käsitys Työmäärän arviointi on vaikeaa Ohjelmisto on dynaaminen On muutettavissa muutettavuutta oletetaan Ohjelmistojen tekemistä on vaikea skaalata Tekijöiden määrän lisääminen nopeuttaa vain vähän valmistumista Mitä enemmän tekijöitä, sen enemmän kommunikointitarvetta. 24.8.2014 TIE-02300/Kari Systä 9
Tarve/idea Esiselvitys unohdetaan Tehdään itse Teetetään Ostetaan Vaatimusmäärittelyt Toimittajan valinta Räätälöidään Suunnittelu Toteutus Testaus Käyttöönotto Ylläpito Poisto 8.9.2014 JOTU/K.Systä 10
http://yle.fi/uutiset/montako_tietojarjestelmaa_tyopai kallasi_on trafissa_niita_on_170/7252898 Työterveyslaitoksen ja Aalto-yliopiston kyselyn mukaan joka kymmenes tehty työtunti tuhraantuu huonoon tietotekniikkaan. Tietojärjestelmiä voi tehdä myös hyvin. Suunnittelu maksaa, jonka vuoksi pienet organisaatiot joutuvat usein turhautumaan huonompien ja halvempien ratkaisujen kanssa. Se vie työaikaa ja turhauttaa. Ei vika ole missään tilanteissa käyttäjissä, sanoo tietojärjestelmien käytettävyyteen erikoistunut Aaltoyliopiston professori Marko Nieminen. miksi työpaikoilla käytettävät järjestelmät tehdään edelleen niin monimutkaisiksi, kun nykyään kuluttajatietotekniikan tietokoneiden, tablettien, älypuhelimien tai vaikkapa autojen tietojärjestelmät ovat niin paljon vaivattomampia. 8.9.2014 JOTU/K.Systä 11
Ohjelmiston rakentaminen projektina Asiakas - toimittaja Tarvitaan yhteisymmärrys siitä mitä halutaan Mitä se maksaa Koska se on valmis Asiakas ymmärrettävä laajasti Sisäinen Varsinaisen asiakkaan edustaja (esim. markkinointi) Tämä kurssi on suunniteltu (myös) tuleville asiakkaille Asiakkaalle projekti on usein osa isompaa kokonaisuutta (hanketta) Ohjelmiston lisäksi laite, liiketoimintamuutos, Elinkaari: esiselvitys, määrittely, toteutus, käyttöönotto, ylläpito, käytöstä poisto 12 8.9.2014 JOTU/K.Systä
Syitä erään suuren projektin epäonnistumiseen 1/2 Järjestelmän ominaisuuksia ja kokoa ei pystytty mitenkään arvioimaan suunnitteluvaiheessa Järjestelmästä tuli huomattavasti suurempi kuin oli alunperin suunniteltu Järjestelmään tehtiin projektin aikana jatkuvasti muutoksia: uusia piirteitä lisättiin ja vanhoja muutettiin Koordinointi osaprojektien välillä oli lähes olematonta Projektin loppupuolella vallitsi tavaton kiire. 23.9.2013 JOTU2013/K.Systä 13
Syitä erään suuren projektin epäonnistumiseen 2/2 Projektin loppupuolella projektipäällikkö sairastui ja hänen tilalleen tuli verraten kokematon henkilö Järjestelmässä oli useita piirteitä, joita ei oltu kokeiltu aikaisemmissa vastaavissa tuotteissa Järjestelmätestauksessa todettiin, että järjestelmä on liian epästabiili käyttöönotettavaksi. Projekti oli kuitenkin jo myöhässä ja paine asiakkaan taholta oli kova, joten järjestelmä otettiin tästä huolimatta käyttöön Jälkikäteen pystyttiin arvioimaan, että järjestelmän rakenne oli sellainen, ettei se olisi mitenkään voinut toimia:... paarlastia olisi tarvittu niin paljon, että alemmat tykkiportit olisivat joutuneet veden alle. Lähde; Curt Borgenstam: Why the Wasa Capsized. 23.9.2013 JOTU2013/K.Systä 14
23.9.2013 JOTU2013/K.Systä 15
Erilaisia projekteja - tuote Toimittaja määrittely toteutus testaus paketointi tutkimus myynti Asiakas 16 8.9.2014 JOTU/K.Systä
Erilaisia projekteja asiakaskohtainen Toimittaja tutkimus toteutus testaus tarjous määrittely käyttöönotto määrittely käyttöönotto tarjouspyyntö Asiakas 17 8.9.2014 JOTU/K.Systä
Erilaisia projekteja asiakaskohtainen Toimittaja Toimittaja tutkimus toteutus testaus Määrittely tarjous tarjous käyttöönotto käyttöönotto Määritrelyn tilaus Asiakas Tarjouspyyntö tilaus 18 8.9.2014 JOTU/K.Systä
Erilaisia projekteja - tuote Toimittaja määrittely toteutus testaus paketointi tutkimus myynti Asiakas 19 8.9.2014 JOTU/K.Systä
Vesiputousmalli Määrittely Suunnittelu Toteutus Testaus 8.9.2014 JOTU/K.Systä 20
Royce, 1970 8.9.2014 JOTU/K.Systä 21
Miksi vesiputous ei aina toimi Oletus 1: kunnon vaatimukset saa tehtyä kun niihin vaan panostaa Mutta: asiakkaan tarpeet muuttuu projektin aikanakin Mutta: ohjelmisto on abstrakti kunnes sen näkee käytännössä Oletus 2: muutokset ovat pieniä Mutta: eivät ole (ja kohdistuvat juuri sinne minne ei pitänyt) Oletus 3: integrointi on vain palasten kokoon laittamista Mutta: komponenttien tekijät olivat vain ihmisiä Oletus 4: aikataulu pitää Oikeasti hyvin harvoin 8.9.2014 JOTU/K.Systä 22
Iteratiiviset, ketterät yms Toimittaja tutkimus tot tot tot tot tarjous määr. test demo test demo test demo test käyt.otto määr. demo demo demo käyt.otto tarjouspyyntö Asiakas tarjous Demo tarkoittaa yhdessä käyttäjän kanssa tehtävää uudelleen pohdintaa. 23 8.9.2014 JOTU/K.Systä
Ketterät prosessit ja menetelmät http://www.agilealliance.com/home Vain oleellinen on tärkeää Asiakas- ja tuotekeskeisyys Kehittäminen tapahtuu asiakkaan kanssa yhteistyössä Valmius jatkuvaan muutokseen Iteratiivisuus Dokumentaation sijaan korostetaan henkilökohtaista kommunikaatiota kykyä demonstroida valmiita ominaisuuksia kykyä muuttaa toteutettua järjestelmää palautteen perusteella Osaamisen, ammattitaidon ja vastuuntunnon korostaminen Esimerkiksi extreme Programming (XP) test driven development (TDD) pariohjelmointi Scrum 24 8.9.2014 JOTU/K.Systä
Asiakasomistajuus Tuo bonusta! Lainaan Heimo Laukkasen (Affecto) esitystä: hyvä asiakas Pystyy luomaan ja tarjoamaan ympäristön, jossa onnistuminen on mahdollista ja epäonnistumisista opitaan Ohjaa toimintaa selkeästi ja tavoitteellisesti, sekä oikeilla mekanismeilla Kuuntelee ja käyttää toimittajien osaamista hyödykseen On onnistumassa ja oppimassa yhdessä Hyvä asiakas on haastava rooli Tällä kurssilla tullaan asiakkaan roolia katsomaan monesta eri näkökulmasta 25 8.9.2014 JOTU/K.Systä
Kehitysprosessit: erilaisia variaatioita samasta teemasta Testaus, laadunvarmistus Asiakkaan ongelma asiakasvaatimukset Määrittely ohjelmistovaatimukset, määrittely Suunnittelu tekniset vaatimukset, suunnittelu Toteutus asiakastoimitus Seuraava versio Hyväksymistestaus JOTU/K.Systä 8.9.2014 26
Tarve/idea Esiselvitys unohdetaan Tehdään itse Teetetään Ostetaan Määritellään itse Tilataan määrittely Räätälöidään Tarjouskilpailu Määrittely Päätös Tarjouskilpailu Suunnittelu Toteutus Testaus 8.9.2014 JOTU/K.Systä 27
Kehitysprosessit: erilaisia variaatioita samasta teemasta Testaus, laadunvarmistus Asiakkaan ongelma asiakasvaatimukset Määrittely Suunnittelu ohjelmistovaatimukset, määrittely tekniset vaatimukset, suunnittelu Toteutus asiakastoimitus Seuraava versio Hyväksymistestaus JOTU/K.Systä 8.9.2014 28
Vaatimusten tyyppejä Toiminnallinen vaatimus (functional requirement), esimerkiksi ohjelmassa on tuki oikeinkirjoituksen tarkastamiselle. Ei-toiminnallinen vaatimus (non-functional requirement), esimerkiksi ohjelman käyttöliittymä on dokumentin WS-100, UI-tyyliopas mukainen. Reunaehdot (constraints), esimerkiksi ohjelmisto on toteutettava Windows-ympäristöön C++-kielellä. 8.9.2014 JOTU/K.Systä 29
Määrittely (Seuraava luento on kokonaan tästä aiheesta) Fred Brooks on yksi alamme tunnetuimpia asiantuntijoita. Hän julkaisi vuonna 1987 paljon huomiota saaneen artikkelinsa No Silver Bullet:Essence and Accidents of Software Engineering [Brooks 1987]. Siinä hän toteaa: The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult in establishing the detailed technical requirements, including the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the results if done wrong. No other part is more difficult to rectify later. Monet tutkimukset (ks. esim [Leffingwell ja Widrig 2003]) osoittavat, että ohjelmistoprojektien epäonnistumisen syyt juontavat juurensa yli 60-prosenttisesti huonoon vaatimustenkäsittelyyn. 8.9.2014 JOTU/K.Systä 30
Kaksi erilaista johtopäätöstä 1. Kannattaa käyttää alussa paljon aikaa vaatimusten miettimiseen ja kirjaamiseen ennen kuin kirjoittaa yhtäkään koodiriviä. 2. Vaatimukset tai ainakin ymmärrys niistä muuttuu projektin aikana kuitenkin. Joten parasta iteroida palanen kerrallaan. 8.9.2014 JOTU/K.Systä 31
Kehitysprosessit: erilaisia variaatioita samasta teemasta Testaus, laadunvarmistus Asiakkaan ongelma asiakasvaatimukset Määrittely Suunnittelu ohjelmistovaatimukset, määrittely tekniset vaatimukset, suunnittelu Toteutus asiakastoimitus Seuraava versio Hyväksymistestaus JOTU/K.Systä 8.9.2014 32
Suunnittelu (Architecture design) Ohjelmiston tekniset ominaisuudet Ohjelmiston jako osiin Osien riippuvuuksien määrittely Osien rajapintojen määrittely Wikipedia: The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. The term also refers to documentation of a system's "software architecture." Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects 8.9.2014 JOTU/K.Systä 33
Ohjelmistoarkkitehtuureja opetetaan erillisellä kurssilla OHJ-3200 Ohjelmistoarkkitehtuurit, periodit 3-4 2011-2012 Tavoitteet: Kurssin tavoitteena on antaa opiskelijoille yleiskuva ohjelmistoarkkitehtuureihin liittyvistä käsitteistä ja tekniikoista sekä valmiudet laadukkaiden ohjelmistojen rakentamiseen ja arviointiin. 8.9.2014 JOTU/K.Systä 34
Kehitysprosessit: erilaisia variaatioita samasta teemasta Testaus, laadunvarmistus Asiakkaan ongelma asiakasvaatimukset Määrittely ohjelmistovaatimukset, määrittely Suunnittelu tekniset vaatimukset, suunnittelu Toteutus asiakastoimitus Seuraava versio Hyväksymistestaus JOTU/K.Systä 8.9.2014 35
Työn kulku tuotekehitysprojektissa (esimerkki) kehitystiimi 1) muutettavat kompone ntit Versionhallinta Työn tasks Change alla tasks tasks olevat komponentit 2) muutetut komponentit testing OK uusi "baseline" 3) palaute Koostaminen (build) & automaattiset testit "Sopiva kooste" "release candidate" Järjestelmätestaus testing OK julkaisu (release) build manager" testaajat 36 27.4.2009 JOTU/K.Systä 36
Mitä on ohjelmistotuotanto? Vaatimusmäärittelyä Asiakas Taitavaa ohjelmointia Elinkaarimallit Yhteispeliä, yhteistä peliä Algoritmit Tietorakenteet Ohjelmointikielet Arkkitehtuurit Laadunvarmistusta Projektinhallinta Kehittäjä Testaus Validointi 8.9.2014 JOTU/K.Systä
Kehitysprosessit: erilaisia variaatioita samasta teemasta Testaus, laadunvarmistus Asiakkaan ongelma asiakasvaatimukset Määrittely ohjelmistovaatimukset, määrittely Suunnittelu tekniset vaatimukset, suunnittelu Toteutus asiakastoimitus Seuraava versio Hyväksymistestaus JOTU/K.Systä 8.9.2014 38
Testaus Testaus on virheiden etsimistä Virhe (error, mistake, bug) on poikkeama spesifikaatiosta. Johdonmukainen testaus ilman spesifikaatiota on siis mahdotonta, sillä lopputuloksen oikeellisuutta ei voida todeta. Debuggaus on puolestaan löydetyn virheen paikallistamista. Ohjelmissa arvioidaan yleensä olevan ohjelmoinnin jälkeen yksi virhe muutamaa kymmentä ohjelmariviä kohden. Jopa pitkään käytössä olleissa ohjelmissa arvioidaan yleensä olevan noin yksi virhe tuhatta ohjelmariviä kohden. On myös arvioitu, että noin 5 % ohjelmavirheistä on sellaisia, ettei niitä "koskaan" edes havaita, sillä vaikka virheellinen kohta suoritettaisiinkin 8.9.2014 JOTU/K.Systä 39
V-malli Määrittely Järjestelmätestaus Arkkitehtuurisuunnittelu Yksityiskohtainen suunnittelu Yksikkötestaus Integrointitestaus 8.9.2014 JOTU/K.Systä 40
Joitain testauksen termejä Testisuunnitelma: koska testataan, kuka testaa, mitä testataan; testitapaukset. Testipeti: ohjelmistorunko jonka avulla testejä on helppo suorittaa Testiautomaatio: testitapausten automaattinen suoritus ja tulosten vertailu Regressiotestaus: testataan vanhatkin ominaisuudet uudelleen uusien lisäämisen jälkeen. Kuormitustesti: kaatuuko systeemi kuorman alla. Luotettavuustesti: miten toipuu häiriötilanteista. Käytettävyystesti: miten loppukäyttäjä näkee järjestelmän. 8.9.2014 JOTU/K.Systä 41
Kehitysprosessit: erilaisia variaatioita samasta teemasta Testaus, laadunvarmistus Asiakkaan ongelma asiakasvaatimukset Määrittely Suunnittelu ohjelmistovaatimukset, määrittely tekniset vaatimukset, suunnittelu Toteutus asiakastoimitus Seuraava versio Hyväksymistestaus JOTU/K.Systä 8.9.2014 42
Hyväksymistestaus Saatiinko sitä mitä tilattiin? Asiakkaan rooli on suuri. 8.9.2014 JOTU/K.Systä 43
Miksi ketterä (agile)? Jatkuva näkyvyys (ei korjaa ongelmia, mutta tuo ne näkyväksi) Mahdollisuus muutoksiin Aiempi bisnesarvo Matalammat riskit 8.9.2014 JOTU/K.Systä 44
Agile -manifesti Helmikuu 2001 17 tekijää We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 8.9.2014 JOTU/K.Systä 45
Manifesti Suomeksi 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. 8.9.2014 JOTU/K.Systä 46
Scrum Ketterän ja iteratiivisen kehityksen prosessikehys Jeff Sutherland, John Scumniotales, and Jeff McKenna OOPSLA 95 8.9.2014 JOTU/K.Systä 47
Scrum-roolit Siat Scrum master Product owner Tiimin jäsenet Kanat Sidosryhmät (asiakas, myyjä ) Johtajat 8.9.2014 JOTU/K.Systä 48
Done -> 100% tehty Burndown -kaavio Velocity -> paljonko tehtävää voidaan yhteen sprinttiin saada mahtumaan Kaaviosta vähennetään tehtävän tunnit, jos tehtävä 100% valmis Jos tehtävä kasvaa, lisätään kaavioon tunteja 8.9.2014 JOTU/K.Systä 49
Timeboxing Projektin osittainen kiinteän mittainen aikasiivu, jolla on omat deadlinensä, vaihetuotteensa ja resurssinsa TB1 TB2 TB3 Riskinhallintametodi Nopea palaute Jäykistää vaatimustenhallintaa 8.9.2014 JOTU/K.Systä 50
Kompromissikolmio Aika Resurssit Ominaisuudet 8.9.2014 JOTU/K.Systä 51
Oppimistavoiteet Jonkinlainen käsitys siitä mitä ohjelmistotuotantoprosessi on? Mitä ja miksi on ketteryys? Miksi asiakasta kiinnostaa millainen prosessi on käytössä? 8.9.2014 JOTU/K.Systä 52