Harjoitukset - muistutus

Transkriptio

1 Harjoitukset - muistutus Muistakaa ilmoittautua IDLE:ssä! Ryhmät Ma TB207, Hannu Ranta Ti TB207, Marie-Elise Kontro Ti TB207, Marie-Elise Kontro Ke TB207, Mikko Andersson Ke TB207, Mikko Andersson Ke TB207, Hannu Ranta Ke TB207, Lauri Virtanen To TB207, Hannu Ranta To TB207, Lauri Virtanen

2 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

3 3

4 Nokian uuden strategian vaikutukset 4

5 Edelleen samasta lähteestä 5

6 Tähän taas yksi onneton Hakukoneeseen - Sampo - Danske - Verkkopankki

7 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ä

8 Motto (kautta vuosien) Ketteryys?????? 8

9 Ohjelmistotuotanto on vielä paljolti "kansanperinnettä". 9

10 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

11 Siispä kurssi jatkuu Ja yritämme omalta osaltamme ratkaista kriisiä 11

12 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

13 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

14 Erilaisia projekteja - tuote Toimittaja määrittely toteutus testaus paketointi tutkimus myynti Asiakas 14

15 Erilaisia projekteja asiakaskohtainen Toimittaja tutkimus toteutus testaus tarjous määrittely käyttöönotto tarjouspyyntö tarjous määrittely käyttöönotto Asiakas 15

16 Tämä kulunut kuva on pakko näyttää 16

17 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

18 Ketterät prosessit ja menetelmät 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

19 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

20 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

21 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ä

22 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

23 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

24 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

25 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

26 Ohjelmistoarkkitehtuureja opetetaan erillisellä kurssilla OHJ-3200 Ohjelmistoarkkitehtuurit, periodit Tavoitteet: Kurssin tavoitteena on antaa opiskelijoille yleiskuva ohjelmistoarkkitehtuureihin liittyvistä käsitteistä ja tekniikoista sekä valmiudet laadukkaiden ohjelmistojen rakentamiseen ja arviointiin

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 27

28 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

29 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

30 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

31 V-malli Määrittely Järjestelmätestaus Arkkitehtuurisuunnittelu Yksityiskohtainen suunnittelu Yksikkötestaus Integrointitestaus

32 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

33 Testauksen voi järjestää monella tavalla Esimerkkinä test-driven development Lähde: wikipedia

34 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

35 Hyväksymistestaus Saatiinko sitä mitä tilattiin? Asiakkaan rooli on suuri

36 Asiakas- ja toimittajaroolit testauksessa (Maaret Pyhäjärvi ) 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

37 Asiakas- ja toimittajaroolit testauksessa (Maaret Pyhäjärvi ) 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