ALM - Application Lifecycle Management - Správa životního cyklu aplikací. Koncept metodiky řízení životního cyklu aplikací - ALM (Application Lifecycle Management)

Atd..

„Řízení životního cyklu“ spočívá v potřebě zvládnout postupy známé systémovému inženýrství:

• správa informací(„správné informace musí být k dispozici správným zúčastněným stranám včas a ve formě, která je přístupná jejich použití“),
• správa konfigurace(„informace o návrhu se musí shodovat s požadavky, informace „tak, jak je postaveno“, musí odpovídat návrhu, včetně zdůvodnění návrhu, fyzický systém musí odpovídat informacím „ve stavu, kdy je vyroben“ a různé části návrhu se musí navzájem shodovat“, někdy část této praxe se nazývá „řízení změn“).

LCMS vs PLM

Nově formulovaný LCMS nepoužívá PLM jako požadovanou softwarovou třídu, kolem které je takový systém postaven. Ve velkých inženýrských projektech se používá více (nejčastěji výrazně „nerozvinutých“) PLM od různých dodavatelů najednou a při vytváření LCMS se většinou bavíme o jejich meziorganizační integraci. Samozřejmě se zároveň řeší i otázky, jak integrovat do LCMS informace těch systémů, které zatím nejsou propojeny s žádným z PLM systémů rozšířeného podniku. Pojem "extended enterprise" (extended enterprise) obvykle označuje organizaci vytvořenou prostřednictvím systému smluv ze zdrojů (lidé, nástroje, materiál) různých právnických osob podílejících se na konkrétním inženýrském projektu. V rozšířených podnicích se odpověď na otázku, do kterého PLM, do kterých konkrétních systémů CAD / CAM / ERP / EAM / CRM / atd. jsou integrována, stává netriviální: nemůžete předepsat vlastníkům různých podniků, aby používali software. jednoho dodavatele.

A protože PLM systém je stále software a „systém řízení“ z LCMS je jasně chápán také jako „systém řízení“, termín LCMS jasně implikuje organizační aspekt, nejen aspekt informačních technologií. Fráze „používání PLM k podpoře systému řízení životního cyklu“ je tedy docela smysluplná, i když může být matoucí, když se v něm doslova přeloží „PLM“ do ruštiny.

Avšak chápání „systému řízení životního cyklu“, když jej ovládají IT lidé, se okamžitě zmenšuje zpět na „pouze software“, který vypadá podezřele jako software PLM. A po tomto přílišném zjednodušení začínají potíže: „krabicový“ PLM systém od některého dodavatele softwaru pro automatizaci projektování je obvykle okamžitě konstruktivně prezentován jako sada softwarových modulů z katalogu tohoto dodavatele bez ohledu na podporované inženýrské a manažerské funkce a se považuje za trojici následujících složek:

• datové úložiště dat životního cyklu,
• "workflow engine" na podporu "managementu",
• „portál“ pro zobrazení obsahu úložiště a stavu pracovního postupu.

Účel LCMS

Hlavní účel: LCMS detekuje a předchází kolizím, které jsou při společném vývoji nevyhnutelné. Všechny ostatní funkce LCMS jsou odvozeniny, které tuto hlavní funkci podporují.

Hlavní myšlenka každého moderního LCMS- jedná se o použití přesné a konzistentní reprezentace systému a světa kolem něj v nevyhnutelně heterogenních a zpočátku nekompatibilních počítačových systémech rozšířené organizace. Využití virtuálních layoutů, informačních modelů, datacentrických úložišť návrhových informací zajišťuje detekci kolizí při „stavbě v počítači“, „virtuální montáži“, a nikoli při zakreslování výkresů a jiných projektových modelů do materiálové reality během vlastní výstavby. „v kovu a betonu“ a uvedení do provozu.

Myšlenka LCMS tak nesouvisí s různými „automatizacemi designu“, primárně s „generativním designem“ (generativní design) a „generativní výrobou“ (generativní výroba). LCMS se již nezabývá syntézou, ale analýzou: detekuje a/nebo předchází kolizím ve výsledcích návrhu jednotlivých subsystémů, když jsou sestaveny dohromady pomocí různých technologií:

• sloučení projektových dat do jednoho úložiště,
• spuštění algoritmu kontroly integrity pro technická data distribuovaná v několika úložištích,
• provedením skutečné „virtuální montáže“ a simulace pro speciálně vybranou podmnožinu návrhových dat.

Přístup založený na modelu

Použití LCMS znamená odmítnutí nejen papíru v designu, ale také "elektronického papíru"(.tiff nebo jiné rastrové formáty) a přechod na datově orientovanou reprezentaci informací. Porovnání dvou modelů, které existují na papíře v některých zápisech, a nalezení nesrovnalostí v nich je mnohem obtížnější a delší než zabránění kolizím ve strukturovaných elektronických dokumentech, které využívají spíše modely inženýrských dat než rastrovou grafiku.

Datový model lze navrhnout podle nějakého jazyka, například:

• v souladu s normou popisu vývojové metody ISO 24744),
• metamodel (z hlediska standardizačního konsorcia OMG),
• datový model/referenční data (ve smyslu normy ISO 15926 pro integraci dat životního cyklu).

Je to tento přechod ke strukturálně reprezentovaným modelům, které již existují v raných fázích návrhu a nazývá se „Model-based system engineering“ (MBSE, model-based system engineering). Odstranění kolizí pomocí počítačového zpracování dat je možné již v nejranějších fázích životního cyklu, ještě předtím, než se objeví plnohodnotné 3D modely konstrukce.

LCMS by měl:

• poskytují mechanismus pro přenos dat z jediné aplikace CAD/CAM/ERP/PM/EAM/atd. jinému- a v elektronické strukturované podobě, nikoli ve formě "balíčku elektronického papíru." Přenos dat z jednoho inženýrského informačního systému (s jasným pochopením kde, kde, kdy, co, proč, jak) je součástí funkcionality poskytované LCMS. LCMS tedy musí podporovat workflow (tok práce, který zčásti vykonávají lidé a zčásti počítačové systémy).
• kontrola verzí, tedy poskytovat funkci správy konfigurace - jak modelů, tak fyzických částí systému. LCMS udržuje taxonomii stupňovitých požadavků a poskytuje prostředky ke kontrole rozhodnutí o stupňovitém návrhu a jejich zdůvodnění kolidujících s těmito požadavky. V průběhu technického vývoje je jakýkoli popis systému, jakýkoli z jeho modelů mnohokrát měněn a doplňován, a proto existují v mnoha alternativních verzích různého stupně správnosti a v různé míře si navzájem odpovídají. LCMS musí zajistit, aby byla pro aktuální práci použita pouze správná kombinace těchto verzí.

Architektura LCMS

Architektonických řešení pro LCMS může být mnoho, stejnou funkci mohou podporovat různé struktury a mechanismy práce. Existují tři typy architektury:

1. Tradiční pokusy o vytvoření LCMS je poskytovat kritické datové přenosy na bázi bod-bod mezi různými aplikacemi. V tomto případě lze použít nějaký specializovaný systém podpory workflow (BPM engine, "business process management engine") nebo systém zpracování událostí (komplexní engine pro zpracování událostí). Bohužel se ukazuje, že množství práce spojené s poskytováním výměn mezi dvěma body je prostě obrovské: pokaždé jsou zapotřebí specialisté, kteří rozumí jak systémům, které mají být připojeny, tak metodě přenosu informací.
2. Použití standardu integrace dat životního cyklu ISO 15926 podle metody "ISO 15926 mimo", kdy je adaptér vyvinut pro každou inženýrskou aplikaci do neutrální reprezentace, která odpovídá normě. Všechna data tak dostanou příležitost setkat se v nějaké aplikaci a lze mezi nimi odhalit kolizi - ale aplikace potřebuje vyvinout pouze jeden adaptér pro přenos dat, nikoli několik takových adaptérů (podle počtu dalších aplikací, se kterými je nutné k zajištění komunikace).
3. PLM(Teamcenter, ENOVIA, SPF, NET Platform atd.) - používá se standardizovaná architektura s jedinou výjimkou, že datový model použitý v každém z těchto PLM je méně univerzální, pokud jde o odrážení jakékoli předmětové oblasti inženýrství, a také není neutrální a je k dispozici ve všech formátech. Takže použití ISO 15926 jako základu pro přenos dat do LCMS lze považovat za další rozvoj myšlenek skutečně implementovaných v moderním PLM.

Podle architektury správy konfigurace lze LCMS rozdělit do tří typů:

• "úložiště"(aktuální uložení všech projektových dat v jednom LCMS úložišti, kam se data kopírují z místa, kde byla vyvinuta),
• "Registrovat"(LCMS udržuje seznam adres dat životního cyklu v mnoha úložištích jiných CAD systémů, inženýrských simulačních systémů, PLM, ERP atd.),
• "hybridní architektura"-- kdy část dat je zkopírována do centrálního úložiště LCMS a část dat je dostupná z jiných míst prostřednictvím odkazů.

Architekt LCMS by měl také popsat:

• "portál"(včetně „webového portálu“), jeho funkce a způsob implementace. Samotná přítomnost portálu umožňuje uklidnit vrcholové manažery tím, že prokáže absenci konfliktů. Specifické požadavky jsou kladeny na architektonická řešení portálu LCMS.
• algoritmy kontroly integrity/konzistence datživotního cyklu a také popis fungování těchto algoritmů:
  • standardní modul v samostatné aplikaci, který pracuje s daty v úložišti této aplikace - ať už jde o CAD nebo PLM;
  • Software pro kontrolu kolizí speciálně vyvinutý pro LCMS, který má přístup k datům z různých aplikací umístěných v centrálním úložišti LCMS;
  • speciálně vyvinutý softwarový nástroj, který přistupuje přes internet přes zabezpečený kanál k různým datovým úložištím umístěným v různých organizacích;
  • speciálně naprogramované kontroly s kontrolou kolizí při načítání různých sad inženýrských dat do centrálního úložiště LCMS;
  • kombinace všech uvedených metod - různé pro různé typy kolizí; atd.
• způsob interakce uživatelů LCMS(projektanti, nákupčí, instalátoři, projektoví manažeři zařízení atd.) a jak software LCMS podporuje tuto interakci bezkolizním způsobem. Normy systémového inženýrství (zejména norma pro praxi systémového inženýrství ISO 15288) vyžadují volbu typu životního cyklu pro komplexní inženýrství objektů a údaj o tom, které možnosti praxe systémového inženýrství budou použity. Model životního cyklu je jedním z hlavních artefaktů, které slouží jako organizační opatření pro koordinaci práce organizace rozšířeného inženýrského projektu. Koordinovaná práce v průběhu kolaborativního inženýrství je klíčem k malému počtu konstrukčních kolizí. Jak přesně to bude model životního cyklu LCMS podporovat? PLM systémy tak obvykle nenacházejí místo pro modely životního cyklu a tím spíše pro modely organizace. Pro LCMS je proto nutné hledat jiná řešení softwarové podpory těchto modelů.
• Organizační aspekt přechodu na používání LCMS. Přechod na používání LCMS může způsobit výraznou změnu ve struktuře a dokonce i v personálním obsazení strojírenského podniku: ne všichni bagristé jsou považováni za bagry, ne všichni taxikáři jsou považováni za taxikáře.

Pro LCMS je hlavní, jak navrhované řešení přispívá k včasné detekci a dokonce i prevenci kolizí. Pokud jde o něco jiného (smysluplná volba typu životního cyklu v souladu s rizikovým profilem projektu, řízení stárnutí, řízení nákladů a reforma rozpočtu, zvládnutí axiomatického navrhování, stavba s dodávkami just-in-time, generování návrhu a konstrukce, a mnohem, mnohem víc, také nesmírně užitečné-moderní-zajímavé), pak je to věc jiných systémů, jiných projektů, jiných metod, jiných přístupů. LCMS by měl dělat svou práci dobře a ne špatně řešit obrovskou sadu libovolně vybraných cizích úkolů.

Architekt LCMS má tedy dva hlavní úkoly:

• zplodit řadu top kandidátských architektur a jejich hybridů
• provést výběr mezi těmito architekturami podle více kritérií.
  • smysluplná úvaha (smysluplnost výběrových kritérií)
  • prezentace výsledku (zdůvodnění).

Kritéria pro výběr architektonického řešení pro LCMS

1. Kvalita výkonu LCMS pro jeho hlavní účel: detekce a prevence kolizí Hlavním kritériem je: jak moc lze urychlit technický pokrok zrychlením detekce nebo zamezení kolizí pomocí navržené architektury LCMS? A pokud nelze zkrátit dobu práce, tak o kolik lze zvýšit množství práce za stejnou dobu se stejnými prostředky? Doporučují se následující metodiky:
   • Goldrattova teorie omezení(TOC, teorie omezení) – architektura by měla udávat, která systémová omezení odstraňuje na kritické cestě zdrojů inženýrského projektu (nezaměňovat s kritickou cestou).
   • ROI(návratnost investic) pro investice do LCMS ve fázi formalizace výsledku věcného přezkumu kandidátských architektur.
   Je důležité zvolit hranice zvažování: celkovou rychlost inženýrského projektu lze měřit pouze na hranici uvažovaného organizačního systému. Hranice jednoho právního subjektu se nemusí shodovat s hranicemi rozšířeného podniku provádějícího rozsáhlý inženýrský projekt a podnik účastnící se pouze jedné fáze životního cyklu může nesprávně posoudit jeho užitečnost a kritičnost pro celý životní cyklus. systému a zvolil špatný způsob integrace do LCMS. Pak se může ukázat, že vytvoření LCMS neovlivní celkové načasování a rozpočty projektu, protože ty nejnepříjemnější kolize budou nadále nové LCMS řešit.
2. Schopnost přijmout přírůstkový životní cyklus vývoje LCMS Inkrementální v ISO 15288 je takový životní cyklus, ve kterém funkčnost není uživateli dána najednou, ale po etapách – ale investice do vývoje také neprobíhají najednou, ale po etapách. Samozřejmě v tomto případě je třeba vzít v úvahu zákon klesající užitečnosti: každý přírůstek LCMS (každý nový typ kolizí zjištěný předem) je dražší a přínosy z něj jsou stále menší, dokud nebude vyvinut LCMS, která probíhá již mnoho let, sama odeznívá. Pokud se ukáže, že u některé z navrhovaných architektur je potřeba do tvorby LCMS investovat hodně peněz najednou, ale benefit lze získat okamžitě ve výši 100 % a až po pěti letech na klíč základ, pak je to špatná architektura. Pokud se ukáže, že je možné vyvinout a zprovoznit nějaké kompaktní jádro LCMS, a pak mnoho a mnoho modulů stejného typu pro různé typy kolizí s jasným mechanismem jejich vývoje (např. na základě použití tzv. ISO 15926), pak je to velmi dobré. Nejde ani tak o aplikaci „agilního vývoje“ (agilních metodologií), ale o poskytnutí modulární architektury LCMS a navržení plánu implementace prioritního seznamu modulů – nejprve nejnaléhavějšího, poté méně naléhavého atd. na. Nezaměňovat s ICM (model přírůstkového závazku), i když význam je zde stejný: lepší architektura, ve které můžete získat nějakou splátku za systém a získat potřebnou funkcionalitu co nejdříve - v aby dostal dávku (alespoň malou) dříve a opožděnou dávku zaplatil později.
3. Základní finanční a intelektuální schopnost ovládat a udržovat technologii Pokud spočítáme náklady nejen na samotný LCMS, ale také na veškerý personál a další infrastrukturu potřebnou pro realizaci projektu, pak musíme pochopit, kolik z těchto investic do vzdělávání, počítačů a organizačního úsilí zůstane plátce a vlastníka LCMS, a kolik se usadí venku - u mnoha dodavatelů, kteří samozřejmě budou vděční nejprve za získání "stipendia" na vývoj nové technologie a poté za podporu systému, který vytvořili. To nové je obvykle extrémně drahé a ne proto, že by bylo drahé samo o sobě, ale proto, že způsobuje lavinu změn, které způsobuje. Právě tento bod beru v úvahu celkové náklady na vlastnictví LCMS a stejný bod zahrnuje zvážení celého životního cyklu, již nikoli inženýrského systému s jeho odvratitelnými kolizemi, ale samotného LCMS.
4. Škálovatelnost architektury LCMS Toto kritérium je relevantní pro velké inženýrské projekty. Protože chcete, aby systém využívaly všechny tisíce zaměstnanců v rozšířené organizaci, bude se muset v tomto rozsahu rychle rozrůst. Do jaké míry může být „pilot“ nebo „polygon“ LCMS schopen rychle růst bez zásadních architektonických změn? S největší pravděpodobností nebudou moci růst. Architektonicky tedy nepotřebujeme „pilota“ nebo „polygon“, ale rovnou „první etapu“. Požadavek měřítka se těsně prolíná s požadavkem kritéria přírůstku, ale dotýká se trochu jiného aspektu - ani ne tak natažení tvorby LCMS v čase, ale možnosti natažení zakrytého objemu. Zkušenosti ukazují, že všechny systémy se vypořádají se zkušebními objemy návrhových dat, ale s těmi průmyslovými si neporadí. Jak porostou náklady na hardware a software nelineárně s růstem objemů / rychlosti? Jak dlouho se budou vypracovávat předpisy, když se ukáže, že nějakým pracovištěm projde více dat, než si může smysluplně prohlédnout jeden člověk? Špatná škálovatelnost může číhat nejen z technické stránky architektury softwarového a hardwarového řešení, ale také ze strany jeho finanční architektury. Nízká cena licence za místo v LCMS nebo dokonce malá cena za nové připojení na serveru úložiště tak může proměnit více či méně atraktivní řešení pro deset míst v absolutně finančně neudržitelné řešení pro cílových tisíc míst.
5. Schopnost řešit nevyhnutelné organizační problémy včetně postojů k oblíbeným starším systémům v rozšířené organizaci. Jak moc by navrhovaná centralizovaná nebo distribuovaná architektura vyžadovala „rozdat funkce jiným oddělením“, „rozdat naše data“ a obecně něco „rozdat“ ve srovnání se současnou situací bez LCMS? Sálové počítače masivně ztratily konkurenci minipočítačů a ty osobní. Neexistuje téměř žádná cesta zpět (k centralizovaným systémům, které LCMS nevyhnutelně představuje), protože všechna data jsou v samostatných aplikacích a tahání těchto dat do nových systémů je velmi náročný organizační úkol. Jak je strukturována architektura LCMS: nahrazuje současné starší inženýrské aplikace, staví na současné IT infrastruktuře, instalují ji „zdarma“ různé služby? Kolik organizačního/manažerského/konzultačního úsilí bude vyžadovat prosazení nové technologie? Kolik lidí propustit, kolik najít a najmout nové specialisty? Toto kritérium organizační přijatelnosti úzce souvisí nejen s centralizací/decentralizací, ale také se zohledněním motivačního systému v rozšířeném podniku, tzn. hodnocení architektury LCMS podle tohoto kritéria daleko přesahuje úzké zvážení samotného LCMS, ale vyžaduje důkladnou analýzu principů budování rozšířené organizace, včetně revizí principů, na nichž jsou založeny smlouvy, podle kterých je vytvořena. Ale to je podstata systémového přístupu: jakýkoli cílový systém (v tomto případě LCMS) je zvažován především nikoli „do hloubky, z jakých částí“, ale „směrem ven, součástí čeho“ – nikoli jeho návrh a mechanismus fungování jsou primárně zajímavé, ale podporované LCMS je funkce pro zamezení kolizí v externím supersystému - a cena, kterou je externí supersystém ochoten zaplatit za tuto novou funkci. Možné architektury LCMS se proto primárně neberou v úvahu z hlediska „použitých slušných technologií, například od dodavatele softwaru XYZ“ (toto je výchozí: všechny navrhované architektury jsou obvykle technologicky slušné, jinak nejsou možnostmi!), ale z hlediska výše uvedených pěti kritérií.

Funkce LCMS

1. Předcházení kolizím
   1. Správa konfigurace
      1. Identifikace (klasifikace, kódování)
      2. Konfigurační účtování (všechny možné základní linie - ConOp, Architecture, design, as built), včetně přenosu dat do úložiště LCMS, včetně podpory změn workflow, včetně podpory paralelního inženýrství (práce v podmínkách neúplných základních linií)
      3. Verze (včetně vidlic)
   2. Nedostatek ručního přenosu dat (přenos vstupních a výstupních dat mezi již existujícími automatizačními ostrůvky, včetně přenosu dat z ostrůvků „vzestupu na digitální“ starého konstrukčního vývoje)
   3. Konfigurace NSI
   4. Kolaborativní systém technické podpory (videokonference, vzdálené projektové sezení atd. – možná ne ten, který se používá k vytvoření samotného systému LCMS)
2. Detekce kolize
   1. Podpora registru kontrolovaných typů kolizí a kontrolních technologií odpovídajících registru
   2. Přenos dat pro kontrolu kolizí mezi automatizačními ostrůvky (bez montáže v úložišti LCMS, ale pomocí integrační technologie LCMS)
   3. Spuštění pracovního postupu pro kontrolu různých typů kolizí
      1. v úložišti LCMS
      2. nikoli v úložišti, ale pomocí integrační technologie LCMS
   4. Spuštění běhu pracovního postupu k vyřešení nalezené kolize (zasílání upozornění na kolize, protože běh pracovního postupu k vyřešení není záležitostí CLMS)
   5. Vedení aktuálního seznamu nevyřešených kolizí
3. Rozvoj(zde je LCMS považován za autopoetický systém, protože "inkrementální implementace" je jednou z nejdůležitějších vlastností samotného LCMS - jedná se tedy o funkci samotného LCMS, nikoli funkci podpůrného systému pro LCMS)
   1. Zajištění komunikace o vývoji LCMS
      1. Plánování práce pro vývoj LCMS (cestovní mapa, vypracování akčního plánu)
      2. Fungování projektové kanceláře LCMS,
      3. Vedení registru typů kolizních kontrol (samotný registr "Wishlist" a plán provádění kontrol)
      4. Organizační a technické modelování (Enterprise Architecture) pro LCMS
      5. Komunikační infrastruktura pro vývojáře LCMS (internetové konference, videokonference, správa znalostí atd. – možná ne ta, která se používá v kolaborativním inženýrství pomocí LCMS)
   2. Jednotnost technologie integrace dat (například technologie ISO 15926)
      1. Použití neutrálního datového modelu
         1. Podpora knihovny referenčních dat
         2. Vývoj referenčních dat
      2. Technologie pro podporu adaptérů na neutrální datový model
   3. Jednotný workflow/technologie integrace BPM (široký podnik)
4. Bezpečnost dat(v měřítku informačních systémů provozovaných v rámci LCMS)
   1. Zajištění jednoty přístupu (jedno přihlašovací jméno a heslo do všech informačních systémů účastnících se workflow)
   2. Správa přístupových práv k datovým prvkům
   3. Záloha

Carolyn Pampino (IBM)
Aplikační: Rational Team Concert Beta 3, Rational Quality Manager Beta 3, Beta 3

Posouzení

Tvrdá konkurence nutí mnoho organizací vytvářet produkty v kratším čase, přičemž je činí ještě inovativnějšími. Vývoj softwaru sám o sobě je složitý úkol, proto jsou systémy vytvářené organizacemi vyvíjejícími informační systémy a zařízení také extrémně složité. Týmy v napjatých termínech tak musí činit bez obětování kvality nebo navýšení rozpočtu. K tomu by jejich strategií mělo být zlepšení efektivity vývoje softwaru. Řešením tohoto dilematu je zlepšit interakce životního cyklu prostřednictvím správy životního cyklu aplikací (LCM).

Řešení pro správu životního cyklu aplikací, navržená pro podporu projektů vývoje softwaru, koordinují lidi, procesy a nástroje v iterativním cyklu vývoje softwaru, který zahrnuje související činnosti plánování, řízení změn, definování požadavků a řízení, správu architektury, správu konfigurace softwaru, sestavení a nasazení. automatizace, řízení kvality. Kromě hlavních funkcí řešení LCA zahrnují sledování mezi artefakty životního cyklu, definici a zajištění procesu a reporting.

Nejdůležitější výhodou řešení PLC je schopnost koordinovat lidi, procesy, informace a nástroje zapojené do projektu za účelem vytvoření inovativních produktů pro účastníky projektu. Protože neexistuje žádné univerzální řešení, doporučujeme našim klientům, aby se při implementaci správy životního cyklu, které nejlépe vyhovuje kultuře a prostředí jejich organizace, zaměřili na následující zásady:

• Používejte plánování v reálném čase;
• Poskytování sledování životního cyklu souvisejících artefaktů;
• Poskytovat příležitosti pro interakci v kontextu;
• Aplikujte obchodní analytiku pro vývoj;
• Implementujte neustálé zlepšování v procesu vývoje.

Plánování v reálném čase

Plánujeme, protože chceme dosáhnout určitého cíle a chceme vědět, kdy bude dosaženo. Existuje pouze jeden způsob, jak zjistit, kdy je práce hotová. K tomu je nutné zajistit, aby plány byly plně integrovány s realizací projektu a byly vždy aktuální. Následující tabulka uvádí několik typických plánovacích činností, které byste měli nebo neměli dělat.

Následující obrázek ukazuje, jak rychlá aktualizace stráveného času přímo z pracovní položky usnadňuje udržování přesných plánů.

Rýže. 1. Aktualizace stráveného času z pracovní položky udržuje plány přesné

Následující tři obrázky ukazují různé pohledy na stejný iterační plán. Používání pohledů pomáhá týmu vyvážit práci, efektivně plánovat a rychleji reagovat na změny.

Rýže. 2. Zobrazení naplánovaného času ukazuje, kdy mají někteří členové týmu více práce než ostatní

Rýže. 3. Elektronický pohled na pracovní desku mohou využívat flexibilní týmy umístěné geograficky

Rýže. 4. Zobrazení plánu rozvoje zobrazuje rozložení úkolů podle dne a týdne tradičnějším způsobem

Obrázek níže ukazuje plán vydání v Rational Team Concert s odkazy na související produktový backlog, kolekce požadavků v Rational Requirements Composer a plán testování v Rational Quality Manager.

Rýže. 5. S plánováním jsou spojeny soubory požadavků a testovacích plánů.

Řešení kolaborativní správy životního cyklu IBM Rational zahrnuje plně integrované plánování v reálném čase.

Stopa životního cyklu

Sledování není další příjemná funkce v životním cyklu vývoje softwaru. Sledování vám pomůže pochopit, co dělají všichni ostatní v týmu. Například analytik požadavků dobře ví, jaké požadavky napsal, ale také potřebuje vědět, zda bude konkrétní požadavek zohledněn v určité vývojové iteraci, a pokud ano, v jaké. Nebo chce vědět, zda byla implementace tohoto požadavku testována a jaký je výsledek.

Řešení PLC, které umožňuje trasování mezi artefakty životního cyklu, pomáhá týmům odpovídat na složité otázky o stavu jejich projektu. Vytváření vazeb mezi artefakty usnadňuje týmům odpovídat na otázky typu: "Které požadavky jsou ovlivněny defekty?" a "Které pracovní položky jsou připraveny k testování?"

Rýže. 6. Důležité otázky zodpovězené řešením LCA

Trasování pomáhá každému členovi týmu pochopit, co dělá zbytek týmu a jak to ovlivňuje rozsah práce jako celku. Pokud pracujete v externě omezeném prostředí, trasování vám pomůže odpovědět na otázky auditorů, jako například „Jaké změny jsou zahrnuty v tomto sestavení, jaké testy byly spuštěny as jakým výsledkem?“

Níže jsou uvedena typická, co dělat a co nedělat související se sledováním:

Obrázek níže ukazuje zobrazení trasování pro plán vydání, který obsahuje odkazy na požadavky a testovací případy. Plán má také sloupec pro zobrazení vad, které ovlivňují prvky plánu. Toto je příklad integrovaného plánu s informacemi o sledování. Na rozdíl od zastaralých, pravidelně generovaných zpráv o trasování se při použití integrovaného plánu s vestavěným zobrazením trasování absence artefaktů stává zřejmou a v projektu ji lze snadno odstranit.

Rýže. 7. Plán vydání zahrnující vývoj, požadavky a testování

Když jsou vytvořena propojení trasování, IBM Rational Collaborative Lifecycle Management automaticky vytvoří propojení trasování na základě defektů zjištěných během testování. Obrázek níže ukazuje defekt s vytvořenými směrovacími odkazy. Když během testování přidáte defekt, automaticky se vytvoří sledovací odkazy defektu na výsledky testu, testovací případ, plán testování, položku plánu a požadavek.

Rýže. 8. Odkazy životního cyklu automaticky generované pro testovací případy zobrazení defektu, prvky plánu a požadavky, které jsou jím ovlivněny

Interakce v kontextu

Interakce se neomezuje pouze na udržování přátelských a pracovních vztahů. Interakce zlepšuje kvalitu a přidává hodnotu zúčastněným stranám, což znamená, že interakce je důležitá pro inovace. Příležitosti pro spolupráci v řešení LCA mohou zlepšit schopnost členů týmu vzájemně komunikovat, reagovat na změny a přispět k předvídatelnosti projektu.

Nástroje pro spolupráci také pomáhají týmům soustředit se na to, na čem záleží. Týmy by měly hledat jakékoli příležitosti k automatizaci manuálních a nekreativních úkolů. Dobré řešení PLC zahrnuje automatizaci pro sestavení a provádění testů, ale mělo by také zahrnovat automatizaci pro hlášení stavu a přístup k informacím. Projektové řídicí panely a osobní řídicí panely hrají důležitou roli při automatickém poskytování informací týmu, které potřebuje, poskytují týmu viditelnost a přístup k aktuálním datům prostřednictvím týmových zpráv a dotazů. Dobře navržené uživatelské rozhraní automatizuje přístup k informacím tím, že poskytuje informace přímo uživatelům, aniž by je nutilo „změnit kontext“ přepnutím na jinou aplikaci. V této podobě automatizace přímo přispívá k lepší interakci.

Obrázek níže ukazuje sadu panelů dashboard s moduly widget obsahující informace z Rational Team Concert, Rational Requirements Composer a Rational Quality Manager. Data na dashboardech zobrazují aktuální stav projektu.

Rýže. 9. Dashboardy s daty z různých zdrojů zajišťují transparentnost práce pro všechny funkční týmy

Obrázek níže ukazuje mini-dashboard, který je vždy k dispozici na straně uživatelského rozhraní a lze jej ukotvit vlevo nebo vpravo. Funguje jako personalizovaný mini dashboard, který uživatele sleduje celým řešením LCA a lze jej kdykoli skrýt nebo zobrazit.

Rýže. 10. Mini panel přístupný odkudkoli v uživatelském rozhraní

Následující obrázek ukazuje osobní minibar v Rational Team Concert. Tento panel obsahuje widget, který zobrazuje změny požadavků v Rational Requirements Composer. Toto je příklad minipanelu s informacemi z různých zdrojů. Když najedete kurzorem na požadavek, zobrazí se náhled s informacemi o stavu požadavku ve Skladateli požadavků. Uživatelé, kteří potřebují rychlý přístup k informacím, si na minipanely rychle zvyknou.

Business intelligence pro rozvoj

Jak poznáte, že se něco zlepšuje, když nedefinujete metriky úspěchu? Dokážete v kterémkoli okamžiku projektu říci, zda tým směřuje k úspěšnému výsledku? Identifikace oblastí, které potřebují zlepšení, stanovení cílů, sledování pokroku směrem k těmto cílům je to, co pomáhá rozvíjet business intelligence pro rozvoj.

Podle Capers Jones 1 jsou projekty, které široce využívají postupy měření, mnohem úspěšnější než ty, které je nepoužívají.

Rýže. 12. Projekty, které využívají postupy měření, mají větší šanci na úspěch

Například následující tři metriky používá méně než 50 % výzkumných organizací Capers Jones:

• Metriky kvality 45 %
• Metriky produktivity 30 %
• Metriky připravenosti 15 %

Obrázek níže ukazuje sestavy pro vývojový tým na řídicím panelu projektu. Když je pracovní položka aktualizována, sestavy odrážejí aktivitu a směr týmu. Pomocí grafů postupu můžete sledovat pokrok svého týmu směrem k dokončení naplánované práce. Nebo použijte grafy, které ukazují změnu počtu pracovních položek ve stavech „Otevřeno“, „Probíhá“ a „Uzavřeno“ (v ideálním případě počet položek ve stavech „Otevřeno“ a „Probíhá“ by měly klesat, zatímco ty v "Uzavřeno" - růst).

Rýže. 13. Dashboard se zprávami a metrikami pro měření zlepšení

Dashboardy a reporty jsou klíčovou součástí řešení LCA, zodpovědné za měření a reakci na aktuální pokrok týmu.

Neustálé zlepšování procesu vývoje

Proces je více než zdokumentovaný soubor činností. Vyvíjíme procesy založené na osvědčených postupech čerpaných z průmyslových zkušeností jako prostředek ke zlepšení týmové komunikace a zvýšení šancí týmu na úspěch. Chování je do značné míry dáno zvykem. Když definujete nebo měníte proces, efektivně žádáte celý tým, aby změnil své návyky a přijal chování, které jim nemusí být na první pohled jasné. Je docela těžké změnit návyky jednoho člověka. Změna procesu často vyžaduje změnu způsobu myšlení a chování lidí. Dobře navržené řešení LCM vám umožňuje postupně měnit proces, zlepšovat dynamiku týmu a pokračovat ve směřování k vyšší efektivitě.

Při analýze vývoje trhu s vývojovými nástroji za posledních 10-15 let lze zaznamenat obecný trend přesouvání důrazu od technologií skutečného psaní programů (které byly od počátku 90. let poznamenány vznikem nástroje RAD - "rychlý vývoj aplikací") na potřebu integrovaného správa celého životního cyklu aplikací - ALM (Application Lifecycle Management) .

S rostoucí složitostí softwarových projektů prudce rostou požadavky na efektivitu jejich implementace. To je o to důležitější dnes, kdy se vývojáři softwaru podílejí na téměř všech aspektech práce podniků a počet takových specialistů roste. Data z výzkumů v této oblasti přitom naznačují, že výsledky minimálně poloviny „in-house“ projektů vývoje softwaru neopravňují naděje do nich vkládané. Za těchto podmínek se stává obzvláště naléhavým úkolem optimalizace celého procesu tvorby softwarových nástrojů s pokrytím všech jeho účastníků – designérů, vývojářů, testerů, podpůrných služeb a manažerů. Správa životního cyklu aplikací (ALM) nahlíží na proces vydávání softwaru jako na neustále se opakující cyklus vzájemně souvisejících fází:

definice požadavků (Requirements);

návrh a analýza (Design & Analysis);

Vývoj (vývoj);

testování (Testování);

nasazení a údržba (Deployment & Operations).

Každý z těchto kroků musí být pečlivě sledován a kontrolován. Správně organizovaný systém ALM vám umožňuje:

Zkrátit dobu potřebnou k uvedení produktů na trh (vývojáři se musí postarat pouze o to, aby jejich programy byly v souladu s formulovanými požadavky);

zlepšit kvalitu a zároveň zajistit, že aplikace bude splňovat potřeby a očekávání uživatelů;

zvýšit produktivitu (vývojáři dostanou příležitost sdílet osvědčené postupy při vývoji a implementaci);

Urychlit vývoj pomocí integrace nástrojů;

· snížit náklady na údržbu neustálým udržováním konzistence mezi aplikací a její projektovou dokumentací;

Získejte maximum ze svých investic do dovedností, procesů a technologií.

Přísně vzato, samotný koncept ALM samozřejmě není něčím zásadně novým - takové chápání problémů tvorby softwaru vzniklo asi před čtyřiceti lety, na úsvitu formování metod průmyslového rozvoje. Až do relativně nedávné doby však hlavní úsilí v automatizaci úloh vývoje softwaru směřovalo k vytváření nástrojů přímo pro programování jako časově nejnáročnější fáze. A teprve v 80. letech se kvůli komplikaci softwarových projektů začala situace výrazně měnit. Zároveň prudce vzrostla relevance rozšiřování funkcionality vývojových nástrojů (v širokém slova smyslu) ve dvou hlavních oblastech: 1) automatizace všech ostatních fází životního cyklu softwaru a 2) integrace nástrojů s navzájem.

Těmito úkoly se zabývalo mnoho společností, ale nesporným lídrem zde byl Rational, který se již více než dvacet let od svého vzniku specializuje na automatizaci procesů vývoje softwaru. Svého času se právě ona stala jedním z průkopníků širokého využití vizuálních metod pro navrhování programů (a prakticky autorkou jazyka UML, akceptovaného de facto jako standard v této oblasti), vytvořila společnou metodiku ALM a odpovídající sadu nástrojů. Dá se říci, že na začátku tohoto století byl Rational jedinou společností, která měla ve svém arzenálu celou řadu produktů na podporu ALM (od business designu po údržbu), ovšem s výjimkou jedné třídy nástrojů - běžné kódovací nástroje. V únoru 2003 však přestala existovat jako nezávislá organizace a stala se divizí IBM Corporation s názvem IBM Rational.

Rational byl donedávna prakticky jediným výrobcem integrovaných vývojových nástrojů třídy ALM, i když pro určité fáze vývoje softwaru existovaly a existují konkurenční nástroje jiných výrobců. Svůj záměr konkurovat jí však před pár lety veřejně oznámila společnost Borland Corporation, která měla vždy silnou pozici na poli tradičních nástrojů pro vývoj aplikací (Delphi, JBuilder atd.), které jsou vlastně základem tzv. korporační komplex ALM, který byl akvizicí rozšířen o další společnosti vyrábějící obdobné produkty. To je zásadní rozdíl mezi obchodními modely obou společností, který otevírá potenciální příležitosti pro skutečnou konkurenci. Poté, co se Rational stal součástí IBM, se Borland dnes staví jako jediný nezávislý dodavatel komplexní platformy ALM (to znamená, že nepropaguje vlastní operační systémy, jazyky atd.). Konkurenti zase poznamenávají, že Borland dosud neformuloval jasnou metodologii ALM, která by poskytovala základ pro kombinaci nástrojů, které má.

Dalším významným hráčem na poli vývojových nástrojů je Microsoft Corporation. I když nevyhrožuje vytvořením vlastní platformy ALM; propagace v tomto směru je pouze v rámci spolupráce s dalšími dodavateli, stejnými Rational a Borland (oba se stali prvními účastníky programu Visual Studio Industry Partner). Vlajková loď vývojového nástroje Visual Studio .NET od Microsoftu zároveň neustále rozšiřuje funkcionalitu díky použití nástrojů pro modelování a řízení projektů na vysoké úrovni, včetně integrace s Microsoft Visio a Microsoft Project.

Je třeba poznamenat, že dnes téměř všechny přední společnosti vyvíjející technologie a softwarové produkty (kromě výše uvedených, lze jmenovat Oracle, Computer Associates atd.) mají pokročilé technologie vývoje softwaru, které byly vytvořeny jak samy o sobě, tak nákupem produkty a technologie vytvořené malými specializovanými firmami. A přestože stejně jako Microsoft zatím neplánují vytvořit vlastní platformu ALM, nástroje CASE vydané těmito společnostmi jsou v určitých fázích životního cyklu softwaru široce používány.

Systémy ALM vám umožňují poskytnout transparentnost, jasné pochopení procesu vývoje aplikací a prezentovat jej jako jeden z obchodních procesů. Analytici však varují, že ALM by nemělo být chápáno pouze jako prostředek sledování a kontroly dodržování předpisů. Tyto systémy nejsou určeny ani tak pro řízení, jako spíše pro automatizaci procesu vývoje a integraci různých nástrojů.

Největším problémem při implementaci nástrojů ALM jsou lidé, kteří nerozumí procesu vývoje. Vedení často předpokládá, že ALM bude schopen dělat věci dobře definovaným způsobem. Není však možné plánovat vše dopředu. Při vývoji aplikací je často nutné v každém kroku projít několika iteracemi, vydat meziverze a postupně zvyšovat funkčnost aplikace. Systém ALM by neměl omezovat činnost vývojářů, ale usnadňovat proces.

IT průmysl rád mluví o překážkách mezi IT a byznysem, ale uvnitř samotné IT organizace existuje mnoho méně viditelných překážek, které mohou neopatrnému systémovému integrátorovi překážet.

Vezměme si například jedno z nejkontroverznějších a nejdiskutovanějších témat současnosti v IT – metodologii DevOps a vše, co s ní souvisí. Jako stručný popis všech úkonů spojených s předáním vyvíjené aplikace do IT služby k reálnému provozu zní tato slova dostatečně neškodně. Celkově však mezi vývojáři podnikových aplikací a specialisty spravujícími podnikovou IT infrastrukturu existuje zeď nedorozumění. Programátoři často obviňují IT z nedostatku flexibility a lidé, kteří řídí každodenní IT operace, ignorují omezení a požadavky produkční infrastruktury, na které musí aplikace, které vytvářejí, běžet.

Toto napětí podněcuje rostoucí zájem o technologii Application Lifecycle Management. ALM), což je sada ovládacích prvků, které mají programátorům a IT pracovníkům poskytnout jasnější představu o povaze vyvíjené aplikace a infrastruktuře, na které musí aplikace běžet. Hlavní myšlenkou je, že usnadnění spolupráce mezi vývojáři a IT profesionály povede k efektivnějšímu fungování celého podnikového informačního prostředí. Problém je v tom, že implementace ALM má malou šanci v situaci, kdy dvě strany, jejichž spolupráce je pro úspěch projektu nezbytná, začnou přesouvat odpovědnost za vzniklé potíže na sebe navzájem.

Pro úspěšnou implementaci metodiky ALM se systémový integrátor musí povznést nad úroveň rekriminace v IT oddělení. Podle Giny Poole, viceprezidentky marketingu divize Software IBM Rational, to znamená najít a najmout IT ředitele nebo finančního ředitele, který pochopí, o kolik peněz zákazník přichází kvůli nekoordinované práci všech služeb IT oddělení. Oprava chyb v aplikaci pozdě ve vývojovém projektu znamená extrémně vysoké náklady. Pokud je potřeba takové nápravy způsobena předchozími předpoklady vývojáře o prostředí, ve kterém bude aplikace fungovat, a tyto předpoklady se nakonec ukážou jako nesprávné, pak cena celého projektu výrazně narůstá, případně zákazník bude nucen odpovídajícím způsobem modernizovat svou infrastrukturu.

Řešení takových rozporů v IT infrastruktuře organizace může samozřejmě stát značné množství peněz. Jediným konečným cílem této práce by však mělo být vytvoření a implementace sady technologií pro správu, které umožní programátorům a specialistům na provoz IT přestat si vzájemně zasahovat do práce. Čím více času programátoři stráví diskusí o spolupráci s IT, tím méně času mají na skutečný vývoj. Čím více aplikací bude vytvořeno, tím pokročilejší infrastruktura bude potřeba a to je samozřejmě dobrá zpráva pro prodejce.

Obecně je debata o DevOps pro prodejce a integrátory rozhodně přínosná. Problémem je nenechat se zatáhnout do vnitřních konfliktů s tím, že chceme paralelně provozovat příliš mnoho IT projektů. Pokud zákazník neakceptuje samotný koncept ALM, je to vlastně velmi dobrý indikátor jeho nevyspělosti a slabé kompetence v řízení IT. To samo o sobě naznačuje, že pro prodejce je lepší držet se od takového zákazníka dál, protože je vysoce pravděpodobné, že takový zákazník přinese více problémů než zisků.