Date post: | 08-Jul-2015 |
Category: |
Documents |
Upload: | luis-alberto |
View: | 8,379 times |
Download: | 3 times |
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.
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
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.
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
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
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
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/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
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.
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
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.
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
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
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
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.
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
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.
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
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.
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
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)
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
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
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
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.
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
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
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
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
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
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:
Factor de Ponderación
Parámetros deMedición
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
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
17
CTOTAL 627
Medición del Proyecto B 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? 4 4
2. ¿Se requiere comunicación de datos?4 4
3. ¿Existen funciones de procesamientodistribuido? 0 0
4. ¿Es crítico el rendimiento? 5 5
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
13. ¿Se ha diseñado el sistema parasoportar múltiples instalaciones endiferentes organizaciones?
0 0
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
18
14. ¿Se ha diseñado la aplicación parafacilitar los cambios y para ser fácilmenteutilizada 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:
PF = CTotal * [0.65 + 0.01 * ]
PF = 627 * [0.65 + 0.01 * 42]
PF = 251.49
Proyecto C:
Factor de Ponderación
Parámetros deMedición
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
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
19
Medición del Proyecto C 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?
5 5
2. ¿Se requiere comunicación de datos? 3 3
3. ¿Existen funciones de procesamientodistribuido?
0 0
4. ¿Es crítico el rendimiento? 3 3
5. ¿Se ejecutará el sistema en un entornooperativo existente y fuertementeutilizado?
4 4
6. ¿Requiere el sistema entrada de datos
interactiva?
2 2
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?
1 1
9. ¿Son complejas las entradas, las salidas,los archivos o las peticiones?
2 2
10. ¿Es complejo el procesamientointerno?
3 3
11. ¿Se ha diseñado el código para serreutilizable?
2 2
12. ¿Están incluidas en el diseño laconversión y la instalación'?
4 4
13. ¿Se ha diseñado el sistema parasoportar múltiples instalaciones endiferentes organizaciones?
0 0
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
20
14. ¿Se ha diseñado la aplicación parafacilitar los cambios y para ser fácilmenteutilizada por el usuario?
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:
Factor de Ponderación
Parámetros deMedición
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
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
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
2. ¿Se requiere comunicación de datos? 3 3
3. ¿Existen funciones de procesamiento
distribuido?
0 0
4. ¿Es crítico el rendimiento? 5 5
5. ¿Se ejecutará el sistema en un entornooperativo existente y fuertementeutilizado?
4 4
6. ¿Requiere el sistema entrada de datosinteractiva?
2 2
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?
1 1
9. ¿Son complejas las entradas, las salidas,los archivos o las peticiones?
2 2
10. ¿Es complejo el procesamientointerno?
3 3
11. ¿Se ha diseñado el código para serreutilizable?
2 2
12. ¿Están incluidas en el diseño laconversión y la instalación'?
4 4
13. ¿Se ha diseñado el sistema parasoportar múltiples instalaciones endiferentes organizaciones?
0 0
14. ¿Se ha diseñado la aplicación parafacilitar los cambios y para ser fácilmenteutilizada por el usuario?
0 0
TOTAL 31
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
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
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
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
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
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
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
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.
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
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
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
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.
R6: Mala estimación de
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.
R7: Mala estimación de
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.
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
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.
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
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
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
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.
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
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
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
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
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
Diagrama de Gantt
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
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
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
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
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
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.
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
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.
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
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
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
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
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
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.
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
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