Anexo 1 - PMP Grupo 8

Ingeniería de Sistemas
PLAN DE ADMINISTRACIÓN DE PROYECTO

TÍTULO
Software de apoyo para la toma de decisiones financieras de Pymes y MiPymes en la localidad de Usme en alian-
za con el Consultorio Contable Javeriano.
OBJETIVO GENERAL
Desarrollar software de operación financiera “user friendly”, para emprendedores de bajos recursos con poca es-
colaridad financiera.
ESTUDIANTE(S)
Luisa Yurani Contreras Vergel ____________________________________
Celular Teléfono fijo Correo Javeriano
320-909-6225 6791104 luisa.contreras@javeriana.edu.co
Juan Sebastian Pulecio Romero____________________________________

316-877-8856 7224447 j-pulecio@javeriana.edu.co
Jairo Hernan Vanegas Garcia _____________________________________

300-670-4506 n/a jairo.vanegas@javeriana.edu.co
DIRECTOR
Cesar Julio Bustacara Medina
Correo Javeriano Empresa donde trabaja y cargo
cbustaca@javeriana.edu.co; Pontificia Universidad Javeriana; Profe-
sor Departamento de Sistemas
5/23/2022
Pontificia Universidad Javeriana Plan de administración del proyecto Grupo 8
Contenido
1 VISTA GENERAL DEL PROYECTO .............................................................................. 5

1.1 SUPUESTOS Y RESTRICCIONES DEL PROYECTO .......................................................... 5
1.2 EVOLUCIÓN DEL PLAN .............................................................................................. 5
2 CONTEXTO DEL PROYECTO........................................................................................ 6

2.1 LENGUAJES Y HERRAMIENTAS.................................................................................. 6
2.1.1 Lenguajes de modelado.............................................................................................. 6
2.1.2 Lenguajes de programación ...................................................................................... 6
2.1.3 Marcos de trabajo para desarrollo............................................................................ 6
2.1.4 Productos de software................................................................................................ 7
2.1.5 Herramientas de desarrollo ....................................................................................... 7
2.1.6 Herramientas administrativas ................................................................................... 7
2.2 PLAN DE ACEPTACIÓN DEL PRODUCTO ..................................................................... 7
2.2.1 Fase de Concepción ................................................................................................... 7
2.2.2 Fase de Construcción ................................................................................................ 8
2.2.3 Fase de Implantación ................................................................................................. 8
2.2.4 Fase de Documentación ............................................................................................. 9
2.3 ORGANIZACIÓN DEL PROYECTO Y COMUNICACIÓN .................................................. 9
2.3.1 Interfaces externas ..................................................................................................... 9
2.3.2 Organigrama y descripción de roles ....................................................................... 10
3 ADMINISTRACIÓN DEL PROYECTO .......................................................................... 13

3.1 INICIO DEL PROYECTO ............................................................................................. 13
3.1.1 Entrenamiento del personal ..................................................................................... 13
3.1.2 Infraestructura ......................................................................................................... 13
3.2 PLANES DE TRABAJO DEL PROYECTO ..................................................................... 14
3.2.1 Descomposición de actividades ............................................................................... 14
3.2.2 Calendarización ....................................................................................................... 15
3.2.3 Responsables ............................................................................................................ 17
4 MONITOREO Y CONTROL DEL PROYECTO .............................................................. 18

4.1 ADMINISTRACIÓN DE REQUERIMIENTOS ................................................................. 18
4.2 MONITOREO Y CONTROL DE PROGRESO ................................................................. 18
5 PROCESOS DE SOPORTE ........................................................................................... 20

5.1 ANÁLISIS Y ADMINISTRACIÓN DE RIESGOS ............................................................. 20
5.2 ADMINISTRACIÓN DE CONFIGURACIÓN Y DOCUMENTACIÓN .................................. 21
5.3 CONTROL DE CALIDAD ........................................................................................... 23
6 ANEXOS..................................................................................................................... 26
Página 1
7 REFERENCIAS ........................................................................................................... 27
Página 2
Lista de figuras
Ilustración 1 Organigrama ....................................................................................................... 12

Ilustración 2 WBS SPMP ........................................................................................................ 14
Ilustración 3 WBS SRS ........................................................................................................... 15
Ilustración 4 WBS SDD .......................................................................................................... 15
Ilustración 5 Definición de requisitos...................................................................................... 18
Ilustración 6 Control de cambios requisitos ............................................................................ 18
Ilustración BPMN Gestión de riesgos .................................................................................... 20
Ilustración BPMN cambio configuración Quasar .................................................................. 22
Ilustración BPMN Control de calidad general ....................................................................... 23
Ilustración BMPN Control de calidad documentación ........................................................... 24
Página 3
Lista de tablas
Tabla 1 Interfaces externas ...................................................................................................... 10

Tabla 2 Descripción de roles ................................................................................................... 11
Tabla 3 Calendarización .......................................................................................................... 17
Tabla 5 Ramas del repositorio de versiones ............................................................................ 22
Tabla 6 Plan de control de calidad .......................................................................................... 25
Página 4
1 Vista General del Proyecto
1.1 Supuestos y restricciones del proyecto

El consultorio contable facilita la interacción con el departamento de tecnologías de la infor-
mación (DTI) para proveer los servidores necesarios en la aplicación a desarrollar. Con esto
se facilita la implementación en los usuarios afiliados al colegio San Gregorio Hernández que
tengan un emprendimiento. Pues deben ser determinados con herramientas y acciones reali-
zadas por el consultorio contable como lo son:
Usuarios: El consultorio contable será el encargado de determinar los usuarios de la aplica-
ción, estos son quienes tengan vínculo con el colegio san Gregorio Hernández y estén ubica-
dos en la localidad de Usme.
Capacitación teórica: El consultorio contable está dispuesto a capacitar los usuarios de la
aplicación.
Administración post desarrollo: El departamento de contaduría pública es quien se encargará
de administrar el manejo y uso del aplicativo por medio de su asociación con DTI.
Mantenimiento continuo: El departamento de contaduría pública será el encargado en asocia-
ción con DTI de brindar mantenimiento continuo y soporte al aplicativo.
El consultorio contable Javeriano también esta informado de los recursos e infraestructura
necesarias para llevar a cabo el proyecto, esto incluye la necesidad de servidores para el des-
pliegue de la herramienta por medio del apoyo del departamento de tecnología e información
(DTI) y el espacio en la web perteneciente a la universidad para la debida distribución y pos-
terior implementación en los computadores de los usuarios finales. Teniendo en cuenta esta
información, el departamento de contaduría pública es el encargado de realizar las gestiones
necesarias con el área de DTI para llevar a cabo las necesidades del proyecto en su imple-
mentación y despliegue.
1.2 Evolución del plan

Conforme avance el proyecto este documento sufrirá cambios, para el desarrollo co-
rrecto donde se pretende cumplir de manera precisa con los parámetros escritos. Estos
cambios serán informados a los responsables de cada sección, para su respectiva ac-
tualización tanto en el contenido como en las tablas, diagramas correspondientes e
historial de versiones. Además, para la realización de estos cambios, todos los inte-
grantes del equipo “Seshat” estarán informados y deberán estar de acuerdo con este.
Página 5
2 Contexto del proyecto
2.1 Lenguajes y Herramientas

2.1.1 Lenguajes de modelado
Para los procesos de modelado de software se ha escogido UML[1] en su versión 2.5.1 como
lenguaje de modelado.
Para los procesos administrativos y de negocio se escogió BPMN[2] en su versión 2.0 como
la notación para modelarlos.
2.1.2 Lenguajes de programación

El lenguaje principal de programación que se usará en el desarrollo del proyecto es Javascript
conforme a las especificaciones de ECMAscript 6[3]. Sin embargo, con el objetivo de tener
mejores prácticas en la codificación se usará Typescript[4], el cual es un lenguaje de progra-
mación fuertemente tipado que se basa en Javascript pero que gracias a su enfoque en los
tipos puede captar errores en tiempo de desarrollo que solo se encontrarían en tiempo de eje-
cución solo con Javascript.
Para el manejo de consultas y modificaciones en la base de datos se usará SQL conforme al
estándar ISO/IEC 9075:2013 el cual es soportado por la versión de PostgreSQL que se usará
en el proyecto como base de datos principal.
2.1.3 Marcos de trabajo para desarrollo

Para el despliegue del frontend del sistema se ha escogido el framework Quasar[5] gracias a
la facilidad de desarrollo que presenta debido a la amplia galería de componentes gráficos
como formularios, modales y diálogos listos para el uso y su vinculación con el framework
Vuejs[6] con lo que permite vinculación de los elementos gráficos con el controlador en
tiempo real. Además de estas características este framework también nos permite desplegar
Vuejs en el modo de Server Side Rendering (SSR) que permite servir las paginas con toda la
potencia de Vuejs como framework MVC, con un cliente ligero que además se puede instalar
en el navegador del usuario como PWA soportando de esta forma varios requisitos del siste-
ma al mismo tiempo desde un solo marco de trabajo.
Quasar permite también la función de servidor web por lo que este aspecto también queda
cubierto gracias a este framework.
Para manejar la conexión con la base de datos, soportando el atributo de calidad de extensibi-
lidad, se usará TypeORM[7] como ORM encargado de abstraer la capa de datos de la imple-
mentación de la base de datos que use el proyecto en su salida y en su tiempo de vida. Esto
permite que los diferentes grupos que trabajen en el sistema tiempo después de nuestra salida
del proyecto puedan usar tecnologías diferentes de bases de datos.
Para la implementación de pruebas unitarias para garantizar la calidad del código fuente se
usara el framework Jest[8].
Página 6
2.1.4 Productos de software

Como se mencionó anteriormente la base de datos escogida para el despliegue del sistema es
PostgreSQL versión 13 que será soportada en un servidor gratuito para el entorno de desarro-
llo en Heroku[9] y en producción será instalada en los servidores dispuestos por la DTI.
2.1.5 Herramientas de desarrollo

Para el desarrollo con estos lenguajes y frameworks escogimos el IDE WebStorm[10] de la
empresa Jet Brains, que presenta una excelente integración con las características de Types-
cript y el framework Quasar.
Este IDE como otras herramientas en este proyecto tienen modelos de licencia de pago, sin
embargo, gracias al GitHub Student Developer Pack[11], podemos tener licencias estudianti-
les con las que poder usar estas herramientas de forma gratuita por la duración del proyecto.
Para el control de versiones del código se usará un repositorio alojado en GitHub[12] el cual
será manejado a través de la herramienta GitKraken[13] que nos proporciona una interfaz
gráfica de GIT, facilitando el uso de ramas y los procesos de control sobre las versiones del
software.
Para el despliegue de los desarrollos incrementales para las pruebas con los interesados se
usará la plataforma como servicio Heroku[14] en uno de sus nodos gratuitos.
2.1.6 Herramientas administrativas

Los diferentes documentos de texto y presentaciones se crearán usando la suite ofimática de
Microsoft Office, en especifico Word y PowerPoint. Para el manejo de la bibliografía y las
referencias en los documentos se usará el manejador de referencias Zotero[15].
Para la organización y comunicación del grupo la principal herramienta de mensajería es
WhatsApp[16] a través del grupo creado con este fin. Las reuniones, en su gran mayoría vir-
tuales, se agendarán y realizaran en Microsoft Teams[17].
Para el modelado de procesos y diseños de software se usarán las herramientas graficas pro-
vistas por draw.io[18] y Bizagi[19].
2.2 Plan de Aceptación del Producto

Para este documento se tomarán en cuenta los entregables relacionados directamente con el
cliente y con las métricas especificas de cada elemento de cara al cliente.
2.2.1 Fase de Concepción

Listado de requisitos no funcionales
Debido a que la funcionalidad del sistema se hereda directamente de la macro SOFI un crite-
rio de aceptación de este entregable es la completitud con la que los requisitos funcionales
cubran la funcionalidad de la macro, la métrica entonces sería el número de casos de uso
descrito por los requisitos entre los casos de uso en SOFI. La medida de aceptación entonces
debería ser superior o igual a 1.
Página 7
Listado de requisitos no funcionales

Por la naturaleza de estos requisitos y teniendo en cuenta que no se puede hacer una compa-
ración justa con la macro SOFI, este criterio de aceptación se reduce a la capacidad con la
que el equipo haya captado las necesidades del cliente. Es por esto por lo que la métrica de
este entregable se define como numero de requisitos no funcionales aprobados por el cliente
sobre el numero total de requisitos no funcionales en el listado. Como medida de aprobación
se espera un valor por encima de 0.89 dejando espacio para negociar requisitos entre los in-
teresados y el equipo del proyecto.
2.2.2 Fase de Construcción

Desarrollo incremental
En cada iteración el desarrollo incremental se refiere a la implementación de las característi-
cas y funcionalidad que da soporte a una lista de requisitos escogidos para ser soportados en
esa iteración. Debido a que la implementación soporta varios requisitos a la vez, no es posible
determinar la validez de un desarrollo incremental con una métrica global, por lo que se divi-
de este entregable para su aceptación en partes individuales que van a ser validadas mediante
encuestas a los interesados que prueben el desarrollo incremental.
Es importante aclarar que cada parte individual se refiere a una parte de la implementación
que soporta uno o más requisitos y la validación se logra con el soporte exitoso del o los re-
quisitos en cuestión. Dichas partes serán evaluadas mediante preguntas en la encuesta y la
métrica de aceptación se define como el numero de respuestas validando la parte sobre el
numero de respuestas total.
Para lograr la aceptación de cada una de las partes individuales es necesario que este alcance
una medida superior o igual a 0.8. Se recuerda que las partes que logren esta medida pasaran
a estar validadas y por consecuente a ser parte de la implementación final que pasará a pro-
ducción.
2.2.3 Fase de Implantación

Servidor web con base de datos integrada
El objetivo de la fase de implantación es entregar el servidor completamente integrado y fun-
cional en los recursos dispuestos por la DTI. Teniendo en cuenta que al momento de redac-
ción de este documento estos recursos se encuentran indeterminados, las métricas de acepta-
ción se dejaran en términos relativos para ser especificados en cuanto se hayan definido los
recursos con los que se pueda trabajar.
Aclarado esto, y teniendo en cuenta que en el alcance de este proyecto se tiene planeado un
programa Beta con algunos usuarios elegidos por el Consultorio Contable, una buena métrica
es la capacidad del sistema de soportar en su totalidad a estos usuarios. Por eso la primera
métrica de aceptación se define como el numero de usuarios creados y activos sobre el núme-
ro de usuarios escogidos por el Consultorio Contable. La medida de aceptación para esta
métrica debe ser de 1 para ser aceptada.
En segundo lugar, no solo es necesario probar que la implantación del sistema funciona en
primera instancia, por eso la segunda métrica a evaluar se define como número de días en que
ha fallado el sistema sobre el número de días en ejecución, esta medida se tomará durante los
Página 8
primeros 30 días desde el lanzamiento del sistema. La medida adecuada para la aceptación
debe ser de un 0.95 o mayor para ser aceptada por el cliente.
Para efectos de la métrica se define un día en que ha habido fallos como un día en el que uno
o mas usuarios han reportado fallos en el sistema, como la incapacidad de ingresar al mismo
o la falla al realizar un caso de uso.
2.2.4 Fase de Documentación

Código fuente y documentación
Respecto a este entregable es importante que la rama de producción del repositorio, la cual
será entregada en formato zip al cliente, cumpla con la totalidad de las pruebas unitarias.
Además de esto la métrica de aceptación para la documentación del código tiene que ver con
el número de funciones documentadas en el código con el formato JSdoc sobre el número
total de funciones. La medida de esta métrica para la aceptación es de un 0.8 teniendo en
cuenta que algunas funciones auxiliares solo serian ruido en la documentación generada.
Manual de usuario
La mejor métrica con la que el cliente puede aceptar este entregable es la capacidad de este
para documentar los casos de uso para su consulta por parte del usuario. Para esto se pondrá
el prototipo de manual a disposición de los usuarios, luego se les pedirá que evalúen cada
caso de uso en sentido de si se ha entendido o no el procedimiento para realizarlo. Un caso de
uso esta validado si la totalidad de los evaluadores acuerdan que pueden entenderlo en el
manual. Esto define la métrica como el numero de casos de uso validados sobre el total de
casos de uso que necesitan documentación para el usuario. Naturalmente la medida de acep-
tación de esta métrica es 1.
Videos de instrucción para el usuario
Este entregable se desprende directamente del entregable Manual de usuario pues este servirá
de guion para cada uno de los videos en donde se explicará uno o mas casos de uso del ma-
nual, por esta razón la aceptación del manual implica directamente la aceptación de los vi-
deos. Sin embargo, debido al contenido audiovisual se le entregaran los videos al cliente para
que los revise y pueda censurar alguna parte o un video completo, esta censura deberá ser
corregida por el equipo con los comentarios del cliente y se entregara el producto final des-
pués de solo una iteración de este proceso.
2.3 Organización del Proyecto y Comunicación

2.3.1 Interfaces externas
Entidad Encargado Descripción
Facultad de ingeniería Alicia Mercedes Arenas Docente encargada del pro-
Valderrama yecto social universitario en
la facultad de ingeniería,
asociada con el consultorio
contable gracias a este pro-
grama.
Página 9
Director de la tesis en la que

se desarrollara el proyecto
Cesar Julio Bustacara Medi-
actual.
na
Facultad de contaduría Jesús Edmundo Rueda Gue- Profesor encargado del

rrero trabajo social en el colegio
san Gregorio Hernández y
encargado de ser el vínculo
con el consultorio contable
en las actividades sociales
que se realizan en el colegio
Braulio Adriano Ramírez Director de la carrera de
Castro contaduría pública, encarga-
do de administrar el desarro-
llo del consultorio contable.
Consultorio contable jave- Carlos Andres Corredor Director del consultorio
riano Herrera contable, encargado de dar
vía a proyectos sociales.
Asociado al colegio san
Gregorio Hernández por
intermediación del profesor
Jesús para la implementa-
ción de trabajo social en el
lugar.
Tabla 1 Interfaces externas
2.3.2 Organigrama y descripción de roles

Rol Encargado Descripción
Asesor de contaduría publi- Braulio Adriano Ramírez Director del programa de
ca Castro contaduría pública, encarga-
do de brindar asesoría para
cumplir con los requeri-
mientos contables necesa-
rios en la elaboración del
proyecto.
Promotor Jesús Edmundo Rueda Gue- Profesor encargado del
rrero proyecto social que el con-
sultorio contable está ejer-
ciendo en el colegio san
Gregorio Hernández y pro-
motor de la iniciativa para la
Página 10
aplicación en Usme.
Asesor de facultad de inge- Alicia Mercedes Arenas Profesora encargada del
niería Valderrama proyecto social por parte de
la facultad de ingeniería.
Director de proyecto Cesar Julio Bustacara Medi- Encargado de brindar las
na herramientas, capacita-
ciones y elementos nece-
sarios para desarrollar la
aplicación.
Director de desarrollo Jairo Hernan Vanegas Gar- Encargado de brindar las
cia herramientas, capacitaciones
y elementos necesarios para
desarrollar la aplicación
Director de bases de datos Juan Sebastián Pulecio Ro- Encargado de determinar
mero los datos e información
contable necesaria para el
desarrollo del proyecto.
Director de documentación Luisa Yurani Contreras Encargada de documen-
Vergel tar la aplicación y su fun-
cionalidad, así como la
parte teórica del proyec-
to.
Director de configuración Jairo Hernan Vanegas Gar- Encargada de brindar
cia asesoría sobre la presen-
tación y requisitos que
debe tener la aplicación.
Jefe de calidad Luisa Yurani Contreras Encargado de verificar el
Vergel estado de la documenta-
ción e infraestructura del
proyecto.
Tabla 2 Descripción de roles
Página 11
Ilustración 1 Organigrama
Como podemos ver en el organigrama anterior el equipo se ha distribuido de forma orgánica
de acuerdo con sus capacidades individuales y en subordinación directa del director de pro-
yecto de grado. Los integrantes del grupo están en el mismo nivel de jerarquía por lo que esto
obliga a que se vigilen, auditen y regulen entre sí.
Página 12
3 Administración del Proyecto
3.1 Inicio del proyecto

3.1.1 Entrenamiento del personal
El director de desarrollo tiene amplia experiencia con el lenguaje Typescript y el framework
Quasar por lo que se ha designado como capacitador para los demás integrantes del equipo de
desarrollo. Su función consiste en identificar las competencias de los integrantes del equipo y
priorizar el entrenamiento de las habilidades que se adapten fácilmente a dichas competencias
y a las necesidades del proyecto teniendo en cuenta las restricciones de tiempo.
Inicialmente se ha llegado al compromiso de realizar sesiones de capacitación con una dura-
ción de 3 horas los fines de semana a finales del año 2021 y principios de 2022 justo antes de
iniciar el proyecto formalmente en el contexto del semestre universitario 2022-1. Con este
esquema se espera lograr capacitar al equipo en los conceptos básicos del lenguaje y los arte-
factos del framework, logrando también la especialización de los miembros del equipo en
ámbitos como diseño de interfaz gráfica, desarrollo de pruebas, procesamiento de informa-
ción e integración de componentes propios del lenguaje y el framework mencionados.
Cada integrante del equipo manifestó capacidad para realizar las entrevistas y encuestas dis-
puestas para la evaluación y validación de los desarrollos incrementales con los interesados,
sin embargo, se designa al jefe de calidad como el encargado de desarrollar e implementar
dichos artefactos para el desarrollo de la fase de construcción.
3.1.2 Infraestructura
Cada uno de los integrantes del equipo posee los equipos de computo que necesitaran para el
desarrollo y la realización de sus funciones de forma individual y son responsables de provi-
sionar los medios para la conexión a internet y las instalaciones en donde se realizaran dichas
tareas.
Respecto a la infraestructura de desarrollo con la que empezará el proyecto, el director de
desarrollo se encargará de crear e inicializar el repositorio en GitHub para el código fuente,
configurar el equipo de trabajo en la plataforma y asignar permisos para los integrantes del
grupo. En el también esta la responsabilidad de administrar el repositorio.
Para el servicio de PAAS en Heroku el director de desarrollo creará la cuenta del proyecto y
aprovisionará los recursos necesarios en procesamiento y memoria para el alojamiento y des-
pliegue del servidor de pruebas para los desarrollos incrementales. Los recursos se limitarán a
los ofrecidos de forma gratuita en la plataforma, sin embargo, por política de la plataforma el
creador de la cuenta debe ingresar información personal y financiera por lo que será el único
autorizado para ingresar y manejar los recursos, así como el despliegue de los servicios.
Si bien el repositorio de código fuente es un recurso compartido por todos los integrantes del
equipo, el servidor de pruebas solo podrá ser manejado por el director de desarrollo. Esta
condición obliga a que cada integrante del grupo despliegue de forma local una copia de la
base de datos y del servidor de pruebas en sus equipos de desarrollo. El director de desarrollo
se encargará de proveer apoyo técnico para la instalación de estos recursos.
Página 13
Si bien no es condición necesaria para el inicio del proyecto en términos técnicos, es deseable
que se encuentren o se inicien los acercamientos con la DTI a través del Consultorio Contable
para definir y obtener acceso pronto a los recursos que la universidad asigne al proyecto. Esto
con el objetivo de poder realizar la instalación de la base de datos y del servidor de pruebas
en estos recursos de forma paralela al entorno de desarrollo descrito en los párrafos anteriores
en Heroku. De esta forma se pueden realizar pruebas técnicas con los recursos en los que se
desplegará el sistema en la fase de Implantación en paralelo a las pruebas con los interesados
en medio de la fase de Construcción.
3.2 Planes de Trabajo del Proyecto

Para el desarrollo de este numeral, que describe como se llevará a cabo la ejecución del pro-
yecto, para ello, se tomarán en cuenta
3.2.1 Descomposición de actividades

Este ítem describe la descomposición de actividades o WBS. La Work Breakdown Structure
consiste en un documento que intenta reflejar, en un diagrama, aquellos paquetes de trabajos
que deberán realizarse para la realización efectiva de un proyecto en particular. De este mo-
do, se detallan las actividades individuales que cada uno de los que integran el proyecto debe
realizar, con la inclusión de los paquetes de trabajo propios de la gestión de este. Como con-
secuencia de ello, será posible visualizar, de modo concreto, la planificación de los paquetes
de trabajo que se encuentran involucrados en la realización de dicho proyecto.[20]
Ahora, teniendo en cuenta esta definición, a continuación, se tendrán en cuenta cada uno de
los entregables para el desarrollo de los WBS.
Ilustración 2 WBS SPMP

En el WBS SPMP, se puede evidenciar que se tienen en cuenta 4 grandes tareas, las cuales
incluyen: supuestos y restricciones, estructura interna, planes de trabajo y procesos transver-
sales.
Página 14
Ilustración 3 WBS SRS

Ahora bien, en el WBS SRS podemos observar que se tienen en cuenta 5 items principales los
cuales se definen como: supuestos y restricciones, interfaces, actores/stakeholders, modelo de
dominio/requisitos funcionales y los requisitos no funcionales.
Ilustración 4 WBS SDD

Por último, en el WBS, se tienen en cuenta 6 tareas que contendrán lo suficiente en cuanto a
contenido del documento, lo cual tiene en cuenta: vista lógica del sistema, vista física del
sistema, estructura del sistema, persistencia e interfaz del usuario.
Cabe resaltar que estas tareas reflejan las actividades más importantes a desarrollar para la
completitud de los documentos, sin embargo, estos documentos cuentan con las diferentes
listas de tablas e ilustraciones, anexos y bibliografía.
3.2.2 Calendarización
Para la calendarización se realizó una tabla que contiene los entregables con su respectiva
descripción y fecha de entrega. A continuación, se encuentra la tabla 3 con la información
consignada.
Entregable Cantidad Descripción Cliente Fecha Herramienta

de determina-
ción
Página 15
SPMP 1 El SPMP (Plan de Jaime 7/11/2021 Cronograma de

Administración de Andrés actividades
Proyectos de Softwa- Pavlich
re) es un documento Mariscal,
en el cuál se describe Cesar
cuidadosamente cada Julio
detalle de la elabora- Bustacara
ción del producto de Medina
software con el fin de
especificar cada una
de sus etapas de ela-
boración y así evitar
al máximo el riesgo
de errores o despropó-
sitos del proyecto.[21]
SRS 1 Un SRS es un docu- Jaime 15/11/2021 Cronograma de
mento cuyo propósito Andrés actividades
es proporcionar una Pavlich
descripción completa Mariscal,
de un producto de Cesar
software a desarrollar, Julio
incluyendo su propó- Bustacara
sito, los principales Medina
procesos de negocio
que serán soportados,
características, pará-
metros clave de ren-
dimiento y compor-
tamiento.[22]
SDD 1 La Descripción del Cesar Por definir Cronograma de
Diseño de Softwa- Julio actividades
re (SDD por sus siglas Bustacara
en inglés) es una des- Medina
cripción escrita de
un producto de soft-
ware, que un diseña-
dor de software escri-
be con el fin de dar un
equipo de desarrollo
de softwa-
re orientación general
para la arquitectura de
un proyecto de soft-
ware. [23]
Página 16
Tabla 3 Calendarización
3.2.3 Responsables
Para el avance de cada una de las actividades, se encuentran cada uno de los integrantes del
equipo “Seshat”, es decir, tomamos el proyecto como propio por lo que hacemos una obliga-
ción el buen desempleo de las actividades. Además, se tienen en cuenta las reglas del equipo
descritas en el Anexo 1 [Reglas de equipo Seshat].
Página 17
4 Monitoreo y Control del Proyecto
4.1 Administración de Requerimientos

En esta sección, se verán a manera de diagrama BPMN donde hemos divido en dos procesos
dicha administración de requerimientos, donde en un primer momento se realiza la definición
de los requisitos y en un segundo momento se realizan los cambios de los mismos, como se
muestra a continuación en la ilustraciones 5 y 6:
Ilustración 5 Definición de requisitos
Ilustración 6 Control de cambios requisitos
4.2 Monitoreo y Control de Progreso

Se tendrán en cuenta las métricas de Funcionalidad, calidad y puntualidad en la medición del
progreso del proyecto:
Funcionalidad: La entrega cumple con la planeación que se había establecido previamente y
emite los resultados esperados en su despliegue e implementación.
Calidad: Se cumple con los estándares necesarios en la implementación y despliegue cum-
pliendo con estándares de calidad, fiabilidad, configuración de software y ciclo de Vida.
Puntualidad: los Elementos necesarios para el desarrollo del proyecto son entregados de ma-
nera oportuna para que se conozca a su debido tiempo el progreso de este.
El progreso será tenido en cuenta bajo estos tres aspectos, para los cuales, se tendrá en cuenta
que en caso de presentarse inconvenientes, el grupo encargado del proyecto y su desarrollo se
encargara de aplicar los cambios necesarios para cubrir los inconvenientes surgidos en alguna
Página 18
validación de requisitos o en algún teste ejecutado tanto en la aplicación como en la docu-

mentación de la misma.
El progreso será tenido en cuenta para establecer entregables y el cumplimiento de requisitos
tanto funcionales como no funcionales hasta la fecha programada de entrega.
Página 19
5 Procesos de Soporte
5.1 Análisis y Administración de Riesgos

Se decidió usar el estándar ISO 31000 [24]en la medida de que se usarán las etapas que estas
normas siguen, además la manera en la que los riesgos se evaluarán será cualitativamente. El
responsable del plan de riesgos será el líder del equipo.
Este estándar determina las siguientes actividades:
• Implantar el contexto: Se toman en cuenta los posibles riesgos internos-
• Identificar Riesgos: Se tendrán en cuenta los riesgos que vayan en contra del desarro-
llo del proyecto, de la comunicación y el ambiente de trabajo en el equipo.
• Analizar Riesgos: Se realizará un proceso de clasificación con el fin de identificar las
distintas características, como la probabilidad de ocurrencia, consecuencias y nivel de
cada riesgo.
• Evaluar Riesgos: Se realizará la priorización de los riesgos de acuerdo con el impacto
y probabilidad de ocurrencia, teniendo en cuenta el análisis anterior.
• Tratar Riesgos: Una vez identificados los riesgos, se seleccionará el plan a aplicar.
• Monitoreo y control: Se realiza de manera transversal durante todo el desarrollo del
proyecto, para detectar cambios que tengan que ver con la gestión de riesgos.
En la siguiente ilustración, BPMN Gestión de riesgos se puede notar cada una de las activi-
dades explicadas anteriormente.
Ilustración 7 BPMN Gestión de riesgos

Como se puede ver, el proceso comienza cuando se implanta el contexto del riesgo que tiene
como fin denotar el alcance del plan de gestión de riesgos, una vez identificado el riesgo, se
realiza un análisis de este donde se tienen en cuenta las variables explicadas anteriormente,
luego de esto se evalúan los riesgos para su posterior tratamiento, por último, en el tratamien-
to de riesgos, se aplicarán las decisiones tomadas para corregir dicho riesgo. Además, se tiene
una tarea activa durante todo el proyecto la cual consiste en el monitoreo constante de los
riesgos identificados. Para observar los riesgos identificados junto con los ítems de relevancia
ver Anexo 2 [Matriz de Riesgos].
Página 20
5.2 Administración de Configuración y Documentación

Principalmente los artefactos de configuración en el servidor de pruebas del entorno de desa-
rrollo son los recursos que se van a desplegar para el nodo de procesamiento y para la base de
datos en Heroku.
Para el nodo de procesamiento se aprovisionan los siguientes recursos:
• Memoria RAM de 512 MB
• 2 hilos de procesamiento
• El proceso de pone en estado de suspensión en caso de que no reciba señales du-
rante 30 minutos, en caso de recibir una señal después de este periodo vuelve a
estar activo después de un pequeño retraso.
Para la base de datos se aprovisionan los siguientes recursos:
• Límite de 20 conexiones.
• Limite de 10.000 filas por tabla.
Se especifican estos recursos en este espacio debido a que por restricción de presupuesto esta
configuración permanecerá estática durante la fase de Construcción.
Respecto al código, como se ha mencionado antes en este documento, las versiones del códi-
go se mantendrán y administrarán en el repositorio alojado en GitHub. Antes de describir las
diferentes ramas que conformarán el sistema de versiones del código, se describirán los pro-
cesos transversales a todas las ramas.
Utilizando las Acciones de GitHub se creará un archivo de configuración bajo el directorio
“GitHub/worflows” para cada una de las ramas en el repositorio. Este archivo configura el
proceso de integración en donde se instalan las dependencias del software y se realizan las
pruebas descritas en el archivo. Con esta configuración y la ayuda de las pruebas unitarias de
Jest se limitan las actualizaciones en el servidor a las ramas que pasen todas las pruebas acu-
muladas, asegurando así que el commit no romperá ninguno de los incrementos pasados.
En la siguiente tabla se describen las diferentes ramas que constituirán el repositorio, se toma
como base el modelo Gitflow con cambios por ejemplo en la eliminación de la rama de hotfix
debido a que el código de producción solo será usado en la fase de Implantación y no será
cambiado hasta que otro equipo remote el desarrollo del sistema.
Nombre Descripción Encargado Ramifica Combina en
de
master Rama principal en la que se Director de N/A N/A
encuentra el código listo para desarrollo
producción.
develop Rama que se deriva de master, Todo el equipo master test
contiene el código estable de las
nuevas características que pue-
den pasar a pruebas según el
esquema de desarrollo incre-
mental.
Página 21
test Rama que contiene las caracte- Jefe de calidad develop master
rísticas que van a ser probadas
con los interesados, se despliega
en el servidor de pruebas, las
características validadas se
combinan en la rama master
feature Conjunto de ramas que se crean Todo el equipo develop develop
y destruyen en función del desa-
rrollo de las características, en
estas se desarrolla el grueso del
código y solo se combinan una
vez hayan pasado todas las
pruebas de calidad del código.
Tabla 4 Ramas del repositorio de versiones

Finalmente, el framework Quasar maneja un archivo de configuración llamado quasar.conf.js
ubicado en la carpeta raíz del código fuente. Dicho archivo condiciona la ejecución del códi-
go fuente en sus diferentes modos, como por ejemplo el modo SSR importante para este pro-
yecto, y el despliegue de los recursos y componentes del framework y el servidor web. Es por
estas razones que se debe tener control total de los cambios hechos en este archivo, no obs-
tante, cualquier miembro del equipo puede necesitar modificarlo en medio del desarrollo de
una característica.
Para dar solución a esta problemática se propone el siguiente proceso para solicitar un cambio
del archivo de configuración de Quasar.
Ilustración 8 BPMN cambio configuración Quasar
Página 22
5.3 Control de Calidad

El control de calidad brindará apoyo al equipo en el seguimiento del proyecto, además a lo-
grar las metas teniendo en cuenta las consideraciones establecidas. Por otro lado, la definición
de un adecuado control de calidad reducirá los riesgos involucrados.
En la siguiente ilustración, se encontrará el BPMN de control de calidad general, proceso en
el cual se identificarán los documentos y errores en el código, lo cual desplegará una serie de
actividades que serán responsabilidad del jefe de calidad y del director de documentación. La
tarea inicia cuando una actividad ha sido terminada y luego de la revisión, se encuentra con
que la entrega no cumple con los estándares, por lo que se procede a las correcciones perti-
nentes y marcación de la tarea como terminada.
Ilustración 9 BPMN Control de calidad general

Para el control de calidad de los documentos se toma como punto de partida la tarea de revi-
sar documentación, donde se tienen en cuenta los entregables documentables. En la siguiente
ilustración, se puede verificar el proceso revisar documentación el cual consiste, en la peti-
ción de por parte del director de documentación, y lo envía a revisión, luego clasifica el tipo
de documento de acuerdo con su naturaleza, para su posterior corrección y revisión en la
respectiva reunión general.
Página 23
Ilustración 10 BMPN Control de calidad documentación

Además, se tendrá en cuenta el plan de control de calidad tal como se muestra en la tabla 6. A
continuación, se encuentra el nombre del control, con su respectivo responsable, el momento
junto con una breve descripción de este.
Nombre de con- Responsable(s) Momento Descripción

trol
Control de calidad de la documentación
Revisión de Do- Director de Una vez a la El director de documentación se
cumentación documentación semana reúne con los demás miembros del
/ documentado- equipo, para detectar los errores o
res anomalías posibles.
Control de calidad del software
Realizar Plan de Tester Cada iteración En las pruebas se tendrán en cuen-
Pruebas ta tanto las pruebas individuales
(Pruebas Unitarias) donde se
definen entradas y salidas espera-
das, para su posterior verificación.
Además, se tendrán en cuenta
software de pruebas donde la
ejecución se desarrolla de manera
ágil luego de la fase de codifica-
ción.
Revisar con planti- Director de Cada interac- El director de documentación y
Página 24
lla el Diseño UML documentación ción configuración revisará que el di-

y configuración seño del software esté acorde con
los requisitos y que tengas buenas
prácticas UML.
Revisar el estándar Director de Cada iteración Por medio de la revisión del direc-
de codificación desarrollo tor de desarrollo, se garantizará
que los demás desarrolladores
cumplan con el estándar de Códi-
go.
Tabla 5 Plan de control de calidad
Página 25
6 Anexos
1. Reglas de equipo Seshat
2. Matriz de Riesgos
3. Glosario
Página 26
7 Referencias
[1] «Unified Modeling Language, v2.5.1», Unified Modeling Language, p. 796.
[2] «Business Process Model and Notation (BPMN), Version 2.0», p. 538.
[3] «ECMAScript 2015 Language Specification – ECMA-262 6th Edition».
https://262.ecma-international.org/6.0/ (accedido nov. 07, 2021).
[4] «JavaScript With Syntax For Types.» https://www.typescriptlang.org/ (accedido nov.
07, 2021).
[5] «Quasar Framework - Build high-performance VueJS user interfaces in record time»,
Quasar Framework. https://quasar.dev/ (accedido nov. 07, 2021).
[6] «Vue.js». https://vuejs.org/ (accedido nov. 07, 2021).
[7] «TypeORM - Amazing ORM for TypeScript and JavaScript (ES7, ES6, ES5). Supports
MySQL, PostgreSQL, MariaDB, SQLite, MS SQL Server, Oracle, WebSQL databases.
Works in NodeJS, Browser, Ionic, Cordova and Electron platforms.»
https://typeorm.io/#/ (accedido nov. 07, 2021).
[8] «Jest». https://jestjs.io/ (accedido nov. 07, 2021).
[9] «Heroku Postgres | Heroku Dev Center». https://devcenter.heroku.com/articles/heroku-
postgresql#provisioning-heroku-postgres (accedido nov. 07, 2021).
[10] «WebStorm: The Smartest JavaScript IDE, by JetBrains», JetBrains.
https://www.jetbrains.com/webstorm/promo/ (accedido nov. 07, 2021).
[11] «GitHub Student Developer Pack», GitHub Education.
https://education.github.com/pack (accedido nov. 07, 2021).
[12] «GitHub: Where the world builds software», GitHub. https://github.com/ (accedido
nov. 07, 2021).
[13] «Free Git GUI for Windows, Mac, Linux | GitKraken». https://www.gitkraken.com
(accedido nov. 07, 2021).
[14] «Cloud Application Platform | Heroku». https://www.heroku.com/ (accedido nov. 07,
2021).
[15] «Zotero | Your personal research assistant». https://www.zotero.org/ (accedido nov. 07,
2021).
[16] «WhatsApp», WhatsApp.com. https://www.whatsapp.com/?lang=es (accedido nov. 07,
2021).
[17] «Inicia sesión | Microsoft Teams». https://www.microsoft.com/es-co/microsoft-
teams/log-in (accedido nov. 07, 2021).
[18] Cloudways, «draw.io – Diagrams for Confluence and Jira», draw.io. https://drawio-
app.com/ (accedido nov. 07, 2021).
[19] «Bizagi - Líder en Automatización Inteligente de Procesos». https://www.bizagi.com/es
[20] «¿Qué implica la Work Breakdown Structure (WBS)?», Universidad Benito Juárez G.,
ene. 27, 2017. https://www.ubjonline.mx/implica-la-work-breakdown-structure-wbs/
[21] «[PDF] [SPMP (SOFTWARE PROJECT MANAGEMENT PLAN)] - Free Download
PDF». https://silo.tips/download/spmp-software-project-management-plan (accedido
nov. 07, 2021).
Página 27
[22] «Especificación de requisitos de software (SRS): consejos y plantillas», Visure Solu-

tions, oct. 08, 2019. https://visuresolutions.com/es/plantilla-de-consejos-de-srs-de-
especificaci%C3%B3n-de-requisitos-de-software/ (accedido nov. 07, 2021).
[23] «Descripción del diseño del software», Wikipedia, la enciclopedia libre. ene. 22, 2021.
Accedido: nov. 07, 2021. [En línea]. Disponible en:
https://es.wikipedia.org/w/index.php?title=Descripci%C3%B3n_del_dise%C3%B1o_de
l_software&oldid=132607368
[24] «ISO 31000 Software ISO». https://www.isotools.org/normas/riesgos-y-seguridad/iso-
31000/ (accedido nov. 07, 2021).
Página 28

Anexo 1 - PMP Grupo 8

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Anexo 1 - PMP Grupo 8

Cargado por

Copyright:

Formatos disponibles

Ingeniería de Sistemas

PLAN DE ADMINISTRACIÓN DE PROYECTO

Juan Sebastian Pulecio Romero____________________________________

Jairo Hernan Vanegas Garcia _____________________________________

1 VISTA GENERAL DEL PROYECTO .............................................................................. 5

2 CONTEXTO DEL PROYECTO........................................................................................ 6

3 ADMINISTRACIÓN DEL PROYECTO .......................................................................... 13

4 MONITOREO Y CONTROL DEL PROYECTO .............................................................. 18

5 PROCESOS DE SOPORTE ........................................................................................... 20

Ilustración 1 Organigrama ....................................................................................................... 12

Tabla 1 Interfaces externas ...................................................................................................... 10

1 Vista General del Proyecto

1.1 Supuestos y restricciones del proyecto

1.2 Evolución del plan

2 Contexto del proyecto

2.1 Lenguajes y Herramientas

2.1.2 Lenguajes de programación

2.1.3 Marcos de trabajo para desarrollo

2.1.4 Productos de software

2.1.5 Herramientas de desarrollo

2.1.6 Herramientas administrativas

2.2 Plan de Aceptación del Producto

2.2.1 Fase de Concepción

Listado de requisitos no funcionales

2.2.2 Fase de Construcción

2.2.3 Fase de Implantación

2.2.4 Fase de Documentación

2.3 Organización del Proyecto y Comunicación

Director de la tesis en la que

Facultad de contaduría Jesús Edmundo Rueda Gue- Profesor encargado del

Tabla 1 Interfaces externas

2.3.2 Organigrama y descripción de roles

Tabla 2 Descripción de roles

3 Administración del Proyecto

3.1 Inicio del proyecto

3.2 Planes de Trabajo del Proyecto

3.2.1 Descomposición de actividades

Ilustración 2 WBS SPMP

Ilustración 3 WBS SRS

Ilustración 4 WBS SDD

Entregable Cantidad Descripción Cliente Fecha Herramienta

SPMP 1 El SPMP (Plan de Jaime 7/11/2021 Cronograma de

4 Monitoreo y Control del Proyecto

4.1 Administración de Requerimientos

Ilustración 5 Definición de requisitos

Ilustración 6 Control de cambios requisitos

4.2 Monitoreo y Control de Progreso

validación de requisitos o en algún teste ejecutado tanto en la aplicación como en la docu-

5.1 Análisis y Administración de Riesgos

Ilustración 7 BPMN Gestión de riesgos

5.2 Administración de Configuración y Documentación

Tabla 4 Ramas del repositorio de versiones

Ilustración 8 BPMN cambio configuración Quasar

5.3 Control de Calidad

Ilustración 9 BPMN Control de calidad general

Ilustración 10 BMPN Control de calidad documentación

Nombre de con- Responsable(s) Momento Descripción

lla el Diseño UML documentación ción configuración revisará que el di-

Tabla 5 Plan de control de calidad

[22] «Especificación de requisitos de software (SRS): consejos y plantillas», Visure Solu-

También podría gustarte