010758000 ohjelmistotekniikka spesifikaatiot ja dokumentointi
This presentation is the property of its rightful owner.
Sponsored Links
1 / 44

010758000 Ohjelmistotekniikka - Spesifikaatiot ja dokumentointi PowerPoint PPT Presentation


  • 98 Views
  • Uploaded on
  • Presentation posted in: General

010758000 Ohjelmistotekniikka - Spesifikaatiot ja dokumentointi. Kevät 2003 Hanna-Kaisa Lammi LTY/Tite. Osa materiaalista on peräisin kurssikirjasta Haikala, Märijärvi: Ohjelmistotekniikka, 2000. Sisältö. Speksaamisesta yleisesti Kuvaustekniikat ja menetelmät Dokumentointi

Download Presentation

010758000 Ohjelmistotekniikka - Spesifikaatiot ja dokumentointi

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


010758000 ohjelmistotekniikka spesifikaatiot ja dokumentointi

010758000 Ohjelmistotekniikka- Spesifikaatiot ja dokumentointi

Kevät 2003

Hanna-Kaisa Lammi

LTY/Tite

Osa materiaalista on peräisin kurssikirjasta Haikala, Märijärvi: Ohjelmistotekniikka, 2000.


Sis lt

Sisältö

  • Speksaamisesta yleisesti

  • Kuvaustekniikat ja menetelmät

  • Dokumentointi

  • Mallintamisesta ja kuvaustekniikoista


Motto

Motto

"Ohjelmistospesifikaation lukeminen on kuin pyhän kirjan lukemista - jos lukee itsekseen voi ymmärtää miten haluaa, jos pyytää jonkun selittämään, ymmärtää miten toinen haluaa, parasta olisi saada jumala (asiakas) paikan päälle selittämään mitä hän tarkoittaa."

tekn.yo Jan Laakso projektityökurssilla


Spesifikaatio

Spesifikaatio

  • Määrittely: Mitä tehdään?

  • Suunnittelu: Miten tehdään?

  • Määrittelyn ja suunnittelun sisältö vaihtelee tilanteesta riippuen, esim.

    • työasemasovelluksen määrittely näyttöjä ja toimintoja

    • sulautettujen järjestelmien ohjelmistot rajapintoja antureihin ja toimilaitteisiin

  • Määrittely ja suunnittelu (toteutus myös) spesifikaatioiden laatimista

  • Spesifikaatio määrittelee, miten vaiheen syötteet eli vaatimukset muutetaan seuraavan vaiheen vaatimuksiksi


Ohjelmistojen tuottaminen speksien tuottamista

käyttäjien

tarpeet, ideat,

Menetelmät,

rajoitukset

kuvaustekniikat

reunaehdot

mitä

esitutkimus

verifiointi

miten

asiakas-

hyväksymis-

vaatimukset

testaus

mitä

määrittely

verifiointi

miten

toiminnallinen

järjestelmä-

määrittely

testaus

mitä

arkkitehtuuri-

verifiointi

suunnittelu

miten

tekninen

integrointi-

määrittely

testaus

mitä

moduuli-

verifiointi

suunnittelu

miten

moduuli-

moduuli-

suunnitelmat

testaus

mitä

verifiointi

ohjelmointi

miten

ohjelma-

koodi

Ohjelmistojen tuottaminen = speksien tuottamista?


Speksattavat asiat pelkistetty kuva

Speksattavat asiat (pelkistetty kuva)

Spesifikaatio N

Spesifikaatio N+1

reunaehdot ja

reunaehdot ja

rajoitteet

rajoitteet

ei-toiminnalliset

ei-toiminnalliset

vaatimukset

spesifiointi

vaatimukset

vaatimukset

toiminnalliset

toiminnalliset

vaatimukset

vaatimukset

testaussuunnitelmat

Verifiointi

edellisen version

spesifikaatiot

esimerkiksi

tarkastamalla


Hyv speksin ominaisuudet

Hyvä speksin ominaisuudet

  • Sujuva ja selkeä kirjallinen esitys

    ”Jos kuukauden toteutunut myynti alittaa tavoitteet, tulostetaan raportti, ellei toteutuneen myynnin ja tavoitteen ero ole vähemmän kuin puolet edellisen kuukauden tavoitteen ja toteutuneen myynnin erosta, tai toteutunut myynti alittaa tavoitteen alle 5%.”

    Selkeää?!


Hyv n speksin ominaisuudet

Hyvän speksin ominaisuudet

  • täydellisyys

  • tarkkuus

  • virheettömyys

  • ymmärrettävyys

  • testattavuus

  • jäljitettävyys

    • jokseenkin samat kuin yksittäisen vaatimuksen ominaisuudet!


Kuvaustekniikat ja menetelm t

Kuvaustekniikat ja menetelmät

  • Kuvaustekniikat ovat ”kieliä” erilaisten asioiden ilmaisemiseksi esim. UML-kuvauskieli, käyttötapauskaaviot, luokkakaaviot, tilakaaviot

    • suunnittelutyön apuvälineitä

    • työn tulosten dokumentointivälineitä

  • Menetelmät ovat tapoja soveltaa kuvaustekniikoita, esim. SA, OMT

  • Kuvaustekniikat täydentävät luonnollisella kielellä tehtyjä spesifikaatioita.


Menetelm t

Menetelmät

  • Kuvaustekniikat sisältävät esim. käyttötapauskaaviot, luokkakaaviot, tilakaaviot, tapahtumasekvenssikaaviot

  • Menetelmä = kuvaustekniikat + ohjeistus

    • esim. SA/RT, OMT, Octopus, Fusion…

  • Laatujärjestelmät eivät yleensä ota kantaa, millä menetelmällä dokumentit tuotetaan


Menetelmist

Menetelmistä

  • Informaalit (vapaamuotoiset) menetelmät

  • Puoliformaalit menetelmät

  • Formaalit (muodolliset) menetelmät


Informaalit menetelm t

Informaalit menetelmät

  • Seinätaulumenetelmät, jossa määriteltävät asiat kuvataan muodostamalla ratkaistavasta ongelmasta suuria selkeitä kaavioita seinälle

  • Hyviä menetelmiä asiakasvaatimusten keräysvaiheessa

  • Menetelmät eivät yleensä vaadi erityiskoulutusta, vaan ovat kaikkien ymmärrettävissä


Puoliformaalit menetelm t

Puoliformaalit menetelmät

  • Käytettyjen merkintätapojen semantiikka (eli tarkoitus) ei ole kovin tarkasti määritelty vaan sitä voi tarpeen mukaan soveltaa joko enemmän tai vähemmän formaalisti

  • esim. OMT- ja SA-menetelmät


Formaalit menetelm t

Formaalit menetelmät

  • Matemaattisia, usein formaaliin logiikkaan perustuvia täsmällisiä spesifiointimenetelmiä

  • Kieli, jolla on tarkasti määritelty sanasto, syntaksi ja semantiikka

  • esimerkkeinä Z, VDM, DisCO

  • Auttavat spesifioimaan hyvin ja täydellisesti, voidaan todistaa ja todeta oikein toimiviksi

  • Merkitys käytännön ohjelmistotyössä lähes olematon johtuen vaikeudesta ja epähavainnollisuudesta


Menetelmist1

Menetelmistä

  • Yleisesti kaikkiin tilanteisiin soveltuvaa menetelmää ei ole olemassakaan

  • Käytännön ohjelmistotyössä menetelmillä ei ole niin suurta merkitystä kuin saattaisi kuvitella

  • Aloittelevalle ohjelmistosuunnittelijalle menetelmät, ”keittokirjaohjeet” ovat tärkeitä, kokenut ohjelmistosuunnittelija pystyy sovittamaan ne kulloiseenkin tilanteeseen


Dokumentointi

Dokumentointi

  • Laadukkaiden dokumenttien tuottaminen on käytännön ohjelmistotyön heikoimpia lenkkejä

  • Dokumentointimallit ja tarkastusmenettelyt dokumentoinnin helpottamiseksi ja varmistamiseksi

  • Yhdysvaltain puolustushallinnon projekteissa dokumentoinnin määrä on todettu projektin yleiseksi riskitekijäksi: dokumentointia yhtä ADA-kielen käskyä kohti n. 400 englannin kielen sanaa

  • Ei dokumentointia dokumentoinnin vuoksi, vaan tilanteen mukaan, sisältö ratkaisee


Dokumentointi1

Dokumentointi

  • Minimidokumentaatio:

    • Määrittely- ja suunnitteludokumentaatio, testaussuunnitelma, testausraportti

  • Dokumenttien sisältö:

    • Dokumentaation ylläpidettävyyden kannalta kannattaa välttää tarpeetonta tietojen toistoa: tietty kuvaus vain yhdessä paikassa

    • Erityisesti suunnitteludokumentaatiossa kannattaa tarkkuustaso valita niin, että ohjelmointivirheiden korjaamien ei välttämättä johda dokumentin päivittämiseen (esimerkiksi vain modulien rajapinnat, modulien sisäinen toiminta kommentteina koodissa)


Ohjelmistosuunnitelu tuotteen versio k 1

Ohjelmistosuunnitelu, tuotteen versio k+1


Esimerkki pieni ohjelmistoyritys

Esimerkki: pieni ohjelmistoyritys

Palaute

Overflow Oy

resurssit,

ideat

neuvottelut/

asetta-

projekti tai

käyttöön-

käyttö

valmistelu

minen

hanke

otto

tarpeet

asiakas

tehtävää

tuotekansio

koskevat

asiakirjat


Yll pitodokumentaatio

Ylläpitodokumentaatio

  • Projektin päättyessä tuotedokumentaatio muutetaan ylläpitoa palvelevaan muotoon

    • esim. käyttöohje, asennus- ja operointiohje, koulutusmateriaali ja tekninen dokumentaatio

  • Dokumentaatio asiakkaan tarpeiden mukaan!


Esimerkki pieni ohjelmistoyritys1

- Projektiohje

- Suunnitteluohje

- Määrittelyohje

- Ohjelmointiohje

- Testausohje

- Tarkastusohje

Projektisuunnittelu, seuranta ja ohjaus

tarkennettu

alustava

kokouspöytäkirjat

loppuraportti

projektisuun-

projektisuun-

nitelma

nitelma

Työn vaiheistus

määrittely

tarkastukset

suunnittelu

projek-

projek-

tin

tarkastukset

tin

käyn-

päät-

nis-

ohjelmointi

tämi-

tämi-

nen

tarkastukset

nen

järjestelmä-

integrointitestaus

testaus-

suunnitelma

järjestelmätestaus

toiminallinen

määrittely

testaus-

tekninen

ohjelmakoodi

raportti

määrittely

Katselmukset

hyväksymis-

määrittely-

suunnittelu-

katselmus

katselmus

katselmus

Pöytäkirjat

Esimerkki: Pieni ohjelmistoyritys


Dokumentointimallit

Dokumentointimallit

  • Kaikkien dokumenttien ulkoasun yhdenmukaisuus

  • Osana laatujärjestelmän dokumentaatiota soveltamisohjeineen

  • Tyyliopas lähdekoodin dokumentointia varten

    • modulin ulkoasu, muuttujien nimet, sisennykset, kommentoinnit, suosituksia työkalujen käytöstä

  • IEEEn standardisarja

  • ESAn standardi PSS-05-04 Issue 2

  • Dokumenttimallien suomenkielisiä versioita esim. http://www.cs.tut.fi/cgi-bin/laatu/sivuhaku.pl?nk_no=&nk_id=0


Esimerkki dokumenttimallista

Esimerkki dokumenttimallista

Ohjetekstejä,

poista ennen

viimeistä

versiota!


Ohjelmiston kehitt misess tarvitaan malleja

Ohjelmiston kehittämisessä tarvitaan malleja

Mallit

- mahdollistavat todellisuuden yksinkertaistamisen

- sallivat eri abstraktiotasot, laajuudet ja näkökulmat

- toimivat vaihetuotteina suunnittelumenetelmissä

- auttavat ymmärtämään sovellusaluetta

- helpottavat kommunikointia koskien järjestelmää ja

sovellusaluetta


Mallien riippuvuus

Mallien riippuvuus

Toteutus

Testaus

Analyysi

Suunnittelu

Vaatimukset

Vaihetuotemalleja


Uml unified modelling language

UML (Unified Modelling Language)

  • Standardoi ohjelmistomallien esitystavan

  • Pohjana OMT, Booch, OOSE

  • Pitkän evoluution tulos, kehittyy edelleen

  • Tarkoitettu erityisesti oliopohjaisille ohjelmistoille

  • Ei liity suoranaisesti mihinkään suunnittelumenetelmään

  • OMG:n siunaama (standardoitu 1997)

  • Nykyinen versio 1.3

  • Erittäin laaja

  • Tosiasiallinen standardi työkaluissa, kirjallisuudessa, teollisuudessa

    ks. www.omg.org


Uml sis lt

UML: sisältö

  • Johdanto: mallintaminen ohjelmistokehityksessä

    • Pikakatsaus kaavioihin

    • Laajennosmekanismit

    • Piirrosvälineet, prosessi, käyttöönotto

  • Vaatimusten mallintaminen: käyttötapauskaaviot

  • Rakenteen mallintaminen: luokkakaaviot

  • Vuorovaikutuksen mallintaminen: sekvenssikaaviot

  • Käyttäytymisen mallintaminen: tila- ja aktiviteettikaaviot


Uml n perusosat

UML:n perusosat

Elementit

Suhteet

Riippuvuus

Luokka

0..1

*

Assosiaatio

Olio

rooli

Kooste

Tila

Yleistys

(Periytyminen)

Pakkaus

Toteutus

Kommentti

jne.

jne.


Kaaviot

Kaaviot

Käyttötapaus

Käsittele puu

Kuljettaja

Sahaa tukki


Miksi k ytt tapauksia

Miksi käyttötapauksia?

  • Liittää asiakasvaatimukset järjestelmän toimintoihin

  • Mahdollistaa vaatimusten täsmentämisen

  • Mahdollistaa yhteisen käsityksen tehtävästä järjestelmästä

  • Rajaa järjestelmän ympäristöstään

  • Auttaa tunnistamaan kuka tai mikä käyttää järjestelmää

  • Määrittää järjestelmän korkean tason toiminnallisuuden

  • Auttaa jakamaan toiminnallisuuden osajärjestelmiin

  • Määrittää järjestelmän perustermit

  • Apuna olioiden tunnistamisessa

  • Voidaan käyttää ohjelmistokehityksen organisointiin (iteraatioiden suunnittelu)

  • Apuna testauksen suunnittelussa

  • Auttaa käyttöohjeiden laatimisessa


K ytt tapauksen kuvaaminen

Käyttötapauksen kuvaaminen

UML ei standardoi esitystapaa.

Käyttötapauksen sisältö voidaan kuvata esimerkiksi:

Käyttötapauksen nimi: Kuvaava nimi

Osallistujat: Mitkä aktorit osallistuvat

Tuloehdot: Mitkä ehdot ovat voimassa, kun käyttötapaus

aloitetaan (epäformaali)

Kuvaus: Epäformaali, voidaan käyttää myös sekvenssikaavioita

Poikkeukset: Poikkeustilanteet (mainitaan myös kuvauksessa)

Jättöehdot: Mitkä ehdot ovat voimassa, kun käyttötapaus

lopetetaan (epäformaali)


K ytt tapauskaavio notaatio

Käyttötapauskaavio: notaatio

Käyttötapaus sisältää

laajennuskohtia, joihin

toinen käyttötapaus

voidaan sijoittaa

Järjestelmä

Aktori: käyttötapaukseen

osallistuva käyttäjä-

tyyppi

Käyttötapaus

<<extend>>

Käyttötapaus

Käyttötapaus

<<include>>

Aktori

Käyttötapaus on

erikoistapaus

toisesta

Käyttötapaus

Käyttötapaus sisältää

toisen osanaan


Laajennusrelaatio

Laajennusrelaatio

Accounting System

Pay invoice

<<extend>>

Seller

Perform

interaction

Byer

Pay overdraft fee


Esimerkki k ytt tapauksesta

Salinvarausjärjestelmä

Varausten

poistaminen

-

Vastuu

<<include>>

Luentosalin

henkilö

varaaminen

ylläpitäjä

Perustietojen

ylläpito

<<include>>

<<include>>

Harjoitussalin

<<include>>

varaaminen

Käyttäjän

Käyttäjän

Salivuokran

Salivuokran

assistentti

identifiointi

identifiointi

laskutus

laskutus

<<actor>>

<<actor>>

vuokra

vuokra

-

-

järjestelmä

järjestelmä

Esimerkki käyttötapauksesta


Esimerkki sanallisesta k ytt tapauksesta

Esimerkki sanallisesta käyttötapauksesta

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.


K ytt tapaus ten laatimisesta

Käyttötapausten laatimisesta

  • Käyttötapauskaavio tukee käyttötapojen suhteiden kuvaamista, ei niiden sisällön kuvaamista. UML ei määrittele sisällön esitystapaa.

  • Käyttötapausten tulee olla ymmärrettävissä sekä asiakkaan että suunnittelijan kannalta.

  • Kaikkia käyttötilanteita ei voi eikä kannata antaa käyttötapauksina.

  • Käyttötapauksella tulee olla selkeä aloitustilanne ja lopetustilanne.

  • Käyttötapauksen "suuruudesta" päättäminen voi olla vaikeaa:

    • Käyttötapauksen tulisi olla suhteellisen lyhyt (yhden sivun kuvaus).

    • Käyttötapaus tuottaa käyttäjälle lisäarvoa (ei yleensä yksittäinen ohjelmiston toiminto, vaan kokonainen tuloksen tuottava ketju toimintoja).

    • Käyttötapaus ei siis yleensä ole yksittäinen ohjelmalla suoritettava toiminto (ei siis esimerkiksi: tekstin kopiointi leikkuupöydälle).


Luokkakaaviot class diagrams

Luokkakaaviot(class diagrams)

  • Oliokaavio, ER-kaavio, Entity Relationship diagram, ERD, tietoyhteyskaavio, käsitekaavio, kohdekaavio

  • Kuvaa järjestelmän käsitteitä (olioita) ja niiden keskinäisiä suhteita

  • Perinteisesti tietokantasuunnittelun väline

  • Oliokeskeisissä menetelmissä keskeisin mallinnusväline


Luokkakaavio

Luokkakaavio

KohdeHallinto

Kohde

Varasto

hallinnoi

palauta

varaa

otaKäyttöön

palauta(Kohde, Varasto)

varaa(Kohde)

otaKäyttöön(Kohde)

1

*

HenkilöAuto

ParkkiAlue

rekisterinumero

Talleta huolto-

informaatio

(palauta kutsuu)

huolla(int km)

palauta


Esimerkki martinin luokkakaaviosta

osallistuu

kuvaa

opinto-

kurssi

opiskelija

jakso

luennoi

kuuluu

suoritus

tentti

opettaja

Esimerkki Martinin luokkakaaviosta


Luokkakaavio chenin notaatiolla

Luokkakaavio Chenin notaatiolla

1:N

0:N

0:N

1:1

osallis-

opinto-

opiskelija

kurssi

<-kuvaa

tuu

jakso

1:1

0:N

0:N

0:N

0:N

kuuluu

suorittaa

tentti

luennoi

0:1

suoritus

opettaja


Mill piirr t

Millä piirrät?

  • Jos et osaa paperilla ja kynällä ei välineestä ole apua.

  • CASE (Computer Aided/Assisted Software/System Engineering)-välineet , esim. Rational Rose, Prosa, Rhapsody…)

    • Hinta verraten korkea (2-10 keur).

    • Perustuvat tietokantaan, johon talletetaan kaikki malliin liittyvät tiedot, kaaviot ovat vain “näkymiä” tietokantaan.

    • “Ymmärtävät” kaavioiden semantiikkaa ainakin jossain määrin.

    • Reverse Engineering+Forward Engineering = Round Trip Engineering.

    • Tukevat dokumentointia (esim. Soda+Rose).

    • Demot ja pienet ohjelmaesimerkit antavat usein liian ruusuisen kuvan.

    • Raskaan sarjan käyttökokemuksia ei ole julkaistu (?).

    • Oppimiskynnys korkeahko.

  • Piirto-ohjelmat (Visio, ABCFlowcharter)

    • Hinta muutamasta sadasta keur:sta ylöspäin.

    • Ainakin Visiossa melko hyvä UML-tuki, lähestyy CASE-välineen ominaisuuksia.

    • Hyvä valinta, jos ei tarvitse CASE-välineen tietokannan tuomia lisäetuja.

  • Julkisohjelmiakin löytyy verkosta.


  • Login