Pojmy¶

• příkaz - který lze chápat jako doklad, který je použit ve skladu a může být např. ve formě výdejky nebo příjemky. Tento doklad se skládá ze dvou částí, a to z hlavičky a řádků. Tyto příkazy se ale vytvářejí až na místě a na míru konkrétního zákazníka, protože každý zákazník požaduje v příkazu různé atributy.
• hlavička - typ dokladu, jakému zákazníkovi je určeno vydávané zboží a identifikace tohoto zákazníka. V jednotlivých řádcích jsou poté uvedeny položky nebo produkty a jejich popis, cena a vydávané množství.
• definice příkazu - je uložena nejčastěji v XML a udává strukturu toho, co se bude nacházet na konkrétním příkazu a jeho stavový diagram.
• stavový diagram - slouží pro evidenci stavu, ve kterém se zrovna doklad nachází (zda byl přijat, vydán atd.).

Cíl projektu¶

Současný stav aplikace, kdy nelze porovnávat dvě definice příkazů přidělává práci zejména konzultantům, kteří nasazují aplikaci DCIx u zákazníka a potřebovali by porovnat dvě existující definice příkazů, zda se v něčem neliší. Lišit se mohou z důvodu, že se nejprve u zákazníka nasadí cvičná verze, kterou zákazník testuje a zkouší si v ní svoje postupy a procesy. Po ověření, že cvičná verze funguje správně, je provedeno nasazení ostré verze, při kterém se ale může stát, že se nepřenesou správně všechny definice příkazů a zákazníkovi tak můžou chybět v definicích některé atributy. Ruční porovnávání je pro konzultanty pracné a časově náročně, proto by jim velmi pomohla možnost porovnat dvě vybrané definice příkazů.
V současné verzi aplikace také funguje porovnávání definic transakcí, kde dojde ke zvýraznění rozdílů v těchto definicí.
Naším cílem je tedy přidat tuto funkčnost pro porovnání dvou definic objednávek (orders definitions) do aplikace do části pro objednávky, aby bylo umožněno jejich snadné porovnání.

Funkční požadavky¶

Do záložky Order definitions v aplikaci DCIx přidat tlačítko Compare, kterým po vybrání dvou definic příkazů získá konzultant v nově otevřeném okně informace o tom, které části příkazu se od sebe liší. Půjde tedy o úpravu klientské části webové aplikace, do které bude přidáno tlačítko pro porovnání a úpravu serverové části, do které bude přidána funkčnost, která zjistí z načtených definic rozdíly a vrátí je zpět do klientské aplikace.

Rizika v projektu¶

• Nedostatek času z důvodu dalšího vytížení týmu (studium)
  • Zde je opatření spočívající v průběžné práci a nenechávání všeho na poslední chvíli na konec iterace, aby jsme vždy mohli zákazníkovi ukázat progress projektu.
• Značně rozsáhlá aplikace, kterou tým nezná a pochopení toho, kde a co nastavit, popřípadě doplnit, může zabrat více času než bylo odhadnuto
  • Zde nám vychází zákazník maximálně vstříc a na každé schůzce nám vždy ukáže potřebné třídy a soubory, které se nám budou při vývoji hodit.
• Připojení k aplikaci a vývojovým prostředím jen pomocí virtuálního serveru zřízeného u zákazníka - v případě výpadku nelze provádět žádnou činnost
  • Je potřeba provádět pravidelně práci na virtuálním stroji a nenechávat vše až na konec iterace. Pokud totiž přijdeme na nefunkčnost stroje, zákazník jí po našem nahlášení může rychle opravit.

Popis iterací v rámci projektu¶

1. terace¶

V první iteraci jsme se soustředili výhradně na sběr požadavků a časté 1 týdenní schůzky se zákazníkem. Díky tomu jsme si velmi brzy ujasnili požadavky na úpravu stávajícího produktu DCIx. Po dvou schůzkách byla napsána vize projektu, která byla na následující 3. schůzce schválena zákazníkem. Dále jsme se seznámili s produktem DCIx, s čím nám opět pomohl zákazník. Po této iteraci jsme také ve spolupráci se zákazníkem sestavili jednotlivé dílčí požadavky, které jsme si následně na Redmine vložili jako úkoly.

2. terace¶

Ve druhé iteraci již řešíme vybrané tři úkoly, opět po dohodě se zákazníkem. Po konci iterace bude hotové tlačítko pro porovnání definic v záložce Orders v aplikaci DCIx. Dále bude implementován handler pro toto tlačítko, který zavolá příslušnou třídu a zatím vrátí do nově otevřeného modálního okna testovací text, který ale po dalším vývoji již bude obsahovat porovnané dvě Order definice. Jako poslední bude vytvořen provizorní controler, který se bude mapovat na kontext /compareOrderDefs. Ještě bude přidán jsp, který opět prozatím zobrazí testovací obsah. Po skončení této iterace bude hotová základní funkčnost, která bude předvedena zákazníkovi.

Akceptační scénáře