Interessent

Stakeholder ( engelsk  stakeholder ), også interesseret part , involveret part , arbejdsdeltager , rolle i projektet  - en person eller organisation, der har rettigheder, andel, krav eller interesser vedrørende systemet eller dets egenskaber, der opfylder deres behov og forventninger ( ISO / IEC / IEEE 15288:2015 [1] , ISO/IEC 29148:2011 [2] :6 ).

Andre definitioner:

Interessenter giver muligheder for systemet og er kilden til krav til systemet. [4] :14

Interessenter er altid en mere, end du ved, og dem, du kender, har mindst et behov mere, end du nu ved.

Tom Gilb ( engelsk ) [7] .

I systemteknik betragtes interessenter i forbindelse med beslutningsprocessen som mennesker eller organisationer, der er afhængige af resultaterne af trufne beslutninger. En forståelse af, hvem der er interessenten i forhold til de beslutninger, der træffes, bør etableres på forhånd. Meget ofte sker dette ikke - interessenterne er ikke fastlagte, før der træffes beslutninger. Men så snart beslutningen er bekendtgjort eller gennemført, vil alle, der på nogen måde var berørt af denne beslutning, give udtryk for deres mening. [8] :258

Ifølge A. I. Levenchuk er det hensigtsmæssigt for interessenter at bruge udtrykket "roller i projektet" [9] .

Forholdet mellem interessenter og andre enheder i et ingeniørprojekt

Figuren viser samspillet mellem de vigtigste enheder og objekter, der er stødt på i projektet. Objekter er grupperet i interesseområder. Interessenten tilhører således kundens interesseområde , da  dette område indeholder alt relateret til brug og drift af systemet. [4] :13-14

Typer (grupper) af interessenter

Der er ingen udtømmende liste over typer (grupper) af interessenter, da de kan variere betydeligt for forskellige målsystemer. Du kan give eksempler på de mest almindelige typer (grupper) af interessenter, der er nævnt i standarderne (GOST R ISO/IEC 15288:2005, ISO/IEC 29148:2011, GOST R ISO/IEC 12207:2010, OMG Essence), System Engineering Code of Knowledge ( SEBoK ) og systemteknik lærebøger [8] :

Identifikation af interessenter efter livscyklusfaser

Hvert system har sine egne livscyklusstadier , såsom konceptuelt design , udvikling, produktion, implementering, drift og bortskaffelse. For hvert trin opstilles en liste over alle interessenter med interesse (relation) til det fremtidige system. Formålet med denne aktivitet er at overveje hver enkelt interessents synspunkt på alle stadier af systemets livscyklus for at etablere et komplet sæt af interessentbehov, der kan prioriteres og konverteres til interessentkrav. Eksempler på interessenters forhold til faserne af livscyklussen er vist i tabel 1.

Tabel 1. Definition af interessenter i overensstemmelse med stadierne af systemets livscyklus [10] :262
Livscyklus stadier Eksempler på interessenter
Engineering (design, analyse) Indkøber , potentielle brugere, marketingafdeling , udviklingsafdeling, standardiseringsorgan , leverandører , testafdeling ( verifikation og validering ), produktionssystem mv.
Udvikling Indkøber, leverandører, designere, integrationsteam mv.
Overførsel til produktion eller brug Kvalitetskontrolafdeling, produktionssystem, operatører mv.
Logistik og support Supporttjenester, instruktører, forsyningskædedeltagere mv.
Udnyttelse Almindelige brugere, tilfældige brugere osv.
likvidation Operatører, bekræftende organ mv.

Graden af ​​regnskab og involvering af interessenter

Ifølge OMG- forslagene skelnes der mellem 6 stater, hvor projektet kan være med hensyn til regnskab, involvering og tilfredsstillelse af interessenter [4] :20-21 :

For at vurdere projektets aktuelle tilstand med hensyn til regnskab, involvering og tilfredshed af interessenter, foreslås følgende tjeklister :

Tabel 2. Tjeklister for interessenter [4] :22-23
Stat Kontrolliste
Defineret

□ Alle interessentgrupper, der i øjeblikket eller i fremtiden er berørt af udviklingen og driften af ​​systemet, er blevet identificeret.
□ Der er enighed om, hvilke interessentgrupper der skal være repræsenteret. Der tages som minimum hensyn til de interessentgrupper, der finansierer, bruger, understøtter og vedligeholder systemet.
□ Ansvar for interessentrepræsentanter defineres.

Repræsenteret

□ Repræsentanter for interessenter har accepteret at udføre deres opgaver.
□ Repræsentanter for interessenter har beføjelse til at udføre deres opgaver.
□ Aftalt tilgang til at sikre samarbejde mellem interessentrepræsentanter.
□ Interessentrepræsentanter støtter og respekterer teamets teknologi.

involveret

□ Interessentrepræsentanter bistår teamet i overensstemmelse med deres ansvar.
□ Repræsentanter for interessenter giver feedback og deltager i beslutningstagningen rettidigt.
□ Interessentrepræsentanter er hurtige til at kommunikere ændringer, der har betydning for deres interessentgrupper.

I overensstemmelse

□ Repræsentanter for interessenter blev enige om minimumsforventningerne til den kommende implementering af det nye system.
□ Repræsentanter for interessenter er tilfredse med deres deltagelse i arbejdet.
□ Repræsentanter for interessenter er enige om, at teamet værdsætter og respekterer deres bidrag til arbejdet.
□ Teammedlemmer er enige om, at interessentrepræsentanter værdsætter og respekterer deres bidrag til arbejdet.
□ Repræsentanter for interessenter er enige om, hvordan deres prioriteter og synspunkter afbalanceres for at give teamet en klar retning.

Tilfreds med implementering (implementering)

□ Interessentrepræsentanter giver feedback fra deres interessentgruppers perspektiv.
□ Repræsentanter for interessenter bekræfter, at systemet er klar til implementering (implementering).

Tilfreds med at bruge

□ Interessenter bruger det nye system og giver feedback på deres erfaringer.
□ Interessenter bekræfter, at det nye system lever op til deres forventninger.

Interessenternes rolle i processerne for organisatorisk støtte til projekter

Organisatorisk projektstøtte består af styring af organisationers evne til at levere og erhverve produkter og tjenester gennem support, levering og projektledelse. Denne bestemmelse giver de nødvendige ressourcer og infrastruktur til at facilitere projekter og sikrer, at organisatoriske mål og eksisterende aftaler overholdes. Det hævder ikke at være det sæt af forretningsprocesser, der udgør styringen af ​​en organisations forretningsaktiviteter. [elleve]

Interessenternes rolle i projektporteføljestyring

GOST R ISO/IEC 12207:2010 (ISO/IEC 12207:2008) standarden bemærker, at kontraktændringsstyringsmekanismen bør afspejle ledelsens roller og ansvar, niveauet for formalisering af anmodninger om foreslåede ændringer og yderligere forhandlinger om kontrakten, samt relationer til interessenter. [elleve]

Som et resultat af vellykket projektporteføljestyring:

Interessenternes rolle i kvalitetsstyring

Organisationen skal udføre periodiske gennemgange af projektkvalitetssikringsplaner. For hvert projekt opstilles forskellige kvalitetsmål, som igen er baseret på interessentkrav. [elleve]

Formålet med en revision er at opretholde en fælles udviklingsforståelse med interessenterne vedrørende aftalens formål, og hvad der præcist skal gøres for at sikre, at et produkt udvikles til interessenternes tilfredshed. Revisioner anvendes både i projektledelsesprocessen og på det tekniske niveau og udføres i hele projektets levetid. [elleve]

Interessenternes rolle i risikostyring

Alle dele af risikostyringsprocessen bør formaliseres og dokumenteres. Formaliseringen og dokumentationen af ​​risikostyringsprocessen indeholder en beskrivelse af risikokategorier, interessentperspektiver og en beskrivelse (eventuelt ved reference) af tekniske og ledelsesmæssige mål, antagelser og begrænsninger. Det er nødvendigt at etablere og vedligeholde en risikoprofil, hvor hver indtastning skal indeholde risikoens betydning. Betydningen afgøres af risikokriterier, som stilles til rådighed af interessenter.

Arten af ​​den relevante risikoprofil bør med jævne mellemrum kommunikeres til interessenter baseret på deres behov, da risikoprofilen kan ændre sig, hvis en bestemt risikotilstand opdateres.

Interessenter bør give anbefalede risikobehandlingsalternativer i krav til risikohandlinger. Hvis interessenterne beslutter, at der skal sættes ind for at gøre risikoen optimal, så bør en alternativ risikobehandling implementeres. Hvis interessenter accepterer en risiko, der overstiger den maksimale værdi, bør denne risiko betragtes som en høj prioritet og konstant overvåges for at bestemme de nødvendige fremtidige handlinger for at imødegå den. [elleve]

Interessenternes rolle i tekniske processer

Tekniske processer bruges til at formulere krav til et system, ændre disse krav til et effektivt produkt, der om nødvendigt muliggør bæredygtig reproduktion af dette produkt, bruge det til at levere de nødvendige tjenester, opretholde leveringen af ​​disse tjenester og bortskaffe af produktet, når det tages ud af cirkulation. [1] :19 Tekniske processer definerer indholdet af arbejdet, der gør det muligt inden for rammerne af virksomhedens og projektets mål at øge profitten og minimere risici, der opstår i processen med at træffe tekniske beslutninger og implementere passende handlinger.

Interessenternes rolle i kravdefinitionsprocessen

I Software System Life Cycle Processes-standarden er opgaven med at definere interessentkrav formuleret som: definere systemkrav, hvis opfyldelse kan sikre levering af tjenester, som kræves af brugere og andre interessenter i et givet applikationsmiljø. Denne proces giver dig mulighed for at definere de interessenter eller klasser af interessenter, der er knyttet til systemet gennem dets livscyklus. Derudover belyses deres behov og ønsker. I processen analyseres og modificeres behov og ønsker til et generelt sæt af interessentkrav, der beskriver den ønskede adfærd for systemet i processen med interaktion med applikationsmiljøet. I forhold til dette sæt valideres hver serviceydelse for at bekræfte, at systemet fuldt ud opfylder de angivne krav. [elleve]

Resultaterne af den vellykkede implementering af processen til definition af interessentkrav er:

Interessentidentifikationsprocessen kan formuleres som: identifikation af interessenter eller klasser af interessenter, der har en interesse i systemet i dets livscyklus. Hvis direkte kommunikation ikke er mulig, vælges interessentrepræsentanter. [elleve]

Kravidentifikationsprocessen består af løsning af følgende opgaver:

  1. Det er nødvendigt at fastlægge kravene fra projektets interessenter. Interessentkrav kan vise sig i form af behov, ønsker, krav, forventninger eller begrænsninger. Softwareproduktkvalitetsstandarder beskriver produktkvalitetsmodellen og kvalitetskravene, som spiller en vigtig rolle i at definere interessenternes krav. [12] [13] Køberen, såvel som brugernes muligheder, kan pålægge systemet nogle begrænsninger, som skal tages i betragtning i interessenternes krav sammen med behov og ønsker. For at måle og evaluere kravene fra nøgleinteressenter anbefales det at etablere præstationsindikatorer.
  2. Grundet eksisterende organisatoriske og tekniske løsninger er der begrænsninger for systemet. Designet skal definere systemets begrænsninger.
  3. Sekvens af aktiviteter, forretningsprocesser er defineret for at etablere arbejdsscenarier og supportscenarier med hensyn til systemanvendelse. Dette er nødvendigt for at identificere uidentificerede krav, det vil sige krav, der ikke formelt er specificeret af interessenter. Ved hjælp af driftsscenarier og supportscenarier analyseres betingelserne for at bruge systemet, som er nødvendige for efterfølgende design.
  4. På implementeringsstadiet er det nødvendigt at tage højde for kapaciteten og evnerne hos brugerne af systemet og følgelig de pålagte begrænsninger.
  5. Designet bør tage højde for de mulige negative virkninger af brugen af ​​systemet på menneskers sundhed og sikkerhed. For at gøre dette er der fastsat visse krav til sundhed, sikkerhed, miljøforhold, sikkerhed og andre egenskaber. [elleve]
Baseline

En specifikation eller et produkt (systemversion), der er formelt gennemgået og aftalt til efterfølgende at tjene som grundlag for videreudvikling, og som kun kan ændres gennem formelle og kontrollerede ændringsprocedurer. [3] :2 Ofte brugt som "baseline", "godkendt version", "arkiveret version".

I projektet er det nødvendigt, sammen med interessenter, at fastslå rigtigheden af ​​udtrykket af deres krav. For at gøre dette er det nødvendigt at give feedback fra udviklere til interessenter for at sikre, at de stillede krav er korrekt forstået. Det er også nødvendigt at diskutere og nå til enighed om modstridende og uigennemførlige interessentkrav. Projektet bør registrere interessenternes krav i en form, der er egnet til kravstyring gennem hele livscyklussen og derefter. Disse registreringer etablerer en basislinje af interessentkrav og gemmer information om ændringer i behov og deres oprindelse i løbet af systemets livscyklus.

Projektet bør spore kilden til fremkomsten af ​​behov fra interessenternes krav. Interessenternes krav gennemgås på vigtige beslutningspunkter i livscyklusprocessen for at sikre, at der tages højde for eventuelle ændringer i behov. [11] Begrænsninger i et system kan skyldes:

Noter

  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 ti mest kraftfulde systemtekniske heuristik blev arkiveret 7. marts 2016 på Wayback Machine
  8. 1 2 3 4 Systemtekniske principper og praksis, 2011 .
  9. Levenchuk A. I. Systemtænkning : Lærebog. - Boston-Uldingen-Kyiv, 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 .

Litteratur

Se også

Links