Viite: Sommerville, Software Engineering, 10 ed., Chapter 2

Ohjelmistoprosessi on jäsennelty joukko toimintoja, joita tarvitaan ohjelmistojärjestelmän kehittämiseen. Huomaa, että puhumme ”ohjelmistoprosessista” — emme ”ohjelmistokehitysprosessista”.”

Ohjelmistoprosesseja on monenlaisia, mutta jokaiseen niistä sisältyy näitä neljää erilaista perustoimintoa:

• Ohjelmiston määrittely – määritellään, mitä järjestelmän pitäisi tehdä;
• Ohjelmistosuunnittelu ja toteutus – järjestelmän organisaation määrittely ja järjestelmän toteuttaminen;
• Ohjelmiston kelpuutus – tarkistetaan, että se tekee sen, mitä asiakas toivoo;
• Ohjelmiston evoluution kehittäminen – muutetaan järjestelmää muuttuvien asiakastarpeiden mukaan.

Ohjelmistoprosessimalli on abstrakti esitys prosessista. Se esittää prosessin kuvauksen jostain tietystä näkökulmasta. Kun kuvaamme ohjelmistoprosesseja ja keskustelemme niistä, puhumme yleensä näihin prosesseihin sisältyvistä toiminnoista, kuten tietomallin määrittelystä, käyttöliittymän suunnittelusta jne. ja näiden toimintojen järjestyksestä.Prosessikuvaukset voivat sisältää myös:

• Tuotteet, jotka ovat prosessin aktiviteetin tuloksia;
• Roolit, jotka kuvastavat prosessiin osallistuvien henkilöiden vastuualueita;
• Esi- ja jälkiehdot, jotka ovat väitteitä, jotka pitävät paikkansa ennen ja jälkeen prosessin aktiviteetin toteuttamisen tai tuotteen tuottamisen.

Suunnitelmapohjaiset prosessit ovat prosesseja, joissa kaikki prosessitoiminnot suunnitellaan etukäteen ja edistymistä mitataan tätä suunnitelmaa vasten. Ketterissä prosesseissa suunnittelu on inkrementaalista ja prosessia on helpompi muuttaa vastaamaan muuttuvia asiakasvaatimuksia. Käytännössä useimmat käytännön prosessit sisältävät elementtejä sekä suunnitelmaperusteisesta että ketterästä lähestymistavasta.

Vesiputousmalli Suunnitelmavetoinen malli. Erilliset ja erilliset vaiheet määrittelylle, ohjelmistosuunnittelulle, toteutukselle, testaukselle ja ylläpidolle. Inkrementaalinen kehitys Määrittely, kehitys ja validointi lomittuvat toisiinsa. Järjestelmä kehitetään useina versioina (inkrementteinä), ja jokainen versio lisää toiminnallisuutta edelliseen versioon. Voi olla suunnitelmapohjainen tai ketterä. Integrointi ja konfigurointi Perustuu merkittävään määrään uudelleenkäytettäviä komponentteja/järjestelmiä. Järjestelmäkehitysprosessissa keskitytään näiden komponenttien integrointiin järjestelmäksi sen sijaan, että niitä kehitettäisiin tyhjästä. Voi olla suunnitelmapohjainen tai ketterä.

Käytännössä useimmat suuret järjestelmät kehitetään käyttäen prosessia, joka sisältää elementtejä kaikista näistä malleista.

Vesiputousmallissa on erilliset tunnistetut vaiheet:

Vaatimusanalyysi ja vaatimusmäärittely Järjestelmän palvelut, rajoitteet ja tavoitteet määritetään kuulemalla järjestelmän käyttäjiä. Sen jälkeen ne määritellään yksityiskohtaisesti ja ne toimivat järjestelmän määrittelynä. Järjestelmä- ja ohjelmistosuunnittelu Järjestelmäsuunnitteluprosessissa vaatimukset kohdistetaan joko laitteisto- tai ohjelmistojärjestelmiin laatimalla järjestelmän kokonaisarkkitehtuuri. Ohjelmistosuunnittelussa tunnistetaan ja kuvataan ohjelmistojärjestelmän perusabstraktiot ja niiden väliset suhteet. Toteutus ja yksikkötestaus Tässä vaiheessa ohjelmistosuunnittelu toteutetaan joukkoina ohjelmina tai ohjelmayksikköinä. Yksikkötestauksessa tarkistetaan, että kukin yksikkö täyttää spesifikaationsa. Integrointi ja järjestelmätestaus Yksittäiset ohjelmayksiköt tai ohjelmat integroidaan ja testataan kokonaisena järjestelmänä sen varmistamiseksi, että ohjelmistovaatimukset on täytetty. Testauksen jälkeen ohjelmistojärjestelmä toimitetaan asiakkaalle. Käyttö ja ylläpito Yleensä (vaikkakaan ei välttämättä) tämä on pisin elinkaaren vaihe. Järjestelmä asennetaan ja otetaan käytännön käyttöön. Ylläpidossa korjataan virheet, joita ei havaittu elinkaaren aikaisemmissa vaiheissa, parannetaan järjestelmäyksiköiden toteutusta ja parannetaan järjestelmän palveluja sitä mukaa kuin uusia vaatimuksia havaitaan.

Vesiputousmallin suurin haittapuoli on vaikeus mukautua muutoksiin sen jälkeen, kun prosessi on jo käynnissä. Periaatteessa vaiheen on oltava valmis ennen siirtymistä seuraavaan vaiheeseen. Vesiputousmallin ongelmia ovat muun muassa:

Vaikea puuttua muutoksiin Projektin joustamaton jakaminen erillisiin vaiheisiin vaikeuttaa reagoimista muuttuviin asiakasvaatimuksiin.Siksi tämä malli soveltuu vain silloin, kun vaatimukset on ymmärretty hyvin ja muutokset ovat melko vähäisiä suunnitteluprosessin aikana. Vain harvoilla liiketoimintajärjestelmillä on vakaat vaatimukset. Hyvin vähän reaalimaailman sovelluksia Vesiputousmallia käytetään useimmiten suurissa järjestelmäsuunnitteluprojekteissa, joissa järjestelmää kehitetään useissa eri toimipisteissä.Näissä tilanteissa vesiputousmallin suunnitelmaperusteisuus auttaa työn koordinoinnissa.

Inkrementaalisen kehityksen edut:

Muutosten alhaisemmat kustannukset Muuttuviin asiakasvaatimuksiin sopeutumisesta aiheutuvat kustannukset vähenevät. Uudelleen tehtävän analyysin ja dokumentoinnin määrä on paljon pienempi kuin vesiputousmallissa. Tiheä palaute Asiakkailta on helpompi saada palautetta tehdystä kehitystyöstä. Asiakkaat voivat kommentoida ohjelmiston demonstraatioita ja nähdä, kuinka paljon on toteutettu. Nopeampi toimitus Käyttökelpoisen ohjelmiston nopeampi toimitus ja käyttöönotto asiakkaalle on mahdollista. Asiakkaat voivat käyttää ohjelmistoa ja saada siitä lisäarvoa aikaisemmin kuin vesiputousprosessissa.

Inkrementaalisen kehityksen ongelmat (johdon näkökulmasta):

Prosessi ei ole näkyvä Johtajat tarvitsevat säännöllisiä tuotoksia edistymisen mittaamiseksi. Jos järjestelmiä kehitetään nopeasti, ei ole kustannustehokasta tuottaa dokumentteja, jotka kuvaavat järjestelmän jokaista versiota. Järjestelmän rakenteella on taipumus heikentyä, kun uusia inkrementtejä lisätään Jos aikaa ja rahaa ei käytetä refaktorointiin ohjelmiston parantamiseksi, säännöllisillä muutoksilla on taipumus turmella sen rakennetta. Uusien ohjelmistomuutosten sisällyttämisestä tulee yhä vaikeampaa ja kalliimpaa.

Tämä lähestymistapa perustuu systemaattiseen uudelleenkäyttöön, jossa järjestelmät integroidaan olemassa olevista komponenteista tai COTS-järjestelmistä (Commercial-off-the-shelf) Prosessin vaiheita ovat:

• Komponenttianalyysi;
• Tarpeiden muokkaus;
• Järjestelmän suunnittelu uudelleenkäyttöä käyttäen;
• Kehittäminen ja integrointi.

Uudelleenkäyttö on nykyään vakiomenetelmä monentyyppisten liiketoimintajärjestelmien rakentamisessa.

Ohjelmistokomponenttien tyypit:

• Verkkopalvelut, jotka on kehitetty palvelustandardien mukaisesti ja jotka ovat käytettävissä etäkutsua varten.
• Objektien kokoelmat, jotka on kehitetty pakettina integroitavaksi komponenttikehykseen, kuten .NET tai J2EE.
• Sisäiset kaupalliset valmisjärjestelmät (COTS), jotka on konfiguroitu käytettäväksi tietyssä ympäristössä.

Todelliset ohjelmistoprosessit ovat teknisten, yhteistoiminnallisten ja hallinnollisten toimintojen toisiinsa kytkeytyviä sekvenssejä, joiden yleistavoitteena on ohjelmistojärjestelmän määrittely, suunnittelu, toteutus ja testaus.

Neljä prosessin perustoimintoa, jotka ovat määrittely, kehittäminen, validointi ja evoluutio, on organisoitu eri tavoin eri kehitysprosesseissa. Vesiputousmallissa ne on järjestetty peräkkäin, kun taas inkrementaalisessa kehityksessä ne on lomitettu toisiinsa.

Ohjelmiston spesifikaatio Prosessi, jossa määritetään, mitä palveluita tarvitaan ja mitä rajoitteita järjestelmän toiminnalle ja kehitykselle asetetaan. Vaatimusmäärittelyprosessi:

• Toteutettavuustutkimus: Onko järjestelmän rakentaminen teknisesti ja taloudellisesti mahdollista?
• Tarpeiden selvittäminen ja analysointi: Mitä järjestelmän sidosryhmät vaativat tai odottavat järjestelmältä?
• Tarpeiden määrittely: Vaatimusten yksityiskohtainen määrittely
• Tarpeiden validointi: Vaatimusten paikkansapitävyyden tarkistaminen

Ohjelmistosuunnittelu ja -toteuttaminen Prosessi, jossa järjestelmäspesifikaatio muunnetaan toteutettavaksi järjestelmäksi.

• Ohjelmistosuunnittelu: suunnitellaan ohjelmistorakenne, joka toteuttaa spesifikaation;
• Toteutus: käännetään tämä rakenne suoritettavaksi ohjelmaksi;

Suunnittelun ja toteutuksen toiminnot liittyvät läheisesti toisiinsa, ja ne voidaan lomittaa toisiinsa. Suunnittelutoimintoja ovat mm:

• Arkkitehtuurisuunnittelu: määritetään järjestelmän kokonaisrakenne, pääkomponentit (joita joskus kutsutaan osajärjestelmiksi tai moduuleiksi), niiden väliset suhteet ja niiden jakautuminen.
• Käyttöliittymäsuunnittelu: määritellään järjestelmän komponenttien väliset rajapinnat.
• Komponenttisuunnittelu: Otetaan kukin järjestelmän komponentti ja suunnitellaan, miten se toimii.
• Tietokantasuunnittelu: suunnitellaan järjestelmän tietorakenteet ja se, miten ne esitetään tietokannassa.

Ohjelmiston validointi Verifioinnin ja validoinnin (V & V) tarkoituksena on osoittaa, että järjestelmä on spesifikaationsa mukainen ja täyttää järjestelmän asiakkaan vaatimukset.

• Validointi: Rakennammeko oikean tuotteen (sen, mitä asiakas haluaa)?
• Verifiointi: Rakennammeko tuotteen oikein?

V & V käsittää tarkistus- ja tarkasteluprosessit sekä järjestelmän testauksen. Järjestelmätestaukseen kuuluu järjestelmän suorittaminen testitapauksilla, jotka on johdettu järjestelmän käsittelemien todellisten tietojen määrittelystä. Testaus on yleisimmin käytetty V & V -toiminto, ja se sisältää seuraavat vaiheet:

• Kehitys- tai komponenttitestaus: yksittäisiä komponentteja testataan itsenäisesti; komponentit voivat olla funktioita tai objekteja tai näiden kokonaisuuksien yhtenäisiä ryhmittymiä.
• Järjestelmätestausta: järjestelmän testaaminen kokonaisuutena, esiin nousevien ominaisuuksien testaaminen on erityisen tärkeää.
• Hyväksymistestaus: testaaminen asiakastiedoilla sen tarkistamiseksi, että järjestelmä vastaa asiakkaan tarpeita.

Ohjelmiston evoluutio Ohjelmisto on luonnostaan joustava ja se voi muuttua. Kun vaatimukset muuttuvat liiketoimintaolosuhteiden muuttuessa, myös liiketoimintaa tukevien ohjelmistojen on kehityttävä ja muututtava.Vaikka kehitys ja evoluutio (ylläpito) on erotettu toisistaan, tämä on yhä merkityksettömämpää, koska yhä harvemmat järjestelmät ovat täysin uusia.

Muutokset ovat väistämättömiä kaikissa suurissa ohjelmistoprojekteissa.Liiketoiminnan muutokset johtavat uusiin ja muuttuneisiin järjestelmävaatimuksiinUudet teknologiat avaavat uusia mahdollisuuksia toteutusten parantamiseen.Muuttuvat alustat edellyttävät sovellusten muuttamista.Muutos johtaa uudelleentyöstämiseen, joten muutoksen kustannuksiin sisältyy sekä uudelleentyöstäminen (esim.esim. vaatimusten uudelleen analysointi) kuin myös uuden toiminnallisuuden toteuttamisen kustannukset.

Kaksi strategiaa uudelleentyöstön kustannusten vähentämiseksi:

Muutosten välttäminen Ohjelmistoprosessi sisältää toimintoja, joilla voidaan ennakoida mahdollisia muutoksia ennen kuin merkittävää uudelleentyöstöä tarvitaan. Voidaan esimerkiksi kehittää prototyyppijärjestelmä, jonka tarkoituksena on esitellä joitakin järjestelmän keskeisiä ominaisuuksia asiakkaille. Muutosten sietokyky Prosessi on suunniteltu siten, että muutokset voidaan ottaa huomioon suhteellisen pienin kustannuksin.Tähän liittyy yleensä jonkinlainen inkrementaalinen kehitys. Ehdotetut muutokset voidaan toteuttaa inkrementteinä, joita ei ole vielä kehitetty. Jos tämä ei ole mahdollista, vain yksi inkrementti (pieni osa järjestelmästä) saatetaan joutua muuttamaan muutoksen sisällyttämiseksi siihen.

Prototyyppi on järjestelmän alustava versio, jota käytetään konseptien havainnollistamiseen ja suunnitteluvaihtoehtojen kokeilemiseen. Prototyyppiä voidaan käyttää:

• Tarvesuunnitteluprosessissa apuna vaatimusten selvittämisessä ja validoinnissa;
• Suunnitteluprosesseissa vaihtoehtojen tutkimiseen ja käyttöliittymäsuunnittelun kehittämiseen;
• Testausprosessissa back-to-back-testien suorittamiseen.

Prototypoinnin hyödyt:

• Parannettu järjestelmän käytettävyys.
• Ohjattu vastaamaan paremmin käyttäjien todellisia tarpeita.
• Suunnittelun laadun parantaminen.
• Parannettu ylläpidettävyys.
• Vähennetty kehitystyön vaiva.

Prototyypit voivat perustua nopean prototyypintekemisen ohjelmointikieliin tai työkaluihin. Niihin voi liittyä toiminnallisuuden jättäminen pois:

• Prototyypin tulisi keskittyä tuotteen osa-alueisiin, joita ei ymmärretä hyvin;
• Virheiden tarkistus ja palautus eivät välttämättä sisälly prototyyppiin;
• Keskittyminen toiminnallisiin eikä ei-toiminnallisiin vaatimuksiin, kuten luotettavuuteen ja turvallisuuteen.

Prototyypit tulisi hylätä kehityksen jälkeen, koska ne eivät ole hyvä perusta tuotantojärjestelmälle:

• Järjestelmää voi olla mahdotonta virittää vastaamaan ei-toiminnallisia vaatimuksia;
• Prototyypit ovat tavallisesti dokumentoimattomia;
• Prototyypin rakenne heikkenee tavallisesti nopeiden muutosten vuoksi;
• Prototyyppi ei todennäköisesti täytä organisaation tavanomaisia laatuvaatimuksia.

Sen sijaan, että järjestelmä toimitettaisiin yhtenä toimituksena, kehitys ja toimitus jaetaan inkrementteihin, joissa kukin inkrementti toimittaa osan vaaditusta toiminnallisuudesta.Käyttäjävaatimukset asetetaan tärkeysjärjestykseen ja tärkeimmät vaatimukset sisällytetään varhaisiin inkrementteihin.Kun inkrementin kehittäminen on aloitettu, vaatimukset jäädytetään, vaikka myöhempien inkrementtien vaatimukset voivat edelleen kehittyä.

Inkrementaalisen toimituksen edut:

• Asiakasarvo voidaan toimittaa jokaisen inkrementin myötä, joten järjestelmän toiminnallisuus on käytettävissä aikaisemmin.
• Varhaiset inkrementit toimivat prototyyppinä, joka auttaa saamaan esiin vaatimuksia myöhempiä inkrementtejä varten.
• Vähäisempi riski koko projektin epäonnistumiselle.
• Prioriteettisimpiin järjestelmäpalveluihin kohdistuu yleensä eniten testausta.

Inkrementaalisen toimituksen ongelmat:

• Useimmat järjestelmät vaativat joukon peruspalveluja, jotka ovat järjestelmän eri osien käytössä. Koska vaatimuksia ei määritellä yksityiskohtaisesti ennen kuin inkrementti on tarkoitus toteuttaa, voi olla vaikeaa tunnistaa yhteisiä toimintoja, joita kaikki inkrementit tarvitsevat.
• Iteratiivisten prosessien ydin on, että määrittelyä kehitetään yhdessä ohjelmiston kanssa. Tämä on kuitenkin ristiriidassa monien organisaatioiden hankintamallin kanssa, jossa täydellinen järjestelmäspesifikaatio on osa järjestelmäkehityssopimusta.

Monet ohjelmistoyritykset ovat kääntyneet ohjelmistoprosessien parantamisen puoleen keinona parantaa ohjelmistojensa laatua, vähentää kustannuksia tai nopeuttaa kehitysprosessejaan. Prosessien parantaminen tarkoittaa nykyisten prosessien ymmärtämistä ja niiden muuttamista tuotteiden laadun parantamiseksi ja/tai kustannusten ja kehitysajan vähentämiseksi.

Prosessien kypsyyslähestymistapa Keskittyy prosessien ja projektinhallinnan parantamiseen ja hyvien ohjelmistosuunnittelukäytäntöjen käyttöönottoon. Prosessien kypsyystaso kuvastaa sitä, missä määrin organisaation ohjelmistokehitysprosesseissa on omaksuttu hyviä teknisiä ja johtamiskäytäntöjä. Ketterä lähestymistapa Keskittyy iteratiiviseen kehitykseen ja ohjelmistoprosessin yleiskustannusten vähentämiseen. Ketterien menetelmien ensisijaisia ominaisuuksia ovat toiminnallisuuden nopea toimittaminen ja reagointi muuttuviin asiakasvaatimuksiin.

Prosessin parantamistoimet muodostavat jatkuvan syklin, jossa on palautesilmukka:

• Mitataan yhtä tai useampaa ohjelmistoprosessin tai -tuotteen ominaisuutta. Nämä mittaukset muodostavat perustason, joka auttaa päättämään, ovatko prosessin parannukset olleet tehokkaita.
• Analysoi nykyinen prosessi ja tunnista mahdolliset pullonkaulat.
• Muuta prosessia joidenkin tunnistettujen prosessin heikkouksien korjaamiseksi. Nämä otetaan käyttöön ja sykli jatkuu, jotta voidaan kerätä tietoa muutosten tehokkuudesta.

Prosessin mittaaminen

• Mahdollisuuksien mukaan olisi kerättävä kvantitatiivista prosessitietoa.
• Prosessimittauksia olisi käytettävä prosessin parannusten arvioimiseen.
• Mittauksia voivat olla esimerkiksi:
  • Prosessin toimintojen läpivientiin kuluva aika, esim.esim. kalenteriaika tai vaiva aktiviteetin tai prosessin suorittamiseen.
  • Prosessien tai aktiviteettien vaatimat resurssit, esim. kokonaisvaikutus henkilötyöpäivinä.
  • tietyn tapahtuman esiintymismäärä, esim. havaittujen vikojen määrä.

SEI:n kyvykkyyskypsyysmalli

• Initial: Pohjimmiltaan hallitsematon
• Toistettavissa: Tuotehallinnan menettelyt määritelty ja käytössä
• Määritelty: Prosessinhallinnan menettelyt ja strategiat määritelty ja käytössä
• Hallittu: Laadunhallintastrategiat määritelty ja käytössä
• Optimointi: Prosessien parantamisstrategiat määritelty ja käytössä