14. ÄÄNESTYSJÄRJESTELMIEN KÄYTTÖ OHJELMISTOTUOTANTOPROSESSIN VAATIMUSTENHALLINNAN MENETELMÄNÄ

Jukka Rannila

14.1. Johdanto

14.1.1. Ohjelmistotuotanto

Suomalainen ohjelmistotuotannon perusteos on Haikalan ja Märijärven "Ohjelmistotuotanto" (1998). Tämä tutkimus käsittelee ohjelmistotuotannosta vain yhtä osa-aluetta. Ohjelmistotuotannon peruskokonaisuuden tietämätöntä lukijaa suosittelen lukemaan Haikalan ja Märijärven (1998) teoksen, jolloin tämä tutkimus asettuu paremmin kokonaisuuteen. Tässä tutkimuksessa luvussa 1.1. on vain lyhyt referaatti ohjelmistotuotannon eri osa-alueista.

Ohjelmistotuotannon projekteissa voidaan erottaa seuraavat perustoiminnot: määrittely, suunnittelu, ohjelmointi, testaus, käyttöönotto ja ylläpito. Erilaisissa ohjelmistotuotannon prosessimalleissa toistuvat yllämainitut perustoiminnot, mutta itse prosessimallit ovat erilaisia. Prosessimalleista riippumatta ohjelmistotuotantoprosesseista voidaan erottaa koko prosessin ajan tapahtuvaksi seuraavat toiminnot: tuotteenhallinta, laadunvarmistus, dokumentointi, vaatimustenhallinta. Tämän tutkimuksen kannalta oleellisimmat toiminnot ovat määrittely ja vaatimustenhallinta.

Määrittelyllä on ohjelmistotuotannon kirjallisuudessa monia nimityksiä: analyysi, vaatimusmäärittely, jne. Tämän tutkimuksen kannalta määrittely tarkoittaa seuraavaa:
Määrittelyn osana on kohdealueen (asiakas) vaatimusten etsiminen, kirjaaminen ja esittäminen.
Määrittelyn osana on toteutettavan järjestelmän määrittely. Määrittelyn tuloksena on määrittelydokumentti eli spesifikaatio.

Olipa käytetty tapa vaiheistaa ohjelmistotyötä mikä hyvänsä, tuotantoprosessin perimmäisenä tarkoituksena on päätyä asiakasvaatimuksista asiakasvaatimukset (ja tehdyt sopimukset) täyttävään ohjelmistoon. (Haikala ja Märijärvi, 1998 s. 77).

Kaiken tämän edellä mainitun varmistamiseen liittyviä toimenpiteitä kutsutaan yhteisellä nimellä vaatimustenhallinta. Vaatimustenhallinnan keskeisin tehtävä on varmistaa, että lopputuote vastaa asiakkaiden vaatimuksia. Lopputuotteessa on oltava kaikki halutut ominaisuudet ja vain ne. (Haikala & Märijärvi, 1998 s. 77).

Edellä mainitut kaksi kappaletta voivat tuntua ensilukemalta yksinkertaiselta ongelmalta. Käytännön ohjelmistotuotantoprojekteissa määrittelyvaiheessa laaditut määrittelydokumentit ovat harvoin lopullisia. Kyseisestä ongelmasta on todettu seuraavaa:
Kehitysprosessin aikana tapahtuvia vaatimusmuutoksia on luonnollisesti kaikin keinoin pyrittävä välttämään niiden aiheuttamista suurista lisäkustannuksista johtuen. Käytännössä on kuitenkin hyväksyttävä se, että kaikkia asiakasvaatimuksia ei voida mitenkään tuntea ja ymmärtää etukäteen kunnolla, ja vaikka tunnettaisiinkin, osa vaatimuksista muuttuu jo projektin aikana. (Haikala & Märijärvi, 1998 s. 78).

Määrittelyn kanssa yhteistä vaatimustenhallinnalla on määrittelydokumentit. Lyhyesti voidaan todeta, että määrittelytoiminto tuottaa määrittelydokumentit, ja vaatimustenhallintatoiminto ylläpitää ja korjaa määrittelydokumentteja.

Vaatimustenhallinnassa voidaan erottaa kaksi sisäistä päätoimintoa:
-	vaatimusten kehittäminen (requirements development)
-	vaatimusten johtaminen (requirements management).
(Wiegers 1999, s.19 vapaasti suomentaen).

Tässä tutkimuksessa en keskity vaatimusten kehittämiseen, eli vaatimusten etsimiseen, analysointiin, spesifiointiin ja todentamiseen. Tämän tutkimuksen lähtökohtana on, että vaatimusten kehittämisen seurauksena on johdettavaksi vaatimuksia.

Vaatimusten johtamisen kohdalla voidaan todeta olevan seuraavat osatoiminnot:
-	muutoshallinta (change control)
-	versionhallinta (version control)
-	vaatimusten seuranta (requirements tracing)
-	vaatimusten tilan seuranta (requirements status tracking).
(Wiegers 1999, s.268 vapaasti suomentaen).

Tämä tutkimus keskittyy muutostenhallintaa (change control), jonka voi todeta sisältävän seuraavat tehtävät:
-	muutosten ehdottaminen (proposing changes)
-	vaikutusten arviointi (analyzing impact)
-	päätösten tekeminen (making decisions)
-	viestintä (communication)
-	vaatimusten vakiintumisen seuranta (measuring requirements stability).
(Wiegers 1999, s.268 vapaasti suomentaen).

Muutoshallinnassa on tämän tutkimuksen keskeisimmät käsitteet. Keskeisintä muutoshallinnassa on päätösten tekeminen, jonka avuksi voidaan ottaa käyttöön menetelmiä ja välineitä. Tässä tutkimuksessa tutkittavana on myöhemmin esittelemäni äänestysjärjestelmä, joka on yksi päätöksenteon väline.

Käsitteellisen sekaannuksen välttämiseksi on eroteltava seuraavat käsitteet: määrittely, spesifikaatio / määrittelydokumentti, spesifiointimenetelmä, vaatimustenhallinta.

Määrittely on toiminto, jonka aikana voidaan käyttää monenlaisia spesifiointimenetelmiä, eli sama vaatimus voidaan etsiä hyvin erilaisilla tavoilla. Spesifiointimenetelmästä riippumatta itse spesifikaatio eli määrittelydokumentti voidaan laatia eri tavoilla. Vaatimustenhallinnassa käsitellään määrittelydokumentteja, vaatimustenhallinnan menetelmät ovat taas riippumattomia määrittelyn menetelmistä. Tämä voi tuntua akateemiselta käsitepyöritykseltä, mutta eri toiminnoilla on selkeät omat tehtävänsä, joita seuraava kaavio selkeyttää:

Kuva 1: Määrittelyn, spesifiointimenetelmän, määrittelydokumentin ja vaatimustenhallinnan suhteet kuvallisena kaaviona.

Määrittelydokumenttien dokumentointiin on olemassa erilaisia dokumenttimalleja, jotka ovat tämän tutkimuksen ulkopuolella. Samalla tavalla määrittelydokumenttien laatimisen prosessi on tämän tutkimuksen ulkopuolella. Edellä oleva kaavio osoittaa, että vaatimustenhallinta ja määrittely liittyvät kiinteästi toisiinsa, ja määrittelytoiminnosta tulee vaatimustenhallinnan käyttöön määrittelydokumentteja. Ohjelmistotuotannon muiden osa-alueiden ja vaatimustenhallinnan välille voidaan laatia vastaavanlaiset kaaviot, mikä on tämän tutkimuksen ulkopuolella.

14.1.2. Vaatimustenhallinnan päätösongelma

14.1.2.1. Päätösongelmista yleisesti ohjelmistotuotannon prosesseissa

Mäkäräinen (2000) on todennut, että muutoshallinta on yleisesti vaikea asia ohjelmistotuotantoprosessissa, ja hän on esitellyt monia erilaisia ongelmia. Tämän tutkimuksen kannalta oleellisimpia ovat Mäkäräisen (2000, s. 84.87, s. 90-91) toteamista ongelmista seuraavat:
-	päätöksenteko-ongelma (decision-making problem)
-	viestintäongelma (communication problem).
Molemmissa ongelmissa on kolme keskeistä kysymystä: kuka, miten, mitä ?

Jonkun henkilön on tehtävä päätöksiä jostain asiasta (kuka ja mitä). Tämä yksinkertaiselta kuulostava lause on kuitenkin lähdekirjallisuuden perusteella monesti vaikeasti toteutettavissa. Tämän tutkimuksen kannalta keskeinen kysymys on, miten vaatimustenhallinnan päätös tehdään. Päätöksenteon apuvälineenä voidaan käyttää monenlaisia (apu)välineitä.

Ohjelmistotuotannon päätöksentekoa leimaa epävarmuus ja päätöksien tekeminen epävarmuuden tilassa. Tästä asiasta on Humphrey (1989) todennut seuraavaa:
Unfortenately, in software development there are an enormous number of unknowns. Without some work we generally have no idea how much code a given function will require or how much effort it will take. What is worse, in many cases the software teams doesn´t even know how to go about finding out. Humphrey (1989, s.58).

14.1.2.2. Vaatimustenhallinnan päätösongelmista

Tämän tutkimuksen kannalta oleellista on tutkia erityisesti vaatimustenhallinnan päätösongelmia. Vaatimusten pysyvyydestä on Humphrey (1989, s. 25-27) todennut, että ohjelmistotuotteen vaatimukset harvoin pysyvät samoina, ja yleensä asiakas itsekään ei tiedä kaikkia vaatimuksia. Tämän seurauksena on ohjelmistotuotannon vaatimustenhallinnan erityispiirre on hallita muuttuvia vaatimuksia hallitusti ja järjestelmällisesti, ja kuvan 1 kohdat "muuttuneet / uudet vaatimukset" ja "uudelleenmäärittely" ovat keskeisiä kohtia vaatimustenhallinnassa.

Humphreyn (1989) väittämien tueksi on Kujalan ja Mäntylän (2000) raportoimat tutkimustulokset, kun tutkittavana on ollut käyttäjiä, joita on tutkittu erilaisilla menetelmillä. Oleellista tämän tutkimuksen kannalta on, että erilaisilla menetelmillä erilaisilla menetelmillä keskittyen erityisesti käyttäjien esittämiin vaatimuksiin ohjelmistotuotannon alkuvaiheessa, on silti havaittavissa monia vaatimusten muutostarpeita ohjelmistotuotannon jatkuessa.

14.1.2.3. Ohjelmistotuotannon päätöksenteon välineet

Edellä todetun perusteella on ymmärrettävää, että ohjelmistotuotannon avuksi on kehitetty erilaisia automatisoituja välineitä (automated tools). White (1982) esittelee yhden erityisen päätöksenteon välineen, jonka avulla on mahdollista seurata järjestelmällisesti kuinka ohjelmistotuotteen kehityksessä on tehty päätöksiä. Oleellista on, että Whiten (1982) esittämän järjestelmän avulla myös tehtyjen päätösten päätösvaihtoehdot säilyvät. Tämän tutkimuksen kannalta tärkeää on pohtia päätöksenteon välineiden käyttöä vaatimustenhallinnassa.

14.1.3. Vaatimustenhallinnan päätöksenteon väline

Vaatimukset eivät synny itsestään, jolloin syntyy tuotevaatimuksen päätösongelma (product requirement decision problems). Päätösongelmien ratkaisun apuna voidaan käyttää päätöksenteon välineitä (decision tools). Onko vaatimustenhallinnan päätöksenteon väline tärkeä ongelma? Tätä asiaa on pohtinut Jarmo Hurri (2000), ja tässä alaluvussa  on vain lyhyt referaatti hänen tutkimustuloksistaan.

14.1.3.1. Tuotevaatimuksen päätösongelma

Ohjelmistotuotteen vaatimuksen päätösongelmassa merkittävää on, että kaikki vaatimukset eivät ole yhtä oleellisia. Suurin ero fyysisen tuotteen ja ohjelmistotuotteen välillä on, että fyysisen tuotteen ominaisuudet ovat helpommin muutettavissa ovat helpommin muutettavissa määrällisiksi ja mitattaviksi vaatimuksiksi.

Koska vaatimuksia voi olla paljon, on vaatimukset käytävä läpi järjestelmällisellä tavalla, ja tehtävä päätökset määrätyllä prosessilla. Tällöin voidaan puhua päätösprosessista. Ohjelmistotuotannon perusongelma on, että päätöksiä tulee yleensä tehtäväksi paljon, jolloin etsitään apuvälinettä päätöksentekoon. Ohjelmistotuotannon päätösongelmat voi jakaa kahteen luokkaan: kaksijakoiset (binary) ja soviteltavat (adjustable).

Kaksijakoisissa ongelmissa päätös on kyllä tai ei, eli vaadittava ominaisuus on tai ei ole ohjelmistotuotteessa. Todellisuus ei ole kuitenkaan näin yksinkertainen, sillä ominaisuus voi olla tällä hetkellä tuntematon tai sen toteuttaminen voi olla siirretty tulevaisuuteen. Soviteltavissa ominaisuuksissa päätöksenteko on huomattavasti ongelmallisempaa. Koska ominaisuus on soviteltavissa, huolimatta yksimielisyydestä koskien ominaisuuden tarvetta, voi päätöksenteossa syntyä erimielisyyksiä ominaisuuden sisällöstä. Esimerkkinä voi olla ohjelmistotuotteessa maksimimäärä avoinna oleville dokumenteille, joka on täysin riippuvainen tehdystä päätöksestä.

14.1.3.2. Vaatimustenhallinnan päätöksenteon välineet

Hurri (2000) on käynyt tutkimuksessaan läpi kirjallisuutta, ja todennut ohjelmistotuotannossa vaatimustenhallintaan löytyvän erilaisia päätöksenteon välineitä. Hurri (2000) toteaa, että vaatimuksenhallinnan päätöksenteon välineitä on tutkittava, ja hän esittelee kehittelemänsä SATIRE-välineen. Koska kyseessä on uuden välineen esittely, toteaa Jarmo Hurri (2000) välineen vaativan useamman empiirisen kokeilun.

Tämä tutkimus ottaa Jarmo Hurrin (2000) tutkimustulokset peruslähtökohdaksi monella tapaa. Keskeistä on seuraava havainto päätösongelmasta:
Second, requirement decision problems are often group decision problems, possibly also negotiation, consensus or voting problems (Hurri 2000, s. 55).
Tutkimuksen peruslähtökohta on tämän vuoksi, että esiteltävässä äänestysjärjestelmässä on huomioitava äänestyksen lisäksi neuvottelu, konsensuksen hakeminen ja päätöksen tekeminen ryhmässä.

14.1.4. Keskeisten käsitteiden määrittely

Edellä olen esitellyt lyhyesti ohjelmistotuotannon ja vaatimustenhallinnan päätöksenteon, minkä voi tämän tutkimuksen kannalta tiivistää seuraavaan kaavioon:

Kuva 2: Vaatimustenhallinnan päätöksenteon keskeiset käsitteet ja käsitteiden suhde kuvallisena kaaviona.

Vaatimus: Tämä on keskeinen käsite, joka tarkoittaa ohjelmistotuotteelle esitettyä ominaisuutta, jota ei ole päätetty eikä toteutettu.
Päätös: Vaatimuksesta tulee ominaisuus, kun vaatimus on käsitelty ja päätökset ominaisuudesta on tehty.
Päätetyt ominaisuudet: Kun ominaisuus on päätetty ottaa ohjelmistotuotteen osaksi, voidaan puhua päätetyistä ominaisuuksista. Päätetyt ominaisuudet voi jakaa edelleen kaksijakoisiin ja soviteltaviin ominaisuuksiin. Osasta kaksijakoisia ominaisuuksia voi tulla seurauksena myös soviteltavia ominaisuuksia.
Muut ominaisuudet: Käsitellyt vaatimukset, joita ei ole päätetty ottaa ohjelmistotuotteen ominaisuuksiksi, voidaan luokitella hyvin monella tavalla. Tämän tutkimuksen kannalta oleellista on, että ne eivät ole ohjelmistotuotteen ominaisuuksia, kunnes toisin päätetään.
Toteutetut ominaisuudet: Ohjelmistotuotteen toteutus on vaatimustenhallinnan kanssa rinnakkainen prosessi, jonka tavoitteena on toteuttaa päätetyt ominaisuudet sisältävä ohjelmistotuote. Tämän tutkimuksen kannalta oleellista on, että päätetyt ominaisuudet ovat tuotantoprosessin lähtökohta.
Ohjelmistotuote: Tuotantoprosessin jälkeen ohjelmistotuote vastaa päätettyjä ominaisuuksia, eli käsiteltyjä ja hyväksyttyjä vaatimuksia.
Päätöksenteon väline: Päätöksenteon välineet ovat tekniikoita, joilla avustetaan päätöksentekoa analysoimalla tehtävän päätöksen rakennetta ja vaikutusta.

14.1.5. Yhteenveto johdannosta ja tutkimuksen rakenne

Johdannossa olen esitellyt kokonaisuuden, jossa on vähitellen siirrytty ohjelmistotuotantoprosessista vaatimustenhallintaan, joka on yksi ohjelmistotuotantoprosessin toiminto. Vaatimustenhallinnan toiminnon sisällä voidaan erotella erilaisia menetelmäryhmiä, joista yksi on päätöksenteon välineet. Tässä tutkimuksessa äänestysjärjestelmä on yksi kehiteltävä ja tutkittava päätöksenteon väline, ja on tutkimuksen kohde.

Luvussa 2 esittelen äänestysjärjestelmän, joka on teoreettisesti rakennettu päätöksenteon väline. Tämän tutkimuksen tehtävä on tutkia äänestysjärjestelmän käyttöä ohjelmistotuotantoprosessin vaatimustenhallinnan menetelmänä. Luvussa 3 esittelen tutkimuksen lähestymistavan ja tutkimusongelman osaongelmineen. Äänestysjärjestelmää voisi tutkia monesta näkökulmasta, ja luvussa 3 esittelen tähän tutkimukseen valitut näkökulmat.

Luvussa 4 esittelen äänestysjärjestelmää ohjelmistotuotanto-organisaation kannalta. Vastaavalla tavalla luvussa 5 on pohdintoja äänestysjärjestelmästä asiakasorganisaation kannalta. Luvussa 6 on käsiteltynä äänestysjärjestelmän käyttöä vaatimustenhallinnan johtamisessa, ja vastaavalla tavalla luvussa 7 on pohdintoja äänestysjärjestelmän käytöstä ohjelmistotuotantosopimuksessa. 

Luvussa 8 on yhteenveto luvuissa 2-7 löytyneistä hypoteeseista, ja arvioita jatkotutkimuksesta. Tutkimuksen tulokset ovat hypoteeseja esitetystä äänestysjärjestelmästä, joten hypoteesien käyttö todennettuina ilman empiiristä kokeilua on tämän tutkimuksen ulkopuolella.

14.2. Äänestysjärjestelmä

Tässä tutkimuksessa käsittelen päätöksenteon välinettä, jota kutsun äänestysjärjestelmäksi. Läpikäymässäni kirjallisuudessa ei ole mainintoja äänestysjärjestelmän käytöstä ohjelmistotuotannon vaatimustenhallinnan päätöksenteon välineenä. Tutkimusta varten olen laatinut äänestysjärjestelmästä kaavion, ja kaavion eri kohdille on perusteena kirjallisuusviitteitä eri lähteistä.

Kuva 3: Äänestysjärjestelmän kokonaisuus kuvallisena kaaviona.

14.2.1. Ohjelmistotuotantoprosessi

Äänestysjärjestelmien kannalta oleellinen asia on, että ohjelmistotuotantoprosessin prosessimallit ovat hyvin erilaisia, ja ohjelmistotuotantoprosessit voivat vaihdella myös saman organisaation sisällä. Ohjelmistotuotantoprosessin tutkiminen ja kehittäminen on Process Engineering -toiminto, kuten Marttiin (1998, s.52) toteaa. Tämä tutkimus ei kehitä ohjelmistotuotantoprosesseja kokonaisuutena Process Engineering -lähestymistavan mukaisesti, vaan vain ohjelmistotuotantoprosessin yhtä toimintoa.

Tutkimuksen rajoitteena on todettava, että äänestysjärjestelmän liittäminen ohjelmistotuotantoprosessin eri vaiheisiin on tämän tutkimuksen ulkopuolella. Äänestysjärjestelmän esittämiseen kaavion muodossa on kuitenkin edellä mainitun lähteen pohjalta perusteltua huomioida ohjelmistotuotantoprosessi, joka tuottaa vaatimusehdotuksia.

14.2.2. Uusi / muuttunut vaatimus (ehdotus)

Hurri (2000) toteaa vaatimuksista seuraavaa:
Product requirements are objectives which have been set for future releases of a product, and which are relevant to stakeholders outside the developing organisation (Hurri 2000, s.1).
Haikala ja Märijärvi (1998) toteavat vaatimusten muutoshallinnan olevan keskeinen osa vaatimustenhallintaa. Näiden lainauksien perusteella kaavioon huomioituna kohta "uusi / muuttunut vaatimus (ehdotus) " on perusteltua.

14.2.3. Vaatimusehdotuksen formalisointi

Monesti esitetty vaatimus on käytävä hyvin yksityiskohtaisesti läpi, jotta sekä vaatimuksen toteuttaja että vaatimuksen esittäjä ymmärtävät vaatimuksen samalla tavalla. Tätä prosessia voi kutsua määrittelyksi, mutta äänestysjärjestelmän kannalta oleellista on saada tarpeeksi yksityiskohtaisia ja määrämuotoisesti esitettyjä vaatimuksia käsiteltäväksi.

Empiiristen havaintojen mukaan (Ropponen, 1991 s. 91) jatkuva muutosten esittely on ohjelmistotuotantoprosessin suurin riskitekijä. Tämän riskin vähentämiseksi on perusteltua käsitellä vaatimuksia, eikä hyväksyä niitä sellaisenaan. Kaaviossa tämä on huomioituna vaatimusehdotusten formalisointi -kohdassa.

14.2.4. Formalisoitu vaatimusehdotus

Brooks (1975, s. 108) toteaa määrittelydokumenteista seuraavaa: ne ovat ensimmäisiä dokumentteja ehdotettaessa uutta tuotetta, ja viimeisiä dokumentteja viimeisteltäväksi. Vaikka lainattu lähde voi tuntua iäkkäältä, myös Haikala ja Märijärvi (1998, s. 51-52) toteavat hyvien määrittelydokumenttien ehdottoman tärkeän merkityksen ohjelmistotuotantoprosessille. Koska lainatuissa lähteissä suositellaan määrämuotoisia dokumentteja vaatimuksen esittämisestä alkaen, on tämä huomioitu kaaviossa kohtana "formalisoitu vaatimusehdotus".

14.2.5. Äänestys / ei

Onko kaikki vaatimusehdotukset vietävä äänestykseen? Koska aiemmin on todettuna, että päätöksenteon välineitä on useita, voidaan formalisoitu vaatimusehdotus käsitellä useammalla päätöksenteon välineellä. Brooks (1975, s. 68-69) esittää yhdeksi välineeksi puhelinlokia, jossa ohjelmistoarkkitehdit merkitsevä puhelimessa esitetyn kysymyksen ja antamansa vastauksen. Tämän tutkimuksen kannalta näin toimittaessa on tehty päätös, ja käytössä on ollut päätöksenteon väline. Tässä kohtaa tarkasti ottaen on päätettävä, mitä päätöksenteon välinettä käytetään vaatimusehdotuksen käsittelyssä. Tähän on viitannut myös Hurri (2000, s.70), ja hän toteaa päätöksentekijällä olevan käytössään monia erilaisia mahdollisia päätöksenteon välineitä.

Edellä mainittujen lainausten perusteella tässä kohtaa on tehtävä kaksi päätöstä:
-	mitä päätöksenteon välinettä käytetään?
-	päätös vaatimusehdotuksesta päätöksenteon välinettä käyttäen.

14.2.6. Vaatimuksen käsittely

14.2.6.1. Päätös vaatimuksesta ilman äänestystä

Koska vaatimusehdotusta voidaan käsitellä muullakin kuin äänestysmenettelyllä, on tämä huomioituna kaaviossa. Muut käsittelymenetelmät ovat tämän tutkimuksen ulkopuolella, mutta on hyvä tiedostaa muidenkin päätöksenteon välineiden olemassaolo.

14.2.6.2. Vaatimuksen käsittely äänestysmenettelyssä

Formalisoitu vaatimusehdotus ei mene suoraan äänestykseen, ja kaavion oletuksena on, että loppukäyttäjät saavat tiedon vaatimusehdotuksien eri vaihtoehdoista ja voivat keskustella eri vaihtoehdoista. Jotta loppukäyttäjät voivat keskustella eri vaatimusehdotuksen vaihtoehdoista, on vaihtoehdot eriteltävä ja esitettävä loppukäyttäjille. Aiemmin luvussa 1 olen todennut, että vaatimuksia on kahdessa pääryhmässä: kaksijakoiset ja soviteltavat.

Spinas et. al (1988) toteavat, että loppukäyttäjien osallistuminen ohjelmistotuotantoprosessiin on vaikeaa. Näitä syitä ovat mm. seuraavat:
-	käyttäjät osallistuvat liian myöhäisessä vaiheessa
-	ohjelmistosuunnittelijat aliarvioivat käyttäjien osuuden
-	käyttäjien ja suunnittelijoiden ajattelutavat eroavat
-	olemassa olevat välineet eivät tue käyttäjien ja suunnittelijoiden yhteistyötä.
Erityisesti Spinas et. al (1998) toteavat käyttäjien ja suunnittelijoiden välisen kommunikaation ongelmalliseksi. Eri vaihtoehtojen esittely ja hyväksyttäminen loppukäyttäjien äänestyksessä saa tästä lähteestä tukea osallistumisen vaatimuksilla.

Damoran et. al (1988) toteavat, että käyttäjien mukaan ottamisessa on kolme muotoa:
-	informoiva (informative)
-	konsultoiva (consultation)
-	osaaottava (participative).
Äänestysjärjestelmän luokittelen kohtiin 2 ja 3 kuuluvaksi, koska loppukäyttäjien äänestyksen tuloksena voidaan tehdä erilaisia päätöksiä: myönteisiä, kielteisiä tai tulevaisuuteen siirtyviä päätöksiä vaatimuksesta.

14.2.7. Loppukäyttäjien äänestys

Edellä olen lainannut kahta lähdettä, joissa todetaan loppukäyttäjien osallistumisen olevan tärkeää. Toisaalta tehtäviä päätöksiä on paljon ohjelmistoprojektien aikana. Tällöin äänestysjärjestelmän toteuttaminen tietoteknisin apuvälinein on perusteltua, jotta monet äänestykset voidaan suorittaa tarpeeksi tehokkaasti. Äänestysjärjestelmän kaavion kohdan "loppukäyttäjien äänestys" lähtökohtana on, että äänestyksen toteutuksessa on apuna jokin tietotekninen järjestelmä, jolloin loppukäyttäjien osallistuminen itse äänestykseen on tarpeeksi tehokasta turvaten samalla loppukäyttäjien osallistumisen.

14.2.8. Äänestystulosten käsittely, päätökset

Wiegers (1999, s. 283) toteaa, ettei pelkkä esitetty vaatimus takaa, että vaatimus todella toteutetaan. Wiegers (1999, s. 290) esittelee muutoksenhallintaryhmän (change control board, CCB) ja muutoksenhallintaryhmän tehtävät. Oleellisinta on, että kaikki esitetyt vaatimukset alistetaan muutoksenhallintaryhmälle päätettäväksi. Äänestysjärjestelmän kaaviossa on muutoksenhallintaryhmä tai vastaava päätöksiä tekevä toimielin kohdissa "äänestystuloksen käsittely, päätökset" ja "päätös vaatimuksesta ilman äänestystä".

14.2.9. Tiedotus loppukäyttäjille

Wiegers (1999) toteaa, että muutoshallinnan keskeinen osa on viestintä. Toisaalta Spinas et. al (1988) toteavat loppukäyttäjien osallistumisen olevan tärkeä osa ohjelmistotuotantoprosessin onnistumiselle.

Äänestysjärjestelmän kaaviossa loppukäyttäjille tiedotusta on kolmessa kohtaa: äänestysvaihtoehtojen tiedotus, äänestystuloksen tiedotus, päätöksen tiedotus. Lisäksi erityinen kohta tiedottamisessa on äänestykseen liittyvä keskustelu, jolloin loppukäyttäjillä on mahdollisuus arvioida esitettyjä vaihtoehtoja omalta kannaltaan. Hurri (2000, s. 55) totesi äänestyksen lisäksi olevan mahdollista neuvottelun ja konsensuksen hakemisen. Esittämässäni äänestysjärjestelmän kaaviossa ennen ja jälkeen varsinaisen äänestyksen on neuvottelua ja konsensuksen hakemista äänestykseen liittyvässä keskustelussa sekä päätöksen tekemisessä äänestyksen jälkeen.

14.2.10. Formalisoidut vaatimukset

Tämän tutkimuksen lähtökohta on, että vaatimustenhallinnan menetelmänä äänestysjärjestelmä tuottaa hyväksyttyjä määrittelydokumentteja. Kaaviossa käsitteenä on formalisoidut vaatimukset, mikä tarkoittaa vaatimusta, joka on käynyt läpi formalisointiprosessin äänestysmenettelyssä. Lopputuloksena on hyväksytty määrittelydokumentti ohjelmistotuotantoprosessin muiden toimintojen käyttöön.

Määrittelydokumenttien luonteesta on mainittu kirjallisuudessa seuraavaa: yksiselitteisyys, täydellisyys, ristiriidattomuus, todennettavuus, muutettavuus, jäljitettävyys, käyttökelpoisuus ylläpidon aikana (vapaasti suomentaen, Icelandic Council for Standardization , MSQH 1991).

Tämän tutkimuksen kannalta jäljitettävyys on äärimmäisen tärkeä kohta. Määrittelydokumenteista ja äänestysjärjestelmistä ei ole hyötyä, jos äänestyksen läpikäyneet vaatimukset eivät tule kirjatuksi määrittelydokumentteihin. Käytännössä tämä tarkoittaisi tilannetta, jossa samaa vaatimusta voidaan viedä äänestysmenettelyyn useamman kerran tai samasta vaatimuksesta tehdään erilainen päätös jollain muulla tavalla.

14.3. Äänestysjärjestelmä tutkimuskohteena

14.3.1. Tutkimuksen lähestymistapa 

Edellä esitetty äänestysjärjestelmä on kokeellinen teoreettinen rakennelma, jonka yksittäiset osat saavat tukea yksittäisistä lähteistä. Äänestysjärjestelmä kokonaisuutena ei saa tukea mistään lähteestä, mutta ei myöskään vastustusta. Äänestysjärjestelmän testaaminen käytännössä olisi yksi mahdollinen tutkimuksen lähestymistapa, eli tutkimus jatkuisi empiirisellä osuudella. Tutkimukselle on monia muitakin lähestymistapoja, kuten P. ja A. Järvinen (2000) osoittavat omassa teoksessaan.

Tämä tutkimus on P. ja A. Järvisen (2000, s. 9) luokituksen mukaisesti käsitteellis-teoreettinen tutkimus. Käsitteellis-teoreettisessa tutkimuksessa on kaksi päätapaa:
-	deduktiivinen (aksioomasta teoriaan)
-	induktiivinen (yksittäisistä tutkimuksista yleistyksiin).
Tämä tutkimus on induktiivinen, eli edellä esitetty äänestysjärjestelmä on tukeutunut aiempiin tutkimuksiin.

14.3.2. Äänestysjärjestelmä prosessina

Tämän tutkimuksen keskeisin näkökulma on tarkastella äänestysjärjestelmää prosessina. Kuvassa 3 on esitetty äänestysjärjestelmän kokonaisuus kuvaa prosessia, jossa on käytössä jokin tietotekninen äänestysväline kohdassa "loppukäyttäjien äänestys". Prosessinäkökulman mukaisesti äänestysväline on osa kokonaisjärjestelmää.

Liiketoimintaprosesseista on Hannus (1997) todennut seuraavaa:
[1] Prosessilla on aina asiakas, joka saa sille määrätyn lopputuloksen, asiakas voi olla yrityksen sisäinen tai ulkoinen.
[2] Prosessit ylittävät organisatoriset rajat, ja ovat yleensä riippumattomia organisaatiorakenteista.
[3] Prosessien suorituskykyä tulee arvioida aina asiakkaan (sisäinen tai ulkoinen) näkökulmasta.
Hannus (1997, s.41).
Kun äänestysjärjestelmää tarkastellaan (liiketoiminta)prosessina, voi prosessia tarkastella monesta näkökulmasta, ja prosessiajattelun voima onkin sen mahdollisuudessa tarkastella prosessia monesta eri näkökulmasta.

14.3.3. Tutkimusongelma

Tässä tutkimuksessa lähestyn äänestysjärjestelmää prosessina erilaisista näkökulmista aikaisempien tutkimustulosten perusteella, ja seuraava kaavio kuvaa näkökulmia.

Kuva 4: Tutkimuksen näkökulmat tutkimuskohteeseen kuvallisena kaaviona

Tämän tutkimuksen näkökulmat ja samalla tutkimuksen osaongelmat ovat seuraavat:
1.	äänestysjärjestelmä loppukäyttäjien organisaation kannalta
2.	äänestysjärjestelmä ohjelmistotuotanto-organisaation kannalta
3.	äänestysjärjestelmä osana ohjelmistotuotantosopimusta
4.	äänestysjärjestelmä ohjelmistotuotantoprosessin johtamisen kannalta.

Äänestysjärjestelmää on mahdollista lähestyä edellä mainittujen lisäksi monesta muusta näkökulmasta, joten yhtenä osaongelmana on seuraava:
5.	mitä muita näkökulmia äänestysjärjestelmään löytyy tutkimuksen aikana?

Edellä olevat osaongelmat ovat osa kokonaisongelmaa, joka on seuraava:
tutkimuksen ongelmana on etsiä esitetystä äänestysjärjestelmästä erilaisista näkökulmista hypoteeseja empiiristä testausta varten.

Tutkimustuloksena saatavilla hypoteeseilla myöhemmin tehtävät tutkimukset voivat suuntautua testaamaan esitettyjä hypoteeseja, jolloin voidaan siirtyä P. ja A. Järvisen (2000) esittämällä tavalla siirtyä muihin tutkimusotteisiin.

14.3.4. Tutkimuksen rajauksia

Tässä tutkimuksessa on seuraavia keskeisiä rajauksia:
1.	Ohjelmistoprosessi kokonaisuutena on tämän tutkimuksen ulkopuolella.
2.	Samoin kuin Hurri (2000) on rajannut, tässäkään tutkimuksessa ei käsitellä vaatimusten etsimistä, joka on laaja ja mielenkiintoinen osa-alue.
3.	Tässä tutkimuksessa käsitellään vain äänestysjärjestelmää päätöksenteon välineenä, ja muut päätöksenteon välineet ovat tämän tutkimuksen ulkopuolella.

Marakas ja Elam (1998) toteavat, että vaatimustenhallinta on oleellisempi osa ohjelmistotuotantoprosessia kuin valittu prosessimalli, joten ohjelmistotuotannon prosessimallin rajaaminen pois tästä tutkimuksesta on perustelua, jolloin keskitytään oleellisempaan ongelma-alueeseen.

Kuvasta 4 ilmenee tämän tutkimuksen keskeisin rajaus, eli äänestysjärjestelmää arvioidaan ohjelmistotuotantoprosessissa, jossa on selkeästi eroteltavissa asiakas (tilaaja, käyttäjä) ja toimittaja eli ohjelmistotuotanto-organisaatio. Tämän perusteella tämä tutkimus ei ota kantaa, voidaanko äänestysjärjestelmää käyttää ohjelmistotuotantoprosesseissa, joissa tuote valmistetaan ilman asiakkaiden laajaa osallistumista. Heiskanen (1994) on jakanut ohjelmistotuotannon kolmeen ryhmään:
1.	sisäiseen ja asiakkaan omaan tuotantoon (in-house and custom development)
2.	sopimustuotantoon (contractual development)
3.	ohjelmistotuotteiden tuotantoon (software product development).
Heiskanen (1994, s. 109 vapaasti suomentaen).
Tämä tutkimus keskittyy kohtien 1 ja 2 mukaisiin ohjelmistotuotantoprosesseihin, joissa on selkeästi eroteltavissa asiakas- ja ohjelmistotuotanto-organisaatio koko ohjelmistoprojektin ajan.

14.3.5. Tutkimusalueen merkittävyydestä

Ennen siirtymistä varsinaisiin tutkimustuloksiin on syytä pysähtyä hetkeksi vaatimustenhallinnan tärkeyteen. Edellä lainattu Ropponen (1997) totesi jatkuvasti muuttuvat vaatimukset ohjelmistotuotantoprosessin suurimmaksi riskiksi. Wiegers (1999, s. 5.) toteaa, että 40-60 % ohjelmistoprojektien virheistä voidaan jäljittää huonosti hoidettuun vaatimustenhallintaa. Lisäksi alan perusoppikirja (Haikala ja Märijärvi, 1998) toteaa, ettei vaatimustenhallintaan yleensä kiinnitetä riittävästi huomiota. Hurri (2000) toteaa, ettei vaatimustenhallinnan päätöksenteon välineitä ole tutkittu liikaa, jolloin on perusteltua tutkia vaatimustenhallinnan päätöksenteon välinettä.

Miksi yleensä ottaen edes tutkia äänestysjärjestelmiä? Tämä kysymys on osa ohjelmistotuotannon laajempaa ongelmaa, johon on kiinnitetty huomiota pitkään, eli ohjelmiston tulevan käyttötilanteen määrittelyn vaikeuden ongelmat. Järvinen (1991, s. 34-43) on pohtinut erilaisia määrittelyongelmia pidemmällä aikavälillä, ja todennut ongelman olevan todellinen erityisesti laajoissa järjestelmissä. Tämän tutkimuksen yhtenä perusteena on tällöin tutkia äänestysjärjestelmän käytön mahdollisuuksia apuvälineenä tämän ongelman hallintaan.

14.4. Äänestysjärjestelmä ohjelmistotuotanto-organisaation kannalta

Tämän tutkimuksen ongelman kannalta vaatimuksista päättäminen vaatii etsimistä vaatimustenhallinnan muiden aiheiden joukosta. Yleisesti ottaen vaatimusten etsiminen on toiminto, johon on kehitetty lukuisia määrä erilaisia menetelmiä.

Äänestysjärjestelmän kannalta ovat Robertson ja Robertson (1999) maininneet seuraavia asioita vaatimuksista ja päättämisestä: vaatimuksen ja ratkaisun ero, ylimääräiset ja uudet vaatimukset.

Sommerville ja Sawyer (1997) ovat todenneet seuraavia kohtia: vaatimuksista neuvottelu, ristiriitaiset vaatimukset, ristiriidat ja niiden käsittely, päätöksenteon järjelliset perusteet, organisaatioiden erot sisäisesti ja ulkoisesti. Ohjelmistotuotantoa oppimisprosessina korostavat Robillard (1999) sekä Tervonen ja Kerola (1998). On selvää, että laajempi kirjallisuuskatsaus tuottaisi lisää uusia kohtia arvioitaessa äänestysjärjestelmää ohjelmistotuotanto-organisaation kannalta.

14.4.1. Vaatimuksen ja ratkaisun ero

Robertson ja Robertson (1999, s. 192-193) toteavat, että vaatimuksen ja ratkaisun välillä on huomattava ero. Vaatimus on ilmaus tarpeesta tai ominaisuudesta, joka on olennainen ohjelmistotuotteen käyttäjän kannalta. Ratkaisu on puolestaan ohjelmistotuotteeseen ohjelmoitu, ja saman vaatimuksen toteuttamisessa voi olla useita vaihtoehtoja. Tässäkin kohtaa on käsitteellinen erottelu tärkeää, sillä Robertson ja Robertson (1999) ottavat esimerkiksi luottamuksellisten tietojen käsittelyn ohjelmistotuotteessa. Luottamuksellisten tietojen käsittelyyn on kehitetty useita erilaisia menetelmiä, joten kyseisen vaatimuksen toteuttamiseen on useita erilaisia vaihtoehtoja. 

Äänestysjärjestelmän kannalta tämä on tärkeä kohta, ja tutkimuksen tuloksena voi esittää seuraavat hypoteesit.
Hypoteesi:
Äänestysjärjestelmän avulla voidaan erotella esitetyt vaatimukset ja ratkaisut toisistaan.
Hypoteesi:
Äänestysjärjestelmän avulla voidaan erotella erilaisten ratkaisujen kannatus, joilla ratkaistaan samaa vaatimusta.

14.4.2. Ylimääräiset ja uudet vaatimukset

Robertson ja Robertson (1999, s. 194-198) ovat pohtineet uusia ja ylimääräisiä vaatimuksia vaatimustenhallintaprosessin kannalta. Näilläkin vaatimuksilla on jälleen selkeä käsitteellinen ero. Uusi vaatimus on asiakkaan todella esittämä vaatimus, mutta kesken ohjelmistotuotantoprosessin. Ylimääräinen vaatimus on vaatimus, jonka toteuttaminen voi olla asiakkaalle ylimääräinen mukava lisäominaisuus, mutta ei välttämätön.

Sekä uusien että ylimääräisten vaatimusten osalta äänestysjärjestelmän oletuksia on seuraava:
Hypoteesi:
Äänestysjärjestelmän avulla voidaan selvittää esitetyn vaatimuksen todellinen kannatus.

14.4.3. Vaatimuksista neuvottelu

Edellä on mainittu useampi lähde, jossa todetaan vaatimusten kehittyvän ohjelmistotuotantoprosessin aikana. Monesti mukana on useita käyttäjiä, ja käyttäjien mukaan ottamista on yleisesti kannatettu monessa lähteessä. Ongelmaksi voi muodostua käyttäjien määrä, jolloin ohjelmistotuotanto-organisaatio ei välttämättä pysty keskustelemaan tehokkaasti kaikkien käyttäjien kanssa. Vaatimuksista neuvottelua on yleisemmin pohtinut Sommerville ja Sawyer (1997, s.385-386).

Äänestysjärjestelmän käyttö ohjelmistotuotanto-organisaation kannalta voi tarkoittaa tilannetta, jossa loppukäyttäjiä on jaoteltu erilaisiin ryhmiin. Äänestysjärjestelmän avulla laajempi joukko loppukäyttäjiä voi olla edustettuna, ja pienempi joukko käyttäjiä neuvottelee aktiivisemmin ohjelmistotuotanto-organisaation kanssa. Tämä on olettamaa, joten tutkimuksen tuloksena voi esittää seuraavat hypoteesit:
Hypoteesi:
Äänestysjärjestelmän avulla loppukäyttäjät voivat olla laajemmin edustettuna.
Hypoteesi:
Äänestysjärjestelmän avulla loppukäyttäjiä voidaan jakaa tarkoituksenmukaisiin ryhmiin ohjelmistotuotanto-organisaation kannalta.

14.4.4. Ristiriitaiset vaatimukset

On mahdollista, että ohjelmistotuotantoprosessin aikana esitetään ristiriitaisia vaatimuksia. Tähän on varmasti monia syitä, jotka riippuvat aina kyseisestä tapauksesta. Ohjelmistotuotanto-organisaation kannalta ristiriitaiset vaatimukset tarkoittavat, että asiakas ei ole täysin ymmärtänyt esittämien vaatimusten ristiriitaisuutta. Sommerville ja Sawyer (1997, s.94-98) esittävät huonosti ymmärrettyjen vaatimusten laatimista prototyypiksi.

Äänestysjärjestelmän käytön kannalta on mahdollista esittää peräkkäin kaksi ristiriitaista vaatimusta, ja selvittää käyttäjien kannatus vaatimuksille. Erilaisia vaihtoehtoja voivat olla vaatimusten näennäinen ristiriidattomuus asiakkaan kannalta, tai jokin muu syy. Koska tämä on vain olettamaa, on tutkimuksen tuloksena seuraava hypoteesi:
Hypoteesi:
Äänestysjärjestelmän avulla voidaan selvittää ristiriitaisia vaatimuksia ohjelmistotuotanto-organisaation kannalta.

14.4.5. Ristiriidat ja niiden käsittely

Sommerville ja Sawyer (1997, s.125-127) toteavat, että ohjelmistotuotantoprosesseissa voi syntyä ristiriitoja. Ohjelmistotuotanto-organisaation kannalta asiakasorganisaation sisäisten ristiriitojen ratkaisu on vaikea tehtävä. Tässä tutkimuksessa olettamana on, että asiakasorganisaation sisäisten ristiriitojen ratkaisu kuuluu asiakasorganisaatiolle, ei ohjelmistotuotanto-organisaatiolle. Ohjelmistotuotanto-organisaatio voi kyllä osoittaa ristiriidat ja auttaa niiden ratkaisussa, mutta lopullinen ratkaisu on oletusarvoisesti asiakasorganisaatiolla.

Äänestysjärjestelmän hyväksikäytössä ristiriitojen ratkaisussa tämä tutkimus esittää seuraavat hypoteesit:
Hypoteesi:
Äänestysjärjestelmän avulla voidaan osoittaa asiakasorganisaation sisäisiä ristiriitoja.
Hypoteesi:
Äänestysjärjestelmä voi olla avuksi asiakasorganisaation sisäisten ristiriitojen ratkaisussa.

14.4.6. Päätöksenteon järjelliset perusteet

Tämä tutkimus ei ota kantaa, onko ihmisten toiminta yleisesti ottaen järjellistä vai ei. Tämän tutkimuksen kannalta on tärkeää, että ihmiset voivat perustella tekemiään päätöksiä perusteilla, joita he pitävät järjellisinä. 

Tähän ongelma-alueeseen Sommerville ja Sawyer (1997, s.87-89) ovat esittäneet erilaisia näkökohtia. Äänestysjärjestelmän kannalta on mahdollisuus, että loppukäyttäjillä on vaatimuksilleen perusteet, joita he pitävät järjellisinä. Koska ohjelmistotuotanto-organisaatio oppii nämä perusteet ohjelmistotuotantoprosessin aikana on tähän hyvä olla jokin väline. Tämän tutkimuksen kannalta tuloksena äänestysjärjestelmistä on seuraava hypoteesi:
Hypoteesi:
Äänestysjärjestelmä auttaa ohjelmistotuotanto-organisaatiota löytämään asiakasorganisaation vaatimuspäätösten perusteet.

14.4.7. Organisaatioiden erot sisäisesti ja ulkoisesti

Ohjelmistotuotanto-organisaatioiden kannalta asiakkaina voi olla useita erilaisia asiakasorganisaatioita. Sommerville ja Sawyer (1997, s.69-71) ovat kiinnittäneet huomiota organisaatioiden välisiin eroihin, eli ns. organisaatiokulttuurin eroihin. Lisäksi laajemmassa organisaatiossa voi olla sisäisiä eroja organisaation eri osien välillä.

Ohjelmistotuotanto-organisaatioille tämä voi tarkoittaa tilannetta, jossa esitetyt vaatimukset ovat erilaisia riippuen esittäjästä. Äänestysjärjestelmän käytön kannalta tämä tarkoittaisi mahdollisuutta erotella erilaisten organisaatioiden ja organisaatioiden osien vaatimusten eroja ja yhtäläisyyksiä. Edellä olevan perusteella tutkimustuloksena on seuraava hypoteesi:
Hypoteesi:
Äänestysjärjestelmän avulla on mahdollista erottaa erilaisista organisaatiokulttuureista johtuvat erilaiset vaatimukset.

14.4.8. Äänestysjärjestelmä ohjelmistotuotanto-organisaation oppimisen kannalta

Tervonen ja Kerola (1998) esittelevät viisi erilaista näkökulmaa ohjelmistojen laatuun:
-	tuotenäkökulman (product view)
-	tuotantonäkökulman (manufacturing view)
-	käyttäjänäkökulman (user view)
-	lisäarvonäkökulman (value for money view)
-	henkisen näkökulman (transcendental view).
Ohjelmistotuotanto-organisaation kannalta tuote- ja tuotantonäkökulma ovat oletettavasti tuttuja näkökulmia. Muut näkökulmat ovat opittavissa, mutta ne vaativat aikaa, menetelmiä ja oppimista. Robillard (1999) toteaa ohjelmistotuotantoprosessin olevan tietämyksen kiteytymistä ohjelmistotuotantoprosessin aikana.

Oppimisnäkökulmasta tämän tutkimuksen tuloksena voi esittää seuraavan hypoteesin:
Hypoteesi:
Äänestysjärjestelmä auttaa ohjelmistotuotanto-organisaatiota näkemään muitakin näkökulmia kuin tuote- ja tuotantonäkökulman.

14.5. Äänestysjärjestelmä asiakas-organisaation kannalta

Edellä on käynyt ilmi, että ohjelmistotuotanto on jatkuvaa päätösten tekemistä, ja ohjelmistotuotanto-organisaatio muuttaa tehdyt päätökset ohjelmistotuotteiksi. Periaatteessa tämä on yksinkertaista, mutta päätöksenteko asiakasorganisaation sisällä voi olla ohjelmistotuotanto-organisaation kannalta käsittämätöntä tai epäselvää.

Päätöksenteon käsittämättömyys tulee esille, koska verrattuna moneen muuhun normaaliin toimintaan ohjelmistotuotannossa on tehtävä paljon enemmän päätöksiä samassa ajassa. Asiakasorganisaation kannalta tämä tarkoittaa normaalin päätöksentekojärjestelmän kuormittamista ohjelmistotuotetta koskevalla päätöksillä. 

Tämän tutkimuksen kannalta oleellista on, miten päätökset tehdään. Asiakasorganisaation kannalta ohjelmistotuote on vain yksi väline organisaation perustehtävän suorittamiseen, ja asiakasorganisaatio on tehnyt päätöksen hankkia ohjelmistotuote. Huomionarvoista on, että päätökset hankkia ohjelmistotuote ja päätökset ohjelmistotuotteen toteutuksen aikana tapahtuvat eri tavalla. Päätöksenteon luonnetta eri vaiheissa on pohtinut tarkemmin Finkelstein (1989), kun hän on pohtinut strategisten päätösten toteuttamista tietoteknisiksi järjestelmiksi.

Tämän tutkimuksen kannalta oleellinen havainto on, että vaatimustenhallinta alkaa, kun strategiset päätökset on tehty ja strategian mukainen ohjelmistotuotteen toteutus alkaa. Monesti strategiaan kuuluu, että ohjelmistotuote toteutetaan ulkopuolisella ohjelmistotuotanto-organisaatiolla. Vasta tässä vaiheessa ohjelmistotuotanto-organisaatio alkaa, ja monesti tarjouskierroksen jälkeen.

Edellä olevan perusteella tämä tutkimus tekee seuraavat rajaukset:
Äänestysjärjestelmän käyttö asiakasorganisaation strategisessa suunnittelussa on tämän tutkimuksen ulkopuolella.
Ohjelmistotuotanto-organisaation vaikutus asiakasorganisaation strategisiin päätöksiin on tämän tutkimuksen ulkopuolella.

Finkelsteinin (1989) teos on erityistapaus organisaatioiden sisäisestä päätöksenteosta. Tämän tutkimuksen lähtökohtana on , että asiakasorganisaatio on tehnyt useita ns. normaaleja päätöksiä, jotka eivät koske ohjelmistotuotteita. Organisaatioiden päätöksentekoa ovat tutkineet yleisemmin Heller et al. (1988), ja äänestysjärjestelmän kannalta organisaatioiden päätöksenteossa on mielenkiintoista:
-	valta organisaatioissa
-	eritasoiset päätökset
-	päätöksentekotasot
-	päätöksentekoon osallistuminen.

14.5.1. Äänestysjärjestelmä päätöksentekovallan kannalta

Jollain henkilöllä tai henkilöiden ryhmällä asiakasorganisaatiossa on oikeus tehdä päätöksiä. Heller et al. (1988, s. 12-18) toteavat, että päätöksentekovallalla kehitellään erilaisia nimikkeitä, jotka peittävät lopullisen tosiasian: jollain henkilöllä on enemmän päätöksentekovaltaa kuin toisilla.

Edellä olen todennut, että ohjelmistotuotteen teettäminen ohjelmistotuotanto-organisaatiolla on strateginen päätös. Kun ohjelmistotuotetta ryhdytään toteuttamaan, jossain vaiheessa käyttäjät osallistuvat enemmän tai vähemmän ohjelmistotuotantoon. Heiskanen (1994, s. 107-121) on kiinnittänyt huomiota, kuinka joku henkilö voi toimia käyttäjien ja ohjelmistotuotanto-organisaation välissä eräänlaisena portinvartijana (gatekeeper). Alkaen strategisten päätöksen toteuttamisesta portinvartijoiden rooli muuttuu, varsinkin ohjelmistotuotteen toteutusvaiheessa.

Organisaatioiden normaalin valtarakenteen kannalta tämä on poikkeava tilanne, koska ohjelmistotuotannon ajan asiakasorganisaation kannalta ongelmaksi muodostuu ohjelmistotuotannon erityispiirre, eli jatkuvasti tehtävät pienet päätökset. Heiskanen (1994) toteaa portinvartijan roolin muuttuvan ongelmalliseksi, koska hänen pitäisi pystyä käsittelemään suuri joukko päätöksiä vaatimuksista, varsinkin niiden muutoksista, ja käsittelemään päätöksiä sekä ohjelmistotuotanto-organisaation että asiakasorganisaation kannalta.

Näiden ongelmien ratkaisemiseksi tämä tutkimus esittää seuraavat hypoteesit:
Hypoteesi:
Äänestysjärjestelmän avulla asiakasorganisaation päätöksentekijät pystyvät seuraamaan tehokkaammin vaatimukseen vaikuttavia osatekijöitä ennen varsinaista päätöstä.
Hypoteesi:
Äänestysjärjestelmä helpottaa portinvartijan roolissa olevan asiakasorganisaation päätöksentekijän työskentelyä.

14.5.2. Päätöksentekotasot

Heller et al. (1988, s. 162-165) toteavat, että ennen lopullista päätöstä päätettävää asiaa voidaan käsitellä useammalla organisaatiotasolla. Ohjelmistotuotannon kannalta vaatimusten muuttuminen voi tarkoittaa, että myös vaatimuksen muutosta joudutaan käsittelemään useammalla organisaatiotasolla. Ongelmaksi muodostuu tällöin päätöksentekoon käytettävä aika; Heller et al. (1988) osoittavat muutamalla esimerkillä, että riippuen asian laajuudesta päätettävän asian läpikäynti kestää eripituisia aikoja, esimerkiksi kahdesta kuukaudesta kahteen vuoteen.

Ohjelmistotuotannon kannalta muuttuvan vaatimuksen käsittely normaalilla päätöksentekomenettelyllä voi olla liian hidasta. Tämän ongelman ratkaisemiseksi äänestysjärjestelmä voi olla osaratkaisu, ja tutkimuksen tuloksena on seuraavat hypoteesit:
Hypoteesi:
Äänestysjärjestelmän avulla voidaan nopeuttaa asiakasorganisaation normaalia päätöksentekoa koskien ohjelmistotuotteen vaatimuksia.
Hypoteesi:
Äänestysjärjestelmän avulla useammat organisaatiotasot voivat osallistua samanaikaisesti päätöksentekoon.

14.5.3. Päätöksentekoon osallistuminen

Monessa lähteessä on mainittu käyttäjien osallistuminen ohjelmistotuotteen kehittämiseen. Jos ohjelmistotuotantoprosessia tarkastelee muutosprosessina asiakasorganisaation kannalta, avaa tämä monia mielenkiintoisia näkökulmia myös äänestysjärjestelmään.

Monesti tietoteknisen järjestelmän hankkiminen tai teettäminen on osa strategisen päätöksen mukaista muutosprosessia. Organisaation kokonaissuorituksen kannalta strategisen päätöksen tekijät voivat todeta muutoksen vaativan yhtenä osana tietoteknistä järjestelmää.

Valitun tietoteknisen muutoksen läpiviemiseksi on monesti perusteltua ottaa mukaan myös loppukäyttäjiä. Tähän on kiinnittänyt huomiota Pettigrew (1980), joka on todennut muutoksien läpivientiin liittyvän monia poliittisia ilmiöitä, tarkasti ottaen Pettigrew kirjoittaa intressiryhmistä.

Intressiryhmien kannalta muutos luo epävarmuutta, koska intressiryhmillä ei ole ennen muutosta ja muutoksen aikana käsitystä omasta asemastaan muutoksen jälkeen. Tämän perusteella Hellerin et al. (1988, s. 18-21) pohdinnat osallistumisesta päätöksentekovallan vaihtoehtona on ymmärrettävää. Lyhyesti ja yksinkertaisesti erilaiset intressiryhmät voivat osallistua itse muutokseen, vaikka päätös muutoksesta on ei olekaan intressiryhmien itsensä tekemä.

Äänestysjärjestelmän kannalta voidaan tehdä seuraava hypoteesi:
Hypoteesi:
Äänestysjärjestelmän avulla voidaan asiakasorganisaation erilaiset intressiryhmät saada mukaan viemään läpi tietoteknistä muutosta.

Heller et al. (1988) toteavat, että erilaisten ryhmien osanotto antaa mahdollisuuden tuoda osallistuvien henkilöiden osaamista mukaan päätöksentekoon. Koska ohjelmistotuotteen vaatimukset ovat muuttuvia huolimatta alkuvaiheen tarkastakin määrittelystä, on loppukäyttäjien asiantuntemuksen käyttö perusteltua asiakasorganisaation muutosprosessin läpiviennin kannalta sekä ohjelmistotuotantoprosessin kannalta. Tämän perusteella tämän tutkimuksen esittämä hypoteesi on seuraava:
Hypoteesi:
Äänestysjärjestelmän avulla voidaan hyödyntää paremmin loppukäyttäjien osaamista.

14.6. Äänestysjärjestelmä osana vaatimustenhallinnan johtamista

Johtaminen ei ole yksiselitteinen ilmiö. Tätä tutkimusta varten läpikäyty kirjallisuus osoittaa, että johtaminen on jakautunut hyvin erilaisiin lähestymistapoihin.

Vaikka tämän tutkimuksen keskeinen lähestymistapa on ajatella äänestysjärjestelmää prosessina, on prosesseihinkin hyvin monenlaisia lähestymistapoja. Hannus (1997) esittelee prosessijohtamisen sisällä kuusi erilaista koulukuntaa. Suomi (1992) toteaa tietohallinnon johtamiseen olevan kahdeksan erilaista paradigmaa.

Erityinen ongelma on ohjelmistotuotannossa on johtaa ihmisten tietämystä ja osaamista. Tästä Sydänmaalakka (2000) toteaa seuraavaa:
Meillä on uusi haaste edessämme: miten voimme johtaa tai hallita sitä valtavaa tietomäärää, joka on nykyisin kaikkien saatavilla. (Sydänmaalakka, 2000 s. 164).

Johtamisen moninaisuuden perusteella voi tehdä seuraavan hypoteesin:
Hypoteesi:
Äänestysjärjestelmään johtamisen apuvälineenä otetaan hyvin monenlaisia lähestymistapoja.

Tehty hypoteesi voi tuntua itsestäänselvyydeltä, mutta sitä se ei kuitenkaan ole. Suomi (1992) toteaa tämän tutkimuksen kannalta hyvänä esimerkkinä:
Olipa tietojenkäsittelyn ongelmakenttä millainen tahansa, liian usein tietohallintojohtajat pyrkivät toteuttamaan yhtä ja samaa johtamistapaa - tapaa, joka on kerran opittu, ja joka ei välttämättä ole menestynyt missään. (Suomi, 1992 s. 13).
Tämän perusteella äänestysjärjestelmään voidaan ottaa monenlaisia lähestymistapoja, mutta näkökulman vaihtaminen äänestysjärjestelmän itsensä vuoksi on vaikeasti ennustettavissa.

Tämän perusteella äänestysjärjestelmään otetaan monenlaisia näkökulmia, mutta herkästi jokaisen näkökulman edustaja katsoo äänestysjärjestelmää vain omasta näkökulmastaan. Suomen (1992) ja Hannuksen (1993) teokset pyrkivät ylittämään erilaisten näkökulmien rajoja ja tarkastelevat johtamista moniulotteisena ilmiönä. Molempien teoksien päätelmänä voi todeta, että yksittäistä johtamisen apuvälinettä voidaan käyttää hyvin eri tavalla erilaisissa tilanteissa, minkä perusteella johtajalla on oltava useiden apuvälineiden kokoelma käytettäväksi erilaisissa tilanteissa.

Tämän luovan pohdinnan perusteella tämä tutkimus esittää seuraavat hypoteesit:
Hypoteesi:
Äänestysjärjestelmän käyttö voi laajentua muillekin alueille kuin vaatimustenhallintaan.
Hypoteesi:
Äänestysjärjestelmän käyttö ei sovi kaikkiin tilanteisiin johdettaessa vaatimustenhallintaa.
Hypoteesi:
Vaatimustenhallinnan johtamistavan muutosta voidaan kokeilla äänestysjärjestelmän avulla.

14.7. Äänestysjärjestelmä osana ohjelmistotuotantosopimusta

Ohjelmistotuotannon erityispiirre on, että toteutettava järjestelmä on abstraktio toteutuksenkin jälkeen, eikä toteutuksenkaan aikana järjestelmää voi koskettaa fyysisenä kokonaisuutena. Tästä abstraktisuudesta huolimatta toteutettavalle ohjelmistotuotteelle esitetään hyvin paljon erilaisia vaatimuksia.

Kontio et al. (1998) toteavat sopimuksen olevan kokoelma sovittuja sitoumuksia, jotka voivat olla havaittavissa eri muodoissa: kirjallisina sopimuksina, suunnitelmina, suullisina sopimuksina, jne. Tämän tutkimuksen kannalta Kontion et. al. (1998) artikkelissa on mielenkiintoista sitoumuksien erittelyssä ohjelmiston toteutusprosessin spesifiointi, jossa on eroteltavissa seuraavat osat:
-	hallinnolliset menettelyt (administrative procedures)
-	toteutusprosessin vaatimukset (development process requirements)
-	muutoshallintamenettelyt (change control procedures)
-	ristiriitojen ratkaisumenettelyt (conflict resolution procedures)
-	prosessistandardit (process standards)
-	riskienhallintaprosessin määrittely (risk management process definition).
Kun tämän tutkimuksen lähestymistapana on ollut tutkia äänestysjärjestelmää prosessina, ovat edellä mainitut ohjelmiston toteutusprosessin osat oleellisia tämän tutkimuksen kannalta.

Aiemmissa luvuissa olen todennut hypoteeseja, jotka tukevat Kontion et al. (1998) esittämissä kohdissa äänestysjärjestelmän käyttöä, joten aiempien hypoteesien toistaminen ei ole tarpeellista. Uutena havaintona äänestysjärjestelmän kannalta on Kontion et al. (1998) toteamus, että ohjelmiston toteutusprosessi on määritettävä sitä tarkemmin, mitä riskialttiimpi toteutusprojekti on. Tämän perusteella tämä tutkimus tekee seuraavat hypoteesit:
Hypoteesi:
Äänestysjärjestelmän käyttö vähäriskisissä projekteissa tuo lisävarmuutta vaatimustenhallintaan.
Hypoteesi:
Jos toteutusprojektissa on paljon riskiä, on äänestysjärjestelmä tapa hallita tulevan ohjelmistotuotteen ristiriitaisia vaatimuksia. Oletuksena on, että äänestysjärjestelmän avulla riskialttiin ohjelmistoprojektin aikana ennalta arvaamattomat vaatimukset löytyvät nopeammin.

Toisaalta erilaisia sopimuksia ohjelmistotuotantoprosessin aikana voi pitää asiakasorganisaation ja ohjelmistotuotanto-organisaation välisenä luottamuksen ilmauksena. Luottamukseen taloudellisena vaikuttajana ovat kiinnittäneet huomiota Harisalo ja Miettinen (1996), ja he toteavat jälkiteollisessa yhteiskunnassa tiedon nousseen keskeiseksi pääomaksi. Tämän perusteella aiempien yhteiskuntamuotojen järjestelmät, myös sopimusjärjestelmät, muuttuvat. 

Sopimusjärjestelmien kannalta muutos tarkoittaa, että huolimatta tarkoista sopimuksista täydellistä tietoa toteutettavasta ohjelmistotuotteesta ei ole ennen tuotteen valmistumista. Tämän vuoksi sekä asiakasorganisaation että ohjelmistotuotanto-organisaation on luotettava toisiinsa. Saman ilmiön toinen puoli on Kontion et al. (1998) toteama sitoumus. Luottamuksen ja sitoumuksen kannalta tämä tutkimus tekee seuraavan hypoteesin: 
Hypoteesi:
Äänestysjärjestelmä on tapa luoda luottamusta organisaatioiden välille ja organisaatioiden sisällä.

14.8. Lopuksi

14.8.1. Johtopäätökset

Tämän tutkimuksen ongelmana oli etsiä hypoteeseja empiiristä testausta varten. Tutkimuksessa esitetyt hypoteesit ovat myönteisiä arvioita äänestysjärjestelmän käyttömahdollisuuksista. Kielteiset vaikutukset, jotka ovat mahdollisia, ovat jääneet tässä tutkimuksessa vähemmälle. Inhimillinen toiminta on monesti yllätyksellistä ja sisältää monia ennakoimattomia vaikutuksia. Tähän ovat kiinnittäneet huomiota Meadows et al. (1973, s. 149-151) jo 1970-luvulla. Keskeiseen kysymykseen, eli millaisia ovat äänestysjärjestelmän todelliset vaikutukset, tämä tutkimus ei ota kantaa. Tähän kysymykseen vastaaminen jää muihin tutkimuksiin.

Tutkimuksen päätuloksena voi todeta, että äänestysjärjestelmä vaatimustenhallinnan menetelmänä ei ole yksiselitteinen, mutta antaa aihetta hypoteesien testaamiselle. Yhteenvetona voi todeta, että rohkeimmat organisaatiot voivat kokeilla äänestysjärjestelmää, ja laatia Heiskasen (1994) esimerkin mukaisesti kriittisen arvioinnin läpikäydystä prosessista.

14.8.2. Jatkotutkimusaiheita

Tutkimuksessa olen etsinyt erilaisilla näkökulmilla hypoteeseja, joita voisi testata erilaisilla tutkimusotteilla. Osa tutkimuksen aikana löydetyistä hypoteeseista on lupaavampia kuin toiset.

Jos äänestysjärjestelmällä pystytään selvittämään nopeammin kannatus, kannatuksen laajuus ja erilaiset näkökulmat löydettyihin vaatimuksiin, olisi äänestysjärjestelmän käyttö perusteltua. Lisäksi päätöksentekoprosessin tehokkuuden nousu sekä ohjelmistotuotanto- että asiakasorganisaatiossa äänestysjärjestelmän avulla olisi lupaava tutkimuskohde. Lisäksi vaatimusten ristiriitaisuuden ja muutosten käsittelyn tehokkuus äänestysjärjestelmän avulla on mielenkiintoinen tutkimuskohde. Muut hypoteesit ovat kyllä mielenkiintoisia, mutta ne ovat monesti seurauksia näistä lupaavista hypoteeseista.

Samalla tavoin kuin Hurri (2000) on tässäkin tutkimuksessa lopuksi todettava esitellyn menetelmän vaativan laajaa empiiristä testausta, ennen kuin äänestysjärjestelmän todellinen hyöty voidaan arvioida. Esitettyjen hypoteesien todellinen arvo voidaan osoittaa vasta muissa tutkimuksissa.

Mielenkiintoinen empiirinen jatkotutkimusaihe olisi tutkia olemassa olevia tietoteknisiä välineitä vaatimustenhallintaan, ja arvioida niiden mahdollisuuksia äänestysjärjestelmän äänestysvälineenä. Yksi mahdollinen empiirinen jatkotutkimus on toteuttaa täysin uusi tietotekninen väline äänestysvälineeksi tai laajentaa jonkin välineen toimintaa äänestysvälineeksi. Jos äänestysvälinettä tarkastellaan ryhmäohjelmana, avaa tämä näkökulma erittäin rikkaan ja monipuolisen tutkimusperinteen käytettäväksi äänestysjärjestelmän arvioinnissa. Tässäkin tapauksessa on mahdollista tutkia empiirisesti olemassa olevien tietoteknisten välineiden käyttöä äänestysjärjestelmänä.

LÄHTEET

Brooks Frederick P. Jr.: The Mythical Man-Month - Essays on Software Engineering. Addison-Wesley Publishing Company, 1975.

Damoran L., Ip K., Beck M.: Integrating Human Factors into Structured Design Methodology: A Case Study in the UK Civil Service. In Information Technology for Organisational Systems - Concepts for Increased Competetiviness. Proceedings of the First European Conference on Information Technology for Organisational Systems - EURINFO ´88, Athens, Greece, 16-20 May, 1988. Edited by H.J. Bullinger, E.N. Protonotarios, D. Bowhuis, F. Reim. North-Holland, 1988.

Finkelstein Clive: An Introduction to Information Engineering - From Strategic Planning to Information Systems. Addison-Wesley Publishing Company, 1989.

Haikala Ilkka, Märijärvi Jukka: Ohjelmistotuotanto. Gummerus Kirjapaino Oy, Jyväskylä 1998 (6. painos).

Hannus Jouko: Prosessijohtaminen. Gummerus Kirjapaino Oy, Jyväskylä 1997 (4. painos).

Harisalo Risto, Miettinen Ensio: Luottamuspääoma - yrittäjyyden kolmas voima. Gummerus Kirjapaino Oy, Saarijärvi 1996 (2. painos).

Heiskanen Ari: Issues and Factors Affecting the Success and Failure of a Student Record System Development Process. Yliopistopaino, Helsinki 1994.

Heller Frank, Drenth Pieter, Koopman Paul, Rus Veljko: Decisions in Organzations - A Three-Country Comparative Study. Sage Publications, 1988.

Humphrey Watt S.: Managing the Software Process. Addison-Wesley Publishing Company Inc., 1989.

Hurri Jarmo: Using decision tools in deciding system product requirements: literature review and a behaviourally motivated lightweight tool. Helsinki University of Technology, Department of Computer Science and Engineering, 3.9.2000.

Icelandic Council for Standardization (STRÍ): Modelling a Software Quality Handbook. Libris, Reykjavik 1991. (MSQH, 1991).

Järvinen Pertti: Atk, toimintayksikkö, yhteiskunta ja maapallo. Tampereen yliopisto, tietojenkäsittelyopin laitos, raportti 1991-C-3. Tampereen yliopisto, Jäljennepalvelu, 1998.

Järvinen Pertti, Järvinen Annikki: Tutkimustyön metodeista. Tampereen Yliopistopaino Oy, Juvenes-Print, Tampere 2000.

Kontio Jyrki, Pitkänen Olli, Sulonen Reijo: Towards Better Software Projects and Contracts:
Commitment Specifications in Software Development Projects. Paper presented at the ICSE 98 in Kyoto, Japan. IEEE Computer Society, 1998.

Kujala S, Mäntylä M.: How Effective Are User Studies? In Proceedings of HCI ´2000 Conference (Sunderland, UK, 6-8 September), pp. 61-71, 2000.

Marakas George M., Elam Joyce J.: Semantic Structuring in Analysis Acquisition and representation of Facts - Requirement Analysis. Information Systems Research, Vol. 9, No. 1. March 1998.

Marttiin Pentti: Customisable Process Modellling Support and Tools for Design Environment. Jyväskylä Studies in Computer Science, Economics and Statistics. University of Jyväskylä, 1998.

Meadows Donella H, et al.: Kasvun rajat. Tammi, Helsinki 1973.

Mäkäräinen Minna: Software change management process in the development of embedded software. VTT publications 416. Otamedia Oy, Espoo 2000.

Pettigrew, Andrew M.: The Politics of Organisational Change. In The Human Side of Information Processing. Proceedings of the Copenhagen Conference on Computer Impact -78, October 25-27, 1978. Edited by Niels Bjørn-Andersen. North-Holland Publishing Company, 1980.

Robertson Suzanne, Robertson James: Mastering the Requirements Process. Addison-Wesley, 1999.

Robillard Pierre N.: The Role of Knowledge in Software Development. Communications of the ACM, January 1994, Vol. 42, No. 1, pp. 87-92.

Ropponen Janne: Risk Management in Information System Development. University of Jyväskylä, Department of Computer Science and Information Systems, Computer Science Reports, Technical Reports TR-3. Jyväskylän yliopiston tutkimuskeskus, 1993.

Spinas Philipp, Ackerman David, Ulich Eberhard: User Participation in Software Development: Results of Case Studies. In Information Technology for Organisational Systems - Concepts for Increased Competetiviness. Proceedings of the First European Conference on Information Technology for Organisational Systems - EURINFO ´88, Athens, Greece, 16-20 May, 1988. Edited by H.J. Bullinger, E.N. Protonotarios, D. Bowhuis, F. Reim. North-Holland, 1988.

Sommerville Ian, Sawyer Pete: Requirements Engineering - A good practise guide. John Wiley & Sons Ltd., Chichester, 1997.

Suomi Reima: Tietohallinnon johtaminen - johtamisparadigmat muutoksen kourissa. Otatieto n:o 892. Hakapaino Oy, Helsinki 1992.

Sydänmaalakka Pentti: Älykäs organisaatio - tiedon, osaamisen ja suorituksen johtaminen. Gummerus Kirjapaino Oy, Jyväskylä 2000.

Tervonen Ilkka, Kerola Pentti: Towards deeper co-understanding of software quality. Information and Software Technology, Vol. 39, (14-15), 1998, pp. 995-1003.

White, John R.: A Desicion Tool for Assisting with the Comprehension on Large Software Systems. In Automated Tools for Information Systems Design. Proceedings of the IFIP WG 8.1. Working Conference on Automated Tools for Information Systems Design and Development, New Orleans, U.S.A., 26-28 January 1982. Edited by Hans-Jochen Schneider, Anthony I. Wasserman. Norh-Holland Publishing Company, 1982.

Wiegers Karl E.: Software Requirements. Microsoft Press, Redmond 1999.