Jsme firma, která už působí na trhu několik let. Za tu dobu jsme nasbírali

Transkript

1 K.O.D.A. s.r.o Jsme firma, která už působí na trhu několik let. Za tu dobu jsme nasbírali dost zkušeností v našem oboru. Zabýváme se vývojem informačního systému pro výrobní podniky a dále konzultačními a implementačními službami aplikací třetích stran - outsourcing. Aplikace je formou tlustého klienta. Poskytujeme komplexní pokrytí všech aspektů výroby od začátku až do konce. Tento IS je modulární a lze ho upravit dle požadavků klienta. Firma nabízí kompletní služby v poradenství a implementaci. Náš systém lze propojit s aplikacemi třetích stran, které ho rozšiřují o další funkcionalitu jako například účetnictví nebo objednávkový systém. Dovednosti analýza komunikace se zákazníkem programování týmová práce technologické know-how bezpečnost outsourcing vedení výroby databáze Role analytik designér vývojář testér team-leader 1

2 obchodník manager konzultant Team Honza Pavel - analytik, konzultant Petr Skočdopole - analytik, konzultant Jan Novák - analytik, team-leader Pavel Němec - senior developer, database specialist, team-leader Milan Pravý - senior developer, database specialist Tomáš Veselý - senior developer Igor Král - junior developer Jan Musil - junior developer, database specialist Jozef Straka - junior developer Petr Vyhlída - junior developer František Kolář - senior tester Ondřej Dvořák - tester Petr Svoboda - tester Jakub Novotný - designer Karel Poděs - obchodník Jan Horáček - management Michal Marek - konsultant 2

3 Projekt Napojení na aplikaci třetí strany bude naším projektem. Tzn. náš projekt bude propojeni stávajího IS pro řízení výroby s objenávkovým/účetním systémem. Tzn. analýza obou aplkací, jak se propojí. Propojení bude realizováno pomocí SDK k objednávkovému/účetnímu systému a bude realizováno na základě databázových jobů a procedur. Obě databáze jsou oddělené, je třeba synchronizovat data. Plus zákazníkovi se nelíbí současný stav co mu aplikace pro objednávkový/účetní systém nabízí, a tak požaduje nějaké úpravy. Tzn. vývojový tým pro úpravy nad aplikací třetí strany a dále vývojový tým pro vytvoření propojení mezi naším IS. Cíle rozhodnout se, jaký systém třetí strany nakoupíme - obchodník vyjedná + analytici prověří, co je nejvhodnější => zůstane jeden systém, který se koupí (staneme se jejich partnery) školení zaměstnanců - konzultanti, kteří se seznámí s obsahem systému, aby byli schopni zodpovídat dotazy klientům (support je na nás) školení analytiků a programátorů - proškolení SDK a technických detailů analýza propojení systému a požadavků na změnu našeho systému a systému třetí strany specifikace návrh řešení - architektura prototyp řešení - prototyp propojení systému programování - náš systém, propojení systémů, úprava systému 3. strany testy akceptační testy nasazení do provozu aktualizace Rizika chybná analýza v průběhu vytváření prototypu se zjistila nedostatečná technologická knowhow v rámci každé etapy počítat s výpadky pracovníků (cca 2-3 nahradíme bez vážnějších problémů) najmutí neschopných pracovníků 3

4 Umřela 2/3 programátorů. Seznam opatření, kterými budeme danou situaci řešit: Zůstali: Milan Pravý Igor Král Igor Král programoval úpravy našeho systému, s 50% spožděním aktuálně naplánovaného plánu může zadaný úkol dokončit. Milan Pravý dělal propojení systému, dostane k ruce 2 juniory, kteří nemají žádné zkušenosti, pro zaškolení do nového projektu bude potřeba vyhradit nejméně 7 dní, dále by měl plán pokračovat dle předpokladů. K úpravě systému 3. strany budou najati 2 specialisté z externí firmy (dodavatele softwaru 3. strany). Funkční body Vstupy kontaktní údaje 2 objednávka 2 aktualizace stavu skladu 0 detailní popis 0 výrobky 1 storno objednávky 1 Tabulka 1: Vstupy Výstupy faktura 2 detailní popis 0 výrobek 1 Tabulka 2: Výstupy Dotazy stav objednávky 1 stav skladu 0 Tabulka 3: Dotazy EI : 2x3 + 2x4 + 2x6 = 26 EO : 1x4 + 1x5 + 1x7 = 16 EQ : 1x3 + 1x4 + 0x6 = 7 ILF: 0x7 + 0x10 + 1x15 = 15 EIF: 1x5 + 0x7 + 2x10 = 25 Celkem : 89 4

5 Vnitřní logické soubory Polozka2Vyrobek 2 Tabulka 4: Logické soubory EIF kontaktní údaje 2 objednávka 2 detailní popis 0 Tabulka 5: EIF Charakteristiky systému Charakteristiky Stupeň hodnocení Vyžaduje systém spolehlivé zálohování a zotavení? 5 Jsou vyžadovány datové komunikace? 3 Existuje distribuované zpracování? 0 Je výkonnost kritická? 3 Poběží systém v stávajícím intenzivně využívaném operačním 1 prostředí? Systém požaduje on-line vstup dat? 5 Vyžaduje on-line vstup dat použití vstupní transakce přes více 3 obrazovek nebo operací? Jsou hlavní soubory opravovány on-line? 4 Jsou vstupy, výstupy, soubory a dotazy složité? 5 Je vnitřní zpracování složité? 4 Je kód navrhován s cílem znovupoužití? 3 Jsou konverze a instalace zahrnuty v návrhu? 2 Je systém navrhován pro násobné instalace u různých organizací? 0 Je aplikace navrhovaná tak, aby zajistila změny a snadné 3 používání na straně uživatele? Součet charakteristik 40 Počet funkčních bodů: Tabulka 6: Hodnocení systému ( (0.01 x 40) ) x 89 = Testování černá skříňka Funkce na vyhledávání objednávky v systému: objekt objednávka :=HledejObjednávku(číslo objednávky, číslo zákazníka) 5

6 číslo objednávk číslo zákazníka objekt objednávka existuje existuje instance objektu existuje neexistuje chyba vstupu neexistuje existuje chyba vstupu neexistuje neexistuje chyba vstupu existuje existuje chyba vstupu * daný zákazník nemá práva na přístup k požadované objednávce Metriky 1. Počet řádků / člověkoden - v této metrice sledujeme počet řádků vyprodukovaných jednotlivcem za určenou časovou jednotku. V rámci různých technologií je možné aplikovat různé koeficienty, které výslednou hodnotu zkorigují, aby byly jednotlivé hodnoty srovnatelné Pro náš projekt: Dolní hranice: přiřadit dohled nad zaměstnancem z důvodu možného neporozumění zadání Horní hranice: zkontrolovat kvalitu kódu 2. Method Hiding Factor - metrika sleduje poměr mezi privátními a všemi metodami v rámci projektu. Výsledkem je procentuální hodnota která určuje míru granularity/strukturování kódu. Hodnota by měla být v rozmezí 60% - 80%, čímž je pravděpodobně zaručena vysoká znovupoužitelnost a čitelnost hodnoceného kódu. Pro náš projekt: 40 - malá znovupoužitelnost kódu, možná velká komplexita kódu příliš velká granularita 3. Cyklomatická - sledujeme množství nezávislých cest, které vznikají v grafu, který odráží průběh programu. Sledujeme počet větvení (+1), které když překročí předem daný koeficient (pro náš projekt je tento koeficient stanoven na 6), tak se kód stává příliš komplexní na testování. CMM - level 2 Řízené požadavky: Plánování softwarového projektu: Plán projektu byl vypracován a udržován pomocí MS Projektu (Ganttův a sítový diagram, PERT odhad) Řízené subkontrakty na software: Požadavky na změnu systému 3. strany jsou realizovány jako jednotlivé subkontrakty dodavateli tohoto systému Zajištění kvality: Pro zajištění a kontrolu kvality vyvíjeného softwaru je použita dříve zmíněná sada metrik, průběžných testů a inspekcí Řízení softwarových konfigurací: máme definované protokoly na řízení softwarových konfigurací 6

7 CMM - level 3 Zlepšování org. procesu: najmeme odpovědného pracovníka na udržování aktuálního pracovního plánu, stanovíme pro jednotlivé subprojekty roli zodpovědného řešitele, který má přehled o jednotlivých částech svého subprojektu a je zodpovědný za jeho včasné a řádné vyřešení Definice org. procesu: nastavení business procesů ve firmě a jejich řízení a udržování pomocí business analytika Školící program: v rámci přípravy na projekt byli jednotliví pracovníci proškoleni Řízení integrovaného software: máme definované protokoly na řízení integrace softwaru Aplikace inženýrských metod u softwarového produktu: RUP Koordinace mezi pracovními skupinami: koordinace je zajišt ována pomocí team leaderů, kteří kooperují na daných požadavcích / úkolech Detailní prověrky a oponentury: rozšíření stávajících inspekčních metod na robustnější a formálně ověřitelné. Zavedení automatických testů a kladení důrazu na unit testy a revize kódu. 7