6 tema : Konfigūracijų valdymas

1. 6 tema: Konfigūracijųvaldymas Prof. Robertas Damaševičius, robertas.damasevicius@ktu.lt Prof. Vytautas Štuikys

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

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

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

5. 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”

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

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

8. 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).

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

10. 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 perfrazuotas1-sisLehmano dėsnis

11. 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”

12. KV Lygmenys (baselines) Tai koncepcija, kuri padeda valdyti pakeitimusbe rimto trukdymo pateisinamam keitimui.

13. Kas yra konfigūravimo objektai?

14. Konfigūravimo objektai (1)

15. Konfigūravimo objektai (2)

16. 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?

17. 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)

18. KV procesai pagal SWEBOK PĮ konfigūracijų valdymas

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

20. KV procesų detalizacija PĮ konfigūracijų valdymas

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

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

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

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

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

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

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

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

29. Life-cycle Phase Pr oject T ype Size SCM T ools Life Span Writing Character of Pr oject A Complex system contracted to Highly Medium Adv anced De v elopment Critical Sho rt another company Structur ed Small softwar e B de v elopment Concept Pr ototype Small Basic Inf ormal pr oject Short C SCMP used by or ganization using Support Lar ge Full On-line Structur ed Maintenance contracted SW S oftwar e Life-Cycle D De v elopment of Commer cial Small Integrated Full Inf ormal embedded All Life-Cycle applicatåions SCM Plano pavyzdys(iš IEEE std.1042.1990) ARENA or TRAMP: Concept. Prototype, Small, On-line, Short, Informal

30. 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_828-1998_sw_config_mgmt.pdf PĮ konfigūracijų valdymas

31. 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.”

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

33. 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ų

34. Keitimo proceso valdymas PĮ konfigūracijų valdymas

35. Pokyčių valdymo procesas (algoritmo pseudokodas)

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

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

38. Versija/variantas/išleidimas-pateiktis/ (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

39. 1.1 1.4 Versijų saugojimas • Pilan kiekvienos versijos kopija • Delta (skirtumas tarp dviejų versijų) • Tiesioginė (Forward delta) • Atvirkštinė (Reverse delta) • Mišrūs metodai 1.2 1.3 1.4 1.1 1.2 1.3 PĮ konfigūracijų valdymas

40. Delta kodavimas • Simetrinis Δ(v1, v2) = (v1 \ v2) U (v2 \ v1), • Kryptinis • Elementarių keitimo operacijų seka, nurodanti kaip iš versijos v1gauti kitą versiją v2 PĮ konfigūracijų valdymas

41. Versijų valdymo modeliai(1/3) • Pagr. problema: kelių programuotojų darbas vienu metu

42. Versijų valdymo modeliai(2/3) • Modelis 1: užrakink-keisk-atrakink Problemos: • Pamiršo užrakinti • Negalima dirbti vienu metu

43. Versijų valdymo modeliai(3/3) Modelis 2: kopijuok-keisk-sujunk

44. PĮ konfigūracijų valdymas

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

46. 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ė

47. Versijos

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

49. Pokyčius atspindintis identifikavimas • Integruoja versijas ir pakeitimus, kurie buvo reikalingi šioms versijoms sukurti • Labiau naudojama sistemoms, o ne komponentams

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