Ohjelmistotekniikka kevät 2003

Johdatusta ohjelmistotekniikkaan

Ohjelmistotekniikka kevät 2003

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

Ohjelmistotekniikka kevät 2003

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ä (~100 000)

-> 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 (~10 000 000)

Ohjelmistotekniikka kevät 2003

Tietotekniikan hyödyntäminen

”Akateeminenmaailma”

Yritykset

Kotitaloudet

Aika

Ohjelmistotekniikka kevät 2003

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

Ohjelmistotekniikka kevät 2003

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)

Ohjelmistotekniikka kevät 2003

Ongelmien lähteitä

• Ohjelmistotekniikalta odotetaan liikaa:– Tekniikka on kehittynyt nopeammin kuin

ohjelmistotuotannon tehokkuus– Kompleksisuus on samalla kasvanut

Kompleksisuus

InternetPC:n suori-

tuskyky

Mobiilipääte-laitteet

Laatuvaatimukset

Ohjelmistotekniikka kevät 2003

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

Ohjelmistotekniikka kevät 2003

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

Ohjelmistotekniikka kevät 2003

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

Ohjelmistotekniikka kevät 2003

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.

Ohjelmistotekniikka kevät 2003

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

Ohjelmistotekniikka kevät 2003

13-6X

10X

15-40X

30-70X

40-1000X

(82X IBMkeskiarvo)

Vir

heen k

orjaam

isen s

uhte

elli

nen k

ust

annus

Vaatimus-määrittely

Suunnittelu Koodaus Kehitys-Testaus

Hyväksymis-Testaus

Käyttöönotto,Ylläpito

Virheen suhteellinen kustannus (Boehm 1981)

Ohjelmistotekniikka kevät 2003

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

Ohjelmistotekniikka kevät 2003

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

Ohjelmistotekniikka kevät 2003

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.

Ohjelmistotekniikka kevät 2003

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

Ohjelmistotekniikka kevät 2003

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?

Ohjelmistotekniikka kevät 2003

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%

Ohjelmistotekniikka kevät 2003

Riskitekijät 1/3

Riskitekijä Riskinhallintatavat

Henkilöstöresurssien riittämättömyys

Asiantuntijan palkkausTyötehtävien ja kykyjen vastaavuuden tarkistaminenKoulutus

Epärealistiset aikataulut ja budjetit

Vähittäinen kehittäminenUudelleenkäyttöVaatimusten selkeyttäminen

Väärien toimintojen ja ominaisuuksien kehittäminen

OrganisaatioanalyysiKäyttäjien osallistuminenProtoilu

Ohjelmistotekniikka kevät 2003

Riskitekijät 2/3

Riskitekijä Riskinhallintatavat

Vääränlaisen käyttöliittymän kehittäminen

ProtoiluKäyttäjien osallistuminen

Liiat/turhat ominaisuudet Vaatimusten selkeyttäminenProtoiluKustannus-hyöty analyysi

Jatkuva vaatimusten muuttuminen

Korkea muutoskynnysMuutosten lykkääminen

Puutteet ulkopuolisissa komponenteissa tai työtehtävissä

Laatukriteerien määrittelyTarkastuksetTieto aiemmista asiakkaista

Ohjelmistotekniikka kevät 2003

Riskitekijät 3/3

Riskitekijä Riskinhallintatavat

Reaaliaikaisuuden puutteet SimulointiLaatukriteerien määrittely

Tietojenkäsittelyresurssien ylikuormitus

Tekninen analyysiProtoilu

Ohjelmistotekniikka kevät 2003

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

Ohjelmistotekniikka kevät 2003

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

Ohjelmistotekniikka kevät 2003

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

Ohjelmistotekniikka kevät 2003

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.

Ohjelmistotekniikka kevät 2003

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!