Systémová analýza v IT

From Systems analysis wiki
Jump to navigation Jump to search

Systémová analýza v IT (Systems Analysis and Design) — přístup k navrhování a rozvoji informačních systémů od záměru až po provoz, zahrnující zjišťování potřeb, formalizaci požadavků, modelování předmětné oblasti a procesů, jakož i hodnocení alternativ a rizik. Jinými slovy, systémová analýza v IT je etapou vývoje, při níž specialisté studují úlohu, určují, co má systém dělat, a navrhují řešení pro jeho vytvoření.

Klasická systémová analýza zahrnuje široké spektrum oblastí použití, nejen vývoj softwaru, ale i organizační změny, strategie a další aspekty.[1] [2]

Předmět a úkoly systémové analýzy v IT

Předmětem systémové analýzy v IT je informační systém (softwarový produkt a/nebo služba) po celém životním cyklu — od záměru a zdůvodnění až po realizaci a provoz.

Úkolem systémové analýzy je přeměnit obchodní potřeby v konzistentní a ověřitelnou sadu požadavků a architektonických rozhodnutí: zjistit a zdokumentovat cíle a omezení stakeholderů, formalizovat požadavky, modelovat předmětnou oblast a procesy, posoudit proveditelnost a rizika alternativ a zdůvodnit zvolenou architekturu. Výsledkem jsou konzistentní dokumenty a jsou vytvořeny sledovatelné vazby mezi požadavky, projektovými rozhodnutími a testy. To zajišťuje řiditelnost a kontrolu nad procesem vývoje.

Úkoly systémové analýzy zahrnují:

  • Zjišťování potřeb a cílů stakeholderů. Analytik shromažďuje a upřesňuje očekávání zákazníků, uživatelů a dalších zainteresovaných stran; používají se rozhovory, dotazníky, pozorování a analýza stávajících procesů. Na výstupu se formuje primární specifikace požadavků s rozdělením na funkční („co má systém dělat") a nefunkční (spolehlivost, výkon, bezpečnost atd.).[1][2]
  • Formalizace a dokumentování požadavků. Požadavky jsou převáděny do ověřitelné podoby. Dobře formulovaný požadavek musí být jasný a jednoznačný, úplný, nerozporný, ověřitelný a sledovatelný k cílům vyšší úrovně; sada požadavků — konzistentní a celistvá.[3][4] V praxi se používají standardizované dokumenty: SRS (Software Requirements Specification) podle ISO/IEC/IEEE 29148, a také v některých odvětvích URS (User Requirements Specification) a funkční specifikace.[5][6][7]
  • Analýza a modelování systému. Pro pochopení toho, jak bude systém fungovat a interagovat s vnějším světem, se vytvářejí modely: diagramy případů užití (Use Case) pro scénáře použití, DFD pro toky dat a obchodní procesy, diagramy tříd/komponent aj. Modely slouží jako základ pro porovnávání alternativních řešení a architektur.[8][9][10]
  • Hodnocení proveditelnosti a výběr řešení. Provádí se feasibility study (technická, organizační, ekonomická, časová proveditelnost) a porovnání architektonických alternativ (trade-off). Pro hodnocení kvality architektury podle atributů (např. výkon, škálovatelnost, modifikovatelnost) se používají metody jako ATAM (Architecture Tradeoff Analysis Method).[11][12] Volba mezi například monolitickou a mikroservisní architekturou [3] se opírá o explicitní kompromisy (složitost provozu vs. nezávislá škálovatelnost a rychlost dodávky) podle doporučení průmyslových příruček.[13][14]
  • Příprava projektových artefaktů. Na základě výsledků analýzy se vytvářejí:
    • schválená specifikace požadavků (s uvedením jejich důležitosti),
    • konceptuální model systému (diagramy/popisy),
    • architektonická a projektová rozhodnutí (schémata dat, rozhraní externích systémů),
    • plán realizace (etapy/moduly).
    • Klíčové je zajistit sledovatelnost (bidirectional traceability) požadavků k prvkům návrhu a testům.[15][4]

Úspěch IT projektu do značné míry závisí na vyspělých postupech práce s požadavky a architekturou. Výzkum provedený McKinsey a Oxford ukázal, že velké IT projekty často překračují rozpočet a termíny. Tento výzkum také zdůraznil, jak důležité je správně řídit strategii, komunikovat se zainteresovanými stranami a odborně shromažďovat požadavky. To vše může výrazně ovlivnit úspěch nebo neúspěch projektu.[16]

Přístupy a metodologie v systémové analýze IT

Systémová analýza v IT se opírá o principy systémového myšlení a metodiky přizpůsobené vývoji softwaru. V praxi se kombinují „tvrdé" a „měkké" přístupy, strukturální metodologie, objektově orientované notace a také jazyky modelování procesů a požadavků.

  • Tvrdý a měkký přístup. V IT projektech tvrdý přístup (hard systems) předpokládá předem formalizovatelné cíle a požadavky, dekompozici a navrhování „shora dolů". Měkký přístup (soft systems) se uplatňuje při nejasných cílech a mnohočetných pohledech: používají se prvky Soft Systems Methodology (SSM) (např. rich picture, kořenové definice, CATWOE) pro sladění chápání problému a požadovaných změn; výsledky jsou pak převáděny do formálních požadavků.[17][18]
  • Metodologie SSM (Soft Systems Methodology). Původně vyvinutá Peterem Checklandem pro organizační změny, SSM je užitečná v předprojektových etapách IT: od průzkumu problémové situace a formulování kořenových definic (vč. CATWOE) až po porovnání konceptuálních modelů s realitou a dosažení akomodace mezi stakeholdery.[19][20]
  • Strukturované metodologie: SADT/IDEF0. SADT modeluje systém jako hierarchii funkcí; standardní notace IDEF0 (IEEE 1320.1) zachycuje funkce a jejich I-C-O-M rozhraní (Inputs, Controls, Outputs, Mechanisms). Metoda je vhodná pro funkční dekompozici a sladění hranic systému nezávisle na algoritmech.[21][22]
  • Objektově orientovaná analýza: UML a SysML (MBSE). UML se stal základním jazykem pro požadavky a návrh (diagramy případů užití, tříd, sekvencí aj.) a usnadňuje validaci scénářů s uživateli; SysML rozšiřuje UML pro systémové inženýrství (diagramy požadavků, parametrické diagramy) a opírá se o přístup MBSE, kde model je centrálním artefaktem napříč etapami od požadavků po testy.[23][24][25]
  • Modelování obchodních procesů: BPMN. Standard BPMN se používá pro grafický popis procesů (bazény, toky prací, události, brány), včetně porovnání as-is/to-be ve specifikacích požadavků a integraci.[26][27]
  • Vazba na inženýrství požadavků. Proces zahrnuje etapy elicitation–analysis–specification–validation–change management; kritéria „dobrého požadavku" a struktura SRS jsou upraveny normou ISO/IEC/IEEE 29148. Pro prioritizaci se používají techniky MoSCoW (Must/Should/Could/Won't) a metody vícekriteriálního výběru, například AHP. V agilních procesech se činnost systémové analýzy odráží ve zpřesnění backlogu a sledovatelnosti požadavků.[28][29][30][31]
  • Vazba na systémové inženýrství. Pro komplexní (kyberfyzické) systémy se používá V-model: na „levé" větvi — systémová analýza a architektura, na „pravé" — integrace, verifikace a validace s vazbou na artefakty levé větve. Metody hodnocení architektury podle kvalitativních atributů zahrnují ATAM (trade-off analýza).[32][33]

Systémová analýza v IT kombinuje osvědčené přístupy — od měkkých metodik slaďování vize až po formální notace a standardy. Volba nástrojů je určena mírou určitosti úlohy: při vysoké nejistotě roste role SSM a facilitace, při jasně definovaných hranicích — formální modely (UML/SysML, IDEF0, BPMN) a předpisy.

Vazba na IT architekturu a architekturu podniku

Systémová analýza v IT projektech úzce souvisí s architektonickým navrhováním. Role analytika a architekta se překrývají: analytik formuluje požadavky a logický model, architekt určuje cílovou strukturu řešení a technické kompromisy; práce probíhá společně.

  • Architektura IT systémů. V užším smyslu je softwarová architektura organizace komponent, jejich vztahy a principy, kterými se řídí při navrhování řešení. Pro analytika je důležité zohledňovat architektonické styly (vrstvená, klient–server, mikroservisní, událostmi řízená aj.), protože nefunkční požadavky (spolehlivost, škálovatelnost, modifikovatelnost) často určují architektonická rozhodnutí a jejich kompromisy.[34][35] V rané fázi analýzy se formuje architektonická vize (high-level vision) a zpracovává se hrubý obrys řešení pro ověření životaschopnosti požadavků (délka iterací a míra detailizace závisí na metodologii).[36]
  • Šablony a předběžná řešení. Pro splnění nefunkčních požadavků se používají architektonické šablony (architectural patterns). Například pro asynchronní komunikaci a volné vazby — publish–subscribe prostřednictvím brokeru zpráv v architektuře řízené událostmi.[37]
  • TOGAF (The Open Group Architecture Framework). Jeden z nejrozšířenějších rámců podnikové architektury; zahrnuje metodu ADM (Architecture Development Method) a artefakty řízení architektury (repozitář, katalogy/matice, principy). V TOGAF je řízení požadavků průřezovým procesem integrovaným do všech fází ADM.[36] Pro podporu požadavků a sledovatelnosti se používají katalogy a matice (např. požadavky ↔ služby, funkce ↔ komponenty) a rozlišují se Architecture Building Blocks a Solution Building Blocks.[38][39] Principy a standardy podniku jsou zachyceny v příslušných katalozích a vystupují jako externí nefunkční požadavky pro projektové týmy.[40] Soulad řešení s cílovou architekturou je potvrzen postupem architektonického souladu (Architecture Compliance Review).[41] Přístup TOGAF předpokládá předběžnou Architecture Vision a následnou detailizaci (data/aplikace/technologie) s plánem migrace a řízením změn požadavků.[42][43]
  • Zachman Framework. Raná a vlivná ontologie artefaktů podnikové architektury, představená jako matice 6×6 (perspektivy × aspekty „co/jak/kde/kdo/kdy/proč"). Řádek „návrhář" odpovídá systémové analýze a navrhování; sloupce určují úplnost zohlednění dat, funkcí/procesů, rolí, umístění a motivace. Rámec slouží jako klasifikace (nikoli metodologie) a pomáhá zajistit úplnost popisu řešení v kontextu podniku.[44]
  • Vazba na podnikovou architekturu (Enterprise Architecture, EA). Systémový analytik pracuje v kontextu EA: nové požadavky jsou sledovány k obchodním schopnostem a provoznímu modelu; uplatňují se standardy a zásadní omezení podniku (bezpečnost, kompatibilita atd.).[45][36] V etapě iniciace se formuje Architecture Vision (cíle/omezení, souhrnné požadavky), poté analytik detailizuje se zachováním sledovatelnosti k vizi a podnikovým standardům; nesplnění standardů se zjišťuje na architektonických přezkumech a může vést k úpravám řešení.[36][46]

Celkově: systémová analýza a architektonické navrhování tvoří vazbu „požadavky → architektonická rozhodnutí → kompromisy podle atributů kvality". Volba metod (stylů/šablon, artefaktů TOGAF, klasifikace Zachman) je určena charakterem projektu a rámcem podnikové architektury.

Procesy a postupy

Systémová analýza se integruje do celého životního cyklu vývoje a provozu softwaru, propojující obchodní cíle, architekturu a dodávku. Zahrnuje předprojektový průzkum, volbu přístupu, tvorbu ověřitelných artefaktů a požadavky na spolehlivost, výkon, bezpečnost a udržovatelnost. V kaskádním modelu se analýza provádí před navrhováním a realizací, v agilních metodách — průběžně prostřednictvím iterací, a v DevOps — s důrazem na provozní cíle. Bez ohledu na přístup zajišťuje analýza sledovatelnost, řízení změn a rizik, dokumentování architektonických kompromisů a dodržování normativních omezení, čímž činí vývoj předvídatelným a řiditelným.

  • Klasický SDLC (Waterfall). Etapa System Analysis & Requirements Definition předchází navrhování a realizaci; požadavky jsou zachyceny v podrobné SRS jako základ plánování a smluv. Efektivní ve stabilních a regulovaných oblastech; rizika „zamrazení" požadavků snižují SRR/přezkumy a řízení změn prostřednictvím CCB.[47][48][49]
  • Agilní metodologie (Agile). Analýza je průběžná: místo finální SRS se vede produktový backlog z user stories s akceptačními kritérii, zpřesňovaný při backlog refinement; používá se BDD (Given–When–Then); riziko ztráty celistvé architektury se kompenzuje ranou architektonickou přípravou a transparentní sledovatelností požadavků ↔ realizaci/testům.[50][51][52]
  • DevOps a SRE. Časté vydávání verzí vyžaduje provozní požadavky „ve výchozím nastavení": automatizaci, pozorovatelnost, rollback. Nefunkční požadavky se formulují jako SLO/SLI, spravuje se error budget; do backlogu se přidávají úkoly na logy/metriky/traces/alerty; pro vydání bez výpadku — vzory blue/green aj.[53][54][55]
  • Řízení požadavků a rizik. Požadavky v ALM mají stavy a vazby na úkoly/vydání/defekty; povinné jsou version control, change impact analysis a pravidelná reprioritizace.[56][57]
  • Zajištění kvality (QA). Kvalita se zabudovává v etapě požadavků: přezkumy, „Three Amigos", plán Acceptance Test Plan, automatizované testy akceptačních kritérií (BDD/ATDD).[58][59]
  • Pozorovatelnost a spolehlivost. Do požadavků se zahrnují SLA/SLO, MTTR a MTBF s měřitelnými cíli a metodami kontroly; parametry přicházejí od businessu/provozu a jsou zabudovány do architektury a testů spolehlivosti.[60][61]

Metriky a kvalita artefaktů

Pro hodnocení práce systémového analytika a kvality jeho výsledků se používají obecně uznávaná kritéria. Kvalitní požadavky a modely — základ úspěšného projektu, proto jsou spravovány po celý životní cyklus (elicitation → specification → verification/validation → change management). Základní atributy kvality požadavků jsou zakotveny ve standardech ISO/IEC/IEEE 29148 a (historicky) IEEE 830.[3][62][1]

  • Správnost (Correctness) — požadavek odráží skutečnou potřebu a je odsouhlaseno s experty v dané oblasti; potvrzuje se validací (review/inspection, prototypy, scénáře).[1][4]
  • Úplnost (Completeness) — jsou zohledněny podstatné aspekty a podmínky.
    • Úplnost jednotlivého požadavku: jsou uvedeny potřebné detaily (např. „indikátor přechází do stavu červený při selhání", nikoli jen „zčervená").
    • Úplnost specifikace: jsou pokryty scénáře/role, jsou stanoveny NFR; dosahuje se kontrolními seznamy a sledovatelností k obchodním cílům; užitečný je nezávislý audit úplnosti (QA/review).[3][63]
  • Jednoznačnost (Unambiguity) — formulace jsou interpretovány jediným způsobem; pomáhá glosář, šablony ve tvaru „systém musí dělat A, když B, pokud C", příklady; diagramy jsou doplněny legendou. Kontrola — princip „čtyř očí".[3][1]
  • Konzistentnost (Consistency) — požadavky si navzájem neodporují a neodporují ani externím omezením; používá se strukturování, souhrnné tabulky atributů, týmové přezkumy; ověřují se předpisy/standardy.[3][63]
  • Ověřitelnost/testovatelnost (Verifiability) — splnění se potvrzuje testem/demonstrací/analýzou; neověřitelné formulace se nahrazují měřitelnými kritérii; pro NFR se stanovují metriky a akceptační kritéria se fixují předem.[3][63]
  • Modifikovatelnost a sledovatelnost (Modifiability & Traceability) — unikátní ID, logická struktura („jedna myšlenka — jeden odstavec"), absence duplicit; udržují se vazby „požadavek ↔ zdroj/cíl/návrh/test", vede se matice sledovatelnosti (RTM).[64][3]
  • Třídění a prioritizace — kvalita sady požadavků; používají se techniky MoSCoW a MCDM (např. AHP); prioritizace společně s businessem ovlivňuje plánování a rizika.[65][66]

Metriky kvality požadavků (příklady):[63][1]

  • hustota defektů požadavků (připomínek na 100 požadavků);
  • počet změn po základním zakotvení;
  • metriky pokrytí: podíl požadavků s testy; podíl požadavků sledovatelných k obchodním cílům;
  • stabilita požadavků (poměr přidaných/odstraněných k celkovému počtu za období);
  • velikost/složitost specifikace (průměrný počet požadavků v případu užití, hloubka dekompozice);
  • spokojenost stakeholderů (průzkum).

Ve vyspělých procesech (např. CMMI úroveň 3+) platí předpisy kvality požadavků: formální kontroly, audity shody se šablonami, sběr/analýza metrik.[67] V kritických oblastech (avionika, kosmonautika aj.) se používají formální metody pro zvýšení spolehlivosti.[68]

Typické chyby

V IT projektech se často vyskytují chyby systémové analýzy: neúplnost a nejednoznačnost požadavků, rozpory, rozostřené hranice, ignorování nefunkčních aspektů, opomenutá integrace a opožděná bezpečnost. To vede k přepracování, zpožděním, nárůstu nákladů a defektům.

Typické problémy, jejich důsledky a způsoby prevence.

  • Neúplnost a chybějící požadavky. Jsou přehlédnuty role se speciálními oprávněními, hraničními případy a NFR. Důsledky: přepracování architektury a odložení spuštění. Jak předejít: kontrolní seznamy, brainstormingy „co kdyby…", raná účast testerů, sledovatelnost k obchodním cílům.[1][69]
  • Nejasné, dvojznačné formulace. Důsledky: vývojáři implementují „něco jiného", zákazník je nespokojený. Jak předejít: měřitelná kritéria, glosář, šablony „A, když B, pokud C", peer‑review.[3][69]
  • Rozporuplné požadavky. Důsledky: zpoždění kvůli upřesňování, přepracování při integraci. Jak předejít: strukturování, srovnání obchodních pravidel/předpisů, sezení pro řešení konfliktů, kontrola konzistentnosti při přezkumech.[3][1]
  • Syndrom „zlatého pozlátka" (gold‑plating). Důsledky: nárůst rozsahu, komplikování, nové body selhání. Jak předejít: propojení každého požadavku s cílem/metrikou; v Agile — nevkládat nadbytečné do backlogu; fixovat scope; viz YAGNI.
  • Nadměrná detailizace tam, kde není potřeba. Jak předejít: oddělovat co/proč (požadavky) od jak (návrh/realizace); používat design‑free requirements tam, kde je to vhodné.[3]
  • Narušení řiditelnosti požadavků. Důsledky: zmatení verzí, realizace „špatné věci". Jak předejít: jediný zdroj pravdy v ALM, historizace a stavy, RTM a change impact analysis; řízení změn prostřednictvím CCB.[64][1]
  • Absence zapojení uživatelů. Jak předejít: rozhovory, pozorování, prototypy, pravidelné ukázky; explicitní validace se stakeholdery.[3][1]
  • Příliš dlouhá „analytická paralýza". Jak předejít: zóna dostatečnosti, iterativnost a timeboxing; spuštění MVP/inkrementů a korekce na základě zpětné vazby.[1]
  • Ignorování nefunkčních požadavků. Jak předejít: vymezit NFR (např. FURPS+), stanovit měřitelná kritéria, zahrnout je do plánu testování a architektonických rozhodnutí.[1][3]
  • Komunikační chyby a „lidský faktor". Jak řešit: rozvíjet techniky rozhovorů a facilitace, zachovávat neutralitu, zaznamenávat rozhodnutí a zdroje požadavků (sledovatelnost k cílům).[1]

Většina problémů se týká kvality formulací, úplnosti a řiditelnosti požadavků; používání standardů ISO/IEC/IEEE 29148 a postupů SWEBOK (validovatelnost, sledovatelnost, iterativnost) výrazně snižuje riziko zpoždění a přepracování.[3][1]

Omezení

Přes svou účinnost při snižování nejistoty má systémová analýza svá omezení:

  • Realita je proměnlivá a složitá. Nelze zohlednit všechny faktory, zvláště v dlouhodobých projektech. Některé požadavky se nevyhnutelně projeví až po spuštění systému. Je důležité usilovat o minimalizaci překvapení, ale je třeba být připraven na změny.
  • Požadavky závisí na lidech. Priority businessu, zákony a trh se mohou měnit. Systémová analýza zachycuje aktuální stav a nemůže předpovědět všechny externí změny. Aby bylo možné se přizpůsobit, je nutné pravidelně aktualizovat požadavky a pracovat iterativně.
  • Uživatelé ne vždy vědí, co chtějí, dokud to neuvidí. Toto je known omezení. Prototypování a agilní metodologie, jako je Agile, pomáhají tento problém překonat. Analýza na papíře má své meze a pro získání přesných dat je potřebná zpětná vazba z realizací.
  • Rovnováha mezi časem a kvalitou. Příliš detailní analýza může zastaraet. V inovativních oblastech je lepší rychle vytvořit minimálně životaschopný produkt (MVP) a získat reálná data. Systémová analýza je efektivní ve stabilních oblastech, ale ve výzkumných projektech (R&D) je její role omezena.
  • Lidský faktor. Ani ty nejlepší metodologie nekompenzují nekompetentnost analytika nebo nedostupnost zákazníka. Je důležité, aby všichni účastníci procesu byli zapojeni a motivováni.

Vliv moderních technologií na systémovou analýzu v IT

Systémová analýza v IT se neustále vyvíjí pod vlivem technologických inovací. Analytik 21. století pracuje v podmínkách explozivního růstu dat, všudypřítomného zavádění AI, rychlého vývojového cyklu a zvýšeného důrazu na bezpečnost. Úspěšná praxe systémové analýzy vyžaduje osvojení nových znalostí (Data Science, kybernetická bezpečnost, cloudové technologie) a flexibilitu při uplatňování metod.

  • Data a AI/ML: co se přidává do analýzy. Pro systémy s AI se již na začátku fixují cíle a kontext použití, požadavky na zdroje a kvalitu dat a také metriky důvěry v rozhodnutí modelu (spolehlivost, bezpečnost, vysvětlitelnost, soukromí, spravedlivost). Plánují se kontroly TEVV (testing, evaluation, verification, validation), monitoring v provozu a bezpečné odstavení/vyřazení modelu. Tyto kroky odpovídají funkcím GOVERN–MAP–MEASURE–MANAGE z rámce NIST pro řízení rizik AI; jsou zohledněny v SRS, architektuře a plánech verifikace/provozu.[70]
  • DevSecOps: bezpečnost „vlevo" a ve výchozím nastavení. Zabudování bezpečnosti do každé etapy CI/CD se stává normou: automatické kontroly (SAST/DAST), skenování závislostí a kontejnerů, zásady nasazení, základní pozorovatelnost. Používají se důvěryhodné registry artefaktů a standardizované „hardened" obrazy; uplatňují se principy nulové důvěry. V systémové analýze jsou předem popsány kontrolní body procesu (podmínky průchodu etapami), vazba požadavků na bezpečnostní kontroly a pravidla přechodu mezi prostředími (dev/test/stage/prod).[71]
  • Co se mění v dokumentech (artefaktech). Jaká sekce se objevuje nebo upřesňuje v klíčových dokumentech při práci s Big Data a AI/ML a při práci podle DevSecOps:
    • SRS / Specifikace požadavků: cíle a kontext použití AI; požadavky na data (původ, kvalita, etická a právní omezení); metriky modelu (přesnost, spolehlivost, doba odezvy); plán TEVV (testing, evaluation, verification, validation); požadavky na transparentnost/vysvětlitelnost a soukromí; kritéria odstavení/vyřazení modelu z provozu.[70]
    • Architektura a rozhodnutí (Architecture, ADR): výsledky modelování hrozeb; opatření „bezpečnost ve výchozím nastavení" (šifrování, řízení přístupu, správa tajemství, princip nejnižšího oprávnění); omezení pro použití dat/modelů; záznamy ADR s hodnocením rizik a kompromisů.[71][70]
    • Plán verifikace a validace (V&V / TEVV): scénáře testování modelů a dat; prahové hodnoty přijetí pro metriky kvality; monitoring driftu dat/modelu; postupy periodického přehodnocení a opakované validace.[70]
    • Zásady CI/CD a „brány" procesu: automatické kontroly SAST/DAST, SCA (závislosti), skenování kontejnerů; podpis a ukládání artefaktů v důvěryhodných registrech; pravidla postupu mezi prostředími (dev/test/stage/prod) a podmínky blokování sestavení při selhání kontrol; požadavky na pozorovatelnost ve výchozím nastavení.[71]
    • Plán řízení dat a modelů: katalog zdrojů a lineage; kritéria kvality a dostupnosti dat; verze datasetů/modelů; harmonogram (do)učení a kontrola bias; zásady přístupu a uchovávání; plán bezpečné deaktivace modelu a smazání dat, je-li to požadováno.[70]
    • Provoz a pozorovatelnost (Ops/Runbook): metriky důvěry v AI a SLO; audit a protokolování; alerty na degradaci/anomálie; plán reakce na incidenty; fallback/kill‑switch pro AI komponenty; požadavky na reporting a analýzu po incidentech.[70][71]
    • Sledovatelnost (end‑to‑end): explicitní vazby „požadavek ↔ kontrola/ověření v procesu\" a „požadavek ↔ test/monitoring v provozu", aby bylo možné prokazatelně ověřovat bezpečnost a kvalitu po celý životní cyklus.[71][70]
  • Role systémového analytika.
    • řídí kontext a rizika AI (aktéři, scénáře použití, předpoklady a omezení dat);
    • zajišťuje sledovatelnost „požadavek ↔ bezpečnostní kontrola v procesu";
    • formuluje ověřitelné nefunkční požadavky (bezpečnost, transparentnost, pozorovatelnost) po celý životní cyklus systému.[70][71]

Rozdíly od klasické systémové analýzy

Termín „systémová analýza" je historicky širší než vývoj softwaru. Klasická systémová analýza je přístupem k řešení složitých interdisciplinárních úloh (sociálních, ekonomických, manažerských), založený na systémovém myšlení a kvantitativních metodách, obvykle pro podporu manažerských rozhodnutí. V IT se systémovou analýzou rozumí aplikovaná disciplína v oblasti softwarového inženýrství zaměřená na tvorbu informačních systémů.

Níže jsou klíčové rozdíly.

  • Cíle a objekt analýzy. Klasická analýza řeší špatně strukturované, „rozmazané" problémy a zlepšuje již existující sociotechnické systémy (městská dopravní síť, strategie společnosti, ekologická politika). Objektem je reálný systém; úkolem je pomoci rozhodovateli zvolit postup. Pro systémovou analýzu v IT je cílem navrhnout a vytvořit nový informační systém nebo softwarový produkt odpovídající požadavkům. Objektem je navrhovaný systém; fokus je na chování a vlastnostech potřebných uživatelům.
  • Metodologické základy. Klasické školy se opírají o systémové myšlení a často o matematiku. Tvrdý přístup (hard systems) — formalizace problému, kvantitativní kritéria, optimalizace (jako v operations research). Měkké metodologie (soft systems) uznávají mnohočetnost pohledů; příkladem je Soft Systems Methodology (SSM), kde prostřednictvím diskusí a konceptuálních modelů se slaďují požadované změny. V IT je základem inženýrské disciplíny: inženýrství požadavků, navrhování softwaru, architektonické rámce. Používají se standardizované procesy (ISO/IEC/IEEE 15288, 12207, 29148), notace UML/SysML a postupy řízení změn.
  • Role a artefakty. V klasické analýze je role „systémového analytika" často neformální; výsledky jsou analytická zpráva, doporučení, matematické modely, scénáře „co kdyby". V IT je role analytika (nebo obchodního analytika) formalizována; vydávají se specifikace požadavků, modely systému (UML, ER), specifikace rozhraní, user stories a backlog — artefakty přímo používané vývojáři a testery.
  • Životní cyklus a proces. Klasická analýza nemá jednotnou šablonu: kroky závisí na problému (v SSM — od zkoumání situace po zavádění změn). V IT jsou přijaty standardní cykly SDLC: v kaskádním modelu existuje samostatná fáze analýzy požadavků; v iterativních a agilních přístupech je analýza trvalou činností každého sprintu. Moderní postupy (DevOps, CI/CD) rozšiřují rámec analýzy na provoz: zohledňují se požadavky na udržovatelnost, pozorovatelnost a aktualizovatelnost. Jinými slovy, systémová analýza v IT je zabudována do životního cyklu vývoje, zatímco klasická se provádí spíše jako projektová/konzultační činnost.

Systémový analytik

Systémový analytik v IT — specialista odpovídající za systémové myšlení při navrhování a rozvoji informačních systémů: formování a validaci požadavků, modelování (UML/BPMN), slaďování architektonických rozhodnutí a zajišťování integrace. Role a kvalifikační požadavky v RF jsou zakotveny v profesním standardu a FGOS.

Hlavní cíl druhu profesní činnosti: Zajištění souladu IT služby, automatizovaného systému, automatizovaného informačního systému, automatizovaného řídicího systému, softwarového, informačního produktu nebo prostředku (dále - Systém) s okolím, výchozími požadavky a omezeními, cíli automatizace a automatizované činnosti prostřednictvím vývoje a předávání kvalitních a vzájemně provázaných projektových rozhodnutí zainteresovaným stranám při spouštění a koordinaci práce jednotlivých realizátorů po celý životní cyklus Systému (Profesní standard „Systémový analytik" (příkaz Ministerstva práce RF ze dne 27.04.2023 č. 367n).[72]

Glosář klíčových pojmů

Základní pojmy a účastníci

  • Systémová analýza v IT — disciplína, jejímž předmětem je informační systém po celém svém životním cyklu, od záměru po provoz.
  • Stakeholdeři — osoby nebo skupiny zainteresované na projektu nebo jím dotčené (zákazníci, uživatelé, manažeři).
  • Projektové artefakty — dokumenty a výsledky vytvářené v průběhu projektu, jako jsou specifikace, modely, plány a rozhodnutí.

Požadavky: druhy a dokumentace

  • Funkční požadavky — popisují, co má systém dělat; jeho funkce a chování.
  • Nefunkční požadavky — popisují atributy kvality systému (spolehlivost, výkon, bezpečnost, použitelnost, škálovatelnost atd.).
  • Specifikace požadavků (primární) — dokument obsahující výchozí sadu požadavků shromážděných v počátečních etapách projektu.
  • SRS (Software Requirements Specification) — standardizovaný dokument podrobně popisující požadavky na software podle mezinárodních standardů (např. ISO/IEC/IEEE 29148).
  • URS (User Requirements Specification) — dokument popisující požadavky uživatele na systém z pohledu obchodních procesů a očekávání koncového uživatele.
  • Architektonicky významné požadavky (ASR) — požadavky podstatně ovlivňující architektonická rozhodnutí a kompromisy.
  • Průřezové funkční požadavky (CFR) — synonymum nefunkčních požadavků zdůrazňující jejich průřezový charakter.
  • Akceptační kritéria (Acceptance Criteria) — ověřitelné podmínky, při jejichž splnění je práce na požadavku považována za přijatou.
  • Definition of Ready (DoR) — dohoda o připravenosti položky backlogu k vývoji (srozumitelnost, odhad, kritéria).
  • Definition of Done (DoD) — dohoda o „dokončenosti" práce (kód, testy, dokumentace, nasazení).
  • Omezení (Constraint) — pevná podmínka omezující řešení (termíny, platformy, standardy, licence).
  • Předpoklad (Assumption) — tvrzení přijímané bez důkazu, vyžadující následnou validaci.
  • Kvalita požadavků — vlastnosti dle ISO 29148: jednoznačnost, úplnost, nerozpornost, ověřitelnost, atomárnost.

Formalizace, sledovatelnost a prioritizace požadavků

  • Formalizace požadavků — proces přeměny neformálních žádostí v jasné, ověřitelné a jednoznačné požadavky.
  • Sledovatelnost požadavků — možnost sledovat životní cyklus požadavku od jeho zdroje po realizaci, testování a nasazení.
  • Bidirectional traceability (obousměrná sledovatelnost) — schopnost sledovat vazby mezi požadavky, prvky návrhu a testovacími scénáři v přímém i zpětném směru.
  • MoSCoW — technika prioritizace požadavků, klasifikující je jako Must-have (musí být), Should-have (mělo by být), Could-have (mohlo by být) a Won't-have (nebude).
  • BDD (Behavior-Driven Development) — metodologie vývoje, při níž jsou testy psány v přirozeném jazyce orientovaném na chování systému z pohledu uživatele (formát Given–When–Then).

Notace a modelování

  • UML (Unified Modeling Language) — standardizovaný jazyk grafického modelování pro specifikaci, vizualizaci, konstruování a dokumentování komponent softwarových systémů.
  • SysML (Systems Modeling Language) — rozšíření UML pro systémové inženýrství, podporující modelování různých aspektů složitých systémů, včetně požadavků, chování, struktury a parametrů.
  • BPMN (Business Process Model and Notation) — standard grafické notace pro popis obchodních procesů, umožňující vizualizaci toků prací, událostí, bran a bazénů.
  • MBSE (Model-Based Systems Engineering) — přístup k systémovému inženýrství, kde model je centrálním artefaktem ve všech etapách životního cyklu systému, od požadavků po testování.
  • ArchiMate — notace podnikové architektury (business, aplikace, technologie) a jejich vazby.
  • DMN (Decision Model and Notation) — modelování obchodních rozhodnutí a tabulek pravidel.
  • DFD (Data Flow Diagram) — diagramy toků dat (kontext, úrovně dekompozice).
  • ERD (Entity-Relationship Diagram) — model předmětné oblasti s entitami, vazbami a atributy.
  • CRUD-matice — korespondence operací Create/Read/Update/Delete s entitami a rolemi/funkcemi.

Architektonické styly a hodnocení řešení

  • Monolitická architektura — architektonický přístup, při němž je celý systém vyvíjen jako jediný, nedělitelný modul.
  • Mikroservisní architektura — architektonický přístup, při němž je systém budován jako sada malých, nezávisle nasaditelných a škálovatelných služeb.
  • Trade-off (kompromis) — volba mezi vzájemně se vylučujícími nebo protichůdnými vlastnostmi či řešeními, kde zlepšení jedné vlastnosti nastává na úkor zhoršení druhé.
  • ATAM (Architecture Tradeoff Analysis Method) — metoda hodnocení softwarové architektury, používaná k analýze kompromisů mezi kvalitativními atributy (např. výkonem, škálovatelností).

Podniková architektura a rámce

  • TOGAF (The Open Group Architecture Framework) — jeden z nejrozšířenějších rámců podnikové architektury, zahrnující metodu ADM (Architecture Development Method) pro vývoj a řízení architektury.
  • Zachman Framework — ontologie artefaktů podnikové architektury, představená jako matice 6×6, klasifikující různé aspekty architektury z různých perspektiv.

Přístupy k analýze a procesům vývoje

  • Tvrdý přístup (Hard Systems) — metodologie systémové analýzy předpokládající předem formalizovatelné cíle a požadavky, dekompozici a navrhování „shora dolů", efektivní pro jasně definované úlohy.
  • Měkký přístup (Soft Systems) — metodologie systémové analýzy uplatňovaná při nejasných cílech a mnohočetných pohledech stakeholderů, zaměřená na sladění chápání problému a požadovaných změn.
  • SSM (Soft Systems Methodology) — konkrétní metodologie měkkého systémového přístupu, vyvinutá Peterem Checklandem, využívající nástroje jako rich picture, kořenové definice a CATWOE.
  • Waterfall (kaskádní model) — klasická metodologie vývoje softwaru, kde etapy (analýza, navrhování, realizace, testování, zavádění) jsou prováděny postupně, s úplným dokončením předchozí etapy před zahájením následující.
  • Agile — skupina agilních metodologií vývoje softwaru orientovaných na iterativní vývoj, adaptaci na změny, spolupráci se zákazníkem a průběžné dodávání hodnoty.

Metody výběru a typické chyby

  • AHP (Analytic Hierarchy Process) — metoda vícekriteriálního výběru umožňující strukturovat složité problémy a hodnotit alternativy na základě hierarchie kritérií.
  • Gold-plating (syndrom „zlatého pozlátka") — chyba v systémové analýze spočívající v přidávání funkcionality, kterou stakeholdeři nevyžadují, což vede k nárůstu rozsahu a složitosti projektu.

Odkazy

  • ISO/IEC/IEEE 15288:2023 — System life cycle processes
  • ISO/IEC/IEEE 12207:2017 — Software life cycle processes
  • ISO/IEC/IEEE 29148:2018 — Requirements engineering
  • ISO/IEC/IEEE 42010:2022 — Architecture description
  • ISO/IEC 25010:2023 — Product quality model (SQuaRE)
  • ISO/IEC/IEEE 24748-2:2024 — Life cycle management — Guidelines for applying ISO/IEC/IEEE 15288
  • ISO/IEC/IEEE 15289:2019 — Content of life-cycle information items (documentation)
  • ISO/IEC/IEEE 42020:2019 — Architecture processes
  • ISO/IEC/IEEE 29119-1:2022 — Software testing — Part 1: General concepts
  • IEEE Std 1012-2024 — System, Software, and Hardware Verification and Validation
  • UML 2.5.1 — OMG Specification
  • BPMN 2.0.2 — OMG Specification
  • SysML v1.7 — OMG Specification
  • TOGAF Standard, 10th Edition — The Open Group
  • ArchiMate 3.2 — The Open Group
  • SEI ATAM — Architecture Tradeoff Analysis Method
  • NASA Systems Engineering Handbook, SP-2016-6105 Rev2 (PDF)
  • SWEBOK Guide v4.0a — IEEE Computer Society (PDF)
  • Guide to the Systems Engineering Body of Knowledge (SEBoK)
  • BABOK Guide v3 — IIBA
  • Google SRE Books — Official site
  • Microsoft Azure Well-Architected Framework — Official docs
  • Systémová analýza jednoduše. YouTube
  • Systémová analýza v IT jednoduše. YouTube

Literatura

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 5. vyd.
  • ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
  • IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
  • The Open Group (2022). The TOGAF® Standard, 10th Edition. Oficiální bezplatná verze.
  • OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
  • OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
  • OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
  • The Open Group (2022). ArchiMate® 3.2 Specification. Oficiální bezplatné stažení (na licenci).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4. vyd.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3. vyd.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2. vyd.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (rev. ed.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5. vyd.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3. vyd.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, 4. vyd.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11. vyd.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8. vyd.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7. vyd.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3. vyd.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2. vyd.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4. vyd.
  • Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
  • Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
  • Keeling, M. (2017). Design It!: From Programmer to Software Architect.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
  • Vernon, V. (2013). Implementing Domain-Driven Design.
  • Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
  • Simsion, G.; Witt, G. (2015). Data Modeling Essentials, 4. vyd.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (rev. eds.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2. vyd.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

Poznámky

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 IEEE Computer Society (2025). Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
  2. ↑ Zowghi, D.; Coulin, C. (2005/2014). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. https://eecs481.org/readings/requirements.pdf
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 ISO/IEC/IEEE 29148 (2011/2018). Systems and software engineering — Requirements engineering. ISO overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html
  4. ↑ 4.0 4.1 4.2 NASA (2020). NPR 7123.1C — Systems Engineering Processes and Requirements. Определение «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all
  5. ↑ GMU (George Mason University). IEEE Software Requirements Specification Template (SRS). https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc
  6. ↑ Westfall, L. (Cal Poly, .edu). The What, Why, Who, When and How of Software Requirements (упоминает URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf
  7. ↑ Stanford University IT (.edu). Functional Specification Document Template. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx
  8. ↑ Penn State (.edu). Elements of a Use Case Diagram. https://www.e-education.psu.edu/geog468/l8_p4.html
  9. ↑ UC Irvine (.edu). Data Flow Diagram. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/
  10. ↑ ISO/IEC/IEEE 42010 (2011/2022). Architecture description — требования к описанию архитектуры и точкам зрения. https://standards.ieee.org/ieee/42010/5334/
  11. ↑ Cornell University (.edu). CS 5150 — Feasibility Studies. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf
  12. ↑ Carnegie Mellon SEI. Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  13. ↑ Microsoft Azure Architecture Center. Architecture styles: microservices — benefits & complexity. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  14. ↑ Google Cloud. What Is Microservices Architecture? — Monolithic vs. microservices (обзор). https://cloud.google.com/learn/what-is-microservices-architecture
  15. ↑ NASA (2023). Requirements Management — Traceability, Bidirectional traceability (definitions). https://www.nasa.gov/reference/6-2-requirements-management/
  16. ↑ McKinsey (2012). Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  17. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM) — CATWOE, 3Es. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  18. ↑ Lancaster University (ePrints). Soft Systems Methodology and root definitions. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf
  19. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM). https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  20. ↑ UCL Discovery (.ac.uk). M. Haklay. Soft System Methodology (SSM). https://discovery.ucl.ac.uk/1296/1/paper13.pdf
  21. ↑ IEEE Std 1320.1-1998 (R2004). Functional Modeling Language — Syntax and Semantics for IDEF0. https://standards.ieee.org/ieee/1320.1/2003/
  22. ↑ ISO/IEC/IEEE 31320-1:2012. IDEF0: Function Modeling. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf
  23. ↑ University of Washington (.edu). UML Class Diagrams / UML overview (course material). https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf
  24. ↑ JHU/APL (.edu). Modeling with SysML — tutorial. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  25. ↑ MIT OCW (.edu). O. de Weck. Introduction to Systems Modeling Languages (incl. SysML, MBSE). https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf
  26. ↑ IBM. What is Business Process Modeling and Notation (BPMN)?. https://www.ibm.com/think/topics/bpmn
  27. ↑ IBM Docs. Business Process Modeling Notation (BPMN) model. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model
  28. ↑ IEEE/ISO/IEC 29148:2018. Systems and software engineering — Requirements engineering (overview). https://standards.ieee.org/ieee/29148/6937/
  29. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  30. ↑ T. L. Saaty. How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19
  31. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  32. ↑ MIT OCW (.edu). V-Model — Fundamentals of Systems Engineering. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/
  33. ↑ Carnegie Mellon SEI (.edu). Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  34. ↑ Microsoft Azure Architecture Center. Architecture styles. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  35. ↑ Kazman, R.; Klein, M.; Clements, P. ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf
  36. ↑ 36.0 36.1 36.2 36.3 The Open Group. Introduction — The TOGAF® Standard. https://www.togaf.org/chap01.html
  37. ↑ Microsoft Azure Architecture Center. Event-Driven Architecture style. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  38. ↑ Jonkers, H. et al. ArchiMate® and the TOGAF® Framework. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf
  39. ↑ Estrem, W. Building Blocks Revisited. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf
  40. ↑ The Open Group. Architecture Principles. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf
  41. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  42. ↑ The TOGAF® Standard, Version 9.2 (спецификация). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf
  43. ↑ Engelsman, W.; van Sinderen, M. Supporting Requirements Management in TOGAF and ArchiMate. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf
  44. ↑ Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276
  45. ↑ MIT CISR. Classic Topics — Enterprise Architecture (определение EA как «organizing logic for business process and IT capabilities…»). https://cisr.mit.edu/content/classic-topics-enterprise-architecture
  46. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  47. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON. Репринт (PDF): https://www.praxisframework.org/files/royce1970.pdf
  48. ↑ Defense Acquisition University. System Requirements Review (SRR) — Acquipedia. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/
  49. ↑ NASA (2023). Requirements Management — baseline, change control (CCB). https://www.nasa.gov/reference/6-2-requirements-management/
  50. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  51. ↑ MSDN Magazine (Microsoft). BDD Primer: Behavior‑Driven Development with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin
  52. ↑ Microsoft Learn. End‑to‑end traceability in Azure DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability
  53. ↑ Google SRE. Service Level Objectives; Error Budget Policy. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/
  54. ↑ Microsoft Learn. Azure Monitor — Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
  55. ↑ AWS Whitepaper. Blue/Green Deployments on AWS. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html
  56. ↑ Microsoft Learn. Manage change — track, triage, and implement change requests. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change
  57. ↑ Microsoft Learn (Azure Boards). Backlogs overview — create and manage your product backlog. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview
  58. ↑ Microsoft Learn (Azure Test Plans). What is Azure Test Plans?. https://learn.microsoft.com/en-us/azure/devops/test/overview
  59. ↑ MSDN Magazine. Behavior‑Driven Design with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow
  60. ↑ IBM. MTTR vs. MTBF: What’s the difference?. https://www.ibm.com/think/topics/mttr-vs-mtbf
  61. ↑ Google Cloud. Google Cloud Observability. https://cloud.google.com/products/observability
  62. ↑ IEEE Std 830‑1998. IEEE Recommended Practice for Software Requirements Specifications (исторический стандарт). Учебная копия (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  63. ↑ 63.0 63.1 63.2 63.3 NASA. Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2). https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  64. ↑ 64.0 64.1 NASA (2023). Requirements Management — traceability, baseline, CCB. https://www.nasa.gov/reference/6-2-requirements-management/
  65. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  66. ↑ Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19
  67. ↑ SEI / CMMI Institute. Capability Maturity Model Integration (CMMI) — Overview. https://www.sei.cmu.edu/cmmi/
  68. ↑ NASA Langley. What is Formal Methods?; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf
  69. ↑ 69.0 69.1 SEI (CMU). Common Testing Problems: Pitfalls to Prevent and Mitigate (о типичных проблемах требований/трассируемости). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/
  70. ↑ 70.0 70.1 70.2 70.3 70.4 70.5 70.6 70.7 NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
  71. ↑ 71.0 71.1 71.2 71.3 71.4 71.5 U.S. DoD CIO (2021). DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf
  72. ↑ Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н).
Retrieved from "https://systems-analysis.ru/int/index.php?title=Systémová_analýza_v_IT&oldid=23286"