Zúčastněná strana

Stakeholder ( anglicky  stakeholder ), též zainteresovaná strana , zúčastněná strana , účastník práce , role v projektu  - osoba nebo organizace, která má práva, podíl, požadavky nebo zájmy týkající se systému nebo jeho vlastností, které splňují jejich potřeby a očekávání ( ISO / IEC / IEEE 15288:2015 [1] , ISO/IEC 29148:2011 [2] :6 ).

Další definice:

Zainteresované strany poskytují systému příležitosti a jsou zdrojem požadavků na systém. [4] : 14

Zainteresované strany jsou vždy o jednu více, než víte, a ti, které znáte, mají alespoň o jednu větší potřebu, než nyní víte.

Tom Gilb ( anglicky ) [7] .

V systémovém inženýrství jsou zúčastněné strany v kontextu rozhodovacího procesu považovány za osoby nebo organizace, které závisí na výsledcích přijatých rozhodnutí. Mělo by být předem stanoveno, kdo je zúčastněnou stranou ve vztahu k přijímaným rozhodnutím. Velmi často se tak neděje – zúčastněné strany nejsou určeny před přijetím rozhodnutí. Jakmile je však rozhodnutí oznámeno nebo realizováno, vyjádří se každý, koho se toto rozhodnutí jakkoli dotklo. [8] :258

Podle A. I. Levenchuka je pro stakeholdery vhodné používat termín „role v projektu“ [9] .

Vztah zúčastněných stran s jinými subjekty inženýrského projektu

Obrázek ukazuje interakci hlavních entit a objektů, se kterými se projekt setkává. Objekty jsou seskupeny v oblastech zájmu. Stakeholder tedy patří do oblasti zájmu klienta , protože  tato oblast obsahuje vše, co souvisí s používáním a provozem systému. [4] :13-14

Typy (skupiny) zúčastněných stran

Neexistuje žádný vyčerpávající seznam typů (skupin) zainteresovaných stran, protože se mohou pro různé cílové systémy výrazně lišit. Můžete uvést příklady nejběžnějších typů (skupin) zainteresovaných stran, které jsou uvedeny v normách (GOST R ISO/IEC 15288:2005, ISO/IEC 29148:2011, GOST R ISO/IEC 12207:2010, OMG Essence), System Engineering Code of Knowledge ( SEBoK ) a učebnice systémového inženýrství [8] :

Identifikace zainteresovaných stran podle fází životního cyklu

Každý systém má své vlastní fáze životního cyklu , jako je koncepční návrh , vývoj, výroba, implementace, provoz a likvidace. Pro každou fázi je stanoven seznam všech zainteresovaných stran se zájmem (vztahem) k budoucímu systému. Účelem této aktivity je zvážit úhly pohledu každého zainteresovaného subjektu ve všech fázích životního cyklu systému, aby se vytvořil kompletní soubor potřeb zainteresovaných stran, které lze upřednostnit a převést na požadavky zainteresovaných stran. Příklady vztahu zainteresovaných stran k fázím životního cyklu jsou uvedeny v tabulce 1.

Tabulka 1. Definice stakeholderů v souladu s fázemi životního cyklu systému [10] :262
Fáze životního cyklu Příklady zainteresovaných stran
inženýrství (návrh, analýza) Nabyvatel, potenciální uživatelé, marketingové oddělení, vývojové oddělení, normalizační orgán , dodavatelé , testovací oddělení ( verifikace a validace ), výrobní systém atd.
Rozvoj Kupující, dodavatelé, designéři, integrační tým atd.
Převod do výroby nebo použití Oddělení kontroly kvality, výrobní systém, operátoři atd.
Logistika a podpora Podpůrné služby, instruktoři, účastníci dodavatelského řetězce atd.
Vykořisťování Běžní uživatelé, příležitostní uživatelé atd.
likvidace Operátoři, potvrzující orgán atd.

Míra účetnictví a zapojení zúčastněných stran

Podle návrhů OMG se rozlišuje 6 států, ve kterých může být projekt z hlediska účetnictví, zapojení a spokojenosti stakeholderů [4] :20-21 :

Pro posouzení současného stavu projektu z hlediska účetnictví, zapojení a spokojenosti zúčastněných stran jsou navrženy následující kontrolní seznamy :

Tabulka 2. Kontrolní seznamy pro zúčastněné strany [4] :22-23
Stát Kontrolní seznam
Definovaný

□ Byly identifikovány všechny skupiny zainteresovaných stran, které jsou v současnosti nebo v budoucnu ovlivněny vývojem a provozem systému.
□ Existuje dohoda o tom, které skupiny zúčastněných stran by měly být zastoupeny. Minimálně jsou brány v úvahu skupiny zainteresovaných stran, které financují, používají, podporují a udržují systém.
□ Jsou definovány odpovědnosti zástupců zainteresovaných stran.

Zastoupená

□ Zástupci zainteresovaných stran souhlasili s výkonem svých povinností.
□ Zástupci zainteresovaných stran jsou zmocněni vykonávat své povinnosti.
□ Dohodnutý přístup k zajištění spolupráce mezi zástupci zainteresovaných stran.
□ Zástupci zainteresovaných stran podporují a respektují technologii týmu.

zapojený

□ Zástupci zainteresovaných stran pomáhají týmu v souladu se svými povinnostmi.
□ Zástupci zainteresovaných stran poskytují zpětnou vazbu a účastní se rozhodování včas.
□ Zástupci zainteresovaných stran rychle sdělují změny, které jsou důležité, jejich skupinám zainteresovaných stran.

V souhlasu

□ Zástupci zainteresovaných stran se shodli na minimálních očekáváních pro nadcházející implementaci nového systému.
□ Zástupci zainteresovaných stran jsou spokojeni se svou účastí na práci.
□ Zástupci zainteresovaných stran souhlasí s tím, že tým oceňuje a respektuje jejich přínos k práci.
□ Členové týmu souhlasí s tím, že zástupci zainteresovaných stran oceňují a respektují jejich přínos k práci.
□ Zástupci zainteresovaných stran se shodnou na tom, jak jsou jejich priority a názory vyváženy, aby dali týmu jasný směr.

Spokojen s nasazením (implementací)

□ Zástupci zainteresovaných stran poskytují zpětnou vazbu z pohledu svých skupin zainteresovaných stran.
□ Zástupci zainteresovaných stran potvrzují, že systém je připraven k nasazení (implementaci).

Spokojen s používáním

□ Zúčastněné strany využívají nový systém a poskytují zpětnou vazbu o svých zkušenostech.
□ Zúčastněné strany potvrzují, že nový systém splňuje jejich očekávání.

Role stakeholderů v procesech organizační podpory projektů

Organizační projektová podpora spočívá v řízení schopnosti organizací dodávat a získávat produkty a služby prostřednictvím podpory, poskytování a projektového řízení. Toto ustanovení poskytuje zdroje a infrastrukturu nezbytnou pro usnadnění projektů a zajišťuje plnění organizačních cílů a stávajících dohod. Netvrdí, že je to soubor obchodních procesů, které tvoří řízení obchodních aktivit organizace. [jedenáct]

Role zúčastněných stran při řízení portfolia projektů

Norma GOST R ISO/IEC 12207:2010 (ISO/IEC 12207:2008) poznamenává, že mechanismus řízení změn smlouvy by měl odrážet role a odpovědnosti managementu, úroveň formalizace požadavků na navrhované změny a dodatečná jednání o smlouvě, stejně jako vztahy se zúčastněnými stranami . [jedenáct]

Výsledkem úspěšného řízení portfolia projektů:

Role zainteresovaných stran v řízení kvality

Organizace musí provádět pravidelné kontroly plánů zajištění kvality projektu. Pro každý projekt jsou stanoveny různé cíle kvality, které zase vycházejí z požadavků zainteresovaných stran. [jedenáct]

Účelem auditu je udržet sdílené znalosti o vývoji se zúčastněnými stranami, pokud jde o cíle dohody a co přesně je třeba udělat, aby se zajistilo, že produkt bude vyvinut ke spokojenosti zainteresovaných stran. Revize se uplatňují jak v procesu projektového řízení, tak na technické úrovni a jsou prováděny po celou dobu životnosti projektu. [jedenáct]

Role zúčastněných stran v řízení rizik

Všechny části procesu řízení rizik by měly být formalizovány a zdokumentovány. Formalizace a dokumentace procesu řízení rizik obsahuje popis kategorií rizik, perspektivy zúčastněných stran a popis (případně odkazem) technických a manažerských cílů, předpokladů a omezení. Je nutné vytvořit a udržovat rizikový profil, jehož každý záznam musí obsahovat důležitost rizika. Důležitost je určena kritérii rizik poskytnutými zúčastněnými stranami.

Povaha příslušného rizikového profilu by měla být zúčastněným stranám pravidelně sdělována na základě jejich potřeb, protože rizikový profil se může změnit, pokud je konkrétní stav rizika aktualizován.

Zúčastněné strany by měly v požadavcích na opatření v oblasti rizik poskytnout doporučené alternativy léčby rizik. Pokud se zúčastněné strany rozhodnou, že by měla být přijata opatření k tomu, aby bylo riziko optimální, pak by měla být implementována alternativní léčba rizik. Pokud zúčastněné strany přijmou riziko, které překračuje maximální hodnotu, pak by toto riziko mělo být považováno za vysokou prioritu a mělo by být neustále monitorováno, aby bylo možné určit nezbytná budoucí opatření k jeho řešení. [jedenáct]

Role zúčastněných stran v technických procesech

Technické procesy se používají k formulování požadavků na systém, k úpravě těchto požadavků na účinný produkt, který v případě potřeby umožňuje udržitelnou reprodukci tohoto produktu, jeho použití k poskytování požadovaných služeb, udržení poskytování těchto služeb a likvidaci produktu, když je stažen z oběhu. [1] :19 Technické procesy definují náplň práce, která umožňuje v rámci podnikových a projektových cílů zvyšovat zisky a minimalizovat rizika vznikající v procesu přijímání technických rozhodnutí a provádění vhodných akcí.

Role zúčastněných stran v procesu definování požadavků

Ve standardu Software System Life Cycle Processes je úkol definování požadavků stakeholderů formulován jako: definování požadavků na systém, jejichž splnění může zajistit poskytování služeb požadovaných uživateli a dalšími stakeholdery v daném aplikačním prostředí. Tento proces vám umožňuje definovat zainteresované strany nebo třídy zainteresovaných stran spojených se systémem během jeho životního cyklu. Navíc jsou zdůrazněny jejich potřeby a přání. V tomto procesu jsou potřeby a přání analyzovány a upraveny do obecného souboru požadavků zainteresovaných stran, které popisují požadované chování systému v procesu interakce s aplikačním prostředím. V porovnání s tímto souborem je každá poskytovaná služba validována, aby se potvrdilo, že systém plně splňuje stanovené požadavky. [jedenáct]

Výsledky úspěšné implementace procesu definování požadavků zainteresovaných stran jsou:

Proces identifikace stakeholderů lze formulovat jako: identifikace stakeholderů nebo tříd stakeholderů, kteří mají zájem o systém během jeho životního cyklu. Pokud přímá komunikace není možná, jsou vybráni zástupci zainteresovaných stran. [jedenáct]

Proces identifikace požadavků se skládá z řešení následujících úkolů:

  1. Je nutné určit požadavky zúčastněných stran projektu. Požadavky stakeholderů se mohou projevit ve formě potřeb, přání, požadavků, očekávání nebo omezení. Standardy kvality softwarových produktů popisují model kvality produktu a požadavky na kvalitu, které hrají důležitou roli při definování požadavků zainteresovaných stran. [12] [13] Nabyvatel, stejně jako možnosti uživatelů, mohou systému ukládat určitá omezení, která je třeba zohlednit v požadavcích zainteresovaných stran spolu s potřebami a přáními. Pro měření a hodnocení požadavků klíčových zainteresovaných stran se doporučuje stanovit ukazatele výkonnosti.
  2. Vzhledem k existujícím organizačním a technickým řešením existují pro systém omezení. Návrh musí definovat omezení systému.
  3. Posloupnost činností, obchodní procesy jsou definovány pro vytvoření pracovních scénářů a scénářů podpory z hlediska systémové aplikace. To je nezbytné pro identifikaci neidentifikovaných požadavků, tj. požadavků, které nejsou formálně specifikovány zúčastněnými stranami. Pomocí provozních scénářů a scénářů podpory jsou analyzovány podmínky používání systému, které jsou nutné pro následný návrh.
  4. Ve fázi implementace je nutné zohlednit možnosti a schopnosti uživatelů systému a následně i uložená omezení.
  5. Návrh by měl brát v úvahu možné nepříznivé účinky používání systému na lidské zdraví a bezpečnost. K tomu jsou stanoveny určité požadavky na zdraví, bezpečnost, podmínky prostředí, zabezpečení a další vlastnosti. [jedenáct]
Základní linie

Specifikace nebo produkt (verze systému), který byl formálně zkontrolován a schválen, aby následně posloužil jako základ pro další vývoj, a který lze změnit pouze prostřednictvím formálních a řízených změnových postupů. [3] :2 Často se používá jako "základní", "schválená verze", "archivovaná verze".

V projektu je nutné společně se zainteresovanými subjekty určit správnost vyjádření jejich požadavků. K tomu je nutné poskytnout zpětnou vazbu od vývojářů zainteresovaným stranám, aby bylo zajištěno správné pochopení stanovených požadavků. Je také nutné projednat a dosáhnout dohody o protichůdných a neproveditelných požadavcích zúčastněných stran. Projekt by měl zaznamenávat požadavky zúčastněných stran ve formě vhodné pro řízení požadavků v průběhu životního cyklu i po něm. Tyto záznamy tvoří základ požadavků zainteresovaných stran a uchovávají informace o změnách potřeb a jejich původu v průběhu životního cyklu systému.

Projekt by měl vysledovat zdroj vzniku potřeb z požadavků zainteresovaných stran. Požadavky zúčastněných stran jsou přezkoumávány v klíčových bodech rozhodování v procesu životního cyklu, aby bylo zajištěno, že budou brány v úvahu všechny změny potřeb. [11] Omezení v systému mohou vyplývat z:

Poznámky

  1. ↑ 1 2 3 4 5 6 7 ISO/IEC/IEEE 15288, 2015 .
  2. ↑ 1 2 3 4 ISO/IEC 29148, 2011 .
  3. ↑ 12 ISO/IEC 42010, 2011 .
  4. ↑ 1 2 3 4 5 6 7 OMG Essence, 2018 .
  5. ↑ PMBoK, 2013 .
  6. ↑ GOST R ISO 9000, 2015 .
  7. ↑ Tom Gilb . Deset nejvýkonnějších heuristik systémového inženýrství archivováno 7. března 2016 na Wayback Machine
  8. ↑ 1 2 3 4 Principy a praxe systémového inženýrství, 2011 .
  9. ↑ Levenchuk A. I. Systémové myšlení: učebnice. - Boston-Uldingen-Kyjev, 2019. - S. 152. - 534 s. — ISBN ISBN 978-1-62540-081-9 .
  10. ↑ 1 2 3 SEBoK, 2012 .
  11. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 GOST R ISO/IEC 12207, 2010 .
  12. ↑ ISO/IEC 9126-1, 2001 .
  13. ↑ ISO/IEC 25030, 2007 .

Literatura

Viz také

Odkazy