Ohjelmistotuotanto
|
|
- Teemu Hiltunen
- 6 vuotta sitten
- Katselukertoja:
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 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ätiedotOhjelmistotuotanto
581259-4 Ohjelmistotuotanto Juha Taina Helsingin yliopisto Tietojenkäsittelytieteen laitos 1. Johdanto Mitä on ohjelmistotuotanto? Ohjelmisto, ohjelmointi, tekniikkaa, insinööritaitoa, kurinalaisuutta,
LisätiedotOhjelmistotuotanto, 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ätiedot2. Ohjelmistotuotantoprosessi
2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa
LisätiedotImplisiittiset 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ätiedotOhjelmistotuotanto, 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ätiedotProsessimalli. 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ätiedot1. 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ätiedotSoftware 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ätiedot3. 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ätiedot4. 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ätiedotOhjelmistotuotanto, 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ätiedotCopyright 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ätiedotOhjelmistojen 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ätiedotProjektisuunnitelma. 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ätiedotTietojä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ätiedotOhjelmiston 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ätiedotOhjelmistotuotanto 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ätiedotLaatu 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ätiedotOhjelmointitekniikka 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ätiedot5. 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ätiedotYhteenvetoa, 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ätiedotMallinnus. 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ätiedotTestausdokumentti. 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ätiedotOleelliset 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ätiedotTOIMINNALLINEN 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ätiedotOhjelmistotekniikka - 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ätiedotProjektityö
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ätiedotProjektin 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ätiedotOhjelmistotekniikka - 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ätiedotOhjelmistotuotanto, s
Ohjelmistotuotanto Ohjelmiston määrittely n tavoitteena on selvittää ohjelmistolle asetettavat vaatimukset niin yksityiskohtaisesti, että niiden perusteella voidaan tuottaa haluttu ohjelmisto. Lineaarisissa
LisätiedotOhjelmistoprojektien 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ätiedotOHJ-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ätiedotT 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ätiedotDokumentointi ketterissä menetelmissä
Dokumentointi ketterissä menetelmissä Dokumentointi kuuluu ketteriin menetelmiin niin kuin kaikkeen ohjelmistotuotantoon Dokumentointi itsessään yksi vaatimus, jonka prioriteetti pitää arvioida (asiakkaan
LisätiedotProjektiryhmä 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ätiedotKurssin 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ätiedotProjektinhallinta: 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ätiedotJuha 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ätiedotOhjelemistotuotanto, 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ätiedotYllä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ätiedotLiite 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ätiedotOhjelmistojen 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ätiedotMS 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ätiedotProjektisuunnitelma. 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ätiedotConvergence 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ätiedotOhjelmistojen 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ätiedotSuunnitteluvaihe 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ätiedotHarjoitustyö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ätiedotOhjelmistojen 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ätiedotProjektisuunnitelma 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ätiedot1. 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ätiedot1. 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ätiedotTestaussuunnitelma 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ätiedotVerifioinnin 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ätiedotTenttikysymykset. + 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ätiedotData Sailors - COTOOL dokumentaatio Riskiloki
Table of Contents 1 Johdanto.................................................................................... 1 1.1 Versiohistoria...........................................................................
Lisätiedot1. 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ätiedot1. 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ätiedotOhjelmistojen 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ätiedotOhjelmistotuotanto, 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ätiedotOhjelmistoprosessit 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ätiedotHajaantuminen. 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ätiedotOhjelmistojen 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ätiedotJuha 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ätiedot1. 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ätiedot1. 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ätiedotAluksi. 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ätiedotMää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ätiedotT 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ätiedot1. 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ätiedotT-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ätiedotOhjelmistotuotanto, 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ätiedotOhjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon
582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta
LisätiedotOrientaatio 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ätiedotOhjelmistojen 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ätiedotGood 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ätiedotOnnistunut 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ätiedotKä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ätiedotKä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ätiedot6. 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ätiedotOhjelmoinnin 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ätiedotOhjelmiston 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ätiedotSiltatiedon 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ätiedotSYSTEMAATTINEN 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ätiedotOhjelmistotekniikan 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ätiedotOhjelmistojen 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ätiedotJohdantoluento. 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ätiedotOhjelmistoprosessit 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ätiedotOhjelmistoprosessit 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ätiedotTestaaminen 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ätiedotOT-s200: Prosessimallit
Ohjelmistoprosessi Ohjelmistotuotanto Ohjelmistoprosessi Ohjelmiston elinkaari Ohjelmiston rakentamisen vaiheet ja niiden tulokset Ohjelmiston elinkaaren määrittely Yleisrakenne sille miten ohjelmisto
LisätiedotOhjelmistotekniikka 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ätiedotJHS 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ätiedotUCOT-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ätiedotdokumentin 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ätiedotKieliaineistojen 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ätiedotTARKASTUSMENETTELYT 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ätiedotPROJEKTIN 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ätiedotA14-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