zswi/pDscm.d
21. kveˇtna 2004
141
KIV/ZSWI 2003/2004 Pr ˇedna ´s ˇka 13 Testova ´nı ´ syste ´mu ----------------* ´ uc ˇelem otestovat cely ´ syste ´m, jehoz ˇ je SW souc ˇa ´stı ´ * mı ´vajı ´ ru ˚zny ´ ´ uc ˇel, napr ˇ. otestovat vlastnosti jako je vy ´konnost, kompatibilita, bezpec ˇnost, instalovatelnost, spolehlivost apod. Testova ´nı ´ vy ´konnosti .................... * v mnoha typech syste ´mu ˚ je nepr ˇı ´pustne ´, aby SW nespln ˇoval poz ˇadavky na vy ´konnost (zejme ´na v r ˇı ´dı ´cı ´ch syste ´mech) * v takove ´m pr ˇı ´pade ˇ by se vy ´konnost me ˇla testovat ve vs ˇech krocı ´ch vc ˇetne ˇ jednotkovy ´ch testu ˚ * pomocne ´ procedury monitorujı ´ dobu vykona ´nı ´ apod. Za ´te ˇz ˇove ´ testova ´nı ´ .................. * obvykle se pouz ˇı ´vajı ´ testy, kde se za ´te ˇz ˇ postupne ˇ zvys ˇuje, dokud nenı ´ vy ´konnost syste ´mu neakceptovatelna ´ nebo dokud syste ´m nehavaruje - za ´te ˇz ˇ = mnoz ˇstvı ´ dat, frekvence poz ˇadavku ˚, data ktera ´ jsou extre ´mne ˇ na ´roc ˇna ´ na zpracova ´nı ´ - je vhodne ´ urc ˇit c ˇa ´sti ko ´du, ktere ´ mohou by ´t problematicke ´ pr ˇi velke ´ za ´te ˇz ˇi, za ´te ˇz ˇove ´ testy navrhnout tak aby pokry ´valy pr ˇedevs ˇı ´m tyto c ˇa ´sti ko ´du - ove ˇr ˇenı ´ zda hava ´rie syste ´mu nepos ˇkodı ´ data apod. - mu ˚z ˇe odhalit ne ˇktere ´ defekty, ktere ´ se norma ´lne ˇ neprojevı ´ - du ˚lez ˇite ´ zejme ´na u internetovy ´ch aplikacı ´, v distribuovany ´ch syste ´mech apod., kde se vysoce zatı ´z ˇene ´ syste ´my mohou zahltit, protoz ˇe si vyme ˇn ˇujı ´ c ˇı ´m da ´l vı ´ce koordinac ˇnı ´ch dat, c ˇı ´mz ˇ se ope ˇt zvys ˇuje za ´te ˇz ˇ syste ´mu atd. Testova ´nı ´ zotavenı ´ syste ´mu po hava ´rii ..................................... * mnoho syste ´mu ˚ se musı ´ by ´t schopno zotavit po hava ´rii v pr ˇedepsane ´m c ˇase, jinak hrozı ´ znac ˇne ´ financ ˇnı ´ ztra ´ty - pr ˇi testova ´nı ´ zotavenı ´ syste ´mu zpu ˚sobujeme ru ˚zne ´ hava ´rie syste ´mu a ove ˇr ˇujeme, zda se syste ´m zotavil spra ´vne ˇ a v c ˇasove ´m limitu Na ´stroje pro testova ´nı ´ SW ------------------------* v rozsa ´hly ´ch syste ´mech mu ˚z ˇe cena testova ´nı ´ dosa ´hnout 50% ceny vy ´voje, mohou existovat stovky az ˇ tisı ´ce testovacı ´ch pr ˇı ´padu ˚ - proto potr ˇeba automatizace testu ˚ - automatizace testu ˚ take ´ sniz ˇuje cenu zme ˇn - programa ´tor ˇi se nemusejı ´ tolik oba ´vat, z ˇe zme ˇnou zanesou do ko ´du defekt, protoz ˇe testy by defekt (s urc ˇitou pravde ˇpodobnostı ´) odhalily - obvykle ´ je na ´sledujı ´cı ´ uspor ˇa ´da ´nı ´:
generátor testovacích dat správce testů testovaný program
specifikace
testovací data
orákulum
skutečné výsledky
predikce výsledků porovnání souborů
generátor sestav
zpráva o výsledcích testů
21. kveˇtna 2004
142
zswi/pDscm.d
* jednotlive ´ programy majı ´ na ´sledujı ´cı ´ fce: - spra ´vce testu ˚ (test manager) - r ˇı ´dı ´ be ˇh testu ˚ - genera ´tor testovacı ´ch dat (test data generator) - generuje testovacı ´ vstupnı ´ data pro testovany ´ SW - ora ´kulum (oracle) - generuje pr ˇedpokla ´dane ´ vy ´stupnı ´ hodnoty . ora ´kulum lze vyvinout jako novy ´ program (obsahujı ´cı ´ podmnoz ˇinu funkc ˇnosti, co nejme ´ne ˇ pracna ´ implementace) . c ˇasto lze vyuz ˇı ´t prototyp SW, pr ˇedchozı ´ verze SW, SW vytvor ˇeny ´ konkurencı ´ apod. . pokud se jako ora ´kulum pouz ˇı ´va ´ pr ˇedchozı ´ verze SW, pouz ˇı ´va ´ se na ´zev regresivnı ´ testova ´nı ´ (regression tests = porovna ´va ´me vy ´sledky stare ´ a nove ´ verze, rozdı ´ly znamenajı ´ potencia ´lnı ´ proble ´m v nove ´ verzi) - program pro porovna ´nı ´ souboru ˚ (file comparator) - porovna ´ vy ´sledky skutec ˇne ´ho be ˇhu s pr ˇedpokla ´dany ´mi hodnotami vygenerovany ´mi ora ´kulem; c ˇasto lze pouz ˇı ´t univerza ´lnı ´ programy jako cmp(1) a diff(1) v UNIXu apod. - genera ´tor zpra ´v (report generator) - umoz ˇn ˇuje definovat a generovat zpra ´vy o vy ´sledcı ´ch testu ˚ Pozna ´mka (regresivnı ´ vs. progresivnı ´ testova ´nı ´) Proces testova ´nı ´ ma ´ testova ´nı ´ pr ˇida ´va ´ a a jejich rozhranı ´ s du ˚sledky zme ˇn v jiz ˇ
svou progresivnı ´ i regresivnı ´ fa ´zi. Progresivnı ´ fa ´ze testuje nove ´ fce (nove ˇ pr ˇidane ´ nebo modifikovane ´ moduly jiz ˇ integrovany ´mi moduly). Regresivnı ´ fa ´ze testuje integrovany ´ch c ˇa ´stech.
[] * jako jednoduchou uka ´zku uvedu c ˇa ´st pr ˇı ´kazove ´ho souboru pro pr ˇı ´kazovy ´ interpret (shell) v UNIXu, ktery ´ prova ´dı ´ testova ´nı ´ aplikace: test-mkdata > data.test test-oracle < data.test > result1.test aplikace < data.test > result2.test if cmp result1.test result2.test; then echo Test 1: PASSED else echo Test 1: FAILED fi
# # # # #
Vytvor ˇı ´ testovacı ´ data ”data.test”. Ora ´kulum pr ˇedpovı ´ vy ´sledky ”result1.test”. Testujeme aplikaci. Porovna ´me skutec ˇne ´ a pr ˇedpove ˇzene ´ vy ´sledky. Soubory stejne ´ -> test pros ˇel.
# Soubory rozdı ´lne ´ -> test nepros ˇel.
* na ´stroje pro zachycenı ´ a pozde ˇjs ˇı ´ pr ˇehra ´nı ´ testu ˚ (capture-replay tool) - informace prote ´kajı ´ SW syste ´mem - na vhodne ´ mı ´sto toku dat aplikacı ´ vloz ˇı ´me na ´stroj, ktery ´ tekoucı ´ data zaznamena ´ - tester spustı ´/vykona ´ a zaznamena ´ testovacı ´ pr ˇı ´pady - pozde ˇji mu ˚z ˇe zaznamenane ´ testovacı ´ pr ˇ´ ıpady spustit znovu (regresivnı ´ testova ´nı ´) - existujı ´ komerc ˇnı ´ capture-replay na ´stroje pro zachycenı ´/pr ˇehra ´nı ´ stisku ˚ kla ´ves a pohybu ˚ mys ˇi, obsahujı ´cı ´ i na ´stroje pro zachycenı ´ a porovna ´nı ´ vy ´stupu ˚ na obrazovku - pouz ˇı ´vane ´ pro GUI aplikace . pro ve ˇts ˇinu ostatnı ´ch ´ uc ˇelu ˚ (testova ´nı ´ zapouzdr ˇeny ´ch syste ´mu ˚ apod.) je ve ˇts ˇinou nutne ´ vytvor ˇit si vlastnı ´ SW pro podporu testova ´nı ´ * kolik defektu ˚ lze oc ˇeka ´vat a kolik z nich lze najı ´t testova ´nı ´m? - podle kvality vy ´voje lze oc ˇeka ´vat asi 10 az ˇ 50 defektu ˚ na 1000 r ˇa ´dek ko ´du pr ˇed testova ´nı ´m . napr ˇ. Microsoft Application Division 10-20 defektu ˚/1000 r ˇa ´dek ko ´du (Moore 1992) - testy najdou obvykle me ´ne ˇ nez ˇ 60% defektu ˚, proto je vhodne ´ je kombinovat s inspekcemi - ne ˇkter ˇı ´ autor ˇi uva ´de ˇjı ´, z ˇe defekty jsou c ˇaste ˇji v testovacı ´ch pr ˇı ´padech nez ˇ v testovane ´m ko ´du (McConnell 1993) - pro kriticke ´ syste ´my je vhodne ´ pouz ˇı ´vat kombinaci forma ´lnı ´ch metod vy ´voje, inspekcı ´ a testova ´nı ´ (napr ˇ. pro Cleanroom metodiku v pru ˚me ˇru 2.3 defektu ˚/1000 r ˇa ´dek ko ´du, pro ne ˇktere ´ syste ´my az ˇ 0 defektu ˚)
Pozna ´mka (kvalita SW a rychlost vy ´voje) Ve ˇts ˇina manageru ˚ se snaz ˇı ´ zkra ´tit dobu vy ´voje omezenı ´m c ˇasu ve ˇnovane ´mu inspekcı ´m na ´vrhu a ko ´du, testova ´nı ´ apod. Zejme ´na testova ´nı ´ by ´va ´ c ˇasto
zswi/pDscm.d
21. kveˇtna 2004
143
obe ˇtova ´no, protoz ˇe je na konci vy ´vojove ´ho cyklu (tj. blı ´zko deadline). Podle dostupny ´ch studiı ´ (shrnuty ´ch napr ˇ. v DeMarco a Lister 1987, McConnell 1996 aj.) tento chybny ´ pr ˇı ´stup celkovou dobu vy ´voje naopak prodluz ˇuje. Jiny ´mi slovy, kvalitne ˇjs ˇı ´ produkt bude dr ˇı ´ve dokonc ˇen. Pokud obe ˇtujeme kvalitu, vy ´voj se tı ´m prodlouz ˇı ´ a prodraz ˇı ´. Ve skutec ˇnosti vypada ´ vztah mezi dobou vy ´voje a poc ˇtem defektu ˚ pr ˇibliz ˇne ˇ na ´sledovne ˇ: většina projektů se pohybuje zde nejrychlejší projekty
životně kritické systémy
doba vývoje cca 95%
100%
% defektů odstraněných před uvolněním produktu
[]
Lade ˇnı ´ ====== * testova ´nı ´m nalezneme defekty, na ´sleduje proces lade ˇnı ´ (angl. debugging) * lade ˇnı ´ = identifikace pr ˇı ´c ˇiny defektu (90% c ˇasu) a jejı ´ oprava (10% c ˇasu) * me ˇlo by probı ´hat v 5 krocı ´ch - (1) stabilizace symptomu, (2) nalezenı ´ pr ˇı ´c ˇiny, (3) oprava, (4) otestova ´nı ´ opravy defektu, (5) vyhleda ´nı ´ obdobny ´ch defektu ˚ * stabilizace symptomu - potr ˇebujeme, aby se defekt projevoval spolehlive ˇ - proto nejprve hleda ´me testovacı ´ pr ˇı ´pad, ktery ´ symptom reprodukuje - testovacı ´ pr ˇı ´pad co nejvı ´ce zjednodus ˇı ´me, aby se defekt jes ˇte ˇ projevoval - pr ˇi zjednodus ˇova ´nı ´ testovacı ´ho pr ˇı ´padu c ˇasto jiz ˇ mu ˚z ˇeme vytva ´r ˇet hypote ´zu, proc ˇ defekt nasta ´va ´ - existujı ´ defekty, ktere ´ se neprojevujı ´ spolehlive ˇ, napr ˇı ´klad neinicializovane ´ prome ˇnne ´, neplatny ´ ukazatel, chyby c ˇasove ´ho soube ˇhu . ne ˇktere ´ z te ˇchto defektu ˚ mu ˚z ˇeme zviditelnit; napr ˇı ´klad neinicializovane ´ prome ˇnne ´ - pr ˇed spus ˇte ˇnı ´m programu pame ˇt’ zaplnit na ´hodny ´mi hodnotami apod. . chyby c ˇasove ´ho soube ˇhu lze zviditelnit pomocı ´ vloz ˇenı ´ yield(), pr ˇı ´padne ˇ na ´hodne ´ho prokla ´da ´nı ´ (o chyba ´ch c ˇasove ´ho soube ˇhu - viz pr ˇedme ˇt ZOS) * nalezenı ´ pr ˇı ´c ˇiny symptomu - napr ˇ. hleda ´nı ´ zu ´z ˇenı ´m podezr ˇele ´ c ˇa ´sti ko ´du: systematicky vynecha ´va ´me ko ´d (i na ´ ukor funkc ˇnosti), testujeme zda se symptom jes ˇte ˇ vyskytuje . adaptace metody bina ´rnı ´ho vyhleda ´va ´nı ´ - vynecha ´ se pr ˇibliz ˇne ˇ polovina ko ´du, pokud se symptom projevuje ope ˇt rozde ˇlı ´me na poloviny atd. . vynecha ´va ´nı ´ vola ´nı ´ podprogramu - pouz ˇitı ´ ladı ´cı ´ho programu nebo ladı ´cı ´ch vy ´pisu ˚ - sledujeme kde nastane symptom . pr ˇeskakujeme ty c ˇa ´sti programu ktere ´ nejsou relevantnı ´, mu ˚z ˇeme pouz ˇı ´t obdobne ´ metody jako vy ´s ˇe (aniz ˇ bychom vynecha ´vali ko ´d) - ne ˇkdy pomu ˚z ˇe se vyspat (podve ˇdomı ´ pracuje za na ´s) * oprava defektu - pokud jsme defekt nalezli, by ´va ´ jeho oprava pome ˇrne ˇ jednoducha ´, ale je vysoke ´ nebezpec ˇı ´ zanesenı ´ dals ˇı ´ho defektu (podle ne ˇktery ´ch studiı ´ vı ´ce nez ˇ 50%) - podle studie z 1986 majı ´ ve ˇts ˇı ´ s ˇanci prove ´st opravu spra ´vne ˇ programa ´tor ˇi s celkovou znalostı ´ programu (oproti programa ´toru ˚m kter ˇı ´ se sezna ´mı ´ pouze s opravovanou c ˇa ´stı ´ programu) - proto je pr ˇed opravou tr ˇeba rozume ˇt jak proble ´mu, tak opravovane ´mu programu * opravu je tr ˇeba otestovat - defekty je nutne ´ opravovat po jednom, opravy po jedne ´ otestovat - pote ´ program otestovat jako celek, nejle ´pe regresivnı ´mi testy, aby se uka ´zaly pr ˇı ´padne ´ vedlejs ˇı ´ efekty opravy
21. kveˇtna 2004
144
zswi/pDscm.d
- pro pr ˇı ´pad defektu v oprave ˇ je vhodne ´ mı ´t uchova ´nu pr ˇedchozı ´ verzi (ruc ˇne ˇ, SCM), porovnat obe ˇ verze (napr ˇ. v UNIXu programem diff(1)), z toho je c ˇasto moz ˇne ´ zjistit proble ´m. * hleda ´me obdobne ´ defekty Defenzivnı ´ programova ´nı ´ ----------------------* defenzivnı ´ programova ´nı ´ = zabezpec ˇenı ´ definovane ´ho chova ´nı ´ pr ˇi chybny ´ch vstupech, zamezenı ´ propagace chyb z podprogramu ven * na ´stroje: - kontroly vstupnı ´ch parametru ˚ - makro assert() v C, aserce v Jave ˇ), preconditions/postconditions v Eiffelu (programming by contract) . pokud nejsou, snadno si naprogramujeme jejich ekvivalent, napr ˇ. v Pascalu: procedure Assert(Condition: boolean; Message: string); begin if (not Condition) then begin writeln(’Assertion ’, Message, ’ failed. Aborting the program’); halt; end end; . pouz ˇitı ´ napr ˇ.: Assert(delitel <> 0, ’delitel <> 0’);
(* de ˇlitel nesmı ´ by ´t roven 0 *)
- vy ´jimky v Jave ˇ, C++, Delphi, Pythonu apod. - konstrukce typu try-catch a try-catch-finally: try { foo(); } catch (SomethingWentWrongException e) { System.out.println(”some error”); } finally { dispose(); }
// zde mu ˚z ˇe nastat vy ´jimka // pokud nastane vy ´jimka, // provede se toto // nakonec se vz ˇdy provede // toto
- program mu ˚z ˇe pr ˇi spus ˇte ˇnı ´ ove ˇr ˇovat sve ´ datove ´ struktury, vola ´nı ´ fcı ´ apod. * reakce na chybu - fce vra ´tı ´ specia ´lnı ´ na ´vratovy ´ ko ´d - programova ´ vy ´jimka, zpu ˚sob propagace - podle stanoveny ´ch konvencı ´ - nastavenı ´ defaultnı ´ hodnoty vstupu nebo defaultnı ´ho stavu * o zpu ˚sobu reakce na chybu se by me ˇlo rozhodnout na ´ urovni architektury, aplikace by se me ˇla ve vs ˇech svy ´ch c ˇa ´stech chovat konzistentne ˇ Pozna ´mka (rozdı ´l mezi vy ´vojovou verzı ´ produktu a dodanou verzı ´) Zatı ´mco be ˇhem vy ´voje potr ˇebujeme, aby defekty byly co nejle ´pe viditelne ´, ve vy ´sledne ´m produktu se naopak snaz ˇı ´me, aby defekty co nejme ´ne ˇ rus ˇily. Ve vy ´sledne ´m produktu proto: * ponecha ´va ´me ko ´d ktery ´ kontroluje vy ´znamne ´ defekty; pokud aplikace hla ´sı ´ internı ´ chybu, me ˇla by take ´ ozna ´mit, jaky ´m zpu ˚sobem jı ´ uz ˇivatel mu ˚z ˇe ohla ´sit * zrus ˇı ´me ko ´d testujı ´cı ´ nepodstatne ´ defekty, * zrus ˇı ´me ko ´d ktery ´ zpu ˚sobuje hava ´rie * ponecha ´me ko ´d ktery ´ umoz ˇnı ´ pr ˇijatelne ´ ukonc ˇenı ´ aplikace pr ˇi chybe ˇ (napr ˇ. s uloz ˇenı ´m dat) Rus ˇenı ´ ko ´du neprova ´dı ´me fyzicky (pr ˇi lade ˇnı ´ ho budeme ope ˇt potr ˇebovat), ale napr ˇ. pomocı ´ preprocesoru vynecha ´me te ˇlo procedury Assert, vyuz ˇijeme verzova ´nı ´ apod.
zswi/pDscm.d
21. kveˇtna 2004
Napr ˇ. v jazyce C definicı ´ makra NDEBUG zme ˇnı ´me vs ˇechny vy ´skyty assert() na pra ´zdny ´ pr ˇı ´kaz. []
´drz U ˇba SW syste ´mu ˚ ================= * ´ udrz ˇba SW = aktivity, ktere ´ jsou prova ´de ˇny po uvolne ˇnı ´ programu, resp. po jeho doda ´nı ´ za ´kaznı ´kovi * ´ udrz ˇba zahrnuje pr ˇedevs ˇı ´m tyto tr ˇi typy aktivit: - oprava chyb SW (corrective maintenance) - pr ˇizpu ˚sobenı ´ SW zme ˇna ´m prostr ˇedı ´, ve ktere ´m be ˇz ˇı ´ - OS, periferie apod. (adaptive maintenance) - pr ˇida ´va ´nı ´ nove ´ funkc ˇnosti nebo zme ˇna funkc ˇnosti na za ´klade ˇ poz ˇadavku ˚ uz ˇivatele (perfective maintenance) * v pru ˚me ˇru cca 17% ´ udrz ˇby se ty ´ka ´ opravy chyb, 18% pr ˇizpu ˚sobenı ´ SW zme ˇna ´m prostr ˇedı ´ a 65% pr ˇida ´va ´nı ´ nebo zme ˇny funkc ˇnosti * ´ udrz ˇba tvor ˇı ´ cca 50% az ˇ 75% vy ´voje, pro obtı ´z ˇne ˇ zme ˇnitelne ´ syste ´my (jako jsou zapouzdr ˇene ´ syste ´my rea ´lne ´ho c ˇasu) az ˇ 80% - studie ukazujı ´ z ˇe cena ´ udrz ˇby syste ´mu postupne ˇ stoupa ´ - proto je efektivnı ´ syste ´m navrhnout a implementovat tak, aby se cena ´ udrz ˇby snı ´z ˇila * proces ´ udrz ˇby je spus ˇte ˇn mnoz ˇinou poz ˇadavku ˚ na zme ˇny od uz ˇivatelu ˚ syste ´mu, managementu nebo od za ´kaznı ´ka - provedeme vyhodnocenı ´ ceny a dopadu zme ˇn - navrz ˇene ´ zme ˇny jsou schva ´leny nebo neschva ´leny; ne ˇktere ´ jsou odloz ˇeny . rozhodnutı ´ o schva ´lenı ´/neschva ´lenı ´ zme ˇn je do urc ˇite ´ mı ´ry ovlivne ˇno udrz ˇovatelnostı ´ komponenty, ve ktere ´ zme ˇnu prova ´dı ´me - zme ˇny jsou implementova ´ny a ove ˇr ˇeny . v idea ´lnı ´m pr ˇı ´pade ˇ: zme ˇna specifikace syste ´mu, na ´vrhu, implementace, otestova ´nı ´ syste ´mu - je doda ´na nova ´ verze * uz ˇ bylo probı ´ra ´no, viz ”Spra ´va poz ˇadavku ˚” na tr ˇetı ´ pr ˇedna ´s ˇce Nestrukturovana ´ ´ udrz ˇba ...................... * vy ´s ˇe uvedene ´ by ovs ˇem platilo v idea ´lnı ´m pr ˇı ´pade ˇ * pracnost a cenu ´ udrz ˇby ve skutec ˇnosti zvys ˇujı ´ tyto faktory: - po doda ´nı ´ produktu je ty ´m obvykle rozpus ˇte ˇn, lide ´ jsou pr ˇir ˇazeni jiny ´m projektu ˚m; ´ udrz ˇba je pr ˇenecha ´na jine ´mu ty ´mu nebo jednotlivcu ˚m, kter ˇı ´ syste ´m neznajı ´ => ve ˇts ˇina jejich ´ usilı ´ musı ´ by ´t ve ˇnova ´na pochopenı ´ existujı ´cı ´ho syste ´mu - smlouva by ´va ´ obvykle pouze na doda ´nı ´ syste ´mu, o ´ udrz ˇbe ˇ se nemluvı ´ => ty ´m nema ´ motivaci vytva ´ˇ ret udrz ˇovatelny ´ SW (zvla ´s ˇte ˇ pokud se pr ˇedpokla ´da ´, z ˇe ´ udrz ˇbu bude prova ´de ˇt ne ˇkdo jiny ´) - ´ udrz ˇba je obvykle pr ˇenecha ´na nejme ´ne ˇ zkus ˇeny ´m programa ´toru ˚m, navı ´c syste ´my mohou by ´t vytvor ˇeny v zastaraly ´ch programovacı ´ch jazycı ´ch (Cobol), ktere ´ se ty ´m prova ´de ˇjı ´cı ´ ´ udrz ˇbu musı ´ teprve nauc ˇit - zme ˇnami se sniz ˇuje strukturovanost ko ´du - tı ´m roste ”entropie” SW, dokumentace stary ´ch syste ´mu ˚ mu ˚z ˇe by ´t ztracena nebo mu ˚z ˇe by ´t nekonzistentnı ´ atd. * v mnoha pr ˇı ´padech je jediny ´m dostupny ´m prvkem SW konfigurace zdrojovy ´ text - proto proces ´ udrz ˇby zac ˇı ´na ´ (obtı ´z ˇny ´m) procesem vyhodnocenı ´ ko ´du . ko ´d obsahuje pouze implementaci, nikoli za ´me ˇr => obtı ´z ˇna ´ interpretace . pokud neexistujı ´ testy, nenı ´ moz ˇne ´ regresivnı ´ testova ´nı ´ - takove ´mu pr ˇı ´padu r ˇı ´ka ´me nestrukturovana ´ ´ udrz ˇba (unstructured maintenance), produktivita klesa ´ na 40:1 oproti vy ´voji (podle Boehma) - tomuto stavu se snaz ˇı ´me pr ˇedejı ´t, pokud je to moz ˇne ´ * v za ´sade ˇ dve ˇ moz ˇnosti jak se k proble ´mu postavit: - pr ˇedpokla ´dat vodopa ´dovy ´ model - syste ´m vyvinout, udrz ˇovat dokud se ´ udrz ˇba stane ekonomicky neu ´nosna ´, pak nahradit novy ´m syste ´mem
145
21. kveˇtna 2004
146
- evoluce syste ´mu - pr ˇedpokla ´dat napr ˇ. spira ´lovy ´ model . syste ´m by me ˇl by ´t navrz ˇen tak, aby ho bylo moz ˇne ´ pr ˇizpu ˚sobovat novy ´m poz ˇadavku ˚m . pokud syste ´m nevyhovuje (= nı ´zka ´ udrz ˇovatelnost), musı ´me syste ´m pr ˇepracovat (pr ˇestrukturovat apod.) * udrz ˇovatelnost syste ´mu lze me ˇr ˇit na ´sledujı ´cı ´mi metrikami: - poc ˇet poz ˇadavku ˚ na opravy chyb . pokud poc ˇet poz ˇadavku ˚ na opravy stoupa ´, mu ˚z ˇe to znamenat, z ˇe do programu je procesem ´ udrz ˇby vna ´s ˇeno vı ´ce chyb nez ˇ je jich odstran ˇova ´no ´ udrz ˇbou, tj. indikuje snı ´z ˇenı ´ udrz ˇovatelnosti - pru ˚ me ˇrna ´ doba potr ˇebna ´ pro vyhodnocenı ´ dopadu zme ˇny . odra ´z ˇı ´ rozsah (napr ˇ. poc ˇet komponent) ktere ´ jsou ovlivne ˇny poz ˇadavkem na zme ˇnu . pokud naroste, udrz ˇovatelnost se sniz ˇuje - pru ˚ me ˇrna ´ doba implementace poz ˇadavku na zme ˇnu - poc ˇet nevyr ˇı ´zeny ´ch poz ˇadavku ˚ na zme ˇnu * pokud je program s ˇpatne ˇ udrz ˇovatelny ´, jsou moz ˇne ´ na ´sledujı ´cı ´ kroky pro zleps ˇenı ´: - konverze SW do modernı ´ho programovacı ´ho jazyka (nebo do moderne ˇjs ˇı ´ varianty pouz ˇite ´ho programovacı ´ho jazyka); napr ˇı ´klad z Fortranu do jazyka Java nebo C# - zpe ˇtne ´ inz ˇeny ´rstvı ´ = analy ´za programu s cı ´lem najı ´t specifikaci a na ´vrh SW . obvykle na za ´klade ˇ zdrojovy ´ch textu ˚ , v ne ˇktery ´ch pr ˇı ´padech jsou ztraceny a je nutne ´ vycha ´zet ze spustitelne ´ho ko ´du - vyleps ˇenı ´ struktury programu s cı ´lem zleps ˇit jeho srozumitelnost . pro automatickou transformaci nestrukturovane ´ho ko ´du na strukturovany ´ existujı ´ na ´stroje (pr ˇi transformace ale ztratı ´me pu ˚vodnı ´ komenta ´r ˇe) - modularizace programu = sdruz ˇenı ´ souvisejı ´cı ´ch c ˇa ´stı ´ programu, v ne ˇktery ´ch pr ˇ´ ıpadech vc ˇetne ˇ transformace architektury SW . stejna ´ motivace jako pr ˇi vytva ´r ˇenı ´ modulu ˚ pr ˇi vy ´voji, tj. abstrakce dat, abstrakce r ˇı ´zenı ´ HW, sdruz ˇenı ´ pr ˇı ´buzny ´ch fcı ´ - pr ˇizpu ˚sobenı ´ zpracova ´vany ´ch dat zme ˇne ˇne ´mu programu O postupech pr ˇi pr ˇepracova ´va ´nı ´ existujı ´cı ´ch syste ´mu ˚ hovor ˇı ´ kniha Martina Fowlera ”Refactoring: Zleps ˇenı ´ existujı ´cı ´ho ko ´du. Grada, Praha 2003.” Metriky ======= * metrika (metrics) = jake ´koli me ˇr ˇenı ´ atributu ˚ SW produktu nebo SW procesu - napr ˇ. poc ˇet r ˇa ´dku ˚ ko ´du, poc ˇet defektu ˚ , defekty na 1000 r ˇa ´dek ko ´du apod. - jsou potr ˇebne ´, abyste ve ˇde ˇli co se s projektem opravdu de ˇje, pro zleps ˇova ´nı ´ SW nebo SW procesu, pro odhady o budoucı ´ch projektech, pro informaci kam zame ˇr ˇit testova ´nı ´ atd. - napr ˇ. pr ˇed zavedenı ´m testovacı ´ho na ´stroje mu ˚z ˇeme zme ˇr ˇit poc ˇet defektu ˚ nalezeny ´ch za c ˇasovou jednotku, tote ´z ˇ po zavedenı ´ na ´stroje - jiny ´ pr ˇı ´klad - nejvı ´ce defektu ˚ by ´va ´ v procedura ´ch/metoda ´ch s vysokou cyklomatickou sloz ˇitostı ´ - tam bychom me ˇli zame ˇr ˇit sve ´ ´ usilı ´ pr ˇi testova ´nı ´ * nejdu ˚lez ˇite ˇjs ˇı ´ metriky se ty ´kajı ´ na ´sledujı ´cı ´ch oblastı ´: - metriky analyticke ´ho modelu (napr ˇ. kvalita specifikace) - metriky na ´vrhu (napr ˇ. sloz ˇitost komponent) - metriky zdrojovy ´ch textu ˚ (napr ˇ. nı ´z ˇe uvedene ´ LOC a cyklomaticka ´ sloz ˇitost) - metriky pro testova ´nı ´ (napr ˇ. pokrytı ´ logiky programu, efektivita testova ´nı ´) * nejjednodus ˇs ˇı ´ a nejc ˇaste ˇjs ˇı ´ metrika zdrojovy ´ch textu ˚ - poc ˇet r ˇa ´dek ko ´du (Lines of Code, LOC) - ota ´zka - co ma ´me poc ˇı ´tat jako r ˇa ´dek ko ´du? - pokud se snaz ˇı ´me me ˇr ˇit mnoz ˇstvı ´ pra ´ce do programu vloz ˇene ´, nebudeme zapoc ˇı ´ta ´vat komenta ´r ˇe, pra ´zdne ´ r ˇa ´dky a automaticky generovany ´ ko ´d - ne ˇkdy se nazy ´va ´ NCLOC (Non-comment LOC) nebo ELOC (Effective LOC) - je za ´klad metodiky COCOMO pro odhad ceny SW * McCabeho metrika ”cyklomaticka ´ sloz ˇitost” poc ˇı ´ta ´ rozhodovacı ´ body v podprogramu - vysoka ´ cyklomaticka ´ sloz ˇitost ma ´ korelaci s chybovostı ´, s obtı ´z ˇnostı ´ c ˇı ´st a testovat podprogram (jak uz ˇ bylo ˇ rec ˇeno, prosta ´ de ´lka podprogramu je
zswi/pDscm.d
zswi/pDscm.d
21. kveˇtna 2004
nema ´ korelaci s chybovostı ´) - cyklomatickou sloz ˇitost spoc ˇteme na ´sledovne ˇ: 1. Pro pr ˇı ´mou cestu podprogramem zapoc ˇteme 1. 2. Pro kaz ˇde ´ z na ´sledujı ´cı ´ch klı ´c ˇovy ´ch slov nebo jejich ekvivalentu ˚ pr ˇic ˇteme jednic ˇku: if, while, do-while, for, a pro ”and a ”or” ve sloz ˇeny ´ch podmı ´nka ´ch. 3. Pro kaz ˇdy ´ pr ˇı ´pad v switch/case pr ˇic ˇteme 1. - pokud je >10, je pr ˇı ´znak z ˇe je vhodne ´ podprogram zjednodus ˇit (napr ˇ. c ˇa ´st podprogramu vloz ˇit do dals ˇı ´ho podprogramu volane ´ho z pu ˚vodnı ´ho) Pozna ´mka pro zajı ´mavost (cyklomaticka ´ sloz ˇitost a graf toku r ˇı ´zenı ´) Pokud v rozhodovacı ´ch pr ˇı ´kazech nejsou sloz ˇene ´ podmı ´nky, odpovı ´da ´ cyklomaticka ´ sloz ˇitost poc ˇtu regionu ˚ v grafu toku r ˇı ´zenı ´ podprogramu. Pojmem region se myslı ´ oblast ohranic ˇena ´ hranami a uzly grafu; oblast mimo graf se poc ˇı ´ta ´ jako samostatny ´ region. Jako pr ˇı ´klad uva ´dı ´m graf toku r ˇı ´zenı ´ pro pr ˇı ´klad bina ´rnı ´ho vyhleda ´va ´nı ´, uvedeny ´ na minule ´ pr ˇedna ´s ˇce:
R1 while
n3
R2
R3 if n5 if n10
R4
Pro kontrolu si mu ˚z ˇeme spoc ˇı ´st cyklomatickou sloz ˇitost pomocı ´ vy ´s ˇe uvedene ´ metody: zapoc ˇteme pr ˇı ´mou cestu, while, if a if, tj. vy ´sledek je ope ˇt 4. [] Ne ˇktere ´ uz ˇitec ˇne ´ metriky ........................ * velikost zdrojovy ´ch textu ˚ - celkovy ´ poc ˇet r ˇa ´dek (LOC) - celkovy ´ poc ˇet komenta ´r ˇovy ´ch r ˇa ´dek (CLOC) - poc ˇet deklaracı ´ dat - poc ˇet pra ´zdny ´ch r ˇa ´dek * produktivita - E-faktor (environmental factor) = poc ˇet nepr ˇerus ˇeny ´ch hodin / celkova ´ pracovnı ´ doba; optima ´lnı ´ je cca 0.4 - pracovnı ´ doba stra ´vena ´ na projektu - pracovnı ´ doba stra ´vena ´ na kaz ˇde ´m podprogramu - poc ˇet zme ˇn v podprogramu - na ´klady projektu - na ´klady projektu na r ˇa ´dek ko ´du - na ´klady na opravu defektu * sledova ´nı ´ defektu ˚ - va ´z ˇnost defektu - mı ´sto defektu - zpu ˚sob opravy defektu - osoba zodpove ˇdna ´ za defekt - poc ˇet r ˇa ´dek zme ˇne ˇny ´ch pr ˇi oprave ˇ defektu - pracovnı ´ doba stra ´vena ´ opravou defektu - pru ˚me ˇrna ´ doba potr ˇebna ´ na nalezenı ´ defektu - pru ˚me ˇrna ´ doba potr ˇebna ´ na opravu defektu - poc ˇet pokusu ˚ opravit defekt - poc ˇet novy ´ch chyb zaneseny ´ch opravou defektu * celkova ´ kvalita
147
21. kveˇtna 2004
148 -
celkovy ´ poc ˇet defektu ˚ poc ˇet defektu ˚ v podprogramu pru ˚me ˇrny ´ poc ˇet defektu ˚ na 1000 r ˇa ´dek ko ´du str ˇednı ´ doba mezi hava ´riemi chyby detekovane ´ pr ˇekladac ˇem
* udrz ˇovatelnost - poc ˇet parametru ˚ pr ˇeda ´vany ´ch kaz ˇde ´mu podprogramu - poc ˇet loka ´lnı ´ch prome ˇnny ´ch pouz ˇity ´ch kaz ˇdy ´m podprogramem - poc ˇet podprogramu ˚ volany ´ch kaz ˇdy ´m podprogramem - poc ˇet rozhodovacı ´ch bodu ˚ v kaz ˇde ´m podprogramu - sloz ˇitost r ˇı ´dı ´cı ´ch konstrukcı ´ v kaz ˇde ´m podprogramu - poc ˇet r ˇa ´dek ko ´du v kaz ˇde ´m podprogramu - poc ˇet komenta ´r ˇ˚ u v kaz ˇde ´m podprogramu - poc ˇet deklaracı ´ dat v kaz ˇde ´m podprogramu - poc ˇet pra ´zdny ´ch r ˇa ´dek v kaz ˇde ´m podprogramu - poc ˇet pr ˇı ´kazu ˚ goto v kaz ˇde ´m podprogramu - poc ˇet vstupne ˇ/vy ´stupnı ´ch pr ˇı ´kazu ˚ v kaz ˇde ´m podprogramu * objektove ˇ orientovane ´ metriky - va ´z ˇena ´ sloz ˇitost tr ˇı ´dy - hloubka stromu de ˇdic ˇnosti - poc ˇet pr ˇı ´my ´ch potomku ˚ tr ˇı ´dy - poc ˇet operacı ´ pr ˇedefinovany ´ch v kaz ˇde ´ podtr ˇı ´de ˇ - stupen ˇ prova ´zanosti mezi tr ˇı ´dami
Pra ´ce v ty ´mech ============== * ve ˇts ˇina profesiona ´lnı ´ch programa ´toru ˚ pracuje v ty ´mech, ty ´my od 2 do ne ˇkolika set lidı ´ - pokud je ty ´m velky ´, je zr ˇejma ´ potr ˇeba aby byl ne ˇjak strukturova ´n . rozde ˇlenı ´ do skupin, kaz ˇda ´ skupina je zodpove ˇdna ´ za podprojekt . skupiny by neme ˇly mı ´t vı ´ce nez ˇ 8 c ˇlenu ˚ . maly ´ poc ˇet = zmens ˇenı ´ komunikac ˇnı ´ch proble ´mu ˚ Constantine (1993) popisuje c ˇtyr ˇi paradigmata pro organizaci ty ´mu ˚: * uzavr ˇene ´ paradigma - ty ´m ma ´ pevne ˇ stanovenou hierarchii - pr ˇı ´kladem je na prvnı ´ pr ˇedna ´s ˇce zmı ´ne ˇny ´ ”chirurgicky ´ ty ´m” - tyto ty ´my pracujı ´ dobr ˇe, pokud je SW podobny ´ pr ˇedchozı ´m projektu ˚m, obvykle by ´vajı ´ me ´ne ˇ inovativnı ´ * na ´hodne ´ paradigma - ty ´m ma ´ volnou strukturu, role za ´visejı ´ na iniciative ˇ jednotlivy ´ch c ˇlenu ˚ ty ´mu (”tvor ˇiva ´ neza ´vislost”) - mu ˚ˇ ze mı ´t vysokou vy ´konnost, pokud si c ˇlenove ´ mohou vza ´jemne ˇ du ˚ve ˇr ˇovat, jednotlivı ´ c ˇlenove ´ majı ´ pr ˇime ˇr ˇene ´ dovednosti a pokud neobsahuje rebely - vhodne ´ pro inovativnı ´ projekty, c ˇasto proble ´my pokud je vyz ˇadova ´na ”be ˇz ˇna ´ pra ´ce” * otevr ˇene ´ paradigma - ty ´m zaloz ˇeny ´ na spolupra ´ci, typicky znac ˇna ´ komunikace a rozhodova ´nı ´ zaloz ˇene ´ na konsensu - vhodne ´ pro r ˇes ˇenı ´ obtı ´z ˇny ´ch proble ´mu ˚, obvykle neby ´va ´ tak efektivnı ´ jako jine ´ typy ty ´mu ˚ * synchronnı ´ paradigma - za ´visı ´ na moz ˇnosti rozde ˇlit proble ´m na neza ´visle ´ c ˇa ´sti - c ˇlenove ´ ty ´mu pracujı ´ na jednotlivy ´ch podproble ´mech, c ˇlenove ´ mezi sebou nemusejı ´ pr ˇı ´lis ˇ komunikovat Neza ´visle na typu organizace ty ´mu ovlivn ˇujı ´ pra ´ci v ty ´mu pr ˇedevs ˇı ´m 4 faktory: * sloz ˇenı ´ ty ´mu: ma ´ ty ´m vyva ´z ˇene ´ technicke ´ schopnosti, zkus ˇenosti, osobnostnı ´ charakteristiky? * koheze ty ´mu: je ty ´m mnoz ˇinou jednotlivcu ˚ nebo ma ´ ”skupinove ´ho ducha” (skupina o sobe ˇ uvaz ˇuje jako o ty ´mu) * skupinova ´ komunikace: doka ´z ˇı ´ spolu c ˇlenove ´ efektivne ˇ komunikovat? * organizace ty ´mu: ma ´ kaz ˇdy ´ pr ˇime ˇr ˇenou roli v ty ´mu?
zswi/pDscm.d
zswi/pDscm.d
21. kveˇtna 2004
Sloz ˇenı ´ ty ´mu ............ * v psychologicke ´ studii motivace (Bass & Dunteman) se uka ´zalo, z ˇe profesiona ´ly lze v za ´sade ˇ rozde ˇlit podle jejich motivace do tr ˇı ´ kategoriı ´: - ´ ukolove ˇ orientovanı ´ - motivacı ´ je jim pra ´ce, kterou vykona ´vajı ´ . pr ˇi vytva ´r ˇenı ´ SW je motivacı ´ intelektua ´lnı ´ vy ´zva vytvor ˇit SW . platı ´ pro velkou c ˇa ´st vy ´voja ´r ˇ˚ u - orientovanı ´ na sebe - v za ´sade ˇ motivova ´ni osobnı ´m ´ uspe ˇchem a uzna ´nı ´m . vy ´voj SW je jim prostr ˇedkem k dosaz ˇenı ´ vlastnı ´ch cı ´lu ˚ - orientovanı ´ na interakci - jsou motivovanı ´ pr ˇı ´tomnostı ´ a c ˇinnostı ´ spolupracovnı ´ku ˚ * lide ´ orientovanı ´ na interakci pracujı ´ rade ˇji ve skupina ´ch, zatı ´mco ´ ukolove ˇ orientovanı ´ a na sebe orientovanı ´ obvykle rade ˇji pracujı ´ sami * u z ˇen je pravde ˇpodobne ˇjs ˇı ´ orientace na interakci nez ˇ u muz ˇ˚ u, c ˇasto jsou efektivne ˇjs ˇı ´ komunika ´tor ˇi * motivace jednotlivce se skla ´da ´ ze vs ˇech tr ˇı ´ kategoriı ´, jedna z nich ale ve ˇts ˇinou pr ˇevaz ˇuje * osobnosti nejsou staticke ´, motivace se mu ˚z ˇe me ˇnit . napr ˇı ´klad pokud ma ´ ´ ukolove ˇ orientovany ´ c ˇlen ty ´mu pocit, z ˇe nenı ´ pr ˇime ˇr ˇene ˇ odme ˇn ˇova ´n, mu ˚z ˇe se jeho motivace zme ˇnit na ”orientovany ´ na sebe” * pro skupinu je dobre ´, pokud obsahuje dopln ˇujı ´cı ´ se typy osobnostı ´: - ´ ukolove ˇ orientovanı ´ by ´vajı ´ obvykle nejsilne ˇjs ˇı ´ technicky - na sebe orientovanı ´ obvykle tlac ˇı ´ ty ´m na dokonc ˇenı ´ pra ´ce (vy ´sledky) - orientovanı ´ na interakci napoma ´hajı ´ komunikaci uvnitr ˇ skupiny * Proc ˇ optimalizovat sloz ˇenı ´ ty ´mu [pr ˇevzato od P. Brady] Dobr ˇe vyva ´z ˇeny ´ ty ´m je velmi silna ´ zbran ˇ s enormnı ´ kapacitou k tvor ˇive ´ pra ´ci - a proto je take ´ drahy ´ a musı ´ by ´t zate ˇz ˇova ´n odpovı ´dajı ´cı ´mi ´ ukoly. Optimalizovat sloz ˇenı ´ je tedy vhodne ´ pr ˇi vytva ´r ˇenı ´ novy ´ch skupin za ´ uc ˇelem ambicio ´znı ´ch a na ´roc ˇny ´ch ´ ukolu ˚, a take ´ pro ty ´my, ktere ´ musı ´ obsta ´t v prostr ˇedı ´ velky ´ch zme ˇn, silne ´ konkurence, potr ˇeby rychle ´ inovace a akc ˇnosti. * Kdy sloz ˇenı ´ ty ´mu nenı ´ kriticke ´ [pr ˇevzato od P. Brady] Nenı ´ vz ˇdy nutne ´ snaz ˇit se optimalizovat sloz ˇenı ´ ty ´mu. Optimalizace nenı ´ na mı ´ste ˇ v pr ˇı ´padech rutinnı ´ch operacı ´ a ´ uloh pod intelektua ´lnı ´ ´ urovnı ´ idea ´lnı ´ho ty ´mu - takovy ´ ty ´m by pro dany ´ ´ uc ˇel byl velmi drahy ´ nehlede ˇ na to, ˇe by pra z ´ce neposkytovala jeho c ˇlenu ˚m motivaci a uspokojenı ´. Ne ˇkdy ji nelze aplikovat z prakticky ´ch c ˇi logisticky ´ch du ˚vodu ˚ - ne vz ˇdy je moz ˇnost vybrat lidi s poz ˇadovany ´mi vlastnostmi aniz ˇ by bylo potr ˇeba nabı ´rat nove ´ zame ˇstnance; je take ´ moz ˇne ´ z ˇe jsou k dispozici lide ´ s potencia ´lem, ale bez technicky ´ch znalostı ´. Je vz ˇdy leps ˇı ´ se o vyva ´z ˇenı ´ sloz ˇenı ´ ty ´mu pokusit c ˇa ´stec ˇne ˇ nez ˇ vu ˚bec. Pokud pr ˇesto nenı ´ vyhovujı ´cı ´, mohou se c ˇlenove ´ jeho nedostatky snaz ˇit nahradit bde ˇnı ´m nad slaby ´mi aspekty s pouz ˇitı ´m ”nejleps ˇı ´ch ze vs ˇech s ˇpatny ´ch” lidı ´ a postupnou zme ˇnou. * du ˚ lez ˇita ´ role je vedoucı ´ skupiny - obvykle technicke ´ sme ˇr ˇova ´nı ´ a administrace projektu - sledujı ´ pra ´ci ty ´mu, efektivitu * vedoucı ´ obvykle urc ˇeni managementem - proble ´m - urc ˇenı ´ vedoucı ´ nemusejı ´ by ´t vu ˚dci skupiny po technicke ´ stra ´nce - ve skutec ˇnosti si skupina mu ˚z ˇe najı ´t ve sve ´m str ˇedu napr ˇ. technicky nejschopne ˇjs ˇı ´ho, nejleps ˇı ´ho motiva ´tora - ne ˇkdy je proto vy ´hodne ´ odde ˇlit technicke ´ vedenı ´ od administrace projektu Koheze skupiny .............. * kohezivnı ´ skupina = pro c ˇleny jsou jejich individua ´lnı ´ za ´jmy me ´ne ˇ du ˚lez ˇite ´ nez ˇ za ´jmy skupiny
149
21. kveˇtna 2004
150
- tj. c ˇlenove ´ se cı ´tı ´ by ´t c ˇleny skupiny, snaz ˇı ´ se skupinu chra ´nit, poma ´hat si navza ´jem apod. - lze podpor ˇit poskytova ´nı ´m informacı ´ a du ˚ve ˇry skupine ˇ * vy ´hody kohezivnı ´ skupiny: - konsensem mohou vzniknout standardy kvality - c ˇlenove ´ skupiny te ˇsne ˇ spolupracujı ´ - mohou se od sebe navza ´jem uc ˇit apod. - c ˇlenove ´ znajı ´ navza ´jem svojı ´ pra ´ci (vy ´hoda pokud napr ˇ. c ˇlen skupiny onemocnı ´) - programy mohou by ´t cha ´pa ´ny jako skupinove ´ vlastnictvı ´ (egoless programming) - usnadn ˇuje prova ´de ˇnı ´ inspekcı ´, pr ˇijı ´ma ´nı ´ kritiky a vyleps ˇova ´nı ´ programu skupinou * kohezivnı ´ skupiny majı ´ na ´chylnost ke dve ˇma proble ´mu ˚m: - iraciona ´lnı ´ rezistence ke zme ˇne ˇ vedoucı ´ho - pokud je vedoucı ´ nahrazen ne ˇky ´m mimo skupinu, skupina se mu ˚z ˇe sjednotit proti nove ´mu vedoucı ´mu => snı ´z ˇenı ´ produktivity . pokud je to moz ˇne ´ me ˇl by by ´t vedoucı ´ zvolen z c ˇlenu ˚ skupiny - tzv. skupinove ´ mys ˇlenı ´ - kriticke ´ mys ˇlenı ´ je potlac ˇeno ve prospe ˇch loajality vu ˚c ˇi skupine ˇ (resp. skupinovy ´m norma ´m, skupinovy ´m rozhodnutı ´m)
Komunikace uvnitr ˇ skupiny ......................... * dobra ´ komunikace mezi c ˇleny skupiny je podstatna ´ * podstatne ´ faktory: - velikost skupiny - struktura skupiny - sloz ˇenı ´ - fyzicke ´ pracovnı ´ prostr ˇedı ´ * klı ´c ˇovy ´m faktorem je velikost skupiny - poc ˇet moz ˇny ´ch komunikac ˇnı ´ch cest je n * (n-1) - tj. pro sedmic ˇlennou skupinu (42 cest) je pravde ˇpodobne ´ z ˇe ne ˇkter ˇı ´ c ˇlenove ´ spolu budou komunikovat velmi zr ˇı ´dka * dals ˇı ´m faktorem struktura skupiny - v neforma ´lne ˇ strukturovany ´ch skupina ´ch efektivne ˇjs ˇı ´ komunikace nez ˇ ve forma ´lne ˇ (hierarchicky) strukturovany ´ch skupina ´ch - v hierarchicky strukturovany ´ch skupina ´ch majı ´ informace tendenci putovat nahoru a dolu ˚ v hierarchii, ale lide ´ na ne ˇktere ´ ´ urovni spolu nekomunikujı ´ - proble ´m velky ´ch skupin * sloz ˇenı ´ skupiny - pokud se skupina skla ´da ´ z pr ˇı ´lis ˇ mnoha lidı ´ stejne ´ho osobnostnı ´ho typu, nasta ´vajı ´ konflikty a komunikace uva ´zne - komunikace je obvykle leps ˇı ´ ve skupina ´ch kde jsou muz ˇi i z ˇeny nez ˇ ve skupina ´ch sloz ˇeny ´ch pouze z muz ˇ˚ u nebo pouze z z ˇen - z ˇeny jsou c ˇaste ˇji interakc ˇne ˇ orientovane ´ => mohou by ´t prostr ˇednı ´ci * fyzicke ´ pracovnı ´ prostr ˇedı ´ - velmi podstatne ´ pro chova ´nı ´ a vy ´konnost skupiny - podle (DeMarco & Lister 1985) rozdı ´ly ve vy ´konnosti ty ´mu ˚ az ˇ 1:11 - pro vy ´konnost nejdu ˚lez ˇite ˇjs ˇı ´ vlastnosti: . soukromı ´ - potr ˇeba prostoru, kde se mohou soustr ˇedit na pra ´ci bez vyrus ˇova ´nı ´ . pr ˇirozene ´ sve ˇtlo, viditelnost vne ˇjs ˇı ´ho prostr ˇedı ´ (= okna) . moz ˇnost individua ´lnı ´ch ´ uprav prostr ˇedı ´ podle zpu ˚sobu pra ´ce * pro komunikaci je podstatne ´, aby skupina mohla diskutovat projekt forma ´lne ˇ i neforma ´lne ˇ - (Weinberg 1971) cituje pr ˇı ´pad, kdy organizace chte ˇla zabra ´nit programa ´toru ˚m ”ztra ´cet c ˇas” povı ´da ´nı ´m u automatu na kafe; po odstrane ˇnı ´ automatu se okamz ˇite ˇ dramaticky zvy ´s ˇil poc ˇet forma ´lnı ´ch poz ˇadavku ˚ na vy ´pomoc - vyplatı ´ se mı ´t neforma ´lnı ´ mı ´sto pro setka ´va ´nı ´, stejne ˇ jako konferenc ˇnı ´ mı ´stnost pro forma ´lnı ´ sezenı ´
zswi/pDscm.d
zswi/pDscm.d
21. kveˇtna 2004 zasedací místnost kancelář
kancelář kancelář
sdílená dokum.
sdílená shared dokum. doc
kancelář
kancelář
kancelář
kancelář
kancelář
Softwarove ´ profese .................. V ra ´mci ty ´mu ˚ vykona ´vajı ´ ru ˚znı ´ c ˇlenove ´ ru ˚ znou pra ´ci; vs ˇichni jsou stejne ˇ potr ˇebnı ´, ne ˇkter ˇı ´ ale nesou ve ˇts ˇı ´ zodpove ˇdnost. Jako pr ˇı ´klad uvedu rozde ˇlenı ´ na profese podle (Paleta 2003): * zadavatel nebo manager produktu - forma ´lne ˇ nenı ´ souc ˇa ´stı ´ ty ´mu - sestavuje poz ˇadavky na vytva ´r ˇenou aplikaci, zodpovı ´da ´ ota ´zky ty ´mu, pr ˇebı ´ra ´ aplikaci - u syste ´mu ˚ vytva ´r ˇeny ´ch na zaka ´zku je za ´stupcem zadavatele * vedoucı ´ projektu - r ˇı ´dı ´ vlastnı ´ vy ´voj, je zodpove ˇdny ´ za splne ˇnı ´ poz ˇadavku ˚, termı ´nu a rozpoc ˇtu - komunikuje se zadavatelem nebo managerem produktu * technicky ´ leader nebo architekt - ostatnı ´ se na ne ˇj obracejı ´, pokud majı ´ technicky ´ dotaz - navrhuje celkovou strukturu aplikace, vybı ´ra ´ technologie a vy ´vojove ´ prostr ˇedky * databa ´zovy ´ specialista - na ´vrh databa ´ze - pr ˇı ´prava vy ´konnostnı ´ch testu ˚ a na za ´klade ˇ jejich vy ´sledku ˚ optimalizace databa ´ze * analytik - rozpracova ´va ´ specifikaci, vytva ´r ˇı ´ konceptua ´lnı ´ model aplikace - navrhuje posloupnost obrazovek apod. - role mu ˚z ˇe by ´t kombinova ´na s pozicı ´ programa ´tora nebo tvu ˚rce dokumentace * na ´vrha ´r ˇ uz ˇivatelske ´ho rozhranı ´ - navrhuje obrazovky aplikace tak, aby byly pr ˇehledne ´ a snadno pouz ˇitelne ´ * programa ´tor - vytva ´r ˇı ´ ko ´d na za ´klade ˇ specifikace a konceptua ´lnı ´ho modelu * tester - r ˇı ´dı ´ nebo prova ´dı ´ testova ´nı ´ * tvu ˚rce dokumentace - zpracova ´va ´ technickou dokumentaci vytva ´r ˇenou ostatnı ´mi c ˇleny ty ´mu, vytva ´r ˇı ´ uz ˇivatelskou dokumentaci (manua ´ly, na ´pove ˇda) Konfigurac ˇnı ´ management ======================= * v SW projektech se me ˇnı ´ poz ˇadavky na syste ´m, design syste ´mu, ko ´d, dokumentace syste ´mu atd. - v pru ˚be ˇhu c ˇasu ve ˇdı ´ vs ˇichni zu ´c ˇastne ˇnı ´ vı ´ce (o tom co potr ˇebujı ´, jak by se to nejle ´pe ude ˇlalo, atd.) - poz ˇadavky na zme ˇny budou pr ˇicha ´zet ve vs ˇech fa ´zı ´ch tvorby SW - pro r ˇı ´zenı ´ zme ˇn v projektech byly vyvinuty procesy, nazy ´vane ´ souhrnne ˇ konfigurac ˇnı ´ management (angl. software configuration management, SCM) - ´ ukolem SCM definovat procedury pro prova ´de ˇnı ´ zme ˇn, eliminuje ne ˇktere ´ proble ´my vznikajı ´cı ´ zejme ´na pokud je mnoho vy ´voja ´r ˇ˚ u a mnoho verzı ´ SW * pr ˇedstavte si ty ´m vyvı ´jejı ´cı ´ SW - ´ uspe ˇs ˇny ´ SW => tisı ´ce poz ˇadavku ˚ na opravy a vyleps ˇenı ´ - ko ´d ve sdı ´lene ´m adresa ´r ˇi - co kdyz ˇ dva programa ´tor ˇi prova ´de ˇjı ´ zme ˇnu ve
151
21. kveˇtna 2004
152
stejne ´m modulu? - oprava chyby v produkc ˇnı ´ verzi, me ˇla by se promı ´tnout za ´roven ˇ ve vy ´vojove ´ verzi do ktere ´ jsou ale mezitı ´m pr ˇida ´va ´ny dals ˇı ´ vlastnosti - vyleps ˇenı ´ zavleklo chyby - jak se vra ´tit ke stare ´ verzi? - jak zjistit, z c ˇeho se ktera ´ verze skla ´da ´? - obvykle kombinace te ˇchto + dals ˇı ´ch proble ´mu ˚ * pro ´ uspe ˇch projektu podstatna ´ schopnost r ˇı ´dit zme ˇny tak, aby si syste ´m mohl zachovat integritu v c ˇase Tradic ˇnı ´ SCM proces ------------------* v tradic ˇnı ´m procesu vy ´voje SW zaloz ˇene ´m na vodopa ´dove ´m modelu je SW pr ˇeda ´n SCM ty ´mu po dokonc ˇenı ´ vy ´voje a po otestova ´nı ´ jednotlivy ´ch komponent - SCM ty ´m pr ˇebı ´ra ´ odpove ˇdnost za sestavenı ´ ´ uplne ´ho syste ´mu a za vedenı ´ testu ˚ - chyby objevene ´ pr ˇi testu syste ´mu jsou pr ˇeda ´ny zpe ˇt k oprave ˇ vy ´vojove ´mu ty ´mu - tento pr ˇı ´stup ovlivnil tvorbu standardu ˚; napr ˇ. IEEE Std. 828 nevyslovene ˇ pr ˇedpokla ´da ´ vodopa ´dovy ´ model, tj. obtı ´z ˇne ˇ se pr ˇizpu ˚sobujı ´ napr ˇ. inkrementa ´lnı ´mu vy ´voji - proto take ´ SCM patr ˇı ´ k nejhu ˚r ˇe zpracovany ´m te ´matu ˚m v literatur ˇe o SW inz ˇeny ´rstvı ´ - napr ˇed popı ´s ˇu tradic ˇnı ´ SCM proces (tak jak ho popisujı ´ standardy), pak zmı ´nı ´m pr ˇizpu ˚sobenı ´ SCM pro inkrementa ´lnı ´ model SW procesu * tradic ˇnı ´ SCM definuje 4 procedury, ktere ´ musejı ´ by ´t pro SW projekt definova ´ny pokud ma ´ by ´t definova ´n dobry ´ SCM proces - identifikace konfigurace - r ˇı ´zenı ´ konfigurace - vytva ´r ˇenı ´ za ´znamu ˚ o stavu konfigurace - autentizace konfigurace Identifikace konfigurace ........................ * informace, ktere ´ jsou vy ´stupem jednotlivy ´ch fa ´zı ´ SW procesu mu ˚z ˇeme rozde ˇlit do tr ˇı ´ velky ´ch kategoriı ´: (1) programy (jak zdrojove ´ texty tak spustitelne ´), (2) dokumentace programu ˚, (3) data - na poc ˇa ´tku ma ´me specifikaci syste ´mu, z nı ´ vznikne DSP, pozde ˇji design atd. - informace vytvor ˇena ´ v du ˚sledku SW procesu a reprezentujı ´cı ´ urc ˇitou podobu dane ´ho SW syste ´mu se nazy ´va ´ konfigurace SW * konfigurace sesta ´va ´ z tzv. ”konfigurovatelny ´ch poloz ˇek” (configurable item, CI), ktere ´ jsou atomicke ´ z hlediska zme ˇn a oznac ˇova ´nı ´ verzı ´ - CI bude napr ˇ. DSP, ERA model, jeden .java soubor, jedna .dll knihovna, mnoz ˇina testovacı ´ch pr ˇı ´padu ˚ apod. - mezi CI existujı ´ za ´vislosti (kompozice, generova ´nı ´, master-dependent, ...) - kaz ˇda ´ CI je jednoznac ˇne ˇ identifikovatelna ´ (typ CI, identifika ´tor projektu, identifika ´tor zme ˇny nebo verze) * konzistentnı ´ konfigurace = SW konfigurace, jejı ´z ˇ prvky jsou navza ´jem bezrozporne ´ - obsahuje napr ˇ. zdrojove ´ texty, makefiles, konfigurac ˇnı ´ soubory, dokumentace, testu ˚ atd. v pr ˇı ´slus ˇny ´ch verzı ´ch - bezrozporna ´ = napr ˇ. zdrojove ´ soubory lze pr ˇeloz ˇit, knihovny pr ˇilinkovat * baseline = konzistentnı ´ konfigurace tvor ˇı ´cı ´ stabilnı ´ za ´klad pro produkc ˇnı ´ verzi nebo dals ˇı ´ vy ´voj (startovacı ´ bod pro r ˇı ´zenou evoluci) - pr ˇı ´klad: milnı ´k beta verze aplikace stabilnı ´: vytvor ˇena ´, otestovana ´, a schva ´lena ´ managementem - pro baseline pr ˇedpokla ´da ´me na ´sledujı ´cı ´ vlastnosti: . dokumentovana ´ funkc ˇnost, tj. vlastnosti SW pro kaz ˇdou baseline jsou dobr ˇe zna ´me ´ . zna ´ma ´ kvalita: napr ˇ. zna ´me ´ chyby budou dokumentova ´ny, SW pros ˇel testova ´nı ´m pr ˇed tı ´m, nez ˇ je definova ´n jako baseline . baseline je nezme ˇnitelna ´ a znovu vytvor ˇitelna ´: po definici nemu ˚z ˇe by ´t baseline zme ˇne ˇna, vs ˇechny CI tvor ˇı ´cı ´ baseline mu ˚z ˇeme kdykoli znovu vytvor ˇit - zme ˇny prvku ˚ baseline jen podle schva ´lene ´ho postupu - pr ˇi proble ´mech na ´vrat k baseline
zswi/pDscm.d
zswi/pDscm.d
21. kveˇtna 2004
- kaz ˇda ´ nova ´ baseline je pr ˇedchozı ´ baseline + souhrn schva ´leny ´ch zme ˇn CI * proces identifikace konfigurace definuje baseline, z jaky ´ch CI se skla ´da ´ * dals ˇı ´ uz ˇitec ˇne ´ pojmy: - delta = mnoz ˇina zme ˇn CI mezi dve ˇma po sobe ˇ na ´sledujı ´cı ´mi verzemi . v ne ˇktery ´ch syste ´mech jednoznac ˇne ˇ identifikovatelna ´ - repository (u ´loz ˇis ˇte ˇ, databa ´ze projektu) = centra ´lnı ´ mı ´sto, kde jsou uloz ˇeny vs ˇechny CI projektu . r ˇ´ ızeny ´ pr ˇı ´stup (udrz ˇenı ´ konzistence) - workspace (pracovnı ´ prostor) = soukromy ´ datovy ´ prostor, v ne ˇmz ˇ je moz ˇno prova ´de ˇt zme ˇny prvku ˚ konfigurace, aniz ˇ by byla ovlivne ˇna jejich podoba v repository . akce ”zkopı ´rova ´nı ´ CI z repository” a ”uloz ˇenı ´ CI do repository” ˇı R ´zenı ´ konfigurace .................. * proble ´m ve vs ˇech fa ´zı ´ch z ˇivotnı ´ho cyklu: - jak zvla ´dat mnoz ˇstvı ´ poz ˇadavku ˚ na ´ upravy produktu (opravy, vyleps ˇenı ´)? - jak poznat kdy uz ˇ jsou vyr ˇes ˇeny? * nutny ´ striktnı ´ postup akcı ´: klasifikace a vyhodnocenı ´ navrhovany ´ch zme ˇn, jejich schva ´lenı ´ nebo neschva ´lenı ´, koordinace schva ´leny ´ch zme ˇn, implementace zme ˇn na pr ˇ´ ıslus ˇnou baseline, dokumentace a ove ˇr ˇenı ´ * poz ˇadavek obsahuje: na ´zev a verzi produktu / subsyste ´mu, ktere ´ho se ty ´ka ´; popis chyby c ˇi poz ˇadovane ´ zme ˇny (co nejpr ˇesne ˇjs ˇı ´) + indikaci priority; pro chybu: jak vznikla, jak je moz ˇne ´ ji znovu reprodukovat; informace o pouz ˇite ´m software (konfigurace, OS, knihovny) - poz ˇadavek procha ´zı ´ stavy: novy ´ -> pr ˇevzaty ´ -> pr ˇir ˇazeny ´ -> vyr ˇes ˇeny ´/zrus ˇeny ´/duplicitnı ´ -> uzavr ˇeny ´ * postup zpracova ´nı ´ poz ˇadavku - pr ˇijetı ´ poz ˇadavku . pr ˇide ˇlenı ´ ID . nastavenı ´ za ´vaz ˇnosti, priority (kriticka ´ chyba - proble ´m - vada na kra ´se - vyleps ˇenı ´) - v tradic ˇnı ´m procesu schva ´lenı ´, neschva ´lenı ´, odloz ˇenı ´ zme ˇny r ˇı ´dı ´ ”komise pro r ˇı ´zenı ´ konfigurace” (angl. configuration control board, CCB) . chyba -> nutno ove ˇr ˇit z ˇe chyba je rea ´lna ´ - zpracova ´nı ´ poz ˇadavku . pove ˇr ˇeny ´ c ˇlove ˇk (dle zodpove ˇdnosti za c ˇa ´sti syste ´mu) . lokalizace zme ˇn v produktech procesu . oprava v loka ´lnı ´m workspace, testova ´nı ´ a validace . schva ´lenı ´, nova ´ baseline * SW podpora - syste ´my pro spra ´vu zme ˇn (bug tracking systems) - evidence a archivace poz ˇadavku ˚, sledova ´nı ´ stavu poz ˇadavku, pr ˇı ´padne ˇ statistiky - c ˇasto emailove ´, webove ´ - napr ˇ. Gnats + Gnatsweb, Bugzilla, JitterBug apod. Vytva ´r ˇenı ´ za ´znamu ˚ o stavu konfigurace ..................................... * zajis ˇte ˇnı ´ sledovatelnosti zme ˇn SW * zaznamena ´va ´nı ´ informacı ´ o kaz ˇde ´ verzi SW a o zme ˇna ´ch oproti pr ˇedchozı ´ baseline, ktere ´ k te ´to verzi vedly * za ´znam pomu ˚z ˇe zodpove ˇde ˇt ota ´zky jako - ”Byla chyba XYZ opravena?” - ”Kdo je zodpove ˇdny ´ za tuto modifikaci?” ˇı - ”C ´m pr ˇesne ˇ se tato verze lis ˇı ´ od baseline?” * konkre ´tnı ´ na ´stroje uvedeme pozde ˇji Autentizace konfigurace ....................... * proces ktery ´ zajis ˇt’uje
153
21. kveˇtna 2004
154
zswi/pDscm.d
- aby v nove ´ baseline byly zahrnuty vs ˇechny pla ´novane ´ a schva ´lene ´ zme ˇny - aby souc ˇa ´stı ´ dodane ´ho syste ´mu byly vs ˇechny poz ˇadovane ´ programy, dokumentace a data
SCM pro inkrementa ´lnı ´ vy ´voj --------------------------* pr ˇı ´klad procesu: - cely ´ syste ´m se sestavuje c ˇasto (napr ˇ. denne ˇ) - organizace urc ˇı ´ c ˇas, do kdy musı ´ vy ´voja ´r ˇi doruc ˇit sve ´ komponenty (napr ˇ. 14h) - komponenty mohou by ´t neu ´plne ´, ale musejı ´ poskytovat za ´kladnı ´ funkc ˇnost, ktera ´ mu ˚z ˇe by ´t otestova ´na * z komponent se sestavı ´ nova ´ verze syste ´mu - syste ´m je pr ˇeda ´n testovacı ´mu ty ´mu, ktery ´ provede pr ˇeddefinovane ´ testy syste ´mu - vy ´voja ´r ˇi zatı ´m da ´le pracujı ´ na svy ´ch komponenta ´ch, pr ˇida ´vajı ´ funkc ˇnost a opravujı ´ chyby objevene ´ v pr ˇedchozı ´ch testech - testovacı ´ ty ´m zdokumentuje objevene ´ chyby, pr ˇeda ´ je vy ´voja ´r ˇ˚ um - vy ´voja ´r ˇi chybu opravı ´ v dals ˇı ´ verzi komponenty * hlavnı ´ vy ´hodou dennı ´ho sestavova ´nı ´ je brzke ´ nalezenı ´ proble ´mu ˚ vznikly ´ch interakcı ´ komponent * vy ´voja ´r ˇi pocit’ujı ´ tlak aby jejich komponenty nezpu ˚sobily hava ´rii syste ´mu du ˚ sledkem je leps ˇı ´ testova ´nı ´ jednotek * SCM proces musı ´ ne ˇkdo r ˇı ´dit, musı ´ ustanovit podrobne ´ procedury, musı ´ zajistit aby vs ˇechny zme ˇny probe ˇhly spra ´vne ˇ * pr ˇı ´klad velke ´ho projektu - ja ´dro OS Linux: - ve ˇts ˇinu skutec ˇne ´ho vy ´voje jinı ´ vy ´voja ´ˇ ri, ale jake ´ vlastnosti bude obsahovat ja ´dro urc ˇuje jeden c ˇlove ˇk - Linus Torvalds - vs ˇichni vy ´voja ´r ˇi mu posı ´lajı ´ zme ˇny ktere ´ majı ´ by ´t zac ˇlene ˇny do ja ´dra - hraje roli SCM procesu: . r ˇ´ ızenı ´ konfigurace (zac ˇlen ˇova ´nı ´/nezac ˇlen ˇova ´nı ´ zme ˇn ostatnı ´ch vy ´voja ´r ˇ˚ u) . vytva ´r ˇenı ´ za ´znamu ˚ o stavu konfigurace (ChangeLog) . autentizace konfigurace (zaruc ˇuje z ˇe ja ´dro ma ´ vs ˇechny c ˇa ´sti)
Verzova ´nı ´ --------* ´ uc ˇel: udrz ˇenı ´ pr ˇehledu o podoba ´ch CI - verze popisuje stav CI, nebo postup jeho zme ˇn - extenziona ´lnı ´ verzova ´nı ´: kaz ˇda ´ verze ma ´ jednoznac ˇne ´ ID napr ˇ. 1.5.1 = za ´kladnı ´ verze pro DOS, 1.5.2 pro UNIX, 1.6.1 oprava pro DOS, 2.1.1 = novy ´ release pro DOS . pr ˇı ´stup v c ˇasto pouz ˇı ´vany ´ch na ´strojı ´ch (rcs/cvs, SourceSafe) . jednoducha ´ implementace . nepouz ˇitelne ´ pr ˇi ve ˇts ˇı ´m poc ˇtu verzı ´ - intenziona ´lnı ´ verzova ´nı ´: verze je popsa ´na souborem atributu ˚ . napr ˇ. OS=DOS and UmiPostscript=YES . nutne ´ pro ve ˇts ˇı ´ prostory verzı ´ . potr ˇeba vhodny ´ch na ´stroju ˚ (Adele, c ˇa ´stec ˇne ˇ cpp) * prostor verzı ´ je c ˇasto reprezentova ´n grafem - uzly = verze, hrany = vazby mezi verzemi, nejc ˇaste ˇji relace na ´slednictvı ´ - ve ˇtvenı ´ (branch) - c ˇasto nahrazuje varianty (rcs/cvs) - operace vytvor ˇenı ´ ve ˇtve (branch-off, split) a spojenı ´ (merge)
v1 sequence
v1 v2
tree v4 v2
v2 v3
v3
acyclic graph
v1
v5
v3 v4
* na ´stroje pro verzova ´nı ´ - ruc ˇnı ´ verzova ´nı ´ = dohody a konvence o znac ˇenı ´ verzı ´ v na ´zvech (dokument,
zswi/pDscm.d
21. kveˇtna 2004
soubor, adresa ´r ˇ), baseline pomocı ´ za ´lohy vs ˇech souboru ˚ v dane ´m c ˇase - za ´kladnı ´ - spra ´va verzı ´ souboru ˚ . obvykle extenziona ´lnı ´ verzova ´nı ´ modulu ˚ . ukla ´da ´nı ´ vs ˇech verzı ´ v zapouzdr ˇene ´ ´ usporne ´ forme ˇ . pr ˇı ´klady na ´stroju ˚ : rcs, cvs - pokroc ˇile ´ - integrovane ´ do CASE . obvykle kombinace extenziona ´lnı ´ho a intenziona ´lnı ´ho verzova ´nı ´ . automaticka ´ podpora pro ci/co prvku ˚ z repository do na ´stroju ˚ . pr ˇı ´klad na ´stroje: ClearCase, Adele rcs: Revision Control System ............................ * spra ´va verzı ´ pro textove ´ soubory; UNIX, Windows, DOS - extenziona ´lnı ´ stavove ´ verzova ´nı ´ komponent - c ˇa ´sti syste ´mu - utility spous ˇte ˇne ´ z pr ˇı ´kazove ´ho r ˇa ´dku: . ci, co, rcs, rlog, rcsdiff, rcsmerge - ukla ´da ´ (do foo.c,v souboru) . historii vs ˇech zme ˇn v textu souboru . informace o autorovi a c ˇasu zme ˇn . textovy ´ popis zme ˇny zadany ´ uz ˇivatelem . dals ˇı ´ informace (stav prvku, symbolicka ´ jme ´na) - pouz ˇı ´va ´ diff(1) pro ´ usporu mı ´sta . poslednı ´ revize uloz ˇena cela ´ . pr ˇedchozı ´ pomocı ´ delta vygenerovane ´ programem diff(1) - funkce . zamyka ´nı ´ souboru ˚, poskytova ´nı ´ R/O kopiı ´ . symbolicka ´ jme ´na revizı ´, na ´vrat k pr ˇedchozı ´m verzı ´m . moz ˇnost ve ˇtvenı ´ . informace o souboru a verzi lze vc ˇlenit do textu pomocı ´ klı ´c ˇovy ´ch slov $Author$, $Date$, $Revision$, $State$, $Log$ (popis poslednı ´ zme ˇny zadany ´ uz ˇivatelem), $Id$ (kombinace filename revision datum author state) . typicke ´ pouz ˇitı ´ v C: static char rcsid[] = ”$Id$” pr ˇi ”co” expanduje na ”$Id: soubor.c,v 1.1 2003/05/16 03:17:16 luki Exp $” CVS (Concurrent Versioning System) .................................. * nadstavba nad rcs => umı ´ vs ˇe co umı ´ rcs (zejm. klı ´c ˇova ´ slova) * optimisticky ´ pr ˇı ´stup ke kontrole paralelnı ´ho pr ˇı ´stupu - mı ´sto zamkni-modifikuj-odemkni (RCS) pracuje syste ´mem zkopı ´ruj-modifikuj-sluc ˇ * pra ´ce s cely ´mi konfiguracemi (projekty) najednou * sdı ´lene ´ repository + soukrome ´ pracovnı ´ prostory * repository loka ´lnı ´ nebo vzda ´lena ´ (rsh, p-server) * moz ˇnost definovat obsah a strukturu konfigurace * zjis ˇt’ova ´nı ´ stavu prvku ˚, rozdı ´lu ˚ oproti repository * pr ˇı ´kazova ´ r ˇa ´dka, graficke ´ nadstavby (UNIX, Windows, web) * rcs i cvs jsou volne ˇ s ˇı ´r ˇene ´ * mnoz ˇstvı ´ informacı ´ on-line, viz napr ˇ. http://www.loria.fr/˜molli/cvs-index.html * existujı ´ dals ˇı ´ podobne ´ na ´stroje, napr ˇ. PRCS, Subversion apod. cpp: Realizace variant ...................... * cpp = C preprocessor, umoz ˇn ˇuje intenziona ´lnı ´ stavove ´ verzova ´nı ´ - napr ˇ. chceme variantu foo.c pro pr ˇı ´pad OS=DOS and UmiPostscript=YES - definice atributu ˚ pro popis variant - hlavic ˇkovy ´ soubor (centra ´lnı ´ mı ´sto def. varianty cele ´ho syste ´mu) parametry pr ˇı ´kazove ´ r ˇa ´dky gcc -DOS_DOS (napr ˇ. v Makefile)
Automatizace pr ˇekladu a sestavenı ´ projektu: make -----------------------------------------------* program ”make” pocha ´zı ´ ze syste ´mu ˚ UNIX, pu ˚vodne ˇ souvislost s jazykem C * ´ uc ˇelem automatizace pr ˇekladu a sestavenı ´ projektu, minimalizace c ˇasu spotr ˇebovane ´ho vytva ´r ˇenı ´m aktua ´lnı ´ch verzı ´ objektovy ´ch a dals ˇı ´ch ”strojove ˇ vytva ´r ˇeny ´ch” souboru ˚
155
21. kveˇtna 2004
156
zswi/pDscm.d
* spustitelny ´ program a objektove ´ soubory se typicky vytva ´r ˇejı ´ ze zdrojovy ´ch textu ˚ * popis pravidel pr ˇekladu umı ´stı ´me do souboru ”Makefile” (pr ˇı ´padne ˇ ”makefile”) * pr ˇeklad spustı ´me pr ˇı ´kazem ”make” Pr ˇı ´klad (projekt v jazyce C v syste ´mu UNIX) * program p bude sestaven ze dvou objektovy ´ch souboru ˚ a.o a b.o * ty se vytva ´r ˇejı ´ pr ˇekladem z odpovı ´dajı ´cı ´ch zdrojovy ´ch textu ˚ a.c a b.c, oba pouz ˇı ´vajı ´ spolec ˇny ´ hlavic ˇkovy ´ soubor inc.h: * pro pr ˇeklad projektu vytvor ˇı ´me soubor Makefile, obsahujı ´cı ´ tr ˇi pravidla: p: a.o b.o cc -o p a.o b.o a.o: a.c inc.h cc -c a.c b.o: b.c inc.h cc -c b.c * poslednı ´ pravidlo znamena ´: - soubor ”b.o” za ´visı ´ na souborech ”b.c” a ”inc.h” . pokud bude soubor ”b.c” nebo soubor ”inc.h” mlads ˇı ´ nez ˇ ”b.o”, je tr ˇeba ”b.o” znovu vytvor ˇit pomocı ´ pr ˇı ´kazu ”cc -c b.c” . b.c bude mlads ˇı ´ napr ˇ. pokud v ne ˇm provedu zme ˇnu textovy ´m editorem - ostatnı ´ pravidla obdobna ´, tj. pokud dojde ke zme ˇne ˇ, provede se minima ´lnı ´ poc ˇet pr ˇı ´kazu ˚, ktera ´ zajistı ´, aby vy ´sledek byl aktua ´lnı ´
p
p cc -o p a.o b.o
a.o
b.o
a.o
b.o cc -c b.c
a.c
inc.h
b.c
a.c
inc.h
b.c
[] * pravidla majı ´ tvar cı ´l: prerekvizity pr ˇı ´kaz1 pr ˇı ´kaz2 - cı ´l (cı ´lovy ´ soubor, co se ma ´ vytvor ˇit) - volitelne ˇ prerekvizity (soubory, ze ktery ´ch se cı ´l vytva ´r ˇı ´) - volitelne ˇ pr ˇı ´kazy, ktere ´ se spustı ´, pokud je ne ˇktera ´ z prerekvizit mlads ˇı ´ nez ˇ cı ´l (cı ´l je ”zastaraly ´”, me ˇl by se vytvor ˇit z prerekvizit; pro zjis ˇte ˇnı ´ sta ´r ˇı ´ se pouz ˇı ´va ´ c ˇas modifikace souboru) . pozor, v UNIXove ´m ”make” musı ´ by ´t pr ˇı ´kazy uvozeny tabula ´torem * provedenı ´ souboru Makefile - spustı ´me pr ˇı ´kaz ”make” - make najde prvnı ´ pravidlo v souboru Makefile - pr ˇed provedenı ´m pravidla rekurzivne ˇ zajistı ´, aby jeho prerekvizity nebyly zastarale ´ . kaz ˇdou prerekvizitu bude povaz ˇovat za cı ´l, najde pr ˇı ´slus ˇne ´ pravidlo . pokud je cı ´l zastaraly ´, vytvor ˇı ´ ho znovu pomocı ´ pr ˇı ´kazu ˚ pravidla - chyba (nenulova ´ na ´vratova ´ hodnota pr ˇı ´kazu) zpu ˚sobı ´ ukonc ˇenı ´ programu make (lze potlac ˇit uvedenı ´m ”-”, tj. ignoruje pr ˇı ´padnou chybu) * fales ˇne ´ (phony) cı ´le - cı ´l je ve skutec ˇnosti ”na ´ve ˇs ˇtı ´ podprogramu”, nikoli vytva ´r ˇeny ´ soubor - pravidlo nema ´ prerekvizity - pouz ˇı ´va ´ se napr ˇ. pro automatizaci ´ uklidovy ´ch akcı ´, instalaci, provedenı ´ testu ˚, vytva ´r ˇenı ´ distribuc ˇnı ´ch archivu ˚ apod. (phony cı ´le clean, install, test apod.)
zswi/pDscm.d
21. kveˇtna 2004 clean: -rm *.o core
* prome ˇnne ´ (v terminologii programu make nazy ´vane ´ makra) - definice: jme ´no=r ˇete ˇzec - pouz ˇitı ´: $(jme ´no) - pr ˇı ´klad: CC=gcc
# ktery ´m pr ˇekladac ˇem jazyka C budeme pr ˇekla ´dat
p: a.c $(CC) -o p a.c * dals ˇı ´ vlastnosti: vestave ˇna ´ pravidla, inferenc ˇnı ´ pravidla * soubory Makefile najdete ve ve ˇts ˇine ˇ volne ˇ s ˇı ´r ˇeny ´ch programu ˚ (ja ´dro OS Linux apod.) * protoz ˇe ”make” je velmi pouz ˇı ´va ´no, mnoho firem apod. ma ´ vlastnı ´ rozs ˇı ´r ˇenı ´ (podpora paralelnı ´ho be ˇhu, ”include” a ”ifdef” podobne ˇ jako v C, apod.) * gcc -M umı ´ vytvor ˇit za ´vislosti pro objektove ´ soubory, jikes pro .class * existujı ´ dals ˇı ´ na ´stroje se obdobny ´m ´ uc ˇelem, napr ˇ. Ant pro automatizaci pr ˇekladu projektu ˚ v jazyce Java
Eticke ´ a pra ´vnı ´ aspekty tvorby SW ================================= * stejne ˇ jako v jiny ´ch oborech i v SW inz ˇeny ´rstvı ´ existujı ´ urc ˇita ´ eticka ´ pravidla, jejichz ˇ nedodrz ˇova ´nı ´ je povaz ˇova ´no za neslus ˇne ´ a neprofesiona ´lnı ´ * profesiona ´lnı ´ organizace jako ACM a IEEE definovaly ”eticke ´ za ´sady SW inz ˇeny ´ra” (CS Code of Ethics), viz http://www.acm.org/serving/se/code.htm * ne ˇktere ´ za ´kladnı ´ za ´sady: - pr ˇi vytva ´r ˇenı ´ SW ma ´te moz ˇnost by ´t ne ˇkomu prospe ˇs ˇnı ´ nebo mu zpu ˚sobit s ˇkodu (nebo da ´t moz ˇnost jiny ´m aby byli prospe ˇs ˇnı ´ nebo ublı ´z ˇili) . napr ˇı ´klad pokud jste zodpove ˇdnı ´ za vy ´voj syste ´mu kriticke ´ho pro bezpec ˇnost lidı ´ a c ˇas va ´s tlac ˇı ´ - bylo by neeticke ´ prohla ´sit syste ´m za otestovany ´, pokud nenı ´ . pokud je pravde ˇpodobna ´ ´ uc ˇast na vojensky ´ch, nuklea ´rnı ´ch nebo jiny ´ch projektech, na ktere ´ existujı ´ ru ˚zne ´ pohledy z eticke ´ho hlediska, je tr ˇeba to pr ˇedem mezi zame ˇstnavatelem a zame ˇstnancem vyjasnit - du ˚ve ˇrnost - me ˇli byste respektovat du ˚ve ˇrnost informacı ´ o klientech nebo zame ˇstnavateli - zpu ˚ sobilost - me ˇli byste si by ´t ve ˇdomi sve ´ ´ urovne ˇ a nepr ˇijı ´mat ve ˇdome ˇ pra ´ci, ktera ´ je nad vas ˇe schopnosti - dodrz ˇovat autorska ´ pra ´va, patenty apod. - porus ˇova ´nı ´m mu ˚z ˇete uve ´st do potı ´z ˇı ´ nejen sebe - nezneuz ˇı ´vat cizı ´ poc ˇı ´tac ˇe napr ˇ. pro provozova ´nı ´ programu ˚, se ktery ´mi by vlastnı ´k nesouhlasil Autorsky ´ za ´kon .............. * pokud se z ˇivı ´te SW, je z ˇivotne ˇ nutne ´ zna ´t autorsky ´ za ´kon (121/2000 Sb. ”Za ´kon o pra ´vu autorske ´m, o pra ´vech souvisejı ´cı ´ch s pra ´vem autorsky ´m a o zme ˇne ˇ ne ˇktery ´ch za ´konu ˚”) viz http://www.nkp.cz/o_knihovnach/00-121.htm - z § 2 vyply ´va ´, z ˇe poc ˇı ´tac ˇovy ´ program (”je-li pu ˚vodnı ´ v tom smyslu, z ˇe je autorovy ´m vlastnı ´m dus ˇevnı ´m vy ´tvorem”) i jeho jednotlive ´ vy ´vojove ´ fa ´ze a c ˇa ´sti jsou pr ˇedme ˇtem ochrany podle AZ; podle § 65 je chra ´ne ˇn jako dı ´lo litera ´rnı ´ - § 5, § 11 a § 26: autorem je fyzicka ´ osoba, ktera ´ dı ´lo vytvor ˇila, autorstvı ´ nelze pr ˇeve ´st nebo se ho vzda ´t * s AZ souvisı ´ § 152 trestnı ´ho za ´kona: ”Kdo neopra ´vne ˇne ˇ zasa ´hne do za ´konem chra ´ne ˇny ´ch pra ´v k autorske ´mu dı ´lu ... bude potresta ´n odne ˇtı ´m svobody az ˇ na dve ˇ le ´ta nebo pene ˇz ˇity ´m trestem nebo propadnutı ´m ve ˇci.” * licence - § 12 a § 46: autor ma ´ pra ´vo sve ´ dı ´lo uz ˇı ´t a ude ˇlit jine ´ osobe ˇ smlouvou
157
21. kveˇtna 2004
158
zswi/pDscm.d
licenci k jednotlivy ´m zpu ˚sobu ˚m nebo ke vs ˇem zpu ˚sobu ˚m uz ˇitı ´ (uz ˇitı ´ podle AZ = rozmnoz ˇova ´nı ´, rozs ˇir ˇova ´nı ´ atd.; rozmnoz ˇova ´nı ´ je podle § 66 i ”vytvor ˇenı ´ rozmnoz ˇeniny (nezbytne ´) k zavedenı ´ ... programu do pame ˇti poc ˇı ´tac ˇe”) . § 49: licence mu ˚z ˇe by ´t vy ´hradnı ´ nebo nevy ´hradnı ´ (vy ´hradnı ´ = autor nesmı ´ poskytnout licenci tr ˇetı ´ osobe ˇ) . § 49: povinnou na ´lez ˇitostı ´ licence je vy ´s ˇe odme ˇny nebo zpu ˚sob jejı ´ho urc ˇenı ´ ˇeske . § 50: nenı ´-li v licenci r ˇec ˇeno jinak, platı ´ pouze na ´ uzemı ´ C ´ republiky . § 50: nenı ´-li urc ˇeno jinak, platı ´ max. jeden rok (!!!) - § 58: zame ˇstnavatel vykona ´va ´ svy ´m jme ´nem a na svu ˚j ´ uc ˇet autorova majetkova ´ pra ´va k dı ´lu, ktere ´ autor vytvor ˇil ke splne ˇnı ´ svy ´ch povinnostı ´ k zame ˇstnavateli (nenı ´-li sjedna ´no jinak) . nenı ´-li sjedna ´no jinak, zame ˇstnavatel mu ˚z ˇe dı ´lo zver ˇejnit pod svy ´m jme ´nem, upravovat atd. . poc ˇı ´tac ˇove ´ programy se povaz ˇujı ´ za zame ˇstnanecka ´ dı ´la i tehdy, byla-li vytvor ˇena na objedna ´vku * licence platna ´ v pra ´vnı ´m r ˇa ´du jine ´ zeme ˇ nemusı ´ by ´t platnou licencı ´ podle c ˇeske ´ho AZ a naopak (zejme ´na pokud v licenci chybı ´ ne ˇktere ´ ze za ´kona povinne ´ ustanovenı ´) * podle c ˇeske ´ho AZ vznika ´ pra ´vo autorske ´ k dı ´lu v okamz ˇiku, ”kdy je dı ´lo vyja ´dr ˇeno v jake ´koli objektivne ˇ vnı ´matelne ´ podobe ˇ” - naproti tomu v jiny ´ch jurisdikcı ´ch je poz ˇadova ´no uve ´st informaci o copyrightu ve tvaru: Copyright
ˇR: * pr ˇı ´klad licence platne ´ v C Copyright 2004 Za ´padoc ˇeska ´ univerzita v Plzni Za ´padoc ˇeska ´ univerzita v Plzni tı ´mto poskytuje nabyvateli rozmnoz ˇeniny tohoto poc ˇı ´tac ˇove ´ho programu a jeho dokumentace (da ´le jen ”Software”) bezu ´platne ˇ celosve ˇtovou a c ˇasove ˇ neomezenou nevy ´hradnı ´ licenci ke vs ˇem zpu ˚ sobu ˚m uz ˇitı ´ Software vc ˇetne ˇ zejme ´na pra ´va Software rozmnoz ˇovat a rozs ˇir ˇovat, s pra ´vem upravovat Software a me ˇnit jeho na ´zev, spojovat Software s jiny ´mi dı ´ly a zar ˇazovat Software do de ˇl souborny ´ch.
❉
