Plan de Administración del Proyecto de Software. (PAPS)
Transcript of Plan de Administración del Proyecto de Software. (PAPS)
Universidad Autónoma Gabriel Rene Moreno.
Facultad de Tecnología
Maestría en Ingeniería de Software
Plan de Administración del Proyecto de Software.
(PAPS)
Sistema integrado de información para la gestión de operaciones en el área de
comercialización, inventarios y recursos humanos para la Cadena Nacional de
Farmacias FarmaCorp.
Módulo Introducción a la Ingeniería de software
Docente Ing. José Antonio Benavente B.
Alumno Ing. Ernesto Soto Roca.
Santa Cruz - Bolivia
Plan de Administración del Proyecto de Software
2
TABLA DE CONTENIDO
Plan de Administración del Proyecto de Software. .................................................. 1 1.1. Introduccion ............................................................................................................. 7 1.2. Antecedentes ............................................................................................................ 8
1.3. Planteamiento del problema ..................................................................................... 9 1.3.1. Situación Problemática ..................................................................................... 9 1.3.2. Situación Deseada........................................................................................... 12
1.4. Delimitaciones ....................................................................................................... 12 1.5. Objetivos ................................................................................................................ 12
1.5.1. Objetivo General............................................................................................. 12
1.5.2. Objetivos Específicos .................................................................................... 12
1.6. Justificación ........................................................................................................... 13 1.6.1. Justificación Teórica ....................................................................................... 13 1.6.2. Justificación Metodológica ............................................................................. 13 1.6.3. Justificación Practica ...................................................................................... 13
1.7. Diseño Metodológico ............................................................................................. 14 1.7.1. Tipo de Investigación ..................................................................................... 14
1.7.2. Procesos Metodológicos ................................................................................. 14 1.7.3. Métodos .......................................................................................................... 15 1.7.4. Técnicas para recolección de información ..................................................... 15
1.7.4.1. Fuentes Primarias: ....................................................................................... 15
1.7.4.2. Fuentes Secundarias: ................................................................................... 15
1.7.5. Recursos utilizados ......................................................................................... 15 1.8. Alcance .................................................................................................................. 16
1.8.1. Requerimientos funcionales. .............................................................................. 16 1.8.2. Requerimientos no funcionales. ........................................................................ 18 1.8.2.1. Especificaciones Suplementarias .................................................................... 18
1.8.2.2. Tiempo de aprendizaje.................................................................................... 18 1.8.2.3. Identificación del usuario propio de la aplicación .......................................... 18
1.8.2.3.1. Contraseña de usuario ................................................................................. 19 1.8.2.4. Confiabilidad .................................................................................................. 19 1.8.2.4.1. Tiempo de disponibilidad del sistema ........................................................ 19
1.8.2.4.2. Tiempo comprendido entre fallas ............................................................... 19 1.8.2.4.3. Tiempo fuera de servicio ............................................................................ 19 1.8.2.4.4. Registro de eventos ..................................................................................... 20 1.8.2.5. Performance .................................................................................................... 20
1.8.2.5.1. Acceso de clientes en línea ......................................................................... 20 1.8.2.5.2. Tiempo de respuesta ................................................................................... 20 1.8.2.5.3. Cantidad de atención a usuarios .................................................................. 20 1.8.2.6. Soportabilidad o Facilidad de Mantenimiento................................................ 20 1.8.2.6.1. Actualización transparente al usuario ......................................................... 20
1.8.2.7. Estándares de codificación ............................................................................. 20 1.8.2.8. Restricciones de Diseño.................................................................................. 20
1.8.2.8.1. Estándares de diseño ................................................................................... 20 1.8.2.8.2. Estándares de arquitectura .......................................................................... 21
Plan de Administración del Proyecto de Software
3
1.8.2.9. Motor de base de datos ................................................................................... 21 1.8.2.10. Cliente del navegador ..................................................................................... 21 1.8.2.11. Servidor Web .................................................................................................. 21
1.8.2.12. Lenguaje de programación ............................................................................. 21 1.8.2.13. Requerimientos de documentación, ayuda en línea y manuales, asistencia
técnica. 21 1.8.2.13.1. Manual de Usuario ...................................................................................... 21 1.8.2.13.2. Ayuda en línea ............................................................................................ 21
1.8.2.13.3. Guías de Instalación y Configuración ......................................................... 21 1.8.2.13.4. Apoyo Técnico ............................................................................................ 21 1.8.2.14. Interfaces ........................................................................................................ 22
1.8.2.14.1. Interfaz de usuario ...................................................................................... 22 1.8.2.14.2. Interfaz de Hardware................................................................................... 22 1.8.2.14.3. Interfaz de Comunicaciones ........................................................................ 22 1.8.2.14.4. Interfaces de Software ................................................................................ 22
1.8.2.15. Requerimientos de Licencias .......................................................................... 22
1.8.2.16. Legales, Derechos de Autor y Otras notas ..................................................... 23 1.8.2.17. Estándares Aplicables ..................................................................................... 23 1.8.2.18. Puesta en Marcha ............................................................................................ 23
1.9. Métricas. ................................................................................................................ 24 1.9.1. Métricas orientadas al tamaño. ........................................................................... 24
1.9.1.1. Datos históricos de proyectos de gestión. ....................................................... 24
1.9.2. Métricas orientadas a la función......................................................................... 24
1.10. Estimaciones....................................................................................................... 25 1.10.1. Estimaciones basadas en líneas de código. ..................................................... 25
1.1.1. Estimaciones COCOMO. (COnstructive COst MOdel) .................................... 27 1.1.2. Estimaciones Basadas en punto función. ........................................................... 29 Fuente: Elaboración propia ............................................................................................... 29
Fuente: Elaboración propia ............................................................................................... 30 1.2. Análisis de Riesgo. ................................................................................................ 31
Fuente: Elaboración propia ............................................................................................... 32 1.2.1. Planificación del riesgo. ..................................................................................... 33
Fuente: Elaboración propia ............................................................................................... 36
1.2.2. Análisis de consecuencias del riesgo ................................................................. 37
Fuente: Elaboración propia ............................................................................................... 38 Fuente: Elaboración propia ............................................................................................... 40 1.2.3. Análisis de los datos obtenido: ........................................................................... 41 1.3. Planificación Temporal .......................................................................................... 41 1.3.1. Identificación de tareas : .................................................................................... 41
Fuente: Elaboración propia ............................................................................................... 41 1.3.2. Diagrama de Gantt ............................................................................................. 42 1.3.3. Diagrama de red ................................................................................................. 43 1.3.3.1. Fase de inicio .................................................................................................. 43 Fuente: Elaboración propia ............................................................................................... 43
1.3.3.2. Fase de elaboración ........................................................................................ 44 Fuente: Elaboración propia ............................................................................................... 44
1.3.3.3. Fase de construcción ....................................................................................... 45
Plan de Administración del Proyecto de Software
4
Fuente: Elaboración propia ............................................................................................... 45 1.3.3.4. Fase de transición. .......................................................................................... 46 Fuente: Elaboración propia ............................................................................................... 46
1.4. Organización Interna .............................................................................................. 47 1.4.1. Estructura. .......................................................................................................... 47 Fuente: Elaboración propia ............................................................................................... 47 1.4.2. Paradigma de la organización. ........................................................................... 47 1.4.3. Organización del equipo..................................................................................... 47
1.5. Recursos ................................................................................................................. 48 1.6. Recursos Humanos. ............................................................................................... 48 1.7. Equipos: ................................................................................................................. 48
1.8. Costo del Proyecto ................................................................................................. 48 ANEXO ............................................................................................................................ 49
ANEXO A-01. ........................................................................................................ 50 1. Modelo de negocio .................................................................................................... 50
2. ANEXO A-02. ................................................................................................. 53 a. Modelo de requerimiento........................................................................................... 53
3. ANEXO A-03. ................................................................................................. 57 a. Modelo de análisis. .................................................................................................... 57
TABLA DE ILUSTRACIONES
Ilustración 1: Situación Problemática ................................................................................... 11 Ilustración 2: Identificación de infraestructura local ............................................................ 22
Ilustración 3: Diagrama de red fase de inicio ....................................................................... 43 Ilustración 4: Diagrama de red fase de elaboracion ............................................................. 44 Ilustración 5: Diagrama de red fase de construcción ............................................................ 45
Ilustración 6: Diagrama de red fase de transición. ............................................................... 46 Ilustración 7: Proceso de negocio Gestionar los pedidos a proveedor ................................. 50
Ilustración 8: Proceso de negocio gestión de devoluciones a proveedores .......................... 51 Ilustración 9: Proceso de negocio gestionar los pedidos internos de la empresa ................. 52
Ilustración 10: Diagrama de casos de uso funcional módulo de inventario ......................... 53
Ilustración 11: Diagrama De Casos De Uso Administrativo Del Sistema ........................... 54
Ilustración 12:Diagrama De Casos De Uso Administrativo Del Sistema ............................ 55 Ilustración 13: Casos de usos funcionales del sistema de ventas ......................................... 56 Ilustración 14: diagrama de clases de análisis sistema de inventario ................................... 57 Ilustración 15: clase s de análisis módulo de ventas. ........................................................... 58
Plan de Administración del Proyecto de Software
5
TABLA DE PLANILLAS
Tabla 1 Estimación de lineas de codigo ............................................................................... 25 Tabla 2: Planilla de personal ................................................................................................ 26
Tabla 3: Valores del dominio de información ...................................................................... 29 Tabla 4 : Valores de ajuste de complejidad .......................................................................... 29 Tabla 5 : Planilla de sueldo................................................................................................... 30 Tabla 6 : Listado inicial de riesgo ........................................................................................ 32 Tabla 7 : Plan de contingencia .............................................................................................. 36
Tabla 8 : Valoracion del riesgo............................................................................................. 38 Tabla 9 : Valoracion del riesgo............................................................................................. 40 Tabla 10 : Identificación de tareas ........................................................................................ 41
Tabla 11: Estructura orgánica del equipo ............................................................................. 47 Tabla 12: Modelo descentralizado controlado ..................................................................... 47
Plan de Administración del Proyecto de Software
6
Plan de Administración del Proyecto de Software (PAPS)
Plan de Administración del Proyecto de Software
7
1.1. Introduccion
El presente documento es un Plan de Administración del Proyecto de Software (PAPS).
Para el desarrollo un sistema integrado de información para la gestión de operaciones en el
área de comercialización, inventarios y recursos humanos para la Cadena Nacional de
Farmacias FarmaCorp.
FarmaCorp, Cadena Nacional de Farmacias es una Unidad de Negocios del grupo
empresarial NEXOCORP, dedicada a la comercialización de productos farmacéuticos y de
consumo masivo, con más de 70 años en el mercado boliviano.
Se realizan metricas y estimacion del proyecto, se gestiona los riesgos posibles en el
desarrollo del proyecto. Con estos elementos se define los costos y la duracion que tendra el
producto.
Esta cadena cuenta con un Reglamento Interno y Manuales de Funciones específicos según
el cargo, así como políticas y normativas para el control interno de cada Sucursal. Desea
tener un moderno sistema computarizado de alta tecnología que permite la comunicación
entre Sucursales a nivel nacional, tecnología que también se utiliza en la venta de productos
y servicios, manejo y control de Inventarios.
Plan de Administración del Proyecto de Software
8
1.2. Antecedentes
FarmaCorp, Cadena Nacional de Farmacias es una Unidad de Negocios del grupo
empresarial NEXOCORP, dedicada a la comercialización de productos farmacéuticos y de
consumo masivo, con más de 70 años en el mercado boliviano. La oferta de productos a sus
clientes es variada, desde farmacéuticos, insumos médicos, hasta de cuidado personal,
cosméticos, suplementos alimenticios y otros. A la fecha cuenta con 44 Sucursales a lo
largo del país, de las cuales 33 Sucursales se encuentran ubicadas en el departamento de
Santa Cruz, 6 en Cochabamba, 2 en la ciudad de La Paz, 2 Sucursales en el departamento
de Tarija y 1 en Oruro. FarmaCorp, es una empresa innovadora que trabaja día a día con
Tecnología Avanzada, Estándares Internacionales y una Excelente Administración,
continuamente implementa nuevas formas de actualización, brindando capacitación
permanente a todo su plantel administrativo y operativo, en técnicas de atención al cliente,
farmacológica, manejo de modernos programas operativos y otros; que la han hecho
merecedora a varios reconocimientos por su óptimo desarrollo y eficiente atención a los
clientes. El personal de FarmaCorp está formado por un equipo de profesionales altamente
capacitados y motivados, asegurando de esta manera recursos humanos calificados, con
formación a nivel Licenciatura en Farmacia y Bioquímica, así como también a nivel
Técnico Superior. .1
1 http://www.nexocorp.com.bo/Farmacorp/info/quienessomos.aspx
Plan de Administración del Proyecto de Software
9
1.3. Planteamiento del problema
1.3.1. Situación Problemática
Las farmacias trabajan 24 horas en tres turnos los siete días de la semana. Los turnos de
7:00 a 15:00 y de 15:00 a 23:00 trabajan a puertas abiertas, mientras que el turno nocturno
de 23:00 a 7:00 a puerta cerrada a través de ventanilla.
En los turnos de puertas abiertas hay al menos 4 vendedores por sucursal. Y se tiene un
regente que administra y supervisa las labores. Los pedidos de productos (medicamentos y
otros) se formulan cualquier día a la oficina central de acuerdo al control de stock. El punto
de reposición es definido por el regente, al igual que la cantidad a pedir. La oficina central
consolida el pedido de todas las sucursales, previa verificación de stocks en almacenes y
efectúa la solicitud de compra a los proveedores. La reposición y abastecimiento de los
productos a las sucursales se realiza todos los días a través de los vehículos que dispone la
compañía, sin embargo no logran cubrir las demandas y solicitudes de las sucursales. A
modo de captar clientes y fidelizarlos, se tiene un registro de los clientes (compradores) y
por cada boliviano de venta a los clientes se considera un punto acumulado. Por lo que los
puntos se pueden acumular hasta ser canjeados por el cliente de acuerdo el catálogo de
ofertas, en el momento que el cliente lo requiera. Se elabora los catálogos de ofertas que
son productos (medicamentos y otros) en promoción, que se ofrecen todos los meses. Son
productos de toda índole (cosméticos, de higiene, etc.) entre los que también se consideran
aquellos que no se venden o están por caducar.
Por otra parte se hacen sorteos para días festivos (día del padre, día de la madre, navidad,
etc.) para lo cual el cliente puede acceder a cupones por la compra de productos. Por cada
Bs. 100.- el cliente tiene derecho a un cupón para dicho concurso. Los premios son variados
desde pasajes y vacaciones pagadas, hasta vehículos. Dentro de las funcionalidades
solicitadas al producto de software se tiene lo siguiente:
Se requiere llevar un registro de los productos (medicamentos y otros) que ingresan de cada
proveedor a los almacenes, y de ahí a las sucursales. Los cuales se venden a cada cliente, de
manera de controlar el stock en todo momento, en almacenes y las sucursales.
Plan de Administración del Proyecto de Software
10
Se requiere llevar un registro de los volúmenes de compra a los proveedores, de los pagos
realizados y de los pagos por realizar de acuerdo a la negociación que se tenga con cada
proveedor.
Se requiere emitir una factura por la venta de los medicamentos a los clientes, llevar un
registro del valor de las ventas de los productos. Así también llevar un registro de los
puntos acumulados por las compras realizadas por los clientes.
Se requiere llevar un registro de los clientes, asignándole un código que será su CI.
Mediante las compras que realizan, para efectuar una bonificación cada cierta cantidad de
puntos acumulados.
Se requiere llevar un registro de los puntos canjeados por los clientes y los catálogos de
oferta.
El sistema debe llevar un registro del personal, que trabaja en las sucursales, oficina central
y almacenes. Permitiendo hacer la gestión de personal, efectuando las asignaciones de
turnos, permisos, vacaciones, etc.
El sistema debe efectuar la gestión de planilla al personal, considerando los beneficios por
turnos nocturnos, días festivos, feriados y otros. Así también como los descuentos según
corresponda.
Plan de Administración del Proyecto de Software
11
1.3.1.1. Mapa Mental de la situación problemática:
Ilustración 1: Situación Problemática Fuente: Elaboración Propia
Plan de Administración del Proyecto de Software
12
1.3.2. Situación Deseada
Contar con un sistema integrado de información para la gestión de operaciones en el
área de comercialización, inventarios y recursos humanos para la Cadena Nacional de
Farmacias FarmaCorp.
1.4. Delimitaciones
1.4.1. Delimitación Científica
Este sistema de información está relacionado y basado en el estudio de: Base de Datos
Relacional, Sistema de información, Ingeniería de Software, Aplicación de Proceso
Unificado de Desarrollo (PUD), Lenguaje Unificado de Modelado (UML),
Arquitectura Multicapas.
1.4.2. Delimitación Espacial
Cadena Nacional de Farmacias FarmaCorp es Unidad de Negocios del grupo
empresarial NEXOCORP. Ubicados en Cuarto Anillo esquina Av. Paragua zona norte
con teléfono 3-474808.
1.4.3. Delimitación Temporal
Desarrollo del software fue de 14 meses Teniendo como fecha de inicio el 03/08/2011.
1.5. Objetivos
1.5.1. Objetivo General
Desarrollar un sistema integrado de información para la gestión de operaciones en el
área de comercialización, inventarios y recursos humanos para la Cadena Nacional de
Farmacias FarmaCorp.
1.5.2. Objetivos Específicos
Identificar los requerimientos de información en los procesos de
comercialización, inventarios y recursos humanos para la Cadena Nacional de
Farmacias FarmaCorp.
Realizar el análisis de los requerimientos planteados como requisitos
Plan de Administración del Proyecto de Software
13
Diseñar el sistema contemplando los módulos anteriores para su integración
usando una arquitectura en capas.
Implementar los componentes de software previamente diseñados.
Realizar las pruebas a los modelos y artefactos construidos.
1.6. Justificación
1.6.1. Justificación Teórica
En el desarrollo de este proyecto aplicaremos conocimientos de base de datos
relacionales, conceptos de sistemas de información, ingeniería de software y
arquitectura de software.
1.6.2. Justificación Metodológica
Se utilizará el Proceso Unificado de Desarrollo (PUD), para organizar las
diferentes etapas de trabajo para el desarrollo de este proyecto, además de
proporcionar los artefactos que deben desarrollarse en las diferentes fases. Para
desarrollar los artefactos utilizaremos el Lenguaje Unificado de Modelado (UML)
para especificar, construir, visualizar y documentar los artefactos de un sistema de
software orientado a objeto.
Se justifica esta metodología porque reduce la dificultad de coordinar las múltiples
etapas: Requerimiento, Análisis, Diseño, Implementación, Prueba de trabajo de un
proyecto de software.
1.6.3. Justificación Practica
Contribuir con la presentación a de plan de proyecto como trabajo final del módulo
de introducción a la ingeniería de software.
Asimismo, profundizar conocimientos en el área de gestión y gerenciamiento de
proyecto.
Plan de Administración del Proyecto de Software
14
1.7. Diseño Metodológico
1.7.1. Tipo de Investigación
Se ha seguido el tipo de investigación descriptiva orientado a la gestion,
desarrrollo de modelos y artefactos para sistemas de gestión.
1.7.2. Procesos Metodológicos
En el desarrollo del proyecto se seguirá los pasos que plantea el ciclo de vida del
Proceso Unificado, por su característica: Dirigido por casos de uso, centrado en su
arquitectura, iterativo e incremental del desarrollo del software, con sus fases de:
Inicio, Elaboración, Construcción y transición. En cada una de estas fases existen
cinco flujos de trabajo: Requisitos, Análisis, Diseño, Implementación y Prueba.
El proceso unificado utiliza el Lenguaje Unificado de Modelado (UML) para
preparar todos los esquemas de un sistema de información.
Para el presente proyecto se plantea las siguientes fases y flujos:
Ilustración 1. 1: Diagrama de Fases y Flujos
Fuente: IBM RUP Rational Unified Process.
Plan de Administración del Proyecto de Software
15
1.7.3. Métodos
Los métodos utilizados para el desarrollo del presente proyecto son Análisis y
Síntesis.
El Análisis para identificar las causas y los efectos, y la Síntesis para
interrelacionar las los sistema.
1.7.4. Técnicas para recolección de información
1.7.4.1. Fuentes Primarias:
Las técnicas utilizadas para la recolección de datos son:
Entrevistas directas con el cliente, el gerente administrativo, gerente de
operaciones con los usuarios finales y con los responsable de TI. de la empresa.
1.7.4.2. Fuentes Secundarias:
Recolección de información por especialistas del Área: Proveedores externo, e
interno, manuales de operaciones, libros.
1.7.5. Recursos utilizados
Seguidamente se muestra una lista de los artefactos y herramientas utilizados en el
desarrollo del proyecto:
1.7.5.1. Artefactos de Diseño
Los Artefactos de diseño utilizados son los siguientes:
Diagrama de Actividades, Diagrama de Casos de Uso, Diagrama de Clases,
Diagrama de Despliegue.
1.7.5.2. Instrumentos de Análisis
Manuales de procedimiento y operaciones de la empresa.
Estatutos, ley de regulación de farmacias.
Plan de Administración del Proyecto de Software
16
1.8. Alcance
1.8.1. Requerimientos funcionales.
Nro. Requerimiento funcionales modulo
1 Aprobar solicitud en dpto. de finanzas inventario
2 Buscar Producto inventario
3 Definir accesos al sistema inventario
4 Elaborar Informe de stock de producto inventario
5 Elaborar Informe de pedidos a proveedor inventario
6 Elaborar Informe de pedidos de venta inventario
7 Elaborar Resumen de pedidos a proveedor inventario
8 Elaborar informe de devoluciones de venta inventario
9 Emitir Comprobante de pedido a inventario inventario
10 Emitir Comprobante de pedido a proveedor inventario
11 Emitir Ficha de registro del proveedor inventario
12 Emitir acta de devolución de productos a inventario inventario
13 Emitir acta de recepción de pedido del proveedor inventario
14 Emitir acta de recepción de productos del dpto. de inventario inventario
15 Emitir comprobante de devolución a proveedor inventario
16 Emitir informe de devoluciones a proveedor inventario
17 Gestionar Proveedor Jurídico inventario
18 Gestionar Proveedor Natural inventario
19 Gestionar Usuario del sistema Administrativo
20 Gestionar Backus de la base de datos Administrativo
21 Gestionar devolución a proveedor inventario
22 Gestionar empleado RRHH
23 Realizar devolución de productos a inventario inventario
24 Realizar pedido de productos a inventario inventario
25 Realizar solicitud de pedido a proveedor inventario
26 Recepción productos del proveedor por devolución inventario
27 Decepcionar Productos del dpto. de inventario inventario
Plan de Administración del Proyecto de Software
17
28 Recepcionar Solicitud del pedido del dpto. de venta inventario
29 Recepcionar pedido del provedores inventario
30 Registrar Almacén inventario
31 Registrar Categoría de productos inventario
32 Registrar Clasificación ABC inventario
33 Registrar País inventario
34 Registrar Sucursal inventario
35 Registrar dpto_Seccion inventario
36 Registrar la subcategoría del producto inventario
37 Registrar producto inventario
38 Realizar solicitud de pedido a proveedor inventario
39 Restaurar Copia de seguridad de la base de datos inventario
40 Gestionar Cliente ventas
41 Programar Creditors a pedido ventas
42 Realizar el pedido del cliente ventas
43 Registrar Forma de Pago ventas
44 Registrar Moneda ventas
45 Registrar Rubro ventas
46 Registrar Sub Categoría ventas
47 Registrar calificación ventas
48 Registrar puntos del cliente ventas
49 Registrar categoria ventas
50 Registrar producto ventas
51 Registrar Cargo rrhh
52 Generar Planilla de sueldos mensual rrhh
53 Gestionar Descuentos rrhh
54 Gestionar Bonos rrhh
55 Gestionar Aportes rrhh
56 Gestionar Bitácora de transacciones Administrativo
Identificación de requerimientos funcionales tomando como referencia el ANEXO A-01, ANEXO A-02
Fuente: Elaboración propia
Plan de Administración del Proyecto de Software
18
1.8.2. Requerimientos no funcionales.
1.8.2.1. Especificaciones Suplementarias
Las Especificaciones Suplementarias contienen los requisitos de sistema que no
se contemplan en el documento de Requerimientos de Software. Algunos de
ellos son:
o Requisitos legales y aplicación de estándares
o Atributos de la calidad del sistema a construir, como la facilidad de uso y la
performance
o Requisitos de entorno y sistema operativo, compatibilidad y restricciones de
diseño
o Otros requisitos que no se contemplan en el documento de requerimiento de
software.
1.8.2.2. Tiempo de aprendizaje
El tiempo que tarden los usuarios en aprender el 80% de la funcionalidad del sistema
deberá ser:
o Usuario de carga: 2 días
o Usuario de consulta: 1 día
o Administrador: 3 días
En cuanto a la capacitación del personal de FarmaCorp, en el manejo de software y
mantenimiento del sistema deberá considerar un tiempo considerable de por lo
menos 25 horas de capacitación, hasta que los lineamientos de manejo del sistema y
otros hayan sido debidamente adquiridos por el personal previamente asignado.
1.8.2.3. Identificación del usuario propio de la aplicación
El usuario ingresará al Sistema con su clave y contraseña, que será validada por
el Active Directory de Windows Server 2000 o 2003.
Plan de Administración del Proyecto de Software
19
1.8.2.3.1. Contraseña de usuario
Para la registración de la contraseña de usuario deberán asegurarse las siguientes
prácticas:
o La contraseña debe viajar encriptado entre el cliente, el servidor Web y
el servidor de base de datos.
o La modificación de la contraseña será efectuada de acuerdo a las
Políticas de validez de cuentas y contraseñas establecidas en al Active
Directory
o De acuerdo a las Políticas de Active Directory de Windows Server
o Al cambiar una contraseña, la nueva contraseña no puede ser igual a la
anterior.
o Luego de tres intentos de acceso fallidos al sistema a causa de contraseña
incorrecta, se debe bloquear esa cuenta de usuario. De acuerdo a las
Políticas de Active Directory .
o La contraseña debe contener letras y números
o La longitud de la contraseña debe ser de 7caracteres. De acuerdo a las
Políticas de Active Directory .
1.8.2.4. Confiabilidad
1.8.2.4.1. Tiempo de disponibilidad del sistema
La aplicación debe estar disponible las 24 horas del día.
1.8.2.4.2. Tiempo comprendido entre fallas
Al ser un sistema de alta disponibilidad en tiempo de fallas estará comprendida
de 0 a 5h. Por gestión.
1.8.2.4.3. Tiempo fuera de servicio
El tiempo máximo de fuera de operación depende del funcionamiento de los,
servidores de codines, servidores de datos y las bases mismas. El mismo debe
ser:
o Fallas comunes 40 minutos (estimado)
Plan de Administración del Proyecto de Software
20
o Fallas no comunes 1hora. (estimado)
1.8.2.4.4. Registro de eventos
La aplicación debe mantener un LOG de eventos para registrar los distintos
eventos que se realicen sobre la base de datos.
1.8.2.5. Performance
1.8.2.5.1. Acceso de clientes en línea
Los usuarios clientes deben poder acceder a los datos en línea, en tiempo real.
1.8.2.5.2. Tiempo de respuesta
El tiempo de respuesta al acceso del usuario debe ir de 5 segundos.
El tiempo de respuesta para una transacción promedio también debe ser de 15
segundos.
1.8.2.5.3. Cantidad de atención a usuarios
El sistema debe poder atender normalmente a 100 usuarios a la vez.
1.8.2.6. Soportabilidad o Facilidad de Mantenimiento
1.8.2.6.1. Actualización transparente al usuario
Debe aprovecharse la característica de la tecnología Web para que las
actualizaciones y patchs de la aplicación se instalen y esta operación sea
transparente al usuario.
1.8.2.7. Estándares de codificación
Debe utilizarse los padrones entregados por IT “Padrón de Desarrollo de Código
de Aplicaciones”.
1.8.2.8. Restricciones de Diseño
1.8.2.8.1. Estándares de diseño
Debe utilizarse los padrones entregados por IT “Padrón de Diseño de
Aplicaciones” en n capas con la tecnología ADO.Net 4.0 de Microsoft.
Plan de Administración del Proyecto de Software
21
1.8.2.8.2. Estándares de arquitectura
Debe utilizarse los padrones entregados por IT “Padrón de Arquitectura de
Aplicaciones de ADO.Net de Microsoft”.
1.8.2.9. Motor de base de datos
Se debe utilizar el motor de base de datos SQL Server 2007 de Microsoft.
1.8.2.10. Cliente del navegador
La aplicación deberá ser accesible utilizando el siguiente tipo de navegador: Internet
Explorer 7 o superior.
1.8.2.11. Servidor Web
El servidor Web debe ser Internet Información Server versión 6.1 o superior.
1.8.2.12. Lenguaje de programación
La aplicación debe desarrollarse en .NET utilizando ASP.NET, ADO.NET, Visual
C#.Net, y derivados de SQL con T/SQL para el motor de base de datos SQL Server
2007 service pack 3ª como mínimo.
1.8.2.13. Requerimientos de documentación, ayuda en línea y manuales,
asistencia técnica.
1.8.2.13.1. Manual de Usuario
Se debe contar con un manual de usuario detallado.
1.8.2.13.2. Ayuda en línea
El manual de usuario debe estar disponible en línea.
1.8.2.13.3. Guías de Instalación y Configuración
Se debe contar con guías y manuales de instalación del sistema y configuración
de equipos de control.
1.8.2.13.4. Apoyo Técnico
Farmacoop considerará como prioritario para la calificación, el soporte técnico y
local (preferentemente) para con el sistema, en cuyo caso se deberá señalar la
empresa que se asigne para este servicio, en caso de emergencia.
Plan de Administración del Proyecto de Software
22
1.8.2.14. Interfaces
1.8.2.14.1. Interfaz de usuario
Se debe contar con una interfaz gráfica.
1.8.2.14.2. Interfaz de Hardware
El sistema debe interpretar las lecturas realizadas en los El sistema deberá
soportar la conexión con las impresoras de código de barra.
1.8.2.14.3. Interfaz de Comunicaciones
o Los usuarios deben tener conexión a Internet para poder utilizar la
aplicación vía Web. La comunicación con los equipos debe ser vía RS-
232, RS-485, MODEM o TCP/IP.
o Para el Entorno de Red: la aplicación deberá tener la capacidad de
funcionar con las siguientes características
o Redes LAN
SERVIDOR SQL SERVIDOR DOMINIO SERVIDOR APLICACIONES
SERVIDOR CODINES
RED RS485
CODIN
CODIN
CODIN
CODIN
CODIN
ARL9000
CODIN
SERVIDOR IIS
RED LAN
DIAGRAMA DE
INSTALACION DE CADA
SEDE
Ilustración 2: Identificación de infraestructura local Fuente: Elaboración propia
Redes WAN, ADSL de 1024 MB Frame Relay 128
1.8.2.14.4. Interfaces de Software
Debe ser diseñado para ambiente Windows 32 bits /98/NT/2000/Seven.
1.8.2.15. Requerimientos de Licencias
FarmaCorp proveerá las licencias correspondientes para todo el Software que se
requiera tanto de Servidores como de Clientes.
Plan de Administración del Proyecto de Software
23
1.8.2.16. Legales, Derechos de Autor y Otras notas
Se deberá considerar la provisión de equipos, servicio de instalación y
conexionado de equipos a satisfacción de FarmaCorp. La garantía de operación
Del sistema, deberá referirse a un plazo no mayor a un año posterior a la
conclusión de los trabajos, luego de que se haya procedido a la firma de una
entrega provisional del servicio.
Las pruebas de aceptación se deberán realizar bajo la supervisión de FarmaCorp.
Para ello se harán: los test y mediciones necesarios para evaluar el buen
funcionamiento de todo el sistema a nivel de hardware y software.
1.8.2.17. Estándares Aplicables
El desarrollo de todo el proyecto se debe regir bajo normas y patrones definidos por
la Gerencia de TI y Telecomunicaciones de FarmaCorp-Bolivia.
Estos incluyen: Padrón de seguridad, Padrón de Arquitectura de Aplicaciones,
Padrón de Diseño de Aplicaciones, Padrón de Desarrollo del Código de una
Aplicación.
1.8.2.18. Puesta en Marcha
o La puesta en marcha se deberá realizar en las oficinas centrales de la
empresa, para la cual se deberá migrar toda la información histórica
disponible, realizar pruebas eléctricas y de funcionamiento de software
(Comunicación).
Plan de Administración del Proyecto de Software
24
Ent radas de usuario . Son entradas que proporcionan diferentes datos a la aplicación. No confundirlos con las peticiones de usuario.
Salidas de usuario . Son reportes, pantallas o mensajes de error que proporcionan información. Los elementos de un reporte, no se cuentan de forma separada.
Pet iciones de usuario . Es una entrada interactiva que produce la generación de alguna respuesta del software en forma de salida interactiva.
A rchivos. Son los archivos que pueden ser parte de una base de datos o independientes.
Int erf aces ext ernas. Son los archivos que se usan para transmit ir información a otro sistema.
1.9. Métricas.
1.9.1. Métricas orientadas al tamaño.
1.9.1.1. Datos históricos de proyectos de gestión.
1.9.2. Métricas orientadas a la función
5
5
2
3
4
3
4
3
2
3
5
5
5
5
54
2. ¿Requiere comunicación de datos?
1. ¿Requiere el sistema copias de seguridad y de recuperación f iables?
FACTOR DE AJUSTE DE COMPLEJIDAD
∑fi.
Va lo re s de a jus te de c o m ple jida d: 0 e s no inf lue nc ia , 1 e s inc ide nta l, 2 e s m o de ra do , 3 e s m e dio , 4 e s s ig nif ic a t iv o y 5 e s e s e nc ia l
9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?
10. ¿Es complejo el procesamiento interno?
11. ¿Se ha diseñado el código para ser reutilizable?
12. ¿Están incluidas en el diseño la conversión y la instalación?
13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?
14 ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?
3. ¿Existen funciones de procesamiento distribuido?
4. ¿Es crítico el rendimiento?
5. ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado?
6. ¿Requiere entrada de datos interactiva?
7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples
pantallas u operaciones? 8. ¿Se actualizan los archivos maestros de forma interactiva?
Fi fi
Simple Medio Complejo
Número de entradas de usuario 56 3 4 6 224
Número de salidas de usuario 38 4 5 7 266
Número de peticiones de 15 3 4 6 60
Número de archivos 35 7 10 15 350
Número de interfaces externas 1 5 7 10 7
Factor de ponderación:
Subtotal
Cuenta Total
Parámetro Cuenta
Factor de ponderación
907 Ct
PF=1079.33 Con estos datos actualizamos los datos histórico de productividad media (PF).
PR O LD C E C OSTO P.D OC . ER R OR S D EFEC TOS PER SON A S KLD C
PR OD U C TIV ID A D
( KLD C / E)
PR OD U C TIV ID A
D ( PF / E) C A LID A D
( Error/ KLD C )
D U R A C ION
( E/ Persona)
Para 6 meses cuant as
personas
A 18000 50 7000 600 89 22 5 18 0.36 21.5866 4.944444444 10 8.333333333
B 15800 38 5000 500 120 36 3 15.8 0.415789474 28.40342105 7.594936709 12.66666667 6.333333333
C 22000 45 9000 900 75 40 6 22 0.488888889 23.98511111 3.409090909 7.5 7.5
D 21200 52 15000 700 36 30 7 21.2 0.407692308 20.75634615 1.698113208 7.428571429 8.666666667
Productividad media (LDC) 0.418092668 23.6828696
Productividad media (PF)
Plan de Administración del Proyecto de Software
25
1.10. Estimaciones.
1.10.1. Estimaciones basadas en líneas de código. Nro. Requerimiento Sopt Smp SPess VE KLDC.
1 Aprobar solicitud en dpto. de finanzas 100 125 150 125 0.125
2 Buscar Producto 90 95 120 98.33 0.098
3 Definir accesos al sistema 100 105 130 108.3 0.108
4 Elaborar Informe de stock de producto 70 80 105 82.5 0.083
5 Elaborar Informe de pedidos a proveedor 75 90 105 90 0.09
6 Elaborar Informe de pedidos de venta 70 87 105 87.17 0.087
7 Elaborar Resumen de pedidos a proveedor 60 95 105 90.83 0.091
8 Elaborar informe de devoluciones de venta 55 90 105 86.67 0.087
9 Emitir Comprobante de pedido a inventario 60 100 105 94.17 0.094
10 Emitir Comprobante de pedido a proveedor 55 80 105 80 0.08
11 Emitir Ficha de registro del proveedor 55 80 105 80 0.08
12 Emitir acta de devolución de productos a inventario 55 80 105 80 0.08
13 Emitir acta de recepción de pedido del proveedor 58 82 105 81.83 0.082
14 Emitir acta de recepción de productos del dpto. de inventario 55 80 105 80 0.08
15 Emitir comprobante de devolución a proveedor 55 80 105 80 0.08
16 Emitir informe de devoluciones a proveedor 55 80 105 80 0.08
17 Gestionar Proveedor Jurídico 90 105 130 106.7 0.107
18 Gestionar Proveedor Natural 80 105 130 105 0.105
19 Gestionar Usuario del sistema 83 105 130 105.5 0.106
20 Gestionar Backus de la base de datos 77 105 130 104.5 0.105
21 Gestionar devolución a proveedor 80 105 130 105 0.105
22 Gestionar empleado 80 105 130 105 0.105
23 Realizar devolución de productos a inventario 100 130 160 130 0.13
24 Realizar pedido de productos a inventario 110 135 160 135 0.135
25 Realizar solicitud de pedido a proveedor 120 145 170 145 0.145
26 Recepción productos del proveedor por devolución 100 125 150 125 0.125
27 Decepcionar Productos del dpto. de inventario 80 105 130 105 0.105
28 Recepcionar Solicitud del pedido del dpto. de venta 80 105 130 105 0.105
29 Recepcionar pedido del proveedores 100 130 160 130 0.13
30 Registrar Almacén 110 135 160 135 0.135
31 Registrar Categoría de productos 120 145 170 145 0.145
32 Registrar Clasificación ABC 100 125 150 125 0.125
33 Registrar País 80 105 130 105 0.105
34 Registrar Sucursal 80 105 130 105 0.105
35 Registrar dpto_Seccion 100 130 160 130 0.13
36 Registrar la subcategoría del producto 110 135 160 135 0.135
37 Registrar producto 120 145 170 145 0.145
38 Realizar solicitud de pedido a proveedor 100 125 150 125 0.125
39 Restaurar Copia de seguridad de la base de datos 80 105 140 106.7 0.107
40 Gestionar Cliente 80 105 130 105 0.105
41 Programar Créditos a pedido 100 130 160 130 0.13
42 Realizar el pedido del cliente 110 135 160 135 0.135
43 Registrar Forma de pago 120 160 170 155 0.155
44 Registrar Moneda 100 125 150 125 0.125
45 Registrar Rubro 100 125 150 125 0.125
46 Registrar Sub Categoría 80 105 130 105 0.105
47 Registrar calificación 80 105 130 105 0.105
48 Registrar puntos del cliente 100 130 160 130 0.13
49 Registrar categoría 110 135 160 135 0.135
50 Registrar producto 120 145 170 145 0.145
51 Registrar Cargo 100 125 150 125 0.125
52 Generar Planilla de sueldos mensual 80 130 140 123.3 0.123
53 Gestionar Descuentos 80 120 130 115 0.115
54 Gestionar Bonos 100 130 160 130 0.13
55 Gestionar Aportes 110 135 160 135 0.135
56 Gestionar Bitácora de transacciones 120 145 170 145 0.145
Total 4938 6374 7705 6,357 6.36
Tabla 1 Estimación de lineas de codigo
Fuente: Elaboración propia
Plan de Administración del Proyecto de Software
26
Para la estimación del esfuerzo se utilizaran las líneas de código estimadas utilizando como
datos histórico la productividad media LDC:
Despejando E=kldc/p
Esfuerzo 24.11 personas/mes
Duración 8.04 meses
Personal 3 analista programador 1 gestor y un consultor externo
Planilla de personal
Empleado cargo Sueldo
Mensual (Sus.)
Duración Costo (sus.)
Ernesto Soto Roca Gestor de proyecto 800 8 6400
Juan Martínez Sánchez Consultor tecnológico 700 5 3500
María Zurita Sánchez Analista programador 600 8 4800
Marcos Mariscal Martínez Analista programador 600 8 4800
Federico Villa Marthi Analista programador 600 8 4800
Costo Total 3300 24300
Tabla 2: Planilla de personal
Fuente: Elaboración propia
Análisis de los resultados:
Los datos obtenidos usando la técnica de estimación LDC dando como resultado:
Esfuerzo=24.11p/m
Duración=8.04 meses
Con un costo total estimado según planilla de sueldo del personal de 24300 00/100
Dólares americanos.
Plan de Administración del Proyecto de Software
27
1.1.1. Estimaciones COCOMO. (COnstructive COst MOdel)
Fórmulas serán las siguientes:
E = Esfuerzo = a KLDC e * FAE (persona x mes)
T = Tiempo de duración del desarrollo = c Esfuerzo d (meses)
P= Personal = E/T (personas)
LENGUAJE LDC/PF
Visual C# 32
SQL 12
Así pues tras saber que son 32 LDC por cada PF, por el hecho de ser C# el resultado
de los KDLC será el siguiente:
KLDC= (PF * Líneas de código por cada PF)/1000 = (261,36*32)/1000= 8,363 KDLC
Número de líneas de código no supera los 50 KLDC, y además el proyecto de gestion,
CONDUCTORES DE COSTE
VALORACIÓN
Muy
bajo
Bajo Nominal Alto Muy
alto
Extr.
alto
Fiabilidad requerida del software 0,75 0,88 1.00 1,15 1,40 -
Tamaño de la base de datos - 0,94 1.00 1,08 1,16 -
Complejidad del producto 0,70 0,85 1.00 1,15 1,30 1,65
Restricciones del tiempo de ejecución - - 1.00 1,11 1,30 1,66
PROYECTO SOFTWARE a e c d
Orgánico 3,2 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 2,8 1,20 2,5 0,32
Plan de Administración del Proyecto de Software
28
Restricciones del almacenamiento principal - - 1.00 1,06 1,21 1,56
Volatilidad de la máquina virtual
-
0,87 1.00 1,15 1,30 -
Tiempo de respuesta del ordenador - 0,87 1.00 1,07 1,15 -
Capacidad del analista 1,46 1,19 1.00 0,86 0,71 -
Experiencia en la aplicación 1,29 1,13 1.00 0,91 0,82 -
Capacidad de los programadores 1,42 1,17 1.00 0,86 0,70 -
Experiencia en S.O. utilizado 1,21 1,10 1.00 0,90 - -
Experiencia en el lenguaje de programación 1,14 1,07 1.00 0,95 - -
Prácticas de programación modernas 1,24 1,10 1.00 0,91 0,82 -
Utilización de herramientas software 1,24 1,10 1.00 0,91 0,83 -
Limitaciones de planificación del proyecto 1,23 1,08 1.00 1,04 1,10 -
FAE=1,15*1,00*0,85*1,11*1,00*1,00*1,07*0,86*0,82*0,70*1,00*0,95*1,00*0,91*1,08
= 0,53508480
Cálculo del esfuerzo del desarrollo:
E = a KLDC e * FAE = 3,2 * (8.363)^1,05
* 0,53508480 = 15,91 personas /mes
Cálculo tiempo de desarrollo:
T = c Esfuerzo d = 2,5 * (15,91)^0,38 = 7,15 meses
Productividad:
PR = LDC/Esfuerzo = 8363/15,91 = 525 ,64 LDC/personas mes
Personal promedio:
P = E/T = 15,91/7,15 = 2,22 personas
Análisis de los resultados:
Para un equipo 3 personas trabajando alrededor de 7 meses, El equipo formado por 3 analista
programador 1 gestor y un consultor externo.
Plan de Administración del Proyecto de Software
29
1.1.2. Estimaciones Basadas en punto función.
Tabla 3: Valores del dominio de información
VALORES DE AJUSTE DE COMPLEJIDAD
0 es no influencia, 1 es incidental, 2 es moderado, 3 es medio, 4 es significativo y 5 es esencial 1. ¿Requiere el sistema copias de seguridad y de recuperación fiables?
4 2. ¿Requiere comunicación de datos?
3 3. ¿Existen funciones de procesamiento distribuido?
0 4. ¿Es crítico el rendimiento?
2 5. ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado?
3 6. ¿Requiere entrada de datos interactiva?
3 7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones? 4 8. ¿Se actualizan los archivos maestros de forma interactiva?
3 9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?
3 10. ¿Es complejo el procesamiento interno?
2 11. ¿Se ha diseñado el código para ser reutilizable?
2 12. ¿Están incluidas en el diseño la conversión y la instalación?
3 13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?
3 14 ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?
3 38
Tabla 4 : Valores de ajuste de complejidad
Fuente: Elaboración propia
PF=833.4416667
1.- Estimación de los valores del dominio de información.
Valor de dominio
de información
So Sp Pesimista Media
ponderada
FACTOR DE
PONDERACION
SUBTO
TAL
Simple Medio Complejo
Nro. Entradas 45 50 60 50.83 3 4 6 203.33
Nro. De salidas 30 40 50 40.00 4 5 7 160.00
Nro. De peticiones 4 6 9 6.17 3 4 6 24.67
Nro. De archivos 50 60 65 59.17 7 10 15 414.17
Nro. Interfaces externas 1 1 1 1.00 5 7 10 7.00
∑CT 809.17
Fi
Plan de Administración del Proyecto de Software
30
Despejando E=PF/p
Productividad media(pf) 23.68287 Esfuerzo 35.19 personas/mes
Duración 11.73 meses
Personal 3 analista programador 1 gestor y un consultor externo
Planilla de personal
Empleado cargo Sueldo
Mensual (Sus.)
Duración Costo (sus.)
Ernesto Soto Roca Gestor de proyecto 800 11.73 9384
Juan Martínez Sánchez Consultor tecnológico 700 5 3500
María Zurita Sánchez Analista programador 600 11.73 7038
Marcos Mariscal Martínez Analista programador 600 11.73 7038
Federico Villa Marthi Analista programador 600 11.73 7038
Costo Total 3300 33998
Tabla 5 : Planilla de sueldo
Fuente: Elaboración propia
Análisis de los resultados:
Los datos obtenidos usando la técnica de estimación Punto función dando como
Resultado:
Esfuerzo=35.19 p/m
Duración=11.78 meses
Con un costo total estimado según planilla de sueldo del personal de 33998 00/100
Dólares americanos.
Plan de Administración del Proyecto de Software
31
1.2. Análisis de Riesgo.
Gestionando el riesgo en las variables, cliente, proceso y el entorno de desarrollo, sin que esto signifique que son la única categoría
de riesgo que pueden afectar al éxito del proyecto.
LISTADO INICIAL DE RIESGO
CAT. NRO RIESGO PROB. IMPACTO
CLIE
NT
E
R1 Que existan frecuentes cambio de los requerimientos por parte de los cliente 0.4 1
R2 No tiene experiencia en proyectos anteriores de similares característica 0.3 2
R3 Idea Clara de los objetivos que pretende el proyecto y de los que quieren los usuarios 0.5 2
R4 No tiene Tiempo para un especificación formal de los requerimiento 0.7 3
R5 No deja Trabajar al equipo de desarrollo, para dando consejo de experto informático 0.4 1
R6 No entiende el ciclo de vida de producto. 0.3 2
PR
OC
. D
E P
RO
DU
CC
ION
R7 No Hay una política clara de normalización y seguimiento de una metodología 0.5 2
R8 Están los gestores y desarrolladores formados 0.7 3
R9 Conoce todo el mundo los estándares 0.4 1
R10 Existen plantillas y modelos para todos los documentos resultado del proceso 0.3 2
R11 Se aplican revisiones técnicas de la especificación de requerimientos diseño y codificación 0.5 2
R12 Se aplican revisiones técnicas de los procedimientos de revisión y prueba 0.7 3
R13 Se documentan los resultados de las revisiones técnicas 0.4 1
R14 Hay algún mecanismos para asegurar que un proceso de desarrollo sigue los estándares 0.3 2
R15 Se realiza gestión de la configuración 0.5 2
R16 Hay mecanismos para controlar los cambios en los requerimientos que tienen impacto en el software 0.7 3
R17 Se documenta suficientemente cada subcontrato 0.4 1
R18 Se ha habilitado y se siguen mecanismos de seguimiento y evaluación técnica de cada subcontrato. 0.3 2
R19 Se dispone de técnicas de especificación de aplicaciones para facilitar la comunicación con el cliente. 0.5 2
R20 Se usan métodos específicos para análisis de software 0.7 3
R21 Se utiliza un método específico para el diseño arquitectónico y de datos 0.4 1
R22 Está el 90% del código en lenguajes de alto nivel 0.3 2
R23 Hay estándares de documentación de código 0.5 2
R24 Se usan métodos específicos para el diseño de pruebas 0.7 3
Plan de Administración del Proyecto de Software
32
R25 Se utilizan herramientas para llevar a cabo la planificación y control 0.4 1 E
NT
OR
NO
DE
DE
SA
RR
OLLO
R26 Que no se tenga herramientas de gestión de proyectos 0.5 2
R27 Hay herramientas de análisis y diseño 0.4 1
R28 No se tiene generadores de código apropiados para la aplicación 0.3 2
R29 Hay herramientas de prueba apropiadas 0.5 2
R30 Hay herramientas de gestión de configuración apropiadas 0.7 3
R31 Se hace uso de una base de datos o repositorio centralizado 0.4 1
R32 Están todas las herramientas de desarrollo integradas 0.3 2
R33 Se ha proporcionado formación a todos los miembros del equipo de desarrollo 0.5 2
R34 Hay expertos a los cuales solicitar ayuda acerca de las herramientas 0.7 3
R35 Hay ayuda en línea y documentación disponible 0.4 1
Tabla 6 : Listado inicial de riesgo
Fuente: Elaboración propia
Plan de Administración del Proyecto de Software
33
1.2.1. Planificación del riesgo.
PLAN DE CONTINGENCIA
RIESGOS DESPUES DE LA LINEA DE CORTE.
CAT. N. RIESGO PROB. IMP PREVENCION GESTION
CLIENTE PROC. DE
PRODUCCION
R1
Que existan frecuentes cambio de los requerimientos por parte de los clientes.
0.4 1
Se aplicaran técnicas de identificación de requerimiento, como cuestionarios, entrevistas personales, identificación del problema usando mapas mentales, y la construcción de prototipos evolutivos del software enmarcados en un modelo incremental e iterativo.
El cliente deberá priorizar los requerimientos en compañía del equipo de desarrollo. Los cuales no podrán ser cambiados hasta que termine la iteración que por lo general dura de dos a cuatro semanas como máximo.
R2
No tiene experiencia en proyectos anteriores de similares característica
0.3 2
Se elaboran cuestionarios, orientados a detectar la experiencia del cliente y usuarios final, con el uso de tecnologías similares, la facilidad u oposición al cambio.
Los resultados de cada iteración servirán como datos históricos reales de productividad y esfuerzo para el proyecto, lo cual permitirá ajustar la planificación a medica que evoluciona el desarrollo
R3
Idea Clara de los objetivos que pretende el proyecto y de los que quieren los usuarios.
0.5 2
Se trabajara en identificar plenamente la situación problemática, y el problema que solucionara el aplicativo.
Construcción de mapas mentales, procesos de negocio actuales de la empresa detectando el funcionamiento real de la actividades
R4
No tiene Tiempo para una especificación formal de los requerimientos.
0.7 3
Se dejara en claro la importancia de la participación del cliente en la priorización de requerimiento y evaluación del resultado en cada iteración.
Definir un conducto formal, planificado de las reuniones de evaluación, e inicio de iteración, según el proceso.
R5
No deja Trabajar al equipo de desarrollo, para dando consejo de experto informático 0.4 1
Plan de Administración del Proyecto de Software
34
R6
No entiende el ciclo de vida de producto.
0.3 2
PROC. DE PRODUCCION ENTORNO DE DESARROLLO
R7
No Hay una política clara de normalización y seguimiento de una metodología
0.5 2
Existen un plan de proyectos, planificación temporal que normara el desarrollo del proyecto
La actualización continúa del plan de proyecto por el gestor de proyecto. Y la auto planificación de actividades por cada equipo de desarrollo
R8
Están los gestores y desarrolladores formados
0.7 3
R9
Conoce todo el mundo los estándares
0.4 1
Se hará un riguroso seguimiento a la aplicación de normas y estándares propuesto por el plan de proyecto.
Detección del artefacto fuera de norma, corrección y autoevaluación.
R10
Existen plantillas y modelos para todos los documentos resultado del proceso
0.3 2
Apego a estándares y normas de documentación.
Detección de los artefactos no documentados y fuera de norma, y procedes a la corrección.
R11
Se aplican revisiones técnicas de la especificación de requerimientos diseño y codificación
0.5 2
Se realizaran presentación por iteraciones cortas. Donde se procederá a la revisión de los entregables y la gestión de configuración.
Efectivizar las reuniones de autoevaluación y revisión de artefactos construidos.
R12
Se aplican revisiones técnicas de los procedimientos de revisión y prueba
0.7 3
R13
Se documentan los resultados de las revisiones técnicas
0.4 1
Se contempla la gestión de configuración
Efectivizar las reuniones de autoevaluación y revisión de artefactos construidos, identificación por cada entregable.
R14
Hay algún mecanismos para asegurar que un proceso de desarrollo sigue los estándares 0.3 2
R15 Se realiza gestión de la configuración
0.5 2 Se contempla la gestión de configuración
Preparar el Plan de SQA para cada proyecto.
R16 Hay mecanismos para controlar los cambios en los requerimientos que 0.7 3
Revisar las actividades de ingeniería en acuerdo con el
Auditar los productos de trabajo designados, para verificar su
Plan de Administración del Proyecto de Software
35
tienen impacto en el software proceso definido.
adherencia con aquellos definidos en el modelo de proceso.
R17
Se documenta suficientemente cada subcontrato
0.4 1
R18
Se ha habilitado y se siguen mecanismos de seguimiento y evaluación técnica de cada subcontrato. 0.3 2
R19
Se dispone de técnicas de especificación de aplicaciones para facilitar la comunicación con el cliente.
0.5 2
Planificación de las Comunicaciones: determinar las necesidades de información y comunicaciones de los interesados en el proyecto.
Informar el Rendimiento: recopilar y distribuir información sobre el rendimiento. Esto incluye informes de estado, medición del progreso y proyecciones. s.
R20
Se usan métodos específicos para análisis de software
0.7 3
Distribución de la Información: poner la información necesaria a disposición de los interesados en el proyecto cuando corresponda.
Gestionar a los Interesados: gestionar las comunicaciones a fin de satisfacer los requisitos de los interesados en el proyecto y resolver polémicas con ello
R21
Se utiliza un método específico para el diseño arquitectónico y de datos
0.4 1
R22
Está el 90% del código en lenguajes de alto nivel
0.3 2
R23
Hay estándares de documentación de código 0.5 2
R24 Se usan métodos específicos para el diseño de pruebas 0.7 3
R25
Se utilizan herramientas para llevar a cabo la planificación y control
0.4 1
ENTORNO DE DESARROLLO R26
Que no se tenga herramientas de gestión de proyectos
0.5 2
Definir con anticipación las herramientas y tecnologías a emplear.
Comprar las licencias para la gestión de configuración, planificación.
R27 Hay herramientas de análisis y diseño 0.4 1 Disponer de herramienta case. Comprar el licenciamiento de
Plan de Administración del Proyecto de Software
36
Enterprise Architect 7.0 dicho producto
R28
No se tiene generadores de código apropiados para la aplicación
0.3 2
El equipo cuenta con herramientas generadores de código.
Poner en funcionamiento el generador de aplicaciones, proceso y formularios.
R29
Hay herramientas de prueba apropiadas
0.5 2
Se realizaran pruebas funcionales, de completitud por iteraciones, comportamiento del entorno, y pruebas de estrés
Realizar por iteraciones las pruebas sugeridas
R30
Hay herramientas de gestión de configuración apropiadas
0.7 3
Se usara el TEEM System de Microsoft para gestionar las liberaciones del producto
Utilizar la herramienta mencionada
R31
Se hace uso de una base de datos o repositorio centralizado 0.4 1
R32
Están todas las herramientas de desarrollo integradas
0.3 2
Se usara el TEEM System de Microsoft para gestionar las liberaciones del producto
R33
Se ha proporcionado formación a todos los miembros del equipo de desarrollo
0.5 2
Hacer y dar a conocer los mecanismos de comunicación y el modelo de equipo.
Informar oportunamente.
R34 Hay expertos a los cuales solicitar ayuda acerca de las herramientas 0.7 3
Se presupuesta un monto para un consultor tecnológico.
Proceder a la contratación del consultor.
Tabla 7 : Plan de contingencia
Fuente: Elaboración propia
Plan de Administración del Proyecto de Software
37
1.2.2. Análisis de consecuencias del riesgo
De acuerdo al enfoque del análisis de riesgo propuesto por las Fuerzas Aéreas de Estados Unidos
•La exposición al riesgo en general, ER, se determina utilizando la siguiente relación:
ER=PxC Donde P es la probabilidad de que ocurra un riesgo, y C es el coste del proyecto si el riesgo ocurriera.
VALORACION DEL RIESGO
CAT. NRO RIESGO PROB. IMPACTO Costo
nro.dias esfuerzo c.unit ($us.)
Total(ER)
CLIE
NT
E
R1 Que existan frecuentes cambio de los requerimientos por parte de los cliente
0.4 1 1 1 8 9
R2 No tiene experiencia en proyectos anteriores de similares característica
0.3 2 1 2 8 10
R3 Idea Clara de los objetivos que pretende el proyecto y de los que quieren los usuarios
0.5 2 2 1 6 7
R4 No tiene Tiempo para un especificación formal de los requerimiento
0.7 3 1 2 2 4
R5 No deja Trabajar al equipo de desarrollo, para dando consejo de experto informático
0.4 1 1 1 1 2
R6 No entiende el ciclo de vida de producto. 0.3 2 3 3 3 6
PR
OC
. D
E P
RO
DU
CC
ION
R7 No Hay una política clara de normalización y seguimiento de una metodología
0.5 2 3 3 3 6
R8 Están los gestores y desarrolladores formados 0.7 3 1 2 2 4
R9 Conoce todo el mundo los estándares 0.4 1 1 1 1 2
R10 Existen plantillas y modelos para todos los documentos resultado del proceso
0.3 2 4 2 2 4
R11 Se aplican revisiones técnicas de la especificación de requerimientos diseño y codificación
0.5 2 2 2 2 4
R12 Se aplican revisiones técnicas de los procedimientos de revisión y prueba
0.7 3 2 1 1 2
R13 Se documentan los resultados de las revisiones técnicas 0.4 1 4 2 3 5
Plan de Administración del Proyecto de Software
38
R14 Hay algún mecanismos para asegurar que un proceso de desarrollo sigue los estándares
0.3 2 3 1 3 4
R15 Se realiza gestión de la configuración 0.5 2 4 2 2 4
R16 Hay mecanismos para controlar los cambios en los requerimientos que tienen impacto en el software
0.7 3 2 1 1 2
R17 Se documenta suficientemente cada subcontrato 0.4 1 4 3 2 5
R18 Se ha habilitado y se siguen mecanismos de seguimiento y evaluación técnica de cada subcontrato.
0.3 2 2 3 2 5
R19 Se dispone de técnicas de especificación de aplicaciones para facilitar la comunicación con el cliente.
0.5 2 2 2 1 3
R20 Se usan métodos específicos para análisis de software 0.7 3 1 1 3 4
R21 Se utiliza un método específico para el diseño arquitectónico y de datos
0.4 1 2 2 3 5
R22 Está el 90% del código en lenguajes de alto nivel 0.3 2 2 2 4
R23 Hay estándares de documentación de código 0.5 2 3 1 1 2
R24 Se usan métodos específicos para el diseño de pruebas 0.7 3 2 2 2 4
R25 Se utilizan herramientas para llevar a cabo la planificación y control
0.4 1 4 1 2 3
EN
TO
RN
O D
E D
ES
AR
RO
LLO
R26 Que no se tenga herramientas de gestión de proyectos 0.5 2 4 2 1 3
R27 Hay herramientas de análisis y diseño 0.4 1 1 1 3 4
R28 No se tiene generadores de código apropiados para la aplicación
0.3 2 5 3 3 6
R29 Hay herramientas de prueba apropiadas 0.5 2 6 3 2 5
R30 Hay herramientas de gestión de configuración apropiadas 0.7 3 7 2 1 3
R31 Se hace uso de una base de datos o repositorio centralizado 0.4 1 7 1 2 3
R32 Están todas las herramientas de desarrollo integradas 0.3 2 1 2 2 4
R33 Se ha proporcionado formación a todos los miembros del equipo de desarrollo
0.5 2 1 2 1 3
R34 Hay expertos a los cuales solicitar ayuda acerca de las herramientas
0.7 3 2 3 1 4
R35 Hay ayuda en línea y documentación disponible 0.4 1 1 1 2 3
TOTAL 90 64 84 148
Tabla 8 : Valoracion del riesgo.
Fuente: Elaboración propia
Plan de Administración del Proyecto de Software
39
CAT. NRO RIESGO PRO
B. IMPACT
O
Costo nro.dia
s esfuerz
o c.unit ($us.)
Total(ER)
CLIE
NT
E
R1 Que existan frecuentes cambio de los requerimientos por parte de los cliente
0.4 1 3 1 8 9
R2 No tiene experiencia en proyectos anteriores de similares característica
0.3 2 1 2 8 10
R3 Idea Clara de los objetivos que pretende el proyecto y de los que quieren los usuarios
0.5 2 2 1 6 7
R4 No tiene Tiempo para un especificación formal de los requerimiento 0.7 3 5 2 2 4
R5 No deja Trabajar al equipo de desarrollo, para dando consejo de experto informático
0.4 1 1 1 1 2
R6 No entiende el ciclo de vida de producto. 0.3 2 3 3 3 6
PR
OC
. D
E P
RO
DU
CC
ION
R7 No Hay una política clara de normalización y seguimiento de una metodología
0.5 2 3 3 3 6
R8 Están los gestores y desarrolladores formados 0.7 3 5 2 2 4
R9 Conoce todo el mundo los estándares 0.4 1 5 1 1 2
R10 Existen plantillas y modelos para todos los documentos resultado del proceso
0.3 2 4 2 2 4
R11 Se aplican revisiones técnicas de la especificación de requerimientos diseño y codificación
0.5 2 3 2 2 4
R12 Se aplican revisiones técnicas de los procedimientos de revisión y prueba
0.7 3 7 1 1 2
R13 Se documentan los resultados de las revisiones técnicas 0.4 1 4 2 3 5
R14 Hay algún mecanismos para asegurar que un proceso de desarrollo sigue los estándares
0.3 2 3 1 3 4
R15 Se realiza gestión de la configuración 0.5 2 4 2 2 4
R16 Hay mecanismos para controlar los cambios en los requerimientos que tienen impacto en el software
0.7 3 7 1 1 2
R17 Se documenta suficientemente cada subcontrato 0.4 1 4 3 2 5
R18 Se ha habilitado y se siguen mecanismos de seguimiento y 0.3 2 2 3 2 5
Plan de Administración del Proyecto de Software
40
evaluación técnica de cada subcontrato.
R19 Se dispone de técnicas de especificación de aplicaciones para facilitar la comunicación con el cliente.
0.5 2 2 2 1 3
R20 Se usan métodos específicos para análisis de software 0.7 3 1 1 3 4
R21 Se utiliza un método específico para el diseño arquitectónico y de datos
0.4 1 2 2 3 5
R22 Está el 90% del código en lenguajes de alto nivel 0.3 2 2 2 4
R23 Hay estándares de documentación de código 0.5 2 3 1 1 2
R24 Se usan métodos específicos para el diseño de pruebas 0.7 3 4 2 2 4
R25 Se utilizan herramientas para llevar a cabo la planificación y control 0.4 1 4 1 2 3
EN
TO
RN
O D
E D
ES
AR
RO
LLO
R26 Que no se tenga herramientas de gestión de proyectos 0.5 2 4 2 1 3
R27 Hay herramientas de análisis y diseño 0.4 1 6 1 3 4
R28 No se tiene generadores de código apropiados para la aplicación 0.3 2 5 3 3 6
R29 Hay herramientas de prueba apropiadas 0.5 2 6 3 2 5
R30 Hay herramientas de gestión de configuración apropiadas 0.7 3 7 2 1 3
R31 Se hace uso de una base de datos o repositorio centralizado 0.4 1 7 1 2 3
R32 Están todas las herramientas de desarrollo integradas 0.3 2 9 2 2 4
R33 Se ha proporcionado formación a todos los miembros del equipo de desarrollo
0.5 2 8 2 1 3
R34 Hay expertos a los cuales solicitar ayuda acerca de las herramientas 0.7 3 7 3 1 4
R35 Hay ayuda en línea y documentación disponible 0.4 1 11 1 2 3 Tabla 9 : Valoracion del riesgo.
Fuente: Elaboración propia
Plan de Administración del Proyecto de Software
41
1.2.3. Análisis de los datos obtenido:
Si la estimación de la duración LDC es de D(LDC)=8.04 meses y la estimación PF es
de D(PF)=11.78 meses más 3 meses por valoración del riesgo. La duración estimada
es de 14 meses.
1.3. Planificación Temporal
1.3.1. Identificación de tareas :
FICHA TECNICA:
PROYECTOS
Sistema integrado de información para la gestión de operaciones en el área de comercialización, inventarios y recursos humanos para la Cadena Nacional de Farmacias FarmaCorp
PROCESO Proceso Unificado de Desarrollo de Software
DURACIÓN 14 meses (280 días laborables)
DISTRIBUCIÓN DEL TIEMPO Plan (3%)
Dominio de información (25%) Diseño (25%)
Impl. (20%)
Prueba (27%) Negocio M.Req. Análisis
6 días 10 dias 20 dias 40 dias 70 dias 56 dias
75 dias
PLAN DE ITERACIONES ASIGNACION DE TIEMPO.
FASE DE INICIO 28 días
I1: Dominio de información 24 días
I2: Desarrollar el Plan de proyecto 4 días
FASE DE ELABORACION 96 días
E1: desarrollo de artefactos primarios 44 días
E2: Desarrollar casos de uso primario 52 días
Revisiones técnica formal 0 días
FASE DE CONSTRUCCION 90 días
C1: Desarrollar casos de uso secundario 40 días
C2: Refinamiento de la aplicación 50 días
Revisiones Técnica Formal 0 días
FASE TRANSICION 66 días
T1: Capacitación y pruebas con usuarios finales 20 días
T2: Refinamiento y corrección de errores 46 días
Tabla 10 : Identificación de tareas
Fuente: Elaboración propia
Plan de Administración del Proyecto de Software
42
1.3.2. Diagrama de Gantt
Plan de Administración del Proyecto de Software
43
1.3.3. Diagrama de red
1.3.3.1. Fase de inicio
Ilustración 3: Diagrama de red fase de inicio
Fuente: Elaboración propia
Plan de Administración del Proyecto de Software
44
1.3.3.2. Fase de elaboración
Ilustración 4: Diagrama de red fase de elaboracion
Fuente: Elaboración propia
Plan de Administración del Proyecto de Software
45
1.3.3.3. Fase de construcción
Ilustración 5: Diagrama de red fase de construcción
Fuente: Elaboración propia
Plan de Administración del Proyecto de Software
46
1.3.3.4. Fase de transición.
Ilustración 6: Diagrama de red fase de transición.
Fuente: Elaboración propia
Plan de Administración del Proyecto de Software
47
1.4. Organización Interna
1.4.1. Estructura.
1.4.2. Paradigma de la organización.
Se empleara el Proceso Unificado de Software por su naturaleza iterativa e
incremental de desarrollo de software.
1.4.3. Organización del equipo
Tabla 12: Modelo descentralizado controlado
El modelo Descentralizado Controlado (DC).por los siguientes motivos: Tiene un
gestor de proyecto para las tareas de “alta gerencia”, Tiene gestores técnico
operativos para tareas específicas. La resolución de problemas se hace en grupo del
área de atención. Existir coordinación entre los subgrupos; la comunicación entre
subgrupos e individuos es horizontal y Hay comunicación vertical entre los jefes
secundarios y el gestor del equipo Modularidad alta (la gente puede hacer cada uno
lo suyo)
Gestor de proyecto
Analista – programado 1 Analista – programado 2
Analista – programado 3
Consultor tecnologico
Tabla 11: Estructura orgánica del equipo Fuente: Elaboración propia
Plan de Administración del Proyecto de Software
48
1.5. Recursos
1.6. Recursos Humanos.
El recurso humano disponible para el presente proyecto es el siguiente
Empleado cargo
Ernesto Soto Roca Gestor de proyecto
Juan Martínez Sánchez Consultor tecnológico
María Zurita Sánchez Analista programador
Marcos Mariscal Martínez Analista programador
Federico Villa Marthi Analista programador
1.7. Equipos:
Empleado cargo
equipo
Ernesto Soto Roca Gestor de proyecto Computador personal
Juan Martínez Sánchez Consultor tecnológico Equipo de desarrollo
María Zurita Sánchez Analista programador Equipo de desarrollo
Marcos Mariscal Martínez Analista programador Equipo de desarrollo
Federico Villa Marthi Analista programador Equipo de desarrollo
1.8. Costo del Proyecto
Tomando datos de técnicas de estimaciones LDC, Punto función, COCOMO más la
valoración del esfuerzo el costo del proyecto sería de 30000 Sus. Con una duración de 1
año y 4 meses.
Plan de Administración del Proyecto de Software
49
ANEXO
Plan de Administración del Proyecto de Software
50
ANEXO A-01.
1. Modelo de negocio Proceso de negocio Gestionar los pedidos a proveedor - (Activity diagram)
Created By: Ernesto Soto Roca on 03/08/2009
Last Modified: 18/02/2010
Version: 1.0. Locked: False
GUID: {98BDBBB2-0A49-437f-9A84-182824E667D9}
act Proceso de negocio Gestionar los pedidos a prov eedor
Proveedor Encargado de Inventario Dpto. de Finanzas
Inicio
Verifica el stock de producto por
almacenes
Si no existe stock de
producto
Solicita la cotizacion de
productos a prov eedor
Realiza solicitud de
pedido a prov eedor
Rev isa la solicitud de
pedido del dpto. de
inv entario
aprobar el pedido a
Inventario
Aceptar solicitud de
pedido de inv entario
Colaca las observ aciones
al pedido
Env iar el pedido de
productos al prov eedor
Recepciona la
conformidad de finanzas
Recepciona la solicitud
de pedido
Env ia el pedido
solicitado
Recepcionar el pedido
de prov eedor
Verifica los productos
del pedido
Si no existen observaciones
Almacenar los
productos
Final
2 dias 1 dias2 dias
Ilustración 7: Proceso de negocio Gestionar los pedidos a proveedor
Plan de Administración del Proyecto de Software
51
Proceso de negocio gestión de devoluciones - (Activity diagram)
Created By: Ernesto Soto Roca on 04/08/2009
Last Modified: 04/08/2009
Version: 1.0. Locked: False
GUID: {CAD2B3F7-A04F-4c56-A57B-0125199CD020}
Ilustración 8: Proceso de negocio gestión de devoluciones a proveedores
Plan de Administración del Proyecto de Software
52
Proceso de negocio gestionar los pedidos internos de la empresa - (Activity diagram)
Created By: Ernesto Soto Roca on 03/08/2009
Last Modified: 19/02/2010
Version: 1.0. Locked: False
GUID: {C977EBFA-E995-45d7-BF1D-138765AA4797}
act Proceso de negocio gestionar los pedidos internos de la empresa
Dpto. de ventas Encargado de inventario
Verifica el stock de
producto
Realiza solicitud de
pedido al dpto. de
inv entario
Recepciona el pedido
realizado
Inicio
Si no existe stock
de producto
Rev isa la solicitud de
pedido del dpto. de
inv entario
aprobar el pedido a
Inventario
Aceptar solicitud de
pedido de inv entario
Colaca las observ aciones
al pedido
Elabora el pedido de
producto
Env ia el pedido interno a
v entaSi hay Observacion
Recepcionar los
productos y almacenar
Final
Ilustración 9: Proceso de negocio gestionar los pedidos internos de la empresa
Plan de Administración del Proyecto de Software
53
2. ANEXO A-02.
a. Modelo de requerimiento Diagrama de casos de uso funcional - (Use Case diagram)
Created By: Ernesto Soto Roca on 27/07/2009
Last Modified: 19/08/2009
GUID: {66ECD689-DBBB-47c0-A846-A76F15EE571C}
Ilustración 10: Diagrama de casos de uso funcional módulo de inventario
Plan de Administración del Proyecto de Software
54
Diagrama De Casos de uso Administrativo del Sistema - (Use Case diagram)
Created By: Ernesto Soto Roca on 27/07/2009
Last Modified: 27/11/2009
Version: 1.0. Locked: False
GUID: {EDCB1E1F-54EE-44f5-91F8-A2FA260A9BF1}
uc diagrama de casos de uso administrativ o del sistema
Diagrama de casos de uso de funciones para administracion del sistema
Encargado del sistema
Asistente del sistema
Gerencia de operaciones
Gestionar backup de
la base de datos
Restaurar Copia de
seguridad de la base
de datos
Registrar
Sucursal
Gestionar Usuario
del sistema
Definir accesos al
sistema
Ilustración 11: Diagrama De Casos De Uso Administrativo Del Sistema
Plan de Administración del Proyecto de Software
55
Diagramas De Casos De Uso De Reportes - (Use Case diagram)
Created By: Ernesto Soto Roca on 27/07/2009
Last Modified: 10/08/2009
Version: 1.0. Locked: False
GUID: {0F16152E-F3B5-45db-898F-29FDC4D1D14C}
uc diagramas de casos de uso de reportes
Diagrama de casos de uso de requerimiento de informacion
Encargado de Inv entario
Asistente de inv entario
Dpto. de finanzas
Dpto. de v entas
«gerencia»
Elaborar Informe de
stock de producto
«gerencia»
Emitir informe de
dev oluciones a
prov eedor
«gerencial»
Elaborar Informe de
pedidos de v enta
«gerencia»
Elaborar Informe de
pedidos a prov eedor
«gerencia»
Elaborar informe de
de dev oluciones de
v enta
«gerencia»
Elaborar Resumen
de pedidos a
prov eedor
Emitir Ficha de
registro del
prov eedor
Emitir
Comprobante de
pedido a
prov eedor
Emitir
Comprobante de
pedido a inv entario
Emitir acta de
recepcion de
productos del dpto
de inv entario
Emitir acta de
recepcion de
peddido del
prov eedor
Emitir comprobante
de dev olucion a
prov eedor
Emitir acta de
dev olucion de
productos a
inv entario
Ilustración 12:Diagrama De Casos De Uso Administrativo Del Sistema
Plan de Administración del Proyecto de Software
56
Modelo De Caso De Uso - (Use Case diagram)
Created By: Ernesto Soto Roca on 06/05/2009
Last Modified: 20/05/2009
Version: 1.0. Locked: False
GUID: {B8005AFE-8E12-4030-9002-F659551228EE}
uc modelo de caso de uso
Sistema de ventas de medicamento
Atencion al clienteEncargado de seccion
Registrar
Rubro
Gestionar
Cliente
Realizar el
pedido del
cliente
Programar
Creditos a pedido
Registrar
producto
Registrar
categoria
Registrar Sub
Categoria
Registrar
Forma de pago
Registrar
calificacion
Registrar
Moneda
Ilustración 13: Casos de usos funcionales del sistema de ventas
Plan de Administración del Proyecto de Software
57
3. ANEXO A-03.
a. Modelo de análisis. Diagrama de clases de Análisis - (Logical diagram)
Created By: Ernesto Soto Roca on 23/08/2009Last Modified: 03/08/2011
Version: 1.0. Locked: False GUID: {F185DB4E-212C-41e5-A398-6267C7A4AB7B}
Ilustración 14: diagrama de clases de análisis sistema de inventario
Plan de Administración del Proyecto de Software
58
Domain Model - (Logical diagram)
Created By: Ernesto Soto Roca on 19/11/2005
Last Modified: 27/05/2009
Version: 1.0. Locked: False
GUID: {B8D51A91-B583-47f9-A3FA-5D2700A02F62}
Ilustración 15: clase s de análisis módulo de ventas.