Iteratiivisuus on ollut keskeinen menettelytapa ohjelmistotuotannossa kautta historian. Jopa vesiputousmallin luoneen Winston Roycen pääajatuksena oli iteratiivinen ohjelmistokehitys. Royce kuvaa vesiputousmallin toimivan vain yksinkertaisimpiin projekteihin. Yhdysvaltain hallituksen sopimusmallit sisälsivät tiukkoja rajoituksia ja vaatimuksia. Työssään Royce kuvasi vesiputousmallin lisäksi iteratiivisten käytänteiden toteuttamista tiukkojen rajojen puitteissa.
Monet kriittisissä ohjelmistotuotantoprojekteissa, joissa oli suuri suunnitteluvaihe ennen toteutusta, käytettiin iteraatiivisia menetelmiä. Vesiputousmalli Nähtiin hyvin varhain vääränlaisena mallina ohjelmistokehitykselle. Malli sopi ideaalitilanteeseen, jossa vaatimusmäärittely voitiin tyhjentävästi toteuttaa.
Artikkeli osoittaa, että iteratiivista ohjelmistokehitystä on onnistuneesti toteutettu jo 1950-luvulla monissa ohjelmistoprojekteissa. Seuraavien vuosikymmenten ohjelmistosuunnittelun näkyvimmät suunnannäyttäjät tukivat iteratiivisia ohjelmistokäytänteitä.
Artikkeli kuvaa ohjelmistotuotannon kehitystä vesiputousmallista kohti ketteriä kehitysmenetelmiä. Konkreettisten ohjelmistotuotantoprojektien kautta artikkeli pyrkii näyttämään, että ohjelmistokehitys on ollut aina iteratiivista prosessia.
Ohjelmistotuontannon ketterät kehitysmenetelmät toimivat sopivissa olosuhteissa: vaihtuvat vaatimukset, ei-kriittinen ohjelmisto sekä pieni ja taitava yhdessä toimiva ryhmä. Ketterät menetelmät toimivat parhaiten alle 50 hengen organisaatiossa, joissa kehittäjillä on hyvä yhteys asiakkaisiin ja liiketoiminnan asiantuntijoihin. Menetelmiä voidaan omaksua ja mukauttaa muihin olosuhteisiin, mutta täyden ketterien menetelmien reunaehdot ovat selvät.
Ketteriä käytäntöjä toteutetaan useissa hankkeissa ja organisaatioissa. Monet laatustandardeja (CMM, ISO 9000) toteuttavat organisaatiot ovat omaksuneet ketteriä käytänteitä ja huomanneet niiden lisänneen tehokkuutta ilman sertifionnista luopumista.
Tarkastella mitä ohjelmistotuotannon ketterät kehitysmenetelmät ovat. Tuoda esille, miten perinteisen insinöörityön käytänteissä voidaan omaksua ketteriä menetelmiä.
Artikkeli kuvaa keskustelua ketterien menetelmien ympärillä 2000-luvulla ja keskustelun painopistettä vuosikymmenellä. Tuo esiin miten käytänteitä on otettu käyttöön ja miten ne ovat organisaatioissa vaikuttaneet.
Ohjelmistotuotannon ketterät menetelmät ovat luovaa yhteistyötä painopiste tehokkuudella ja liikkuvuudella.
Määrittää ongelman, johon ohjelmistotuotannon ketterät kehitysmenetelmät pyrkivät vastaamaan. Esittää miksi ketterät kehitysmentelmät parantavat ohjelmistotuotannon käytänteitä.
Todellisia esimerkkejä on jotka vakuuttavat ketterien menetelmien puolesta, joissa on onnistuneesti vastattu muutoksiin. Ja on olemassa epäonnistuneita projekteja, joissa muutoksiin liiallinen sopeutuminen on tullut kalliiksi. Molemmille sekä ketterille menetelmille että suunnitelmaperustaisella lähestymistavalla on omat etunsa. Joissain tapauksissa molempien menetelmien käytänteitä voidaan yhdistää tehokkaasti.
Hyvillä, pienellä määrällä kehittäjiä sekä pienellä projektilla ketterät menetelmät toimivat. Suunnitelmaperustainen kehitys skaalautuu paremmin isoihin projekteihin.
Osoittaa, että suunnitteluperusteisella ohjelmistotuotantomentelmillä on tarvetta edelleen tarvetta.
Ketterät kehitysmenetelmät vaativat osaavan kehittäjätiimin. Kaikki kehittäjät eivät voi tilastollisesti huomioiden osaavia, joten ohjelmistokehityksessä on edelleen tarvetta suunnittelulle. Ketterät kehitymenetelmät luottavat kehittäjien ja tiimin hiljaiseen tietoon, sen sjaan että dokumentoitaisiin suunnitelmaa. Kehittäjät saattavat tehdä peruuttamattomia arkitehtuurisia päätöksiä perustuen vajavaiseen tietoon. Suunnitelmaperustainen kehitys vähentää riskiä.
Ketterässä kehityksessä kantavana ajatuksena on kehittäjätiimin kyky vastata muutoksiin: helpottamalla tiedonsiirtoa ihmisten välillä sekä pienentämällä aikaa päätöksenteon ja toteutuksen välillä. Tämä saavutetaan tekemällä liiketoimialueen asiantuntijoista osa kehitystiimiä ja työskentelemällä inkrementaalisesti. Ketterän kehitystiimin yksilöiden taito on kriittinen tekijä projektien onnistumiselle. Jos ihmiset ovat taitavia, he voivat saavuttaa tavoitteensa prosesseista riippumatta. Taitamattomien riittämättömyyttä ei mikään prosessi voi korvata.
Osoittaa, että hmiset yhdessä saavuttavat, hyvällä viestinnän ja vuorovaikutuksen avulla, enemmän kuin yksilöinä. Prosessit luovat puitteet ryhmille ja yksilöille, mutta prosessi ei itsessään korvaa pätevyyden puutetta. Pätevyys sen sijaan voi ylittää prosessien aiheuttamat vaikeudet.
Ketterä kehitys keskittyy yksilön kykyyn ja taitoon. Prosesseja tulee muokata yksilöiden ja tiimien mukaan.
Suuri projekti tarvitsee paljon koordinointia. Mitä suurempi määrä eri rooleja kehitystiimissä on sitä suurempi menetelmä tarvitaan. Kriittinen järjestelmä, jonka havaitsemattomat viat tuottavat suurta vahinkoa, tarvitsee enemmän suunnittelua tietyillä työkaluilla sekä prosesseilla.
Raskaat tuotantomentelmät laskevat tuottavuutta. Ongelman ratkaisuun tarvitaan vähemmän ihmisiä kevyemmillä menetelmillä. Ihmisten määrä rajoittaa ratkaistavien ongelmien kokoa. Iso kehitystiimi kykenee ratkaisemaan raskailla menetelmillä suuria ongelmia. Kun ongelman koko muuttuu, niin erillaisten menetelmien yhdistelmät ovat optimaalisia. Ongelman laajuuden tai projektin alussa tarvittavan kehittäjätiimin minimikoon määrittäminen on vaikeaa.
Artikkeli pyrkii kuvaamaan puitteet ohjelmistotuotantomenetelmien eriyttämiseksi ja periaatteita menetelmien valitsemiseksi.
Artikkeli esittelee ohjelmistotuotannossa esiintyviä muuttujia, joiden perusteella voidaan kategorisoida ohjemistoprojekteja ja selvittää niille sopivimmat mentelmät.
XP (extreme programming) muuttaa perinteistä ohjelmistotuotannon prossesseja. XP pyrkii vähentämään ohjelmiston muuttamisen kustannuksia luonnnostelemalla, analysoimalla ja suunnittelemalla koko kehitysprosessin ajan.
Artikkeli kuvaa XP:n (extreme programming) käytänteitä ja miten ne vastaavat ohjelmistotuotannon ongelmiin.
Kustannukset ja laatu eivät ole internet-ohjelmistojen kehitystä ohjaavia määreitä. Nopeus on tärkein tuotantoa ohjaava arvo. Laatuvaatimukset ovat neuvoteltavissa ja muuttuvat toiminnallisuuden ja tuotteen saatavuuden mukaan. Projektihallinta on jatkuvaa operointia ilman alkua ja loppua. Ohjelmistokehityksen ongelmat ovat pilkottu pieniksi tehtäviksi, jotka esitellään pieninä räätälöityinä tuotteina. Ylläpitö on yhdistetty "vaatimusmäärittely-toteutus-julkaisu"-kiertoon tuoden uusia toiminnallisuuksia.
Ohjelmistuotannon riskeihin perustuva spiraalimalli on mukautuvampi erilaisiin ohjelmistotuotantoprojekteihin kun vesiputousmalli tai koodiin perustuva menetelmä. Se on erityisen käyttökelpoinen laajoihin ja monimutkaisiin ohjelmistoihin.
Riskiin perustuva lähestymistapa mahdollistaa spriraalimallin mukautumaan yhdistelemällä spesifiointia, prototyypitystä, simulointia tai muita ohjelmistokehityksen menetelmiä.
Perinteiset ohjelmistoprosessit ehkäisevät tehokkaampia ohjelmistotuotantomentelmiä. Artikkeli esittelee spiraalimallin ohjelmistoprosessimalliksi. Spiraalimalli tärkein tunnusmerkki on riskiin perustuva lähestymistapa, eikä niinkään dokumentointiin.
Vesiputousmallin pääasiallinen ongelma on loppuun asti laadittujen asiakirjojen Korostuminen. Laaditut dokumentit ovat merkkinä vaatimusmäärittelyn ja suunnitteluvaiheen valmistumiselle. Vaikka joillekin ohjelmistoille vesiputousmalli on tehokkain tapa, niin interaktiivisille ja loppukäyttäjille suunnitelluille ohjelmistoille vesiputousmalli ei toimi hyvin.
Asiakkaita tyydyttääkseen on toimitettava toimivaa ohjelmistoa mahdollisimman aikaisin ja jatkuvasti. Kasvava tulevaisuuden ennakoimattomuus on nykyisen talouden haastellisimpia näkökohtia. Muuttuvat vaatimukset ovat toivottavia ja ne on käännettävä asiakkaan kilpailueduksi.
Artikkeli formalisoi useita kevyitä ohjelmistotuotannon kevyitä menetelmiä.
Artikkelissa määritellään kevyiden ohjelmistotuotantomenetelmien periaatteita ja arvoja.
TDD-mentelmää käyttävät opiskelijat kirjoittivat keskimäärin enemmän testejä sekä olivat tuottavampia.
Esitellä formaali tutkimus TDD:n vahvuuksista ja heikkouksista.
Artikkelissa kuvataan kokeilua TDD:n (Test-Driven Development) kehitysmenetelmän arvioimiseksi: TDD:ssä ohjelmoijat kirjoittaa toiminnallisuuden testit ennen vastaavaa varsinaista toiminnallisuutta. Koe suoritettiin opiskelijoilla. Molemmat testiryhmät käyttivät iteratiivista prosessia lisäämällä uusia toiminnallisuuksia sekä tekemällä regressiotestejä näille.
Ohjelmistokehitys vaatii viestintää eri toimintojen välillä. Hallinnollisia sekä teknisiä ongelmia tulee esiin jatkuvasti. Jotkin ongelmat vaativat tieto ja yhteistyötä toisilta ihmisiltä. Henkilökohtainen viestintä on tärkeää menestymiselle, mutta saattaa olla liian kallista, lyhytaikaista tai paikallista ollakseen tehokasta. Ihmistenvälistä viestintää pitää tehostaa ja tehdä siitä vaikuttavampaa.
Suurten ohjelmistotuotantoprojektien aikaansaaminen johtaa työn erikoistumiseen ja jakautumiseen. Organisaatiossa tämä johtaa yhteenliittyvien toimijoiden lokerointiin maantieteellisesti ja sosiaalisesti erillisiin alaorganisaatioihin. Tämä luo esteitä ja vähentää halua jakaa tietoa sekä oppia kollegoilta. Työn osastoiminen isossa organisaatiossa vähentää tarpeettoman tiedon määrää, mutta luo koordinointiin liittyviä ongelmia.
Ohjelmistotuotannon hallinassa on vaadittava paljon dokumentointia. Ohjelmistontuotannnon hallinta ei ole mahdollista ilman kattavaa dokumentointia. Hyväksyttävä kirjallinen kuvaus pakottaa yksiselitteiseen mielipiteeseen ja tarjoaa konkreettisen todisteen valmistumisesta.
Kuvata suuriin ohjelmistojärjestelmien kehitykseen sopivan ohjelmistotuotantomenetelmän.
Artikkeli kuvaa ohjelmistotuotannossa käytettävän vesiputousmallin.
Kevyet ohjelmistotuotantomenetelmät eivät sovi kaikkiin projekteihin. Tämän päivän yleisin ohjelmistotuotannnon lähestymistapa on: ensin koodaa ja sitten korjaa (code and fix). Kevyiden ohjelmistotuotantomenetelmien käyttöönotto on helpompaa kuin raskaiden menetelmien ohjelmistoprojektien läpiviemiseen. Helpompia menetelmiä noudatetaan todennäköisemmin jos organisaatiossa ei olla aikaisemmin noudatettu mitään menetelmiä.
Kevyiden ohjelmistotuotantomenetelmien sopivuudesta suurempiin projekteihin ei ole riittävästi näyttöä.
Selvittää milloin ohjelmistotuotantoprojekteissa on välttämätöntä käyttää kevyempiä ohjelmistotuotantomenetelmiä ja milloin raskaammat menetelmät ova sopivampia.
Artikkelissa kuvataan syitä kevyille ohjelmistotuotantomenetelmille keskittyen niiden mukautuvaan luonteeseen ja ihmiskeskeiseen lähestymistapaan.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent