Ohjelmistokehityshallinta ( eng. Software project management ) on erityinen projektinhallinta , jonka puitteissa tapahtuu ohjelmistokehitysprojektien suunnittelu, seuranta ja ohjaus . Avain ohjelmistokehitysprojektin johtamiseen on oikean kehitystavan valinta.
Tietokoneiden tehon nopean kasvun vuoksi XX-luvun 60- ja 70-luvuilla niiden avulla ratkaistavissa olevat ongelmat vaikeutuivat. Siksi tarvittiin suurempia projekteja , joihin kuului useamman ihmisen työn koordinointi ja paljon enemmän koodin kirjoittaminen . Tällaisten projektien johtamiseen käytetyt menetelmät on kuitenkin suunniteltu vastaamaan paljon pienempien projektien haasteisiin. Tarvittavan metodologian puute on johtanut valtavaan määrään epäonnistuneita hankkeita. Yritykset muuttaa tilannetta parempaan johtivat uudenlaisen kehitysprosessin mallin luomiseen , jossa keskityttiin enemmän lopullisen ohjelmistotuotteen vastaamaan asiakkaan alkuperäisiä vaatimuksia .
Tutkimukset epäonnistuneista projekteista ovat osoittaneet, että yleisimmät epäonnistumisen syyt olivat: [1]
Sen jälkeen on tehty useita parannuksia jo olemassa oleviin ( iteratiivinen lähestymistapa ) ja täysin uusia ( testiohjattu kehitys ) ohjelmistokehityksen hallintamenetelmiin. Nykyään on kuitenkin taipumus siirtyä vesiputousmallista sykliseen malliin , joka jäljittelee ohjelmistokehityksen vaiheita .
GOST 19 "Yhteinen ohjelmistodokumentaatiojärjestelmä" [2] ja GOST 34 "Automaattisten järjestelmien kehittämisen standardit" [3] keskittyvät johdonmukaiseen lähestymistapaan ohjelmistokehitykseen. Näiden standardien mukainen kehitys tapahtuu vaiheittain, joista jokainen sisältää tiukasti määritellyn työn toteuttamisen. Näiden GOST-standardien tiukka noudattaminen johtaa kaskadimalliin. Näiden standardien pohjalta kehitetään ohjelmistojärjestelmiä Venäjän valtion tilauksiin .
Tämän mallin kehitti 1980-luvun puolivälissä Carnegie Mellonin yliopiston Software Engineering Institute luodakseen vertailumallin ohjelmistokehityksen järjestämiseen. Se perustuu organisaation tiettyjen vaatimusten noudattamisen tarkistamiseen ja ohjelmistokehitysprosessin kypsyysasteen määrittämiseen.
Rational Software on kehittänyt Unified Processin UML :n täydennykseksi . RUP-malli kuvaa abstraktia yleistä prosessia, jonka pohjalta organisaation tai projektitiimin tulee luoda oma tarpeisiinsa keskittyvä erikoistunut prosessi.
Microsoft Solutions Framework on rakennettu iteratiivisen kehityksen ympärille. MSF:n erityispiirre on suuri huomio tehokkaan ja ei-byrokraattisen tiimin luomiseen.
Henkilökohtainen ohjelmistoprosessi määrittelee kehittäjän pätevyysvaatimukset, jotta he voivat hankkia Team Software Process -prosessiin tarvittavat taidot. Team Software Process -prosessi yhdessä Personal Software Process -prosessin kanssa perustuu 3-20 hengen itseohjautuviin tiimeihin. Joukkueiden tulee:
Kaikkien kettereiden mallien perusajatuksena on, että ohjelmistokehitysprosessin tulee olla mukautuva. Niiden tavoitteena on keskittyä ihmisiin ja heidän vuorovaikutukseensa prosessien ja työkalujen sijaan. Kaikki joustavat mallit perustuvat iteraatioon, inkrementaalisuuteen, tiimin itsehallintaan ja prosessien mukautumiseen.
Ohjelmistokehitysprojektin johtamisprosessi sisältää muita, tarkempia prosesseja, jotka tähtäävät tiettyjen liiketoimintapäätösten tekemiseen. Monia niistä voidaan soveltaa muuntyyppisiin projekteihin. Esimerkiksi:
Yleisesti ottaen ohjelmistokehityksen hallintaa, jolla on paljon lainauksia projektinhallinnasta, voidaan soveltaa perinteisen johtamisen menetelmiin . Alan ainutlaatuisuudesta johtuen materiaalituotannossa kertynyt ja esimerkiksi PMI PMBOK -standardissa esitelty ammattilaisten kokemus ei kuitenkaan juurikaan edistä ohjelmistoprojektin hallinnan onnistumista. On monia mielipiteitä siitä, mitä tietoja ja taitoja ohjelmistokehitysprojektipäälliköllä tulisi olla. Esimerkiksi kuuluisa amerikkalainen tietojenkäsittelytieteilijä John Reynolds kirjoitti:
Jotkut väittävät, että ohjelmistojen luomista on mahdollista hallita ilman ohjelmointitaitoja . Tämä luottamus näyttää johtuvan siitä väärinkäsityksestä, että ohjelmistokehitys on tuotannon muoto. Mutta tuotanto on toistuvien identtisten objektien luomista, kun taas ohjelmistotuotanto on ainutlaatuisten objektien luomista, eli se on yksi luovuuden muodoista . Ohjelmistotuotanto on siis verrattavissa julkaisuun – ohjelmistokehityspäällikkö, joka ei osaa koodata, on kuin sanomalehden toimittaja, joka ei osaa kirjoittaa.
Alkuperäinen teksti (englanniksi)[ näytäpiilottaa] "Jotkut väittävät, että ohjelmistotuotantoa voidaan hallita ilman ohjelmointikykyä. Tämä uskomus näyttää johtuvan siitä virheellisestä näkemyksestä, että ohjelmistotuotanto on valmistuksen muoto. Mutta valmistus on identtisten objektien toistuvaa rakentamista, kun taas ohjelmistotuotanto on ainutlaatuisia esineitä, eli koko prosessi on suunnittelun muoto.Rikkinäinen linkki