Stakeholder ( inglés stakeholder ), también parte interesada , parte involucrada , participante del trabajo , rol en el proyecto - una persona u organización que tiene derechos, acciones, requisitos o intereses con respecto al sistema o sus propiedades que satisfacen sus necesidades y expectativas ( ISO / IEC / IEEE 15288:2015 [1] , ISO/IEC 29148:2011 [2] :6 ).
Otras definiciones:
Las partes interesadas brindan oportunidades para el sistema y son la fuente de requisitos para el sistema. [4] :14
Las partes interesadas son siempre una más de las que conoce, y las que conoce tienen al menos una necesidad más de las que ahora conoce.
Tom Gilb ( inglés ) [7] .En ingeniería de sistemas , las partes interesadas se consideran en el contexto del proceso de toma de decisiones como personas u organizaciones que dependen de los resultados de las decisiones tomadas. Se debe establecer de antemano quién es la parte interesada en relación con las decisiones que se toman. Muy a menudo, esto no sucede: las partes interesadas no se determinan antes de tomar las decisiones. Sin embargo, tan pronto como la decisión sea anunciada o implementada, todos los que se vieron afectados de alguna manera por esta decisión expresarán su opinión. [8] :258
Según A. I. Levenchuk, es apropiado que las partes interesadas utilicen el término “roles en el proyecto” [9] .
La figura muestra la interacción de las principales entidades y objetos encontrados en el proyecto. Los objetos se agrupan en áreas de interés. Así, el stakeholder pertenece al área de interés del cliente , ya que esta área contiene todo lo relacionado con el uso y operación del sistema. [4] :13-14
No existe una lista exhaustiva de tipos (grupos) de partes interesadas, ya que pueden diferir significativamente para diferentes sistemas de destino. Puede dar ejemplos de los tipos (grupos) más comunes de partes interesadas que se mencionan en los estándares (GOST R ISO/IEC 15288:2005, ISO/IEC 29148:2011, GOST R ISO/IEC 12207:2010, OMG Essence), Código de conocimientos de ingeniería de sistemas ( SEBoK ) y libros de texto de ingeniería de sistemas [8] :
Cada sistema tiene sus propias etapas del ciclo de vida , como el diseño conceptual , el desarrollo, la producción, la implementación, la operación y la eliminación. Para cada etapa, se determina una lista de todas las partes interesadas con interés (relación) con el futuro sistema. El propósito de esta actividad es considerar el punto de vista de cada parte interesada en todas las etapas del ciclo de vida del sistema para establecer un conjunto completo de necesidades de las partes interesadas que se puedan priorizar y convertir en requisitos de las partes interesadas. En la Tabla 1 se presentan ejemplos de la relación de los stakeholders con las etapas del ciclo de vida.
| Etapas del ciclo de vida | Ejemplos de partes interesadas |
|---|---|
| Ingeniería (diseño, análisis) | Adquiriente, usuarios potenciales, departamento de marketing , departamento de desarrollo, organismo de normalización , proveedores , departamento de pruebas ( verificación y validación ), sistema de producción, etc. |
| Desarrollo | Comprador, proveedores, diseñadores, equipo de integración, etc. |
| Transferir a producción o uso | Departamento de control de calidad, sistema de producción, operarios, etc. |
| Logística y soporte | Servicios de apoyo, instructores, participantes de la cadena de suministro, etc. |
| Explotación | Usuarios habituales, usuarios ocasionales, etc. |
| liquidación | Operadores, cuerpo de confirmación, etc. |
Según las propuestas de OMG , se distinguen 6 estados en los que puede estar el proyecto en términos de contabilidad, involucramiento y satisfacción de los stakeholders [4] :20-21 :
Para evaluar el estado actual del proyecto en términos de contabilidad, participación y satisfacción de las partes interesadas, se proponen las siguientes listas de verificación :
| Estado | Lista de control |
|---|---|
| definido |
□ Se han identificado todos los grupos de partes interesadas que se ven afectados actualmente o en el futuro por el desarrollo y funcionamiento del sistema. |
| representado |
□ Los representantes de las partes interesadas han aceptado desempeñar sus funciones. |
| involucrado |
□ Los representantes de las partes interesadas ayudan al equipo de acuerdo con sus responsabilidades. |
| En acuerdo |
□ Los representantes de las partes interesadas acordaron las expectativas mínimas para la próxima implementación del nuevo sistema. |
| Satisfecho para el despliegue (implementación) |
□ Los representantes de las partes interesadas brindan retroalimentación desde la perspectiva de sus grupos de partes interesadas. |
| satisfecho con el uso |
□ Las partes interesadas utilizan el nuevo sistema y brindan retroalimentación sobre sus experiencias. |
El soporte de proyectos organizacionales consiste en gestionar la capacidad de las organizaciones para entregar y adquirir productos y servicios a través del soporte, el aprovisionamiento y la gestión de proyectos. Esta disposición proporciona los recursos y la infraestructura necesarios para facilitar los proyectos y asegura que se cumplan los objetivos de la organización y los acuerdos existentes. No pretende ser el conjunto de procesos de negocio que componen la gestión de las actividades de negocio de una organización. [once]
El estándar GOST R ISO/IEC 12207:2010 (ISO/IEC 12207:2008) señala que el mecanismo de gestión de cambios del contrato debe reflejar las funciones y responsabilidades de la gestión, el nivel de formalización de las solicitudes de cambios propuestos y negociaciones adicionales sobre el contrato, así como las relaciones con las partes interesadas. [once]
Como resultado de una gestión exitosa de la cartera de proyectos:
La organización necesita realizar revisiones periódicas de los planes de aseguramiento de la calidad del proyecto. Para cada proyecto, se establecen diferentes objetivos de calidad, que a su vez se basan en los requisitos de las partes interesadas. [once]
El propósito de una auditoría es mantener un entendimiento de desarrollo compartido con las partes interesadas con respecto a los objetivos del acuerdo y qué se debe hacer exactamente para ayudar a garantizar que un producto se desarrolle a satisfacción de las partes interesadas. Las revisiones se aplican tanto en el proceso de gestión del proyecto como a nivel técnico y se llevan a cabo a lo largo de la vida del proyecto. [once]
Todas las partes del proceso de gestión de riesgos deben formalizarse y documentarse. La formalización y documentación del proceso de gestión de riesgos contiene una descripción de las categorías de riesgo, las perspectivas de las partes interesadas y una descripción (posiblemente por referencia) de los objetivos, suposiciones y limitaciones técnicas y de gestión. Es necesario establecer y mantener un perfil de riesgo, cada entrada del cual debe contener la importancia del riesgo. La importancia está determinada por los criterios de riesgo proporcionados por las partes interesadas.
La naturaleza del perfil de riesgo relevante debe comunicarse periódicamente a las partes interesadas en función de sus necesidades, ya que el perfil de riesgo puede cambiar si se actualiza un estado de riesgo en particular.
Las partes interesadas deben proporcionar alternativas de tratamiento de riesgo recomendadas en los requisitos de acción de riesgo. Si las partes interesadas deciden que se deben tomar medidas para que el riesgo sea óptimo, entonces se debe implementar un tratamiento de riesgo alternativo. Si las partes interesadas aceptan un riesgo que excede el valor máximo, entonces este riesgo debe ser considerado como de alta prioridad y monitoreado constantemente para determinar las acciones futuras necesarias para abordarlo. [once]
Los procesos técnicos se utilizan para formular requisitos para un sistema, modificar esos requisitos en un producto eficiente que permita, si es necesario, la reproducción sostenible de este producto, utilizarlo para proporcionar los servicios requeridos, mantener la prestación de estos servicios y eliminarlos. del producto cuando sea retirado de la circulación. [1] :19 Los procesos técnicos definen el contenido del trabajo que permite, en el marco de los objetivos de la empresa y del proyecto, aumentar las ganancias y minimizar los riesgos que surgen en el proceso de toma de decisiones técnicas e implementación de acciones apropiadas.
En el estándar Procesos del ciclo de vida del sistema de software, la tarea de definir los requisitos de las partes interesadas se formula como: definir los requisitos del sistema, cuyo cumplimiento puede garantizar la prestación de los servicios requeridos por los usuarios y otras partes interesadas en un entorno de aplicación determinado. Este proceso le permite definir las partes interesadas o clases de partes interesadas asociadas con el sistema a lo largo de su ciclo de vida. Además, se destacan sus necesidades y deseos. En el proceso, las necesidades y los deseos se analizan y modifican en un conjunto general de requisitos de las partes interesadas que describen el comportamiento deseado del sistema en el proceso de interacción con el entorno de la aplicación. Frente a este conjunto, cada servicio prestado se valida para confirmar que el sistema satisface plenamente los requisitos establecidos. [once]
Los resultados de la implementación exitosa del proceso de definición de requisitos de las partes interesadas son:
El proceso de identificación de partes interesadas se puede formular como: identificación de partes interesadas o clases de partes interesadas que tienen interés en el sistema durante su ciclo de vida. Si la comunicación directa no es posible, se seleccionan representantes de las partes interesadas. [once]
El proceso de identificación de requisitos consiste en resolver las siguientes tareas:
Una especificación o producto (versión del sistema) que ha sido formalmente revisado y acordado para servir posteriormente como base para un mayor desarrollo, y que solo puede modificarse a través de procedimientos de cambio formales y controlados. [3] : 2 A menudo se usa como "línea de base", "versión aprobada", "versión archivada".
En el proyecto, es necesario, junto con las partes interesadas, determinar la corrección de la expresión de sus requisitos. Para hacer esto, es necesario proporcionar retroalimentación de los desarrolladores a las partes interesadas para garantizar que los requisitos que se establecen se comprendan correctamente. También es necesario discutir y llegar a un acuerdo sobre los requisitos conflictivos e inviables de las partes interesadas. El proyecto debe registrar los requisitos de las partes interesadas en una forma adecuada para la gestión de requisitos a lo largo del ciclo de vida y más allá. Estos registros establecen una línea de base de los requisitos de las partes interesadas y almacenan información sobre los cambios en las necesidades y su origen durante el ciclo de vida del sistema.
El proyecto debe rastrear la fuente de la aparición de necesidades a partir de los requisitos de las partes interesadas. Los requisitos de las partes interesadas se revisan en puntos de decisión clave en el proceso del ciclo de vida para garantizar que se tenga en cuenta cualquier cambio en las necesidades. [11] Las restricciones en un sistema pueden resultar de: