Ohjelmistotekniikka Specifikaatiot: Määrittely, suunnittelu, työkalut ja standardit . Kevät 2002 Päivi Ovaska LTKK/Tite.

Esitys aiheesta: "Ohjelmistotekniikka Specifikaatiot: Määrittely, suunnittelu, työkalut ja standardit . Kevät 2002 Päivi Ovaska LTKK/Tite."— Esityksen transkriptio:

1 Ohjelmistotekniikka Specifikaatiot: Määrittely, suunnittelu, työkalut ja standardit
. Kevät 2002 Päivi Ovaska LTKK/Tite

2 Mää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)

3 Määrittelyprosessi

4 Asiakasvaatimusten kartoittaminen 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

5 ”Perimmäisen syyn” lö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

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

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

8 Asiakasvaatimukset vs. mää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

9 Esimerkki järjestelmän
(ohjelmisto ja laitteisto) kehitysprosessista

10 Toiminnallisen määrittelyn sisältörunko
Lähde: standardista IEEE830 vapaasti mukailtu

11 Määrittelyssä käytettyjä kuvauksia
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

12 Käyttötapauskaavio

13 Käyttötapauksen sanallinen esitys
Nimi: Luentosalin varaaminen, versio 1.0 / ijh Suorittajat: 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 vapaaksi havaitsemaltaan 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.

14 Liittymäkaavio

15 Ylimmän tason tietovirtakaaviot

16 ER-kaavio Chenin notaatiolla

17 Luokkakaavio

18 Yksinkertainen esimerkki päätöspuusta

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

20 Suunnitteluprosessi

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

22 Esimerkkejä ohjelmistoarkkitehtuuri- malleista (1)

23 Esimerkkejä ohjelmistoarkkitehtuuri- malleista (2)

24 Esimerkkejä ohjelmistoarkkitehtuuri- malleista (3)

25 Esimerkkejä ohjelmistoarkkitehtuuri- malleista (4)

26 Laitteistoarkkitehtuuri

27 Arkkitehtuurisuunnittelun tavoitteet
”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

28 Teknisen määrittelyn sisältörunko
Lähde: standardista IEEE1016 vapaasti mukailtu

29 Työ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

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

31 CASE määrittely- ja suunnitteluvä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 markkaa MetaCase, Rational Rose ja paljon paljon muita ...

32 Case-välineet ja kuvauskanta

33 Ohjelmistotuotannon standardit
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)

34 CASE-väline vai toimintapa?

35 Erilaisia 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 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.

36 IEEEn standardeja