====== Poznámky z předmětu A4M33SEP ====== * vhodný doplněk ke slidům ===== Requirements Engineering ===== schématický pohled * vyjednávání - schůzky, jedání, poznávání uživatelů atd, tohle analytik dělá na těch schůzkách * analýza - máme podněty ze schůzek a jednání, máme poznámky, návrhy, diagramy a ty dle zpracováváme a třídíme. všechno je to v hlavně či na neformálních papírech * specifikace - formální zápis požadavků, uvedení do formy, dekomponování, popis, notace * verifikace - primální odběratel čte text, my s ním schůzujeme a on potvrzuje a vyjadřuje se k tomu, co jsme sestavili. Předkládáme mu požadavky, návrhy, klidně i část gui zkrátka cokoliv co nutí uživatele k zamyšlení, zda-li je to opravdu to, co chce * výsledkem je že se pozná, ověří a zapíše to, co uživatel opravdu chce a potřebuje u požadavků je obvykle šedá zóna, neboť každá strana považuje určité věci za jinak důležité, takže někdo to neočekává a druhý ano a pak dochází k nedorozumění atd každý analytik by si měl položit několik zásadních otázek a byl schopen na ně odpovědět * co má být výsledek analýzy? dokument doprovázený obrázky * obsah? posbírané všechny typy požadavků, nic nezanedbávat * forma? strukturovaný text, uml diagramy jsou horší na pochopení, pokud jich je moc bez vysvětlení * logická a fyzická dekompozice? nové systémy je obvykle výhodné dekomponovat podle features, strukturovat atd.obvykle lze dále dekomponovat * míra detailu? tak akorát, aby tam bylo vše ale zároveň to netrvalo zbytečně dlouho a nebylo to tudíž zbytečné a drahé * pracnost? obvykle 15-30%, většinou tak 20-25% trvá analýza * kalendářní čas - problém se součinností zákazníka, není to jen o tom sednou a sepsat to, ale je nutné zařídit správnou schůzky, aby odpovídal a tak. Docela slušná finta je stanovení nějaké reakční doby a pokud dojde k jejímu překročení, tak pak se prodlužuje doba projektu například o měsíc. Je potřeba i průběžně měřit efektivitu projektu, aby bylo možné ověřit, zda-li se projekt stíhá či nikoliv., takže je nezbytná nějaká metrika atd. * počet lidí? tak aby bylo možné je uřídit, aby měli co dělat a tak * obvykle lze navrhovat architekturu atd. co nejdříve, protože je potřeba uvažovat i o termínu dodání, realizaci atd., protože nesmí nastat situace, že dané požadavky jsou nerealizovatelné, příliš drahé atd., tudíž od začátku je nezbytné to sledovat i z hlediska realizovatelnosti * implementace je možná až po sestavení určitých požadavků a otestování návrhu * architektura odpovídá na nefunkční požadavky jako je výkon, stabilita a může odpovídat i na požadavky rozhraní jako komunikace s dalšími systémy atd. Obvykle tak z ní otázka "Lze splnit nefunkční požadavky?" * jako prevence proti změně požadavků je proaktivní přístup - sám navrhovat změny a tak. * fenomén gold-plating - pořád se analyzuje znovu a znovu a nikdy se nezačne programovat ===== Architektura a design ===== softwarový proces - důležité * věci v oranžovém kolečku - vnitřní - primární činnosti procesu, silně doporučené dělat * v modrém - vnější - sekundární, podpůrné LCO - life cycle objectives - co to má dělat, co se od toho očekává LCA - life cycle activities - trochu podrobněji rozmyšlené co to má dělat atd, tisky, uživatelské stránky, exporty atd. IOC - initial operation capability - tvorba vlastního produktu, dodání zákazníkovi, například beta provoz, odladění user-friendly etc.první build který se dodává zákazníkovi, má to ořezanou funkcionalitu, kterou již zákazník může používat ke svému businessu SWEBOK * software engineering body of knowledge * jsou tam dobré věci jako checklisty které je potřeba udělat - vždy se vyplatí to projít pro kontrolu architektura * to důležité, věci které je potřeba rozhodnout na začátku projektu nebo v hodně brzkých fázích * hraje zásadní roli u systému, pozdější změna je docela problematická * tato rozhodnutí obvykle ovlivní životaschopnost projektu v dalších částech vývojového cyklu * realizuje spíše nefunkční požadavky design * detailnější ladění toho co jednotlivé komponenty v těch svých vrstvách vlastně dělají * realizuje už mnohdy funkční požadavky, aplikuje návrhové vzory atd. (toto rozdělení ale není 100%, existují výjimky v obou směrech) * základní koncepty * dekompozice - rozložení velkého problému na menší * abstrakce - zobecnění - znovupoužitelnost, snazší vnímání celku * zapouzdření - každý objekt se stará pouze o své věci a neleze jinam * koheze - soudržnost kódu, aby věci co spolu souvisí byly u sebe a ne všude možně po aplikaci * coupling - provázanost komponent, lepší menší architektura vs. design * nelze jasně definovat, lidé se obvykle neshodnout, architekt má přehled a rozhoduje o hlavních a velkých věcech, menší úkoly deleguje na jednotlivé komponenty. abstraktní datový typ * univerzálnost * šablona určitého typu, má to strukturu atd OOP * type - zobecnění něčeho * class - šablona pro tvrbu objektů, instance typu * object - instance třídy * modul - větší celek, skupina tříd plnící určitou funkčnost, zapouzdřený, uzavřený, testovatelný pravidla dobrého OOP * programovat proti interface - ne tak závazný kontrakt * upřednostňovat skládání před dědičností - silná vazba * DRY, shy - Dont Repeat Yourself tvorba architektury * zákazník - zda to jde, kdy to bude, co to bude stát, jaká jsou rizika, je to realizovatelné atd * uživatel - bude to dělat to co chce, nové požadavky bude možné za rozumné peníze dodat, bude to dělat ty scénáře co to má a tak * systémový inženýr - potřebuje tam dostat ty potřebné nefunkční požadavky, podpora pro analýzy dalších věcí, zajišťuje úplnost a konzistenci architektury v celém systému * vývojář - kontroluje, že architektura poskytuje dostatečný detail pro design, zajišťuje kontrolu podpory komunikace s dalšími is, udržitelnost kódu atd * údržbář - jak se to bude muset udržovat, co to bude za práci, jak to kooperuje se stávajícími systémy, ... architektura 4+1 * pohled na procesy (jaké jsou tam procesy, jak se spolu baví, jaká je škálovatelnost atd, je to vnitřní pohled) * HW, síťová topologie atd * logický - rozdělení na komponenty atd * pohled vývojáře * scénáře - funkční požadavky atd. podle IEEE existuje jiné rozlišení co je potřeba dokumentovat, ale lze to docela dobře mapovat proti 4+1 vliv kontextu na architekturu * databáze * klient x server * webové technologie * tlustý klient atd. OO systémy * výhody * znovupoužitelnost * udržitelnost kódu * přenositelnost * přizpůsobivost * rozšiřitelnost * techniky * zapouzdření * abstrakce * rozhraní a sdílení kódu * polymorfismus - vlastnost objektů různých typů poskytovat stejnou funkčnost na určité úrovni abstrakce, poskytuje to stejné rozhraní (API) * sdílení návrhu OO frameworky * frozen spots - věci a techniky, které frameworky diktují a nedovolí to nijak obejít * hot spots - prostor kam dodat vlastní kód abychom dosáhli kýžené funkcionality ===== Konstrukce ===== * z části v LCA a IOC * mohutně zde probíhá vývoj * obvykle nelze začít, dokud není zpracována analýza, návrh a design. občas lze dělat nějaké drobné části, např. komunikační moduly, security, ale je to pouze zřídka * IDE pomáhá, statická analýza kódu, framework vs. knihovna * framework určuje i design a architekturu * zatímco knihovna nic nevynucuje, např. logování je docela na hraně je potřeba znát cenu projektu - abych nebastlil a neměl nízkou kvalitu ani neměl zlatý kód, což se nedá zaplatit je potřeba dodržovat firemní pravidla, standardy a dobré mravy ctít architekturu psát testy znát základní sw pravidla - vlákna, deadlock atd. DDD (Domain Driven Development) * přístup který vychází z domény, ve které se orientuji a kolem toho stavím techniku. Bavíme se o businessu a ten reprezentuji v prog. jazyku a db * domain specific language DSL * pro určitou doménu specifické konstrukce * orientují se v tom i neprogramátoři, kteří se vyznají v tom businessu * lze pomocí toho dělat i úpravy v aplikaci bez nutnosti rekompilace atd. * potřeba aby odborníci byli na obou stranách aplikace * je potřeba vlastní parser, gramatika atd. MDD (Model Driven Development * věc namodeluji a již to umí generovat kód * triviální příklad specifikace WSDL, ze které lze generovat server i klient TDD - ruku v ruce implementuji a testuji Refactoring - úprava kódu za účelem zapouzdření, cohesion, coupling, .. Self-documenting code * kód by měl být jasný a srozumitelný * okomentovaný * plně nenahrazuje dokumentaci, architektura, design atd by měly být v dokumentu atd. * tzn například vhodně pojmenované metody, třídy, proměnné * krátké metody a třídy Literate programming - programování v jazyku hodně podobném srozumitelné řeči Technický dluh * kříž * prozíravý, bezhlavý * úmyslný neúmyslný * ve chvíli kdy dělám dluh, měl bych si toho být nějak vědom a poznamenat si to, abych to někdy doopravil * potom například změnové řízení může být o dost dražší atd., když je to zprasené ===== QA a Testování ===== Testování * součást QA * testování nezajišťuje kvalitu, ale měří kvalitu * testování je o * hledání defektů (ve specifikaci, kódu, běžícím programu, ...) * ujasňuje zadání - musím vědět co to má dělat, abych to mohl otestovat, tzn. odhalí se například neúplná specifikace * prevence se do vývoje zavádí kvůli zlevnění detekce * testovací plán * kdo co a jak * testovací případy (TC) * záměr testování, popis funkcionality kterou chceme testovat * testovací skript * implementace TC, konkrétní kroky * Testovací data * vstupní data pro testovací případ * Test Oracle * mechanismus, který ví, jak měl daný test dopadnout * pokud test nejde automatizovat, tak je to obvykle kvůli nemožnosti automatizace orákula - obcházíme to ručním testováním a zaznamenáním výsledků * v automatickém testu je to Assert, verify, ... * test report * zpráva o výsledku testu Základní pravdy * kompletní tsetování není možné * nikdy není možné otestovat vše, je potřeba stanovit rozumnou míru dle cílového produktu * práce testerů je kreativní a náročná * špatné je vzít lidi z ulice a nechat je to otestovat, protože neodhalí skoro nic * potřeba je aby lidé byli inteligentní, motivovaní a kreativní * testování je řízeno riziky * hodně práce / málo času - v takové chvíli je potřeba otestovat jen to nejzásadnější, to u čeho je největší riziko a selhání by moc vadilo * analýza plánování a návrh jsou důležité * je potřeba to plánovat a navrhovat, jinak to bude chaotické a nesystematické, mohou dojít peníze, otestuje se jen malá část atd. prostě v tom bude bordel * motivace je důležitá * čas a zdroje jsou důležité * je potřeba včas zastavit testování, protože v určitou dobu to přestane být výhodné, jeikož je to drahé a najde se už jen málo * časování přípravy testů hraje velkou roli * ukončení testování musí být podloženo testy a ne pocity, aby to bylo zdokumentované a argumentovatelné * měření slouží i pro řízení testů * měření a sledování pokrytí je důležité * při testování je potřeba najít takové scénáře, které mají co nejlepší poměr cena / výkon, pak to otestuje hodně věcí za málo času Typologie testů * 1D - co testujeme * unit, integrační, systémové, akceptační (uživatelské, operační) * 2D jaký aspekt testujeme * funkční, výkonové, bezpečností, testy dostupnosti, spolehlivosti * testujeme metody, systém, třídu * 3D za jakým cílem testujeme * regresní (ověřují starou funkcionalitu), kvalifikační ( minimalistická sada testů, ověřuji základní věci například v poslední den před releasem atd) * akceptační testy patří zrovna tak do 3. dimenze, protože je to speciální cíl testů - testování obvykle 15-20% Man-Day z celkového projektu - patří sem V-Model * když píšu požadavky, tak vlastně zároveň definuji akceptační testování * když navrhuji design, tak vlastně definuji integrační a systémové testy, které pak budou testovat požadované vlastnosti atd. * s tím pracuje TDD kontinuální integrace * každý den se builduje, reportuje, testuje * na straně ývojáře je jen základní testovací sada, která dovoluje udělat commit. velké testy jsou na severu a běží pomalu * testovací platforma se spouští třeba jen jednou za čas, tak to není tak často a tam běží vokonové, nefunkční, manuální testy atd. * testovací platforma musí odpovídat té cílové, být spolehlivá a kvlaitní, aby ty testy k něčemu byly Equivalence analysis * máme sadu testovacích scénářů, ale spustit všechny trvá dlouho. tak vezmu ty ekvivalentní a z nich vyberu nějakého reprezentanta, který má největší šanci odhalit defekt. Obvykle se mnohdy využívají i singulární případy (využívá se teorie množin) Black x White box * black box jsou lépe udržovatelné když se implementace mění, opravdu testují jen to jak se to má chovat * white box testuje přesně průchod kódem, který testuje každý while, if atd, ale jsou křehké na změnu kódu, protože pak už vlastně nejsou aktuální - je drahé je udržovat Testovací technika * technika je recept jak se postavit k návrhu testovacích případů, aby byla co nejvyšší šance odhalit chybu, která stojí za report * záleží na cíli * najít co nejvíce chyb * minimalizovat náklady na hot-line * otestovat co největší část systému aby bylo zřejmé, jestli je v pohodě nebo je to šmejd * cokoliv dalšího si vymyslím * techniky * scénářové * navrhujte dle klasického chování uživatele v systému od login po logout * používám jen ty nejběžnější * funkcionální * bere se funkce za funkcí a v izolaci se otestují * ignorují se závislosti, chování uživatele * doménové * používá se v okamžiku, kdy chceme otestovat velké množství formulářů s velkým množstvím dat * například když počítáme pojistné pro klienta - tam se zohledňuje zdraví, věk, atd, .... asi tak 150k atributů - je to naše doména * každý atribut má téměř nekončený počet možností, tzn moc moc různých dat * tzn je potřeba tu množinu tak nějak zmenšit - hledají se nejlepší kombinace volby dat, aby byly co nejprůkaznější a našlo to toho conejvíc - hodně se používá s whitebox testing napřklad * risk based * snažím se předcházet rizikům pomocí testů, abych ta rizika snížil * vychází se ze zkušenosti své, konkurence, obecných znalostí, atd. tzn. risk management * specification based * vezmu specifikaci a ověřím každou větu, co se dá ověřit * stress * zátěžové testování, spustí se na super stroji aplikace a hrozně moc se zatíží. je potřeba sledovat, proč to spadlo - došla paměť, nestačilo CPU atd. aby se dalo takovému pádu předejít či říci, že tohle nehrozí či je potřeba to opravit. * user - uživatelské * posadím reálného uživatele před reálný systém a on to ověří. není tam nikdo, kdo předstírá že je uživatel, ale je to skutečný uživatel * high volume automated * automatizace testů v plném rozsahu * stroj vymýšlí TC, provádí TC, vyhodnocuje TC atd. * to lze obvykle jen v případech, kdy je systém popsán např. matematickým modelem * výhoda je skutečně důkladné testování, problém je že to lze zřídkakdy použít * exploratory * průzkumné testování * expert na danou doménu se zkušenostmi z podobných systémů se pokusí simulovat chování reálného uživatele a uplatňuje u toho všechny své znalosti a zkušenosti * najde chyby které jsou běžné a běžné techniky by je nenapadly, protože se obvykle nepřemýšlí tak jak se chová uživatel * regression * ověřuje funkčnost již staré funkcionality, tyto testy zajišťují, že již nalezené chyby se v systému znovu neobjeví Quality Assurance * aby se dodaný sw choval tak jak má a zákazník byl happy * nemělo cenu si dělat poznámky, všechno staré, známé, omleté + ve slidech. Testování ruční * před releasem se seznam TC překlopí jako issues a přiřadí se lidem. * tak se ví co je potřeba udělat, pokud TC projde tak close, pokud fail tak nahlásit chybu * výhoda je že je to pak vše na jednom místě QA - zajištění kvality validace - ověření, zda-li to má dělat to co má smysl a co je užitečné, ideálně validuje zákazník, zkrátka aby to nedělalo zbytečnosti a nesmysly verifikace -ověření, zda-li sw dělá to co má dělat akceptační testování * ověření toho, že to dělá to co bylo dohodnuto - a když to sedí, tak to zákazník musí vzít * akceptační testování dělá zákazník, který si ověřuje že přebírá to co chtěl kvalifikační testování * provádí dodavatel, aby nedodal šunt, provádí dříve než pošle k akceptaci, aby si nezkazil jméno * kvalifikační testování - testování před tím, než to předám zákazníkovi, ověřuji si že mu předávám to co chtěl TestCase - návod jak otestovat, elementární jednotka, má předpoklady, postup a post-conditions, měl by pokrývat právě jeden případ, ne víc TestScenario - množina TestCase, sdružuje jednotlivé úkoly z praktických důvodů, abychom se neustále nepřihlašovali atd. smoke testing - celkové otestování je moc pomalé,tak uděláme jen částečné testování toho nejzákladnějšího, je to rychlé výkonnostní - testujeme, zda-li je to dostatečně rychlé a dává to požadovanou odezvu zátěžové - zkusíme předimenzovat zátěž a zjišťujeme, co se stane, když je zahlcena aplikace - zda-li lehne, zotaví se atd. lokalizační testování - testování překladů - zda-li je kvalita překladu úplná a bezchybná, protože jinak je to problém fuzzy testing - testování náhodou, bez jakýchkoliv předpokladů a znalostí automatické vs. manuální testování * drahé klikání, ale i drahá změna skriptu * ideálně automatizovat jen stálé funkce (třeba 8x se už testovala stejně manuálně) * dobré regresními testy pokrýt chyby, které se již objevily * při vývoji dobré psát unit testy * netestovat na produkci protože je to moc rizikové * ideální testovat v testovacím prostředí * testovací prostředí by mělo být co nejbližší produkci - ani ne co se týče výkonu jako co se týče struktury * oddělovat vývojové a testovací prostředí, protože pak nešikovně interagují vývojáři a testeři * u menších projektů neoddělovat vývojáře a testery, je tam velká režie a špatná komunikace. při spojení se lépe šíří znalosti, lépe se alokují lidé a tak. Unit testy * testy co nejmenší, aby jejich pád jasně říkal, co je špatně * pro úspěch alespoň 2 testy, aby ten jeden nebyla náhoda * testovat mezní hodnoty * psát hezky i testy, protože jinak je pak peklo je spravovat * test by měl mít assert * při testování lze sledovat i logy, například pro ověření role, pod kterou jsem právě přihlášen automatické testování * velké a pomalé testy nikdo nespouští * když to trvá dlouho nebo je spuštění složité tak to taky nikdo nespouští * vyšší granularita testů je dobrá, protože se pak ví, co spadlo * špagetykód je mizerný, protože se v tom pak cokoliv těžko hledá * psát testy podle plánu, protože když se píší jak se zrovna chce, tak pak není jasné co je otestované, co ne a tak * neodkládat úpravu testů, protože se odloží na nikdy testovací plán * testovací data * alokace lidí * co se bude testovat () * jak se bude testovat (manuálně, automaticky, regresně, unit, validační atd..) * negativní vymezení (co se netestuje) * pass / fail criteria - jaké testy a co musí projít, aby se aplikace považovala za funkční * požadavky na sw, hw, definice prostředí * jak se bude měnit plán ===== Konfigurační řízení ===== * jediná pravda, možnost rychlého hot-fix, možnost vrátit se k verzi vč. testů, issue tracking (např napojit na mejly, k zákazníkovi atd.) , ... * řízení verzí projektu * svn * jak dělat balíčky * hlavní účel je abychom měli k dispozici všechny stabilní stavy projektu, dodávky a mohli jsme v nich pracovat bez větší námahy. opravit tam například chybu * tzn například malé změnové řízení z aktuální verze, kterou má uživatel, je bez verzování docela problém * hromada změnových řízení je taky špatně, je potřeba je spravovat a řídit - bug tracking system * na konfigurační řízení padne z celkoové náročnosti projektu 5%, jednotky MD - napsat skripty, napsat strukturu, práce s issue trackingem, commity, ... * musíme řídit * produkt, který dodáváme - sw, databáze, cokoliv. musíme řídit všechny jednotky zvlášťs * dokumentaci * evidence - víme co všechno je v tom produktu, takže se nám nic neztratí, vím e co tam patří * identifikace částí i celku, každému přiřazujeme určitou verzi * přehled stavu - zjistit kde je jaká položka v jaké verzi co se od té doby změnilo a tak. aby při detekci chyby bylo snazší zjistit proč vznikla a co ovlivnila * obvykle to spadá do plánu projektového manažera (viz SWEBOOK) * chceme v tom mít pořádek * kontrola verzí * textové soubory, dokumentace, zdrojáky, konfiguráky, DDL na databázi, definice procedur do DB, data, knihovny * s každým nakládáme trochu nějak jinak - něco SVN, něco sdílený disk atd * například potřebujeme provázat data a verzi DB, knihovny, ... * výhodné je používání Tagů a branchí než si zbytečně pamatovat čísla revizí * správa nastavení jednotlivých prostředí, verzování všeho nastavení a tak. * CM != konfigurace systému * verzovat zdrojáky, knihovny, dokumenty, celé dodávky, databázové dumpy ... * verzovací systém musí být zálohován * knihovny je relativní dávat do SVN, neboť je projekty sdílejí a je zbytečné je neustále kopírovat. lepší je sdílet nějak bokem, ... * k open source knihovnám je lepší zálohovat i zdrojáky, .. Issue tracking * používat pro evidenci chyb, životní cyklus chybu atd. * propojovat issue tracking s fixy v svn, aby se dalo monitorovat * hodně logovat, protože pak hlášení nejsou úplná a kvalitní, navíc zákazník neví, co se v aplikaci dělo řízení změn * hranu mezi placenou a neplacenou změnu určuje specifikace * potřeba trackovat změnu kódu proti změně řízení * vypracuje se detailní rozpis úkonů + cena a dá se to předložit zákazníkovi. obvykle je to práce na dny * až po schválení se začne pracovat * je to důležité, aby se zákazník seznámil s cenou a riziky * největší potíž změnových řízení je je uřídit, protože se musí evidovat, plánovat do releasu, schvalovat atd. obvykle ta režie kolem změny je tak 100x větší než náročnost na implementaci * tzn není efektivní pracovat na změnách sériově. je lepší jich testovat víc současně atd. * postup - zákazník něco chce změnit - udělám analýzu, odhady, dopad - zákazník to musí schválit - naplánuji změnu do releasu, optimalizace s testováním atd. přibalím do pravidelné revize (ať menší či větší) (jen critical dodávám hned) * důležitá je vazba v code base pro dané změnové řízení (např záznam do commit logu) * definice procesů a praktik, odpovědnosti, autority, .... * potřeba změnového řízení je zejména ve fázi údržby, ... ===== Údržba ===== * adaptace * zákazníkovi se změní prostředí, změní se produkt na kterém to závisí atd. a je potřeba ten náš produkt přizpůsobit novým podmínkám. * preventivní * například chyby co jsme našli my ale ještě ne zákazník tak na nich pracujeme než se stanou skutečným problémem (Trac, Jira, ...) * změnové řízení pomocí waterfallu, protože se jedná o malou práce a iterativní přístup by přinesl zbytečně velký overhead (rozsah ZZ 1-100 MD) * není problém sednout a vše rovnou do detailu rozmyslet, protože se jedná o malou práci * další velká výhoda je, že znám ten systém, neboť jsem jej dělal a tak umím udělat dobrý odhad kolik je to práce, kam se musí zasáhnout a co se pokazí * změny se dělají ve větších blocích a pak se udělá release, nedělá se po každém kousku znovu * v rámci plánování celého projektu je velký prostor pro přelévání zdrojů, když se spleteme v určitém odhadu. Při množství 10k MD pak není problém někde ubrat a jinde přidat. * rozdíl oproti změnovému řízení je rozsah, protože při 1-100 MD pak už není moc manévrovací prostor pro přenášení zdrojů. proto je důležité dělat mnohem mnohem přesnější odhady. * měření je důležité, abychom byli v budoucnu schopni poučit se z minulosti, abychom byli s to udělat přesnýý odhad založený na předchozí zkušenosti * změnové řízení per issue - lze je pak porovnávat, lépe plánovat, dohledat, ... * zápis práce od výkazu je vhodné doplnit i o činnost kterou jsem tu dobu dělal (analýza, testování, imple, dokumentace, ...) abych pak mě možnost zpětného sledování, která fáze projektu mě kolik stála Smlouva o údržbě, servisní smlouva * obvykle se stanovuje už se začátkem projektu * definuje 24x7, 16x5, 8x5 ... je stanovena doba, kdy se opravdu dovolám abych nahlásil chybu atd * stanovuje se reakční doba na opravu chyby * někdy se předplácí XX MD na opravy. např 100. Potom nahlásí chybu, vyčíslím práci a odečtu z předplaceného * dále lze stanovit například počet dodávek ročně zdarma - zaplatí se změnové řízení, ale ne vlastní dodávka * lze podepsat podporu na určitou dobu - půl roku, rok, 5, 10, ... Dokumentace * nutné udržovat aspoň základ - specifikace, architektura atd. aby i nový člověk co systém nezná byl s to se v rozumném čase zorientovat * patří sem například i návod co nainstalovat, kde postahovat knihovny, jaké verze, jaké IDE, kde je SVN, jaký je login, kde jsou servery na DB a Hudson atd. * určitě je potřeba * udržovat design systému * management - plán releasů a dodávek, co je kdy plánované atd * procesy - hesla, vývojová prostředí, FAQ, konfigurační řízení, ... * změnové řízení - popis co to znamená, kolik to stojí atd - specifikace ===== Software project management ===== * týká se projektů o velikosti 5-20 lidí, vývoj projektů na zakázku * u procesů je nutná jejich dokumentace + definovat kdo za to zodpovídá * zastřešuje všechny oblasti SI * probíhá po celou dobu projektu * swebok opět nabízí checklist, tzn seznam věcí, na které by se nemělo zapomenout * projektový plán * plánování vývoje * odhad pracnosti ( jednak se to oproti specifikaci trochu mění, a navíc tady je to s jinou granularitou - menší. podle toho se pak už dá zase lépe plánovat dál) * dodávky - kdy co jak * práce, plánování, kolik zbývá, ... - odhad vývoje projektu abych věděl jestli stíhám nebo mám skluz * alokace zdrojů - lidi + role, železo * plánování a řízení rizik * řízení kvality * řízení harmonogramu - vytvoření + aktalizace, měl by to mít někdo na zodpovědnost * realizace * implementace plánu * contract s odběratelem * implementace procesu měření, abych měl data pro budoucnost, abych mohl hodnotit současný projekt, výkaz práce, abych věděl jaká aktivita mě co stojí * monitorování procesů - abych věděl co je jak náročné * řídící proces - například sem spadá způsob zadávání práce, * reporting - pokud je vše šikovně nastavené, tak už to je jako výstup ostatních procesů, jinak se na to musím zaměřit * review a vyhodnocení * kontrola projektu, že běží tak jak má. případně nám to dává data, abychom běh projektu upravili k lepším výsledkům * rozhodnutí o naplnění požadavků * vyhodnocení výkonu procesů * konec projektu * ukončení projektu, přechod do fáze údržby * stanovit kdy projekt končí * procesy které se provádí při ukončení projektu - výstupní dokumenty jako historie projektu, předávací protokol * měření projektu - viz přednáška 12 best practices - viz slide vazby PM * na požadavky - musí je realizovat, nesmí jich být moc ani málo * na architekturu - podobně jako požadavky * vazba na konfigurační řízení - má vliv na to, jak se to dodává, jak se dodávají například celé sety * proces SI * kvalita software * čím víc toho PM ví, tím lépe to pak dokáže řídit. POkud to zná jenom na papíře, tak pak ta efektivita není taková a je to zejména na těch lidech, kterým práci deleguje. Sám už nedokáže nic moc zachránit, jelikož tomu vlastně nerozumí základní metoda * ustavení organizace projektu - definuje základní nastavení projektu, kdo co kdy kde proč a jak bude dělat, dokument slouží pouze interně, hlavně pro PM a zamstnance. definuje zejména - plánování zdrojů, organizační strukturu, tetování, plán konfiguračního řízení, dokumentace, instalace * zjistění a porozumění tomu, co se má dělat - sběr požadavků, co a jak budeme dělat * postupné rozložení práce na jednotlivé jednotky * umožňuje lepší odhad * lepší plánování zdrojů * lepší určení závislostí * snadnější sestavení harmonogramu, protože znám závislosti * přiřazení zdrojů * plánování pomocí nějakého rozpisu aktivit + termínů * zobrazovat textově i Ganttem, každé je dobré na něco - Gantt na závislosti * měření a monitorování postupu na projektu * řešení pomocí dekompozice např v excelu. abych měl odhad co jak trvá jak jsem daleko a kolik zbývá * přijímání nápravných opatření - co se povedlo co se nepovedlo atd * historie projektu - co se dělalo a proč, nemusí se psát jen na konci, může se psát třeba průběžně a ještě k tomu z několika různých pohledů (dáno rolí) Organizace práce v týmu * jak přidělovat - například na schůzce projektové, mejlem, * vědět co kdo dělá - chce to mít zápis, ať v dokumentu nebo třeba v nějakém bug tracking systému * jak plánovat vůči lidem * odhadnuté + reálně spotebované MDs - udržovat přehled * role - pm, team leader + definování odpovědnosti řízení rizik * kdo je odpovědný * pravděpodobnost že nastane * závažnost dopadu * prevence * může být i návod co dělat když nastane * komentář ===== Historie a měření ===== nabídka * měli bychom zákazníka znát, pak ná dá třeba i možnost udělat nabídku a to takovou, aby mu to vyhovovalo * zákaznický tým - odborný a technický * zákazník musí vědět o nás, protože to neposílá všem * můžu se proaktivně snažit mu nabízet produkty a změny co se mu hodí * RFI - request for information * RFP - request for proposal - odpověď je nabídka * mnohdy je požadovaná i forma, aby se daly nabídky snadno porovnávat, mohou mít omezený i počet stránek * Bodyshop - nákup lidí, ale řídí si to sám zákazník. Od IT dodavatelů si pronajímá lidi * zákazník má lidi jen na dobu určitou * možná se tak dostane i ke kvalitnějším, několik nabídek na stejnou pozici * Team lease - něco mezi tím * systém na evidenci * proces jak tvořit * jaké nároky na obsah * jak odhadovat * jaký rozsah? * jeden max 2 odpovědní z anabídku * cena se dává odděleně v zalepené obálce * nabídku vyhodnocuje business, IT oddělení a pak to vyhodnocení někdo porovná s nabídnutou cenou * odhady * nejlepší podle znalosti zákazníka a zkušenosti z předchozích projektů * COCOMO - vychází z hromady zkušeností, ale požaduje těžko odhadnutelné vstupy * zapomíná se na kvalifikační testování, záruku (10% ceny systému), podpora, tvorba dodávky, licence, ... * plánování * analýza 10% * design 15% * implementace 30-40% * testování 10-20% * dodávka 5% * záruka 10% * projektové řízení 5% historie projektů * odhady * rizika * okrajové podmínky * kdo to dělal * údržba metriky * čas * rozsah (LOK) * pracnost (MD, issues) * jakost (bugs) Odhad pracnosti * odhad musí být už na začátku, když stejně ještě ani pořádně nevím co budu dělat * nutné dělat rezervy, protože odhad těžko trefím * když dám velkou, nevyhraju projekt * když dám malou, nevydělám * způsoby odhadování * dekompozice na obrazovky, požadavky, programy, entity (tabulky v db), ... a každé má své ohodnocení pracnosti a pak se to sečte * to se obvykle dělá podle historie projektů, tzn podle reálných historických dat * lze dělat odhad několika metodami a pak použít nějaký průnik, což je největší pravděpodobnost * lze převést na podobný projekt, který jsme už dělali - tzn převedu na něco co znám a s tím pracuji * projektový management středního projektu je třeba půl uvazku člověka po celou dobu projektu * rozložení * 10-20% testy * 10% dokumentace * 20% analýza * 40% implementace * 10% projektové řízení * časová náročnost fází se měří podle výkazu práce * plán * zdroje (lidi, železo) * přidělení úkolů lidem (kontrola denně, celý plán týdně) * rizika * dlouhodobý výhled * úkoly na 14 dní Nabídka a poptávka * na veřejně vypsanou nabídku je zavadatel povinnen odpovědět do 5 dnů, ale už není řečeno jak moc musí odpovědět * obvykle se v nabídce píší kvalifikační kritéria jako velikost firmy, certifikáty, obrat atd. aby se tam nemohla přihlásit firma, která není dostatečně velká na to, aby mohla nabídku splnit * mnohdy je přihlášení do výběrového řízení i závazek v podobě smlouvy, zaplacení určité zálohy atd.... * obvykle když musíme napsat nabídku tak stejně neznáme hromadu faktorů, které musíme zohlednit * často se vyžadují reference * vhodná je historie projektů, abychom pak snáze odhadovali náročnost projektu - pak se stačí podívat jo to jsme už dělali, je to podobné, stálo to tolik času * součástí zadávací dokumentace bývá info o zadavateli, popis jeho činnosti, info o organizátorovi (obvykle právník), cíl výběrového řízení, současný stav včetně technologií + co má být nové. Obvykle je velká výhoda když je možné využít z co největší části již existující řešení, neboť je to pak mnohem levnější * zadavatel si obvykle vyhrazuje právo odmítnout všechny nabídky či zrušit výběrové řízení bez náhrady nákladů * mnoho věcí (použití technologií, splnění kvalifikačních kritérií lze splnít díky delegaci na subdodavatele (pomocí smlouvy) * státní správa mnohdy vyžaduje seznam lidí, kteří na tom budou pracovat už v nabídce * u složitých zakázek může zákazník zakoupit konzultaci za prestudy, tzn analýza systému, sestavení konkrétních požadavků, návrh možného řešení a až z toho se pak sestavuje zadávací dokumentace ===== Dokumentace ===== * prostě je super, ale je nutné stanovit komu to má sloužit * určitou dokmentaci se vyplatí udržovat, jako například uživatelskou či administrátorskou příručku, ale některé dokumenty se vyplatí nechat hnít v SVN, jelikož se jedná jen o dočasné dokumenty například obsahující návrh nějaké současné komponenty a po jejich použití ztrácí význam. TYto dokumenty se už nejspíš nikdy nepoužití, tak není třeba se zatěžovat udržováním aktuální verze * je potřeba vědět, jestli dokumentujeme pro sebe nebo pro zákazníka (či někoho třetího) tam pak musíme dokumentovat mnohem víc, neboť oni nemají naše konvence atd. * i dokumentace je výstup projektu * v-model- ukazuje která část testování odpovídá které fázi vývoje * když nastavím proces, musím ho kontrolovat, protože jinak to vyšumí * klíčové dokumenty je nutné kontrolovat, že dávají smysl a jsou úplné * dokumentace * vývojářská - v kódu, nebo něco obecnějšího jako popis programu * uživatelská - návod jak to používat * projektová dokumentace - projektový plán, historie projektů (kvůli metrikám) * administrátorská - instalace a údržba * dbát na vzhled, udává to i prestiž a dojem, který mnohdy rozhodne (spolu s doporučením) * administrátorská dokumentace * psát ‫hodně detailně * tyto chyby pak bývají drahé, protože se špatně hledají * zákazník pravděpodobně narazí na problémy, na které jsme již narazili taky, takže se vyplatí tam dát troubleshooting * když něco selže tak může být aplikace hnána k odpovědnosti, takže opatrně * používat prerekvizity * psát jak se zálohuje, jak se konfiguruje (paměť serveru, notifikace, info o pádu) * vývojářská * architektura, design * kuchařka jak něčeho docílit (není podstatné jak to funguje, ale jak to udělat) * změna konfigurace, designu * jak provést dodávku * slovníček pojmů, aby bylo zákazníkovi rozumět * javadoc * přítel na telefonu, takže někdo, kdo je znalý a odpovědný * techničtější než uživatelská příručka