Departamento de Informática

INGENIERIA DE SOFTWARE II

Aplicación de la guía PMBOK a

proyecto “Cooperativa 30 de
Febrero”
http://repositorioacademico.upc.edu.pe/upc/bitstream/10757/303686/1/farje_mj-pub-
delfos.pdf
https://es.slideshare.net/gsimportations/ejemploproyectocompletopmbok

Autores: Adrián Calvopiña, Santiago Almeida

Tutor: Ing. Gilma Toaza

 1. ACTA DE CONSTITUCIÓN DEL PROYECTO

Requerimientos del proyecto que satisfacen las necesidades, deseos y expectativas del
cliente, el patrocinador y los demás interesados.

● Necesidades del negocio, descripción del proyecto a alto nivel o

requerimientos del producto.

El proyecto fue realizado como parte de la materia Ingenieria de Software I, el sistema en

cuestión, simula los procesos de una pequeña cooperativa financiera ficticia denominada
“Cooperativa 30 de Febrero”, como lo son la gestión de cuentas, clientes, transacciones y
simulación de préstamos. Esta cooperativa ficticia se adapta al alcance y necesidades del
proyecto.

● Justificación del proyecto.

El sistema fue realizado para ayudar a la institución en la gestión de los datos que manejan
en todo lo relacionado a clientes, cuentas para los cuales se debe asegurar su integridad y
seguridad, para hacer gestión de los movimientos que se realizan dentro de la cooperativa,
estos movimientos están clasificados en depósitos y retiros de dinero de las cuentas de
clientes por lo que están atados a condiciones y tambien el sistema ayudara con la
simulación de préstamos para clientes de la cooperativa por lo que la aprobación de los
préstamos está sujeta a condiciones todo estos procesos son automatizados por el
programa.

● Gerente de proyecto asignado y nivel de autoridad.

Como gerente del proyecto se asignó a Santiago Almeida, Director del área de TI del la
cooperativa.

● Lista con hitos.

Inicio del proyecto 10/05/2017

Toma de Requisitos por parte del Cliente. 15/05/2017

División de responsabilidades en equipo de trabajo 17/05/2017

Creación de un repositorio de fuentes 18/05/2017

Diseño de una interfaz para la gestión de la cooperativa 22/05/2017

Implementación de un Login 24/05/2017

 Creación del módulo de Clientes 26/05/2017

Creación del módulo de Cuentas 01/06/2017

Creación del módulo de Movimientos 07/06/2017

Realización de pruebas estáticas 10/07/2017

Implementación del módulo de simulación de préstamos 12/07/2017

Realización de pruebas estáticas 24/07/2017

Gestionar Configuración 11/12/2017

Gestionar Riesgos 09/01/18

Plan de gestión del proyecto elaborado 30/01/18

Fin del proyecto 20/02/2018

● Influencia de los interesados.

Debido a la naturaleza del proyecto se tiene un stakeholder, que era el docente del la
materia para la cual fue creado este sistema, por lo tanto el único interesado tiene una
influencia alta ya que el decidía los requisitos en su totalidad y un poder alto por la misma
razón, el trato que se le dio a esta persona fue prioritario y se trabajó exclusivamente con el.

Fig. 1. Matriz de estrategias con stakeholders

 ● Áreas u organizaciones funcionales y su participación.

Cooperativa 30 de Febrero: como principal participante debido a que será el beneficiario

principal del los resultados del proyecto

Universidad de las Fuerzas Armadas ESPE: Participa con los desarrolladores y la

infraestructura de trabajo.

● Exclusiones del proyecto.

El sistema únicamente recogerá datos concernientes a la cooperativa, mas no certifica la

validez de los mismo, asi mismo todos los datos guardados por el sistema se les asegura
cierto nivel de seguridad, esto no comprende pérdida o divulgación por actos humanos.

2. IDENTIFICACION DE LOS STAKEHOLDERS

Los stakeholders en el proyecto son aquellas personas y/u organizaciones que están
activamente involucrados en el proyecto o cuyos intereses se pueden ver afectados, tanto
de manera positiva como negativa, por la ejecución o terminación del proyecto. Estos
pueden influir sobre el proyecto y sus entregables. A continuación, se detalla los
stakeholders del proyecto:

Nombre del Posición / Rol Expectativas Influencia Interés

Interesado Título

Ing Gilma Docente de Supervisora Supervisión y Alta Alto

Toaza la materia del plan de aprobación de
Ingeniería de proyectos la
Software II documentación
del proyecto

Ing Henry Docente de Cliente Final Supervisión y Alta Alto

Coral la materia aprobación del
Ingeniería de proyecto
Software I

3. PLAN DE GESTIÓN DEL PROYECTO

a. Plan de Gestion del Alcance

Caracteristicas(Requisitos Funcionales):

El sistema atenderá las necesidades expresadas por los interesados y cubrirá las áreas de:
- Gestion de Clientes
- Gestión de Cuentas
- Registro y Búsqueda de Transacciones
- Simulación y registro de préstamos

La gestión comprende Registro, busqueda, suspensión y actualización de las cuentas y

clientes.
Atributos de Calidad(Requisitos No Funcionales):

El stakeholder aprobará que interfaz gráfica sea la apropiada para el uso en la cooperativa,
se deberá usar una base de datos relacional aprobada por el stakeholder

Las limitaciones que se encontró dentro del desarrollo de este proyecto:

Las limitaciones más grandes del proyecto son los recursos con los que se cuentan debido
a que el proyecto de lo realizó de manera académica y se trato de gastar la menor cantidad
de dinero posible esto no quiere decir que los gastos fueron nulos, el tiempo también es un
limitante ya que se trabaja con un horario y cronograma académico eso implica que los hitos
deben alcanzarse de manera semestral.

● Ciclo de vida del proyecto.

Se elegirá un ciclo de vida Iterativo para el proyecto debido a la volatilidad de los requisitos
y la cantidad de gente que trabaja en el proyecto, las actividades comprendidas dentro de
cada iteración son la usuales dentro de los proyecto de software: Análisis, Diseño,
Implementación, Pruebas, Despliegue y Mantenimiento.

● Procesos de gestión de proyectos.

El Proceso de gestión para el proyecto incluye todas las áreas de conocimiento
especificadas por el PMBOK, todas las áreas se procederá a gestionar de manera manual
según indican los estándares para cada una de las áreas.

● Plan de gestión de cambios.

La gestión del cambio se realizará todos los elementos, documentos y archivos que se
definan como línea base del proyecto se Identificaran, Controlan, Garantizara que sea un
cambio exitoso y Reportan los cambios todos los cambios a los elementos dentro del ciclo
de vida del producto, se usarán herramientas de software (Github y/o Jira) para controlar las
fechas, razones y autores de los cambios, si un cambio efectuado afecta de manera
negativa al proyecto y por ende a los interesados se revertirá.

● Plan de gestión de la configuración.

La gestión de la configuración del proyecto se realizará mediante el estándar IEEE-828 el
cual encierra todas las acciones necesarias para la correcta gestión de la configuración.
Para este proyecto, los elementos de configuración se corresponderá con los entregables
definidos en el Modelo de Proceso. Aunque no necesariamente todos los entregables
deben ser elementos de configuración. La decisión de cuáles de los entregables serán
elementos de configuración será tomada por el SCMR, quién deberá tomar en cuenta qué
productos serán necesarios cuando se quiera recuperar una versión completa del sistema.
Se debe generar una línea base por iteración en cada fase, de acuerdo a lo siguiente:
- Los eventos que dan origen a la línea base.
- Los elementos que serán controlados en la línea base.
- Los procedimientos usados para establecer y cambiar la línea base.
- La autorización requerida para aprobar cambios a los documentos de la línea base.

● Gestión de líneas base.

Se indica la siguiente nomenclatura para cada entregable en el modelo de proceso según la
disciplina (en caso que exista algún elemento de configuración que se agregue a los que se
detallan abajo, se deberá incluir en las tablas.

Requerimientos:
 Nomenclatura Entregable
RQALS Alcance del Sistema
RQDRQ Documento de Requerimientos
RQDVC Documento de validación con el Cliente
RQGL Glosario
RQMOD Modelo de Casos de Uso
RQMD Modelo de Dominio
RQRRQ Resumen de las reuniones de requerimientos
Análisis:
Nomenclatura Entregable
ANERQ Documento de Especificación de Requerimientos
ANMOD Modelo de Análisis

Diseño:
Nomenclatura Entregable
DSMOD Modelo de Diseño
DSDIST Modelo de Distribución

Implementación:
Nomenclatura Entregable
IMDT Documentación técnica
IMELBA Ejecutable de la Línea Base de la Arquitectura
IMES Ejecutable del Sistema
IMESF Ejecutable Final del Sistema
IMEDT Estándar de documentación técnica
IMEIM Estándar de implementación
IMMTP Manual técnico del prototipo
IMMOD Modelo de Implementación
IMPINT Plan de Integración
IMPROT Prototipo
IMRREP Reporte de revisión por pares
IMRVEP Reporte de verificación por pares

Para los nombres de los archivos de código fuente se debe definir el procedimiento que
permita su identificación.

De todas las anteriores:

Nomenclatura Entregable
DESARQ Descripción de la Arquitectura

Verificación:

Nomenclatura Entregable
VRCPRU Casos de Prueba
VREVRIT Evaluación de la verificación de la iteración
VRIFVR Informe final de verificación
VRMOD Modelo de Testeo
VRPRUP Plan de Pruebas
VRPRUPPR Plan de Pruebas del Prototipo
VRPLAN Plan de Verificación
VRREPU Reporte de Pruebas unitarias
VRREPIS Reporte de Pruebas de integración
VRREPUIS Reporte de Pruebas del Sistema
 VRREVDOC Reporte de verificación de documentos
VRREPRUPR Reporte de pruebas del Prototipo

Gestión de Configuración (SCM):

Nomenclatura Entregable
SCMIAUD Informe de la auditoría a la gestión de configuración
SCMPLAN Plan de SCM

Gestión de Calidad (SQA):

Nomenclatura Entregable
SQADEVP Documento de evaluación y ajustes al Plan de SQA
SQAENS Entrega semanal de SQA
SQAINRV Informe de revisión de SQA
SQAINRTF Informe de Revision Tecnica Formal (RTF)
SQAINF Informe final de SQA
SQAPLAN Plan de SQA

Gestión del Proyecto (GP):

Nomenclatura Entregable
GPACQ Acta de la Reunión Quincenal
GPDES Documento de Estimaciones
GPDEVP Documento de evaluación y ajustes del Plan del Proyecto
GPDRIES Documento de riesgos
GPICONF Informe de conclusiones de la Fase
GPISITP Informe de Situación del Proyecto
GPIFAD Informe final del Administrador
GPITERP Plan de la iteración
GPPLAN Plan del Proyecto
GPREGAC Registros de Actividad

Documentación

Se utilizará google Doc para la elaboración de documentos, ya que es útil a la hora de

compartir la información entre los integrantes el equipo de desarrollo. Además, permite una
colaboración más dinámica entre los participantes.

Luego que los documentos son verificados por el SQAR y entregados, pasan a
almacenarse, los que correspondan según la planificación, a un repositorio Git en Github.

Para este repositorio sólo tendrán permisos de lectura todos los integrantes excepto el
Administrador, SQAR y SCMR, los cuales dispondrán de todos los privilegios.

Código fuente

Se utilizará otro repositorio Git en Github. donde mediante la utilización de ramas, se

mantendrá la línea de desarrollo por un lado y por otro la línea estable o también
denominado master que lo crea por default.
Se definirá y se detallará más claramente el flujo de trabajo en la posteridad. Tendrán
acceso a este repositorio todos los integrantes del grupo.

Se evaluará en una etapa posterior si resulta necesario mantener la línea base del código
fuente en un repositorio aparte con otros permisos de acceso.
 Control de configuración

En esta sección se detallan las actividades de solicitud, evaluación, aprobación e

implementación de cambios a los elementos de la línea base. Los cambios apuntan
tanto a la corrección como al mejoramiento. El procedimiento que se describe a
continuación es el que se utilizará cada vez que se precise introducir un cambio al
sistema.
Se entiende por cambio al sistema las modificaciones que afecten a la línea base del
sistema como pueden ser:
● Cambios en los Requerimientos.
● Cambios en el Diseño.
● Cambios en la Arquitectura.
● Cambios en las herramientas de desarrollo.
● Cambios en la documentación del proyecto. (agregar nuevos documentos o
modificar
● La estructura de los existentes)

● Plan de gestión de las comunicaciones.

Tabla de Requerimientos de Comunicación del Proyecto

Comunicac Objetivo Contenid For Med Frecuenc Plazo Resp Aprobador Audiencia
ión o mato io ia para onsa /
confir ble Receptore
mar s
recepc
ión

Estado de Tener N/A Lunes y Docente Adrian

proyecto actualizad Avances Hab Miércole Inmedi Santi Calvopiña
o a las del lado s de ato ago / Docente
partes proyecto manera Almei
interesad especific semanal da
as sobre adas en
el estado los
del requisito
proyecto s

Requisitos Lunes y Adrian Adrian

del Establece Requisit Hist Hab Miércole Inmedi Doce Calvopiña Calvopiña
proyecto r los os para oria lado s de ato nte / Santiago
requisitos el de manera Almeida
para el desarroll Usu semanal
proyecto o del ario
proyecto

Recursos asignados a actividades de comunicaciones

No existen recursos exclusivamente asignados para las comunicaciones más que el tiempo
de las horas clase en las que se trabaja.

Diagrama de Flujo de Información

● Plan de revisiones de gestión.

4. REQUISITOS

REQUISITOS FUNCIONALES:

Requisito N.- 1
● El sistema debe tener un Login al iniciar la aplicación. Los datos del Login estarán
guardados en una base de datos.

Requisito N.- 2
● El sistema debe ser capaz de desplegar la información correspondiente a los
clientes que se encuentran registrados dentro de la cooperativa. La información
mostrada será: el código del cliente (que en el caso de este sistema será la cédula) y
el nombre del mismo.De esta manera, el sistema permitirá ingresar o buscar a los
clientes de la cooperativa.

Requisito N.- 3
● El sistema debe ser capaz de desplegar la información correspondiente a las
cuentas de los clientes, como lo es: el código distintivo de la cuenta, el tipo de
cuenta que es (Ahorro, Corriente), el saldo que posee y el estado actual de las
mismas (Activo, Inactivo). Cabe destacar que se permitirá crear una nueva cuenta
relacionada a un cliente, y se podrá habilitar o deshabilitar la cuenta dependiendo se
requiera ese proceso.

Requisito N.- 4
● El sistema debe ser capaz de desplegar la información correspondiente a los
diferentes movimientos que se hagan con las cuentas de los clientes. Estos
movimientos serán validados mediante la comprobación del estado de la cuenta. Asi
mismo se podrá generar nuevos movimientos entre los que se encuentran: Débito y
Crédito. Para la búsqueda de movimiento, se tendrá la facilidad de escoger el rango
de tiempo en el cual se haya realizado algún tipo de movimiento anteriormente
mencionado.

Requisito N.- 5
● El sistema permitirá simular un préstamo para un cliente en especifico. Se tendrán
ciertas restricciones para poder solicitar el prestamo, como lo es un monto máximo,
calculado por medio de los ingresos mensuales del cliente, y del saldo promedio que
este tenga en su cuenta. El sistema calculará dependiendo estos criterios la tabla de
amortización indicando factores como: Mes, Saldo inicial, Interes, Amortizacion,
Pago y Saldo Inicial. Además, se procederá a mostrar el monto máximo que puede
aspirar el cliente a pedir de manera de préstamo.
Requisito N.- 6
● El sistema debe ser capaz de validar correctamente la cédula o pasaporte ingresado
para la creación de una nueva cuenta.

REQUISITOS NO FUNCIONALES:

Requisito N.- 1
● Toda funcionalidad del sistema y transacción de negocio debe responder al usuario
en menos de 5 segundos.

Requisito N.- 2
● El sistema debe ser capaz de operar adecuadamente con hasta 1000 cuentas de
ahorros procedentes de los usuarios. Conjuntamente se tomará en cuenta la misma
cantidad de cuentas activas que se generarán.

Requisito N.- 3
● Los datos modificados en la base de datos deben ser actualizados para todos los
clientes que acceden en menos de 2 segundos.

Requisito N.- 4
● Garantizar al Usuario el acceso de información de acuerdo al nivel que posee.

Requisito N.- 5
● El sistema debe contar con manuales de usuario estructurados adecuadamente.

Requisito N.- 6
● El sistema debe poseer interfaces gráficas bien formadas.

5. ESTRUCTURA DE PLANEACIÓN DEL TRABAJO

El gráfico especifica las tareas a realizar en cada una de las fases del proyecto según está
especificado por el ciclo de vida, también se toman en cuenta que se van a repetir estas
fases para el mejoramiento del sistema de manera posterior a su entrega.
 6. SECUENCIAR LAS ACTIVIDADES
En cada iteración del trabajo se harán todas la actividades establecidas en el punto anterior,
la secuencialidad de las mismas es obligatoria por como lo dice el ciclo de vida

Las macro actividades dependen de su predecesora de manera obligatoria, lo que no ocurre

con los actividades que las conforman muchas de estas actividades se pueden realizar de
manera simultánea esto se da más comúnmente en las dos primeras fases del proyecto:
Diseño e Implementación.

Todas las actividades de estas fases pueden ser realizadas de manera simultánea ya que
trabajan de manera independiente a las demas micro actividades dentro de la misma fase.

7. ESTIMAR LOS RECURSOS DE LAS ACTIVIDADES

La estimación de recursos globales encierra los recursos que se presume serán necesarios
para la correcta ejecución del proyecto sin importar la fase.
 La estimación de los recursos se realizará de manera independiente y en orden para cada
fase puesto que la algunos resultados de cada fase en un recurso importante de para la
fase siguiente:

Analisis

Recurso Tipo Costo Uso Resultado

Stakeholders Humano ninguno Obtención de Requisitos en alto

información nivel
sobre los
procesos del
negocio

Sala de reuniones Instalacion ninguno Lugar de Sin especificar

reuniones para
la discusión del
proyecto

Repositorio de Software $50 mensuales Alojara todos Gestion del cambio

Documentos los documentos
resultantes

Diseño

Recurso Tipo Costo Uso Resultado

Herramientas CASE Software $320 Diseño de los Diagramas de alto

diagramas nivel sobre la
propios de esta estructura del sistema
fase
Especificación de Documento 2 semanas de Lineamientos Sin especificar
Requerimientos del trabajo para los
Software diseños

Implementación

Recurso Tipo Costo Uso Resultado

IDE de desarrollo Software ninguno Desarrollo de la Sistema

aplicación

Diseños de la Documentos 2 semanas de Desarrollo de la Sistema

Aplicación trabajo aplicación

Repositorio de fuentes Software ninguno Aloja los Gestion del cambio

archivos con
código fuente
de la aplicación

Gestor de base de Software ninguno Desarrollo de la Sistema

datos aplicación

Computadores Tecnologia Por cada Desarrollo de la Sistema

personales Desarrollador aplicación

Desarrolladores Humanos ninguno Desarrollo de la Sistema

aplicación

Pruebas

Recurso Tipo Costo Uso Resultado

Desarrolladores Humanos ninguno Testeo de la Reporte de pruebas

aplicación

Plan de pruebas Documentos 3 días de trabajo Testeo de la Reporte de pruebas

aplicación

Módulos del sistema Software 2 meses de trabajo Testeo de la Reporte de pruebas

aplicación

Codigo Fuente Software Testeo de la Reporte de pruebas

aplicación

Software para pruebas Software ninguno Testeo de la Reporte de pruebas

estáticas aplicación

Despliegue

Recurso Tipo Costo Uso Resultado

Desarrolladores Humanos ninguno Configuración Sistema desplegado
de la aplicación

Computadores Tecnologia Por parte del Configuración Sistema desplegado

personales cliente de la aplicación

Mantenimiento

Recurso Tipo Costo Uso Resultado

Desarrolladores Humanos ninguno Asistencia al Reporte de problemas

cliente

Computadores Tecnologia Por parte del Asistencia al Reporte de problemas

personales encargado de cliente
mantenimiento

ServiceDesk Software $50 mensuales Aloja todos las Reporte de problemas

peticiones de
cambio o
problemas

8. ESTIMAR LA DURACIÓN DE LAS ACTIVIDADES

Dentro del desarrollo del sistema para la gestión de la cooperativa “30 De Febrero”, se
plante que su ciclo de vida de desarrollo dure 6 meses, correspondientes a la planificación,
desarrollo, implementación, pruebas y salida al mercado del mismo.
La duración de cada una de estas iteraciones estará estrechamente relacionada con la
cantidad de entregables que se tengan que tener y de la complejidad de cada uno de los
procesos realizados. Para la correcta estimación de las actividades dentro del proyecto se
utilizara el método Pert el cual asume tres estimaciones de tiempo por cada actividad, estas
estimaciones son:
- Tiempo optimista (a): Duración que ocurre cuando el desarrollo de la actividad
transcurre de forma perfecta. En la práctica suele acudirse al tiempo récord de
desarrollo de una actividad, es decir, el mínimo tiempo en que una actividad de esas
características haya sido ejecutada.

- Tiempo más probable (m): Duración que ocurre cuando el desarrollo de la actividad
transcurre de forma normal. En la práctica suele tomarse como el tiempo más
frecuente de ejecución de una actividad de iguales características.

- Tiempo pesimista (b): Duración que ocurre cuando el desarrollo de la actividad

transcurre de forma deficiente, o cuando se materializan los riesgos de ejecución de
la actividad.

Dentro de este análisis se tomará como unidad de medida el total de semanas que se
dedicara a cada hito del proyecto anteriormente mencionado.
 Tabla: Estimación de duración de las actividades mediante el Método Pert.

Tabla: Resultados de la estimación mediante el Método Pert.

9. DESARROLLAR EL CRONOGRAMA

Dentro del cronograma de actividades correspondientes a cada iteración dentro del proyecto
se puede mostrar la duración del mismo, contando con un total de 201 días. Cabe
mencionar que si a este cronograma no se toma en cuenta a los días festivos, y los meses
de vacaciones que el equipo de desarrollo no trabajo, se podrá ver que se ajusta a la
estimación mostrada en el punto anteriormente descrito.

Tabla: Duración de desarrollo del proyecto.

 Fig: Cronograma de actividades de los hitos del proyecto.

10. DETERMINAR EL PRESUPUESTO

Como se especificó al inicio del documento, este sistema fue diseñado para una asignatura
en específico dentro de la Universidad de las Fuerzas Armadas. Sin embargo, contando con
los costos del mercado actual, el costo del desarrollo del proyecto medidos en unidades de
días/hombres será el siguiente:

COSTOS DIRECTOS

ACTIVIDAD Unidad Cantidad Valor Total Valor total

unitario Costo

RECOLECCION DE Días/hombre 9 2 18
INFORMACION

ANÁLISIS DE Días/hombre 13 2 26
REQUERIMIENTOS
 DISEÑO DE SISTEMA Días/hombre 9 2 18

IMPLEMENTACION Días/hombre 110 2 220

PRUEBAS Días/hombre 30 1 30

ENTREGA Días/hombre 4 0 0

INSTALACION Días/hombre 2 5 10

TOTAL COSTOS 322

DIRECTOS

Tabla: Costos directos del proyecto

COSTOS INDIRECTOS

Costos directos 322

IU (imprevistos y utilidad) 18%

Imprevistos= Costo Directo * 5 % $ 16.10

Utilidad= Costo Directo * 13% $ 57.96

Garantía = Costo Directo * 10% $ 3.22

Costo indirecto = Costo directo * IU + Garantía $399.28

Tabla: Costos indirectos

11. DESARROLLAR EL PLAN DE RECURSOS HUMANOS Y COMUNICACIONES

En cuanto a los recursos humanos, el equipo de trabajo está conformado por dos
integrantes, los cuales tienen una comunicación constante en reuniones semanales,
reuniones semanales entre ellos, para definir correctamente los requisitos que se
dieron anteriormente y poder brindar una correcta funcionalidad al cliente. Debido a
que el equipo está conformado por dos integrantes, se tuvo que realizar una
clasificación en cada rol, con el fin de tener una óptima sincronización.
Director del proyecto: Adrián Israel Calvopiña Vinueza, tendrá la tarea de designar
las tareas que se realizaran dentro de los diferentes procesos que se desarrollen
durante la gestión de riesgos.

Director del Área de TI: Jonathan Santiago Almeida Salas, tendrá a su cargo el
desarrollo del producto teniendo en cuenta los lineamientos del SDD.

Documentación: Jonathan Santiago Almeida Salas y Adrián Israel Calvopiña

Vinueza tendrán a su cargo la documentación de cada uno de los componentes
resultantes del producto.

El proyecto se desarrollará en el lenguaje de programación Java, dentro del IDE Netbeans.

La ventaja que se tiene dentro de esta sección, es que las licencias de instalación del
producto son gratis. En cuanto a los recursos físicos, todos los miembros del equipo
cuentan con al menos un computador personal además de los disponibles en los
laboratorios de la Universidad.

12. PLANIFICAR LAS ADQUISICIONES

El propósito de este plan es documentar y describir cómo serán gestionados los procesos
de adquisiciones para el proyecto, desde la identificación y el desarrollo de la
documentación para las adquisiciones hasta el cierre del contrato.
Observaciones: Las adquisiciones para el proyecto serán gestionadas a través de cuatro
procesos.
● Planificar las adquisiciones.
● Efectuar las adquisiciones.
● Administrar las adquisiciones.
● Cerrar las adquisiciones.

Componente Descripción

Título del proyecto Aplicación de la guía PMBOK a proyecto

“Cooperativa 30 de Febrero”

Implementación del plan de Los procesos de Gestión de Adquisiciones del

Adquisiciones Proyecto y sus herramientas y técnicas asociadas
se documentan en el presente Plan de Gestión.

Planificar las Adquisiciones:

Se plantea la necesidad de tener un software que
permita la completa integración continua entre el
sistema y permita la administración de tareas del
proyecto. Luego, se procede a ver la factibilidad de
poseer un sistema de paga que pueda realizar
dichas actividades. El director del proyecto será el
encargado de determinar la factibilidad del mismo y
dar paso a la siguiente fase.

Los procesos de Gestión de Adquisiciones del

Proyecto y sus herramientas y técnicas asociadas
se documentan en el presente Plan de Gestión.

Planificar las Adquisiciones:

Se plantea la necesidad de tener un software que
permita la completa integración continua entre el
sistema y permita la administración de tareas del
proyecto. Luego, se procede a ver la factibilidad de
poseer un sistema de paga que pueda realizar
dichas actividades. El director del proyecto será el
encargado de determinar la factibilidad del mismo y
dar paso a la siguiente fase.

Análisis de Hacer o Comprar.

Dada la anterior planificación, se procede a buscar
en el mercado software que brinde las
características buscadas por parte del grupo de
desarrollo. Se desarrollarán diferentes estudios
para revisar cuál es su viabilidad en un proyecto:

Comparación de Atlassian
 Sacado de TrustRadius

Después de realizar este análisis se decidió utilizar

el servicio de Bamboo para la integración continua
de los diferentes componentes del sistema.
Efectuar las Adquisiciones
La salida del proceso de la adquisición consistirá
en la adjudicación del contrato de adquisición
correspondiente al sistema del cual se pretende
utilizar el software de integración continua. En este
caso se hará mediante una empresa de pagos en
línea (PayPal), el cual será el encargado de realizar
un contrato entre el proveedor y el equipo de
desarrollo.

Administrar las adquisiciones.

El director del proyecto será el que tenga total
control sobre el software adquirido, para lo cual
creará usuarios para el director del área de TI de la
empresa pueda ingresar y gestionar ciertos
procesos dentro del software adquirido.

Cerrar las Adquisiciones

Una vez finalizado el ciclo de vida del sistema de la
cooperativa “30 de Febrero”, se hará un análisis
conjunto entre las diferentes partes del equipo del
proyecto para ver si mantienen contrato con la
empresa proveedora o terminan relaciones hasta el
siguiente proyecto.

Tipo de contrato a utilizar Para la adquisición del servicio de Bamboo, se

utilizará un sistema de pago en línea, que servirá
como contrato de precio fijo por el uso de este
servicio. El pago de este servicio será

Gestión de múltiples
proveedores
Asunciones y restricciones
13. GESTIÓN DE LA CALIDAD
Componente
Título del proyecto
Políticas de calidad del Proyecto
mensualmente, con un costo de $10.
Para el desarrollo de este proyecto se plantea un
segundo software de integración continua
(Jenkins), pero se lo tomara como segunda
alternativa en caso de que el que se escogió
primero produzca algún inconveniente.
Asunciones
● Disponibilidad de insumos en el mercado
local.
● El proveedor cumplirá con todas las
cláusulas y condiciones del contrato.
● En caso de existir controversias generadas
en los contratos se resolverán por mutuo
acuerdo.
Restricciones
● El costo real de cada adquisición en el
proyecto no debe excederse al monto
contractual.
Descripción
Aplicación de la guía PMBOK a proyecto
“Cooperativa 30 de Febrero”
La Política de Calidad del Proyecto cumplirá con
los requisitos de calidad desde el punto de vista
de la Cooperativa, es decir culminar el Proyecto
en el tiempo y presupuesto planificado,
cumpliendo con las normas aplicables y
utilizando la tecnología adecuada con el fin de
brindar la satisfacción a los requerimientos del
cliente.
 Estructura Organizacional

Descripción de la gestión de Dentro del plan de control de calidad se llevarán

calidad del proyecto a cabo ciertas actividades de que se detallarán a
continuación, para mantener la calidad del
proyecto a través de todas sus fases:

● Aseguramiento de la calidad en los

procesos del desarrollo del producto:
En cada etapa del proyecto, el administrador de
calidad y manejo de riesgos tendrá en cuenta los
posibles riesgos asociados y analizará su
impacto en caso de que ocurran. También se
realizarán correcciones y validaciones de los
cambios hechos por parte del equipo de
desarrollo y registro de estos.

● Aseguramiento de la calidad en la
documentación
En las reuniones semanales del equipo de
desarrollo, se discutirá la documentación de
cada uno de los entregables, asegurando la
claridad y calidad de los mismos. El Tutor
encargado de guiar al equipo de desarrollo,
tendrá la responsabilidad de revisar y aprobar la
documentación generada.

● Aseguramiento de la calidad en el
desarrollo
Cada semana se revisará la adecuada
documentación de la codificación del producto,
especificando el funcionamiento y avance. El
desarrollador será el encargado de realizar esta
documentación, la cual será revisada por el
auxiliar de desarrollo.
 Roles y responsabilidades
Documentos normativos para la
calidad
Mejora Continua del Proceso
Director del proyecto:
Adrián Israel Calvopiña Vinueza
Objetivo del rol:
Responsable de elaborar y asegurar el
cumplimiento del plan de gestión de la calidad
Funciones del rol:
Designar las tareas que se realizaran dentro de
los diferentes procesos que se desarrollen
durante la gestión de riesgos.
Nivel de autoridad:
Exigir el cumplimiento de entregables al equipo
del proyecto.
Reporta / Supervisa:
Tutor (StakeHolder) / Director del Área de TI
Director del Área de TI:
Jonathan Santiago Almeida Salas
Objetivo del rol:
Asegurar y controlar la calidad de los
entregables según los estándares establecidos.
Funciones del rol:
Tendrá a su cargo el desarrollo del producto
teniendo en cuenta los lineamientos del negocio.
Nivel de autoridad:
Uso de recursos asignados
Reporta:
Director del proyecto
Las guías para conducir auditorías a la calidad
de software están incluidas en "IEEE Std 1028 -
Software Reviews and Audits". El Control de la
Calidad de Software (SQC) se encarga de
aplicar métodos, herramientas y técnicas para
asegurar que los productos del trabajo de
software satisfacen los requerimientos de calidad
para un producto de software en desarrollo.
Cada vez que se requiera mejorar un proceso,
debido a las necesidades del proyecto, se
seguirá los siguientes pasos:
1. Definir el proceso.
2. Establecer la oportunidad de mejora.
3. Analizar la información sobre el proceso.
4. Definir y Aplicar las acciones correctivas
para mejorar el proceso.
5. Verificar si las acciones correctivas han
sido efectivas.
6. Estandarizar las mejoras logradas para
 hacerlas parte del proceso.
Tabla: Gestión de la Calidad

14. GESTIÓN DE RIESGOS

Los riesgos que se encuentran dentro del sistema, se los podrá expresar de correcta
manera dentro del programa PILAR 6.4.3, el cual permite la correcta identificación de los
riesgos. En la siguiente imagen se puede mostrar la clasificación de los riesgos:

En el cuadro anteriormente mostrado, se ven los riesgos más generales que pueden
suscitarse dentro del desarrollo del sistema, pero se los representará de mejor manera en el
cuadro que se encuentra a continuación:

Riesgo Probabilidad Efecto Responsable Estrategia

Desconfiguración Baja Serio Equipo de Tener un backup

de ambiente desarrollo de la instalación
donde se inicial en un
desarrolla el segundo
software. computador.

Autenticación Moderada Serio Equipo de Tener una correcta

incorrecta en el desarrollo verificación dentro
Login de la autenticación
de la base de datos

El cronograma Alta Tolerable Equipo de Realizar

planteado no se desarrollo modificaciones a
alcanza las tareas dentro
del cronograma
 Manipulación de Alta Serio Equipo de Poner seguridad
datos desarrollo adicional a la base
de datos, para
prevenir ingresos
bruscos

Modificación Moderada Serio Equipo de Determinar los

repentina en desarrollo requerimientos bien
requerimientos definidos.

Falsificación de Baja Serio Equipo de Programar

cédula para la desarrollo algoritmo exacto
creación de para la detección
clientes de errores en
ingreso de cédula

Falta de tiempo en Alta Seria Equipo de Encontrar apoyo

los integrantes del desarrollo entre los
equipo de trabajo integrantes del
equipo para la
realización de
tareas según la
responsabilidad.

Falla de conexión Alta Seria Equipo de Definir un tiempo

con el servidor de desarrollo de respuesta de
la base de datos conexión. En caso
de que el servicio
no responda
correctamente, se
enviará un correo a
los administradores
del sistema
indicando los
inconvenientes.

Modificación de los Medio Serio Administrador Plantear seguridad

datos ingresados de base de dentro de la base
dentro de la base datos de datos y del
de datos sin servidor, además
autorización de ingresar
autenticación
correcta dentro del
mismo programa.
Eliminación de los Alta Seria Administrador Plantear
registro de los de base de seguridades dentro
movimientos de datos de la aplicación
los clientes para no permitir la
eliminación de
estos datos

Tabla: Gestión de Riesgos