Instituto tecnolgico de Cancn

Ingeniera de Software

Unidad 2
Metodologas de Desarrollo

Integrantes
Jesus Gudalupe Centeno Centeno
Roberto Misael Rubio Vazque
Manuel Espinosa Cetina
David Orlando Moguel Balam

NDICE
INTRODUCCIN............................................................................................................... 3
2.1 METODOLOGAS CLSICAS........................................................................................ 3
2.1.1 CASCADA................................................................................................................ 4
2.1.2 INCREMENTAL......................................................................................................... 7
2.1.3 DESARROLLO EVOLUTIVO..................................................................................... 10
2.1.4 DESARROLLO EN ESPIRAL..................................................................................... 14
2.1.5 DESARROLLO DE PROTOTIPOS............................................................................18
2.1.6 DESARROLLO BASADO EN COMPONENTES...........................................................21
2.2 OTRAS METODOLOGAS........................................................................................... 25
2.2.1GANAR-GANAR (WIN & WIN).................................................................................... 26
2.2.2 PROCESO UNIFICADO (UP).................................................................................... 28
2.2.3 INGENIERA WEB................................................................................................... 42
2.2.4 METODOLOGAS GILES........................................................................................ 53
2.2.5 METODOLOGAS EMERGENTES............................................................................. 58
2.2.6 REINGENIERIA..................................................................................................... 71
Conclusin...................................................................................................................... 75
Bibliografa...................................................................................................................... 76
Glosario.......................................................................................................................... 77

INTRODUCCIN

En esta unidad aprenderemos sobre las metodologas de desarrollo, como es que

funcionan cada una de ellas e identificar las principales caracterstica que tienen los
diferentes modelos entre los modelos y similitudes Para la creacin y desarrollo de
aplicacin o software permitiendo saber sus procesos en la implementacin de sus
metodologas. Cada metodologa tiene sus ventajas y desventajas de acuerdo al modelo
que se vaya a realizar

2.1 METODOLOGAS CLSICAS

Los modelos de proceso dependen de las opiniones o creencias de las personas

involucradas en un proyecto. Por ejemplo, algunas de estas opiniones o creencias
implican que es necesario comprender el problema antes de desarrollar una solucin, el
proceso para resolver un problema debe dar un resultado predecible (sin importar qu
individuo hace el trabajo), es indispensable planear y calcular el proceso con gran
precisin, para que proceso tenga xito es importante evaluar y administrar el riesgo y la
entrega de etapas intermedias bien definidas aumenta la confianza que se tiene en el
resultado final. A continuacin se describen los modelos de procesos clsicos,
analizando las creencias en las cuales se basan.

2.1.1 CASCADA

En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada,

es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el
desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la
finalizacin de la etapa anterior.
Un ejemplo de una metodologa de desarrollo en cascada es:
Anlisis de requisitos.
Diseo del Sistema.
Diseo del Programa.
Codificacin.
Pruebas.
Implantacin.
Mantenimiento.
De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce
necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los
costos del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la
gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de
un proyecto.
Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria, sigue
siendo el paradigma ms seguido al da de hoy.
Fases del modelo.

El "modelo cascada" sin modificar. El progreso fluye de arriba hacia abajo, como una
cascada.

Anlisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD
(documento de especificacin de requisitos), que contiene la especificacin completa de lo
que debe hacer el sistema sin entrar en detalles internos.
Es importante sealar que en esta etapa se debe consensuar todo lo que se requiere del
sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose requerir
nuevos resultados a mitad del proceso de elaboracin del software.
Diseo del Sistema
Descompone y organiza el sistema en elementos que puedan elaborarse por separado,
aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD
(Documento de Diseo del Software), que contiene la descripcin de la estructura
relacional global del sistema y la especificacin de lo que debe hacer cada una de sus
partes, as como la manera en que se combinan unas con otras.

Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El

primero de ellos tiene como objetivo definir la estructura de la solucin (una vez que la
fase de anlisis ha descrito el problema) identificando grandes mdulos (conjuntos de
funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura
de la solucin elegida. El segundo define los algoritmos empleados y la organizacin del
cdigo para comenzar la implementacin.
Diseo del Programa
Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los
requerimientos del usuario as como tambin los anlisis necesarios para saber que
herramientas usar en la etapa de Codificacin.
CODIFICACIN
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como
de pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y
componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea
un proceso mucho ms rpido.
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba
que funciona correctamente y que cumple con los requisitos, antes de ser entregado al
usuario final.
Verificacin
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya
realizaron exhaustivas pruebas para comprobar que el sistema no falle.
En la creacin de desarrollo de cascada se implementa los cdigos de investigacin y
pruebas del mismo
Mantenimiento
Una de las etapas ms crticas, ya que se destina un 75% de los recursos, es el
mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no
cumpla con todas nuestras expectativas.

Variantes
Existen variantes de este modelo; especialmente destacamos la que hace uso de
prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento,
verificando que el sistema final est libre de fallos.
Desventajas
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala
implementacin del modelo, lo cual hace que lo lleve al fracaso.
El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso
de prueba y hasta que el software no est completo no se opera. Esto es la base para que
funcione bien.
Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al
rediseo y nueva programacin del cdigo afectado, aumentando los costos del
desarrollo.
2.1.2 INCREMENTAL
El modelo incremental fue propuesto por Harlan Mills en el ao 1980.
Surgi el enfoque incremental de desarrollo como una forma de reducir la repeticin del
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en
los requisitos hasta adquirir experiencia con el sistema. Este modelo se conoce tambin
bajo las siguientes denominaciones:
Mtodo de las comparaciones limitadas sucesivas.
Mtodo de atacar el problema por ramas.
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofa
interactiva de Construccin de Prototipos. El modelo incremental aplica secuencias
lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada
secuencia lineal produce un incremento del software. El primer incremento generalmente
es un producto esencial denominado ncleo.
En una visin genrica, el proceso se divide en 4 partes:
Anlisis
Diseo

Cdigo
Prueba

Sin
embargo, para la produccin del Software, se usa el principio de trabajo en cadena o
Pipeline. Con esto se mantiene al cliente en constante contacto con los resultados
obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al
final de cada incremento a fin de que el software se adapte mejor a sus necesidades
reales. El proceso se repite hasta que se elabora el producto completo. De esta forma el
tiempo de entrega se reduce considerablemente.
El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento
la entrega de un producto completamente operacional. Este modelo es particularmente til
cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los
pueden realizar un grupo reducido de personas y en cada incremento se aadir personal,
de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos
tcnicos.
Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al final
terminar siendo la solucin completa requerida por el cliente, pero stas partes no se
pueden realizar en cualquier orden, sino que dependen de lo que el cliente este
necesitando con ms urgencia, de los puntos ms importantes del proyecto, los
requerimientos ms bsicos, difciles y con mayor grado de riesgo, ya que estos se deben
hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada versin.

De este modo podemos terminar una aplicacin ejecutable (primera versin) que podr
ser entregada al cliente para que ste pueda trabajar en ella y el programador pueda
considerar las recomendaciones que el cliente efecte para hacer mejoras en el producto.
Estas nuevas mejoras debern esperar a ser integradas en la siguiente versin junto con
los dems requerimientos que no fueron tomados en cuenta en la versin anterior.
El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del
sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio
ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una
vez entregado un incremento, no se realizan cambios sobre el mismo, sino nicamente
correccin de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial,
es necesario conocer los requerimientos completos al comienzo del desarrollo.

Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las
funcionalidades que proporcionar el sistema. Se confecciona un bosquejo de requisitos
funcionales y ser el cliente quien se encarga de priorizar que funcionalidades son mas
importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de
incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que
el sistema entregar. La asignacin de funcionalidades a los incrementos depende de la
prioridad dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con
el primer incremento.
Caractersticas
Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta
frecuencia.
El usuario se involucra ms.
Difcil de evaluar el costo total.
Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar
como un todo.
Requiere gestores experimentados.
Los errores en los requisitos se detectan tarde.
El resultado puede ser positivo.

Ventajas

Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se

implementa la funcionalidad parcial.

Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana

de partes operativas del software.

El modelo proporciona todas las ventajas del modelo en Cascada realimentado,

reduciendo sus desventajas slo al mbito de cada incremento.

Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.

Desventajas:

El modelo incremental no es recomendable para casos de sistemas de tiempo real,

de alto nivel de seguridad, de procesamiento distribuido y/o de alto ndice de

riesgos.
Requiere de mucha planeacin, tanto administrativa como tcnica.
Requiere de metas claras para conocer el estado del proyecto.

2.1.3 DESARROLLO EVOLUTIVO

Un modelo de desarrollo es una representacin abstracta de un proceso de software, cada
modelo representa el proceso de desarrollo de software de una manera en particular. A
pesar de estar definidos claramente, no representan necesariamente la realidad de cmo
se debe desarrollar el software, sino que establece un enfoque comn. Un modelo puede
ser modificado y adaptado de acuerdo a las necesidades del software en desarrollo.
Desarrollo Evolutivo
El desarrollo evolutivo consta del desarrollo de una versin inicial que luego de exponerse
se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del
cliente o del usuario final. Las fases de especificacin, desarrollo y validacin se
entrelazan en vez de separarse.
Existen dos tipos de desarrollo evolutivo:
1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para
explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las
partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos
atributos propuestos por el cliente.
2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es
comprender los requerimientos del cliente y entonces desarrollar una definicin mejorada

de los requerimientos para el sistema. El prototipo se centra en experimentar con los

requerimientos del cliente que no se comprenden del todo.
Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer ms
ventajas en comparacin con un enfoque en cascada ya que el sistema se va ajustando a
las necesidades del cliente, a la vez que l mismo entiende mejor sus propios
requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva de ingeniera y
gestin suele tener dos grandes problemas:
1. El proceso no es visible. Los administradores tienen que hacer entregas regulares para
medir el progreso. Si los sistemas se desarrollan rpidamente, no es rentable producir
documentos que reflejen cada versin del sistema.
2. A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden
a corromper la estructura del software. Incorporar cambios en l se convierte cada vez
ms en una tarea difcil y costosa.
Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para
sistemas pequeos y medianos. En los sistemas grandes, los constantes cambios en el
desarrollo solo dificultan la estabilidad y la integracin de los avances de los distintos
grupos de trabajo que puedan existir. La mayora de las empresas que desarrollan
grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques
evolutivos y de cascada.
Etapas del modelo evolutivo Basado en Componentes
PLANEACION: En esta etapa evala la funcin y el rendimiento que se asignaron al
Software durante la Ingeniera del Sistema de Computadora para establecer un mbito de
proyecto que no sea ambiguo, e incomprensible.
ANLISIS DE RIESGOS: en esta etapa l analista se encarga de analizar los riesgos que
el software a crear estar expuesto y as encontrar la manera de corregirlos.
CONSTRUCCIN Y ADAPTACIN DE LA INGENIERA: en esta etapa se construye el
software, se prueba si no tiene algn problema o para detectar errores, se instala, y luego
se le brinda soporte al cliente.
VALUACIN DEL CLIENTE: el cliente tiene la tarea de evaluar el software para verificar si

este cumple con los requisitos que este proporciono y est en todo la tarea de aprobar o
rechazar el software.

Caractersticas
Es evolutivo
Posee un enfoque evolutivo para la creacin de software
Comienza con la identificacin de las clases ms importantes
Examina los datos que se van a manejar
Permite la reutilizacin del software
El ensamblaje de los componentes reduce el 70 del 100% del tiempo del ciclo del
desarrollo del software y un 84 del 100% del costo del proyecto.

Ventajas

Desventajas

Ventajas

Reutilizacin del software.

Simplifica las pruebas; pues
estas se le hacen a los
componentes antes de probar el
conjunto completo de
componentes ensamblados.
Simplifica el mantenimiento del
sistema.
Mayor calidad.

Desventajas

Genera mucho tiempo

en el desarrollo del
sistema.
Modelo costoso.
Requiere experiencia en
la identificacin de
riesgos.
Genera mucho trabajo
adicional.

Ejemplo:

Un procesador de texto que sea desarrollado bajo el paradigma Incremental podra

aportar, en principio, funciones bsicas de edicin de archivos y produccin de
documentos (algo como un editor simple). En un segundo incremento se le podra agregar
edicin ms sofisticada, y de generacin y mezcla de documentos. En un tercer
incremento podra considerarse el agregado de funciones de correccin ortogrfica,
esquemas de paginado y plantillas; en un cuarto capacidades de dibujo propias y
ecuaciones matemticas. As sucesivamente hasta llegar al procesador final requerido.
As, el producto va creciendo, acercndose a su meta final, pero desde la integra del
primer incremento ya es til y funcional para el cliente, el cual se observa una respuesta
rpida en cuanto a entrega temprana; sin notar que la fecha lmite del proyecto puede no
estar acotada ni tan definida, lo que da margen de operacin y alivia presiones al equipo
de desarrollo.

Conclusin:
Este modelo se encarga de poder modificar o cambiar algn software que est en
funcionamiento ponindole o diseando mejoras para este con el fin de brindar un
satisfaccin en tiempo evolutivo para el cliente y que sea de su agrado
2.1.4 DESARROLLO EN ESPIRAL
El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera
vez porBarry Boehm en 1986, utilizado generalmente en la ingeniera de software. Las
actividades de este modelo se conforman en una espiral, en la que cada bucle
o iteracin representa un conjunto de actividades. Las actividades no estn fijadas a
ninguna prioridad, sino que las siguientes se eligen en funcin del anlisis de riesgo,
comenzando por el bucle interior.
Boehm, autor de diversos artculos de ingeniera del software; modelos de estimacin de
esfuerzo y tiempo que se consume en hacer productos software; y Modelos de Ciclo de
Vida; ide y promulg un modelo desde un enfoque distinto al tradicional en Cascada: El
Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta
fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se
comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo ms
asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el
software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra
vuelta de la espiral, as hasta que llegue un momento en el que el producto software
desarrollado sea aceptado y no necesite seguir mejorndose con otro nuevo ciclo.
Ciclos o Iteraciones:
En cada vuelta o iteracin hay que tener en cuenta:
Los Objetivos: qu necesidad debe cubrir el producto.
Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde
diferentes puntos de vista como pueden ser:
1.

Caractersticas: experiencia del personal, requisitos a cumplir, etc.

2.

Formas de gestin del sistema.

3.

Riesgo asumido con cada alternativa.

Desarrollar y Verificar: Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:

Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La

espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la
angular:
1.

Angular: Indica el avance del proyecto del software dentro de un ciclo.

2.

Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteracin se

pasa ms tiempo desarrollando.

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por
ejemplo, la creacin de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestin de riesgo se dice que uno de los
aspectos fundamentales de su xito radica en que el equipo que lo aplique tenga la
necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.
Tareas
Para cada ciclo habr cuatro actividades:
1.

Determinar Objetivos.

2.

Anlisis del riesgo.

3.

Planificacin.

4.

Desarrollar y probar.

Determinar o fijar objetivos

Fijar tambin los productos definidos a obtener: requerimientos, especificacin, manual
de usuario.

Fijar las restricciones.

Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos.

Hay una cosa que solo se hace una vez: planificacin inicial.

Anlisis del riesgo

Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos
no deseados y los daos y consecuencias que stas puedan producir.

Planificar
Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las
fases siguientes y planificamos la prxima actividad.
Desarrollar, verificar y validar (probar)
Tareas de la actividad propia y de prueba.

Anlisis de alternativas e identificacin resolucin de riesgos.

Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo para el

desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo,
cascada, etc. As si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un
modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. Si lo
riesgos de proteccin son la principal consideracin, un desarrollo basado en
transformaciones formales podra ser el ms apropiado.
Mecanismos de control

La dimensin radial mide el coste.

La dimensin angular mide el grado de avance del proyecto.

Ventajas
El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los
restantes modelos.

Reduce riesgos del proyecto

Incorpora objetivos de calidad
Integra el desarrollo con el mantenimiento, etc.

Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la
metodologa, ya que este ciclo de vida no es rgido ni esttico.
Desventajas

Inconvenientes

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso
Requiere experiencia en la identificacin de riesgos

Planificar un proyecto con esta metodologa es a menudo imposible, debido a la

incertidumbre en el nmero de iteraciones que sern necesarias. En este contexto la
evaluacin de riesgos es de la mayor importancia y, para grandes proyectos, dicha
evaluacin requiere la intervencin de profesionales de gran experiencia.
Ejemplo:

El Modelo Espiral es particularmente apto para el desarrollo de Sistemas Operativos

(complejos); tambin en sistemas de altos riesgos o crticos (Ej. navegadores y
controladores aeronuticos) y en todos aquellos en que sea necesaria una fuerte gestin
del proyecto y sus riesgos, tcnicos o de gestin.
Conclusin:
Las actividades de este modelo se conforman en una espiral, en la que cada bucle o
iteracin representa un conjunto de actividades. Las actividades no estn fijas a ninguna
prioridad, sino que las siguientes se eligen en funcin del anlisis de riesgo, comenzando
por el bucle interior
Conformado por ciclos o interacciones, los objetivos que son las necesidades que deben
cubrir los productos. Las alternativas son las diferentes formas de conseguir los objetivos.
De igual forma se involucra el desarrollo y la verificacin que se en carga de programar y
probar el software, por otro lado Si el resultado no es el adecuado o se necesita
implementar mejoras o funcionalidades:
Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral
tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la
angular.

2.1.5 DESARROLLO DE PROTOTIPOS

El Modelo de prototipos, en Ingeniera de software, pertenece a los modelos de desarrollo
evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas
adecuados y no se debe utilizar muchos recursos.
El diseo rpido se centra en una representacin de aquellos aspectos del software que
sern visibles para el cliente o el usuario final. Este diseo conduce a la construccin de
un prototipo, el cual es evaluado por el cliente para una retroalimentacin; gracias a sta
se refinan los requisitos del software que se desarrollar. La interaccin ocurre cuando el
prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo
tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a
corto plazo.
Etapas

Plan rpido
Modelado, diseo rpido
Construccin del Prototipo
Desarrollo, entrega y retroalimentacin
Comunicacin

Este modelo es til cuando el cliente conoce los objetivos generales para

Ventajas

el software, pero no identifica los requisitos detallados de entrada,

procesamiento o salida.

Tambin ofrece un mejor enfoque cuando el responsable del

desarrollo del software est inseguro de la eficacia de un algoritmo,
de la adaptabilidad de un sistema operativo o de la forma que
debera tomar la interaccin humano-mquina.
La construccin de prototipos se puede utilizar como un modelo del proceso
independiente, se emplea ms comnmente como una tcnica susceptible de
implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos.
Sin importar la forma en que ste se aplique, el paradigma de construccin de prototipos
ayuda al desarrollador de software y al cliente a entender de mejor manera cul ser el
resultado de la construccin cuando los requisitos estn satisfechos. De esta manera, este
ciclo de vida en particular, involucra al cliente ms profundamente para adquirir el
producto.

Inconvenientes
El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema
final. A causa de la intencin de crear un prototipo de forma rpida, se suelen desatender
aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que
obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido
su funcin. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese
prototipo se construya el sistema final, lo que lo convertira en un prototipo evolutivo, pero
partiendo de un estado poco recomendado.
En reas de desarrollar rpidamente el prototipo, el desarrollador suele tomar algunas
decisiones de implementacin poco convenientes (por ejemplo, elegir un lenguaje de
programacin incorrecto porque proporcione un desarrollo ms rpido). Con el paso del
tiempo, el desarrollador puede olvidarse de la razn que le llev a tomar tales decisiones,
con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema
final...

Ejemplo:

En el Diseador de aplicaciones, el cuadro de herramientas incluye prototipos de

aplicaciones predefinidos que puede utilizar para definir las aplicaciones. Un prototipo de
aplicacin define una aplicacin pre configurada de un tipo de aplicacin especfico. Por
ejemplo, puede comenzar definiendo una aplicacin ASP.NET que expone un servicio
Web arrastrando el prototipo ASP.NETWebService del cuadro de herramientas al

diagrama de aplicaciones. Esta accin crea una aplicacin ASP.NET que tiene un extremo
del proveedor de servicios Web predeterminada. En los tipos de aplicaciones que admiten
la implementacin, Visual Studio genera los proyectos apropiados cuando los implementa
para que pueda continuar con la definicin de estas aplicaciones en cdigo. Tambin
puede crear prototipos personalizados a partir de aplicaciones y extremos ya configurados
en el diagrama de aplicaciones as como expandir el conjunto de tipos y prototipos de
aplicaciones que puede utilizar mediante la instalacin de paquetes suministrados por
Microsoft o por terceros o crendolos mediante el kit de desarrollo de software (SDK) del
modelo de definicin del sistema (SDM).
Conclusiones
En este modelo a pesar de que surjan problemas, es muy importante en la construccin
de prototipos ya que puede ser un enfoque muy efectivo para la ingeniera del software.
La clave es definir las diferentes reglas que rigen para este modelado y enfocarlos desde
el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:

Que el prototipo se construya y sirva como un mecanismo para la definicin de

requisitos.

Que el prototipo se descarte, al menos en parte.

Que despus se desarrolle el software real con un enfoque hacia la calidad

2.1.6 DESARROLLO BASADO EN COMPONENTES
Ingeniera de Software Basada en Componentes (ISBC)
Tradicionalmente los ingenieros del software han seguido un enfoque de desarrollo
descendente (top-Down) basado en el ciclo de vida en cascada (anlisis-diseo
implementacin) para la construccin de sus sistemas, donde se establecen los requisitos
y la arquitectura de la aplicacin y luego se va desarrollando, diseando e implementando
cada parte software hasta obtener la aplicacin completa implementada.
La ISBC parte de la idea de la integracin de componentes software ya existente
(Desarrollo ascendente o bottom-up). Las tecnologas de objetos proporcionan el marco
de trabajo tcnico, para la ingeniera de software, para un modelo de proceso basado en
componentes. El paradigma orientado a objetos enfatiza la creacin de clases que
encapsulan tanto los datos como los algoritmos para manejar esos datos. Si se disean y
se implementan adecuadamente, las clases

Orientadas a objetos son reutilizables por diferentes aplicaciones.

Es la reutilizacin la que permite a los desarrolladores construir aplicaciones sin partir
desde cero, sino acercndose ms al modelo de construccin de otras ingenieras, donde
los productos se construyen en base al ensamblaje y adaptacin de distintos
componentes desarrollados por terceros (como lo es la industria del hardware para
computadoras). Por ello requiere un conjunto de estndares, guas, procesos y prcticas,
para que se la considere como una ingeniera tal, y como una sub-disciplina de la
Ingeniera de Software.
Segn Pressman, La metodologa que propone entonces la Ingeniera de Software
Basada en Componentes (ISBC) (Figura 1) incorpora muchas de las caractersticas del
Modelo en Espiral. Es evolutivo2 por naturaleza, y por ello exige tambin un enfoque
iterativo para la creacin del software.

Fases de Ingeniera y Construccin y Accin de ste modelo por una sola fase de
Construccin y adaptacin de la Ingeniera:

*Comunicacin con el cliente- las tareas requeridas para establecer comunicacin

entre el desarrollador y el cliente.

*Planificacin- las tareas requeridas para definir recursos, el tiempo y otra

informacin relacionadas con el proyecto.

*Anlisis de riesgos- las tareas requeridas para evaluar riesgos tcnicos y de

gestin.

*Construccin y adaptacin de la Ingeniera

*Evaluacin del cliente- las tareas requeridas para obtener la reaccin del cliente
segn la evaluacin de las representaciones del software creadas durante la etapa
de ingeniera e implementada durante la etapa de instalacin.

Evoluciona con el tiempo, se crean versiones cada vez ms completas del producto.

Un componente de software individual es un paquete de software, un servicio web, o

un mdulo que encapsula un conjunto de funciones relacionadas (o de datos).
Todos los procesos del sistema son colocados en componentes separados de tal manera
que todos los datos y funciones dentro de cada componente estn semnticamente
relacionados (justo como con el contenimiento de clases). Debido a este principio, con
frecuencia se dice que los componentes son modulares y cohesivos.
Con respecto a la coordinacin a lo largo del sistema, los componentes se comunican uno
con el otro por medio de interfaces. Cuando un componente ofrece servicios al resto del
sistema, este adopta una interfaz proporcionada que especifica los servicios que otros
componentes pueden utilizar, y cmo pueden hacerlo. Esta interfaz puede ser vista como
una firma del componente - el cliente no necesita saber sobre los funcionamientos
internos del componente (su implementacin) para hacer uso de ella. Este principio resulta
en componentes referidos como encapsulados. Las ilustraciones UML de este artculo
representan a las interfaces proporcionadas, con un smbolo lollipop unido al borde
externo del componente.
Sin embargo, cuando un componente necesita usar otro componente para poder
funcionar, adopta una interfaz usada que especifica los servicios que necesita. En las
ilustraciones de UML en este artculo, las interfaces usadas son representadas por un
smbolo de zcalo abierto unido al borde externo del componente.

Un simple ejemplo de varios componentes de software - representados dentro de un

hipottico sistema de reservaciones de das de fiesta representado en UML 2.0.
Otro atributo importante de los componentes es que son sustituibles, as que un
componente puede sustituir a otro (en tiempo de diseo o tiempo de ejecucin), si el
componente sucesor cumple los requisitos del componente inicial (expresado por medio
de las interfaces). Por lo tanto, los componentes pueden ser sustituidos por una versin
actualizada o una alternativa sin romper el sistema en el cual operan.
Como una regla de oro general para los ingenieros que sustituyen componentes, el
componente B puede sustituir inmediatamente al componente A, si el componente B
proporciona por lo menos que el componente A provee y no usa ms cosas que las que el
componente A usa.
Los componentes de software con frecuencia toman la forma de objetos (no clases) o de
colecciones de objetos (de la programacin orientada a objetos), en una cierta forma
binaria o textual, adhirindose a un cierto lenguaje de descripcin de interfaz (IDL) de
modo que el componente pueda existir autnomo de otros componentes en
una computadora.
Cuando un componente debe ser accesado o compartido a travs de contextos de
ejecucin

enlaces

de

red,

menudo

son

empleados

tcnicas

tales

como serializacin o marshalling para enviar el componente a su destino.

La reusabilidad es una importante caracterstica de un componente de software de alta
calidad. Los programadores deben disear e implementar componentes de software de
una manera tal que diversos programas puedan reutilizarlos. Adems, cuando los

componentes de software interactan directamente con los usuarios, debe ser

considerada la prueba de usabilidad basada en componentes.
Toma un significativo esfuerzo y conciencia para escribir un componente de software que
sea efectivamente reutilizable. El componente necesita estar:

completamente documentado
probado a fondo
robusto - con una comprensiva comprobacin para la validez de la entrada
capaz de devolver mensajes de error apropiados o cdigos de retorno
diseado con conciencia de que ser puesto en usos imprevistos

Beneficios del Desarrollo de Software basado en Componentes

El paradigma de ensamblar componentes y escribir cdigo para hacer que estos
componentes

funcionen

se

conoce

como

Desarrollo

de

Software

Basado

en

Componentes. El uso de este paradigma posee algunas ventajas:

Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de
software.
Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de
los componentes antes de probar el conjunto completo de componentes ensamblados.
Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre
componentes, el desarrollador es libre de actualizar y/o agregar componentes segn sea
necesario, sin afectar otras partes del sistema.
Mayor calidad. Dado que un componente puede ser construido y luego mejorado
continuamente por un experto u organizacin, la calidad de una aplicacin basada en
componentes mejorar con el paso del tiempo.
Ejemplo:

Un simple ejemplo de dos componentes expresado en UML 2.0. El componente Checkout

(comprobacin), responsable de facilitar los pedidos del cliente, requiere al componente
CardProcessing (procesador de tarjetas) para cargar el monto a la tarjeta de crdito/dbito
del cliente (funcionalidad que este ltimo provee).

2.2 OTRAS METODOLOGAS

Metodologa SCRUM:
Es un marco de trabajo para la gestin y desarrollo de software basada en un
proceso iterativo e incremental

utilizado comnmente en entornos basados en

el desarrollo gil de software.

Aunque Scrum estaba enfocado a la gestin de procesos de desarrollo de software, puede
ser utilizado en equipos de mantenimiento de software, o en una aproximacin de gestin
de programas: Scrum de Scrums.
Programacin extrema
La programacin extrema o eXtreme Programming (XP) es una metodologa de desarrollo
de la ingeniera de software formulada por Kent Beck, autor del primer libro sobre la
materia, Extreme Programming Explained: Embrace Change (1999). Es el ms destacado
de los procesos giles de desarrollo de software.
En el siguiente diagrama nos muestra ciclo de entrega en la programacin extrema.
Al igual que stos, la programacin extrema se diferencia de las metodologas
tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la
previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la
marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.
Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la
vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los
requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios
en los requisitos.

Se puede considerar la programacin extrema como la adopcin de las mejores

metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto,
y aplicarlo de manera dinmica durante el ciclo de vida del software.
Proceso unificado gil
El proceso unificado gil de Scott ambler o agile unified process (aup) en ingls es una
versin simplificada delproceso unificado de rational (rup). Este describe de una manera
simple y fcil de entender la forma de desarrollar aplicaciones de software de negocio
usando tcnicas giles y conceptos que an se mantienen vlidos en rup. El aup aplica
tcnicas giles incluyendo desarrollo dirigido por pruebas (test driven development - tdd),
modelado gil, gestin de cambios gil, y refactorizacin de base de datos para mejorar la
productividad.

2.2.1GANAR-GANAR (WIN & WIN)

Ganar-ganar: extiende el modelo espiral, haciendo nfasis en la identificacin de las
condiciones de ganancia para todas las partes, creando un plan para alcanzar las
condiciones ganadoras y los riesgos correspondientes.
Se establecen las reglas para definir el proceso de desarrollo del proyecto, tomando en
cuenta todas las partes implicadas.
El modelo no necesita mucho tiempo de gestin, lo que permite utilizarlo tanto en
proyectos pequeos, como mayores.
Se consideran cuatro ciclos, compuesto cada uno de cuatro actividades:

Elaborar los objetivos, restricciones y alternativas del proceso y producto del

sistema y subsistema
Evaluar las alternativas con respecto a los objetivos y restricciones.
Identificar y resolver las fuentes principales de riesgo en el proceso y el producto.
Elaborar la definicin del producto y proceso.

Planear el siguiente ciclo y actualizar el plan de su ciclo de vida, incluyendo la

particin del sistema en subsistemas para ser consideradas en ciclos paralelos. Esto
puede incluir un plan para terminar el proyecto si es muy riesgoso o no es factible.
Asegurar el compromiso de la administracin para continuar segn lo planeado.

Ganar-ganar: Una vez revisadas las actividades, los ciclos definen lneas especficas a
seguir:

Ciclo 0. Grupos de aplicacin. Se determina la viabilidad de un

grupo apropiado de aplicaciones

Ciclo 1. Objetivos del ciclo de vida de la aplicacin. Se desarrollan
los objetivos del ciclo de vida, incluyendo prototipos, planes y
especificaciones de aplicaciones individuales, y se verifica la
existencia de al menos una arquitectura viable para cada

aplicacin.
Ciclo 2. Arquitectura del ciclo de vida de la aplicacin. Se
establece una arquitectura del ciclo de vida detallado, se verifica la
viabilidad y determina que no existen riesgos mayores en

satisfacer los planes y especificaciones.

Ciclo 3. Capacidad de operacin inicial. Alcanzar una capacidad
operacional inicial para cada etapa crtica del proyecto en el ciclo
de vida del software.

Ejemplo: La evaporacin de nubes es la tcnica que tiene TOC para solucin de

conflictos.
La nube es la metodologa para definir e identificar correctamente los conflictos que es la
raz de todos los problemas.

Del diagrama podemos deducir:

La flecha quebrada de la ltima parte simboliza el conflicto
Los Quieros no pueden existir simultneamente.
La Necesidad es la razn por la cual cada parte insiste en obtener lo que quiere.
Para satisfacer la Necesidad es necesario alcanzar el Quiero.
El Objetivo Comn es una situacin que ambas partes desean, y para que exista
Cada parte debe satisfacer su Necesidad.

2.2.2 PROCESO UNIFICADO (UP)

El Proceso Unificado es un proceso de software genrico que puede ser utilizado para una
gran cantidad de tipos de sistemas de software, para diferentes reas de aplicacin,
diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes
tamaos de proyectos.
Provee un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de
una organizacin de desarrollo. Su meta es asegurar la produccin de software de muy
alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario
y presupuesto predecible.
El Proceso Unificado tiene dos dimensiones (Figura 1):
Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del
proceso a lo largo de su desenvolvimiento
Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una
manera lgica de acuerdo a su naturaleza.
La primera dimensin representa el aspecto dinmico del proceso conforme se va
desarrollando, se expresa en trminos de fases, iteraciones e hitos

La segunda dimensin representa el aspecto esttico del proceso: cmo es descrito en

trminos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos
y roles.

Flujo de Trabajo de RUP

En RUP se han agrupado las actividades en grupos lgicos definindose 9 flujos de
trabajo principales, los 6 primeros son conocidos como flujos de ingeniera y los tres
ltimos como flujos de apoyo.
Modelo del Negocio: Describe los procesos de negocio, identificando quines participan
y las actividades que requieren automatizacin.
Requerimiento: Define qu es lo que el sistema debe hacer, para lo cual se identifican las
funcionalidades requeridas y las restricciones que se imponen.
Anlisis y Diseo: Describe cmo el sistema ser realizado a partir de la funcionalidad
prevista y las restricciones impuestas (requerimientos), por lo que indica con precisin lo
que se debe programar.
Implementacin: Define cmo se organizan las clases y objetos en componentes, cules
nodos se utilizarn y la ubicacin en ellos de los componentes y la estructura de capas de
la aplicacin.
Prueba (Testeo): Busca los defectos a los largo del ciclo de vida.

Instalacin o despliegue: Produce realce del producto y realiza actividades (empaque,

instalacin, asistencia a usuarios, etc.) para entregar el software a los usuarios finales.
Administracin del proyecto: Involucra actividades con las que se busca producir un
producto que satisfaga las necesidades de los clientes.
Administracin de configuracin y cambios: Describe cmo controlar los elementos
producidos

por

todos

los integrantes del

equipo

de

proyecto

en

cuanto

a:

utilizacin/actualizacin concurrente de elementos, control de versiones, etc.

Ambiente: Contiene actividades que describen los procesos y herramientas que
soportarn el equipo de trabajo del proyecto; as como el procedimiento para implementar
el proceso en una organizacin.
El Proceso Unificado se basa en componentes (component-based), lo que significa que
el sistema en construccin est hecho de componentes de software interconectados por
medio de interfaces bien definidas (well-defined interfaces).
El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la preparacin
de todos los planos del sistema. De hecho, UML es una parte integral del Proceso
Unificado, fueron desarrollados a la par.
Los aspectos distintivos del Proceso Unificado estn capturados en tres conceptos clave:
dirigido por casos de uso (use-case driven), centrado en la arquitectura (architecturecentric), iterativo e incremental. Esto es lo que hace nico al Proceso Unificado.
El Proceso Unificado es dirigido por casos de uso
Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un
sistema exitoso se debe conocer qu es lo que quieren y necesitan los usuarios
prospectos.
El trmino usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas.
En este contexto, el trmino usuario representa algo o alguien que interacta con el
sistema por desarrollar.
Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un
resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los
casos de uso juntos constituyen el modelo de casos de uso el cual describe la
funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificacin
funcional del sistema. Una especificacin funcional tradicional se concentra en responder

la pregunta: Qu se supone que el sistema debe hacer? La estrategia de casos de uso

puede ser definida agregando tres palabras al final de la pregunta: por cada usuario?
Estas tres palabras tienen una implicacin importante, nos fuerzan a pensar en trminos
del valor a los usuarios y no solamente en trminos de las funciones que sera bueno que
tuviera. Sin embargo, los casos de uso no son solamente una herramienta para
especificar los requerimientos del sistema, tambin dirigen su diseo, implementacin y
pruebas, esto es, dirigen el proceso de desarrollo.
An y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada.
Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso
dirigen la arquitectura del sistema y la arquitectura del sistema influencia la eleccin de los
casos de uso. Por lo tanto, la arquitectura del sistema y los casos de uso maduran
conforme avanza el ciclo de vida.

El Proceso Unificado est centrado en la arquitectura

El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto
desempea en la construccin de edificios. El edificio se mira desde diferentes puntos de
vista: estructura, servicios, plomera, electricidad, etc. Esto le permite al constructor ver
una radiografa completa antes de empezar a construir. Similarmente, la arquitectura en
un sistema de software es descrita como diferentes vistas del sistema que est siendo
construido.
El concepto de arquitectura de software involucra los aspectos estticos y dinmicos ms
significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y
como las interpretan los usuarios y otros stakeholders, y tal y como estn reflejadas en los
casos de uso. Sin embargo, tambin est influenciada por muchos otros factores, tales
como la plataforma de software en la que se ejecutar, la disponibilidad de componentes
reutilizables, consideraciones de instalacin, sistemas legados, requerimientos no
funcionales (ej. desempeo, confiabilidad). La arquitectura es la vista del diseo completo
con las caractersticas ms importantes hechas ms visibles y dejando los detalles de
lado. Ya que lo importante depende en parte del criterio, el cual a su vez viene con la
experiencia, el valor de la arquitectura depende del personal asignado a esta tarea. Sin
embargo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como
claridad (understandability), flexibilidad en los cambios futuros (resilience) y reso.

Cmo se relacionan los casos de uso con la arquitectura? Cada producto tiene funcin y
forma. Uno slo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas
para obtener un producto exitoso. En este caso funcin corresponde a los casos de uso y
forma a la arquitectura. Existe la necesidad de intercalar entre casos de uso y
arquitectura. Es un problema del huevo y la gallina. Por una parte, los casos de uso
deben, cuando son realizados, acomodarse en la arquitectura. Por otra parte, la
arquitectura debe proveer espacio para la realizacin de todos los casos de uso, hoy y en
el futuro. En la realidad, ambos arquitectura y casos de uso deben evolucionar en
paralelo.
El Proceso Unificado es Iterativo e Incremental
Desarrollar un producto de software comercial es una tarea enorme que puede continuar
por varios meses o aos. Es prctico dividir el trabajo en pequeos pedazos o miniproyectos. Cada mini-proyecto es una iteracin que finaliza en un incremento. Las
iteraciones se refieren a pasos en el flujo de trabajo, los incrementos se refieren a
crecimiento en el producto. Para ser ms efectivo, las iteraciones deben estar controladas,
esto es, deben ser seleccionadas y llevadas a cabo de una manera planeada.
Los desarrolladores basan su seleccin de qu van a implementar en una iteracin en dos
factores. Primero, la iteracin trata con un grupo de casos de uso que en conjunto
extienden la usabilidad del producto. Segundo, la iteracin trata con los riesgos ms
importantes. Las iteraciones sucesivas construyen los artefactos del desarrollo a partir del
estado en el que fueron dejados en la iteracin anterior.
En cada iteracin, los desarrolladores identifican y especifican los casos de uso
relevantes, crean el diseo usando la arquitectura como gua, implementan el diseo en
componentes y verifican que los componentes satisfacen los casos de uso. Si una
iteracin cumple sus metas y usualmente lo hace el desarrollo contina con la
siguiente iteracin. Cuando la iteracin no cumple con sus metas, los desarrolladores
deben revisar sus decisiones previas y probar un nuevo enfoque.
Principales ventajas

Coste del riesgo a un solo incremento.

Reduce el riesgo de no sacar el producto en el calendario previsto.
Acelera el ritmo de desarrollo.
Se adapta mejor a las necesidades del cliente.

Ejemplo Real:

PROCESO UNIFICADO RACIONAL, APLICADO EN DISTRIBUCIN

Categora
Operacin de Sistemas de Potencia
RESUMEN
El objetivo de este trabajo es presentar de forma prctica un ejemplo de caso, al aplicar la
metodologa RUP (Proceso Unificado Racional) en la implementacin de un sistema para
medir la calidad en distribucin elctrica.
PALABRAS CLAVES.
Desarrollo de software, calidad del servicio de Distribucin Local, metodologa RUP.

INTRODUCCIN
Los sistemas de transporte de energa elctrica en Colombia, han sido impactados por los
cambios metodolgicos, para determinar la calidad de prestacin del servicio.
Desde el 2008, se present la metodologa para reemplazar en los Sistemas de
Distribucin Local SDL , los ndices de duracin y frecuencia de eventos (DES y FES),
por un indicador trimestral (ITAD), el cual mide la calidad de prestacin del servicio de
distribucin.
Dentro de la metodologa se estableci que el XM en su calidad de Liquidador y
Administrador de Cuentas LAC-, debe determinar el ITAD de forma paralela al clculo
que debe realizar cada Operador de Red, quien es responsable de la operacin y de la
calidad del servicio en sus redes.
La implementacin del sistema informtico para calcular el ITAD, XM realiz un ejercicio
prctico, aplicando la metodologa de desarrollo de software RUP (Rational Unified
Process).
La metodologa RUP, comprende la adaptacin del proceso, el equilibrio de las
prioridades, ventajas de dividir el problema en iteraciones, gestin de riesgos,
colaboracin entre equipos, elevar el nivel de abstraccin y enfocarse en el control de la
calidad del producto.

El objetivo de este trabajo es presentar los resultados encontrados al aplicar la

metodologa RUP y documentar la experiencia para que desarrollos informticos futuros,
se beneficien con las lecciones aprendidas.
El trabajo se divide en cuatro secciones. En la primera parte, se detalla el marco terico
de la metodologa RUP. A continuacin se describen el estudio de caso aplicado a la
construccin del aplicativo para el clculo del ITAD. En la tercera parte se detalla el
proceso iterativo y control de calidad empleado, para garantizar la aplicacin correcta de
las regla de negocio. En la ltima parte se

presentan los resultados obtenidos, las

conclusiones y lecciones aprendidas, en la construccin de software en el mbito del

sector elctrico.
Tanto las etapas del flujo de trabajo, como las fases de desarrollo, se presentan en la
siguiente grfica:

Los elementos anteriores, fueron tenidos en cuenta para el desarrollo informtico, para el
clculo de la calidad, en los Sistemas de Distribucin Local SDL-, cuyo anlisis se
presenta en la siguiente seccin.
ESTUDIO DE CASO
Bajo la metodologa RUP, se efectu el desarrollo informtico de un sistema, para calcular
los ndices de calidad de los SDL.
El proyecto se dividi en dos partes: especificacin y desarrollo del sistema.

ESPECIFICACIN (ANLISIS)
La Resolucin CREG 097 de 2008, establece la metodologa para el clculo del ITAD,
ndice Trimestral Agrupado de Discontinuidad, el cual mide la calidad del servicio en los
SDL. En cuanto mayor sea su valor, el servicio tiene peor calidad.
Dicha resolucin, plantea las ecuaciones y reglas para calcular el ITAD. Bajo esta ptica,
se realiz la

especificacin de

las

necesidades, reglas

de negocio, requisitos

funcionales, validaciones, requisitos no funcionales, tal como se describe a continuacin

[1]:
Necesidades: Es aquello que requiere ser resuelto en un proceso para cerrar o dar fin
a una problemtica que se presenta en la actualidad en el negocio. Esta necesidad
igualmente representa lo que el sistema de informacin le permitir hacer a los analistas
de negocio para cumplir con los objetivos del proceso respectivo, siendo independiente de
la forma (tcnica) como que se va a implementar en el sistema de informacin.
Para el caso del clculo del ITAD, las necesidades estaban basadas por ejemplo, en
recibir la informacin diaria, de las interrupciones de los transformadores y circuitos, de los
Operadores de Red.
Se utiliz la metodologa UML

- Lenguaje Unificado de Modelado, para modelar las

necesidades, los requisitos, y la posterior definicin de los casos de uso del sistema.
Reglas de negocio: son aquellos enunciados que definen o restringen algunos aspectos
del negocio. Describen las operaciones, las definiciones, y las restricciones que aplican a
la organizacin. Dichas reglas pueden aplicar a la gente, a los procesos, al
comportamiento corporativo e incluso, a los sistemas de cmputo de la empresa, y se
ponen en marcha para ayudar a la organizacin a alcanzar sus metas. En un proceso de
requisitos, las reglas de negocio permiten restringir el grado de libertad en el
funcionamiento del sistema de informacin en cuestin, reflejando las directrices del
proceso.
Para el caso del sistema, las reglas de negocio establecieron por ejemplo que la
informacin que se maneja de energa, estaba expresada en kWh. Tambin en

la

especificacin quedaba explcito, reglas relacionadas con el horario de carga de

informacin, la estructura de los datos, el manejo de la bitcora para el registro de
actividades del sistema entre otras.

Validacin:

una

vez

se

determina

el comportamiento del sistema, y por el gran

manejo de volumen de informacin, se incluyeron las normas que debe cumplir el sistema
para su correcto funcionamiento.
Como ejemplo, se validaba que la informacin cargada estuviera completa, que las fechas
de carga fueran correctas, que los clculos de variables especficas no fueran negativos
entre otros. Es importante mencionar que para cada validacin, se defini el
correspondiente mensaje de alerta, de confirmacin o error segn el caso, esto permite
tener un mejor control sobre el sistema.

Grafica 2 - Validaciones del Sistema

Requisito funcional general: Se detallan aquellas funcionalidades que son utilizadas de
forma transversal en todo el sistema, por ejemplo, requisitos relacionados con la
elaboracin de informes, auditoria, impresin, seguridad, autenticacin, etc.

Para este caso, por ejemplo los requisitos consistan en las ecuaciones para el clculo del
ITAD, partiendo de las expresiones intermedias, hasta llegar a la determinacin de ste
ndice.

En la Grfica 3, se ilustra un ejemplo de un requisito, para calcular el ITG, que es

una variable intermedia para llegar al ITAD.

Grafica 3 Requisito General Funcional

Ntese lo importante de la numeracin del requisito, seguido por una descripcin
completa y clara de lo que se requiere.

Requisito no funcional general: constituyen las funcionalidades de orden tecnolgico y las

caractersticas de calidad del producto final.
Dada la gran cantidad de informacin del sistema, por ejemplo se definieron tiempos de
respuesta esperados, para evaluar el desempeo del sistema y poder efectuar los
clculos y publicaciones, bajo los plazos establecidos en la norma.
Requisito de informacin: existe informacin que el usuario puede ver en pantalla, con
la cual toma decisiones. Un requisito de este tipo, contiene por ejemplo el listado de
datos producto de

un

clculo, un

proceso u operacin.

En la siguiente grfica, se ilustra un requisito de informacin para la informacin diaria de

interrupciones:

Grafica 4 Requisitos de informacin

Casos de uso: es la forma de agrupar una serie de validaciones, reglas, funcionalidades,
interaccin del usuario con el sistema, donde queda de manera organizada, los escenarios
donde el usuario realizar alguna actividad, para lograr un objetivo especfico.

Un caso de uso, tiene asociado una descripcin general, la

tiene

cual relata su objetivo,

la definicin de los requisitos, tales como precondiciones y poscondiciones, que se

deben tener, las restricciones, y el listado de actividades que se realizan en el escenario.

En la Grfica 5 se ilustra un ejemplo de cmo quedan conformados los casos de uso, su
relacin entre s y entre los actores, que son los encargados de activarlos, segn
se requiera.

Grafica 5 Modelo de Casos de Uso

Cada caso de uso tiene agrupadas distintas funcionalidades, y permite un mejor
entendimiento tanto al analista que realiz la especificacin, como al lder tcnico para su
monitoreo y control.
DESARROLLO DEL SISTEMA
Una vez especificado el sistema y teniendo documentadas las reglas de negocio, las
validaciones, la totalidad de requisitos etc., se inicia con la construccin del sistema.

Para el caso del aplicativo para el clculo del ITAD, se inici la construccin por cada una
de las iteraciones conformadas en el numeral 3.
A cada una de las iteraciones se les asoci los casos de uso correspondientes.
Una vez terminada el diseo, anlisis, codificacin, pruebas, el caso de uso queda listo
para su montaje en ambiente de produccin.

Las pruebas fueron realizadas por una firma independiente a la casa de software,
encargada de la construccin del sistema, esto permite una mayor verificacin de la
calidad del producto, toda vez que es un tercero quien tiene que aprender sobre el sistema
y efectuar validaciones estrictas.
En

este

punto

es

importante mencionar, que al tener una documentacin clara,

detallada, el entendimiento del problema y la posterior construccin de los casos de

prueba, resulta una tarea ms eficiente, con menor reproceso.
CONTROL Y DEFINICIN DE ITERACIONES
Al dividir el sistema, se encontr una simplificacin de su complejidad, para efectos del
seguimiento. Una forma como se conformaron las iteraciones del sistema fueron:
Mdulo administrativo: en el cual el usuario, puede

su voluntad,

administrar

la

informacin bsica necesaria para que el sistema funcione. Ejemplo: la configuracin de

horarios de carga de informacin, la asignacin de Operadores de Red que hacen parte
del esquema.
Mdulo de cargas: para calcular el ITAD, se necesita de la informacin diaria de los
eventos en los SDL. Para tal fin se cre un sistema que permite recibir la informacin, su
correspondiente validacin en lnea y su posterior descarga.
Mdulos de clculos: una vez se cuenta con los insumos, previamente validados, se
procede con los clculos intermedios hasta llegar al ITAD.
Mdulo

de

reportes: en este

paquete,

se encuentran todas las consultas que se

requieren del sistema. Algunas pueden ser las fechas de carga, los valores de energa, las
interrupciones entre otras.
Bajo los cuatro mdulos anteriores, se hizo la jerarqua de iteraciones, en las cuales cada
entregable, estaba asociado con los casos de uso de cada mdulo, cada uno previamente

verificado y aprobado, por los lderes usuario encargados de la especificacin, y por los
lderes tcnicos, encargados de la verificacin del funcionamiento tecnolgico.
Al segmentar las entregas, se realiz un control ms detallado y es posible minimizar
errores que pueden desencadenar efectos ms grandes, a medida que se va construyendo
el sistema.
As mismo al dividir en iteraciones, se llev un mejor seguimiento del cronograma de
actividades y de los costos del proyecto.

CONCLUSIONES Y RECOMENDACIONES
Definitivamente un factor de xito en la construccin de software, consiste en tener en
primera medida un claro entendimiento sobre el problema a resolver.
Al mismo nivel, disponer de la especificacin en las distintas herramientas disponibles en el
mercado, conformando artefactos auto contenido y claro, para que cualquier casa de
software est en capacidad de construirlos.
Construir software sin una metodologa clara, puede llevar a mayores reprocesos y
costos, sin que la solucin definitiva quede documentada y sin tener la trazabilidad sobre
los mdulos del sistema.
Adicionalmente una vez se tiene el sistema debidamente documentado, su mantenimiento
se facilita. As mismo en caso de cambios regulatorios, es ms fcil identificar el
impacto, segn los casos de uso que se ven afectados por la nueva regla de negocio.
RECOMENDACIONES
Al dividir el problema por iteraciones, se facilita su control y seguimiento.
La especificacin debe quedar detallada, clara y se debe validar que todo quede bien
documentado.
Modelar el proceso, antes de establecer los requisitos, ya que se adquiere una visin
integral sobre el problema a resolver, y las soluciones encontradas, pueden ser ms
efectivas.
2.2.3 INGENIERA WEB

La ingeniera web es una nueva rea de la ingeniera del software que abarca procesos,
tcnicas y modelos orientados a los entornos Web. Consiste en la aplicacin de
metodologas sistemticas, disciplinadas y cuantificables al desarrollo eficiente, operacin
y evolucin de aplicaciones web de alta calidad. Los principales mbitos de la ingeniera
web incluyen, entre otros, los siguientes aspectos:
Diseo de procesos de negocio para aplicaciones web.
Herramientas CASE para aplicaciones web.
Generacin de cdigo para aplicaciones web.
Desarrollo web colaborativo.
Modelado conceptual de aplicaciones web.
Diseo de Modelos de datos para sistemas de informacin web.
Entornos de desarrollo de aplicaciones web integrados.
Herramientas de autor para contenido multimedia.
Pruebas de rendimiento de aplicaciones basadas en web.
Personalizacin y adaptacin de aplicaciones web.
Modelado de procesos para aplicaciones web.
Herramientas y mtodos de prototipado.
Control de calidad y pruebas de sistemas.
Ingeniera de requisitos para aplicaciones web.
Aplicaciones para la Web Semntica.
Factoras de software para la web.
Mtodos, herramientas y automatizacin de pruebas para aplicaciones web.
Aplicaciones web mviles y ubcuas.
Usabilidad de aplicaciones web.
Accesibilidad para la web.

 Metodologas de diseo web.

Diseo de interfaces de usuario.
Mtricas para la web, estimacin de costes y medicin.
Gestin de proyectos web y gestin de riesgos.
Desarrollo y despliegue de servicios web.
En los ltimos aos existe una tendencia importante a reconocer que las aplicaciones
basadas en el Web deben expresarse a un nivel de abstraccin mayor que aqul que
ofrecen las primitivas propias de las plataformas tecnolgicas. OMG en los ltimos aos
ha reconocido que el enfoque de modelado es una forma potente de especificar sistemas
y as lo demuestra su estrategia Model Driven Architecture (MDA) con la cual se busca
ofrecer al diseador la posibilidad de expresar la estructura, comportamiento y
funcionalidad del sistema independientemente de los aspectos tecnolgicos y lograr con
ello adems la posibilidad de una fcil integracin con otros sistemas. La Ingeniera Web
Dirigida por Modelos (MDWE) es la aplicacin de la Arquitectura Dirigida por Modelos al
campo del desarrollo de aplicaciones web donde puede resultar especialmente til debido
a la evolucin continua de las tecnologas y plataformas web. En esta direccin existen
propuestas de modelado de las cuales podemos destacar dos vertientes importantes: Metodologas orientadas al diseo navegacional cuyo objetivo es construir aplicaciones
hipermedia en sistemas estticos. La mayora de estas aproximaciones estn basadas en
el Modelo Relacional clsico, o bien en extensiones de ste. Algunos ejemplos
destacables de estas iniciativas son OOHDM, WebML, ADM, AutoWeb y RMM. - El otro
grupo de aproximaciones se basan en la idea de extender los mtodos de desarrollo
orientados a aplicaciones dinmicas tratando de introducir la semntica de la hipermedia
como caracterstica inherente a este nuevo tipo de sistemas software. Este tipo de
aproximaciones de introducir caractersticas navegacionales al modelo OO. En este grupo
podemos encontrar los mtodos UWE, WSDM, EORM, OOW y OO-Method.
METODOLOGAS
A continuacin se comentan algunas de las metodologas enumeradas en el apartado
anterior:
UWE (UML-based Web Engineering) sirve para modelar aplicaciones web, y presta una
especial atencin a la sistematizacin y personalizacin (sistemas adaptativos). Provee de
perfiles UML, metamodelos, un proceso de desarrollo dirigido por modelos, y herramientas

de soporte para el diseo sistemtico de aplicaciones web (ArgoUWE y MagicUWE).

Utiliza notacin basada en UML 2.0 (OMG): para aplicaciones Web en general y para
aplicaciones adaptativas en particular. La metodologa consta de seis modelos: o Modelo
de casos de uso para capturar los requisitos del sistema. O Modelo conceptual para el
contenido (modelo del dominio). O Modelo de usuario: modelo de navegacin que incluye
modelos estticos y dinmicos. O Modelo de estructura de presentacin, modelo de flujo
de presentacin. O Modelo abstracto de interfaz de usuario y modelo de ciclo de vida del
objeto. O Modelo de adaptacin.
Web Services Distributed Management (WSDM, se pronuncia wisdom) es una
especificacin basada en servicios web para gestionar y monitorizar el estado de otros
servicios. Es un estndar OASIS (Organization for the Advancement of Structured
Information Standards), y WSDM consiste en dos especificaciones: o Management Using
Web Services (MUWS): define como representar y como acceder a las interfaces de
gestin de recursos expuestos como servicios web. Define un conjunto bsico de
operaciones de gestin sobre los servicios, tales como identificacin, mtricas,
configuracin y relaciones, adems de un formato de eventos estndar. O Management Of
Web Services (MOWS): define como manejar servicios web como recursos y como
describir y acceder a las capacidades de gestin utilizando MUWS. Esta especificacin
permite a las aplicaciones de gestin de servicios web interoperar entre s.

 WebML (Web Modeling Language): Es una metodologa de modelado visual de

aplicaciones web, centrada especialmente en las aplicaciones de uso intensivo de datos,
separando el contenido de la informacin en pginas, navegacin y presentacin, que se
pueden definir y desarrollar de forma independiente. Permite la especificacin de
operaciones de manipulacin de datos para actualizar la aplicacin. Cuenta con cuatro
perspectivas: el Modelo Estructural (de los datos de la aplicacin), el Modelo de Hipertexto

(para cada hipertexto describe qu pginas lo componen, y cmo navegan), el Modelo de

Presentacin (disposicin y apariencia grfica), y el Modelo de Personalizacin (para
definir operaciones especficas para usuarios grupos de usuarios, ya que se almacenan
como entidades en el Modelo Estructural). Dispone de una herramienta CASE (WebRatio).
OOWS: Es una extensin del mtodo OO-Method (ya basado en modelos), al cual se le
aaden a las tcnicas de modelado conceptual, capacidades de expresar la hipermedia
inherente a las aplicaciones web. Consta de cinco modelos, que se especifican a
continuacin: o El Modelo de Objetos define la estructura y las relaciones estticas entre
clases identificadas en el dominio del problema. O En el Modelo Dinmico se describen
las posibles secuencias de servicios y los aspectos relacionados con la interaccin entre
objetos. O El Modelo Funcional captura la semntica asociada a los cambios de estado
entre los objetos motivados por la ocurrencia de eventos o servicios. O El Modelo de
Navegacin define la semntica navegacional asociada a las clases de los objetos del
modelo. Es en este modelo donde se explicita la navegacin permitida en la aplicacin
para cada agente del sistema, por lo que se realiza un mapa navegacional por cada uno,
en el que se definen nodos (posibles puntos de interaccin con el usuario) y arcos
(posibilidad de alcanzar otro nodo).
A continuacin se muestra un ejemplo:

El Modelo de Presentacin captura los requisitos bsicos de presentacin de informacin.

Est fuertemente basado en el modelo de navegacin y permite definir, de una manera
abstracta, la estructura lgica de presentacin de los objetos navegacionales en la interfaz
de usuario. Esta metodologa tambin cuenta con un entorno de desarrollo para
aplicaciones web (OOWS Suite).
NDT (Navigational Development Techniques): Es una metodologa orientada a la
Ingeniera Dirigida por Modelos (MDE). Aunque en un principio se centraba en las fases
de ingeniera de requisitos y anlisis, se ha ido ampliando a otras fases del ciclo de vida.
Define un conjunto de metamodelos para las fases de requisitos y anlisis, y una serie de
transformaciones y reglas que permiten obtener los modelos de anlisis a partir de ellos.
Los metamodelos se representan a partir de MOF (MetaObject Facility), mientras que las
transformaciones se definen mediante QVT (Query/View/Transformation). Consta de una
herramienta denominada NDT Suite. Todas estas metodologas necesitan transformar los
modelos para generar aplicaciones web. Segn el framework MDA, las transformaciones
se pueden aplicar para establecer un proceso de desarrollo trazable desde los modelos
abstractos (CIM, PIM) a los modelos dependientes de la plataforma, incluso
directamente a su implementacin. La mayora de las metodologas utilizan herramientas
CASE para realizar estas transformaciones. Estas herramientas se basan en tcnicas de
generacin de cdigo para obtener aplicaciones web a partir de un reducido conjunto de
modelos conceptuales de diseo. Las transformaciones se pueden dividir en
Transformaciones

Modelo-a-Modelo,

Transformaciones

Transformaciones Modelo-a-Modelo se pueden separar en:

Modelo-a-Cdigo.

Las

 Transformaciones verticales que convierten modelos de un mayor nivel de abstraccin

en otros de un nivel menor.
Transformaciones horizontales que describen el mapeo entre modelos del mismo nivel
de abstraccin. Las transformaciones verticales utilizan lenguajes como QVT, ATL AGG.
A veces incluso se definen como mecanismos de mezcla para introducir nuevos conceptos
como estilos de arquitectura, requisitos de usuario, y medida de la calidad. Las
transformaciones horizontales se utilizan para mantener la consistencia de las
especificaciones de los modelos, comprobando que estos modelos no imponen requisitos
contradictorios en sus elementos comunes. Las transformaciones Modelo-a-Cdigo se
llevan realizando ms tiempo, aunque a menudo se han utilizado lenguajes de propsito
general (C++, Java Python). Aunque un nuevo estndar del OMG ha establecido las
caractersticas propias de los lenguajes de transformacin Modelo-a-Cdigo, y algunas
herramientas han sido adaptadas para incluirlas.
HERRAMIENTAS Y PLATAFORMAS
Las metodologas comentadas anteriormente utilizan distintas herramientas para llevar a
cabo diversas operaciones:
ArgoUWE: Es una extensin de la herramienta de cdigo abierto ArgoUML a la cual se
le han aadido capacidad de modelado, navegacin y estructuras de presentacin.
WebTE: Es una herramienta de UML que soporta XMI permitiendo la introduccin de los
modelos y transformaciones en un motor de transformacin que los ejecuta y produce una
aplicacin web en JavaEE.
WebRatio: Es una herramienta comercial que da soporte a la metodologa WebML.
Trabaja con metamodelos basados en MOF, modelando los objetos de negocio mediante
los estndares UML E/R mientras que el front-end se modela con WebML. A partir de
aqu, para esos modelos se genera automticamente la aplicacin en la arquitectura
JavaEE y las fuentes de datos SQL/XML.
Eclipse Modelling Project (EMP): Proporciona una gran cantidad de facilidades de
desarrollo dirigido por modelos de gran calidad, entre otros: o Un framework de modelado
comn denominado EMF o Meta-editores como GMF (Graphical Modelling Framework) o
Motores de transformacin como ATL o VIATRA, entre otros o Generadores de cdigo
como MOFScript

 NDT Suite: Es un conjunto de herramientas para aplicar la metodologa NDT en

entornos prcticos. Consta de las siguientes: o NDT-Profile es un perfil (profile) definido en
la herramienta Enterprise Architect. Este perfil aporta diversas herramientas y artefactos
propios de NDT. O NDT-Driver permite, a partir de un fichero de NDT-Profile como
entrada, ejecutar las transformaciones automticamente, y a partir de los requisitos y los
modelos obtiene prototipos HTML automticos. O NDT-Quality toma como entrada un
fichero de Enterprise Architect y comprueba que la trazabilidad y las normas de NDT se
cumplen.
OOWS Suite: Es un entorno de desarrollo que da soporte a la metodologa OOWS. Se
integra con la herramienta comercial OlivaNOVA, que implementa el proceso de desarrollo
de O-Method. El entorno consta de un editor grfico denominado OOWS Visual Editor, el
cual asocia a cada primitiva conceptual su representacin grfica o textual.
EJEMPLO
A continuacin se muestra el ejemplo del desarrollo de una aplicacin web para la compra
de discos por internet: Existen dos tipos de usuarios, los Administradores y los Usuarios
Navegantes.
Mientras que los primeros se encargan de la gestin de los lbumes a la venta, los
segundos son usuarios comunes (compradores). Las compras que realicen los Usuarios
Navegantes se debern ir incluyendo, simblicamente, en una cesta de la compra; el
usuario podr consultar en cualquier momento el contenido de su cesta y realizar
modificaciones sobre su contenido. Esta cesta de la compra se crear en el momento en
el que se reciba la peticin de entrada en el sistema y pertenecer al usuario que est
navegando en ese momento; todas las operaciones que el usuario realice sobre el
sistema se harn de forma annima, de modo que el usuario no deber identificarse
(registrarse) hasta que no vaya a confirmar su compra; para comprar un lbum se deber
llegar a l a travs del autor o de la categora a la que pertenece; desde la pgina de inicio
podremos acceder a un listado de autores o a un listado de categoras y desde ah al
listado de los lbumes del autor o de la categora que hayamos seleccionado; cuando
seleccionemos un lbum de la lista, se mostrarn todos los datos de ese lbum y se podr
comprar. Esto har que el lbum sea incluido en la cesta de la compra de ese usuario y
que se muestre su contenido actual; mientras veamos el contenido de la cesta, podremos
cambiar el nmero de unidades que se desea adquirir de cada lbum de los comprados
hasta el momento o eliminar alguna de las compras de la cesta; cuando se decida
confirmar la compra se realizarn dos acciones: la primera consistir en crear una factura

(para lo que el comprador debe haberse identificado) y la segunda ser reducir el stock de
los lbumes comprados; cuando se haya confirmado una compra, ya no se podr
modificar el contenido de la cesta. Los administradores se encargan de gestionar y
mantener el catlogo de productos del sistema, as como mantener la lista de autores que

poseen discos en la tienda. El primer paso es la fase de la Especificacin del Problema,

lo cual genera diagramas de casos de uso a partir de la funcionalidad encontrada en el
anlisis de los requisitos. A continuacin se muestra el caso de uso para el agente Usuario
Navegante.

En la fase de modelado conceptual se construyen los siguientes modelos:

Modelo de Objetos, Modelo Dinmico, Modelo Funcional, Modelo Navegacional y Modelo
de Presentacin.
A continuacin se muestra el Modelo de Objetos, para realizar el cual se han estudiado los
requisitos funcionales del sistema desde un punto de vista OO, asociando la funcionalidad
a cada usuario segn los casos de uso mostrados en la fase anterior.

Despus del Modelo de Objetos, se construye el Modelo Dinmico donde se describen las
vidas vlidas de los objetos representando el comportamiento de cada clase del sistema.
A continuacin se muestra la parte del Modelo Dinmico para la clase Cesta.

El siguiente paso es el Modelo Funcional, el cual captura la semntica asociada a los

cambios de estado de los objetos. Cada atributo ve modificado su valor dependiendo de la
accin que activ el cambio de estado, de los argumentos del evento, y del estado actual
de ese objeto. La siguiente figura muestra una parte del modelo para la clase Lnea, que
contiene la evaluacin siguiente:

El Modelo de Navegacin es el siguiente paso, donde se estructura el acceso de cada

usuario al sistema. A continuacin se muestra el mapa de navegacin del agente Usuario
Navegante, con los contextos de navegacin definidos, y los servicios que se ejecutan al
iniciar y finalizar sesin. Los contextos de exploracin (etiquetados como E) son los que
tendr disponible siempre, y a partir de estos podra alcanzar los dems navegando por
diferentes caminos.

Viendo ms en detalle el contexto Autores, se ve que se recupera la informacin sobre un

autor (su nombre), sus lbumes que estn disponibles (ttulo, ao y precio) y el nombre de
la categora del lbum. Seleccionando el ttulo de un lbum se puede navegar al contexto
lbumes, donde se podrn ver detalles, y aadirlo a la cesta. Tambin se han definido una
estructura de acceso que permitir acceder a los autores por su letra inicial, adems de un
filtro de tipo aproximado (like) para facilitar la bsqueda por nombre.

Por ltimo, se construye el Modelo de Presentacin donde se definen los requisitos de

presentacin de la informacin para cada contexto del Mapa de Navegacin. Por ejemplo,
seguidamente se muestra la plantilla de presentacin asociada al contexto Autores.

Despus de la fase de construccin de los modelos, es necesario afrontar la segunda

fase, Desarrollo de la Solucin, donde utilizando una estrategia de compilacin de
modelos, se obtiene el prototipo software completo de manera automtica. A continuacin
se muestra una posible interfaz de usuario que cumple los requisitos de navegabilidad y
de interfaz del agente Usuario Navegante.

2.2.4 METODOLOGAS GILES

Luego de varias opiniones tanto a favor como en contra de las metodologas tradicionales
se genera un nuevo enfoque denominado, mtodos giles, que nace como respuesta a
los problemas detallados anteriormente y se basa en dos aspectos puntuales, el retrasar
las decisiones y la planificacin adaptativa; permitiendo potencia an ms el desarrollo de
software a gran escala.
Como resultado de esta nueva teora se crea un Manifiesto gil cuyas principales ideas
son:
Los individuos y las interacciones entre ellos son ms importantes que las herramientas y
los procesos empleados.
Es ms importante crear un producto software que funcione que escribir documentacin
exhaustiva.
La colaboracin con el cliente debe prevalecer sobre la negociacin de contratos.
La capacidad de respuesta ante un cambio es ms importante que el seguimiento estricto
de un plan.
Entre los principales mtodos giles tenemos el XP (eXtreme Programming), Scrum,
Iconix, Cristal Methods, AUP entre otras.
Estas metodologas ponen de relevancia que la capacidad de respuesta a un cambio es
ms importante que el seguimiento estricto de un plan. Nos lo proponen porque para
muchos clientes esta flexibilidad ser una ventaja competitiva y porque estar preparados
para el cambio significar reducir su coste.
Retrasar las decisiones y Planificacin Adaptativa

Es el eje en cual gira la metodologa gil, el retrasar las decisiones tan como sea posible
de manera responsable ser ventajoso tanto para el cliente como para la empresa, lo cual
permite siempre mantener una satisfaccin en el cliente y por ende el xito del producto,
las principales ventajas de retrasar las decisiones son:

Reduce el nmero de decisiones de alta inversin que se toman.

Reduce el nmero de cambios necesario en el proyecto.
Reduce el coste del cambio

La planificacin adaptativa permite estar preparados para el cambio ya que lo hemos

introducido en nuestro proceso de desarrollo, adems hacer una planificacin adaptativa
consiste en tomar decisiones a lo largo del proyecto, estaremos transformando el proyecto
en un conjunto de proyectos pequeos.
Esta planificacin a corto plazo nos permitir tener software disponible para nuestros
clientes y adems ir aprendiendo del feedback para hacer nuestra planificacin ms
sensible, sea ante inconvenientes que aceleren o retrasen nuestro producto. A
continuacin se detalla el XP que es el ms aceptado dentro del desarrollo de SW.
EXTREME---PROGRAMMING---(XP)
Es la ms destacada de los procesos agiles de desarrollo de software formulada por Kent
Beck. La programacin extrema se diferencia de las metodologas tradicionales
principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad.
Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un
aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser
capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto
es una aproximacin mejor y ms realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los
requisitos.
Las caractersticas fundamentales del mtodo son:
Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.
Pruebas Unitarias

continuas, frecuentemente repetidas y automatizadas, incluyendo

priebas de regresion. Se aconseja escribir el cdigo de la prueba antes de la codificacin.

Programacin por parejas: se recomienda que las tareas de desarrollo se lleven a cabo
por dos personas en un mismo puesto. Se supone que la mayor calidad del cdigo escrito

de esta manera -el cdigo es revisado y discutido mientras se escribe- es ms importante

que la posible prdida de productividad inmediata.

Frecuente interaccin del equipo de programacin con el cliente o usuario. Se

recomienda que un representante del cliente trabaje junto al equipo de desarrollo.

Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer
entregas frecuentes.

Refactorizacin: del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar
su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de
garantizar que en la refactorizacin no se ha introducido ningn fallo.
Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de
cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el
personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas
de regresin garantizan que los posibles errores sern detectados.
Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo
funcione se podr aadir funcionalidad si es necesario. La programacin extrema apuesta
que en ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si
se requiere, que realizar algo complicado y quizs nunca utilizarlo.
La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms
comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer. Mientras
ms simple es el sistema, menos tendr que comunicar sobre este, lo que lleva a una
comunicacin ms completa, especialmente si se puede reducir el equipo de
programadores.
Ventajas

Apropiado para entornos voltiles

Estar preparados para el cambio, significa reducir su coste.
Planificacin ms transparente para nuestros clientes, conocen las fechas de

entrega de funcionalidades. Vital para su negocio

Permitir definir en cada iteracin cuales son los objetivos de la siguiente
Permite tener realimentacin de los usuarios muy til.
La presin esta a lo largo de todo el proyecto y no en una entrega final

Desventajas

Delimitar el alcance del proyecto con nuestro cliente

Para mitigar esta desventaja se plantea definir un alcance a alto nivel basado en la
experiencia.
Ejemplo:
Las metodologas giles se han convertido en los ltimos aos en los principales mtodos
a seguir por la gran mayora de empresas de desarrollo de software. En 2001, diecisiete
prestigiosos ingenieros, convocados por Kent Beck, crearon un manifiesto que dictaba
doce principios bsicos sobre las metodologas giles.
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua
de software con valor.

Aceptamos que los requisitos cambien, incluso en etapas tardas del desarrollo. Los

procesos giles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con

preferencia al periodo de tiempo ms corto posible.

Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana

durante todo el proyecto.

Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y

el apoyo que necesitan, y confiarles la ejecucin del trabajo.

El mtodo ms eficiente y efectivo de comunicar informacin al equipo de desarrollo y entre

sus miembros es la conversacin cara a cara.

El software funcionando es la medida principal de progreso.
Los procesos giles promueven el desarrollo sostenible. Los promotores, desarrolladores y

usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

La atencin continua a la excelencia tcnica y al buen diseo mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseos emergen de equipos auto-organizado

A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para a

continuacin ajustar y perfeccionar su comportamiento en consecuencia.
A partir de estos principios, se definen diferentes metodologas reconocidas como giles
basadas en el desarrollo iterativo e incremental, donde los requisitos y soluciones
evolucionan mediante la colaboracin de grupos auto-organizados y multidisciplinarios. La
forma de dirigir el desarrollo del proyecto cambia en comparacin a la forma tradicional,
las etapas estn fraccionadas en unidades de requisitos que avanzan en diferente tiempo,
por lo que permite mayor flexibilidad a la hora de seguir el proceso de ingeniera.
Figura 1

Comparacin del mtodo tradicional respecto al mtodo gil

Entre esta familia de metodologas destacan Scrum, Kanban, o eXtreme Programming.
Cada una con sus peculiaridades, sus pros y sus contras. Aunque lo cierto es que como
dijo Corey Ladas: El proceso de planificacin del trabajo ideal debera siempre ser
proporcionado por el equipo de desarrollo con el mejor propsito para trabajar en lo
siguiente, ni ms ni menos.. Por esa misma razn seguir una metodologa depender del
equipo y despus del proyecto, pudiendo hibridar las metodologas para el ajuste correcto.
En este proyecto se ha tomado como base la metodologa Scrumban y se han adoptado
otras caractersticas de otras metodologas giles, hasta conseguir la metodologa de
trabajo.

2.2.5 METODOLOGAS EMERGENTES

ICONIX:
El proceso ICONIX se define como un proceso de desarrollo de software prctico.
Est entre la complejidad de RUP y la simplicidad y pragmatismo de XP, sin
eliminar

las

tareas

de

anlisis

diseo

que

XP

no

contempla.

Es un proceso simplificado en comparacin con otros procesos ms tradicionales,

que unifica un conjunto de mtodos de orientacin a objetos con el objetivo de
abarcar todo el ciclo de vida de un proyecto. ICONIX presenta claramente las
actividades de cada fase y exhibe una secuencia de pasos que deben ser
seguidos. Adems, est adaptado a patrones y ofrece el soporte UML, dirigido por
Casos
Las

de

Uso

tres

es

caractersticas

un

proceso

iterativo

fundamentales

de

incremental.

ICONIX

son:

Iterativo e incremental: varias interacciones ocurren entre el modelo del dominio

y la identificacin de los casos de uso. El modelo esttico es incrementalmente
refinado

por

los

modelos

dinmicos.

Trazabilidad: cada paso est referenciado por algn requisito. Se define la

trazabilidad como la capacidad de seguir una relacin entre los diferentes
artefactos

producidos

Dinmica del UML: la metodologa ofrece un uso dinmico del UML como los
diagramas del caso de uso, diagramas de secuencia y de colaboracin.
Las tareas que se realizan en la metodologa ICONIX son:

Anlisis de requisitos
Anlisis y diseo preliminar
Diseo
Implementacin

Fundamentos de los procesos

Tiene que ser lo suficientemente flexible como para adaptarse a diferentes

estilos y tipos de problemas.

Hay que apoyar la forma de trabajo del personal (incluidos los prototipos y

desarrollo iterativo / incremental).

Sirve como una gua para los menos experimentados
Expone los productos anteriores al cdigo de manera estndar y
comprensible.

Fases de ICONIX
Revisin de los requisitos/ Anlisis de Requisitos: Identificar en el mundo real, los
objetos y todas las relaciones de agregacin y generalizacin entre ellos. Se
deben analizar todos los requisitos formaran parte del sistema y con estos
construir el diagrama de clases, que representa las agrupaciones funcionales que
estructuraran el sistema en desarrollo.
Para esta fase se utilizan 3 herramientas
Modelo de Dominio: esto se refiere a identificar objetos y cosas del mundo real
que intervienen con nuestro sistema. (Esttico)
Modelo de Casos de Uso: describe las acciones o el comportamiento que un
usuario realiza dentro del sistema. Comprende de actores, casos de uso y el
sistema.
Prototipo de Interfaz de Usuario: implica la creacin de un modelo o modelos
operativos del trabajo de un sistema, en el que analistas y clientes deben estar de
acuerdo. (Dinmico/ los usuarios se hacen participantes activos en el desarrollo)
Revisin del diseo preliminar /Anlisis y Diseo Preliminar
En esta fase a partir de cada caso de uso se obtendrn una ficha de caso de uso,
(la cual no pertenece a UML) , est formada por un nombre, una descripcin, una
precondicin que debe cumplir antes de iniciarse, una postcondicion que debe
cumplir al terminar si termina correctamente.

Diagrama de Robustez: Un diagrama de robustez es un hbrido entre un

Diagrama de Clases y un Diagrama de Actividades. Es una herramienta que nos
permite capturar el Que hacer y a partir de eso l Como hacerlo.
Facilita el reconocimiento de objetos y hace ms sencilla la lectura del sistema.
Ayuda a identificar los objetos que participan en cada caso de uso.
El diagrama de Robustez se divide en:
Objetos fronterizos: usado por los actores para comunicarse con el sistema.
Objetos entidad: son objetos del modelo del dominio.
Objetos de Control: es la unin entre la interfaz y los objetos de entidad.
Diagrama de Clases: describe la estructura de un sistema mostrando sus clases,
atributos y las relaciones entre ellos
Revisin crtica del diseo/Diseo
En esta fase se reconocen todos los elementos que forman parte de nuestro
sistema.
Diagramas de Secuencia: muestra los mtodos que llevaran las clases de
nuestro sistema. Muestra todos los cursos alternos que pueden tomar todos
nuestros casos de uso.
Se debe terminar el modelo esttico, aadiendo los detalles del diseo en el
diagrama de clases.
Implementacin
En esta fase a partir del buen diseo logrado se creara el software; que
posteriormente se entregara.
Ejemplo:
Roles XP

Aunque en otras fuentes de informacin aparecen algunas variaciones y

extensiones de roles XP, en este apartado describiremos los roles de acuerdo con
la propuesta original de Beck.
Programador
El programador escribe las pruebas unitarias y produce el cdigo del sistema.
Debe existir una comunicacin y coordinacin adecuada entre los programadores
y otros miembros del equipo.
Cliente
El cliente escribe las historias de usuario y las pruebas funcionales para validar su
implementacin. Adems, asigna la prioridad a las historias de usuario y decide
cules se implementan en cada iteracin centrndose en aportar mayor valor al
negocio. El cliente es slo uno dentro del proyecto pero puede corresponder a un
interlocutor que est representando a varias personas que se vern afectadas por
el sistema.
Encargado de pruebas (Tester)
El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.
Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es
responsable de las herramientas de soporte para pruebas.
Encargado de seguimiento (Tracker)
El encargado de seguimiento proporciona realimentacin al equipo en el proceso
XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones
realizadas y el tiempo real dedicado, comunicando los resultados para mejorar
futuras estimaciones. Tambin realiza el seguimiento del progreso de cada
iteracin y evala si los objetivos son alcanzables con las restricciones de tiempo y
recursos presentes. Determina cundo es necesario realizar algn cambio para
lograr los objetivos de cada iteracin.
Entrenador (Coach)

Es responsable del proceso global. Es necesario que conozca a fondo el proceso

XP para proveer guas a los miembros del equipo de forma que se apliquen las
prcticas XP y se siga el proceso correctamente.
Consultor
Es un miembro externo del equipo con un conocimiento especfico en algn tema
necesario para el proyecto. Gua al equipo para resolver un problema especfico.
Gestor (Big boss)
Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje
efectivamente creando las condiciones adecuadas. Su labor esencial es de
coordinacin.
PROCESO XP
Un proyecto XP tiene xito cuando el cliente selecciona el valor de negocio a
implementar basado en la habilidad del equipo para medir la funcionalidad que
puede entregar a travs del tiempo. El ciclo de desarrollo consiste (a grandes
rasgos) en los siguientes pasos:
El cliente define el valor de negocio a implementar.
El programador estima el esfuerzo necesario para su implementacin.
El cliente selecciona qu construir, de acuerdo con sus prioridades y las
restricciones de tiempo.
El programador construye ese valor de negocio.
Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador
aprenden. No se debe presionar al programador a realizar ms trabajo que el
estimado, ya que se perder calidad en el software o no se cumplirn los plazos.
De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega

del producto, para asegurarse que el sistema tenga el mayor valor de negocio
posible con cada iteracin.
El ciclo de vida ideal de XP consiste de seis fases: Exploracin, Planificacin de la
Entrega (Release), Iteraciones, Produccin, Mantenimiento y Muerte del Proyecto.
Fase I: Exploracin
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que
son de inters para la primera entrega del producto. Al mismo tiempo el equipo de
desarrollo se familiariza con las herramientas, tecnologas y prcticas que se
utilizarn en el proyecto. Se prueba la tecnologa y se exploran las posibilidades
de la arquitectura del sistema construyendo un prototipo. La fase de exploracin
toma de pocas semanas a pocos meses, dependiendo del tamao y familiaridad
que tengan los programadores con la tecnologa.
Fase II: Planificacin de la Entrega
En esta fase el cliente establece la prioridad de cada historia de usuario, y
correspondientemente, los programadores realizan una estimacin del esfuerzo
necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la
primera entrega y se determina un cronograma en conjunto con el cliente. Una
entrega debera obtenerse en no ms de tres meses. Esta fase dura unos pocos
das.
Las estimaciones de esfuerzo asociado a la implementacin de las historias la
establecen los programadores utilizando como medida el punto. Un punto,
equivale a una semana ideal de programacin. Las historias generalmente valen
de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la
"velocidad" de desarrollo, establecida en puntos por iteracin, basndose
principalmente en la suma de puntos correspondientes a las historias de usuario
que fueron terminadas en la ltima iteracin.
La planificacin se puede realizar basndose en el tiempo o el alcance. La
velocidad del proyecto es utilizada para establecer cuntas historias se pueden

implementar antes de una fecha determinada o cunto tiempo tomar implementar

un conjunto de historias. Al planificar por tiempo, se multiplica el nmero de
iteraciones por la velocidad del proyecto, determinndose cuntos puntos se
pueden completar. Al planificar segn alcance del sistema, se divide la suma de
puntos de las historias de usuario seleccionadas entre la velocidad del proyecto,
obteniendo el nmero de iteraciones necesarias para su implementacin.
Fase III: Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El
Plan de Entrega est compuesto por iteraciones de no ms de tres semanas. En la
primera iteracin se puede intentar establecer una arquitectura del sistema que
pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las
historias que fuercen la creacin de esta arquitectura, sin embargo, esto no
siempre es posible ya que es el cliente quien decide qu historias se
implementarn en cada iteracin (para maximizar el valor de negocio). Al final de
la ltima iteracin el sistema estar listo para entrar en produccin.
Los elementos que deben tomarse en cuenta durante la elaboracin del Plan de la
Iteracin son: historias de usuario no abordadas, velocidad del proyecto, pruebas
de aceptacin no superadas en la iteracin anterior y tareas no terminadas en la
iteracin anterior. Todo el trabajo de la iteracin es expresado en tareas de
programacin, cada una de ellas es asignada a un programador como
responsable, pero llevadas a cabo por parejas de programadores. Wake en [18]
proporciona algunas guas tiles para realizar la planificacin de la entrega y de
cada iteracin.

Fase IV: Produccin

La fase de produccin requiere de pruebas adicionales y revisiones de rendimiento
antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se

deben tomar decisiones sobre la inclusin de nuevas caractersticas a la versin

actual, debido a cambios durante esta fase.
Es posible que se rebaje el tiempo que toma cada iteracin, de tres a una semana.
Las ideas que han sido propuestas y las sugerencias son documentadas para su
posterior implementacin (por ejemplo, durante la fase de mantenimiento).
Fase V: Mantenimiento
Mientras la primera versin se encuentra en produccin, el proyecto XP debe
mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas
iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De
esta forma, la velocidad de desarrollo puede bajar despus de la puesta del
sistema en produccin. La fase de mantenimiento puede requerir nuevo personal
dentro del equipo y cambios en su estructura.
Fase VI: Muerte del Proyecto
Es cuando el cliente no tiene ms historias para ser incluidas en el sistema. Esto
requiere que se satisfagan las necesidades del cliente en otros aspectos como
rendimiento y confiabilidad del sistema. Se genera la documentacin final del
sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto
tambin ocurre cuando el sistema no genera los beneficios esperados por el
cliente o cuando no hay presupuesto para mantenerlo.
PRCTICAS XP
La principal suposicin que se realiza en XP es la posibilidad de disminuir la mtica
curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para
que el diseo evolutivo funcione. XP apuesta por un crecimiento lento del costo del
cambio y con un comportamiento asinttico. Esto se consigue gracias a las
tecnologas disponibles para ayudar en el desarrollo de software y a la aplicacin
disciplinada de las prcticas que describiremos a continuacin.
El juego de la planificacin

Es un espacio frecuente de comunicacin entre el cliente y los programadores. El

equipo

tcnico

realiza

una

estimacin

del

esfuerzo

requerido

para

la

implementacin de las historias de usuario y los clientes deciden sobre el mbito y

tiempo de las entregas y de cada iteracin. Esta prctica se puede ilustrar como
un juego, donde existen dos tipos de jugadores: Cliente y Programador. El cliente
establece la prioridad de cada historia de usuario, de acuerdo con el valor que
aporta para el negocio. Los programadores estiman el esfuerzo asociado a cada
historia de usuario. Se ordenan las historias de usuario segn prioridad y esfuerzo,
y se define el contenido de la entrega y/o iteracin, apostando por enfrentar lo de
ms valor y riesgo cuanto antes. Este juego se realiza durante la planificacin de
la entrega, en la planificacin de cada iteracin y cuando sea necesario reconducir
el proyecto.
Entregas pequeas
La idea es producir rpidamente versiones del sistema que sean operativas,
aunque obviamente no cuenten con toda la funcionalidad pretendida para el
sistema pero s que constituyan un resultado de valor para el negocio. Una
entrega no debera tardar ms 3 meses.
Metfora
En XP no se enfatiza la definicin temprana de una arquitectura estable para el
sistema. Dicha arquitectura se asume evolutiva y los posibles inconvenientes que
se generaran por no contar con ella explcitamente en el comienzo del proyecto
se solventan con la existencia de una metfora. El sistema es definido mediante
una metfora o un conjunto de metforas compartidas por el cliente y el equipo de
desarrollo. Una metfora es una historia compartida que describe cmo debera
funcionar el sistema. Martin Fowler explica que la prctica de la metfora consiste
en formar un conjunto de nombres que acten como vocabulario para hablar sobre
el dominio del problema. Este conjunto de nombres ayuda a la nomenclatura de
clases y mtodos del sistema.
Diseo simple

Se debe disear la solucin ms simple que pueda funcionar y ser implementada

en un momento determinado del proyecto. La complejidad innecesaria y el cdigo
extra debe ser removido inmediatamente. Kent Beck dice que en cualquier
momento el diseo adecuado para el software es aquel que: supera con xito
todas las pruebas, no tiene lgica duplicada, refleja claramente la intencin de
implementacin de los programadores y tiene el menor nmero posible de clases y
mtodos.
Pruebas
La produccin de cdigo est dirigida por las pruebas unitarias. Las pruebas
unitarias son establecidas antes de escribir el cdigo y son ejecutadas
constantemente ante cada modificacin del sistema. Los clientes escriben las
pruebas funcionales para cada historia de usuario que deba validarse. En este
contexto de desarrollo evolutivo y de nfasis en pruebas constantes, la
automatizacin para apoyar esta actividad es crucial.
Refactorizacin (Refactoring)
La refactorizacin es una actividad constante de reestructuracin del cdigo con el
objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y
hacerlo ms flexible para facilitar los posteriores cambios. La refactorizacin
mejora la estructura interna del cdigo sin alterar su comportamiento externo.
Robert Martin seala que el diseo del sistema de software es una cosa viviente.
No se puede imponer todo en un inicio, pero en el transcurso del tiempo este
diseo evoluciona conforme cambia la funcionalidad del sistema. Para mantener
un diseo apropiado, es necesario realizar actividades de cuidado continuo
durante el ciclo de vida del proyecto. De hecho, este cuidado continuo sobre el
diseo es incluso ms importante que el diseo inicial. Un concepto pobre al inicio
puede ser corregido con esta actividad continua, pero sin ella, un buen diseo
inicial se degradar.
Programacin en parejas

Toda la produccin de cdigo debe realizarse con trabajo en parejas de

programadores. Segn Cockburn y Williams en un estudio realizado para
identificar los costos y beneficios de la programacin en parejas, las principales
ventajas de introducir este estilo de programacin son: muchos errores son
detectados conforme son introducidos en el cdigo (inspecciones de cdigo
continuas), por consiguiente la tasa de errores del producto final es ms baja, los
diseos son mejores y el tamao del cdigo menor (continua discusin de ideas
de los programadores), los problemas de programacin se resuelven ms rpido,
se posibilita la transferencia de conocimientos de programacin entre los
miembros del equipo, varias personas entienden las diferentes partes sistema, los
programadores conversan mejorando as el flujo de informacin y la dinmica del
equipo, y finalmente, los programadores disfrutan ms su trabajo. Dichos
beneficios se consiguen despus de varios meses de practicar la programacin en
parejas. En los estudios realizados por Cockburn y Williams este lapso de tiempo
vara de 3 a 4 meses.
Propiedad colectiva del cdigo
Cualquier programador puede cambiar cualquier parte del cdigo en cualquier
momento. Esta prctica motiva a todos a contribuir con nuevas ideas en todos los
segmentos del sistema, evitando a la vez que algn programador sea
imprescindible para realizar cambios en alguna porcin de cdigo.
Integracin contina
Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el
sistema puede llegar a ser integrado y construido varias veces en un mismo da.
Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo
cdigo sea incorporado definitivamente. La integracin continua a menudo reduce
la fragmentacin de los esfuerzos de los desarrolladores por falta de comunicacin
sobre lo que puede ser reutilizado o compartido. Martin Fowler afirma que el
desarrollo de un proceso disciplinado y automatizado es esencial para un proyecto
controlado, el equipo de desarrollo est ms preparado para modificar el cdigo

cuando sea necesario, debido a la confianza en la identificacin y correccin de

los errores de integracin.
40 horas por semana
Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras
en dos semanas seguidas. Si esto ocurre, probablemente est ocurriendo un
problema que debe corregirse. El trabajo extra desmotiva al equipo. Los proyectos
que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser
entregados con retraso. En lugar de esto se puede realizar el juego de la
planificacin para cambiar el mbito del proyecto o la fecha de entrega.
Cliente in-situ
El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran
parte del xito del proyecto XP se debe a que es el cliente quien conduce
constantemente el trabajo hacia lo que aportar mayor valor de negocio y los
programadores pueden resolver de manera inmediata cualquier duda asociada. La
comunicacin oral es ms efectiva que la escrita, ya que esta ltima toma mucho
tiempo en generarse y puede tener ms riesgo de ser mal interpretada. Jeffries
indica que se debe pagar un precio por perder la oportunidad de un cliente con
alta disponibilidad. Algunas recomendaciones propuestas para dicha situacin son
las siguientes: intentar conseguir un representante que pueda estar siempre
disponible y que acte como interlocutor del cliente, contar con el cliente al menos
en las reuniones de planificacin, establecer visitas frecuentes de los
programadores al cliente para validar el sistema, anticiparse a los problemas
asociados

estableciendo

llamadas

telefnicas

frecuentes

conferencias,

reforzando el compromiso de trabajo en equipo.

Estndares de programacin
XP enfatiza la comunicacin de los programadores a travs del cdigo, con lo cual
es indispensable que se sigan ciertos estndares de programacin (del equipo, de
la organizacin u otros estndares reconocidos para los lenguajes de

programacin utilizados). Los estndares de programacin mantienen el cdigo

legible para los miembros del equipo, facilitando los cambios.
Comentarios respecto de las prcticas
El mayor beneficio de las prcticas se consigue con su aplicacin conjunta y
equilibrada puesto que se apoyan unas en otras.
La mayora de las prcticas propuestas por XP no son novedosas sino que en
alguna forma ya haban sido propuestas en ingeniera del software e incluso
demostrado su valor en la prctica El mrito de XP es integrarlas de una forma
efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los
valores humanos y el trabajo en equipo.

Figura 1. Las prcticas se refuerzan entre s

2.2.6 REINGENIERIA
Reingeniera de Software es una forma de modernizacin para mejorar las
capacidades y/o mantenibilidad de los sistemas de informacin heredados
mediante la aplicacin de tecnologas y prcticas modernas. La Reingeniera de
Software ofrece una disciplina de preparacin para migrar un sistema de

informacin heredado hacia un sistema evolucionable. El proceso aplica principios

de ingeniera para un sistema existente para encontrar nuevos requerimientos.
La reingeniera cuenta entre sus objetivos con:
Proporcionar asistencia automatizada para el mantenimiento.
Reducir los errores y costos del mantenimiento
Incrementar la intercambialidad del grupo de mantenimiento
Hacer sistemas fciles de entender, cambiar y probar.
Habilitar la conversin y migracin de sistemas.
Reforzar el apego a estndares.
Mejorar la respuesta a peticiones de mantenimiento.
Mejorar el estado de animo del grupo de mantenimiento.
Proteger y extender la vida del sistema.
Usar CASE para apoyar sistemas existentes.
Re-usar componentes de sistema existentes.

Hacer Reingeniera de un sistema de software, segn Ian Sommerville, tiene dos

ventajas clave sobre aproximaciones ms radicales a la evolucin del sistema:
Riego reducido. Existe un alto riesgo en volver a desarrollar software critico para
los negocios. Pueden cometerse errores en la especificacin, o puede haber
problemas en el desarrollo. Los retrasos en la introduccin del nuevo software
pueden significar perdidas en el negocio e incurrir en costes adicionales. Por
ejemplo, en 1999 una gran compaa de comida de EU tuvo retrasos en la
introduccin de un nuevo sistema de pedidos, lo que condujo a retrasos en las

entregas de productos valoradas en 100 millones de dlares en una estacin de

mxima venta.
Coste reducido. El coste de hacer reingeniera es significativamente menor que el
coste de desarrollar nuevo software. Ulrich cita un ejemplo de un sistema
comercial en el que los costes de reimplementacin se estimaron en 50 millones
de dlares. Al sistema se le aplico reingeniera con xito por 12 millones de
dlares. Se presume que, con la tecnologa moderna del software, el coste relativo
de la reimplementacion probablemente sea menor. Pero aun as supera de forma
considerable los costes de la reingeniera.
Desventaja:
La principal desventaja de la reingeniera del software es que existen limites
prcticos a la extensin del sistema que puede ser mejorada mediante
reingeniera. No es posible. Por ejemplo, convertir un sistema diseado utilizando
una aproximacin funcional en un sistema orientado a objetos. Los cambios
arquitectnicos mayores o la reorganizacin radical de la gestin de datos del
sistema no pueden realizarse de forma automtica, por lo que se incurrir en
costes

adicionales

elevados.

Aunque

la

reingeniera

puede

mejorar

la

mantenibilidad, el sistema al que se va a aplicar reingeniera probablemente no

ser tan mantenible como un nuevo sistema desarrollado utilizando mtodos
modernos de ingeniera de software.
Durante la reingeniera del programa, los datos del sistema tambin sufren
reingeniera.
Las actividades de este proceso de reingeniera son:
Traduccin del cdigo fuente. El programa es convenido desde un lenguaje de
programacin antiguo a una versin ms moderna del mismo lenguaje o a un
lenguaje diferente.
Ingeniera Inversa. El programa se analiza y se extrae informacin a partir de l.
Esto ayuda a documentar su organizacin y funcionalidad.

Mejora de la estructura de los programas. La estructura de control del programa se

analiza y modifica para hacerla ms fcil de leer y comprender.
Popularizacin de los programas. Se agrupan las panes relacionadas del
programa y se elimina la redundancia en donde resulta adecuado. En algunos
casos. esta etapa puede implicar una transformacin arquitectnica en la que un
sistema centralizado pensado para una nica computadora se modifica para
ejecutarse sobre una plataforma distribuida.
Reingeniera de datos. Los datos procesados por el programa se cambian para
reflejar los cambios en l.
Aunque la reingeniera se usa principalmente durante el mantenimiento del
software, va mas all de una simple ayuda de mantenimiento. La reingeniera es el
puente desde las viejas hacia las nuevas tecnologas que las organizaciones
deben usar en la actualidad para responder al cambio de requerimientos del
negocio.
BENEFICIOS DE LA REINGENIERA
Procesos sencillos, fciles de administrar y controlar
Menores costos por reduccin o eliminacin de duplicidad de funciones, trabajos
que no agregan valor, retrabajos y errores, reduccin del ciclo delos procesos
Mayor satisfaccin de los clientes, como resultado de un mejor desempeo en las
reas crticas y estratgicas del negocio
Mejor imagen de la empresa ante el mercado
Oportunidades de aumentar ventas
Mejor clima organizacional, como resultado de la mayor responsabilidad y
autoridad de los empleados, del desarrollo de su potencial y habilidades, y del
mayor involucramiento entre la administracin y la fuerza de trabajo
Ejemplo:

Conclusin

Teniendo claro las caractersticas y similitudes que existen entre los mtodos de
desarrollo de software, podrs analizar casos que sean resueltos por el mtodo
que mejor se adapte, por eso debemos
solucione

el caso

de estudio

mediante

seleccionar el mtodo adecuado que

el

anlisis

de

estos

modelos.

Permitindonos una mejor eficiencia y un buen resultado al implementar y crear un

software ya que gracias a estas metodologas y componentes que conformar cada
una de estas, se pueden ahorrar trabajo, dinero y tiempo que son los factores
principales para poder emprender un proyecto de software y tener un buen
desarrollo laboral y socialmente

Bibliografa

Libro: ingeniera del software un enfoque prctico, Quinta edicin; Roger S.

Pressman
http://www.ptolomeo.unam.mx:8080/xmlui/
http://ithjlmvu2.blogspot.mx/
http://dianao9.blogspot.mx/
http://fgaith2.blogspot.mx/
Sicilia, M. (2015). OpenStax CNX. [online] Cnx.org. Available at:
http://cnx.org/contents/8d78fc4c-0db4-4c8f-96d4-13e9a2c03a5c@3/Qu-es-

Reingeniera-del-Software [Accessed 14 Sep. 2015].

Garcia, F. (2013). Unidad II-Metodologias de

desarrollo.

[online]

Fgaith2.blogspot.com. Available at: http://fgaith2.blogspot.com/ [Accessed

14 Sep. 2015].
Bergey, John & Smith Dennis "Guidelines for Using OAR
Concepts in a DoD Product Line Acquisition Context"
(CMU/SEI-2000-TN-004). Pittsburgh, Pa.: Software
Engineering Institute, Carnegie Mellon University, 2000
Bass, L & Kazman, R. Architecture-Based Development

(CMU/SEI-99-TR-007). Pittsburgh, Pa.: Software Engineering

Institute, Carnegie Mellon University, 1999

Business Week, www.e.biz.online.com/9903
Davenport, Thomas H., Will Participative Makeovers of Business Processes
Succeed Where Reengineering Failed? Planning Review, January 1995; Pg.

24.
Diario La Nacin 2/5/99
Economist Newspaper Group, Reengineering Reviewed, The Economist,

Junio 1994, Pg 24.

Beck, 2004) Beck, K. Extreme programming explained: embrace change.

Addison-Wesley, 2004.
(Humphrey, 2004a) Humphrey, W.S. Introduction to the personal software

process. SEI Series in Software Engineering. AddisonWesley, 2004.

(Humphrey, 2004b) Humphrey, W.S. Introduction to the team software
process. SEI Series in Software Engineering. Addison-Wesley, 2004.

(Humphrey, 2004c) Humphrey, W.S. A discipline for software engineering.

SEI Series in Software Engineering. Addison-Wesley, 2004.

Glosario
Uml: es un lenguaje grfico para visualizar, especificar, construir y documentar un
sistema.
Rup: es un proceso de desarrollo de software y junto con el lenguaje unificado de
modelado uml, constituye la metodologa estndar ms utilizada para el anlisis,
implementacin y documentacin de sistemas orientados a objetos.
Sistema informtico: un sistema informtico como todo sistema, es el conjunto
de partes interrelacionadas, hardware, software y de recurso humano
Reingeniera: la reconcepcin fundamental y el rediseo radical de los procesos
de negocios para lograr mejoras dramticas en medidas de desempeo tales
como en costos, calidad, servicio y rapidez
Previsibilidad:
que puede ser previsto o conocido con antelacin por medio de ciertas seales o i
ndicios:
Bucle: en el mbito de la programacin, un bucle o loop es una estructura que
posibilita la repeticin de sentencias en muchas oportunidades.
Mdulo administrativo: en el cual el usuario, puede a su voluntad, administrar
la informacin bsica necesaria para que el sistema funcione. Ejemplo: la
configuracin de horarios de carga de informacin, la asignacin de Operadores
de Red que hacen parte del esquema.
Mdulo de cargas: para calcular el ITAD, se necesita de la informacin diaria
de

los eventos en los SDL. Para tal fin se cre un sistema que permite recibir la

informacin, su correspondiente validacin en lnea y su posterior descarga.

Mdulos de clculos: una vez se cuenta con los

insumos,

previamente

validados, se procede con los clculos intermedios hasta llegar al ITAD.

Mdulo de reportes: en este paquete, se encuentran todas las consultas que

se requieren del sistema. Algunas pueden ser las fechas de carga, los valores de
energa, las interrupciones entre otras.