Ejemplo Iconix

ICONIX

SIGMAJE: desarrollado para el rubro educativo, usando tecnologías open

source innovadoras.

PROYECTO SIGMAJE2-WEB


Se puede visualizar los miembros del grupo, los coordinadores, y al docente de la asignatura.

RESUMENSIGMAJE - 2 es la segunda versión del software para Gestión de Matrículas SIGMAJE, la cual toma como base a la primera versión del mismo. Ésta tiene implementada un sistema vía web que permite reservar matrículas y la visualización de notas, así como los datos personales del alumno; permitiendo el acceso a padres de familia, alumnos y público en general. Ha sido desarrollada de acuerdo a los parámetros del proceso ICONIX. El presente proyecto está orientado hacia las empresas del rubro educativo, siendo no necesariamente colegios, pues para que satisfaga las necesidades de otro tipo de institución educativa bastaría con crear nuevas versiones mejoradas, implementando o modificando ciertos campos.

Con el fin de lograr el desarrollo de este sistema, es decir, un funcionamiento más óptimo, el código se encuentra liberado en el hosting de Assembla, siendo su sitio web http://svn.assembla.com/svn/sigmaje2web, en esta dirección se encuentra la versión web del proyecto desarrollado en base al proceso ICONIX.

El sistema permitirá a los clientes informase sobre la visión, los convenios y las actividades del colegio, así como la existencia del número de vacantes en el grado en el que estén interesados, permitir la reserva de las mismas, visualizar las calificaciones de los alumnos, datos personales y un cárdex económico; dado que las diferentes computadoras de las oficinas estarán interconectadas, la información será actualizada constantemente en tiempo real, logrando una mayor satisfacción por parte del cliente hacia la empresa. Con este sistema se podrá saber los conceptos por los que aporta el alumno al colegio.

Palabras clave: SIGMAJE, ICONIX, web, capas.


http://svn.assembla.com/svn/sigmaje2web

Tabla de contenidosResumen

I. Introducción1. Escenario

1.1.Objetivos2. SIGMAJE: Una visión global

2.1.Visión globalII. Justificación y metodología

3. Justificación3.1.Aplicaciones Desktop.3.2.Aplicaciones Web.3.3.Aplicaciones en Capas.3.4.Open Source.

4. Metodología4.1. ICONIX4.2.Aplicación de ICONIX en SIGMAJE

III. Requisitos del proceso ICONIX5. Análisis de requisitos.

5.1.Requerimientos Funcionales.5.2.Requerimientos No Funcionales.5.3. Interfaces para la Aplicación de Escritorio.5.4. Interfaces para la Aplicación Web5.5.Modelo del Dominio.5.6.Casos de Uso

6. Análisis y diseño preliminar6.1.Diagramas de Robustez: Gestión de Pagos

6.1.1. Registrar pago de matrícula6.1.2. Registrar pago de uniformes

6.2.Diagramas de Robustez: Gestión de Matrículas6.3.Diagramas de Robustez: Gestión de Uniformes

7. Diseño Detallado 7.1.Diagramas de Secuencia: Gestión de Pagos7.2.Diagramas de Secuencia: Gestión de Matrículas7.3.Diagramas de Secuencia: Gestión de Uniformes

8. Gestiones8.1.Gestión de Matrículas

8.1.1. Registro de alumnos8.1.2. Búsqueda de alumnos8.1.3. Visualización de información del alumno

8.2.Gestión de pagos8.3.Gestión de uniformes escolares

8.3.1. Creación de pedidos8.3.2. Añadir uniformes a un pedido8.3.3. Visualización de pedidos

8.4.Herramientas8.4.1. Desarrollo8.4.2. Ejecución

9. Uso de COCOMO II 9.1.Estimación del Tamaño


9.1.1. Estimación de los Puntos de Función 9.1.2. Cálculo de los Puntos de Función (PF)

9.2.Aplicación de Escritorio9.3.Uso de COCOMO – Constructive9.4.Aplicación Web

IV. Conclusiones y Trabajo Futuro10.Conclusiones y trabajo futuro

10.1. Visión global del trabajo realizado10.2. Aspectos favorables10.3. Aspectos desfavorables10.4. Trabajo futuro


Parte I. IntroducciónCapítulo 1. EscenarioEl desarrollo de un sistema de gestión implica una alta inversión, siendo accesible sólo por las medianas y grandes empresas. La mayor parte del empresariado peruano está constituido por PYMES (micro o pequeñas empresas), por lo que sus recursos tecnológicos son limitados, afectando la productividad de éstas; como es el caso de la empresa a la cual va orientada este sistema.

“San Josemaría Escrivá” es un colegio femenino secundario que cuenta con 150 alumnas, aproximadamente. Pertenece al consorcio educativo Max Planck, a pesar de ser parte de este consorcio, sus ingresos no son muy elevados. Actualmente, cuenta con un sistema de matrículas, presentando algunas deficiencias, corregidas en el presente sistema.

La gestión de matrícula se realiza de la siguiente manera:

Si la alumna es nueva: pide informes en secretaría y, si cree conveniente matricularse, primero cancela en caja la mensualidad y la matrícula; para ello, el cajero crea al nuevo cliente en el sistema ingresando nombre y grado, lo que generará el ID asignado. Después, va con la secretaria, quien llenará la ficha de matrícula.

Si la alumna es antigua y tiene dudas sobre el proceso, va a secretaría a consultarlas. Posteriormente, cancelará en caja, siendo necesario para esto indicar su número de ID.

Cuando el alumno adquiera prendas del uniforme, primero deberá cancelar en caja indicando su ID, luego irá al almacén donde se le hará entrega del uniforme presentando su respectiva boleta de pago y, para evitar posteriores reclamos, se cerciora la entrega en el sistema.

1.1. Objetivos

El presente proyecto está orientado a la creación de una aplicación web para el sector educativo, además contará con una aplicación en escritorio, donde se registrarán las actividades realizadas en la página web. El ámbito de gestión de la institución está referido a la programación, brindar información, realizar pagos y registrar los mismos. El sistema presenta las siguientes funcionalidades:

Gestión de Matrículas: La aplicación de escritorio permitirá registrar y modificar la información de los alumnos; en cuanto a la web sólo se podrá modificar dos campos de los datos personales, siendo éstos: dirección y teléfono.

Gestión de Pagos: Permite registrar el aporte de cada alumno hacia la institución, ya sea por con concepto de matrícula o uniformes; el registro de cada aporte al colegio podrá ser visto vía web en un cárdex económico.


Gestión de Uniformes: Permite actualizar constantemente el stock de cada prenda, precios y ventas.

Gestión vía web: Permite el acceso del público en general mediante la web y así poder realizar la reserva de matrículas, ver vacantes disponibles, etc.

Capítulo 2. SIGMAJE: una visión global

2.1. Visión Global

SIGMAJE es un proyecto open source que presenta un proceso de desarrollo ágil y sencillo. Fue desarrollado en base al proceso ICONIX desde sus inicios.

SIGMAJE-2 es un sistema de aplicación desktop (de escritorio) y aplicación web, el código fuente de éstos está alojado en assembla, pudiendo ser descargado por el usuario que lo requiera, ya sea para aplicarlo a su empresa o para crear una versión mejorada.


Parte II. Justificación y metodología

Capítulo 3. Justificación

3.1. Aplicaciones Desktop

Las aplicaciones desktop, conocidas también como de escritorio, están diseñadas para cubrir las necesidades del negocio y administrar la información interna del mismo.

Con las aplicaciones desktop es posible llevar la contabilidad de un negocio, administración, facturación, nómina y contar con altos niveles de rendimiento, velocidad de respuesta y seguridad.

Aunque actualmente existe un gran auge por las aplicaciones Web, muchas empresas y negocios siguen manteniendo este tipo de aplicaciones porque al estar instaladas en cada cliente (computadora) aprovechan recursos del sistema operativo ofreciendo al usuario características propias del mismo.

Adicionalmente, la información contenida en ellas no está expuesta a personas no autorizadas a través de Internet

3.2. Aplicaciones web

Los primeros bocetos de una aplicación web son las redes implementadas para la parte interna de la empresa, con el surgimiento del internet y con el paso de los años las aplicaciones web han tenido un gran auge, siendo muy usadas, sobre todo con el fin de fomentar el comercio electrónico.

Las aplicaciones web, hoy en día, son muy importantes, su facilidad de administración, debido a que pueden ser manejadas desde cualquier lugar, las hace ideales tanto para su despliegue en internet como en intranets corporativas.

La facilidad de uso de los interfaces web y el hecho de que cada día más personas estén acostumbradas a la navegación por internet hace que el tiempo de aprendizaje se reduzca considerablemente respecto a aplicaciones tradicionales standalone.

El auge de multitud de soluciones o frameworks open source hace que su desarrollo sea sencillo y que un gran número de desarrolladores tengan experiencia con ellos.


3.3. Aplicaciones en Capas

Esta nueva versión mantiene la constitución en capas de la primea versión en cuanto a la aplicación de escritorio se refiere, mientras la web tiene un diseño sencillo, es decir, realiza las funciones más importantes tanto de información como los requerimientos de los alumnos en ésta: reserva de matrícula, cuenta de cada estudiante, permitiéndole ver sus calificaciones, datos personales, horarios y próximas actividades del colegio. La aplicación web y la de escritorio están interconectadas en esta versión, permitiendo el registro de las reservas web en la aplicación de escritorio.

Las aplicaciones de escritorio suelen encontrarse con importantes problemas de escalabilidad, disponibilidad, seguridad e integración. Para dar solución a estos problemas, se ha generalizado la división de las aplicaciones en tres capas: una capa que servirá para guardar los datos (base de datos), una capa para centralizar la lógica de negocio (modelo) y por último una interfaz gráfica que facilite al usuario el uso del sistema.

Si se establece una separación entre la capa de interfaz gráfica (cliente), replicada en cada uno de los entornos de usuario, y la capa modelo, que quedaría centralizada en un servidor de aplicaciones, según el siguiente diagrama obtenemos una potente arquitectura que nos otorga algunas ventajas:

Centralización de los aspectos de seguridad y transaccionalidad, que serían responsabilidad del modelo.

No replicación de lógica de negocio en los clientes: esto permite que las modificaciones y mejoras sean automáticamente aprovechadas por el conjunto de los usuarios, reduciendo los costes de mantenimiento.

Mayor sencillez y satisfacción de los clientes. Mejor organización del sistema.


3.4. Open Source

La decisión de liberar el código fuente de este proyecto tiene como objetivo principal el distribuir libremente el software a otras personas para que pueda ser reutilizado, mejorado, optimizado, etc.

Por ser open source, la decisión de utilizar esta aplicación ha de tener en cuenta ciertos hechos relevantes remarcados en:

• Cuota de mercado• Fiabilidad• Rendimiento• Escalabilidad• Seguridad• Costo total de la propiedad • Reducción de riesgos y desventajas respecto a soluciones propietarias.• Evita conflictos de licencias y costes de administración.• Flexibilidad• Apoyo a la innovación

Capítulo 4. MetodologíaLa elaboración de esta nueva versión estuvo guiada por las directrices señaladas por ICONIX.

4.1. ICONIX

El proceso de ICONIX es un modelado de objetos conducido por casos de uso, como RUP; también es relativamente pequeño y firme, como XP, pero no desecha el análisis y diseño de éste. Este proceso también hace uso aerodinámico del UML (estándar del Object Management Group) mientras guarda un enfoque afilado en el seguimiento de requisitos. Y, el proceso se queda igual a la visión original de Jacobson del “manejo de casos de uso”, esto produce un resultado concreto, específico y casos de uso fácilmente entendibles, que un equipo de un proyecto puede usar para conducir el esfuerzo hacia un desarrollo real. El enfoque es flexible y abierto; siempre se puede seleccionar de los otros aspectos del UML para complementar los materiales básicos. Además de las características ya mencionadas, presenta las siguientes:

Centrado en datos: se descompone en fronteras de datos Basado en escenarios que descomponen los casos de uso Enfoque iterativo e incremental Ofrece trazabilidad

En conclusión, ICONIX es un proceso intermedio entre XP y RUP, siendo el primero muy útil para software’s pequeños y, el segundo, muy útil para software’s industriales; por tanto, ICONIX es una mezcla entre la agilidad de XP y la robustez de RUP.


Estas técnicas se aplican a proyectos con un equipo de desarrollo de tamaño mediano.

4.2. Aplicación de ICONIX en SIGMAJE

ICONIX es relativamente ágil y lo suficientemente robusto para un proyecto de mediana envergadura.

Concretamente, se cumplen las siguientes recomendaciones para emplear ICONIX en un proyecto:

• Interés sincero por todas las partes en que el proyecto tenga éxito.• El equipo de trabajo es mediano.• A diferencia de XP, con este proceso existe un contrato fijo previo

especificando tiempo, recursos y alcance, debido a que se hace uso de una gestión de costes y tiempo.

• El equipo dispone de una formación elevada y capacidad de aprender.• El proyecto tiene un riesgo medio en cuanto a lo innovador de la tecnología.

La metodología de ICONIX tiene éxito dentro de proyectos Open Source. Es relativamente simple, realiza ciertos procedimientos propios de XP como Integración continua, refactorización, pruebas unitarias y Test-Driven Development, a la vez toma las tareas de análisis ydiseño de RUP. A continuación se procederá a explicar la aplicación de cada una ellas en este proyecto.

1. Análisis de requisitos.

Se analiza las necesidades, requerimientos del sistema, es decir, sus funciones, por lo que se realiza el diagrama de clases.


2. Análisis y diseño preliminar.

En este paso, se realizan el modelo de dominio, que no es otra cosa sino el diagrama de clases, los diagramas de caso de uso y los diagramas de robustez.

3. Diseño detallado.

Se analizan detalladamente los diagramas de secuencia y robustez, si hay cambios se realizan, y se procede a la realización de los diagramas de secuencia.

4. Implementación.

Del diagrama de clases nuevo generado a partir de todo ese proceso, se crea el código, para este proyecto usamos Enterpirse Architect, el cual permite exportar el código.


Parte III. Requisitos del proceso ICONIX

Capítulo 5. Análisis de Requisitos

5.1. Requerimientos Funcionales

El sistema deberá ser capaz de:

Mostrar las vacantes para cada grado. Realizar un mantenimiento para los nuevos alumnos que ingresan a la

institución (registro, búsqueda, modificación y eliminación) Hacer un mantenimiento para secretarias, cajero y almacenero (registro,

búsqueda, modificación y eliminación), el encargado de realizar esto es el director.

Hacer un mantenimiento para los costos de la matrícula y pensión (ingreso y modificación), el encargado de realizar esto es únicamente el director.

A través del software de aplicación se actualizará automáticamente la base de datos.

A través de este sistema se podrá pagar las matrículas, pensiones y uniformes.

Emitir un recibo por concepto de pago (matrícula, pensión y uniformes) Mostrar un reporte de las matrículas realizadas en el presente año escolar y

la recaudación total de ingresos de acuerdo al grado de estudios. Brindar servicio de acceso Web (se podrá visualizar información,

verificación de notas, etc.)

5.2. Requerimientos No Funcionales

Se hará uso de un servidor local con el propósito de evitar colas al momento de la matrícula.

El acceso al software estará restringido mediante una clave de acceso al sistema que únicamente contarán los que participen en este y así mantener una mayor seguridad de la información.

Usar la plataforma Visual Studio .NET y el gestor de base de datos SQL Management.

El número de usuarios para la administración del sistema no debe exceder de los cuatro trabajadores incluyendo el director.

El sistema no debe ser demasiado pesado. Los tiempos de carga deben ser mínimos. Las tareas deben estar muy bien distribuidas para cada usuario del sistema. Las consultas de información de cualquier tipo dentro del sistema, deberán

realizarse de manera veloz.


El sistema debe realizar copias de seguridad de información importante e imprescindible para el mismo.

El acceso a la información del sistema en su totalidad deberá ser realizado única y exclusivamente por el administrador de la institución (director).

El sistema debe ser de fácil entendimiento para el usuario evitando complicaciones.

Al trabajar con Visual Studio 2005 la empresa tiene que comprar las licencias de este producto.

Contar con un Dominio y un Hosting. El sistema vía web debe dar soporte al acceso de todos los padres de

familia de la institución y al público en general.

5.3. Interfaces para la Aplicación de Escritorio.

Estas son algunas de las interfaces diseñadas para el software de escritorio:

5.4. Interfaces para la Aplicación Web.





5.5. Modelo del Dominio

Para SIGMAJE - 2, nos basamos principalmente en el mismo diseño que la versión anterior obteniendo el siguiente modelo del dominio.


5.6. Casos de Uso

El proyecto consiste en un sistema de gestión de registro y pagos de matrículas, pensión y uniformes adquiridos del colegio, además de la gestión vía web.

El ámbito de gestión de la institución está referido a la programación, brindar información, realizar pagos y registrar los mismos.

Capítulo 6. Análisis y Diseño PreliminarEn base a los casos de uso mencionados anteriormente, se procede a generar los diagramas de robustez. Aquí se detalla cada gestión paso a paso dentro del sistema.

6.1. Diagramas de Robustez: Gestión de Pagos

6.1.1. Registrar pago de matricula

Se dirige a la interfaz Registrar Pago de Matricula e ingresa el código del alumno.

Se obtiene el código.


Para eso se busca en la BD. Si el código no es encontrado se muestra un mensaje de información y se genera el nuevo código (se toma como un nuevo alumno). Se ingresan los apellidos, nombres y grado procediéndose a guardar el registro y actualizar la BD.

Si el código es encontrado se muestran los apellidos y nombres del alumno y se selecciona el grado a cursar. Se guarda el registro haciéndose efectivo el proceso mediante la actualización del nuevo registro en la BD.

Se emite el recibo de pago de matricula.

6.1.2. Registrar pago de uniformes

Se dirige a la interfaz Registrar Pago de Uniforme e ingresa el código del alumno.

Se obtiene el código. Se busca el código en la BD. Si el código no es encontrado se muestra un

mensaje de información y no puede realizarse el proceso. Si el código es encontrado se muestran los apellidos y nombres y se adicionan los uniformes a adquirir.

Se guarda el registro procediéndose a actualizar la BD. Se emite el recibo de pago de uniforme.

6.2. Diagramas de Robustez: Gestión de Matrículas

La secretaria es la encargada de todo lo referente al proceso de inscripción del alumno, mediante los siguientes pasos:


Se dirige a la interfaz de Registrar Alumno e ingresa el código del alumno. Obtiene el código. Para eso, busca el código en la BD(actualizada previamente por el cajero

mediante el pago de matricula y pensión) Si no encuentra el código, muestra un mensaje de advertencia y no puede

culminarse el proceso de matrícula. Caso contrario, muestra los apellidos, nombres y grado del alumno.

Ingresa datos adicionales del alumno. Guarda los cambios haciéndose efectivo el registro. Se actualiza la BD haciéndose efectiva la nueva información.

6.3. Diagramas de Robustez: Gestión de Uniformes

Esta gestión es llevada a cabo por el almacenero, quien es el encargado del manejo de los uniformes en la institución mediante los siguientes pasos:

Se dirige a la interfaz Registrar Entrega de Uniformes. Se obtiene el código buscándolo en la BD. Actualizada previamente por el

cajero mediante la Gestión de Pagos. Si el código no es encontrado se muestra un mensaje de información. Si es

encontrado se muestra el pedido del alumno, se selecciona el estado del pedido (de pendiente a entregado), se guarda el registro y se procede a actualizar la BD.


Capítulo 7. Diseño DetalladoEn este capítulo se hace un diseño más detallado y profundo del sistema, mediante esta herramienta que brinda el proceso ICONIX que son los diagramas de secuencia.

7.1. Diagramas de Secuencia: Gestión de Pagos


7.2. Diagramas de Secuencia: Gestión de Matrículas

7.3. Diagramas de Secuencia: Gestión de Uniformes


7.4. Diagrama de Clases

El presente diagrama de clases fue reestructurado tomando en base los diagramas de robusticidad y secuencia.

Capítulo 8. Gestiones

8.1. Gestión de Matrículas Este apartado está orientado al registro de matrículas de alumnos. Individualmente, cada alumno registrado cuenta con atributos como:

Código Apellidos Nombres GradoAdicionalmente se pueden tener información para contactar con ellos, por ejemplo:

Dirección Teléfono E-mail Apoderado

Y datos adicionales como:

Lugar de Nacimiento Fecha de Nacimiento Colegio de procedencia


8.1.1. Registro de alumnos

Al registrar un alumno se llenan los datos mencionados anteriormente previo pago en caja por derechos de matrícula y pensión.

8.1.2. Búsqueda de alumnos

Se podrán realizar búsquedas por código, en los casos de registro de pago, ventas de uniformes e inscripción de alumnos.

8.1.3. Visualización de información del alumno

Esto se realizará cuando se desee imprimir algún recibo de pago, se registre la entrega de uniformes y/o el director consulte la lista de alumnos inscritos.

8.2. Gestión de pagos

La gestión de pagos (models) se centra en el pago de los conceptos tanto de matrícula, pensión, como de uniformes escolares (products) En cuanto al modelo se de pago de matricula y pensión se tienen los siguientes atributos:

Código del alumno Nombres Grado Concepto de cargo de matricula y pensión asignado para todos por defecto.

En cuanto al modelo de pago de uniforme escolar se consideró lo siguiente: Código del alumno Nombres Grado Tipo de uniforme escolar y su respectiva talla a elegir.

8.3. Gestión de uniformes escolares

Se gestiona la venta de uniformes escolares propios de la institución, pues poseen un diseño y colores distintivos de la institución.

Están clasificados por tipo ya sea polos, buzos, short, chompas y chalecos; y por tallas como XS, S, M y L.

El proceso de ventas de uniformes comienza cuando un cliente escoge una serie de productos y cantidades que se formalizan en un pedido.

Posteriormente los pedidos son actualizados en el servidor y la entrega se hará efectiva cuando el almacenero registre que el pedido ya fue entregado.


8.3.1. Creación de pedidos

A partir de un cliente se podrá crear un nuevo pedido. El único dato necesario será el código del cliente.

8.3.2. Añadir uniformes a un pedido

Se podrán buscar los uniformes por tallas para añadirlos al pedido en curso, en la cantidad deseada.

8.3.3. Visualización de pedidos

Se podrá visualizar el pedido en el recibo de pago emitido por el cajero.

8.4. Herramientas

En el desarrollo de este proyecto se han utilizado las siguientes herramientas en cada ámbito.

8.4.1. Desarrollo

• Visual Studio Team System.Net• SQL Management

8.4.2. Ejecución

El software requerido para la ejecución del sistema es:1. SQL Management como base de datos. 2. Visual Studio Team System.NET para la ejecución del proyecto.3. Un navegador web (Internet Explorer ó Mozilla) para la actualización de

datos y la visualización del sistema vía web.

Capítulo 9. Uso de COCOMO II a. Estimación del Tamaño

9.1.1 Estimación de los Puntos de Función

Puntos de Función .Es una medida sintética bastante exacta para medir el tamaño de un Sistema de Información.

Objetivo: obtener una medida de las unidades a producir, aunque se puede llegar a deducir el esfuerzo en horas asociado a dicha producción.

Es una métrica definida por Allan Albrecht (IBM, 1979) y es un método para medir el tamaño del software.


Pretende medir la funcionalidad entregada al usuario independientemente de la tecnología utilizada para la construcción y explotación del software, útil en cualquiera de las fases del ciclo de vida del software.

Existen diferentes metodologías de medición, la más popular de las cuales es la mantenida por el International Function Point Users Group (IFPUG).

9.1.2 Cálculo de los Puntos de Función (PF)

Los PF de desarrollo de un proyecto de software, se calcula en base a:

El cálculo de los Puntos de Función Desajustados (PFD) El cálculo del Factor Ajuste del Valor (FAV) El cálculo de los Puntos de Función Ajustados (PFA)

PF de desarrollo (proyecto): PFA = PFD * FAV

b. Aplicación de Escritorio

Estimación de los Puntos de Función Desajustados - Método de Albretch

Entradas:

a. Registro de Alumnos.b. Registro de pagos de Matricula.c. Registro de pago de Uniforme.d. Registro de Entrega de Uniforme.e. Registro de Reglas del Director.f. Registro de Uniforme.g. Logueo del Usuario.

Salidas:

a. Recibo de Pago de Matricula.b. Recibo de Pago de Uniforme.c. Reportes de Matricula por Periodo(6)

Consultas:

a. P_ALUMNO_REGISTRARb. P_ALUMNOS_BUSCARxCODIGOc. P_Entrega_REGISTRARd. P_Matricula_ReservarMatriculae. P_ModificarAlumnof. P_Plan_Academico_Generarg. P_Plan_AcademicoxTipo_Periodoh. P_TipoMatricula_BUSCARxNumero


i. P_TipoMatricula_REGISTRARj. P_Uniforme_BUSCARxCODIGOk. SP_ALUMNO_REGISTRARl. SP_ALUMNOS_BUSCARxCODIGO

Interfaces:

a. Registro de Alumnos.b. Registro de pagos de Matricula.c. Registro de pago de Uniforme.d. Regitro de Entrega de Uniforme.e. Registro de Reglas del Director.f. Registro de Uniforme.g. Logeo del Usuario.h. Recibo de Pago de Matricula.i. Recibo de Pago de Uniforme.j. Reportes de Matricula por Periodok. Menú Principal.l. Buscar Vacantes.

Archivos:

a. Alumnosb. DespachoUniformec. Matriculad. Plan_Academicoe. Tipo_Matriculaf. Uniforme

Tabla de Complejidad de la Clasificación de las Estructuras de datos

Complejidad

Descripción Baja Media Alta total

Entradas 3x3 1x4 3x6 31

Salidas 2x4 6x5 38

Consultas 8x3 4x4 40

Archivos 4x7 2x10 48

Interfaces dePrograma

8x5 4x7 68

PFD: Total de Puntos de Función sin Ajustar

225


La tabla de complejidad de procesado de las 14 funciones

0-5

Comunicación de datos 5

Configuración de gran uso 3

Velocidad de transacción 4

Eficacia de usuario Final 1

Procesado complejo 5

Facilidad de Instalación 3

Varios sitios 5

Rendimiento 3

Funciones distribuidas 1

Introducción de datos en línea 4

Actualización en línea 1

Reusabilidad 2

Facilidad de manejo 2

Ampliabilidad 0

Complejidad de Procesado = PC=39 PCA = 0,65 + (0,01* 39)=1.04

Complejidad de Procesado Ajustada (PCA) = 0,65 + (0,01* PC)

Total de Puntos de Función Ajustados (PFA) = PC * PFD

PFA =39 * 225=8775


c. Uso de COCOMO – Constructive

Cost Model para la Estimación

Ingreso de los Puntos Función ya calculados anteriormente.


Resultados final


d. Aplicación Web

Estimación de los Puntos de Función Desajustados - Método de Albretch

Entradas:

Logueo. Registro de Clases. Programa Académico. Registro de Alumnos. Pago de Matricula. Configuración. Buscar Alumno. Buscar Uniforme.

Salidas:

Recibo de Matricula. Recibo de Uniforme. Consulta Reporte.

Consultas:

Sp_Grabar_Alumno. sp_selAlumno. sp_selNotas. sp_selPago. sp_selUsuario.

Interfaces:

Logueo. Registro de Clases. Programa Académico. Registro de Alumnos. Pago de Matricula. Configuración. Buscar Alumno. Buscar Uniforme. Recibo de Matricula. Recibo de Uniforme. Alumno Director

Archivos:


ALUMNO CLASE CURSO GRADO MATRICULA NOTAS PAGO PERIODO PROFESOR PROGRAMA PROFESOR

Tabla de Complejidad de la Clasificación de las Estructuras de datos

Cálculo de los Puntos de Función Ajustados

• Ajuste de los Puntos Función de las 14 funciones

Puntos de Función Ajustados 0-5

1 5

2 4

3 4

4 3

5 3

6 4

7 4


de programas

884X104X74X5Interfaces

1163X155X103X7Archivos

201X62X42X3Consultas

180X72X52X4Salidas

394X63X41X3Entradas

TotalAltaMediaBajaDescripción

Complejidad

Total de Puntos de Función sin Ajustar = PFD 281

8 3

9 1

10 4

11 3

12 5

13 0

14 2

PC 45

Complejidad de Procesado = PC

Utilizar la tabla de complejidad de procesado de las 14 funciones Complejidad de procesado

• Gran efecto

Complejidad de Procesado Ajustada (PCA) = 0,65 + ( 0,01* PC )

Total de

Puntos de Función Ajustados (PFA) = PC * PFD

Guía para la Estimación del Tamaño y Esfuerzo en Productos de Software


Complejidad de Procesado Ajustada (PCA) = 0,65 + ( 0,01* PC )

0.695

Total de Puntos de Función Ajustados (PFA) = PC * PFD

17595

Ingreso de los puntos de fusión

Resultado


Estimación del esfuerzo del proyecto, en base a los puntos funcionales calculados en la parte 1.


Parte IV. Conclusiones y trabajo futuro

Capítulo 10. Conclusiones y trabajo futuro

10.1. Visión global del trabajo realizado

En el presente trabajo se ha realizado sistema de apoyo a la gestión de pagos de matrícula, mensualidades y uniformes adquiridos propios de la institución educativa San Josemaría Escrivá.

Para el desarrollo del sistema se ha optado por soluciones innovadoras tanto en tecnología como metodología, escogiendo el proceso ICONIX, separando el proceso en sucesivas iteraciones que han añadido funcionalidad progresivamente, y que han permitido disponer de versiones de demostración en corto tiempo.

10.2. Aspectos favorablesGestión metodológica del proyecto, con control e historial de cambios, gestión de versiones y documentación exhaustiva.

Es importante destacar que el trabajo conjunto universidad-empresa es una buena estrategia que se debe aprovechar, principalmente porque el foco de las universidades es investigar.

La colaboración con el cliente más que la negociación de un contrato. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.

El diseño se ha mantenido sencillo, desde luego pasando los tests, con un mínimo de código gracias al núcleo del sistema que proporciona un gran dinamismo y evita la necesidad de implementación de operaciones repetitivas.

10.3. Aspectos desfavorablesEl principal aspecto desfavorable ha sido el gran reto a los que nos hemos enfrentado al desarrollar una aplicación en pocos meses son muy diferentes de aquellos que desarrollan una aplicación en un año. Fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto, minando la planificación efectiva, y reduciendo las actividades críticas para el desarrollo, como el análisis de requerimientos o el diseño. También


supone una excesiva presión para los desarrolladores, quienes a largo plazo se ven afectados en su moral y su productividad.

Los proyectos se aceleran intentando acortar las actividades "no esenciales", y puesto que el análisis de requerimientos, la arquitectura y el diseño no producen código directamente, son los candidatos fáciles.

10.4. Trabajo Futuro

Establecer un plan de acción que permita mejorar las capacidades de la empresa evaluada.

Evaluar las adecuaciones de SIGMAJE en la implantación.

Realizar una mayor cantidad de evaluaciones, que permitan proponer mejoras que puedan adaptarse completamente a las instituciones educativas de nuestro país.

Realizar nuevas actualizaciones del proyecto si es necesario

Mejorar la tecnología del proyecto.

Implementar más funcionalidades al sistema vía web.


Apéndice A. Obtención y compilación del código

A.1. Descarga y compilación del código fuente disponible en SVNEl proyecto utiliza TortoiseSVN como herramienta de gestión. Tan sólo se necesita seguir los siguientes pasos:

1. Instalar el software TortoiseSVN

2. Crear una carpeta en el escritorio y ponerle de nombre SIGMAJE 2

3. Abrir la carpeta SIGMAJE 2 y hacer clic derecho elegir la opción Check out.

4. A continuación se abre una ventana donde se introduce como URL de repositorio la siguiente dirección: http://svn.assembla.com/svn/sigmaje2web. Dar clic en aceptar y esperar la descarga. Si en algún momento se desea para la descarga solo dar clic en cancelar y luego cerrar la ventana. Los archivos ya descargados hasta ese momento se conservaran en la carpeta.


http://svn.assembla.com/svn/sigmaje2web

5. Los archivos ya descargados aparecerán en estado agregado.

6. En caso de modificar alguno se mostrará esta señal en el archivo modificado.


7. Si se desea actualizar lo modificado en el archivo central que se encuentra alojado en Assembla. Abrir la carpeta SIGMAJE, dar clic derecho en un espacio vacio y hacer clic en la opción SVN commit

8. En la ventana q aparece dar clic en aceptar, esperar que actualice el archivo modificado, actualizar la PC (F5) y listo.


Apéndice B. InstalaciónB.1. InstalaciónLa instalación del sistema completo implica la instalación de una base de datos y e software visual Studio team System 2005.

B.2. Instalación de la base de datosEl funcionamiento del proyecto ha sido probado con la base de datos SQL-Server 2005.

Accedemos a una base de datos de SQL Server, usando los objetos del espacio de nombres System.Data.SqlClient.

Imports System.Data

Imports System.Data.SqlClient

Private cadena As String = "Data Source=(local); Initial Catalog=BDSpike; Integrated Security=true;"

La variable Cadena Conexión será la cadena con la que conectaremos a la base de datos.

Dim conexion As New SqlConnection(cadena)

Creamos un nuevo objeto del tipo DataSet, que será el que nos permita acceder a los datos

Dim ds As New DataSet

Creamos un objeto del tipo DataAdapter, este será el que realmente nos permita acceder a ‘los datos físicos de la base de datos, primero para rellenar el DataSet y posteriormente ‘para actualizar los cambios realizados en la base de datos

Dim da As New SqlDataAdapter

Iniciamos la conexión

da.SelectCommand = New SqlCommand()

En el caso de necesitar acceder a una consulta solo le mandamos el nombre tal y como lo llamamos en la creacion de la base de datos

da.SelectCommand.CommandText = "Sp_Listar_Grados"

da.SelectCommand.CommandType = CommandType.StoredProcedure


da.SelectCommand.Connection = conexion

Abrimos la conexión a la base de datos

conexion.Open()

Cerramos la conexión la conexión de la base de datos

conexion.Close()

Glosario

.NET .NET Framework constituye la base sobre la que se asienta .NET. Para nosotros es la pieza fundamental de esta nueva tecnología y es la que nos va a proporcionar las herramientas y servicios que necesitaremos en nuestros desarrollos.

Framework Conjunto de APIs y herramientas destinadas a la construcción de un determinado tipo de aplicaciones de manera generalista.

SQL Es una solución completa de administración de bases de datos y el desarrollo.


Documents

Ejemplo Iconix