Evolving Trends in Software Engineering Over Decades

1. Johdatusta ohjelmistotekniikkaan

2. OT:n historiaa – 4 vaihetta (1/2) • 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ä • 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!!!

3. OT:n historiaa – 4 vaihetta (2/2) • Vaihe (70-luvun alku – 80-luvun loppu) • Henkilökohtaisia tietokoneita + hajautettuja järjestelmiä • Ohjelmistokustannukset > laitteistokustannukset • Ohjelmistoilla paljon käyttäjiä (~100 000) -> massamarkkinet -> laatuvaatimukset nousivat • Vaihe (80-luvun loppu - ) • Tehokkaat PC:t (myös kannettavat) • Oliotekniikat • Case-välineet • Valtavat käyttäjämäärät (~10 000 000)

4. Tietotekniikan hyödyntäminen Kotitaloudet Yritykset ”Akateeminen maailma” Aika

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

6. 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)

7. Ongelmien lähteitä • Ohjelmistotekniikalta odotetaan liikaa: • Tekniikka on kehittynyt nopeammin kuin ohjelmistotuotannon tehokkuus • Kompleksisuus on samalla kasvanut Laatuvaatimukset Mobiilipääte- laitteet Kompleksisuus PC:n suori- tuskyky Internet

8. Ongelmien lähteitä • Teknologiasiirron hitaus • Uudet menetelmät siirtyvät käytännön ohjelmistotyöhön jopa 10-20 vuoden viiveellä • Liian suuret laatuvaatimukset

9. Tekniikan kehitys tieteeksi (Shaw 1990) • Mikä tahansa toimiva (ad hoc) ratkaisu kelpaa. • Löydetään ratkaisuja, jotka toimivat useammassa kuin yhdessä tapauksessa (”kansanperinne”) • Otetaan käyttöön systemaattisia menetelmiä • Kehitetään malleja, teorioita ja formaaleja menetelmiä • Löydetään uusia ongelmia, ja palataan taas alkuun

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

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

12. 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).

13. Virheen suhteellinen kustannus (Boehm 1981)

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

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

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

17. Keskeiset ongelma-alueet • Vaatimusmäärittely • Vaatimusten oikeellisuus on tärkeää lopputuotteen tehokkuuden ja laadun kannalta. • Kompleksisuus • Integraation tarve • Standardit • Projektitoiminnan tarve (Windows 95 – 200 työntekijää) • Muutostarpeet • Tuotteen hallinta • Ylläpito

18. 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?

19. Tuottavuustekijät Tekijöiden yhteisvaikutus maksimissaan n. 13x !!!

20. Riskitekijät 1/3

21. Riskitekijät 2/3

22. Riskitekijät 3/3

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

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

25. Weinbergin teesit 1/2 • Parhaiten menestyvät ne, jotka eivät luota liikaa uusiin ”poppakonsteihin”, mutta ovat valmiita kokeilemaan uusia ideoita. • Mikään ei korvaa ratkaistavan ongelman perusteellista ymmärtämistä • Mikään ratkaisutapa ei sovi kaikkiin tehtäviin. Jossain tapauksessa paras ratkaisu voi olla toisessa tapauksessa huonoin • On monia hyödyllisiä lähestymistapoja, jotka ovat toimineet useammassa kuin yhdessä tilanteessa, joten kannattaa tutustua sellaiseen, mikä on toiminut aikaisemmin

26. Weinbergin teesit 2/2 • Ongelman ratkaisun niksi ei ole pelkästään miten menetelmiä sovelletaan (know-how), vaan mieluummin milloin niitä sovelletaan (know-when) • 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.

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