1 Zavedení Jak instalovat a zavádět Na koho se obrátit Pozor •Zavedení je společná práce –Manažerů dodavatele – zajistí dodávku systému – Manažerů odběratele – zajistí lidi, prostředky, organizaci na místě –Expertů resp uživatelú obou stran 3 Zavedení informačního systému •Předání (instalace, předávací testy, zkušební provoz) •Školení pracovníků –Spoluúčast tvůrců (nebývají ale pedagogicky zdatní, nevyužívá se jejich odbornost) –Vhodní jsou dobří lektoři, dokonce specializované firmy •Plánování přechodu –Konverze dat Postup překlopení –Vhodné je inkrementální zavádění, lze-li. Podmínkou je vhodná architektura. –Je vhodné stanovit kriteria úspěchu zavádění 4 Dokumenty při zavádění •Vize systému a specifikace požadavků •Návrh a zdrojové texty (nedělá-li dodavatel údržbu) •Dokumenty o testech, případně deník projektu •Manuály •Dohoda o zkušení době a procedurách odstraňování chyb •Záruky a rizika 5 Křivka učení a typy uživatelů 6 Křivka učení a typy uživatelů 7 Koho získat jako spojence •Inovátoři jsou motivováni novinkami, nikoliv zlepšováním své práce, –Nemívají prestiž mezi spolupracovníky, nerozumí jejich potřebám –Brzy ztrácí zájem •Časní osvojitelé chtějí zlepšovat svou práci a noviny při tom vítají, mívají vysokou reputaci u uživatelů, to jsou ti praví spojenci •Časná většina inovace spíše vítá, ale chce mít svůj klid • 8 Křivka učení •Nemá být příliš strmá (intensita učení příliš vysoká) ani příliš plochá •Je nutné zvládání chápat jako učení, je to tedy specifický úkol a je proto třeba zajistit –Kvalitní vyučující –Čas, pomůcky a prostředí –Hodnocení pokroku („známkování“) •Často se to podceňuje 9 pro jednu osobu 10 Křivka učení a typy zvládání 11 12 13 14 Údržba I instrukce se z logického pohledu (potřeb) opotřebují 15 Druhy údržby, opakování •Corrective odstranění defektů, které nebyly detekovány oponenturami a testováním, vlastně ty, na které nebyl čas ani prostředky •Enhancive – vylepšování •Adaptive – přizpůsobování změnám platformy, přenos, změny norem 16 Corrective maintenace Model průběhu velikosti týmu a tedy intensity práce, starší varianta 17 Corrective maintenace Rychlý pokles?! Nepozoruje se Pro t>3 je velikost týmu prakticky nula Þ není co dělat, nebyla by corrective maintenance, to se nepozoruje. Pravidlo polovin: ve vrcholu jsem v půli se spotřebou práce i s dobou řešení, to je příliš optimistické 18 Corrective maintenance Zobecnit na t = aT+d Jsou důvody pro komplikovanější model Mnoho práce se vykoná i pro t >5, Posun vlevo lineární transformací nezávislé proměnné 19 Najímaný tým, vrchol a odhad doby řešení čas Osoby/max. velikost týmu Vlevo sešikmená funkce Pravidlo třetin. Do vrcholu 1/3 prací a 1/3 doby (za běžných okolností.Transformace proměnných tak, aby max bylo v bodě 1 a mělo hodnotu 1 a v nule byla hodnota funkce prakticky nula. U pevného týmu odpovídá intensitě práce Předání 1/4 1/4 1/4 1/4 Zákon třetin: maximum třetina doby do předání a třetina spotřeby práce do předání 20 Najímaný tým, vrchol a odhad doby řešení krirických systémů čas Osoby/max. velikost týmu Vlevo sešikmená funkce Ve vrcholu méně než 1/5 doby do předání a málo více než ¼ (0.277) prací Předání 3/8 1/4 1/4 1/4 Zákon pětin: maximum pětina doby do předání a pětina spotřeby práce do předání 1/10 21 Etapy údržby •Převzetí •Etapa investic –Corrective maintenance, prvá vylepšení a přizpůsobení •Etapa maximálního užitku –Vylepšení požadované uživateli –Regresní testy, stabilní provoz •Zmenšování užitku –Vylepšení pro další uživatele, zlepšování výkonu, roste počet problémů 22 Vanová křivka. I SW se opotřebí 23 Vanová křivka. I SW se opotřebí Záběh Záp. exp. Opotřebeno Stálá úroveň selhání – – – – – – – – – – – – – – – – – – 24 Dno vanové křivky implikuje nenulovou střední frekvenci selhání •Opravou se zanesou další chyby •SW se stále upravuje (vylepšuje, přenáší na nové platformy) a tím se zanáší problémy a další chyby, tím se údržba stává stále pracnější. –Za odstraněný defekt přibude často nový, někdy i více než jeden –Není proto možné zero defect software 25 Složitost údržby roste s časem, důvod stoupající větve vanové křivky Nakonec se to nedá udržet, je to nutné celé přepsat, to se stalo Příklad údržby OS IBM 360 Hlubší důvod k vyhození systému •Pozoruje se, že si systém zachovává své základní vlastnosti plynoucí z filosofie volby požadavků a technologie návrhu a vývoje •Nectnosti systému se spíše zviditelňují a zesilují filosofie zastarává, není „in“, •Platí to i pro jiné technické prostředky (nákladní auta) 27 Jednoduchá kontrola toho, zda došlo k opotřebení – Pravděpodobnosti výskytů 1% (překročení vlevo), a 0.0001% (několikanásobně vpravo) 28 Co se tím vlastně prokazuje •Je málo pravděpodobné (p << 0,001), že nedošlo k posunu střední hodnoty směrem nahoru, tj. je pravděpodobné, že k němu došlo (tak se testují statistické hypotézy) •Lze použít efektivnější prostředky mat. statistiky, např. t test –je účinnější a přesnější, není ale tak názorný a je proto méně vhodný pro on-line zásahy 29 Co snižuje pracnost údržby •Správné specifikace (správné požadavky ale také správná dekompozice ) •Vhodná architektura celku (SOA), Struktura částí (Objektová orientace, komponenty) •Převzetí existujícího (knihovny, produkty třetích stran existující domácí SW) •Správné procesy vývoje (inkrementálnost, agilnost) a kvalita dokumentace, kvalita oponentur a testů, normy •Přenositelné technologie (Java), normy, PaaS •Vývojové nástroje (menší rozsah dokumentů, srozumitelnost, podpora korektnosti oprav,…) • 30 Co snižuje pracnost údržby •Dobře vedené programování (Gunderloy) –Používám, co je napsáno (existující aplikace, produkty třetích stran, knihovny), normy –Používám moderní metodiky (OO, SOA, metanástroje jako XML a s ním spojené jazyky a DB) a vhodný jazyk –Agilní metody vývoje –Dohodnuté standardy •Komentáře, volby identifikátorů, pravidla strukturování, oponovaní, vývoj testů, …. – – 31 Co snižuje pracnost údržby •Kvalita technik údržby –Automatizace opakování testů –DB reklamací a defektů –Sledování trendů defektů (frekvence) –Sledování prapříčin, jaká chyba člověka je prvotní a které chyby jsou důsledkem – Použití logů komunikace přes uživatelské rozhraní a mezi komponentami (výhodné v SOA) a rozhraní • 32 Reinženýring •V podstatě kompletní přepsání systému jako jediná alternativa k jeho zrušení •Varianty –Enhansive, obvykle s novými funkcemi, nová architektura –Adaptive, změna platformy a jazyka či databáze –Vyjímečně větší spolehlivost (SLA) •Rizika: ovlivnění starými praktikami, neochota k žádoucím změnám, riziko, že to nestojí za to 33 Podíly pracnosti Údržba stojí podstatně více než vývoj (obvykle dvakrát více, to závisí na počtu uživatelů). U customizovaných systémů je podíl údržby pro jednotlivé instalace podstatně menší (platí se tím, že se zákazník musí přizpůsobovat Jaké techniky snižují pracnost údržby •Vždy: Kvalitní architektura, kvalitní specifikace, kvalitní vývojové prostředí •Corrective –Architektura SW, možnost agility –Moderní metody vývoje moderní vývojová prostředí, vodný jazyk •Adaptive –PaaS, nástroje nezávislé na platformě •Enhansive –SOA s hrubozrnným rozhraním, automatické testy, kvalitní specifikace – – 34 Jak se projeví SaaS, software as a service A také cloud computing Platform as a service Zatím ve fázi líbánek 35