Ohjelmistotekniikka kevt 2003 Johdatusta ohjelmistotekniikkaan Ohjelmistotekniikka kevt 2003

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) 1. Henkilökohtaisia tietokoneita + hajautettuja järjestelmiä 2. Ohjelmistokustannukset > laitteistokustannukset 3. 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)

Ohjelmistotekniikka kevät 2003 Tietotekniikan hyödyntäminen Kotitaloudet Yritykset ”Akateeminen maailma” 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 Mobiilipäätelaitteet Laatuvaatimukset Kompleksisuus PC: n suorituskyky Internet

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 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. 13 x !!! 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 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

Ohjelmistotekniikka kevät 2003 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

Ohjelmistotekniikka kevät 2003 Riskitekijät 3/3 Riskitekijä Riskinhallintatavat Reaaliaikaisuuden puutteet Simulointi Laatukriteerien määrittely Tietojenkäsittelyresurssien ylikuormitus Tekninen analyysi Protoilu

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: Sovellusalueet: • • • Systeemiohjelmisto Reaaliaikaohjelmistot Tieteellinen ohjelmisto Hallinnollinen ohjelmisto Sulautettu ohjelmisto Henkilökohtainen ohjelmisto • Tekoälyjärjestelmät Pankit Vakuutusyhtiöt Elektroniikkateollisuus Vapaa-aika Sotateknologia Yms. Vaaditaan erityisosaamista ohjelmistotyypistä ja sovellusalueesta!