Datum poslední modifikace: 6. 2. 2024
Dokumentaci k projektu můžete psát v téměř libovolném systému, či editoru dosažitelném v prostředí CVT.
Doporučeny jsou Microsoft Word, HTML, .pdf (dle nabídky Project Office 365 ), .prj (Rational Rose). Důležitá je správnost a čitelnost textu. K tomu přispívá zejména gramatická správnost, rozumná vyjadřovací schopnost a přehledná struktura dokumentu. Počet stránek v tabulce uvedený je přibližný a nepočítá se do něj titulní stránka. Pro obsahovou náplň odevzdávaných dokumentů použijte šablony, níže v tabulce uvedené, které můžete vhodně upravit a doplnit dle konkrétní situace řešeného problému ( tj. použitého vývojového přístupu, použitého vývojového prostředí, specifika projektového týmu, apod.).
Dokumentace se odevzdává prostřednictvím IS VUT, dle příslušnosti k týmu nebo musí být dle plánovaných termínů dostupná na webových stránkách týmu.
| Dokumenty | Stran textu (cca) | Šablona |
| Definice
problému, Úvodní studie |
2-5 | zde zde |
| Specifikace požadavků, analýza, Přezkoumání požadavků |
5-10 2-3 |
zde zde |
| Plán projektu | 2-5 | zde |
| Plán etapy (implementace) | 1-2 | zde |
| Návrh | 3-7 | zde |
| Výsledky oponentury | 1-2 | zde |
| Konfigurační řízení | 2-3 | zde |
| Zdrojové texty programu | všechny | - |
| Zpráva o testování, změnové řízení | 3-5 | zde |
| Referenční a uživatelská příručka | 4-10 | zde |
| Záznamy o schůzkách, protokoly o ukončení etap | 2-5 |
zde |
| Uzavření
projektu, závěrečné
zhodnocení |
2-5 |
zde |
| Seznam rizik s možným dopadem na cenu/čas/kvalitu/rozsah) ve vašem projektu a návrh preventivních opatření. Na každého člena týmu minimálně 5 identifikovaných rizik. Může být součástí dokumentu plánu projektu. Náměty k identifikaci rizik. | 6-9 |
|
| Metriky výsledného produktu - nejméně 10 metrik (např. počet funkcí, počet tříd, počet skriptů, chyb, apod.) | 1-2 | |
| Sledování a vyhodnocení trvání prací na projektu (plánované/skutečné) *1 | 3-5 |
|
| Zpracujte
data o příčinách chyb
ve vašem projektu. Použijte Paretovu
analýzu . Výsledky prezentujte
pomocí Paretových
digramů (soft.
podp. např. zde).
Zvolte jednotné náklady na odstranění zjištěných závad (100 Kč/hod.). *2 |
2-3 |
|
| Logická rámcová matice *3 | 2-3 | |
Každý dokument odevzdávaný v rámci projektu MPR bude obsahovat následující části (v uvedeném pořadí):
Obsah (pro dokumenty delší jak 2 strany).
Úvod s uvedením účelu a přehledem zbytku dokumentu. Zde je vhodné také uvést tabulku zkratek a odkazy na zdroje informací k řešenému problému.
Text dokumentu členěný na číslované oddíly.
Je velmi vhodné, aby všechny
dokumenty
jednoho týmu měly stejnou (nebo podobnou) grafickou úpravu - titulní
stránka, použité typy písma, systém očíslování.
Vzhledově bude stejná pro všechny dokumenty. Obsahuje identifikační údaje. Název týmu je dle vaší vlastní volby na začátku semestru, Název projektu podle zadání, Název dokumentu, např. "Dokument specifikace požadavků".
Pokud bude dokument produktem jiného systému (Project Office 365, Rational Rose), je nutné dbát na to, aby tyto informace byly na patřičných místech zaznamenány.
Vzor obsahu titulní stránky dokumentu:
Fakulta informačních
technologií
Ústav informačních systémů
Management projektů
<Název projektu>
<Název dokumentu>
<Název týmu>
<Autoři dokumentu>
<Datum>
Jako autoři budou uvedeni jen ti členové týmu, kteří se na přípravě dokumentu aktivně podíleli; za jménem člena, který je za dokument zodpovědný jako "manažer fáze", bude uvedena příslušná indikace.
Standardní obsah dokumentu; úroveň detailu (zda budou uvedeny sekce N nebo i N.N nebo dokonce N.N.N) zvolte vhodně podle délky a složitosti dokumentu. Pokud dokument obsahuje množství obrázků a/nebo tabulek, je vhodné vytvořit a za obsah připojit také seznam těchto elementů.
Stručný a jasný přehled, čeho se dokument týká a jaké má části; nutnou součástí každého dokumentu. Stačí dva, maximálně tři odstavce; mají být napsány tak, aby nemusel čtenář už dál číst a přesto měl přehled o celém dokumentu.
Pokud se jedná o technický dokument, hemžící se zkratkami a akronymy, je nutné uvést zde i vysvětlující tabulku (zkratka, plný text). Může být vhodné zde také uvést odkazy na další dokumentaci (např. pro návrhové dokumenty, odkaz na specifikaci požadavků, literaturu o používaných metodách apod.)
Čleňte jej do očíslovaných sekcí (např. 1. Úvod) a podsekcí (např. 1.1 Použité nástroje) - číslování usnadňuje orientaci a odkazy. Taktéž číslujte obrázky, diagramy a tabulky, podle vhodného systému konzistentně uplatňovaného. Používejte jednotný font.
Soustřeďte se především na obsah. Nerozlévejte se do epické šíře, pište stručně a jasně, ale s uvedením všech potřebných informací.
Pokud se jedná o velmi dlouhý dokument a/nebo členitý dokument, je dobré mít na konci rejstřík (neboli index), jako je v každé dobré technické knize; např. se může hodit pro detailní návrh nebo rozsáhlou specifikaci požadavků.
Podrobný popis struktury dokumentu viz výtah z IEEE standardu.
Bude obsahovat např. model jednání, diagram tříd. Musí být posouzen a schválen uživatelem (bude kontrolováno). Nezapomeňte si naplánovat schválení tohoto dokumentu.
Podklad pro oponenturu
Účel a hlavní funkce systému
- Popis účelu a funkce.
- Funkční rozhraní - hlavičky a popis exportovaných funkcí.
- Datové rozhraní - struktura exportovaných dat, odkazy na soubory/tabulky.
- Vazby na ostatní moduly.
- Popis funkcí.
- Přehled - celkový popis, ERD implementační struktury dat (alternativně třídy), pokud je výrazně odlišná od analytického modelu.
- Struktuta souborů/tabulek - pro každý soubor, účel, kterými moduly je používán.
Může mít např. následující formát:
Tým: Předmět: Datum: Účastníci: Seznam nálezů: .. .. .. Opravy provede: Celkové zhodnocení: |
Záznam nálezů
Požadovaná dokumentace nebude úplným plánem testování, cílem je pokrýt nejpodstatnější informace pro specifikaci a výsledky testů. Provedené testy budou testovat nejméně dva vybrané moduly, pro každý budou nejméně dva testovací případy.
Software testing - typy testů Automatizace testů
- Kritéria dokončení testů (kdy je možno prohlásit "hotovo")
- Postupy a nástroje
Pro každý testovací případ bude uvedeno:
- Identifikátor případu.
- Název testovaného modulu.
- Účel testovacího případu (co se teststuje).
- Vstupní (testovací) data, pomocí jakých technik vybrána.
- Očekávané výstupní hodnoty.
- Postup provedení testu (pokud není zřejmý/standardní).
- Výsledky - tabulka, každý řádek obsahuje:
- datum, čas a jméno testéra,
- skutečné výstupní hodnoty,
- indikace typu Prošel/Neprošel,
- opakuje se tolikrát, kolikrát byl testovací případ opakován než neodhalil chybu.
- účel a cíl programu (z jakého důvodu byl vytvořen, k čemu slouží uživateli, jak toho dosahuje),
- přehled funkcí programu (co vše umožňuje),
- typografické konvence používané v příručce.
- potřebné vybavení,
- postup instalace,
- možné variace, doporučená instalace.
- spuštění a ukončení,
- standardní horké klávesy, kombinace (ukončení, help, další lekce, ...),
- nápověda (pokud existuje; jak ji získat, jak se v ní pohybovat --- postup přes menu/klávesy, zadávané hodnoty, příklady).
Odevzdávání výsledného produktuMožný obsah na dokumentaci některých fází najdete zde:
- parametry příkazové řádky, default nastavení,
- konfigurační soubory/menu,
- struktura menu a přehled funkcí.
Metodika OO vývoje aplikací
Program se odevzdává ve třech fázích:
!!! Nezapomeňte uvést do plánu projektu !!!
Upozornění: Instalace je nutnou součástí projektu. Budou také dodány zdrojové texty, které musí obsahovat README soubor s popisem struktury a INSTALL s popisem instalace. Veškerá definitivní dokumentace projektu, včetně vytvořené aplikace (zdrojové texty) bude vhodně strukturována do adresářů a odevzdána na CD, případně odevzdána dle pokynů vedoucího asistenta (např. v dokumentovém skladu).