La Identificación de Stakeholders en la Ingeniería de Requisitos

Transcripción

1 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. S I N T E S I S 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

2 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 (CMMi SM ), 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

3 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.

4 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. Teoría del Aproximación a Red de Platilla MEWSIC Principios Banco Criterios Saliente la Identificación stakeholders de Volere de la Ciencia de Mundial Sistemas Soluciona identificación stakeholders. la de

5 Establecimiento de los roles de los stakeholders. Análisis de los requisitos. Establecimiento del alcance del proyecto. Análisis de las características del stakeholder. Provee una guía de los stakeholders. X X X X X X X X X X X X X X X X X Validación. X X X 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

6 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ó.