Proyecto Farmacia Plan Desarrollo

UNIVERSIDAD AUTNOMA GABRIEL REN MORENO
Unidad de Postgrado de la Facultad de Ciencias Exactas y

Tecnologa
PLAN DE DESARROLLO PARA EL SISTEMA FARMACORP

Versin 1.3
Presentada por:
Marines Lpez
YennyPrez
Timoteo Ponce
Roger Uoja
Carla Villena
Santa Cruz de la Sierra, Bolivia

0
TERA
SOFT
PLAN DE DESARROLLO DE
SOFTWARE
Cdigo: TS-DPD-01
Revisin: 4
Versin: 04
CONTROL DE CAMBIOS
NUMERO
DE
REVISION
SECCION Y/O
PAGINA
DESCRIPCION DE LA
MODIFICACION
FECHA DE
MODIFICACION
Toda el
documento
Versin inicial
25-4-2012
Organizacin y
Correcciones y verificaciones
Responsabilidades
26-4-2012
Planificacin
temporal y de
recursos
Planificacin temporal y de recursos
27-4-2012
Todo el
documento
Primera revisin
05-05-2012
i
ELABORO
Timoteo Ponce
Control de Emisin
REVISO
APROBO
Yenny Perez
Marines Lopez
Timoteo Ponce
Roger Uoja
Carla Villena
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-01
Revisin: 4
Versin: 04
INDICE DEL CONTENIDO

1.
INTRODUCCIN
1.1.
Antecedentes...............................................................................................................................1
1.2.
Definicin del problema..............................................................................................................1
1.3.
Situacin problemtica................................................................................................................1
2.
VISTA GENERAL DEL PROYECTO
2.1. Objetivo general..............................................................................................................................2

2.2. Objetivos especficos......................................................................................................................2
2.3. Alcance............................................................................................................................................2
2.3.1. Requerimientos funcionales.....................................................................................................2
2.3.2. Requerimientos no funcionales................................................................................................3
2.3.3. Suposiciones y restricciones....................................................................................................4
2.4. Fundamentacin de la metodologa................................................................................................4
2.4.1. Modelo de proceso...................................................................................................................4
2.4.2. Entregables...............................................................................................................................5
2.4.3. Hitos principales......................................................................................................................6
2.4.4. Proceso de desarrollo...............................................................................................................6
3.
ORGANIZACIN DEL PROYECTO
3.1. Organizacin interna.......................................................................................................................7

3.2. Roles y responsabilidades...............................................................................................................8
4.
PROCESO TCNICO 9
4.1.
Mtodos, herramientas y tcnicas...............................................................................................9
4.2.
Documentacin del producto....................................................................................................10
5.
ANLISIS DE REQUERIMIENTOS
11
5.1. Dominio de la aplicacin..............................................................................................................11

5.2. Identificacin de actores y casos de uso.......................................................................................12
5.2.1. Actores...................................................................................................................................12
5.2.2. Casos de uso...........................................................................................................................12
5.3. Sub-sistemas identificados............................................................................................................15
5.3.1. Arquitectura de despliegue.....................................................................................................16
5.3.2. Tipo de aplicacin..................................................................................................................16
i
TERA
SOFT
Cdigo: TS-DPD-01
Revisin: 4
Versin: 04
SOFTWARE
5.3.3. Tipo de conexin....................................................................................................................16
6.
6.1.
ESTIMACIN DE RECURSOS
18
Mtricas.....................................................................................................................................18
6.1.1.
Orientadas al tamao (MOT).............................................................................................18
6.1.2.
Orientadas a la funcin (MOF)..........................................................................................19
OpenBravo...................................................................................................................................19
OpenERP......................................................................................................................................20
ERP5............................................................................................................................................20
6.2.
Estimaciones..............................................................................................................................21
6.2.1.
Modelos empricos.............................................................................................................22
6.2.2.
Modelo COCOMO.............................................................................................................22
6.2.3.
Anlisis de las estimaciones...............................................................................................22
7.
ANLISIS Y MANEJO DE RIESGOS
23
7.1.
Valoracin..................................................................................................................................23
7.2.
Plan de aversin........................................................................................................................23
8.
GESTIN DEL PROCESO 27
8.1. Recursos........................................................................................................................................28
8.1.1. Recursos humanos.................................................................................................................28
8.1.2. Recursos fsicos.....................................................................................................................29
8.2. Estimaciones del proyecto............................................................................................................29
8.2.1. Anlisis de costos...................................................................................................................29
8.2.2. Costos del riesgo....................................................................................................................31
9.
REFERENCIAS 32
10. ANEXOS 32
10.1. Anexo A: Especificaciones de hardware.....................................................................................32

10.2. Anexo B: Especificaciones de software......................................................................................33
ii
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-01
Revisin: 4
Versin: 04
INDICE DE TABLAS
Tabla 1: Roles 8
Tabla 2: Casos de uso 13
Tabla 3: Aplicaciones open-source a comparar
Tabla 4: MOT histrico
18
19
Tabla 5: MOF aplicadas a OpenBravo
19
Tabla 6: MOF aplicadas a OpenERP 20

Tabla 7: MOF aplicadas a ERP5
20
Tabla 8: MOF aplicadas a la aplicacin a desarrollar

Tabla 9: Estimaciones por KLDC
21
21
Tabla 10: COCOMO bsico 22

Tabla 11: Plan de aversin
26
Tabla 12: Recursos humanos 28

Tabla 13: Recursos fsicos
29
Tabla 14: Costo de personal 30

Tabla 15: Costo de recursos 30
Tabla 16: Costo de recursos 30
Tabla 17: Costo con previsin de riesgos
31
Tabla 18: Especificaciones de hardware
32
Tabla 19: Especificaciones de software
33
iii
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-01
Revisin: 4
Versin: 04
INDICE DE FIGURAS
Figura 1: Proceso de desarrollo
Figura 2: Organigrama interno
Figura 3: Modelo de dominio11

Figura 4: Modelo de casos de uso
14
Figura5: Sub-sistemas identificados 15

Figura6: Arquitectura de despliegue 16
Figura 7: Topologa de red VPN
17
Figura 8: Planificacin temporal
27
iv
TERA
SOFT
SOFTWARE
1.
INTRODUCCIN
1.1.
Antecedentes
Cdigo: TS-DPD-01
Revisin: 4
Versin: 04
La empresa Farmacorp tiene desplegadas a lo largo del territorio local una cadena de farmacias que funcionan en
forma continua durante todos los das de la semana, incluyendo aquellas que se encuentran de turno. Adicionalmente
la empresa se est enfocando en la captura y atencin de clientes a travs de ofertas, bonificaciones y concursos que se
realizan peridicamente o durante fechas festivas.
1.2.
Definicin del problema
Debido a su crecimiento dado durante los ltimos aos, el tamao de sus operaciones ha sobrepasado su capacidad e
instalaciones esperadas reduciendo su eficiencia y capacidad de administracin.
Estas operaciones incluyen la administracin de los productos que ofrecen, la administracin de sus clientes, de sus
proveedores de productos y de su personal. El control de todos estos factores implica un gran esfuerzo para los
administradores en cada sucursal y an ms para los administradores regionales.
Adicionalmente a esto, la cadena de farmacias ofrece catlogos de ofertas de productos y un sistema de bonificacin a
los clientes, los cuales tienen que ser registrados.
1.3.
Situacin problemtica
La falta de facilidades de administracin, registr e integracin de todas las sucursales de la cadena de farmacias, de
sus proveedores y clientes, que permitan a la cadena crecer sin impactar negativamente en su capacidad de control.
TERA
SOFT
2.
SOFTWARE
Cdigo: TS-DPD-01
Revisin: 4
Versin: 04
VISTA GENERAL DEL PROYECTO
2.1. Objetivo general

Desarrollo de un sistema de gestin interconectado que permita integrar todas las sucursales y almacenes de productos
con la oficina central ofreciendo facilidades de administracin de clientes y personal.
2.2. Objetivos especficos

Investigar sobre productos de software con objetivos similares para que puedan ser usados en el clculo de
las estimaciones.
Identificar los problemas de gestin, control y administracin.
Registrar todas las actividades, eventos e hitos de desarrollo en registros y/o bitcoras.
Definir el alcance, requerimientos y restricciones del sistema a desarrollar.
Realizar un breve anlisis de los datos obtenidos a travs de un anlisis de requerimientos.
Definir el plan de gestin de configuracin de software que definir el cmo los tems de proyecto deben ser
manejados.
Desarrollar el sistema bajo criterios convenidos con el cliente, documentando cada fase del proyecto y sus
artefactos resultantes.
Realizar presentaciones peridicas e incrementales del sistema a los clientes, para su aprobacin y/o
correccin contina.
Desplegar el sistema en la configuracin definida por este plan.
2.3. Alcance
2.3.1. Requerimientos funcionales
1. El sistema deber llevar un registro de todos los productos que ingresan a los almacenes y son distribuidos a
las sucursales.
2. El sistema deber llevar un registro detallado de compras realizadas a los proveedores, de los pagos
realizados y los pagos futuros a realizar por tales compras.
3. El sistema deber llevar un registro de ventas de productos a los clientes.
4. El sistema deber llevar un registro de los clientes usando el nmero de carnet de identidad como
vi
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-01
Revisin: 4
Versin: 04
identificador primario.
5. El sistema deber llevar un registro de puntos acumulados por las compras de los clientes, adems de llevar
un registro de los puntos usados (canjeados) por el mismo.
6. El sistema deber llevar un registro de los catlogos de oferta.
7. El sistema deber emitir facturas por la venta de productos a los clientes acorde a las leyes y restricciones
establecidas por la oficina de impuestos nacionales.
8. El sistema deber llevar un registro del personal trabajando en las sucursales, oficina central y almacenes.
Permitiendo realizar la gestin de personal, asignaciones de turno, permisos, vacaciones, etc.
9. El sistema deber gestionar la planilla del personal, tomando en cuenta beneficios por turnos especiales, das
festivos, feriados y otros. As tambin como descuentos correspondientes.
10. El sistema deber emitir reportes para:
a.
Reporte de ingreso diario de productos por sucursal y almacenes por proveedor y total en cantidad e
importe.
b. Reporte de proveedores considerando volmenes de compras, de forma mensual y a requerimiento.

c.
Reporte diario de productos vendidos, por turno y el total en cantidad e importe por sucursal y
consolidado.
d. Reporte de productos solicitados a proveedores.

e.
Reporte de volumen de ventas diarias, mensuales y a requerimiento por turno y total por sucursal y
consolidado.
f.
Reporte de clientes, sus puntos acumulados y puntos usados (canjeados).
g. Reporte del catlogo de ofertas.

11. El sistema deber proveer funciones para los usuarios basndose en privilegios de uso, los cuales estn
definidos por sus roles: vendedores, regentes, almaceneros, gerentes.
2.3.2. Requerimientos no funcionales

1. El sistema deber tener un alto grado de disponibilidad, para cubrir con los horarios de atencin: 24 horas en
turnos los siete das de la semana (tres turnos, 7 a 15, 15 a 23, y 23 a 7 a travs de ventanilla).
2. El sistema deber contar con restricciones de seguridad que evite el acceso de personas no autorizadas al
mismo, ya que al ser un sistema interconectado puede ser accedido desde cualquier punto sucursal.
3. El sistema deber mantener un alto grado de consistencia en el manejo de productos en almacn, para que los
pedidos y distribucin se hagan de forma correcta.
4. El sistema deber soportar la cantidad esperada de acciones concurrentes, ya que se trabajar con varias
vii
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-01
Revisin: 4
Versin: 04
sucursales de manera simultnea.

5. El sistema deber emitir facturas en concordancia con las reglamentaciones tributarias nacionales.
6. El sistema deber ser accesible para los equipos actualmente disponibles, esto incluye los ordenadores ya
existentes que no son obsoletos.
2.3.3. Suposiciones y restricciones

1. El sistema deber ser desarrollado sobre tecnologa probada con referentes previos de estabilidad, el uso de
cualquier herramienta o tecnologa experimental deber ser obviado.
2. El sistema en desarrollo est orientado a propsitos especficos definidos por el cliente, por tanto la
implementacin no requiere ser compatible con mltiples plataformas o interfaces.
3. El sistema debe desarrollarse en un periodo de tiempo no mayor a 3 aos.
4. Los diferentes componentes de hardware requeridos para el despliegue del sistema deben ser provedos por la
empresa, y pagados posteriormente por los clientes.
2.4. Fundamentacin de la metodologa

Describe la seleccin de la metodologa de desarrollo y sus justificaciones.
2.4.1. Modelo de proceso

Debido a que el sistema es de tamao mediano, y se tienen las siguientes necesidades:
1. Entregas incrementales de las diferentes funcionalidades
2. Demostraciones peridicas
3. Sistema funcional por mdulos
4. Tiempos cortos de entrega
El proceso de desarrollo seleccionado es el de Extreme Programming, con todos sus artefactos, roles, prcticas,
procesos e iteraciones.
Valores de trabajo
1. Retroalimentacin: Test driven development, juego de planificacin, equipo completo, Programacin en
pares.
2. Proceso continuo: Integracin continua, diseo incremental, entregas pequeas.
viii
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-01
Revisin: 4
Versin: 04
3. Conocimiento compartido: Diseo simple, apropiado para la audiencia esperada, comunicativo, limpio,
mnimo, metfora del sistema, propiedad colectiva del cdigo, convenciones de codificacin.
4. Bienestar: Ritmo sostenible.
2.4.2. Entregables
Los elementos entregables del proyecto incluyen los artefactos de uso interno como los de conocimiento del cliente,
tales artefactos son:
Internos
Tarjetas CRC, tarjetas describiendo el comportamiento y estructura de las diferentes clases.
Especificacin tcnica, documento conteniendo la documentacin tcnica del producto, su arquitectura,
interfaces, componentes y su distribucin.
Tarjeta de tareas, conjunto de unidades de trabajo desglosadas a partir de una historia de usuario.
Externos
Productbacklog, un listado completo de todas las historias de usuario o funcionalidades requeridas en el
software.
Historias de usuario, elaboradas en conjunto entre el equipo de desarrollo y los clientes, listando sus criterios
de aceptacin, prioridad, y estimacin.
Pizarra de tarjeta de historia, pizarras donde se organizan las diferentes historias de usuario ordenadas por
iteracin y entregas.
Calendario de entregas, calendario con fechas de entrega de las diferentes versiones del producto.
Pruebas de aceptacin, complementan a la documentacin y requerimientos al proveer un conjunto de reglas
de verificacin de los diferentes componentes del sistema.
2.4.3. Hitos principales

Se definen los siguientes hitos principales:
Releaseplanning: En esta reunin o reuniones se definen las funcionalidades a implementar para el producto.
Definicin de la arquitectura: Al finalizar este hito, se debe tener un bosquejo de arquitectura de alto nivel,
tal arquitectura ser utilizada y modificada durante el desarrollo.
Release candidatos: Estos releases se hacen cada cierto tiempo y se presentan como paquetes entregables al
ix
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-01
Revisin: 4
Versin: 04
usuario, generalmente engloban todas las funcionalidades de un mdulo.
2.4.4. Proceso de desarrollo
El proceso de desarrollo puede resumirse en el siguiente proceso:
Figura 1: Proceso de desarrollo

El proceso es exactamente el mismo definido por XP, pero con una personalizacin hacia las necesidades del cliente,
que adems de entregas pequeas exige la elaboracin de entregas candidato, que podrn ser aprobadas o no por los
clientes.
TERA
SOFT
3.
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
ORGANIZACIN DEL PROYECTO
En esta seccin se describe el modelo de proceso, la estructura organizacional y responsabilidades individuales en el

proyecto.
3.1. Organizacin interna

Debido al tamao y complejidad de la aplicacin, el desarrollo del proyecto se estructurar de forma descentralizada
controlada (DC), donde los encargados de cada grupo estarn a cargo de un equipo y deben rendir informes al lder
de desarrollo y/o proyecto.
Equipos de trabajo:
1. Administracin
1.1. Lder de proyecto/tracker/coach
1.2. Personal administrativo/manager
2. Equipo de desarrollo/team
2.1. Equipo de desarrollo principal/team/developer
2.2. Diseadores/team
2.3. Representante del cliente/customer
3. Administracin de sistemas y redes/team
4. Tester
Figura 2: Organigrama interno
11
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
3.2. Roles y responsabilidades

ROL
RESPONSABILIDAD
Gerente/manager
Jefe mximo de la organizacin, es la persona a cargo de todos los proyectos.
Lder de
proyecto/tracker
Profesional en la administracin de proyectos. Tiene la responsabilidad de planificar,

ejecutar y concluir un proyecto. Es la persona responsable del alcance de los objetivos.
Lder de
desarrollo/coach
Responsable de definir la arquitectura de la aplicacin (en colaboracin con el

arquitecto de software), as como de velar por el trabajo realizado por los
desarrolladores.
Especialista en
redes/team
Encargado de disear y desplegar las redes fsicas de comunicacin para la aplicacin.

Es adems un especialista en hardware de redes y comunicaciones.
Arquitecto de
software/team
Responsable de definir la arquitectura de la aplicacin, sus componentes y la interaccin

entre ellos. Tambin es encargado de modelar todas estas definiciones.
Diseador/team
Responsable de la conceptualizacin, diseo y aplicacin de las interfaces de usuario de

la aplicacin.
Desarrolladores/team
Personal encargado del desarrollo de la aplicacin, incluyendo la documentacin y

prueba de todos los componentes desarrollados.
Representante del
cliente/customer
Representante del cliente dentro del equipo, esta persona o personas estn encargados de
velar por las necesidades de los clientes frente al equipo. Es el punto de concentracin
de todas las preguntas y dudas.
Tester
Equipo de verificacin de calidad, encargados de probar y verificar todas las

funcionalidades de la aplicacin/sistema.
Tabla 1: Roles
12
TERA
SOFT
4.
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
PROCESO TCNICO
Esta seccin describe los procesos tcnicos de alto nivel usados en el proyecto incluyendo los mtodos tcnicos,
herramientas, documentos principales y actividades de soporte tales como la administracin de configuracin y el
aseguramiento de la calidad.
4.1.
Mtodos, herramientas y tcnicas
Los principales componentes de software estn listados en el Anexo B, pero para el proceso de desarrollo se definen
las siguientes prcticas y herramientas:
1. Desarrollo
Test DrivenDevelopment
Tcnica FIT para pruebas de aceptacin.
Pruebas de interfaces de usuario con Selenium.
2. Estimaciones
Estimaciones Gut-feeling para tareas repetitivas o conocidas.
Estimaciones con clculo de velocidad para tareas desconocidas o largas.
3. Retrospectiva
Los elementos de retrospectiva deben colocarse en un lugar de conocimiento pblico, en una pared o
muro de notificaciones.
Se debe elegir y corregir al menos un elemento de retrospectiva por iteracin.
4. Entrega
Las entregas se hacen de forma automatizada de ser posible, de forma que el cliente tenga una entrega
rpida para realizar sus pruebas.
Las entregas se versionarn de acuerdo a los hitos y entregas siguiendo la numeracin estndar
VERSION_ENTREGA_BUILD (e.g. App-1.0.2).
5. Iteraciones
Duracin establecida de una semana.
13
TERA
SOFT
5.
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
ANLISIS DE REQUERIMIENTOS
Una vez definido el mbito del proyecto, se deben elaborar conclusiones que definirn las secciones siguientes, tales
conclusiones deben marcar el rumbo a seguir para realizar el clculo de recursos, la complejidad del sistema, y su
tamao.
5.1. Dominio de la aplicacin
Figura 3: Modelo de dominio
14
TERA
SOFT
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
SOFTWARE
5.2. Identificacin de actores y casos de uso

5.2.1. Actores
1. Gerente: Principal administrador a cargo de administrar las labores, empleados y productos en todas las
sucursales.
2. Regente: Encargado de administrar labores, horarios y turnos, es tambin el encargado de definir la cantidad
de productos a requerir de almacn y los puntos de reposicin de los mismos.
3. Almacenero: Empleado de almacn, encargado de recibir peticiones de productos y de su despacho, tambin
es la persona a cargo del recargo de los productos comprados a los diferentes proveedores.
4. Vendedor: Encargado de la atencin del cliente y el registro/ejecucin de ventas.
5.2.2. Casos de uso

Los siguientes casos de uso son una aproximacin inicial que debe ser refinada en la fase de captura de requisitos.
ID
NOMBRE
PRIORIDAD
Registrar producto
Alta
Modificar producto
Media
Eliminar producto
Baja
Registrar venta
Alta
Emitir factura
Alta
Registrar cliente
Alta
Modificar cliente
Media
Eliminar cliente
Baja
Crear catlogo
Media
10
Modificar catlogo
Media
11
Eliminar catlogo
Baja
12
Registrar empleado/usuario
Alta
13
Modificar empleado/usuario
Alta
14
Eliminar empleado/usuario
Media
15
Registrar sucursal
Alta
16
Modificar sucursal
Alta
15
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
17
Eliminar sucursal
Media
18
Ingresar al sistema
Alta
19
Crear turno
Alta
20
Modificar turno
Media
21
Eliminar turno
Baja
22
Asignar turno
Alta
23
Generar reportes
Alta
24
Registrar compra
Alta
25
Registrar pago-compra
Alta
26
Registrar proveedor
Alta
27
Modificar proveedor
Media
28
Eliminar proveedor
Baja
Tabla 2: Casos de uso
16
Figura 4: Modelo de casos de uso
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
Nota: El actor Usuario es usado como referencia, no existe un actor especfico para ese rol.
5.3. Sub-sistemas identificados

A partir de los requerimientos previamente identificados, se puede identificar un conjunto de mdulos del sistema que
pueden ser usados para definir el producto final.
Figura 5: Sub-sistemas identificados
17
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
1. Gestin de sucursales, permite gestionar todas las sucursales de la cadena.

2. Gestin de productos, permite gestionar los productos de almacn y catlogos resultantes.
3. Gestin de clientes, permite gestionar a los clientes, sus puntajes y datos personales.
4. Gestin de personal, permite gestionar al personal de la entidad, incluyendo la administracin de turnos y
horarios.
5. Gestin de compras y pedidos, permite gestionar todas las compras y pedidos a realizar a los proveedores,
incluye las funcionalidades de gestin de proveedores.
6. Gestin de ventas, permite gestionar todos los aspectos relativos a ventas, facturas y recibos.
7. Reportes, permite generar reportes de todas las acciones registradas. Estos reportes solamente deberan ser
visibles para los cargos administrativos.
5.3.1. Arquitectura de despliegue

Debido a que la organizacin es del tipo cerrado, donde las sucursales, almacenes y oficinas deben estar actualizados
y en uso de la misma informacin. La arquitectura del sistema ser del tipo cliente-servidor, la cual provee una base
central de datos y centraliza el acceso de los usuarios al sistema, estas caractersticas permiten cumplir a cabalidad los
Figura 6: Arquitectura de despliegue
18
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
requerimientos funcionales de consistencia de datos.
5.3.2. Tipo de aplicacin

Dados los requerimientos de compatibilidad con los recursos actuales, el tipo de aplicacin ms conveniente es de una
aplicacin web. Ya que los requerimientos para los nodos usuario se limitan a disponer de un navegador web.
5.3.3. Tipo de conexin

Debido a que el tipo de aplicacin definido es web, su acceso debe limitarse a la cadena de sucursales, almacenes y su
oficina central. La conexin de red debe ser suficientemente robusta para evitar ataques externos, ya que datos crticos
pueden verse afectados.
Existen dos opciones para el tipo de conexin: el sistema publicado en web armado con todas medidas de seguridad
posibles, y el sistema publicado en una red privada (VPN 1) donde cada nodo se conecta de forma segura. El tipo de
conexin aconsejado es del tipo privado (VPN), ya que el desarrollo de las medidas de seguridad necesarias
incrementara de forma significativa el costo del proyecto.
1
Virtual Private Network
Figura 7: Topologa de red VPN
19
TERA
SOFT
SOFTWARE
20
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
TERA
SOFT
6.
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
SOFTWARE
ESTIMACIN DE RECURSOS
6.1.
Mtricas
Las mtricas a usar para la estimacin de recursos se basarn en dos enfoques diferentes para tener una visin mas
certera del tamao y complejidad del sistema, la mtricas basadas en tamao y las mtricas basadas en funcin.
Debido al mercado laboral actual, a la arquitectura y tipo de aplicacin (adems de las restricciones definidas), las
mtricas deben estar en el dominio de las tecnologas Java, .Net, Python y PHP 2.
6.1.1. Orientadas al tamao (MOT3)

Como este tipo de mtricas se basan en datos histricos, se utilizarn los siguientes productos de software como base
de estimacin.
Estos proyectos fueron seleccionados en base a las funcionalidades que proveen, ya que son sistemas ERP y CRM que
se aproximan al sistema base que se intenta desarrollar. Adems al ser proyectos de cdigo abierto permiten usar su
cdigo como base de mtricas.
PRODUCTO
DESCRIPCIN
KLDC
KLDC
(ARREGLADO)
OpenBravo
Sistema web ERP+CRM orientado para empresas 244

Medianas y grandes, desarrollado sobre Java.
244
OpenERP

pequeas y medianas, desarrollado sobre Python.
220
ERP5

medianas y grandes, desarrollado sobre Python.
372
Tabla 3: Aplicaciones open-source a comparar
Debido a que ambas aplicaciones estn desarrolladas en lenguajes diferentes, el KLDC 4 arreglado se rige bajo la
siguiente proporcin (Schmidt, 2008):
http://blog.sudobits.com/2011/04/14/the-most-popular-programming-languages/
MOT Mtricas orientadas al tamao
Kilo lnea de cdigo
21
TERA
SOFT
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
SOFTWARE
Dados los datos anteriores, y usando la ecuacin del software para calcular el tamao esperado de la aplicacin,
tenemos:
Nota: El clculo del precio del producto se hizo en base al precio por KLDC (Spolsky, 2007).
PROYECTO
OpenBravo
OpenERP
ERP5
Valor esperado
KLDC
ESFUERZO
(P/M)
30
20
80
36
244
220
372
261
COSTO
($US)
292800
264000
446400
274000
TIEMPO
(MESES)
48
40
60
48
ERRORES
DEFECTOS
220
100
300
213
80
75
250
107
Tabla 4: MOT histrico
6.1.2. Orientadas a la funcin (MOF5)

Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las
mtricas orientadas a la funcin se centran en la funcionalidad o utilidad del programa.
Las mtricas orientadas a la funcin fueron el principio propuestas por Albercht quien sugiri un acercamiento a
la medida de la productividad denominado mtodo del punto de funcin. Los puntos de funcin que obtienen
utilizando una funcin emprica basando en medidas cuantitativas del dominio de informacin del software y
valoraciones subjetivos de la complejidad del software.
OpenBravo
PARMETROS CUENTA FACTORES DE PESO6
TOTAL
SIMPLE MEDIO COMPLEJO

Entradas
50
150
Salidas
100
700
Peticiones
20
60
Archivos
150
10
15
1050
10
150
Interfaces externas 30
Cuenta total
2110
Tabla 5: MOF aplicadas a OpenBravo

5
MOF Mtricas orientadas a la funcin
Factores obtenidos de Pressman, 2001
22
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
OpenERP
PARMETROS
CUENTA FACTORES DE PESO

SIMPLE MEDIO
COMPLEJO
TOTAL
Entradas
30
90
Salidas
80
400
Peticiones
20
80
Archivos
100
10
15
700
Interfaces externas
20
10
140
Cuenta total
1410
Tabla 6: MOF aplicadas a OpenERP
ERP5
PARMETROS

SIMPLE MEDIO
COMPLEJO
TOTAL
Entradas
50
200
Salidas
180
900
Peticiones
100
600
Archivos
500
10
15
5000
Interfaces externas
50
10
140
Cuenta total
6840
Tabla 7: MOF aplicadas a ERP5
En base a las mtricas anteriores, podemos aplicar las mtricas orientadas a funciones para la aplicacin a desarrollar
usando la frmula del software para calcular el valor probable.
23
TERA
SOFT
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
SOFTWARE
PARMETROS
TOTAL
SIMPLE MEDIO
COMPLEJO
Entradas
40
120
Salidas
50
250
Peticiones
30
180
Archivos
150
10
15
1500
Interfaces externas
25
10
175
Cuenta total
1775
Tabla 8: MOF aplicadas a la aplicacin a desarrollar
Clculo de puntos funcin para la aplicacin:
6.2.
Estimaciones
A partir de las mtricas anteriores hemos deducido los siguientes datos:

Tamao esperado en KLDC:
METODO
KLDC
TAMAO ESPERADO
MINIMO
MOT
261
MOF
188
188
MAXIMO
261
249
Tabla 9: Estimaciones por KLDC
ESPERADO
24
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
6.2.1. Modelos empricos

Esfuerzo calculado en base a MOT:
7
Esfuerzo calculado en base a MOF:

8
6.2.2. Modelo COCOMO

A continuacin se aplicar el modelo de estimacin COCOMO (Pressman, 2001).
Proyecto de software
Orgnico
2,4
1,05
2,5
0,38
Semi-acoplado
3,0
1,12
2,5
0,35
Empotrado
3,6
1,20
2,5
0,32
Tabla 10: COCOMO bsico

Esfuerzo:
Duracin:
6.2.3. Anlisis de las estimaciones

Una vez estimados los valores probables del proyecto: tamao, esfuerzo necesario y duracin. Adems de los datos
empricos, se debe sacar una conclusin usando el criterio personal y la experiencia. En este caso se tomaran los
valores ms altos, ya que su variacin con respecto al valor mnimo no es exuberante.
Estimaciones resultantes
7
Modelo de Walston-Felix
Modelo de Albretch-Gaffney
25
TERA
SOFT
7.
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
SOFTWARE
ANLISIS Y MANEJO DE RIESGOS
Dado el caso de estudio previamente descrito, el plan de gestin de riesgos a desarrollar envuelve las siguientes tareas:
Identificacin, priorizacin, anlisis, previsin y mitigacin.
Las tareas de previsin comprenden todas aquellas medidas que se tomen para evitar que los riesgos definidos
ocurran. Las tareas de mitigacin estn orientadas a reducir el impacto de los riesgos una vez presentes 9.
7.1.
Valoracin
La valoracin de los riesgos se basar en dos parmetros, probabilidad e impacto o severidad de acuerdo a la siguiente
ponderacin.
Probabilidad:
Alta
Alta probabilidad de ocurrencia
50%
Media
Probabilidad de ocurrencia moderada
50%
Baja
Baja probabilidad de ocurrencia
50%
Impacto/Severidad:
Alto
El riesgo no gestionado podra resultar en el fracaso del proyecto.
Medio
El riesgo podra tener un gran impacto en la planificacin, costo o rendimiento del

proyecto.
Bajo
El riesgo tendra un impacto menor en el proyecto.
El documento de gestin de riesgos est basado en el documento detallado en (NASA, 2002)
26
TERA
SOFT
7.2.
SOFTWARE
Plan de aversin
El plan de aversin muestra los riesgos, su impacto y sus tareas preventivas y reactivas.
27
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
TERA
SOFT
ID
NOMBRE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
SOFTWARE
DESCRIPCIN
PROBABILIDAD
IMPACTO
PREVENCIN
REACCIN
Correctitud del proyecto La aplicacin puede no cumplir Bajo

las expectativas
Alto
* Realizar entregas peridicas e

* Revisar la especificacin
incrementales para la aprobacin del de requerimientos.
cliente.
* Exigir la aprobacin del cliente por
entrega realizada.
Estabilidad del equipo

del proyecto
El equipo del proyecto puede

ser modificado durante el
desarrollo del mismo.
Alto
* Brindar condiciones salariales

atractivas.
* Reforzar las clusulas de
despido/renuncia en los contratos.
* Documentar religiosamente los
artefactos y componentes resultantes
del desarrollo.
* Reducir la dependencia en
base a empleados en
particular.
* Distribuir tareas de forma
genrica para compartir el
conocimiento.
Seguimiento de los
procesos del proyecto
El proceso de desarrollo
Bajo
seleccionado puede o no ser
seguido al pie de la letra por el
equipo.
Medio
* Monitorear el proceso de desarrollo

y su progreso.
* Definir convenciones de desarrollo
desde el inicio.
* Llamar la atencin sobre

las faltas e informar
constantemente de los pasos
del proceso.
Objetivos de
rendimiento
La aplicacin puede no cumplir Bajo

las expectativas de rendimiento
inicialmente definidas.
Bajo
* Incluir pruebas de rendimiento,

junto a las pruebas unitarias.
* Priorizar la
implementacin de las
pruebas de rendimiento.
Aprobacin de clientes Los clientes puede desaprobar Medio

la aplicacin o partes de ella
durante y despus del
desarrollo del producto.
Alto
* Incluir revisiones peridicas con el * Detener el desarrollo en

cliente.
espera de la aprobacin o
rechazo de los clientes.
Correctitud del
presupuesto
El presupuesto planificado
Medio
puede ser equivocado o no ser
suficiente.
Alto
* Definir un margen de seguridad para * Re-estructurar el alcance

el presupuesto.
de las entregras para reducir
el presupuesto.
Tamao del proyecto
Las estimaciones de tamao de Medio

la aplicacin pueden ser
errneas.
Medio
* Usar el valor estimado mayor por

seguridad.
Bajo
* Refactorizar y eliminar
componentes/artefactos no
necesarios.
Pgina 28
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
Insolencia de tecnologa La tecnologa usada puede

Bajo
quedar obsoleta al poco tiempo
de entregar la aplicacin.
Bajo
* Utilizar tecnologa probada y usada

en el mercado.
Correctitud de la
La planificacin temporal
planificacin temporal puede tener retrasos.
Medio
* Revisar y actualizar la planificacin * Re-estructurar la

temporal durante el desarrollo.
planificacin temporal tan
* Definir un margen de seguridad para pronto como un retraso es
las tareas, agregndole un tiempo
identificado.
extra.
10 Velocidad de desarrollo El equipo de desarrollo puede Bajo

estable
tener una productividad no
consistente.
Bajo
* Mantener el equipo motivado con

diferentes medidas: intercambiar
tareas, realizar demostraciones de
avance, etc.
11 Correctitud de
requerimientos
Los requerimientos definidos Medio

pueden no ser correctos o estar
completamente errados.
Alto
* Definir los requerimientos de forma * Revisar la especificacin

simple y entendible, el trabajo de sub- de requerimientos con el
dividirlo en tareas es trabajo del
cliente.
equipo.
12 Testeabilidad de la
aplicacin
La aplicacin puede tener unas Bajo

deficiencias de diseo que
limitan la posibilidad de probar
sus componentes.
Bajo
* Aplicar pruebas unitarias y

refactorizacin como convencin de
desarrollo.
* Automatizar las revisiones de
cdigo, que indiquen errores de
diseo o falta de pruebas.
13 Estabilidad de la
documentacin
Durante el desarrollo de la
Bajo
aplicacin la documentacin
puede ser inconsistente con los
artefactos desarrollados.
Bajo
* Incluir a la documentacin como

parte integral del proceso de
desarrollo.
* Monitorear la documentacin y su
consistencia regularmente.
Medio
* Tratar todos los temas durante las * Identificar los puntos

reuniones peridicas de revisin, con dbiles de comunicacin,
el cliente o un representante presente. proveer esta informacin en
14 Comunicacin cruzada La comunicacin entre el

equipo, lderes y el cliente
puede no ser suficiente.
Medio
Medio
* Identificar las causas del

problema e intentar
resolverlas.
* Refactorizar los
componentes problemticos
y escribir pruebas unitarias
para verificar su correctitud.
Pgina 29
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
las reuniones peridicas.
15 Gestin de
configuracin de
software
La ubicacin de los
Bajo
documentos, el rea de
desarrollo y ambientes pueden
ser desconocidos para el equipo
y el cliente.
Bajo
* Todos los tpicos referentes a la

gestin de configuracin del software
deben estar especificados en el
documento de Gestin de
Configuracin (SCM)
16 Licencias y permisos
legales
Las licencias, propiedad

Bajo
intelectual y aspectos legales
pueden no estar especificados.
Bajo
* El contrato de desarrollo debe

especificar todas las clusulas legales
del proyecto.
17 Complejidad de
implementacin
El grado de complejidad de la Bajo

aplicacin puede causar
problemas en etapas
posteriores de mantenimiento.
Bajo
* Revisar la correctitud del diseo.

* Monitorear el grado de complejidad
algortmica con herramientas
automticas.
18 Correctitud de recursos Los recursos fsicos estimados Bajo

fsicos estimados
pueden no ser suficientes.
Bajo
* Especificar los recursos con un alto

grado de previsin, estimando
recursos fsicos que puedan
fcilmente satisfacer las necesidades.
19 Seguridad de datos
Alto
* Definir medidas de seguridad de

datos con respaldos incrementales y
medidas de seguridad altas para el
acceso a los servidores de datos.
Los datos pueden ser

Bajo
susceptibles a dao,
manipulacin o corrupcin por
factores externos.
Tabla 11: Plan de aversin
Pgina 30
TERA
SOFT
8.
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
GESTIN DEL PROCESO
En este captulo se identifican las diferentes actividades a realizar durante la realizacin del proyecto, tales actividades
se realizaran en un orden establecido con un intervalo de tiempo asignado. Las actividades especificadas deben estar
enmarcadas y fundamentadas bajo algn criterio de desarrollo, en este caso se usar un proceso del tipo Extreme
programming.
La figura a continuacin engloba el plan de fases y el calendario con las fechas de entrega.
Figura 8: Planificacin temporal
PLAN DE DESARROLLO PARA EL SISTEMA FARMACORP Pgina 31
TERA
SOFT
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
SOFTWARE
8.1. Recursos
Los recursos se calcularn en base a las estimaciones previas, dado que las estimaciones especifican variables
especficas se usarn variables indirectas para obtener los dems valores. Para la distribucin de personal se utilizar
el criterio de distribucin de trabajo multi-tarea por pesona (Braude, 2000).
8.1.1. Recursos humanos

NOMBRE
Gerencia y administracin
DESCRIPCIN
CANTIDAD
Personal encargado de velar por el progreso constante del

proyecto.
Gestor/lder de proyecto
Encargado del proyecto en la parte contratista. Gestiona,
coordina, planifica y resuelve problemas dentro del equipo.

Secretaria
Encargada de facilitar tareas administrativas y asuntos
varios.
Desarrollo
Desarrolladores senior
Encargados del proceso de desarrollo y lderes de equipo,

cumplen
mltiples
funciones
dentro
del
proyecto:
arquitectos, expertos en pruebas, gestores de calidad.

Desarrolladores (medios, junior) Encargados del desarrollo de la aplicacin, coordinados por
14
los lderes de equipo.

Diseadores
Encargados del diseo de interfaces de usuario para la
aplicacin.
Sistemas y redes
Expertos en redes y telecomunicaciones, encargados de la
instalacin, configuracin y mantenimiento de todo equipo

de hardware.
Total
25
Tabla 12: Recursos humanos
8.1.2. Recursos fsicos

Los recursos fsicos calculados se basan en las especificaciones y rendimiento de sistemas trabajando sobre la
plataforma Java Virtual Machine, la cual nos da un rendimiento promedio de 250 usuarios por servidor (Specs, 2008).
Debido a que la mayora de las instalaciones y recursos van a ser reutilizados, los recursos necesarios se reducen a su
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
mnimo posible.
RECURSO
DESCRIPCIN
CANTIDAD
Ordenadores personales
Utilizados para el desarrollo, cada 25

miembro del equipo debe contar con un
ordenador personal (sin costo, ya
provedos por el contratista).
Impresora y fax
Utilizado para la recepcin, impresin y 1

envo de documentos (sin costo, ya
provedos por el contratista)..
Servidores
Utilizados para contener los servicios a 3 servidores de produccin (por cada

usar durante el desarrollo, tambin para 250 usuarios)
los ambientes de prueba, integracin y 1 servidor para servicios de
produccin.
desarrollo y pruebas
Routers y concentradores VPN Usados en los ambientes de integracin y 410

produccin, para concentrar datos y
mantener la VPN activa
Tabla 13: Recursos fsicos
8.2. Estimaciones del proyecto

El costo total del proyecto requiere un sumario de todos los factores previamente listados: estimaciones, mtricas,
clculo de recursos. A continuacin se especifica el costo esperado del proyecto en base a todos los factores
mencionados.
8.2.1. Anlisis de costos

Primero se debe tabular el costo del personal en sueldos, tomando en cuenta la base media nacional y el promedio de
sueldos provedos por el INE (INE, 2010). Adems se debe tomar en cuenta que no todo el equipo trabaja durante el
tiempo de vida del proyecto, algunos miembros trabajan durante ciertas fases.
Cargo
Factor
Sueldo
($us)
Monto mensual
($us)
Tiempo empleado
(meses)
Monto total
Secretaria
250
250
30
7500
Gestor de proyecto
2000
2000
30
60000
Desarrollador senior
1200
4800
24
115200
14
500
7000
18
126000
Desarrollador
10
Basado en la especificacin CISCO http://www.cisco.com/en/US/products/ps5743/Products_Sub_Category_Home.html
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
Diseador
700
1400
11200
Experto en redes
1300
3900
23400
Total por mes
19350
Total
343300
Tabla 14: Costo de personal

El segundo factor importante son los recursos, en este caso se deben usar servidores y componentes de redes
especficos y orientados a las tareas requeridas. Vea el Anexo A para la especificacin de los recursos de hardware.
Recurso
Cantidad Costo($us) Monto total
Servidores
Routers VPN
11
Concentradores de red
2000
8000
700
1400
300
600
Total
10000
Tabla 15: Costo de recursos
Variable
Monto($us)
Recursos humanos
Recursos fsicos
Total
343300
10000
353300
Tabla 16: Costo de recursos
8.2.2. Costos del riesgo

Con el plan de gestin de riesgos ya definido, se tienen 10 riesgos con probabilidad de ocurrencia media y alto
impacto, el costo de las medidas de prevencin ya est includo en la planificacin del proyecto. Lo que debe definirse
es el costo de las medidas de reaccin, en este caso se incrementar como margen de seguridad el costo de 1 mes de
trabajo:
Variable
Costo recursos
Franja de seguridad en caso de ocurrencia de riesgos
11
Precios obtenidos de http://shopper.cnet.com/routers/
Monto($us)
353300
19350
TERA
SOFT
SOFTWARE
Total
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
372650
Tabla 17: Costo con previsin de riesgos
TERA
SOFT
9.
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
SOFTWARE
REFERENCIAS
Schmidt, Stephan. Comparing Java and Python is Java 10x more verbose than Python (LOC)? A modest
empiric approach. [enlnea], 2008. <http://codemonkeyism.com/comparing-java-and-python-is-java-10xmore-verbose-than-python-loc-a-modest-empiric-approach/>
Spolsky,
Joel.
Dollars
per
Thousan
lines
of
code.
[el
lnea],
2007.
<http://discuss.joelonsoftware.com/default.asp?biz.5.467536.25>.
NASA. Risk management plan: Building the Computational Technology Infrastructure for Public Health and
Environmental Forecasting. [en lnea], 2002. <http://bp.gsfc.nasa.gov/pub/BP-RMP-1.0.pdf>.
Pressman, Roger. Ingeniera del software, un enfoque prctico. Estados Unidos - McGrawhill, 2001.
Braude, Eric. Software Engineering: An object-oriented perspective. Estados Unidos John Wiley&Sons,
2000.
Specs.
All
SPEC
JVM2008
Results
Published
by
SPEC.
[en
lnea],
2008.
lnea],
2010.
<http://www.spec.org/jvm2008/results/jvm2008.html>.
INE.
Segundo
trimestre
2010:
Salario
renumeracin
media.
<www.ine.gob.bo/pdf/Resumenes/RES_2010_25.pdf>.
10.
ANEXOS
10.1. Anexo A: Especificaciones de hardware

Recurso
Descripcin
Servidor Web
* PowerEdge T610 Tower Server customized

* OS: RedHat Enterprise Linux 6
* 2 tarjetas NIC
* 2 SSD-HD con 1TB cada uno
Servidor de datos

* FS: XFS con journallingactivo
Servidor de respaldo

* FS: XFS con journallingactivo
Router
3900 Series IntegratedServicesRouter
VPN
Cisco VPN 3000 Concentrator
Tabla 18: Especificaciones de hardware
[en
TERA
SOFT
SOFTWARE
Cdigo: TS-DPD-04
Revisin: 4
Versin: 04
10.2. Anexo B: Especificaciones de software

Recurso
Descripcin
Costo
Servidor web
JBossApplication Server 7
ninguno
Servidor de datos
PostgreSQL 5
ninguno
Integracin continua
Jenkins CI
ninguno
Sistema de control de versiones
GIT 1.7.3
ninguno
Procesador de texto
LibreOffice 3.4 Enterprise
ninguno
Sistema operativo (servidores)
RedHat Enterprise Linux 6
599 $us por instalacin
Sistema operativo (desarrollo)
Windows 7 Proffessional
200 $us
Entorno de desarrollo integrado
Eclipse JEE Helios
Ninguno
Gestor de tareas y bugs
JIRA Enterprise Edition
1800 $us
Tabla 19: Especificaciones de software

Proyecto Farmacia Plan Desarrollo

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto Farmacia Plan Desarrollo

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD AUTNOMA GABRIEL REN MORENO

Unidad de Postgrado de la Facultad de Ciencias Exactas y

PLAN DE DESARROLLO PARA EL SISTEMA FARMACORP

Santa Cruz de la Sierra, Bolivia

Planificacin temporal y de recursos

INDICE DEL CONTENIDO

Definicin del problema..............................................................................................................1

VISTA GENERAL DEL PROYECTO

2.1. Objetivo general..............................................................................................................................2

ORGANIZACIN DEL PROYECTO

3.1. Organizacin interna.......................................................................................................................7

Mtodos, herramientas y tcnicas...............................................................................................9

Documentacin del producto....................................................................................................10

5.1. Dominio de la aplicacin..............................................................................................................11

5.3.3. Tipo de conexin....................................................................................................................16

Orientadas al tamao (MOT).............................................................................................18

Orientadas a la funcin (MOF)..........................................................................................19

Anlisis de las estimaciones...............................................................................................22

ANLISIS Y MANEJO DE RIESGOS

GESTIN DEL PROCESO 27

10.1. Anexo A: Especificaciones de hardware.....................................................................................32

Tabla 5: MOF aplicadas a OpenBravo

Tabla 6: MOF aplicadas a OpenERP 20

Tabla 8: MOF aplicadas a la aplicacin a desarrollar

Tabla 10: COCOMO bsico 22

Tabla 12: Recursos humanos 28

Tabla 14: Costo de personal 30

Tabla 18: Especificaciones de hardware

Tabla 19: Especificaciones de software

Figura 1: Proceso de desarrollo

Figura 2: Organigrama interno

Figura 3: Modelo de dominio11

Figura5: Sub-sistemas identificados 15

Figura 8: Planificacin temporal

Definicin del problema

VISTA GENERAL DEL PROYECTO

2.1. Objetivo general

2.2. Objetivos especficos

b. Reporte de proveedores considerando volmenes de compras, de forma mensual y a requerimiento.

d. Reporte de productos solicitados a proveedores.

Reporte de clientes, sus puntos acumulados y puntos usados (canjeados).

g. Reporte del catlogo de ofertas.

2.3.2. Requerimientos no funcionales

sucursales de manera simultnea.

2.3.3. Suposiciones y restricciones

2.4. Fundamentacin de la metodologa

2.4.1. Modelo de proceso

2.4.3. Hitos principales

usuario, generalmente engloban todas las funcionalidades de un mdulo.

2.4.4. Proceso de desarrollo

El proceso de desarrollo puede resumirse en el siguiente proceso:

Figura 1: Proceso de desarrollo

ORGANIZACIN DEL PROYECTO

En esta seccin se describe el modelo de proceso, la estructura organizacional y responsabilidades individuales en el

3.1. Organizacin interna

Figura 2: Organigrama interno

PLAN DE DESARROLLO PARA EL SISTEMA FARMACORP

3.2. Roles y responsabilidades

Jefe mximo de la organizacin, es la persona a cargo de todos los proyectos.

Profesional en la administracin de proyectos. Tiene la responsabilidad de planificar,

Responsable de definir la arquitectura de la aplicacin (en colaboracin con el

Encargado de disear y desplegar las redes fsicas de comunicacin para la aplicacin.

Responsable de definir la arquitectura de la aplicacin, sus componentes y la interaccin