Ohjelmistotekniikka Specifikaatiot: Määrittely, suunnittelu, työkalut ja standardit

OhjelmistotekniikkaOhjelmistotekniikkaSpecifikaatiot: Määrittely, Specifikaatiot: Määrittely,

suunnittelu, työkalut ja suunnittelu, työkalut ja standarditstandardit

Kevät 2002Päivi OvaskaLTKK/Tite

.

MäärittelyMäärittely Synonyymejä analyysi, vaatimusmäärittely Asiakasvaatimusten kartoittaminen (esitutkimus, prestudy,

tarvekartoitus), toteuttavan järjestelmän määrittely Vaatimusten kartoitus: ”varaston kiertonopeus lisääntyy

10%”, ”energiankulutus pienenee vähintään 20%” Määrittelyssä spesifioidan nämä vaatimukset toteuttava

järjestelmä Voi olla järjestelmän määritttely (laitteisto ja ohjelmisto),

ohjelmiston määrittely, ohjelmiston osan määrittely

toiminnallinen määrittely (functional specification)

tai vaatimusmäärittely (requirement specification)

MäärittelyprosessiMäärittelyprosessi

OK

korjattavaa

MäärittelyprosessiIdeat,

lähtökohdat, rajoitteet,

reunaehdotOngelman

ymmärtäminen, vaatimusten

kartoitus

Toteutettavan järjestelmän spesifiointi

Tarkastus

Toiminnallinen määrittely, alustava

käyttöohje, toteutusprojektin

projektisuunnitelma, testaussuunnitelma

Arkkitehtuuri- suunnittelu

Asiakasvaatimusten Asiakasvaatimusten kartoittaminen ja analysointikartoittaminen ja analysointi

Tärkeä vaihe, vrt ohjelmistoprojektien top riskit Asiakasvaatimuksia kartoitetaan markkinoinnilta, omasta

organisaatiosta, tuotteen aikaisempien versioiden käyttäjiltä, prototyyppejä rakentamalla, ideointiaivoriihien tuloksena ja tutkimalla kilpailijoiden tuotteita

Alustavat asiakasvaatimukset ”toiveiden tynnyri”, tarvitaan analysointia

Asiakasvaatimuksia analysoimalla pyritään– selvittämään kunkin asiakasvaatimuksen tarve eli ”perimmäinen

syy”– arvoimaan kunkin vaatimuksen tärkeys (priorisointi)– sovittamaan yhteen ristiriitaiset vaatimukset

””Perimmäisen syyn” Perimmäisen syyn” löytäminenlöytäminen

Vaatimuksen perimmäisen syyn löytämiseksi kannattaa kysyä ”miksi?” esim.

– ”Näytön alareunassa olevan stop-nappulan on vilkuttava punaisena, kun järjestelmän muistiresursseista on enää 10% vapaana”

– System analyst: ”Miksi nappulan pitäisi tässä tilanteessa muuttua punaiseksi?

– Todellinen asiakasvaatimus: ”tässä tilanteessa on turvallisinta lopettaa järjestelmän käyttö, koska muistin loppuminen voi aiheuttaa ongelmatilanteen”

– System analyst: ”Millaisia erilaisia ratkaisuja ongelmaan voisi löytyä?” Tuotteen luonteesta riippuu, kannattaako tehdä asiakkaan

vaatimuksen mukainen toteutus vai yleisempi,laajemmalle asiakaskunnalle soveltuva ratkaisu

Vaatimusten priorisointiVaatimusten priorisointi

Priorisointi perustuu vaatimuksen pohdiskeluun liieketoiminnan kannalta

Toimivat apuna, kun päätetään, mitkä ominaisuudet otetaan mukaan ohjelmiston seuraavaan versioon ja mitkä voidaan jättää toteutettavaksi myöhemmin

esimerkkejä prioriteeteista: välttämätön, toivottu, valinnainen

Priorisoinnista apua tilanteissa, jossa aikataulupaineiden takia joudutaan karsimaan toteutettavia ominaisuuksia

Vaatimusten analysointiVaatimusten analysointi Analysoinnin tuloksena alustavat vaatimukset muuttuvat,

niitä yhdistellään, löydetään kokonaan uusia vaatimuksia Analysoidut vaatimukset voidaan ryhmitellä ja numeroida,

jolloin niihin voidaan viitata muista dokumenteista Kustakin vaatimuksesta lisäksi:

– perustelut, prioriteetti, liittymät muihin vaatimuksiin, mistä vaatimus on peräisin

– voidaan analysoida myös vaatimuksen muutosherkkyyttä-> auttaa projektin riskien arvioinnissa, projektin vaihejakomallin valintaa jne.

Asiakasvaatimukset vs. Asiakasvaatimukset vs. määrittelymäärittely

Asiakasvaatimusten perusteella tehdään ohjelmiston määrittelytyö-> yksi vaatimus voi ”kuvautua” useaksi eri toiminnoksi, yksi toiminto voi liittyä useisiin vaatimuksiin

Asiakasvaatimukset tarkentuvat ja uusia löytyy määrittelytyön aikana

kirjataan toiminnalliseen määrittelyyn

Järjes- telmä-

suunnit- telun

ohjaus ja

koordi- nointi

Järjestelmän kenttätestaus,

asiakkaan hyväksyminen

ja arviointi

Järjestelmän integrointi-

testaus

Ohjelmiston moduuli-

suunnittelu

Laitteiston yksityis-

kohtainen suunnittelu

Laitteiston alustava

suunnittelu

Ohjelmiston määrittely

Laitteiston rakentaminen,

testaus ja integrointi

Ohjelmointi, testaus,

integrointi

Ohjelmiston arkkitehtuuri-

suunnittelu

Järjestelmän suunnittelu

Laitteiston määrittely

Järjestelmän määrittely

Järjestelmän toiminnalliset vaatimuksetEsimerkki järjestelmän

(ohjelmisto ja laitteisto) kehitysprosessista

Toiminnallisen määrittelyn Toiminnallisen määrittelyn sisältörunko sisältörunko

1. Johdanto1.1. Tarkoitus1.2. Tuote1.3. Määritelmät, termit ja lyhenteet1.4. Viitteet, muut tähän liittyvät

dokumentit1.5. Yleiskatsaus dokumenttiin

2. Yleiskuvaus2.1. Ympäristö2.2. Toiminta2.3. Käyttäjät2.4. Yleiset rajoitteet2.5. Oletukset ja riippuvuudet

3. Tiedot ja tietokanta4. Toiminnot

4.n. Toiminnon kuvaus

...

5. Ulkoiset liittymät5.1. Käyttöliittymä5.2. Laitteistoliittymät5.3. Ohjelmistoliittymät5.4. Tietoliikenneliittynnät

6. Muut ominaisuudet6.1. Suorituskyky6.2. Käytettävyys, toipuminen,

turvallisuus ja suojaukset6.3. Ylläpidettävyys6.4. Siirrettävyys, yhteensopivuus6.5. Operointi

7. Suunnittelurajoitteet7.1. Standardit7.2. Laitteistorajoitteet7.3. Ohjelmistorajoitteet7.4. Muut rajoitteet

Lähde: standardista IEEE830 vapaasti mukailtu

Määrittelyssä käytettyjä Määrittelyssä käytettyjä kuvauksiakuvauksia

Toiminnan havainnollistamiseen (toiminnallinen määrittely, luku 2) käyttötapauskaavioita, liittymäkaavioita, ylimmän tason tietovirtakaavioita, luokkakaavioita, käyttöliittymäkuvauksia,

Toimintojen määrittelyn apuna tietovuokaaviot, tila-automaatit, kulkukaaviot, päätöstaulut, kommunikointikaaviot jne

Tietojen ja tietokantojen (toiminnallinen määrittely luku 3) tietohakemistokuvaukset ja luokkakaaviot

KäyttötapauskaavioKäyttötapauskaavio

Varausten poistaminen

Salinvarausjärjetelmä

Vastuu-henkilö

assistentti

ylläpitäjä

Perustietojenylläpito

Luentosalinvaraaminen

Harjoitussalinvaraaminen

Käyttäjän identifiointi

<<include>>

<<include>>

<<include>>

<<include>>

Käyttötapauksen sanallinen Käyttötapauksen sanallinen esitysesitys

Nimi: Luentosalin varaaminen, versio 1.0 / ijhSuorittajat: Kurssin vastuuhenkilöEsiehdot: Vastuuhenkilö ja kurssi on syötetty järjestelmään (KT henkilötietojen ylläpito)Kuvaus: Vastuuhenkilö seuraa WWW-linkkiä, joka johtaa järjestelmän pääsivulle. Hän syöttää järjestelmään käyttäjätunnuksensa ja salasanansa (uses: KT käyttäjän identifiointi).Käyttäjä pyytää järjestelmää näyttämään salin varaustilanteen haluamaltaan aikaväliltä. Hän saa eteensä salin lukujärjestysnäytön (ks. liite). Käyttäjä näkee näytöstä vapaat ajat sekä myös, mille kursseille sali on milloinkin varattu ja kuinka monelle viikolle. Käyttäjä tekee varauksen joltain vapaaksihavaitsemaltaan ajankohdalta. [Poikkeus: varaus ei onnistu]. Poikkeukset:Varaus ei onnistu: Varaustilanne on voinut muuttua sillä aikaa kun varaaja tekee varausta.Järjestelmä ilmoittaa tilanteesta käyttäjälle ja käyttäjä yrittää uudelleen.Lopputulos: Varaukset kurssin luentoajoiksi on tehty.Muut vaatimukset:Päivittäin käsitellään kiireisimpänäkin aikana enintään n. 100 varausta. Vastausajan on oltava alle 1 sekuntia, lukujärjestysnäytön päivitys saa kestää 5 sekuntia.

LiittymäkaavioLiittymäkaavio

tentti-ilmoittau- tuminen

ov_yhteenveto

opinto-jakso-tiedot

opiskelija-tiedot

kurssi-ilmoit-tautuminen

tulos-lista

osallistuja-lista

suoritus-kysely

suori-tukset

suoritus-kysely

KURREK

opiskelija opettaja

ylläpitäjä

opetta-jatiedot

laitoksen johtaja

Ylimmän tason Ylimmän tason tietovirtakaaviottietovirtakaaviot

ajanjakso

lämpötilatlämpötila

trigger

rekisteröi lämpötila

ohjaa rekisteröin-

tiä

lämpötila- historia

anna lämpotilat

lämpötila- anturi

rekisteröinti- tietokone

ER-kaavio Chenin notaatiollaER-kaavio Chenin notaatiolla

0:N

0:N

1:10:N

1:1 0:N

0:1

0:N

0:N 1:N osallistuu

opiskelija kurssi

opettaja

luennoi

opintojakso

<-kuvaa

suoritus

suorittaa tentti kuuluu

LuokkakaavioLuokkakaavio

suoritus

arvosanaov-määräpvm

opettajanimiosoitehenkilöNro

opintojakso

kuvaus

kurssikurssitunnusperioditlukukausi

0..1

0..*

0..1

0..*luennoi

10..* 10..*

<kuvaa

tentti

1

0..*

1

0..*kuuluu

Opiskelijanimiop.nroosoite

ilmoittaudu()

0..*1..* 0..*1..*

osallistuu

0..*

0..*

0..*

0..*

suorittaa

Yksinkertainen esimerkki Yksinkertainen esimerkki päätöspuustapäätöspuusta

e

k

e

k

e

k

punainen

keltainen

vihreä

valon väri

?

ehtiikö jarruttamaan

?


?


?

aja risteykseen

pysähdy

pysähdy

aja risteykseen

aja risteykseen

aja risteykseen

SuunnitteluSuunnittelu

Tarkoituksena muuntaa asiakkaan tarpeiden mukaan tehty määrittely tekniselle kielelle – järjestelmän toteutuksen kuvaukseksi

Jaetaan kahteen osaan: arkkitehtuurisuunnittelu ja moduulisuunnittelu

Lisää suunnitteluperiaatteista myöhemmin

SuunnitteluprosessiSuunnitteluprosessi

korjattavaa

Määrittelyvaiheesta

Toiminnallinen määrittely

Tekninen määrittely

Moduuli- suunnitelmat

Arkkitehtuuri- suunnittelu

Tarkastus

Moduuli- suunnittelu,

toteutus- suunnittelu

Ohjelmointi KoodiTarkastus

Tarkastukseen,testaukseen

Uudelleen- käytettävät komponentit

korjattavaa

Arkkitehtuurisuunnittelun tasotArkkitehtuurisuunnittelun tasot

Ohjelmistoarkkitehtuuri– Järjestelmän osien välisen työnjaon ja

rajapintojen suunnittelu

Laitteistoarkkitehtuuri– Järjestelmän fyysisten osien ja niiden välisten

rajapintojen suunnittelu

Data-keskeinen malli

Tietokanta

Sovellus 1

Sovellus 2

Sovellus 3

• “Perinteinen” arkkitehtuuri• Virhetilanteiden jäljitys haasteellista• Muutokset tietomallissa erittäin vaikeita

Esimerkkejä Esimerkkejä ohjelmistoarkkitehtuuri-ohjelmistoarkkitehtuuri-

malleista (1)malleista (1)

Tietovuoarkkitehtuuri

• Toiminnalliset kokonaisuudet vastaavat osaa toimintaketjussa

• Kukin vaihe vastaa prosessin yhtä vaihetta

Vaihe 1

Vaihe 2

Vaihe 3

“Tilauksen luonti”

“Tilauksen tietojen tallennus”

“Tilausrivien luonti”

Vaihe 4 Vaihe 4

“Tilausrivien tietojen tallennus”



K ysely-vastaus arkkitehtuuri

• Kukin tapahtuma muodostuu joukosta riippumattomia “atomaarisia tapahtumia”

• Kukin moduuli tekee ainoastaan sille annetun tehtävän tietämättä muista “samantasoisista” moduuleista

• Mahdollistaa moduulien välisten riippuvuuksien minimoinnin



K errosarkkitehtuuri

• Järjestelmä koostuu eri kerroksista joilla kullakin oma tehtävänsä

• Ydin muodostuu joukosta atomaarisia operaatioita

• Varsinainen sovelluslogiikka tuodaan vasta ylemmillä kerroksilla

• Mahdollistaa moduulien välisten riippuvuuksien minimoinnin ja uudelleenkäytettävyyden

Järjestelmän ydin

Palvelukerros

Sovelluskerros

Käyttöliittymäkerros



• Kuvataan järjestelmän fyysiset komponentit

• Kuvataan tiedonvaihto (tietoalkiot) komponenttien välillä

• Kuvataan käytetyt protokollan komponenttien välillä

UT UT

FirewallIP=xxx.xxx.xxx.xxx

WWW serverIP=xxx.xxx.xxx.xxx

HTTPS

HTTPS

App ServerIP=xxx.xxx.xxx.xxx

IIOP

Comp serverIP=xxx.xxx.xxx.xxx

DB serverIP=xxx.xxx.xxx.xxx

JDBC / proprietaryIIOP

LaitteistoarkkitehtuuriLaitteistoarkkitehtuuri

Arkkitehtuurisuunnittelun Arkkitehtuurisuunnittelun tavoitteettavoitteet

”Monimutkaisuuden hallinta” Tavoitteena on jakaa ohjelmisto mahdollisimman

vähän toisistaan riippuviin moduuleihin niin, että yksittäisen modulin sisällä tehtävät muutokset eivät säteile modulin ulkopuolelle– muutosten tekeminen helpottuu, muutokset voidaan rajata– ohjelmiston osat voidaan toteuttaa toisistaan

mahdollisimman riippumattomasti– uudelleenkäytettävyys paranee– testattavuus paranee– ylläpidettävyys paranee

tekninen määrittely

Teknisen määrittelyn Teknisen määrittelyn sisältörunkosisältörunko

1. Johdanto1.1 Tarkoitus1.2 Dokumentin kattavuus1.3 Määritelmät, termit ja lyhenteet1.4 Viittaukset muihin dokumentteihin, stan-

dardeihin, käsikirjoihin jne...1.5 Yleiskatsaus dokumenttiin

2. Järjestelmän yleiskuvausSovellusalueen kuvaus, järjestelmän osuus siinä,laitteisto- ja ohjelmistoympäristön kuvaus,toteutuksen keskeiset reunaehdot jajärjestelmän liittyminen ympäristöönsä

3. Arkkitehtuurin kuvaus3.1 Ratkaisuperiaatteet3.2 Tietokanta-arkkitehtuuri3.3 Ohjelmistoarkkitehtuuri

moduulit japrosessit.

3.4. Uudelleenkäytettävät komponentit4. Moduuli (ja prosessi) -kuvaukset

4.i Kustakin moduulista (ja prosessista) esitetään: yleiskuvaus,attribuutit (ylläpidettävät tilatiedot),operaatiot (rajapinnan määrittely),poikkeus- ja virhetilanteiden käsittely (myös "odottamattomien") sekäohjeita moduulisuunnittelua ja toteutustavarten (viittaukset käytettäviin algoritmeihin,

uudelleenkäytettävyys, jne.)Muita mahdollisia kohtia

Ylläpito-ohjeetSiirrettävyysVirhetilanteiden käsittelyLuotettavuusErityiset tekniset ratkaisutHylättyjä ratkaisuvaihtoehtoja, miksi ne hylättiinKäyttöliittymä, jos ei tarkasti määrittelyssäRatkaisun rajoitteetTestattavuusJäljitettävyys

Lähde:standardistaIEEE1016 vapaastimukailtu

TyökalutTyökalut

Ohjelmistopohjaiset apuvälineet, jotka helpottavat ja edesauttavat jotain ohjelmistotyön työvaihetta

CASE (Computer Aided Software Engineering) –välineet– projektinhallintaohjelmistot– kääntäjät – editorit– piirtotyökalut– sovelluskehittimet, jne

CASE-välineetCASE-välineet

edustavälineet (upper-CASE, front-end)– määrittely ja suunnitteluvaiheiden apuvälineet

taustavälineet(lower-CASE, back-end)– toteutusvaiheen apuvälineet, esim. kääntäjät,

sovelluskehittimet

IPSE (Integrated Project Support Environment) – kaikki ohjelmistoprojektiin liittyvät työkalut

integroitu yhtenäiseksi työvälineeksi

CASE määrittely- ja CASE määrittely- ja suunnitteluvälineetsuunnitteluvälineet

Yksinkertaisimmat kaavioiden piirtovälineitä Monipuolisemmat perustuvat kuvauskantaan, joka

sisältää kaikki ohjelmistosta tehdyt kuvaukset– jossain välineissa voidaan suorittaa automaattista

koodin generointia– erilaisia analysointi- animointi- ja protoilutyökaluja

Melko kalliita PC-pohjaiset 10 000-100 000 markkaa

MetaCase, Rational Rose ja paljon paljon muita ...

Case-välineet ja kuvauskantaCase-välineet ja kuvauskanta

Kuvauskanta

Projektinhallinta

Käytön hallinta

...

Raportit, dokumentit

Kuvausten teko ja käsittely

Analyysit, johdonmukai- suustarkistuk

set

Protoilu

Tuotteen- hallinta

Testauksen apuvälineet

Generointi: ohjelmointikieli, näytöt, raportit

...

Liittymät muihin

välineisiin

Kuvauskannan hallinta

Vaatimusten- hallinta

Tuki menetelmille ja prosessille

Ohjelmistotuotannon Ohjelmistotuotannon standarditstandardit

Standardeja ohjelmistotuotantoon julkaistu noin 500 Ohjelmistotuotannon standardisointijärjestöjä:

– IEEE (Institute of Electrical and Electronic Engineers)– ANSI (American National Standards Institute)– NBS (National Bureau of Standards)– NASA (National Aeronautics and Space Administration)– DoD (Department of Defence)– ISO (International Organisation of Standization)– ESA (European Space Agency)– KOTEL (komponenttiteollisuuden yhteistyöjärjestö– SFS (Suomen Standardisoimisliitto)– TIEKE (Tietotekniikan Kehittämiskeskus)

CASE-väline vai toimintapa?CASE-väline vai toimintapa?

Erilaisia standardejaErilaisia standardeja

De facto –standardit eli käytännön standardit esim. IBM CUA standardi

Viitekehykset standardeja, joissa määritellään alueet joille standardeja kehitetään, esim. ISO/OSI –malli

Prosessistandardit määrittävät ohjelmistoprosessin, esim. ISO 9001, ISO/IEC 15504(SPICE), CMM, IEEE 1074-1995

Ohjelmistoergonomiaan ja turvallisuuskriittisiin järjestelmiin liittyvät standardit, esim. ISO 9241

Sanastostandardit, esim. IEEE 610.2, ISO 8402 Erilaisia standardeja hankintaprojektin läpiviemiseksi,

ohjelmistotuotteiden arviointiin yms.

IEEEn standardejaIEEEn standardejaLaatujärjestelmä, prosessi: 1074-1997

määrit- tely

testausohjel- mointi

suunnittelu

Projektinhallinta: 1058.1-1998

Tuotteenhallinta: 828-1998, 1042-1987

Laadunohjaus: 730-1998, 1028-1997, 1012-1998, 1045-1992, 1061-1998 1298-1992

Dokumentointi: 1063-1987...

Määrittely: 830-1998

Käyttö, ylläpito:

1219-1998

Testaus:829-1998, 1008-1987

OhjelmointiSuun- nittelu:

1016-1998

Documents

Ohjelmistotekniikka Specifikaatiot: Määrittely, suunnittelu, työkalut ja standardit