UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA Facultad de Ingeniería de Minas, Geología y Civil Escuela de Formación Profesional de Ingeniería de Sistemas “NOTIFICACIÓN ELECTRÓNICA EN LA FACTURACIÓN DEL SERVICIO DE AGUA POTABLE Y ALCANTARILLADO SEDA AYACUCHO S.A, 2017” Informe Profesional presentado por : Bach. Abel I. VENTURA CHOQUECAHUA Para optar el título profesional de : Ingeniero de Sistemas Tipo de investigación : Aplicada Ayacucho – Perú 2017 i DEDICATORIA Dedico esta tesis a mi padre Isaias Ventura Rojas, a mi madre Felicitas Choquecahua Palomino, quienes han estado a mi lado a lo largo de mi vida velando por mi salud y educación. ii AGRADECIMIENTO Agradezco a Dios el Todopoderoso por cuidarme, protegerme, bendecirme con su amor infinito y guiándome por el buen camino en cada cosa que hago. A mis padres porque siempre están a mi lado alentándome y dándome fuerza para seguir adelante. Al Mg. Ing. Richar Mendoza Pumacahua por su amistad y apoyo incondicional A mi asesora Ing. Edith F. Guevara Morote por ser guía en la elaboración del proyecto de tesis. iii CONTENIDO Página DEDICATORIA ............................................................................................................................ i AGRADECIMIENTO .................................................................................................................. ii CONTENIDO .............................................................................................................................. iii RESUMEN.................................................................................................................................... v INTRODUCCIÓN ....................................................................................................................... vi CAPITULO I ............................................................................................................................... 1 PLANTEAMIENTO DE LA INVESTIGACIÓN .................................................................... 1 1.1. DIAGNOSTICO Y ENUNCIADO DEL PROBLEMA ................................................ 1 1.2. DEFINICIÓN DEL PROBLEMA DE INVESTIGACIÓN ........................................... 3 1.3. OBJETIVOS DE LA INVESTIGACIÓN ..................................................................... 3 1.4. HIPÓTESIS DE LA INVESTIGACIÓN ....................................................................... 4 1.5. JUSTIFICACIÓN Y DELIMITACIÓN DE LA INVESTIGACIÓN ........................... 4 CAPITULO II ............................................................................................................................. 6 MARCO TEÓRICO ................................................................................................................... 6 2.1. ANTECEDENTES DE LA INVESTIGACIÓN............................................................ 6 2.2. MARCO TEÓRICO ...................................................................................................... 6 2.2.1. NOTIFICACIÓN ELECTRÓNICA .............................................................................. 6 2.2.2. FACTURACIÓN ........................................................................................................... 8 2.2.3. CORREO ELECTRÓNICO ........................................................................................ 10 2.2.4. CERTIFICADO DIGITAL .......................................................................................... 11 2.2.5. FIRMA DIGITAL ....................................................................................................... 11 2.2.6. FIRMA ELECTRÓNICA ............................................................................................ 12 2.2.7. CRIPTOGRAFIA ........................................................................................................ 12 2.2.8. LA METODOLOGÍA AGIL Y FORMAL ICONIX .................................................. 13 2.2.9. SISTEMA GESTOR DE BASE DE DATOS RELACIONAL ................................... 26 2.2.10. LENGUAJE DE PROGRAMACIÓN ORIENTADA A OBJETOS ........................... 27 2.2.11. UML ............................................................................................................................ 27 2.2.12. REFIRMA ................................................................................................................... 28 2.2.13. TECNOLOGÍA DE INTERNET ................................................................................. 30 CAPITULO III .......................................................................................................................... 33 METODOLOGÍA DE LA INVESTIGACIÓN ...................................................................... 33 3.1. TIPO DE INVESTIGACIÓN ...................................................................................... 33 3.2. DISEÑO DE LA INVESTIGACIÓN .......................................................................... 33 3.3. POBLACIÓN Y MUESTRA ...................................................................................... 33 iv 3.4. VARIABLES E INDICADORES ............................................................................... 34 3.4.1. DEFINICIÓN CONCEPTUAL DE LAS VARIABLES ............................................. 34 3.4.2. DEFINICIÓN OPERACIONAL DE LAS VARIABLES ........................................... 35 3.5. TÉCNICAS E INSTRUMENTOS PARA LA RECOLECCIÓN DE DATOS ........... 36 3.5.1. TÉCNICAS .................................................................................................................. 36 3.5.2. INSTRUMENTOS ...................................................................................................... 36 3.5.3. HERRAMIENTAS PARA EL TRATAMIENTO DE DATOS E INFORMACION . 36 3.5.4. TÉCNICAS PARA APLICAR ICONIX ..................................................................... 38 CAPITULO IV .......................................................................................................................... 46 ANÁLISIS Y RESULTADOS DE LA INVESTIGACIÓN ................................................... 46 4.1. RESULTADOS ........................................................................................................... 46 4.1.1. ANÁLISIS DE REQUISITOS .................................................................................... 46 4.1.2. REVISIÓN DE REQUISITOS .................................................................................... 63 4.1.3. DISEÑO PRELIMINAR ............................................................................................. 69 4.1.4. REVISIÓN DE DISEÑO PRELIMINAR ................................................................... 72 4.1.5. ARQUITECTURA TÉCNICA .................................................................................... 75 4.1.6. DISEÑO DETALLADO ............................................................................................. 77 4.1.7. REVISIÓN CRÍTICA DE DISEÑO ............................................................................ 81 4.1.8. IMPLEMENTACIÓN ................................................................................................. 85 4.2. ANÁLISIS COSTO BENEFICIO ............................................................................... 90 CAPÍTULO V ............................................................................................................................ 94 DISCUSIÓN DE LA INVESTIGACIÓN ................................................................................ 94 5.1. DISCUSIÓN ................................................................................................................ 94 CAPÍTULO VI .......................................................................................................................... 95 CONCLUSIONES Y RECOMENDACIONES ...................................................................... 95 6.1. CONCLUSIONES ....................................................................................................... 95 6.2. RECOMENDACIONES ............................................................................................. 96 ANEXOS .................................................................................................................................... 97 ANEXO A: ENCUESTA AL CLIENTE ................................................................................ 97 BIBLIOGRAFÍA ....................................................................................................................... 98 v RESUMEN La Unidad de Facturación del servicio de agua potable y alcantarillado SEDA Ayacucho, es un área encargada de la emisión y reparto de recibos por consumos de agua potable y alcantarillado, reportando la información estadística, registrando volúmenes y montos facturados. Esta unidad emite la facturación mensual de los recibos de agua potable y alcantarillado de acuerdo al cronograma de facturación, los recibos de agua son impresos para luego ser repartidos a los clientes a sus domicilios por los operarios comerciales abarcando a los distritos como Ayacucho, Carmen Alto, San Juan Bautista, Jesús Nazareno y Andrés Avelino Cáceres Dorregaray. Las impresiones y repartos de los recibos de agua se realizan mensualmente incurriendo en costos de papel, impresión y pagos mensuales a los operarios comerciales. El objetivo de la investigación es desarrollar una aplicación web de notificación electrónica para mejorar la facturación del servicio de agua potable y alcantarillado SEDA Ayacucho S.A. La investigación se realizara mediante la metodología Iconix y framework de desarrollo .NET integrándose con el patrón de desarrollo Modelo Vista Controlador (MVC), usando firma digital. El tipo de investigación es aplicada, con el nivel de investigación descriptiva y con el diseño de investigación no experimental y transversal. Los resultados logrados de acuerdo al capítulo IV se obtuvieron los artefactos de análisis de requisitos funcionales en la tabla N° 4.1 (N° 20, 21, 22, 23, 24, 25, 26), descripción de casos de uso en la tabla N° 4.12, diagrama de robustez en la figura N° 4.24, diagrama de secuencia en la figura N° 4.32 y diagrama de clases de diseño en la figura N° 4.33 y el esquema de base de datos física en la figura N° 4.37, usando la metodología Iconix. Se envía el recibo de agua al correo electrónico y un mensaje de texto al celular del cliente informando de manera oportuna sobre su facturación correspondiente. Palabras clave Notificación Electrónica, Facturación, Aplicación Web, Metodología Iconix, Firma digital. vi INTRODUCCIÓN Las notificaciones electrónicas son aquellas comunicaciones que emiten la administración pública y privada utilizando medios electrónicos y telemáticos, tales como el Internet y el correo electrónico (Chiara, s.f). El proceso de facturación es la actividad comercial que lleva a cabo una empresa concesionaria con sus usuarios, consistente en determinar y calcular los consumos absorbidos durante un periodo mensual, aplicar los precios unitarios vigentes, emitir los respectivos recibos con los rubros, parámetros e importes calculados y entregados a cada uno de los usuarios en sus domicilios (Osorio, 2002). La metodología ICONIX se encuentra entre el proceso unificado (PU) y la programación extrema (XP). ICONIX está conducido por casos de uso, es relativamente pequeño y ligero (Porras, 2011, p. 1). Se plantea resolver el problema con la notificación electrónica para mejorar la facturación en la Unidad de Facturación del servicio de agua potable y alcantarillado Ayacucho, el motivo personal es que el cliente sea notificado sobre su cuenta a pagar mensualmente en un recibo de agua digital enviando a su cuenta de correo electrónico personal, así teniendo informado al cliente de manera oportuna para su posterior pago y evitar el corte del servicio. Los clientes acuden a la oficina central de la empresa, a reclamar mencionando que su recibo de agua no fue entregado en su domicilio generando desinformación sobre su pago correspondiente del servicio de agua potable y alcantarillado y perjudicando el pago oportuno y el corte del servicio. El objetivo general es: desarrollar una aplicación web para la notificación electrónica que mejora la facturación del servicio de agua potable y alcantarillado SEDA Ayacucho S.A, 2016. Usando un software web desarrollado con la metodología Iconix, un sistema gestor de base datos relacional, lenguaje de programación orientada a objetos, firma digital, con el propósito de mejorar el proceso de facturación de servicio de agua potable y alcantarillado, y con el fin de mejorar la prestación de servicio al ciudadano. 1 CAPITULO I PLANTEAMIENTO DE LA INVESTIGACIÓN 1.1. DIAGNOSTICO Y ENUNCIADO DEL PROBLEMA La empresa de Servicio de Agua Potable y Alcantarillado de Ayacucho S.A – SEDA Ayacucho, ubicada dentro de la región de Ayacucho, atiende a la ciudad de Ayacucho y Huanta. La ciudad de Ayacucho conformado por los distritos de Ayacucho, San Juan Bautista, Jesús Nazareno, Carmen Alto y Andrés Avelino Cáceres, cuenta con una población total de 208,514 habitantes, con una cobertura del servicio de agua potable al 89.61% que representa una población servida de 186,849 tineantes y con una cobertura del servicio de desagüe asciende a 80.30%, que representa a una población servida de 167,437 habitantes. Tabla N° 1.1: Número de conexiones activas por distritos y mes (SEDA, 2016) El Departamento de Medición de la Gerencia Comercial es la encargada de registrar e ingresar información de lecturas de consumo de agua potable de los medidores de cada cliente, para lo cual cuentan con los trabajadores denominados operarios comerciales, quienes visitan a los domicilios de los clientes para dar lectura a los medidores activos. CUADRO N°05 ESTADO DE LAS CONEXIONES ACTIVAS POR DISTRITO MESES AYACUCHO % CARMEN ALTO % SAN JUAN BAUTISTA % JESÚS NAZARENO % ANDRÉS A. CÁCERES % TOTAL % PERIODO 2016 ENERO 25,118 56.42% 4,732 10.63% 11,102 24.94% 3,358 7.54% 206 0.46% 44,516 100.00% FEBRERO 25,232 56.43% 4,745 10.61% 11,147 24.93% 3,372 7.54% 221 0.49% 44,717 100.00% MARZO 25,276 56.32% 4,772 10.63% 11,216 24.99% 3,380 7.53% 233 0.52% 44,877 100.00% ABRIL 25,312 56.31% 4,784 10.64% 11,209 24.94% 3,389 7.54% 258 0.57% 44,952 100.00% MAYO 25,392 56.30% 4,788 10.62% 11,257 24.96% 3,398 7.53% 265 0.59% 45,100 100.00% JUNIO 25,494 56.31% 4,793 10.59% 11,299 24.96% 3,409 7.53% 279 0.62% 45,274 100.00% JULIO 25,542 56.28% 4,804 10.59% 11,330 24.97% 3,421 7.54% 283 0.62% 45,380 100.00% AGOSTO 25,626 56.21% 4,826 10.59% 11,407 25.02% 3,440 7.55% 288 0.63% 45,587 100.00% SEPTIEMBRE 25,948 56.84% 4,836 10.59% 11,418 25.01% 3,445 7.55% 0.00% 45,647 100.00% 2 Con la información registrada y procesada por el Departamento de Medición, la Unidad de Facturación se encarga de facturar los consumos de cada uno de los clientes que tienen conexiones activas, tomando referencia para el cálculo el volumen de agua consumida y la estructura tarifaria de los servicios de agua y desagüe, obteniendo como resultado el recibo de agua con la información correspondiente de su pago y son impresas los recibos de agua en grandes cantidades uno por cliente según la tabla N° 1.1, se imprimirían 45, 647 recibos de agua, que luego son distribuidas a los domicilios de cada cliente por los obreros “operadores comerciales”. Tabla N° 1.2: Escala única de remuneraciones (SEDA Ayacucho, 2016) Según la tabla N° 1.1, hasta el mes de setiembre se cuenta con 45, 657 conexiones activas y tiende en aumento mes a mes, esto genera un costo excesivo en la compra formatos de recibos de agua en 300 millares el costo asciende a 11, 580 soles. Para la distribución de los recibos de agua a los domicilios de los clientes el lapso de tiempo es de 5 días y se dispone de 15 obreros (Obrero I y Obrero II), que también son conocidos como operarios comerciales, según el nivel remunerativo perciben una mensualidad de 2,410.92 soles, en Niveles Remunerativos Nivel Nomenclatura Remuneración Bruta Remuneración Básica Asignación Unificada Gerente General D3 Gerente General 4,073.14 3,883.74 189.40 Gerentes de Línea y Apoyo D2 Gerentes de Línea y Apoyo 3,037.29 2,847.89 189.40 Gerente de Huanta D1 Gerente de Huanta 2,866.40 2,677.00 189.40 Auditor Interno D1 Jefe de Control Interno 2,866.40 2,677.00 189.40 Profesional II P2 Jefe de Oficina 2,993.80 2,678.60 315.20 Profesional II P2 Jefe de Departamento 2,939.92 2,624.72 315.20 Profesional I P1 Jefe de Unidad 2,839.92 2,524.72 315.20 Profesional I P1 Especialista en Oficina 2,671.92 2,356.72 315.20 Profesional I P1 Especialista en Departamento 2,621.92 2,306.72 315.20 Profesional I P1 Especialista en Unidad 2,571.92 2,256.72 315.20 Técnico II T2 Técnico 2,521.92 2,206.72 315.20 Técnico I T1 Técnico 2,491.92 2,176.72 315.20 Obrero II O2 Obrero 2,410.92 2,086.72 324.20 Obrero I O1 Obrero 2,410.92 2,086.72 324.20 3 total se destina un presupuesto de 36, 163.80 soles mensuales. 1.2. DEFINICIÓN DEL PROBLEMA DE INVESTIGACIÓN 1.2.1. PROBLEMA PRINCIPAL ¿Cómo la notificación electrónica mejora la facturación del servicio de agua potable y alcantarillado SEDA Ayacucho S.A, 2017? 1.2.2. PROBLEMAS SECUNDARIOS a. ¿En qué medida la trazabilidad de la notificación electrónica identifica al cliente? b. ¿De qué manera la integridad de la notificación electrónica otorga valor legal al recibo de agua? c. ¿De qué manera el medio electrónico de la notificación electrónica apoya a la recaudación? 1.3. OBJETIVOS DE LA INVESTIGACIÓN 1.3.1. OBJETIVO GENERAL Desarrollar una aplicación web para la notificación electrónica que mejora la facturación del servicio de agua potable y alcantarillado SEDA Ayacucho S.A, 2017. Usando un software web desarrollado con la metodología Iconix, un sistema gestor de base datos relacional, lenguaje de programación orientada a objetos, firma digital, con el propósito de mejorar el proceso de facturación de servicio de agua potable y alcantarillado, y con el fin de mejorar la prestación de servicio al ciudadano. 1.3.2. OBJETIVOS SECUNDARIOS a. Seguir la trazabilidad en la notificación electrónica para identificar al cliente, con el propósito de brindar información correcta al cliente. b. Comprobar la integridad en la notificación electrónica para dar valor legal al recibo de agua, con el propósito de garantizar que el documento no sea manipulado. c. Utilizar el medio electrónico en la notificación electrónica para apoyar a la recaudación, con el propósito de brindar información oportuna al cliente. 4 1.4. HIPÓTESIS DE LA INVESTIGACIÓN Si implementamos la notificación electrónica mejora la facturación de servicio de agua potable y alcantarillado SEDA Ayacucho, 2017. 1.5. JUSTIFICACIÓN Y DELIMITACIÓN DE LA INVESTIGACIÓN 1.5.1. JUSTIFICACIÓN La tecnología siempre ha sido parte de la vida del hombre, desde tiempos prehistóricos, el hombre ha usado su inteligencia para crear tecnologías que le permitan contar con herramientas con las cuales poder hacer mejor sus labores. En la actualidad las tecnologías de la información y la comunicación constituyen herramientas privilegiadas para el desarrollo de las personas y de las sociedades al facilitar el manejo de información, las personas hoy en día cuentan con smartphones, computadoras y correos electrónicos para el envío y recepción de mensajes, archivos, documentos, imágenes, etc. El trabajo de investigación plantea desarrollar e implementar una aplicación web de notificación electrónica en la facturación del servicio de agua potable y alcantarillado, para lo cual los clientes deben aceptar él envió del recibo de agua por el medio electrónico, para lo cual deben proporcionar su número de celular, correo personal y además consignar un correo alterno, propio o de un familiar directo, el recibo de agua generado será firmado digitalmente con un certificado digital y remitido a su correo electrónico, además se enviarán un mensaje de texto al celular, con la trazabilidad en la notificación electrónica podremos verificar que el mensaje enviado al cliente sea el correcto y que el cliente pueda recibir el mensaje y ser informado oportunamente. Por tales motivos la Unidad de Facturación de SEDA Ayacucho requiere contar con una aplicación web de notificación electrónica como una herramienta importante para mejorar y agilizar el proceso de facturación en la emisión y entrega de los recibos de agua a sus clientes con conexiones activas, reduciendo gastos en pagos a los personales “operarios comerciales”, en impresiones, en la adquisición de formato de recibo de agua. 1.5.2. DELIMITACIÓN El presente trabajo de investigación se realizara en la Unidad de Facturación del servicio de agua potable y alcantarillado SEDA Ayacucho, el levantamiento de datos será http://es.wikipedia.org/wiki/Tecnolog%C3%ADa 5 en el año 2017 y se implementara una aplicación web de notificación electrónica. 6 CAPITULO II MARCO TEÓRICO 2.1. ANTECEDENTES DE LA INVESTIGACIÓN Morales (2016), afirma que la implementación de las notificaciones electrónicas da ventajas al proceso judicial, demostrando de manera significativa aportan en la economía, seguridad y celeridad procesal, el retaso se reduce drásticamente por cuanto las notificaciones se reciban en tiempo real, a través de la red del internet. Es indispensable que la notificación electrónica ofrezca la posibilidad al Poder Judicial de utilizar un instrumento que permita aumentar su capacidad de operación, disminuya costos operativos y ofrezca las garantías dentro del debido proceso. Pérez (2008), afirma que la notificación electrónica cumple con el objetivo de que los litigantes puedan recibir las notificaciones en su propio domicilio sin la necesidad de que el notificador tenga que ir a dejar las notificaciones hasta las oficinas, pues como se sabe son cientos de notificaciones las que tienen que realizar los notificadores y a través de este medio puede utilizarse hasta con el propio litigante que tenga un acceso a un correo electrónico. Noj (2012), afirma que La Ley Reguladora de las Notificaciones por medios Electrónicos en el Organismo Judicial, Decreto 15-2011 del Congreso de la República de Guatemala representa el medio para la agilización de las notificaciones judiciales introduciendo paulatinamente la tecnología en la administración de justicia, beneficiando a las partes procesales y a la justicia misma. 2.2. MARCO TEÓRICO 2.2.1. NOTIFICACIÓN ELECTRÓNICA Para López (2010), este servicio permite al ciudadano o a la empresa recibir todas las notificaciones precedentes de las administraciones públicas en un buzón asociado a su Dirección Electrónica Única (DEU), que es una dirección electrónica especial en Correos, diferente a una cuenta de correo electrónico convencional. La recepción de las notificaciones es confidencial y segura, enviando además al ciudadano mediante un 7 correo electrónico habitual un aviso de recepción de notificación. El ciudadano puede elegir, para cada procedimiento, si desea ser notificado en forma electrónica. Según Nájera (2014), la notificación electrónica es el acto mediante el cual, con las formalidades legales preestablecidas, se da a conocer a los interesados a través de medios electrónicos y telemáticos, tales como una página web, y el correo electrónico, una resolución judicial o administrativa, recaída en un trámite o en un asunto judicial, en donde se le requiere; para que cumpla un acto procesal. Chiara (s.f), define las notificaciones electrónicas como aquellas comunicaciones que emiten la administración pública y privada utilizando medios electrónicos y telemáticos, tales como el Internet y el correo electrónico. En el campo de la administración de justicia, surgen como una alternativa inmediata para lograr que los procesos judiciales que utilicen este medio se desarrollen con una mayor celeridad, economía y seguridad procesal. A. TRAZABILIDAD “Aquellos procedimientos preestablecidos y autosuficientes que permiten conocer el histórico, la ubicación y la trayectoria de un producto o lote de productos a lo largo de la cadena de suministros en un momento dado, a través de herramientas determinadas” (Darwin, 2008, p. 100). La expresión “trazabilidad” la posibilidad de encontrar y seguir el rastro, a través de todas las etapas de producción, transformación y distribución, de un alimento, un pienso, un animal destinado a la producción de alimentos o una sustancia destinada a ser incorporada en alimentos o piensos o con probabilidad de serlo (Parlamento Europeo y Consejo de 28 de Enero del 2002, 2008). Según Codex Alimentarius (2006), “trazabilidad es la capacidad para seguir el desplazamiento de un alimento a través de una o varias etapas especificadas de sus producción, transformación y distribución”. B. INTEGRIDAD La integridad significa que la información enviada a través del mensaje de datos no carece de alguna de sus partes, como tampoco ha sido transformada. En tal sentido, la 8 integridad es uno de los requisitos esenciales con los cuales se le da plena validez jurídica al documento electrónico y es por esto que se confía en la firma digital o en la firma electrónica como está contemplado en el artículo 7 de la ley 527 de 1999, pues, gracias a ella, se asegura la integridad del mensaje de datos que ha sido firmado adecuadamente, y es, además totalmente independiente el medio en que se almacene (Rincón, 2006, p. 52). Para la integridad implica que el contenido, ya sea que se encuentre en un computador o que circule a través de una red, permanezca inalterado. En caso de sufrir modificaciones que sea por persona autorizada y que exista en el sistema la constancia de esta modificación, que hará viable su control al realizarse auditorías. Según Salido (2010), la integridad de los datos puede definirse como la imposibilidad de que alguien modifique datos sin ser descubierto. Desde la perspectiva de la seguridad de datos y redes, la integridad de los datos es la garantía de que nadie pueda acceder a la información ni modificarla sin contar con la autorización necesaria. C. MEDIO ELECTRÓNICO Asociación Española de Comercio Electrónico y Marketing Relacional (AECEM), define “el medio electrónico como el mecanismo, instalación, equipamiento o sistema que permite producir, almacenar o transmitir documentos, datos e informaciones, incluyendo cualquier red de comunicación abierta o restringida como Internet, telefonía fija y móvil o de otros”. Para Rodríguez (2005), “los dispositivos tecnológicos para transmitir o almacenar datos e información, a través de computadoras, líneas telefónicas, enlaces dedicados, microondas, o de cualquier otra tecnología”. 2.2.2. FACTURACIÓN Para Osorio (2002), es la actividad comercial que lleva a cabo una empresa concesionaria con sus usuarios, consistente en determinar y calcular los consumos absorbidos durante un período mensual, aplicar los precios unitarios vigentes, emitir los respectivos recibos con los rubros, parámetros e importes calculados y entregarlos a cada uno de los usuarios en sus domicilios. 9 Según Medina (2004), la facturación debe permitir el control de la cartera de clientes. La facturación debe de agregarle valor a la operación de venta, ya que es una actividad de servicio directo al cliente (no aporta beneficio a la empresa que la hace sino que solo le permite cumplir una obligación administrativa). “El proceso de facturación tiene objetivo de controlar, procesar y registrar todas las actividades relacionadas u operaciones que tiene como objetivo mantener y aumentar las ventas de una empresa” (Catacora, 1997, p. 282). A. CLIENTE El cliente es la persona que adquiere un bien o servicio para uso propio o ajeno a cambio de un precio determinado por la empresa y aceptado socialmente. Constituye el elemento fundamental por y para el cual se crean productos en las empresas (Bastos, 2006, p. 3). El cliente no es únicamente aquel que compra los productos o servicios de la empresa, el concepto es mucho más amplio. Son clientes, reales o potenciales, todos aquellos que entran en contacto con la empresa. También hay que considerar como clientes aquellos que en su momento, por diversos motivos, dejaron de serlo (Londoño, 1995, p. 54). “Un cliente es la organización o persona que recibe un servicio. Estos se encuentran cada vez mejor informados y conocen mejores sus derechos por los que se genera un mercado más exigente y selectivo” (Rosander, 2009, p. 5) B. RECIBO DE AGUA Según SEDA (2016), el recibo de agua es un documento impreso que contiene no solo el monto a pagar, sino la cantidad exacta de agua consumida en metros cúbicos, el cargo fijo (lectura, formato de recibo, entrega de recibo y cobranza en ventanilla), los recibos de agua son entregados mensualmente en el domicilio del cliente por lo menos 10 días hábiles antes de la fecha de vencimiento señalado en el recibo de agua. La facturación es quizás el punto de contacto con el cliente más amplio en una empresa al registrar lecturas de medidores y entrega de facturas (recibos de agua), a través del cual la empresa consolida su imagen y todos aquellos aspectos estratégicos que la condicionan dentro del medio en que trabaja porque permite establecer una comunicación directa entre 10 la empresa y el consumidor, a través de la factura (recibo de agua) como el principal instrumento de cobranza de los servicios (ANDESAPA). C. RECAUDACIÓN Para León (2000), la recaudación es la acción desplegada por la administración para hacer ingresar a la hacienda municipal el producto de los impuestos. En el mundo actual en el que las distancias se acortan, cada vez más, y no se exige presencia física para el desarrollo de las actividades cotidianas, existe la posibilidad de aplicar mecanismos innovadores, que permitan la mayor facilidad a los ciudadanos a la hora de cumplir con sus deberes impositivos. Según Parra (2002), analiza formas novedosas de recaudación de los impuestos municipales, la autoliquidación por parte del ciudadano, la cual puede efectuarse mediante depósito bancario directo, autorización de descuento en cuenta e incluso por vía electrónica de Internet mediante las cuentas propias o tarjeta de crédito. Según Sierra (1997), Entre esas formas de recaudación, puede citarse, además de la autoliquidación, el facilitar diversos sitios en el municipio, en el cual pueden acudir los contribuyentes a cancelar sus impuestos, así como incentivos que estimulen el pago puntual, tales como descuentos por pronto pago, tal y como plantea. 2.2.3. CORREO ELECTRÓNICO El correo es el medio de comunicación existente desde hace siglos. El correo electrónico, también conocido como E-mail, ha sustituido en gran parte él envió tradicional de correo. Los motivos de ello son diversos: para empezar, un mensaje de correo electrónico solo tarda unos minutos en llegar al otro lado del mundo y, en segundo lugar, el precio del envió se limita a una única tarifa (…). El correo electrónico es también una herramienta extraordinaria para comunicarse y mantener el contacto con amigos, colegas del trabajo o amigos (Lackerbauer, 1999, p. 153). “Un correo electrónico es el uso de sistemas informáticos para transferir mensajes entre individuos, mensajes que están normalmente almacenados de forma centralizada hasta que el destinatario los reconoce” (Crystal, 2004, p. 38). 11 El correo electrónico, conocido por su palabra en inglés e mail (electronic mail), es un servicio de comunicación de Internet; que viene a potenciar el intercambio de mensajes entre personas. Tradicionalmente, este intercambio se ha realizado a través del correo postal y fax. Con la aparición de Internet, el correo electrónico se convierte en un medio alternativo, que hoy es el medio de comunicación escrita más utilizada a escala mundial. El correo permite enviar y recibir mensajes que, en lugar de ser entregados por un cartero, son enviados vía electrónica, utilizando computadoras y servidores espaciales ligados a Internet (Quesada, 2002, p. 90). 2.2.4. CERTIFICADO DIGITAL El certificado digital es un documento en el que una autoridad de certificación, que es una empresa u organismo de confianza que se encarga de emitir y revocar los certificados digitales y certificados de firmas electrónicas, garantiza que una clave pública y un determinado sujeto están realmente asociados, evitando de esta forma posibles suplantaciones de identidad (Aguilera, 2010, p. 162). “En la práctica, la firma digital se implementa mediante certificados digitales. Un certificado digital es un documento, con un formato especial, emitido y firmado por una autoridad de certificación que identifica la clave pública del propietario del certificado” (Seoane, 2005, p. 95). Un certificado digital es un documento digital mediante el cual un tercero de confianza (una autoridad de certificación) acredita electrónicamente la autenticidad de la identidad de una persona física, persona jurídica u otro tipo de identidad como lo puede ser, por ejemplo, una URL de un sitio web (López, 2010, p. 31). 2.2.5. FIRMA DIGITAL La firma digital es una tecnología que surge dentro de un esfuerzo más amplio que procura sustituir al tradicional documento impreso con el documento electrónico, especialmente en las transacciones no presenciales. En síntesis, es el resultado de encriptar (codificar), empleando una clave secreta o privada, un conjunto de datos que a su vez son el resultado de aplicar a un documento o mensaje lo se denomina una función hash (procedimiento capaz de generar una representación simbólica, matemática, del original). El documento o mensaje, con su correspondiente firma digital, es enviado al 12 destinatario, quien puede decodificar la firma digital y confrontar el resultado con el texto original. Una comparación exacta prueba irrefutablemente que el mensaje proviene del poseedor de la clave secreta y que no ha sido alterado en tránsito (Hess, 2001, p. 15). Para Riascos, Martínez y Solano (2008), la firma digital, es un instrumento que garantiza tanto la autenticidad de un documento (certeza sobre su originador) como la integridad del mismo (certeza sobre la integridad de su contenido); se puede decir que la firma digital es un conjunto de caracteres, que son puestos en un documento y que viajan con el mismo de una manera completamente electrónica. Estos caracteres son puestos en el documento por su creador mediante una llave privada que solo él conoce, previamente asignada por una entidad certificadora. 2.2.6. FIRMA ELECTRÓNICA “La firma electrónica es el conjunto de datos en forma electrónica, consignados junto a otros o asociados con ellos, que pueden ser utilizados como medio de identificación del firmante” (Hernández, 2014, p. 204). Según Martinez (2001), “firma electrónica es cualquier método o símbolo basado en medios electrónicos utilizado o adoptado por una parte con la intención actual de vincularse o autenticar un documento, cumpliendo todas o algunas de las funciones características de una firma manuscrita.” 2.2.7. CRIPTOGRAFIA La criptografía también puede emplearse para crear firmas digitales, para autenticar mensajes electrónicos y para verificar su integridad (esto es: los mensajes se recibieron en la misma forma en que se enviaron y provienen de la fuente indicada), lo que en el contexto de los negocios electrónicos resulta de vital importancia (Hance, 1997, p. 180). “Que la criptografía es la ciencia que se ocupa de transformar mensajes en formas aparentemente ininteligibles y devolverlos a su forma original” (Martínez, 2001, p. 45). “Arte de escribir con clave secreta o de un modo enigmático” (Real Academia Española, 2001). 13 A. CRIPTOGRAFÍA SIMÉTRICA Se utiliza la misma clave para cifrar que para descifrar los datos, con lo que ambas partes, emisor y receptor, deben conocer la clave (uno para cifrar y otro para descifrar), teniendo que basar sus relaciones en cuestiones de total y absoluta confianza, ya que, para que exista seguridad, la clave debe permanecer secreta y uno debe confiar en que el otro no la da a conocer a nadie y viceversa (Dávara, 2000, p. 421). B. CRIPTOGRAFÍA ASIMÉTRICA “Cuando el operador A quiere enviar un mensaje electrónico aplica al mismo su clave privada y el mensaje así cifrado se envía a B, que al recibir el mensaje le aplica la clave pública de A para obtener el mensaje descifrado” (Dávara, 2000, p. 421). 2.2.8. LA METODOLOGÍA AGIL Y FORMAL ICONIX ICONIX proceso es un análisis de casos de uso basada en el diseño y la metodología. Su foco principal está en cómo llegar de forma fiable a partir de casos de uso de código en menor número de pasos posible. (Rosenberg, Stephens y Collins-Cope, 2005). Figura 2.1: Ágil ICONIX en pocas palabras, adaptado. (Doug Rosenberg, Matt Stephens, and Mark Collins-Cope; 2005) A. PROCESO ICONIX Rosenberg y Stephens (2007) afirma: En teoría, todos y cada uno de los aspectos 14 de UML es potencialmente útil, pero en la práctica, nunca parece haber suficiente tiempo para hacer el modelado, análisis y diseño. Siempre hay presión por parte de la administración para saltar al código e iniciar la codificación de forma prematura, porque los avances en proyectos de software tienden a medirse por la cantidad de código existente. El proceso ICONIX, tal y como se muestra en la figura de apertura de este capítulo, es minimalista, tiene un enfoque racionalizado que se centra en esa zona que se encuentra entre los casos de uso y el código. Su énfasis está en lo que tiene que pasar en ese momento del ciclo de vida que se está comenzando: donde ya se tiene un inicio en algunos casos de uso, y es momento de hacer un buen análisis y diseño. Figura Nº 2.2: Esquema del proceso ICONIX, adaptado. (Rosenberg and Stephens; 2007) Gutiérrez (2008) sostiene que: Entre las características más importantes de ICONIX se encuentran: el permitir pasar de los requerimientos a código fuente de una manera rápida y eficiente; usar diagramas de UML; permitir el seguimiento de los requerimientos por todas las etapas del proceso; poseer un ciclo de vida iterativo e incremental; y tener en cuenta todos los requerimientos funcionales en el diseño. ICONIX se divide en las etapas de: análisis de requerimientos, análisis y diseño preliminar, diseño e implementación y pruebas. 15 B. INICIO DE LOS REQUISITOS a. Requisitos funcionales: Definir lo que el sistema debe ser capaz de hacer. Dependiendo de la forma en que su proyecto está organizado, ya sea que usted participe en la creación de los requisitos funcionales o que los requisitos serán "dictados desde lo alto" de un cliente o un equipo de analistas de negocios. b. Modelo de Dominio: Entender el espacio del problema en términos inequívocos (sin ambigüedad). c. Requisitos de comportamiento: Define la forma en que el usuario y el sistema interactúan (es decir, escribir el primer proyecto de casos de uso). Le recomendamos que empezar con un prototipo GUI (lo que llamamos “guión” GUI) e identificar todos los casos de uso que vamos a poner en práctica, o, al menos, llegar a una primera lista de casos de uso, que espera razonablemente cambiar a medida que se explora los requisitos con mayor profundidad. d. Etapa 1: Revisión de Requisitos: Asegúrese de que la descripción de los caso de uso coincidan con las expectativas de sus clientes. Tenga en cuenta que se deben revisar los casos de uso en pequeños lotes, justo antes de diseñarlos. C. ANÁLISIS, DISEÑO CONCEPTUAL, Y ARQUITECTURA TÉCNICA a. Análisis de robustez: Dibuje un diagrama de robustez (una "imagen del objeto" de los pasos en un caso de uso), reescribiendo los casos de uso a medida que avanza. b. Actualice el modelo de dominio mientras escribe los casos de uso y dibuje el diagrama de robustez. Aquí descubrirá algunas clases “perdidas”, corregirá las ambigüedades, y añadirá atributos a los objetos de dominio (por ejemplo: identificar que un libro tiene un Título, autor, sinopsis, etc.). c. Nombre todas las funciones lógicas del software (controladores) necesitadas para hacer que los casos de uso funcionen. d. Reescriba el primer borrador de casos de uso. D. DISEÑO Y CODIFICACIÓN a. Diagrama de Secuencia: Dibuje un diagrama de secuencia (un diagrama de 16 secuencia por cada caso de uso) para mostrar en detalle cómo va a implementar el caso de uso caso. La función fundamental de los diagramas de secuencia es asignar comportamiento para sus clases. b. Actualice el modelo de dominio mientras se dibujan los diagramas de secuencia, y añada operaciones a los objetos de dominio. En esta fase, los objetos de dominio son realmente clases de dominio, o entidades, el modelo de dominio debe convertirse rápidamente en un modelo estático, o diagrama de clases-una parte crucial de su diseño detallado. c. Limpiar el modelo estático. E. PRUEBAS Y TRAZABILIDAD DE REQUISITOS a. Código/pruebas unitarias: Escriba el código y las pruebas unitarias. (o, dependencia de sus preferencias, escriba las pruebas unitarias y luego el código) b. Integración y pruebas de escenario: Base las pruebas de integración en los casos de uso, de modo que así probara ambos cursos, el básico y el alterno. c. Ejecute una revisión de código y actualice el modelo para prepararse para la próxima ronda de trabajo. 2.2.8.1.DE LA METODOLOGÍA ICONIX A. MODELO DE DOMINIO Figura Nº 2.3: Modelo de dominio, adaptado. (Doug Rosenberg and Matt Stephens; 17 2007) “El modelo del dominio no es más que un diagrama de clases sin ningún tipo de detalle (sin atributos, sin métodos,…), en el cual se pueden ver gráficamente todas las relaciones identificadas en la Figura 2.3.”(Gutiérrez, 2008) “El Modelo de Dominio es un artefacto colaborativo vivo. Es refinado y actualizado en cada parte el proyecto, de modo que refleja siempre la comprensión actual del espacio del problema.” (Rosenberg y Stephens, 2007) B. MODELO DE CASOS DE USO Figura Nº 2.4: Modelo de casos de uso, adaptado. (Doug Rosenberg and Matt Stephens; 2007) Rosenberg y Stephens, (2007), con un primer modelo de dominio inicial en su lugar, es hora de comenzar a escribir los casos de uso. Los casos de uso dan un modo estructurado de capturar los requisitos de comportamiento de un sistema, de modo que puede razonablemente crear un diseño desde ellos. Le ayudan a responder ciertas preguntas fundamentales: ¿Qué están tratando de hacer los usuarios del sistema? ¿Cuál es la experiencia del usuario? Una cantidad sorprendente de lo que su software debe hacer se dicta por el modo en que los usuarios deben interactuar con él. 18 C. REVISION DE REQUISITOS Figura Nº 2.5: Revisión de requisitos, adaptado. (Doug Rosenberg and Matt Stephens; 2007) Rosenberg y Stephens (2007), la sesión de revisión de requisitos garantiza que el sistema tal y como se describe coincide con los requisitos. Se trata de un período de sesiones de colaboración que impliquen al representante(s) del cliente, los usuarios finales (es decir, las personas que realmente van a utilizar el sistema, o quien está usando el sistema actual que se sustituirá), y las personas de marketing-básicamente, todos los stakeholders que tienen un interés en asegurar que los requisitos encajen con su punto de vista del sistema. D. ANÁLISIS DE ROBUSTEZ Rosenberg y Stephens (2007), para obtener a partir de los casos de uso un diseño detallado (y luego el código), lo que se necesita es enlazar los casos de uso a los objetos. La técnica que se describe en este capítulo, el análisis de robustez, le ayuda a superar la brecha que existe del análisis al diseño. En pocas palabras, es una manera de analizar sus casos de uso e identificar un primer conjunto de objetos para cada caso de uso. Estos se clasifican en objetos interfaz, objetos entidad, y controladores (que son a menudo más como funciones que como objetos). 19 Figura Nº 2.6: Análisis de Robustez, adaptado. (Doug Rosenberg and Matt Stephens; 2007) E. REVISIÓN PRELIMINAR DEL DISEÑO “Las sesiones de Revisión del Diseño Preliminar (RDP) ayudan a asegurarse que los diagramas de robustez, el modelo de dominio, y la descripción de casos de uso coincidan entre sí. Esta revisión es el "puente" entre el diseño preliminar y en las etapas del diseño detallado, para cada paquete de casos de uso.” (Rosenberg y Stephens, 2007) 20 Figura Nº 2.7: Revisión Preliminar del diseño, adaptado. (Doug Rosenberg and Matt Stephens; 2007) F. ARQUITECTURA TÉCNICA El objetivo de arquitectura técnica (AT) es obtener un sentido general del sistema que vas a desarrollar. ¿Será un sistema basado en Internet? O un sistema en VB. NET o Java Swing, para un cliente muy rico?. Es necesario utilizar un framework de aplicación específico (por ejemplo, un framework de una compañía estándar). No hay una notación estándar o un formato para documentar la AT, la profundidad y el formato de la arquitectura técnica-y los convenios para crearla-varían mucho de empresa a empresa, por lo que no insistiremos en esta área demasiado tiempo. (Rosenberg y Stephens, 2007) 21 Figura Nº 2.8: arquitectura técnica, adaptado. (Doug Rosenberg and Matt Stephens; 2007) G. DIAGRAMA DE SECUENCIA Rosenberg y Stephens (2007), una vez que se ha finalizado el análisis de robustez, y ha celebrado una Revisión del Diseño Preliminar, es tiempo de iniciar el diseño detallado. En este momento, la descripción de sus casos de uso debe ser completa, correcta, detallada y explícita. En resumen, los casos su uso deben estar en un estado del que se pueda crear un diseño detallado. Todos los pasos del proceso hasta este momento han estado preparando a los casos de uso para la actividad del diseño detallado. Después de haber completado el análisis de robustez y la RDP, debería tener descubiertas casi todas las clases de dominio que va a necesitar. También es necesario tener la arquitectura técnica (AT) en la presente etapa. 22 Figura Nº 2.9: diagrama de secuencia, adaptado. (Doug Rosenberg and Matt Stephens; 2007) H. REVISIÓN CRÍTICA DEL DISEÑO Figura Nº 2.10: revisión Critico del diseño, adaptado. (Doug Rosenberg and Matt Stephens; 2007) 23 (Rosenberg y Stephens, 2007) señaló que: “Tu proyecto debería estar ahora en mucha mejor condición que muchos otros proyectos que están en esta etapa. Por ahora, has utilizado el análisis de robustez para desambiguar la descripción de los casos de uso y descubrir las clases de dominio faltantes, has mantenido una revisión de diseño preliminar (PDR) para asegurarte que los casos de uso coinciden con lo que el cliente realmente quiere, y has elaborado cuidadosamente un diseño detallado de los casos de uso que has implementado para esta versión. Por tanto, estás casi listo para comenzar la codificación-hay sólo una etapa rápida (pero vital) para comprobar el primero de la lista: Revisión del Diseño Critico (CDR).” I. IMPLEMENTACIÓN: PASO DEL DISEÑO DETALLADO AL CÓDIGO “Si usted ha pasado por todo el esfuerzo para crear un diseño agradable y detallado, vale la pena tener una buena idea de cómo traducir ese diseño detallado en el código fuente (y las pruebas unitarias, por supuesto.”(Rosenberg y Stephens, 2007) Figura Nº 2.11: Implementación, adaptado. (Rosenberg y Stephens; 2007) J. REVISIÓN DEL CÓDIGO Y ACTUALIZACIÓN DEL MODELO (Rosenberg y Stephens, 2007) señaló que: “Durante la codificación, lo más probable es que te han hecho algunos cambios en el diseño, por lo que el código ahora estar ligeramente fuera de sincronía con los diagramas de diseño. Una reacción tristemente común en este etapa consiste en considerar que la documentación de diseño 24 obsoleto, tirar a la basura, y seguir todas las posteriores desarrollo del trabajo sin hacer ningún trabajo de diseño más. Figura Nº 2.12: Revisión del código y actualización del modelo, adaptado. (Rosenberg y Stephens; 2007) K. DISEÑO GUIADO POR PRUEBAS Figura Nº 2.13: Diseño de pruebas, adaptado. (Rosenberg y Stephens; 2007) 25 (Rosenberg y Stephens, 2007) señaló que: “Es fácil ver el módulo de un programa y decir; “Bien, ya terminé”, pero este sentido de compleción puede decepcionarnos. ¿Cómo estás seguro que el código reúne todos los escenarios de casos de uso –no solo los cursos básicos, sino también los cursos alternos? Las Prueba basadas en el diseño (DDT, por sus siglas en inglés) provee un método ‘a prueba de balas’ para producir casos de prueba y verificar que todos los escenarios específicos están completos. Puedes además usar este proceso para escribir pruebas unitarias ejecutables de estos casos de prueba. La prueba es un proceso que debería comenzar mucho antes de la codificación. Comenzar a probar el producto cuando se afirma que está “terminado” es poco más que un pinchazo en el ojo, pero el proceso de prueba debería empezar bastante antes de que se empezara a codificar inclusive. La preparación para las pruebas comienza durante la fase de análisis, identificando los casos de prueba usando los diagramas de robustez. Es posible eliminar muchos más errores –antes que existan- haciendo pruebas tempranamente. Las pruebas hacen efecto poco después del diseño preliminar, y luego la escritura de código para pruebas unitarias tiene su lugar durante la implementación. Asegúrate que tus pruebas están estrechamente ligadas a tus requisitos. Eso no significa que cada prueba tenga que ser seguida hacia atrás hasta un requisito, pero debería haber una prueba para “verificar” que cada requisito ha sido implementado correctamente. El proceso que describimos en este capítulo es un método para hacer eso justamente: conduciendo los casos de prueba desde los casos de uso.” L. ATENDIENDO REQUISITOS Rosenberg y Stephens, 2007) señaló que: “No es una parte fundamental del proceso de simplemente porque las diferentes organizaciones tienen diferentes estrategias para el manejo de los requisitos. En algunas empresas, los requisitos son dictados desde lo alto, y por razones políticas u otras razones, no hay posibilidad de cambiar el proceso de obtención de requerimientos. De hecho, a veces parece como si hay tantas maneras de abordar los requisitos, ya que hay software proyectos de desarrollo.” 26 Figura Nº 2.14: atención de requisitos, adaptado. (Rosenberg y Stephens; 2007) 2.2.9. SISTEMA GESTOR DE BASE DE DATOS RELACIONAL Según Luque, Gómez, López y Cerruela (2002), un SGBD es una colección de programas de aplicación que proporciona al usuario de la base de datos los medios necesarios para realizar las siguientes tareas; a) Definición de los datos a los distintos niveles de abstracción (físico, lógico y externo), b)Manipulación de los datos en la base de datos, es decir, la inserción, modificación, borrado y acceso o consulta a los mismo, c) Mantenimiento de la integridad de la base de datos, integridad en cuanto a los datos en sí, sus valores y las relaciones entre ellos, d) Control de la privacidad y seguridad de los datos en la base de datos, e) Los medios necesarios para el establecimiento de todas aquellas características exigibles a una base de datos. Un sistema de gestión de base de datos relacional es un software o conjunto de programas que permite crear y mantener una base de datos. El SGBD actúa como interfaz entre los programas de aplicación (Usuarios) y el sistema operativo. El objetivo principal de un SGBD es proporcionar un entorno eficiente a la hora de almacenar y recuperar la información de la base de datos. (Cobo, 2007, p. 7). Para Rivera (2008), una base de datos relacional es básicamente un conjunto de tablas, similares a las tablas de una hoja de cálculo, formadas por filas (registros) y columnas (campos). Los registros representan cada uno de los objetos descritos en la tabla y los campos los atributos (variables de cualquier tipo) de los objetos. En el modelo relacional 27 de base de datos, las tablas comparten algún campo entre ellas. 2.2.10. LENGUAJE DE PROGRAMACIÓN ORIENTADA A OBJETOS La programación orientada a objetos (POO) encapsula datos (atributos) y métodos (comportamientos) dentro de objetos; los datos y los métodos de un objeto se encuentran íntimamente ligados entre sí. Los objetos tienen la propiedad d ocultar la información Esto significa que aunque los objetos puedan saber cómo comunicarse entre sí, a través de interfaces bien definidas, por lo general a los objetos no se les permite saber cómo se implementan otros objetos; los detalles de implementación están ocultos dentro de los mismos objetos (Deitel, 2004, p. 866). “En la programación orientada a objetos se usa un mecanismo llamado herencia (inheritance) para diseñar dos o más entidades que son diferentes pero que comparten muchas características comunes de las entidades” (Wu, 2008, p. 23). La clase de quien se hereda se conoce como clase padre o clase ascendente o superclase, mientras que la clase que hereda se conoce como clase hija o clase descendiente o subclase. Esta clase hija a su vez puede convertirse en padre y así sucesivamente. A ésta descendencia se conoce como jerarquía de clases (Vásquez y Balta, 2008, p. 27). El término polimorfismo expresa la posibilidad de que el mismo mensaje, enviado a objetos distintos, ejecute métodos distintos. Esto significa que podemos definir dentro de dos clases distintas dos operaciones con el mismo nombre y aspecto externo, pero con distintas implementaciones para cada clase (Noriega, 2007, p. 26). 2.2.11. UML El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Captura de decisiones y conocimiento sobre los sistemas que se deben construir. Se usa para entender, diseñar, hojear, configurar, mantener, y controlar la información sobre tales sistemas. El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas de modelado e incorporar las mejoras prácticas actuales en un acercamiento estándar (Rumbaugh, Jacobson y Booch, 2000, p. 3). En el proceso de desarrollo de software, las actividades definen los pasos necesarios para 28 lograr las metas y los objetivos, deben ser fáciles de definir y seguir; simplificar la comprensión del sistema; y ofrecer flexibilidad, precisión y extensibilidad. Las actividades básicas del proceso de desarrollo de software son las siguientes; a) Requisitos para especificar los aspectos funcionales del sistema, que describen cómo interactuaría un usuario con la aplicación, b) Análisis para dar al sistema una estructura o arquitectura robusta y extensible independiente del ambiente de implementación final, c) Diseño para adoptar y refinar la arquitectura del sistema y adaptarla al ambiente de implementación específico, d) Implementación para codificar el sistema, e) Integración para combinar componentes del sistema, f) Pruebas para validar y verificar el sistema, g) Documentación para describir los diversos aspectos del sistema, h) Mantenimiento para extender la funcionalidad del sistema (Weitzenfeld,2005,p. 38). El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas; la finalidad de los diagramas es presentar diversas perspectivas de un sistema a las cuales se les conoce como modelo. El modelo UML de un sistema es similar a un modelo a escala de un edificio junto con la interpretación del artista del edificio (Schmuller, 2001, p. 8). 2.2.12. REFIRMA El propósito del software REFIRMA es permitir firmar digitalmente documentos en formato PDF dentro del marco de la IOFE (Infraestructura Oficial de Firma Electrónica). Esto quiere decir, cumplimiento con los requisitos técnicos y legales que exige la Autoridad Administrativa Competente – ACC. Entre sus características principales podemos mencionar: a) Capacidad de visualización, firma y verificación de documentos en formato PDF 1.7 (ISO 32000-1:2008).  Es posible efectuar múltiples firmas digitales en un mismo documento.  Es posible verificar un documento con múltiples firmas digitales.  Es posible visualizar, firmar y verificar un documento firmado usando otro software de firma digital. b) Capacidad de verificación de documentos PDF firmados digitalmente. 29  Constata la integridad del documento firmado.  Visualiza información de la firma y del certificado asociado.  Visualiza información referida a la ruta de certificación de todas las firmas digitales del documento. c) Capacidad de verificación de la validez de un certificado.  Constata que el certificado sirve para efectuar firmas digitales.  Constata que, al momento de la firma, el certificado se encuentre vigente o no haya expirado.  Verifica el estado de renovación de un certificado de forma automatizada. - Procesamiento de CRLs, cuya URL es obtenida de los atributos del certificado procesado. d) Capacidad de procesamiento de la TSL.  Obtención la TSL (estándar ETSI TS 102 231) oficial del INDECOPI para la verificación de la ruta de certificación del certificado.  Procesamiento de las Entidades de Certificación acreditadas en la TSL.  Verificación de la integridad de la TSL. e) Capacidad de desarrollar rutas de certificación. Una ruta de certificación es un árbol jerárquico compuesto de certificados, CRLs o respuestas OCSP. f) Capacidad de procesamiento de la ruta de certificación. Para cada elemento de la ruta:  Verifica las firmas del certificado; para lo cual usa la clave pública del certificado del emisor.  Verifica que la fecha de realización del proceso de firma se encuentra dentro del periodo de vigencia del certificado.  Verifica que el uso del certificado es consistente con sus extensiones (distingue firma, autenticación y cifrado).  Verifica que el certificado no haya sido revocado. 30  Si el elemento verificado es el certificado de una entidad de certificación raíz verifica su estado en la TSL.  Si una de las verificaciones anteriores no es satisfactoria no se permite efectuar la firma digital. g) Capacidad de interacción con dos fuentes de certificados:  Instalados y gestionados por el sistema operativo MS Windows.  Importados desde archivos criptográficos en formato PKCS#12. 2.2.13. TECNOLOGÍA DE INTERNET A. INTERNET Según Camacho (2003), el internet es un nuevo espacio de interacción entre los seres humanos, que esta mediado por computadoras y que por eso tiene características especiales. Es imprescindible evidenciar que la participación individual y colectiva en el internet implica siempre una interacción social entre grupos y personas. Es decir, que es necesario visibilizar los hombres y mujeres que están sentados frente a las computadoras, estableciendo relaciones. Internet es conocida también como la red de redes, se basa en la tecnología cliente/servidor. Las personas que utilizan la red controlan sus tareas mediante aplicaciones web tal como software de navegador. Todos los datos incluyendo mensajes de correo y las páginas web se almacenan en servidores. Un cliente utiliza internet para solicitar información de un servidor web determinado situado en una computadora lejana; el servidor envía la información solicitada al cliente vía la red de internet (Joyanes, 2008, p. 30). Según Ceballos (2006), “es una red de redes informáticas distribuidas por todo el mundo que intercambian información entre sí mediante la familia de protocolos TCP/IP. Puede imaginarse Internet como una gran nube con ordenadores conectados”. B. APLICACIÓN WEB Para Luján (2002), en las aplicaciones web suelen distinguirse tres niveles (como en las arquitecturas cliente/servidor de tres niveles); el nivel superior que interacciona con el usuario (el cliente web, normalmente un navegador), el nivel inferior que 31 proporciona los datos (la base de datos) y el nivel intermedio que procesa los datos (el servidor web). Las aplicaciones web solo se distinguen de las aplicaciones de escritorio tradicionales en que, en vez de implementar la interfaz de usuario utilizando un lenguaje particular como C/C++ o Java, se utilizan páginas web como punto de acceso a las aplicaciones. Por consiguiente, no es de extrañar que también se construyan las aplicaciones web multicapa. Dichas aplicaciones construyen un interfaz utilizando formularios HTML, implementan su lógica en sistemas distribuidas y suelen almacenar sus datos en sistemas gestores de base de datos relacionales (Berzal, Cortijo y Cubero, 2005). Según Groussard (2010), una aplicación web generalmente se compone de los siguiente elementos: a) Recursos estáticos: paginas HTML, imágenes, sonidos, hojas de estilo, etc., b) Recursos dinámicos: servlets, JSP, Java Bean, c) Librerías de clases y d) Descriptor de despliegue para definir los parámetros de funcionamiento de la aplicación en el servidor. C. PROTOCOLO HTTP Para Mateu (2004), el protocolo HTTP (hypertext tranfer protocol) es el protocolo base de la WWW. Se trata de un protocolo simple, orientado a conexión y sin estado. La razón de que esté orientado a conexión es que emplea para su funcionamiento un protocolo de comunicaciones (TCP, transport control protocol) de modo conectado, un protocolo que establece un canal de comunicaciones de extremo a extremo (entre el cliente y el servidor) por el que pasa el flujo de bytes que constituyen los datos que hay que transferir, en contraposición a los protocolos de datagrama o no orientados a conexión que dividen los datos en pequeños paquetes (datagramas) y los envían, pudiendo llegar por vías diferentes del servidor al cliente. El protocolo HTTP [Hypertext Tranfer Protocol] es un protocolo simple de tipo solicitud- respuesta incluido dentro de la familia de protocolos TCP/IP que se utiliza en Internet. Esto quiere decir que, cada vez que accedemos a una página (en general, a un recurso accesible a través de HTTP), se establece una conexión diferente e independiente de las anteriores (Berzal, Cortijo y Cubero, 2005). 32 Figura Nº 2.15: Funcionamiento del protocolo HTTP (Berzal, Cortijo y Cubero, 2005) D. PROTCOLO TCP/IP Según Behrouz (2002), es un protocolo jerárquico compuesto por módulos interactivos, cada uno de los cuales proporciona una funcionalidad específica, pero que nos son necesariamente interdependientes. TCP/IP define dos protocolos en el nivel de transporte; Protocolo de Control de Transmisión (TCP) y Protocolo de Datagramas de Usuario (UDP). En el nivel de red, el principal protocolo definido por TCP/IP es el protocolo entre redes (IP). “El protocolo es el elemento que hace posible que los distintos ordenadores repartidos por el mundo y conectados a la red intercambien información. El protocolo que utiliza Internet es el TCP/IP” (Rodríguez, 2007, p. 7). 33 CAPITULO III METODOLOGÍA DE LA INVESTIGACIÓN 3.1. TIPO DE INVESTIGACIÓN Tipo de Investigación Desarrollaremos un aplicativo web de notificación electrónica mejorando la facturación del servicio de agua potable y alcantarillado SEDA Ayacucho S.A, 2017. Usando la Metodología Ágil y Formal Iconix. El tipo de investigación es aplicada, ya que se parte de los conocimientos adquiridos, además de la información de diferentes fuentes, todos ellos referidos al servicio de agua potable y alcantarillado SEDA Ayacucho. El propósito del trabajo busca la resolución del problema, es decir, los resultados aportados a la investigación implementan técnicas y estrategias para enfrentar y solucionar el problema. Nivel de Investigación El nivel de la investigación es descriptivo ya que en ella se precisa definir claramente lo que se deseamos conocer y consecuentemente, que o quienes serán objeto de la observación medida, que en nuestro caso son los usuarios que hacen uso del servicio de agua potable y alcantarillado. 3.2. DISEÑO DE LA INVESTIGACIÓN El instrumento de recolección de datos se usa durante el desarrollo del software para cada proceso (ICONIX) y de forma única, el diseño de la investigación es no experimental y transversal. 3.3. POBLACIÓN Y MUESTRA POBLACIÓN La población de estudio está compuesta por los usuarios que hacen uso del servicio de agua potable y alcantarillado SEDA Ayacucho S.A, 2017. 34 MUESTRA Se ha estimado el tamaño de la muestra mediante el sistema de muestreo aleatorio simple, siendo: N (E)2(N-1) + 1 En donde: N = Población n = Muestra E= Porcentaje de error (0.07)2 45 647 (0.07)2 (45 647 - 1) + 1 n = 203.17770337 n = 203 tamaño de muestra. 3.4. VARIABLES E INDICADORES 3.4.1. DEFINICIÓN CONCEPTUAL DE LAS VARIABLES VARIABLE INDEPENDIENTE Notificación electrónica.- Son aquellas comunicaciones que se emiten utilizando medios electrónicos y telemáticos, tales como el internet y el correo electrónico. La recepción de las notificaciones es confidencial y segura, enviando además al ciudadano mediante un correo electrónico habitual un aviso de recepción de notificación. INDICADORES DE LA VARIABLE INDEPENDIENTE Trazabilidad.- Son procedimientos que permite saber y conocer la ubicación, la trayectoria y ubicación de un producto. Capacidad de seguir el desplazamiento a través de una o varias etapas. Integridad.- Por integridad del mensaje en computación se entiende que cuando se envíe un mensaje de una persona a otra o bien de una máquina a otra, este mensaje no sea modificado, sin que el destinatario pueda comprobarlo. n = n = 35 Medio electrónico.- Un mecanismo, equipamiento o sistema que permite producir, almacenar o transmitir documentos, datos e informaciones, incluyendo cualquier red de comunicación abierta o restringida como Internet, telefonía fija y móvil o de otros”. VARIABLE DEPENDIENTE Facturación.- Es la actividad comercial que consiste en determinar y calcular los consumos durante un periodo mensual aplicando los precios unitarios establecidos, emitiendo los recibos con las características e importes calculados y entregarlos a cada uno de los clientes en sus domicilios. INDICADORES DE LA VARIABLE DEPENDIENTE Cliente.- Es la persona u organización que demanda bienes o servicios proporcionados por el productor o el proveedor de servicios, a cambio de un precio, siendo el elemento fundamental por y para el cual se crean productos en las empresas. Recibo de agua.- Es un documento impreso que contiene el monto a pagar, la cantidad de agua consumida en metros cúbicos, el cargo fijo que debe pagar el cliente. Es el punto de contacto más amplio entre la empresa y el cliente que a través del cual la empresa consolida su imagen. Recaudación.- Es el proceso de obtener o recibir dinero o recursos que tiene como finalidad cobrar los pagos pendientes, obtener dinero en efectivo de una persona o empresa a la que se le han emitido una o más facturas. 3.4.2. DEFINICIÓN OPERACIONAL DE LAS VARIABLES VARIABLE INDEPENDIENTE X: Notificación electrónica INDICADORES X1: Trazabilidad X2: Integridad X3: Medio electrónico 36 VARIABLE DEPENDIENTE Y: Facturación INDICADORES Y1: Cliente Y2: Recibo de agua Y3: Recaudación 3.5. TÉCNICAS E INSTRUMENTOS PARA LA RECOLECCIÓN DE DATOS 3.5.1. TÉCNICAS Se empleara las técnicas de entrevista y encuesta a los clientes que hacen uso del servicio de agua potable y alcantarillado en la ciudad de Ayacucho, presentado en el Anexo A, tabla N° A.1. 3.5.2. INSTRUMENTOS Guía de Entrevista a los clientes.- Instrumento que permite recopilar información sobre las variables en estudio, obtener información sobre el estado de servicio de agua potable y alcantarillado. Cuestionario estructurado a los clientes.- Instrumento que permite obtener información mediante un conjunto de preguntas, sobre la entrega de recibo de agua a su domicilio, presentado en el Anexo A, tabla N° A.1. Muestra la información de aceptación para el envió de recibo de agua mediante el correo electrónico, proporcionando por el cliente 3.5.3. HERRAMIENTAS PARA EL TRATAMIENTO DE DATOS E INFORMACION Las herramientas tecnológicas que se utilizan son seleccionadas en función a las necesidades y limitaciones como: recursos económicos y recursos humanos. SOFTWARE FABRICANTE SERVICIO WINDOWS 8 Microsoft Corporation Sistema operativo. 37 C# Desarrollado por Microsoft Corporation. Es un lenguaje de programación orientado a objetos diseñado para la infraestructura de lenguaje común. Utiliza el modelo de objetos de la plataforma .NET. ASP.NET MVC4 Desarrollado por Microsoft Corporation. ASP.NET MVC es el “nuevo” framework que ha sacado Microsoft para desarrollar aplicaciones web, usando tecnología .NET. VISUAL STUDIO 2013 Desarrollado por Microsoft Corporation. Visual Studio Ultimate 2013 es la solución de desarrollo de vanguardia que permite a los equipos de todos los tamaños diseñar y crear aplicaciones atractivas del gusto de los usuarios. Para elegir la opción de descarga más adecuada a sus necesidades, consulte las descripciones que se incluyen más adelante en esta página. SQL SERVER 2008 r2 Producido por Microsoft Es un sistema para la gestión de bases de datos basado en el modelo Relacional. HTML5 (LENGUAJE DE MARCAS DE HIPERTEXTO) Es el lenguaje de marcado predominante para la elaboració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. JAVASCRIPT JavaScript es un lenguaje de programación interpretado, dialecto del estándar ECMAScript. Se define como orientado a objetos, basado en prototipos, imperativo, débilmente tipado y dinámico. JSON Abril de 2001, y financiado por Empresas Tesla. En la actualidad dotas las empresas de JSON, acrónimo de JavaScript Object Notation, es un formato ligero para el intercambio de datos. JSON es un subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML. 38 desarrollo ofrecen sus versiones. AJAX Creado en 2005 por Jesse James Garrett Es una técnica de desarrollo web para crear aplicaciones interactivas. 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. UML Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables. ENTERPRISE ARCHITECT Enterprise Architect es una herramienta comprensible de diseño y análisis UML, cubriendo el desarrollo de software desde el paso de los requerimientos a través de las etapas del análisis, modelos de diseño, pruebas y mantenimiento. EA es una herramienta multi- usuario, basada en Windows, diseñada para ayudar a construir software robusto y fácil de mantener. Ofrece salida de documentación flexible y de alta calidad. El manual de usuario está disponible en línea. Tabla N° 3.1: Herramientas tecnológicas para tratamiento de datos. 3.5.4. TÉCNICAS PARA APLICAR ICONIX TAREA ARTEFACTO TÉCNICA RESPONSABLE 39 Identificar requisitos  Requisitos funcionales y no funcionales.  Casos de prueba de aceptación.  Entrevistas  Definir lo que el sistema debe hacer  Escribir al menos un caso de prueba para cada requisito Usuario Cliente Analista Identificar objetos del mundo real y dibujar modelo de dominio Modelo de dominio  Identificar clases clave del negocio.  Identificar sustantivos y depurar.  Identificar objetos en requisitos funcionales y asignar al modelo de dominio.  Utilizar agregación y generalización. Analista Asignar casos de uso a los requisitos funcionales Relación entre requisitos funcionales y casos de uso  Asignar casos de uso a los requisitos funcionales. Analista Descubrir casos de uso Lista de casos de uso  Utilizar requisitos funcionales  Entrevistas Usuario Cliente Analista Dibujar y empaquetar casos de uso  Paquete de casos de uso  Diagrama de casos de uso  Identificar roles y responsabilidades de actores.  Asociar actores con casos de uso.  Relacionar casos de uso.  Agrupar lógicamente casos de uso. Analista Realizar prototipo de interfaz grafica Prototipo GUI  Utilizar historia de eventos del usuario (storyboards).  Utilizar los requisitos funcionales. Programador Analista 40  Diseñar interfaz gráfica básica. Escribir el primer borrador de casos de uso Primer borrador de casos de uso  Utilizar glosario de objetos del modelo de dominio.  Utilizar la regla de dos párrafos  Escribir el caso de uso como flujos de evento/respuesta  Escribir el caso de uso con estructura sustantivo-verbo- sustantivo.  Escribir caso de uso en voz activa.  Referenciar por su nombre las pantallas. Analista Tabla N° 3.2: Análisis de requisitos (Porras, 2011) TAREA ARTEFACTO TÉCNICA RESPONSABLE Revisar el modelo de dominio Modelo de dominio revisado  Identificar al menos 80% de clases clave de dominio del problema. Usuario Cliente Analista Programador Revisar el prototipo GUI Prototipo GUI revisado  Diseñar con precisión la GUI relacionada al caso de uso Revisar la descripción de casos de uso Casos de uso revisado  Eliminar clases fuera del dominio del problema.  Cambiar descripción de voz pasiva a activa.  Describir todos los cursos alternos.  Asociar todos los requisitos a los casos de uso. 41  Describir que intenta hacer el usuario para cada caso de uso. Tabla N° 3.3: Revisión de requisitos (Porras, 2011) TAREA ARTEFACTO TÉCNICA RESPONSABLE Rescribir el primer borrador para cada caso de uso Casos de uso desambiguado  Rescribir el caso de uso durante el análisis de robustez. Analista Identificar el primer corte de objetos que completan escenarios para cada caso de uso Diagrama de robustez  Copiar la descripción del caso de uso en el diagrama de robustez.  Usar clases del modelo de dominio.  Crear un objeto interfaz por cada GUI y nombrarlo.  Transformar verbos del caso de uso en controladores.  Relacionar un caso de uso al diagrama de robustez cuando es invocado.  Utilizar las reglas para construir el diagrama de robustez. Actualizar el modelo de dominio Modelo de dominio actualizado  Actualizar el modelo de dominio con nuevas clases y atributos durante el análisis de robustez. Actualizar el diagrama de clases de análisis Modelo de dominio actualizado  Actualizar el diagrama de clases de análisis al finalizar el análisis de robustez. 42  Asignar atributos a las clases entidad. Tabla N° 3.4: Diseño preliminar (Porras, 2011) TAREA ARTEFACTO TÉCNICA RESPONSABLE Revisar descripción de casos de uso Caso de uso  Coincidir la descripción del caso de uso con el diagrama de robustez. Usuario Cliente Analista Programador Revisar diagrama de robustez Diagrama de robustez  Coincidir el diagrama de robustez con descripción de caso de uso.  Verificar que el diagrama de robustez cumple con las reglas.  Verificar que el diagrama de robustez tiene todos los cursos alternos. Revisar modelo de dominio actualizado Modelo de dominio actualizado  Coincidir los objetos entidad del diagrama de robustez con el modelo de dominio actualizado. Tabla N° 3.5: Revisión de diseño preliminar (Porras, 2011) TAREA ARTEFACTO TÉCNICA RESPONSABLE Diseñar diagrama de componentes Diagrama de componentes  Entrevistas.  Características del negocio.  Utilizar la arquitectura MVC.  Integrar frameworks. Cliente Analista Programador Arquitecto de software Diseñar diagrama de despliegue Diagrama de despliegue  Entrevistas.  Características del negocio.  Utilizar modelo cliente servidor. Tabla N° 3.6: Arquitectura técnica (Porras, 2011) 43 TAREA ARTEFACTO TÉCNICA RESPONSABLE Dibujar un diagrama de secuencia para cada caso de uso Diagrama de secuencia  Copiar la descripción del caso de uso.  Copiar objetos entidad, interfaz y actores del diagrama de robustez.  Verificar que un mensaje del diagrama de secuencia es verbo en el caso de uso.  Hacer refactoring al diagrama de secuencia antes de codificar. Programador Diseñador Actualizar el diagrama de clases de un caso de uso Diagrama de clase  Asignar operaciones a las clases a partir de los mensajes del diagrama de secuencia.  Establecer multiplicidad en las clases.  Depurar las clases, operaciones y atributos del diagrama de clases. Extraer controladores para pruebas unitarias Lista de controladores  Identificar controladores para la lógica del negocio desde un diagrama de robustez. Tabla N° 3.7: Diseño detallado (Porras, 2011) TAREA ARTEFACTO TÉCNICA RESPONSABLE Revisar diagrama de secuencia Diagrama de secuencia.  Verificar que el diagrama de secuencia coincide con la descripción del caso de uso  Verificar que el diagrama de secuencia Diseñador 44 representa los cursos básicos y alternos.  Verificar en los mensajes que los atributos y valores de retorno son correctos. Programador Revisar diagrama de clases Diagrama de clases  Verificar que el nombre, atributos y operaciones que asignaron correctamente a las clases.  Asignar requisitos no funcionales a los casos de uso y clases. Diseñador Programador Revisar lista de pruebas unitarias Lista de controladores  Actualizar la lista de controladores. Diseñador Programador Tabla N° 3.8: Revisión crítica de diseño (Porras, 2011) TAREA ARTEFACTO TÉCNICA RESPONSA BLE Implementar la base de datos física Base de datos física  Escribir el script usando el modelo de dominio actualizado.  Ejecutar el script usando un DBMS. Programador Implementar código para clases entidad Código fuente  Escribir o generar código fuente con una herramienta usando el modelo de dominio actualizado. Programador Implementar código para las interfaces Código fuente  Generar código fuente usando una herramienta. Programador Crear pruebas unitarias para cada controlador Prueba unitaria  Escribir código fuente para una prueba unitaria usando una herramienta. Programador 45 Implementar código fuente para cada controlador Código fuente  Escribir el código fuente siguiendo el flujo normal del diagrama de secuencia.  Actualizar el diagrama de secuencia con la codificación. Programador Ejecutar pruebas unitarias para cada controlador Reporte de pruebas unitarias  Ejecutar el módulo de cada prueba unitaria.  Modificar código fuente si la prueba unitaria es incorrecto. Programador Ejecutar pruebas de aceptación para cada caso de uso Reporte de pruebas de aceptación.  Utilizar los casos de prueba de aceptación.  Ejecutar el módulo de un caso de uso.  Modificar código fuente si la prueba de aceptación muestra resultado incorrecto. Programador Usuario Cliente Tabla N° 3.9: Implementación (Porras, 2011) 46 CAPITULO IV ANÁLISIS Y RESULTADOS DE LA INVESTIGACIÓN 4.1. RESULTADOS Aplicando las técnicas de la metodología ICONIX, obtenemos los artefactos como análisis de requisitos, revisión de requisitos, diseño preliminar, revisión de diseño premilitar, diseño detallado, revisión crítica de diseño e implementación. 4.1.1. ANÁLISIS DE REQUISITOS A. REQUISITOS FUNCIONALES N ° REQ REQUISITOS FUNCIONALES 1 El sistema debe permitir al administrador y al notificador ingresar al sistema mediante una cuenta de usuario. 2 El sistema debe ser capaz de validar el nombre usuario y contraseña ingresada. 3 El sistema debe permitir al administrador mostrar la lista de los clientes. 4 El sistema debe permitir al administrador modificar los datos del cliente. 5 El sistema debe permitir al administrador eliminar cliente. 6 El sistema debe permitir al administrador mostrar la lista de correos electrónicos de la empresa. 7 El sistema debe permitir al administrador registrar un nuevo correo electrónico de la empresa. 8 El sistema debe permitir al administrador modificar el correo electrónico de la empresa. 9 El sistema debe permitir al administrador eliminar el correo electrónico de la empresa. 10 El sistema debe permitir al notificador buscar al cliente por los apellidos y nombres. 47 11 El sistema debe permitir al notificador mostrar el cliente con sus respectivos datos (código, nombre completo, DNI o RUC). 12 El sistema debe permitir al notificador registrar el correo electrónico y el número de celular del cliente. 13 El sistema debe permitir al notificador mostrar la lista de clientes que confirmaron sus correos electrónicos según el mes, el año de facturación y el sector al que pertenecen. 14 El sistema debe permitir generar el documento de recibo de agua de cada cliente en formato PDF. 15 El sistema debe permitir al notificador visualizar en una vista previa el documento de recibo de agua generada. 16 El sistema debe ser capaz de guardar el documento de recibo de agua con nombre (sector, mes, año, nombre completo y código de cliente) en el servidor en formato PDF. 17 La Refirma permite firmar digitalmente los documentos de recibos de agua. 18 El sistema debe permitir al notificador mostrar la lista de los clientes a quienes se les generó sus recibos de agua según el mes, el año de facturación y el sector al que pertenecen. 19 El sistema debe permitir al notificador mostrar la ventana de envió de correo electrónico del cliente seleccionado. 20 El sistema debe permitir al notificador seleccionar la cuenta de correo electrónico con el que se enviara el mensaje. 21 El sistema debe permitir al notificador ingresar la contraseña de la cuenta de correo electrónico que fue seleccionada. 22 El sistema debe ser capaz de mostrar el correo electrónico o los correos electrónicos del cliente. 23 El sistema debe permitir al notificador mostrar el asunto del mensaje. 24 El sistema debe permitir al notificador adjuntar el documento de recibo de agua en formato PDF del cliente. 25 El sistema debe ser capaz de enviar el correo electrónico al cliente con su respectivo documento de recibo de agua. 48 26 El sistema debe ser capaz de enviar un mensaje de texto al celular del cliente, informando sobre su importe de facturación del servicio de agua potable y alcantarillado. 27 El sistema debe permitir al notificador visualizar el reporte de los correos enviados a cada cliente según el mes, el año de facturación y el sector al que pertenecen. Tabla N° 4.1: Requisitos funcionales B. REQUISITOS NO FUNCIONALES N ° REQ REQUISITOS NO FUNCIONALES 1 El sistema debe estar basado en una aplicación web. 2 La aplicación web debe tener un interfaz fácil de utilizar. 3 El acceso de usuarios debe ser mediante un nombre de usuario y contraseña. 4 La aplicación web debe presentar una arquitectura técnica y codificación usando estándares que permita su operación y mantenimiento. 5 La aplicación web usara procedimientos almacenados para mejorar el mantenimiento y las actualizaciones más fáciles. 6 La aplicación web visualizarse y funcionar correctamente en el navegador web Chrome. Tabla N° 4.2: Requisitos no funcionales C. GLOSARIO DE TÉRMINOS 2. Administrador. 3. Notificador. 4. Cuenta de usuario. 5. Cliente. 6. Correo electrónico. 7. Empresa. 8. Facturación. 9. Sector. 10. Documento. 11. Servidor. 49 12. Recibo de agua. 13. Refirma. 14. Firma digital. 15. Asunto. 16. Mensaje de texto. 17. Celular. 50 D. MODELO DE DOMINIO INICIAL Figura N° 4.1: Modelo de dominio inicial class Modelo de domi... Administrador Cliente CorreoElectrónico ReciboAgua FirmaDigital Empresa Facturación Sector Refirma Notificador Asunto CuentaUsuario Documento MensajeTexto Celular Serv idor envia tiene posee posee genera realiza envia realiza pertenece tiene pertenece tiene 51 E. RELACIÓN ENTRE REQUISITOS FUNCIONALES Y CASOS DE USO REQUISITOS FUNCIONALES CASOS DE USO Req 01. El sistema debe permitir al administrador ingresar al sistema mediante una cuenta de usuario. CU 01. Iniciar Sesión Req 02. El sistema debe ser capaz de validar el nombre usuario y contraseña ingresada. CU 02. Autenticar usuario. Req 03. El sistema debe permitir al administrador mostrar la lista de los clientes. Req 04. El sistema debe permitir al administrador modificar los datos del cliente. Req 05. El sistema debe permitir al administrador eliminar cliente. CU 03. Mantener cliente. Req 07. El sistema debe permitir administrador registrar un nuevo correo electrónico de la empresa. CU 04. Registrar Correo electrónico empresarial. Req 06. El sistema debe permitir al administrador mostrar la lista de correos electrónicos de la empresa. Req 08. El sistema debe permitir al administrador modificar el correo electrónico de la empresa. Req 09. El sistema debe permitir al administrador eliminar el correo electrónico de la empresa. CU 05. Mantener correo electrónico empresarial. Req 10. El sistema debe permitir al notificador buscar al cliente por los apellidos y nombres. Req 11. El sistema debe permitir al notificador mostrar el cliente con sus respectivos datos (código, nombre completo, DNI o RUC). CU 06. Mostrar cliente. Req 12. El sistema debe permitir al notificador registrar el correo electrónico y el número de celular del cliente. CU 07. Registrar correo electrónico de cliente. Req 13. El sistema debe permitir al notificador mostrar la lista de clientes que confirmaron sus correos electrónicos según el mes, el año de facturación y el sector al que pertenecen. CU 08. Mostrar lista de clientes confirmados. 52 Req 14. El sistema debe permitir generar el documento de recibo de agua de cada cliente en formato PDF. Req 15. El sistema debe permitir al notificador visualizar en una vista previa el documento de recibo de agua generada. Req 16. El sistema debe ser capaz de registrar el documento de recibo de agua con nombre (sector, mes, año, nombre completo y código de cliente) en el servidor en formato PDF. CU 09. Generar recibo electrónico de agua. Req 17. La Refirma permite firmar digitalmente los documentos de recibos de agua. CU 10. Firmar digitalmente recibo electrónico de agua. Req 18. El sistema debe permitir al notificador mostrar la lista de los clientes a quienes se les generó sus recibos de agua según el mes, el año de facturación y el sector al que pertenecen. CU 11. Mostrar lista de clientes con recibos electrónicos de agua. Req 19. El sistema debe permitir al notificador mostrar la ventana de envió de correo electrónico del cliente seleccionado. CU 12. Mostrar ventana de envió. Req 20. El sistema debe permitir al notificador seleccionar la cuenta de correo electrónico con el que se enviara el mensaje. Req 21. El sistema debe permitir al notificador ingresar la contraseña de la cuenta de correo electrónico que fue seleccionada. Req 22. El sistema debe ser capaz de mostrar el correo electrónico o los correos electrónicos del cliente. Req 23. El sistema debe permitir al notificador mostrar el asunto del mensaje. Req 24. El sistema debe permitir al notificador adjuntar el documento de recibo de agua en formato PDF del cliente. Req 25. El sistema debe ser capaz de enviar el correo electrónico al cliente con su respectivo documento de recibo de agua. Req 26. El sistema debe ser capaz de enviar un mensaje de texto al celular del cliente, informando sobre su importe de facturación del servicio de agua potable y alcantarillado. CU 13. Enviar correo electrónico. 53 Req 27. El sistema debe permitir al notificador visualizar el reporte de los correos enviados a cada cliente según el mes, el año de facturación y el sector al que pertenecen. CU 14. Emitir reporte de correos enviados. Tabla N° 4.3: Relación entre requisitos funcionales y casos de uso F. LISTA DE CASOS DE USO N ° CASOS DE USO 1 Iniciar Sesión. 2 Autenticar usuario. 3 Mantener cliente. 4 Registrar Correo electrónico empresarial. 5 Mantener Correo electrónico empresarial. 6 Mostrar cliente. 7 Registrar Correo electrónico del cliente. 8 Mostrar lista de clientes confirmados. 9 Generar recibo electrónico de agua. 10 Firmar digitalmente recibo electrónico de agua. 11 Mostrar lista de clientes con recibos electrónicos de agua. 12 Mostrar ventana de envió. 13 Enviar correo electrónico. 14 Emitir reporte de correos enviados. Tabla N° 4.4: Lista de casos de uso 54 G. PAQUETES DE CASOS DE USO Figura N° 4.2: Paquetes de casos de uso H. DIAGRAMA DE CASOS DE USO a. Actores Figura N° 4.3: Paquete “Actores” uc Actores Notificador Administrador Cliente Refirma Usuario 55 b. Administración Figura N° 4.4: Paquete “Administración” c. Mantenimiento Figura N° 4.5: Paquete “Mantenimiento” uc Mantenimie... Notificador (from Actores) Mantener cliente Registrar Correo electrónico empresarial Mantener Correo electrónico empresarial 56 d. Confirmar correo electrónico Figura N° 4.6: Paquete “Confirmar correo electrónico” e. Generar recibo electrónico de agua Figura N° 4.7: Paquete “Generar recibo electrónico de agua” f. Firma digital Figura N° 4.8: Paquete “Firma digital” uc Confirmar correo electrónico Mostrar cliente Registrar correo electrónico de cliente Notificador (from Actores) uc Generar recibo de agua Mostrar lista de clientes confirmados Generar recibo de agua Notificador (from Actores) uc Firma digital Refirma (from Actores) Firmar digitalmente recibo de agua 57 g. Enviar recibo electrónico de agua Figura N° 4.9: Paquete “Enviar recibo electrónico de agua” h. Reporte Figura N° 4.10: Paquete “Reporte” uc Env iar recibo de ag... Notificador (from Actores) Mostrar lista de clientes con recibos de agua Mostrar v entana de env ió Env iar correo electrónico uc Reporte Notificador (from Actores) Emitir reporte de correos env iados 58 I. PROTOTIPO DE INTERFAZ DE USUARIO PARA LOS CASOS DE USO CU 09. Generar recibo electrónico de agua Figura N° 4.11: Prototipo de interfaz gráfica “Generar recibo electrónico de agua” CU 10. Firmar digitalmente recibo electrónico de agua Figura N° 4.12: Prototipo de interfaz gráfica “Firmar digitalmente recibo electrónico de agua” 59 CU 11. Mostrar lista de clientes con recibos electrónicos de agua Figura N° 4.13: Prototipo de interfaz gráfica “Mostrar lista de clientes con recibos electrónicos de agua” CU 13. Enviar correo electrónico Figura N° 4.14: Prototipo de interfaz gráfica “Enviar correo electrónico” 60 J. PRIMER BORRADOR DE CASOS DE USO Casos de Uso Descripción CU 09. Generar recibo electrónico de agua Curso Básico: 1. El notificador hace clic en el menú lateral “Generar Recibo”. 2. El sistema muestra la página de generar recibo. 3. El notificador selecciona el mes, año de facturación y el sector. 4. El sistema muestra los clientes que confirmaron sus correos electrónicos anteriormente desde la base de datos en una tabla de lista de clientes. 5. El notificador hace clic en el botón “Generar” del cliente. 6. El sistema registra y genera el recibo de agua del cliente seleccionado y luego muestra una vista previa del recibo de agua. Curso Alterno: 1. El sistema no genera el recibo de agua del cliente. 2. El sistema no registra el recibo de agua del cliente. 3. El sistema no muestra la vista previa del recibo de agua del cliente. Tabla N° 4.5: Primer borrador de caso de uso “Generar recibo electrónico de agua” Casos de Uso Descripción CU 10. Firmar digitalmente recibo electrónico de agua Curso Básico: 1. El notificador hace doble clic en icono de “Refirma”. 2. El software Refirma muestra la página principal. 3. El notificador hace clic en el icono abrir documento. 4. El software Refirma muestra la venta de abrir documento. 5. El notificador selecciona el documento y hace clic en el botón abrir. 6. El software Refirma muestra el documentó seleccionado. 7. El notificador hace clic en la opción “Firmar”. 8. El software Refirma muestra la ventana de conformidad. 9. El notificador hace clic en el botón “Si”. 10. El software Refirma muestra la lista de certificados digitales. 61 11. El notificador selecciona el certificado digital. 12. El software Refirma muestra la venta de petición de acceso al certificado digital. 13. El notificador procede a ingresar la clave de acceso al certificado digital y luego hace clic en el botón “Aceptar”. 14. El software Refirma realiza la firma digital al recibo de agua. Curso Alterno: 1. El software Refirma no muestra la lista de los certificados digitales. 2. El software Refirma no realiza la firma digital al recibo de agua. Tabla N° 4.6: Primer borrador de caso de uso “Firmar digitalmente recibo electrónico de agua” Casos de Uso Descripción CU 11. Mostar lista de clientes con recibos electrónicos de agua Curso Básico: 1. El notificador hace clic en el menú lateral “Enviar Recibo”. 2. El sistema muestra la página de enviar recibo. 3. El notificador selecciona el mes, año de facturación y el sector. 4. El sistema muestra los clientes que se les genero los recibos de agua anteriormente desde la base de datos en una tabla de lista de clientes. Curso Alterno: 1. El sistema no muestra la página de enviar recibo. 2. El sistema no muestra la lista de clientes. Tabla N° 4.7: Primer borrador de caso de uso “Mostar lista de clientes con recibos electrónicos de agua” 62 Casos de Uso Descripción CU 13. Enviar correo electrónico Curso Básico: 1. El notificador hace clic en el botón “Seleccionar archivo”. 2. El sistema muestra la venta de adjuntar recibo de agua. 3. El notificador selecciona el recibo de agua que pertenece al cliente según sector, mes, año, nombre completo del cliente y código del cliente. 4. El notificador selecciona el correo electrónico de la empresa con el que se enviara, luego procede a ingresar la contraseña del correo electrónico seleccionado y luego hace clic en botón “Enviar”. 5. El sistema envía el correo electrónico al correo electrónico del cliente y un mensaje de texto al celular del cliente con la información de su recibo de agua. Curso Alterno: 1. El sistema no adjunta el recibo de agua. 2. El sistema no envía el correo electrónico al cliente. 3. El sistema no envía el mensaje de texto al celular del cliente. Tabla N° 4.8: Primer borrador de caso de uso “Enviar correo electrónico” 63 4.1.2. REVISIÓN DE REQUISITOS A. MODELO DE DOMINIO REVISADO Figura N° 4.15: Modelo de dominio revisado class Modelo de domi... Administrador Notificador Usuario Cliente CuentaUsuario CorreoElectrónico Empresa ReciboAgua CorreoCliente CorreoSeda Refirma FirmaDigital Facturación genera pertenece posee posee realiza posee realiza 64 B. PROTOTIPO GUI REVISADO CU 09. Generar recibo electrónico de agua Figura N° 4.16: Prototipo de interfaz gráfica revisada “Generar recibo electrónico de agua” CU 10. Firmar digitalmente recibo e