1) Ve které fázi vývoje začíná a končí DSP (dokument specifikace požadavků). [NENALEZENO] IMHO: silně závisí na daném projektu a použité metodice (iterativní, agilní) plácnul jsem že na začátku a až do hlavní implementace (ještě v návrhu lze) 2) Daily build, continuous build který použít pro projekt o 12 lidech 8 programátorech 120 případech užití, ... a proč. Daily Build and Smoke test -------------------------- - Integrační sestavení + zkouška těsnosti - pravidelně 1x denně (někdy nočně) - výsledky okamžitě známy a reflektovány ==> nová hlášení problémů ==> opravy ihned zapracovány do kódu (Microsoft Windows NT 3.0 consisted of 5.6 million lines of code spread across 40,000 source files. A complete build took as many as 19 hours on several machines, but the NT development team still managed to build every day. – McConnell, 1996) - check-in kódu, který vede k chybám, je neslušné chování ==> lehká (nebo i vážnější) sankce vhodná Výhody: - zvladatelné množství změn během denních check-in - zvladatelné množství oprav, detekce problémů „vždyť včera to fungovalo“, analýza změn kódu místo ladění – viz diskuse o sestavení - pravidelný, obecně známý rytmus projektu - lepší morálka týmu („to nám to roste“) Cena: trocha discipliny, trocha automatizace Continuous Integration ---------------------- - Dotažení do dokonalosti (nebo extrému ;-) - "1x denně" --> "neustále" Klíč: automatizace - co/ci, sestavení, testování, oznamování - robot na spouštění 3) Vzor observer, jeho UML sekvenční diagram. - vzor Observer / Listener - reakce na změny dat v jiných částech aplikace [z těhle pár řádek by jsme podle něj měli bejt schopný udělat UML, to jako LoL, dá se najít na netu příklady pro herní enginy] 4) Největší problém metriky LOC (lines of code) [nebo něco takovýho, další způsoby jsou testy]. [NENALEZENO] 5) Kdo hlásí, udává důležitost, datum do kdy opravit, píše číslo revize kdy bylo opraveno, při reportování chyby. [na každym řádku napsanýho něco takovýho a udat kdo to bude dělat, IMHO: silně závislé na nastolených zvyklostech projektu] 6) Burndown graf + popsat části. Graf postupu prací - "Sprint/release burndown" ^ 100 |----- | ---- Zbývající | --- práce v | --- hodinách | ---- | --- |-------------------------> Datum (iterace, sprint) 0 postupně klesá k nule [existuje několik verzí a variací] 7) Techniky ověření kvality architektury, 2500 zaměstnanců, 19 oddělení, správa dokumentů, vybrat některé + proč, popsat? [NENALEZENO] 8) Projekt má hotové 2/3 částí, co bude ještě potřeba udělat v systému revizí pro vydání release? [NENALEZENO](spojit větve s trunk, build testy atd., poté kopie do tag) 9) Co je to backlog. Backlog ------- - features, úkoly, chyby,... ==> release backlog: 1-3 dny práce ==> sprint backlog: 4-16 hod - tým identifikuje položky - zákazník stanovuje priority 10) Vlastnosti dobrých tříd + popis + příklad? Základní vlastnosti dobrých tříd -------------------------------- - Správce informací (information expert) - zodpovědnosti přiřazeny třídám, které mají potřebná data - "Kdo to zařídí" --> "Kdo k tomu má podklady" - Vysoká soudržnost - zodpovědnosti třídy "jsou si podobné", "spolu souvisí" - třída je informačním expertem - lze najít krátké výstižné jméno pro celou třídu - Malá provázanost - třída má málo vazeb na jiné (asociace, závislost) - deleguje na informační experty - nemusí platit pro knihovní třídy 11) Techniky prevence a detekce chyb, jejich ppst úspěchu. Účinnost detekce chyb avg max --------------------- --- --- - modelování, prototypování 65% 80% - formální oponentury návrhu 55% 75% - neformální procházení 40% 60% - čtení kódu 40% 60% - integrační testování 45% 60% - testování modulů 25% 50% 12) UML diagram aktivit, od začátku vyhledávání až do odevzdání zadání BP na sekretariát KIV. [něco jako stavový diagram, plná tečka = začátek, tečka v kolečku = konec] 13) Programování do rozhraní popsat + UML. [v bublině napsáno: naučte se programovat do rozhraní][takže asi ty bubliny v přednáškách myslí vážně ;) ]