Tämän artikkelisarjan tavoitteena on avata peruskäsitteitä ja auttaa ymmärtämään mitä ketteryys ohjelmistokehityksessä tarkoittaa. Vaatimusmäärittely on kuitenkin jat-kuvaa, ja vaatimukset kehittyvät projektin edetessä. Toimintaprosessit ja toiminnan tarpeet ovat lähtökohtana vaatimusmäärittelylle. Kuka käyttää järjestelmää?
Mihin muihin järjestelmiin kehitettävä järjestelmä on yhteydessä? Myös tuotekehityksessä tehdään vaatimusmäärittelyä, osa siitä jo tuote-ehdotuksen luomiseksi. Alustava vaatimusmäärittely. Ne ovat tärkein hankinnan kohdetta kuvaava sisällöllinen liite itse hankintailmoituksessa, joita vasten tarjoaja esittää tarjouksensa. JUHTA - Julkisen hallinnon tietohallinnon neuvottelukunta Kuva 1. ICT-palvelujen kehittämisen vaiheet.
Oikeastaan vain seuraavista asioista ollaan yleisesti samaa mieltä: Järjestelmälle asetetaan (toiminnallisia ja ei-toiminnallisia) vaatimuksia, jotka sen on toteutettava. Käyttötapaukset vs. Hyöty selviää kuitenkin kaikille osapuolille melko pian, kun huomataan, että puhutaan samaa kieltä ja luodaan yksiselitteisiä vaatimuksia. Mää-rittelyä tekevä asiakas on mukana työssä koko sen ajan tarkentaen ja ohjaten sitä ohjelmiston kehittyessä.
Suullinen, vuorovaikutteinen kommu-nikaatio vähentää väärinymmärryksiä verrattuna perinteiseen kirjalliseen vaatimusmäärittelyyn. Asiantuntijamateriaalimme on kattava ja käytännönläheinen tietopaketti ketterän ohjelmistokehityksen vaatimusmäärittelystä. Lataa opas ja lue miten edetä vaatimusmäärittelyssä, miten ketterä ohjelmistokehitys eroaa vesiputousmallista ja miten arvioida ohjelmistokehityksen määrittelyn onnistumista. Monesti vaatimusmäärittely jää liian pienelle huomiolle uutta ohjelmistoa suunniteltaessa. Kokonaiskuvan hahmottamiseksi on tärkeää tehdä edes karkean tason vaatimusmäärittely työn alla olevasta kokonaisuudesta.
Oletko ostajana joutunut projektista sivuun sen alkaessa? Tehokas vaatimusmäärittely –kurssilla paneudutaan sopivien vaatimusten kuvaustapojen ja tarkkuustasojen löytämiseen eri tilanteissa. Kouluttaja Kouluttajana toimii Tarja Raussi, kokonaisarkkitehti ja konsultti Coalasta.
Hänellä on yli vuoden kokemus käsitemalleista ja tietoarkkitehtuurin kehittämisestä eri ympäristöissä. Scrum on yksinkertainen, mutta samalla erittäin haastava hallita täysin. Tällä kurssilla opit, kuinka toimit onnistuneesti tuoteomistajana Scrum-projektissa. Ketterä ja tutkiva testaus. Ota haastavat projektit hallintaasi!
Tule mukaan oppimaan ICT-projektijohtamisen perusteita ja luo edellytykset projektisi onnistumiselle. Kurssin jälkeen ymmärrät tapaa toimia ICT-projekteissa ja kuinka saavuttaa tavoitteesi ammattimaisena ICT-projektista vastaavana henkilönä. Tällä kaikella on omat vaikutuksensa siihen, miten julkinen ketterä hankinta kannattaa kilpailuttaa. Tässä työssä tarkastellaan näitä kysymyksiä kirjallisuusselvityksen ja tapauskuvausten avulla. Joskus vaatimusmäärittely vie sinne, missä kukaan ei ole vielä käynyt.
Tai ainakaan määrittelijä itse ei ole käynyt. Näin konsultin hommissa tuo on tuiki tavallista – ei uuteen hommaan ryhdyttäessä välttämättä toimiala tai teknologia ole aina tuttua. Silloin on pakko samalla opiskella ja tutkia uutta maastoa.
Osa sivun sisällöstä vaatii kirjautumisen ja kurssille ilmoittautumisen. Jos olet jo ilmoittautunut kurssille, ole hyvä ja kirjaudu sisään nähdäksesi tämän sisällön. Iteratiivinen ja ketterä toimintatapa lähteekin siitä ajatuksesta, ettei etukäteistä yhteisymmärrystä lopullisesta ratkaisusta ole mahdollista saavuttaa. Iteratiivisessa toimintatavassa yleinen laskutyömalli myös tarkoittaa sitä, ettei Toimittajalla ole vastaavaa sanktioitua ratkaisun toimitusvastuuta kuin kokonais- ja tavoitehintaisissa sopimuksissa perinteisellä tavalla toimien.
Toisaalta turhan moni ketteryyden kannattaja tuumaa, ettei vaatimuksia tarvitse enää määritellä – riittää kun jutskataan ihmisten kanssa. Törmäsimme kollegan kanssa talvella tapaukseen, jossa potentiaalinen. Mikä on siis ”oikein”?
Ohjelmistojen vaatimusmäärittely.
Ei kommentteja:
Lähetä kommentti
Huomaa: vain tämän blogin jäsen voi lisätä kommentin.