INTRODUCCIN A LAS METODOLOGIAS DE DESARROLLO DE SOFTWARE

Una metodologa de desarrollo de software no es ms que una serie de pasos que se realizan de
forma rigurosa tal que su resultado a partir de unos requisitos nuevos o modificados sea un
software nuevo o modificado. Se puede ver como una caja negra, como muestra la siguiente
imagen:

Una metodologa de desarrollo de software se refiere al entorno que se usa para estructurar,
planificar y controlar el proceso de desarrollo de un sistema de informacin. Una gran variedad
de metodologas se han desarrollado a lo largo de los aos, cada una de ellas con sus fortalezas
y debilidades. Una determinada metodologa no es necesariamente aplicable a todo tipo de
proyectos, ms bien cada tipo de proyecto tiene una metodologa a la que se adapta mejor.
Una Metodologa de desarrollo de software consiste en:

Una filosofa de desarrollo de sofware con una base de procesos de desarrollo de

software
Mltiples herramientas, modelos y mtodos, para asistir en el proceso de desarrollo de
software.
Suele estar documentada y alguna clase de documentacin formal.
Suele estar promovida por algn tipo de organizacin ya sea esta pblica o privada que
es la que se encarga de promover esta metodologa.

HISTORIA DE LAS METODOLOGIAS DE DESARROLLO DE SOFTWARE

El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la dcada de 1960 para
desarrollar a gran escala funcional de sistemas de negocio en una poca de grandes
conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas de
informacin en una muy deliberada, estructurada y metdica, reiterando cada una de las etapas
del ciclo de vida. Los sistemas de informacin en torno a las actividades resueltas pesadas para
el procesamiento de datos y rutinas de clculo.
Metodologas de Desarrollo de Software tiene como objetivo presentar un conjunto de tcnicas
tradicionales y modernas de modelado de sistemas que permitan desarrollar software de calidad,
incluyendo heursticas de construccin y criterios de comparacin de modelos de sistemas.
Para tal fin se describen, fundamentalmente, herramientas de Anlisis y Diseo Orientado a
Objetos (UML), sus diagramas, especificacin, y criterios de aplicacin de las mismas. Como
complemento se describirn las metodologas de desarrollo de software que utilizan dichas
herramientas, ciclos de vida asociados y discusin sobre el proceso de desarrollo de software
ms adecuado para las diferentes aplicaciones ejemplos que se presentarn. Principalmente, se
presentar el Proceso Unificado el cual utiliza un ciclo de vida iterativo e incremental.
Kendall y Kendall
1.
2.
3.
4.
5.
6.

Identificacin del problema, oportunidades y objetivos.

Determinacin de los requerimientos de informacin.
Anlisis de las necesidades del sistema.
Diseo del sistema recomendado.
Desarrollo y documentacin del software.
Pruebas y mantenimiento del sistema. VII. Implantacin y evaluacin del sistema.

James Senn
1.
2.
3.

Ciclo de vida y desarrollo del sistema.

Desarrollo por anlisis estructurado
Prototipo del sistema.

Llorens Fabregas
1.
2.
3.
4.
5.

Requerimientos.
Anlisis/Diseo.
Construccin.
Pruebas.
Produccin y mantenimiento.

Jonas Montilva
1.
2.
3.
4.
5.

Definir el proyecto.
Anlisis del contexto.
Definicin de los requerimientos.
Diseo preliminar.
Diseo detallado.

Roger Pressman

1.
2.
3.
4.
5.

Anlisis de los requerimientos del Software.

II. Diseo.
III. Generacin de cdigo.
IV. Pruebas.
V. Mantenimiento;

METODOLOGIAS DE DESARROLLO DE SOFTWARE

1970

Programacin estructurada sol desde 1969

Programacin estructurada Jackson desde 1975

1980

Structured Systems Analysis and Design Methodology (SSADM) desde 1980

Structured Analysis and Design Technique (SADT) desde 1980
Ingeniera de la informacin (IE/IEM) desde 1981

1990

Rapid application development (RAD) desde 1991.

Programacin orientada a objetos (OOP) a lo largo de la dcada de los 90's
Virtual finite state machine (VFSM) desde 1990s
Dynamic Systems Development Method desarrollado en UK desde 1995.
Scrum (desarrollo), en la ltima parte de los 90's
Rational Unified Process (RUP) desde 1999.
Extreme Programming(XP) desde 1999

Nuevo milenio

Enterprise Unified Process (EUP) extensiones RUP desde 2002

Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thrisson
Agile Unified Process (AUP) desde 2005 por Scott Ambler

ENFOQUE DE DESARROLLO DE SOFTWARE

Cada metodologa de desarrollo tiene ms o menos su propio enfoque de en lo que debera de

consistir un proyecto de desarrollo de software.
Pero todas ellas se basan en una serie de enfoques generalistas como son:

Waterfall Model Lineal

Prototyping Iterativo
Incremental combinacin de iterativo y lineal
Spiral Combinacin de iterativo y lineal
Rapid Application Development (RAD) -- iterativo

MODELO CASCADA
Tambin conocido como modelo
clsico, modelo tradicional o modelo
lineal secuencial. l mtodo de la
cascada es considerado como el
enfoque clsico para el ciclo de vida
del desarrollo de sistemas, se puede
decir que es un mtodo puro que
implica un desarrollo rgido. Est es
una secuencia de actividades (o
etapas) que consisten en el anlisis de
requerimientos,
l
diseo,
la
implementacin, la integracin y las
pruebas.

El anlisis de requerimientos
consiste en reunir las necesidades del producto y casi siempre su salida es texto.
El diseo describe la estructura interna del producto y suele representarse con
diagramas y texto.
La implementacin significa programacin. Producto de esta etapa es el cdigo en
cualquier nivel, incluido el producido por sistemas de generacin automtica.
La integracin es el proceso de integracin es el proceso de ensamblar las partes para
completar el producto.

Es caracterizado por ordenar de manera rigurosa las etapas del ciclo de vida de software, dado
que el comienzo de cada etapa debe esperar a la finalizacin de la inmediata anterior. Cuando la
revisin determina que el proyecto no est listo para pasar a la siguiente etapa, permanece en la
etapa actual hasta que est preparado. Y debido a que el proceso est planeado es ms fcil
determinar costos y los plazos. Est modelo puede ser visto como un modelo con forma de
cascada de agua con varios saltos, en la que cada salto representa cada una de las fases del ciclo
de vida.

La metodologa en cascada es esencialmente:

El inicio y el alcance del proyecto

La planificacin del proyecto (calendario, recursos necesarios, costo)

Definicin de las necesidades del negocio y el anlisis en detalle dela solucin
La creacin de la solucin
Prueba que la solucin funciona. La entrega de la solucin a su pblico objetivo
Cierre del proyecto.

Ventajas

Permite la departamentalizacin y control de gestin.

El horario se establece con los plazos normalmente adecuados para cada etapa de
desarrollo.
Este proceso conduce a entregar el proyecto a tiempo.
Es sencilla y facilita la gestin de proyectos.
Permite tener bajo control el proyecto.
Limita la cantidad de interaccin entre equipos que se produce durante el desarrollo.

Criticas

No refleja realmente el proceso de desarrollo del software. Ya que la mayora de los que
desarrollan proyectos no cumple con este lineamiento.
Se tarda mucho tiempo en pasar por todo el ciclo
La aplicacin de la metodologa en cascada se orienta mejor al desarrollo de proyectos
de corto plazo, de poca innovacin y proyectos definitivos y detallados.
Metodologa pueden confundir al equipo profesional en las etapas tempranas del
proyecto.
No es frecuente que el cliente o usuario final explicite clara y completamente los
requisitos.

MODELO PROTOTIPADO

Modelo de Prototipos. Tambin conocido como desarrollo con prototipacin o modelo de

desarrollo evolutivo, se inicia con la definicin de los objetivos globales para el software, luego
se identifican los requisitos conocidos y las reas del esquema en donde es necesaria ms
definicin. Este modelo se utiliza para dar al usuario una vista preliminar de parte del software.
Este modelo es bsicamente prueba y error ya que si al usuario no le gusta una parte del
prototipo significa que la prueba fallo por lo cual se debe corregir el error que se tenga hasta que
el usuario quede satisfecho. Adems el prototipo debe ser construido en poco tiempo, usando los
programas adecuados y no se debe utilizar mucho dinero pues a partir de que este sea aprobado
nosotros podemos iniciar el verdadero desarrollo del software. Pero eso si al construir el
prototipo nos asegura que nuestro software sea de mejor calidad, adems de que su interfaz sea
de agrado para el usuario. Un prototipo podr ser construido solo si con el software es posible
experimentar.

Etapas

Recoleccin y refinamiento de requisitos

Modelado, diseo rpido
Construccin del Prototipo
Desarrollo, evaluacin del prototipo por el cliente
Refinamiento del prototipo
Producto de Ingeniera

Cmo se lleva a cabo

Se comienza elaborando un prototipo del producto final: qu aspecto tendr, cmo funcionar.
Para muchas interfaces de usuario, este modelo puede resultar tan simple como unos dibujos
con lpiz y papel o tan complejo como el propio cdigo operativo final. Para interfaces de
hardware o estaciones de trabajo, el modelo puede consistir en maquetas de espuma, caucho,
cartn o cartulina. Cuanto ms prximo se encuentre el prototipo al producto real, mejor ser la
evaluacin, si bien se pueden obtener magnficos resultados con prototipos de baja fidelidad.

Ventajas

No modifica el flujo del ciclo de vida

Reduce el riesgo de construir productos que no satisfagan las necesidades de los
usuarios
Reduce costo y aumenta la probabilidad de xito
Exige disponer de las herramientas adecuadas
Este modelo es til cuando el cliente conoce los objetivos generales para 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.

Para que sea efectivo

Debe ser un sistema con el que se pueda experimentar

Debe ser comparativamente barato (menor que el 10%)
Debe desarrollarse rpidamente
nfasis en la interfaz de usuario
Equipo de desarrollo reducido
Herramientas y lenguajes adecuados

Desventajas

Debido a que el usuario ve que el prototipo funciona piensa que este es el producto
terminado y no entienden que recin se va a desarrollar el software.
El desarrollador puede caer en la tentacin de ampliar el prototipo para construir el
sistema final sin tener en cuenta los compromisos de calidad y mantenimiento que tiene
con el cliente

Tipos de Modelo de Prototipos

Modelo de Prototipos rpido: Metodologa de diseo que desarrolla rpidamente

nuevos diseos, los evala y prescinde del prototipo cuando el prximo diseo es
desarrollado mediante un nuevo prototipo.
Modelo de Prototipos reutilizable: Tambin conocido como "Evolutionary
Prototyping"; no se pierde el esfuerzo efectuado en la construccin del prototipo pues
sus partes o el conjunto pueden ser utilizados para construir el producto real.
Mayormente es utilizado en el desarrollo de software, si bien determinados productos
de hardware pueden hacer uso del prototipo como la base del diseo de moldes en la
fabricacin con plsticos o en el diseo de carroceras de automviles.
Modelo de Prototipos Modular: Tambin conocido como Prototipado Incremental
(Incremental prototyping); se aaden nuevos elementos sobre el prototipo a medida que
el ciclo de diseo progresa.
Modelo de Prototipos Horizontal: El prototipo cubre un amplio nmero de aspectos y
funciones pero la mayora no son operativas. Resulta muy til para evaluar el alcance
del producto, pero no su uso real.
Modelo de Prototipos Vertical: El prototipo cubre slo un pequeo nmero de
funciones operativas. Resulta muy til para evaluar el uso real sobre una pequea parte
del producto.

Modelo de Prototipos de Baja-fidelidad: El prototipo se implementa con papel y

lpiz, emulando la funcin del producto real sin mostrar el aspecto real del mismo.
Resulta muy til para realizar tests baratos.
Modelo de Prototipos de Alta-fidelidad: El prototipo se implementa de la forma ms
cercana posible al diseo real en trminos de aspecto, impresiones, interaccin y
tiempo.

Tipos de prototipos
Hay dos clases de prototipos el desechable y el evolucionario.

El desechable: nos sirve para eliminar dudas sobre lo que realmente quiere el cliente
adems para desarrollar la interfaz que ms le convenga al cliente.
El evolucionario: es un modelo parcialmente construido que puede pasar de ser
prototipo a ser software pero no tiene una buena documentacin y calidad.

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

Ciencia de salir del paso.
Mtodo de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofa
interactiva de Construccin de Prototipos. Como se muestra en la Figura 1, 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.

Conclusin:
Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del
producto Software denominados "incrementos" del sistema, que son escogidos en base a
prioridades predefinidas de algn modo. El modelo permite una implementacin con
refinamientos sucesivos (ampliacin y/o mejoras). Con cada incremento se agrega nueva
funcionalidad o se cubren nuevos requisitos o bien se mejora la versin previamente
implementada del producto software.
MODELO ESPIRAL
El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por
Barry Boehm en 1988. El modelo espiral en el desarrollo del software es un modelo meta del
ciclo de vida del software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un
esfuerzo del desarrollo por ah mismo comienza otro; adems en cada ejecucin del desarrollo
se sigue cuatro pasos principales:
1. Determinar o fijar los objetivos.
En este paso se definen los objetivos especficos para posteriormente identifica las limitaciones
del proceso y del sistema de software, adems se disea una planificacin detallada de gestin y
se identifican los riesgos.
2. Anlisis del riesgo.
En este paso se efecta un anlisis detallado para cada uno de los riesgos identificados del
proyecto, se definen los pasos a seguir para reducir los riesgos y luego del anlisis de estos
riesgos se planean estrategias alternativas.
3. Desarrollar, verificar y validar.
En este tercer paso, despus del anlisis de riesgo, se eligen un paradigma para el desarrollo del
sistema de software y se lo desarrolla.
4. Planificar.
En este ltimo paso es donde el proyecto se revisa y se toma la decisin si se debe continuar con
un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los planes para la
siguiente fase del proyecto.

Caractersticas
Es considerado como un modelo evolutivo ya que combina el modelo clsico con el diseo de
prototipos.

Contiene una nueva etapa que es el anlisis de riesgos, no incluida anteriormente.

Este modelo es el indicado para desarrollar software con diferentes versiones
actualizadas como se hace con los programas modernos de PCs.

La ingeniera puede desarrollarse a travs del ciclo de vida clsico o el de construccin

de prototipos.
Este es el enfoque ms realista actualmente.

El modelo en espiral esta compartida en varias actividades estructurales, tambin llamadas

regiones de tareas. Existen seis regiones de tareas que son:
1. Comunicacin con el cliente: esta es una tarea requerida para establecer comunicacin
entre el desarrollador y el cliente.
2. Planificacin: esta tarea es necesaria aplicarla para poder definir los recursos, el tiempo
y otras informaciones relacionadas con el proyecto, es decir, son todos los
requerimientos.
3. Anlisis de riesgos: esta es una de las tareas principales por lo que se aplica el modelo
en espiral, es requerida para evaluar los riesgos tcnicos y otras informaciones
relacionadas con el proyecto.
4. Ingeniera: esta es una tarea necesaria ya que se requiere construir una o ms
representaciones de la aplicacin.
5. Construccin y adaptacin: esta tarea es requerida en el modelo espiral porque se
necesita construir, probar, instalar y proporcionar soporte al usuario.
6. Evaluacin el cliente: esta tambin es una tarea principal, necesaria para adquirir la
reaccin del cliente segn la evaluacin de las representaciones del software creadas
durante la etapa de ingeniera y la de implementacin creada durante la etapa de
instalacin.
Ventajas Del Modelo Espiral

No requiere una definicin completa de los requerimientos del software a desarrollar

para comenzar su funcionalidad.
En la terminacin de un producto desde el final de la primera iteracin es muy factible
aprobar los requisitos.
Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos presentados
tempranamente y existe la forma de poder corregirlos a tiempo.

Desventajas Del Modelo Espiral

Existe complicacin cuando se evala los riesgos.

Se requiere la participacin continua por parte del cliente.
Se pierde tiempo al volver producir inicialmente una especificacin completa de los
requerimientos cuando se modifica o mejora el software.

Conclusin
El prototipo del modelo en espiral para la ingeniera de software es en la actualidad el enfoque
ms realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque
evolutivo para la ingeniera de software, permitiendo al desarrollador y al cliente entender y
reaccionar a los riesgos en cada nivel del modelo en espiral. Utiliza la creacin de prototipos
como un mecanismo de reduccin de riesgo, pero, lo que es ms importante permite a quien lo
desarrolla aplicar el enfoque de creacin de prototipos en cualquier etapa de la evolucin de
prototipos.

MODELO XP (eXtreme Programming)

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

La programacin extrema o XP es una metodologa de desarrollo que se englobara dentro de las

denominadas metodologas giles en la que se da mxima prioridad a la obtencin de
resultados y reduce la burocracia que utiliza las metodologas tradicionales.

Caractersticas De La Metodologa Xp

Se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis

en la adaptabilidad que en la previsibilidad.
Se aplica de manera dinmica durante el ciclo de vida del software.
Es capaz de adaptarse a los cambios de requisitos.
Los individuos e interacciones son ms importantes que los procesos y herramientas.
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas.

Pasos de la Metodologa Xp

Los Pasos fundamentales inmersos en las fases del mtodo son:

Desarrollo iterativo e incremental: Pequeas mejoras, unas tras otras.
Pruebas unitarias continuas: Son frecuentemente repetidas y automatizadas, incluyendo
pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la
codificacin.
Programacin en 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 integracin 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 compartido: 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 del 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 es 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.

Ventajas:

Programacin organizada.

Menor taza de errores.

Satisfaccin del programador.

Desventajas:

Es recomendable emplearlo solo en proyectos a corto plazo.

Altas comisiones en caso de fallar.

Ciclo de entrega en XP

MODELO DE DESARROLLO RAPIDO DE APLICACIONES RAD

El desarrollo rpido de aplicaciones o RAD (Rapid Application Development) es un proceso de
desarrollo de software, desarrollado inicialmente por James Martin en 1980. El mtodo
comprende el desarrollo iterativo, la construccin de prototipos y el uso de utilidades CASE.
Tradicionalmente, el desarrollo rpido de aplicaciones tiende a englobar tambin la usabilidad,
utilidad y la rapidez de ejecucin.
El Desarrollo Rpido de Aplicaciones (DRA) (Rapid Application Development RAD) es un
modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de
desarrollo extremadamente corto. DRA es una adaptacin a "Alta velocidad" en el que se logra
el desarrollo rpido utilizando un enfoque de construccin basado en componentes. Si se
comprenden bien los requisitos y se limita el mbito del proyecto, el proceso DRA permite al
equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de
tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de informacin, el
enfoque DRA comprende las siguientes fases:

Modelado de gestin: el flujo de informacin entre las funciones de gestin se modela

de forma que responda a las siguientes preguntas: Qu informacin conduce el proceso
de gestin? Qu informacin se genera? Quin la genera? A dnde va la
informacin? Quin la proceso?

Modelado de datos: el flujo de informacin definido como parte de la fase de modelado

de gestin se refina como un conjunto de objetos de datos necesarios para apoyar la
empresa. Se definen las caractersticas (llamadas atributos) de cada uno de los objetos y
las relaciones entre estos objetos.
Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos
quedan transformados para lograr el flujo de informacin necesario para implementar
una funcin de gestin. Las descripciones del proceso se crean para aadir, modificar,
suprimir, o recuperar un objeto de datos. Es la comunicacin entre los objetos.
Generacin de aplicaciones: El DRA asume la utilizacin de tcnicas de cuarta
generacin. En lugar de crear software con lenguajes de programacin de tercera
generacin, el proceso DRA trabaja para volver a utilizar componentes de programas ya
existentes (cuando es posible) o a crear componentes reutilizables (cuando sea
necesario). En todos los casos se utilizan herramientas automticas para facilitar la
construccin del software.
Pruebas de entrega: Como el proceso DRA enfatiza la reutilizacin, ya se han
comprobado muchos de los componentes de los programas. Esto reduce tiempo de
pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben
ejercitar todas las interfaces a fondo.

Caractersticas De Rad
Entre las principales caractersticas del RAD tenemos:
1. Equipos Hbridos

Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y

usuarios de tiempo completo del sistema as como aquellas personas involucradas con
los requisitos.
Los desarrolladores de RAD deben ser "renacentistas": analistas, diseadores y
programadores en uno.

2. Herramientas Especializadas

Desarrollo "visual"
Creacin de prototipos falsos (simulacin pura)
Creacin de prototipos funcionales
Mltiples lenguajes
Calendario grupal
Herramientas colaborativas y de trabajo en equipo
Componentes reusables
Interfaces estndares (API)
Control de versiones

3. "Timeboxing"

Las funciones secundarias son eliminadas como sea necesario para cumplir con el
calendario.

4. Prototipos Iterativos y Evolucionarios

Reunion JAD (Joint Application Development):

Se renen los usuarios finales y los desarrolladores.

Lluvia de ideas para obtener un borrador inicial de los requisitos.
Iterar hasta acabar:
Ingeniera de Software
Los desarrolladores construyen y depuran el prototipo basado en los requisitos
actuales.
Los diseadores revisan el prototipo.
Los clientes prueban el prototipo, depuran los requisitos.
Los clientes y desarrolladores se renen para revisar juntos el producto, refinar los
requisitos y generar solicitudes de cambios.
Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios
se eliminan si es necesario para cumplir el calendario.