Skip to content

5.3 Toimeksianto

Johdanto toimeksiantoon

CodeCerub Oy on saanut asiakkaakseen JAMK IT:n WIMMA Capstone-koulutusympäristön, joka on juuri nyt kehityksen alla. WIMMA Capstonen toimintaa pyritään avaamaan eri sidosryhmille ja siihen tarvitaan erilaisia palveluja. Toimeksianto CodeCerub Oy:lle on kehittää WIMMA Capstonen käyttöön soveltuva Foorumi-palvelu, joka liitetään myöhemmin osaksi kotisivuja. Foorumin toteutuksen pohjana hyödynnetään (Open Source) avoimen lähdekoodin perustuvaa Conduit-ohjelmistoa, joka on asiakkaan esittämä toive. Syynä tähän on tiukka aikataulu. Asiakkaalla on vahva oletus, että tämä säästää aikaa kehitykseltä ja voidaan keskittyä nopeampaan käyttöönottoon.

Demo-palvelin avuksi

CodeCerub Oy:n tiimi on tutustunut ennakolta Conduit -palveluun käyttäen apuna vapaasti tarjolla olevia demo-palveluita. Näitä voi käyttää projektin määrittelyn tukena. Demo-palvelu löytyy syksyllä 2023 oletuksena seuraavalta palvelimelta osoitteesta: https://demo.realworld.io/#/. Samasta Conduit-palvelusta on tarjolla myös erilaisia toteutuksia (eri kielillä ja kehikoilla) ja näihin voi myös tutustua https://codebase.show/projects/realworld

Muista, että Demo-palvelin saattaa yllättäen kaatua ja tiedot katoavat aina tässä yhteydessä!

Tärkeät henkilöt ja tarpeet

Asiakkaan edustajana toimii aiemmin WIMMA Capstonen kehityksessä työskennellyt arkkitehti Maarit Pitkäniemi, joka toivoo Forum-palvelun käyttöön saamista ~4 kk jälkeen projektin alkamisesta. Tämä tarkoittaa sitä, että ohjelmistopalvelu tarvittavine muutoksineen on asiakkaan täysimääräisessä käytössä projektin loppuessa. CodeCerub Oy vastaa tämän jälkeen palvelun tukemisesta ja siihen liittyvästä ylläpidosta. Ylläpito ja tukipalvelu ei kuulu alkuperäisen projektin tavoitteisiin.

Projektin tavoite on muokata ja kehittää nykyisestä Conduit-ohjelmistosta paremmin asiakkaan tarpeeseen sopiva versio. Tärkeimpinä toimintoina asiakas edellyttää käyttöliittymän sulavaa integrointia WIMMA Lab-kotisivun kanssa ja saumatonta liittämistä osaksi kotisivuja. Lisäksi tietosuojan vaikutukset on otettava huomioon palvelun tuotannossa.

Projektin kesto ja kokonaisuus

  • Projektin kesto on max 3.5 kk
  • Projektissa käytetään yhden viikon mittaisia sprinttejä (1 sprint = 1 viikko)
  • Projektin aloituspäivä on Keskiviikko 28.8.2024
  • Projektin alkuvaiheen suunnittelu voidaan laskuttaa taannehtivasti, eli projektin valmistelu voidaan aloitaa heti
  • Tarkka aloitus päivä projektille määrittyy opintojakson suoritushetken perusteella (Tarkasta mikä on aloitusluennon/infon päivämäärä = projektin aloituspäivä)
  • Projektin työaika maanantaista-perjantaihin 8:00-16:00

Toimeksiantoon liittyvät henkilöt

  • Asiakkaan edustajana toimii WIMMA Capstonen tiimistä Maarit Pitkäniemi
  • Johtoryhmään oletetusti kuuluvat seuraavat henkilöt:
  • Sinä (tunnuksesi gitlabissa)
  • WIMMA Capstonen Senior Coach Mauri Karvalahti
  • Tuoteomistajana toimii Marko "Narsuman" Rintamäki, jolle ei ole erillistä tunnusta gitlabissa (Älä liitä assign)

Projektin jakaminen vaiheisiin:

CodeCerubilla työskentelevä vanhempi projektipäällikkö Arnold Suksi on antanut sinulle listan tärkeimmistä etapeista, joita hän on käyttänyt aiemmissa projekteissa. Arnold kehotti käyttämään näitä, koska ne ovat toimineet aika hyvin, mutta voit soveltaa niitä tarpeen mukaan

Muista, että etappi tarkoittaa joitan valittua päivämäärää, jolloin ennalta sovitut tavoitteet on tarkoitus saavuttaa. Älä sekoita etappia käynnissä olevaan sprinttin.

Projektin etapit ja arvioidut kestot

  • E0 - Esivalmistelut ~1 vk
  • E1 - Tarkempi suunnittelu ~2 vk
  • E2 - Toteutus (implementointi) käynnissä (???)
  • E3 - Tarkistukset ja korjaukset ~2 vk
  • E4 - Luovutus ja projektin lopetus 1 vk
  • E5 - Palvelutuotannossa ~2 pv

Asiakkaan antamaa taustatietoa (vaatimuksia palvelulle)

Asiakkaan kanssa on käytä alustavasti keskustelua palvelun toteuttamisesta ja samalla on tullut ilmi muutamia tärkeitä kohtia:

  • Palvelun kannalta saavutettavuus on tärkeässä osassa ja pyritään noudattamaan EU:n asettamia saavutettavuuden vaatimuksia.
  • Kannattaa tutustua saavutettavuudelle asetettuihin yleisiin vaatimuksiin 5-10 kpl. Nämä kirjataan vaatimusmäärittelyyn
  • Palvelun suorituskyvylle (performance) on asetettu tavoitteeksi palvella alkuvaiheessa suomen tasolla muutamia satoja käyttäjiä. Tulevaisuudessa on varauduttava kansainvälisen kanssakäynnin aktivoitumiseen ja oletetaan, että käyttäjä kunta on 5 vuoden aikajänteellä noin 10000 henkilöä.
  • Yhtäaikaisisia käyttäjiä oletetaan olevan ~10 normaalitilanteessa, mutta aktiivisemmassa tilanteessa ~100 henkilöä.
  • Palvelun on oltava saatavilla 24/7 ja SLA:ssa vaatimuksena 99% käyttöaste, eli 1 % on varttu huoltokatkoihin.
  • Tietoturvan osalta edellytetään Kyberturvallisuus keskuksen jakamia tunnettuja hyviä käytänteitä. Nämä lähteet toimivat myös lähteinä vaatimusmäärittelylle.
  • Kannattaa tutustua esitettyihin tietoturvavaatimuksiin ja kirjata niistä mielestäsi tärkeät (5-10kpl) mukaan omaan vaatimusmäärittelyyn

Asiakkaan antamaa lisätietoa

Asiakkaalta tuli materiaalia, josta selviää millaisia sidosryhmiä (stakeholders) liittyy tulevaisuudessa käynnistyvään WIMMA Capstonen toimintaan. Niitä voi käyttää määrittelytyön tukena. JAMK IT:llä aiemmin toimineen WIMMA Labin sidosryhmät ovat yhä voimassa, joten niitä voidaan käyttää samassa yhteydessä.

Kannattaa ehdottomasti tutustua WIMMA Lab Black Book

Työtehtävien tuntihinnoittelu asiakkaalle toimeksiannossa

Arnolod kaivoi kainalokotelostaan esille myös listan työtehtävien hinnoittelusta. Nämä ovat siis tuntihintoja jotka laskutetaan suoraan asiakkaalta. Älä hämmästy hintoja! (Kannattaa miettiä miten työtehtävän tuntihinta rakentuu: henkilön palkka ja sosiaalikulut, KATE (Kiinteät kulut) Tilat, laitteet, vuokrat etc.)

Hinnat eivät sisällä ALV 25,5 %

Kilpailu on koventunut, ja viimeisimmät tarkistetu hinnat eri tehtäville ovat seuraavat:.

  • Arkkitehti/johtava ohjelmoija 85 €/h
  • Ohjelmoija 80 €/h
  • Testaaja 75 €/h
  • Palvelumuotoilu 85 €/h
  • Projektihallinta 90 €/h
  • Graafinen suunnittelu 70 €/h
  • Palvelin ja tuotanto (DevOps) 90 €/h
  • Muut tehtävät 65 €/h

Miten paljon meillä on käytössä työaikaa?

Arnold selvitti ystävällisesti ennakkoon, miten paljon on käytettävissä eri henkilöill aikaa mahdolliseen projektiin. Tulokset perustuvat siihen miten paljon eri henkilöillä on kuormitusta. On normaalia, että eri henkilöt työskentelevät eri projekteille samaan aikaan ja on tärkeää selvitää miten paljon heillä on aikaa käytettävissä. Löydät jokaisen käytettävissä olevat tunnit tiimin kuvauksesta:

Projektin eteneminen vaiheittain

Milloin eri osaajia tarvitaan projektissa? Alla hieman hahmottelua, eli karkea resurssien käyttö projektin aikana etapeittain. (Perustuu aiempien projektien oppeihin). Tätä voi soveltaa kustannuslaskennan apuna.

  • (E0) Käynnistysvaihe: Projektipäällikkö (on käytännössä mukana kaikissa vaiheissa)
  • (E1) Määrittelyvaihe: CodeCerub-asiakaspalvelun edustaja, arkkitehti/pääohjelmoija, palvelumuotoilija, ja projektipäällikkö
  • (E2) Suunnittelu + Toteutus: mukaan liittyy tulevat graafinen suunnittelija ja yksi testaaja
  • (E3) Toteutus+korjaus: ohelmoijat + testaajat + tarvittaessa muita henkilöitä
  • (E4) Toteutus/hyväksyntätestaus Mukana ovat testaajat ja ohjelmoijat ja asiakaspalvelu ja projektinhallinta
  • (E5) Palvelun käynnistys vaiheessa Projektipäälliikö + tuotantotiimi

Alustava Työlista/Backlog

Arnold ehti palaveerata asiakkaan kanssa pari viikko sitten ja kartoitti ennakkoon tärkeitä tehtäviä, joita projektissa on saatava aikaiseksi tulevien kuukausien aikana. Tutustu alla olevaan listaan tehtävistä ja siirrä ne oletuksena Gitlab-projektiisi (issueiksi) työlistan eli (Backlog) muotoon.

Huomaa useat tehtävät on kirjauttu suoraan User Story muotoon! Listaan voi vielä tulla täydennystä, jos jotain ilmenee! Huomio, että eri tyyppiset tehtävät kirjataan Issue-tyyppien mukaan!

Arnoldin keräämä lista:

HUOMIO Ennalta on sovittu seuraavat tapahtumat ja ne kirjataan projektin työlistaan (Backlog) käyttäen "Yleinen" -Issue Templatea. Sijoita issuet aikataulun mukaan!

Tehtävä Ajankohta Vastuu Muuta
Organisoi johtoryhmän kokoukset E4 Johtoryhmä Tutustu materiaaliin 2.7 Johtoryhmä ja palverikäytännöt
Projektisuunnittelun työkokous E2 Johtoryhmä Tutustu materiaaliin 2.7 Johtoryhmä ja palverikäytännöt
Järjestä saunailta E5 Johtoryhmä + koko tiimi
Pidä tilannekatsaus Joka toinen viikko koko tiimi
Järjestä esittelytilaisuus sidosryhmille E3 Johtoryhmä + sidosryhmät

Seuraava lista sisältää itse tuotteeseen käyttötarinoita (User Story), vikaraportteja (Bug report) ja parannusehdotuksia (Enhancement), jotka tulivat esiin asiakkaan keskusteluissa. Nämä pitää ehdottomasti kirjata projektin Backlogiin! Ne syötetään käyttäen apuna sopivaa Issue Templatea, koska samalla ne saavat oikean Label-merkinnän.

ID Kuvaus Tyyppi
US39 Palvelutuottajana haluan ajaa palvelua Amazon AWS:n varassa, koska se selkeyttää tuotantoa User Story
US30 Kehittäjänä haluan, että voin käynnistää testiympäristön docker-compose up komennolla User Story
US31 Palvelutuottajana haluan saada palautetta loppukäyttäjilä, jonka perusteella palvelua voidaan parantaa asiakaslähtöisesti User Story
US32 Palvelutuottajana haluan tukea loppukäyttäjää käyttäen siihen DOORBELL.io palvelua, koska en halua kuormittaa kehitystiimiä ylimääräisillä kysmyksillä User Story
US33 Palvelutuottajan on palvelustamme löydyttävä GDPR kuvaukset, koska tietosuojalaki edellyttää sitä User Story
US34 Palvelutuottajan haluan vaihtaa palvelun värit WIMMA Capstonen-sivuston mukaisiksi User Story
US35 Testaajana haluan pystyttää testiympäristön kontti (docker) tekniikalla, koska se on tehokkaampaa User Story
US36 Kehittäjänä haluan päivittää kehitysympäristön tietokannan nopeasti käyttäen kontteja User Story
US37 Toimeksiantajana toivon, että sivusto näyttää visuaalisesti yhtenäiseltä sopien WIMMA Capstonen brandiin User Story
US38 Palvelun käyttäjän toivon, että tunnukseni ovat turvassa ja voin käyttää HTTPS-yhteyttä, koska en uskalla käyttää HTTP-palveluja nykyaikana User Story
US49 Palvelun kehittäjänä toivon, että kaikki käyttäjäpalaut tulee Gitlab Issue-muodossa eteeni, koska se on selkeämpää jatkokäsitellä User Story
US40 Järjestelmän ylläpitäjänä haluan että testiympäristön tietokannasta voidaan ottaa tarvittaessa backup komentoriviltä User Story
US41 Palvelun tuottajana haluan käytää konttien jakamisessa myös Docker Hubin konttirekisteriä User Story
US42 Palvelun tuottajana haluan, että palvelu tallentaa päivittäin kättölogia, josta voidaa nähdä käyttäjien määrä ja palvelun käyttöaste User Story
US40 Forumin käyttäjänä toivon voivani palata helposti WIMMA Capstone-sivustolle
ENHANCEMENT-4 Delete-nappula on hyvä lisätä artikkelin muokkausnäkymään EHDOTUS
BUG Artikkelin suuri koko aiheuttaa virheviestin ja istunto kaatuu tai jumittuu VIKA
ENHANCEMENT-5 Tägin lisääminen vaatii syöttökentässä ENTER-painalluksen EHDOTUS