1 / 9

Ohjelmistotekniikka Vaatimustenhallinta

Ohjelmistotekniikka Vaatimustenhallinta. Kevät 2002 Päivi Ovaska LTKK/Tite. Vaatimustenhallinta. Ohjelmistotuotannon perimmäinen tavoite päätyä asiakasvaatimukset täyttävään ohjelmmistoon Vaatimustenhallinnan keskeisin tehtävä varmistaa, että lopputuote vastaa asiakkaan vaatimuksia

katoka
Download Presentation

Ohjelmistotekniikka Vaatimustenhallinta

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. OhjelmistotekniikkaVaatimustenhallinta . 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 : <The name of the project/product> CR Number: Ordinal number Change originator’s name: <Name of the person/group who propose the change> Request date: 1999-01-01 Change description: <Describe and give reasons for the change. > Change request evaluation: <Evaluate consequences of the change both from project and product's point of view. Evaluate the extra work and cost needed for the change work.> 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: <Describe who shall be informed and name person(s) responsible and practices (e-mail, phone etc.) to share information.> Recommendation: <Recommendation of the person / group who made the evaluation.> Evaluated by: <Name person / group who made the evaluation> 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: <Document reviews and acceptance of work products and the names of the persons responsible for this.> Acceptance: <Record person(s) / group who have accepted the change.> Acceptance date: 2001-01-01 Esimerkki muutostenhallintalomakkeesta

More Related