Administración de requerimientos de software



Principios de la administración de requerimientos

Definir una base de requerimientos proporciona a los futuros usuarios un entendimiento compartido de las capacidades y propiedades que pueden esperar en la entrega. Desde una perspectiva práctica, los requerimientos deben ser distinguidos de otros que hayan sido propuestos pero no aceptados. El documento de SRS debe contener solo los requerimientos que están planeados para una entrega específica.

Atributos de los requerimientos

De acuerdo con Wiegers (2003) cada requerimiento funcional debe contener varias partes de información de apoyo o atributos asociados. Estos atributos establecerán un contexto para cada requerimiento que se ajusta bien, incluso va más allá de la descripción de la funcionalidad deseada.
Un buen conjunto de atributos es de gran importancia, especialmente en proyectos grandes y complejos. Para cada requerimiento hay que considerar las siguientes especificaciones de atributos:
  • Registrar la fecha en que el requerimiento se creó
  • Registrar el número de versión actual
  • Registrar quién es el autor del requerimiento 
  • Registrar quién es el responsable de asegurar que el requerimiento se cumpla
  • Registrar el propietario de un requerimiento o una lista de futuros usuarios para tomar decisiones sobre posibles cambios
  • Registrar el estatus del requerimiento 
  • Registrar el origen o fuente del requerimiento 
  • Registrar la lógica detrás del requerimiento 
  • Registrar los subsistemas del requerimiento
  • Registrar el número de entrega del producto
  • Registrar el método de verificación o criterios de pruebas de aceptación
  • Registrar la prioridad de implementación
  • Registrar la estabilidad (un indicador de que tan probable es que el requerimiento cambie a lo largo del tiempo)


Hay que seleccionar el conjunto de atributos que nos ayuden a administrar el proyecto de manera efectiva.


Proceso de administración del cambio

Wiegers (2003) mencionó que la mayoría de los desarrollados han experimentado el caso en el que un cambio, aparentemente simple, se torna mucho más complicado de lo esperado.
Los desarrolladores, por lo general, no son capaces de producir estimaciones realistas de los costos y otras ramificaciones de un cambio propuesto. Los cambios que no tienen un buen control pueden ser una causa de caos en el proyecto.
Una organización comprometida con la administración de proyectos de software debe asegurarse de: 
1. Evaluar cuidadosamente los cambios propuestos a los requerimientos, antes de ser incorporados.
2. Determinar quiénes son las personas adecuadas para tomar decisiones sobre los cambios solicitados.
3. Comunicar los cambios aceptados a todos los participantes afectados.
4. Incorporara de manera consistente los cambios de los requerimientos.

Matríz de rastreo de requerimientos 

Una herramienta fundamental para la administración de requerimientos es la matriz de rastreo de requerimientos, la cual consiste en una tabla que liga cada requerimiento funcional con los elementos de diseño y de código que lo implementan, así como las pruebas que lo verifican.
La matriz de rastreo de requerimientos también puede conectar los requerimientos funcionales con los requerimientos de alto nivel de los que fueron derivados. La idea es poblar esta matriz durante el desarrollo y no hasta el final del proyecto.

Enlaces en la cadena de requerimientos

El rastreo de requerimientos documenta las dependencias y las relaciones lógicas entre los requerimientos individuales y otros elementos del sistema, Estos elementos incluyen otros requerimientos de varios tipos: regla de negocios, arquitectura y componentes de diseño, módulos de código fuente, casos de pruebas y archivos de ayuda.

Modelado de casos de uso

Un caso de uso describe una secuencia de interacciones entre un sistema y una entidad externa.
Los casos de uso surgieron del mundo de desarrollo orientado a objetos. Sin embargo, los proyectos que siguen un enfoque de desarrollo pueden usarlo porque al usuario no le interesa cómo está construido el software.
Los casos de uso están  en el centro del ampliamente usado Proceso de Desarrollo de Software Unificado.

Diagramas de clase

De acuerdo con Eriksson y Penker (1997) los diagramas de clase son los más comunes en el modelado de sistemas orientados a objetos, un diagrama de clase muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones entre ellos.
Los diagramas de clase se usan en el diseño del modelo elástico para ver un sistema. Para las demás partes, este modelado involucra el vocabulario del sistema, el modelado de colaboraciones y el modelado de esquemas.
Los diagramas de clase son importantes no sólo para la visualización, especificación y documentación del modelo estructural, sino también par a la construcción de sistemas ejecutables.

Otros diagramas UML

Diagrama de caso de uso. Un diagrama de casos de uso contiene elementos de modelo para el sistema, los actores y los casos de uso; muestra las diferentes relaciones, tales como: generalización, asociación y dependencia entre estos elementos. Los elementos de un diagrama de casos de uso son:

- Sistema. Un sistema en un diagrama es descrito como una caja; el nombre del sistema aparece arriba o dentro de la caja.
- Actor. Es alguien o algo que interactuar con el sistema, en otras palabras, es quien utiliza el sistema.
- Casos de uso. Representan la funcionalidad completa, tal y como la percibe un actor.

Diagrama de Secuencia. Este diagrama muestra la interacción de los objetos entre ellos (es importante comentar que hasta este momento no se han considerado objetos técnicos).

Diagrama de Colaboración. Este diagrama muestra interacciones, pero se centra en el espacio. Puede ser utilizado para ilustrar la ejecución de una operación, una ejecución de un caso de uso o simplemente un escenario de interacción dentro del sistema.

Diagrama de Estados. Este diagrama captura el ciclo de vida de los objetos, sistemas y subsistimos. Dicho diagrama determina los estados que un objeto puede tener y cómo los eventos afectan esos estados, a través del tiempo.

Diagrama de Componentes. Este diagrama describe los componentes del software, y sus dependencias con otros componentes, representando la estructura del código. Los componentes del software pueden ser: componentes de código, componentes binarios, componentes ejecutables.

Diagrama de despliegue. Contiene los nodos y las conexiones que muestran la arquitectura del sistema: tiempo de ejecución a través de procesadores, dispositivos y componentes del software. Esta es la última descripción física de la topología del sistema, describiendo la estructura de las unidades de hardware y software que se ejecutan en cada unidad.



Referencias

Wiegers, K. (2003). Software requirements
Eriksson, H. Y Penker, M. (1997). UML Toolkit


Comentarios

Publicar un comentario

Entradas populares de este blog

U3 - 5. Estrategia y técnicas de negociación integrativa

Imagen
Estrategia y técnicas de negociación integrativa Designed by Freepik   Comprometerse con los intereses de la otra parte y con los propios hace que la resolución de problemas sea la estrategia preferible. En muchas negociaciones no es necesario que haya ganadores y perdedores, pues todas las partes pueden ganar. En una negociación integradora las metas de las partes no son excluyentes. Si una parte consigue sus metas, no evita que la otra parte alcance las suyas. Las ganancias de una parte no es a expensas de la otra. Para que una negociación se considere integradora, los negociadores deben: Concentrarse en las afinidades, no en las diferencias. Intentar abordar las necesidades y los intereses, no las posiciones. Comprometerse a satisfacer las necesidades de todas las partes. Intercambiar información e ideas. Crear opciones para una ganancia mutua. Emplear criterios objetivos para los estándares de desempeño. Panorama del proceso de negociació...
Leer más

U3 - Ensayo de la negociación

Introducción El diario vivir de cada persona se encuentra repleto de decisiones que deben ser tomadas en torno a un conjunto de intereses propios. La gran mayoría de estas decisiones suelen ser tan pequeñas e irrelevantes que llegan a pasar desapercibidas, pero hay muchas otras que sí deben ser analizadas con mayor detenimiento. El reto surge cuando nuestros intereses se ven ligados a los de alguien más, de modo que las decisiones no pueden ser tomadas sin la intervención de una segunda parte, generando de esta manera un conflicto. Hablamos de la existencia de un conflicto, cuando dos o más personas tienen diferentes percepciones acerca de un tema determinado, y se necesitan mutuamente para solucionarlo. Surge de esta manera un proceso llamado negociación, que puede ser definido, citando a Pruitt y Carnevale (1193) , como una " discusión entre dos o más partes que desean resolver intereses incompatibles". Por lo tanto, la negociación es una actividad habitual en el ser h...
Leer más

U3 -2. Estilos alternativos, estrategias y técnicas de negociación

Etapas de la negociación Es indispensable ver el proceso en 5 etapas: preparación, introducción, iniciación, intensificación y cierre. Sin embargo, no debe esperar que el proceso siempre se dé en cinco etapas distintas, ya que normalmente las etapas se traslapan. Cuanto mas compleja sea el asunto de la negociación, más lo será el proceso. Etapa Introductoria Uno de los primeros pasos en la interacción es establecer el tono de la negociación, refiriéndonos a una atmósfera competitiva o cooperativa. En esta etapa se pretende hacer contacto personal, establecer la confianza y el tono. Debe transmitirse una actitud cálida y cooperativa, tratando a la otra persona con dignidad y respeto. El comportamiento y el lenguaje corporal son pistas sobre la actitud de una persona hacia la negociación. Si ambas partes intentan establecer el mismo tono, comenzarán a progresar. Si una de las partes adopta un tono competitivo mientras que la otra busca uno cooperativo, el primer tema a neg...
Leer más