plan de administraciÓn de requerimientos … · web viewel fin último del procedimiento aquí...

PLAN DE ADMINISTRACIÓN DE REQUERIMIENTOS

Plan de Administración de Requerimientos QuickSoft

TABLA DE CONTENIDO

1. PLAN DE ADMINISTRACIÓN DE REQUERIMIENTOS

1.1 PROPÓSITO

1.2 ALCANCE

1.3 GENERALIDADES1.4 ¿QUÉ SIGNIFICA DEFINIR LOS REQUERIMIENTOS?1.5 ¿POR QUE ES IMPORTANTE?

2. PAUTAS PARA DEFINIR REQUERIMIENTOS

3. CARACTERÍSTICAS DE LOS REQUERIMIENTOS

4. DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS4.1 IMPORTANCIA DE LA INGENIERÍA DE REQUERIMIENTOS4.2 ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS

5. EL PROGRAMA DE ADMINISTRACIÓN DE REQUERIMIENTOS5.1 Análisis comparativo de las técnicas de Ingeniería de Requerimientos5.2 Identificación de Requerimientos5.3 Trazabilidad5.4 Atributos5.5 Procesamiento y aprobación de las solicitudes de cambio

6. VALIDACIÓN DE REQUERIMIENTOS7. CHEQUEANDO REQUERIMIENTOS


1. PLAN DE ADMINISTRACIÓN DE REQUERIMIENTOS

1.1 PROPÓSITOEl presente documento tiene por objetivo definir el procedimiento por el cual se efectúan cambios en los requerimientos.

1.2 ALCANCETodos los cambios sugeridos para la versión actual del proyecto seguirán el procedimiento descrito en el presente documento. Cambios propuestos para otras versiones del presente producto que futuros proyectos pudieran construir quedan fuera del alcance del presente documento.

1.3 GENERALIDADESEl fin último del procedimiento aquí descrito es el de que todos los interesados conozcan las implicancias de los cambios de requerimientos sobre el proyecto, incentivando a los posibles iniciadores a proponerlos en estadíos tempranos del mismo, donde los cambios cuentan con mayor probabilidad de ser aprobados y su impacto en costos, calendario y recursos tiende a ser menor. Así mismo se insta al mantenimiento de una lista actualizada con los requerimientos aprobados.

1.4 ¿QUÉ SIGNIFICA DEFINIR LOS REQUERIMIENTOS?

Como podemos apreciar, el proceso de adquisiciones comienza por la etapa de definición de requerimientos, que se origina con una necesidad o solicitud generada por alguna unidad de la organización. Entonces, en términos prácticos, esta etapa consistirá en generar una definición clara y precisa de los aspectos más relevantes del producto o servicio que se necesita comprar o contratar, es decir, se trata de explicar qué, cómo, cuándo y dónde se quiere adquirir.Para realizar esta definición será necesario tener muy claras las necesidades que originan el requerimiento. No hay que olvidar que detrás de cada req hay alguna necesidad relacionada con una actividad de la organización, por lo que todo el proceso debiera estar orientado a satisfacer dicha necesidad de manera eficaz, eficiente y transparente.

Tomando en cuenta estas definiciones, resulta claro que en la gestión de requerimientos deben participar activamente usuarios, directivos y técnicos, cada uno con roles y responsabilidades específicas. Si el usuario final no participa del proceso de desarrollo hay más probabilidades de que encuentre que el producto no responde a las necesidades planteadas, lo que podría llevar al fracaso de la implementación. En este sentido, un error bastante habitual es la posición que adoptan los técnicos de no involucrar a los usuarios hasta que el software es visible, es decir, cuando ya fue desarrollado.

El proceso de gestión de requerimientos implica tres tipos de tareas:

Elicitación: Se trabaja estrechamente con los usuarios a fin de conocer la problemática en detalle. La esencia de esta etapa consiste en extraer el


conocimiento relevante del

problema. Especificación: Es el proceso de documentación del comportamiento deseado

del sistema. Una especificación puede ser vista como un acuerdo entre usuarios y desarrolladores del software.

Validación: Permite asegurar que las especificaciones reflejan correctamente las intenciones de clientes y usuarios.

Estas tareas se desarrollan en forma interactiva a partir de un abordaje progresivo del problema.

Se espera que una especificación de requerimientos que fue aprobada por clientes y/o usuarios tenga al menos las siguientes características:

Que contenga todos los requerimientos deseados. Que cada requerimiento solo tenga una interpretación posible (esto apunta a

eliminar ambigüedades). Que el cumplimiento de cualquier requerimiento no provoque conflictos con el

cumplimiento de otro requerimiento, es decir, que sea consistente. Que se definan prioridades.

El desafío es tomar las teorías y aplicarlas de una manera inteligente y realista, considerando las características específicas del contexto de trabajo de cada organización. La forma de gestionar requerimientos no será igual para todos los casos. Trabajará en forma distinta un equipo que atiende a varias áreas y desarrolla distintos software, que uno o dos técnicos que dependen directamente de un área usuaria con la que trabajan en conjunto, y mantienen un único sistema. En forma análoga, también es razonable pensar que hay diferencias entre gestionar requerimientos que surgen en la etapa de mantenimiento del sistema y lo que implica desarrollar un nuevo sistema.


Recordemos que este proceso es la piedra angular en la construcción de software y, por lo tanto, mejorar este aspecto repercute automáticamente en el resto del desarrollo. Estudios realizados muestran que más del 53% de los proyectos de software fracasan por no realizar una adecuada gestión de requerimientos. Algunos de los motivos más habituales para llegar a esta situación suelen ser la falta de participación del usuario o la presencia de requerimientos incompletos o que se modifican en forma permanente sin poder estabilizarse. Otro dato interesante revela que el costo de solucionar un error en la etapa de mantenimiento es aproximadamente 200 veces mayor que solucionarlo en la etapa de requerimientos.

En un futuro artículo se profundizará en la definición de los distintos escenarios de trabajo y se recomendarán ciertas prácticas que apunten a mejorar la forma de gestionar requerimientos, para mostrar los beneficios que se pueden obtener en cada caso.









1.5 ¿POR QUE ES IMPORTANTE?

Una buena Gestión de Requerimientos es el mayor factor común relacionado con el éxito de los proyectos.


2. PAUTAS PARA DEFINIR REQUERIMIENTOS

El ciclo de vida de los requerimientosLos requerimientos en un proyecto no solo comprenden las tareas de captura y manejo de los cambios a lo largo de todo el proyecto, también comprenden estas otras tareas:1. Identificar los skateholdersSe describe una lista de toda la persona interesada en el desarrollo del sistema.

2. Entender las necesidades de los usuarios y clientes necesarias para planear el sistema y sus expectativas

3. Identificar los requerimientosInicialmente los requerimientos provienen de los objetivos que plantea el negocio, En esta actividad los requerimientos se indican por medio de sentencias. En un escenario de negocio se usa para entender los requerimientos del negocio

4. Aclarecer y refinar los requerimientosEsta actividad se ejecuta cuando se tiene plena seguridad plena certeza de que los requerimientos indican las necesidades reales del cliente y que estos pueden ser usados por el resto de equipos en el proyecto.

5. Analizar los requerimientosSe realiza cuando los requerimientos se encuentran bien definidos y cumplen con el criterio de un buen requerimiento.

6. Definir los requerimientos de forma estándar para los skateholdersDebido a que cada skateholder tiene una perspectiva diferente del sistema y sus requerimientos, es importante esforzar un poco de tiempo en la descripción de los requerimientos usando un vocabulario adecuado.

7. Especificar los requerimientosCada requerimiento debe expresarse en forma detallada de tal manera que pueda ser incluido en otros documentos de especificación o en otros proyectos

8. Priorizar los requerimientosTodos los requerimientos tienen niveles diferentes de importancia para los clientes y usuarios. Unos tienen prioridad críticas, otros no tanta y otros de bajo nivel de prioridad.La priorización de los requerimientos es una actividad que nos va a permitir desarrollar nuevas versiones de nuestro proyecto de forma continua sin verse retrasadas por tiempo en sus salidas.

9. Derivar los requerimientos:Esta actividad nos permite detallar requerimientos no visibles para nuestros clientes o usuarios que no se han logrado identificar, pero que son importantes para el funcionamiento adecuado del requerimiento en detalle.


10. Particionar los requerimientosSe clasifican los requerimientos en diferentes criterios: Hardware, software y entrenamiento.

11. Asignar los requerimientosEsta actividad asigna los requerimientos a diferentes subsistemas y componentes internos,

12. Hacer seguimiento a los requerimientosSe desarrolla la capacidad de permitir que un requerimiento satisfecho pueda ser referenciado dentro del sistema

13. Manejar los requerimientosSe desarrolla un sistema de control de los requerimientos, necesario para adicionar, modificar y borrar requerimientos, al igual que la implantación de un repositorio para estos.

14. Probar y verificar los requerimientosEn esta actividad se validan los requerimientos, diseños, código etc... para asegurarse que los requerimientos están bien

15. Validar los requerimientosFinalmente se confirman los requerimientos reales que han sido implementados para el sistema.

3. CARACTERÍSTICAS DE LOS REQUERIMIENTOS

Un conjunto de requerimientos deben presentar una serie de características tanto individualmente como en grupo. Debe ser:

- Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.- Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.- Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.- Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.- No ambiguo: Un requerimiento no es ambiguo cuando tiene unaE sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.- Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.


4. DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS

- Los requerimientos no son obvios y vienen de muchas fuentes.- Son difíciles de expresar en palabras (el lenguaje es ambiguo).- Existen muchos tipos de requerimientos y diferentes niveles de detalle.- La cantidad de requerimientos en un proyecto puede ser difícil de manejar.- Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.- Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.- Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.- Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.- Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

4.1 IMPORTANCIA DE LA INGENIERÍA DE REQUERIMIENTOSLos principales beneficios que se obtienen de la Ingeniería deRequerimientos son:

- Permite gestionar las necesidades del proyecto en forma estructurada:Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.

- Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.

- Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE.

- Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).

- Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.

- Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.


4.2 ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS

Se divide las prácticas de la IR en 4 actividades:

- Extracción Esta fase representa el comienzo de cada ciclo. Extracción es el nombre

comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Se debe trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar.

Esto no suele ser tarea fácil: muchas veces los clientes/usuarios no tienen una idea clara de sus necesidades reales, diversas personas dentro de la organización tienen necesidades encontradas, pueden existir limitaciones técnicas o tecnológicas para cumplir con algunos requerimientos.

Descubrir los requerimientos del sistema no sólo implica preguntar a las personas qué quieren: es un proceso delicado que involucra comprender el domino de aplicación, es decir, obtener un conocimiento del área general de aplicación del sistema; comprender el problema en sí, lo que implica que se debe extender y especializar el conocimiento sobre el dominio general para que se aplique al cliente en particular; comprender el negocio, por tanto, se debe entender en profundidad cómo es que este sistema afectará a las partes del negocio que estarán involucradas y cómo puede contribuir a lograr las metas de la empresa.

Comprender las necesidades y restricciones de los usuarios del sistema en particular, se deben entender los procesos de trabajo que se supone que el sistema apoyará y el rol de cualquier otro sistema que actualmente se involucre en dichos procesos.

- Análisis Aquí se apunta a descubrir problemas con los requerimientos del sistema

identificados hasta el momento. Usualmente se hace un análisis luego de haber producido un bosquejo inicial del

documento de requerimientos; aquí se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos.

- Especificación En esta fase se documentan los requerimientos acordados con el cliente, en un

nivel apropiado de detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, pero

podríamos decir que la Especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML.


- Validación La validación es la etapa final. Su objetivo es validar los requerimientos, es

decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos.

La validación representa un punto de control interno y externo; interno, porque se debe verificar internamente lo que se está haciendo, y externo, porque se debe validar con el cliente.

El documento de requerimientos obtenido en la etapa anterior sólo debería incluir los requerimientos que son aceptables para los usuarios.

Pero es inevitable que durante la validación se descubran algunos problemas relacionados con los usuarios, y esto se debe corregir antes de aprobarse el documento final de requerimientos.

En definitiva, la validación de especificaciones realmente significa asegurarse de que el documento de requerimientos represente una descripción clara del sistema, y es una verificación final de que los requerimientos cubren las necesidades de los usuarios.

La diferencia con el análisis es clara: mientras que en el análisis se trabaja sobre el boceto del documento de requerimientos, en la validación se utiliza el documento final.


5. EL PROGRAMA DE ADMINISTRACIÓN DE REQUERIMIENTOS

5.1 Análisis comparativo de las técnicas de Ingeniería de Requerimientos

A continuación se presentan las principales ventajas y desventajas de implementar cada una estas técnicas utilizadas en la etapa de Ingeniería de Requerimientos.

En base a las ventajas y desventajas mostradas anteriormente, se hace una comparación entre algunas de las técnicas.

Entrevistas vs. Casos de Uso: Un alto porcentaje de la información recolectada durante una entrevista, puede ser usada para construir casos de uso. Mediante esto, el equipo de desarrollo puede entender mejor el ambiente de trabajo de los involucrados. Cuando el analista sienta que tiene dificultades para entender una tarea, pueden recurrir al uso de un cuestionario y mostrar los detalles recabados en un caso de uso. De hecho, durante las entrevistas cualquier usuario puede utilizar diagramas de casos de uso para explicar su entorno de trabajo.

Entrevistas vs. Lluvia de Ideas: Muchas de las ideas planteadas en el grupo, provienen información recopilada en entrevistas o cuestionarios previos. Realmente la lluvia de ideas trata de encontrar las dificultades que existen para la comprensión de términos y conceptos por parte de los participantes; de esta forma se llega a un consenso.


Casos de Uso vs. Lluvia de Ideas: La lista de ideas proveniente del brainstorm puede ser representada gráficamente mediante casos de uso.

El siguiente cuadro muestra las técnicas que pueden ser utilizadas en las diferentes actividades de la IR.

5.2 Identificación de RequerimientosUna vez comunicados los requerimientos por el cliente, el trabajo del Analista de Sistema en este caso el Líder de Desarrollo consistirá en identificar con claridad los requerimientos para que a continuación el los reúna en el documento “Especificaciones de Requerimientos de Software”, documento este que será mantenido atento a los cambios que pudieran tener lugar durante el desarrollo del proyecto.

5.3 TrazabilidadLa trazabilidad de los cambios se efectuará mediante el almacenamiento de la planilla de solicitud de cambios, cada una cuales se va actualizando conforme el proceso de cambio va pasando por las distintas fases.

5.4 AtributosSe describen a continuación atributos que son referenciados en el proceso de definición de cambios.

Estado

Será el establecido por el comité de cambios, con la aprobación de quienes sea necesario, como resultado de las distintas revisiones y negociaciones con el cliente. Favorecen la definición del progreso del baseline del producto.

Propuestas Features descriptas que se encuentran bajo discusión, que aún no han sido revisadas y aprobadas por los canales oficiales.


Aprobadas Capacidades que se han considerado útiles y factibles y se han aprobado para su implementación a través de los canales previstos.

Rechazados Característica rechazada por el canal oficial.

Incorporadas Features incorporados al baseline del producto en un momento específico.

Así mismo, el estado para una solicitud de cambio se establecerá como

Abierto Cuando el cambio aun no fue evaluado o cuando el cambio fue aprobado pero aún no se ha implementado.

Cerrado Cuando el cambio fue rechazado o cuando fue ya implementados.

Beneficio

Establecidos por Business Líder de Desarrollo y el cliente. La definición de importancia sobre los requerimientos estará en relación con los usuarios finales, y será el resultado del diálogo entre el cliente y el project manager, atendiendo a las necesidades de los primeros y a las restricciones del proyecto. Estos atributos definen a si mismo las prioridades para su implementación.

Críticos Son features esenciales, que de fallar en su implementación implicarían el no cumplimiento de las necesidades de nuestro cliente. Deberán ser implementadas indefectiblemente en la versión.

Importantes Features importantes para la eficacia y eficiencia del producto. Caracteriza al feature en cuestión cuando la funcionalidad no pudiera ser alcanzada con facilidad por medios alternativos. Por lo tanto, la no inclusión de un feature evaluado como importante afectará la satisfacción del usuario o del cliente, pudiendo tener consecuencias económicas para el proyecto, pero no será motivo para demorar la entrega de la versión.

Útiles Son features que resultan útiles en circunstancias que típicamente podríamos considerar como poco frecuentes o en las que de todos modos se cuenta con una alternativa razonablemente eficiente. La satisfacción del cliente o los beneficios obtenidos con el producto no se ven afectados de manera significativa si estos features no son incluidos en la versión.

Ninguna No se reconoce utilidad en el cambio propuesto.


5.5

Procesamiento y aprobación de las solicitudes de cambio

A continuación se señalas los componentes del proceso que sigue una solicitud de cambio, desde su origen hasta su cierre, indicando también los principales actores intervinientes.

El iniciador del cambio será un Líder del Proceso autorizado para elevar tal solicitud. El origen del cambio puede tener lugar en un nuevo requerimiento que el cliente descubrió a medida que el proyecto fue avanzando, una necesidad de mejora, o simplemente un cambio solicitado por la no satisfacción del cliente con algún aspecto del producto en desarrollo. Deberá completar una solicitud formal para el cambio y firmarla.

El iniciador debe comprender que todo cambio tiene un costo desde el momento mismo en que completa y firma la solicitud de cambio, pues aunque finalmente no se apruebe, la evaluación previa requiere de esfuerzo, tiempo y dinero. Debe quedar en claro que será muy favorable para el calendario y la organización de los recursos, elevar las solicitudes de cambio en la etapa más temprana posible. Cuánto más tardías sean estas solicitudes, mayor será el impacto en el plan de proyecto y mayores serán los costos, reduciéndose la probabilidad de aprobación de aquellas.

El Project Manager recibe la propuesta y notifica al Líder de Control de Cambios.

El análisis del impacto estará a cargo del Project Manager (PM) y se hará en relación a las variables del proyecto que cualquier cambio puede afectar. Trabajará en conjunto con el Líder de Desarrollo y quien considere con la aptitud necesaria para un adecuado análisis. El PM completa la información requerida en la planilla de solicitud de cambios y la firma.

En base al informe sobe el análisis de impacto se efectuará una evaluación sobre la necesidad del cambio. Participarán aquí los miembros del comité de cambios. Un representante del comité de cambios reportará lo acordado en la planilla de solicitud de cambios, y respaldará el documento con su firma.

Una vez considerados los efectos, costos y beneficios del cambio solicitado, el comité de cambios decidirá su aprobación. Si el cambio es aprobado el proceso continua, de lo contrario se procede al cierre de la solicitud y se comunica al iniciador. Un representante del comité de cambios firma la planilla respaldando la resolución tomada.

El iniciador, al ser comunicado de la decisión, firmará la solicitud indicando que ha tomado conocimiento de aquella.

Durante la priorización y planificación se determina en el orden en el que los cambios aprobados serán ejecutados. De ser posible, se los agrupará. Se define cuando serán ejecutados y en que versión del producto serán aplicados (actual o subsiguientes). En


base al beneficio reportado, el Project Manager junto con el Change Control Manager se ocuparán de esta priorización de los diferentes cambios aprobados, actualizará las especificaciones de requerimientos de software y efectuará las modificaciones pertinentes en el plan de proyecto.

Luego se procede al desarrollo y prueba. Más tarde a la validación, para verificar que se haya cumplido con las expectativas del cliente para ese cambio, y más tarde a la implementación en producción.

6. VALIDACIÓN DE REQUERIMIENTOS

Demostración de que los requerimientos que definen el sistema son lo que el cliente realmente quiere.

Los costos de errores en los requerimientos son altos, por lo cual, la validación es muy importante.• Fijar un error de requerimiento después del desarrollo puede resultar en un costo 100 veces mayor que fijar un error en la implementación.

El Prototipado es una técnica importante de la validación de Requerimientos

7. CHEQUEANDO REQUERIMIENTOS

Validación. Provee al sistema las funciones que mejor soporten las necesidades del cliente?

Consistencia. Existe cualquier conflicto en los requerimientos? Completo. Están incluidas todas las funciones requeridas por el cliente? Realismo. Pueden los requerimientos ser implementados con la tecnología y el

presupuesto disponible?

Comparación Vs. Documento Plan de Administración de Requerimientos I

En completitud al documento efectuado en la fase pasada, en este trabajo se plasman Criterios de Pautas para la Definición de Requerimientos, como también Actividades de Ingeniería de Requerimientos, además de un Análisis comparativo de las técnicas de Ingeniería de Requerimientos necesarias para una buena construcción del Problema todo concerniente a los ítems que se deben seguir para tener un excelente Plan de Administración de Requerimientos.


plan de administraciÓn de requerimientos … · web viewel fin último del procedimiento aquí...

Documents