Ohjelmistotekniikka kevät 2015 Jouni Lappalainen Jouni Lappalainen 1
Luennoilla käydään läpi Pressmanin Software Engineering kirjan (7. painos) sisältö Hyvää materiaalia löytyy myös Open seminar sivulta http://openseminar.org/se/screen.do ja kirjasta Williams L., A (Partial) Introduction to Software Engineering Practices and Methods, (kannattaa googlettaa termillä williams-draftbook) Luennoilla tehdään myös pieniä luentotehtäviä. Luentotehtävien ratkaisu menestyksekkäästi antaa pisteitä kurssisuoritusta kohti. Tehtäviä on sekä luennon aluksi/ luennolle valmistautuessa että luennon päätteeksi. Luennot & harjoitukset Harjoitukset (7kertaa) etenevät luentojen rinnalla ja siellä käsitellään edellisen viikon luentoihin liittyviä tehtäviä. Tehtävät esitellään luennoilla ja kurssisivulla on linkki niihin. Harjoitukset voi tehdä 2-3 opiskelijan ryhmässä tai yksin. Ratkaisut kerätään harjoitusraportiksi, joka palautetaan periodin lopussa. Harjoitusraportti edellytetään kurssin suorittamiseen. Harjoitustehtävät on palautettava viikottain BitBucket-versionhallinta palveluun git-ohjelmistoa käyttäen. Hyvä harjoitusosaaminen antaa pisteitä kurssisuoritukseen. Se tarkoittaa tehtävien ratkaisua joko etukäteen tai harjoituksissa ratkaisujen esittelyä harjoitusten vetäjälle, joka pitää kirjaa suorituksista ratkaisujen keräämistä harjoitusraporttiin, joka palautetaan periodin lopussa 2 Jouni Lappalainen
Kuinka suorittaa kurssi? 2 vaihtoehtoa: ryhmätyö tai essee (molempiin vaihtoehtoihin kuuluu myös harjoitusraportti, osasuoritukset ovat voimassa seuraavaan kurssin toteutukseen) Ryhmätyö (study group) luennoilla annetaan pohdittavia tehtäviä (löytyvät myös kurssisivulta) etsikää lisämateriaalia ja pohtikaa pienessä ryhmässä (2-3 opisk.) ryhmä voi olla sama kuin harjoituksissa viikoittain palaveri, jossa käydään läpi edellisen viikon asiat (ja ryhmän ratkaisut) jokainen ryhmän jäsen osallistuu myös tehtävien esittelyyn Essee voitte valita noin 10 aihetta, joista kirjoitatte esseessä (tarkoituksena on tutustua laajasti ohjelmistotekniikkaan) materiaalia löytyy esim. Pressmanin kirjasta ja webistä IEEE Software (Nelli portaalin kautta) Computer (Nelli portaalin kautta) Crosstalk (http://www.crosstalkonline.org) Jouni Lappalainen 3
Miten arvostellaan? 2 vaihtoehtoa: ryhmätyö tai essee Molemmissa vaihtoehdoissa on suoritettava harjoitukset palauttamalla harjoitustehtäviin hyväksyttävät vastaukset harjoitusraportin muodossa! Harjoitustehtävistä voi saada pisteitä (max. 8 pistettä) vain esittelemällä hyväksyttävät Vastaukset kyseisen viikon harjoituksissa harjoitusten vetäjille, jotka pitävät kirjaa suorituksista. Luentotehtävistä voi hyväksyttävillä vastauksilla saada pisteitä (max. 14 pistettä) molempiin suoritusvaihtoehtoihin. Study group -työskentely + -raportti / essee: (max. 34 pistettä) Hyvältä arvosanalta vaaditaan - perustumista ohjelmistotuotannon oppikirjoihin ja alan lehtiin - monipuolista ja kriittistä lähteiden käyttöä (muista myös viitata tekstissä) - omaa pohdintaa lukujen lopussa (jos on omaa kokemusta alalta, voi käyttää) - hyvää rakennetta ja hyvää kieltä Arvosanat jakautuvat (max 50pistettä) Arvosana 1: 25-28 pistettä Arvosana 2: 29-32 pistettä Arvosana 3: 33-37 pistettä Arvosana 4: 38-43 pistettä Arvosana 5: 44-50 pistettä 4
Mistä materiaalia ryhmätöihin ja esseisiin? Ohjelmistotekniikan lait (esitellään luentojen yhteydessä): poimittu 50 laista ja 25 hypoteesistä, jotka esitetty kirjassa: Endres A., Rombach D., A handbook of software and systems engineering: empirical observations, laws and theories, 2003 1. Mikä sopii pieniin järjestelmiin ei sovi suuriin / no 11, DeRemer 1975 1. Ohjelmiston uudelleenkäyttö vähentää kehitysaikaa ja parantaa tuottavuutta ja laatua / no 15, McIlroy 1968 (Naur 1969) 1. Henkilöiden lisääminen myöhässä olevaan projektiin aiheuttaa vain lisää myöhästymistä / no 36, Brooks 1975 5
Millaisia kysymyksiä study groupeissa käsitellään? Miten ohjelmistojen korjaamisen aiheuttamaa rapistumista" voidaan välttää? Tee yhteenveto Hookerin seitsemästä periaatteesta ja esitä tiivistelmä omin sanoin muutamalla lauseella (katso http://c2.com/cgi/wiki? SevenPrinciplesOfSoftwareDevelopment) Cockburn esittelee oheisessa paperissa yhtäläisyyksiä ohjelmistojen kehittämisen ja perinteisen teollisen tuotannon välillä. Mikä on mielestäsi paperin tärkein sanoma ohjelmistojen kehittäjille? Cockburn A., What engineering has in common with manufactoring and why it matters, Crosstalk, April, 2007, pp. 4-7 6
Palaute Kurssilla on käytössä jatkuvan palautteenannon järjestelmä: http://jounilappalainen.fi/ohjelmistotekniikka Palautetta seurataan käytännössä päivittäin, ja mikäli jotain tärkeää ilmenee, niin asioihin voidaan palata vaikkapa heti seuraavalla kerralla. Palautetta voi antaa niin monta kertaa kuin haluaa Palautteenanto ja sitä tukeva järjestelmä on osa laitoksen tutkimusta, ja tästä kokeilusta saatuja tuloksia voidaan käyttää tieteellisten julkaisujen materiaalina Palautejärjestelmästä ei voi yksilöidä yksittäisen vastauksen antajaa, ja tulokset ovat näkyvissä vain palvelimen ylläpitäjälle, tutkimuksen tekijälle (M. Kelanti) ja kurssin vastuuhenkilölle. Jouni Lappalainen 7
Ohjelmistotekniikka - FAQ 1. Mitä ohjelmistotekniikka tarkoittaa 2. Mikä on ohjelmisto, miten se poikkeaa muista ihmisen rakentamista tuotteista? 3. Millaisia ohjelmistosovelluksia on? 4. Ohjelmistotuotannon peruskäytänteet ja periaatteet. 5. Onko jokin prosessimalli (elinjaksomalli) paras? 6. Onko jokin suunnittelumenetelmä paras ja jokin kuvaustapa se ainoa ja oikea? 7. Miten ohjelmiston laatuvaatimukset vaikuttavat ohjelmiston kehittämiseen? 8
Ohjelmistotekniikka - FAQ 8. Mitkä tekijät aiheuttavat eniten virheitä? 9. Mikä on ylläpidon rooli? 10. Miten ohjelmistojen kehitys muuttuu tulevina vuosina? 9
1. Mitä ohjelmistotekniikka tarkoittaa The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines» määrittely Naton järjestämässä ensimmäisessä SE konferenssissa 1968 /Naur & Randell 1969 Software engineering is that form of engineering that applies the principles of computer science and mathematics to achivieng cost-effective solutions to software problems. / CMU/SEI-90-TR-003 The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. / IEEE 1990 10
SWEBOK 11
Core Body of Knowledge Areas Graduate Software Engineering 2009 (GSwE2009) Curriculum Guidelines for Graduate Degree Programs in Software Engineering Integrated Software & Systems Engineering Curriculum (issec) Project 12
Ohjelmistotuotanto vai ohjelmistotekniikka - ohjelmistotuotannon osa-alueet / Haikala & Märijärvi 2000 Liiketoiminta, johtaminen Laatujärjestelmä Hankkeiden hallinta Projektinhallinta Projektinhallinta Projektinhallinta määrittely suunnittelu ohjelmointi testaus tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta, riskienhallinta,... käyttöönotto ylläpito 13
SEMAT (Software Engineering Methods and Theory) ydin Jacobson Ivar, Ng Pan-Wei, McMahon Paul, Spence Ian, Lidman Svante, The Essence of Software Engineering: the Semat Kernel CSI Communications, August 2013, pp. 7-14 14
2. Mikä on ohjelmisto, miten se poikkeaa muista ihmisen rakentamista tuotteista? Luontainen monimutkaisuus ongelmat ovat monimutkaisia Näkymättömyys eri tason kuvauksia Muunnettavuus helppo muuttaa Ainutkertaisuus räätälöidyt ratkaisut valmiiden komponenttien käyttö lisääntyy Skaalautumattomuus isot projektit/pienet projektit valtameriristeilijän rakentaminen ei ole samaa kuin 3000 soutuveneen rakentaminen Laatutavoitteet/laatutekniikat täydellinen testaus mahdotonta ohjelmisto ei kulu 16
Laitteiston häiriöasteen kasvu häiriöaste aika 17
Ohjelmiston häiriöasteen kasvu häiriöaste aika todellinen käyrä - miksi? tavoitekäyrä 18
Ohjelmiston häiriöasteen kasvu sivuvaikutusten aiheuttama häiriöaste häiriöaste muutos aika todellinen käyrä tavoitekäyrä 19
3. Millaisia ohjelmistosovelluksia on? Järjestelmäohjelmistot Sovellusohjelmistot Tekniset/tieteelliset ohjelmistot Sulautetut ohjelmistot Tuotelinjaohjelmistot Web-sovellukset Tekoälyohjelmistot Lisäksi jokapaikan (pervasive) ohjelmistot, jotka kehitetty hajautetusti ja avoimeen koodiin perustuen 20
Web sovelluksen ominaispiirteet Verkosta riippuvuus (verkkointensiivisyys) sovellus elää verkossa ja palvelee hyvin hajanaisen asiakaskunnan tarpeita Samanaikaisuus suuret käyttäjämäärät käyttävät sovellusta samaan aikaan, käyttötavat voivat poiketa paljonkin Ennustamaton kuormitus käyttäjämäärät voivat vaihdella huomattavasti eri päivinä Suorituskyky vasteajan täytyy olla kohtuullinen, jotta käyttäjä on tyytyväinen
Web sovelluksen ominaispiirteet Palveluaste (availability) vaikka 100 % palveluastetta ei saavuteta, suositun sovelluksen käyttäjät vaativat 24/7/365 palvelua Tietoa käyttäjälle sovelluksen ensisijainen tarkoitus on hypermedian keinoin tarjota tietoa eri esitysmuodoissa Sisällön tärkeys sisällön laatu ja esitystapa tärkeimmät sovelluksen laatutekijät Jatkuva evoluutio Web sovellukset kehittyvät jatkuvasti, eivät suunnitelluin julkaisuin, kuten perinteiset
Web sovelluksen ominaispiirteet Välittömyys (kehittämisnopeus) Web sovellusten kehittämisaika muutamia päiviä/viikkoja Varmuus sovelluksen käytön oltava turvallista käyttäjän kannalta Esteettisyys teknisen suunnittelun lisäksi tarvitaan myös ulkonäön suunnittelua
4. Ohjelmistotuotannon peruskäytänteet ja periaatteet Ohjelmistotuotannon peruskäytänteet How to solve it Polya 1945 Ymmärrä ongelma kommunikointi ja analyysi Suunnittele ratkaisu mallintaminen ja ohjelmistosuunnittelu Toteuta suunnitelma koodin generointi Testaa toteutusta testaus ja laadunvarmistus Ohjelmistotuotannon periaatteet Hooker 1996 The reason it all exists KISS Maintain the vision What you produce, others will consume Be open to the future Plan ahead for reuse Think! 24
Ohjelmistotuotannon 7 ydinperiaatetta / Hooker 1996 The Reason It All Exists Tuotetun ohjelmiston tulee olla hyödyllinen käyttäjälle, älä lisää mitään ominaisuuksia, jotka eivät tuo lisäarvoa KISS (Keep It Simple, Stupid!) kaiken suunnittelun tulee olla niin yksinkertaista kuin mahdollista, mutta ei yksinkertaisempaa Maintain the Vision selvä visio tavoitteesta on onnistuneen projektin tae What You Produce, Others Will Consume ohjelmistoa ei kehitetä tyhjiössä, määrittele, suunnittele ja koodaa ohjelmisto se mielessä, että jonkun muun täytyy ymmärtää tuotoksesi Be Open to the Future järjestelmien elinkaari on pitkä - ylläpitoa tarvitaan, älä suunnittele itseäsi nurkkaan, muista suunnitellessasi entäpä jos kysymykset Plan Ahead for Reuse uudelleenkäyttö säästää aikaa ja työpanosta, mutta uudelleenkäytettävyyden huomioiminen komponentin suunnittelussa ja toteutuksessa lisää myös kustannuksia (25-200%) Think! parempiin tuloksiin pääsee, kun miettii hetken ennen tekemistä» http://c2.com/cgi/wiki?sevenprinciplesofsoftwaredevelopment 25
5. Onko jokin prosessimalli (elinjaksomalli) paras? Ohjelmistotuotannon yleiset käytänteet How to solve it Polya 1945 Ymmärrä ongelma kommunikointi ja analyysi Suunnittele ratkaisu mallintaminen ja ohjelmistosuunnittelu Toteuta suunnitelma koodin generointi Testaa toteutusta testaus ja laadunvarmistus Prosessikehikon aktiviteetit» Pressman 2005 kommunikointi projektisuuunnittelu mallintaminen rakentaminen toimitus, käyttöön vieminen (deployment) 26
Käyttäjän tarpeet Vesiputousmalli Vaatimusmäärittely Toiminnallinen suunnittelu - käyttöliittymän suunnittelu - käyttötapausanalyysi Ohjelmistosuunnittelu Toteutus Integrointi ja testaus Käyttöönotto ja ylläpito
Lisäyksin etenevä kehittäminen (inkrementaalinen) Kommunikointi Projektin suunnittelu Mallintaminen Ohjelmiston toiminnallisuus ja ominaisuusdet Lisäys 1 Lisäys 2 Lisäys n Lisäyksen 1 toimitus Lisäyksen 2 toimitus Rakentaminen Toimitus Lisäyksen n toimitus Projektin kalenteriaika 28
(Rational) Unified Process (iteratiivinen ja inkrementaalinen) Elaboration (kehittäminen) Inception (aloitus) suunnittelu mallintaminen julkaisu ohjelmiston uusi osa kommunikointi toimitus Production (tuotanto) Transition (siirto) rakentaminen Construction (rakentaminen)
Scrum prosessi (sprintti ja sen katselmointi) Sprintin työlista: - ominaisuudet yhteen Sprint kierrokseen Kehitä, paketoi, katselmoi, sovita (ei vaadita peräkkäisyyttä) Tuotteen työlista (backlog): - asiakkaan haluamat ominaisuudet Päivittäin 30 päivää 15-30 minuutin päivittäinen Scrum tapaaminen ( tilannekatsaus) Ei projektipäällikköä, Scrum master valvoo prosessin noudattamista Uusi toteutettu ominaisuus Sprintin katselmointi: sidosryhmä osallistuu 30
6. Onko jokin suunnittelumenetelmä paras (ja jokin kuvausmenetelmä ainoa ja oikea)? Suunnittelumenetelmät ovat aikansa lapsia (kaikissa eri abstraktiotason kuvauksia) 1980 luvulla JSD (Jackson System Development), Jackson 1983 MSA (Modern Structured Analysis), Yourdon 1989 1990 luvulla oliomenetelmät ja kuvaustavat, kuten OOA & OOD, Coad & Yourdon 1991 OMT, Rumbaugh et al. 1991 UML kuvaustavan määrittely, Rumbaugh et al. 1999 UML & RUP prosessi, Jacobson et al. 1998 OMT++, Jaaksi et al. 1999 2000 luvulla UML & RUP valtakausi jatkuu 31
Olioperustainen ohjelmistokehitys Rakenne Korkean tason toiminnalisuus Käyttötapauskaaviot Käyttäytyminen Ohjelmistokehitys Esimerkkejä Oliokaaviot Aktiviteettikaaviot Sijoittelukaaviot Komponenttikaaviot Luokkakaaviot Sekvenssikaaviot Tilakaaviot Yhteistyökaaviot Koskimies K., Oliokirja, 2000
Use case; Sending a short message Description: The user writes a short message and adds his signature to the end of the message. Then he sends the message to selected recipients. User System Phone request() send() OK User MainView MainController Phone request() sendrequest() send() OK showmessage( Done ) Analyysi Arkkitehtuurisuunnittelu User MainView MainController Recipient Phone buttonpressed() sendrequest(text,names) getnumber(name) Loop: while names nbr send(text,nbr) End of loop OK showmessage( Done ) Yksityiskohtainen suunnittelu Pienimuotoinen esimerkki ratkaisun tarkentumisesta class MainController{ MainView v; Recipient r; Phone p; void sendrequest(text,names) { nbr = r.getnumber(name); p.send(text,nbr); v.showmessage( Done ); } } Ohjelmointi 33
7. Miten ohjelmiston laatuvaatimukset vaikuttavat ohjelmiston kehittämiseen? luotettavuutta korostava (dependability, reliability) tuotteen laatuominaisuuksia tarkasteleva Toiminnallisuus (Functionality) suitability, accuracy, interoperability, security Luotettavuus (Reliability) maturity, fault tolerance, recoverability Käytettävyys (Usability) understandability, learnability, operability, attractiveness Tehokkuus (Efficiency) time behaviour, resource utilisation Ylläpidettävyys (Maintainability) analysability, changeability, stability, testability Siirrettävyys (Portability) adaptability, installability, co-existence, replaceability 34
Mitä ohjelmistovirheet voivat aiheuttaa? Vakavia onnettomuuksia Therac-25 sädehoitolaitteisto antoi liian suurta säteilyä 80 luvulla Ariane-5 raketti tuhoutui lähdössä 1996 Mars luotain tuhoutui 1999 Pienempiä häiriöitä - yleensä uusien ohjelmistoversioiden käyttöönoton yhteydessä Häiriöt puhelinkeskusten toiminnassa Häiriöt matkapuhelinten toiminnassa Häiriöt pankkien maksuliikenteen hoidossa Häiriöt pankkiautomaattien toiminnassa Häiriöt autojen toiminnassa 35
Häiriö (failure) = järjestelmä ei käyttäydy käyttäjän tai asiakkaan toivomalla tavalla Jos puutteellisuutta ei löydetä kehitysvaiheessa, ohjelmaan jää vika (fault), joka aiheuttaa joko säännöllisiä tai satunnaisia häiriöitä Ohjelmistosuunnittelija tai ohjelmoija tekee virheen (mistake), joka aiheuttaa puutteellisuuden (defect) ohjelmistosuunnitelmaan tai koodiin
Millä tekniikoilla ohjelmiston laatua parannetaan? Käyttäjän tarpeet Ohjelmisto käytössä Vaatimusmäärittely Yksikkötestaus Käytettävyystestaus Tarkastus eri vaiheissa Toiminnallinen suunnittelu - käyttöliittymän suunnittelu - käyttötapaus-analyysi Koodaus Testisuunnitelmat Järjestelmätestaus Hyväksymistestaus Toiminnallinen testaus Ohjelmistosuunnittelu Integrointitestaus Regressiotestaus
$16.000 $14.000 $14.102 $12.000 $10.000 $8.000 $6.000 $7.136 $4.000 $2.000 $139 $455 $977 Vaatimusm. Suunnittelu Koodaus Testaus Ylläpito Virheiden ja puutteellisuuksien korjauskustannukset (Pressman 2010, Boehm & Basili 2001)
8. Mitkä tekijät aiheuttavat eniten ohjelmistovirheitä? / Galin 2004 Vaatimusmäärittelyjen virheet virheelliset, puutteelliset, ylimääräiset ominaisuudet ongelmat asiakas-kehittäjä kommunikoinnissa Loogiset suunnitteluvirheet virheelliset algoritmit ja prosessin virheet raja-arvovirheet virhetilanteiden puuttuva käsittely Koodausvirheet Testausprosessin puutteet puutteelliset testisuunnitelmat ajanpuute Dokumentointivirheet ei esitellä kaikkea tarpeellista esitellään ylimääräisiä toimintoja virheet käyttöohjeissa 39
9. Mikä on ylläpidon rooli? Muutokset ohjelmistoon ovat väistämättömiä Ohjelmiston elinjakson pituus vaikuttaa ylläpidon osuuteen ohjelmiston kokonaiskustannuksista Ylläpito voi olla neljää eri tyyppiä; ennalta ehkäisevää, korjaavaa, täydellistävää tai mukauttavaa Korjaus Laajennus Proaktiivinen Ennalta ehkäisevä Täydellistävä Reaktiivinen Korjaava Mukauttava 40
Ohjelmiston evoluutio Mitä vanhoille olemassa oleville (legacy) ohjelmille pitäisi tehdä? ei mitään, jos ei aiheuta ongelmia uudelleen rakentamista (re-engineering), jos halutaan ylläpitää (parantaa rakennetta tai lisätä uusia piirteitä) reverse engineering, tuotetaan kuvaus ylemmälle abstraktiotasolle restructuring ja refactoring, tehdään uusi rakenteeltaan parempi ratkaisu (samalla abstraktiotasolla) 41
Esimerkki elinkaarikustannusten jakautumisesta (Schach 1999) vaat.määr. määrittely suun koodaus mod.test integrointi ylläpito Ylläpito (67%) koostuu virheiden korjauksista asiakkaan toiminnan ja ympäristön muuttumisen vaatimista korjauksista uusien piirteiden lisäämisestä 42
10. Miten ohjelmistojen kehitys muuttuu tulevina vuosina? 1. Kuvausmenetelmänä UML ei muutosta 2. Ketterien menetelmien voittokulku jatkuu 3. Pilvipalvelujen (pilvilaskenta, cloud computing) rooli kasvaa Pilvipalvelujen käyttämä verkko voi olla jotain neljästä pilvityypistä: Yksityinen pilvipalvelu, (Private cloud) Yrityksen oma tai vuokrattu palvelu, jolloin resurssit ovat ainoastaan yrityksen omassa käytössä (muodostaa oman suljetun verkon) Yhteisön omaan käyttöön tarkoitettu pilvipalvelu (Community cloud) Resurssit jaettuja ainoastaan määritellyn yhteisön käyttöön. Julkinen pilvipalvelu (Public cloud) Julkinen pilvi, avoin, lähes rajoittamattomat resurssit ja käyttäjät. Infrastruktuuri sijaitsee jaetuilla palvelimilla muiden samaa pilvipalveluntarjoajaa käyttävien asiakkaiden kanssa Yhdistelmä pilvipalvelu (Hybrid cloud) 43
Tunnetuimmat pilvipalvelun palvelutyypit IaaS - Infrastructure as a Service, IT infrastruktuuri, verkko, laitteistot ja sovellukset hankitaan pilvipalveluna PaaS - Platform as a Service alustapalvelu, jonka päälle asiakas voi rakentaa sovelluksia, esimerkiksi Googlen AppEngine, Microsoftin Azure. SaaS - Software as a Service sovellus tai sovelluksia hankitaan pilvipalveluna. 44
Luento 1: lait ja pohdiskeluaiheet 1. Mikä sopii pieniin järjestelmiin ei sovi suuriin / no 11, DeRemer 1975 pienten järjestelmien rakentamisessa saatuja kokemuksia ei voida suoraan venyttää suuriin järjestelmiin One cannot build an ocean cruiser by planning to build 3000 rowing boats (Jones 2000) 2. Ohjelmiston uudelleenkäyttö vähentää kehitysaikaa ja parantaa tuottavuutta ja laatua / no 15, McIlroy 1968 (Naur 1969) uudelleenkäyttö toteutetaan kehysten, suunnittelumallien ja komponenttien keinoin komponenttien uudelleenkäytössä voidaan noudattaa white box tai black box periaatetta 45
Luento 1: lait ja pohdiskeluaiheet 3. Henkilöiden lisääminen myöhässä olevaan projektiin aiheuttaa vain lisää myöhästymistä / no 36, Brooks 1975 laki perustuu OS/360 käyttöjärjestelmäprojektissa saatuihin kokemuksiin lakia voidaan soveltaa suuriin projekteihin, jossa osallistujilta vaaditaan sovellusalueen tietämystä miksi näin on? uusien henkilöiden koulutus projektin töiden jakaminen uudelleen (re-partitioning) vaikuttaa rikkovasti projektiin kommunikointikustannukset kasvavat (n 2 ) 46
Luento 1: lait ja pohdiskeluaiheet Miten ohjelmistojen korjaamisen aiheuttamaa rapistumista" voidaan välttää? Tee yhteenveto Hookerin seitsemästä periaatteesta ja esitä tiivistelmä omin sanoin muutamalla lauseella (katso http://c2.com/cgi/wiki? SevenPrinciplesOfSoftwareDevelopment) Cockburn esittelee oheisessa paperissa yhtäläisyyksiä ohjelmistojen kehittämisen ja perinteisen teollisen tuotannon välillä. Mikä on mielestäsi paperin tärkein sanoma ohjelmistojen kehittäjille? Cockburn A., What engineering has in common with manufactoring and why it matters, Crosstalk, April, 2007, pp. 4-7 http://jounilappalainen.fi/ohjelmistotekniikka 47