ohjelmistot vs. perinteinen teknologia · käsitteiden, niiden ominaisuuksien ja suhteiden avulla....
Post on 20-Jun-2020
1 Views
Preview:
TRANSCRIPT
24.11.2014
Kertausluento
24.11.2014 1 JOTU-2014 / K.Systä
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 3 JOTU-2014 / K.Systä
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 4 JOTU-2014 / K.Systä
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 ostaja-
organisaatiota
24.11.2014 5 JOTU-2014 / K.Systä
24.11.2014
6
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]
JOTU-2014 / K.Systä
Mitä on ohjelmistotuotanto?
7
Taitavaa
ohjelmointia Yhteispeliä,
yhteistä peliä
Elinkaarimallit
Vaatimus-
määrittelyä
Laadun-
varmistusta
Testaus
Validointi
Algoritmit
Tietorakenteet
Ohjelmointikielet
Arkkitehtuurit
Projektinhallinta
24.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.
8
24.11.2014
JOTU-2014 / K.Systä
24.11.2014
9
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
JOTU-2014 / K.Systä
24.11.2014
10
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ä?
JOTU-2014 / K.Systä
6.9.2009
11
Kuva 1.2
Prosessi- ja tuotantoautomaatio
Tuotteiden suunnittelu,
operatiiviset järjestelmät,
tuotannonohjaus,
materiaalihallinto,
logistiikka
Taloushallinto
Johdon
tietojärjestelmät,
päätöksenteon tuki
Markkinointi
Tietotekniikka tuotteissa
Infrastuktuuri: tietoliikenne, toimistoautomaatio, ryhmätyö, asianhallinta, palvelimet...
Yrityksen tietovarastot
JOTU-2014 / K.Systä 11
12
Esimerkki 1: tyypillinen työkoneen
ohjausjärjestelmä
CAN-väylä
Puomin ja
kouran
ohjaus
toimilaitteet ja
anturit
Moottorin
ohjaus
toimilaitteet ja
anturit
Rungon
ohjaus
toimilaitteet ja
anturit
Hallinta-
laitteiden
ohjaus
toimilaitteet ja
anturit
Vaihteis-
ton
ohjaus
toimilaitteet ja
anturit
Ohjaus-
PC
Tyypillisesti PLC-ohjaimia (+IEC 61131-3 -standardin mukainen ohjelmointi)
tai RT-käyttöjärjestelmä (+C-ohjelmointi)
Linux- tai Windows-käyttöjärjestelmä
JOTU-2014 / K.Systä 12
6.9.2009
13
Sulautetut järjestelmät
• 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
• Työn tuottavuus?
LOC – Lines of Code, koodiriviä
JOTU-2014 / K.Systä 13
Ohjelmistojen koko
24.11.2014 14
Embedded Software: Facts, Figures, and Future IEEE Computer, April 2009 (vol. 42
no. 4)
JOTU-2014 / K.Systä
Ohjelmistojen koko
24.11.2014 15
Embedded Software: Facts, Figures, and Future IEEE Computer, April 2009 (vol. 42
no. 4) JOTU-2014 / K.Systä
Koodia on paljon
24.11.2014 16 JOTU-2014 / K.Systä
24.11.2014
17
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ä
JOTU-2014 / K.Systä
Tämä kulunut kuva on pakko näyttää
24.11.2014
18
JOTU-2014 / K.Systä
Miksi menee pieleen; tilaajanäkökulma
24.11.2014 19
0 5 10 15 20 25 30 35 40 45 50
Yritysjärjestelyt
Ei kriisejä
Ongelmat…
Hinnoittelumallista…
Sopimuksesta…
Kommunikaation puute
Henkilövaihdokset…
Laadun pettäminen
Eri näkemys projektin…
Budjetin pettäminen
Aikataulun pettäminen
Lähde: tietotekniikan liiton, ohjelmistoyrittäjien ja Celkee OY:n tutkimus JOTU-2014 / K.Systä
Miksi menee pieneen; toimittajanäkökulma
24.11.2014 20
0 5 10 15 20 25
Yritysjärjestelyt
Sopimuksesta aiheutuvat syyt
Hinnoittelumallista johtuvat syyt
Ongelmat henkilökemioissa
Ei kriisejä
Budjetin pettäminen
Laadun pettäminen
Henkilövaihdokset projektissa
Aikataulun pettäminen
Eri näkemys projektin sisällöstä
Kommunikaation puute
Lähde: tietotekniikan liiton, ohjelmistoyrittäjien ja Celkee OY:n tutkimus JOTU-2014 / K.Systä
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 21 JOTU-2014 / K.Systä
Ohjelmistoprojekti on
muutokseen reagoimista
24.11.2014
22
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
24.11.2014
23
JOTU-2014 / K.Systä
24.11.2014 24
Kehitysprosessit: erilaisia variaatioita samasta
teemasta
Asiakkaan ongelma
Määrittely
asiakasvaatimukset
Suunnittelu
ohjelmistovaatimukset, ”määrittely”
Toteutus
tekniset vaatimukset, ”suunnittelu”
Hyväksymistestaus
asiakastoimitus
Te
sta
us, la
ad
un
va
rmis
tus
Seuraava versio
JOTU-2014 / K.Systä
Vesiputous Managing the development of Large Software Systems [Royce 1970]
24.11.2014 25
Järjestelmä-
vaatimukset
Ohjelmisto-
vaatimukset
Ohjelmiston-
määrittely
Ohjelmiston-
suunnittelu
Ohjelmointi
Testaus
Käyttö JOTU-2014 / K.Systä
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 26 JOTU-2014 / K.Systä
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 27 JOTU-2014 / K.Systä
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 28 JOTU-2014 / K.Systä
24.11.2014 29
Esimerkki: SCRUM
”Requirements”
Sprintissä toteutettavat
tehtävät, aika-arviot
päivitetään päivittäin
Sprint burndown chart:
aika
työm
äärä
tuotteen
inkrementti
Sprint planning meeting: 4+4 tuntia:
•tuotteen omistaja esittelee Product
backlogia
•Tiimi päättää, mihin voi sitoutua
30 päivän pyrähdys
(sprint)
Sprint Review Meeting (4 tuntia):
Tiimi esittelee tuloksen
omistajalle…
The Sprint
Retrospective
(3 tuntia): miten
asiat saataisiin
sujumaan
paremmin
seuraavassa
pyrähdyksessä
Daily Scrum Meeting: 15 min:
•Edistys edellisestä palaverista?
•Ovatko aika-arviosi kunnossa?
•Mitä teet seuraavaksi?
•Onko ongelmia näkyvissä?
JOTU-2014 / K.Systä
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 30 JOTU-2014 / K.Systä
24.11.2014
Asiakasvaatimuksista tuotteeseen
Määrittely
Suunnittelu&
toteutus
ohjelmistovaatimukset
asiakasvaatimukset
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ä.
24.11.2014 JOTU-2014 / K.Systä 32
Asiakas-
vaatimukset
Ohjelmisto-
vaatimukset
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
24.11.2014
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) (?)
JOTU-2014 / K.Systä 34
24.11.2014
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.
JOTU-2014 / K.Systä 35
27.8.2012 36
Tarve/idea Esiselvitys unohdetaan
Tehdään itse Tilataan
Räätälöidään Vaatimus-
määrittelyt
Ostetaan
Suunnittelu
Toteutus
Testaus
Käyttöönotto Ylläpito Poisto
Toimittajan
valinta
Erilaisia projekteja - tuote
8.9.2014
37
Toimittaja
Asiakas
tutkimus
määrittel
y
toteutus testaus
myynti
paketointi
JOTU/K.Systä
Erilaisia projekteja – asiakaskohtainen
8.9.2014
38
Toimittaja
Asiakas
tutkimus
määrittely
toteutus testaus
käyttöönotto
tarjouspyyntö
tarjous
määrittely käyttöönotto
JOTU/K.Systä
Toimittaja
Erilaisia projekteja – asiakaskohtainen
8.9.2014
39
Toimittaja
Asiakas
tutkimus
tarjous
toteutus testaus
käyttöönotto
Määritrelyn
tilaus
Määrittely
Tarjous-
pyyntö
käyttöönotto
tilaus
tarjous
JOTU/K.Systä
Iteratiiviset, ketterät yms
8.9.2014
40
Toimittaja
Asiakas
tutkimus
määr.
tot
test
käyt.otto
tarjouspyyntö
tarjous
tarjous
määr. käyt.otto
demo
demo
tot
test
demo
demo
tot
test
tot
test
demo
demo
Demo tarkoittaa yhdessä käyttäjän
kanssa tehtävää uudelleen
pohdintaa.
JOTU/K.Systä
24.11.2014 41
Käyttötapauskaavio, versio 1
Ohjaaja
Lisää uusi
opiskelija
Etsi ehdot
täyttävät
opiskelijat
kirjoita
lausunto
tee
palaverimuisti
o
Lisää uusi
kenttä
Dipparekisteri
Pohja järjestelmän
hahmottamiselle ja siitä
keskustelemiselle
JOTU-2014 / K.Systä
24.11.2014 42
Käyttötapauskaavio, versio 2
Ohjaaja
Laitoksen johtaja
Lisää uusi
opiskelija
Etsi ehdot
täyttävät
opiskelijat
kirjoita
lausunto
tee
palaverimuisti
o
tarkastele
tilastoja
lisää/poista
ohjaaja
Lisää uusi
kenttä
Dipparekisteri
JOTU-2014 / K.Systä
24.11.2014 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
JOTU-2014 / K.Systä
24.11.2014 44
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”
JOTU-2014 / K.Systä
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 45 JOTU-2014 / K.Systä
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.)
JOTU-2014 / K.Systä 46 24.11.2014
Esitetään useimmiten graafisesti
• Oliokaavio
• Luokkakaavio (UML)
• ER-kaavio (entity-relationship kaavio)
• Tietoyhteyskaavio
• Käsitekaavio
• Kohdekaavio
JOTU-2014 / K.Systä 47 24.11.2014
Käsitekaavio
(UML:n luokkakaavio)
Nimi
Ominaisuudet
Metodit
Nimi
Ominaisuudet
Metodit
nimi
lkm lkm
JOTU-2014 / K.Systä 48 24.11.2014
Esimerkki
JOTU-2014 / K.Systä 49 24.11.2014
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 50 JOTU-2014 / K.Systä
Tietojärjestelmän rakentaminen
Liiketoimintastrategia
Strategiset
tavoitteet
Järjestelmä-
vaatimukset
Tietojärjestel-
mätoimitus
Käyttöönotto
ja hyväksyminen
Mittaus ja
analysointi
Mukailtu lähteestä:
Timo Koivisto: Tietojärjestelmä-
toimituksen jälkiseuranta,
Systeemityö 3/2006
Ylläpito
24.11.2014 JOTU-2014 / K.Systä 51
Toimittaja
Asiakas
tutkimus
määrittely
toteutus testaus
käyttöönotto
tarjouspyyntö
tarjous
tarjous
määrittely käyttöönotto
Toimittaja
Asiakas
tutkimus
määr.
tot
test
käyt.otto
tarjouspyyntö
tarjous
tarjous
määr. käyt.otto
demo
demo
tot
test
demo
demo
tot
test
tot
test
demo
demo
Demo tarkoittaa yhdessä käyttäjän
kanssa tehtävää uudelleen
pohdintaa.
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?
Tehdään yhdessä iteratiivisesti + voidaan yhdessä oppia * vaatii molemminpuolista sitoutumista ja luottamusta
24.11.2014 JOTU-2014 / K.Systä 52
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 55 JOTU-2014 / K.Systä
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 56 JOTU-2014 / K.Systä
Sidosryhmät
24.11.2014 57 JOTU-2014 / K.Systä
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 58 JOTU-2014 / K.Systä
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 59 JOTU-2014 / K.Systä
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 62 JOTU-2014 / K.Systä
Kiva löytö: (Ken Schwaber: Agile project managemet)
24.11.2014 JOTU-2014 / K.Systä 63
Close to
agreement
Far from
agreement
Close to certainty Far from certainty
Simple
Complicated
Complicated
Complex
Anarchy
Projektisuunnittelun haaste
24.11.2014 JOTU-2014 / K.Systä 64
Ku
sta
nn
ukse
t
Kalenteriaika
Ma
hd
oto
n a
lue
Mahdoton alue
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 65 JOTU-2014 / K.Systä
Projektin puristajat
24.11.2014 66 JOTU-2014 / K.Systä
Projekti
24.11.2014 67 JOTU-2014 / K.Systä
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 68 JOTU-2014 / K.Systä
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 71 JOTU-2014 / K.Systä
No mitäs opiskella tämän jälkeen?
24.11.2014 72
JOTU TIE-21100
Ohjelmistot. menetelmät
TIE-13100
Tietotekn.
projektityö
TIE-21300
Ohjelmistoarkkitehtuurit
TIE-21200
Ohjelmistojen testaus
TIE-22100
Johdatus tietokantoihin
TIE-41106
User interface design
TLO-35250
Datan ja inform, hallinta
TLO-35200
Liiket. ja tietoj yhteensov.
JOTU-2014 / K.Systä
Ja muistakaa palaute
• Suoritusmerkintää ei kuulemma saa jos kaikupalautetta ei ole
annettu
24.11.2014 JOTU-2014 / K.Systä 73
top related