18
PLAN DE PROYECTO DE SOFTWARE 1. INTRODUCCION Se desarrollará una aplicación que controle todos los aspectos relacionados con la gestión de una farmacia. La farmacia Buenas Nuevas necesita tanto hardware como software de forma que las personas encargadas de las ventas y de la administración puedan agilizar las diferentes operaciones que realizan, siendo este el objetivo principal del sistema de Contabilidad y manejo de inventarios. Además el sistema debe brindar todas las planillas necesarias para poder realizar la contabilidad de la farmacia, el responsable actual de realizar esta labor es el contador. Una de las cosas mas notables del sistema es que gracias a el se podrá establecer un control de inventarios de los productos 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 software necesario para la gestión, con sus respectivos manuales y documentos de soporte. 2. MISIÓN Y VISIÓN DE LA FARMACIA 2.1. Misión de la Farmacia. La misión de la farmacia “Buenas Nuevas” es brindar un servicio eficaz y eficiente a la sociedad para que pueda adquirir productos confiables y acordes a la economía nacional. La farmacia tiene como misión la comercialización de medicamentos, además de productos adicionales. Para poder cumplir este propósito, la administración de la farmacia vio conveniente contar

Plan de Proyecto Software

Embed Size (px)

Citation preview

PLAN DE PROYECTODE SOFTWARE

1. INTRODUCCION

Se desarrollar una aplicacin que controle todos los aspectos relacionados con la gestin de una farmacia. La farmacia Buenas Nuevas necesita tanto hardware como software de forma que las personas encargadas de las ventas y de la administracin puedan agilizar las diferentes operaciones que realizan, siendo este el objetivo principal del sistema de Contabilidad y manejo de inventarios.

Adems el sistema debe brindar todas las planillas necesarias para poder realizar la contabilidad de la farmacia, el responsable actual de realizar esta labor es el contador.

Una de las cosas mas notables del sistema es que gracias a el se podr establecer un control de inventarios de los productos 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 software necesario para la gestin, con sus respectivos manuales y documentos de soporte.

2. MISIN Y VISIN DE LA FARMACIA

2.1. Misin de la Farmacia.La misin de la farmacia Buenas Nuevas es brindar un servicio eficaz y eficiente a la sociedad para que pueda adquirir productos confiables y acordes a la economa nacional.

La farmacia tiene como misin la comercializacin de medicamentos, adems de productos adicionales. Para poder cumplir este propsito, la administracin de la farmacia vio conveniente contar con un sistema computacional, ya que le servir para realizar una mejor administracin de los productos, de las ventas y compras que se realizan.Con el sistema contable el administrador y el vendedor podrn interactuar con el sistema de manera amigable facilitndole su trabajo ya que el sistema le ofrece las siguientes ventajas:

Informacin completa sobre el inventario de los productos. Emitir el comprobante de compra. Registro de Ventas. Reporte de Compras. Reporte de los libros.

2. Visin de la Farmacia.Con una mayor experiencia en el rubro, la farmacia Buenas Nuevas ofrecer una mejor atencin a sus clientes ofreciendo servicios y frmacos de calidad a un precio que va de acuerdo a la economa de la sociedad. Otra de sus aspiraciones es de poder contar siempre con informacin actualizada sobre los frmacos nuevos y alta calidad de los productos.

3. VISION DE LOS DESARROLLADORESLa visin del grupo de desarrolladores es lograr que el sistema pueda satisfacer los requerimientos de la farmacia, para que pueda ser utilizado por el mismo. Tambin lograr que el costo estimado del proyecto se aproxime al costo real del sistema.

4. ALCANCE DEL DOCUMENTOEl objetivo de este documento es el de establecer un calendario de trabajo completo para el desarrollo del sistema contable y de inventarios, estimar el esfuerzo, el tiempo, el costo y los riesgos asociados al desarrollo del mismo.

Tambin nos servir como instrumento para la distribucin de tareas, el control y seguimiento del proyecto y como gua para tomar decisiones cuando el desarrollo normal del proyecto este comprometido.

Finalmente aadir que las etapas previstas en el plan de proyecto de software se basan directamente en el ciclo de vida elegido, por lo cual se har necesario mecanismos y tcnicas de seguimiento que garanticen la continuidad del trabajo y la eficiencia en las tareas.

5. OBJETIVOS DEL PROYECTOEl objetivo general del Proyecto es: Automatizar el manejo manual actual utilizado por la Farmacia Buenas Nuevas.

El Sistema Contable y manejo de inventarios colaborar con las funciones del vendedor y el administrador para realizar una mejor administracin de la farmacia Buenas Nuevas de una forma ms rpida y eficiente.

6. ALCANCE DEL PROYECTOEl alcance de este plan proyecto abarca desde el anlisis hasta el desarrollo por lo cual el objetivo de este documento es planificar de forma ordenada, eficiente y precisa la realizacin del proyecto hasta su culminacin, cumpliendo con los requerimientos de usuario, teniendo como objetivo principal que el sistema sea usable, mantenible y robusto.

Otro objetivo del presente plan de proyecto es cumplir en el tiempo previsto las diferentes tareas que se han identificado, adems de hacer una distribucin eficiente de los recursos, disminuir riesgos del proyecto tomando solo los necesarios, tambin cumplir con el presupuesto asignado al proyecto.

El Documento de plan de proyecto de Software esta orientado a los desarrolladores del sistema, de manera que les sirva de gua para cumplir eficientemente con el desarrollo del proyecto.

7. DESCRIPCIN DEL SISTEMA7.1. Objetivos del Sistema.El Sistema Contable y manejo de inventarios debe cumplir con los siguientes objetivos :

Automatizar los registros de Contabilidad. Automatizar el manejo de inventarios. Ahorro de tiempo al obtener los diferentes reportes. Colaborar al vendedor con las ventas diarias de los productos.

2. Funciones Principales del Sistema.Entre las funciones principales del sistema tenemos:

Ayudar a organizar los productos segn su tipo.Facilitara al vendedor tener un mejor control de los productos existentes, para poder ubicarlos con mayor facilidad, tambin obtener informacin sobre los productos con una fecha de expiracin prxima.

Obtener reportes del libro diario.-Para tener control sobre las transacciones realizadas en el da.

Obtener reportes del libro mayor.-Le servir al administrador para realizar un control del movimiento de cada una de las cuentas, conforme se vaya habilitando las cuentas en el libro diario.

Obtener reportes de inventarios.-Para obtener informacin de los productos faltantes, compra y venta de productos.

Colaborar con las ventas diarias de los productos.-A travs del sistema se ayudara al vendedor a realizar la bsqueda de un producto , si este existe le mostrara la informacin correspondiente al producto (precio, descripcin, etc.)

Proporcionar informes diarios de las ventas, compras realizadas.-A travs de estos reportes se podr tener un mejor control sobre las transacciones realizadas en la farmacia Buenas Nuevas.

7.3.Restricciones Tcnicas y de Gestin

La farmacia Buenas nuevas desea que el sistema sea desarrollado para trabajar bajo la plataforma de Windows.

El administrador de la farmacia Buenas Nuevas necesita implantar el sistema en la prxima gestin, por tanto nos da un plazo de 8 meses.

Los futuros usuarios del sistema que podrn ayudarnos sern el administrador y el vendedor , en el rea contable de nuestro sistema nos asesorara un contador.

7. CICLO DE VIDA DEL SISTEMA

El modelo que usaremos para el desarrollo del Software ser el modelo cascada, dado que contamos con la informacin necesaria proporcionada por el propietario de la Farmacia para obtener requerimientos especficos concretos y concisos.Tambin se identificaron las siguientes causas para optar por este modelo :

Los requerimientos del usuario son claros y no existe ambigedades.

El sistema no es complejo, adems de que ya existen otros sistemas de contabilidad y manejo de inventarios, los que utilizaremos como base de consulta para nuestro sistema.

Este modelo nos permite manejar la informacin de manera ordenada y es fcil de administrar la informacin obtenida.

Se cuenta con bastante material bibliogrfico para su implementacin y diseo.

La estructura de este ciclo de vida es secuencial, progresa a travs del anlisis, diseo, prueba y mantenimiento del software.

Existen otras aplicaciones que pertenecen al mismo domino lo que nos sirve como referencia para el desarrollo de este software.

La estructura de este modelo se describe a continuacin:

Ciclo de Vida en Cascada.

Las fases del modelo en cascada son las siguientes:

1) Anlisis de la Ingeniera de Software.- En esta fase se establecen los requerimientos de todos los elementos del sistema.2) Anlisis.- En esta fase se realiza el proceso de la recoleccin de datos para los requerimientos , centrado en el software.3) Diseo.- Es en esta fase donde se establece la estructura de datos, arquitectura del software y detalle procedimental.4) Codificacin.- En esta fase se realiza la codificacin del software.5) Prueba.- En esta fase se hacen las pruebas necesarias sobre el cdigo que se ha generado.6) Mantenimiento es aqu donde se realizan cambios despus de que se entrega al cliente.1. Estructura de Descomposicin de Trabajos del Proyecto.- Para cada una de las fases del modelo en cascada se han determinado las siguientes tareas a realizar.

|I. INGENIERA Y ANLISIS DEL SISTEMA | | ||TAREAS |Producto y/o Documentacin especifica |Tiempo Das ||T1) Recoleccin de informacin a travs de entrevistas |P1) Documento de informacin recolectada |3 |

|II. ANLISIS DEL SOFTWARE | | ||TAREAS |Producto y/o Documentacin especifica |Tiempo Das ||T 2) Anlisis de informacin obtenida en la entrevista |P2) Documento de Especificacin de Requerimientos |6 ||T3) Elaboracin del modelo lgico y el modelo de datos. |P3) Modelo de datos elaborado |7 |

|III. DISEO | | ||TAREAS |Producto y/o Documentacin especifica |Tiempo Das ||T4) Diseo de estructura de datos |P4)Especificacin de la estructura de datos |6 ||T5) Diseo Arquitectnico |P5)Arquitectura del software |6 ||T6) Diseo de la interfaz |P6) Diseo de interfaz entre mdulos y componentes |7 || Emisin de los asientos diarios. | | || Emisin de un estado de resultados. | | || Emisin de un balance general. | | || Emisin del control de stock de los productos. | | || Emisin de ingresos y egresos. | | || Emitir el comprobante de compra. | | || Registro de Ventas. | | || Reporte de Compras. | | ||T7) Definicin de la B.D. |P7) Especificacin de la B.D. a emplear |12 ||T8) Anlisis y diseo de algoritmos a utilizar para la |P8) Especificacin de algoritmos a utilizar para obtener mayor |12 ||realizacin de : |eficiencia, segn los procesos de los componentes. | || Emisin de reportes. | | ||T9) Diseo de la interfaz de usuario. |P9) Estructura de la interfaz de usuario. |15 ||T10) Diseo de ayuda de usuario. |P10) Documento de diseo de ayuda para el usuario |7 ||*Ayuda en linea del sistema | | ||* Mensajes producidos por el sistema | | ||T11) Codificacin de los mdulos del proyecto, |P11) Procesos codificados |30 ||especificado en el punto de anlisis. | | ||T12) Seguimiento y control de la codificacin de |P12) Verificacion de los modulos.|15 ||mdulos. | | ||T13) Seguimiento y control de la codificacin de |P13) Software integrado. |10 ||mdulos. | | |

|IV PRUEBAS | | ||TAREAS |Producto y/o documentacin especifica. |Tiempo das ||T14) Realizacin de pruebas del software integrado |P15) Software validado. |7 |

2. Dependencia de Tareas.- De acuerdo a las tareas identificadas se ha realizado la dependencia que existe entre ellas. El conocimiento de la dependencia de tareas nos ayuda a tener una mejor organizacin en el desarrollo de las mismas, para que se pueda tener el Software terminado en la fecha prevista.

|Tareas |Duracion (das) |Dependencias ||T1 |3 | ||T2 |6 |T1 ||T3 |7 |T2 ||T4 |6 |T3 ||T5 |6 |T2 ||T6 |7 |T5, T4 ||T7 |12 |T2 ||T8 |12 |T4,T5,T6 ||T9 |15 |T2 ||T10|7 |T9 ||T11 |30 |T7, T8, T9,T10 ||T12 |15 |T11 ||T13 |10 |T11, T12 ||T14 |7 |T13 |

Dependencia de Tareas

8.3. Red de Actividades.-

Los productos obtenidos en cada Hito son:H1: Entrega del documento de la recoleccin de la informacin realizada a travs de entrevistas.H2: Entrega del documento de especificacin de requerimientos.H3: Entrega del documento del modelo de datos.H4: Entrega de la especificacin de la estructura de datos y el diseo arquitectnico.H5: Entrega del diseo de la interfaz entre los componentes.H6: Entrega del diseo de la interfaz de usuario.H7: Entrega de la especificacin de la Base de Datos.H8: Entrega de la especificacin de algoritmos.H9: Entrega del diseo de ayuda para el usuario.H10: Entrega de procesos codificados.H11: Entrega de mdulos verificados.H12: Entrega del Software integrado.H13: Entrega del Software validado.

8.4. Distribucin de Tareas.

[pic]

8. ESTIMACIN DE RECURSOS PARA EL PROYECTO

Para realizar los siguientes clculos se han estimado los Puntos de Funcin (PF) lo que nos dar una idea del tamao del proyecto de software que se va a producir basados en la complejidad y cantidad de sus componentes.

- Numero de Entradas de Usuario:En el sistema se determino que tendremos entre 15 y 20 entradas de usuario siendo 18 la mas probable ya que es un sistema pequeo.

Numero de Salidas de usuario :

Se identifican entre 10 y 15 salidas de usuario con un valor de 12 salidas de usuario como mas probable, todas ella con una complejidad media.

- Numero de Peticiones de Usuario:Se han identificado entre 14 y 22 peticiones de usuario, lo mas probable es que se tenga 19 peticiones.

- Numero de Archivos:En un caso optimista se requerirn solo 3 archivos y en el peor de los casos 6. Debido a la seguridad que se debe proveer.

- Numero de Interfaces Externas:Se considera el uso de 2 interfaces de complejidad alta, en el peor de los casos se utilizara 3 de dichas interfaces y en el menor 3.

9.1. Clculo de Puntos de Funcin.

|Puntos de Funcin |Optimista |Probable |Pesimista |Peso |Subtotal ||# entradas usr |15 |18 |20 |3 |53.50 ||# salidas de usr |10 |12 |15 |4 |48.70 ||# peticiones de usr |14 |19 |22 |3 |56.01 ||#Archivos |3 |5 |6 |8 |38.64 ||# interfaces externas |2 |3 |3 |5 |14.15 ||211 |

Clculo de Valores de Ajuste de Complejidad:

1- Requiere el sistema copias de seguridad y recuperacin fiables?La informacin es de alta importancia y esta no se pierde con el tiempo siendo necesaria su recuperacin en cualquier momento.

5

2- Se requiere comunicacin de datos?Nuestro sistema requiere mover datos o modificarlos.

3

3- Existen funciones de procesamiento distribuido?Nuestro sistema no se requiere este tipo de proceso.04- Es critico el rendimiento?Los procesos son de tipo administrativo por lo cual requiere algunos clculos.

4

5- Se ejecutara el sistema en un entorno conocido y fuertemente utilizado?El software funcionara en Windows ya que es el Sistema Operativo solicitado por el usuario.

4

6- Requiere el sistema entrada de datos interactiva?Algunas de las operaciones sern interactivos.2

7- Requiere la entrada de datos iteractiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas o aplicaciones?Se realizaran en distintas interfase con sus propias pantalla dentro del sistema.

5

8- Se actualizan los archivos maestros de forma interactiva?El trato de los datos es muy cuidadoso por lo cual se requerir acceso directo.

5

9- Son complejas las entradas, las salidas, los archivos o la peticiones?No son muy complejas por que se manipula datos simples .

1

10- Es complejo el procesamiento interno?Los clculos no son muy simples .3

11- Se ha diseado el cdigo para ser reutilizable?Se tratara de hacer la mayor parte del cdigo con esta caracterstica.

5

12-Estn incluidas en el diseo la conversin o la instalacin?Se ha contemplado el diseo central.413-Se ha diseado el sistema para soportar mltiples instalaciones en diferentesorganizaciones?Solo se ha contemplado el diseo del sistema para el caso especifico.2

14- Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmenteutilizada por el usuario?Se ha tenido en cuenta ambas opciones.

5

Calculando PF:

Estimando los factores de ajuste:

F1=5 F8=5F2=3 F9=1F3=0 F10=3F4=4 F11=5F5=4 F12=4F6=2 F13=2F7=5 F14=5

Sumatoria de Factores de Ajuste (Fi)= 48

Puntos de Funcin Estimado:

PF = UCF * (0.65 + 0.01 * ( (Fi))

PF = 211 * (0.65 + 0.01 * 48)PF = 238Puntos de Funcin = 238

9.2. Productividad.-

El tiempo estimado para la conclusin del proyecto es de 5 meses, este plazo debe comprender un periodo para cubrir los retrasos del proyecto, por lo que el clculo de la productividad requerida se har sobre un tiempo menor y teniendo en cuenta un equipo de 4 personas.Se har el calculo para 4 meses para tener una idea de cmo puede variar la productividad y as poder tomar otras decisiones.

PRODUCTIVIDAD = (238 PF/4 per.)/ 4 meses

PRODUCTIVIDAD = 14.87 PF/PERSONA MES

Para efectos del calculo real sobre los 5 meses la productividad seria:

PRODUCTIVIDAD = (PF/ 4 per)/ 5 meses

PRODUCTIVIDAD = (238 PF/4per.)/ 5 meses

PRODUCTIVIDAD = 11.9 PF/PERSONA MES

9.3 Costo

En la cotizacin el precio del desarrollo se indico sobre 800 Bs/persona, para los PF calculados el costo seria:Con 5 mesesEsfuerzo = 238 PF/ 11.9 PF pers. / mesEsfuerzo = 20 pers. / mes

Costo Total del Proyecto = 20 * 800= 16000 .- BsCon 4mesesEsfuerzo = 238 PF/ 14.87 PF pers. / mesEsfuerzo = 16 pers. / mes

Costo Total del Proyecto =16 * 800= 12800.- Bs

NOTA:De todas maneras se debe considerar que este precio no incluye otros gastos como ser pasajes, alimentacin , etc.

9.4. COCOMO 81.-Para el clculo del COCOMO 81 se utiliza lneas de cdigo, para esto se tiene como premisas que se utiliza el ciclo de vida en cascada y que el desarrollo se inicia en cero. Las LDC de la siguiente tabla son estimaciones realizadas por el grupo.

|Funcin |LDC optimista |LDC probable |LDC pesimista |LDC esperado ||Libro diario |500 |800 |1000 |783 ||Libro mayor |800 |1000 |1500 |1050 ||Estado de resultados |400 |600 |800 |600 ||Balance general |700 |900 |1200 |917 ||Cuentas activo y pasivo |450 |750 |850 |717 ||Total | | | |4067 |

SimpleM=1

PM =2.4 (KDSI) 1.051 * MPM = 2.4 (4.067)1.051 *1PM = 10.48 per* mes

Costo Total del Proyecto = 10.48*800 = 8384 Bs9.5. COCOMO 2.Como estamos en las primeras etapas del proyecto utilizaremos la aproximacin bsica que seria la de CONSTRUCCIN DE PROTOTIPOS. Para esto primero necesitamos el numero de PUNTOS DE OBJETO:

Pantallas : 4complejas = 28 POInformes : 10 simples = 25 PO5 moderados = 30 PO5 complejos = 40 PO

TOTAL 133 PO

Tambin necesitamos de un indicador de productividad el cual se obtiene de la experiencia y capacidad de los desarrolladores la cual se considera muy baja:PROD = 4 (PO/MES)

Es necesario aproximar un nivel de reutilizacin de cdigo, por lo cual daremos el siguiente porcentaje:

% reutilizacin = 40%

Tendramos el siguiente calculo:

PM = (PO *(1-%reutilizacion/100))/PROD

PM = (133*(1- 40)/100))/4 = 19.95 PERSONAS /MES

Costo Total del Proyecto = 19.95 * 800 Bs = 15960 Bs.

9.6.CONCLUSIONES

Concluimos que los costos totales del proyecto se asemejan, por lo que se puede considerar que se ha hecho una estimacin aproximada.El objetivo es lograr que el cliente acepte nuestra propuesta y al mismo tiempo ofrezca ganancia al equipo de trabajo. En el caso de tiempo de concluir el proyecto en 4 meses costo total del proyecto aumentara ya que la productividad aumenta y esto influye en el costo total del proyecto.

10. RIESGOS DEL PROYECTO

Como en todo proyecto a realizar este puede llegar a tener ciertos percances ya sea en su anlisis, implementacin o ya dentro del software mismo.

10.1. Identificacin de Riesgos.-Se pudieron identificar los siguientes riesgos:

|RIESGO |TIPO DE RIESGO |DESCRIPCIN ||Movimiento de personal |Proyecto |Alguno de los integrantes del grupo abandone el || | |proyecto antes de que sea completado ||Errores de Hardware |Proyecto |Hardware que esta siendo utilizado en el proyecto sufra|| | |perdida de informacin. ||Falta de experiencia del grupo de |Proyecto |El grupo de desarrolladores no cuenta con mucha ||desarrolladores | |experiencia. ||Requerimientos cambian |Proyecto y producto|Los requerimientos pueden sufrir algn cambio que no || | |se esperaba. ||Retrasos en el cumplimiento de las |Proyecto y producto|Las tareas designadas a cada uno de los integrantes no||tareas | |estarn disponibles a tiempo ||Subestimacin de tamao |Producto y proyecto|El tamao del sistema ha sido subestimado ||Sub-rendimiento de herramientas CASE |Producto |Herramientas CASE que soportan el proyecto no funcionan|| | |como esperaba ||Cambio en tecnologa |Negocio |La tecnologa en que el sistema es construido es || | |suplantada por nueva tecnologa ||Competencia del producto |Negocio |Un producto competitivo est publicitado antes de que || | |el sistema est completo ||Tiempo subestimado para desarrollar |Proyecto |Para el desarrollo de los componentes del sistema se || | |necesita ms tiempo del previsto. |

10.2. Plan de Gestin de Riesgos.

|RIESGO |ESTRATEGIA ||Movimiento de personal |Reorganizar el grupo de trabajo para hacer ms superposicin de tareas || |para que los dems comprendan el trabajo a realizar. ||Errores de Hardware |Reemplazar componentes defectuosos, adems tener copias de seguridad del || |proyecto. ||Falta de experiencia del grupo de |Ganar experiencia con el proyecto a realizar. Y tomar cursos de ||desarrolladores |capacitacin y actualizacin por parte del equipo. ||Requerimientos cambian |Derivar informacin para valorar el impacto del cambio de los || |requerimientos. ||Retrasos en el cumplimiento de las |Alertar el cliente sobre dificultades potenciales y la posibilidad de ||tareas |retrasos. ||Subestimacin de tamao |Tratar de que el tamao del sistema no sobrepase la estimacin hecha, en || |caso de no lograrse entonces informar al cliente sobre la situacin del || |sistema. ||Sub-rendimiento de herramientas CASE|Cambiar de herramientas CASE. ||Cambio en tecnologa |El sistema sea flexible para soportar un cambio tecnolgico, como ser : || |plataforma, PC. ||Competencia del producto |Respaldarnos con el contrato hecho con el cliente. ||Tiempo subestimado para desarrollar |Obtener componentes pre-hechos |

-----------------------

Ingeniera

De Software

Mantenimiento

Prueba

Codificacin

Diseo

Anlisis

UCF= 211