1. Johdanto. Ohjelmistotuotannon piirteitä
|
|
- Vilho Hovinen
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 1. Johdanto Termi Ohjelmistotuotanto (Software Engineering) esiteltiin ensimmäistä kertaa 1968 pidetyssä NATO:n konferenssissa. Termi määriteltiin näin: The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. (P. Naur, R.Randell (eds.): Software Engineering: A Report on a Conference Sponsored by the NATO Science Committee, 1968) Juha Taina, Ohjelmistotuotanto 1 Ohjelmistotuotannon piirteitä Määritelmä oli aikaansa edellä, sillä se pätee erittäin hyvin edelleen. Ohjelmistotuotanto on kurinalaista insinöörityötä, pyrkii tarjoamaan keinot valmistaa laadukkaita ja tehokkaita ohjelmistoja mahdollisimman edullisesti ja tarjoaa tehtäväjaon ja työkalut kaikkiin ohjelmistojen valmistuksen työvaiheisiin. Juha Taina, Ohjelmistotuotanto 2 1
2 Ohjelmisto ja järjestelmä Ohjelmisto (software) on kokoelma yhteistyössä toimivia tietokoneohjelmia, ohjelmien käyttämiä tiedostoja ja niihin liittyviä dokumentteja. (Tietokonepohjainen) järjestelmä (computer-based system) on joukko toisiinsa liittyviä komponentteja. laitteisto- ja ohjelmistokomponentteja, käyttäjiä ja käyttöympäristöjä. Juha Taina, Ohjelmistotuotanto 3 Osajärjestelmät ja käyttäjät Yleensä järjestelmä koostuu useasta osajärjestelmästä. Kukin osajärjestelmä on itsenäinen kokonaisuus, joka toimii yhteistyössä muiden osajärjestelmien kanssa. Osajärjestelmä rakentuu laitteisto- ja ohjelmistokomponenteista, jotka toteuttavat yhteistyössä osajärjestelmän tehtävät. Käyttäjät käyttävät järjestelmää yhden tai useamman osajärjestelmän kautta. Juha Taina, Ohjelmistotuotanto 4 2
3 Järjestelmän ja ohjelmiston laadinta Järjestelmää ja ohjelmistoa on laadittava yhteistyössä: Ohjelmistotuotantoa ei voi tehdä ilman tietoa ympäristöstä, johon ohjelmistoa ollaan tekemässä. Yhteistyö edellyttää ohjelmiston laatijoilta valmiutta kommunikoida sovellusalueen asiantuntijoiden kanssa. Ohjelmistoa on helppo syyttää, jos jokin menee pieleen, vaikka syy olisi muualla. Juha Taina, Ohjelmistotuotanto 5 Mitä vaaditaan hyvältä ohjelmistolta? Hyvällä ohjelmistolla on seuraavat keskeiset ominaisuudet: Ylläpidettävyys: tuotetta voidaan muokata vastaamaan muuttuviin vaatimuksiin. Luotettavuus: tuote ei aiheuta fyysisiä eikä taloudellisia vahinkoja missään tilanteessa. Tehokkuus: tuote ei tuhlaa resursseja. Käytettävyys: tuote on looginen ja helppokäyttöinen. Juha Taina, Ohjelmistotuotanto 6 3
4 2. Ohjelmistotuotannon historiaa Ensimmäinen kaupallinen ohjelmisto tehtiin niinkin aikaisin kuin 1951 Englannissa, tekijänä J. Lyons company. Alkuaikoina ohjelmistojen teko oli suoraviivaista ja ohjaamatonta. Silti jo 50-luvulla tehtiin kohtuullisen monipuolisia ohjelmistoja. Juha Taina, Ohjelmistotuotanto luku ja ohjelmistokriisi 1960-luvun alussa määriteltiin jo aika moderneja asioita, kuten testattavuus ja rajapinnat. Silti ei vielä voitu puhua varsinaisesta ohjelmistotuotannosta. Vuosikymmenen edetessä ohjelmistojen koot kasvoivat ja ongelmat pahenivat. Projektit alkoivat myöhästellä ja ylittää kustannuksensa. Syntyi ns. 60-luvun ohjelmistokriisi. Suoraviivainen koodaus ei enää riittänyt. Juha Taina, Ohjelmistotuotanto 8 4
5 Ensimmäiset ohjelmistotuotannon konferenssit Lopulta 1968 NATO organisoi jo aiemmin mainitun konferenssin, jossa esiteltiin termi Software Engineering. Seuravana vuonna NATO organisoi toisen Software Engineering konferenssin. Yhdessä näissä konferensseissa määriteltiin ohjelmistotuotannon perusteet. Juha Taina, Ohjelmistotuotanto 9 Ensimmäisten konferenssien tulos Konferenssien tulokset eivät ehkä ratkaisseet ohjelmistokriisiä. Jotkut asiantuntijat ovat sitä mieltä, että kriisi ei ole vieläkään kunnolla ratkennut. Sen sijaan konferensseissa esitellyt ideat olivat perusta, jolle nykyaikainen ohjelmistotuotanto on rakennettu. Juha Taina, Ohjelmistotuotanto 10 5
6 1970-luku ja prosessimallit 1970-luvulle tultaessa määriteltiin ensimmäinen ohjelmistotuotannon prosessimalli: vesiputousmalli. Prosessimalli on mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen. Vesiputousmallin pohjana käytettiin muiden insinööritieteiden järjestelmäsuunnittelumallia (systems engineering model). Juha Taina, Ohjelmistotuotanto 11 Lisää prosessimalleja Järjestelmäsuunnittelumallin avulla voidaan suunnitella vaikkapa siltoja. Malli kopioitiin suoraan ohjelmistotuotantoon. Varsin pian huomattiin, että vesiputousmalli ei sovi kaikenlaisten ohjelmistojen tekoon. Niinpä 70- ja 80- luvulla esiteltiin lukuisia muita ohjelmistotuotannon prosessimalleja. Juha Taina, Ohjelmistotuotanto 12 6
7 Ohjelmointikielten alkuaikoja Ensimmäiset ohjelmat kirjoitettiin konekielellä, mutta ensimmäiset lausekielet kehitettiin jo 1950-luvulla. 60-luvun alussa kehitetyt Algol, Cobol ja PL/1 olivat ensimmäiset kunnon kielet. 60-luvun lopussa kehitetty C-kieli (tietenkin B-kielestä jatkokehitetty) oli merkittävä askel suorituskykyisten ohjelmien kehitystyössä. Juha Taina, Ohjelmistotuotanto luku ja oliopohjaisuus 1980-luvun suurin uusi asia oli oliopohjaisuus. Ensimmäinen oliokonferenssi OOPSLA pidettiin Oliomaailman periaatteet oli toki esitelty aiemmin, mutta vasta ensimmäiset oliokielet kokosivat ne yhteen. Ohjelmointikielistä oliopohjaisuus levisi vähitellen koko ohjelmistotuotantoon. Juha Taina, Ohjelmistotuotanto 14 7
8 1990-luvun alku ja henkilökohtainen tietojenkäsittely 90-luvulle tultaessa ohjelmistotuotanto oli aika vakiintunutta. 80-luvulla alkanut henkilökohtainen tietojenkäsittely (jokaisella oma tietokone) mullisti ohjelmistojen tarpeen mutta ei niiden valmistuksen tekniikkaa. Ohjelmistotuotanto eli työkalujen aikaa. CASE-työkalut (Computer-Aided Software Engineering) kehittyivät. Juha Taina, Ohjelmistotuotanto ja ketterät prosessimallit Toistaiseksi viimeinen ohjelmistotekniikan murros tapahtui Tällöin esiteltiin ensimmäinen ketterä prosessimalli Extreme Programming (XP). Ketterät prosessimallit saavuttivat nopeasti erityisesti ohjelmoijien ja PKyritysten suosion, sillä mallit suosivat ohjelmointia suunnittelun sijaan. Juha Taina, Ohjelmistotuotanto 16 8
9 Nykyhetki (2007) Tällä hetkellä (2007) ohjelmistotuotantoa kuvaa parhaiten nopea kehitystyö, hajaantuminen ja erikoistuminen. Vaikka perusperiaatteet, joita opetetaan mm. tällä kurssilla, ovat säilyneet ennallaan, niin yritykset käyttävät omia räätälöityjä prosessimalleja, menetelmiä ja työkaluja. Asiakkaat odottavat tuloksia usein jo 3-4 kk projektin alkamisen jälkeen. Yrityksen käyttämien ohjelmistorajapintojen (API) hallinta on iso osa ammattitaitoa. Juha Taina, Ohjelmistotuotanto 17 Erikoistunut nykyhetki (2007) Myös tehtävät ohjelmistot eroavat toisistaan enemmän kuin koskaan. Yhtäältä meillä on kännyköihin ja mobiililaitteisiin tehtäviä pieniä ohjelmia. Toisaalta meillä on valtavia ohjelmia, joiden suorituskyky ja käyttöturvallisuus on määritelty erittäin korkealle. Näin ohjelmistoyritysten täytyy erikoistua säilyttääkseen markkinansa. Juha Taina, Ohjelmistotuotanto 18 9
10 Tulevaisuus Tulevaisuudessa ohjelmistotuotannolla on kolme haastetta: Epäyhtenäisyyden haaste (heterogeneity challenge). Toimitusajan haaste (delivery challenge). Luottamuksen haaste (trust challenge). Haasteet eivät ole riippumattomia. Osa voi olla jopa keskenään ristiriitaisia. Juha Taina, Ohjelmistotuotanto 19 Epäyhtenäisyyden haaste Ohjelmistopohjaisten järjestelmien täytyy toimia hyvin erilaisissa ympäristöissä eri järjestelmien kanssa. Ohjelmistojen pitää myös toimia vanhojen järjestelmien kanssa. Vanhoihin järjestelmiin täytyy usein kehittää uutta toiminnallisuutta. Vanhoja järjestelmiä tekohengitetään. Juha Taina, Ohjelmistotuotanto 20 10
11 Toimitusajan haaste Ohjelmistojen teko ohjelmistotuotannon menetelmin vaatii paljon aikaa. Aika taas on kallis resurssi. Liiketoiminnassa taas täytyy olla dynaaminen ja valmis muutoksiin. Näin myös ohjelmistojen teossa täytyy valmistua ja mukautua muutokseen aiempaa nopeammin ilman että laatu kärsii. Juha Taina, Ohjelmistotuotanto 21 Luottamuksen haaste Ohjelmistot vaikuttavat aina vain enemmän elämäämme. Mitä enemmän ohjelmistot hallitsevat, sitä enemmän meidän pitää voida luottaa niihin. Luottamus ei kuitenkaan synny tyhjästä. Ohjelmistoista pitää voida nähdä, että ne toimivat halutulla tavalla. Esimerkiksi autoissa on paljon autojen ohjelmistoista johtuvia pikkuvikoja. Juha Taina, Ohjelmistotuotanto 22 11
12 3. Ohjelmistotuotantoprosessi Ohjelmistotuotantoprosessi (software process) on joukko toimintoja, jotka johtavat ohjelmiston valmistumiseen. Prosessi on ohjeisto. Se kertoo työvaiheet ja niiden väliset suhteet. Prosessin ilmentymä on projekti. Siinä toteutetaan prosessin työvaiheet. Käytännössä jokainen ohjelmistoyritys käyttää itselleen räätälöityjä prosesseja. Juha Taina, Ohjelmistotuotanto 23 Prosessimalli Prosessimalli (process model) on abstrakti kuvaus prosessista. Prosessimallista voidaan johtaa monta erilaista prosessia eri organisaatioihin ja sovellusalueille. Prosessimalli kuvaa yleisperiaatteen, ei yksityiskohtia. Näin prosessimalli määrittelee kehykset, joihin itse prosessit rakennetaan. Juha Taina, Ohjelmistotuotanto 24 12
13 Prosessimallien perustehtävät Jokaiseen prosessimalliin sisältyy tavalla tai toisella seuraavat perustehtävät: Vaatimusten keruu ja analyysi (vaatimusmäärittely), Ohjelmiston suunnittelu, Toteutus ja yksikkötestaus, Integrointi ja järjestelmätestaus, Käyttö ja ylläpito. Juha Taina, Ohjelmistotuotanto 25 Vaatimusmäärittely Mitä vaatimuksia ohjelmistolle asetetaan: Mitä toimintoja sen pitää sisältää. Mitä laadullisia vaatimuksia ohjelmistolle asetetaan (vaikkapa nopeuden tai käyttötavan suhteen). Mitä rajoituksia ohjelmiston toimintaan liittyy (kuten muiden ohjelmistojen yhteistoiminnan synnyttämät ehdot). Juha Taina, Ohjelmistotuotanto 26 13
14 Vaatimusmäärittelyprosessi Feasibility study Feasibility repor t Requir ements elicitation and anal ysis System models Requir ements specification User and system requirements Requir ements validation Kuvalla (C) I. Sommerville 2004 Requir ements document Juha Taina, Ohjelmistotuotanto 27 Ohjelmiston suunnittelu Suunnittelu kuvaa ohjelmiston rakenteen, ohjelmiston tarvitsemat ja käsittelemät tiedot, komponenttien väliset rajapinnat ja käytetyt algoritmit. Suunnittelu perustuu kerättyihin vaatimuksiin. Sen tuloksena saadaan yksi tai useampi ohjelmiston toteutuksessa käytettävä malli ohjelmiston rakenteesta. Juha Taina, Ohjelmistotuotanto 28 14
15 Suunnittelun tasot Suunnitteluprosessi vaatii useita työvaiheita, jotka käsittelevät ongelmaa eri tarkkuustasoilla. Tasot voivat olla seuraavat (tai jotain muuta; suunnittelua ei kannata yhtenäistää liikaa): Arkkitehtuurisuunnittelu Tehdään järjestelmästä korkean tason malli, josta selviävät osajärjestelmät ja niissä käytettävät komponentit. Juha Taina, Ohjelmistotuotanto 29 Suunnittelun tasot 2 Abstrakti määrittely Määritellään kunkin osajärjestelmän tarjoamat palvelut ja rajoitteet. Rajapintasuunnittelu Määritellään kunkin osajärjestelmän tarjoamat rajapinnat muille osajärjestelmille. Komponenttisuunnittelu Määritellään osajärjestelmittäin palvelut toteuttavat komponentit rajapintoineen ja suunnitellaan ne. Juha Taina, Ohjelmistotuotanto 30 15
16 Suunnittelun tasot 3 Tietorakenteiden suunnittelu Suunnitellaan järjestelmän toteutuksessa välttämättömät tietorakenteet. Algoritmien suunnittelu Suunnitellaan järjestelmän toteutuksessa käytettävät algoritmit. Komponentti on tietyt tehtävät tekevä ohjelmiston osa, joka yhteistyössä muiden komponenttien kanssa toteuttaa ohjelmiston tarjoamat palvelut. Juha Taina, Ohjelmistotuotanto 31 Yleinen suunnitteluprosessi Requirements specification Design activities Architectural design Abstract specification Interface design Component design Data structure design Algorithm design System architecture Software specification Interface specification Component specification Data structure specification Algorithm specification Design products Kuvalla (C) I. Sommerville 2004 Juha Taina, Ohjelmistotuotanto 32 16
17 Toteutus ja yksikkötestaus Toteutuksessa suunnitelman perusteella tehdään komponentteja. Komponentti tekee yhden asian (eikä muuta) kunnolla. Sillä on selkeä rajapinta ulospäin. Komponentti voi olla kooltaan mitä tahansa yhdestä oliosta kokonaiseen ohjelmaan. Toteutuksen osana tehtävässä yksikkötestauksessa varmistetaan, että komponentit toimivat suunnittelussa määritellyllä tavalla. Juha Taina, Ohjelmistotuotanto 33 Integrointi ja järjestelmätestaus Ohjelmakomponentit kootaan yhteen. Komponenttien välinen yhteistyö testataan integrointitestauksessa. Komponenteista kootaan osajärjestelmiä (itsenäisiä osia). Osajärjestelmien yhteistyö testataan. Koko järjestelmä testataan todellisessa käyttöympäristössä: järjestelmätestaus. Juha Taina, Ohjelmistotuotanto 34 17
18 Ohjelmistoprosessin testausvaiheet Requir ements specifica tion System specifica tion System design Detailed design Acceptance test plan System integ ration test plan Sub-system integ ration test plan Module and unit code and test Service Kuvalla (C) I. Sommerville 2004 Acceptance test System integ ration test Sub-system integ ration test Kaaviossa testaus on alalaidassa ja suunnittelu ylälaidassa. Testauksen kaaviokuva kuvaa V-mallin. Siitä puhutaan lisää myöhemmin. Juha Taina, Ohjelmistotuotanto 35 Ohjelmiston käyttö ja ylläpito Ohjelmistoa on usein tarvetta muuttaa myöhemminkin: Käytössä paljastuu virheitä. Käyttäjien vaatimukset täsmentyvät tai muuttuvat. Käyttöympäristö ja laitteisto muuttuvat. Käyttötavat muuttuvat. Ylläpito = ohjelmiston muuttaminen käyttöönoton jälkeen. Evoluutio = väistämättömät tekijät, jotka pakottavat ohjelmiston muuttumaan. Juha Taina, Ohjelmistotuotanto 36 18
19 3.1. Yleisimmät prosessimallit Yleisimmät prosessimallit ja niiden tyypillisimmät ominaisuudet ovat: Vesiputousmalli: tehtävät peräkkäin. Evoluutiomalli: prototyypit. Komponenttimalli: valmiiden osien käyttö. Lisäävä malli: tehdään vähän kerrassaan. Spiraalimalli: toistetaan samat tehtävät eri mittakaavassa eri vaiheissa. Ketterät mallit: vähemmän hallintoa. Juha Taina, Ohjelmistotuotanto 37 Vesiputousmalli Vesiputousmallissa on lineaarinen lähestymistapa: Jo päätettyyn vaiheeseen ei enää palata myöhemmin. Jokainen vaihe saatetaan loppuun, sen tulokset hyväksytään ja jäädytetään ennen seuraavaan vaiheeseen siirtymistä. Mallin vaiheet ovat suoraviivaisesti prosessimallin perustehtävät. Juha Taina, Ohjelmistotuotanto 38 19
20 Vesiputousmallin tehtäväjako Vaatimusmäärittely Suunnittelu Toteutus Testaus Ylläpito Dokumentointi Juha Taina, Ohjelmistotuotanto 39 Vesiputousmallin edut ja haitat + Malli on selkeä ja helppo omaksua + Kustannusarvio ja aikataulu on helpompi tehdä kuin muissa malleissa. + Ohjelmiston arkkitehtuuri pysyy yleensä hyvin koossa. + Tuloksena saatava hyvä dokumentaatio auttaa ylläpidossa. - Kaikkien vaatimusten selvittäminen kerralla on hankalaa, ja vaatimukset voivat muuttua. - Puhtaasti lineaarinen prosessi ei yleensä onnistu, vaan tarvitaan iteratiivisuutta. - Asiakas ei osallistu kehitystyöhön. - Virheiden elinkaari voi olla hyvin pitkä. Juha Taina, Ohjelmistotuotanto 40 20
21 Evoluutiomalli Evoluutio- tai prototyyppimallissa ohjelmistoa kehitetään väliversioittain. Väliversiot ovat prototyyppejä, joita jalostetaan askeleittain tuotantoversioksi. Ensimmäiset prototyypit ovat suppeita purkalla koottuja nopeita versioita. Käyttäjä antaa palautetta väliversioista. Palautteen perusteella jatketaan kehitystä ja parannetaan samalla laatua. Juha Taina, Ohjelmistotuotanto 41 Evoluutiomallin vaiheet Concurr ent acti vities Specifica tion Initial version Outline description Development Inter media te versions Valida tion Final version Kuvalla (C) I. Sommerville 2004 Juha Taina, Ohjelmistotuotanto 42 21
22 Mitä prototyypille tehdään Prototyypin hylkääminen Tarkoituksena on tarkentaa asiakkaan toiveita ja vaatimuksia. Prototyypin kehittäminen eteenpäin Tarkoituksena on esitellä asiakkaalle ohjelmiston ydintoiminnot. Miksi prototyyppi ei ole valmis ohjelmisto? Prototyyppi on esitoteutus. Prototyyppi ei täytä valmiille ohjelmistolle asetettavia laatuvaatimuksia. Juha Taina, Ohjelmistotuotanto 43 Evoluutiomallin edut ja haitat + Vaatimuksia ei tarvitse määritellä kerralla. + Asiakas antaa jatkuvasti palautetta. + Virheiden elinkaari on yleensä lyhyt. + Käyttöliittymä on koko ajan näkyvillä, joten ohjelmisto pitäisi olla helppo oppia. - Jatkuvat muutokset rikkovat arkkitehtuurin. - Prototyyppien tekoon tarvitaan sovelluskehitin. - Asiakkaan voi olla vaikea ymmärtää, että prototyyppi ei kelpaa lopputuotteeksi. - Viimeinen prototyyppi onkin lopputuote, joten projektilla ei ole selkeää päätepistettä. Juha Taina, Ohjelmistotuotanto 44 22
23 Komponenttimalli Tavoitteena on käyttää mahdollisimman paljon jo valmiita ohjelman osia eli komponentteja. Valmiita komponentteja saadaan omista aiemmista projekteista, ostamalla tai ilmaisista Free Software projekteista (vaarallisia, koska ylläpidosta ei ole takeita) Uudelleenkäytettäviä komponentteja pidetään komponenttikirjastossa. Juha Taina, Ohjelmistotuotanto 45 Komponenttimallin työvaiheet Komponenttimallin työvaiheet ovat: Vaatimusmäärittely Etsitään ja analysoidaan vaatimuksia. Komponenttianalyysi Etsitään komponenttikirjastosta vaatimusanalyysin mukaiseen tuotteeseen sopivia komponentteja. Vaatimusten muokkaus Täydennetään vaatimuksia ottaen huomioon löydetyt komponenttiehdokkaat. Juha Taina, Ohjelmistotuotanto 46 23
24 Komponenttimallin työvaiheet II Työvaiheet jatkuvat: Suunnittelu ja komponenttien eristys Eristetään komponenttikirjastoon omia kelvollisia komponenttiehdokkaiden suunnitelmia. Toteutus ja komponenttien eristys Eristetään komponenttikirjastoon omia kelvollisia komponenttiehdokkaiden toteutuksia. Järjestelmän validointi Varmistetaan, että tehtiin oikea järjestelmä. Juha Taina, Ohjelmistotuotanto 47 Komponenttimallin edut ja haitat + Valmiiden komponenttien käyttö voi säästää paljon työtä. + Komponenttiajattelu ohjaa uudelleenkäytettäviin ratkaisuihin. + Komponenttikirjaston omaa sisältöä voidaan halutessa myydä muille. + Pyörää ei tarvitse keksiä joka kerta uudelleen. - Ohjelmistoa saatetaan tehdä liikaa komponenttien ehdoilla, jolloin asiakkaan vaatimukset yritetään väkisin muokata komponentteihin sopiviksi. - Komponentin dokumentaatio voi olla vajaa. - Komponentin liittäminen oman ohjelmiston osaksi voi olla yllättävän työlästä. - Valmiissa komponentissa olevan virheen löytäminen ja korjaus on usein hyvin hankalaa. Juha Taina, Ohjelmistotuotanto 48 24
25 Lisäävä malli Vesiputousmallissa ohjelma määritellään ja suunnitellaan yhtenä kokonaisuutena. Tämä ei usein toimi: vaatimuksia ei tunneta kunnolla, vaatimukset ovat epäselviä tai vaatimukset muuttuvat projektin aikana. Lisäävässä mallissa ohjelma määritellään ja toteutetaan iteratiivisesti sykleissä: ytimestä erikoisosiin. Juha Taina, Ohjelmistotuotanto 49 Lisäävä malli II Ohjelmisto jaetaan osiin, jotka toteutetaan omina sykleinä. Ensin toteutetaan ydin, johon seuraavien syklien tulokset voidaan liittää. Vain yhden syklin vaatimukset käsitellään kerrallaan. Toteuttamattomien syklien vaatimukset voivat muuttua. Juha Taina, Ohjelmistotuotanto 50 25
26 Lisäävän mallin strategia, edut ja haitat Define outline requirements Assign requirements to increments Design system architectur e Develop system increment Kuvalla (C) I. Sommerville 2004 Valida te increment System incomplete Integ rate increment Validate system + Tuote on käyttökelpoinen alusta alkaen. + Tärkeimmät piirteet toteutetaan ensin. + Virheelliset määritykset huomataan nopeasti. + Syklin aikataulu pysyy yleensä hyvin hallussa. - Koko projektin aikataulun laadinta vaikeutuu. - Projektin hallinta on hankalaa: tehtävät ovat pieniä ja rinnakkaisia. - Mitä lyhyempi on sykli, sitä suurempi on kiusaus säästää laadusta. Final system Juha Taina, Ohjelmistotuotanto 51 Spiraalimalli Spiraalimallissa kukin spiraalin kierros esittää yhtä prosessin työvaihetta. Kussakin spiraalissa on neljä sektoria: tehtävän asetus, tavoite ja aikataulu, riskianalyysi, kehitystyö ja tuloksen verifiointi, tuloksen arviointi ja seuraavan spiraalin suunnittelu. Spiraaleissa voidaan käyttää mitä tahansa prosessimallia. Juha Taina, Ohjelmistotuotanto 52 26
27 Spiraalimallin edut ja haitat + Malli sopii mainiosti erikokoisiin tehtäviin. + Kussakin spiraalissa voidaan käyttää omaa prosessia. + Riskienhallinta on osa prosessimallia. + Mallilla voidaan kuvata tuotteen koko elinkaari mukaan lukien ylläpito. - Malli voi olla vaikea selittää sitä tuntemattomalle. - Projektin hallinta voi olla vaikeaa. - Aikataulun tekeminen vaikeutuu. - Käytännön kokemuksia on vähän: ketterät prosessimallit ovat syöneet spiraalimallin suosiota. Juha Taina, Ohjelmistotuotanto 53 Ketterät prosessimallit ja 1990-luvun prosessimalleissa korostettiin huolellista projektisuunnittelua, formaalia laadunvalvontaa, yksityiskohtaisia analyysi- ja suunnittelumenetelmiä, CASE-työkalujen käyttöä ja täsmällistä tarkasti ohjattua ohjelmistoprosessia. Juha Taina, Ohjelmistotuotanto 54 27
28 Ketterien prosessimallien synty Prosessimallit tukivat erityisesti laajojen, pitkäikäisten ohjelmistojen kehitystyötä, mutta pienten ja keskisuurten ohjelmistojen tekoon ne osoittautuivat usein turhan jäykiksi. Ristiriidan seurauksena syntyi joukko ketteriä prosessimalleja (agile process models), jotka korostivat itse ohjelmistoa yksityiskohtaisen suunnittelun ja dokumentaation sijaan. Näistä tunnetuimmat ovat extreme Programming (XP) ja Scrum. Juha Taina, Ohjelmistotuotanto 55 Ketterien prosessien luonne Kaikki ketterät prosessimallit ovat lisäävän mallin tapaan iteratiivisia. Yksi sykli on vain muutaman viikon mittainen. Sen aikana käydään läpi vaiheet vaatimuksista luovutukseen. Lyhyen syklin johdosta asiakas on jatkuvasti mukana kehitystyössä. Asiakkaan palautetta tarvitaan jatkuvasti Juha Taina, Ohjelmistotuotanto 56 28
29 Ketterien prosessien periaatteet Asiakkaan osallistuminen Asiakas osallistuu aktiivisesti kehitystyöhön. Asiakas esittää ja priorisoi uusia järjestelmän vaatimuksia ja evaluoi syklin aikana saadut tulokset. Lisääntyvät ominaisuudet Kullakin syklillä ohjelmistoon lisätään uusia ominaisuuksia, joiden vaatimukset saadaan asiakkaalta. Juha Taina, Ohjelmistotuotanto 57 Ketterien prosessien periaatteet II Ihmiset prosessia tärkeämmät Työntekijöiden taidot ja toimintatavat ovat tärkeämmät kuin vahvasti ohjattu prosessi. Muutoksen hyväksyminen Vaatimukset muuttuvat, joten edellisillä sykleillä tehtyä koodia saatetaan joutua uudistamaan. Yksinkertaisuuden ylläpito Sekä ohjelmisto että prosessi tulee pitää mahdollisimman yksinkertaisena (mutta ei yhtään yksinkertaisempana). Dokumentaatio minimoidaan Juha Taina, Ohjelmistotuotanto 58 29
30 Ketterien prosessimallien edut ja haitat + Lyhyessä syklissä vaatimusmäärittely, suunnittelu ja yksikkötestaus on helppo tehdä. + Asiakas on jatkuvasti läsnä antamassa palautetta. + Mallit ovat joustavia suosien tekijöitä enemmän kuin hallintaa. + Vaatimukset saavat muuttua projektin aikana. + Pienten ja keskisuurten projektien teko on tehokasta. - Koko projektin aikataulun laadinta on hyvin vaikeaa. - Projektin hallinta on vaikeaa. - Jatkuva koodin uudistaminen on kallista ja voi heikentää tuotteen laatua. - Pieninkään mahdollinen kokonaisuus ei aina mahdu sykliin. - Sykliin on kiusaus laittaa enemmän tavaraa kuin sinne oikeastaan mahtuu. - Isojen projektien tekeminen on vaikeaa. Juha Taina, Ohjelmistotuotanto 59 Extreme programming (XP) Ohjelma kehitetään hyvin pieninä sykleinä. Aluksi tehdään pieni ydin. Jatkossa lisätään sykli kerrallaan mahdollisimman pieni järkevä joukko ominaisuuksia. Toteutusjärjestys määräytyy asiakkaiden tarpeista Projektia suunnitellaan mahdollisimman lyhyt aika eteenpäin. Dokumentaatio karsitaan minimiin. Toimiva tuote on tärkeämpi kuin raskas dokumenttikirjasto. Koodi on tärkein dokumentti. Malliin kuuluu joukko prosessiohjeita. Juha Taina, Ohjelmistotuotanto 60 30
31 4. Ohjelmistojen vaatimusmäärittely Ehkä kaikkein merkittävin ohjelmistotuotannon ongelma on selvittää asiakkaalta järjestelmälle asetettavat vaatimukset (requirements) Kaikki helposti määriteltävät järjestelmät on jo määritelty, joten ongelma vain pahenee. Vaatimukset kuvaavat sen, minkälaisen järjestelmän asiakas haluaa auttamaan tai helpottamaan jotain toimintaa. Juha Taina, Ohjelmistotuotanto 61 Vaatimusmäärittelyn tehtävät Vaatimusmäärittely (requirements engineering) tarkoittaa prosessia, jossa selvitetään järjestelmälle asetettavat vaatimukset. Vaatimusmäärittelyssä selvitetään mitä järjestelmän pitää tarjota (toiminnot), toivotut ja vaaditut koko järjestelmää koskevat ominaisuudet (laatuvaatimukset), järjestelmän rajoitukset ja reunaehdot. Juha Taina, Ohjelmistotuotanto 62 31
32 4.1. Vaatimusmäärittelyprosessi Kuten yleisemmissäkin prosesseissa, myös vaatimusmäärittelyprosesseissa on paljon vaihtelua. Käytännössä kaikista prosesseista löytyvät kuitenkin samat perustehtävät: kelpoisuusselvitys (feasibility study), kartoitus ja analyysi (elictation and analysis), määrittely (specification) ja validointi (validation). Juha Taina, Ohjelmistotuotanto 63 Vaatimusmäärittelyn tehtäväjako (sama kuin kalvo 27) Feasibility study Requir ements elicitation and anal ysis Requir ements specification Feasibility repor t Requir ements validation System models User and system requirements Requir ements document Kuvalla (C) I. Sommerville 2004 Juha Taina, Ohjelmistotuotanto 64 32
33 Vaatimusmäärittelyn spiraalimalli Vaatimusmäärittelyyn voidaan ottaa myös spiraalimainen näkökulma. Tällöin saadaan mukaan näkökulma, minkä mukaan vaatimuksia ei saada kokoon kerralla vaan iteratiivisesti. Malli sallii myös vaatimusmäärittelyn rinnalla tehtävän ohjelmiston suunnittelun/toteutuksen. Juha Taina, Ohjelmistotuotanto 65 Vaatimusmäärittelyn spiraalí System requirements specification and modeling Requirements specification User requirements specification Business requirements specification System requirements elicitation User requirements elicitation Feasibility study Prototyping Requirements elicitation Reviews Requirements validation Kuvalla (C) I. Sommerville 2004 System requirements document Juha Taina, Ohjelmistotuotanto 66 33
34 Kelpoisuusselvitys Kelpoisuusselvitys on lyhyt esivaihe vaatimusmäärittelylle. Siinä vastataan seuraaviin kysymyksiin: 1. Tuoko kehitettävä järjestelmä lisäarvoa asiakkaalle? 2. Voidaanko järjestelmä toteuttaa nykyisellä teknologialla projektille varatulla aikataululla ja budjetilla? 3. Voidaanko järjestelmä integroida jo käytössä oleviin järjestelmiin? Juha Taina, Ohjelmistotuotanto 67 Kelpoisuusselvitys 2 Lisäksi, vaikka Sommerville ei sitä listaa: 4.Kannattaako järjestelmä toteuttaa, vai voidaanko vastaava järjestelmä ostaa valmiina? Onko ostettava järjestelmä sovitettavissa asiakkaan tarpeisiin? Tuloksena saadaan päätös siitä, kannattaako järjestelmän kehitystyötä jatkaa. Juha Taina, Ohjelmistotuotanto 68 34
35 Vaatimusten kartoitus ja analyysi Vaatimusten kartoitus ja analyysi työvaiheessa etsitään yhteistyössä asiakkaan ja järjestelmän loppukäyttäjien kanssa, mitä palveluja järjestelmältä vaaditaan, mitä järjestelmän suorituskyvyltä vaaditaan, mitä laitteisto- ja ympäristörajoituksia on huomioitava jne. Työvaiheessa huomioidaan sidosryhmät. Juha Taina, Ohjelmistotuotanto 69 Sidosryhmät Sidosryhmä (stakeholder) on henkilö tai ryhmä, joka suoraan tai välillisesti on tekemisissä kehitettävän järjestelmän kanssa. Eri sidosryhmillä on erilaisia tarpeita kehitettävälle järjestelmälle Ł ristiriitoja. Sidosryhmät eivät välttämättä osaa kertoa, mitä kaipaavat järjestelmältä. Juha Taina, Ohjelmistotuotanto 70 35
36 Kartoituksen ja analyysin vaiheet Vaatimusten kartoitus ja analyysi voidaan osittaa seuraaviin tehtäviin: Vaatimusten esiinkaivelu (req. discovery) Vaatimusten luokittelu (req. classification and organization) Vaatimusten priorisointi (req. priorization) Vaatimuksista neuvottelu (req. negotiation) Vaatimusten dokumentointi (req. documentation) Juha Taina, Ohjelmistotuotanto 71 Kartoituksen ja analyysin spiraali Requirements classification and organisation Requirements discovery Requirements prioritization and negotiation Requirements documentation Kartoitus ja analyysi on iteratiivinen prosessi. Prosessi aloitetaan isoista vaatimuksista ja edetään kohti pienempiä ja pienempiä yksityiskohtia. Kuvalla (C) I. Sommerville 2004 Juha Taina, Ohjelmistotuotanto 72 36
37 Vaatimusten esiinkaivelu Vaatimusten esiinkaivelussa sidosryhmiltä selvitetään, mitä he odottavat järjestelmältä. Selvittäminen voi olla suoraviivaista (esim. haastattelut) tai se voi epäsuoraa (dokumentaatioon tutustuminen, loppukäyttäjien työympäristöön tutustuminen). Juha Taina, Ohjelmistotuotanto 73 Esiinkaivelun tekniikoita Esiinkaivelussa voidaan käyttää esimerkiksi seuraavia tekniikoita: Näkökulmat (viewpoints): mitä suoria tai epäsuoria yhteyksiä sidosryhmillä on järjestelmään. Haastattelut (interviews): sidosryhmiltä selvitetään sopivin kysymyksin, mitä he odottavat järjestelmältä. Juha Taina, Ohjelmistotuotanto 74 37
38 Esiinkaivelun tekniikoita 2 Lisää tekniikoita: Skenaariot (scenarios) ja käyttötapaukset (use cases): kirjataan suoraviivaisia kuvauksia tulevan järjestelmän käytöstä, skenaarioita. Tarvittaessa toisiinsa sidoksissa olevat skenaariot ryhmitellään yhteen käyttötapauksiksi. Etnografia (ethnography): mennään paikan päälle katsomaan, miten tulevan järjestelmän loppukäyttäjät työskentelevät. Juha Taina, Ohjelmistotuotanto 75 Vaatimusten määrittely Vaatimusten määrittelyssä vaatimusten kartoituksessa ja analyysissa löydetyt vaatimukset lajitellaan käyttäjä- ja järjestelmävaatimuksiksi. Tarvittaessa vaatimuksia muokataan ja tarkennetaan. Käyttäjävaatimuksista voidaan johtaa uusia järjestelmävaatimuksia. Tuloksena saadaan koko järjestelmää esittävät priorisoidut vaatimukset. Juha Taina, Ohjelmistotuotanto 76 38
39 Käyttäjävaatimukset Käyttäjävaatimuksissa kuvataan luonnollisella kielellä ja kaavioilla, mitä palveluja järjestelmän odotetaan tarjoavan ja mitä rajoituksia ja reunaehtoja järjestelmällä on. Käyttäjävaatimusten lukijat eivät ole ohjelmistotuotannon ammattilaisia, joten kuvausten pitää olla helppolukuisia. Juha Taina, Ohjelmistotuotanto 77 Järjestelmävaatimukset Järjestelmävaatimukset määrittelevät yksityiskohtaisesti ja rakenteisella yhtenäisellä kuvaustekniikalla järjestelmän tarjoamat palvelut, järjestelmän toiminnot, järjestelmän toiminnan rajoitteet. Järjestelmävaatimukset määrittelevät täsmälleen, mitä järjestelmä tekee ja mitä ehtoja sille asetetaan. Juha Taina, Ohjelmistotuotanto 78 39
40 Käyttäjä- ja järjestelmävaatimusten käyttö Käyttäjävaatimuksia käytetään kilpailutettaessa ohjelmistoyrityksiä ohjelmistosopimuksesta, kuvattaessa järjestelmää loppukäyttäjille, kuvattaessa järjestelmää omalle johdolle. Järjestelmävaatimuksia käytetään sopimuksena asiakkaan ja ohjelmistoyrityksen välillä, suunnittelun lähtökohtana. Juha Taina, Ohjelmistotuotanto 79 Vaatimusten luokittelu Käyttäjä- ja järjestelmävaatimukset luokitellaan kolmeen ryhmään: Toiminnalliset vaatimukset (functional requirements) kuvaavat järjestelmän tarjoamat palvelut, miten järjestelmä reagoi annettuihin syötteisiin ja miten järjestelmä toimii määritellyissä tilanteissa. Joskus toiminnalliset vaatimukset määrittelevät myös, mitä järjestelmä ei missään tapauksessa tee. Juha Taina, Ohjelmistotuotanto 80 40
41 Vaatimusten luokittelu 2 Ei-toiminnalliset vaatimukset (nonfunctional requirements) ovat järjestelmän toiminnoille asetettavia rajoituksia ja reunaehtoja. Ei-toiminnalliset vaatimukset koskevat koko järjestelmää. Kaikki järjestelmän toiminnalliset vaatimukset toteuttavat järjestelmän ei-toiminnalliset vaatimukset. Jotkut ei-toiminnalliset vaatimukset voivat koskea myös järjestelmän kehitystyötä. Juha Taina, Ohjelmistotuotanto 81 Vaatimusten luokittelu 3 Toimintaympäristövaatimukset (domain requirements) ovat vaatimuksia, jotka järjestelmän täytyy täyttää toimiakseen yhteistyössä muun maailman kanssa. Toimintaympäristövaatimukset (tai lyhyemmin ympäristövaatimukset) liittyvät esimerkiksi muihin yhteistyössä toimiviin järjestelmiin tai fysiikan lakeihin. Toimintaympäristövaatimukset voivat olla toiminnallisia tai ei-toiminnallisia. Juha Taina, Ohjelmistotuotanto 82 41
42 Toiminnalliset vaatimukset Toiminnalliset vaatimukset voidaan kuvata palveluina: mitä kaikkea järjestelmä tarjoaa, toimintoina: mitä järjestelmä tekee ja miten, palveluina ja toimintoina: mitkä toiminnot toteuttavat mitkä palvelut (ristiviittaus). Toiminnallisten vaatimusten on oltava täydellisiä: kaikki palvelut määritellään, yhdenmukaisia: ei ristiriitoja. Juha Taina, Ohjelmistotuotanto 83 Ei-toiminnalliset vaatimukset Ei-toiminnalliset vaatimukset ovat ainakin yhtä tärkeitä kuin toiminnalliset vaatimukset. Ne kertovat sen, miten käyttäjä kokee järjestelmän. On mahdollista, että ei-toiminnallisen vaatimuksen pettäessä koko järjestelmä on käyttökelvoton. Kehitystyöhön liittyvät ei-toiminnalliset vaatimukset vaikuttavat esim. ylläpitoon. Juha Taina, Ohjelmistotuotanto 84 42
43 Ei-toiminnallisia vaatimuksia Non-functional requir ements Product requir ements Organisational requir ements External requir ements Efficiency requir ements Reliability requir ements Portability requir ements Inter oper ability requir ements Ethical requir ements Usa bility requir ements Deli very requir ements Implementa tion requir ements Standar ds requir ements Leg islative requir ements Perfor mance requir ements Space requir ements Kuvalla (C) I. Sommerville 2004 Privacy requir ements Safety requir ements Juha Taina, Ohjelmistotuotanto 85 Käyttöympäristövaatimukset Käyttöympäristövaatimukset ovat tärkeitä, sillä ne määrittelevät ehdot, jotka järjestelmän tulee täyttää, jotta se voi toimia yhteistyössä muiden järjestelmien tai fysiikan lakien kanssa. Käyttöympäristövaatimuksia ovat esimerkiksi järjestelmälle määriteltävät rajapinnat muihin järjestelmiin ja luonnonlaeista seuraavat rajoitteet. Juha Taina, Ohjelmistotuotanto 86 43
44 Vaatimusten validointi Vaatimusten validoinnissa ratkotaan vaatimusten väliset konfliktit ja osoitetaan, että vaatimuksilla kuvattu järjestelmä on sitä, mitä asiakas haluaa. Validointi on erittäin tärkeää, sillä virheelliset vaatimukset heijastuvat koko tuotteen elinkaaren ajan. Mitä myöhemmin virheellinen vaatimus keksitään, sitä kalliimpaa sen korjaus on. Juha Taina, Ohjelmistotuotanto 87 Vaatimusten tarkastus Vaatimuksista tarkastetaan Yhtenäisyys: onko vaatimukset kuvattu johdonmukaisella tarkkuudella ja tekniikoilla? Täydellisyys: kuvaavatko vaatimukset koko järjestelmän? Verifioitavuus: ovatko vaatimukset testattavissa? Ymmärrettävyys: ymmärtävätkö tekijät ja loppukäyttäjät vaatimukset? Seurattavuus: onko jokaisen vaatimuksen esittäjä ja sidosryhmä tiedossa? Mukautuvuus: Voidaanko vaatimuksia muuttaa ilman laajoja muutoksia muihin vaatimuksiin? Juha Taina, Ohjelmistotuotanto 88 44
45 Vaatimusdokumentti Vaatimusdokumentti (software requirements document tai software requirements specification, SRS) kuvaa yksiselitteisesti ainakin seuraavat asiat: Järjestelmän käyttötarkoituksen. Dokumentaatiossa käytetyn ammattisanaston. Käyttäjä- ja järjestelmävaatimukset. Järjestelmäarkkitehtuurin ja järjestelmämallit. Järjestelmän elinkaaren ja yhteydet muihin järjestelmiin. Juha Taina, Ohjelmistotuotanto 89 Vaatimusdokumentin rakenne Vaatimusdokumentin rakenteen pitää olla sellainen, että sitä voidaan käyttää ainakin sopimuksena asiakkaan ja ohjelmistoyrityksen välillä, suunnittelun lähtökohtana, johdolle esiteltävänä yleisenä kuvauksena tehtävästä tuotteesta ja järjestelmätestauksen lähtökohtana. Juha Taina, Ohjelmistotuotanto 90 45
46 5. Ohjelmistojen suunnittelu Suunnittelussa päätetään ohjelmiston loogisesta rakenteesta. Rakenne kuvataan eri abstraktiotasoilla. Mitä korkeampi abstraktiotaso, sitä paremmin selviää yleiskuva, mutta sitä vähemmän näkyy yksityiskohtia. Korkein suunnittelun abstraktiotaso on arkkitehtuurisuunnitelma, matalin on pseudokoodi. Juha Taina, Ohjelmistotuotanto 91 Suunnittelun luonne Suuunnittelu on luovaa toimintaa, jota ei kannata rajoittaa liikaa prosesseihin. Myös vastakkainen kanta, tarkasti ohjattu suunnitteluprosessi, on saanut kannatusta. Ei ole helppoa suoraviivaista tapaa suunnitella ohjelmisto. Jokainen suunnittelu on ainutkertainen. Suunnittelun lähtökohtana voi käyttää esimerkiksi prosessia kalvolla 32. Juha Taina, Ohjelmistotuotanto 92 46
47 5.1. Arkkitehtuurisuunnittelu Suuret järjestelmät ositetaan aina keskenään yhteistyötä tekeviksi osajärjestelmiksi. Osajärjestelmien tunnistaminen ja niiden välisen viestinvälityksen määrittely on arkkitehtuurisuunnittelua. Arkkitehtuurisuunnittelun lopputuloksena saadaan järjestelmän arkkitehtuurikuvaus. Juha Taina, Ohjelmistotuotanto 93 Osajärjestelmät ja ei-toiminnalliset vaatimukset Osajärjestelmiin jako riippuu eitoiminnallisista vaatimuksista: Jos suorituskyky on tärkeää, kannattaa käyttää mahdollisimman pientä lukumäärää laajoja osajärjestelmiä. Jos turvallisuus on tärkeää, kannattaa käyttää sisäkkäisiä arkkitehtuureja, joista kaikkein sisimmällä tasolla ovat turvallisuuskriittisimmät toiminnot. Jos saatavuus on tärkeää, samat palvelut kannattaa toistaa monessa osajärjestelmässä. Jos ylläpidettävyys on tärkeää, kannattaa käyttää suurta määrää pieniä osajärjestelmiä. Juha Taina, Ohjelmistotuotanto 94 47
48 Arkkitehtuurisuunnitelma Arkkitehtuurisuunnittelun lopputuloksena saadaan järjestelmän arkkitehtuurisuunnitelma. Se sisältää koko järjestelmän kuvauksen, järjestelmästä tehdyt kaaviokuvat selityksineen, järjestelmän jaon osajärjestelmiin ja osajärjestelmittäin komponentteihin, osajärjestelmien välisen yhteydenpidon. Juha Taina, Ohjelmistotuotanto 95 Osajärjestelmin ositus Arkkitehtuurisuunnittelun jälkeen kukin osajärjestelmä ositetaan moduuleiksi (module). Moduuli on järjestelmän komponentti, joka käyttää muiden moduuleiden palveluja ja tarjoaa muille moduuleille palveluja. Moduuli ei ole itsenäinen,kuten osajärjestelmä, vaan tiiviissä yhteistyössä muiden moduulien kanssa toteuttaa osajärjestelmän toiminnot. Juha Taina, Ohjelmistotuotanto 96 48
49 5.2. Rajapintasuunnittelu Rajapintasuunnittelu on ehkä suunnittelun tärkein työvaihe. Siinä jokaisen osajärjestelmän tai moduulin rajapinta muihin osajärjestelmiin tai moduuleihin suunnitellaan ja dokumentoidaan yksityiskohtaisesti. Rajapintojen pitää olla sellaiset, että tarjottuja palveluja voidaan käyttää tietämättä niiden toteutuksesta mitään. Juha Taina, Ohjelmistotuotanto 97 Rajapintojen määrittely Rajapintojen määrittelyt tulee tehdä yksiselitteisiksi ja ristiriidattomiksi. Rajapintakuvauksesta tulee näkyä: Rajapinnan palvelut. Kunkin palvelun syötteiden ja tulosteiden tyypit ja arvoalueet. Kunkin palvelun kohdalta ehdot, joiden on oltava voimassa ennen palvelun kutsua ja ehdot, jotka palvelu takaa kutsun jälkeen. Rajapinnoissa oikea abstraktiotaso on tärkeä. Juha Taina, Ohjelmistotuotanto 98 49
50 5.3. Oliopohjainen suunnittelu Aiemmin esitelty suunnitteluprosessi (kalvo 32) on geneerinen, jota voidaan tarkentaa esimerkiksi oliopohjaisessa lähestymistavassa. Sommerville listaa viisi työvaihetta, jotka sopivat erityisesti oliopohjaiseen suunnitteluun: ymmärrys, arkkitehtuuri, oliot, mallit, rajapinnat. Juha Taina, Ohjelmistotuotanto 99 Oliopohjaisen suunnittelun perustehtävät 1. Järjestelmän toiminnan ja sen erilaisten käyttötapojen ymmärtäminen. Siis vaatimusten ymmärtäminen. 2. Järjestelmäarkkitehtuurin suunnittelu Arkkitehtuurisuunnittelua, kokonaiskuvan määrittely. 3. Tärkeimpien olioiden tunnistus Oliot voivat olla eritasoisia osajärjestelmästä palvelun tai toiminnon yksityiskohtaan. 4. Järjestelmämallien kehitys Osajärjestelmä- ja komponenttisuunnittelua. 5. Olioiden rajapintojen määrittely Rajapintasuunnittelua. Juha Taina, Ohjelmistotuotanto
51 Oliomalli ja yleinen suunnittelumalli Yleiseen suunnittelumalliin verrattuna oliosuunnittelumalli painottaa olioiden roolia. Oliot ovat käteviä mm. ulkomaailman mallintamisessa, mutta silti on järkevää pitää lisäksi komponenttitaso kokoamassa yhteistyössä toimivat oliot yhteen. Olioita voidaan tunnistaa järjestelmämalleista ja kuvauksista. Näitä olioita käyttämällä ja uusia lisäämällä saadaan tarkennettua arkkitehtuuria ja kehitettyä järjestelmämalleja. Juha Taina, Ohjelmistotuotanto Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, jossa varmistetaan, että ohjelmisto täyttää sille asetetut vaatimukset ja ohjelmisto täyttää sen tilanneen asiakkaan ohjelmistolle asettamat tarpeet. V&V:ta tehdään koko ohjelmistoprosessin elinkaaren ajan. Juha Taina, Ohjelmistotuotanto
52 Verifioinnin ja validoinnin ero Verifioinnissa varmistetaan, että ohjelmisto vastaa määrityksiään siis kirjattuja vaatimuksia: Verification: Are we building the product right? Validoinnissa varmistetaan, että ohjelmisto täyttää asiakkaan odotukset ja tarpeet: Validation: Are building the right product? Juha Taina, Ohjelmistotuotanto 103 Verifiointi- ja validointitekniikat V&V:ssa käytetään enimmäkseen kahta tekniikkaa: tarkastuksia ja testausta. Tarkastukset (software inspections). Tarkastuksessa joukko ihmisiä analysoi ja tarkastaa järjestelmällisesti muodollisessa tarkastustilaisuudessa jonkin projektin tuotoksen tai sen osan etsien siitä puutteita ja virheitä. Tarkastukset ovat staattinen tekniikka. Ne eivät vaadi suorituskelpoista ohjelmaa. Tarkastettavana voi olla esimerkiksi vaatimusdokumentaation, suunnittelun tai ohjelmakoodin osa. Juha Taina, Ohjelmistotuotanto
53 Verifiointi- ja validointitekniikat 2 Testaus (software testing). Testauksessa ohjelmistoa tai sen osaa suoritetaan tietyillä testitiedoilla. Tuloksia analysoimalla ja ohjelmiston suoritusta seuraamalla selvitetään, että toiminta on odotettua. Testaus on dynaaminen tekniikka, sillä siihen tarvitaan suorituskelpoinen ohjelma. Tarkastuksia voidaan tehdä koko ajan, testausta vasta ohjelmakoodin kanssa. Molempia tekniikoita tarvitaan V&V:ssa, sillä ne paljastavat eri tyyppisiä virheitä. Juha Taina, Ohjelmistotuotanto 105 Verifioinnin ja validoinnin tavoite V&V:n tavoitteena on varmistaa, että ohjelmisto täyttää sille asetetut tarpeet. Ohjelmiston ei tarvitse olla virheetön, eikä se myöskään yleensä ole sitä. Ohjelmiston on sen sijaan oltava tarkoitettuun käyttöön riittävän hyvä. Se, miten paljon on riittävän hyvä, riippuu ohjelmiston käyttöympäristöstä. Juha Taina, Ohjelmistotuotanto
54 V&V:n hallinnan V-malli (V-kirjaimia riittää!) Requir ements specifica tion System specifica tion System design Detailed design Acceptance test plan System integ ration test plan Sub-system integ ration test plan Module and unit code and test Service Acceptance test System integ ration test Sub-system integ ration test Kuvalla (C) I. Sommerville 2004 V-malli kuvaa V&V-työvaiheen suhteen muihin prosessin työvaiheisiin. Tarkastuksia voidaan pitää missä tahansa työvaiheessa tai niiden välillä. Juha Taina, Ohjelmistotuotanto Tarkastukset Tarkastus (inspection) on muodollinen kokous, jossa tarkastetaan jonkin projektin tuotos, tai osa siitä, ja yritetään löytää tuotoksesta puutteita ja virheitä. Puute = vajaa määritys tai puuttuva toiminta. Virhe = väärin tehty määritys tai ei-toivottu toiminta. Juha Taina, Ohjelmistotuotanto
55 Katselmoinnit Katselmointi (review) on tekniikka, jossa yksi tai useampi henkilö etsii toisen tuotoksesta puutteita ja virheitä. Tarkastus on muodollisin katselmointitekniikka. Muita katselmointitekniikoita ovat esimerkiksi pariohjelmointi (pair programming), tekninen tarkastus (team review tai technical review) ja koodin läpikäynti (code walkthrough). Katselmointeja tehdään kaikissa prosessin työvaiheissa. Mikä tahansa dokumentti voidaan verifioida tai validoida katselmoinnilla. Katselmoinnit parantavat tuotteen laatua. Mitä aiemmin puute tai virhe löydetään, sitä helpompi se on korjata. Juha Taina, Ohjelmistotuotanto 109 Tarkastusten luonne Tarkastus on muodollinen tilaisuus, johon osallistuu 3-6 henkilöä. Tilaisuudella on tarkka aikataulu. Osallistujat edustavat eri sidosryhmiä asiakkaasta projektiryhmän jäseniin. Tarkastuksessa kootaan ja dokumentoidaan löydetyt puutteet ja virheet. Osallistujat valmistautuvat etukäteen noin kahden tunnin ajan tilaisuuteen tutustumalla tarkastettavaan dokumenttiin. Juha Taina, Ohjelmistotuotanto
56 Tarkastukseen osallistujat Osallistujien roolit: Puheenjohtaja (moderator): vastaa tarkastuksen aikataulusta ja ohjelmasta. Sihteeri (scribe): kirjaa ylös löydetyt asiat. Alustaja (reader): kuvaa esitettävän asian. Kirjoittaja (author/owner): edustaa tekijöitä ja selventää tarvittaessa epäselvyyksiä. Tarkastaja (inspector): etsii dokumentista puutteita ja virheitä (kaikkien rooli). Juha Taina, Ohjelmistotuotanto 111 Ennen tarkastusta Ennen tarkastustapahtumaa: kaikki tarkastuksessa tarvittavat dokumentit ovat saatavilla, osallistujilla on ollut aikaa tutustua dokumentteihin (valmistautuminen noin 2h), osallistujat ovat saaneet tarkistuslistat yleisimmistä puutteista ja virheistä, ja tarkastettava dokumentti on sellaisella tasolla, että siinä ei ole ilmeisiä virheitä. Juha Taina, Ohjelmistotuotanto
57 Tarkastustapahtuma Tarkastustapahtuma saa kestää korkeintaan kaksi tuntia. Siinä keskitytään yksinomaan löytämään puutteita ja virheitä. Tarkastukseen osallistujat eivät keskustele löydetyistä puutteista. Kun puute on havaittu, sihteeri kirjaa sen ylös ja siirrytään eteenpäin. Juha Taina, Ohjelmistotuotanto 113 Tarkastuksen päätös Tarkastuksen lopuksi ryhmä äänestää tuotoksen hyväksymisestä: Hyväksytään sellaisenaan: ei muutoksia. Hyväksytään muutoksin: löydetyt puutteet ja virheet on korjattava, mutta tuotoksesta ei tarvita enää uutta tarkastusta. Hylätään: löydetyt puutteet ja virheet on korjattava. Korjauksen jälkeen tuotoksesta käydään läpi uusi tarkastus. Juha Taina, Ohjelmistotuotanto
58 Tarkastusten kultaiset säännöt 1.Arvioidaan tuotetta, ei tekijää. 2.Suunnitellaan aikataulu ja pidetään siitä kiinni. 3.Ei väittelyä. 4.Ei ratkota löydettyjä ongelmia. 5.Rajoitetaan osallistujien määrä 3-6 henkeen. 6.Valmistaudutaan huolellisesti tarkastukseen. 7.Käytetään tarkistuslistoja sekä valmistautuessa että tarkastuksessa. 8.Varataan riittävästi aikaa ja resursseja. 9.Koulutetaan osallistujat. 10. Pidetään tarkastuksessa kännykät kiinni! Juha Taina, Ohjelmistotuotanto Testaus Testauksella on kaksi tavoitetta: Osoittaa sekä asiakkaille että projektille, että ohjelmisto täyttää sille asetetut vaatimukset. Tämä on validointitestausta. Löytää ohjelmistosta puutteita ja virheitä, joiden johdosta ohjelmisto ei toimi, toimii väärin tai ei vastaa sille asetettuja määrittelyjä. Tämä on määritysten ja syntaksin testausta (Sommervillella termi on defect testing). Juha Taina, Ohjelmistotuotanto
59 Testauksen piirteitä Suunnittelu kannattaa tehdä V-mallin mukaisesti rinnan kehitystyön kanssa. Valmistelu on testiympäristön ohjelmointia ja tietojen keruuta, johon pätevät normaalit ohjelmistotekniikan säännöt. Suoritus pitää automatisoida, jotta testit voidaan suorittaa helposti uudestaan. Analysoinnissa tarvitaan oraakkeli (oracle), joka kertoo, oliko testin antama tulos oikea. Juha Taina, Ohjelmistotuotanto 117 Täydellinen testaus mahdotonta Täydellinen testaus, missä ohjelma testataan kaikilla mahdollisilla syötteillä, syötekombinaatioilla ja ajoituksilla, ei ole käytännössä mahdollista. Jo hyvin yksinkertaisilla ohjelmilla kaikkien testitapausten suoritus veisi vuosia. Tämän johdosta testauksessa valitaan osajoukko kaikista mahdollisista testitapauksista. Juha Taina, Ohjelmistotuotanto
60 Testausvaiheet Sommerville jakaa testauksen kahtia: Komponenttitestauksessa (Component testing) ohjelmaa testataan osina. Testatut osat kootaan yhteen ja testaan koottuina. Komponenttitestaus kuuluu pääosin ohjelmiston kehittäjille (projektiryhmälle). Järjestelmätestauksessa (System testing) testataan järjestelmää kokonaisuutena. Järjestelmätestaus kuuluu pääosin ulkopuoliselle testausryhmälle. Juha Taina, Ohjelmistotuotanto 119 Järjestelmätestaus Työvaihe on liittävä: Kuhunkin osajärjestelmään liitetään komponentteja ja testataan komponenttien yhteistyö. Tämä on integrointitestausta. Komponentit lisätään ja testataan yksi kerrallaan, kunnes kaikki osajärjestelmän komponentit on liitetty ja testattu. Kun kaikki osajärjestelmät on koottu ja testattu, testataan vielä, että osajärjestelmät toimivat yhdessä oikein. Juha Taina, Ohjelmistotuotanto
61 Integrointitestaus Integrointitestauksessa testataan valmiiden yksittäin toimivien komponenttien yhteistyö osajärjestelmässä. Integrointia voidaan tehdä ylhäältä alas (aloitetaan ohjaavista osista) tai alhaalta ylös (aloitetaan suorittavista osista). Voidaan myös integroida molemmista suunnista samaan aikaan. Juha Taina, Ohjelmistotuotanto 121 Rasitustestaus Integrointitestauksen jälkeen järjestelmän kriittisiä ominaisuuksia voidaan testata: suorituskykyä, luotettavuutta ja vikasietoisuutta, turvallisuutta. Rasitustestauksessa ohjelma viedään äärirajoille ja mielellään vielä niiden yli. Juha Taina, Ohjelmistotuotanto
Ohjelmistojen suunnittelu
Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer
2. Ohjelmistotuotantoprosessi
2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa
Prosessimalli. 2. Ohjelmistotuotantoprosessi. Prosessimallin vaihejako. Prosessimallien perustehtävät. Ohjelmiston suunnittelu. Vaatimusmäärittely
2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa
1. Johdanto. Ohjelmistotuotannon piirteitä
1. Johdanto Termi Ohjelmistotuotanto (Software Engineering) esiteltiin ensimmäistä kertaa 1968 pidetyssä NATO:n konferenssissa. Termi määriteltiin näin: The establishment and use of sound engineering principles
1. Johdanto. Ohjelmistotuotannon piirteitä
1. Johdanto Termi Ohjelmistotuotanto (Software Engineering) esiteltiin ensimmäistä kertaa 1968 pidetyssä NATO:n konferenssissa. Termi määriteltiin näin: The establishment and use of sound engineering principles
1. Johdanto. Ohjelmistotuotannon piirteitä. Ohjelmisto ja järjestelmä. Osajärjestelmät ja käyttäjät. Järjestelmän ja ohjelmiston laadinta
1. Johdanto Termi Ohjelmistotuotanto (Software Engineering) esiteltiin ensimmäistä kertaa 1968 pidetyssä NATO:n konferenssissa. Termi määriteltiin näin: The establishment and use of sound engineering principles
1. Johdanto. Ohjelmistotuotannon piirteitä
1. Johdanto Termi Ohjelmistotuotanto (Software Engineering) esiteltiin ensimmäistä kertaa 1968 pidetyssä NATO:n konferenssissa. Termi määriteltiin näin: The establishment and use of sound engineering principles
Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi. Verifiointi- ja validointitekniikat. Verifiointi- ja validointitekniikat II
7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja
1. Johdanto. Ohjelmistotuotannon piirteitä. Ohjelmisto ja järjestelmä. Osajärjestelmät ja käyttäjät. Järjestelmän ja ohjelmiston laadinta
1. Johdanto Termi Ohjelmistotuotanto (Software Engineering) esiteltiin ensimmäistä kertaa 1968 pidetyssä NATO:n konferenssissa. Termi määriteltiin näin: The establishment and use of sound engineering principles
1. Johdanto. Ohjelmistotuotannon piirteitä. Ohjelmisto ja järjestelmä. Osajärjestelmät ja käyttäjät. Järjestelmän ja ohjelmiston laadinta
1. Johdanto Termi Ohjelmistotuotanto (Software Engineering) esiteltiin ensimmäistä kertaa 1968 pidetyssä NATO:n konferenssissa. Termi määriteltiin näin: The establishment and use of sound engineering principles
Ohjelmistotuotanto, prosessit Syksy Ohjelmistotuotantoprosessi. Prosessimalli. Prosessimallien perustehtävät. Prosessimallin vaihejako
2. Ohjelmistotuotantoprosessi peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa
7. Verifiointi ja validointi
7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja
Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit
Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää
Juha Taina, Marko Salmenkivi ja Kjell Lemström,
Hajaantuminen tällä hetkellä ohjelmistotuotantoa kuvaa hajaantuminen ja erikoistuminen perusperiaatteet ovat säilyneet ennallaan, mutta yritykset käyttävät omia räätälöityjä prosessimalleja, menetelmiä
Hajaantuminen. Juha Taina, Marko Salmenkivi ja Kjell Lemstöm, Ohjelmistotuotanto 30
Hajaantuminen tällä hetkellä ohjelmistotuotantoa kuvaa hajaantuminen ja erikoistuminen perusperiaatteet ovat säilyneet ennallaan, mutta yritykset käyttävät omia räätälöityjä prosessimalleja, menetelmiä
Ohjelmistotuotanto, verifiointi ja validointi Syksy Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi
7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja
Copyright by Haikala. Ohjelmistotuotannon osa-alueet
Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary
Johdattelua, motivointia, eli missä ollaan ja kuinka siihen on tultu
Johdattelua, motivointia, eli missä ollaan ja kuinka siihen on tultu 581259 Ohjelmistotuotanto 1 Ohjelmistotuotanto Kuinka valmistaa laadukkaita ja tehokkaita ohjelmistoja mahdollisimman edullisesti? Ohjelmistotuotanto
Juha Taina, Marko Salmenkivi ja Kjell Lemström,
Ohjelmistotuotanto Johdattelua, motivointia, eli missä ollaan ja kuinka siihen on tultu Kuinka valmistaa laadukkaita ja tehokkaita ohjelmistoja mahdollisimman edullisesti? Ohjelmistotuotanto (Software
1. Johdanto. Ohjelmistotuotannon ongelmia
1. Johdanto Mitä ohjelmistotuotanto on? ohjelmointi + ohjelmisto + tekniikat + insinööritaito + kurinalainen työskentely Määritelmä (60-luvun ohjelmistokriisi): The establishment and use of sound principles
Tietojärjestelmän osat
Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto
Dokumentointi ketterissä menetelmissä
Dokumentointi ketterissä menetelmissä Dokumentointi kuuluu ketteriin menetelmiin niin kuin kaikkeen ohjelmistotuotantoon Dokumentointi itsessään yksi vaatimus, jonka prioriteetti pitää arvioida (asiakkaan
4. Vaatimusanalyysi. Vaatimusanalyysin tavoitteet
4. Vaatimusanalyysi Laadukkaiden ohjelmistojen tuottaminen ei ole helppo tehtävä. Sen lisäksi, että ohjelman täytyy toimia virheettömästi, sen täytyy täyttää sille asetetut implisiittiset ja eksplisiittiset
Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus
Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright
Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita
Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita 581259 Ohjelmistotuotanto 378 Lemström, 2006-2011 581259 Ohjelmistotuotanto Kiitos Tuomolle kuvasta 379 Ohjelmistotuotannon perustehtävät projektinhallinta:
TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI
TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa
Implisiittiset vaatimukset. 4. Vaatimusmäärittely. Eksplisiittiset vaatimukset. Vaatimusmäärittelyn tavoitteet. Vaatimusten luonne II
4. Vaatimusmäärittely Implisiittiset vaatimukset Laadukkaiden ohjelmistojen tuottaminen ei ole helppo tehtävä. Jos se olisi helppoa, kaikki tekisivät laadukkaita ja edullisia ohjelmia. Sen lisäksi, että
Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari
4. Vaatimusmäärittely
4. Vaatimusmäärittely Laadukkaiden ohjelmistojen tuottaminen ei ole helppo tehtävä. Jos se olisi helppoa, kaikki tekisivät laadukkaita ja edullisia ohjelmia. Sen lisäksi, että ohjelman täytyy toimia virheettömästi,
Ohjelmistojen testaus
Ohjelmistojen testaus Juha Taina 1. Perusteet (P&Y:1-4) Kurinalainen insinöörityö sisältää suunnittelun ja rakentamisen lisäksi välttämättä tehtäviä, joiden tarkoitus on tunnistaa ja poistaa keskeneräisestä
Software engineering
Software engineering Alkuperäinen määritelmä: Naur P., Randell B. (eds.): Software Engineering: A Report on A Conference Sponsored by the NATO Science Committee, NATO, 1968: The establishment and use of
Verifiointi ja validointi
Verifiointi ja validointi 581259 Ohjelmistotuotanto 170 Verifiointi ja validointi (V & V) V&V:n tavoitteena on varmistaa, että Ohjelmisto vastaa määrityksiä (verifiointi) Ohjelmisto täyttää käyttäjän odotukset
Juha Taina, Marko Salmenkivi ja Kjell Lemström,
Verifiointi ja validointi (V & V) Verifiointi ja validointi V&V:n tavoitteena on varmistaa, että Ohjelmisto vastaa määrityksiä (verifiointi) Ohjelmisto täyttää käyttäjän odotukset (validointi) V&V:ta tehdään
Ohjelmistotekniikka - Luento 2
Ohjelmistotekniikka - Luento 2 Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento 2: Prosessimallit
Ohjelmistotuotanto, vaatimusanalyysi Syksy Vaatimusanalyysi. Implisiittiset vaatimukset. Eksplisiittiset vaatimukset
4. Vaatimusanalyysi Implisiittiset vaatimukset Laadukkaiden ohjelmistojen tuottaminen ei ole helppo tehtävä. Jos se olisi helppoa, kaikki tekisivät laadukkaita ja edullisia ohjelmia. Sen lisäksi, että
Ohjelmistotekniikka - Luento 2 Jouni Lappalainen
Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento
Ohjelmistoprojektien hallinta Vaihejakomallit
Ohjelmistoprojektien hallinta Vaihejakomallit Vaihejakomallit TAVOITE: YMMÄRTÄÄ eri vaihejakomallien etujajahaittoja 2 Erilaisia malleja Tee ja korjaa (Code-and-Fix) Vesiputousmalli (Waterfall) Vesiputousmalli
Laatu tietojärjestelmähankkeissa. Tietohallinnon kokemuksia Juha-Pekka Leskinen Atk-päällikkö Eduskunnan kanslia
Laatu tietojärjestelmähankkeissa Tietohallinnon kokemuksia Juha-Pekka Leskinen Atk-päällikkö Eduskunnan kanslia 5.10.2010 Pohdintaa tietojärjestelmien laadusta Mitä on laatu Miten laatua tavoitellaan tietojärjestelmäprojekteissa
Ohjelmiston testaus ja laatu. Testaustasot
Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu
Ohjelmistojen mallintaminen, mallintaminen ja UML
582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti
Suunnitteluvaihe prosessissa
Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet
Oleelliset vaikeudet OT:ssa 1/2
Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet
Menetelmäraportti Ohjelmakoodin tarkastaminen
Menetelmäraportti Ohjelmakoodin tarkastaminen Sisällysluettelo 1. Johdanto...3 2. Menetelmän kuvaus...4 2.1. Tarkastusprosessi...4 2.1.1. Suunnittelu...4 2.1.2. Esittely...5 2.1.3. Valmistautuminen...5
Katselmoinnit. review) Katselmoinnit (review( Mitä ovat katselmoinnit? Katselmoinnin määritelmä (IEEE 1988)
Katselmoinnit Johdatus ohjelmistotekniikkaan Sami Kollanus 19.10.2004 Katselmoinnin määritelmä (IEEE 1988) An evaluation of software element(s) or projects status to ascertain discrepancies from planned
Testaaminen ohjelmiston kehitysprosessin aikana
Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/
Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1
Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon 31.10.2008 Harri Laine 1 Ohjelmisto Tietokoneohjelma (computer program) toimintaohje, jonka mukaan toimien tietokone suorittaa jonkin tietojenkäsittelytehtävän
Ohjelemistotuotanto, syksy 1998 /Prosessi Prosessimallit
Prosessimallit Prosessimalli on ohjelmiston elinkaaren rakenteen määrittely ts. kuvaus sille millaisten vaiheiden kautta ohjelmisto kehittyy ideasta hautaan mahdollisimman yleisesti sovellettavissa oleva
Harjoitustyön testaus. Juha Taina
Harjoitustyön testaus Juha Taina 1. Johdanto Ohjelman teko on muutakin kuin koodausta. Oleellinen osa on selvittää, että ohjelma toimii oikein. Tätä sanotaan ohjelman validoinniksi. Eräs keino validoida
Tutkittua tietoa. Tutkittua tietoa 1
Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.
Ohjelmistotuotanto, suunnittelu Syksy Suunnittelu. Suunnittelun tulos. Suunnitteluprosessin työvaiheet. Suunnitteluprosessi.
6. Suunnittelu Suunnittelun tulos Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja.
tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004
Tarkastusmenettelyt ja katselmukset tsoft Vesa Tenhunen 4.2.2004 http://cs.joensuu.fi/tsoft/ Johdanto Yksi tärkeimmistä tekijöistä laadukkaiden ohjelmistojen tuottamisessa on puutteiden aikainen havaitseminen
6. Suunnittelu. Suunnittelun tulos
6. Suunnittelu Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja. Tavoitteena on
Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus
LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:
Standardi IEC Ohjelmisto
Sundcon Oy Standardi IEC 61508 3 Ohjelmisto muutokset Matti Sundquist Sundcon Oy www.sundcon.fi Standardi IEC 61508 3 (1) Standardissa di esitetään vaatimukset niiden tietojen ja menettelytapojen valmisteluun,
OT-s200: Prosessimallit
Ohjelmistoprosessi Ohjelmistotuotanto Ohjelmistoprosessi Ohjelmiston elinkaari Ohjelmiston rakentamisen vaiheet ja niiden tulokset Ohjelmiston elinkaaren määrittely Yleisrakenne sille miten ohjelmisto
Ohjelmistojen mallintaminen. Luento 11, 7.12.
Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,
Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA
Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta
Ohjelmistojen mallinnus, s2008 HY/TKTL, 28/10/2008. Harri Laine 1. Ohjelmisto
jen mallinnus, s2008 jen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Tietokoneohjelma (computer program) toimintaohje, jonka mukaan toimien tietokone suorittaa jonkin tietojenkäsittelytehtävän suoritettava
10. Tarkastukset. Tarkastusten rakenne
10. Tarkastukset Tarkastus (inspection) on tehokas analyysitekniikka, jota voidaan käyttää minkä tahansa projektin tuotoksen läpikäyntiin. Tarkastus on systemaattinen ja yksityiskohtainen katselmointi
Tarkastusten rakenne. 10. Tarkastukset. Tuotoksen tekijän rooli. Tarkastustiimi. Tarkastusprosessin vaiheet. Tarkastusprosessi
10. Tarkastukset Tarkastus (inspection) on tehokas analyysitekniikka, jota voidaan käyttää minkä tahansa projektin tuotoksen läpikäyntiin. Tarkastus on systemaattinen ja yksityiskohtainen katselmointi
Kurssin aihepiiri: ohjelmistotuotannon alkeita
Kurssin aihepiiri: ohjelmistotuotannon alkeita [wikipedia]: Ohjelmistotuotanto on yhteisnimitys niille työnteon ja työnjohdon menetelmille, joita käytetään, kun tuotetaan tietokoneohjelmia sekä monista
Testausprosessin vaatimukset. 2. Testausprosessi (Artikkelit) Vesiputousmallin ongelmia. V-mallin neljä osavaihetta. Testausprosessimalli V-malli
2. ausprosessi (Artikkelit) Nykyisin useimpien prosessimallien lähtökohta on, että testaus on oleellinen osa ohjelmistotuotantoprosessia. Itse asiassa huolellinen testaus vie helposti 50% tai enemmän käytettävistä
Tenttikysymykset. + UML- kaavioiden mallintamistehtävät
Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä
Kontrollipolkujen määrä
Testaus Yleistä Testaus on suunnitelmallista virheiden etsimistä Tuotantoprosessissa ohjelmaan jää aina virheitä, käytettävistä menetelmistä huolimatta Hyvät menetelmät, kuten katselmoinnit pienentävät
Convergence of messaging
Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO
Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon
582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta
Ohjelmistoprosessit ja ohjelmistojen laatu kevät Suunnitelmakeskeiset prosessit (lukuisia lähteitä)
6. Suunnitelmakeskeiset prosessit (lukuisia lähteitä) Ennen ketteriä prosessimalleja kehitettyjä prosesseja kutsutaan nykyisin suunnitelmakeskeisiksi (plan-driven) prosesseiksi. Suunnitelmakeskeisyys tarkoittaa,
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
6. Suunnitelmakeskeiset prosessit (lukuisia lähteitä) Ennen ketteriä prosessimalleja kehitettyjä prosesseja kutsutaan nykyisin suunnitelmakeskeisiksi (plan-driven) prosesseiksi. Suunnitelmakeskeisyys tarkoittaa,
Suunnittelun tulos. 6. Suunnittelu. Suunnitteluprosessin työvaiheet. Suunnitteluprosessi. 6.1 Arkkitehtuurisuunnittelu.
6. Suunnittelu Suunnittelun tulos Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja.
Ohjelmistotuotantoprojekti
Ohjelmistotuotantoprojekti Ryhmä Muppett TESTAUSDOKUMENTTI Helsinki 5.8.2008 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ohjelmistotuotantoprojekti, kesä 2008 Projekti: Muutos- ja korjauspyyntöjen
Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Koskelo Helsinki 16.12.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Tom Bertell Johan
Onnistunut SAP-projekti laadunvarmistuksen keinoin
Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.
Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa:
Testaus käsite Sekalaista asiaa Sami Kollanus 15.11.2006 Jos ajatellaan, että = V&V, voidaan erottaa: Staattinen Dynaaminen Toisaalta voidaan määritellä Myersin (1979) mukaan: Testaus on ohjelman suoritusta,
Testaussuunnitelma PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma PULSU Syksy 2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Heikki Manninen Noora Joensuu
Uudelleenkäytön jako kahteen
Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta
Testausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausraportti Orava Helsinki 5.5.2005 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Juhani Bergström Peter
TIE Tietorakenteet ja algoritmit 1. TIE Tietorakenteet ja algoritmit
TIE-20100 Tietorakenteet ja algoritmit 1 TIE-20100 Tietorakenteet ja algoritmit TIE-20100 Tietorakenteet ja algoritmit 2 Lähteet Luentomoniste pohjautuu vahvasti prof. Antti Valmarin vanhaan luentomonisteeseen
Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!
Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! eli... Hyvä kaava sanoo enemmän kuin,... tuhat riviä koodia!... sata riviä tekstiä!... kymmenen diagrammia! YLEISTÄ FORMAALEISTA
Testaussuunnitelma Labra
Testaussuunnitelma Labra Helsinki 25.8.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 1 Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op) Projektiryhmä Anssi Kapanen,
Ohjelmiston toteutussuunnitelma
Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,
Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori
Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita
Projektisuunnitelma. KotKot. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Projektisuunnitelma KotKot Helsinki 22.9.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 + 1 op) Projektiryhmä Tuomas Puikkonen
Onnistunut Vaatimuspohjainen Testaus
Onnistunut Vaatimuspohjainen Testaus Kari Alho Solution Architect Nohau Solutions, Finland Sisältö Mitä on vaatimuspohjainen testaus? Vaatimusten ymmärtämisen haasteet Testitapausten generointi Työkalujen
Testaussuunnitelma. PUSU-ryhmä. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma PUSU-ryhmä Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Jussi Hynninen
5. Järjestelmämallit. Mallinnus
5. Järjestelmämallit Käyttäjävaatimukset pitää kirjoittaa luonnollisella kielellä. Niitä lukevat myös asiakkaat ja loppukäyttäjät. Järjestelmävaatimukset kannattaa kirjoittaa jollain rakenteisella kuvaustavalla.
Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia
Ohjelmistojen mallintaminen, kurssikoe 15.12. esimerkkivastauksia Tehtävä 1 a: Ohjelmistotuotantoprosessi sisältää yleensä aina seuraavat vaiheet: määrittely, suunnittelu, toteutus, testaus ja ylläpito.
Ohjelmistotuotanto s
Laadunvarmistustekniikoita Ohjelmistotuotanto 1 testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia dokumentin (voi olla
Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu
Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu
Projektityö
Projektityö 21.10.2005 Projektisuunnitelma Työn ositus Projektisuunnitelman sisältö Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: tp@cs.uta.fi, työhuone: B1042) Kurssin kotisivut:
Mallinnus. 5. Järjestelmämallit. Abstraktiot. Mallinnuksen etuja. Arkkitehtuurimalli. Yhteysmallit. Ohjelmistotuotanto, järjestelmämallit Kevät 2005
5. Järjestelmämallit Käyttäjävaatimukset pitää kirjoittaa luonnollisella kielellä. Niitä lukevat myös asiakkaat ja loppukäyttäjät. Järjestelmävaatimukset kannattaa kirjoittaa jollain rakenteisella kuvaustavalla.
Arkkitehtuurien tutkimus Outi Räihä. OHJ-3200 Ohjelmistoarkkitehtuurit. Darwin-projekti. Johdanto
OHJ-3200 Ohjelmistoarkkitehtuurit 1 Arkkitehtuurien tutkimus Outi Räihä 2 Darwin-projekti Darwin-projekti: Akatemian rahoitus 2009-2011 Arkkitehtuurisuunnittelu etsintäongelmana Geneettiset algoritmit
Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op)
581361 Ohjelmistoprosessit ja ohjelmistojen laatu (4op) Ohjelmistojärjestelmien syventävien opintojen kurssi Myös ohjelmistotekniikan profiilin pakollinen kurssi eli ohjelmistotekniikka-aiheisen gradun
Katselmoinnin määritelmä. Katselmoinnit osa 1. ja vielä ajatuksia katselmoinneista. Katselmointi. Katselmointi, katselmus (review) IEEE Std
Katselmoinnin määritelmä Katselmoinnit osa 1 Sami Kollanus 1.12.2006, katselmus (review) IEEE Std 1028-1988 Ohjelmiston osien tai projektin tilan arviointi (evaluation), jonka tarkoitus on tunnistaa tuotosten
6. Suunnittelu. Suunnitteluprosessi
6. Suunnittelu Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja. Tavoitteena on
Luku 8 Rakennusvaihe. Detailed Design. Programming. Moduulisuunnittelu. Ohjelmointi
Luku 8 Rakennusvaihe Moduulisuunnittelu Detailed Design Programming Ohjelmointi Teknisen Complete suunnittelun Technical viimeistely Design Suunnittelukatselmuksen Design Perform suorittaminen Review Yhteisen
T Johdatus käyttäjäkeskeiseen tuotekehitykseen. suunnitteluprosessissa. Käyttäjän huomiointi. Iteroitu versio paljon kirjoitusvirheitä
Käyttäjäkeskeinen suunnittelu Käyttäjän huomiointi suunnitteluprosessissa Iteroitu versio 1.1 muutettu klo12.10 - paljon kirjoitusvirheitä Käyttäjäkeskeinen suunnittelu Perusidea: käyttäjät huomioidaan
Käyttäjäkeskeinen suunnittelu
Käyttäjäkeskeinen suunnittelu Käyttäjän huomiointi suunnitteluprosessissa Iteroitu versio 1.1 muutettu klo12.10 - paljon kirjoitusvirheitä Käyttäjäkeskeinen suunnittelu Perusidea: käyttäjät huomioidaan
T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tästä dokumentista ilmenee T1-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 1.12.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi
Ohjelmistojen mallintaminen, kesä 2009
582104 Ohjelmistojen mallintaminen, kesä 2009 1 Ohjelmistojen mallintaminen Software Modeling Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön tuntemus Ohjelmoinnin
Johdantoluento. Ohjelmien ylläpito
Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito