Programinės įrangos kūrimas

Nepaisant sparčios informacinių technologijų plėtros, programinės įrangos kūrimas yra palyginti nauja industrijos šaka, kurios praktikos nėra nusistovėjusios. Tiek kūrėjai, tiek užsakovai ieško sprendimų, kaip optimizuoti programinės įrangos kūrimo procesus, kad minimaliomis lėšomis būtų sukurtas kokybiškas, vartotojo poreikius atitinkantis produktas.

Šiame straipsnyje apžvelgsime programinės įrangos kūrimo procesą iš kūrėjų pozicijos – trumpai perteiksime UAB „Baltijos programinė įranga“ patirtį, sukauptą per 10 darbo metų įvairiuose programinės įrangos projektuose, įskaitant ir visame pasaulyje pripažinto modeliavimo įrankio „MagicDraw UML“ kūrimą.

Programinės įrangos kūrimo procesas

Programinės įrangos kūrimo veiklos dažnai skirstomos į inžinerines ir palaikančias arba valdymo veiklas. Dažniausiai išskiriamos keturios pagrindinės inžinerinės veiklos: reikalavimų analizė, projektavimas, programavimas ir testavimas. Šios veiklos formaliai ar neformaliai atliekamos visuose programinės įrangos projektuose. Visgi programinės įrangos kūrimo sėkmę dažnai didžiąja dalimi lemia ne inžinerinės veiklos, o efektyvus valdymo veiklų vykdymas. UAB „Baltijos programinė įranga“ kaip svarbiausias valdymo veiklas išskiria projektų valdymą ir kokybės valdymą.

1 pav. Programinės įrangos kūrimo proceso veiklos

Reikalavimų analizė

Programinės įrangos kūrimas prasideda nuo reikalavimų analizės ir aprašymo. Daugiausia problemų, kuriant programinę įrangą, kyla būtent iš prastai dokumentuotų, nepilnai aprašytų, skirtingai suprantamų bei projekto eigoje besikeičiančių reikalavimų. Labai svarbu suprasti, kad programinės įrangos projektų reikalavimai turi būti nuosekliai analizuojami keliuose lygiuose – nuo vizijos ir verslo tikslų iki galutinio vartotojo scenarijų bei realizacijos funkcijų aprašymo.

2 pav. Cockburn reikalavimų laivo modelis

Apie reikalavimų analizės kokybę dažnai galima spręsti iš vėliau parengtų vartotojo instrukcijų. Jeigu aprašinėjami vien vartotojo sąsajos langai ir mygtukai, tačiau neaišku, kaip atlikti veiksmų seką, leidžiančią pasiekti vartotojui reikalingą rezultatą, tai yra indikatorius, kad reikalavimų analizė buvo atlikta tiktai realizacijos lygmenyje, neatsižvelgiant į vartojimo scenarijus.

UAB „Baltijos programinė įranga“ savo kuriamuose projektuose taiko panaudos atvejų metodą, kuris leidžia analizuoti reikalavimus galutinio vartotojo lygmenyje.

Pav. 3 Defektų valdymo sistemos panaudojimo atvejai (padidinti)

Reikalavimų kokybė tiesiogiai priklauso nuo užsakovų ir galutinių vartotojų įtraukimo į projektą. Siekiant kuo labiau įtraukti vartotoją į projektą ir išgauti iš jo tikslius reikalavimus, naudojami įvairūs metodai – nuo „brainstorming“ sesijų ir klausymų iki interaktyvių sistemos prototipų kūrimo. Net ir kruopščiai surinkti reikalavimai gali keistis projekto eigoje dėl įvairių priežasčių, todėl užsakomuosiuose projektuose labai svarbu įvesti formalią reikalavimų pakeitimų procedūrą. Chaotiškai keičiant reikalavimus, išauga projekto apimtis, nesilaikoma tvarkaraščių, krenta produkto kokybė.

Projektavimas

Kaip ir pastatus prieš statybas ar automobilius prieš pradedant jų gamybą, taip ir programinės įrangos sistemas reikia suprojektuoti. Tik turint pakankamai detalų projektą galima pereiti į jų gamybos – programavimo – etapą. Programinės įrangos projektavimas galimas daugybe pjūvių. Šiuo metu populiariausias yra 4+1 pjūvių architektūros modelis, išskiriantis konceptualų, realizacijos, procesų ir išdėstymo pjūvius bei juos apjungiantį funkcionalumo (panaudojimo atvejų) pjūvį.

4 pav. 4+1 architektūrinių pjūvių modelis

Kuriais pjūviais analizuoti ir projektuoti labai priklauso nuo projekto specifikos. Nors daugiausiai dėmesio įprasta skirti realizacijos pjūviui, kuris aprašo programinio kodo struktūrą ir veikimą, tačiau to neužtenka. UAB „Baltijos programinė įranga“ vykdytuose projektuose daug dėmesio skiriama ir panaudos atvejų bei konceptualiam pjūviams. Kuriant paskirstytas sistemas, projektuojamas išdėstymo pjūvis, nurodantis, kaip programinės įrangos komponentai bus paskirstyti techninėje įrangoje ir kokiais protokolais bendraus tarpusavyje. Procesų pjūvis svarbus realaus laiko ir paskirstytų procesų sistemose, kur reikia užtikrinti greičio, našumo, pralaidumo charakteristikas. Visi pjūviai projektuojami, naudojant UML modeliavimo kalbą, kuri šiuo metu yra visuotinai pripažinta kaip programinės įrangos sistemų analizės ir projektavimo lingua franca.

5 pav. Konceptuali defektų valdymo sistemos analizė, naudojant UML klasių diagramą (padidinti)

Programinės įrangos projektai daugiau ar mažiau keičiasi pradėjus programuoti, todėl reikia tinkamai pasirinkti, kuriuos projektavimo artefaktus atnaujinti ir išlaikyti projekto eigoje, o kuriuos panaudoti pradinei analizei ir komunikacijai, o vėliau tiesiog išmesti. Per daug detalaus techninio projekto palaikymas gali tapti nereikalinga našta ir įvesti sinchronizacijos chaosą. Detalų projektavimą tikslingiau atlikti programavimo metu, o naudojant atstatomosios inžinerijos įrankius, galima kai kurias modelio diagramas nubraižyti automatizuotai pagal programinį kodą. Dažniausiai modeliuojami, dokumentuojami ir palaikomi šie programinės įrangos sistemų projektavimo aspektai:

• Duomenų struktūros;
• Programinių modulių išskaidymas ir integracija;
• Vartotojo sąsajos elementai ir navigacijos schemos.

Programavimas

Programavimas yra kertinė programinės įrangos kūrimo veikla, kurios metu sukuriamos veikiančios programinės įrangos versijos. Profesionaliam programavimui reikalingas ne tik geras naudojamų programavimo kalbų ir technologijų išmanymas, bet ir analitinis mąstymas, komandinio darbo įgūdžiai, bendro stiliaus susitarimai ir kūrimo įrankių rinkinys.

Bendrovės „Baltijos programinė įranga“ programuotojai naudoja šiuos pagrindinius įrankius:

1. Integruotą programavimo aplinką – efektyviam programavimui, defektų paieškai ir taisymui, kodo struktūros analizei ir perdarymui.
2. Versijų kontrolės sistemą – versijų išsaugojimui, pastoviam kuriamų modulių integravimui.
3. Konstravimo konfigūracijos įrankį – programinės įrangos sistemų konstravimo iš programinio kodo ir kitų modulių, pvz. sistemos konfigūracijos failų arba duomenų bazės, aprašymui.
4. Modulinio testavimo karkasą – programinio kodo modulių testavimo kodo aprašymui ir vykdymui.

Žinoma, patys įrankiai darbų neatlieka – reikia mokėti efektyviai jais naudotis, sukurti procesą, kaip jie naudojami dirbant komandoje, automatizuoti tam tikras veiklas.

Labai svarbu vykdyti programinio kodo peržiūras – jos leidžia pastebėti ir ištaisyti daugumą kodo defektų, pagerinti programinio kodo struktūrą, skaitomumą, pakelti sistemos veikimo greitį. Kartu tai yra įrankis tobulėjimui – programinio kodo peržiūros ir pastebėtų problemų aptarimas pasiteisino kaip geriausias programuotojų kvalifikacijos kėlimo būdas UAB „Baltijos programinė įranga“ praktikoje.

Testavimas

Testavimas apima tiek galutinio programinės įrangos produkto, tiek tarpinių artefaktų tikrinimą, siekiant įvertinti, ar pasiekti rezultatai tenkina lūkesčius. Nemažai programinę įrangą kuriančių kompanijų atlieka tiktai galutinio produkto testavimą, prieš perduodant jį vartotojams. Kartais testavimas netgi perkeliamas ant užsakovo pečių – nustatomas programinės įrangos perėmimo periodas, kurio metu vartotojai turi ją ištestuoti ir pranešti apie defektus. Mes esame įsitikinę, kad tai klaidinga praktika – atliekant testavimą projekto pabaigoje, dažnai randama rimtų defektų reikalavimuose arba architektūriniuose sprendimuose. Tokių defektų taisymas yra labai brangus, todėl paprastai nusprendžiama, kad „šaukštai po pietų“ ir ieškoma, kaip apeiti defektą kitomis priemonėmis, kurios nebūna patogios vartotojui.

UAB „Baltijos programinė įranga“ praktikuoja reikalavimų specifikacijų, projektavimo modelių, programinio kodo tikrinamą atliekant peržiūras. Galutinio produkto testavimas suplanuojamas iš anksto, reikalavimų peržiūrų metu aprašant testavimo atvejus. Tokiu būdu randami įvairūs reikalavimų defektai – informacijos trūkumas, dviprasmiškumai, skirtingų reikalavimų nesuderinamumas.

Svarbu, kad programinę įrangą ar kitus artefaktus (reikalavimų specifikacijas, programinį kodą ir kt.) tikrintų ne jų autorius, o kitas žmogus. Lietuvių patarlė byloja, kad „kito akyje ir krislą pastebėsi, o savoje ir rąsto nematai“. Jeigu programinės įrangos modulį testuoja tas pats programuotojas, daug defektų lieka nepastebėti. Dėl šios priežasties bendrovėje „Baltijos programinė įranga“ įkurta kokybės inžinierių grupė, kuri atsakinga už testavimo planavimą ir vykdymą.

Visų pastebėtų defektų iškart ištaisyti neįmanoma, todėl juos visus reikia užregistruoti. Defektai grupuojami pagal prioritetą, kuris nurodo, kaip dažnai defektas pasitaiko vartotojui, ir žalingumą, kuris nusako defekto poveikį sistemai. Defekto aprašymas turi būti aiškus, kad defektą būtų galima pakartoti ir ištaisyti. Neužtenka tik aprašyti ir pataisyti defektus – reikalingas nuoseklus defektų valdymas. Kiekvienas defektas turi būti išsprendžiamas, tačiau tai nebūtinai turi būti ištaisymas – kai kurie defektai atidedami, kiti yra nepataisomi, dar kiti atmetami, jeigu jie užregistruojami dėl klaidingo testuojančio žmogaus supratimo apie sistemą. Ištaisius defektą, reikia patikrinti, ar jis buvo tinkamai ištaisytas ir ar nesąlygojo naujų defektų atsiradimo. Todėl efektyviam testavimui užtikrinti būtina naudoti defektų registravimo ir valdymo sistemą bei nustatyti defektų užregistravimo, taisymo, patikrinimo ir užbaigimo procedūras.

6 pav. Defekto aprašymo ir būsenos istorijos pavyzdys (padidinti)

Prieš perduodant programinės įrangos produktą vartotojams, reikia užtikrinti, kad pasiektas tinkamas produkto kokybės lygis, pavyzdžiui, turi būti ištaisyti visi aukščiausio prioriteto ir didžiausio žalingumo defektai ir savaitę laiko naujų tokių defektų neberandama.

Projektų valdymas

Programinės įrangos projektų valdymui tinka visi bendri projektų valdymo principai, tačiau didžiulę įtaką daro programinės įrangos kūrimo specifika. Pagrindinės projektų vadovo atsakomybės grupuojamos į tris funkcijas – projekto apibrėžimas, planavimas ir kontrolė.

Apibrėžimo metu turi būti sutarta dėl reikalavimų ir projekto vykdymo taisyklių:

• kaip finansuojamas ir organizuojamas projektas (fiksuota kaina ar valandiniai įkainiai, kiek iteracijų, kokios tarpinės versijos);
• projekto resursų (darbuotojų, techninės ir programinės įrangos);
• komunikacijos schemų (kas ruošia ir tvirtina reikalavimus, kas atsakingas už planų suderinimą, kokia galutinio produkto priėmimo procedūra);
• reikalavimų pakeitimų valdymo procedūros ir kitų formalumų.

Ypatingą dėmesį programinės įrangos projektuose reikia skirti projekto apimties vertinimui, kuris yra viena iš sunkiausių projekto vadovų užduočių. Projekto apimtis vertinama pagal reikalavimus, kurie projekto pradžioje niekada nebūna pakankamai detalūs, be to jie daugiau ar mažiau skirtingai suprantami užsakovų ir kūrėjų, taigi neišvengiamai kinta projekto eigoje. Vertinant apimtį, labai svarbu suskaidyti projektą į smulkesnes užduotis ir sudaryti pradinį projekto planą, kuris vėliau koreguojamas ir detalizuojamas. Vienas svarbiausių kriterijų vertinant apimtį yra patirtis ankstesniuose projektuose. Žinoma, projekto vadovas turi apklausti technines žinias turinčius darbuotojus, kurie gali geriau nustatyti užduočių sudėtingumą. Projekto vadovo atsakomybė yra nuspręsti, kiek tikslūs darbuotojų apskaičiavimai, taip pat numatyti galimas rizikas bei „atakuoti“ jas nuo pat projekto pradžios. Rizikos nurodo, kokios grėsmės gali iškilti projekto eigoje. Pavyzdžiui, užsakovas laiku nepateiks reikalavimų, bus dirbama su naujomis technologijomis, todėl daug laiko gali užtrukti įvairių techninių problemų sprendimams. Rekomenduotina sudaryti rizikų valdymo planą. Dažniausiai į projekto apimtį tiesiog įskaičiuojami papildomi laiko buferiai, tačiau tai yra pats paprasčiausias rizikų valdymo būdas, kuris ne visada tinka.

Tikslią projekto apimtį įmanoma įvertinti tiktai tada, kai projektas užbaigtas. Kadangi projekto apimties vertinimas yra netikslus, didesnius projektus rekomenduotina vykdyti keliomis iteracijomis, kur kiekvienoje sukuriama produkto versija, papildyta nauju funkcionalumu. Nedidelės trukmės iteracijas galima detaliau suplanuoti, lengvesnis ir efektyvesnis projekto kontroliavimas. Progresas įvertinamas kiekvienos iteracijos metu ir pagal tai galima tiksliau planuoti kitas iteracijas. Jeigu vėluojama įgyvendinti tam tikrą funkcionalumą, jį galima atidėti kitai iteracijai, užuot pateikus vartotojui nepilną ar nekokybišką realizaciją.

7 pav. Projekto užduočių išdėstymo lentelė, naudojant „MS Project“ (padidinti)

Kontroliuojant programinės įrangos projekto vykdymą, gana keblu sekti progresą. Programuotojai linkę optimistiškai vertinti situaciją ir dažnai sako, kad „praktiškai pabaigė“ užduotį, tačiau vėliau išaiškėja, kad dėl įvairių nenumatytų smulkmenų tenka dar tiek pat laiko skirti jos užbaigimui. Čia galioja 90/90 taisyklė, kuri teigia, kad „pirmi 90 % užduoties užima 90 % suplanuoto laiko, o likę 10 % užduoties užima dar 90 % laiko“. Todėl rekomenduotina užduotis skaidyti ir vertinti tik dviem būsenom – užbaigta arba neužbaigta – ir tada paskaičiuoti, kiek procentų užduočių yra užbaigta. Pagal progresą projekto vadovas turi sekti, ar nenukrypstama nuo planų, ir imtis koregavimo veiksmų, kai taip atsitinka. Koregavimo veiksmas gali būti atidėjimas vėlesniems etapams arba atsisakymas žemesnio prioriteto funkcionalumo, kad būtų laiku įgyvendintos aukštesnio prioriteto funkcijos, taip pat galimas papildomų darbuotojų paskyrimas užduoties vykdymui. Reikia pabrėžti, kad naujų darbuotojų pridėjimas efektyvus tik ilgai trunkančioms užduotims. Kai vėluojama užbaigti projektą ir pridedama naujų darbuotojų, jis dažniausiai tik dar labiau suvėlinamas.

Projektų užbaigimas yra labai svarbus akcentas – reikia pasimokyti iš savo atradimų ir klaidų. Gera praktika yra rengti projekto užbaigimo susirinkimus, kuriuose projekto dalyviai pasako, kas, jų nuomone, projekto vykdyme buvo gerai ir kas blogai. Svarbiausi akcentai protokoluojami. Negalima užmiršti ir projekto dalyvių. Labai dažnai projekto pabaigoje dirbami viršvalandžiai. Po intensyvaus darbo, užbaigus projektą, rengiami projektų užbaigimo vakarėliai, savaitę ar dvi dirbama prie nesunkių užduočių. Vadovavimas projektams visų pirma yra darbas su žmonėmis, todėl reikia išlaikyti darbingumą ir gerą atmosferą tarp visų projekto dalyvių, ir kartu skatinanti efektyvų bendradarbiavimą ateities projektuose.

Kokybės valdymas

Dažnai sutapatinamos sąvokos kokybės valdymas ir testavimas. Tačiau tai toli gražu nėra tas pats. Kokybės sąvoka apima ir produkto kokybę, kuri nusakoma defektais, ir proceso kokybę, kuri įtakoja kūrimo efektyvumą, ir vartotojo pasitenkinimą. Programinės įrangos kokybė stipriai priklauso nuo to, ar tinkamai vykdomi nustatyti procesai: ar rašoma ir tvirtinama reikalavimų specifikacija, ar prieš programuojant suprojektuojami techniniai sistemos realizacijos modeliai, ar sudaromi testavimo planai, ar visi pastebėti reikalavimų defektai registruojami defektų valdymo sistemoje ir pan. Taip pat labai svarbu formuoti tinkamą visų darbuotojų požiūrį į kokybę. Pozityvus požiūris į kritiką, konstruktyvios diskusijos ir noras tobulėti yra geriausias kokybės kėlimo įrankis. Sakoma, kad „ko negali išmatuoti, negali valdyti“. Todėl viena iš kokybės valdymo veiklų – kiekybinė kokybės metrikų analizė. Pavyzdžiui, prieš išleidžiant produkto versiją yra skaičiuojama naujai užregistruotų ir ištaisytų defektų santykio metrika. Jeigu užregistruota daugiau naujų defektų nei ištaisyta, produkto kokybė yra prasta ir versijos, skirtos galutiniams vartotojams, išleisti dar negalima.

8 pav. Defektų pasiskirstymo kūrimo etapuose pareto histograma

Nors dažnai manoma, kad kokybė daug kainuoja, tačiau kuriant programinę įrangą, turinčią išliekamąją vertę, dėl prastos kokybės reikalingi taisymai ir perdarymai gali kainuoti daug daugiau.

Baigiamasis žodis

Visos programinės įrangos kūrimo veiklos – reikalavimų analizė, projektavimas, programavimas ir testavimas bei projekto ir kokybės valdymas – yra svarbios, siekiant efektyviai kurti kokybišką programinę įrangą. Šiame straipsnyje trumpai pristatėme šių veiklų aspektus, kurie, mūsų nuomone, buvo aktualiausi „Baltijos programinės įrangos“ vykdytuose projektuose. Tikimės, kad šiame straipsnyje pateikta informacija Jums buvo aktuali ir naudinga.