Programinės įrangos kūrimas

Autorius: Darius Šilingas,
No Magic Europe sprendimų skyriaus vadovas
Šis el.pašto adresas yra apsaugotas nuo šiukšlų. Jums reikia įgalinti JavaScript, kad peržiūrėti jį.

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 No Magic Europe, UAB 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. No Magic Europe, UAB kaip svarbiausias valdymo veiklas išskiria projektų valdymą ir kokybės valdymą.

schema2N

Paveikslas Nr. 1 – Programinės įrangos kūrimo proceso veiklos

Reikalavimų analizė

Faktas 25. Nepilni reikalavimai yra sunkiausiai ištaisoma reikalavimų klaida.
–– Robert L. Glass, “Facts and Fallacies of Software Engineering”

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.

Cockburn RV laivas

Paveikslas Nr. 2 – 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.

No Magic Europe, UAB savo kuriamuose projektuose taiko panaudos atvejų metodą, kuris leidžia analizuoti reikalavimus galutinio vartotojo lygmenyje.

Use Case Diagram  Defektu valdymas small

Paveikslas Nr. 3 – Defektų valdymo sistemos panaudojimo atvejai

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

Gero projektavimo paslaptis – žinojimas, kur išlaikyti visumą, ką sujungti, ką išskaidyti ir ką išmesti.
–– Kevlin Henny

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 1 architekturiniai pjuviai

Paveikslas Nr. 4 – 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. No Magic Europe,UAB 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.

Class Diagram  ER diagrama small

Paveikslas Nr. 5 – Konceptuali defektų valdymo sistemos analizė, naudojant UML klasių diagramą

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

Gerą meistrą pažinsi iš jo įrankių.
–– Patarlė

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 No Magic Europe programuotojai naudoja šiuos pagrindinius įrankius:

  • Integruotą programavimo aplinką – efektyviam programavimui, defektų paieškai ir taisymui, kodo struktūros analizei ir perdarymui.
  • Versijų kontrolės sistemą – versijų išsaugojimui, pastoviam kuriamų modulių integravimui;
  • 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;
  • 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 No Magic Europe, UAB praktikoje.

Kuriant MagicDraw UML produktą, programuotojų komandoje nusistovėjo bendras stilius, įrankių rinkinys, darbo procesas.
  • Programuotojai naudoja integruotą programavimo aplinką IntelliJ IDEA, kuri turi labai patogius įrankius programavimo konstrukcijų automatizavimui, defektų paieškai, kodo struktūros keitimo (refactoring) funkcijas. Programinio kodo struktūros keitimo funkcijos leidžia lengvai keisti suprojektuotas programinio kodo paketų ir klasių struktūras, todėl nebūtina detaliai projektuoti prieš pradedant programavimą.
  • Visi programuotojai kiekvienos dienos pabaigoje priregistruoja naujausias savo sukurtų ar keistų programinio kodo failų versijas į bendrą programinio kodo failų versijų saugyklą CVS, o kiekvieną rytą visi pasiima naujausias programinio kodo versijas. Toks požiūris leidžia dirbti, remiantis nuolatinės integracijos principu, ir išvengti galutinės integracijos problemų, kurios labai dažnos, jeigu kuriami atskiri moduliai, kurie tarpusavyje integruojami tiktai projekto pabaigoje.
  • Sistemos konstravimo užduotys aprašytos ANT konstravimo faile, kuris naudojamas visų programuotojų, todėl nekyla nesusipratimų, kaip teisingai sukompiliuoti ar konfigūruoti sistemą.
  • Svarbiausiems duomenų manipuliavimo moduliams yra parašyti JUnit karkasu paremti moduliniai testai, kurių paskirtis ištestuoti programinio kodo modulius ir užtikrinti, kad keičiant kodą nebūtų pažeisti nustatyti modulių kontraktai. Kasnakt automatizuotai paimama naujausia programinio kodo versija, sukonstruojama sistema ir įvykdomas visų modulinių testų rinkinys. Jeigu testai randa klaidų, išsiunčiamos e-pašto žinutės programuotojams, kurie paskutiniai keitė programinį kodą.
  • Reguliariai vykdomos programinio kodo peržiūros ir jų metu pastebėtų problemų aptarimas.

Visos šios praktikos yra neatsiejama Agile programavimo metodų dalis.


Testavimas

Programinės įrangos be defektų nebūna.
–– Gerai žinoma tiesa

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.

No Magic Europe,UAB 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 No Magic Europe į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.

bug small

Paveikslas Nr. 6 – Defekto aprašymo ir būsenos istorijos pavyzdys

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

Viena moteris per devynis mėnesius gali pagimdyti vaiką. Devynios moterys per vieną mėnesį vaiko nepagimdys.
–– Palyginimas apie projektų resursų, trukmės ir apimties planavimą bei kontrolę

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.

Vykdant tarptautinius projektus, viena didžiausių rizikų yra sudėtingas vartotojo įtraukimas bei neefektyvi komunikacija. Tokiu atveju standartinis rizikos valdymo būdas yra deleguoti vieną ar kelis žmones dirbti pas užsakovus. Tokiu būdu jie galės daug paprasčiau dalintis informacija bei kontroliuoti projektą. Analogiškai, užsakovų atstovas gali dirbti pas programinės įrangos kūrėjus, tačiau tai daug retesnis atvejis. Žinoma, darbuotojų delegavimas į užsienį nemažai kainuoja, bet dar daugiau kainuotų neteisingai suprastų reikalavimų realizavimas ir taisymas. Tuo tarpu buferių numatymas leistų tik užtęsti neefektyvų darbą, bet nepadėtų pakelti jo efektyvumo.

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ą.

project plan small

Paveikslas Nr. 7 – Projekto užduočių išdėstymo lentelė, naudojant MS Project

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

Nėra jokios priežasties, dėl kurios jūsų geriausias kolega ir draugas negalėtų būti jūsų aršiausias kritikas.
–– Gerald M. Weinberg

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.

defektai

Paveikslas Nr. 8 – 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 No Magic Europe vykdytuose projektuose. Tikimės, kad šiame straipsnyje pateikta informacija Jums buvo aktuali ir naudinga. Lauksime skaitytojų komentarų elektroniniu paštu Šis el.pašto adresas yra apsaugotas nuo šiukšlų. Jums reikia įgalinti JavaScript, kad peržiūrėti jį.  .