Inicio >> Artículos Científicos >> Propuesta de un procedimiento para el flujo de trabajo de requisitos en un proyecto de software

Main Menu

Contenidos

Material Secundaria

webs amigas

  • Webs Científicas
    • Cienciateca
      Web dedicada a la divulgacón científica en todas sus vertientes. Artículos de opinión, textos científicos, historias de la ciencia. Su zona de artículos de divulgación es genial.
    • Casanchi
      Web con contenidos científicos en español. Trata temas de forma general con apartados que dividen distintas categorías científicas. Muy interesante y didáctica.
    • J.Ramón Casanova
      Web sobre temas científicos variados. Muy amena, entretenida y actualizada. Monforte de Lemos debe ser un lugar maravillos para vivir.
Propuesta de un procedimiento para el flujo de trabajo de requisitos en un proyecto de software Imprimir Correo electrónico
Escrito por Naryana Linares   
Martes 14 de Octubre de 2008 03:00

UCI.jpgEl 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 ámb ito 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. 

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, no rma, 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 c umplir 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:
 

 

Información sobre involucrados en la captura de requisitos.

Especialista

Nombre(s) y Apellidos:

Especialidad:

 

Cargo que ocupa:

 

 

 

 

 

 

Experiencia

Bajo

Medio

Alto

Experiencia Laboral

 

 

 

 

Desarrollo de Software

 

 

 

Analista a cargo.

Nombre (s) y Apellidos:

Especialidad:

 

Cargo que ocupa:

 

Objetivo del encuentro (Captura, Definición, Validación de los requisitos):

 

Medio

Experiencia

Bajo

Alto

Experiencia Laboral

 

 

 

 

Desarrollo de Software

 

 

 

 

 

 

 

Requisitos levantados

Fecha: dd/mm/aa

 

Lista de Requisitos.

Criticidad

Proceso

Trazabilidad (Estado actual)

 

 

 

 





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 conteni do 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.  (Ra tional 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.

 

fig2.jpg

 

  Figura 2. Flujo de trabajo del procedimiento para la gestión de requisitos.

Con el objetivo de obtener una especificación de los requerimientos lo m&aacu te;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:

  •      &ique st;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.

 

fig3.jpg

 

Figura 3. Proceso de trazabilidad de requisitos.

 

fig4.jpg

  Figura 4. Elementos de seguimiento a los requisitos.

 

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.

 

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.
  • So mmerville, Ian. 2005. Ingeniería de Software. Madrid : PEARSON EDUCACIÓN, S.A., 2005

 

Autoras: Naryana Linares Pons (Departamento de Ingeniería y Gestión de Software,  Ciudad de  La Habana, Cuba.) y Yaima García García (Departamento de Programación, Ciudad de  La Habana, Cuba.)

 

Última actualización el Jueves 04 de Diciembre de 2008 14:20