Ohjelmistotuotannon käytännöt 6 op

Transkriptio

1 Ohjelmistotuotannon käytännöt 6 op

2 Kurssin tavoitteet ja aiheet Saada kuva ohjelmistotuotantoprosessista kokonaisuutena Hallita ohjelmistotuotannon vaiheet ja erilaiset ohjelmistoprosessit Tuntea ohjelmistotuotannon vaihetuotteiden sisällöt ja osata tuottaa niihin liittyviä dokumentteja Osata käyttää UML-kaavioita eri ohjelmistotuotannon vaiheissa Keskeiset aihealueet Ohjelmistotyö ja sen osa-alueet Ohjelmistoprosessit UML-mallinnus Ohjelmiston elinkaari Ohjelmistojen laatustandardit 1-2

3 Kurssin materiaali Kurssi pohjautuu kirjaan Ilkka Haikala, Tommi Mikkonen: Ohjelmistotuotannon käytännöt, Talentum 2011 (12. painos) Kurssin kalvot perustuvat kirjaan ja osittain Ilkka Haikalan materiaaleihin Lisäksi lähteinä käytetty www:stä löydettyä materiaalia Kurssin kalvoniput on koostanut Erja Nikunen ja Auvo Häkkinen 1-3

4 Kurssikirjan otsikot Ilkka Haikala, Tommi Mikkonen: Ohjelmistotuotannon käytännöt 1. Johdanto 2. Ohjelmistoprojektimallit 3. Vaatimustenkäsittely 4. Määrittelystä ja määrittelynotaatioista 5. Käyttötapaukset 6. Luokkakaaviot 7. Tapahtumasekvenssikaaviot 8. Tila- ja aktiviteettikaaviot 9. Tietovirtakaaviot 10. Käsiteltävän tiedon rakenteen määrittely 11. Laadunhallintajärjestelmä ja prosessit 12. Ohjelmistoprojektin hallinta 13. Tuotteenhallinta 14. Ohjelmistosuunnittelu 15. Tarkastukset ja katselmoinnit 16. Testaus 1-4

5 Kurssi Teoriaa Opettajat käy läpi ohjelmistotuotannon osa-alueita Tuotantoa ja/tai kaavioita käydään läpi tunneilla esimerkin avulla Afrikan tähti -peli tästä kaksi välikoetta Harjoituksia parityönä tehtävä suurempi harjoitustyö (esitutkimus-,) määrittely- tai suunnitteluvaihe Harjoitustyön etenemistä esitellään myös muille opiskelijoille (vertaisarviointia) 1-5

6 Arvostelu Kirjalliset kokeet, 50% Harjoitukset, 50% Erilliset tehtävät raportin sisältö raportin rakenne, jäsentely, selkeys, havainnollisuus raportin vertaisarviointi Hyväksytty suoritus noin 50% pisteistä Molemmista osista noin puolet 1-6

7 OHJELMISTOTEKNIIKKA Ilkka Haikala, Tommi Mikkonen: Ohjelmistotuotannon käytännöt luku 1 1-7

8 Ohjelmistotekniikka Ohjelmistotekniikkaan erikoistuessasi opit tietokoneohjelmien yleiset suunnitteluperiaatteet, joita osaat käyttää laajasti ja luovasti eri sovellusaloilla. Sinulla ei tarvitse olla aikaisempaa koodauskokemusta, mutta looginen päättelykyky ja mielikuvitus ovat hyväksi avuksi. Tietotekniikka-alan yritykset kehittävät ohjelmistoja, tarjoavat tietotekniikan käyttöpalveluja ja konsultointia, tietokantapalveluita sekä sisällön tuotantoa. Muiden alojen yritykset hyödyntävät tietotekniikkaa omassa liiketoiminnassaan parantamaan tuottavuutta ja tuloksellisuutta sekä tuotteiden ja palveluiden laatua. Nykyisin melkein kaikissa tuotteissa on älykkyyttä ohjelmistojen muodossa. Ohjelmistotekniikan insinöörinä voit käyttää taitojasi kehittäessäsi sovelluksia pankeille, terveydenhuoltoon tai peliteollisuuteen yhtä hyvin kuin lukuisille mobiililaitteille tai sulautetun tietotekniikan laitteille. Metropolian web-sivut 1-8

9 Ohjelmistotekniikka Laitoksen ohjelmistotekniikan erikoistumislinjalla tarkastellaan laadukkaiden ohjelmistojen systemaattista tuottamista. "Laadukkuus" ja "systemaattisuus" pitävät sisällään sekä ohjelmistotuotteisiin kohdistuvia teknisempiä aiheita kuten ohjelmointitekniikat ja -kielet, suunnittelu- ja mallinnusmenetelmät sekä ohjelmistotyökalut että ohjelmistotuotantoa tukevia ja valvovia toimenpiteitä kuten prosessit, projektityö, mittaaminen, testaus ja dokumentointi Ohjelmistotekniikan laaja hallitseminen vaatii täten varsin monipuolista osaamista, jota pyritään edistämään erikoistumislinjan opetuksessa ja tutkimuksessa. HY / TKTL:n web-sivut 1-9

10 LAADUKKUUS? 1-10

11 11

12 Tilastoa laadusta - kaaosraportti Standish Group IT executives in US companies in diverse industry segments, 8,380 projects average time overrun = 222%. Project completion 61% of originally specified features included 16% On time, on budget, with all of the specified features and functions 53%? ü Cancelled before they were completed average cost overrun = 189% 31% delivered and operational but overbudget, over-schedule or with fewer features and functions than 1-12

13 Uudempia tutkimuksia

14 1-14

15 Projektin koon mukaan 1-15

16 Miksi epäonnistutaan? (Charette 1989) Lopetettu sopimusongelmien takia Saatettu loppuun, mutta mutta käyttäjät eivät voi tai halua käyttää mutta järjestelmä ei vastaa kustannuksiltaan sovittua mutta ei pysynyt sovitussa aikataulussa mutta järjestelmä ei täytä alunperin sovittuja laatukriteerejä mutta järjestelmä ei täytä alunperin luvattua suorituskykyä mutta järjestelmää ei pysty kehittämään kustannustehokkaasti mutta

17 Surkean kuuluisia esimerkkejä East Texas Cancer Center / USA / 1986 London Ambulance Dispatching System / UK / 1992 European Space Agency: Ariane 5 / Eurooppa / 1996 New air traffic system / UK / 2002 ebay/ USA / 2000, 2009 Fidelity Investments online / Kanada / 2002 EDB Fellesdata AS (pankkeja) / Norja / 2001 Sampo-pankki / Suomi / 2008 Sähköinen äänestys / Suomi / 2008 AMK-pääsykokeet / Suomi / 2003 jne 1-17

18 Therac-25 säteilyhoitokone Aiemmin laitteistolla toteutettuja varmistuksia siirretty ohjelmistolle käytettiin silti aiemman version ohjelmistoa Antoi tietyissä harvinaisissa tilanteissa valtavan yliannostuksen säteilyä potilaalle Huonosti testattu palautetta ei otettu tosissaan eikä siitä pidetty järjestelmällisesti kirjaa järjestelmä huonosti dokumentoitu kun ongelmista raportoitiin, asiaa ei tutkittu tarpeeksi Olemattomat laadunhallintaprosessit luotettiin, että hardis voi särkyä, softa ei Softa on testattu, se toimii, eihän se voi mennä rikki ajan myötä Hinta kolme kuollutta kolme pysyvästi vammautunutta courses.cs.vt.edu/professionalism/therac_25/therac_1.html 1-18

19 Safety - London Ambulance Dispatching System 1992 The full introduction of the computer system effectively did away with the radio and telephone calls to stations, with the computer dispatching crews to answer calls. Within hours, during the morning rush, it became obvious that calls were going missing in the system; ambulances were arriving late or doubling up on calls. emergency callers were also held in a queuing system which failed to put them through for up to 30 minutes. As many as 20 people might have died because of the delays One 14-year-old boy had died of an asthma attach after waiting 45 minutes. The call was dealt with in 28 minutes - although the Patient's Charter has a target of 14 minutes. A man of 83 died before the service reverted to the old system at 2p.m. on Tuesday. Causes: assumed location of ambulances known, memory leak, operators left out /Risks/13.88.html#subj

20 Ariane Ariane 4:stä komponentteja uudelleenkäyttöön Moduuli, joka laski lähdössä korkeutta ja nousukulmaa, ei huomioinut muistivuotoja Muunnos 64-bittisestä 16-bittiseen tuotti ylivuodon Ei huomioitu, että Ariane 5 tehokkaampi ja mitatut arvot suurempia Ko. luvut ei olleet edes maastanousun jälkeen olennaisia, ts. laskennan olisi voinut lopettaa heti, kun raketti ilmassa Muistivuoto aiheutti tietokoneen alasajon Backup-järjestelmä laski saman samaan aikaan samalla tavoin, ja kaatui myös Sukkulaa ei ohjannut enää mikään 10 vuoden kehitystyö ja lasti jouduttiin räjäyttämään 40 s nousun jälkeen Aikansa kallein ohjelmointivirheen aiheuttama vahinko Kehityskustannukset n. 7 M$ Lastia n. 500 M$ edestä (satelliitteja)

21 Over budget / Over schedule 2002 National Air Traffic Services (Nats) is already looking at replacing the systems at its new control centre at Swanwick in Hampshire, even though the system doesn't become operational until next week. Swanwick was originally meant to be operational by 1997, but problems with the development of software by Lockheed Martin caused delays. Now running six years late and 180m over budget, the system will control 200,000 square miles of airspace over England and Wales, looking after two million flights a year. But long-term planners are already looking at replacing the systems. Nats told that it plans to do things very differently next time in a bid to avoid delays. Air traffic control system crashes again

22 Data Integrity - Fidelity Investments online service 2002 Canadian account holders information was accessible 29 May 2002 A design flaw at a Fidelity Investments online service accessible to 300,000 people allowed Canadian account holders to view other customers' account activity. Fidelity said it had fixed the problem and was offering customers the option of changing account numbers

23 Upgrading ebay 2009 ebay apologized to customers for a system upgrade that has led to intermittent outages and frustrating service problems during the past two weeks. In a note to members on its annoucements board, ebay apologized for the problems and blamed them on an upgrade of its database that it began in August. "It may seem like it should take a short time to implement these improvements," ebay said in its note. "But it is quite a task to perform installations and testing while keeping the existing site running. We conduct lots of tests to make sure that these transitions are as seamless as possible. Sometimes they are not. And for that, we are very sorry." ebay representatives did not respond to repeated calls seeking comment. In its note, ebay said it should complete the upgrade in the next "seven to 10 days." 1-23

24 Pohjoismaista yhteistyötä Telia-Soneran www-sivut katosivat verkosta , kun UPS-laitevika kaatoi palvelimen Tietoenatorin konesalissa UPS tarkoitettu turvaamaan virransaanti sähkökatkon sattuessa Norjalainen datayhtiö EDB Fellesdata oli elokuussa 2001 mukana asentamassa lähes 300 kiintolevyn klusteria pankin tietojärjestelmään. Työntekijän piti alustaa uusi järjestelmä, mutta hän tyhjensikin vanhan käytössä olleen levystön Maksuliikenne ja saldotiedot olivat poikki useita päiviä Suuri määrä s-postia tuhoutui n asiakkaalta, ja 1.8 milj. viestin välitys kesti jopa kolme vuorokautta, kun TeliaSoneran postipalvelin hajosi Tukholmassa Palvelin vioittui ennen joulua, mutta se oli saatu toimimaan Kukaan ei seurannut toimintaa, ja se hajosi uudestaan Aiemmin valvoneen henkilön työsuhde päättyi joulukuussa, eikä tilalle oltu nimitetty uutta valvojaa Myös varmuuskopiot olivat pilalla 15. joulukuuta lähtien 1-24

25 Mikä tekee ohjelmistoista niin erikoisia? verrattuna muihin insinööritieteisiin Ohjelmisto aineetonta "sitä ei voi potkaista" sen hahmottaminen vaikeaa sen laatua ja valmiusastetta vaikea arvioida Virheitä voi syntyä helposti, ja niitä löytyy vielä pitkänkin käytön jälkeen Asiakasvaatimuksia vaikea määritellä täydellisesti vaikea ymmärtää asiakkaan vaatimuksia yksikäsitteisesti vaatimusten muuttuessa täytyy välittää suuria tietomääriä ja kommunikoida useiden ryhmien kesken Ohjelmiston muuttaminen näennäisesti liiankin helppoa Ohjelmistoa lähes mahdoton testata perusteellisesti ja kattavasti 1-25

26 Ohjelmistotyyppejä Pakettiohjelmisto / valmisohjelmisto muodostavat yhden kokonaisuuden ei ole suunniteltu tai valmistettu asiakaskohtaisesti markkinointi ja toimitus samanlaisina jopa miljoonille käyttäjille esim. taulukkolaskenta-, tekstinkäsittely- ja virustentorjunta Asiakaskohtaiset ohjelmistot räätälöidään asiakkaan tarpeiden mukaan yleensä tiiviistä yhteistyötä asiakkaan kanssa Sulautetut ohjelmistot tehdään osaksi muuta kuin varsinaista atk-tuotetta esim. matkapuhelimien ja autojen sisältämät ohjelmistot Toimialaraportti, 17/2005, Marko Ylikorpi (toim.) KTM:n ja TE-keskusten julkaisu 1-26

27 Sulautetut järjestelmät NMT-puhelin 20 kloc (Lines Of Code) GSM-keskus 15MLOC GSM-puhelin 500 kloc kommunikaattori 1,5 MLOC 3G matkapuhelin koodimäärä kolminkertaistuu 2Gpuhelimeen verrattuna televisio 200 kloc hissi 50 kloc moderni auto 50 kloc avaruussukkula 21 MLOC (sukkulassa 0,5MLOC) 1-27

28 Mikä ei ole muuttunut? Laatu edelleen ongelmallista jopa enemmän kuin ennen Ohjelmistojen tekeminen edelleen käsityötä edelleen erittäin henkilökohtaista tekemistä tuottavuus vaihtelee suuresti eri ihmisten välillä Vain pieni osa projekteista menestyksellisiä viidestä projektista yksi ei tuota koskaan mitään hyödyllistä loput kärsivät aikataulu- ja budjettiongelmista Epäonnistumisten syyt harvemmin teknisiä useimmiten ongelmat löytyvät huonosta hallinnosta huonosta projektiosaamisesta / -johtamisesta huonosta prosessiosaamisesta yms. 1-28

29 Ratkaisu? Suurempi paino systemaattiseen kehittämiseen Formaalit tai puoliformaalit määritykset järjestelmän vaatimuksista Tietokoneavusteiset kehitysvälineet (CASE) Keskittyminen asiakasvaatimusten selvittämiseen Varhaisten versioiden demonstrointi (prototyypit) Suurempi paino virheettömän koodin tuottamiseen ohjelmistotuotanto 1-29

30 Ohjelmistotuotanto - Software Engineering Määritelmiä Designing, building and maintaining large software systems Software engineering is concerned with the theories, methods and tools for developing, managing and evolving software products. I. Sommerville The practical application of scientific knowledge in the design and construction of computer programs and the associated documentation required to develop, operate and maintain them. B.W.Boehm The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. F.L.Bauer 1-30

31 Software Engineering - ohjelmistotuotanto Lisää määritelmiä vrt. The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. IEEE Standard The technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost constraints. R. Fairley Electrical Engineering, Mechanical Engineering, Civil Engineering, Aerospace Engineering, Chemical Engineering 1-31

32 1-32

33 Ohjelmistotuotannon osa-alueet (oppikirjan mukaan) Liiketoiminta, johtaminen Laatujärjestelmä Hankkeiden hallinta (tuotteen tasolla) Projektinhallinta Projektinhallinta Projektinhallinta ohjelmointi suunnittelu testaus määrittely käyttöönotto, ylläpito tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta... Kirjan kuva 2.1 otupk/ilkka Haikala 1-33

34 Millainen projekti - millainen prosessi More formal, more controlled, more bureaucratic Configuration management Project management Methods Documentation Requirements specification Quality control, inspections SW design Programming language, tools, and technical skills Requirements management Measurement Testing procedures, planning Small programs Large systems Sometimes, for some people, it seems to be more important 34 to get the process done than to get the product done. 1-34