Johdanto, elinkaari (luvut 1 ja 2)

1. Johdanto, elinkaari (luvut 1 ja 2) • Ohjelmistot • Tuotantoprosessi • Osaamisalueet • Elinkaari/prosessi-mallit • Osa-alueet • Kustannukset

2. Software Engineering -- ohjelmistotuotanto ? • Software -- ohjelmisto ? • Computer programs, procedures, rules, documentation, and data pertaining to the operation of a computer system. • Software Engineering -- ohjelmistotuotanto ? • The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. [IEEE 610.12]

3. Ohjelmakoodi • Ohjelmakoodia kirjoitetaan jollain ohjelmointikielellä, tässä esimerkiksi shakkia pelaavaa ohjelmaa C++-kielellä • Realistisissa järjestelmissä tällaisia rivejä on tuhansittain, esimerkiksi puhelinkeskuksessa vaikkapa 15 miljoonaa. • Ohjelmisto on aineetonta: • sitä on vaikea hahmottaa • sen laatua ja valmiusastetta on vaikea arvioida • virheitä syntyy helposti, ja niitä löytyy vielä pitkänkin käytön jälkeen if((( loppuy == 0) && (alkuy==1)) && ((alkux==loppux) ||(alkux==loppux-1) || (alkux==loppux+1) || (alkux==loppux+1) )){ return true; //siirto oli ok } //end of if //jos loppuruutu on tyhja, eli nappula on null vektori if(nappula == 0){//jos ruutu on yksi ylospain, siirto ok. if((alkux == loppux) && ((alkuy-1) == loppuy)){ return true; //siirto oli ok } //jos ruutu on kaksi ylospain if((alkux == loppux) && ((alkuy-2) == loppuy) && (lauta->kuka_on_ruudussa(alkux, alkuy-1))== 0 ){ //jos ollaan toisiksi alimmassa ruudussa if(alkuy == 6){ return true; //siirto oli ok }else{ return false; //yritettiin vaaraa siirtoa } } //end of if //ohestalyonti…

4. Kuva 1.2

6. Ohjelmistotyyppejä(1) • Varus- ja työkaluohjelmistot • teknis-tieteelliseen laskentaan tarkoitetut ohjelmistot • tietämyspohjaiset järjestelmät • kaupallishallinnolliset ohjelmistot • prosessinohjaus- ja prosessiautomaatiojärjestelmät

7. Ohjelmistotyyppejä(2) • Sulautetut järjestelmät • Koneen tai laiteen sisällä • hissin ohjausjärjestelmä • Reaaliaikajärjestelmät • Ohjelman on reagoitava heti • polttoaineen ja jarrujen säätely • Reaktiiviset järjestelmät • toimivat jatkuvasti • puhelinkeskus Pohdittavaa: Minkälainen on tyypillinen nykyaikainen ohjelmisto?

8. Ohjelmiston luonne • ohjelmiston koko ja käsiteltävän tiedon määrä • käsittelypainotteinen vs. tietopainotteinen • vasteaika- ja reaaliaikaisuusvaatimukset • kovat reaaliaikavaatimukset • reaktioaika

9. Ohjelmiston ominaisuuksia • luotettavuus • puolustava ohjelmointi • elektroniikka- ja mekaniikkatason varmistukset • hajautus • paikallinen / laaja • sulautetut järjestelmät - laiteväylä • tuotteistusaste • räätälöity vs. täysin tuotteistettu massatuote • asiakasvarioituvat massatuotteet

10. Sulautetut järjestelmät • NMT-puhelin 20 kLOC • GSM-keskus 15MLOC • GSM-puhelin 500 kLOC • kommunikaattori 1,5 MLOC • 3G matkapuhelin – koodimäärä kolminkertaistuu 2G-puhelimeen verrattuna • televisio 200 kLOC • hissi 50 kLOC • moderni auto 50 kLOC • avaruussukkula 21 MLOC (sukkulassa 0,5MLOC) LOC – Lines of Code, koodiriviä 2.9

11. Motto (kautta vuosien)

12. 30 years ago mainframes small programs proprietary all self made terminating programs centralized systems non -critical tailored heroes and cowboys ADP, scientific applications Now “network is the computer” complex systems heterogeneous, standardized numerous vendors/subcontractors 24 h * 7 days/week distribution critical product families teamwork masses of new application areas, embedded systems&more traditional systems combined What has changed?

13. What has not changed ? • Quality is still a problem -- even worse than before. • Producing SW is still handicraft, i.e. highly person dependent with extremely high variance in individual productivity. • Minor part of projects are success stories. Out of 5 projects one never delivers anything useful, and most (all?) of the rest suffer from serious schedule&budget. • The most common reasons for failures are seldom technical, but rather due to poor management, poor process skills etc.

14. Määrittely Suunnittelu& toteutus Asiakasvaatimuksista tuotteeseen asiakasvaatimukset ohjelmistovaatimukset

15. Asiakas- ja tuotekehitysprosessit (Kuva 11.4)

16. Asiakas- ja tuotekehitysprosessit (Kuva 11.4)

17. Areas of expertise Management skills Presentation& negotiation skills, teamwork Nongeneric technical skills Generic technical skills Application domain expertize Process skills

18. Half-life of the “market value” of skills :-) revolution Nongeneric technical skills Application domain expertize Process skills Presentation & negotiation skills, teamwork Management skills Generic technical skills evolution 0v 10v 20v

19. Elinkaari ja prosessi (Luku 2.1) • Elinkaari: ajanjakso ohjelman kehitystyöstä sen käytöstä poistamiseen. • Malleja • Vesiputous • Evo • Protoilu • Sulautetun järjestelmän kehitys • Järjestelmätoimitus • Tuotantoprosessi: toimintatapamalli, jolla ohjelmisto tuotetaan • Vaiheet (esimerkiksi tarjous, vaatimukset, määrittely…) • Tukitoiminnot (Tuotteenhallinta, seuranta ja mittaaminen…) • Roolit (projektipäällikkö, testaaja, ohjelmoija…) • Tehtävät, vastuut • Vaihetuotteet

20. Asiakas- vaatimukset Toiminallinen määrittely Tekninen määrittely Ohjelma- koodi yms. Valmis järjestelmä Vesiputousmalli (Kuva 2.2)

21. Miettimispysähdys • Oletetaan, että olet suunnittelemassa maailman ensimmäistä Notepad-ohjelman tapaista editoriohjelmaa. • Mitähän vuotta eletään? • Millaisia asioita tehdään/käsitellään/selvitellään vesiputousmallin eri tasoilla: • vaatimusten määrittelyssä • toiminnallisessa määrittelyssä • teknisessä määrittelyssä • toteutuksessa • integroinnissa? • Mitenhän toimitus voitaisiin jakaa vaiheisiin? • Millaisia rooleja elinkaarimalliin liittyy? 9.9

22. Todellisuus määritely suunnittelu toteutus testaus suunniteltu todellisuus aika

23. Tietoviikko, Mikko Torikka 9.9.2003 Baan ja Konecranes pääsivät sopuun KCI Konecranes ja toiminnanohjaustalo Baan pääsivät sopuratkaisuun kiistassaan, joka alkoi epäonnistuneesta Omniman erp-projektista. Projektisopimus solmittiin vuonna 1998 ja projekti päättyi vuonna 2000. Yhtiöillä oli oikeuskiistoja Ruotsissa, Alankomaissa sekä Yhdysvalloissa. Sopimuksen perusteella kaikki kiistat on lopullisesti sovittu. Sopimuksen yksityiskohdat ovat luottamuksellisia. Sopimus synnyttää Konecranesille kertaluonteisen kulun, mikä heikentää tulosta verojen jälkeen noin 5,5 miljoonaa euroa.

24. Vaatimukset (Kuva 2.3)

25. Tarjous- Projekti- Markki- Esitutkimus pyyntö suun- nointi nitelma asiakas Alustava määrittely Sopimus Toteutus- Alustava Tarjous projekti määrittely- Järjestelmä asiakas dokumentti & asiakas dokumentit Koulutus- Projekti- Esisopimus Käyttöön- projekti suunnittelu otto- projekti Ylläpito Jälkiarviointi Toimitusprojekti (Kuva 2.11)

26. Protoilu (Kuva 2.7)

27. vuosi vuosi vuosi Tuotteen evoluutio • Tuotteen uudet versiot =>hidas evo-prosessi • Ongelmat • Tuntemattomat/muuttuvat/väärinymmärretyt… vaatimukset • Myöhäinen asiakaspalaute • Riskien hallinta • Opittujen asioiden hyödyntäminen • Testauksen aloittaminen ajoissa • Testausympäristöjen ja menetelmien testaaminen • Itsensä huijaaminen etapeissa • Kärsimättömät asiakkaat/pomot • Projektiryhmän usko onnistumiseen

28. osaamisalueet jäivät kattamatta Iteratiivinen prosessi 2 viikkoa 2 viikkoa 2 viikkoa 2 viikkoa Tärkeimmät käyttö- tapaukset: #1, 3 määrittely suunnittelu toteutus testaus Versio 0.1 Seuraavat KT:t: #2, 4, 5 määrittely suunnittelu toteutus testaus Versio 0.5 Loput KT:t: määrittely suunnittelu toteutus testaus Versio 1.0

29. iteratiivinen perinteinen Iteratiivisuuden laatutavoitteet ei-toiminnalliset ominaisuudet Toiminnallisuus

30. Projektinhallinta?

31. Ketterät prosessit • Agile processes • Vain oleellinen on tärkeää • Asiakas- ja tuotekeskeisyys • Kehittäminen tapahtuu asiakkaan kanssa yhteistyössä • Valmius jatkuvaan muutokseen • Iteratiivisuus • Osaamisen, ammattitaidon ja vastuuntunnon korostaminen • Esimerkiksi eXtreme Programming (XP) • test driven design • pariohjelmointi • …

33. Osa-alueet (Kuva 2.1)

34. Tukitoiminnot (2.3-2.4) • Laadunvarmistus • Dokumentointi • Tuotteenhallinta • Vaatimustenhallinta...

35. Laadunvarmistus (Luku 2.3) • Mitä kauemmin virheet ovat järjestelmässä, sen kalliimmaksi ne tulevat. • Terveydenhoito: toimintatavat, jotka vähentävät virheitä. • Sairaanhoito: virheiden seulominen mahdollisimman aikaisessa vaiheessa: tarkastukset.

36. esitutkimus& sopimus määrittely suunnittelu ohjelmointi ja tarkastus moduulitestaus katselmus, toimittajan integrointi katselmus, asiakas mukana järjestelmätestaus aika Tarkastukset ja katselmukset (Kuva 2.10)

37. Dokumentointi (Kuva 3.4)

38. Tuotteenhallinta (Kuva 13.1)

39. Vaatimustenhallinta(Kuva 4.2)

40. testaus koodaus moduuli- suunnittelu integrointi 6% määrittely 7% 7% 6% vaatimukset 5% 3% 67% ylläpito Kustannusten jakautuminen (Kuva 2.12)

41. Arvoketju (Kuva 2.13)

42. Kannattaako siis edes yrittää? (Kuva 1.6)

43. Yhteenveto 30 vuoden kokemuksesta What I found was this: the inspection and testing process, defect discovery and repair throughout the development life cycle, seemed to drive success -- delivering a usable system in time. I could not correlate success with programming methods such as design methods, language, or coding practices. A certain number of defects will be introduced regardless. What appears to matter a great deal is the application of professional engineering. By that I mean technical management: establishing precise plans and procedures; defining computer programs in terms of their correctness, not just their development, and evaluating them quantitatively with respect to budgets and schedules; using models; developing a detailed system integration plan; and measuring results scientifically (projects that rely on status reports, such as “test cases run”, do not fare well). Britcher, R.N., A View from Below. In: Glass, R.L., In the Beginning: Recollections of Software Pioneers, IEEE Computer Science Press (1998) pp. 98-111 (quotation from page 111).