Suunnittelu tehokkaasti oikeille raiteille


2014-10-20, 09:12 Kirjoittanut Tommi Palomäki

Edellinen blogikirjoitukseni käsitteli ketterää suunnittelua. Tällä kertaa pureudun suunnittelun lähtökohtiin, eli ei-toiminnallisiin vaatimuksiin. 

Suunnittelu lähtee vaatimuksista

Ohjelmistotekniikassa pätee vanha sanonta: garbage in, garbage out. Vaatimukset määräävät hyvin pitkälle syntyvän ohjelmistotuotteen laadun.

Ohjelmiston arkkitehtuuri pohjautuu pitkälti ohjelmiston ei-toiminnallisiin vaatimuksiin. Näitä ovat esimerkiksi ohjelmiston ylläpidettävyys, robustisuus, skaalautuvuus, tehokkuus ja tietoturvallisuus. Näistä ei-toiminnallisista vaatimuksista käytetään muun muassa nimitystä architecture drivers tai driving requirements. SEI määrittelee asian seuraavasti: "The combination of functional, quality-attribute, and business requirements that shape the architecture or the element under consideration".

Kilpailevat vaatimukset

Sanotaan että arkkitehtuurisuunnittelu on keskenään kilpailevien vaatimusten yhteensovittamista. Suorituskyvyltään pitkälle optimoitu ohjelmisto on harvoin ylläpidettävä. Tietoturvaan panostaminen voi puolestaan vaikuttaa ohjelmiston käytettävyyteen ja suorituskykyyn.

Ohjelmiston arkkitehtuuri määrää, mitkä ei-toiminnalliset vaatimukset täyttyvät toisten vaatimusten kustannuksella. Siksi projektin alussa on tärkeää tunnistaa ja priorisoida arkkitehtuuriin vaikuttavat vaatimukset.

Konkreettiset skenaariot

Ei-toiminnallisten vaatimusten kuvaus jää valitettavan usein köykäiselle tasolle. Esimerkiksi vaatimus: "Ohjelmiston tulee olla skaalautuva" jättää paljon tulkinnanvaraa. Minkä suhteen ohjelmiston tulisi skaalautua; käyttäjien, datan vai käyttökuorman suhteen? Mihin määrään skaalautuvuutta arkkitehtuurin tulisi mukautua?

Ei-toiminnallinen vaatimus tulisi purkaa konkreettiseksi skenaarioksi, joka kuvaa vaatimuksen hyvin konkreettisena, esimerkinomaisena käyttötapauksena. Esimerkiksi suorituskykyvaatimus voidaan kuvata seuraavasti: "Käyttäjä jättää tilauksen järjestelmään. Järjestelmässä on ruuhka-aika, jolloin sisäänkirjautuneita käyttäjiä on yhtä aikaa 2000 ja tilauksia jätetään 500 tilausta tunnissa. Käyttäjälle näkyvä vasteaika tilauksen jättämiselle saa olla korkeintaan kaksi sekuntia."

Quality Workshop työkaluksi vaatimusten tunnistamiseen

Quality Attribute Workshop on SEI:n kehittämä työkalu ei-toiminnallisten vaatimusten tunnistamiseen. Workshop-työskentelyssä projektin eri sidoshenkilöt tunnistavat ohjelmiston ei-toiminnalliset vaatimukset. Konkreettiset skenaariot kirjataan ylös ja priorisoidaan. Oikein läpivietynä workshop on tehokas ja organisoitu tapa koota yhteen ohjelmiston laatuvaatimukset. Projektin alussa se antaa hyvä pohjan arkkitehtuurisuunnittelulle, ja projektin aikana se voi toimia tarkistuspisteenä vaatimusten osalta.

Minimissään workshop tarkoittaa muutaman tunnin palaveria, jossa käydään läpi ei-toiminnallisia vaatimuksia eri lähteistä. Muun muassa MSDN:stä ja Wikipediasta löytyy kattava lista erilaisista ei-toiminnallisista vaatimuksista. Osallistujat puntaroivat vaatimuksia projektin näkökulmasta ja kirjoittavat relevantit vaatimukset ylös konkreettisten skenaarioiden muodossa. Vaatimukset priorisoidaan vaikkapa kolmeen luokkaan: high, medium ja nice-to-have.

SOS-lapsikyläprojekti hyötyi Quality Workshopista

Cybercomissa toteutettiin kesätyöprojektina verkkopalvelu SOS-lapsikylille. Quality Workshop järjestettiin kun projekti oli edennyt yhden sprintin verran, eli hyvään saumaan projektin alkuvaiheissa.

Workshopin merkityksestä saatiin jälkikäteen seuraavaa palautetta:

  • "SOS projektissa kaikkien sidosryhmien kanssa tehty quality workshop auttoi kiinnittämään huomion ja resurssit oikeisiin asioihin aikaisessa vaiheessa. Yleensä vain toiminnalliset määrittelyt varastavat huomion."
  • "Workshop teki projektin aikana oikeiden ratkaisuiden teon helpoksi sillä koko tiimi tiesi mitkä ovat onnistuneen ohjelmiston tavoitteet."
  • "Product Ownerin roolissa tein toimintojen suunnittelussa ratkaisuja jotka olivat linjassa suorituskyky- ja käytettävyysvaatimusten kanssa."
  • "Ennalta tehdyt tavoitteet suorituskykyyn motivoivat koodaajat tekemään heti optimointeja, nämä osoittautuivat erittäin tärkeiksi."
  • "Karttaratkaisussa päätettiin aikaisessa vaiheessa toteuttaa työläämpi teknologia joka johti parempaan käyttökokemukseen."
  • "Tuloksena oli hyvin käyttötarkoitustaan vastaava palvelu."

Alla esimerkkiä workshopin tuotoksista. Tämän blogikirjoituksen alussa oleva valokuva on myöskin otettu kyseisestä workshopista.


comments powered by Disqus