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


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


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


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


6

Plan de Administración del Proyecto de Software (PAPS)


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


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.


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

http://www.nexocorp.com.bo/Farmacorp/info/quienessomos.aspx


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.


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.


11

1.3.1.1. Mapa Mental de la situación problemática:

Ilustración 1: Situación Problemática Fuente: Elaboración Propia


12

1.3.2. Situación Deseada

Contar con un sistema integrado de información para la gestión de operaciones en el



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



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


Realizar el análisis de los requerimientos planteados como requisitos


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.


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.


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.


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


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


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.


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)


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.


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.


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.


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


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)


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



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


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.


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


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


Para un equipo 3 personas trabajando alrededor de 7 meses, El equipo formado por 3 analista

programador 1 gestor y un consultor externo.


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


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


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



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.


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


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



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


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


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


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



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


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.



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


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.



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



42

1.3.2. Diagrama de Gantt


43

1.3.3. Diagrama de red

1.3.3.1. Fase de inicio

Ilustración 3: Diagrama de red fase de inicio



44

1.3.3.2. Fase de elaboración

Ilustración 4: Diagrama de red fase de elaboracion



45

1.3.3.3. Fase de construcción

Ilustración 5: Diagrama de red fase de construcción



46

1.3.3.4. Fase de transición.

Ilustración 6: Diagrama de red fase de transición.



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


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.


49

ANEXO


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


51

Proceso de negocio gestión de devoluciones - (Activity diagram)




GUID: {CAD2B3F7-A04F-4c56-A57B-0125199CD020}

Ilustración 8: Proceso de negocio gestión de devoluciones a proveedores


52

Proceso de negocio gestionar los pedidos internos de la empresa - (Activity diagram)




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


53

2. ANEXO A-02.

a. Modelo de requerimiento Diagrama de casos de uso funcional - (Use Case diagram)



GUID: {66ECD689-DBBB-47c0-A846-A76F15EE571C}

Ilustración 10: Diagrama de casos de uso funcional módulo de inventario


54

Diagrama De Casos de uso Administrativo del Sistema - (Use Case diagram)




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


55

Diagramas De Casos De Uso De Reportes - (Use Case diagram)




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


56

Modelo De Caso De Uso - (Use Case diagram)




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


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


58

Domain Model - (Logical diagram)




GUID: {B8D51A91-B583-47f9-A3FA-5D2700A02F62}

Ilustración 15: clase s de análisis módulo de ventas.

plan de administración del proyecto de software. (paps)

Documents