Pisemky-reseni-1x2

y orientované (je např. OO). Různí partneři požadují různé rozhraní -Řešení: Infra služba jako přeřazená brána.
Prototypování, ladění RT systémů: viz. obr... Zprávy lze přesměrovat beze změny implementovaných služeb buď na uživatelské rozhraní (efektivní prototyp, použitelné i za běhu
systému), nebo dokonce na simulátor (ladění RT systémů)Zajímavý obrat – jak zjistit při dobu odezvy za nepřítomnosti řízené soustavy. Řešení: Kalendář
událostí v simulátoru, simulátor má nejvyšší priorituNouzové základní brány: Aplikace nemusí být vybavena branou, jak doplnit? Mám zdroje –
upravím programy. Odposlech na rozhraní UR * aplikační vrstva. Odposlech terminálu.Patterns a antipatterns: Antipatterns jsou takové prohřešky, které při vývoji OO systémů vedou
s velkou pravděpodobností k selhání projektu. Některé jsou fatální vždy (chybné specifikace), jiné platí spíše pro monolitické systémy, Některé objektové antipatterns jsou v prostředí SOA
předností. Snadná prevence následujících antipatterns: Plánování bez konce (lze prosadit rychlou
realizaci jádra systému výběrem nejužitečnějších služeb ). Obtížný člen týmu (dáme mu vyvinout autonomní službu). Dlouhé termíny než je systém funkční. Návrh výborem který fakticky za nic
neručí (nelze se se vymlouvat na fakt, že ještě nic nefunguje). Znovu vynalézat kolo (snadno používáme existující aplikace). Vendor lock-in - závislost na jednom dodavateli (lze doplňovat
produkty třetích stran a nově vyvinuté komponenty)Antipatterns, které mají v SO jen omezený vliv, nejsou tedy v pravém smyslu antipatterns:
Změna metodik vývoje během řešení. Nedotýkají-li se změny infrastruktury systému nebo vývoje dané komponenty a jsou skryty za rozhraním. Vystřihovánky (volné kombinování) na
úrovni služeb.
26. Hackerský syndrom
Příznaky: Raději práce s počítači než diskuse s lidmi, nemilují práci v týmu. Tendence k černobílému uvažování. Přeceňování čistě informatických znalostí a schopnosti programovat. V
tomto ohledu může málokdo našim programátorům vyrovnat, snadno seženou dobrý job. Práci považují hlavně za fascinující intelektuální hru.
Positivní – tvorba volně šiřitelného softwaruNegativní – tvorba virů, trojských koní a někdy přímo kriminalita
Podceňování neinformatických oborů, znalostí a schopností koncových uživatelů a významu spolupráce s nimi. Odpor k filosofii experimentálních věd a zvláště k matematické statistice jako
nástroji analýzy dat. To je ale nutné k podpoře managementu uživatele i vlastní firmy. Bez toho nelze kvalifikovaně hodnotit kvalitu softwaru a zlepšovat procesy vývoje SW. Je to nutný
předpoklad k porozumění potřebám zákazníků. Kvalita dat zásadním způsobem ovlivňuje specifikaci požadavků (kritický řetěz při řízení projektů, rozvrhování, atd. bude diskutováno níže)
Další vlastnosti „hackera“: Neochota pracovat v týmu. Odpor k dokumentování (někdy i oprávněný - viz zásady agilního vývoje). Tendence jít hned na věc a nebabrat se se specifikacemi
požadavků (a tedy strategie pokus-omyl). Při moderních principech vývoje, např. při servisní orientaci, lze snáze používat (agilní formy vývoje). Obtíže při přijímání filosofie moderních
směrů v softwaru, např. servisní orientace. Neochota aplikovat p2p přístup. Neochota používat existující aplikace a produkty třetích stran.. Neochota používat „zastaralé“ technologie a
kombinovat datový a příkazový přístup a existující aplikace. Snaha neopouštět kyberprostor (svět počítače). Extrém – rande u počítače s videem.
Proč třeba prevence, když dobrý programátor najde práci všude: HS blokuje uplatnění v kvalifikovanějších rolích při vývoji softwaru (analytik, vedoucí projektu, SW architekt). Z toho
důvodu se jako vedoucí IT oddělení a IT projetů se často uplatňují lidé, kteří studovali něco jiného než informatiku, nebo ji studovali na VŠE. Zhoršuje adaptibilitu na změny na trhu práce
(dnešní studenti půjdou do důchodu po více než 40 létech, programátorská virtuosita se ztrácí v 35 létech, schopnost analýzy se ztrácí později, viz praxi IBM, kde se zbavují třicátníků, jsou
výjimky), je proto velmi žádoucí, aby se neuzavírala možnost uplatnění mimo informatiku. Pro to je dobrou průpravou práce analytika – má i jiné dovednosti než ty, které se uplatní jen při práci s
počítačem. Délka profesní kariéry mezi 25 až 50 roky. Během této doby dojde k významným změnám na trhu práce.
Těžko se léčí, raději prevence: Predispozice a důvod volby dráhy informatika při rozhodování, co studovat. Nevíme, jaké je rozložení talentů a zda se prevence vyplatí. Utvrzován běžnou praxí
výuky. Ve výuce je obtížné navodit situace ukazující např. potřebu spolupráce s koncovými uživateli nebo dokumentování. Často spojen s programátorskou virtuozitou – zatím cesta k
dobrým rychlým výdělkům (a k podceňováním studia a hlubších znalostí v informatice a hlavně mimo informatiku).
28. Metody získávání informací od zákazníka (interview ...), klady a zápory
Varianta porady, kde se jedni převážně ptají a druzí odpovídají. Ve dvou (moderátor a respondent). Skupinové.
Zdálo by se, že vypracování "Specifikace požadavků" by mělo být výhradním dílem budoucího uživatele. Podle zkušeností však specifikace požadavků zákazníkem značně zvyšuje pracnost
realizovaného systému a především zvětšuje pravděpodobnost neúspěchu. Příčiny této situace jsme diskutovali na více místech. Shrňme je nyní:
Uživatel nebývá schopen omezit požadavky na rozumné minimum. Nevylučují se požadavky méně potřebné až neužitečné (syndrom dortu pejska a kočičky). Může být nepříznivě ovlivněno
těmi „co jsou při tom“. Uživatelé jsou si zřídka plně vědomi vlastností, možností a omezení moderních informačních technologií (zvláště u customizovaných IS).
Uživatele nemají dostatek zkušeností pro vypracování uceleného systému požadavků (jako slohové práce).Nezřídka jim chybí komplexní znalosti o fungování vlastního podniku na
mikroúrovni a top úrovni. Nemají cit pro to, co lze použít, co lze snadno realizovat a kdy je realizace ohrožena. Je větší nebezpečí, že se do požadavků prosadí zájmy těch "co jsou u toho" a
budou opomenuti ostatní budoucí uživatelé systému.
Dokument "Specifikace požadavků" by měl proto být vypracován ve spolupráci pracovníků dodavatele s pracovníky uživatele a oponován managementem uživatele ale především
budoucími koncovými uživateli systému.
Role zákazníka při specifikaci požadavků v důsledku shromažďování zkušeností s provozem informačních systémů a možnostem, které nabízejí nové informační technologie, postupně
vzrůstá ale stále nestačí k tomu, aby specifikoval pouze zákazník. Asi tomu tak bude i v budoucnu. Optimální je, když jsou v týmu koncoví uživatelé, kteří mají trochu pojem o IT, ale
zajímají se o IT jako nástroje zlepšení své práce, a vývojáři, kteří rozumí problémům uživatele. Ze strany uživatele nebývají žádoucí počítačoví fandové (zajímají se o počítače a nikoliv o
zlepšení své „černé práce). Pozor na poučené laiky (Případ Olomouc), musí se účastnit koncoví uživatelé (obvykle ti koncoví uživatele s dosti vysokým postavením).
Předpoklady spolupráce uživatele na specifikaci: Pocit vlastnictví a a odpovědnosti za celek. Neegoistický přístup. Opravuje ten, komu to dá nejméně práce. Neprosazuje sobecká řešení z
důvodu nafoukanosti nebo lenosti. Mezi posuzovateli jsou ti, kteří budou závislí na kvalitě specifikací (uživatelé, řešitelé následných etap), ti budou mít zájem o kvalitní oponenturu.
Specifikace požadavků by měla být: úplná, testovatelná, bezesporná, konzistentní, modifikovatelná, vystopovatelná, využitelná i v době běhu systému, stabilní
29. 80-20 a kdy je použít. Jaké jsou komplikace při uzavírání smlouvy. Vztah k agilnímu vývoji.
Pareto zjistil, že u vývoje většiny systémů (nejen SW) 20% úsilí přináší 80% užitku. Málo potřebné a tedy většinou nedomyšlené funkce v IS dají většinou mnoho práce. Je tedy vhodné
funkce nebo požadavky uspořádat podle významu a od těch začínat budovat systém. To má následující výhody:
Zachytíme úzké místo ve smyslu Goldratta. Brzy dosáhneme použitelnosti. Zmenšíme nebezpečí implementace zbytečných a chybných funkcí. Nové funkce mohou využít zkušeností s provozem
existujících funkcí. Snížení problémů se zvládáním systémů (plošší křivka učení)
Je výhodné systém budovat postupně počínaje snadno implementovatelným jádrem, které je již ale rozumně použitelné. Takové jádro nazveme existenčním řešením. Podle zákona 80-20 může
již malé úsilí a investice přinést velmi významný efekt. Je ale nutné dobře odhadnout, co je nejpotřebnější. Podmínkou je vhodná architektura systému, souhlas uživatele a možnost uzavřít
rámcovou smlouvu. Tento princip je vhodné využít i při zavádění customizovaných systémů.Jádro by mělo pokrývat nejkritičtější požadavky
Problémy při uzavírání smlouvy: Agilní formy programování neřeší dostatečně problém formulace smlouvy externím partnerem. Je možné učinit dohodu, že se smlouva doplní v
okamžiku kdy se odevzdá nějaká komponenta a dohodne se další. To je ale dost riskantní pro obě strany a hlavně to neřeší otázku, jak reagovat na neustálé změny. Jednou z možností je, že se
řešitelský tým jakoby najme od dodavatele, nebo se skutečně najme nebo se použije vlastní IT oddělení. Ověřeno to ale není.
Problémy agilního přístupu: Vyžaduje kvalitní lidi. Vyžaduje rozsáhlé zapojení uživatelů. Nejasné jak agilně customizovat customizovatelné systémy (nějaké možnosti zřejmě jsou). Nelze
pro opravdu velké systémy, Servisní orientace tento problém zmírňuje. Nelze pro kritické systémy. Menší rizika jsou a vyšší možnosti pro agilitu nabízí SO, pro kritické systémy asi i
tehdy nevhodné.
Manifest:Individuals and interactions over processes and tools
Working software over comprehensive documentation Customer collaboration over contract negotiation
Responding to change over following a plan
30. Restrukturalizace podnikových procesů
Je velmi žádoucí nemodifikovat radikálně podnikové procesy (business process reingeneering, BPR), pokud to není absolutně nutné. V reálných situacích jsou v zemích, jako je ČR, BP skryty
v myslích lidí a založeny na zvládnutých dovednostech a mnohé není vůbec explicitně zaznamenáno, vybaví se až při vzniku určité situace = tvz. taktilní informace
Obtížnost BPR – případ NDR. Úplná restrukturalizace průmyslu NDR se ukázala jako neobyčejně drahá a velice dlouhodobá záležitost. Ani dnes po více než patnácti létech není jasné,
zda a kdy úspěšně skončí. Jisté náznaky zlepšení existují. Doměka: Struktura průmyslu se zcela rozbila a vybudování je úkol pro více než jednu generaci.
Cena změny: několik bilionů marek/euro (200 miliard marek ročně, fakticky třikrát tolik-
Studium známých případů BPR naznačuje, že jistější a často i efektivnější cesta než radikální (tvrdé) BPR je angažování kvalitního manažera. Revoluční změny podnikových procesů, jako
TQM (total quality management), často vedou ke zhoršení výsledků (výsledky průzkumu Gartner Group). Nové metody zavádějí nadprůměrní a mnoho dobrých výsledků se dosahuje
proto, že jsou nadprůměrní,měli by dobré výsledky i při používání jiných metod (viz školské reformy u nás)
Důvody selhání restrukturalizace: V déle existujících organizacích v Evropě je mnohé založeno na zkušenostech (vzpomenu si, co mám dělat až když nastane příslušná situace, taktilní
dovednost a znalost). V restrukturalizovaných procesech se tato znalost ztratí. Změna typu procesů vyžadující změnu kultury (s iniciativou/přesný). Nové principy a zásady nemusí být pro
danou situaci vhodné. Nové principy mohou být příliš jednostranné a poplatné módámKulturní bariéry. Nové nemusí být správně zvládnutelné s danými zaměstnanci (kvalifikace,
znalosti, školení, zvyky). Odpor zaměstnanců proti změnám při ohrožení jejích postů může být velmi účinný. Nové nelze bez účinné pomoci klíčových zaměstnanců vůbec implementovat.
Měníme jen to co je nezbytné: U BPR je možná buď úplná změna, ta je ale velmi riskantní (tvrdá varianta BPR). Nebo uplatnit měkkou variantu BPR, což je vhodné v případě, kdy jde o
celkem dobře fungující organizaci. Tehdy lze často postupovat tak, že se nasazení IS jeví jako informační podpora a jednoduchá modifikace dosavadních procesů, byť fakticky za změnou stojí
výkonná optimalizace. Takové BPR je levné a málo riskantní, nejde ale uplatnit vždy. Mohou následovat postupné modifikace za provozu.
plus domluva s managementem a jeho úkol
31. Co je to SOA + nákres
Soubor softwarových komponent spolupracujících obdobně jako služby reálného světa Všechny služby jsou stále aktivní. Vyřizují požadavky asynchronně. Konfederace – služby se
znají i aliance. Služby a infrastruktura, zajišťující jejich spolupráci (middleware), včetně možnosti čekání na odpověď. V prakticky použitelných systémech se SOA vztahuje pouze na
část systému. Jeho volnou součástí jsou dávkové části (export dat, hromadné výpočty, atd.)
Vlastnosti SOA IS: Virtuální peer-to-peer spolupráce autonomních komponent (autonomie využití a také vývoje) spolupracujících jako služby masové obsluhy, p2p je nutnou podmínkou,
aby se SW komponenty chovaly obdobně jako služby (v tom, co je služba není ještě mezi experty úplná shoda, pro nás autonomní komponenta, peer ve virtuální síti pracující asynchronně)
Dostupnost některých operací jinak obtížně realizovatelných (částečný outsourcing, decentralizace, podpora manažerských operací uživatelů obecně)
Výhodné SW-inženýrské vlastnosti (otevřenost, modifikovatelnost, metody oživování, znovupoužitelnost, úspory při vývoji a údržbě,…)
Použitelnost agilních forem vývoje ….
32. Organizační typy
Jednoduchá struktura: Nejsou explicite stanoveny role, vše na okamžité dohodě (jako tým je známo pod jménem horda)
Ad-hoc-kracie: Role se na jistou dobu dohodnou (demokratický tým)Nízká organizační pyramida, Dobře vyvinuta horizontální specializace (jaké typy činností kdo
dělá), málo vertikální (kdo koho řídí), vysoká flexibilita. Vhodná pro nová nikoliv extrémně velká řešení. Pro situace vyžadující přímou, častou a rozsáhlou komunikaci mezi pracovníky
Pro vývoj a výzkum, jsou-li k dispozici kvalitní lidé, pro agilní formy vývoje. Pro virtuální týmy spolupracující přes internet (GNU, virtuální ad-hoc-kracie)
Podmínky: Nekritické aplikace. Nepříliš tvrdé termíny. Kvalitní pracovníci. Nová řešeníDemokratický tým je typický pro menší SW firmy a SW týmy.
Strojová byrokracie: Vše přes společného šéfa, přísně stanovené role, typické pro vojenské jednotky. Centralizace: Vysoká org. pyramida, veškeré dohody přes nejnižšího společného šéfa,
jasně vymezení rolí a nadřízeností a podřízeností. Náplň práce je do značné míry určena postavením v pyramidě. Vhodné pro rychlou předem „nacvičenou“ reakci na známé situace a pro
spíše rutinní činnosti. Nutná v armádě. Často nutná u velkých organizací, pokud se nemohou, nebo nechtějí decentralizovat . Flexibilita závisí od kvality vedení, nebývá nikdy vysoká
Žádoucí podporovat iniciativu a horizontální vazby. strjová byrokracie a IT: Předpoklad, že IT sníží výšku pyramidy se potvrdil jen zčásti, spíše
usnadnil decentralizaci. IT usnadňuje vedení opravdu velkých organizací, podporuje horizontální spolupráci urychlením cest přes šéfy, často ale neformálně i přímo (horizontálně). Je nutno pro IT
získat šéfy. Je ale riziko, že se nedostaneme ke koncovým uživatelům. IT často ohrožuje střední management, bez něhož ale nelze systém specifikovat a uvést do provozu, jsou nutné
kompromisy (jen taková řešení, která ty střední manažery, které potřebujeme, ohrozí jen málo)
Profesní byrokracie: Pozice plyne z profesní způsobilosti (lékaři, akademická sféra, státní správa ). Pozice a pracovní náplň plyne z profesní způsobilosti nebo z politického pověření - z
„papíru“ (lékaři, akademická sféra, státní byrokracie). V části organizace je vždy nutná strojová byrokracie (důvodem je potřeba kontinuity a profesionality), s tou je vhodné domlouvat detaily
IS. Vedoucí bývají pověřeni vedením nebo zvoleni jen na určitou dobu. Není proto výjimkou, že nemají zájem o dlouhodobé projekty a často ani pro ekonomiku provozu.
Při budování IS je nutné balancovat mezi šéfy volenými a byrokraty. Rizika změny cílů na začátku dalšího volebního období. Bývají nejasnosti v dělbě pravomocí. Nebývá ochota efektivně
spolupracovat, tendence ke všimnému. Dosti obtížná varianta spolupráce.
Divizní struktura (decentralizace): V globalizovaném světě stále častější. Víceméně nutná pro opravdu velké organizace. Centrum stanovuje rámcové podmínky a alokuje zdroje, o které divize
fakticky bojují na základě svých výsledků, vizí a někdy i známostí. Divize si tedy mohou i tak trochu konkurovat (viz VW a Škoda Mladá Boleslav). Přechází až do spolupráce nezávislých
(dceřinných) organizací. Šetří náklady, zvyšuje otevřenost, zvyšuje flexibilitu včetně outsourcingu a insourcingu, prodeje a nákupu částí. Divizní struktura je hlavní oblast uplatnění
SW konfederací. IS budovány často zdola metodou pokusů a někdy i omylů. Důležitost vizí. IS usnadňují decentralizaci a organizační změny. Usnadňuje budování virtuálních sítí podniků
33. Jaké jsou nejčastější faktory krachu projektu
V roce 2003 podobný průzkum. Hlavní výsledky: Kvalita řešitelů není problém i nadále, význam kvality řešitelů se dále zmenšil (je samozřejmostí). Zesílil význam managementu, nástrojů a
technik Důležitá je standardní architektura systému a minimalizace jeho rozsahu. Hlavní problém je stále ve specifikacích požadavků, v jednání s uživateli a na straně managementu, Význam
kvalitního managementu roste a stává se klíčovým problémem. Malá role kompetentnosti řešitelů znamená, že je kompetentnost řešitelů standardem a možná se úkol řešitelů poněkud usnadnil
Jiné obtížně měřitelné vlivy: Velikost úkolu PROBLÉMEM. Potřeba nových technologiíNejasné a nepřímé efekty (globalizace). Existenční ohrožení (střední management) a ztráta
mocenských pozic (včetně ztráty informačního monopolu). Skrytá rizika (ztratí se staré znalosti)Nevhodná kombinace ručního a automatizovaného. Nutnost reakce na změny, lenost