UML-kaaviot, Product Backlog (PB) ja Sprint Backlog (SB)

UML-kaaviot

• UML-kaavioita (tietoyhteyskaavio, luokkakaavio, käyttötapauskaavio) piirretään tekstimuotoisen määrittelyn ohella.
• Toimivat visuaalisena esityksenä järjestelmän rakenteesta ja toiminnasta.
• Navigaatiokaavio ei kuulu UML-kaavioihin.
• Käyttötapausten poikkeustilanteet ja ei-toiminnalliset vaatimukset voivat estää käyttäjää suorittamasta käyttötapausta loppuun.
• Esimerkki: ongelmat verkkokaupassa.

Product Backlog (PB) ja Sprint Backlog (SB)

• Product Backlog on järjestetty lista kaikista tuotteen tunnetuista ja tarpeellisista ominaisuuksista.
• Ainoa vaatimuslähde tuotteeseen tehtäville muutoksille.
• Product Backlog ei ole koskaan valmis, vaan muuttuu jatkuvasti tuotteen tarpeiden, kilpailukyvyn ja hyödyllisyyden mukaan.
• Sprint Backlog sisältää osan Product Backlogin alkioista, jotka on valittu kyseiseen sprinttiin.
• Sprint Backlogia muokataan koko sprintin ajan.

Pyrähdyksen tehtäväpino/tehtäväjono (Sprint Backlog = SB)

• Ei tule muuttaa pyrähdyksen aikana.
• Suunnitellut ominaisuudet muodostavat sprintin kehitysjonon.
• Mahdolliset uudet vaatimusideat (esim. asiakkaalta) siirretään Product Backlogiin.
• Product Backlogin palikoita ei oteta mukaan kesken olevaan pyrähdykseen.
• Tiimi arvioi sopivan määrän tehtäviä ja sitoutuu suunnitelmaan.
• Product Backlogin pilkkominen osiin johtaa Sprint Backlogiin.
• Kehitystiimi pilkkoo vaatimuksen/ominaisuuden pienemmiksi tehtäviksi (task).
• Yhden tehtävän koko on enintään yksi (tai 1,5) henkilötyöpäivää.

Ohjelmiston elinkaarimallit

• Esimerkkejä malleista: vesiputousmalli, lohiputousmalli, spiraalimalli, suihkulähdemalli, ketterä kehitysmalli.
• Näitä malleja yhdistää määrittely, suunnittelu, toteutus ja testaus.
• Elinkaareen kuuluvat: tarve/idea, esiselvitys, vaatimusmäärittely, suunnittelu, toteutus, testaus, käyttöönotto, ylläpito ja poisto.

Suurten ohjelmistojen kirjoittamisvaikeudet

• Suurten ohjelmistojen kehittäminen on haastavaa abstraktiuden, monimutkaisuuden, komponenttien lukumäärän ja riippuvuuksien vuoksi.

Ohjelmiston hankinnan eri tapoja

• Tekeminen itse, teettäminen, ostaminen ja räätälöinti, ostaminen valmiina.

Ketterän kehityksen periaatteet

• Iteratiivinen ja inkrementaalinen projektin hallintatapa.
• Tavoitteena on tuottaa ohjelmisto mahdollisimman pian.
• Vaiheittainen/asteittainen kehitysmalli ja pienempiin osiin pilkkominen.
• Asiakkaan mukanaolo ja panostus sekä asiakkaan määrittämät vaatimukset.
• Toiminnan säännöllinen tarkastelu.

Ketterän kehityksen menetelmät

• Scrum ja Kanban ovat esimerkkejä ketteristä menetelmistä.

Scrum

• Viitekehys, joka tekee tuotehallinnan ja työmenetelmien suorituskyvyn näkyväksi.
• Terminologia: Product Backlog, Sprint (toteutussykli), Daily Scrum (päivittäispalaveri), Scrum Master (työn edistäjä).

Kanban

• Visuaalinen työkalu, jolla seurataan tehtävien etenemistä.
• Tavoitteena optimoida tuotanto ja maksimoida asiakkaalle tuotettava arvo.
• Yksinkertaisimmillaan taulu, jossa säiliöt: TODO, DOING, DONE.

Scrum-tiimi

• Tuoteomistaja, kehitystiimi ja Scrum Master.
• Pyrähdys on Scrum-kehityksen peruselementti.
• Aikarajoitettu työjakso, enintään kuukauden pituinen.
• Uusi pyrähdys alkaa edellisen päätyttyä.

Burndown

• Kertoo jäljellä olevan tehtävän määrän.
• X-akselilla aika, Y-akselilla työmäärä.
• Voidaan käyttää tuotteelle, releaselle tai sprintille.
• Osoittaa jäljellä olevan työn määrän.

Burn up

• Kuvastaa projektin valmiusastetta ja seuraa edistymistä.
• X-akselilla aika ja valmiiksi saatu työ, Y-akselilla suunniteltu työ.

Palvelumuotoilun hyötyjä

• Tulisi olla mukana jokaisessa projektissa, ratkaisemaan ongelmia.
• Käyttäjä edellä, säätöjä ennen kehitystä.
• Yhteinen ymmärrys ja suunta, liiketoiminnan sekä käyttäjän tavoitteet linjassa.
• Sujuva asiointikokemus.

Ohjelmistokehityksen hukka

• Syntyy monissa eri vaiheissa ja liittyy ohjelmistoon, kehitysprosessiin sekä hankintoihin.

Vihreän koodin kymmenen lähtökohtaa

• Rajoita laskentatarkkuutta, tarkkaile energiakulutusta tosiaikaisesti, valitse sopiva ohjelmointikieli ja tekoälymalli, kerää virrankulutusdataa.
• Pyrähdysten ideana on testata tietty määrä uutta toiminnallisuutta.
• Testaus tulisi aloittaa heti, kun uutta testattavaa tulee, testauksen työmäärää aliarvioidaan usein.

Käyttöliittymän prototyypit

• Esimerkkejä: paperiprototyyppi, wireframe-prototyyppi ja interaktiiviset prototyypit.

Vähäkoodinen kehitys

• Sovelluskehitystä graafisessa ympäristössä ilman perinteistä ohjelmointia.
• Tavoitteena tehostaa ja nopeuttaa kehitystyötä.
• Vähentää ammattiohjelmoijien tarvetta.
• Soveltuu prosessien automatisointiin ja pieniin liiketoimintasovelluksiin.
• Ei sovellu kaikkiin käyttötapauksiin.

Muistisäännöt kaavioiden piirtämiseen

• Teksti ja kaaviot tukevat toisiaan, auttavat hahmottamaan järjestelmää ja rajaavat järjestelmän ympäristöä.

PaaS (Platform as a Service)

• Alustapalvelu, jossa käyttäjät voivat ottaa käyttöön pienempiä yksiköitä.
• Pilvipalvelu, joka mahdollistaa ohjelmistojen kehittämisen, julkaisun ja hallinnoinnin ilman omaa infrastruktuuria.
• Tarjoaa kehittäjille valmiin ympäristön omien sovellusten luomiseen.

FaaS (Function as a Service)

• Funktioiden ajoalusta, palveluntarjoaja vastaa resurssien allokoinnista.
• Mahdollistaa pilvipohjaisen sovelluskehityksen ilman, että käyttäjän tarvitsee huolehtia resurssien hallinnasta.
• Funktio pitää ajaa vain kerran, maksetaan vain käytöstä.

IaaS (Infrastructure as a Service)

• Alin tason cloud-palvelukerros, joka käsittää virtuaalikoneet, levyvekko, palomuuri yms.
• Skaalautuvia ja automatisoituja laskentaresursseja.
• Mahdollistaa resurssien ostamisen tarpeen mukaan.
• Joustavin pilvipalvelumalli.
• Etuja: tallennustilan, verkon, palvelimen ja prosessointitehon helppo automatisointi.
• Huolenaiheet: tietoturva, vanhojen järjestelmien toiminta pilvessä, sisäiset resurssit ja koulutus.

SaaS (Software as a Service)

• Yksittäinen sovellus palveluna, yleisin Cloud-palvelumalli.
• Ohjelmisto, joka otetaan käyttöön internetin kautta.
• Ylläpito on helppoa, etuja ovat hallinta ja saatavuus.
• Huolenaiheet: yhteentoimivuusongelmat, sitoutuminen yhteen palveluntarjoajaan, integraation puute ja tietoturva.

Pehmoasioiden merkitys projektin onnistumisessa

• Projektin onnistumiseen vaikuttavat muutkin asiat kuin tekniset taidot: vuorovaikutus, motivaatio ja hyvinvointi.

Huono pohja työlle

• Epäselvät tai puutteelliset vaatimusmäärittelyt.
• Hosumalla aloittaminen ja riittämätön suunnittelu.
• Oikeiden ongelmien ratkaisematta jättäminen.
• Syvä kuilu ohjelman suunnittelijoiden ja käyttäjien välillä.
• Aliarvioiminen.

Projektipäällikön/Scrum Masterin vastuu

• Projektipäällikkö: kommunikointi kaikkien sidosryhmien välillä, riskien hallinta, suunnitelman laatiminen ja hyväksyntä.
• Scrum Master: tiimi noudattaa Scrumin sääntöjä, paikantaa ja poistaa tiimin esteitä, valmentaa ja vaikuttaa Scrumin sääntöjen kautta.
• Palvelee organisaatiota johtamalla Scrum-käyttöönottoa.

Asiakaspuolen vastuu projektissa

• Tavoitteiden määrittely, vaatimusmäärittely, mukanaolo, kommunikointi, testaus ja muutosvastarinta.
• Ongelmien ratkaiseminen: ennakointi, varhainen tunnistaminen ja oppiminen.
• Vinkkejä työskentelyyn projektissa.

Projektin tavoitteiden selvitys

• Panostus suunnitteluun, aktiivinen kommunikointi, yhteistyö ja loppukäyttäjän sekä asiakkaan ymmärrys edesauttavat projektin onnistumisessa.

Tilannekuva ja tilannetietoisuus

• Tilannekuva: missä ollaan nyt.
• Tilannetietoisuus: mitä pitää tehdä seuraavaksi ja sen jälkeen.

Tilaajan vastuut ja velvollisuudet

• Hyväksyä määrittelydokumentti, olla mukana, kertoa tarvittavat ominaisuudet sekä muutokset ja asettaa vaatimukset tärkeysjärjestykseen.

Allianssimalli

• Pyrkii tiiviimpään yhteistyöhön tilaajan ja toimittajan välillä, jakaen hankkeen riskit ja hyödyt.
• Pyritään kokoamaan kyvykkyyksiä, mihin yksittäiset toimijat eivät yksin kykene.

Ohjelmistoprojektien yleisimmät ongelmat

• Määrittelyyn ja tavoitteisiin, suunnitteluun sekä valmisteluun, kommunikointiin ja yhteistyöhön, resursseihin ja osaamiseen ja testaukseen sekä laatuun liittyvät ongelmat.

Projektipäällikön työkaluja

• Kommunikointivälineet, suunnittelu- ja seuranta, projektinhallintaohjelmat, riskienhallintatyökalut ja testaus sekä laadunvarmistus.
• Pehmeät taidot ovat tärkeitä.
• Projektin edistymisen seurantaan käytetään versionhallintaa, PB, SB, Kanbania sekä palavereita.
• Loppukäyttäjien muutosvastarinta on huomioitava.

Ohjelmiston laajuuden mittaamista ja mittareita

• Tarkoitetaan toiminnallisen laajuuden määrittämistä (euroa tai tunteja per toimintopiste).

FLSMA mittari

• Vuorovaikutteiset navigointi- ja kyselytoiminnot sekä syöttötoiminnot.
• Yksisuuntaiset tulostetoiminnot.
• Lähetettävät ja vastaanotettavat liittymätoiminnot.
• Tiedonvarastointitoiminnot.
• Algoritmiset toiminnot ja käsittelytoiminnot.

Retrospektiivi

• Arviointi- ja kehityspalaveri pyrähdyksen lopussa.

Avoimen lähdekoodin ohjelmiston mahdollisuuden arviointi seitsemän askeleen prosessin avulla

• Seitsemän askelta: mitä ohjelman pitäisi pystyä tekemään, suoritetaan ohjelman koeasennus, arvioidaan tuen tarve, tutkitaan kannattaako palvelinta ylläpitää itse, arvioidaan hyödyt, selvitetään lisenssit sekä hyödyt, haitat ja kustannukset.

Avoimen ja suljetun lähdekoodin

• Avoin lähdekoodi: saatavilla ja muokattavissa, jatkokehitys mahdollista, monenlaisia lisenssejä.
• Suljettu lähdekoodi: ei saatavilla loppukäyttäjälle, laatu kehittäjäyrityksen vastuulla, kaupalliset lisenssit.

Sopimuksiin liittyviä huomioita

• Yleisiä huomioita: tarvittaessa käytä konsulttia.
• Välimiesmenettely yritysten välisten riitojen ratkaisemiseen.
• IPR (immateriaalioikeudet): suojaavat luovaa työtä (tuotteita, palveluita ja innovaatioita), lisenssit määrittelevät käyttöehdot ja rajoitukset.

Kilpailukieltosopimus

• Työnantajan ja työntekijän välinen sopimus, jolla rajoitetaan työntekijän kilpailevaa toimintaa työsuhteen päätyttyä.
• Tekijänoikeus syntyy ilman rekisteröintiä, jos teos täyttää tekijänoikeuden ja -lain kriteerit.

Sulautettujen järjestelmien haasteet

• Testaus on hankalaa, järjestelmien suunnittelu sekä toimivuus yhdessä.
• Ohjelmiston päivitettävyys.
• Hyvän tuoteomistajan rooli: syvällinen liiketoiminnan, tuotteen ja asiakkaiden tuntemus, vastuu onnistumisesta, voi edustaa asiakkaan roolia.

Tekoälysäädösten ulkopuolelle jäävät järjestelmät

• Päätöksentekojärjestelmät, jotka noudattavat ihmisten asettamia sääntöjä ilman koneoppimista.
• Laatukäsikirjaa ja sertifikaattia ei välttämättä tarvita, jos asiakas ei niitä vaadi.