1 010758002 Ohjelmistotuotanto - Spesifikaatiot ja dokumentointi Kevät 2005 Jani Vaara LTY/Tite.

Esitys aiheesta: "1 010758002 Ohjelmistotuotanto - Spesifikaatiot ja dokumentointi Kevät 2005 Jani Vaara LTY/Tite."— Esityksen transkriptio:

1 1 010758002 Ohjelmistotuotanto - Spesifikaatiot ja dokumentointi Kevät 2005 Jani Vaara LTY/Tite

2 2 Sisältö Speksaamisesta yleisesti Kuvaustekniikat ja menetelmät Dokumentointi

3 3 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

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

5 5 Ohjelmistojen tuottaminen ~ speksien tuottamista

6 6 Ohjelmiston tuotantoprosessi Tuotantoprosessi on vaiheittainen kuvaus järjestelmän vaatimuksista niiden toteuttamiseksi. Jokaisella tasolla tuotetaan seuraavan tason vaatimukset (speksi, speisfikaatiodokumentti) Speksien esittämiseksi tarvitaan kuvauskieliä: –Ylimmällä tasolla kuvauskieli usein luonnollinen kieli –Alimmalla tasolla ohjelmiston toteutus jollain toteutusvälineellä, esimerkiksi ohjelmointikielellä.

7 7 Speksattavat asiat (pelkistetty kuva) Spesifikaatio N spesifiointi toiminnalliset vaatimukset ei-toiminnalliset vaatimukset reunaehdot ja rajoitteet Spesifikaatio N+1 toiminnalliset vaatimukset ei-toiminnalliset vaatimukset reunaehdot ja rajoitteet Verifiointi esimerkiksi tarkastamalla vaatimukset testaussuunnitelmat edellisen version spesifikaatiot

8 8 Spesifioinnin prosessista Syötespesifikaatio on usein virheellistä, puutteellista ja ristiriitaista –Aikaisempiin spesifiontivaiheisiin joudutaan usein palaamaan. Jos olemassa olevasta tuotteesta tuotetaan uutta versiota, vaiheen syötteenä on uuden spesifikaation lisäksi myös edelliseen versioon liittyviä spesifikaatiota –Uudet spesifikaatiot eivät tällöin kuvaa projektin tuloksena syntyvää tuotetta, vaan muutoksia joita tehdä olemassa olevaan tuotteeseen.

9 9 Hyvän speksin merkitys Hyvä spesifikaatio on usein jokaisen vaiheen tärkeimpiä onnistumistekijöitä. Määrittelyvaiheessä tehdyt virheet tulevat myöhemmissä vaiheissa kalliiksi. Määrittelyä tekevien tulee tietää aloitusvaiheen oikeat toimintatavat. Loppukäyttäjien tulee olla mukana spesifioinnissa erityisesti käyttötapauksien ja käyttöliittymän osalta.

10 10 Hyvän speksin ominaisuudet 1/3 jokseenkin samat kuin yksittäisen vaatimuksen ominaisuudet! –täydellisyys: spesifikaatio määrittelee kaikki tarpeelliset asiat ja vain ne. –tarkkuus –virheettömyys –ymmärrettävyys: usein ristiriitainen edellisten kanssa.

11 11 Hyvän speksin ominaisuudet 2/3 –testattavuus: testausvaiheessa on mahdollista verrata spesifikaatiota ja toteutettua järjestelmää ja verifioida onko järjestelmä spesifikaation mukainen. –jäljitettävyys: on mahdollista muodostaa katkeamaton ketju asiakasvaatimuksista aina toteutukseen asti.

12 12 Hyvän speksin ominaisuudet 3/3 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ää?!

13 13 Täydellisen speksin mahdottomuus Spesifikaatiossa on kytännössä aina virheitä, puutteellisuuksia ja moniselitteisyyksiä, joita joudutaan ratkomaan projektin myöhemmissä vaiheissa. Eri osapuolet ymmärtävät jonkin speksatun asian eri tavoilla. Täydelliseen spesifikaatioon pyrkiminen voi olla ongelma, ”analysis paralysis”

14 14 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 (Structured Analysis), OMT, OMT++ Kuvaustekniikat täydentävät luonnollisella kielellä tehtyjä spesifikaatioita.

15 15 Kuvaustekniikoiden merkitys Toimivat suunnittelutyön apuvälineinä, joiden avulla kuvausta laativat henkilöt voivat: –kommunikoida keskenään –analysoida työnsä tuloksia Käytetään työn tulosten dokumentointiin niiden siirtämiseksi seuraavan vaiheen syötteeksi. –Osa tehdyistä kuvauksista voidaan unohtaa työdokumenttien luonteisina seuraavaan vaiheeseen siirryttäessä.

16 16 Spesifiontimenetelmät Kuvaustekniikat sisältävät esim. käyttötapauskaaviot, luokkakaaviot, tilakaaviot, tapahtumasekvenssikaaviot Menetelmä = kuvaustekniikat + ohjeistus –esim. SA/RT, OMT, Octopus, Fusion… Menetelmät usein tarkoitettu käytettäväksi vain yhdessä ohjelmistotyön vaiheessa. –Esim. SA-menetelmä tarkoitettu ensisijaisesti vaatimusten analysointiin ja määrittelyyn mutta sovellettavissa myös sunnitteluvaiheessa.

17 17 Menetelmien soveltaminen Käytännön ohjelmistotyössä menetelmillä ei ole kovin suurta merkitystä –suurin osa ohjelmistoista tehdään noudattamatta tarkasti mitään menetelmää. Yleistä kaikkiin tilanteisiin sopivaa menetelmää ei ole olemassa. –Laatujärjestelmät eivät yleensä ota kantaa, millä menetelmällä dokumentit tuotetaan. Menetelmien tarkassa noudattimessa on se vaara, että yritetään sovittaa ongelmaa menetelmiin, eikä päinvastoin.

18 18 Menetelmän ohjeistus Menetelmät näkyvät laatujärjestelmässä yleensä ohjeistettuina dokumentteina. –esim. oliokeskeisessä ohjelmistotuotannossa määrittelydokumenttimallissa on paikka mm. käyttötapauskaavioille ja luokkakaavioille. Uuden työntekijän kannalta on kuitenkin hyvä että jokaiseen työvaiheeseen on selkeät menetelmät. –mahdollistaa itsenäisen työskentelyn –kokeneet suunnittelijat voivat sovittaa menetelmät kuitenkin kulloiseenkin tilanteeseen sopiviksi.

19 19 Menetelmistä Informaalit (vapaamuotoiset) menetelmät Puoliformaalit menetelmät Formaalit (muodolliset) menetelmät

20 20 Informaalit menetelmät Seinätaulumenetelmä tyyppisen menetelmä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ä

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

22 22 Formaalit menetelmät Matemaattisia, usein formaaliin logiikkaan perustuvia täsmällisiä spesifiointimenetelmiä Kieli, jolla on tarkasti määritelty sanasto, syntaksi ja semantiikka esimerkkeinä Z ja VDM. 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 keskeneräisyyksistä.

23 23 Formaalit spesifikaatiot Ovat usein epähavainnollisia –täydellisyys vs. ymmärrettävyys Joitakin formaaleja spesifikaatioita voidaan animoida, jolloin niiden oikeellisuus voidaan todeta ennen järjestelmän toteutusta. Joissakin formaaleissa menetelmissä spesifiointi voi edetä asteittain tarkentuen –oikeellisuus säilyy ja on todistettavissa

24 24 Dokumentointi Laadukkaiden dokumenttien tuottaminen on käytännön ohjelmistotyön heikoimpia lenkkejä –Aikataulujen kiristyessä dokumenttien tuottaminen jää usein vähemmälle huomiolle tai se tehdään jopa jälkikäteen. Kiireisissä projekteissa kaikkia määrittelyyn ja suunnitteluun liittyviä asioita ei kirjata kunnolla –Jos ohjelmistoon tehtyjä muutoksia ei kirjata dokumentteihin, dokumentit muuttuvat vähitellen hyödyttömiksi.

25 25 Dokumentoinnin riittävyys Dokumentointimallit ja tarkastusmenettelyt dokumentoinnin helpottamiseksi ja riittävyyden sekä laadun 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

26 26 Dokumentoinnin riittävyys Ei dokumentointia dokumentoinnin vuoksi, vaan tilanteen mukaan, sisältö ratkaisee Dokumentaation määrä riippuu projektin koosta ja monimutkaisuudesta. Tietty perusdokumentaatio tuotetusta järjestelmästä tulee kuitenkin löytyä –Ylläpidon mahdollistaminen –Työnsäästöjä tuoteen myöhemmissä versioissa

27 27 Dokumentointi Minimidokumentaatio: –Määrittely- ja suunnitteludokumentaatio, testaussuunnitelma, testausrawportti 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)

28 28 Ohjelmistokehityksen dokumentaatio Laatukäsikirjaan liittyvät dokumentit Projektinhallintaan liittyvät dokumentit Tuotedokumentit –Projektikohtaiset tuotedokumentit –Tuotekohtaiset tuotedokumentit

29 29 Dokumenttityypit Laatujärjestelmän raportit: mittaus, auditointi... Projekti- suunnitelma Syötedoku- mentit Tulosdoku- mentit Työdokumentit Ohjaus ja seuranta Projekti Seurantaraportit, tarkastus- pöytäkirjat tuotedokumentaatio projektinhallintadokumentaatio ohjeistus Laatujärjes- telmän ohjeistus Laatujärjestelmä Tuotekohtai- set ohjeet

30 30 Esimerkki tuotedokumentaatiosta Alustavat versiot vihreällä

31 31 Laatujärjestelmän dokumentit Esimerkiksi laatukäsikirja, ohjeistukset, dokumenttimallit, laatujärjestelmän auditoinnin raportit ja jotkin kokouspöytäkirjat. Myös tarkistuspöytäkirjat, vikailmoitukset, projektin resurssi- ja työmääräennusteet voidaan lukea laatujärjestelmään. –Kertovat laatujärjestelmän toiminnasta ja laadusta –voidaan analysoida laatujärjestelmän kehittämiseksi.

32 32 Projektinhallinnan dokumentit Ominaista projektiin liittyvä kertaluonteisuus, mm. –asiakkaan kanssa tehty sopimus järjestelmän toteuttamisesta –projektisuunnitelma –projektin seurantaraportit ja loppuraportti Kun projekti on ohi, tarvittavat dokumentit arkistoidaan.

33 33 Dokumentointi EVO-mallissa Järjestelmän kehittäminen ensimmäisen version jälkeen aloitetaan edellisen version pohjalta (nyt tehtävä versio merkitään k+1). Projektissa tehtävät asiat ovat lisäyksiä, muutoksia ja korjauksia versioon k. Spesifikaation käyttö tiedon siirtäjänä monimutkaistuu siirryttäessä vaiheesta toiseen.

34 34 EVO-malli

35 35 Ohjelmistosuunnitelu, tuotteen versio k+1

36 36 Tuotedokumentoinin päivitys Tuotetason dokumentaatio jää usein päivittämättä projektikiireiden takia. –> Tuotteen tekninen määrittely ei ole ajantasalla Tuotteentekninen määrittely kannattaakin kirjoittaa yleisellä tasolla –Pienet muutokset eivät aiheuta päivitystarvetta –Yksityiskohdat voidaan piilottaa projektin tekniseen määrittelyyn, koska sen ylläpito päättyy projektin päättyessä.

37 37 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!

38 38 Esimerkki: pienen ohjelmistoyrityksen ohjelmistohankkeen kulku neuvottelut/ valmistelu tehtävää koskevat asiakirjat Overflow Oy asiakas resurssit, ideat tarpeet asetta- minen projekti tai hanke käyttöön- otto tuotekansio käyttö Palaute

39 39 Esimerkki: pienen ohjelmistoyrityksen projektin dokumentaatio tarkastukset alustava projektisuun- nitelma tarkennettu projektisuun- nitelma loppuraporttikokouspöytäkirjat toiminallinen määrittely tekninen määrittely ohjelmakoodi Työn vaiheistus Katselmukset hyväksymis- katselmus suunnittelu- katselmus projek- tin käyn- nis- tämi- nen projek- tin päät- tämi- nen määrittely- katselmus suunnittelu tarkastukset määrittely ohjelmointi tarkastukset integrointitestaus järjestelmätestaus testaus- raportti - Projektiohje - Määrittelyohje - Tarkastusohje - Ohjelmointiohje - Testausohje - Suunnitteluohje Projektisuunnittelu, seuranta ja ohjaus Ohjeistukset järjestelmä- testaus- suunnitelma Pöytäkirjat

40 40 Dokumentointimallit Kaikkien dokumenttien ulkoasun yhdenmukaisuus –Dokumentti alkaa kansilehdellä (sisältää ainakin organisaation ja projektin nimien, dokumentin nimen, versionumeron, tekijät ja tilan) Osana laatujärjestelmän dokumentaatiota soveltamisohjeineen Tyyliopas lähdekoodin dokumentointia varten –modulin ulkoasu, muuttujien nimet, sisennykset, kommentoinnit, suosituksia työkalujen käytöstä

41 41 Dokumentointimallistandardeja 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

42 42 Määrittely: toiminnallinen määrittely (IEEE 830) 5. Ulkoiset liittymät 5.1.Käyttöliittymä 5.2.Laitteistoliittymät 5.3.Ohjelmistoliittymät 5.4.Tietoliikenneliittynnät 6. Muut ominaisuudet 6.1.Suorituskyky 6.2. Käytettävyys, toipuminen, turvallisuus jasuojaukset 6.3.Ylläpidettävyys 6.4.Siirrettävyys, yhteensopivuus 6.5.Operointi 7. Suunnittelurajoitteet 7.1.Standardit 7.2.Laitteistorajoitteet 7.3.Ohjelmistorajoitteet 7.4.Muut rajoitteet

43 43 Suunnittelu: tekninen määrittely (IEEE 1016)

44 44 Esimerkki dokumenttimallista Ohjetekstejä, poista ennen viimeistä versiota!