Monografias.com > Sin categoría
Descargar Imprimir Comentar Ver trabajos relacionados

Gestión de los requisitos de un proyecto software (página 2)



Partes: 1, 2

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.

Los cambios deben controlarse y documentarse. Hay que
convivir con el cambio. Por lo
tanto, es esencial planear posibles cambios a los requerimientos
cuando el sistema sea desarrollado y utilizado. Por tanto la
gestión
de los requisitos del software, de su evolución es un proceso
externo que ocurre a lo largo del ciclo de vida
del proyecto.

La Gestión de Requisitos es el conjunto de
actividades que ayudan al equipo de trabajo a
identificar, controlar y seguir los requisitos y sus cambios en
cualquier momento. O sea, básicamente, consiste en
gestionar los cambios a los requisitos acordados, las relaciones
entre ellos, las dependencias entre la Especificación de
Requisitos del Software (ERS) y otros documentos
producidos por el proceso de desarrollo de
software. Esta actividad asegura la consistencia entre los
requisitos y el sistema construido (o en construcción). Consume grandes cantidades
de tiempo y
esfuerzo. Abarca todo el ciclo de vida del producto. Es
una actividad necesaria porque:

  • Los requisitos son volátiles:
  • Mutantes o cambiantes: sufren ligeras
    variaciones.
  • Emergentes: surgen al ir analizando el sistema en
    profundidad.
  • Colaterales: surgen como efecto de la
    inclusión de otros requisitos.
  • Por compatibilidad: se añaden para adaptar
    el sistema a su entorno, debido a que el entorno
    físico cambia, o sea, trasladar un sistema de un
    entorno a otro siempre requiere modificaciones. El entorno
    organizacional también cambia, las políticas cambian, se producen cambios
    en las reglas y en los procesos
    del negocio, provocando cambios en el sistema.
  • La propia existencia del sistema va a generar nuevos
    requisitos por parte de los usuarios.

La gestión de requisitos
implica:

  • Definir procedimientos
    que establezcan los pasos y los análisis que se realizarán antes
    de aceptar los cambios propuestos.
  • Cambiar los atributos de los requisitos
    afectados.
  • Mantener la trazabilidad hacia atrás, hacia
    delante y entre requisitos.
  • Controlar las versiones del documento de
    requisitos.

Cambios a los requisitos involucra modificar el tiempo
en el que se va a implementar una característica en
particular, modificación que a la vez puede tener impacto
en otros requerimientos. Por esto, la gestión de cambios
involucra actividades como establecer políticas, guardar
históricos de cada requerimiento, identificar dependencias
entre ellos y mantener un control de
versiones.

Como ya se ha expuesto, es vital planificar los cambios,
de acuerdo a las prioridades que los clientes
determinen durante la identificación. Hay que aprobar los
mecanismos para la configuración del cambio y las
políticas de trazabilidad.

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. Obsérvense las figuras 1 y 2.

Figura 1 Canal de
cambios.

Figura 2 Proceso de control de
cambios.

La gestión de los cambios se realiza de acuerdo a
las prioridades, debiéndose identificar problemas y causas
por los que se produce el cambio; analizar el impacto y el
costo del cambio
y finalmente, tomada la decisión, ejecutar (proceder con)
el cambio.

Aspectos a considerar para la aprobación de un
cambio solicitado:

  • Impacto del cambio en el costo y funcionalidades del
    sistema.
  • Impacto para el cliente y stakeholders
    externos.
  • Desestabilización potencial del sistema que
    pudiera ocasionar un cambio.

Las solicitudes de cambios, desde el momento en que son
comunicadas hasta su implementación, transitan por
diferentes estados en el que intervienen los implicados asumiendo
diferentes roles. Obsérvense la figura 3 y la tabla
1.

Ejecución de los cambios

Aprobado el cambio se procede a su
implementación, de acuerdo a la fase del proyecto a que
corresponda. En caso de que los cambios aprobados:

  • impliquen el desarrollo de un nuevo sistema, entonces
    será necesario comenzar un nuevo proceso de
    IR.
  • impliquen la implementación de nuevos
    requisitos, entonces será necesario comenzar por la
    actividad de elicitación o educción de
    requisitos.
  • afecten otras fases del proceso de desarrollo del
    proyecto, entonces se implementan en esas.

Trazabilidad

Los requisitos deben ser "rastreables": por su origen
(¿quién lo propuso?); necesidad (¿por
qué existe?); por su relación con otros requisitos;
por su relación con elementos del diseño
y/o la implementación. Esta información es útil para saber
qué afecta un cambio en un requisito. Para resolver esta
necesidad se usan las matrices para
el seguimiento de los requisitos, entre ellas:

  • Matriz de seguimiento de características
    (definidas por el cliente).
  • Matriz de seguimiento de orígenes: identifica
    el origen de cada requisito.
  • Matriz de seguimiento de dependencias: indica
    cómo se relacionan los requisitos entre
    sí.
  • Matriz de seguimiento de subsistemas: vincula a los
    requisitos con los subsistemas (o módulos) que los
    manejan.
  • Matriz de seguimiento de interfases: muestra
    cómo los requisitos están vinculados a las
    interfases internas y externas del sistema.

Figura 3 Posibles estados de una
petición de cambio

Tabla 1 Posibles roles en el
procedimiento de control de cambios.

Rol

Descripción

Grupo de control de cambios (GCC)

Grupo de personas que deciden aprobar o rechazar
las peticiones de cambios para un proyecto
específico.

Promotor del cambio

Persona autorizada que solicita la
petición de cambio de requisitos.

Evaluador

Persona que analiza el impacto de la
petición de cambio (puedes ser técnico,
martketing, cliente o combinación).

Modificador

Persona que realiza el cambio como consecuencia
de una petición de cambio aprobada.

Verificador

Persona que determina si el cambio se ha
realizado correctamente.

Validador

Persona del cliente que valida la
implementación del cambio realizado.

En [Edwards, 1991] la trazabilidad está definida
como una técnica usada para "proveer una relación
entre requisitos, el diseño y la implementación
final del sistema". En [Palmer, 1997] se establece que "la
trazabilidad da asistencia esencial en el entendimiento de las
relaciones que existen entre y a través los requisitos, el
diseño y la implementación".

Estas relaciones permiten mostrar que el diseño
cumple con los requisitos funcionales y ayudan al reconocimiento
temprano de aquellos requisitos que no son satisfechos por el
diseño.

Control de versiones (evolución en el
tiempo de la ERS)

Habitualmente la ERS necesitará ser modificada a
medida que progresa el producto software, como resultado de los
cambios aprobados en requisitos individuales o grupos de ellos.
En la medida en que la especificación sea más
completa, como consecuencia de que sus requisitos fueron
especificados lo más completamente posible, menos
versiones de la ERS habrá que producir.

Entre algunos de los beneficios que proporciona el
control de versiones están:

  • Prevenir cambios no autorizados.
  • Guardar revisiones de los documentos de
    requerimientos.
  • Recuperar versiones previas de los
    documentos.
  • Administrar una estrategia de
    "releases".
  • Prevenir la modificación simultánea a
    los requisitos.

Tener versiones de los requerimientos es tan importante
como tener versiones del código,
ya que evita tener requerimientos emparchados en un
proyecto.ç

Para la trazabilidad y el control de versiones se
realiza la identificación y almacenamiento de
requisitos. Cada requisito y cada versión de ERS aprobada
tendrán un identificador único.

Cuando la Gestión de los Requisitos no se hace
bien, de inmediato aparecen síntomas:

  • Altos niveles de re-trabajo a lo largo del
    proyecto.
  • Los requisitos se aceptan por el personal desde
    cualquier fuente que consideren fidedigna.
  • Se incrementa de forma desmesurada las peticiones de
    requisitos.
  • Incapacidad para probar que el producto cumple los
    requisitos aprobados.

¿Por qué se debe tener cuidado?
Porque:

  • La falta de acuerdo entre los afectados sobre
    cuáles son los requisitos "reales" incrementa el tiempo
    y el costo del proyecto.
  • Hay altas probabilidades de entregar un producto
    incompleto o incorrecto.
  • Volver a revisar cambios en los requisitos, una y
    otra vez, es un derroche de recursos muy visibles para el
    cliente.

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.

REFERENCIAS BIBLIOGRÁFICAS

[Boehm, 1988]: Boehm, B.: "A Spiral Model of Software
Development and Enhancement". IEEE Computer. Vol. 21, # 5.
1988.

[DoD, 1994]: DoD. Military Standard 498: Software
Development and Documentation. Departament of Defense of the
United States of America, 1994.

[Durán, 2002]: Durán, A.,
Bernández, B.: "Metodología para la Elicitación de
Requisitos de Software", Universidad de
Sevilla. 2002.

[Edwards, 1991]: Edwards M., Howell S.: A methodology
for system requirements specification and traceability for large
real- time complex systems. Technical Report, Naval Surface
Warfare Center, 1991.

[García, 2000]: García Ávila,
Lourdes. Modelo para la
evaluación de la calidad del análisis y
diseño orientados a objetos de sistemas
informáticos (CADOOSI). Tesis de
doctorado. Universidad Central de Las Villas, 2000.

[Jacobson, et al., 1998]: Jacobson, I., Booch, G.,
Rumbaugh, J.: "The Unified Software Process". Adison- Wesley.
1998.

[Leffingwell y Widrig, 2003]: Leffingwell, Dean, Widrig,
Don. "Managing Software Requirements". Second Edition.
Addison-Wesley 2003.

[Minasi, 2000]: Minasi, Mark: The Software Conspiracy:
Why Sftware Companies Put Out Faulty Products, How They Can Hurt
You, and What You Can Do. McGraw-Hill, 2000.

[Palmer, 1997]: Palmer J. D.: Traceability in Software
Requirements Engineering, R.H. Thayer and M. Dorfman (Eds), IEEE
Computer Society Press, 1997. (364:374).

[Pressman, 2002]: Pressman, Roger S.: "Ingeniería de Software. Un enfoque
práctico." Quinta edición. McGraw-Hill. Madrid.
2002.

[Rational, 2001]: Rational Unified Process. Rational
Software Corporation. "Rational Unified Process". Version
2001A.04.00, Copyright 1987-2001.

[Sawyer y Kontoya, 1999]: Sawyer, P. y Kontoya, G.:
SWEBOK: "Software Requirements Engineering Knowledge Area
Description". Informe
Técnico Versión 0.5, SWEBOK Project, 1999.
Disponible en http://www.swebok.org.

[Sommerville, 2005]: Sommerville, Ian: "Software
Engineering". 7th. Edition. Addison-Wesley 2005.

[SWEBOK, 2004]: Guide to the Software Engineering Body
of Knowledge. IEEE Computer Society Order Number C2330, ISBN
0-7695-2330-7, Library of Congress Number 2005921729.
2004.

 

Ing. Leidy Fernández
Sánchez.

leidy[arroba]cfg.etecsa.cu

Empresa de Telecomunicaciones de Cuba S. A.
Cuba

Dra. Lourdes García
Ávila.

Dpto. Ing. Industrial.Universidad Central "Martha Abreu"
de Las Villas. Cuba

Partes: 1, 2
 Página anterior Volver al principio del trabajoPágina siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter