PLAN DE ADMINISTRACIÓN DE PROYECTO

(1)

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 [email protected]

Juan Sebastian Pulecio Romero____________________________________

316-877-8856 7224447 [email protected]

Jairo Hernan Vanegas Garcia _____________________________________

300-670-4506 n/a [email protected]

DIRECTOR

Cesar Julio Bustacara

Medina

Correo Javeriano Empresa donde trabaja y cargo [email protected]; Pontificia Universidad Javeriana; Profe-

sor Departamento de Sistemas

(2)

Contenido

1 V

ISTA

G

ENERAL DEL

P

ROYECTO

... 5

1.1 S

UPUESTOS Y RESTRICCIONES DEL PROYECTO

... 5

1.2 E

VOLUCIÓN DEL PLAN

... 5

2 C

ONTEXTO DEL PROYECTO

... 6

2.1 L

ENGUAJES Y

H

ERRAMIENTAS

... 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 P

LAN DE

A

CEPTACIÓN DEL

P

RODUCTO

... 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 O

RGANIZACIÓN DEL

P

ROYECTO Y

C

OMUNICACIÓN

... 9

2.3.1 Interfaces externas ... 9

2.3.2 Organigrama y descripción de roles ... 10

3 A

DMINISTRACIÓN DEL

P

ROYECTO

... 13

3.1 I

NICIO DEL PROYECTO

... 13

3.1.1 Entrenamiento del personal ... 13

3.1.2 Infraestructura ... 13

3.2 P

LANES DE

T

RABAJO DEL

P

ROYECTO

... 14

3.2.1 Descomposición de actividades ... 14

3.2.2 Calendarización ... 15

3.2.3 Responsables ... 17

4 M

ONITOREO Y

C

ONTROL DEL

P

ROYECTO

... 18

4.1 A

DMINISTRACIÓN DE

R

EQUERIMIENTOS

... 18

4.2 M

ONITOREO Y

C

ONTROL DE

P

ROGRESO

... 18

5 P

ROCESOS DE

S

OPORTE

... 20

5.1 A

NÁLISIS Y

A

DMINISTRACIÓN DE

R

IESGOS

... 20

5.2 A

DMINISTRACIÓN DE

C

ONFIGURACIÓN Y

D

OCUMENTACIÓN

... 21

5.3 C

ONTROL DE

C

ALIDAD

... 23

6 A ... 26

(3)

7 R

EFERENCIAS

... 27

(4)

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

(5)

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

(6)

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 despliegue 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 posterior 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.

(7)

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 sistema 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].

(8)

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 desarrollo 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 criterio 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.

(9)

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 interesados 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 requisitos 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

(10)

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 manual, por esta razón la aceptación del manual implica directamente la aceptación de los videos. 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 Valderrama

Docente encargada del proyecto social universitario en la facultad de ingeniería, asociada con el consultorio contable gracias a este programa.

(11)

Cesar Julio Bustacara Medi- na

Director de la tesis en la que se desarrollara el proyecto actual.

Facultad de contaduría Jesús Edmundo Rueda Gue- rrero

Profesor encargado del 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

Castro

Director de la carrera de contaduría pública, encargado de administrar el desarrollo del consultorio contable.

Consultorio contable javeriano

Carlos Andres Corredor Herrera

Director del consultorio 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- ca

Braulio Adriano Ramírez Castro

Director del programa de contaduría pública, encargado de brindar asesoría para cumplir con los requerimientos contables necesarios en la elaboración del proyecto.

Promotor Jesús Edmundo Rueda Gue-

rrero

Profesor encargado del proyecto social que el consultorio contable está ejer- ciendo en el colegio san Gregorio Hernández y promotor de la iniciativa para la

(12)

aplicación en Usme.

Asesor de facultad de inge- niería

Alicia Mercedes Arenas Valderrama

Profesora encargada del proyecto social por parte de la facultad de ingeniería.

Director de proyecto Cesar Julio Bustacara Medi-

na

Encargado de brindar las

herramientas, capacita- ciones y elementos nece- sarios para desarrollar la aplicación.

Director de desarrollo Jairo Hernan Vanegas Gar- cia

Encargado de brindar las herramientas, capacitaciones y elementos necesarios para desarrollar la aplicación Director de bases de datos Juan Sebastián Pulecio Ro-

mero

Encargado de determinar

los datos e información contable necesaria para el desarrollo del proyecto.

Director de documentación Luisa Yurani Contreras

Vergel

Encargada de documen-

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-

cia

Encargada de brindar

asesoría sobre la presen- tación y requisitos que debe tener la aplicación.

Jefe de calidad Luisa Yurani Contreras

Vergel

Encargado de verificar el

estado de la documenta- ción e infraestructura del proyecto.

Tabla 2 Descripción de roles

(13)

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 proyecto 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í.

(14)

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 artefactos 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 despliegue 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.

(15)

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 proyecto, 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 modo, 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 transversales.

(16)

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

(17)

SPMP 1 El SPMP (Plan de Administración de Proyectos de Softwa- re) es un documento en el cuál se describe cuidadosamente cada detalle de la elabora- ción del producto de 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]

Jaime Andrés Pavlich Mariscal, Cesar Julio Bustacara Medina

7/11/2021 Cronograma de actividades

SRS 1 Un SRS es un docu-

mento cuyo propósito es proporcionar una descripción completa de un producto de software a desarrollar, incluyendo su propó- sito, los principales procesos de negocio que serán soportados, características, pará- metros clave de ren- dimiento y compor- tamiento.[22]

Jaime Andrés Pavlich Mariscal, Cesar Julio Bustacara Medina

15/11/2021 Cronograma de actividades

SDD 1 La Descripción del

Diseño de Softwa- re (SDD por sus siglas en inglés) es una des- cripción escrita de un producto de software, 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 software. [23]

Cesar Julio Bustacara Medina

Por definir Cronograma de actividades

(18)

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].

(19)

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 manera 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

(20)

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.

(21)

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 desarrollo 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 actividades 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].

(22)

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

Principalmente los artefactos de configuración en el servidor de pruebas del entorno de desarrollo 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 durante 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 procesos 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

de

Combina en

master Rama principal en la que se encuentra el código listo para producción.

Director de desarrollo

N/A N/A

develop Rama que se deriva de master, contiene el código estable de las nuevas características que pueden pasar a pruebas según el esquema de desarrollo incremental.

Todo el equipo master test

(23)

test Rama que contiene las caracte- 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

Jefe de calidad develop master

feature Conjunto de ramas que se crean y destruyen en función del desarrollo 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.

Todo el equipo develop develop

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 proyecto, 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

(24)

5.3 Control de Calidad

El control de calidad brindará apoyo al equipo en el seguimiento del proyecto, además a lograr 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 revisar 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.

(25)

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- trol

Responsable(s) Momento Descripción

Control de calidad de la documentación Revisión de Do-

cumentación

Director de documentación / documentado- res

Una vez a la semana

El director de documentación se reúne con los demás miembros del equipo, para detectar los errores o anomalías posibles.

Control de calidad del software Realizar Plan de

Pruebas

Tester Cada iteración En las pruebas se tendrán en cuenta 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

(26)

lla el Diseño UML documentación y configuración

ción configuración revisará que el di- seño del software esté acorde con los requisitos y que tengas buenas prácticas UML.

Revisar el estándar de codificación

Director de desarrollo

Cada iteración Por medio de la revisión del director 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

(27)

6 Anexos

1. Reglas de equipo Seshat 2. Matriz de Riesgos 3. Glosario

(28)

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 (accedido nov. 07, 2021).

[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/

(accedido nov. 07, 2021).

[21] «[PDF] [SPMP (SOFTWARE PROJECT MANAGEMENT PLAN)] - Free Download PDF». https://silo.tips/download/spmp-software-project-management-plan (accedido nov. 07, 2021).

(29)

[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).