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

PARTE I..............................................................................................................................4

1.1 INTRODUCCIÓN.......................................................................................................................51.2 DEFINICION DEL PROBLEMA.................................................................................................51.3 SITUACION PROBLEMÁTICA..................................................................................................61.4 SITUACION DESEADA..............................................................................................................61.5 OBJETIVOS...............................................................................................................................6

1.5.1 Objetivo General...................................................................................................................61.5.2 Objetivos específicos............................................................................................................7

1.6 JUSTIFICACIÓN........................................................................................................................71.7 ALCANCE..................................................................................................................................8

1.7.1 Cliente..................................................................................................................................81.7.2 Solicitud de pedidos.............................................................................................................81.7.3 Empresa...............................................................................................................................8

1.8 VENTAJAS.................................................................................................................................8

PARTE II.............................................................................................................................9

2 2.1 ESTRUCTURA ORGANIZACIONAL...................................................................10

3 2.2 CRONOGRAMA DE TRABAJO...........................................................................10

PARTE III.........................................................................................................................24

INTRODUCCIÓN..............................................................................................................24

PROPÓSITO..............................................................................................................................................25ALCANCE.................................................................................................................................................25

3.1. GESTIÓN DEL RIESGO........................................................................................25

3.1.1. IDENTIFICACIÓN DE RIESGOS.......................................................................................................253.1.2. ANÁLISIS DEL RIESGO.................................................................................................................263.1.3. ACCIONES DE PREVENCIÓN Y DE CORRECCIÓN..............................................................................333.1.4. CONTROL Y SEGUIMIENTO DE RIESGOS.........................................................................................36

3.1.5. MATRIZ DE RIESGO........................................................................................36

PARTE IV.........................................................................................................................55

4. INTRODUCCIÓN...............................................................................................................................554.1. Factibilidad Técnica..........................................................................................................56 Software:.................................................................................................................................56 Hardware:...............................................................................................................................564.2. Factibilidad Económica.....................................................................................................564.3. Factibilidad Operativa.......................................................................................................584.4. Factibilidad Legal..............................................................................................................58

PARTE V...........................................................................................................................59

5. MOTIVACIÓN GENERAL.........................................................................................60

5.1.1. REQUERIMIENTOS Y ANÁLISIS.....................................................................................................615.1.2. DISEÑO.....................................................................................................................................61

Página 2

5.1.3. IMPLEMENTACIÓN......................................................................................................................61

Parte VI............................................................................................................................63

Página 3

Parte IPerfil de Proyecto

“En esta parte del proyecto se presenta la introducción al proyecto paraque 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 IIPlan 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.

ResponsableDías Trabajados

Detalle de trabajo

HolguraFecha Inicio

Fecha final

Total de días asignado

Scrum Master 16 Realizar el 4 18/11/2 10/12/201 20

Página 10

control del proceso de construcción del proyecto coordinando con los diferentes responsables de área

013 3

Product Owner

16

Realizar la gestión y el control de todos los procesos de análisis, Diseño, implementación y prueba junto a su equipo de trabajo Team.

1620/11/2013

06/12/2013

16

Teams (Developer’s)

16

Realizar la gestión de todos los procesos de análisis, Diseño, implementación y prueba junto con el Product Owner.

1620/11/2013

06/12/2013

16

Prueba y Testeo

16

Realizar el control de todos los procesos deprueba y testeo de la aplicación

1014/10/2013

06/12/2013

16

Gestión de configuración

16

Realizar el control de todos los cambios de la aplicación

1614/12/2013

06/12/2013

16

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

Cantidad E

precio V m/mes c/man serv/a

21970 5 4394      

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 Cantidad E precio V m/mes c/man serv/a21970 5 4394                 Precio   4394 50 0 50           

2.5 CRONOGRAMA POR ÁREA

2.5.1 Requerimientos y análisis

Detalle del Cronograma.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ñoCRONOGRAMA DE ACTIVIDADESTiempo Total para el Diseño de Software es de 44 días Hábiles.

Fase 1: Diseño de Paquetes (Subsistemas)- El tiempo para completar exitosamente esta fase es de 6 días.

Página 14

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- El tiempo para completar exitosamente esta fase es de 6 días.

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.El tiempo para las pruebas es de 2 días.

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.

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.

El tiempo para las pruebas es de 3 días.

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.

Página 15

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

Detalle del Cronograma.Tiempo Total para el Desarrollo es de 30 días.Fase 1: Investigación y Elección del Protocolo de Comunicación

- El tiempo para completar exitosamente esta fase es de 4 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.

Día 3- 4:

Página 16

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)- El tiempo para completar exitosamente esta fase es de 5 días.

Día 1 – 2Implementación del Servidor de acuerdo al protocolo de comunicación.

Día 3 – 4 - 5Implementació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.

Fase 3: Desarrollo del Segundo Módulo (Módulo Cliente)- El tiempo de implementación para completar esta fase exitosamente es de 4

días.

Día 1 - 2Implementación de todos los casos de usos involucrados para completar este módulo.

Día 3 - 4Implementació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.

Página 17

Fase 4: Desarrollo del Tercer Módulo (Módulo Solicitudes)- El tiempo de implementación para completar esta fase exitosamente es de 5

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 – 5En 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.

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 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 – 4Implementar todos los casos de usos definidos, incluyendo la implementación de los prototipos de interfaz gráfica.

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.

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.

Página 18

El tiempo total para el desarrollo es de 30 días, teniendo así 10 días restantes como holgura en caso de alguna de las fases no se cumpla en el plazo determinado.

Vista gráfica.

2.5.4 Calidad y testeo.

Detalle del Cronograma.Tiempo Total para el Desarrollo de Pruebas y Calidad en cada Área es de 40 días.Fase 1: Análisis y Requerimiento

- El tiempo para completar exitosamente esta fase es de 10 días.

Día 1 - 2:Enumerar Requisitos Candidatos.

Página 19

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- El tiempo para completar exitosamente esta fase es de 10 días.

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.

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.

Página 20

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 protocolos de comunicación.

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 todos los casos de usos definidos y la implementación de los prototipos de interfaz Gráfica.

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 – 5En este tiempo planteado, se tiene que llevar a cabo todas las pruebas de todos los casos de usos definidos y la implementación de los prototipos de interfaz Gráfica del Software terminado.

Página 21

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 holgura en caso de alguna de las fases no se cumpla en el plazo determinado.

Vista gráfica.

Página 22

Página 23

Parte IIIEstudio de análisis de Riesgo

3. RIESGO GENERAL

Página 24

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.

3.1. Gestión del Riesgo

3.1.1.  Identificación de Riesgos

Página 25

Listado de Riesgos, Tipo de Riesgo

ID Descripción del Riesgo Tipo de Riesgo

R01 Requisitos poco claros Riesgo del Producto

R02 Abandono temporal de un miembro del equipo

Riesgo del Proyecto

R03 Falta de Experiencia en tareas de planificación

Riesgo del Proyecto

R04 Falta de Experiencia con las herramientas utilizadas

Riesgo del Producto/Proyecto

R05 Diseño Erróneo Riesgo del Producto

R06 Falta de un Experto Riesgo del Proyecto

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

Riesgo del Proyecto

R08 Conflictos entre los integrantes del grupo Riesgo del Proyecto

R09 Inestabilidad del entorno de desarrollo y documentación el proyecto

Riesgo del Proyecto

R10 Estimación de costos fuera del alcance de la realidad

Riesgo del Proyecto

R11 Falta de seguimiento permanente de tareas y actividades

Riesgo del Proyecto

R12 Aprendizaje de JSF Riesgo del Proyecto

R13 Falta de comunicación entre los integrantes del grupo.

Riesgo del Proyecto

3.1.2. Análisis del Riesgo

ID Análisis del Riesgo

R01Magnitud

Variable según la fase de aparición: Inicio: baja. Elaboración: media. Construcción: alta.

Página 26

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.

R02Magnitud

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

Página 27

falta de disponibilidad de personal puede suponer una pérdida de calidad en el producto.

IndicadoresNinguno. 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. Elaboración: media. Construcción: alta. Transición: alta.

Descripción

Página 28

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 no cumple las expectativas. Se complica la implementación.

R06 MagnitudMedia.

Página 29

DescripciónNo hay un experto del dominio en el equipo de desarrollo al que poder consultar.

ImpactoPuede suponer retrasos.

IndicadoresNo procede

R07 MagnitudAlta.

DescripciónPor 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.

ImpactoVariable, puede suponer una catástrofe, o un simple retraso.

IndicadoresNinguno.

R08 MagnitudMedia.

DescripciónAparición de problemas y discrepancias entre los miembros del proyecto. Falta de acuerdo en las decisiones tomadas.

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

IndicadoresMucho tiempo dedicado a decisiones concretas, énfasis en las posturas enfrentadas, número de enfrentamientos con respecto a una misma

Página 30

decisión.

R09 MagnitudAlta

DescripciónTanto el proceso de desarrollo como el de documentación se soportan sobre un servidor gratuito que puede sufrir caídas intermitentes.

ImpactoPuede generar desconfianza en el cliente en cuanto a la calidad del producto desarrollado.

IndicadoresLa página donde se encuentre alojado el proyecto demora mucho en cargar y/o no carga.

R10MagnitudMedia

DescripciónSe sobreestiman o subestiman los costos involucrados con el desarrollo del producto de software

ImpactoPuede 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

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

R11 MagnitudMedia

DescripciónNo se realiza un seguimiento de las tareas planificadas para cada sprint, lo que puede ocasionar que algunas de ellas sean dejadas para última

Página 31

instancia, con la consecuente baja en su calidad

ImpactoSobrecarga de trabajo en los días previos a la entrega de un presentable, pobre calidad de los entregables, se obvian detalles importantes.

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

R12 MagnitudAlta

DescripciónEl 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.

ImpactoPuede generar retrasos así como también que se vuelvan a desarrollar módulos que ya se encontraban terminados.

IndicadoresEl cliente y/o el jefe de proyecto anuncia al equipo el cambio de tecnología.

R13 MagnitudMedia

DescripciónDurante 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.

ImpactoPueden producirse duplicación de tareas.

Indicadores

Página 32

Conflictos entre los artefactos desarrollados.

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

ID Plan de Prevención Plan de CorrecciónR01 Realización de varias reuniones

con el cliente; elaboración de cuestionarios para aclarar puntos poco claros de las reuniones previas.

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 lasmodificaciones/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.

R02 Tratar de cumplir las metas y objetivos antes de lo estimado en la planificación siempre que sea posible, paraque 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.

R03 El uso de Scrum como proceso de desarrollo. Realización de

Se observarán las diferencias entre la planificación de cada iteración y

Página 33

reuniones entre los miembros del proyecto parala evaluación de la marcha del proyecto y consultas al tutor.

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 desarrollo del proyecto se destinará al aprendizaje de las nuevas herramientas.

Si se produce un retraso en el aprendizaje por parte de un miembro del equipo, los demás miembros tratarán de ayudar a superarlo. Si no resultara, consultar a fuentes externas como profesores, bibliografía, foros enInternet. 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 sistemapara comprobar la validez de la misma. En caso de encontrase errores o inconsistencias, podrá modificarse eldiseño al mismo tiempo que la implementación del prototipo.

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.

R06 Aprendizaje continúo durante todo el proyecto

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

R07 Se realizarán copias de seguridad en los ordenadores personales de cada uno de los miembros del equipo, así como copias en un servidor remoto

Actualizar con la última copia disponible

R08 Cada vez que se fije un punto de Se establecen las siguientes reglas

Página 34

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.

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.

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

R10 Realizar estimaciones en base a varias herramientas para tratar de hallar un estimado más cercano a la realidad

Redimensionar el proyecto conforme se va desarrollando y nuevas funcionalidades se agregan o se eliminan.

R11 Llevar al día una revisión del estado del proyecto para anotar los posibles atrasos y poder asi tomar medidas en el instante.

Realizar una recandelirización de tareas, así como llamadas de atención a los miembros del equipo que dejen sus tareas para última instancia.

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

En caso de que el aprendizaje sea demasiado costoso, la tecnología de programación de “salvaguarda” será PHP.

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.

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. Responsable Fecha de Terminación Estado ObservacionesR01 Analista Fin del Proyecto IniciadoR02 Jefe de

ProyectoFin del Proyecto Iniciado

R03 Jefe de Proyecto

Fin del Proyecto Iniciado

R04 Programador/Tester

Fin del Proyecto Iniciado

R05 Analista/Arquitecto

Fin del Proyecto Iniciado

R06 Equipo de Desarrollo

Fin del Proyecto Iniciado

R07Programador

Fin del Proyecto Iniciado

R08 Equipo de Desarrollo

Fin del Proyecto Iniciado

R09 Equipo de desarrollo

Fin del proyecto Iniciado

R10 Analista Fin del proyecto IniciadoR11 Jefe del

proyectoFin del proyecto Iniciado

R12 Programador Fin del proyecto 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

TipoRiesgo

Probab.Ocurrencia

Nivel deImpacto

Evaluacióndel Riesgo

Acciones de Prevención

Acción de Corrección

R01

Cambios en los Requisitos

Producto

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

R02

Bajas en el Equipo de Desarrollo

Proyecto

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

Reasignar ciertas tareas a otros miembros según vayan siendo necesarios los artefactos para la consecución de los hitos.

R0 Falta de Proyect 50 2 1 Realización de Se

Página 37

3 Experiencia en tareas de planificación

o reuniones entre los miembros del proyecto parala evaluación de la marcha del proyecto y consultas al tutor.

observarán las diferencias entre la planificación de cada iteración y el informe de seguimiento de suejecución, para tratar de detectar y corregir errores de planificación enlas iteraciones posteriores.

R04

Falta de Experiencia con las herramientas utilizadas

Producto/Proyecto

50 2 1 Una parte del tiempo de desarrollo del proyecto se destinará al aprendizaje de las herramientas dedocumentación e implementación.

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

Página 38

R05

Diseño Erróneo

Producto

40 3 1.2 Durante la fase de Elaboración se desarrollará en paralelo un prototipo conteniendo la arquitectura del sistemapara comprobar la validez de la misma.

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

R06

Falta de un Experto

Proyecto

80 1 0.8 Aprendizaje continúo durante todo el proyecto

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

R07

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

Proyecto

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

Actualizar con la última copia disponible

R08

Conflictos entre los

Proyect 75 2 1.5 Se celebrarán reuniones de

Establecer las reglas

Página 39

integrantes del grupo

o proyecto para poder discutir cuestiones de requisitos y diseño.

para definir una política de toma de decisiones en caso de desacuerdo.

R09

Inestabilidad del entorno de desarrollo y documentación el proyecto

Proyecto

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.

R10

Mala estimación de costos

Proyecto

50 3 1.5 Realización de varias estimaciones con metodologías diferentes

Redimensionar el proyecto conforme se ejecuta

R11

Falta de seguimiento de tareas

Proyecto

50 3 1.5 Planificación adecuada de tareas, seguimiento del desarrollo de las mismas usando SVN

Recandelerización de las tareas, charla con el equipo de desarrollo en caso de detectarse malas prácticas.

R12

Aprendizaje de JSF

Proyecto

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

Utilizar PHP como tecnología de programación “salvaguarda”.

R1 Falta de Proyect 20 2 0.4 Mantener una Realizar

Página 40

3 Comunicación entre los Integrantes

o documentación única como medio de documentación centralizado.

reuniones informativas a la salida de clase.

3.2. RIESGO POR ÁREAS

3.2.1. Requerimientos y Análisis

IDENTIFICACION DE RIESGOSListado de riesgos, tipos de riesgos.

ID DESCRIPCION DEL RIESGO TIPO DE RIESGOR01 El cliente cambiará los requisitos. Riesgo del Producto.R02 Mala comunicación con el cliente. Riesgo del

Producto/Proyecto.R03 Mala elección de ciclo de vida. Riesgo del

Producto/Proyecto.R04 Renuncia de un analista. Riesgo del Producto.R05 Mala estimación de esfuerzo y tiempo. Riesgo del

Producto/Proyecto.R06 Herramienta de desarrollo desconocido. Riesgo del Producto.R07 Analistas sin experiencia. Riesgo del Producto.R08 Retiro parcial de un analista. Riesgo del Producto.

ANÁLISIS DEL RIESGO

ID ANÁLISIS DEL RIESGOR01 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

Página 41

largo avance de dicho proyecto.

Contingencia

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 Magnitud Alto

DescripciónEl cliente por diferentes motivos ya sea de trabajo, familiar, etc. No tendría mucho tiempo para poder acudir a nuestras entrevistas propuestas.

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

R03 Magnitud Medio

DescripciónEl grupo de trabajo podría elegir un ciclo de vida inadecuado.

ContingenciaEn 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

Página 42

Medio

Descripción Por algún motivo ya sea conocido o desconocido podría renunciar un analista.

ContingenciaMi 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 MagnitudBajo

DescripciónLa estimación podría variar de acuerdo a lo establecido tanto en tiempo como en esfuerzo.

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

Página 43

R06 MagnitudBajo

DescripciónLa herramienta elegida para desarrollar los diferentes podría ser desconocida para los analistas.

ContingenciaEn este caso de inmediato se hará la capacitación respectiva para que estos puedan desarrollar sus funciones de manera óptima.

R07 MagnitudBajo

DescripciónEl grupo tiene poca experiencia en el área de trabajo.

ContingenciaOrganizar cursos de capacitación para el personal ya existente, investigar la posibilidad de contratar en otras regiones del país

R08 MagnitudBajo

DescripciónPor muchos factores un analista podría dejar el cargo parcialmente.

ContingenciaReorganizar 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 DESCRIPCION DEL RIESGO TIPO DE RIESGOR01 Integrante del equipo de Diseño se retire Riesgo del Producto

Página 44

del proyecto.R02 Estrategia de Diseño desconocido. Riesgo del

Producto/ProyectoR03 Herramienta de Diseño desconocido Riesgo del

Producto/ProyectoR04 Mala estimación y planificación de tiempo

debido a no contemplar actividades ajenas al proyecto.

Riesgo del Producto

R05 Problemas de comunicación entre los Diseñadores.

Riesgo del Producto/Proyecto

ANÁLISIS DEL RIESGO DISEÑOID ANÁLISIS DEL RIESGOR01 Magnitud

Alta

DescripciónAl ser un riesgo por causas externas al proceso, se supone que es un riesgo difícil de predecir.

Contingencia

Redefinir las funciones de los integrantes.No saturar de manera desmedida el trabajo.

R02 MagnitudMedia

DescripciónSe 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.

ContingenciaTrabajar de manera organizada y minuciosamente, empleando toda la documentación posible acerca de la estrategia a utilizar.

R03 MagnitudMedia

DescripciónEste riego se puede presentar al momento de realizar el diseño

Página 45

o cambiar el diseño en último momento.Contingencia

Buscar información y ayuda en el manejo la misma.Trabajar con herramientas empleadas previamente.

R04 MagnitudMedia

DescripciónEn 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.

ContingenciaContemplar dentro de la planificación de tiempo un tiempo de demora asumiendo cualquier tipo de eventualidad.

R05 MagnitudMedia

Descripción

Realizar actividades para incentivar la Buena Comunicación entre compañeros.

ContingenciaEspecificar 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 RIESGOSListado de riesgos, tipos de riesgos.ID DESCRIPCION DEL RIESGO TIPO DE RIESGOR01 Retiro Parcial o Definitivo de un Programador Riesgo del ProductoR02 Mala comprensión en el uso del Ciclo de Vida Riesgo del

Página 46

Producto/ProyectoR03 Curva de Aprendizaje en el uso de Tecnologías Riesgo del

Producto/ProyectoR04 Tiempo de Estimación Riesgo del ProductoR05 Perdida de Información Riesgo del

Producto/Proyecto

ANÁLISIS DEL RIESGOID ANÁLISIS DEL RIESGOR01 Magnitud

Alta

DescripciónEste 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.

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

Página 47

R02 MagnitudMedia

DescripciónSe puede presentar a la hora de realizar el proceso de implementación, teniendo así un impacto en el proceso de desarrollo del Proyecto.

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

Para el cambio de Ciclo de Vida se tiene como plazo un máximo de 2 días.

R03 MagnitudMedia

DescripciónEl 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.

ContingenciaPara el entendimiento y uso de las tecnologías ya escogidas se tiene un plazo de 3 días.

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.

R04 MagnitudMedia

DescripciónEl grupo tiene poca experiencia en el desarrollo de software siguiendo una estructura de tareas y fechas preestablecido.

ContingenciaSi el tiempo de estimación impuesto por el Director de Proyecto no

Página 48

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 alcance, se haría un respectivo estudio y análisis de alargar el trabajo hacia los Fines de Semana.

R05 MagnitudAlta

DescripciónLa pérdida de información, a la vez es casi inevitable, ya sea por problemas de Software (virus), Hardware (mal funcionamiento de los equipos).

ContingenciaSe 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

Página 49

Identificación de Riesgos

Listado de Riesgos, Tipo de RiesgoID Descripción del Riesgo Prioridad Tipo de Riesgo

R1. Infección de equipos por virus. Alta Riesgo del Proyecto

R2. Mala Estimación del tiempo. Alta Riesgo del Proyecto

R3. Incumplimiento de la LEY 164: Ley General de Telecomunicaciones.

Alta Riesgo del Proyecto

R4. Que el Software no haga los que el Cliente Espera, si provoca efectos secundarios adversos.

Alta Riesgo del Producto/Proyecto

R5. Que no Cumpla con los Requisitos del Proyecto. Media Riesgo del ProductoR6. Fallas en el Software y Hardware. Alta 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

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.Fase 3: Tiempo estimado 8 días, tomando de aquí 2 días para realizar pruebas.Fase 4: Tiempo estimado 8 días, tomando de aquí 2 días para realizar pruebas.Total días: 40

Análisis de RiesgoID Análisis del RiesgoR1 Magnitud

Alta

DescripciónEste riesgo se puede dar por varios motivos, Establecimiento de políticas de

Página 50

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. 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ónSe 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

Página 51

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

Alta

DescripciónProtocolos, 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.

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.

R4 Magnitud

Alta

DescripciónQue el software no Realiza lo que el cliente pidió y que tenga efectos secundarios.

Plan de PrevenciónDurante la fase de Elaboración se desarrollará en paralelo un prototipo conteniendo la arquitectura del sistemapara comprobar la validez de la misma.

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 re-estructuración del proyecto, En este caso la Holgura sobre el tiempo estimado en el proyecto sería más días.

R5 Magnitud

Media

Página 52

DescripciónRealizació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ónSe 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.Este riesgo está presente en toda Fase del proyecto ya que se puede tomar por alto algún requerimiento que exige el proyecto.

R6 Magnitud

Alta

DescripciónFallas y falta de material que se pueden tener en el desarrollo del Software.

Plan de Prevención

R7 Magnitud

Alta

DescripciónPor 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 losordenadores 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

Página 53

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.

R8 MagnitudAlta

DescripciónDurante 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ónRealizar 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.

Página 54

Parte IVEstudio de la 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.”.

Página 55

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 AdelanteLenguaje de programación: JSP,Java.IDE (entorno de desarrollo integrado): Netbeans 7.3.SGDB (data manangentsytem): MySQL.Case: Enterprise Architect 8

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

Cargosueldo/mes $

#mes trab #Personal

total p. $

Director 900 4 1 3600Analista 700 2 1 1400A. Analista 400 1 1 400Diseñador 700 2 1 1400A. Diseño 400 1 1 400Programador 700 2 1 1400A. Programador 400 1 2 800Ing. Prueba Calidad 700 2 1 1400Capacitador 500 1 1 500             Total F. $   11300

Material

Detalle cantidadprecio $ utilidad Total p. $

Servidor 1 8000 0,25 2000Computadora 2 900 0,5 900Móvil 1 400 1 400

Página 56

Impresora 1 100 1 100material de escritorio 1 200 1 200Licencia 0 0 0 0             Total $   3600

Precio Total SW

DetalleCosto P

RRHH 11300Material 3600   Total P 14900   Ganancia 4470   precio Proy 19370

Precio Venta Sin Mantenimiento           precio T

Cantidad E

precio V m/mes c/man serv/a

21970 5 4394                 Precio   5272,8 0 100 80           

Precio Venta con Mantenimiento           precio T Cantidad E precio V m/mes c/man serv/a21970 5 4394                 Precio   4394 50 0 50

Página 57

           

4.3. 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 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 problemasFormulario 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 TareasFormulario 2 Es el documento que nos permite comunicarnos entre especialistas de área para llevar un control más detallado.

Reporte de TareasFormulario 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.

Página 58

Parte VMotivación

5. MOTIVACIÓN GENERAL

Página 59

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

5.1. MOTIVACIÓN POR ÁREAS

Página 60

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

Página 61

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

Parte VIAnexo

Formulario 1

Página 63

Formulario 2

Página 64

Formulario 3

Página 65

Página 66