Poznámky z předmětu A4M33SEP

• vhodný doplněk ke slidům

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

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

• 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é

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

• 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
  1. zákazník něco chce změnit
  2. udělám analýzu, odhady, dopad
  3. zákazník to musí schválit
  4. 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, …

• 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 24×7, 16×5, 8×5 … 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

• 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ář

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

• 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