Oleelliset vaikeudet OT ssa 12 Monimutkaisuus Mahdoton ymmrt

Oleelliset vaikeudet OT: ssa 1/2 • Monimutkaisuus: – – – Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet Turvallisuuriskit • Yhteensopivuus, mukautuvuus – Suhteellisen yksinkertainen tehdä muutoksia -> Muutoksia myös vaaditaan usein – Periaatteessa ohjelmistoja voidaan koota olemassa olevista komponenteista – käytännössä joudutaan mukauttamaan

Oleelliset vaikeudet OT: ssa 2/2 • Muuttuvuus – Ohjelmistotuotteeseen tehdään jatkuvasti muutoksia -> Luotettavuuden säilyminen haastavaa – Muutoksen kustannuksia ei ymmärretä kuten fyysisissä tuotteissa • Näkymättömyys – Ohjelma on abstrakti, siitä ei voi tehdä kolmiulotteista mallia -> Ohjelman kokonaisuutta on vaikea hahmottaa -> Haittaa myös kommunikointia

Edistysaskeleet 1/5 • Korkean tason kielet – Jo C-kielestä odotettiin läpimurtoa, kehitys vieläkin vähittäistä – Tavoitteena sekä työn, että oppimisen tehostaminen – Täytyy tietää mitä tekee –> nopeuttaa työntekoa, mutta ei välttämättä oppimista • “Automaattinen” ohjelmointi = Vielä korkeamman tason ohjelmointikieliä (Parnas) – Täytyy esittää ratkaisumenetelmä jollain tasolla – Joillekin erityisalueille on mahdollista toteuttaa toimiva ohjelmistokehitin

Edistysaskeleet 2/5 • Olio-ohjelmointi – Helpottaa reaalimaailman mallintamista – On helpottanut komponenttipohjaista ohjelmointia – Ei kuitenkaan suurta vaikutusta tehokkuuteen • Tekoäly ja asiantuntijajärjestelmät – Ohjelmistotuotannossa voidaan yhdistää kehitystyökaluihin, jolloin järjestelmä ehdottaa erilaisia toimenpiteitä – Vaikea ja työläs rakentaa – Mistä saadaan asiantuntijat tiedon ja päättelysääntöjen luomiseksi

Edistysaskeleet 3/5 • Graafinen ohjelmointi = koodin generointi suunnittelukaavioista - Vaatii todella tarkkaa suunnittelua ja monimutkaisia kaavioita - Voi toimia osittain • Formaali todentaminen – Perustuu oikeellisuuden matemaattiseen todentamiseen – Edellyttää formaalia spesifikaatiota – Määrittely voi olla virheellinen

Edistysaskeleet 4/5 • Ohjelmointiympäristöt – Editorit, debuggerit, graafiset kehittimet – Integrointi – yhteinen tietokanta • Oleellisten tehtävien tukeen keskittyminen – Keskitytään tehostamaan tehtäviä, jotka vaativat eniten aikaa ja toistokertoja – Oma tieto vs. vanhat tutkimukset • Vaatimusten tarkentaminen nopealla protoilulla – Asiakas ei aluksi tunne tarkasti vaatimuksia – Nykyiset graafiset ohjelmistokehittimet

Edistysaskeleet 5/5 • Ostaminen ja ulkoistaminen – Valmisohjelmat jatkuvasti yleistyneet – Moduulien myynti on yleistynyt hitaasti – Edullista, välitön saatavuus, hyvä dokumentointi, ylläpito • Vähittäinen kehittäminen – Toteutetaan ensin ohjelman ydin – Toteutetaan toiminnot yksi kerrallaan • ”Gurujen” kouluttaminen – Tiedostetaan, että yksilöiden väliset erot tuotannon laadussa ja tehokkuudessa ovat suuria – Panostetaan hyviin tyyppeihin

Prosessimallit • On useita malleja, jotka vaiheistavat ohjelmistotuotantoprosessia: – – Sisältää ohjelmistotuotantoprosessin keskeiset osa-alueet Kuvaa osaprosessien suoritusjärjestyksen Malli tuottaa dokumentaation Malli on yleinen -> sovellettavissa kaikkialle, mutta mukautettava organisaation tarpeisiin • Malli sisältää ainakin seuraavat osat: – Määrittely – Kehittäminen – Ylläpito

Ylläpidon suuri osuus on elinkaarimallien ongelma Vaihe Kustannusosuus 1 Vaatimukset 3% 2 Määrittely 5% 3 Suunnittelu 7% 4 Koodaus 6% 5 Moduulitestaus 7% 6 Integrointi 6% 7 Ylläpito 67 % Elinkaarikustannusten jakautuminen (Schach 1990)

Vesiputousmalli Järjestelmän hahmottaminen Analyysi Suunnittelu Toteutus Testaus Ylläpito

Vesiputousmallin ongelmia • Peruutus on vikeaa ja työlästä • Malli ei välttämättä vastaa projektin todellista kulkua • Vaiheen siirtyminen toiseen aiheuttaa viiveitä, jos seuraavan vaiheen syötteeksi vaaditaan edellisen vaiheen verifioitu lopputuotos • Tuote nähdään ensimmäisen kerran vasta loppuvaiheessa, jolloin vaatimusten muuttaminen on kallista ja aikaa vievää

Prototyyppimalli ”Asiakas ei tiedä mitä haluaa, mutta hän tietää kyllä mitä ei halua – heti kun näkee sen” • Tarkoitus siis vaatimusten todellinen selvittäminen • Prototyyppi konkretisoi muuten abstraktia ohjelmiston kehitystä sekä asiakkaalle että kehitystiimille • Nykyiset graafiset sovelluskehittimet helpottavat silloin kuin niitä voidaan hyödyntää

Protoilun vaiheet 1. Vaatimusten ja määrittelyjen kerääminen ja tarkentaminen 2. Ulospäin näkyvien toimintojen suunnittelu ja tarkentaminen 3. Prototyypin rakentaminen 4. Asiakkaan suorittama prototyypin kokeilu ja arviointi 5. Prorotyypin parantelu

Protoilun ongelmia • Jarjestelmän (proto-osan) rakentaminen moneen kertaan aiheuttaa lisätyötä • Protyypissä tehtyjen ohjelmanosien siirtäminen lopputuotteeseen saattaa tuottaa laatuongelmia • Kaikki ongelmat eivät tule näkyviin protovaiheessa, esim. tehokkuus, laajennettavuus • Maltetaanko suunnitella kunnolla? • Luotetaanko liikaa siihen mitä näkyy? Jääkö abstraktimpien asioiden suunnittelu vähemmälle? • Asiakkaan mielestä prototyyppi voi olla melkein valmis ohjelma

Inkrementaalinen malli • Rakennetaan aluksi vain ohjelman runko ja tärkeimmät toiminnot • Toimintoja lisätään vaihe kerrallaan • Aiempia kokemuksia voidaan hyödyntää uusien osien määrittelyssä • Saadaan toimiva (vaikkakin suppea) järjestelmä lyhyessä ajassa • Asettaa kovat vaatimukset suunnittelulle, jos ei suunnitella koko sovellusta kerralla

Spiraalimalli • • Keskittyy tuotantoprosessin alkuvaiheisiin Toteutuksessa voidaan soveltaa mitä mallia tahansa Korostaa tuotantoprosessin iteratiivisuutta ja riskien huomioimista Jokaisella kierroksella neljä vaihetta: 1. 2. 3. 4. • Tavoitteiden, vaihtoehtojen ja rajoitteiden määrittely Vaihtoehtojen arviointi, riskien tunnistus Kehitys ja varmistus Seuraavan kierroksen suunnittelu Vaatii paljon aikaa ja asiakkaan osallistumista