proyecto siba ejemplo

Av. Corrientes 2367 (C1046AAB) C.A.B.A.(54 11) 4555-5555

[email protected]

DDooccuummeennttaacciióónn

ddeell

PPrrooyyeeccttoo

http://www.seruteniano.com.ar

mailto:[email protected]

Universidad Tecnológica NacionalFacultad Regional Buenos AiresIngeniería en Sistemas de Información

Proyecto

SibaNRO. CURSO

K5051

K5052

K5152

TURNO N

AÑO 2008

TITULAR DE LA CÁTEDRA: LIC. CARLOS TOMASSINO

DOCENTES A CARGO DEL CURSO: LIC. CARLOS TOMASSINO

DOCENTES A CARGO DEL PROYECTO: GONZÁLEZ, MARIA CECILIASALEM, GABRIELASUASNÁBAR, MARIA JULIA

TRABAJO PRÁCTICO: TP Proyecto Final

TÍTULO PROYECTO: SIBA - Informatización del Instituto Buenos Aires

NOMBRE Y APELLIDO LEGAJO N° Curso EMAIL CONTACTO

Castro, Gabriel Edgardo 116815-0 K-5052 [email protected]’Aloia, Martín Miguel 116842-3 K-5052 [email protected]ía Pérez, Jorge Luís 116959-2 K-5051 [email protected]ález Lorenzo, Sebastián Carlos 113199-0 K-5152 [email protected]





13/11/2008 3

Ser Uteniano Consulting

Proyecto: Informatización del IBAVersión 2.0 FECHA 13/11/2008

Historial de RevisiónFecha Versión Descripción Autor

11/07/2008 1.0 Creación del documento unificado Martín D’Aloia

15/08/2008 1.1 Correcciones de las secciones Referencia delos CU.Corrección del orden del CU104 y CU105.Correcciones de los diagramas de secuencia.

Martín D’AloiaGabriel Castro

13/11/2008 2.0 Actualización general. Martín D’Aloia

13/11/2008 4



Índice

ANÁLISIS ........................................................................................................................................ 8ANÁLISIS PRELIMINAR ................................................................................................................................. 9

Resumen Ejecutivo ..............................................................................................................................10Objetivo del Proyecto ...........................................................................................................................10Beneficios de la Informatización .........................................................................................................10Descripción de la situación actual .......................................................................................................11Descripción de la solución propuesta ..................................................................................................12Vista General del Proyecto ..................................................................................................................12Resultados de Cada Etapa ...................................................................................................................13Alcances y Límites ...............................................................................................................................13Tiempo estimado de Implementación ..................................................................................................14

ACTA DE PROYECTO ...................................................................................................................................15

Objetivo del Trabajo ............................................................................................................................16Resumen Ejecutivo ..............................................................................................................................16Objetivo del Proyecto ...........................................................................................................................16Vista General del Proyecto ..................................................................................................................17Resultados de Cada Fase .....................................................................................................................17Alcances y Límites ...............................................................................................................................18Cronograma de Trabajo ......................................................................................................................18Plataforma Tecnológica ......................................................................................................................18Plataforma de desarrollo .....................................................................................................................19Metodologías a utilizar ........................................................................................................................19Definición de Recursos Humanos .......................................................................................................20Estructura propuesta ...........................................................................................................................21

ANÁLISIS DE RIESGOS .................................................................................................................................24

Identificación de los Riesgos ...............................................................................................................25Riesgos técnicos ...............................................................................................................................25Riesgos organizacionales .................................................................................................................25Riesgos externos ...............................................................................................................................25Riesgos de Project Managment .........................................................................................................26

Análisis de los Riesgos.........................................................................................................................27Tabla de Análisis de Riesgos ............................................................................................................27

Mitigación y Contingencia ..................................................................................................................30

ANÁLISIS DE FACTIBILIDAD ........................................................................................................................31

Factibilidad técnica .............................................................................................................................32Factibilidad operativa ..........................................................................................................................32Factibilidad Económica ......................................................................................................................33

Análisis de los Ingresos Afectos a Impuestos .....................................................................................33Análisis de los Egresos Afectos a Impuestos ......................................................................................33Análisis de los Gastos No Desembolsables ........................................................................................36Análisis de los Ingresos No Afectos a Impuestos ...............................................................................38Análisis de los Egresos No Afectos a Impuestos ................................................................................38Flujo de Caja ...................................................................................................................................38Cálculo y Análisis del TIR ................................................................................................................43Cálculo y Análisis del VAN ...............................................................................................................43

ANÁLISIS DE REQUERIMIENTOS ..................................................................................................................44

Módulo de Gestión de Cobranzas ..........................................................................................................45

Descripción del Módulo.......................................................................................................................46Análisis del CU101 – Generar Listado de Débitos ...............................................................................48

Descripción del caso ........................................................................................................................48

13/11/2008 5



Especificación ..................................................................................................................................48Análisis del CU102 – Procesamiento de Resultados de los Débitos ......................................................50

Descripción del caso ........................................................................................................................50Especificación ..................................................................................................................................50

Análisis del CU103 – Clientes sin Cuenta Bancaria ............................................................................52Descripción del caso ........................................................................................................................52Especificación ..................................................................................................................................52

Análisis del CU104 – Generar Reporte de Morosos .............................................................................54Descripción del caso ........................................................................................................................54Especificación ..................................................................................................................................54

Análisis del CU105 – Impresión de Recibos ........................................................................................56Descripción del caso ........................................................................................................................56Especificación ..................................................................................................................................56

Análisis del CU106 – Imprimir Recibo ................................................................................................58Descripción del caso ........................................................................................................................58Especificación ..................................................................................................................................58

Análisis del CU107 – Buscar Clientes con Deudas ..............................................................................59Descripción del caso ........................................................................................................................59Especificación ..................................................................................................................................59

Análisis del CU108 – Generar Archivo Débitos ...................................................................................60Descripción del caso ........................................................................................................................60Especificación ..................................................................................................................................60

Análisis del CU109 – Convertir Archivo de Créditos ...........................................................................61Descripción del caso ........................................................................................................................61Especificación ..................................................................................................................................61

Diagramas de Actividades ...................................................................................................................62Generar Listado de Débitos ..............................................................................................................62

Diagramas de Secuencia .....................................................................................................................63Generar Listado de Débitos ..............................................................................................................63

Diagramas de Estado...........................................................................................................................64Gestión de Débitos ...........................................................................................................................64

Módulo de Situación vía Web ................................................................................................................65

Descripción del Módulo.......................................................................................................................66Análisis del CU201 – Consulta de saldo ..............................................................................................67


Análisis del CU202 – Consulta de Deudas ...........................................................................................69Descripción del caso ........................................................................................................................69Especificación ..................................................................................................................................69

Análisis del CU203 – Impresión Listado Deudas .................................................................................71Descripción del caso ........................................................................................................................71Especificación ..................................................................................................................................71

Diagramas de Actividades ...................................................................................................................72Consulta de deudas ..........................................................................................................................72

Módulo de Inscripción ...........................................................................................................................73

Descripción del Módulo.......................................................................................................................74Análisis del CU301 – Alta de Preinscripción .......................................................................................75


Análisis del CU302 – Administrar preinscripciones.............................................................................78Descripción del caso ........................................................................................................................78Especificación ..................................................................................................................................78

Análisis del CU303 – Consulta de Estado de Preinscripción ...............................................................80Descripción del caso ........................................................................................................................80Especificación ..................................................................................................................................80

Diagramas de Actividades ...................................................................................................................81Administrar Preinscripciones ...........................................................................................................81Alta de Preinscripciones ..................................................................................................................82

13/11/2008 6



Diagramas de Secuencia .....................................................................................................................83Alta de Preinscripción ......................................................................................................................83

Diagramas de Estado...........................................................................................................................84Inscripción .......................................................................................................................................84

Módulo de Administración de Datos .....................................................................................................85

Descripción del Módulo.......................................................................................................................86Análisis del CU401 – Modificación de Datos de Alumnos ...................................................................87


Análisis del CU402 – Baja de Alumnos ...............................................................................................89Descripción del caso ........................................................................................................................89Especificación ..................................................................................................................................89

Diagramas de Actividad.......................................................................................................................91Administración de Alumnos ..............................................................................................................91

Módulo de Administración de Seguridad ..............................................................................................92

Descripción del Módulo.......................................................................................................................93Análisis del CU501 – Administración de Permisos ..............................................................................94


Análisis del CU502 – Administración de Perfiles ................................................................................96Descripción del caso ........................................................................................................................96Especificación ..................................................................................................................................96

Análisis del CU503 – Administración de Usuarios ..............................................................................98Descripción del caso ........................................................................................................................98Especificación ..................................................................................................................................98

Anexos del Análisis ........................................................................................................................... 100Diagramas de Secuencia de Logueo al Sistema ............................................................................... 100

DISEÑO ........................................................................................................................................ 101DISEÑO DEL SISTEMA................................................................................................................................ 102

Diagrama de Dominio ....................................................................................................................... 103Cliente ........................................................................................................................................... 103Cuenta ........................................................................................................................................... 104Inscripción ..................................................................................................................................... 105

Diagrama de Entidad-Relación (DER) .............................................................................................. 106

DISEÑO DE LA ARQUITECTURA ................................................................................................................. 107

Análisis de requerimientos no funcionales y restricciones ................................................................. 108Performance .................................................................................................................................. 108Concurrencia ................................................................................................................................. 108Transaccionalidad.......................................................................................................................... 108Disponibilidad ............................................................................................................................... 108Modificabilidad .............................................................................................................................. 108Seguridad ....................................................................................................................................... 109Testeabilidad.................................................................................................................................. 109Usabilidad ..................................................................................................................................... 109Portabilidad ................................................................................................................................... 110Tiempo ........................................................................................................................................... 110

Priorización de requerimientos no funcionales ................................................................................. 111Arquitectura del sistema .................................................................................................................... 112

Tecnología ..................................................................................................................................... 112Estructura ...................................................................................................................................... 113Capa de presentación ..................................................................................................................... 114Capa de negocio............................................................................................................................. 116Capa de persistencia ...................................................................................................................... 117Diagrama de Componentes............................................................................................................. 118Diagrama de Despliegue ................................................................................................................ 119

13/11/2008 7



Conceptos transversales ................................................................................................................. 120Software Configuration Management (SCM) .................................................................................... 123

Sistema de Control de Versiones ..................................................................................................... 123Herramienta de Software Project Managment................................................................................. 123Herramientas de colaboración ....................................................................................................... 124Code Coverage (Cobertura del código por medio de los Tests) ....................................................... 124Bug Tracking, Issue Tracking y Project Management ...................................................................... 124

Tecnología......................................................................................................................................... 126Normas de codificación ..................................................................................................................... 128Documentación ................................................................................................................................. 129Administración de riesgos arquitecturales ......................................................................................... 130Diagrama del Framework de la Capa de Persistencia ....................................................................... 132

DAOs (Data Access Object)............................................................................................................ 133Diagrama del Framework de la Capa de Presentación ...................................................................... 135

INFORMES DE AVANCE ........................................................................................................... 138Informe de avance al 09/05/2008 ....................................................................................................... 139Informe de avance al 23/05/2008 ....................................................................................................... 140Informe de avance al 06/06/2008 ....................................................................................................... 141Informe de avance al 20/06/2008 ....................................................................................................... 142Informe de avance al 11/07/2008 ....................................................................................................... 143Informe de avance al 15/08/2008 ....................................................................................................... 144Informe de avance al 26/09/2008 ....................................................................................................... 145Informe de avance al 10/10/2008 ....................................................................................................... 146Informe de avance al 24/10/2008 ....................................................................................................... 147Informe de avance al 28/11/2008 ....................................................................................................... 148

MINUTAS DE REUNIÓN ............................................................................................................ 149Minuta de reunión del día 09/05/2008 ............................................................................................... 150Minuta de reunión del día 23/05/2008 ............................................................................................... 151Minuta de reunión del día 06/06/2008 ............................................................................................... 152Minuta de reunión del día 20/06/2008 ............................................................................................... 153Minuta de reunión del día 11/07/2008 ............................................................................................... 154Minuta de reunión del día 15/08/2008 ............................................................................................... 155Minuta de reunión del día 26/09/2008 ............................................................................................... 156Minuta de reunión del día 10/10/2008 ............................................................................................... 157Minuta de reunión del día 24/10/2008 ............................................................................................... 158

ANEXOS ....................................................................................................................................... 159PRESENTACIÓN COMERCIAL..................................................................................................................... 160

VIDEO PUBLICITARIO ............................................................................................................................... 173

PLANIFICACIÓN ........................................................................................................................................ 180

13/11/2008 8



Análisis

13/11/2008 9



Análisis Preliminar

13/11/2008 10



Resumen EjecutivoA partir de la motivación por parte del sector Directivo del Instituto surge la

necesidad de comenzar un proceso de informatización atacando los sectores más críticos

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 electrónica) 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. También, al ser un proceso automatizado, se reducirán los errores humanos

generados en el proceso.

Paralelamente se plantea también la realización de un módulo de preinscripciones

que permitirá administrar con mayor eficiencia las mismas.

Objetivo del ProyectoManejar la información de los clientes referida al cobro de cuotas, generando el

archivo necesario para la entidad bancaria que maneja los debitos, estandarizando el

archivo según las normas vigentes del banco.

Permitir imprimir los recibos de los clientes una vez recibida la respuesta del banco,

así como también las notificaciones de falta de pago correspondientes.

Realizar la gestión 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

también informando a los morosos de su situación.

Suministrar información de los saldos adeudados y/o a pagar de los clientes de

manera Web.

Tener un modulo anexo que permita realizar la preinscripción de los alumnos al

ciclo lectivo próximo, facilitando el tramite a los alumnos que cursan actualmente.

Beneficios de la InformatizaciónEntre las principales ventajas de implementar la informatización del sistema de

cobros y de inscripciones se pueden destacar las siguientes:

Automatización de la generación 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 11



Reducir los errores generados por el procesamiento manual de la

información

Permitir a los clientes consultar el estado del último pago y los historiales vía

Web

Realizar electrónicamente la preinscripción de los alumnos, reduciendo

tiempos y papelerio

Administrar las preinscripciones recibidas electrónicamente

Informatización de los datos de los clientes

Posibilidad a futuro para agregar nuevos módulos al sistema

Descripción de la situación actualEl Instituto Buenos Aires es una institución de nivel secundario situada en el Partido

de Almirante Brown. Actualmente posee alrededor de 330 alumnos.

La problemática principal que presenta es la ausencia de automatización del circuito

de cobro.

Hace dos años comenzó a realizar cobros de sus cuotas mediante débitos

bancarios. Para esto se completa una planilla de cálculo que mediante un script genera

un archivo con el formato que necesita el banco y se le envía por email. Luego de cada

fecha de cobro, el banco envía una respuesta indicando a quién se les pudo debitar la

cuota y a quién no.

Esto parece sencillo y es así porque la problemática está en generar el listado de

cobro y asentar los pagos en un cuaderno que contiene toda la información al respecto.

Luego de esto, como la información 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 días de una persona dedicada especialmente a la

misma. Además de esto se agrega un costo de imagen en el caso de cometer errores,

cosa muy común en un sistema manual y que ha pasado varias veces, ya que el dinero

es un tema sensible.

13/11/2008 12



Descripción de la solución propuestaRealizar un sistema que principalmente mantenga la información de las cuentas de

los alumnos. A esto se le agregaría un módulo que genere automáticamente la lista de

cobros con el formato establecido por el banco para que éste pueda ser enviado vía e-

mail 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 opción de imprimir los recibos generados automáticamente, así como también las

notificaciones de falta de pago. También permitirá consultar por Web a los clientes el

saldo que debe pagar y, en caso de que exista, la deuda que posea.

Se confeccionará también un módulo que permitirá realizar la gestión 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 módulo proporcionara a los

clientes, que por la razón 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 información de cobros

centralizada.

Además incluirá un módulo que permita realizar la preinscripción de los alumnos vía

Web. Sin la necesidad de concurrir en diciembre a la escuela para reservar la vacante

como se hace actualmente. Esto facilitará la digitalización de los datos. Éste módulo

servirá para los alumnos nuevos y los alumnos que concurren al establecimiento dándole

prioridad a éstos últimos.

El sistema será con interfaz Web y permitirá, según la persona que ingrese,

(cliente, profesor, administrador, etc.) brindar para cada uno de ellos las funcionalidades

anteriormente detalladas.

Vista General del ProyectoSe ha planteado dividir el proyecto en 2 fases.

En la primera fase se realizará el análisis del sistema y el entorno y con ello se

generará el diseño propuesto para cumplir con los requerimientos solicitados. Además se

13/11/2008 13



realizará una exposición para mostrar la solución propuesta. Esta fase está planificada

para ser terminada a principios de Julio de 2008.

En la segunda fase se realizará la codificación del sistema, se realizarán las pruebas

de integración necesarias y finalmente se pasará a producción. Esta fase está planificada

para ser terminada a fines de Noviembre de 2008.

Resultados de Cada EtapaAl 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í también 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 tendrán una serie de entregables que verificarán

las tareas desarrolladas.

Alcances y LímitesSe proveerá de los recursos humanos para el análisis, diseño, desarrollo e

implementación del sistema.

Se realizará una interfaz gráfica básica apropiada para correcta operación 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 módulo 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 módulo que permita ingresar al sistema los pagos de los clientes

que abonan en efectivo en el establecimiento.

Se desarrollará el módulo que permita a los clientes consultar vía Web el saldo

deudor y el saldo a pagar de la próxima cuota.

Se desarrollará el módulo que permita realizar una preinscripción Web de los

alumnos.

Se creará la base de datos necesaria para desarrollar el sistema.

El desarrollo del producto se realizará específicamente para cubrir las necesidades

del Instituto Buenos Aires.

13/11/2008 14



Se usarán herramientas Open Source para el desarrollo.

No se proporcionará personal para el mantenimiento del sistema posterior a la

implementación.

No se proporcionará hardware de ningún tipo para la implementación del sistema.

Aclaración: Si bien, esta etapa no contemplará el desarrollo de nuevos productos,

en caso que surgiera un producto que fuese considerado estratégico como para

adicionarlo al proyecto, será necesario analizarlo y plantearlo como Cambio de Alcance

en el Proyecto.

Tiempo estimado de ImplementaciónEl 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 días de Abril del

2008.

13/11/2008 15



Acta de Proyecto

13/11/2008 16



Objetivo del TrabajoEste documento tiene como objetivo principal presentar una propuesta Técnica y

Operativa, acompañada del Plan de Proyecto, que tenga como eje principal la

implementación de un nuevo software que integra el manejo de cuotas e inscripciones de

alumnos del Instituto Buenos Aires.

Resumen EjecutivoA partir de la inquietud por mejorar la operatoria de cobranza de cuotas y la

interacción entre el los alumnos y el instituto, se planteó como objetivo elaborar una

propuesta Técnica y Operativa, acompañada del Plan de Proyecto correspondiente y para

ello, se realizaron un conjunto de actividades claves que se detallan a continuación:

1. Se definieron los objetivos de la solución

2. Se definió el alcance del proyecto y sus componentes

3. Se analizó la plataforma tecnológica.

4. Se analizó la factibilidad técnica y operativa.

Entre las características más significativas encontradas, podemos mencionar:

1. Como resultado del relevamiento se detectó deficiencia en el manejo de la

información, 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 características y de las actividades desarrolladas, arribamos a la

siguiente conclusión:

La solución se realizará en dos fases, comenzado por el análisis de las operaciones

y finalizando con la codificación e implementación. La misma, además de cubrir los

objetivos actuales, contemplará la futura integraron de otros sistemas (Arquitectura

Empresarial).

Objetivo del ProyectoManejar la información 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 débitos,

13/11/2008 17



estandarizando el archivo según 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 también visualizar las notificaciones de falta de pago correspondientes.

Permitir ingresar clientes al sistema, así como también sus pagos, antes de poseer

una cuenta bancaria para poder mantener sincronizado el estado de morosidad de los

mismos.

Suministrar información de los saldos adeudados y/o a pagar de los clientes de

manera Web.

Tener un modulo anexo que permita realizar la preinscripción de los alumnos al

ciclo lectivo próximo, facilitando el tramite a los alumnos que cursan actualmente.

Vista General del ProyectoSe ha planteado dividir el proyecto en 2 fases.

En la primera fase se realizará el análisis del sistema y el entorno y con ello se

generará el diseño propuesto para cumplir con los requerimientos solicitados. Además se

realizará una exposición para mostrar la solución propuesta. Esta fase está planificada

para ser terminada a principios de Julio de 2008.

En la segunda fase se realizará la codificación del sistema, se realizarán las pruebas

de integración necesarias y finalmente se pasará a producción. Esta fase está planificada

para ser terminada a mediados de Noviembre de 2008.

Resultados de Cada FaseAl 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í también 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 tendrán una serie de entregables que verificarán

las tareas desarrolladas.

13/11/2008 18



Alcances y LímitesSe proveerá de los recursos humanos para el análisis, diseño, desarrollo e

implementación del sistema.

Se realizará una interfaz gráfica básica apropiada para correcta operación 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 módulo 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 módulo que permita ingresar al sistema los pagos de los clientes

que abonan en efectivo en el establecimiento.

Se desarrollará el módulo que permita a los clientes consultar vía Web el saldo

deudor y el saldo a pagar de la próxima cuota.

Se desarrollará el módulo que permita realizar una preinscripción Web de los

alumnos.

Se creará la base de datos necesaria para desarrollar el sistema.

El desarrollo del producto se realizará específicamente para cubrir las necesidades

del Instituto Buenos Aires.

Se usarán herramientas Open Source para el desarrollo.

No se proporcionará personal para el mantenimiento del sistema posterior a la

implementación.

No se proporcionará hardware de ningún tipo para la implementación del sistema.

Cronograma de TrabajoPara el desarrollo del Proyecto se elaboró un plan de trabajo y un cronograma que

se adjunta como Anexo de este proyecto.

Plataforma TecnológicaComo resultado de un análisis preliminar hemos constatado que la disponibilidad de

equipos del instituto es adecuada para la implementación del sistema, por lo que no será

necesario la compra de nuevo hardware. Se utilizarán los siguientes equipos:

13/11/2008 19



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. Conexión a Internet

Puesto de trabajo estándar

1. Cualquier equipo que soporte la ejecución de Firefox 2 o superior.

2. Conexión al Sitio Central por medio de red local o Internet.

Plataforma de desarrolloRespecto de las herramientas a usar para el desarrollo del software asociado al

sistema en cuestión se utilizará lenguaje Java, bases de datos MySQL, Hibernate como

puente entre objetos y bases de datos relacionales, GWT para presentación Web, Tomcat

como Servlet Container, Maven como herramienta para la gestión del proyecto de

software, SVN como repositorio para el control de versiones y Eclipse como IDE.

Aclaración: Cabe aclarar que una vez comenzada la Fase de “Desarrollo e

Implementación” del proyecto se efectuará nuevamente el análisis 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 tecnología de punta.

Metodologías a utilizarPara 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 análisis, diseño y desarrollo de

la solución y una parte del estándar UML (y de ser necesario se introducirán pequeños

cambios que ayuden a clarificar y transmitir mejor las ideas) como lenguaje de

documentación.

13/11/2008 20



Definición de Recursos HumanosUn punto muy importante a tener en cuenta, y que puede resultar clave para llevar

a cabo el proyecto de manera exitosa, es la organización del equipo de desarrollo; es

decir que roles, responsabilidades y/o actividades llevarán adelante los integrantes del

equipo.

Si bien, en principio, cada integrante va a asumir un rol en particular, los mismos

son dinámicos y esto quiere decir que, por ejemplo, en determinada situación un Analista

Programador puede realizar actividades propias de un Analista Funcional y viceversa. La

idea es que los roles no sean fijos ni estáticos, 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. Líder de ProyectoEl líder 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 líder de proyecto tiene la responsabilidad principal de proporcionar

liderazgo en la planificación y organización del equipo de trabajo.

2. Líder TécnicoEs el referente de la tecnología a utilizar y será el encargado de armar la

arquitectura del sistema y guiar el desarrollo del mismo.

3. Analista ProgramadorLa labor fundamental de este será la de definir y documentar los

requerimientos del sistema, especificar cómo implementar la solución y

programarlo. Se necesitaran 2 (dos) puestos de trabajo para este rol.

4. Analista FuncionalSu principal aporte esta centrado en definir qué debe realizar el sistema a

nivel funcional. Este rol coordinará a los Analistas Programadotes.

5. TestersSe encargarán de asegurar que el sistema realice lo que figura en las

especificaciones y reportar las conclusiones. Este Rol es fundamental para

13/11/2008 21



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

mencionados arriba llevarán a cabo esta tarea.

6. Data EntrySe 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 UserDado que el desarrollo del sistema es “a medida”, este rol es fundamental

para validar los diseños funcionales del sistema. Aportando información

necesaria del negocio. La interacción continua con esta persona será vital para el

éxito del proyecto. También 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 implementación serán: ejecutar las tareas antes

detalladas, informar avances, analizar desvíos, subsanar imprevistos, implementar y

documentar.

Por último, la participación (inicialmente parcial) del Sponsor será el nexo entre el

instituto y el líder 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 22



EtapaRecurso Análisis Diseño Desarrollo Testing

Líder de proyectoSponsorKey UserLíder técnicoAnalista FuncionalProgramadorTesterData-Entry

Matriz de roles y responsabilidades

Líder deproyecto

Sponsor KeyUser

Lídertécnico

AnalistaFuncional

Tester Programador DataEntry

Documento deAnálisisPreliminar

Aprueba Aprueba Participa Realiza

Documento deActa deProyecto

Aprueba Aprueba Participa Realiza

Documento deAnálisis deRiesgo

Lidera Aprueba Realiza

Documento deFactibilidad

Lidera Aprueba Realiza

Documento deAnálisis deFuncionalidades

Revisa Aprueba Realiza

Documento deDiseño delSistema

Revisa Aprueba Participa

Documento deDiseño de laArquitectura

Revisa Aprueba Participa

Documento delaFuncionalidadGenerar Listadode Débitos parael Banco


Documento delaFuncionalidadProcesamientode Resultadosde los Débitos


Documento delaFuncionalidadClientes sinCuentaBancaria


Documento delaFuncionalidadGeneración deReporte de


13/11/2008 23



Líder deproyecto

Sponsor KeyUser

Lídertécnico

AnalistaFuncional

Tester Programador DataEntry

MorososDocumentoFuncionalidadImpresión deRecibos


DocumentoFuncionalidadConsulta deSaldo a Pagar


DocumentoFuncionalidadConsulta deDeudas


DocumentoFuncionalidadAlta dePreinscripción


DocumentoFuncionalidadAdministradordePreinscripción


DocumentoFuncionalidadABM Datos deAlumnos


Documento deDiseño

Aprueba Revisa Realiza

Librería deInterfazsimulada


Desarrollo decadafuncionalidad

Aprueba Valida Lidera Participa Participa Participa Participa

Documentacióndel desarrollo

Aprueba Valida Lidera Participa Participa Participa

Presentaciónfinal

Aprueba Aprueba Aprueba Participa Participa Participa Participa

13/11/2008 24



Análisis de Riesgos

13/11/2008 25



Identificación de los RiesgosLos riesgos que identificamos y que eventualmente pueden impactar en el proyecto

son los que se detallan a continuación, se encuentran separados en cuatro categorías

riesgos técnicos, riesgos organizacionales, riesgos externos y riesgos de Project

Managment:

Riesgos técnicos1. Dado que los procesos actuales se encuentran mal documentados o no existe

una documentación formal que los avale, posiblemente el sistema cuente con

circuitos mal especificados.

2. Dado que le aplicación será Web y en el instituto no se utiliza ningún sistema

Web para su operatoria actual, pude existir la posibilidad que la conexión a

Internet no sea la adecuada.

Riesgos organizacionales3. Dado que el personal del Sector de Administración del instituto se encuentra

habituado a realizar la operatoria de forma manual, posiblemente

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

aceptación por parte del usuario.

4. Dado que los padres de los alumnos deberán utilizar periódicamente el

sistema para la consulta de los saldos, posiblemente percibamos una

resistencia de parte de algunos padres que no estén acostumbrados a operara

a través de aplicaciones Web.

Riesgos externos5. Como el archivo que genera al sistema para el banco esta totalmente

adaptado al estándar del mismo, si el banco decide cambiarlo quedará

inutilizado el módulo que genera el archivo.

6. Renuncia de personal del instituto, como por ejemplo el Key User, que es la

persona que más conoce los procesos que el equipo necesita relevar para el

desarrollo del sistema.

13/11/2008 26



Riesgos de Project Managment7. Solicitud de una ampliación de la funcionalidad acordada en un comienzo del

proyecto por parte del cliente.

8. Estimación no tan exactas ya que en momento de realizarla no se cuenta con

toda la información necesaria del proyecto y la persona encargada no cuenta

con experiencia en esta tarea.

13/11/2008 27



Análisis de los Riesgos

Tabla de Análisis de Riesgos

ID Prioridad Descripción Probabilidadde

ocurrencia

Impacto Exposición

1 Alta Procesos no documentados Media Alto Media2 Media Conexión insuficiente Media Alto Media3 Alta Resistencia al cambio por

usuarios internosAlta Muy Alto Media

4 Alta Resistencia al cambio porusuarios externos

Media Medio Baja

5 Media Cambio de especificación delBanco

Baja Muy Alto Media

6 Baja Desvinculación de RRHH Media Medio Baja7 Baja Ampliación de funcionalidad Media Medio Baja8 Alta Mala estimación Media Alto Media

A continuación se expone el análisis 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 administración del instituto.

o Condición: Los procesos que se deben modelizar no se encuentran

documentados como corresponde.

o Consecuencia: Se atrasaría la etapa de extracción de requerimientos

al usuario.

o Clasificación del Impacto: Administrativo.

Riesgo 02: Conexión de Internet insuficiente.

o Fuente: El instituto.

o Condición: La conexión de Internet contratada actualmente no brinda

el ancho de banda necesario para la normal operatoria del sistema.

o Consecuencia: El sistema no funcionaria correctamente una vez

puesto en marcha.

o Clasificación del Impacto: Estratégico.

13/11/2008 28



Riesgo 03: Resistencia al cambio por parte del usuario final interno al

Instituto.

o Fuente: El sector de administración del instituto.

o Condición: Un usuario del instituto no puede adaptarse al nuevo

sistema.

o Consecuencia: El usuario se resistirá a usar el nuevo sistema.

o Clasificación del Impacto: Estratégico, Administrativo.

Riesgo 04: Resistencia al cambio por parte de los usuarios finales externos al

Instituto.

o Fuente: Los padres de los alumnos del instituto.

o Condición: Un padre de un alumno se resiste al uso de la nueva

interfaz externa del sistema.

o Consecuencia: El usuario se resistirá a usar el nuevo sistema.


Riesgo 05: Cambio de la especificación del estándar del banco.

o Fuente: El banco receptor de depósitos de los clientes.

o Condición: El banco cambia el formato de entrada del archivo.

o Consecuencia: El archivo generado por el sistema no servirá para

corresponder con el nuevo estándar.


Riesgo 06: Renuncia de personal del instituto.

o Fuente: Personal del instituto.

o Condición: La renuncia de personal del instituto que nos debía

proporcionar la información necesaria para el desarrollo del sistema o

que debía realizar el testing del sistema.

o Consecuencia: Se atrasaría la etapa de extracción de requerimientos

al usuario o la etapa de testing, dependiendo de la etapa en la que se

encuentre el proyecto.


Riesgo 07: Ampliación de las funcionalidades solicitadas por el cliente.

o Fuente: El cliente del sistema.

o Condición: El cliente solicita una funcionalidad que no estaba

acordada que realice el sistema.

13/11/2008 29



o Consecuencia: Se retrasara el cronograma del proyecto.

o Clasificación del Impacto: Estratégico.

Riesgo 08: Mala estimación.

o Fuente: Líder de proyecto.

o Condición: La mala estimación de tiempo y recurso al momento de

calendarizar el proyecto.

o Consecuencia: Se atrasaría la puesta en marcha del nuevo sistema.


13/11/2008 30



Mitigación y ContingenciaPara cada uno de los riesgos analizados se definieron los siguientes planes de

acción:

1. Se contará con el apoyo del personal de mayor cargo dentro del instituto que

nos brindará apoyo, toda la documentación 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 decisión 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 capacitación para los empleados de las áreas

de administración 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 capacitación y difusión 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 evaluación 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 estimación y se le brindara la

mayor cantidad de información para reducir la probabilidad de ocurrencia.

13/11/2008 31



Análisis deFactibilidad

13/11/2008 32



Factibilidad técnicaLuego de haber analizado la situación tecnológica 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 Tecnológica” y “Plataforma de

Desarrollo” cumplen los requisitos necesarios y posibilitan el desarrollo conveniente del

proyecto.

También podemos destacar que actualmente es muy sencillo conseguir en el

mercado muy buenos recursos humanos capacitados técnicamente 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 ningún equipo especial. Con una PC de escritorio estándar

(microprocesador Pentium IV de 3.0 Ghz, 1 Gb de RAM y disco rígido de 80 Gb.) el

sistema puede operar y ser desarrollado sin presentar problema alguno.

Factibilidad operativaActualmente no existe ningún software que cumpla con las necesidades del

instituto. Es por este motivo que la realización de este proyecto es deseado fuertemente

por el sector directivo y el personal del instituto dado que supone una mejora en los

métodos de trabajo y una consecuente reducción de tiempos y errores humanos.

Así también permitirá continuar con la informatización de los procesos del instituto

a futuro permitiéndose que sea integrado al sistema a desarrollar como nuevos módulos.

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 más en el

conocimiento de las facilidades que posee el sistema.

Por los motivos enunciados anteriormente, el proyecto será altamente factible

operativamente.

13/11/2008 33



Factibilidad Económica

Análisis de los Ingresos Afectos a ImpuestosEn 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

continuación.

Ingresos por Nuevos Alumnos

C0 C1 C2 C3Nuevos Alumnos

Ingresos por Nuevos Alumnos -$ 240,000.00$ 288,000.00$ 360,000.00$Subtotal Nuevos Alumnos: -$ 240,000.00$ 288,000.00$ 360,000.00$

Total de Ingresos Afectos a Impuestos: -$ 240,000.00$ 288,000.00$ 360,000.00$

Ingresos Afectos a Impuestos Por Período [$]Concepto

Ingresos por Ahorros

C1 C2 C3Reducción de Costos

Costos de los Procesos 24,000.00$ 28,320.00$ 29,166.72$Subtotal Reducción de Costos: 24,000.00$ 28,320.00$ 29,166.72$

Totales: 24,000.00$ 28,320.00$ 29,166.72$

Concepto Ahorro Neto Por Período [$]

Análisis de los Egresos Afectos a ImpuestosDentro de éste rubro podemos encontrar los gastos que tiene el instituto por tener

que pagar los honorarios de las personas que llevarán adelante el proyecto, los

honorarios de las personas que en los próximos tres años usarán el nuevo sistema y los

costos fijos que tendrá a lo largo de la vida útil del nuevo sistema.

Una aclaración importante es que para el cálculo de los sueldos no se ha tenido en

cuenta el índice de inflación, ya que resulta muy difícil establecer realmente cuál es

realmente dicho índice, y más cómo se comportará de acá a tres años. Con lo cual su

inclusión solo hubiera generado una evaluación con un grado mayor de incertidumbre.

A continuación se presenta un cuadro con el resumen anual, y en las siguientes

sub-secciones se podrá encontrar el detalle de cada período.

13/11/2008 34



C0 C1 C2 C3Sueldos del Personal del Proyecto

Líder de Proyecto 27,000.00$ -$ -$ -$Analista Funcional (SemiSenior) 18,000.00$ -$ -$ -$Desarrollador (SemiSenior) 45,000.00$ -$ -$ -$Técnico en Redes 12,000.00$ -$ -$ -$

Subtotal Sueldos del Personal del Proyecto: 102,000.00$ -$ -$ -$Sueldos del Personal del Instituto

Director -$ 60,000.00$ 60,000.00$ 60,000.00$Vice Director -$ 54,000.00$ 54,000.00$ 54,000.00$Personal Operativo de Cobros -$ 72,000.00$ 72,000.00$ 72,000.00$

Subtotal Sueldos del Personal del Instituto: -$ 186,000.00$ 186,000.00$ 186,000.00$Total de Sueldos del Personal: 102,000.00$ 186,000.00$ 186,000.00$ 186,000.00$

Sueldos del Personal Por Período [$]Concepto

Sueldos del Personal del Proyecto

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.

Hs./Hombre Total Hs. Sueldo Mes TotalSueldos del Personal del Proyecto

Líder de Proyecto 1 28.13$ 960 4,500.00$ 27,000.00$Analista Funcional (SemiSenior) 1 18.75$ 960 3,000.00$ 18,000.00$Desarrollador (SemiSenior) 3 15.63$ 960 2,500.00$ 45,000.00$Técnico en Redes 1 12.50$ 960 2,000.00$ 12,000.00$

Subtotal Sueldos del Personal del Proyecto: 75.00$ 3840 12,000.00$ 102,000.00$Sueldos del Personal del Instituto

Director 0 -$ 0 -$ -$Vice Director 0 -$ 0 -$ -$Personal Operativo de Cobros 0 -$ 0 -$ -$

Subtotal Sueldos del Personal del Instituto: -$ -$ -$Total de Sueldos del Personal: 75.00$ 12,000.00$ 102,000.00$

Cant.Concepto Costo Sueldo [$]

Periodo C0

Sueldos del Personal de CobrosEn éste cuadro se pueden apreciar los costos asociados a tener que pagar los

sueldos de las personas que emplearán el nuevo sistema a partir de la puesta en

producción.

13/11/2008 35



Hs./Hombre Total Hs. Sueldo Mes TotalSueldos del Personal del Instituto

Director 1 31.25$ 1920 5,000.00$ 60,000.00$Vice Director 1 28.13$ 1920 4,500.00$ 54,000.00$Personal Operativo de Cobros 2 18.75$ 1920 3,000.00$ 72,000.00$

Subtotal Sueldos del Personal del Instituto: 78.13$ 12,500.00$ 186,000.00$Total de Sueldos del Personal: 78.13$ 12,500.00$ 186,000.00$

Costo Sueldo [$]ConceptoCant.

Periodo C1




ConceptoPeriodo C2

Cant. Costo Sueldo [$]




Periodo C3

Cant. Costo Sueldo [$]Concepto

Costos FijosEn éste cuadro se pueden apreciar los costos fijos anuales asociados a tener

operativa la nueva solución.

C0 C1 C2 C3Mantenimiento General

Mantenimiento del Software -$ 12,000.00$ 12,000.00$ 12,000.00$Mantenimiento del Hardware -$ 7,200.00$ 7,200.00$ 7,200.00$

Subtotal Mantenimiento General: -$ 19,200.00$ 19,200.00$ 19,200.00$Insumos

Insumos para PCs -$ 13,200.00$ 15,180.00$ 17,460.00$Subtotal Insumos: -$ 13,200.00$ 15,180.00$ 17,460.00$

Comunicación y ConexiónTelefonía + Banda Ancha -$ 9,600.00$ 9,600.00$ 9,600.00$

Subtotal Comunicación y Conexión: -$ 9,600.00$ 9,600.00$ 9,600.00$Total de Costos Fijos: -$ 42,000.00$ 43,980.00$ 46,260.00$

Costos Fijos Por Período [$]Concepto

El detalle de cómo llegar a los números 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 36



Individual Mensual AnualMantenimiento General

Mantenimiento del Software 1 1,000.00$ 1,000.00$ 12,000.00$Mantenimiento del Hardware 1 600.00$ 600.00$ 7,200.00$

Subtotal Mantenimiento General: 1,600.00$ 1,600.00$ 19,200.00$Insumos

Insumos para PCs 1 1,100.00$ 1,100.00$ 13,200.00$Subtotal Insumos: 1,100.00$ 1,100.00$ 13,200.00$

Comunicación y ConexiónTelefonía + Banda Ancha 1 800.00$ 800.00$ 9,600.00$

Subtotal Comunicación y Conexión: 800.00$ 800.00$ 9,600.00$Total de Costos Fijos: 3,500.00$ 3,500.00$ 42,000.00$

Costo Fijo [$]ConceptoCantidad

Periodo C1







ConceptoPeriodo C2

Cantidad Costo Fijo [$]







Periodo C3

Cantidad Costo Fijo [$]Concepto

Análisis de los Gastos No DesembolsablesDentro de los Gastos No Desembolsables analizaremos aquellos generados por los

Bienes de Uso adquiridos como inversión para el proyecto.

A continuación 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 37



depreciaciones de cada uno de éstos bienes y el Valor Contable de cada bien en el último

período de vida del proyecto.

Costos de los Bienes de Uso

Concepto Cantidad Valor Unitario[$]

Valor Total[$]

Hardware de PCWorkstation (Dell Vostro 200 Slim Tower) 4 1,600.00$ 6,400.00$Monitor (Dell 1708FP) 4 1,200.00$ 4,800.00$Servidor (Dell PowerEdge 1900) 1 5,500.00$ 5,500.00$Impresora (HP Color LaserJet CM1015 MFP) 2 1,500.00$ 3,000.00$

9,800.00$ 19,700.00$Intranet

Router Linksys 1 300.00$ 300.00$Bocas de Red 10/100 4 10.00$ 40.00$Cableado UTP-5 100 0.90$ 90.00$

310.90$ 430.00$Mobiliario de Oficina

Escritorio de PC P/ Oficina 4 250.00$ 1,000.00$Escritorio P/ Impresoras 2 150.00$ 300.00$

400.00$ 1,300.00$Licencias de Sofware

Microsoft Windows XP SP2 Professional Edition 4 450.00$ 1,800.00$Microsoft Office 2003 Professional Edition 4 600.00$ 2,400.00$

1,050.00$ 4,200.00$11,560.90$ 25,630.00$

Subtotal Hardware de PC:

Subtotal Intranet:

Total Bienes de Uso:

Subtotal Mobiliario de Oficina:

Subtotal Licencias de Sofware:

Depreciaciones de los Bienes de Uso

Hardware de PCWorkstation (Dell Vostro 200 Slim Tower) 6,400.00$ 3 2,133.33$ 6,400.00$ -$Monitor (Dell 1708FP) 4,800.00$ 3 1,600.00$ 4,800.00$ -$Servidor (Dell PowerEdge 1900) 5,500.00$ 3 1,833.33$ 5,500.00$ -$Impresora (HP Color LaserJet CM1015 MFP) 3,000.00$ 3 1,000.00$ 3,000.00$ -$

Subtotal Hardware de PC: 19,700.00$ 6,566.67$ 19,700.00$ -$Intranet

Router Linksys 300.00$ 5 60.00$ 180.00$ 120.00$Bocas de Red 10/100 40.00$ 5 8.00$ 24.00$ 16.00$Cableado UTP-5 90.00$ 5 18.00$ 54.00$ 36.00$

Subtotal Intranet: 430.00$ 86.00$ 258.00$ 172.00$Mobiliario de Oficina

Escritorio de PC P/ Oficina 1,000.00$ 10 100.00$ 300.00$ 700.00$Escritorio P/ Impresoras 300.00$ 10 30.00$ 90.00$ 210.00$

Subtotal Mobiliario de Oficina: 1,300.00$ 100.00$ 300.00$ 700.00$Licencias de Sofware

Microsoft Windows XP SP2 Professional Edition 1,800.00$ 3 600.00$ 1,800.00$ -$Microsoft Office 2003 Professional Edition 2,400.00$ 3 800.00$ 2,400.00$ -$

Subtotal Licencias de Sofware: 4,200.00$ 1,400.00$ 4,200.00$ -$Total Depreciaciones: 25,630.00$ 8,152.67$ 24,458.00$ 872.00$

ValorContable

[$]Concepto

DepreciaciónTotal

[$]

DepreciaciónAnual

[$]

VidaÚtil

[Años]

Valor Total[$]

13/11/2008 38



Análisis de los Ingresos No Afectos a ImpuestosEl único ítem que queda abarcado bajo éste concepto es el préstamo que deberá

pedir el Instituto Buenos Aires para llevar adelante el proyecto.

Detalle del Préstamo

Principal dela Deuda

Plazo dePago

Tasa deInterés

Préstamo 30,000.00$ 3 8%

ConceptoDatos del Préstamo

Período Saldo dela Deuda

CuotaAmortizada

InteresAmortizado

CapitalAmortizado

01 30,000.00$ (11,641.01)$ (2,400.00)$ (9,241.01)$2 20,758.99$ (11,641.01)$ (1,660.72)$ (9,980.29)$3 10,778.71$ (11,641.01)$ (862.30)$ (10,778.71)$

Total: 0.00$ (34,923.02)$

Flujo del Préstamo (Método Francés)

Análisis de los Egresos No Afectos a ImpuestosDentro de éste rubro podemos encontrar dos ítems, la amortización del préstamo

pedido al Banco Supervielle y los costos de la inversión inicial del proyecto en Bienes de

Uso.

Amortización del PréstamoEn base al detalle del préstamo pedido, los intereses y el capital amortizado por

período son los que se detallan a continuación.

1 2 3Préstamo (2,400.00)$ (1,660.72)$ (862.30)$

Amortización de Intereses de Préstamos (2,400.00)$ (1,660.72)$ (862.30)$

1 2 3Préstamo (9,241.01)$ (9,980.29)$ (10,778.71)$

Amortización de Capital de Préstamos (9,241.01)$ (9,980.29)$ (10,778.71)$

Concepto Capital Amortizado Por Período [$]

Concepto Intereses Amortizado Por Período [$]

Inversión en Bienes de UsoRemitirse a la sección 0 Costos de los Bienes de Uso.

Flujo de CajaA continuación se presentan los dos flujos de caja pedidos, teniendo y no teniendo

en cuenta el préstamo.

(Ver cuadro en hoja siguiente)

13/11/2008 39



Tomando en Cuenta el Préstamo

C0 C1 C2 C3Año 0 Año 1 Año 2 Año 3

Ingresos Afectos a ImpuestosIngresos

Nuevos Alumnos -$ 240,000.00$ 288,000.00$ 360,000.00$Ahorros

Reducción de Costos -$ 24,000.00$ 28,320.00$ 29,166.72$Total Ingresos Afectos a Impuestos: -$ 264,000.00$ 316,320.00$ 389,166.72$

Egresos Afectos a ImpuestosSueldos

Sueldos del Personal del Proyecto (102,000.00)$ -$ -$ -$Sueldos del Personal del Instituto -$ (186,000.00)$ (186,000.00)$ (186,000.00)$

Amortización de Intereses de Préstamos -$ (2,400.00)$ (1,660.72)$ (862.30)$Mantenimiento General -$ (19,200.00)$ (19,200.00)$ (19,200.00)$Insumos -$ (13,200.00)$ (15,180.00)$ (17,460.00)$Comunicación y Conexión -$ (9,600.00)$ (9,600.00)$ (9,600.00)$

Total Egresos Afectos a Impuestos: (102,000.00)$ (230,400.00)$ (231,640.72)$ (233,122.30)$Gastos No Desembolsados

Depreciación -$ (8,152.67)$ (8,152.67)$ (8,152.67)$Valor Contable -$ -$ -$ (872.00)$

Total Gastos No Desembolsados: -$ (8,152.67)$ (8,152.67)$ (9,024.67)$Total de Egresos: (102,000.00)$ (238,552.67)$ (239,793.39)$ (242,146.96)$

Utilidad Antes de Impuestos: (102,000.00)$ 25,447.33$ 76,526.61$ 147,019.76$Impuestos: 35,700.00$ (8,906.57)$ (26,784.31)$ (51,456.91)$

Utilidad Neta Después de Impuestos: (66,300.00)$ 16,540.77$ 49,742.30$ 95,562.84$Ajustes Gastos No Desembolsados

Depreciación -$ 8,152.67$ 8,152.67$ 8,152.67$Valor Contable -$ -$ -$ 872.00$

Total Ajustes Gastos No Desembolsados: -$ 8,152.67$ 8,152.67$ 9,024.67$Ingresos No Afectos a Impuestos

Préstamos 30,000.00$ -$ -$ -$Otros Ingresos (No Aplica) -$ -$ -$ -$

Total Ingresos No Afectos a Impuestos: 30,000.00$ -$ -$ -$Egresos No Afectos a Impuestos

Amortización de Capital de Préstamos -$ (9,241.01)$ (9,980.29)$ (10,778.71)$Hardware de PC (19,700.00)$ -$ -$ -$Intranet (430.00)$ -$ -$ -$Mobiliario de Oficina (1,300.00)$ -$ -$ -$Licencias de Sofware (4,200.00)$ -$ -$ -$

Total Egresos No Afectos a Impuestos: (25,630.00)$ (9,241.01)$ (9,980.29)$ (10,778.71)$FLUJO DE CAJA (Con Préstamo) (61,930.00)$ 15,452.43$ 47,914.68$ 93,808.80$

VAN: 38,508.61$TIR: 47%

Tomando en Cuenta el PréstamoPeríodos

13/11/2008 40



Flujo de Caja (Con Préstamo)

$ (61,930.00)

$ 15,452.43

$ 47,914.68

$ 93,808.80

$ (80,000.00)

$ (60,000.00)

$ (40,000.00)

$ (20,000.00)

$ -

$ 20,000.00

$ 40,000.00

$ 60,000.00

$ 80,000.00

$ 100,000.00

$ 120,000.00

C0 C1 C2 C3

Períodos

13/11/2008 41



Sin Tomar en Cuenta el Préstamo

C0 C1 C2 C3Año 0 Año 1 Año 2 Año 3

Ingresos Afectos a ImpuestosIngresos

Nuevos Alumnos -$ 240,000.00$ 288,000.00$ 360,000.00$Ahorros

Reducción de Costos -$ 24,000.00$ 28,320.00$ 29,166.72$Total Ingresos Afectos a Impuestos: -$ 264,000.00$ 316,320.00$ 389,166.72$

Egresos Afectos a ImpuestosSueldos

Sueldos del Personal del Proyecto (102,000.00)$ -$ -$ -$Sueldos del Personal del Instituto -$ (186,000.00)$ (186,000.00)$ (186,000.00)$

Amortización de Intereses de Préstamos -$ -$ -$ -$Mantenimiento General -$ (19,200.00)$ (19,200.00)$ (19,200.00)$Insumos -$ (13,200.00)$ (15,180.00)$ (17,460.00)$Comunicación y Conexión -$ (9,600.00)$ (9,600.00)$ (9,600.00)$

Total Egresos Afectos a Impuestos: (102,000.00)$ (228,000.00)$ (229,980.00)$ (232,260.00)$Gastos No Desembolsados

Depreciación -$ (8,152.67)$ (8,152.67)$ (8,152.67)$Valor Contable -$ -$ -$ (872.00)$

Total Gastos No Desembolsados: -$ (8,152.67)$ (8,152.67)$ (9,024.67)$Total de Egresos: (102,000.00)$ (236,152.67)$ (238,132.67)$ (241,284.67)$

Utilidad Antes de Impuestos: (102,000.00)$ 27,847.33$ 78,187.33$ 147,882.05$Impuestos: 35,700.00$ (9,746.57)$ (27,365.57)$ (51,758.72)$

Utilidad Neta Después de Impuestos: (66,300.00)$ 18,100.77$ 50,821.77$ 96,123.33$Ajustes Gastos No Desembolsados

Depreciación -$ 8,152.67$ 8,152.67$ 8,152.67$Valor Contable -$ -$ -$ 872.00$Total Ajustes Gastos No Desembolsados: -$ 8,152.67$ 8,152.67$ 9,024.67$

Ingresos No Afectos a ImpuestosPréstamos -$ -$ -$ -$Otros Ingresos (No Aplica) -$ -$ -$ -$

Total Ingresos No Afectos a Impuestos: -$ -$ -$ -$Egresos No Afectos a Impuestos

Amortización de Capital de Préstamos -$ -$ -$ -$Hardware de PC (19,700.00)$ -$ -$ -$Intranet (430.00)$ -$ -$ -$Mobiliario de Oficina (1,300.00)$ -$ -$ -$Licencias de Sofware (4,200.00)$ -$ -$ -$

Total Egresos No Afectos a Impuestos: (25,630.00)$ -$ -$ -$FLUJO DE CAJA (Sin Préstamo) (91,930.00)$ 26,253.43$ 58,974.43$ 105,148.00$

VAN: 98,445.87$TIR: 37%

No Tomando en Cuenta el PréstamoPeríodos

13/11/2008 42



Flujo de Caja (Sin Préstamo)

$ (91,930.00)

$ 26,253.43

$ 58,974.43

$ 105,148.00

$ (150,000.00)

$ (100,000.00)

$ (50,000.00)

$ -

$ 50,000.00

$ 100,000.00

$ 150,000.00

C0 C1 C2 C3

Períodos

13/11/2008 43



Cálculo y Análisis del TIR

Tomando en Cuenta el PréstamoEl TIR esperado tomando en cuenta el préstamo es del 47%. Esto es más que

satisfactorio tomando en cuenta la Tasa de Corte propuesta por el Instituto Buenos Aires

es del 20%.

Sin Tomar en Cuenta el PréstamoSin tomar en cuenta el préstamo solicitado, el TIR desciende a 37%. Esto se debe a

que el préstamo 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 obtendría sin

tener en cuenta el préstamo solicitado.

Cálculo y Análisis del VAN

Tomando en Cuenta el Préstamo

El VAN esperado es de $38.508,61. Dicho VAN es relativamente menor debido a

que se tiene que considerar la devolución del préstamo solicitado.

Sin Tomar en Cuenta el PréstamoEl 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 devolución de un préstamo.

Si sólo se tomara el TIR, la primera opción parece ser mejor que la segunda. Si sólo

se usara el VAN para analizar el Flujo de Caja se pensaría que no solicitar el préstamo

sería la mejor opción. Es por ello que es necesario emplear ambos criterios para

determinar si se solicitará el préstamo o no.

Nuestra recomendación es solicitar el préstamo dado que implicará una menor

inversión inicial y además analizando el flujo de caja podemos ver que si bien los

ingresos son menores, debido al pago de los intereses del préstamo, la diferencia no es

demasiado significativa.

13/11/2008 44



Análisis deRequerimientos

13/11/2008 45



Módulo de Gestión de Cobranzas

13/11/2008 46



Descripción del MóduloEste módulo tiene por finalidad automatizar gran parte de la gestión de cobros que

hoy se hace en forma manual.

Actualmente la gestión 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 través de un e-mail. El banco procesa la

información recibida y genera una respuesta en otro archivo.

Una de las finalidades principales de este módulo es poder automatizar el proceso

anteriormente descrito. Para ello es necesario poseer la información 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.

También es de gran utilidad para el instituto conocer quienes son todos los clientes

que son morosos porque tienen algún tipo de deuda con el instituto, es por ello que se

cuenta con un módulo de generación de reporte de morosos.

Para finalizar el circuito de cobros, se necesita que se puedan generar los recibos

correspondientes por los débitos realizados a los clientes para que sean entregados a los

mismos. Para cumplir esta funcionalidad se posee un caso de impresión de recibos.

Debemos aclarar que existe un caso especial: los clientes que no poseen cuenta

bancaria aún. Para hacer frente a este tema y que se pueda digitalizar la información 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 módulo y quienes son los actores.

13/11/2008 47



A continuación se analizarán en detalle cada caso y se realizará la especificación de

los mismos.

13/11/2008 48



Análisis del CU101 – Generar Listado de Débitos

Descripción del casoEste caso de uso debe permitir la generación automatizada y totalmente

informatizada del archivo que será enviado vía 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 través de la aplicación.

Se debe efectuar primero el cobro de cuotas e intereses desde los más antiguos a

los más recientes y luego efectuar el cobro de las cuotas actuales. Esto posibilita que los

intereses acumulados no crezcan desmesuradamente.

Especificación

Caso de UsoCU101-Generar Listado de Débitos

Breve Descripción Generar un listado de débitos para enviar al banco para el cobro decuotas y otros cargos.

Actores CobradorPrecondiciones Estar logueado al sistema

Poseer los permisos necesariosExistencia de clientes con cuenta bancaria con deudas

Post condiciones Se obtiene el listado de cobros y el archivocorrespondiente.

Referencias Incluye a:CU107-Buscar Clientes con DeudasCU108-Generar Archivo Débitos

Requerimientos NoFuncionalesCurso Normal

1. El Actor ingresa a la sección de cobros y elige la opción de generación del listadode cobros.

2. El Sistema muestra el formulario para la generación del listado de débitos.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 información y presiona “Generar Archivo para el Banco” para

descargar el mismo.8. Se ejecuta el “CU108-Generar Archivo Débitos”.9. El Sistema permite descargar el archivo generado.10. El Actor guarda el archivo para enviarlo al banco.

13/11/2008 49



Curso Alternativo3.1. El sistema detecta que esta incompleto el formulario y le muestra un mensaje conel 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 débitos a cobrar a clientes concuenta bancaria” en el caso de que la búsqueda no retorne ningún cliente que tengacuenta bancaria y posea deudas.

Interfases

Supuestos y Dependencias

Problemas / ComentariosLas tres fechas de cobro deben ser distintas y posteriores a la fecha actual. Además lasegunda fecha debe ser mayor a la primera y menor a la tercera; y la tercera mayor a laprimera y segunda.Anexo 1

PrioridadLas deudas se ordenarán cronológicamente y tendrán prioridad las cuotas.

InteresesLas cuotas tienen un 3% acumulativo de recargo por mes de atraso, por lo que secalcularan con la siguiente formula:

CF = C * (1 + i) M

CF: Valor Cuota FinalC: Valor Cuota InicialM: Meses de atrasoi: Interés

Campos de la tabla del punto 6Se deben mostrar el legajo del alumno, el CBU de la cuenta del mismo y el importe deldébito a efectuar por el banco en la cuenta indicada.

13/11/2008 50



Análisis del CU102 – Procesamiento de Resultados de losDébitos

Descripción del casoEste 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 débito 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 información. 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 también para el cálculo de deudas e intereses futuros.

Especificación

Caso de UsoCU102- Procesamiento de Resultados de losDébitos

Breve Descripción Ingreso al sistema de la información recibida del banco para laactualización de las cuentas de los clientes.


Poseer los permisos necesariosTener el archivo con los resultados de los débitos

Post condiciones Se actualiza el sistema con la información de los cobrosReferencias Incluye a:

CU109-Convertir Archivo De CréditosRequerimientos NoFuncionales

No posee

Curso Normal1. El Actor ingresa a la sección de cobros y elige la opción de ingreso de resultado de

débitos.2. El Sistema muestra el formulario pidiendo el archivo que envió el banco con los

resultados de los débitos solicitados.3. El Actor ingresa el archivo y presiona “Subir”.4. El Sistema valida y ejecuta el “CU109-Convertir Archivo De Créditos”.5. El Sistema actualiza las cuentas y muestra por pantalla que la operación se ha

realizado con éxito.

13/11/2008 51



Curso Alternativo3.1. El actor presiona “Limpiar” y vuelve al punto 2.4.1. Si la validación falla el sistema presenta un mensaje de error indicando que no escorrecto el archivo ingresado.4.2. Continúa en el punto 3.

Interfases


Problemas / Comentarios

Anexo 1

Formato del archivo de resultado de débitosEl archivo tiene como nombre “idbla.sds”.A continuación de describe la estructura:Header (2 líneas)Línea-CaracterInicial-CaracterFinal00-00-03 ID Establecimiento00-04-05 Código de XYZBody (una línea por débito)Footer (1 línea)

13/11/2008 52



Análisis del CU103 – Clientes sin Cuenta Bancaria

Descripción del casoEste caso de uso debe permitir registrar los cobros de cuotas de los clientes que

aún 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 través del sistema.

También mediante este caso es posible que el cliente realice adelantos de dinero en

concepto de crédito para cancelar futuros débitos.

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 impresión de recibos.

Especificación

Caso de UsoCU103-Clientes sin Cuenta Bancaria

Breve Descripción Ingreso de los pagos efectuados en forma manual al sistema de losusuarios sin cuenta bancaria.


Poseer los permisos necesariosPost condiciones Se actualiza el sistema con la información de los cobrosReferencias Incluye a:

CU106-Imprimir ReciboRequerimientos NoFuncionalesCurso Normal

1. El Actor ingresa a la sección de cobros y elige la opción de cobro manual.2. El Sistema muestra el formulario de búsqueda 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

búsqueda.5. El Actor selecciona el cliente que desea realizar el pago haciendo clic en el botón

“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 confirmación 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 53



Curso Alternativo3.1. El Actor presiona “Limpiar” y vuelve al punto 2.4.1.1. Si la búsqueda trae una lista vacía porque no hay alumnos coincidentes con elcriterio de búsqueda muestra un mensaje indicando dicha situación.4.2.1. El Actor presiona “Limpiar” si desea realizar una nueva búsqueda. Vuelve alpunto 27.1. El Actor presiona “Limpiar” y vuelve al punto 6.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

Campos de la tabla del punto 4Se deben mostrar el legajo, nombre, apellido y documento del alumno. Además se debemostrar una columna con un botón que permita seleccionar al alumno para efectuar elcobro.

Campos de la tabla del punto 6Se deben mostrar la fecha, una descripción y el monto de cada deuda que posea elalumno.

13/11/2008 54



Análisis del CU104 – Generar Reporte de Morosos

Descripción del casoEste 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 día con sus obligaciones.

Para la búsqueda de los clientes que poseen deudas se tendrán en cuenta los

mismos factores utilizados para generar el archivo de débitos a enviar al banco. Por dicho

motivo se dispondrá de un caso que lleve a cabo esta tarea de forma general.

Especificación

Caso de UsoCU104-Generar Reporte de Morosos

Breve Descripción Genera un listado de morosos e información de los mismos.


Poseer los permisos necesariosPost condiciones Se obtiene el listado de morososReferencias Incluye a:

CU107-Buscar Clientes Con DeudasRequerimientos NoFuncionalesCurso Normal

1. El Actor ingresa a la sección de cobros y elige la opción de generación de reportede morosos.

2. Se ejecuta automáticamente el “CU107-Buscar Clientes Con Deudas”.3. El Sistema genera el listado y lo muestra por pantalla (Ver “Anexo 1”). Además

también muestra la cantidad de morosos en forma numérica.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 Alternativo3.1. Si la búsqueda trae una lista vacía porque no hay morosos muestra el mensaje“No se ha encontrado ningún moroso”.4.1. Si no hay morosos, al querer imprimir el reporte se mostrará una advertencia conel mensaje “No hay morosos a incluir en el reporte”.

Interfases


13/11/2008 55




Anexo 1

Campos de la tabla del punto 3Se deben mostrar el legajo, nombre, apellido y teléfono del alumno además del monto dela deuda que posee.

Los morosos se ordenarán de mayor a menor deuda.

13/11/2008 56



Análisis del CU105 – Impresión de Recibos

Descripción del casoEste caso de uso debe permitir la impresión 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 impresión,

se debe permitirse la impresión masiva de recibos seleccionados. Ello supondrá una

ventaja en cuanto a tiempos y trabajo necesario.

Especificación

Caso de UsoCU105-Impresión de Recibos

Breve Descripción Impresión de los recibos de todos los clientes.


Poseer los permisos necesariosPost condiciones Se obtienen impresos todos los recibos de los clientesReferencias Incluye a:

CU106-Imprimir ReciboRequerimientos NoFuncionalesCurso Normal

1. El Actor ingresa a la sección de cobros y elige la opción de impresión de recibos.2. El Sistema automáticamente muestra un listado de los recibos pendientes de ser

impresos. También se muestra la cantidad total de recibos a imprimir y también lacantidad 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 Alternativo2.1. Si la búsqueda trae una lista vacía porque no hay recibos se debe mostrar elmensaje “No se ha encontrado ningún recibo”.3.1. Si no hay recibos a ser impresos y se hace clic sobre “Imprimir Recibos” semostrará una advertencia con el mensaje “No hay recibos pendientes de serimpresos”.

Interfases

13/11/2008 57





Anexo 1

Campos de la tabla del punto 2Se deben mostrar el número de recibo interno del sistema, el legajo, nombre y apellido delalumno y la fecha del recibo.

13/11/2008 58



Análisis del CU106 – Imprimir Recibo

Descripción del casoEste caso de uso debe permitir la impresión 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 parámetros de impresión a utilizar para los recibos a

confeccionar.

Especificación

Caso de UsoCU106-Imprimir Recibo

Breve Descripción Imprime un recibo. Contiene la lógica de impresiónActores SistemaPrecondiciones Datos del reciboPost condiciones Recibo impresoReferencias Es incluido por:

CU103-Clientes sin Cuenta BancariaCU105-Impresión de Recibos


1. Se genera el recibo a imprimir a partir de un modelo predefinido.2. Se configura la impresión con la calidad y el tamaño del papel correspondiente.3. Se permite su impresión.

Curso Alternativo2.1. Si no se encuentra el modelo se muestra un mensaje indicando dicha situación.3.1. Si no se puede mostrar el recibo se muestra un mensaje indicando dicha situación.

Interfases



13/11/2008 59



Análisis del CU107 – Buscar Clientes con Deudas

Descripción del casoEste 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 situación de

cada cliente y efectuar los cálculos de cobro e intereses correspondientes.

Encapsula la lógica de búsqueda de los clientes deudores para así facilitar su

reutilización en otros casos de uso.

Este caso de uso será utilizado por otros que para su ejecución es necesario

conocer quienes son deudores, por ejemplo para la generación de reporte de morosos.

Especificación

Caso de UsoCU107-Buscar Clientes con Deudas

Breve Descripción Busca los clientes con deuda.

Actores SistemaPrecondiciones Fecha máximaPost condiciones Se obtiene el listado de clientes con deudaReferencias Es incluido por:

CU101-Generar Listado de DébitosCU104-Generar Reporte de Morosos

Requerimientos NoFuncionalesCurso Normal1. Ejecuta la búsqueda de clientes obteniendo todos aquellos cuyo crédito es superado

por los débitos generados antes de la fecha máxima.

Interfases



13/11/2008 60



Análisis del CU108 – Generar Archivo Débitos

Descripción del casoEste caso de uso debe ser capaz de generar el archivo con los débitos a las cuentas

de los clientes del instituto para el cobro de cuotas, deudas e intereses.

Contiene la lógica de generación del archivo con el formato que utiliza el banco a

través de la macro definida en la planilla de Excel que provee el banco para realizar estas

operaciones.

Para la generación 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.

EspecificaciónCaso de Uso

CU108-Generar Archivo Débitos

Breve Descripción Generar el archivo de texto con el formato que requiere el bancoActores SistemaPrecondiciones Obtener la información sobre los débitos.Post condiciones Archivo generado para el bancoReferencias Es incluido por:

CU101-Generar Listado de DébitosRequerimientos NoFuncionalesCurso Normal

1. Se genera el archivo con el formato correspondiente (Ver “Anexo 1”).Interfases



Anexo 1

Formato del archivo de débito para el bancoEl resultado del proceso genera un archivo de texto plano que lleva como nombre “idbla.sds”.

A continuación de describe la estructura:

Header (2 líneas)Línea-CaracterInicial-CaracterFinal00-00-03 ID Establecimiento00-04-05 Código de XYZ

Body (una línea por débito)

Footer (1 línea)

13/11/2008 61



Análisis del CU109 – Convertir Archivo de Créditos

Descripción del casoEste caso de uso debe ser capaz de interpretar el archivo de resultados a las

operaciones de débitos 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 información de

respuesta pueda ser cargada a la base de datos del sistema de cobros del instituto.

Encapsula la lógica de interpretación de dicho archivo.

Especificación

Caso de UsoCU109-Convertir Archivo De Créditos

Breve Descripción Convierte el archivo de créditos.Actores SistemaPrecondiciones Poseer archivo con créditosPost condiciones Estructura de datos con la información del archivoReferencias Es incluido por:

CU102-Procesamiento de Resultados de los DébitosRequerimientos NoFuncionalesCurso Normal

1. Convertir el archivo a una estructura de datos manejable por nuestro sistema.

Curso Alternativo

Interfases

Supuestos y Dependencia


13/11/2008 62



Diagramas de Actividades

Generar Listado de Débitosact Modulo 1 Generar Listado Debitos

Mostrar Formulario para laGeneración del Listado de

Débitos

Buscar Clientes conDeudas

Solicitar Logueo

Solicitar Permisos

Comi enzo

Mostrar Listado conlas Deudas

Fi n

Completar Formulario

Generar Listado dedébitos

Generar Archiv oDébitos

GuardarArchiv o

«datastore»Archiv os de

Debi tos

Cancelar la accio n de completar elformulario

No tiene Permisos

Formu larioIncom pleto

Cancel ar lageneracion

13/11/2008 63



Diagramas de Secuencia

Generar Listado de Débitossd 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 64



Diagramas de Estado

Gestión de Débitosstm Gestión de Débitos

Ini cio

Período deGeneración de Débitos

Débitos G enerados

Débitos Enviados

Resultado Dé bitosRecibido

Débito Rechazado

¿Resultado Débito?

Débito Realizado

Recha zo Dé bitoAsentado

Débito EfectuadoAsentado

Deuda Cancelada conDébito

Fin al

[Cancelar Deudas Correspondientes]

[Asentar Débi to Efectuado]

[Débito E fectuado][Débito No Efectuado]

[Asentar Rechazo]

[Procesar Resultados]

[Recibir Resultados]

[Enviar Débitos]

[Generar Débitos]

13/11/2008 65



Módulo de Situación vía Web

13/11/2008 66



Descripción del MóduloEste módulo tiene por finalidad proporcionarle al cliente información sobre el estado

de los pagos de cuotas y de los débitos que se le han podido realizar o no.

También permite proporcionarle al cliente información sobre las deudas y los

intereses generados por falta de pago de cuotas anteriores.

Con este módulo el cliente podrá saber y cotejar con la información que provea el

banco cuales fueron los débitos que el instituto ha realizado a su cuenta para el cobro de

las cuotas y deudas correspondientes.



uc Situación Vía Web

Clie nte

CU201-Consul ta deSaldo

CU202-Consulta deDeudas

CU203-Impre siónListado Deudas

Cobrador

«include»


los mismos.

13/11/2008 67



Análisis del CU201 – Consulta de saldo

Descripción del casoEste caso de uso debe permitir que el cliente vea las transacciones (debitos-

créditos) realizadas en su cuenta.

Con esta información el cliente podrá saber por ejemplo que día se hizo el debito de

su cuenta bancaria.

Además 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.

Especificación

Caso de UsoCU201-Consulta De Saldo

Breve Descripción Busca las transacciones de la cuenta del cliente

Actores Cliente, CobradorPrecondiciones Estar logueado al sistema

Poseer los permisos necesariosPost condiciones Se obtiene el listado con las transacciones de los clientesReferenciasRequerimientos NoFuncionalesCurso Normal

1. El Actor ingresa a la sección de Consulta de Situación y elige la opción Consultade 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 además de datos

básicos del cliente. (Ver “Anexo 1”)Curso Alternativo

2.1.1. Si se determina que el usuario pertenece al instituto se habilita la búsqueda declientes

2.1.2. Se muestra el formulario de búsqueda 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 búsqueda (Ver “Anexo 2”)2.1.3.1 Si el actor presiona “Limpiar” vuelve al punto 2.1.22.1.4. El Actor presiona el botón “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 botón “Volver”

que le permite regresar al punto 2.1.43.1. Si el no existen movimientos se mostrará el mensaje que indique dicha situación.3.2. Si el cliente no posee una cuenta bancaria se le mostrará el mensaje indicando

dicha situación. Sólo podrá ver la situación luego del primer cobro manual.

13/11/2008 68



Interfases:



Anexo 1

Datos básicos a mostrar en el punto 3Se mostrará el nombre, apellido, banco, CBU y saldo del cliente.

Campos de la tabla del punto 3Se deben mostrar la fecha, una descripción, el monto de débito y el monto de crédito(completo si corresponde) para cada transacción.

Anexo 2

Campos de la tabla del punto 2.1.3Se deben mostrar el legajo, nombre, apellido y documento del cliente. Además se debemostrar una columna con un botón que permita seleccionar el cliente para ver los detallesde las transacciones.

13/11/2008 69



Análisis del CU202 – Consulta de Deudas

Descripción del casoEste caso de uso debe permitir al cliente, en caso de tener deudas, visualizar en

forma detallada el estado de su situación respecto al cobro de cuotas por parte del

instituto.

Se deben mostrar las deudas con sus respectivos intereses y el total de las mismas.

Además 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.

Especificación

Caso de UsoCU202-Consulta de Deudas

Breve Descripción Muestra al cliente las cuotas que debe (y otras deudas) y losintereses correspondiente.

Actores Cliente, CobradorPrecondiciones Estar logueado al sistema

Poseer los permisos necesarios

Post condiciones

Referencias Incluye a:CU203-Impresión de Listado Deudas


1. El Actor ingresa a la sección de Consulta de Situación y elige la opción deConsulta 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 botón “Imprimir

Reporte” y el sistema ejecuta el “CU203-Impresión de Listado Deudas”.

13/11/2008 70



Curso Alternativo2.1.1. Si se determina que el usuario pertenece al instituto se habilita la búsqueda de

clientes.2.1.2. Se muestra el formulario de búsqueda 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 búsqueda (Ver “Anexo 2”)2.1.3.1 Si el actor presiona “Limpiar” vuelve al punto 2.1.22.1.4. El Actor presiona el botón “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 botón “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 encontradodeudas”.

Interfases



Anexo 1

Datos básicos a mostrar en el punto 3Se mostrará el nombre y apellido del cliente.

Campos de la tabla del punto 3Se deben mostrar la fecha, una descripción, el monto de la deuda.

Anexo 2

Campos de la tabla del punto 2.1.3Se deben mostrar el legajo, nombre, apellido y documento del cliente. Además se debemostrar una columna con un botón que permita seleccionar el cliente para ver los detallesde las transacciones.

13/11/2008 71



Análisis del CU203 – Impresión Listado Deudas

Descripción del casoEste caso de uso debe permitir la impresión de los detalles de las deudas que posee

un cliente (si así es) con la información que visualiza por pantalla.

Para facilitar el guardado y también la impresión 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 página o si no lo posee deberá bajarlo para poder

visualizarlo en otra aplicación y luego imprimirlo.

Especificación

Caso de UsoCU203-Impresión Listado Deudas

Breve Descripción Imprime el detalle de las deudas que posee un cliente.

Actores SistemaPrecondiciones Un cliente usuario debe estar logueado al sistema

El cliente debe poseer deudas

Post condiciones

Referencias Es incluido por:CU202-Consulta de Deudas


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 envía al generador de reportes en PDF la información obtenida en el

punto anterior.4. El sistema muestra el reporte para permitir que el cliente lo imprima o lo guarde.

Curso Alternativo4.1 Seleccionando “Guardar” el sistema guarda el archivo PDF generado.

Interfases



13/11/2008 72




Consulta de deudasact Modulo 2 Consultas de Deudas

Comi enzo

Solicitar Logueo

Fi n

Solicitar Permisos

Obtener Usuario

Obtener Duedas

Imprimir grilla con lasdeudas

¿Es cl iente?

Buscar Cliente

Seleccionar Cliente

No tiene permisos

No esta logueado

S i

No

13/11/2008 73



Módulo de Inscripción

13/11/2008 74



Descripción del MóduloEste módulo tiene por finalidad la administración de las preinscripciones, tanto para

el alta de las mismas con todos sus datos requeridos como para aprobar o rechazar una

solicitud. Además este módulo permite consultar el estado de la preinscripción cargada

en el sistema por parte del cliente o si el usuario es un empleado del instituto se le

permite consultar por cualquier preinscripción.

Los datos necesarios para realizar una preinscripción actualmente están contenidos

en un formulario con una gran cantidad de datos que se deben completar. Dicho

formulario es definido por la Dirección General de Cultura y Educación de la Provincia de

Buenos Aires.

La administración de las preinscripciones recibidas hasta la fecha de tope informada

oportunamente, permitirá tener la información de la solicitud para que pueda ser

analizada y aceptada o en su defecto rechazada.



uc Inscripción

Clie nte

CU301 -Alta dePreinsc ripción

CU302-Administradorde Preinscripción

Direc tiv o

CU303-Consul ta deEstado de

Preinsc ripción


los mismos.

13/11/2008 75



Análisis del CU301 – Alta de Preinscripción

Descripción del casoEste 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 período correspondiente, la preinscripción 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 período de preinscripción definido, el padre

podrá consultar cual fue el resultado de la misma también vía Internet.

El padre deberá concurrir al establecimiento del instituto solo luego de que fue

aprobado su pedido.

Especificación

Caso de UsoCU301-Alta de Preinscripción

Breve Descripción Permite realizar la preinscripción de alumnos (tanto nuevos como delos que ya pertenecen al instituto) para el próximo ciclo lectivo.

Actores Padres o tutores del Alumno, DirectivoPrecondiciones El Módulo debe estar habilitadoPost condiciones La información de preinscripción es guardada y queda a la

espera de ser aprobada con el administrador.ReferenciasRequerimientos NoFuncionalesCurso Normal

1. El Actor ingresa a la sección de preinscripción y elige la opción de Alta depreinscripciones.

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 operación se ha realizado con éxito.8. El Sistema genera un reporte, para ser impreso, con la constancia de

preinscripción la cual contiene un número único para futuras consultas.

13/11/2008 76



Curso Alternativo3.1. Si el usuario logueado es un cliente y ya posee una solicitud de preinscripción en

curso se le mostrará un mensaje que indicará dicha situación y se lo invitará aconsultar el estado desde el “CU303-Consulta de estado de preinscripción”.Además 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 más deuna preinscripción.

4.1. El Actor presiona “Limpiar” para borrar los datos ingresados y poder comenzar otravez.

5.1. Si alguno de los datos no es válido, el sistema regresa al punto 2 y muestra unmensaje indicando cual es el dato incorrecto.

6.1. Si el usuario logueado es del personal del instituto el sistema automáticamentecreará un usuario para que sea entregado al cliente futuras consultas e interaccióncon el instituto.

7.1. Si el usuario logueado es del personal del instituto se mostrará además unmensaje con el usuario y contraseña 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 77



13/11/2008 78



Análisis del CU302 – Administrar preinscripciones

Descripción del casoEste caso de uso debe permitir administrar las preinscripciones recibidas en el

período definido para aceptar preinscripciones para el siguiente ciclo lectivo.

El directivo deberá poder visualizar la información ingresada por los padres para así

poder evaluar la situación y aceptar o rechazar la misma.

Luego de especificar una resolución, los padres que han solicitado podrán conocer

el resultado de la misma y en caso de ser aceptada deberán concurrir al establecimiento

para finalizar el proceso de inscripción.


CU302-Administrar Preinscripciones

Breve Descripción Administrar las preinscripciones ingresadas por el módulo de alta depreinscripciones, para aceptar o rechazar las mismas.

Actores DirectivoPrecondiciones Estar logueado al sistema

Poseer los permisos necesarios

Post condiciones Las preinscripciones recibidas han sido procesadas yguardado un resultado para cada una de las mismas.

ReferenciasRequerimientos NoFuncionalesCurso Normal

1. El Actor ingresa a la sección de preinscripción y elige la opción de administraciónde preinscripción.

2. El Sistema muestra los distintos criterios de búsqueda para analizar laspreinscripciones (según Modalidad, Año, Turno y da la opción de ver los yaprocesados o los que están pendientes).

3. El Sistema muestra un apartado con estadísticas de preinscripciones. (Ver “Anexo1”).

4. El Actor ingresa los criterios de búsqueda 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 división o “rechazar” en su defecto y selecciona las

preinscripciones de los alumnos que formarán parte de la asignación y presiona“Asignar División” para realizar una asignación de varias preinscripciones a la vez.

7. El Sistema coloca los alumnos en los cursos indicados y muestra un mensaje deasignación correcta.

8. El Actor presiona el botón “Volver” y regresa al punto 2 donde podrá asignar otroscursos a las preinscripciones restantes.

13/11/2008 79



Curso Alternativo5.1. El Actor presiona “Volver” y regresa al punto 2.

6.1.1. El Actor selecciona individualmente una preinscripción.6.1.2. El Actor hace clic sobre la celda que dice “Haga clic”, o que posee la división si

ya se le había asignado una, de la fila correspondiente a la preinscripción aadministrar.

6.1.3. El Sistema muestra una lista con las posibilidades de asignación.6.1.4. El Actor selecciona la opción de asignación deseada y presiona en el tilde verde

para aceptar o en la cruz roja para cancelar.

6.2.1. El Actor presiona el botón “Ver” para examinar los datos de la preinscripción (losmismos 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

Estadísticas de PreinscripcionesPara mostrar las estadísticas de preinscripciones se utilizará un árbol donde cada ítemconsolidará la cantidad de preinscripciones Aceptadas, Rechazadas y No Procesadas,indicadas con color verde, rojo y azul respectivamente, por cada Modalidad, Turno, Año yCurso. Esto permitirá visualizar tanto la información a nivel global como en formadetallada.

Anexo 2

Campos de la tabla del punto 5Se deben mostrar el nombre, apellido, división (esta columna deberá ser editable para queal hacer clic se pueda cambiar la misma). Además se debe mostrar una columna con unbotón que permita seleccionar la preinscripción para ver los detalles de la misma.

13/11/2008 80



Análisis del CU303 – Consulta de Estado de Preinscripción

Descripción del casoEste 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 preinscripción; o que el usuario sea del instituto por lo cual podrá consultar por

distintas preinscripciones.


CU303-Consulta de Estado de PreinscripciónBreve Descripción Consultar el estado de una preinscripción dada de alta en el

sistema.

Actores Padres o tutores del Alumno, DirectivoPrecondiciones Estar logueado al sistema

Poseer los permisos necesariosExistencia de preinscripciones

Post condiciones El estado de la preinscripción ha sido informado.ReferenciasRequerimientos NoFuncionalesCurso Normal

1. El Actor ingresa a la sección de preinscripción y elige la opción de consulta depreinscripción.

2. El Sistema determina si el usuario logueado es un cliente.3. El Sistema muestra automáticamente el estado de la preinscripción para el cliente.

Curso Alternativo2.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 búsqueda.2.1.3. El Actor completa el/los campo/s solicitado/s y presiona “Consultar”.2.1.3.1. Si no existe una preinscripción que coincida con el criterio indicado se

informará de dicha situación.2.1.4. El Sistema muestra el estado de la preinscripción indicada.2.1.5. El Actor presiona “Limpiar” y vuelve al punto 2.1.23.1. Si el usuario no tiene una preinscripción cargada se informará dicha situación.

Interfases:



13/11/2008 81




Administrar Preinscripcionesact Administración Preinscripcion

Solicitar Logueo

Comi enzo

ConsultarPreinscriptos

Asignar alumnos acurso o rechazar

Guardar datos decursos

«datastore»Archivo de Cursos

Fi n

Solicitar permisos

Cambiar de criterio

No esta logueado

No tiene permisos

Terminar Consulta

Cambiar de curso

Termina r carga

13/11/2008 82



Alta de Preinscripcionesact Alta de Preinscripción

Comi enzo

Ingresar aPreincripción

Ingresar Datos

Guardar datos«datastore»

Archiv o DatosPreinscripciones

Fi n

Solicitar Logueo

Solicitar permisos

No esta logueado

No tiene permisos

Cancelarpreinscripción

Tiene errores

Cancelarpreinscripción

13/11/2008 83



Diagramas de Secuencia

Alta de Preinscripciónsd Alta de Preinscripción

Usuario Page Data PreinscripcionBO Preinscri pcionDAO PreinscripcionManejoErrores

IngresarDatos()

AltaPreinscripcion(Datos)

ValidateData(Datos) :bool ean

IsInvalid()

Invalid(Cause)

SavePreinscripcion(Preinscripcion)

SavePreinscripcion()

[Results]()

[OK orNOK]()

13/11/2008 84



Diagramas de Estado

Inscripciónstm Inscripción

Ini cio

PreinscripciónHabil itada

PreinscripciónRecibida

PreinscripciónRecha zada

PreinscripciónAceptada

Espe randoConfirmación

Vacante Rechazadapor Cliente

Vacante Otorgada

Inscripc iónFinalizada OK

Final

Vacante Liberada

¿Resultado?

¿Resu ltadoConfirmación?

[Nueva Prei nscripción]

[Otorgar vacante temporalmente]

[Rechazar Pre inscripción]

[Aceptar Pre inscripción]

[Rechazar Co nfirmación][Recibir Co nfirmación]

13/11/2008 85



Módulo de Administración de Datos

13/11/2008 86



Descripción del MóduloEste módulo tiene por finalidad la administración de los datos manejados por la

aplicación y que pueden ser modificados, por ejemplo los datos de los alumnos.



uc Administración de Datos

Empleado

CU401-Modificac ión deDatos de Alumnos

CU402 -Baja deAlumnos


los mismos.

13/11/2008 87



Análisis del CU401 – Modificación de Datos de Alumnos

Descripción del casoEste caso de uso debe permitir la modificación de los datos de los alumnos del

instituto.

Se usará principalmente para actualizar datos de los alumnos, como por ejemplo

domicilio, número de teléfono y otros.

En cuanto a que datos se podrán modificar, deberá poder modificarse todos los

datos asociados al alumno y solo podrá ser realizado por el perfil de más alto rango dado

que posee información sensible y se debe tener especial cuidado.

Especificación

Caso de UsoCU401 – Modificación de Datos de Alumnos

Breve Descripción Modificación de los datos de los alumnos del instituto.Actores EmpleadoPrecondiciones Estar logueado al sistema

Poseer los permisos necesariosPost condiciones Se modificaron los datos de un alumno que ya existía.Referencias


1. El Actor ingresa a la sección Administración de alumnos y elige la opción demodificación.

2. El Sistema muestra el formulario para ingresar los criterios de búsqueda dealumnos.

3. El Actor completa el formulario con los criterios deseados y presiona “Buscar”.4. El Sistema muestra, además de los criterios de búsqueda indicados, una grilla con

los datos de los alumnos que cumplen el criterio seleccionado y que son alumnosdel instituto (Ver “Anexo 1”).

5. El Actor presiona sobre el botón “Modificar” de la fila correspondiente al alumno amodificar.

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 88



Curso Alternativo3.1.1. El Actor presiona “Buscar” sin completar ningún criterio.3.1.2. El Sistema informa que debe completar al menos un criterio de búsqueda.3.2. El Actor presiona “Limpiar” y vuelve al punto 2.

4.1. Si no hay alumnos que coincidan con el criterio indicado se informa dichasituación con un mensaje.

5.1. El Actor presiona “Volver” y regresa al punto 2.

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 válidos se le informará con diversos mensajes dela ubicación de los mismos y cuál es el error.

Interfases:



Anexo 1

Campos de la tabla del punto 4Se deben mostrar el legajo, nombre, apellido y documento del alumno. Además se debemostrar una columna con un botón que permita seleccionar al alumno para modificar losdatos del mismo.

Anexo 2

Formulario de modificación de datosEl formulario de modificación de datos debe incluir además de los datos del alumno,padre, madre y responsable/tutor, los datos de la cuenta bancaria y los datos del cursoactual del alumno.

13/11/2008 89



Análisis del CU402 – Baja de Alumnos

Descripción del casoEste 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 institución por cualquier motivo.

Permitirá que se puedan ver los datos del alumno antes de su baja y además se

tendrá la posibilidad de dar de baja a varios alumnos a la vez.

Esta operación solo podrá ser realizada por el perfil de más alto rango dado que

posee información sensible y se debe tener especial cuidado.

Especificación

Caso de UsoCU402 – Baja de Alumnos

Breve Descripción Baja de los alumnos que ha dejado de formar parte del instituto.Actores EmpleadoPrecondiciones Estar logueado al sistema

Poseer los permisos necesariosPost condiciones Se dio de baja a uno o varios alumnos del instituto.Referencias


1. El Actor ingresa a la sección Administración de alumnos y elige la opción de baja dealumnos.

2. El Sistema muestra el formulario para ingresar los criterios de búsqueda dealumnos.

3. El Actor completa el formulario con los criterios deseados y presiona “Buscar”.4. El Sistema muestra, además de los criterios de búsqueda indicados, una grilla con

los datos de los alumnos que cumplen el criterio seleccionado y que son alumnosdel instituto (Ver “Anexo 1”).

5. El Actor presiona sobre el botón “Eliminar” de la fila correspondiente al alumno a darde baja.

6. El Sistema solicita una confirmación de la acción requerida.7. El Actor acepta la confirmación.8. El Sistema procesa el pedido de baja y guarda los cambios.9. El Sistema vuelve al punto 4.

13/11/2008 90



Curso Alternativo3.1.1. El Actor presiona “Buscar” sin completar ningún criterio.3.1.2. El Sistema informa que debe completar al menos un criterio de búsqueda.3.2. El Actor presiona “Limpiar” y vuelve al punto 2.

4.1. Si no hay alumnos que coincidan con el criterio indicado se informa dichasituación con un mensaje.

5.1. El Actor presiona “Volver” y regresa al punto 2.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 confirmación sobre la baja de los alumnos

seleccionados.5.2.3. El Actor acepta la confirmación de baja masiva.5.2.3.1. El Actor rechaza la confirmación y vuelve al punto 5.2.15.2.4. El Sistema procesa y da de baja a los alumnos.5.2.5. El Sistema informa con un mensaje que la operación se ha completado y vuelve

al punto 4.5.3.1. El Actor presiona el botón “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.5.4. El Actor presiona “Volver” y regresa al punto 4.

Interfases:



Anexo 1

Campos de la tabla del punto 4Se deben mostrar el legajo, nombre, apellido y documento del alumno. Además se debemostrar una columna con un botón que permita ver los detalles de los datos del alumno yotra columna con otro botón para poder dar de baja al alumno correspondiente a la filaindicada.Anexo 2

Formulario de modificación de datosEl formulario de modificación de datos debe incluir además de los datos del alumno,padre, madre y responsable/tutor, los datos de la cuenta bancaria y los datos del cursoactual del alumno.

13/11/2008 91



Diagramas de Actividad

Administración de Alumnosact Modulo 4 Administración de Alumnos

Mostrar opciones demodificación o baja

Solicitar Logueo

Solicitar Permisos

Comi enzo

Fi n

Mostrar buscador deAlumnos

Guarda Datos«datastore»

Datos Alumnos

Modificar datos oEliminar Alumno

Modificación Eliminar

ConfirmarModificación

Confirmar BajaAlumno

No tiene permisos

Cancelar Modificación

No esta logueado

Cancelar

Cancelar

No se encontró Alumno

Tiene errores

13/11/2008 92



Módulo de Administración deSeguridad

13/11/2008 93



Descripción del MóduloEste módulo tiene por finalidad la administración de la seguridad del sistema.

A través de los casos de uso de este módulo se podrán crear usuarios y perfiles,

asignar perfiles y permisos. Así mismo se podrán modificar los datos de los usuarios,

perfiles y permisos ya creados.



uc Administración de Seguridad

Administrador delSistema

CU501- Administraciónde Permisos

CU502- Administraciónde Perfiles

CU502- Administraciónde Usuarios


los mismos.

13/11/2008 94



Análisis del CU501 – Administración de Permisos

Descripción del casoEste caso de uso debe permitir el alta y la modificación de los permisos que el

sistema posee.

Se usará principalmente para actualizar datos de los permisos, por ejemplo entre

ellos los títulos de las entradas de menú y la descripción de los mismos para facilitar su

comprensión.

Se deberá poder buscar por distintos criterios para que luego sean modificados.

Especificación

Caso de UsoCU501 – Administración Permisos

Breve Descripción Modificación de los permisos del sistema.Actores Administrador del SistemaPrecondiciones Estar logueado al sistema

Poseer los permisos necesariosPost condiciones Se modificaron los datos de los permisos del sistema.Referencias


1. El Actor ingresa a la sección Administración de Seguridad y elige la opción dePermisos.

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 enel 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 operación

13/11/2008 95



Curso Alternativo3.1.1. El Actor presiona “Buscar permisos para modificar”.3.1.2. El Sistema presenta los campos correspondientes a los criterios de búsqueda

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

modificación 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.53.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 alpunto 2 pero con los datos ingresados por el actor.

Interfases:



Anexo 1

Campos de la tabla del punto 3.1.5Se deben mostrar el identificador del permiso dentro del sistema, el titulo que aparece enel menú y la descripción del permiso. Además se debe mostrar una columna con un iconoque permita seleccionar el permiso para que sea modificado.

13/11/2008 96



Análisis del CU502 – Administración de Perfiles

Descripción del casoEste caso de uso debe permitir el alta y la modificación 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.


Especificación

Caso de UsoCU502 – Administración Perfiles

Breve Descripción Modificación de los perfiles del sistema.Actores Administrador del SistemaPrecondiciones Estar logueado al sistema

Poseer los permisos necesariosPost condiciones Se modificaron los datos de los perfiles del sistema.Referencias


1. El Actor ingresa a la sección Administración de Seguridad y elige la opción dePerfiles.

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 operación.

13/11/2008 97



Curso Alternativo3.1.1. El Actor presiona “Buscar perfiles para modificar”.3.1.2. El Sistema presenta los campos correspondientes a los criterios de búsqueda

de perfiles.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 perfiles que corresponden al criterio

especificado (Ver “Anexo 1”).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

modificación de todos los campos.3.1.8. El Actor realiza los cambios, presiona “Guardar” para hacer efectivos los


Interfases:



Anexo 1

Campos de la tabla del punto 3.1.5Se deben mostrar el detalle del perfil y una columna con un icono que permita seleccionarel perfil para que sea modificado.

13/11/2008 98



Análisis del CU503 – Administración de Usuarios

Descripción del casoEste caso de uso debe permitir el alta y la modificación de los usuarios que el

sistema posee.

Se usará principalmente para actualizar datos de los usuarios, por ejemplo su

nombre, apellido, contraseña y el perfil actual asociado al usuario. Además permitirá

agregar nuevos usuarios al sistema.


Especificación

Caso de UsoCU503 – Administración Usuarios

Breve Descripción Modificación de los usuarios del sistema.Actores Administrador del SistemaPrecondiciones Estar logueado al sistema

Poseer los permisos necesariosPost condiciones Se modificaron los datos de los usuarios del sistema.Referencias


1. El Actor ingresa a la sección Administración de Seguridad y elige la opción deUsuarios.

2. El Sistema muestra el formulario para ingresar los datos del usuario a dar de alta(nombre, apellido, usuario, contraseña, si es externo o interno al instituto y lista deperfiles 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 operación.

13/11/2008 99



Curso Alternativo3.1.1. El Actor presiona “Buscar usuarios para modificar”.3.1.2. El Sistema presenta los campos correspondientes a los criterios de búsqueda

de usuarios.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 usuarios que corresponden al criterio

especificado (Ver “Anexo 1”).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

modificación de todos los campos excepto la del nombre de usuario.3.1.8. El Actor realiza los cambios, presiona “Guardar” para hacer efectivos los


Interfases:



Anexo 1

Campos de la tabla del punto 3.1.5Se deben mostrar el nombre, apellido, usuario y además una columna con un icono quepermita seleccionar al usuario para que sea modificado.

13/11/2008 100



Anexos del Análisis

Diagramas de Secuencia de Logueo al Sistemasd Logueo

Cliente Login PersonaSecurityManager

Login()

ValidateUser()

CheckPermission()

Permissions()

ValidatePermissions()

OK or NOK() :Cuase

13/11/2008 101



Diseño

13/11/2008 102



Diseño del Sistema

13/11/2008 103



Diagrama de Dominio

ClienteEn este paquete se encuentra toda la información relativa a un cliente que

representa básicamente en esta organización a un alumno.

class Cliente

«enumeration»Prov inc iaEnum

«enum» BUENOS_AIRES CAPITAL_FEDERAL CATAMARCA CHACO CHUBUT CORDOBA CORRI ENTES ENTRE_RIOS FORMOSA JUJUY LA_PAMPA LA_RIOJA MENDOZA MISI ONES NEUQUEN RIO_NEGRO SALTA SAN_ JUAN SAN_ LUIS SANTA_CRUZ SANT A_FE SANTIAGO_DEL_ESTERO TIERRA_DEL_FUEGO TUCUMAN

«enumeration»TipoDocumentoEnum

«enum» DNI CI LE LC

«enumeratio...SexoEnum

«enum» MASCULINO FEMENINO

«enumeration»TipoResponsableEnum

«enum» PADRE MADRE TUTOR

«enumeration»NivelEnum

«enum» NINGUNO PRIM ARIO SECUNDARIO TERCI ARIO UNIVERS ITARIO

«enumeration»ModalidadEnum

«enum» COMARTEYDISEÑO ECONYGESTION

«enumeratio...TurnoEnum

«enum» MANIANA TARDE

«enumeratio...Divisi onEnum

«enum» A B C R

IBABusinessObjectCurso

- anio: Long- division: DivisionEnum- modalidad: M odalidadEnum- turno: TurnoEnum

IBABusinessObjectDomicilio

- calle: String- codigoPosta l: String- departamento: String- localidad : String- manzana: String- numero: String- piso: String- provincia: P rovinciaEnum- torre: String

IBABusinessObjectDocumento

- emitidoPor: String- numero: Long- pais: String- tipo: TipoDocumentoEnum

IBABusinessObjectPersona

- apell ido: String- documento: Documento- domici lio: Domici lio- fechaNacimiento: Calendar- lugarNacimie nto: String- nacional idad: String- nombre: String- sexo: SexoEnum- telefonos: List<Telefono>- vive: boolean

ResponsableAlumno

- completo: boolean = false- gradoInstruccion: int- nivel Instrucci on: NivelEnum- profesion : String- tipo: TipoResponsableEnum

Clie nte

- cantHerman os: Long- cantHermanosEstab lecimiento: Long- cuenta: Cuenta- curso: Curso- fechaBaja: Calendar- responsables: Set<ResponsableAlumno>- tieneHermanos: boolean- usuario: Usuario

IBABusinessObjectCue nta

- CBUBloqueDos: Long- CBUBloqueUno: Long- nombreBanco: String- persona: Persona- rechazosDebito: L ist<RechazoDebi to>- recibos: L ist<Recibo>- saldo: double- transacciones: List<Transaccion>

IBABusinessObjectTelefono

- descripcion: String- numero: String- persona: Persona

-turno -modal idad-division

-provincia

-tipo

-sexo

-domicil io

-documento

-tipo

-nivelInstruccion

-curso

-persona

-cuenta

-persona

13/11/2008 104



CuentaAquí se reúne la estructura de la cuneta de un cliente. Por un lado tenemos las

transacciones y por otro los debitos rebotados. También se almacenan los recibos

impresos.

class Cuenta

Clie nte

- cantHermanos: Long- cantHermanosEstab lecimiento: Long- cuenta: Cuenta- curso: Curso- estado: EstadoEnum- fechaBaja: Calendar- responsables: Set<ResponsableAlumno>- tieneHermanos: boolean- usuario: Usuario

IBABusinessObjectConsolidacion

- credito: Credito- debito: Debito- monto: Double

Credito

IBABusinessObjectCue nta

- CBUBloqueDos: Long- CBUBloqueUno: Long- nombreBanco: String- persona: Persona- rechazosDebi to: L ist<RechazoDebito>- recibos: L ist<Recibo>- saldo: double- transacciones: List<Transaccion>

Cuota

- anio: Integer- interes: Double- mes: Integer

Debito

IBABusinessObjectDescripcionTransaccion

- descripcio n: String

IBABusinessObjectItemCuota

- detalle: String- monto: Double- porcentaje : Double

«enumeration»ItemCuotaEnum

i d

«enum» ARANCEL_BASE EXTRACURRICULARES EMER_M EDICAS PRORRAT EO_MANT COMPENSACION_COSTOS_LAB INTERES CRED_A_CUENTA OTROS_CONCEPTOS

IBABusinessObjectItemRecibo

- descripcio n: String- monto: Double- recibo: Recibo

IBABusinessObjectPers ona

- apel lido: String- documento: Documento- domicilio: Domicilio- fechaNacimiento: Calendar- lugarNacimie nto: String- nacionalidad: String- nombre: String- sexo: SexoEnum- telefonos: List<Telefono>- vive: boolean

IBABusinessObjectRechazoDebito

- cuenta: Cuenta- fecha: Calendar- monto: Double- referencia : String

IBABusinessObjectRec ibo

- alumno: Cliente- credito: Credito- cuenta: Cuenta- debito: Debito- fecha: Calendar- fechaImpresion: Calendar- items: List<ItemRecibo>

IBABusinessObjectTransaccion

# consolidaciones: L ist<Consolidacion># cubierta: boolean# cuenta: Cuenta# descripcionTransaccion: DescripcionTransaccion# fecha: Calendar# monto: Double# montoRestan te: Double

-persona

-cuenta

#descripcionTransaccion

-cuenta

-alumno

-credito-cuenta-debito

#cuenta

-recibo

-credito -debito

13/11/2008 105



InscripciónEn estas clases se almacena toda la información necesaria para la inscripción

class Inscripcion

IBABusinessObjectCurso

- anio: Long- division: DivisionEnum- modalidad: M odalidadEnum- turno: TurnoEnum

«enumeratio...DivisionEnum

«enum» A B C R

IBABusinessObjectDocumento

- emitidoPor: String- numero: Long- pais: String- tipo: T ipoDocumentoEnum

IBABusinessObjectDomic ilio

- calle: String- codigoPosta l: String- departament o: String- local idad : String- manzana: String- numero: String- piso: String- provincia: P rovinciaEnum- torre: String

IBABusinessObjectEstablecimientoEducativo

- distrito: String- nivel: NivelEnum- nombre: String- numero: String- publico: boolean

«enumeration»EstadoEnum

«enum» NOPROCESADA ACEPTADA RECHAZADA

IBABusinessObjectInscri pcion

- anio: Long- cicloLectivo: Integer- cliente: Cliente- division: DivisionEnum- establecimientoEducativo: EstablecimientoEducativo- estado: EstadoEnum- fechaCreacion: Calendar- fechaProcesada: Calendar- modalidad: M odalidadEnum- turno: TurnoEnum

«enumeration»ModalidadEnum

«enum» COMARTEYDISEÑO ECONYGESTION

«enumeration»Niv el Enum

«enum» NING UNO PRIM ARIO SECUNDARIO TERCI ARIO UNIVERSITARIO

«enumeration»Provinc iaEnum

«enum» BUENOS_AIRES CAPITAL_FEDERAL CATAMARCA CHACO CHUBUT CORDOBA CORRI ENTES ENTRE_RIOS FORMOSA JUJUY LA_PAMPA LA_RIOJA MENDOZA MISIONES NEUQ UEN RIO_NEGRO SALTA SAN_ JUAN SAN_ LUIS SANTA_CRUZ SANT A_FE SANTIAGO_DEL_ESTERO TIERRA_DEL_FUEGO TUCUMAN

ResponsableAlumno

- completo: bo olean = false- gradoInstruccion: int- nivelInstrucci on: NivelEnum- profesion : String- tipo: TipoResponsableEnum

«enumeratio...SexoEnum

«enum» MASCULINO FEMENINO

IBABusinessObjectTelefono

- descripcion: String- numero: String- persona: Persona

«enumeration»TipoDocumentoEnum

«enum» DNI CI L E L C

«enumeration»TipoResponsableEnum

«enum» PADRE MADRE TUTOR

«enumeratio...TurnoEnum

«enum» MANIANA TARDE

Clie nte

- cantHerman os: Long- cantHermanosEstab lecimiento: Long- cuenta: Cuenta- curso: Curso- fechaBaja: Calendar- responsables: Set<ResponsableAlumno>- tieneHermanos: boolean- usuario: Usuario

IBABusinessObjectPers ona

- apellido: String- documento: Documento- domicilio: Domicilio- fechaNacimiento: Calendar- lugarNacimie nto: String- nacionalidad: String- nombre: String- sexo: SexoEnum- telefonos: List<Telefono>- vive: boolean

-modal idad

-estado

-establecimientoEducativo

-division

-nivel

-tipo

-nivelInstruccion

-turno

-provincia

-tipo

-turno-modal idad

-division

-cliente

-documento

-domicilio

-persona

-sexo

13/11/2008 106



Diagrama de Entidad-Relación (DER)En la creación 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 107



Diseño de laArquitectura

13/11/2008 108



Análisis de requerimientos no funcionales y restriccionesA continuación se detallarán una serie de aspectos a considerar para el diseño de la

arquitectura que dé soporte al sistema informático a construir para satisfacer las

necesidades del Instituto Buenos Aires.

PerformanceSe debe garantizar un máximo de 5 transacciones simultáneas con un tiempo de

respuesta no mayor a 10 segundos, de lunes a viernes, de 9:00 a 18:00 Hs. Esta

estimación se cálculo basándose en el análisis y la información provista por el área

de cobros del Instituto. Por tiempo de respuesta se entiende el tiempo desde que

el sistema recibe el pedido de transacción hasta que envía 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 e-

mail, Web Services, otros).

ConcurrenciaEl sistema debe ser concurrente para permitir asegurar la integridad de los datos

y la simultaneidad de operaciones de los distintos usuarios.

TransaccionalidadEn caso de falla, el sistema debe poder deshacer los cambios realizados hasta el

momento para asegurar que los datos queden consistentes.

DisponibilidadEl sistema debe estar disponible el 99% de las veces, y prioritariamente en los

momentos de generación de listado de cobros y momentos de preinscripción.

ModificabilidadExtensibilidad: Se quiere que en el futuro el sistema pueda ser operado por los

clientes del instituto a través del celular (WAP) o telefónicamente a través de un

IVR1. De modo que debería pensarse en alguna interfaz que interactúe con los

futuros módulos.

1 Interactive Voice Response: sistema telefónico que es capaz de recibir una llamada e interactuar con elhumano a través de grabaciones de voz.

13/11/2008 109



Interoperabilidad: La forma de envío de la información de cobro hacia el banco

actualmente es a través de un e-mail. Es probable que en el futuro el banco

decida cambiar esta modalidad por un Web Service. Esta tarea no tendría que

demandar un esfuerzo mayor a 100 horas/hombre para modificar dicho aspecto.

Para hacer frente a esta cuestión se desacoplará y se aislará lo más posible la

interacción con dichas entidades.

SeguridadEl sistema deberá asegurar confidencialidad sobre los datos del usuario. Cada

usuario tiene un nombre único y un password (mayor a 6 caracteres y con

combinación de letras y números) que serán almacenados de manera cifrada.

Los datos con información acerca del usuario deberán 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 podrán acceder a privilegios de usuarios

que posean otro perfil.

El sistema deberá contar con un módulo para poder realizar auditorias y

seguimiento interno del funcionamiento de la aplicación. Para ello deberá proveer

información de las operaciones realizadas en todo momento, por lo tanto, un

módulo del sistema deberá encargarse de registrar las transacciones realizadas.

TesteabilidadDurante la etapa de desarrollo para el testeo de la aplicación se utilizará las

técnicas de testeo unitario y debe garantizarse que el 80% del sistema estará

cubierto por los tests tanto unitarios como de pruebas de usuario.

UsabilidadLa interfaz del sistema podrá visualizarse correctamente utilizando las

resoluciones más comunes. Se podrá minimizar y maximizar la pantalla

conservando las proporciones y la ubicación 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 110



información, un encabezado, un pie de página 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 deberán estar disponible en español.

Debido a que el sistema esta orientado al público en general deberá tener

comentarios descriptivos de la funcionalidad de cada una de las interfaces que

componen el sistema.

PortabilidadLa aplicación deberá poder ser utilizada tanto en principalmente en Firefox, pero

no se descarta su uso con Internet Explorer.

TiempoDebido a que el sistema se debe poner en producción para el próximo ciclo lectivo

y se deben realizar con anterioridad las pruebas para certificar que el sistema

funciona según lo previsto, el desarrollo del proyecto debe finalizarse antes del 15

de Noviembre.

13/11/2008 111



Priorización 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 más 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 información

sensible que solo conoce el usuario (como passwords) de manera cifrada.

Seguridad: Módulo 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 información sensible del usuario deberá viajar encriptada.

Performance: Debe garantizar un máximo de 5 transacciones simultáneas.

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 módulos de testeo unitario para minimizar los

miedos al cambio ante futuras modificaciones.

Aunque los demás 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 112



Arquitectura del sistema

Optamos por una combinación de varias configuraciones estándar de estilos

arquitectónicos.

Tanto el dominio de la aplicación como la arquitectura que de soporte al mismo,

serán modelados haciendo uso de la orientación a objetos. Se ha optado el mismo dado

que el dominio tiende a ser más 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 aplicación.

Dado que la aplicación se ejecutará en un servlet container que soporte tecnología

J2EE, se aprovechará la capacidad de definir filtros que realicen un primer proceso a los

pedidos solicitados por los usuarios a través de los browsers. Estos procesos pueden ser

tales como comprobaciones de seguridad, apertura de sesiones y transacciones para

interactuar con la base de datos.

TecnologíaEl desarrollo del sistema se realizará haciendo uso y aprovechando las capacidades

de la tecnología J2EE (Java To Entreprise Edition). Principalmente la elección de dicha

tecnología se debe a que el equipo de desarrollo destinado a la realización del proyecto

posee sólidos conocimientos de la misma, permitiendo así cumplir con la restricción de

tiempo que se nos ha impuesto. Además 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 aplicación Server-Side:

Requerimientos mínimos para el cliente de la aplicación.

La lógica del dominio reside completamente en el servidor.

Posibilidad de realizar mayores controles dado que la lógica del negocio reside

en el Server.

Relacionado con el punto anterior, posibilidad de realizar múltiples tipos de

clientes (Ej: cliente web, cliente desktop, web service).

La aplicación puede ser dividida y distribuida en múltiples procesadores para

realizar balanceo de carga permitiendo aumentar la disponibilidad,

escalabilidad y la recuperación ante fallos.

Algunas desventajas de una aplicación Server-Side:

Incompatibilidad de versiones de los clientes, generalmente browsers.

13/11/2008 113



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.

EstructuraLa arquitectura estará estructurada en capas dado que el tipo de sistema que

soportará es una aplicación web (y no se descarta de otros tipos de clientes en el futuro),

por lo que es deseable una separación entre los componentes de la capa de presentación,

persistencia, dominio y aplicación.

En la arquitectura propuesta podemos identificar 3 capas:

Presentación Negocio Persistencia

Como a cada capa se le define la/s responsabilidad/es que le atañen, se aumenta el

grado de desacoplamiento dado que el conocimiento y la comunicación 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 separación brinda mayor flexibilidad

ante futuro cambios intra-capa, a costa de quizás, añadir mayor complejidad a la

solución 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 persistirán o presentarán los datos

procesados, cuestión altamente deseable dado que está previsto que los datos sean

obtenidos/guardados tanto a través de una base de datos como de web services en

un futuro.

Como una desventaja podemos mencionar que si bien la separación 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 cuestión se relaciona

fuertemente con la modificabilidad del sistema e implica que si existe la necesidad de

realizar una refactorización en alguna de dichas clases, probablemente se vean

afectadas también la capa de presentación y de persistencia.

Aunque el punto anterior sea considerado desfavorable, hemos decidido adoptar este

estilo arquitectónico dado que creemos que las ventajas son mayores. Podemos

mencionar como ventajas:

o Amplia difusión en el mercado actual.

o Amplia gama de frameworks que dan soporte a cada una de las capas

o Posibilidad de paralelización y asignación de tareas de desarrollo por capas.

13/11/2008 114



Estas tres ventajas permiten un tiempo de desarrollo menor dado que al existir

amplio soporte, documentación y experiencias de usuarios de los frameworks usados

en cada capa permite resolver eventuales problemas más rápidamente. Además

facilita la incorporación de programadores dado que muchos ya han usado los mismos

en otros trabajos.

Como la interacción del usuario con el sistema se realizará a través de la capa de

presentación, esto permite tener acotados:

o Los puntos de seguridad: permitiendo facilitar el control de autenticación y

autorización del usuario.

o 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.

o Los puntos de auditoria: permitiendo registrar las transacciones realizadas por

el cliente.

Para resumir lo expuesto en esta sección, se presenta a continuación un esquema

de alto nivel de la arquitectura propuesta.

Capa de presentación

ObjetivoPermitir al usuario a través de la UI (en este caso un browser) interactuar con la

aplicación modelada en la capa de negocio. Así mismo permite a la capa de negocio

mostrar y controlar el flujo de la información que se presentará a través de esta capa.

Permite ver los resultados de los procesos efectuados.

Tiene la responsabilidad del manejo de validación de datos ingresados,

presentación de los resultados, lo que permite mantener un aspecto visual consistente, y

manejo de errores. También resuelve la transformación de los datos ingresados en datos

del dominio del negocio y la transformación de resultados del negocio a datos

presentables al usuario.

NegocioBrowser

Application Server J2EE

Persistencia

Server Side

Presentación

Client Side

DB

13/11/2008 115



ComponentesPara esta capa se evaluaron 2 frameworks de presentación: Flex y GWT.

A favor de Flex podemos mencionar que posee características novedosas, las

interfaces de usuario son más estilizadas, es fácil 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 máquinas no tan modernas como las que posee actualmente el instituto, lo cual es un

gran punto en contra debido a los acotados recursos económicos que dispone el instituto

para financiar el proyecto. Además gran parte de los mejores componentes visuales

existentes no son gratuitos para uso comercial.

Si bien no se descarta que en una segunda versión se pueda utilizar Flex, creemos

que en esta primera versión no es recomendable su utilización.

Reflexionando hemos decidido que para el desarrollo de esta capa usaremos GWT

debido a que posee las siguientes características, cubriendo los requerimientos del

sistema:

Es posible implementar el patrón conocido como MVC (Model View Controller)

donde el Model sería la capa de negocio, el View serían las páginas codificadas en

Java y luego traducidas a JavaScript por GWT y el Controller sería la lógica

implementada en un Dispatcher que permite determinar el flujo de navegación de la

aplicación.

Alta compatibilidad nativa para Internet Explorer y Firefox si tener que realizar la

misma funcionalidad a través de distinto código 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 código Java y no en HTML y JavaScript.

Enfatiza la reusabilidad de componentes.

Permite realizar llamadas asincrónicas al Server.

Programación de la interfaz de usuario en lenguaje orientado a objetos y más

precisamente en Java.

Alta difusión en el mercado.

Alto grado de soporte (manuales, tutoriales, ejemplos, comunidad de

desarrolladores, etc.)

La mayoría de los desarrolladores web lo conocen y están 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 116



Varias de las ventajas del uso de GWT mencionadas en los puntos anteriores nos

permiten principalmente acortar el tiempo de desarrollo.

Además GWT posee características de manejos de mensajes de errores, soporte

para layouts, internacionalización y otras cuestiones que permiten desarrollar fácilmente

una interfaz de usuario que soporte las características de usabilidad definidas como

requerimientos.

Alternativas acerca de los tipos de clientes para interfaz gráficaDentro de las decisiones a tomar sobre la capa de presentación están si se optará

por un cliente pesado (del estilo RIA) o liviano (a través de un browser) dado que dicha

elección condicionará subsiguientes decisiones y qué interfaz expone para realizar la

integración 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 más 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 información sensible del negocio

sea manejada y/o resida en los clientes, sino que son manejadas en el servidor de la

aplicación de manera centralizada minimizando la posibilidad que un proceso de negocio

se vea afectado por prácticas 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 y extensibilidad para realizar futuras

modificaciones y que el cambio deba ser efectuado en un solo lado. Claramente también

está asociado a la seguridad como se mencionó anteriormente.

Capa de negocio

ObjetivoLa 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 interacción con el cliente

primariamente es a través de la Web, no se descarta en un futuro agregar otras

13/11/2008 117



interfases de usuario como por ejemplo consulta de reservas telefónicamente. De esta

forma, la capa de negocio debe exponer una interfaz que sea capaz de dialogar con la

capa de presentación actual y con algún otro módulo futuro, intentando alcanzar un alto

grado de modificabilidad. Los cambios serán menores y más sencillos si la capa sólo

maneja aspectos del negocio.

ComponentesEsta capa hace uso del servicio de persistencia para guardar la información ingresada

por el usuario y procesada por el sistema. También para obtener datos para que

sean informados al usuario.

También se hace uso de la capa de presentación para mostrar la información

necesaria y para que el cliente pueda interactuar con el sistema. En esta parte, la

capa de negocio actúa como proveedora de datos para la capa de presentación.

Dado que la seguridad es uno de los requerimientos importantes que debe abordar la

arquitectura se aplicará una táctica 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 aplicación el framework de

seguridad llamado Acegi en conjunto con Spring, el cual nos permite mantener la

lógica de negocio libre de código 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

ObjetivoProveer del soporte necesario para poder almacenar la información manejada por la

aplicación y recuperarla para su procesado durante la vida útil de la aplicación.

Para poder proveer dicho soporte ésta capa debe tener una interfaz apropiada con

la capa del dominio posibilitando el fácil acceso a los datos que pueden estar

almacenados en distintos tipos de repositorios.

ComponentesPara poder cumplir con el objetivo de esta capa, es necesario definir 4 cuestiones

fundamentales:

Medio físico donde se almacenará la información.

Forma de comunicación entre la aplicación y el medio físico de almacenamiento.

Tecnología de conversión/adaptación de los datos al ambiente de objetos (de ser

necesario).

13/11/2008 118



Interfaz para el acceso a dicha capa desde el dominio de la aplicación.

Enunciados los puntos anteriores pasaremos a explicar la estrategia de solución

adoptada para la resolución de los mismos:

Como medio físico, para la arquitectura descrita, se propone el uso de un motor

de base de datos relacional. Se ha optado por esta solución dado que en el

mercado actual existen RDMS con amplio soporte, altas prestaciones, priorizando

la escalabilidad de los datos, su rápido acceso, su disponibilidad y

transaccionalidad; cuestiones altamente prioritarias como requerimientos no

funcionales.

Otro factor importante es la necesidad de que el sistema esté en producción para

el 15 de Noviembre, por lo cual se necesita disponer de recursos humanos con

conocimientos en la tecnología utilizada en el menor tiempo posible, y

actualmente, al estar más expandidos los motores de base de datos relacional, es

más factible conseguir recursos en ésta tecnología.

Para resolver la comunicación se hará uso de Drivers JDBC (Java Database

Connectivity) correspondiente a la base de datos seleccionada. La API de JDBC

forma parte de la especificación J2EE y provee conectividad entre la aplicación

Java y la base de datos independientemente de cuál sea esta última dado que

existen diversas implementaciones (Drivers) de dicha API.

Dado que estaremos usando una base de datos que organiza la información de

manera relacional y que se ha adoptado modelar el dominio a través de la

orientación de objetos (la cual se puede pensar como una estructura de grafos)

necesitamos de algún mecanismo que permita realizar la adaptación 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 aceptación en el mercado, soporte para las base de datos más

conocidas usando Drivers JDBC, la gran cantidad de puntos de extensión 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 cuestión. El mismo es de desarrollo propio.

Diagrama de ComponentesA continuación mostraremos la composición de componentes de arquitectura y la

interacción entre los mismos:

13/11/2008 119



cmp Diagrama de componentes

Framework Presentación

GWT 1 .5.2 Componentes Propios

Framework Persistencia

Hibernate 3.3.1 JDBC MySQL

Browser con soporte para Jav aScript (Firefox o IE) Base de Datos (MySQL 5.0.67)

Dominio IBA Interfaz EntidadBancaria«use»

«use»«use»

«use» «use»

Diagrama de DespliegueA continuación mostraremos cómo es la distribución 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

Client Side Server Side

Sun JVM 1.6 Update 6

«Apache Tomcat 6.0.18»Application Serv er

IBA.war

+ Arch. Configuración+ Estilos+ Imágenes

«Java 1.6 Update 6»Dominio

«Hibernate 3.3.1»Persis tencia

«MySQL 5.0.67»Database Serv er

IBA S chema

«GWT 1.5.2»Presentación

«Firefox o IE»Brow ser

JavaS cript

CSS

HTML

«HTTP,HTTPS»

«JDBC»

13/11/2008 120



Conceptos transversales

A continuación se definirán conceptos presentes a lo largo de toda la aplicación y se

enunciará la postura a tomada.

LoggingEl concepto de Logging permite poder trazar los eventos que ocurren

durante la ejecución de la aplicación, facilitado la tarea de desarrollo,

corrección de errores y mantenimiento, posibilitando reducir los tiempos

dedicados al desarrollo. Éste punto en conjunto con otras cuestiones

permitirán 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 implementación a

utilizar. En nuestro caso, la implementación a usar será el ampliamente

reconocido Log4J.

Se ha decidido el uso de esta implementación dado que no solo será

usada por la aplicación, sino que también los frameworks usados por la

arquitectura usan y recomiendan la misma.

Además su configuración es muy sencilla y permite efectuar diferentes

niveles de logging, pudiendo definir luego el nivel deseado de detalle.

Otra característica importante es que se puede configurar distintas

salidas, como un archivo, e-mail, base de datos, ftp y muchos otros. También

provee una interfaz para poder definir una implementación propia.

SeguridadPara 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 detallarán a continuación hemos decidido hacer uso del

framework de autenticación y autorización llamado Acegi Security. Su

adopción 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 configuración y variados puntos de

extensión. Permite diferentes formas de autenticación (HTTP Basic, HTTP

Digest, certificados X509, LDAP) y autorización sobre todos los HTTP Request

13/11/2008 121



de la aplicación y sobre cada objeto del dominio en particular permitiendo

definir una lista de control de accesos (ACL, Access Control List).

Además se integra con el framework de aplicación denominado Spring

(también con un alto nivel de aceptación en el mercado) para cuestiones de

Inyección 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.

Además el equipo de desarrollo destinado a la realización del proyecto posee

sólidos conocimientos de éstos frameworks.

ExcepcionesSe utilizará tanto para el desarrollo de la aplicación como de la

arquitectura, casi en la totalidad de los casos, excepciones no chequeadas,

reservando el uso de las chequeadas para casos muy específicos y donde sea

necesario.

Dicha elección fue tomada en base a que las excepciones no chequeadas

proveen más flexibilidad dado que no es obligatorio definir en la firma de los

métodos que excepciones pueden llegar a ser lanzadas y que deban ser

tratadas. Además aumenta la declaratividad y legibilidad del código.

También se usará una jerarquía de excepciones para agrupar en

excepciones de negocio, de persistencia, de presentación, de seguridad y de

programa. Esta separación permite que puedan ser tratadas (por ejemplo en

un filtro) de forma distinta en el caso de que la excepción se propague y nadie

la trate permitiendo generar mensajes más descriptivos para el usuario.

Testeo UnitarioSe usará la técnica de testeo unitario tanto para los componentes de la

arquitectura como para los de la aplicación.

Podemos mencionar como ventajas de su uso y aplicación 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 documentación del sistema.

Permite aumentar la claridad del código dado que los tests y sus

comprobaciones están separados de la lógica del negocio.

13/11/2008 122



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 código y la robustez del sistema.

Si bien la realización 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 más estable y menor en el tiempo que

si no se realiza testeo unitario.

La implementación que usaremos será JUnit dada su alta difusión y

aceptación en el mercado. Además el IDE a usar (Eclipse) posee integración

nativa con dicho framework.

AuditoriaA través de un servicio se realizarán 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 través de un componente propio.

13/11/2008 123



Software Configuration Management (SCM)

Sistema de Control de VersionesUsaremos como software de administración de versiones el Subversión 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 código, 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 través 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 envían sólo las diferencias en ambas direcciones (y no se envían siempre al

servidor los archivos completos).

Posibilidad de uso a través de HTTP y HTTPS, con el uso de este último, se permite

no ser filtrados su uso por proxies corporativos.

Posibilidad de agregar módulos de extensión para diversas cuestiones tanto

administrativas como de uso.

Utilizaremos Subversive como GUI, un plugin que integra Subversión (SVN) al IDE

Eclipse.

Herramienta de Software Project ManagmentPara realizar la administración del código del software y del proyecto, se utilizará

una herramienta de gestión y comprensión de proyectos Java denominada Maven en su

versión 2.0.9. Esta herramienta fue desarrollada por Apache Foundation y es Open

Source.

Esta herramienta permite automatizar la gestión de dependencias externas

necesarias para el funcionamiento del sistema. Además permite generar

automáticamente el archivo .war de la aplicación para que pueda ser desplegado en el

servidor.

Una de sus características principales es que permite agregarle nuevas

funcionalidades para facilitar cuestiones de gestión del proyecto de software a través de

plugins.

13/11/2008 124



Herramientas de colaboraciónPara el manejo del conocimiento vamos a usar los servicios de “Assembla”

(www.assembla.com). Assembla es una organización que provee de una basta cantidad

de herramientas de colaboración orientadas a mejorar el desarrollo de software, las

comunicaciones y el equipo de trabajo. Hace más fácil la colaboración y 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 características profesionales.

Entre las herramientas ofrecidas podemos mencionar:

SVN: proveen un repositorio para el versionados de código y documentos sin

límites 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 ningún costo y son accesibles vía

cualquier browser.

Code Coverage (Cobertura del código 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 análisis del

“code coverage” (cobertura del código). La misma descubre las secciones del código que

no están 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 integración al entorno de

desarrollo es directa.

Bug Tracking, Issue Tracking y Project ManagementPara realizar estas tareas utilizaremos la herramienta “Trac” (provisto por

www.assembla.com) dado que la misma hace que dicho proceso sea más fácil para el

equipo.

http://www.assembla.com).

http://www.assembla.com)

13/11/2008 125



Algunas características remarcables de la herramienta son:

Permite manejar los bugs, tareas, mejoras o cualquier issue.

Tiene una interfaz de usuario limpia y poderosa de fácil entendimiento para

los usuarios funcionales y para los usuarios técnicos.

Permite relacionar procesos de negocio a workflows personalizables.

Fácil de extender e integrar con otros sistemas (E-Mail, RSS, Excel, XML y

Sistemas de Control de Versiones)

Alta configurabilidad de las opciones de comunicación.

13/11/2008 126



TecnologíaSe desarrollara mediante la tecnología J2EE (Java To Enterprise Edition), esto lo

seleccionamos porque cumple las especificaciones y pruebas de conformidad que

permiten la portabilidad de las aplicaciones a través 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 mayoría de los procesos de la aplicación en el servidor, haciendo menor el

requerimiento de hardware del cliente. Con este tipo de arquitectura se permite que una

simple aplicación soporte simultáneamente clientes con distintos tipos de interfaces.

Además permite escalabilidad, confiabilidad, disponibilidad y recuperabilidad.

Aplicaciones basadas en el servidor pueden ser divididas y distribuidas en múltiples

procesadores.

Maquina VirtualVamos a utilizar la JDK (Java Development Kit) versión 1.6 Update 6 la cual

además de poseer la JRE (Java Runtime Enviroment) de la misma versión, incluye

herramientas específicas orientadas al desarrollador.

La JRE es la implementación de Sun Microsystems de la JMV (Java Virtual Machina)

sobre donde se ejecutará la aplicación.

Application ServerUtilizaremos como Application Server Apache Tomcat versión 6.0.18. El cual es

OpenSource, multiplataforma, consume pocos recursos y es de fácil instalación y

mantenimiento.

Repositorio de DatosUtilizaremos la Base de Datos MySQL Community Server versión 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 configuración e instalación, por dar soporte a multiplataformas y

principalmente por su baja probabilidad de corromper los datos debido a que es

fundamental para la aplicación mantener lo datos consistentes.

IDE para el Entorno de DesarrolloSe utilizará Eclipse 3.4 con WTP (Web Tools Platform) 2.0 con los plugins para los

productos mencionados en la sección “Software Configuration Management”.

13/11/2008 127



Se elige este IDE dado que provee una muy buena interfaz gráfica, es

multiplataforma, no se instala, es Open Source, permite agregarle funcionalidad a través

de plugins, entre otras.

13/11/2008 128



Normas de codificación

El motivo de esta sección es proveer las normas básicas de codificación y

convenciones para obtener los siguientes beneficios:

Incrementar la legibilidad

Reducir el esfuerzo de mantenimiento

Facilitar la reusabilidad y la compartición de código

Los estándares que usaremos son los que define Sun como convenciones de

codificación para Java. Los mismos se encuentran detallados en un PDF provisto por Sun

en la siguiente dirección: 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 comprobación del

cumplimiento de las normas de Sun (o de las personalizadas, dado que se puede configurar

los estilos de codificación) en el código de la aplicación.

Para la documentación del código se usará la norma de documentación estándar para

lenguaje Java denominada JavaDoc (http://java.sun.com/j2se/javadoc/), dado que es posible

ser manejada desde el Eclipse debido a su excelente integración. Además permite generar

documentación automática sobre las clases, interfaces, relaciones, atributos, métodos y

parámetros con sus correspondientes explicaciones.

http://java.sun.com/docs/codeconv/CodeConventions.pdf

http://eclipse-cs.sourceforge.net/

http://checkstyle.sourceforge.net/).

http://java.sun.com/j2se/javadoc/

13/11/2008 129



Documentación

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 (lógico y físico)

y diagrama de clases.

Para la documentación del código utilizaremos JavaDoc.

Se documentarán los casos de pruebas utilizados.

También realizaremos prototipos de interfaz de usuario.

13/11/2008 130



Administración de riesgos arquitecturales

Utilizaremos la clasificación de los atributos de calidad para dividir los riesgos.

PerformanceLos principales problemas de performance que puede presentar la aplicación se

atribuyen a dos factores: la arquitectura en capas y la gran cantidad de conexiones con

otros sistemas.

El primero genera que la información de una operación sea convertida varias veces,

para saltar de capa en capa, creando una carga adicional para el sistema en general.

Esto se ve más que nada en los Web Services y en la capa de Presentación. En el caso de

que la aplicación sufra por este motivo, como primera instancia se debería analizar la

posibilidad de aumentar la capacidad del hardware. Si no se resuelve, sería necesario

plantear una replicación 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

solución para esto sería mucho más compleja ya que no tenemos contacto con el sistema

al cual nos vamos a comunicar. Una solución sería analizar si es posible realizar algunas

de las transacciones off-line o asincrónicas para bajar la carga de la conexión y manejar

la persistencia de nuestro lado.

DisponibilidadEn este punto, el mayor riesgo es la rotura del servidor, ya que solo hay uno.

Teniendo en cuenta que todo termina dependiendo de esta máquina la convierte en un

punto débil del sistema. La solución sería tener otro servidor para poder derivar el

trabajo mientras se intenta levantar el servidor caído.

También, 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

compañías que pierdan la conexión al sistema.

ModificabilidadEl sistema no presenta grandes riesgos a nivel de modificabilidad a menos que por

problema de performance o algún otro, el diseño en capas quede obsoleto. La pérdida en

este caso es el consumo de tiempo para la reestructuración del mismo.

13/11/2008 131



SeguridadAl utilizar como capa de presentación una interfase web estándar, el uso de

tecnologías de encriptación esta reducida a lo que soporten los navegadores actuales.

Para solucionarlo, habría que cambiar la capa de presentación.

Para hacer frente a todo los problemas relacionados a hacking, cracking, sniffing,

etc. se tendrán en cuenta normas fundamentales y estándares en el mercado tendientes

a minimizar la ocurrencia de estos posibles ataques.

TesteabilidadLa aplicación no tendrá riesgos de testeabilidad si se prosigue correctamente con su

plan de desarrollo.

UsabilidadEl 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 diseño y en el

último de los casos se desarrollarán clientes pesados.

13/11/2008 132



Diagrama del Framework de la Capa de Persistencia

Para realizar la persistencia de los datos manejados por la aplicación será necesario

la creación y uso de un framework propio. Para ello proponemos un esquema de

arquitectura preeliminar.

El mismo proveerá abstracciones sobre las clases más 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 más automática

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

aplicación que se está desarrollando, para ello se debe redefinir el método

registerClasses() y dentro del mismo llamar a register() y como parámetro pasarle el

Class de la subclase de BusinessObject a registrar. Veamos la estructura de lo que

acabamos de enunciar:

class ClassCatalog

ClassCatalog

+ register() : void+ registerClasses() : void

IBAClass Catalog

+ registerClasses() : void

OtherAppClassCatalog

+ registerClasses() : void

BusinessObject posee métodos que permite un manejo del guardado/borrado de

objetos en la DB (en realidad de los datos) de una forma que es más acorde al

paradigma de objetos.

Una de las clases más usadas de este framework es PersistenceService dado que a

través de ella es que construyen los pedidos (queries) para realizar consultas a la base

de datos. Dicha construcción retorna un SearchCriteria al cual le podremos agregar las

restricciones necesarias según sea el caso y definir el orden de los datos a obtener.

13/11/2008 133



Si bien PersistenceService define métodos para el guardado y borrado de objetos,

es conveniente que esto sea realizado por los mismos BusinessObjects a través de los

métodos provistos por BusinessObject.

A continuación esquematizaremos la estructura básica y con las clases más

importantes del framework de persistencia:

class Framework

Sess ionDatabase Session

+ beginTransact ion() : void+ commitTransaction() : void+ endTransacti on() : void+ getHibernateSession() : void+ rollbackTransaction() : void

DatabaseTransaction

+ commit() : void+ rollback() : void

Transaction

CriteriaSearchCriteria

+ add() : void+ addOrder() : void+ createCriteria() : void+ findUnique() : void+ li st() : void

PersistenceServ ice

+ delete() : void+ getCriteri a() : void+ save() : void

«interface»Persistible

+ delete() : void+ save() : void

Busines sObject

+ delete() : void+ save() : void

Usua rio TipoDocumento

Hibe rna teFramework

«use»

«use»

«use»

1 1 1

1

DAOs (Data Access Object)Una práctica común es usar el patrón 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 mayoría de las comunicaciones que se realizan con ella. Este

patrón es realmente muy sencillo y no posee una estructura determinada ya que es más

bien un concepto. Una forma de implementar este patrón es definiendo métodos de clase

(o static, en nomenclatura Java) para permitir su fácil acceso. Ej:

13/11/2008 134



# UsuarioDAO

public static Usuario getByUsuario(String username) {

[…]

}

public static List<Usuario> getAll() {

[…]

}

Además 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 práctica permite que el código

quede más claro, entendible y pueda ser reutilizado en varios casos de uso que requieran

la misma información (Ej: lista de tipos de documentos, buscar una notificación por su

código 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.

También hemos ideado un esquema y una abstracción que recomendamos usar

para estandarizar la forma de acceder a la base de datos para realizar consultas.

A continuación 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>

+ getCriteria() : Criteria+ getCriteria(String) : Criteria+ getQuery(String) : Query+ getType() : Class<T>+ list(Criteri a) : List<T>+ list(Query) : List<T>+ uniqueResult (Query) : T+ uniqueResult(Criteria) : T

AlumnoHibernateDAO<Alumno>

+ getType() : Class<T>

«interface»AlumnoDAO

+ getAll () : List<Alumno>+ getByDocumento(Long, String) : Alumno

Alumno

- apell ido: int- nombre: int- nroDocumento: int- tipoDocumento: int

13/11/2008 135



Diagrama del Framework de la Capa de Presentación

Para facilitar la construcción de las interfaces gráficas de usuario hemos

considerado necesario generar unas abstracciones sobre la base GWT (Google Web

Toolkit), el framework de presentación elegido para usar.

Para ello debemos diferenciar los 2 lados posibles: cliente y servidor.

Para el lado del cliente, se han creado una abstracción para las páginas (GwtPage),

a su vez, como un caso de uso puede contener varias páginas se ha creado un

contenedor de páginas (GwtPageGroup). Como la aplicación tendrá varios casos de uso

que deberán ser coordinados y gestionados, es que surge la necesidad de crear un

controlador (GwtController) que administre los grupos de páginas y el contexto del

cliente.

Para el lado del servidor, se ha creado un Servlet customizado (GwtBaseServlet)

basado en el Servlet estándar 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 abstracción para que los casos de uso se concentren en la lógica del

mismo sin tener que preocuparse por la gestión del mismo.

A continuación esquematizaremos en un diagrama de clases los aspectos más

importantes del framework de presentación.

13/11/2008 136



13/11/2008 137



Para comprender mejor el framework de presentación y cómo es su utilización el

proyecto, expondremos un diagrama de clases con un ejemplo de uso del mismo:

13/11/2008 138



Informes de

Avance

13/11/2008 139



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 ysegundo cuatrimestre.

Brief acta de proyecto con el formato solicitado.

Acta de proyecto con el formato solicitado.

Documento de análisis riesgos

Definición de los roles necesarios.

Análisis de factibilidad técnica y operativa.

En ProcesoDefinir las fechas para las tareas del segundocuatrimestre.

Completar el acta de proyecto.

PendienteEmpezar la realización del análisis de los casos deuso.

Completar la documentación.

Problemas Presentados

Problema Detalles

Disponibilidad de tiempo Se nos hizo complicado avanzar demasiado conel proyecto dado que fue una semana complicadalaboralmente para todos los miembros del grupo.

13/11/2008 140




Tareas


Gantt para primer cuatrimestre.

Brief Acta de Proyecto.

Acta de Proyecto

Factibilidad

Gantt reorganizado según lo acordado en laanterior revisión.

Acta de proyecto corregido.

Documento de análisis riesgos

Definición de la Matriz de Roles - Entregables.

Análisis de funcionalidad “Generar listado dedébitos para el banco” del módulo “Gestión deCobranzas”.

En ProcesoConfección de las especificaciones de lasfuncionalidades del módulo “Gestión deCobranzas”.

Ajustar fechas en la planificación del segundocuatrimestre

PendienteRealizar próximamente la factibilidad económica.


Problema Detalles

Confección del Documento de Riesgos Si bien no es un problema en si, confeccionamosel documento de riesgos pero aun no tenemos elformato solicitado por la cátedra.

13/11/2008 141




Tareas


Gantt Completo.


Acta de Proyecto

Factibilidad


Primeros Caso de Uso

Documento de análisis riesgos corregido

Matriz de Roles – Entregables corregido

Casos de Uso corregidos

Factibilidad Económica

En ProcesoCompletar y Refinar los documentos de los casosde uso.

PendienteRealizar los diagramas de secuencia yactividades.


Problema Detalles

Definición de requerimientos Nos dimos cuenta que algunos requerimientos noestaban bien planteados.

13/11/2008 142




Tareas


Gantt Completo.


Acta de Proyecto

Factibilidad


Casos de Uso

Nueva revisión de los Casos de Uso

Estructura del equipo corregida

En ProcesoCompletar y Refinar los documentos del análisis.

PendienteEmpezar con la etapa de diseño.


Problema Detalles

13/11/2008 143




Tareas


Gantt Completo y actualizado.


Acta de Proyecto

Factibilidad


Casos de Uso

Documentación del análisis

Documentación del diseño

Correcciones varias de los casos de uso

Documentación completa del 1° cuatrimestre

CD con la documentación en formato digital

En ProcesoTerminar de realizar los prototipos de lasinterfases de usuario.

PendienteRealizar el video comercial.

Empezar a codificar la solución.


Problema Detalles

13/11/2008 144




Tareas


Documentación completa del 1°cuatrimestre

CD con la documentación enformato digital

Documentación completa del 1° cuatrimestrecorregida (enviada por e-mail a los profesores acargo del proyecto)

Gantt actualizado con las fechas de entrega delvideo y de la presentación comercial

En ProcesoCodificación de la arquitectura de la aplicación

Codificación del módulo de generación einterpretación de los archivos usados por laentidad bancaria

Realización del video comercial del producto

PendienteArmar la presentación comercial.


Problema Detalles

13/11/2008 145




Tareas


Documentación completa del 1°cuatrimestre

CD con la documentación enformato digital

Exposición de la presentacióncomercial.

Video comercial del producto

Armado de la arquitectura de la aplicación.

Codificación del módulo de generación einterpretación de los archivos usados por laentidad bancaria

Utilitario de generación e interpretación de losarchivos usados por la entidad bancaria.

Correcciones surgidas en la reunión del15/08/20008.

En ProcesoDesarrollo del Módulo de Preinscripción

Desarrollo del Módulo de Administración dedatos del alumno.

PendienteArmar la presentación comercial.


Problema Detalles

13/11/2008 146




Tareas


Documentación completa del 1°cuatrimestre corregida (enviada pore-mail a los profesores a cargo delproyecto)

Gantt actualizado con las fechas deentrega del video y de lapresentación comercial

Módulo de Preinscripción

Módulo de Modificación de datos del Usuario.


En ProcesoMódulo de validación de ingreso al sistema.

Módulo de administración de seguridad (usuarios,perfiles y permisos).

Actualización de la documentación.

PendienteCorrección del tamaño de la aplicación.

Ver la posibilidad de subir la aplicación para quesea accedida por la cátedra.


Problema Detalles

13/11/2008 147




Tareas



Módulo de Modificación de datosdel Usuario.

Módulo de validación de ingreso al sistema.

Módulo de administración de seguridad (usuarios,perfiles y permisos).


En ProcesoCodificación del módulo de generación dearchivo de débitos a enviar al banco

Codificación del módulo de proceso de archivocon el resultado de los débitos recibidos desde elbanco.

Ajuste de la documentación.

Generación de los manuales del sistema.

PendienteContinuar el desarrollo del módulo de cobranza.

Continuar el desarrollo del módulo de situaciónvía Web.

Agregado de estadísticas de preinscripciones.


Problema Detalles

13/11/2008 148




Tareas



Módulo de Modificación de datosdel Usuario.

Módulo de validación de ingreso alsistema.

Módulo de administración deseguridad (usuarios, perfiles ypermisos).

Módulo de Gestión de Cobranzas

Documentación del proyecto

Manuales de usuario

Manuales de instalación y configuración

CD que contiene el sistema y la documentaciónen formato digital

Exposición presentando la versión 1.0 del sistemaen funcionamiento

En Proceso

Pendiente


Problema Detalles

13/11/2008 149



Minutas de

Reunión

13/11/2008 150



Minuta de reunión del día 09/05/2008

i) ASISTENTES

Grupo 507: Castro, Gabriel EdgardoD’Aloia, Martín MiguelGarcía Pérez, Jorge LuísGonzález Lorenzo, Sebastián

Cátedra de Proyecto: González, María CeciliaSalem, GabrielaSuasnabar, María Julia

ii) OBJETIVO DE LA REUNIÓN

Realizar una revisión del estado del proyecto y del avance del mismoRevisar la documentación generadaRevisar y ajustar la planificación

iii) TEMAS TRATADOS

Se revisó la documentación, se definieron los ajustes a realizar y los avances a solicitarpara la próxima entrega.

iv) PRÓXIMOS PASOS

Se nos realizaron las siguientes observaciones a modificar para la siguiente reuniónplanificada:

Realizar la matriz de asociación de Roles con EntregablesPlanificar la presentación comercial para el segundo cuatrimestreAgregar la capacitación del equipo de trabajo a la planificaciónAgregar tareas de configuración de entorno para desarrollo a la planificaciónCambiar lo que definimos como “Caso de Uso XYZ” por “Funcionalidad XYZ”Identificar los entregables dentro de la planificación con un formato que sobresalteCambiar en el Acta de Proyecto en donde dice ETAPA por FASE (Ej.: en Resultados decada Etapa)Poner los entregables del diseño a nivel de módulo.

v) PRÓXIMA REUNIÓN

Se planificó para ser realizada el día Viernes 23 de mayo de 2008Se entregará el Análisis de los Riesgos, la matriz de Roles-Entregables, el Análisis dela funcionalidad de Generación de listados de débitos para el banco, la planificaciónreorganizada y el acta de proyecto corregida.

13/11/2008 151




i) ASISTENTES




Realizar una revisión del estado del proyecto y del avance del mismoRevisar la documentación generadaRevisar las correcciones realizadas

iii) TEMAS TRATADOS

Se revisó la documentación, se definieron los ajustes a realizar y los avances a solicitarpara la próxima entrega.

iv) PRÓXIMOS PASOS


Corregir las responsabilidades de la matriz de asociación de Roles con Entregables.Corregir los Casos de Uso.Corregir el Análisis de Riesgos y realizar una matriz de asociación.Corregir la fecha del Análisis de Factibilidad en la planificación del proyecto.


Se planificó para ser realizada el día Viernes 06 de Junio de 2008Se entregará el Análisis de los Riesgos corregido, la matriz de Roles-Entregablescorregida, la corrección de los casos de uso y la factibilidad económica.

13/11/2008 152




i) ASISTENTES





iii) TEMAS TRATADOS

Se revisó la documentación, se definieron los ajustes a realizar y los avances a solicitarpara la próxima entrega.Se han llevado la documentación entregada en la reunión para ser revisada en detalle yefectuarnos las correcciones a realizar para la próxima entrega.

iv) PRÓXIMOS PASOS


Corregir la estructura propuesta del equipo para realizar el proyecto y sus roles.Avanzar con la definición de los Casos de Uso.


Se planificó para ser realizada el día Viernes 20 de Junio de 2008Se entregará una nueva revisión de los casos de uso, la corrección de la estructuradel proyecto y el avance en la planificación.

13/11/2008 153




i) ASISTENTES





iii) TEMAS TRATADOS


iv) PRÓXIMOS PASOS


Enviar por e-mail antes de la próxima reunión el proyecto completo a todos lostutores del grupo.Hacer un único documento por módulo y no por caso de uso.Realizar los diagramas de actividad y secuencia en los casos necesarios.Empezar a realizar la etapa de diseño 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 algún error y tablas sin datos luego debúsquedas.En “Comentario” poner las validaciones de negocio.En las secciones “Breve Descripción” de los casos de uso decir lo que hace solamente,no hacerlo condicional.Actualizar las fechas


Se planificó para ser realizada el día Viernes 11 de Julio de 2008Se entregará los documentos de análisis completo y de diseño, las correcciones de loserrores indicados y el avance en la planificación.

13/11/2008 154




i) ASISTENTES





iii) TEMAS TRATADOS


iv) PRÓXIMOS PASOS


En la sección Referencias de los casos de uso poner si Incluye a o Es incluido por yque los mismos tengan hipervínculos dentro del documento.En CU103 corregir la numeración de la sección Curso normal.Corregir el orden de los casos de uso CU104 y CU105.Corregir el titulo del diagrama de estados de Inscripción.Corregir los diagramas de secuencia: no se deben poner respuestas desde la interfazal cliente.


Se planificó para ser realizada el día Viernes 15 de Agosto de 2008Se entregará las correcciones del documento, la actualización del Gantt y seinformará el avance en cuanto a codificación y realización del video.

13/11/2008 155




i) ASISTENTES





iii) TEMAS TRATADOS


iv) PRÓXIMOS PASOS


En la sección Referencias de los casos de uso poner si Incluye a o Es incluido por yque los mismos tengan hipervínculos dentro del documento.En CU103 corregir la numeración de la sección Curso normal.Corregir el orden de los casos de uso CU104 y CU105.Corregir el titulo del diagrama de estados de Inscripción.Corregir los diagramas de secuencia: no se deben poner respuestas desde la interfazal cliente.



13/11/2008 156




i) ASISTENTES





iii) TEMAS TRATADOS


iv) PRÓXIMOS PASOS


Agregar a los campos obligatorios una identificación de dicha propiedad (por ej.: *).Cambiar el campo de provincias por un combo con las provincias argentinas.Permitir que se pueda copiar la dirección ingresada en el domicilio del alumno alpadre, madre y tutor/responsable.Validar que el documento sea numérico.Limpiar los mensajes en todas las pantallas.Revisar el tamaño de la aplicación.



13/11/2008 157




i) ASISTENTES


Cátedra de Proyecto: Tomassino, CarlosGonzález, María CeciliaSuasnabar, María Julia


Realizar una revisión del estado del proyecto y del avance del mismoRevisar las correcciones realizadasControlar el avance de la programación del sistema y su uso.

iii) TEMAS TRATADOS

Se revisó el avance en la programación de la aplicación y se controló que las correccionesrealizadas en reuniones anteriores hayan sido efectuadas.También se definieron los ajustes a realizar y los avances a solicitar para la próximaentrega.

iv) PRÓXIMOS PASOS


Validar datos de Nacimiento de los padres con los hijos y con el día de hoy.Permitir en la modificación de los datos del alumno cambiar el curso y agregar losdatos de la cuenta bancaria en la misma.Agregar un cartel de confirmación de eliminación del alumno antes de darlo de bajadefinitivamente. Cuando se seleccionan muchos poner si esta seguro de eliminartantos alumnos.Agregar datos del Tutor/Responsable y hacer que sea obligatorio completar al menosuno de los tres.Adaptar la aplicación para que se vea en toda la pantalla y no que quede fija entamaño, respetando que pueda seguir siendo usada en 800x600.Agregar la pantalla de validación de ingreso al sistema y de los casos deadministración de seguridad asociados al mismo.Ver la posibilidad de poner la aplicación para que sea accedida remotamente por lacátedra.


Se planificó para ser realizada el día Viernes 24 de Octubre de 2008Se corregirán las observaciones realizadas acerca de la aplicación y se continuará conel desarrollo de la aplicación.

13/11/2008 158




i) ASISTENTES


Cátedra de Proyecto: Tomassino, CarlosSalem, GabrielaSuasnabar, María Julia



iii) TEMAS TRATADOS

Se revisó el avance en la programación de la aplicación y se controló que las correccionesrealizadas en reuniones anteriores hayan sido efectuadas.También se definieron los ajustes a realizar y los avances a solicitar para la próximaentrega.Se ha devuelto la corrección de la carpeta con la documentación presentada al final de laprimera etapa.

iv) PRÓXIMOS PASOS


Arreglar el conteo de cantidad de aceptados por división ya que lo traía en 0.Continuar con el desarrollo del módulo de cobranzas.Continuar con el desarrollo del módulo de situación vía Web.Ajustar los detalles visuales.Agregar un menú de ayuda a la derecha de la aplicación.Ver de presentar las estadísticas de otra forma porque les resultó confuso.Ajustar la documentación para la entrega final.


Se planificó para ser realizada el día Viernes 31 de Octubre de 2008.Se nos informará la fecha de presentación a través de un sorteo a realizarse el mismodía de la reunión.

13/11/2008 159



Anexos

13/11/2008 160



PresentaciónComercial

13/11/2008 161



13/11/2008 162



13/11/2008 163



13/11/2008 164



13/11/2008 165



13/11/2008 166



13/11/2008 167



13/11/2008 168



13/11/2008 169



13/11/2008 170



13/11/2008 171



13/11/2008 172



13/11/2008 173



Video Publicitario

13/11/2008 174



13/11/2008 175



13/11/2008 176



13/11/2008 177



13/11/2008 178



13/11/2008 179



13/11/2008 180



Planificación

13/11/2008 181



13/11/2008 182



13/11/2008 183



13/11/2008 184



proyecto siba ejemplo

Documents