Johdatusta ohjelmistotekniikkaan

Transkriptio

1 Johdatusta ohjelmistotekniikkaan OT:n historiaa 4 vaihetta (1/2) 1. Vaihe (0 60-luvun alku) Vähän tietokoneita Eräajo-tyyppisiä ohjelmia Pääasiassa matemaattisia, pieniä yhden käyttäjän sovelluksia Ei kaupallista merkitystä 2. Vaihe (60-luvun alku 70-luvun alku) Enemmän ja suurempia tietokoneita Monen käyttäjän (~100) ajantasaiset järjestelmät Tietokannat Kaupallinen hyödyntäminen -> Ensimmäiset ohjelmistotalot Ohjelmistokriisi!!!

2 OT:n historiaa 4 vaihetta (2/2) 3. Vaihe (70-luvun alku 80-luvun loppu) - Henkilökohtaisia tietokoneita + hajautettuja järjestelmiä - Ohjelmistokustannukset > laitteistokustannukset - Ohjelmistoilla paljon käyttäjiä (~ ) -> massamarkkinet -> laatuvaatimukset nousivat 4. Vaihe (80-luvun loppu - ) - Tehokkaat PC:t (myös kannettavat) - Oliotekniikat - Case-välineet - Valtavat käyttäjämäärät (~ ) Tietotekniikan hyödyntäminen Kotitaloudet Yritykset Akateeminen maailma Aika

3 Ohjelmistotekniikan trendit Programming-in-the-small (50-60 luvut) Henkilökohtainen tehokkuus Programming-in-the-large (70-luku) Tuotteen kompleksisuuden hallinta ja modularisointi Programming-in-the-small (80-luku) Tuotantoprosessin ja projektityöskentelyn kompleksisuuden hallinta OT tänään Krooniset ongelmat jatkuvat Nyrkkisääntö (1994): Jopa hyvin suunnitellut ohjelmistohankkeet ylittävät budjettinsa keskimäärin 25 % ja aikataulunsa 50 % OT ei ole vieläkään yhtä kehittynyt kuin monet muut insinööritieteet CMM:n tilastoissa 65 % viimeisen viiden vuoden aikana luokitelluista yrityksistä on jäänyt alle tason kolme (tasot 1-5)

4 Ongelmien lähteitä Ohjelmistotekniikalta odotetaan liikaa: Tekniikka on kehittynyt nopeammin kuin ohjelmistotuotannon tehokkuus Kompleksisuus on samalla kasvanut Laatuvaatimukset Kompleksisuus PC:n suorituskyky Mobiilipäätelaitteet Internet Ongelmien lähteitä Teknologiasiirron hitaus Uudet menetelmät siirtyvät käytännön ohjelmistotyöhön jopa vuoden viiveellä Liian suuret laatuvaatimukset

5 Tekniikan kehitys tieteeksi (Shaw 1990) 1. Mikä tahansa toimiva (ad hoc) ratkaisu kelpaa. 2. Löydetään ratkaisuja, jotka toimivat useammassa kuin yhdessä tapauksessa ( kansanperinne ) 3. Otetaan käyttöön systemaattisia menetelmiä 4. Kehitetään malleja, teorioita ja formaaleja menetelmiä 5. Löydetään uusia ongelmia, ja palataan taas alkuun Ohjelmistotekniikan kuvailua Software Engineering means how to program if you can t (Dijkstra 1968) Mitään ihmeratkaisua ohjelmistotekniikan ongelmiin ei ole tulossa, vaan kehitys jatkuu edelleen vähäisenä (Brooks 1986) Ohjelmistotekniikka ei ole perinteisten insinööritieteiden tasolla, paitsi joillakin hyvin hallituilla osa-alueilla (Shaw 1990) Oliomenetelmien arvellaan yleisesti vaikuttavan tuntuvasti

6 Ohjelmistotekniikan myyttejä (johto) Meillä on dokumentoidut toimintatavat. Eivätkö työntekijät näe siitä kaiken tarpeellisen. Työntekijöillä on uusimmat kehitysvälineet miksi ei synny parempaa tulosta? Jos jäämme aikataulusta jälkeen, voimme korjata sen lisäämällä ohjelmoijia. Ohjelmistotekniikan myyttejä (asiakas) Yleinen tavoitteiden määrittely riittää, jotta ohjelmien kirjoittaminen voidaan aloittaa yksityiskohdat voidaan täydentää myöhemmin. Projektin vaatimukset muuttuvat jatkuvasti, mutta muutokset voidaan toteuttaa helposti, koska ohjelmisto on joustavaa (vrt. laitteistot).

7 Virheen suhteellinen kustannus (Boehm 1981) X Virheen korjaamisen suhteellinen kustannus 1 3-6X 10X 15-40X 30-70X (82X IBM keskiarvo) Vaatimusmäärittely Suunnittelu Koodaus Kehitys- Testaus Hyväksymis- Testaus Käyttöönotto, Ylläpito Ohjelmistotekniikan myyttejä (työntekijä) Työ on tehty, kun olemme kirjoittaneet ohjelman, joka toimii. Ennen kuin saan ohjelman pyörimään en voi mitenkään arvioida sen laatua Onnistuneen projektin ainoa toimitettava tuotos on toimiva ohjelma

8 Ohjelmistotekniikan erityispiirteitä 1/2 Ohjelmistot ovat abstrakteja, eivät fyysisiä -> joustavuus, monimutkaisia Ohjelmistojen käyttäytyminen on epäjatkuvaa -> ei voida tehdä oletuksia, sillä pienikin virhe voi kaataa koko järjestelmän Ohjelmisto kehitetään, sitä ei koota peruskomponenteista ohjelmistotehdas tuotekehitysosasto Ohjelmistojen monistaminen on halpaa Ohjelmistotekniikan erityispiirteitä 2/2 Ei varastotavaraa ohjelmistot räätälöidään asiakaskohtaisesti Ohjelmat eivät kulu, mutta ylläpito voi johtaa ränsistymiseen. Varaosia ei ole, kuten fyysisissä tuotteissa.

9 Keskeiset ongelma-alueet Vaatimusmäärittely Vaatimusten oikeellisuus on tärkeää lopputuotteen tehokkuuden ja laadun kannalta. Kompleksisuus Integraation tarve Standardit Projektitoiminnan tarve (Windows työntekijää) Muutostarpeet Tuotteen hallinta Ylläpito Ongelmakysymyksiä Miksi ohjelmistotuotanto on niin kallista ja hidasta? Miksi ohjelmistoprojektien keston ja kustannusten arviointi on niin vaikeaa? Miksi kaupallisissa ohjelmissa on puutteita ja virheitä? Miksi ohjelmistojen suunnittelu on vaikeaa? Miksi valmista ja toimivaa ohjelmaa täytyy ylläpitää? Miksi eri ohjelmistojen välillä on niin paljon yhteensopivuusongelmia?

10 Tuottavuustekijät Tekijöiden yhteisvaikutus maksimissaan n. 13x!!! Tuottavuustekijä Inhimilliset tekijät Ongelmatekijät Prosessitekijät Tuotetekijät Resurssitekijät Vaikutus (max.) +90% +40% +50% +140% +40% Riskitekijät 1/3 Riskitekijä Henkilöstöresurssien riittämättömyys Epärealistiset aikataulut ja budjetit Väärien toimintojen ja ominaisuuksien kehittäminen Riskinhallintatavat Asiantuntijan palkkaus Työtehtävien ja kykyjen vastaavuuden tarkistaminen Koulutus Vähittäinen kehittäminen Uudelleenkäyttö Vaatimusten selkeyttäminen Organisaatioanalyysi Käyttäjien osallistuminen Protoilu

11 Riskitekijät 2/3 Riskitekijä Vääränlaisen käyttöliittymän kehittäminen Liiat/turhat ominaisuudet Jatkuva vaatimusten muuttuminen Puutteet ulkopuolisissa komponenteissa tai työtehtävissä Riskinhallintatavat Protoilu Käyttäjien osallistuminen Vaatimusten selkeyttäminen Protoilu Kustannus-hyöty analyysi Korkea muutoskynnys Muutosten lykkääminen Laatukriteerien määrittely Tarkastukset Tieto aiemmista asiakkaista Riskitekijät 3/3 Riskitekijä Reaaliaikaisuuden puutteet Tietojenkäsittelyresurssien ylikuormitus Riskinhallintatavat Simulointi Laatukriteerien määrittely Tekninen analyysi Protoilu

12 Kustannustekijät riskit 1/2 Vaatimukset Ohjelmiston koko Laitteiston resurssirajoitukset Sovelluksen reaaliaikavaatimus Teknologian tuttuus Vaatimusten pysyvyys Henkilöstö Saatavuus ja vaihtuvuus Osaamisalueet vs. sovellusalue Kokemus Henkilöstöjohtaminen Kustannustekijät riskit 2/2 Uudelleenkäytettävä ohjelmisto Saatavuus (alihankinta) Muutostarpeet Kielen sopivuus vaatimuksiin Oikeudet Laadun varmennus Työvälineet Välineiden muutostarve Saatavuus Oikeudet Konfiguraation hallinta

13 Weinbergin teesit 1/2 1. Parhaiten menestyvät ne, jotka eivät luota liikaa uusiin poppakonsteihin, mutta ovat valmiita kokeilemaan uusia ideoita. 2. Mikään ei korvaa ratkaistavan ongelman perusteellista ymmärtämistä 3. Mikään ratkaisutapa ei sovi kaikkiin tehtäviin. Jossain tapauksessa paras ratkaisu voi olla toisessa tapauksessa huonoin 4. On monia hyödyllisiä lähestymistapoja, jotka ovat toimineet useammassa kuin yhdessä tilanteessa, joten kannattaa tutustua sellaiseen, mikä on toiminut aikaisemmin Weinbergin teesit 2/2 5. Ongelman ratkaisun niksi ei ole pelkästään miten menetelmiä sovelletaan (know-how), vaan mieluummin milloin niitä sovelletaan (know-when) 6. Riippumatta siitä, kuinka hyvin taitaa edellisen kohdan miten ja milloin, on olemassa ongelmia, jotka ovat nykytietämyksellä mahdottomia ratkaista tai joiden perimmäisistä kukaan ei ymmärrä riittävästi.

14 Monimuotoisuus Ohjelmistotyypit: Systeemiohjelmisto Reaaliaikaohjelmistot Tieteellinen ohjelmisto Hallinnollinen ohjelmisto Sulautettu ohjelmisto Henkilökohtainen ohjelmisto Tekoälyjärjestelmät Sovellusalueet: Pankit Vakuutusyhtiöt Elektroniikkateollisuus Vapaa-aika Sotateknologia Yms. Vaaditaan erityisosaamista ohjelmistotyypistä ja sovellusalueesta!