Vedení týmového projektu - jaro 2009/LS

Z FI WIKI
Přejít na: navigace, hledání

Projekt do předmětu Vedení týmového projektu: LS s.r.o.

Profil společnosti

Spoločnosť Logistic Systems s.r.o. sa zaoberá tvorbou informačných systémov pre dopravné spoločnosti a logistické centrá. Našim cieľom je poskytnúť klientom integrované IT riešenia, pokrývajúce všetky potreby modernej dopravnej spoločnosti. Špecializujeme sa na systémy plánovania dopravy, Warehouse Management a Warehouse Control systémy a integráciu týchto systémov s existujúcimi ERP riešeniami ako SAP, Oracle Applications a Microsoft Dynamics. Máme rozsiahle skúsenosti s mobilnými technológiami, ktoré zaisťujú našim klientom presné informácie v reálnom čase, nevyhnutné pre konkurencieschopnosť logistickej spoločnosti.

Naša spoločnosť disponuje silným tímom skúsených IT expertov a programátorov, ktorých znalosti pokrývajú široké spektrum platforiem a technológií. Dodávame riešenia na báze Java EE, Microsoft .NET, Windows CE, Symbian OS, Oracle a MS SQL Server. Spolu s našimi partnermi Vám navrhneme a zrealizujeme najvhodnejšie riešenie, vrátane dodania potrebného hardware.

Manažeři

Realizované projekty

  • Velkobochod s hračkami
    • pouze pro interní použití
  • Větší velkoobchod
    • b2b support (web services, věci ven)
  • Spediční firma - transport farmaceutického zboží

Řešený projekt

Nadnárodní logistická firma

Požadavky

  • skladové hospodářství
  • planovani dopravy
  • optimalizace vyse uvedenych
  • chceme vedet, kde mame kamiony - real-time sledovani
  • chceme vedet, kde mam jednotlive zasilky
  • webovy frontend pro ucely trackingu a zadavani objednavek
  • podpora b2b fungovani
  • fungovani v mezinarodnim prostredi

Dovednosti, role ve společnosti

  • generický programátor - 2x
  • databázový specialista - 1x
  • síťový specialista - 1x
  • hardwarový specialista - 1x
  • grafik - 1x
  • analytik - 2x
  • softwarový architekt - 1x
  • tester - 2x
  • senior programátor - 2x
  • teamleader - 1x
  • specialista cílového oboru (logistik) - 1x

Zaměstnanci

  • František Vočoudil - analytik
  • Josef Nemakal - analytik
  • Adam Churavý - teamleader
  • Slavomír Šeňo - síťový specialista
  • Tamara Cenková - generický programátor
  • Petr Kubej - generický programátor
  • Jiří Růžička - senior programátor
  • Jiří Jakubů - senior programátor
  • Miloš Kajuk - softwarový architekt
  • Ján Lukány - grafik
  • Zdena Kmuníčková - tester
  • Daria Netíková - databázový specialista
  • Vladimír Fiedler - hardwarový specialista
  • Václava Nováková - specialista cílového oboru (logistik)
  • Radim Karpíšek - tester

Typ projektu

Projekt jsme zvolili typu 3 (vysoká jistota produktu a nízká jistota procesu a zdrojů). Výcházíme ze zkušeností a předchozích projektů. Model životního cyklu jsme zvolili inkrementální.

Jednotlivé části systému

  • Jádro systému (1)
    • Databáze
    • Prostředí
    • Datový model a API
  • Skladové hospodářství (2)
  • Webové rozhraní (5)
  • Mobilní přístup (5)
  • Plánování dopravy (3)
  • Tracking (4)
    • Zpětná vazba na plánování dopravy
  • B2B (webová služba) (5)
  • Sběr statistik a nástroj pro návrh optimalizací (možné budoucí rozšíření)


Rizika

TOP 10 rizika

  • Nedostastek pracovníků - outsourcing z profesionální programátorské společnosti, v případě dlouhodobého nedostatku headhunting
  • Nereálné termíny a rozpočty - nutnost nalezení kompromisu se zákazníkem, případné odstoupení od smlouvy
  • COTS, externí komponenty - nalezení alternativního řešení (pokus o analýzu roblému a bugfix)
  • Neshody v požadavcích - požadavky musí být jasně dané, pokud ne, musíme žádat o upřesnění
  • Neshody v uživatelském rozhraní - vyhovění zákazníkovi, ať je rozhraní podle toho jaké chce on (i kdyby to měla být hloupost)
  • Architektura, výkon, kvalita - volba alternativních a přijatelných technologických prostředků
  • Změny v požadavcích - vyhovění zákazníkovi, ale adekvátní prodloužení termínů a zvýšení rozpočtů
  • Zděděný software - neakceptujeme, vytváříme nový, maximálně implementujeme stejné či inovované funkce
  • Externě řešené úlohy - programujeme si vše sami, maximálně využíváme externího specialistu na vyškolení
  • Přecenění možností informatiky - stornování projektu, případně realizace pouze jeho části v rámci možností informatiky

Konkrétní rizika

  • Uvodni studie
    • Nespravny odhad rozsahu system – dokladna analyza
    • Neochota klienta spolupracovat – potreba osoby, kt. bude zodpovedna za projekt na strane klienta
    • Neznalost ocenovacich postupov zo strany klienta (na zaciatku mu nevieme povedat presnu sumu) – vysvetlit klientovi postup ocenovania, ramcova zmluva
    • Nepochopenie obchodneho modelu spolocnosti (potreba cloveka, kt. sa je odbornik na cielovu oblast, v nasom pripade logistika)
  • Jadro systemu
    • Nepochopenie principu jadra systemu a doplnkov
    • Potreba vysoko kvalifikovanych pracovnikov – vyhnut sa rieseniu len s jednym expertom (ak odide, bude obtiazne system rozsirovat)
    • Nedostatocna dokumentacia
    • Malo flexibilny datovy model (ak neskorsia zmena poziadavkov bude vyzadovat upravu jadra a jadro nabude dostatocne flexibilne)
    • Chyby v jadre (povod: interne testovanie je malo efektivne, externy audit)
  • Skladove hospodarstvi
    • Klient nie je schopny dostatocne formulovat poziadavky na system (neexistuje nikto, kto presne pozna fungovanie celeho skladu)
  • Planovani dopravy
    • Nezvladnutie teorie (planovacie algoritmy) – nedostatok kvalifikovanych pracovnikov
  • Tracking
    • Nezvladnutie novych HW & SW technologii – ciarove kody (tlaciarne, citacky, SW API), RFID, GPS (HW + API)
    • Nedostatok kvalifikovanych pracovnikov – ak budeme chciet nasich ludi zaskolit, moze to mat za nasledok to, ze nebudu pracovat, ale ucit sa
  • Webove rozhrani
    • Podcenenie dolezitosti web. rozhrania – priradenie ulohy neskusenym programatorom
    • Nedostatocny vykon, bezpecnost (dodrziavat best practices, striktna n-vrstvova architektura – web je len cisto prezentacna vrstva)
    • Zla pouzitelnost / uzivatelska neprivetivost / obtiazna navigacia – nespokojnost zakaznika (potreba testov pouzitelnosti, komunikacia so zamestnancami klienta)
  • Mobilni pristup
    • Nezvladnutie novej technologie (zaplatenie skolenia / riesenie externou firmou)
    • Zle navrhnute uzivatelske rozhranie - pouzitelnost (mensi display)

Funkční body

Datový model - Skladové hospodářství

Dat model.png

Funkční body vztažené k datovým funkcím

  • Interní logické soubory (ILF)
  1. Odesílatel, Příjemce, Objednávka, Balík, Volné skladové prostory, Obsazené skladové prostory
5
  2. Aktuální stav skladu
1
  3. Přidání a úprava odesílatele a příjemce, Přidaní odebraní skladových prostor
4
  9. formuláře: přidání a úprava zákazníků, vytvoření objednávky
3 (EIF)
  Celkem
10
  • Soubory externího rozhraní (EIF)
Celkem 3

Funkční body vztažené k transakčním funkcím

  • Externí vstupy (EI)
  1. registarce a změna údajů zákazníka, vytvoření objednávky
3
  11. změna údajů v objednávce
1
  Celkem
4
  • Externí výstupy (EO)
  3. aktuální stav objednávek pro fakturaci
1
  6. zobrazení a tisk objednávky
2
  8. aktuální stav skladu (grafy)
2
  Celkem
5
  • Externí dotazy (EO)
  1. aktuální stav skladu pro tracking a statistiku
2
  4. tisk stavu objednávky (tracking), tisk statistiky
2
  Celkem
4

Faktory technické složitosti

1. Vyžaduje systém spolehlivé zálohování a zotavení?
4
2. Jsou vyžadovány datové komunikace?
5
3. Existuje distribuované zpracování?
0
4. Je výkonnost kritická?
1
5. Poběží systém v stávajícím intenzivně využívaném operačním prostředí?
3
6. Systém požaduje on-line vstup dat?
5
7. Vyžaduje on-line vstup dat použití vstupní transakce přes více obrazovek nebo operací?
1
8. Jsou hlavní soubory opravovány on-line?
0
9. Jsou vstupy, výstupy, soubory a dotazy složité?
1
10. Je vnitřní zpracování složité?
1
11. Je kód navrhován s cílem znovupoužití?
4
12. Jsou konverze a instalace zahrnuty v návrhu?
3
13. Je systém navrhován pro násobné instalace u různých organizací?
2
14. Je aplikace navrhovaná tak, aby zajistila změny a snadné používání na straně uživatele?
4

Testy

Testování vložení balíku do systému

  • ID balíku - musí být kód země, v které byl balík podán k doručení a pořadové číslo dle počtu balíku podaných v dané zemi
    • kód země musí být dvě velká písmena
    • číslo za kódem země musí být větší jak 0
    • stejné ID balíku nesmí být použito v systému vícekrát
  • Rozměry - udáváno v milimetrech ve tvaru výška,šířka,hloubka
    • musí být zadány všechna tři čísla oddělená čárkami
    • žádný z rozměrů není záporný ani nulový
  • Hmotnost - udávána v gramech
    • hodnota nesmí být záporná ani nulová

Metriky

  • FO - Počet typů použitých v deklaracích, formálních parametrech, návratových typech, deklaracích vyhazování vyjímek a lokálních proměnných. Jednoduché a rodičovské typy se nepočítají.
    • FO využíváme k měření složitosti a "čistoty" návrhu.
  • NOAM - Počítá se množství metod přidané třídou. Zděděné a překrité metody nejsou započítány. Vysoká hodnota téte metriky indikuje velké odlišnosti od rodičovské třídy. V takovém případě je vhodné zvážit jestli by daná třída neměla být rozdělena do několika menších tříd.
    • NOAM využíváme k ohodnocení znovupoužitelnosti kódu.
  • Měření produktivity zaměstnanců v závislosti na: pracovní době (flexibilní, pevná), pracovním prostředí (v kanceláři, doma). Výpočet: počet funkčních bodů za jednotku času.
    • Dané metriky používáme pro zefektivnění produktivity a dodržování termínů.