Plan de gestión de requisitos para el SACPUVE

SISTEMA DE
ADMINISTRACIÓN DE LA
COOPERATIVA PUNTOS
VERDES
Plan de gestión de
requisitos para el
SACPUVE
2010
El documento describe el Plan de gestión de requisitos que se
seguirá en el desarrollo del sistema de administración de la
cooperativa Puntos Verdes
I.
Información del Documento
Gestión de la Configuración.
Título:
Plan de gestión de requisitos para el SACPUVE
Referencia:
Ninguna
Autores:
Jesús Castro Magaña
Hudy Chan Rodríguez
Félix Sosa Quintal
Juan Ku Quintana
Victor Rodriguez Camara
14/11/2010
Fecha:
Histórico de Versiones.
Versión
0.1
1.0
Fecha
14/11/2010
03/01/2011
Estado
Final
Final
Responsable(s)
Jesús Castro Magaña
Jesús Castro Magaña
Nombre de Archivo
Plan_RM_Ver-0.1
SACPUVE_PP_RM_1.0
Histórico de Cambios.
Versión
0.1
1.0
Fecha
14/11/2010
03/01/2011
Cambios
No AplicaPrimeraVersión
Cambios sobre todo el documento para apegarse al proceso definido
y realizar aclaraciones respecto a las herramientas.
Plan de Administración de Requisitos|1
Contenido
I.
Información del Documento.............................................................................. 1
Gestión de la Configuración. ........................................................................... 1
Histórico de Versiones..................................................................................... 1
Histórico de Cambios. ..................................................................................... 1
1.
Introducción .................................................................................................. 3
1.1
Proposito ................................................................................................... 3
1.2
Alcance ..................................................................................................... 3
2.
Identificación de las Fuentes de Requisitos .................................................. 4
3.
Obtención de Acuerdo de los requerimientos ............................................... 5
4.
Administración de Cambios en los Requisitos .............................................. 6
4.1 Selección de la Herramienta para el manejo de la Base de Datos de
Requerimientos .............................................................................................................. 7
5.
Mantener la Trazabilidad de los Requerimientos .......................................... 8
6.
Identificación de Inconsistencias................................................................... 9
7.
Responsabilidades en la Administración de Requisitos .............................. 10
8.
Estándares y Plantillas ............................................................................... 11
9.
Herramientas .............................................................................................. 12
Plan de Administración de Requisitos|2
1. Introducción
1.1 Proposito
El propósito del Plan de Administración de Requisitos del sistema SACPUVEes la
de establecer y mantener un acuerdo entre el cliente y el proyecto; lo anterior enfocado
sobre los requisitos; lo cual representa el alcance del producto que será dirigido por el
proyecto.
Los requisitos serán la base para estimar, planear, ejecutar y controlar las
actividades durante toda la duración del proyecto.
Este plan se ocupa de cómo el Proyecto SACPUVE administrará el desarrollo y los
cambios en los requisitos para asegurar que las necesidades iniciales del cliente y los
objetivos del proyecto están asignados dentro de los requisitos funcionales y no
funcionales necesarios para desarrollar una solución.
Aquí se detalla el proceso a detalle es decir:




Asignación de Responsabilidades
Identificación de Técnicas a Implementar
Las Herramientas a Usar
Desarrollo de Documentación adecuada
Es responsabilidad del Administrador de Proyecto delSACPUVE asegurarse de
que el equipo de desarrollo conozca y siga este plan, así mismo el proceso asociado y
también quienes son los responsables nombrados.
1.2 Alcance
El alcance del Plan abarca la gestión de los requisitos del Proyecto SAPUVE
durante todo su ciclo de vida, con el objetivo de tener un correcto control sobre los
requisitos que afectan a la funcionalidad, diseño y otros factores de manera oportuna.
1.3 Documentos Referenciados
Archivo
Nombre
Proceso de Gestión de la Configuración
SACPUVE_PrP_CM_1.0.0.docx
Proceso de Gestión de Requerimientos
SACPUVE_PrP_RM_1.0.0.docx
Plan de Administración de Requisitos|3
2. Identificación de las Fuentes de Requisitos
La información recogida sobre cada stakeholder será el nombre de la persona o
grupo, algún identificador del stakeholder e información general sobre el rol del
stakeholder o cómo éste podría ser afectado por el proyecto, dichos datos son mostrados
en la tabla anexa a este apartado.
Con base a lo anterior y a lo estipulado en el Apéndice A1 del proceso de gestión
de requisitos, se identificaron a los siguientes Stakeholders como fuentes de
requerimientos oficiales, dicha selección se llevo a cabo el día 20-12-2010 de acuerdo a lo
acordado en la agenda de trabajo:
Identificador:
Nombre:
Rol:
Información General:
SH-001
Identificador:
Nombre:
Rol:
Información General:
SH-002
Identificador:
Nombre:
Rol:
Información General:
SH-003
Dr. Ángel Cirilo Lendechy Grajales
Contacto con el cliente
El stakeholder es el contacto directo entre
el cliente y el equipo de desarrollo, por
consiguiente se ve afectado por todos los
cambios por mínimos que sean sobre el
sistema.
Miembro de la Cooperativa
Usuarios Indirectos del sistema
Son todos aquellos miembros de la
cooperativa que se ven afectados por todos
los trabajos realizados por la cooperativa,
así pues al hacerse un cambio en el
sistema estos pueden verse afectados de
manera indirecta
Administrador de la Coopertiva
Usuario directo del sistema
Es aquella persona encargada de la
administración de la cooperativa y que se
ve afectada por todos los cambios para con
el sistema, independientemente del modulo
que sea, así mismo es quien proporciona
un mayor desempeño para con los
requisitos de la UI
Plan de Administración de Requisitos|4
3. Obtención de Acuerdo de los requerimientos
Con base a los Stakeholders identificados anteriormente, se procede a analizar
los requerimientos, así pues se realizó una reunión para revisar los criterios de los
requerimientos del actual ERS celebrada el 22 de 12 del 2010 de donde se obtuvo el
documento denominado RM_A3_22-12-2010.docx en el cual se estipulan los criterios que
fueron aprobados por los requisitos de acuerdo al Apéndice A2 del proceso de gestión de
requerimientos, de donde se obtienen las siguientes observaciones:

Existe un rastro de ambigüedad en el requisito referente a los prestamos de
la cooperativa para con los socios.
Así mismo, se obtuvo un acuerdo con los Stakeholders sobre los requerimientos
celebrado el 27 de 12 del 2010, con el conocimiento de las observaciones antes citadas,
así pues se obtuvo el documento denominado RM_A4_27-12-2010.docx, en el cual los
Stakeholders estuvieron de acuerdo con los requerimientos y se realizaron observaciones
sobre la ambigüedad antes mencionada, permitiendo al equipo llegar a un consenso
sobre el mismo, acordando dejar el modulo referente a dicho requerimiento como el ultimo
a ser realizado y esclarecer en reuniones posteriores dichas ambigüedades con la
finalidad de reprimirlas.
Plan de Administración de Requisitos|5
4. Administración de Cambios en los Requisitos
El proceso de administración de cambios en los requisitos se usará para
administrar: eliminaciones, modificaciones y adiciones dentro de la misma línea de los
objetivos originales o para modificar formalmente los objetivos originales y para el apoyo
de la agenda y los recursos.
A continuación se definen las personas que estarán autorizadas para realizar una
solicitud de cambio.
Nombre
Administradores de la Cooperativa
Dr. Ángel Cirilo Lendechy Grajales
Jesús Castro
Jefe de la Junta de Requisitos
Miembro de la Junta de Requisitos
Rol
Stakeholder
Patrocinador/Stakeholder
Líder de Proyecto
Hudy Chan Rodriguez
Felix Sosa Quintal
El comité de cambios estará conformado por:




Dr. Ángel Cirilo Lendechy Grajales, como representante del cliente
Jesús Castro, como líder del proyecto y parte del equipo de desarrollo
Hudy Chan, como jefe de la junta de requisitos y parte del equipo de desarrollo
Félix Sosa, como parte de la junta de requisitos y del equipo de desarrollo
Ahora bien el origen del cambio puede dar lugar a 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 (RFC) y
firmarla, dicha solicitud se encuentra anexa en el Apéndice AX del proceso de Gestión de
la Configuración.
El iniciador debe comprender que todo cambio tiene un costo desde el momento
mismo en que completa y firma la solicitud de cambio (véase la plantilla de Solicitud de
Cambio que se encuentra en el plan de Administración de la Configuración), pues aunque
finalmente no se apruebe, la evaluación previa requiere de esfuerzo, tiempo y dinero,
además de ello, 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 del proyecto, ya que 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 solicitudes.
Para ser más específicos dentro de esta tarea, se debe recurrir al apartado 4.3.2.3
del proceso de gestión de requerimientos en el cual se muestra de manera más detallada
el proceso adecuado para la correcta gestión de los requerimientos.
Plan de Administración de Requisitos|6
4.1 Selección de la Herramienta para el manejo de la Base de Datos
de Requerimientos
Para seleccionar la herramienta que servirá como gestor de la base de datos, se
tomara en cuenta los siguientes puntos:



Que la versión del software no sea de prueba o de paga.
Que sea un sistema fácil de usar
Que no sea un plugin de un ambiente de desarrollo (IDE).
Herramienta
Prueba
Usabilidad
Plugin
Total
No
Multi
OS
No
Rational
Requisite PRO
ReqStudio
No
Si
No
Si
No
No
8
9
Tabla 1. Comparación de Herramientas de gestión de la BD de requerimientos
Con respecto a la Tabla 1. Comparación de Herramientas de gestión de , se puede
ver que el sistema que se usara es Rational Requisite PRO, ya que es la más completa
según el análisis que se realizo.
Con base a lo anterior Se procede a generar el documento llamado RM_A7_29-122010.docx, en el cual se estipula como mecanismo de gestión de la configuración el
conjunto de herramientas Rational Requisite PRO, el cliente SmartSVN y el repositorios
Google Code para realizar la gestión de los requisitos del sistema SACPUVE.
Plan de Administración de Requisitos|7
5. Mantener la Trazabilidad de los Requerimientos
Dada la naturaleza del proyecto y la herramienta para la gestión dada, se optará
por usar las matrices de trazabilidad del sistema Rational Requisite PRO, las cuales
deberán de ser generadas de manera periódica de acuerdo a las fechas de celebración
de las reuniones programadas del equipo de Gestión estipuladas dentro de la agenda de
desarrollo las cuales son:

28-01-2011
Así mismo de acuerdo a lo estipulado en el apartado anterior, se puede tomar
como referencia el documento RM_A8_29-12-2010.docx para entender el proceso de
rastreabilidad de los requerimientos.
Plan de Administración de Requisitos|8
6. Identificación de Inconsistencias
De acuerdo a lo acordado dentro del proceso de gestión de requerimientos, en el
apartado 4.3.1.5 se estipulan los procedimientos adecuados para llevar acabo esta tarea,
así pues de acuerdo a ello se estipulan las siguientes fechas para la revisión de los
requerimientos y productos de trabajo, así como las matrices de trazabilidad para
identificar todos aquellos conflictos dentro de dichos elementos, así mismo durante cada
reunión se procederá a realizar los documentos RM_A10_XX-XX-XXX.docx y
RM_A11_XX-XX-XXX.docx que representan a los documentos de inconsistencias y
acciones correctivas de cada reunión:

28-01-2011
Con base a la nomenclatura de los documentos de las reuniones, la sección XX-XXXXXX, deberá ser cambiada a la fecha de realización del mismo con el formato:
Día-Mes-Año, en donde Día y Mes serán representados por dos dígitos.
Plan de Administración de Requisitos|9
7. Responsabilidades en la Administración de Requisitos
Las personas responsables de la administración de requisitos serán:



Br. Jesús Castro
Br. Victor Rodriguez
Br. Félix Sosa
El responsable para la administración de cambios de requisitos será:

Br. Hudy Chan
El cual deberá coordinarse con el administrador de la configuración Br. Victor
Rodriguez.
El responsable de recibir solicitudes de cambios de requisitos será únicamente el
administrador del proyecto:

Br. Jesús Castro
Los responsables de desarrollar y validar los requisitos con los stakeholders:



Br. Juan Ku
Br. Yichao Zhu
Br. Hudy Chan
Plan de Administración de Requisitos|10
8. Estándares y Plantillas






ERS con el estándar IEEE - 830
Plantilla de Petición de Cambios (RFC)-Proceso de Gestión de
Requerimientos
Plantilla de Especificación del Motivo de Rechazo-Proceso de Gestión de la
Configuración
Plantilla de Orden de Cambio-Proceso de Gestión de la Configuración
Plantilla de Inconsistencia-Proceso de Gestión de Requerimientos
Plantilla de AcciónCorrectiva-Proceso de Gestión de Requerimientos
Todas Las Plantillas deberán de ser administradas por la gestión de la
configuración.
Plan de Administración de Requisitos|11
9. Herramientas




SmartSVN: Es un cliente para el sistema de control de versiones Subversión,
esto quiere decir que maneja ficheros y directorios a lo largo del tiempo dentro
de un repositorio.
MySQL:Es un sistema de gestión de bases de datos (SGBD) multiusuario,
multiplataforma y de código abierto.
Matriz de Trazabilidad: Es un documento de texto que pudiera ser sustituido
por una hoja de cálculo.
Rational Requisite Pro: Herramienta utilizada para la administración de
requisitos durante el desarrollo de software.
Plan de Administración de Requisitos|12