UNIVERSIDAD AUTNOMA GABRIEL REN MORENO UNIDAD DE POSTGRADO

PLAN DE ADMINISTRACIN DE PROYECTO DE SOFTWARE

GESTIN DE FARMACIAS
Luis Alberto Baigorria Rodas
08/08/2011

[Caso de Estudio: FarmaCorp] El presente documento constituye un Plan de Administracin de Proyecto de Software para la Gestin y Administracin de las diferentes actividades realizadas por la cadena de Farmacias FarmaCorp.

INTRODUCCIN
El presente documento constituye un Plan de Administracin de Proyecto de Software para la Gestin y Administracin de las diferentes actividades realizadas por una cadena de Farmacias, como caso de estudio tenemos FarmaCORP. Se desarrollar la implementacin de una aplicacin que controle todos los aspectos

relacionados con la gestin de las diferentes actividades de la cadena de farmacia FarmaCORP. La cadena de farmacias FarmaCORP requiere de una rpida instalacin de un nuevo sistema que opere en red, conectando a todas las sucursales con la oficina central y los diferentes almacenes, de forma que las personas encargadas de las ventas y de la administracin puedan agilizar las diferentes operaciones que realizan. En la cadena de farmacias se dispone ya de un sistema que permite realizar las diferentes actividades en cada de una de las farmacias, pero debido al crecimiento de las operaciones de las demandas de los clientes, ste ha sido sobre pasado. Es por ello, por medio de este plan de proyecto y un anlisis de la viabilidad, se considere la rpida incorporacin y puesta en marcha de un sistema que opere en red y conecte a la oficina central con las diferentes sucursales, ofrecer una atencin ms rpida y que pueda cubrir las demandas por parte de nuestros clientes en su totalidad. Algunos aspectos notables del sistema es que todos los productos tenga una alta disponibilidad, permita establecer un control de inventarios de los productos (medicamentos y otros) que se adquieren, as como los que se ponen a la venta, este control tendr la finalidad de poder manejar stock de seguridad y adelantarse ante posibles contingencias (falta de material). El trabajo a realizar consiste en desarrollar el plan de administracin del proyecto de software, el cual nos permita realizar un anlisis de la viabilidad del plan, realizar un anlisis de las mtricas y estimaciones, posibles riesgos, plan de contingencia, la manera de organizar a nuestro equipo de trabajo, los recursos humanos, los costos asociados a la ejecucin del plan y los asociados a los diferentes riesgos.

ANTECEDENTES
FarmaCorp naci el 13 de mayo de 1934 en Santa Cruz de la Sierra, Bolivia, bajo el nombre de Gutirrez, apellido de su fundador el bioqumico Osvaldo Gutirrez. Este sera administrador de la empresa farmacutica durante varios aos. Su hija mayor, Rosario Gutirrez, abri en 1964 otra empresa farmacutica, la farmacia Santa Mara, ubicada al frente de la farmacia Gutirrez. Hace 70 aos, Osvaldo Gutirrez, de profesin bioqumico, abri la primera farmacia a la que puso por nombre Gutirrez, y durante mucho tiempo la administr. Don Osvaldo nunca imagin que aquella iniciativa permanecera por tanto tiempo, pero su hija mayor, Rosario, mirando el espritu emprendedor del padre, quiso seguir sus pasos y en 1964, con la ayuda de su esposo Lorgio Paz, pusieron en marcha la farmacia Santa Mara; ubicndola frente a la Gutirrez. Posteriormente, Mara Ren se integr al negocio de su padre y ms tarde lo hara su hermana Rosemary que tambin form parte del equipo Gutirrez. Entre tanto, Mara Eugenia, la menor de las cuatro hermanas se incorpor en el desafo para llevar adelante a la Santa Mara. Desde esa poca, ambas farmacias compartieron liderazgo dentro del departamento. En 1993 fue un ao muy importante para la familia Gutirrez, una de sus empresas dara un salto dentro de lo que es el servicio en el rubro farmacutico, puesto que con la apertura del segundo punto de venta de la Santa Mara, naci el concepto de cadena. De esa manera las cuatro hermanas se convirtieron en rivales circunstanciales en sus farmacias, pero slo en el trabajo porque luego de la jornada, la familia se reuna en largas tardes y noches de charlas y festejos, criando a los hijos y soando con que la siguiente generacin se encargara de seguir con el emprendimiento de los Gutirrez. Este sueo no tardara en llegar, puesto que en 1996 se dio la primera incorporacin de la tercera generacin a una de las farmacias. Rosario, nieta de Osvaldo Gutirrez, incursion en el rubro ayudndole a su madre en la administracin de farmacia Santa Mara, y Ximena hija de
3

Mara Ren lo hizo en la Gutirrez. Ambas empresas continuaron creciendo y abriendo sucursales dentro del departamento. Una vez consolidadas las dos farmacias, Santa Mara y Gutirrez, y ante la necesidad de encarar nuevos proyectos, naci la idea de fusionarlas para evitar la competencia entre ambas, puesto que pertenecan a la misma familia. La visin y misin estuvo a cargo de los nietos de Osvaldo Gutirrez, quienes cada uno con sus profesiones distintas, lejos del entorno farmacutico con el que haban crecido, tomaron la iniciativa de crear la compaa FarmaCorp. Entonces empez el trabajo y tras la primera reunin, nace el nombre que fue ideado por Chiqui, la ms creativa y la que lanza la mayora de las ideas, indicaron sus primos Ximena y Erwin. Se qued en que no se mirara para atrs, pase lo que pase, y "eso es lo que hemos hecho hasta el momento", recuerda Ximena. Esteban y Erwin se encargaron de ver los aspectos financieros y econmicos para la viabilidad de la nueva empresa, mientras que Ximena y Chiqui se encargaban de la organizacin. La fusin fue un momento histrico para la familia, ya que cada uno de los integrantes recin se dio cuenta de lo mucho que se haba logrado hasta entonces. Recuerdo que el momento de la fusin no cost, lo complicado fue unir recursos humanos y las personas idneas para desempear las funciones, indic Erwin. Las gestiones se iniciaron el ao 1999 y FarmaCorp empez a operar un ao despus, en plena crisis econmica. Los jvenes empresarios, aunque les asustaba el hecho de comparar las ventas de aos anteriores y las que se daban en ese momento, siguieron trabajando sin mirar atrs y con el apoyo de sus padres. Fue una etapa muy difcil, explican. En ese tiempo tenan buenas expectativas pero no tenan idea de lo que les esperaba. En la actualidad la cadena de farmacia FarmaCORP se encuentra en su mejor momento, las operaciones han crecido y sobrepasado la aplicacin que se tiene instalada, en una junta con los directivos de dicha farmacia se ha tomado la decisin de mejorar la productividad y disponibilidad de los productos.
4

El escenario que se tiene actualmente en las farmacias es el siguiente, por lo que se requiere de un plan inmediato de Administracin de Proyecto de Software. Las farmacias trabajan 24 horas en tres turnos los siete das 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 travs 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 da a la oficina central de acuerdo al control de stock. El punto de reposicin es definido por el regente, al igual que la cantidad a pedir. La oficina central consolida el pedido de todas las sucursales, previa verificacin de stocks en almacenes y efecta la solicitud de compra a los proveedores. La reposicin y abastecimiento de los productos a las sucursales se realiza todos los das a travs de los vehculos que dispone la compaa, 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 catalogo de ofertas, en el momento que el cliente lo requiera. Se elabora los catlogos de ofertas que son productos (medicamentos y otros) en promocin, que se ofrecen todos los meses. Son productos de toda ndole (cosmticos, de higiene, etc.) entre los que tambin se consideran aquellos que no se venden o estn por caducar. Por otra parte se hacen sorteos para das festivos (da del padre, da 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 cupn para dicho concurso. Los premios son variados desde pasajes y vacaciones pagadas, hasta vehculos.
5

OBJETIVOS
Objetivo General
Desarrollar un Sistema de Informacin para la Gestin y Administracin de los productos de la cadena de farmacias FarmaCORP en un entorno Web y centralizado.

Objetivos Especficos
Para alcanzar nuestro objetivo general nos hemos planteado los siguientes objetivos especficos: Identificar y recolectar los requerimientos y/o requisitos que nos puedan brindar toda la informacin necesaria para el anlisis y elaboracin del Sistema.

Realizar entrevistas, reuniones con los directivos de la empresa a fin de recabar ms informacin del proceso de registro de los productos, los medicamentes y las forma en la que stos se encuentran organizados.

Disear y modelar los diferentes artefactos de software tomando como base el anlisis de requisitos, para lo cual se utilizaran herramientas de diseo del Lenguaje Unificado de Modelado UML. Documentar todos los detalles durante el proceso de construccin del Sistema y en cada una de sus fases. Establecer la estructura organizacional del equipo de trabajo, el nmero de participantes por equipo y la metodologa apropiada para desarrollar el sistema.

Implementar cada uno de los modelos generados durante la fase de diseo en el lenguaje de programacin ms apropiado.

Realizar pruebas y depuracin para garantizar que el software desarrollado cumpla con los requerimientos del cliente.

Disear e implementar una Base de Datos capaz de soportar todos los requerimientos del sistema de tal forma que se pueda gestionarlos datos requeridos por el sistema con mayor exactitud.

Disear interfaces visuales amigables para el usuario,

de tal modo que sea

comprensible y fcil de manejar, evitando las posibles complicaciones durante el proceso de gestin de los datos.

ALCANCES
A continuacin se describe el alcance del sistema a desarrollar, se realiza un detalle de los principales requerimiento Funcionales y No Funcionales.

Requerimientos Funcionales
Dentro de las funcionalidades solicitadas de lo que tiene que hacer el producto de Software se tiene lo siguiente: Gestionar el Registro de los Medicamentos Gestionar Proveedor de Productos Gestionar Almacenes Gestionar Compra de Medicamentos Gestionar Formas de Pagos a los Proveedores Generar Factura de Venta Gestionar Puntos Acumulados Gestionar Clientes Gestionar Catlogos de Oferta Gestionar Puntos Canjeados
7

Gestionar Personal (Oficina Central, Sucursales y Almacenes) Gestionar Asignacin de Turnos Gestionar Permisos Gestionar Vacaciones Gestionar Planilla de Personal Gestionar Reportes Generar Reporte de Ingresos diarios de Productos Generar Reporte de Proveedores Generar Reporte de Productos Vendidos Generar Reporte de Medicamentos en Punto de Reposicin Generar Reporte de Productos Solicitados a Proveedores Generar Reporte de Volumen de Ventas Generar Reporte de Clientes Generar Reporte de Puntos Acumulados Generar Reporte de Puntos Canjeados Generar Reporte de Catalogo de Ofertas Inicialmente estos son los requerimientos funcionales identificados de acuerdo al escenario actual que se presenta en la cadena de farmacia. Una vez identificados estos requerimientos se proceder, ms adelante, a realizar una descripcin ms detallada de cada uno de los requerimientos, organizndolos y estableciendo un valor prioritario.

Requerimientos No Funcionales

Al tener una oficina central y operar en red, la solucin que proponemos debe ser escalable bajo la estrategia scale-up (Aadir ms inicialmente y luego scale-out (Aadir ms procesamiento. Si el sistema debe conformar con las normas de estandarizacin ISO 9000 - 9003. recursos al servidor central)

servidores), segn las necesidades de

El sistema deber contemplar alta disponibilidad y estabilidad ya que operar las 24 horas del da. El sistema debe estar sometido a altos niveles de seguridad, ya que deber estar en un entorno Web. Deber ser extensible a cambios, ya que la empresa est en constante crecimiento y mejora continua.

Rendimiento
El sistema antes de ingresar a produccin deber ser sometido a una serie de tcnicas y procedimiento para determinar el grado de rendimiento que se tiene, as mismo ver el comportamiento del sistema a los cambios que puedan presentarse. A continuacin detallamos las diferentes tcnicas que se podr utilizar para las pruebas de rendimientos: Prueba de estrs Esta prueba se utilizar con el fin de romper la aplicacin. Se va doblando el nmero de usuarios que se agregan a la aplicacin y se ejecuta una prueba de carga hasta que se rompe. Este tipo de prueba se realiza para determinar la solidez de la aplicacin en los momentos de carga extrema y ayuda a los administradores para determinar si la aplicacin rendir lo suficiente en caso de que la carga real supere a la carga esperada. Prueba de estabilidad (soak testing) Esta prueba se realizar cundo sea necesario determinar si la aplicacin puede aguantar una carga esperada continuada. Pruebas de picos (spike testing) La prueba de picos, trata de observar el comportamiento del sistema variando el nmero de usuarios, tanto cuando bajan, como cuando tiene cambios drsticos en su carga.

Pre-requisitos para las pruebas de carga Es aconsejable, para realizar la prueba de carga disponer de un entorno de pruebas de rendimiento lo ms parecido como se pueda al entorno de produccin, y no as con pruebas de aceptacin de usuarios ni con el entorno de desarrollo.

Restricciones
Las suposiciones y restricciones respecto del sistema, y que se derivan directamente de las entrevistas realizadas con los stakeholder de la empresa son: a) Debe contemplarse las implicaciones de los siguientes puntos crticos: El sistema opere en red conectando a todas las sucursales con la oficina central y las oficinas. Plataforma de desarrollo ASPX. Sistemas seguros: proteccin de informacin, seguridad en las trasmisiones de datos. Durante el horario de atencin. 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. b) La automatizacin de la gestin interna del registro de los medicamentos debe ajustarse a la legislacin vigente y considerar la previsin de nuevas legislaciones. c) El subsistema de Gestin de Almacenes se deber disear como un mdulo independiente para ser utilizado posteriormente en otras regiones de los distintos almacenes no centralizados. Como es natural, la lista de suposiciones y restricciones se incrementar durante el desarrollo del proyecto.

10

MTRICAS
El objetivo principal en este paso es determinar el tiempo necesario para terminar el proyecto de software y cul es el esfuerzo necesario que se necesitar, es decir personas requeridas para desarrollar el proyecto. Las tablas de registro est construida en base a experiencia personal y de compaeros de la universidad en proyectos desarrollados en entorno Web, con los lenguaje de programacin, ASP, PHP y JSP, es decir la experiencia en desarrollo de los proyectos es acadmica. Estos datos servirn como base para realizar las mtricas necesarias para el proyecto requerido. A partir de los resultados obtenidos en el anlisis de los datos, se proceder a realizar la mtrica para nuestro proyecto, tomando como datos supuestos una media de los datos de los proyectos presentados.

Registro de Proyectos trabajados anteriormente (MOT)

PROYECTO
A B C D

GENTE
4 5 2 4

ESFUERZO
16 15 10 16

COSTO $us
350 450 600 700

KLDC
9.15 5.5 12.6 10.5

PAG. DOC.
130 200 180 150

ERRORES
30 20 15 17

LENGUAJE
ASP JSP PHP ASP

TIEMPO
4 3 5 4

Proyecto A: Sistema de Informacin para el seguimiento del historial oftalmolgico, gestionar consulta y reserva va Web para la Clnica de Ojos. (ASPX-Tecnologa .NET)

11

Proyecto B: Sistema de Informacin para Gestionar el proceso de Inscripcin, obtencin de notas, Registro y Control de Pago de Pensiones para la Unidad Educativa Privada Santa Cecilia. Proyecto C: Sistemas para Gestionar Envos de Campanias Publicitarias desde un enfoque de Social CRM (Desarrollado en PHP) Proyecto D: Sistema de Informacin para gestionar compra y venta de medicamentos para la Farmacia Santa Juan Para los clculos de Calidad y Productividad se aplic la siguiente frmula:
Calidad = (Errores / KLDC) Productividad = (KLDC / Persona-Mes) Documentacin = Pag. Doc/KLDC

CALCULO DE LA CALIDAD Y PRODUCTIVIDAD DE LOS DATOS HISTRICOS

Los siguientes resultados muestran la calidad de los proyectos y la productividad.

1. Proyecto A Calidad = (30) / 9.15 = 3.2786 Productividad = (9.15 / 16 ) * 1000 = 571.875 2. Proyecto B Calidad = (20) / 5.5 = 3.6363 Productividad = (5.5 / 15) * 1000 = 366.6666 3. Proyecto C Calidad = (15) / 12.6 = 1.1904 Productividad = (12.6 / 10) * 1000 = 1260 4. Proyecto D Calidad = (17) / 10.5 = 1.6190 Productividad = (10.5 / 16) * 1000 = 656.25
12

A partir de estos datos estadsticos se buscar valores supuestos para cada uno de los campos solicitados, cada uno de estos valores nos permitir realizar la mtricas apropiadas para nuestro proyecto, como ser: Mtricas Orientadas al Tamao (MOT) y Mtricas Orientada a la Funcin (MOF).

Mtrica Orientada al Tamao

COSTO $us
350 450 600 700 3000

PROYECTO
A B C D SISTEMA
FARMACORP

GENTE
4 5 2 4 5

ESFUERZO
16 15 10 16 30

KLDC
9.15 5.5 12.6 10.5

PAG. DOC.
130 200 180 150 5150

ERRORES
30 20 15 17 40

LENGUAJE
ASP JSP PHP ASP PHP

TIEMPO
4 3 5 4 6

95.0

Anlisis. Como se puede ver en el cuadro correspondiente a los datos de anteriores proyectos, se ha incluido el proyecto a tratar (SISTEMA FARMACORP), se est tomando valores supuestos, de acuerdo al nmero de requerimientos identificados, en este plan de proyecto se ha identificado 30 requerimientos, si por cada uno de los requerimientos se crear 3 clases, siguiendo el arquitectura MCV (Modelo, Vista, Controlador) o 3 capas (Presentacin, Negocio y Datos) entonces se habrn creado 80 clases, supongamos que existen 15 clases ms de ayuda para la realizacin de algunos requerimientos, entonces tenemos 95 clases, si cada clase tiene como mximo 100 LDC, multiplicando 100 LDC X 95 Clases, eso nos dar 95.000 LDC en todo el proyecto. Por lo tanto, nuestro valor supuesto en LDC, son:

95.000 LDC.
13

Con estos valores, procedemos a calcular las mtricas de productividad y calidad orientadas al tamao, de acuerdo a las siguientes frmulas: 1. Calidad = (Errores / KLDC) 2. Productividad = (KLDC / Persona-Mes) * 1000 3. Documentacin = Pagina. Documento / KLDC 4. Costo = $us / KLDC Calidad = 80 / 95 = 0.84 Productividad = (95 / 30) * 1000 = 3166.6666 Documentacin = 5150/ 95 = 54 Costo = 3000 / 95000

Mtrica Orientada a la Funcin

Al igual como se realiz en las Mtricas Orientadas a la Funcin, las siguientes tablas presentas datos de diferentes proyectos presentados en la Universidad, el cual nos permitir realizar nuestro cuadro de datos aplicado al plan que se est elaborando. Los siguientes datos nos servirn como muestras estadsticas, suponiendo que fuera el caso en el que nos encontremos en una empresa en la que ya se cuenta con datos de diferentes proyectos trabajados, el cual nos permite realizar un anlisis para elaboracin de nuestro Plan de Administracin de Proyecto de Software.

Datos Estadsticos de Proyectos

Proyecto A:

Factor de Ponderacin
Parmetros de Medicin Cuenta Simple Medio Complejo Eleccin Sumatoria

14

Nmero de Entradas de Usuario Numero de Salidas de Usuario Nmero de peticiones de Usuario Numero de archivos Numero de interfaces externas

23 6 4 2 1

3 4 3 7 5

4 5 4 10 7

6 7 6 15 10 CTOTAL

3 5 3 7 7

69 30 12 14 7 132

Medicin del Proyecto A segn el factor de peso

4, SIGNIFICATIVO

2, MODERADO

0, NO INCLUYE

1, INCIDENTAL

5, ESENCIAL

3, MEDIO

PREGUNTAS

1. Requiere el sistema copias de seguridad y de recuperacin fiables? 2. Se requiere comunicacin de datos? 3. Existen funciones de procesamiento distribuido? 4. Es crtico el rendimiento? 5. Se ejecutara el sistema en un entorno operativo existente y fuertemente utilizado? 6. Requiere el sistema entrada de datos interactiva? 7. Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas u operaciones? 8. Se actualizan los archivos maestros de forma interactiva?

0 5 0 5 5 4

SUMA
0 5 0 5 5 4 2 4 15

9. Son complejas las entradas, las salidas, los archivos o las peticiones? 10. Es complejo el procesamiento interno? 11. Se ha diseado el cdigo para ser reutilizable? 12. Estn incluidas en el diseo la conversin y la instalacin'? 13. Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones? 14. Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario? 0

1 5 1

1 5 1 0 2 2

TOTAL
Medicin del Proyecto A segn las mtricas orientadas a la funcin
14

39

fi
Entonces calculando el PF tenemos:

PF = CTotal * [0.65 + 0.01 *

i 1

PF = 132 * [0.65 + 0.01 * 39] PF = 137.28

Proyecto B:

Factor de Ponderacin
Parmetros de Medicin Nmero de Entradas de usuario Nmero de Salidas de Usuario Nmero de peticiones de Usuario Nmero de archivos Nmero de interfaces externas Cuenta 40 8 30 30 1 Simple 3 4 3 7 5 Medio 4 5 4 10 7 Complejo 6 7 6 15 10 ELECCION 4 5 4 10 7 Sumatoria 160 40 120 300 7

16

CTOTAL

627

Medicin del Proyecto B segn el factor de peso

4, SIGNIFICATIVO

2, MODERADO

0, NO INCLUYE

1, INCIDENTAL

5, ESENCIAL

3, MEDIO

PREGUNTAS

1. Requiere el sistema copias seguridad y de recuperacin fiables? 2. Se requiere comunicacin de datos?

de

4 4 0 5 5 3

SUMA
4 4 0 5 5 3 0 3 3 5 5 5 0 17

3. Existen funciones de procesamiento distribuido? 4. Es crtico el rendimiento? 5. Se ejecutar el sistema en un entorno operativo existente y fuertemente utilizado? 6. Requiere el sistema entrada de datos interactiva? 7. Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas u operaciones? 8. Se actualizan los archivos maestros de forma interactiva? 9. Son complejas las entradas, las salidas, los archivos o las peticiones? 10. Es complejo el procesamiento interno? 11. Se ha diseado el cdigo para ser reutilizable? 12. Estn incluidas en el diseo la conversin y la instalacin'? 13. Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones?

3 3 5 5 5 0

14. Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario?

TOTAL

42

Medicin del Proyecto B segn las mtricas orientadas a la funcin

Entonces calculando el PF tenemos:
14

fi

PF = CTotal * [0.65 + 0.01 * i 1 PF = 627 * [0.65 + 0.01 * 42] PF = 251.49

Proyecto C:

Factor de Ponderacin
Parmetros de Medicin Nmero de Entradas de usuario Nmero de Salidas de Usuario Nmero de peticiones de Usuario Numero de archivos Numero de interfaces externas Cuenta 40 35 5 21 5 Simple 3 4 3 7 5 Medio 4 5 4 10 7 Complejo 6 7 6 15 10 ELECCION 4 5 3 10 5 CTOTAL Sumatoria 160 175 15 210 25 585

18

Medicin del Proyecto C segn el Factor de Peso

4, SIGNIFICATIVO

2, MODERADO

0, NO INCLUYE

1, INCIDENTAL

5, ESENCIAL
5

3, MEDIO

PREGUNTAS

1. Requiere el sistema copias seguridad y de recuperacin fiables? 2. Se requiere comunicacin de datos?

de 3 0 3 4 2

SUMA
5 3 0 3 4 2 0 1 2 3 2 4 0 19

3. Existen funciones de procesamiento distribuido? 4. Es crtico el rendimiento? 5. Se ejecutar el sistema en un entorno operativo existente y fuertemente utilizado? 6. Requiere el sistema entrada de datos interactiva? 7. Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas u operaciones? 8. Se actualizan los archivos maestros de forma interactiva? 9. Son complejas las entradas, las salidas, los archivos o las peticiones? 10. Es complejo el procesamiento interno? 11. Se ha diseado el cdigo para ser reutilizable? 12. Estn incluidas en el diseo la conversin y la instalacin'? 13. Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones?

1 2 3 2 4 0

14. Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario?

TOTAL
Medicin del Proyecto A segn las mtricas orientadas a la funcin
14

29

fi
Entonces calculando el PF tenemos: PF = CTotal * [0.65 + 0.01

*i1

PF = 585 * [0.65 + 0.01 * 29] PF = 549.9

Mtricas Orientadas a la Funcin aplicado al Proyecto
El siguiente cuadro muestra datos supuestos para el clculo de la Cuenta Total aplicado al proyecto. Son datos supuestos sacados de la experiencia en los proyectos trabajados con anterioridad. Proyecto FarmaCORP:

Factor de Ponderacin
Parmetros de Medicin Nmero de Entradas de usuario Nmero de Salidas de Usuario Nmero de peticiones de Usuario Numero de archivos Numero de interfaces externas Cuenta Simple Medio Complejo Sumatoria

130 145 60 80 5

3 4 3 7 5

4 5 4 10 7

6 7 6 15 10 CTOTAL

143 161 73 112 27 516 20

Medicin del Proyecto segn el Factor de Peso

4, SIGNIFICATIVO

2, MODERADO

0, NO INCLUYE

1, INCIDENTAL

5, ESENCIAL
5

3, MEDIO

PREGUNTAS

1. Requiere el sistema copias seguridad y de recuperacin fiables? 2. Se requiere comunicacin de datos?

de 3 0

SUMA
5 3 0 5 4 2 0 1 2 3 2 4 0 0

3. Existen funciones de procesamiento distribuido? 4. Es crtico el rendimiento? 5. Se ejecutar el sistema en un entorno operativo existente y fuertemente utilizado? 6. Requiere el sistema entrada de datos interactiva? 7. Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas u operaciones? 8. Se actualizan los archivos maestros de forma interactiva? 9. Son complejas las entradas, las salidas, los archivos o las peticiones? 10. Es complejo el procesamiento interno? 11. Se ha diseado el cdigo para ser reutilizable? 12. Estn incluidas en el diseo la conversin y la instalacin'? 13. Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones? 14. Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario?

5 4 2

1 2 3 2 4 0

TOTAL

31
21

Clculo de las Mtricas Orientada a la Funcin

Entonces calculando el PF tenemos:
14

fi

PF = CTotal * [0.65 + 0.01 * PF = 516 * [0.65 + 0.01 * 31] PF = 495.36

i 1

ESTIMACIONES
El objetivo principal en este paso es realizar estimaciones de coste y esfuerzo necesarios para desarrollar el proyecto en su totalidad. La estimacin del coste y del esfuerzo del software nunca ser una ciencia exacta. Son demasiadas las variables humanas, tcnicas, de entorno, polticas, etc. que pueden afectar al costo final del software y al esfuerzo aplicado para desarrollarlo. Por consiguiente, los siguientes clculos estn basados en modelos empricos, el modelo COCOMO.

Estimacin de LDC (Lneas de Cdico)

En esta siguiente actividad vamos a la estimacin del coste y del esfuerzo del software nunca ser una ciencia exacta. Son demasiadas las variables humanas, tcnicas, de entorno, polticas que pueden afectar al coste final del software y al esfuerzo aplicado para desarrollarlo. Sin embargo, la estimacin del proyecto de software puede dejar de ser un oscuro arte para convertirse en una serie de pasos sistemticos que proporcionen estimaciones con un grado de riesgo aceptable. Entonces, se calcula el valor esperado de LDC o de PF. El valor esperado para la variable de estimacin, E, se obtiene como una media ponderada de las estimaciones LDC PF optimista (a), ms probable (m) y pesimista (c). Por ejemplo:

22

E = (a + 4m + c)/6

Se asume que despus de refinamiento se hallaron las funciones de SW lo siguiente: Interfaz de Usuario y facilidad de control (IU) Gestin de Base de Datos (GBD) Llevar registro de actividades de producto, cliente, venta y empleado (RA) Entorno distribuido de los datos (ED) Control perifrico (CP) Modulo de reportes de las actividades (producto, cliente, venta y empleado).(MR)

Tabla de estimacin por LDC Funcin Optimista (LDC) UI GBD RA ED CP MR Total 1800 2200 1600 1300 1900 1400 Ms probable (LDC) 2500 2400 1700 1500 2100 1600 Psimo (LDC) 3600 2500 2000 2100 2300 1900 Valor Esperado VE = (a + 4m + c)/6 2566 2383 1733 1566 2100 1616 11964

23

Calculado: 11964 LDC esperado y una revisin histrica nos da: LDC Estimada Tarifa Laboral Coste LDC Productividad PM (Esfuerzo) LDC/Productividad 11964 LDC 3000 $/Mes 7$ 600 LDC/Persona-Mes 11964/600 = 20PM

Modelo COCOMO

El Modelo Constructivo de Costo es una jerarqua de modelos de estimacin para el software. Las ecuaciones del modelo COCOMO bsico tienen la siguiente forma: E (Esfuerzo) = Persona-Mes a * (KLDCb)

D (Tiempo de desarrollo) = Meses c * Ed N (Numero de personas) E/D

Tabla de coeficiente de valores constantes Tipo de proyecto Orgnico Semiacoplado Empotrado a 2.4 3.0 3.6 b 1.05 1.12 1.20 c 2.5 2.5 2.5 d 0.38 0.35 0.32

Calculamos la estimacin de esfuerzo para 11964 LDC aplicando el Modelo COCOMO bsico y usando un tipo de proyecto orgnico:

24

E = 2.4 * (11.91.05) = 32.304 Persona-Mes D = 2.5 * 32.3040.38 = 9.3637 Meses 9 Meses N = 32.304/9.3637 = 3 Personas

Breve Anlisis de los resultados Obtenidos

Al igual que se realiz en las Mtricas, los datos de las tablas correspondiente para la estimacin por LDC y modelo COCOMO fueron obtenidos de experiencias trabajados en proyectos de la Universidad, es por ello son datos supuestos, pero que nos permiten realizar un anlisis aproximado para determinar las LDC y a partir de esos datos estimar el esfuerzo, tiempo y costo de la realizacin del Proyecto. Si bien esos datos no son 100% exactos, en cuanto a las lneas de cdigo por cada funcionalidad identificado es un valor que no est fuera de la realidad. Por lo tanto los resultados que se obtuvo son valores supuestos.

ANLISIS DE RIESGO
Alcance y propsito del Documento de Riesgo

El riesgo del proyecto tiene su origen en la incertidumbre que est presente en todos los proyectos y por ende amenaza al xito de todo proyecto. Se identifica los posibles riesgos que pueden presentarse en el transcurso del proyecto. Se analiza cada riesgo encontrado anteriormente y se establece probabilidad de

ocurrencia y el dao que causar si dichos riesgos ocurren. Realizar una clasificacin de los riesgos segn su probabilidad de ocurrencia y el impacto que pudiesen causar. El propsito es desarrollar un plan de para determinar que acciones tomar frente a aquellos riesgos con gran probabilidad de que ocurran.

25

La organizacin debe estar comprometida a tratar la gestin de riesgos de forma proactiva y consistente durante todo el proyecto Un factor de riesgo que tiene un alto impacto, pero una probabilidad baja de que suceda, no debe absorber una cantidad significativa de tiempo.

Tabla de riesgos
La siguiente tabla muestra los diferentes riesgos que se pueden presentar en el proyecto. El impacto puede tener alguno de los siguientes valores: NI = No Influye M = Medio SG = Significativo CR = Critico

% Probabilidad

Plan de Aversin Impacto Reducir Probabilidad

-Realizar peridicamente copias de las aplicaciones en desarrollo. -Contar con antivirus actualizados en todos los equipos. -Realizar Mantenimiento de equipos de hardware peridicamente.

Riesgo

Reducir Impacto

R1: Prdida de informacin, ya sea por motivos tcnicos, infeccin de virus, etc.

30

CR

- Usar diferentes dispositivos de almacenamiento (CD, Pen Drive, etc) que sean seguros, de buena calidad, etc.

R2: Fallas de hardware o software.

40

SG

-Almacenar la informacin con la que se est trabajando en el software en otros dispositivos o maquinas. -Trabajar con estrategias empleadas previamente. - Capacitar peridicamente al personal en nuevas

- Adquirir equipos y/o Accesorios Informticos con garanta.

R3: Estrategia de

-Trabajar de manera organizada y minuciosamente, empleando toda la documentacin posible

26

desarrollo desconocido.

20

tecnologas.

acerca de la estrategia a utilizar.

R4: Herramienta de desarrollo desconocida.

-Trabajar con herramientas empleadas previamente. 20 SG - Capacitar peridicamente al personal. -En el momento de realizar la planificacin de tiempos y actividades, realizarla siguiendo un calendario en el cual contemple posibles eventualidades y tiempos reales de trabajo de los integrantes del equipo. -Elaborar un plan de estimacin bien detallado y con datos lo ms aproximadamente posibles al proyecto. -Elaborar varios mtodos de estimacin del software.

-Buscar informacin y ayuda en el manejo de la misma.

R5: Mala estimacin de tiempo debido a no contemplar actividades ajenas al proyecto.

70

CR

-Contemplar dentro de la planificacin de tiempo un tiempo de demora u holgura asumiendo cualquier tipo de eventualidad.

R6: Mala estimacin de costo.

60

CR

-Realizar un informe detallado del costo real del software.

R7: Mala estimacin de esfuerzo.

50

-Aumentar el personal asignado al desarrollo del software. -Solucionar los problemas de comunicacin.

-Realizar actividades para incentivar la buena comunicacin entre compaeros. -Especificar las tareas que debe realizar cada desarrollador detallando las fechas de presentacin. -Que el inmediato superior al desarrollador este siempre dispuesto a despejar las dudas del desarrollador en cada etapa del desarrollo del proyecto.

R8: Problemas de comunicacin entre los desarrolladores. 75 SG

-Explicar a las personas que hayan malinterpretado las tareas que deberan realizar para que lo corrijan.

27

R9: Cambio de Requisitos.

50

CR

-Realizar una captura de requerimientos minuciosa sobre las funciones que tiene que realizar el software e investigar detalladamente como lo hacan antes.

- Informar al cliente de que los cambios que solicita afectan en el tiempo, costo y esfuerzo del proyecto. -Realizar los cambios en el software y tratar de mantener la planificacin. -Informar al equipo de desarrollo de los cambios en la planificacin del proyecto.

R10: Integrante del equipo de desarrollo se retira del proyecto

-Firmar Contrato de trabajo con los integrantes del equipo 60 SG -Motivar a los integrantes del equipo a travs de dinmicas de trabajo

No distribuir de manera critica el trabajo

Reduccin y Supervisin de los riesgos (RSGR)

Anteriormente se identifico una lista de 10 posibles riesgos que se podran presentar durante el proceso de desarrollo del Software, as tambin se describi como se los podra reducir y supervisar. En cada uno de los posibles riesgos identificados se describi y detallo un Plan de Aversin, reduciendo as la probabilidad y el impacto.

PLANIFICACIN TEMPORAL
El objetivo principal en este paso es evitar los posibles retrasos en la entrega del producto de Software. Una vez establecido el costo y el esfuerzo necesario para la realizacin del proyecto, en esta fase se realizar un plan que permita la entrega del producto en los lmites establecidos, para ello realizaremos la identificacin de las diferentes tareas a realizar, la distribucin del esfuerzo necesario, clculo de selector de tareas, un diagrama de Gantt que permita reflejar las tareas a realizar en los tiempos establecidos, y por ltimo un diagrama de Red.

28

Identificacin de Tareas
A continuacin, se describe las diferentes tareas identificadas y asociadas a cada de las fases para el desarrollo del proyecto. Fase 1: Proceso de Desarrollo de la Aplicacin Abarca todo el proceso de desarrollo del proyecto, anlisis, diseo, implementacin, depuracin y pruebas de la aplicacin. 1. Entrevistas con el Cliente 2. Entrega de una propuesta inicial 3. Captura de Requerimientos 4. Seleccionar Miembros del Equipo 5. Anlisis de Requerimientos 6. Anlisis del Software 7. Diseo del Software 8. Implementar la aplicacin 9. Integracin de los mdulos 10. Pruebas Iniciales 11. Depuracin de la Aplicacin Fase 2: Pruebas Finales Esta fase abarca el proceso de pruebas finales, es decir, an se haya realizado pruebas iniciales durante el proceso de desarrollo de la aplicacin, con la finalidad de comprobar que todo funcionaba correctamente y el producto estaba listo para la entrega. 1. Fijar Calendario de Prueba 2. Aplicar Tcnicas de Prueba 3. Aplicar pruebas de Rendimiento Fase 3: Documentacin

29

Esta fase abarca todo el proceso de documentar el software, la investigacin de diferentes tecnologas que no se tenga conocimiento, investigacin de herramientas, capacitacin para los estndares de documentacin. Describe todas las tareas necesarias para la elaboracin de la documentacin. 1. Aplicacin del Calendario de Entrega Final 2. Elaboracin de Manuales de Uso y de Ayuda 3. Videos de Ayuda 4. Entrenamiento

Distribucin del Esfuerzo

La distribucin del esfuerzo se lo realizar de la siguiente manera en cada una de las fases identificadas anteriormente. Fase 1: Proceso de Desarrollo de la Aplicacin

En esta fase la distribucin del esfuerzo ser la de: 40 20 40, que establece lo siguiente: 40% del esfuerzo ser distribuido para el Anlisis y Diseo. 20% del esfuerzo ser distribuido para la codificacin, es decir para la implementacin (Generacin de Cdigo) 40% del esfuerzo ser distribuido para las pruebas iniciales, estas pruebas se realizan conforme se ir desarrollando el software.
Fase 2: Pruebas Finales En esta fase la distribucin del esfuerzo ser distribuido de la siguiente forma: 20 % del esfuerzo ser para la implementacin del entorno de prueba, es decir se emplear 20% del esfuerzo ser empleado para elaborar las diferentes pruebas a las cuales se someter el software. Estas pruebas finales sern las que determinarn en correcto funcionamiento del producto. Este equipo construir las pruebas necesarias a realizar, sern los que vayan evaluando los resultados de las pruebas que vayan realizando el 80% restante. 80% del esfuerzo ser utilizado para realizar las diferentes pruebas establecidas por los equipos de pruebas. 30

Fase 3: Documentacin
En esta fase se utilizar el 100% del esfuerzo.

Clculo del Selector de Tarea

Proceso del clculo del selector de Tarea. Multiplicador Criterios de adaptacin Grado Peso Desarr. Concep. 0 0 0 0 0 1 Nvo. Desarr. 1 1 1 1 1 1 Mejoras Mtto Reing. 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 0 1 1 Subtotal

Tamao del proyecto Nmero de usuarios Importancia para el negocio Longevidad de la aplicacin Estabilidad de los requisitos Facilidad de comunicacin Madurez de la tecnologa aplicable Limitaciones de rendimiento Empotrado/no empotrado Personal del proyecto Interoperabilidad Factores de reingeniera

3 5 4 3 3 3

1.20 1.10 1.10 0.90 1.20 0.90

3.6 5.5 4.4 2.7 3.6 2.7

0.90

4.6

2 3 3 4 2

0.80 1.20 1.00 1.10 1.20

0 1 1 0 0

1 1 1 1 0

1 1 1 1 0

0 0 1 1 0

1 1 1 1 1

1.6 3.6 3.0 4.4 2.4

Selector de conjuntos de tareas (TSS)

3.50

31

El resultado obtenido se encuentra dentro de la siguiente tabla de valores:

Valor del TSS TSS < 1.2 1.0 < TSS < 3.0 TSS > 2.4

Grado de rigor Informal Estructurado

Estricto

Por lo tanto, de acuerdo al TSS el Grado de Rigor Aplicable al Proyecto es: ESTRICTO

Tareas Identificadas: Entrevistas con el Cliente Entrega de una propuesta inicial Captura de Requerimientos Seleccionar Miembros del Equipo Anlisis de Requerimientos Anlisis del Software Diseo del Software Implementar la aplicacin Integracin de los mdulos Pruebas Iniciales Depuracin de la Aplicacin Fijar Calendario de Prueba Aplicar Tcnicas de Prueba Aplicar pruebas de Rendimiento Calendario de Entrega Final Elaboracin de Manuales de Uso y de Ayuda Videos de Ayuda Entrenamiento

32

Diagrama de Gantt

Diagrama de Red

Clave
A B C D E F G H I J K L M N O P

Tarea
Entrevistas con el Cliente Entrega de una propuesta inicial Captura de Requerimientos Seleccionar Miembros del Equipo Anlisis de Requerimientos Anlisis del Software Diseo del Software Implementar la aplicacin Integracin de los mdulos Pruebas Iniciales Depuracin de la Aplicacin Calendario de entregas finales Fijar Calendario de Prueba Aplicar Tcnicas de Prueba Finales Aplicar pruebas de Rendimiento Elaboracin de Manuales de Uso y de Ayuda

Tiempo (d) Antecesor(es)

6 4 15 16 20 46 40 40 10 30 32 3 7 5 3 8 L J N O A B C C, D E E, F G, F, E H, E, F, G I J

Clave
Q R

Tarea
Videos de Ayuda Calendario de Entrega Final

Tiempo (d) Antecesor(es)

6 6 P P

ORGANIZACIN INTERNA

CARGOS
Nombre del Cargo Relaciones internas Relaciones externas Jefe de Proyecto. Jefe de Proyecto. Con los clientes, encargado de negociar y cumplir con los requisitos que soliciten. Dirigir y mantener en una buena posicin comercial el negocio. Supervisin de las tares, Tener claro su propio trabajo, Desarrollar un plan para alcanzar sus objetivos, Asignar tareas, Establecer mecanismos de control, Evaluar la efectividad, Hacerse responsables de su propia tarea, y de la de sus subordinados Decisiones que puede tomar sin
35

Objetivo del cargo Responsabilidades bsicas

consultar y decisiones que debe consultar al superior: Autnomo.

Nombre del Cargo Relaciones internas Relaciones externas

Objetivo del cargo

Programador Analista Diseador Jefe de Proyecto. Con los clientes, el encargado de tomar nota de los requerimientos y analizarlos para realizar un buen desarrollo. Tiene como cometido analizar un problema y describirlo con el propsito de ser solucionado mediante un sistema de informacin. Crea la parte artstica o visual de un sitio y la estructura que tendr la pgina o software. El diseo se planifica en base al objetivo y luego se desarrolla teniendo en cuenta la navegabilidad, interactividad. Usabilidad y arquitectura de la informacin. Decisiones que puede tomar sin consultar y decisiones que debe consultar al superior: Autnomo.

Responsabilidades bsicas

36

Nombre del Cargo Relaciones internas Relaciones externas Objetivo del cargo

Responsabilidades bsicas

Secretaria Jefe de Proyecto n/a - Ser puntual en todas sus actividades de funciones. - Reclutar las solicitudes de servicios. - Hacer una evaluacin peridica de los proveedores para verificar el cumplimiento y servicios de stos. - Recibir e informar asuntos que tenga que ver con el departamento correspondiente, para que todos estemos informados y desarrollar bien el trabajo asignado. - Mantener discrecin sobre todo lo que respecta a la empresa. - Evitar hacer comentarios innecesarios sobre cualquier funcionario o departamentos dentro de la empresa. - Hacer y recibir llamadas telefnicas para tener informado a los jefes de los compromisos y dems asuntos. - Obedecer y realizar instrucciones que te sean asignadas por t jefe. - Mejora y aprendizaje continuo. Brindar a su jefe un apoyo incondicional con las tareas establecidas, adems de acompaar en la vigilancia de los procesos a seguir dentro de la empresa. Decisiones que puede tomar sin consultar y decisiones que debe consultar al superior: Siempre debe informar y solicitar autorizacin al Jefe de Proyecto.

37

Justificacin
La empresa XXXXX, debe cumplir con los objetivos de acuerdo a como lo establece la ley orgnica adems de que debe de soportar la informacin que debe de proporcionar a terceros como son los Gobiernos, congreso del estado, y dems por ser esta una obligacin de toda institucin pblica. Para lograr lo anterior, se apoya a travs de sistemas integrados y personalizados a sus necesidades, estos sistemas de informacin son elaborados por el Departamento de Sistemas de Informacin.

Objetivo
El Departamento de Sistemas de Informacin es un rea de apoyo de vanguardia en la elaboracin de proyectos informticos a ser una institucin proactiva en cuanto a la modernizacin de sus procesos administrativos, en la explotacin de la informacin generada en pro del conocimiento, la toma de decisiones y el crecimiento de la Institucin.

Misin
Proporcionar a los clientes, en este caso FARMACORP. , que le permitan la toma de decisiones de manera oportuna, eficiente y consistente a travs de un sistema de informacin integral.

Funciones
El Departamento de Sistemas de Informacin tiene como funcin principal: proporcionar a la empresa XXXXX elementos tecnolgicos que le permitan cumplir con sus responsabilidades en cuanto a la gestin y a la toma de decisiones. Estos elementos tecnolgicos se traducen a Sistemas de Informacin que permiten a todos los niveles de la organizacin poder acceder a la informacin generada. - Integrar soluciones de Sistemas de Informacin. - Presentar propuestas de actualizacin de nuevas Tecnologas referentes a Sistemas de Informacin. - Mantener la continuidad operativa de los sistemas de informacin ya existentes. - Establecer la normatividad en los Sistemas de Informacin

38

reas que lo integran

Unidad de Desarrollo de Software Unidad de Soporte Tcnico Unidad de Administracin de Servicios de Informacin Unidad de Calidad del Software

RECURSOS
En este captulo veremos las cosas necesarias para realizar alguna tarea: RECURSOS Equipo de Desarrollo.- Director de proyecto, analistas, diseadores y programadores. Soporte de Desarrollo.- Especialista en base de Organizacin o Externas datos, en redes locales y comunicaciones, en interfaces, en informacin, as como Operadores y Administradores. Cliente y Usuario.- Personal de alta direccin, Directores y personal de los departamentos afectados. Salas de reuniones.- En donde usuarios, clientes y desarrolladores realizaran tareas conjuntas. Entorno de desarrollo.- Donde los informticos realizan trabajos individualmente como documentar o programar. Hay que hacer notar que muchos de Desarrolladores las compaas y empleados ms productivos disponen de oficinas silenciosas. Zona par recogida de datos.- Lugares de trabajo de los usuarios y zonas de archivos tanto actuales como
39

futuras. Mobiliario de oficina.- Mesas, sillas, lmparas, telfonos, fax, etc. Material de presentacin.- Proyectores, pantallas, Equipamiento mesas apropiadas, etc. Ordenadores.- Infraestructura de red, estaciones de trabajo, Hardware especifico del sistema de desarrollo, etc. Sistema el desarrollo de Operativo, Lenguajes de desarrollo,

Material Bsico para

Herramienta de desarrollo (CASE). Manual de Software: iniciacin, manual de usuario, software libreras, etc. Libros con referencias a tcnicas de desarrollo. Material de escritorio: Bolgrafos, clips, grapas,

Material Fungible

barras de pegamento, liquido corrector, etc Material para los quipos: Tinta o tner de impresora, papel de impresora, transparencia, disquetes, cinta de back-up, etc.

El haber descrito con tanto detalle algunos de los materiales se debe a que en la prctica se pierde mucho tiempo, de personal de desarrollo, por no estar disponibles cosas que aparentemente tienen poca importancia.

COSTO DEL PROYECTO

En este captulo, despus de haber realizado un anlisis detallado de una planificacin temporal, el diagrama de Gantt y de Red, se ha logrado establecer las diferentes tareas que se realizaran durante todo el proceso de desarrollo, el tiempo necesario para realizar cada una de estas tareas. A partir de todos estos datos, se establecer un valor aproximado del coste de la realizacin del proyecto. 40

Anlisis de Costos
Para ello se toman en cuenta las siguientes consideraciones iniciales: - El proyecto lo va a desarrollar por un equipo de 5 personas con un nivel profesional a ingeniero. - El perodo de desarrollo del proyecto abarca unos 11 meses. 1. Costo Estimado por LDC Datos LDC = 95.000 Esfuerzo ED = 2.4 (LDC) 1.05 Horas-mes ED = 2.4 (95) 1.05 = 239.4 horas-mes Tiempo de Desarrollo TD = 2.5 (ED) 0.38 m TD = 2.5 (239.4) 0.38 = Productividad PR = LDC / ED Ldc/Horas-mes PR = 95000 / 239.4 = 396.83 Calculando el Costo del proyecto Costo por LD = 95 / TD horas 396.83 = 0.234 Bus / LDC Costo del Proyecto = 95000 LDC * 0.234 Bus / DLC = 22230 Bs. 3175 2. Costo Estimado por PF CostoPF = 3000 bs personames / 470 pf persona / mes = 6.38 Bs pf Costo del Proyecto = 495.56 * 5 = 3163 Bs Sueldo Bsico = 300 $us/Mes

41