desarrollo adaptable de software, una solucin gil para aplicaciones
Anuncio
DESARROLLO ADAPTABLE DE SOFTWARE, UNA SOLUCIÓN ÁGIL PARA APLICACIONES E-COMMERCE DIEGO ANDRÉS GONZÁLEZ MORENO JOSÉ LUIS PEREA ÁLVAREZ PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS BOGOTA D.C. 2005 DESARROLLO ADAPTABLE DE SOFTWARE, UNA SOLUCIÓN ÁGIL PARA APLICACIONES E-COMMERCE DIEGO ANDRÉS GONZÁLEZ MORENO JOSÉ LUIS PEREA ÁLVAREZ Proyecto de grado presentado para optar el título de Ingeniero de Sistemas Director MIGUEL EDUARDO TORRES MORENO Ingeniero de Sistemas. PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS BOGOTA D.C. 2005 PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS Rector magnífico: R.P. Gerardo Remolina Vargas, S.J. Decano académico: Ing. Francisco Javier Rebolledo Muñoz Decano del Medio Universitario: R.P. Antonio José Sarmiento Nova, S.J. Director de Carrera: Ing. Hilda Cristina Chaparro López Director Departamento: Ing. Germán Alberto Chavarro Flórez Nota de aceptación ____________________________________________________ ____________________________________________________ ____________________________________________________ ______________________________________ Director del proyecto ______________________________________ Jurado ______________________________________ Jurado BOGOTA, D.C JUNIO DE 2005 Artículo 23 de la Resolución No. 1 de Junio de 1946 “La universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia.” A nuestras madres quienes son la mayor inspiración en nuestras vidas AGRADECIMIENTOS Los autores expresan sus agradecimientos a: Nuestras Familias por toda su colaboración. Nuestros compañeros por aguantarnos toda la carrera y por su continua ayuda y apoyo (ellos saben quienes son). Miguel Eduardo Torres, Ingeniero de Sistemas y Director de este proyecto, por su motivación y determinación en este trabajo. Profesores, docentes y colaboradores quienes hicieron posible nuestro desarrollo profesional. TABLA DE CONTENIDO Pág. 0. 1. INTRODUCCIÓN ...................................................................................................... 12 MARCO TEORICO................................................................................................... 14 1.1. EL DESARROLLO DE SOFTWARE ............................................................. 14 1.2. EXTREME PROJECTS .................................................................................... 15 1.3. DESARROLLO ÁGIL ....................................................................................... 16 1.3.2. Modelamiento ágil (AM) ........................................................................... 17 1.3.3. Scrum........................................................................................................... 17 1.3.4. Metodologías Cristal .................................................................................. 17 1.3.5. Feature Driven Development Method (FDD) .......................................... 17 1.4. ADAPTIVE SOFTWARE DEVELOPMENT (DAS) ..................................... 18 1.4.1. Ciclo de vida del Desarrollo Adaptable de Software............................... 19 1.5. FRAMEWORK .................................................................................................... 20 1.5.1. Patrones utilizados en el desarrollo de un Framework según Craig Larman 22 1.5.2. Patrones utilizados en el proceso de desarrollo de un Framework según Brent Carlson y James Carey.................................................................................... 23 1.6. E-COMMERCE................................................................................................... 26 2. DESCRIPCION DEL PROYECTO ......................................................................... 28 3. DESARROLLO ADAPTABLE DE SOFTWARE .................................................. 29 4. DESARROLLO DEL FRAMEWORK ...................................................................... 35 4.1. PLAN DE CICLOS DE DESARROLLO ADAPTABLE ............................... 35 4.2. ANALISIS ........................................................................................................... 36 4.3. DISEÑO............................................................................................................... 38 4.4. IMPLEMENTACION I ..................................................................................... 41 4.5. IMPLEMENTACION II.................................................................................... 49 4.6. PRUEBAS Y DOCUMENTACION.................................................................. 54 4.6.1. Pruebas ........................................................................................................ 54 4.6.2. Documentación ........................................................................................... 54 5. DESARROLLO DE LA APLICACIÓN PARA LA VENTA DE DVD ................ 56 5.1. PLAN DE CICLOS DE DESARROLLO ADAPTABLE ............................... 56 5.2. ANALISIS ........................................................................................................... 56 5.3. DISEÑO............................................................................................................... 57 5.4. IMPLEMENTACION I ..................................................................................... 59 5.5. IMPLEMENTACION II.................................................................................... 60 5.6. PRUEBAS Y DOCUMENTACION.................................................................. 65 5.6.1. Pruebas ........................................................................................................ 65 5.6.2. Documentación ........................................................................................... 65 6. CONCLUSIONES Y RECOMENDACIONES ....................................................... 66 TRABAJO A FUTURO ..................................................................................................... 72 BIBLIOGRAFIA ................................................................................................................ 73 LISTA DE FIGURAS Ilustración 1. Ciclo de Vida del Desarrollo Adaptable......................................................... 19 Ilustración 2. Diagrama de Casos de Uso del Framework ................................................... 37 Ilustración 3. Modelo de Datos del Framework ................................................................... 38 Ilustración 4. Diagrama de Arquitectura del Framework..................................................... 39 Ilustración 5. Clases Producto, BackupAdmin, Cliente y Administrador. ........................... 42 Ilustración 6. Clases TipoTarjeta, OrdenCompra, Tarjeta Credito y Producto Fisisco....... 43 Ilustración 7. Clases Service Locator y Factory.................................................................. 44 Ilustración 8. ClienteMgr Session EJB ................................................................................. 45 Ilustración 9. AdministradorMgr Session EJB. .................................................................... 46 Ilustración 10. TiendaMgr Session EJB ............................................................................... 47 Ilustración 11. EntidadFinancieraMgr y KartMgr SessionsEJB........................................... 48 Ilustración 12. Clases DAO's................................................................................................ 49 Ilustración 13. EJB EntitiesEJB CMP'S ............................................................................... 50 Ilustración 14. EJB EntitiesEJB CMP .................................................................................. 51 Ilustración 15. Clase Bussines Delegate............................................................................... 53 Ilustración 16. Diagrama Casos de Uso Aplicación DVD ................................................... 57 Ilustración 17. Modelo de Datos Aplicación DVD .............................................................. 58 Ilustración 18. Diagrama de Arquitectura Aplicación DVD ................................................ 59 Ilustración 19. Clase DVD y ProductoCreator ..................................................................... 60 Ilustración 20. Clase DAOProductos Aplicación DVD ....................................................... 60 Ilustración 21. BMPDVDProducto Aplicación DVD .......................................................... 62 Ilustración 22. Clase BusinessDelegate Aplicación DVD.................................................... 64 Ilustración 23. Clase Servlet Aplicación DVD..................................................................... 65 GLOSARIO DAS: Desarrollo Ágil de Software, metodología de desarrollo ágil la cual provee un marco de trabajo para sistemas de desarrollo iterativos largos y complejos. Framework: Un Framework es un conjunto de componentes reutilizables, los cuales intentan resolver determinado número de problemas en uno o más dominios. E-commerce: Es el tipo de transacción económica -compra y venta- que se realiza a través de sistemas electrónicos. Una empresa, comúnmente presente en la red, vende productos o servicios a través de Internet. Base de Datos: Una base de datos es un conjunto de información estructurada, como por ejemplo las cifras de ventas de un año. Las bases de datos tradicionales están diseñadas para gestionar datos tales como importes, cantidades, fechas y, limitadamente, texto. DAO: Data Access Object, este es un patrón el cual tiene como fin abstraer y encapsular todos los accesos a la fuente de datos, logrando así desacoplar la lógica de negocios de la lógica de acceso a datos. El DAO maneja la conexión con la fuente de datos para obtener y almacenar datos. Enterprise Java Beans EJB: Los EJBs proporcionan un modelo de componentes distribuido estándar para el lado del servidor. El objetivo de los Enterprise Beans es dotar al programador de un modelo que le permita abstraerse de los problemas generales de una aplicación empresarial (concurrencia, transacciones, persistencia, seguridad, etc.) para centrarse en el desarrollo de la lógica de negocio en sí. El hecho de estar basado en componentes nos permite que éstos sean flexibles y sobre todo reutilizables. EJBs de Entidad (Entity EJBs): Su objetivo es encapsular los objetos de lado de servidor que almacenan los datos. Los EJBs de entidad presentan la característica fundamental de la persistencia: • • Persistencia gestionada por el contenedor (CMP): El contenedor se encarga de almacenar y recuperar los datos del objeto de entidad mediante un mapeado en una tabla de una base de datos. Persistencia gestionada por el bean (BMP): El propio objeto entidad se encarga, mediante una base de datos u otro mecanismo, de almacenar y recuperar los datos a los que se refiere. 10 EJBs de Sesión (Session EJBs): Gestionan el flujo de la información en el servidor. Generalmente sirven a los clientes como una fachada de los servicios proporcionados por otros componentes disponibles en el servidor. Puede haber dos tipos: • • con estado (StateFul). Los Beans de sesión con estado son objetos distribuidos que poseen un estado. El estado no es persistente, pero el acceso al bean se limita a un solo cliente. sin estado (Stateless). Los Beans de sesión sin estado son objetos distribuidos que carecen de estado asociado permitiendo por tanto que se los acceda concurrentemente. No se garantiza que los contenidos de las variables de instancia se conserven entre llamadas al método. Business Delegate: Patrón que se utiliza para reducir el acoplamiento entre los clientes de la capa de presentación y los servicios de negocio. El Business Delegate oculta los detalles de la implementación del servicio de negocio, como los detalles de búsqueda y acceso de la arquitectura EJB. Java: Es una plataforma de software desarrollada por Sun Microsystems. Esta plataforma ha sido desarrollada de tal manera que los programas desarrollados para ella puedan ejecutarse de la misma forma en diferentes tipos de arquitecturas y dispositivos computacionales. J2EE: Se refiere a la plataforma Java 2 Edición Empresarial que define un estándar para desarrollar aplicaciones empresariales en lenguaje de programación Java. Oracle: Es un sistema de administración de base de datos (o RDBMS por el acrónimo en inglés de Relational Data Base Management System), fabricado por Oracle Corporation. SQL: El Lenguaje de Consulta Estructurado (Structured Query Language) es un lenguaje declarativo de acceso a Bases de Datos relacionales que permite especificar diversos tipos de operaciones sobre las mismas, aún a características del Álgebra y el Cálculo relacional permitiendo lanzar consultas con el fin de recuperar información de interés de una base de batos, de una forma sencilla. Carro de Compras: Entidad encargada de guardar en memoria los productos que el cliente desea comprar. JNDI: Una extensión de la plataforma Java que provee una interfaz estándar para nombres heterogéneos y directorio de servicios. Data Source: Un sitio de datos específico, donde la información es almacenada y puede ser obtenida. 11 0. INTRODUCCIÓN Cuando se desarrolla software es importante saber manejar los problemas comunes que pueden presentarse, por ejemplo el cambio en los requerimientos, mientras se desarrolla una aplicación, lo cual es una situación muy normal, debido a lo volátil que son las organizaciones hoy en día, y a la fuerte competencia que hay entre éstas. También el cambio de ámbito de las aplicaciones y la introducción de nuevas tecnologías pueden derivar en serios problemas de desarrollo, como estos hay muchos factores que hacen que el desarrollo de software sea una tarea compleja; estas situaciones son totalmente ajenas al equipo de trabajo. Lo que el desarrollo ágil de software busca es una fácil solución a estos problemas, mejorando el manejo de los cambios inevitables del proyecto y reduciendo los costos que nacen gracias a éstos, ya que facilitar el cambio es más efectivo que tratar de prevenirlo. El desarrollo ágil de software se enfoca más en los individuos y sus respectivas interacciones, que en los procesos y herramientas y le da mayor importancia al trabajo de software que las documentaciones. Es por eso, que la mayor prioridad del desarrollo ágil de software es la satisfacción del cliente, pero para llegar a ese punto es necesario la colaboración de todas las partes, ya sean patrocinadores, clientes, usuarios y por supuesto los desarrolladores. En el mundo de los procesos, se cree en la eficiencia de controlarlos y llevar un seguimiento para poder optimizarlos, pero la época en la que estamos viviendo no se rige por estas leyes o fundamentos, ya que el desarrollo de aplicaciones se ha vuelto en cierta forma impredecible, ya que es imposible controlar el cambio constante de las variables del entorno. El desarrollo adaptable de software, a diferencia de muchas otras metodologías, entiende que el mundo del dominio esta cambiando, por lo cual el desarrollo de software no puede verse desde una perspectiva lineal en ningún caso. Por lo que cada proyecto tiene un contexto y forma de resolución diferente. En Colombia, el desarrollo de software para e-commerce en las empresas es cada vez más fuerte y tiene más acogida1, por lo que cada vez mas grupos de desarrollo de software optan por diferentes metodologías para agilizar los procesos en su entorno. El desarrollo de aplicaciones reutilizables, se ha vuelto una costumbre, tanto para las empresas, como para los desarrolladores independientes. Es por eso que el diseño e implementación de Frameworks, ha ido creciendo de una forma acelerada ya que al ser reutilizables, reducen drásticamente los costos y la complejidad de los proyectos de 1 ACIS Asociación Colombiana de Ingenieros de Sistemas, http://www.acis.org.co/ 12 software. “Un Framework es un conjunto de clases reutilizables para el diseño e implementación de un clase de software específico. Extendiendo un poco esta definición se puede decir que un Framework es un conjunto de componentes que pueden solucionar problemas en uno o más dominios de aplicación”2. Es el encargado de manejar el núcleo de la aplicación. El objetivo de este proyecto es el desarrollo de un Framework para aplicaciones e-commerce utilizando el desarrollo adaptable de software. Para verificar la funcionalidad del Framework y ver su fácil adaptación y utilización, se desarrolló una aplicación específica de e-commerce, en este caso la venta de DVDs3 por Internet. Por medio del uso del desarrollo adaptable de software en este proyecto de investigación, se pretende mostrar la aplicación de una metodología diferente en el desarrollo de software, a las comúnmente usadas, para que esta pueda ser utilizada por personas interesadas en conocer el desarrollo de aplicaciones por medio de una metodología ágil. También se quiere mostrar, la importancia del análisis y el diseño a la hora de desarrollar aplicaciones reutilizables como el Framework, ya que estas etapas y sus respectivos entregables hacen parte de dicha reutilización. Esperamos que este Proyecto colme las expectativas del lector y deje un aporte en cada uno de ellos. 2 3 Carey, James y Carlson, Brent. Framework Process Patterns Pág. 1 Digital Video Disc 13 1. MARCO TEORICO Muchos autores a través de los años han comparado el desarrollo de software, con el alpinismo4, en esta disciplina, el objetivo es escalar la montaña, para conseguir esto el escalador debe tener ciertas habilidades dependiendo de las características de la montaña, es decir la altura, la inclinación, temperatura, clima y demás factores externos y además determinadas herramientas como botas, arnés, poleas, cuerdas, guantes y otras herramientas necesarias, las cuales aumentan o disminuyen la dificultad y el tiempo del ascenso (sin ellas puede llegar a ser imposible la escalada). En el desarrollo de software debemos tener ciertas habilidades y herramientas de acuerdo al tipo de proyecto (montaña) y su entorno (altura, clima etc.), ya que como en el alpinismo éstas nos ayudan o dificultan el logro de los objetivos planteados en el mismo. Este trabajo se enfoca en una forma particular de escalar montañas y de desarrollar software, de alta velocidad y rápido cambio. 1.1.EL DESARROLLO DE SOFTWARE A finales de los 70`s el desarrollo de software no era tarea compleja, eran comunes los “mainframe”5, y los requerimientos a cumplir eran pocos. COBOL era el lenguaje del momento y la ingeniería de la información era el camino, los modelos se caracterizaban por diagramas de flujo de datos y diagramas entidad relación. A esta época de desarrollo de software, Ken Orr la llama “Monumental Software Development” (Desarrollo de software monumental)6. Esta época se caracterizaba por un desarrollo “top-down” y “long-term” empezando en lo alto de las organizaciones, trasladando las necesidades del negocio en modelos de datos, e implementándolos en bases de datos para después construir aplicaciones. Todo esto tomaba varios años por lo que lo ideal era producir el software correcto en el primer intento. El punto más alto de esta época fueron las metodologías definidas en 14 volúmenes, en los cuales se detalla cada tarea, documento o forma, que debe tenerse en cuenta en el desarrollo de software, de estas prácticas se derivó lo que ahora conocemos como herramientas CASE (Computer-Aided Software Engineering). Hasta finales de los años 90 muchos productos de software fueron construidos utilizando estas técnicas de desarrollo, los cuales sufrieron varios tipos de inconvenientes, tales como: 4 James Highsmith, Adaptive Software Development, 2000 Capítulo 1, Computador Central 6 HIGHSMITH, James. Agile Software Development: The People Factor. En Institute of Electrical and Electronics Engineers (IEEE) magazine, Noviembre de 2001. 5 14 • Los clientes no estaban satisfechos, ya que después de ciclos tan largos de desarrollo, muchas aplicaciones no cubrían sus necesidades, ya que los requerimientos habían cambiado durante el desarrollo. • El tiempo que se tomaba el proceso era muy largo, y el negocio era muy variable, su cambio era muy rápido para ese tipo de ciclo de vida de desarrollo. • En general los métodos del desarrollo monumental de software no se adaptan bien al rápido y constante cambio de las condiciones y el entorno de algunos negocios. A principios de los años 90 esta perspectiva cambió debido a la aparición de los computadores personales, de C++, Java, Delphi, Visual Basic, etc., surgiendo una nueva forma de desarrollo que Ken Orr llama “Accidental Software Development” (Desarrollo accidental de software)7. Esta época al contrario de la Monumental, se caracteriza por la no existencia de métodos o metodologías, ya que se creía que el proceso solo demoraría el desarrollo, utiliza una metodología “bottom-up” y “short-term”, la cual empieza con el desarrollo inmediato de aplicaciones que cubren las necesidades de los clientes, dándole poca importancia a la integración con las demás aplicaciones, el código debía ser rápido sin prestarle mucha atención al diseño. El desarrollo de estas aplicaciones oscilaba entre los 2 a 6 meses, ya que se consideraba que si un proyecto duraba más tiempo sería un producto obsoleto al finalizar el proceso. El desarrollo accidental de software, también tenía varios inconvenientes: • La poca integración del software con las demás aplicaciones • Fragmentación de datos y redundancia múltiple, ya que el tener los datos sincronizados era un reto permanente, esto debido a la poca si no nula integración del software. • El software final requería mantenimiento constante, ya que las aplicaciones tenían datos redundantes, y diferentes modelos de datos. En conclusión este tipo de desarrollo termina siendo largo y costoso debido a la cantidad de correcciones y mantenimiento general que deben ser realizadas después de implantar el software. 1.2.EXTREME PROJECTS “Las organizaciones hoy en día, suelen tener problemas con los proyectos de alta velocidad y rápido cambio, que son comunes de e-business y e-commerce”8. Estos proyectos son desarrollados como proyectos comunes de software, por lo cual terminan siendo difíciles, problemáticos y comúnmente fallidos, ya que su entorno cambia constantemente, y su margen de error debe ser mínimo. Algunos de este tipo de proyectos se conocen como “Extreme Projects”, y difieren mucho de los proyectos comunes de software en que requieren menos velocidad y menos cambio. 7 HIGHSMITH, James. Agile Software Development: The People Factor. En Institute of Electrical and Electronics Engineers (IEEE) magazine, Noviembre de 2001. 8 James Highsmith Adaptive Software Development, 2000 Capitulo 1 15 “Para desarrollar esta clase de proyectos se requiere mas que una nueva herramienta o técnica, una nueva manera de pensar a la hora de desarrollar software”9. 1.3.DESARROLLO ÁGIL En el desarrollo de software es importante saber enfrentarse a problemas comunes, por ejemplo el cambio en los requerimientos, lo cual es una situación muy normal, debido a la competencia y los cambios que se viven en las organizaciones día a día. También el cambio de ámbito de las aplicaciones y la introducción de nuevas tecnologías, hacen que el desarrollo de software sea una tarea compleja; estas situaciones son totalmente ajenas al equipo de trabajo y usualmente ocurren a lo largo del ciclo de vida del proyecto, generando de este modo que el costo del proyecto cambie. Lo que el desarrollo ágil de software busca, es mejorar el manejo de los cambios inevitables, reduciendo costos que nacen a través del proyecto, ya que facilitar el cambio es más efectivo que tratar de prevenirlo.10 “El desarrollo ágil de software se enfoca más en los individuos y sus respectivas interacciones, que en los procesos y herramientas. Así como es más importante el trabajo de software que las documentaciones, y se preocupa por la colaboración con el cliente que en el contrato de negociación”.11 Es por eso, que la mayor prioridad del desarrollo ágil de software es la satisfacción del cliente, pero para llegar a ese punto es necesaria la colaboración, ya sea de patrocinadores, clientes, usuarios y por supuesto los desarrolladores. El desarrollo ágil de software se ha vuelto más popular en los últimos años, por lo que diversos métodos de desarrollo ágil han sido implementados, con el ánimo de poder entregar al usuario un software mucho más rápido. Los métodos de desarrollo ágil de software son basados en satisfacer al máximo al cliente, adaptarse al cambio fácilmente, hacer entregables frecuentemente y que exista una estrecha colaboración hacia el equipo de trabajo, por parte del personal del negocio. En comparación con los procesos de software tradicionales, los métodos de desarrollo ágil de software son orientados mucho más al código y a las entregas, por lo que la documentación no es el centro del proceso de desarrollo, donde al usuario le importa más la entrega realizada después de cada ciclo del desarrollo que el propio documento. 12 Los métodos de desarrollo ágil de software se preocupan más por la adaptabilidad que por la predicción, por lo que fueron desarrollados para adaptase y prosperar rápidamente a los cambios frecuentes. 9 HIGHSMITH, James. Agile Software Development: The Business of Innovation. En Institute of Electrical and Electronics Engineers (IEEE) magazine, Septiembre de 2001. 10 HIGHSMITH, James. Agile Software Development: The Business of Innovation. En Institute of Electrical and Electronics Engineers (IEEE) magazine, Septiembre de 2001. 11 HIGHSMITH, James. Requirements Engineering and Agile Software development. 2001. 12 HIGHSMITH, James. Requirements Engineering and Agile Software development. 2001. 16 Entre los métodos más comunes de desarrollo de Software están XP (Extreme Programming), Modelamiento Ágil (AM), Scrum, metodologías Cristal, FDD (Feature Driven Development), DSMD (Dynamic Systems Development Methods) y en la que se enfoca este trabajo DAS (Adaptive Software Development).13 A continuación se hará una breve reseña de las más importantes metodologías de desarrollo ágil de software 1.3.1. Extreme Programming (XP) Esta basado en simplicidad, retroalimentación y comunicación, donde los ciclos recomendados o iteraciones deben ser de 2 a 6 semanas, esto con el fin de producir entregas rápidas y una retroalimentación más continua, inventando soluciones simples, para que los cambios sean menores y corregirlos tome menos tiempo. Desarrollado para sistemas en constante cambio y basado en desarrollo en parejas. 1.3.2. Modelamiento ágil (AM) Da a los desarrolladores una base de cómo construir modelos, que resuelven problemas de diseño, para no construirlos nuevamente. No es un proceso de desarrollo completo, únicamente para el diseño. 1.3.3. Scrum Es un método para la gestión del proceso de desarrollo del sistema, aplicando ideas de flexibilidad, adaptabilidad y productividad para aplicaciones de proceso industrial. Scrum se basa en dar a conocer como un equipo de trabajo debe trabajar unido para producir una excelente calidad de trabajo en un ambiente en constante cambio. 1.3.4. Metodologías Cristal Son una familia de diferentes metodologías, las cuales pueden ser escogidas, dependiendo del tipo de proyecto, dentro de los tipos se encuentran Clear, Yellow, Orange, Red, Magenta, Blue, Violet. Entre más oscuro el color, más personas deben estar involucradas en el desarrollo, debido a la complejidad. 1.3.5. Feature Driven Development Method (FDD) Es una metodología que provee un marco de trabajo adecuado para el desarrollo de aplicaciones rápidas. Existen dos pasos en esta metodología, el primero es el estudio de factibilidad y el segundo es el estudio del negocio. A su vez la parte de pruebas, es integrada a la parte de desarrollo, es decir se van haciendo pruebas a medida que avanza el desarrollo. 13 HIGHSMITH, James. Agile Software Development: The Business of Innovation. En Institute of Electrical and Electronics Engineers (IEEE) magazine. 2001. 17 1.4.ADAPTIVE SOFTWARE DEVELOPMENT (DAS) Provee un marco de trabajo para sistemas de desarrollo iterativos largos y complejos. Se basa en un desarrollo iterativo e incremental con constantes entregas de prototipos. Debido a que los sistemas tienen múltiples cambios, DAS se basa en métodos tolerantes al cambio, donde los primeros ciclos deben ser cortos, y asegurarse de que el cliente esté totalmente envuelto en el proyecto y que el proyecto a su vez sea viable. Cada ciclo finaliza con las revisiones pertinentes por parte de el/los cliente/s y estas reuniones son documentadas para dejar por escrito los cambios y correcciones. 14 Las principales características del ciclo de vida adaptable son las siguientes • Enfocado a una Misión • Basado en Componentes • Iterativo • Tiempos de entregas • Mitigación de Riesgos • Tolerancia a cambios La cultura de optimización, cree en el rigor de los procesos, pero la era del Internet ha alterado estos fundamentos, ya que estas aplicaciones trabajadas vía Web son comúnmente impredecibles, porque tienen variables que están cambiando constantemente, como por ejemplo los requerimientos, los productos, la tecnología, etc. Es ahí donde el desarrollo adaptable de software entiende que para tener éxito en este tipo de aplicaciones, se debe aprender que el desarrollo de software no es un procedimiento mecánico sino uno orgánico, no lineal y no determinístico. Por lo que cada proyecto tiene un contexto y forma de resolución diferente. 14 HIGHSMITH, James. Requirements Engineering and Agile Software development. 2001. 18 1.4.1. Ciclo de vida del Desarrollo Adaptable de Software Ilustración 1. Ciclo de Vida del Desarrollo Adaptable El ciclo de vida Especular-Colaborar-Aprender, es un ciclo orientado al cambio, ya que esta dedicado al continuo aprendizaje, y a una alta colaboración entre los desarrolladores y sus clientes. A diferencia de la mayoría de metodologías de desarrollo de software las cuales utilizan un ciclo de vida estático: Planear-Diseñar-Construir, DAS ofrece un ciclo de vida iterativo no lineal, donde cada ciclo puede iterar y ser modificado al tiempo que otro lo hace. El desarrollo adaptable de software utiliza un ciclo de desarrollo dinámico e iterativo conocido como Especular-Colaborar-Aprender, este ciclo esta dedicado a un constante aprendizaje y a una intensa colaboración entre desarrolladores y clientes, esto debido al constante cambio en el ambiente de los negocios. • Especulación: Ofrece más espacio para explorar, para darse cuenta que no todo es seguro, permitiendo desviarse del plan sin ningún temor. Muchas veces desviarse del plan original puede considerarse un error, mas que una oportunidad de aprendizaje, es ahí donde la especulación incita a explorar y a experimentar. Si se admite que no se conoce todo, se está más dispuesto a aprender. • Colaboración: Las aplicaciones complejas requieren, la recolección y el análisis de un gran volumen de información, lo cual no puede ser controlado por una sola persona. A su vez aplicaciones con ambientes cambiantes como las de e-commerce producen un gran flujo de datos, los cuales no pueden ser manejados por una persona, o un grupo pequeño, ya que estos no pueden saberlo todo. • Aprendizaje: Se debe evaluar el conocimiento constantemente, realizando retroalimentaciones y reuniones de grupo, al final de cada ciclo iterativo, en lugar 19 de al final del proyecto, ya que esto ayuda a soportar y solucionar de una mejor manera el constante cambio que puede tener el proyecto, su adaptación. 1.5.FRAMEWORK Para aquella persona que está familiarizada con el desarrollo orientado a objetos (objectoriented development), estará a su vez familiarizado con el desarrollo de un Framework, ya que éste se basa en el diseño orientado a objetos, y a su vez es muy importante la entrega de componentes y la entrega limitada de documentación hecha anteriormente. Tal vez esto último suene conocido, ya que se basa en aspectos donde el Desarrollo Adaptable de Software también lo hace. Craig Larman define un Framework como “un conjunto extensible de objetos para funciones relacionadas”, como ejemplo podemos ver Frameworks de interfaz grafica de usuario, como AWT y SWING de Java15. Por otro lado se puede ver la definición de James Carey y Brent Carlson donde afirman que un Framework es una serie de componentes trabajando de forma unida, que direccionan el número de problemas en uno o más dominios16. Un Framework proporciona muchas clases e interfaces para las funciones principales que manejan los datos, interfaces, persistencia, etc. Gracias a esto los desarrolladores pueden crear subclases o redefinir ciertos métodos, dependiendo de las necesidades de su aplicación. Además pueden conectar diversos comportamientos de respuesta a los eventos en las clases de los elementos predefinidos. En general un Framework se caracteriza por: 17 • Ser un conjunto cohesivo de clases e interfaces que colaboran para proporcionar los servicios de la parte central e invariable de un sistema lógico. • Contiene clases concretas y abstractas que definen, las interfaces a las que deben ajustarse, interacciones de objetos en las que participar, y otras variantes. • Normalmente requiere que el usuario del Framework, defina subclases que extiendan o implementen las clases del Framework, con el fin de adaptar y extender los servicios de este. • Tener clases abstractas que podrían contener tanto métodos abstractos como concretos. • Confía en el Principio Hollywood, “No nos llame, nosotros le llamaremos”. Esto significa que las clases definidas por el usuario recibirán mensajes desde las clases predefinidas del Framework. 15 Larman, Craig. Applying UML and patterns: An introduction to object-oriented analysis and design. 1998. Carey, James and Carlson, Brent. Framework Process Patterns. 2002 17 Carey, James and Carlson, Brent. Framework Process Patterns. 2002 16 20 • Ofrecer un alto grado de reutilización. • Hay que tener en cuenta que un Framework no es una clase librería, ya que un Framework no provee clases y funciones al punto de ser únicas, sino que provee la reutilización al siguiente nivel de clases y funciones. Esto sin dejar atrás que un Framework puede ser construido mediante el uso de una librería. • El desarrollo de un Framework no es solo un grupo de patrones, sino que a su vez es la combinación de diseños e implementaciones, enfocados a encontrar una serie de necesidades en general y una construcción acorde a las necesidades de las cuales se pueda extender y personalizar para que se ajuste a las necesidades anteriormente descritas. • Existen 6 disciplinas las cuales se debe tener en cuenta para un desarrollo de un Framework de forma adecuada, como lo son la comunicación, consistencia, iteración, incompletitud, flexibilidad y desconfianza. o Comunicación: Debido a que la información debe ser comunicada a tiempo y de una manera precisa o Consistencia: Las cosas iguales deben ser hechas de igual manera. o Iteración: Debido a que debe estar en constante refinamiento. o Incompletitud: Esto con el fin de que los usuarios tengan la habilidad de completarlo para sus necesidades particulares. o Flexibilidad: Se debe determinar hasta donde debe llegar el grado de extensión del Framework, con el fin de que el usuario pueda implementar ciertas cosas a su gusto. o Desconfianza: Las cosas que son obvias, a su vez pueden generar problemas sino se tiene cuidado. Con el fin de desarrollar un Framework de buena calidad se deben o pueden utilizar distintos patrones de software, que permitan realizar un buen diseño e implementación de éste, esto depende en general de los siguientes factores: • Correspondencia: Se debe establecer alguna correspondencia (mapping), entre una clase y su almacenamiento persistente, y entre los atributos de los objetos y los campos en un registro. • Identidad de Objeto: Existe un único identificador de registros y objetos, con el fin de asegurar que no haya duplicados. • Conversor de base de datos: Un Mapper encargado de la materialización y desmaterialización de la base de datos. • Materialización y Desmaterialización: Transformar una representación de datos no orientada a objetos de un almacenamiento persistente a objetos y viceversa. • Caché: Los servicios persistentes almacenan en un caché los objetos materializados por razones de rendimiento. • Estado de Transacción de Objeto: Es útil conocer el estado de los objetos en función de sus relaciones con la transacción actual. 21 • Operaciones de transacción: Commit y Rollback. • Materialización Perezosa: No todos los objetos se materializan de una vez, solo lo hacen por demanda. A partir de estos factores, se seleccionan los patrones de software a utilizar en la construcción del Framework. 1.5.1. Patrones utilizados en el desarrollo de un Framework según Craig Larman18 Representación de Objetos como tablas: Este patrón propone la definición de una tabla en una base de datos relacional por cada clase de objeto persistente. Los atributos de los objetos que contienen tipos de datos primitivos, se corresponden con las columnas. Por lo que si un objeto tiene atributos de tipos de datos primitivos la correspondencia es directa. Identificador de objetos: Es muy conveniente contar con una forma de relacionar los objetos y los registros y asegurar que la materialización no proporciona objetos duplicados. Este patrón propone asignar a cada objeto y registró un identificador único (Object ID). Este identificador usualmente es un valor alfanumérico. En el campo de los objetos, un OID se representa mediante una interfaz o clase OID, que encapsula su valor real y su representación, en el caso de las bases de datos comúnmente se almacena como un carácter de longitud fija. Cada tabla tendrá un OID como llave primaria y cada objeto tendrá un OID asociado, con esto cada objeto se corresponde de manera 1 a 1 con un registro de una tabla. Un OID también proporciona un tipo de llave consistente para utilizarla en la interfaz con el servicio de persistencia. Fachada: La fachada se encarga de proporcionar una interfaz uniforme a un subsistema. Método Plantilla: Este patrón es un parte esencial en el diseño del Framework, la idea es crear un método en una superclase que defina el esqueleto de un algoritmo, con sus partes variables e invariables. El método plantilla invoca otros métodos, algunos de estos pueden ser redefinidos en una subclase, de esta manera se puede añadir un comportamiento propio y único a los puntos de variabilidad, dependiendo de las necesidades del usuario. Estado: Para este patrón debemos asumir que los objetos persistentes pueden, insertarse, eliminarse o modificarse. Pero operar sobre un objeto persistente no provoca una actualización inmediata de la base de datos. 18 Larman, Craig. Applying UML and patterns: An introduction to object-oriented analysis and design. 1998 22 Por esto el patrón crea clases de estado para cada estado, que implementa una interfaz común, ya que el comportamiento de un objeto depende de su estado y sus métodos contienen la lógica de casos que reflejan las acciones dependientes del estado. Command: Una transacción es un conjunto de tareas las cuales deben completarse todas con éxito o no se debe completar ninguna (atomicidad). En cuanto a los servicios de persistencia, las tareas de una transacción (insertar, eliminar, actualizar) podrían ser varias, por ejemplo 2 insertar y 1 actualizar. Para esto se define una clase por cada tarea que implemente una interfaz común, así las acciones se convierten en objetos y de esta forma se pueden ordenar. Cada tarea o acción de la transacción se representa mediante un objeto que posee un método polimórfico “ejecutar”, este nos proporciona flexibilidad ya que la respuesta es tratada como un objeto en si.19 1.5.2. Patrones utilizados en el proceso de desarrollo de un Framework según Brent Carlson y James Carey20 Los patrones que se mencionan a continuación son patrones que tienen que ver con el todo el proceso de desarrollo del Framework, su arquitectura y ciertos aspectos a considerar en la ejecución del proceso de desarrollo. Seguir un proceso de desarrollo metódico: Para el desarrollo de un Framework es necesario seguir con un proceso metódico, este podrá ser cualquiera que sea acorde a lo que se quiere, ya que el proceso escogido le permitirá crear los artefactos de las necesidades del usuario del Framework de forma consistente. Conectar Dominio y técnicos expertos: Debido a que el software se mueve en dirección al reino de la aplicación del negocio y las tecnologías permanecen en constante avance, es muy difícil tener una persona en algún momento determinado que posea el dominio y la experiencia técnica necesarias, a su vez es necesario que se incremente la conexión entre expertos, ya que esto mejorará el software que se produce. Este patrón se conoce también como “Preguntas Inocentes”. Dividir y Conquistar: Este es una frase conocida, la cual significa que los problemas grandes deben ser divididos para convertirlos en pequeños problemas para facilitar su solución. El Framework deberá ser dividido en partes que sean más fáciles de desarrollar y llevar a cabo. La consistencia es el Rey: 19 20 Larman, Craig. Applying UML and patterns: an introduction to object-oriented analysis and design. 1998 Carey, James and Carlson, Brent. Framework Process Patterns. 2002 23 Este patrón conocido también como “Mantener la consistencia a través del Framework”, lo que quiere es mostrar que una de las mejores cosas que se puede hacer es mejorar el entendimiento y la utilidad del Framework a construir, haciéndolo más consistente. Tres iteraciones para validar: Como cualquier desarrollo de software orientado a objetos, la iteración es un aspecto muy importante en el desarrollo de un Framework. Estas iteraciones permitirán un refinamiento del Framework, y según los autores el número de iteraciones es importante definirlo, pero 3 iteraciones es la clave según autores21. Exponerlo todo: Conocido también como “El cliente del Framework es su compañero”, ya que el usuario es parte del equipo de desarrollo del Framework, por lo que el Framework deberá ser compartido y explicado al usuario. Una de las principales tareas del desarrollo de un Framework, y se podría decir que es la más importante, es la definición de requerimientos, ya que identificarlos y capturarlos es la clave para la construcción exitosa del Framework. Un buen levantamiento de requerimientos ayuda a asegurarse de que el Framework esta bien enfocado. Según Carey y Carlson de esta tarea depende todo de ahí en adelante, si se construye una buena base, el éxito será más fácil de alcanzar.22 Existen ciertos patrones para la recolección de requerimientos.23 Identificar la personalización: Para encontrar puntos potenciales que se han perdido o no se han detectado, se puede escuchar al experto del dominio en sus discusiones y argumentos, de allí se pueden recaudar ideas interesantes. Cuando algo es realmente extremo: Saber identificar cuando un requerimiento es extremo e innecesariamente aumenta la complejidad del Framework. Por lo que se debe tener en cuenta cuando refinar, explorar y evaluar un requerimiento para que sea manejable. Implementación haciéndose pasar por requerimientos: Debe tenerse en cuenta en la evaluación de requerimientos, que esos requerimientos no estén únicamente describiendo una implementación en disfraz, sino que hay que tomarse el tiempo para explorar los objetivos que están detrás de los requerimientos ya declarados. Como segundo ciclo se puede ver el ciclo del Análisis, que según los autores Carey y Carlson antes mencionados24, si la fase anterior eran los requerimientos, y estos son la 21 Carey, James and Carlson, Brent. Framework Process Patterns. 2002 Carey, James and Carlson, Brent. Framework Process Patterns. 2002 23 Carey, James and Carlson, Brent. Framework Process Patterns. 2002 22 24 materia prima, el análisis es el que comienza con su proceso de refinamiento. Si el análisis es bueno, debe identificar entidades y definir responsabilidades. Existen ciertos patrones que sirven para asistir en la fase del análisis. Descomponiendo el problema: Conocido también como “Comerse el elefante (un mordisco a la vez)”, lo que trata de mostrar es que cuando se esta analizando el dominio del problema del Framework, se debe buscar oportunidades de separar aspectos grandes en componentes que tienen un mínimo de interacción con otros componentes y las clases de análisis con una alta afinidad con otras clases deberán ser agrupadas entre sí para facilidad en el manejo de dependencias. Algo es mejor que nada: Conocido también como “Documentar lo que conoces cuando lo conoces”. Este patrón es básico, ya que lo que indica es que a medida que se va adelantando, se debe documentar, claro que esta documentación deberá ser sencilla e informal, ya que no se pretende tardar mucho tiempo documentando. A su vez cuando se piense en algo que necesite hacerse, deberá escribirse con el fin de que esto no que de en el aire y se olvide. Comunicación entre dominio y equipo: Debe haber una excelente comunicación y profunda información entre los desarrolladores y las funciones del dominio para las cuales ellos tienen la responsabilidad. A su vez si existe un error debido a la constante comunicación que debe haber, la corrección de este se hará de forma temprana y su costo será mucho menor. El tercer ciclo llamado el Diseño se encarga de convertir o transformar la información que provee el análisis y los requerimientos en verdaderos anteproyectos (blueprints). Es aquí donde los métodos, las clases y las relaciones son definidos y trabajan juntas para completar el comportamiento descrito en los casos de uso. Existen patrones que sirven para asistir en la fase del Diseño. Conocer cuando un Framework no debería hacer algo: Este patrón es usado, para ayudar en la implementación de lo funcional, que pueda quedar algo a la imaginación del usuario, ya que en ciertos casos deberá dejarse abierto para que el comportamiento del Framework no sea tan estricto, y el usuario pueda personalizarlo. Desarrollar y aplicar patrones: Los patrones son la clave del desarrollo exitoso de un Framework. Ellos llevan a la consistencia, crear un nivel alto de lenguaje y a aumentar la velocidad de desarrollo. Los Frameworks no están exentos de prácticas buenas o malas de ser orientados a objetos: 24 Carey, James and Carlson, Brent. Framework Process Patterns. 2002 25 Se debe tener en cuenta que el desarrollo de Frameworks debe ser orientado a objetos, por lo que las malas prácticas en proyectos orientados a objetos no deberán ser usadas para el desarrollo de un Framework. 1.6. E-COMMERCE La introducción del comercio electrónico en los países en desarrollo, ha provocado cambios dramáticos en la forma en que se desarrollan los negocios, incluso en aquellas que parecían perpetuarse. Nuestro país no es un caso aislado a los demás. Uno de los objetivos primarios del comercio electrónico es la contribución al aumento de la capacidad competitiva en el mercado, mediante el fortalecimiento del mercado, de los clientes del negocio, también tiene como objetivo en muchos de los casos, ampliar el mercado del negocio a un nivel interregional e internacional si es posible. Para ello el comercio electrónico tendrá implicaciones que afecten a otros (empresas, proveedores, clientes). Así que ante este nuevo entorno, las empresas buscarán calidad y menor precio, y si en su actual red comercial de distribución no satisfacen estos factores, debe pensarse en el rediseño de la misma o en prescindir de ella. Este tipo de cambios dramáticos no ha sido únicamente característico de esta era digital, también ha sucedido en otras etapas del desarrollo tecnológico de la comunicación. Una nueva tecnología siempre cambia la manera de actuar de las sociedades. El trabajo cotidiano, la educación, la política, el comercio, y en general la forma de desenvolvimiento de las organizaciones se transforma con la introducción de una tecnología. De acuerdo a Neil Postman25, Internet podría definirse como una tecnología similar a la televisión o a la radio, considerando su formidable capacidad para introducir e imponer profundos cambios culturales, los cuales repercuten en distintas dimensiones de las organizaciones sociales. Según la Organización Mundial de Comercio, las tecnologías de Internet ofrecen a los países en desarrollo grandes oportunidades para obtener información que antes era inaccesible para ellos. La transferencia de conocimientos resultante puede estimular el crecimiento de esos países y contribuir a su integración en los mercados mundiales. El crecimiento de Internet y el comercio electrónico ha sido, cuando menos, meteórico, y este ritmo vertiginoso no parece decaer. Nuevos elementos y estimaciones en los medios de información y otras publicaciones, sobre todo en los tres últimos años, explican las razones de ese auge. Como observación de carácter general, las múltiples previsiones que se han hecho de ese fenómeno en crecimiento se han puesto una y otra vez en tela de juicio, en respuesta a una tendencia (que ahora está desapareciendo) a subestimar la expansión de ese fenómeno. Los avances tecnológicos de la computación y las comunicaciones por Internet han ido evolucionando las actividades de las personas, así como la forma de hacer negocios. Internet se ha consolidado como la plataforma ideal para el desarrollo de pequeñas y grandes empresas, al permitir la globalización de productos y servicios. El comercio 25 CHERNIAK, 1998 26 también se ha visto beneficiado con estos avances, con el llamado e-commerce o comercio electrónico. El e-commerce (Comercio Electrónico) es la compra y venta de bienes y servicios través de Internet. Podríamos decir que el e-commerce está estructurado por "Tiendas virtuales" en sitios Web que ofrecen catálogos en línea. Incluso se han creado "Centros comerciales virtuales" con gran cantidad de tiendas con todo tipo de accesorios para la venta. Esta forma de comercio electrónico ha consolidado a grandes empresas que ya figuran en la bolsa de valores y son de los portales de Internet más visitados. Cuando se habla de transacciones comerciales se distinguen claramente los distintos roles de una transacción. Los compradores que desean cierto bien o servicio, por otra parte los vendedores, que son aquellos interesados en ofrecer sus productos, el mercado o lugar físico donde se realiza la transacción, el dinero o medio de pago y por último el producto o servicio a comercializar. En el e-commerce también se pueden distinguir ciertos actores o elementos además de los anteriores: • Un producto o servicio, el que puede ser virtual o real • El lugar físico es ahora reemplazado por un sitio Web abierto las 24Hs. • Compradores que son los navegantes de la tienda virtual • Vendedores que operan a través de la tienda virtual • Una cuenta comercial con un Banco para hacer efectivas las transacciones por lo general a través de la validación de tarjetas de crédito • Un sistema de distribución de los productos • Un sistema de atención al cliente, vía mail, Internet, Chat, etc. 27 2. DESCRIPCION DEL PROYECTO A continuación veremos una breve descripción general del proyecto con el fin de ubicarnos, y poder hacer un mejor seguimiento de las partes que lo componen. El proyecto de investigación se dividirá en 3 etapas: • Investigación Desarrollo Adaptable de Software y desarrollo de Framework • Desarrollo de Framework utilizando DAS • Desarrollo de Aplicación Venta DVD utilizando el Framework y DAS La primera etapa de la investigación comenzó después de entregada la propuesta y se continuó a medida que el proyecto avanzaba, ya que la información relacionada con estos temas es muy nueva y surgía constantemente. La segunda etapa consistió en la construcción de un Framework para el desarrollo de aplicaciones e-commerce, para la venta o alquiler de bienes materiales, a consumidores individuales. La tercera etapa consiste en el desarrollo e implantación de una aplicación específica de e-commerce, utilizando el Framework elaborado en la etapa anterior. Esta aplicación estará orientada a la venta y alquiler de DVDs, todo esto se hará basado en la metodología Desarrollo Adaptable de Software. De acuerdo a los resultados obtenidos en cuanto a tiempo de desarrollo, calidad del software, dificultades, ventajas y desventajas del DAS para este tipo de aplicaciones, se podrá obtener una aplicación tangible de ecommerce la cual podrá ser utilizada en el mercado colombiano, incluyendo el desarrollo del Framework el cual podrá ser usado para el desarrollo de otro tipo de aplicaciones ecommerce diferente a la desarrollada por nosotros. Para la construcción del Framework, nos basaremos en la metodología del desarrollo adaptable de software. La implementación del mismo tendrá 3 etapas generales, la especulación en la cual se realiza el análisis y el diseño, la colaboración la cual cubre el desarrollo componentes (diseño del Framework, y la instanciación del mismo), y por último el aprendizaje el cual se refiere al control de calidad y la entrega final del Framework. Estas 3 actividades se llevaron a cabo de manera iterativa, pero no necesariamente lineal, se realizaron 6 ciclos (el número de ciclos es el aconsejado por James Highsmith en su libro “Adaptive Software Development” de acuerdo a la duración del proyecto), hasta obtener el producto final acorde a los requerimientos establecidos. 28 3. DESARROLLO ADAPTABLE DE SOFTWARE Se investigaron las empresas de desarrollo de software colombianas, con el fin de conocer si alguna trabajaba o había trabajado con el desarrollo adaptable de software en alguno de sus procesos de desarrollo, para esto se seleccionaron 8 empresas al azar estas empresas se nombran a continuación • Incubeit En esta compañía se utiliza una metodología de cascada, no se utiliza ni se conoce nada sobre DAS • Asesoftware Se utiliza la metodología RUP, no se utiliza ni se conoce nada sobre DAS • Bisa Corporation Se utiliza UML, bajo un estándar propio de la compañía, no se utiliza ni se conoce nada sobre DAS • DataSixx Se utiliza una metodología propia basada en SAP Blueprint no se utiliza ni se conoce nada sobre DAS • Heinsohn Se utiliza UML, bajo un estándar propio de la compañía, no se utiliza ni se conoce nada sobre DAS • EDS Se utiliza RUP y se están realizando investigaciones para la utilización de XP (Programación extrema), no se utiliza DAS • CSI- Complex Systems Inc. Se utiliza una metodología propia de la compañía, no se utiliza ni se conoce nada sobre DAS • Alpha GL Se utiliza UML, bajo un estándar propio, no se utiliza ni se conoce nada sobre DAS • Sybase No se conoce nada sobre DAS, en cuanto a la metodología utilizada la información no fue suministrada 29 • TinySoft No se conoce nada sobre DAS, en cuanto a la metodología utilizada la información no fue suministrada De acuerdo a la información ninguna de las 10 empresas seleccionadas había trabajado ni conocía el desarrollo adaptable de software. En conclusión son muy pocas las empresas las cuales utilizan metodologías de desarrollo ágil de software. A continuación veremos el proceso de desarrollo adaptable de software que se utilizó en la realización del framework. • 1 Ciclo Para el Plan de Ciclos de desarrollo adaptable se realizaron 7 iteraciones en total. o Primera iteración 15/08/2004 Corresponde a la especulación, se definieron el número de ciclos que se realizarían y sus correspondientes actividades, esta información era tentativa, ya que se tenía muy poco conocimiento e información del desarrollo del Framework en general. o Segunda iteración 20/08/2004 A medida que se obtuvo más información acerca del desarrollo del Framework, Se replantearon los ciclos que debían llevarse acabo, en consecuencia se cambiaron el nombre, actividades y objetivos de los ciclos 2, 3, 4, 5, 6. Al redefinirse los ciclos, las actividades y el cronograma cambiaron acorde al documento Gracias al DAS estos cambios no causaron ningún trauma en el desarrollo del proyecto. o Tercera iteración 21/08/2004 Se encontró un problema en las actividades a realizarse en el ciclo 3, ya que estas no estaban bien definidas. o Cuarta iteración 15/10/2004 Debido a cambios en el análisis y el diseño del Framework, se cambiaron algunos componentes de los ciclos de implementación, se realizó la correspondiente corrección de la lista de actividades y el cronograma. Se redefinió el ciclo 6, igual que sus objetivos y componentes. o Quinta iteración 16/10/2004 Se corrigieron algunas actividades y componentes de los ciclos de análisis, diseño e implementación. o Sexta iteración 18/10/2004 Corrección de algunas de las actividades y componentes de los ciclos de implementación. 30 o Séptima iteración 28/03/2005 De acuerdo a la recomendación del comité de investigación se cambió el término e-business por e-commerce • 2 Ciclo Para el ciclo de Análisis se realizaron 8 iteraciones. o Primera iteración 24/09/2004 Se realizó una primera versión del documento (borrador) propuesto en el 1 ciclo o Segunda iteración 28/09/2004 Se complemento el documento de análisis, se agregaron diagramas de casos de uso y su correspondiente documentación o Tercera iteración 02/10/2004 Se corrigió la documentación de los casos de uso y se cambio el tiempo de respuesta o Cuarta iteración 04/10/2004 Se agregaron comentarios referentes al desarrollo del Framework, se corrigió documentación de los casos de uso o Quinta iteración 10/10/2004 Se agregaron casos de uso, y se realizó una identificación de objetos inicial, con su correspondiente diagrama de dominio o Sexta iteración 11/10/2004 Se corrigieron errores en la documentación o Séptima iteración 30/10/2004 Se corrigieron los requerimientos del sistema de acuerdo a la implementación, además se agregaron casos de uso y su correspondiente documentación o Octava iteración 28/03/2005 De acuerdo a la recomendación del comité de investigación se cambió el término e-business por e-commerce. • 3 Ciclo Para el ciclo de Diseño se realizaron 11 iteraciones. o Primera iteración 26/10/2004 31 Se realizó una primera versión del documento (borrador) propuesto en el 1 ciclo o Segunda iteración 28/10/2004 Se completo la descomposición por entidades o Tercera iteración 31/10/2004 Se agregaron más entidades, y una descripción de componentes J2EE o Cuarta iteración 10/11/2004 Se agrego el modelo de datos y su documentación, se corrigieron algunos errores en la arquitectura o Quinta iteración 11/11/2004 Se corrigió el modelo de datos o Sexta iteración 20/11/2004 Se agregaron componentes J2EE (SessionsEJB y EntitiesEJB) y Patrones de Software a la arquitectura o Séptima iteración 23/11/2004 Se agregó un ejemplo de creación de tablas (script) de acuerdo al modelo de datos, se agregaron diagrama de clases de los componentes J2EE y diagrama de clases o Octava iteración 24/11/2004 Se corrigió el modelo de datos o Novena iteración 26/11/2004 Se cambio el diagrama de arquitectura, y cambio el diagrama de componentes J2EE o Décima iteración 27/11/2004 Se mejoro la descripción de la arquitectura, y algunos diagramas de componentes, se corrigió el modelo de datos o Undécima iteración 28/03/2005 De acuerdo a la recomendación del comité de investigación se cambió el término e-business por e-commerce. • 4 Ciclo Para el ciclo de Implementación I se realizaron 8 iteraciones. o Primera iteración 16/11/2004 Se implementaron las clases correspondientes a la lógica del negocio, la clase ProductoCreator(Factory) y la clase Service Locator 32 o Segunda iteración 18/11/2004 Se corrigieron errores de configuración del Service Locator o Tercera iteración 22/11/2004 Se corrigieron errores de conectividad del Service Locator o Cuarta iteración 26/11/2004 Se implementaron los Session EJB y las bases de datos o Quinta iteración 10/12/2004 Se corrigieron errores en la conectividad de los Session Bean, se modificaron algunas tablas de la base de datos de acuerdo a cambios en el diseño o Sexta iteración 15/12/2004 Se corrigieron problemas en la funcionalidad de los Session Bean o Séptima iteración 20/012005 Se modificaron algunos atributos de las tablas debido a desbordamiento de información o Octava iteración 31/01/2005 Se realizaron ajustes de acuerdo a las pruebas realizadas. • 5 Ciclo Para el ciclo de Implementación II se realizaron 6 iteraciones. o Primera iteración 28/11/2004 Se implementaron las clases DAO, los Entities CMP y la clase Business Delegate o Segunda iteración 3/12/2004 Se corrigieron errores de conectividad y consultas en los DAO o Tercera iteración 10/12/2004 Se corrigieron errores en la transaccionalidad de los CMP o Cuarta iteración 15/12/2004 Se agregaron métodos a la clase Business Delegate o Quinta iteración 07/01/2005 Se integraron todos los componentes del Framework y la lógica del negocio o Sexta iteración 31/01/2005 Se realizaron ajustes de acuerdo a las pruebas realizadas. 33 • 6 Ciclo Para el ciclo de Pruebas se realizaron 5 iteraciones. o Primera iteración 08/01/2005 Se realizó una primera versión del documento (borrador) propuesto en el 1 ciclo o Segunda iteración 22/01/2005 Se realizaron el manual de usuario y el manual de instalación y configuración o Tercera iteración 25/01/2005 Se realizó la guía de extensión del Framework o Cuarta iteración 30/01/2005 Se cambio la estructura de algunas pruebas o Quinta iteración 15/02/2005 Se corrigieron errores en los manuales y la guía del Framework Estas iteraciones fueron realizadas de una manera no lineal y se basaron en el aprendizaje de la iteración previa. Además los ciclos y sus actividades se fueron modificando de acuerdo al avance del proyecto. 34 4. DESARROLLO DEL FRAMEWORK Como se dijo anteriormente la 1 etapa se baso en investigación, ahora describiremos mas detalladamente las siguientes 2 etapas. La segunda etapa de nuestro proyecto como ya se dijo consistió en la construcción de un Framework para el desarrollo de aplicaciones e-commerce, para la venta de bienes materiales, a consumidores individuales. Aplicando la metodología ágil DAS, se definieron el número de ciclos que tendría el desarrollo del Framework. Se realizaron 6 ciclos - el número de ciclos aconsejado por James Highsmith26 - de acuerdo a la duración del proyecto, hasta obtener el producto final acorde a los requerimientos establecidos. 4.1. PLAN DE CICLOS DE DESARROLLO ADAPTABLE Una vez definido el número de ciclos, se realizó el plan de ciclos de desarrollo adaptable (ver Anexo A Plan de Ciclos de Desarrollo Adaptable Framework), aquí se siguieron los siguientes pasos27, se definió una misión ya que el ciclo de vida del desarrollo adaptable, debe estar enfocado en esta, después se definieron los marcos de tiempo de cada ciclo de trabajo lo cual dependió de los componentes que se desarrollarían en cada uno de ellos. Se definió un objetivo para cada uno de los ciclos, y un entregable para cada uno de ellos, de igual manera se definieron las herramientas tecnológicas que se usarían y cada uno de los componentes que se desarrollaría en cada uno de los ciclos, por último se definió una lista de actividades que cubriría todo el proyecto. Para finalizar el documento se definió un cronograma tentativo para cada una de las actividades. Este plan de desarrollo de ciclos fue sometido a varias revisiones, ya que el desarrollo adaptable de software se desarrolla de una forma iterativa, esto nos ayudo a controlar los cambios que fueron surgiendo en el proyecto, en este caso surgieron varios cambios debido al poco conocimiento que se tenia sobre el tema al iniciar el proyecto. El desarrollo adaptable de software permite seleccionar cualquier estándar para el desarrollo de las aplicaciones, ya que se enfoca en la administración de software, y no en una metodología de desarrollo específica. Para la documentación nos basamos en los estándares de la IEEE, y se manejo un control de versiones para cada uno de ellos. Después de definido y aprobado el plan de ciclos de desarrollo adaptable, empezaron los ciclos y las actividades definidas allí. 26 27 James Highsmith, Adaptive Software Development, 2000 James Highsmith, Adaptive Software Development, 2000 35 4.2. ANALISIS Primero se empezó con el ciclo de análisis de la aplicación, este ciclo nos plantea las siguientes actividades: • Definir el dominio del Framework: Esta actividad es muy importante, ya que aquí se definió el alcance a nivel funcional que tendrá nuestro Framework, además este factor es de vital importancia para el éxito del desarrollo ya que es imposible intentar cubrir todos los requerimientos de todas las aplicaciones en todos los dominios28. • Análisis de Requerimientos: Después de observar varias tiendas de comercio electrónico, en Latinoamérica y en el mundo (DeRemate.com, ebay, exitovirtual.com, TowerRecords, Amazon) se sacó una lista preliminar de requerimientos de acuerdo a la funcionalidad y transaccionalidad que manejan en común estas tiendas. Esta lista se fue refinando, a medida que avanzaba el proyecto. Los requerimientos obtenidos fueron los siguientes: o Agregar o eliminar productos del carro de compras o Agregar o modificar productos del sistema o Agregar Tipos de Tarjeta o Consultar detalle orden de compra o Consultar Inventario de productos o Consultar ordenes de compra o Consultar productos o Consultar clientes o Desactivar clientes no deseados o Generar una orden de compra o Modificar el stock de productos del inventario (Agregar o Disminuir) o Modificar información del cliente o Registrar la fecha de backup de la información o Registrar una orden de compra enviada o Registrar usuarios en el sistema o Seleccionar forma de pago o Validación y autenticación de usuarios o Ver los detalles del producto o Manejar Carro de Compras o El tiempo de respuesta deberá ser menor a 7 segundos o El tiempo de disponibilidad de la base de datos deberá ser de un 90% anual. o Deberá soportar hasta 1000 clientes al mismo tiempo. o El sistema deberá ser seguro, confiable y protegido. Después de esto se identificaron los actores del sistema, estos fueron el administrador y el cliente. 28 Carey, James and Carlson, Brent. Framework Process Patterns. 2002 36 • Diagrama de Casos de Uso En este punto se definieron los casos de uso de la aplicación en su primera versión de acuerdo a los requerimientos obtenidos, y se documentaron de acuerdo a la plantilla de Alistair Cockburn.29. Ilustración 2. Diagrama de Casos de Uso del Framework 29 http://alistair.cockburn.us 37 Para una información mas detallada acerca del análisis del Framework (Ver Anexo B Análisis Framework). Con esto se finalizo el segundo ciclo, del desarrollo del Framework, este ciclo fue revisado y corregido a medida que se fueron implementando los otros ciclos. 4.3. DISEÑO El tercer ciclo de la aplicación, se dedicó al diseño de Framework, en esta etapa se definió el modelo de datos que se usaría, la arquitectura del sistema, y los diagramas de clases correspondientes a la aplicación. Las actividades que se llevaron a cabo en este ciclo son las siguientes: • Definición Modelo de Datos: De acuerdo a los requerimientos definidos en el ciclo de análisis se diseño un modelo de datos para la aplicación, en este se especificaron las entidades y sus correspondientes relaciones. El modelo de datos puede verse a continuación. Ilustración 3. Modelo de Datos del Framework 38 • Arquitectura del Framework: Para este desarrollo utilizaremos una arquitectura J2EE, se escogió este tipo debido a que es una de las arquitecturas mas utilizadas para el desarrollo de aplicaciones empresariales de e-commerce. Esta arquitectura nos provee: o Un modelo de desarrollo de aplicaciones basado en componentes o Un modelo de desarrollo de aplicaciones distribuidas basado en múltiple capas y multired. o Esta constituido por un conjunto de tecnologías estándar, Servlets, EJB, JSP etc. De acuerdo con esto tendríamos la siguiente arquitectura (Ilustración 4): Ilustración 4. Diagrama de Arquitectura del Framework En este diagrama tenemos que nuestro cliente accedería al sistema por medio de el Business Delegate para obtener la lógica del negocio del sistema, esto puede ser mediante interfaces graficas, JSP dependiendo de las necesidades del cliente, es decir nos da acceso a los servicios del negocio, este a su vez hace una petición al ServiceLocator el cual es el encargado de ubicar los servicios, este realiza la conexión con la tienda (SessionEJB), Tienda es de tipo Stateless y Carro de compras StateFul, debido a que necesitamos que este guarde su estado dependiendo de la sesión (cliente), es decir necesitamos que los productos que 39 estén en el carro de algún cliente se mantengan si se presenta algún problema en la sesión (error de conexión), estos productos se eliminarán una vez el cliente haya terminado su sesión. A su vez el Session Tienda se comunica con un Session Cliente y un Session administrador dependiendo la clase de usuario, estos dos Session a su vez se comunican y administran los Entities Cliente, Administrador, Tarjeta, Orden de compra y ProductoFisico, encargados de la comunicación con la Base de Datos. El producto depende del tipo de producto que se quiera vender, es decir es configurable según las necesidades del cliente. Además dependiendo del servicio que se necesite la tienda puede acceder a la base de datos mediante un DAO, el cual es el encargado de realizar consultas, y/o peticiones (Querys) que no pueden hacer los EntitiesEJB. En el caso del Framework este producto es configurable, además que no tiene que ser solo uno pueden ser varios, por lo cual el usuario debe implementar tantos BMP EntitiesEJB como productos desee vender en su tienda, todo esto depende de las necesidades del usuario. De la misma forma la Base de datos que se vaya usar también es configurable por parte del cliente según el motor de Base de Datos que se vaya a utilizar, como Oracle, SQL Server, Point Base etc. También es necesario que al utilizar el Framework se defina y utilice un Servidor de Aplicaciones (Application Server) acorde a las necesidades del usuario, tales como JBoss, Sun One Application Server, Websphere etc. En cada uno de estos debe configurarse una fuente de datos (DataSource), un correspondiente Pool de conexiones (Connection Pool) y un administrador de persistencia (Persistence Manager), con el fin de que la aplicación pueda acceder a la Base de Datos. Además de esto el servidor de aplicaciones esta encargado de realizar el Despliegue (‘deploy’) de la aplicación. El Framework cuenta con una clase, NombreReferencia, la cual nos permite configurar los JNDI Names, de la aplicación. • Patrones: Con el fin de fortalecer el diseño y la implementación de la aplicación, se seleccionó una serie de patrones acorde al desarrollo del Framework. Dentro de estos patrones se encuentran: o Business Delegate Para la aplicación se utilizó una clase Business Delegate30 la cual es la encargada de proporcionar el acceso a la lógica del negocio, esta a su vez es la encargada de comunicarse con el Session tienda. El cliente utiliza a esta clase para acceder a todos los métodos de la lógica del negocio. 30 Patrón de Diseño de Software, Larman, Craig. Applying UML and patterns: An introduction to objectoriented analysis and design. 1998. 40 o Service Locator Es el encargado de realizar las conexiones entre los Beans, la base de datos, Data Source, y demás componentes que requieran un servicio. o Data Access Object (DAO) Estas son varias clases ya que se implementa de acuerdo a las tablas a las cuales se va a acceder. Son los encargados de realizar las consultas y Querys, las cuales no puedan ser manejadas por los Entity Beans. o Factory (ProductoCreator) Esta clase permite crear varias clases de productos específicos a través de la herencia de la clase producto. Para este, las clases de productos específicos que se vayan a crear deben extender de la clase producto, la cual maneja unos atributos y métodos generales de los productos. • Módulos: El sistema se dividió en 4 módulos de acuerdo a su funcionalidad, la interfaz cliente, la interfaz administrador, la tienda, y el carro de compras, correspondientes a ClienteMgr Bean, AdministradorMgr Bean, TiendaMgr Bean y KartMgr Bean respectivamente. • Diagrama de Clases: Para el diseño de las clases se siguió la metodología propuesta por Bernd Bruegge en su libro Ingeniería de Software Orientada a Objetos31, la cual nos dice que deben definirse unas entidades correspondientes a la aplicación y de acuerdo a las entidades definidas, se construyó un diagrama de clase que podemos ver en el disco anexo en la carpeta de gráficos. Para una explicación mas detallada del ciclo de diseño (Ver Anexo C Diseño Framework). 4.4. IMPLEMENTACION I El cuarto ciclo de la aplicación se dedicó a la implementación de la arquitectura y las clases definidas en la fase de diseño. Como primera actividad se definió la implementación de las clases, correspondientes a las entidades de la aplicación, a continuación se definen las clases y los métodos que se implementaron. 31 BRUEGGE Bernd y DUTOIT Allen, Ingeniería de Software Orientada a Objetos, Capitulo 6. 41 Ilustración 5. Clases Producto, BackupAdmin, Cliente y Administrador. Estas clases se implementaron de acuerdo a los objetos identificados en el análisis y el diseño, están la clase producto la cual es la encargada de manejar la información referente a los productos a vender en la tienda, la clase cliente y administrador manejan la respectiva clase de usuario, y el BackupAdmin, en la cual se guardan los registros de la realización de Backup del sistema. 42 Ilustración 6. Clases TipoTarjeta, OrdenCompra, Tarjeta Credito y Producto Fisisco Se implementaron de igual forma la clase tipo tarjeta la cual nos indica el tipo de las tarjetas (visa, diners, american, etc.), la clase orden de compra para el manejo de estas, y la clase producto físico la cual hace referencia al producto físico en sí (inventario). Después de las clases se implementaron, el patrón Factory y el Service Locator 43 Ilustración 7. Clases Service Locator y Factory El patrón Factory nos permite manejar la creación de productos, cuando se quiera agregar un producto esta clase debe modificarse. El Service Locator es una clase la cual solo puede instanciarse una vez (patrón Singleton), la cual esta encargada de localizar los servicios y componentes de la aplicación (“lookup”) Seguimos con la implementación de los Session Beans, Un Session EJB permite realizar cierta lógica solicitada por un cliente ya sea un JSP|Servlet, Applet e inclusive otro EJB. Existen dos tipos de Session EJB's: • Stateless (Session) EJB's Este tipo de EJB como su nombre lo indica no mantiene estado ("Stateless") en el "EJB Container", estos EJB's son utilizados para realizar tareas rutinarias que no requieren identificar o rastrear al cliente, algunos EJB's de este tipo son: operaciones matemáticas complejas, búsquedas generales, etc. • StateFul (Session) EJB's A diferencia de "Stateless (Session) EJB's" este tipo de EJB's permiten mantener la sesión del cliente en el "EJB Container", de esta manera el cliente puede trabajar con cierto juego de datos específico administrado por el "EJB Container", la aplicación ideal para este tipo 44 de EJB es un componente de compra ("Shopping Cart") el cual puede identificar artículos e información personal del cliente a través de un lapso de tiempo extenso ("Session"). A continuación veremos los Session EJB, que se implementaron en el desarrollo del Framework. Ilustración 8. ClienteMgr Session EJB El clienteMgr es el encargado de manejar todas las transacciones requeridas por el cliente y de administrar el carro de compras de cada uno de ellos 45 Ilustración 9. AdministradorMgr Session EJB. 46 Ilustración 10. TiendaMgr Session EJB 47 La clase TiendaMgr es la encargada de manejar todas las transacciones de la tienda, tanto las del cliente como las del administrador, es la fachada del sistema, ya que a esta se le hacen todas las peticiones. Ilustración 11. EntidadFinancieraMgr y KartMgr SessionsEJB El KartMgr es el encargado de manejar las transacciones correspondientes al carro de compras y el EntidadFinancieraMgr es el encargado de manejar la validación local de las tarjetas. Este es el encargado de comunicarse con la aplicación seleccionada para el manejo de los pagos. Estos Session EJB (Ilustración 9, 10, 11, 12) fueron los definidos para el Framework. Después de la implementación de los Session, se generó un script para la creación del modelo de datos, este script se realizó para la especificación Ansi Sql 92. Para ver de forma más detallada el script y la información de las clases (ver Anexo C Diseño Framework o referirse al código adjunto). 48 4.5. IMPLEMENTACION II En el 5 ciclo se terminaron los componentes que faltaban en la aplicación. Se escribieron los DAO, los EJB Entity CMP y EJB Entity BMP y por último el “Business Delegate” pagina 47, después se hizo la integración de todo el Framework. Los DAO son los encargados de realizar las conexiones a la Base de Datos, de una forma transparente. (Ilustración 13). Ilustración 12. Clases DAO's Se realizó un DAO para cada una de las tablas que fueron utilizadas, cada uno de los DAO tiene sus correspondientes métodos los cuales son los encargados de realizar las consultas, las inserciones y las actualizaciones respectivas. 49 Ilustración 13. EJB EntitiesEJB CMP'S 50 Cada uno de estos CMP (Ilustración 14, 15), esta encargado de manejar la persistencia de la información correspondiente, por ejemplo el CMPClienteBean esta encargado de los datos específicos del cliente Ilustración 14. EJB EntitiesEJB CMP Entity BMP El Entity BMP no se implementó ya que esta clase de Entity depende de los productos que quiera vender el cliente, es decir se debe implementar un Entity BMP para cada uno de los productos que se deseen vender en la tienda, en este bean deben implementarse los correspondientes métodos para obtener acceso a los atributos del producto, además debe implementarse un método del negocio (“business method”) que sirva para modificar el producto y un buscador (“finder”) el cual devuelva el Entity BMP de acuerdo a la llave primaria buscada. 51 Este o estos EntitiesEJB (de acuerdo a las necesidades del cliente), permitirán manejar la información referente a los productos específicos que ofrecerá el cliente. En cada uno de los Entibies BMP que se creen se deben declarar 3 atributos obligatoriamente, el Id. del Producto, el nombre y su correspondiente precio, esto debido a que son características fundamentales que debe tener todo producto. Además las distintas características específicas del producto deben agregarse como atributos al BMP, los atributos que se agreguen son opcionales y dependen de la decisión del usuario. 52 Ilustración 15. Clase Bussines Delegate 53 Por último se implementó la clase Business Delegate de acuerdo con lo descrito en la pagina 47. Para información mas detallada acerca de las clases (ver anexo C Diseño Framework o código adjunto). En este ciclo terminó la implementación de nuestro Framework. 4.6. PRUEBAS Y DOCUMENTACION En el sexto y último ciclo se desarrollaron las pruebas específicas para la aplicación y se definió la documentación que se realizaría. 4.6.1. Pruebas Para el desarrollo de las pruebas se definió un plan de pruebas, de acuerdo al estándar IEEE32, se realizaron pruebas de caja negra a todas las funciones del Framework. Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo internamente. Las funciones referentes al producto no fueron probadas, ya que su implementación depende del cliente. Para las pruebas se definieron, un objetivo y un alcance con el fin de delimitar, las pruebas que se realizarían. Después se seleccionaron los procedimientos a ser probados en cada uno de los módulos, se definieron casos de prueba para cada uno de los procedimientos a probar. Se realizaron pruebas de conectividad, pruebas al modulo cliente y pruebas al modulo administrador. Para todas las pruebas fueron definidos criterios de Aprobación y Fallo. Para obtener información detallada del desarrollo de las pruebas (ver Anexo D Pruebas Framework). 4.6.2. Documentación Para la documentación de la aplicación además de los entregables de cada uno de los ciclos se definieron tres guías o manuales33: • 32 33 Manual de Usuario Framework. IEEE standard for software test documentation Carey, James and Carlson, Brent. Framework Process Patterns. 2002 Pág. 202 54 Con este manual nos aproximamos al Framework desde una perspectiva de domino, para que los usuarios obtengan un mayor entendimiento del Framework, con lo cual puedan llegar a usarlo para el desarrollo de sus aplicaciones. Esta manual contiene una descripción general de las funciones que nos provee el Framework y una pequeña descripción de su funcionalidad. • Manual de Instalación y Configuración Framework. Este manual es una guía en la cual se puede observar detalladamente el proceso de instalación y configuración de varios de los componentes utilizados en el Framework. Esta guía se dividió en tres partes ya que son tres los componentes principales a instalar, en cada una de estas se explica detalladamente la instalación y configuración de sus componentes. • • • Base de Datos Servidor de Aplicaciones Aplicación En este manual se encuentran ejemplos con un software específico, de igual manera se dan las pautas generales para que el usuario pueda trabajar en otros programas. • Guía de Extensión Framework. Este manual es una guía en la cual se puede observar detalladamente el proceso de extensión del Framework, con el fin que el usuario, pueda implementar sus propias aplicaciones basándose en la tecnología usada en el Framework, su documentación, implementación y arquitectura. En esta guía el usuario encontrara la forma de implementar, paso a paso, sus propios productos para la venta en la tienda virtual. Para obtener información detallada acerca de los manuales (ver Anexos E, F, G). 55 5. DESARROLLO DE LA APLICACIÓN PARA LA VENTA DE DVD La tercera etapa como se explicó en la descripción del proyecto consistió en el desarrollo de una aplicación para la venta de DVDs, para el desarrollo de esta se utilizó el Framework construido en la segunda etapa del proyecto, extendiendo de su documentación y funcionalidad, para esta aplicación también se aplicó la metodología DAS. El producto elegido, en este caso películas DVD, se seleccionó debido a la gran acogida que tiene este producto a nivel comercial. Se decidió tomar este producto a gusto propio y aprobado por el director de proyecto, quien a su vez le pareció una muy buena elección. Como en la etapa anterior se definió el número de ciclos que se utilizarían para desarrollar la aplicación, al igual que en el Framework, se definieron seis ciclos debido a que el tiempo de ejecución del proyecto era el mismo. 5.1. PLAN DE CICLOS DE DESARROLLO ADAPTABLE Al igual que en el Framework, al definir el número de ciclos se prosiguió a realizar el plan de ciclos de desarrollo adaptable (ver Anexo H Plan de Ciclos de Desarrollo Adaptable Aplicación DVD), de la misma forma que en el plan de ciclos del Framework, se definió una misión para el proyecto, además se definieron los marcos de tiempo, los objetivos, entregables y actividades que se realizaría en cada uno de los ciclos. Los ciclos prácticamente son los mismos, pero al utilizar el Framework se variaron las actividades de cada uno de ellos, ya que muchos de los componentes necesarios para la aplicación los provee el Framework. El desarrollo de este plan fue más sencillo ya que se uso el Framework como base. Al igual que en el Framework todos los entregables se basaron en estándares IEEE34 y se manejo un control de versiones en cada uno de ellos. 5.2. ANALISIS En este ciclo se definió un dominio de la aplicación, unos requerimientos y unos casos de uso. El dominio que se selecciono es el de una aplicación e-commerce que basada en la venta de películas de DVD35 por Internet, la cual maneja registro de usuarios, inventario, órdenes de compra (ventas), detalles del producto y registro de envíos. Después de esto se definieron los requerimientos correspondientes. Como primera medida se tiene que esta aplicación de venta de películas en DVD, se basa en el uso del Framework para aplicaciones e-commerce. Los requerimientos funcionales 34 35 Los estándares IEEE utilizados se pueden consultar en la Bibliografía Disco de video digital 56 abarcan toda la parte que el Framework cubre (ver Anexo B Análisis Framework). A su vez para esta aplicación nacen estos requerimientos presentados a continuación: • • • • • Agregar o modificar películas DVD del sistema Consultar Inventario de películas DVD Consultar películas DVD Modificar el stock de películas DVD del inventario (Agregar o Disminuir) Ver los detalles de las películas DVD Ilustración 16. Diagrama Casos de Uso Aplicación DVD Como se explicó esta aplicación extiende del Framework por lo cual solo se muestran los casos de uso pertenecientes a la aplicación. Para ver información detallada sobre el ciclo de análisis (ver Anexo H Análisis Aplicación DVD). 5.3. DISEÑO Para elaborar el diseño de la Aplicación de DVD se utilizó el modelo de datos definido en el Framework, ya que este nos provee la información requerida para nuestra aplicación, la única modificación que se realizó a este modelo fue la agregación de una tabla DVD, ya que este será el producto específico a vender en la aplicación, esto podemos verlo en el modelo descrito a continuación. 57 Ilustración 17. Modelo de Datos Aplicación DVD Utilizamos la arquitectura propuesta en el Framework, para la capa de presentación, se utilizaron Servlets y JSP y a una de las capas de interacción se le agregara un BMPDVDProducto. De acuerdo con este modelo se tiene la siguiente arquitectura: 58 Interacción Presentación * Logica del Negocio Interacción EIS * * * DAO * JSP * * * * Service Locator * CMPBackUp Session Administrador «uses» Servlets * * * * * Business Delegate * * *** * CMPTipoTarjeta * Session Tienda * * * * * Data CMPProductoFisico * ** * * Session Cliente Cliente ** * * * CMPOrdenCompra * * * ** * * * CMPCliente SessionKart * * * BMPDvdProducto * * * * * * Ilustración 18. Diagrama de Arquitectura Aplicación DVD En este diagrama tenemos que nuestro cliente accederá al sistema por medio de Internet y los JSP, estos se comunican con los Servlets los cuales utilizan el Business Delegate para obtener la lógica del negocio del sistema, además se agregara un Entity BMP llamado BMPDVDProducto, el cual se encarga de la comunicación y el manejo de la información con la tabla DVD y la tabla producto respectivamente. A los componentes se les agregaron y/o modificaron algunas funciones de acuerdo a los requerimientos de la aplicación (solamente se muestran las clases que tendrán algún cambio). Se agrego la clase BMPDVDProducto, la cual nos representa el producto que se venderá en la tienda virtual. Se utilizaron los patrones definidos en el Framework, y se realizaron las respectivas modificaciones de acuerdo a la configuración de la aplicación Para ver información detallada sobre el ciclo de diseño (ver Anexo H Diseño Aplicación DVD). 5.4. IMPLEMENTACION I En esta fase se implementaron y reutilizaron, las clases y los EJB de la aplicación modificándolos si era necesario. Se creó la clase DVD que extiende de producto y se modificaron el producto creador, el Service Locator. 59 Ilustración 19. Clase DVD y ProductoCreator Además se modificaron los Session EJB y la base de datos según el modelo de datos. Para ver más detalladamente estas modificaciones, (ver código de la Aplicación Adjunto). 5.5. IMPLEMENTACION II En este ciclo se modificaron los DAO’s y el Business Delegate, se implementó el BMP y los Servlets y JSP’s. Ilustración 20. Clase DAOProductos Aplicación DVD 60 Se creó una clase DAOProductos, ya que era necesario manejar las transacciones a la base de datos, como se explicó anteriormente se utilizó un patrón DAO para esto, además se le agregaron los métodos necesarios a los demás DAO’s y al Business Delegate, para completar la funcionalidad de la aplicación desarrollada, específicamente la que corresponde a los productos. 61 Ilustración 21. BMPDVDProducto Aplicación DVD 62 En este Entity CMP (Ilustración 23) se declararon los 3 atributos obligatorios detallados en el diseño del Framework, el Id. del Producto, el nombre y su correspondiente precio, Además de los atributos específicos del producto. En este bean también se debe implementar una función constructora (create) y un buscador (finder) con el fin de encontrar y cargar los correspondientes productos. 63 Ilustración 22. Clase BusinessDelegate Aplicación DVD 64 Ilustración 23. Clase Servlet Aplicación DVD Se creó una clase ServletDvd, la cual es la encargada de manejar las peticiones y respuestas vía Internet Para más detalles sobre la implementación (ver el código de la aplicación adjunto). 5.6. PRUEBAS Y DOCUMENTACION De la misma forma que en el Framework en el sexto y último ciclo se desarrollaron las pruebas específicas para la aplicación y se definió la documentación que se realizaría. 5.6.1. Pruebas Para las pruebas se utilizó el mismo plan que en el Framework pero se le agregaron casos de prueba a la funcionalidad creada específicamente para la aplicación. Se realizaron las mismas pruebas del Framework, más los casos de prueba nuevos. 5.6.2. Documentación Para la documentación se definieron dos manuales, un manual de usuario y un manual de instalación y configuración. Para ver información detallada de los manuales y las pruebas (ver Anexos K, L, M). 65 6. CONCLUSIONES Y RECOMENDACIONES Debido a que la metodología ágil DAS se basa en la administración de proyectos de software e intenta solucionar el constante cambio de los proyectos, esto permitió que los cambios presentados durante el desarrollo del Framework y de la aplicación Web de administración y venta de películas DVD, fueran manejados de manera simple y ágil debido al ciclo de vida que presenta la metodología DAS, donde alguna modificación, cambio o mejora al componente que se va a entregar al finalizar el ciclo, se realiza mediante una iteración al ciclo que es afectado únicamente y no una revisión exhaustiva a todo el proyecto. La metodología DAS basada en la adaptabilidad al cambio y no en la prevención de éste, promueve reuniones periódicas para mirar el avance del proyecto, es aquí donde uno de los principales factores para que los cambios se realizaran rápidamente en el desarrollo del Framework y de la aplicación Web, fueron las constantes reuniones que se llevaron a cabo en el proyecto (cada 15 días). Esto permitió detectar errores en el proceso de desarrollo de forma rápida, al identificar los problemas o cambios oportunamente se hizo mucho más manejable su solución, sin llegar a afectar gravemente el cronograma del proyecto. Otro de los factores es que al realizar modificaciones no se generaron documentos nuevos, estos cambios se manejaron en las iteraciones correspondientes de cada ciclo. Por ejemplo en las pruebas se encontró un error en el tipo de dato de una de las tablas, esto provocó el desarrollo de una nueva iteración en el diseño y por lo tanto en la implementación, estas iteraciones fueron manejadas mediante un control de cambios que se maneja en cada uno de los documentos. El manejo de componentes del DAS nos permitió dividir un proyecto extenso y complejo como lo es el desarrollo de un Framework, en pequeños problemas a solucionar, esto hizo más manejable y sencillo el desarrollo del proyecto. El proyecto fue dividido en tres partes, la investigación, el desarrollo del Framework y el desarrollo de la aplicación. Para el desarrollo del Framework y de la aplicación, fueron seleccionados 6 ciclos, donde cada uno de los ciclos era un pequeño problema a solucionar. El manejo de los ciclos como lo presenta DAS, permitió una mayor organización, ya que cada uno de los ciclos fue planeado y enfocado a una misión. La metodología DAS presenta el refinamiento como parte del ciclo de vida en la parte del aprendizaje. Es por eso que los entregables realizados en cada ciclo como los documentos de análisis, diseño y pruebas y componentes desarrollados en los ciclos de implementación fueron mejorados y refinados en cada iteración, como lo presenta DAS para la etapa de aprendizaje y en las reuniones periódicas que deben realizarse para mirar el seguimiento y avance del proyecto. 66 Uno de los principales obstáculos del proyecto, fue el no tener un cliente ya que debido a esto toda la parte del análisis de requerimientos debió tratarse de una forma poco común (visitar tiendas virtuales), esto llevó a desacuerdos en cuanto a los requerimientos que se cubrirían. A pesar de esto se seleccionaron los requerimientos a común acuerdo más importantes basándonos en el dominio definido en la aplicación, de aquí la importancia de la definición del dominio acorde con lo que se quiere realizar en la aplicación. Una de las grandes complicaciones que dificultó la investigación y el desarrollo del proyecto, fue la falta de muchos recursos y la reciente metodología ágil como lo es el desarrollo adaptable de software. A su vez el desarrollo de un Framework es algo que es una tarea compleja, por lo que llevar a cabo el desarrollo de este proyecto fue bastante complicado, ya que los artículos encontrados sobre esta metodología, no son explicativos sino informativos, lo que quiere decir que nombran la metodología y las explicaciones son superficiales, con el fin de atraer al lector, pero no profundizar en la metodología de desarrollo adaptable. Se dice que lo más difícil es comenzar, por lo que iniciar el proyecto usando DAS, fue difícil sin tener una guía o proyecto anterior, pero a medida que el proyecto avanzaba, el desarrollo del proyecto se hizo más fácil ya que todos los ciclos fueron manejados de la misma manera y guiados por el ciclo de vida que presenta DAS. Desarrollo Adaptable de Software El Desarrollo Adaptable de Software no se centra en la metodología de construcción de software, o en las buenas practicas de programación como Extreme Programming, este se basa en la administración de proyectos de software, ya que intenta solucionar el constante cambio de los proyectos • Adaptable y tolerante al cambio La metodología desarrollo adaptable de software se basa en la adaptabilidad y tolerancia al cambio, lo que permitió que un desarrollo complejo y extenso como lo fue el desarrollo de un Framework y de una aplicación e-commerce, cuando se quisieron realizar innovaciones, cambios, ajustes e incluso mantenimiento, fuera una tarea sencilla y poco dispendiosa, ya que al realizar modificaciones no se generan documentos nuevos, estos cambios se manejan en las iteraciones correspondientes de cada ciclo. Por ejemplo en las pruebas se encontró un error en el tipo de dato de una de las tablas, esto provocó el desarrollo de una nueva iteración en el diseño y por lo tanto en la implementación, estas iteraciones fueron manejadas mediante un control de cambios que se maneja en cada uno de los documentos. • Ciclos manejados por una misión La metodología DAS, deja al desarrollador la propiedad de hacer cuantos ciclos se crean convenientes, pero define una pauta muy importante la cual es definir antes de cada ciclo una misión a seguir. La misión deberá abarcar el problema a tratar lo más que se pueda, dando una guía posterior a donde se quiere llegar y que se quiere hacer para que al final de cada ciclo se obtenga lo que realmente se desea obtener. La definición de la misión la propone DAS, haciendo referencia a como una empresa trabaja, es decir, el ejemplo de una empresa que tiene su misión apenas es creada para que sus objetivos 67 puedan cumplirse y muestre los beneficios al final de cada año. De esta manera DAS, da una idea de cómo al final de cada ciclo los objetivos pueden llegar a cumplirse. La planeación de los ciclos fue de vital importancia a la hora de desarrollar el componente de determinado ciclo. Dentro de la planeación de cada ciclo se determinaba una misión, lo que ayudó a seguir siempre un camino y no desbordarse, siempre sabiendo cual era la meta para cada ciclo. • Los ciclos adaptables son basados en componentes La metodología DAS define que en cada uno de los ciclos se haga entrega de un componente, es decir que para cada iteración se obtenga un entregable mejor al anterior. Para DAS el cliente es lo más importante, por lo que se debe tener al cliente totalmente satisfecho a largo del ciclo de vida del desarrollo de la aplicación y por supuesto al final de éste. Esto permite al cliente tener un avance en cada ciclo y mirar el progreso del desarrollo y dar su opinión. En el desarrollo del Framework y de la aplicación ecommerce cada iteración dejó como resultado un entregable, y al final de cada ciclo un componente desarrollado y refinado, para poder proseguir al siguiente ciclo. El hecho de que esta metodología esté basada en componentes permitió que el desarrollo del Framework siendo una aplicación tan extensa y compleja, se dividiera en pequeños problemas a solucionar, con soluciones más sencillas para cada componente para facilitar el desarrollo. • Los ciclos adaptables son planeados y programados El hecho de que los ciclos sean planeados y programados permitió una mayor organización para cada uno de los entregables realizados. En ningún momento el desarrollo de algún componente fue realizado a la deriva y sin un objetivo a cumplir. Al inicio de cada ciclo, como lo define DAS, el ciclo fue planeado y programado, por lo que se estimaba el tiempo para cada tarea y actividad dentro de cada uno de los ciclos. El hecho de planear y programar cada ciclo por separado, permitió tener una mejor planeación de todo el proyecto, ya que generó una planeación por partes y no una global que es más compleja de realizar y monitorear. En cada uno de los ciclos la planeación facilitó la repartición de las actividades a realizar para cada uno de los implicados en el proyecto y facilitó la estimación de tiempo para cada ciclo. • Establece colaboración por parte del usuario al equipo de trabajo y viceversa. Este es un factor destacado en la metodología DAS, ya que en todo momento existe un acercamiento con el cliente. Esto permite que el cliente exprese sus ideas de cómo le gustaría cada cosa y que el equipo de trabajo opine en la viabilidad de cumplir el requerimiento, esto con el fin de que al final del desarrollo del proyecto el equipo de desarrollo entregue realmente lo que el cliente deseaba. A su vez el cliente puede ayudar con los requerimientos del proyecto supliendo información suficiente a medida que avanza el proyecto. • La satisfacción del cliente es lo primordial Para DAS, aparte de las diferentes características para el desarrollo de una aplicación y la metodología a seguir para cada uno de los ciclos, es primordial y fundamental que todo el desarrollo de alguna aplicación este enfocado a la satisfacción del cliente por 68 encima de todo. Según esta metodología, no habrá un buen resultado si el cliente no esta de acuerdo con la entrega final. Para el desarrollo del Framework y de la aplicación ecommerce de venta de películas DVD, el resultado fue satisfactorio ya que cumplió los objetivos planteados para cada uno de los ciclos (ver anexos A, H), por lo que se cumple esta parte de la metodología ágil que nos presenta el desarrollo adaptable de software. • El cliente no es un usuario. El cliente hace parte del equipo de trabajo. Debido a que el cliente debe estar involucrado todo el tiempo en el desarrollo de la aplicación, se puede decir que él no es un usuario, sino parte del equipo de trabajo, ya que su colaboración es de vital importancia para obtener un resultado final satisfactorio. Para este proyecto, fue fácil notar esto, ya que en el desarrollo del Framework y de la aplicación de DVDs, el usuario y el equipo de trabajo eran el mismo, por lo que de forma literal se logró darse cuenta de que el producto final es más fácil obtenerlo si el cliente y el equipo de trabajo, se unen para trabajar en uno solo. • Metodología realmente nueva El desarrollo adaptable de software es una metodología ágil, esto hace en principio que se tome como una metodología realmente nueva. Es una metodología que no ha sido utilizada en muchos proyectos, por lo que casos de estudio realizados por DAS, son realmente pocos. En este proyecto, logró darse cuenta que foros de discusión y proyectos realizados por DAS eran pocos, lo que hizo menos fácil el desarrollo de estas dos aplicaciones. • Pocos desarrollos en Colombia usando como metodología el desarrollo adaptable de software Debido a que es una metodología nueva en el ámbito del desarrollo de software como se menciona anteriormente, cabe anotar que en Colombia el desarrollo de proyectos usando como metodología de desarrollo DAS es muy poco como pudimos observar a través de la consulta de algunas empresas que desarrollan software en Bogota, por ende se hizo difícil un contacto personal, con el fin de encontrar puntos de vista sobre esta metodología no implantada en proyectos colombianos, y experiencias obtenidas en sus propios desarrollos de aplicaciones. • Poca documentación La documentación obtenida sobre esta metodología adaptable es realmente poca, lo que hace difícil la investigación de la metodología, artículos, casos de estudio y textos guía. Realmente el libro que muestra la metodología es uno solo36. Los artículos encontrados sobre esta metodología, no son explicativos sino informativos, lo que quiere decir que nombran la metodología y las explicaciones son superficiales, con el fin de atraer al lector, pero no profundizar en la metodología de desarrollo adaptable. 36 James Highsmith, Adaptive Software Development, 2000 69 • Manejo con el cliente se puede complicar En puntos anteriores, se nombra que el trabajo unido con el cliente es de vital importancia para el DAS, lo que tiene a su vez en contra, es que el cliente en ciertas ocasiones no tiene idea de cómo se desarrollan las cosas, es decir el cliente puede llegar a ver las cosas desde una perspectiva diferente a la del equipo de trabajo, llegando así a un mal entendimiento con el personal de desarrollo, y por qué no a problemas en el resultado final. Otro problema que existe en el trabajo conjunto con el cliente, es que algunas veces el cliente cree que las aplicaciones a desarrollar son sencillas, cuando en realidad son tareas complejas y extensas, que requieren de validaciones y procesos realmente agotadores. Framework El desarrollo de aplicaciones reutilizables (Frameworks), se esta convirtiendo en uno de los principales factores a la hora de diseñar software. Pero, ¿Cómo es posible crear una aplicación que nos provea un núcleo de funcionalidad, que nos permita construir distintas aplicaciones a través de éste? El proceso de desarrollo del Framework, debe basarse en las instancias comunes del desarrollo de software, Análisis, Diseño, Implementación, etc. Pero cada una de estas etapas debe realizarse de una manera más profunda y detallada (en algunos casos se realizan actividades especificas para el Framework), debido a la necesidad de reutilización propia del Framework. Al igual que las otras aplicaciones, es importante la iteración de cada una de las etapas, con el fin de corregir errores o cambios en los requerimientos. El desarrollo del Framework exige un tratamiento especial al análisis y al diseño de la aplicación, ya que debe definirse un dominio claro y conciso. Esto debido a que es imposible desarrollar un núcleo el cual sea útil para todas las aplicaciones que quieran desarrollarse, por eso es necesario definir el alcance, en cuanto a requerimientos y funcionalidad que nos prestará el Framework. Al diseñar el Framework, debe definirse claramente que componentes o módulos serán configurables, ya que estos son los que mayor atención deben tener, debido a que en ellos recae la correcta reutilización de la aplicación. Para esta clase de desarrollos es necesario apoyarse en una gran cantidad de patrones, los cuales garanticen el correcto desarrollo de la aplicación. Para esto se seleccionaron los patrones que solucionan determinada problemática en el desarrollo de la aplicación. Una de las principales diferencias cuando se desarrolla un Framework contra cualquier otra clase de software es la importancia de la documentación. Ya que con el Framework la documentación no solo es un soporte al producto, sino que en realidad es parte del producto. 70 Para los usuarios del Framework es importante el mapeo explícito de la aplicación contra el Framework, a medida que el mapeo se haga mas temprano en el proceso de desarrollo de la aplicación, mayor será el uso que se le de al Framework, hasta llegar a su mayor capacidad. Los usuarios del Framework, deben basar su documentación en la del Framework, esta debe ser el punto de partida y debe expandirse a los requerimientos específicos de la aplicación. En conclusión al construir aplicaciones reutilizables, debe analizarse específicamente el nivel de reutilización que se quiere obtener de dicha aplicación, y que tipo de funcionalidad prestara y a que tipo de usuarios estará dirigida, esto con el fin que el usuario aproveche el Framework al máximo, y pueda sacar el mayor provecho de este. 71 TRABAJO A FUTURO A un futuro debe mejorarse el diseño gráfico de la aplicación DVD ya que el realizado solo se hizo para probar la funcionalidad de la aplicación y del Framework, mas no se hizo pensando en el usuario final. Por esto las pantallas pueden llegar a ser poco atractivas a la vista. Validar los campos de la interfaces graficas con sus correspondientes tipos de datos como el correo electrónico. La aplicación podrá ser complementada con el desarrollo correspondiente al alquiler de bienes materiales. Reutilización del Framework para otro producto diferente. 72 BIBLIOGRAFIA [1] AMOR, Daniel. The E-Business Revolution, 1999. [2] BRUEGGE Bernd y DUTOIT Allen, Ingeniería de Software Orientada a Objetos. [3] Carey, James y Carlson, Brent. Framework Process Patterns. [4] Asociación Colombiana de Ingenieros de Sistemas, www.acis.org, 5 mayo de 2004. [5] FOWLER, Martin y HIGHSMITH, James. The Agile Manifesto. En Software Development Magazine, Agosto de 2001. [6] FOWLER, Martin. The new Methodology (online) Abril de 2003. http://martinfowler.com/articles/newMethodology.html [7] Guía al “Software Engineering Book of Knowledge”, www.swebok.org. [8] HAMEL, Sylvian y HIGHSMITH, James. Optimize or Apapt En Software Development Magazine, Abril de 2000. [9] HIGHSMITH, James. Adaptive Software Development, A collaborative approach to managing complex systems, 2001. [10] HIGHSMITH, James. Agile Software Development: The Business of Innovation. En Institute of Electrical and Electronics Engineers (IEEE) magazine, Septiembre de 2001. [11] HIGHSMITH, James. Agile Software Development: The People Factor. En Institute of Electrical and Electronics Engineers (IEEE) magazine, Noviembre de 2001. [12] HIGHSMITH, James. Project Management at the edge. The It Project Leader Magazine, Febrero de 2000. [13] HIGHSMITH, James. Retiring Lifecycle Dinosaur. En Software and Testing & Quality Engineering, Agosto de 2000. [14] HIGHSMITH, James. Software Ascents. En American Programmer Magazine, junio de 1992. [15] IEEE standard for software test documentation 73 [16] IEEE Recommended Practice for Software Requirements Specifications [17] IEEE Recommended Practice for Software Design Descriptions [18] IEEE standard for software user documentation [19] KALAKOTA, Dr. Ravi. E-Business, Roadmap for Success, 1999. [20] Larman, Craig. Applying UML and patterns: An introduction to object-oriented analysis and design. 1998. 74
