Peruskäsitteet. Vaatimusmäärittely- ja hallinta. Vaatimusmuutosten hinta. Syyt aikataulun ja budjetin ylitykseen

Transkriptio

1 Peruskäsitteet Vaatimusmäärittely- ja hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto Vaatimusten yhteydessä puhutaan yleensä erikseen vaatimusmäärittelystä ja vaatimusten hallinnasta Vaatimusmäärittely on vaatimusten luomista ja dokumentointia Vaatimusten hallinta on kontrolloitua vaatimusmuutosten hallintaa ja liittyy siten läheisesti projektinhallintaan OHTU 2007 Sami Kollanus 2 Syyt aikataulun ja budjetin ylitykseen Vaatimusmuutosten hinta X Virheen korjaamisen suhteellinen kustannus 1 3-6X 10X 15-40X 30-70X (82X IBM keskiarvo) Vaatimusmäärittely Suunnittelu Koodaus Kehitys- Testaus Hyväksymis- Testaus Käyttöönotto, Ylläpito Chaos report 1994, OHTU 2007 Sami Kollanus 3 Boehm Software Engineering Economics. OHTU 2007 Sami Kollanus 4

2 Vaatimukset ja CMMI Vaatimusmäärittelyn vaiheet Level5 Level4 Level3 Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management Risk Management Decision Analysis and Resolution Level2 Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management Level1 Organizational Innovation and Deployment Causal Analysis and Resolution Organizational Process Performance Quantitative Project Management Aloitus Ymmärretään ongelma Vaatimusten selvittäminen Käyttäjät, liiketoiminta yms. Tarkentaminen Määritellään edellä kerätyt vaatimukset tarkemmin Neuvottelu Kaikkea ei voida toteuttaa Spesifikaatio Validointi Vaatimusten hallinta OHTU 2007 Sami Kollanus 5 Pressman 2006 OHTU 2007 Sami Kollanus 6 Vaatimusmäärittelyn vaiheet Eritasoinen spesifikaatio User requirements Client managers System end-users Client engineers Contractor managers System architects System requirements System end-users Client engineers System architects Software developers Software design specification Client engineers System architects Software developers Wiegers 2000: Describes 10 Requirements Traps to Avoid OHTU 2007 Sami Kollanus 7 Sommerville OHTU 2007 Sami Kollanus 8

3 Baseline ( lähtötaso ) baseline Käyttäjävaatimukset Vaatimusspesifikaatio Suunnitteluspesifikaatio Toteutus Testaus OHTU 2007 Sami Kollanus 9 Gilb. T Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. OHTU 2007 Sami Kollanus 10 Vaatimustyypit Toiminnalliset vaatimukset Ei-toiminnalliset vaatimukset Suorituskyky, luotettavuus, turvallisuus yms. Rajoitteet: Hinta, aikataulu, standardit, laki yms. Vaatimusmäärittelyn käytänteitä (CMMI) tunnistetaan eri osapuolten tarpeet, odotukset Luodaan asiakasvaatimukset Laaditaan tuotevaatimukset Suunnitelmien vaatima tarkkuustaso Suunnitteluratkaisut -> vaatimukset Vaatimusten väliset yhteydet -> konfiguraationhallinta Koskinen ym. 2001, 56. OHTU 2007 Sami Kollanus 11 OHTU 2007 Sami Kollanus 12

4 Vaatimusten lähteitä Asiakas Käyttäjä Rajapinnat muihin järjestelmiin Valmiskomponentti Osajärjestelmä Standardit: asiakkaan ympäristö, oma tuotelinja yms., alan yleiset standardit Markkinat Laki Vaatimusten tuottaminen Technology demonstrations Interface control working groups Technical control working groups Interim project reviews Questionnaires, interviews, and operational scenarios obtained from end users Operational walkthroughs and end-user task analysis Prototypes and models Brainstorming Quality Function Deployment Market surveys Beta testing Extraction from sources such as documents, standards, or specifications Observation of existing products, environments, and workflow patterns Use cases Business case analysis Reverse engineering (for legacy products) OHTU 2007 Sami Kollanus 13 OHTU 2007 Sami Kollanus 14 Vaatimusmäärittelyn käytänteitä (CMMI) Kohdennetaan vaatimukset toiminnoiksi komponenteiksi Rajoitukset eri komponenteille Tunnistetaan vaatimukset rajapinnoille Testijärjestelmä, tuotantotilat, yms. Analysoidaan ja validoidaan vaatimukset OHTU 2007 Sami Kollanus 15 Vaatimusdokumentin rakenne 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3. Specific requirements Appendixes Index IEEE Std OHTU 2007 Sami Kollanus 16

5 Specific requirements 3.1 External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces Specific requirements 3.2 Functional requirements User class Functional requirement n Functional requirement 1.n 3.2.m User class m 3.2.m.1 Functional requirement m m.n Functional requirement m.n IEEE Std OHTU 2007 Sami Kollanus 17 IEEE Std OHTU 2007 Sami Kollanus Specific requirements 3.3 Performance requirements Number of terminals or simultaneous users Amount and type of information handled 3.4 Design constraints Standards, hardware limitations etc. 3.5 Software system attributes Reliability, availability, security, maintainability, portability etc. 3.6 Other requirements IEEE Std OHTU 2007 Sami Kollanus 19 Vaatimusten esittäminen strukturoidusti ECLIPSE/Workstation/Tools/DE/FS/3.5.1 Function Add node Description Adds a node to an existing design. The user selects the type of node, and its position. When added to the design, the node becomes the current selection. The user chooses the node position by moving the cursor to the area where the node is added. Inputs Source Outputs Destination operation. Requires Pre-condition Node type, Node position, Design identifier. Node type and Node position are input by the user, Design identifier from the database. Design identifier. The design database. The design is committed to the database on completion of the Design graph rooted at input design identifier. The design is open and displayed on the user's screen. Post-condition The design is unchanged apart from the addition of a node of the specified type at the given position. Side-effects None Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1 Sommerville 2001 OHTU 2007 Sami Kollanus 20

6 Validointikriteerit mukaan Vaatimusten validointi Osaksi vaatimusmäärittelyä Kuinka tunnistetaan onnistunut toteutus? Minkälaisia testejä tarvitaan? Kuinka validi vaatimus on Tarvitaanko todella? Onko fiksumpaa vaatia jotain muuta? Yhdenmukaisuus Täydellisyys Realismi Verifioitavuus Pressman OHTU 2007 Sami Kollanus 21 Sommerville 2001, 137. OHTU 2007 Sami Kollanus 22 Validointitapoja Vaatimusten luokittelu- QFD Katselmoinnit Asiakas, käyttäjä, kehitystiimi Prototyypit Testitapausten luonti Automatisoitu yhdenmukaisuuden tarkistaminen Quality Function Deployment 1. Normal requirements Neuvotellut vaatimukset 2. Expected requirements Esim. käytettävyys 3. Exciting requirements Ylittää asiakkaan odotukset Sommerville 2001, 138. OHTU 2007 Sami Kollanus 23 Pressman 2006 OHTU 2007 Sami Kollanus 24

7 Vaatimusten priorisointi Vaatimusongelmia (Hall ym. 2002) Wiegersin mallissa otetaan huomioon: Hyöty (benefit) Menetys (penalty) Kustannus (cost) Riski (risk) Arvioidaan tekijöiden vaikutus vaatimukseen asteikolla 1-9 Lasketaan tunnusluku, joka ilmaisee vaatimusten tärkeyden Wiegers, K First Things First: Prioritizing Requirements. Software Development 7(9). OHTU 2007 Sami Kollanus 25 Aineisto kerätty 12 (45 ryhmää, 200 hlö) yrityksestä Englannissa Ryhmät ohjattiin keskustelemaan ohjelmistokehityksen ongelmista Laskettiin mainittujen ongelmien määrä ja luokiteltiin ongelmat Tutkittiin erikseen vaatimuksiin liittyviä ongelmia OHTU 2007 Sami Kollanus 26 kehityksen ongelmat eri tehtävissä Vaatimusongelmien luokittelu Vaatimukset 48 % Suunnittelu 7 % Koodaus 7 % Testaus 24 % Ylläpito 13 % Luokiteltiin kahteen luokkaan: Organisaatioon liittyvät 63 % Prosessiin liittyvät 37 % OHTU 2007 Sami Kollanus 27 OHTU 2007 Sami Kollanus 28

8 organisaatioon liittyvät ongelmat prosessiin liittyvät ongelmat Kehittäjien kommunikaatio 24 % Riittämättömät taidot 20 % Riittämättömät resurssit 14 % Henkilöstön pysyvyys 13 % Käyttäjien kommunikaatio 12 % Koulutuksen puute 8 % Yrityskulttuuri 8 % Epämääräiset vaatimukset 25 % Määrittämätön vaatimusprosessi 24 % Vaatimusten kasvu 23 % Sovelluksen monimutkaisuus 20 % Huono käyttäjien ymmärtäminen 4 % Riittämätön vaatimusten jäljitettävyys 3 % OHTU 2007 Sami Kollanus 29 OHTU 2007 Sami Kollanus 30 ja vielä huomio Vaatimusmäärittelyn ongelmia Tutkimuksessa oli mukana organisaatioita eri CMM:n mukaisilta kypsyystasoilta Kypsyystasolla vaikutti olevat yhteys vaatimusongelmiin Korkean kypsyystason organisaatiossa mainittiin vähemmän vaatimusongelmia Ohjelmisto on aina uusi -> ei ole valmista täydellistä mallia vaatimusmäärittelylle Käyttäjien tarpeet hyvin vaihtelevia Asiakas on usein eri kuin käyttäjä Asiakas ei osaa määritellä tarpeitaan tarpeeksi yksityiskohtaisesti ja teknisesti (tai omalla kielellä) Asiakas on liian urautunut vanhaan toimintamalliin Tuottaja ei tunne sovellusaluetta tarpeeksi Asiakas kiinnittää liiaksi toteutusta Tuottaja pyrkii vaikuttamaan liiaksi vaatimuksiin OHTU 2007 Sami Kollanus 31 Koskinen ym. 2001, OHTU 2007 Sami Kollanus 32

9 Vältä näitä 1. Hämmennys vaatimuksista: Vaatimuksilla sanana viitataan useaan eri asiaan. -> eri sidosryhmien tunnistaminen 2. Riittämätön asiakkaan osallistuminen: luotetaan telepatiaan vaatimusten välittämisessä käyttäjältä kehittäjille. -> käyttäjäluokkien tunnistaminen Vältä näitä 3. Epäselvät ja moniselitteiset vaatimukset: jokainen tulkitsee ne omalla tavallaan ja olettaa loput. -> moniselitteiset sanat, katselmoinnit, testitapaukset 4. Priorisoimattomat vaatimukset: kaikki vaatimukset ovat kriittisiä. -> Priorisointi: odotettu käytön määrä, tärkeimät käyttäjäluokat, ydinprosessit Wiegers, K Karl Wiegers Describes 10 Requirements Traps to Avoid. Software Testing and Quality Engineering 2(1). OHTU 2007 Sami Kollanus 33 Wiegers, K Karl Wiegers Describes 10 Requirements Traps to Avoid. Software Testing and Quality Engineering 2(1). OHTU 2007 Sami Kollanus 34 Vältä näitä Vältä näitä 5. Rakennetaan toimintoja, joita kukaan ei käytä -> jäljitetään vaatimuksen alkuperä 6. Analysis paralysis -> hyäksytään epätäydellisyydet, mutta suunnitellaan niiden tulevaisuus 7. Laajuuden venyminen: Vaatimuksia tulee lisää -> puskuri muutoksille, huolellinen määrittely, muutoksenhallintaprosessi 8. Riittämätön tai olematon muutoshallintaprosessi -> tarpeen mukainen prosessi Wiegers, K Karl Wiegers Describes 10 Requirements Traps to Avoid. Software Testing and Quality Engineering 2(1). OHTU 2007 Sami Kollanus 35 Wiegers, K Karl Wiegers Describes 10 Requirements Traps to Avoid. Software Testing and Quality Engineering 2(1). OHTU 2007 Sami Kollanus 36

10 Vältä näitä 9. Riittämätön muutoksen vaikutusten analysointi -> analyysi päätöksenteon tueksi 10. Riittämätön versionhallinta -> kommunikaatio, työkalu Vaatimusmuutosten lähteitä Kaikkia asiakasvaatimuksia ei ymmärretä oikein projektin alkuvaiheessa Asiakasvaatimuksia voi jäädä huomaamatta Toimintaympäristössä voi tapahtua muutoksia (organisaatio, tekniikka, ohjelmistot) Jokin määritelty ominaisuus voi osoittautua käyttökelvottomaksi Wiegers, K Karl Wiegers Describes 10 Requirements Traps to Avoid. Software Testing and Quality Engineering 2(1). OHTU 2007 Sami Kollanus 37 Haikala & Märijärvi (2002, ) OHTU 2007 Sami Kollanus 38 Vaatimusmuutosten lähteitä Vaatimusten hallinta - CMMI Aikataulupaineet -> jotain voi jäädä toteuttamatta Markkinatilanne -> kilpailija julkistaa uuden tuotteen Teknologiavalinnat osoittautuvat epäonnistuneiksi (standardit) Ymmärretään vaatimukset Kriteerit vaatimusten hyväksyntää varten, analysoidaan vaatimukset, yhteinen ymmärrys vaatimuksista Sitoumukset vaatimuksiin Hallitaan vaatimusmuutoksia Ylläpidä muutoshistoria -> perustelut Muutosten vaikutus Muutos näkyväksi projektille Haikala & Märijärvi (2002, ) OHTU 2007 Sami Kollanus 39 OHTU 2007 Sami Kollanus 40

11 Vaatimusten hallinta - CMMI Ylläpidetään jäljitettävyyttä molempiin suuntiin Tunnistetaan epäjohdonmukaisuudet ja poikkeamat vaatimuksiin nähden Projektin alussa + seuranta Muutosten hallinta Muutosprosessin määrittely Vaatimusten priorisointi Vaikutusten huolellinen analysointi Kustannukset, vaikutukset muihin vaatimuksiin tai tekniseen toteutukseen Jäljitettävyys Muutosten dokumentointi Muutosten verifiointi OHTU 2007 Sami Kollanus 41 OHTU 2007 Sami Kollanus 42