Proyecto Siba Ejemplo

Documentacin
del
Proyecto
Av. Corrientes 2367 (C1046AAB) C.A.B.A.

(54 11) 4555-5555
www.seruteniano.com.ar
info@seruteniano.com.ar
Universidad Tecnolgica Nacional

Facultad Regional Buenos Aires
Ingeniera en Sistemas de Informacin
Proyecto
Siba
K5051
NRO. CURSO
K5052
K5152
TURNO
AO
2008
TITULAR DE LA CTEDRA: LIC. CARLOS TOMASSINO

DOCENTES A CARGO DEL CURSO: LIC. CARLOS TOMASSINO
DOCENTES A CARGO DEL PROYECTO: GONZLEZ, MARIA CECILIA
SALEM, GABRIELA
SUASNBAR, MARIA JULIA
TRABAJO PRCTICO: TP Proyecto Final
TTULO PROYECTO: SIBA - Informatizacin del Instituto Buenos Aires
NOMBRE Y APELLIDO
LEGAJO N
Curso
EMAIL CONTACTO
Castro, Gabriel Edgardo

DAloia, Martn Miguel
Garca Prez, Jorge Lus
Gonzlez Lorenzo, Sebastin Carlos
116815-0
116842-3
116959-2
113199-0
K-5052
K-5052
K-5051
K-5152
gaecastro@gmail.com
martindaloia@gmail.com
jlgarciaperez@gmail.com
sebagonzalezlorenzo@gmail.com
Ser Uteniano Consulting

Proyecto: Informatizacin del IBA
Versin 2.0
FECHA 13/11/2008
Historial de Revisin
Fecha
Versin
Descripcin
Autor
11/07/2008
1.0 Creacin del documento unificado
Martn DAloia
15/08/2008
1.1 Correcciones de las secciones Referencia de

los CU.
Martn DAloia
Gabriel Castro
Correccin del orden del CU104 y CU105.

Correcciones de los diagramas de secuencia.
13/11/2008
13/11/2008
2.0 Actualizacin general.
Martn DAloia

Versin 2.0
FECHA 13/11/2008
ndice
ANLISIS ........................................................................................................................................ 8
ANLISIS PRELIMINAR ................................................................................................................................. 9
Resumen Ejecutivo ..............................................................................................................................10
Objetivo del Proyecto...........................................................................................................................10
Beneficios de la Informatizacin .........................................................................................................10
Descripcin de la situacin actual .......................................................................................................11
Descripcin de la solucin propuesta ..................................................................................................12
Vista General del Proyecto ..................................................................................................................12
Resultados de Cada Etapa ...................................................................................................................13
Alcances y Lmites ...............................................................................................................................13
Tiempo estimado de Implementacin ..................................................................................................14
ACTA DE PROYECTO ...................................................................................................................................15
Objetivo del Trabajo ............................................................................................................................16
Resumen Ejecutivo ..............................................................................................................................16
Objetivo del Proyecto...........................................................................................................................16
Vista General del Proyecto ..................................................................................................................17
Resultados de Cada Fase .....................................................................................................................17
Alcances y Lmites ...............................................................................................................................18
Cronograma de Trabajo ......................................................................................................................18
Plataforma Tecnolgica ......................................................................................................................18
Plataforma de desarrollo .....................................................................................................................19
Metodologas a utilizar ........................................................................................................................19
Definicin de Recursos Humanos .......................................................................................................20
Estructura propuesta ...........................................................................................................................21
ANLISIS DE RIESGOS .................................................................................................................................24
Identificacin de los Riesgos ...............................................................................................................25
Riesgos tcnicos ...............................................................................................................................25
Riesgos organizacionales .................................................................................................................25
Riesgos externos...............................................................................................................................25
Riesgos de Project Managment .........................................................................................................26
Anlisis de los Riesgos.........................................................................................................................27
Tabla de Anlisis de Riesgos ............................................................................................................27
Mitigacin y Contingencia ..................................................................................................................30
ANLISIS DE FACTIBILIDAD ........................................................................................................................31
Factibilidad tcnica .............................................................................................................................32
Factibilidad operativa..........................................................................................................................32
Factibilidad Econmica ......................................................................................................................33
Anlisis de los Ingresos Afectos a Impuestos .....................................................................................33
Anlisis de los Egresos Afectos a Impuestos......................................................................................33
Anlisis de los Gastos No Desembolsables........................................................................................36
Anlisis de los Ingresos No Afectos a Impuestos ...............................................................................38
Anlisis de los Egresos No Afectos a Impuestos ................................................................................38
Flujo de Caja ...................................................................................................................................38
Clculo y Anlisis del TIR ................................................................................................................43
Clculo y Anlisis del VAN...............................................................................................................43
ANLISIS DE REQUERIMIENTOS ..................................................................................................................44
Mdulo de Gestin de Cobranzas ..........................................................................................................45
Descripcin del Mdulo.......................................................................................................................46
Anlisis del CU101 Generar Listado de Dbitos ...............................................................................48
Descripcin del caso ........................................................................................................................48
13/11/2008

Versin 2.0
FECHA 13/11/2008
Especificacin ..................................................................................................................................48
Anlisis del CU102 Procesamiento de Resultados de los Dbitos ......................................................50
Especificacin ..................................................................................................................................50
Anlisis del CU103 Clientes sin Cuenta Bancaria ............................................................................52
Especificacin ..................................................................................................................................52
Anlisis del CU104 Generar Reporte de Morosos .............................................................................54
Especificacin ..................................................................................................................................54
Anlisis del CU105 Impresin de Recibos ........................................................................................56
Especificacin ..................................................................................................................................56
Anlisis del CU106 Imprimir Recibo ................................................................................................58
Especificacin ..................................................................................................................................58
Anlisis del CU107 Buscar Clientes con Deudas ..............................................................................59
Especificacin ..................................................................................................................................59
Anlisis del CU108 Generar Archivo Dbitos ...................................................................................60
Especificacin ..................................................................................................................................60
Anlisis del CU109 Convertir Archivo de Crditos ...........................................................................61
Especificacin ..................................................................................................................................61
Diagramas de Actividades ...................................................................................................................62
Generar Listado de Dbitos ..............................................................................................................62
Diagramas de Secuencia .....................................................................................................................63
Generar Listado de Dbitos ..............................................................................................................63
Diagramas de Estado...........................................................................................................................64
Gestin de Dbitos ...........................................................................................................................64
Mdulo de Situacin va Web ................................................................................................................65
Anlisis del CU201 Consulta de saldo ..............................................................................................67
Especificacin ..................................................................................................................................67
Anlisis del CU202 Consulta de Deudas...........................................................................................69
Especificacin ..................................................................................................................................69
Anlisis del CU203 Impresin Listado Deudas .................................................................................71
Especificacin ..................................................................................................................................71
Consulta de deudas ..........................................................................................................................72
Mdulo de Inscripcin ...........................................................................................................................73
Anlisis del CU301 Alta de Preinscripcin .......................................................................................75
Especificacin ..................................................................................................................................75
Anlisis del CU302 Administrar preinscripciones.............................................................................78
Especificacin ..................................................................................................................................78
Anlisis del CU303 Consulta de Estado de Preinscripcin ...............................................................80
Especificacin ..................................................................................................................................80
Administrar Preinscripciones ...........................................................................................................81
Alta de Preinscripciones ..................................................................................................................82
13/11/2008

Versin 2.0
FECHA 13/11/2008
Diagramas de Secuencia .....................................................................................................................83

Alta de Preinscripcin ......................................................................................................................83
Diagramas de Estado...........................................................................................................................84
Inscripcin .......................................................................................................................................84
Mdulo de Administracin de Datos .....................................................................................................85
Anlisis del CU401 Modificacin de Datos de Alumnos ...................................................................87
Especificacin ..................................................................................................................................87
Anlisis del CU402 Baja de Alumnos ...............................................................................................89
Especificacin ..................................................................................................................................89
Diagramas de Actividad.......................................................................................................................91
Administracin de Alumnos ..............................................................................................................91
Mdulo de Administracin de Seguridad ..............................................................................................92
Anlisis del CU501 Administracin de Permisos ..............................................................................94
Especificacin ..................................................................................................................................94
Anlisis del CU502 Administracin de Perfiles ................................................................................96
Especificacin ..................................................................................................................................96
Anlisis del CU503 Administracin de Usuarios ..............................................................................98
Especificacin ..................................................................................................................................98
Anexos del Anlisis ........................................................................................................................... 100
Diagramas de Secuencia de Logueo al Sistema ............................................................................... 100
DISEO ........................................................................................................................................ 101

DISEO DEL SISTEMA................................................................................................................................ 102
Diagrama de Dominio ....................................................................................................................... 103
Cliente ........................................................................................................................................... 103
Cuenta ........................................................................................................................................... 104
Inscripcin ..................................................................................................................................... 105
Diagrama de Entidad-Relacin (DER) .............................................................................................. 106
DISEO DE LA ARQUITECTURA ................................................................................................................. 107
Anlisis de requerimientos no funcionales y restricciones ................................................................. 108
Performance .................................................................................................................................. 108
Concurrencia ................................................................................................................................. 108
Transaccionalidad.......................................................................................................................... 108
Disponibilidad ............................................................................................................................... 108
Modificabilidad .............................................................................................................................. 108
Seguridad....................................................................................................................................... 109
Testeabilidad.................................................................................................................................. 109
Usabilidad ..................................................................................................................................... 109
Portabilidad ................................................................................................................................... 110
Tiempo ........................................................................................................................................... 110
Priorizacin de requerimientos no funcionales ................................................................................. 111
Arquitectura del sistema .................................................................................................................... 112
Tecnologa ..................................................................................................................................... 112
Estructura ...................................................................................................................................... 113
Capa de presentacin ..................................................................................................................... 114
Capa de negocio............................................................................................................................. 116
Capa de persistencia ...................................................................................................................... 117
Diagrama de Componentes............................................................................................................. 118
Diagrama de Despliegue ................................................................................................................ 119
13/11/2008

Versin 2.0
FECHA 13/11/2008
Conceptos transversales ................................................................................................................. 120

Software Configuration Management (SCM) .................................................................................... 123
Sistema de Control de Versiones..................................................................................................... 123
Herramienta de Software Project Managment................................................................................. 123
Herramientas de colaboracin ....................................................................................................... 124
Code Coverage (Cobertura del cdigo por medio de los Tests) ....................................................... 124
Bug Tracking, Issue Tracking y Project Management ...................................................................... 124
Tecnologa......................................................................................................................................... 126
Normas de codificacin ..................................................................................................................... 128
Documentacin ................................................................................................................................. 129
Administracin de riesgos arquitecturales ......................................................................................... 130
Diagrama del Framework de la Capa de Persistencia ....................................................................... 132
DAOs (Data Access Object)............................................................................................................ 133
Diagrama del Framework de la Capa de Presentacin ...................................................................... 135
INFORMES DE AVANCE ........................................................................................................... 138

Informe de avance al 09/05/2008....................................................................................................... 139
MINUTAS DE REUNIN ............................................................................................................ 149

Minuta de reunin del da 09/05/2008 ............................................................................................... 150
ANEXOS ....................................................................................................................................... 159

PRESENTACIN COMERCIAL..................................................................................................................... 160
VIDEO PUBLICITARIO ............................................................................................................................... 173
PLANIFICACIN ........................................................................................................................................ 180
13/11/2008

Versin 2.0
FECHA 13/11/2008
Anlisis
13/11/2008

Versin 2.0
FECHA 13/11/2008
Anlisis Preliminar
13/11/2008

Versin 2.0
FECHA 13/11/2008
Resumen Ejecutivo
A partir de la motivacin por parte del sector Directivo del Instituto surge la
necesidad de comenzar un proceso de informatizacin atacando los sectores ms crticos
actualmente para la operatoria diaria.
Para ello se ha detectado que la necesidad de automatizar el sistema de cobros y el
proceso de resultados de los mismos (los pagos de las cuotas se realizan por
transferencia electrnica) en un plazo no mayor a los 8 meses.
Esto le permitir reducir en un 80% la cantidad de tiempo insumido para generar
esta tarea. Tambin, al ser un proceso automatizado, se reducirn los errores humanos
generados en el proceso.
Paralelamente se plantea tambin la realizacin de un mdulo de preinscripciones
que permitir administrar con mayor eficiencia las mismas.
Objetivo del Proyecto

Manejar la informacin de los clientes referida al cobro de cuotas, generando el
archivo necesario para la entidad bancaria que maneja los debitos, estandarizando el
archivo segn las normas vigentes del banco.
Permitir imprimir los recibos de los clientes una vez recibida la respuesta del banco,
as como tambin las notificaciones de falta de pago correspondientes.
Realizar la gestin de cobranza de los clientes nuevos antes de poseer una cuenta
bancaria que le permita realizar el pago de la misma manera que los clientes existentes
tambin informando a los morosos de su situacin.
Suministrar informacin de los saldos adeudados y/o a pagar de los clientes de
manera Web.
Tener un modulo anexo que permita realizar la preinscripcin de los alumnos al
ciclo lectivo prximo, facilitando el tramite a los alumnos que cursan actualmente.
Beneficios de la Informatizacin
Entre las principales ventajas de implementar la informatizacin del sistema de
cobros y de inscripciones se pueden destacar las siguientes:
Automatizacin de la generacin del archivo solicitado por la entidad
bancaria
Reducir los tiempos utilizados para el procesamiento de los resultados
devueltos por la entidad bancaria
13/11/2008
10

Versin 2.0
Reducir
los
errores generados
FECHA 13/11/2008
por
el
procesamiento manual
de la
informacin
Permitir a los clientes consultar el estado del ltimo pago y los historiales va
Web
Realizar electrnicamente la preinscripcin de los alumnos, reduciendo
tiempos y papelerio
Administrar las preinscripciones recibidas electrnicamente
Informatizacin de los datos de los clientes
Posibilidad a futuro para agregar nuevos mdulos al sistema
Descripcin de la situacin actual

El Instituto Buenos Aires es una institucin de nivel secundario situada en el Partido
de Almirante Brown. Actualmente posee alrededor de 330 alumnos.
La problemtica principal que presenta es la ausencia de automatizacin del circuito
de cobro.
Hace dos aos comenz a realizar cobros de sus cuotas mediante dbitos
bancarios. Para esto se completa una planilla de clculo que mediante un script genera
un archivo con el formato que necesita el banco y se le enva por email. Luego de cada
fecha de cobro, el banco enva una respuesta indicando a quin se les pudo debitar la
cuota y a quin no.
Esto parece sencillo y es as porque la problemtica est en generar el listado de
cobro y asentar los pagos en un cuaderno que contiene toda la informacin al respecto.
Luego de esto, como la informacin no esta digitalizada, se deben hacer los recibos uno
por uno, teniendo en cuenta los diferentes tems e intereses de pagos atrasados.
Esta tarea requiere entre 4 y 5 das de una persona dedicada especialmente a la
misma. Adems de esto se agrega un costo de imagen en el caso de cometer errores,
cosa muy comn en un sistema manual y que ha pasado varias veces, ya que el dinero
es un tema sensible.
13/11/2008
11

Versin 2.0
FECHA 13/11/2008
Descripcin de la solucin propuesta

Realizar un sistema que principalmente mantenga la informacin de las cuentas de
los alumnos. A esto se le agregara un mdulo que genere automticamente la lista de
cobros con el formato establecido por el banco para que ste pueda ser enviado va email al banco al finalizar el proceso.
Una vez realizados los debitos, se recibe la respuesta del banco y se ingresa al
sistema para que actualice el estado de las cuentas de los clientes. Finalmente, nos dar
la opcin de imprimir los recibos generados automticamente, as como tambin las
notificaciones de falta de pago. Tambin permitir consultar por Web a los clientes el
saldo que debe pagar y, en caso de que exista, la deuda que posea.
Se confeccionar tambin un mdulo que permitir realizar la gestin de cobranza
de los clientes nuevos antes de poseer una cuenta bancaria que permita realizar el pago
de la misma manera que los clientes existentes. Este mdulo proporcionara a los
clientes, que por la razn que fuera no posean una cuenta bancaria donde se le pueda
debitar la cuota, la posibilidad de abonar en efectivo en el establecimiento escolar y
mantener el historial de pagos; y a la escuela tener toda la informacin de cobros
centralizada.
Adems incluir un mdulo que permita realizar la preinscripcin de los alumnos va
Web. Sin la necesidad de concurrir en diciembre a la escuela para reservar la vacante
como se hace actualmente. Esto facilitar la digitalizacin de los datos. ste mdulo
servir para los alumnos nuevos y los alumnos que concurren al establecimiento dndole
prioridad a stos ltimos.
El sistema ser con interfaz Web y permitir, segn la persona que ingrese,
(cliente, profesor, administrador, etc.) brindar para cada uno de ellos las funcionalidades
anteriormente detalladas.
Vista General del Proyecto

Se ha planteado dividir el proyecto en 2 fases.
En la primera fase se realizar el anlisis del sistema y el entorno y con ello se
generar el diseo propuesto para cumplir con los requerimientos solicitados. Adems se
13/11/2008
12

Versin 2.0
FECHA 13/11/2008
realizar una exposicin para mostrar la solucin propuesta. Esta fase est planificada
para ser terminada a principios de Julio de 2008.
En la segunda fase se realizar la codificacin del sistema, se realizarn las pruebas
de integracin necesarias y finalmente se pasar a produccin. Esta fase est planificada
para ser terminada a fines de Noviembre de 2008.
Resultados de Cada Etapa

Al finalizar cada hito planificado se tendr los entregables pertinentes a las tareas
realizadas. Esto nos permitir validar los requerimientos y continuar el desarrollo del
proyecto como as tambin detectar posibles problemas y cambios de forma temprana.
As mismo, hemos definido 2 grandes momentos (enunciados en el punto Vista
General del Proyecto) en los cuales se tendrn una serie de entregables que verificarn
las tareas desarrolladas.
Alcances y Lmites
Se proveer de los recursos humanos para el anlisis, diseo, desarrollo e
implementacin del sistema.
Se realizar una interfaz grfica bsica apropiada para correcta operacin del
sistema dejando la posibilidad de que pueda ser adaptada a los estilos visuales del
establecimiento.
Dado las diferencias que existen entre los diferentes navegadores existentes en el
mercado, el desarrollo se realizar enfocado primariamente a uno en particular.
Se desarrollar el mdulo principal del sistema que se encargar de generar: el
listado de cobro con los saldos deudores de cada cliente, el archivo con el formato que
necesita el banco para el debito de las cuotas.
Se desarrollar el mdulo que permita ingresar al sistema los pagos de los clientes
que abonan en efectivo en el establecimiento.
Se desarrollar el mdulo que permita a los clientes consultar va Web el saldo
deudor y el saldo a pagar de la prxima cuota.
Se desarrollar el mdulo que permita realizar una preinscripcin Web de los
alumnos.
Se crear la base de datos necesaria para desarrollar el sistema.
El desarrollo del producto se realizar especficamente para cubrir las necesidades
del Instituto Buenos Aires.
13/11/2008
13

Versin 2.0
FECHA 13/11/2008
Se usarn herramientas Open Source para el desarrollo.

No se proporcionar personal para el mantenimiento del sistema posterior a la
implementacin.
No se proporcionar hardware de ningn tipo para la implementacin del sistema.
Aclaracin: Si bien, esta etapa no contemplar el desarrollo de nuevos productos,
en caso que surgiera un producto que fuese considerado estratgico como para
adicionarlo al proyecto, ser necesario analizarlo y plantearlo como Cambio de Alcance
en el Proyecto.
Tiempo estimado de Implementacin

El tiempo estimado por cronograma del proyecto para que el sistema se encuentre
operativo es de 8 meses.
La fecha de Inicio del Proyecto se ha establecido para los primeros das de Abril del
2008.
13/11/2008
14

Versin 2.0
FECHA 13/11/2008
Acta de Proyecto
13/11/2008
15

Versin 2.0
FECHA 13/11/2008
Objetivo del Trabajo

Este documento tiene como objetivo principal presentar una propuesta Tcnica y
Operativa, acompaada del Plan de Proyecto, que tenga como eje principal la
implementacin de un nuevo software que integra el manejo de cuotas e inscripciones de
alumnos del Instituto Buenos Aires.
Resumen Ejecutivo
A partir de la inquietud por mejorar la operatoria de cobranza de cuotas y la
interaccin entre el los alumnos y el instituto, se plante como objetivo elaborar una
propuesta Tcnica y Operativa, acompaada del Plan de Proyecto correspondiente y para
ello, se realizaron un conjunto de actividades claves que se detallan a continuacin:
1. Se definieron los objetivos de la solucin
2. Se defini el alcance del proyecto y sus componentes
3. Se analiz la plataforma tecnolgica.
4. Se analiz la factibilidad tcnica y operativa.
Entre las caractersticas ms significativas encontradas, podemos mencionar:
1. Como resultado del relevamiento se detect deficiencia en el manejo de la
informacin, motivado por el almacenamiento no digitalizado, tanto en
velocidad como en errores.
2. Debe poder ampliarse la funcionalidad del sistema a futuro.
A partir de estas caractersticas y de las actividades desarrolladas, arribamos a la
siguiente conclusin:
La solucin se realizar en dos fases, comenzado por el anlisis de las operaciones
y finalizando con la codificacin e implementacin. La misma, adems de cubrir los
objetivos actuales, contemplar la futura integraron de otros sistemas (Arquitectura
Empresarial).
Objetivo del Proyecto

Manejar la informacin de los clientes referida al cobro de cuotas. Para esto se debe
generar el archivo que se entrega a la entidad bancaria que maneja los dbitos,
13/11/2008
16

Versin 2.0
FECHA 13/11/2008
estandarizando el archivo segn las normas vigentes del banco, y procesar el archivo de
respuesta.
Permitir imprimir los recibos de los clientes una vez recibida la respuesta del banco,
as como tambin visualizar las notificaciones de falta de pago correspondientes.
Permitir ingresar clientes al sistema, as como tambin sus pagos, antes de poseer
una cuenta bancaria para poder mantener sincronizado el estado de morosidad de los
mismos.
Suministrar informacin de los saldos adeudados y/o a pagar de los clientes de
manera Web.
Tener un modulo anexo que permita realizar la preinscripcin de los alumnos al
ciclo lectivo prximo, facilitando el tramite a los alumnos que cursan actualmente.
Vista General del Proyecto

Se ha planteado dividir el proyecto en 2 fases.
En la primera fase se realizar el anlisis del sistema y el entorno y con ello se
generar el diseo propuesto para cumplir con los requerimientos solicitados. Adems se
realizar una exposicin para mostrar la solucin propuesta. Esta fase est planificada
para ser terminada a principios de Julio de 2008.
En la segunda fase se realizar la codificacin del sistema, se realizarn las pruebas
de integracin necesarias y finalmente se pasar a produccin. Esta fase est planificada
para ser terminada a mediados de Noviembre de 2008.
Resultados de Cada Fase

Al finalizar cada hito planificado se tendr los entregables pertinentes a las tareas
realizadas. Esto nos permitir validar los requerimientos y continuar el desarrollo del
proyecto como as tambin detectar posibles problemas y cambios de forma temprana.
As mismo, hemos definido 2 grandes momentos (enunciados en el punto Vista
General del Proyecto) en los cuales se tendrn una serie de entregables que verificarn
las tareas desarrolladas.
13/11/2008
17

Versin 2.0
FECHA 13/11/2008
Alcances y Lmites
Se proveer de los recursos humanos para el anlisis, diseo, desarrollo e
implementacin del sistema.
Se realizar una interfaz grfica bsica apropiada para correcta operacin del
sistema dejando la posibilidad de que pueda ser adaptada a los estilos visuales del
establecimiento.
Dado las diferencias que existen entre los diferentes navegadores existentes en el
mercado, el desarrollo se realizar enfocado primariamente a uno en particular.
Se desarrollar el mdulo principal del sistema que se encargar de generar el
listado de cobro con los saldos deudores de cada cliente y el archivo con el formato que
necesita el banco para el debito de las cuotas.
Se desarrollar el mdulo que permita ingresar al sistema los pagos de los clientes
que abonan en efectivo en el establecimiento.
Se desarrollar el mdulo que permita a los clientes consultar va Web el saldo
deudor y el saldo a pagar de la prxima cuota.
Se desarrollar el mdulo que permita realizar una preinscripcin Web de los
alumnos.
Se crear la base de datos necesaria para desarrollar el sistema.
El desarrollo del producto se realizar especficamente para cubrir las necesidades
del Instituto Buenos Aires.
Se usarn herramientas Open Source para el desarrollo.
No se proporcionar personal para el mantenimiento del sistema posterior a la
implementacin.
No se proporcionar hardware de ningn tipo para la implementacin del sistema.
Cronograma de Trabajo
Para el desarrollo del Proyecto se elabor un plan de trabajo y un cronograma que
se adjunta como Anexo de este proyecto.
Plataforma Tecnolgica
Como resultado de un anlisis preliminar hemos constatado que la disponibilidad de
equipos del instituto es adecuada para la implementacin del sistema, por lo que no ser
necesario la compra de nuevo hardware. Se utilizarn los siguientes equipos:
13/11/2008
18

Versin 2.0
FECHA 13/11/2008
Sitio Central
1. Hardware: AMD 64
2. Sistema Operativo: Windows o Linux
3. Motor de Base de Datos: MySQL 5.0
4. Servidor Web: Apache Tomcat 6.0
5. Conexin a Internet
Puesto de trabajo estndar

1. Cualquier equipo que soporte la ejecucin de Firefox 2 o superior.
2. Conexin al Sitio Central por medio de red local o Internet.
Plataforma de desarrollo
Respecto de las herramientas a usar para el desarrollo del software asociado al
sistema en cuestin se utilizar lenguaje Java, bases de datos MySQL, Hibernate como
puente entre objetos y bases de datos relacionales, GWT para presentacin Web, Tomcat
como Servlet Container, Maven como herramienta para la gestin del proyecto de
software, SVN como repositorio para el control de versiones y Eclipse como IDE.
Aclaracin: Cabe aclarar que una vez comenzada la Fase de Desarrollo e
Implementacin del proyecto se efectuar nuevamente el anlisis de
infraestructura, lo que va a permitir contemplar soluciones nuevas que
aparezcan en el mercado de ese momento y que nos brinde la
posibilidad de implementar tecnologa de punta.
Metodologas a utilizar
Para llevar a cabo el desarrollo se utilizar un modelo modificado de desarrollo de
software denominado Cascada para poder afrontar los problemas que tiene el modelo
puro del mismo.
Se utilizar OOM (Object Oriented Method) para el anlisis, diseo y desarrollo de
la solucin y una parte del estndar UML (y de ser necesario se introducirn pequeos
cambios que ayuden a clarificar y transmitir mejor las ideas) como lenguaje de
documentacin.
13/11/2008
19

Versin 2.0
FECHA 13/11/2008
Definicin de Recursos Humanos

Un punto muy importante a tener en cuenta, y que puede resultar clave para llevar
a cabo el proyecto de manera exitosa, es la organizacin del equipo de desarrollo; es
decir que roles, responsabilidades y/o actividades llevarn adelante los integrantes del
equipo.
Si bien, en principio, cada integrante va a asumir un rol en particular, los mismos
son dinmicos y esto quiere decir que, por ejemplo, en determinada situacin un Analista
Programador puede realizar actividades propias de un Analista Funcional y viceversa. La
idea es que los roles no sean fijos ni estticos, y que cada uno pueda participar con
libertad y dar sus apreciaciones sobre tal o cual tema, siempre respetando el entorno y
contexto en el cual se trabaja.
Para este proyecto en particular hemos identificado los siguientes:
1. Lder de Proyecto
El lder de proyecto es pieza fundamental en el desarrollo y xito del mismo.
Deber planear, organizar y controlar el trabajo para lograr el objetivo del
proyecto. El lder de proyecto tiene la responsabilidad principal de proporcionar
liderazgo en la planificacin y organizacin del equipo de trabajo.
2. Lder Tcnico
Es el referente de la tecnologa a utilizar y ser el encargado de armar la
arquitectura del sistema y guiar el desarrollo del mismo.
3. Analista Programador
La labor fundamental de este ser la de definir y documentar los
requerimientos del sistema, especificar cmo implementar la solucin y
programarlo. Se necesitaran 2 (dos) puestos de trabajo para este rol.
4. Analista Funcional
Su principal aporte esta centrado en definir qu debe realizar el sistema a
nivel funcional. Este rol coordinar a los Analistas Programadotes.
5. Testers
Se encargarn de asegurar que el sistema realice lo que figura en las
especificaciones y reportar las conclusiones.
13/11/2008
Este Rol es fundamental para
20

Versin 2.0
FECHA 13/11/2008
asegurar un cierto nivel de calidad en el software. Los desarrolladores

mencionados arriba llevarn a cabo esta tarea.
6. Data Entry
Se necesitaran cargar los datos que posee la empresa de sus clientes para
poder realizar las pruebas del desarrollo (este recurso lo proveer el cliente y no
formar parte del grupo de desarrollo).
7. Key User
Dado que el desarrollo del sistema es a medida, este rol es fundamental
para validar los diseos funcionales del sistema. Aportando informacin
necesaria del negocio. La interaccin continua con esta persona ser vital para el
xito del proyecto. Tambin ser de vital importancia en la etapa de Test,
validando los desarrollos.
A nivel general podemos decir que las responsabilidades de cualquier miembro del
equipo que participe en el desarrollo e implementacin sern: ejecutar las tareas antes
detalladas, informar avances, analizar desvos, subsanar imprevistos, implementar y
documentar.
Por ltimo, la participacin (inicialmente parcial) del Sponsor ser el nexo entre el
instituto y el lder de proyecto.
Estructura propuesta
En el siguiente esquema se representa la disponibilidad requerida para cada uno

de los recursos durante las distintas etapas del ciclo de vida del proyecto:
13/11/2008
21

Versin 2.0
Recurso
Etapa
FECHA 13/11/2008
Anlisis
Diseo
Desarrollo
Testing
Lder de proyecto
Sponsor
Key User
Lder tcnico
Analista Funcional
Programador
Tester
Data-Entry
Matriz de roles y responsabilidades
Documento de
Anlisis
Preliminar
Documento de
Acta de
Proyecto
Documento de
Anlisis de
Riesgo
Documento de
Factibilidad
Documento de
Anlisis de
Funcionalidades
Documento de
Diseo del
Sistema
Documento de
Diseo de la
Arquitectura
Documento de
la
Funcionalidad
Generar Listado
de Dbitos para
el Banco
Documento de
la
Funcionalidad
Procesamiento
de Resultados
de los Dbitos
Documento de
la
Funcionalidad
Clientes sin
Cuenta
Bancaria
Documento de
la
Funcionalidad
Generacin de
Reporte de
Lder de
proyecto
Sponsor
Key
User
Aprueba
Aprueba
Participa
Realiza
Aprueba
Aprueba
Participa
Realiza
Lidera
Aprueba
Realiza
Lidera
Aprueba
Realiza
Revisa
Lder
tcnico
Aprueba
Analista
Funcional
Tester
Programador
Realiza
Revisa
Aprueba
Participa
Revisa
Aprueba
Participa
Revisa
Aprueba
Realiza
Revisa
Aprueba
Realiza
Revisa
Aprueba
Realiza
Revisa
Aprueba
Realiza
13/11/2008
Data
Entry
22

Versin 2.0
Lder de
proyecto
Morosos
Documento
Funcionalidad
Impresin de
Recibos
Documento
Funcionalidad
Consulta de
Saldo a Pagar
Documento
Funcionalidad
Consulta de
Deudas
Documento
Funcionalidad
Alta de
Preinscripcin
Documento
Funcionalidad
Administrador
de
Preinscripcin
Documento
Funcionalidad
ABM Datos de
Alumnos
Documento de
Diseo
Librera de
Interfaz
simulada
Desarrollo de
cada
funcionalidad
Documentacin
del desarrollo
Presentacin
final
Sponsor
Key
User
FECHA 13/11/2008
Lder
tcnico
Analista
Funcional
Revisa
Aprueba
Realiza
Revisa
Aprueba
Realiza
Revisa
Aprueba
Realiza
Revisa
Aprueba
Realiza
Revisa
Aprueba
Realiza
Revisa
Aprueba
Realiza
Aprueba
Revisa
Tester
Programador
Realiza
Revisa
Aprueba
Realiza
Aprueba
Valida
Lidera
Participa
Participa
Participa
Aprueba
Valida
Lidera
Participa
Participa
Participa
Aprueba
Participa
Participa
Participa
Participa
Aprueba
13/11/2008
Aprueba
Data
Entry
Participa
23

Versin 2.0
FECHA 13/11/2008
Anlisis de Riesgos
13/11/2008
24

Versin 2.0
FECHA 13/11/2008
Identificacin de los Riesgos

Los riesgos que identificamos y que eventualmente pueden impactar en el proyecto
son los que se detallan a continuacin, se encuentran separados en cuatro categoras
riesgos tcnicos, riesgos organizacionales, riesgos externos y riesgos de Project
Managment:
Riesgos tcnicos
1.
Dado que los procesos actuales se encuentran mal documentados o no existe

una documentacin formal que los avale, posiblemente el sistema cuente con
circuitos mal especificados.
2.
Dado que le aplicacin ser Web y en el instituto no se utiliza ningn sistema

Web para su operatoria actual, pude existir la posibilidad que la conexin a
Internet no sea la adecuada.
Riesgos organizacionales
3.
Dado que el personal del Sector de Administracin del instituto se encuentra

habituado
realizar
la
operatoria
de
forma
manual,
posiblemente
encontremos resistencia al cambio a la hora de realizar la prueba de

aceptacin por parte del usuario.
4.
Dado que los padres de los alumnos debern utilizar peridicamente el

sistema para la consulta de los saldos, posiblemente percibamos una
resistencia de parte de algunos padres que no estn acostumbrados a operara
a travs de aplicaciones Web.
Riesgos externos
5.
Como el archivo que genera al sistema para el banco esta totalmente

adaptado al estndar del mismo, si el banco decide cambiarlo quedar
inutilizado el mdulo que genera el archivo.
6.
Renuncia de personal del instituto, como por ejemplo el Key User, que es la
persona que ms conoce los procesos que el equipo necesita relevar para el
desarrollo del sistema.
13/11/2008
25

Versin 2.0
FECHA 13/11/2008
Riesgos de Project Managment

7.
Solicitud de una ampliacin de la funcionalidad acordada en un comienzo del

proyecto por parte del cliente.
8.
Estimacin no tan exactas ya que en momento de realizarla no se cuenta con

toda la informacin necesaria del proyecto y la persona encargada no cuenta
con experiencia en esta tarea.
13/11/2008
26

Versin 2.0
FECHA 13/11/2008
Anlisis de los Riesgos

Tabla de Anlisis de Riesgos
ID Prioridad
1
2
3
Alta
Media
Alta
Alta
Media
6
7
8
Baja
Baja
Alta
Descripcin
Probabilidad
de
ocurrencia
Impacto Exposicin
Procesos no documentados
Conexin insuficiente
Resistencia al cambio por
usuarios internos
Resistencia al cambio por
usuarios externos
Cambio de especificacin del
Banco
Desvinculacin de RRHH
Ampliacin de funcionalidad
Mala estimacin
Media
Media
Alta
Alto
Alto
Muy Alto
Media
Media
Media
Media
Medio
Baja
Baja
Muy Alto
Media
Media
Media
Media
Medio
Medio
Alto
Baja
Baja
Media
A continuacin se expone el anlisis efectuado para cada uno de los riesgos

identificados previamente:
Riesgo 01: Atrasos ocasionados por procesos no documentados o mal
documentados.
o
Fuente: El sector de administracin del instituto.
Condicin: Los procesos que se deben modelizar no se encuentran

documentados como corresponde.
Consecuencia: Se atrasara la etapa de extraccin de requerimientos

al usuario.
Clasificacin del Impacto: Administrativo.
Riesgo 02: Conexin de Internet insuficiente.

o
Fuente: El instituto.
Condicin: La conexin de Internet contratada actualmente no brinda

el ancho de banda necesario para la normal operatoria del sistema.
Consecuencia: El sistema no funcionaria correctamente una vez

puesto en marcha.
13/11/2008
Clasificacin del Impacto: Estratgico.
27

Versin 2.0
FECHA 13/11/2008
Riesgo 03: Resistencia al cambio por parte del usuario final interno al
Instituto.
o
Fuente: El sector de administracin del instituto.
Condicin: Un usuario del instituto no puede adaptarse al nuevo

sistema.
Consecuencia: El usuario se resistir a usar el nuevo sistema.
Clasificacin del Impacto: Estratgico, Administrativo.
Riesgo 04: Resistencia al cambio por parte de los usuarios finales externos al
Instituto.
o
Fuente: Los padres de los alumnos del instituto.
Condicin: Un padre de un alumno se resiste al uso de la nueva

interfaz externa del sistema.
Consecuencia: El usuario se resistir a usar el nuevo sistema.
Riesgo 05: Cambio de la especificacin del estndar del banco.

o
Fuente: El banco receptor de depsitos de los clientes.
Condicin: El banco cambia el formato de entrada del archivo.
Consecuencia: El archivo generado por el sistema no servir para

corresponder con el nuevo estndar.
Riesgo 06: Renuncia de personal del instituto.

o
Fuente: Personal del instituto.
Condicin: La renuncia de personal del instituto que nos deba

proporcionar la informacin necesaria para el desarrollo del sistema o
que deba realizar el testing del sistema.
Consecuencia: Se atrasara la etapa de extraccin de requerimientos

al usuario o la etapa de testing, dependiendo de la etapa en la que se
encuentre el proyecto.
Riesgo 07: Ampliacin de las funcionalidades solicitadas por el cliente.

o
Fuente: El cliente del sistema.
Condicin: El cliente solicita una funcionalidad que no estaba

acordada que realice el sistema.
13/11/2008
28

Versin 2.0
FECHA 13/11/2008
Consecuencia: Se retrasara el cronograma del proyecto.
Clasificacin del Impacto: Estratgico.
Riesgo 08: Mala estimacin.

o
Fuente: Lder de proyecto.
Condicin: La mala estimacin de tiempo y recurso al momento de

calendarizar el proyecto.
13/11/2008
Consecuencia: Se atrasara la puesta en marcha del nuevo sistema.
29

Versin 2.0
FECHA 13/11/2008
Mitigacin y Contingencia
Para cada uno de los riesgos analizados se definieron los siguientes planes de
accin:
1.
Se contar con el apoyo del personal de mayor cargo dentro del instituto que
nos brindar apoyo, toda la documentacin necesaria y los empleados de
mayor experiencia en los diversos procesos necesarios para el desarrollo del
proyecto reduciendo de esta forma la probabilidad de ocurrencia.
2.
Se contar con el apoyo del personal de mayor cargo dentro del instituto,
quien tendr el poder de decisin de contratar un nuevo proveedor de
Internet en caso de que el equipo de desarrollo lo sugiera.
3.
Se pondr en marcha un plan de capacitacin para los empleados de las reas

de administracin y contabilidad buscando de esta forma que los usuarios
conozcan y se acostumbren al uso del sistema reduciendo de esta forma la
probabilidad de ocurrencia como el impacto del riesgo.
4.
Se pondr en marcha un plan de capacitacin y difusin para los padres de los

alumnos, buscando de esta forma que conozcan y se acostumbren al uso del
sistema reduciendo de esta forma la probabilidad de ocurrencia como el
impacto del riesgo.
5.
Es un riesgo que existe, pero con una baja probabilidad por lo que no se
atacar en el proyecto.
6.
Se elevar el riesgo al Instituto para que realice una evaluacin del estado de
los recursos pertenecientes al proyecto y encare acciones preventivas para
mitigar el riesgo.
7.
Se mitigar el riesgo retrazando la puesta en marcha en caso de producirse.
8.
Se capacitar a la persona que realizara la estimacin y se le brindara la

mayor cantidad de informacin para reducir la probabilidad de ocurrencia.
13/11/2008
30

Versin 2.0
FECHA 13/11/2008
Anlisis de
Factibilidad
13/11/2008
31

Versin 2.0
FECHA 13/11/2008
Factibilidad tcnica
Luego de haber analizado la situacin tecnolgica en que se encuentra el instituto y
dado los requerimientos solicitados y detectados concluimos que es posible realizar el
proyecto sin inconvenientes. Las herramientas y lenguajes existentes en el mercado y
puntualmente las definidas en los puntos Plataforma Tecnolgica y Plataforma de
Desarrollo cumplen los requisitos necesarios y posibilitan el desarrollo conveniente del
proyecto.
Tambin podemos destacar que actualmente es muy sencillo conseguir en el
mercado muy buenos recursos humanos capacitados tcnicamente como para poder
llevar a cabo el desarrollo del proyecto en las plataformas especificadas.
Respecto al hardware necesario tanto para operar el sistema como para que sea
desarrollado, no se requiere ningn equipo especial. Con una PC de escritorio estndar
(microprocesador Pentium IV de 3.0 Ghz, 1 Gb de RAM y disco rgido de 80 Gb.) el
sistema puede operar y ser desarrollado sin presentar problema alguno.
Factibilidad operativa
Actualmente no existe ningn software que cumpla con las necesidades del
instituto. Es por este motivo que la realizacin de este proyecto es deseado fuertemente
por el sector directivo y el personal del instituto dado que supone una mejora en los
mtodos de trabajo y una consecuente reduccin de tiempos y errores humanos.
As tambin permitir continuar con la informatizacin de los procesos del instituto
a futuro permitindose que sea integrado al sistema a desarrollar como nuevos mdulos.
La interfaz del sistema posibilitar a los distintos usuarios hacer uso de sus
beneficios, sin necesidad de ser usuarios expertos dado que ser sencilla e intuitiva para
permitir a los nuevos usuarios familiarizarse con su uso y avanzar cada vez ms en el
conocimiento de las facilidades que posee el sistema.
Por los motivos enunciados anteriormente, el proyecto ser altamente factible
operativamente.
13/11/2008
32

Versin 2.0
FECHA 13/11/2008
Factibilidad Econmica
Anlisis de los Ingresos Afectos a Impuestos
En base a los datos proporcionados por el instituto, los ingresos que se esperan
obtener a lo largo de la vida til del nuevo sistema son los que se detallan a
continuacin.
Ingresos por Nuevos Alumnos

Concepto
C0
Nuevos Alumnos
Ingresos por Nuevos Alumnos
$
Subtotal Nuevos Alumnos: $
Total de Ingresos Afectos a Impuestos: $
Ingresos Afectos a Impuestos Por Perodo [$]

C1
C2
C3
-
$
$
$
240,000.00 $
240,000.00 $
240,000.00 $
288,000.00 $
288,000.00 $
288,000.00 $
360,000.00
360,000.00
360,000.00
Ingresos por Ahorros

Concepto
Reduccin de Costos
Costos de los Procesos
$
Subtotal Reduccin de Costos: $
Totales: $
Ahorro Neto Por Perodo [$]

C1
C2
C3
24,000.00 $
24,000.00 $
24,000.00 $
28,320.00 $
28,320.00 $
28,320.00 $
29,166.72
29,166.72
29,166.72
Anlisis de los Egresos Afectos a Impuestos

Dentro de ste rubro podemos encontrar los gastos que tiene el instituto por tener
que pagar los honorarios de las personas que llevarn adelante el proyecto, los
honorarios de las personas que en los prximos tres aos usarn el nuevo sistema y los
costos fijos que tendr a lo largo de la vida til del nuevo sistema.
Una aclaracin importante es que para el clculo de los sueldos no se ha tenido en
cuenta el ndice de inflacin, ya que resulta muy difcil establecer realmente cul es
realmente dicho ndice, y ms cmo se comportar de ac a tres aos. Con lo cual su
inclusin solo hubiera generado una evaluacin con un grado mayor de incertidumbre.
A continuacin se presenta un cuadro con el resumen anual, y en las siguientes
sub-secciones se podr encontrar el detalle de cada perodo.
13/11/2008
33

Versin 2.0
FECHA 13/11/2008
Concepto
Sueldos del Personal del Proyecto
Lder de Proyecto
Analista Funcional (SemiSenior)
Desarrollador (SemiSenior)
Tcnico en Redes
Subtotal Sueldos del Personal del Proyecto:
Sueldos del Personal del Instituto
Director
Vice Director
Personal Operativo de Cobros
Subtotal Sueldos del Personal del Instituto:
Total de Sueldos del Personal:
Sueldos del Personal Por Perodo [$]

C1
C2
C0
$
$
$
$
$
27,000.00
18,000.00
45,000.00
12,000.00
102,000.00
$
$
$
$
$
$
$
$
$
$
102,000.00
$
$
$
$
$
$
$
$
$
$
60,000.00
54,000.00
72,000.00
186,000.00
186,000.00
$
$
$
$
$
60,000.00
54,000.00
72,000.00
186,000.00
186,000.00
C3
$
$
$
$
$
$
$
$
$
$
60,000.00
54,000.00
72,000.00
186,000.00
186,000.00

En ste cuadro se pueden apreciar los costos asociados a tener que pagar los
sueldos de las personas que participan en el desarrollo del nuevo sistema.
Concepto
Lder de Proyecto
Analista Funcional (SemiSenior)
Desarrollador (SemiSenior)
Tcnico en Redes
Subtotal Sueldos del Personal del Proyecto:
Director
Vice Director
Periodo C0
Costo Sueldo [$]
Cant.
Hs./Hombre Total Hs. Sueldo Mes
1
1
3
1
$
$
$
$
$
28.13
18.75
15.63
12.50
75.00
0 $
0 $
0 $
$
$
75.00
960
960
960
960
3840
Total
$
$
$
$
$
4,500.00
3,000.00
2,500.00
2,000.00
12,000.00
$
27,000.00
$
18,000.00
$
45,000.00
$
12,000.00
$ 102,000.00
0 $
0 $
0 $
$
$
12,000.00
$
$
$
$
$ 102,000.00
Sueldos del Personal de Cobros

En ste cuadro se pueden apreciar los costos asociados a tener que pagar los
sueldos de las personas que emplearn el nuevo sistema a partir de la puesta en
produccin.
13/11/2008
34

Versin 2.0
Concepto
Director
Vice Director
Concepto
FECHA 13/11/2008
Periodo C1
Costo Sueldo [$]
Cant.
1 $
1 $
2 $
$
$
1920 $
5,000.00
4,500.00
1920 $
1920 $
3,000.00
$ 12,500.00
$ 12,500.00
Periodo C2
Costo Sueldo [$]
Cant.

Director
Vice Director
Concepto
Total
31.25
28.13
18.75
78.13
78.13
1 $
1 $
2 $
$
$
31.25
28.13
18.75
78.13
78.13
1920 $
1920 $
1920 $
$
$
$
$
$
$
$
Total
5,000.00
4,500.00
3,000.00
12,500.00
12,500.00
$
$
$
$
$
Periodo C3
Costo Sueldo [$]
Cant.

Director
Vice Director
1 $
1 $
2 $
$
$
31.25
28.13
18.75
78.13
78.13
1920 $
1920 $
1920 $
$
$
60,000.00
54,000.00
72,000.00
186,000.00
186,000.00
60,000.00
54,000.00
72,000.00
186,000.00
186,000.00
Total
5,000.00
4,500.00
3,000.00
12,500.00
12,500.00
$
$
$
$
$
60,000.00
54,000.00
72,000.00
186,000.00
186,000.00
Costos Fijos
En ste cuadro se pueden apreciar los costos fijos anuales asociados a tener
operativa la nueva solucin.
Concepto
Mantenimiento General
Mantenimiento del Software
Mantenimiento del Hardware
Subtotal Mantenimiento General:
Insumos
Insumos para PCs
Subtotal Insumos:
Comunicacin y Conexin
Telefona + Banda Ancha
Subtotal Comunicacin y Conexin:
Total de Costos Fijos:
Costos Fijos Por Perodo [$]

C1
C2
C0
C3
$
$
$
$
$
$
12,000.00 $
7,200.00 $
19,200.00 $
12,000.00 $
7,200.00 $
19,200.00 $
12,000.00
7,200.00
19,200.00
$
$
$
$
13,200.00 $
13,200.00 $
15,180.00 $
15,180.00 $
17,460.00
17,460.00
$
$
$
$
$
$
9,600.00 $
9,600.00 $
42,000.00 $
9,600.00 $
9,600.00 $
43,980.00 $
9,600.00
9,600.00
46,260.00
El detalle de cmo llegar a los nmeros anteriores en base a los costos estimados
por la empresa y el grupo de analistas se puede apreciar en los siguientes cuadros.
13/11/2008
35

Versin 2.0
Concepto
Insumos
Insumos para PCs
Subtotal Insumos:
Concepto
Insumos
Insumos para PCs
Subtotal Insumos:
Concepto
Insumos
Insumos para PCs
Subtotal Insumos:
FECHA 13/11/2008
Cantidad
Periodo C1
Costo Fijo [$]
Individual
Mensual
Anual
1 $
1 $
$
1,000.00 $
600.00 $
1,600.00 $
1,000.00 $
600.00 $
1,600.00 $
12,000.00
7,200.00
19,200.00
1 $
$
1,100.00 $
1,100.00 $
1,100.00 $
1,100.00 $
13,200.00
13,200.00
1 $
$
$
800.00 $
800.00 $
3,500.00 $
800.00 $
800.00 $
3,500.00 $
9,600.00
9,600.00
42,000.00
Cantidad
Periodo C2
Costo Fijo [$]
Individual
Mensual
Anual
1 $
1 $
$
1,000.00 $
600.00 $
1,600.00 $
1,000.00 $
600.00 $
1,600.00 $
12,000.00
7,200.00
19,200.00
1 $
$
1,265.00 $
1,265.00 $
1,265.00 $
1,265.00 $
15,180.00
15,180.00
1 $
$
$
800.00 $
800.00 $
3,665.00 $
800.00 $
800.00 $
3,665.00 $
9,600.00
9,600.00
43,980.00
Cantidad
Periodo C3
Costo Fijo [$]
Individual
Mensual
Anual
1 $
1 $
$
1,000.00 $
600.00 $
1,600.00 $
1,000.00 $
600.00 $
1,600.00 $
12,000.00
7,200.00
19,200.00
1 $
$
1,455.00 $
1,455.00 $
1,455.00 $
1,455.00 $
17,460.00
17,460.00
1 $
$
$
800.00 $
800.00 $
3,855.00 $
800.00 $
800.00 $
3,855.00 $
9,600.00
9,600.00
46,260.00
Anlisis de los Gastos No Desembolsables

Dentro de los Gastos No Desembolsables analizaremos aquellos generados por los
Bienes de Uso adquiridos como inversin para el proyecto.
A continuacin se presentan dos cuadros, en el primero de ellos se puede observar
los costos de cada uno de los Bienes de Uso; y en el segundo se pueden ver las
13/11/2008
36

Versin 2.0
FECHA 13/11/2008
depreciaciones de cada uno de stos bienes y el Valor Contable de cada bien en el ltimo
perodo de vida del proyecto.
Costos de los Bienes de Uso
Concepto
Cantidad
Hardware de PC
Workstation (Dell Vostro 200 Slim Tower)
4
Monitor (Dell 1708FP)
4
Servidor (Dell PowerEdge 1900)
1
Impresora (HP Color LaserJet CM1015 MFP)
2
Subtotal Hardware de PC:
Intranet
Router Linksys
1
Bocas de Red 10/100
4
Cableado UTP-5
100
Subtotal Intranet:
Mobiliario de Oficina
Escritorio de PC P/ Oficina
4
Escritorio P/ Impresoras
2
Subtotal Mobiliario de Oficina:
Licencias de Sofware
Microsoft Windows XP SP2 Professional Edition
4
Microsoft Office 2003 Professional Edition
4
Subtotal Licencias de Sofware:
Total Bienes de Uso:
Valor Unitario
[$]
Valor Total
[$]
$
$
$
$
$
1,600.00
1,200.00
5,500.00
1,500.00
9,800.00
$
$
$
$
$
6,400.00
4,800.00
5,500.00
3,000.00
19,700.00
$
$
$
$
300.00
10.00
0.90
310.90
$
$
$
$
300.00
40.00
90.00
430.00
$
$
$
250.00 $
150.00 $
400.00 $
1,000.00
300.00
1,300.00
$
$
$
$
1,800.00
2,400.00
4,200.00
25,630.00
$
$
$
$
450.00
600.00
1,050.00
11,560.90
Depreciaciones de los Bienes de Uso

Valor Total
[$]
Concepto
Hardware de PC
Workstation (Dell Vostro 200 Slim Tower)
Monitor (Dell 1708FP)
Servidor (Dell PowerEdge 1900)
Impresora (HP Color LaserJet CM1015 MFP)
Subtotal Hardware de PC:
Intranet
Router Linksys
Bocas de Red 10/100
Cableado UTP-5
Subtotal Intranet:
Escritorio de PC P/ Oficina
Escritorio P/ Impresoras
Subtotal Mobiliario de Oficina:
Microsoft Windows XP SP2 Professional Edition
Microsoft Office 2003 Professional Edition
Subtotal Licencias de Sofware:
Total Depreciaciones:
13/11/2008
$
$
$
$
$
6,400.00
4,800.00
5,500.00
3,000.00
19,700.00
$
$
$
$
Vida Depreciacin Depreciacin

til
Anual
Total
[Aos]
[$]
[$]
Valor
Contable
[$]
$
$
$
$
$
2,133.33
1,600.00
1,833.33
1,000.00
6,566.67
$
$
$
$
$
6,400.00
4,800.00
5,500.00
3,000.00
19,700.00
$
$
$
$
$
300.00
40.00
90.00
430.00
5 $
5 $
5 $
$
60.00
8.00
18.00
86.00
$
$
$
$
180.00
24.00
54.00
258.00
$
$
$
$
120.00
16.00
36.00
172.00
$
$
$
1,000.00
300.00
1,300.00
10 $
10 $
$
300.00 $
90.00 $
300.00 $
700.00
210.00
700.00
$
$
$
$
1,800.00
2,400.00
4,200.00
25,630.00
3 $
3 $
$
$
3
3
3
3
100.00 $
30.00 $
100.00 $
600.00
800.00
1,400.00
8,152.67
$
$
$
$
1,800.00
2,400.00
4,200.00
24,458.00
37
$
$
$
$
872.00

Versin 2.0
FECHA 13/11/2008
Anlisis de los Ingresos No Afectos a Impuestos

El nico tem que queda abarcado bajo ste concepto es el prstamo que deber
pedir el Instituto Buenos Aires para llevar adelante el proyecto.
Detalle del Prstamo

Concepto
Prstamo
Perodo
0
1
2
3
Total:
Datos del Prstamo

Principal de
Plazo de
Tasa de
la Deuda
Pago
Inters
$ 30,000.00
3
8%
Flujo del Prstamo (Mtodo Francs)

Cuota
Interes
Saldo de
la Deuda
Amortizada
Amortizado
$ 30,000.00 $
$ 20,758.99 $
$ 10,778.71 $
$
0.00 $
Capital
Amortizado
(11,641.01) $ (2,400.00) $
(9,241.01)
(11,641.01) $ (1,660.72) $
(9,980.29)
(11,641.01) $
(862.30) $ (10,778.71)
(34,923.02)
Anlisis de los Egresos No Afectos a Impuestos

Dentro de ste rubro podemos encontrar dos tems, la amortizacin del prstamo
pedido al Banco Supervielle y los costos de la inversin inicial del proyecto en Bienes de
Uso.
Amortizacin del Prstamo

En base al detalle del prstamo pedido, los intereses y el capital amortizado por
perodo son los que se detallan a continuacin.
Concepto
Prstamo
$
Amortizacin de Intereses de Prstamos $
Concepto
Prstamo
$
Amortizacin de Capital de Prstamos $
Intereses Amortizado Por Perodo [$]

1
2
3
(2,400.00) $ (1,660.72) $
(862.30)
(2,400.00) $ (1,660.72) $
(862.30)
Capital Amortizado Por Perodo [$]
1
2
3
(9,241.01) $ (9,980.29) $ (10,778.71)
(9,241.01) $ (9,980.29) $ (10,778.71)
Inversin en Bienes de Uso

Remitirse a la seccin 0 Costos de los Bienes de Uso.
Flujo de Caja
A continuacin se presentan los dos flujos de caja pedidos, teniendo y no teniendo
en cuenta el prstamo.
(Ver cuadro en hoja siguiente)
13/11/2008
38

Versin 2.0
FECHA 13/11/2008
Tomando en Cuenta el Prstamo

Perodos
C0
Ao 0
Ingresos Afectos a Impuestos
Ingresos
Nuevos Alumnos
$
Ahorros
Reduccin de Costos
$
Total Ingresos Afectos a Impuestos: $
Egresos Afectos a Impuestos
Sueldos
Amortizacin de Intereses de Prstamos
Insumos
Total Egresos Afectos a Impuestos:
C2
Ao 2
C3
Ao 3
240,000.00 $
288,000.00 $
360,000.00
$
$
24,000.00 $
264,000.00 $
28,320.00 $
316,320.00 $
29,166.72
389,166.72
$
$
$
$
$
$
$
(102,000.00)
(102,000.00)
$
$
$
$
$
$
$
(186,000.00)
(2,400.00)
(19,200.00)
(13,200.00)
(9,600.00)
(230,400.00)
$
$
$
$
$
$
$
(186,000.00)
(1,660.72)
(19,200.00)
(15,180.00)
(9,600.00)
(231,640.72)
$
$
$
$
$
$
$
(186,000.00)
(862.30)
(19,200.00)
(17,460.00)
(9,600.00)
(233,122.30)
$
$
$
$
$
$
$
(102,000.00)
(102,000.00)
35,700.00
(66,300.00)
$
$
$
$
$
$
$
(8,152.67)
(8,152.67)
(238,552.67)
25,447.33
(8,906.57)
16,540.77
$
$
$
$
$
$
$
(8,152.67)
(8,152.67)
(239,793.39)
76,526.61
(26,784.31)
49,742.30
$
$
$
$
$
$
$
(8,152.67)
(872.00)
(9,024.67)
(242,146.96)
147,019.76
(51,456.91)
95,562.84
8,152.67 $
$
8,152.67 $
8,152.67 $
$
8,152.67 $
8,152.67
872.00
9,024.67
Gastos No Desembolsados
Depreciacin
Valor Contable
Total Gastos No Desembolsados:
Total de Egresos:
Utilidad Antes de Impuestos:
Impuestos:
Utilidad Neta Despus de Impuestos:
Ajustes Gastos No Desembolsados
Depreciacin
Valor Contable
Total Ajustes Gastos No Desembolsados:
Ingresos No Afectos a Impuestos
Prstamos
Otros Ingresos (No Aplica)
Total Ingresos No Afectos a Impuestos:
$
$
$
$
$
$
30,000.00 $
$
30,000.00 $
Egresos No Afectos a Impuestos

Amortizacin de Capital de Prstamos
Hardware de PC
Intranet
Total Egresos No Afectos a Impuestos:
FLUJO DE CAJA (Con Prstamo)
$
$
$
$
$
$
$
(19,700.00)
(430.00)
(1,300.00)
(4,200.00)
(25,630.00)
(61,930.00)
VAN: $
TIR:
38,508.61
47%
13/11/2008
C1
Ao 1
$
$
$
$
$
$
$
$
$
$
(9,241.01)
(9,241.01)
15,452.43
$
$
$
$
$
$
$
$
$
$
(9,980.29)
(9,980.29)
47,914.68
$
$
$
$
$
$
$
$
$
$
(10,778.71)
(10,778.71)
93,808.80
39

Versin 2.0
FECHA 13/11/2008
Flujo de Caja (Con Prstamo)

$ 120,000.00
$ 100,000.00
$ 93,808.80
$ 80,000.00
$ 60,000.00
$ 47,914.68
$ 40,000.00
$ 15,452.43
$ 20,000.00
$C0
C1
C2
C3
$ (20,000.00)
$ (40,000.00)
$ (60,000.00)
$ (61,930.00)
$ (80,000.00)
Perodos
13/11/2008
40

Versin 2.0
FECHA 13/11/2008
Sin Tomar en Cuenta el Prstamo
No Tomando en Cuenta el Prstamo

Perodos
C0
Ao 0
Ingresos Afectos a Impuestos
Ingresos
Nuevos Alumnos
$
Ahorros
Reduccin de Costos
$
Total Ingresos Afectos a Impuestos: $
Egresos Afectos a Impuestos
Sueldos
Amortizacin de Intereses de Prstamos
Insumos
Total Egresos Afectos a Impuestos:
C1
Ao 1
C2
Ao 2
C3
Ao 3
240,000.00 $
288,000.00 $
360,000.00
$
$
24,000.00 $
264,000.00 $
28,320.00 $
316,320.00 $
29,166.72
389,166.72
$ (102,000.00) $
$
$ (186,000.00)
$
$
$
$ (19,200.00)
$
$ (13,200.00)
$
$
(9,600.00)
$ (102,000.00) $ (228,000.00)
$
$
$
$
$
$
$
(186,000.00)
(19,200.00)
(15,180.00)
(9,600.00)
(229,980.00)
$
$
$
$
$
$
$
(186,000.00)
(19,200.00)
(17,460.00)
(9,600.00)
(232,260.00)
$
$
(8,152.67) $
$
$
$
$
$
(8,152.67) $
$ (102,000.00) $ (236,152.67) $
$ (102,000.00) $
27,847.33 $
$
35,700.00 $
(9,746.57) $
$
(66,300.00) $
18,100.77 $
(8,152.67)
(8,152.67)
(238,132.67)
78,187.33
(27,365.57)
50,821.77
$
$
$
$
$
$
$
(8,152.67)
(872.00)
(9,024.67)
(241,284.67)
147,882.05
(51,758.72)
96,123.33
8,152.67
872.00
9,024.67
Gastos No Desembolsados
Depreciacin
Valor Contable
Total Gastos No Desembolsados:
Total de Egresos:
Utilidad Antes de Impuestos:
Impuestos:
Utilidad Neta Despus de Impuestos:
Ajustes Gastos No Desembolsados
Depreciacin
Valor Contable
Total Ajustes Gastos No Desembolsados:
Ingresos No Afectos a Impuestos
Prstamos
Otros Ingresos (No Aplica)
Total Ingresos No Afectos a Impuestos:
$
$
$
$
$
$
8,152.67 $
$
8,152.67 $
8,152.67 $
$
8,152.67 $
$
$
$
$
$
$
Egresos No Afectos a Impuestos

Amortizacin de Capital de Prstamos
Hardware de PC
Intranet
Total Egresos No Afectos a Impuestos:
FLUJO DE CAJA (Sin Prstamo)
$
$
$
$
$
$
$
(19,700.00)
(430.00)
(1,300.00)
(4,200.00)
(25,630.00)
(91,930.00)
VAN: $
TIR:
98,445.87
37%
13/11/2008
$
$
$
$
$
$
$
26,253.43
$
$
$
$
$
$
$
$
$
$
58,974.43
$
$
$
$
$
$
$
$
$
$
105,148.00
41

Versin 2.0
FECHA 13/11/2008
Flujo de Caja (Sin Prstamo)

$ 150,000.00
$ 105,148.00
$ 100,000.00
$ 58,974.43
$ 50,000.00
$ 26,253.43
$C0
C1
C2
C3
$ (50,000.00)
$ (100,000.00)
$ (91,930.00)
$ (150,000.00)
Perodos
13/11/2008
42

Versin 2.0
FECHA 13/11/2008
Clculo y Anlisis del TIR

El TIR esperado tomando en cuenta el prstamo es del 47%. Esto es ms que
satisfactorio tomando en cuenta la Tasa de Corte propuesta por el Instituto Buenos Aires
es del 20%.
Sin tomar en cuenta el prstamo solicitado, el TIR desciende a 37%. Esto se debe a
que el prstamo posee una Tasa menor a la Tasa de Corte, por lo que si se tiene en
cuenta como en el tem anterior hace que el TIR sea superior al TIR que se obtendra sin
tener en cuenta el prstamo solicitado.
Clculo y Anlisis del VAN

El VAN esperado es de $38.508,61. Dicho VAN es relativamente menor debido a
que se tiene que considerar la devolucin del prstamo solicitado.
El VAN esperado es de $98.445,87; el cual es mucho mayor al anterior ya que no
se debe tener en cuenta la solicitud y devolucin de un prstamo.
Si slo se tomara el TIR, la primera opcin parece ser mejor que la segunda. Si slo
se usara el VAN para analizar el Flujo de Caja se pensara que no solicitar el prstamo
sera la mejor opcin. Es por ello que es necesario emplear ambos criterios para
determinar si se solicitar el prstamo o no.
Nuestra recomendacin es solicitar el prstamo dado que implicar una menor
inversin inicial y adems analizando el flujo de caja podemos ver que si bien los
ingresos son menores, debido al pago de los intereses del prstamo, la diferencia no es
demasiado significativa.
13/11/2008
43

Versin 2.0
FECHA 13/11/2008
Anlisis de
Requerimientos
13/11/2008
44

Versin 2.0
FECHA 13/11/2008
Mdulo de Gestin de Cobranzas
13/11/2008
45

Versin 2.0
FECHA 13/11/2008
Descripcin del Mdulo

Este mdulo tiene por finalidad automatizar gran parte de la gestin de cobros que
hoy se hace en forma manual.
Actualmente la gestin de los cobros se realiza en forma manual y luego en un
Excel se vuelcan los datos finales procesados. El Excel posee una macro que genera un
archivo que luego es enviado al banco a travs de un e-mail. El banco procesa la
informacin recibida y genera una respuesta en otro archivo.
Una de las finalidades principales de este mdulo es poder automatizar el proceso
anteriormente descrito. Para ello es necesario poseer la informacin digitalizada de cada
cliente y su estado de deuda de cuotas al instituto. Para ello se deber poseer un caso
para generar dicho archivo a enviar al banco y otro caso para procesar la respuesta de
ste.
Tambin es de gran utilidad para el instituto conocer quienes son todos los clientes
que son morosos porque tienen algn tipo de deuda con el instituto, es por ello que se
cuenta con un mdulo de generacin de reporte de morosos.
Para finalizar el circuito de cobros, se necesita que se puedan generar los recibos
correspondientes por los dbitos realizados a los clientes para que sean entregados a los
mismos. Para cumplir esta funcionalidad se posee un caso de impresin de recibos.
Debemos aclarar que existe un caso especial: los clientes que no poseen cuenta
bancaria an. Para hacer frente a este tema y que se pueda digitalizar la informacin de
los cobros es que se necesita un caso de uso especial para el cobro de cuotas a dichos
clientes.
En el siguiente diagrama podremos ver cuales son los casos de uso que intervienen
en este mdulo y quienes son los actores.
13/11/2008
46

Versin 2.0
FECHA 13/11/2008
A continuacin se analizarn en detalle cada caso y se realizar la especificacin de

los mismos.
13/11/2008
47

Versin 2.0
FECHA 13/11/2008
Anlisis del CU101 Generar Listado de Dbitos

Descripcin del caso
Este caso de uso debe permitir la generacin automatizada y totalmente
informatizada del archivo que ser enviado va e-mail al banco para efectuar los cobros
de las cuotas de los clientes del instituto.
El archivo deber respetar el formato tal cual al que genera la macro del Excel
provisto por el banco, dado que para dicha entidad debe ser transparente si el archivo ha
sido generado por el Excel o a travs de la aplicacin.
Se debe efectuar primero el cobro de cuotas e intereses desde los ms antiguos a
los ms recientes y luego efectuar el cobro de las cuotas actuales. Esto posibilita que los
intereses acumulados no crezcan desmesuradamente.
Especificacin
Caso de Uso
CU101-Generar Listado de Dbitos
Breve Descripcin
Generar un listado de dbitos para enviar al banco para el cobro de

cuotas y otros cargos.
Cobrador
Actores
Precondiciones
Post condiciones
Referencias
Estar logueado al sistema

Poseer los permisos necesarios
Existencia de clientes con cuenta bancaria con deudas
Se obtiene el listado de cobros y el archivo
correspondiente.
Incluye a:
CU107-Buscar Clientes con Deudas
CU108-Generar Archivo Dbitos
Requerimientos No
Funcionales
Curso Normal
1. El Actor ingresa a la seccin de cobros y elige la opcin de generacin del listado

de cobros.
2. El Sistema muestra el formulario para la generacin del listado de dbitos.
3. El Actor completa el formulario ingresando las tres fechas de cobro.
4. El Actor presiona Generar.
5. Se ejecuta el CU107-Buscar Clientes con Deudas
6. El Sistema busca todas las deudas de los clientes hasta la primer fecha de cobro,
crea el listado y lo muestra por pantalla (Ver Anexo 1).
7. El Actor verifica la informacin y presiona Generar Archivo para el Banco para
descargar el mismo.
8. Se ejecuta el CU108-Generar Archivo Dbitos.
9. El Sistema permite descargar el archivo generado.
10. El Actor guarda el archivo para enviarlo al banco.
13/11/2008
48

Versin 2.0
FECHA 13/11/2008
Curso Alternativo
3.1. El sistema detecta que esta incompleto el formulario y le muestra un mensaje con
el campo obligatorio que falta y vuelve a 2.
4.1. El Actor presiona Limpiar y vuelve a 2.
6.1.1. El Sistema muestra un mensaje de No hay dbitos a cobrar a clientes con
cuenta bancaria en el caso de que la bsqueda no retorne ningn cliente que tenga
cuenta bancaria y posea deudas.
Interfases
Supuestos y Dependencias
Problemas / Comentarios
Las tres fechas de cobro deben ser distintas y posteriores a la fecha actual. Adems la
segunda fecha debe ser mayor a la primera y menor a la tercera; y la tercera mayor a la
primera y segunda.
Anexo 1
Prioridad
Las deudas se ordenarn cronolgicamente y tendrn prioridad las cuotas.
Intereses
Las cuotas tienen un 3% acumulativo de recargo por mes de atraso, por lo que se
calcularan con la siguiente formula:
CF = C * (1 + i) M
CF: Valor Cuota Final
C: Valor Cuota Inicial
M: Meses de atraso
i: Inters
Campos de la tabla del punto 6
Se deben mostrar el legajo del alumno, el CBU de la cuenta del mismo y el importe del
dbito a efectuar por el banco en la cuenta indicada.
13/11/2008
49

Versin 2.0
FECHA 13/11/2008
Anlisis del CU102 Procesamiento de Resultados de los

Dbitos
Descripcin del caso
Este caso de uso debe permitir poder automatizar e ingresar al sistema de cobros
del instituto los resultados generados por la entidad bancaria como respuesta al
procesamiento del archivo que se le ha enviado para el dbito de las cuentas de los
clientes con motivo del cobro de las cuotas y deudas correspondientes.
Actualmente este archivo que genera el banco con los resultados es cargado por
una macro de un Excel para mostrar la informacin. El sistema deber ser capaz de leer
dicho archivo para poder guardarlo en la base de datos del sistema y as poder ser
utilizado para otros fines, como por ejemplo la consulta de deudas que pueden realizar
los clientes desde Internet y tambin para el clculo de deudas e intereses futuros.
Especificacin
Caso de Uso
CU102- Procesamiento de Resultados de los

Dbitos
Breve Descripcin
Ingreso al sistema de la informacin recibida del banco para la

actualizacin de las cuentas de los clientes.
Actores
Cobrador
Precondiciones
Post condiciones
Referencias
Requerimientos No
Funcionales
Curso Normal

Tener el archivo con los resultados de los dbitos
Se actualiza el sistema con la informacin de los cobros
Incluye a:
CU109-Convertir Archivo De Crditos
No posee
1. El Actor ingresa a la seccin de cobros y elige la opcin de ingreso de resultado de

dbitos.
2. El Sistema muestra el formulario pidiendo el archivo que envi el banco con los
resultados de los dbitos solicitados.
3. El Actor ingresa el archivo y presiona Subir.
4. El Sistema valida y ejecuta el CU109-Convertir Archivo De Crditos.
5. El Sistema actualiza las cuentas y muestra por pantalla que la operacin se ha
realizado con xito.
13/11/2008
50

Versin 2.0
FECHA 13/11/2008
Curso Alternativo
3.1. El actor presiona Limpiar y vuelve al punto 2.

4.1. Si la validacin falla el sistema presenta un mensaje de error indicando que no es
correcto el archivo ingresado.
4.2. Contina en el punto 3.
Interfases
Anexo 1
Formato del archivo de resultado de dbitos

El archivo tiene como nombre idbla.sds.
A continuacin de describe la estructura:
Header (2 lneas)
Lnea-CaracterInicial-CaracterFinal
00-00-03 ID Establecimiento
00-04-05 Cdigo de XYZ
Body (una lnea por dbito)
Footer (1 lnea)
13/11/2008
51

Versin 2.0
FECHA 13/11/2008
Anlisis del CU103 Clientes sin Cuenta Bancaria

Descripcin del caso
Este caso de uso debe permitir registrar los cobros de cuotas de los clientes que
an no poseen una cuenta bancaria al que se le pueda debitar el dinero correspondiente.
Por ello deber existir la posibilidad de registrar el cobro de una cuota de forma
individual y manualmente a travs del sistema.
Tambin mediante este caso es posible que el cliente realice adelantos de dinero en
concepto de crdito para cancelar futuros dbitos.
Una
vez
efectuado
el
cobro
ser
necesario
imprimir
el/los
recibo/s
correspondiente/s para que el cliente tenga la constancia del pago efectuado. Para ello se
utilizar un caso de uso de impresin de recibos.
Especificacin
Caso de Uso
CU103-Clientes sin Cuenta Bancaria
Breve Descripcin
Ingreso de los pagos efectuados en forma manual al sistema de los

usuarios sin cuenta bancaria.
Cobrador
Actores
Precondiciones
Post condiciones
Referencias

Se actualiza el sistema con la informacin de los cobros
Incluye a:
CU106-Imprimir Recibo
Requerimientos No
Funcionales
Curso Normal
1. El Actor ingresa a la seccin de cobros y elige la opcin de cobro manual.

2. El Sistema muestra el formulario de bsqueda del alumno.
3. El Actor completa los datos necesarios y presiona Buscar.
4. El Sistema presenta una lista con los alumnos que cumplen con los criterios de la
bsqueda.
5. El Actor selecciona el cliente que desea realizar el pago haciendo clic en el botn
Seleccionar de la fila correspondiente al mismo.
6. El Sistema muestra las deudas del cliente y un campo para ingresar el monto a
cobrar.
7. El Actor ingresa el monto abonado por el cliente y presionar Cobrar.
8. El Sistema solicita una confirmacin de cobro por el monto indicado al cliente
seleccionado.
9. El Sistema actualiza la cuenta del cliente.
10. El Sistema ejecuta CU106-Imprimir Recibo.
11. El Sistema muestra el recibo generado para que pueda ser impreso.
13/11/2008
52

Versin 2.0
FECHA 13/11/2008
Curso Alternativo
3.1. El Actor presiona Limpiar y vuelve al punto 2.

4.1.1. Si la bsqueda trae una lista vaca porque no hay alumnos coincidentes con el
criterio de bsqueda muestra un mensaje indicando dicha situacin.
4.2.1. El Actor presiona Limpiar si desea realizar una nueva bsqueda. Vuelve al
punto 2
8.1. El Actor selecciona cancelar y vuelve al punto 7.
11.1. El Actor presiona Volver y vuelve al punto 2.
Interfase
Anexo 1

Se deben mostrar el legajo, nombre, apellido y documento del alumno. Adems se debe
mostrar una columna con un botn que permita seleccionar al alumno para efectuar el
cobro.
Se deben mostrar la fecha, una descripcin y el monto de cada deuda que posea el
alumno.
13/11/2008
53

Versin 2.0
FECHA 13/11/2008
Anlisis del CU104 Generar Reporte de Morosos

Descripcin del caso
Este caso de uso debe permitir generar un listado de los clientes que poseen
deudas con el instituto a fin de poder tomar las medidas reparadoras necesarias para que
los clientes se pongan al da con sus obligaciones.
Para la bsqueda de los clientes que poseen deudas se tendrn en cuenta los
mismos factores utilizados para generar el archivo de dbitos a enviar al banco. Por dicho
motivo se dispondr de un caso que lleve a cabo esta tarea de forma general.
Especificacin
Caso de Uso
CU104-Generar Reporte de Morosos
Breve Descripcin
Genera un listado de morosos e informacin de los mismos.
Actores
Cobrador
Precondiciones
Post condiciones
Referencias

Se obtiene el listado de morosos
Incluye a:
CU107-Buscar Clientes Con Deudas
Requerimientos No
Funcionales
Curso Normal
1. El Actor ingresa a la seccin de cobros y elige la opcin de generacin de reporte

de morosos.
2. Se ejecuta automticamente el CU107-Buscar Clientes Con Deudas.
3. El Sistema genera el listado y lo muestra por pantalla (Ver Anexo 1). Adems
tambin muestra la cantidad de morosos en forma numrica.
4. El Actor presiona Imprimir Reporte.
5. El Sistema muestra un reporte con el listado de morosos (que contiene los mismos
datos mostrados en el punto 3) para que pueda ser impreso.
Curso Alternativo
3.1. Si la bsqueda trae una lista vaca porque no hay morosos muestra el mensaje
No se ha encontrado ningn moroso.
4.1. Si no hay morosos, al querer imprimir el reporte se mostrar una advertencia con
el mensaje No hay morosos a incluir en el reporte.
Interfases
13/11/2008
54

Versin 2.0
FECHA 13/11/2008
Anexo 1

Se deben mostrar el legajo, nombre, apellido y telfono del alumno adems del monto de
la deuda que posee.
Los morosos se ordenarn de mayor a menor deuda.
13/11/2008
55

Versin 2.0
FECHA 13/11/2008
Anlisis del CU105 Impresin de Recibos

Descripcin del caso
Este caso de uso debe permitir la impresin de recibos para ser entregados a los
clientes y que dejan constancia de que han efectuado el pago de las cuotas y de las
deudas.
Para no tener que imprimir recibo por recibo y minimizar los tiempos de impresin,
se debe permitirse la impresin masiva de recibos seleccionados. Ello supondr una
ventaja en cuanto a tiempos y trabajo necesario.
Especificacin
Caso de Uso
CU105-Impresin de Recibos
Breve Descripcin
Impresin de los recibos de todos los clientes.
Actores
Cobrador
Precondiciones
Post condiciones
Referencias

Se obtienen impresos todos los recibos de los clientes
Incluye a:
Requerimientos No
Funcionales
Curso Normal
1. El Actor ingresa a la seccin de cobros y elige la opcin de impresin de recibos.

2. El Sistema automticamente muestra un listado de los recibos pendientes de ser
impresos. Tambin se muestra la cantidad total de recibos a imprimir y tambin la
cantidad contando los duplicados. (Ver Anexo 1).
3. El Actor presiona Imprimir Recibos.
4. El Sistema busca todas los pagos de los clientes para los cuales no se les ha
impreso el recibo.
5. Con el listado anterior se ejecuta por cada cliente y recibo el CU106-Imprimir
Recibo.
Curso Alternativo
2.1. Si la bsqueda trae una lista vaca porque no hay recibos se debe mostrar el
mensaje No se ha encontrado ningn recibo.
3.1. Si no hay recibos a ser impresos y se hace clic sobre Imprimir Recibos se
mostrar una advertencia con el mensaje No hay recibos pendientes de ser
impresos.
Interfases
13/11/2008
56

Versin 2.0
FECHA 13/11/2008
Anexo 1

Se deben mostrar el nmero de recibo interno del sistema, el legajo, nombre y apellido del
alumno y la fecha del recibo.
13/11/2008
57

Versin 2.0
FECHA 13/11/2008
Anlisis del CU106 Imprimir Recibo

Descripcin del caso
Este caso de uso debe permitir la impresin de un recibo individual de cobro.
Ser utilizado por otros casos de uso que necesitan imprimir masivamente los
recibos o en casos puntuales como puede ser el cobro de cuotas a clientes no
bancarizados.
Es responsable de definir los parmetros de impresin a utilizar para los recibos a
confeccionar.
Especificacin
Caso de Uso
Breve Descripcin
Actores
Imprime un recibo. Contiene la lgica de impresin

Sistema
Precondiciones
Post condiciones
Referencias
Datos del recibo

Recibo impreso
Es incluido por:
CU103-Clientes sin Cuenta Bancaria
CU105-Impresin de Recibos
Requerimientos No
Funcionales
Curso Normal
1. Se genera el recibo a imprimir a partir de un modelo predefinido.

2. Se configura la impresin con la calidad y el tamao del papel correspondiente.
3. Se permite su impresin.
Curso Alternativo
2.1. Si no se encuentra el modelo se muestra un mensaje indicando dicha situacin.

3.1. Si no se puede mostrar el recibo se muestra un mensaje indicando dicha situacin.
Interfases
13/11/2008
58

Versin 2.0
FECHA 13/11/2008
Anlisis del CU107 Buscar Clientes con Deudas

Descripcin del caso
Este caso de uso debe permitir encontrar todos los clientes que poseen deudas con
el instituto a fin de poder tomar las medidas necesarias para regularizar la situacin de
cada cliente y efectuar los clculos de cobro e intereses correspondientes.
Encapsula la lgica de bsqueda de los clientes deudores para as facilitar su
reutilizacin en otros casos de uso.
Este caso de uso ser utilizado por otros que para su ejecucin es necesario
conocer quienes son deudores, por ejemplo para la generacin de reporte de morosos.
Especificacin
Caso de Uso
CU107-Buscar Clientes con Deudas
Breve Descripcin
Busca los clientes con deuda.
Actores
Sistema
Precondiciones
Fecha mxima
Se obtiene el listado de clientes con deuda
Post condiciones
Referencias
Es incluido por:
CU104-Generar Reporte de Morosos
Requerimientos No
Funcionales
Curso Normal
1. Ejecuta la bsqueda de clientes obteniendo todos aquellos cuyo crdito es superado

por los dbitos generados antes de la fecha mxima.
Interfases
13/11/2008
59

Versin 2.0
FECHA 13/11/2008
Anlisis del CU108 Generar Archivo Dbitos

Descripcin del caso
Este caso de uso debe ser capaz de generar el archivo con los dbitos a las cuentas
de los clientes del instituto para el cobro de cuotas, deudas e intereses.
Contiene la lgica de generacin del archivo con el formato que utiliza el banco a
travs de la macro definida en la planilla de Excel que provee el banco para realizar estas
operaciones.
Para la generacin del archivo se debe respetar este formato dado que para el
banco debe ser indistinto si el archivo fue generado con la planilla Excel o con el sistema.
Especificacin
Caso de Uso
CU108-Generar Archivo Dbitos
Breve Descripcin
Generar el archivo de texto con el formato que requiere el banco
Actores
Sistema
Precondiciones
Post condiciones
Referencias
Obtener la informacin sobre los dbitos.

Archivo generado para el banco
Es incluido por:
Requerimientos No
Funcionales
Curso Normal
1. Se genera el archivo con el formato correspondiente (Ver Anexo 1).

Interfases
Anexo 1
Formato del archivo de dbito para el banco

El resultado del proceso genera un archivo de texto plano que lleva como nombre idbla.sds.
A continuacin de describe la estructura:
Header (2 lneas)
Lnea-CaracterInicial-CaracterFinal
00-00-03 ID Establecimiento
00-04-05 Cdigo de XYZ
Body (una lnea por dbito)
Footer (1 lnea)
13/11/2008
60

Versin 2.0
FECHA 13/11/2008
Anlisis del CU109 Convertir Archivo de Crditos

Descripcin del caso
Este caso de uso debe ser capaz de interpretar el archivo de resultados a las
operaciones de dbitos solicitadas.
Este archivo si bien es de texto plano, el formato es propio del banco y es
interpretado por una macro de una planilla Excel que provee el banco para poder
visualizar los resultados.
Por dicho motivo deber poder interpretar dicho formato para que la informacin de
respuesta pueda ser cargada a la base de datos del sistema de cobros del instituto.
Encapsula la lgica de interpretacin de dicho archivo.
Especificacin
Caso de Uso
CU109-Convertir Archivo De Crditos
Breve Descripcin
Actores
Convierte el archivo de crditos.

Sistema
Precondiciones
Poseer archivo con crditos
Post condiciones
Estructura de datos con la informacin del archivo
Referencias
Es incluido por:
CU102-Procesamiento de Resultados de los Dbitos
Requerimientos No
Funcionales
Curso Normal
1. Convertir el archivo a una estructura de datos manejable por nuestro sistema.

Curso Alternativo
Interfases
Supuestos y Dependencia
13/11/2008
61

Versin 2.0
FECHA 13/11/2008
Diagramas de Actividades
Generar Listado de Dbitos
act Modulo 1 Generar Listado Debitos
Solicitar Logueo
Comi enzo
Solicitar Permisos
No tiene Permisos
Mostrar Formulario para la

Generacin del Listado de
Dbitos
Cancelar la accio n de completar el

formulario
Completar Formulario
Formu lario
Incom pleto
Generar Listado de
dbitos
Cancel ar la
generacion
Buscar Clientes con

Deudas
Mostrar Listado con

las Deudas
Generar Archiv o
Dbitos
datastore
Archiv os de
Debi tos
13/11/2008
Guardar
Archiv o
Fi n
62

Versin 2.0
FECHA 13/11/2008
Diagramas de Secuencia
Generar Listado de Dbitos
sd Generar Listado de Debitos
Cobrador
PageCobros
CobrosBO
ManejoErrores
Cuent asDAO
Cuentas
Fechas()
GenerarListadoDeudas()
ValidatePermissions()
ValidatesDates()
IsInvalid()
Invalid(Cause)
BuscarClientesConDeudas()
Clientes()
Results(List<Clientes>)
results(List<Clientes>)
List()
Download()
Download()
File()
13/11/2008
63

Versin 2.0
FECHA 13/11/2008
Diagramas de Estado
Gestin de Dbitos
stm Gestin de Dbitos
Ini cio
Per odo de
Generacin de Dbitos
[Generar Dbitos]
Dbitos G enerados
[Enviar Dbitos]
Dbitos Env iados
[Recibir Resultados]
Resultado D bitos
Reci bido
[Procesar Resultados]
[Dbito No Efectuado]
[Dbito E fectuado]
Resultado Dbito?
Dbito Rechazado
Dbito Realizado
[Asentar Rechazo]
[Asentar Dbi to Efectuado]
Recha zo D bito
Asentado
Dbito Efectuado
Asentado
[Cancelar Deudas Correspondientes]
Deuda Cancelada con

Dbito
Fin al
13/11/2008
64

Versin 2.0
FECHA 13/11/2008
Mdulo de Situacin va Web
13/11/2008
65

Versin 2.0
FECHA 13/11/2008

Este mdulo tiene por finalidad proporcionarle al cliente informacin sobre el estado
de los pagos de cuotas y de los dbitos que se le han podido realizar o no.
Tambin permite proporcionarle al cliente informacin sobre las deudas y los
intereses generados por falta de pago de cuotas anteriores.
Con este mdulo el cliente podr saber y cotejar con la informacin que provea el
banco cuales fueron los dbitos que el instituto ha realizado a su cuenta para el cobro de
las cuotas y deudas correspondientes.
uc Situacin Va Web
CU201-Consul ta de
Sal do
Clie nte
CU202-Consul ta de
Deudas
include
CU203-Impre sin
Listado Deudas
Cobrador

los mismos.
13/11/2008
66

Versin 2.0
FECHA 13/11/2008
Anlisis del CU201 Consulta de saldo

Descripcin del caso
Este caso de uso debe permitir que el cliente vea las transacciones (debitoscrditos) realizadas en su cuenta.
Con esta informacin el cliente podr saber por ejemplo que da se hizo el debito de
su cuenta bancaria.
Adems este mismo caso debe permitir al personal del instituto poder buscar
clientes en base a ciertos criterios para poder consultar el estado particular de cada
cliente.
Especificacin
Caso de Uso
CU201-Consulta De Saldo
Breve Descripcin
Busca las transacciones de la cuenta del cliente
Actores
Cliente, Cobrador
Precondiciones
Post condiciones

Se obtiene el listado con las transacciones de los clientes
Referencias
Requerimientos No
Funcionales
Curso Normal
1. El Actor ingresa a la seccin de Consulta de Situacin y elige la opcin Consulta

de Saldo.
2. El Sistema determina si el usuario logueado es un cliente para mostrar su estado.
3. El Sistema muestra una grilla de transacciones y el saldo actual adems de datos
bsicos del cliente. (Ver Anexo 1)
Curso Alternativo
2.1.1. Si se determina que el usuario pertenece al instituto se habilita la bsqueda de

clientes
2.1.2. Se muestra el formulario de bsqueda por documento, legajo, apellido y nombre.
2.1.3. El Actor persiona Buscar y se completa la grilla con los clientes que cumplen el
criterio de bsqueda (Ver Anexo 2)
2.1.3.1 Si el actor presiona Limpiar vuelve al punto 2.1.2
2.1.4. El Actor presiona el botn Seleccionar de la fila correspondiente al cliente para
el cual desea ver los detalles de transacciones.
2.1.5. El sistema muestra el punto 3 del curso normal pero muestra el botn Volver
que le permite regresar al punto 2.1.4
3.1. Si el no existen movimientos se mostrar el mensaje que indique dicha situacin.
3.2. Si el cliente no posee una cuenta bancaria se le mostrar el mensaje indicando
dicha situacin. Slo podr ver la situacin luego del primer cobro manual.
13/11/2008
67

Versin 2.0
FECHA 13/11/2008
Interfases:
Anexo 1
Datos bsicos a mostrar en el punto 3

Se mostrar el nombre, apellido, banco, CBU y saldo del cliente.
Se deben mostrar la fecha, una descripcin, el monto de dbito y el monto de crdito
(completo si corresponde) para cada transaccin.
Anexo 2
Campos de la tabla del punto 2.1.3

Se deben mostrar el legajo, nombre, apellido y documento del cliente. Adems se debe
mostrar una columna con un botn que permita seleccionar el cliente para ver los detalles
de las transacciones.
13/11/2008
68

Versin 2.0
FECHA 13/11/2008
Anlisis del CU202 Consulta de Deudas

Descripcin del caso
Este caso de uso debe permitir al cliente, en caso de tener deudas, visualizar en
forma detallada el estado de su situacin respecto al cobro de cuotas por parte del
instituto.
Se deben mostrar las deudas con sus respectivos intereses y el total de las mismas.
Adems este mismo caso debe permitir al personal del instituto poder buscar
clientes en base a ciertos criterios para poder consultar el estado de deudas particular de
cada cliente.
Especificacin
Caso de Uso
CU202-Consulta de Deudas
Breve Descripcin
Muestra al cliente las cuotas que debe (y otras deudas) y los

intereses correspondiente.
Actores
Cliente, Cobrador
Precondiciones

Post condiciones
Referencias
Incluye a:
CU203-Impresin de Listado Deudas
Requerimientos No
Funcionales
Curso Normal
1. El Actor ingresa a la seccin de Consulta de Situacin y elige la opcin de

Consulta de Deudas.
2. El Sistema determina si el usuario logueado es un cliente para mostrar su estado.
3. El Sistema muestra una grilla con los detalles de las deudas que tiene y de los
intereses generados por el paso del tiempo. (Ver Anexo 1).
4. El Actor puede imprimir la grilla generada, haciendo clic en el botn Imprimir
Reporte y el sistema ejecuta el CU203-Impresin de Listado Deudas.
13/11/2008
69

Versin 2.0
FECHA 13/11/2008
Curso Alternativo
2.1.1. Si se determina que el usuario pertenece al instituto se habilita la bsqueda de

clientes.
2.1.2. Se muestra el formulario de bsqueda por documento, legajo, apellido y nombre.
2.1.3. El Actor persiona Buscar y se completa la grilla con los clientes que cumplen el
criterio de bsqueda (Ver Anexo 2)
2.1.3.1 Si el actor presiona Limpiar vuelve al punto 2.1.2
2.1.4. El Actor presiona el botn Seleccionar de la fila correspondiente al cliente para
el cual desea ver los detalles de deudas.
2.1.5. El sistema muestra el punto 3 del curso normal pero muestra el botn Volver
que le permite regresar al punto 2.1.4
3.1 Si el usuario no tiene deudas se mostrar el mensaje No se han encontrado
deudas.
Interfases
Anexo 1
Datos bsicos a mostrar en el punto 3

Se mostrar el nombre y apellido del cliente.
Se deben mostrar la fecha, una descripcin, el monto de la deuda.
Anexo 2

Se deben mostrar el legajo, nombre, apellido y documento del cliente. Adems se debe
mostrar una columna con un botn que permita seleccionar el cliente para ver los detalles
de las transacciones.
13/11/2008
70

Versin 2.0
FECHA 13/11/2008
Anlisis del CU203 Impresin Listado Deudas

Descripcin del caso
Este caso de uso debe permitir la impresin de los detalles de las deudas que posee
un cliente (si as es) con la informacin que visualiza por pantalla.
Para facilitar el guardado y tambin la impresin respetando los formatos, se
deber generar un archivo PDF que contenga el listado a imprimir. Este archivo, si el
usuario del sistema posee el plugin de Adobe para su browser podr ser visualizado,
guardado e impreso desde la misma pgina o si no lo posee deber bajarlo para poder
visualizarlo en otra aplicacin y luego imprimirlo.
Especificacin
Caso de Uso
CU203-Impresin Listado Deudas
Breve Descripcin
Imprime el detalle de las deudas que posee un cliente.
Actores
Sistema
Precondiciones
Un cliente usuario debe estar logueado al sistema

El cliente debe poseer deudas
Post condiciones
Referencias
Es incluido por:
CU202-Consulta de Deudas
Requerimientos No
Funcionales
Curso Normal
1. El sistema recibe el cliente para el cual se debe generar el reporte de deudas.

2. El sistema busca las deudas del cliente.
3. El sistema enva al generador de reportes en PDF la informacin obtenida en el
punto anterior.
4. El sistema muestra el reporte para permitir que el cliente lo imprima o lo guarde.
Curso Alternativo
4.1 Seleccionando Guardar el sistema guarda el archivo PDF generado.

Interfases
13/11/2008
71

Versin 2.0
FECHA 13/11/2008
Consulta de deudas
act Modulo 2 Consultas de Deudas
No esta logueado
Solicitar Logueo
Comi enzo
Solicitar Permisos
No tiene permisos
Obtener Usuario
Es cliente?
Buscar Cliente
No
Si
Seleccionar Cliente
Obtener Duedas
Imprimir grilla con las

deudas
Fi n
13/11/2008
72

Versin 2.0
FECHA 13/11/2008
Mdulo de Inscripcin
13/11/2008
73

Versin 2.0
FECHA 13/11/2008

Este mdulo tiene por finalidad la administracin de las preinscripciones, tanto para
el alta de las mismas con todos sus datos requeridos como para aprobar o rechazar una
solicitud. Adems este mdulo permite consultar el estado de la preinscripcin cargada
en el sistema por parte del cliente o si el usuario es un empleado del instituto se le
permite consultar por cualquier preinscripcin.
Los datos necesarios para realizar una preinscripcin actualmente estn contenidos
en un formulario con una gran cantidad de datos que se deben completar. Dicho
formulario es definido por la Direccin General de Cultura y Educacin de la Provincia de
Buenos Aires.
La administracin de las preinscripciones recibidas hasta la fecha de tope informada
oportunamente, permitir tener la informacin de la solicitud para que pueda ser
analizada y aceptada o en su defecto rechazada.
uc Inscripcin
CU301 -Alta de
Preinsc ripcin
Clie nte
CU303-Consul ta de
Esta do de
Preinsc ripcin
Direc tiv o
CU302-Administrador
de Preinscripcin

los mismos.
13/11/2008
74

Versin 2.0
FECHA 13/11/2008
Anlisis del CU301 Alta de Preinscripcin

Descripcin del caso
Este caso de uso debe permitir el alta de preinscripciones de nuevos alumnos que
quieran ingresar al instituto.
Permitir a los padres efectuar, desde cualquier computadora conectada a Internet,
en el perodo correspondiente, la preinscripcin de sus hijos al instituto sin necesidad de
tener que hacer largas colas que son cotidianas en las pocas de preinscripciones para el
siguiente ciclo lectivo.
De esta forma, luego de finalizado el perodo de preinscripcin definido, el padre
podr consultar cual fue el resultado de la misma tambin va Internet.
El padre deber concurrir al establecimiento del instituto solo luego de que fue
aprobado su pedido.
Especificacin
Caso de Uso
CU301-Alta de Preinscripcin
Breve Descripcin
Permite realizar la preinscripcin de alumnos (tanto nuevos como de

los que ya pertenecen al instituto) para el prximo ciclo lectivo.
Actores
Padres o tutores del Alumno, Directivo
Precondiciones
El Mdulo debe estar habilitado
Post condiciones
La informacin de preinscripcin es guardada y queda a la

espera de ser aprobada con el administrador.
Referencias
Requerimientos No
Funcionales
Curso Normal
1. El Actor ingresa a la seccin de preinscripcin y elige la opcin de Alta de

preinscripciones.
2. El Sistema determina si el usuario logueado es un cliente.
3. El Sistema muestra el formulario pidiendo los datos necesarios para el proceso.
4. El Actor ingresa los datos solicitados (Ver Anexo 1) y presiona Guardar.
5. El Sistema valida y procesa los datos ingresados.
6. El Sistema graba los datos.
7. El Sistema muestra por pantalla que la operacin se ha realizado con xito.
8. El Sistema genera un reporte, para ser impreso, con la constancia de
preinscripcin la cual contiene un nmero nico para futuras consultas.
13/11/2008
75

Versin 2.0
FECHA 13/11/2008
Curso Alternativo
3.1. Si el usuario logueado es un cliente y ya posee una solicitud de preinscripcin en

curso se le mostrar un mensaje que indicar dicha situacin y se lo invitar a
consultar el estado desde el CU303-Consulta de estado de preinscripcin.
Adems no se le mostrar el formulario de alta de preinscripciones.
3.2. Si el usuario logueado es del personal del instituto se le permitir ingresar ms de
una preinscripcin.
4.1. El Actor presiona Limpiar para borrar los datos ingresados y poder comenzar otra
vez.
5.1. Si alguno de los datos no es vlido, el sistema regresa al punto 2 y muestra un
mensaje indicando cual es el dato incorrecto.
6.1. Si el usuario logueado es del personal del instituto el sistema automticamente
crear un usuario para que sea entregado al cliente futuras consultas e interaccin
con el instituto.
7.1. Si el usuario logueado es del personal del instituto se mostrar adems un
mensaje con el usuario y contrasea generado en el punto 6.1.
Interfases:
Supuestos y Dependencias:
Problemas / Comentarios:
Anexo 1
Datos a solicitar para preinscribir a un alumno:
13/11/2008
76

Versin 2.0
13/11/2008
FECHA 13/11/2008
77

Versin 2.0
FECHA 13/11/2008
Anlisis del CU302 Administrar preinscripciones

Descripcin del caso
Este caso de uso debe permitir administrar las preinscripciones recibidas en el
perodo definido para aceptar preinscripciones para el siguiente ciclo lectivo.
El directivo deber poder visualizar la informacin ingresada por los padres para as
poder evaluar la situacin y aceptar o rechazar la misma.
Luego de especificar una resolucin, los padres que han solicitado podrn conocer
el resultado de la misma y en caso de ser aceptada debern concurrir al establecimiento
para finalizar el proceso de inscripcin.
Especificacin
Caso de Uso
CU302-Administrar Preinscripciones
Breve Descripcin
Administrar las preinscripciones ingresadas por el mdulo de alta de

preinscripciones, para aceptar o rechazar las mismas.
Actores
Directivo
Precondiciones

Post condiciones
Las preinscripciones recibidas han sido procesadas y

guardado un resultado para cada una de las mismas.
Referencias
Requerimientos No
Funcionales
Curso Normal
1. El Actor ingresa a la seccin de preinscripcin y elige la opcin de administracin

de preinscripcin.
2. El Sistema muestra los distintos criterios de bsqueda para analizar las
preinscripciones (segn Modalidad, Ao, Turno y da la opcin de ver los ya
procesados o los que estn pendientes).
3. El Sistema muestra un apartado con estadsticas de preinscripciones. (Ver Anexo
1).
4. El Actor ingresa los criterios de bsqueda que desee y presiona Buscar.
5. El Sistema muestra los criterios especificados y las preinscripciones que cumplen
con los mismos (Ver Anexo 2).
6. El Actor elige una divisin o rechazar en su defecto y selecciona las
preinscripciones de los alumnos que formarn parte de la asignacin y presiona
Asignar Divisin para realizar una asignacin de varias preinscripciones a la vez.
7. El Sistema coloca los alumnos en los cursos indicados y muestra un mensaje de
asignacin correcta.
8. El Actor presiona el botn Volver y regresa al punto 2 donde podr asignar otros
cursos a las preinscripciones restantes.
13/11/2008
78

Versin 2.0
FECHA 13/11/2008
Curso Alternativo
5.1. El Actor presiona Volver y regresa al punto 2.

6.1.1. El Actor selecciona individualmente una preinscripcin.
6.1.2. El Actor hace clic sobre la celda que dice Haga clic, o que posee la divisin si
ya se le haba asignado una, de la fila correspondiente a la preinscripcin a
administrar.
6.1.3. El Sistema muestra una lista con las posibilidades de asignacin.
6.1.4. El Actor selecciona la opcin de asignacin deseada y presiona en el tilde verde
para aceptar o en la cruz roja para cancelar.
6.2.1. El Actor presiona el botn Ver para examinar los datos de la preinscripcin (los
mismos que han sido ingresados en el alta).
6.2.2. Luego de visualizar los datos el actor presiona Volver para regresar al punto 5.
Interfases:
Anexo 1
Estadsticas de Preinscripciones
Para mostrar las estadsticas de preinscripciones se utilizar un rbol donde cada tem
consolidar la cantidad de preinscripciones Aceptadas, Rechazadas y No Procesadas,
indicadas con color verde, rojo y azul respectivamente, por cada Modalidad, Turno, Ao y
Curso. Esto permitir visualizar tanto la informacin a nivel global como en forma
detallada.
Anexo 2

Se deben mostrar el nombre, apellido, divisin (esta columna deber ser editable para que
al hacer clic se pueda cambiar la misma). Adems se debe mostrar una columna con un
botn que permita seleccionar la preinscripcin para ver los detalles de la misma.
13/11/2008
79

Versin 2.0
FECHA 13/11/2008
Anlisis del CU303 Consulta de Estado de Preinscripcin

Descripcin del caso
Este caso de uso debe permitir consultar el estado de las preinscripciones.
Para tal motivo se presentan 2 posibilidades: que el usuario que ha ingresado al
sistema sea un cliente, por lo cual se le mostrar directamente el estado correspondiente
a su preinscripcin; o que el usuario sea del instituto por lo cual podr consultar por
distintas preinscripciones.
Especificacin
Caso de Uso
CU303-Consulta de Estado de Preinscripcin
Breve Descripcin
Consultar el estado de una preinscripcin dada de alta en el

sistema.
Actores
Padres o tutores del Alumno, Directivo
Precondiciones
Post condiciones
Referencias

Existencia de preinscripciones
El estado de la preinscripcin ha sido informado.
Requerimientos No
Funcionales
Curso Normal
1. El Actor ingresa a la seccin de preinscripcin y elige la opcin de consulta de

preinscripcin.
2. El Sistema determina si el usuario logueado es un cliente.
3. El Sistema muestra automticamente el estado de la preinscripcin para el cliente.
Curso Alternativo
2.1.1. El Sistema determina que el usuario es de un empleado del instituto.

2.1.2. El Sistema muestra un formulario para especificar criterios de bsqueda.
2.1.3. El Actor completa el/los campo/s solicitado/s y presiona Consultar.
2.1.3.1. Si no existe una preinscripcin que coincida con el criterio indicado se
informar de dicha situacin.
2.1.4. El Sistema muestra el estado de la preinscripcin indicada.
2.1.5. El Actor presiona Limpiar y vuelve al punto 2.1.2
3.1. Si el usuario no tiene una preinscripcin cargada se informar dicha situacin.
Interfases:
13/11/2008
80

Versin 2.0
FECHA 13/11/2008
Administrar Preinscripciones
act Administracin Preinscripcion
Solicitar Logueo
No esta l ogueado
Comi enzo
Solicitar permisos
No tiene permisos
Cambiar de criterio
Consultar
Preinscriptos
Terminar Consulta
Cambiar de curso
Asignar alumnos a
curso o rechazar
Termina r carga
datastore
Archiv o de Cursos
Guardar datos de
cursos
Fi n
13/11/2008
81

Versin 2.0
FECHA 13/11/2008
Alta de Preinscripciones
act Alta de Preinscripcin
Solicitar Logueo
No tiene permi sos
Comi enzo
Solicitar permisos
No esta logueado
Ingresar a
Preincripcin
Cancelar
preinsc ripcin
Ingresa r Datos
Tiene errores
Cancelar
preinscripcin
datastore
Archiv o Datos
Preinscr ipciones
13/11/2008
Guardar datos
Fi n
82

Versin 2.0
FECHA 13/11/2008
Diagramas de Secuencia
Alta de Preinscripcin
sd Alta de Preinscripcin
Usuario
Page Data
Preinscri pci onBO
ManejoErrores
Prei nscri pcionDAO
Preinsc ri pcion
IngresarDatos()
AltaPreinscripcion(Datos)
ValidateData(Datos) :
bool ean
IsInvali d()
Invali d(Cause)
SavePreinscripcion(Prei nscri pcion)
SavePreinscripcion()
[Results]()
[OK or
NOK]()
13/11/2008
83

Versin 2.0
FECHA 13/11/2008
Diagramas de Estado
Inscripcin
stm Inscripcin
Ini cio
Preinscripcin
Habil itada
[Nueva Prei nscripcin]
Preinscripcin
Reci bida
Preinscripcin
Recha zada
[Rechazar Pre inscripcin]
Resultado?
[Aceptar Pre inscripcin]
Preinscripcin
Aceptada
[Otorgar vacante temporalmente]
Espe rando
Confir macin
Vacante Otorgada
[Recibir Co nfirmacin]
[Rechazar Co nfirmacin]
Resu ltado
Confirmacin?
Insc ripc in
Finalizada OK
Vacante Rechazada
por Cliente
Vacante Liberada
Fin al
13/11/2008
84

Versin 2.0
FECHA 13/11/2008
Mdulo de Administracin de Datos
13/11/2008
85

Versin 2.0
FECHA 13/11/2008

Este mdulo tiene por finalidad la administracin de los datos manejados por la
aplicacin y que pueden ser modificados, por ejemplo los datos de los alumnos.
uc Administracin de Datos
CU401-Modificac in de
Datos de Alumnos
Empl eado
CU402 -Baj a de
Alumnos

los mismos.
13/11/2008
86

Versin 2.0
FECHA 13/11/2008
Anlisis del CU401 Modificacin de Datos de Alumnos

Descripcin del caso
Este caso de uso debe permitir la modificacin de los datos de los alumnos del
instituto.
Se usar principalmente para actualizar datos de los alumnos, como por ejemplo
domicilio, nmero de telfono y otros.
En cuanto a que datos se podrn modificar, deber poder modificarse todos los
datos asociados al alumno y solo podr ser realizado por el perfil de ms alto rango dado
que posee informacin sensible y se debe tener especial cuidado.
Especificacin
Caso de Uso
CU401 Modificacin de Datos de Alumnos
Breve Descripcin
Modificacin de los datos de los alumnos del instituto.

Empleado
Actores
Precondiciones
Post condiciones

Se modificaron los datos de un alumno que ya exista.
Referencias
Requerimientos No
Funcionales
Curso Normal
1. El Actor ingresa a la seccin Administracin de alumnos y elige la opcin de

modificacin.
2. El Sistema muestra el formulario para ingresar los criterios de bsqueda de
alumnos.
3. El Actor completa el formulario con los criterios deseados y presiona Buscar.
4. El Sistema muestra, adems de los criterios de bsqueda indicados, una grilla con
los datos de los alumnos que cumplen el criterio seleccionado y que son alumnos
del instituto (Ver Anexo 1).
5. El Actor presiona sobre el botn Modificar de la fila correspondiente al alumno a
modificar.
6. El Sistema muestra un formulario con los datos del alumno (Ver Anexo 2).
7. El Actor modifica los datos deseados y presiona Modificar.
8. El Sistema valida los datos ingresados sean correctos.
9. El Sistema guarda las modificaciones realizadas y vuelve al punto 4.
13/11/2008
87

Versin 2.0
FECHA 13/11/2008
Curso Alternativo
3.1.1. El Actor presiona Buscar sin completar ningn criterio.

3.1.2. El Sistema informa que debe completar al menos un criterio de bsqueda.
4.1. Si no hay alumnos que coincidan con el criterio indicado se informa dicha
situacin con un mensaje.
7.1. El Actor presiona Volver y regresa al punto 4 sin modificar los datos del alumno.
8.1. Si los datos ingresados no son vlidos se le informar con diversos mensajes de
la ubicacin de los mismos y cul es el error.
Interfases:
Anexo 1

mostrar una columna con un botn que permita seleccionar al alumno para modificar los
datos del mismo.
Anexo 2
Formulario de modificacin de datos

El formulario de modificacin de datos debe incluir adems de los datos del alumno,
padre, madre y responsable/tutor, los datos de la cuenta bancaria y los datos del curso
actual del alumno.
13/11/2008
88

Versin 2.0
FECHA 13/11/2008
Anlisis del CU402 Baja de Alumnos

Descripcin del caso
Este caso de uso debe permitir la baja de alumnos del instituto.
Se usar principalmente para dar de baja a los alumnos que han dejado de formar
parte de la institucin por cualquier motivo.
Permitir que se puedan ver los datos del alumno antes de su baja y adems se
tendr la posibilidad de dar de baja a varios alumnos a la vez.
Esta operacin solo podr ser realizada por el perfil de ms alto rango dado que
posee informacin sensible y se debe tener especial cuidado.
Especificacin
Caso de Uso
CU402 Baja de Alumnos
Breve Descripcin
Baja de los alumnos que ha dejado de formar parte del instituto.

Empleado
Actores
Precondiciones
Post condiciones

Se dio de baja a uno o varios alumnos del instituto.
Referencias
Requerimientos No
Funcionales
Curso Normal
1. El Actor ingresa a la seccin Administracin de alumnos y elige la opcin de baja de

alumnos.
2. El Sistema muestra el formulario para ingresar los criterios de bsqueda de
alumnos.
3. El Actor completa el formulario con los criterios deseados y presiona Buscar.
4. El Sistema muestra, adems de los criterios de bsqueda indicados, una grilla con
los datos de los alumnos que cumplen el criterio seleccionado y que son alumnos
del instituto (Ver Anexo 1).
5. El Actor presiona sobre el botn Eliminar de la fila correspondiente al alumno a dar
de baja.
6. El Sistema solicita una confirmacin de la accin requerida.
7. El Actor acepta la confirmacin.
8. El Sistema procesa el pedido de baja y guarda los cambios.
9. El Sistema vuelve al punto 4.
13/11/2008
89

Versin 2.0
FECHA 13/11/2008
Curso Alternativo
3.1.1. El Actor presiona Buscar sin completar ningn criterio.

3.1.2. El Sistema informa que debe completar al menos un criterio de bsqueda.
4.1. Si no hay alumnos que coincidan con el criterio indicado se informa dicha
situacin con un mensaje.
5.2.1. El Actor selecciona varias filas de la grilla y presiona Eliminar alumnos
seleccionados para dar de baja varios alumnos a la vez.
5.2.2. El Sistema solicita una confirmacin sobre la baja de los alumnos
seleccionados.
5.2.3. El Actor acepta la confirmacin de baja masiva.
5.2.3.1. El Actor rechaza la confirmacin y vuelve al punto 5.2.1
5.2.4. El Sistema procesa y da de baja a los alumnos.
5.2.5. El Sistema informa con un mensaje que la operacin se ha completado y vuelve
al punto 4.
5.3.1. El Actor presiona el botn Ver de la fila correspondiente al alumno que se
desea ver los datos del mismo.
5.3.2. El Sistema muestra un formulario no editable con los datos del alumno.
5.3.3. El Actor presiona Volver y regresa al punto 4.
Interfases:
Anexo 1

mostrar una columna con un botn que permita ver los detalles de los datos del alumno y
otra columna con otro botn para poder dar de baja al alumno correspondiente a la fila
indicada.
Anexo 2
Formulario de modificacin de datos

El formulario de modificacin de datos debe incluir adems de los datos del alumno,
padre, madre y responsable/tutor, los datos de la cuenta bancaria y los datos del curso
actual del alumno.
13/11/2008
90

Versin 2.0
FECHA 13/11/2008
Diagramas de Actividad
Administracin de Alumnos
act Modulo 4 Administracin de Alumnos
Solicitar Logueo
No esta logueado
Comi enzo
Solicitar Permisos
No tiene permisos
Mostrar opciones de
modificacin o baj a
Mostrar buscador de
Alumnos
Cancelar Mo dificacin
No se encon tr Alumno
Modificar datos o
Eliminar Alumno
Modifi cacin
Tiene errores
Confirmar
Modificacin
Elim inar
Cancelar
Confirmar Baj a
Alumno
Cancelar
datastore
Datos Alumnos
Guarda Datos
Fi n
13/11/2008
91

Versin 2.0
FECHA 13/11/2008
Mdulo de Administracin de
Seguridad
13/11/2008
92

Versin 2.0
FECHA 13/11/2008

Este mdulo tiene por finalidad la administracin de la seguridad del sistema.
A travs de los casos de uso de este mdulo se podrn crear usuarios y perfiles,
asignar perfiles y permisos. As mismo se podrn modificar los datos de los usuarios,
perfiles y permisos ya creados.
uc Administracin de Seguridad
CU501- Administracin
de Permisos
de Perfiles
Administrador del
Sistema
de Usuarios

los mismos.
13/11/2008
93

Versin 2.0
FECHA 13/11/2008
Anlisis del CU501 Administracin de Permisos

Descripcin del caso
Este caso de uso debe permitir el alta y la modificacin de los permisos que el
sistema posee.
Se usar principalmente para actualizar datos de los permisos, por ejemplo entre
ellos los ttulos de las entradas de men y la descripcin de los mismos para facilitar su
comprensin.
Se deber poder buscar por distintos criterios para que luego sean modificados.
Especificacin
Caso de Uso
CU501 Administracin Permisos
Breve Descripcin
Modificacin de los permisos del sistema.

Administrador del Sistema
Actores
Precondiciones
Post condiciones

Se modificaron los datos de los permisos del sistema.
Referencias
Requerimientos No
Funcionales
Curso Normal
1. El Actor ingresa a la seccin Administracin de Seguridad y elige la opcin de

Permisos.
2. El Sistema muestra el formulario para ingresar los datos del permiso a dar de alta
(Identificador del permiso usado internamente por el sistema, el titulo a mostrar en
el men y un detalle del mismo).
3. El Actor ingresa todos los campos solicitados y hace clic en Guardar.
4. El Sistema procesa y guarda los datos del permiso.
5. El Sistema muestra un mensaje indicando el xito de la operacin
13/11/2008
94

Versin 2.0
FECHA 13/11/2008
Curso Alternativo
3.1.1. El Actor presiona Buscar permisos para modificar.

3.1.2. El Sistema presenta los campos correspondientes a los criterios de bsqueda
de permisos.
3.1.3. El Actor ingresa los criterios por los cuales desea buscar.
3.1.4. El Actor presiona Buscar
3.1.5. El Sistema presenta una grilla con los permisos que corresponden al criterio
especificado (Ver Anexo 1).
3.1.6. El Actor selecciona un permiso haciendo clic en el icono correspondiente a la
fila del permiso a modificar.
3.1.7. El Sistema presenta un formulario con los datos del permiso y permite la
modificacin de todos los campos excepto del identificador del permiso.
3.1.8. El Actor realiza los cambios, presiona Guardar para hacer efectivos los
mismos y volver al punto 3.1.5
3.1.8.1. El Actor presiona Volver para regresar al punto 3.1.5 sin guardar cambios.
5.1. El Sistema indica que ya existe un permiso con el mismo identificador y vuelve al
punto 2 pero con los datos ingresados por el actor.
Interfases:
Anexo 1

Se deben mostrar el identificador del permiso dentro del sistema, el titulo que aparece en
el men y la descripcin del permiso. Adems se debe mostrar una columna con un icono
que permita seleccionar el permiso para que sea modificado.
13/11/2008
95

Versin 2.0
FECHA 13/11/2008
Anlisis del CU502 Administracin de Perfiles

Descripcin del caso
Este caso de uso debe permitir el alta y la modificacin de los perfiles que el
sistema posee.
Se usar principalmente para actualizar datos de los perfiles, por ejemplo su detalle
o los permisos asociados al perfil y para agregar nuevos perfiles al sistema.
Especificacin
Caso de Uso
CU502 Administracin Perfiles
Breve Descripcin
Modificacin de los perfiles del sistema.

Actores
Precondiciones
Post condiciones

Se modificaron los datos de los perfiles del sistema.
Referencias
Requerimientos No
Funcionales
Curso Normal

Perfiles.
2. El Sistema muestra el formulario para ingresar los datos del perfil a dar de alta
(Detalle del perfil y lista de permisos existentes).
3. El Actor ingresa todos los campos solicitados.
4. El Actor selecciona de la grilla los permisos que desea asociar al perfil para
permitir su acceso.
5. El Actor hace clic en Guardar.
6. El Sistema procesa y guarda los datos del perfil.
7. El Sistema muestra un mensaje indicando el xito de la operacin.
13/11/2008
96

Versin 2.0
FECHA 13/11/2008
Curso Alternativo
3.1.1. El Actor presiona Buscar perfiles para modificar.

de perfiles.
3.1.5. El Sistema presenta una grilla con los perfiles que corresponden al criterio
3.1.6. El Actor selecciona un perfil haciendo clic en el icono correspondiente a la fila
del perfil a modificar.
3.1.7. El Sistema presenta un formulario con los datos del perfil y permite la
modificacin de todos los campos.
Interfases:
Anexo 1

Se deben mostrar el detalle del perfil y una columna con un icono que permita seleccionar
el perfil para que sea modificado.
13/11/2008
97

Versin 2.0
FECHA 13/11/2008
Anlisis del CU503 Administracin de Usuarios

Descripcin del caso
Este caso de uso debe permitir el alta y la modificacin de los usuarios que el
sistema posee.
Se usar principalmente para actualizar datos de los usuarios, por ejemplo su
nombre, apellido, contrasea y el perfil actual asociado al usuario. Adems permitir
agregar nuevos usuarios al sistema.
Especificacin
Caso de Uso
CU503 Administracin Usuarios
Breve Descripcin
Modificacin de los usuarios del sistema.

Actores
Precondiciones
Post condiciones

Se modificaron los datos de los usuarios del sistema.
Referencias
Requerimientos No
Funcionales
Curso Normal

Usuarios.
2. El Sistema muestra el formulario para ingresar los datos del usuario a dar de alta
(nombre, apellido, usuario, contrasea, si es externo o interno al instituto y lista de
perfiles existentes).
3. El Actor ingresa todos los campos solicitados.
4. El Actor selecciona de la grilla el perfil que desea asociar al usuario para permitir
su acceso.
5. El Actor hace clic en Guardar.
6. El Sistema valida los datos ingresados.
7. El Sistema procesa y guarda los datos del usuario.
8. El Sistema muestra un mensaje indicando el xito de la operacin.
13/11/2008
98

Versin 2.0
FECHA 13/11/2008
Curso Alternativo
3.1.1. El Actor presiona Buscar usuarios para modificar.

de usuarios.
3.1.5. El Sistema presenta una grilla con los usuarios que corresponden al criterio
3.1.6. El Actor selecciona un usuario haciendo clic en el icono correspondiente a la fila
del usuario a modificar.
3.1.7. El Sistema presenta un formulario con los datos del usuario y permite la
modificacin de todos los campos excepto la del nombre de usuario.
Interfases:
Anexo 1

Se deben mostrar el nombre, apellido, usuario y adems una columna con un icono que
permita seleccionar al usuario para que sea modificado.
13/11/2008
99

Versin 2.0
FECHA 13/11/2008
Anexos del Anlisis

Diagramas de Secuencia de Logueo al Sistema
sd Logueo
Cliente
Login
SecurityManager
Persona
Login()
ValidateUser()
CheckPermission()
Permissions()
ValidatePermi ssions()
OK or NOK () :Cuase
13/11/2008
100

Versin 2.0
FECHA 13/11/2008
Diseo
13/11/2008
101

Versin 2.0
FECHA 13/11/2008
Diseo del Sistema
13/11/2008
102

Versin 2.0
FECHA 13/11/2008
Diagrama de Dominio
Cliente
En este paquete se encuentra toda la informacin relativa a un cliente que
representa bsicamente en esta organizacin a un alumno.
class Cliente
enumeration
Prov inc iaEnum
enumeration
TipoDocumentoEnum
enum
BUENOS _AIRES
CAPIT AL_FEDERAL
CATAMARCA
CHA CO
CHUBUT
CORDOBA
CORRI ENTES
ENTRE _RIOS
FORMOSA
JUJUY
LA_PAMPA
LA_RIOJA
MENDOZA
MISI ONES
NEUQ UEN
RIO_NEGRO
SALTA
SAN_ JUAN
SAN_ LUIS
SANTA_CRUZ
SANT A_FE
SANTIAGO_DEL_ESTERO
TIERRA_DEL_FUEGO
TUCUMAN
enum
DNI
CI
LE
LC
-provi ncia
-tipo
IBABusinessObject
IBABusi nessObject
Docum ento
Domic ilio
-
-sexo
enum
MASCULINO
FEMENINO
IBABusi nessObject
IBABusinessObject
Telefono
Pers ona
IBABusi nessObject
Cue nta
-
enumeratio...
SexoEnum
- emiti doPor: Stri ng

calle: String
- numero: Long
codi goPosta l: String
- pai s: String
departamento: Stri ng
- ti po: TipoDocumentoEnum
localidad : String
manzana: String
-documento
numero: String
pi so: Stri ng
provinci a: P rovinci aEnum -domicil io
torre: Stri ng
-persona
CBUBl oqueDos: Long

CBUBl oqueUno: Long
nombreBanc o: String
persona: Persona
rechazosDebito: L ist<RechazoDebi to>
recibos: L ist<Reci bo>
sal do: double
transacciones: List<Transacci on>
apell ido: String

documento: Documento
domi ci lio: Domi ci lio
-persona
fechaNacimi ento: Cal endar
lugarNacimie nto: Stri ng
nacional ida d: Stri ng
nombre: String
sexo: SexoEnum
telefonos: List<Telefono>
vive: bool ean
enumerati on
TipoResponsableEnum
enum
PADRE
MADRE
TUTOR
-cuenta
-tipo
Responsab leAlumno
Clie nte
-
descripci o n: String
numero: String
persona: Persona
cantHerman os: Long

cantHermanosEstab l ecimiento: Long
cuenta: Cuenta
curso: Curso
fechaBaj a: Calendar
responsables: Set< ResponsableAl umno>
ti eneHermanos: boolean
usuario: Usuario
completo: bo olean = false

gradoInstruccion: int
nivel Instrucci on: NivelEnum
profesi on : Stri ng
tipo: TipoResponsabl eEnum
-ni velInstruccion
-curso
enumerati on
Niv elEnum
IBABusi nessObject
Cur so
-
-divi si on
-turno
enumerati o...
TurnoEnum
enum
MANIANA
TARDE
13/11/2008
enum
NING UNO
PRIM ARIO
SECUNDARIO
TERCI ARIO
UNIVERS ITARIO
ani o: Long
divi si on: Divisi onEnum
modali dad: M odalidadEnum
turno: TurnoEnum
enumerati o...
Div isi onEnum
enum
A
B
C
R
-modal idad
enumeration
Modalid adEnum
enum
COMARTEYDISEO
ECONYG ESTION
103

Versin 2.0
FECHA 13/11/2008
Cuenta
Aqu se rene la estructura de la cuneta de un cliente. Por un lado tenemos las
transacciones y por otro los debitos rebotados. Tambin se almacenan los recibos
impresos.
class Cuenta
IBABusinessObject
IBABusinessObject
RechazoDebito
DescripcionTransaccion
cuenta: Cuenta
fecha: Calendar
monto: Double
referencia : String
IBABusinessObject
Transa ccion
#descripcionTransaccion
descripcio n: Stri ng
#
#
#
#
#
#
#
-cuenta
IBABusinessObject
consolidaciones: L ist<Consolidacion>
cubierta: boolean
cuenta: Cuenta
descripcionTransaccion: DescripcionTransaccion
fecha: Cal endar
monto: Double
montoRestan te: Doubl e
#cuenta
Cue nta
-
CBUBloqueDos: Long
CBUBloqueUno: Long
nombreBanco: String
persona: Persona
rechazosDebi to: L ist<RechazoDebito>
recibos: L ist<Reci bo>
saldo: double
transacci ones: List<Transaccion>
IBABusinessObject
Credito
Debito
Consolidacion
-credito
-
-cuenta
-debito
credito: Credito
debito: Debito
monto: Double
-credito
-debito
-cuenta
-persona
IBABusinessObject
IBABusi nessObject
Pers ona
-
Rec ibo
apel lido: Stri ng

domicilio: Domicilio
fechaNacimi ento: Calendar
l ugarNacimie nto: Stri ng
nacionalida d: String
nom bre: String
sexo: SexoEnum
telefonos: List<Tel efono>
vive: boolean
al umno: Cliente
credito: Credito
cuenta: Cuenta
debito: Debito
fecha: Calendar
fechaImpresi on: Calendar
items: List <ItemRecibo>
Cuo ta
-
anio: Integer
interes: Double
mes: Integer
-recibo
IBABusinessObject
ItemRecibo
-alumno
-
Clie nte
-
cantHerman os: Long

cantHermanosEstab lecimiento: Long
cuenta: Cuenta
curso: Curso
estado: E stadoEnum
fechaBaja: Calendar
responsables: Set<ResponsableAlumno>
tieneHermanos: boolean
usuari o: Usuario
13/11/2008
descripcio n: String
monto: Double
recibo: Recibo
IBABusi nessObject
ItemCuota
-
detalle: String
monto: Double
porcentaje : Double
enumeration
ItemCuotaEnum
id
enum
ARANCEL_BASE
EXTRACURRICULARES
EMER_M EDICAS
PRORRAT EO_MANT
COMPENSACION_COSTOS_LAB
INTE RES
CRED_A_CUENTA
OTROS_CONCEPTOS
104

Versin 2.0
FECHA 13/11/2008
Inscripcin
En estas clases se almacena toda la informacin necesaria para la inscripcin
class Inscripcion
IBABusinessObject
Pers ona
-sexo
enum
MASCULINO
-persona
FEME NINO
IBABusinessObject
apellido: String
domicilio: Domicili o
-documento
fechaNacimiento: Calendar
lugarNacimie nto: String
naci onalida d: String
nombre: String
sexo: SexoEnum
telefonos: List<Telefono>
vive: boolean
enumeratio...
SexoEnum
-tipo
emitidoPor: String
numero: Long
pais: String
tipo: T ipoDocumentoEnum
Telefono
-
Domic ilio
-domicilio
Clie nte
ResponsableAlumno
-
completo: bo olean = false

gradoInstrucci on: int
nivelInstrucci on: NivelEnum
profesion : String
tipo: Ti poResponsableEnum
cantHerman os: Long

cantHermanosEstab lecimiento: Long
cuenta: Cuenta
curso: Curso
fechaBaja: Calendar
responsables: Set<ResponsableAlumno>
tieneHermanos: boolean
usuario: Usuario
-cliente
enum
PADRE
MADRE
T UT OR
enumerati on
Niv el Enum
IBABusinessObject
Establecimie ntoEducativ o
enum
-nivel
NING UNO
PRIM ARIO
SECUNDARIO
T ERCI ARIO
UNIVERS IT ARIO
distrito: String
nivel: NivelEnum
nombre: String
numero: String
publico: boolean
-establ ecimientoEducativo
IBABusinessObject
enumeration
Estad oEnum
Inscri pcion
enum
NOPROCESADA
ACEPT ADA
RECHAZADA
-estado
anio: Long
cicloLectivo: Integer
cliente: Cli ente
di vi sion: Divisi onEnum
establ ecimientoEducativo: Establecimi entoEducativo
estado: E stadoEnum
fechaCreacion: Calendar
fechaProcesada: Calendar
modalidad: M odalidadEnum
turno: TurnoEnum
-modal idad
enumeratio...
TurnoEnum
enum
COMARTE YDISEO
ECONYG ESTION
enum
MANIANA
T ARDE
-modal idad
calle: String
codigoPosta l: String
departament o: String
local idad : String
manzana: String
numero: String
piso: String
provi ncia: P rovi nciaEnum
torre: String
-provincia
enum
BUENOS _AIRES
CAPIT AL_FEDERAL
CATAMARCA
CHA CO
CHUBUT
CORDOBA
CORRI ENTES
ENTRE _RIOS
FORMOSA
JUJUY
LA_PAMPA
LA_RIOJA
MENDOZA
MISIONES
NEUQ UEN
RIO_NEGRO
SALT A
SAN_ JUAN
SAN_ LUIS
SANT A_CRUZ
SANT A_FE
SANT IAGO_DEL_EST ERO
TIERRA_DEL_FUEGO
TUCUMAN
-division
-turno
enumeration
ModalidadEnum
enumeration
Prov inc iaEnum
-nivelInstruccion
-tipo
enumeration
TipoResponsableEnum
enum
DNI
CI
LE
LC
IBABusinessObject
descripci o n: String
numero: String
persona: Persona
enumeration
TipoDocumentoEnum
IBABusinessObject
Docum ento
-turno
enumeratio...
Div isionEnum
enum
A
B
C
R
-di vi sion
IBABusinessObject
Cur so
-
13/11/2008
ani o: Long
division: DivisionEnum
modalidad: M odalidadEnum
turno: TurnoEnum
105

Versin 2.0
FECHA 13/11/2008
Diagrama de Entidad-Relacin (DER)

En la creacin del modelo de datos se tuvo en cuenta que se utilizar hibernate
para el mapeo de objetos. Por este motivo se realizaron las estructuras de manera de
evitar futuros inconvenientes.
13/11/2008
106

Versin 2.0
FECHA 13/11/2008
Diseo de la
Arquitectura
13/11/2008
107

Versin 2.0
FECHA 13/11/2008
Anlisis de requerimientos no funcionales y restricciones

A continuacin se detallarn una serie de aspectos a considerar para el diseo de la
arquitectura que d soporte al sistema informtico a construir para satisfacer las
necesidades del Instituto Buenos Aires.
Performance
Se debe garantizar un mximo de 5 transacciones simultneas con un tiempo de
respuesta no mayor a 10 segundos, de lunes a viernes, de 9:00 a 18:00 Hs. Esta
estimacin se clculo basndose en el anlisis y la informacin provista por el rea
de cobros del Instituto. Por tiempo de respuesta se entiende el tiempo desde que
el sistema recibe el pedido de transaccin hasta que enva una respuesta. Este
tiempo incluye el tiempo de procesamiento de la respuesta del propio sistema y
de los sistemas con los que eventualmente deba interactuar (Ej: Servidores de email, Web Services, otros).
Concurrencia
El sistema debe ser concurrente para permitir asegurar la integridad de los datos
y la simultaneidad de operaciones de los distintos usuarios.
Transaccionalidad
En caso de falla, el sistema debe poder deshacer los cambios realizados hasta el
momento para asegurar que los datos queden consistentes.
Disponibilidad
El sistema debe estar disponible el 99% de las veces, y prioritariamente en los
momentos de generacin de listado de cobros y momentos de preinscripcin.
Modificabilidad
Extensibilidad: Se quiere que en el futuro el sistema pueda ser operado por los
clientes del instituto a travs del celular (WAP) o telefnicamente a travs de un
IVR1. De modo que debera pensarse en alguna interfaz que interacte con los
futuros mdulos.
Interactive Voice Response: sistema telefnico que es capaz de recibir una llamada e interactuar con el
humano a travs de grabaciones de voz.
13/11/2008
108

Versin 2.0
FECHA 13/11/2008
Interoperabilidad: La forma de envo de la informacin de cobro hacia el banco

actualmente es a travs de un e-mail. Es probable que en el futuro el banco
decida cambiar esta modalidad por un Web Service. Esta tarea no tendra que
demandar un esfuerzo mayor a 100 horas/hombre para modificar dicho aspecto.
Para hacer frente a esta cuestin se desacoplar y se aislar lo ms posible la
interaccin con dichas entidades.
Seguridad
El sistema deber asegurar confidencialidad sobre los datos del usuario. Cada
usuario tiene un nombre nico y un password (mayor a 6 caracteres y con
combinacin de letras y nmeros) que sern almacenados de manera cifrada.
Los datos con informacin acerca del usuario debern viajar encriptados.
En el sistema se manejaran dos tipos de usuarios principales: los clientes
registrados y los empleados del rea de cobros. Cada perfil dispondr para
realizar las operaciones pertinentes y no podrn acceder a privilegios de usuarios
que posean otro perfil.
El sistema deber contar con un mdulo para poder realizar auditorias y
seguimiento interno del funcionamiento de la aplicacin. Para ello deber proveer
informacin de las operaciones realizadas en todo momento, por lo tanto, un
mdulo del sistema deber encargarse de registrar las transacciones realizadas.
Testeabilidad
Durante la etapa de desarrollo para el testeo de la aplicacin se utilizar las
tcnicas de testeo unitario y debe garantizarse que el 80% del sistema estar
cubierto por los tests tanto unitarios como de pruebas de usuario.
Usabilidad
La
interfaz
del
sistema
podr
visualizarse
correctamente
utilizando
las
resoluciones ms comunes. Se podr minimizar y maximizar la pantalla

conservando las proporciones y la ubicacin de los elementos dentro de la misma.
Se debe mantener un aspecto visual consistente. Deber proveerse la posibilidad
de tener un layout (esquema) general que permita tener un men, un rea de
13/11/2008
109

Versin 2.0
FECHA 13/11/2008
informacin, un encabezado, un pie de pgina y un rea donde se mostrar el

contenido de los casos de uso a utilizar.
El sistema deber contener mensajes de error descriptivos.
Dado que el sistema se utilizara por personas residentes en la Argentina, todas las
interfaces de usuario debern estar disponible en espaol.
Debido a que el sistema esta orientado al pblico en general deber tener
comentarios descriptivos de la funcionalidad de cada una de las interfaces que
componen el sistema.
Portabilidad
La aplicacin deber poder ser utilizada tanto en principalmente en Firefox, pero
no se descarta su uso con Internet Explorer.
Tiempo
Debido a que el sistema se debe poner en produccin para el prximo ciclo lectivo
y se deben realizar con anterioridad las pruebas para certificar que el sistema
funciona segn lo previsto, el desarrollo del proyecto debe finalizarse antes del 15
de Noviembre.
13/11/2008
110

Versin 2.0
FECHA 13/11/2008
Priorizacin de requerimientos no funcionales

En este punto se definir una lista ordenada por prioridad decreciente sobre los
requerimientos no funcionales que el sistema necesita para garantizar los atributos de
calidad ms importantes para el negocio y que son altamente deseables o en algunos
casos imprescindibles que la arquitectura les d soporte.
Transaccionalidad: En caso de falla, el sistema debe poder deshacer los cambios
realizados hasta el momento para asegurar que los datos queden consistentes.
Concurrencia: El sistema debe ser concurrente para permitir asegurar la
integridad de los datos y simultaneidad de operaciones.
Seguridad: Confidencialidad de los datos del usuario, guardando informacin
sensible que solo conoce el usuario (como passwords) de manera cifrada.
Seguridad: Mdulo de auditoria que registre todas las transacciones realizadas en
el sistema.
Seguridad: Disponibilidad de varios tipos de perfiles de usuario con la posibilidad
de definir diferentes grados de restricciones sobre los usuarios incluidos en un
perfil.
Seguridad: La informacin sensible del usuario deber viajar encriptada.
Performance: Debe garantizar un mximo de 5 transacciones simultneas.
Disponibilidad: El sistema debe estar disponible el 99% de las veces.
Usabilidad: El sistema debe mostrar mensajes de error descriptivos.
Usabilidad: Se debe mantener un aspecto visual consistente.
Modificabilidad: Se debe dejar abierta la posibilidad de interactuar con las
entidades bancarias de distintas maneras.
Testeabilidad: se deben realizar mdulos de testeo unitario para minimizar los
miedos al cambio ante futuras modificaciones.
Aunque los dems requerimientos son importantes, se consideran de igual prioridad
y deben tratar de cumplirse sin que stos afecten el desarrollo de otras partes del
sistema.
13/11/2008
111

Versin 2.0
FECHA 13/11/2008
Arquitectura del sistema

Optamos por una combinacin de varias configuraciones estndar de estilos
arquitectnicos.
Tanto el dominio de la aplicacin como la arquitectura que de soporte al mismo,
sern modelados haciendo uso de la orientacin a objetos. Se ha optado el mismo dado
que el dominio tiende a ser ms complejo en un futuro por los que creemos que se
minimiza el costo de las modificaciones a realizar y aumenta la mantenibilidad general de
la aplicacin.
Dado que la aplicacin se ejecutar en un servlet container que soporte tecnologa
J2EE, se aprovechar la capacidad de definir filtros que realicen un primer proceso a los
pedidos solicitados por los usuarios a travs de los browsers. Estos procesos pueden ser
tales como comprobaciones de seguridad, apertura de sesiones y transacciones para
interactuar con la base de datos.
Tecnologa
El desarrollo del sistema se realizar haciendo uso y aprovechando las capacidades
de la tecnologa J2EE (Java To Entreprise Edition). Principalmente la eleccin de dicha
tecnologa se debe a que el equipo de desarrollo destinado a la realizacin del proyecto
posee slidos conocimientos de la misma, permitiendo as cumplir con la restriccin de
tiempo que se nos ha impuesto. Adems el foco de J2EE es proveer las bases para el
desarrollo de aplicaciones Java Server-Side portables, robustas, escalables y seguras.
Algunas ventajas de una aplicacin Server-Side:
Requerimientos mnimos para el cliente de la aplicacin.
La lgica del dominio reside completamente en el servidor.
Posibilidad de realizar mayores controles dado que la lgica del negocio reside
en el Server.
Relacionado con el punto anterior, posibilidad de realizar mltiples tipos de
clientes (Ej: cliente web, cliente desktop, web service).
La aplicacin puede ser dividida y distribuida en mltiples procesadores para
realizar
balanceo
de
carga
permitiendo
aumentar
la
disponibilidad,
escalabilidad y la recuperacin ante fallos.

Algunas desventajas de una aplicacin Server-Side:
Incompatibilidad de versiones de los clientes, generalmente browsers.
13/11/2008
112

Versin 2.0
FECHA 13/11/2008
Mayor esfuerzo para lograr, en un cliente liviano (como un browser) el

dinamismo presente en aplicaciones de escritorio.
Necesidad de realizar validaciones duplicadas en el cliente y el Server si se
quiere agregar dinamismo al cliente.
Estructura
La arquitectura estar estructurada en capas dado que el tipo de sistema que
soportar es una aplicacin web (y no se descarta de otros tipos de clientes en el futuro),
por lo que es deseable una separacin entre los componentes de la capa de presentacin,
persistencia, dominio y aplicacin.
En la arquitectura propuesta podemos identificar 3 capas:
Presentacin
Negocio
Persistencia
Como a cada capa se le define la/s responsabilidad/es que le ataen, se aumenta el
grado de desacoplamiento dado que el conocimiento y la comunicacin entre las
mismas es solo a nivel de interfaz. Esto facilita la modificabilidad, por ejemplo, al
momento de integrar al sistema Web Services y el portal WAP.
Un corolario del punto anterior es que dicha separacin brinda mayor flexibilidad
ante futuro cambios intra-capa, a costa de quizs, aadir mayor complejidad a la
solucin pero permitiendo aumentar el grado de modificabilidad.
El tener una capa exclusiva para el dominio del negocio permite que el desarrollo del
mismo no est acoplado a la forma en que se persistirn o presentarn los datos
procesados, cuestin altamente deseable dado que est previsto que los datos sean
obtenidos/guardados tanto a travs de una base de datos como de web services en
un futuro.
Como una desventaja podemos mencionar que si bien la separacin en capa eleva el
grado de desacoplamiento, existe una dependencia vertical de las clases del dominio
definidas en la capa de negocio con el resto de las capas. sta cuestin se relaciona
fuertemente con la modificabilidad del sistema e implica que si existe la necesidad de
realizar una refactorizacin en alguna de dichas clases, probablemente se vean
afectadas tambin la capa de presentacin y de persistencia.
Aunque el punto anterior sea considerado desfavorable, hemos decidido adoptar este
estilo arquitectnico dado que creemos que las ventajas son mayores. Podemos
mencionar como ventajas:
o
Amplia difusin en el mercado actual.
Amplia gama de frameworks que dan soporte a cada una de las capas
Posibilidad de paralelizacin y asignacin de tareas de desarrollo por capas.
13/11/2008
113

Versin 2.0
FECHA 13/11/2008
Estas tres ventajas permiten un tiempo de desarrollo menor dado que al existir
amplio soporte, documentacin y experiencias de usuarios de los frameworks usados
en cada capa permite resolver eventuales problemas ms rpidamente. Adems
facilita la incorporacin de programadores dado que muchos ya han usado los mismos
en otros trabajos.
Como la interaccin del usuario con el sistema se realizar a travs de la capa de
presentacin, esto permite tener acotados:
o
Los puntos de seguridad: permitiendo facilitar el control de autenticacin y

autorizacin del usuario.
El manejo de errores: lo cual se ve reflejado en la usabilidad solicitada para el

sistema en cuanto a que debe mostrar mensajes de error descriptivos.
Los puntos de auditoria: permitiendo registrar las transacciones realizadas por

el cliente.
Para resumir lo expuesto en esta seccin, se presenta a continuacin un esquema

de alto nivel de la arquitectura propuesta.
Client Side
Server Side
Application Server J2EE
Browser
Presentacin
Negocio
Persistencia
DB
Capa de presentacin
Objetivo
Permitir al usuario a travs de la UI (en este caso un browser) interactuar con la
aplicacin modelada en la capa de negocio. As mismo permite a la capa de negocio
mostrar y controlar el flujo de la informacin que se presentar a travs de esta capa.
Permite ver los resultados de los procesos efectuados.
Tiene
la
responsabilidad
del
manejo
de
validacin
de
datos
ingresados,
presentacin de los resultados, lo que permite mantener un aspecto visual consistente, y

manejo de errores. Tambin resuelve la transformacin de los datos ingresados en datos
del dominio del negocio y la transformacin de resultados del negocio a datos
presentables al usuario.
13/11/2008
114

Versin 2.0
FECHA 13/11/2008
Componentes
Para esta capa se evaluaron 2 frameworks de presentacin: Flex y GWT.
A favor de Flex podemos mencionar que posee caractersticas novedosas, las
interfaces de usuario son ms estilizadas, es fcil crear las pantallas y que est orientado
a eventos. Sin embargo para su funcionamiento en el cliente debe utilizarse el plugin de
Flash Player y las aplicaciones tienden a ser bastantes pesadas para que sean ejecutadas
en mquinas no tan modernas como las que posee actualmente el instituto, lo cual es un
gran punto en contra debido a los acotados recursos econmicos que dispone el instituto
para financiar el proyecto. Adems gran parte de los mejores componentes visuales
existentes no son gratuitos para uso comercial.
Si bien no se descarta que en una segunda versin se pueda utilizar Flex, creemos
que en esta primera versin no es recomendable su utilizacin.
Reflexionando hemos decidido que para el desarrollo de esta capa usaremos GWT
debido a que posee las siguientes caractersticas, cubriendo los requerimientos del
sistema:
Es posible implementar el patrn conocido como MVC (Model View Controller)
donde el Model sera la capa de negocio, el View seran las pginas codificadas en
Java y luego traducidas a JavaScript por GWT y el Controller sera la lgica
implementada en un Dispatcher que permite determinar el flujo de navegacin de la
aplicacin.
Alta compatibilidad nativa para Internet Explorer y Firefox si tener que realizar la
misma funcionalidad a travs de distinto cdigo HTML y JavaScript.
Soporte AJAX nativo.
Manejo de eventos de usuario.
Alto grado de flexibilidad para desarrollar componentes visuales propios debido a que
se realizan en cdigo Java y no en HTML y JavaScript.
Enfatiza la reusabilidad de componentes.
Permite realizar llamadas asincrnicas al Server.
Programacin de la interfaz de usuario en lenguaje orientado a objetos y ms
precisamente en Java.
Alta difusin en el mercado.
Alto
grado
de
soporte
(manuales,
tutoriales,
ejemplos,
comunidad
de
desarrolladores, etc.)
La mayora de los desarrolladores web lo conocen y estn utilizando (incluso GMail).
Existen varias extensiones ya realizadas por otras personas para resolver cuestiones
comunes en un desarrollo web.
Es Open Source.
13/11/2008
115

Versin 2.0
FECHA 13/11/2008
Varias de las ventajas del uso de GWT mencionadas en los puntos anteriores nos
permiten principalmente acortar el tiempo de desarrollo.
Adems GWT posee caractersticas de manejos de mensajes de errores, soporte
para layouts, internacionalizacin y otras cuestiones que permiten desarrollar fcilmente
una interfaz de usuario que soporte las caractersticas de usabilidad definidas como
requerimientos.
Alternativas acerca de los tipos de clientes para interfaz grfica

Dentro de las decisiones a tomar sobre la capa de presentacin estn si se optar
por un cliente pesado (del estilo RIA) o liviano (a travs de un browser) dado que dicha
eleccin condicionar subsiguientes decisiones y qu interfaz expone para realizar la
integracin con la capa de negocio. Respecto del cliente, convendr un cliente liviano si
las interacciones con el sistema son numerosas y hay un reiterado intercambio de datos,
y convendr un cliente ms pesado si hay una importante cantidad de datos a validar y
para efectuarlas se desea que no se acceda al servidor.
Se ha elegido optar por un cliente liviano porque tiene como ventajas la
portabilidad y la seguridad ya que no es necesario que informacin sensible del negocio
sea manejada y/o resida en los clientes, sino que son manejadas en el servidor de la
aplicacin de manera centralizada minimizando la posibilidad que un proceso de negocio
se vea afectado por prcticas maliciosas. Este aspecto muy importante dadas las
transacciones de dinero que el sistema deber manejar. Como supuesta desventaja
podemos mencionar que ser necesario el manejo de numerosos pedidos al servidor.
Decimos supuesta dado que al estar todas las acciones concentradas en el servidor se
aumenta
la
flexibilidad,
mantenibilidad
extensibilidad
para
realizar
futuras
modificaciones y que el cambio deba ser efectuado en un solo lado. Claramente tambin
est asociado a la seguridad como se mencion anteriormente.
Capa de negocio
Objetivo
La capa de negocio ser la encargada de modelar e implementar todos los casos de
uso requeridos y las reglas de negocio definidas para los mismos.
Se busca lograr una capa de negocio sencilla, que solamente contenga objetos del
dominio buscando un mayor grado de simplicidad.
Un aspecto importante a tener en cuenta es que si bien la interaccin con el cliente
primariamente es a travs de la Web, no se descarta en un futuro agregar otras
13/11/2008
116

Versin 2.0
FECHA 13/11/2008
interfases de usuario como por ejemplo consulta de reservas telefnicamente. De esta

forma, la capa de negocio debe exponer una interfaz que sea capaz de dialogar con la
capa de presentacin actual y con algn otro mdulo futuro, intentando alcanzar un alto
grado de modificabilidad. Los cambios sern menores y ms sencillos si la capa slo
maneja aspectos del negocio.
Componentes
Esta capa hace uso del servicio de persistencia para guardar la informacin ingresada
por el usuario y procesada por el sistema. Tambin para obtener datos para que
sean informados al usuario.
Tambin se hace uso de la capa de presentacin para mostrar la informacin
necesaria y para que el cliente pueda interactuar con el sistema. En esta parte, la
capa de negocio acta como proveedora de datos para la capa de presentacin.
Dado que la seguridad es uno de los requerimientos importantes que debe abordar la
arquitectura se aplicar una tctica que nos permita poder validar para cada pedido
del usuario si el mismo posee los permisos apropiados. Para poder cumplir con estos
requerimientos de seguridad se utilizara en toda la aplicacin el framework de
seguridad llamado Acegi en conjunto con Spring, el cual nos permite mantener la
lgica de negocio libre de cdigo de seguridad, permitiendo que no se vea
comprometida la modificabilidad. Este framework es muy sencillo de configurar y
demanda poco tiempo de aprendizaje.
Capa de persistencia
Objetivo
Proveer del soporte necesario para poder almacenar la informacin manejada por la
aplicacin y recuperarla para su procesado durante la vida til de la aplicacin.
Para poder proveer dicho soporte sta capa debe tener una interfaz apropiada con
la capa del dominio posibilitando el fcil acceso a los datos que pueden estar
almacenados en distintos tipos de repositorios.
Componentes
Para poder cumplir con el objetivo de esta capa, es necesario definir 4 cuestiones
fundamentales:
Medio fsico donde se almacenar la informacin.
Forma de comunicacin entre la aplicacin y el medio fsico de almacenamiento.
Tecnologa de conversin/adaptacin de los datos al ambiente de objetos (de ser
necesario).
13/11/2008
117

Versin 2.0
FECHA 13/11/2008
Interfaz para el acceso a dicha capa desde el dominio de la aplicacin.

Enunciados los puntos anteriores pasaremos a explicar la estrategia de solucin
adoptada para la resolucin de los mismos:
Como medio fsico, para la arquitectura descrita, se propone el uso de un motor
de base de datos relacional. Se ha optado por esta solucin dado que en el
mercado actual existen RDMS con amplio soporte, altas prestaciones, priorizando
la
escalabilidad
de
los
datos,
su
rpido
acceso,
su
disponibilidad
transaccionalidad; cuestiones altamente prioritarias como requerimientos no

funcionales.
Otro factor importante es la necesidad de que el sistema est en produccin para
el 15 de Noviembre, por lo cual se necesita disponer de recursos humanos con
conocimientos en la tecnologa utilizada en el menor tiempo posible, y
actualmente, al estar ms expandidos los motores de base de datos relacional, es
ms factible conseguir recursos en sta tecnologa.
Para resolver la comunicacin se har uso de Drivers JDBC (Java Database
Connectivity) correspondiente a la base de datos seleccionada. La API de JDBC
forma parte de la especificacin J2EE y provee conectividad entre la aplicacin
Java y la base de datos independientemente de cul sea esta ltima dado que
existen diversas implementaciones (Drivers) de dicha API.
Dado que estaremos usando una base de datos que organiza la informacin de
manera relacional y que se ha adoptado modelar el dominio a travs de la
orientacin de objetos (la cual se puede pensar como una estructura de grafos)
necesitamos de algn mecanismo que permita realizar la adaptacin entre estos
dos tipos de estructuras. Estos sistemas son conocidos como ORM (Object
Relational Mapping). Hemos optado por utilizar el ORM denominado Hibernate
debido a su amplia aceptacin en el mercado, soporte para las base de datos ms
conocidas usando Drivers JDBC, la gran cantidad de puntos de extensin que
soporta y su alta escalabilidad.
Por ltimo para el acceso a la capa de persistencia se utilizar un servicio que
hemos denominado PersistenceService, permitiendo concentrar en un solo
punto los accesos a la capa en cuestin. El mismo es de desarrollo propio.
Diagrama de Componentes
A continuacin mostraremos la composicin de componentes de arquitectura y la
interaccin entre los mismos:
13/11/2008
118

Versin 2.0
FECHA 13/11/2008
cmp Diagrama de componentes
Dominio IBA
use
use
use
Framew ork Presentacin
GWT 1 .5.2
Componente s Propios
Framew ork P ersistencia
Hiber nate 3.3.1
use
Brow ser con soporte para Jav aScript (Firefox o IE)
Interfaz Entidad
Banc aria
JDBC MySQL
use
Base de Datos (MySQL 5.0.67)
Diagrama de Despliegue
A continuacin mostraremos cmo es la distribucin de cada uno de los
componentes enunciados y como se compone la arquitectura tanto del lado del cliente
como del lado del servidor.
deployment Diagrama de Despliegue
Server Side
Cl ient Side
Sun JVM 1.6 Update 6
Apache Tomcat 6.0.18

Application Serv er
IBA. w ar
+ Arch. Configuracin
Firefox o IE
Brow ser
+ Estilos
+ Imgenes
Jav aS cript
GWT 1.5.2
Presen tacin
CS S
HTTP,HTTPS
Java 1.6 Update 6

Dominio
HTML
M ySQL 5.0.67
Database Serv er
Hi bernate 3.3.1
Persis tencia
JDBC
IBA S chema
13/11/2008
119

Versin 2.0
FECHA 13/11/2008
Conceptos transversales
A continuacin se definirn conceptos presentes a lo largo de toda la aplicacin y se
enunciar la postura a tomada.
Logging
El concepto de Logging permite poder trazar los eventos que ocurren
durante la ejecucin de la aplicacin, facilitado la tarea de desarrollo,
correccin de errores y mantenimiento, posibilitando reducir los tiempos
dedicados al desarrollo. ste punto en conjunto con otras cuestiones
permitirn cumplir el proyecto en el tiempo requerido.
Para realizar las tareas de logging se utilizara la API de interfases definida
en el utilitario Jakarta commons-logging de Apache. La misma define una
serie de interfases comunes permitiendo elegir o alternar la implementacin a
utilizar. En nuestro caso, la implementacin a usar ser el ampliamente
reconocido Log4J.
Se ha decidido el uso de esta implementacin dado que no solo ser
usada por la aplicacin, sino que tambin los frameworks usados por la
arquitectura usan y recomiendan la misma.
Adems su configuracin es muy sencilla y permite efectuar diferentes
niveles de logging, pudiendo definir luego el nivel deseado de detalle.
Otra caracterstica importante es que se puede configurar distintas
salidas, como un archivo, e-mail, base de datos, ftp y muchos otros. Tambin
provee una interfaz para poder definir una implementacin propia.
Seguridad
Para las cuestiones de seguridad hemos evaluado usar los frameworks
JGuard, JSecurity y Acegi Security.
Respecto a JSecurity es un framework muy nuevo y creemos que no es
conveniente su uso dado que le falta madurar; JGuard provee funcionalidades
similares a Acegi pero no est tan difundido como este ltimo. Por lo tanto,
por las razones que se detallarn a continuacin hemos decidido hacer uso del
framework de autenticacin y autorizacin llamado Acegi Security. Su
adopcin se debe a que dicho framework es muy reconocido en el mercado y
altamente usado en aplicaciones empresariales de gran escala dado que
posee un alto grado de flexibilidad de configuracin y variados puntos de
extensin. Permite diferentes formas de autenticacin (HTTP Basic, HTTP
Digest, certificados X509, LDAP) y autorizacin sobre todos los HTTP Request
13/11/2008
120

Versin 2.0
de la
FECHA 13/11/2008
aplicacin y sobre cada objeto del dominio en particular permitiendo
definir una lista de control de accesos (ACL, Access Control List).

Adems se integra con el framework de aplicacin denominado Spring
(tambin con un alto nivel de aceptacin en el mercado) para cuestiones de
Inyeccin de Dependencia (o IoC Inversion of Control).
Ambos frameworks poseen muy buen soporte tanto por sus creadores
como por la comunidad y existe material de referencia de muy buena calidad.
Adems el equipo de desarrollo destinado a la realizacin del proyecto posee
slidos conocimientos de stos frameworks.
Excepciones
Se utilizar tanto para el desarrollo de la aplicacin como de la
arquitectura, casi en la totalidad de los casos, excepciones no chequeadas,
reservando el uso de las chequeadas para casos muy especficos y donde sea
necesario.
Dicha eleccin fue tomada en base a que las excepciones no chequeadas
proveen ms flexibilidad dado que no es obligatorio definir en la firma de los
mtodos que excepciones pueden llegar a ser lanzadas y que deban ser
tratadas. Adems aumenta la declaratividad y legibilidad del cdigo.
Tambin se usar una jerarqua de excepciones para agrupar en
excepciones de negocio, de persistencia, de presentacin, de seguridad y de
programa. Esta separacin permite que puedan ser tratadas (por ejemplo en
un filtro) de forma distinta en el caso de que la excepcin se propague y nadie
la trate permitiendo generar mensajes ms descriptivos para el usuario.
Testeo Unitario
Se usar la tcnica de testeo unitario tanto para los componentes de la
arquitectura como para los de la aplicacin.
Podemos mencionar como ventajas de su uso y aplicacin los siguientes
puntos:
Facilita el refactor dado que se pierde el miedo a realizar cambios ya
que si se modifica algo, corriendo los tests puedo verificar si se
produjo un cambio en el comportamiento o no.
Es una buena herramienta para solucionar errores que han sido
detectados y pueden ser reproducidos.
Contribuye a la documentacin del sistema.
Permite aumentar la claridad del cdigo dado que los tests y sus
comprobaciones estn separados de la lgica del negocio.
13/11/2008
121

Versin 2.0
FECHA 13/11/2008
Permite mostrar como es el uso de un determinado componente o

una parte del mismo.
Como corolario de todas las anteriores, ayuda a aumentar la claridad
y calidad del cdigo y la robustez del sistema.
Si bien la realizacin de los casos de prueba requieren un cierto esfuerzo
adicional creemos que las ventajas de su uso es mucho mayor que esta
posible desventaja dado que teniendo un buen conjunto de tests el costo de
corregir un error tiende a ser muchos ms estable y menor en el tiempo que
si no se realiza testeo unitario.
La implementacin que usaremos ser JUnit dada su alta difusin y
aceptacin en el mercado. Adems el IDE a usar (Eclipse) posee integracin
nativa con dicho framework.
Auditoria
A travs de un servicio se realizarn las cuestiones relacionadas con el
proceso de auditoria del sistema, permitiendo registrar las acciones solicitadas
por el usuario.
Para esto no existe un framework que facilite la tarea, por lo tanto se
realizar a travs de un componente propio.
13/11/2008
122

Versin 2.0
FECHA 13/11/2008
Software Configuration Management (SCM)

Sistema de Control de Versiones
Usaremos como software de administracin de versiones el Subversin conocido
como SVN.
Los motivos que llevaron a tomar SVN, y no CVS (Concurrent Versions System, otro
sistema de control de versiones) por ejemplo, son los siguientes:
Es open source y free software. CollabNet posee los derechos del cdigo, pero se
distribuye bajo licencia del estilo Apache/BSD, permitiendo ser descargado,
modificado y redistribuido libremente.
Sigue la historia de los archivos y directorios a travs de copias y renombrados (y no
se pierde el historial del archivo en caso de renombrarlo)
Maneja eficientemente archivos binarios (y no los trata internamente como si fueran
de texto)
Se envan slo las diferencias en ambas direcciones (y no se envan siempre al
servidor los archivos completos).
Posibilidad de uso a travs de HTTP y HTTPS, con el uso de este ltimo, se permite
no ser filtrados su uso por proxies corporativos.
Posibilidad de agregar mdulos de extensin para diversas cuestiones tanto
administrativas como de uso.
Utilizaremos Subversive como GUI, un plugin que integra Subversin (SVN) al IDE
Eclipse.
Herramienta de Software Project Managment

Para realizar la administracin del cdigo del software y del proyecto, se utilizar
una herramienta de gestin y comprensin de proyectos Java denominada Maven en su
versin 2.0.9. Esta herramienta fue desarrollada por Apache Foundation y es Open
Source.
Esta herramienta permite automatizar la gestin de dependencias externas
necesarias
para
el
funcionamiento
del
sistema.
Adems
permite
generar
automticamente el archivo .war de la aplicacin para que pueda ser desplegado en el

servidor.
Una
de
sus
caractersticas
principales
es
que
permite
agregarle
nuevas
funcionalidades para facilitar cuestiones de gestin del proyecto de software a travs de

plugins.
13/11/2008
123

Versin 2.0
FECHA 13/11/2008
Herramientas de colaboracin
Para el manejo del conocimiento vamos a usar los servicios de Assembla
(www.assembla.com). Assembla es una organizacin que provee de una basta cantidad
de herramientas de colaboracin orientadas a mejorar el desarrollo de software, las
comunicaciones
el
equipo de trabajo. Hace ms
fcil
la colaboracin
el
compartimiento de conocimientos dentro del equipo de desarrollo. Los servicios ofrecidos

tienen como ventaja el simple manejo y accesibilidad, una interfase amigable,
herramientas poderosas y de caractersticas profesionales.
Entre las herramientas ofrecidas podemos mencionar:
SVN: proveen un repositorio para el versionados de cdigo y documentos sin
lmites de espacio y que puede ser accedido mediante https.
TRAC: es un wiki y un sistema de issue tracker.
Files: permite subir archivos al espacio del proyecto.
Tickets: permite asignar tareas a los integrantes del proyecto.
Todas estas herramientas son provistas sin ningn costo y son accesibles va
cualquier browser.
Code Coverage (Cobertura del cdigo por medio de los Tests)

Vamos a utilizar la herramienta EclEmma para mejorar la calidad de las pruebas.
EclEmma es una herramienta poderosa y altamente configurable para el anlisis del
code coverage (cobertura del cdigo). La misma descubre las secciones del cdigo que
no estn siendo probadas adecuadamente por los Unit Tests (pruebas de unidad).
Mencionaremos una frase que resume la importancia del uso de esta herramienta
en el transcurso de la etapa de desarrollo y mantenimiento:
Unit tests drive code quality; Code coverage drives unit test quality.
EclEmma es compatible con JUnit 3.x y 4.x y otros frameworks de testing.
Esta herramienta es un plugin de Eclipse por lo cual su integracin al entorno de
desarrollo es directa.
Bug Tracking, Issue Tracking y Project Management

Para realizar estas tareas utilizaremos la herramienta Trac (provisto por
www.assembla.com) dado que la misma hace que dicho proceso sea ms fcil para el
equipo.
13/11/2008
124

Versin 2.0
FECHA 13/11/2008
Algunas caractersticas remarcables de la herramienta son:

Permite manejar los bugs, tareas, mejoras o cualquier issue.
Tiene una interfaz de usuario limpia y poderosa de fcil entendimiento para
los usuarios funcionales y para los usuarios tcnicos.
Permite relacionar procesos de negocio a workflows personalizables.
Fcil de extender e integrar con otros sistemas (E-Mail, RSS, Excel, XML y
Sistemas de Control de Versiones)
Alta configurabilidad de las opciones de comunicacin.
13/11/2008
125

Versin 2.0
FECHA 13/11/2008
Tecnologa
Se desarrollara mediante la tecnologa J2EE (Java To Enterprise Edition), esto lo
seleccionamos porque cumple las especificaciones y pruebas de conformidad que
permiten la portabilidad de las aplicaciones a travs de la amplia gama de sistemas
empresariales compatibles con J2EE.
J2EE est basado en la arquitectura del lado del servidor. Este tipo de arquitectura
concentra la mayora de los procesos de la aplicacin en el servidor, haciendo menor el
requerimiento de hardware del cliente. Con este tipo de arquitectura se permite que una
simple aplicacin soporte simultneamente clientes con distintos tipos de interfaces.
Adems permite escalabilidad, confiabilidad, disponibilidad y recuperabilidad.
Aplicaciones basadas en el servidor pueden ser divididas y distribuidas en mltiples
procesadores.
Maquina Virtual
Vamos a utilizar la JDK (Java Development Kit) versin 1.6 Update 6 la cual
adems de poseer la JRE (Java Runtime Enviroment) de la misma versin, incluye
herramientas especficas orientadas al desarrollador.
La JRE es la implementacin de Sun Microsystems de la JMV (Java Virtual Machina)
sobre donde se ejecutar la aplicacin.
Application Server
Utilizaremos como Application Server Apache Tomcat versin 6.0.18. El cual es
OpenSource, multiplataforma, consume pocos recursos y es de fcil instalacin y
mantenimiento.
Repositorio de Datos
Utilizaremos la Base de Datos MySQL Community Server versin 5.0.67.
La elegimos porque su licencia es gratuita, por su velocidad a la hora de realizar las
operaciones, lo que la hace uno de los gestores que ofrecen mayor rendimiento, por su
gran facilidad de configuracin e instalacin, por dar soporte a multiplataformas y
principalmente por su baja probabilidad de corromper los datos debido a que es
fundamental para la aplicacin mantener lo datos consistentes.
IDE para el Entorno de Desarrollo

Se utilizar Eclipse 3.4 con WTP (Web Tools Platform) 2.0 con los plugins para los
productos mencionados en la seccin Software Configuration Management.
13/11/2008
126

Versin 2.0
FECHA 13/11/2008
Se elige este IDE dado que provee una muy buena interfaz grfica, es
multiplataforma, no se instala, es Open Source, permite agregarle funcionalidad a travs
de plugins, entre otras.
13/11/2008
127

Versin 2.0
FECHA 13/11/2008
Normas de codificacin
El motivo de esta seccin es proveer las normas bsicas de codificacin y
convenciones para obtener los siguientes beneficios:
Incrementar la legibilidad
Reducir el esfuerzo de mantenimiento
Facilitar la reusabilidad y la comparticin de cdigo
Los estndares que usaremos son los que define Sun como convenciones de
codificacin para Java. Los mismos se encuentran detallados en un PDF provisto por Sun
en la siguiente direccin: http://java.sun.com/docs/codeconv/CodeConventions.pdf
Para poder facilitar el cumplimiento de dichas normas se usar un plugin para el IDE
Eclipse denominado Eclipse-CS (http://eclipse-cs.sourceforge.net/) basado en CheckStyle
(http://checkstyle.sourceforge.net/). El mismo permite automatizar la comprobacin del
cumplimiento de las normas de Sun (o de las personalizadas, dado que se puede configurar
los estilos de codificacin) en el cdigo de la aplicacin.
Para la documentacin del cdigo se usar la norma de documentacin estndar para

lenguaje Java denominada JavaDoc (http://java.sun.com/j2se/javadoc/), dado que es posible
ser manejada desde el Eclipse debido a su excelente integracin. Adems permite generar
documentacin automtica sobre las clases, interfaces, relaciones, atributos, mtodos y
parmetros con sus correspondientes explicaciones.
13/11/2008
128

Versin 2.0
FECHA 13/11/2008
Documentacin
Todo lo referente a arquitectura del proyecto se documentar utilizando los
diagramas de UML y otros diagramas actualmente usados en el mercado.
Se armar un diagrama de despliegue, un DER de la base de datos (lgico y fsico)
y diagrama de clases.
Para la documentacin del cdigo utilizaremos JavaDoc.
Se documentarn los casos de pruebas utilizados.
Tambin realizaremos prototipos de interfaz de usuario.
13/11/2008
129

Versin 2.0
FECHA 13/11/2008
Administracin de riesgos arquitecturales

Utilizaremos la clasificacin de los atributos de calidad para dividir los riesgos.
Performance
Los principales problemas de performance que puede presentar la aplicacin se
atribuyen a dos factores: la arquitectura en capas y la gran cantidad de conexiones con
otros sistemas.
El primero genera que la informacin de una operacin sea convertida varias veces,
para saltar de capa en capa, creando una carga adicional para el sistema en general.
Esto se ve ms que nada en los Web Services y en la capa de Presentacin. En el caso de
que la aplicacin sufra por este motivo, como primera instancia se debera analizar la
posibilidad de aumentar la capacidad del hardware. Si no se resuelve, sera necesario
plantear una replicacin de servidores para dividir el trabajo.
En el caso de las conexiones con otros sistemas se genera una dependencia de
performance, o sea, estamos sujetos a la respuesta que tengan otros sistemas. La
solucin para esto sera mucho ms compleja ya que no tenemos contacto con el sistema
al cual nos vamos a comunicar. Una solucin sera analizar si es posible realizar algunas
de las transacciones off-line o asincrnicas para bajar la carga de la conexin y manejar
la persistencia de nuestro lado.
Disponibilidad
En este punto, el mayor riesgo es la rotura del servidor, ya que solo hay uno.
Teniendo en cuenta que todo termina dependiendo de esta mquina la convierte en un
punto dbil del sistema. La solucin sera tener otro servidor para poder derivar el
trabajo mientras se intenta levantar el servidor cado.
Tambin, como en el punto anterior, dependemos de la disponibilidad que tengan
los otros sistemas. Esto no es tan grave ya que solo afecta las transacciones con las
compaas que pierdan la conexin al sistema.
Modificabilidad
El sistema no presenta grandes riesgos a nivel de modificabilidad a menos que por
problema de performance o algn otro, el diseo en capas quede obsoleto. La prdida en
este caso es el consumo de tiempo para la reestructuracin del mismo.
13/11/2008
130

Versin 2.0
FECHA 13/11/2008
Seguridad
Al utilizar como capa de presentacin una interfase web estndar, el uso de
tecnologas de encriptacin esta reducida a lo que soporten los navegadores actuales.
Para solucionarlo, habra que cambiar la capa de presentacin.
Para hacer frente a todo los problemas relacionados a hacking, cracking, sniffing,
etc. se tendrn en cuenta normas fundamentales y estndares en el mercado tendientes
a minimizar la ocurrencia de estos posibles ataques.
Testeabilidad
La aplicacin no tendr riesgos de testeabilidad si se prosigue correctamente con su
plan de desarrollo.
Usabilidad
El riesgo mayor en este caso es que el usuario no tenga una buena respuesta frente
a la interfaz presentada y se deba cambiar. Primero se ver de mejorar el diseo y en el
ltimo de los casos se desarrollarn clientes pesados.
13/11/2008
131

Versin 2.0
FECHA 13/11/2008
Diagrama del Framework de la Capa de Persistencia

Para realizar la persistencia de los datos manejados por la aplicacin ser necesario
la creacin y uso de un framework propio. Para ello proponemos un esquema de
arquitectura preeliminar.
El mismo proveer abstracciones sobre las clases ms comunes de Hibernate (el
framework de mapeo de objetos a relacional que hemos seleccionado para utilizar en la
capa de persistencia). Dichas abstracciones permiten manejar de forma ms automtica
las transacciones (los commit y rollback) de la base de datos dependiendo de si se
produjeron errores o no.
Para que se pueda hacer uso de dichas capacidades, los objetos de negocio deben
extender de BusinessObject y estar registradas en la subclase de ClassCatalog de la
aplicacin
que
se
est
desarrollando,
para
ello
se
debe
redefinir
el
mtodo
registerClasses() y dentro del mismo llamar a register() y como parmetro pasarle el

Class de la subclase de BusinessObject a registrar. Veamos la estructura de lo que
acabamos de enunciar:
class ClassCatalog
ClassCatalog
+
+
register() : voi d
registerClasses() : void
IBAClass Catalog
+
OtherAppCl assCatalog
+
BusinessObject posee mtodos que permite un manejo del guardado/borrado de

objetos en la DB (en realidad de los datos) de una forma que es ms acorde al
paradigma de objetos.
Una de las clases ms usadas de este framework es PersistenceService dado que a
travs de ella es que construyen los pedidos (queries) para realizar consultas a la base
de datos. Dicha construccin retorna un SearchCriteria al cual le podremos agregar las
restricciones necesarias segn sea el caso y definir el orden de los datos a obtener.
13/11/2008
132

Versin 2.0
FECHA 13/11/2008
Si bien PersistenceService define mtodos para el guardado y borrado de objetos,

es conveniente que esto sea realizado por los mismos BusinessObjects a travs de los
mtodos provistos por BusinessObject.
A continuacin esquematizaremos la estructura bsica y con las clases ms
importantes del framework de persistencia:
class Framew ork
Database Session
Sess ion
1
+
+
+
+
+
beginTransact ion() : void

comm itTransaction() : void
endTransacti on() : void
getHibernateSe ssion() : void
rollbackTransa ction() : void
DatabaseTr ansaction
+
+
commit() : void
rollback() : voi d
Transaction
1
Hibe rna te
Framew ork
use
SearchCriteria
Persisten ceServ ice
+
+
+
delete() : void
getCriteri a() : void
save() : void
Criteria
use
+
+
+
+
+
add() : void
addOrder() : void
createCriteria() : void
findUnique() : voi d
li st() : void
use
interface
Persistible
+
+
delete() : void
save() : void
Busines sObj ect

+
+
Usua rio
delete() : void
save() : void
TipoDocumento
DAOs (Data Access Object)

Una prctica comn es usar el patrn DAO (Data Access Object) definido por cada
objeto de negocio para realizar las operaciones de acceso a la base de datos, permitiendo
tener en un solo punto la mayora de las comunicaciones que se realizan con ella. Este
patrn es realmente muy sencillo y no posee una estructura determinada ya que es ms
bien un concepto. Una forma de implementar este patrn es definiendo mtodos de clase
(o static, en nomenclatura Java) para permitir su fcil acceso. Ej:
13/11/2008
133

Versin 2.0
FECHA 13/11/2008
# UsuarioDAO
public static Usuario getByUsuario(String username) {
[]
}
public static List<Usuario> getAll() {
[]
}
Adems de la ventaja de tener concentrado la totalidad (o casi toda) de los accesos
a la base de datos para obtener los datos necesarios, sta prctica permite que el cdigo
quede ms claro, entendible y pueda ser reutilizado en varios casos de uso que requieran
la misma informacin (Ej: lista de tipos de documentos, buscar una notificacin por su
cdigo de barras).
Dichos DAOs utilizan la arquitectura de persistencia definida y hacen un uso
intensivo de la clase PersistenceService para poder cumplir con el objetivo de proveer los
datos solicitados.
Tambin hemos ideado un esquema y una abstraccin que recomendamos usar
para estandarizar la forma de acceder a la base de datos para realizar consultas.
A continuacin mostraremos un ejemplo del esquema propuesto, siendo la clases
AbstractHibernateDAO una clase del framework de persistencia y el resto clases de
dominio propias del sistema a construir.
class DAO
AbstractHibernateDAO<T>
interface
AlumnoDAO
+
+
getAll () : List<Alumno>
getByDocumento(Long, String) : Al umno
Alumno
-
13/11/2008
apell ido: int

nombre: int
nroDocumento: int
tipoDocumento: int
+
+
+
+
+
+
+
+
getCriteria() : Criteria
getCriteria(String) : Criteria
getQuery(String) : Query
getType() : Class<T>
list(Criteri a) : List<T>
list(Query) : List<T>
uniqueResult (Query) : T
uniqueResult(Criteri a) : T
AlumnoHibernateDAO<Alumno>
+
getType() : Cl ass<T>
134

Versin 2.0
FECHA 13/11/2008
Diagrama del Framework de la Capa de Presentacin

Para facilitar la construccin de las interfaces grficas de usuario hemos
considerado necesario generar unas abstracciones sobre la base GWT (Google Web
Toolkit), el framework de presentacin elegido para usar.
Para ello debemos diferenciar los 2 lados posibles: cliente y servidor.
Para el lado del cliente, se han creado una abstraccin para las pginas (GwtPage),
a su vez, como un caso de uso puede contener varias pginas se ha creado un
contenedor de pginas (GwtPageGroup). Como la aplicacin tendr varios casos de uso
que debern ser coordinados y gestionados, es que surge la necesidad de crear un
controlador (GwtController) que administre los grupos de pginas y el contexto del
cliente.
Para el lado del servidor, se ha creado un Servlet customizado (GwtBaseServlet)
basado en el Servlet estndar de GWT (RemoteServiceServlet) dado que es necesario
realizar cuestiones de seguridad comunes a todos los casos y permite encapsular
complejidades de conexiones y otro temas. Extendiendo GwtBaseServlet es que
generamos una abstraccin para que los casos de uso se concentren en la lgica del
mismo sin tener que preocuparse por la gestin del mismo.
A continuacin esquematizaremos en un diagrama de clases los aspectos ms
importantes del framework de presentacin.
13/11/2008
135

Versin 2.0
13/11/2008
FECHA 13/11/2008
136

Versin 2.0
FECHA 13/11/2008
Para comprender mejor el framework de presentacin y cmo es su utilizacin el

proyecto, expondremos un diagrama de clases con un ejemplo de uso del mismo:
13/11/2008
137

Versin 2.0
FECHA 13/11/2008
Informes de
Avance
13/11/2008
138

Versin 2.0
FECHA 13/11/2008
Informe de avance al 09/05/2008

Tareas
Entregado
En esta entrega
Gantt para primer cuatrimestre.

Brief acta de proyecto.
Gantt con las tareas y entregables para el primer y

segundo cuatrimestre.
Brief acta de proyecto con el formato solicitado.
Acta de proyecto con el formato solicitado.
Documento de anlisis riesgos
Definicin de los roles necesarios.
Anlisis de factibilidad tcnica y operativa.
En Proceso
Definir las fechas para las tareas del segundo
cuatrimestre.
Completar el acta de proyecto.
Pendiente
Empezar la realizacin del anlisis de los casos de
uso.
Completar la documentacin.
Problemas Presentados
Problema
Disponibilidad de tiempo
13/11/2008
Detalles
Se nos hizo complicado avanzar demasiado con
el proyecto dado que fue una semana complicada
laboralmente para todos los miembros del grupo.
139

Versin 2.0
FECHA 13/11/2008

Tareas
Entregado
En esta entrega
Gantt para primer cuatrimestre.

Brief Acta de Proyecto.
Gantt reorganizado segn lo acordado en la

anterior revisin.
Acta de proyecto corregido.
Acta de Proyecto
Documento de anlisis riesgos
Factibilidad
Definicin de la Matriz de Roles - Entregables.

Anlisis de funcionalidad Generar listado de
dbitos para el banco del mdulo Gestin de
Cobranzas.
En Proceso
Confeccin de las especificaciones de las
funcionalidades del mdulo Gestin de
Cobranzas.
Ajustar fechas en la planificacin del segundo
cuatrimestre
Pendiente
Realizar prximamente la factibilidad econmica.
Problema
Confeccin del Documento de Riesgos
13/11/2008
Detalles
Si bien no es un problema en si, confeccionamos
el documento de riesgos pero aun no tenemos el
formato solicitado por la ctedra.
140

Versin 2.0
FECHA 13/11/2008

Tareas
Entregado
En esta entrega
Gantt Completo.
Documento de anlisis riesgos corregido
Matriz de Roles Entregables corregido
Acta de Proyecto
Casos de Uso corregidos
Factibilidad
Factibilidad Econmica
Anlisis de Riesgos
En Proceso
Completar y Refinar los documentos de los casos
de uso.
Primeros Caso de Uso
Realizar los
actividades.
Pendiente
diagramas
de
secuencia
Problema
Definicin de requerimientos
13/11/2008
Detalles
Nos dimos cuenta que algunos requerimientos no
estaban bien planteados.
141

Versin 2.0
FECHA 13/11/2008

Tareas
Entregado
En esta entrega
Gantt Completo.
Nueva revisin de los Casos de Uso
Estructura del equipo corregida
Acta de Proyecto
En Proceso
Completar y Refinar los documentos del anlisis.
Factibilidad
Anlisis de Riesgos
Pendiente
Empezar con la etapa de diseo.
Casos de Uso
Problema
13/11/2008
Detalles
142

Versin 2.0
FECHA 13/11/2008

Tareas
Entregado
En esta entrega
Gantt Completo y actualizado.
Documentacin del anlisis
Documentacin del diseo
Acta de Proyecto
Correcciones varias de los casos de uso
Factibilidad
Documentacin completa del 1 cuatrimestre
Anlisis de Riesgos
CD con la documentacin en formato digital
Casos de Uso
En Proceso
Terminar de realizar los prototipos de las
interfases de usuario.
Pendiente
Realizar el video comercial.
Empezar a codificar la solucin.
Problema
13/11/2008
Detalles
143

Versin 2.0
FECHA 13/11/2008

Tareas
Entregado
En esta entrega
Documentacin completa del 1

cuatrimestre
CD con la documentacin en
formato digital
Documentacin completa del 1 cuatrimestre

corregida (enviada por e-mail a los profesores a
cargo del proyecto)
Gantt actualizado con las fechas de entrega del
video y de la presentacin comercial
En Proceso
Codificacin de la arquitectura de la aplicacin
Codificacin del mdulo de generacin e
interpretacin de los archivos usados por la
entidad bancaria
Realizacin del video comercial del producto
Pendiente
Armar la presentacin comercial.
Problema
13/11/2008
Detalles
144

Versin 2.0
FECHA 13/11/2008

Tareas
Entregado
En esta entrega

cuatrimestre
Armado de la arquitectura de la aplicacin.
CD con la documentacin en
formato digital
Codificacin del mdulo de generacin e

interpretacin de los archivos usados por la
entidad bancaria
Exposicin de la presentacin
comercial.
Utilitario de generacin e interpretacin de los

archivos usados por la entidad bancaria.
Video comercial del producto
Correcciones surgidas en la reunin del

15/08/20008.
En Proceso
Desarrollo del Mdulo de Preinscripcin
Desarrollo del Mdulo de Administracin de
datos del alumno.
Pendiente
Armar la presentacin comercial.
Problema
13/11/2008
Detalles
145

Versin 2.0
FECHA 13/11/2008

Tareas
Entregado
En esta entrega

cuatrimestre corregida (enviada por
e-mail a los profesores a cargo del
proyecto)
Gantt actualizado con las fechas de
entrega del video y de la
presentacin comercial
Mdulo de Preinscripcin
Mdulo de Modificacin de datos del Usuario.
Correcciones
26/09/20008.
surgidas
en
la
reunin
del
En Proceso
Mdulo de validacin de ingreso al sistema.
Mdulo de administracin de seguridad (usuarios,
perfiles y permisos).
Actualizacin de la documentacin.
Pendiente
Correccin del tamao de la aplicacin.
Ver la posibilidad de subir la aplicacin para que
sea accedida por la ctedra.
Problema
13/11/2008
Detalles
146

Versin 2.0
FECHA 13/11/2008

Tareas
Entregado
En esta entrega
Mdulo de validacin de ingreso al sistema.
Mdulo de Modificacin de datos

del Usuario.
Mdulo de administracin de seguridad (usuarios,

perfiles y permisos).
Correcciones
10/10/20008.
surgidas
en
la
reunin
del
En Proceso
Codificacin del mdulo de generacin de
archivo de dbitos a enviar al banco
Codificacin del mdulo de proceso de archivo
con el resultado de los dbitos recibidos desde el
banco.
Ajuste de la documentacin.
Generacin de los manuales del sistema.
Pendiente
Continuar el desarrollo del mdulo de cobranza.
Continuar el desarrollo del mdulo de situacin
va Web.
Agregado de estadsticas de preinscripciones.
Problema
13/11/2008
Detalles
147

Versin 2.0
FECHA 13/11/2008

Tareas
Entregado
En esta entrega
Documentacin del proyecto
Mdulo de Modificacin de datos

del Usuario.
Manuales de usuario
Mdulo de validacin de ingreso al

sistema.
Mdulo de administracin de
seguridad (usuarios, perfiles y
permisos).
Mdulo de Gestin de Cobranzas
Manuales de instalacin y configuracin

CD que contiene el sistema y la documentacin
en formato digital
Exposicin presentando la versin 1.0 del sistema
en funcionamiento
En Proceso
Pendiente
Problema
13/11/2008
Detalles
148

Versin 2.0
FECHA 13/11/2008
Minutas de
Reunin
13/11/2008
149

Versin 2.0
FECHA 13/11/2008
Minuta de reunin del da 09/05/2008

i)
ASISTENTES
Grupo 507:

Gonzlez Lorenzo, Sebastin
Ctedra de Proyecto:
Gonzlez, Mara Cecilia

Salem, Gabriela
Suasnabar, Mara Julia
ii) OBJETIVO DE LA REUNIN

Realizar una revisin del estado del proyecto y del avance del mismo
Revisar la documentacin generada
Revisar y ajustar la planificacin
iii) TEMAS TRATADOS
Se revis la documentacin, se definieron los ajustes a realizar y los avances a solicitar
para la prxima entrega.
iv) PRXIMOS PASOS
Se nos realizaron las siguientes observaciones a modificar para la siguiente reunin
planificada:
Realizar la matriz de asociacin de Roles con Entregables
Planificar la presentacin comercial para el segundo cuatrimestre
Agregar la capacitacin del equipo de trabajo a la planificacin
Agregar tareas de configuracin de entorno para desarrollo a la planificacin
Cambiar lo que definimos como Caso de Uso XYZ por Funcionalidad XYZ
Identificar los entregables dentro de la planificacin con un formato que sobresalte
Cambiar en el Acta de Proyecto en donde dice ETAPA por FASE (Ej.: en Resultados de
cada Etapa)
Poner los entregables del diseo a nivel de mdulo.
v)
PRXIMA REUNIN
Se planific para ser realizada el da Viernes 23 de mayo de 2008
Se entregar el Anlisis de los Riesgos, la matriz de Roles-Entregables, el Anlisis de
la funcionalidad de Generacin de listados de dbitos para el banco, la planificacin
reorganizada y el acta de proyecto corregida.
13/11/2008
150

Versin 2.0
FECHA 13/11/2008

i)
ASISTENTES
Grupo 507:

Ctedra de Proyecto:

Salem, Gabriela

Revisar las correcciones realizadas
iii) TEMAS TRATADOS
iv) PRXIMOS PASOS
planificada:
Corregir
Corregir
Corregir
Corregir
v)
las responsabilidades de la matriz de asociacin de Roles con Entregables.

los Casos de Uso.
el Anlisis de Riesgos y realizar una matriz de asociacin.
la fecha del Anlisis de Factibilidad en la planificacin del proyecto.
PRXIMA REUNIN
Se planific para ser realizada el da Viernes 06 de Junio de 2008
Se entregar el Anlisis de los Riesgos corregido, la matriz de Roles-Entregables
corregida, la correccin de los casos de uso y la factibilidad econmica.
13/11/2008
151

Versin 2.0
FECHA 13/11/2008

i)
ASISTENTES
Grupo 507:

Ctedra de Proyecto:

Salem, Gabriela

iii) TEMAS TRATADOS
Se han llevado la documentacin entregada en la reunin para ser revisada en detalle y
efectuarnos las correcciones a realizar para la prxima entrega.
iv) PRXIMOS PASOS
planificada:
Corregir la estructura propuesta del equipo para realizar el proyecto y sus roles.
Avanzar con la definicin de los Casos de Uso.
v)
PRXIMA REUNIN
Se planific para ser realizada el da Viernes 20 de Junio de 2008
Se entregar una nueva revisin de los casos de uso, la correccin de la estructura
del proyecto y el avance en la planificacin.
13/11/2008
152

Versin 2.0
FECHA 13/11/2008

i)
ASISTENTES
Grupo 507:

Ctedra de Proyecto:

Salem, Gabriela

iii) TEMAS TRATADOS
iv) PRXIMOS PASOS
planificada:
Enviar por e-mail antes de la prxima reunin el proyecto completo a todos los
tutores del grupo.
Hacer un nico documento por mdulo y no por caso de uso.
Realizar los diagramas de actividad y secuencia en los casos necesarios.
Empezar a realizar la etapa de diseo del proyecto.
Unificar nomenclatura de CU con en Gantt del Project.
En CU104 (ex CU004) borra el titulo en "Curso Normal"
En CU103 (ex CU003) poner que pasa si usuario no desea imprimir el recibo.
En Curso Alternativo mostrar cuando ocurre algn error y tablas sin datos luego de
bsquedas.
En Comentario poner las validaciones de negocio.
En las secciones Breve Descripcin de los casos de uso decir lo que hace solamente,
no hacerlo condicional.
Actualizar las fechas
v)
PRXIMA REUNIN
Se planific para ser realizada el da Viernes 11 de Julio de 2008
Se entregar los documentos de anlisis completo y de diseo, las correcciones de los
errores indicados y el avance en la planificacin.
13/11/2008
153

Versin 2.0
FECHA 13/11/2008

i)
ASISTENTES
Grupo 607:

Ctedra de Proyecto:

Salem, Gabriela

iii) TEMAS TRATADOS
iv) PRXIMOS PASOS
planificada:
En la seccin Referencias de los casos de uso poner si Incluye a o Es incluido por y
que los mismos tengan hipervnculos dentro del documento.
En CU103 corregir la numeracin de la seccin Curso normal.
Corregir el orden de los casos de uso CU104 y CU105.
Corregir el titulo del diagrama de estados de Inscripcin.
Corregir los diagramas de secuencia: no se deben poner respuestas desde la interfaz
al cliente.
v)
PRXIMA REUNIN
Se planific para ser realizada el da Viernes 15 de Agosto de 2008
Se entregar las correcciones del documento, la actualizacin del Gantt y se
informar el avance en cuanto a codificacin y realizacin del video.
13/11/2008
154

Versin 2.0
FECHA 13/11/2008

i)
ASISTENTES
Grupo 607:

Ctedra de Proyecto:

Salem, Gabriela

iii) TEMAS TRATADOS
iv) PRXIMOS PASOS
planificada:
En la seccin Referencias de los casos de uso poner si Incluye a o Es incluido por y
que los mismos tengan hipervnculos dentro del documento.
En CU103 corregir la numeracin de la seccin Curso normal.
Corregir el orden de los casos de uso CU104 y CU105.
Corregir el titulo del diagrama de estados de Inscripcin.
Corregir los diagramas de secuencia: no se deben poner respuestas desde la interfaz
al cliente.
v)
PRXIMA REUNIN
13/11/2008
155

Versin 2.0
FECHA 13/11/2008

i)
ASISTENTES
Grupo 607:

Ctedra de Proyecto:

Salem, Gabriela

iii) TEMAS TRATADOS
iv) PRXIMOS PASOS
planificada:
Agregar a los campos obligatorios una identificacin de dicha propiedad (por ej.: *).
Cambiar el campo de provincias por un combo con las provincias argentinas.
Permitir que se pueda copiar la direccin ingresada en el domicilio del alumno al
padre, madre y tutor/responsable.
Validar que el documento sea numrico.
Limpiar los mensajes en todas las pantallas.
Revisar el tamao de la aplicacin.
v)
PRXIMA REUNIN
13/11/2008
156

Versin 2.0
FECHA 13/11/2008

i)
ASISTENTES
Grupo 607:

Ctedra de Proyecto:
Tomassino, Carlos

Controlar el avance de la programacin del sistema y su uso.
iii) TEMAS TRATADOS
Se revis el avance en la programacin de la aplicacin y se control que las correcciones
realizadas en reuniones anteriores hayan sido efectuadas.
Tambin se definieron los ajustes a realizar y los avances a solicitar para la prxima
entrega.
iv) PRXIMOS PASOS
planificada:
Validar datos de Nacimiento de los padres con los hijos y con el da de hoy.
Permitir en la modificacin de los datos del alumno cambiar el curso y agregar los
datos de la cuenta bancaria en la misma.
Agregar un cartel de confirmacin de eliminacin del alumno antes de darlo de baja
definitivamente. Cuando se seleccionan muchos poner si esta seguro de eliminar
tantos alumnos.
Agregar datos del Tutor/Responsable y hacer que sea obligatorio completar al menos
uno de los tres.
Adaptar la aplicacin para que se vea en toda la pantalla y no que quede fija en
tamao, respetando que pueda seguir siendo usada en 800x600.
Agregar la pantalla de validacin de ingreso al sistema y de los casos de
administracin de seguridad asociados al mismo.
Ver la posibilidad de poner la aplicacin para que sea accedida remotamente por la
ctedra.
v)
PRXIMA REUNIN
Se planific para ser realizada el da Viernes 24 de Octubre de 2008
Se corregirn las observaciones realizadas acerca de la aplicacin y se continuar con
el desarrollo de la aplicacin.
13/11/2008
157

Versin 2.0
FECHA 13/11/2008

i)
ASISTENTES
Grupo 607:

Ctedra de Proyecto:
Tomassino, Carlos
Salem, Gabriela

iii) TEMAS TRATADOS
Se revis el avance en la programacin de la aplicacin y se control que las correcciones
realizadas en reuniones anteriores hayan sido efectuadas.
Tambin se definieron los ajustes a realizar y los avances a solicitar para la prxima
entrega.
Se ha devuelto la correccin de la carpeta con la documentacin presentada al final de la
primera etapa.
iv) PRXIMOS PASOS
planificada:
Arreglar el conteo de cantidad de aceptados por divisin ya que lo traa en 0.
Continuar con el desarrollo del mdulo de cobranzas.
Continuar con el desarrollo del mdulo de situacin va Web.
Ajustar los detalles visuales.
Agregar un men de ayuda a la derecha de la aplicacin.
Ver de presentar las estadsticas de otra forma porque les result confuso.
Ajustar la documentacin para la entrega final.
v)
PRXIMA REUNIN
Se planific para ser realizada el da Viernes 31 de Octubre de 2008.
Se nos informar la fecha de presentacin a travs de un sorteo a realizarse el mismo
da de la reunin.
13/11/2008
158

Versin 2.0
FECHA 13/11/2008
Anexos
13/11/2008
159

Versin 2.0
FECHA 13/11/2008
Presentacin
Comercial
13/11/2008
160

Versin 2.0
13/11/2008
FECHA 13/11/2008
161

Versin 2.0
13/11/2008
FECHA 13/11/2008
162

Versin 2.0
13/11/2008
FECHA 13/11/2008
163

Versin 2.0
13/11/2008
FECHA 13/11/2008
164

Versin 2.0
13/11/2008
FECHA 13/11/2008
165

Versin 2.0
13/11/2008
FECHA 13/11/2008
166

Versin 2.0
13/11/2008
FECHA 13/11/2008
167

Versin 2.0
13/11/2008
FECHA 13/11/2008
168

Versin 2.0
13/11/2008
FECHA 13/11/2008
169

Versin 2.0
13/11/2008
FECHA 13/11/2008
170

Versin 2.0
13/11/2008
FECHA 13/11/2008
171

Versin 2.0
13/11/2008
FECHA 13/11/2008
172

Versin 2.0
FECHA 13/11/2008
Video Publicitario
13/11/2008
173

Versin 2.0
13/11/2008
FECHA 13/11/2008
174

Versin 2.0
13/11/2008
FECHA 13/11/2008
175

Versin 2.0
13/11/2008
FECHA 13/11/2008
176

Versin 2.0
13/11/2008
FECHA 13/11/2008
177

Versin 2.0
13/11/2008
FECHA 13/11/2008
178

Versin 2.0
13/11/2008
FECHA 13/11/2008
179

Versin 2.0
FECHA 13/11/2008
Planificacin
13/11/2008
180

Versin 2.0
13/11/2008
FECHA 13/11/2008
181

Versin 2.0
13/11/2008
FECHA 13/11/2008
182

Versin 2.0
13/11/2008
FECHA 13/11/2008
183

Versin 2.0
13/11/2008
FECHA 13/11/2008
184

Proyecto Siba Ejemplo

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Proyecto Siba Ejemplo

Transféré par

Droits d'auteur :

Formats disponibles

Documentacin

Av. Corrientes 2367 (C1046AAB) C.A.B.A.

Universidad Tecnolgica Nacional

TITULAR DE LA CTEDRA: LIC. CARLOS TOMASSINO

TRABAJO PRCTICO: TP Proyecto Final

TTULO PROYECTO: SIBA - Informatizacin del Instituto Buenos Aires

Castro, Gabriel Edgardo

Ser Uteniano Consulting

1.0 Creacin del documento unificado

1.1 Correcciones de las secciones Referencia de

Correccin del orden del CU104 y CU105.

2.0 Actualizacin general.

Ser Uteniano Consulting

Ser Uteniano Consulting

Ser Uteniano Consulting

Diagramas de Secuencia .....................................................................................................................83

DISEO ........................................................................................................................................ 101

Ser Uteniano Consulting

Conceptos transversales ................................................................................................................. 120

INFORMES DE AVANCE ........................................................................................................... 138

MINUTAS DE REUNIN ............................................................................................................ 149

ANEXOS ....................................................................................................................................... 159

Ser Uteniano Consulting

Ser Uteniano Consulting

Ser Uteniano Consulting

Objetivo del Proyecto

Ser Uteniano Consulting

Descripcin de la situacin actual

Ser Uteniano Consulting

Descripcin de la solucin propuesta

Vista General del Proyecto

Ser Uteniano Consulting

Resultados de Cada Etapa

Ser Uteniano Consulting

Se usarn herramientas Open Source para el desarrollo.

Tiempo estimado de Implementacin

Ser Uteniano Consulting

Ser Uteniano Consulting

Objetivo del Trabajo

Objetivo del Proyecto

Ser Uteniano Consulting

Vista General del Proyecto

Resultados de Cada Fase

Ser Uteniano Consulting

Ser Uteniano Consulting

Puesto de trabajo estndar

Ser Uteniano Consulting

Definicin de Recursos Humanos

Este Rol es fundamental para

Ser Uteniano Consulting

asegurar un cierto nivel de calidad en el software. Los desarrolladores

En el siguiente esquema se representa la disponibilidad requerida para cada uno

Ser Uteniano Consulting

Matriz de roles y responsabilidades

Ser Uteniano Consulting

Ser Uteniano Consulting

Ser Uteniano Consulting

Identificacin de los Riesgos

Dado que los procesos actuales se encuentran mal documentados o no existe

Dado que le aplicacin ser Web y en el instituto no se utiliza ningn sistema

Dado que el personal del Sector de Administracin del instituto se encuentra

encontremos resistencia al cambio a la hora de realizar la prueba de

Dado que los padres de los alumnos debern utilizar peridicamente el

Como el archivo que genera al sistema para el banco esta totalmente