Transcript 6 tema
6 tema: Konfigūracijų valdymas Prof. Robertas Damaševičius, [email protected] Prof. Vytautas Štuikys Tikslai • Paaiškinti programinės įrangos konfigūravimo valdymą • Aprašyti esmines konfigūravimo valdymo veiklas (uždavinius, procesus) – planavimas, versijų valdymas, sistemų kūrimas • Aptarti (trumpai) CASE įrankių naudojimą KV procesams palaikyti Kas yra konfigūravimo valdymas? • “SCM is the control of the evolution of complex systems,…, for the purpose to contribute to satisfying quality and delay constraints.” – Jacky Estublier • “SCM provides the capabilities of identification, control, status accounting, audit and review, manufacture, process management, and teamwork.” – Susan Dart Konfigūracijų valdymas: sąvokos ir apibrėžimai • Programų keitimo rezultatų valdymas • Konfigūracija: – Sistema (komponentų rinkinys, atliekantis specifinę funkciją arba aibę funkcijų) [IEEE610] – Sistemos konfigūracija: aparatūros arba/ir programinės įrangos arba jų kombinacijos funkcija arba fizinės charakteristikos, kurios numatytos ir techninėje dokumentacijoje ir pačiame produkte – Sistemos konfigūracija gali būti suvokta kaip specifinės aparatūros, programinės objektų, apjungtų tarpusavyje, specifinės versijos tam, kad būtų galima pasiekti norimą tikslą. Konfigūracijos valdymas: IEEE610 apibrėžtis • “Tai disciplina, taikanti technines ir administracines vadovavimo ir sekimo priemones tam, kad būtų galima nustatyti ir aprašyti konfigūravimo objektų funkcines ir fizines charakteristikas, valdyti tų charakteristikų pakeitimus, registruoti ir pranešti pasikeitimų procesus ir įgyvendinimo statusą (būseną) ir patikrinti atitikimą numatytiems reikalavimams” Kokios išvados išplaukia iš sąvokų apibrėžties? • Konfigūracija susijusi su keitimais – tai keitimų valdymo realizavimas • Jei keitimai aprašo techninius ir netechninius dalykus, tai konfigūracija aprašo keitimų valdymo procedūras ir pasekmes PĮ konfigūracijos valdymas (KV) • Svarbu atskirti PP nuo KV. • PP yra PI veikla, kuri iš esmės prasideda po jos pateikimo vartotojui ir paleidimo. • KV yra aibė sekimo ir valdymo veiksmų, kurie prasideda tada, kai projektas prasideda ir baigiasi, kai sistema yra atstatydinama (nustoja veikusi). • KV susijęs su Kokybės Užtikrinimu (SQA) Programų Inžinerijos (PI) proceso išeiga • PI proceso išeiga arba rezultatas yra informacija, kuri gali būti suskirstyta į tris kategorijas: ( 1) Kompiuterinės programos (išeities arba vykdomo kodo pavidale) ( 2) Dokumentai, kurie aprašo programas (techniniame ir vartotojo lygmenyse) ( 3) Duomenų struktūros, esančios programų viduje ir išorėje (failai, DB). Programų konfigūravimas (PK) • Dalykai (objektai, ištekliai), kurie apima visą informaciją sukurtą PI procese, kaip to proceso dalis, yra vadinama programų konfigūravimo (PK) objektais. • Sistemos specifikacija apsprendžia PI projekto planą ir reikalavimų specifikavimą. Tie, savo ruožtu, kitus dokumentus ir t.t.. • Nelaimei, dar vienas kintamasis atsiranda tame procese - tai keitimai. Keitimai gali atsirasti bet kada ir dėl bet kurios priežasties. Pirmasis Programų Inžinerijos dėsnis • “Nesvarbu kokiame sistemos gyvavimo cikle jūs esate, sistema keisis, ir noras pakeisti ją lydės per visą gyvavimo ciklą” [Bersoff, E.H., V. D. Henderson, and S. G. Siegel, PĮ konfigūracijų valdymas, Prentice-Hall, 1980]. • Tai tik perfrazuotas 1-sis Lehmano dėsnis Problemos akcentavimas • Projektavimas keitimams remiasi srities variantiškumo numatymu (“ the ability to predict needed variabilities in future assets” is a key element in success of reuse and domain engineering” (Frakes 2006) • Programos konfigūracijų valdymas yra “projektavimas keitimams perstumtoje gyvavimo ciklo fazėje – priežiūros fazėje” KV Lygmenys (baselines) Tai koncepcija, kuri padeda valdyti pakeitimus be rimto trukdymo pateisinamam keitimui. Sistemų inžinerija ---------------------------- Sistemos specifikacija Reikalavimų analizė --------------------------------- Reikalavimų specifikacija PĮ projektavimas ---------------------------- Projekto specifikacija Kodavimas ----------------------------- Išeities kodas Išbandymas Bandymų planai/------------------------/ Procedūros/Duomenys Veikianti sistema------------------------------------- Kas yra konfigūravimo objektai? D u om en ų m odelis P rojekto specifikacija D uom en ų projektas A rchitektūros projektas M odulio projektas S ąsajos projektas M od u lis N S ąsajos aprašas A lgoritm o aprašas PDL T estavim o specifikacija T estavim o planas T estavim o proced ū ra T estavim o atvejai Išeities k o d a s Konfigūravimo objektai (1) 1 . S istem o s sp ecifik a cija 2 . P Į p ro jek to p la n a s 3 . a . P Į R eik a la v im ų sp ecifik a cija b . V y k d o m o ji a rb a “ p o p ierin is” p ro to tip a s 4 . P relim in a ri v a rto to jo in stru k cija ( U ser M a n u a l) 5 . P ro jek to sp ecifik a cija a. P ro jek to du o m en ų ap rašy m as b . A rch itek tū rin io p ro jek tav im o ap rašas c. M o d u lių (k o m p o n en tų ) p ro jek tav im o ap rašai d . S ąsajų p ro jek tav im o ap rašai e. O b jek tų ap rašai (esan t o b jek tin ei p ro jek tav im o p arad ig m ai) 6 . P ra d in io k o d o išv a rd ijim a s 7 . A . B a n d y m o (testa v im o ) p la n a s ir p ro ced ū ra b . B a n d y m ų v a ria n ta i ir rezu lta tų reg istra v im a s Konfigūravimo objektai (2) 8. D arb o ir in staliavim o in stru k cijos (O peration and Installation M anuals). 9. V y k d om oji p rogram a a. M od u liai- vy k d om asis k od as b. S u red agu oti m od u liai 10. D u om en ų b a zės ap rašas a. m od eliai (sch em a) , failų stru k tū ra b. p rad in is tu rin y s 11. G alu tin ė in stru k cija vartotoju i 12. P riežiū ros d ok u m en tai a. P Į p rob lem ų p ran ešim ai b. P riežiū ros u žk lau sos c. In žin erin ių p ak eitim ų u žsa k y m ai 13. P I stan d artai ir proced ū ros KV procesas • Reikalauja atsakyti į tokius klausimus: – Kaip organizacija nustato ir valdo programos versijų egzistavimą (ir jos dokumentaciją), kad būtų galima efektyviai atlikti pakeitimus? – Kaip organizacija valdo pakeitimus prieš ir po to, kai PĮ pateikiama vartotojui? – Kas atsako už prioritetus keičiant ir duoda pritarimus? – Kas gali užtikrinti, kad pakeitimai buvo padaryti teisingai? – Koks mechanizmas yra naudojamas informuoti kitus apie pakeitimus, kurie yra daromi? KV uždaviniai • Atsakymai leidžia apibrėžti 5 KV uždavinius: – – – – – Objektų nustatymo (identifikavimo) Versijų valdymo Pakeitimų valdymo Konfigūravimo audito Dokumentavimo (Pranešimų ir ataskaitų formavimo) KV procesai pagal SWEBOK PĮ konfigūracijų valdymas 18 6 KV Procesai pagal SWEBOK • • • • • • KV vadybos procesas PĮ Konfigūracijos nustatymas (identifikavimas) PĮ Konfigūracijos valdymas PĮ Konfigūracijos būsenos apskaita PĮ išleidimo vadyba ir pateikimas PĮ Konfigūracijos auditas KV procesų detalizacija PĮ konfigūracijų valdymas 20 Konfigūracijų valdymas • Naujos programinių sistemų versijos yra sukuriamos keitimo metu – skirtingoms platformoms/OS – siūlo skirtingą funkcionalumą – pritaikytos prie tam tikrų vartotojo reikalavimų • Konfigūracijų valdymas yra susijęs su besivystančių (tobulinamų) programinių sistemų valdymu – siekia kontroliuoti kaštus ir įdėtas pastangas Konfigūracijų valdymas • Apima sukūrimą ir taikymą procedūrų ir standartų, skirtų besivystančio (tobulinamo) programinio produkto valdymui • Yra dalis bendresnio kokybės valdymo proceso Konfigūracijų valdymo standartai • KV visada turi būti pagrįstas organizacijoje taikomais standartais • Standartai turi apibrėžtis, kaip identifikuojamos programos, valdomi pokyčiai ir naujos versijos • Standartai gali remtis išoriniais standartais (pvz: IEEE) • Esantys standartai remiasi krioklio modeliu reikalingi nauji standartai evoliuciniam programų kūrimui Konfigūravimo valdymo planavimas • Visi programinės įrangos kūrimo proceso produktai (objektai) turi būti valdomi – specifikacijos, projektai, programos, testiniai duomenys, vartotojo vadovai • Didelė programinė sistema gali turėti tūkstančius skirtingų dokumentų • Planavimo proceso detalės (žr. duotą schemą) Konfigūracijos valdymo planavimas • Prasideda ankstyvosiose projekto fazėse • Turi apibrėžti valdomus dokumentus arba dokumentų klases • Dokumentai, kurių gali prireikti programų priežiūrai ateityje, turi būti identifikuojami Konfigūracijos valdymo planas (1) • Apibrėžia valdomų dokumentų tipus ir dokumentų įvardijimo (klasifikavimo) schemą • Apibrėžia atsakomybę už KV procedūras • Apibrėžia pokyčių ir versijų valdymo taisykles • Apibrėžia KV įrašus, kurie turės būti prižiūrimi Konfigūracijos valdymo planas (2) • Apibrėžia įrankius naudojamus KV procese ir jų apribojimus • Apibrėžia įrankių naudojimo procesą • Apibrėžia KV duomenų bazė • Gali turėti papildomą informaciją Konfigūravimo objektų identifikavimas • Dideli projektai paprastai pateikia tūkstančius dokumentų, kurie turi būti unikaliai identifikuojami • Kai kuriuos dokumentus reikia prižiūrėti visą programos gyvavimo laiką • Turi būti apibrėžta duomenų įvardijimo schema • Turbūt lanksčiausias metodas yra hierarchinė schema su daugelio lygmenų vardais SCM Plano pavyzdys (iš IEEE std.1042.1990) Life-cycle Phase Project Type Size SCM Tools Life Span Writing A Development Critical Medium Advanced Short Character of Project Highly Structured Complex system contracted to another company Small software development project B Concept Prototype Small Basic Short Informal Maintenance Support Software Large On-line Full Life-Cycle Structured SCMP used by organization using contracted SW Commercial Small Integrated Full Life-Cycle Informal Development of embedded applicatåions C D All ARENA or TRAMP: Concept. Prototype, Small, On-line, Short, Informal Konfigūracijos valdymo planavimo standartas • IEEE Std. 828-1990 • Nauja versija IEEE Std. 828-1998 • Establishes the minimum required contents of a software configuration management plan and defines the specific activities to be addressed and their requirements for any portion of a software product's life cycle. • http://bluehawk.monmouth.edu/~lvallone/ieee_8 28-1998_sw_config_mgmt.pdf PĮ konfigūracijų valdymas 30 Atitiktis IEEE Std. 828-1998 • Pateikties formatas ir pateikiama informacija – Atskiras dokumentas arba jo skyrius, kuris vadinasi “Software Configuration Management Plan”. – 6 skyriai / skirsniai: Introduction, Management, Activities, Schedules, Resources and Plan Maintenance • Atitikties kriterijai – Visos KV plane apibrėžtos veiklos yra priskirtos organizacijos padaliniams arba asmenims kurie turi visus veiklai atlikti reikalingus resursus – Visiems konfigūravimo objektams priskirti keitimo valdymo procesai • Jei tenkina, KV plane gali būti toks sakinys: “This SCMP conforms with the requirements of IEEE Std 828-1998.” Konfigūravimo duomenų bazė • Visa KV informacija turi būti saugoma KV duomenų bazėje (sąsaja su RT ir saugyklos metodu, žr. paskaitą RT ir PPT) • Turi būti saugomi atsakymai į šiuos klausimus – Kur yra tam tikra sistemos versija? – Kokios reikia platformos? – Kokios versijos bus paveiktos pakeitus komponentą X? – Kiek yra surastų klaidų versijoje T? • Pageidaujama, kad KV duomenų bazė turi būti surišta su valdoma programinę įranga Pokyčių valdymas • Programinės sistemos pokyčių valdymas ir realizavimo užtikrinimas • Apima pokyčių užklausų apdorojimą – iš vartotojų – iš kūrėjų – iš rinkos dalyvių Keitimo proceso valdymas PĮ konfigūracijų valdymas 34 Pokyčių valdymo procesas (algoritmo pseudokodas) Pakeitimų istorija • Aprašo pakeitimus taikomus dokumentui arba kodo komponentui • Turi aprašyti pokytį, jo priežastį, autorių ir laiką • Gali būti komentaras programos tekste Versijų valdymas • Pasirinkti sistemos versijų identifikavimo schemą • Suplanuoti naujas sistemos versijas • Užtikrinti tinkamą versijų valdymo procedūrų taikymą • Suplanuoti naujų sistemos versijų išleidimą Versija/variantas/išleidimaspateiktis/ (release) • Versija: sistemos egzempliorius, kurio funkcionalumas skiriasi nuo kitų programos egzempliorių • Variantas: sistemos egzempliorius, kuris yra funkciškai identiškas, tačiau turi ne funkcinių skirtumų nuo kitų egzempliorių • Išleidimas-pateiktis (Release): sistemos egzempliorius platinamas išorėje • Šaka: tam tikra versijų seka Versijų saugojimas Pilan kiekvienos versijos kopija Delta (skirtumas tarp dviejų versijų) Tiesioginė (Forward delta) 1.1 1.3 1.4 Atvirkštinė (Reverse delta) 1.1 1.2 1.2 1.3 1.4 Mišrūs metodai PĮ konfigūracijų valdymas 39 Delta kodavimas • Simetrinis Δ(v1, v2) = (v1 \ v2) U (v2 \ v1), • Kryptinis – Elementarių keitimo operacijų seka, nurodanti kaip iš versijos v1 gauti kitą versiją v2 PĮ konfigūracijų valdymas 40 Versijų valdymo modeliai (1/3) Pagr. problema: kelių programuotojų darbas vienu metu Versijų valdymo modeliai (2/3) Modelis 1: užrakink-keisk-atrakink Problemos: Pamiršo užrakinti Negalima dirbti vienu metu Versijų valdymo modeliai (3/3) Modelis 2: kopijuok-keisk-sujunk PĮ konfigūracijų valdymas 44 Versijų identifikavimas • Versijų identifikavimo procedūros turi vienareikšmiškai identifikuoti komponentų versijas • Trys pagrindiniai metodai – versijų numeravimas – Identifikavimas pagal atributus – pokyčius atspindintis identifikavimas Versijų numeravimas • Paprasčiausia vardijimo schema naudoja linijinę (tiesinę) numeraciją: V1, V1.1, V1.2, V2.1, V2.2 … • Iš tikro schema yra medis arba tinklas • Vardai nėra prasmingi • Hierarchinė schema būtų geresnė Versijos Versijų identifikavimas pagal atributus • Atributai gali būti susiję su versija: – Data, autorius, programavimo kalba, klientas, statusas, … • Lanksti, bet gali būti ne unikali • Reikia paprasto vardo lengvesniam įvardijimui Pokyčius atspindintis identifikavimas • Integruoja versijas ir pakeitimus, kurie buvo reikalingi šioms versijoms sukurti • Labiau naudojama sistemoms, o ne komponentams Išleidimo-pateikties valdymas • Išleidimas turi apimti pokyčius, atliktus taisant vartotojų surastas klaidas • Turi apimti naują sistemos funkcionalumą • Planavimas yra susijęs su sekančios sistemos išleidimo laiku Sistemos išleidimas • Sistemos išleidimas (release) - tai ne tik vykdomosios programos • Gali apimti – – – – – Konfigūracijos failus duomenų failus instaliavimo programas dokumentaciją įpakavimą ir t.t. Išleidimo sukūrimas • Apima visų reikiamų failų ir dokumentacijos surinkimą • Turi būti parašyti konfigūracijų aprašai ir skirtingi instaliavimo scenarijai • Turi būti gerai dokumentuotas, kad galėtų būti sėkmingai pakartotas Sistemos surinkimas • Sistemos kompiliavimo ir surišimo į vykdomąją sistemą procesas • Skirtingos sistemos yra kuriamos iš skirtingų komponentų kombinacijų • Dažnai atliekama automatiškai naudojant scenarijus Problemos • • • • Ar netrūksta sistemos komponentų? Ar specifikuota tinkama komponento versija? Ar turimi visi duomenų failai? Ar visos nuorodos į duomenų dailus yra teisingos? • Ar sistema surenkama reikiamai platformai? • Ar naudojama tinkama kompiliatoriaus versija? Sistemos surinkimas CASE įrankiai konfigūracijų valdymui • KV procesai yra standartizuoti ir naudoja iš anksto žinomas procedūras • Turi būti valdomi dideli duomenų kiekiai • CASE įrankių naudojimas yra esminis Pokyčių valdymo įrankiai • Pokyčių valdymas gali būti integruotas su versijų valdymo sistema • Įrankiai – Pokyčių užklausų formų redaktorius – Perdavimo automatizavimo sistema – Pokyčių duomenų bazė Versijų valdymo įrankiai • Versijų identifikavimas – identifikatorius priskiriamas automatiškai, kai sistemai pateikiama nauja versija • Atminties valdymas – saugomi tik skirtumai tarp versijų • Pokyčių istorija • Nepriklausomas kūrimas – vienu metu gali būti keičiama tik viena versija KV įrankiai Versijų valdymo Klaidų registravimo RCS, CVS, Subversion, Visual Source Safe, Rational ClearCase Bugzilla, Mantis Bugtracker, Rational ClearQuest Projektų valdymo Sourceforge.net, freshmeat.net, GForge, DForge Konfigūracijų valdymo DB PĮ konfigūracijų valdymas 60 Konfigūracijų valdymo DB PĮ konfigūracijų valdymas 61 Duomenų baze pagrįsta sistema Sistemos surinkimas • Įrankiai turi užtikrinti – – – – specifikacijos kalbą ir jos interpretatorių įrankių pasirinkimą paskirstytą kompiliavimą objektų valdymą Dokumentacija • Tikriausiai labiausiai ignoruojamas dalykas sistemų kūrime!!! • 1. Reikalavimai PĮ sistemų dokumentacijai: – Ji turi būti tarpininku grupės nariams bendraujant tarpusavyje – Ji turi būti sistemos informacinė saugykla, naudojama priežiūros inžinierių – Ji turi pateikti informaciją valdymui, kad palengvinus PĮ proceso planavimą, biudžeto ir tvarkaraščių ribojimus – Dalis dokumentacijos turi pasakyti vartotojui, kaip naudoti ir administruoti sistemą. Dokumentų klasifikacija: • 2. Proceso dokumentacija: Šie dokumentai registruoja projektavimo procesą ir priežiūrą Pavyzdžiai: – Planai, Įvertinimai, Grafikai (tvarkaraščiai): Reikalingi vadybininkams numatyti ir valdyti PĮ kūrimo procesus – Ataskaitos: reikalingos nurodyti, kaip resursai buvo naudojami procese Dokumentų klasifikavimas (tąsa): • 3. Dokumentavimo proceso pavyzdžiai: – Standartai: Šie dokumentai nustato, kaip procesas turi būti įdiegtas. Jie gali būti sukurti iš organizacijos, nacionalinių ar tarptautinių standartų ir pateikti procesą detaliai. – Darbiniai dokumentai: Tai dažnai esminiai techninio bendravimo dokumentai. Inžinierių idėjos, mintys apie projektą, tai produktų dokumentacijos laikinos versijos (interim version). Aprašo kūrimo strategijas, formuluoja nustatytas problemas. Tai netiesioginiai pasako apie projekto sprendimus. Dokumentų klasifikavimas (tąsa): • Priminimai ir e-žinutės – Aprašai kasdienio bendravimo tarp vadybininkų ir projektavimo inžinierių. Dokumentų klasifikavimas (tąsa): • 4. Gaminio dokumentacija: Ši dokumentacija aprašo sistemą, kuri yra projektuojama. Lentelėje fiksuojami 5 požiūriai į dokumentaciją: Pavadinimas Kam skirta Tikslas Funkcinis aprašas Sistemos vertintojams Aprašo teikiamas pasaugas Instaliavimo dokumentas Sistemos administratoriams Pasako, kaip instaliuoti sistemą Įvadinis vadovas Vartotojui -naujokui Pasako, nuo ko pradėti Sistemos vadovas (Reference Manual) Patyrusiems vartotojams Detalus sistemos aprašymas Vadovas administratoriui Sistemos administratoriams Palaikymas/Sistemos naudojimas Dokumentų klasifikavimas (tąsa): • Sistemos dokumentai turi turėti: – – – – Reikalavimus dokumentui ir atitinkamą aprašą Dokumentą, aprašantį visos sistemos architektūrą Kiekvienai programai jos architektūrą Kiekvienam komponentui specifikaciją ir projektavimo aprašą Dokumentų klasifikavimas (tąsa): • Sistemos dokumentacija: – Programos pradinio kodo aprašas (listingai). Jie turi turėti komentarus, ypač sudėtingose kodavimo vietose. Jei prasminiai vardai naudojami ir nėra “goto” sakinių, kodas turėtų būti save dokumentuojantis. – Testavimo / validavimo dokumentas, aprašantis kaip testavimo dokumentas atitinka reikalavimus Dokumentų klasifikavimas (tąsa): • Sistemos dokumentacija: – Sistemos priežiūros vadovas, kuris aprašo žinomas sistemos problemas, – aprašo sistemos dalis, kurios yra nuo aparatūros priklausomos, – nuo PĮ priklausomos ir – kaip sistemos projektavimas įvertina sistemos evoliuciją. Dokumentacijos standartai: • Proceso standartas turi: – Apibrėžti procesą, kuris leistų pagaminti aukštos kokybės dokumentą • Procesas turėtų apimti sukūrimą (word processors, text formatters, equation writers, drawing and art packages), • Kalbos glūdinimą (polishing) (spell checkers, thesauri and style checkers) • Ir išleidimo procesą (desktop publishing packages, art packages and type styling programs). Dokumentacijos standartai (tąsa): • Valdyti pačius dokumentus. – Dokumento identifikavimo standartai : kaip mes galime surasti arba cituoti atitinkamą dokumentą? – Dokumento struktūros standartas (trumpam dokumentui): ką jis turi turėti ? Visi dokumentai turi turėti titulinį lapą (cover page), kuris identifikuoja projektą ir tą dokumentą, autorių, išleidimo datą, dokumento tipą, konfigūracijos valdymo informaciją , kokybės užtikrinimo informaciją, konfidencialumo klasę, dokumento paieškos informaciją (raktažodžius ir santrauką) ir teisinės apsaugos žinutę Dokumentacijos standartai (tąsa): – Struktūra dokumentams, kurie daugiau nei keli puslapiai: • Turi būti sudalinti į skyrius, o skyriai į skirsnius • Turi būti pateiktas turinys • Suderinta skyrių ir skirsnių numeracija • Skyriai turi prasidėti atskiru puslapiu: tai palengvina daryti pakeitimus ir spausdinimus dalimis Dokumentacijos standartai (tąsa): Dokumento struktūra su daugybe nuorodų ir detalių Turi turėti indeksus ir nuorodas, kad informacija būtų lengvai išgaunama net ir blogai parašytam dokumentui Jei dokumentai skirti daugeliui skaitytojų, kurių žodynėliai gali skirtis, turi būti pateiktas techninių terminų apibrėžimų, sutrumpinimų žodynėlis Dokumentų pateikimo standartai : • Šriftas, firmos ženklas (emblema) ir formatai – Dokumentų atnaujinimo standartai: Kaip mes galime nurodyti pakeitimus Dokumentacijos standartai (tąsa): • Pasikeitimo standartai: – Užtikrinti elektroninį dokumentų saugojimą ir pasikeitimą Pokyčio užklausos forma • Dalis KV proceso • Aprašo reikalaujamą pokytį, siūlantį asmenį, keitimo priežastį ir skubos pobūdį • Aprašo pokyčio įvertinimą, analizės įtaką, pokyčio kaštus ir rekomendacijas Keitimo užklausos forma Literatūra • Guide to the Software Engineering Body of Knowledge, 2004 Version, SWEBOK Concepts in Configuration Management Systems, Susan Dart, CMU. Software Configuration Management: A Roadmap, Jacky Estublier, CNRS, France. PĮ konfigūracijų valdymas 79