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.

Esitys aiheesta: "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."— Esityksen transkriptio:

1 Analyysi

2 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

3 Tietojärjestelmän osat Laitteisto Tietokannat Dokumentit Ihmiset Toiminta- ja käyttösäännöt Huomioitava jokaisen osan vaatimukset ja rajoitukset!

4 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ö

5 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)

6 Ohjelmiston vaatimukset 1.Vaatimusmäärittely –Ongelmallisin osa ohjelmistotuotantoprosessia 2.Vaatimusten hallinta –Täytyy olla systemaattista

7 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!

8 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)

9 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.

10 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

11 Vaatimusprosessi (Sommerville 1995) Feasibility study Requirements analysis Requirements definition Requirements specificationc Feasibility report System models Requirements document Definition of requirements Specification of requirements Software Specification validointi

12 Vaatimusten validointi Oikeellisuus –Tarkempi analyysi saattaa muuttaa vaatimuksia Yhtenäisyys –Ei ristiriitoja Täydellisyys –Toiminnot ja rajoitteet Realistisuus –Toiminnallisuus, rajoitukset ja kustannukset

13 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

14 CASE: pankkijärjestelmä Järjestelmä Asiakkaat Automaatti, netti Muut pankit Transaktion peruutus Johtajat Statistiikka Asiakaspalvelu Tietokantavastaava Integrointi Tietoturvavastaava Markkinointi Kilpailu Ylläpito Laitteisto ja ohjelmisto Top-down –lähestymistapa ei onnistu!

15 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)

16 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

17 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

18 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