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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
7/97
CAPITULO I
MARCO TERICO CONCEPTUAL
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
9/97
1.1.1 Organigrama
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
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 2
Proyecto: Proyecto-SistemaCobra
Fecha: mi 26/10/11
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
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 3
Proyecto: Proyecto-SistemaCobra
Fecha: mi 26/10/11
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
13/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
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
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
14/97
Id Modo de
tarea
Nombre de tarea Duracin Comienzo Fin
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
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 2
Proyecto: Proyecto-SistemaCobra
Fecha: mi 26/10/11
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
15/97
Id Modo de
tarea
Nombre de tarea Duracin Comienzo Fin
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
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 3
Proyecto: Proyecto-SistemaCobra
Fecha: mi 26/10/11
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
16/97
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
17/97
CAPITULO II
ANLISIS DEL SISTEMA ACTUAL
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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?
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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?
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
21/97
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
22/97
CAPITULO III
ANALISIS Y DISEO DEL SISTEMA PROPUESTO
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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/Framework8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.html8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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)
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
Actores Administrador,
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
Actores Administrador,
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
44/97
Grafico Caso de Uso 1
Grafico Caso de Uso 2
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
45/97
Grafico Caso de Uso 3
Grafico Caso de Uso 4
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
46/97
Grafico Caso de Uso 5
Grafico Caso de Uso 6
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
47/97
Grafico Caso de Uso 7
Grafico Caso de Uso 8
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
48/97
Grafico Caso de Uso 9
Grafico Caso de Uso 10
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
50/97
Diagrama de Secuencia
TABLA1
TABLA2
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
51/97
TABLA 3
TABLA 4
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
52/97
TABLA 5
TABLA 6
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
53/97
TABLA 7
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
54/97
TABLA 8
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
55/97
TABLA 9
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
56/97
TABLA 10
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
57/97
Diagrama de Actividades
TABLA 1
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
58/97
TABLA 2
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
59/97
TABLA 3
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
60/97
TABLA 4
TABLA 5
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
61/97
TABLA 6
TABLA 7
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
62/97
TABLA 8
TABLA 9
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
63/97
TABLA 10
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
76/97
TD_REGISTRO_COBRADOR
TD_REGISTRO_ENTREGA
TD_REGISTRO_USUARIO
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
77/97
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
78/97
Pantalla de Login
Pantalla de Seguridad del Login
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
79/97
Carga del Sistema
Pantalla del Modulo Cobranza
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
80/97
Pantalla de Ingreso de Pago de Cobranza
Pantalla de Entrega de Dinero
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
81/97
Nueva entrega de Dinero
Cambiar Fecha de Nuevo Dia del Sistema
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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.
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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).
8/3/2019 INFORME-FINAL-JAVIERPEAGARCIA
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
Top Related