Metodologa

Modelo en
cascada

Caractersticas
Similares
Las caractersticas de ste
modelo similares a otras
metodologas
son las
siguientes:
Inicia con la especificacin de
requerimientos del cliente y
contina con la planeacin, el
modelado, la construccin y el
despliegue para culminar en el
soporte
del
software
terminado.
Las caractersticas similares
de sta metodologa a las
otras, se basa prcticamente
en el mtodo que se usa y el
objetivo que se busca al
implementar sta metodologa
de Software.
Se puede decir que como las
dems metodologas tienen un
proceso
en
el
cual,
primeramente es la entrevista
con el usuario para establecer
las
necesidades
y

Caractersticas Principales
Desarrollo en cascada, tambin
llamado modelo en cascada, es el
enfoque metodolgico que ordena
rigurosamente las etapas del
ciclo de vida del software, de tal
forma que el inicio de cada etapa
debe esperar a la finalizacin de
la inmediatamente anterior.

Es el ms utilizado.

Es
una
visin
del
proceso de desarrollo de
software
como
una
sucesin de etapas que
producen
productos
intermedios.

Para que el proyecto

tenga
xito
deben
desarrollarse todas las
fases.
Las fases continan
hasta que los objetivos

Ventajas

Desventajas

Se tiene todo bien

organizado y no se
mezclan las fases.
Es perfecto para
proyectos que son
rgidos, y adems
donde
se
especifiquen
muy
bien
los
requerimientos y se
conozca muy bien la
herramienta a utilizar.

La planificacin
sencilla.

La
calidad
del
producto resultante
es alta.

Iteraciones costosas.

Los
problemas
presentan son
posteriormente.

Puede que el software no

cumpla con los requisitos.

Es difcil incorporar nuevas

cosas si se quiere actualizar.

Es normal detenerse en su
desarrollo y seguir con otras
fases.

Se tarda mucho tiempo en

pasar por todo el ciclo.

Las revisiones de proyectos

de gran complejidad son muy
difciles.

es

Sus
fases
son
conocidas por los
desarrolladores.

que
se
corregidos

requerimientos, para seguir

con el diseo la codificacin y
la evaluacin por parte del
Cliente,
as tambin el Modelo en
Cascada.

se han cumplido.

Si se cambia el orden de
las fases, el producto
final ser de inferior
calidad.

FASES
Las fases del mtodo
desarrollo en cascada son:

Modelo Vida
Espiral

Las caractersticas similares

de sta metodologa a las
otras es que como en las
dems se lleva acabo un
etapa en la que se inicia con
entrevistas al cliente o
usuario, despus se disea,
se implementa y el usuario lo
valida haciendo los
comentarios y modificaciones
pertinentes.
Despus de este ciclo se lleva
a cabo otro en el cual despus
de sta entrega y la valoracin
del usuario, se realizan los
mismos pasos desde el inicio
para hacer una modificacin o

Los
usuarios
lo
pueden comprender
fcilmente.

de

Anlisis de requisitos
Diseo del Sistema
Diseo del Programa
Codificacin
Pruebas
Implantacin
Mantenimiento

Es un modelo de proceso de
software evolutivo, desarrollado
por primera vez por Barry
Boehm en 1988.
Las actividades de este modelo
se conforman en una espiral, en
la que cada bucle o iteracin
representa un conjunto de
actividades.
Las actividades no estn fijadas a
priori, sino que las siguientes se
eligen en funcin del anlisis de
riesgo, comenzando por el bucle
interior.
En cada giro se construye un

El modelo en espiral es un
enfoque realista del desarrollo
de sistemas.

Resulta difcil convencer a grandes

clientes de que el enfoque evolutivo es
controlable.

Modelo de proceso adaptable.

El modelo en espiral puede
aplicarse a lo largo de la vida
del software.

Es nuevo y no se ha utilizado tanto

como otros modelos de ciclo de vida.

El desarrollador y el cliente
comprenden y reaccionan
mejor ante riesgos en cada
uno de los niveles evolutivos.
Permite a quien lo desarrolla
aplicar el enfoque de
construccin de prototipos en
cualquier etapa de evolucin
del producto.

Requiere una considerable habilidad

para la evaluacin del riesgo, y cuenta
con esta habilidad para el xito.
Si un riesgo importante no es
detectado y gestionado a tiempo,
indudablemente surgirn problemas.

reajuste al programa.

nuevo modelo del sistema

completo.
Este modelo puede combinarse
con otros modelos de proceso de
desarrollo (cascada, evolutivo).
Mejor modelo para el desarrollo
de grandes sistemas.
El anlisis de riesgo requiere la
participacin de personal con alta
calificacin.
No hay un nmero definido de
iteraciones. Las iteraciones debe
decidirlas el equipo de gestin de
proyecto.
Ms realista que el ciclo de vida
clsico.
Este es el enfoque ms realista
actualmente.

Modelo en
Construccin
de Prototipos

Las caractersticas que hacen

similar sta metodologa alas
dems son las siguientes:
Se puede utilizar como un
modelo del proceso
independiente. Ayuda al desar
rollador de software y al
cliente a entender de mejor
manera cul ser el resultado
de la construccin cuando los

Este modelo comienza con la

recoleccin de requisitos, el
desarrollador y el cliente definen
los objetivos globales para el
software, originndose un diseo
rpido que se centra en una
representacin de esos aspectos
del software que sean visibles
para el usuario/cliente.

Demanda una consideracin

directa de los riesgos tcnicos
en todas las etapas del
proyecto y si se aplica
adecuadamente debe reducir
los riesgos antes de que se
conviertan en problemas.
Modelos evolutivos como el
espiral, son apropiados,
particularmente para el
desarrollo de Sistemas OO.
Trata de mejorar los ciclos de
vida clsicos y prototipos.
Permite acomodar otros
modelos.
Incorpora objetivos de calidad
y gestin de riesgos.
Elimina errores y alternativas
no atractivas al comienzo.

No modifica el flujo
del ciclo de vida.

Reduce el riesgo de
construir productos
que no satisfagan las
necesidades de los
usuarios.

De este diseo surge la

Reduce costos y

A los usuarios les gusta el sistema real

y a los desarrolladores les gusta
construir algo de inmediato. Sin
embargo, la construccin de prototipos
se torna problemtica por las
siguientes razones:

El cliente ve funcionando lo
que para l es la primera
versin del prototipo que ha
sido construido con chicle y

requisitos estn satisfechos.

Se plantea con rapidez una
iteracin de construccin de
prototipos y se presenta el
modelado (en forma de un
diseo rpido).Esto se realiza
al estar escuchando los
requerimientos por parte del
Usuario o por parte del Cliente

construccin de un prototipo y
este es evaluado por el
cliente/usuario. La interaccin
ocurre cuando el prototipo
satisface las necesidades del
cliente.

aumenta la
probabilidad de xito.

Exige disponer de las

herramientas
adecuadas.

No presenta calidad
ni robustez.

Una vez identificados

todos los requisitos
mediante el prototipo,
se construye el
producto de
ingeniera.

cable para embalaje, y puede

decepcionarse al indicarle que
el sistema aun no ha sido
construido.

El desarrollador puede caer en

la tentacin de aumentar el
prototipo para construir el
sistema final sin tener en
cuenta las obligaciones de
calidad y de mantenimiento
que tiene con el cliente.

Modelo
Incremental

Se entrega software por

partes funcionales ms
pequeas.
Pero reutilizables, a los cuales
seles llama incrementos.
El producto esencial queda en
manos del cliente (o se
somete a una evaluacin
detallada).
Este proceso se repite

Los riesgos asociados con el

desarrollo de sistemas largos y
complejos son enormes. Una
forma de recudir los riesgos es
construir solo una parte del
sistema, reservando otros
aspectos para niveles posteriores.

El desarrollo incremental es el
proceso de construccin siempre
incrementando subconjuntos de
requerimientos es escrito al
capturar todos los requerimientos

El modelo de desarrollo
incremental provee algunos
beneficios significativos para
los proyectos:

Construir un sistema
pequeo es siempre
menos riesgoso que
construir un sistema
grande.

Al ir desarrollando
parte de las

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.

despus de la entrega de
cada incremento mientras no
se haya elaborado el producto
completo.
Aplica secuencias lineales de
manera escalonada. Cada
incremento se construye sobre
aquel que ya fue entregado.

para el sistema completo. El

desarrollo incremental no
demanda una forma especifica de
observar el desarroll de algn
otro incremento. As, el modelo
cascada puede ser usado para
administrar cada esfuerzo de
desarrollo.

funcionalidades, es
ms fcil determinar
si los requerimientos
planeados para los
niveles subsiguientes
son correctos.

Si un error importante
es realizado, solo la
ltima iteracin
necesita ser
descartada.

Reduciendo el tiempo
de desarrollo de un
sistema (en este caso
en incremente del
sistema decrecen las
probabilidades que
esos requerimientos
de usuarios puedan
cambiar durante el
desarrollo.

Si un error importante
es realizado, el
incremento previo
puede ser usado.

Los errores de
desarrollo realizados
en un incremento,
pueden ser
arreglados antes del
comienzo del prximo
incremento.

El modelo de desarrollo
incremental provee algunos
beneficios significativos para los
proyectos:
Construir un sistema pequeo es
siempre menos riesgoso que
construir un sistema grande.
Al ir desarrollando parte de las
funcionalidades, es ms fcil
determinar si los requerimientos
planeados para los niveles
subsiguientes son correctos.
Si un error importante es
realizado, solo la ltima iteracin
necesita ser descartada.
Reduciendo el tiempo de
desarrollo de un sistema (en este
caso en incremente del sistema
decrecen las probabilidades que
esos requerimientos de usuarios
puedan cambiar durante el
desarrollo.
Si un error importante es

realizado, el incremento previo

puede ser usado.
Los errores de desarrollo
realizados en un incremento,
pueden ser arreglados antes del
comienzo del prximo incremento.
Proceso
Unificado de
Desarrollo

Las siguientes caractersticas

son las que hacen a sta
metodologa muy similar a las
dems: La arquitectura del
proceso se modela con
orientacin a objetos.
Es un conjunto de
metodologas adaptables al
contexto y necesidades de
cada organizacin. Y tambin
como caracterstica similar a
los de ms es que sta
metodologa es iterativo e
incremental ya que despus
de cada siclo se le hacen
modificaciones al programa

El Proceso Unificado es un marco

de desarrollo iterativo e
incremental compuesto de cuatro
fases denominadas Inicio,
Elaboracin, Construccin y
Transicin.
Cada una de estas fases es a su
vez dividida en una serie de
iteraciones (la de inicio puede
incluir varias iteraciones en
proyectos grandes).
Estas iteraciones ofrecen como
resultado un incremento del
producto desarrollado que aade
o mejora las funcionalidades del
sistema en desarrollo.
Cada una de estas iteraciones se
divide a su vez en una serie de
disciplinas que recuerdan a las
definidas en el ciclo de vida
clsico o en cascada: Anlisis de
requisitos, Diseo,

Coste del riesgo a un

solo incremento.

Mtodo pesado Por el grado

de complejidad puede ser no
muy adecuado.

En proyectos pequeos, es
posible que no se puedan
cubrir los costos de dedicacin
del equipo de profesionales
necesarios.

Tiene las desventajas del

modelo espiral debido a las
iteraciones en cada ciclo y
puede tomar mucho ms
tiempo.

Por el grado de complejidad

puede no resultar muy
adecuado. El RUP es
generalmente mal aplicado en
el estilo cascada. Requiere
conocimientos del proceso y
de UML.

Hay certificaciones RUP.

Reduce el riesgo de
no sacar el producto
en el calendario
previsto.

Acelera el ritmo de
desarrollo.

Se adapta mejor a las

necesidades del
cliente.

Implementacin y Prueba.
Aunque todas las iteraciones
suelen incluir trabajo en casi
todas las disciplinas, el grado de
esfuerzo dentro de cada una de
ellas vara a lo largo del proyecto.

Unifica los mejores

elementos de
metodologas anteriores.

Preparado para
desarrollar grandes y
complejos proyectos.
Orientado a Objetos.
Utiliza el UML como
lenguaje de
representacin visual.

Programacin
Extrema X.P

Las caractersticas similares

de sta metodologa con
algunas de las otras son las
siguientes:
Para el desarrollo de sta
aplicacin se lleva a cabo una
planificacin en donde se
tiene contacto directo con el
cliente, pues este quin
desde un principio establece
y define los requisitos del

As, la XP se puede definir como

un conjunto de pasos de diversas
metodologas, acopladas de
manera que sean pasos flexibles
a seguir utilizadas con el uso
comn, para realizar un desarrollo
ms agradable y sencillo.
Esta metodologa tiene como
base la simplicidad y como
objetivo principal la satisfaccin
del cliente; para lograrlo se deben
tomar en cuenta cuatro valores

Una de las ventajas de la

programacin extrema es que
se adapta al desarrollo
de sistemas pequeos y
grandes; optimiza el tiempo de
desarrollo; permite realizar el
desarrollo del sistema en
parejas para complementar
los conocimientos; el cdigo
es sencillo y entendible,
adems de la poca
documentacin a elaborar

Las desventajas son que no se tiene la

definicin del costo y el tiempo de
desarrollo; el sistema va creciendo
despus de cada entrega al cliente y
nadie puede decir que el cliente no
querr una funcin ms; se necesita de
la presencia constante del usuario, lo
cual en la realidad es muy difcil de
lograr.
Otra desventaja es la programacin en
parejas, algunos desarrolladores son

Software. Durante la vida

del Software se llevan a cabo
pasos
biendefinidos como cualquier
otrametodologa de programac
in endonde u para la
elaboracin de ste existe una
organizacin de los
desarrolladores

fundamentales:
Comunicacin
Es muy importante que haya una
comunicacin constante con el
cliente y dentro de todo el equipo
de trabajo, de esto depender que
el desarrollo se lleve a cabo de
una manera sencilla, entendible y
que se entregue al cliente lo que
necesita.
Simplicidad
En la XP se refiere que ante todo
y sin importar qu funcionalidad
requiera el usuario en su sistema,
ste debe ser fcil. El diseo debe
ser sencillo y amigable al usuario,
el cdigo debe ser simple y
entendible, programando slo lo
necesario y lo que se utilizar.
Retroalimentacin
Es la comunicacin constante
entre el desarrollador y el usuario.
Coraje. Se refiere a la valenta
que se debe tener al modificar o
eliminar el cdigo que se realiz
con tanto esfuerzo; el
desarrollador debe saber cuando
el cdigo que desarroll no es til
en el sistema y, por lo mismo,
debe ser eliminado. Tambin se
refiere a tener la persistencia para
resolver los errores en la
programacin.
Dentro de la programacin

para el desarrollo del sistema.

Programacin
organizada.
Menor taza de
errores.
Satisfaccin del
programador.

celosos del cdigo que escriben y no

les es grato que alguien ms modifique
las funciones que realiz o que su
cdigo sea desechado por no cubrir el
estndar.
Es recomendable emplearlo solo en
proyectos a corto plazo.
Altas comisiones en caso de fallar.

extrema se tiene 12 principios que

llevan o guan el desarrollo con
esta metodologa:
1. El principio de pruebas
2. Proceso de planificacin
3. El cliente en el lugar
4. Programacin en parejas
5. Integracin contina
6. Refactorizacin
7. Entregas pequeas
8. Diseo simple
9. Metfora
10. Propiedad colectiva del cdigo
11. Estndar de codificacin
12. La semana de 40 horas
Metodologa
SCRUM

Esta metodologa se
caracteriza con las dems
porque durante el desarrollo
de Software hay etapas
interactivas e incrementales
basadas en practicas agiles.
Comparte los principios
estructurales del desarrollo
agial, a partir del concepto o
visin de la necesidad del
cliente, construye el producto
de forma incremental a travs
de iteraciones breves que
comprenden fases de
especulacin exploracin y
revisin. Estas iteraciones (en
Scrum llamadas sprints) se
repiten de forma continua
hasta que el cliente da por
cerrado el producto. Scrum es

Enfatiza valores y prcticas de

gestin, sin pronunciarse sobre
requerimientos, prcticas de
desarrollo, implementacin y
dems cuestiones tcnicas.
Hace uso de Equipos autodirigidos y auto-organizados
Puede ser aplicado tericamente
a cualquier contexto en donde un
grupo de gente necesita trabajar
junta para lograr una meta comn.
Desarrollo de software iterativo
incremental basado en prcticas
agiles Iteraciones de treinta das;
aunque se pueden realizar con
ms frecuencia, estas iteraciones,
conocidas como Sprint. Dentro de
cada Sprint se denomina el Scrum

La primera y la que, a mi
parecer es la ms importante,
es que estas metodologas
ofrecen una rpida respuesta
a cambios de requisitos a lo
largo del desarrollo del
proyecto gracias a su proceso
iterativo, es tan importante
realizar una buena recolecta
de requisitos, como despus
poder modificarlos evitando
grandes prdidas en cuanto a
costes, motivacin, tiempo

Falta de documentacin del diseo. Al

no haber documentacin es el cdigo
(junto con sus comentarios) lo que se
toma como documentacin.
Problemas derivados de la
comunicacin oral. No hace falta decir
que algo que est escrito no se puede
borrar, en cambio, algo dicho es muy
fcil crear ambigedad.

El cliente, si quiere colaborar,

puede observar como va
avanzando el proyecto, y por
supuesto, opinar sobre su
evolucin gracias a las
numerosas reuniones que

Restricciones en cuanto a tamao

de los proyectos.

Fuerte dependencia de las personas.

Falta de reusabilidad derivada de la
falta de documentacin.

Problemas derivados del fracaso de

los proyectos giles. Si un proyecto gil
fracasa no hay documentacin o hay

un proceso en el que se
aplican de manera regular un
conjunto de mejores prcticas
para trabajar en equipo y
obtener el mejor resultado
posible de un proyecto. Estas
prcticas se apoyan unas a
otras y su seleccin tiene
origen en un estudio de la
manera de trabajar de equipos
altamente productivos.

Master al Lder de Proyecto quien

llevar a cabo la gestin de la
iteracin.
Se convocan diariamente un
Scrum Daily Meeting el cual
representa una reunin de avance
diaria de no ms de 15 minutos
con el propsito de tener
realimentacin sobre las tareas de
los recursos y los obstculos que
se presentan.
En la cual se responden
preguntas como: Qu has hecho
desde el ltimo encuentro? Qu
obstculos hay para cumplir la
meta? Qu hars antes del
prximo encuentro?

realiza el equipo con el cliente.

Esto le da tranquilidad.

muy poca; lo mismo ocurre con el

diseo.

Uniendo las dos anteriores, se

puede deducir que al utilizar
estas metodologas, los
cambios que quiera realizar el
cliente van a tener un menor
impacto, ya que se va a
entregar en un pequeo
intervalo de tiempo un
pequeo trozo del proyecto
al cliente, y si ste quiere
cambiarlo, solo se habr
perdido unas semanas de
trabajo.
Con las metodologas
tradicionales las entregas al
cliente se realizaban tras la
realizacin de una gran parte
del proyecto, eso quiere decir
que el equipo ha estado
trabajando meses para que
luego un mnimo cambio que
quiera realizar el cliente,
conlleve la prdida de todo
ese trabajo.

La comprensin del sistema se queda

en las mentes de los desarrolladores.

Importancia de la simplicidad
al eliminar trabajo innecesario

Qu es lo que pudiste observar mediante la tabla respecto a las caractersticas de los modelos?
Las metodologas de desarrollo de Software son una herramienta indispensable para poder llevar a cabo el desarrollo de las
aplicaciones, todas tienen una caractersticas principal que es lo que las hacen diferentes, pero tambin tienen caractersticas
10

similares que por lo general stas caractersticas establecen la vida del Software ya que se considera desde que se tiene la idea de
crear una aplicacin, hasta que el cliente acepta la aplicacin y se da por concretado el proyecto. Cada una de estas metodologa
tienen sus particularidades, yo veo que cualquiera de ellas puedes usarse para el desarrollo de una aplicacin pero si estas se
analizan detalladamente se da uno cuenta que tiene ventajas y desventajas y es cuando el desarrollador tiene que dedicarle mucho
estudio en cual es la que mas le conviene tanto a uno como programador y poder establecer y seguidamente cul va a ser la mejor
metodologas para que se le pueda adaptar al proyecto del cliente o usuario.
Empezaremos con el modelo en cascada es muy interesante porque desde el principio se tiene contacto con el cliente y se va
desarrollando el Software por etapas que esto es lo interesante pero ya esta metodologa ya casi no se esta usando ya que los
actuales software requieren de metodologas mas avanzadas para que soporten programas ms elaborados para que se vayan
involucrando ms programadores. El MODELO BASADO EN PROTOTIPOS. El cliente puede hacer pensar que el prototipo es una
versin acabada. Pero por esto pueden llegar a pasarse por alto la calidad del software global o el mantenimiento a largo plazo. Las
herramientas elegidas pueden ser inadecuadas. La clave del xito de este modelo consiste en definir bien, desde el principio, las
reglas del juego. Y tiene un alto grado de participacin del usuario.
La programacin extrema es una programacin que se plantea muy interesante, esto debido a que durante la programacin se
involucra al Cliente o al Usuario y se siente parte del equipo de trabajo y se tiene la informacin a la mano de los requerimientos que
deber llevar el Software a desarrollarse. El MODELO INCREMENTAL O EVOLUTIVO. Los clientes no tienen que esperar hasta
tener el sistema completo. El primer incremento satisface los requisitos ms crticos. Los primeros incrementos sirven como
prototipo y ayudan en la tarea de detectar los posteriores requisitos. Existe un riesgo bajo de fallar en el proyecto total. Los servicios
del sistema con la prioridad ms alta tienden a ser los ms probados .Puede ser difcil ajustar los requisitos a los incrementos. El
MODELO ESPIRAL, Requiere comunicacin permanente con el cliente por lo tanto si se cambia el contacto con el cual se realiza
desarrollo es necesario que est al tanto de lo realizado y lo pendiente, cliente debe ser gran conocedor del sistema. El MODELO
BASADO EN COMPONENTES (ORIENTADO A OBJETOS). Optimiza los tiempos de respuesta a los requerimientos del cliente y
facilita la labor del programador pues hay un alto aprovechamiento del cdigo. La metodologa que creo que es la ms funcional es
la metodologa RUP esto porque la metodologa de RUP (Scrum) y junto con el lenguaje Unificado de Modelado UML, constituye la
metodologa estndar ms utiliza para el anlisis, implementacin y documentacin de sistemas orientados a objetos. El RUP no es
un sistema con pasos firmente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada
organizacin. Originalmente se dise un proceso genrico y de dominio pblico, , se enfoca fuertemente sobre la arquitectura del
software, para su implementacin se hace a travs de cuatro etapas o fases y en cada una de estas etapas es desarrollada
mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala, este tiene grandes
11

ventajas con respectos a XP, ya que se enfoca en los requisitos y el diseo, as como tambin el cliente interacta con el equipo de
desarrollo mediante reunionesa diferencia de la metodologa XP que el cliente es parte del equipo. Sin duda RUP es una de las
metodologas ms completas y satisfactorias que se puede usar para el desarrollo de un Software.
REFERENCIAS BIBLIOGRFICAS.
Ingeniera de software. Teora y Prctica. Shari Lawrence Peleeger.
Un enfoque prctico Roger S. Pressman Mc Graw Hill. Fuentes Consultadas.
http://boyso.wordpress.com/2008/04/29/ciclo-de-vida-de-los-sistemas-modelo-por-prototipos/
http://scruz334.blogspot.es/i2007-10/
http://frios334.blogspot.es/i2007-04/ Administracin de Proyectos. 8
http://desarrollodefw.blogspot.mx/2012/10/caracteristicas-scrum.html
http://www.uv.mx/universo/486/infgral/infgral_15.html
https://sisteminformacii.wikispaces.com/MODELO+DE+PROTOTIPOS
Fuentes:
Beck, K. A. (2004). Extreme Programming Explained. Addison Wesley.
Martin, R., & Newkirk, J. (2002). La programacion extrema en la practica. Pearson Addison-Wesley.

12