DI Uolevi Nikulaprof. J Sajaniemi, prof. H Kälviäinen

15.5.2001 Uolevi Nikula, LTKK 2

JohdantoTutkimustuloksiaTulevaisuudensuunnitelmia

15.5.2001 Uolevi Nikula, LTKK 3

Software Engineering –termi esitelty 1968Requirements Engineering (RE) –termi esitelty 1973RE aktiivinen tutkimusalue 90-luvullaKirjallisuusbuumi 90-luvun lopussa

15.5.2001 Uolevi Nikula, LTKK 4

Vaatimus [huom. vapaasti suomennettuna]Vaatimukset ovat tietokoneen ohjelmoinnin aiheuttamia vaikutuksia sovellusalueeseen. (Kovitz 1999, p.34)

Vaatimusmäärittely (vm/RE)Vaatimusmäärittely on ohjelmistotuotannon alue, joka keskittyy ohjelmistojärjestelmien reaalimaailman tavoitteisiin, toiminnallisuuksiin sekä rajoitteisiin. Se sisältää myös näiden tekijöiden liittymisen ohjelmistojen tarkkoihin käyttäytymisen määritelmiin ja niiden kehittymisen ajan kuluessa sekä eri ohjelmistoperheissä. (Zave 1997)

Vaatimustenhallinta (RM)Systemaattinen lähestymistapa järjestelmän vaatimusten keräämiseen, järjestämiseen ja dokumentointiin sekä prosessi, joka luo ja ylläpitää asiakkaan ja projektitiimin välistä sopimusta järjestelmän muuttuviin vaatimuksiin liittyen. (Leffingwell & Widrig 1999, p.16)

15.5.2001 Uolevi Nikula, LTKK 5

Vaatimusmäärittely

Vaatimusten kehittäminen Vaatimustenhallinta

Selvitys Analyysi Määrittely Verifiointi

Wiegers 1999, p.19

15.5.2001 Uolevi Nikula, LTKK 6

Vaatimusten selvitys (elicitation)Haastattelut, kyselyt, ryhmätyösessiot, workshopit, snow card, etnografia, contextual design, protot, ...

AnalyysiTarkastukset & työkalut: täydellisyys, ristiriidattomuus, priorisointi, jäljitettävyys, ...

Määrittely/dokumentointiConOps (1362), SRS (830), Volére, use case, FM, ...

VerifiointiTarkastukset, katselmoinnit

15.5.2001 Uolevi Nikula, LTKK 7

Analysoi,dokumentoi,katselmoi,neuvottele

Vaatimustenmuutos-prosessi

Sovitut vaatimukset

Markkinointi, asiakkaat, johtovaatimukset

Vaatimustenkehittäminen

tarkistettubaseline

nykyinenbaseline

Vaatimustenhallinta

Markkinointi, asiakkaat,

johto

Projekti-ympäristö

projekti-muutokset

vaatimustenmuutokset

Wiegers 1999, p.21

15.5.2001 Uolevi Nikula, LTKK 8

CHAOS raportti, Standish Group, 1995Arviolta 250 miljardia USD käytetään vuosittain IT kehitykseen n. 175 000 projektissaStandish Group tutki 3682 projektia 365 yrityksessäTutkimuksen perusteella arvioitiin, että amerikkalaiset yritykset ja hallitus käyttivät vuonna 1995 81 miljardia USD peruttuihin projekteihin ja tämän lisäksi 59 miljardia USD pitkittyneisiin projekteihinOnnistumisprosentti 16.2%; riitautettuja 52.7%; peruttuja 31.1%Jokaista 100 alkanutta projektia kohden oli 94 uudelleenaloitustaKeskimääräinen kustannusylitys oli 189% alkuperäisestä arviostaKeskimääräinen pitkittyminen oli 222% alkuperäisestä arviostaKeskimäärin vain 61% alkuperäisten määritysten mukaisista toiminnoista ja ominaisuuksista toteutettiin näissä projekteissa

15.5.2001 Uolevi Nikula, LTKK 9

Projektien onnistumiseen johtaneet tekijätKäyttäjien osallistuminen 15.9%Johtoportaan tuki 13.9%Selvästi kirjatut vaatimukset 13.0%

Projektien riitauttamiseen johtaneet tekijätKäyttäjien palautteen puuttuminen 12.8%Epätäydelliset vaatimukset ja määritykset 12.3%Muuttuvat vaatimukset ja määritykset 11.8%

Projektien perumisen aiheuttaneet tekijätEpätäydelliset vaatimukset 13.1%Käyttäjien osallistumisen puute 12.4%Resurssien puute 10.6%

15.5.2001 Uolevi Nikula, LTKK 10

Vaatimusten epäonnistunut tunnistaminen on yksi tärkeimpiä syitä asiakkaiden tyytymättömyyteen toimitettuihin järjestelmiin (Macaulay 1996)

15.5.2001 Uolevi Nikula, LTKK 11

Kaikki prosessimallit sisältävät vm:nVesiputousmalli, Royce 1970

• Järjestelmän toteuttamiskelpoisuus, ohjelmistosuunnitelmat ja määritykset, tuotteen suunnittelu, koodaus, integrointi, käyttöönotto, käyttö ja ylläpito

Spiraalimalli, Boehm 1988• Periaatteessa sisältää vesiputousmallin erikoistapauksena• Kierros 0: Toteuttamiskelpoisus; Kierros 1: Toimintojen määrittely;

Kierros 2: Korkeimman tason vaatimusmäärittely; jne.RAD malli, Pressman 2001 (90-luvun alussa)

• Liiketoimintojen mallinnus, tietomallinnus, prosessimallinnus, sovelluksen generointi, testaus & luovutus

Extreme Programming, XP, Beck 1999• ”XP on kevyt menetelmäoppi pienille ja keskisuurille tiimeille, jotka

kehittävät ohjelmistoja epämääräisiin tai nopeasti muuttuviin vaatimuksiin perustuen.”

15.5.2001 Uolevi Nikula, LTKK 12

Vaatimusmäärittelyä on tutkittu ja tehty jo yli 30 vVaatimusmääritelytietous ei ole vieläkään jokapäiväisessä käytössä teollisuudessaTerminologia (ja menetelmät) eivät ole vielä vakiintuneitaLiiketoiminta- tai asiakaskeskeisyys tarkoittaa vaatimuskeskeisyyttäVaatimukset ovat kiinteä osa kaikkia realistisia ohjelmistokehitysmalleja

15.5.2001 Uolevi Nikula, LTKK 13

Nykytilankartoitus – TBRC RR1, 2 konf.paperia”A State-of-the-Practice Survey on Requirements Engineering in Small- and Medium-Sized Enterprises”

Lea Reinikaisen diplomityö – RR4, konf.paperi”Elicitation of Customer Requirements with Group Methods in Software Engineering”

Markus Mannion Erikoistyö – RR5”Requirements Elicitation Using a Combination of Prototypes and Scenarios”

Satu Alaoutisen RM työkalukatsaus – QURE esitys

”Are RM Tools of Any Practical Use?”

15.5.2001 Uolevi Nikula, LTKK 14

Yritykset12 pk-yritystä, 6 kaupunkia, 4-1000+ työntekijää, liikevaihto 2-100 mmk

Tutkimusmenetelmätrakenteinen haastattelukysymykset pääosin kirjallisuudesta: Jackson 1995, Sommerville and Sawyer 1997 ja IEEE Std 830-1998

Kevyt RE-kypsyysarvioREAIMS-malli

15.5.2001 Uolevi Nikula, LTKK 15

0

2

4

6

8

10

12

Conf. mgmt Testing CASE RM

Työntekijöiden rooleissa

Ohjelmistokehitystyökaluissa

024

68

Des UI/DB Sys. anal. Tech writer Testers All dev.

15.5.2001 Uolevi Nikula, LTKK 16

0 3 6 9 12

1. Std doc structure2. Use simple language

3. Formal insp. done4. Easy change planned

5. Reqs have unique id6. Reqs template used7. Anal. checklist used

8. Conflict resol. planned9. RM policies defined

10. Doc checklist defined

Company count

Standard

Normal

Discret.

Never

REAIMS Top Ten –käytännöt

15.5.2001 Uolevi Nikula, LTKK 17

0369

12151821242730

1 2 3 4 5 6 7 8 9 10 11 12Company

Poin

t Gai

n

REAIMS Top Ten –pisteet

15.5.2001 Uolevi Nikula, LTKK 18

Kysytyt kirjat ja RM työkalut7 kirjaa: Davis 1993, Gause & Weinberg 1989, Jackson 1995, Kovitz 1999, Robertson & Robertson 1999, Sommerville & Sawyer 1997, Thayer & Dorfman 199713 RM työkalua INCOSE työkaluvertailusta 6/1999

15 haastatellusta4 tunnisti 1 kirjan1 tunnisti 2 kirjaa10 ei tunnistanut yhtään kirjaa7 tunnisti 1-3 työkalua8 ei tunnistanut yhtään työkalua

15.5.2001 Uolevi Nikula, LTKK 19

Yleensä tietokantapohjaisia (dokumentti/tietomallinnus)Perusominaisuuksia

Haku eri kenttien arvojen perusteellaLajittelutJäljitettävyysMuutostenhallinta/versionhallintaOikeuksienhallinta/tietoturvaDokumenttien generointi

Kaupalliset työkalut n. 15 tmk –Ks. INCOSE vertailu internetissä

15.5.2001 Uolevi Nikula, LTKK 20

RM työkaluista ja niiden valinnasta on kirjoitettu varsin paljonAiheesta ei ole juurikaan kirjoitettu akateemisia tutkimuspapereitaTutkimukset on tehty yleensä johonkin projektiin tai yritykseen tarpeisiin liittyen – ja julkaistu muutamissa tapauksissaHarvat tutkimukset sisältävät ajantasalla olevaa tietoa työkaluistaVihjeitä tulevaisuuden suunnista on vaikea löytää

15.5.2001 Uolevi Nikula, LTKK 21

Useimmat yritykset käyttävät yhä satunnaisia menetelmiä epäjärjestelmällisestiErinomaisuus riippuu ihmisistä ja heidän toimintatavoistaan – yrityksen koko tms. ei näytä ennustavan sitäMeidän tulokset vahvistavat tutkimustulosten hitaan siirtymisen käytäntöönMeidän tavoitteena on läheinen yhteistyö teollisuuden kanssa

15.5.2001 Uolevi Nikula, LTKK 22

Kahden diplomityön aloitus kesällä• Yana – liiketoimintamallinnus• Anna – arkkitehtuurivaatimukset/RE?

MiRE – Minimum REtSoft-hanke

15.5.2001 Uolevi Nikula, LTKK 23

Mikä on vähintä, mitä ohjelmistokehityksessä pitäisi tehdä vaatimuksiin liittyen ja kuinka nämä asiat kannattaisi tehdä?Teknologiansiirto tutkimusyhteisöstä jokapäiväiseen ohjelmistokehitykseenPeruselementit:

VaatimusmäärittelydokumentitProsessiTyökalutuki/automatisointiMittaaminen

15.5.2001 Uolevi Nikula, LTKK 24

Menetelmän määrittely 2001Menetelmän käytännön testaus Q4/2001-

15.5.2001 Uolevi Nikula, LTKK 25

IEEE:llä on 8 vaatimusmäärittelyä sivuavaa standardiaRational Unified Process (RUP) sisältää pohjat 7 eri vaatimuksiin liittyvälle dokumentilleYksi vaihtoehto dokumentin pohjaksi löytyy tSoft:n kotisivuilta

15.5.2001 Uolevi Nikula, LTKK 26

Vaatimusmäärittelytutkimus on Joensuun yliopiston ja LTKK:n välistä yhteistyötäKontaktihenkilö Joensuussa on prof. J SajaniemiAjatuksia mahdollisista yhteistyön muodoista otetaan vastaan ja niihin reagoidaan mahdollisuuksien mukaan

15.5.2001 Uolevi Nikula, LTKK 27

Vaatimusmäärittely/teknologiansiirto on kiinnostava tutkimusalueKäytännön ohjelmistokehitys hyödyntää harvoin edes perustuloksia tutkimuspuoleltaVaatimusmäärittelyalue sisältää hyvin käytännönläheisten ongelmien lisäksi hyvin teoreettisia ongelmiaVaatimusmäärittely/Ohjelmistotuotanto/Tieto-järjestelmätieteet ovat ajoittain lähempänä sosiologiaa kuin insinööritieteitä

15.5.2001 Uolevi Nikula, LTKK 28

Onko teillä kehitystarpeita vaatimusmäärittelyyn liittyen?Liittyvätkö ne

VaatimusmäärittelydokumentteihinProsessiinTyökaluihin/automatisointiinMittaamiseen

Haluatteko kehittää vm-toimintojanne tSoftin yhteydessä?

15.5.2001 Uolevi Nikula, LTKK 30

Beck K. Extreme Programming Explained. Addison Wesley, New Jersey, 1999Boehm BW. A Spiral Model of Software Development and Enhancement.

Computer vol. 31, no. 5, May 1988, pp. 61-72Davis AM. Software Requirements: Objects, Functions, and States. Prentice Hall,

1993Gause DC, Weinberg GM. Exploring Requirements: Quality Before Design.

Dorset House, New York, 1989INCOSE. Tools Survey: Requirements Management (RM) Tools. Available in

www.incose.org/tools/tooltax.html, accessed May 11, 2001Jackson M. Software Requirements & Specifications – a lexicon of practice,

principles and prejudices. Addison-Wesley, 1995Kovitz BL. Practical Software Requirements: A Manual of Content and Style.

Manning Publications Company, 1999Leffingwell D, Widrig D. Managing Software Requirements: A Unified

Approach. Addison Wesley, New Jersey, 1999Macaulay L. Requirements Engineering. Springer-Verlag, London, 1996

15.5.2001 Uolevi Nikula, LTKK 31

Pressman, RS. Software Engineering: A Practitioner’s Approach, 5th ed. McGraw-Hill, New York, 2001

Robertson S, Robertson J. Mastering the Requirements Process. Addison-Wesley, 1999

Royce, WW. Managing the Development of Large Software Systems: Concepts and Techniques. In Proc. Wescon, Aug. 1970. Also available in Proc. ICSE 9, Computer Society Press, 1987

Sommerville I, Sawyer P. Requirements Engineering – A Good Practice Guide. John Wiley & Sons, New York, 1997

Thayer RH, Dorfman M (eds). Software Requirements Engineering, second Edition. IEEE Computer Society, Los Alamitos, California, 1997

The Standish Group. CHAOS Report. Available in www.standishgroup.com, accessed May 11, 2001

Wiegers KE. Software Requirements. Microsoft Press, Washington, 1999Zave P. Classification of Research Efforts in Requirements Enigneering. ACM

Computing Surveys vol. 29, no. 4, Dec 1997, pp. 315-321