Programmatūras izstrādes

stratēģijas (paradigmas)
2023./2024.M.G.

1
2
Pārbaudes darba tēmas
1. Waterfall
2. V-model
3. Spiral
4. Prototyping
5. Incremental
6. Agile
7. Scrum
8. Kanban

3
 Programmatūras izstrādes modeļi

• Ūdenskrituma modelis
• Evolucionārā izstrāde
• Pētnieciskās programmēšanas modelis
• Prototipēšanas modelis
• Soļmodelis
• Formālā transformācija
• Sistēmas komplektēšana no atkārtotās
lietošanas komponentiem

4
Informācijas avoti par modeļiem
https://skolo.lv/mod/hvp/view.php?id=44260347

https://skolo.lv/mod/hvp/view.php?id=45815769

5
Izstrādes modeļi
Lineārie: Ūdenskrituma, V-modelis

Iteratīvie: Spirāles, Inkrementu(soļmodelis)/ iterāciju (Interactive),

Spējas (Agile), Extreme (XP), Scrum, Prototyping, DevOps, Rapid
Application Development (RAD), Rational Unified Process (RUP), B-
model, …

*izceltas Kvalifikācijas eksāmena teorijas jautājuma tēmas

6
Ūdenskrituma (Kaskādes) Apraksts

Waterfall model
Atbilst programmatūras
dzīves ciklam.
Katrs izstrādes posms seko
iepriekšējam.
Lai pārietu uz jaunu posmu
ir pilnībā jāpabeidz tekošo.

7
 Ūdenskrituma modelis
• Sistēmas prasības
• Programmatūras prasības
Prasību analīze • Prasību specifikācija *
un definīcijas
• Sistēmas specifikācija
Sistēmas • Projektējuma apraksts *
• Testēšanas plāns
projektēšana • Algoritmu kopa
• Programmu pirmkodi
Implementēšana un • Testēšanas pārskats
programmvienību testēšana

Integrācija un • Lietotāja ceļvedis *

sistēmas testēšana

Uzturēšana
8
 Laika patēriņa sadale
izstrādes procesā

Programmvienību Prasību analīze 10%

testēšana 25% Specifikāciju
definēšana 10%

Projektēšana
Integrācija un 15%
sistēmas testēšana Kodēšana 20%
20%

9
Ūdenskrituma Plusi
Ūdenskrituma modelis ir viegli saprotams, dod atbalsta
struktūru nepieredzējušai komandai
Katra posmā ir pilna dokumentēšana
Vienmēr var skaidri plānot izmaksas un termiņus

10
Ūdenskrituma Mīnusi
Vēl pirms projekta sākuma nepieciešams noteikt un apstiprināt
pilnu prasību klāstu
Ja mainās vai papildinās prasības būs nepieciešams
atgriezties pie pašā pirmā posma

11
Ūdenskrituma Var izmantot pie gadījumiem
Valsts iestādes projekti, lielas iestādes, bankas
Strādā labi, kad kvalitāte ir svarīgāka par izmaksām un laiku
Ja prasības ir labi zināmas
Tiek veidota jauna versija eksistējošam produktam
Eksistējoša produkta pārnešana uz citu platformu

12
V-model (V-modelis)

Ūdenskrituma modeļa
variants, kur liek uzsvaru uz
produkta verifikāciju un
validāciju
Testēšana tiek veikta
paralēli katrā izstrādes fāzē
Plusi un Mīnusi atbilstoši
Ūdenskrituma modelim

13
 V-model Plusi
• Konstantā paralēlā testēšana ļauj pārliecināties ka viss tiks veikts pēc
dokumentācijas un prasībām
• Modelis nav sarežģīts un ir viegli saprotams
• Rezultātā veidojas efektīva un pilna dokumentācija
• Var viegli plānot izstrādes gaitu
• Mudina kļūdu novēršanu, nevis labošanu
• Mazina riskus
• Uzlabota izsekojamība: V-Modelis nodrošina skaidru saikni starp prasībām un
galaproduktu, atvieglojot programmatūras izmaiņu izsekošanu un pārvaldību.
• Tas ļauj projektu vadībai precīzi izsekot progresam.
• Vienkāršs un viegli saprotams un lietojams.

14
V-model Mīnusi
• Nav efektīvs gadījumos kad nav skaidras visas prasības
• Nav elastīgs (izņemot vācu versijas)
• Pārāk vienkāršots process var radīt problēmas, nav reālistisks
• Neprecīzs un dažkārt neskaidrs modelis, var rasties grūtības
• Lēns
• Augsts risks un nenoteiktība.
• Laikietilpīgs: V-modelis var būt laikietilpīgs, jo tas prasa daudz dokumentācijas un
testēšanas.
• Pārmērīga paļaušanās uz dokumentāciju: V-modelis liek lielu uzsvaru uz
dokumentāciju, kas var novest pie pārmērīgas paļaušanās uz dokumentāciju uz
faktiskā izstrādes darba rēķina.

15
V-model Var izmantot pie gadījumiem
V modelis ir jāizmanto maziem un vidējiem projektiem, kur
prasības ir skaidri noteiktas un fiksētas.
V modelis ir jāizvēlas, kad ir pieejami pietiekami tehniskie
resursi un nepieciešamās tehniskās zināšanas.

16
Spiral model

Tika izstrādāts, izmantojot

ūdenskrituma paradigmu kā
pamatu.

Šī pieeja ir sadalīta vairākos

ciklos:

17
Spirāles modelis
1.Plānošanas (Planning): Identificē projektu mērķus, nosaka resursus un
izveido plānu nākamajām iterācijām.
2.Riska analīze (Risk Analysis): Identificē un novērtē iespējamos riskus un
neapstiprinātības faktorus, kas var ietekmēt projektu.
3.Inženiertehniskais posms (Engineering): Īsteno projektu, izstrādājot,
testējot un integrejot jaunus elementus vai funkcionalitāti.
4.Evaluācija un plāna pārskatīšana (Evaluation and Planning): Pārskata
rezultātus, novērtē, vai izpildītie darbi atbilst plānam un vai ir nepieciešamas
izmaiņas. Šis posms veicina turpmāku plānošanu un nākamo iterāciju
izstrādi.

18
Spiral model Plusi
Uzlabota kvalitāte - ļauj veikt vairākas programmatūras izstrādes procesa iterācijas, kā
rezultātā var uzlabot programmatūras kvalitāti un uzticamību.
Riska pārvaldība - labākais attīstības modelis gadījumos, kad projektiem ir daudz
nezināmu risku, jo tiek veikta riska analīze un risināšana katrā fāzē.
Aktīva komunikācija - nodrošina regulāru progresa pārskatu, kas uzlabo saziņu starp
klientu un izstrādes komandu.
Piemērotība - piemērots apjomīgiem projektiem ar vidēju vai augstu risku
Elastība prasībās - Arī vēlākajā posmā var iekļaut prasību izmaiņas un veiksmīgi tās
izpildīt.
Iteratīvā un pakāpeniskā pieeja - nodrošina iteratīvu un pakāpenisku pieeju
programmatūras izstrādei, nodrošinot elastību un pielāgojamību, reaģējot uz mainīgām
prasībām vai negaidītiem notikumiem.

19
Spiral model Mīnusi
Pārāk liela uzticamība riska analīzei;
Sarežģīts - šis modelis ir daudz sarežģītāks nekā citi SDLC modeļi.
Izmaksas - šis modelis nav piemērots maziem projektiem, jo ​tas ir
dārgs.
Laikietilpīgs - spirālveida modelis var būt laikietilpīgs, jo tam ir
nepieciešami vairāki novērtējumi un bieža pārskatīšana.
Resursu ietilpīgs - spirālveida modelis var būt resursietilpīgs, jo tas
prasa ievērojamus ieguldījumus plānošanā, riska analīzē un
novērtēšanā.

20
Spiral model Var izmantot pie gadījumiem
Spirālveida modelis bieži tiek izmantots sarežģītiem un lieliem
programmatūras izstrādes projektiem, jo ​tas ļauj nodrošināt elastīgāku un
pielāgojamāku pieeju programmatūras izstrādei.
Tas ir arī labi piemērots projektiem ar augstu riska līmeni.
Ja projekts ir plašs programmatūras inženierijā;
Ja nepieciešama bieža versiju izlaišana;
Kad ir lietderīgi izveidot prototipu;
Ja projektiem ir vidējs vai augsts risks;
Ja prasības ir sarežģītas un neskaidras;
Ja jebkurā brīdī ir iespējamas izmaiņas;

21
 Programmatūras izstrādes modeļi

• Ūdenskrituma modelis
• Evolucionārā izstrāde
• Pētnieciskās programmēšanas modelis
• Prototipēšanas modelis
• Soļmodelis
• Formālā transformācija
• Sistēmas komplektēšana no atkārtotās
lietošanas komponentiem

22
 Pētnieciskās programmēšanas modelis
(Exploratory / Iteraktīvais)

Specifikācijas
skices
izstrāde Sistēmas Sistēmas izmantošana
implementēšana

Nē Sistēma
atbilst?

Jā
Sistēmas nodošana

23
 Pētnieciskās programmēšanas modelis
Sākumā ir jāizstrādā sistēmas sākumversija, kas jāpiedavā
ekspluatācijai un tad jāuzlabo sistēma, lai īstenotu lietotāju
velmes.
Tas var notikt vairākas reizes, kamēr visas prasības būs
ievērotas.
Sistēmas iznāk slikti strukturētas

24
Prototyping model
Prototipēšana ir produkta vai projektējamās sistēmas darba
kopijas izstrādes process. Tas piedāvā nelielu galaprodukta
kopiju un tiek izmantots klientu atsauksmju saņemšanai.
Prototips ir kā eksperimentāla versija, kas ļauj izstrādātājiem
vai projektētājiem redzēt, kā darbojas vai izskatās produktu
potenciālā gala versija, pirms tā tiek pilnībā izstrādāta vai
ražota.

25
Prototipēšanas modelis (Prototyping)

Izstrādāt
specifikācijas
uzmetumu Izstrādāt Novērtēt
prototipu prototipu

to tipa ti
pro onen
kom
p Specificēt
sistēmu
Projektēt,
implementēt un
Apstiprināt
testēt sistēmu
sistēmu

26
Prototipēšanas modelis
Lieto, kad pasūtītās nespēj formulēt prasības
1. Formulē prototipēšanas mērķi
2. Izlēmj, kādas funkcijas iekļauj prototipā vai nefunkcionālās
prasības
3. Izstrādā/īsteno prototipu (var ignorēt to, kas nav mērķis,
piem. kļūdu apstrādi)
4. Novērtē prototipu
Palielina izmaksas!

27
Prototipu veidi:
Funkcionālie prototipi: Šie prototipi tiek izveidoti, lai
demonstrētu produkta darbību un funkcionalitāti.
Vizuālie prototipi: Šādi prototipi fokusējas uz izskata un dizaina
aspektiem, lai vizuāli parādītu, kā galīgais produkts izskatīsies.
Interaktīvie prototipi: Šādi prototipi ļauj lietotājiem mijiedarboties
ar produktu vai sistēmu tā, it kā tas būtu galīgais produkts.
Strukturālie prototipi: Šādi prototipi koncentrējas uz produktu vai
sistēmu struktūru un organizāciju, neievērojot dizaina detaļas vai
funkcionalitāti.

28
Prototipēšanas modeļa Plusi
Šim modelim ir elastīga konstrukcija;
Ir viegli pamanīt kļūdas;
Var viegli atrast trūkstošo funkcionalitāti;
Pastāv iespēja piestrādāt, kas nozīmē, ka jaunās prasības var viegli īstenot;
Nākotnē izstrādātājs to varētu atkārtoti izmantot sarežģītākiem projektiem;
Tas nodrošina augstāku klientu apmierinātības un komforta līmeni;
Ideāli piemērots tiešsaistes sistēmai;
Tas palīdz izstrādātājiem un lietotājiem labāk izprast sistēmu;
Tas var aktīvi piesaistīt lietotājus izstrādes posmā.

29
Prototipēšanas modeļa Mīnusi
Šis modelis ir dārgs;
Var būt slikta dokumentācija, jo klientu prasības vienmēr mainās;
Prasības atšķiras;
Dažreiz klienti pieprasa, lai faktiskais produkts tiktu piegādāts drīz pēc
tam, kad viņi ir redzējuši sākotnējo prototipu;
Klienti var nebūt apmierināti vai ieinteresēti produktā pēc sākotnējā
prototipa apskates;
Problēmas analīze var būt nepilnīga;
Sistēmas sarežģītība var palielināties

30
Prototipēšanas modeļa Var izmantot pie gadījumiem

Prototipēšanas modelis jāizmanto, kad prasības produktam ir

neskaidras vai nestabilas.
Arī prototipēšanas modeli var izmantot, ja prasības ātri mainās.
Šo modeli var veiksmīgi izmantot, lai izstrādātu lietotāja
interfeisus, augsto tehnoloģiju programmietilpīgas sistēmas, kā
arī sistēmas ar sarežģītiem algoritmiem un saskarnēm.
Prototipēšanas modelis var izmantot, lai demonstrētu produkta
tehnisko īstenojamību

31
Soļmodelis (Incremental)
Prasību Sistēmas arhitektūras
definēšana projektēšana

Sistēmas Sistēmas Sistēmas

sastāvdaļas sastāvdaļas sastāvdaļas
specificēšana izveidošana testēšana
Nē
Sistēma pilnīgi Sistēmas Sistēmas
pabeigta? testēšana integrācija
Jā
Sistēmas nodošana

32
Soļmodelis
Paredz pakāpenisko soļsecīgu (pa inkrementiem) sistēmas
izstrādi un nodošanu klientam
1. Definēt prasības sistēmai
2. Projektēt sistēmas struktūru un sadalīt to daļās (inkremetos),
kuras var veidot un nodot pa soļiem
3. Specificēt, izstrādāt, pārbaudīt, nodot tos klientam,
integrējot tos ar iepriekšējām

33
Incremental (Soļmodelis)

Inkrementu modelis prioritizē

sistēmas prasības un tad
ievieš tās pa grupām
Veido daļēju implementāciju
no visas sistēmas, tad lēnām
liek klāt funkcionalitāti līdz
visa funkcionalitāte ir ieviesta

34
Inkrementu Plusi
Augsta riska vai svarīgākās funkcijas ievieš pirmās
Katrs izlaidums dod strādājošo produktu
Klients var dot recenziju par katru jauno versiju
Sākotnējais produkts ir izveidots ātrāk
Klienti iegūst svarīgu funkciju ātrāk
Prasību izmaiņu risks ir mazāks

35
Inkrementu Mīnusi
Vajag labu plānojumu un dizainu
Agri vajag definīciju pilnībā funkcionējošai sistēmai, lai veiktu
inkrementāciju
Labi definētu moduļu saskarne ir nepieciešama
Kopējās izmaksas sistēmai nav zemākas

36
Inkrementu Var izmantot pie gadījumiem
Nepieciešama kaut kāda funkcionalitāte tirgū pēc iespējas ātrāk
Kad nepieciešama faktiskās izmantošanas aprobācija un risku
analīze
Visas prasības ir zināmas, bet gaidāms ka tās mainīsies
Projektos ar gariem izstrādes grafikiem
Projektos ar jaunām tehnoloģijām

37
Agile (Spējas modelis)

Veido sistēmu pa daļām, pēc

daļas izveidošanas to
parāda klientam
novērtēšanai un
atgriezeniskās saites
gūšanai. Nākamās daļas
veidošanā ņem vērā klienta
atsauksmes un koriģē
programmatūras izstrādi

38
Agile un Scrum tēmas vislābāk apgūt pēc agilescrum.lv vietnes
materiāliem

39
Agile manifests - 4
(2001.)
Agile manifests vēsta – savā darbā novērtējam:
Cilvēkus un viņu mijiedarbi augstāk par rīkiem un procesiem
Strādājošu programmatūru augstāk par detalizētu
dokumentāciju
Kopsadarbību ar pasūtītāju augstāk par līguma sarunām
Reaģēšanu uz izmaiņām augstāk par sekošanu plānam

40
Agile principi - 12
1. Mūsu augstākā prioritāte ir apmierināt klienta vajadzības,
pēc iespējas drīz un nepārtraukti piegādājot vērtību
pievienojošu programmatūru.
2. ………………..

11. ………………
12. Komanda regulāri analizē savu sniegumu, lai kāpinātu sava
darba efektivitāti, un atbilstoši maina un pielāgo savu uzvedību.

41
Minimal viable product
(Minimālais Dzīvotspējīgais Produkts)

A B

42
Agile Apraksts
Nepārtraukta programmatūras piegāde
Nepārtraukta sadarbība ar klientu
Nepārtraukti atjauninājumi pēc izmaiņām

43
SCRUM PĪLĀRI - 3
Caurskatāmība (Transparency)
Visiem tekošajiem darbiem un procesiem ir
jābūt caurskatāmiem.
Pārbaude (Inspection)
Pārbaudes tiek veiktas regulāri, lai
nodrošinātu mērķa sasniegšanu un gadījumā,
ja tiek pamanītas kādas novirzes no plānotā
mērķa, tiek veikta pielāgošana.
Pielāgošana (Adaptation)
Pielāgots var tikt gan process, gan produkts.
Tas tiek darīts tiklīdz tiek uzzināta jauna
informācija, kas var ietekmēt virzību uz mērķi.

44
Agile un Scrum tēmas vislābāk apgūt pēc agilescrum.lv vietnes
materiāliem

45
Scrum Team - 3

1 1 ~10

46
Scrum Team
Scrum Master - Scrum meistars (kapteinis) ir patiess
kalpojošais līderis, kas ir atbildīgs par Scrum komandas
efektivitāti. Māca darboties Scrum ietvara robežās
Product Owner - Produkta īpašnieks - atbildīgs par maksimālu
produkta vērtības radīšanu (pārstāv produkta kvalitāti)
Developers - Izstrādātāji - jebkurš, kas apņemas izveidot
jebkura veida lietojamu inkrementu katrā Sprintā (analītiķis,
programmētājs, testētājs, …)

47
Kanban – metodoloģija darba procesu plūsmas
vizualizācijai

48
Kanban metodoloģija
Kanban ir populārs organizēšanas palīglīdzeklis, ko izmanto, lai
uzlabotu produktivitāti, efektivitāti un ienesīgumu.
Kanban izmanto paneļus, lai organizētu individuālus uzdevumus
kolonnās, palīdzot sadalīt uzdevumus mazākās,
vieglāk sagremojamās daļās.
Kanban (japāņu: 看板 , kas nozīmē stends vai “billboard”) ir
vienkārša metode, lai pārvaldītu un uzlabotu darbu dažādās
cilvēku sistēmās. 1950 gados Kanban kā vadības metode tika
izveidota Toyota ražošanas rindu optimizācijai.

49
Kanban diagramma ar aprakstu
1. Vizualizējiet darbplūsmu: izmantojiet Kanban dēli,
lai skatītu darba posmus.
2. Ierobežot WIP: iestatiet maksimālos uzdevumus
katrā posmā, lai izvairītos no pārslodzes.
3. Pārvaldiet plūsmu: pārraugiet darba kustību un
identificējiet vājās vietas.
4. Norādiet standartus skaidri: dokumentējiet
noteikumus, piemēram, darba prioritātes.
5. Izmantojiet atgriezeniskās saites cilpas: regulāri
pārskatiet un uzlabojiet savu Kanban sistēmu.
6. Nepārtraukti uzlabojiet: pielāgojiet savu Kanban
sistēmu mainīgajām vajadzībām.

WIP - Work In Progress

50
Kanban Plusi
Viegli saprast uzdotos uzdevumus
Viegli saprast komandas padarīto/progresu.
Uzlabota komandas efektivitāte.
Mazāks izdegšanas risks.
Paaugstināta redzamība
Uzlabota koncentrēšanās un efektivitāte
Uzlabota sadarbība un komunikācija
Paaugstināta pielāgošanās spēja un elastība
Nepārtraukta uzlabošana

51
Kanban Mīnusi
Grūti noteikt kad projekts būs pabeigts.
Projekta sarežģītības ierobežojumi.
Nepieciešama disciplinēta komanda, lai metode efektīvi darbotos.
Sākotnējā mācīšanās līkne
Izturība pret pārmaiņām
Ļaunprātīgas izmantošanas iespēja
Ierobežota darbības joma
Nepieciešama pastāvīga apņemšanās

52
Kanban Var izmantot pie gadījumiem
To izmanto elastīgos projektos, kur ir daudz ienākošo pieprasījumu, kas
atšķiras pēc prioritātes un lieluma.
Kanban spīd scenārijos, kuros nepieciešama nepārtraukta darbplūsma
un piegāde, piemēram, programmatūras izstrāde un mārketings.
Ierobežojot nepabeigto darbu un koncentrējoties uz vizuālo darbplūsmas
pārvaldību, tas nodrošina vienmērīgu plūsmu un pielāgojamību tādos
uzdevumos kā ražošana, klientu apkalpošana un produktu izstrāde.
Elastība ļauj integrēties ar citām metodoloģijām un personīgās
produktivitātes lietojumprogrammām. Tomēr Kanban var nebūt vislabāk
piemērots projektiem ar stingrām prasībām vai sarežģītām atkarībām.

53
 Projektu vadības rīki

Projektu vadības rīki Koda repozitoriji Mākoņglabātuve

Avoti
1. Waterfall
How to Use nTask for Waterfall Project Management - A Practical Guide for First Timers -
nTask (ntaskmanager.com)
2. Vairāku izstrādes modeļu apraksti
Waterfall Model (Software Engineering) – javatpoint
3. Agile kultūra, Agile domāšanas veids, Agile manifests un vērtības, Iteratīvā pieeja
projektu izstrādē. Scrum ietvars, Scrum komanda un lomas, Scrum pilāri un vērtības,
Pabeigta darba definīcija
http://agilescrum.lv/
4. Agile Scrum pamācība
https://www.edureka.co/blog/agile-scrum-tutorial/

55