1 Metody návrhu systému Jak pokračovat po specifikacích 2 Spolupráce třívrstvých komponent Semantic web 3 Spolupráce třívrstvých komponent •Spolupráce podle vrstev, –Logika je na aplikačním serveru, datová na datovém – – Uživatelské rozhraní Výkonná logika aplikace Datové služby, správa dat Databáze 1 Databáze 2 – – – Uživatelské rozhraní Výkonná logika aplikace Datové služby, správa dat Databáze3 Databáze 4 – Zprávy, XML Datové operace vyšší úrovně V SOA mohou být vrstvy tvořeny podsítěmi (pod SOA) Datové operace databázových systémů Databázově orientované systémy •Aplikace pracující nad stejnou DB •Aplikační vrstva zčásti pomocí uložených procedur •Nutná disciplina při vývoji, lze pak vytvořit systém, který se do značné míry obejde bez middlewaru (ten je nahrazen službami databáze) • Systémy propojené přes databázi 5 Uživatelské rozhraní Aplikační vrstva Datová vrstva Uložené procedury Uživatelské rozhraní Aplikační vrstva Datová vrstva Uložené procedury Databáze 6 Tři vrstvy a server OO usnadňuje posun rozhraní (srv. connectors) 7 K SOA 8 K SOA, základní sestava 9 10 Middleware Architekturní služby fungují jako rozšíření middleware, architekturu jako službu, agilní vývoj a agilní byznys procesy 11 Hlavní výhody SOA •Znovupoužití existujících a cizích aplikací •Autonomní vývoj částí •Inkrementální vývoj •Modifikovatelnost a udržovatelnost •Umožnění principů agilního vývoje ve velkých systémech •Cesta k softwaru jako high tech 12 Některé nevýhody SOA •Sekvenční zpracování je nutné zajišťovat – Řešení: Odpovím určené službě – Mohu čekat na odpověď – Identifikátor zprávy na kterou se odpovídá a nebo vratný parametr (identifikuje odkud pokračovat) •Nejasné jak efektivně spoluopracovat se SOAP a obecně jak optimálně aplikovat to nejlepší z objektové orientace •Obtížné přijetí filosofie SOA • 13 Jaksonova metoda •Je vhodná pro sekvenční dávkové zpracování uspořádaných souborů •Základní princip: –Logiku mnohých programů lze odvodit z toho, jak se zpracovává soubor •Akce na začátku nebo ří změně klíče (pohyby na daném účtu) •Varianty zpracování vět • Akce na konci seznamu pro daný klíč –Lze opakovat při změně hodnoty klíče 14 Jaksonova metoda •Je vhodná pro vývoj jednotlivých procesů v diagramu toků dat •V jistém smyslu obdoba objektové orientace pro dávkové systémy 15 Jaksonova metoda 16 Jaksonova metoda Často lze strukturu programu odvodit z dekompozice činností, vhodné pro dávkové zpracování 17 Dataflow 18 Dataflow, funkcionální dekompozice Prvky DFD v SOA a cloudu •Datové úložiště se zapouzdří jako služba •Rozhraní dávkoé (bulk) i interaktivní) 20 Odvozená hierarchická dekompozice 21 Diagram kontextu. Dají se použít Use Case 22 Výhody a nevýhody •Vhodnější pro dávkové zpracování, tam ale významem obdoba SOA pro interaktivní spolupráci •Pokud je možné použít, může podstatně usnadnit vývoj a modifikace využitím úložišť •Nevýhoda je, že může omezit použití on-line operací •Je možná kombinace úložišť a komunikace výměnou zpráv,to je zvláště vhodné pro manažery, viz Generalized Petri Places 23 Rozhodovací tabulky •Umožňuje přehledně zapsat, za jakých podmínek učinit příslušnou akci/akce •Do horního pole se zapisují požadované pravdivostní hodnoty jednotlivých podmínek (ano A, ne N, na podmínce nezáleží X) •Do dolního pole se zapisuje značkou x, zda se má příslušná akce pro kombinaci podmínek uvedenou v horní části sloupce provést 24 Rozhodovací tabulky 25 Rozhodovací tabulky •Vhodné spíše pro dávky a menší úlohy •Osvědčuje se pro vyjasnění všech možností •Podmínek nesmí být příliš mnoho •Spíše jen okrajová metoda •Použitelné při specifikaci požadavků i při návrhu systému •Používá se v podnicích 26 Modely pro specifikaci požadavků • Aktor • Případ použití 27 Případy použití 28 Případy použití •Lze použít pro jednotlivé služby (mají-li uživatelsky orientované rozhraní, to by ale mělo být pravidlem,neboť jinak nemá SOA žádoucí vlastnosti) i pro celé SOA •Měly by být specifikovány v jazyce uživatele a pak zpřesněny pomocí diagramů, k diagramům přecházet až když jazyk uživatele není dostatečně přesný •Je výhodné použít pojmy z objektové orientace 29 Případy použití •Mezi aktory může existovat vztah dědění – vedoucí skladu dědí akce skladníka •Mezi případy použití jsou vztahy – používá – rozšiřuje (podobné vztahu dědění) • 30 Pracovní tok 31 Pracovní tok •Vhodné pro popis návaznosti činností, spíše na úrovni systému •Blízké k pracovním tokům ve smyslu podnikových procesů •Rozsáhle zobecněno v UML a v různých variantách specifikace pracovních toků. Zobecnění hlavně v oblasti paralelity (souběh, vzájemné vyloučení, následnost) 32 Pracovní tok 33 Pracovní tok, scénář 34 Pracovní tok, spolupráce komponent •Vhodné pro popis systému dekomponovaného do komponent spolupracujících prostřednictvím výměny zpráv •Vhodné i pro vývoj SOA systémů •Vhodné pro scénáře spolupráce lidí i SW komponent •Existuje několik variant, včetně té, která mýsto komponent používá jednotlivé třídy 35 Pracovní tok, UML Ok/ne 36 Příklad diagramu aktivit • activityDiagramDistributeSchedules 37 Diagramy aktivit 38 Diagramy aktivit 39 40 41 42 43 Activity diagram 44 Diagram aktivit •Diagram aktivit je prostředkem definování částečně paralelních aktivit v OO •Všimněme si rozdílu přístupu SOA a OO – SOA – služby běží paralelně a jejich synchronizaci je nutné nějak zařídit – v OO je naopak nutno programovat paralelitu 45 Signatury 46 Koordinace činností (UML) 47 Koordinace činností (UML) 48 SADT Structured Analysis and Design Technique •Starší systém, spíše pro dávky •Vychází z IDEF norem živých v průmyslu při specifikaci podnikových procesů •Dnes zřídka používaný 49 SADT (IDEF0 až IDEF3) 50 SADT (IDEF0 až IDEF3) 51 SADT (IDEF0 až IDEF3) 52 SADT (IDEF0 až IDEF3) 53 Kolik investovat do nástrojů •Kolik dávat do „neproduktivních“ činností, takových, jejichž výstup není částí projektu – HW – Podpůrný SW –Nástroje •Kupované •Vlastní –Vzdělávání lidí 55 Etapy zvládání nové metodiky •Líbánky –Metodika se používá v oblastech, pro které byla především vyvinuta, tam se osvědčuje –Pracují s ní kvalitnější lidé, kteří se snaží touto cestou získat slávu, nejsou komerční nástroje velkých výrobců •Vystřízlivění –Nehodí se na vše, výrobci SW jsou stále opatrní, náraz na meze –Má mouchy (implemetační, metodické) –Vužaduje zaškolení a změnu návyků (to někdy až při změně generace vývojářů, viz objektovou orientaci) –Inovátoři se zajímají o nové hity •Soužití (ne vždy k němu dojde) –Většina nedostatků se odstraní –Systém používají stálí uživatelé a ti si s problémy nějak poradí, nebo si na ně zvyknouPřibývá komerční podpora od velkých firem a výuka na školách –Časem dojde k ustálenému stavu (plató) – 56 Modernost metodiky •Nezapomínat na rozumnou opatrnost •Ale také nezapomínat, že risk je zisk •Nové zkoušet na menších projektech a nasadit na to kvalitní pracovníky •To platí i pro každé nové nástroje a programovací jazyky • 57 Řízení konfigurace • Dosáhnout toho, aby byly vyvinuty, prověřeny a do celku se dostaly komponenty (prvky konfigurace), které pro danou verzi výrobku patří k sobě •Obecně technický problém • ISO10007 – obecně řízení konfigurace • ISO 12207, ISO 90003, ISO 15846, ISO 20000 – software process •Jsou normy i pro Plán řízení konfigurace 58 Řízení konfigurace • Stanoví se (někdy v etapách) prvky konfigurace, každý prvek má jméno a id, který určuje, do které konfigurace patří •Prvky projdou cyklem od zadání k převzetí •Správa konfigurace hlídá, zda jsou prvky k dispozici, tj. zda prošly i řádným vývojem a byly prověřeny •Do konfigurace (verze) x.y.z.w patří prvky se jménem v seznamu a z těch s id mající nejdelší společný prefix s id konfigurace 59 Projekt Provoz – DB přijatých požadavků DB jmen prvků Požadavky na změny Požadavky na změny Požadavky na změny Požadavky na změny – Vymezení konfigurace – Zadání úkolů – Akceptace – Vytvoření konfigurace – Instalace DB přijatých požadavků Seznam prvků Přijaté prvky Systém Prvky k přijetí Protokoly 60 Kódování Psaní programu podle přesných specifikací Člověk jako kompilátor 61 Kódování •Kódování není dnes hlavní problém •Jedna sedmina pracnosti vývoje a pracnost kódování se dále zmenšuje –Ví se, jak na věc a jak to učit a standardizoat –Systémy podpory programování (vizuálnost, CASE, Delphi, Power Builder, …), asi nevhodné pro SOA –Servisní orientace, objektová orientace, komponent –Problém je ve specifikacích, to je úzké místo, kódování nikoliv •Při kódování je výhoda mládí. Nebezpečí, že se mladí omezí na kódování a nic dlouhodobějšího se nenaučí 62 Programovací jazyky •Jsou méně důležité, než se má za to, úzké hrdlo je jinde (Prof.Malík simuloval lidské srdce ve Fortranu, ač se tento jazyk pro to nehodí, stálo ho to dva měsíce práce, koncepce byla dobrá díky jazyce Simula, jazyka pro programování simulací. Simulátor byl totiž nejprve napsán v jazyce Simula .Simulátor se používal při testech správnosti aplikace kardiostimulátorů a jejich vylepšování) •Nejen vlastnosti jazyka, ale také vývojového prostředí, včetně knihoven a hotových částí, zásuvné moduly • Důležité, jak se jazyk uplatní v podpoře SW architektur (COBOL a dataflow diagramy pro dávkové výpočty) •Nový jazyk se zpravidla uplatní jen, je-li určen pro volnou niku na trhu (Java pro webové stránky, srv. FORTRAN kontra Algol či PL/1) •Znalosti vývojářů závisí na jazyce a s ním spojenými nástroji a metodikami • 63 Testování •Součást evaluace (ověřování), zda produkt odpovídá potřebám uživatelů •Nejpracnější etapa vývoje •Jde automatizovat jen zčásti. Důvody: –Testuje se i správnost specifikace a ta je fuzzy a mění se v čase, blokované znalosti –Nutné testovat předpoklady o schopnostech a potřebách uživatelů •To vyžaduje spoluúčast uživatelů 64 Testování •Mnohé problémy lze automatizovat jen zčásti i v případě dokonalých specifikací, jaké bývají u kritických aplikaci. –Důvody: Churchova téze, co nejde algoritmizovat na Turingově stroji, nelze vůbec, složitost reálného světa – ten není počítačem, je náhodný v principu (kvantová mechanika) – Algoritmicky nerozhodnutelné problémy při testování, na příklad •Detekce mrtvého kódu •Otestování všech kombinací návazností větví programu •Detekce nekonečného cyklu –Důsledek: Nelze plně automatizovat, tvůrčí problém, •Řeší se heuristicky, vždy ale nějaký problém zůstane 65 Testování •Součást evaluace (ověřování), zda produkt odpovídá potřebám uživatelů •Většinou zahrnuje i testování s uživatelem –To je největší problém •Výše uvedené problémy indikují, že nelze prakticky nikdy odstranit všechny problémy, nelze zero defect software 66 Pravděpodobnost neúspěchu v závislosti na době testování 67 Najímaný tým, vrchol a odhad doby řešení čas Osoby/max. velikost týmu Vlevo sešikmená funkce 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í 68 Nelze zero defect software •Ale jak řídit, když průběh funkcí neznám? •Intuice manažera - odhadne nejvhodnější dobu •Obecně je pocit, že lépe předat před minimem než po minimu •Proč? 69 Obecně je pocit, že lépe před minimem než po minimu • • –Po minimu z dlouhodobého hlediska zvětším možnost, že vyroste konkurence –Také ne zcela správný pocit, že už je to dobré • 70 Jak poznat, že je produkt dostatečně spolehlivý, použitelné jako test ukončení testování u kritických aplikací Hranice konfidenčního intervalu Existují účinnější postupy z teorie spolehlivosti. Exponenciální model poklesu frekvence selhání je zpravidla správný (podmínkou je nezávislost detekce selhání) 71 Druhy testů •Částí, (unit tests) –samostatných kusů programů – dost často testují programátoři sami •Integrační –Shora –Zdola –Selektivní, sendvič, jádro a programy •Regresní (zopakování většiny testů) –Může být příliš náročné na uživatele a na provoz, v agilním vývoji spíše pravidlo 72 Druhy testů •Funkcí –Ucelených akcí systému •Systému –V simulovaném provozu jako celek •Předávací – Podle smlouvy •Test užíváním –Zkušební provoz •Test simulací nebo prototypem 73 Integrace zdola -Je třeba mnoho pomocných dat a programů -Funkce systému se testují a mohou předvádět poměrně pozdě •+ Moduly jsou obecněji použitelné (méně závisí na změnách funkcí systému) •+ Ověřují se možnosti implementace • - 74 Integrace shora •+ Je třeba méně pomocných dat a programů •+ Funkce systému a rozhraní se testují a mohou předvádět poměrně brzy -Moduly jsou použitelné jen v daném prostředí (někdy je to výhoda) -Chyby na vyšších úrovních mohou být fatální (až příliš pozdě se zjistí problémy s implementací) 75 Podpora testů • CASE systémy mají testovací roboty –IBM Rose, RRrobot –Agilní přístup, buduje se testovací podsystém –Generátory (power builder) –Systémy podpory programování usnadňují testování, spíše detailů •Pracnost testování závisí na architektuře systému, v SOA a při agilním vývoji je menší –Znovupoužitelnost a produkty třetích stran –Možnost testování služeb přesměrováním zpráv –Využívání prototypů a žurnálů –Mentálně zvládnutelné –Použití ISO norem u kritických aplikací výhodiu i nutnosti • 76 Programátoři a testéři •Tři varianty „spolupráce“ 1.Programátor je současně testér •Populární, rychlé, málo účinné (vadí u kritických aplikací) • Kompromis: Unit tests. Testy částí. 2.Testér je specifická role, bílé skříňky •Testér spolupracuje s programátorem při nápravě selhání 3.Testér testuje černé skříňky, testéři nemají zdrojové kódy ani kontakt s programátory •Nejúčinnější je 3, ale je to velmi drahé a vyžaduje to kvalitní profesionály 77 Terminologie testování •Selhání – jiný než očekávaný výsledek •Neúspěch testu – nedetekuje selhání •Testový případ: Data, scénář, výsledky •Testová procedura: Síť testových případů •Test: Síť testových procedur •Položka k testování: Vše, co potřebuje testový případ (prostředí, SW, data, scénáře, očekávané chování systému, výstupy) 78 Terminologie testování •U agilního programování se nejprve definují testové případy pro nově vyvíjenou část •Naprogramuje se část •Testové případy se použijí k otestování části (fakultativně), provádí programátor •Testové případy se integrují s ostatními testy, systém se integruje •Systém se při agilních postupech integruje a testuje jako celek, to lze u menších a nekritických aplikací či u nepříliš složitých služeb v SOA 79 Specifikace testů, neagilní případ, složité či kritické části •Id •Podmínky a způsob provedení •Popis testu, testové procedury •Kriterium přijetí/zamítnutí testů •Kriteria pro přerušení testu •Rizika 80 Popis problému (selhání) •Prováděný testový případ, procedura, test („místo“) •Skutečné výsledky ve srovnání s očekávanými •Popis anomálie •Doba •Pokusy o opakování •Kdo testoval •Nemá být spojováno s návrhy oprav 81 Proces testování Specifikace testových případů Nebývá nutné u agilních forem 82 Souhrnná zpráva o testech •Zprávy o předání položek •Žurnál testů •Zprávy o selháních (incidentech) •Souhrnné hodnocení –Co se vše testovalo –Hodnocení výsledku (přijmout/nepřijmout testovaný produkt, případná opatření) 83 Testové metriky (Příklady) 1.Počet modulů modifikovaných při vývoji/změně. 2.Počet defektů odstraněných v dané etapě. 3.Pro modul počet defektů na tisíc řádků. 4. Počet změněných příkazů/míst. 5. Doba na lokalizaci a odstranění chyby. 6. Druhy a frekvence selhání systému. 7. Výčet modulů s největším (nejmenším) počtem defektů. 8.Výčet modulů, které jsou nejsložitější, tj. těch, pro něž nějaká metrika nabývá extrémních hodnot nebo překračuje nějakou hodnotu. 84 Evidence příčin selhání • chyba specifikací • chyba návrhu, • kódovací chyby, • selhání hardwaru, • chyba v reakci softwaru na selhání hardwaru (př. Škoda Plzeň) •chyba obsluhy 85 Využití testovacích metrik •Kdy ukončit testování •Dodatečná kontrola efektivnosti oponentur • Ověřování kvality nástrojů a jejich efektů •Skrytě hodnocení členů týmu •Lze použít technologie hodnocení kvality technických výrobků (střední doba mezi poruchami, kritické části) • 86 Datová báze výsledků testů (selhání) by měla být stejná jako u oponentur a u reklamací, Cíl je identifikovat (možnost) selhání defekty se detekují v následných aktivitách Je třeba dohledat prapříčiny 87 Konceptuální schéma, opakování Osoba Dokument Defekt Selhání Proces Osoba Osoba * * * * + Odpovídá za Obsahuje Způsobeno Má opravit Má řešit Zjištěno v Našla * V procesu odstraňování selhání se * změní na + Způsoben * Proces je oponentura, test, nebo stížnost uživatele, technicky odkaz na zápis Jak se dá zjistit, kdo udělal opomenutí – * Oprava Řeší * Provedla •Jednoduchá datová struktura pro vyhledání zdrojů problémů + integrace s oponenturami Permanent obsolence •Dříve než systém otestuji se změní požadavky a všeobecné podmínky –Použité normy zastarají –Požadavky se změní –Trh se změní, mám jiné obchodní parnery –Změní se paradigma • Řešení –Dělám po částech (komponenty, služby) –Koupím, znovu použij –Outsourcuji –Zlepším své procesy vývoje a údržby – – 88 89 Zavedení Jak instalovat a zavádět Na koho se obrátit 90 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í 91 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 92 Křivka učení a typy uživatelů 93 Křivka učení a typy uživatelů 94 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 • 95 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 96 pro jednu osobu 97 Křivka učení a typy zvládání 98 99 100 101 Údržba I instrukce se z logického pohledu (potřeb) opotřebují 102 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 103 Corrective maintenace Model průběhu velikosti týmu a tedy intensity práce, starší varianta 104 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é 105 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é 106 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í 107 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 108 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, dnes skoro pemanentní vývoj –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ů 109 Vanová křivka. I SW se opotřebí 110 Vanová křivka. I SW se opotřebí Záběh Záp. exp. Opotřebeno Stálá úroveň selhání – – – – – – – – – – – – – – – – – – 111 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 112 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) 114 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) 115 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 116 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,…) • 117 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ů, …. – – 118 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í • 119 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 120 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 – – 121 Jak se projeví SaaS, software as a service A také cloud computing Platform as a service Zatím ve fázi líbánek 122 123 Měření softwaru 124 Výsledek měření je metrika •Bez měření nelze kvalitně řídit ani hodnotit kvalitu SW, atributy kvality mohou ale být různé •Softwarová metrika je nějaký údaj, který lze nakonec převést na číselné hodnocení nějakého atributu softwaru •DB softwarových metrik je paměť firmy a prostředek optimalizace softwarových procesů (procesů vývoje softwaru) a managementu (např. méně rizik při uzavírání smluv), •Je součástí business intelligence SW firmy a přepoklad uplatnění moderních způsobů řízení, např. CMMI 125 Použití SW metrik •a) Výzkum: podklad pro hledání metod realizace softwarových produktů, které by přinesly podstatné zvýšení jeho kvality a snížení nákladů a doby vývoje a hlavně rozsahu prací při údržbě softwaru (výzkum metod a zákonitostí vývoje softwaru). •b) Normy: základ pro stanovení technicko-ekonomických podkladů pro řízení prací při tvorbě softwaru (normy pracnosti, odhady takových metrik, jako je pracnost či doba řešení) a uzavírání smluv (cena, termíny), předpoklad CMM •c) Kontrola kvality: prostředek sledování spolehlivosti softwaru při provozu a podklad pro řídící zásahy během údržby,procesy zajišťujíící kvalitu •d) Operativa:prostředek sledování průběhu prací při vývoji (dodržování termínů, procento testovaných komponent, trendy počtů chyb, počty nově zanesených chyb, komponenty s největším počtem chyb, atd.). 126 Použití SW metrik •Výsledkem výzkumu SW metrik jsou metodiky vývoje (SOA, OO, strukturované programování, znalosti a vlivu kvality specifikací atd.) a metodiky odhadu pracnosti a doby řešení COCOMO, funkční body, a filosofií SOA ITIL •ISO 9126, ISO 250xx, ISO 12207, ISO 20000 •ISO 250XX, Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Planning and management •ISO 270XX Information Security Management System • 127 Infrastruktura sběru metrik 128 Problémy se systémem měření •Hlavním cílem je systém měření umožňující snadný přístup k metrikám a efektivní metody vyhledávání a vyhodnocování informací. • Cílem měření není pouze každodenní operativní dohled a kontrola. –Systém orientovaný na kontrolu a dohled má tendenci ustrnout a nevyvíjet se. Navíc hrozí, že se nevyužijí možnosti, které systém nabízí pro vrcholové řízení. 129 Problémy se systémem měření •Systém měření nemá vyvolávat odpor, jinak je neefektivní •Odpor může být způsoben nevhodnými opatřeními managementu. –Zviditelnění dobrých výsledků může vést management k rozhodnutí nadměrně redukovat zdroje pro daný úkol. –Zviditelnění nevýkonnosti může vést k posílení zdrojů, později však i k postihům. Pozdní posílení může být kontraproduktivní •Je důležité, aby většina cítila, že jsou metriky užitečné a poctivé zvýhodňují a zvyšují šance na úspěch. 130 Problémy se systémem měření •Využívání metrik může být ztíženo krátkozrakostí a profesionálními předsudky (nekritické přeceňování účetnictví a finanční operativy atd.). •Informace a rozhodnutí mohou složitým způsobem záviset na několika metrikách. Snaha o zjednodušení může vést k nesprávným závěrům. Management by měl své závěry konzultovat s členy týmu. –Chybovost modulu může být náhoda •Efektivnost využití systému sběru a vyhodnocování metrik závisí na tom, do jaké míry bude všemi akceptován a kvalifikovaně užíván. Při tom lze využívat matematickou statistiku 131 Vlastnosti systému měření •Jasně definované cíle měření –U všech sbíraných dat musí být jasné, že jsou potenciálně užitečné pro všechny, byť se hned nevyužívají, –Jinak je sběr metrik chápán jako šikana •Otevřenost, modifikovatelnost –Znalosti o metrikách (state of the art) se mění, mění se i potřeby managementu a standardy 132 Vlastnosti systému měření •Vychází z potřeb managementu –Integrální součást řízení •Měření odděleno od vyhodnocování •Lidé by měli cítit systém měření jako podporu jejich práce a ne jako hrozbu. Neměli by být dominováni systémem – • 133 Kvalita dat •V managementu se musí používat data, která nejsou zcela spolehlivá a relevantní •Podpora managementu se stává hlavním úkolem informatiky. Operativa je už do značné míry vyřešeným úkolem (neplatí pro zábavu) 134 Kvalita dat 135 Problémy s kvalitou dat pro řízeni •Relevantnost a včasnost závisí na frekvenci zjišťování nebo na tom, jak je časově náročné data vytvořit (např. data rozvrhu) •Kvalita dat může implikovat vytvoření datového úložiště v SOA, aby management mohl ovlivňovat chod systému 136 Problémy s kvalitou dat pro řízeni •Kvalita dat může implikovat filosofii řešení – Kritická cesta a kritický řetězec •Kvalitu je nutno měřit či odhadovat •Kvalitu dat můžeme zlepšovat –Okrajová data, odstranění –Chybějící data pro parametry, pro regresi, doplnit –Opakovaná data, odstranit –Rozsah dat, měl by být dostatečný 137 Přesnost SW metrik je malá •Hodnoty metrik závisí –Na typu projektu, projekty se málo opakují (výjimka: SAP atp.) •Velikost projektu a ostrost termínů •Typu úlohy RT*dávka bez přímých následků – Na stavu oboru •Výkon HW, sítě, vývojová prostředí, •paradigmata 138 Přesnost SW metrik je malá •Hodnoty metrik závisí –Dosažitelné technologii –Kvalitě programátorů (produktivita 1:20) •Kvalitnější vývojáři píší lepší programy (rychlost 1:10 a to s méně chybami) •Programátoři jsou schopni silně ovlivnit určitou SW metriku, je-li jim dovoleno nebrat ohled na jiné metriky (rychlost a úkor délky) –Do jaké míry se řeší podobné problémy (viz minulý semestr) 139 Přesnost SW metrik je malá (velký rozptyl) •Výhrady k přesnosti metrik neplatí pro metriky sledující vlastnosti systému za provozu –Frekvence chyb/střední doba mezi poruchami –Počet stížností –Frekvence nalézání problémů a detekce defektů 140 Pracnost závisí zejména na •– druh softwaru: míra interakce od dávkových až po tvrdé systémy reálného času, závažnost •- důsledků selhání, od nevýznamných škod, přes ekonomické ztráty až k ohrožení životů. V neposlední řadě •- velikosti systému; •– ostré až obtížně splnitelné termíny realizace; •– použití moderních projekčních technik a technik vývoje; •– kvalita zúčastněných; •– omezení hardwaru a softwaru. Pokud systém využívá zdroje jako je rychlost a paměť více než na dvě třetiny, vzrůstá značně pracnost řešení. 141 Interní a externí metriky (ISO 9126, ISO 250XX) •Též implicitní a explicitní metriky (in process, after process) •Interní – známo jen týmu během vývoje na základě sledování vývojových procesů: např. spotřeba práce, a také doba řešení •Externí: dají se zjistit na hotovém produktu, např. délka •Některé metriky je možné chápat obojím způsobem (počet selhání při testování, externí – zjištěno uživateli) 142 Datové typy SW metrik •Příslušnost k třídě (id. - číslo tramvaje) –Trendy počtů objektů s daným id, operace rovnost =) •Fuzzy (id hodnocení, dobrý, lepší, nejlepší, známky ve škole) –Operace = test na rovnost, < test na „velikost“. Obvykle se převádí na číselné hodnocení. Př. COCOMO, známky ve škole (tam se používají přímo fuzzy hodnoty ve formě čísel) 143 Datové typy SW metrik •Interval –Čas, teplota –Je možná lineární transformace, =, < –Využitelný je rozdíl jako číselná metrika •Číselná metrika –Délka programu, doba řešení –Jsou smysluplné všechny operace pro reálná čísla 144 ISO 9126 (4 části) •Stovky metrik, rozumně použitelné většinou jen u velkých firem •Není jasné, k čemu se to všechno použije •Jádro (principy a některé metriky) použitelné •Modernizace norme - sada norem 250xx –Základní principy a základní metriky stejné 145 Externí metriky •Del – délka produktu v řádcích. U programů se nepočítají komentáře. Del programů se někdy udává v lexikálních atomech. Do metriky Del se někdy nezahrnují deklarace proměnných a záhlaví podprogramů. •Srnd – rozsah slovníku operandů. Tato metrika se týká programů. Operand je bud’ konstanta (např. celé číslo 10, nebo řetězec znaků „ xyz“, v terminologii programování literál), nebo proměnná, např. x. Srnd je pak počet logicky odlišných operandů vyskytujících se v programu. 146 Externí metriky • •Nrnd – počet výskytů operandů v programech •Noper – Počet výskytů delimiterů a znaků operací a podprogramů v programech. •Soper – rozsah slovníku operací, podprogramů a delimiterů. Tato metrika udává, kolik program obsahuje významem různých znaků operací (*, C, atd.), jmen podprogramů (sin, tan, put), delimiterů (: if begin real atd.). • 147 Externí metriky •Users – Maximální počet uživatelů, pro které je systém plánován. •McCabe – počet podmíněných příkazů (if), příkazů cyklu (for, while, . . . ) a přepínačů (case) v programu. Metrika McCabe je dobrým indikátorem složitosti programů. Jejím nedostatkem je, že není citlivá na hloubku a způsob vloženosti podmíněných příkazů (tvar rozhodovacího stromu (případně lesa). 148 Externí metriky •In, Out, Qer, File, Filee – složitost příkazů vstupu, výstupu, dotazů na terminál a operací se soubory interními a se soubory společnými s jinými aplikacemi. U databází složitost SQL dotazů. Tyto metriky se používají v odhadech pracnosti a doby řešení v metodě funkčních bodů. •FanIn, FanOut – míry indikující složitost rozhraní tříd, modulů a aplikací. FanIn udává počet logicky různých •typů dat vstupujících do dané entity (např. modulu). FanOut je obdoba FanIn pro vystupující datové toky. •Často se používá metrika Fan1 =∑modul i (FanIni * FanOuti) 2. Problém metrik pro SOA •Obtíže s měřením složitosti komunikace, • Jak měřit složitost hrubozrnných zpráv • 150 Interní metriky •Prac – spotřeba práce, obvykle v člověkoměsících •Doba – doba provádění •Prod – jednotky délky za člověkoměsíc (řádky za měsíc) •Fail – počet selhání za týden (den) 151 Interní metriky •Prod – produktivita, počet jednotek délky vytvořených za člověkoměsíc. •team(t) – velikost týmu (počet osob) v čase t, měřeno od začátku prací. Tato metrika umožňuje postupné zpřesňování odhadů pracnosti a doby řešení během vývoje projektu. •Team – průměrná velikost týmu. 152 Interní metriky • • •Fail(t,p) – počet selhání systému /části p detekovaných při testování či provozu v čase t. Při provozu hlásí selhání zákazníci. Obvykle se udává po dnech nebo týdnech. Tato metrika je důležitou mírou kvality. Při inspekcích je hodnota metriky Fail dána počtem chyb zjištěných při inspekci. 153 Interní metriky • •Defect(t,p) – počet míst v programech, která bylo nutno opravit pro odstranění selhání nebo pro nápravu selhání v čase t (den, týden) v části p, normalizovaný pro 1 000 řádků (1000 _ počet defektů_délka). • •Defect1(e1,e2,t,p) – počet defektů v části p vzniklých v etapě řešení e1 a zjištěných v etapě e2 v době t. Tato metrika a metriky z ní odvozené jsou účinnou mírou efektivnosti inspekcí a testů. Důležitá externí metrika pro vyhodnocování kvality produktu 154 Interní metriky •Satisf(t) – průměrná míra spokojenosti zákazníků včase t. Spokojenost se udává ve stupnici 1 až 5 (nejlepší). Lze vyhodnocovat trendy. Existují metody odhadu vývoje úspěšnosti produktu na trhu z aktuálních hodnot metrik Satisf (Babich, 1992). •DobaOpr – průměrná doba opravy selhání. 155 Interní metriky •Zmeny(f,t) – počet změněných míst souboru f včase t (týdnu/dni). Tato metrika se snadno zjišťuje a její trendy mohou v průběhu prací poskytnout cenné informace. • •MTBF(t) – (Mean Time Between Failures): střední doba mezi poruchami (v určitém období, např. týdnu, t). • • 156 Vztah mezi rozsahy slovníků operandů a operací 157 Výpočet charakteristik programu 158 Halsteadův vztah pro malé programy •Odvozeno z analýzy počtu rozhodnutí při psaní •Prac @ C Del Nrnd (Soper/Srnd) log(Soper+Srnd) •V dobře napsaných programech jsou Srnd a Nrnd úměrné délce. Pro velké Soper a Srnd lze logaritmus nahradit konstantou. Pak ale bude •Prac @ C‘ Del Soper 159 Halsteadův vztah pro malé programy •Poněvadž je pozorováno, že • Soper @ C“ Delb •dostaneme •Prac = c Del1+b b @ 0,25 •Pro velké programy je hodnota b příliš vysoká. Je to důsledek toho že vztah modifikujtakové technologie, jako dekompozice a znovupoužití částí. • Pokud se dekomponuje do malých komponent a systémy se liší jen počtem komponent a transport zpráv se nemusí pracně implementovat, bude b velmi malé. 160 Závislost pracnosti na délce programu Běžná regrese Ortogonální regrese Data DoD 161 Závislost pracnosti na délce programu Data IBM 162 C→M1 C 163 164 165 – 166 Pozor na statistiku •Analýzou dat klasickou regresí dostaneme •Prac = c10 Deld •Kde d < 1, což není zřejmě reálné, neboť jedna instrukce ve velkém systému dá podle zkušeností více práce (např. díky nákladům na chod týmu, než jedna instrukce v malém systému. •Je nutné použít ortogonální regresi. 167 Problémy s regresí 168 Pro obchodní systémy ani to nevysvětluje nízký koeficient regrese •Možnost: Velké systémy více používají různé nástroje, jako jsou generátory kódu, CASE systémy, atd. Generovaný kód je „řinčí“ 169 Prvá zákonitost •Pro délku a pracnost platí vztah •log(Prac) = (1+a)log(Del) + c´ •takže •Prac = c Del1+a •Ortogonální regrese dává •a @ 1/8 170 Prvá zákonitost •Pro délku a pracnost platí vztah •log(Prac) = (1+a)log(Del) + c´ •takže •Prac = c Del1+a •Ortogonální regrese dává •a @ 1/8 •Avšak c i a závisí na typu projektu 171 Použití a důsledky •Vztah Prac = c Del1+a se využívá v odhadu COCOMO •Pokud je pracnost budování middleware zanedbatelná klesne pracnost monolitního systému po dekompozici na n zhruba stejných dílů z Prac1 = c Del1+a na •Pracn = c n(Del/n)1+a = n-a Prac1 172 Empirické výsledky 173 Putnamova rovnice •Podle třetí řádky tabulky čili Z definice Del = Prac Doba, takže To je Putnamova rovnice 174 Vliv napjatých termínů •Dobu řešení nelze v praxi libovolně zkracovat, •Pro každý projekt existuje tedy mez m, pod níž se nelze prakticky dostat. Interval <0,m> se nazývá nedosažitelná oblast pro daný projekt. m je funkcí Prac •Pro více projektů je nedosažitelná oblast oblast roviny (Prac, Doba), kde •Doba < ¾ Prac1/3 • 175 Pracnost u nedosažitelné oblasti cD-4 m –D D Efekt líného studenta 176 Některé starší výsledky pro SW projekty 177 Chování pracnosti u nedosažitelné oblasti •Uvažujme dvě realizace A,B stejného projektu s atributy • • •Vydělením Putnamových rovnic pro obě realizace dostaneme 178 Chování pracnosti u nedosažitelné oblasti •Nechť DobaA > DobaB. Poněvadž programy psané ve spěchu bývají delší je možné předpokládat DelA £ DelB tj. DelA /DelB £ 1 •Po úpravách dostaneme z poslední rovnice • 1 ³ DelA /DelB = (PracA /PracB)1/3 (DobaA / DobaB)4/3 •Z toho po úpravách, považujeme-li hodnoty s indexem A za konstantní dostaneme obdobu Stefan-Botzmannova zákona •PracB ³ c30 DobaB-4 179 Použití ve function points • •Zkrácení termínu o šestinu prodlouží pracnost dvakrát Ale zkrácení o polovinu zvýší pracnost šestnáctkrát. Metodika Function points nemá opravu na zkracování termínů tak drastickou, zkrácení na polovinu ale nepovažuje za možné. 180 Corrective maintenace Rayleightův model pro team(t) 181 Kritika Rayleightova modelu •Příliš rychle klesá v nekonečnu, potom by ale byl SW bez chyb možný a to se nepozoruje •Množství práce do maxima je příliš veliké, neodpovídá datům o corrective maintenance (40% pracnosti vývoje) •Nevysvětluje, proč platí pro SW Stefan-Botzmannův zákon •Má málo parametrů a změna parametrů nemění příliš tvar •Proto si půjčíme Planckův zákon 182 Planckův model •Standardní tvar zákona záření absolutně černého tělesa Team(t) = Ct-5 exp(D/t)-1 D určuje tvar křivky a polohu maxima 183 Corrective maintenance Planckův model 184 Kritika Planckova modelu •Začíná růst až od 1/3 (Existují názory, že je to OK, pokud do team(t) nezahrnujeme práce na specifikacích). •Má také málo parametrů A.Zavedeme lineární transformaci nezávisle proměnné B.Změníme exponent 5 v polynomiální části • 185 Modifikace Planckova modelu A.Transformace nezávislé proměnné team(T) = Dává dobré výsledky 186 Najímaný tým, vrchol a odhad doby řešení čas Osoby/max. velikost týmu Vlevo sešikmená funkce 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í 187 Proložení Planckovy křivky pro SW řízení ponorek 188 Proložení Planckovy křivky pro projekt Safeguard 189 Bylo jasné, že projekt nelze v rozumné době dokončit i proto, že nebylo možno včas vytvořit SW. A také by to stálo majlant 190 Zobecnění Planckova modelu •Planckův model lze zobecnit team´(T) = C(T+kd)-qdq exp(D/(T+kd))-1 Paramery jsou C, D, k, d q. Stefan-Botzmannův zákon pak dostane tvar PracB ³ c30 DobaB-q+1 191 Zobecnění Planckova modelu •Zobecněný Planckův model dostaneme výše uvedeným postupem, má-li Putnamům zákon tvar •Del @ cPrac1/pDobaq/p •pro vhodné kladné p 192 Použití Rayleigtova a Planckova modelu •Uvažujeme-li fakt, že část práce se po předání e přesune do údržby, platí následující pravidla •Rayleigt - zákon polovin. V době dosažení maxima velikosti týmu jsme za polovinou doby řešeni a spotřebovali jsme přes polovinu práce •Planck – zákon třetin, jsme asi v třetině doby řešení a spotřebovali jsme třetinu práce (a tedy budeme muset dvojnásobek dosud spotřebované práce ještě vynaložit) 193 Rozložení výkonnosti •Budiž a(p) procento výsledků, které dosáhlo p procent nejlepších (např. a(1) je procento branek, které nastřílelo jedno procento nejlepších. Uvidíme, že a(1)=7) Vyneseme-li graf a(p) v dvojitě logaritmickém měřítku dostaneme následující obrázek. 194 195 Výsledky nejlepších •Z grafu vyplývá, že •a(p)=cp1/2 •kde c nepříliš silně závisí na typu činnosti •Procento nejlepších udělá 7,5% výsledků, 20% nejlepších udělá polovinu práce, 40% nejhorších neudělá skoro nic •Seřadíme-li pracovníky podle výkonnosti, a budeme-li vynášet, kolik udělal každý jednotlivec, bude mít příslušná funkce tvar • b(p) = 1/2cp-1/2 196 Použití •Vědomí důležitosti talentu a kvality lidí –Nejlepší udělají nejen nejvíce výsledků na hlavu, ale také udělají i nejlepší výsledky •Pokud jsou ve větší skupině problémy na straně kvalitních lidí, je nutné zkoumat, čím to je a zda to vadí (např. zda se nejedná o rutinní práce, kde se mohou kvalitní lidé cítit nevytíženi) 197 Závislost produktivity na délce programu pro malé programy, směrnice = -1/4. 198 Vliv vytíženost HW 199 Využití •U produktů, které nemají charakter masové spotřeby –Instalovat systém s 50-60% rezervou aby byl prostor na úpravy –Zvětšit reservu na alespoň 50%a, klesne- reserva pod 40% –Příklad použití: Letecký dispečink –Často se zbytečně šetří – 200 Náročnost údržby Vyšší jazyk Asembler 201 Využití •Asembler je na údržbu (měřeno počtem osob udržujících systém na tisíc řádků) asi pětkrát pracnější než klasický programovací jazyk. U moderních systémů může být rozdíl ještě markantnější •Poněvadž jeden řádek vyššího jazyka nahradí i několik řádek assembleru, je rozdíl produktivity alespoň 1:10 •Vyhýbat se asembleru, je-li to možné 202 Databáze metrik 203