====== N-INS 2 ====== ===== Zadání ===== Vývoj uživatelského rozhraní. Problém testování. Zásady tvorby dokumentace. Počítačová ergonomie. Práce v týmu. ===== O této otázce ===== Tato otázka vychází z předmětů TIS1 a TIS2. Veškeré potřebné informace jsou přímo v knize //Informační systémy// od profesora Krále. ======= Vypracování ======= ====== Vývoj uživatelského rozhraní ====== ((Kapitola 14, str. 217))Návrh a vývoj UI má specifické problémy a tudíž je vhodné koncipovat UI v IS jako samostatný subsystém. Kvalita UI ovlivňuje: * Celkovou spokojenost zákazníka * Složitost ovládání IS * Dobu zaškolování se systémem * Pracnost používání IS Analýza 31 projektů v 1993 ukázala, že vývoj UI spotřebuje od 4% do 15% celkových nákladů na projekt. ==== Zásady návrhu UI ==== * Analýza požadavků * Návrh UI * Realizace prototypů a jejich testování s uživateli * Integrace UI se zbytkem systému a testování UI společně s uživateli * Sledování vlastností UI za provozu a vylepšování vlastnosti UI Při //analýze// se využívají některé již zavedené techniky a některé specifické čistě pro UI. //Pozorování uživatelů// a jimi prováděné úkony je jeden ze základních postupů. Dalším, známým, způsobem jsou //scénáře// neboli zaznamenávání ucelených postupů uživatele při práci. //Myšlení nahlas// je technika, při níž uživatel za přítomnosti autora IS nebo testera nahlas říká, co právě dělá a proč to dělá. //Heuristika evaluace// je metoda, kde se neformálně hodnotí předložené UI podle sepsaných doporučení (které jsou identifikovány v některých publikacích). Testování UI má svá specifika. Test se provádí za přítomnosti vývojáře. Testování by mělo probíhat anonymně a ve větší skupině pečlivě vyraných uživatelů (3-6). Testování má následující etapy: * Příprava * Zahájení - je třeba zdůraznit že se testuje systém, nikoliv uživatel. Požádat o "myšlení nahlas". * Provedení testů - atmosféra by měla být uvolněná. Nedávat najevo že uživatel je pomalý či že dělá chyby. * Vyhodnocení testů - Výsledky testů zavést do databáze projektu. ====== Počítačová ergonomie ====== ((Kapitola 4, str. 49)) IT systémy využívá stále větší část populace. To ovšem vytváří i negativní vlivy, které si musíme uvědomit a jako tvůrci softwaru se je pokusit odstranit a sami se jim vyvarovat. **Expozičná doba** -- priemerná doba pôsobenia škodlivého vplyvu do prepuknutia choroby ===== PC nemoci z povolání ===== Práce s PC je mentálně namáhavá a může ohrozit zdraví psychické i fyzické. Uživatel by měl občas přenést pohled z obrazovky někam jinam, třeba se občas podívat oknem do přírody Mezi objektivně zjistitelné nemoci z práce s počítači patří různé otoky a záněty. Zasažena bývá krční a bederní páteř a paže. * RSI (repetitive strain injuries - poškození rukou a paží z monotoní práce) * záněty v loketním kloubu - projevuje se bolestí lokte v určitých pozicích * otoky nervových pouzder v ruce a v předloktí - projevuje se brněním * otoky a záněty pouzder šlach a šlachových úponů - bolesti v paži vedoucím až k znehybnění * poškození kloubů a šlach v zápěstí * krčové žily * Poškození krční páteře - při nevhodné poloze předloh a nevhodné poloze obrazovky dochází k přetěžování krční páteře a šíje. To vyvolává problémy např. u pokladních samoobsluh. Proto se nazývá //nemoc pokladních//. * Poškození bederní oblasti - bolesti v kříži. Nejčastěji je způsobeno nevhodným sezením a nekvalitní židlí * Ruky - pocit slabosti alebo tiaže, problémy pri jemných pohyboch, trias, problém zavriet pasť Obrana proti RSI jsou přestávky, uvolňovací cviky. Proti poškození páteře se bráníme kvalitní sedačkou, dobře umístěným displejem a přestávkami. Kromě objektivních potíží existují i potíže subjektivní * zažívací * nespavost a noční úzkosti * poruchy soustředění * pocit psychické nepohody Tyto subjektivní problémy mohou být vyvolány neodstíněným vysokofrekvenčním polem a vyzařováním obrazovky. Medzi časté problémy profesného života patrí aj **vyhorenie**. Príznaky vyhorenia: * odcudzenie: spolupracovníci ma štvú * "fekálizmus": všetko stojí za ... * marnost: všetko je stále dookola ====== Problém testování ====== Existují 3 typy testerů: vývojář, white-box tester a black-box tester. ((Kapitola 13, str. 203)) V SW jsou vždy chyby. Pro každý případ chybného fungování je třeba nalézt příčinu. Opravený program se testuje dokud frekvence selhávání systému neklesne pod určitou mez. Etapa ladění je velmi pracná, pracnější než psaní programů a je považována za nejobtížnější ze všech etap vývoje SW. Testy se dají rozdělit do následujících typů: * Jednotkové testy - jednotkové testy prováděné vývojářem * Integrační testy - testování, ve kterém je zapojeno více programových tříd či modulů * Funkční testy - funkční testování softwaru bez znalosti vnitřní struktury * Testování při převzetí (acceptance) * Testovanie výkonnosti (performance) Vstupy pro testování začínají vznikat už v návrhu aplikace. Výsledkem návrhu je mimo jiné i vypracování testových případů. Testování využívá i výsledků oponentur všech etap vývoje a inspekcí kódu. Na základě plánu testů se pro jednotlivé moduly SW specifikuje: * Jaké testové případy se uvažují (vstupy, příkazy, očekávané reakce systému) * Jaké testové procedury se předpokládají * Popis testu (cíl testu, podmínky provedení) Po provedení testů se vypracovávají zprávy o zjištěných nedostatcích a ty je dobré zaznamenávat do žurnálu testů. Na závěr se vypracuje souhrná zpráva o testech. Jedno selhání se popisuje následovně ((vtipné, je to v podstatě bug report, popsaný jazykem z dávných dob :-) )): * Identifikátor testu * Zkrácený popis problému (abstrakt) * Podrobný popis problému * Důsledky selhání pro plán testů (co je třeba opravit) Souhrná zpráva obsahuje: * Zprávy o předání položek k testování * Žurnál testů * Zprávy o chybách nebo jejich shrnutí * Souhrná zpráva - co vše se testovalo, jakoé jsou výsledky, zda je produkt přijat či ne Organizační zabezpečení testů u velkých projektů obvykle zastřešuje speciální tým testerů. Tento tým může pracovat nezávisle, to je ale velmi drahé. Proto se doporučuje, aby testéři spolupracovali s vývojovým týmem. Po dokončení testů jednotlivých modulů IS dochází k propojení (integraci) jednotlivých částí do celku. IS by se neměl integrovat naráz, ale postupně. Vycházet by se mělo ze závislostního grafu (modul B je závislý na modulu A) a pomocí tohoto grafu postupně integrovat. Integraci můžeme rozdělit na //integraci shora// a //integraci zdola//. Integrace zdola začíná u modulů které //nepotřebují jiné moduly// a postupně integruje až se integrují již integrované množiny modulů. Je to poměrně dobrá metoda, vyžaduje však mnoho pomocných programů, které generují data pro prověřené moduly. Také se pozdě zkontrolují funkce systému. Integrace shora začíná u modulů, které //nejsou potřeba v jiných modulech// a závislosti tohoto modulu jsou simulovány. Tyto simulované podřízené moduly se naprogramují později a připojí do vznikajícího systému. Výhodou je, že se testují konečné funkce (moduly na vysoké úrovni abstrakce) a testuje se dříve rozhraní. Nevýhodou je, že simulace nižších úrovní je často velmi obtížná. Existují některé další integrační (kombinované metody). //Metoda sendviče// funguje tak, že se systém rozdělí a některé funkcionality se integrují shora a některé zdola. Například u OS se uživatelské moduly integrují zdola a společné služby shora. ====== Zásady tvorby dokumentace ====== ((Kapitola 17, str. 277))Dokumentace SW je velmi důležitá, platí to jak o technické, tak o administrativní a ekonomické dokumentaci. Do jisté míry představuje paměť firmy. Dokumentace má být: * aktuální * přehledná a srozumitelná * umožňuje snadno ověřit správnost implementace * umožňuje sledovat průběh prací SW dokumenty mají obsahovat informace o tom * jak systém používat * jak systém instalovat a obsluhovat * jak systém udržovat * popis realizace * testové procedury, data a hodnocení testů * ostatní dokumenty Dále existuje uživatelská dokumentace a dokumentace pro údržbu. ((tyto dokumentace jsou dále v knize rozvedeny, ale z důvodu rozsahu je zde neuvádím)) Kvalita dokumentace je stejně důležitá jako kvalita programu, přes nejrůznější doporučení a normy bývá ale na dosti nízké úrovni. Dokumentace bývá neúplná, zastaralá a především nepřehledná. Psaní dokumentace vyžaduje hodně úsilí. Napsaný text by měl být pečlivě čten autorem i jeho spolupracovníky, oponován a upravován. Některé zásady které pomůžou ke kvalitnější dokumentaci: * Psát kratší věty * Používáme-li často odkazy je vhodné nepoužívat pouze čísla kapitol ale i nadpis kapitoly v textu odkazu * Snažíme se o maximální stručnost * U obtížných míst naopak nešetřeme slovy i s příkladem. * Je třeba zajistit jednoznačnost používaných termínů. Například pojem //proces// může mít v různém kontextu různý význam. Pak je vhodné doplnit slovník. * Dokument by měl být dekomponován do kapitol nejvýše několik stránek dlouhých. Odstavce ne delší než 10 vět. * Jazykově správně * Dobře graficky upravený * Dobře hierarchicky rozdělen Pro vedení dokumentace existují normy. Obecné zásady jsou v ISO 9000-3. ====== Práce v týmu ====== ((Kapitola 10, str. 121))Je zjevné, že větší úkoly nemůže realizovat jednotlivec ani malá skupina. Pro dobrou funkci týmu je zde ovšem mnoho překážek. Mezi jeho členy nesmí být jedinci totálně neschopní týmové práce, např. "schopní všeho". Čím větší tým tím více je třeba věnovat plánování, kontrolním opatření, schůzím. Z průzkumů vyplývá, že je větší spokojenost s prací a vyšší produktivita u členů menších týmů s neformální organizací((pozn. Filip N.: tzn třeba agilní metodiky)). Centralizace je výhodná tam, kde je nutné rychlé rozhodování a u relativně jednoduchých a pracných činností, jako je shromažďování a předávání informací. Optimální tedy je malá neformállní skupina se členy obou pohlaví a neautokratickým vedoucím. Bohužel existují úkoly, na které malý tým nestačí. Tímy je možné deliť na **pevné** (tím je pevný, úlohy sa hľadajú) a **najímané** (pracovníci sa prenajímajú podľa potreby) V rámci tímu je možné jednotlivcov deliť na základe niekoľkych vlastností/pováh opísaných v a)-d) a) Existuje základní dělení pracovníků, podle jejich motivací: - Pracovníci orientovaní na úkol (workoholici) - Pracovníci orientovaní na spolupráci (kamarádi) - Pracovníci orientovaní především na sebe sama (sobci). Pro tyto je hlavní motivace úspěch (1) mohou být dobří vedoucí. Ale pokud jich je v týmu mnoho, tak mají tendenci k organizační nekázni, neradi se podřizují. (3) jsou dobří vedoucí, ale musí být motivováni prací. Mívají dostatek vůle a zároveň se nespokojují s nižším postavením. Z pohledu pohlaví jsou muži častěji orientovaní na práci, ženy pak na spolupráci. //Týmová loajalita// je pojem vyjadřující stav, kdy členové týmu pojmou cíle projektu za své vlastní a brání ho před vnějším světem. Týmová loajalita zvyšuje výkonnost týmu a však po jisté době může narůstat bez zjevného důvodu rozpory, což je známé jako //ponorková nemoc//. Při práci v týmu mohou nastávat různé problémy: * Ve skupinách začnou vznikat (třeba na poradách) různé rozpory. Bývá to tehdy, pokud je mezi členy týmu příliš mnoho vůdců (1), (3). Pak je vhodné tým reorganizovat - neboli rozdělit na více týmů * Egoistické postoje. Je důležité, aby se chyby v programech a dokumentaci brali jako nutné zlo a nikdo se neobviňoval. Kód a celý software je dílem týmu, nikoliv spojení částí patřících jednotlivcům. Při řešení nějakého rozhodnutí existují následující metody: * postavení před hotovou věc * rozhodnutí v klice (klika je malá skupina uvnitř týmu) * dohoda menšiny * dohoda - konsenzus - většiny * všeobecný konsenzus * zdánlivý konsenzus Nejlepší rozhodnutí je všeobecný konsenzus a nejhorší zdánlivá dohoda. b) V rámci tímu zohrávajú dôležitú úlohu rôzne typy povahových zručností: - športová - sociálna (vedenie tímu) - abstraktná - emocionálna - umelecká (grafik) c) Delenie na základe neoficiálnych profesných rolí: * iniciátor, inovátor, sudca, encyklopedista, harmonizátor, kronikár(všetko si pamätá), navigátor, štoural, ťahač d) Delenie na základe neoficialných škodlivých rolí: * sebec, agresor, negativista, tlachal, panikár, playboy, kanaďan(vtipmi uráža ostatných) ===== Vedoucí týmu ===== Úspěch týmu silně závisí na //vedoucím// týmu. Vedoucí bývá přirozeně osoba, jehož rozhodnutí nebo doporučení bývají často respektována - nazývá se //vedoucí de facto//. Je výhodné aby byl zároveň vedoucím //de jure// neboli zvolen oficiálně organizací. Existují i týmy, kde mohou být tyto role odděleny a tito dva vedoucí musí respektovat své vzájemné role. Vedoucí de facto musí chápat potřebnost administrativy a vedoucí de jure musí ustoupit v technických otázkách. Vedoucí by měl budit pocit, že je platným členem týmu. Má být schopen najít svého zástupce a spolupracovat s ním. Za hlavní psychologické rysy osobnosti patří: * Odborná a organizační kompetentnost * Tvrdohlavost, ne však arogance * Schopnost najít správné lidi a stanovit jim adekvátní úkoly * Být příkladem * Nepanikařit. Podržet tým při neúspěchu **Petriho princíp** -- Zamestnanec je povyšovaný až dokým na pozíciu nestačí ===== Organizace SW týmů ===== Ke struktuře týmu je třeba zmínit princip //minimaxu//. Při tomto manažerském přístupu se rozhodnutí volí tak, aby maximální možná ztráta byla minimální. Pro příklad si představme špičkového programátora který sám pracuje na důležitém projektu. Takový programátor může zastat mnoho průměrných programátorů (poměr 1:20 není neobvyklý), nicméně maximální možná ztráta právě tohoto zaměstnance. Z principu //minimaxu// tedy vyvodíme, že je lepší více průměrných programátorů. Ovšem i přístup minimaxu má své nevýhody - několik průměrných programátorů pravděpodobně stvoří pouze průměrný produkt, využití kvalitního programátora se dá parafrázovat větou "risk je zisk". Existuje několik základních typů organizace SW týmu. * **horda** historicky nejstarší a práce se v ní rozprostře rovnoměrně mezi několik nebo mnoho programátorů a každý z nich řeší svůj díl od počáteční analýzy, přes algoritmizaci až po odladění. Ač není nutné tuto organizaci týmu zavrhovat, tak sebou nese velké úskalí, že z členů týmu se stanou osamělí vlci, pracující na vlastní pěst. S prací pak končí ve chvíli, kdy je přestane bavit - typicky dlouho před dokončením projektu. * **demokratická skupina** funguje dobře pouze pokud je tvořena schopnými pracovníky. Nesmí být příliš velká a nesmí pracovat na ostrých termínech. * **tým šéfprogramátora** je výhodný, pokud je k dispozici několik vynikajících odborníků a poměrně mnoho relativně nezkušených pracovníků. V takovém týmu se dají řešit středně velké problémy * **supertým** Opravdu velké problémy. Je to spojení více týmů, kde každý tým má určité kompetence. * **osamelý vlk** neznesiteľní jedinci môžu byť vyčlenený z tímu a pracovať samostatne ===== Ostatní aspekty práce v týmu ===== V týmech se mohou objevit podvědomá schémata chování, tzv. //psychohry//. Nejčastěji se vyskytuje hra //alkoholik//. Nevýkonný pracovník je alkoholik kterého se snaží napravit vedoucí. Ve špatných zvyklostech ho udržuje //utěšovatelka// tím že mu říká "oni pro tebe nemají pochopení" a kamarádi, kteří alkoholika přesvědčují, že o nic nejde. Další zajímavá hra je "beru vše" - člen týmu, co přijímá stále nové úkoly a pak se vymlouvá na přetížení. ===== Předměty ===== [[https://is.muni.cz/auth/predmet/fi/podzim2011/PA102|FI:PA102]] Technologie informačních systémů I., prof. RNDr. Jaroslav Král, DrSc. [[https://is.muni.cz/auth/predmet/fi/jaro2012/PA105|FI:PA105]] Technologie informačních systémů II., prof. RNDr. Jaroslav Král, DrSc. ===== Zdroje ===== Informační Systémy, prof. RNDr. Jaroslav Král, DrSc., 1998 [[http://fi.muny.cz/statni-zkouska-magisterska-aplikovana-informatika-szmap/| FI MUNY]] [[http://fi.muny.cz/technologie-informacnich-systemu-i-pa102/| Vypracované otázky k PA102]] [[http://fi.muny.cz/technologie-informacnich-systemu-ii-pa105//| Vypracované otázky k PA105]] ===== Přílohy ===== {{:mgr-szz:in-ins:2.pdf|}} -- rozšíření některých témat a soukromé zpracování, vycházelo se z této wiki na přelomu roku 2013/2014. Nekonzultováno s kantory. ===== Vypracoval ===== Filip Nguyen (nguyen.filip@mail.muni.cz), hotovo ~~DISCUSSION~~