Tarkvaraarenduse meetodid (0)

1. Tarkvara arenduse meetodid 1.1 Struktuurprojekteerimine
Terve arendatav programm/tarkvara valmib struktuurprojekteerimise korral korraga. 
Projekteerimise etapid (analüüs, disain, arendus jne) on selgelt piiritletud ja järgmine 
etapp ei käivitu enne kui eelnev on lõppenud. 
Sellisel projekteerimisel on ka tõsised puudused, näiteks kui tehakse disaini käigus, siis 
need vead ilmnevad tihti alles arenduse lõppfaasis, mis omakorda raskendab ja 
pikendab projekti valmimist. Lahenduste korduvkasutus on komplitseeritud, lahendused 
koosnevad harva moodulitest ning funktsionaalsuse lisamine muutub aina 
keerulisemaks. 
Eelnevalt mainitud puuduste kõrvaldamiseks kasutatakse tihti meetodit nimega 
prototüüpimine, kus lahendustele tehakse kiiranalüüs. Prototüüpimine kujutab endas 
piiratud funktsionaalsusega prototüübi valmistamist, mida testitakse tellija juures ja 
edasiste lahenduse puhul lähtutakse ka prototüübi tagasisidest. 1.2 Objekt-orienteeritud projekteerimine
Objekt-orienteeritud projekteerimisel korral lähtutakse sellest, et arendus toimub objekt-
orienteeritud arendusvahenditega. See tähendab seda, et teostatakse analüüsi ja disainimise 
etapid vahenditega, mis toetavad hilisemat lahenduste teostamist objekt-orienteeritud 
vahenditega. Suuremad lahendused jagatakse väiksemateks eraldiseisvateks lahendusteks, 
mida on võimalik arendada iseseisvalt.
Erinevat struktuurprojekteerimisest on tellija kaasatud tihedalt arendusetappidesse. Lahendus ei
valmi kunagi tervikunga korraga, vaid pigem tsüklitena, kus iga tsükliga lisatakse lahendusele 
täiendavaid funktsioone, seda nimetatakse ka iteratiivseks arendusprotsessiks. 2. Agiilne meetod Agiilsed meetodid keskenduvad kõige enam riskide(vead, eelarve ja muudatuste) 
minimaliseerimisele ning funktsionaalsuse lisamisele. Agiilsetel meetoditel arenvada 
meeskonnad tarkvara iteratsioonidena, mis tähendab, et iga iteratsiooniga lisatakse tarkvarale 
rohkem funktsioone järk-järgult.


2.1 Scrum 
Scrum keskendub enamjaolt agiilsele projektijuhtumise raamistikule, mida saab kasutada igat 
liiki iteratiivsete ja inkrementaalsete projektide haldamiseks. Töötava toote omanik on alati 
tihedas koostöös oma meeskonnaga, et tuvastada ja seada prioriteedi süsteemi 
funktsionaalsusele, enamjaolt saadakse selline funktsionaalsus luues tootele backlog’i.
See koosneb sellest juhistest, mida tuleb teha, et edukalt toimivat tarkvarasüsteemi realiseerida.
Kogu arendustegevus jagatakse tavaliselt sprint’ideks, mille kestvus võib olla sõltuvalt üks kuni 
kaks nädalat. 2.2 Lean ja Kanban
Lean arendus keskendub vaid tähtsatele asjadele.klientide jaoks. Need tähtsad funktsioonid 
peavad olema siis tõeliselt väärtuslikud funktsioonid ja need tuuakse siis esikohale ja seejärel 
töödatakse väikeste osade kaupa ka välja. Selline metoodika tugineb kiirele ja usaldusväärsele 
tagasisidele programmeerijate ja klientide vahel, rõhutades just arendustöövoogude kiirust ja 
tõhusust.
Lean seitse peamist printsiibi, mis tuleks selle kasutamisel rakendada: 1. Eemalda  rämps (Eliminate Waste) a. ebavajalik kood ja funktsionaalsus;
b. alustades rohkemaga, millega saaks hakkama, lisab ebavajalikku keerulisust  süsteemile; c. arenduse venimine;
d. hägused ja pidevalt muutuses olevad nõuded;
e. bürokraatia;
f. aeglane ja mitte tõhus suhtlus meeskonna vahel;
g. osaliselt tehtud töö;
h. ülesannete vahetamine töötajate vahel. 2. Kvaliteedile keskendumine a. kahele arendajale sama ülesande andmine, et nad saaksid teineteist abistada ja  toodet muuta kvaliteetsemaks; b. pidev töövoog ja tagasiside;
c. ooteaegade minimaliseerimine;
d. automatiseerimine. 3. Teadlikuse suurendamine a. koos programmeerimine;
b. koodi ülevaatamine;
c. dokumentatsioon;
d. wiki;
e. põhjalikult kommenteeritud kood
f. harjutamine;
g. töövahendite kasutamine, et hoida silma peal vajaminevate ülesannete ellu  viimisel. 4. Liigse pühendumise vähendamine;


a. asju ei tohiks planeerida mitmeid kuid detailselt ette ja tuleks hoida pigem pead  avatuna ideedele ja tagasisidele. 5. Kiire arendus;
6. Inimeste austamine;
7. Optimeerimine. Kanban arendus on visuaalse töövoo juhtimise meetod, mida kasutatakse enamjaolt just Lean 
meeskondade seas. Statistiliselt 83% Leani kasutatavatest meeskondadest kasutab Kanbani, et
visualiseerida ja aktiivselt hallata toodete loomist, mille peamine rõhuasetus on pidev tarnimine.
Kanban kujutab endas seda, et kasutatakse erinevaid vahendeid, et hoida töövool silm peal 
visuaalselt ja, et kõik teaksid, mis ülesanded kellele kuuluvad.
Kanban näited:


2.3 Extreme Programming - XP
Tegu on ühe kõige populaarsema agiilse metoodikaga, mis on distsiplineeritud lähenemine 
kvaliteetse tarkvara kiirele ja pidevalte tarnimisele. Selle eesmärk on parandada tarkvara 
kvaltieeti ja reageerimisvõimet klientide muutuvatele vajadustele. 
Soodustab klientude suurt kaasamist, kiiret tagasisidet, pidevat testimist, planeerimist ja tihedat 
meeskonnatööd. 2.4 Crystal
Käesolev metoodika on üks kõige kerge kaalulisemaid ja kohandatavamaid lähenemisviise 
tarkvara arendamisele, mis koosneb agiilsete meetodite perekonnast, mille hulka kuuluvad ka 
Crystal Clear, Crystal Yellow, Crystal Orange jt. Iga üks omab unikaalseid tunnusjooni, mida 
juhivad mitmed tegurid nagu meeskonna suurus, süsteemi kriitilisus ning projekti prioriteedid. 
Iga projekti puhul võib vaja minna veidi kohandatud poliitikate, tavade ja protsesside kogumit, et
vastata toote ainulaadsetele omadustele.


2.5 Dynamic Systemst Development Method - DSDM
DSDM on ülesse ehitatud kaheksa põhiprintsiibi abil, mis on mõeldud juhtima meeskonda ja 
looma mõtteviisi, mis võimaldaksid ette nähtud aja ja eelarvega tarnida toimiva lahenduse 
klientideni.
Kaheksa printsiibi: 1. keskendu ettevõtte vajadustele;
2. tarni õigel ajal;
3. koostöö;
4. kunagi ei kahjusta kvaliteeti;
5. ehitage järk-järgult;
6. töötage iteratiivselt;
7. suhtle pidevalt ja selgelt;
8. näidake kontrolli. 2.6 Feature Driven Development - FDD
FDD on mudelitel põhinev lühiajaline iteratsiooniprotsess, mis on üles ehitatud tarkvaratehnika 
parimate tavadele, nagun äiteks domeeni objekti modelleerimine, funktsioonide arendamine ja 
koodide omandiline kuuluvus. 2.7 Visuaalne näide


3. DevOps projekteerimine DevOps projekteerimine pole vaid arendusmetoodika, vaid ka praktikate kogum, mis toetab 
organisatsioonide kultuure. Käesolev meetod toetab organisatsioonitasandil kõige enam 
erinevate osakondade omavahelist suhtlust tarkvara arendamisel, keskendub enamuselt 
arendustsüklile, arenduse kvaliteedile, operatsioonidele ja planeerimisele. 3.1 Plussid
Kuna enamuselt keskendutakse sellele, et tagada kvaliteet, õigeajaline tarne, uute väljalasete 
ebaõnnestumise tõenäoususe vähendamine, ajakulu minimaliseerimine vigade parandamisele 
ning töökindluse tagamisele. Proovitakse automatiseerida pidev arendus, et tagada sujuv ja 
töökindel süsteemi toimivus. Statistika on näidanud, et DevOps metoodikat kasutavad 
ettevõtted on suutnud märkimisväärselt vähendada ajakulu vigade parandamisele  samal ajal 
suurendades klientide rahulolu, toote kvaliteeti ja töötajate tõhusust. 3.2 Miinused
Osad kliendid ei ole alati huvitatud pidevatest uuendustest oma süsteemidele. Regulatsioonid 
teatud erialadel, mis nõuavad tõhusat testimist enne kui saab toote tarnida. Kõik osakonnad 
ettevõttes peavad kasutama sama arenduskeskkonda, vastasel juhul võivad esineda vead 
tarkvarasse, mida ei märgata. Osad kvaliteedi tagamise atribuudid vajavad inimese reaalset 
sisestust, see aeglustab tarnet klientideni. 3.3 Visuaalne näide:


4. Waterfall projekteerimine Waterfall projekteerimine on traditsioonile projekteerimine, mis on täpselt sama sisuga, mis 
struktuurprojekteerimine. 4.1 Visuaalne näide


5. Rapid application development Teisisõnu kui RAD on väga tihe arendusprotsess, mis kujutab endas kõrge kvaliteediga toote 
loomist madalate kuludega. See on väga agiilne arendusmeetod, kus saab kiiresti alati muuta 
arenduse suunda ja funktsioone. See hõlmab endas nelja etappi: 1. nõuded;
2. kasutajaliidese disain;
3. arendus;
4. väljastamine. 5.1 Plussid
Väga tõhus just hästi defineeritud äri objektiivile ja kindlale sihtrühmale, kuid ei ole liiga 
keeruline. Eriti tõhus väiksematest kuni keskmise suurustega projektideni, mis on väga kindla 
ajavahemikuga vaja valmis saada. 5.2 Miinused
Vajab stabiilset meeskonda koos väga tugevate arendajate ning kasutajatega, kes on väga 
teadlikud käesolevast erialast. Teadlikkus on vajalik nii tihedas arenduse ajavahemikus mis 
vajab kinnitus peale igat funktsiooni lisamise faasi, ettevõtted, mis nendele tingimustele ei vasta,
ei ole väga tõenäolised saama RAD metoodikat tõhusalt kasutada. 5.3 Visuaalne näide


6. GIT Kasutamine väiksemates tiimides GIT on hea ja lihtne viis meeskondadel hoida end alati kursis oma kaaslaste töö ja 
muudatustega ning annab kõigile hea viisi kõike testida ja arendada ning näha, millega keegi 
teine tegeleb. Väiksemate tiimide jaoks on väga kasulik ja lihtne järgneb branch’ide kasutamise meetod GIT 
süsteemis: 1. Kaks peamist branchi: a. master (mis luuakse kui alustad uue projektiga GIT süsteemis automaatselt);
b. development (mille saab luua käsitsi git branch  käsuga). 2. master branch on vaid stabiilsete versioonide ja testitud funktsioonide jaoks;
3. Development branch’e mis on uute funktsioonide ja veaparanduste jaoks: a. iga töötaja teeb development branch’i  uue branch’i oma arendatava  funktsiooni/veaparanduse nimega. b. kui funktsioon on loodud siis viiakse see development branch’i testimiseks ja  edasi juba master branch’i. 4. Kui funktsioon on väljatootatud ja testitud, siis viiakse see üle master branch’i, uue  väljalaskena.

Document Outline

• 1. Tarkvara arenduse meetodid
  • 1.1 Struktuurprojekteerimine
  • 1.2 Objekt-orienteeritud projekteerimine
  • 2. Agiilne meetod
    • 2.1 Scrum
    • 2.2 Lean ja Kanban
    • 2.3 Extreme Programming - XP
    • 2.4 Crystal
    • 2.5 Dynamic Systemst Development Method - DSDM
    • 2.6 Feature Driven Development - FDD
    • 2.7 Visuaalne näide
  • 3. DevOps projekteerimine
    • 3.1 Plussid
    • 3.2 Miinused
    • 3.3 Visuaalne näide:
  • 4. Waterfall projekteerimine
    • 4.1 Visuaalne näide
  • 5. Rapid application development
    • 5.1 Plussid
    • 5.2 Miinused
    • 5.3 Visuaalne näide
  • 6. GIT Kasutamine väiksemates tiimides