You are on page 1of 41

UNIVERSIDAD AUTÓNOMA GABRIEL RENÉ MORENO – UNIDAD DE POSTGRADO

PLAN DE ADMINISTRACIÓN DE PROYECTO DE SOFTWARE
GESTIÓN DE FARMACIAS
Luis Alberto Baigorria Rodas
08/08/2011

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

INTRODUCCIÓN
El presente documento constituye un Plan de Administración de Proyecto de Software para la Gestión y Administración de las diferentes actividades realizadas por una cadena de Farmacias, como caso de estudio tenemos FarmaCORP. Se desarrollará la implementación de una aplicación que controle todos los aspectos

relacionados con la gestión de las diferentes actividades de la cadena de farmacia FarmaCORP. La cadena de farmacias FarmaCORP requiere de una rápida instalación 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 administración 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 análisis de la viabilidad, se considere la rápida incorporación y puesta en marcha de un sistema que opere en red y conecte a la oficina central con las diferentes sucursales, ofrecer una atención más rápida 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 administración del proyecto de software, el cual nos permita realizar un análisis de la viabilidad del plan, realizar un análisis de las métricas y estimaciones, posibles riesgos, plan de contingencia, la manera de organizar a nuestro equipo de trabajo, los recursos humanos, los costos asociados a la ejecución del plan y los asociados a los diferentes riesgos.

2

ANTECEDENTES
FarmaCorp nació el 13 de mayo de 1934 en Santa Cruz de la Sierra, Bolivia, bajo el nombre de Gutiérrez, apellido de su fundador el bioquímico Osvaldo Gutiérrez. Este sería administrador de la empresa farmacéutica durante varios años. Su hija mayor, Rosario Gutiérrez, abrió en 1964 otra empresa farmacéutica, la farmacia Santa María, ubicada al frente de la farmacia Gutiérrez. Hace 70 años, Osvaldo Gutiérrez, de profesión bioquímico, abrió la primera farmacia a la que puso por nombre Gutiérrez, y durante mucho tiempo la administró. Don Osvaldo nunca imaginó que aquella iniciativa permanecería por tanto tiempo, pero su hija mayor, Rosario, mirando el espíritu emprendedor del padre, quiso seguir sus pasos y en 1964, con la ayuda de su esposo Lorgio Paz, pusieron en marcha la farmacia Santa María; ubicándola frente a la Gutiérrez. Posteriormente, María René se integró al negocio de su padre y más tarde lo haría su hermana Rosemary que también formó parte del equipo Gutiérrez. Entre tanto, María Eugenia, la menor de las cuatro hermanas se incorporó en el desafío para llevar adelante a la Santa María. Desde esa época, ambas farmacias compartieron liderazgo dentro del departamento. En 1993 fue un año muy importante para la familia Gutiérrez, una de sus empresas daría un salto dentro de lo que es el servicio en el rubro farmacéutico, puesto que con la apertura del segundo punto de venta de la Santa María, nació el concepto de cadena. De esa manera las cuatro hermanas se convirtieron en rivales circunstanciales en sus farmacias, pero sólo en el trabajo porque luego de la jornada, la familia se reunía en largas tardes y noches de charlas y festejos, criando a los hijos y soñando con que la siguiente generación se encargara de seguir con el emprendimiento de los Gutiérrez. Este sueño no tardaría en llegar, puesto que en 1996 se dio la primera incorporación de la tercera generación a una de las farmacias. Rosario, nieta de Osvaldo Gutiérrez, incursionó en el rubro ayudándole a su madre en la administración de farmacia Santa María, y Ximena hija de
3

María René lo hizo en la Gutiérrez. Ambas empresas continuaron creciendo y abriendo sucursales dentro del departamento. Una vez consolidadas las dos farmacias, Santa María y Gutiérrez, y ante la necesidad de encarar nuevos proyectos, nació la idea de fusionarlas para evitar la competencia entre ambas, puesto que pertenecían a la misma familia. La visión y misión estuvo a cargo de los nietos de Osvaldo Gutiérrez, quienes cada uno con sus profesiones distintas, lejos del entorno farmacéutico con el que habían crecido, tomaron la iniciativa de crear la compañía FarmaCorp. Entonces empezó el trabajo y tras la primera reunión, nace el nombre que fue ideado por Chiqui, la más creativa y la que lanza la mayoría de las ideas, indicaron sus primos Ximena y Erwin. Se quedó en que no se miraría para atrás, 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 económicos para la viabilidad de la nueva empresa, mientras que Ximena y Chiqui se encargaban de la organización. La fusión fue un momento histórico para la familia, ya que cada uno de los integrantes recién se dio cuenta de lo mucho que se había logrado hasta entonces. “Recuerdo que el momento de la fusión no costó, lo complicado fue unir recursos humanos y las personas idóneas para desempeñar las funciones”, indicó Erwin. Las gestiones se iniciaron el año 1999 y FarmaCorp empezó a operar un año después, en plena crisis económica. Los jóvenes empresarios, aunque les asustaba el hecho de comparar las ventas de años anteriores y las que se daban en ese momento, siguieron trabajando sin mirar atrás y con el apoyo de sus padres. Fue una etapa muy difícil, explican. En ese tiempo tenían buenas expectativas pero no tenían 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 aplicación que se tiene instalada, en una junta con los directivos de dicha farmacia se ha tomado la decisión 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 Administración de Proyecto de Software. Las farmacias trabajan 24 horas en tres turnos los siete días de la semana. Los turnos de 7:00 a 15:00 y de 15:00 a 23:00 trabajan a puertas abiertas, mientras que el turno nocturno de 23:00 a 7:00 a puerta cerrada a través de ventanilla. En los turnos de puertas abiertas hay al menos 4 vendedores por sucursal. Y se tiene un regente que administra y supervisa las labores. Los pedidos de productos (medicamentos y otros) se formulan cualquier día a la oficina central de acuerdo al control de stock. El punto de reposición es definido por el regente, al igual que la cantidad a pedir. La oficina central consolida el pedido de todas las sucursales, previa verificación de stocks en almacenes y efectúa la solicitud de compra a los proveedores. La reposición y abastecimiento de los productos a las sucursales se realiza todos los días a través de los vehículos que dispone la compañía, sin embargo no logran cubrir las demandas y solicitudes de las sucursales. A modo de captar clientes y fidelizarlos, se tiene un registro de los clientes (compradores) y por cada boliviano de venta a los clientes se considera un punto acumulado. Por lo que los puntos se pueden acumular hasta ser canjeados por el cliente de acuerdo el catalogo de ofertas, en el momento que el cliente lo requiera. Se elabora los catálogos de ofertas que son productos (medicamentos y otros) en promoción, que se ofrecen todos los meses. Son productos de toda índole (cosméticos, de higiene, etc.) entre los que también se consideran aquellos que no se venden o están por caducar. Por otra parte se hacen sorteos para días festivos (día del padre, día de la madre, navidad, etc.) para lo cual el cliente puede acceder a cupones por la compra de productos. Por cada Bs. 100.el cliente tiene derecho a un cupón para dicho concurso. Los premios son variados desde pasajes y vacaciones pagadas, hasta vehículos.
5

OBJETIVOS
Objetivo General
Desarrollar un Sistema de Información para la Gestión y Administración de los productos de la cadena de farmacias FarmaCORP en un entorno Web y centralizado.

Objetivos Específicos
Para alcanzar nuestro objetivo general nos hemos planteado los siguientes objetivos específicos: Identificar y recolectar los requerimientos y/o requisitos que nos puedan brindar toda la información necesaria para el análisis y elaboración del Sistema.

Realizar entrevistas, reuniones con los directivos de la empresa a fin de recabar más información del proceso de registro de los productos, los medicamentes y las forma en la que éstos se encuentran organizados.

Diseñar y modelar los diferentes artefactos de software tomando como base el análisis de requisitos, para lo cual se utilizaran herramientas de diseño del Lenguaje Unificado de Modelado UML. Documentar todos los detalles durante el proceso de construcción del Sistema y en cada una de sus fases. Establecer la estructura organizacional del equipo de trabajo, el número de participantes por equipo y la metodología apropiada para desarrollar el sistema.

Implementar cada uno de los modelos generados durante la fase de diseño en el lenguaje de programación más apropiado.

6

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

Diseñar 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.

Diseñar interfaces visuales amigables para el usuario,

de tal modo que sea

comprensible y fácil de manejar, evitando las posibles complicaciones durante el proceso de gestión de los datos.

ALCANCES
A continuación 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 Catálogos de Oferta Gestionar Puntos Canjeados
7

Gestionar Personal (Oficina Central, Sucursales y Almacenes) Gestionar Asignación 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 Reposición 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á, más adelante, a realizar una descripción más detallada de cada uno de los requerimientos, organizándolos y estableciendo un valor prioritario.

Requerimientos No Funcionales

Al tener una oficina central y operar en red, la solución que proponemos debe ser escalable bajo la estrategia scale-up (Añadir más inicialmente y luego scale-out (Añadir más procesamiento. Si el sistema debe conformar con las normas de estandarización ISO 9000 - 9003. recursos al servidor central)

servidores), según las necesidades de

8

El sistema deber contemplar alta disponibilidad y estabilidad ya que operará las 24 horas del día. 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 producción deberá ser sometido a una serie de técnicas 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 continuación detallamos las diferentes técnicas que se podrá utilizar para las pruebas de rendimientos: Prueba de estrés Esta prueba se utilizará con el fin de romper la aplicación. Se va doblando el número de usuarios que se agregan a la aplicación y se ejecuta una prueba de carga hasta que se rompe. Este tipo de prueba se realiza para determinar la solidez de la aplicación en los momentos de carga extrema y ayuda a los administradores para determinar si la aplicación rendirá lo suficiente en caso de que la carga real supere a la carga esperada. Prueba de estabilidad (soak testing) Esta prueba se realizará cuándo sea necesario determinar si la aplicación puede aguantar una carga esperada continuada. Pruebas de picos (spike testing) La prueba de picos, trata de observar el comportamiento del sistema variando el número de usuarios, tanto cuando bajan, como cuando tiene cambios drásticos en su carga.

9

Pre-requisitos para las pruebas de carga Es aconsejable, para realizar la prueba de carga disponer de un entorno de pruebas de rendimiento lo más parecido como se pueda al entorno de producción, y no así con pruebas de aceptación 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 críticos: El sistema opere en red conectando a todas las sucursales con la oficina central y las oficinas. Plataforma de desarrollo ASPX. Sistemas seguros: protección de información, seguridad en las trasmisiones de datos. Durante el horario de atención. 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 automatización de la gestión interna del registro de los medicamentos debe ajustarse a la legislación vigente y considerar la previsión de nuevas legislaciones. c) El subsistema de Gestión de Almacenes se deberá diseñar como un módulo 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

MÉTRICAS
El objetivo principal en este paso es determinar el tiempo necesario para terminar el proyecto de software y cuál 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 compañeros de la universidad en proyectos desarrollados en entorno Web, con los lenguaje de programación, ASP, PHP y JSP, es decir la experiencia en desarrollo de los proyectos es académica. Estos datos servirán como base para realizar las métricas necesarias para el proyecto requerido. A partir de los resultados obtenidos en el análisis de los datos, se procederá a realizar la métrica 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 Información para el seguimiento del historial oftalmológico, gestionar consulta y reserva vía Web para la “Clínica de Ojos”. (ASPX-Tecnología .NET)

11

Proyecto B: Sistema de Información para Gestionar el proceso de Inscripción, obtención de notas, Registro y Control de Pago de Pensiones para la Unidad Educativa Privada “Santa Cecilia”. Proyecto C: Sistemas para Gestionar Envíos de Campanias Publicitarias desde un enfoque de Social CRM (Desarrollado en PHP) Proyecto D: Sistema de Información para gestionar compra y venta de medicamentos para la Farmacia “Santa Juan” Para los cálculos de Calidad y Productividad se aplicó la siguiente fórmula:
Calidad = (Errores / KLDC) Productividad = (KLDC / Persona-Mes) Documentación = Pag. Doc/KLDC

CALCULO DE LA CALIDAD Y PRODUCTIVIDAD DE LOS DATOS HISTÓRICOS

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 estadísticos se buscará valores supuestos para cada uno de los campos solicitados, cada uno de estos valores nos permitirá realizar la métricas apropiadas para nuestro proyecto, como ser: Métricas Orientadas al Tamaño (MOT) y Métricas Orientada a la Función (MOF).

Métrica Orientada al Tamaño
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

Análisis. 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 número 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 (Presentación, Negocio y Datos) entonces se habrán creado 80 clases, supongamos que existen 15 clases más de ayuda para la realización de algunos requerimientos, entonces tenemos 95 clases, si cada clase tiene como máximo 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 métricas de productividad y calidad orientadas al tamaño, de acuerdo a las siguientes fórmulas: 1. Calidad = (Errores / KLDC) 2. Productividad = (KLDC / Persona-Mes) * 1000 3. Documentación = Pagina. Documento / KLDC 4. Costo = $us / KLDC Calidad = 80 / 95 = 0.84 Productividad = (95 / 30) * 1000 = 3166.6666 Documentación = 5150/ 95 = 54 Costo = 3000 / 95000

Métrica Orientada a la Función
Al igual como se realizó en las Métricas Orientadas a la Función, 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 servirán como muestras estadísticas, 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 análisis para elaboración de nuestro Plan de Administración de Proyecto de Software.

Datos Estadísticos de Proyectos
Proyecto A:

Factor de Ponderación
Parámetros de Medición Cuenta Simple Medio Complejo Elección Sumatoria

14

Número de Entradas de Usuario Numero de Salidas de Usuario Número 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

Medición del Proyecto A según 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 recuperación fiables? 2. ¿Se requiere comunicación de datos? 3. ¿Existen funciones de procesamiento distribuido? 4. ¿Es crítico 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 múltiples 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

2

4

9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones? 10. ¿Es complejo el procesamiento interno? 11. ¿Se ha diseñado el código para ser reutilizable? 12. ¿Están incluidas en el diseño la conversión y la instalación'? 13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones? 14. ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario? 0

1 5 1

1 5 1 0 2 2

5

5

TOTAL
Medición del Proyecto A según las métricas orientadas a la función
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 Ponderación
Parámetros de Medición Número de Entradas de usuario Número de Salidas de Usuario Número de peticiones de Usuario Número de archivos Número 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

Medición del Proyecto B según 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 recuperación fiables? 2. ¿Se requiere comunicación 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 crítico 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 múltiples 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 diseñado el código para ser reutilizable? 12. ¿Están incluidas en el diseño la conversión y la instalación'? 13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?

0

3 3 5 5 5 0

14. ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?

0

0

TOTAL

42

Medición del Proyecto B según las métricas orientadas a la función
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 Ponderación
Parámetros de Medición Número de Entradas de usuario Número de Salidas de Usuario Número 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

Medición del Proyecto C según 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 recuperación fiables? 2. ¿Se requiere comunicación 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 crítico 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 múltiples 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 diseñado el código para ser reutilizable? 12. ¿Están incluidas en el diseño la conversión y la instalación'? 13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?

0

1 2 3 2 4 0

14. ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?

0

0

TOTAL
Medición del Proyecto A según las métricas orientadas a la función
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
Métricas Orientadas a la Función aplicado al Proyecto
El siguiente cuadro muestra datos supuestos para el cálculo de la Cuenta Total aplicado al proyecto. Son datos supuestos sacados de la experiencia en los proyectos trabajados con anterioridad. Proyecto FarmaCORP:

Factor de Ponderación
Parámetros de Medición Número de Entradas de usuario Número de Salidas de Usuario Número 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

Medición del Proyecto según 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 recuperación fiables? 2. ¿Se requiere comunicación 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 crítico 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 múltiples 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 diseñado el código para ser reutilizable? 12. ¿Están incluidas en el diseño la conversión y la instalación'? 13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones? 14. ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?

5 4 2

0

1 2 3 2 4 0

0

TOTAL

31
21

Cálculo de las Métricas Orientada a la Función
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 estimación del coste y del esfuerzo del software nunca será una ciencia exacta. Son demasiadas las variables humanas, técnicas, de entorno, políticas, etc. que pueden afectar al costo final del software y al esfuerzo aplicado para desarrollarlo. Por consiguiente, los siguientes cálculos están basados en modelos empíricos, el modelo COCOMO.

Estimación de LDC (Líneas de Códico)

En esta siguiente actividad vamos a la estimación del coste y del esfuerzo del software nunca será una ciencia exacta. Son demasiadas las variables —humanas, técnicas, de entorno, políticas— que pueden afectar al coste final del software y al esfuerzo aplicado para desarrollarlo. Sin embargo, la estimación del proyecto de software puede dejar de ser un oscuro arte para convertirse en una serie de pasos sistemáticos 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 estimación, E, se obtiene como una media ponderada de las estimaciones LDC ó PF optimista (a), más probable (m) y pesimista (c). Por ejemplo:

22

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

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

Tabla de estimación por LDC Función Optimista (LDC) UI GBD RA ED CP MR Total 1800 2200 1600 1300 1900 1400 Más probable (LDC) 2500 2400 1700 1500 2100 1600 Pésimo (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 revisión histórica 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 jerarquía de modelos de estimación para el software. Las ecuaciones del modelo COCOMO básico 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 Orgánico 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 estimación de esfuerzo para 11964 LDC aplicando el Modelo COCOMO básico y usando un tipo de proyecto orgánico:

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 Análisis de los resultados Obtenidos
Al igual que se realizó en las Métricas, los datos de las tablas correspondiente para la estimación 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 análisis aproximado para determinar las LDC y a partir de esos datos estimar el esfuerzo, tiempo y costo de la realización del Proyecto. Si bien esos datos no son 100% exactos, en cuanto a las líneas de código 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.

ANÁLISIS DE RIESGO
Alcance y propósito 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 daño que causará si dichos riesgos ocurren. Realizar una clasificación de los riesgos según su probabilidad de ocurrencia y el impacto que pudiesen causar. El propósito es desarrollar un plan de para determinar que acciones tomar frente a aquellos riesgos con gran probabilidad de que ocurran.

25

La organización debe estar comprometida a tratar la gestión 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 Aversión Impacto Reducir Probabilidad
-Realizar periódicamente copias de las aplicaciones en desarrollo. -Contar con antivirus actualizados en todos los equipos. -Realizar Mantenimiento de equipos de hardware periódicamente.

Riesgo

Reducir Impacto

R1: Pérdida de información, ya sea por motivos técnicos, infección 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 información con la que se esté trabajando en el software en otros dispositivos o maquinas. -Trabajar con estrategias empleadas previamente. - Capacitar periódicamente al personal en nuevas

- Adquirir equipos y/o Accesorios Informáticos con garantía.

R3: Estrategia de

-Trabajar de manera organizada y minuciosamente, empleando toda la documentación posible

26

desarrollo desconocido.

20

M

tecnologías.

acerca de la estrategia a utilizar.

R4: Herramienta de desarrollo desconocida.

-Trabajar con herramientas empleadas previamente. 20 SG - Capacitar periódicamente al personal. -En el momento de realizar la planificación 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 estimación bien detallado y con datos lo más aproximadamente posibles al proyecto. -Elaborar varios métodos de estimación del software.

-Buscar información y ayuda en el manejo de la misma.

R5: Mala estimación de tiempo debido a no contemplar actividades ajenas al proyecto.

70

CR

-Contemplar dentro de la planificación de tiempo un tiempo de demora u holgura asumiendo cualquier tipo de eventualidad.

R6: Mala estimación de costo.

60

CR

-Realizar un informe detallado del costo real del software.

R7: Mala estimación de esfuerzo.

50

M

-Aumentar el personal asignado al desarrollo del software. -Solucionar los problemas de comunicación.

-Realizar actividades para incentivar la buena comunicación entre compañeros. -Especificar las tareas que debe realizar cada desarrollador detallando las fechas de presentación. -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 comunicación entre los desarrolladores. 75 SG

-Explicar a las personas que hayan malinterpretado las tareas que deberían 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 hacían 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 planificación. -Informar al equipo de desarrollo de los cambios en la planificación 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 través de dinámicas de trabajo

No distribuir de manera critica el trabajo

Reducción y Supervisión de los riesgos (RSGR)
Anteriormente se identifico una lista de 10 posibles riesgos que se podrían presentar durante el proceso de desarrollo del Software, así también se describió como se los podría reducir y supervisar. En cada uno de los posibles riesgos identificados se describió y detallo un Plan de Aversión, reduciendo así la probabilidad y el impacto.

PLANIFICACIÓN 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 realización del proyecto, en esta fase se realizará un plan que permita la entrega del producto en los límites establecidos, para ello realizaremos la identificación de las diferentes tareas a realizar, la distribución del esfuerzo necesario, cálculo 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

Identificación de Tareas
A continuación, 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 Aplicación Abarca todo el proceso de desarrollo del proyecto, análisis, diseño, implementación, depuración y pruebas de la aplicación. 1. Entrevistas con el Cliente 2. Entrega de una propuesta inicial 3. Captura de Requerimientos 4. Seleccionar Miembros del Equipo 5. Análisis de Requerimientos 6. Análisis del Software 7. Diseño del Software 8. Implementar la aplicación 9. Integración de los módulos 10. Pruebas Iniciales 11. Depuración de la Aplicación Fase 2: Pruebas Finales Esta fase abarca el proceso de pruebas finales, es decir, aún se haya realizado pruebas iniciales durante el proceso de desarrollo de la aplicación, con la finalidad de comprobar que todo funcionaba correctamente y el producto estaba listo para la entrega. 1. Fijar Calendario de Prueba 2. Aplicar Técnicas de Prueba 3. Aplicar pruebas de Rendimiento Fase 3: Documentación

29

Esta fase abarca todo el proceso de documentar el software, la investigación de diferentes tecnologías que no se tenga conocimiento, investigación de herramientas, capacitación para los estándares de documentación. Describe todas las tareas necesarias para la elaboración de la documentación. 1. Aplicación del Calendario de Entrega Final 2. Elaboración de Manuales de Uso y de Ayuda 3. Videos de Ayuda 4. Entrenamiento

Distribución del Esfuerzo
La distribución del esfuerzo se lo realizará de la siguiente manera en cada una de las fases identificadas anteriormente. Fase 1: Proceso de Desarrollo de la Aplicación

En esta fase la distribución del esfuerzo será la de: 40 20 40, que establece lo siguiente: 40% del esfuerzo será distribuido para el Análisis y Diseño. 20% del esfuerzo será distribuido para la codificación, es decir para la implementación (Generación de Código) 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 distribución del esfuerzo será distribuido de la siguiente forma: 20 % del esfuerzo será para la implementación 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 serán las que determinarán en correcto funcionamiento del producto. Este equipo construirá las pruebas necesarias a realizar, serán 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: Documentación
En esta fase se utilizará el 100% del esfuerzo.

Cálculo del Selector de Tarea
Proceso del cálculo del selector de Tarea. Multiplicador Criterios de adaptación 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

Tamaño del proyecto Número de usuarios Importancia para el negocio Longevidad de la aplicación Estabilidad de los requisitos Facilidad de comunicación Madurez de la tecnología aplicable Limitaciones de rendimiento Empotrado/no empotrado Personal del proyecto Interoperabilidad Factores de reingeniería

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

4

0.90

1

1

0

0

1

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 Análisis de Requerimientos Análisis del Software Diseño del Software Implementar la aplicación Integración de los módulos Pruebas Iniciales Depuración de la Aplicación Fijar Calendario de Prueba Aplicar Técnicas de Prueba Aplicar pruebas de Rendimiento Calendario de Entrega Final Elaboración 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 Análisis de Requerimientos Análisis del Software Diseño del Software Implementar la aplicación Integración de los módulos Pruebas Iniciales Depuración de la Aplicación Calendario de entregas finales Fijar Calendario de Prueba Aplicar Técnicas de Prueba Finales Aplicar pruebas de Rendimiento Elaboración 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

ORGANIZACIÓN 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 posición comercial el negocio. Supervisión 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 básicas

consultar y decisiones que debe consultar al superior: Autónomo.

Nombre del Cargo Relaciones internas Relaciones externas

Objetivo del cargo

Programador Analista Diseñador 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 propósito de ser solucionado mediante un sistema de información. Crea la parte artística o visual de un sitio y la estructura que tendrá la página o software. El diseño se planifica en base al objetivo y luego se desarrolla teniendo en cuenta la navegabilidad, interactividad. Usabilidad y arquitectura de la información. Decisiones que puede tomar sin consultar y decisiones que debe consultar al superior: Autónomo.

Responsabilidades básicas

36

Nombre del Cargo Relaciones internas Relaciones externas Objetivo del cargo

Responsabilidades básicas

Secretaria Jefe de Proyecto n/a - Ser puntual en todas sus actividades de funciones. - Reclutar las solicitudes de servicios. - Hacer una evaluación periódica 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 discreción 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 telefónicas para tener informado a los jefes de los compromisos y demás 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, además de acompañar 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 autorización al Jefe de Proyecto.

37

Justificación
La empresa XXXXX, debe cumplir con los objetivos de acuerdo a como lo establece la ley orgánica además de que debe de soportar la información que debe de proporcionar a terceros como son los Gobiernos, congreso del estado, y demás por ser esta una obligación de toda institución pública. Para lograr lo anterior, se apoya a través de sistemas integrados y personalizados a sus necesidades, estos sistemas de información son elaborados por el Departamento de Sistemas de Información.

Objetivo
El Departamento de Sistemas de Información es un área de apoyo de vanguardia en la elaboración de proyectos informáticos a ser una institución proactiva en cuanto a la modernización de sus procesos administrativos, en la explotación de la información generada en pro del conocimiento, la toma de decisiones y el crecimiento de la Institución.

Misión
Proporcionar a los clientes, en este caso FARMACORP. , que le permitan la toma de decisiones de manera oportuna, eficiente y consistente a través de un sistema de información integral.

Funciones
El Departamento de Sistemas de Información tiene como función principal: proporcionar a la empresa XXXXX elementos tecnológicos que le permitan cumplir con sus responsabilidades en cuanto a la gestión y a la toma de decisiones. Estos elementos tecnológicos se traducen a Sistemas de Información que permiten a todos los niveles de la organización poder acceder a la información generada. - Integrar soluciones de Sistemas de Información. - Presentar propuestas de actualización de nuevas Tecnologías referentes a Sistemas de Información. - Mantener la continuidad operativa de los sistemas de información ya existentes. - Establecer la normatividad en los Sistemas de Información

38

Áreas que lo integran

Unidad de Desarrollo de Software Unidad de Soporte Técnico Unidad de Administración de Servicios de Información Unidad de Calidad del Software

RECURSOS
En este capítulo veremos las cosas necesarias para realizar alguna tarea: RECURSOS Equipo de Desarrollo.- Director de proyecto, analistas, diseñadores y programadores. Soporte de Desarrollo.- Especialista en base de Organización o Externas datos, en redes locales y comunicaciones, en interfaces, en información, así como Operadores y Administradores. Cliente y Usuario.- Personal de alta dirección, Directores y personal de los departamentos afectados. Salas de reuniones.- En donde usuarios, clientes y desarrolladores realizaran tareas conjuntas. Entorno de desarrollo.- Donde los informáticos realizan trabajos individualmente como documentar o programar. Hay que hacer notar que muchos de Desarrolladores las compañías y empleados más 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, lámparas, teléfonos, fax, etc. Material de presentación.- 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 Básico para

Herramienta de desarrollo (CASE). Manual de Software: iniciación, manual de usuario, software librerías, etc. Libros con referencias a técnicas de desarrollo. Material de escritorio: Bolígrafos, clips, grapas,

Material Fungible

barras de pegamento, liquido corrector, etc Material para los quipos: Tinta o tóner 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 práctica se pierde mucho tiempo, de personal de desarrollo, por no estar disponibles cosas que aparentemente tienen poca importancia.

COSTO DEL PROYECTO
En este capítulo, después de haber realizado un análisis detallado de una planificación 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 realización del proyecto. 40

Análisis 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 período 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 Básico = 300 $us/Mes

41