Analyysi
Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla
Tietojärjestelmän osat Laitteisto Tietokannat Dokumentit Ihmiset Toiminta- ja käyttösäännöt Huomioitava jokaisen osan vaatimukset ja rajoitukset!
Järjestelmän hahmottaminen 1/2 1. Asiakkaan tarpeiden yleinen kartoitus 2. Soveltuvuustutkimus Kustannus hyöty Teknologian saatavuus/järkevyys Tietosuoja Tuotantovaihtoehdot (alihankinta) 3. Kustannus- ja aikarajoitteet 4. Kaupallinen ja tekninen analyysi Potentiaaliset asiakkaat/käyttäjät Laite- ja sovellusympäristö
Järjestelmän hahmottaminen 2/2 5. Järjestelmän jako komponenteiksi Laitteisto Ohjelmisto Tietokannat Inhimilliset tekijät (käyttäjät) -> Mitä osia täytyy uusia? -> Mitä rajoituksia olemassa olevat osat tuovat? -> Kuinka suuri osa järjestelmästä on yleensä tarpeen automatisoida? (esim. integrointitilanteet)
Ohjelmiston vaatimukset 1. Vaatimusmäärittely Ongelmallisin osa ohjelmistotuotantoprosessia 2. Vaatimusten hallinta Täytyy olla systemaattista
Kustannusarvioinnin vaikeus 1. Toistuvat vaatimusten muutokset 2. Puuttuvat vaatimukset 3. Riittämätön kommunikointi käyttäjien kanssa 4. Vaatimusten heikko spesifiointi 5. Riittämätön analyysi Kustannusarvio on helpompi laatia vaatimusten jälkeen!
Vaatimusanalyysi - Vaatimusten luokittelu Toiminnalliset vaatimukset Mitä toimintoja vaaditaan? Ei-toiminnalliset vaatimukset Suorituskyky- ja reaaliaikavaatimukset Luotettavuus Tietoturva Siirrettävyys Rajoitteet Hinta ja aikataulu Lainsäädäntö ja standardit Työkalut, menetelmät ja tyyliseikat (värit) Lopputuotoksen esim. dokumentaation määrittely (Oikeuksista sopiminen)
Vaatimusanalyysin vaiheet 1. Ongelman hahmottaminen. Ohjelmiston rooli järjestelmässä ja rajapinnat. Haastatellaan asiakasta. 2. Tuotteen hahmottaminen. Tieto, toiminnot, rajoitteet, liitännät. 3. Mallinnus pääkomponenttitasolla. Tietosisältö ja ulkoiset rajapinnat. 4. Määrittely 5. Katselmus asiakkaan kanssa. Parantelu.
Erilaiset dokumentit eri tarkoituksiin (Sommerville 1995) Requirements definition Mitä järjestelmältä odotetaan? Rajoitukset? Asiakkaalta saatavan informaation pohjalta Johtajalle ymmärrettävällä abstraktiotasolla Requirements specification Kuvaa tarkasti toiminnot Muut asiat, jotka ovat asiakkaalle oleellisia Voi toimia sopimuksena Software specification Lisää yksityiskohtia Tarkoitettu suunnittelun pohjaksi
Vaatimusprosessi (Sommerville 1995) Feasibility study Feasibility report Requirements analysis System models Requirements definition Requirements specificationc Definition of requirements Requirements document validointi Specification of requirements Software Specification
Vaatimusten validointi Oikeellisuus Tarkempi analyysi saattaa muuttaa vaatimuksia Yhtenäisyys Ei ristiriitoja Täydellisyys Toiminnot ja rajoitteet Realistisuus Toiminnallisuus, rajoitukset ja kustannukset
Vaatimusanalyysiprosessi (Sommerville 1995) 1. Toimialan ymmärtäminen (esim. marketti) 2. Vaatimusten keräys (arvioidaanko infolähteet?) 3. Luokittelu 4. Ristiriitojen ratkaisu (laitteisto ei jousta) 5. Priorisointi 6. Vaatimusten validointi
CASE: pankkijärjestelmä Asiakkaat Automaatti, netti Muut pankit Transaktion peruutus Johtajat Statistiikka Ylläpito Laitteisto ja ohjelmisto Järjestelmä Asiakaspalvelu Markkinointi Kilpailu Tietoturvavastaava Tietokantavastaava Integrointi Top-down lähestymistapa ei onnistu!
Vaatimusdokumentin rakenne 1/2 1. Johdanto 1.1 Järjestelmän kuvaus: ohjelmisto, laitteisto, tieto ihmiset 1.2 Yleiskuvaus (sanallinen kuvaus ohjelmistosta, liitännöistä) 1.3 Ohjelmistoprojektin rajoitukset (raha, aika) 2. Tietosisällön kuvaus 2.1 Tietovuo (datan kulku) 2.2 Kontrollivuo (sisäinen suorituslogiikka) 2.3 Tiedon sisältö, merkitys ja muoto 3. Toimintokuvaus 3.1 Ohjelmiston rakenne 3.2 Rajoitukset käytölle 3.3 Suorituskykyvaatimukset 3.4 Kaaviot (rakenne, liitännät)
Vaatimusdokumentin rakenne 2/2 4. Dynaamisen käyttäytymisen kuvaus 4.1 Järjestelmän tilat 4.2 Herätteet ja toiminnot (reagointi ulkoisiin toimintapyyntöihin) 5. Validointimenettely 5.1 Suorituskykyvaatimukset 5.1.1 Ohjelmiston toiminnan testaus 5.1.2 Ohjelmiston tuottamat tuotokset Viiteluettelo (liittyvät dokumentit, standardit yms.) Liitteet
Vaatimusmäärittelyn ongelmat Ohjelmisto on aina uusi -> ei ole valmista täydellistä mallia vaatimusmäärittelylle Käyttäjien tarpeet hyvin vaihtelevia Asiakas on usein eri kuin käyttäjä Asiakas ei osaa määritellä tarpeitaan tarpeeksi yksityiskohtaisesti ja teknisesti (tai omalla kielellä) Asiakas on liian urautunut vanhaan toimintamalliin Tuottaja ei tunne sovellusaluetta tarpeeksi Asiakas kiinnittää liiaksi toteutusta Tuottaja pyrkii vaikuttamaan liiaksi vaatimuksiin
Vaatimusmuutosten ongelmat Kaikki asiakasvaatimuksia ei ymmärretä oikein aluksi Asiakasvaatimuksia jää huomaamatta Muutokset toimintaympäristössä (tavat, laitteistot) Jotkut vaatimukset osoittautuvat mahdottomiksi ja käyttökelvottomiksi Aikataulupaine -> ominaisuuksia jää toteuttamatta Kilpailijalta uusi tuote -> lisätään vaatimuksia Projektin alkuvaiheessa tehdään epäonnistuneita teknologiavalintoja