Projektin vaiheet

Transkriptio

1 Projektin vaiheet

2 Prosessi, teknologia ja ihmiset Prosessi Teknologia Teknologia Prosessi Prosessi Teknologia Ihmiset Ihmiset Ihmiset

3 Hanke vs. projekti vs. prosessi Usein softaa tehdään projekteina Projektit viedään usein läpi prosesseina On olemassa myös muita projekteja kuin kehitysprojekteja Jos projektit kuuluvat samaan kokonaisuuteen, kutsutaan niitä hankkeeksi

4 Projekti Projektiin liittyy lähtötilanne, syy käynnistämiselle ja tavoitetila Yksi määritelmä: Projekti on kertaluontoinen, toisiinsa liittyvien tehtävien ja aktiviteettien muodostama kokonaisuus, jolla on suunnitelmallinen toteutus (=tavoitteet, aikataulu, resurssit, kustannukset). Projektiin liittyy organisaatio, joka yleensä poikeaa linjaorganisaatiosta johto osallistujat sidosryhmät... Ovatko projekteja? Ohjelmistotuotannon perusteet-kurssi syys 2012 DI-tutkinnon suorittaminen Komponenttivaraston kiertonopeuden kasvattaminen

5 Projektityyppejä Esitutkimusprojekti, määrittelyprojekti toteutusprojekti Jako aliprojekteiksi Suurissa projekteissa jako aliprojekteihin (yksi nyrkkisääntö: jos projekti on yli viisi henkilötyövuotta ja kestää yli vuoden, hankaluuksia on varmasti odotettavissa). Muita projektityyppejä käyttöönottoprojekti koulutusprojekti hankintaprojekti laatujärjestelmän kehitysprojekti. ohjelmistoprojektiin voi liittyä myös laitteistoprojekti. Asiakas- vs. tuotekehitysprojekti: Verrattuna asiakaskohtaisen ohjelmiston tuottamiseen, ohjelmiston tuotteistaminen on moninkertainen urakka. Massatuotteessa vikojen seuraukset voivat olla erittäin kalliita.

6 Keskeisiä projektin suureita Projektin tuotos Laajuus (scope) Lopputuloksen laatu Kalenteriaika Ihmiset ("resurssit") Mitä tapahtuu, kun yhtä joudutaan muuttamaan (trade-offs)?

7 Prosessit, metodit, työkalut, taidot... More formal, more controlled, more bureaucratic Configuration management Project management Methods Documentation Requirements specification SW design Programming language, tools, and technical skills Requirements management Measurement Testing procedures, planning Quality control, inspections Small programs Large systems Sometimes, for some people, it seems to be more important to get the process done than to get the product done

8 Ohjelmistoprosessi: Historia (teoriassa)

9 Prosessi: Historia (todellisuudessa) Rakenteiset menetelmät Olio-ohjelmointi Prosessi: Iteratiivinen kehitys CMM, Spice, ISO9001 Ketterät menetelmät Koodaa ja korjaa Näkyvimmät trendit : ketteryys (agility) Scrum työkalut Global SW Development (GSD) Lean Outsourcing 9

10 Ohjelmistokehitysprosessi: erilaisia variaatioita samasta teemasta Asiakkaan ongelma Määrittely asiakasvaatimukset Testaus, laadunvarmistus, vaatimustenhallinta, tuotteenhallinta... Suunnittelu ohjelmistovaatimukset, määrittely tekniset vaatimukset, suunnittelu Toteutus, integrointi Seuraava versio asiakastoimitus Hyväksymistestaus

11 Prosessi: Todellisuus määritely suunnittelu toteutus testaus suunniteltu todellisuus 11 aika

12 Tärkeimmät dokumentit Asiakkaan ongelma Testaussuunnitelma(t) Projektisuunnitelma Testaus, laadunvarmistus, vaatimustenhallinta, tuotteenhallinta... Määrittely Suunnittelu Toteutus asiakasvaatimukset ohjelmistovaatimukset tekniset vaatimukset, asiakastoimitus Toiminnallinen määrittely Tekninen määrittely Hyväksymistestaus

13 Prosessin iteratiivisuus Suunnittelu Ohjelmointi Alustava vaatimusmäärittely Arkkitehtuurisuunnittelu Vaatimusten täsmennys Verifiointi Toimitus Uudelleensuunnittelu Validointi Tuote 1.3 SW Kuva Juha-Markus Aallon esitelmästä oliopäivillä

14 Työmäärät vaiheittain (RUP) Inception Elaboration Construction Transition Requirements Analysis Design Implementation Test iter. 1 iter

15 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

16 Esimerkki: SCRUM 1 Iteratiivinen Prosessikehys, joka keskittyy projektin ohjaukseen ja seurantaan tuloslähtöisesti. Voidaan käyttää muiden menetelmien yhteydessä. Roolit Tuotteen omistaja (Product Owner) Omistaa projektin tavoitteet ( projektin onnistumisen määrittelyn ) Vastaa taloudellisesta tuloksesta (ROI), priorisoi vaatimukset, aikatauluttaa julkaisut Scrum-mestari (Scrum Master, projektipäällikkö ) Omistaa Scrum-prosessin Toimii tiimin ja tuotteen omistajan valmentajana Tiimi Omistaa tuotantoprosessin (!) Kevät 2009: Scrumista on tullut yleisimmin käytetty menetelmä ohjelmistoprojektien hallinnassa?

17 SCRUM: aktiviteetit ja vaihetuotteet Sprintissä toteutettavat tehtävät, aika-arviot päivitetään päivittäin Daily Scrum Meeting: 15 min: Edistys edellisestä palaverista? Ovatko aika-arviosi kunnossa? Mitä teet seuraavaksi? Onko ongelmia näkyvissä? Sprint burndown chart: työmäärä aika Sprint planning meeting: 4+4 tuntia: omistaja esittelee Product backlogia Tiimi päättää, mihin voi sitoutua 30 päivän pyrähdys (sprint) tuotteen inkrementti Sprint Review Meeting (4 tuntia): Tiimi esittelee tuloksen omistajalle The Sprint Retrospective (3 tuntia): miten asiat saataisiin sujumaan paremmin seuraavassa pyrähdyksessä Requirements

18 Tuotantoprosessi Scrum ei määrittele tuotantoprosessia Voidaan soveltaa esimerkiksi XP:n ideoita Case X: Pariohjelmointi Jatkuva integrointi (Cruise Control) Tuotteen/versionhallinta Testauksen automatisointi Yksikkötestaustasolla (JUnit) Järjestelmätestaustasolla (FIT)

19 Havaintoja Samat ongelmat toistuvat vuodesta toiseen. Täytyy saada tarpeeksi monta kertaa turpaan ennen kuin oppii (kaikki eivät silti opi). Ongelmat eivät useimmiten ole teknisiä, vaan liittyvät: asiakasvaatimusten ymmärtämiseen ja hallintaan kommunikointiin ihmisjohtamiseen projektinhallintaan... Onnistuminen on mahdollista. Samat ideat nousevat usein uudelleen pintaan eri nimisinä (ja erilaisilla painotuksilla). Yksilöiden (ja tiimien) tuottavuus vaihtelee tavattomasti. Hopealuoteja ei ole. Loppujen lopuksi tärkeintä on terve talonpoikaisjärki ja riittävä systemaattisuus (eikä esimerkiksi uudet menetelmät ja työkalut)

20 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

21 Kehitysprosessit: erilaisia variaatioita samasta teemasta Asiakkaan ongelma asiakasvaatimukset Testaus, laadunvarmistus Määrittely Suunnittelu ohjelmistovaatimukset, määrittely tekniset vaatimukset, suunnittelu Toteutus Seuraava versio asiakastoimitus Hyväksymistestaus

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

23 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

24 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

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

29 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

31 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

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

33 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

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

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

37 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

38 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