______________________________________ Director del proyecto
______________________________________ J urado
______________________________________
J urado
BOGOTA, D.C J UNIO DE 2005
Artculo 23 de la Resolucin No. 1 de J unio de 1946
La universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado.
Slo velar porque no se publique nada contrario al dogma y la moral catlica y porque no contengan ataques o polmicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la J usticia.
A nuestras madres quienes son la mayor inspiracin en nuestras vidas
AGRADECIMIENTOS
Los autores expresan sus agradecimientos a: Nuestras Familias por toda su colaboracin. Nuestros compaeros 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 motivacin y determinacin en este trabajo. Profesores, docentes y colaboradores quienes hicieron posible nuestro desarrollo profesional.
TABLA DE CONTENIDO
Pg.
0. INTRODUCCIN......................................................................................................12 1. 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. Metodologas 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 segn Craig Larman 22 1.5.2. Patrones utilizados en el proceso de desarrollo de un Framework segn 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. DISEO...............................................................................................................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. Documentacin ...........................................................................................54 5. DESARROLLO DE LA APLICACIN PARA LA VENTA DE DVD................56 5.1. PLAN DE CICLOS DE DESARROLLO ADAPTABLE...............................56 5.2. ANALISIS ...........................................................................................................56 5.3. DISEO...............................................................................................................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. Documentacin ...........................................................................................65 6. CONCLUSIONES Y RECOMENDACIONES .......................................................66 TRABAJO A FUTURO.....................................................................................................72 BIBLIOGRAFIA................................................................................................................73
LISTA DE FIGURAS
Ilustracin 1. Ciclo de Vida del Desarrollo Adaptable.........................................................19 Ilustracin 2. Diagrama de Casos de Uso del Framework ...................................................37 Ilustracin 3. Modelo de Datos del Framework...................................................................38 Ilustracin 4. Diagrama de Arquitectura del Framework.....................................................39 Ilustracin 5. Clases Producto, BackupAdmin, Cliente y Administrador............................42 Ilustracin 6. Clases TipoTarjeta, OrdenCompra, Tarjeta Credito y Producto Fisisco.......43 Ilustracin 7. Clases Service Locator y Factory..................................................................44 Ilustracin 8. ClienteMgr Session EJ B.................................................................................45 Ilustracin 9. AdministradorMgr Session EJ B. ....................................................................46 Ilustracin 10. TiendaMgr Session EJ B...............................................................................47 Ilustracin 11. EntidadFinancieraMgr y KartMgr SessionsEJB...........................................48 Ilustracin 12. Clases DAO's................................................................................................49 Ilustracin 13. EJ B EntitiesEJB CMP'S...............................................................................50 Ilustracin 14. EJ B EntitiesEJB CMP..................................................................................51 Ilustracin 15. Clase Bussines Delegate...............................................................................53 Ilustracin 16. Diagrama Casos de Uso Aplicacin DVD...................................................57 Ilustracin 17. Modelo de Datos Aplicacin DVD..............................................................58 Ilustracin 18. Diagrama de Arquitectura Aplicacin DVD................................................59 Ilustracin 19. Clase DVD y ProductoCreator.....................................................................60 Ilustracin 20. Clase DAOProductos Aplicacin DVD.......................................................60 Ilustracin 21. BMPDVDProducto Aplicacin DVD..........................................................62 Ilustracin 22. Clase BusinessDelegate Aplicacin DVD....................................................64 Ilustracin 23. Clase Servlet Aplicacin DVD.....................................................................65
GLOSARIO
DAS: Desarrollo gil de Software, metodologa 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 nmero de problemas en uno o ms dominios.
E-commerce: Es el tipo de transaccin econmica -compra y venta- que se realiza a travs de sistemas electrnicos. Una empresa, comnmente presente en la red, vende productos o servicios a travs de Internet.
Base de Datos: Una base de datos es un conjunto de informacin estructurada, como por ejemplo las cifras de ventas de un ao. Las bases de datos tradicionales estn diseadas para gestionar datos tales como importes, cantidades, fechas y, limitadamente, texto.
DAO: Data Access Object, este es un patrn el cual tiene como fin abstraer y encapsular todos los accesos a la fuente de datos, logrando as desacoplar la lgica de negocios de la lgica de acceso a datos. El DAO maneja la conexin con la fuente de datos para obtener y almacenar datos.
Enterprise Java Beans EJB: Los EJ Bs proporcionan un modelo de componentes distribuido estndar 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 aplicacin empresarial (concurrencia, transacciones, persistencia, seguridad, etc.) para centrarse en el desarrollo de la lgica 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 EJ Bs de entidad presentan la caracterstica 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 Sesin (Session EJBs): Gestionan el flujo de la informacin 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 sesin 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 sesin 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 mtodo.
Business Delegate: Patrn que se utiliza para reducir el acoplamiento entre los clientes de la capa de presentacin y los servicios de negocio. El Business Delegate oculta los detalles de la implementacin del servicio de negocio, como los detalles de bsqueda y acceso de la arquitectura EJ B.
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 J ava 2 Edicin Empresarial que define un estndar para desarrollar aplicaciones empresariales en lenguaje de programacin J ava.
Oracle: Es un sistema de administracin de base de datos (o RDBMS por el acrnimo en ingls 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, an a caractersticas del lgebra y el Clculo relacional permitiendo lanzar consultas con el fin de recuperar informacin de inters 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 extensin de la plataforma J ava que provee una interfaz estndar para nombres heterogneos y directorio de servicios.
Data Source: Un sitio de datos especfico, donde la informacin es almacenada y puede ser obtenida.
11
0. INTRODUCCIN
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 aplicacin, lo cual es una situacin muy normal, debido a lo voltil que son las organizaciones hoy en da, y a la fuerte competencia que hay entre stas. Tambin el cambio de mbito de las aplicaciones y la introduccin de nuevas tecnologas 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 fcil solucin 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 ms efectivo que tratar de prevenirlo.
El desarrollo gil de software se enfoca ms 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 satisfaccin del cliente, pero para llegar a ese punto es necesario la colaboracin 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 metodologas, entiende que el mundo del dominio esta cambiando, por lo cual el desarrollo de software no puede verse desde una perspectiva lineal en ningn caso. Por lo que cada proyecto tiene un contexto y forma de resolucin diferente.
En Colombia, el desarrollo de software para e-commerce en las empresas es cada vez ms fuerte y tiene ms acogida 1 , por lo que cada vez mas grupos de desarrollo de software optan por diferentes metodologas 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 diseo e implementacin de Frameworks, ha ido creciendo de una forma acelerada ya que al ser reutilizables, reducen drsticamente los costos y la complejidad de los proyectos de
1 ACIS Asociacin Colombiana de Ingenieros de Sistemas, http://www.acis.org.co/ 12 software. Un Framework es un conjunto de clases reutilizables para el diseo e implementacin de un clase de software especfico. Extendiendo un poco esta definicin se puede decir que un Framework es un conjunto de componentes que pueden solucionar problemas en uno o ms dominios de aplicacin 2 . Es el encargado de manejar el ncleo de la aplicacin.
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 fcil adaptacin y utilizacin, se desarroll una aplicacin especfica de e-commerce, en este caso la venta de DVDs 3 por Internet.
Por medio del uso del desarrollo adaptable de software en este proyecto de investigacin, se pretende mostrar la aplicacin de una metodologa diferente en el desarrollo de software, a las comnmente usadas, para que esta pueda ser utilizada por personas interesadas en conocer el desarrollo de aplicaciones por medio de una metodologa gil.
Tambin se quiere mostrar, la importancia del anlisis y el diseo a la hora de desarrollar aplicaciones reutilizables como el Framework, ya que estas etapas y sus respectivos entregables hacen parte de dicha reutilizacin.
Esperamos que este Proyecto colme las expectativas del lector y deje un aporte en cada uno de ellos.
2 Carey, J ames y Carlson, Brent. Framework Process Patterns Pg. 1 3 Digital Video Disc 13
1. MARCO TEORICO
Muchos autores a travs de los aos han comparado el desarrollo de software, con el alpinismo 4 , en esta disciplina, el objetivo es escalar la montaa, para conseguir esto el escalador debe tener ciertas habilidades dependiendo de las caractersticas de la montaa, es decir la altura, la inclinacin, temperatura, clima y dems factores externos y adems determinadas herramientas como botas, arns, 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 (montaa) 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 montaas y de desarrollar software, de alta velocidad y rpido 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 ingeniera de la informacin era el camino, los modelos se caracterizaban por diagramas de flujo de datos y diagramas entidad relacin.
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 implementndolos en bases de datos para despus construir aplicaciones. Todo esto tomaba varios aos por lo que lo ideal era producir el software correcto en el primer intento.
El punto ms alto de esta poca fueron las metodologas definidas en 14 volmenes, en los cuales se detalla cada tarea, documento o forma, que debe tenerse en cuenta en el desarrollo de software, de estas prcticas se deriv lo que ahora conocemos como herramientas CASE (Computer-Aided Software Engineering). Hasta finales de los aos 90 muchos productos de software fueron construidos utilizando estas tcnicas de desarrollo, los cuales sufrieron varios tipos de inconvenientes, tales como:
4 J ames Highsmith, Adaptive Software Development, 2000 Captulo 1, 5 Computador Central 6 HIGHSMITH, J ames. Agile Software Development: The People Factor. En Institute of Electrical and Electronics Engineers (IEEE) magazine, Noviembre de 2001. 14 Los clientes no estaban satisfechos, ya que despus de ciclos tan largos de desarrollo, muchas aplicaciones no cubran sus necesidades, ya que los requerimientos haban cambiado durante el desarrollo. El tiempo que se tomaba el proceso era muy largo, y el negocio era muy variable, su cambio era muy rpido para ese tipo de ciclo de vida de desarrollo. En general los mtodos del desarrollo monumental de software no se adaptan bien al rpido y constante cambio de las condiciones y el entorno de algunos negocios.
A principios de los aos 90 esta perspectiva cambi debido a la aparicin de los computadores personales, de C++, J ava, 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 mtodos o metodologas, ya que se crea que el proceso solo demorara el desarrollo, utiliza una metodologa bottom-up y short-term, la cual empieza con el desarrollo inmediato de aplicaciones que cubren las necesidades de los clientes, dndole poca importancia a la integracin con las dems aplicaciones, el cdigo deba ser rpido sin prestarle mucha atencin al diseo. El desarrollo de estas aplicaciones oscilaba entre los 2 a 6 meses, ya que se consideraba que si un proyecto duraba ms tiempo sera un producto obsoleto al finalizar el proceso.
El desarrollo accidental de software, tambin tena varios inconvenientes:
La poca integracin del software con las dems aplicaciones Fragmentacin de datos y redundancia mltiple, ya que el tener los datos sincronizados era un reto permanente, esto debido a la poca si no nula integracin del software. El software final requera mantenimiento constante, ya que las aplicaciones tenan datos redundantes, y diferentes modelos de datos.
En conclusin este tipo de desarrollo termina siendo largo y costoso debido a la cantidad de correcciones y mantenimiento general que deben ser realizadas despus de implantar el software.
1.2.EXTREME PROJECTS
Las organizaciones hoy en da, suelen tener problemas con los proyectos de alta velocidad y rpido 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 difciles, problemticos y comnmente fallidos, ya que su entorno cambia constantemente, y su margen de error debe ser mnimo.
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, J ames. Agile Software Development: The People Factor. En Institute of Electrical and Electronics Engineers (IEEE) magazine, Noviembre de 2001. 8 J ames Highsmith Adaptive Software Development, 2000 Capitulo 1 15 Para desarrollar esta clase de proyectos se requiere mas que una nueva herramienta o tcnica, 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 situacin muy normal, debido a la competencia y los cambios que se viven en las organizaciones da a da. Tambin el cambio de mbito de las aplicaciones y la introduccin de nuevas tecnologas, 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 travs del proyecto, ya que facilitar el cambio es ms efectivo que tratar de prevenirlo. 10
El desarrollo gil de software se enfoca ms en los individuos y sus respectivas interacciones, que en los procesos y herramientas. As como es ms importante el trabajo de software que las documentaciones, y se preocupa por la colaboracin con el cliente que en el contrato de negociacin. 11 Es por eso, que la mayor prioridad del desarrollo gil de software es la satisfaccin del cliente, pero para llegar a ese punto es necesaria la colaboracin, ya sea de patrocinadores, clientes, usuarios y por supuesto los desarrolladores.
El desarrollo gil de software se ha vuelto ms popular en los ltimos aos, por lo que diversos mtodos de desarrollo gil han sido implementados, con el nimo de poder entregar al usuario un software mucho ms rpido. Los mtodos de desarrollo gil de software son basados en satisfacer al mximo al cliente, adaptarse al cambio fcilmente, hacer entregables frecuentemente y que exista una estrecha colaboracin hacia el equipo de trabajo, por parte del personal del negocio.
En comparacin con los procesos de software tradicionales, los mtodos de desarrollo gil de software son orientados mucho ms al cdigo y a las entregas, por lo que la documentacin no es el centro del proceso de desarrollo, donde al usuario le importa ms la entrega realizada despus de cada ciclo del desarrollo que el propio documento. 12
Los mtodos de desarrollo gil de software se preocupan ms por la adaptabilidad que por la prediccin, por lo que fueron desarrollados para adaptase y prosperar rpidamente a los cambios frecuentes.
9 HIGHSMITH, J ames. Agile Software Development: The Business of Innovation. En Institute of Electrical and Electronics Engineers (IEEE) magazine, Septiembre de 2001. 10 HIGHSMITH, J ames. Agile Software Development: The Business of Innovation. En Institute of Electrical and Electronics Engineers (IEEE) magazine, Septiembre de 2001. 11 HIGHSMITH, J ames. Requirements Engineering and Agile Software development. 2001. 12 HIGHSMITH, J ames. Requirements Engineering and Agile Software development. 2001. 16
Entre los mtodos ms comunes de desarrollo de Software estn XP (Extreme Programming), Modelamiento gil (AM), Scrum, metodologas Cristal, FDD (Feature Driven Development), DSMD (Dynamic Systems Development Methods) y en la que se enfoca este trabajo DAS (Adaptive Software Development). 13
A continuacin se har una breve resea de las ms importantes metodologas de desarrollo gil de software
1.3.1. Extreme Programming (XP)
Esta basado en simplicidad, retroalimentacin y comunicacin, donde los ciclos recomendados o iteraciones deben ser de 2 a 6 semanas, esto con el fin de producir entregas rpidas y una retroalimentacin ms 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 cmo construir modelos, que resuelven problemas de diseo, para no construirlos nuevamente. No es un proceso de desarrollo completo, nicamente para el diseo.
1.3.3. Scrum
Es un mtodo para la gestin 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. Metodologas Cristal
Son una familia de diferentes metodologas, las cuales pueden ser escogidas, dependiendo del tipo de proyecto, dentro de los tipos se encuentran Clear, Yellow, Orange, Red, Magenta, Blue, Violet. Entre ms oscuro el color, ms personas deben estar involucradas en el desarrollo, debido a la complejidad.
1.3.5. Feature Driven Development Method (FDD)
Es una metodologa que provee un marco de trabajo adecuado para el desarrollo de aplicaciones rpidas. Existen dos pasos en esta metodologa, 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, J ames. 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 mltiples cambios, DAS se basa en mtodos 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 caractersticas del ciclo de vida adaptable son las siguientes Enfocado a una Misin Basado en Componentes Iterativo Tiempos de entregas Mitigacin de Riesgos Tolerancia a cambios
La cultura de optimizacin, cree en el rigor de los procesos, pero la era del Internet ha alterado estos fundamentos, ya que estas aplicaciones trabajadas va Web son comnmente impredecibles, porque tienen variables que estn cambiando constantemente, como por ejemplo los requerimientos, los productos, la tecnologa, 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 mecnico sino uno orgnico, no lineal y no determinstico. Por lo que cada proyecto tiene un contexto y forma de resolucin diferente.
14 HIGHSMITH, J ames. Requirements Engineering and Agile Software development. 2001. 18 1.4.1. Ciclo de vida del Desarrollo Adaptable de Software
Ilustracin 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 colaboracin entre los desarrolladores y sus clientes.
A diferencia de la mayora de metodologas de desarrollo de software las cuales utilizan un ciclo de vida esttico: Planear-Disear-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 dinmico e iterativo conocido como Especular-Colaborar-Aprender, este ciclo esta dedicado a un constante aprendizaje y a una intensa colaboracin entre desarrolladores y clientes, esto debido al constante cambio en el ambiente de los negocios.
Especulacin: Ofrece ms espacio para explorar, para darse cuenta que no todo es seguro, permitiendo desviarse del plan sin ningn temor. Muchas veces desviarse del plan original puede considerarse un error, mas que una oportunidad de aprendizaje, es ah donde la especulacin incita a explorar y a experimentar. Si se admite que no se conoce todo, se est ms dispuesto a aprender.
Colaboracin: Las aplicaciones complejas requieren, la recoleccin y el anlisis de un gran volumen de informacin, 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 pequeo, 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 adaptacin.
1.5.FRAMEWORK
Para aquella persona que est familiarizada con el desarrollo orientado a objetos (object- oriented development), estar a su vez familiarizado con el desarrollo de un Framework, ya que ste se basa en el diseo orientado a objetos, y a su vez es muy importante la entrega de componentes y la entrega limitada de documentacin hecha anteriormente. Tal vez esto ltimo suene conocido, ya que se basa en aspectos donde el Desarrollo Adaptable de Software tambin 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 J ava 15 . Por otro lado se puede ver la definicin de J ames Carey y Brent Carlson donde afirman que un Framework es una serie de componentes trabajando de forma unida, que direccionan el nmero de problemas en uno o ms dominios 16 .
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 mtodos, dependiendo de las necesidades de su aplicacin. Adems 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 lgico.
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 podran contener tanto mtodos abstractos como concretos.
Confa en el Principio Hollywood, No nos llame, nosotros le llamaremos. Esto significa que las clases definidas por el usuario recibirn mensajes desde las clases predefinidas del Framework.
15 Larman, Craig. Applying UML and patterns: An introduction to object-oriented analysis and design. 1998. 16 Carey, J ames and Carlson, Brent. Framework Process Patterns. 2002 17 Carey, J ames and Carlson, Brent. Framework Process Patterns. 2002 20 Ofrecer un alto grado de reutilizacin.
Hay que tener en cuenta que un Framework no es una clase librera, ya que un Framework no provee clases y funciones al punto de ser nicas, sino que provee la reutilizacin al siguiente nivel de clases y funciones. Esto sin dejar atrs que un Framework puede ser construido mediante el uso de una librera.
El desarrollo de un Framework no es solo un grupo de patrones, sino que a su vez es la combinacin de diseos e implementaciones, enfocados a encontrar una serie de necesidades en general y una construccin 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 comunicacin, consistencia, iteracin, incompletitud, flexibilidad y desconfianza.
o Comunicacin: Debido a que la informacin debe ser comunicada a tiempo y de una manera precisa o Consistencia: Las cosas iguales deben ser hechas de igual manera. o Iteracin: 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 extensin 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 diseo e implementacin 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 materializacin y desmaterializacin de la base de datos. Materializacin y Desmaterializacin: Transformar una representacin 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 Transaccin de Objeto: Es til conocer el estado de los objetos en funcin de sus relaciones con la transaccin actual. 21 Operaciones de transaccin: Commit y Rollback. Materializacin 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 construccin del Framework.
1.5.1. Patrones utilizados en el desarrollo de un Framework segn Craig Larman 18
Representacin de Objetos como tablas: Este patrn propone la definicin 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 materializacin no proporciona objetos duplicados. Este patrn propone asignar a cada objeto y registr un identificador nico (Object ID). Este identificador usualmente es un valor alfanumrico.
En el campo de los objetos, un OID se representa mediante una interfaz o clase OID, que encapsula su valor real y su representacin, en el caso de las bases de datos comnmente se almacena como un carcter 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 tambin 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.
Mtodo Plantilla: Este patrn es un parte esencial en el diseo del Framework, la idea es crear un mtodo en una superclase que defina el esqueleto de un algoritmo, con sus partes variables e invariables. El mtodo plantilla invoca otros mtodos, algunos de estos pueden ser redefinidos en una subclase, de esta manera se puede aadir un comportamiento propio y nico a los puntos de variabilidad, dependiendo de las necesidades del usuario.
Estado: Para este patrn debemos asumir que los objetos persistentes pueden, insertarse, eliminarse o modificarse. Pero operar sobre un objeto persistente no provoca una actualizacin 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 patrn crea clases de estado para cada estado, que implementa una interfaz comn, ya que el comportamiento de un objeto depende de su estado y sus mtodos contienen la lgica de casos que reflejan las acciones dependientes del estado.
Command: Una transaccin 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 transaccin (insertar, eliminar, actualizar) podran ser varias, por ejemplo 2 insertar y 1 actualizar. Para esto se define una clase por cada tarea que implemente una interfaz comn, as las acciones se convierten en objetos y de esta forma se pueden ordenar.
Cada tarea o accin de la transaccin se representa mediante un objeto que posee un mtodo polimrfico 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 segn Brent Carlson y James Carey 20
Los patrones que se mencionan a continuacin son patrones que tienen que ver con el todo el proceso de desarrollo del Framework, su arquitectura y ciertos aspectos a considerar en la ejecucin del proceso de desarrollo.
Seguir un proceso de desarrollo metdico: Para el desarrollo de un Framework es necesario seguir con un proceso metdico, 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 tcnicos expertos: Debido a que el software se mueve en direccin al reino de la aplicacin del negocio y las tecnologas permanecen en constante avance, es muy difcil tener una persona en algn momento determinado que posea el dominio y la experiencia tcnica necesarias, a su vez es necesario que se incremente la conexin entre expertos, ya que esto mejorar el software que se produce. Este patrn se conoce tambin como Preguntas Inocentes.
Dividir y Conquistar: Este es una frase conocida, la cual significa que los problemas grandes deben ser divididos para convertirlos en pequeos problemas para facilitar su solucin. El Framework deber ser dividido en partes que sean ms fciles de desarrollar y llevar a cabo.
La consistencia es el Rey:
19 Larman, Craig. Applying UML and patterns: an introduction to object-oriented analysis and design. 1998 20 Carey, J ames and Carlson, Brent. Framework Process Patterns. 2002 23 Este patrn conocido tambin como Mantener la consistencia a travs 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, hacindolo ms consistente.
Tres iteraciones para validar: Como cualquier desarrollo de software orientado a objetos, la iteracin es un aspecto muy importante en el desarrollo de un Framework. Estas iteraciones permitirn un refinamiento del Framework, y segn los autores el nmero de iteraciones es importante definirlo, pero 3 iteraciones es la clave segn autores 21 .
Exponerlo todo: Conocido tambin como El cliente del Framework es su compaero, 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 podra decir que es la ms importante, es la definicin de requerimientos, ya que identificarlos y capturarlos es la clave para la construccin exitosa del Framework. Un buen levantamiento de requerimientos ayuda a asegurarse de que el Framework esta bien enfocado. Segn Carey y Carlson de esta tarea depende todo de ah en adelante, si se construye una buena base, el xito ser ms fcil de alcanzar. 22
Existen ciertos patrones para la recoleccin de requerimientos. 23
Identificar la personalizacin: 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.
Implementacin hacindose pasar por requerimientos: Debe tenerse en cuenta en la evaluacin de requerimientos, que esos requerimientos no estn nicamente describiendo una implementacin en disfraz, sino que hay que tomarse el tiempo para explorar los objetivos que estn detrs de los requerimientos ya declarados.
Como segundo ciclo se puede ver el ciclo del Anlisis, que segn los autores Carey y Carlson antes mencionados 24 , si la fase anterior eran los requerimientos, y estos son la
21 Carey, J ames and Carlson, Brent. Framework Process Patterns. 2002 22 Carey, J ames and Carlson, Brent. Framework Process Patterns. 2002 23 Carey, J ames and Carlson, Brent. Framework Process Patterns. 2002 24 materia prima, el anlisis es el que comienza con su proceso de refinamiento. Si el anlisis es bueno, debe identificar entidades y definir responsabilidades. Existen ciertos patrones que sirven para asistir en la fase del anlisis.
Descomponiendo el problema: Conocido tambin 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 mnimo de interaccin con otros componentes y las clases de anlisis con una alta afinidad con otras clases debern ser agrupadas entre s para facilidad en el manejo de dependencias.
Algo es mejor que nada: Conocido tambin como Documentar lo que conoces cuando lo conoces. Este patrn es bsico, ya que lo que indica es que a medida que se va adelantando, se debe documentar, claro que esta documentacin 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.
Comunicacin entre dominio y equipo: Debe haber una excelente comunicacin y profunda informacin 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 comunicacin que debe haber, la correccin de este se har de forma temprana y su costo ser mucho menor.
El tercer ciclo llamado el Diseo se encarga de convertir o transformar la informacin que provee el anlisis y los requerimientos en verdaderos anteproyectos (blueprints). Es aqu donde los mtodos, 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 Diseo.
Conocer cuando un Framework no debera hacer algo: Este patrn es usado, para ayudar en la implementacin de lo funcional, que pueda quedar algo a la imaginacin 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 estn exentos de prcticas buenas o malas de ser orientados a objetos:
24 Carey, J ames 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 prcticas en proyectos orientados a objetos no debern ser usadas para el desarrollo de un Framework.
1.6. E-COMMERCE
La introduccin del comercio electrnico en los pases en desarrollo, ha provocado cambios dramticos en la forma en que se desarrollan los negocios, incluso en aquellas que parecan perpetuarse. Nuestro pas no es un caso aislado a los dems.
Uno de los objetivos primarios del comercio electrnico es la contribucin al aumento de la capacidad competitiva en el mercado, mediante el fortalecimiento del mercado, de los clientes del negocio, tambin 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 electrnico tendr implicaciones que afecten a otros (empresas, proveedores, clientes). As que ante este nuevo entorno, las empresas buscarn calidad y menor precio, y si en su actual red comercial de distribucin no satisfacen estos factores, debe pensarse en el rediseo de la misma o en prescindir de ella.
Este tipo de cambios dramticos no ha sido nicamente caracterstico de esta era digital, tambin ha sucedido en otras etapas del desarrollo tecnolgico de la comunicacin. Una nueva tecnologa siempre cambia la manera de actuar de las sociedades. El trabajo cotidiano, la educacin, la poltica, el comercio, y en general la forma de desenvolvimiento de las organizaciones se transforma con la introduccin de una tecnologa. De acuerdo a Neil Postman 25 , Internet podra definirse como una tecnologa similar a la televisin 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. Segn la Organizacin Mundial de Comercio, las tecnologas de Internet ofrecen a los pases en desarrollo grandes oportunidades para obtener informacin que antes era inaccesible para ellos. La transferencia de conocimientos resultante puede estimular el crecimiento de esos pases y contribuir a su integracin en los mercados mundiales.
El crecimiento de Internet y el comercio electrnico ha sido, cuando menos, meterico, y este ritmo vertiginoso no parece decaer. Nuevos elementos y estimaciones en los medios de informacin y otras publicaciones, sobre todo en los tres ltimos aos, explican las razones de ese auge. Como observacin de carcter general, las mltiples previsiones que se han hecho de ese fenmeno 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 expansin de ese fenmeno.
Los avances tecnolgicos de la computacin 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 pequeas y grandes empresas, al permitir la globalizacin de productos y servicios. El comercio
25 CHERNIAK, 1998 26 tambin se ha visto beneficiado con estos avances, con el llamado e-commerce o comercio electrnico.
El e-commerce (Comercio Electrnico) es la compra y venta de bienes y servicios travs de Internet. Podramos decir que el e-commerce est estructurado por "Tiendas virtuales" en sitios Web que ofrecen catlogos en lnea. Incluso se han creado "Centros comerciales virtuales" con gran cantidad de tiendas con todo tipo de accesorios para la venta. Esta forma de comercio electrnico ha consolidado a grandes empresas que ya figuran en la bolsa de valores y son de los portales de Internet ms visitados.
Cuando se habla de transacciones comerciales se distinguen claramente los distintos roles de una transaccin. 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 fsico donde se realiza la transaccin, el dinero o medio de pago y por ltimo el producto o servicio a comercializar.
En el e-commerce tambin se pueden distinguir ciertos actores o elementos adems de los anteriores: Un producto o servicio, el que puede ser virtual o real El lugar fsico es ahora reemplazado por un sitio Web abierto las 24Hs. Compradores que son los navegantes de la tienda virtual Vendedores que operan a travs de la tienda virtual Una cuenta comercial con un Banco para hacer efectivas las transacciones por lo general a travs de la validacin de tarjetas de crdito Un sistema de distribucin de los productos Un sistema de atencin al cliente, va mail, Internet, Chat, etc.
27
2. DESCRIPCION DEL PROYECTO
A continuacin veremos una breve descripcin general del proyecto con el fin de ubicarnos, y poder hacer un mejor seguimiento de las partes que lo componen.
El proyecto de investigacin se dividir en 3 etapas: Investigacin Desarrollo Adaptable de Software y desarrollo de Framework Desarrollo de Framework utilizando DAS Desarrollo de Aplicacin Venta DVD utilizando el Framework y DAS
La primera etapa de la investigacin comenz despus de entregada la propuesta y se continu a medida que el proyecto avanzaba, ya que la informacin relacionada con estos temas es muy nueva y surga constantemente.
La segunda etapa consisti en la construccin 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 implantacin de una aplicacin especfica de e-commerce, utilizando el Framework elaborado en la etapa anterior. Esta aplicacin estar orientada a la venta y alquiler de DVDs, todo esto se har basado en la metodologa 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 aplicacin tangible de e- commerce 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 e- commerce diferente a la desarrollada por nosotros.
Para la construccin del Framework, nos basaremos en la metodologa del desarrollo adaptable de software. La implementacin del mismo tendr 3 etapas generales, la especulacin en la cual se realiza el anlisis y el diseo, la colaboracin la cual cubre el desarrollo componentes (diseo del Framework, y la instanciacin 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 nmero de ciclos es el aconsejado por J ames Highsmith en su libro Adaptive Software Development de acuerdo a la duracin 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 haba 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 continuacin
Incubeit En esta compaa se utiliza una metodologa de cascada, no se utiliza ni se conoce nada sobre DAS
Asesoftware Se utiliza la metodologa RUP, no se utiliza ni se conoce nada sobre DAS
Bisa Corporation Se utiliza UML, bajo un estndar propio de la compaa, no se utiliza ni se conoce nada sobre DAS
DataSixx Se utiliza una metodologa propia basada en SAP Blueprint no se utiliza ni se conoce nada sobre DAS
Heinsohn Se utiliza UML, bajo un estndar propio de la compaa, no se utiliza ni se conoce nada sobre DAS
EDS Se utiliza RUP y se estn realizando investigaciones para la utilizacin de XP (Programacin extrema), no se utiliza DAS
CSI- Complex Systems Inc. Se utiliza una metodologa propia de la compaa, no se utiliza ni se conoce nada sobre DAS
Alpha GL Se utiliza UML, bajo un estndar propio, no se utiliza ni se conoce nada sobre DAS
Sybase No se conoce nada sobre DAS, en cuanto a la metodologa utilizada la informacin no fue suministrada 29
TinySoft No se conoce nada sobre DAS, en cuanto a la metodologa utilizada la informacin no fue suministrada
De acuerdo a la informacin ninguna de las 10 empresas seleccionadas haba trabajado ni conoca el desarrollo adaptable de software. En conclusin son muy pocas las empresas las cuales utilizan metodologas de desarrollo gil de software.
A continuacin veremos el proceso de desarrollo adaptable de software que se utiliz en la realizacin del framework.
1 Ciclo
Para el Plan de Ciclos de desarrollo adaptable se realizaron 7 iteraciones en total.
o Primera iteracin 15/08/2004 Corresponde a la especulacin, se definieron el nmero de ciclos que se realizaran y sus correspondientes actividades, esta informacin era tentativa, ya que se tena muy poco conocimiento e informacin del desarrollo del Framework en general.
o Segunda iteracin 20/08/2004 A medida que se obtuvo ms informacin acerca del desarrollo del Framework, Se replantearon los ciclos que deban 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 ningn trauma en el desarrollo del proyecto.
o Tercera iteracin 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 iteracin 15/10/2004 Debido a cambios en el anlisis y el diseo del Framework, se cambiaron algunos componentes de los ciclos de implementacin, se realiz la correspondiente correccin de la lista de actividades y el cronograma. Se redefini el ciclo 6, igual que sus objetivos y componentes.
o Quinta iteracin 16/10/2004 Se corrigieron algunas actividades y componentes de los ciclos de anlisis, diseo e implementacin.
o Sexta iteracin 18/10/2004 Correccin de algunas de las actividades y componentes de los ciclos de implementacin. 30
o Sptima iteracin 28/03/2005 De acuerdo a la recomendacin del comit de investigacin se cambi el trmino e-business por e-commerce
2 Ciclo
Para el ciclo de Anlisis se realizaron 8 iteraciones.
o Primera iteracin 24/09/2004 Se realiz una primera versin del documento (borrador) propuesto en el 1 ciclo
o Segunda iteracin 28/09/2004 Se complemento el documento de anlisis, se agregaron diagramas de casos de uso y su correspondiente documentacin
o Tercera iteracin 02/10/2004 Se corrigi la documentacin de los casos de uso y se cambio el tiempo de respuesta
o Cuarta iteracin 04/10/2004 Se agregaron comentarios referentes al desarrollo del Framework, se corrigi documentacin de los casos de uso
o Quinta iteracin 10/10/2004 Se agregaron casos de uso, y se realiz una identificacin de objetos inicial, con su correspondiente diagrama de dominio
o Sexta iteracin 11/10/2004 Se corrigieron errores en la documentacin
o Sptima iteracin 30/10/2004 Se corrigieron los requerimientos del sistema de acuerdo a la implementacin, adems se agregaron casos de uso y su correspondiente documentacin
o Octava iteracin 28/03/2005 De acuerdo a la recomendacin del comit de investigacin se cambi el trmino e-business por e-commerce.
3 Ciclo
Para el ciclo de Diseo se realizaron 11 iteraciones.
o Primera iteracin 26/10/2004 31 Se realiz una primera versin del documento (borrador) propuesto en el 1 ciclo
o Segunda iteracin 28/10/2004 Se completo la descomposicin por entidades
o Tercera iteracin 31/10/2004 Se agregaron ms entidades, y una descripcin de componentes J 2EE
o Cuarta iteracin 10/11/2004 Se agrego el modelo de datos y su documentacin, se corrigieron algunos errores en la arquitectura
o Quinta iteracin 11/11/2004 Se corrigi el modelo de datos
o Sexta iteracin 20/11/2004 Se agregaron componentes J 2EE (SessionsEJB y EntitiesEJB) y Patrones de Software a la arquitectura
o Sptima iteracin 23/11/2004 Se agreg un ejemplo de creacin de tablas (script) de acuerdo al modelo de datos, se agregaron diagrama de clases de los componentes J 2EE y diagrama de clases
o Octava iteracin 24/11/2004 Se corrigi el modelo de datos
o Novena iteracin 26/11/2004 Se cambio el diagrama de arquitectura, y cambio el diagrama de componentes J 2EE
o Dcima iteracin 27/11/2004 Se mejoro la descripcin de la arquitectura, y algunos diagramas de componentes, se corrigi el modelo de datos
o Undcima iteracin 28/03/2005 De acuerdo a la recomendacin del comit de investigacin se cambi el trmino e-business por e-commerce.
4 Ciclo
Para el ciclo de Implementacin I se realizaron 8 iteraciones.
o Primera iteracin 16/11/2004 Se implementaron las clases correspondientes a la lgica del negocio, la clase ProductoCreator(Factory) y la clase Service Locator 32
o Segunda iteracin 18/11/2004 Se corrigieron errores de configuracin del Service Locator
o Tercera iteracin 22/11/2004 Se corrigieron errores de conectividad del Service Locator
o Cuarta iteracin 26/11/2004 Se implementaron los Session EJB y las bases de datos
o Quinta iteracin 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 diseo
o Sexta iteracin 15/12/2004 Se corrigieron problemas en la funcionalidad de los Session Bean
o Sptima iteracin 20/012005 Se modificaron algunos atributos de las tablas debido a desbordamiento de informacin
o Octava iteracin 31/01/2005 Se realizaron ajustes de acuerdo a las pruebas realizadas.
5 Ciclo
Para el ciclo de Implementacin II se realizaron 6 iteraciones.
o Primera iteracin 28/11/2004 Se implementaron las clases DAO, los Entities CMP y la clase Business Delegate
o Segunda iteracin 3/12/2004 Se corrigieron errores de conectividad y consultas en los DAO
o Tercera iteracin 10/12/2004 Se corrigieron errores en la transaccionalidad de los CMP
o Cuarta iteracin 15/12/2004 Se agregaron mtodos a la clase Business Delegate
o Quinta iteracin 07/01/2005 Se integraron todos los componentes del Framework y la lgica del negocio
o Sexta iteracin 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 iteracin 08/01/2005 Se realiz una primera versin del documento (borrador) propuesto en el 1 ciclo
o Segunda iteracin 22/01/2005 Se realizaron el manual de usuario y el manual de instalacin y configuracin
o Tercera iteracin 25/01/2005 Se realiz la gua de extensin del Framework
o Cuarta iteracin 30/01/2005 Se cambio la estructura de algunas pruebas
o Quinta iteracin 15/02/2005 Se corrigieron errores en los manuales y la gua del Framework
Estas iteraciones fueron realizadas de una manera no lineal y se basaron en el aprendizaje de la iteracin previa. Adems 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 investigacin, ahora describiremos mas detalladamente las siguientes 2 etapas.
La segunda etapa de nuestro proyecto como ya se dijo consisti en la construccin de un Framework para el desarrollo de aplicaciones e-commerce, para la venta de bienes materiales, a consumidores individuales. Aplicando la metodologa gil DAS, se definieron el nmero de ciclos que tendra el desarrollo del Framework. Se realizaron 6 ciclos - el nmero de ciclos aconsejado por J ames Highsmith 26 - de acuerdo a la duracin del proyecto, hasta obtener el producto final acorde a los requerimientos establecidos.
4.1. PLAN DE CICLOS DE DESARROLLO ADAPTABLE
Una vez definido el nmero 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 pasos 27 , se defini una misin ya que el ciclo de vida del desarrollo adaptable, debe estar enfocado en esta, despus se definieron los marcos de tiempo de cada ciclo de trabajo lo cual dependi de los componentes que se desarrollaran 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 tecnolgicas que se usaran y cada uno de los componentes que se desarrollara en cada uno de los ciclos, por ltimo se defini una lista de actividades que cubrira 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 estndar para el desarrollo de las aplicaciones, ya que se enfoca en la administracin de software, y no en una metodologa de desarrollo especfica.
Para la documentacin nos basamos en los estndares de la IEEE, y se manejo un control de versiones para cada uno de ellos.
Despus de definido y aprobado el plan de ciclos de desarrollo adaptable, empezaron los ciclos y las actividades definidas all.
Primero se empez con el ciclo de anlisis de la aplicacin, 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, adems 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 dominios 28 . Anlisis de Requerimientos: Despus de observar varias tiendas de comercio electrnico, en Latinoamrica 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 comn 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 informacin del cliente o Registrar la fecha de backup de la informacin o Registrar una orden de compra enviada o Registrar usuarios en el sistema o Seleccionar forma de pago o Validacin y autenticacin 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.
Despus de esto se identificaron los actores del sistema, estos fueron el administrador y el cliente.
28 Carey, J ames and Carlson, Brent. Framework Process Patterns. 2002 36 Diagrama de Casos de Uso
En este punto se definieron los casos de uso de la aplicacin en su primera versin de acuerdo a los requerimientos obtenidos, y se documentaron de acuerdo a la plantilla de Alistair Cockburn. 29 .
Ilustracin 2. Diagrama de Casos de Uso del Framework
29 http://alistair.cockburn.us 37 Para una informacin mas detallada acerca del anlisis del Framework (Ver Anexo B Anlisis 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. DISEO
El tercer ciclo de la aplicacin, se dedic al diseo de Framework, en esta etapa se defini el modelo de datos que se usara, la arquitectura del sistema, y los diagramas de clases correspondientes a la aplicacin.
Las actividades que se llevaron a cabo en este ciclo son las siguientes: Definicin Modelo de Datos: De acuerdo a los requerimientos definidos en el ciclo de anlisis se diseo un modelo de datos para la aplicacin, en este se especificaron las entidades y sus correspondientes relaciones. El modelo de datos puede verse a continuacin.
Ilustracin 3. Modelo de Datos del Framework
38 Arquitectura del Framework: Para este desarrollo utilizaremos una arquitectura J 2EE, 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 mltiple capas y multired. o Esta constituido por un conjunto de tecnologas estndar, Servlets, EJ B, J SP etc. De acuerdo con esto tendramos la siguiente arquitectura (Ilustracin 4):
Ilustracin 4. Diagrama de Arquitectura del Framework
En este diagrama tenemos que nuestro cliente accedera al sistema por medio de el Business Delegate para obtener la lgica del negocio del sistema, esto puede ser mediante interfaces graficas, J SP dependiendo de las necesidades del cliente, es decir nos da acceso a los servicios del negocio, este a su vez hace una peticin al ServiceLocator el cual es el encargado de ubicar los servicios, este realiza la conexin con la tienda (SessionEJ B), Tienda es de tipo Stateless y Carro de compras StateFul, debido a que necesitamos que este guarde su estado dependiendo de la sesin (cliente), es decir necesitamos que los productos que 39 estn en el carro de algn cliente se mantengan si se presenta algn problema en la sesin (error de conexin), estos productos se eliminarn una vez el cliente haya terminado su sesin. 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 comunicacin con la Base de Datos. El producto depende del tipo de producto que se quiera vender, es decir es configurable segn las necesidades del cliente. Adems 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, adems 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 tambin es configurable por parte del cliente segn el motor de Base de Datos que se vaya a utilizar, como Oracle, SQL Server, Point Base etc.
Tambin 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 J Boss, 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 aplicacin pueda acceder a la Base de Datos. Adems de esto el servidor de aplicaciones esta encargado de realizar el Despliegue (deploy) de la aplicacin.
El Framework cuenta con una clase, NombreReferencia, la cual nos permite configurar los J NDI Names, de la aplicacin.
Patrones: Con el fin de fortalecer el diseo y la implementacin de la aplicacin, se seleccion una serie de patrones acorde al desarrollo del Framework. Dentro de estos patrones se encuentran:
o Business Delegate Para la aplicacin se utiliz una clase Business Delegate 30 la cual es la encargada de proporcionar el acceso a la lgica 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 mtodos de la lgica del negocio.
30 Patrn de Diseo de Software, Larman, Craig. Applying UML and patterns: An introduction to object- oriented 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 dems 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 especficos a travs de la herencia de la clase producto. Para este, las clases de productos especficos que se vayan a crear deben extender de la clase producto, la cual maneja unos atributos y mtodos generales de los productos.
Mdulos: El sistema se dividi en 4 mdulos 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 diseo de las clases se sigui la metodologa propuesta por Bernd Bruegge en su libro Ingeniera de Software Orientada a Objetos 31 , la cual nos dice que deben definirse unas entidades correspondientes a la aplicacin y de acuerdo a las entidades definidas, se construy un diagrama de clase que podemos ver en el disco anexo en la carpeta de grficos.
Para una explicacin mas detallada del ciclo de diseo (Ver Anexo C Diseo Framework).
4.4. IMPLEMENTACION I
El cuarto ciclo de la aplicacin se dedic a la implementacin de la arquitectura y las clases definidas en la fase de diseo. Como primera actividad se defini la implementacin de las clases, correspondientes a las entidades de la aplicacin, a continuacin se definen las clases y los mtodos que se implementaron.
31 BRUEGGE Bernd y DUTOIT Allen, Ingeniera de Software Orientada a Objetos, Capitulo 6. 41
Ilustracin 5. Clases Producto, BackupAdmin, Cliente y Administrador.
Estas clases se implementaron de acuerdo a los objetos identificados en el anlisis y el diseo, estn la clase producto la cual es la encargada de manejar la informacin 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 realizacin de Backup del sistema. 42
Ilustracin 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 fsico la cual hace referencia al producto fsico en s (inventario).
Despus de las clases se implementaron, el patrn Factory y el Service Locator 43
Ilustracin 7. Clases Service Locator y Factory
El patrn Factory nos permite manejar la creacin 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 (patrn Singleton), la cual esta encargada de localizar los servicios y componentes de la aplicacin (lookup) Seguimos con la implementacin de los Session Beans, Un Session EJ B permite realizar cierta lgica solicitada por un cliente ya sea un J SP|Servlet, Applet e inclusive otro EJ B. Existen dos tipos de Session EJ B's: Stateless (Session) EJB's Este tipo de EJ B como su nombre lo indica no mantiene estado ("Stateless") en el "EJ B Container", estos EJ B's son utilizados para realizar tareas rutinarias que no requieren identificar o rastrear al cliente, algunos EJ B's de este tipo son: operaciones matemticas complejas, bsquedas generales, etc. StateFul (Session) EJB's A diferencia de "Stateless (Session) EJ B's" este tipo de EJ B's permiten mantener la sesin del cliente en el "EJ B Container", de esta manera el cliente puede trabajar con cierto juego de datos especfico administrado por el "EJ B Container", la aplicacin ideal para este tipo 44 de EJ B es un componente de compra ("Shopping Cart") el cual puede identificar artculos e informacin personal del cliente a travs de un lapso de tiempo extenso ("Session"). A continuacin veremos los Session EJB, que se implementaron en el desarrollo del Framework.
Ilustracin 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
Ilustracin 9. AdministradorMgr Session EJB. 46
Ilustracin 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.
Ilustracin 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 validacin local de las tarjetas. Este es el encargado de comunicarse con la aplicacin seleccionada para el manejo de los pagos.
Estos Session EJB (Ilustracin 9, 10, 11, 12) fueron los definidos para el Framework. Despus de la implementacin de los Session, se gener un script para la creacin del modelo de datos, este script se realiz para la especificacin Ansi Sql 92. Para ver de forma ms detallada el script y la informacin de las clases (ver Anexo C Diseo Framework o referirse al cdigo adjunto).
48 4.5. IMPLEMENTACION II
En el 5 ciclo se terminaron los componentes que faltaban en la aplicacin. Se escribieron los DAO, los EJ B Entity CMP y EJ B Entity BMP y por ltimo el Business Delegate pagina 47, despus se hizo la integracin de todo el Framework. Los DAO son los encargados de realizar las conexiones a la Base de Datos, de una forma transparente. (Ilustracin 13).
Ilustracin 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 mtodos los cuales son los encargados de realizar las consultas, las inserciones y las actualizaciones respectivas. 49
Ilustracin 13. EJB EntitiesEJB CMP'S
50 Cada uno de estos CMP (Ilustracin 14, 15), esta encargado de manejar la persistencia de la informacin correspondiente, por ejemplo el CMPClienteBean esta encargado de los datos especficos del cliente
Ilustracin 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 mtodos para obtener acceso a los atributos del producto, adems debe implementarse un mtodo 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), permitirn manejar la informacin referente a los productos especficos 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 caractersticas fundamentales que debe tener todo producto. Adems las distintas caractersticas especficas del producto deben agregarse como atributos al BMP, los atributos que se agreguen son opcionales y dependen de la decisin del usuario.
52
Ilustracin 15. Clase Bussines Delegate
53 Por ltimo se implement la clase Business Delegate de acuerdo con lo descrito en la pagina 47.
Para informacin mas detallada acerca de las clases (ver anexo C Diseo Framework o cdigo adjunto). En este ciclo termin la implementacin de nuestro Framework.
4.6. PRUEBAS Y DOCUMENTACION
En el sexto y ltimo ciclo se desarrollaron las pruebas especficas para la aplicacin y se defini la documentacin que se realizara.
4.6.1. Pruebas
Para el desarrollo de las pruebas se defini un plan de pruebas, de acuerdo al estndar IEEE 32 , 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 mdulo, es decir, intentan encontrar casos en que el mdulo no se atiene a su especificacin. 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 mdulo internamente.
Las funciones referentes al producto no fueron probadas, ya que su implementacin depende del cliente.
Para las pruebas se definieron, un objetivo y un alcance con el fin de delimitar, las pruebas que se realizaran. Despus se seleccionaron los procedimientos a ser probados en cada uno de los mdulos, 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 Aprobacin y Fallo. Para obtener informacin detallada del desarrollo de las pruebas (ver Anexo D Pruebas Framework).
4.6.2. Documentacin
Para la documentacin de la aplicacin adems de los entregables de cada uno de los ciclos se definieron tres guas o manuales 33 :
Manual de Usuario Framework.
32 IEEE standard for software test documentation 33 Carey, J ames and Carlson, Brent. Framework Process Patterns. 2002 Pg. 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 descripcin general de las funciones que nos provee el Framework y una pequea descripcin de su funcionalidad.
Manual de Instalacin y Configuracin Framework. Este manual es una gua en la cual se puede observar detalladamente el proceso de instalacin y configuracin de varios de los componentes utilizados en el Framework.
Esta gua se dividi en tres partes ya que son tres los componentes principales a instalar, en cada una de estas se explica detalladamente la instalacin y configuracin de sus componentes.
Base de Datos Servidor de Aplicaciones Aplicacin
En este manual se encuentran ejemplos con un software especfico, de igual manera se dan las pautas generales para que el usuario pueda trabajar en otros programas.
Gua de Extensin Framework. Este manual es una gua en la cual se puede observar detalladamente el proceso de extensin del Framework, con el fin que el usuario, pueda implementar sus propias aplicaciones basndose en la tecnologa usada en el Framework, su documentacin, implementacin y arquitectura.
En esta gua el usuario encontrara la forma de implementar, paso a paso, sus propios productos para la venta en la tienda virtual.
Para obtener informacin detallada acerca de los manuales (ver Anexos E, F, G).
55
5. DESARROLLO DE LA APLICACIN PARA LA VENTA DE DVD
La tercera etapa como se explic en la descripcin del proyecto consisti en el desarrollo de una aplicacin para la venta de DVDs, para el desarrollo de esta se utiliz el Framework construido en la segunda etapa del proyecto, extendiendo de su documentacin y funcionalidad, para esta aplicacin tambin se aplic la metodologa DAS. El producto elegido, en este caso pelculas 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 eleccin.
Como en la etapa anterior se defini el nmero de ciclos que se utilizaran para desarrollar la aplicacin, al igual que en el Framework, se definieron seis ciclos debido a que el tiempo de ejecucin del proyecto era el mismo.
5.1. PLAN DE CICLOS DE DESARROLLO ADAPTABLE
Al igual que en el Framework, al definir el nmero de ciclos se prosigui a realizar el plan de ciclos de desarrollo adaptable (ver Anexo H Plan de Ciclos de Desarrollo Adaptable Aplicacin DVD), de la misma forma que en el plan de ciclos del Framework, se defini una misin para el proyecto, adems se definieron los marcos de tiempo, los objetivos, entregables y actividades que se realizara en cada uno de los ciclos. Los ciclos prcticamente 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 aplicacin los provee el Framework.
El desarrollo de este plan fue ms sencillo ya que se uso el Framework como base. Al igual que en el Framework todos los entregables se basaron en estndares IEEE 34 y se manejo un control de versiones en cada uno de ellos.
5.2. ANALISIS
En este ciclo se defini un dominio de la aplicacin, unos requerimientos y unos casos de uso. El dominio que se selecciono es el de una aplicacin e-commerce que basada en la venta de pelculas de DVD 35 por Internet, la cual maneja registro de usuarios, inventario, rdenes de compra (ventas), detalles del producto y registro de envos.
Despus de esto se definieron los requerimientos correspondientes.
Como primera medida se tiene que esta aplicacin de venta de pelculas en DVD, se basa en el uso del Framework para aplicaciones e-commerce. Los requerimientos funcionales
34 Los estndares IEEE utilizados se pueden consultar en la Bibliografa 35 Disco de video digital 56 abarcan toda la parte que el Framework cubre (ver Anexo B Anlisis Framework). A su vez para esta aplicacin nacen estos requerimientos presentados a continuacin:
Agregar o modificar pelculas DVD del sistema Consultar Inventario de pelculas DVD Consultar pelculas DVD Modificar el stock de pelculas DVD del inventario (Agregar o Disminuir) Ver los detalles de las pelculas DVD
Ilustracin 16. Diagrama Casos de Uso Aplicacin DVD
Como se explic esta aplicacin extiende del Framework por lo cual solo se muestran los casos de uso pertenecientes a la aplicacin. Para ver informacin detallada sobre el ciclo de anlisis (ver Anexo H Anlisis Aplicacin DVD).
5.3. DISEO
Para elaborar el diseo de la Aplicacin de DVD se utiliz el modelo de datos definido en el Framework, ya que este nos provee la informacin requerida para nuestra aplicacin, la nica modificacin que se realiz a este modelo fue la agregacin de una tabla DVD, ya que este ser el producto especfico a vender en la aplicacin, esto podemos verlo en el modelo descrito a continuacin. 57
Ilustracin 17. Modelo de Datos Aplicacin DVD
Utilizamos la arquitectura propuesta en el Framework, para la capa de presentacin, se utilizaron Servlets y J SP y a una de las capas de interaccin se le agregara un BMPDVDProducto.
De acuerdo con este modelo se tiene la siguiente arquitectura: 58 Business Delegate Service Locator uses Session Tienda Session Administrador Session Cliente DAO CMPCliente CMPOrdenCompra CMPProductoFisico CMPTipoTarjeta CMPBackUp * * * * * * * * * * * * * * * * * * * * * * SessionKart * * * * Data * * * * * * * * * * * * * * BMPDvdProducto * * * * Cliente * * * * * * * * Presentacin Interaccin Logica del Negocio EIS Interaccin Servlets JSP * * * *
Ilustracin 18. Diagrama de Arquitectura Aplicacin DVD
En este diagrama tenemos que nuestro cliente acceder al sistema por medio de Internet y los J SP, estos se comunican con los Servlets los cuales utilizan el Business Delegate para obtener la lgica del negocio del sistema, adems se agregara un Entity BMP llamado BMPDVDProducto, el cual se encarga de la comunicacin y el manejo de la informacin 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 aplicacin (solamente se muestran las clases que tendrn algn 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 configuracin de la aplicacin
Para ver informacin detallada sobre el ciclo de diseo (ver Anexo H Diseo Aplicacin DVD).
5.4. IMPLEMENTACION I En esta fase se implementaron y reutilizaron, las clases y los EJ B de la aplicacin modificndolos si era necesario. Se cre la clase DVD que extiende de producto y se modificaron el producto creador, el Service Locator. 59
Ilustracin 19. Clase DVD y ProductoCreator
Adems se modificaron los Session EJ B y la base de datos segn el modelo de datos.
Para ver ms detalladamente estas modificaciones, (ver cdigo de la Aplicacin Adjunto).
5.5. IMPLEMENTACION II
En este ciclo se modificaron los DAOs y el Business Delegate, se implement el BMP y los Servlets y J SPs.
Ilustracin 20. Clase DAOProductos Aplicacin 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 patrn DAO para esto, adems se le agregaron los mtodos necesarios a los dems DAOs y al Business Delegate, para completar la funcionalidad de la aplicacin desarrollada, especficamente la que corresponde a los productos.
61
Ilustracin 21. BMPDVDProducto Aplicacin DVD 62 En este Entity CMP (Ilustracin 23) se declararon los 3 atributos obligatorios detallados en el diseo del Framework, el Id. del Producto, el nombre y su correspondiente precio, Adems de los atributos especficos del producto.
En este bean tambin se debe implementar una funcin constructora (create) y un buscador (finder) con el fin de encontrar y cargar los correspondientes productos.
63
Ilustracin 22. Clase BusinessDelegate Aplicacin DVD 64
Ilustracin 23. Clase Servlet Aplicacin DVD
Se cre una clase ServletDvd, la cual es la encargada de manejar las peticiones y respuestas va Internet
Para ms detalles sobre la implementacin (ver el cdigo de la aplicacin adjunto).
5.6. PRUEBAS Y DOCUMENTACION
De la misma forma que en el Framework en el sexto y ltimo ciclo se desarrollaron las pruebas especficas para la aplicacin y se defini la documentacin que se realizara.
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 especficamente para la aplicacin. Se realizaron las mismas pruebas del Framework, ms los casos de prueba nuevos.
5.6.2. Documentacin
Para la documentacin se definieron dos manuales, un manual de usuario y un manual de instalacin y configuracin. Para ver informacin detallada de los manuales y las pruebas (ver Anexos K, L, M).
65
6. CONCLUSIONES Y RECOMENDACIONES
Debido a que la metodologa gil DAS se basa en la administracin 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 aplicacin Web de administracin y venta de pelculas DVD, fueran manejados de manera simple y gil debido al ciclo de vida que presenta la metodologa DAS, donde alguna modificacin, cambio o mejora al componente que se va a entregar al finalizar el ciclo, se realiza mediante una iteracin al ciclo que es afectado nicamente y no una revisin exhaustiva a todo el proyecto.
La metodologa DAS basada en la adaptabilidad al cambio y no en la prevencin de ste, promueve reuniones peridicas para mirar el avance del proyecto, es aqu donde uno de los principales factores para que los cambios se realizaran rpidamente en el desarrollo del Framework y de la aplicacin Web, fueron las constantes reuniones que se llevaron a cabo en el proyecto (cada 15 das). Esto permiti detectar errores en el proceso de desarrollo de forma rpida, al identificar los problemas o cambios oportunamente se hizo mucho ms manejable su solucin, 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 iteracin en el diseo y por lo tanto en la implementacin, 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 pequeos problemas a solucionar, esto hizo ms manejable y sencillo el desarrollo del proyecto. El proyecto fue dividido en tres partes, la investigacin, el desarrollo del Framework y el desarrollo de la aplicacin. Para el desarrollo del Framework y de la aplicacin, fueron seleccionados 6 ciclos, donde cada uno de los ciclos era un pequeo problema a solucionar. El manejo de los ciclos como lo presenta DAS, permiti una mayor organizacin, ya que cada uno de los ciclos fue planeado y enfocado a una misin.
La metodologa 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 anlisis, diseo y pruebas y componentes desarrollados en los ciclos de implementacin fueron mejorados y refinados en cada iteracin, como lo presenta DAS para la etapa de aprendizaje y en las reuniones peridicas que deben realizarse para mirar el seguimiento y avance del proyecto.
66 Uno de los principales obstculos del proyecto, fue el no tener un cliente ya que debido a esto toda la parte del anlisis de requerimientos debi tratarse de una forma poco comn (visitar tiendas virtuales), esto llev a desacuerdos en cuanto a los requerimientos que se cubriran. A pesar de esto se seleccionaron los requerimientos a comn acuerdo ms importantes basndonos en el dominio definido en la aplicacin, de aqu la importancia de la definicin del dominio acorde con lo que se quiere realizar en la aplicacin.
Una de las grandes complicaciones que dificult la investigacin y el desarrollo del proyecto, fue la falta de muchos recursos y la reciente metodologa 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 artculos encontrados sobre esta metodologa, no son explicativos sino informativos, lo que quiere decir que nombran la metodologa y las explicaciones son superficiales, con el fin de atraer al lector, pero no profundizar en la metodologa de desarrollo adaptable. Se dice que lo ms difcil es comenzar, por lo que iniciar el proyecto usando DAS, fue difcil sin tener una gua o proyecto anterior, pero a medida que el proyecto avanzaba, el desarrollo del proyecto se hizo ms fcil 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 metodologa de construccin de software, o en las buenas practicas de programacin como Extreme Programming, este se basa en la administracin de proyectos de software, ya que intenta solucionar el constante cambio de los proyectos
Adaptable y tolerante al cambio La metodologa 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 aplicacin 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 iteracin en el diseo y por lo tanto en la implementacin, estas iteraciones fueron manejadas mediante un control de cambios que se maneja en cada uno de los documentos.
Ciclos manejados por una misin La metodologa 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 misin a seguir. La misin deber abarcar el problema a tratar lo ms que se pueda, dando una gua 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 definicin de la misin la propone DAS, haciendo referencia a como una empresa trabaja, es decir, el ejemplo de una empresa que tiene su misin apenas es creada para que sus objetivos 67 puedan cumplirse y muestre los beneficios al final de cada ao. De esta manera DAS, da una idea de cmo al final de cada ciclo los objetivos pueden llegar a cumplirse. La planeacin de los ciclos fue de vital importancia a la hora de desarrollar el componente de determinado ciclo. Dentro de la planeacin de cada ciclo se determinaba una misin, 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 metodologa DAS define que en cada uno de los ciclos se haga entrega de un componente, es decir que para cada iteracin se obtenga un entregable mejor al anterior. Para DAS el cliente es lo ms importante, por lo que se debe tener al cliente totalmente satisfecho a largo del ciclo de vida del desarrollo de la aplicacin 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 opinin. En el desarrollo del Framework y de la aplicacin e- commerce cada iteracin 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 metodologa est basada en componentes permiti que el desarrollo del Framework siendo una aplicacin tan extensa y compleja, se dividiera en pequeos problemas a solucionar, con soluciones ms 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 organizacin para cada uno de los entregables realizados. En ningn momento el desarrollo de algn 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 planeacin de todo el proyecto, ya que gener una planeacin por partes y no una global que es ms compleja de realizar y monitorear. En cada uno de los ciclos la planeacin facilit la reparticin de las actividades a realizar para cada uno de los implicados en el proyecto y facilit la estimacin de tiempo para cada ciclo.
Establece colaboracin por parte del usuario al equipo de trabajo y viceversa. Este es un factor destacado en la metodologa DAS, ya que en todo momento existe un acercamiento con el cliente. Esto permite que el cliente exprese sus ideas de cmo le gustara 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 informacin suficiente a medida que avanza el proyecto.
La satisfaccin del cliente es lo primordial Para DAS, aparte de las diferentes caractersticas para el desarrollo de una aplicacin y la metodologa a seguir para cada uno de los ciclos, es primordial y fundamental que todo el desarrollo de alguna aplicacin este enfocado a la satisfaccin del cliente por 68 encima de todo. Segn esta metodologa, no habr un buen resultado si el cliente no esta de acuerdo con la entrega final. Para el desarrollo del Framework y de la aplicacin e- commerce de venta de pelculas 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 metodologa 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 aplicacin, se puede decir que l no es un usuario, sino parte del equipo de trabajo, ya que su colaboracin es de vital importancia para obtener un resultado final satisfactorio. Para este proyecto, fue fcil notar esto, ya que en el desarrollo del Framework y de la aplicacin 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 ms fcil obtenerlo si el cliente y el equipo de trabajo, se unen para trabajar en uno solo.
Metodologa realmente nueva El desarrollo adaptable de software es una metodologa gil, esto hace en principio que se tome como una metodologa realmente nueva. Es una metodologa 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 discusin y proyectos realizados por DAS eran pocos, lo que hizo menos fcil el desarrollo de estas dos aplicaciones.
Pocos desarrollos en Colombia usando como metodologa el desarrollo adaptable de software Debido a que es una metodologa nueva en el mbito del desarrollo de software como se menciona anteriormente, cabe anotar que en Colombia el desarrollo de proyectos usando como metodologa de desarrollo DAS es muy poco como pudimos observar a travs de la consulta de algunas empresas que desarrollan software en Bogota, por ende se hizo difcil un contacto personal, con el fin de encontrar puntos de vista sobre esta metodologa no implantada en proyectos colombianos, y experiencias obtenidas en sus propios desarrollos de aplicaciones.
Poca documentacin La documentacin obtenida sobre esta metodologa adaptable es realmente poca, lo que hace difcil la investigacin de la metodologa, artculos, casos de estudio y textos gua. Realmente el libro que muestra la metodologa es uno solo 36 . Los artculos encontrados sobre esta metodologa, no son explicativos sino informativos, lo que quiere decir que nombran la metodologa y las explicaciones son superficiales, con el fin de atraer al lector, pero no profundizar en la metodologa de desarrollo adaptable.
36 J ames 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 cmo 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 disear software. Pero, Cmo es posible crear una aplicacin que nos provea un ncleo de funcionalidad, que nos permita construir distintas aplicaciones a travs de ste?
El proceso de desarrollo del Framework, debe basarse en las instancias comunes del desarrollo de software, Anlisis, Diseo, Implementacin, etc. Pero cada una de estas etapas debe realizarse de una manera ms profunda y detallada (en algunos casos se realizan actividades especificas para el Framework), debido a la necesidad de reutilizacin propia del Framework. Al igual que las otras aplicaciones, es importante la iteracin 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 anlisis y al diseo de la aplicacin, ya que debe definirse un dominio claro y conciso. Esto debido a que es imposible desarrollar un ncleo 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 disear el Framework, debe definirse claramente que componentes o mdulos sern configurables, ya que estos son los que mayor atencin deben tener, debido a que en ellos recae la correcta reutilizacin de la aplicacin.
Para esta clase de desarrollos es necesario apoyarse en una gran cantidad de patrones, los cuales garanticen el correcto desarrollo de la aplicacin. Para esto se seleccionaron los patrones que solucionan determinada problemtica en el desarrollo de la aplicacin.
Una de las principales diferencias cuando se desarrolla un Framework contra cualquier otra clase de software es la importancia de la documentacin. Ya que con el Framework la documentacin 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 explcito de la aplicacin contra el Framework, a medida que el mapeo se haga mas temprano en el proceso de desarrollo de la aplicacin, mayor ser el uso que se le de al Framework, hasta llegar a su mayor capacidad.
Los usuarios del Framework, deben basar su documentacin en la del Framework, esta debe ser el punto de partida y debe expandirse a los requerimientos especficos de la aplicacin.
En conclusin al construir aplicaciones reutilizables, debe analizarse especficamente el nivel de reutilizacin que se quiere obtener de dicha aplicacin, 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 mximo, y pueda sacar el mayor provecho de este.
71
TRABAJO A FUTURO
A un futuro debe mejorarse el diseo grfico de la aplicacin DVD ya que el realizado solo se hizo para probar la funcionalidad de la aplicacin 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 electrnico.
La aplicacin podr ser complementada con el desarrollo correspondiente al alquiler de bienes materiales.
Reutilizacin del Framework para otro producto diferente.
72
BIBLIOGRAFIA
[1] AMOR, Daniel. The E-Business Revolution, 1999.
[2] BRUEGGE Bernd y DUTOIT Allen, Ingeniera de Software Orientada a Objetos.
[3] Carey, J ames y Carlson, Brent. Framework Process Patterns.
[4] Asociacin Colombiana de Ingenieros de Sistemas, www.acis.org, 5 mayo de 2004.
[5] FOWLER, Martin y HIGHSMITH, J ames. 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] Gua al Software Engineering Book of Knowledge, www.swebok.org.
[8] HAMEL, Sylvian y HIGHSMITH, J ames. Optimize or Apapt En Software Development Magazine, Abril de 2000.
[9] HIGHSMITH, J ames. Adaptive Software Development, A collaborative approach to managing complex systems, 2001.
[10] HIGHSMITH, J ames. Agile Software Development: The Business of Innovation. En Institute of Electrical and Electronics Engineers (IEEE) magazine, Septiembre de 2001.
[11] HIGHSMITH, J ames. Agile Software Development: The People Factor. En Institute of Electrical and Electronics Engineers (IEEE) magazine, Noviembre de 2001.
[12] HIGHSMITH, J ames. Project Management at the edge. The It Project Leader Magazine, Febrero de 2000.
[13] HIGHSMITH, J ames. Retiring Lifecycle Dinosaur. En Software and Testing & Quality Engineering, Agosto de 2000.
[14] HIGHSMITH, J ames. 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.