Ohjelmistotuotanto
|
|
- Kristiina Leppänen
- 5 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 ohjelma- 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
2. Ohjelmistotuotantoprosessi
2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa
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ä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ä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ä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ä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ätiedotOhjelmistotuotanto
581259-4 Ohjelmistotuotanto Juha Taina Helsingin yliopisto Tietojenkäsittelytieteen laitos 1. Johdanto Mitä on ohjelmistotuotanto? Ohjelmisto, ohjelmointi, tekniikkaa, insinööritaitoa, kurinalaisuutta,
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ä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ä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ä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ä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ä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ä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ä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ä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ä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ä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ä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ä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ä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ä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ä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ä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ä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ä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ä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 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ä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ä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ä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ä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ä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ä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ä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ä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ä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ä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ätiedot4. 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, 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ä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ätiedotOT-s200: Prosessimallit
Ohjelmistoprosessi Ohjelmistotuotanto Ohjelmistoprosessi Ohjelmiston elinkaari Ohjelmiston rakentamisen vaiheet ja niiden tulokset Ohjelmiston elinkaaren määrittely Yleisrakenne sille miten ohjelmisto
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ä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ä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ä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ätiedotOhjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon
582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta
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ä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ä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ä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ä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ätiedotITK130 Ohjelmistoprosessi
ITK130 Ohjelmistoprosessi Ohjelmistotuotteen elinkaari Ohjelmistoprosessimalli Koodaa ja korjaa Miksi ohjelmistoprosesseja? Prosessimallin tavoitteet Prosessi ongelmaratkaisuna Prosessi, musta laatikko
LisätiedotJohdattelua, motivointia, eli missä ollaan ja kuinka siihen on tultu
Johdattelua, motivointia, eli missä ollaan ja kuinka siihen on tultu 581259 Ohjelmistotuotanto 1 Ohjelmistotuotanto Kuinka valmistaa laadukkaita ja tehokkaita ohjelmistoja mahdollisimman edullisesti? Ohjelmistotuotanto
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ä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ä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ätiedotJuha Taina, Marko Salmenkivi ja Kjell Lemström,
Ohjelmistotuotanto Johdattelua, motivointia, eli missä ollaan ja kuinka siihen on tultu Kuinka valmistaa laadukkaita ja tehokkaita ohjelmistoja mahdollisimman edullisesti? Ohjelmistotuotanto (Software
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 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ä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ätiedotData Sailors - COTOOL dokumentaatio Riskiloki
Table of Contents 1 Johdanto.................................................................................... 1 1.1 Versiohistoria...........................................................................
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ä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ä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ätiedotKoekysymyksiä. Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistojen suorituskyky
Koekysymyksiä Ohjelmistoprosessit ja ohjelmistojen laatu 30.4.2015 58153003 Ohjelmistojen suorituskyky 1 Kurssikokeeseen tulee neljä koetilaisuudessa vastattavaa kysymystä KOKEESSA VASTATTAVAT KYSYMYKSET
LisätiedotYksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }
Yksikkötestauksella tarkoitetaan lähdekoodiin kuuluvien yksittäisten osien testaamista. Termi yksikkö viittaa ohjelman pienimpiin mahdollisiin testattaviin toiminnallisuuksiin, kuten olion tarjoamiin metodeihin.
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ä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ä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ätiedotSuunnittelun tulos. 6. Suunnittelu. Suunnitteluprosessin työvaiheet. Suunnitteluprosessi. 6.1 Arkkitehtuurisuunnittelu.
6. Suunnittelu Suunnittelun tulos Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja.
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ätiedotOhjelmistotuotanto, s
Ohjelmistotuotanto Ohjelmiston määrittely n tavoitteena on selvittää ohjelmistolle asetettavat vaatimukset niin yksityiskohtaisesti, että niiden perusteella voidaan tuottaa haluttu ohjelmisto. Lineaarisissa
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ätiedotMiten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant
Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant On mahdollista löytää Se Oikea! Luotanko sattumaan? Onnistuminen on aloitettava heti Onnistumisen kaava on 4 x
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ä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ätiedotTestausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausraportti Orava Helsinki 5.5.2005 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Juhani Bergström Peter
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ätiedotProjektisuunnitelma. (välipalautukseen muokattu versio) Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus
Projektisuunnitelma (välipalautukseen muokattu versio) Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus Ville Toiviainen Tomi Tuovinen Lauri af Heurlin Tavoite Projektin tarkoituksena
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ätiedotKäytettävyyden huomiointi ohjelmisto prosessissa testausta lisäämällä
Käytettävyyden huomiointi ohjelmisto prosessissa testausta lisäämällä Agenda Tehtävänanto Johdanto Näkökulma Ohjelmistotuotantoprosessit Testaus & arviointimenetelmät Menetelmien yhdistäminen, onnistuuko?
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ätiedotProjektisuunnitelma. Kohahdus. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Projektisuunnitelma Kohahdus Helsinki 11.12.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Taro Morimoto,
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ä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ä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ätiedotOhjelmiston testaus ja laatu. Testaustasot
Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu
LisätiedotTestaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Koskelo Helsinki 16.12.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Tom Bertell Johan
LisätiedotPS-vaiheen edistymisraportti Kuopio
PS-vaiheen edistymisraportti Kuopio Kuopio, PS-vaiheen edistymisraportti, 30.10.2001 Versiohistoria: Versio Pvm Laatija Muutokset 1.0 30.10.2001 Ossi Jokinen Kuopio2001, vain kurssin T-76.115 arvostelun
LisätiedotProjektisuunnitelma. Halaan-ryhmä. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Projektisuunnitelma Halaan-ryhmä Helsinki 22.11.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Paula Kemppi
LisätiedotERP järjestelmät. Mitä, miksi ja kuinka? Parhaita käytäntöjä. Kevät 2017 Lauri Tapola
ERP järjestelmät. Mitä, miksi ja kuinka? Parhaita käytäntöjä. Kevät 2017 Lauri Tapola Vanha liiketoimintamalli organisaation toiminta osastoperustaista. Lopputuote Raaka-aine Kaikilla funktioilla omat
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ätiedotProjektisuunnitelma Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus
Projektisuunnitelma Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus Ville Toiviainen Tomi Tuovinen Lauri af Heurlin Tavoite Projektin tarkoituksena on luoda valmis sekvenssiohjelma säätötekniikan
LisätiedotTest-Driven Development
Test-Driven Development Ohjelmistotuotanto syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole
Lisätiedot