30.11.2015 JOTU-2015 / K.Systä 1 Kertausluento 30.11.2015
Harjoitustyöstä https://mooc.tut.fi/courses/12/pages/harjoitustyon-neljas-ja-lopullinen-palautus Asiakasrooli: Palaute määrittelydokumentista Viimeistään pe 11.12. klo 16 Kirjoitetaan asiakkaan näkökulmasta. Asiakasryhmä tarkastaa ja arvioi: Vastaako määrittely vaatimuksia ja muuta sovittua (sähköposti, palaverit), eli onko toimittaja kuunnellut asiakasta. Onko helppolukuinen? Onko viittaukset kunnossa? Ymmärtääkö kaavioita? Tajuaako asiakas, mistä on kyse? Onko vaatimukset helppo jäljittää? 30.11.2015 JOTU-2015 / K.Systä 2
Toimittajarooli Yleiset vaatimukset: Määrittelyn tulee kattaa kaikki dokumenttipohjan kohdat. Määrittelyn tulee vastata asiakasvaatimuksia. UML-kaaviot (vähintään 2 kpl): käyttötapauskaavio, tärkeimmät käyttötapaukset ja käyttäjäroolit. luokkakaavio ohjelmiston tietosisällöstä. Erittäin suositeltavaa on tehdä navigaatiokartta järjestelmästä, esim. UML:n tilakone. Johdanto tarkoitus ja kattavuus tuote ja ympäristö määritelmät, termit ja lyhenteet Yleiskuvaus ympäristö toiminta käyttäjät Käyttöliittymä Toiminnot(mieti myös virhetilanteita) toiminnalliset ominaisuudet ei-toiminnalliset ominaisuudet reunaehdot ja rajoitteet Laatutavoitteet Jatkokehitysajatukset Lähteet Vielä avoimet asiat 30.11.2015 JOTU-2015 / K.Systä 3
Mitä vaaditaan tentissä Kurssin tavoite on kattaa alueet jotka sidosryhmien kuten asiakkaat, myynti, muiden alueiden insinöörit on hyvä tietää Kirja Ohjelmistotuotannon käytännöt, on hyvää lukemistoa mutta kirjan kaikki osat ei kuulu tenttialueeseen Kts myöhemmin tuleva kalvo Luennot, kalvot ovat verkossa mutta eivät sisällä kaikkea Luennolla kuullun muistaminen, tai googlettaminen auttaa 30.11.2015 JOTU-2015 / K.Systä 4
Tenttikysymyksistä (ja vastauksista) Arvostan lyhyitä, ytimekkäitä ja täsmällisiä vastauksia Arvostan sitä, että vastaus osoittaa asian ymmärtämisen Haulikko -vastaus (kerrotaan kaikki mitä aihepiiristä tiedetään siinä toivossa että oikeakin vastaus tulee katettua) ei tuota paljoa pisteitä Vastauksen seassa olevista vääristä väitteistä vähennetään pisteitä. Selvästi liian pitkästä vastauksesta vähennetään pisteitä Tentissä tyypillisesti Yksi monivalintakysymys Lyhyitä tekstivastauksia Kaavion piirtoa tai ymmärtämistä Arvosanan painotus: viikkoharjoituksista (6 pistettä) harjoitustyöstä (6 pistettä) tentistä (3*18 pistettä) Huonoin 6 pistettä pois arvostelusta 30.11.2015 JOTU-2015 / K.Systä 5
30.11.2015 JOTU-2015 / K.Systä 6 Mikä osa kirjasta kannattaa lukea Alku 1 2.8.2 on syytä lukea Mutta sellaiset yksityiskohdat jotka ovat merkitseviä vain toteutusporukalle eivät kuulu tenttialueeseen 2.8.3, 2.9, 2.10 eivät kuulu tälle kurssille 3 on keskeistä sisältöä 4-4.3 kuuluu, mutta 4.4 ei (UML:n teoria ei kuulu tälle kurssille ollaan enemmän klubiaskin kansi linjalla) 5 kuuluu 6 sillä tasolla kuin luennoilla käsiteltiin
30.11.2015 JOTU-2015 / K.Systä 7 Mikä osa kirjasta kannattaa lukea 7,8,9 ei kuulu 10 sillä tasolla kuin luennoilla käsiteltiin Lähinnä käsitekaavion perusteet (Viitosen tavoittelijat opettelevat myös lukumääräsuhteet) 11-11.2 kuuluu; 11.3-11.6 ei 12 kuuluu 13 ja 14 ei kuulu 15 kuuluu 16 kuuluu mutta ei mennä yksityiskohtiin
Vierailuluentokin oli havainnut kurssin ytimen 30.11.2015 JOTU-2015 / K.Systä 8
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit, prosessit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon/käsitteiden mallintamisesta (kirjan luku 10) Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Asiakasrooleista Ohjelmistolisensseistä 30.11.2015 JOTU-2015 / K.Systä 9
Mitä on ohjelmistotuotanto? Vaatimusmäärittelyä Taitavaa ohjelmointia Elinkaarimallit Yhteispeliä, yhteistä peliä Algoritmit Tietorakenteet Ohjelmointikielet Arkkitehtuurit Laadunvarmistusta Testaus Validointi Projektinhallinta 10 30.11.2015 JOTU-2015 / K.Systä
Miksi ohjelmien tekeminen on niin vaikeaa? Ohjelmisto on abstrakti Tekijöiden ja asiakkaiden välillä ei välttämättä ole sama käsitys Työmäärän arviointi on vaikeaa Ohjelmisto on dynaaminen On muutettavissa muutettavuutta oletetaan Ohjelmistojen tekemistä on vaikea skaalata Tekijöiden määrän lisääminen nopeuttaa vain vähän valmistumista Mitä enemmän tekijöitä, sen enemmän kommunikointitarvetta. 30.11.2015 11 JOTU-2015 / K.Systä
Ohjelmistotuotanto = Ohjelmointia Laadunvarmistusta Dokumentointia Käyttöönottoa Määrittelyä Projektinhallintaa Myyntiä Määrittely = Ohjelman ominaisuuksien keksimistä/löytämistä ja niistä päättämistä 30.11.2015 JOTU-2015 / K.Systä 12
Ohjelmistotyyppejä(1) Varus- ja työkaluohjelmistot teknis-tieteelliseen laskentaan tarkoitetut ohjelmistot tietämyspohjaiset järjestelmät kaupallishallinnolliset ohjelmistot (yrityksen tietojärjestelmät) prosessinohjaus- ja prosessiautomaatiojärjestelmät 13 30.11.2015 JOTU-2015 / K.Systä
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 autossa Reaktiiviset järjestelmät toimivat jatkuvasti Puhelinkeskus Hissin ohjauslogiikka Melkein kaikki laitteet tänä päivänä? 14 30.11.2015 JOTU-2015 / K.Systä
Miksi menee pieleen; tilaajanäkökulma Aikataulun pettäminen Budjetin pettäminen Eri näkemys projektin Laadun pettäminen Henkilövaihdokset Kommunikaation puute Sopimuksesta Hinnoittelumallista Ongelmat Ei kriisejä Yritysjärjestelyt 0 5 10 15 20 25 30 35 40 45 50 Lähde: tietotekniikan liiton, ohjelmistoyrittäjien ja Celkee OY:n tutkimus JOTU-2015 / K.Systä 30.11.2015 15
Miksi menee pieneen; toimittajanäkökulma Kommunikaation puute Eri näkemys projektin sisällöstä Aikataulun pettäminen Henkilövaihdokset projektissa Laadun pettäminen Budjetin pettäminen Ei kriisejä Ongelmat henkilökemioissa Hinnoittelumallista johtuvat syyt Sopimuksesta aiheutuvat syyt Yritysjärjestelyt 0 5 10 15 20 25 Lähde: tietotekniikan liiton, ohjelmistoyrittäjien ja Celkee OY:n tutkimus JOTU-2015 / K.Systä 30.11.2015 16
Tämä kulunut kuva on pakko näyttää 17 30.11.2015 JOTU-2015 / K.Systä
Ohjelmistotuotanto on täynnä rajapintoja Teknisiä API Jakamaan komponentteihin, eri toimittajille, Käyttäjälle Ymmärtääkö käyttäjä? Osaako käyttää Asiakkaalle Oikea tarve Oikeat ominaisuudet Oikeaan aikaan Oikealla hinnalla Tämän kurssin viestit - Asiakkaan ja toimittajan Yhteistyö tärkeää 30.11.2015 JOTU-2015 / K.Systä 18
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit, prosessit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon/käsitteiden mallintamisesta (kirjan luku 10) Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Asiakasrooleista Ohjelmistolisensseistä 30.11.2015 JOTU-2015 / K.Systä 19
Ohjelmistoprojekti on muutokseen reagoimista 20 30.11.2015 JOTU-2015 / K.Systä
Ohjelmiston rakentaminen projektina Asiakas - toimittaja Tarvitaan yhteisymmärrys siitä mitä halutaan Mitä se maksaa Koska se on valmis Asiakas ymmärrettävä laajasti Sisäinen Varsinaisen asiakkaan edustaja (esim. markkinointi) Tämä kurssi on suunniteltu (myös) tuleville asiakkaille Asiakkaalle projekti on usein osa isompaa kokonaisuutta (hanketta) Ohjelmiston lisäksi laite, liiketoimintamuutos, Elinkaari: esiselvitys, määrittely, toteutus, käyttöönotto, ylläpito, käytöstä poisto 21 30.11.2015 JOTU-2015 / K.Systä
Kehitysprosessit: erilaisia variaatioita samasta teemasta Testaus, laadunvarmistus Asiakkaan ongelma asiakasvaatimukset Määrittely Suunnittelu ohjelmistovaatimukset, määrittely tekniset vaatimukset, suunnittelu Toteutus asiakastoimitus Seuraava versio Hyväksymistestaus JOTU-2015 / K.Systä 30.11.2015 22
Vesiputous Managing the development of Large Software Systems [Royce 1970] Järjestelmävaatimukset Ohjelmistovaatimukset Ohjelmistonmäärittely Ohjelmistonsuunnittelu Ohjelmointi Testaus Käyttö 30.11.2015 JOTU-2015 / K.Systä 23
Protoilu Usein tarpeen jotta voidaan Testata uutta käyttöliittymäideaa Kokeilla uutta teknologiaa Varmistaa suorituskyky Pois heitettävä (throw-away) proto Ei ole tarkoitus käyttää tuotteessa Evoluutioproto Osaa käytetään Huomion arvoista Usein on tulee paine viedä tuotteeseen Mikä on oleellista Sukulainen demoilulle 30.11.2015 JOTU-2015 / K.Systä 24
Iteratiivinen - taustaa Oppimisen tehokas hyödyntäminen Pitkässä projektissa kestää kauan määrittelystä toteutukseen Riskien hallinnan monimutkaisuus & ennalta-arvaamattomuus Vaatimusten tarkentuminen ja myöhäinen asiakaspalaute Testauksen myöhäinen aloittaminen Itsepetos Kärsimättömät asiakkaat 30.11.2015 JOTU-2015 / K.Systä 25
Ketterät http://www.agilealliance.com/home Vain oleellinen on tärkeää Asiakas- ja tuotekeskeisyys Kehittäminen tapahtuu asiakkaan kanssa yhteistyössä Valmius jatkuvaan muutokseen Iteratiivisuus Dokumentaation sijaan korostetaan henkilökohtaista kommunikaatiota kykyä demonstroida valmiita ominaisuuksia kykyä muuttaa toteutettua järjestelmää palautteen perusteella Osaamisen, ammattitaidon ja vastuuntunnon korostaminen 30.11.2015 JOTU-2015 / K.Systä 26
Ketterä manifesti Löydämme parempia tapoja tehdä ohjelmistokehitystä, kun teemme sitä itse ja autamme muita siinä. Kokemuksemme perusteella arvostamme: Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa Jälkimmäisilläkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja enemmän. 30.11.2015 JOTU-2015 / K.Systä 27
työmäärä Esimerkki: SCRUM Sprintissä toteutettavat tehtävät, aika-arviot päivitetään päivittäin Daily Scrum Meeting: 15 min: Edistys edellisestä palaverista? Ovatko aika-arviosi kunnossa? Mitä teet seuraavaksi? Onko ongelmia näkyvissä? Sprint burndown chart: aika Sprint planning meeting: 4+4 tuntia: tuotteen omistaja esittelee Product backlogia Tiimi päättää, mihin voi sitoutua 30 päivän pyrähdys (sprint) tuotteen inkrementti Sprint Review Meeting (4 tuntia): Tiimi esittelee tuloksen omistajalle The Sprint Retrospective (3 tuntia): miten asiat saataisiin sujumaan paremmin seuraavassa pyrähdyksessä Requirements 30.11.2015 JOTU-2015 / K.Systä 28
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon/käsitteiden mallintamisesta (kirjan luku 10) Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Asiakasrooleista Ohjelmistolisensseistä 30.11.2015 JOTU-2015 / K.Systä 29
Asiakasvaatimuksista tuotteeseen asiakasvaatimukset Määrittely Suunnittelu& toteutus ohjelmistovaatimukset 30.11.2015 JOTU-2015 / K.Systä 30
Erilaisia vaatimuksia - esimerkki Asiakasvaatimus tyypillisesti asiakkaan ongelma, jolle toivotaan ratkaisua: tuotetaan mahdollisimman virheettömiä dokumentteja. Ominaisuus, feature jokin asiakkaan kannalta mielekäs kokonaisuus ohjelmiston toiminnallisuudesta: tuki oikeinkirjoituksen tarkastamiselle. Ohjelman toiminto yksittäinen ohjelmistolla tehtävä asia: tarkasta oikeinkirjoitus, ehdota korjausta, korjaa automaattisesti... Tekniset vaatimukset miten ohjelmisto toteutetaan: tiedostopuskuri, dialogin toteutus,... Kannattaa huomata, että luokittelu ei ole mitenkään itsestään selvä. Asiakasvaatimukset Ohjelmistovaatimukset 30.11.2015 JOTU-2015 / K.Systä 31
Vaatimukset vs. rajoitteet Toiminnallinen vaatimus (functional requirement), esimerkiksi ohjelmassa on tuki oikeinkirjoituksen tarkastamiselle. Ei-toiminnallinen vaatimus (non-functional requirement), esimerkiksi ohjelman käyttöliittymä on UI-tyyliopas mukainen tai ohjelmiston asennus saa käyttää korkeintaan 5MB levytilaa. Reunaehdot (constraints), esimerkiksi ohjelmisto on toteutettava Windows-ympäristöön C++-kielellä. 30.11.2015 JOTU-2015 / K.Systä 32
Hyvän speksin/vaatimuksen ominaisuuksia täydellisyys: kaikki tarpeellinen, ei mitään turhaa tarkkuus virheettömyys ymmärrettävyys testattavuus: miten voidaan "mitata", onko vaatimus täytetty jäljitettävyys: mistä vaatimus on peräisin, miten tärkeä se on sama asia vain yhdessä paikassa (ei redundanssia) (?) 30.11.2015 JOTU-2015 / K.Systä 33
Esimerkkejä Järjestelmän käytettävissä on 64k-tavun muisti. Luokalla voi siis olla vain yksi luokanvalvoja? Jos kuukauden toteutunut myynti alittaa tavoitteet, tulostetaan raportti, ellei toteutuneen myynnin ja tavoitteen ero ole vähemmän kuin puolet edellisen kuukauden tavoitteen ja toteutuneen myynnin erosta, tai toteutunut myynti alittaa tavoitteen alle 5%. Varaston kiertonopeus kasvaa. Ilmoituksen on oltava kuvaruudulla 300ms kuluessa hälytyksen tapahtumisesta. Suihkumoottoreita ei saa kytkeä pakille ellei kone ole kentällä. Suihkumoottoreita ei saa kytkeä pakille ellei nokkapyörä pyöri tai nopeus ole nolla. 30.11.2015 JOTU-2015 / K.Systä 34
30.11.2015 JOTU-2015 / K.Systä 35 Käyttötapauskaavio, versio 1 Dipparekisteri Lisää uusi opiskelija Lisää uusi kenttä Ohjaaja Etsi ehdot täyttävät opiskelijat tee palaverimuisti o kirjoita lausunto Pohja järjestelmän hahmottamiselle ja siitä keskustelemiselle
30.11.2015 JOTU-2015 / K.Systä 36 Käyttötapauskaavio, versio 2 Dipparekisteri Lisää uusi opiskelija Lisää uusi kenttä Ohjaaja Etsi ehdot täyttävät opiskelijat Ydin on yksinkertainen - Kuka tarvitsee ja mitä tee palaverimuisti o lisää/poista ohjaaja kirjoita lausunto Laitoksen johtaja tarkastele tilastoja
Käyttötapaus vs. käyttäjätarina Käyttötapaus Nimi Osallistujat Tuloehdot Kuvaus Poikkeukset Lopputulos Muut vaatimukset Käyttäjätarina Muutamaan lauseeseen typistetty "käyttötapaus" Tarinasta selviää: - rooli (aktori) - mitä tehdään - yleensä mitä lisäarvoa tekeminen tuottaa käyttäjälle Käytössä ketterissä 30.11.2015 JOTU-2015 / K.Systä 37
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon/käsitteiden mallintamisesta (kirjan luku 10) Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Asiakasrooleista Ohjelmistolisensseistä 30.11.2015 JOTU-2015 / K.Systä 38
Käsitteellinen mallintaminen (lainaus kurssin tietokantojen suunnittelu luentomateriaalista) Kuvataan maailmaa (kohdealue) siellä olevien käsitteiden, niiden ominaisuuksien ja suhteiden avulla. Näiden tilat voivat muuttua ajoittain tapahtumien vaikutuksesta. Ollaan kiinnostuneita maailman tilasta menneisyydessä, nyt ja tulevaisuudessa. Käsitteellinen malli = kohdealueen vääristymätön ja täydellinen esitys (, jossa mahdolliset toteutusnäkökohdat jätetään huomioimatta.) 30.11.2015 JOTU-2015 / K.Systä 39
Esitetään useimmiten graafisesti Oliokaavio Luokkakaavio (UML) ER-kaavio (entity-relationship kaavio) Tietoyhteyskaavio Käsitekaavio Kohdekaavio 30.11.2015 JOTU-2015 / K.Systä 40
Käsitekaavio (UML:n luokkakaavio) Nimi Ominaisuudet lkm lkm nimi Nimi Ominaisuudet Metodit Metodit 30.11.2015 JOTU-2015 / K.Systä 41
42 0-* Oppimistapahtu ma Luento 1 Viikkoharjoit us Opintokokonaisuus 1..* 1-* Opintojakso 0-* 1-* 1-* 0-* Esitieto -> 0-* Luennoija 0-* Yhteinen käsite Assistentti opettaja? Harjoitustyö 30.11.2015 JOTU-2015 / K.Systä
Jatketaan viime kerran esimerkkiä (Sama PDF:ää varten) Opiskelija Osallistuu 0-* Oppimistapahtu ma Ilmoittautuu Luento 1 1-* Toteutusker ta 1-* 0-* Luennoija Opintokokonaisuus 1-* 1..* Opintojakso 0-* 0-* Esitieto -> Viikkoharjoit us Harjoitustyö 0-* Assistentti 30.11.2015 JOTU-2015 / K.Systä 43
Esimerkki 30.11.2015 JOTU-2015 / K.Systä 44
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon/käsitteiden mallintamisesta (kirjan luku 10) Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Asiakasrooleista Ohjelmistolisensseistä 30.11.2015 JOTU-2015 / K.Systä 45
Käytettävyydestä Käytettävyydestä voi maksaa joko paljon tai vähän. Jos haluaa maksaa paljon kuten VR kannattaa julkaista keskeneräisiä tuotteita, joita pitää korjata kiireellä ja jotka saavat asiakkaat valitsemaan muita vaihtoehtoja. Jos haluaa sijoittaa vähemmän ja tuottavammin, se pitää tehdä heti projektin alussa ja hiukan lisää arviointivaiheessa. Aapo Puskala VR:n käytettävyysarviossaan 30.11.2015 JOTU-2015 / K.Systä 46
Sidosryhmät 30.11.2015 JOTU-2015 / K.Systä 47
Käytettävyys ja käyttökokemus Käytettävyys (usability) Kuinka määritellyt käyttäjät voivat käyttää järjestelmää saavuttaakseen määritellyt tavoitteet tehokkaasti, tarkoituksenmukaisesti ja tyytyväisinä määritellyssä käyttökontekstissa (ISO 9241-210) Määritelmän mukaan mitataan siis speksejä vastaan Käyttäjäkokemus (user experience) Henkilön käsitys järjestelmän käytön tai odotetun käytön tarjoamasta arvosta tietyssä käyttökontekstissa. (Hassenzahl ja Tractinsky 2006 sekä ISO 9241-210 2010) 30.11.2015 JOTU-2015 / K.Systä 48
Käyttäjä (user) Henkilö, joka on järjestelmän kanssa vuorovaikutuksessa (ISO 9241-11:1998) Käyttäjäryhmät Segmentointi: kohdekäyttäjäryhmät ensisijaiset ja toissijaiset loppukäyttäjä, kehittäjä, huolto, tuki, jne. Kuluttajakäyttäjät ja työkäyttäjät 30.11.2015 JOTU-2015 / K.Systä 49
Käyttäjän rooli vaihtelee Yritysjärjestelmät & työkalut Asiointisovellukset Viihdeohjelmistot Jne. Jne. 30.11.2015 JOTU-2015 / K.Systä 50
Käyttäjät ovat hyvin erilaisia Ikä Sukupuoli Kulttuuri Fyysiset ominaisuudet Psykologiset ominaisuudet Kognitiiviset (mieleen liittyvät) Motivaatio, asenne Luonne, temperamentti 30.11.2015 JOTU-2015 / K.Systä 51
Käyttäjän ominaisuuksia suhteessa tuotteeseen 30.11.2015 JOTU-2015 / K.Systä 52
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon/käsitteiden mallintamisesta (kirjan luku 10) Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Asiakasrooleista Ohjelmistolisensseistä 30.11.2015 JOTU-2015 / K.Systä 53
Laatu ja laatujärjestelmä Termi laatu on omiaan herättämään tunneperäisiä reaktioita. Onko laatu virheettömyyttä, mitä on virheettömyys? Onko laadukkaiden osien summa laadukas? "Määritelmä" Tuotteen kyky täyttää asiakkaan kohtuulliset toiveet ja odotukset. Oikea tuote, oikea hinta, oikeaan aikaan. Laatu on välttämättä aina jossain määrin subjektiivista, so. riippuvainen käyttäjästä Objektiivinen laatu: tuote on siinä mielessä virheetön ja tarkoituksenmukainen, että se on määrittelynsä mukainen. Subjektiivinen laatu: tuote täyttää käyttäjänsä (ja asiakkaan) tuotteeseen kohdistamat odotukset. Eri käyttäjillä on erilaisia odotuksia. Laatujärjestelmä eli laadunhallintajärjestelmä määrittelee yrityksen toimintatavat. 30.11.2015 JOTU-2015 / K.Systä 54
Testaus, laadunvarmistus Kehitysprosessit: erilaisia variaatioita samasta teemasta Asiakkaan ongelma Tarkastus, katselmointi asiakasvaatimukset Määrittely Suunnittelu ohjelmistovaatimukset, määrittely tekniset vaatimukset, suunnittelu Toteutus asiakastoimitus Seuraava versio Hyväksymistestaus Testaus JOTU-2015 / K.Systä 30.11.2015 55
Tekniikoita Testaus: ohjelmaa tai se osaa ajetaan etukäteen määritellyillä testitapauksilla ja tarkastellaan toimiiko ohjelma halutulla tavalla Lisää tietoa: http://www.cs.tut.fi/~testaus/s2015/luennot/tie-21204_2015.pdf Tarkastukset (inspection) ovat projektin sisäisiä tapahtumia, joiden päätavoite on laadunvarmistus mutta joihin usein liittyy myös muita tavoitteita, kuten esimerkiksi kommunikointi ja koulutus. Läpikäynti (walkthrough) on epämuodollinen tarkastuksen muoto, joka yleensä tehdään vain ohjelmakoodille. Läpikäynnissä tekijä selittää, mitä hän "luulee ohjelmansa tekevän". Katselmointi (review, technical review) on projektin etappiin sidottu tapahtuma, jonka tarkoituksena on todeta tietyn vaiheen päättyminen. Arviointi (assessment) on jollekin artefaktille tai prosessille suoritettu toimenpide, jossa sitä ja sen ominaisuuksia arvioidaan. Kolme viimeistä voidaan kohdistaa sekä koodiin että dokumenttin 30.11.2015 JOTU-2015 / K.Systä 56
Testauksen käsitteet pikaisesti Moduulitestaus: ohjelmiston yksittäistä osaa testataan erikseen Esimerkiksi tietokanta Regressiotestaus: ajetaan vanhat testit uudelleen Yleensä kun on toteutettu uusi ominaisuus testataan ettei vanhat ominaisuudet ole menneet rikki Integraatiotesti: testataan että järjestelmän komponentit toimivat yhdessä Järjestelmätesti: testataan kokonaista järjestelmää Hyväksymistesti: testataan asiakkaan kannalta suostuuko asiakas ottamaan vastaan 30.11.2015 JOTU-2015 / K.Systä 57
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Asiakasrooleista Käytettävyyden merkityksestä Tiedon mallintamisesta (kirjan luku 10) Laadunvarmistuksesta Projektitoiminnasta Ohjelmistolisensseistä 30.11.2015 JOTU-2015 / K.Systä 58
Projektin hallinta vai sallinta Tehokkuus Optimi riippuu tilanteesta - projektista - asiakkaasta - kehittäjäporukasta Luova kaaos Byrokratia-kaaos Alhainen motivaatio Sekamelska Kontrollin ja valvonnan määrä 30.11.2015 JOTU-2015 / K.Systä 59
Projekti Projektiin liittyy lähtötilanne, syy käynnistämiselle ja tavoitetila Yksi määritelmä: Projekti on kertaluontoinen, toisiinsa liittyvien tehtävien ja aktiviteettien muodostama kokonaisuus, jolla on suunnitelmallinen toteutus (=tavoitteet, aikataulu, resurssit, kustannukset). Projektiin liittyy organisaatio, joka yleensä poikkeaa linjaorganisaatiosta johto osallistujat sidosryhmät... Ovatko projekteja? Johdatus ohjelmistotuotannon -kurssi syys 2013 DI-tutkinnon suorittaminen Komponenttivaraston kiertonopeuden kasvattaminen 30.11.2015 JOTU-2015 / K.Systä 60
Vesiputous vs. ketterä Tarkat suunnitelmat Tarkka valvonta Kurinalainen toiminta Tarkat suunnitelmat vain seuraavasta askeleesta Yhteinen visio ja asiakaspalaute Tiimityö, yhteisvastuu Sopimus rahasta, resursseista ja tuloksista Kommunikaation väline projektin sisällä ja ulkopuolelle Johtamisen väline 30.11.2015 JOTU-2015 / K.Systä 61
Kiva löytö: (Ken Schwaber: Agile project managemet) Far from agreement Anarchy Complicated Complex Close to agreement Simple Complicated Close to certainty Far from certainty 30.11.2015 JOTU-2015 / K.Systä 62
Usein vielä vaikeampaa Kompromissikolmio (Iron triangle) Ominaisuudet Aika Hinta 30.11.2015 JOTU-2015 / K.Systä 63
Kustannukset Mahdoton alue Projektisuunnittelun haaste Mahdoton alue Kalenteriaika 30.11.2015 JOTU-2015 / K.Systä 64
Projektisuunnitelma: MIKSI? Projektin ohjauksen ja seurannan apuväline, joka samalla toimii "sopimuksena" ja tiedonvälittäjänä eri sidosryhmien kesken. Tavoitteet Tehtävät ja aikataulu Organisointi ja vastuut Toimintatavat, työvälineet Raha Riskit 30.11.2015 JOTU-2015 / K.Systä 65
Projektin suunnittelu Organisointi; osallistujien työpanoksen kartoittaminen sekä aikataulutus tavoitteiden tarkentaminen riskien analysointi, millä edellytyksillä projekti voi toteutua. teknologioiden ja työmenetelmien valinta tukitoimintojen suunnittelu vaiheistaminen ja osittaminen (WBS) työmäärien arviointi projektibudjetti, kassavirtalaskelma 30.11.2015 JOTU-2015 / K.Systä 66
Projektin suunnittelu Hyvin suunniteltu on puoliksi tehty Jokainen tietää omat vastuunsa projektissa Jokainen tuntee projektin tavoitteet Tiedetään, kuinka projektia seurataan ja etenemisestä raportoidaan Pystytään vertaamaan edistymistä suunnitelmiin ja sitä kautta arvioimaan projektin lopetusajankohta ja lopullinen hinta Selkeät päätökset ja päättämisen paikat 30.11.2015 JOTU-2015 / K.Systä 67
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Käytettävyyden merkityksestä Tiedon mallintamisesta (kirjan luku 10) Lisenssit, IPR, avoimet rajapinnat Projektitoiminnasta Asiakasrooleista Ohjelmistolisensseistä 30.11.2015 JOTU-2015 / K.Systä 68
Tietojärjestelmän rakentaminen Liiketoimintastrategia Strategiset tavoitteet Mittaus ja analysointi Järjestelmävaatimukset Tietojärjestelmätoimitus Käyttöönotto ja hyväksyminen Ylläpito Mukailtu lähteestä: Timo Koivisto: Tietojärjestelmätoimituksen jälkiseuranta, Systeemityö 3/2006 30.11.2015 JOTU-2015 / K.Systä 69
Toimittaja tutkimus tarjous tarjouspyyntö tarjous määrittely määrittely toteutus testaus käyttöönotto käyttöönotto Kunnon määrittely ensin + On selkeä sopimus +Tiedetään etukäteen mitä saadaan + Kun on etukäteen mietitty ei matkan varrella tehdä turhaa + Riitatilanteissa tuomareilla on helppoa - Muutosten tekeminen vaikeaa - Voiko määrittelyä tehdä kunnolla? Asiakas Toimittaja Tehdään yhdessä iteratiivisesti + voidaan yhdessä oppia * vaatii molemminpuolista sitoutumista ja luottamusta tutkimus tarjous määr. tot test demo tot test demo tot test demo tot test käyt.otto määr. demo demo demo käyt.otto Demo tarkoittaa yhdessä käyttäjän tarjouspyyntö kanssa tehtävää uudelleen pohdintaa. 30.11.2015 Asiakas JOTU-2015 / K.Systä 70 tarjous
Käyttöönotto Vaikea ja tärkeä osa, mutta oppaita ja materiaalia löytyy aika vähän Rajattu oppikirjankin ulkopuolelle Ohjelmiston käyttöönotto = uuden tietojärjestelmän toteutus 30.11.2015 JOTU-2015 / K.Systä 71
Toiminnanohjausjärjestelmän käyttöönotto pkyrityksissä VTT-julkaisu 854 Julkaisun keskeinen johtopäätös on, että tietojärjestelmän käyttöönotto on luonteeltaan organisatorinen oppimisprosessi, jota tulee systemaattisesti tukea ja vahvistaa kokemukset ja tutkimukset viittaavat siihen, että liiketoimintaprosessien uudistamiseen liittyvät laajat tietotekniikkahankkeet epäonnistuvat usein. Kansainvälisesti arvioiden vain noin kolmannes hankkeista onnistuu. 30.11.2015 JOTU-2015 / K.Systä 72
Käyttöönottoon kuuluu Vanhan tiedon siirtämistä uuteen Voi mennä pieleen Järjestelmän ja organisaation yhteensovittamista Usein molempiin muutoksia Oppimista ja omaksumista Ei riitä että osaa käyttää uutta järjestelmää, on myös osattava liittää se omaan työhön tehokkaasti Onko kiire vai tehdäänkö tietokoneella Ongelmien ja häiriöiden ratkomista Eli siis testausta ja korjaamista Käyttäjätuen organisoimista 30.11.2015 JOTU-2015 / K.Systä 73
Monitoimittajaprojektit Tarvittavaa järjestelmää rakentaa usein monen toimijan verkosto Koska projekti on liian suuri yhdelle, tai Tarvitaan monenlaista osaamista, tai Kilpailutus tai liiketoimintasyistä Haasteita Vastuun jakaminen (yksi toimittaja vastuussa kokonaisuudesta vaiko tilaaja) Rajapintojen määritteleminen tärkeä 30.11.2015 JOTU-2015 / K.Systä 74
Rajapinnat ja monitoimittajaverkostot Rajapinta on yleisin tapa toteuttaa työnjako projektin aikana Vaatii ylimääräistä vaivaa, mutta vaihtoehto on vielä kalliimpi Dokumentoitu ja erikseen hallittu rajapinta mahdollistaa uusien toimittajien käyttämisen lisäkomponentteihin Standardi (tai de-facto) rajapinta mahdollistaa valmiiden komponenttien käytön Toinen puoli asiasta vendor lock-in 30.11.2015 JOTU-2015 / K.Systä 75
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Asiakasrooleista Käytettävyyden merkityksestä Tiedon mallintamisesta (kirjan luku 10) Laadunvarmistuksesta Projektitoiminnasta Ohjelmistolisensseistä 30.11.2015 JOTU-2015 / K.Systä 76
IPR:n tyypit Patentti Vastoin kuin joskus väitetään ohjelmistokeksintöjä voi patentoida Copyright Voi suojata lähdekoodia, käyttöliittymää tai ohjelmointirajapintaa (API) Liikesalaisuus (Trade secret) 30.11.2015 JOTU-2015 / K.Systä 77
Hankinnan ja oston kysymyksiä sopimusta tehtäessä Kuuluuko kauppaan sekä binääri että lähdekoodi Entä dokumentointi Kellä on oikeus jatkokehittää? Mikä ovat komponentteina käytettyjen osien tai riippuvuuksien IPR- ja lisenssitilanne? Tulevat organisaatiouudistukset ja yrityskaupat 30.11.2015 JOTU-2015 / K.Systä 78
No mitäs opiskella tämän jälkeen? TIE-21300 Ohjelmistoarkkitehtuurit TIE-21200 Ohjelmistojen testaus JOTU TIE-21100 Johdatus tietokantoihin TIE-21100 Ohjelmistot. menetelmät TIE-41106 User interface design TLO-35250 Datan ja inform, hallinta TIE-13100 Tietotekn. projektityö TLO-35200 Liiket. ja tietoj yhteensov. 30.11.2015 JOTU-2015 / K.Systä 79