Ohjelmistotekniikka Vaatimustenhallinta Kevät 2002 Päivi Ovaska LTKK/Tite.

Esitys aiheesta: "Ohjelmistotekniikka Vaatimustenhallinta Kevät 2002 Päivi Ovaska LTKK/Tite."— Esityksen transkriptio:

1 Ohjelmistotekniikka Vaatimustenhallinta Kevät 2002 Päivi Ovaska LTKK/Tite.

2 Vaatimustenhallinta Ohjelmistotuotannon perimmäinen tavoite päätyä asiakasvaatimukset täyttävään ohjelmmistoon Vaatimustenhallinnan keskeisin tehtävä varmistaa, että lopputuote vastaa asiakkaan vaatimuksia – Lopputuotteessa on oltava kaikki halutut ominaisuudet ja vain ne – “Ei tullut takkia, tuli liivit”

3 Vaatimusten hallinta

4 Vaatimusten verifiointi ja validointi Verifiointi: jokaisen vaiheen päätteeksi todennetaan vaatimusten toteutuminen vertaamalla vaiheen syötedokumentteja (vaatimukset) sen tulosdokumentteihin – testausvaiheessa verrataan testien tuloksia vastaaviin specifikaatioihin (esim. järjestelmätekstauksessa toiminnalliseen määrittelyyn) Validointi(kelpoistaminen): pyritään osoittamaan, että toteutettava järjestelmä vastaa asiakkaan tarpeita ( – esim. projektin loppuvaiheessa vaatimusten toteutuminen voidaan varmistaa testaaamalla tuotetta sen oikeassa käyttöympäristössä

5 Vaatimusten jäljitettävyys Jäljitettävyys (traceability): voidaan tarvittaessa jokaisessa vaiheessa todeta, että tuote täyttää kaikki asiakasvaatimukset (eteenpäin jäljitettävyys) ja vain ne (taaksepäin jäljitettävyys) – eteenpäin jäljitettävyys: yksittäisestä asiakasvaatimuksesta voidaan päätellä, mitkä toiminnallisessa määrityksessä kuvatut ohjelmistovaatimukset täyttävät ko. vaatimuksen, edelleen mitkä osat teknisessä määrittelyssä toteuttavat ko. toiminnot – taaksepäin jäljittettävyys: Yksittäisestä koodimodulista lähtien voidaan päätellä sen liittyminen aikaisempien vaiheiden vaihetuotteisiin aina asiakasvaatimuksiin asti Jäljitettävyysmatriisi Vaatimustenhallintaohjelmisto, esim. Doors, Requisite Pro

6 Esimerkki jäljitettävyysmatriisista ”Mikä testitapaus liittyy mihinkin käyttötapaukseen?”

7 Vaatimusmuutosten hallinta Vaatimuksissa muutoksia vielä määrittelyvaiheen jälkeen (ikävä kyllä), tarvitaan muutostenhallintaa Jokainen muutos on tarkasteltava kriittisesti, mihin ja miten se vaikuttaa projektin eri vaiheissa!!!!!! Projektissa sovitut menettelyt muutostenhallintaa varten -> projektisuunnitelmassa muutostenhallinnan kuvaus Jäljitettävyys muutostenhallinnan kannalta tärkeä

8 Esimerkki erään projektin muutostenhallintamenettelystä

9 Project or product name : CR Number: Ordinal number Change originator’s name: Request date: 1999-01-01 Change description: Change request evaluation: Change list: <List the work products (documents, plans, code, data etc.) that shall be changed. Nominate person responsible for changes in each work product. Define schedule and resources for the implementation of the changes. Describe also responsibilities for the review and acceptance of the changed work products.> Information plan: Recommendation: Evaluated by: Evaluation date: 2001-01-01 Decision: <Record the decision (accept / reject). Give also reasons for the decision. Name the person(s) / group who made the decision.> Decision date: 2001-01-01 Review and acceptance of the work products: Acceptance: Acceptance date: 2001-01-01 Esimerkki muutostenhallintalomakkeesta