Intressent

Intressent ( engelska  stakeholder ), även intresserad part , involverad part , arbetsdeltagare , roll i projektet  - en person eller organisation som har rättigheter, andelar, krav eller intressen gällande systemet eller dess egenskaper som uppfyller deras behov och förväntningar ( ISO / IEC / IEEE 15288:2015 [1] , ISO/IEC 29148:2011 [2] :6 ).

Andra definitioner:

Intressenter ger möjligheter för systemet och är källan till krav på systemet. [4] :14

Intressenter är alltid en mer än du vet, och de du känner har minst ett behov mer än du nu vet.

Tom Gilb ( engelska ) [7] .

Inom systemteknik betraktas intressenter inom ramen för beslutsprocessen som människor eller organisationer som är beroende av resultaten av fattade beslut. En förståelse för vem som är intressent i förhållande till de beslut som fattas bör fastställas i förväg. Mycket ofta händer inte detta – intressenter bestäms inte innan beslut fattas. Så snart beslutet meddelas eller verkställs kommer dock alla som på något sätt berörts av detta beslut att yttra sig. [8] :258

Enligt A. I. Levenchuk är det lämpligt för intressenter att använda termen "roller i projektet" [9] .

Förhållandet mellan intressenter och andra enheter i ett tekniskt projekt

Figuren visar interaktionen mellan de viktigaste enheterna och objekten som påträffats i projektet. Objekt är grupperade i intresseområden. Således tillhör intressenten kundens intresseområde , eftersom  detta område innehåller allt relaterat till användning och drift av systemet. [4] :13-14

Typer (grupper) av intressenter

Det finns ingen uttömmande lista över typer (grupper) av intressenter, eftersom de kan skilja sig väsentligt för olika målsystem. Du kan ge exempel på de vanligaste typerna (grupperna) av intressenter som nämns i standarderna (GOST R ISO/IEC 15288:2005, ISO/IEC 29148:2011, GOST R ISO/IEC 12207:2010, OMG Essence), System Engineering Code of Knowledge ( SEBoK ) och systemteknik läroböcker [8] :

Identifiering av intressenter efter livscykelstadier

Varje system har sina egna livscykelstadier , såsom konceptuell design , utveckling, produktion, implementering, drift och kassering. För varje steg fastställs en lista över alla intressenter med intresse (relation) till det framtida systemet. Syftet med denna aktivitet är att överväga varje intressents synvinkel i alla skeden av systemets livscykel för att etablera en komplett uppsättning av intressentbehov som kan prioriteras och omvandlas till intressentkrav. Exempel på intressenternas förhållande till livscykelns stadier presenteras i tabell 1.

Tabell 1. Definition av intressenter i enlighet med stadierna i systemets livscykel [10] :262
Stadier i livscykeln Exempel på intressenter
Engineering (design, analys) Inköpare, potentiella användare, marknadsavdelning , utvecklingsavdelning , standardiseringsorgan , leverantörer , testavdelning ( verifiering och validering ) , produktionssystem, etc.
Utveckling Köpare, leverantörer, designers, integrationsteam m.m.
Överföring till produktion eller användning Kvalitetskontrollavdelning, produktionssystem, operatörer m.m.
Logistik och support Supporttjänster, instruktörer, deltagare i supply chain, etc.
Utnyttjande Vanliga användare, tillfälliga användare, etc.
likvidation Operatörer, bekräftande instans, etc.

Graden av redovisning och involvering av intressenter

Enligt OMG- förslagen särskiljs 6 stater där projektet kan vara i termer av redovisning, engagemang och tillfredsställelse av intressenter [4] :20-21 :

För att bedöma projektets nuvarande tillstånd i termer av redovisning, involvering och tillfredsställelse av intressenter, föreslås följande checklistor :

Tabell 2. Checklistor för intressenter [4] :22-23
stat Kontrolllista
Definierat

□ Alla intressentgrupper som för närvarande eller i framtiden påverkas av utvecklingen och driften av systemet har identifierats.
□ Det råder enighet om vilka intressentgrupper som ska vara representerade. Som ett minimum tas hänsyn till de intressentgrupper som finansierar, använder, stödjer och underhåller systemet.
□ Intressentrepresentanternas ansvar definieras.

Representerad

□ Representanter för intressenter har gått med på att utföra sina uppgifter.
□ Representanter för intressenter har befogenhet att utföra sina uppgifter.
□ Enad strategi för att säkerställa samarbete mellan representanter för intressenter.
□ Representanter för intressenter stödjer och respekterar teamets teknik.

inblandade

□ Representanter för intressenter bistår teamet i enlighet med deras ansvar.
□ Representanter för intressenter ger feedback och deltar i beslutsfattandet i tid.
□ Intressentrepresentanter är snabba med att kommunicera förändringar som är viktiga för sina intressentgrupper.

I överenskommelse

□ Representanter för intressenter enades om minimiförväntningarna på det kommande genomförandet av det nya systemet.
□ Representanter för intressenter är nöjda med sitt deltagande i arbetet.
□ Representanter för intressenter är överens om att teamet uppskattar och respekterar deras bidrag till arbetet.
□ Teammedlemmar är överens om att representanter för intressenter uppskattar och respekterar deras bidrag till arbetet.
□ Representanter för intressenter är överens om hur deras prioriteringar och synpunkter balanseras för att ge teamet tydlig riktning.

Nöjd för implementering (implementering)

□ Intressentrepresentanter ger feedback från sina intressentgruppers perspektiv.
□ Representanter för intressenter bekräftar att systemet är redo för implementering (implementering).

Nöjd med att använda

□ Intressenter använder det nya systemet och ger feedback om sina erfarenheter.
□ Intressenter bekräftar att det nya systemet uppfyller deras förväntningar.

Intressenternas roll i processerna för organisatoriskt stöd till projekt

Organisatoriskt projektstöd består av att hantera organisationers förmåga att leverera och förvärva produkter och tjänster genom support, provisionering och projektledning. Denna bestämmelse tillhandahåller de resurser och den infrastruktur som krävs för att underlätta projekt och säkerställer att organisatoriska mål och befintliga avtal uppfylls. Det gör inte anspråk på att vara den uppsättning affärsprocesser som utgör hanteringen av en organisations affärsaktiviteter. [elva]

Intressenternas roll i projektportföljförvaltning

Standarden GOST R ISO/IEC 12207:2010 (ISO/IEC 12207:2008) noterar att mekanismen för kontraktsändringshantering bör återspegla ledningens roller och ansvar, nivån på formalisering av förfrågningar om föreslagna ändringar och ytterligare förhandlingar om kontraktet, samt relationer med intressenter. [elva]

Som ett resultat av framgångsrik projektportföljförvaltning:

Intressenternas roll i kvalitetsstyrning

Organisationen behöver utföra regelbundna granskningar av projektens kvalitetssäkringsplaner. För varje projekt sätts olika kvalitetsmål som i sin tur bygger på intressenternas krav. [elva]

Syftet med en revision är att upprätthålla en delad utvecklingsförståelse med intressenterna om avtalets mål och vad som exakt behöver göras för att säkerställa att en produkt utvecklas till intressenternas belåtenhet. Revisioner tillämpas både i projektledningsprocessen och på teknisk nivå och genomförs under hela projektets livslängd. [elva]

Intressenternas roll i riskhantering

Alla delar av riskhanteringsprocessen bör formaliseras och dokumenteras. Formaliseringen och dokumentationen av riskhanteringsprocessen innehåller en beskrivning av riskkategorier, intressentperspektiv och en beskrivning (eventuellt genom referens) av tekniska och ledningsmässiga mål, antaganden och begränsningar. Det är nödvändigt att upprätta och upprätthålla en riskprofil, där varje post måste innehålla riskens betydelse. Betydelsen avgörs av riskkriterier som tillhandahålls av intressenter.

Arten av den relevanta riskprofilen bör regelbundet kommuniceras till intressenter baserat på deras behov, eftersom riskprofilen kan ändras om ett visst riskläge uppdateras.

Intressenter bör tillhandahålla rekommenderade riskbehandlingsalternativ i kraven på riskåtgärder. Om intressenterna beslutar att åtgärder ska vidtas för att göra risken optimal bör en alternativ riskbehandling implementeras. Om intressenter accepterar en risk som överstiger det maximala värdet, bör denna risk betraktas som en hög prioritet och ständigt övervakas för att fastställa nödvändiga framtida åtgärder för att hantera den. [elva]

Intressenternas roll i tekniska processer

Tekniska processer används för att formulera krav för ett system, modifiera dessa krav till en effektiv produkt som vid behov möjliggör hållbar reproduktion av denna produkt, använda den för att tillhandahålla de erforderliga tjänsterna, upprätthålla tillhandahållandet av dessa tjänster och kassera av produkten när den tas ur omlopp. [1] :19 Tekniska processer definierar innehållet i arbetet som gör det möjligt att, inom ramen för företagets och projektets mål, öka vinsten och minimera risker som uppstår i processen att fatta tekniska beslut och genomföra lämpliga åtgärder.

Intressenternas roll i kravdefinitionsprocessen

I standarden Software System Life Cycle Processes är uppgiften att definiera intressentkrav formulerad som: definiera systemkrav, vars uppfyllande kan säkerställa tillhandahållandet av tjänster som krävs av användare och andra intressenter i en given applikationsmiljö. Denna process låter dig definiera de intressenter eller klasser av intressenter som är associerade med systemet under hela dess livscykel. Dessutom lyfts deras behov och önskemål fram. I processen analyseras och modifieras behov och önskemål till en generell uppsättning intressentkrav som beskriver systemets önskade beteende i processen för interaktion med applikationsmiljön. Mot denna uppsättning valideras varje tillhandahållen tjänst för att bekräfta att systemet helt uppfyller de angivna kraven. [elva]

Resultaten av den framgångsrika implementeringen av processen för definition av intressentkrav är:

Processen för identifiering av intressenter kan formuleras som: identifiering av intressenter eller klasser av intressenter som har ett intresse av systemet under dess livscykel. Om direkt kommunikation inte är möjlig väljs representanter för intressenter. [elva]

Kravidentifieringsprocessen består av att lösa följande uppgifter:

  1. Det är nödvändigt att fastställa kraven från projektets intressenter. Intressenternas krav kan visa sig i form av behov, önskemål, krav, förväntningar eller begränsningar. Kvalitetsstandarder för mjukvaruprodukter beskriver produktkvalitetsmodellen och kvalitetskraven, som spelar en viktig roll för att definiera intressenternas krav. [12] [13] Köparen, liksom användarnas möjligheter, kan införa vissa begränsningar för systemet, som måste beaktas i intressenternas krav tillsammans med behov och önskemål. För att mäta och utvärdera kraven från nyckelintressenter rekommenderas det att upprätta resultatindikatorer.
  2. På grund av befintliga organisatoriska och tekniska lösningar finns det begränsningar för systemet. Designen måste definiera systemets begränsningar.
  3. Sekvens av aktiviteter, affärsprocesser definieras för att upprätta arbetsscenarier och stödscenarier när det gäller systemtillämpning. Detta är nödvändigt för att identifiera oidentifierade krav, det vill säga krav som inte är formellt specificerade av intressenter. Med hjälp av driftscenarier och supportscenarier analyseras förutsättningarna för att använda systemet, vilka är nödvändiga för efterföljande design.
  4. I implementeringsstadiet är det nödvändigt att ta hänsyn till kapaciteten och förmågorna hos användarna av systemet, och följaktligen de pålagda begränsningarna.
  5. Utformningen bör ta hänsyn till de eventuella negativa effekterna av användningen av systemet på människors hälsa och säkerhet. För att göra detta ställs vissa krav på hälsa, säkerhet, miljöförhållanden, säkerhet och andra egenskaper. [elva]
Baslinje

En specifikation eller produkt (systemversion) som formellt har granskats och godkänts för att sedan ligga till grund för vidareutveckling, och som endast kan ändras genom formella och kontrollerade förändringsprocedurer. [3] :2 Används ofta som "baslinje", "godkänd version", "arkiverad version".

I projektet är det nödvändigt, tillsammans med intressenter, att fastställa riktigheten av uttrycket av deras krav. För att göra detta är det nödvändigt att ge feedback från utvecklare till intressenter för att säkerställa att de krav som ställs är korrekt förstådda. Det är också nödvändigt att diskutera och nå enighet om motstridiga och omöjliga intressenters krav. Projektet bör registrera intressenternas krav i en form som lämpar sig för kravhantering under hela livscykeln och därefter. Dessa register upprättar en baslinje för intressenternas krav och lagrar information om förändringar i behov och deras ursprung under systemets livscykel.

Projektet bör spåra källan till uppkomsten av behov från intressenternas krav. Intressenternas krav ses över vid viktiga beslutspunkter i livscykelprocessen för att säkerställa att eventuella förändringar i behov beaktas. [11] Begränsningar i ett system kan bero på:

Anteckningar

  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 . De tio mest kraftfulla systemtekniska heuristikerna arkiverade 7 mars 2016 på Wayback Machine
  8. ↑ 1 2 3 4 Systemtekniska principer och praxis, 2011 .
  9. ↑ Levenchuk A. I. Systemtänkande : Lärobok. - Boston-Uldingen-Kiev, 2019. - S. 152. - 534 sid. — 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 .

Litteratur

Se även

Länkar