Johdatusta ohjelmistotekniikkaan

1
Johdatusta ohjelmistotekniikkaan
2
OTn 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 -gt Ensimmäiset
  ohjelmistotalot
• Ohjelmistokriisi!!!

3
OTn historiaa 4 vaihetta (2/2)

• Vaihe (70-luvun alku 80-luvun loppu)
• Henkilökohtaisia tietokoneita hajautettuja
  järjestelmiä
• Ohjelmistokustannukset gt laitteistokustannukset
• Ohjelmistoilla paljon käyttäjiä (100 000)
• -gt massamarkkinet
• -gt laatuvaatimukset nousivat
• Vaihe (80-luvun loppu - )
• Tehokkaat PCt (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
• CMMn 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

Mobiilipääte- laitteet
Laatuvaatimukset
Kompleksisuus
PCn 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)

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

10
Ohjelmistotekniikan kuvailua

• Software Engineering means how to program if you
  cant (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ä
• -gt joustavuus, monimutkaisia
• Ohjelmistojen käyttäytyminen on epäjatkuvaa -gt 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
  !!!

Tuottavuustekijä Vaikutus (max.)
Inhimilliset tekijät 90
Ongelmatekijät 40
Prosessitekijät 50
Tuotetekijät 140
Resurssitekijät 40
20
Riskitekijät 1/3
Riskitekijä Riskinhallintatavat
Henkilöstöresurssien riittämättömyys Asiantuntijan palkkaus Työtehtävien ja kykyjen vastaavuuden tarkistaminen Koulutus
Epärealistiset aikataulut ja budjetit Vähittäinen kehittäminen Uudelleenkäyttö Vaatimusten selkeyttäminen
Väärien toimintojen ja ominaisuuksien kehittäminen Organisaatioanalyysi Käyttäjien osallistuminen Protoilu
21
Riskitekijät 2/3
Riskitekijä Riskinhallintatavat
Vääränlaisen käyttöliittymän kehittäminen Protoilu Käyttäjien osallistuminen
Liiat/turhat ominaisuudet Vaatimusten selkeyttäminen Protoilu Kustannus-hyöty analyysi
Jatkuva vaatimusten muuttuminen Korkea muutoskynnys Muutosten lykkääminen
Puutteet ulkopuolisissa komponenteissa tai työtehtävissä Laatukriteerien määrittely Tarkastukset Tieto aiemmista asiakkaista
22
Riskitekijät 3/3
Riskitekijä Riskinhallintatavat
Reaaliaikaisuuden puutteet Simulointi Laatukriteerien määrittely
Tietojenkäsittelyresurssien ylikuormitus Tekninen analyysi Protoilu
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

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

26
Weinbergin teesit 2/2

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

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