Patria - FINSE
Patria - FINSE
Patria - FINSE
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>FINSE</strong>-syysseminaari 2011<br />
Vaatimustenhallinta hankinta- ja<br />
toimitusprojekteissa<br />
Pohdintaa käytännön ja teorian suhteesta –<br />
onko kuilua vai ei <br />
Taisto Tuominen<br />
<strong>Patria</strong> Systems
<strong>Patria</strong><br />
Terminologian tarkennusta<br />
• Vaatimusten hallinta<br />
– vaatimustenhallinta on vain osa vaatimuksiin liittyvää toimintaa (engl.<br />
”Requirements Engineering”)<br />
– erilaisia luokitteluja löytyy eri lähteistä; eniten asiasta kirjoitetaan ohjelmistoprosessien<br />
yhteydessä, suomenkielinen terminologia ei ole vakiintunut<br />
– tämä esitys käsittelee vaatimusten roolia yleisellä järjestelmätasolla, jossa<br />
toteutustapaa (SW, HW, …) ei ole vielä päätetty<br />
• Requirements elicitation,<br />
• Requirements analysis and negotiation,<br />
• Requirements specification,<br />
• System modeling,<br />
• Requirements validation,<br />
• Requirements management.
<strong>Patria</strong><br />
Vaatimusten kulku<br />
• Vaatimusten kehittäminen<br />
– Käyttäjän tarpeen välittyminen suunnitteluvaatimukseksi tapahtuu usean<br />
välivaiheen kautta<br />
• Käyttäjän / omistajan prosessi<br />
• Toimittajan / rakentajan prosessi(t)<br />
• Yhteinen sopimus- ja muutostenhallintaprosessi<br />
Sopimus &<br />
muutosten käsittely
<strong>Patria</strong><br />
Vaatimuksista arkkitehtuuriin<br />
• Järjestelmäsuunnitteluprosessi – eräs yleisesti hyväksytty malli<br />
– Vaatimuksista edetään arkkitehtuuriin / konseptiin toiminnallisuuksien<br />
määrittelyn kautta
<strong>Patria</strong><br />
Vaatimuksista arkkitehtuuriin<br />
– Arkkitehtuurin osille kirjoitetaan omat, edellisen tason suunnitteluratkaisuista<br />
johdetut, vaatimukset ja tätä jatketaan kunnes voidaan tehdä<br />
järjestelmäelementtien (HWCI, SWCI) yksityiskohtainen suunnittelu
<strong>Patria</strong><br />
Järjestelmämalli ANSI/EIA-632<br />
• Järjestelmähierarkia<br />
– Järjestelmä koostuu lopputuotteesta ja sen tukijärjestelmistä<br />
– Molemmat voidaan edelleen jakaa osakokonaisuuksiin<br />
• ”End Products”:<br />
– Varsinainen käyttäjän tarve<br />
– Alijärjestelmät, ohjelmisto-, elektroniikka- yms. tuotteet<br />
• ”Enabling Products”:<br />
– Edellisen tukijärjestelmät<br />
– Kehitys-, testi-, tuotanto-, koulutus- ja ylläpitojärjestelmät yms.
<strong>Patria</strong><br />
Järjestelmämalli ANSI/EIA-632<br />
• Vaatimusten rakenteen tulisi<br />
noudattaa tuoterakennetta<br />
– Rakenteen osille kirjoitetaan<br />
itsenäiset vaatimukset<br />
– Rajapinnoille kirjoitetaan<br />
liityntäspesifikaatiot
<strong>Patria</strong><br />
Järjestelmämalli ANSI/EIA-632<br />
• Riippuu näkökulmasta mikä on ”End Product” ja mikä ”Enabling Product”<br />
– Esim. testijärjestelmän suunnittelijalle ja toimittajalle se on ”End Product” mutta<br />
tilaajalle ”Enabling Product”
<strong>Patria</strong><br />
Järjestelmämalli ANSI/EIA-632<br />
• Toteutuksessa osakokonaisuudet voidaan järjestää alihankinnoiksi ja<br />
projekteiksi tilanteen mukaan<br />
– Lopulta tehdään jako olemassa oleviin, hankkeessa toteutettaviin ja valmiina<br />
hankittaviin (COTS, MOTS) osuuksiin
<strong>Patria</strong><br />
Teoreettinen järjestelmä- ja vaatimusrakenne<br />
• Teoriassa<br />
– Vaatimuksilla on siis sama hierarkia, kuin itse järjestelmällä<br />
• Järjestelmävaatimukset sisältävät parhaimmillaan siis vain asioita, jota vaikuttavat<br />
päätason arkkitehtuurin valintoihin<br />
– Vasta kun nämä valinnat on tehty, voidaan kirjoittaa seuraavan tason vaatimukset jne.<br />
– Se, joka päättää kokonaisarkkitehtuurin, myös vastaa siitä ja tilaa toimittajalta vain<br />
arkkitehtuurin osat niille kirjattujen vaatimusten perusteella
<strong>Patria</strong><br />
Järjestelmä- ja vaatimusrakenne käytännössä<br />
• Käytännössä<br />
– Kaikkea ei kehitetä hankkeessa, vaan osana käytetään olemassa olevia<br />
osuuksia (m.l. BFE/GFE) ja COTS/MOTS-tuotteita
<strong>Patria</strong><br />
Vaatimustenhallintaa teoriassa ja käytännössä<br />
• Käytännössä (jatkuu)<br />
• Alijärjestelmien tai laitteiden alkuperäiset vaatimukset puuttuvat tai niitä on muutettu<br />
elinkaaren kuluessa<br />
• COTS/MOTS-osuuksille ei ole vaatimuksia eikä niiden toiminnallisuutta ole aina<br />
riittävän hyvin dokumentoitu<br />
• MLU-tyyppiset päivitykset voivat säilyttää suuren osan järjestelmän vanhaa<br />
rakennetta, miten silloin kirjoitetaan vaatimukset <br />
– Vain muutetuille osille Koko järjestelmälle muutosten jälkeen <br />
– Järjestelmävaatimukset sisältävät myös yksityiskohtaisia vaatimuksia<br />
• Vaatimukset perustuvat jo johonkin ajatukseen tai oletukseen arkkitehtuurista ja sitten<br />
on esitetty vaatimuksia myös sen osille<br />
– Aina tätä kokonaisarkkitehtuuria ei kuitenkaan ole kerrottu tai muodollisesti vaadittu<br />
– Samalla toimittajaa pyydetään ottamaan vastuu kokonaisuudesta eli myös tilaajan tekemistä<br />
valinnoista
<strong>Patria</strong><br />
Yhteenveto<br />
• Olisi kiinnitettävä enemmän huomiota vaatimusten rakenteeseen<br />
– Pyritään noudattamaan tuoterakennetta; määritellyille osille laaditaan itsenäiset vaatimukset<br />
– Kirjoitettaan käyttäjävaatimuksista johdetut vaatimukset aina myös uudelleenkäytettäville ja<br />
COTS/MOTS-osuuksille ja verifioidaan tuotteen toteutusta vaatimuksiin nähden<br />
• Arkkitehtuurin hallinta<br />
– Jos tilaajalla on tarve pohjata hankinta ennalta määriteltyyn arkkitehtuuriin, se pitäisi kuvata<br />
ja laatia vaatimukset arkkitehtuurin elementeille sen pohjalta<br />
– On mietittävä, kuka lopulta vastaa kokonaisuuden toiminnasta, jos arkkitehtuuri on ennalta<br />
määrätty tai<br />
• Muita vaatimuksiin liittyviä huomioita<br />
– Vaatimusten muuttaminen työn aikana pitäisi olla osa normaalia työtä, johon on varauduttu<br />
prosessina ja budjetoitu rahaa<br />
– Viittauksia standardeihin käytetään usein ilman että määritellään mihin nimenomaiseen<br />
kohtaan viitataan tai mikä standardin sisältämä vaatimustaso valitaan jne.<br />
• Lähteet:<br />
– ANSI/EIA-632<br />
– Systems Engineering Fundamentals, Defence Acquisition Univercity Press, 2001<br />
– Uolevi Nikula: Introducing Basic Systematic Requirements Engineering Practices in Small<br />
Organisations with Easy to Adopt Method, Väitöskirja LTKK 2004
<strong>Patria</strong><br />
Kiitos mielenkiinnosta !<br />
Kysyttävää <br />
Kysyttävää <br />
Dilbert ©2011, Universal Uclick
Change language