Tarkvaraarenduse elutsüklis on erinevaid tegevusi, mille tulemusel tekib "artefakte", mis dokumenteerivad projektis tehtavaid/tehtud tegevusi ja nende tegijaid.
Dokumentatsioon tekib peaaegu igas tarkvaraarenduse elutsükli etapis ja neid esineb igas elutsükli tüübis. Need "artefaktid" moodustavad tarkvara dokumentatsiooni.
On olemas erinevaid tüüpe dokumentatsioone, tüüpiliselt võib tarkvaraprojektis esineda:
Erinevate arendustsüklite analüüsietapi väljund, kus defineeritakse koostöös lõppkasutaja/kliendiga arendatava süsteemi erinevad nõuded. Arvestatakse mõlema osapoole vajadusi ning selgitatakse välja erinevad takistavad tegurid.
Dokumendi eesmärk on anda arendajatele arhitektuurse disaini dokumendi loomise jaoks juhised selle kohta, mida arendama peab.
Kirjeldab dokumendi eesmärgi (milleks, kellele), projekti ulatuse. Terminite sõnastik. Viited teistele dokumentidele (diagrammid, kasutajajuhendid, haldusjuhendid jne).
Kirjeldab tarkvaratoodet, mida dokumendi abil arendatakse.
Kirjeldatakse kasutaja soovid tarkvaratootest, mida klient sellest saab. Mis on nende osapoolte erinevad vajadused ja kas neid on eelnevaid kogemusi sarnaste toodetega samast tootekategooriast.
Näiteks rollipõhine tabel sotsiaalmeedia rakenduse jaoks:
| Roll | Tegevused/õigused |
|---|---|
| Külaline |
|
| Registreeritud kasutaja |
|
| Administraator |
|
| Süsteemi administraator |
|
Profiilide detailne kirjeldamine aitab arendajatel paremini aru saada kasutajakogemusega seotud eesmärkidest tarkvaratoote arendamisel, et lõpuks jõuaks lõppkasutajani ootustele vastav toode.
Kirjeldatakse erinevad piirangud või tõkestavad aspektid, mis võivad arendusel ette tulla, kasutajatel esineda, arendusvahenditest tulenevad ja seaduslikud piirangud.
Toote loomist võib nõuda mingisugune eelnev tingimus, näiteks viiakse sisse riigisüsteemis muudatus, kuid digitaalne vahend selle jaoks puudub. Leitakse, et on vaja arendada vastav tööriist, et tagada riigisüsteemi muutuse ülalhoid.
Kirjeldab keskkonda, millel arendatud toode toimima peab. Sinna võivad kuuluda:
Kirjeldab detailselt erinevaid funktsionaalseid nõudeid, näiteks nõuded seotud turvalisuse ning programmi kasutatavusega. Kirjelduste hulgas võib esineda ka kasutajalugusid ja UML skeeme.
Tarkvaraprojekti sisemise struktuuri kirjeldus. Kirjeldab erinevaid mooduleid, komponente ja nende omavahelisi seoseid. Samuti kirjeldatakse, kuidas süsteem suhtleb süsteemiväliste elementidega (liidesed, APId, riistvarad jne).
Kirjeldab dokumendi eesmärgi (milleks, kellele), projekti ulatuse. Terminite sõnastik. Viited teistele dokumentidele (diagrammid, kasutajajuhendid, haldusjuhendid jne).
Kirjeldatakse, milliseid arendusvahendeid kasutatakse projekti arendustöös. Põhjendatakse vahendite valikut.
Kokkuleppelised konventsioonid, mida tuleks kogu arendusprotsessi käigus jälgida, näiteks:
Kirjeldatakse teised välised süsteemid ja kuidas arendatav tarkvaratoode nendega suhtlema peaks, sealhulgas ka mis kujul need välised süsteemid infot vastu võtavad ja tagastavad.
Kuidas tarkvaratoode erinevateks sisemisteks komponentideks jaguneb ja milline on nende komponentide omavaheline struktuur. Iga komponendi ülesanne ja eesmärk, kuidas ta suhtleb teiste komponentidega.
Põhjendatakse erinevaid arhitektuuriotsuseid. Pakutakse välja ka olemasolevatele otsustele alternatiive juhuks, kui esialgne plaan osutub ebasobivaks/ebaõnnestub.
Kliendi poolt esitatud jõudlusnõuded, näiteks kui palju kasutajaid suudab sotsiaalmeedia platvorm korraga hallata. Kõik jõudlusnõuded peaksid olema testitavad simuleeritud koormusega.
Kuidas väljendab programm oma funktsionaalsust lõppkasutajale, kuidas esitatakse programmivigu kasutajale.
Kui palju arendatav toode vajab erinevaid süsteemi raudvara ressursse, näkteks:
Kuidas hoitakse lõppkasutaja andmed ja raudvara toimiva ja turvalisena, kuidas tehakse kindlaks, et lõppkasutaja saab kätte ainult need andmed, mida tal programmis oleva tegevuse jaoks vaja on.
Näiteks krüpteeritakse tundlikud andmed esmasel sisestusel ning iga järgmine kord võrreldakse kasutaja sisestusi admebaasis juba olemasoleva krüpteeritud kujuga.
Kas ja millistel teistel (riist- /tarkvaralistel) platvormidel on programmi võimalik käivitada.
Arenduse käigus tekkivate muutuste tekkimisel tuleks need muudatused kanda ka arhitektuurse disaini dokumenti. Selle jaoks peaks olema süsteemi nõudete ja arhitektuursete otsuste vahel ristviited - vajadusel on võimalik mingi nõude muutmisel muuta temaga seotud arhitektuurilisi lahendusi, ning vastupidi.
Arhitektuurilise disaini dokumenteerimise eest vastutab tavaliselt tarkvaraarhitekt.
Dokument, mis aitab lõppkasutajal kasutada ning navigeerida valminud tarkvaratootes. Kirjeldab, kuidas erinevaid programmisiseseid tegevusi sooritada, mille jaoks programmi kasutada saab, kuidas lahendada korduma kippuvaid küsimusi jne.
Kasutajajuhend on kirjutatud selle põhjal, mis on kasutajale näha ja saadaval, kuid selles pole kirjeldatud programmisisesed detailid.
Dokument, mille eesmärk on valmivast programmist anda ülevaade isikule, kes otseselt pole seotud arendusprotsessiga, kuid kes on kliendi poolt määratud hiljem valmis süsteemi hooldama.
Dokumendis käsitletakse:
Käsitleb projekti haldamisega seotud dokumente - ajakava planeerimine, seotud ressursid, arendustöö hetkejärk jne.