|
Spolupráce softwarových firem při začlenění externí agendy do
projektu autor:
RNDr. Ilja Kraval, květen 2011 Object
Consulting s.r.o. Server
objektových technologií Úvod Nedávno jsem se při konzultaci setkal se zajímavým problémem, který se při vývoji SW vyskytuje poměrně dost často. Dvě SW firmy, nazvěme je symbolicky A a B, spolupracovaly na větším projektu při vývoji velmi rozsáhlého informačního systému. Firma B vystupovala vůči firmě A jako subdodavatel specifické části řešení. Obchodní záměr spolupráce obou firem byl jasný a zřejmý: Původní produkt doposud nepodporoval určitou důležitou agendu, bylo proto obchodně žádoucí tuto agendu do produktu začlenit. Protože firma B měla s touto agendou bohaté zkušenosti a firma A v podstatě žádné, úkolem firmy B jako externího dodavatele bylo tuto agendu „zapojit“ do projektu jako integrální část systému. Bylo vcelku pochopitelné a samozřejmé, že se vyžadovalo, aby se v celém produktu externě dodaná část nejevila jako cizorodý prvek, tj. bylo žádoucí, aby agenda dodaná firmou B vystupovala v pozici rovnocenně s ostatními agendami firmy A. Je třeba zdůraznit, že toto začlenění nespočívá v tom, že by se vzalo nějaké již naprogramované řešení firmy B, naprogramoval se pouze můstek mezi systémem a touto aplikací. Cílem bylo vytvořit další agendu systému, využít přitom expertní znalosti problematiky dané agendy ze strany pracovníků firmy B, použít některých již naprogramovaných částí vnitřku agendy a naprogramovat požadované části agendy pro návaznost na celý systém.
Je zřejmé, že okamžitě vyvstal problém „styčných bodů“ obou systémů a rozvinula se poměrně hektická a bouřlivá debata o společných entitách, společných číselnících, tabulkách a jiných prvcích systému a rozhodovalo se, na které straně se budou tyto problémy řešit. A právě o postupu při začlenění určitého řešení externí firmy do projektu pojednává tento článek. Hlavní úskalí problému začlenění externího řešení do systému Většinou se při řešení problému začlenění agendy externího dodavatele do jiného rozsáhlého systému, věnuje relativně dost dlouhý úvod analýze možných průniků a odlišností obou aplikací. To je sice je v pořádku, ale má to svoje nebezpečné úskalí. Diskuse nad společnými prvky a nad rozdíly v obou aplikacích bývají většinou zahájeny slovy „a ještě nesmíme zapomenout na to, že je třeba upravit…“ anebo podobně „…a ještě nesmíme zapomenout na to, že se v evidenci liší obě aplikace v tom, že…“. Poté následují rozbory a analýzy obsahu číselníků, atributů, omezení, potřebnosti a odlišnosti obou aplikací… Praxe ukazuje, že pokud se v diskusi začíná příliš často objevovat věta „a ještě nesmíme zapomenout na to, že…“, tak je to silný signál k tomu, aby se účastníci diskuse zamysleli nad tím, zda jim náhodou nechybí nějaký dobrý a kvalitní systematický postup, tj. algoritmus neboli systematická metoda pro vyhledávání toho, na co se nesmí zapomenout. Jinak řečeno, není špatné si vyjmenovávat postupně „na co se nesmí zapomenout“, ale jakmile začíná být tento seznam příliš dlouhý, začíná být kritickou otázka „a jak tedy provedeme inventuru toho, že jsme na nic nezapomněli?“. Hlavní riziko začlenění a úpravy jiného
řešení subdodavatele do stávajícího systému spočívá v možnosti opomenout
některé aspekty tohoto začlenění, protože seznam úprav a požadavků na
začlenění externí agendy bývá dlouhý a pouhým výčtem nepřehledný. Firmy přitom
bohužel nehledají způsob, jak provést přehlednou a kvalitní inventuru
takovýchto požadavků. Řešení Zahájení prací na dobrém a efektivní algoritmu pro inventuru všech požadavků na propojení stávajícího systému a externí agendy nehledejme paradoxně v obou systémech, ale mimo systém. Při tvorbě logicky přehledného, správného a kvalitního seznamu všech nutných návazností systémů je totiž třeba vyjít ze základů procesního modelování (BPM) a nalézání případů užití (UCM). Tam totiž leží jádro pudla a tam hledejme odpověď na naši otázku. Princip práce je nyní již jednoduchý: 1. Najděme procesy podniku, tedy činnosti v okolí systému, které souvisejí s dodávanou agendou. Pro tento zápis stačí stručná varianta v textovém tvaru. 2. Pokud třeba, určíme případně i logické posloupnosti procesů, opět stačí pouze v textu. 3. Identifikujeme související případy užití agendy a v nich najdeme styčné body návazností obou systémů. Poznámka: Procesní modelování (tedy hledání kontextu použití systému pomocí činnosti okolí informačního systému) při současné identifikaci a popisu případů užití patří k nejzákladnějším postupům analytika a je mu proto věnována patřičná pozornost i na našich pobytových nebo internetových školeních (včetně zajímavých příkladů a cvičení). Je třeba zdůraznit, že vyhledávání procesů podniku má svůj přesný řád a proto se případy užití dají zinventarizovat. Následně uvnitř případů užití vidíme zřetelně návaznosti obou systémů. Je zřejmé, že díky tomu získáme (a nutno podotknout, že velmi efektivně) přehledný soupis všech styčných bodů mezi dodávanou agendou a systémem přímo již jako úkoly k řešení (tasky do task manageru).
Příklad Aby bylo úplně jasné, jak vypadá tento postup, ukažme si jednoduchý příklad. Představme si, že systém nepodporuje agendu Skladové hospodářství a externí dodavatel má za úkol začlenit ji do stávajícího systému. Zahájíme práce pomocí „klasických postupů“ procesního modelování a vyhledávání případů užití, které by měl každý analytik dobře znát a ovládat (pozn.: je to jeho parketa, viz zmíněná internetová a pobytová školení). Nalézají se tedy jednotlivé procesy, uspořádávají se do stromové struktury, hledá se logika posloupnosti procesů (metodou Parser apod.), nalézají se případy užití. Nechť se pomocí metody Parser nalezl tento scénář procesu Příjem zboží na rampu skladu (berte jako příklad), neboli jedno User Story: BP Příjem zboží na rampu skladu K rampě přijíždí kamion. Skladník bere do
ruky PDA a provede naskladnění na rampu, viz UC Evidence
naskladnění zboží na rampu UC Evidence naskladnění zboží na
rampu Obsluha oběhne všechny balíky, u každého pomocí čtečky načte čárový kód balíku, v systému se najde podle tohoto kódu Druh zboží na skladě, zobrazí se jeho název, obsluha zadá počet balíků, poté pokračuje dalším balíkem anebo ukončí scénář toho UC. Všimněte si, že tento jednoduchý scénář ihned implikuje problémy k řešení: Je sice zřejmé, že program pro čtečku a PDA dodá subdodavatel (firma B) v rámci dodané agendy skladu, ale okamžitě vyvstává otázka návaznosti entit na centrální agendu číselníku Druh zboží. Jak je ze scénáře zřetelně vidět, vyžaduje se, aby na základě sejmutého čárového kódu byl identifikován prvek v číselníku Druh zboží, což zatím není řešeno a přitom je nutno zdůraznit, že číselník Druhů zboží patří do centrální agendy! Tento problém je tedy nutno vyřešit a vznikl tak první „task“ do „task manažeru“ pro vývojáře (jak provázat čárový kód s Druhem zboží a jak se s ním bude pracovat). Na okraj jenom podotknu, že možných řešení je hned několik, například zásah a přeprogramování číselníku Druh zboží, nebo zavedení druhé entity (Kód), která si ukazuje na tento Druh zboží (tj. druhá tabulka s kódem a cizím klíčem ID Druhu zboží), anebo importem číselníku do agendy apod. To je však již zvolené řešení, důležité je, že dostáváme úkoly k řešení v systematické a logické podobě. Zvolil jsem úmyslně velmi jednoduchý příklad, aby bylo jasné, jak tento postup funguje. A teď si představme, že jsme klasickými postupy BPM a UCM nalezli další a další procesy (například přesun na skladě, vyskladnění atd.) a spouštěné případy užití, v nich nalézáme další návaznosti mezi systémem a dodávanou agendou - a tím samozřejmě další „tasky k řešení“. Závěr Také externě dodávaná agenda by měla mít svůj procesní model a svůj model případů užití. Z těchto modelů lze vycházet při inventarizaci styčných bodů obou systémů, protože procesní modelování nám umožňuje všechny styčné body uspořádat velmi přehledně díky zavedené stromové struktuře a případy užití ve svých scénářích přesně definují nutné body spolupráce mezi systémy. Opominutí tohoto postupu vede v diskusích ke skákání od problému k problému, k nekonečným a stále otevřeným diskusím nad styčnými body a samozřejmě následně k potencionálním problémům při realizaci, kdy se na spoustu důležitých styčných bodů prostě zapomene anebo se dohoda nad nimi chápe z obou stran jinak.
Konec
článku
|