stanford-oval/wikipedia huggingface dataset:
Oravaisten taistelu
Aiheesta muualla

Kuvia tai muita tiedostoja aiheesta Oravaisten taistelu Wikimedia Commonsissa
Suomen sota
| --- | --- |
Taistelut: Ahvenanmaan kansannousu • Ahvenanmaan valtaus • Alavuden taistelu • Aron kahakka • Gotlannin miehitys • Helsinginrannan maihinnousu • Hörneforsin taistelu • Jauhiaisen salmen taistelu • Juuttaan taistelu • Jynkän taistelu • Kalmalahden taistelu • Kanttin kapina • Karstulan taistelu • Kauhajoen kapina • Kauhajoen taistelu • Kokkonevan taistelu • Koljonvirran taistelu • Kuopion valtaus • Lapuan taistelu • Lemun taistelu • Lintulahden taistelu • Nummijärven taistelu • Oravaisten taistelu • Palvan meritaistelu • Parjakannevan taistelu • Pitsundin taistelu • Pulkkilan taistelu • Pyhäjoen taistelu • Pälkjärven taistelu • Revonlahden taistelu • Rothin ja Spoofin sissiretki • Ruonan taistelu • Samelinlakson taistelu • Sandön taistelu • Siikajoen taistelu • Svartholman piiritys • Toivalan taistelu • Uumajan valtaus • Vaasan taistelu • Venäläiskivi • Viaporin piiritys • Vornan taistelu
Muuta: Haminan rauha • Kainuun sopimus • kansannousut • Lohtajan aselepo • Olkijoen aselepo • Ruotsin vallankaappaus 1809 • Suomen lähetyskunta
| --- | --- |
Auktoriteettitunnisteet: Taiteenala :  KulturNav
Ohjelmistotuotanto

Ohjelmistotuotanto on yhteisnimitys niille työnteon ja työnjohdon menetelmille, joita käytetään, kun tuotetaan tietokoneohjelmia sekä monista tietokoneohjelmista koostuvia tietokoneohjelmistoja. Laajasti ymmärrettynä ohjelmistotuotanto kattaa kaiken tietokoneohjelmistojen valmistukseen liittyvän prosessinhallinnan sekä kaikki erilaiset ohjelmistokehitysmenetelmät. Ohjelmistotuotantoon kuuluu siis periaatteessa mikä tahansa toiminta, joka tähtää tietokoneohjelmien tai -ohjelmistojen valmistukseen. Tarve valmistukseen tulee asiakkaalta tai ohjelman tuottaja tekee markkinointitutkimuksen ja päättelee tarpeen ohjelmistolle.
Jotta ohjelmistojen valmistusta voitaisiin käsitellä järjestelmällisesti, ohjelmistotuotannossa on pyritty mallintamaan ohjelmistojen valmistusprosessia niin sanotun elinkaarimallin mukaisesti. Elinkaarimallissa ohjelmiston valmistus pyritään näkemään mahdollisimman laajana, aikaan sidottuna prosessina, jossa ohjelmiston varsinainen tekninen valmistus on vain pieni – joskin äärimmäisen tärkeä osa – kokonaisketjua.
Ohjelmistotuotannossa tieteenhaarana tutkitaan myös ohjelmien rakenteellisia ominaisuuksia kuten dokumentointia, versionhallintaa, sekä jäljitettävyyttä. Tutkimuksen kohteena ovat myös erilaiset ohjelmistojen tukiprosessit, kuten määrittelyprosessi, ylläpitoprosessi ja projektinhallinta. Myös erilaisia toteutus- ja suunnittelumenetelmiä, joilla itse tuotannon laatua voidaan tehostaa, tutkitaan.
Ohjelmistotuotantoon kuuluvat myös erilaiset laatujärjestelmät, joita käytetään erityisesti yrityksissä dokumentoimaan yrityksen toimintatapoja. Laatujärjestelmän tavoitteena on dokumentoida ja ottaa käyttöön hyväksi havaitut toimintatavat, jotka parantavat yrityksen toimintaprosessin laatua.
Kaupallista ohjelmistokehitystä tehdään yleensä projektityönä. Toisaalta useiden ohjelmistojen kehitys ja ylläpito jatkuvat koko niiden elinkaaren ajan ilman ennakoitavaa päätepistettä. Ylläpitotyökin voidaan jakaa määrämittaisiksi toisiaan seuraaviksi projekteiksi. Projektin toteuttamista ohjaavat ohjelmistoprosessit, jotka kuvaavat toistuvan tavan toteuttaa ohjelmistoprojekteja. Prosessit vaihtelevat suuresti laajuudeltaan ja sen suhteen, millaisia menettelytapaohjeita ne antavat. Noudatettava prosessimalli voi olla kevyt, jos kehityshankkeet ovat pieniä ja niiltä odotetaan suurta kustannustehokkuutta. Raskaita prosesseja käytetään toimialoilla, joissa ohjelmistoilta odotetaan poikkeuksellisen suurta luotettavuutta.
Ohjelmistotuotannon historia

Ensimmäiset digitaaliset tietokoneet tulivat käyttöön 1940-luvulla. Näiden koneiden suorittamat tehtävät määriteltiin muuttamalla koneiden sähköisiä kytkentöjä. Von Neumannin arkkitehtuurin mukaiset ohjelmoitavat tietokoneet kehitettiin 40-luvun lopulla, jolloin myös ensimmäiset tietojärjestelmä- ja ohjelmistokehityshankkeet käynnistettiin.
Ennen vuotta 1954 lähes kaikki ohjelmointi tehtiin matalan tason ohjelmointikielillä kuten konekielellä tai assemblyllä. Suuri osa ohjelmoijien työstä liittyi tuon ajan tietokoneiden rajoitteisiin.
Termi software engineering (ohjelmistosuunnittelu) on esiintynyt vuonna 1965 Computers and Automation -lehden yritysluettelossa. Myöhemmin termi esiintyi vuonna 1966 ACM:n puheenjohtajan Anthony A. Oettingerin kirjeessä Communications of the ACM -lehdessä. Oettinger kirjoittaa tietojenkäsittelytieteen olevan yksistään liian rajaava termi ja huomauttaa ammattimaisen insinöörialan luonteesta ohjelmiston ja laitteiston suunnittelussa.
Ohjelmistokriisi tunnistettiin 1960-luvun loppupuolella. Sillä tarkoitettiin tilannetta, jossa pula ohjelmoijista ja selkeiden systeemityömenetelmien puuttuminen johti heikkoon tuottavuuteen, paljon ohjelmointivirheitä sisältäviin ohjelmiin ja kustannusten karkaamiseen käsistä. 1900-luvun loppupuolella alkanut tietokoneohjelmien merkityksen ja lukumäärän kasvu ovat tuoneet julkisuuteen lukuisia tietokoneiden aiheuttamia virheitä, jotka ovat lähes aina olleet seurausta inhimillisistä erehdyksistä: tietokoneohjelmien lähdekoodeissa on ollut virheitä tai ohjelmien käytettävyys on ollut huono. Ohjelmistotuotanto tutkimusalueena on kehitetty vastaamaan kysymykseen, miten ohjelmistoja tulisi valmistaa niin, että niiden laatu olisi mahdollisimman korkea. Ohjelmiston laatu pitää tässä yhteydessä käsittää ohjelmiston tavoiteltavana toimintana, mikä ei ole sama asia kuin lähdekoodin tai käyttöliittymän täydellinen virheettömyys.
Ohjelmistotuotannon merkityksestä

Ohjelmistoteollisuus on Suomen nopeimmin kasvava vientiala.
Ohjelmistoalan merkittävin alatoimiala on ohjelmistojen suunnittelu ja valmistus.
Vaihejakomallit

Ohjelmiston tai ohjelman tuottaminen on laaja ja monimutkainen tehtävä. Onnistuneen tuotannon varmistamiseksi kehitystyö jaetaan osiin. Seuraavaan osaan ei voida edetä, ennen kuin edellinen osa on tarpeellisin osin saatu valmiiksi. Tätä ositusta ohjelmien suunnittelussa sanotaan vaihejakomalliksi.
Vaihejakomallit > Vesiputousmalli

Tässä perinteisessä prosessissa vaiheet soljuvat eteenpäin kuin vesiputous tasolta toiselle (vain yhteen suuntaan), ja siksi tätä prosessia kutsutaankin vesiputousmalliksi. Ajatuksena on, että kukin vaiheista tuottaa dokumentin tai joukon dokumentteja, jotka toimivat syötteenä seuraavalle vaiheelle. Esimerkiksi vaatimusanalyysi määrää ja asettaa vähimmäisvaatimukset ja rajat toiminnalliselle määrittelylle, jotta määrittelyn lopussa voidaan tarkastaa, vastaako määritelty ohjelmisto vaatimusanalyysin mukaista järjestelmää. Toisaalta taas toteutusvaiheessa (koodaus) teknisen määrittelyn pitäisi kattaa ne tarvittavat tiedot, joiden perusteella ohjelmisto voidaan kirjoittaa.
Vesiputousmallissa suurin vaikeus on suunnitella koko tuote kerralla toteutuskuntoon.
Käytännössä tuotantoprosessi on usein iteratiivinen, eli suunnittelua ja toteutusta tehdään pienimmissä osissa ja prosessia toistetaan. Näin ohjelmisto kehittyy inkrementaalisesti eli koko ajan kasvaen kohti lopullista muotoaan. Tästä käytännön sanelemasta tarpeesta ovat syntyneet useat iteratiiviset prosessimallit, kuten Rational Unified Process, spiraalimalli tai niin sanottu ketterä kehitys.
Kun vesiputousmalliin yhdistetään joka vaihetta vastaava testaus (esimerkiksi vaatimusmäärittelystä hyväksymistestaus) aikajanalle syntyy niin kutsuttu V-malli, jonka vasen sakara kuvastaa prosessin vaiheita ja oikea kunkin testausta. Prosessia, joka toistaa alemman tason suunnittelua ja toteutusta, kutsutaankin W-malliksi, jossa keskisakara kuvastaa iteraatiota.
Vesiputousmalli kuvastaa ohjelmistotuotantoa teoreettisella tasolla hyvin, mutta sen soveltuvuudesta käytännön ohjelmistotuotantoon ollaan erimielisiä. Vesiputousmallin tärkein ansio onkin antaa puitteet, joita myös iteratiiviset prosessit noudattavat, vaikkakin huomattavasti tiheämmissä sykleissä ja kevyemmillä menetelmillä. Voidaankin sanoa, että kaikki ohjelmistotuotantohankkeet noudattavat jollain tasolla vesiputousmallia, mutta eivät välttämättä toteuta kaikkia sen vaiheita dokumentoiduilla menetelmillä.
Vaihejakomallit > Prototyyppimenetelmä

Prototyyppimenetelmässä ohjelman kehittäminen etenee spiraalimaisesti. Prototyyppimallissa ulkoasu (käyttöliittymä) rakennetaan ensin ja vasta sitten spiraalimaisesti laajenevin kehin tuotteen liiketoiminnallinen kerros (bisneslogiikka) sekä tietokantakerros. Menetelmän etuna asiakas saa nopeasti nähtäväksi tuotteen lopullisen ulkoasun. Asiakas voi jo tässä vaiheessa kertoa, jos kehittelijät ovat toteuttaneet jotain toisin kuin hän on halunnut. Mahdolliset muutokset on vielä helppo ja kustannuksiltaan edullista ja työmäärältään vähäistä tehdä tässä vaiheessa. Prototyyppimenetelmä on hyvä myös silloin kun (asiakkaan) vaatimukset muuttuvat usein.
Kun asiakas on hyväksynyt kehityskierroksen esitetyn prototyypin, kehittelyä jatketaan spiraalin laajenevalla kehällä. Syvennetään ja laajennetaan suunnittelua. Kun kehitysprosessi on kiertänyt kokonaisen ympyrän, seuraavaa prototyyppiä esitellään asiakkaalle. Näin jatketaan iteratiivisesti, kunnes päädytään tuotteen lopulliseen kehitysversioon. Kun asiakas on hyväksynyt tuotteen, se on valmis.
Vaihejakomallit > RUP

RUP (Rational Unified Process) perustuu peräkkäisiin iteraatioihin, joista jokainen iteraatio suunnitellaan vesiputousmallin mukaisesti. Kehittäminen jakautuu neljään vaiheeseen: aloitus, tarkennus, rakennus ja käyttöönotto.
Vaihejakomallit > Ketterät menetelmät

Nopeasti muuttuvassa ympäristössä ennalta suunnittelun vaikeus on noussut suurimmaksi esteeksi perinteiselle vesiputousmallille. Iteratiivinen prosessi antaa mahdollisuuden muuttaa projektin kulkua ja suuntaa hallitusti kesken prosessin. Ohjelmisto ei useinkaan tule kerralla valmiiksi, ja monet ohjelmistotuotteet jatkavat kehitystään julkaisun jälkeenkin. Nopeimmin kehittyvillä ohjelmistotuotannon aloilla ja etenkin pienemmissä ohjelmistoprojekteissa on omaksuttu niin kutsuttuja ketteriä ohjelmistoprosesseja, jotka korostavat muutosten hallintaa ja nopeita iteraatiosyklejä. Periaate on suunnata ja korjata kehittelyä mahdollisimman aikaisessa vaiheessa. Virheellistä kehitystyötä on tehty silloin vasta mahdollisimman vähän ja kehittelyn resurssien (muun muassa aika- ja kustannusresurssit) hukkaaminen on mahdollisimman vähäistä.
Yksi uusimpia ketteriä menetelmiä on Scrum.
Vaihejakomallit > Muita menetelmiä

Muita ohjelmankehitysmenetelmiä on muun muassa Suihkulähdemalli. Menetelmässä ohjelma koodataan suoraan ja sen jälkeen luodaan dokumentointi. Varsinaista mallinnusta ja suunnittelua ei tässä menetelmässä ole. Suunnittelu tapahtuu koodaajan mielessä. Suihkulähdemalli soveltuu pienien (apu)ohjelmien tekoon. Laajempien ohjelmistojen suunnittelun hallinta ei onnistu suihkulähdemenetelmällä.
EVO-mallissa rakennetaan ensin ydinjärjestelmä, jota kehitellään edelleen seuraavissa projektin iteraatioissa.
Ohjelmiston elinkaaren vaiheet

Ohjelmiston elinkaari jakautuu kahteen pääluokkaan: kehitys ja ylläpito. Ohjelman kehitykseen kuuluvat vaatimusmäärittely, ohjelmistosuunnittelu, toteutus, testaus, julkistus ja käyttöönotto.
Ennenaikainen-Alpha on teknologianäyte ohjelmiston yhdestä tai kahdesta ydintoiminnosta. Vaihe koostuu ennen kaikkea toimintojen suunnittelusta. Alpha on ohjelmiston kehityksen ensimmäinen vaihe, jonka aikana ohjelmisto suunnitellaan pääpiirteissään ja jonka aikana ohjelmiston toiminnot luodaan. Beta on vaihe, jonka aikana ohjelmiston toiminnallisuus on suunniteltu loppuun. Vaiheen aikana on tarkoitus viimeistellä toiminnot ja tuottaa ohjelmisto tilaan, jossa se kykenee toimimaan käytännön tilanteessa omillaan.
Ohjelmiston elinkaaren vaiheet > Vaatimusanalyysi

Vaatimusanalyysin eli vaatimusmäärittelyn tarkoituksena on selvittää ne ohjelmistotuotteelle asetetut ohjelmistovaatimukset, mitkä valmiin järjestelmän tulisi täyttää. Vaatimusanalyysin tarkoituksena ei ole ottaa millään tavoin kantaa siihen, miten nämä tavoitteet saavutetaan. Näin toimitaan siksi, että on edullisinta siirtää toteutusmenetelmiin liittyvät päätökset mahdollisimman myöhäiseen vaiheeseen. Tyypillisesti ohjelmiston tekninen toiminta muuttuu sen elinkaaren myötä monistakin syistä, ja muutosten tekeminen on sitä kalliimpaa taloudellisesti, mitä aikaisempaan vaiheeseen ne joudutaan kohdistamaan.
Toisinaan vaatimuksiin voi toki kuulua rajoituksia, jotka esimerkiksi sitovat toteutuksen tiettyyn ohjelmointikieleen esimerkiksi asiakkaan erityistarpeiden vuoksi.
Esimerkiksi ohjelmistotuotteelle asetettuja vaatimuksia voisivat olla seuraavat: ohjelmiston pitää kyetä numeeriseen sekä symboliseen laskentaan ja lukemaan käyttäjältä tarvittavat syötteet. Nyt huomattavaa on, että tässä vaatimuksessa ei ole kuvattu esimerkiksi sitä, millaisessa muodossa syöte tulee antaa, onko järjestelmä graafinen vai ei, pitääkö tiloja kyetä tallentamaan jne. Yksi suurimpia vaikeuksia vaatimusanalyysissä (kuin myös muissa vaiheissa) onkin huomata se, onko saatujen tietojen määrä riittävä, jotta seuraavaan vaiheeseen voidaan edetä. Sen vuoksi kukin vaiheista yleensä hyväksytetäänkin loppuvaiheessa, yleensä vähintäänkin ensimmäiset vaiheet myös asiakkaan kesken.
Vaatimusanalyysi tulee tehdä tiiviissä yhteistyössä ohjelmiston asiakkaan kanssa. Analyysi ei juurikaan muutu, vaikka asiakas olisi kuvitteellinen (esimerkiksi siksi, että tuotteella ei ole etukäteen tiedossa asiakasta). Analyysissä on tärkeää osata sivuuttaa turhat toteutustekniset vaatimukset – esimerkiksi asiakas saattaa toivoa laitteeseen kymmentä eri painonappia, vaikka parempi olisi nappien toiminnallisuudet toteuttava valikko.
Vaatimusanalyysi tuottaa lopputuloksenaan dokumentin asiakasvaatimukset.
Ohjelmiston elinkaaren vaiheet > Järjestelmäsuunnittelu

Järjestelmäsuunnittelussa tarkastellaan järjestelmien välistä työnjakoa ja integrointia sekä laitteiston ja ohjelmiston välistä työnjakoa. Järjestelmäsuunnittelussa voidaan päättää hajauttaa eri ohjelmistoja eri laitteille tai asentaa samaa ohjelmistoa usealle laitteelle.
Järjestelmäsuunnittelua voidaan tehdä esimerkiksi kahdella tasolla:
Järjestelmäkartan tasolla pohditaan mitä laitteita ja ohjelmistoja tarvitaan ja kuinka ne liittyvät toisiinsa.
Yksittäisen laitteen tasolla päätetään muun muassa laitteistosta, käyttöjärjestelmästä ja ohjelmistoista, yhteyksistä ja tietoturvasta.
Järjestelmäsuunnittelu on tavallinen vaihe räätälöityjen ohjelmistojen tuotannossa. Valmisohjelmien tuotannossa sitä ei yleensä tarvita.
Ohjelmiston elinkaaren vaiheet > Toteutus

Määrittelydokumentin valmistuttua toteutus voi alkaa. Toteutus käsittää lähinnä varsinaisen koodaamisen valitulla ohjelmointikielellä sekä tarvittavien oheiskomponenttien tuottamisen (käytetyt kuvat, äänet jne). Mikäli edelliset vaiheet on toteutettu kunnolla, niin toteutukseen menevä aika on noin 10–20 % koko ohjelmistoprojektiin käytetystä ajasta. Tämän vaiheen tuotoksena on siis ajettava ohjelmisto, mutta siinä on kuitenkin yleensä suhteellisen paljon toiminnallisia virheitä.
Ohjelmankehitysympäristöissä toteutusvaihe voi olla puoliautomaattinen. Kehitysympäristö osaa kehittää luoduista suunnitelmista ohjelmakoodin rungon, jossa luokkakaaviosta on johdettu valmiit koodit luokille, luokan tietojäsenille sekä metodirungot parametreineen. Se nopeuttaa huomattavasti koodaajan työtä kun hänen pitää lisätä vain metodien toiminnallinen sisältö koodeihin.
Ohjelmiston elinkaaren vaiheet > Testaus

Alpha-testaus on ohjelmistokehityksen vaihe, jonka aikana tutkitaan luotujen toimintojen kykyä toimia oikein käytännön tilanteessa. Vaiheen aikana on tarkoitus kartoittaa myös ohjelmiston sisäinen koodi dokumentoituun muotoon. Beta-testausvaiheen aikana ohjelmistosta etsitään ja korjataan pois mahdolliset ohjelmointivirheet eli bugit, joita on saattanut aiheutua mahdollisista Beta-vaiheen aikana tehdyistä muutoksista. Beta-testaus on ohjelmistonkehityksessä eräs eniten aikaa vaativista vaiheista.
Virheitä löytyy toteutuksen huolellisuudesta riippumatta käytännössä kaikista ohjelmistoista. Esimerkiksi yritykselle on erittäin tärkeää löytää virheet (ja korjata ne) itse sen sijaan, että asiakas löytää ne ja kertoo sitten huonoista kokemuksistaan muille.
Vaikka testaus onkin osana kaikkea ohjelmistokehitystä, niin sen harteille ei pidä sälyttää vastuuta lopputuotteen hyvästä laadusta. Laatuajattelun on oltava mukana aivan ensimmäisestä vaiheesta alkaen, sillä tutkitusti testattaessa ei löydetä kuitenkaan käytännössä koskaan kaikkia virheitä, ja myös virheiden korjaaminen aiheuttaa usein uusia virheitä.
Testaukseen kuuluu muun muassa testausmenetelmien suunnittelu, erilaisten testidokumenttien sekä testipenkkien laatiminen.
Testitulosten mukaan ohjelmistoon tehdään tarvittavat muutokset – jos muutoksia pitää tehdä ylemmille tasoille kuten toiminnalliseen määrittelyyn, niin se on yleensä merkki koko projektin yli ulottuvasta heikosta laadusta.
Siinä missä toteutuksessa on tarkoituksena tehdä mahdollisimman virheetön ohjelmisto, testauksessa on tarkoitus löytää mahdollisimman paljon virheitä. Testaus vaatii siis testaajalta destruktiivisen eli hajottavan asenteen. Monet virheet vaativat korjaamista, joten hyvin suoritettu testaus aiheuttaa lisätöitä ohjelmiston toteuttajille. Tämän vuoksi on usein järkevää, että organisaatiossa testauksesta huolehtii eri yksikkö kuin toteutuksesta. Pienissä organisaatioissa tämä ei välttämättä onnistu, mutta mahdollisuuksien mukaan ohjelmoijat voivat kuitenkin testata toistensa valmistamat ohjelmistot tai niiden osat.
Ohjelmiston testaus voidaan jaotella myös muun muassa seuraaviin:
Yksikkötestaaminen
Integraatiotestaaminen
Regressiotestaaminen
Hyväksyntätestaaminen
Ohjelmiston elinkaaren vaiheet > Julkaisu tai käyttöönotto

Julkaisuehdokkuudesta puhutaan kun ohjelmisto on saavuttanut tietyn toiminnallisen tilan, jossa kaikki ohjelmiston ominaisuudet toimivat lähes virheettömästi ja ohjelmisto on valmis julkaistavaksi. Useimmissa tapauksissa julkaisua ei kuitenkaan voi tapahtua, ennen kuin kaikki ohjelmistoa kehittävät tahot ovat siihen tyytyväisiä. Joskus ohjelmiston valmistuminen ajallaan on tärkeämpää kuin riittävä testaus, jolloin Julkaisuehdokkuus kyseenalaisesti ohitetaan.
Julkisesti saataville tarkoitetun ohjelmatuotteen valmistuttua se yleensä julkaistaan. Julkaistaessa kerätään ohjelman osat ja dokumentointi yhdeksi paketiksi sekä tiedotetaan uuden ohjelman tai ohjelmaversion saatavuudesta, lisenssiehdoista sekä ominaisuuksista. Näitä toimenpiteitä varten on olemassa työkaluja ja hallintajärjestelmiä.
Tuotantoon julkaisemista kutsutaan myös nimellä kultaaminen, joka tulee siitä, että alkuperäinen ohjelmiston Master-levy viedään monistettavaksi ja paketoitavaksi tehtaalle tai se valmistellaan internet-pohjaista levitystä varten. Ohjelmisto saatetaan kääntää eri kielille, lisäksi sen ohjekirjat kirjoitetaan ja tulostetaan. Myös markkinoinnin suunnittelu kuuluu osaksi tätä vaihetta.
Lisenssiehdot määräävät kaupalliset ja juridiset ehdot ohjelman jakelulle, asentamiselle ja käyttämiselle. Kaupallisen (ks. omisteinen ohjelmisto) jakelun lisäksi on avoimen lähdekoodin lisenssejä kuten GNU GPL. Freeware-ohjelmistot ovat maksuttomia, mutta niiden lähdekoodi ei ole aina saatavilla.
Jos ohjelmisto on rakennettu tietylle asiakkaalle, julkaisun sijaan tehdään käyttöönotto. Käyttöönotossa ohjelmistosta valmistellaan asennettava kokonaisuus, joka sitten suunnitellusti asennetaan määrätyille laitteille. Käyttöönottoon liittyy usein myös muun muassa laitteiston asennus ja valmistelu, tietoyhteyksien valmistelu, vanhojen tietojen konvertointi ja käyttäjien valmentaminen.
Ohjelmiston elinkaaren vaiheet > Ylläpito

Ohjelmien ja ohjelmistojen ylläpito ei kuulu enää ohjelmistotuotantoon eikä ohjelmien kehittelyyn vaiheena. Ylläpidon tarkoitus on pitää ohjelmisto toimintakuntoisena ja raportoida virheistä tuotannolle. Ylläpitoon kuuluu ohjelmien uusien versioiden päivitys vanhojen tilalle ja päivityksestä aiheutuvat muutostoimet. Ylläpito käsittää ne toimenpiteet, mitä asiakkaat tarvitsevat ollakseen tyytyväisiä ohjelmistotuotteeseen. Tyypillisesti ohjelmistojen katsotaan vanhenevan ennen pitkää, ja tarpeet myös muuttuvat; lisäksi laadukkaastakin ohjelmistotuotteesta löytyy yleensä vähintäänkin pieniä ohjelmistovirheitä, joten käyttäjät odottavat uusia versioita täyttämään muuttuvat tarpeet ja esiintyneet ongelmat.
Ohjelmiston elinkaaren vaiheet > Elinkaaren loppu

Ohjelma ei ”kuole” koskaan. Ohjelma voi tulla tarpeettomaksi kun
käyttöympäristö muuttuu siten, että ohjelmaa ei voida enää käyttää
tulee uusi parempi menetelmä suorittaa ohjelman tekemät asiat
ohjelman tekemien toimenpiteiden tarve loppuu
ohjelman toiminnot yhdistetään uuteen ohjelmaan
ohjelman käyttö ja kehittely loppuu.
Ohjelmistotuotannon työkalut

Prosessia helpottamaan on kehitetty erilaisia työkaluja. Perustyökaluja ohjelmistotuotannossa ovat mallit, joiden avulla prosessin vaiheita voi hallita. Esim. vesiputousmallissa vaiheet suoritetaan yksi kerrallaan loppuun asti – testausvaiheesta ei voi palata analyysiin.
Muita ohjelmistotuotannon työkaluja ovat UML ja CASE. UML (Unified Modeling Language, yhtenäistetty mallinnuskieli) auttaa visualisoimaan suunnitelmia. UML on kokoelma yksinkertaisia graafisia merkintöjä, kuten laatikoita ja nuolia, joilla on määrätty merkitys. UML on kehitetty olio-ohjelmointiin. UML-mallinnuksia voi tehdä esimerkiksi ohjelmilla MS Visio, Argo UML, Eclipseen asennettavalla liitännäisohjelmalla, NetBeans, yms.
CASE (Computer Aided Software Engineering, tietokoneavusteinen ohjelmistotuotanto) on ollut käytössä 1970-luvulta alkaen. CASE-työkalut ovat ohjelmia, joiden avulla voi organisoida ja visualisoida ohjelmistotuotannon prosesseja. Eri ohjelmointikielille ja -ympäristöille on omat CASE-työkalunsa.
Tunnettu ohjelmankehitysympäristö on Eclipse.
Kirjallisuutta

Hong, Zhu: Software Design Methodology: From Principles to Architectural Styles.  Oxford:  Elsevier, 2005.  ISBN 0-7506-6075-9  (englanniksi)
Pressman, Roger: Software Engineering: a Practitioner's Approach.  Upper Saddle River:  Prentice Hall, 2005.  (englanniksi)
Sommerville, Ian: Software Engineering.  USA:  Addison-Wesley, 1992.  ISBN 0-201-56529-3  (englanniksi)
Haikala, Ilkka & Märijärvi, Jukka: Ohjelmistotuotanto.  Satku, 2000.  ISBN 951-762-769-6
Rytkönen, ﻿Marko & Kakkonen & Kari: ACT 2 LEAD: ohjelmistotestauksen johtamisen käsikirja.  (1. painos., sarja: CxO Academy Kirjat)  Tuusula:  Ketterät Kirjat, 2023.  ISSN 2323-7627; 32  ISBN 978-952-7518-05-2
Brooks, Fred: The Mythical Man-Month.  Addison-Wesley, 1975.  ISBN 0-201-00650-2
Aiheesta muualla

Kuvia tai muita tiedostoja aiheesta Ohjelmistotuotanto Wikimedia Commonsissa
Matti Ylöstalo

Matti Ylöstalo vuonna 1964.
Matti Viljo Ylöstalo (4. helmikuuta 1917 Tampere – 14. syyskuuta 2002 Helsinki) oli suomalainen oikeustieteilijä, joka toimi Helsingin yliopiston siviilioikeuden professorina vuosina 1959–1980. Ylöstalo toimi myös Suomen Asianajajaliiton sihteerinä ja useissa muissa luottamustehtävissä.