- Plan de Gestión de Proyecto MoSimPa
- Sección 1: Introducción
- Sección 2: Objetivos
- Sección 4: Documentos relacionados
- Sección 5: Destinatarios del plan
- Sección 6: Adminitración del proyecto
- Sección 7: Entregables y criterios de aceptación
- Sección 8: Apéndice
Plan de Gestión de Proyecto MoSimPa
Convenciones del documento
En el presente Documento se utilizan convenciones estándar de texto, con el objetivo de facilitar su comprensión y uso. En esta Sección se procede a detallar las instrucciones necesarias para que el usuario del documento sustituya la información genérica provista en esta plantilla con la información de su propio proyecto. El usuario del documento deberá evaluar la información genérica suministrada en este plan de Gestión de la Configuración y ajustarla a las necesidades de su proyecto.
[[texto]] Cambios globales: Los textos que aparecen en modo regular, y encerrados con dobles corchetes [[]], representan cambios que pueden realizarse de manera global (Por ej. en [[Modifique en “Asunto” el nombre del Proyecto]] el usuario podrá modificar la propiedad indicada (Archivo→Propiedades→Descripción) en el procesador de texto, lo que le permitirá hacer un cambio a todas las ocurrencias del proyecto.
\ Guías de uso: El texto que aparece encerrado entre los símbolos \ representa instrucciones o guías de ayuda al usuario del documento. Este texto sólo será visible e impreso en formato Markdown. De todas maneras, si lo considera necesario, puede borrar estas instrucciones.
Sección 1: Introducción
El presente Plan de Gestión de Proyecto surge de la aprobación de la propuesta técnica de solicitud de servicio de consultoría de asistencia técnica en aspectos normativos y regulatorios para el registro del producto médico que se encuentra en proceso de diseño y desarrollo en el marco del Proyecto MoSimPa. Esta propuesta fue documentada y acordada por las partes interesadas, resultando en un Acta de Constitución del Proyecto en la forma de un Convenio Específico, el cual será referenciado en el presente. Los procesos involucrados en este contexto de diseño y desarrollo serán guiados y debidamente documentados en base a la información contenida en este Plan.
Este Documento va dirigido a las partes interesadas (stakeholders) especificadas en la sección 5, quienes tendrán responsabilidad en el control y seguimiento del Proyecto MoSimPa .
1.1. Organización del Documento
A continuación se describirá brevemente cada una de las secciones que componen el presente Documento. Se sugiere al lector una lectura secuencial, siguiendo el orden propuesto.
Sección 1: – Introduce al lector al contenido del Plan.
Sección 2 :– Describe los objetivos del Plan.
Sección 3: – Identifica los alcances y exclusiones del Plan.
Sección 4: – Identifica los documentos relacionados con el Plan.
Sección 5: – Identifica los lectores/actores a los cuales está dirigido el Plan.
Sección 6: – Describe los procesos y actividades involucradas en cada uno de ellos, relacionadas con la gestión del proyecto.
Sección 7: – Identifica los entregables y criterios de aceptación de los mismos como tales, así como los hitos (milestones) con los que contará el proyecto y las líneas bases de configuración asociadas a un hito particular, lo que permitirá la implementación del Plan.
Sección 8:– Expone un glosario de términos y definiciones del Plan, así como la historia de los cambios que se realizan al Documento.
Sección 2: Objetivos
El objetivo del presente Documento es establecer las bases de acuerdo entre los stakeholders, y definir un documento para consulta, delimitando la declaración del alcance, la declaración del trabajo del proyecto, la gestión de recursos y comunicaciones, la gestión de los requerimientos, la gestión de los riesgos, gestión de los cambios, la estrategia de desarrollo empleada, la delimitación de las fases/incrementos/módulos que lo constituirán, la estructura de desglose de tareas (WBS), la definición del equipo de proyecto, los hitos de entrega y entregables, presentación de avances, mecanismos de seguimientos y métricas.
SECCIÓN 3: ALCANCE DEL DOCUMENTO
Gestionar el alcance del Proyecto MoSimPa se enfoca primordialmente en definir y controlar qué se incluye y qué no se incluye en el proyecto. La definición del alcance se basa en desarrollar una descripción detallada del proyecto, definición que es posterior a la captura de requerimientos, por lo que será necesario disponer del Documento de Especificación de Requerimientos.
3.1. Alcances
El alcance del Proyecto es el trabajo realizado para entregar un producto, servicio o resultado con las funciones y características especificadas. La formalidad para el comienzo en la ejecución del proyecto se dará cuando se haya validado el alcance por las partes interesadas, delineando la línea base de configuración de alcance.
En este contexto, en base a la información contenida en el Documento de Especificación de Requerimientos antes citado, los requerimientos funcionales y no funcionales que deberán ser aplicados como criterios de diseño en el marco del Proyecto MoSimPa son los que se detallan a continuación en la siguiente tabla, indicando nombre de denominación de cada requerimiento, número de identificación, tipo de requerimiento (funcional, no funcional, etc.), nivel de criticidad asociado al mismo y su nivel de complejidad.
3.2. Exclusiones
Queda fuera del alcance del Proyecto el planteamiento de los requerimientos y la realización de la API para celulares.
Sección 4: Documentos relacionados
A continuación se indican los Documentos del Proyecto MoSimPa relacionados con este Plan:
- Convenio específico.
- Plan de gestión de configuración del proyecto.
- Plan de testing. To Do: Arreglar el link.
- Plan de gestión de riesgos.
- Documento de especificación de requerimientos.
Sección 5: Destinatarios del plan
En la siguiente tabla se identifican los destinatarios a los que está dirigido el Plan de Gestión del Proyecto MoSimPa. Este apartado constituye el registro de stakeholders.
| Lector/Actor | Rol |
|---|---|
| MANDOLESI, Pablo | Líder de Proyecto / Ingeniero de D&D de Hardware |
| PÉREZ MEYER, Lisandro | Ingeniero de D&D de Software / Administrador de la Configuración |
| AYMONINO, Andrés | Ingeniero de D&D de Hardware |
| POUSO, Marcelo | Ingeniero de D&D de Software |
| CASANOVA, Alejandro | Ingeniero de D&D de Software |
| VALLASCIANI, Luis Guillermo | Ingeniero de D&D de Hardware |
| COPPA, Guillermo | Ingeniero de D&D de Hardware |
| ROSSI, Esteban | Líder Consultor de Procesos – RRHH externo |
| ALBORNOZ LAFERRARA, Josué | Ingeniero Consultor de Procesos Sr. – RRHH externo |
| GRAMAJO, Rodrigo | Ingeniero Consultor de Procesos Jr. – RRHH externo |
| CARDOSO, Paula | Ingeniera Consultora de Procesos Jr.– RRHH externo |
Sección 6: Adminitración del proyecto
El presente Plan de Gestión de Proyecto busca garantizar el cumplimiento de las herramientas de Gestión de Configuración General, y con ello facilitar el cumplimiento de las normativas relacionadas al desarrollo de software y hardware del producto médico del Proyecto MoSimPa.
Para concretar esta actividad, el Grupo Consultor ha propuesto:
-
Crear un Plan de Proyecto donde se definirán: ciclo de vida como estrategia del proyecto; roles y responsabilidades; entregables y criterios de aceptación; actividades por fase/hitos; mecanismos de control y seguimiento; cronograma de trabajo y referencias a los procesos/procedimientos de administración de la configuración del Proyecto, gestión de riesgos; verificación y validación; modificaciones y problemas; y demás actividades involucradas en el proyecto.
-
Crear una estructura de desglose de trabajo (WBS) de las tareas realizadas por el grupo MoSimPa.
-
Importar la WBS a GitLab.
-
Generar repositorios en GitLab: un repositorio núcleo documental (que contendrá la WBS), y los repositorios necesarios de software (SW) y de hardware (HW); cada uno de los repositorios últimos tendrá un conjunto de issues que evolucionarán y sobre los cuales se dejarán evidencias del avance del proyecto.
Desde el repositorio núcleo se realizará la gestión a los demás repositorios del proyecto y se trasladarán peticiones a los demás repositorios. Para ello se configuran boards con estados para denotar el workflow a seguir de cada issue y etiquetas para indicar a qué tipo de issue corresponde. Con esto se logra que:
-
los issues sirvan como evidencia para resguardar los cambios históricos realizados,
-
los issues puedan moverse entre repositorios,
-
los issues puedan relacionarse entre ellos, ejemplo, issues de Casos de Pruebas para issue tipo hito de actividades de verificación y validación,
-
cada issue tenga al menos un commit referenciado, acompañado de una descripción,
-
las líneas de bases de configuración, por cada hito definido como trascendental, correspondan a un tag del repositorio correspondiente.
Se definirán workflows de requerimientos en la WBS del Proyecto, con el objetivo de contar con la estructura de requerimientos y ver los avances de los activos que se irán generando.
A continuación se procederá a detallar aspectos relacionados con la estrategia de ciclo de vida del proyecto que se ha propuesto, así como información referida a la organización y responsabilidades del equipo de proyecto, gestión y mecanismos de control y seguimiento del Proyecto MoSimPa.
6.1. Estrategia del Proyecto: Ciclo de Vida
El proyecto demanda, de acuerdo a las estimaciones realizadas a partir de un análisis inicial, una duración de 11 semanas, esto incluye: diseño, desarrollo y pruebas, con la documentación asociada.
Priorizando la transparencia, inspección, adaptación y participación del cliente, se ha decidido llevar adelante el Proyecto MoSimPa con un ciclo de vida de desarrollo del tipo Iterativo e Incremental, consistente en entregas parciales y prácticas ágiles de desarrollo a través de incrementos, que éstos a su vez están divididos en iteraciones. Éste modelo de ciclo de vida permite al proyecto gestionar objetivos y alcances cambiantes, para reducir la complejidad del proyecto o cuando la entrega parcial de un producto beneficia y genera valor para uno o más grupos de interesados sin afectar el entregable o conjunto de entregables finales.
Incrementos: Los incrementos resultarán en entregables que serán puestos a disposición de las partes interesadas. En cuanto a construcción, los incrementos generarán productos con funcionalidades concretas, que serán verificables. Cada incremento se divide a su vez en iteraciones o sprints.
Iteración: Es un período fijo de tiempo (2 semanas), donde se ejecutarán un conjunto de actividades, repetidas ciclo a ciclo, en donde se espera concretar la realización de módulos funcionales.
Se emplearán además eventos formales del marco de trabajo Scrum para las actividades de planificación, seguimiento y control del proyecto.
El proyecto se dividirá en 3 incrementos, de los cuales resultará en un conjunto de entregables con hitos definidos y en la declaración de líneas bases, según corresponda. Las líneas bases manifestarán objetivos concretos alcanzados y validados, los cuales tendrán una duración de 1 semana, 6 semanas, 4 semanas respectivamente. Cada incremento por lo tanto consistirán en hitos de acuerdos por las partes.
Incremento 1: será de modelado (Arquitectura del SW), planificación y elaboración de los activos documentales (Gestión de proyecto, gestión de la configuración, gestión de riesgos, plan de testing, requerimientos), cuyos entregables resultarán en planes y documentos de especificaciones.
Incremento 2: se especificarán, probarán e implementarán los casos de uso de acuerdo a las funcionalidades abordadas, se desarrollarán los casos de prueba, se implementarán los requerimientos según planificación, se evidenciará la gestión de los riesgos alcanzada.
Incremento 3: se finalizará con los desarrollos, se ejecutarán actividades de verificación y validación y se actualizarán los planes desarrollados en los incrementos anteriores.
En lo referente a la gestión del proyecto, se propone ejecutar actividades de planificación a diferentes niveles, reuniones de revisión, seguimiento y control. Asimismo, se administrará la configuración del producto en la medida que el mismo sea desarrollado, como así también la gestión de cambios, modificaciones y problemas.
Los incrementos y las tareas a realizar en cada iteración se encuntran disponible en: https://gitlab.com/mosimpa/documentation/-/milestones
6.2. Organización del Proyecto
6.2.1. Composición del Equipo de Proyecto y Responsabilidades
| Recurso | Rol | |||||||
|---|---|---|---|---|---|---|---|---|
| Líder de Proyecto | Líder Consultor de Procesos | Ingeniero de D&D de Hardware | Ingeniero de D&D de Software | Implementador de campo | Ingeniero Consultor de Procesos Sr. | Ingeniero Consultor de Procesos Jr. | Administrador de la Configuración | |
| MANDOLESI, Pablo | X | X | ||||||
| PÉREZ MEYER, Lisandro | X | X | ||||||
| AYMONINO, Andrés | X | |||||||
| POUSO, Marcelo | X | |||||||
| CASANOVA, Alejandro | X | |||||||
| MESSINA, Gabriel | X | |||||||
|
ROSSI, Esteban |
X | |||||||
| ALBORNOZ LAFERRARA, Josué | X | |||||||
| GRAMAJO, Rodrigo | X | |||||||
| CARDOSO, Paula | X | |||||||
La siguiente tabla lista a todos los miembros mencionados anteriormente, que serán responsables de asumir los roles definidos en el proceso de administración de la configuración, y de cumplir con las actividades definidas en el presente Plan.
| Rol | Responsabilidades |
|---|---|
| Líder de Proyecto |
|
| Administrador de la Configuración |
|
| Ingeniero de D&D de Software |
|
| Ingeniero de D&D de Hardware |
|
| Implementador de campo |
|
| Líder Consultor de Procesos |
|
| Ingeniero Consultor de Procesos |
|
6.3. Administración de la Configuración del Proyecto
El objetivo general de un Plan de Administración de la Configuración (CM) es documentar e informar a los interesados en el proyecto sobre las actividades de CM del proyecto, qué herramientas para CM se utilizan, cómo se almacenarán los ítems de configuración (IC) y la forma en que se gestionarán para promover el éxito del proyecto. El Plan de CM define la estructura del proyecto y métodos para:
- Identificar, definir y establecer las líneas de base.
- Controlar los cambios y versiones de los ICs.
- Generación de informes y registro de estado de los ICs y cualquier solicitud de cambios.
- Controlar el almacenamiento, la manipulación, y la entrega de los ICs.
El Plan de Gestión de la Configuración del Proyecto se encuentra disponible en: ../../ConfigurationManagement/PLN_Gestion_Configuracion/00.md.
6.4. Gestión de Riesgo
Las actividades de gestión de riesgos se irán ejecutando en cada fase del desarrollo del software, de acuerdo al ciclo de vida elegido, como se especifica en el plan de gestión de riesgos.
Los activos relacionados a la gestión de riesgo se encuentran en ../VerificationAndValidation/.
6.5. Testing
El plan de Testing se elabora para determinar la calidad en un desarrollo de software, y ver si cumple con los requerimientos solicitados al principio del proyecto. Encargándose de definir aspectos como los módulos o funcionalidades sujeto de verificación, tipos de pruebas, entornos, recursos asignados, etc.
El Plan de Testing se encuentra disponible en: LINK AL REPO DOCUMENTAL DEL PLAN DE TESTING EN GITLAB.
Los flujos de trabajo se encuentran definidos en el Plan de CM del Proyecto disponible en: ../../ConfigurationManagement/PLN_Gestion_Configuracion/00.md
6.6. Mecanismos de Control y Seguimiento
6.6.1. Control de Cambios
El Control de los Cambios es el proceso para la identificación, documentación, aprobación o rechazo y control de los cambios en las líneas bases del proyecto. En otras palabras, se utiliza para el control de los cambios de todos los aspectos de un Plan de Proyecto aprobado. Un efectivo control de los cambios, asegura que:
- Los cambios propuestos serán revisados y se analiza su impacto, antes de aprobarlos o rechazarlos.
- Todas las solicitudes y los cambios están debidamente documentados para proporcionar trazabilidad.
Los flujos de trabajo para el control de los cambios se encuentran disponibles en el Plan de Gestión de la Configuración del Proyecto, disponible en:* *https://gitlab.com/mosimpa/documentation/-/tree/master/docs/ConfigurationManagement
6.6.2. Gestión de Comunicaciones
| Tipo de Comunicación | Métodos/Herramientas | Frecuencia/Cronograma | Información | Participantes |
|---|---|---|---|---|
| Comunicación: | ||||
| Reunión de kick-off | Teleconferencia | Puesta en marcha del servicio de consultoría | Equipo del Proyecto + Grupo Consultor | |
| Reuniones de Avances | Teleconferencias | Semanalmente o a demanda | Estado del proyecto, problemas, riesgos, cambios en los requerimientos | Equipo del Proyecto + Grupo Consultor |
6.7. Arquitectura del software
Realizar arquitectura es la primera etapa en el proceso de diseño del software del proyecto MoSimPa. Es el enlace entre el diseño y el plan de requerimientos, ya que identifica los principales componentes estructurales en un sistema y la relación entre ellos. La salida del diseño arquitectónico consiste en un modelo que describe de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos.
La arquitectura de software se seleccionara y diseñara en base a los objetivos (alcances y restricciones) ver 3.1. Alcances.
Para consultar sobre la Arquitectura del software utilizada para resolver el proyecto MoSimPa, ver el siguiente link: ../VerificationAndValidation/.
Sección 7: Entregables y criterios de aceptación
7.1. Planificación de Hitos, Líneas Bases de Configuración, Entregables y Criterios de Aceptación
| Incremento | Iteración | Tipo de sprint [1] | Hito [2] | Tag de línea base [3] | Entregable | Criterio de aceptación | Responsable de aceptación |
|---|---|---|---|---|---|---|---|
| I1 | S1 | Planificación | NA [4] | NA | NA | NA | NA |
| S2 | Desarrollo | Hito 1 | NA | Plan de Proyecto | Validación del Cliente | ||
| Plan de Administración de la Configuración | Validación del Cliente | ||||||
| Plan de Gestión de Riesgos | Validación del Cliente | ||||||
| Especificación de Arquitectura de Software (SAS) | Validación del Cliente | ||||||
| Especificación de Requerimientos de Software (SRS) | Validación del Cliente | ||||||
| Plan de Verificación y Validación | Validación del Cliente | ||||||
| I2 | S1 | Desarrollo | NA | NA | NA | NA | |
| S2 | Desarrollo | NA | NA | NA | NA | ||
| S3 | Verificación y validación | Hito 2 | NA | Código Fuente de los requerimientos: REQ01 a REQ05 y REQ12, REQ13 y REQ14 | Informes de Pruebas de Integración, de Aceptación y Funcionales | ||
| Ejecutable de la aplicación | |||||||
| Plan de Gestión de Riesgos actualizado | Validación del Cliente | ||||||
| Especificación de Casos de Pruebas | Correctitud y Completitud de Casos de Prueba | ||||||
| Plan de Proyecto actualizado | Validación del Cliente | ||||||
| Especificación de Requerimientos de Software (SRS) actualizado | Validación del Cliente | ||||||
| Especificación de Arquitectura de Software (SAS) actualizado | Validación del Cliente | ||||||
| I3 | S1 | Desarrollo | NA | NA | NA | NA | |
| S2 | Verificación y Validación | Hito 3 | 2.0 | Código Fuente de los requerimientos: REQ06 a REQ11 y REQ15 | Informes de Pruebas de Integración, de Aceptación y Funcionales | ||
| Ejecutable de la Aplicación | |||||||
| Plan de Administración de la Configuración actualizado | Validación del Cliente | ||||||
| Plan de Gestión de Riesgos actualizado | Validación del Cliente | ||||||
| Especificación de Casos de Pruebas | Correctitud y Completitud de Casos de Prueba | ||||||
| Plan de Proyecto actualizado | Validación del Cliente | ||||||
| Especificación de Requerimientos de Software (SRS) actualizado | Validación del Cliente | ||||||
| Especificación de Arquitectura de Software (SAS) actualizado | Validación del Cliente |
7.2. Estructura de Desglose de Trabajo (WBS)
La Estructura de Desglose del Trabajo (WBS, Work Breakdown Structure) del Proyecto MoSimPa es un resultado orientado al análisis del trabajo involucrado en el proyecto y define el alcance total del mismo.
La WBS es una jerarquía del trabajo que se necesita organizar, desde la meta del proyecto hasta las tareas o subtareas. En el nivel superior se encuentra la meta final del proyecto, el segundo nivel contiene los objetivos del proyecto, el tercer nivel contiene las actividades del proyecto y dependiendo del tamaño y complejidad de cada actividad la estructura puede contener un cuarto nivel que describa las tareas.
El foco fundamental en la elaboración del WBS está en pensar en los resultados finales, entregables, más allá de las acciones concretas. Para ello es aconsejable estructurar la WBS orientado al ciclo de vida elegido para el desarrollo (véase 6.1. Estrategia del Proyecto: Ciclo de Vida)
Para visualizar los Issues que representa la WBS del proyecto ver el siguiente link : https://gitlab.com/groups/mosimpa/-/issues.
Si quisiera observar o filtrar algún Issues en particular de la WBS del proyecto MoSimPa puede dirigirse al siguiente link que explica los pasos a seguir: https://docs.gitlab.com/ee/user/search/index.html#filtering-issue-and-merge-request-lists.
7.3. Cronograma
La especificación del desglose de la estructura de trabajo se realiza cada inicio de incremento, donde se asignan tiempos, recursos y roles.
Para visualizar el diagrama de Gantt del Proyecto MoSimPa se utilizara la app GanttLab, para acceder se puede hacer mediante el siguiente link: https://app.ganttlab.com/.
Seleccionar la opción GitLab.
Para poder utilizar la app GanttLab con el usuario de GitLab, deberá tener activado su Personal Access Tokens, para poder activarlo se recomienda el siguiente link: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html.
Seleccionar “Created by me”, luego en la pestaña “By project”.
Escribir en el buscador “mosimpa/documentation”. Al seleccionar podrá observar el diagrama de Gantt del proyecto.
Sección 8: Apéndice
8.1. Términos y Definiciones
En este enlace se puede consultar el glosario de términos y definiciones ide ocurrencia.
8.2. Historial de Cambios
El historial de los cambios puede consultarse en la historia de las revisiones del Proyecto MoSimPa, o bien mediante la identificación de las versiones taggeadas según el sistema de control de versionado empleado. La descripción de los cambios estará especificada en los comentarios del commit correspondiente.