Pap app delivery

PLAN DE PROYECTO
MODULO:

GESTION DE REQUERIMIENTOS
INTEGRANTES.Gustavo Tantani Mamani
Alexandro Arauco Sánchez
Hernán Luis Peñafiel Velásquez
José Luis Irala Cárdenas
Alfonsín Pestañas Márquez
Mario Pérez Gonzales

Diciembre del 2013

Santa cruz - Bolivia

1.1 INTRODUCCIÓN................................................................................................................................5
1.2 DEFINICION DEL PROBLEMA.............................................................................................................5
1.3 SITUACION PROBLEMÁTICA..............................................................................................................6
1.4 SITUACION DESEADA........................................................................................................................6
1.5 OBJETIVOS........................................................................................................................................6
1.5.1 Objetivo General.........................................................................................................................6
1.5.2 Objetivos específicos...................................................................................................................7
1.6 JUSTIFICACIÓN..................................................................................................................................7
1.7 ALCANCE...........................................................................................................................................8
1.7.1 Cliente..........................................................................................................................................8
1.7.2 Solicitud de pedidos.....................................................................................................................8
1.7.3 Empresa.......................................................................................................................................8
1.8 VENTAJAS..........................................................................................................................................8

2 2.1 ESTRUCTURA ORGANIZACIONAL.................................................................10
3 2.2 CRONOGRAMA DE TRABAJO..........................................................................10
INTRODUCCIÓN.........................................................................................................25
PROPÓSITO............................................................................................................................................. 25
ALCANCE................................................................................................................................................25

3.1. GESTIÓN DEL RIESGO.........................................................................................26
3.1.1.
3.1.2.
3.1.3.
3.1.4.

IDENTIFICACIÓN DE RIESGOS.............................................................................................................26
ANÁLISIS DEL RIESGO.......................................................................................................................26
ACCIONES DE PREVENCIÓN Y DE CORRECCIÓN.......................................................................................33
CONTROL Y SEGUIMIENTO DE RIESGOS................................................................................................36

3.1.5. MATRIZ DE RIESGO..........................................................................................36
4. INTRODUCCIÓN.....................................................................................................................................56
4.1. Factibilidad Técnica.....................................................................................................................56
Software:...........................................................................................................................................56
Hardware:.........................................................................................................................................57
4.2. Factibilidad Económica...............................................................................................................57
4.3. Factibilidad Operativa.................................................................................................................58
4.4. Factibilidad Legal........................................................................................................................59

5. MOTIVACIÓN GENERAL.......................................................................................60
5.1.1. REQUERIMIENTOS Y ANÁLISIS.............................................................................................................61
5.1.2. DISEÑO..........................................................................................................................................62
5.1.3. IMPLEMENTACIÓN ...........................................................................................................................62

Página 2

Parte I
Perfil de Proyecto

“En esta parte del proyecto se presenta la introducción al proyecto para
que se tenga una comprensión general del ámbito
y las posibles soluciones”

Página 4

1.1

INTRODUCCIÓN

El auge de los servicios que se proveen hoy en día en Internet, el avance
tecnológico, la tendencia hacia dispositivos más pequeños y más rápidos, junto con
la necesidad de acceso a la información en cualquier momento, son los factores
determinantes del surgimiento de nuevas tecnologías de acceso a Internet desde
cualquier tipo de dispositivos incluyendo a los teléfonos celulares, los SmartPhones
y las tablets PC.
Empresas e instituciones de todo el mundo ejecutan procesos de negocios
distribuidos en diferentes puntos geográficos, que requieren sistemas de software
eficientes y de alta disponibilidad.
El desarrollo de estas aplicaciones con lleva una constante adquisición y
renovación de conocimientos específicos en nuevas tecnologías, requiriendo
profesionales siempre actualizados y con acceso constante a nuevos dispositivos,
para que puedan ofrecer soluciones innovadoras y eficaces a los problemas,
requerimientos y necesidades que las empresas y el contexto social diariamente
presentan.
Las aplicaciones que pueden ejecutarse desde un dispositivo celular se dividen en
dos grandes géneros, las que acceden a un sitio de Internet a través de un
navegador disponible en el dispositivo, las que ejecutan en el celular y las que se
acceden a través del envío de mensajes de texto.
La combinación de estas aplicaciones, es decir, acceder a servicios de Internet
utilizando aplicaciones instaladas en el celular, acompañado de un impresionante
desarrollo tecnológico, ha dado impulso a la creación de numerosas aplicaciones
que ejecutan en diferentes plataformas móviles.
El surgimiento del iPhone, seguido de la aparición de una enorme variedad de
dispositivos con sistema operativo Android ha revolucionado el mercado de las
aplicaciones móviles.
Las tiendas online han dejado de estar orientadas al entretenimiento y al ocio
ofreciendo solo contenidos multimedia y juegos, sino también aplicaciones de
propósito general tales como ofimática y comunicaciones; servicios de información
tales como noticias, tránsito y tiempo; así como aplicaciones específicas en áreas
tales como medicina, ingeniería, arquitectura y diseño por citar alguno ejemplos.

1.2

DEFINICION DEL PROBLEMA

Actualmente podemos observar que las empresas que se encargan de la venta de
productos en diversas áreas, se ven saturados por el incremento de la población,
Página 5

dando lugar la apertura de nuevos sucursales para mejorar la atención. Esto
implica incremento de presupuesto en la parte técnica, humana. Como ser nuevo
espacio físico, nuevas herramientas de trabajo y nuevo personal de trabajo, etc.
1.3

SITUACION PROBLEMÁTICA

Las empresas que se encargan de vender sus productos lo realizan de manera
personal (cliente vs personal de venta), o pedidos por llamada telefónica indicando
las características del producto y los datos personales y la ubicación del
comprador, generando problemas al momento de la entrega por falta de datos,
además para pedir un producto se demora entre 10 a 15 minutos por teléfono.

1.4

SITUACION DESEADA

Contar con una aplicación servidor y una aplicación móvil para mejorar el servicio
de entrega de productos a domicilio.

1.5

OBJETIVOS

Los objetivos sobre las cuales se enmarcar el presente proyecto son detallados a
continuación

1.5.1 Objetivo General
Desarrollar una aplicación móvil, para el servicio de envió de pedido de
comidas a domicilio.

Página 6

1.5.2 Objetivos específicos
 Recolectar los requerimientos sobre el manejo de la distribución de productos a
domicilio.
 Realizar entrenamientos por área de trabajo, para no tener problemas con las
diferentes herramientas que se utilizaran para la construcción de dicha
aplicación.
 Realizar un plan de desarrollo de proyecto con fechas establecidas para su
entrega por fases.
 Realizar constantes reuniones con los personales de cada área para poder tener
una buena comunicación.
 Realizar motivación a los diferentes personales por área y general.

1.6

JUSTIFICACIÓN

El motivo por el cual decidimos realizar esta aplicación móvil delivery comida
rápida es porque notamos colas bastante largas en las empresas que se encargan a
la atención de venta de comidas, la atención por cliente demora un tiempo
aproximado de 10 a 15 minutos, lo cual pone descontento a los que están
esperando.
La empresa al contar con una aplicación móvil el cual ayudara a reducir las colas y
dando la alternativa de que si el cliente quiere comida para su casa, lo podrá
realizar con previo registro de cliente, y así de esa manera poder satisfacer a los
clientes reduciendo su pérdida de tiempo.

Página 7

1.7

ALCANCE

1.7.1 Cliente
En este módulo se realizara el registro de datos del cliente.
1.7.2 Solicitud de pedidos
En este módulo se registrara todos los pedidos, ubicación geográfica, pagos
realizados por el cliente.

1.7.3 Empresa
En este módulo se realizara el registro de todo el personal, registro de producto o
servicio y las sucursales con las que cuenta la empresa.

1.8

VENTAJAS

Reducción de la apertura de nuevos sucursales si no cuentan con un presupuesto
para la ejecución.
Brindar comodidad al cliente que quiere solicitar pedidos a domicilio.
Modernización utilizando nuevas tecnologías para el incremento del márquetin.

Página 8

Parte II
Plan de Trabajo

Página 9

2

2.1 ESTRUCTURA ORGANIZACIONAL

3

2.2 CRONOGRAMA DE TRABAJO.

En el siguiente apartado mostraremos el plan de trabajo del proyecto de
forma general y por roles de un Sprint.
Cronograma General de desarrollo del proyecto.
Detalle del Cronograma.
Días
Responsable Trabajad
os

Detalle
trabajo

de

Holgura

Fecha
Inicio

Fecha final

Total
de días
asigna
do

Página 10

Scrum Master 16

Product
Owner

16

Teams
16
(Developer’s)

Prueba
Testeo

y

16

Gestión
de
16
configuración

Realizar
el
control
del
proceso
de
construcción del
proyecto
4
coordinando
con
los
diferentes
responsables de
área
Realizar
la
gestión y el
control de todos
los procesos de
análisis, Diseño, 16
implementación
y prueba junto a
su equipo de
trabajo Team.
Realizar
la
gestión de todos
los procesos de
análisis, Diseño,
implementación 16
y prueba junto
con el Product
Owner.
Realizar
el
control de todos
los
procesos
10
deprueba
y
testeo de la
aplicación
Realizar
el
control de todos
16
los cambios de
la aplicación

18/11/2
10/12/2013 20
013

20/11/2
06/12/2013 16
013

20/11/2
06/12/2013 16
013

14/10/2
06/12/2013 16
013

14/12/2
06/12/2013 16
013

Página 11

2. 3 Vista Gráfica General.

2. 4

ESTIMACIÓN Y COSTO GENERAL.

La estimación del costo basándose en dos planes de adquisición del producto, toda
venta te producto incluye un mantenimiento limitado de la aplicación por 1 año,
luego de ese tiempo el cliente decide según el plan de venta que adquiera, también
el paquete incluye el hospedaje de la aplicación en nuestro servidor por 2 años,
luego de ese tiempo también tendrá que pagar un monto de dinero para que siga
alojado la aplicación en nuestro servidor, los planes citamos a continuación:

Plan A.
Este plan es sin mantenimiento lo cual incluye el hospedaje de la aplicación por dos
años, luego tendrá que pagar 80$ por año, y por cada mantenimiento fuera del
tiempo del contrato 100$ por mantenimiento.
Precio Venta Sin Mantenimiento
precio
T
21970

Cantidad
E
5

precio
V
4394

m/mes c/man serv/a
Página 12

Precio

5272,8 0

100

80

Plan B.
Este plan es con mantenimiento lo cual implica que cada mes tiene que pagar 50$ el
hospedaje de la aplicación por dos años, luego tendrá que pagar 50$ por mes,
también incluye el alojamiento de la aplicación por dos año gratuitos y luego tendrá
que pagar 50$ por año.

Precio Venta con Mantenimiento
precio
T
21970
Precio

2.5

Cantidad E precio V m/mes c/man serv/a
5
4394
4394

50

0

50

CRONOGRAMA POR ÁREA

2.5.1 Requerimientos y análisis
Tiempo Total para la captura de requisitos y análisis es de 33 días.
1. Enumerar Requisitos Candidatos.(1-5)
Aquí se efectúa una serie de entrevistas al cliente lo permitirá
extraer una lista de características del sistema a desarrollar.
2. Comprender el Contexto del Sistema (1-5).
Página 13

Aquí se hará una comprensión general del sistema lo cual se definirá
los modelos iniciales (modelo de dominio/clases).
3. Capturar los Requisitos Funcionales (1-6).
Ya comprendido el Sistema en general se puede definir un modelo
general de todo lo que hará dicho sistema (modelo de casos de uso).
4. Capturar los Requisitos no Funcionales (1-5).
Acá se definirá sobre todo bajo que plataformas (SO, Lenguajes de
programación, etc.) y restricciones funcionara el sistema.
5. Analizar la Arquitectura del sistema (1-6).
Se definirá los casos de uso asociándolos a algún modulo o paquete
lo que permitirá tener un contexto mejor dicho sistema.
6. Analizar Casos de Uso (1-6).
Se definirá los la comunicación de cada función del sistema para
llevar adelante la elaboración eficiente de dicho proceso.

Vista gráfica.

2.5.2 Diseño
CRONOGRAMA DE ACTIVIDADES
Tiempo Total para el Diseño de Software es de 44 días Hábiles.
Página 14

Fase 1: Diseño de Paquetes (Subsistemas)
- El tiempo para completar exitosamente esta fase es de 6 días.
 Se realizara la organización de casos de uso y paquetes para
acomodar los casos de uso por modulo de paquetes.
Los Diseñadores deberán presentar un informe de actividades, dicho
informe tiene que ser en forma digital e impreso.
El tiempo para las pruebas es de 1 día.
Fase 2: Diseño de Clases
 Se va a definir los tipos de datos operaciones.
 Visibilidad de atributos y operaciones.
 Operaciones, parámetros, atributos y tipos.
 Clase de Entidad de Análisis  Clase que almacena datos.
 Clase de Control de Análisis  Clase que encapsula la lógica.
 Clase de Interfaz de Análisis  Formularios, Diálogos, Ventanas.
Al final de cada día, dicha documentación tiene que ser impresa y digital.
El tiempo para las pruebas es de 2 días.
Fase 3: Diseño Casos de uso
- El tiempo de implementación para completar esta fase exitosamente es de 7
días.
 Realización flujo de sucesos - diseño de casos de uso.
Fase 4: Diseño de Interfaz
- El tiempo para la realización de esta fase es de 8 días.
 En esta fase se realizara la especificación de operaciones que tendrá
la interfaz.

Página 15

 Se definirá las interfaces de la aplicación con las que interactúa entre
los subsistemas, y también las interfaces para que interactúe el
usuario.

Fase 5: Diseño de la Arquitectura
- El tiempo para la realización de esta fase es de 6 días.
 En esta fase se realizara la descomposición del modelo en subsistemas
junto con sus interfaces.
 Organizar los Casos de Uso con su uso de funcionalidad critica.
El tiempo para las pruebas tiene como plazo máximo de 2 días.
Se realizara documentación de los Diseños realizados, tanto digital como impresa,
se presentara informes por cada fase completada.
Por cada Fase completada exitosamente se realizara pruebas.
El tiempo total para el DISEÑO es de 34 días, teniendo así 10 días restantes como
holgura en caso de alguna de las fases no se cumpla en el plazo determinado.

2.5.3 Implementación
Página 16

Tiempo Total para el Desarrollo es de 30 días.
Fase 1: Investigación y Elección del Protocolo de Comunicación
Día 1:
Investigar sobre todos los protocolos de comunicación existentes.
Día 2:
Realizar pruebas y demos de cada uno de los protocolos de comunicación
encontrados.
Día 3- 4:
Se realiza pruebas del protocolo de comunicación ya escogido para el
problema a desarrollar.
-

Por cada día, el desarrollador deberá presentar un informe de actividades,
dicho informe tiene que ser en forma digital e impreso.

Fase 2: Desarrollo del Primer Módulo (Módulo Conexión)
Día 1 – 2
Implementación del Servidor de acuerdo al protocolo de comunicación.
Día 3 – 4 - 5
Implementación de los Clientes, en este caso son Clientes Móviles son SO
Android siguiendo el protocolo de comunicación escogido.
Al final de cada día, se procede a documentar el código, dicha
documentación tiene que ser impresa y digital.
Una vez finalizado el periodo de implementación tanto del Cliente como del
Servidor, se realizara las pruebas pertinentes, estas pruebas tienen como
plazo máximo a realizarse en 2 días.

Página 17

Fase 3: Desarrollo del Segundo Módulo (Módulo Cliente)
días.
Día 1 - 2
Implementación de todos los casos de usos involucrados para completar
este módulo.
Día 3 - 4
Implementación de los prototipos de interfaz gráfica, definidos en el Diseño.
Una vez finalizado el periodo de implementación de esta fase, se realizara
las pruebas pertinentes, estas pruebas tienen como plazo máximo a
realizarse en 2 días.
Fase 4: Desarrollo del Tercer Módulo (Módulo Solicitudes)
días.
En este módulo se realizara el registro de solicitud de pedidos, el registro de
los pedidos enviados, se recepcionará la ubicación geográfica del pedido.
Día 1 – 5
En este tiempo planteado, se tiene que llevar a cabo la implementación de
todos los casos de usos definidos y la implementación de los prototipos de
interfaz Gráfica.
Fase 5: Desarrollo del Cuarto Módulo (Módulo Empresa)
- El tiempo de implementación para completar exitosamente esta fase es de 4
días.
En este módulo se realizara el registro de datos de la empresa, sucursales,
empleados, productos o servicios que brinda o presta.
Día 1 – 4
Página 18

Implementar todos los casos de usos definidos,
implementación de los prototipos de interfaz gráfica.

incluyendo

la

Para llevar a cabo la implementación correctamente se está usando el Paradigma
Orientado a Objetos y el ciclo de vida XP (Xtreme Programming).
Se realizara documentación de código, tanto digital como documentación impresa,
se presentara informes por cada fase completada.
Por cada Fase completada exitosamente se realizara pruebas.
El tiempo total para el desarrollo es de 30 días, teniendo así 10 días restantes como

Vista gráfica.

Página 19

2.5.4 Calidad y testeo.
Tiempo Total para el Desarrollo de Pruebas y Calidad en cada Área es de 40 días.
Fase 1: Análisis y Requerimiento
Día 1 - 2:
Enumerar Requisitos Candidatos.
Día 3 - 4 :
Comprender el Contexto del Sistema.
Día 5 - 6:
Capturar los Requisitos Funcionales y No Funcionales.
Día 7 – 8:
Analizar la Arquitectura del sistema y Casos de Uso.
-

Por cada día, el desarrollador deberá presentar un informe de actividades al
encargado de Tester, dicho informe tiene que ser en forma digital e impreso,
se tiene 2 días de holgura por si se tarda en definir los análisis y
requerimiento.

Fase 2:
Diseño
Día 1 – 3:
Diseño y pruebas de Paquetes.
Diseño y pruebas de clases.
Día 4 – 6:
Diseño y pruebas de casos de uso.
Diseño y pruebas de interfaz.
Día 7 – 8:
Diseño y pruebas de la arquitectura.

Página 20

Al final de cada día, se procede a documentar el código, dicha
documentación tiene que ser impresa y digital.
Una vez finalizado la Fase de pruebas del Diseño tanto del Cliente como del
Servidor, se realizara las pruebas pertinentes, estas pruebas tienen como
plazo máximo a realizarse en 2 días.
Fase 3: Implementador
- El tiempo de implementación para completar esta fase exitosamente es de
10 días.
Día 1:
Investigar sobre todos los protocolos de comunicación existentes.
Día 2:
Realizar pruebas y demos de cada uno de los protocolos de comunicación
encontrados y escogidos para el proyecto a desarrollar.
Día 3:
Implementación del Servidor de acuerdo a normas y
comunicación.

protocolos de

Día 4 :
Implementación de los Clientes, en este caso son Clientes Móviles son SO
Android siguiendo el protocolo de comunicación escogido.

Día 5:
Implementación de todos los casos de usos involucrados para completar
este módulo.
Día 6 –8:
En este tiempo planteado, se tiene que llevar a cabo la implementación de
interfaz Gráfica.

Página 21

Una vez finalizado la fase de pruebas en la Implementación, se realizara las
pruebas pertinentes, estas pruebas tienen como plazo máximo a realizarse
en 2 días.

Fase 4: Tester y Calidad
- El tiempo de pruebas para completar esta fase exitosamente es de 10 días.
En Fase se realizara las pruebas de registro de solicitud de pedidos, el
registro de los pedidos enviados, se recepcionará la ubicación geográfica del
pedido de todo el Sistema.
Día 1 – 5
En este tiempo planteado, se tiene que llevar a cabo todas las pruebas de
interfaz Gráfica del Software terminado.
Una vez finalizado la fase de tester, se realizara las pruebas pertinentes,
estas pruebas tienen como plazo máximo a realizarse en 5 días.
El tiempo total para el desarrollo es de 30 días, teniendo así 10 días restantes como

Página 22

Parte III
Estudio de análisis de
Riesgo

Página 24

3. RIESGO GENERAL
Introducción
Uno de los elementos clave a la hora de asegurar el éxito en el proyecto,
medido en términos de cumplimiento de plazos, costes, alcance funcional y
calidad final de la solución, es la Gestión de Riesgos. Implantar una
Gestión de Riesgos adecuada será un elemento decisivo a la hora de
asegurar el Proyecto, mediante la identificación y el
análisis
por
adelantado de los riesgos potenciales que puedan afectar al Proyecto, y la
elaboración de las acciones de contingencia adecuadas para evitar su
aparición o para
minimizar el impacto en el Proyecto, en caso de que
finalmente el riesgo se verifique.
Propósito
Este documento presenta el análisis de los riesgos identificados durante la
fase de Inicio del
proyecto “Virtual Class II”. Para cada riesgo observado
se valorarán sus efectos y contexto de
aparición para el caso en que se
convierta en un hecho. Además, se definirán estrategias para reducir
la
probabilidad del riesgo o para controlar sus posibles efectos.
Alcance
El ámbito del análisis de riesgos cubre toda la extensión del proyecto
observado desde su fase inicial. Será necesario durante el desarrollo del
proyecto revisar y actualizar los contenidos del análisis de riesgos en caso
de que se detecten nuevos riegos no visibles en este momento.
Este documento será aplicable a todas las fases del Proyecto.

Página 25

3.1.

Gestión del Riesgo

3.1.1. Identificación de Riesgos
Listado de Riesgos, Tipo de Riesgo
ID
R01
R02
R03
R04
R05
R06
R07
R08
R09
R10
R11
R12
R13

Descripción del Riesgo
Requisitos poco claros
Abandono temporal de un miembro del
equipo
Falta de Experiencia en tareas de
planificación
Falta de Experiencia con las herramientas
utilizadas
Diseño Erróneo
Falta de un Experto
Pérdida de documentación y/o otros
artefactos
Conflictos entre los integrantes del grupo
Inestabilidad del entorno de desarrollo y
documentación el proyecto
Estimación de costos fuera del alcance de
la realidad
Falta de seguimiento permanente de
tareas y actividades
Aprendizaje de JSF
Falta de comunicación entre los
integrantes del grupo.

Tipo de Riesgo
Riesgo del Producto
Riesgo del Proyecto
Riesgo del Proyecto
Riesgo
Producto/Proyecto
Riesgo del Producto
Riesgo del Proyecto
Riesgo del Proyecto

del

Riesgo del Proyecto
Riesgo del Proyecto
Riesgo del Proyecto
Riesgo del Proyecto
Riesgo del Proyecto
Riesgo del Proyecto

3.1.2. Análisis del Riesgo
ID

Análisis del Riesgo
Página 26

R01
Magnitud
Variable según la fase de aparición:
 Inicio: baja.
 Elaboración: media.
 Construcción: alta.
 Transición: muy alta
Descripción
Los requisitos representan la idea que tiene el cliente sobre la
aplicación, sobre ellos se construyen los casos de uso y dichos casos de
uso guían el desarrollo del proyecto. Una mala o insuficiente recolección
de los mismos afecta a la calidad de todo el proyecto.
Impacto
La incorporación o modificación de requisitos durante el desarrollo
requerirá realizar cambios sobre gran parte de la documentación del
producto elaborada con anterioridad al momento del cambio. Estas
modificaciones serán menos costosas durante las dos primeras fases del
proyecto, pero pueden suponer trastornos importantes durante las fases
de Construcción y Transición, pues no sólo cambiaría la documentación
sino también el código fuente y los ejecutables.
Indicadores
Al realizar la consulta al cliente, no sabe indicar con propiedad cuales
son los servicios que espera obtener de la aplicación.
R02
Magnitud
Alta, cuando afecta a un solo miembro. Muy alta, si afecta a más de uno.
Descripción
Algún miembro del proyecto no se encuentra disponible por cualquier
motivo externo (enfermedad, lesión, etc) durante un periodo corto de
tiempo, y por lo tanto no puede realizar tareas relacionadas con el
Página 27

proyecto.
Impacto
La falta de disponibilidad de los recursos humanos puede provocar el
retraso con respecto a la planificación inicial de cualquier actividad del
proyecto. Teniendo en cuenta que la entrega no puede posponerse, la
falta de disponibilidad de personal puede suponer una pérdida de
calidad en el producto.
Indicadores
Ninguno. Al ser un riesgo por causas externas al proceso, se supone que
es un riesgo difícil de predecir.
R03

Magnitud
Media.
Descripción
El grupo tiene poca experiencia en el desarrollo de software siguiendo
una estructura de tareas y fechas preestablecido.
Impacto
La planificación guía todo el desarrollo del proyecto. Un error en la
misma puede incidir directamente en sus resultados. No obstante, la
división en iteraciones reduce el posible impacto de los errores,
permitiendo que estos puedan ser corregidos o absorbidos en
iteraciones posteriores a la de su aparición.
Indicadores
Diferencias entre el desarrollo real del proyecto y la planificación
estimada.

R04

Magnitud
Variable según la fase de aparición:
 Inicio: baja.
Página 28





Elaboración: media.
Construcción: alta.
Transición: alta.

Descripción
El equipo tiene dificultades a la hora de realizar sus objetivos (tanto de
documentación como de implementación) por su inexperiencia con las
herramientas disponibles para el mismo.
Impacto
Puede suponer retrasos.
Indicadores
No procede.
R05
Magnitud
Baja en Elaboración, alta en Construcción.
Descripción
El diseño del sistema resulta inadecuado. Al realizar actividades de
implementación puede encontrase que el diseño carece del suficiente
nivel de detalle o está mal enfocado, bien por la naturaleza del
problema, o bien por restricciones de uso impuestas por tecnologías de
terceros.
Impacto
Puede introducir retrasos en el proyecto ante la necesidad de volver a
considerar el diseño trazado.
Requiere la actualización o modificación de los artefactos de diseño.
Indicadores
La arquitectura
implementación.

no

cumple

las

expectativas.

Se

complica

la

Página 29

R06
Magnitud
Media.
Descripción
No hay un experto del dominio en el equipo de desarrollo al que poder
consultar.
Impacto
Puede suponer retrasos.

R07

Indicadores
No procede
Magnitud
Alta.
Descripción
Por causas varias se pierde parte o el total de la documentación así
como la posibilidad de perder parte o el total de otros artefactos, como
pueden ser: parte de la implementación o ficheros de planificación.
Impacto
Variable, puede suponer una catástrofe, o un simple retraso.
Indicadores
Ninguno.

R08

Magnitud
Media.
Descripción
Aparición de problemas y discrepancias entre los miembros del
proyecto. Falta de acuerdo en las decisiones tomadas.
Impacto
Si los desacuerdos no son rápidamente resueltos se pueden provocar
retrasos en la planificación. Teniendo en cuenta que no se puede
producir un retraso en la entrega final, se tendría que reajustar la
planificación con una posible pérdida de calidad del producto.
Página 30

Indicadores
Mucho tiempo dedicado a decisiones concretas, énfasis en las posturas
enfrentadas, número de enfrentamientos con respecto a una misma
decisión.
R09

Magnitud
Alta
Descripción
Tanto el proceso de desarrollo como el de documentación se soportan
sobre un servidor gratuito que puede sufrir caídas intermitentes.
Impacto
Puede generar desconfianza en el cliente en cuanto a la calidad del
producto desarrollado.
Indicadores
La página donde se encuentre alojado el proyecto demora mucho en
cargar y/o no carga.

R10
Magnitud
Media
Descripción
Se sobreestiman o subestiman los costos involucrados con el desarrollo
del producto de software
Impacto
Puede generar que el equipo entre en períodos de sobrecarga de trabajo
o periodos de ausencia del mismo, lo que a su vez puede conllevar a un
deterioro en la calidad

R11

Indicadores
El equipo trabaja más o menos horas de las inicialmente programadas,
se presentan quejas a jefe del Proyecto o Pedidos de
redimensionamiento
Magnitud
Media

Página 31

Descripción
No se realiza un seguimiento de las tareas planificadas para cada sprint,
lo que puede ocasionar que algunas de ellas sean dejadas para última
instancia, con la consecuente baja en su calidad
Impacto
Sobrecarga de trabajo en los días previos a la entrega de un presentable,
pobre calidad de los entregables, se obvian detalles importantes.

R12

Indicadores
En el gráfico burn-down, se mantiene como constante una proporción
de horas mayor en los últimos días de cada iteración en comparación al
trabajo en el resto del sprint.
Magnitud
Alta
Descripción
El sistema se va a construir usando el lenguaje JSF. Los miembros del
equipo de desarrollo tienen que aprender a utilizarlo. Un
desconocimiento del sistema impedirá el desarrollo de la fase de
construcción y elaboración de una manera ágil.
Impacto
Puede generar retrasos así como también que se vuelvan a desarrollar
módulos que ya se encontraban terminados.

R13

Indicadores
El cliente y/o el jefe de proyecto anuncia al equipo el cambio de
tecnología.
Magnitud
Media
Descripción
Durante la realización de un proyecto software, hay muchos artefactos
que realizar y tareas que completar por la totalidad de integrantes del
grupo. Normalmente dichas tareas están relacionadas de alguna manera,
y cualquier cambio independiente en una de ellas afecta al resultado
final o a otras tareas.
Impacto
Página 32

Pueden producirse duplicación de tareas.
Indicadores
Conflictos entre los artefactos desarrollados.

3.1.3. Acciones de Prevención y de Corrección

R01

R02

ID Plan de Prevención
Realización de varias reuniones
con el cliente; elaboración de
cuestionarios para aclarar puntos
poco claros de las reuniones
previas.

Plan de Corrección
En las primeras fases se realizarán
los cambios necesarios para
incorporar los nuevos requisitos o
los cambios necesarios para que se
cumpla con la funcionalidad
solicitada. En las fases de
Construcción y Transición se
valorará la importancia de las
modificaciones/requisitos nuevos
frente a la cantidad de tiempo
disponible para abordarlos.
En caso de que se decida
aceptarlos, se revisarán los
requisitos afectados, así como toda
la
documentación
y
código
derivado de los mismos hasta el
punto de aparición del cambio.

Tratar de cumplir las metas y
objetivos antes de lo estimado en
la planificación siempre que sea
posible, para
que una ausencia no suponga un
retraso importante importante.

El equipo de desarrollo tratará de
cubrir el trabajo no realizado por el
miembro del proyecto que no
puede trabajar. En caso necesario,
dejarán de realizarse tareas menos
importantes para centrarse en las
principales.
Se tratará de reajustar la
planificación del proyecto.
Página 33

R03

El uso de Scrum como proceso de
desarrollo.
Realización
de
reuniones entre los miembros del
proyecto para
la evaluación de la marcha del
proyecto y consultas al tutor.

Se observarán las diferencias entre
la planificación de cada iteración y
el informe de seguimiento de su
ejecución, analizando las causas de
sus diferencias para tratar de
detectar y corregir errores de
planificación en las iteraciones
posteriores.

R04

Una parte del tiempo de Si se produce un retraso en el
desarrollo del proyecto se aprendizaje por parte de un
destinará al aprendizaje de las miembro del equipo, los demás
nuevas herramientas.
miembros tratarán de ayudar a
superarlo. Si no resultara, consultar
a
fuentes
externas
como
profesores, bibliografía, foros en
Internet. En último lugar se haría
una redistribución de tareas.

R05

Durante la fase de Elaboración se
desarrollará en paralelo un
prototipo
conteniendo
la
arquitectura del sistema
para comprobar la validez de la
misma. En caso de encontrase
errores o inconsistencias, podrá
modificarse el
diseño al mismo tiempo que la
implementación del prototipo.

R06

Aprendizaje continúo
todo el proyecto

R07

Se realizarán copias de seguridad Actualizar con la última copia
en los ordenadores personales de disponible
cada uno de los miembros del
equipo, así como copias en un
servidor remoto

Si el riesgo se convierte en hecho
durante la fase de Elaboración, se
revisará
y
modificará
la
documentación de diseño afectada.
Si lo hace durante la fase de
construcción, se estudiará una
solución acorde a los tiempos de
plazo de que se dispone.
La planificación se reajustará si
fuera necesario.

durante Las dudas que no se sepan resolver
se trasladarán al tutor y a foros
especializados.

Página 34

R08

Cada vez que se fije un punto de
dirección en el proyecto, todo
tiene que quedar totalmente claro,
sin dudas y con la aceptación total
de todos los miembros del grupo.

Se establecen las siguientes reglas
para definir una política de toma de
decisiones en caso de desacuerdo.
Las
cuestiones
relativas
a
requisitos se tratarán junto al
cliente, que será quién tome la
decisión.
Las cuestiones de diseño o técnicas
se tratarán junto al tutor del
proyecto, que aportará su opinión.

R09

Contratar un hosting seguro, que
brinde garantía acerca de la
disponibilidad del servicio 24
horas diarias, los 7 días de la
semana.
Realizar estimaciones en base a
varias herramientas para tratar de
hallar un estimado más cercano a
la realidad
Llevar al día una revisión del
estado del proyecto para anotar
los posibles atrasos y poder asi
tomar medidas en el instante.

En caso de emergencia utilizar una
de las PC’s del equipo como
servidor.

R10

R11

R12

Se ha de conseguir bibliografía
básica y realizar un taller entre los
integrantes del grupo.

R13

Utilizar el msn y reuniones como
punto
de
sincronización
y
comunicación de nuevas ideas
sobre el proyecto y todo lo
relacionado con él.
Mantener una documentación
única
como
medio
de
documentación centralizado.

Redimensionar
el
proyecto
conforme se va desarrollando y
nuevas funcionalidades se agregan
o se eliminan.
Realizar una recandelirización de
tareas, así como llamadas de
atención a los miembros del equipo
que dejen sus tareas para última
instancia.
En caso de que el aprendizaje sea
demasiado costoso, la tecnología de
programación de “salvaguarda”
será PHP.
Realizar reuniones a la salida de
clases
para
acordar
temas
referentes al proyecto así como las
fechas de futuras reuniones.

Página 35

3.1.4. Control y Seguimiento de Riesgos
Id.
R01
R02
R03
R04

R05
R06

Responsable
Analista
Jefe
de
Proyecto
Jefe
de
Proyecto
Programador
/
Tester
Analista/
Arquitecto
Equipo
de
Desarrollo

R09
R10
R11
R12

Programador
Equipo
de
Desarrollo
Equipo
de
desarrollo
Analista
Jefe
del
proyecto
Programador

Fin del Proyecto
Fin del Proyecto

o
Iniciado

Fin del Proyecto

Iniciad

Fin del Proyecto

o
Iniciado
Iniciado

Fin del Proyecto

Iniciado

Fin del proyecto

Iniciado

Fin del proyecto
Fin del proyecto

Iniciado
Iniciado

Fin del proyecto

Observaciones

Iniciad

Fin del Proyecto

R07
R08

Fecha de Terminación Estado
Fin del Proyecto
Iniciado
Fin del Proyecto
Iniciado

Iniciado

Responsable: Persona o personas asignadas a la implantación de las acciones
preventivas y/o correctoras
Fecha Terminación: Fecha límite en la cual todas las acciones anteriormente
descritas deban haber sido ejecutadas por el responsable o responsables asignados.
Estado: Estado Actual del Riesgo y de las Acciones Preventivas y/o Correctoras.
Observaciones: Descripción de las observaciones encontradas para este riesgo
(opcional).
3.1.5. Matriz de Riesgo

Página 36

Se propone la utilización de una matriz específica que sirva de soporte para la
Gestión de Riesgos. Esta matriz se utilizará en las reuniones de seguimiento y/o
cuando se estime necesario (en el caso de situaciones excepcionales), y su
contenido será el siguiente:
Id.

Descripción
del Riesgo

Tipo
Riesgo

R0
1

Cambios en Product
los Requisitos o

R0
2

R0
3

Probab.
Ocurrenci
a

Acciones
de Prevención

Acción de
Corrección

20

Nivel de Evaluac
Impacto ión
del
Riesgo
4
0.8

Realización de
varias
reuniones con el
cliente para la
aclaración
de
requisitos.

Se revisarán
los
requisitos
afectados,
así
como
toda
la
documentaci
ón y código
derivado de
los mismos
hasta
el
punto
de
aparición del
cambio.

Bajas en el Proyect
Equipo
de o
Desarrollo

30

4

1.2

Tratar
de
cumplir
las
metas
y
objetivos antes
de lo estimado
en
la
planificación
siempre que sea
posible.

Falta
de Proyect
Experiencia
o
en tareas de

50

2

1

Reasignar
ciertas
tareas
a
otros
miembros
según vayan
siendo
necesarios
los
artefactos
para
la
consecución
de los hitos.
Realización de Se
reuniones entre observarán
los miembros las
Página 37

planificación

del
proyecto
para
la evaluación de
la marcha del
proyecto
y
consultas
al
tutor.

diferencias
entre
la
planificación
de
cada
iteración y el
informe de
seguimiento
de su
ejecución,
para tratar
de detectar y
corregir
errores de
planificación
en
las
iteraciones
posteriores.

Si
se
produce un
retraso por
parte de un
miembro del
equipo, los
demás
miembros
tratarán de
ayudar
a
superarlo.
Consultar a
fuentes
externas En
último lugar
se haría una
redistribució
n de tareas.

R0
4

Falta
de Product 50
Experiencia
o/Proye
con
las cto
herramientas
utilizadas

2

1

Una parte del
tiempo
de
desarrollo del
proyecto
se
destinará
al
aprendizaje de
las
herramientas de
documentación
e
implementación
.

R0

Diseño

3

1.2

Durante la fase Se revisará y

Product

40

Página 38

5

Erróneo

o

de Elaboración
se desarrollará
en paralelo un
prototipo
conteniendo la
arquitectura del
sistema
para comprobar
la validez de la
misma.

modificará la
documentaci
ón de diseño
afectada.
La
planificación
se reajustará
si
fuera
necesario.

R0
6

Falta de un Proyect
Experto
o

80

1

0.8

Aprendizaje
Las
dudas
continúo
que no se
durante todo el sepan
proyecto
resolver se
trasladarán
al tutor y a
foros
especializad
os.

R0
7

Pérdida
de Proyect
documentaci o
ón y/o otros
artefactos

40

4

1.6

Se usará una
forja
(repositorio)
para el control
de versiones. Se
realizarán
copias
de
seguridad en los
ordenadores
personales de
cada uno de los
miembros del
equipo
de
desarrollo.

Actualizar
con la última
copia
disponible

R0
8

Conflictos
Proyect
entre
los o
integrantes
del grupo

75

2

1.5

Se celebrarán
reuniones
de
proyecto para
poder discutir

Establecer
las
reglas
para definir
una política

Página 39

cuestiones
requisitos
diseño.

R0
9

Proyect
o

80

5

4

Búsqueda
y
contratación de
una
empresa
que nos brinde
garantía de su
servicio

Utilizar una
de las PC’s
del equipo
como
servidor.

Proyect
o

50

3

1.5

Redimension
ar
el
proyecto
conforme se
ejecuta

R1
1

Falta
de Proyect
seguimiento
o
de tareas

50

3

1.5

Realización de
varias
estimaciones
con
metodologías
diferentes
Planificación
adecuada
de
tareas,
seguimiento del
desarrollo
de
las
mismas
usando SVN

R1
2

Aprendizaje
de JSF

Proyect
o

50

3

1.5

Se
ha
de
conseguir
bibliografía
básica y realizar
un taller entre
los
desarrolladores.

R1
3

Falta
de Proyect
Comunicació o
n entre los

20

2

0.4

Mantener una
documentación
única
como

R1
0

Inestabilidad
del entorno
de desarrollo
y
documentaci
ón
el
proyecto
Mala
estimación de
costos

de de toma de
y decisiones
en caso de
desacuerdo.

Recandeleriz
ación de las
tareas,
charla con el
equipo
de
desarrollo
en caso de
detectarse
malas
prácticas.
Utilizar PHP
como
tecnología
de
programació
n
“salvaguarda
”.
Realizar
reuniones
informativas

Página 40

Integrantes

3.2.

medio
de a la salida de
documentación clase.
centralizado.

RIESGO POR ÁREAS

3.2.1. Requerimientos y Análisis
IDENTIFICACION DE RIESGOS
Listado de riesgos, tipos de riesgos.
ID
R01
R02

DESCRIPCION DEL RIESGO
El cliente cambiará los requisitos.
Mala comunicación con el cliente.

R03

Mala elección de ciclo de vida.

R04
R05

Renuncia de un analista.
Mala estimación de esfuerzo y tiempo.

R06
R07
R08

Herramienta de desarrollo desconocido.
Analistas sin experiencia.
Retiro parcial de un analista.

TIPO DE RIESGO
Riesgo del Producto.
Riesgo
Producto/Proyecto.
Riesgo
Producto/Proyecto.
Riesgo
Producto/Proyecto.

del
del

del

ANÁLISIS DEL RIESGO
ID
R01

Magnitud
Alto
Descripción
Este riesgo se puede dar por el caso que no mostremos un avance
permanente del producto que se está desarrollando lo cual podría
ocasionar un cambio de requisitos después de haber obtenido ya un
largo avance de dicho proyecto.
Contingencia
Página 41

Si el cliente decide hacer un cambio de requisitos por algún motivo,
de inmediato se hará los prototipos de acuerdo a la especificación de
requisitos lo cual se lo muestra al cliente cosa que la idea sea muy
clara para ya no dar paso atrás.

R02

R03

Magnitud
Alto
Descripción
El cliente por diferentes motivos ya sea de trabajo, familiar, etc. No
tendría mucho tiempo para poder acudir a nuestras entrevistas
propuestas.
Contingencia
Si el cliente por algún motivo casi siempre no tiene tiempo para
entrevistarse con nosotros lo que haremos es priorizar su tiempo y
adecuarnos a su tiempo libre de tal manera que podamos
comunicarnos.
Magnitud
Medio
Descripción
El grupo de trabajo podría elegir un ciclo de vida inadecuado.
Contingencia
En este caso de inmediato reelegir el nuevo ciclo de vida adecuado
para el proyecto pero ya tomando ciertos parámetros que nos darán
la elección correcta.

R04

Magnitud
Medio
Descripción
Por algún motivo ya sea conocido o desconocido podría renunciar
Página 42

un analista.
Contingencia
Mi persona como encargado del área toma el puesto por unos 3 días
solicitando al Director del Proyecto la contratación de un nuevo
Analista, para la continuación de la captura de requisitos y análisis
de dicho proyecto, teniendo un plazo como máximo de 5 días para
dicha contratación.

R05

Magnitud
Bajo
Descripción
La estimación podría variar de acuerdo a lo establecido tanto en
tiempo como en esfuerzo.
Contingencia
El tiempo de estimación para este proyecto en la fase de requisitos y
análisis es de 30 días, teniendo así 10 días para hacer una revisión
general.
Superando los 30 días establecidos, pues se recurre a usar 5 días de
la fase de revisión general para la terminación del proyecto, en caso
de no cumplir con ese tiempo establecido se procede al desarrollo
del software solicitando al Director ampliación de tiempo.

R06

Magnitud
Bajo

Página 43

Descripción
La herramienta elegida para desarrollar los diferentes podría ser
desconocida para los analistas.
Contingencia
En este caso de inmediato se hará la capacitación respectiva para
que estos puedan desarrollar sus funciones de manera óptima.
R07

Magnitud
Bajo
Descripción
El grupo tiene poca experiencia en el área de trabajo.
Contingencia
Organizar cursos de capacitación para el personal ya existente,
investigar la posibilidad de contratar en otras regiones del país

R08

Magnitud
Bajo
Descripción
Por muchos factores un analista podría dejar el cargo parcialmente.
Contingencia
Reorganizar el equipo de tal forma que se solapen el trabajo y los
miembros comprendan el trabajo de los demás.

3.2.2. DISEÑO
RIESGOS DISEÑO
ID
R01
R02

Integrante del equipo de Diseño se retire
del proyecto.
Estrategia de Diseño desconocido.

R03

Herramienta de Diseño desconocido

TIPO DE RIESGO
Riesgo del Producto
Riesgo
del
Producto/Proyecto
Riesgo
del
Página 44

R04

Mala estimación y planificación de tiempo
debido a no contemplar actividades
ajenas al proyecto.

R05

Problemas de comunicación entre los
Diseñadores.

Producto/Proyecto
Riesgo del Producto

Riesgo
del
Producto/Proyecto

ANÁLISIS DEL RIESGO DISEÑO
ID
R01
Magnitud
Alta
Descripción
Al ser un riesgo por causas externas al proceso, se supone que
es un riesgo difícil de predecir.
Contingencia

R02

Redefinir las funciones de los integrantes.
No saturar de manera desmedida el trabajo.
Magnitud
Media
Descripción
Se puede presentar al momento de realizar el diseño del
producto teniendo así un impacto en el proceso de diseño del
desarrollo del Proyecto.
Contingencia
Trabajar de manera organizada y minuciosamente, empleando
toda la documentación posible acerca de la estrategia a utilizar.

R03

Magnitud
Media
Descripción
Este riego se puede presentar al momento de realizar el diseño
o cambiar el diseño en último momento.
Contingencia
Buscar información y ayuda en el manejo la misma.
Trabajar con herramientas empleadas previamente.
Página 45

R04

R05

Magnitud
Media
Descripción
En el momento de realizar la planificación de tiempos y
actividades, realizarla siguiendo un calendario en el cual
contemple posibles eventualidades y tiempos reales de trabajo
de los integrantes del equipo.
Contingencia
Contemplar dentro de la planificación de tiempo un tiempo de
demora asumiendo cualquier tipo de eventualidad.
Magnitud
Media
Descripción
Realizar actividades para incentivar la Buena Comunicación
entre compañeros.
Contingencia
Especificar las tareas que debe realizar cada desarrollador
detallando las fechas de presentación.
Explicar a las personas que hayan malinterpretado las tareas
que deberían realizar para que lo corrijan.

3.2.3. Implementación

IDENTIFICACION DE RIESGOS
Listado de riesgos, tipos de riesgos.
ID
R01 Retiro Parcial o Definitivo de un Programador
R02 Mala comprensión en el uso del Ciclo de Vida
R03

Curva de Aprendizaje en el uso de Tecnologías

R04
R05

Tiempo de Estimación
Perdida de Información

TIPO DE RIESGO
Riesgo del Producto
Riesgo
Producto/Proyecto
Riesgo
Producto/Proyecto
Riesgo del Producto
Riesgo

del
del

del

Página 46

Producto/Proyecto
ID
R01 Magnitud
Alta
Descripción
Este riesgo se puede dar por varios motivos, entre los más comunes
puede ser por problemas emocionales (deceso de algún familiar),
enfermedad o alguna causa externa.
Contingencia
En caso de algún programador pase por estos inconvenientes, a
dicha persona se le otorga un permiso temporal por 3 días.
Para continuar con el proceso de implementación y poder cumplirlo
satisfactoriamente
mi
persona
como
Responsable
de
Implementación tomara el lugar de dicho programador, por el plazo
de 3 días, si el programador no retorna a sus labores en el permiso
propuesto, se procede a rendir un informe hacia el Director de
Proyecto y solicitarle un nuevo programador para cubrir dicho
puesto, para el proceso de contratación se tiene como plazo máximo
de 2 días.
Al ser un riesgo por causas externas al proceso, se supone que es un riesgo
difícil de predecir.

R02

Magnitud
Media
Descripción
Se puede presentar a la hora de realizar el proceso de
Página 47

implementación, teniendo así un impacto en el proceso de desarrollo
del Proyecto.
Contingencia
Si en las primeras etapas de proceso de implementación del
proyecto se demuestra que el ciclo de vida escogido no es el
correcto, se recurre a hacer un informe por parte del Responsable de
Implementación y los Programadores hacia el Director de Proyecto
informando de los inconvenientes de dicho ciclo de Vida.

R03

Para el cambio de Ciclo de Vida se tiene como plazo un máximo de 2
días.
Magnitud
Media
Descripción
El equipo tiene dificultades a la hora de realizar sus objetivos (tanto
de documentación como de implementación) por su inexperiencia
con las herramientas disponibles para el mismo.
Contingencia
Para el entendimiento y uso de las tecnologías ya escogidas se tiene
un plazo de 3 días.

R04

Caso contrario sucediese que no se puede lograr en este tiempo se
amplía a 5 días antes del proceso de desarrollo del Proyecto.
Magnitud
Media
Descripción
El grupo tiene poca experiencia en el desarrollo de software
siguiendo una estructura de tareas y fechas preestablecido.
Contingencia
Si el tiempo de estimación impuesto por el Director de Proyecto no
cubre la totalidad de la implementación del Proyecto, se prosigue a
presentar informes respectivos.
En este caso se está tomando en cuenta que solo se va a trabajar de
Lunes a Viernes, existiendo esta posibilidad de que el tiempo no
Página 48

alcance, se haría un respectivo estudio y análisis de alargar el trabajo
hacia los Fines de Semana.

R05

Magnitud
Alta
Descripción
La pérdida de información, a la vez es casi inevitable, ya sea por
problemas de Software (virus), Hardware (mal funcionamiento de
los equipos).
Contingencia
Se puede perder información ya sea por otros problemas, en este
caso se puede dar un bajón de corriente, este problema ocasionaría
que todos los equipos dejen de funcionar y no permitir guardar
dicha información del proceso de implementación, lo cual conlleva
en gran parte a veces a empezar de cero, en este caso contar con un
dispositivo que permita almacenar energía por un tiempo de
30minutos así permitiendo guardar toda la información,
permitiendo así poder apagar los equipos correctamente y salvando
toda la información.
Como la empresa cuenta con un servidor para el proceso de
Desarrollo, una opción es guardar el proceso de implementación en
dicho servidor.
También se contara con informes periódicamente, documentación
de código tanto digital como documentación impresa.

3.2.4. Prueba y testeo
Identificación de Riesgos
Listado de Riesgos, Tipo de Riesgo
ID
Descripción del Riesgo
R1.
Infección de equipos por virus.

Prioridad
Alta

Tipo de Riesgo
Riesgo del Proyecto

Página 49

R2.

Mala Estimación del tiempo.

Alta

Riesgo del Proyecto

R3.

Alta

Riesgo del Proyecto

R5.
R6.

Incumplimiento de la LEY 164: Ley General de
Telecomunicaciones.
Que el Software no haga los que el Cliente
Espera, si provoca efectos secundarios
adversos.
Que no Cumpla con los Requisitos del Proyecto.
Fallas en el Software y Hardware.

Media
Alta

Riesgo del Producto
Riesgo del Proyecto

R7.

Perdida de Información y documentación.

Alta

Riesgo del Proyecto

R8.

Falta de Comunicación entre los Integrantes

Media

Riesgo del Proyecto

R4.

Alta

Riesgo del
Producto/Proyecto

Se tiene como tiempo estimado para la Pruebas un plazo de 30 días teniendo así 10
días como holgura.
Fase 1: Tiempo estimado 10 días.
Fase 2: Tiempo estimado 8 días, tomando de aquí 2 días para realizar pruebas.
Total días: 40

Análisis de Riesgo
ID
Análisis del Riesgo
R1
Magnitud
Alta
Descripción
Este riesgo se puede dar por varios motivos, Establecimiento de políticas de
seguridad para prevenir el uso de aplicaciones no autorizadas en las estaciones
de trabajo.
Plan de Prevención
Restringir el acceso a Internet a las estaciones de trabajo que por su uso no lo
requieran.
Página 50

Eliminación de disketteras, quemadores de CD, etc. en estaciones de trabajo que
no lo requieran.
Deshabilitar los puertos de comunicación USB en las estaciones de trabajo que
no los requieran habilitados, para prevenir la conexión de unidades de
almacenamiento externo.
Aplicar filtros para restricción de correo entrante, y revisión de archivos
adjuntos en los correos y así prevenir la infección de los terminales de trabajo
por virus.
Contar con antivirus instalados en cada estación de trabajo, el mismo que debe
estar actualizado permanentemente.
Contar con equipos de respaldo ante posibles fallas de las estaciones, para su
reemplazo provisional hasta su desinfección y habilitación.
R2

Magnitud
Alta
Descripción
Se sobreestiman o subestiman el Tiempo para el desarrollo del producto de
software
Plan de Prevención
Si el tiempo de estimación impuesto por el Director de Proyecto no cubre la
totalidad de la implementación del Proyecto, se prosigue a presentar informes
respectivos que demuestren lo contrario.
En este caso se está tomando en cuenta que solo se va a trabajar de Lunes a
Viernes, existiendo esta posibilidad de que el tiempo no alcance, se haría un
respectivo estudio y análisis de alargar el trabajo hacia los Fines de Semana.
Para el cambio de Ciclo de Vida se tiene como plazo un máximo de 2 días.

R3

Magnitud

Página 51

Alta
Descripción
Protocolos, normas y leyes establecidos para el desarrollo del producto de
software
Plan de Prevención
Cumplir con las normas y leyes establecidas en el Proyecto para no correr el
riegos de romper las estructuras.

R4

En caso de incumplimiento de las normas y protocolos se procede a entragar un
informe respectivo solicitando una reunión informativa con el equipo de
implementación, dicha reunión tiene como plazo máximo a realizarse en 2 dias.
Magnitud
Alta
Descripción
Que el software no Realiza lo que el cliente pidió y que tenga efectos secundarios.
Plan de Prevención
Durante la fase de Elaboración se desarrollará en paralelo un prototipo
conteniendo la arquitectura del sistema
para comprobar la validez de la misma.

R5

Si en cada revisión periódica el software presenta falencias significativas tanto
en el proceso de diseño e implementación se procede a la reformulación y reestructuración del proyecto, En este caso la Holgura sobre el tiempo estimado en
el proyecto sería más días.
Magnitud
Media
Descripción
Realización de varias reuniones con el cliente para la aclaración de requisitos y
que estos no fueron cumplidos en el desarrollo del Software.
Plan de Prevención
Se revisarán los requisitos afectados, así como toda la documentación y código
Página 52

R6

derivado de los mismos hasta el punto de aparición del cambio.
Este riesgo está presente en toda Fase del proyecto ya que se puede tomar por
alto algún requerimiento que exige el proyecto.
Magnitud
Alta
Descripción
Fallas y falta de material que se pueden tener en el desarrollo del Software.
Plan de Prevención

Página 53

R7

Magnitud
Alta
Descripción
Por causas varias se pierde parte o el total Información y de la documentación
así como la posibilidad de perder parte o el total de otros artefactos, como
pueden ser: parte de la implementación o ficheros de planificación.
Plan de Prevención
Se usará una forja (repositorio) para el control de versiones. Se realizarán copias
de seguridad en los
ordenadores personales de cada uno de los miembros del equipo de desarrollo.
La perdida de información, a la vez es casi inevitable, ya sea por problemas de
Software (virus), Hardware (mal funcionamiento de los equipos).
Se puede perder información ya sea por otros problemas, en este caso se puede
dar un bajón de corriente, este problema ocasionaría que todos los equipos dejen
de funcionar y no permitir guardar dicha información del proceso de
implementación, lo cual conlleva en gran parte a veces a empezar de cero, en este
caso contar con un dispositivo que permita almacenar energía por un tiempo de
30minutos así permitiendo guardar toda la información, permitiendo así poder
apagar los equipos correctamente y salvando toda la información.
Como la empresa cuenta con un servidor para el proceso de Desarrollo, una
opción es guardar el proceso de implementación en dicho servidor.
También se contara con informes periódicamente, documentación de código
tanto digital como impreso.

Página 54

R8

Magnitud
Alta
Descripción
Durante la realización de un proyecto software, hay muchos artefactos que
realizar y tareas que completar por la totalidad de integrantes del grupo.
Normalmente dichas tareas están relacionadas de alguna manera, y cualquier
cambio independiente en una de ellas afecta al resultado final o a otras tareas.
Plan de Prevención
Realizar reuniones como punto de sincronización y comunicación de nuevas
ideas sobre el proyecto y todo lo relacionado con él.
Mantener una documentación única como medio de documentación centralizado.
Realizar reuniones cada lunes para acordar temas referentes al proyecto así
como las fechas de futuras reuniones.

Parte IV
Estudio de la
Página 55

Pre Factibilidad

4. Introducción
“El estudio de la factibilidad es el encargado de determinar la
infraestructura Tecnológica y capacidad técnica que implica la implantación del
sistema dentro de la empresa, así también los costos, los beneficios y el grado de
aceptación que la propuesta genera dentro de la institución.”.
4.1.

Factibilidad Técnica

Se evalúa dos enfoques muy importantes dentro de la informática que son el
Hardware y el Software.
•

Software:

Sistema Operativo: Windows 7, Android 2.3 en Adelante
Lenguaje de programación: JSP,Java.
IDE (entorno de desarrollo integrado): Netbeans 7.3.
SGDB (data manangentsytem): MySQL.
Case: Enterprise Architect 8
Página 56

•

Hardware:

Servidor de datos.
Dispositivos móviles.
4.2.

Factibilidad Económica

Es la parte donde nos damos cuenta de los costos y ganancias dentro de la empresa.
RRHH
sueldo/mes #mes
total p.
Cargo
$
trab
#Personal $
Director
900
4
1
3600
Analista
700
2
1
1400
A. Analista
400
1
1
400
Diseñador
700
2
1
1400
A. Diseño
400
1
1
400
Programador
700
2
1
1400
A. Programador
400
1
2
800
Ing.
Prueba
Calidad
700
2
1
1400
Capacitador
500
1
1
500
Total F. $

11300

Material
Detalle
Servidor
Computadora
Móvil
Impresora
material de escritorio
Licencia

cantida
d
1
2
1
1
1
0

precio
$
8000
900
400
100
200
0
Total $

utilida
d
0,25
0,5
1
1
1
0

Total p. $
2000
900
400
100
200
0
3600

Precio Total SW
Costo
Detalle
P
RRHH
11300
Material
3600

Página 57

Total P

14900

Ganancia

4470

precio
Proy

19370

Precio Venta Sin Mantenimiento
precio
T
21970
Precio

Cantidad
E
5

precio
V
4394

m/mes c/man serv/a

5272,8 0

100

80

Precio Venta con Mantenimiento
precio
T
21970
Precio

4.3.

Cantidad E precio V m/mes c/man serv/a
5
4394
4394

50

0

50

Factibilidad Operativa

Muy importante ya que a través de esta nos damos de cuenta si el sistema a
desarrollar será puesto en marcha aprovechando los beneficios que el mismo
ofrece a todos los usuarios involucrados con el mismo. Dentro de este también se
suministran las herramientas para el uso del nuevo sistema ya sea la capacitación
necesaria.
El sistema operativo que deben utilizar es el SO Windows 7 en adelante esto para el
administrador del servicio, también dispositivo móviles con sistema operativo
Android 2.3 en adelante para el operador que se encargara de llevar el producto, la
cantidad dispositivos depende de la cantidad de usuarios logísticos. Y también se

Página 58

contempla talleres de capacitación para los usuarios tanto administradores como
también móviles.
4.4.

Factibilidad Legal

Es donde realizamos algunos documentos de contrato y reportes para el
seguimiento del desarrollo de la aplicación.
• Reporte de problemas
Formulario 1 Es el documento con el cual realizamos el reporte de los problemas
para hacer conocer a todo el personal involucrado en el proyecto.
• Reporte de Tareas
Formulario 2 Es el documento que nos permite comunicarnos entre especialistas
de área para llevar un control más detallado.
• Reporte de Tareas
Formulario 3 Es el documento que nos permite firmar un contrato con el cliente
con las especificaciones detalladas llegando a un acuerdo con el cliente, el tema de
mantenimiento y hospedaje más puntual.

Parte V
Página 59

Motivación

5. MOTIVACIÓN GENERAL
MOTIVACION EQUIPO DE DESARROLLO:
 Interés en el proyecto: Intentar conseguir proyectos interesantes y
asignarlos a las personas menos motivadas y con un índice de motividad
alto. Es necesario que lo vean como una oportunidad para expresar su
capacidad. Por supuesto esto varía dependiendo de los intereses de cada
uno, por eso es importante conocer a las personas, averiguar sus intereses y
tener comunicación continua.
 Formación y conocimiento recibido: Es muy importante que la gente se
forme en cursos o de compañeros de más nivel y aprenda nuevas
tecnologías y técnicas de desarrollo. Creo que este aspecto nos diferencia de
otras profesiones, la necesidad imperiosa del reciclaje tecnológico.
 Ambiente de trabajo: Para mejorar el ambiente de trabajo es necesario
transmitir cercanía, cordialidad y compañerismo, no excederse en la
presión, promover la justicia entre compañeros y evitar las rivalidades y
enfrentamientos. En definitiva tratar de crear un grupo de compañeros que
Página 60









5.1.

tengan un objetivo común y velen por su cumplimiento de una forma
agradable.
Salario percibido: Esto es lo más complicado pero creo que dentro de
nuestras posibilidades tenemos que intentar ser justos y evidenciar y
notificar las injusticias en este aspecto.
Responsabilidad y confianza: Dar responsabilidad a alguien denota
confianza y por lo tanto es una compensación y una expresión de un
trabajo previo bien hecho.
Horario flexible: La diferencia entre un trabajo manufacturero y uno
artístico, como es la construcción de software, reside en el número de
decisiones que se toman por unidad de tiempo, y para tomar esas
decisiones de la manera más eficiente debemos tener un estado mental de
alta concentración, es por ello que aunque sí es bueno que tengamos un
horario marco de trabajo, no debamos ceñirnos a él, al son de una bocina.
Evolución profesional: Es importante generar perspectivas de crecimiento
profesional en las personas, mantener un cierto grado de ilusión, por una
progresión, que, aunque no sea inmediata es algo que se valora a la hora de
elegir un empleo y creo que también influye en la motivación, al menos a mi
me influye. También es importante para tu propio crecimiento, que el
equipo crezca contigo.

MOTIVACIÓN POR ÁREAS

5.1.1. Requerimientos y Análisis
Formación y conocimiento recibido: Es muy importante motivar
con cursos de capacitación o de compañeros de más nivel y aprenda
nuevas tecnologías y técnicas de diseño.
 Responsabilidad y confianza: Dar responsabilidad a alguien denota
 Horario flexible: La diferencia de trabajo con otros tipos de trabajos,
reside en el número de decisiones que se toman por unidad de
tiempo, y para tomar esas decisiones de la manera más eficiente
debemos tener un estado mental de alta concentración, es por ello
que aunque sí es bueno que tengamos un horario marco de trabajo,
no debamos ceñirnos a él, al son de una bocina.


Página 61

5.1.2. Diseño
 Formación y conocimiento recibido: Es muy importante motivar
con cursos de capacitación o de compañeros de más nivel y aprenda
nuevas tecnologías y técnicas de diseño.
 Responsabilidad y confianza: Dar responsabilidad a alguien denota
 Horario flexible: La diferencia de trabajo con otros tipos de trabajos,
reside en el número de decisiones que se toman por unidad de
tiempo, y para tomar esas decisiones de la manera más eficiente
debemos tener un estado mental de alta concentración, es por ello
que aunque sí es bueno que tengamos un horario marco de trabajo,
no debamos ceñirnos a él, al son de una bocina.

5.1.3. Implementación
 Formación y conocimiento recibido: Es muy importante
motivar con cursos de capacitación o de compañeros de más
nivel y aprenda nuevas tecnologías y técnicas de diseño.
 Responsabilidad y Confianza: Dar responsabilidad a alguien
denota confianza y por lo tanto es una compensación y una
expresión de un trabajo previo bien hecho.
 Horario flexible: La diferencia de trabajo con otros tipos de
trabajos, reside en el número de decisiones que se toman por
unidad de tiempo, y para tomar esas decisiones de la manera
más eficiente debemos tener un estado mental de alta
concentración.

Página 62

Pap app delivery

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (8)

Similar a Pap app delivery

Similar a Pap app delivery (20)

Último

Último (20)

Pap app delivery