Prosessimallit

Ohjelmistotekniikka - Luento 2
© Jouni Lappalainen & Ilkka Tervonen
Jouni Lappalainen
Luku 2: Prosessimallit
- miten spiraalimalliin päädyttiin
- spiraalimallista (R)UP malliin
-  oman ammattitaidon kehittäminen; PSP ja TSP mallit
1
© Jouni Lappalainen
Luento 2: Prosessimallit
2
Luku 2: Prosessimallit
•  Prosessikehikon
aktiviteetit
Menetelmät
Prosessi
Sitoutuminen laatuun
© Jouni Lappalainen & Ilkka Tervonen
Työkalut
–  kommunikointi
–  projektisuuunnittelu
–  mallintaminen
–  rakentaminen
–  toimitus, jakelu,
käyttöön vieminen
(deployment)
Tasoittainen eteneminen
3
© Jouni Lappalainen & Ilkka Tervonen
Ohjelmistoprosessien kehittyminen
Leffingwell D., Agile Software Requirements, 2011
4
Prosessityypit
Kommunikointi
Proj. suunnnittelu
Mallintaminen
Rakentaminen
Toimitus
Rakentaminen
Toimitus
Lineaarinen prosessi
Kommunikointi
Proj. suunnnittelu
Mallintaminen
Proj. suunnnittelu
Mallintaminen
Evolutionaarinen prosessi
Kommunikointi
Lisäys (inkrementti)
Kommunikointi
© Jouni Lappalainen & Ilkka Tervonen
Iteratiivinen prosessi
Toimitus
Rakentaminen
Proj. suunnnittelu
Rinnakkainen prosessi
Mallintaminen
Rakentaminen
Toimitus
5
Prosessikehyksestä prosessimalleihin
How to solve it Polya 1945
–  Ymmärrä ongelma
•  kommunikointi ja analyysi
–  Suunnittele ratkaisu
•  mallintaminen ja
ohjelmistosuunnittelu
–  Toteuta suunnitelma
•  koodin generointi
–  Testaa toteutusta
•  Prosessikehyksen
aktiviteetit
»  Pressman 2005
–  kommunikointi
–  projektisuuunnittelu
–  mallintaminen
–  rakentaminen
–  toimitus, käyttöön
vieminen (deployment)
© Jouni Lappalainen & Ilkka Tervonen
•  Ohjelmistotuotannon yleiset
käytännöt
•  testaus ja laadunvarmistus
6
Käyttäjän!
tarpeet!
Vesiputousmalli
Vaatimusmäärittely!
© Jouni Lappalainen & Ilkka Tervonen
Toiminnallinen suunnittelu!
- käyttöliittymän suunnittelu!
- käyttötapausanalyysi!
Ohjelmisto-!
suunnittelu!
Toteutus!
Integrointi ja!
testaus!
Käyttöönotto !
ja ylläpito! 7
V-malli
Käyttäjän!
tarpeet!
Ohjelmisto!
käytössä!
Järjestelmä-!
testaus!
Toiminnallinen suunnittelu!
- käyttöliittymän !
suunnittelu!
- käyttötapaus-analyysi!
Ohjelmisto-!
suunnittelu!
© Jouni Lappalainen & Ilkka Tervonen
Hyväksymis-!
testaus!
Vaatimusmäärittely!
Toiminnallinen!
testaus!
Integrointi-!
testaus!
Koodaus!
Yksikkö-!
testaus!
8
Lisäyksin etenevä kehittäminen
(inkrementaalinen)
Kommunikointi!
Projektin"
suunnittelu!
Mallintaminen!
Rakentaminen!
Toimitus!
Lisäys 2
Lisäys 1
Lisäyksen n toimitus
Lisäyksen 2 toimitus
Lisäyksen 1 toimitus
Projektin kalenteriaika
9
© Jouni Lappalainen & Ilkka Tervonen
Ohjelmiston toiminnallisuus ja ominaisuusdet
Lisäys n
Nopea sovelluksen kehittäminen
(RAD, Rapid Application Development)
Tiimi n
Tiimi 2
Kommunikointi!
Projektin"
suunnittelu!
Mallintaminen!
-  liiketoiminta!
-  tieto!
-  prosessi!
Tiimi 1
Mallintaminen!
-  liiketoiminta!
-  tieto!
-  prosessi!
Rakentaminen!
-  komponenttien "
uudelleenkäyttö!
-  automaattinen "
koodigenerointi!
-  testaus!
Rakentaminen!
-  komponenttien "
uudelleenkäyttö!
-  automaattinen "
koodigenerointi!
-  testaus!
© Jouni Lappalainen & Ilkka Tervonen
Mallintaminen!
-  liiketoiminta!
-  tieto!
-  prosessi!
Toimitus!
-  integrointi!
-  jakelu!
-  palautteet!
Rakentaminen!
-  komponenttien "
uudelleenkäyttö!
-  automaattinen "
koodigenerointi!
-  testaus!
60 - 90 päivää
10
Nopea sovelluksen kehittäminen
(RAD, Rapid Application Development)
•  Milloin vaikeuksia?
© Jouni Lappalainen & Ilkka Tervonen
–  isoissa projekteissa RAD vaatii tarpeeksi henkilöitä, jotta
saadaan riittävä määrä tiimejä
–  jos projektihenkilöt eivät ole sitoutuneita tiukkaan
aikatauluun, projekti voi epäonnistua
–  jos järjestelmää ei voida jakaa aidosti moduleihin,
komponenttien rakentaminen vaikeutuu
–  jos pyritään korkeaan suorituskykyyn, joka vaatii
komponenttien viritystä (loppuvaiheessa), RAD ei
välttämättä toimi
–  RAD ei ole paras malli, jos tekniset riskit ovat suuret
(esim. kun käytettävä teknologia on uutta)
11
Evolutionaariset prosessimallit
•  Evolutionaariset mallit ovat iteratiivisia
•  Tuottavat joka iteraatiolla hieman täydellisemmän ohjelmistoversion
•  Protoilu
© Jouni Lappalainen & Ilkka Tervonen
–  kun asiakas voi kiinnittää yleiset tavoitteet ohjelmistolle, mutta ei
pysty kertomaan yksityiskohtia, prototyypin kehittäminen auttaa
–  iteraatio suunnitellaan ja toteutetaan nopeasti
–  tärkeää sopia asiakkaan kanssa periaatteista, esim. proto palvelee
vaatimusten määrittelyä, lopullinen ohjelmisto rakennetaan
noudattamaan myös laatutavoitteita
•  Spiraalimalli
–  yhdistää protoilun ja vesiputousmallin piirteitä
–  sopii suurten ohjelmistojen/järjestelmien kehittämiseen
•  jopa kattamaan tuotteen koko elinjakson
–  riskivetoinen prosessimalli, jossa kaksi perusperiaatetta
•  syklisyys: joka kierroksella tuotetaan tarkempi määrittely ja
vähennetään riskiä
•  etapit: sidosryhmät sitoutuvat kierroksella esitettyyn ratkaisuun
12
Kommunikointi
Projektisuunnittelu
Asiakkaan kommentit
ja muutosvaatimukset
Suunnittelu
-  työmäärä
-  aikataulu
-  riskianalyysi
Vaatimusten analyysi
ja projektin suunnittelu
Riskianalyysi
Asiakkaan vaatimusten
määrittely
Asiakkaan tekemä
arviointi
Ensimmäisen proton
suunnittelu
Asiakkaan tekemä
arviointi
Ensimmäisen proton
rakentaminen
Toimittaminen
-  jakelu
-  palautteet
Rakentaminen
© Jouni Lappalainen & Ilkka Tervonen
Asiakkaan vaatimuksiin
liittyvien riskien arviointi
Mallintaminen
-  analyysi
-  suunnittelu
Suunnittelu
Rakentaminen
- koodaus
-  testaus
Kehittynyt spiraalimalli, Boehm 1998
13
Inception (aloitus)
- tuotteen ominaisuudet
- alustavat käyttötapausmallit
- alustava projektihakemisto
- alustava liiketoimintacase
- alustavat riskit
- projektisuunnitelma
- vaiheet ja iteraatiot
- yksi tai useampia protoja
suunnittelu
rakentaminen
kommunikointi
julkaisu
ohjelmiston
lisäys
(inkrementti)
mallintaminen
Elaboration (kehittäminen)
- käyttötapausmallit
- tarkentavat vaatimukset
- (myös laatu)
- analyysimalli
- arkkitehtuurikuvaus
- arkkitehtuuriin perustuva
suoritettava prototyyppi
- tarkennettu riskilista
- alustava suunnittelumalli
- tarkennettu projektisuunnitelma
- alustava käyttöohje
toimitus
Transition (siirto)
- valmis ohjelmiston osa
- Beta testauksen raportit
- käyttäjän palautteet
Production (tuotanto)
Construction (rakentaminen)
- suunnittelumalli
- ohjelmistokomponentit
- integroitu ohjelmiston
uusi osa
- testisuunnitelmat
- testitapaukset
- tukidokumentit, ohjeet
- käyttöönotolle
- käytölle
- osan kuvaus
14
© Jouni Lappalainen & Ilkka Tervonen
(Rational) Unified Process
Iteraatiot
Projektin
Project
vaiheet
Työnkulut
2
3
4
5
6
7
8
© Jouni Lappalainen & Ilkka Tervonen
1
Neliön koko kertoo
aktiviteettiin
käytetystä ajasta
15
Vesiputousmallin erot RUP malliin
© Jouni Lappalainen & Ilkka Tervonen
•  Vesiputousmallissa vaiheet ja työnkulut on
yhdistetty
•  Esimerkiksi vaatimusmäärittelyvaiheessa
suoritetaan vain vaatimusmäärittelyn aktiviteetteja
•  Kaikki vaatimusmäärittelyn aktiviteetit tulisi olla
tehtynä, ennenkuin analyysivaihe alkaa
•  Iteratiivisessa projektin elinjaksossa huomataan,
että osa vaatimusmäärittelyjen työstä tapahtuu
rinnakkain analyysin kanssa
16
PSP menetelmä
•  PSP (Personal Software Process)
• 
• 
• 
• 
• 
© Jouni Lappalainen & Ilkka Tervonen
–  Humphreyn (1996) esittämä menetelmä, joka tavoitteena on
henkilökohtaisen osaamisen parantaminen
–  Menetelmässä henkilö pyrkii parantamaan työnsä laatua seuraavissa
työvaiheissa
Projektisuunnittelu
Korkean tason suunnittelu
Korkean tason suunnittelun katselmointi
Kehittäminen
Projektin jälkeinen katselmointi (postmortem)
–  PSP tarjoaa kurinalaisen ja metriikkapohjaisen tavan oppia hyviä
ohjelmistotekniikan käytänteitä.
–  Ideana on oppia tekemistään virheistä.
17
TSP menetelmä
•  TSP (Team Software Process)
–  Humphreyn (2000) esittämä menetelmä, joka tavoitteena on
ryhmätyön parantaminen
–  Menetelmässä tiimi pyrkii parantamaan työnsä laatua seuraavissa
työvaiheissa (aktiviteeteissa)
Projektin käynnistys
Korkean tason suunnittelu
Toteutus
Integrointi ja testaus
Projektin jälkeinen katselmointi (postmortem)
© Jouni Lappalainen & Ilkka Tervonen
• 
• 
• 
• 
• 
–  TSP tarjoaa kurinalaisen tavan oppia rakentamaan ohjelmistoja ja
miten samalla kvantitatiivisesti mitataan sekä prosessia että tuotetta.
–  TSP menetelmä perustuu skriptien käytölle, joilla ohjataan edellä
mainittujen aktiviteettien suorittamista.
–  TSP tunnistaa itseohjautuvat tiimit parhaiksi, niissä tiimi asettaa
tavoitteet, sovittaa prosessin tavoitteisiin, valvoo aikataulua ja
keräämiensä mittatietojen perusteella pyrkii parantamaan prosessia.
http://jounilappalainen.fi/ohjelmistotekniikka
19