Estado del arte de metodologías, herramientas y lenguajes para el desarrollo de aplicaciones Web (página 2)

Teniéndose como base la metodología para el desarrollo del software seleccionada en el capítulo anterior, se estructurarán los tópicos de este capítulo por la disciplina que XP establece.

Se realiza una descripción de las características principales del sistema a desarrollar, teniéndose en cuenta el problema por el cual fue concebido. Además se especifican las funcionalidades que se desean informatizar en la búsqueda de satisfacer las necesidades de los usuarios.

2.2 Requisitos no funcionales del sistema.

Los requerimientos no funcionales son propiedades o cualidades que el producto debe tener y que de una u otra forma puedan limitar el sistema. Debe pensarse en estas propiedades como las características que hacen al producto atractivo, usable, rápido o confiable.

Usabilidad:

• El sistema debe estar funcionado durante el horario laboral.

• El sistema será utilizado por profesionales (autorizados del Grupo de Operación y Mantenimiento Técnico del Centro Telefónico de ETECSA Holguín), los cuales recibirán un adiestramiento básico para el uso de la aplicación.

Rendimiento:

• Para un funcionamiento óptimo de la aplicación se seguirán las diferentes técnicas de elaboración de sitios Web, que faciliten el acceso rápido a sus páginas.

• La eficiencia del producto estará determinada en gran medida por el aprovechamiento de los recursos que se disponen en el modelo cliente/servidor y la velocidad de la consultas de la base de datos.

• La aplicación propuesta debe ser rápida y el tiempo de respuesta debe ser el mínimo posible, adecuado a la rapidez con que el cliente requiere la respuesta a su petición.

Portabilidad:

• Las herramientas utilizadas podrán ser usadas bajo cualquier sistema operativo Windows NT en adelante o cualquier distribución de Linux.

• El servidor Web y el servidor de Base de Datos pueden estar en la misma PC sin ocasionar problema alguno.

Seguridad:

• Confiabilidad: La información manejada por el sistema debe estar protegida de acceso no autorizado. Realizar salvas de la base de datos periódicamente en diferentes máquinas preferentemente al finalizar cada jornada laboral.

• Integridad: La información manejada por el sistema debe ser objeto de cuidadosa protección contra la corrupción y estados de inconsistencia.

Software:

• En las computadoras de los usuarios solo se requiere un navegador Web, bajo cualquier sistema operativo Windows NT en adelante o cualquier distribución de Linux.

• En el servidor de base de datos se requiere Windows NT en adelante o cualquier distribución de Linux.

• Para su implementación se utilizará el framework Symfony como herramienta de desarrollo y como gestor de base de datos PostgreSQL.

Hardware:

• En el cliente se requiere una máquina con 128 MB de RAM como mínimo.

• El servidor Web junto con el servidor de base de datos debe tener 256 MB de RAM.

• Todas las máquinas implicadas en la funcionalidad de la aplicación deben estar conectadas a la red de al menos 100 Mbps de velocidad.

2.3 Personas relacionadas con el sistema.

Se denomina persona relacionada con el sistema a aquella que interactúa e intercambia con el sistema y obtiene resultados de los procesos desarrollados en la aplicación. Además aquella que interactúa con la misma sin poder hacer uso de las secciones privilegiadas del sistema. En la siguiente tabla se detalla una breve descripción sobre las actividades que puede realizar una persona con la aplicación.

Tabla 2.1 Personas relacionadas con el sistema.

2.4 Fase de Exploración.

La exploración es la primera fase de la metodología de Programación Extrema. En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo.

2.4.1 Historias de Usuario.

Las historias de usuario son la forma en que se especifican en XP los requisitos funcionales del sistema. Constan de 3 ó 4 líneas escritas por el cliente se escriben desde la perspectiva del cliente aunque los desarrolladores pueden brindar también su ayuda en la identificación de las mismas. Son usadas para estimar tiempos de desarrollo de la parte de la aplicación que describen. También se utilizan en la fase de pruebas, para verificar si el programa cumple con lo que especifica la historia de usuario.

En aras de solucionar la problemática existente en el Centro Telefónico de ETECSA Holguín relacionada con el proceso de gestión de la información que generada el Grupo de Operación y Mantenimiento Técnico, se identificaron 8 historias de usuario, las cuales se muestran a continuación:

Tabla 2.2 Historia de Usuario Autenticar Usuario.

Tabla 2.3 Historia de Usuario Gestionar Cuenta de Usuario.

Tabla 2.4 Historia de Usuario Gestionar AT1.

Tabla 2.5 Historia de Usuario Gestionar AT3.

Tabla 2.6 Historia de Usuario Gestionar Clave de Cierre.

Tabla 2.7 Historia de Usuario Gestionar Reparador

Tabla 2.8 Historia de Usuario Generar Reporte AT1.

Tabla 2.9 Historia de Usuario Generar Reporte AT3.

2.5 Fase de Planificación.

Durante la fase de planificación se realiza una estimación del esfuerzo que costará implementar cada historia de usuario. Este se expresa utilizando como medida el punto. Un punto se considera como una semana ideal de trabajo donde los miembros de los equipos de desarrollo trabajan el tiempo planeado sin interrupción.

Cuando se habla de estimación de esfuerzo se podría confundir con estimación de tiempos. Y no es tan raro, pues hay una relación importante. El esfuerzo se refiere a la suma de los tiempos que le dedicarán los diferentes recursos a cierta actividad o al proyecto. Se mide en horas/hombre, días/hombre, semanas/hombre, etc. No importa que el trabajo se haga de forma secuencial por un solo recurso o en paralelo por diferentes personas. Se suman los tiempos de cada uno de ellos para obtener el esfuerzo total.

2.5.1 Estimación de esfuerzos por Historias de Usuario.

Para el desarrollo de la aplicación propuesta en este trabajo se realizó una estimación del esfuerzo para cada una de las historias de usuario identificadas, permitiendo tener una medida real de la velocidad de progreso del proyecto y brindando una guía razonable a la cual ajustarse, los resultados se muestran en la siguiente tabla.

Tabla 2.10 Estimación de esfuerzos por Historia de usuario.

2.5.2 Plan de duración de las iteraciones.

Como parte del ciclo de vida de un proyecto utilizando la metodología XP se crea el plan de duración de cada una de las iteraciones, según los equipos de desarrollo con que se cuente, en este caso se hace para el único equipo de desarrollo que se tiene. Este plan se encarga de mostrar las historias de usuario que serán implementadas en cada una de las iteraciones, así como la duración estimada de cada una y el orden en que se implementarán.

Tabla 2.11 Duración de las iteraciones.

2.5.3 Plan de Entregas.

A continuación se presenta el plan de entregas ideado para la fase de implementación. En este plan se acoplan las funcionalidades referentes a un mismo tema en módulos, esto permite un mayor entendimiento en la fase de implementación quedando de la siguiente manera:

Tabla 2.12 Módulos e Historias de Usuario.

Tabla 2.13 Módulos e Iteraciones.

2.6 Iteraciones.

Esta es la fase principal en el ciclo de desarrollo de XP, incluye varias iteraciones sobre el sistema antes de ser entregado. Las funcionalidades son desarrolladas en esta fase, generando al final de cada una un entregable funcional que implementa las historias de usuario asignadas a la iteración. Como las historias de usuario no tienen suficiente detalle como para permitir su análisis y desarrollo, al principio de cada iteración se realizan las tareas necesarias de análisis, recabando con el cliente todos los datos que sean necesarios. El cliente, por lo tanto, también debe participar activamente durante esta fase del ciclo. Las iteraciones son también utilizadas para medir el progreso del proyecto. Una iteración terminada sin errores es una medida clara de avance.

1ra Iteración.

Esta iteración tendrá como objetivo darle cumplimiento a las historias de usuarios que tengan prioridad alta, estas historias de usuario son 1, 2, 3 y 4 que son las de mayor importancia para el cliente, estas recogen las principales funcionalidades del sistema.

2da Iteración.

En esta iteración se le dará cumplimiento a las historias de usuario de prioridad media 5 y 6 que complementan las funcionalidades de las Historias de Usuario realizadas en la iteración anterior.

3ra Iteración.

La implementación de las historias de usuarios 7 y 8 en esta iteración proporcionará una idea completa de la aplicación, al finalizar su implementación quedará terminado el sistema.

2.7 Tareas.

Todo el trabajo de la iteración es expresado en tareas de programación, cada una de ellas es asignada a un programador como responsable. Estas historias de usuario son divididas en tareas de entre 1 y 3 días de duración que se asignarán a los programadores.

Las tareas que se establecieron para el desarrollo de la aplicación web se relacionan a continuación:

Tabla 2.14 Tareas establecidas en cada iteración.

Tarea de la Primera Iteración

Tabla 2.15 Tareas Diseño de la interfaz de autenticación.

Tarea de la Segunda Iteración

Tabla 2.16 Tareas Diseño de la interfaz de Clave de Cierre.

Tarea de la Tercera Iteración

Tabla 2.17 Tareas Generación del reporte AT1.

Tabla 2.18 Tareas Generación del reporte AT3.

Las tareas restantes las podemos encontrar en el Anexo 2.

2.8 Producción.

La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase. Para ello:

• Se diseña.

• Se codifica.

• Se prueba.

2.8.1 Diseño.

Este sistema fue diseñado para facilitar la gestión de la información generada por el Grupo de Operación y Mantenimiento Técnico del Centro Telefónico de ETECSA de forma dinámica y agradable al usuario. Para lograrlo se emplearon algunos principios de diseño visual en las páginas que la conforman.

El diseño visual define la apariencia del sistema y es de gran importancia para lograr que el usuario se sienta satisfecho con la información que obtiene y con la forma en que lo hace por eso la aplicación presenta un diseño simple y sencillo, orientado al entorno de trabajo del cliente para que se sienta identificado con la aplicación.

Se eligieron los colores azul claro y oscuro, negro y blanco pues se consideró que estos colores contribuyen a construir una interfaz agradable a la vista del usuario, además de ser los colores representativos de la empresa para la que se realizó el mismo. Se utilizó el azul claro para el fondo de las páginas, algunas letras, y para el fondo de las tablas, el negro para las letras garantizando una lectura favorable de los textos. Se escogió la letra Verdana para los textos de las páginas. Este tipo de letra permite una lectura rápida y cómoda. Es mínimo el uso de imágenes y animaciones para evitar largos tiempos de espera a la hora de visualizarlas.

Para la construcción del sistema se tomaron en cuenta algunos de los estándares de implementación propuestos: un header o banner, donde se muestra la información general de sistema como logo de la institución, el nombre del sistema e imágenes y textos que muestren de manera general el contenido de la aplicación, un menú superior donde se encuentran los diferentes vínculos de acceso a las secciones del sistema, la sección del contenido donde se muestra la información que se desea buscar y finalmente un footer o pie de página donde se muestra la firma de derecho de autor. Una muestra de las pantallas es la de autenticación al sistema que puede ser consultada en el Anexo 1.

El diseño de la base de datos fue realizado con la herramienta Embarcadero ErEstudio, el mismo está compuesto por 16 tablas, la cuales están normalizadas, cumpliendo con las normas establecidas para el diseño de bases de datos.

Tarjetas CRC

La metodología XP para el diseño de las aplicaciones no requiere la presentación del sistema mediante diagramas de clases utilizando notación UML, en su lugar se usan otras técnicas como las tarjetas CRC (Contenido, Responsabilidad y Colaboración). No obstante el uso de estos diagramas puede aplicarse siempre y cuando influyan en el mejoramiento de la comunicación, no sea un peso su mantenimiento, no sean extensos y se enfoquen en la información importante.

La forma de diseño y organización que se adopta es de diseñar una tarjeta CRC (Clase-Responsabilidad-Colaboración) por cada uno de los módulos que brindan una funcionalidad directa al negocio, es decir aquellos que fueron desarrollados desde la raíz. De esta forma se obtiene un diseño simple y no se implementan características que no son necesarias. Estas tarjetas CRC permiten desprenderse del método de trabajo basado en procedimientos y trabajar con una metodología basada en objetos.

2.8.2 Codificación.

En la implementación del sistema se utiliza el lenguaje de programación web PHP (Personal Home Page), el cual es un lenguaje del lado del servidor y es diseñado originalmente para la creación de aplicaciones web dinámicas. Se emplean clases en el código fuente porque según las características del sistema se considera que es necesario emplear la programación orientada a objeto (POO). Además se hace evidente el uso de la reutilización de código pues las funcionalidades del sistema presentan características en común.

2.8.3 Pruebas Funcionales.

Las pruebas funcionales son pruebas que se crean a partir de las historias de usuario. Durante las iteraciones las historias de usuarios seleccionadas serán traducidas a pruebas funcionales.

En ellas se especifican, desde la perspectiva del cliente, los escenarios para probar que una historia de usuario ha sido implementada correctamente. Una historia de usuario puede tener todas las pruebas funcionales que necesite para asegurar su correcto funcionamiento. El objetivo final de éstas es garantizar que los requerimientos han sido cumplidos y que el sistema es aceptable.

Una historia de usuario no se considera completa hasta que no ha pasado por sus pruebas funcionales es por eso que se realizaron diferentes pruebas funcionales al software, las mismas se muestran a continuación:

Pruebas Funcionales de la Primera Iteración

Tabla 2.28 Prueba 1 Autenticar Usuario.

Pruebas Funcionales de la Segunda Iteración

Tabla 2.29 Prueba 5 Insertar Clave de Cierre.

Pruebas Funcionales de la Tercera Iteración

Tabla 2.29 Prueba 7 Reporte AT1.

Tabla 2.30 Prueba 8 Reporte AT3.

Las pruebas restantes se encuentran en el Anexo 3.

2.9 Mantenimiento.

Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar después de la puesta del sistema en producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura.

Como parte del proceso de perfeccionamiento de las funcionalidades del sistema y con el objetivo de satisfacer las solicitudes e inconformidades del cliente una vez que fueron entregadas cada iteración se realizaron mantenimientos al software, en algunas ocasiones fueron mantenimientos correctivos y en otras adaptativos.

2.10 Muerte del proyecto.

Se produjo cuando el cliente no tuvo más historias para ser incluidas en el sistema pues quedó satisfecho en todos los aspectos incluyendo rendimiento y confiabilidad del sistema. A partir de aquí se generó la documentación final del sistema y no se realizan más cambios en la arquitectura.

2.11 Conclusiones del capítulo.

El análisis del funcionamiento de la aplicación web permitió definir las características fundamentales del sistema propuesto a través de la Metodología de Ingeniería del Software escogida, su estructura, quiénes deben tener acceso a él y con qué finalidad; generándose los artefactos en cada una de las fases de dicha metodología.

A partir del análisis realizado se construyó la aplicación Web que introdujo una nueva vía para gestionar la información relacionada con la gestión de la información que generada el Grupo de Operación y Mantenimiento Técnico del Centro Telefónico de ETECSA Holguín.

• Conclusiones Generales

Con el desarrollo de esta investigación, se da cumplimiento a los objetivos propuestos.

• Se obtiene un software para la gestión y procesamiento de la información generada por el Grupo de Operación y Mantenimiento Técnico del Centro Telefónico de ETECSA Holguín.

• Fueron analizadas diferentes herramientas y tecnologías para el desarrollo del sistema.

• Permite el manejo de la información desde cualquier parte en la que exista conexión con la red del sistema en ETECSA Holguín.

• Recomendaciones

• Se recomienda la utilización del software para la gestión de la información generada por el Grupo de Operación y Mantenimiento Técnico de ETECSA Holguín.

• Se exhorta a la extensión de esta aplicación web a otras provincias que presenten un problema similar.

• Referencias Bibliográficas

• 1. Alonso, J. (2006, 29/09/2006). ¿Qué es un Framework? Retrieved 09/12, 2010, from http://jordisan.net/blog/2006/que-es-un-framework

• 2. Beck, K. (1999). Extreme Programming Explained. Embrace Change: Pearson Education.

• 3. Blanco, Y. C. (2007). Sistema para la Gestión de información relacionada con la Disciplina Laboral en los Joven Club de la provincia de Holguín. UNIVERSIDAD DE HOLGUIN "OSCAR LUCERO MOYA", Holguín.

• 4. Canós, J. H., Letelier, P., & Penadés, M. C. (2008). Métodologías Ágiles en el Desarrollo de Software.

• 5. Corona, G. J. G. (2010). Sistema para la gestión del cuestionario Kano en la ECTA "26 de Julio de la Provincia Granma. Unpublished Informática, Universidad de Granma.

• 6. Corporation, R. S. (2003). Ayuda extendida de RUP (Rational Unified Process)

• 7. Cumulus (2009 ). Cumulus Software Retrieved 08/02, 2011, from http://www.losprogramasgratis.net/2009/01/secomat-111-sencillo-control-de.html

• 8. Eguiluz, J. (2008, 01/02/2008). ¿Por qué Symfony es tan bueno? Retrieved 12/12, 2010, from http://www.symfony.es/2008/02/01/por-que-symfony-es-tan-bueno/

• 9. ETECSA (2010). Empresa de Telecomunicaciones de Cuba S.A Retrieved 11/01, 2011, from http://www.etecsa.cu

• 10. Fundation, T. A. S. (2011). The Apache Software Fundation, from http://www.apache.org

• 11. Gamboa, R. W., & Nuez, L. P. d. l. (2009). Modelación de un sistema informático para la gestión y control de las actividades asociadas al proceso de despliegue en Venezuela del proyecto PDVAL., UCI, Habana.

• 12. Group, P. G. D. (2007). PostgreSQL Retrieved 09/12, 2010, from http://www.postgresql.org/

• 13. Masadelante (2006). ¿Qué es un servidor? – Definición de servidor Retrieved 09/12, 2010, from http://www.masadelante.com/faqs

• 14. NetBeans.org (2010, 22/06/2010). Netbeans 6.9 final liberado Retrieved 09/12, 2010, from http://www.desarrolloweb.com/actualidad

• 15. Pacheco, C. T., & Pérez, J. A. R. (2009). Sistema para el control de la Base de Microbús de la Universidad de las Ciencias Informáticas., UCI, Habana.

• 16. Per Kroll, P. K. (2005). The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP (Object Technology Series)

• 17. Potencier, F., & Zaninotto, F. (2008). Symfony la Guía Definitiva.

• 18. Pyssa (2011). Secomat Retrieved 18/02, 2011, from http://www.pyssa.com/es/pygmao.asp

• 19. Ravioli, P. (2009). Lenguaje de programación para paginas web Retrieved 13/13, 2010, from http://www.monografias.com/Computacion/Programacion

• 20. Solís, M. C. (2003). Una explicación de la programación extrema (XP) Madrid – España.

• 21. Suárez, D. R. (2010). Desarrollo del Sitio Web para los profesores guías de la Facultad 8. Unpublished Informática, Universidad de Ciencias Informáticas.

• 22. Tecnology, I. (2008). Aplicaciones Web a la medida Retrieved 12/12, 2010, from http://www.intellia.com.mx/esp/servicios/aplicaciones_web_a_la_medida.php

• 23. Technologies, Z. (2009). Programmer's Reference Guide, Zend Framework Retrieved 09/12, 2010, from http://framework.zend.com/manual/en/index.html

• 24. Valdez, D. P. (2009). Los diferentes lenguajes de programación para la web Retrieved 13/12, 2010, from http://www.maestrosdelweb.com/principiantes/programacion

• 25. Wesley, A. (2000). Una explicación de la programación extrema. Aceptar el cambio.

Bibliografía Consultada

• 1. A. Navasa, M.A. Pérez, M. Sánchez.Ed. M. Sánchez. 1999. Aplicación de UML al desarrollo de sistemas orientados a objetos. 1999. 84-605-9632-X.

• 2. Alexander, Christopher, Ishikawa, Sara y Silverstein, Murray. 1977. A Pattern Language. New York: Oxford University Press, 1977. 0195019199.

• 3. Clements, Paul, y otros. 2002. Documenting Software Architectures: Views and Beyond. s.l.: Addison Wesley, 2002.0-201-70372-6.

• 4. Cockburn, Alistair. 2000. Writing Efective Use Cases. s.l.: Addison-Wesley, 2000. 0201702258.

• 5. Coplien, James. 1996. Software Patterns. s.l.: SIGS, 1996. 978-1884842504.

• 6. Delgado, Andrea, y otros. 2008. Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process. Monte Video, Uruguay: s.n., 2008. 4. Bass, Len, Clements, Paul y Kazman, Rick. 2003. Software Arquitecture in Practice, Second Edition. s.l.: Pearson Education, Inc., 2003. ISBN: 0-321-154959.

• 7. Billy Reinoso, Carlos y Kicillof, Nicolás. 2004. Estilos y Patrones en la Estrategia de Arquitectura de Microsoft. Buenos Aires: s.n., 2004

• 8. Grady Booch, Robert C, Martin y James Newkirk. Oriented Analysis and Design with Applications. s.l. : Addison Wesley Longman, 1998.

• 9. José H. Canós, Patricio Letelier y Mª Carmen Penadés. Métodologías Ágiles en el Desarrollo de Software.

• 10. Stephens, Matt y Rosenberg, Doug. Extreme Programming Refactored: The Case Against XP. Apress, 2003.

• 11. Jorge Ferrer Zarzuela. Metodologías Ágiles.

• 12. Joskowicz. Reglas y Prácticas en eXtreme Programming. 2008.

• 13. PostgreSQL. [En Línea] http://www.postgresql.org

• 14. PostgreSQL. Características fundamentales [En Línea].

http://www.netpecos.org/docs/mysql_postgres/x15.html

• 15. PostgreSQL Comparativas. [En Línea].

http://www.netpecos.org/docs/mysql_postgres/x108.html

• 16.  Miguel, Angel Alvarez. desarrolloweb.com. [Online] [Cited: Marzo 6, 2011.]

http://www.desarrolloweb.com/articulos/que-es-html.html

• 17.  maestrosdelweb.com. [Online] [Cited: Marzo 6, 2011.]

http://www.maestrosdelweb.com/editorial/introcss/.

• 18. Javier, Garcia Gallego Felipe. css.infames.org. [Online] [Cited: Marzo 7, 2011.] http://css.infames.org/ventajas.html.

• Glosario de Términos

APACHE: Herramienta software libre para servir aplicaciones Web en PHP y MySQL.

GNU: Proyecto que reside en la Fundación del Software Libre para la organización, control y difusión del software libre.

HTML (Hypertext Markup Language): Lenguaje usado para escribir documentos para servidores World Wide Web.

INTERNET: Red de redes a escala mundial de millones de computadoras interconectadas con el conjunto de protocolos TCP/IP.

OPEN SOURCE: Código abierto. Manera de nombrar también a las aplicaciones desarrolladas bajo el amparo de un producto con licencia GPL.

UML. (Unified Modeling Languaje): Es una notación standard para modelar objetos del mundo real.

XML: EXtensible Markup Language. Es un metalenguaje extensible de etiquetas desarrollado.HTML

RELEASE: Versión de un producto informático con mejorías leves. Cuando las mejoras son sustanciales se realiza un cambio de versión.

W3C: El World Wide Web Consortium, abreviado W3C, es un consorcio internacional que produce estándares para la world wide web, organización que desarrolla estándares para guiar la expansión de la Web. La misión del W3C es: guiar la Web hacia su máximo potencial a través del desarrollo de protocolos y pautas que aseguren el crecimiento futuro de la Web.

• Anexos

Anexo 1. Pantalla de autenticación al sistema.

Autor:

Ing. Eric Ismael Leonard Brizuela

M.Sc. Caridad Brizuela Arias

M.Sc. Yudi Castro Blanco

Bayamo, M.N.

Octubre, 2013

[1] Sistema Gestor de Bases de Datos