paps - plan de administración de proyecto de software

5/9/2018 PAPS - Plan de Administraci n de Proyecto de Software - slidepdf.com

http://slidepdf.com/reader/full/paps-plan-de-administracion-de-proyecto-de-software

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

PLAN DE ADMINISTRACIÓN DEPROYECTO 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 deProyecto de Software para la Gestión y Administración de las diferentes actividades realizadaspor la cadena de Farmacias FarmaCorp.



2

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



3

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 dela 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 seguircon 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



4

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.



5

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.



6

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.



7

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 requerimientosdel 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 setiene 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



8

Gestionar Personal (Oficina Central, Sucursales y Almacenes)

Gestionar Asignación de Turnos

Gestionar Permisos

Gestionar VacacionesGestionar 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 escenarioactual 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 recursos al servidor central)

inicialmente y luego scale-out (Añadir más servidores), según las necesidades de

procesamiento.

Si el sistema debe conformar con las normas de estandarización ISO 9000 - 9003.



9

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.



10

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.



11

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 GENTE ESFUERZOCOSTO

$us KLDCPAG.DOC. ERRORES LENGUAJE TIEMPO

A 4 16 350 9.15 130 30 ASP 4

B 5 15 450 5.5 200 20 JSP 3

C 2 10 600 12.6 180 15 PHP 5

D 4 16 700 10.5 150 17 ASP 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)



12

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



13

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

PROYECTO GENTE ESFUERZOCOSTO

$usKLDC

PAG.DOC.

ERRORES LENGUAJE TIEMPO

A 4 16 350 9.15 130 30 ASP 4

B 5 15 450 5.5 200 20 JSP 3

C 2 10 600 12.6 180 15 PHP 5

D 4 16 700 10.5 150 17 ASP 4

SISTEMAFARMACORP

5 30 3000 95.0 5150 40 PHP 6

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.



14

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 deMedición

Cuenta Simple Medio Complejo Elección Sumatoria



15

Número de Entradas deUsuario

23 3 4 6 3 69

Numero de Salidas deUsuario

6 4 5 7 5 30

Número de peticiones

de Usuario

4 3 4 6 3 12

Numero de archivos 2 7 10 15 7 14

Numero de interfacesexternas

1 5 7 10 7 7

CTOTAL 132

Medición del Proyecto A según el factor de peso

PREGUNTAS

0 , N O I N C L U Y E

1 , I N C I D E N T A L

2 , M O D E R A D O

3 , M E D I O

4 , S I G N I F I C A T I V O

5 , E S E N C I A L

S U M A

1. ¿Requiere el sistema copias de seguridad

y de recuperación fiables? 0 0

2. ¿Se requiere comunicación de datos? 5 5

3. ¿Existen funciones de procesamientodistribuido?

0 0

4. ¿Es crítico el rendimiento? 5 5

5. ¿Se ejecutara el sistema en un entornooperativo existente y fuertementeutilizado?

5 5

6. ¿Requiere el sistema entrada de datosinteractiva? 4 4

7. ¿Requiere la entrada de datos interactivaque las transacciones de entrada se llevena cabo sobre múltiples pantallas uoperaciones?

2 2

8. ¿Se actualizan los archivos maestros deforma interactiva?

4 4



16

9. ¿Son complejas las entradas, las salidas,los archivos o las peticiones?

1 1

10. ¿Es complejo el procesamiento interno? 5 5

11. ¿Se ha diseñado el código para serreutilizable?

1 1

12. ¿Están incluidas en el diseño laconversión y la instalación'?

0 0

13. ¿Se ha diseñado el sistema parasoportar múltiples instalaciones endiferentes organizaciones?

2 2

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

5 5

TOTAL 39

Medición del Proyecto A según las métricas orientadas a la función

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

PF = 132 * [0.65 + 0.01 * 39]

PF = 137.28

Proyecto B:



Cuenta Simple Medio Complejo ELECCION Sumatoria

Número de Entradasde usuario

40 3 4 6 4 160

Número de Salidas de

Usuario 8 4 5 7 5 40

Número de peticionesde Usuario

30 3 4 6 4 120

Número de archivos 30 7 10 15 10 300

Número de interfacesexternas

1 5 7 10 7 7

14

1i

fi



17

CTOTAL 627

Medición del Proyecto B según el factor de peso

PREGUNTAS



2 , M O D E R A D O

3 , M E D I O


5 , E S E N C I A L

S U M A

1. ¿Requiere el sistema copias deseguridad y de recuperación fiables? 4 4

2. ¿Se requiere comunicación de datos?4 4

3. ¿Existen funciones de procesamientodistribuido? 0 0


5. ¿Se ejecutará el sistema en un entornooperativo existente y fuertementeutilizado?

5 5

6. ¿Requiere el sistema entrada de datosinteractiva? 3 3

7. ¿Requiere la entrada de datosinteractiva que las transacciones deentrada se lleven a cabo sobre múltiplespantallas u operaciones?

0 0

8. ¿Se actualizan los archivos maestros deforma interactiva? 3 3

9. ¿Son complejas las entradas, las salidas,los archivos o las peticiones? 3 3

10. ¿Es complejo el procesamientointerno?

5 5

11. ¿Se ha diseñado el código para serreutilizable? 5 5

12. ¿Están incluidas en el diseño laconversión y la instalación'? 5 5


0 0



18


0 0

TOTAL 42

Medición del Proyecto B según las métricas orientadas a la función

Entonces calculando el PF tenemos:

PF = CTotal * [0.65 + 0.01 * ]

PF = 627 * [0.65 + 0.01 * 42]

PF = 251.49

Proyecto C:



Cuenta Simple Medio Complejo ELECCION Sumatoria

Número de Entradasde usuario

40 3 4 6 4 160

Número de Salidasde Usuario

35 4 5 7 5 175

Número depeticiones deUsuario

5 3 4 6 3 15

Numero de archivos 21 7 10 15 10 210

Numero deinterfaces externas

5 5 7 10 5 25

CTOTAL 585

14

1i

fi



19

Medición del Proyecto C según el Factor de Peso

PREGUNTAS



2 , M O D E R A D O

3 , M E D I O


5 , E S E N C I A L

S U M A

1. ¿Requiere el sistema copias de

seguridad y de recuperación fiables?

5 5


3. ¿Existen funciones de procesamientodistribuido?

0 0



4 4

6. ¿Requiere el sistema entrada de datos

interactiva?

2 2


0 0


1 1


2 2


3 3


2 2


4 4


0 0



20


0 0

TOTAL 29

Medición del Proyecto A según las métricas orientadas a la función

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

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:



Cuenta Simple Medio Complejo Sumatoria

Número deEntradas de

usuario130 3 4 6 143

Número de Salidasde Usuario

145 4 5 7 161

Número de

peticiones deUsuario

60 3 4 6 73

Numero dearchivos

80 7 10 15 112

Numero deinterfaces externas

5 5 7 10 27

CTOTAL 516

14

1i

fi



21

Medición del Proyecto según el Factor de Peso

PREGUNTAS

0 , N O I N C L

U Y E

1 , I N C I D E N

T A L

2 , M O D E R A D O

3 , M E D I O

4 , S I G N I F I C A

T I V O

5 , E S E N C I A L

S U M A

1. ¿Requiere el sistema copias deseguridad y de recuperación fiables?

5 5


3. ¿Existen funciones de procesamiento

distribuido?

0 0



4 4

6. ¿Requiere el sistema entrada de datosinteractiva?

2 2


0 0


1 1


2 2


3 3


2 2


4 4


0 0


0 0

TOTAL 31



22

Cálculo de las Métricas Orientada a la Función

Entonces calculando el PF tenemos:

PF = CTotal * [0.65 + 0.01 * ]

PF = 516 * [0.65 + 0.01 * 31]

PF = 495.36

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:

14

1i fi



23

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)

Más probable

(LDC)

Pésimo

(LDC)

Valor Esperado

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

UI 1800 2500 3600 2566

GBD 2200 2400 2500 2383

RA 1600 1700 2000 1733

ED 1300 1500 2100 1566

CP 1900 2100 2300 2100

MR 1400 1600 1900 1616

Total 11964



24

Calculado: 11964 LDC esperado y una revisión histórica nos da:

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 a b c d

Orgánico 2.4 1.05 2.5 0.38

Semiacoplado 3.0 1.12 2.5 0.35

Empotrado 3.6 1.20 2.5 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:

LDC Estimada 11964 LDC

Tarifa Laboral 3000 $/Mes

Coste LDC 7 $

Productividad 600 LDC/Persona-Mes

PM (Esfuerzo) LDC/Productividad 11964/600 = 20PM



25

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.



26

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

Riesgo %

P r o b a b i l i d a d

I m p a c t o

Plan de Aversión

Reducir Probabilidad Reducir Impacto

R1: Pérdida de

información, ya sea por

motivos técnicos,

infección de virus, etc. 30 CR

-Realizar periódicamente

copias de las aplicaciones en

desarrollo.

-Contar con antivirus

actualizados en todos los

equipos.

- Usar diferentes

dispositivos de

almacenamiento (CD, Pen

Drive, etc) que sean

seguros, de buena

calidad, etc.

R2: Fallas de hardware o

software. 40 SG

-Realizar Mantenimiento de

equipos de hardware

periódicamente.

-Almacenar la información

con la que se esté

trabajando en el software

en otros dispositivos omaquinas.

- Adquirir equipos y/o

Accesorios Informáticos

con garantía.

R3: Estrategia de

-Trabajar con estrategias

empleadas previamente.

- Capacitar periódicamente

al personal en nuevas

-Trabajar de manera

organizada y

minuciosamente,

empleando toda la

documentación posible



27

desarrollo desconocido. 20 M tecnologías. acerca de la estrategia a

utilizar.

R4: Herramienta de

desarrollo desconocida. 20 SG

-Trabajar con herramientas

empleadas previamente.

- Capacitar periódicamenteal personal.

-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

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

-Contemplar dentro de la

planificación de tiempo un

tiempo de demora u

holgura asumiendo

cualquier tipo de

eventualidad.


costo.60 CR

-Elaborar un plan deestimación bien detallado y

con datos lo más

aproximadamente posibles

al proyecto.

-Realizar un informe

detallado del costo real del

software.


esfuerzo.50 M

-Elaborar varios métodos de

estimación del software.

-Aumentar el personal

asignado al desarrollo del

software.

R8: Problemas de

comunicación entre los

desarrolladores.75 SG

-Realizar actividades para

incentivar la buenacomunicació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 deldesarrollador en cada etapa

del desarrollo del proyecto.

-Solucionar los problemas

de comunicación.

-Explicar a las personas

que hayan malinterpretado

las tareas que deberían

realizar para que locorrijan.



28

R9: Cambio de Requisitos. 50 CR

-Realizar una captura de

requerimientos minuciosa

sobre las funciones que

tiene que realizar elsoftware 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 demantener 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

60 SG

-Firmar Contrato de

trabajo con los integrantes

del equipo

-Motivar a los integrantesdel 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.



29

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 Prueba2. Aplicar Técnicas de Prueba

3. Aplicar pruebas de Rendimiento

Fase 3: Documentación



30

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 Final2. 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 identificadasanteriormente.

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.



31

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.

Criterios de adaptación Grado Peso

Multiplicador

SubtotalDesarr.Concep.

Nvo.Desarr.

Mejoras Mtto Reing.

Tamaño del proyecto 3 1.20 0 1 1 1 1 3.6

Número de usuarios 5 1.10 0 1 1 1 1 5.5

Importancia para el negocio 4 1.10 0 1 1 1 1 4.4

Longevidad de la aplicación 3 0.90 0 1 1 0 0 2.7

Estabilidad de los requisitos 3 1.20 0 1 1 1 1 3.6

Facilidad de comunicación 3 0.90 1 1 1 1 1 2.7

Madurez de la tecnologíaaplicable

4 0.90 1 1 0 0 1 4.6

Limitaciones de rendimiento 2 0.80 0 1 1 0 1 1.6

Empotrado/no empotrado 3 1.20 1 1 1 0 1 3.6

Personal del proyecto 3 1.00 1 1 1 1 1 3.0

Interoperabilidad 4 1.10 0 1 1 1 1 4.4

Factores de reingeniería 2 1.20 0 0 0 0 1 2.4

Selector de conjuntos de tareas (TSS) 3.50



32

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

Valor del TSS Grado de rigor

TSS < 1.2 Informal1.0 < TSS < 3.0 Estructurado

TSS > 2.4 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ónIntegració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 AyudaEntrenamiento



Diagrama de Gantt



Diagrama de Red

Clave Tarea Tiempo (d) Antecesor(es)

AEntrevistas con el Cliente

6

BEntrega de una propuesta inicial

4 A

CCaptura de Requerimientos

15 B

DSeleccionar Miembros del Equipo

16 C

E Análisis de Requerimientos 20 C, D

FAnálisis del Software

46 E

GDiseño del Software

40 E, F

HImplementar la aplicación

40 G, F, E

IIntegración de los módulos

10 H, E, F, G

JPruebas Iniciales

30 I

KDepuración de la Aplicación

32 J

L Calendario de entregas finales 3

MFijar Calendario de Prueba

7 L

N

Aplicar Técnicas de Prueba Finales

5 J

OAplicar pruebas de Rendimiento

3 N

PElaboración de Manuales de Uso y de Ayuda

8 O



35

Clave Tarea Tiempo (d) Antecesor(es)

Q Videos de Ayuda

6 P

R

Calendario de Entrega Final

6 P

ORGANIZACIÓN INTERNA

CARGOS

Nombre del Cargo Jefe de Proyecto.

Relaciones internas Jefe de Proyecto.

Relaciones externas Con los clientes, encargado de negociary cumplir con los requisitos quesoliciten.

Objetivo del cargo Dirigir y mantener en una buenaposición comercial el negocio.

Responsabilidades básicas Supervisión de las tares, Tener

claro su propio trabajo, Desarrollar unplan para alcanzar susobjetivos, Asignar tareas, Establecermecanismos de control,Evaluar la efectividad, Hacerseresponsables de su propiatarea, y de la de sus subordinadosDecisiones que puede tomar sin



36

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

Nombre del Cargo Programador Analista Diseñador

Relaciones internas Jefe de Proyecto.

Relaciones externas Con los clientes, el encargado detomar nota de los requerimientos yanalizarlos para realizar un

buen desarrollo.Objetivo del cargo Tiene como cometido analizar un

problema y describirlo con el propósitode ser solucionado mediante unsistema de información. Crea la parte artística o visual de unsitio y la estructura que tendrá lapágina o software. El diseño se planificaen base al objetivo y luego se desarrollateniendo en cuenta la navegabilidad,

interactividad.Usabilidad y arquitectura de lainformación.

Responsabilidades básicas Decisiones que puede tomar sinconsultar y decisiones que debeconsultar al superior: Autónomo.



37

Nombre del Cargo Secretaria

Relaciones internas Jefe de Proyecto

Relaciones externas n/a

Objetivo del cargo - Ser puntual en todas susactividades de funciones.- Reclutar las solicitudes deservicios.- Hacer una evaluación periódicade los proveedores para verificar elcumplimiento y servicios de éstos.- Recibir e informar asuntos quetenga que ver con eldepartamento correspondiente,

para que todos estemosinformados y desarrollar bien eltrabajo asignado.- Mantener discreción sobre todolo que respecta a la empresa.- Evitar hacer comentariosinnecesarios sobre cualquierfuncionario o departamentosdentro de la empresa.- Hacer y recibir llamadastelefónicas para tener informado alos jefes de los compromisos ydemás asuntos.- Obedecer y realizar instruccionesque te sean asignadas por tú jefe.- Mejora y aprendizaje continuo.

Responsabilidades básicas Brindar a su jefe un apoyoincondicionalcon las tareas establecidas, ademásde acompañar en la vigilancia delos procesos a seguir dentro de la

empresa.Decisiones que puede tomar sinconsultar y decisiones que debeconsultar al superior:Siempre debe informar y solicitarautorización al Jefe de Proyecto.



38

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óngenerada 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.

FuncionesEl 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



39

Á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

O r g a n i z a c i ó

n o E x t e r n a s

Equipo de Desarrollo.- Director de proyecto,

analistas, diseñadores y programadores.

Soporte de Desarrollo.- Especialista en base de

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.

D e s a r r o l l a d o r e s

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

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



40

futuras.

E q u i p a m i e n t o

Mobiliario de oficina.- Mesas, sillas, lámparas,

teléfonos, fax, etc.

Material de presentación.- Proyectores, pantallas,mesas apropiadas, etc.

Ordenadores.- Infraestructura de red, estaciones de

trabajo, Hardware especifico del sistema de

desarrollo, etc.

M a t e r i a l B á s i c o p a r a

e l d e s a r r o l l o

d e

s o f t w a r e

Sistema Operativo, Lenguajes de desarrollo,

Herramienta de desarrollo (CASE).

Manual de Software: iniciación, manual de usuario,librerías, etc.

Libros con referencias a técnicas de desarrollo.

M a t e r i a l F u n g i b l e

Material de escritorio: Bolígrafos, clips, grapas,

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.



41

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 Sueldo Básico = 300 $us/Mes

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

paps - plan de administración de proyecto de software

Documents