Ejemplo Plan de 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
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
2
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
1.2. Análisis de Riesgo. ................................................................................................ 31
Fuente: Elaboración propia............................................................................................... 32
1.2.1. Planificación del riesgo. ..................................................................................... 33
1.2.2. Análisis de consecuencias del riesgo ................................................................. 37
1.2.3. Análisis de los datos obtenido: ........................................................................... 41
1.3. Planificación Temporal .......................................................................................... 41
1.3.1. Identificación de tareas : .................................................................................... 41
1.3.2. Diagrama de Gantt ............................................................................................. 42
1.3.3. Diagrama de red ................................................................................................. 43
1.3.3.1. Fase de inicio .................................................................................................. 43
1.3.3.2. Fase de elaboración ........................................................................................ 44
1.3.3.3. Fase de construcción ....................................................................................... 45
3

1.3.3.4. Fase de transición. .......................................................................................... 46
1.4. Organización Interna .............................................................................................. 47
1.4.1. Estructura. .......................................................................................................... 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
4
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
5

(PAPS)
6
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.
7
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
8
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.
9
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.
10
1.3.1.1. Mapa Mental de la situación problemática:
Ilustración 1: Situación Problemática

Fuente: Elaboración Propia
11
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
12
 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.
13
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.
14
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.
15
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
16
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
17
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.
18
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)
19
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.
20
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.
21
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 IIS SERVIDOR SQL SERVIDOR DOMINIO SERVIDOR APLICACIONES
RED LAN
SERVIDOR CODINES
DIAGRAMA DE
INSTALACION DE CADA CODIN
CODIN
SEDE ARL9000
RED RS485 CODIN
CODIN CODIN
CODIN
Ilustración 2: Identificación de infraestructura local

 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.
22
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).
23
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.
PR O D U C T I V I D A
PR O D U C T I V I D A D D ( PF / E) C A LI D A D D U R A C ION Par a 6 meses cuant as
PR O LD C E C O ST O P. D O C . ER R O R S D EF EC T O S PER SO N A S KLD C ( KLD C / E) ( Er r o r / KLD C ) ( E/ Per so na) p er so nas
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)
1.9.2. Métricas orientadas a la función
Factor de ponderación: FACTOR DE AJUSTE DE COMPLEJIDAD
Factor de ponderación Va lo re s de a jus te de c o m ple jida d: 0 e s no influe 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 nific a tiv o y 5 e s e s e nc ia l
1. ¿Requiere el sistema copias de seguridad y de recuperación fiables? 5
Parámetro Cuenta Simple Medio Complejo Subtotal
Número de entradas de usuario 56 3 4 6 224 2. ¿Requiere comunicación de datos? 5
Número de salidas de usuario 38 4 5 7 266 3. ¿Existen funciones de procesamiento distribuido?
Número de peticiones de 15 3 4 6 60
2
Número de archivos 35 7 10 15 350 4. ¿Es crítico el rendimiento? 3
Número de interfaces externas 1 5 7 10 7 5. ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado? 4
C ue nta Total
 Ct
907
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 4
Entradas de usuario. Son entradas que proporcionan diferentes datos a la aplicación. No confundirlos con las peticiones de usuario. pantallas
8. ¿Seu operaciones?
actualizan los archivos maestros de forma interactiva? 3
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. 9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones? 2
Peticiones de usuario. Es una entrada interactiva que produce la generación de alguna respuesta del software en forma de salida interactiva. 10. ¿Es complejo el procesamiento interno? 3
Archivos. Son los archivos que pueden ser parte de una base de datos o independientes. 11. ¿Se ha diseñado el código para ser reutilizable? 5
Interfaces externas. Son los archivos que se usan para transmitir información a otro sistema. 12. ¿Están incluidas en el diseño la conversión y la instalación? 5
13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones? 5
14 ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario? 5
∑fi. Fi fi 54
PF=1079.33 Con estos datos actualizamos los datos histórico de productividad media (PF).
24
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
25
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
Sueldo
Empleado cargo Mensual Duración Costo (sus.)
(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.
26
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
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
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 Nominal Alto Muy Extr.

bajo alto 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
27
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.
28
1.1.2. Estimaciones Basadas en punto función.
1.- Estimación de los valores del dominio de información.

Valor de dominio So Sp Pesimista Media FACTOR DE SUBTO
de información ponderada PONDERACION 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
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
 Fi 38
Tabla 4 : Valores de ajuste de complejidad
PF=833.4416667
29
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
Sueldo
Empleado cargo Mensual Duración Costo (sus.)
(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.
30
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

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
CLIENTE
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
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
PROC. DE PRODUCCION
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
31
R25 Se utilizan herramientas para llevar a cabo la planificación y control 0.4 1

R26 Que no se tenga herramientas de gestión de proyectos 0.5 2
ENTORNO DE DESARROLLO
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
32
1.2.1. Planificación del riesgo.

PLAN DE CONTINGENCIA
RIESGOS DESPUES DE LA LINEA DE CORTE.
CAT. N. RIESGO PROB. IMP PREVENCION GESTION
Que existan frecuentes cambio de los Se aplicaran técnicas de El cliente deberá priorizar los
requerimientos por parte de los identificación de requerimiento, requerimientos en compañía del
clientes. como cuestionarios, entrevistas equipo de desarrollo. Los cuales
personales, identificación del no podrán ser cambiados hasta
problema usando mapas que termine la iteración que por
mentales, y la construcción de lo general dura de dos a cuatro
prototipos evolutivos del software semanas como máximo.
enmarcados en un modelo
R1 0.4 1 incremental e iterativo.
No tiene experiencia en proyectos Se elaboran cuestionarios, Los resultados de cada iteración
anteriores de similares característica orientados a detectar la servirán como datos históricos
experiencia del cliente y usuarios reales de productividad y
final, con el uso de tecnologías esfuerzo para el proyecto, lo cual
CLIENTE similares, la facilidad u oposición permitirá ajustar la planificación a
PROC. DE al cambio. medica que evoluciona el
PRODUCCION R2 0.3 2 desarrollo
Idea Clara de los objetivos que Se trabajara en identificar Construcción de mapas
pretende el proyecto y de los que plenamente la situación mentales, procesos de negocio
quieren los usuarios. problemática, y el problema que actuales de la empresa
solucionara el aplicativo. detectando el funcionamiento
R3 0.5 2 real de la actividades
No tiene Tiempo para una Se dejara en claro la importancia Definir un conducto formal,
especificación formal de los de la participación del cliente en planificado de las reuniones de
requerimientos. la priorización de requerimiento y evaluación, e inicio de iteración,
evaluación del resultado en cada según el proceso.
R4 0.7 3 iteración.
No deja Trabajar al equipo de
desarrollo, para dando consejo de
R5 experto informático 0.4 1
33
No entiende el ciclo de vida de

producto.
R6 0.3 2
No Hay una política clara de Existen un plan de proyectos, La actualización continúa del
normalización y seguimiento de una planificación temporal que plan de proyecto por el gestor de
metodología normara el desarrollo del proyecto. Y la auto planificación
proyecto de actividades por cada equipo
R7 0.5 2 de desarrollo
Están los gestores y desarrolladores
R8 formados 0.7 3
Conoce todo el mundo los estándares Se hará un riguroso seguimiento Detección del artefacto fuera de
a la aplicación de normas y norma, corrección y
estándares propuesto por el plan autoevaluación.
R9 0.4 1 de proyecto.
Existen plantillas y modelos para todos Apego a estándares y normas de Detección de los artefactos no
los documentos resultado del proceso documentación. documentados y fuera de
norma, y procedes a la
R10 0.3 2 corrección.
PROC. DE Se aplican revisiones técnicas de la Se realizaran presentación por Efectivizar las reuniones de
PRODUCCION especificación de requerimientos iteraciones cortas. Donde se autoevaluación y revisión de
ENTORNO DE diseño y codificación procederá a la revisión de los artefactos construidos.
DESARROLLO entregables y la gestión de
R11 0.5 2 configuración.
Se aplican revisiones técnicas de los
R12 procedimientos de revisión y prueba 0.7 3
Se documentan los resultados de las Se contempla la gestión de Efectivizar las reuniones de
revisiones técnicas configuración autoevaluación y revisión de
artefactos construidos,
identificación por cada
R13 0.4 1 entregable.
Hay algún mecanismos para asegurar
que un proceso de desarrollo sigue los
R14 estándares 0.3 2
Se realiza gestión de la configuración Se contempla la gestión de Preparar el Plan de SQA para
R15 0.5 2 configuración cada proyecto.
Hay mecanismos para controlar los Revisar las actividades de Auditar los productos de trabajo
R16 cambios en los requerimientos que 0.7 3 ingeniería en acuerdo con el designados, para verificar su
34
tienen impacto en el software proceso definido. adherencia con aquellos

definidos en el modelo de
proceso.
Se documenta suficientemente cada
R17 subcontrato 0.4 1
Se ha habilitado y se siguen
mecanismos de seguimiento y
evaluación técnica de cada
R18 subcontrato. 0.3 2
Se dispone de técnicas de Planificación de las Informar el Rendimiento:
especificación de aplicaciones para Comunicaciones: determinar las recopilar y distribuir información
facilitar la comunicación con el cliente. necesidades de información y sobre el rendimiento. Esto
comunicaciones de los incluye informes de estado,
interesados en el proyecto. medición del progreso y
proyecciones.
R19 0.5 2 s.
Se usan métodos específicos para Distribución de la Información: Gestionar a los Interesados:
análisis de software poner la información necesaria a gestionar las comunicaciones a
disposición de los interesados en fin de satisfacer los requisitos de
el proyecto cuando corresponda. los interesados en el proyecto y
R20 0.7 3 resolver polémicas con ello
Se utiliza un método específico para el
R21 diseño arquitectónico y de datos 0.4 1
Está el 90% del código en lenguajes de
R22 alto nivel 0.3 2
Hay estándares de documentación de
R23 código 0.5 2
Se usan métodos específicos para el
R24 diseño de pruebas 0.7 3
Se utilizan herramientas para llevar a
R25 cabo la planificación y control 0.4 1
Que no se tenga herramientas de Definir con anticipación las Comprar las licencias para la
ENTORNO DE gestión de proyectos herramientas y tecnologías a gestión de configuración,
DESARROLLO R26 0.5 2 emplear. planificación.
R27 Hay herramientas de análisis y diseño 0.4 1 Disponer de herramienta case. Comprar el licenciamiento de
35
Enterprise Architect 7.0 dicho producto

No se tiene generadores de código El equipo cuenta con Poner en funcionamiento el
apropiados para la aplicación herramientas generadores de generador de aplicaciones,
R28 0.3 2 código. proceso y formularios.
Hay herramientas de prueba Se realizaran pruebas Realizar por iteraciones las
apropiadas funcionales, de completitud por pruebas sugeridas
iteraciones, comportamiento del
R29 0.5 2 entorno, y pruebas de estrés
Hay herramientas de gestión de Se usara el TEEM System de Utilizar la herramienta
configuración apropiadas Microsoft para gestionar las mencionada
R30 0.7 3 liberaciones del producto
Se hace uso de una base de datos o
R31 repositorio centralizado 0.4 1
Están todas las herramientas de Se usara el TEEM System de
desarrollo integradas Microsoft para gestionar las
R32 0.3 2 liberaciones del producto
Se ha proporcionado formación a todos Hacer y dar a conocer los Informar oportunamente.
los miembros del equipo de desarrollo mecanismos de comunicación y
R33 0.5 2 el modelo de equipo.
Hay expertos a los cuales solicitar Se presupuesta un monto para un Proceder a la contratación del
R34 ayuda acerca de las herramientas 0.7 3 consultor tecnológico. consultor.
Tabla 7 : Plan de contingencia

36
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

Costo
CAT. NRO RIESGO PROB. IMPACTO c.unit
nro.dias esfuerzo Total(ER)
($us.)
Que existan frecuentes cambio de los requerimientos por parte
R1 de los cliente
0.4 1 1 1 8 9
No tiene experiencia en proyectos anteriores de similares
R2 característica
0.3 2 1 2 8 10
CLIENTE
Idea Clara de los objetivos que pretende el proyecto y de los

R3 que quieren los usuarios
0.5 2 2 1 6 7
No tiene Tiempo para un especificación formal de los
R4 requerimiento
0.7 3 1 2 2 4
No deja Trabajar al equipo de desarrollo, para dando consejo
R5 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
No Hay una política clara de normalización y seguimiento de
PROC. DE PRODUCCION
R7 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
Existen plantillas y modelos para todos los documentos
R10 resultado del proceso
0.3 2 4 2 2 4
Se aplican revisiones técnicas de la especificación de
R11 requerimientos diseño y codificación
0.5 2 2 2 2 4
Se aplican revisiones técnicas de los procedimientos de
R12 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
37
Hay algún mecanismos para asegurar que un proceso de

R14 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
Hay mecanismos para controlar los cambios en los
R16 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
Se ha habilitado y se siguen mecanismos de seguimiento y
R18 evaluación técnica de cada subcontrato.
0.3 2 2 3 2 5
Se dispone de técnicas de especificación de aplicaciones para
R19 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
Se utiliza un método específico para el diseño arquitectónico y
R21 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
Se utilizan herramientas para llevar a cabo la planificación y
R25 control
0.4 1 4 1 2 3
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

No se tiene generadores de código apropiados para la
R28 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
Se ha proporcionado formación a todos los miembros del
R33 equipo de desarrollo
0.5 2 1 2 1 3
Hay expertos a los cuales solicitar ayuda acerca de las
R34 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.
38
PRO IMPACT Costo

CAT. NRO RIESGO nro.dia esfuerz c.unit Total(E
B. O
s o ($us.) R)
Que existan frecuentes cambio de los requerimientos por parte de
R1 0.4 1 3 1 8 9
los cliente
No tiene experiencia en proyectos anteriores de similares
R2 0.3 2 1 2 8 10
característica
CLIENTE
Idea Clara de los objetivos que pretende el proyecto y de los que

R3 0.5 2 2 1 6 7
quieren los usuarios
R4 No tiene Tiempo para un especificación formal de los requerimiento 0.7 3 5 2 2 4
No deja Trabajar al equipo de desarrollo, para dando consejo de
R5 0.4 1 1 1 1 2
experto informático
R6 No entiende el ciclo de vida de producto. 0.3 2 3 3 3 6
No Hay una política clara de normalización y seguimiento de una
R7 0.5 2 3 3 3 6
metodología
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
Existen plantillas y modelos para todos los documentos resultado
PROC. DE PRODUCCION
R10 0.3 2 4 2 2 4
del proceso
Se aplican revisiones técnicas de la especificación de
R11 0.5 2 3 2 2 4
requerimientos diseño y codificación
Se aplican revisiones técnicas de los procedimientos de revisión y
R12 0.7 3 7 1 1 2
prueba
R13 Se documentan los resultados de las revisiones técnicas 0.4 1 4 2 3 5
Hay algún mecanismos para asegurar que un proceso de desarrollo
R14 0.3 2 3 1 3 4
sigue los estándares
R15 Se realiza gestión de la configuración 0.5 2 4 2 2 4
Hay mecanismos para controlar los cambios en los requerimientos
R16 0.7 3 7 1 1 2
que tienen impacto en el software
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
39
evaluación técnica de cada subcontrato.

Se dispone de técnicas de especificación de aplicaciones para
R19 0.5 2 2 2 1 3
facilitar la comunicación con el cliente.
R20 Se usan métodos específicos para análisis de software 0.7 3 1 1 3 4
Se utiliza un método específico para el diseño arquitectónico y de
R21 0.4 1 2 2 3 5
datos
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
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
Se ha proporcionado formación a todos los miembros del equipo de
R33 0.5 2 8 2 1 3
desarrollo
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.
40
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:
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
PROYECTOS FarmaCorp
PROCESO Proceso Unificado de Desarrollo de Software
DURACIÓN 14 meses (280 días laborables)
Dominio de información (25%) Prueb
Diseño Impl. a
DISTRIBUCIÓN DEL TIEMPO Plan (3%) Negocio M.Req. Análisis (25%) (20%) (27%)
56 75
6 días 10 dias 20 dias 40 dias 70 dias dias 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
41
1.3.2. Diagrama de Gantt
42
1.3.3. Diagrama de red

1.3.3.1. Fase de inicio
Ilustración 3: Diagrama de red fase de inicio

43
1.3.3.2. Fase de elaboración
Ilustración 4: Diagrama de red fase de elaboracion

44
1.3.3.3. Fase de construcción
Ilustración 5: Diagrama de red fase de construcción

45
1.3.3.4. Fase de transición.
Ilustración 6: Diagrama de red fase de transición.

46
1.4. Organización Interna

1.4.1. Estructura.
Gestor de proyecto
Consultor tecnologico
Analista – programado 1 Analista – programado 2 Analista – programado 3
Tabla 11: Estructura orgánica del equipo

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)
47
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:
equipo
Empleado cargo
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.
48
ANEXO
49
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
Rev isa la solicitud de

pedido del dpto. de
inv entario
Recepcionar el pedido Verifica el stock de producto por

Recepciona la solicitud almacenes aprobar el pedido a
de prov eedor
de pedido Inventario
Si no existe stock de
producto Colaca las observ aciones Aceptar solicitud de
Verifica los productos al pedido pedido de inv entario
del pedido
Env ia el pedido
solicitado Solicita la cotizacion de
productos a prov eedor
Si no existen observaciones
Realiza solicitud de
pedido a prov eedor
Almacenar los
productos
Recepciona la
conformidad de finanzas
Env iar el pedido de

productos al prov eedor
Final
2 dias
2 dias 1 dias
Ilustración 7: Proceso de negocio Gestionar los pedidos a proveedor
50
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
51
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
Inicio
Verifica el stock de Rev isa la solicitud de

producto pedido del dpto. de
inv entario
Si no existe stock
de producto aprobar el pedido a
Inventario
Realiza solicitud de
pedido al dpto. de Colaca las observ aciones Aceptar solicitud de
inv entario al pedido pedido de inv entario
Recepciona el pedido Elabora el pedido de

realizado producto
Env ia el pedido interno a

v enta
Si hay Observacion
Recepcionar los
productos y almacenar
Final
Ilustración 9: Proceso de negocio gestionar los pedidos internos de la empresa
52
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
53
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
Gestionar Usuario
del sistema
Registrar
Encargado del sistema Sucursal
Gerencia de operaciones
Gestionar backup de Definir accesos al

la base de datos sistema
Restaurar Copia de
seguridad de la base
de datos
Asistente del sistema
Ilustración 11: Diagrama De Casos De Uso Administrativo Del Sistema
54
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

«gerencia»
«gerencia» «gerencia»
Emitir informe de
dev oluciones a Elaborar informe de Elaborar Resumen
prov eedor de dev oluciones de de pedidos a
v enta prov eedor
Dpto. de finanzas
«gerencia»
Elaborar Informe de
pedidos a prov eedor
Emitir acta de
recepcion de
Emitir Ficha de productos del dpto
registro del Emitir
Comprobante de de inv entario
Encargado de Inv entario prov eedor
pedido a
prov eedor
Emitir comprobante Emitir

de dev olucion a Comprobante de
prov eedor pedido a inv entario
Emitir acta de
recepcion de
peddido del
prov eedor «gerencial»
Elaborar Informe de
pedidos de v enta
Dpto. de v entas
Asistente de inv entario
«gerencia»
Elaborar Informe de Emitir acta de
stock de producto dev olucion de
productos a
inv entario
Ilustración 12:Diagrama De Casos De Uso Administrativo Del Sistema
55
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

Registrar
producto
Registrar
Registrar
Rubro
Moneda
Gestionar
Cliente
Registrar
Realizar el categoria
Atencion al cliente pedido del Encargado de seccion
cliente
Registrar Sub
Categoria
Programar
Creditos a pedido
Registrar
Forma de pago
Registrar
calificacion
Ilustración 13: Casos de usos funcionales del sistema de ventas
56
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
57
Domain Model - (Logical diagram)

GUID: {B8D51A91-B583-47f9-A3FA-5D2700A02F62}
Ilustración 15: clase s de análisis módulo de ventas.
58

Ejemplo Plan de Proyecto de Software (PAPS)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ejemplo Plan de Proyecto de Software (PAPS)

Uploaded by

Copyright:

Available Formats

Universidad Autónoma Gabriel Rene Moreno.

Maestría en Ingeniería de Software

Plan de Administración del Proyecto de Software.

Sistema integrado de información para la gestión de operaciones en el área de

Módulo Introducción a la Ingeniería de software

Santa Cruz - Bolivia

1.8.2.9. Motor de base de datos ................................................................................... 21

Fuente: Elaboración propia ............................................................................................... 45

Plan de Administración del Proyecto de Software

FarmaCorp, Cadena Nacional de Farmacias es una Unidad de Negocios del grupo

1.3. Planteamiento del problema

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

Ilustración 1: Situación Problemática

1.3.2. Situación Deseada

1.4.2. Delimitación Espacial

1.4.3. Delimitación Temporal

 Diseñar el sistema contemplando los módulos anteriores para su integración

1.6.2. Justificación Metodológica

1.6.3. Justificación Practica

1.7. Diseño Metodológico

1.7.2. Procesos Metodológicos

Ilustración 1. 1: Diagrama de Fases y Flujos

1.7.4. Técnicas para recolección de información

1.7.5. Recursos utilizados

1.7.5.2. Instrumentos de Análisis

28 Recepcionar Solicitud del pedido del dpto. de venta inventario

1.8.2. Requerimientos no funcionales.

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

o Requisitos de entorno y sistema operativo, compatibilidad y restricciones de

o Otros requisitos que no se contemplan en el documento de requerimiento de

1.8.2.2. Tiempo de aprendizaje

o Usuario de carga: 2 días

1.8.2.3. Identificación del usuario propio de la aplicación

1.8.2.3.1. Contraseña de usuario

o La contraseña debe viajar encriptado entre el cliente, el servidor Web y

1.8.2.4.2. Tiempo comprendido entre fallas

1.8.2.4.3. Tiempo fuera de servicio

o Fallas comunes 40 minutos (estimado)

o Fallas no comunes 1hora. (estimado)

1.8.2.4.4. Registro de eventos

1.8.2.5.2. Tiempo de respuesta

El tiempo de respuesta para una transacción promedio también debe ser de 15

1.8.2.5.3. Cantidad de atención a usuarios

1.8.2.6. Soportabilidad o Facilidad de Mantenimiento

1.8.2.7. Estándares de codificación

1.8.2.8. Restricciones de Diseño

1.8.2.8.2. Estándares de arquitectura

1.8.2.9. Motor de base de datos

1.8.2.10. Cliente del navegador

1.8.2.11. Servidor Web

1.8.2.12. Lenguaje de programación

1.8.2.13. Requerimientos de documentación, ayuda en línea y manuales,

1.8.2.13.2. Ayuda en línea

1.8.2.13.3. Guías de Instalación y Configuración

1.8.2.13.4. Apoyo Técnico

1.8.2.14.2. Interfaz de Hardware

o Para el Entorno de Red: la aplicación deberá tener la capacidad de

SERVIDOR IIS SERVIDOR SQL SERVIDOR DOMINIO SERVIDOR APLICACIONES

RED RS485 CODIN

Ilustración 2: Identificación de infraestructura local

 Redes WAN, ADSL de 1024 MB Frame Relay 128

1.8.2.15. Requerimientos de Licencias