Viimeisen luentoviikon aikana pohditaan ohjelmallista hypermediaa toteuttavan unelmaprojektin koostumusta. Ohjelmallista hypermediaa tuotetaan käytännössä aina projektimuotoisesti, joten projekti käy mainiosti jäsennykseksi opintojakson yhteenvedolle. Mistä tekijöistä unelmaprojekti koostuu?
Projekti alkaa tavoitteiden ja reunaehtojen määrittelyllä. Tavoitteita ja reunaehtoja aiheuttavat:
- käyttäjätarpeet: loppukäyttäjä, ylläpitäjä, (jatkokehittäjä)
- tietoturva
- olemassa olevat järjestelmät
- tuki sisällöntuotannolle
Myös teknologiavalinnat voivat määritellä reunaehtoja. Parasta kuitenkin olisi jos teknologia olisi mahdollista valita projektille asetettujen tavoitteiden perusteella, joten ihannetapauksessa teknologia ei tuo mukanaan uusia reunaehtoja.
Unelmaprojektin synnyttämää lopputuotetta voidaan kuvata seuraavilla laadun sanoilla:
- käytettävyys,
- saavutettavuus,
- laiteriippumattomuus,
- standardinmukaisuus (XHTML, CSS, …),
- yhteensopivuus, siirrettävyys, laajennettavuus, ylläpidettävyys,
- yksinkertaisuus ja
- yleinen skaalautuvuus (käyttöliittymä, käyttäjämäärä, ominaisuuksien määrä, jne.).
Vrt. “Build half a product, not a half-ass product” (Jason Fried, 2005).
Projektin kokoonpanolla on keskeinen merkitys projektin onnistumiselle. Unelmaprojektiryhmän kokoonpanoon kuuluvat esimerkiksi seuraavat asiantuntijat:
- ohjelmoijat,
- sovellusarkkitehti,
- sovellusalan asiantuntija,
- projektipäällikkö/rakennusmestari,
- yksittäisen asiakkaan edustaja,
- käytettävyystieteilijä,
- tekninen tuki,
- graafikko ja
- testaaja.
Projektilla on alkamisaika ja päättymisaika, joiden välissä projekti suunnitellaan ja toteutetaan. Projektin aikajana voidaan hyödyntää hallitusti erilaisten vaihejakomallien mukaisesti jäsennettynä. Vaihtoehtoja ovat ainakin
- vesiputousmallin eri sovellukset tai
- ketterä ohjelmistokehitys.
Unelmaprojektia ajatellessa mieleen tulee kiireettömyys, joka on suora johdannainen työn kokonaismäärän ja käytettävissä olevan ajan suhteesta. Projektin toteutustyön määrän pienentämisen tukena voidaan hyödyntää seuraavia ratkaisuja:
- Web-sovelluskehykset,
- yksittäiset ohjelmistokomponentit tai
- valmiit räätälöitävät sovellukset, esimerkiksi avoimen lähdekoodin sisällönhallintajärjestelmät.
NIH-ilmiön vältteleminen kaikin keinoin on keskeinen keino työmäärän pienentämisessä.
Ennen toteutustyön aloittamista on tietenkin syytä käyttää aikaa työn suunnittelemiseen. Ainakin seuraavat asiat on syytä lyödä lukkoon ja kirjata ylös suunnitteludokumentaatioon:
- tietosisältö,
- yksittäiset toiminnot: kuvaus, sallittu syöte, poikkeukset, tila toiminnon jälkeen, virheilmoitukset,
- toimintovuot (prosessit),
- tekninen arkkitehtuuri ja keskeiset rajapinnat.
Räätälöityjen HYTT-mallin mukaisten dokumenttien käyttäminen on soveltuvin osin toki mahdollista myös ketterässä ohjelmistokehityksessä. Vaihtoehtoisesti suunnittelutyössä voidaan soveltaa Verkkopalvelun sisällöntuotannossa esiteltäviä suunnitteludokumentteja. Suunnitteluperustan (design rationale) käsitteeseen tutustuminen on myös suositeltavaa. Ketterissä menetelmissä valtaosa suunnitteludokumentaatiosta kuitataan esimerkiksi käyttötarinoilla (user story) tai tuotteen ominaisuuksien listalla (backlog tai work queue) ja käytössä olevan sovelluskehyksen omalla dokumentaatiolla.
Laadunvarmistusprosessin automatisointi helpottaa jo julkaistun tuotteen ylläpitoa, esimerkiksi
Projektiryhmän työskentelyn tueksi tarvitaan joukko erilaisia sovellusohjelmia kehitystyön rutiinien automatisointiin, yhteisten resurssien hallinnoimiseen, kommunikoimiseen ja tiedon jakamiseen. Unelmaprojektin käytössä on ainakin osa seuraavista välineistä:
- versionhallinta (CVS, SVN),
- kehitysympäristö eli IDE (kääntäjä, ajoympäristö, editori),
- ohjelmointivirheiden hallinta (Google-haku “bug tracker”),
- sähköposti,
- pikaviestimiä (IRC, Jabber, Skype),
- tiedon jakaminen: Wiki, blogi (vrt. Getting Real: Ride the Blog Wave),
- todo-listat ja
- jokin ryhmätyöväline: kalenteri ja muita ominaisuuksia.
Esimerkiksi 37signals on rakentanut joukon sovelluksia sovelluskehitysprojektien tueksi.
Hyvä nyrkkisääntö välineiden valinnassa on se, että välineen käytön myötä säästyvän ajan on oltava välineen tehokkaan käytön oppimiseen kuluvaan aikaan verrattuna merkittävästi suurempi.
Unelmaprojektin välineistö ja kokoonpano on yksinkertainen, mutta antaa tekijöille riittävät eväät laadukkaaseen lopputulokseen pääsemiseen suoraviivaisimmalla mahdollisella tavalla.
Eväitä unelmaan löytyy (pienistä hypetyksen elkeistä huolimatta) esimerkiksi Jason Friedin esitelmästä How to make big things happen with small teams (PDF-muodossa).
Mitä elementtejä unelmaprojektista vielä puuttuu? Kerro mielipiteesi kommentoimalla tätä viestiä.
Tuoreimmat kommentit
RSS