Académique Documents
Professionnel Documents
Culture Documents
El documento describe el Plan de gestin de requisitos que se seguir en el desarrollo del sistema de administracin de la cooperativa Puntos Verdes
I.
Gestin de la Configuracin. Ttulo: Referencia: Autores: Plan de gestin de requisitos para el SACPUVE Ninguna Jess Castro Magaa Hudy Chan Rodrguez Flix Sosa Quintal Juan Ku Quintana Victor Rodriguez Camara 14/11/2010
Fecha:
Histrico de Versiones. Versin 0.1 1.0 Fecha 14/11/2010 03/01/2011 Estado Final Final Responsable(s) Jess Castro Magaa Jess Castro Magaa Nombre de Archivo Plan_RM_Ver-0.1 SACPUVE_PP_RM_1.0
Histrico de Cambios. Versin 0.1 1.0 Fecha 14/11/2010 03/01/2011 Cambios No AplicaPrimeraVersin Cambios sobre todo el documento para apegarse al proceso definido y realizar aclaraciones respecto a las herramientas.
Contenido
I. Informacin del Documento.............................................................................. 1 Gestin de la Configuracin. ........................................................................... 1 Histrico de Versiones..................................................................................... 1 Histrico de Cambios. ..................................................................................... 1 1. 1.1 1.2 2. 3. 4. Introduccin .................................................................................................. 3 Proposito ................................................................................................... 3 Alcance ..................................................................................................... 3 Identificacin de las Fuentes de Requisitos .................................................. 4 Obtencin de Acuerdo de los requerimientos ............................................... 5 Administracin de Cambios en los Requisitos .............................................. 6
4.1 Seleccin de la Herramienta para el manejo de la Base de Datos de Requerimientos .............................................................................................................. 7 5. 6. 7. 8. 9. Mantener la Trazabilidad de los Requerimientos .......................................... 8 Identificacin de Inconsistencias................................................................... 9 Responsabilidades en la Administracin de Requisitos .............................. 10 Estndares y Plantillas ............................................................................... 11 Herramientas .............................................................................................. 12
1. Introduccin
1.1 Proposito
El propsito del Plan de Administracin 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 sern la base para estimar, planear, ejecutar y controlar las actividades durante toda la duracin del proyecto. Este plan se ocupa de cmo 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 estn asignados dentro de los requisitos funcionales y no funcionales necesarios para desarrollar una solucin. Aqu se detalla el proceso a detalle es decir: Asignacin de Responsabilidades Identificacin de Tcnicas a Implementar Las Herramientas a Usar Desarrollo de Documentacin 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 tambin quienes son los responsables nombrados.
1.2 Alcance
El alcance del Plan abarca la gestin 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, diseo y otros factores de manera oportuna.
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 mnimos que sean sobre el sistema.
SH-002
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
SH-003
Administrador de la Coopertiva
Usuario directo del sistema Es aquella persona encargada de la administracin 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 desempeo para con los requisitos de la UI
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 ambigedad 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 ambigedades con la finalidad de reprimirlas.
El comit de cambios estar conformado por: Dr. ngel Cirilo Lendechy Grajales, como representante del cliente Jess Castro, como lder del proyecto y parte del equipo de desarrollo Hudy Chan, como jefe de la junta de requisitos y parte del equipo de desarrollo Flix 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 satisfaccin del cliente con algn aspecto del producto en desarrollo. Deber completar una solicitud formal para el cambio (RFC) y firmarla, dicha solicitud se encuentra anexa en el Apndice AX del proceso de Gestin de la Configuracin. El iniciador debe comprender que todo cambio tiene un costo desde el momento mismo en que completa y firma la solicitud de cambio (vase la plantilla de Solicitud de Cambio que se encuentra en el plan de Administracin de la Configuracin), pues aunque finalmente no se apruebe, la evaluacin previa requiere de esfuerzo, tiempo y dinero, adems de ello, debe quedar en claro que ser muy favorable para el calendario y la organizacin de los recursos, elevar las solicitudes de cambio en la etapa ms temprana posible del proyecto, ya que cunto ms tardas sean estas solicitudes, mayor ser el impacto en el plan de proyecto y mayores sern los costos, reducindose la probabilidad de aprobacin de aquellas solicitudes. Para ser ms especficos dentro de esta tarea, se debe recurrir al apartado 4.3.2.3 del proceso de gestin de requerimientos en el cual se muestra de manera ms detallada el proceso adecuado para la correcta gestin de los requerimientos.
Con respecto a la Tabla 1. Comparacin de Herramientas de gestin de , se puede ver que el sistema que se usara es Rational Requisite PRO, ya que es la ms completa segn el anlisis 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 gestin de la configuracin el conjunto de herramientas Rational Requisite PRO, el cliente SmartSVN y el repositorios Google Code para realizar la gestin de los requisitos del sistema SACPUVE.
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.
6. Identificacin de Inconsistencias
De acuerdo a lo acordado dentro del proceso de gestin 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 revisin 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 reunin 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 reunin: 28-01-2011
Con base a la nomenclatura de los documentos de las reuniones, la seccin XX-XXXXXX, deber ser cambiada a la fecha de realizacin del mismo con el formato: Da-Mes-Ao, en donde Da y Mes sern representados por dos dgitos.
El cual deber coordinarse con el administrador de la configuracin Br. Victor Rodriguez. El responsable de recibir solicitudes de cambios de requisitos ser nicamente el administrador del proyecto: Br. Jess Castro
Los responsables de desarrollar y validar los requisitos con los stakeholders: Br. Juan Ku Br. Yichao Zhu Br. Hudy Chan
8. Estndares y Plantillas
ERS con el estndar IEEE - 830 Plantilla de Peticin de Cambios (RFC)-Proceso de Gestin de Requerimientos Plantilla de Especificacin del Motivo de Rechazo-Proceso de Gestin de la Configuracin Plantilla de Orden de Cambio-Proceso de Gestin de la Configuracin Plantilla de Inconsistencia-Proceso de Gestin de Requerimientos Plantilla de AccinCorrectiva-Proceso de Gestin de Requerimientos
9. Herramientas
SmartSVN: Es un cliente para el sistema de control de versiones Subversin, esto quiere decir que maneja ficheros y directorios a lo largo del tiempo dentro de un repositorio. MySQL:Es un sistema de gestin de bases de datos (SGBD) multiusuario, multiplataforma y de cdigo abierto. Matriz de Trazabilidad: Es un documento de texto que pudiera ser sustituido por una hoja de clculo. Rational Requisite Pro: Herramienta utilizada para la administracin de requisitos durante el desarrollo de software.