Ohjelmistotuotanto

Koko: px
Aloita esitys sivulta:

Download "Ohjelmistotuotanto"

Transkriptio

1 Ohjelmistotuotanto Juha Taina Helsingin yliopisto Tietojenkäsittelytieteen laitos 1. Johdanto Mitä on ohjelmistotuotanto? Ohjelmisto, ohjelmointi, tekniikkaa, insinööritaitoa, kurinalaisuutta, systemaattisia menetelmiä. Alkuperäinen määritelmä: P. Naur, R. Randell (eds.): Sofware Engineering: A Report on a Conference Sponsored by the NATO Science Committee. Nato, 1968: The establishement and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. Synty-ympäristö 60-luvun ohjelmistokriisi: miten pystytään täyttämään yhä lisääntyvä ohjelmistokysyntä. Sivu - 2-1

2 Ohjelmistotuotannon ongelmia Ohjelmistojen koon ja monimutkaisuuden jatkuva kasvu. Yhä vaikeampia ongelmia ratkotaan tieto- ja ohjelmistoteknisin keinoin. Yli 10 miljoonan koodirivin isot ohjelmat yleistyvät jatkuvasti. Tuotantoprosessin määrittely ja mittaaminen. On vaikeaa hallita prosessia, jos sitä ei voida mitata. Liikaa taidetta, liian vähän raakaa työtä. Tuotteen määrittely Asiakas ei tiedä mitä haluaa. Tieteellisten menetelmien puute. Sivu Ongelmat jatkuvat Tuotteen laadun tai toimivuuden varmistus. Formaali määrittely on vaikeaa. Täysin kattava testaus on mahdotonta. Jälkihoidon raskaus. Usein ylläpitokustannukset ovat huomattavasti suuremmat kuin kehityskustannukset. Etukäteisarviointi. Projektin vaatiman työmäärän arviointi onnistuu liian harvoin. Teorian puuttuminen. Tieteellisen pohjan puuttuminen. Ohjelmistotuotanto perustuu enemmän hyväksi havaittuihin menetelmiin kuin eksaktiin tieteeseen. Sivu - 4-2

3 Ongelmista ei päästä vieläkään eroon Standardiosien puute. Vain pieni osa (10-20%) kirjoitettavasta koodista on todella uutta. Kaikki muu on joskus kirjoitettu jossain. Tieteellisen tutkimustyön ja käytännön tuotantotyön välinen kuilu. Usein tieteellinen tutkimusongelma ei kohtaa käytännön ongelmaa. Tieteelliset tulokset sopivat usein tarkasti yhteen tiettyyn pienehköön ongelmaan. Yrityksissä ei tunneta uutta tutkimusta. Yritysten ratkaisut ovat teknologiakeskeisiä. Yritykset eivät pitkäjännitteisesti ratko ohjelmistotuotannon perusongelmia. Sivu Kysy ohjelmistotuotannosta Mikä on ohjelmisto? Toisiinsa sidoksissa olevat tietokoneohjelmat, niiden dokumentaatio ja käytetyt konfigurointitiedostot. Mitä on ohjelmistotuotanto? Kaikkiin ohjelmiston tuotannon osa-alueisiin vaikuttavaa insinööritaitoa ja -toimintaa (Sommerville, vapaa käännös). Myös alkuperäinen -68 annettu määritelmä on varsin hyvä. Onko ohjelmistotuotanto tiedettä? Tästä käydään jatkuvaa kädenvääntöä. Ohjelmistotuotannossa on paljon tiedettä, mutta on myös alueita, jotka eivät perustu esitettyihin todennettaviin teorioihin vaan käytännössä hyviksi koettuihin menetelmiin. Toistaiseksi ohjelmistotuotanto on (valitettavasti) enemmän insinöörityötä kuin tiedettä. Sivu - 6-3

4 Kysy lisää ohjelmistotuotannosta Mikä on ohjelmistotuotantoprosessi? Joukko toimintoja, joiden tarkoituksena on ohjelmiston kehittäminen tai ylläpito. Mikä on ohjelmistotuotannon prosessimalli? Yksinkertaistettu esitys ohjelmistotuotantoprosessista. Mallissa keskitytään suuriin kokonaisuuksiin yksityiskohtien kustannuksella. Miten ohjelmistotuotannon kustannukset jakautuvat? 60% kehitystyötä, 40% testausta (arvio). Ylläpitokustannukset saattavat helposti ylittää tuotantokustannukset. Lisää kysymyksiä: Sommerville luku 1.1 Sivu Järjestelmäsuunnittelu Järjestelmäsuunnittelu (system engineering - huono käännös) käsittelee järjestelmiä kokonaisuuksina. Järjestelmä on joukko toisiinsa liittyviä komponentteja, jotka toteuttavat yhdessä ennalta määritellyn toiminnallisuuden. Järjestelmään kuuluu yleensä ainakin laitteisto- ja ohjelmistokomponentteja, käyttäjiä ja käyttöympäristö. Järjestelmäsuunnittelu käsittelee järjestelmien määrittelyä, suunnittelua, toteutusta, käyttöönottoa ja käytettävyyttä. Sivu - 8-4

5 Järjestelmäsuunnittelu: so what? Miksi ohjelmistotuotannossa pitää tietää järjestelmäsuunnittelusta? Koska ohjelmistotekniikan asiantuntijoiden täytyy ymmärtää koko järjestelmän toiminta voidakseen tuottaa laadukkaita ohjelmistoja. Koska useista ohjelmistotekniikan asiantuntijoista tulee yrityksissä koko järjestelmän asiantuntijoita. Koska ohjelmisto on erottamaton osa (ohjelmistopohjaista) järjestelmää. Kurssin kannalta kiinnostavimpia järjestelmiä ovat tietokonepohjaiset järjestelmät, sillä ne usein sisältävät yllättävänkin suuria ohjelmistoja. Ei ole ohjelmistoa ilman sen sisältämää järjestelmää. Sivu Osajärjestelmät Järjestelmäsuunnittelussa järjestelmä jaetaan usein osajärjestelmiin. Jokainen osajärjestelmä on itsenäinen kokonaisuus, joka toimii yhteistyössä muiden osajärjestelmien kanssa. Jokainen osajärjestelmä voidaan jakaa edelleen ohjelmisto- ja laitteistokomponentteihin. Nämä komponentit puolestaan toimivat yhteistyössä täyttääkseen osajärjestelmien tehtävät. Käyttäjät ovat osa järjestelmää käyttäessään järjestelmän toimintoja osajärjestelmien kautta. Sivu

6 Järjestelmät ja ympäristö Järjestelmät eivät toimi yksin, vaan ne toimivat ja vaikuttavat jossain ympäristössä. Esimerkiksi käyttäjille uuden järjestelmän käyttöönotto voi vaikuttaa toimintatapoihin: käyttö saattaa erota vanhan järjestelmän käytöstä. Tarvitaan käyttökoulutusta. työtehtäviin: järjestelmä saattaa luoda uusia työtehtäviä ja tehdä joistain vanhoista turhia. Tarvitaan organisaation sisäisiä työtehtävien järjestelyä. organisaatioon: uuden järjestelmän järjestelmäasiantuntijat saattavat saada lisää vaikutusmahdollisuuksia. Muutos voi olla suuri, ja siihen pitää varautua. Sivu Järjestelmäsuunnitteluprosessi Uutta järjestelmää kehitettäessä tai vanhaa parannettaessa tarvitaan kehys, minkä mukaan voidaan rakentaa varsinainen projektisuunnitelma. Tämä kehys, järjestelmäsuunnitteluprosessi, sisältää seuraavat työvaiheet: 1. Vaatimusten määrittely 2. Koko järjestelmän suunnittelu 3. Osajärjestelmien kehitystyö 4. Järjestelmän integrointi 5. Järjestelmän asennus 6. Järjestelmän ylläpito 7. Järjestelmän alasajo Sivu

7 Järjestelmäsuunnitteluprosessi - osa II Näyttääkö tutulta? Aivan, tämä muistuttaa suuresti perinteistä ohjelmistotuotannon vesiputousmallia Itse asiassa vesiputousmalli on saanut paljon vaikutteita huomattavasti vanhemmasta järjestelmäsuunnitteluprosessista. Erojakin toki on: Eri insinöörialoilla on oma sanastonsa, periaatteensa ja standardinsa. Järjestelmäsuunnittelussa on suuri riski siinä, että eli osajärjestelmien asiantuntijat eivät ymmärrä toisiaan. Muutokset ovat kalliita. Jostain riippusillasta ei tuosta vaan rakenneta prototyyppiä, mikä sitten voidaan heittää menemään. Kun jokin suunnittelupäätös on tehty, siinä myös pysytään. Sivu Järjestelmäsuunnittelun menetelmät Järjestelmäsuunnittelussa voidaan käyttää samoja menetelmiä kuin ohjelmistotuotannossa. Vai meneekö tämä päin vastoin? Ohjelmistotuotannossa voidaan käyttää samoja menetelmiä kuin järjestelmäsuunnittelussa. Joka tapauksessa jatkossa esiteltävät menetelmät sopivat sellaisenaan tai soveltuvin osin myös järjestelmäsuunnitteluun. Esimerkiksi koko järjestelmä on järkevää kuvata kaaviolla, joka sisältää osajärjestelmät ja niiden väliset yhteistyötavat. Sivu

8 Esimerkkijärjestelmä (Sommerville) Radar system Transponder system Data comms. system Aircraft comms. Telephone system Position processor Backup position processor Comms. processor Backup comms. processor Aircraft simulation system Flight plan database Air Traffic Control system architecture Weather map system Accounting system Controller info. system Controller consoles Kuvalla (C) I. Sommerville 2000 Activity logging system Sivu Se järjestelmäsuunnittelusta Järjestelmäsuunnittelu on hankalaa. Sen lisäksi, että ohjelmiston on sovittava järjestelmään, myös osajärjestelmien on sovittava yhteen. Ohjelmistoa pidetään usein syntipukkina ongelmiin, vaikka syyt saattavat olla huonossa järjestelmäsuunnittelussa. Ohjelmistoasiantuntijoilla ei ole hyviä vastauksia järjestelmäsuunnittelun vaikeisiin kysymyksiin. Vähin, mitä voidaan vaatia, on että ohjelmistotuotannossa otetaan ympäröivä järjestelmä mahdollisimman hyvin huomioon. Sivu

9 2. Ohjelmistotuotantoprosessit Ohjelmistotuotantoprosessin systematisoimiseksi on kehitetty lukuisia prosessimalleja. Malli = mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen. Malli ei tarjoa konkreettisia yksityiskohtaisia toimintasääntöjä, vaan se on pelkän yleisperiaatteen kuvaus. Malli on käytettävissä eri organisaatioissa ja sovellusalueilla. Nykyisin käytännössä jokaisella itseään kunnioittavalla ohjelmistoja tuottavalla yrityksellä on oma prosessimalli. Nämä yrityskohtaiset prosessimallit yleensä perustuvat johonkin tässä luvussa esitellyistä yleisistä prosessimalleista. Sivu Prosessimallien perustehtävät Vaikka prosessimalleja on lukuisia, niillä kaikilla on yhteisiä perustehtäviä. Näitä ovat: Ohjelmiston määrittely. Ohjelmistolle asetetut vaatimukset ja ohjelmistoon liittyvät rajoitukset on selvitettävä. Ohjelmiston suunnittelu ja toteutus. Määrittelyn mukainen ohjelmisto pitää saattaa suoritettavaan kuntoon. Ohjelmiston verifiointi ja validointi. Verifiointi tarkastaa, että ohjelmisto toimii virheettömästi. Validointi tarkastaa, että ohjelmisto toteuttaa sille määrittelyssä asetetut vaatimukset. Ohjelmiston ylläpito. Ohjelmisto muuttuu elinkaarensa aikana, kun ohjelmiston käyttäjien vaatimukset, käyttöympäristö ja laitteisto muuttuvat. Sivu

10 Prosessimallin vaihejako Jokainen prosessi on jaettavissa osavaiheisiin, joilla on ennalta määrätty suoritusjärjestys. Vaihejaossa jokainen osavaihe tuottaa määritellyn tuloksen, osavaiheen tulos toimii syötteenä seuraavalle osavaiheelle, osatulokset ohjaavat seuraavan osavaiheen suoritusta, osavaiheiden tulokset ovat jollain määritellyillä kriteereillä hyväksyttävissä/hylättävissä ja jokaisen osavaiheen alku ja loppu ovat selvästi havaittavissa Käytännössä prosessi on aina iteratiivinen. Yhtä tulosta tarkennetaan, siirrytään seuraavaan, palataan takaisin edelliseen jne. Sivu Vesiputousmalli Vesiputousmalli on vanhin julkaistu ohjelmistotuotannon prosessimalli. Sen juuret ovat vahvasti systeemisuunnittelussa. Vesiputousmallin lähestymistapa on lineaarinen. Jo päätettyyn työvaiheeseen ei enää palata myöhemmin. Jokainen työvaihe on saatettava päätökseen ja tulokset on hyväksyttävä ja jäädytettävä ennen seuraavaan työvaiheeseen siirtymistä. Prosessimallien perustehtävät muodostavat vesiputousmallin työvaiheet. Sivu

11 Vesiputousmallin työvaiheet 1. Vaatimusten kartoitus ja vaatimusanalyysi Järjestelmän tarjoavat palvelut, rajoitukset ja tavoitteet selvitetään. Vaatimuksien perusteella tehdään ohjelmistosta yksi tai useampi malli, joita käytetään vaatimusten järkevyyden tarkistukseen. 2. Suunnittelu Vaatimusanalyysista saatu mallia tarkennetaan, jolloin järjestelmästä tarkentuvat osajärjestelmät ja niiden välinen yhteistyö. Jokainen osajärjestelmä tarkennetaan halutulle abstraktiotasolle asti. 3. Toteutus ja yksikkötestaus Suunnitelma toteutetaan yhdellä tai useammalla ohjelmointikielellä. Aina yhden jakamattoman osan toteutuksen jälkeen se testataan yksikkötestauksen menetelmin. Sivu Vesiputousmallin työvaiheet - II 4. Integrointi- ja järjestelmätestaus Yksittäiset ohjelman osat integroidaan osajärjestelmiksi, minkä jälkeen osajärjestelmät integroidaan valmiiksi järjestelmäksi. Samalla suoritetaan integrointitestausta, millä varmistetaan rajapintojen toimivuus. Integrointitestauksen jälkeen koko järjestelmä verifioidaan (selvitetään, että se toimii) ja validoidaan (selvitetään, että se tekee mitä halutaan). 5. Ylläpito Ohjelmisto otetaan käyttöön ja sen käyttöä valvotaan. Ongelmatapauksissa ja vaatimusten muuttuessa ohjelmistosta voidaan tehdä korjattuja/uusia versioita, jolloin ylläpitovaihe vaikuttaa kaikkiin aikaisempiin työvaiheisiin. Malli perustuu vahvasti hyvään dokumentaatioon. Sivu

12 Vesiputousmallin työvaiheet Vaatimusanalyysi Suunnittelu Toteutus Testaus Ylläpito Dokumentointi Sivu Prototyyppimalli Prototyyppimallissa (tai Sommervillen mukaan Evoluutiokehitysmallissa, Evolutionary development) ohjelmisto kehitetään iteratiivisesti vaiheittain. Ensin tuotetaan yksikertainen prototyyppi mahdollisimman nopeasti. Asiakas arvioi proton, ja arvion perusteella suunnitellaan seuraava versio. Prosessia jatketaan, kunnes ollaan saatu viimeisellä iteraatiolla lopullinen versio. Ensimmäiset prototyypit sisältävät sellaisia osia, jotka ovat näkyvissä käyttäjille. Toteutus voi olla aluksi hyvin kevyttä. Käyttöliittymä on alusta asti mukana. Sivu

13 Prototyyppimallin ihmeitä Usein prototyyppimallissa ei käytetä selkeää tehtävien vaihejakoa. Protoa kehitettäessä saatetaan olla samanaikaisesti määrittely-, suunnittelu- ja toteutusvaiheessa. Asiakas on jatkuvasti mukana prosessissa. Seuraavan iteraatiokierroksen prototyyppi tehdään asiakkaan palautteen ja jatketun vaatimusanalyysin perusteella. Usein prototyyppimallin vaatimuksena on jonkinlainen alaan sopiva sovelluskehitin. Muuten yhteen iteraatioon kuluu liikaa aikaa. Sovelluskehitin saatetaan toteuttaa projektin yhteydessä. Sivu Mitä tehdä prototyypille? Edellisen kierroksen prototyyppi voidaan joko hylätä, jolloin tarkoituksena on ollut tarkentaa prototyypin avulla asiakkaan ohjelmistolle asettamia toiveita ja vaatimuksia tai kehittää seuraavan kierroksen prototyypiksi, jolloin prototyypin tarkoituksena on ollut esitellä asiakkaalle ydinohjelmisto tai jokin ydinohjelmistoon liitetty aputoiminto. Asiakkaalle voi olla vaikeaa ymmärtää, miksi täysin toimiva prototyyppi ei vielä kelpaa lopputuotteeksi tai jalostettavaksi. Prototyyppiä on nimensä mukaisesti esitoteutus. Se ei vielä täytä laadukkaalle ohjelmistolle asetettavia vaatimuksia. Sivu

14 Prototyyppimallin työvaiheet Määrittely 1. Proto Yleiskuvaus Kehitystyö Väliproto Väliproto Validointi Valmis tuote Sivu Formaalit menetelmät Formaaleissa menetelmissä ohjelmisto kehitetään pitkälti samaan tapaan kuin vesiputousmallissa. Menetelmien ero on siinä, että formaaleissa menetelmissä kehitetään jokin matemaattinen malli, jonka avulla määritelty ongelma muunnetaan ongelman ratkaisevaksi ohjelmaksi. Muunnoksia voi olla useita. Tällöin yksi malli tekee muunnoksen välimuotoon, seuraava muuntaa välimuotoa jne. Jos sopiva formalismi löydetään, menetelmä on ylivertainen kaikkiin muihin menetelmiin verrattuna. Sivu

15 Formaalit menetelmät jatkuvat Mallien avulla ohjelma voidaan todistaa oikeaksi. Todistus tehdään osoittamalla taaksepäin ohjelmasta lähtien, että kukin saavutetun tason tulos vastaa yksikäsitteisesti lähtötason syötettä. Valitettavasti sopivia malleja on vähän ja niiden käyttö on rajoittunut pienille hyvin määritellyille ongelma-alueille. Uuden mallin kehitystyö on kallista eikä usein onnistu. Harvalla ohjelmistotekniikan ammattilaisella on riittävästi valmiutta kehitystyöhön. Mallia on vaikeaa selittää asiakkaalle. Sivu Iteratiiviset mallit Ideaalimaailmassa ohjelmistolle asetettavat vaatimukset ovat selkeät eivätkä muutu projektin aikana. Todellisuudessa tämä ei toteudu koskaan. Kaikissa todellisissa prosesseissa on iteratiivisuutta. Työvaiheissa joudutaan palaamaan edellisiin vaiheisiin sitä mukaa kun järjestelmälle asetettavat vaatimukset muuttuvat. Onneksi kaikkiin listattuihin malleihin voidaan lisätä iteratiivisia piirteitä. Sivu

16 Lisäävä malli Lisäävässä mallissa (Incremental development) ohjelmisto jaetaan erillisiin osiin, jotka toteutetaan sykleissä. Jokainen sykli voidaan toteuttaa esimerkiksi vesiputousmallin mukaan. Vaatimusanalyysissa keskitytään vain kyseisen syklin vaatimiin vaatimuksiin. Ensimmäisellä syklillä rakennetaan ohjelmiston ydin, johon seuraavien syklien tulokset voidaan liittää. Jokaisella syklillä voi olla oma prosessimalli tarpeen mukaan. Sivu Lisäävän mallin luonteesta Lisäävä malli pyrkii hyödyntämään sekä vesiputousmallin että prototyyppimallin parhaat puolet. Tuote voidaan määritellä sellaiseksi, että ydinohjelmistossa ovat tärkeimmät vaatimukset, kun taas myöhemmissä sykleissä vaatimusten prioriteetti pienenee. Jokaisen syklin kohdalla syklissä toteutettavat vaatimukset kiinnitetään samaan tapaan kuin vesiputousmallissa. Toteuttamattomien syklien vaatimukset voivat muuttua. Sivu

17 Extreme programming Extreme programming (XP) kehitettiin 1990-luvun loppupuolella. Malli on erittäin kevyt lisäävä prosessimalli. XP perustuu ajatukseen, että ohjelma on mahdollista kehittää hyvin pienillä lisäyksillä. Ydinohjelman toteutuksen jälkeen jokaisella syklillä lisätään mahdollisimman pieni järkevä kokonaisuus ominaisuuksia. Vastaavasti projektia suunnitellaan vain mahdollisimman lyhyt aika eteenpäin. Projektin dokumentaatio on pääosin pelkkää koodia. Sivu Extreme programming piirteitä XP perustuu seuraaviin asioihin: Lyhyt sykli. Jokaisen uuden version pitää olla mahdollisimman pieni. Versioon toteutetaan loogisesti yhtenäiset ominaisuudet, mutta ei mitään muuta. Kuvaus. Tämä vastaa XP:ssa arkkitehtuurikuvausta. Se kertoo, miten järjestelmän tulisi toimia. Yksinkertainen suunnittelu. Toteutus on aina kevyin mahdollinen. Testaus. Toteutuksessa XP:ssa rakennetaan ensin testitapaukset, jotka toteutettavan koodin tulee läpäistä. Testaus automatisoidaan: kirjoitetut testit voidaan suorittaa automaattisesti uudelleen. Refaktorointi. XP:ssa jo tehtyä koodia pyritään korjaamaan jatkuvasti uusien vaatimusten mukaiseksi tai paremmin ylläpidettäväksi. Sivu

18 XP:n piirteet jatkuvat Lisää piirteitä: Pariohjelmointi. XP:ssa koodi kirjoitetaan aina pareittain. Toinen kirjoittaa koodia ja toinen miettii parasta tapaa toteuttaa ratkaistava ongelma. Yhteinen koodi. XP:ssa koodilla ei ole omistajaa. Jokaisella on oikeus ja velvollisuus korjata toisten ratkaisuja. Jatkuva integrointi. Kirjoitettu uusi koodi liitetään kehitysversioon saman tien. 40-tuntinen työviikko. Tämä on tosiaan XP:n vaatimuksissa. Läsnäoleva asiakas. XP:ssa asiakas on jatkuvasti mukana projektiryhmässä. Koodausstandardit. Tavoitteena on, että kirjoitettu koodi näyttää yhtenäiseltä (eli tyylierot eivät tule näkyville). Sivu Spiraalimalli Spriaalimallissa prosessi esitetään spiraalina. Jokainen spiraalin silmukka esittää yhtä prosessin työvaihetta. Spiraalimallin silmukka jakautuu neljään sektoriin: Tehtäväasetus. Silmukan tavoite ja aikataulu asetetaan. Riskianalyysi. Silmukkaan liittyvät riskit tunnistetaan, analysoidaan ja priorisoidaan. Tärkeiksi luokitelluille riskeille mietitään vastatoimia. Kehitystyö ja validointi. Työvaihe toteutetaan ja validoidaan sopivilla menetelmillä ja prosessimalleilla. Syklin suunnittelu. Lopputulos arvioidaan ja pätetään jatkosta (eli seuraavasta syklistä). Sivu

19 Spiraalimalli Spiraalimalli ei määrittele kiinteitä tehtäviä, vaan käyttää syklien sektoreissa muita prosessimalleja tai niiden osia. Yksi sykli voi esimerkiksi käsitellä yksinomaan vaatimusanalyysia, jolloin käytettävä prosessi on vaatimusanalyysin prosessi. Toisaalta sykli voi olla yhden prototyypin teko, jolloin käytettävä prosessi voi vaikkapa perustua vesiputousmalliin. Spiraalimallia voidaan käyttää myös ohjelmiston ylläpitoon. Tällöin yksi sykli tarkoittaa uuden ohjelmiston version tuottamista. Sivu Spiraalimalliesimerkki Determine objectives alternatives and constraints Plan next phase Kuvalla (C) I. Sommerville 2000 REVIEW Requirements plan Life-cycle plan Development plan Integration and test plan Risk analysis Risk analysis Risk analysis Prototype 2 Risk analysis Prototype 1 Concept of Operation S/W requirements Requirement validation Design V&V Service Acceptance test Evaluate alternatives identify, resolve risks Prototype 3 Operational protoype Simulations, models, benchmarks Product design Integration test Code Unit test Detailed design Develop, verify next-level product Sivu

20 3. Ohjelmistotuotantoprojektin ohjaus Ohjelmistotuotannon alkuaikoina ja luvuilla törmättiin ohjelmistokriisiin. Ohjelmistojen koko kasvoi. Ohjelmistot toimitettiin myöhässä. Ohjelmistot olivat heikkolaatuisia. Ohjelmistotuotantoprojektien budjetit ylitettiin roimasti. Tuotettujen ohjelmistojen tehokkuudessa oli toivomisen varaa jne. Projektit pettivät, koska niiden hallintaan käytettiin muista insinööritieteistä lainattuja menetelmiä. Ohjelmistotuotanto eroaa kuitenkin selvästi muista insinööritieteistä. Ohjelmistolla ei ole fyysistä olemusta, jokaiselle tuotteelle on omat prosessiin vaikuttavat vaatimukset, tuotteiden vertailukohtia ei välttämättä löydy jne. Sivu Projektipäällikkö Kuten muissakin insinööritieteissä, myös ohjelmistotuotannossa projektia johtaa projektipäällikkö (software manager). Projektipäällikkö vastaa projektista ja sen valmistumisesta ajallaan budjetin mukaan. Projektipäällikön tehtävät vaihtelevat yrityksittäin ja projekteittain. Pääasiassa vastuun lisäksi projektipäällikkö toimii projektin teknisenä asiantuntijana sekä kanavana projektin johtoryhmän ja projektiin osallistujien välillä. Johtoryhmä seuraa projektin etenemistä. Sivu

21 Projektipäällikön vastuualueet Yleensä projektipäällikön vastuulla on seuraavaa: Tehtäväkuvauksen laadinta: kuvaus selvittää projektin tavoitteet ja yleissuunnitelman tavoitteiden saavuttamiseksi. projektisuunnitelman ylläpito: projektisuunnitelma kertoo projektin työvaiheet, tarkistuspisteet ja toimitettavat tuotokset. ja niille lasketut ajat. Aikataulun ylläpito: aikataulu on osa projektisuunnitelmaa. Se kertoo työvaiheiden suunnitellut toteutusajat ja työvaiheisiin osallistuvat henkilöt. Projektin kustannusarvio: kustannusarvion teon apuna voidaan käyttää jo päättyneitä vastaavia projekteja. Sivu Vastuualueet jatkuvat Projektin seuranta ja tarkastukset: projektia seurataan säännöllisesti sekä aikataulun että tuotteen laadun mukaan. Tarkastuksissa katsastetaan projektin eteneminen tai jokin projektin tuotoksista. Työntekijöiden valinta ja arviointi: tavoitteena on jokainen työntekijä omia erikoistaitojaan vastaaviin tehtäviin. Raportointi: projektipäällikkö raportoi säännöllisin väliajoin projektin edistymisestä johtoryhmälle. Kaikissa yrityksissä ja projekteissa ei ole johtoryhmää. Tällöin raportointi tehdään yleensä projektin johtajalle, joka on vastuussa useasta samaan aikaan käynnissä olevasta projektista. Luonnollisesti projektipäällikön vastuualueet saattavat jakaantua usean projektin jäsenen kesken. Sivu

22 3.2. Projektin suunnittelu Jotta projektia voidaan ohjata, tarvitaan kehys, jonka mukaan projekti etenee. Kehys, eli projektisuunnitelma on projektin tärkein dokumentti. Se tehdään ennen varsinaisia projektin työvaiheita. Projektin etenemistä seurataan projektisuunnitelman avulla. Tarvittaessa projektisuunnitelmaa päivitetään ja täydennetään, kun projekti etenee. Projektisuunnitelma antaa mahdollisuudet saada projekti valmiiksi ajoissa ja keinot huomata aikataulusta lipsumiset mahdollisimman pian. Sivu Projektin seuranta Projektia seurataan Sommervillen mukaan seuraavan pseudokoodin tapaan: 1. Selvitetään projektin rajat (aikarajat, henkilöt, budjetti jne.) 2. Selvitetään projektin yleiset parametrit (rakenne, koko, ym.) 3. Määritellään projektin tarkistuspisteet ja tuotokset 4. Toistetaan vaiheita 5-12 kunnes projekti on päättynyt tai keskeytetty: 5. Tehdään aikataulu 6. Sijoitetaan tehtävät ja henkilöt aikatauluun 7. Annetaan projektiryhmän toimia aikataulun ja tehtäväjaon mukaan 8. Tarkistetaan projektin eteneminen 9. Muutetaan tarvittaessa projektin parametreja 10. Päivitetään tarvittaessa aikataulua 11. Neuvotellaan tarvittaessa päivityksistä projektin rajoihin ja tuotoksiin 12. Jos onglemia ilmenee, pidetään tekninen tarkastus prosessista ja mahdollisesti kirjoitetaan uusi versio projektisuunnitelmasta Sivu

23 3.3. Projektisuunnitelma Projektisuunnitelma sisältää vähintään välttämättömät tiedot projektin etenemiseksi ja seuraamiseksi. Lisäksi se saattaa sisältää laaduntarkkailusuunnitelman: miten projektissa varmistetaan, että valmistettava tuote on riittävän laadukas, validointisuunnitelman: miten tehdyn järjestelmän ja vaatimusten yhtenäisyys varmistetaan, versionhallintasuunnitelman: miten tehtävän ohjelmiston eri versiota hallitaan, ylläpitosuunnitelman: mitä ylläpitoa ohjelmisto tarvitsee valmistumisensa jälkeen ja miten ylläpitopalvelut hoidetaan, ja koulutussuunnitelman: miten projektiin osallistuvien koulutus hoidetaan. Sivu Projektisuunnitelma (jatkuu) Yleensä edellisellä kalvolla listatut suunnitelmat ovat erillisiä dokumentteja. Tällöin projektisuunnitelmaan jäävät pelkästään projektin työvaiheisiin, tehtäviin ja aikatauluun vaikuttavat kohdat. Projektisuunnitelmaa päivitetään koko projektin kestoajan. Jotkut osat projektisuunnitelmasta, kuten aikataulun yksityiskohdat, saattavat muuttua tiheään. Niinpä dokumentti kannattaa laatia sellaiseksi, että muuttuvien osien päivitys on suoraviivaista eikä vaadi pysyvämpien osien päivittämistä. Sivu

24 Projektisuunnitelman rakenne Projektisuunnitelma sisältää yleensä ainakin seuraavat osat: 1. Johdanto Selvittää lyhyesti projektin tavoitteet ja listaa budjetin, ajoituksen, henkilöresurssien ym. ylärajat. Johdanto antaa projektille rakenteen ja rajoitukset, joihin projektisuunnitelma perustuu. 2. Projektiorganisaatio Selvittää projektiin osallistuvat henkilöt, heidän roolinsa ja mahdollisesti heidän erityisosaamisensa. 3. Riskianalyysi Selvittää mahdolliset projektin riskit, arvioi riskien todennäköisyyden, määrittelee riskin vakavuuden ja selvittää strategian, jonka avulla riskin toteutuessa siitä selvitään. Sivu Projektisuunnitelma jatkuu 1. Laitteisto- ja ohjelmistovaatimukset Selvittää kehitystyössä tarvittavat laitteisto- ja ohjelmistokomponentit. Jos projektia varten tarvitaan uusia komponentteja, annetaan komponenttien kustannusarvio. 2. Työn ositus Selvitetään projektin toiminnot, tarkistuspisteet ja kunkin toiminnon tuloksena saatavat tuotokset. 3. Projektin aikataulu Selvitetään osituksen toimintojen väliset riippuvuudet, aika kunkin tarkistuspisteen vaatimasta ajasta ja henkilöiden tehtävät kussakin toiminnossa. 4. Seuranta- ja raportointitavat Selvitetään, miten projektia seurataan ja miten hoidetaan sekä projektin sisäinen että projektista ulos lähtevä raportointi. Sivu

25 3.4. Tarkistuspisteet ja tuotokset Projektia suunniteltaessa projektille määritetään joukko tarkistuspisteitä (milestones). Jokainen tarkistuspiste on jonkin työvaiheen lopussa. Tarkistuspisteiden avulla tarkastetaan, että projekti pysyy aikataulussa. Aikataulu tehdään työvaihden ja tarkistuspisteiden mukaan. Projektin tuotos (deliverable) on jokin projektista saatava asiakkaalle merkittävä tulos. Esimerkiksi vaatimusdokumentti on yleensä tuotos, mutta suunnitteludokumentti ei välttämättä ole. Sivu Tarkistuspisteet ja tuotokset (jatkuu) Tuotokset ovat käytännössä aina tarkistuspisteitä, mutta tarkistuspisteiden ei tarvitse olla tuotoksia. Tarkistuspisteiden määrittämiseksi projekti on ensin jaettava yhtenäisiin perustoimintoihin. Perustoiminto: jokin kokonaisuus, jolla on selkeä alku ja selkeä lopputuotos. Esimerkiksi vaatimusanalyysissä yksi perustoiminto voisi olla vaatimusten kartoitus, minkä lopputuloksena saadaan vaatimuslista. Jokainen tarkistuspiste päättää perustoiminnon, mutta perustoiminto ei välttämättä pääty tarkistuspisteeseen. Sivu

26 3.5. Projektin aikataulu Kun projekti on saatu jaettua perustoimintoihin, jokaiselle perustoiminnolle annetaan kestoarvio ja selvitetään riippuvuudet muihin perustoimintoin. Kullekin tuotokselle ja tarkistuspisteelle päätetään perustoiminto, mikä tuottaa tuotoksen tai minkä päättyminen merkitsee tarkistuspisteen saavuttamista. Tämän jälkeen perustoiminnot yhdistetään toimintoverkoksi, mistä selviävät perustoimintojen järjestys ja kesto. Toimintoverkko käytännössä kertoo perustoimintojen järjestyksen ja aikataulun. Sivu Toimintoverkko Yleensä Toimintoverkolla kuvataan yksi laajempi työvaihe, esimerkiksi vaatimusanalyysi. Projektissa on kuitenkin useita tarkistuspisteitä, missä kaikki käynnissä olevat perustehtävät yhtyvät. Näitä on hyvä käyttää hyväksi aikataulun laadinnassa. Toimintoverkon teko kuuluu yleensä projektipäällikön tehtäviin. Jos samasta projektista annetaan kahdelle eri projektipäällikölle tehtäväksi tehdä toimintoverkko, tuloksena saadaan melko varmasti kaksi eri verkkoa. Sivu

27 Kriittinen polku Määritetyillä perustehtävillä on keskinäisiä riippuvuuksia, jotka on otettava huomioon toimintoverkossa. Joitain tehtäviä ei voida aloittaa ennen kuin jotkin muut tehtävät on saatu päätökseen. Vastaavasti toimintoverkossa voi olla rinnakkaisia tehtäviä: useita toisistaan riipumattomia tehtäviä voidaan hoitaa samanaikaisesti, kunhan jokaiselle tehtävälle on riittävästi henkilöresursseja. Rinnakkaisuus nopeuttaa projektia, mutta aiheuttaa työtä aikataulun laadinnalle. Laadinnassa on otettava huomioon kriittinen polku. Sivu Ajoituskaavio Kriittinen polku määrittelee tehtävät, jotka on saatava valmiiksi aikataulussa, jotta projektin aikataulu pitää. Kaikille perustehtäville tehdään seuraava jaottelu: 1. Aikaisin hetki, jolloin tehtävä voi alkaa. 2. Viimeisin hetki, jolloin tehtävän pitää alkaa. 3. Aikaisin mahdollinen lopetusaika. 4. Viimeisin mahdollinen lopetusaika. 5. Ylijäämäaika, joka riippuu tehtävästä ja kriittisestä polusta. Työvaiheen lopputuloksena saadaan ajoituskaavio. Siitä näkyvät kaikki perustehtävät kestoaikoineen ja tarkistuspisteet. Sivu

28 Muuta aikataulusta Kaikkien isompien työvaiheiden ajoituskaaviot yhdessä antavat projektin aikataulun. Tietenkin projekti voi myös tyytyä yhteen isoon ajoituskaavioon, joka silloin sisältää kaikki projektin työvaiheet. Ratkaisu riippuu projektin luonteesta. Tehtäväjaon ei pitäisi olla liian hienojakoinen, sillä se vaikeuttaa sekä projektin toteutusta että sen seuraamista. Pienimmät perustehtävät voivat olla suurusluokkaa 1-2 viikkoa. Seuraavilla kalvoilla on Sommervillen esimerkki tehtäväjaosta, kriittisestä polusta ja ajoituskaaviosta Sivu Task durations and dependencies Task Duration (days) Dependencies T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8) Kuvalla (C) I. Sommerville 2000 Sivu

29 Activity network 4/7/99 start 8 days T1 15 days T2 14/7/99 15 days M1 T3 5 days 25/7/99 T6 M3 20 days T7 4/8/99 M4 15 days T9 25/8/99 M6 7 days T11 10 days T4 Kuvalla (C) I. Sommerville /7/99 M5 25/7/99 M2 10 days T5 25 days T8 11/8/99 M7 5/9/99 M8 15 days T10 10 days T12 Finish 19/9/99 Sivu Activity timeline 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 T4 T1 T2 Start M1 T7 T3 M5 T8 Kuvalla (C) I. Sommerville 2000 M3 M2 T6 T5 T9 M4 M7 T10 T11 T12 M6 M8 Finish Sivu

30 3.6. Riskienhallinta Riskienhallinta on projektin hallintaa, missä projektin valmistuminen pyritään takaamaan myös tilanteissa, milloin jotain ei-toivottua tapahtuu. Riskienhallinnassa pyritään tunnistamaan projektin onnistumista vaikeuttavat riskit, analysoidaan tunnistetut riskit: annetaan riskien toteutumiselle todennäköisyys ja selvitetään riskin toteutumisen vaikutukset, suunnitellaan vastatoimet: riskin toteutuminen pyritään estämään tai pyritään minimoimaan riskin haittavaikutukset ja seurataan riskejä: riskejä arvioidaan projektin kestoajan, ja projektisuunnitelman riskianalyysia päivitetään sitä mukaa, kun uutta tietoa projektin riskeistä tulee selville. Sivu Riskit, siis mitä? Riski on tapahtuma, jonka todennäköisyys on alle yksi ja joka toteutuessaan vahingoittaa projektia. Jos riskin todennäköisyys on yksi, eli se totetutuu aina, se ei ole riski vaan rajoitus. Riskit voivat olla projektikohtaisia: nämä vaikuttavat projektin aikatauluun tai käytössä oleviin resursseihin, tuotekohtaisia: nämä vaikuttavat kehitettävän tuotteen laatuun tai yrityskohtaisia: nämä vaikuttavat organisaatioon tai tuotteen menestykseen. Vaikka riskit ovat projektikohtaisia, samankaltaiset riskit esiintyvät useimmissa projekteissa. Sivu

31 Riskien tunnistus Riskien tunnistuksessa pyritään löytämään kaikkia mahdollisia riskejä, mitkä voivat vaikuttaa projektin onnistumiseen. Käytännössä kaikkein epätodennäköisimmät ja vaikutuksiltaan merkityksettömimmät riskit unohdetaan suosiolla. Tunnistusta auttaa riskityypittely: Teknologiariskit. Henkilökuntariskit. Organisaatioriskit. Työkaluriskit. Vaatimusten kartoituksen riskit. Kustannus- ja aikatauluarvioinnin riskit. Sivu Riskien analysointi Tunnistetuille riskeille mietitään riskin todennäköisyys ja vakavuus. Todennäköisyys: miten varmasti riski toteutuu. Luokitteluna käy epätodennäköinen (< 10%), mahdollinen (10%- 25%), keskimääräinen (25-50%), todennäköinen (50-75%) ja erittäin todennäköinen (>75%). Vakavuus: miten merkittävä riski on projektille. Luokitteluna käy tuhoisa, vakava, siedettävä ja vähäpätöinen. Lopulta päätetään, mihin riskeihin varaudutaan erityisen hyvin, mihin normaalisti ja mitkä jätetään huomioimatta. Sivu

32 Riskien vastatoimet Riskien analysoinnin jälkeen jokaiselle valitulle riskille mietitään vastatoimet. Vastatoimet otetaan käyttöön, jos riski toteutuu. Vastatoimet riippuvat riskin luonteesta ja vakavuudesta. Toimet voivat olla riskien välttämistä: pyritään pienentämään todennäköisyyttä, että jokin riski tapahtuu, vaikutusten minimointia: riskiä ei pystytä välttämään, mutta pyritään vähentämään riskin toteutumisesta syntyviä haittavaikutuksia, jatkosuunnitelmia: mietitään toimintatapoja, joita voidaan seurata riskin toteutuessa (esim. yrityiskohtaiset riskit). Sivu Riskien seuranta Riskianalyysin jälkeen meillä on listattuna projektisuunnitelmassa joukko riskejä ja niiden vastatoimia. Riskien toteutumista seurataan koko projektin elinkaaren ajan. Projektin kestäessä saattaa ilmaantua uusia riskejä. Nämä otetaan huomioon riskianalyysissa, mikä saattaa pakottaa projektisuunnitelman päivitykseen. Myös jo tunnistettujen riskien todennäköisyydet ja vakavuudet voivat muuttua. Sivu

33 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 vaatimukset. Implisiittiset vaatimukset: ominaisuudet, jotka oletetaan olevan kaikilla kehitettävän tyyppisillä laadukkailla ohjelmistoilla. Tällaisia ovat esimerkiksi hyvä ylläpidettävyys, selkeä ja yhdenmukainen käyttöliittymä ja virheettömyys. Näitä ei välttämättä listata erikseen, mutta siitä huolimatta tuotettavan ohjelman täytyy toteuttaa ne. Eksplisiittiset vaatimukset: vaatimukset, jotka on lueteltu erikseen ja jotka tuotettavan ohjelman täytyy toteuttaa. Nämä selvitetään vaatimusanalyysissa. Sivu Vaatimusanalyysin tavoitteet Vaatimusanalyysin tavoitteena on selvittää ohjelmistolle asetettavat vaatimukset sellaisella tarkkuudella, että niiden perusteella voidaan tuottaa haluttu ohjelmisto. Lineaarisissa malleissa työvaiheen lopputuloksena saadaan täydellinen lista vaatimuksista ja analyysi niiden vaikutuksista. Iteratiivisissa malleissa saadaan lista tällä iteraatiokierroksella vaikuttavista vaatimuksista. Vaatimukset ovat eritasoisia. Osa on hyvin korkealla tasolla, osa menee syvälle yksityiskohtiin. Sivu

34 Vaatimusten luonteesta Dokumentoitavien vaatimusten on oltava virheettömiä. Vaatimusanalyysissä tehty virhe vaikuttaa koko projektin elinkaaren ajan ja tulee kalliiksi. ristiriidattomia. Ristiriitaisuus syntyy puhutun ja kirjoitetun kielen moniselitteisyydestä. täydellisiä. Vaatimukset muuttuvat lähes poikkeuksetta projektin elinkaaren aikana, joten täydellisyyteen (ja virheettömyyteen) ei päästä. realistisia. Vaatimusanalyysissa selvitetään myös järjestelmäsuunnittelun ja toteutusympäristön asettamat rajoitukset. tarpeellisia. Tarpeellisten vaatimusten selvittäminen on yllttävän vaikea tehtävä. Vaatimukset kannattaa priorisoida. todennettavissa. Jokainen vaatimus on löydettävä tuotteesta, ja tuotteen jokainen ei-triviaali ominaisuus on oltava tunnistettu vaatimus. jäljitettävissä. Jokaisella vaatimuksella on esittäjä, joka on voitava selvittää tarpeen vaatiessa. Sivu Vaatimustyypit Vaatimusanalyysia vaikeuttaa, että vaatimukset on tarkoitettu eri tarkoituksiin: Vaatimuksia käytetään kuvaamaan tehtävää ohjelmistoa Vaatimukset toimivat sopimuksena asiakkaan ja ohjelmistoyrityksen välillä. Vaatimukset kuvaavat ohjelmiston toiminnan yksityiskohtia Vaatimukset toimivat suunnittelun perustana. Vaatimusten monimerkityksisyyden johdosta Sommerville jakaa vaatimukset kolmeen tyyppiin: käyttäjän vaatimukset (user requirements), järjestelmävaatimukset (system requirements) ja ohjelmiston määrittelykuvaukset (software design specification). Sivu

35 Vaatimustyypit jatkuvat Käyttäjän vaatimukset Vaatimukset listaavat ohjelmiston tarjoamat palvelut ja ohjelmistolle asetettavat rajoitukset. Vaatimukset kuvataan luonnollisella kielellä ja kaavioilla. Käyttäjän vaatimuksia käytetään analyysin pohjana ja yhteydenpidossa asiakkaan kanssa. Järjestelmävaatimukset Vaatimukset kuvaavat ohjelmiston palvelut ja rajoitukset yksityiskohtaisesti. Kaikki vaatimukset kuvataan samalla formaatilla. Järjestelmävaatimuksia käytetään sopimuksena asiakkaan ja ohjelmistoyrityksen välillä. Ohjelmiston määrittelykuvaukset Määrittelykuvaus on yksityiskohtainen ja kattava kuvaus ohjelmistosta. Kuvauksessa käytetään standardoituja menetelmiä, kaavioita ja strukturoitua kuvausta. Kuvaus toimii suunnittelun esiasteena. Sivu Vaatimusten luokittelu Äsken tyypiteltiin, nyt luokitellaan vaatimuksia. Käyttäjä- ja järjestelmävaatimukset voidaan luokitella toiminnallisiin (functional) vaatimuksiin ja eitoiminnallisiin (non-functional) vaatimuksiin. Toiminnalliset vaatimukset: Nämä määrittelevät, mitä palveluja ohjelmiston on tarjottava, miten ohjelmisto reagoi syötteisiin ja miten se käyttäytyy annetuissa tilanteissa. Joskus toiminnalliset vaatimukset myös määrittelevät, mitä ohjelmiston ei pidä tehdä. Ei-toiminnalliset vaatimukset: Nämä määrittelevät rajoitukset ja reunaehdot toiminnallisille vaatimuksille. Sivu

36 Vaatimusten luokittelu (jatkuu) Esimerkiksi vaikka näin: Ohjemistoon pitää pystyä tekemään kyselyjä kulloinkin paikalla olevista käyttäjistä (toiminnallinen vaatimus). Ohjelmiston on selvittävä sadasta kyselystä sekunnissa (eitoiminnallinen vaatimus). Ohjelmiston on reagoitava hälytykseen hälytysmerkkiäänellä ja vilkkuvalla näytöllä (toiminnallinen vaatimus). Hälytykseen on reagoitava alle 0,1 sekunnin sisällä hälytyksen aiheuttaneen signaalin saapumisesta (ei-toiminnallinen vaatimus). Ohjelmistossa on oltava ylläpidolle tarjotut palvelut toiseen käyttöympäristöön siirtymiseksi (toiminnallinen vaatimus). Ohjelmiston on toimittava Windows- ja Linux-ympäristöissä (eitoiminnallinen vaaatimus). Sivu Toiminnalliset vaatimukset Toiminnalliset vaatimukset ovat intuitiivisesti selkeitä. Tarkoitus on listata, mitä palveluja järjestelmä tarjoaa. Toiminnallisiin vaatimuksiin kuuluvat luonnollisesti ohjelmiston normaalit palvelut, mutta niihin kuuluvat myös virhetilanne- ja poikkeuskäsittelyn tarjoamat toiminnot ja toipumistavat. Toiminnalliset vaatimukset etsitään alkaen suurista kokonaisuuksista ja edeten kohti pienempiä osia. Vaatimukset pyritään kartoittamaan eri näkökulmista, jotta vaatimuksista saadaan mahdollisimman kattavat. Sivu

37 Ei-toiminnalliset vaatimukset Koska ei-toiminnalliset vaatimukset eivät liity suoraan palveluihin, ne eivät ole yhtä intuitiivisia kuin toiminnalliset vaatimukset. Ei-toiminnalliset vaatimukset asettavat ohjelmistolle ja sen toteutukselle rajoituksia. Rajoitus: jokin sääntö, joka ohjelmiston on toteutettava. Esimerkiksi edellä esimerkissä oli aika- ja ylläpitorajoituksia. Koska ei-toiminnalliset vaatimukset eivät suoraan käsittele ohjelmiston tarjoamia palveluja, niiden löytäminen, luokittelu ja validointi on vaikeampaa kuin toiminnallisten vaatimusten. Sivu Ei-toiminnallisia vaatimusluokkia Seuraava luokittelu voi auttaa löytämään eitoiminnallisia vaatimuksia: Nopeus: tapahtumia sekunnissa, vasteajat, päivitysajat ym. Koko: ohjelmiston koko, syöttö-/tulostiedoston koko ym. Helppokäyttöisyys: koulutusaika, opastusjärjestelmä ym. Luotettavuus: vikasietoisuusaste, saavutettavuusaika ym. Sitkeys (robustness): toipumisaika, kaatumistodennäköisyys, virhetilanteessa tietojen katoamistodennäköisyys ym. Siirrettävyys (portability): alustariippuvan koodin määrä, tuettavien järjestelmäalustojen määrä ym. Ei-funktionaaliset vaatimukset pyritään aina kuvaamaan tarkasti numeroarvoilla. Sivu

38 Ympäristövaatimukset Ympäristövaatimukset (domain requirements) ovat vaatimuksia, joiden lähtökohtana on ohjelmistoa ympäröivä toimintaympäristö käyttäjien sijaan. Ympäristövaatimukset voivat olla joko toiminnallisia tai ei-toiminnallisia vaatimuksia. Ympäristövaatimukset ovat tärkeitä, sillä ne määrittelevät ehdot, jotka ohjelmiston tulee täyttää, jotta se voi toimia järjestelmässä. Ympäristövaatimuksia ovat esimerkiksi ohjelmistolle määriteltävät rajapinnat muihin ohjelmistokomponentteihin. Sivu Vaatimusdokumentti Vaatimusanalyysin lopputuloksena saadaan vaatimusdokumentti. Se kuvaa yksiselitteisesti kaikki ohjelmistolle asetetut vaatimukset ja kehitetyt mallit. Vaatimusdokumentin täytyy täyttää seuraavat vaatimukset: Se määrittelee vain ulkoisen toiminnan: mitä ohjelmisto tarjoaa. Se määrittelee toteutukselle asetettavat rajoitukset. Se on helposti muutettavissa. Se toimii lähdeteoksena ohjelmiston ylläpitäjille. Se sisältää arvion tuotteen elinkaaresta. Se käsittelee myös virhetilanteet. Sivu

39 Vaatimusdokumentti (jatkuu) Jokaisella yrityksellä on vaatimusdokumentin pohja, joka helpottaa vaatimusdokumentin kirjoittamista. Kirjallisuudesta löytyy myös standardoituja pohjia, kuten IEEE:n standardi vaatimusdokumenteille (IEEE/ANSI ). Vaatimusdokumentti hyväksytään sekä asiakkaan että ohjelmistoyrityksen puolelta. Sen pitää olla rakenteeltaan sellainen, että kaikki sidosryhmät voivat käyttää sitä: asiakkaat, johtoryhmä, laadunvalvontaryhmä, halinto, projektipäällikkö, projektiryhmä ym. Sivu Vaatimusdokumentin sisällysluettelo Seuraava lista perustuu Sommervillen esittämään vaatimusdokumentin rakenteeseen. 1. Esipuhe (preface) Selvittää kenelle dokumentti on tarkoitettu, dokumentin versiohistorian ja yhteenvedon edellisen version jälkeen tehdyistä muutoksista. 2. Johdanto Sisältää järjestelmän yleiskuvauksen, tärkeimmät tehtävät ja yhteistyön muiden järjestelmien kanssa. Johdanto voi sisältää myös lyhyen vanhan järjestelmän kuvauksen ja viitteet vanhan järjestelmän dokumentaatioon. 3. Sanasto Määrittelee dokumentissa käytetyt termit. Dokumentin tulee olla myös alan sanastoa tuntemattoman henkilön luettavissa. Sivu

40 Sisällysluettelo (jatkuu) 4. Käyttäjän vaatimukset Määrittelee käyttäjän vaatimukset luonnollisella kielellä ja kaavioilla. Myös mahdolliset käyttäjän vaatimuksiin laskettavat ympäristövaatimukset luetellaan täällä. 5. Järjestelmäarkkitehtuuri Antaa yleiskuvan toteutettavan ohjelmiston rakenteesta. Luku sisältää myös tiedot jo valmiina olevista ohjelmistokomponenteista. Järjestelmäarkkitehtuurista tarvitaan sopivalla kuvaustekniikalla tehty kaaviokuva. 6. Järjestelmävaatimukset Märittelee yksityiskohtaiset toiminnalliset ja ei-toiminnalliset vaatimukset. Sivu Sisällysluettelo (jatkuu II) 7. Järjestelmämallit Sisältää yksityiskohtaisemmat mallit järjestelmän osajärjestelmistä, komponenteista ja niiden välisistä suhteista. Järjestelmämallit ovat suunnittelun perustana. Ne kuvataan yhdellä tai useammalla kuvaustekniikalla. 8. Järjestelmän kehitys Selittää odotetut laitteiston, käytön ja ohjelmiston vaatimusten muutokset. 9. Liitteet Sisältää sellaiset olemassaolevat dokumentit tai viitteet, jotka vaikuttavat tuotteeseen, mutta joita ei ole määritelty vaatimusanalyysissa. Esimerkiksi käytettävän tietokannan hallintajärjestelmän kuvaus voi olla tällainen liitedokumentti. 10. Hakemisto Sivu

41 4.4. Vaatimusanalyysin vaiheet Vaatimusanalyysissa on seuraavat työvaiheet: Kelpoisuusselvitys (feasibility study). Katsotaan, kannattaako ohjelmistoa ylipäänsä toteuttaa. Vaatimusten kartoitus ja analyysi (requirements elicatation and analysis). Kerätään vaatimuksia yhteistyössä asiakkaan kanssa ja mallinnetaan löydettyjen vaatimusten perusteella kehitettävää järjestelmää. Vaatimusten määrittely (requirements specification). Jaetaan kartoitetut vaatimukset käyttäjävaatimuksiin ja järjestelmävaatimuksiin. Kehitetään ohjelmiston määrittelykuvaukset. Vaatimusten validointi (requirements validation). Varmennetaan, että löydetyt vaatimukset todella määrittelevät asiakkaan haluaman järjestelmän. Sivu Kelpoisuusselvitys Kelpoisuusselvitys on lyhyt esivaihe vaatimusanalyysille. Siinä pyritään vastaamaan: 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 olemassaoleviin järjestelmiin? 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. Sivu

42 Vaatimusten kartoitus ja analyysi Tavoitteena on löytää, luokitella ja mallintaa kaikki prosessin työvaiheeseen kuuluvat vaatimukset. Vesiputousmallissa tämä tarkoittaa kaikkia vaatimuksia. Prorotyyppimallissa tämä tarkoittaa seuraavalle prototyypille asetettavia vaatimuksia jne. Työvaiheeseen kuuluvat seuraavat osavaiheet: 1. Sovellusympäristön selvitys (domain understanding). 2. Vaatimusten keruu (requirements collection). 3. Vaatimusten luokittelu (classification). 4. Ristiriitaisuuksien selvitys (conflict resolution). 5. Vaatimusten priorisointi (priorisation). 6. Vaatimusten tarkastus (requirements checking). Sivu Skenaariot Eräs tapa kartoittaa vaatimuksia on pyytää asiakkaalta skenaarioita (scenarios) nykyisestä ja tulevasta järjestelmän toiminnasta. Skenaariot ovat kuvauksia järjestelmän käytöstä eri näkökulmista. Skenaario sisältää yleensä järjestelmän tilan kuvauksen ennen toiminnan alkua, normaalin toiminnan kuvauksen, poikkeustilanteiden kuvauksen (voi olla oma skenaarionsa), tiedot mahdollisista muista samanaikaisista tapahtumista, jotka vaikuttavat tähän skenaarioon ja järjestelmän tilan kuvauksen toiminnan päättymisen jälkeen. Sivu

43 Käyttötapaukset Käyttötapaus (use-case) sisältää yhden tai useamman skenaarion järjestelmästä. Samankaltaiset tai samoihin järjestelmän osiin vaikuttavat skenaariot kootaan saman käyttötapauksen alle. Jokainen käyttötapaus kertoo yhden tavan toimia kehitettävässä järjestelmässä, toiminnan tehtävät ja toimintaan osallistuvat sidosryhmät. Käyttötapaukset voivat olla selväkielistä tekstiä tai niihin voidaan käyttää sopivaa kuvaustekniikkaa. Käyttötapauksia voidaan tarkentaa käymällä asiakkaan luona katsomassa nykyistä toimintaa. Sivu Vaatimusten tyypittely Kun vaatimukset on saatu kerättyä, luokiteltua ja mallinnettua, ne tyypitellään käyttäjän vaatimuksiin ja järjestelmävaatimuksiin. Samalla tarkistetaan, että vaatimukset vastaavat kehitettyjä malleja ja että mallit ovat täydelliset ja riittävät. Tarvittaessa palataan takaisin keräämään ja analysoimaan lisää vaatimuksia. Tämän työvaiheen tuloksena saadaan yksityiskohtaiset vaatimuslistat ja korkean tason ohjelmistosuunnitelmat kehitettävästä ohjelmistosta. Sivu

44 Vaatimusten validointi Viimeisenä vaiheena kerätyt, analysoidut, tarkennetut ja tyypitellyt vaatimukset validoidaan. Tarkoituksena on selvittää, että saatu vaatimuslista ja vaatimusten perusteella kehitetyt mallit ovat yhtenäiset ja toteuttavat vaatimuksille asetetut ominaisuudet: Vaatimusten on oltava virheettömiä, ristiriidattomia, täydellisiä, realistisia, tarpeellisia, todennettavissa ja jäljitettävissä. Vaatimusten validointia varten saatetaan rakentaa järjestelmästä prototyyppi tai kirjoittaa alustava käyttöohje. Sivu Vaatimusanalyysin hallinta Vaatimusanalyysi on prosessi, joten se tarvitsee hallintaa. Hallinnan tehtävä on organisoida työvaiheet ja varustautua siihen, että vaatimukset muuttuvat projektin edetessä. Myös vaatimusanalyysiin kuuluu riskienhallintaa. Riskit tunnistetaan ja niihin varaudutaan. Esimerkiksi jos on todennäköistä, että vaatimukset elävät voimakkaasti projektin aikana, kehitetään mieluummin lisäävällä mallilla tai prototyyppimallilla ohjelmistoa vähän kerrassaan toivottuun suuntaan. Sivu

45 3a. Projektin hallinta (lisäys lukuun 3) Tehokas projektin hallinta keskittyy kolmeen osaalueeseen: henkilökuntaan, tehtävään ja prosessiin. Henkilökunta: on yrityksen tärkein voimavara, oikea henkilö oikeassa tehtävässä = menestys, väärä henkilö väärässä tehtävässä = kaaos. Henkilöhallinnan alueita: palkkaus, valinta tehtäviin, souritusten seuranta, koulutus, hyvitysperiaatteet, urakehitys, työnkuva ja ryhmätyön kehittäminen. Tehtävä: Onnistunut projekti vaatii tarkan rajauksen ja yksityiskohtaisen tehtäväkuvauksen. Sivu Projektin hallinta (jatkuu) Prosessi: Sopivaa prosessia käyttämällä saadaan kehys projektille. Yksityiskohtaiset tehtävät määritellään projektin alkuvaiheessa käytetyn prosessin mukaisesti. Sekä tuotteen että projektin laatua valvotaan koko projektin kestoajan. Tehtävästä ja prosessista on puhuttu aiemmin. Sen sijaan henkilöistä ei ole puhuttu juuri mitään. Projektin tärkeimmät osallistujat ovat projektipäällikkö ja projektin jäsenet. Muita osallistujia ovat mm. asiakkaan tekniset asiantuntijat, johtoryhmä ja markkinointiosastojen työntekijät. Sivu

46 Projektipäällikkö Projektipäällikkö vastaa projektin lisäksi projektin jäsenistä. Projektipäälliköltä vaaditaan: ongelmanratkaisukykyä: Hän ymmärtää työalueen ja pystyy löytämään uusia ratkaisuja. Hän osaa motivoida muita. johtamistaitoa: Hän ottaa suurimman vastuun projektin onnistumisesta. Hän osaa tehdä päätöksiä ja ottaa vastuuta myös vaikeissa tilanteissa. kannustuskykyä: hän kannustaa ryhmää hallittuun riskinottoon ja uusien ideoiden tuottamiseen. pyskologista silmää: hän ymmärtää ryhmän jäsenten välisiä jännitteitä. Hän järjestää tehtävät sillä tavalla, että ryhmän jäsenet tuntevat työskentelevänsä miellyttävässä ympäristössä. Sivu Projektiryhmä Projektiryhmän rakenne: Demokraattinen hajautettu (DD, democratic decentralized): Ryhmällä ei ole pysyvää johtajaa. Jokaisella tehtävällä on vastuuhenkilö, joka vaihtuu tehtävän vaihtuessa. Kommunikointi tapahtuu demokraattisesti ryhmän sisällä. Ohjattu hajautettu (CD, controlled decentralized): Koko projektilla on vastuussa oleva johtaja. Projektiryhmä on jaettu osaryhmiin, joista jokaisella on päällikkö. Ongelmanratkaisu tapahtuu yleensä ryhmässä, mutta toteutus tehdään osaryhmissä. Kommunikointi tapahtuu pääasiassa osaryhmien sisällä. Ohjattu keskitetty (CC, controlled centralized): Ryhmällä on projektipäällikkö, joka hoitaa keskitetysti koko projektin hallinnan. Projektin jäsenille annetaan selkeät tehtävät. Kommunikointi tapahtuu projektipäällikön kautta. Sivu

4. Vaatimusanalyysi. Vaatimusanalyysin tavoitteet

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

Lisätiedot

Ohjelmistotuotanto

Ohjelmistotuotanto 581259-4 Ohjelmistotuotanto Juha Taina Helsingin yliopisto Tietojenkäsittelytieteen laitos 1. Johdanto Mitä on ohjelmistotuotanto? Ohjelmisto, ohjelmointi, tekniikkaa, insinööritaitoa, kurinalaisuutta,

Lisätiedot

Ohjelmistotuotanto, vaatimusanalyysi Syksy Vaatimusanalyysi. Implisiittiset vaatimukset. Eksplisiittiset vaatimukset

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ä

Lisätiedot

2. Ohjelmistotuotantoprosessi

2. Ohjelmistotuotantoprosessi 2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa

Lisätiedot

Implisiittiset vaatimukset. 4. Vaatimusmäärittely. Eksplisiittiset vaatimukset. Vaatimusmäärittelyn tavoitteet. Vaatimusten luonne II

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ä

Lisätiedot

Ohjelmistotuotanto, projektinhallinta Kevät 2005

Ohjelmistotuotanto, projektinhallinta Kevät 2005 3. Projektinhallinta Ohjelmistoprojektien koon kasvaessa on törmätty projektinhallinnan ongelmiin, kuten jatkuva, osin huonosti hallittu kasvu, myöhästymiset, huono laatu, budjettien ylitykset, projektien

Lisätiedot

Prosessimalli. 2. Ohjelmistotuotantoprosessi. Prosessimallin vaihejako. Prosessimallien perustehtävät. Ohjelmiston suunnittelu. Vaatimusmäärittely

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

Lisätiedot

1. Johdanto. Ohjelmistotuotannon ongelmia

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

Lisätiedot

Software engineering

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

Lisätiedot

3. Projektinhallinta. Miksi ohjelmistoprojektin hallinta on erilaista?

3. Projektinhallinta. Miksi ohjelmistoprojektin hallinta on erilaista? 3. Projektinhallinta Ohjelmistoprojektien koon kasvaessa on törmätty projektinhallinnan ongelmiin, kuten jatkuva, osin huonosti hallittu kasvu, myöhästymiset, huono laatu, budjettien ylitykset, projektien

Lisätiedot

4. Vaatimusmäärittely

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,

Lisätiedot

Ohjelmistotuotanto, prosessit Syksy Ohjelmistotuotantoprosessi. Prosessimalli. Prosessimallien perustehtävät. Prosessimallin vaihejako

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

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

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

Lisätiedot

Ohjelmistojen suunnittelu

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

Lisätiedot

Projektisuunnitelma. KotKot. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

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

Lisätiedot

Tietojärjestelmän osat

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

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

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

Lisätiedot

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

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

Lisätiedot

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

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

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

Lisätiedot

5. Järjestelmämallit. Mallinnus

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.

Lisätiedot

Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita

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:

Lisätiedot

Mallinnus. 5. Järjestelmämallit. Abstraktiot. Mallinnuksen etuja. Arkkitehtuurimalli. Yhteysmallit. Ohjelmistotuotanto, järjestelmämallit Kevät 2005

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.

Lisätiedot

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

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

Lisätiedot

Oleelliset vaikeudet OT:ssa 1/2

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

Lisätiedot

TOIMINNALLINEN MÄÄRITTELY MS

TOIMINNALLINEN MÄÄRITTELY MS TOIMINNALLINEN MÄÄRITTELY 11.11.2015 MS YLEISTÄ 1/2 jäsennelty etenee yleiskuvauksesta yksityiskohtiin kieliasultaan selkeä kuvaa myös tulevan järjestelmän ympäristöä tarpeellisella tarkkuudella kuvaa

Lisätiedot

Ohjelmistotekniikka - Luento 2

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

Lisätiedot

Projektityö

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:

Lisätiedot

Projektin suunnittelu

Projektin suunnittelu Projektin suunnittelu Sami Kollanus TJTA330 Ohjelmistotuotanto 15.3. Projektin suunnittelu - CMMIkäytänteet Projektin estimaatit: Määritellään projektin laajuus (scope) Määritellään tehtävien ja tuotosten

Lisätiedot

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen

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

Lisätiedot

Ohjelmistotuotanto, s

Ohjelmistotuotanto, s Ohjelmistotuotanto Ohjelmiston määrittely n tavoitteena on selvittää ohjelmistolle asetettavat vaatimukset niin yksityiskohtaisesti, että niiden perusteella voidaan tuottaa haluttu ohjelmisto. Lineaarisissa

Lisätiedot

Ohjelmistoprojektien hallinta Vaihejakomallit

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

Lisätiedot

OHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta

OHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta OHJ-3010 Ohjelmistotuotannon perusteet Ohjelmistoprojektin hallinta 1 Sisältö Projektiorganisaatio ja sidosryhmät Ohjelmistoprojektin kulku Projektin suunnittelu Ositus Osallistujat Työmäärän arviointi

Lisätiedot

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä

Lisätiedot

Dokumentointi ketterissä menetelmissä

Dokumentointi ketterissä menetelmissä Dokumentointi ketterissä menetelmissä Dokumentointi kuuluu ketteriin menetelmiin niin kuin kaikkeen ohjelmistotuotantoon Dokumentointi itsessään yksi vaatimus, jonka prioriteetti pitää arvioida (asiakkaan

Lisätiedot

Projektiryhmä Tete Työajanseurantajärjestelmä. Riskienhallintasuunnitelma

Projektiryhmä Tete Työajanseurantajärjestelmä. Riskienhallintasuunnitelma Projektiryhmä Tete Työajanseurantajärjestelmä T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 2(6) Muutoshistoria Versio PVM Tekijä Kuvaus 0.10 14.10.2003 Miikka Lötjönen Dokumenttipohja (projektisuunnitelman

Lisätiedot

Kurssin aihepiiri: ohjelmistotuotannon alkeita

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

Lisätiedot

Projektinhallinta: johtajuus ja organisaatio

Projektinhallinta: johtajuus ja organisaatio Projektinhallinta: johtajuus ja organisaatio 581259 Ohjelmistotuotanto 291 Kaikki projektit tarvitsevat jonkinlaista hallintaa ja johtamista, muuten seurauksena kaaos Johtajuus Virallinen johtajan rooli

Lisätiedot

Juha Taina, Marko Salmenkivi ja Kjell Lemström,

Juha Taina, Marko Salmenkivi ja Kjell Lemström, Projektinhallinta: johtajuus ja organisaatio Kaikki projektit tarvitsevat jonkinlaista hallintaa ja johtamista, muuten seurauksena kaaos Johtajuus Virallinen johtajan rooli vs. (mahdollisesti epävirallinen)

Lisätiedot

Ohjelemistotuotanto, syksy 1998 /Prosessi Prosessimallit

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

Lisätiedot

Ylläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Ylläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ylläpitodokumentti Boa Open Access Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari

Lisätiedot

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

Lisätiedot

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1

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

Lisätiedot

MS Project 2016 perusteet projektiarkkitehdeille ja -insinööreille ver Hannu Hirsi 2018

MS Project 2016 perusteet projektiarkkitehdeille ja -insinööreille ver Hannu Hirsi 2018 MS Project 2016 perusteet projektiarkkitehdeille ja -insinööreille ver. 7.2 Hannu Hirsi 2018 1 Yleistä : 1. Yksi käytetyimmistä projektien hallintaohjelmista on Microsoft Project, joka on tehokas ja joustava

Lisätiedot

Projektisuunnitelma. Boa Open Access. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Projektisuunnitelma. Boa Open Access. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Projektisuunnitelma Boa Open Access Helsinki 4.2.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari

Lisätiedot

Convergence of messaging

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

Lisätiedot

Ohjelmistojen mallintaminen, mallintaminen ja UML

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

Lisätiedot

Suunnitteluvaihe prosessissa

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

Lisätiedot

Harjoitustyön testaus. Juha Taina

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

Lisätiedot

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

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.

Lisätiedot

Projektisuunnitelma Nero-ryhmä

Projektisuunnitelma Nero-ryhmä Projektisuunnitelma Nero-ryhmä Kuusela Johannes Muukkonen Jyrki Sjöblom Teemu Sundberg Ville Suominen Osma Tuohenmaa Timi Ohjelmistotuotantoprojekti Helsinki 9.9.2004 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen

Lisätiedot

1. Johdanto. Ohjelmistotuotannon piirteitä

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

Lisätiedot

1. Johdanto. Ohjelmistotuotannon piirteitä

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

Lisätiedot

Testaussuunnitelma PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

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

Lisätiedot

Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi. Verifiointi- ja validointitekniikat. Verifiointi- ja validointitekniikat II

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

Lisätiedot

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

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ä

Lisätiedot

Data Sailors - COTOOL dokumentaatio Riskiloki

Data Sailors - COTOOL dokumentaatio Riskiloki Table of Contents 1 Johdanto.................................................................................... 1 1.1 Versiohistoria...........................................................................

Lisätiedot

1. Johdanto. Ohjelmistotuotannon piirteitä. Ohjelmisto ja järjestelmä. Osajärjestelmät ja käyttäjät. Järjestelmän ja ohjelmiston laadinta

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

Lisätiedot

1. Johdanto. Ohjelmistotuotannon piirteitä. Ohjelmisto ja järjestelmä. Osajärjestelmät ja käyttäjät. Järjestelmän ja ohjelmiston laadinta

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

Lisätiedot

Ohjelmistojen mallinnus, s2008 HY/TKTL, 28/10/2008. Harri Laine 1. Ohjelmisto

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

Lisätiedot

Ohjelmistotuotanto, suunnittelu Syksy Suunnittelu. Suunnittelun tulos. Suunnitteluprosessin työvaiheet. Suunnitteluprosessi.

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.

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus

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:

Lisätiedot

Hajaantuminen. Juha Taina, Marko Salmenkivi ja Kjell Lemstöm, Ohjelmistotuotanto 30

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ä

Lisätiedot

Ohjelmistojen mallintaminen. Luento 11, 7.12.

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,

Lisätiedot

Juha Taina, Marko Salmenkivi ja Kjell Lemström,

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ä

Lisätiedot

1. Johdanto. Ohjelmistotuotannon piirteitä

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

Lisätiedot

1. Johdanto. Ohjelmistotuotannon piirteitä. Ohjelmisto ja järjestelmä. Osajärjestelmät ja käyttäjät. Järjestelmän ja ohjelmiston laadinta

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

Lisätiedot

Aluksi. Riskien hallinta. Riskityyppejä. Riskillä on kaksi ominaisuutta. Reaktiivinen strategia. Proaktiivinen strategia

Aluksi. Riskien hallinta. Riskityyppejä. Riskillä on kaksi ominaisuutta. Reaktiivinen strategia. Proaktiivinen strategia Aluksi Riskien hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 24.1.2007 Reaktiivinen strategia Indiana Jones -tyyli Ei huolehdita ongelmista ennen kuin ne tapahtuu Proaktiivinen strategia Tunnistetaan

Lisätiedot

Määrittelyvaihe. Projektinhallinta

Määrittelyvaihe. Projektinhallinta Määrittelyvaihe Projektinhallinta testaus määrittely suunnittelu ohjelmointi käyttöönotto, testaus tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta Määrittely Määrittely, eli kansanomaisesti

Lisätiedot

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä

Lisätiedot

1. Johdanto. Ohjelmistotuotannon piirteitä

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

Lisätiedot

T-76.115 Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

T-76.115 Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä

Lisätiedot

Ohjelmistotuotanto, projektinhallinta Syksy Miksi ohjelmistoprojektin hallinta on erilaista? 3. Projektinhallinta

Ohjelmistotuotanto, projektinhallinta Syksy Miksi ohjelmistoprojektin hallinta on erilaista? 3. Projektinhallinta 3. Projektinhallinta ohjelmistoprojektien koon kasvaessa on törmätty projektinhallinnan ongelmiin: jatkuva, osin huonosti hallittu kasvu myöhästymiset huono laatu budjettien ylitykset projektien epäonnistumiset

Lisätiedot

Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

Lisätiedot

Orientaatio ICT-alaan. Projekti

Orientaatio ICT-alaan. Projekti Orientaatio ICT-alaan Projekti Projekti Ajallisesti rajoitettu, kertaluonteinen tehtävä määrätyt resurssit sekä oma (linjaorganisaatiosta poikkeava) organisaatio Toteutus tapahtuu suunnitelmallisesti ennalta

Lisätiedot

Ohjelmistojen mallintaminen. Matti Luukkainen

Ohjelmistojen mallintaminen. Matti Luukkainen Ohjelmistojen mallintaminen Matti Luukkainen Kurssin aihepiiri: ohjelmistotuotannon alkeita [wikipedia]: Ohjelmistotuotanto on yhteisnimitys niille työnteon ja työnjohdon menetelmille, joita käytetään,

Lisätiedot

Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi

Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006-11-25 Janne Mäkelä Alustava 1.0 2006-12-10 Janne Mäkelä Valmis 1.

Lisätiedot

Onnistunut SAP-projekti laadunvarmistuksen keinoin

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.

Lisätiedot

Käyttötapausanalyysi ja testaus tsoft

Käyttötapausanalyysi ja testaus tsoft Käyttötapausanalyysi ja testaus tsoft 15.09.2004 http://cs.joensuu.fi/tsoft/ Johdanto Use Case analyysi (käyttötapausanalyysi) on yleisesti käytetty järjestelmälle asetettujen toiminnallisten vaatimusten

Lisätiedot

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä www.niksula.cs.hut.fi/~jjkankaa// Demosovelluksen tekninen määrittely v. 0.6 Päivitetty 11.12.2000 klo 20:26 Mickey Shroff 2 (12) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite

Lisätiedot

6. Suunnittelu. Suunnittelun tulos

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

Lisätiedot

Ohjelmoinnin perusteet Y Python

Ohjelmoinnin perusteet Y Python Ohjelmoinnin perusteet Y Python T-106.1208 2.3.2009 T-106.1208 Ohjelmoinnin perusteet Y 2.3.2009 1 / 28 Puhelinluettelo, koodi def lue_puhelinnumerot(): print "Anna lisattavat nimet ja numerot." print

Lisätiedot

Ohjelmiston toteutussuunnitelma

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,

Lisätiedot

Siltatiedon tarkkuustason määrittäminen Taitorakennerekisterissä. Maria Vinter

Siltatiedon tarkkuustason määrittäminen Taitorakennerekisterissä. Maria Vinter Siltatiedon tarkkuustason määrittäminen Taitorakennerekisterissä Maria Vinter 2 Taustaa Diplomityö: Tietomallinnuksen hyödyntäminen siltojen ylläpidossa, valmis 09/2017 https://julkaisut.liikennevirasto.fi/pdf8/opin_2017-03_tietomallinnuksen_hyodyntaminen_web.pdf

Lisätiedot

SYSTEMAATTINEN RISKIANALYYSI YRITYKSEN TOIMINTAVARMUUDEN KEHITTÄMISEKSI

SYSTEMAATTINEN RISKIANALYYSI YRITYKSEN TOIMINTAVARMUUDEN KEHITTÄMISEKSI Päivitetty 28.3.2017 SYSTEMAATTINEN RISKIANALYYSI YRITYKSEN TOIMINTAVARMUUDEN KEHITTÄMISEKSI Riskianalyysiohjeen tarkoitus on tukea yrityksen toimintaa uhkaavien tilanteiden (riskien) tunnistamisessa,

Lisätiedot

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 582101 - Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 1 Vaatimukset ja käyttötapaukset Vaiheittainen mallintaminen ja abstraktiotasot Järjestelmän rajaaminen sidosryhmäkaaviolla

Lisätiedot

Ohjelmistojen testaus

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ä

Lisätiedot

Johdantoluento. Ohjelmien ylläpito

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

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu kevät Suunnitelmakeskeiset prosessit (lukuisia lähteitä)

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,

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009

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,

Lisätiedot

Testaaminen ohjelmiston kehitysprosessin aikana

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/

Lisätiedot

OT-s200: Prosessimallit

OT-s200: Prosessimallit Ohjelmistoprosessi Ohjelmistotuotanto Ohjelmistoprosessi Ohjelmiston elinkaari Ohjelmiston rakentamisen vaiheet ja niiden tulokset Ohjelmiston elinkaaren määrittely Yleisrakenne sille miten ohjelmisto

Lisätiedot

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,

Lisätiedot

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja Versio: 0.9 Julkaistu: n.n.2011 Voimassaoloaika: toistaiseksi 1 Yleistä Palvelun kehitys jakautuu vaiheisiin, joiden väleissä

Lisätiedot

UCOT-Sovellusprojekti. Testausraportti

UCOT-Sovellusprojekti. Testausraportti UCOT-Sovellusprojekti Testausraportti Ilari Liukko Tuomo Pieniluoma Vesa Pikki Panu Suominen Versio: 0.02 Julkinen 11. lokakuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Hyväksyjä Päivämäärä

Lisätiedot

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant AgilElephant Testausraportti I1 Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Testausraportti Sivu 1 / 5 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision

Lisätiedot

Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä

Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä Omistaja Tyyppi Tiedoston nimi Turvaluokitus Kohderyhmä Turvaluokituskäytäntö --- SE/Pekka Järveläinen Projektisuunnitelma projektisuunnitelma_kielihallinto.doc

Lisätiedot

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

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

Lisätiedot

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS 10 KEYS TO SUCCESSFUL SOFTWARE PROJECT 1. Clear Vision 2. Stable, Complete, Written Requirements 3. Detailed User Interface Prototypes

Lisätiedot

A14-11 Potilaan mittaustiedon siirtäminen matkapuhelimeen

A14-11 Potilaan mittaustiedon siirtäminen matkapuhelimeen 1 AS-0.3200 Automaatio- ja systeemitekniikan projektityöt A14-11 Potilaan mittaustiedon siirtäminen matkapuhelimeen Projektisuunnitelma Tommi Salminen, Hanna Ukkola, Olli Törmänen 19.09.2014 1 Projektin

Lisätiedot