Monografias | Propuesta de un procedimiento para el flujo de trabajo de requisitos en un proyecto de software

Resumen

La industria de software se enfrenta actualmente a innumerables retos, altas demandas y clientes que se vuelven cada vez más exigentes con tiempos de entrega y calidad. Es por ello que en la mayoría de los proyectos las principales preocupaciones giran en torno a lograr un fuerte equipo de desarrolladores capaz de satisfacer las actuales presiones y de minimizar en buena medida soluciones que no cumplan con los principales parámetros de calidad establecidos. En el éxito final de un producto, la ingeniería de requisitos es una de las etapas más importantes. La especificación de requisitos es una actividad que en ocasiones se torna difícil para los analistas, debido en gran medida a la dificultad que presentan muchas personas de trasmitir lo que realmente desean y esperan del futuro sistema, ello, unido a los conflictos existentes como resultado de la comunicación y la experiencia acumulada de cada cual, hacen de este proceso, el evento más serio en la actividad productiva de software.
El establecimiento de un procedimiento para la gestión de requisitos, incidiendo de forma aguda en su trazabilidad, pudiera aliviar alguna de las actuales frustraciones que tienen la mayoría de los proyectos hoy y que les impiden culminar el ciclo de sus productos en la forma establecida y recomendada por la mayoría de las metodologías de desarrollo instituidas.
En el presente trabajo se pretende tratar las problemáticas planteadas, proponiendo un procedimiento que responde a las necesidades reales que presentan hoy los proyectos de desarrollo de software.

Introducción

El mundo es testigo de una gran revolución cognitiva donde en lugar de capital hoy se habla de conocimiento. Ordenadores más potentes y aplicaciones cada vez más robustas en cuanto a tiempo de procesamiento y respuestas a eventos de diferentes índoles, invaden día tras día el mercado, marcando cada vez más la competencia y señalando el camino a la excelencia.
El desarrollo de la industria del software continúa su avance, surgiendo cada día numerosos proyectos. Muchos de ellos se atrasan, tienen problemas con su calidad o lo que es peor, no llegan a su término, fracasando por diversas causas dentro de las que juega un papel fundamental una mala gestión de requisitos ya que, al ser uno de los primeros y fundamentales flujos de trabajo que se llevan a cabo a la hora de construir un software, los errores de comprensión cometidos en esta etapa inicial de los proyectos son los más costosos de resolver.
Un requisito de software dicho en otras palabras es una característica, condición funcional o capacidad, que debe tener un producto en aras de satisfacer las necesidades de un determinado cliente. En todo proyecto de desarrollo de software una de las primeras acciones a seguir es justamente identificar esas capacidades o características que debe conseguir aquello que se está desarrollando.
El flujo de trabajo de requerimientos se implementará precisamente con el objetivo de establecer y mantener un acuerdo entre clientes, representantes del equipo de desarrollo y otros involucrados sobre lo que el producto final deberá hacer y/o tener, a la vez que se define el ámbito del sistema y con él una interfaz, enfocada a las necesidades y metas de los futuros usuarios. Juega un papel fundamental, entonces, el procedimiento que se debe llevar a cabo para lograr una efectiva ingeniería de requisitos.

Desarrollo

La Ingeniería de Requerimientos trata de establecer lo que el sistema debe hacer, sus propiedades emergentes deseadas y esenciales, y las restricciones en el funcionamiento del sistema y los procesos de desarrollo del software. Por lo tanto puede considerar la ingeniería de requerimientos como el proceso de comunicación entre los clientes y usuarios del software y los desarrolladores del mismo. (Sommerville, 2005)
Son los requisitos los que describen las condiciones que deben cumplir o las capacidades que deben tener los productos entregables del proyecto para satisfacer un contrato, norma, especificación o cualquier otro documento formalmente impuesto. El análisis de los interesados que incluyen la totalidad de sus necesidades, deseos y expectativas se traducen en requisitos priorizados. (Project Management Institute, 2004)

El procedimiento que a continuación se propone seguir, en virtud de lograr los resultados esperados en este flujo de trabajo, consta de tres momentos fundamentales:
Captura de requisitos: Esta es la actividad en la que se identifica a los interesados (stakeholders) y se establecen las primeras relaciones entre ellos y el equipo de desarrollo. Se hace con el objetivo de conocer todo lo posible acerca del entorno en el cual el sistema será desarrollado, y utilizar esta información en las etapas posteriores. Termina con el levantamiento o la identificación de los principales requisitos que debe cumplir el futuro sistema.
Antes de mantener las reuniones con los clientes y usuarios e identificar los requisitos es fundamental conocer el dominio del problema y los contextos organizacional y operacional, es decir, la situación actual. Mantener reuniones con clientes y usuarios sin conocer las características de su actividad hará que probablemente no se entiendan sus necesidades y que su confianza inicial se vea deteriorada enormemente. Esta tarea es opcional, ya que puede que no sea necesario realizarla si se tiene experiencia en el dominio del problema y el sistema actual es conocido. (Durán Toro, y otros, 2002)
En esta etapa, además de definir quienes son las personas que participarán en el proceso de captura de requisitos, se debe recolectar información sobre ellos. Para este caso particular se ha diseñado la siguiente plantilla:



Definición de requisitos: Creación de modelos que ayuden a entender la entidad a construir, se utilizarán palabras sencillas en la descripción y se detallará la funcionalidad del mismo. Se debe ver la definición de requisitos como una prolongación del modelo de negocio, que permitirá concretar las funcionalidades de cada uno de los procesos identificados en la etapa anterior y acercarse en la medida de lo posible al idioma que utilizarán posteriormente en la implementación los desarrolladores. Es importante en esta etapa considerar la priorización de requisitos que ayudará a mantener una política de sobre-protección en aquellos que resulten arquitectónicamente significativos.
En este sentido es válido resaltar que los requisitos pueden ser agrupados de acuerdo a su funcionalidad en:
Requisitos Funcionales de Gestión: En ellos se concentrarán aquellos que describen los servicios (funciones) que se esperan del sistema y que tengan que ver con algún proceso propiamente de gestión (crear, modificar, eliminar, consultar, actualizar).
Requisitos Funcionales de Soporte: Estos requisitos se caracterizan por describir funcionalidades generales que el sistema debe tener habilitadas y que pueden ser usadas en cualquier momento, por ejemplo (imprimir un documento, vista previa, generación de plantillas, deshacer, salir de una opción determinada, entre otras).
Requisitos Funcionales de Negocio: En estos se ubicarán aquellos requisitos que no forman parte de ningún paquete específico y que responden a funcionalidades concretas de cada negocio.
Requisitos No Funcionales: Estos son restricciones sobre los requisitos funcionales, a diferencia de los anteriores, los no funcionales son cualidades que el sistema debe cumplir o características determinadas que el producto debe tener. A la hora de definirlos habrá que tener en cuenta atributos que respondan a la seguridad, funcionalidad, fiabilidad, usabilidad, consistencia, portabilidad, flexibilidad, mantenibilidad y eficiencia.
Validación de requisitos: Validar es evaluar el flujo y contenido de la información. La definición de las funciones del software, entender el comportamiento del software ante eventos, el establecimiento de las características de la interfaz y el descubrimiento de restricciones adicionales de diseño. Toda esta evaluación se sintetiza en la definición en detalle de los datos, funciones y el comportamiento del sistema.
- Construcción de un prototipo de alto nivel del sistema.
- Revisión por parte del usuario.
- Firma del contrato si las partes están de acuerdo.
Se proponen como roles implicados en este flujo de trabajo de Requisitos y como parte del procedimiento, los siguientes:
Especialista funcional: Será el cliente potencial del negocio que se modele y en consecuencia el responsable de comunicar las funcionalidades que pretende sean modeladas e implementadas en su producto.
Analista: Define el alcance del sistema e identifica los principales procesos que permiten modelar completa y consistentemente dicho sistema.
Arquitecto: Deberá ser responsable de describir la vista de la arquitectura definiendo la prioridad de cada requisito así como en qué iteración será desarrollado cada uno.
Desarrollador: Participará con el objetivo de obtener el esbozo inicial y conocer las necesidades de lo que posteriormente deberá implementar.
Los artefactos que como resultado serán generados al finalizar el flujo de trabajo en cuestión son:
Especificación de requisitos: En este documento se detallará el requisito como acción concreta, especificando el verbo que lo tipifica, el estado operacional y los conceptos tratados fundamentalmente.
Refinamiento de la arquitectura: En este documento se representan un poco más acabados los procesos más significativos para la arquitectura, aquellos que describen alguna funcionalidad importante y crítica o algún requisito que deba priorizarse.
Glosario de términos: El documento contendrá los términos comunes que se utilizan para describir el sistema, así como aquellos que a los usuarios o al grupo de desarrollo les pueda causar duda.
Seguimiento a los requisitos: El artefacto de Seguimiento a los Requisitos es mantenido durante todo el ciclo de vida del proyecto, tiene como propósito mantener información sobre los requisitos, sus atributos y dependencias para ser usados en la evaluación del impacto y gestión de los cambios. (Rational Software Corporation, 2003)
Prototipo de interfaz usuario: En este artefacto se presentará la interfaz del producto que representa la funcionalidad contenida en los procesos; de manera que permita que el usuario verifique que el sistema va a satisfacer sus necesidades y el modo en que gráficamente se propone lo haga.
En la figura 2 se muestra brevemente el procedimiento propuesto hasta el momento.



Con el objetivo de obtener una especificación de los requerimientos lo más precisa, completa y clara posible se proponen a continuación una serie de interrogantes que responden a determinados atributos que se deben tener en cuenta.
En el caso de evaluar precisión se deberá insistir en:
ü ¿Los requerimientos son verdaderamente estables? ¿No se contradicen los unos con los otros?
ü ¿Existe algún requerimiento que se encuentre en conflicto con algo que ya se ha declarado o restringido?
ü ¿Soportan los requerimientos los objetivos del negocio y del sistema de software?
ü ¿Se va del alcance del proyecto algún requerimiento o no es requerido?
Para la completitud se debe tener en cuenta:
ü ¿Están las metas y objetivos del sistema de software claros y completamente definidos?
ü ¿Se han manejado todos los eventos y condiciones?
ü ¿Han sido especificadas todas las operaciones?
ü ¿Han sido especificadas todas las definiciones y reglas requeridas?
ü ¿El equipo de diseño se siente satisfecho con el nivel de detalle de las especificaciones?
En cuanto a la claridad se debe observar que:
ü ¿Los requerimientos están libres de ser restringidos a una alternativa de diseño específica?
ü ¿Se encuentran redactados en forma coherente y utilizando un lenguaje sencillo cada uno de los requisitos?
ü ¿Han sido declarados en forma precisa y concisa todos los requerimientos?

Trazabilidad de requerimientos.

En el desarrollo exitoso de un proyecto inciden varias variables y en la buena gestión de requisitos una de las que más influencia tiene es la trazabilidad. La trazabilidad de requisitos es uno de los procesos que repercuten con mucha fuerza en la entrega a tiempo y el cumplimiento de los cronogramas establecidos para el desarrollo de software. Se define como el arte de describir y seguir la vida y el estado en todo momento de un requisito en los dos sentidos, es decir, lo mismo hacia el momento de su captura o definición que hacia la etapa de implementación. (Anaya)
Entre los objetivos fundamentales que se propone la trazabilidad en un proyecto está el hecho de entender en primer lugar el alcance del mismo, gestionar además los cambios que se lleven a cabo generalmente como consecuencia de nuevas funcionalidades que el cliente desea sean añadidos. Por otro lugar la trazabilidad permite determinar el impacto y la repercusión que provoca en materia de tiempo, costo y calidad, un cambio en el desarrollo que hasta el momento había sido concebido. También es válido resaltar que este proceso traceable posibilita determinar el grado de satisfacción de un requisito a través de las pruebas concebidas, tributando así a lograr una mayor calidad en el producto final, además que permite que todos los requisitos del sistema sean satisfechos mediante la implementación a la vez que verifica que la aplicación haga solo lo que debe hacer.

Existe una trazabilidad directa entre los requerimientos y los casos de uso del sistema, los casos de uso no son más que la representación gráfica de funcionalidades del sistema. Estos además, deben hacer referencia a al menos un requerimiento, es decir, cada requerimiento debe quedar representado en un caso de uso y cualquier modificación que exista en algún requerimiento pueda afectar al caso de uso correspondiente, de la misma forma, si un caso de uso es modificado, se debe revisar esa modificación y ver qué requerimiento pueda estar afectado también, todo este control se puede llevar gracias a la trazabilidad que existe entre ambos elementos.
En las figuras que se muestran a continuación aparecen representados los elementos fundamentales a tener en cuenta y el procedimiento propuesto para la trazabilidad de los requisitos en un proyecto de desarrollo.







Conclusiones

Establecer un procedimiento para la gestión de requisitos permitirá instituir en el proyecto una disciplina de trabajo a la vez que servirá de guía para conocer de las actividades y el orden de precedencia que deben tener las mismas, en función de lograr optimizar los tiempos de entrega y elevar la calidad del trabajo. Se concluye en que la propuesta realizada tributa a minimizar las actuales deficiencias que existen hoy en la mayoría de los proyectos y de las cuales no escapa la industria cubana de software.

Referencias Bibliograficas

Anaya, Víctor. SmarTTrace: Una Herramienta para Trazabilidad de Requisitos en Proyectos basados en UML. Workshop en Ingeniería de Requerimientos. [En línea] [Citado el: 29 de agosto de 2008.] http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER02/anaya.pdf.

Duran Toro, Amador y Bernárdez Jiménez, Beatriz. 2002. Metodología para la Elicitación de Requisitos de Sistemas Software Versión 2.3. España : Universidad de Sevilla, 2002.

Project Management Institute. 2004. Guía de los Fundamentos de la Dirección de Proyectos. s.l. : PMI Publications, 2004.

Rational Software Corporation. 2006. Rational Unified Process. 2006.

Sommerville, Ian. 2005. Ingeniería de Software. Madrid : PEARSON EDUCACIÓN, S.A., 2005.

Autoras

Nombre y Apellidos: Naryana Linares Pons.
Título universitario: Ingeniero en Ciencias Informáticas.
Grado científico: -
Categoría Docente: Instructor recién graduado.
Institución: Universidad de las Ciencias Informáticas.
Dirección postal: Carretera a San Antonio de los Baños, km 2 ½, Boyeros, Ciudad de La Habana, Cuba, Código Postal 19370.
Número de teléfono: 837-3183.
Correo electrónico: nlinares@uci.cu
Curriculum:
Profesora Adiestrada.
Graduado en el 2007 de Ingeniero en Ciencias Informáticas en la Universidad de Ciencias Informáticas (UCI), Título de Oro
Ha impartido asignaturas del departamento de Ingeniería y Gestión de Software.
Participó en el Foro Global sobre la Juventud y las Tecnologías de la Información y las comunicaciones (TIC´s) que se desarrolló en Ginebra en septiembre de 2007.
Participó como coautora en el evento UCIENCIA del curso 2007-2008, en el cual se presentó una investigación relacionada con su tema de tesis obteniendo la condición de destacado.
Posee tres publicaciones, en temas de factoría de software aplicando inteligencia, donde consta como coautora.
Se desempeñó como Líder del proyecto ERP en sus inicios y actualmente es analista del equipo principal del mismo.

Nombre y Apellidos: Yaima García García.
Título universitario: Ingeniero en Ciencias Informáticas.
Grado científico: -
Categoría Docente: Instructor recién graduado.
Institución: Universidad de las Ciencias Informáticas.
Dirección postal: Carretera a San Antonio de los Baños, km 2 ½, Boyeros, Ciudad de La Habana, Cuba, Código Postal 19370.
Número de teléfono: 837-8032.
Correo electrónico: ygarciaga@uci.cu
Curriculum:
Profesora Adiestrada.
Graduado en el 2007 de Ingeniero en Ciencias Informáticas en la Universidad de Ciencias Informáticas (UCI), Título de Oro.
Ha impartido asignaturas de los departamentos de Sistemas Digitales y Programación.
Se desempeña como Gestor de Configuración y Cambios en el proyecto con el Banco Nacional de Cuba.
Se desempeña como Jefa del Departamento de Programación de la Facultad 4.

Compartir