Poznámky z předmětu A4M33SEP
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
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
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í
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ů
- 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
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í
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
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
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
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
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)
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