Harjoitukset - muistutus Muistakaa ilmoittautua IDLE:ssä! Ryhmät Ma 16.00-18.00 TB207, Hannu Ranta Ti 10.00-12.00 TB207, Marie-Elise Kontro Ti 12.00-14.00 TB207, Marie-Elise Kontro Ke 08.00-10.00 TB207, Mikko Andersson Ke 10.00-12.00 TB207, Mikko Andersson Ke 12.00-14.00 TB207, Hannu Ranta Ke 14.00-16.00 TB207, Lauri Virtanen To 12.00-14.00 TB207, Hannu Ranta To 14.00-16.00 TB207, Lauri Virtanen 27.8.2012 1
Alustava luentoaikataulu Vko 35: johdanto 36: mitä on ohjelmistotuotanto (kirjan luku 1) 37: vaatimusten kirjaamisesta (luku 3) 38: vaatimuksista jatkuu: ohjelmistotyön vaiheet ja tehtävät (luku 2 alku) 40: ohjelmistotyön vaiheet ja tehtävät (luku 2 alku) jatkuu 41: UML-kaaviot (luku 4 etc) 42: Asiakkaan ja sidosryhmän rooleista 44: käytettävyyden ja käyttökokemuksen perusteet 45: Prosessi/elinkaarimalleista (luvun 2 loppu) 46: Tiedon mallintaminen 47: Laadunvarmistus, testaus, (11,15,16) 48: Projektitoiminnan perusteet. Työmäärät, kustannukset (12) 49: IPR, sopimukset, open source 50: Kertausta 2
http://www.softwareindustrysurvey.fi/slidesfinland2012.pdf 3
Nokian uuden strategian vaikutukset 4
Edelleen samasta lähteestä 5
Tähän taas yksi onneton Hakukoneeseen - Sampo - Danske - Verkkopankki - 2008 27.8.2012 6
Analyysiä Suurin osa tiedosta lienee luottamuksellista, mutta Sampo Pankin uudesta järjestelmästä on kerrottu, että se on yksi, yhtenäinen kokonaisuus. Tämän vuoksi järjestelmää ei voitu ottaa käyttöön esimerkiksi yksi toiminto kerrallaan, vaan se oli otettava käyttöön kertarysäyksellä ja hyväksyttävä toimeen liittyvät riskit. Integraatioita tutkinut Maria Alaranta kirjoitti: Yhteenvetona voidaan sanoa, että suurin osa fuusion jälkeisen it-integraation ongelmista johtuu huonosta johtamisesta, vaikkei teknisiä ongelmiakaan pidä aliarvioida. Yleinen arvio on, että hankkeesta päättäneet eivät tienneet millaiseen savottaan olivat lähdössä
Motto (kautta vuosien) Ketteryys?????? 8
Ohjelmistotuotanto on vielä paljolti "kansanperinnettä". 9
Toivotonta? Ei sentään! Terve skeptismi muotivirtauksiin mutta avoimuus uusille asioille Valitse käyttäen tervettä järkeä: Mitä Milloin Miten Tavoitteemme pitää olla kunnianhimoinen: me teemme ja tilaamme parempaa ohjelmistoa 10
Siispä kurssi jatkuu Ja yritämme omalta osaltamme ratkaista kriisiä 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
Muita haasteita Tuote vs asiakaskohtainen Sopivuus asiakkaan tarpeisiin Kehittämisen ja ylläpidon kustannukset Dilemma. Kummalla rikastut: teet kerran ja myyt miljoona kopiota vai tekemällä monta projektia? Eri toimintatavat Hajautettu kehitys Resurssit ja asiantuntemus voi olla hajallaan Kustannusten vuoksi halutaan siirtää työtä halvan kustannuksen maihin. Monessa yrityksessä edustus asiakkaan luona, loput esim. Intiassa 13
Erilaisia projekteja - tuote Toimittaja määrittely toteutus testaus paketointi tutkimus myynti Asiakas 14
Erilaisia projekteja asiakaskohtainen Toimittaja tutkimus toteutus testaus tarjous määrittely käyttöönotto tarjouspyyntö tarjous määrittely käyttöönotto Asiakas 15
Tämä kulunut kuva on pakko näyttää 16
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. 17
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 18
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 19
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 20
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ä. 27.8.2012 21
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. 27.8.2012 22
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. 27.8.2012 23
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 24
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 27.8.2012 25
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. 27.8.2012 26
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 27
Työn kulku tuotekehitysprojektissa (esimerkki) kehitystiimi 1) muutettavat komponen tit 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 28 27.4.2009
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 29
Testaus Testaus on virheiden estämistä 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 27.8.2012 30
V-malli Määrittely Järjestelmätestaus Arkkitehtuurisuunnittelu Yksityiskohtainen suunnittelu Yksikkötestaus Integrointitestaus 27.8.2012 31
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. 27.8.2012 32
Testauksen voi järjestää monella tavalla Esimerkkinä test-driven development Lähde: wikipedia 27.8.2012 33
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 34
Hyväksymistestaus Saatiinko sitä mitä tilattiin? Asiakkaan rooli on suuri. 27.8.2012 35
Asiakas- ja toimittajaroolit testauksessa (Maaret Pyhäjärvi 6.6.2012) Toimittajaorganisaatio haluaisi mielellään hyväksynnän (=lasku maksuun) heti OMAN työnsä päätteeksi Asiakasorganisaatio haluaisi testata että osat toimivat hyväksyttävästi osana kokonaisuutta ennen hyväksymistä. Toimittajaorganisaatio haluaisi mielellään vain OMAN palasensa virheitä todistetusti Asiakasorganisaation tekniset osaamiset eivät välttämättä riitä virheen kohdistamiseen teknisesti oikealle palaselle ja jäädään pallottelemaan tai laskutetaan erikseen hyväksymistestauksen tuesta 27.8.2012 36
Asiakas- ja toimittajaroolit testauksessa (Maaret Pyhäjärvi 6.6.2012) Toimittajaorganisaatiossa leikataan helposti testauksesta jota ei selkeästi ole vaadittu testaamaton ei ole toimimaton! ja testaus on aina otos. Kokoava järjestelmätestaus ei kuulu kenellekään. Asiakasorganisaatiossa ei ymmärretä / hyväksytä että testaus on myös vaatimuksista oppimista asiakkaan liiketoiminnan tietotaito kriittistä oikea-aikaisten havaintojen tekemiseen Toimittajan intresseissä ei aina ole TESTATA, mutta kyllä KORJATA. Testaus voi maksaa korjaamista enemmän. Tulevaisuuden korjaaminen = liiketoiminnan jatkuvuuden perusta. 27.8.2012 37