DESARROLLO MÓDULO DE RENDICIONES PORTAL PSP

RODRIGO GARCÉS RENGIFO

CÓDIGO: 2030071

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE

FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA INFORMÁTICA

SANTIAGO DE CALI

2009

DESARROLLO MÓDULO DE RENDICIONES PORTAL PSP

RODRIGO GARCÉS RENGIFO

CÓDIGO: 2030071

Trabajo de grado para optar el titulo de

Ingeniero Informático

Modalidad: pasantía

Director

ING. OLMEDO ARCILA GUZMÁN.

INGENIERO DE SISTEMAS

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE

FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA INFORMÁTICA

SANTIAGO DE CALI

2009

Nota de aceptación:

Aprobado por el Comité de Grado en

cumplimiento de los requisitos exigidos

por la Universidad Autónoma de

Occidente para optar al título de

Ingeniero Informático

OLMEDO ARCILA GUZMÁN ____

Firma del presidente del jurado

ORLANDO ARBOLEDA______

Firma del jurado

CARLOS ALBERTO PELAEZ .

Firma del jurado

Santiago de Cali, 9 de Diciembre de 2009

AGRADECIMIENTOS

Agradezco a la empresa Keyvolution3 Ltda., quien financió este proyecto

permitiendo poner en práctica los conocimientos adquiridos durante mi formación

profesional en la Universidad Autónoma de Occidente.

El autor expresa su agradecimiento a:

Ing. Nelson Quiceno, Gerente de la empresa Keyvolution3 Ltda., el cual me

brindo su apoyo incondicional en el proyecto, permitiéndome el uso de las

instalaciones y los recursos informáticos necesarios. Además por el conocimiento

adquirido en el transcurso del desarrollo del proyecto.

Ing. Olmedo Arcila Guzmán, Ingeniero de Sistemas, Docente de la Facultad de

Ingeniería de la Universidad Autónoma de Occidente de Cali, por sus admirables

aportes, orientación y constante apoyo en el desarrollo de este trabajo.

A todos aquellas personas que me han brindado su apoyo incondicional, de las

cuales he aprendido, y de las cuales me han hecho un mejor individuo.

CONTENIDO

pág.

INTRODUCCIÓN .....................................................................................................1

1. TITULO..............................................................................................................3

2. PARTICIPANTES..............................................................................................3

2.1 ESTUDIANTES.................................................................................................3

2.2 DIRECTOR ACÁDEMICO..................................................................................3

2.3 ASESOR EMPRESARIAL..................................................................................3

3. PLANTEAMIENTO DEL PROBLEMA ...............................................................4

4. JUSTIFICACIÓN ...............................................................................................5

5. ANTECEDENTES .............................................................................................6

6. MARCO TEORICO............................................................................................8

6.1 DEFINICIÓN DE MÓDULO DE RENDICIONES................................................9

6.2 HERRAMIENTAS DE DESARROLLO .............................................................10

6.2.1 Python...........................................................................................................10

6.2.2 Patrón de Diseño Modelo Vista Controlador. ................................................11

6.2.3 Django...........................................................................................................13

6.2.4 JQuery. .........................................................................................................14

6.2.5 AJAX. ............................................................................................................14

6.2.6 MySQL. .........................................................................................................15

6.2.7 WAE..............................................................................................................16

7. OBJETIVOS ....................................................................................................18

7.1 OBJETIVO GENERAL .....................................................................................18

7.2 OBJETIVOS ESPECIFICOS............................................................................18

8. METODOLOGÍA..............................................................................................19

9. DESARROLLO DEL PROYECTO...................................................................21

9.1 ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE........................21

9.1.1 Listado de Casos de Uso. .............................................................................22

9.1.2 Listado de Actores. .......................................................................................23

9.1.3 Descripción ó guiones de casos de uso........................................................23

9.1.4 Diagramas de clase. ....................................................................................25

9.1.5 Diagramas de secuencia...............................................................................25

9.2 ANÁLISIS Y DISEÑO.......................................................................................26

9.2.1 Diagrama relacional de casos de uso. ..........................................................26

9.2.2 Modelado del software. .................................................................................27

9.2.4 Modelado de la base de datos. .....................................................................29

9.3 IMPLEMENTACIÓN.........................................................................................31

9.3.1 Lenguaje de Programación. ..........................................................................31

9.3.2 Framework de desarrollo Web. .....................................................................31

9.3.3 Bases de datos. ............................................................................................31

9.3.4 Lenguaje utilizado en la interfaz....................................................................32

9.3.5 Librerías externas. ........................................................................................32

9.3.6 Interfaces de la aplicación.............................................................................32

9.3.6.1 Formulario de ingresar documento. ...........................................................32

9.3.6.2 Formulario matriz de documentos..............................................................34

9.3.6.3 Formulario ingresar nota de corrección......................................................34

9.4 PRUEBAS........................................................................................................36

10. CONCLUSIONES ........................................................................................37

11. RECOMENDACIONES ................................................................................39

BIBLIOGRAFÍA ......................................................................................................40

ANEXOS................................................................................................................44

LISTA DE TABLAS

pág.

Tabla 1. Guión ingresar nota de corrección 24 Tabla 2. Prueba unitaria para el caso de uso ingresar documento. 36

LISTA DE FIGURAS pág.

Figura 1. Tecnologías agrupadas bajo el concepto de AJAX 15 Figura 2. Diagrama de clase WAE caso de uso N.12 25 Figura 3. Diagrama de secuencia caso de uso N.12 26 Figura 4. Diagrama relacional de casos de uso. 27 Figura 5. Esquema MVC en Django. 28 Figura 6. Modelo Entidad Relación. 30 Figura 7. Formulario Ingresar Documento (A). 33 Figura 8. Formulario Ingresar Documento (B). 33 Figura 9. Formulario Matriz de Documentos. 34 Figura 10. Formulario Ingresar Nota de Corrección. 35

LISTA DE ANEXOS pág.

ANEXO 1. Diagrama de Caso de Uso 44 ANEXO 2. Diagrama de Caso de Uso 64 ANEXO 3. Diagrama de Secuencia 75 ANEXO 4. Modelo Relacional de Datos 85 ANEXO 5. Formularios 90 ANEXO 6. Pruebas Unitarias 95

1

INTRODUCCIÓN

La calidad en la educación es un elemento sumamente importante que fortalece el aprendizaje y nivel de competencia a nivel general. Fortalecer este pilar aumenta las posibilidades de mejorar las capacidades intelectuales de cada uno de los estudiantes y el nivel de enseñanza en cada uno de ellos. Es necesario contar con herramientas e instrumentos que eleven la calidad de la educación para cosechar un conocimiento lleno de intelectualidad con índice de perfeccionamiento. Una de las herramientas existentes en la actualidad son los PSP (Planes de Superación Profesional), estos PSP son implementados por el Gobierno de Chile mediante el Ministerio de Educación. Estos planes son aplicados a los profesionales de la educación que resultaron evaluados con nivel de desempeño básico, de acuerdo a la Ley 19.961 de febrero de 2004 de Chile. A continuación se describe en que consisten:

“El Ministerio de Educación de Chile, a través del Centro de Perfeccionamiento, Experimentación e Investigaciones Pedagógicas (CPEIP), transferirá a los municipios recursos económicos para financiar los Planes de Superación Profesional, atendiendo al número de docentes evaluados, con nivel básico e insatisfactorio. El total de recursos a transferir año a año se establecerá en la Ley de Presupuestos del Sector Público.

Los municipios podrán gastar los recursos transferidos sólo en las actividades contenidas e indicadas en el diseño del Plan de Superación Profesional de la comuna, el cual debe ser presentado al Centro de Perfeccionamiento, Experimentación e Investigaciones Pedagógicas (CPEIP) en el mes de abril de cada año.

Los municipios deberán rendir cuenta documentada y detallada de los gastos en que hayan incurrido para financiar los Planes de Superación Profesional de cada comuna, estando limitado el gasto a lo indicado anteriormente. La rendición 1 de gastos se deberá presentar al Centro de Perfeccionamiento, Experimentación e Investigaciones Pedagógicas (CPEIP) en el mes de Noviembre de cada año, pudiendo éste observar el gasto y solicitar las rectificaciones que sean necesarias.”

“Los Planes de Superación Profesional contemplan actividades como las siguientes:

1 Rendición es el término usado en Chile para referirse a la información documentada y detallada que incurrieron en los gastos para financiar cada uno de los PSP en la comuna.

2

1. Tutorías o asesorías provistas por profesionales idóneos; Participación en cursos, talleres o seminarios organizados por entidades académicas o de capacitación.

2. Lecturas recomendadas, para las cuales se deberá proveer de material bibliográfico u orientaciones para acceder a información disponible en Internet.

3. Observaciones de clases hechas por docentes destacados u otros profesionales calificados.”

Es necesario que la rendición de gastos o como también es llamada rendición, sea confiable, concisa y que refleje de una manera estructurada cada uno de los PSP, pudiendo recopilar toda la información financiera para cada uno de ellos.

El siguiente trabajo consiste en el desarrollo de una aplicación informática que permita recopilar la información financiera de cada PSP, permitiendo el desarrollo de un módulo de rendiciones capaz de reunir toda la funcionalidad que implica el control y gestión de cada una de la rendición de gastos para cada municipio, estableciendo de esta manera una supervisión centralizada desde una aplicación computacional, obteniendo así resultados eficaces y seguros con un acceso inmediato a la información. De esta manera se pueden rectificar cada una de las rendiciones, aumentado el flujo en el proceso para cada rendición por comuna. [3]

3

1. TITULO Desarrollo Módulo de Rendiciones Portal PSP (Planes de Superación Profesional).

2. PARTICIPANTES 2.1. ESTUDIANTES. Nombre y apellidos

Código Programa Modalidad e- mail

Rodrigo Garcés Rengifo

2030071 Ingeniería Informática

Pasantía Institucional

rrgarces.85@gmail.com

2.2. DIRECTOR ACÁDEMICO. Nombre Títulos Olmedo Arcila Guzmán Ingeniero de Sistemas

2.3. ASESOR EMPRESARIAL. Nombre y apellidos Cargo Nelson Quiceno Ingeniero de Sistemas

4

3. PLANTEAMIENTO DEL PROBLEMA El PSP Online (Planes de Superación Profesional Online) es una plataforma que en la actualidad presenta problemas en el manejo del presupuesto de sus planes (PSP), por lo cual se ha decido implementar un sistema de información que permita controlar estos costos presupuestados de una menara adecuada. Estos costos van asignados en lo que se define como rendiciones, las cuales son la última etapa del Plan de Superación Profesional (PSP) y son la base del proceso inicial del año siguiente.

5

4. JUSTIFICACIÓN Teniendo en cuenta que la educación es algo primordial, y que el diseño y ejecución de los PSP son base para el mejoramiento de la calidad en la educación, se necesita que la financiación de cada PSP se realice de manera confiable y correcta. El módulo de registro de gastos permitirá a los Planes de Superación Profesional optar con un esquema de financiación seguro y acorde a las normas evaluadas por cada registro de gasto, permitiendo así obtener rendiciones que representen un presupuesto válido para una planeación y ejecución para el próximo periodo. El módulo brindará un control y seguimiento por cada rendición de cada comuna, con la finalidad de mantener una gestión en cada proceso de la rendición, permitiendo de esta manera un control sobre toda la financiación de cada PSP. Por medio de este módulo, se podrán agilizar los procesos de asignación de costos, logrando una mayor fluidez en la ejecución de cada PSP. A través de este módulo se generarán mecanismos de monitoreo continuos y retroalimentación de cada PSP, potenciando el funcionamiento de cada registro de gasto por comuna.

6

5. ANTECEDENTES El módulo de rendiciones es una aplicación informática que surge debido a la necesidad empresarial de organizar y controlar las deficiencias que hay en la gestión del manejo de sus gastos para cada PSP, existen diversas herramientas que ayudan a las entidades a conocer detalladamente las rendiciones o gastos para determinados ítems.

• Report System – Software de Comercio Exterior: Report System es una aplicación que se basa en una serie de módulos, entre los cuales se encuentra el módulo de Facturación - Gestión Financiera – Contabilidad, el cual permite la generación y emisión de facturas y rendiciones de gastos. [10] Sus características de seguridad únicas en el mercado permiten mostrar a los importadores/exportadores, el seguimiento real de sus operaciones (on line). Report System es una empresa que se dedica desde 1989 al desarrollo de software de comercio exterior, orientado principalmente a la tarea que desarrollan los Despachantes de Aduana , realmente integrado y con toda la versatilidad, seguridad, agilidad y eficiencia adquiridas durante 15 años de desarrollo ininterrumpido.

• Datahouse Company - Software de gestión comercial Sistema Isis: es una aplicación completamente modular y customizable, cumpliendo con las especificaciones que lo transforman en un auténtico software ERP. [11] El sistema de gestión comercial brinda un control total sobre la deuda de los clientes. Trazabilidad total de valores, documentos, operaciones y cobradores (se puede rastrear hasta el origen mismo de la operación, por ejemplo la nota de pedido original); emisión de listados de deuda para cobranzas; estado de pendiente para deudas no rendidas por sus cobradores. Está conformado por el módulo “Módulo de Gestión de Cobranzas”, el cual permite un manejo de rendiciones de cobranzas, indicando múltiples formas de pago (cheques, documentos, moneda extranjera, etc).

7

Datahouse Company es una alianza de empresas que desde Agosto de 2001 ofrece los mejores sistemas y soluciones en el mercado argentino para las diferentes soluciones empresariales que se presenten.

8

6. MARCO TEORICO Los Planes de Superación Profesional (en adelante PSP) son un conjunto de acciones formativas diseñadas y ejecutadas por los municipios (comunas) [5]. Esta formación está dirigida a los profesores que resulten evaluados con un nivel de desempeño básico e insatisfactorio en la Evaluación Nacional de Desempeño Docente y deberá consistir en acciones de aprendizaje y re-aprendizaje, respecto de las competencias, conocimientos, habilidades, dominios y criterios establecidos en el Marco para la Buena Enseñanza y deberá estar relacionada con las necesidades de desarrollo profesional derivadas del informe de resultados entregado a cada municipio. ¿En qué consiste la Evaluación Docente? La Evaluación Docente es un sistema de evaluación de los profesionales de la educación que se desempeñan como docentes de aula. Nació el 25 de junio del año 2003 a partir del Acuerdo Marco tripartito suscrito por el Ministerio de Educación, la Asociación Chilena de Municipalidades y el Colegio de Profesores de Chile. El Sistema de Evaluación del Desempeño Profesional Docente es un proceso formativo que busca fortalecer la profesión docente, favoreciendo el reconocimiento de las fortalezas y la superación de las debilidades de los docentes , con el fin de lograr mejores aprendizajes en sus alumnos. Para ello, cada docente evaluado recibe un informe individual de resultados que da cuenta de los aspectos más y menos logrados de su desempeño, según la información proporcionada por los cuatro instrumentos de evaluación. La intención de los PSP es que a nivel comunal se constituyan espacios locales de desarrollo profesional de los docentes. El fin último de los PSP es que los profesores cuenten crecientemente con más y mejores herramientas profesionales que contribuyan eficazmente a elevar la calidad de los aprendizajes de sus alumnos. El Ministerio de Educación de Chile, a través del Centro de Perfeccionamiento, Experimentación e Investigaciones Pedagógicas (CPEIP) es el responsable de aprobar, monitorear y evaluar la aplicación de los PSP desarrollados por los municipios, con el fin de asegurar que estas acciones sean pertinentes, oportunas y efectivas. [8]

9

Asimismo, CPEIP es el encargado de transferir a los municipios recursos económicos para financiar los PSP, atendiendo al número de docentes evaluados con nivel básico e insatisfactorio, además de revisar las correspondientes rendiciones presupuestarias una vez finalizada la implementación del plan en la comuna. La aplicación PSP on-line es un programa computacional que permite diseñar, monitorear y evaluar los PSP implementados en las comunas. Al PSP on-line pueden acceder los distintos perfiles involucrados en el proceso de diseño, ejecución y seguimiento de los PSP:

• Encargados Comunales de los PSP. • Entidades Ejecutoras o Ejecutores. • Docentes. • Funcionarios del CPEIP.

6.1 DEFINICIÓN DE MÓDULO DE RENDICIONES El módulo de rendiciones o como también es llamado “Registro de Gastos” es un módulo el cual reúne información del Plan de Superación Profesional luego de su diseño y ejecución a través de todo un año. Durante el diseño de cada uno de los PSP se planifican e implementan actividades por cada PSP, las cuales son la base de su desarrollo. Estas a su vez se asignan a los docentes, los cuales participaran en ellas y con lo cual se lograrán que las competencias, conocimientos y habilidades de los docentes mejoren. A medida que se desarrolla el (PSP) se diseña (asigna) un presupuesto, indicando los costos estimados de cada actividad según los diferentes ítems de pago. A continuación de describe cada ítem de pago:

• Pago Organismo Ejecutor: Se refiere al pago que se estima se hará al organismo ejecutor (son los profesionales designados por el Encargado Comunal para ejecutar una o más de las actividades del PSP) de la actividad.

• Pago de Honorarios: Se refiere los gastos por honorarios a pagar a él o los profesionales que ejecutarán la actividad (cuando los honorarios no están incluidos dentro del pago al organismo ejecutor).

• Pago Materiales de Oficina: Se refiere a los gastos estimados de papeles, lápices, fotocopias, etc.

• Pago de Trasporte: Se refiere a los gastos estimados asociados a trasladar a los docentes o profesionales para realizar la actividad.

10

• Pago Material Educativo: Se refiere al costo estimado por cualquier material educativo que se utilizará para la actividad, como por ejemplo, libros.

• Pago Otro: Se refiere a los costos de ítems que no entran en las categorías anteriores.

Luego de la finalización del diseño y ejecución de los PSP, se deben de asignar los costos rendidos (costos reales) de cada actividad por ítem de pago, de esta manera se confrontan los valores estimados Vs. los rendidos y a su vez conocer el saldo pendiente por rendir para el próximo año en caso de que ambos costos no sean iguales. Toda esta información de costos rendidos se le conoce como rendición. La intención del módulo es permitir controlar la aprobación y rechazo de cada rendición (hay que tener en cuenta que cada rendición se realiza por comuna, Chile es un país el cual está conformado por 15 regiones y aproximadamente 347 comunas). De esta manera se obtiene un control de los costos rendidos Vs. los estimados a través del año en el transcurso del desarrollo del PSP, acceso a los costos rendidos por los Encargados Comunales (encargados de diseñar el PSP para los docentes evaluados en su comuna como básicos e insatisfactorios), visualización y gestión de cada rendición. Además permite el ingreso de los documentos los cuales son el formato para asignar los costos rendidos por PSP. Este módulo es usado por dos perfiles del sistema; los Encargados Comunales y CPEIP. 6.2 HERRAMIENTAS DE DESARROLLO A continuación se describen cada una de las herramientas usadas en el desarrollo del módulo de rendiciones. 6.2.1 Python. Python es un lenguaje de programación interpretado o de script, con tipado dinámico, fuertemente tipado, multiplataforma y orientado a objetos. A continuación se explican cada una de sus características: Lenguaje interpretado o de script: se ejecuta utilizando un programa intermedio llamado intérprete, en lugar de compilar el código a lenguaje máquina que pueda comprender y ejecutar directamente una computadora (lenguajes compilados). Python tiene, no obstante, muchas de las características de los lenguajes compilados, por lo que se podría decir que es semi interpretado. En Python, como en Java y muchos otros lenguajes, el código fuente se traduce a un pseudo código máquina intermedio llamado bytecode la primera vez que se ejecuta, generando

11

archivos .pyc o .pyo (bytecode optimizado), que son los que se ejecutarán en sucesivas ocasiones. [12] Tipado dinámico : la característica de tipado dinámico se refiere a que no es necesario declarar el tipo de dato que va a contener una determinada variable, sino que su tipo se determinará en tiempo de ejecución según el tipo del valor al que se asigne, y el tipo de esta variable puede cambiar si se le asigna un valor de otro tipo. Fuertemente tipado: no se permite tratar a una variable como si fuera de un tipo distinto al que tiene, es necesario convertir de forma explícita dicha variable al nuevo tipo previamente. Por ejemplo, si tenemos una variable que contiene un texto (variable de tipo cadena o string) no podremos tratarla como un número (sumar la cadena “9” y el número 8). En otros lenguajes el tipo de la variable cambiaría para adaptarse al comportamiento esperado, aunque esto es más propenso a errores. Multiplataforma : el intérprete de Python está disponible en multitud de plataformas (UNIX, Solaris, Linux, DOS, Windows, OS/2, Mac OS, etc.). Orientado a objetos : se manejan clases y objetos, lo que permite durante la ejecución del programa una serie de interacciones entre los objetos. 6.2.2 Patrón de Diseño Modelo Vista Controlador. Es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista. A continuación se describe el patrón: • Modelo : esta es la representación específica de la información con la cual el

sistema opera. La lógica de datos asegura la integridad de estos y permite derivar nuevos datos; por ejemplo, no permitiendo comparar un número de unidades negativo, calculando si hoy es el cumpleaños del usuario o los totales, impuestos o importes en un carrito de la compra.

12

• Vista : este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.

• Controlador : este responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista.

Muchos sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar los datos: en MVC corresponde al modelo. Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente: • El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el

usuario pulsa un botón, enlace, etc.).

• El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback.

• El controlador accede al modelo, actualizándolo, posiblemente modificándolo

de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.

• El controlador delega a los objetos de la vista la tarea de desplegar la interfaz

de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, el patrón de observador puede ser utilizado para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista.

• La interfaz de usuario espera nuevas interacciones del usuario, comenzando el

ciclo nuevamente.

13

6.2.3 Django. Django es un framework de desarrollo Web de código abierto, escrito en Python. [7] La arquitectura de Django es la siguiente: Controlador: • Asocia consultas (URLs) a vistas. • Usa expresiones regulares para determinar las equivalencias. • Es capaz de capturar parámetros desde la URL. • El uso de expresiones regulares permite un primer nivel de validación. Vista: • Ejecuta las operaciones necesarias para devolver el HTML al cliente. • Es el encargado de la lógica de programa. • Hace uso del modelo para extraer los datos de la base de datos. • Hace uso de las plantillas para generar el código HTML. Modelo: • Define los objetos de nuestra base de datos. • Permite establecer relaciones entre los objetos. • Una vez definidos nos permite crearlos en la base de datos. • Una vez creados los objetos permite acceder a ellos cómodamente. Plantillas: • Permiten crear la presentación de los datos. • Genera HTML a partir de un código HTML y una serie de variables y

estructuras simples. • Las plantillas que incluye Django soportan herencia, bucles, bifurcaciones,

variables y filtros. Middleware: • Procesa los datos entre varios puntos del sistema. • Permite que todas las consultas y respuestas pasen una serie de filtros. • Django integra algunos como el manejo de sesiones o la autenticación.

14

Otras características de Django son: • Es modular. • Genera un panel de administración. • Soporta varias bases de datos (MySQL, SQLite, Postgres). • Un mapeador de objeto relacional. • Una API de base de datos robusta. • Un sistema extensible de plantillas basado en etiquetas, con herencia de

plantillas. • Un despachador de URLs basado en expresiones regulares. 6.2.4 JQuery. JQuery es una biblioteca o framework de JavaScript, que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM (Document Object Model – Modelo de Objetos del Documento) [4], manejar eventos, desarrollar animaciones y agregar interacción con la tecnología AJAX a páginas web. [9] Carateristicas:

• Selección de elementos DOM. • Interactividad y modificaciones del árbol DOM, incluyendo soporte para CSS. • Eventos. • Manipulación de la hoja de estilos CSS. • Efectos y animaciones. • AJAX. • Soporta extensiones.

6.2.5. AJAX. AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript Asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones. [14] AJAX es una tecnología asíncrona, en el sentido de que los datos adicionales se requieren al servidor y se cargan en segundo plano sin interferir con la visualización ni el comportamiento de la página. JavaScript es el lenguaje interpretado (scripting language) en el que normalmente se efectúan las funciones

15

de llamada de AJAX mientras que el acceso a los datos se realiza mediante XMLHttpRequest, objeto disponible en los navegadores actuales. AJAX es una combinación de cuatro tecnologías: • XHTML (o HTML) y hojas de estilos en cascada (CSS) para el diseño que

acompaña a la información. • Document Object Model (DOM) accedido con un lenguaje de scripting por parte

del usuario, especialmente implementaciones como JavaScript, para mostrar e interactuar dinámicamente con la información presentada.

• El objeto XMLHttpRequest para intercambiar datos de forma asíncrona con el servidor web.

• XML es el formato usado generalmente para la transferencia de datos solicitados al servidor, aunque cualquier formato puede funcionar, incluyendo HTML preformateado, texto plano, JSON (JavaScript Object Notation).

Figura 1. Tecnologías agrupadas bajo el concepto de AJAX

6.2.6. MySQL. MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario, el cual se caracteriza por su facilidad de uso, velocidad y flexibilidad para funcionar en diferentes sistemas operativos. Algunas características de MySQL son: • Procedimientos almacenados. • Disparadores (triggers). • Cursores. • Vistas actualizables. • Soporte a VARCHAR.

16

• Modo Strict. • Soporte X/Open XA de transacciones distribuidas; transacción en dos fases

como parte de esto, utilizando el motor InnoDB de Oracle. • Motores de almacenamiento independientes (MyISAM para lecturas rápidas,

InnoDB para transacciones e integridad referencial). • Transacciones con los motores de almacenamiento InnoDB, BDB Y Cluster;

puntos de recuperación (savepoints) con InnoDB. • Sub-SELECTs (o SELECTs anidados). MySQL es un sistema de administración relacional de bases de datos: una base de datos relacional archiva datos en tablas separadas en vez de colocar todos los datos en un gran archivo. Esto permite velocidad y flexibilidad. Las tablas están conectadas por relaciones definidas que hacen posible combinar datos de diferentes tablas sobre pedido. MySQL es software de fuente abierta: fuente abierta significa que es posible para cualquier persona usarlo y modificarlo. Cualquier persona puede bajar el código fuente de MySQL y usarlo sin pagar. Cualquier interesado puede estudiar el código fuente y ajustarlo a sus necesidades. MySQL usa el GPL (GNU General Public License) para definir qué puede hacer y que no puede hacer con el software en diferentes situaciones. Si usted no se ajusta al GPL o requiere introducir código MySQL en aplicaciones comerciales, usted puede comprar una versión comercial licenciada. [1] 6.2.7 WAE. WAE, acrónimo de Web Application Extension, es la convención más difundida y aceptada hasta nuestros días para el modelado de aplicaciones Web. Esta extensión se definió en 1998 por Jim Conallen. [2] Esta extensión define los siguientes estereotipos en clases: • ServerPage: son las páginas que contienen los scripts o código ejecutable en

el servidor. • ClientPage: son las páginas que están en el lado del cliente, normalmente

páginas HTML y jsvascript. • Form: es la representación de un formulario. Es código HTML que contiene

etiquetes de formulario como: <input>, <textarea>, etc.

17

A continuación se definen algunos estereotipos en relaciones: • Build: una relación entre una página servidor y una página cliente. • Link: es una relación entre una página y otra del sistema. • Submit: es una relación entre un formulario y un servidor de página.

18

7. OBJETIVOS

7.1 OBJETIVO GENERAL Desarrollar una aplicación computacional que permita reflejar y recopilar toda la financiación llevada a cabo para cada PSP, convirtiéndose así en un módulo de rendiciones para la aplicación PSP Online (Planes de Superación Profesional), el cual permita un modelo de información preciso y accesible para el diseño, registro, monitoreo, gestión y supervisión de las rendiciones de cada comuna implementadas en cada PSP, logrando así un acceso a la información de gastos permitiendo que se puedan dar las rectificaciones de una manera segura y eficiente por el CPEIP.

7.2 OBJETIVOS ESPECIFICOS 1. Analizar cada proceso involucrado en el manejo y desarrollo de las

rendiciones. 2. Elaborar el documento donde se especifiquen los requerimientos (SRS) o

necesidades del usuario y las funciones que realizara el software. 3. Diseñar un modelo de datos para el manejo de las rendiciones. 4. Implementar una base de datos que soporte el manejo de cada una de las

rendiciones por cada PSP. 5. Diseñar e implementar cada una de las interfaces gráficas para cada

funcionalidad revisadas en el proceso inicial de análisis. 6. Construir e implementar el módulo de rendiciones portal PSP Online. 7. Realizar y ejecutar un plan de pruebas funcionales para los formularios de

ingreso de datos para implantar el módulo con el menor número de no conformidades.

19

8. METODOLOGÍA Los pasos para el desarrollo del módulo de rendiciones son los siguientes: Análisis y Recopilación de la información : Reunir toda la información posible, de cómo es el proceso para el manejo de la rendición de gastos para cada comuna, establecer los controles, rectificaciones y revisiones dadas para cada PSP. Definir claramente como se lleva este proceso de rendiciones. Además realizar toda la documentación respectiva de cada herramienta, tecnología y lenguaje de programación a usar. Este punto de análisis es fundamental para el desarrollo, diseño e implementación del módulo de rendiciones, ya que es el paso donde se deberán aclarar todas las dudas y enfatizar en la funcionalidad de la aplicación orientada al proceso. Por otro lado realizar el análisis de requerimientos, el cual será base para el diseño de cada caso de uso en el sistema. Modelo de Datos : Diseñar un modelo de datos que se ajuste a todo el proceso de rendiciones, un modelo que permita ser escalable en cualquier momento y cumpla en su totalidad con el flujo de información que se maneja y refleje de una forma concisa el proceso en su totalidad. Se debe diseñar el modelo entidad relación (MER) el cual será la base para el desarrollo de la base de datos del sistema. Diseño e Implementación : Se deben de diseñar cada caso de uso para cada una de las funcionalidades del sistema mediante el análisis del proceso de la rendición de gastos. Implementar cada uno de estos casos de uso, obteniendo así una sincronización entre control implementado, interfaz y modelo de datos. Además de los casos de uso, se deben diseñar los diagramas de clase y secuencia, ya que permiten una definición y recopilación global del proceso con la aplicación, logrando transmitir una detallada operatividad del sistema. Implementación de la Base de Datos : Diseñando el MER de la aplicación, se deberá implementar este mismo a un motor base de datos, permitiendo la integración con la aplicación con el fin de controlar y gestionar el almacenamiento de los datos. Diseñar e implementar las interfaces gráficas : Luego de realizar el análisis y recopilación del proceso de rendición, se deberá diseñar cada una de las interfaces graficas, las cuales recopilarán la operatividad de la aplicación, por lo cual deben ser legibles y fáciles de interactuar. Hay que tener en cuenta que el proceso de las rendiciones está claramente reflejado en las interfaces. Elaborar un documento final que recopile toda la información descrita anteriormente, logrando una unificación del trabajo realizado y obteniendo así un

20

informe basado en la ingeniería de software, siendo capaz de reflejar un documento claro, preciso y detallado. Pruebas: En esta fase se realizaran las pruebas funcionales para los interfaces de ingreso de datos, las cuales permitirán que cuando sea liberado el módulo de rendiciones, salga con la menor cantidad de no conformidades.

21

9. DESARROLLO DEL PROYECTO En este capítulo se detalla el desarrollo del módulo de rendiciones para el portal PSP, el cual permitirá un mejor manejo y eficacia en las rendiciones de cada comuna.

9.1 ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE

A continuación se incluye información detallada sobre los requerimientos mínimos que se tuvieron en cuenta para el desarrollo del módulo de rendiciones del portal PSP. � Requerimientos Funcionales. Estos requisitos son las declaraciones que debe proporcionar el sistema, de la manera en que éste debe de reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. Ejemplos de estos requisitos son: cálculos, detalles técnicos y manipulación de datos. A continuación se detallan los requisitos funcionales de la aplicación:

• Ingresar nuevos documentos a la Base de Datos.

• Visualizar matriz de documentos.

• Ingresar notas de corrección para cada rendición.

• Visualizar costos rendidos por actividad para cada documento.

• Visualizar cuadros de costo efectivo, el cual reúne la información de los costos estimados y los rendidos.

• Aprobación de la rendición por parte de CPEIP.

• Ingresar formulario de documentación física para el envío posterior de la rendición a CPEIP.

• Generar reporte de las rendiciones para las comunas con la información de costos rendidos, costos estimados y estado de la rendición.

• Consultar rendición para cada comuna.

• Imprimir matriz de documentos.

• Imprimir documento.

• Enviar rendición a CPEIP para que sea revisada y evaluada.

22

� Requerimientos No Funcionales. Estos requisitos son aquellos que definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema. Ejemplos de estos requisitos: la fiabilidad y la capacidad de almacenamiento. [16] A continuación se detallan los requisitos no funcionales de la aplicación: • El sistema debe de operar y funcionar bajo cualquier plataforma. • Los colores y diseño de las interfaces debe de ser seleccionadas por el usuario final. • Las restricciones de duplicidad de los datos debe ser manejada tanto por la aplicación como de la base de datos.

� Requerimientos de infraestructura.

• Espacio en disco de 4GB. • 1GB de Memoria RAM. • Navegadores de Internet (browser):

o Firefox 1.7 o superior. o Microsoft Internet Explorer 6.0 o superior.

• Apache.

9.1.1 Listado de Casos de Uso. El caso de uso es simplemente un texto escrito que describe el papel de un actor que interactúa con el acontecer del sistema. Para el módulo de rendiciones, los casos de uso son los siguientes:

1. Ingresar documento. 2. Modificar documento. 3. Eliminar documento. 4. Imprimir documento. 5. Consultar costos rendidos por actividad. 6. Imprimir matriz de documentos. 7. Consultar cuadro de costo efectivo. 8. Enviar rendición a CPEIP. 9. Ingresar formulario de documentación física. 10. Consultar notas de corrección. 11. Consultar matriz de documentos.

23

12. Ingresar nota de corrección. 13. Recibir rendición. 14. Rechazar rendición (en corrección). 15. Enviar rendición a desarrollo. 16. Aprobar rendición. 17. Consultar rendición. 18. Generar reporte de rendiciones.

9.1.2 Listado de Actores. Actor es toda entidad (persona o sistema) externa al sistema que guarda una relación con este y que le demanda una funcionalidad. Para el caso de las personas, estos se pueden ver como definiciones de rol, por lo que un mismo individuo puede corresponder a uno o más actores. A continuación se presentan los actores de este módulo: • Encargado Comunal. • CPEIP.

9.1.3 Descripción ó guiones de casos de uso. Los guiones son una secuencia detallada de pasos que describen la interacción entre el usuario y la aplicación, con el fin de especificar la comunicación y el comportamiento de un sistema mediante su interacción con los actores. [15] A continuación se mostrará el guión para el caso de uso N.12 ingresar nota de corrección.

24

Tabla 1. Guión ingresar nota de corrección Número: 12

Nombre: Ingresar Nota de Corrección.

Descripción: El usuario puede ingresar una nota de corrección a través del asunto y descripción de la nota. Actor(es): CPEIP

Usuario Sistema

1. Digita el asunto de la nota.

2. Valida que el asunto de la nota sea un texto adecuado.

3. Digita la descripción de la nota. 4. Valida que la descripción de la nota

sea un texto adecuado. 5. Almacena los datos de la nota en la

base de datos. 6. Muestra mensaje “Acaba de ingresar

una nota de corrección”. 7. Termina. Excepciones. Debe escribir un nombre más adecuado. 2. Valida que el asunto de la nota tenga al

menos 5 caracteres. 8. Muestra mensaje “Debe escribir un

nombre más adecuado”. 9. Vuelve a punto 1. Debe escribir un mensaje más adecuado. 4. Valida que el asunto de la nota tenga al

menos 5 caracteres. 10. Muestra mensaje “Debe escribir un

mensaje más adecuado” 11. Vuelve al punto 3. Precondición: Haber ingresado a la matriz de documentos. Poscondición: Se ingresa la nota de corrección. Casos de uso relacionados:

25

9.1.4 Diagramas de clase. Este tipo de diagrama es una descripción de las clases en un sistema y sus relaciones. A continuación se muestra uno de los diagramas de clase usando WAE (ver Figura 2). Figura 2. Diagrama de clase WAE caso de uso N.12

9.1.5 Diagramas de secuencia. Estos tipos de diagrama permiten visualizar como durante la ejecución de un sistema orientado a objetos, los objetos interactúan entre sí. A continuación se mostrará el diagrama de secuencia para ingresar nota de corrección (ver Figura 3), los demás diagramas de secuencia podrán ser observados en los Anexos (en los anexos 3) que se encuentran al final de documento.

26

Figura 3. Diagrama de secuencia caso de uso N.12

9.2 ANÁLISIS Y DISEÑO

9.2.1 Diagrama relacional de casos de uso. A continuación se muestra gráficamente (ver Figura 4) a que recursos o casos de uso tendrán acceso los actores (Encargado Comunal y CPEIP).

27

Figura 4. Diagrama relacional de casos de uso.

9.2.2 Modelado del software. Para el modelado de software se implementó RUP (Rational Unified Process). RUP es un proceso de desarrollo de software iterativo, con arquitectura centrada. [13] Se utilizó este modelado debido a que no es un sistema de pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. Por otro lado es una secuencia de pasos incrementales o iteraciones, por lo que cada iteración incluye parte o la mayoría de las disciplinas de desarrollo (requerimientos, análisis, diseño e implementación).

28

9.2.3 Arquitectura de software. Para la arquitectura se implementó el patrón MVC (Modelo Vista Controlador), ya que me permite la separación de los datos de una aplicación, la interfaz de usuario y la lógica de control en tres componentes distintos. Además que es un modelo altamente usado en aplicaciones Web. A continuación se presenta el patrón MVC de la aplicación: Controlador - Vista: ejecuta las operaciones necesarias para devolver el HTML al cliente, además hace uso del modelo para extraer los datos de la base de datos. Modelo: define los objetos de la base de datos, por otro lado permite establecer relaciones entre los objetos. Plantilla: permiten crear la presentación de los datos y generar HTML a partir de una serie de variables y estructuras simples. [6] Figura 5. Esquema MVC en Django.

En la figura 5 se muestra como el controlador a través de una URL accede a la vista la cual ejecuta las consultas necesarias mediante las relaciones de la base de datos, esta información es agregada a la plantilla para que pueda ser vista por el usuario.

29

9.2.4 Modelado de la base de datos. Para el almacenamiento de los datos, se implementó del modelo entidad relación (ver Figura 6), ya que permite expresar las entidades del sistema con sus interrelaciones y propiedades. Además se pueden visualizar los objetos que pertenecen a la Base de Datos.

30

Figura 6. Modelo Entidad Relación.

31

9.3 IMPLEMENTACIÓN A continuación se detallan cada una de las herramientas usadas para desarrollar e implementar el módulo de rendiciones.

9.3.1 Lenguaje de Programación. Debido a que el desarrollo del módulo de rendiciones debía de ser un desarrollo eficaz y rápido, se decidió usar Python, debido al tiempo de aprendizaje que requiere y con la opción de integrarlo a un Web framework, para una implementación mucho mas dinámica. Un conjunto de motivos por los cuales se determinó el uso de Python es su sintaxis clara, sencilla y simple, la gran cantidad de librerías disponibles, el gestor de memoria y la potencia del lenguaje, entre otros, que hacen que desarrollar una aplicación en Python sea muy rápido. Además que es un lenguaje cercano al lenguaje natural permitiendo que los programas elaborados en Python parezcan pseudocódigo.

9.3.2 Framework de desarrollo Web. Para permitir un desarrollo mucho más estructurado y sencillo, se decidió optar en la implementación de un framework de desarrollo Web para Python. Actualmente Python soporta muchos de estos, entre los cuales se encuentran: Django, Grok, Pylons, TurboGears, entre otros. Escoger la estructura de soporte apropiada fue una tarea difícil debido a la variedad y las ventajas que cada uno tiene. La decisión final se baso principalmente en la experiencia, esto se debe a que la empresa ya había desarrollado bajo uno de los frameworks, por lo que existía una documentación y un aprendizaje previo. Por esta razón se seleccionó a Django, el cual posee mucha documentación en la red, y su sitio Web (www.djangoproject.com) está muy bien organizado y explicito.

9.3.3 Bases de datos. Para la selección del motor base de datos se tuvieron en cuenta dos fundamentos claves. El primero, que debía de ser una base de datos que fuera muy utilizada en aplicaciones Web. Segundo, que debía de respaldar su configuración con Django mediante una gran documentación. Debido a estos dos fundamentos, se escogió MySQL. Esto se debe a que en las aplicaciones Web con MySQL hay baja

32

concurrencia en la modificación de datos y en cambio el entorno es intensivo en lectura de datos, por lo que es ideal para este tipo de aplicaciones. Por último, en la integración con Django existe mucha documentación, y la gran cantidad de ejemplos funcionan con una conexión a MySQL, convirtiéndolo en el único candidato en la unificación con el framework.

9.3.4 Lenguaje utilizado en la interfaz. Para la interfaz grafica se uso el lenguaje CSS (Cascading Style Sheets hojas de estilo en cascada), las cuales me permiten definir la presentación de un archivo estructurado escrito en HTML o XML. La ventaja de las hojas de estilo en cascada, es que si deseo agregar o modificar alguna propiedad a alguna etiqueta, tales como fuentes, color, fondo, texto, margen, borde, entre otros, solo debo de editar o anexar al archivo que contiene CSS y no realizar un cambio en toda la aplicación en cada una de las propiedades de etiqueta para que se vea reflejado el cambio.

9.3.5 Librerías externas. Se debía de analizar la forma en que se realizarían las validaciones de los campos en los formularios de una manera ágil. Para remediar esta tarea, se decidió agregar una librería que se encargara de estas validaciones, las cuales en muchos casos pueden ser muy complejas. En este caso se incluyo jQuery, la cual es una librería JavaScript que permite manejar eventos, animaciones, validaciones para correos, formato para campos de fecha y moneda, implementación de Ajax, etc.…

9.3.6 Interfaces de la aplicación. A continuación se muestran algunas interfaces de usuario desarrolladas para el módulo de rendiciones para la aplicación PSP.

9.3.6.1 Formulario de ingresar documento. En el siguiente formulario, los Encargados Comunales agregan documentos para empezar con el proceso en el modulo de rendiciones. Debido a que el formulario es muy amplio, se mostrara en dos partes (ver Figura 7 y 8).

33

Figura 7. Formulario Ingresar Documento (A).

Figura 8. Formulario Ingresar Documento (B).

34

9.3.6.2 Formulario matriz de documentos. En el siguiente formulario, el usuario Encargado Comunal, puede ver el estado de su rendición, el número de documentos ingresados, las actividades asociadas al documentos, entre otros (ver Figura 9). Figura 9. Formulario Matriz de Documentos.

9.3.6.3 Formulario ingresar nota de corrección. En el siguiente formulario, el usuario CPEIP ingresa las notas de corrección para la rendición en una comuna (ver Figura 10).

35

Figura 10. Formulario Ingresar Nota de Corrección.

36

9.4 PRUEBAS Para el módulo de rendiciones para el portal PSP, se realizaron las siguientes pruebas: • Pruebas unitarias Permiten probar cada una de las funcionalidades de manera independiente y de esta manera hallar no conformidades con el sistema. Estas pruebas son realizadas a los formularios de ingreso de datos, ej: ingresar documentos. Cabe mencionar que el módulo de rendiciones es tan solo una parte del portal PSP, por lo que solo pertenecen al proceso de rendiciones. En la tabla 2 se detalla una de las pruebas unitarias que se realizaron para el módulo de rendiciones. Tabla 2. Prueba unitaria para el caso de uso ingresar documento.

Prueba unitaria Caso de uso No 1 ingresar documento.

Descripción de la prueba Se ingresarán los campos nombre, número, RUT, descripción del documento ( __222, xxxxx, 12345r4-5, __333 ).

Resultado esperado Se espera que el sistema envíe un mensaje de error para cada uno de los campos, con el objetivo de que valide el formato de cada uno de ellos.

Resultado de la prueba Esta prueba de software cumplió a cabalidad con el requerimiento que se esperaba, que fuera el de validar los campos del documento enviando un mensaje de error para cada uno de los campos.

37

10. CONCLUSIONES En el desarrollo de este proyecto se aplicaron temas vistos en los cursos de Ingeniería de Software, Bases de Datos, Aseguramiento de la Calidad de Software, tales como; diagramas de secuencia, descripción de casos de uso, modelo entidad relación, modelo relacional de datos, plan de pruebas, etc., y muchos de estos conceptos aprendidos fueron fundamentales para la correcta ejecución de este. El emplear RUP como modelo de desarrollo de software, permitió un desarrollo eficaz a través de sus 4 fases (Inicio, Elaboración, Construcción y Transición), las cuales brindaron un control sobre cada uno de los pasos del proyecto y una organización durante el ciclo de desarrollo del módulo de rendiciones. La elaboración del plan de pruebas, logró que el módulo presentara el menor número de no conformidades y se alcanzaran todos los objetivos proyectados. El aplicar un framework de desarrollo Web (Django), permitió una implementación mucho más ágil y segura, debido a que Django dentro de sus paquetes; incluye funciones y métodos que brindaron al sistema mayor confiabilidad y seguridad en las transacciones, mediante algoritmos de encriptación. Al realizar el desarrollo del proyecto usando Python y su integración con Django, se pudo cumplir con los tiempos de entrega al cliente y se garantizó la accesibilidad al modulo para los usuarios, pues facilito el acoplamiento entre diferentes tecnologías de desarrollo y permitió hacer abundante reutilización de funciones. El buen análisis detallado, estructurado y organizado en el inicio de la elaboración del módulo de rendiciones, permitió una implementación eficaz y dinámica, ya que las correcciones presentadas fueron muy pocas y mínimas durante el desarrollo del módulo, lo que facilitó que se ejecutaran de manera correcta los requerimientos establecidos. Esto se debe a que se estableció claramente los pasos para realizar el proceso. El módulo de rendiciones cumplió las metas fijadas y solucionó la gran cantidad de inconvenientes que surgían en el pasado, como la demora de la confirmación del comprobante del envío físico de los documentos, además de la demora en acceso a la información, ya que anteriormente se debía esperar a que llegaran los documentos en formato físico para verificar y corregir información. Ahora con la implementación del módulo, se agilizo por completo el proceso anterior; se accede con agilidad a la información en tiempo real, los tiempos de respuesta son rápidos entre cada uno de los procesos y existe una rápida comunicación entre los Encargados Comunales y CPEIP.

38

El módulo de rendiciones es una cosecha de conocimiento adquirido para brindar y desarrollar software, el cual permite que se mejoren y agilicen los procesos internos de una compañía, entidad u organización.

39

11. RECOMENDACIONES Luego de haber realizado la aplicación del modulo de rendiciones para el portal PSP, el desarrollador sugiere las siguientes recomendaciones para aquellas personas que deseen continuar con el proyecto, o hacerlo parte de una investigación: Optimizar las consultas para la parte del reporte de rendiciones en el perfil CPEIP, ya que a la hora de mostrar el reporte tarda mucho tiempo. Debido a que Django para sus consultas usa sus propios métodos de búsqueda, que construyen la consulta al SQL equivalente, la positivo de este aspecto es que permite realizar consultas de manera muy sencilla, pero su lado débil se presenta al involucrar consultas con muchas tablas. Por lo anterior se recomienda revisar las consultas para el reporte y mientras el Framework libere mecanismos que optimicen este tipo de consultas, reconstruir las consultas en SQL puro. Agregar a la matriz de documentos un Data Grid, esto con el objetivo de poder organizar la información, sea por tipo de documento, tipo de ítem de pago, número de documento, etc., con el objetivo de poder agrupar y visualizar los registros de manera más agradable, para que la usabilidad para el usuario sea mucho más sencilla y pueda obtener información que le pueda ser más útil. Por último, actualizar la versión del Django (1.0) una vez se libere la nueva, ya que incluirá mejoras, nuevas funciones y paquetes, que permitirán ayudar a los perfiles Encargado Comunal y CPEIP y a enriquecer el módulo de rendiciones.

40

BIBLIOGRAFÍA [1] COBO, Ángel. PHP y MySQL Tecnologías para el desarrollo de aplicaciones web. primera edición. España. Ediciones Díaz de Santos. 2005. 339 p. [2] CONALLEN, Jim. Building Web Applications with UML. segunda edición. Boston. Addison Wesley. 2002. 350 p. [3] CORTÉS, Flavio. Planes de Superación Profesional: una alternativa de desarrollo profesional ligada a la evaluación docente [en línea]. Santiago de Chile. Chile. Centro Medición MIDE. 2007. [Consultado 18 de Febrero de 2008]. Disponible en Internet: www.mideuc.cl/docs/seminario/Cortes_Flavio_Seminario_MIDE_UC_02_10_2007.pdf [4] CUALIFICACION, Innovación y. Javascript. Málaga. Ediciones Innova. 2001. 10 p. [5] Definición Planes de Superación Profesional [en línea]: En que consisten los Planes de Superación Profesional. Santiago de Chile. Chile. 2004. [Consultado 16 de Febrero de 2009] Disponible en Internet: http://www.cpeip.cl/website/index2.php?id_portal=1&id_contenido=86 [6] Django: Framework MVC en Python [en línea]: El Framework para perfeccionistas con fecha límite. Madrid. España. 2008. [Consultado 1 de Noviembre de 2009]. Disponible en Internet: www.whyfloss.com/en/conference/madrid08/getpdf/62 [7] Documentación Django [en línea]: Django The Web Framework for perfectionists with deadlines. Culver City. California. Estados Unidos. 2007. [Consultado 10 de Marzo de 2009] Disponible en Internet: http://docs.djangoproject.com/en/dev/intro/tutorial01/#intro-tutorial01 [8] Documentación Evaluación Docente [en línea]: ¿En que consiste la Evaluación Docente? Santiago de Chile. Chile. 2006. [Consultado 16 de Febrero de 2009] Disponible en Internet: http://www.atinachile.cl/node/10148 [9] Documentación JQuery [en línea]: Jquery. Culver City. California. Estados Unidos. 2006. [Consultado 21 de Marzo de 2009] Disponible en Internet: http://dizque.lacalabaza.net/sotanos/2006/05/introduccion-a-jquery/

41

[10] Documentación Software Manejo de Rendiciones [en línea]: Report System: Software de Comercio Exterior. Buenos Aires. Argentina. 1989. [Consultado 08 de Febrero de 2009] Disponible en Internet: http://www.reportsystem.com.ar/Zona.php?name=Content&pa=showpage&pid=1 [11] Documentación Software Manejo de Rendiciones [en línea]: DATAHOUSE COMPANY: Software de gestión comercial. Buenos Aires. Argentina. 2008. [Consultado 08 de Febrero de 2009] Disponible en Internet: http://www.datahousecompany.com.ar/comercial1.html [12] DUQUE, Raúl González. Python Para Todos. España. Creative Commons Attribution ShareAlike 2.0, 2008. 7 p. [13] KROLL, Per y KRUCHTEN, Philipe. The Rational Unified Process Made Easy A Practitioners Guide to the RUP. cuarta edición. Boston. Addison Wesley. 2003. 3 p. [14] MAXWELL, John. Ajax un juego de niños. España. KnowWare E.U.R.L.. 2005. 12 p. [15] PRESSMAN, Roger S. Ingeniería Del software un enfoque practico. quinta edición. Madrid. MacGraw-Hill/interamericana de España. 2002. 187 p. [16] SOMMERVILLE, Ian. Ingeniería de Software. séptima edición. México. Pearson – Addison Wesley. 2005. 110-111 p.

42

GLOSARIO

Ajax: es un estilo de programación que permite al desarrollador hacer que una página Web interactué con el servidor Web que la aloja. AJAX es una filosofía, el cual está compuesto de 4 elementos: JavaScript, el objeto XMLHttpResuqest, una aplicación del lado del servidor y CSS. Apache: es un servidor Web HTTP de código abierto, que implementa el protocolo HTTP/1.1 y la noción de sitio virtual. Aplicación Web: es una aplicación software que se codifica en un lenguaje soportado por los navegadores Web (HTML, JavaScript, Java, PHP, etc.). CSS: es el lenguaje que se utiliza para aplicar reglas de estilo a los documentos HTML, por ejemplo sobre fuentes y posicionamiento. Data Grid: es una interfaz de usuario bastante típica, que sirve para visualizar información en una tabla. La información suele ser un conjunto de registros, y se suelen mostrar cada uno de ellos en una fila. Además, los Data Grid suelen tener integradas funcionalidades para la ordenación de los datos y opciones para su edición o borrado. Django: es un framework de desarrollo web de código abierto, escrito en Python, que cumple el paradigma Modelo Vista Controlador.

Framework de desarrollo web: es una estructura de soporte definida, mediante la cual otro proyecto de software puede ser organizado y desarrollado. Típicamente, puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros software para ayudar a desarrollar y unir los diferentes componentes de un proyecto. Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. Provee una estructura y una metodología de trabajo la cual extiende o utiliza las aplicaciones del dominio.

HTML: siglas de HyperText Markup Language (Lenguaje de Marcas de Hipertexto), es el lenguaje de marcado predominante para la construcción de páginas web. Es usado para describir la estructura y el contenido en forma de texto, así como para complementar el texto con objetos tales como imágenes. HTML se escribe en forma de "etiquetas", rodeadas por corchetes angulares (<,>). JavaScript: es un lenguaje compacto, y basado en objetos, diseñado para el desarrollo de aplicaciones cliente-servidor a través de Internet. jQuery: es una librería de JavaScript ágil y concisa que simplifica el cambio en las platillas HTML, manejo de eventos, animación, e interacciones Ajax para un

43

desarrollo web rápido. JQuery está diseñado para cambiar la forma como se escribe JavaScript. MySQL: es un sistema de administración de base de datos relacionales rápido, sólido y flexible. Es ideal para crear base de datos con acceso desde páginas web dinámicas, para la creación de sistemas de transacciones on-line o para cualquier otra solución profesional que implique almacenar datos. Python: Python es un lenguaje interpretado o de script, con tipado dinámico, fuertemente tipado, multiplataforma y orientado a objetos. RUP: Proceso Unificado de Rational; modelo de proceso del software genérico que presenta el desarrollo del software como una actividad iterativa de cuatro fases que son inicio, elaboración, construcción y transición. SQL: siglas de Structured Query Language en español Lenguaje de consulta estructurado, es un lenguaje declarativo de acceso a base de datos relacionales que permite especificar diversos tipos de operaciones en estas. UML: siglas en ingles de Unified Modeling Language en español Lenguaje Unificado de Modelado, permite la realización de los diagramas de clase, secuencia, permitiendo estandarizar todo el proceso de desarrollo y diseño. WAE : siglas en ingles de Web Application Extension, consiste en un método para modelar aplicaciones Web mediante UML. XML: siglas en ingles de Extensible Markup Language (lenguaje de marcas extensible), es un metalenguaje de marcado de texto que soporta el intercambio de datos estructurados. Cada campo de datos se delimita por etiquetas que proporcionan información sobre ese campo.

44

ANEXOS

ANEXO 1: Diagramas de Casos de Uso

Caso de Uso 1. Guión ingresar documento. Número: 01 Nombre: Ingresar Documento.

Descripción: El usuario puede ingresar un documento por medio de la información requerida. Actor(es): Encargado Comunal Flujo Básico

Usuario Sistema

1. Digita el nombre del documento.

2. Valida que el nombre del documento sea texto adecuado.

3. Selecciona el tipo de documento. 4. Valida que se seleccione un tipo de

documento. 5. Selecciona el tipo de ítem de pago.

6. Valida que se seleccione un ítem de pago.

7. Digita el número del documento. 8. Valida que el número del documento

sea un valor numérico. 9. Digita el RUT del documento. 10. Valida que el RUT ingresado. 11. Digita la descripción del documento.

12. Valida que la descripción del documento sea un texto adecuado.

13. Selecciona la fecha del documento.

14. Valida que se selecciona una fecha para el documento.

15. Digita el monto total del documento.

16. Valida que el monto total del documento sea ingresado.

45

Flujo Alternativo1 17. Selecciona la opción “si” para ¿el monto total del documento corresponde por completo al monto a rendir por el PSP?”

18. El sistema muestra el monto total del documento.

Flujo Alternativo2 19. Selecciona la opción “no” para ¿el monto total del documento corresponde por completo al monto a rendir por el PSP?”

19. Digital el monto a rendir por el PSP.

20. Valida que el monto a rendir por el PSP sea ingresado.

Flujo Básico 21. Selecciona las actividades que serán financiadas por el CPEIP.

22. Valida que al menos una actividad sea seleccionada.

Flujo Alternativo1 23. Selecciona la opción “si” para ¿el monto a rendir CPEIP se distribuye en partes iguales entre las actividades seleccionadas?

24. El sistema muestra la asignación de montos para cada una de las actividades seleccionadas.

Flujo Alternativo2 25. Selecciona la opción “no” para ¿el monto a rendir CPEIP se distribuye en partes iguales entre las actividades seleccionadas?

26. Digita el monto para cada una de las actividades seleccionadas.

27. Valida que el monto sea ingresado para cada una de las actividades.

Flujo Básico 28. Selecciona la opción Guardar. 29. Muestra el mensaje “El ingreso del

documento se realizó exitosamente”. 30. Termina. Excepciones.

46

Nombre de documento no es adecuado. 2. Valida el nombre del documento tenga

al menos 5 caracteres. 31. Muestra el mensaje “Debe escribir un

nombre más adecuado”. 32. Vuelve a punto 1. Seleccione un tipo de documento. 4. Valida que se seleccione un tipo de

documento. 33. Muestra el mensaje “Seleccione un

tipo de documento”. 34. Vuelve a punto 3. Seleccione un tipo de ítem de pago para el documento. 6. Valida que se seleccione un ítem de

pago. 35. Muestra el mensaje “Selección un tipo

de ítem de pago”. 36. Vuelve a punto 5. Número del documento no es un valor numérico. 8. Valida que el número del documento

sea un valor numérico. 37. Muestra el mensaje “Ingrese un valor

numérico para el documento”. 38. Vuelve a paso 7. RUT del documento no es válida. 10. Valida el RUT del documento. 39. Muestra el mensaje “Ingrese el RUT

sin puntos y con guión de esta forma: 12345678-9”.

40. Vuelve a paso 9. Ingrese una descripción para el documento. 12. Valida la descripción del documento. 41. Muestra el mensaje “Debe escribir

una descripción más adecuada”. 42. Vuelve a punto 11. Ingrese el monto total del documento. 16. Valida que el monto total de

documento sea ingresado. 43. Muestra el mensaje “Debe ingresar el

monto total del documento”. 44. Vuelve a punto 15. Ingrese el monto a rendir por el PSP. 20. Valida que el monto a rendir por el

47

PSP sea ingresado. 45. Muestra el mensaje “Debe ingresar el

monto a rendir por el PSP”, “El monto ingresado es mayor al monto total”.

46. Vuelve a punto 19. Seleccione las actividades que serán financiadas por el PSP. 22. Valida que al menos una actividad

sea seleccionada. 47. Muestra el mensaje “¡No sea ha

seleccionado ninguna actividad!”. 48. Vuelve a punto 21. Ingrese el monto para cada una de las actividades seleccionadas. 27. Valida que el monto sea ingresado

para cada una de las actividades. 49. Muestra el mensaje “No ha ingresado

el monto para la actividad y ¡¡Verifique los montos de cada actividad!! La suma de los montos difiere del monto a rendir”.

50. Vuelve a punto 26. Precondición: Haber ingresado a la matriz de documentos. Poscondición: Se ingresa el documento. Casos de uso relacionados:

Caso de Uso 2. Guión modificar documento.

Número: 02 Nombre: Modificar Documento.

Descripción: El usuario puede modificar un documento. Actor(es): Encargado Comunal Flujo Básico

Usuario Sistema

1. Selecciona el documento de la matriz de documentos.

2. Modifica el nombre del documento.

3. Valida que el nombre del documento sea texto adecuado.

4. Modifica el tipo de documento. 5. Valida que se seleccione un tipo de

documento. 6. Modifica el tipo de ítem de pago. 7. Valida que se seleccione un ítem de

48

pago. 8.Modifica el número del documento. 9. Valida que el número del documento

sea un valor numérico. 10. Modifica el RUT del documento. 11. Valida que el RUT sea ingresado. 12. Modifica la descripción del documento.

13. Valida que la descripción del documento sea un texto adecuado.

14. Modifica la fecha del documento. 15. Valida que se selecciona una fecha

para el documento. 16. Modifica el monto total del documento.

17. Valida que el monto total del documento sea ingresado.

Flujo Alternativo1 18. Selecciona la opción “si” para ¿el monto total del documento corresponde por completo al monto a rendir por el PSP?”

19. El sistema muestra el monto total del documento.

Flujo Alternativo2 20. Selecciona la opción “no” para ¿el monto total del documento corresponde por completo al monto a rendir por el PSP?”

21. Modifica el monto a rendir por el PSP.

22. Valida que el monto a rendir por el PSP sea ingresado.

Flujo Básico 23. Selecciona las actividades que serán financiadas por el CPEIP.

24. Valida que al menos una actividad sea seleccionada.

Flujo Alternativo1 25. Selecciona la opción “si” para ¿el monto a rendir CPEIP se distribuye en partes iguales entre las actividades seleccionadas?

26. El sistema muestra la asignación de

49

montos para cada una de las actividades seleccionadas.

Flujo Alternativo2 27. Selecciona la opción “no” para ¿el monto a rendir CPEIP se distribuye en partes iguales entre las actividades seleccionadas?

28. Modifica el monto para cada una de las actividades seleccionadas.

29. Valida que el monto sea ingresado para cada una de las actividades.

Flujo Básico 30. Selecciona la opción Guardar. 31. Muestra el mensaje “La modificación

del documento se realizó exitosamente”. 32. Termina. Excepciones. Nombre de documento no es adecuado. 3. Valida el nombre del documento tenga

al menos 5 caracteres. 33. Muestra el mensaje “Debe escribir un

nombre más adecuado”. 34. Vuelve a punto 2. Seleccione un tipo de documento. 5. Valida que se seleccione un tipo de

documento. 35. Muestra el mensaje “Seleccione un

tipo de documento”. 36. Vuelve a punto 4. Seleccione un tipo de ítem de pago para el documento. 7. Valida que se seleccione un ítem de

pago. 37. Muestra el mensaje “Selección un tipo

de ítem de pago”. 38. Vuelve a punto 6. Número del documento no es un valor numérico. 9. Valida que el número del documento

sea un valor numérico. 39. Muestra el mensaje “Ingrese un valor

numérico para el documento”. 40. Vuelve a paso 7. RUT del documento no es válido. 11. Valida el RUT del documento.

50

41. Muestra el mensaje “Ingrese el RUT sin puntos y con guión de esta forma: 12345678-9”.

42. Vuelve a paso 10. Ingrese una descripción para el documento. 13. Valida la descripción del documento. 43. Muestra el mensaje “Debe escribir

una descripción más adecuada”. 44. Vuelve a punto 12. Ingrese el monto total del documento. 17. Valida que el monto total de

documento sea ingresado. 45. Muestra el mensaje “Debe ingresar el

monto total del documento”. 46. Vuelve a punto 16. Ingrese el monto a rendir por el PSP. 22. Valida que el monto a rendir por el

PSP sea ingresado. 47. Muestra el mensaje “Debe ingresar el

monto a rendir por el PSP”, “El monto ingresado es mayor al monto total”.

48. Vuelve a punto 21. Seleccione las actividades que serán financiadas por el PSP. 24. Valida que al menos una actividad

sea seleccionada. 49. Muestra el mensaje “¡No sea ha

seleccionado ninguna actividad!”. 50. Vuelve a punto 23. Ingrese el monto para cada una de las actividades seleccionadas. 29. Valida que el monto sea ingresado

para cada una de las actividades. 51. Muestra el mensaje “No ha ingresado

el monto para la actividad y ¡¡Verifique los montos de cada actividad!! La suma de los montos difiere del monto a rendir”.

52. Vuelve a punto 30. Precondición: Haber ingresado a la matriz de documentos y haber ingresado al menos un documento. Poscondición: Se modifica el documento. Casos de uso relacionados:

51

Caso de Uso 3. Guión eliminar documento. Número: 03

Nombre: Eliminar Documento.

Descripción: El usuario puede eliminar los documentos de la matriz de documentos. Actor(es): Encargado Comunal

Usuario Sistema

1. Selecciona la opción de eliminar.

Flujo Alternativo1 2. Selecciona la opción “no” para ¿Desea eliminar el documento?

3. Vuelve a la matriz de documentos. 4. Termina. Flujo Alternativo2 5. Selecciona la opción “si” para ¿Desea eliminar el documento?

6. El sistema elimina el documento. 7. Termina. Excepciones. Precondición: Haber ingresado a la matriz de documentos y haber ingresado al menos un documento. Poscondición: Se elimina el documento y vuelve a la matriz de documentos. Casos de uso relacionados:

Caso de Uso 4. Guión imprimir documento.

Número: 04 Nombre: Imprimir Documento.

Descripción: El usuario puede imprimir un documento. Actor(es): Encargado Comunal

Usuario Sistema

1. Selecciona un documento.

2. Selecciona la opción imprimir. 3. El sistema imprime el documento. 4. Termina. Excepciones.

52

Precondición: Haber ingresado a la matriz de documentos. Poscondición: Se imprime el documento. Casos de uso relacionados:

Caso de Uso 5. Guión consultar costos rendidos por actividad.

Número: 05 Nombre: Consultar Costos Rendidos por Actividad.

Descripción: El usuario puede consultar los costos rendidos por actividad en cada documento. Actor(es): Encargado Comunal

Usuario Sistema

1. Selecciona la opción de “ACTIVIDADES ASOCIADAS AL DOCUMENTO”.

2. El sistema valida que el documento tenga actividades asociadas.

3. El sistema muestra cada una de las actividades asociadas al documento, con sus respectivos costos.

4. Termina. Excepciones. Error al leer las actividades. 2. El sistema valida que el documento

tenga actividades asociadas. 5. Muestra el mensaje de error: “Error al

leer las actividades”. 6. Vuelve al punto 1. Precondición: Haber ingresado a la matriz de documentos y haber ingresado al menos un documento. Poscondición: Se muestran las actividades asociadas al documento. Casos de uso relacionados:

Caso de Uso 6. Guión imprimir matriz de documentos.

Número: 06 Nombre: Imprimir Matriz de Documentos.

Descripción: El usuario puede imprimir la matriz de documentos. Actor(es): Encargado Comunal

Usuario Sistema

1. Selecciona la opción imprimir.

53

2. El sistema imprime el documento. 3. Termina. Excepciones. Precondición: Haber ingresado a la matriz de documentos. Poscondición: Se imprime la matriz de documentos. Casos de uso relacionados:

Caso de Uso 7. Guión consultar cuadro de costo efectivo.

Número: 07 Nombre: Consultar Cuadro de Costo Efectivo.

Descripción: El usuario puede consultar el cuadro de costo efectivo para cada rendición. Actor(es): Encargado Comunal

Usuario Sistema

1. Selecciona la opción “Ver CUADRO RESUMEN DE COSTO EFECTIVO”.

2. El sistema muestra el cuadro resumen de costo efectivo.

3. Termina. Excepciones. Precondición: Haber ingresado a la matriz de documentos. Poscondición: Muestra el cuadro resumen de costo efectivo. Casos de uso relacionados:

Caso de Uso 8. Guión enviar rendición a CPEIP.

Número: 08 Nombre: Enviar Rendición a CPEIP.

Descripción: El usuario envía la rendición a CPEIP para que esta pueda ser revisada. Actor(es): Encargado Comunal

Usuario Sistema

1. Selecciona la opción “Enviar Rendición”.

Flujo Alternativo1 2. Selecciona la opción “Cancelar” para “Está a punto de enviar la

54

rendición online de su PSP. Una vez enviada no tendrá la opción de agregar o modificar los documentos. Si usted está seguro de que ha registrado la totalidad de los documentos presione Aceptar, de lo contrario Cancelar para volver a la Matriz de Documentos.” 3. Vuelve a la matriz de documentos. 4. Termina. Flujo Alternativo2 5. Selecciona la opción “Aceptar” para “Está a punto de enviar la rendición online de su PSP. Una vez enviada no tendrá la opción de agregar o modificar los documentos. Si usted está seguro de que ha registrado la totalidad de los documentos presione Aceptar, de lo contrario Cancelar para volver a la Matriz de Documentos.”

6. El sistema envía la rendición a CPEIP.

7. El sistema muestra el mensaje: “Se requiere del envío físico de los documentos de respaldo, además de la rendición online, para dar comienzo al proceso de cierre. SE MATENDRÁ EN ESTADO PENDIENTE DE ENVÍO FÍSICO. SI EL ENVÍO FÍSICO YA FUE REALIZADO PRESIONE REPORTAR ENVÍO FÍSICO DE DOCUMENTOS.”

8. Termina. Excepciones. Precondición: Haber ingresado a la matriz de documentos y haber ingresado al menos un documento. Poscondición: Se envía la rendición a CPEIP. Casos de uso relacionados:

55

Caso de Uso 9. Guión ingresar formulario de documentación física.

Número: 09

Nombre: Ingresar Formulario de Documentación Física .

Descripción: El usuario ingresa el formulario de documentación física con el que registra el envío físico de sus documentos. Actor(es): Encargado Comunal

Usuario Sistema

1. Selecciona la opción “Reportar envío físico de documentos”.

2. El sistema muestra un formulario de ingreso.

3. Ingresa la fecha de envío. 4. El sistema verifica que la fecha de

envío sea ingresada y válida. 5. Ingresa el número del conductor. 6. El sistema verifica que el número del

conductor sea ingresado y valido. 7. El sistema muestra mensaje “Acaba de

pasar a estado: PENDIENTE DE RECEPCIÓN”.

8. Termina. Excepciones. Ingrese la fecha. 4. El sistema verifica que la fecha de

envío sea ingresada. 9. Muestra el mensaje “Ingrese la fecha”. 10. Vuelve al punto 3. Ingrese una fecha válida. 4. El sistema verifica que la fecha sea

válida. 11. Muestra el mensaje “Ingrese una

fecha valida”. 12. Vuelve al punto 3. Ingrese el número del conductor. 6. El sistema verifica que el número del

conductor sea ingresado. 13. Muestra el mensaje “Ingrese el

número del conductor” 14. Vuelve al punto 5. Ingrese un número válido. 6. El sistema verifica que el número de

56

conductor sea un número valido. 15. Muestra el mensaje “Ingrese un

número válido”. 16. Vuelve al punto 5. Precondición: Haber enviado la rendición a CPEIP. Poscondición: Envío de formulario de documentación física. Casos de uso relacionados: 08

Caso de Uso 10. Guión consultar notas de corrección.

Número: 10 Nombre: Consultar Notas de Corrección.

Descripción: El usuario puede consultar las notas de corrección ingresadas por CPEIP. Actor(es): Encargado Comunal

Usuario Sistema

1. Selecciona la opción “Ver BANDEJA DE NOTAS”.

2. El sistema verifica que existan notas de corrección.

3. Termina. Excepciones. NO EXISTEN NOTAS DE CORRECCIÓN. 2. El sistema verifica que existan notas de

corrección. 4. Muestra el mensaje “¡NO EXISTEN

NOTAS DE CORRECCIÓN!” 5. Vuelve al punto 1. Precondición: Haber ingresado a la matriz de documentos. Poscondición: Muestra las notas de corrección. Casos de uso relacionados:

Caso de Uso 11. Guión consultar matriz de documentos.

Número: 11

Nombre: Consultar Matriz de documentos.

Descripción: El usuario CPEIP puede consultar la matriz de documentos para cada una de las comunas. Actor(es): CPEIP

Usuario Sistema

1. Selecciona la región de la barra de

57

navegación.

2. Valida las comunas asociadas a la región seleccionada.

3. Selecciona la comuna. 4. Selecciona la opción “Buscar”. 5. El sistema muestra la pantalla inicial de

la comuna seleccionada. 6. Selecciona la opción “Registro de Gastos”.

7. El sistema muestra la matriz de documentos para la comuna seleccionada.

8. Termina. Excepciones. Error al actualizar lista de comunas. 2. Valida las comunas asociadas a la

región seleccionada. 9. Muestra mensaje “Error al actualizar

lista de comunas”. 10. Vuelve a punto 1. Precondición: Haber ingresado al sistema. Poscondición: Se ingresa a la matriz de documentos. Casos de uso relacionados:

Caso de Uso 12. Guión ingresar nota de corrección.

Número: 12 Nombre: Ingresar Nota de Corrección.

Descripción: El usuario puede ingresar una nota de corrección a través del asunto y descripción de la nota. Actor(es): CPEIP

Usuario Sistema

1. Digita el asunto de la nota.

2. Valida que el asunto de la nota sea un texto adecuado.

3. Digita la descripción de la nota. 4. Valida que la descripción de la nota

sea un texto adecuado. 5. Almacena los datos de la nota en la

base de datos. 6. Muestra mensaje “Acaba de ingresar

58

una nota de corrección”. 7. Termina. Excepciones. Debe escribir un nombre más adecuado. 2. Valida que el asunto de la nota tenga al

menos 5 caracteres. 8. Muestra mensaje “Debe escribir un

nombre más adecuado”. 9. Vuelve a punto 1. Debe escribir un mensaje más adecuado. 4. Valida que el asunto de la nota tenga al

menos 5 caracteres. 10. Muestra mensaje “Debe escribir un

mensaje más adecuado” 11. Vuelve al punto 3. Precondición: Haber ingresado a la matriz de documentos. Poscondición: Se ingresa la nota de corrección. Casos de uso relacionados:

Caso de Uso 13. Guión recibir rendición.

Número: 13 Nombre: Recibir Rendición.

Descripción: El usuario CPEIP recibe la rendición enviada por el Encargado Comunal para que esta pueda ser revisada. Actor(es): CPEIP

Usuario Sistema

1. Selecciona la opción “Confirmar Recepción Física”.

2. Valida que la comuna tenga una rendición creada.

3. Vuelve a la matriz de documentos. 4. Termina. Excepciones. Rendición no existe. 2. Valida que la comuna tenga una

rendición creada. 5. Muestra mensaje “Rendición no existe”. 6. Vuelve a punto 1. Precondición: El Encargado Comunal envió la rendición a CPEIP. Poscondición: Se recibe la rendición. Casos de uso relacionados:

59

Caso de Uso 14. Guión rechazar rendición (en corrección). Número: 14

Nombre: Rechazar Rendición (En Corrección).

Descripción: El usuario CPEIP envía la rendición nuevamente al Encargado Comunal para que pueda ser revisada. Actor(es): CPEIP

Usuario Sistema

1.Selecciona la opción “Rechazado”.

2. Muestra una ventana.

3. Digita el asunto de la nota.

4. Valida que el asunto de la nota sea un texto adecuado.

5. Digita la descripción de la nota. 6. Valida que la descripción de la nota

sea un texto adecuado. 7. Almacena los datos de la nota en la

base de datos. 8. Muestra mensaje “Acaba de enviar la

rendición a estado: RENDICIÓN DEL GASTO CON REPAROS, REVISAR NOTAS DE CORRECCIÓN”.

9. Termina. Excepciones. Debe escribir un nombre más adecuado. 4. Valida que el asunto de la nota tenga al

menos 5 caracteres. 10. Muestra mensaje “Debe escribir un

nombre más adecuado”. 11. Vuelve a punto 3. Debe escribir un mensaje más adecuado. 6. Valida que el asunto de la nota tenga al

menos 5 caracteres. 12. Muestra mensaje “Debe escribir un

mensaje más adecuado” 13. Vuelve al punto 5. Precondición: El Encargado Comunal envió la rendición a CPEIP. Poscondición: Se envía la rendición al Encargado Comunal. Casos de uso relacionados:

60

Caso de Uso 15. Guión enviar rendición a desarrollo. Número: 15

Nombre: Enviar Rendición a Desarrollo.

Descripción: El usuario CPEIP libera la rendición para que el Encargado Comunal pueda realizar cambios a la rendición. Actor(es): CPEIP

Usuario Sistema

1. Selecciona la opción “Liberar Rendición”.

Flujo Alternativo 1. 2. Selecciona la opción “Cancelar” para “¿Desea liberar la rendición?”

3. Vuelve a la matriz de documentos. 4. Termina. Flujo Alternativo 2. 5. Selecciona la opción “Aceptar” para “¿Desea liberar la rendición?”

6. Envía de nuevo la rendición al Encargado Comunal.

7. Vuelve a la matriz de documentos. 8. Termina. Excepciones. Precondición: El Encargado Comunal envió la rendición a CPEIP. Poscondición: Se envía la rendición al estado de Desarrollo para que pueda ser revisada por el Encargado Comunal. Casos de uso relacionados:

Caso de Uso 16. Guión aprobar rendición.

Número: 16

Nombre: Aprobar Rendición.

Descripción: El usuario CPEIP aprueba la rendición, para finalizar el proceso de rendición. Actor(es): CPEIP

Usuario Sistema

1. Selecciona la opción “Aprobado”.

Flujo Alternativo 1. 2. Selecciona la opción “Cancelar” para “¿Desea aprobar la rendición?”.

61

3. Vuelve a la matriz de documentos. 4. Termina. Flujo Alternativo 2. 5. Selecciona la opción “Aceptar” para “¿Desea aprobar la rendición?”

6. Aprueba la rendición. 7. Vuelve a la matriz de documentos. 8. Termina. Excepciones. Precondición: El Encargado Comunal envió la rendición a CPEIP. Poscondición: Se aprueba la rendición. Casos de uso relacionados:

Caso de Uso 17. Guión consultar rendición.

Número: 17 Nombre: Consultar Rendición.

Descripción: El usuario CPEIP puede consultar las rendiciones de las comunas para cada región. Actor(es): CPEIP

Usuario Sistema

1. Selecciona la región de la barra de navegación.

2. Valida las comunas asociadas a la región seleccionada.

3. Selecciona la opción “Buscar”. 4. Selecciona cualquiera de los siguientes ítems: “Rendiciones en desarrollo, Rendiciones pendientes de envió documentación física, Rendiciones pendientes de recepción por CPEIP, Rendiciones recibidas en corrección, Rendiciones con reparos revisar notas de corrección, Rendiciones aprobadas por CPEIP”.

5. El sistema valida que para el ítem seleccionado existan rendiciones.

6. El sistema abre el listado de las rendiciones de acuerdo al ítem seleccionado.

62

7. Selecciona una opción en “Filtro por campo”.

8. Selecciona la opción “Buscar”. 9. El sistema valida que para el ítem

seleccionado existan rendiciones. 10. Termina. Excepciones. Error al actualizar lista de comunas. 2. Valida las comunas asociadas a la

región seleccionada. 11. Muestra mensaje “Error al actualizar

lista de comunas”. 12. Vuelve a punto 1. No se encontraron resultados para la consulta. 5. Valida que existan rendiciones para el

ítem seleccionado. 13. Muestra mensaje “No se encontraron

resultados para la consulta”. 14. Vuelve a punto 7. No se encontraron resultados para la consulta. 9. Valida que existan rendiciones para el

ítem seleccionado. 15. Muestra mensaje “No se encontraron

resultados para la consulta”. 16. Vuelve a punto 7. Precondición: Haber ingresado al sistema. Poscondición: Se visualiza el listado de las rendiciones. Casos de uso relacionados:

Caso de Uso 18. Guión generar reporte de rendiciones.

Número: 18 Nombre: Generar Reporte de Rendiciones.

Descripción: El usuario CPEIP genera un reporte de las comunas para la región seleccionada. Actor(es): CPEIP

Usuario Sistema

1. Selecciona la región de la barra de navegación.

2. Valida las comunas asociadas a la región seleccionada.

3. Selecciona la opción “Buscar”.

63

4. Selecciona la opción “REPORTE DE RENDICIONES”.

5. El sistema abre el reporte. 6. Termina. Excepciones. Precondición: Haber ingresado al sistema. Poscondición: Se visualiza el reporte de rendiciones. Casos de uso relacionados:

64

ANEXO 2: Diagramas de Clase WAE

Diagrama de Clase 1. Guión ingresar documento.

65

Diagrama de Clase 2. Guión modificar documento.

Diagrama de Clase 3. Guión eliminar documento.

66

Diagrama de Clase 4. Guión imprimir documento.

Diagrama de Clase 5. Guión consultar costos rendidos por actividad.

67

Diagrama de Clase 6. Guión imprimir matriz de documentos.

Diagrama de Clase 7. Guión consultar cuadro de costo efectivo.

Diagrama de Clase 8. Guión enviar rendición a CPEIP.

68

Diagrama de Clase 9. Guión ingresar formulario de documentación física.

Diagrama de Clase 10. Guión consultar notas de corrección.

69

Diagrama de Clase 11. Guión consultar matriz de documentos.

70

Diagrama de Clase 12. Guión ingresar nota de corrección.

71

Diagrama de Clase 13. Guión recibir rendición.

Diagrama de Clase 14. Guión rechazar rendición (en corrección).

72

Diagrama de Clase 15. Guión enviar rendición a desarrollo.

Diagrama de Clase 16. Guión aprobar rendición.

73

Diagrama de Clase 17. Guión consultar rendición.

74

Diagrama de Clase 18. Guión generar reporte de rendiciones.

75

ANEXO 3: Diagramas de Secuencia

Diagrama de Secuencia 1. Guión ingresar documento.

76

Diagrama de Secuencia 2. Guión modificar documento.

77

Diagrama de Secuencia 3. Guión eliminar documento.

Diagrama de Secuencia 4. Guión imprimir documento.

78

Diagrama de Secuencia 5. Guión consultar costos rendidos por actividad.

Diagrama de Secuencia 6. Guión imprimir matriz de documentos.

79

Diagrama de Secuencia 7. Guión consultar cuadro de costo efectivo.

Diagrama de Secuencia 8. Guión enviar rendición a CPEIP.

80

Diagrama de Secuencia 9. Guión ingresar formulario de documentación física.

Diagrama de Secuencia 10. Guión consultar notas de corrección.

81

Diagrama de Secuencia 11. Guión consultar matriz de documentos.

Diagrama de Secuencia 12. Guión ingresar nota de corrección.

82

Diagrama de Secuencia 13. Guión recibir rendición.

Diagrama de Secuencia 14. Guión rechazar rendición (en corrección).

83

Diagrama de Secuencia 15. Guión enviar rendición a desarrollo.

Diagrama de Secuencia 16. Guión aprobar rendición

84

Diagrama de Secuencia 17. Guión consultar rendición.

Diagrama de Secuencia 18. Guión generar reporte de rendiciones.

85

ANEXO 4: Modelo Relacional de Datos

Modelo Relacional de Datos 1. Clase región.

NOMBRE COLUMNA TIPO NULO

LLAVE PRIMARIA

LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

nom_region Varchar (100) NO

Modelo Relacional de Datos 2. Clase comuna.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

region_id Int(10) NO SI

nom_comuna Varchar (100) NO

Modelo Relacional de Datos 3. Clase plan.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

comuna_id Int(10) NO SI

nombre_plan Varchar(100) NO

cantidad_periodos Int(10) NO

activo Boolean NO

fecha_postulacion date SI

fecha_creacion date SI

id_psp_psp1 int (10) NO

Modelo Relacional de Datos 4. Clase ano_proceso.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

etiqueta Varchar(10) NO

Modelo Relacional de Datos 5. Clase estado_planificacion.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI nombre_estado_plan Varchar(100) NO

86

Modelo Relacional de Datos 6. Clase periodo.

NOMBRE COLUMNA TIPO NULO

LLAVE PRIMARIA

LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

plan_id int (10) NO SI

ano_proceso_id int (10) NO SI

numero_periodo int (10) NO estado_planificacion_id int (10) NO SI

id_planifica_psp1 int (10) NO

fecha_modicacion Date SI

fecha_aprobacion Date SI

Modelo Relacional de Datos 7. Clase tipo_actividad.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI nombre_tipo_actividad varchar (100) NO

Modelo Relacional de Datos 8. Clase modalidad_actividad.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

nombre_modalidad varchar (100) NO

Modelo Relacional de Datos 9. Clase actividad.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI modalidad_actividad_id int (10) NO SI

tipo_actividad_id int (10) NO SI descripción_actividad longtext NO

horas_planificadas int (10) SI

fecha_inicio Date SI

fecha_fin Date SI

predefinida Date SI

87

Modelo Relacional de Datos 10. Clase actividad_periodo.

NOMBRE COLUMNA TIPO NULO

LLAVE PRIMARIA

LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

periodo_id int (10) NO SI

actividad_id int (10) NO SI

Modelo Relacional de Datos 11. Clase tipo_item_pago.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

tipo_item_pago varchar (100) NO

Modelo Relacional de Datos 12. Clase costo_estimado.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

tipo_item_pago_id int (10) NO SI actividad_periodo_id int (10) NO SI

costo int (10) NO

Modelo Relacional de Datos 13. Clase estado_rendicion.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

nombre_estado varchar(100) NO

Modelo Relacional de Datos 14. Clase rendicion.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

comuna_id int (10) NO SI

ano_proceso_id int (10) NO SI estado_rendicion_id int (10) NO SI

fecha_rendicion Date NO

observado Varchar(15) SI

88

Modelo Relacional de Datos 15. Clase envio_formulario.

NOMBRE COLUMNA TIPO NULO

LLAVE PRIMARIA

LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

rendicion_id int (10) NO SI

numero_conductor int (10) NO

fecha_envio Date NO

estado Varchar(15) NO

Modelo Relacional de Datos 16. Clase nota.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

asunto_nota Varchar(100) NO

mensaje_nota longtext NO

tipo_nota Varchar(30) NO

fecha_nota date NO

comuna_nota Varchar(50) NO

remitente Varchar(100) NO

Modelo Relacional de Datos 17. Clase nota_rendicion.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

rendicion_id int (10) NO SI

Modelo Relacional de Datos 18. Clase tipo_documento.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

tipo_documento varcahr (100) NO

89

Modelo Relacional de Datos 19. Clase documento.

NOMBRE COLUMNA TIPO NULO

LLAVE PRIMARIA

LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

rendicion_id int (10) NO SI

tipo_documento_id int (10) NO SI

tipo_item_pago_id int (10) NO SI nombre_documento Varchar(100) NO numero_documento int (10) NO

fecha_documento Date NO

RUT Varchar(20) NO descripción_documento NO

montoCPEIP int (10) SI

montoPSP int (10) SI

montoTotal int (10) NO tipoIngresoMontoAct Varchar(15) NO

Modelo Relacional de Datos 20. Clase actividad_documento.

NOMBRE

COLUMNA TIPO NULO LLAVE

PRIMARIA LLAVE UNICA

LLAVE FORANEA VALIDACION

Id int (10) NO SI

actividad_id int (10) NO SI

documento_id int (10) NO SI

monto int (10) NO

90

ANEXO 5: Formularios

Formulario 1. Ingresar documento (A).

Formulario 1. Ingresar documento (B).

91

Formulario 2. Matriz de documentos.

Formulario 3. Cuadro de costo efectivo.

92

Formulario 4. Actividades asociadas al documento.

Formulario 5. Envío físico de documentos.

93

Formulario 6. Consultar rendiciones.

Formulario 7. Ingresar nota de corrección.

94

Formulario 8. Consultar notas de corrección.

95

ANEXO 6: Pruebas Unitarias Prueba Unitaria 1. Tabla para el caso de uso ingresar documento.

Prueba unitaria Caso de uso No 1 ingresar documento.

Descripción de la prueba Se ingresarán los campos nombre, número, RUT, descripción del documento ( __222, xxxxx, 12345r4-5, __333 ).

Resultado esperado Se espera que el sistema envíe un mensaje de error para cada uno de los campos, con el objetivo de que valide el formato de cada uno de ellos.

Resultado de la prueba Esta prueba de software cumplió a cabalidad con el requerimiento que se esperaba, que fuera el de validar los campos del documento enviando un mensaje de error para cada uno de los campos.

Prueba Unitaria 2. Tabla para el caso de uso ingresar documento.

Prueba unitaria Caso de uso No 1 ingresar documento.

Descripción de la prueba Se dejaran los campos nombre de documento, tipo de documento, tipo de ítem de pago, RUT del documento, descripción del documento, montoPSP vacíos.

Resultado esperado Se espera que el sistema envíe un mensaje de error informando que debe de llenar todos los campos.

Resultado de la prueba Esta prueba de software cumplió a cabalidad con el requerimiento que se esperaba, que fuera el de validar los campos del documento para que sean obligatorios enviando un mensaje de error para cada uno de los campos.

96

Prueba Unitaria 3. Tabla para el caso de uso ingresar documento.

Prueba unitaria Caso de uso No 1 ingresar documento.

Descripción de la prueba Se dejaran sin seleccionar las actividades del documento.

Resultado esperado Se espera que el sistema envíe un mensaje de error informando que debe de seleccionar al menos una actividad.

Resultado de la prueba Esta prueba de software cumplió a cabalidad con el requerimiento que se esperaba, que fuera el de validar que al menos una actividad fuera seleccionada enviando un mensaje de error.

Prueba Unitaria 4. Tabla para el caso de uso modificar documento.

Prueba unitaria Caso de uso No 2 modificar documento.

Descripción de la prueba Se dejaran todos los campos del documento vacíos.

Resultado esperado Se espera que el sistema envíe un mensaje de error informando que debe de llenar todos los campos.

Resultado de la prueba Esta prueba de software cumplió a cabalidad con el requerimiento que se esperaba, que fuera el de validar los campos del documento para que sean obligatorios enviando un mensaje de error para cada uno de los campos.

Prueba Unitaria 5. Tabla para el caso de ingresar formulario de documentación física.

Prueba unitaria Caso de uso No 9 ingresar formulario de documentación física.

Descripción de la prueba Se ingresan los campos número de conductor y fecha de envío incorrectas al formato (rererer, 2000-22-40).

Resultado esperado Se espera que el sistema envíe un mensaje de error informando que debe de ingresar un número de conductor valido y fecha valida.

Resultado de la prueba Esta prueba de software cumplió a cabalidad con el requerimiento que se esperaba, que fuera el de validar los campos del formulario de envío enviando un mensaje de error para cada uno de los campos.

97

Prueba Unitaria 6. Tabla para el caso de ingresar formulario de documentación física.

Prueba unitaria Caso de uso No 9 ingresar formulario de documentación física.

Descripción de la prueba Se ingresan los campos número de conductor y fecha de envío sin completar.

Resultado esperado Se espera que el sistema envíe un mensaje de error informando que debe de ingresar ambos campos.

Resultado de la prueba Esta prueba de software cumplió a cabalidad con el requerimiento que se esperaba, que fuera el de validar los campos del formulario de envío enviando un mensaje de error.

Prueba Unitaria 7. Tabla para el caso de ingresar formulario de documentación física.

Prueba unitaria Caso de uso No 9 ingresar formulario de documentación física.

Descripción de la prueba Se ingresan los campos número de conductor y fecha de envío validos al formato (12345674, 10-10-2008)

Resultado esperado Se espera que el sistema envíe un mensaje de satisfacción informando que se envió correctamente el formulario.

Resultado de la prueba Esta prueba de software cumplió a cabalidad con el requerimiento que se esperaba, que fuera el de validar los campos del formulario de envío enviando un mensaje de satisfacción.

98

Prueba Unitaria 8. Tabla para el caso de ingresar nota de corrección.

Prueba unitaria Caso de uso No 12 ingresar nota de corrección.

Descripción de la prueba Se ingresan los campos asunto y mensaje de la nota con espacios y de 4 caracteres (__me, __df).

Resultado esperado Se espera que el sistema envíe un mensaje de error informando que se debe de ingresar un nombre de nota y mensaje de nota mas adecuado.

Resultado de la prueba Esta prueba de software cumplió a cabalidad con el requerimiento que se esperaba, que fuera el de validar los campos de la nota enviando un mensaje de error.

Prueba Unitaria 9. Tabla para el caso de ingresar nota de corrección.

Prueba unitaria Caso de uso No 12 ingresar nota de corrección.

Descripción de la prueba Se dejaran los campos de asunto de la nota y mensaje de la nota vacíos.

Resultado esperado Se espera que el sistema envíe un mensaje de error informando que se ambos campos deben de llenarse.

Resultado de la prueba Esta prueba de software cumplió a cabalidad con el requerimiento que se esperaba, que fuera el de validar los campos siendo obligatorios enviando un mensaje de error.

Prueba Unitaria 10. Tabla para el caso de ingresar nota de corrección.

Prueba unitaria Caso de uso No 12 ingresar nota de corrección.

Descripción de la prueba Se ingresaran los campos asunto y mensaje de la nota (revisión, se debe de completar la información…..).

Resultado esperado Se espera que el sistema envíe un mensaje de satisfacción informando que acaba de ingresar una nota de corrección.

Resultado de la prueba Esta prueba de software cumplió a cabalidad con el requerimiento que se esperaba, que fuera el de validar los campos enviando un mensaje de satisfacción.