Tesis 192

DESARROLLO ADAPTABLE DE SOFTWARE, UNA SOLUCIN
GIL PARA APLICACIONES E-COMMERCE

DIEGO ANDRS GONZLEZ MORENO

JOS LUIS PEREA LVAREZ

PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERA
CARRERA DE INGENIERA DE SISTEMAS
BOGOTA D.C.
2005

DESARROLLO ADAPTABLE DE SOFTWARE, UNA SOLUCIN
GIL PARA APLICACIONES E-COMMERCE

DIEGO ANDRS GONZLEZ MORENO

JOS LUIS PEREA LVAREZ

Proyecto de grado presentado para optar el ttulo de Ingeniero de Sistemas

Director

MIGUEL EDUARDO TORRES MORENO

Ingeniero de Sistemas.

BOGOTA D.C.
2005




Rector magnfico: R.P. Gerardo Remolina Vargas, S.J .

Decano acadmico: Ing. Francisco J avier Rebolledo Muoz

Decano del Medio Universitario: R.P. Antonio J os Sarmiento Nova, S.J .

Director de Carrera: Ing. Hilda Cristina Chaparro Lpez

Director Departamento: Ing. Germn Alberto Chavarro Flrez

Nota de aceptacin

____________________________________________________
____________________________________________________
____________________________________________________

______________________________________
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
and Electronics Engineers (IEEE) magazine, Septiembre de 2001.
11
HIGHSMITH, J ames. Requirements Engineering and Agile Software development. 2001.
12
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
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
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
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
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
22
23
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
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.

Se realiz una primera versin del documento (borrador) propuesto en el 1
ciclo

Se complemento el documento de anlisis, se agregaron diagramas de casos
de uso y su correspondiente documentacin

Se corrigi la documentacin de los casos de uso y se cambio el tiempo de
respuesta

Se agregaron comentarios referentes al desarrollo del Framework, se corrigi
documentacin de los casos de uso

Se agregaron casos de uso, y se realiz una identificacin de objetos inicial,
con su correspondiente diagrama de dominio

Se corrigieron errores en la documentacin

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
trmino e-business por e-commerce.

3 Ciclo

Para el ciclo de Diseo se realizaron 11 iteraciones.

31
ciclo

Se completo la descomposicin por entidades

Se agregaron ms entidades, y una descripcin de componentes J 2EE

Se agrego el modelo de datos y su documentacin, se corrigieron algunos
errores en la arquitectura

Se corrigi el modelo de datos

Se agregaron componentes J 2EE (SessionsEJB y EntitiesEJB) y Patrones de
Software a la arquitectura

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

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
trmino e-business por e-commerce.

4 Ciclo

Para el ciclo de Implementacin I se realizaron 8 iteraciones.

Se implementaron las clases correspondientes a la lgica del negocio, la
clase ProductoCreator(Factory) y la clase Service Locator
32

Se corrigieron errores de configuracin del Service Locator

Se corrigieron errores de conectividad del Service Locator

Se implementaron los Session EJB y las bases de datos

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

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

Se realizaron ajustes de acuerdo a las pruebas realizadas.

5 Ciclo

Para el ciclo de Implementacin II se realizaron 6 iteraciones.

Se implementaron las clases DAO, los Entities CMP y la clase Business
Delegate

Se corrigieron errores de conectividad y consultas en los DAO

Se corrigieron errores en la transaccionalidad de los CMP

Se agregaron mtodos a la clase Business Delegate

Se integraron todos los componentes del Framework y la lgica del negocio

Se realizaron ajustes de acuerdo a las pruebas realizadas.

33
6 Ciclo

Para el ciclo de Pruebas se realizaron 5 iteraciones.

ciclo

Se realizaron el manual de usuario y el manual de instalacin y
configuracin

Se realiz la gua de extensin del Framework

Se cambio la estructura de algunas pruebas

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.

26
J ames Highsmith, Adaptive Software Development, 2000
27
35
4.2. ANALISIS

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
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
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.

74

Tesis 192

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tesis 192

Încărcat de

Drepturi de autor:

Formate disponibile

DESARROLLO ADAPTABLE DE SOFTWARE, UNA SOLUCIN

GIL PARA APLICACIONES E-COMMERCE

S-ar putea să vă placă și