Programmatūras izstrādes process

Programmatūras izstrādes process ir soļu jeb posmu kopums, kas tiek paveikts līdz brīdim, kad programmatūra ir izstrādāta un piegādāta pasūtītājam. Programamtūras izstrāde sastāv no vairākām fāzēm.

 Posmi 
Programmatūras izstrāde sastāv no galvenajiem posmiem:
 Analīze: Šajā sākuma posmā tiek noteiktas un definētas prasības, kas programmai ir jāsasniedz un kāda būs tās funkcionalitāte. Tas ir būtiski, lai precīzi izprastu projekta mērķus un sniegtu visaptverošu skatījumu uz programmas vajadzībām.
 Sagatavošana jeb projektēšana: Nākamajā fāzē tiek plānots, kādā veidā programmatūra tiks izstrādāta un kuri dalībnieki ir atbildīgi par konkrētiem uzdevumiem. Visas prasības jaunajai sistēmai tiek sadalītas divās lielās grupās — tās, kas attiecas uz aparatūru (datori, tīkli, ievadierīces, izvadierīces u. c.), un tās, kuras attiecas uz programmatūru. Šī posma mērķis ir nodrošināt efektīvu un koordinētu darbu, lai sasniegtu izvirzītos mērķus.
 Realizēšana jeb programmēšana (arī implementēšana): Šajā fāzē programmētāji aktīvi uzsāk darbu pie programmatūras izstrādes, bāzējoties uz iepriekšējiem plāniem un prasību analīzes rezultātiem. Šajā posma ietver problēmas risināšanas algoritma detalizēšanu un tā pierakstīšanu attiecīgajā programmēšanas valodā, kā arī datu struktūras izvēli un to kodēšanu saskaņā ar klienta vajadzībām un specifikācijām. Programmēšanas laikā arī pārbauda, vai programma atbilst uzdevuma prasībām. Izveidotajām programmām vai to moduļiem veic atkļūdošanu.
 Testēšana: Pēc programmas izstrādes programmētājiem seko testētāju loma. Šī fāze ietver programmas pārbaudi un testēšanu, lai identificētu un novērstu iespējamās kļūdas un problēmas. Testi tiek veikti, lai nodrošinātu, ka programmatūra darbojas pareizi un atbilst visiem noteiktajiem kritērijiem.
 Dokumentēšana: Pēc programmatūras izstrādes un testēšanas posma notiek dokumentācijas process. Tas ietver programmas dokumentēšanu, lai sniegtu detalizētu aprakstu par tās darbību, funkcijām un izmantošanu biznesa lietotājiem. Labi sagatavota dokumentācija ir būtiska, lai nodrošinātu pareizu programmas izmantošanu un uzturēšanu nākotnē.
 Uzturēšana: Pēdējais posms ir programmas uzturēšanas periods, kurā izstrādātājs turpina sekot līdzi un nodrošina, ka programma darbojas pareizi un atbilst klienta prasībām. Šī fāze ir būtiska, lai novērstu iespējamus problēmas un nodrošinātu ilgtermiņa programmas efektivitāti.

 Process 
Procesa jeb dzīves cikla programmatūras izstrādes laika gaitā ir pārdzīvojis daudzas revolūcijas. Sākot ar tradicionālo ūdenskrituma modeli, kurā programmatūras izstrādes process ir stingri nodalīts un viena fāze seko nākošai un beidzot ar dažādiem prototipēšanas modeļiem, kuros programmatūras process tiek organizēts daudzos posmos ar daudzām programmatūras piegādēm pasūtītājam. Programmatūras dzīves cikla atšķirības nav tikai speciālistu iegriba pēc kāda jauna procesa. Visu šo izstrādes dzīves ciklu rašanās ir bijusi saistīta ar konkrētām problēmām projektu realizācijā. Programmatūras izstrādes process balstās uz kādu no programmatūras dzīves cikla modeļiem.

 Metodoloģijas 
Izstrādes modeļi jeb metodoloģijas ir programmatūras izstrādes process, kas balstās uz kādu no programmatūras dzīves cikla modeļiem. Dažādos modeļos tiek dažādi organizēts programmatūras izstrādes process. Vienā un tajā pašā fāzē gala rezultāts, nodevumi un patērētais laiks var atšķirties. Lai arī kāds būtu programmatūras izstrādes dzīves cikla modelis, tas var sastāvēt no dažādām fāzēm.

Lai ieviestu kvalitātes sistēmu, kā arī veiktu izstrādi atbilstoši standartizētiem procesiem, ir jāiegulda liels darbs (dokumentācija, apmācība, koordinēšana, auditi). Kustība, kura paredz alternatīvu “normatīvai” pieejai, ir spējās programmatūras izstrādes (Agile) metodoloģijas. Tādi kā: ekstrēma programmēšana, Scrum, dinamiska sistēmu izstrādes metodoloģija, spējā modelēšana, spējie dati, Feature Driven Programming, Adaptive Software Development u.c.

 Spējā programmatūras izstrāde 

Spējā programmatūras izstrāde () ir iteratīvs programmatūras izstrādes process, kas raksturīgs ar to, ka katrā iterācijā praktiski tiek izpildīti visi izstrādes soļi sākot no prasību analīzes līdz testēšanai un piegādes pasūtītājam. Parasti vienas iterācijas laiks nav garāks par 2 līdz 4 nedēļām. Uzsvars šādā dzīves cikla modelī ir uz piegādātā produkta derīgumu pasūtītājam. Viena no Agile biežāk lietotajām metodoloģijām ir Scrum.

 Ūdenskrituma izstrāde 
Ūdenskrituma modelis () ir senākais un praksē pazīstamākais programmatūras izstrādes dzīves cikla modelis. Raksturīgas secīgas fāzes, kas panāktu augstu kvalitāti, jo katras fāzes beigās ir iespējams veikt pārbaudi.

 Analīze. Šajā posmā formulē programmatūras sistēmas izstrādes mērķi un nosaka prasības, kurām tai ir jāatbilst, izpildāmās funkcijas, darbības vidi, ātrdarbību, u.c. Iegūtās prasības apraksta formālā dokumentā, ko sauc par prasību specifikāciju. Speciālistu, kas darbojas programmatūras izstrādes posmā, sauc par sistēmanalītiķi.
 Projektēšana. Šajā posmā pamatojoties uz iepriekš iegūtajām prasībām, definē sistēmas uzbūvi un datu glabāšanas struktūras, kā arī izstrādā sistēmas funkcionēšanas algoritmus. Visas nosauktās lietas apraksta dokumentā, ko sauc par projektējumu. Šajā programmatūras izstrādes posmā pamatā darbojas projektētājs.
 Realizēšana. Šajā posmā veic sistēmas realizāciju (kodēšanu) kādā programmēšanas valodā vai vidē. Šo darbu izpilda programmētājs. Tā rezultātā iegūst programmatūras sistēmas kodu.
 Testēšana. Testēšanas rezultātus fiksē testēšanas dokumentācijā, kā arī sagatavo sistēmas lietotāja rokasgrāmatu, kas ir paredzēta sistēmas lietotājiem un viegli uztveramā valodā apraksta sistēmas izmantošanas iespējas. Speciālistu, kas darbojas šajā programmatūras izstrādes posmā, sauc par testētāju.
 Uzturēšana.

 Spirāles izstrāde 
Spirāles modelis () ir līdzīgs kā prototipēšanas modeļa gadījumā, darbs pie šādiem projektiem notiek iteratīvi. Iterāciju laikā tiek precizētas prasības, veikta projektēšana un tikai pēdējās iterācijās tiek veikta projekta testēšana, integrācija.

 Prototipēšanas modelis 
Līdzīgi kā ūdenskrituma modeļa gadījumā, arī prototipēšanas dzīves cikla modeļa gadījumā ir skaidra fāzu secība, taču atšķirībā no ūdenskrituma modeļa, sākotnējās fāzēs netiek veikta detalizēta analīze, vai pilnīga programmas izstrāde, kā rezultātā var tikt neizstrādāti pilnīgi projekta dokumenti, neveikta detalizēta izstrāde un testēšana. Prototipa izstrāde pamatojas uz sistēmas specifikācijas skici. Mērķis — atklāt sistēmas prasības un specifikācijas.

Lietderīgi izmantot, lai pārbaudītu dažādus projektēšanas paņemienus, ilustrētu idejas un funkcionalitāti, noskaidrotu lietotāju vēlmes.

 Soļmodelis 
Soļmodelis jeb pasoļu modelis () paredz pakāpenisku soļsecīgu programmatūras izstrādi. Nodrošina iespēju lietot, pārbaudīt un novērtēt katru sastāvdaļu izveides laikā. Lietderīgi izmantot, kad nav pietiekošu darbinieku sistēmas izstrādei vai, kad ir plānots novērtēt programmatūras tehniskus riskus.

 Rational Unified Process 
Rational Unified Process (RUP) nav konkrēts programmatūras izstrādes dzīves cikla modelis, bet gan vairāk kā ietvars (framework), kurā katrā atsevišķā projektā iespējams definēt tādu dzīves ciklu, kāds tas konkrētajā situācijā ir nepieciešams. RUP integrācija Rational rīkos atbalsta lietotāja veiktās dzīves cikla pielāgošanas un ļauj veikt programmatūras izstrādi atbilstoši definētajam dzīves ciklam.

RUP tiek izdalītas četras fāzes:
 Uzsākšanas fāze (inception phase)
 Analīzes fāze (elaboration phase)
 Izstrādes fāze (construction phase)
 Ieviešanas fāze (transition phase)

 Procesa metamodeļi 
Daži "procesu modeļi" ir abstrakti apraksti, lai novērtētu, salīdzinātu un uzlabotu konkrēto organizācijas pieņemto procesu.

 ISO 12207 
ISO 12207 pieder ISO standartu saimei un ir tapis vairāku standartu evolūcijas rezultātā.
Galvenie procesiOrganizācijas procesiAtbalsta procesi Projekta iegūšana
 Nodrošināšana
 Izstrāde
 Uzturēšana
 Darbināšana Pārvaldība
 Infrastruktūra
 Uzlabošana
 Apmācība Dokumentēsāna
 Konfigurāciju pārvaldība
 Kvalitātes nodrošināšana
 Verifikācija un testēšana
 Validēšana
 Apskates
 Audits
 Problēmu risināšana

 Capability Maturity Model 
Capability Maturity Model (CMM) ir starptautisks standarts, kurš ir pielietojams tieši programmatūras izstrādē. CMM definē piecas brieduma pakāpes, kādās var atrasties uzņēmums, kas izstrādā vai lieto programmatūru un sākumādarbojas spontāni, vēlāk pievēršarvien lielāku uzmanību projektu organizēšanai, procesu izpildei, prasību pārvaldībai, kvalitātei u.tml.

Šo modeli 1986. gadā izveidojis ASV programminženierijas institūts Software Engineering Institute. Sākumā tika ieviesti vairāki standarti, tomēr šobrīd tiek uzturēta Capability Maturity Model Integrated (CMMI) versija.

 Atsauces 

Kategorija:Programmatūras izstrāde