INFORME-FINAL-JAVIERPEÑAGARCIA

8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA

1/97

UNIVERSIDAD CATLICA LOS ANGELES DE CHIMBOTE

FILIAL-SULLANA

PRE1P 1RE

Javier Andrs Pea Garcia

AUTOR

DOCENTE

ESTHER Y. LIZAMA PUELLES

15SESIONSESION


2/97

INTRODUCCIN

El presente proyecto denominado como

MODELAMIENTO DEL SISTEMA DECOBRANZAS UTILIZANDO SOFTWARE LIBRE PARA LA EMPRESA

WATCHING SERVICIOS GENERALES- SULLANA se realiza con la importancia que

al consultar los pagos y cobranzas se pueda tener un rpido servicio al cliente y de tal

manera mejorar la imagen de la empresa en su calidad para poder as competir con otras

empresas. Por lo que se ha credo conveniente presentar este proyecto, con la finalidad de

mejorar el servicio al cliente. Con el presente proyecto se pretende contribuir a

solucionar los problemas como el ahorro de trabajo a la hora de escribir en varios libros

todos los pagos y entregas de la empresa,

Obviamente el sistema tramite registros y mejora los procesos actuales que vienen

realizando en forma manual. Descongestionara el trabajo del personal de la empresa.

Minimizara totalmente el tiempo que se dedica a la bsqueda de un registro para asi dar el

informe de respuesta a los clientes.

El anlisis y diseo del sistema de registros est orientado para implementar en todas las

oficinas que se encuentran comprendidas ya que se va a encontrar en red.

Entre las ventajas ms resaltantes, que se obtendrn con la implementacin del sistema.

Podemos mencionar


3/97

RESUMEN

El Presente Proyecto denominado MODELAMIENTO DE SISTEMAS DE

COBRANZAS UTILIZANDO SOTFWARE LIBRE PARA LA EMPRESA

WATCHING SERVICIOS GENERALES - SULLANA

Se realizara como resultado de anlisis de la situacin actual de la empresa WATCHING

SERVICIOS GENERALES SULLANA. Tal es as que se ha permitido conocer que no

se cuenta actualmente con un sistema de Informacin de ingreso y bsquedas que permite

un seguimiento adecuado a sus clientes y mucho menos con una base de datos

normalizada.

Por tal razn se ha desarrollado el presente estudio que implica las etapas de anlisis,

diseo y la presentacin de algunos prototipos a fin de sustentar y demostrar tcnicamente

la posibilidad de la implantacin de un sistema de cobranzas en la empresa WATCHING

SERVICIOS GENERALES SULLANA.

La presente instruccin se identifica en cinco sesiones, lo mismos que brevemente se

detallan a continuacin.

En la sesin I, denominado: Aspectos Generales, se define evaluar, teniendo en cuenta la

informacin detallada de su Ubicacin Geogrfica, base legal de su creacin, reas que

comprende, funciones de dichas reas y su organigrama; as mismo su Historia yEvolucin para concluir con los servicios que presta. Esta informacin permitir analizar y

conocer personas involucradas en el proyecto del sistema de cobranzas. Lo cual se permite

identificar los requerimientos del sistema.

En el sesin II, denominado: Anlisis del sistema Actual, se determina la fase de

recopilacin de la Informacin, la formulacin del problema, descripcin de los procesos o

actividades que se realizan en el sistema actual y finalmente se concluye identificando los

requerimientos.En la sesin III, Denominado: Anlisis y Diseo del sistema Propuesto, se explica

primeramente las metodologas ms usadas en la actualidad comparando entre el anlisis y

diseo orientado a objetos y anlisis y diseo estructurado. Asimismo se realiza la

fundamentacin de la seleccin de la metodologa UML y se indica software libre que se

utilizara para el moldeamiento.


4/97

En esta sesin de igual forma se realiza la explicacin de la etapa de anlisis, definiendo

los requisitos, detallando los casos esenciales de uso, diagramas de caso de uso, modelo

conceptual, diagramas de secuencia y diagrama de actividades. En la etapa de diseo se

explica el tema de los casos reales de uso, diagramas de clase; la implementacin de lasbases de datos y las interfaces.

En la sesin IV, denominado: Prototipos del sistema, se trata de fundamentar el uso de los

prototipos de sistemas antes de la implantacin, se presentan prototipos de algunos

procesos de sistema propuesto y se concluye explicando la seguridad del sistema.

En el sesin V, denominado: evaluacin Econmica del Proyecto, se realizan el desarrollo

de los estudios de Viabilidad y costes Beneficios, a fin de determinar la o no la

posibilidad de la implantacin del Sistema de Cobranzas PARA LA EMPRESA

WATCHING SERVICIOS GENERALES SULLANA.

Finalmente, se detalla un glosario de trminos a fin de que se pueda entender algunos

trminos usados en el presente estudio y la seccin de Anexos que contiene, Manual de

Organizacin y Funciones de la PARA LA EMPRESA WATCHING SERVICIOS

GENERALES SULLANA, Proforma y Presupuestos para el licenciamiento de Software

propietario, Fichas de Entrevistase e Inventario de Equipos


5/97

NOMBRE DEL PROYECTO

MODELAMIENTO DE SISTEMAS COBRANZAS UTILIZANDO SOFTWARE

LIBRE PARA LA EMPRESA WATCHING SERVICIOS GENERALES- SULLANA

OBJETIVOS GENERAL

Describir y Proponer alternat ivas de solucin a las dificultades de seguimiento de l a s

cobranzas y entregas de dinero a los clientes de la empresa WATCHING SERVICIOS

GENERALES - SULLANA

OBJETIVOS ESPECIFICOS

Realizar un trabajo de recopilacin necesaria, mediante el mtodo de entrevistas alas personas que se encuentran inmersas en el proceso del manejo de pagos y

entregas al cliente y anlisis del procedimiento existentes.

Normas adecuadamente el registro sistematizado de la informacin al momentode dar los historiales de los clientes. En diferentes oficinas de la empresa como

el administrador y sus digitadores.

Modelar el sistema con la metodologa UML Disear y construir una Base de Datos integra y confiable mediante un sistema

de administracin de base de datos utilizando DBdesinger y MySql

Evaluar y especificar los requerimientos de Hardware y Software necesarios para lainstalacin e implementacin del Sistema.

Determinar la factibilidad econmica del proyecto, mediante un anlisis decostos y Beneficios.

Disear un prototipo para poder eliminar los problemas de entendimiento delsistema.


6/97

OBJETIVOS DEL SISTEMA

Realizar un trabajo de recopilacin necesaria, mediante el mtodo de entrevistas alas personas encargadas del uso del sistema

Evaluar y especificar los requerimientos de Hardware y Software necesariospara la instalacin e implementacin del Sistema.

Determinar la factibilidad econmica del proyecto, mediante un anlisis deCostos y Beneficios.

Automatizar el proceso de Registro, Seguimiento y Ubicacin de todas lashistorias de los clientes que se tramita.

Implementar un sistema utilizando Software libre en su totalidad tanto para elanlisis, diseo y para su implementacin.

Disear interfaces sencillas amigables, que sean totalmente fcil de entender ymanipular por cualquier trabajador.


7/97

CAPITULO I

MARCO TERICO CONCEPTUAL


8/97

1.1 DATOS GENERALES DE LA ORGANIZACIN

1.1.1 UBICACIN GEOGRFICA

Razn social de la empresa

EMPRESA WACHING SERVICIOS GENERALES

SULLANA

Representantes legales

LUCHO WACHING

Gerente

Direccin

CALLE SAN MARTIN 426 CENTRO SULLANA

1.1.2 VISION

Ser la mejor institucin micro financiera gil y confiable en la

generacin de valor para nuestros clientes, colaboradores y

accionistas.

1.1.3 MISIN

Brindar soluciones financieras en forma rpida y oportuna a los

clientes, con un equipo humano orientado hacia la excelencia,

contribuyendo al desarrollo econmico y social del pas.

1.1.4 VALORES

1) Orientacin al cliente.

2) Desarrollo para los colaboradores.

3) Orientacin al logro.

4) Integridad y honradez.

5) Trabajo en equipo.

6) Orientacin a la innovacin y calidad.

7) Liderazgo.


9/97

1.1.1 Organigrama


10/97

Id Modo de

tarea

Nombre de tarea Duracin Comienzo Fin

1 Proyecto del Sistema 94 das mi 26/10/11lun 05/03/12

2 Definicion del Precio 1 da mi 26/10/11mi 26/10/11

4 Fin del Precio 0 das mi 26/10/11 mi 26/10/11

5 Definicion del Tiempo 1 da mi 26/10/11mi 26/10/11

7 Fin del Tiempo 0 das mi 26/10/11 mi 26/10/11

8 Recopilacion de

Informacion

2 das jue 27/10/11 vie 28/10/11

13 Fin de Recopilacion de

Informacion

0 das vie 28/10/11 vie 28/10/11

14 Analisis UML 3 das mar 01/11/11 jue 03/11/1119 Fin de Analisis UML 0 das jue 03/11/11 jue 03/11/11

20 Diseo del Sistema 11 das lun 07/11/11 lun 21/11/11

24 Fin del Diseo 0 das lun 21/11/11 lun 21/11/11

25 Desarrollo del Sistema 61 das lun 21/11/11 lun 13/02/12

29 Fin del Desarrollo del

Sistema

0 das lun 13/02/12 lun 13/02/12

30 Entrega de Demos 6 das mar 14/02/12 mar 21/02/12

32 Fin de Entrega de Demo0 das mar 21/02/12 mar 21/02/12

33 Capacitacin 3 das vie 24/02/12 mar 28/02/12

36 Fin de la Capacitacin 0 das mar 28/02/12 mar 28/02/12

37 Entrega del Sistema 4 das mi 29/02/12lun 05/03/12

39 Fin de la Entrega 0 das lun 05/03/12 lun 05/03/12

40 FIN DEL SISTEMA 0 das lun 05/03/12 lun 05/03/12

26/10

26/10

28/10

03/11

21/11

10 17 24 31 07 14 21 28

nov '11 dic '

Tarea

Divisin

Hito

Resumen

Resumen del proyecto

Tareas externas

Hito externo

Tarea inactiva

Hito inactivo

Resumen inactivo

Tarea manual

Slo duracin

Informe de resumen manual

Resumen manual

Slo el comienzo

Slo fin

Fecha lmite

Progreso

Pgina 1

Proyecto: Proyecto-SistemaCobra

Fecha: mi 26/10/11


11/97

13/02

21/02

28/02

05/03

05/03

28 05 12 19 26 02 09 16 23 30 06 13 20 27 05 12 19

dic '11 ene '12 feb '12 mar '12

Tarea

Divisin

Hito

Resumen


Tareas externas

Hito externo

Tarea inactiva

Hito inactivo

Resumen inactivo

Tarea manual

Slo duracin


Resumen manual

Slo el comienzo

Slo fin

Fecha lmite

Progreso

Pgina 2


Fecha: mi 26/10/11


12/97

19 26 02 09 16 23 30 07 14 21 28 04 11 18 25 02 09

abr '12 may '12 jun '12 jul '12

Tarea

Divisin

Hito

Resumen


Tareas externas

Hito externo

Tarea inactiva

Hito inactivo

Resumen inactivo

Tarea manual

Slo duracin


Resumen manual

Slo el comienzo

Slo fin

Fecha lmite

Progreso

Pgina 3


Fecha: mi 26/10/11


13/97

Id Modo de

tarea


1 Proyecto del Sistema 94 das mi 26/10/11lun 05/03/12

2 Definicion del Precio 1 da mi 26/10/11mi 26/10/11

3 Precio Determinado 1 da mi 26/10/11 mi 26/10/11

4 Fin del Precio 0 das mi 26/10/11 mi 26/10/11

5 Definicion del Tiempo 1 da mi 26/10/11mi 26/10/11

6 Tiempo Determinado1 da mi 26/10/11 mi 26/10/11

7 Fin del Tiempo 0 das mi 26/10/11 mi 26/10/11

8 Recopilacion de

Informacion

2 das jue 27/10/11 vie 28/10/11

9 Entrevista con el Jefe1 da jue 27/10/11 jue 27/10/11

10 Entrevista con los

Usuarios

1 da jue 27/10/11 jue 27/10/11

11 Encuesta con el Jefe 1 da vie 28/10/11 vie 28/10/11

12 Encuesta con los

Usuarios

1 da vie 28/10/11 vie 28/10/11

13 Fin de Recopilacion de

Informacion

0 das vie 28/10/11 vie 28/10/11

14 Analisis UML 3 das mar 01/11/11 jue 03/11/11

15 Sotfware Para UML 1 da mar 01/11/11 mar 01/11/11

16 Caso de Uso 1 da mi 02/11/11 mi 02/11/11

17 Diagrama de Activida1 da mi 02/11/11 mi 02/11/11

18 Diagrama de Secuenc1 da jue 03/11/11 jue 03/11/11

19 Fin de Analisis UML 0 das jue 03/11/11 jue 03/11/11

26/10

26/10

28/10

03/11

10 17 24 31 07 14 21 28

nov '11 dic '

Tarea

Divisin

Hito

Resumen


Tareas externas

Hito externo

Tarea inactiva

Hito inactivo

Resumen inactivo

Tarea manual

Slo duracin


Resumen manual

Slo el comienzo

Slo fin

Fecha lmite

Progreso

Pgina 1


Fecha: mi 26/10/11


14/97

Id Modo de

tarea


20 Diseo del Sistema 11 das lun 07/11/11 lun 21/11/11

21 Diagrama de Clase 2 das lun 07/11/11 mar 08/11/11

22 Diagrama de Base de

Datos

4 das mi 09/11/11 lun 14/11/11

23 Prototipo 5 das mar 15/11/11 lun 21/11/11

24 Fin del Diseo 0 das lun 21/11/11 lun 21/11/11

25 Desarrollo del Sistema 61 das lun 21/11/11 lun 13/02/12

26 Sotfware Para Motor

de Base de Datos

1 da lun 21/11/11 lun 21/11/11

27 Sotfware Para

Programacin

1 da lun 21/11/11 lun 21/11/11

28 Modulos Del Sistema 60 das mar 22/11/11 lun 13/02/12

29 Fin del Desarrollo del

Sistema

0 das lun 13/02/12 lun 13/02/12

30 Entrega de Demos 6 das mar 14/02/12 mar 21/02/12

31 Verificacin del

Modulo

6 das mar 14/02/12 mar 21/02/12

32 Fin de Entrega de Demo0 das mar 21/02/12 mar 21/02/12

33 Capacitacin 3 das vie 24/02/12 mar 28/02/12

34 Manual de Usuario 3 das vie 24/02/12 mar 28/02/12

35 Realizar Pruebas con

los Usuarios

1 da mar 28/02/12 mar 28/02/12

36 Fin de la Capacitacin 0 das mar 28/02/12 mar 28/02/12

21/11

10 17 24 31 07 14 21 28

nov '11 dic '

Tarea

Divisin

Hito

Resumen


Tareas externas

Hito externo

Tarea inactiva

Hito inactivo

Resumen inactivo

Tarea manual

Slo duracin


Resumen manual

Slo el comienzo

Slo fin

Fecha lmite

Progreso

Pgina 2


Fecha: mi 26/10/11


15/97

Id Modo de

tarea


37 Entrega del Sistema 4 das mi 29/02/12lun 05/03/12

38 Comprobar Entrega 4 das mi 29/02/12 lun 05/03/12

39 Fin de la Entrega 0 das lun 05/03/12 lun 05/03/12

40 FIN DEL SISTEMA 0 das lun 05/03/12 lun 05/03/12

10 17 24 31 07 14 21 28

nov '11 dic '

Tarea

Divisin

Hito

Resumen


Tareas externas

Hito externo

Tarea inactiva

Hito inactivo

Resumen inactivo

Tarea manual

Slo duracin


Resumen manual

Slo el comienzo

Slo fin

Fecha lmite

Progreso

Pgina 3


Fecha: mi 26/10/11


16/97


17/97

CAPITULO II

ANLISIS DEL SISTEMA ACTUAL


18/97

2.1. Recopilacin de la Informacin

Segn nuestra recopilacin de informacin nos muestra que el

software que se va a usar debe

tener las siguientes caractersticas Que se pueda obtener los datos de

los clientes al presionar

un botn, como en caso de los cancelados y vigentes Entre lo que se

pide tambin el ingreso

de pagos, entregas y un cadre mensual, un estimado de ganancia en

porcentaje

segn las entregas con las cobranzas, un Historial para saber que

clientes no

renovaron para irlos a visitar en caso que sean clientes puntuales.

2.1.1. Revisin documental

Los procesos de registro, ubicacin y seguimiento de los clientes para

obtener una

rpida respuesta al consultar se ha diseado este nuevo sistema para un

proceso ms

eficiente y que se realice en menor tiempo. Como en los casos antiguos los

todos

los pagos de los clientes se hacan escrito ahora el cliente mediante una

clave y usuario

puede ver sus pagos sin tener que ir a la entidad, solamente tiene quecontar con una PC

con internet para verificar su cuenta.

2.1.2. Entrevistas para obtener requerimientos

Las entrevistas realizadas durante la etapa de recoleccin deinformacin


19/97

tienen la finalidad de determinar las razones que se encuentran

detrs de

l presente trabajo de investigacin.

Es aqu en esta etapa donde se inicia el proceso determinacin

de los requerimientos y necesidades de los usuarios para contar con un

sistema

que solucione su problemtica.

2.2.1. Seleccin de personas a entrevistar

1. Gerente de la empresa Servicios Generales Waching

Gerente

2. Lic. Berenice Neyra Chavez

Digitadora.

2.2.2. Diseo de Entrevistas

En el cuestionario que se prepar para el desarrollo de las

entrevistas,

se plantearon algunas de las siguientes situaciones:

1. Cuentan uds., con un sistema automatizado de?

2. Cmo se realiza actualmente el registro y seguimiento de los

clientes?

3. Cules son los problemas de mayor envergadura que tienen en

realizar?

4. Se presta actualmente un buen servicio de atencin al cliente?

5. Cree usted que con el sistema actual la informacin es

confiable

y la atencin es oportuna?


20/97

6. Cree usted., que es necesario contar con un sistema para el

Seguimiento

de los clientes en su cuentas?

7. Cree que mejorara su rendimiento profesional y laboral contando

c

on un sistema web que el usuario pueda ve sus pagos?

8. Asume usted que mejorara la imagen de la empresa y sus

servicios?


21/97


22/97

CAPITULO III

ANALISIS Y DISEO DEL SISTEMA PROPUESTO


23/97

3.1 DESCRIPCION DE LAS METODOLOGIAS MS USADAS:

Una metodologa de desarrollo de software se refiere a un frameworkque es usado para

estructurar, planear y controlar el proceso de desarrollo en sistemas de informacin.

A lo largo del tiempo, una gran cantidad de mtodos han sido desarrollados

diferencindose por su fortaleza y debilidad.

El framework para metodologa de desarrollo de software consiste en:

Una filosofa de desarrollo de programas de computacion con el enfoque del

proceso de desarrollo de software

Herramientas, modelos y mtodos para asistir al proceso de desarrollo de

software

Estos frameworks son a menudo vinculados a algn tipo de organizacin, que adems

desarrolla, apoya el uso y promueve la metodologa. La metodologa es a menudo

documentada en algn tipo de documentacin formal.

Todo proyecto sea grande o pequeo se debe tener en cuenta en utilizar un mtodo de

desarrollo, ya que al no llevar una metodologa de por medio, posteriormente se ven

consecuencias como es tener clientes insatisfechos con el resultado y desarrolladores

an ms insatisfechos.

METODOLOGIA RUP

Forma parte del grupo de metodologas tradicionales, el ciclo de vida RUP es una

implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en

secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones

en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi
http://es.wikipedia.org/wiki/Frameworkhttp://es.wikipedia.org/w/index.php?title=Filosof%C3%ADa_de_desarrollo_de_programas_de_computacion&action=edit&redlink=1http://es.wikipedia.org/wiki/Desarrollo_en_espiralhttp://es.wikipedia.org/wiki/Desarrollo_en_espiralhttp://es.wikipedia.org/w/index.php?title=Filosof%C3%ADa_de_desarrollo_de_programas_de_computacion&action=edit&redlink=1http://es.wikipedia.org/wiki/Framework


24/97

en las distintas actividades. En la Figura muestra cmo vara el esfuerzo asociado a las

disciplinas segn la fase en la que se encuentre el proyecto RUP.

Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la

comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la

eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea Base) de

la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de

modelado del negocio y de requisitos.

En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la

arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios

(refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de

la arquitectura.

En la fase de construccin, se lleva a cabo la construccin del producto por medio de

una serie de iteraciones.

Para cada iteracin se selecciona algunos Casos de Uso, se refina su anlisis y diseo y

se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada

ciclo. Se realizan tantas iteraciones hasta que se termine la implementacin de la nueva

versin del producto.

En la fase de transicin se pretende garantizar que se tiene un producto preparado para

su entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero que

dependiendo de la fase el esfuerzo dedicado a una disciplina vara.
http://esl.proz.com/kudoz/english_to_spanish/international_org_dev_coop/2221427-baseline.htmlhttp://esl.proz.com/kudoz/english_to_spanish/international_org_dev_coop/2221427-baseline.html


25/97

FASES DE LA METODOLOGIA RUP:

a. FASE DE INICIO

Durante esta fase de inicio las iteraciones se centran con mayor nfasis en las

actividades de modelamiento de la empresa y en sus requerimientos

b. FASE DE ELABORACIN

Durante esta fase de elaboracin, las iteraciones se centran al desarrollo de la

base de la diseo, encierran ms los flujos de trabajo de requerimientos, modelo

de la organizacin, anlisis, diseo y una parte de implementacin orientada a la

base de la construccin

c. FASE DE CONSTRUCCIN

Durante esta fase de construccin, se lleva a cabo la construccin del producto

por medio de una serie de iteraciones las cuales se seleccionan algunos Casos de

Uso, se redefine su anlisis y diseo y se procede a su implantacin y pruebas.

En esta fase se realiza una pequea cascada para cada ciclo, se realizan tantas

iteraciones hasta que se termine la nueva implementacin del producto.

d. FASE DE TRANSICIN

Durante esta fase de transicin busca garantizar que se tiene un producto

preparado para su entrega al usuario.


26/97

. PRINCIPALES CARACTERISTICAS

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu,

cundo y cmo)

Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo

Administracin de requisitos

Uso de arquitecturas basada en componentes.

Control de cambios

Modelado visual del software

Verificacin de la calidad del software.

3.1.1.4. ASPECTOS IMPORTANTES:

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:

Proceso: Las etapas de esta seccin son:

Modelado de negocio

Requisitos

Anlisis y Diseo

Implementacin

Pruebas Despliegue

Soporte: En esta parte nos conseguimos con las siguientes etapas:

Gestin del cambio y configuraciones

Gestin del proyecto

Entorno

La estructura dinmica de RUP es la que permite que este sea un proceso dedesarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases

descritas anteriormente.

Inicio(Tambin llamado Incepcin)

Elaboracin

Desarrollo(Tambin llamado Implementacin, Construccin)

Cierre (tambin llamado transicin)


27/97

METODOLOGIA XP

1 Fase: Planificacin del proyecto. Historias de usuario: El primer paso de cualquier

proyecto que siga la metodologa X.P es definir las historias de usuario con el cliente.

Las historias de usuario tienen la misma finalidad que los casos de uso pero con algunas

diferencias: Constan de 3 4 lneas escritas por el cliente en un lenguaje no tcnico sin

hacer mucho hincapi en los detalles; no se debe hablar ni de posibles algoritmos para

su implementacin ni de diseos de base de datos adecuados, etc. Son usadas para

estimar tiempos de desarrollo de la parte de la aplicacin que describen. Tambin se

utilizan en la fase de pruebas, para verificar si el programa cumple con lo que especifica

la historia de usuario. Cuando llega la hora de implementar una historia de usuario, el

cliente y los desarrolladores se renen para concretar y detallar lo que tiene que hacer

dicha historia. El tiempo de desarrollo ideal para una historia de usuario es entre 1 y 3

semanas.

Release planning: .Despus de tener ya definidas las historias de usuario es necesario

crear un plan de publicaciones, en ingls "Release plan", donde se indiquen las historias

de usuario que se crearn para cada versin del programa y las fechas en las que se

publicarn estas versiones. Un "Release plan" es una planificacin donde los

desarrolladores y clientes establecen los tiempos de implementacin ideales de las

historias de usuario, la prioridad con la que sern implementadas y las historias que

sern implementadas en cada versin del programa. Despus de un "Release plan"

tienen que estar claros estos cuatro factores: los objetivos que se deben cumplir (que son

principalmente las historias que se deben desarrollar en cada versin), el tiempo que

tardarn en desarrollarse y publicarse las versiones del programa, el nmero de personas

que trabajarn en el desarrollo y cmo se evaluar la calidad del trabajo realizado.

(*Release plan: Planificacin de publicaciones).

Iteraciones Todo proyecto que siga la metodologa X.P. se ha de dividir en iteraciones

de aproximadamente 3 semanas de duracin. Al comienzo de cada iteracin los clientes

deben seleccionar las historias de usuario definidas en el "Release planning" que sern

implementadas. Tambin se seleccionan las historias de usuario que no pasaron el test

de aceptacin que se realiz al terminar la iteracin anterior. Estas historias de usuario

son divididas en tareas de entre 1 y 3 das de duracin que se asignarn a los


28/97

programadores.

....... Velocidad del proyecto: La velocidad del proyecto es una medida que representa

la rapidez con la que se desarrolla el proyecto; estimarla es muy sencillo, basta con

contar el nmero de historias de usuario que se pueden implementar en una iteracin; de

esta forma, se sabr el cupo de historias que se pueden desarrollar en las distintas

iteraciones. Usando la velocidad del proyecto controlaremos que todas las tareas se

puedan desarrollar en el tiempo del que dispone la iteracin. Es conveniente reevaluar

esta medida cada 3 4 iteraciones y si se aprecia que no es adecuada hay que negociar

con el cliente un nuevo "Release Plan".

Programacin en pareja: La metodologa X.P. aconseja la programacin en parejaspues incrementa la productividad y la calidad del software desarrollado. El trabajo en

pareja involucra a dos programadores trabajando en el mismo equipo; mientras uno

codifica haciendo hincapi en la calidad de la funcin o mtodo que est

implementando, el otro analiza si ese mtodo o funcin es adecuado y est bien


29/97

diseado. De esta forma se consigue un cdigo y diseo con gran calidad.

Reuniones diarias. Es necesario que los desarrolladores se renan diariamente y

expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen

que ser fluidas y todo el mundo tiene que tener voz y voto.

2 Fase: Diseo.Diseos simples: La metodologa X.P sugiere que hay que conseguir

diseos simples y sencillos. Hay que procurar hacerlo todo lo menos complicado

posible para conseguir un diseo fcilmente entendible e implemntable que a la larga

costar menos tiempo y esfuerzo desarrollar.

Glosarios de trminos: Usar glosarios de trminos y un correcta especificacin de los

nombres de mtodos y clases ayudar a comprender el diseo y facilitar sus posteriores

ampliaciones y la reutilizacin del cdigo.

Riesgos: Si surgen problemas potenciales durante el diseo, X.P sugiere utilizar una

pareja de desarrolladores para que investiguen y reduzcan al mximo el riesgo que

Funcionalidad extra: Nunca se debe aadir funcionalidad extra al programa aunque sepiense que en un futuro ser utilizada. Slo el 10% de la misma es utilizada, lo que

implica que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos.

Refactorizar. Refactorizar es mejorar y modificar la estructura y codificacin de

cdigos ya creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo

estos cdigos para procurar optimizar su funcionamiento. Es muy comn rehusar

cdigos ya creados que contienen funcionalidades que no sern usadas y diseos

obsoletos. Esto es un error porque puede generar cdigo completamente inestable y muy

mal diseado; por este motivo, es necesario refactorizar cuando se va a utilizar cdigo

ya creado.

Tarjetas C.R.C. El uso de las tarjetas C.R.C (Class, Responsabilities and

Collaboration) permiten al programador centrarse y apreciar el desarrollo orientado a

objetos olvidndose de los malos hbitos de la programacin procedural clsica.

Las tarjetas C.R.C representan objetos; la clase a la que pertenece el objeto se puede

escribir en la parte de arriba de la tarjeta, en una columna a la izquierda se pueden


30/97

escribir las responsabilidades u objetivos que debe cumplir el objeto y a la derecha, las

clases que colaboran con cada responsabilidad. 3 Fase: Codificacin.

Como ya se dijo en la introduccin, el cliente es una parte ms del equipo de desarrollo;

su presencia es indispensable en las distintas fases de X.P. A la hora de codificar una

historia de usuario su presencia es an ms necesaria. No olvidemos que los clientes son

los que crean las historias de usuario y negocian los tiempos en los que sern

implementadas. Antes del desarrollo de cada historia de usuario el cliente debe

especificar detalladamente lo que sta har y tambin tendr que estar presente cuando

se realicen los test que verifiquen que la historia implementada cumple la funcionalidad

especificada.

La codificacin debe hacerse ateniendo a estndares de codificacin ya creados.

Programar bajo estndares mantiene el cdigo consistente y facilita su comprensin y

escalabilidad.

Crear test que prueben el funcionamiento de los distintos cdigos implementados nos

ayudar a desarrollar dicho cdigo. Crear estos test antes nos ayuda a saber qu es

exactamente lo que tiene que hacer el cdigo a implementar y sabremos que una vez

implementado pasar dichos test sin problemas ya que dicho cdigo ha sido diseado


31/97

para ese fin. Se puede dividir la funcionalidad que debe cumplir una tarea a programar

en pequeas unidades, de esta forma se crearn primero los test para cada unidad y a

continuacin se desarrollar dicha unidad, as poco a poco conseguiremos un desarrollo

que cumpla todos los requisitos especificados. Como ya se coment anteriormente, X.P

opta por la programacin en pareja ya que permite un cdigo ms eficiente y con una

gran calidad. X.P sugiere un modelo de trabajo usando repositorios de cdigo dnde las

parejas de programadores publican cada pocas horas sus cdigos implementados y

corregidos junto a los test que deben pasar. De esta forma el resto de programadores que

necesiten cdigos ajenos trabajarn siempre con las ltimas versiones. Para mantener un

cdigo consistente, publicar un cdigo en un repositorio es una accin exclusiva para

cada pareja de programadores X.P tambin propone un modelo de desarrollo colectivo

en el que todos los programadores estn implicados en todas las tareas; cualquiera

puede modificar o ampliar una clase o mtodo de otro programador si es necesario y

subirla al repositorio de cdigo. El permitir al resto de los programadores modificar

cdigos que no son suyos no supone ningn riesgo ya que para que un cdigo pueda ser

publicado en el repositorio tiene que pasar los test de funcionamiento definidos para el

mismo.

La optimizacin del cdigo siempre se debe dejar para el final. Hay que hacer que

funcione y que sea correcto, ms tarde se puede optimizar. X.P afirma que la mayora de

los proyectos que necesiten ms tiempo extra que el planificado para ser finalizados no

podrn ser terminados a tiempo se haga lo que se haga, aunque se aadan ms

desarrolladores y se incrementen los recursos. La solucin que plantea X.P es realizar

un nuevo "Release plan" para concretar los nuevos tiempos de publicacin y de

velocidad del proyecto. A la hora de codificar no seguimos la regla de X.P que aconseja

crear test de funcionamiento con entornos de desarrollo antes de programar. Nuestros

test los obtendremos de la especificacin de requisitos ya que en ella se especifican las

pruebas que deben pasar las distintas funcionalidades del programa, procurando

codificar pensando en las pruebas que debe pasar cada funcionalidad.

4 Fase: Pruebas. Uno de los pilares de la metodologa X.P es el uso de test para

comprobar el funcionamiento de los cdigos que vayamos implementando.

El uso de los test en X.P es el siguiente: Se deben crear las aplicaciones que realizarn

los test con un entorno de desarrollo especfico para test.

Hay que someter a tests las distintas clases del sistema omitiendo los mtodos mstriviales.


32/97

Se deben crear los test que pasarn los cdigos antes de implementarlos; en el apartado

anterior se explic la importancia de crear antes los test que el cdigo.

Un punto importante es crear test que no tengan ninguna dependencia del cdigo que en

un futuro evaluar. Hay que crear los test abstrayndose del futuro cdigo, de esta forma

aseguraremos la independencia del test respecto al cdigo que evala.

Como se coment anteriormente los distintos test se deben subir al repositorio de cdigo

acompaados del cdigo que verifican. Ningn cdigo puede ser publicado en el

repositorio sin que haya pasado su test de funcionamiento, de esta forma, aseguramos el

uso colectivo del cdigo (explicado en el apartado anterior).

El uso de los test es adecuado para observar la refactorizacin. Los test permiten

verificar que un cambio en la estructura de un cdigo no tiene porqu cambiar su

funcionamiento.


33/97

CONCLUSIONES

Despus de investigar y describir sobre las metodologas que ms se usan para la

realizacin de los sistemas de informacin se llega a la siguiente conclusin:

a. Existen muchos mtodos que podemos hacer uso para el desarrollo de un

sistema de informacin, sin importar si es un proyecto de largo o corto plazo.

b. Es muy indispensable el uso de estas metodologas, ya que nos van a

servir como una gua en nuestro proyecto, que si ponemos en

comparacin sobre un arquitecto que necesita de planos para hacer una casa

o un edificio, de igual forma un ingeniero necesita de un plano a seguir paraque pueda hacer un buen sistema de informacin. De igual forma reducen

costos y brinda flexibilidad a los proyectos de software donde la

incertidumbre est presente.

c. Todas las metodologas descritas lneas arriba son adecuadas, por lo tanto

depende de cmo o que manera lo usemos, ya que cada una de ellas requiere

tcnicas diferentes, y depende de recursos que estn disponibles para la

implementacin de la metodologa, como por ejemplo: en el caso de la

Metodologa RUP requiere un grupo grande de programadores para

empezar a trabajar con esta metodologa, en cambio con la Metodologa XP

Se requiere un grupo pequeo de programadores para trabajar con esta

metodologa y estos irn aumentando conforme sea necesario.

d. Debemos evitar retrasar las decisiones en el proyecto porque esto ocasiona

que el valor del producto incremente tanto para el cliente y la persona

quien est desarrollando el proyecto.

e. Para poder usar las diferentes metodologas se debe poseer conocimiento,

experiencia y capacidad para obtener resultados positivos.


34/97

Todo en el software cambia. Los requisitos cambian. El diseo cambia. El negocio cambia. La tecnologa cambia. El equipo

cambia. Los miembros del equipo cambian.

El problema no es el cambio en s mismo, puesto que sabemos queel cambio va a suceder; el problema es la incapacidad de

adaptarnos a dicho cambio cuando ste tiene lugar.

METODOLOGIA RATIONAL UNIFIED PROCESS (RUP) METODOLOGIA EXTREME PROGRAMMING (XP)

RUP Forma disciplinada de asignar tareas y responsabilidades en unaempresa de desarrollo (quin hace qu, cundo y cmo).

Mtodo pesado

Costo de cambio:

Un cambio en las etapas de vida del sistema incrementara

notablemente el costo.

XP Nace en busca de simplificar el desarrollo del softwarey que se lograra reducir el costo del proyecto.

Mtodo ligero:No produce demasiado overhead sobre las actividades de

desarrollo, y no impide el avance de nuestros proyectos.

Costo de cambio:

Reduce el costo del cambio en las etapas de vida del sistema.


35/97

Requiere un grupo grande de programadores para trabajar con estametodologa.

RUP es un marco del proyecto que describe una clase de los procesos queson iterativos e incrementales.

RUP define un manojo entero de las actividades y de los artefactos queusted necesita elegir de para construir sus el propios, proceso individual.

RUP es el proceso de desarrollo ms general de los existentesactualmente.

Los procesos de RUP estiman tareas y horario del plan midiendo lavelocidad de iteraciones concerniente a sus estimaciones originales. Las

iteraciones tempranas de proyectos conducidos RUP se enfocan

fuertemente sobre arquitectura del software; la puesta en prctica rpida de

caractersticas se retrasa hasta que se ha identificado y se ha probado una

arquitectura firme.

RUP proporciona muchas ventajas sobre XP le da nfasis en los requisitosy el diseo.

La ventaja principal de RUP es que se basa todo en las mejores prcticasque se han intentado y se han probado en el campo. (en comparacin conXP que se basa en las prcticas inestables que utilizaron juntas se evita que

se derribe).

Se requiere un grupo pequeo de programadores para trabajarcon esta metodologa entre 2 15 personas y estas irnaumentando conforme sea necesario.

Sus programadores pueden ser ordinarios.

Combina las que han demostrado ser las mejores prcticas dedesarrollo de software, y las lleva al extremo.

El desarrollo de software es riesgoso y difcil de controlar.

Se redisear todo el tiempo (refactoring), dejando el cdigosiempre en el estado ms simple posible.

Se harn pruebas todo el tiempo, no slo de cada nueva clase

(pruebas unitarias) sino que tambin los clientes comprobarnque el proyecto va satisfaciendo los

requisitos (pruebas funcionales).

Las pruebas de integracin se efectuarn siempre, antes de

aadir cualquier nueva clase al proyecto, o despus demodificar cualquiera existente (integracin

continua), utilizandoframeworks de testing, como elxUnit.

Las iteraciones sern radicalmente ms cortas de lo que esusual en otros mtodos, esto permite beneficiarse de la

retroalimentacin tan a menudo como sea posible.


36/97

RUP se divide en cuatro fases: Inicio(Define el alcance del proyecto) Elaboracin(definicin, anlisis, diseo) Construccin

(implementacin)Transicin (fin del proyecto y puesta en produccin)

Cada fase concluye con un HITO (T. Decisiones)

Planear las 4 fases incluye:Asignacin de tiempo

Hitos Principales

Iteraciones por Fases

Plan de proyecto.

XP define 4 variables para el proyecto de software:Coste

TiempoCalidad

Alcance.

XP tiene como valores lo siguiente:Comunicacin

Simplicidad

RealimentacinCoraje.

Este es un conjunto mnimo y consistente de valores que

permitirn hacer la vida ms fcil del grupo, la gerencia y los

clientes. Sirve tanto a los fines humanos como a los

comerciales.

XP deriva una docena de Principios Bsicos: Realimentacinrpida, Asumir la Simplicidad, El Cambio Incremental,

Adherirse (Abrazar) al Cambio, Trabajo de Alta Calidad(desde trabajo excelente hasta trabajo increblemente

sobresaliente).

XP desarrolla 4 actividades que guiarn el desarrollo:CodificarTestear

Atender

Disear.


37/97

RUP define nueve disciplinas a realizar en cada fase delproyecto:Modelado del negocio

Anlisis de requisitos

Anlisis y diseoImplementacinTestDistribucin

Gestin de configuracin y cambiosGestin del proyecto

Gestin del entorno

Iterativo e Incremental:

Doce practicas de XP:Jugar el juego de planificacin.

Hacer pequeos Releases.Hacer historias y usar metforas.

Disear simple.

ProbarTestear. RearmarRefactorizar. Programar

por pares. Propiedad

Colectiva. Integrar

Continuamente. Semanasde 40 horas. Cliente On-

Site.

Usar Standares de Codificacin

XP intenta reducir la complejidad del sw por medio de untrabajo orientado directamente al objetivo, basado en las

relaciones interpersonales y la velocidad de reaccin.

XP tiene una debilidad cuando se utiliza en dominios deaplicaciones complejas o situaciones difciles en la

organizacin: el rol del cliente no refleja los diferentes

intereses, habilidades y fuerzas a las que enfrentan los

programadores durante el desarrollo de proyectos.

XP define UserStories como base del software adesarrollar. Estas historias las escribe el cliente y describen

escenarios sobre el funcionamiento del

software, que no solo se limitan a la GUIsi no tambin pueden

describir el modelo, dominio, etc.


38/97

Cada fase en RUP puede descomponerse en iteraciones. Una iteracin es unciclo de desarrollo completo dando como resultado una entrega de productoejecutable (interna o externa)

El proceso define una serie de roles:Los roles se distribuyen entre los miembros del proyecto y que definen lastareas de cada uno y el resultado (artefactos) que se espera de ellos.

Todos los miembros del equipo comparten:1 Base de conocimiento1 Proceso1 Vista de cmo desarrollar software

1 Lenguaje de modelamiento (UML)

XP es un sistema de prcticas mnimas - le suponen utilizarlastodas en el principio de un proyecto y

adaptarlas y agregar los adicionales como cuando usted

experimenta la necesidad.

XP se puede ver tcnico como caso de RUP, aunque l separece ser algo diferente en cultura. En el hecho,racional incluso proporciona un XP plugin para su software de

RUP.

XP intenta minimizar el riesgo de fallo del proceso por mediode la disposicin permanente de un representante competente

del cliente a disposicin del equipo de desarrollo. Esterepresentante debera estar en

condiciones de contestar rpida y correctamente a cualquier

pregunta del equipo de desarrollo de forma que no se retrase la

toma de decisiones.

En XP, la programacin se hace en parejas, pero elcdigo pertenece al equipo completo, no a un

programador o pareja, de forma que cada programador puede

cambiar cualquier parte del cdigo en cualquier

momento si as lo necesita, dejndose en todo caso las mejoras

orientadas al rendimiento, para el final.

XP presenta un diseo evolutivo hace que no se le de apenasimportancia al anlisis como fase independiente, puesto que se

trabaja exclusivamente en funcin de las necesidades del

momento.


39/97

RUP realiza un levantamiento exhaustivo de requerimientos.

Busca detectar defectos en las fases iniciales.

Intenta reducir al nmero de cambios tanto como sea posible.

Realiza el Anlisis y diseo, tan completo como sea posible. Diseo

genrico, intenta anticiparse a futuras necesidades. Las necesidades

de clientes no son fciles de discernir.

Existe un contrato prefijado con los clientes.

El cliente interacta con el equipo de desarrollo mediante reuniones adiferencia de la metodologa XP que el cliente es parte del equipo (in situ).

Partes de XP:

Roles XP:

Programador (Programmer)Responsable de decisiones tcnicasResponsable de construir el sistema

Sin distincin entre analistas, diseadores o

codificadores

En XP, los programadores disean, programan y realizan las

pruebas

Jefe de Proyecto (Manager)Organiza y gua las reunionesAsegura condiciones adecuadas para el proyecto


40/97

Relaciones entre Productos de Desarrollo y Niveles de Prueba Cliente (Customer)Es parte del equipoDetermina qu construir y cundoEstablece las pruebas

funcionales

La metodologia a usar es el RUP: Segun los conceptos

Se asegura de que las pruebas func


41/97

3.3 ANALISIS

TABLA 1

TABLA3

Caso de

UsoCONSULTAR PROGRAMACION DE ENTREGAS

Actores Digitadora,

Cobrador,

Tipo Secundario

Descripcin El Cobrador le indica el ltimo pago del cliente a la Digitadora

entonces verifica en el sistema si coinciden si es verdad se programa

para una nueva entrega.

Caso de

Uso

REGISTRAR PAGOS

Actores Digitadora,

Cobrador,

Cajera

Tipo Primario

Descripcin El Cobrador trae la libreta de pagos de los clientes y le da a la Cajera

para que cuadre con el dinero. en efectivo

La Cajera le da la orden para que la Digitadora ingrese los datos.

Caso de

Uso

REGISTRAR CLIENTES

Actores Administrador,

Cliente,

Cajera

Tipo Primario

Descripcin El Cliente se acerca a la oficina da sus datos y el monto de dinero que

se desea recibir, a la cajera entonces recibe los datos y se los da al

administrador para que lo incorpore al sistema.

TABLA2


42/97

TABLA4

Caso de

Uso

CONSULTAR PAGOS

Actores Digitadora,

Cobrador,Cliente

Tipo Secundario

Descripcin EL Cliente pide su saldo, el Cobrador hace una llamada a la

Digitadora para que dicte los pagos pasa que si concilie los pagos con

lo que se encuentra en el sistema y poder distar el saldo.

TABLA5

Caso de

Uso

CONSULTAR CLIENTES ATRASADOS


Cobrador,

Tipo Secundario

Descripcin Administrador pide informacin al Cobrador para verificar los pagos

de los Clientes, lo cual si se pasaron de los 3 das de impago se cobra

una mora y si se paso del da del trmino se le cobrara una porcentaje

adicional.

TABLA6

Caso de

UsoINGRESAR AL SISTEMA


Gerente,

Digitadora

Tipo Primario

Descripcin El Gerente, Administrador, Digitadora sus claves son distintas lo cual

ambos no cumplen los mismos roles

TABLA7

Caso de

Uso

CONCILIACION DE COBRANZAS

Actores Gerente,

Cajera,

Tipo Primario

Descripcin La Cajera da el efectivo y el Gerente concilia si el efectivo coincide

con los ingreso de entrega en el sistema


43/97

TABLA8

Caso de

Uso

CONCILIACION DE ENTREGAS

Actores Gerente,

Cajera,

Administrador,

Tipo Primario

Descripcin El Gerente entrega el dinero a la Cajera lo cual la Cajera entrega el

dinero al Cliente y entonces se le consulta a la Digitadora para que

ingrese la entrega

TABLA9

Caso de

Uso

GENERAR REPORTE DE ENTREGAS

Actores Gerente,

Administrador,

Tipo Secundario

Descripcin El Gerente luego de ver las conciliaciones genera un reporte de

entregas lo cual interacta con el administrador en caso de hacer

correcciones como cambio de entregas o una entrega mltiple

TABLA10

Caso de

Uso

GENERAR REPORTE DE COBRANZAS

Actores Gerente,

Administrador,

Tipo Secundario

Descripcin El Gerente luego de ver las conciliaciones genera un reporte de

Cobranzas lo cual interacta con el administrador en caso de hacercorrecciones en el caso que el cliente para que reciba un nuevo

prstamo paga antes de la fecha, y tengas que hacer pagos rapidos


44/97

Grafico Caso de Uso 1



45/97




46/97




47/97




48/97




49/97

Cajera Registra los pagos y entrega el cambio

Cliente Recibe una entrega de dinero

Paga la entrega del dinero ms el inters

Gerente Inicia y Cierra el da

Administrador

del sistema

Incorpora nuevos usuarios, verifica los clientes atrasados

Modifica y elimina datos de los clientes

Caso de Uso General


50/97

Diagrama de Secuencia

TABLA1

TABLA2


51/97

TABLA 3

TABLA 4


52/97

TABLA 5

TABLA 6


53/97

TABLA 7


54/97

TABLA 8


55/97

TABLA 9


56/97

TABLA 10


57/97

Diagrama de Actividades

TABLA 1


58/97

TABLA 2


59/97

TABLA 3


60/97

TABLA 4

TABLA 5


61/97

TABLA 6

TABLA 7


62/97

TABLA 8

TABLA 9


63/97

TABLA 10


64/97

3.4 Diseo

3.4.1 Caso reales de Uso

3.3.2 Diagrama de Clase

3.5 Implementacin de la Base de Datos

3.5.1. Concepto de Base de Datos

Una base de datos o banco de datos (en ocasiones abreviada BB.DD.) es un conjunto

de datos pertenecientes a un mismo contexto y almacenados sistemticamente para

su posterior uso.


65/97

VENTAJAS DEL USO DE BASE DE DATOS

Obtener ms informacin de la misma cantidad de data - La base de datos facilita alusuario obtener mas informacin debido a la facilidad que provee esta estructura para

proveer datos a los usuarios (si se tiene el privilegio). Ejemplo: comparar un Centro de

Cmputos tradicional en COBOL vs uno que utilize una Base de Datos.

Compartir los Datos - Usuarios de distintas oficinas pueden compartir datos si estanautorizados. Esto implica que si un dato cambia de contenido como por ejemplo la

direccin de un cliente, todos los usuarios que pueden acceder ese dato, vern

inmediatamente el cambio efectuado. Ejemplo: Explicar cmo trabajaba un Centro de

Computos tradicional con un Sistema Estudiantil que tenga sub-sistemas de Registro,

Asistencia Economica, Estudio y Trabajo, Matrcula, etc.

Balance de Requerimientos Conflictivos - Para que la Base de Datos trabajeapropiadamente, necesita de una persona o grupo que se encargue de su

funcionamiento. El ttulo para esa posicin es Administrador de Base de Datos y

provee la ventaja de que Disea el sistema tomando en mente la necesidad de cada

departamento de la empresa. Por lo tanto se beneficia mayormente la empresa

aunque algunos departamentos podran tener leves desventajas debido a su

idiosincracia. Tradicionalmente se diseaba y programa segn la necesidad de cadadepartamento por separado. Ejemplo: Explicar cmo en diferentes departamentos

utilizaban diferentes herramientas y estructuras de datos para su sistema particular y

como esto afectaba a los otros departamentos.

Se refuerza la estandarizacin - Debido a lo que se mencion previamente, es ms facilestandarizar procesos, formas, nombres de datos, formas, etc.

Redundancia controlada - Debido al sistema tradicional de archivos independientes,los datos se duplicaban constantemente lo cual creaba mucha duplicidad de datos y

creaba un problema de sincronizacin cuando se actualizaba un dato en un archivo en

particular. Ejemplo: En el sistema de Registro y de Asistencia Econmica pasaba

mucho eso. El mtodo que utilizaron para resolver el problema fue el de

periodicamente actualizar el archivo de Asistencia Econmica, con el archivo de

registraduria (principal). Lo cual trae como consecuancia, uso inecesario de los

recursos de la computadora. Ojo!, la redundancia se controla, no se elimina por

completo.


66/97

Consistencia - Al controlarse la redundancia, cuando actualizas un dato, todos losusuarios autorizados de la Base de Datos pueden ver el cambio independientemente

de que estn trabajando en distintos sistemas.

Integridad - La base de datos tiene la capacidad de validar ciertas condiciones cuandolos usuarios entan datos y rechazar entradas que no cumplan con esas condiciones. El

DBA (Data Base Administrator) es responsable de establecer esas validaciones.

Seguridad - El DBA al tener control central de los Datos, la Base de Datos le proveemecanismos que le permiten crear niveles de seguridad para distintos tipos de

Usuarios. En COBOL esta opcin tendra que programarse.

Flexibilidad y rapidez al obtener datos - Aqui el usuario puede fcilmente obtenerinformacin de la Base de Datos con tan solo escribir unas breves oraciones. Esto evitael antiguo y burocrtico proceso de llenar una peticin al Centro de Cmputos para

poder obtener un informe. Ejemplo: Explicar como ocurra ese proceso.

Aumenta la productividad de los programadores - Debido a que los progamadores nose tienen que preocupar por la organizacin de los datos ni de su validacin, se pueden

concentrar en resolver otros problemas inmediatos, mejorando de ese modo su

productividad.

Mejora el mantenimiento de los programas - Debido a que los datos sonindependientes de los programas (a diferencia de Cobol), si ocurre un cambio en la

estructura de una tabla (archivo), el cdigo no se afecta. Ejemplo: Explicar el problema

de Cobol cuando ocurre un cambio de campo en un archivo an con el uso de libreras.

Independencia de los Datos - Debido a lo que se menciono previamente, los datospueden modificarse para por ejemplo mejorar el "performance" de la Base de Datos y

como consecuancia, no se tiene que modificar los programas.

3.4.2. Conversin del diagrama de clase a una Base de Datos

Cada tabla normalizada representa una entidad o clase de negocios. Por lo tanto, un

diagrama de clases se puede convertir en una lista de tablas normalizadas. Asmismo,

es posible dibujar una lista de tablas normalizadas como un diagrama de clases.

Tcnicamente, las entidades en un diagrama de clases no tienen que estar en la 3NF (o

posterior). Algunos diseadores utilizan un diagrama de clases como resumen, o


67/97

imagen general de los negocios, y dejan fuera algunos detalles normalizados. En esta

situacin, tendrn que convertirse las clases a una lista de tablas normalizadas.

Relaciones uno-a-muchos

La regla ms importante al convertir diagrama de clases a tablas normalizadas es que

las relaciones se manejan al colocar una columna comn en cada una de las tablas

relacionadas. Esta columna suele ser una llave en una de las tablas y este proceso es

fcil de apreciar con las relaciones uno-a-muchos.

Para convertir una relacin uno-a-muchos debe agregarse la llave primaria del lado

uno a la tabla del lado muchos. Esa llave agregada a la tabla del lado muchos no

formar parte de su llave primaria, sino que ser una columna comn.

Relaciones muchos-a-muchos

Los diagrama de clases resumidos suelen contener relaciones muchos-a-muchos. Sin

embargo, en una base de datos relacional, las relaciones muchos a muchos deben

dividirse en dos relaciones uno-a-muchos para llegar a la BCNF.

Cada una de las dos entidades iniciales (con una relacin muchos-a-muchos) seconvierte en una tabla. El paso siguiente es crear una tabla nueva, que contiene las

llaver primarias de las otras dos tablas. Esta tabla representa la relacin muchos-a-

muchos. Debe verificarse que las tres tablas estn en la 3NF, donde cada columna que

no es una llave depende de la llave completa y slo de la llave.

Asociaciones enarias

Las asociaciones enarias se representan con un diamante. Esta asociacin con undiamante tambin se vuelve una clase. En cierto sentido, una asociacin enaria es un

grupo de varias asociaciones binarias. La nueva clase de asociacin contiene la llave

primaria de cada una de las otras clases. Siempre y cuando las asociaciones binarias

sean uno-a-muchos, cada columna en la nueva clase de asociacin ser parte de la

llave primaria. Si por alguna razn una asociacin binaria es uno-a-uno, la columna

correspondiente no sera una llave.

Generalizacin o tipos secundarios


68/97

Al convertir este tipo de diseo a una base de datos relacional, existen 2 mtodos

bsicos.

1. Si los tipos secundarios son similares, puede ignorar las clases secundarias ycomprimirlas en la clase principal, la cual contendra todas las propiedades de

cada una de las clases secundarias.

2. En casi todos los casos, un mejor mtodo es crear tablas separadas para cadaclase secundaria. Cada tabla contendr la llave primaria de la clase principal

(superclase o clase padre). Adems debern agregarse atributos especficos a

cada uno de los tipos secundarios.

Asociaciones reflexivas

En ocasiones, una entidad puede vincularse consigo misma. Para hacer la conversin,

se crea una tabla con los atributos de esta entidad como columnas, y agregar como

otra columna el nombre dado al vnculo en la asociacin reflexiva.

Correspondencia entre clases y tablas

Toda clase se corresponde con una o ms tablas; de igual manera

que una clase tiene atributos, esos atributos pasan a ser atributos

de la tabla, aadiendo el ID del objeto y detalles como partes de la

formulacin del modelo de tablas, especificando que atributos

pueden o no ser nulos y asignando un dominio a cada atributo.

Correspondencia entre Asociaciones y Tablas

En trminos generales, una asociacin puede o no corresponderse

con una tabla ya que esto depende del tipo y multiplicidad de la

asociacin y; del criterio de quien disea la base de datos.

Puede presentarse el caso de asociaciones de Uno-a-muchos con

una clave externa en la tabla para la clase muchos

Tambin puede presentarse la asociacin de muchos-a-muchos,

extradas del diagrama de clases.

La asociacin muchos-a-muchos siempre se corresponde con unatabla concreta, satisfaciendo as la tercera forma normal.


69/97

Las claves primarias tanto la para las clases relacionadas como

para los atributos de enlace pasan a ser atributos de la tabla de

asociacin.

Correspondencia de las generalizaciones a Tablas

Esta correspondencia se basa en las clases con herencia simple, sin

embargo la correspondencia consiste en eliminar la tabla de

superclase y los atributos de la superclase se duplican para cada

subclase, esto le permite eliminar la navegacin de superclase a

subclases y as acelerar el proceso, manteniendo la tercera forma

normal.

3.4.3. Modelado Conceptual

3.4.3.1. Ciclo de Vida de las bases de datos

La primera etapa de un diseo de Base de Datos es el

diseo del modelo conceptual, en la cual se construye

el esquema de informacin que se maneja en el rea

documentaria, finalmente obtener una representacina travs de los diagramas.

La bases de datos son unos de los componentes

principales de un Sistema informtico; por lo que el

ciclo de vida de un sistema de informacin esta

inmerso directamente al ciclo de vida de la base de

daos sobre la que operar.

A continuacin se mencionan las etapas que implican

El ciclo de la base de datos:

Planificacin de la Base de Datos Definicin del Sistema, especificando el mbito y los lmites del uso y aplicacin de la base de datos.


70/97

Diseo de la Base de Datos Implementacin Mantenimiento.

El Modelo de Datos es el enfoque utilizado paradescribir y representar las

caractersticas y relacionesentre datos, dentro de la base de datos.

El Modelo Entidad Relacin (E/R), es un modelode datos compuesto por

objetos llamados entidades yrelaciones entre ellos; es el modelo utilizado en el

proceso de diseo y desarrollo de la Base de Datos del Sistema de Trmite

Documentario.

Es importante comprender que en un nivel ms cercano en la implementacin

el Modelo nos permite representar los datos y las relaciones entre los datos

mediante un conjunto de tablas que posteriormente construirn la estructura

de la base de datos.

Como principal elemento grfico del modelado de informacin, se tiene el

Diagrama Entidad-Relacin, el cual est compuesto de las entidades y sus

relaciones.

Es importante reconocer las entidades usadas por el sistema para disear el

diagrama Entidad / Relacin.

Para este proyecto al realizar la primera normalizacin se obtiene adems las

siguientes entidades:

El Modelo de Datos es el enfoque utilizado para describir y representar las

caractersticas y relaciones entre datos, dentro de la base de datos.

El Modelo Entidad Relacin (E/R),

Es importante comprender que en un nivel ms cercano en la implementacin

el Modelo nos permite representar los datos y las relaciones entre los datos

mediante un conjunto de tablas que posteriormente construirn la estructura

de la base de datos.

Como principal elemento grfico del modelado de informacin, se tiene el

Diagrama Entidad-Relacin, el cual est compuesto de las entidades y sus

relaciones. Es importante reconocer las entidades usadas por el sistema paradisear el diagrama Entidad / Relacin.


71/97

Para este proyecto al realizar la primera normalizacin se obtiene adems las

siguientes entidades:

Usuarios autorizados para acceder al sistema

1. Usuarios autorizados para acceder al sistema(USER_LIST)

2. Registro de Clientes(TD_REGISTRO_CLIENTE)

3. Registro de Pagos(TD_REGISTRO_Pago)4. Registro de Entrega (TD_REGISTRO_ENTREGA)

3.3.1. Tcnicas de NormalizacinLa normalizacin simplifica el diseo de una base de datos a travs de la

bsqueda de la mejor estructuracin de las entidades involucradas.

La normalizacin es el proceso mediante el cual se transforman datos

complejos a un conjunto de estructuras de datos ms pequeas, que adems

de ser ms simples y ms estables, son ms fciles de mantener

La Normalizacin se adopt porque el viejo estilo de poner todos los datos en

un solo lugar, como un archivo o tabla de la base de datos, era ineficiente y

conduca a errores de lgica cuando se trataba de manipular los datos.

Al modelar y crear una base datos es importante evitar puntos que crean

confusin, duplicacin de informacin y; por ende un mal funcionamiento y

exploracin de la informacin.

Es importante observar que la normalizacin nos permitir:

1. La recuperacin sencilla de datos2. Simplificar el mantenimiento de los datos. Se entiende la insercin,

eliminacin, modificaciones)

3. Minimiza el tiempo / costo para reorganizar los datos cuando serequieran implementar nuevas aplicaciones, mdulos, etc.


72/97

4. Elimina la informacin redundante y que muchas veces se registra enforma repetitiva.

5. Reduce el tamao de la base de datos6. Permite una mejor organizacin estructural en el diseo e

implementacin.

Existen cuatro Formas de Normalizacin, las mismas que se describen

brevemente:

Primera Forma de Normalizacin (1FN)

Un conjunto de relaciones esta en 1FN, si todos los atributos presentes en

stas son atmicos, es decir que cada campo debe de tener un nico valor

indivisible. Las relaciones de las entidades principales presentadas se

encuentran en primera forma normal.

En consecuencia establece que las columnas repetidas deben eliminarse y

colocarse en tablas separadas.

Segunda Forma de Normalizacin (2FN)

Se trabaja solo con aquellas relaciones que contienen dependencias

funcionales. Por ejemplo en la relacin Usuario, contiene atributos de

documentos que pueden o no presentar un Usuario, por lo tanto la

informacin en estos documentos obliga a la creacin de una tabla.

En consecuencia, establece que todas las dependencias parciales se deben

eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un

trmino que describe a aquellos datos que no dependen de la clave de la tablapara identificarlos.

Tercer Forma de Normalizacin (3FN)

La tercera y ltima forma de normalizacin establece que hay que eliminar y

separar cualquier dato que no sea clave.

Es decir el valor de esta columna debe depender de la clave. Todos los valores

deben identificarse nicamente por la clave.


73/97

Cuarta Forma Normal

Una tabla est en cuarta forma normal si y slo si para cualquier combinacin

clave campo no existen valores duplicados.

3.3.2. Modelado LgicoLa Arquitectura de Base de Datos, se divide en tres niveles: el nivel externo,

conceptual e interno.

En la grfica que se muestra a continuacin se puede observar estos tres

niveles:

Puesto por objetos llamados entidades y relaciones entre ellos; es el modelo

utilizado en el proceso de diseo y desarrollo de la Base de Datos del Sistema

de Trmite Documentario.

Nivel Externo

Nivel Interno

Nivel Conceptual

Usuarios

Diseo

Almacenamiento

Correspondencias

Correspondencias

A continuacin se describe el concepto de cada uno de los niveles:

Nivel Interno: es el nivel ms bajo de abstraccin y define como sealmacena la informacin en el soporte fsico.

Nivel Conceptual: es el nivel medio de abstraccin, se trata de larepresentacin de los datos del sistema de trmite documentario de la


74/97

Universidad Los ngeles de Chimbote, incluye la definicin de datos y la

relacin existente entre ellos.

Nivel externo:es el nivel de mayor abstraccin, se refiere a las diferentesnecesidades o requerimientos con respecto a la base de datos por parte

de los usuarios.

El modelo de arquitectura de base de datos, permite establecer el

principio de independencia de los datos; esta independencia puede ser

lgica y fsica.

3.3.3. Modelado FsicoUna vez que se han definido las entidades, sus relaciones y sus atributos o

caractersticas podemos centrarnos en los requerimientos de datos para cada

entidad.

Se desarrollar un diagrama de estructura de datos a partir del modelo

conceptual y del modelo lgico planteado y, sobre todo basndose en las

tcnicas de normalizacin indicadas.

Los componentes bsicos que se visualizarn en los diagramas o diseos de

estructura de datos son las entidades, atributos, apuntadores atributos y

apuntadores lgicos.

Los apuntadores atributos enlazan dos entidades mediante la informacin

comn usualmente un atributo llave en uno y, un atributo en el otro.

Los apuntadores lgicos identifican las relaciones entre las entidades; sirven

para obtener acceso inmediato a la informacin en una entidad.

Los atributos llave pueden ser de dos tipos: las llaves primarias (PK) * y las

llaves forneas (FK). *

* En ingls PK = Primary Key

* En ingls FK = Foreing Key


75/97

Con el software que se ha utilizado para el presente proyecto se podr

observar las entidades, los campos o atributos junto con el tipo de dato as

mismo los atributos llave.

TD_REGISTRO_CLIENTE


76/97

TD_REGISTRO_COBRADOR

TD_REGISTRO_ENTREGA

TD_REGISTRO_USUARIO


77/97


78/97

Pantalla de Login

Pantalla de Seguridad del Login


79/97

Carga del Sistema

Pantalla del Modulo Cobranza


80/97

Pantalla de Ingreso de Pago de Cobranza

Pantalla de Entrega de Dinero


81/97

Nueva entrega de Dinero

Cambiar Fecha de Nuevo Dia del Sistema


82/97

1.1. METODO DEL PROTOTIPO DEL SISTEMA1.1.1 FINALIDAD DE LOS PROTOTIPOS EN LOS SISTEMAS

El Modelo de prototipos que pertenece a los modelos de desarrolloevolutivo, El prototipo debe ser construido en poco tiempo, usando losprogramas adecuados y no se debe utilizar mucho dinero pues a partir de

que ste sea aprobado nosotros podemos iniciar el verdadero desarrollo

del software.

El diseo rpido se centra en una representacin de aquellos aspectos del

software que sern visibles para el cliente o el usuario final. Este diseo

conduce a la construccin de un prototipo, el cual es evaluado por el

cliente para una retroalimentacin; gracias a sta se refinan los requisitosdel software que se desarrollar. La interacin ocurre cuando el prototipo

se ajusta para satisfacer las necesidades del cliente. Esto permite que al

mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el

cliente vea resultados a corto plazo.


83/97

1.1.2 VENTAJAS DE USO DE PROTOTIPO Este modelo es til cuando el cliente conoce los objetivos generales

para el software, pero no identifica los requisitos detallados de

entrada, procesamiento o salida.

Tambin ofrece un mejor enfoque cuando el responsable deldesarrollo del software est inseguro de la eficacia de un algoritmo,

de la adaptabilidad de un sistema operativo o de la forma que debera

tomar la interaccin humano-mquina.

La construccin de prototipos se puede utilizar como un modelo del

proceso independiente, se emplea ms comnmente como una tcnica

susceptible de implementarse dentro del contexto de cualquiera de los

modelos del proceso expuestos. Sin importar la forma en que ste se

aplique, el paradigma de construccin de prototipos ayuda al

desarrollador de software y al cliente a entender de mejor manera cul

ser el resultado de la construccin cuando los requisitos estnsatisfechos. De esta manera, este ciclo de vida en particular, involucra al

cliente ms profundamente para adquirir el producto.

1.1.3 DESVENTAJAS DE USO DE PROTOTIPO

El usuario tiende a crearse unas expectativas cuando ve el prototipode cara al sistema final. A causa de la intencin de crear un prototipo

de forma rpida, se suelen desatender aspectos importantes, tales

como la calidad y el mantenimiento a largo plazo, lo que obliga en lamayor parte de los casos a reconstruirlo una vez que el prototipo ha

cumplido su funcin. Es frecuente que el usuario se muestre reacio a

ello y pida que sobre ese prototipo se construya el sistema final, lo

que lo convertira en un prototipo evolutivo, pero partiendo de un

estado poco recomendado.

En aras de desarrollar rpidamente el prototipo, el desarrollador sueletomar algunas decisiones de implementacin poco convenientes (por

ejemplo, elegir un lenguaje de programacin incorrecto porque

proporcione un desarrollo ms rpido). Con el paso del tiempo, el

desarrollador puede olvidarse de la razn que le llev a tomar tales

decisiones, con lo que se corre el riesgo de que dichas eleccionespasen a formar parte del sistema final.


84/97

1.1.3.1. REPETICIN DEL PROCESO LAS VECES QUE SEANECESARIO

El proceso antes descrito se repite varias veces; engeneral, son necesarias entre cuatro y seis iteraciones.

El proceso finaliza cuando los usuarios y analistas estn

de acuerdo en que el sistema ha evolucionado lo

suficiente como para incluir todas las caractersticas

necesarias o cuando ya es evidente que no se obtendrn

mayor beneficio con una iteracin adicional.

4.2. Prototipos de principales procesos

Se ha preparado los prototipos de los siguientes procesos:

INGRESO AL SISTEMA LISTADO DE ENTREGAS VENCIDAS INGRESO DE COBRADOR NUEVO USUARIO REGISTRO DE ENTREGA DIARIAS REGISTRO DE COBRANZA DIARIAS BUSCAR ENTREGAS DIARIAS LISTADO DE ENTREGA VENCIDA LISTADO DE ENTREGA ATRASADAS

FECHA CIERRE DE DIA CAMBIAR FECHA O RETROCEDER DE FECHA REPORTE DE ENTREGA DIARA REPORTE DE COBRANZA DIARIA CUADRE MENSUAL

4.3. Seguridad del SistemaEn lo que respecta a la seguridad del sistema se ha tenido en cuenta los requerimientos

de Seguridad de la Informacin del Sistema el cual est basado en la proteccin de los

datos y

seguridad de informacin. Para ello el sistema cuenta con una interfaz donde se valida

rgidamente el acceso al sistema el mismo que deber ser debidamente autorizado.

Es necesario asignar cuentas para el usuario y nivel de accesos para cada uno de ellos,

con la finalidad de definir a los procesos que tendr acceso navegar el usuario.

La creacin de los usuarios y sus respectivos permisos, sern debidamente asignados

por el administrador del sistema o quien haga sus veces.

Copias de Seguridad: Generacin y Restauracin

Como parte de la seguridad del sistema existe la generacin de las copias de seguridad

ya que la prdida de informacin se puede presentar por muchas causas tales como

dispositivos de almacenamientos malogrados o defectuosos, equipos robados, virusinformticos, etc. Por lo tanto frente a estas situaciones se hace necesario establecer un


85/97

plan para proteger los datos de la Institucin. Las copias de seguridad se realizarn

mediante el men principal, debiendo de tener el nivel y permiso necesario o las

funciones de administrador para realizar estos procesos, debindose realizar en la

frecuencia que se evale necesaria de acuerdo al volumen de informacin que se este

registrando o almacenando en la base de datos. Las copias de seguridad debern de

realizarse como mnimo en un nmero de 02 los cuales debern ser guardados uno alinterior de la institucin y otro en un lugar seguro pero fuera de la institucin.


86/97

5.1. ESTUDIO DE VIABILIDAD

Si bien es cierto que el factor econmico es imprescindible para evaluar la

viabilidad de cualquier proyecto se deben de tener en cuenta adems el aspecto

tecnolgico y operacional

5.1.1 Viabilidad Tecnolgica

La viabilidad tecnolgica determina si el sistema de cobranzas es viable

tecnolgicamente, es decir que existen herramientas tecnolgicas y equipos que

hagan posible su implementacin.

Por este motivo se realizo una evaluacin fsica a las instalaciones de la

EMPRESA WATCHING SERVICIOS GENERALES- SULLANA

Asimismo todos los equipos se encuentran debidamente conectados a una red

local con cableado estructurado topologa estrella; que se encuentra totalmente

operativa lo que garantiza que el sistema pueda trabajar en red.

En consecuencia se puede afirmar que el proyecto si tiene viabilidad

tecnolgica.

5.1.2 Viabilidad operacional

La viabilidad operacional consiste en analizar si se cuenta o no con el personal y

las instalaciones que permitan el buen funcionamiento y operatividad del

Sistema de cobranzas

En cuanto al personal necesario para poner en funcionamiento el sistema decobranzas es suficiente con el que cuenta actualmente la empresa

La infraestructura fsica o instalaciones con las que se cuenta actualmente son

suficientes.

En consecuencia se puede afirmar que el proyecto SI TIENE VIABLIDAD

OPERACIONAL.


87/97

5.1.3Viabilidad econmica

La viabilidad econmica determina si el valor econmico del proyecto es menor

que el beneficio producido por la implantacin del sistema.

La viabilidad econmica tambin considera si la inversin necesaria puede ser

asumida por la universidad para contribuir en el logro de sus metas y objetivos.

La pregunta a responder es si vale la pena invertir el dinero en el proyecto

propuesto y si la utilidad o el beneficio a obtener es considerable.

Este estudio de viabilidad econmica se orientar bsicamente en realizar una

evaluacin y una comparacin de dinero de los gastos de implementacin en

dos plataformas diferentes ya que no se podr evaluar ni considerar

equipamiento porque la universidad tiene equipos y no requiere de gastos en este

rubro, esta comparacin se realizar luego de unos clculos del proceso que se

denomina anlisis de costesbeneficios.

5.2. Anlisis de Costes - BeneficiosEl objetivo es conseguir una lista de todo lo que se requiere para

implementar el y una lista de Beneficios.

5.2.1. Costes para implantacinEs necesario realizar un anlisis serio y responsable de los costes

de implantacin del , que involucre todo el conjunto integral de

los gastos que implica.

Para efectos de la implantacin es necesario recordar que este

sistema funcionar en 17 equipos (5.1.1. Viabilidad Tecnolgica)

por lo tanto algunos de los clculos a realizar tomaran en cuenta

esta cantidad.


88/97

Los costes que sern tomados para la implantacin del Sistema de

cobranzas se basarn en dos alternativas:

a). Costos de Licenciamiento

ALTERNATIVA A: SOFTWARE LICENCIADO

CANT SOFTWARE P.UNIT. TOTAL

01 Windows Server 2003

Para servidor Incluye 5

Licencias para estaciones

4,409.00 4,409.00

16 Sistemas Operativos para

estaciones Windows XP

Profesional 578.00 9,248.00

11 Licencias CAL para que

las estaciones se conecten

con Windows 2003 Server

499.00 5,489.00

01 SQL Server 2005 para el

servidor con 5 Licencias

para estaciones

Administrador de bases de

datos 3,232.00 3,232.00


89/97

11 Licencias CAL para que

las estaciones se conecten

con SQL Server 500.00 5,500.00

01 Power Builder

Lenguaje Programacin

para desarrollo. 18,285.00 18,285.0

01 Racional Rouse

Para diseo UML 1,8000 1,800.0

TOTALLICENCIAMIENTO- 47,963.0

Tipo de cambio: S/. 3.40

ALTERNATIVA B: SOFTWARE LIBRE

El software considerado a continuacin est en el mismo

orden de las funciones que hace el software licenciado es

decir son sus equivalentes en software libre.

CANT

.

SOFTWARE P.UNIT. TOTAL

01 Linux - Debian

Para servidor 0.00 0.00

16 Sistemas Operativos para

estaciones Debian 0.00 0.00

11 Licencias CAL para que las


90/97

estaciones se conecten con

Servidor 0.00 0.00

01 MySql Administrador de

Bases de datos - Servidor 0.00 0.00

11 Licencias CAL para que las

estaciones se conecten con

MySql 0.00 0.00

01 PHP

Lenguaje para desarrollo. 0.00 0.00

01 Poseidon for UML - CE

Para diseo UML 0.00 0.00

01 Dbdesigner para disear las

bases de datos 0.00 0.00

TOTAL

LICENCIAMIENTO- 0.00

b) Costo de desarrollo del Software

Este monto lo constituye el monto fijado por el personal

especialista en el desarrollo de sistemas.

- Anlisis diseo, programacin eImplantacin

(S/. 1,000 mes * 6 meses) S/. 6,000.00

Total S/. 6,000.00

c) Costo de Equipo para el desarrollo


91/97

- Computador

(S/. 2.00 hora * 8 horas/dia *

6 dias/semana * 4 semanas/mes *

6 Meses) S/. 2,304.00

- Impresora (Pruebas y Reportes)

(S/. 0.50 hoja * 200 hojas mximo) S/. 200.00

Total S/. 2,504.00

d) Otros costos

Estos son los costos que son ocasionados por materiales de

oficina y algunos imprevistos

- Materiales de Oficina S/. 200.00

- Imprevistos S/. 200.00

Total S/. 400.00

Entonces en forma resumida tendremos la comparacin

siguiente:

ALTERNATIVA A: SOFTWARE LICENCIADO


92/97

DESCRIPCION TOTAL S/.

Licenciamiento de Software 47,963.00

Costo de desarrollo de Software 6,000.00

Costo de Equipos para el desarrollo 2,504.00

Otros Costos 400.00

Total Inversin 56,867.00

ALTERNATIVA A: SOFTWARE LIBRE

DESCRIPCION TOTAL S/.

Licenciamiento de Software 0.00

Costo de desarrollo de Software 6,000.00

Costo de Equipos para el desarrollo 2,504.00

Otros Costos 400.00

Total Inversin 8,904.00

5.2.2. Beneficios de la implementacin

Luego del presente estudio y luego de concluir que es

importante su implementacin podemos mencionar losbeneficios ms importantes que se lograran:

El sistema de cobranzas brindar tanto a los trabajadorescomo a los solicitantes informacin oportuna, segura,

actualizada y confiable.


93/97

Contribuir a la eficiencia y eficacia del proceso de pagosy entregas a los clientes

Se automatizar el registro, seguimiento y ubicacin delos expedientes presentados a la Universidad.

Permitir la ubicacin fsica en forma inmediata,confiable y oportuna de cualquier expediente.

Ahorrar tiempo para acceder a la informacin.

Contar con un historial de los expedientes que se hantramitado al interior en la Universidad Los ngeles de

Chimbote.

Permitir evaluar el desenvolvimiento de las diferentesoficinas de la universidad en lo que respecta al tiempo de

atencin o la frecuencia que atienden los expedientes que

ingresan a sus respectivas oficinas.

Disminuir el esfuerzo laboral del personal en el registro,seguimiento y ubicacin de los expedientes.

Seguridad y privacidad del trmite de la documentacin.

Se mejorar notablemente la atencin al pblicosolicitante y por ende mejorar la imagen institucional.

Otros beneficios como: reduccin de tasas de error,reduccin de prdidas de informacin, reduccin de tareas

y procesos manuales (menor costo).


94/97

5.2.3. Determinacin de la ejecucin del proyecto

Luego del anlisis de coste beneficio que hemos descrito

anteriormente podemos concluir que los beneficios que se vana obtener versus la inversin que significa la implantacin son

muchos mayores y satisfacen las necesidades de la institucin

acorde con sus polticas, visin y misin.

Por lo tanto la implantacin del sistema ce cobranzas

utili

INFORME-FINAL-JAVIERPEÑAGARCIA

Documents

Transcript of INFORME-FINAL-JAVIERPEÑAGARCIA