La primera medida de éxito de un sistema software es el grado en el

La Identificación de Stakeholders en la Ingeniería de
Requisitos
Trabajo de investigación tutelado.
Doctorando: Carla Leninca Pacheco Agüero.
Tutor: Dr. Edmundo Tovar Caro.
SINTESIS
La primera medida de éxito de un sistema software es el grado en el cuál este cumple con el
propósito para el que fue creado, es decir que el sistema satisfaga los requisitos. Sin
embargo, a pesar de que se conocen muchas de las características que pueden tener unos
requisitos correctamente obtenidos, todavía en la actualidad - principalmente en la industria
- se incluyen requisitos de pobre calidad, que son ambiguos, incompletos, inconsistentes,
incorrectos, inusables, nada factibles o bien que no pueden ser verificados.
Para reducir el coste de arreglar requisitos erróneos o malentendidos en la industria del
software- problema que incrementa exponencialmente el tiempo de desarrollo de un
proyecto software- es crucial tener una buena Ingeniería de Requisitos (IR). La IR siempre
debe tener como objetivo descubrir el propósito del software mediante el proceso de la
identificación de los stakeholders y de sus necesidades, así como documentar estas
necesidades para un análisis posterior y su subsiguiente implementación.
Por lo que una de las actividades más importantes dentro de la IR, es la elicitación de los
requisitos, ya que descubre cuál es el problema a resolver y las limitaciones que tendrá el
proyecto, así mismo identifica a los stakeholders - aspecto crítico en esta etapa puesto que
de ellos depende que el proyecto tenga éxito o fracase-. En la etapa de la elicitación, es
fundamental la actividad humana por lo que los stakeholders deben ser identificados, así
mismo deben establecerse las relaciones entre el equipo de desarrollo y el cliente. Uno de
los principios fundamentales de la IR es que exista una buena comunicación entre los
usuarios y los ingenieros del software, ya que este suele ser un problema crucial en un
La Identificación de Stakeholders en la Ingeniería de Requisitos
desarrollo. Previo al desarrollo, los especialistas de requisitos deben establecer una pauta
para esta comunicación, ya que son estos quiénes deben mediar entre el dominio de los
usuarios de software (y otros stakeholders) y las palabras técnicas utilizadas por el
ingeniero de software.
Sin embargo, el proceso de especificar requisitos correctos y de alta calidad no es una tarea
trivial, debido a que frecuentemente la identificación de los stakeholders, así como de sus
necesidades y expectativas es llevada a cabo muy pobremente dentro del proyecto. Por lo
que cuándo lo que nos interesa es cómo identificar al conjunto de stakeholders en un
proyecto especifico, las definiciones encontradas en la literatura de la IR pueden no ser de
gran ayuda ya que por lo regular es común encontrar ejemplos y categorías de stakeholders
que suelen ser inapropiados o incompletos para el problema específico a resolver.
Hasta el momento, no existen muchas metodologías o herramientas para identificar a los
stakeholders en un proyecto software; ya que se asume erróneamente que este proceso es
obvio en un desarrollo o bien que los usuarios directos, clientes y el equipo de software son
los stakeholders exclusivos de cualquier proyecto. Actualmente, las metodologías existentes
sólo dicen qué categorías pueden utilizarse ya que no especifican los roles que los
stakeholders pueden desempeñar dependiendo del proyecto a desarrollar, por ejemplo en el
Modelo Integrado de Capacidad de Madurez (CMMiSM), en el Cuerpo de Conocimiento de
IS (SWEBOK) del Instituto de Ingeniería Eléctrica y Electrónica (IEEE), en los reportes
técnicos de la CMU/SEI, etc.
La mayoría de los métodos propuestos para la identificación de los stakeholders tienen muy
poca madurez o bien carecen de una validación en la puesta en práctica que nos permita
evaluar su funcionalidad, aspecto muy importante, ya que la calidad de un software refleja
la madurez del proceso de desarrollo utilizado. Este debe ser un aspecto clave en la
elicitación de los requisitos, ya que se conoce que muchos proyectos software fracasan
debido a que no se obtuvieron los requisitos correctos a partir de los stakeholders
involucrados y el hecho de corregir estos defectos en la fase de mantenimiento puede
requerir cerca de doscientas veces más de esfuerzo que si la corrección fuese llevada a cabo
en la fase de especificación del software.
Éste trabajo de investigación tuvo por objeto definir criterios que permitieran realizar un
análisis comparativo de las metodologías existentes utilizadas en la identificación de los
La Identificación de Stakeholders en la Ingeniería de Requisitos
stakeholders, para presentar sus aspectos fuertes y débiles. Dicha comparación se hizo en
base a los siguientes criterios propuestos:
Criterio 1: Se soluciona la identificación de stakeholders.
Este indicador se utiliza como un control para asegurar que todos los métodos analizados
corresponden a la identificación de stakeholders.
Criterio 2: Establecimiento de roles para los stakeholders.
El rol de un stakeholder debe ser definido en base a la naturaleza del interés que la persona
tiene en el proyecto; por lo que se puede decir que es el rol quién define al stakeholder. El
resultado del establecimiento de roles demuestra las conexiones que existen entre el
proyecto y los stakeholders. Este indicador puede ayudar a lograr una mejor comprensión
de las diferentes interpretaciones que cada autor tiene del término stakeholder y de su
desempeño dentro de un proyecto específico.
Criterio 3: Análisis de requisitos.
Este indicador es muy importante para determinar que requisitos son necesidades reales. Se
debe tomar como base el objetivo del proyecto para asignar las prioridades a los requisitos,
lo que representa un gran reto ya que los proyectos software usualmente son descritos como
un conjunto de atributos y dependiendo del valor de dichos atributos el proyecto puede ser
resuelto de diferentes formas, por lo que los atributos deben escogerse dependiendo de las
expectativas que cubrirá el proyecto.
Criterio 4: Establecimiento del alcance del proyecto.
La depuración de los requisitos se puede utilizar como un marco de referencia para evaluar
si los requisitos que serán especificados satisfacen con éxito la meta que se marco en el
inicio del proyecto con lo que se podrá establecer un criterio que determine la cobertura en
base a lo planeado.
Criterio 5: Análisis de las características del stakeholder.
Se deben analizar las cualidades, las habilidades, el conocimiento y la experiencia que el
stakeholder debe poseer para que pueda cubrir las características que exigen determinados
roles o actividades específicas dentro de un proyecto. Con lo que se obtiene un amplio
dominio del tipo de conocimiento y de la responsabilidad que la persona posee.
La Identificación de Stakeholders en la Ingeniería de Requisitos
Criterio 6: Provee una guía de los stakeholders.
Este indicador nos brinda información si el método analizado proporciona una lista
apropiada de los posibles stakeholders que se pueden encontrar en las diferentes actividades
que se realizan en un proyecto.
Criterio 7: Validación del método.
Este criterio nos puede ayudar a determinar el grado de madurez del método, ya que deben
existir resultados que avalen que dicho método cumple con el objetivo para el cuál fue
creado, que este caso: la identificación de stakeholders.
Los métodos analizados en este trabajo, con base en los criterios anteriormente expuestos,
son los siguientes:
ƒ
Teoría del saliente.
ƒ
Aproximación a la identificación de stakeholders.
ƒ
Método de la red de stakeholders.
ƒ
Plantilla de Volere.
ƒ
MEWSIC.
ƒ
Método basado en los principios de los sistemas.
ƒ
Modelo del banco mundial.
En la Tabla1 se muestra un cuadro comparativo que sintetiza la aplicación de cada uno de
los criterios a los métodos mencionados anteriormente, en ella se puede apreciar que ningún
método cubre todos los criterios, a pesar de que algunos presentan propuestas interesantes.
Criterios
Teoría del
Aproximación a
Red de
Platilla
Saliente
la Identificación
stakeholders
MEWSIC
Principios
Banco
de
de la
Mundial
Volere
Ciencia de
Sistemas
Soluciona
la
identificación
de
stakeholders.
3
3
3
3
3
3
3
La Identificación de Stakeholders en la Ingeniería de Requisitos
Establecimiento de
los roles de los
3
X
X
3
3
X
3
stakeholders.
Análisis
de
los
requisitos.
3
X
X
X
3
X
3
3
X
3
X
3
X
3
3
X
X
X
3
X
3
3
X
Establecimiento
del
alcance
del
proyecto.
Análisis
de
las
características del
stakeholder.
Provee una guía de
los stakeholders.
Validación.
3
X
X
X
3
3
3
3
X
3
X
3
√ Indica que el método cumple con el criterio de comparación, X indica que el método no cumple el criterio de comparación.
Tabla1. Cuadro comparativo de los diferentes métodos para la identificación de stakeholders.
Del análisis llevado a cabo en el apartado anterior se puede llegar a la conclusión de que
ninguna de las aproximaciones consideradas cubre al 100% los criterios definidos en este
trabajo. Algunos métodos carecen de validación; otros no cubren aspectos técnicos,
sociales, organizacionales y humanos que implica la identificación de stakeholders; o bien,
sólo proporcionan una guía para la identificación pero no establecen los roles que los
stakeholders deben desempeñar en un proyecto determinado; por lo que se puede decir que
la mayoría de estas aproximaciones sólo se limitan a proporcionar una clasificación muy
general de quiénes pueden ser los stakeholders.
Independientemente del método que se utilice, debe hacerse énfasis en la necesidad de
obtener la confianza de los stakeholders para así lograr un compromiso con el proyecto. En
un proceso de identificación no solo deben tomarse en cuenta las habilidades profesionales
y la fiabilidad de la persona propuesta para ser stakeholder, sino también la destreza que
posee para comunicarse, su carácter y demás atributos importantes para el intercambio de
ideas ya que un proyecto software requiere de un intenso intercambio de información que
en muchas ocasiones se desarrolla bajo condiciones de incertidumbre. El director de
La Identificación de Stakeholders en la Ingeniería de Requisitos
proyecto debe ser capaz de legitimar las acciones de los stakeholders que pueden afectar los
resultados del proyecto o que se vean afectados por dichos resultados. Así mismo deberá
identificar los plazos para que se lleven a cabo los requisitos propuestos por cada
stakeholder y agruparlos según sea el caso: a corto, a mediano y a largo plazo.
Como se pudo apreciar, todos los métodos existentes cubren el proceso de identificación de
forma parcial por lo que sería interesante desarrollar como trabajo futuro la validación de
los métodos en un ambiente controlado o bien, proponer un método que cubra las
deficiencias que cada uno de ellos presentó.