Informační systémy (IS)

Klíčové pojmy

data · informace · znalosti · DIKW · informační systém · hardware · software · orgware · peopleware · dataware · TPS · MIS · DSS · EIS · ERP · CRM · SCM

Výklad látky

1. Data – informace – znalosti (model DIKW)

• Data – surová fakta, čísla, znaky bez kontextu ("37,2").
• Informace (information) – data zasazená do kontextu, mající význam pro příjemce ("pacient má teplotu 37,2 °C – mírně zvýšenou").
• Znalosti (knowledge) – zobecněné informace + zkušenost, umožňují rozhodovat ("mírně zvýšená teplota po operaci je v prvních dnech běžná, není třeba zasahovat").
• Moudrost (wisdom) – schopnost znalosti správně použít; vrchol pyramidy DIKW.

2. Definice informačního systému

Informační systém je uspořádaný soubor lidí, technických prostředků, programů, dat a metod, zajišťující sběr, přenos, uchování, zpracování a prezentaci informací pro potřeby rozhodování a řízení.

3. Komponenty IS

• Hardware – technické prostředky (servery, sítě, koncová zařízení).
• Software – programové vybavení (systémové i aplikační).
• Dataware – data a jejich organizace (databáze, datové sklady).
• Peopleware – lidé: uživatelé, správci, analytici.
• Orgware – organizační pravidla, směrnice, procesy (kdo, co, kdy a jak v systému dělá).
• Důležité: IS ≠ software. Software je jen jedna z pěti složek.

4. Klasifikace IS podle úrovně řízení (pyramida)

• Operativní úroveň – TPS (Transaction Processing Systems): zpracování každodenních transakcí (pokladna, objednávky, docházka). Velké objemy dat, rutinní operace, důraz na rychlost a spolehlivost.
• Taktická úroveň – MIS (Management Information Systems): souhrnné reporty pro střední management (měsíční tržby dle poboček).
• Strategická úroveň – DSS/EIS (Decision Support / Executive IS): podpora rozhodování vrcholového vedení, analýzy, prognózy, "co-kdyby" scénáře, přehledové dashboardy.
• Směrem vzhůru: méně dat, více agregace, menší strukturovanost úloh.

5. Typy IS podle zaměření

• ERP (Enterprise Resource Planning) – integrovaný systém řízení podniku (finance, sklady, výroba, mzdy). Příklady: SAP, Microsoft Dynamics, Helios, Money.
• CRM (Customer Relationship Management) – řízení vztahů se zákazníky (evidence kontaktů, obchodních příležitostí, marketing).
• SCM (Supply Chain Management) – řízení dodavatelského řetězce.
• Další: docházkové a mzdové systémy, e-shop, rezervační systémy, školní IS (Bakaláři, Edookit), státní IS (registry, datové schránky).

Příklady z praxe

• Pokladna v supermarketu (TPS): markování zboží = transakce; zároveň krmí daty vyšší úrovně (MIS report prodejů – strategické rozhodnutí o otevření nové pobočky z EIS analýz).
• DIKW na školním příkladu: "3" (údaj) – "Novák má z matematiky trojku" (informace) – "Novákovi klesá průměr tři čtvrtletí po sobě, hrozí reparát, nabídneme doučování" (znalost + rozhodnutí).

Zajímavosti / historky

• ERP systémy jsou evolučními "potomky" systémů MRP (Material Requirements Planning) z 60.–70. let, které původně jen hlídaly, kolik materiálu je potřeba objednat pro výrobu. Postupným přibalováním dalších agend (finance, mzdy, prodej) vznikly dnešní ERP giganty řídící celé korporace.
• Firmu SAP založilo v roce 1972 pět bývalých zaměstnanců IBM v Německu. Jejich revoluční nápad: zpracovávat podniková data v reálném čase na obrazovce, zatímco tehdejší standard bylo dávkové zpracování přes noc z děrných štítků. Z pětičlenného startupu je dnes jeden z největších softwarových koncernů světa.

Klíčové pojmy

životní cyklus IS (SDLC) · studie proveditelnosti · funkční a nefunkční požadavky · AS-IS · TO-BE · specifikace požadavků · architektura · datový model · prototyp

Výklad látky

1. Přehled životního cyklu IS (SDLC)

1. Plánování / iniciace – proč systém vůbec chceme?
2. Analýza – co má systém dělat?
3. Návrh (design) – jak to bude řešeno?
4. Implementace – vytvoření systému.
5. Testování – ověření správnosti.
6. Nasazení – uvedení do provozu.
7. Provoz a údržba – nejdelší fáze cyklu.
8. Vyřazení – ukončení provozu, migrace na nástupce.

2. Plánování / iniciace

• Identifikace potřeby (problém nebo příležitost), definice cílů a přínosů.
• Studie proveditelnosti (feasibility study): technická (umíme to?), ekonomická (vyplatí se to? – hrubý odhad nákladů a přínosů, návratnost), časová, legislativní, personální proveditelnost.
• Rozhodnutí: vyvíjet na míru × koupit hotové řešení × pronajmout jako službu (SaaS).

3. Analýza

• Analýza současného stavu (AS-IS): jak procesy fungují dnes, kde jsou slabá místa.
• Sběr požadavků: rozhovory s uživateli, dotazníky, pozorování práce, studium dokumentů, workshopy.
• Funkční požadavky – co má systém dělat ("systém umožní vystavit fakturu").
• Nefunkční požadavky – jaké má mít vlastnosti: výkon (odezva do 2 s), bezpečnost, dostupnost (99,9 %), použitelnost, kapacita, soulad s legislativou (GDPR).
• Výstup: specifikace požadavků – závazný dokument, o který se opírá vše další (i smlouva s dodavatelem).

4. Návrh (design)

• Návrh cílového stavu (TO-BE): budoucí podoba procesů se systémem.
• Architektura systému – rozdělení na moduly/vrstvy (typicky: prezentační vrstva – aplikační logika – databáze), volba technologií.
• Datový model – návrh databáze (entity, vztahy – detailně v hodině 6).
• Návrh uživatelského rozhraní – drátěné modely (wireframes), prototyp k odsouhlasení uživateli.
• Návrh rozhraní na okolní systémy (propojení s bankou, dopravci, státní správou).

5. Proč je analýza kritická

• Chyba v požadavcích se propisuje do všech dalších fází; čím později se odhalí, tím dražší je oprava.

Příklady z praxe

• Feasibility study "e-shop": firma zvažuje vývoj na míru (vysoké náklady, plná kontrola) vs. krabicové řešení typu Shoptet (rychlé, levné, ale omezené přizpůsobení) vs. open-source WooCommerce (střední cesta). Porovnání nákladů, času, rizik, personálu.
• AS-IS/TO-BE: papírová kniha docházky (AS-IS: pozdní přepisy, chyby, žádné statistiky) – čipový docházkový systém (TO-BE: automatické podklady pro mzdy, přehledy přesčasů).
• Ukázka mini-specifikace (rozdat/promítnout): 5 funkčních + 5 nefunkčních požadavků na rezervační systém školních učeben; žáci určují, který požadavek je funkční a který nefunkční.

Zajímavosti / historky

• V softwarovém inženýrství se traduje pravidlo o rostoucí ceně chyby: oprava chyby odhalené až v provozu je řádově 10× až 100× dražší než oprava téže chyby ve fázi analýzy (přesný násobek se studie od studie liší, řádový trend ale potvrzují opakovaně). Proto se vyplácí investovat do analýzy dřív, než se napíše první řádek kódu.
• Mars Climate Orbiter (1999): NASA přišla o sondu za více než 300 milionů dolarů, protože jeden tým počítal v metrických a druhý v anglosaských jednotkách – chyba v rozhraní mezi systémy, která měla být odhalena už ve specifikaci. Dodnes jeden z nejcitovanějších příkladů toho, proč se požadavky a rozhraní musí definovat naprosto přesně.

Aktivita

Dvojice sepíší 3 funkční a 3 nefunkční požadavky na "aplikaci školní jídelny"; společná kontrola se zaměřením na měřitelnost nefunkčních požadavků ("rychlý" ne, "odezva do 2 sekund" ano.)

Klíčové pojmy

implementace · jednotkový/integrační/systémový/akceptační test · verifikace · validace · nasazení · souběžný/pilotní/postupný/přímý přechod · helpdesk · SLA · korektivní/adaptivní/perfektivní/preventivní údržba · migrace dat

Výklad látky

1. Implementace

• Programování, konfigurace hotových produktů, tvorba databáze, integrace komponent, tvorba dokumentace.
• Souběžně vzniká uživatelská dokumentace a školicí materiály.

2. Testování

• Úrovně testů:
  • jednotkové (unit) – jednotlivé funkce/moduly, provádějí vývojáři,
  • integrační – spolupráce modulů mezi sebou (rozhraní!),
  • systémové – celý systém proti specifikaci,
  • akceptační (UAT) – provádějí budoucí uživatelé; podmínka převzetí díla.
• Verifikace = "děláme systém správně?" (soulad s návrhem) × validace = "děláme správný systém?" (soulad s potřebami uživatele). Systém může projít verifikací a přesto být k ničemu, pokud analýza špatně zachytila potřeby.
• Black-box vs. white-box testování (návaznost na "černou skřínku" z okruhu 1).

3. Strategie nasazení (přechodu na nový systém)

4. Provoz

• Monitoring (dostupnost, výkon, bezpečnostní incidenty), zálohování, podpora uživatelů (helpdesk, úrovně podpory L1/L2/L3).
• SLA (Service Level Agreement) – smluvně garantovaná úroveň služby (dostupnost 99,9 %, reakce na kritickou závadu do 4 hodin…).

5. Údržba (nejdelší a souhrnně nejdražší fáze!)

• Korektivní – opravy chyb nalezených v provozu.
• Adaptivní – přizpůsobení změnám okolí: nová legislativa (DPH, GDPR), nový OS, nové rozhraní banky.
• Perfektivní – vylepšování na základě požadavků uživatelů (nové funkce, lepší UI).
• Preventivní – úpravy předcházející budoucím problémům (refaktoring, výměna zastarávající komponenty).
• Přes celkový životní cyklus spotřebuje údržba typicky větší část celkových nákladů na systém než samotný vývoj.

6. Vyřazení (ukončení životního cyklu)

• Morální zastarání (systém už neodpovídá potřebám / nelze rozvíjet) vs. fyzické zastarání (neudržovatelné technologie).
• Migrace dat do nástupnického systému – často podceňovaná a riziková část (čištění dat, převodní můstky, ověření úplnosti).
• Archivace dle zákonných lhůt (účetnictví, personalistika).

Příklady z praxe

• Škola přechází na nový školní IS: typicky souběžný nebo pilotní provoz – jeden klasifikační pololetí se známky vedou v obou systémech a porovnávají se.
• Adaptivní údržba v ČR: hromadné úpravy účetních softwarů při změnách sazeb DPH, zavedení EET, nástupu GDPR nebo datových schránek – dodavatelé rozesílají povinné aktualizace všem zákazníkům.
• Akceptační testování: účetní (ne programátor!) projde v novém systému kompletní měsíční uzávěrku a teprve pak firma dílo převezme a doplatí.

Zajímavosti / historky

• Problém Y2K: kvůli úspoře tehdy drahé paměti ukládaly starší systémy rok jen dvěma číslicemi ("99"). Hrozilo, že "00" systémy vyhodnotí jako 1900 – s dopady na úroky, řazení, plánování. Celosvětové náklady na prověrky a úpravy (obří akce adaptivní údržby) se odhadují na stovky miliard dolarů. Protože k velkým haváriím nakonec nedošlo, dodnes se vedou spory, zda šlo o zbytečnou paniku, nebo o největší úspěšně zvládnutý údržbový projekt historie – pravda je nejspíš blíž druhé možnosti.
• NHS National Programme for IT (Velká Británie): megaprojekt centralizace zdravotnických IS byl v roce 2011 po letech problémů z velké části zrušen; utopeny byly miliardy liber. Mezi příčinami: přehnaně ambiciózní rozsah, nedostatečné zapojení koncových uživatelů (lékařů) do analýzy a problematické nasazování do reálného provozu nemocnic. Učebnicový příklad, že u IS neselhávají primárně technologie, ale řízení projektu a práce s lidmi.

Klíčové pojmy

metoda · metodika · metodologie · vodopádový model · iterace · inkrement · spirálový model · agilní vývoj · Agilní manifest · Scrum (sprint, backlog, Product Owner, Scrum Master) · Kanban · WIP limit · strukturovaný vs. objektový přístup

Výklad látky

1. Vymezení pojmů

• Metoda – konkrétní postup řešení dílčího úkolu (např. metoda interview pro sběr požadavků).
• Metodika – ucelený, doporučený soubor metod, rolí a postupů pro celý vývoj (např. Scrum).
• Metodologie – nauka o metodách; v praxi se ale slova metodika/metodologie často zaměřují.

2. Vodopádový model (Waterfall)

• Fáze SDLC (SW Development life Cycle - Životní cyklus vývoje softwaru) probíhají přísně za sebou; další fáze začíná až po dokončení a schválení předchozí; návrat zpět je nákladný.
• Výhody: přehlednost, snadné plánování a kontrola, důkladná dokumentace – vhodné tam, kde jsou požadavky stabilní a známé předem a kde to vyžadují normy (letectví, zdravotnická technika, jaderná energetika, velké státní zakázky).
• Nevýhody: uživatel vidí funkční systém až na konci; pozdní odhalení nedorozumění v požadavcích; špatná reakce na změny.

3. Iterativní a inkrementální vývoj

• Iterace – opakovaný cyklus (analýza–návrh–implementace–test) v krátkých kolech; každé kolo zpřesňuje výsledek.
• Inkrement – každé kolo dodá další funkční kus systému, který lze ukázat/používat.
• Spirálový model (Barry Boehm, 1986): iterace + v každém závitu spirály explicitní analýza rizik; vhodný pro velké, rizikové projekty.

4. Agilní metodiky

• Agilní manifest (2001): 4 hodnoty – (1) jednotlivci a interakce před procesy a nástroji, (2) fungující software před vyčerpávající dokumentací, (3) spolupráce se zákazníkem před vyjednáváním o smlouvě, (4) reagování na změnu před dodržováním plánu. (Pravá strana má hodnotu, levá větší.)
• Scrum:
  • práce v časově pevných sprintech (typicky 2 týdny), každý sprint končí předvedením přírůstku,
  • product backlog – prioritizovaný seznam požadavků; sprint backlog – výběr pro daný sprint,
  • role: Product Owner (zastupuje zákazníka, prioritizuje), Scrum Master (chrání proces a tým), vývojový tým,
  • rituály: plánování sprintu, denní stand-up (15 min), review, retrospektiva.

• Kanban: vizualizace toku práce na tabuli (To Do – In Progress – Done), WIP limit (omezení počtu rozpracovaných úkolů) – plynulý tok místo pevných sprintů; vhodný pro údržbu a provoz.

• Agilní ≠ bez disciplíny: pravidla jsou jiná, ne žádná.

5. Strukturovaný vs. objektově orientovaný přístup

• Strukturovaný (70.–80. léta): odděluje data a funkce; nástroje DFD, ERD (bude probíráno dále).
• Objektově orientovaný (od 90. let): svět modeluje jako objekty spojující data + chování; jazyk UML (bude probíráno dále).

6. Volba metodiky

• Kritéria: stabilita požadavků, velikost a rozptýlení týmu, kritičnost systému (ohrožení života/majetku), požadavky norem, zapojení zákazníka.
• Neexistuje univerzálně "nejlepší" metodika; velké firmy dnes často kombinují (hybridní přístupy).

Příklady z praxe

• Vodopád: software řídicího systému jaderné elektrárny – požadavky dané normami, změny za chodu nepřípustné, nutná úplná dokumentace pro certifikaci.
• Scrum: tým vyvíjející mobilní aplikaci – dvoutýdenní sprinty, po každém sprintu funkční nová verze pro zákazníka, priority se průběžně mění podle zpětné vazby uživatelů.
• Kanban: tým správy a údržby IS – požadavky (tickety) přicházejí průběžně, tabule v Jira/Trello, WIP limit brání rozdělanosti deseti věcí najednou.

Zajímavosti / historky

• Slovo "Scrum" pochází z ragby – označuje mlýn, semknutou formaci hráčů tlačících se společně za míčem. Do vývoje produktů ho přenesli v roce 1986 Japonci Takeuchi a Nonaka článkem "The New New Product Development Game": pozorovali, že nejúspěšnější týmy (Honda, Canon...) nepracují štafetově (oddělení si předávají práci jako kolík – v podstatě vodopád), ale jako ragbyová formace – celý tým postupuje vpřed společně.
• Agilní manifest vznikl v únoru 2001 na horské chatě ve Snowbirdu (Utah), kde se sešlo 17 vývojářů do té doby konkurenčních "lehkých" metodik (mj. tvůrci Scrumu a Extreme Programming). Chtěli najít, co mají společného – výsledkem je dokument o pár větách, který změnil způsob práce softwarového průmyslu na desítky let dopředu. Historickou kuriozitou je, že se účastníci dodnes neshodnou, kdo přesně navrhl slovo "agile".

1. IS jako projekt

• Projekt = dočasné úsilí s jedinečným cílem, definovaným začátkem/koncem, rozpočtem a zdroji (× rutinní provoz, který je opakovaný a trvalý).
• Tvorba IS je typický projekt; jeho provoz už je proces.

2. Trojimperativ projektu

• Trojúhelník ČAS – NÁKLADY – ROZSAH (kvalita): veličiny jsou provázané, změna jedné vyvolá tlak na ostatní.
• "Rychle, levně, kvalitně – vyberte si dvě." Zkrácení termínu = dražší (více lidí, přesčasy) nebo osekání rozsahu.

3. Role v projektu tvorby IS

• Sponzor – zadavatel z vedení; financuje, odstraňuje překážky, dělá zásadní rozhodnutí.
• Projektový manažer – odpovídá za dodání v čase/rozpočtu/rozsahu; plánuje, řídí, reportuje.
• Byznys analytik – překladatel mezi světem uživatelů a světem IT; sbírá a formalizuje požadavky.
• Architekt – navrhuje technické řešení a technologie.
• Vývojáři, testeři – realizace a ověřování.
• Klíčoví uživatelé – zástupci budoucích uživatelů; dodávají znalost procesů, provádějí akceptační testy.

4. Plánování projektu

• WBS (Work Breakdown Structure) – hierarchický rozklad díla na dodávky – balíky práce – úkoly (aplikovaná dekompozice z okruhu 1!).
• Ganttův diagram – úkoly na časové ose, závislosti mezi nimi, milníky (klíčové kontrolní body).
• Kritická cesta – řetězec úkolů, jejichž zpoždění posune celý projekt; těmto úkolům patří největší pozornost.
• Alokace zdrojů: lidé, rozpočet, technika; pozor na přetížení klíčových lidí.

5. Řízení rizik

• Cyklus: identifikace – analýza (pravděpodobnost × dopad) – plán reakce – sledování.
• Matice rizik (pravděpodobnost × dopad, např. 3×3) – vizuální prioritizace.
• Strategie reakce: vyhnutí se, zmírnění, přenesení (pojištění, smluvní pokuty dodavateli), akceptace.

6. Řízení změn (change management požadavků)

• Změny požadavků v průběhu projektu jsou nevyhnutelné – nesmí ale probíhat živelně.
• Formální proces: změnový požadavek – posouzení dopadu (čas? náklady? rozsah?) – schválení změnovou komisí – úprava plánu a smlouvy.
• Neřízené přibývání požadavků = "scope creep" (plíživé bobtnání rozsahu) – jedna z nejčastějších příčin selhání projektů.

7. Komunikace a akceptace

• Pravidelné statusy/reporty sponzorovi, řídicí výbor, eskalace problémů.
• Akceptační řízení – formální převzetí díla na základě splnění akceptačních kritérií.

Příklady z praxe

• Matice rizik pro projekt nového školního IS: "klíčový vývojář onemocní" (střední pravděpodobnost, vysoký dopad – zástupnost, dokumentace), "škola nedodá včas data o učebnách" (vysoká/střední – eskalace na sponzora), "výpadek serveru při ostrém startu" (nízká/vysoký – záložní prostředí).
• Scope creep v praxi: zákazník v polovině vývoje e-shopu "jen doobjedná" věrnostní program a mobilní aplikaci – bez změnového řízení projekt nabere zpoždění a překročí rozpočet, se změnovým řízením se dohodne nový termín a cena.

Zajímavosti / historky

• CHAOS Report (Standish Group) sleduje úspěšnost IT projektů od roku 1994. Dlouhodobě ukazuje, že plně úspěšná (v čase, rozpočtu i rozsahu) je jen menšina IT projektů; velká část je "challenged" (dokončené s prodražením/zpožděním/osekáním) a nezanedbatelné procento se ruší úplně. Zpráva je nejcitovanějším argumentem, proč projektové řízení, řízení rizik a change management nejsou byrokracie, ale nutnost. Zajímavé také je, že menší projekty vykazují dlouhodobě výrazně vyšší úspěšnost než megaprojekty – další argument pro inkrementální dodávání.
• Zavazadlový systém letiště Denver (90. léta): plně automatizované třídění zavazadel mělo být chloubou nového letiště. Podcenění složitosti, nerealistický harmonogram a nedostatečné testování vedly k legendárním záběrům rozhazovaných kufrů, zpoždění otevření letiště o cca 16 měsíců a stamilionovým vícenákladům (údržba nefunkčního letiště stála asi milion dolarů denně). Systém byl nakonec provozován jen omezeně a později zcela opuštěn. Učebnicový příklad selhání odhadu rozsahu, řízení rizik a testování.

Klíčové pojmy

model · abstrakce · ER diagram · entita · atribut · vztah · kardinalita (1:1, 1:N, M:N) · DFD · proces · datový tok · datové úložiště · terminátor · UML · use case · aktér · diagram tříd · vývojový diagram

Výklad látky

1. Proč modelujeme

• Model = zjednodušené, účelové zobrazení reality (abstrakce – vynecháváme nepodstatné).
• Funkce modelu: společný jazyk analytika, vývojáře a zákazníka; odhalení nejasností dřív, než se draze naprogramují; dokumentace.
• Přímá vazba na okruh 1: model zachycuje prvky, vazby, hranici a chování systému.

2. Datové modelování – ER diagram (Entity-Relationship)

• Entita – objekt reálného světa, o němž evidujeme data (ŽÁK, TŘÍDA, PŘEDMĚT).
• Atribut – vlastnost entity (jméno, datum narození); primární klíč – atribut jednoznačně identifikující výskyt entity (rodné číslo, ID).
• Vztah – vazba mezi entitami; kardinalita:
  • 1:1 – žák – přihláška na konkrétní zkoušku,
  • 1:N – třída má N žáků, žák patří do 1 třídy,
  • M:N – žák studuje více předmětů, předmět studuje více žáků (v databázi se řeší vazební tabulkou – jen zmínit, detail patří do databází).
• ER diagram je předstupněm návrhu databáze (stručně zmínit normalizaci jako téma navazujícího učiva o databázích).

3. Funkční/procesní modelování – DFD (Data Flow Diagram)

• Čtyři stavební prvky:
  • proces (kruh/oblý obdélník) – činnost transformující data ("Zpracovat objednávku"),
  • datový tok (šipka) – pohyb dat,
  • datové úložiště (otevřený obdélník) – kde data leží ("Databáze objednávek"),
  • terminátor / vnější entita (obdélník) – okolí systému ("Zákazník", "Banka") – přímá aplikace pojmů okolí a hranice systému!
• Úrovně DFD: kontextový diagram (celý systém jako 1 proces – černá skřínka) – úroveň 0 – detailnější úrovně (aplikovaná dekompozice).
• Doplněk: vývojový diagram (flowchart) – detailní algoritmus jednoho procesu (žáci znají z programování – propojit).

4. Objektové modelování – UML (Unified Modeling Language)

• Standardní grafický jazyk pro modelování softwaru; obsahuje kolem desítky typů diagramů, pro nás nejdůležitější:
  • Use case diagram: aktéři (panáčci – role uživatelů či okolní systémy) + případy užití (elipsy – co systém umožňuje) + hranice systému (rámeček). Odpovídá na otázku "k čemu systém slouží a komu".
  • Zmínka: diagram tříd (statická struktura – obdoba ER pro objekty), sekvenční diagram (časový průběh komunikace).