360 likes | 610 Vues
Ohjelmistotekniikka Specifikaatiot: Määrittely, suunnittelu, työkalut ja standardit. Kevät 2002 Päivi Ovaska LTKK/Tite. Määrittely. Synonyymejä analyysi, vaatimusmäärittely Asiakasvaatimusten kartoittaminen (esitutkimus, prestudy, tarvekartoitus), toteuttavan järjestelmän määrittely
E N D
OhjelmistotekniikkaSpecifikaatiot: Määrittely, suunnittelu, työkalut ja standardit . Kevät 2002 Päivi Ovaska LTKK/Tite
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)
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
”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
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
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.
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
Esimerkki järjestelmän (ohjelmisto ja laitteisto) kehitysprosessista
Toiminnallisen määrittelyn sisältörunko Lähde: standardista IEEE830 vapaasti mukailtu
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
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.
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
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
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
Teknisen määrittelyn sisältörunko Lähde: standardista IEEE1016 vapaasti mukailtu
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
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
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 10 000-100 000 markkaa • MetaCase, Rational Rose ja paljon paljon muita ...
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)
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 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.