Gestión de proyectos de software

Gestión de los requisitos de un proyecto software

RESUMEN

En la actualidad persisten problemas en el desarrollo de software, entre ellos, un inadecuado entendimiento de las necesidades de los usuarios, incapacidad de absorber cambios en los requisitos e insatisfacciones de los clientes por inaceptable o bajo desempeño del software. Las principales causas son la administración insuficiente de requisitos; los problemas que afectan la comunicación; las inconsistencias no detectadas entre requisitos, diseño y programación; las validaciones tardías de requisitos; el enfrentamiento reactivo de riesgos y la propagación de cambios sin control.

Los modelos de proceso de Ingeniería de Requisitos (IR), a pesar de su evolución, aún presentan carencias. Por tanto, para obtener un producto de calidad, se requiere una mejora en los procesos de IR. El objetivo del trabajo es proporcionar un procedimiento para efectuar la gestión de los requisitos de un proyecto de software basado en la integración de las mejores prácticas, con un enfoque holístico, proactivo y estratégico que potencie de manera efectiva el desempeño del proceso de gestión de desarrollo del proyecto de software y la satisfacción del cliente.

Palabras claves: requisitos, gestión del cambio, gestión de requisitos.

INTRODUCCIÓN

A pesar de la creciente participación del software en el mundo actual y de los avances producidos, su proceso aun no es adecuado.

El desarrollo de software aun no responde a las exigencias de estos tiempos. Las necesidades y expectativas de los clientes y usuarios no son captadas satisfactoriamente. De ahí que gran cantidad de proyectos de software que no llegan a cumplir sus objetivos, y como consecuencia de esto, los altos por cientos de rechazo entre ellos. Es otra problemática importante la incapacidad de absorber cambios en esos requisitos.

Las principales causas de estos problemas son la administración insuficiente de requisitos, comunicación ambigua e imprecisa, inconsistencias no detectadas entre requerimientos, diseño y programación, validaciones tardías de los requisitos, enfrentamiento tardío de riesgos y propagación de cambios sin control [Minasi, 2000], [García, 2000]. En este sentido, es necesario recordar que los errores más comunes y más costosos de reparar, así como los que más tiempo consumen, se deben a una inadecuada Ingeniería de Requisitos (IR). Actividades propias de esta área, como la especificación de requisitos o la gestión de requisitos del usuario, son algunas de las consideradas más críticas en el desarrollo y la producción del software.

La relación no lineal entre la ingeniería de requisitos y el resto del ciclo de vida del desarrollo del software ha sido detectada desde antaño y propuestas metodológicas como el Modelo en Espiral [Boehm, 1988] y el Proceso Unificado de Racional [Jacobson, et al., 1998], incorporan estrategias iterativas dentro de sus procesos de desarrollo para facilitar la ejecución de actividades propias de la ingeniería de requisitos, una vez iniciado el resto del proceso de desarrollo, al detectarse en éste la necesidad de renegociar algunos requisitos de difícil implementación o porque aparecen nuevos requisitos durante el proceso de desarrollo, entre otros. Debe tenerse en cuenta que la IR continúa durante todo el proceso de desarrollo [Sawyer y Kontoya 1999].

En [DoD, 1994] se ofrece una definición muy precisa de requisito, se dice que es la característica del sistema que es una condición para su aceptación por el cliente.

Si partimos de la definición anterior, entonces será necesario no sólo descubrir y especificar correcta y claramente los requisitos, sino que, además, será necesario seguirlos a lo largo de todo el ciclo de vida del proyecto, hasta su implementación, y mantener un control adecuado de los cambios. Así la gestión de los requisitos puede contribuir a reducir el tiempo del proyecto y disminuir los recursos implicados, facilitando la reutilización de requisitos y la implicación del usuario final en todo el proceso.

Otro aspecto importante a considerar es la línea base de requisitos, estructura dinámica que se genera durante el proceso de ingeniería de requisitos que evoluciona junto al proceso de desarrollo de software y que acompaña las tareas de mantenimiento.

Es importante enfatizar la importancia de la capacidad de referencias cruzadas entre la línea base de requisitos y el proceso de desarrollo y mantenimiento. Esto permite el seguimiento de los requisitos en cualquier punto durante el desarrollo y el mantenimiento hacia su punto de origen [García, 1999].

Para lograr producir aquello que el cliente requiere, en el plazo solicitado y ajustados al presupuesto asignado, se necesita desarrollar un proceso que incluya desde la etapa más temprana la gestión de los requisitos acordados, de forma que se garantice la satisfacción del cliente.

DESARROLLO

Los principios para realizar la gestión de los requisitos del software son:

• El acuerdo de los requisitos es el puente entre el desarrollo de requisitos y la gestión de requisitos.
• La gestión de requisitos incluye todas las actividades para mantener la integridad, exactitud y difusión de los acuerdos de los requisitos durante la vida del proyecto.

Los requisitos cambian y esto persiste a lo largo de la vida del sistema. Los cambios ocurren por:

• Cambios tecnológicos;
• Cambios en las estrategias o prioridades del negocio;
• Modificaciones en leyes y/o regulaciones;
• Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas;
• Porque cambió el problema que se estaba resolviendo;
• Porque los usuarios cambiaron su forma de pensar o sus percepciones;
• Porque cambió el ambiente de negocios;
• Porque cambió el mercado en el cual se desenvuelve el negocio.

Procedimiento de gestión de cambios en los requisitos

Desde el inicio hay que establecer la conformación de la línea base de requisitos, como un canal simple para el control de cambios, que se podrá usar para "capturar" nuevos cambios.
Línea base de requisitos
Es el conjunto de requisitos funcionales y no-funcionales que el equipo del proyecto se ha comprometido a implementar en una release específica. Es una versión aprobada de la especificación de requisitos del software.
Los requisitos antes de entrar en la Línea Base deben ser sometidos a un procedimiento de revisión formal (con su aprobación para ser incluido en la línea base). Una vez entrado el requisito en la línea base cualquier cambio debe someterse al procedimiento de control de cambios.
Es adecuado que el documento de requisitos que se esté elaborando previo a entrar en la línea base esté sometido a un procedimiento de control de versión (para distinguir versiones borradores de versión aprobada).
Canal y control de cambios
En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos.
La identificación del cambio se inicia desde el análisis de requisitos, nuevas necesidades del cliente, problemas operacionales; después se realiza el análisis del cambio y evaluación de costos, debiendo quedar claro cuántos requisitos se verán afectados y cuánto costará (tiempo y recursos); sólo después se toma la decisión de la implementación del cambio, que será documentado al ser realizado. 

 

Proceso de control de cambio:

 

Buenas prácticas de la actividad de gestión de requisitos.

• Definir un proceso de control de cambios.
• Establecer un grupo (o comité) de control de cambios.
• Realizar análisis del impacto sobre los cambios.
• Crear líneas base y controlar las versiones de los requisitos.
• Mantener la historia de los cambios.
• Seguir el estado de los requisitos.
• Medir la volatilidad de los requisitos.
• Usar herramientas de gestión de requisitos.
• Crear matrices de trazabilidad de los requisitos.

El proyecto puede responder frente a petición de nuevos requisitos o petición de cambios en los requisitos de diferentes maneras:

• Diferir los requisitos de baja prioridad.
• Obtener recursos adicionales.
• Ordenar realizar más horas de trabajo (preferiblemente durante un periodo corto de tiempo y pagado).
• Retrasar el calendario para acomodarse a la nueva funcionalidad.
• Permitir reducir el nivel de calidad bajo la presión de mantener la fecha original (frecuentemente esta es la reacción por defecto).

Ninguna aproximación es universalmente correcta porque cada uno de los proyectos es diferente (características, presupuesto, calendario, recursos y calidad).
Independientemente a cómo se responda a los cambios de los requisitos, lo que realmente importa es ajustar las expectativas y los compromisos cuando sea necesario.
Las gestión de requisitos tiene como salidas los cambios aprobados y no aprobados, informes acerca del estado del proceso, de actividades o requisitos, resultados de análisis de matrices y otros.

CONCLUSIONES

El procedimiento propuesto en este artículo está diseñado para ser desarrollado durante todo el ciclo de vida del proyecto software y permite gestionar la obtención incremental de los requisitos y los inevitables cambios a los que están sujetos desde la fase de IR y en el resto del ciclo de vida del proyecto
También se establecen mecanismos que garantizan la trazabilidad de los requisitos a lo largo de todo el ciclo de vida, hacia atrás, hacia delante y entre ellos.
Esto permite proveer una relación entre requisitos, diseño e implementación del sistema y el reconocimiento temprano de aquellos que no son satisfechos.
Constituye un instrumento estratégico con enfoque proactivo, que permite al gestor del proyecto adoptar, desarrollar e implementar adecuadamente las actividades de gestión de los requisitos de una forma disciplinada, coherente y repetitiva.
Una eficiente gestión de requisitos a lo largo de todo el ciclo de vida del proyecto contribuye eficazmente a la calidad del producto final y al grado de satisfacción del cliente.

Diagrama de flujo de datos

INTRODUCCIÓN.

En esta clase se explicó el diagrama de fuljo de datos que se lo realiza para tener una comunicación entre el usuario y programador para que el usuario sepa de qué forma fluyen sus datos.

MARCO TEÓRICO

DIAGRAMA DE FLUJO DE DATOS

La metodología del flujo de datos para determinar los requerimientos humanos. “Los diagramas de flujo de datos (DFD) describen de forma general las entradas, los procesos y las salidas del sistema.”

Se lo puede definir como una técnica de análisis estructurado, donde el analista de sistemas puede ensamblar una representación gráfica de los procesos de datos a través de la organización. Al usar combinaciones de sólo cuatro símbolos, el analista puede crear una descripción ilustrada de los procesos con el fin de elaborar una documentación sólida para el sistema.

Ventajas de la metodología del flujo de datos

1. No hay que comprometerse demasiado pronto con la implementación técnica del sistema.

2. Permite comprender con más detalle la capacidad de interrelación de los sistemas y subsistemas.

3. Se puede comunicar el conocimiento del sistema actual a los usuarios por medio de diagramas de flujo de datos.

4. Se puede analizar un sistema propuesto para determinar si se han definido los datos y procesos necesarios.

CONVENCIONES USADAS EN LOS DFD

4 SÍMBOLOS BÁSICOS para graficar el movimiento de los datos en el diagrama:

Un cuadrado doble, una flecha, un rectángulo con esquinas redondas y un rectángulo con un extremo abierto (cerrado del lado izquierdo y abierto del lado derecho).

ENTIDAD.

 Describe una entidad externa (una empresa, una persona o una máquina) que pueda enviar/recibir datos hacia/desde el sistema.

 Cada entidad se identifica con un nombre apropiado. Aunque interactúa con el sistema, se considera fuera de los límites de éste.

 Se debe denominar a las entidades con un sustantivo. Se puede utilizar la misma entidad más de una vez en un diagrama de flujo de datos para evitar cruzar las líneas de flujo de datos.

FLUJO DE DATOS.

 La flecha muestra el movimiento de los datos de un punto a otro;

 La cabeza de la flecha apunta hacia el destino de los datos.

 Los flujos de datos que ocurren al mismo tiempo se pueden describir mediante el uso de flechas paralelas.

 Como una flecha representa datos sobre una persona, lugar o cosa, también se debe describir con un sustantivo.

PROCESO.

 Se utiliza un rectángulo con esquinas redondas para mostrar la ocurrencia de un proceso de transformación.

 Siempre expresan un cambio o transformación en los datos; por ende, el flujo de datos que sale de un proceso siempre se identifica de manera distinta al flujo que entra al proceso.

 Representan el trabajo que se realiza en el sistema y se deben denominar mediante el uso de uno de los siguientes formatos.

 Debe recibir un número de identificación único que indique su nivel en el diagrama.

ALMACEN DE DATO.

 El rectángulo se dibuja con dos líneas paralelas que se cierran mediante una línea corta del lado izquierdo y cuyo extremo derecho está abierto.

 En los DFD lógicos no se especifica el tipo de almacenamiento físico (permite examinar, agregar y recuperar los datos).

 Puede representar un almacén manual como un archivero o una base de datos computarizada.

 Como los almacenes de datos representan a una persona, lugar o cosa, se denominan con un sustantivo.

 Los almacenes de datos temporales, como el papel de borrador o un archivo temporal de computadora, no se incluyen en el diagrama de flujo de datos.

 Hay que dar a cada almacén de datos un número de referencia único, como D1, D2, D3, por ejemplo.

PROCEDIMIENTO QUE REALIZA EL ANALISTA

 Se utiliza una metodología arriba-abajo para dibujar primero un diagrama de flujo de datos a nivel de contexto del sistema con una vista más amplia.

o Se dibuja un diagrama de flujo de datos lógico de nivel 0.

o Se muestran los procesos y se agregan los almacenes de datos.

 Se crea un diagrama hijo para cada uno de los procesos en el Diagrama 0.

o Las entradas y salidas permanecen constantes, pero los almacenes de datos y los orígenes cambian. Al expandir el diagrama de flujo de datos original, el analista de sistemas se puede concentrar en descripciones más detalladas del movimiento de datos en el sistema.

 Se desarrolla un diagrama de flujo de datos físico a partir del diagrama de flujo de datos lógico y se particiona para facilitar la programación.

o Se analiza cada proceso para determinar si debe ser manual o automatizado.

DIAGRAMA DE CONTEXTO

• El diagrama de contexto es el nivel más alto en un diagrama de flujo de datos y contiene sólo un proceso, el cual representa a todo el sistema.

• El proceso recibe el número cero.

• El diagrama no contiene almacenes de datos y es bastante simple de crear una vez que los analistas conocen las entidades externas y el flujo de datos que entra y sale de ellas.

DIBUJO DEL DIAGRAMA 0

El Diagrama 0 es la expansión del diagrama de contexto; puede incluir hasta nueve procesos.

Los diagramas de contexto (superior) se pueden “expandir” en un Diagrama 0 (inferior).

CREACIÓN DE DIAGRAMAS HIJOS (Niveles más detallados).

La regla principal para crear diagramas hijos es el balanceo vertical; establece que no puede producir salida o recibir entrada que el proceso padre no produzca o reciba también.

Todos los datos entrantes o salientes del proceso padre deben mostrarse como entrantes o salientes en el diagrama hijo.

Se enumeran mediante el uso del número del proceso padre, un punto decimal y un número único para cada proceso hijo.

El flujo de datos que concuerda con el flujo padre se denomina flujo de datos de interfaz y se muestra como una flecha que entra o sale de un área en blanco del diagrama hijo.

Los procesos se pueden o no expandir, dependiendo de su nivel de complejidad. Cuando un proceso no se expande, se dice que es funcionalmente primitivo y se le denomina proceso primitivo.

COMPROBACIÓN DE ERRORES EN LOS DIAGRAMAS

1. Olvidar incluir un flujo de datos o apuntar una flecha en dirección equivocada.

2. Conectar almacenes de datos y entidades externas directamente entre sí. No se pueden conectar los almacenes de datos y las entidades entre sí; se deben conectar sólo mediante un proceso. Las entidades externas no trabajan directamente con archivos.

3. Etiquetar de manera incorrecta los procesos o el flujo de datos. Cada flujo de datos se debe describir con un sustantivo.

4. Incluir más de nueve procesos en un diagrama de flujo de datos. Al tener muchos procesos se produce un diagrama sobrecargado de información que crea confusión. Si hay más de nueve procesos, conviene agrupar algunos para formar un subsistema y colocarlos en un diagrama hijo.

5. Omitir el flujo de datos. Buscar un flujo de datos en el que cada proceso sólo tiene una entrada y una salida. El flujo de datos lineal ocurre raras veces. Por lo general su presencia indica que faltan flujos de datos en el diagrama.

6. Crear una expansión desbalanceada en los diagramas hijos. Cada diagrama hijo debe tener el mismo flujo de datos de entrada y salida que el proceso padre. La excepción a esta regla es la salida menor, como las líneas de error que se incluyen sólo en el diagrama hijo.

ERRORES COMUNES QUE PUEDEN OCURRIR EN UN DIAGRAMA DE FLUJO DE DATOS

(EJEMPLO DE NÓMINA).

EL DIAGRAMA DE FLUJO DE DATOS CORRECTO.

(EJEMPLO DE NÓMINA).

CONCLUSIÓN.

Es importante realizar este diagrama de flujo de dato ya q este diagrama dará entendimiento al usuaria de su software ya que en él se describen todo sus procesos y entidades que contendrás y sabrá como se van a estar movilizando los datos o ver como fluye la información.