INGENIERIA DE SOFTWARE

Unidad II. Metodologas de desarrollo

El desarrollo de un producto software de cierta complejidad es un
desafo intelectual tanto para la organizacin en la que se desarrolla
como para cada una de las personas que intervienen. Estos dos factores,
humano y organizativo, se relacionan durante el proceso de gestacin
del producto.
La ingeniera de software se preocupa principalmente del proceso de
desarrollo que implica a un equipo numeroso de personas en el
desarrollo de sistemas de software complejos. En estos casos, cada
ingeniero de software forma parte de un equipo de trabajo y desarrolla
su actividad en relacin con los componentes del mismo.
En funcin de las actividades y de los conocimientos necesarios para
realizarlas, cada integrante del equipo de trabajo posee un perfil tcnico
especializado. Los perfiles necesarios, aunque no totalmente disjuntos,
permiten establecer una primera divisin del trabajo durante el proceso
de desarrollo.
Los individuos que forman parte del desarrollo de un sistema deben
conocer sus obligaciones a nivel individual, poseer los conocimientos
requeridos para ello e incluso deben realizar adecuadamente las
actividades encomendadas, pero es necesario establecer una clara
dependencia y control de las actividades de desarrollo, conseguir una
eficaz gestin de los recursos implicados y, finalmente, asegurar un nivel
de calidad adecuado a lo largo de todo el proceso.
Un conjunto de actividades, orientadas a un fin concreto, empleando y
generando determinada informacin relativa al sistema en desarrollo se
denomina proceso. Como ejemplo, un proceso sera la obtencin de una
nueva versin de un sistema; otro, la prueba de mdulos ya
implementados; otro ms, la animacin de un modelo del sistema de
software durante las primeras fases.
Para cada uno de los procesos se requiere fijar unas actividades,
responsables, entradas y salidas, planificacin temporal y de recursos
necesarios, y mecanismos para asegurar que se realiza correctamente.
Los modelos prescriptivos de proceso definen un conjunto de
actividades, acciones, tareas, fundamentos y productos de trabajo que
se requieren para producir software de alta calidad. No son perfectos,
pero son una gua para el trabajo de los ingenieros de software.
El modelo de proceso de software es importante porque proporciona
estabilidad, control y organizacin al desarrollo del software.

La aplicacin de estos modelos produce como resultado programas,

documentos y datos como consecuencia de las actividades y tareas que
definen el proceso.
2.1
Metodologas clsicas
A partir de los aos setenta, se haba acumulado suficiente experiencia
sobre el desarrollo de productos software para poder identificar un
conjunto de actividades comunes a todos los proyectos. Asimismo, la
estructura organizativa requerida para controlar su ejecucin y la forma
en la que el control de calidad aseguraba la validez de un determinado
producto eran suficientemente conocidas como para definir marcos de
referencia utilizables en nuevos proyectos de desarrollo. Esta idea
desemboc en el concepto de modelo de ciclo de vida de un producto
software.
Por ciclo de vida de un producto software se entiende la secuencia de
fases, actividades en cada una de ellas, controles para pasar de una fase
a otra y resultados generados en cada una de ellas que permiten el
desarrollo de un producto desde su concepcin, entrega al usuario, y
evolucin posterior, hasta su retirada del mercado.
Cualquier organizacin debe definir un conjunto nico de actividades
dentro del marco de trabajo para el o los procesos de software que
adopte. Tambin debe llenar cada actividad del marco de trabajo con un
conjunto de tareas que identifique el trabajo y los productos del trabajo
que deben completarse para alcanzar las metas de desarrollo. Despus
la organizacin debe adaptar el modelo de proceso resultante y ajustarlo
a la naturaleza especfica de cada proyecto, a las personas que lo
realizarn, y el ambiente en el que se ejecutar el trabajo. Sin importar
el modelo del proceso seleccionado, los ingenieros de software han
elegido de manera tradicional un marco de trabajo genrico para el
proceso, el cual incluye las siguientes actividades dentro del marco:
comunicacin, planeacin, modelado, construccin y despliegue.
2.1.1 Cascada
Es el paradigma ms antiguo de la ingeniera de software, tambin
llamado modelo del ciclo de vida clsico, donde se sugiere un enfoque
sistemtico, secuencial hacia el desarrollo de software, que se inicia con
la especificacin de los requerimientos del cliente y que contina con la
planeacin, el modelado, la construccin y el despliegue para culminar
con el soporte del software terminado.
Anlisis de los requisitos del software. El proceso de reunin de
requisitos se intensifica y se centra especialmente en el software. Para
comprender la naturaleza del (los) programa(s) a construirse, el
ingeniero (analista) del software debe comprender el dominio de

informacin
del
software,
as
como
la
comportamiento, rendimiento e interconexin.

funcin

requerida,

El objetivo de la fase de definicin de requisitos (tambin se le suele

denominar de especificacin de requisitos) es obtener una clara
comprensin del problema a resolver, extraer las necesidades del
usuario y derivar de ellas las funciones que debe realizar el sistema.
Esta fase suele subdividirse en dos subfases: anlisis de requisitos de
usuario y anlisis de requisitos de sistema.
La subfase de anlisis de requisitos de usuario tiene como objetivo
conocer las necesidades de los usuarios y cules deben ser los servicios
que un sistema de software debe ofrecerles para satisfacerlas. La fase
implica la creacin del Documento de Requisitos de Usuario (DRU) que
constituye el documento base para que, al final del desarrollo, el sistema
sea aceptado por el usuario.
La subfase de anlisis de requisitos del sistema consiste en la
construccin de un modelo lgico del sistema de software describiendo
las funciones que sean necesarias (sin tomar ninguna decisin sobre
cmo implementarlas) y las relaciones entre ellas suponiendo que no
existen limitaciones de recursos.
Por modelo lgico se entiende la identificacin de las funciones de
software requeridas para satisfacer los requisitos del usuario. Esta
identificacin se suele realizar en varios niveles de detalle hasta llegar a
uno en el que las funciones identificadas estn suficientemente claras
de tal forma que no exija un refinamiento posterior.
El producto generado en esta fase es el Documento de Requisitos de
Software (DRS). Tambin se genera en esta sub-fase el plan de gestin
del desarrollo con estimaciones de costos y recursos ms ajustados que
en la sub-fase anterior.
Es importante distinguir en esta subfase entre requisitos funcionales
(aquellos ligados a la relacin entre datos de entrada y resultados (datos
de salida) que debe presentar el sistema, incluidos los derivados de
restricciones temporales cuando stas estn cuantificadas) y requisitos
no funcionales (que incluyen todos los aspectos de calidad del
sistema: por ejemplo, mantenibilidad (facilidad para que el sistema
evolucione y se modifique una vez entregado al usuario), escalabilidad
(posibilidad de incrementar sustancialmente el nmero de usuarios u
otros parmetros), facilidad de uso, etc., que no pueden ligarse a
funciones concretas dentro del sistema.
Diseo. El diseo del software es realmente un proceso de muchos
pasos que se centra en cuatro atributos distintos de programa:
estructura de datos, arquitectura de software, representaciones de
interfaz y detalle procedimental (algoritmo). El proceso del diseo

traduce requisitos en una representacin del software donde se pueda

evaluar su calidad antes de que comience la codificacin.
La fase de diseo tiene como objetivo determinar una solucin a los
requisitos del sistema definidos en la fase anterior. Obviamente, existen
muchas maneras de satisfacer los requisitos y, por tanto, multitud de
diseos posibles.
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, documento resultante: Documento de Diseo Detallado
(DDD).
En la subfase de diseo arquitectnico se parte del modelo lgico
generado en la fase de definicin de requisitos software y se transforma
en una arquitectura agrupando las funciones identificadas en
componentes software. Asimismo, se define la activacin y
desactivacin de cada uno de los componentes y el intercambio de
informacin entre ellos. El resultado de esta fase es el Documento de
Diseo Arquitectnico (DDA).
El proceso de diseo detallado suele requerir diversos pasos de
refinamiento en los que mltiples decisiones de diseo permiten
incorporar restricciones de implementacin derivadas del uso de
recursos limitados: la ejecucin de las funciones identificadas requiere
tiempo y espacio de memoria o bfferes as como recursos de CPU que
no son ilimitados.
El refinamiento culmina cuando la descomposicin modular ha
alcanzado el nivel suficiente como para poder comenzar la
implementacin del sistema en un lenguaje ejecutable con las
prestaciones adecuadas en mdulos de complejidad abordable por una
persona (o un pequeo grupo). En esta subfase podemos conocer los
recursos software requeridos para ello y hacer una estimacin (conocida
la tecnologa de software a utilizar).
Generacin de cdigo. El diseo se debe traducir en una forma legible
por la mquina. El paso de generacin de cdigo lleva a cabo esta tarea.
Si se lleva a cabo el diseo de una forma detallada, la generacin de
cdigo se realiza mecnicamente.
Es interesante mencionar que todas las fases anteriores son
conceptualmente independientes del lenguaje de programacin

seleccionado. Es en esta fase cundo se selecciona y utiliza un lenguaje

de programacin determinado.
Pruebas. Una vez que se ha generado el cdigo, comienzan las pruebas
del programa. El proceso de pruebas se centra en los procesos lgicos
internos del software, asegurando que todas las sentencias se han
comprobado, y en los procesos externos funcionales; es decir, realizar
las pruebas para la deteccin de errores y asegurar que la entrada
definida produce resultados reales de acuerdo con los resultados
requeridos.
Mantenimiento. El software indudablemente sufrir cambios despus
de ser entregado al cliente (una excepcin posible es el software
empotrado). Se producirn cambios porque se han encontrado errores,
porque el software debe adaptarse para acoplarse a los cambios de su
entorno externo (por ejemplo: se requiere un cambio debido a un
sistema operativo o dispositivo perifrico nuevo), o porque el cliente
requiere mejoras funcionales o de rendimiento. El soporte y
mantenimiento del software vuelve a aplicar cada una de las fases
precedentes a un programa ya existente y no a uno nuevo.
Una vez que el producto de software ha entrado en operacin regular
por el usuario no es de ningn modo un sistema inmutable. Todo
producto software complejo debe adaptarse a un entorno que va
cambiando (nuevas necesidades del cliente, evolucin de la plataforma
de ejecucin hardware o software, etc). Un producto software que no
evoluciona va hacindose cada vez menos til en ese entorno.

Se suele hablar de tres tipos diferentes de mantenimiento:

1) Mantenimiento correctivo. Pretende eliminar problemas surgidos
durante la fase de operacin del sistema y que no han sido detectados
anteriormente.
2) Mantenimiento perfectivo. Pretende mejorar la funcionalidad del
sistema ya sea en relacin con la eficiencia en ejecucin del mismo
(menor tiempo de respuesta, optimizacin del uso de la memoria, etc.),
facilitar su uso, etc.
3) Mantenimiento evolutivo. Pretende modificar (ampliar, eliminar o
sustituir) la funcionalidad del sistema para adaptarla a las nuevas
necesidades del usuario o con el objetivo de adaptarlo a nuevas
interfaces hardware o software.
Ventajas del modelo en cascada:
a) Fases conocidas por todos los desarrolladores y ligadas a los perfiles
tcnicos
clsicamente
establecidos.
Existe
gran
experiencia

documentada sobre el uso del modelo que coincide con la formacin

tpica del ingeniero de software.
b) Es el ms eficiente cuando el sistema es conocido y los requisitos
estables ya que se puede avanzar rpidamente hacia la fase de diseo
arquitectnico sin que exista el peligro de una contina interaccin entre
las primeras fases.
c) Permite una gestin del proceso de desarrollo basada en revisiones de
los documentos generados en cada fase facilitando la ejecucin de los
procedimientos de gestin.
Algunos problemas que nos podemos encontrar al aplicar este
modelo son:
1. Es muy raro que los proyectos reales sigan el flujo secuencial que
propone el modelo. A pesar de que el modelo lineal incluye
iteraciones, lo hace de manera indirecta. Como resultado, los
cambios confunden mientras el equipo de proyecto acta.
2. Con frecuencia es difcil para el cliente establecer todos los
requisitos de manera explcita. El modelo en cascada lo requiere y
se enfrentan dificultades al incorporar la incertidumbre natural
presente en el inicio de muchos proyectos.
3. El cliente debe tener paciencia. Una versin de funciones de los
programas estar disponible cuando el proyecto est muy
avanzado. Un grave error ser desastroso si no se detecta antes
de la revisin del programa.
Este modelo conduce a estados de bloqueo, lo que quiere decir que
algunos miembros del equipo deben esperar a otros para terminar
tareas dependientes. El estado de bloqueo tiende a ser ms comn al
principio y al final del proceso secuencial.
En la actualidad el trabajo del software est acelerado y sujeto a una
cadena infinita de cambios (caractersticas, funciones y contenido de la
informacin). Con frecuencia el modelo en cascada no es apropiado para
dicho trabajo. Sin embargo, puede servir como un modelo de proceso
til en situaciones donde los requerimientos estn fijos y donde el
trabajo que se realiza hasta su conclusin, de una manera lineal.

2.1.2 Incremental
En muchas situaciones los requisitos iniciales del software estn bien
definidos en forma razonable, pero el enfoque global del esfuerzo de
desarrollo excluye un proceso puramente lineal. Adems, quiz haya una
necesidad imperiosa de proporcionar de manera rpida un conjunto
limitado de funcionalidad para el usuario y despus refinarla y

expandirla en las entregas posteriores del software. En estos casos se

elige un modelo de proceso diseado para producir el software en forma
incremental.
El modelo incremental combina elementos del modelo en cascada
aplicado en forma iterativa. Como se muestra en la siguiente figura:

El modelo incremental aplica secuencias lineales de manera escalonada

conforme avanza el tiempo.
Cada secuencia lineal produce incrementos del software. Por ejemplo,
el software procesador de texto desarrollado con el paradigma
incremental en su primer incremento, podra realizar funciones bsicas
de administracin de archivos, edicin y produccin de documentos, en
el segundo incremento, ediciones ms sofisticadas, y tendra funciones
ms complejas de produccin de documentos; en el tercer incremento,
funciones de correccin ortogrfica y gramatical; y en el cuarto
capacidades avanzadas de configuracin pgina. Se debe tener en
cuenta que el flujo de proceso de cualquier incremento puede incorporar
el paradigma de construccin de prototipos.
A menudo, al utilizar un modelo incremental el primer incremento es un
producto esencial. Es decir, se incorporan los requisitos bsicos pero
muchas caractersticas suplementarias (algunas conocidas, otras no) no
se incorporan. El producto esencial queda en manos del cliente (o se
somete a una evaluacin detallada). Como resultado de la evaluacin se
desarroll un plan para el incremento siguiente. El plan afronta la

modificacin del producto esencial con el fin de satisfacer de mejor

manera las necesidades del cliente y la entrega de caractersticas y
funcionalidades adicionales. Este proceso se repite despus de la
entrega de cada incremento mientras no se haya elaborado el producto
completo.
El modelo de proceso incremental, al igual que la construccin de
prototipos y otros enfoque evolutivos es iterativo por naturaleza.
Pero a diferencia de la construccin de prototipos, se enfoca en la
entrega del producto operacional con cada incremento. Los primeros
incrementos son versiones incompletas del producto final, pero
proporcionan al usuario la funcionalidad que se necesita y una
plataforma para su evaluacin.
Este modelo es til sobre todo cuando el personal necesario para una
implementacin completa no est disponible. Los primeros incrementos
se pueden implementar con menos gente. Si el producto esencial es
bien recibido se agrega (si se requiere) ms personal para implementar
el incremento siguiente. Adems, los incrementos se pueden planear
para manejar los riesgos tcnicos. Por ejemplo, un sistema grande
podra requerir la disponibilidad de un hardware nuevo que est en
desarrollo y cuya fecha de entrega es incierta. Sera posible planear los
primeros incrementos de forma que se evite el uso de este hardware, lo
que permitira la entrega de funcionalidad parcial a los usuarios finales
sin retrasos desordenados.
Este proceso de desarrollo incremental tiene varias ventajas:
1. Los clientes no tienen que esperar hasta que el sistema completo
se entregue para sacar provecho de l. El primer incremento
satisface los requerimientos ms crticos de tal forma que pueden
utilizar el software inmediatamente.
2. Los clientes pueden utilizar los incrementos iniciales como
prototipos y obtener experiencia sobre los requerimientos de los
incrementos posteriores del sistema.
3. Existe un bajo riesgo de un fallo total del proyecto. Aunque se
pueden encontrar problemas en algunos incrementos, lo normal es
que el sistema se entregue de forma satisfactoria al cliente.
4. Puesto que los servicios de ms alta prioridad se entregan
primero, y los incrementos posteriores se integran en ellos, es
inevitable que los servicios ms importantes del sistema sean a los
que se les hagan ms pruebas. Esto significa que es menos
probable que los clientes encuentren fallos de funcionamiento del
software en las partes ms importantes del sistema.
Sin embargo, existen algunos problemas en el desarrollo incremental.
Los incrementos deben ser relativamente pequeos (no ms de 20.000
lneas de cdigo) y cada uno debe entregar alguna funcionalidad del

sistema. Puede ser difcil adaptar los requerimientos del cliente a

incrementos de tamao apropiado. Ms an, muchos de los sistemas
requieren un conjunto de recursos que se utilizan en diferentes partes
del sistema. Puesto que los requerimientos no se definen en detalle
hasta que un incremento se implementa, puede ser difcil identificar los
recursos comunes que requieren todos los incrementos.
2.1.3 Evolutivo
El desarrollo evolutivo se basa en la idea de desarrollar una
implementacin inicial, exponindola a los comentarios del usuario y
refinndola a travs de las diferentes versiones hasta que se desarrolla
un sistema adecuado.

Las actividades de especificacin, desarrollo y validacin se entrelazan

en vez de separarse, con una rpida retroalimentacin entre stas.
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.

En la produccin de sistemas, un enfoque evolutivo para el desarrollo de

software suele ser ms efectivo que el enfoque en cascada, ya que
satisface las necesidades inmediatas de los clientes. La ventaja de un
proceso del software que se basa en un enfoque evolutivo es que la
especificacin se puede desarrollar de forma creciente. Tan pronto como
los usuarios desarrollen un mejor entendimiento de su problema, ste se
puede reflejar en el sistema software.
Sin embargo, desde una perspectiva de ingeniera y de gestin, el
enfoque evolutivo tiene dos 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.
Para sistemas pequeos y de tamao medio (hasta 500.000 lneas de
cdigo), el enfoque evolutivo de desarrollo es el mejor. Los problemas
del desarrollo evolutivo se hacen particularmente agudos para sistemas
grandes y complejos con un periodo de vida largo, donde diferentes
equipos desarrollan distintas partes del sistema. Es difcil establecer una
arquitectura del sistema estable usando este enfoque, el cual hace difcil
integrar las contribuciones de los equipos.
Para sistemas grandes, se recomienda un proceso mixto que incorpore
las mejores caractersticas del modelo en cascada y del desarrollo
evolutivo. Esto puede implicar desarrollar un prototipo desechable
utilizando un enfoque evolutivo para resolver incertidumbres en la
especificacin del sistema. Puede entonces re-implementarse utilizando
un enfoque ms estructurado.
Las partes del sistema bien comprendidas se pueden especificar y
desarrollar utilizando un proceso basado en el modelo en cascada. Las
otras partes del sistema, como la interfaz de usuario, que son difciles de
especificar por adelantado, se deben desarrollar siempre utilizando un
enfoque de programacin exploratoria.
2.1.4 Espiral
Es un modelo de proceso evolutivo que conjuga la naturaleza iterativa
de la construccin de prototipos con aspectos controlados y sistemticos
del modelo de cascada. Proporciona el material para el desarrollo rpido
de versiones incrementales del software.
El modelo de desarrollo en espiral es un generador del modelo de
proceso guiado por el riesgo que se emplea para conducir sistemas

intensivos de ingeniera de software concurrente con mltiples usuarios.

Tiene dos caractersticas distintivas principales. Una de ellas es un
enfoque cclico para el crecimiento incremental del grado de definicin e
implementacin de un sistema, mientras su grado de riesgos disminuye.
La otra es un conjunto de puntos de fijacin para asegurar el
compromiso del usuario con soluciones de sistema que sean factibles y
mutuamente satisfactorias.
Cuando se aplica el modelo en espiral, el software se desarrolla en una
serie de entregas evolutivas. Durante las primeras iteraciones, la
entrega tal vez sea un documento del modelo o un prototipo. Durante
las ltimas iteraciones se producen versiones cada vez ms completas
del sistema desarrollado.

Un proceso en espiral se divide en un nmero de actividades del marco

de trabajo que define el equipo de ingeniera de software. Para
propsitos ilustrativos se aprovechan las actividades genricas del
marco de trabajo representa un segmento de la ruta en espiral.
Cuando comienza este proceso evolutivo el equipo de software realiza
actividades implicadas en un circuito alrededor de la espiral y que se

inicia en el centro. El riesgo es un factor considerado en cada revolucin.

Los puntos de fijacin una combinacin de productos de trabajo y
condiciones incluidas a lo largo de la ruta de la espiral- se consideran
para cada paso evolutivo.
El primer circuito alrededor de la espiral quiz genere el desarrollo de
una especificacin del producto; los pasos subsecuentes alrededor de la
espiral se pueden aprovechar para desarrollar un prototipo y despus,
en forma progresiva, versiones ms elaboradas de software. Cada paso
a travs de la regin de planeacin resulta en ajustes al plan del
proyecto. Los costos y el itinerario se ajustan con base en la
retroalimentacin derivada de la relacin con el cliente despus de la
entrega. Adems, el administrador del proyecto ajusta el nmero de
iteraciones planeado que se requiere para completar el software.
A diferencia de otros modelos de proceso que terminan cuando se
entrega el software, el modelo de espiral puede adaptarse y aplicarse a
lo largo de la vida del software de computadora. Por lo tanto, el primer
circuito alrededor de la espiral podra representar un proyecto de
desarrollo del concepto, el cual se inicia en el centro de la espiral y
contina con mltiples iteraciones hasta que el desarrollo del concepto
est completo. Si el concepto se desarrollar en un proyecto de
desarrollo de un producto nuevo. El nuevo producto evolucionar a
travs de un nmero de iteraciones alrededor de la espiral. Despus, un
circuito alrededor de la espiral se podra emplear para representar un
proyecto de mejoramiento del producto. En esencia. La espiral, cuando
se caracteriza de esta forma, permanece operativa hasta que el software
se retira. En ocasiones el proceso est inactivo, pero siempre que se
inicie un cambio el proceso comienza en el punto de entrada aprobado
(por ejemplo, mejoramiento del producto).
El modelo en espiral es un enfoque realista para el desarrollo de
software y de sistemas a gran escala. Como el software evoluciona
conforme avanza el proceso, el desarrollador y el cliente entienden y
reaccionan de mejor manera ante los riesgos en cada etapa evolutiva. El
modelo en espiral emplea la construccin de prototipos como un
mecanismo encaminado a reducir riesgos pero, en forma ms
importante, permite al desarrollador la aplicacin del enfoque de la
construccin de prototipos en cualquier etapa evolutiva del producto.
Mantiene un enfoque sistemtico de los pasos que sugiere el ciclo de
vida clsico, pero lo incorpora al marco de trabajo iterativo que refleja
de forma ms verdica el mundo real. El modelo en espiral exige una
consideracin directa de los riesgos tcnicos en todas las etapas del
proyecto y, si se aplica en forma apropiada, debe reducir los riesgos
antes de que se vuelvan problemticos.
El desarrollo evolutivo se basa en la idea de desarrollar una
implementacin inicial, exponindola a los comentarios del usuario y

refinndola a travs de las diferentes versiones hasta que se desarrolla

un sistema adecuado.

2.1.5 Prototipos
El cliente normalmente define los objetivos generales del software pero
no identifica detalladamente todos los requisitos. En otro caso el
diseador no puede estar seguro de entender al cliente, de cmo podr
ser el software que requiere, de la eficiencia que espera, etc. En estas
situaciones puede ser mejor el mtodo de construccin de un prototipo.
El desarrollador y el cliente encuentran y definen los objetivos globales
para el software, identifican los requisitos conocidos y las reas del
esquema en donde es obligatoria ms definicin. Entonces aparece un
diseo rpido. El diseo rpido se centra en una representacin de
esos aspectos del software que sern visibles para el usuario/cliente (por
ejemplo: enfoques de entrada y formatos de salida). El diseo rpido
lleva a la construccin de un prototipo. El prototipo lo evala el
cliente/usuario y se utiliza para refinar los requisitos del software a
desarrollar. La iteracin ocurre cuando el prototipo se pone a punto para
satisfacer las necesidades del cliente, permitiendo al mismo tiempo que
el desarrollador comprenda mejor lo que se necesita hacer.

El prototipo puede ser elaborado en papel o programado para que

implemente algunas funciones requeridas de manera rudimentaria, sin
todos los detalles y acabados del programa final.
Se empieza con la recoleccin de requisitos, se produce un diseo rpido
que se enfoca sobre los aspectos visibles al usuario (pantallas, informes,
etc.) Se construye el prototipo y se evala por parte del cliente y sus
observaciones se usan para refinar los requisitos del software a
desarrollar. Se produce un proceso iterativo en el que el prototipo se
afina para que satisfaga las necesidades del cliente y al mismo tiempo
facilita al desarrollador una mejor comprensin de lo que tiene que
hacer.
2.1.6 Desarrollo basado en componentes
Las tecnologas de objetos proporcionan el marco de trabajo tcnico
para un modelo de proceso basado en componentes para la ingeniera
del software. El paradigma orientado a objetos enfatiza la creacin de
clases que encapsulan tanto los datos como los algoritmos que se
utilizan para manejar los datos. Si se disean y se implementan
adecuadamente, las clases orientadas a objetos son reutilizables por las
diferentes aplicaciones y arquitecturas de sistemas basados en
computadora.

El modelo de desarrollo basado en componentes incorpora muchas de

las caractersticas del modelo en espiral. Es evolutivo por naturaleza, y
exige un enfoque iterativo para la creacin del software. Sin embargo, el
modelo de desarrollo basado en componentes configura aplicaciones
desde componentes preparados de software llamados clases.

Las clases creadas en los proyectos anteriores de ingeniera de software,

se almacenan en una biblioteca de clases o diccionario de datos
(repository) Una vez identificadas las clases candidatas, la biblioteca de
clases se examina para determinar si estas clases ya existen. En caso de
que as fuera, se extraen de la biblioteca. Se compone as la primera
iteracin de la aplicacin a construirse, mediante las clases extradas de
la biblioteca y las clases nuevas construidas para cumplir las
necesidades nicas de la aplicacin. El flujo del proceso vuelve a la
espiral y volver a introducir por ltimo la iteracin ensambladora de
componentes a travs de la actividad de ingeniera y se vuelven a
utilizar.
El modelo de desarrollo basado en componentes conduce a la
reutilizacin del software, y la reutilizacin proporciona beneficios a los
ingenieros de software. Segn estudios de reutilizacin, QSM Associates,
Inc. Informa que el ensamblaje de componentes lleva a una reduccin
del 70 por 100 de tiempo de ciclo de desarrollo, un 84 por 100 del coste
del proyecto.

2.2

Otras Metodologas

2.2.1 Ganar-ganar

En la recoleccin de los requisitos el cliente y el desarrollador entran en

un proceso de negociacin, donde el cliente puede ser preguntado para
sopesar la funcionalidad, rendimiento, y otros productos o caractersticas
del sistema frente al coste y al tiempo de comercializacin.

Las mejores negociaciones se esfuerzan en obtener ganar-ganar. Esto

es, el cliente gana obteniendo el producto o sistema que satisface la
mayor parte de sus necesidades y el desarrollador gana trabajando para
conseguir presupuestos y lograr una fecha de entrega realista.
El modelo en espiral WINWIN de Boehm define un conjunto de
actividades de negociacin al principio de cada paso alrededor de la
espiral. Ms que una simple actividad de comunicacin con el cliente, se
definen las siguientes actividades:
1. Identificacin del sistema o subsistemas clave de los
directivos.
2. Determinacin de las condiciones de ganar de los directivos.
3. Negociacin de las condiciones de ganar de los directivos
para reunirlas en un conjunto de condiciones ganar-ganar
para todos los afectados (incluyendo el equipo del proyecto de
software).
Conseguidos completamente estos pasos iniciales se logra un resultado
ganar-ganar, que ser el criterio clave para continuar con la definicin
del sistema y del software.
En esencia, los puntos de fijacin representan tres visiones diferentes
del progreso mientras que el proyecto recorre la espiral. El primer punto
de fijacin, llamado objetivos del ciclo de vida (OCV), define un conjunto
de objetivos para cada actividad principal de ingeniera del software.
Como ejemplo, de una parte de OCV, un conjunto de objetivos asociados
a la definicin de los requisitos del producto/sistema del nivel ms alto.

El segundo punto de fijacin, llamado arquitectura del ciclo de vida

(ACV), establece los objetivos que se deben conocer mientras que se
define la arquitectura del software y el sistema. Como ejemplo, de una
parte de la ACV, el equipo del proyecto de software debe demostrar que
ha evaluado la funcionalidad de los componentes del software
reutilizables y que ha considerado su impacto en las decisiones de
arquitectura. La capacidad operativa inicial (COI) es el tercer punto de
fijacin y representa un conjunto de objetivos asociados a la preparacin
del software para la instalacin/distribucin, preparacin del lugar
previamente a la instalacin, y la asistencia precisada de todas las
partes que utilizar o mantendr el software.

2.2.2 Proceso Unificado (UP)

El Proceso de desarrollo unificado fue creado reuniendo los mejores

rasgos y caractersticas de modelos de procesos de software. Reconoce
la importancia de la comunicacin con el cliente enfatiza el importante
papel de la arquitectura de software, y ayuda al arquitecto a enfocarse
en las metas correctas. Sugiere un flujo de proceso iterativo e
incremental y que proporciona el sentido evolutivo esencial en el
desarrollo del software moderno.
Es un marco de trabajo para la ingeniera de software orientado a
objetos, mediante la utilizacin de UML (lenguaje de modelado
unificado).
Lanzamiento

Transicin

Despliegue

Construcci
n

Incremento del software

Produccin

Comunicaci
n

Inicio

Modelado

Planeacin

Elaboracin

Se compone de las siguientes fases:

a. Inicio: Abarca la comunicacin con el cliente y las actividades de
planeacin. Al colaborar con los clientes y usuarios finales se
identifican los requisitos de negocios para el software, se propone
una arquitectura aproximada para el sistema y se desarrolla un
plan para la naturaleza iterativa e incremental del sistema
subsiguiente. El propsito de esta fase es establecer una visin
general para el proyecto, identificar los requisitos de negocios,
formar un caso de negocios para el software y definir los riesgos
del proyecto y del negocio que pudieran representar un obstculo
para el xito. En esta etapa se obtiene el modelo de caso de uso
que es una coleccin de casos de uso que describen la forma en
que actores externos (usuarios humanos y no humanos del
software) interactan con el sistema y obtienen valor a partir de
ste. En esencia, el modelo de casos de uso es una coleccin de
escenarios de uso con plantillas estandarizadas que implican
caractersticas y funciones del software mediante la descripcin de
una serie de condiciones previa, un flujo de eventos o un
escenario, y un conjunto de condiciones exteriores para la
interaccin representada. En un inicio, los casos de uso describen
requisitos al nivel del dominio de negocios (por ejemplo, el grado
de abstraccin es alto). Sin embargo, el modelo de casos de uso se
refina y elabora conforme cada fase del Proceso Unificado se
ejecuta y sirve como una entrada importante para la creacin de
productos de trabajo subsecuentes. Durante la fase de inicio slo
se completa entre el 10 y el 20 por ciento de los casos de uso.
Despus de la elaboracin, se ha creado entre un 80 y 90 por
ciento del modelo.
b. Elaboracin: Abarca la comunicacin con el cliente y las
actividades de modelado del modelo genrico. La elaboracin
refina y expande los casos de uso preliminares que se
desarrollaron como parte de la fase de inicio; adems, expande la
representacin arquitectnica para incluir cinco visiones diferentes
del software: el modelo de caso de uso, el modelo de anlisis, el
modelo de diseo, el modelo de implementacin y el modelo de
despliegue. En algunos casos, la elaboracin crea una lnea de
base arquitectnica ejecutable que representa un sistema
ejecutable en su primer corte. La lnea de base arquitectnica
demuestra la viabilidad de la arquitectura, pero no proporciona
todas las caractersticas y funciones necesarias para utilizar el
sistema. Esta fase produce un conjunto de productos de trabajo
que elabora requisitos (incluso requisitos no funcionales), as como

una descripcin arquitectnica y un diseo preliminar. Cuando el

ingeniero de software inicia con el anlisis orientado a objetos, el
objetivo es definir un conjunto de clases de anlisis que describan
en forma adecuada el comportamiento del sistema. El modelo de
anlisis del Proceso Unificado es un producto de trabajo que se
desarrolla como consecuencia de esta actividad. Los paquetes de
clases y anlisis (colecciones de clases) definidos como una parte
del modelo de anlisis se refinan despus en un modelo de diseo,
el cual identifica clases de diseo, subsistemas y las interfaces
entre los subsistemas. Adems en esta fase se revisan los riesgos
y el plan del proyecto para asegurar que cada uno de ellos
conserve su validez.
c. Construccin: Est fase es idntica a la actividad de construccin
definida para el proceso genrico del software. Si se utiliza el
modelo arquitectnico como entrada, la fase de construccin
desarrolla o adquiere los componentes del software que harn que
cada caso de uso sea operativo para los usuarios finales. Lograr
esto requiere que los modelos de anlisis y diseo iniciados
durante la fase de elaboracin se completen para reflejar la
versin final del incremento del software. Todas las caractersticas
y funciones necesarias y requeridas del incremento del software
(por ejemplo la entrega) se implementan en cdigo fuente.
Conforme los componentes estn en proceso de implementacin,
se disean y ejecutan pruebas de unidad para cada uno de ellos.
Adems, se realizan las actividades de integracin (ensamblaje de
componentes y pruebas de integracin). Los casos de uso se
utilizan para derivar un conjunto de pruebas de aceptacin que se
ejecutan antes del inicio de la siguiente fase. La fase de
construccin produce un modelo de implementacin que traduce
las clases de diseo en componentes de software que se
constituirn para ejecutar el sistema, y un modelo de despliegue
convierte los componentes en el ambiente fsico de computacin.
Por ltimo, un modelo de prueba describe las pruebas empleadas
para asegurar que los casos de uso se reflejen de manera
apropiada en el software que se ha construido.
d. Transicin: abarca las ltimas etapas de la actividad genrica de
construccin y la primera parte de la actividad genrica de
despliegue. El software se entrega a los usuarios finales para
realizar pruebas beta, y la retroalimentacin del usuario reporta
tanto defectos como cambios necesarios. Adems, el equipo de
software crea la informacin de soporte necesaria (por ejemplo,
manuales del usuario, guas de resolucin de problemas,
procedimientos de instalacin) para el lanzamiento. Al final de la
fase de transicin, el incremento de software se convierte en un
lanzamiento de software utilizable. La fase transicin entrega el
incremento del software y evala los productos de trabajo

elaborados durante la etapa en que los usuarios finales trabajan

con el software. En esta etapa se produce la retroalimentacin
proveniente de las pruebas beta y los requerimientos cualitativos
de cambio.
e. Produccin: Esta fase coincide con la actividad de despliegue del
proceso genrico. Durante esta fase se monitorea el uso
subsiguiente del software, se proporciona soporte para el
ambiente operativo (infraestructura), y se reciben y evalan los
informes de defectos y los requerimientos de los cambios.
En este modelo es posible que mientras se estn ejecutando las fases de
construccin, transicin y produccin ya se hayan iniciado trabajos para
el siguiente incremento del software.
La perspectiva prctica de este proceso describe buenas prcticas de la
ingeniera del software que son aconsejables en el desarrollo de
sistemas. Se recomiendan seis buenas prcticas fundamentales:
1. Desarrolle el software de forma iterativa. Planifique incrementos
del sistema basado en las prioridades del usuario y desarrollo y
entregue las caractersticas del sistema de ms alta prioridad al
inicio del proceso de desarrollo.
2. Gestione los requerimientos. Documente explcitamente los
requerimientos del cliente y mantngase al tanto de los cambios
de estos requerimientos. Analice el impacto de los cambios en el
sistema antes de aceptarlos.
3. Utilice arquitecturas basadas en componentes. Estructure la
arquitectura del sistema en componentes.
4. Modele el software visualmente. Utilice modelos grficos UML para
presentar vistas estticas y dinmicas del software.
5. Verifique la calidad del software. Asegure que el software cumple
los estndares de calidad organizacionales.
6. Controle los cambios del software. Gestione los cambios del
software usando un sistema de gestin de cambios y
procedimientos y herramientas de gestin de configuraciones.

2.2.3

Ingeniera Web

El proceso de ingeniera Web comienza con una formulacin del

problema que pasa a resolverse con las WebApps. Se planifica el
proyecto y se analizan los requisitos de la WebApp, entonces se lleva a
cabo el diseo de interfaces arquitectnico y del navegador. El sistema
se implementa utilizando lenguajes y herramientas especializados
asociados con la Web, y entonces comienzan las pruebas. Dado que las
WebApps estn en constante evolucin, deben de establecerse los
mecanismos para el control de configuraciones, garanta de calidad y
soporte continuo.

La Ingeniera Web (IWeb) est relacionada con el establecimiento y

utilizacin de principios cientficos, de ingeniera y de gestin, y con
enfoques sistemticos y disciplinados del xito del desarrollo, empleo y
mantenimiento de sistemas y aplicaciones basados en Web de alta
calidad.
Los sistemas basados en Web implican una mezcla de publicacin
impresa y desarrollo de software, de marketing e informtica, de
comunicaciones internas y relaciones externas, y de arte y tecnologa.
Atributos de las aplicaciones WEB:
Intensivas de Red. Por su propia naturaleza, una WebApp es intensiva
de red. Reside en una red y debe dar servicio a las necesidades de una
comunidad diversa de clientes. Una WebApp puede residir en Internet
(haciendo posible as una comunicacin abierta para todo el mundo). De
forma alternativa, una aplicacin se puede ubicar en una Intranet
(implementando la comunicacin a travs de redes de una organizacin)
o una Extranet (comunicacin entre redes).
Controlada por el contenido. En muchos casos, la funcin primaria de
una WebApp es utilizar hipermedia para presentar al usuario el
contenido de textos, grficos, sonido y vdeo.
Evolucin continua. A diferencia del software de aplicaciones
convencional, que evoluciona con una serie de versiones planificadas y
cronolgicamente espaciadas, las aplicaciones Web estn en constante
evolucin. No es inusual que algunas WebApps (especficamente, su
contenido) se actualicen cada hora.
Inmediatez. Las aplicaciones basadas en Web tienen una inmediatez
que no se encuentra en otros tipos de software. Es decir, el tiempo que
se tarda en comercializar un sitio Web completo puede ser cuestin de
das o semanas. Los desarrolladores debern utilizar los mtodos de
planificacin, anlisis, diseo, implementacin y comprobacin que se
hayan adaptado a planificaciones apretadas en tiempo para el desarrollo
de WebApps.
Seguridad. Dado que las WebApps estn disponibles a travs del
acceso por red, es difcil, si no imposible, limitar la poblacin de usuarios
finales que pueden acceder a la aplicacin. Con objeto de proteger el
contenido confidencial y de proporcionar formas seguras de transmisin
de datos, debern implementarse fuertes medidas de seguridad en toda
la infraestructura que apoya una WebApp y dentro de la misma
aplicacin.
Esttica. Una parte innegable del atractivo de una WebApp es su
apariencia e interaccin. Cuando se ha diseado una aplicacin con el
fin de comercializarse o vender productos o ideas, la esttica puede
tener mucho que ver con el xito del diseo tcnico.

Categoras de las pginas Web

1. Informativa: se proporciona un contenido solo de lectura con
navegacin y enlaces simples.
2. Descarga: un usuario descarga la informacin desde el servidor
apropiado.
3. Personalizable: el usuario personaliza el contenido a sus necesidades
especficas.
4. Interaccin: la comunicacin entre una comunidad de usuarios ocurre
mediante un espacio chat (charla), tablones de anuncios o
mensajera instantnea.
5. Entrada del usuario: la entrada basada en formularios es el
mecanismo primario de la necesidad de comunicacin.
6. Orientada a transacciones: el usuario hace una solicitud (por
ejemplo, la realizacin un pedido) que es cumplimentado por la
WebApp.
7. Orientado a servicios: la aplicacin proporciona un servicio al
usuario, por ejemplo, ayuda al usuario a determinar un pago de
hipoteca.
8. Portal: la aplicacin canaliza al usuario llevndolo a otros contenidos
o servicios Web fuera del dominio de la aplicacin del portal.
9. Acceso a bases de datos: el usuario consulta en una base de datos
grande y extrae informacin.
10. Almacenes de datos: el usuario hace una consulta en una
coleccin de bases de datos grande y extrae informacin.

2.2.4

Metodologas giles

Hasta hace poco el proceso de desarrollo de software tena un marcado

nfasis en el control del proceso mediante una rigurosa definicin de
roles, actividades y artefactos, incluyendo modelado y documentacin
detallada. Este esquema "tradicional" para abordar el desarrollo de
software ha demostrado ser efectivo y necesario en proyectos de gran
tamao (respecto a tiempo y recursos), donde por lo general se exige un
alto grado de ceremonia en el proceso. Sin embargo, este enfoque no
resulta ser el ms adecuado para muchos de los proyectos actuales
donde el entorno del sistema es muy cambiante, y en donde se exige
reducir drsticamente los tiempos de desarrollo pero manteniendo una
alta calidad. Ante las dificultades para utilizar metodologas tradicionales
con estas restricciones de tiempo y flexibilidad, muchos equipos de
desarrollo se resignan a prescindir del buen hacer de la ingeniera del
software, asumiendo el riesgo que ello conlleva.
En este escenario, las metodologas giles emergen como una posible
respuesta para llenar ese vaco metodolgico. Por estar especialmente
orientadas para proyectos pequeos, las metodologas giles
constituyen una solucin a medida para ese entorno, aportando una

elevada simplificacin que a pesar de ello no renuncia a las prcticas

esenciales para asegurar la calidad del producto.
Las caractersticas de los proyectos para los cuales las metodologas
giles han sido especialmente pensadas se ajustan a un amplio rango de
proyectos industriales de desarrollo de software; aquellos en los cuales
los equipos de desarrollo son pequeos, con plazos reducidos, requisitos
voltiles, y/o basados en nuevas tecnologas.
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el
trmino gil aplicado al desarrollo de software. En esta reunin
participan un grupo de 17 expertos de la industria del software,
incluyendo algunos de los creadores o impulsores de metodologas de
software. Su objetivo fue esbozar los valores y principios que deberan
permitir a los equipos desarrollar software rpidamente y respondiendo
a los cambios que puedan surgir a lo largo del proyecto. Se pretenda
ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rgidos y dirigidos por la
documentacin que se genera en cada una de las actividades
desarrolladas.
Tras esta reunin se cre The Agile Alliance, una organizacin, sin nimo
de lucro, dedicada a promover los conceptos relacionados con el
desarrollo gil de software y ayudar a las organizaciones para que
adopten dichos conceptos. El punto de partida fue el Manifiesto gil, un
documento que resume la filosofa gil.
El Manifiesto gil.
Segn el Manifiesto se valora:

Al individuo y las interacciones del equipo de desarrollo sobre el

proceso y las herramientas. La gente es el principal factor de xito
de un proyecto software. Es ms importante construir un buen
equipo que construir el entorno. Muchas veces se comete el error
de construir primero el entorno y esperar que el equipo se adapte
automticamente. Es mejor crear el equipo y que ste configure su
propio entorno de desarrollo en base a sus necesidades.
Desarrollar software que funciona ms que conseguir una buena
documentacin. La regla a seguir es no producir documentos a
menos que sean necesarios de forma inmediata para tomar un
decisin importante- Estos documentos deben ser cortos y
centrarse en lo fundamental.
La colaboracin con el cliente ms que la negociacin de un
contrato. Se propone que exista una interaccin constante entre el
cliente y el equipo de desarrollo. Esta colaboracin entre ambos
ser la que marque la marcha del proyecto y asegure su xito.
Responder a los cambios ms que seguir estrictamente un plan. La
habilidad de responder a los cambios que puedan surgir a los largo

del proyecto (cambios en los requisitos, en la tecnologa, en el

equipo, etc.) determina tambin el xito o fracaso del mismo. Por
lo tanto, la planificacin no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son
caractersticas que diferencian un proceso gil de uno tradicional. Los
dos primeros principios son generales y resumen gran parte del espritu
gil. El resto tienen que ver con el proceso a seguir y con el equipo de
desarrollo, en cuanto metas a seguir y organizacin del mismo. Los
principios son:
I. La prioridad es satisfacer al cliente mediante tempranas y
continuas entregas de software que le aporte un valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que
el cliente tenga una ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de
semanas a un par de meses, con el menor intervalo de tiempo
posible entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a
lo largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el
entorno y el apoyo que necesitan y confiar en ellos para conseguir
finalizar el trabajo.
VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para
comunicar informacin dentro de un equipo de desarrollo.
VII. El software que funciona es la medida principal de progreso.
VIII. Los procesos giles promueven un desarrollo sostenible. Los
promotores, desarrolladores y usuarios deberan ser capaces de
mantener una paz constante.
IX. La atencin continua a la calidad tcnica y al buen diseo mejora la
agilidad.
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseos surgen de los
equipos organizados por s mismos.
XII. En intervalos regulares, el equipo reflexiona respecto a cmo
llegar a ser ms efectivo, y segn esto ajusta su comportamiento.

Metodologas giles
Basadas en heursticas provenientes de
prcticas de produccin de cdigo.
Especialmente preparados para cambios

Metodologas tradicionales
Basadas en normas provenientes de
estndares seguidos por el entorno de
desarrollo
Cierta resistencia a los cambios.

durante el proyecto.
Impuestas internamente (por el equipo)
Proceso menos controlado, con pocos
principios
No existe contrato tradicional o al
menos es bastante flexible
El cliente es parte del equipo de
desarrollo
Grupos pequeos ( menos de 10
integrantes) y trabajando en el mismo
sitio
Pocos artefactos
Pocos roles
Menos nfasis en la arquitectura de
software

Impuestas externamente
Proceso mucho ms controlados, con
numerosas polticas/normas
Existe un contrato prefijado
El cliente interacta con el equipo de
desarrollo mediante reuniones
Grupos grandes y posiblemente
distribuidos
Ms artefactos
Ms roles
La arquitectura del software es
esencial y se expresa mediante
modelos.

PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP)

XP es una metodologa gil centrada en potenciar las relaciones
interpersonales como clave para el xito en desarrollo de software,
promoviendo el trabajo en equipo, preocupndose por el aprendizaje de
los desarrolladores, y propiciando un buen clima de trabajo. XP se basa
en realimentacin continua entre el cliente y el equipo de desarrollo,
comunicacin fluida entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. XP se
define como especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. Los
principios y prcticas son de sentido comn pero llevadas al extremo, de
ah proviene su nombre. Kent Beck, el padre de XP, describe la filosofa
de XP en sin cubrir los detalles tcnicos y de implantacin de las
prcticas. Las caractersticas esenciales de XP: historias de usuario,
roles, proceso y prcticas.
a) Las Historias de Usuario
Son la tcnica utilizada para especificar los requisitos del software. Se
trata de tarjetas de papel en las cuales el cliente describe brevemente
las caractersticas que el sistema debe poseer, sean requisitos
funcionales o no funcionales. El tratamiento de las historias de usuario
es muy dinmico y flexible. Cada historia de usuario es lo
suficientemente comprensible y delimitada para que los programadores
puedan implementarla en unas semanas.
Debe tener los siguientes contenidos segn Beck: fecha, tipo de
actividad (nueva, correccin, mejora), prueba funcional, nmero de
historia, prioridad tcnica y del cliente, referencia a otra historia previa,
riesgo, estimacin tcnica, descripcin, notas y una lista de seguimiento

con la fecha, estado cosas por terminar y comentarios. A efectos de

planificacin, las historias pueden ser de una a tres semanas de tiempo
de programacin (para no superar el tamao de una iteracin). Las
historias de usuario son descompuestas en tareas de programacin (task
card) y asignadas a los programadores para ser implementadas durante
una iteracin.
b) Roles XP
Los roles de acuerdo con la propuesta original de Beck son:

Programador. El programador escribe las pruebas unitarias y

produce el cdigo del sistema.
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.
Encargado de pruebas (Tester). 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). Proporciona realimentacin al
equipo. Verifica el grado de acierto entre las estimaciones
realizadas y el tiempo real dedicado, para mejorar futuras
estimaciones. Realiza el seguimiento del progreso de cada
iteracin.
Entrenador (Coach). Es responsable del proceso global. Debe
proveer guas al 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, en el que
puedan surgir problemas.
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.

c) Proceso XP
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:
1. El cliente define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su implementacin.
3. El cliente selecciona qu construir, de acuerdo con sus prioridades y
las restricciones de tiempo.
4. El programador construye ese valor de negocio.
5. 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.
d) 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. Esto se consigue
gracias a las tecnologas disponibles para ayudar en el desarrollo de
software y a la aplicacin disciplinada de las siguientes prcticas.

El juego de la planificacin. Hay una comunicacin frecuente 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.
Entregas pequeas. Producir rpidamente versiones del sistema
que sean operativas, aunque no cuenten con toda la funcionalidad
del sistema. Esta versin ya constituye un resultado de valor para
el negocio. Una entrega no debera tardar ms 3 meses.
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 (conjunto de nombres que
acten como vocabulario para hablar sobre el dominio del
problema, ayudando 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.
Pruebas. La produccin de cdigo est dirigida por las pruebas
unitarias. stas son establecidas por el cliente antes de escribirse
el cdigo y son ejecutadas constantemente ante cada modificacin
del sistema.
Refactorizacin (Refactoring). 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. Se mejora la

estructura interna del cdigo sin alterar su comportamiento
externo [8].
Programacin en parejas. Toda la produccin de cdigo debe
realizarse con trabajo en parejas de programadores. Esto conlleva
ventajas implcitas (menor tasa de errores, mejor diseo, mayor
satisfaccin de los programadores, ).
Propiedad colectiva del cdigo. Cualquier programador puede
cambiar cualquier parte del cdigo en cualquier momento.
Integracin continua. 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.
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.
Cliente in-situ. El cliente tiene que estar presente y disponible todo
el tiempo para el equipo. ste es uno de los principales factores de
xito del proyecto XP. El cliente 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.
Estndares de programacin. XP enfatiza que la comunicacin de
los programadores es a travs del cdigo, con lo cual es
indispensable que se sigan ciertos estndares de programacin
para mantener el cdigo legible.

El mayor beneficio de las prcticas se consigue con su aplicacin

conjunta y equilibrada puesto que se apoyan unas en otras. Esto se
ilustra en la figura anterior, donde una lnea entre dos prcticas significa

que las dos prcticas se refuerzan entre s. 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.

2.2.5 Metodologas emergentes

Aunque los creadores e impulsores de las metodologas giles ms
populares han suscrito el manifiesto gil y coinciden con los principios
enunciados anteriormente, cada metodologa tiene caractersticas
propias y hace hincapi en algunos aspectos ms especficos. A
continuacin se resumen otras metodologas giles. La mayora de ellas
ya estaban siendo utilizadas con xito en proyectos reales pero les
faltaba una mayor difusin y reconocimiento.

SCRUM5. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike

Beedle. Define un marco para la gestin de proyectos, que se ha
utilizado con xito durante los ltimos 10 aos. Est
especialmente indicada para proyectos con un rpido cambio de
requisitos. Sus principales caractersticas se pueden resumir en
dos. El desarrollo de software se realiza mediante iteraciones,
denominadas sprints, con una duracin de 30 das. El resultado de
cada sprint es un incremento ejecutable que se muestra al cliente.
La segunda caracterstica importante son las reuniones a lo largo
proyecto, entre ellas destaca la reunin diaria de 15 minutos del
equipo de desarrollo para coordinacin e integracin.
Crystal Methodologies. Se trata de un conjunto de metodologas
para el desarrollo de software caracterizadas por estar centradas
en las personas que componen el equipo y la reduccin al mximo
del nmero de artefactos producidos. Han sido desarrolladas por
Alistair Cockburn. El desarrollo de software se considera un juego
cooperativo de invencin y comunicacin, limitado por los recursos
a utilizar. El equipo de desarrollo es un factor clave, por lo que se
deben invertir esfuerzos en mejorar sus habilidades y destrezas,
as como tener polticas de trabajo en equipo definidas. Estas
polticas dependern del tamao del equipo, establecindose una
clasificacin por colores, por ejemplo Crystal Clear (3 a 8
miembros) y Crystal Orange (25 a 50 miembros).
Dynamic Systems Development Method(DSDM)]. Define el marco
para desarrollar un proceso de produccin de software. Nace en
1994 con el objetivo de crear una metodologa RAD unificada. Sus
principales caractersticas son: es un proceso iterativo e
incremental y el equipo de desarrollo y el usuario trabajan juntos.
Propone cinco fases: estudio viabilidad, estudio del negocio,

modelado funcional, diseo y construccin, y finalmente

implementacin. Las tres ltimas son iterativas, adems de existir
realimentacin a todas las fases.
Adaptive Software Development (ASD). Su impulsor es Jim
Highsmith. Sus principales caractersticas son: iterativo, orientado
a los componentes software ms que a las tareas y tolerante a los
cambios. El ciclo de vida que propone tiene tres fases esenciales:
especulacin, colaboracin y aprendizaje. En la primera de ellas se
inicia el proyecto y se planifican las caractersticas del software; en
la segunda desarrollan las caractersticas y finalmente en la
tercera se revisa su calidad, y se entrega al cliente. La revisin de
los componentes sirve para aprender de los errores y volver a
iniciar el ciclo de desarrollo.
Feature -Driven Development (FDD). Define un proceso iterativo
que consta de 5 pasos. Las iteraciones son cortas (hasta 2
semanas). Se centra en las fases de diseo e implementacin del
sistema partiendo de una lista de caractersticas que debe reunir
el software. Sus impulsores son Jeff De Luca y Peter Coad.
Lean Development10 (LD). Definida por Bob Charette.s a partir de
su experiencia en proyectos con la industria japonesa del
automvil en los aos 80 y utilizada en numerosos proyectos de
telecomunicaciones en Europa. En LD, los cambios se consideran
riesgos, pero si se manejan adecuadamente se pueden convertir
en oportunidades que mejoren la productividad del cliente. Su
principal caracterstica es introducir un mecanismo para
implementar dichos cambios.

2.3 Reingeniera
Cuando un software es obsoleto se necesitar reconstruirlo. Se crear un
producto con una funcionalidad nueva, un mejor rendimiento y
fiabilidad, y un mantenimiento mejorado. Eso es lo que llamamos
reingeniera.
La reingeniera es realizada por ingenieros del software.
El proceso de reingeniera del software acompaa el anlisis de
inventarios, la estructuracin de documentos, la ingeniera inversa, la
reestructuracin de datos y la ingeniera avanzada. El objetivo de estas
actividades es crear versiones nuevas de los programas existentes que
exhiben una mantenibilidad de mayor calidad.
Son varios los productos que se elaboran (por ejemplo, modelos anlisis,
modelos de diseo, procedimientos de pruebas).
El resultado final es el software de reingeniera que lo soporta.

En la actualidad, existen compaas importantes que poseen decenas de

miles de programas de computadora que prestan apoyo a las viejas
reglas del negocio. Cuando los administradores trabajan para modificar
estas reglas y lograr as una mayor efectividad y competitividad, el
software seguir el mismo ritmo. En algunos casos, esto implica la
creacin de sistemas nuevos e importantes basados en computadora.
Pero en muchos otros, esto implica la modificacin y/o reconstruccin de
las aplicaciones existentes.