Ohjelmistotuotannon osa- alueet Kevät 2002 Päivi Ovaska LTKK/Tite.

Esitys aiheesta: "Ohjelmistotuotannon osa- alueet Kevät 2002 Päivi Ovaska LTKK/Tite."— Esityksen transkriptio:

1 Ohjelmistotuotannon osa- alueet Kevät 2002 Päivi Ovaska LTKK/Tite

2 Ohjelmistotuotannon eri tasot SWE-Process Technologies Java Wintel Corba C++... Products Sciences Formal methods DB theory Cognitive psychology Management sciences... Methods&tools OOE UML Purify Rose... Requirements

3

4

5

6

7

8 Asiakasvaatimuksista tuotteeseen Määrittely Suunnittelu& toteutus ohjelmistovaatimukset asiakasvaatimukse t

9 Asiakas- ja tuotekehitysprosessit

10

11 Asiantuntemuksen alueet Yleinen tekninen osaaminen Johtamis- taidot Esiintymis- ja Neuvottelutaidot, Ryhmätyötaidot Prosessi- osaaminen Sovellusalueen asiantuntemus Erityisalueen tekninen osaaminen

12 Ohjelmiston elinkaari (life cycle) Ajanjakso ohjelman kehitystyöstä sen käytöstä poistamiseen. Malleja – Vesiputous – RAD – Evo-mallit – Protoilu – Sulautetun järjestelmän kehitys – Järjestelmätoimitus

13 Ohjelmiston elinkaari Esitutkimus Määärittely Suunnittelu Toteutus Ylläpito Vaatimusmäärittely, requirement analysis, requirement specification, system analysis Moduulitestaus Integrointitestaus Järjestelmätestaus Ongelmien ratkomista, virheiden korjaamista, ohjelmien muuttamista, uusien piirteiden lisäämistä Analysoidaan asiakasvaatimuksia, johde- taan ohjelmistovaatimukset Toiminnallinen määrittely Mitä tehdään? Asetetaan yleiset järjestelmätason vaatimukset, asiakasvaatimukset Miksi ohjelmisto tulisi tehdä? Arkkitehtuurisuunnittelu Moduulisuunnittelu Testaus Miten tehdään? Tavoitteena löytää virheitä

14 Vaatimukset (Requirements) ” asiakkaan on tuotettava mahdollisimman virheettömiä dokumentteja” ”järjestelmässä on oltava tuki oikeinkirjoitukselle” ” tarkasta oikeinkirjoitus jokaisen kirjoitetun sanan jälkeen” ” haluamme järjestelmään tuen oikein- kirjoitukselle”

15 Vesiputousmalli (Linear model, Waterfall model) käyttökelpoinen, kun vaatimukset on hyvin tiedossa

16 Kun vaatimuksia halutaan tarkentaa, eikä tiedetä mitä halutaan Vesiputousmalli nopeaan, komponenttipohjaiseen kehi- tykseen

17 Evo-malli (Evolutionary Model) year Specification Design Realization Testing Specification Design Realization Testing Specification Design Realization Testing... Version 1Version 2Version 3 Unknown/changing/misunderstood requirements Managing of risks

18

19 Evolutionary incremental model implement The rest of the UC’s specifydesign implementtest Version 0.1 Most important use cases: #1, 3 specifydesigntest Version 0.5 The next UC’s: #2, 4, 5 specifydesignimplementtest Version 1.0 2 weeks

20 RUP (Rational Unified Process) -iteraatiot

21 RUP Iteraatio

22 RUP vaiheiden limittyminen

23 Protoilu

24

25 Sulautettu järjestelmä

26 Tukitoiminnot Laadunvarmistus Dokumentointi Tuotteenhallinta Vaatimustenhallinta...

27 Mitä on ohjelmiston laatu? Ohjelmistotuotteen kykyä täyttää käyttäjänsä kohtuulliset toiveet ja odotukset Laatu subjektiivinen, käyttäjästä ja käyttöympäristöstä riippuva käsite Toiminnan laatu, tuotteen laatu Toiminnan hyvä laatu tarkoittaa lopputuotteen laatuun positiivisesti vaikuttavia toimintatapoja

28 Yrityksen laatujärjestelmä Tuotteen tekemiseksi käytettävä yrityksen toimintapa Tavoitteena taata, että tuotantoprosessi tuottaa suunniteltua laatutasoa vastaavia tuotteita aikataulun ja budjetin mukaisesti Kuvaus yrityksen laatukäsikirjassa Laatusertifikaatti todiste siitä, että yritys toimii laatujärjestelmänsä mukaisesti, mutta se ei todista laatujärjestelmän erinomaisuutta

29 Laadunvarmistus Mitä kauemmin virheet ovat järjestelmässä, sen kalliimmaksi ne tulevat. Terveydenhoito: toimintatavat, jotka vähentävät virheitä. Sairaanhoito: virheiden seulominen mahdollisimman aikaisessa vaiheessa: tarkastukset.

30 Tarkastukset ja katselmukset (esimerkki)

31 Dokumentointi

32 Tuotteenhallinta

33 Vaatimustenhallinta

34 Ohjelmistoprojekti Esitutkimusprojekti Määrittelyprojekti Toteutusprojekti Käyttöönottoprojekti Koulutusprojekti Nyrkkisääntö: projekti ei saisi kestää yli vuotta

35 Toimitusprojekti

36 Ohjelmistoprojektin ongelmia epärealistiset aikataulut ja budjetit vaatimusten muuttuminen projektin aikana henkilöstöongelmat sovellusalueen huono tuntemus tekniikan huono tuntemus työmääräarviot pettävät, budjetit ylittyvät asiakas ei tiedä mitä haluaa

37 Elinkaarikustannukset

38 Arvoketju (esimerkki) [Boehm 1987]

39 Onko rationaalinen tuotantoprosessi mahdollinen? Parnas&Clemens: – Ohjelmistolle asetettavat vaatimukset eivät juuri koskaan ole täysin tunnettuja alkuvaiheessa – Vaikka vaatimukset tunnettaisiinkin, monet toteutukseen liittyvät seikat selviävät vasta projektin aikana – Vaikka kaikki tosiseikat olisivatkin tiedossa jo alussa, on tosiseikkoja niin paljon, ettei ihminen pysty käsittelemään niitä virheettömästi – Vaikka tosiseikat pystyisikin käsittelemään virheettömästi, ne voivat muuttua ulkoisista syistä

40 Onko rationaalinen tuotantoprosessi mahdollinen? Ihminen takertuu aikaisemmin oppimiinsa ratkaisuihin, jolloin rationaalisesti perusteltavissa oleva ratkaisu jää huomaamatta Aikaisemmin kirjoitettujen ohjelmien uudelleenkäyttö johtaa myös usein omituisiin ratkaisuihin

41 Kannattaako siis edes yrittää? Kannattaa, koska prosessit – antavat ohjeita mitä missäkin vaiheessa pitäisi tehdä – helpottavat siirtymistä projektista toiseen, jos ne muistuttavat toisiaan – projektinhallinta helpottuu – ulkopuolisen arvioijan helpompi arvioida projektin tilannetta – mahdollistavat mittatietojen keräämisen ja toiminnan kehittämisen tähän perustuen Programming-in-large vs. programming-in-small