24.11.2014 JOTU-2014 / K.Systä 1 Kertausluento 24.11.2014
Arvostelusta Tentistä saa maksimissaan 18 pistettä. Harjoitustyöstä saa 1-6 pistettä. Viikkoharjoituksista voi myös saada 1-6 pistettä aktiivisuuden mukaan. (10 osallistumiskertaa antaa 6 pistettä, yhden pisteen saa viidestä osallistumiskerrasta. Arvosana lasketaan kahdella tavalla: tentti+harjoitustyö ja tentti+harjoitustyö+viikkoharjoitukset. Parempi arvosana jää voimaan. 24.11.2014 JOTU-2014 / K.Systä 2
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon mallintamisesta (kirjan luku 10) Asiakasrooleista Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Ohjelmistolisensseistä 24.11.2014 JOTU-2014 / 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 seuraava kalvo Luennot, kalvot ovat verkossa mutta eivät sisällä kaikkea Luennolla kuullun muistaminen, tai googlettaminen auttaa 24.11.2014 JOTU-2014 / K.Systä 4
24.11.2014 JOTU-2014 / K.Systä 5 Mikä osa kirjasta kannattaa lukea Alku 1 2.8.2 on syytä lukea 2.6, 2.8.3, 2.9, 2.10 ei kuulu tälle kurssille 3 on keskeistä sisältöä 4-4.3 kuuluu, mutta 4.4 ei 5 kuuluu 6 sillä tasolla kuin luennoilla käsiteltiin 9 ei kuulu 7,8,10 sillä tasolla kuin luennoilla käsiteltiin 11 ja 12 kuuluu 13 ja 14 ei kuulu 15 kuuluu 16 kuluu vain niiltä osin kuin koskee myös ostajaorganisaatiota
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] 6 24.11.2014 JOTU-2014 / K.Systä
Mitä on ohjelmistotuotanto? Vaatimusmäärittelyä Taitavaa ohjelmointia Elinkaarimallit Yhteispeliä, yhteistä peliä Algoritmit Tietorakenteet Ohjelmointikielet Arkkitehtuurit Laadunvarmistusta Testaus Validointi Projektinhallinta 724.11.2014 JOTU-2014 / 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. 24.11.2014 8 JOTU-2014 / K.Systä
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 9 24.11.2014 JOTU-2014 / K.Systä
Ohjelmistotyyppejä(2) Sulautetut järjestelmät Koneen tai laiteen sisällä hissin ohjausjärjestelmä Reaaliaikajärjestelmät (esimerkki) 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ä? 10 24.11.2014 JOTU-2014 / K.Systä
Kuva 1.2 Infrastuktuuri: tietoliikenne, toimistoautomaatio, ryhmätyö, asianhallinta, palvelimet... Yrityksen tietovarastot Johdon tietojärjestelmät, päätöksenteon tuki Markkinointi Taloushallinto Tuotteiden suunnittelu, operatiiviset järjestelmät, tuotannonohjaus, materiaalihallinto, logistiikka Prosessi- ja tuotantoautomaatio Tietotekniikka tuotteissa 11 6.9.2009 JOTU-2014 / K.Systä 11
Esimerkki 1: tyypillinen työkoneen ohjausjärjestelmä Ohjaus- PC Linux- tai Windows-käyttöjärjestelmä CAN-väylä Puomin ja kouran ohjaus Moottorin ohjaus Vaihteiston ohjaus Rungon ohjaus Hallintalaitteiden ohjaus toimilaitteet ja anturit toimilaitteet ja anturit toimilaitteet ja anturit toimilaitteet ja anturit toimilaitteet ja anturit Tyypillisesti PLC-ohjaimia (+IEC 61131-3 -standardin mukainen ohjelmointi) tai RT-käyttöjärjestelmä (+C-ohjelmointi) 12 JOTU-2014 / K.Systä 12
NMT-puhelin 20 kloc GSM-keskus 15MLOC äly-puhelin 20MLOC? televisio 200 kloc (yksinkertainen)hissi 50 kloc moderni auto? avaruussukkula 21 MLOC (sukkulassa 0,5MLOC) säätoventtiilin ohjaus 25kLOC työkoneen ohjaus 250kLOC Sulautetut järjestelmät Työn tuottavuus? LOC Lines of Code, koodiriviä 13 6.9.2009 JOTU-2014 / K.Systä 13
Ohjelmistojen koko Embedded Software: Facts, Figures, and Future IEEE Computer, April 2009 (vol. 42 no. 4) 24.11.2014 JOTU-2014 / K.Systä 14
Ohjelmistojen koko Embedded Software: Facts, Figures, and Future IEEE Computer, April 2009 (vol. 42 no. 4) 24.11.2014 JOTU-2014 / K.Systä 15
Koodia on paljon 24.11.2014 JOTU-2014 / K.Systä 16
Ohjelmiston ominaisuuksia ohjelmiston koko ja käsiteltävän tiedon määrä käsittelypainotteinen vs. tietopainotteinen vasteaika- ja reaaliaikaisuusvaatimukset kovat reaaliaikavaatimukset reaktioaika luotettavuus puolustautuva ohjelmointi kahdentaminen elektroniikka- ja mekaniikkatason varmistukset hajautus paikallinen / laaja sulautetut järjestelmät - laiteväylä 17 24.11.2014 JOTU-2014 / K.Systä
Tämä kulunut kuva on pakko näyttää 18 24.11.2014 JOTU-2014 / 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-2014 / K.Systä 24.11.2014 19
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-2014 / K.Systä 24.11.2014 20
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon mallintamisesta (kirjan luku 10) Asiakasrooleista Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Ohjelmistolisensseistä 24.11.2014 JOTU-2014 / K.Systä 21
Ohjelmistoprojekti on muutokseen reagoimista 22 24.11.2014 JOTU-2014 / 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 23 24.11.2014 JOTU-2014 / 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-2014 / K.Systä 24.11.2014 24
Vesiputous Managing the development of Large Software Systems [Royce 1970] Järjestelmävaatimukset Ohjelmistovaatimukset Ohjelmistonmäärittely Ohjelmistonsuunnittelu Ohjelmointi Testaus Käyttö 24.11.2014 JOTU-2014 / K.Systä 25
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 24.11.2014 JOTU-2014 / K.Systä 26
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 24.11.2014 JOTU-2014 / K.Systä 27
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 Esimerkiksi extreme Programming (XP) test driven development (TDD) Pariohjelmointi Scrum 24.11.2014 JOTU-2014 / K.Systä 28
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 24.11.2014 JOTU-2014 / K.Systä 29
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon mallintamisesta (kirjan luku 10) Asiakasrooleista Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Ohjelmistolisensseistä 24.11.2014 JOTU-2014 / K.Systä 30
Asiakasvaatimuksista tuotteeseen asiakasvaatimukset Määrittely Suunnittelu& toteutus ohjelmistovaatimukset 24.11.2014 JOTU-2014 / K.Systä 31
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 24.11.2014 JOTU-2014 / K.Systä 32
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ä. 24.11.2014 JOTU-2014 / K.Systä 33
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) (?) 24.11.2014 JOTU-2014 / K.Systä 34
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. 24.11.2014 JOTU-2014 / K.Systä 35
Tarve/idea Esiselvitys unohdetaan Tehdään itse Tilataan Ostetaan Vaatimusmäärittelyt Toimittajan valinta Räätälöidään Suunnittelu Toteutus Testaus Käyttöönotto Ylläpito Poisto 27.8.2012 36
Erilaisia projekteja asiakaskohtainen Toimittaja tutkimus toteutus testaus tarjous määrittely käyttöönotto määrittely käyttöönotto tarjouspyyntö Asiakas 38 8.9.2014 JOTU/K.Systä
Erilaisia projekteja asiakaskohtainen Toimittaja Toimittaja tutkimus toteutus testaus Määrittely tarjous tarjous käyttöönotto käyttöönotto Määritrelyn tilaus Asiakas Tarjouspyyntö tilaus 39 8.9.2014 JOTU/K.Systä
Iteratiiviset, ketterät yms Toimittaja tutkimus tot tot tot tot tarjous määr. test demo test demo test demo test käyt.otto määr. demo demo demo käyt.otto tarjouspyyntö Asiakas tarjous Demo tarkoittaa yhdessä käyttäjän kanssa tehtävää uudelleen pohdintaa. 40 8.9.2014 JOTU/K.Systä
24.11.2014 JOTU-2014 / K.Systä 41 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
24.11.2014 JOTU-2014 / K.Systä 42 Käyttötapauskaavio, versio 2 Dipparekisteri Lisää uusi opiskelija Lisää uusi kenttä Ohjaaja Etsi ehdot täyttävät opiskelijat tee palaverimuisti o lisää/poista ohjaaja kirjoita lausunto Laitoksen johtaja tarkastele tilastoja
24.11.2014 JOTU-2014 / K.Systä 43 Käyttötapauksen kuvaaminen UML ei standardoi mitenkään esitystapaa, eikä oikeastaan juuri muutakaan niihin liittyvää => paljon erilaisia tulkintoja Käyttötapauksen sisältö voidaan kuvata esimerkiksi: Käyttötapauksen nimi: Kuvaava nimi Osallistujat: Mitkä aktorit osallistuvat Tuloehdot: Mitkä ehdot ovat voimassa, kun käyttötapaus aloitetaan Kuvaus: Epäformaali, voidaan käyttää myös sekvenssikaavioita Poikkeukset: Poikkeustilanteet (mainitaan myös kuvauksessa) Lopputulos: Mitkä ehdot ovat voimassa, kun käyttötapaus lopetetaan Muut vaatimukset: käyttötapaukseen liittyvät ei-toiminnalliset vaatimukset
Käyttäjätarina (user story) Ketterissä menetelmissä yleisesti käytetty termi. Muutamaan lauseeseen typistetty "käyttötapaus" Tarinasta selviää: rooli (aktori) mitä tehdään ja yleensä mitä lisäarvoa tekeminen tuottaa käyttäjälle (paitsi jos tämä on kuitenkin ilmeistä) Esimerkiksi: Kurssin vastuuhenkilönä pystyn tekemään kaikki yhden kurssin luentosalivaraukset yhdellä varausoperaatiolla (silloin kun luentoajat ovat koko kurssin ajan samoina viikonpäivinä samaan kellonaikaan). Huom: pyrähdyksen taskeissa definition of done 24.11.2014 JOTU-2014 / 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) Asiakasrooleista Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Ohjelmistolisensseistä 24.11.2014 JOTU-2014 / K.Systä 45
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.) 24.11.2014 JOTU-2014 / K.Systä 46
Esitetään useimmiten graafisesti Oliokaavio Luokkakaavio (UML) ER-kaavio (entity-relationship kaavio) Tietoyhteyskaavio Käsitekaavio Kohdekaavio 24.11.2014 JOTU-2014 / K.Systä 47
Käsitekaavio (UML:n luokkakaavio) Nimi Ominaisuudet lkm lkm nimi Nimi Ominaisuudet Metodit Metodit 24.11.2014 JOTU-2014 / K.Systä 48
Esimerkki 24.11.2014 JOTU-2014 / K.Systä 49
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon mallintamisesta (kirjan luku 10) Asiakasrooleista Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Ohjelmistolisensseistä 24.11.2014 JOTU-2014 / K.Systä 50
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 24.11.2014 JOTU-2014 / K.Systä 51
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 tarjous tarjouspyyntö Demo tarkoittaa yhdessä käyttäjän kanssa tehtävää uudelleen 24.11.2014 JOTU-2014 / K.Systä pohdintaa. 52 Asiakas
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ä 24.11.2014 JOTU-2014 / K.Systä 53
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 24.11.2014 JOTU-2014 / K.Systä 54
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon mallintamisesta (kirjan luku 10) Asiakasrooleista Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Ohjelmistolisensseistä 24.11.2014 JOTU-2014 / K.Systä 55
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 24.11.2014 JOTU-2014 / K.Systä 56
Sidosryhmät 24.11.2014 JOTU-2014 / K.Systä 57
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) 24.11.2014 JOTU-2014 / K.Systä 58
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon mallintamisesta (kirjan luku 10) Asiakasrooleista Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Ohjelmistolisensseistä 24.11.2014 JOTU-2014 / K.Systä 59
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. 24.11.2014 JOTU-2014 / K.Systä 60
Standardeja ISO9001 Tällä hetkellä käytännössä tärkein (ei silti kovin tärkeä?). ISO9001 standardi määrittelee tietyt puitteet laatujärjestelmän kehittämiseksi. Uusin versio vuonna 2008. CMMI SEI:n (Software Engineering Institute) perinteinen CMM-malli (Capability Maturity Model) määrittelee viisi kypsyystasoa. Kypsyystasomalli määrittelee asiat, joita kullakin tasolla on kehitettävä seuraavalle tasolle pääsemiseksi. Nykyisin mallin nimi on CMMI ja siitä on kaksi versiota staged representation: perinteinen CMM-malli continuous representation: vastaa ISO 15504-standardia SPICE (eli ISO 15504) Muita standardeja Laatupalkintokriteerit (www.sly.fi): vuoden 2009 voittaja Viking Line ITIL (~ISO 20000): palveluiden hallinta, yrityksen tietohallinto (Joel test) 24.11.2014 JOTU-2014 / K.Systä 61
Kertausluento Kirjan luku 1 Ohjelmistotuotannon yleiset haasteet Ohjelmistotyypit Kirjan luku 2 Projektimallit Yleiset periaatteet, asiakkaan kannalta Vaatimusten käsittely (kirjan luku 3) Tiedon mallintamisesta (kirjan luku 10) Asiakasrooleista Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Ohjelmistolisensseistä 24.11.2014 JOTU-2014 / K.Systä 62
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 24.11.2014 JOTU-2014 / K.Systä 63
Kustannukset Mahdoton alue Projektisuunnittelun haaste Mahdoton alue Kalenteriaika 24.11.2014 JOTU-2014 / K.Systä 64
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 24.11.2014 JOTU-2014 / K.Systä 65
Projektin puristajat 24.11.2014 JOTU-2014 / K.Systä 66
Projekti 24.11.2014 JOTU-2014 / 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) Tiedon mallintamisesta (kirjan luku 10) Asiakasrooleista Käytettävyyden merkityksestä Laadunvarmistuksesta Projektitoiminnasta Ohjelmistolisensseistä 24.11.2014 JOTU-2014 / K.Systä 68
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) 24.11.2014 JOTU-2014 / K.Systä 69
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 24.11.2014 JOTU-2014 / K.Systä 70
Nykyajan elämää 24.11.2014 JOTU-2014 / K.Systä 71
No mitäs opiskella tämän jälkeen? TIE-21300 Ohjelmistoarkkitehtuurit TIE-21200 Ohjelmistojen testaus JOTU TIE-22100 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. 24.11.2014 JOTU-2014 / K.Systä 72
Ja muistakaa palaute Suoritusmerkintää ei kuulemma saa jos kaikupalautetta ei ole annettu 24.11.2014 JOTU-2014 / K.Systä 73