1 / 36

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

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

lucien
Download Presentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OhjelmistotekniikkaSpecifikaatiot: 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 10 000-100 000 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 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.

  36. IEEEn standardeja

More Related