INTEGRANTES:

Arellano del Aguila Jorge Arturo

joararellanode@ittepic.edu.mx

13400382

Becerra Casillas Efrain Alejandro

efalbecerraca@ittepic.edu.mx

13400391

Garnica Lpez Luis Alberto

lualgarnicalo@ittepic.edu.mx

13400416

Pardo Prez Jessica Lizbeth

13400472

Contents
Introduccin........................................................................................................ 2
Metodologas clsicas......................................................................................... 3
Metodologa en Cascada.................................................................................. 3
Caractersticas............................................................................................. 5
Modelo Incremental......................................................................................... 6
Caractersticas............................................................................................. 8
Modelo Evolutivo............................................................................................. 9
Caractersticas........................................................................................... 11
Modelo en Espiral.......................................................................................... 12
Caractersticas........................................................................................... 14
Modelo de Prototipos..................................................................................... 15
Caractersticas........................................................................................... 16
Desarrollo basado en componentes...............................................................17
Caractersticas........................................................................................... 19
Otras Metodologas........................................................................................... 20
Modelo Ganar-Ganar...................................................................................... 20
Caractersticas........................................................................................... 21
Proceso Unificado (UP)................................................................................... 22
Caractersticas........................................................................................... 23
Ingeniera Web............................................................................................... 24
Caractersticas........................................................................................... 25
Metodologas giles....................................................................................... 26
Caractersticas........................................................................................... 29
Metodologa Emergente................................................................................. 30
Caractersticas........................................................................................... 31
Reingeniera...................................................................................................... 31
Caractersticas........................................................................................... 33
Herramientas de Comparacin.........................................................................35
Comparacin de ventajas y desventajas.......................................................38
Observaciones............................................................................................... 42
Referencias....................................................................................................... 44

Introduccin
Dentro de esta investigacin se abarcan tanto la parte de la extraccin y
recopilacin, como la contrastacin de las caractersticas que identifica a cada
una de las diferentes metodologas que se han considerado dentro del trabajo
de la unidad. El trabajo consta de 2 partes, la primera consiste en el anlisis de
las caractersticas principales de cada una de las metodologas, la
investigacin de este punto se estructur primero con el concepto de cada
una, el cual se ha extrado de la consulta de varios autores, seguida de una
relacin de todas las caractersticas que se considera definen
principalmente a dicha metodologa. Esto se hace basndonos en una
categorizacin, comenzando por la investigacin de las llamadas
metodologas clsicas y continuando con las menos comunes, por ltimo, se
analiza la reingeniera y como incide en los procesos de desarrollo y
mantenimiento de software. La segunda parte del trabajo, consiste en una
herramienta de aprendizaje que nos permite realizar una comparacin clara de
las caractersticas de cada una de las metodologas investigadas, para poder
observar similitudes y diferencias que se presentan en cada metodologa,
pudiendo de ello, comenzar a inferir en que caso resulta ms til apegarse a
alguna y en qu caso a otra.
Realizar una investigacin respecto a las metodologas, nos permite
comprender en qu consisten y cules son sus puntos fuertes, para que, en un
futuro, y en proyectos posteriores, podamos pensar en la mejor manera en que
pueden ser aplicadas. Esto es importante ya que el desarrollo de sistemas de
informacin, y de todo tipo de soluciones de software ha ido incrementando en
complejidad, a medida que las computadoras han ido incrementando en sus
capacidades. Esto es consecuencia del desarrollo de nueva tecnologa el cual
ha obligado a que el desarrollo de software deba aplicar tcnicas de ingeniera
para poder proporcionar soluciones eficientes ya que se trata de proyectos
muy grandes y que tienen muchos componentes o elementos que deben
trabajarse en manera colaborativa. Si uno no se apega adecuadamente a una o
varias metodologas de desarrollo el proyecto puede tener inconsistencias y
contradicciones internas.
La informacin que se ha extrado y se presenta compactada en el este
documento, es producto de un proceso de investigacin documental. Para ello
se contrast la informacin que al respecto nos proporcionaban varios autores
que se consideran expertos en la materia. Dichos autores se encuentran
debidamente referenciados a lo largo del texto, para que se pueda ubicar con
facilidad el origen de la informacin presentada. Trabajar mediante la
investigacin documental, si bien resulta prctico para las llamadas
metodologas clsicas, representa un problema cuando se trata de obtener
informacin de las metodologas ms recientes, muchas de las cuales resulta
difciles de investigar en informacin en nuestro idioma, lo que obliga a buscar
fuentes de informacin menos comunes.
Se espera que el resultado de esta investigacin sea capaz de reflejar
adecuadamente la informacin sobre las metodologas, de manera que sea

clara y de fcil entendimiento, y que proporcione una gua respecto a las

mismas y para poder tomarla como base en la eleccin de una metodologa al
plantearse el inicio de un proyecto de software.

Metodologas clsicas
Metodologa en Cascada
El autor Weitzenfeld (2005)1 nos menciona que el modelo en cascada original
se desarroll entre las dcadas de los sesenta y setenta, y que se define como
una secuencia de actividades, donde la estrategia principal es seguir el
progreso del desarrollo de software haca puntos de revisin definidos
mediante estregas calendarizadas.

El modelo original plantea que cada actividad debe completarse antes de

poder continuar con la siguiente actividad. Sin embargo, en una revisin
posterior se extendi el modelo permitiendo el regreso a actividades
anteriores.
Weitzenfeld nos puntualiza algunas creencias del modelo en cascada:

Las metas se logran mejor cuando se tienen puntos de revisin bien

preestablecidos y documentados, dividiendo el desarrollo en actividades
secuenciales bien definidas.

Weitzenfeld, A. (2005). Ingeniera de software orientada a objetos con UML, Java e Internet. D.F.,

Mxico: Thomson. Pg. 50

Los documentos tcnicos son comprensibles para usuarios y

administradores no tcnicos.
Cada detalle de los requisitos se conoce de antemano antes de
desarrollar el software, y los detalles son estables durante el desarrollo.
Las pruebas y evoluciones se realizan eficientemente al final del
desarrollo.

Por otro lado Sommerville (2011)2 lo conceptualiza diciendo que recibe su

nombre debido al paso de una fase en cascada a otra. Es un ejemplo de un
proceso dirigido por un plan en principio, pues se debe planear y programar
todas las actividades del proceso, antes de comenzar a trabajar con ellas.

Posteriormente identifica las principales etapas del modelo en cascada de la

siguiente manera, e indicando que cada una representa una parte del ciclo de
vida del software tradicional:
1. Anlisis y definicin de requerimientos. Los servicios, las restricciones y
las metas del sistema se establecen mediante consulta a los usuarios del
sistema. Luego, se definen con detalle y sirven como una especificacin
del sistema.
2. Diseo del sistema y del software. El proceso de diseo de sistemas
asigna los requerimientos, para sistemas de hardware o de software, al
establecer una arquitectura de sistema global. El diseo del software
implica identificar y describir las abstracciones fundamentales del
sistema de software y sus relaciones.
3. Implementacin y prueba de unidad. Durante esta etapa, el diseo de
software se realiza como un conjunto de programas o unidades del
programa. La prueba de unidad consiste en verificar cada unidad cumpla
con su especificacin.

2 Somerville, I. (2005). Ingeniera del Software (Sptima ed.). Madrid, Espaa: Pearson Educacin. Pg.
62

4. Integracin y prueba del sistema. Las unidades del programa o los

programas individuales se integran y prueban como un sistema
completo para asegurarse de que se cumplan los requerimientos de
software. Despus de probarlo, se libera el sistema de software al
cliente.
5. Operacin y mantenimiento. Por lo general (aunque no necesariamente),
sta es la fase ms larga del ciclo de vida, donde el sistema se instala y
se pone en prctica. El mantenimiento incluye corregir los errores que no
se detectaron en etapas anteriores del ciclo de vida, mejorar la
implementacin de las unidades del sistema e incrementar los servicios
del sistema conforme se descubren nuevos requerimientos.
Las cuales, como vemos, difieren de las que planteaba Weitzenfield, y que son
de hecho las ms conocidas y las que suelen tomarse en cuenta al hablar de
este modelo. En este modelo en cada fase se produce documentacin. Esto lo
hace visible, de modo que los administradores monitorean el progreso contra el
plan de desarrollo. Su principal problema es la particin inflexible del proyecto
en distintas etapas. Tienen que establecerse compromisos en una etapa
temprana del proceso, lo que dificulta responder a los requerimientos
cambiantes del cliente.
El modelo en cascada slo debe usarse cuando los requerimientos se
entiendan bien y sea improbable el cambio radical durante el desarrollo del
sistema. Sin embargo, el modelo en cascada refleja el tipo de proceso utilizado
en otros proyectos de ingeniera. Como es ms sencillo emplear un modelo de
gestin comn durante todo el proyecto, an son de uso comn los procesos
de software basados en el modelo en cascada.

Caractersticas

Define una secuencia de actividades, donde la estrategia principal es

seguir el progreso del desarrollo de software haca puntos de revisin
definidos mediante entregas calendarizadas
Los documentos tcnicos son comprensibles para usuarios y
administradores no tcnicos.
Cada detalle de los requisitos se conoce de antemano antes de
desarrollar el software, y los detalles son estables durante el desarrollo.
Las pruebas y evoluciones se realizan eficientemente al final del
desarrollo.
Cada actividad debe completarse antes de poder continuar con la
siguiente actividad, aunque actualmente se admiten excepciones.
Recibe su nombre debido al paso de una fase en cascada a otra.
Tienen que establecerse compromisos en una etapa temprana del
proceso, lo que dificulta responder a los requerimientos cambiantes del
cliente.

Modelo Incremental
Segn el enfoque de Pressman (2002)3 el modelo incremental combina
elementos del modelo lineal secuencial con la filosofa interactiva de
construccin de prototipos. Aplica secuencias lineales de forma escalonada
conforme avanza el tiempo y en cada secuencia lineal produce un incremento
del software.

Por otro lado Weitzenfeld (2005)4 menciona que el modelo incremental es un

desarrollo inicial de la arquitectura completa del sistema, seguido de

3 Pressman, R. S. (2002). Ingeniera del software. Un enfoque prctico. (Quinta ed.). Madrid, Espaa:
McGraw Hill. Pg. 52

incrementos y versiones parciales del mismo. Cada incremento tiene su propio

ciclo de vida.
Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema.
Conforme se completa cada etapa, se verifica e integra la versin con las
dems versiones ya completadas del sistema. Durante cada incremento, el
sistema evala con respecto al desarrollo de versiones futuras. Las actividades
se dividen en procesos y subprocesos, dando lugar al trmino software factory.
Para que la secuencia de desarrollo sea exitosa, es esencial definir etapas que
no requieran cambiar los resultados anteriores al agregar nuevas. Por lo tanto,
es importante comprender al inicio los requisitos completos del sistema, algo
que normalmente es muy difcil de lograr.
El desarrollo incremental evita la teora del "Bing bang" para el desarrollo de
software, donde una gran explosin de desarrollo se transforma
repentinamente en el sistema final.
Algunas creencias del modelo incremental son las que se mencionan a
continuacin:

La administracin de proyectos es ms fcil de lograr en incrementos

ms pequeos.
Es ms fcil comprender y probar incrementos de funcionalidad ms
pequeos.
La funcionalidad inicial se desarrolla ms temprano, logrando los
resultados de inversin en menor tiempo.
Hay ms probabilidad de satisfacer el cambio en los requisitos de
usuario mediante incrementos de software en el tiempo, que si fueran
planeados todos a la vez en un mismo periodo.

Desde el punto de vista del autor Somerville (2005) 5 el modelo incremental es

un enfoque intermedio, es decir se encuentra entre el modelo de desarrollo en
cascada y el desarrollo evolutivo y combina las ventajas de ambos modelos.
En un proceso de desarrollo incremental los clientes identifican a grandes
rasgos los servicios que proporcionar el sistema, identifican qu servicios son
ms importantes y cules menos. Entonces, se definen varios incrementos en
donde cada uno proporciona un subconjunto de la funcionalidad del sistema. La
asignacin de servicios a los incrementos depende de la prioridad del servicio
con los servicios de prioridad ms alta entregados primero.

4 Weitzenfeld, A. (2005). Ingeniera de software orientada a objetos con UML, Java e Internet. D.F.,
Mxico: Thomson. Pg.51.

5 Somerville, I. (2005). Ingeniera del Software (Sptima ed.). Madrid, Espaa: Pearson Educacin. Pg.
66

Una vez que los incrementos del sistema se han identificado, los
requerimientos para los servicios que se van a entregar en el primer
incremento se definen en detalle, y este se desarrolla. Durante el desarrollo,
se puede llevar a cabo un anlisis adicional de requerimientos para los
requerimientos posteriores, pero no se aceptan cambios en los requerimientos
para el incremento actual.
Una vez que el incremento se completa y entrega, los clientes pueden ponerlo
en servicio, esto significa que tienen una entrega temprana de parte de la
funcionalidad del sistema. Pueden experimentar con el sistema, lo cual les
ayuda a clarificar sus requerimientos para los incrementos posteriores y para
las ltimas versiones del incremento actual. Tan pronto como se completan los
nuevos incrementos, se integran en los existentes de tal forma que la
funcionalidad del sistema mejora con cada incremento entregado. Los servicios
comunes se pueden implementar al inicio del proceso o de forma incremental
tan pronto como sean requeridos por un incremento.
El proceso del desarrollo incremental segn Somerville se representa con el
siguiente diagrama, donde se puede observar que en efecto es un proceso
iterativo:

Caractersticas

El modelo de proceso incremental es iterativo por naturaleza.

Aplica secuencias lineales de forma escalonada conforme avanza el
calendario establecido.
Cada secuencia lineal produce un incremento del software, es decir una
parte pequea, pero utilizable.
Se centra en la entrega de un producto opcional con cada incremento.
Cuando se utiliza un modelo incremental, el primer incremento a
menudo es un producto esencial. Es decir se afrontan requisitos bsicos
pero muchas funciones suplementarias quedan sin extraer.
Cada incremento se escribe sobre aqul que ya ha sido entregado.
Se recomienda utilizar esta metodologa cuando se tenga una fecha de
entrega imposible de cambiar.

Es particularmente til cuando la dotacin de personal no est

disponible para una implementacin completa en la fecha lmite que se
haya establecido para el proyecto.
Los primeros incrementos se pueden implementar con menos personas.
Define una secuencia de actividades, donde la estrategia principal es
seguir el progreso del desarrollo de software haca puntos de revisin
definidos mediante entregas calendarizadas
Los documentos tcnicos son comprensibles para usuarios y
administradores no tcnicos.
Cada detalle de los requisitos se conoce de antemano antes de
desarrollar el software, y los detalles son estables durante el desarrollo.
Las pruebas y evoluciones se realizan eficientemente al final del
desarrollo.

Modelo Evolutivo
Llamado por Ian Somerville6, Desarrollo Evolutivo el autor nos dice que 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. Dicha afirmacin se acompaa
de un diagrama que lo representa.

6 Somerville, I. (2005). Ingeniera del Software (Sptima ed.). Madrid, Espaa: Pearson Educacin. Pg.
63

Como vemos las actividades de especificacin, desarrollo y validacin se

entrelazan en vez de separarse, con una rpida retroalimentacin entre stas.
El punto principal que este autor destaca es que partiendo de una versin
inicial que se presenta al cliente, se mejoran, aaden o redisean partes de la
misma segn sucesivas revisiones y opiniones del cliente hasta lograr llegar a
la versin final.
Otra perspectiva, brindada por Weitzenfeld 7, lo llama modelo evolucionario y
nos indica que se trata de una extensin al modelo incremental, donde los
incrementos se hacen de manera secuencial en lugar de en paralelo. Desde el
punto de vista del cliente, el sistema evoluciona segn se van entregando los
incrementos. Desde el punto de vista del desarrollador, los requerimientos que
son claros al principio del proyecto dictarn el incremento inicial, mientras que
los incrementos para cada uno de los siguientes ciclos de desarrollo sern
clarificados a travs de la experiencia de los incrementos anteriores. La clave
en lo que Weitzenfeld nos asegura es que los incrementos que se hacen, no
son en el sentido de hacer una parte del sistema y llevarla hasta su versin
final, para luego hacer otra, proceso que se sigue en el modelo incremental.
Sino hacer una versin completa inicial, sujeta a modificaciones,
adaptaciones y a sumarle ms y ms particularidades hasta convertirla en la
versin esperada por el cliente.
Sommerville, por otro lado, divide esta metodologa en 2 tipos:
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

7 Weitzenfeld, A. (2005). Ingeniera de software orientada a objetos con UML, Java e Internet. D.F.,
Mxico: Thomson. Pg.52.

sistema. El prototipo se centra en experimentar con los requerimientos

del cliente que no se comprenden del todo.
Como vemos, la segunda categorizacin de Sommerville coincide ms con lo
que plantea Alfredo, sin embargo la primera pareciera ms enfocada a la suma
de caractersticas, intentando que se encuentren cada vez, lo ms completas
posibles antes de poder pasar a lo siguiente.
Sommerville tambin nos hace algunas anotaciones sobre cuando resulta ms
prctico y cuando no, el utilizar este modelo de desarrollo. Nos dice que 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. Y que Tan pronto como los usuarios desarrollen un mejor
entendimiento de su problema, ste se puede reflejar en el sistema software.
Al respecto de cuando es mejor no utilizarlo, Sommerville identifica 2
problemas que tiene esta metodologa. La primera es que el proceso no es
visible. Esto significa que los administradores tienen que hacer entregas
regulares del software para poder medir el progreso. Si los sistemas se
desarrollan rpidamente, no es rentable producir documentos que reflejen cada
versin del sistema pues se generar demasiada documentacin. La segunda y
que de hecho es bastante importante y limita demasiado este modelo es que 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.
Es por lo anterior que Sommerville solo lo recomienda para utilizarlo en
sistemas pequeos, que el define como sistemas de hasta 500.000 lneas de
cdigo. Para sistemas grandes, recomienda un proceso mixto que combine lo
mejor del modelo en cascada, el desarrollo evolutivo. Esto puede implicar,
segn el autor, desarrollar un prototipo desechable utilizando un enfoque
evolutivo para resolver incertidumbres en la especificacin del sistema. Y luego
entonces reimplementarse 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
podran desarrollar siempre utilizando un enfoque de programacin
exploratoria.
En este sentido Weitzenfield identifica las siguientes, como algunas creencias
en que se basa el modelo evolucionario.

Se entrega temprano parte del sistema, aunque no estn completos

todos los requerimientos.
Se permite entregar parte del sistema como herramienta para la
generacin de requerimientos faltantes.

Se obtienen beneficios para el sistema mediante entregas iniciales,

mientras las entregas posteriores estn en desarrollo.

Caractersticas

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.
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.
Solo se recomienda para utilizarlo en sistemas pequeos, como
sistemas de hasta 500.000 lneas de cdigo.
Suele ser ms efectivo que el enfoque en cascada, ya que satisface
las necesidades inmediatas de los clientes.
Los cambios continuos tienden a corromper la estructura del
software.

Modelo en Espiral
De acuerdo al autor Somerville8, este modelo fue propuesto por Boehm en
1988, que estaba dirigido por el riesgo. Este se representa como un espiral, y
no como una secuencia de actividades con cierto retroceso de una actividad a
otra. Se menciona que cada ciclo en la espiral representa una fase del proceso
de software. Esto quiere decir que el ciclo interno puede relacionarse con la
factibilidad del sistema, el siguiente con la definicin de requerimientos, el
ciclo que sigue con el diseo del sistema, y as sucesivamente. Este modelo
combina el evitar el cambio con la tolerancia al cambio. Esto supone que los
cambios son resultado de riesgos del proyecto e incluye actividades de gestin
de riegos explcitas para reducir tales riesgos.
Por otra parte, Pressman9 nos dice que el modelo espiral es un modelo
evolutivo del proceso de software que, adems, se acopla con la naturaliza
iterativa de hacer prototipos con los aspectos controlados y sistmicos del
modelo de cascada. Su creador, Boehm lo define del modo siguiente:
El modelo de desarrollo espiral es un generador de modelo de proceso
impulsado por el riesgo, que se usa para guiar la ingeniera concurrente con
participantes mltiples de sistemas intensivos en software. Tiene dos
caractersticas distintivas principales. La primera es el enfoque cclico para el
crecimiento incremental del grado de definicin de un sistema y su
implementacin, mientras que disminuye su grado de riesgo. La otra es un
conjunto de puntos de referencia de anclaje puntual para asegurar el
compromiso del participante con soluciones factibles y mutuamente
satisfactorias.
Con el empleo del modelo espiral, el software se desarrolla en una serie de
entregas evolutivas. Durante estas iteraciones, al inicio se entregan modelos o
prototipos. En las posteriores se producen versiones cada vez ms completas
del sistema cuya ingeniera se est haciendo.
Antes de comenzar el proceso evolutivo, el equipo de software realiza
actividades implcitas en un circuito alrededor de la espiral en el sentido
horario, partiendo del centro.

8 Ian Somerville. Ingeniera de Software (9na Edicin) Pearson Education.

Mxico D.F. 2011. Pg. 68
9 Roger Pressman. Ingeniera de Software, Un enfoque Prctico. (7ma Edicin)
Mc Graw Hill. Mxico D.F. 2010. Pg. 58

Cada
la
se
en

ciclo en
espiral
divide
cuatro

sectores:
1. Establecimiento de objetivos: Se definen objetivos especficos
para dicha fase del proyecto. Se identifican restricciones en el
proceso y el producto, y se traza un plan de gestin detallado. Se
identifican los riesgos del proyecto, pueden planearse estrategias
alternativas, segn sean los riesgos.
2. Valoracin y reduccin del riesgo: En cada uno de los riesgos
identificados del proyecto, se realiza un anlisis minucioso. Se dan
acciones para reducir el riesgo. Por ejemplo, si existe un riesgo de
que los requerimientos sean inadecuados, puede desarrollarse un
sistema prototipo.
3. Desarrollo y Validacin: Despus de una evaluacin del riesgo, se
elige un modelo de desarrollo para el sistema. Por ejemplo, la
creacin de prototipos desechables sera el mejor enfoque de
desarrollo, si predominan los riesgos en la interfaz del usuario. Si
la principal consideracin son los riesgos de seguridad, el
desarrollo con base en transformaciones formales sera el proceso
ms adecuado, entre otros. Si el principal riesgo identificado es la
integracin de subsistemas, el modelo en cascada sera el mejor
modelo de desarrollo a utilizar.
4. Planeacin: El proyecto se revisa y se toma una decisin sobre si
hay que continuar con otro ciclo de la espiral. Si es as, se trazan
todos los planes para la siguiente fase del proyecto. 10
Como podemos ver en la imagen de arriba, el modelo en espiral se da por
diversos circuitos donde poco a poco se van desarrollando pequeas partes

10 Ian Somerville. Ingeniera de Software (9na Edicin) Pearson Education.

Mxico D.F. 2011.

del proyecto. Pressman nos explica que, en el primer circuito alrededor de la

espiral da como resultado el desarrollo de una especificacin del producto: las
vueltas sucesivas se usan para desarrollar un prototipo, y luego, versiones
cada vez ms sofisticadas del software. Cada vez que se pase por la primera
fase del proyecto, se realizarn ajustes en el mismo plan, y as con las dems
fases. El gerente del proyecto ajusta el nmero planeado de iteraciones que se
requieren para terminar el software.
A diferencia de otros modelos de proceso de desarrollo que finalizan cuando se
entrega el software, este modelo espiral puede adaptarse para aplicarse a lo
largo de toda la vida del software de cmputo. Por lo que se puede comprobar
que, el primer circuito alrededor de la espiral puede representar un proyecto
de desarrollo del concepto que comienza en el centro de la espiral y contina
por iteraciones mltiples hasta que queda terminado el desarrollo del concepto.
Si el concepto va a desarrollarse en un producto real, el proceso sigue hacia
afuera de la espiral y comienza un producto nuevo. Este seguir su camino por
iteraciones, hasta que el software se retira.

Caractersticas

Enfoque cclico para el crecimiento incremental del grado de definicin

de un sistema y su implementacin.
Contiene un conjunto de puntos de referencia de anclaje puntual para
asegurar el compromiso del participante con soluciones factibles y
mutuamente satisfactorias.
El software se desarrolla en una serie de entregas evolutivas, llamadas
prototipos.
Se divide en cuatro sectores: Establecimiento de sectores, Valoracin y
reduccin del riesgo, Desarrollo y Validacin y Planeacin.
Combina evitar el cambio con la tolerancia al mismo, debido a que se
incluyen actividades para reducir estos riesgos.
Es necesario contar con un grupo de usuarios o expertos que puedan
evaluar el producto y estudiar su adecuacin, aportando mejoras y
requisitos realistas.11
El modelo espiral puede adaptarse para aplicarse a lo largo de toda la
vida del software.

11 Jos Salvador Snchez Garreta. Ingeniera de Proyectos Informticos:

actividades y procedimientos. Universitat Jaume I, 2003

Modelo de Prototipos
Por ultimo dentro de las metodologas clsicas del desarrollo de software
tenemos el modelo de prototipos, un modelo con bastante rendimiento.
Valderrama (1997)12, nos detalla un poco sobre el origen y el concepto del
modelo de prototipos:
En el resto de los modelos clsicos, por una parte, los errores de anlisis
son muy caros y difciles de eliminar ya que son los primeros que se
producen y los ltimos que se detectan (efecto bola de nieve) y por otra
parte, en la prctica, el modelo tiende a deformarse de modo que todo el
peso de la realimentacin cae en su mayor parte en el cdigo.
Frente a este mtodo de desarrollo, se plantea la utilizacin de
prototipos dentro del proceso de construccin del sistema informtico,
entendiendo como tales las primeras versiones de un producto. El
prototipo se emplea para determinar los requerimientos de un sistema,
examinar aspectos tcnicos, simular formatos de pantalla entre otras
cosas. (p. 156).
Es posible apreciar que el objetivo de la creacin de esta metodologa es crear
un diseo que cumpla con los requerimientos iniciales de un sistema que se
adecue lo mximo posible al usuario final.
El mismo Valderrama (1997), clasifica en dos tipos de prototipos el modelo en
el campo de la ingeniera de software:

Los horizontales o experimentales, en los que se han incluido todas

las funciones que lleva a cabo el sistema pero sin estar totalmente
desarrolladas.
Los verticales o exploratorios, en los que no se incorpora todas las
caractersticas del producto final, pero las previstas se han
desarrollado completamente.

Posteriormente Valderrama (1997) hace una descripcin general sobre el

camino que se debe de tomar para poder llegar a lograr aplicar la metodologa
del modelo de prototipos y los pasos que se deben de seguir para que el
desarrollo satisfaga las especificaciones que necesitan ser cubiertas en el
sistema a desarrollar:

12 Valderrama, J. (1997). Informacin Tecnolgica. (1 edicin). Chile: La Serena.

La utilizacin del prototipado se ha incluido dentro del ciclo de vida

clsico como una etapa entre la especificacin y el diseo. Hasta que el
prototipo no est construido y validado por el usuario no se pasa al
diseo del producto final. En este modelo el prototipo se desecha,
construyndose la aplicacin a partir de experiencias obtenidas.
Sin embargo, las lneas de investigacin actuales proponen emplear el
prototipado dentro del paradigma de la programacin automtica. En
este modelo la especificacin de requerimientos se realiza de un modo
formal, convirtindose en el prototipo. El desarrollo del producto final
surge de la evolucin del prototipo a partir de las especificaciones que se
van aadiendo. En realidad lo que se est haciendo es realizar en
paralelo el anlisis, diseo e implementacin del producto. La generacin
automtica de cdigo a partir de la especificacin formal, permite
obtener una ejecucin de cada versin del prototipo. (p. 156).
Otro punto de vista sobre este tipo de metodologa la podemos tomar de
Martnez (2011)13, quien lo describe de la siguiente manera:
Este modelo arranca con el establecimiento de los requerimientos del
sistema, se definen los objetivos del sistema y los requisitos conocidos
con base en las reas de mayor prioridad e importancia para el sistema.
Luego se hace un diseo preliminar sobre el cual se construye un
prototipo, compuesto a menudo de ventanas, tablas de la base de datos,
formatos de entrada y de salida clsicos. Este prototipo se ajusta lo
mejor que se pueda a la solucin requerida por el usuario y sobre l se
terminan de establecer los dems requerimientos del sistema.
Si el prototipo, es una versin construida sobre un buen conjunto de
requerimientos, slido y real y satisface en buena proporcin las
necesidades del usuario, en materia de datos y de ventanas, podra
servir como un prototipo de trabajo, aquel sobre el cual se empieza a
construir el sistema definitivo, pero la mayora de las veces este primer
prototipo debe desecharse. (p. 47).
Se hace an ms evidente que el diseo del modelo en esta metodologa es
ampliamente dominado por los requerimientos del sistema, verificando los
objetivos y requisitos que este quiere alcanzar siendo el pilar fundamental del
desarrollo del mismo.
A su vez, Martnez nos indica puntualmente dos crticas altamente
considerables sobre este tipo de modelo:

Falta de calidad en el prototipo inicial, el usuario se hace a la idea de un

gran avance en el desarrollo de su sistema y a veces los analistas se
comprometen a arreglar un prototipo que deberan desechar.

13 Martnez, S. (2011). Metodologa de implementacin de ERP. (1 edicin). Espaa: Pyme.

La tcnica es buena si se establecen las reglas de juego desde el

comienzo, es de vital importancia que los usuarios especialmente los
gerentes entiendan y calculen el tamao del proyecto, sus fases, la
metodologa y los tiempos. (p. 47).

Caractersticas

Plantea la utilizacin de prototipos dentro del proceso de construccin

del sistema informtico, entendiendo como tales las primeras
versiones de un producto.
El prototipo se emplea para determinar los requerimientos de un
sistema, examinar aspectos tcnicos, simular formatos de pantalla
entre otras cosas.
Se hace un diseo preliminar sobre el cual se construye un prototipo,
compuesto a menudo de ventanas, tablas de la base de datos,
formatos de entrada y de salida clsicos.
Clasifica en dos tipos de prototipos el modelo en el campo de la
ingeniera de software: Los horizontales o experimentales y los
verticales o exploratorios.
El prototipado se emplea dentro del paradigma de la programacin
automtica.
El modelo en esta metodologa es ampliamente dominado por los
requerimientos del sistema.
En realidad, lo que se est haciendo es realizar en paralelo el anlisis,
diseo e implementacin del producto.

Desarrollo basado en componentes

Somerville (2005)14 menciona que en la mayora de los proyectos de software
existe algo de reutilizacin de software. Esto suele suceder de manera informal
cuando se requieren diseos o cdigo similares al requerido. Entonces se
buscan esos cdigos que ya se tienen, se modifican segn lo necesario y los
incorporan en el sistema. Actualmente se utiliza de manera muy amplia.
Este enfoque est basado en la reutilizacin se compone de una gran base de
componentes software reutilizables y de algunos marcos de trabajo de
integracin para estos. Algunas veces estos componentes son sistemas por si
mismos que se pueden utilizar para proporcionar una funcionalidad especfica,
como dar formato al texto o efectuar clculos numricos.
La etapa de especificacin de requerimientos y la de validacin son
comparables con otros procesos, las etapas intermedias en el proceso
orientado a la reutilizacin con diferentes, estas etapas son:

14

Somerville, I. (2005). Ingeniera del Software (Sptima ed.). Madrid, Espaa: Pearson Educacin.

1. Anlisis de componentes: Dada la especificacin de requerimientos,

se buscan los componentes para implementar esta especificacin. Por lo
general, no existe una concordancia exacta y los componentes que se
utilizan slo proporcionan parte de la funcionalidad requerida.
2. Modificacin de requerimientos: En esta etapa, los requerimientos se
analizan utilizando informacin acerca de los componentes que se han
descubierto. Entonces, estos componentes se modifican para reflejar los
componentes disponibles. Si las modificaciones no son posibles, la
actividad de anlisis de componentes se puede llevar a cabo
nuevamente para buscar soluciones alternativas.
3. Diseo del sistema con reutilizacin: En esta fase se disea o se
reutiliza un marco de trabajo para el sistema. Los diseadores tienen en
cuenta los componentes que se reutilizan y organizan el marco de
trabajo para que los satisfaga. Si los componentes reutilizables no estn
disponibles, se puede tener que disear nuevo software.
4. Desarrollo e integracin: Para crear el sistema, el software que no se
puede adquirir externamente se desarrolla, y los componentes y los
sistemas COTS se integran. En este modelo, la integracin de sistemas
es parte del proceso de desarrollo, ms que una actividad separada.

Somerville menciona que tiene la ventaja obvia de reducir la cantidad de

software a desarrollarse y as reduce los costos y los riesgos. Por lo general,
tambin permite una entrega ms rpida del software. Sin embargo, los
compromisos en los requerimientos son inevitables, y esto puede dar lugar a
un sistema que no cumpla las necesidades reales de los usuarios.
Si las nuevas versiones de los componentes reutilizables no estn bajo el
control de la organizacin que los utiliza, se pierde parte del control sobre la
evolucin del sistema.
De igual manera Pressman (2002)15 nos brinda una idea muy parecida a lo que
anteriormente nos mencion Somerville, l dice que se trata de un proceso que
se centra en el diseo y construccin de sistemas basados en computadora
que utilizan componentes de software reutilizables.

15 Pressman, R. S. (2002). Ingeniera del software. Un enfoque prctico. (Quinta ed.). Madrid, Espaa:
McGraw Hill.

Lo que busca el desarrollo basado en componentes es que el sistema no tenga

que construirse a partir de piezas por separado.
Aunque la existencia de componentes reutilizables no garantiza que estos
componentes puedan integrarse fcilmente, o de forma eficaz, en la
arquitectura elegida para una aplicacin nueva. Esta es la razn por la que se
aplica una sucesin de actividades de desarrollo basada en componentes
cuando se ha propuesto que se utilice un componente.

El paradigma de ensamblar componentes y escribir cdigo para hacer que

estos componentes funcionen se conoce como Desarrollo de Software Basado
en Componentes. El optar por comprar componentes de terceros en lugar de
desarrollarlos, posee algunas ventajas:
1. Ciclos de desarrollo ms cortos. La adicin de una pieza dada de
funcionalidad tomar das en lugar de meses o aos.
2. Mejor ROI. Usando correctamente esta estrategia, el retorno sobre la
inversin puede ser ms favorable que desarrollando los componentes
uno mismo.
3. Funcionalidad mejorada. Para usar un componente que contenga una
pieza de funcionalidad, solo se necesita entender su naturaleza, ms no
sus detalles internos. As, una funcionalidad que sera imprctica de
implementar en la empresa, se vuelve ahora completamente
asequible.16

Caractersticas
Est basado en la reutilizacin de Software.
Se compone de una gran base de componentes software reutilizables y

de algunos marcos de trabajo de integracin para estos.

Dada la especificacin de requerimientos, se buscan los componentes
para implementar esta especificacin.
No existe una concordancia exacta y los componentes que se utilizan
slo proporcionan parte de la funcionalidad requerida.

16 Terreros, J. C. (s.f.). Microsoft: Developer Network. Obtenido de Microsoft: https://msdn.microsoft.com/eses/library/bb972268.aspx

Reduce la cantidad de software a desarrollar y as reduce los costos y los

riesgos.
Permite una entrega ms rpida del software.
Puede dar lugar a un sistema que no cumpla las necesidades reales de
los usuarios.

Otras Metodologas
Modelo Ganar-Ganar
Tando Wetzenfield17, como Barry, W. Boehm18 (principal creador del modelo),
citado en por Selby nos indica que el modelo ganar-ganar (win-win) extiende
el modelo espiral La cuestin extendida es que, segn nos comenta Alfredo,
se hace nfasis en la identificacin de las condiciones de ganancia para todas
las partes, creando un plan para alcanzar las condiciones ganadoras y los
riesgos correspondientes. Se establecen las reglas para definir el proceso de
desarrollo del proyecto, tomando en cuenta todas las partes implicadas. El
modelo no necesita mucho tiempo de gestin, lo que permite utilizarlo tanto en
proyectos pequeos, como mayores.
Esto es parecido a lo que Boehm indica cuando dice: El modelo Ganar-Ganar
utiliza el enfoque de la Teora W (Win-Win) para converger en un nivel superior
de los objetivos, restricciones y alternativas del sistema. El enfoque de la teora

17 Weitzenfeld, A. (2005). Ingeniera de software orientada a objetos con UML, Java e Internet. D.F., Mxico:
Thomson. Pg.54.

18 Selby, R. (2007). Software Engineering: Barry W. Boehm's Lifetime Contributions to Software. USA. University
of Southern California. Pg. 375

W implica indentificar los stakeholders del sistema y sus condiciones de

ganancia, y el uso de procesos de negociacin para determinar un conjunto de
objetivos, restricciones y alternativas mutuamente satisfactorios.
Al ser una extensin del modelo espiral, se sigue trabajando en base a ciclo, sin
embargo, las actividades en cada ciclo, cambian. De esta Alfredo nos dice que
se consideran cuatro ciclos, compuestos cada uno de cuatro actividades, las
cuales procede a detallar:
1. Elaborar los objetivos, restricciones y alternativas del proceso y producto
del sistema y subsistema.
2. Evaluar las alternativas con respecto a los objetivos y restricciones.
Identificar y resolver las fuentes principales de riesgo en el proceso y el
producto.
3. Elaborar la definicin del producto y proceso.
4. Planear el siguiente ciclo y actualizar el plan de su ciclo de vida,
incluyendo la particin del sistema en subsistemas para ser
considerados en ciclos paralelos. Esto puede incluir un plan para
terminar el proyecto si es muy riesgoso o no es factible. Asegurar el
compromiso de la administracin para continuar segn lo planeado.

Una vez revisadas las actividades, los ciclos definen lneas especficas a seguir:
Ciclo 0. Grupos de aplicacin. Se determina la viabilidad de un grupo apropiado
de aplicaciones.
Ciclo 1. Objetivos del ciclo de vida de la aplicacin. Se desarrollan los objetivos
del ciclo de vida, incluyendo prototipos, planes y especificaciones de
aplicaciones individuales, y se verifica la existencia de al menos una
arquitectura viable para cada aplicacin.
Ciclo 2. Arquitectura del ciclo de vida de la aplicacin. Se establece una
arquitectura del ciclo de vida detallado, se verifica la viabilidad y determina
que no existen riesgos mayores en stisfacer los planes y especificaciones.
Ciclo 3. Capacidad de operacin incial. Alcanzar una capacidad operacional
inicial para cada etapa crtica del proyecto en el clcilo de vida del software.
Si bien lo que ha de hacerse en cada ciclo, vemos que se enfoca sobretodo a
incluir las necesidades y oportunidades del cliente o todos los involucrados
(stakeholders), cada uno de los ciclos sigue manteniendo una gran similitud
con los que se trabaja dentro del proceso en Espiral.
Posteriormente nos menciona algunas de las que considera son las creencias
de este modelo, en las cuales se fundamenta.

Crear software basado en componentes para incrementar la calidad en

los sistemas de mayor tamao.

Escribir software reutilizable para hacer eficiente el proceso de

desarrollo.
Medir la calidad del sistema como aspecto clave del desarrollo del
producto.
Lograr mayor calidad en el proceso de ensamblaje a partir de
componentes menores.
Usar tecnologas basadas en objetivos como aspecto bsico para lograr
la calidad.
Producir sistemas rpidamente, sencillos, confiables y de calidad,
empleando procesos bien definidos.
Utilizar el modelo de espiral como base del proceso.
Flexibilizar el proceso de creacin del software para lograr los objetivos
generales de eficiencia.
Involucrar al cliente mediante el manejo de prototipos.
Analizar los riesgos en el proceso del desarrollo del software para
asegurar la calidad final del sistema.

Caractersticas

Extiende el modelo espiral, por lo que se sigue trabajando en base a

ciclo.
Hace nfasis en la identificacin de las condiciones de ganancia para
todas las partes, creando un plan para alcanzar las condiciones
ganadoras y los riesgos correspondientes.
Utiliza el enfoque de la Teora W (Win-Win) para converger en un nivel
superior de los objetivos, restricciones y alternativas del sistema.
Establece las reglas para definir el proceso de desarrollo del proyecto,
tomando en cuenta todas las partes implicadas.
El modelo no necesita mucho tiempo de gestin, lo que permite
utilizarlo tanto en proyectos pequeos.
Se enfoca sobretodo a incluir las necesidades y oportunidades del
cliente o todos los involucrados (stakeholders).
Usa tecnologas basadas en objetivos como aspecto bsico para
lograr la calidad.

Proceso Unificado (UP)

Revisando lo que nos aporta Weizenfield19 con respecto a esto, nos dice que se
trata de una extensin al proceso objectory (object factory) que tiene sus
orgenes en la dcada de 1980. La principal caracterstica que destaca y en la
que coincide con Ivar Jacobson, Grady Booch y James Rumbaugh 20 es que estos
modelos de proceso se basan principalmente en la especificacin de

19 Weitzenfeld, A. (2005). Ingeniera de software orientada a objetos con

UML, Java e Internet. D.F., Mxico: Thomson. Pg.56.

requerimientos de un sistema mediante casos de uso. El proceso unificado

tiene como aspecto esencial del desarrollo de software una visin que parte de
la arquitectura del sistema, siguiendo un proceso iterativo e incremental.
Posteriormente Pressman21 nos explica detalladamente en que consiste el
Proceso Unificado, pues nos comenta que consta de 5 fases importantes, las
cuales se muestran a continuacin.
1. La fase de inicio.
Abarca la comunicacin con el cliente y las actividades de planeacin. Se
identifican los requisitos de negocios para el software y se desarrolla un plan
para la naturaleza iterativa e incremental del sistema subsiguiente. Los
requisitos se describen a travs de un conjunto de casos de uso que describen
cules caractersticas y funciones son deseables para cada clase importante de
usuarios. La planeacin identifica recursos, evala los riesgos importantes,
define un itinerario y establece una base para las fases que se aplicarn
conforme se desarrolle el incremento del software.
2. La fase de elaboracin.
Abarca la comunicacin con el cliente y las actividades de modelado del
proceso. La elaboracin refina y expande los casos de uso preliminares que se
desarrollaron como parte de una fase de inicio; adems, expande la
representacin arquitectnica del software para incluir cinco versiones
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. El
plan se revisa de manera cuidadosa al trmino de la fase de elaboracin para
asegurar que el mbito, los riesgos y los datos entregados an son razonables.
Las modificaciones al plan se deben hacer en este momento.
3. La fase de construccin.
Desarrolla o adquiere los componentes de 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 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. Los casos de uso se
utilizan para derivar un conjunto de pruebas de aceptacin que se ejecutan
antes del inicio de la siguiente fase del PU.

20 Jacobson, I., Booch, G & J.Rumbaugh. (1999). The Unified Software

Development Process. USA. Addison-Wesley
21

Pressman, R. S. (2002). Ingeniera del software. Un enfoque prctico. (Quinta ed.). Madrid, Espaa:

McGraw Hill. Pg. 68

4. La fase de transicin.
Abarca las ltimas etapas de la actividad de construccin y la primera parte de
la actividad 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. El equipo de software crea la informacin de soporte
necesaria (manuales de usuario, guias de resolucin de problemas, etc.) para
el lanzamiento.
5. La fase de produccin.
Coincide con la actividad de despliegue del modelo en cascada. Durante esta
fase se monitorea el uso subsiguiente del software, se proporciona el soporte
para el ambiente operativo y se reciben y evalan los informes de defectos y
los requerimientos de cambios.

Para finalizar su comprensin, Weitzenfeld nos indica las que considera, son las
creencias en las que se basa este proceso.
Para construir un sistema exitoso se debe conocer qu quieren y necesitan
los usuarios potenciales.
Al igual que la arquitectura en la construccin, permite disear edificios
desde mltiples puntos de vista, estructura, electricidad, etc. Las arquitecturas
de los sistemas de software deben permitir visualizar un sistema desde
mltiples perspectivas.
El desarrollo de un producto de software comercial puede significar un gran
esfuerzo durante meses, e incluso aos. Es prctico dividir el trabajo en etapas,
donde cada iteracin resulta en un incremento del proyecto.

Caractersticas

Estos modelos de proceso se basan principalmente en la

especificacin de requerimientos de un sistema mediante casos de
uso.

Se compone de 5 fases: inicio, elaboracin, construccin, transicin y

produccin
Los requisitos se describen a travs de un conjunto de casos de uso
que describen cules caractersticas y funciones son deseables.
Trabaja bajo un esquema o paradigma orientado a objetos.
Sigue un proceso iterativo e incremental.
Su divisin en etapas facilita la entrega del proyecto.
Para que el sistema sea exitoso, se debe conocer que quieren y
necesitan los usuarios potenciales, para lo cual se aprovecha la
generacin de los casos de uso ya mencionados.

Ingeniera Web
Galindo22 lo define como la especializacin de la IS para el caso del desarrollo
basado en tecnologas web. Este autor afirma que la ingeniera web no es un
nuevo paradigma o un nuevo tipo de ingeniera, sino que los mtodos de
desarrollo web toman las tcnicas de la IS ms tiles para el caso concreto del
software web.
La explicacin y planteamiento anterior, coincide plenamente con la que
Pressman23 desarrolla cuando nos dice que la ingeniera Web (IWeb) aplica
slidos principios cientficos, de ingeniera y de administracin, y enfoques
disciplinados y sistemticos para el desarrollo, despliegue y mantenimiento
exitosos de sistemas y aplicaciones basados en Web de alta calidad
Segn nos indica Pressman los modelos de procesos IWeb adoptan la filosofa
del desarrollo gil. El desarrollo gil enfatiza un enfoque de desarrollo riguroso
que incorpora rpidos ciclos de desarrollo. La razn por la cual es importante el
desarrollo gil es decrita por Aoyama en la siguiente forma:
Internet cambi la prioridad principal del desarrollo de software de qu a
cundo. El reducido tiempo para el mercado se ha convertido en el lmite
competitivo por el que luchan las compaas lderes. En consecuencia, reducir
el ciclo de desarrollo es ahora una de las misiones ms importantes de la
ingeniera de software
Si la inmediatez y la evolucin continua son atributos principales de la WebApp,
un equipo de ingeniera Web debe elegir un modelo de proceso gil que
produzca liberaciones de WebApp a un ritmo vertiginoso. Por otra parte, si una
WebApp ser desarrollada durante un largo periodo (por ejemplo, una gran

22 Galindo, M. (2010). Escaneando la informtica. Barcelona, Espaa: UOC. Pg.

189-190
23 Pressman, R. S. (2002). Ingeniera del software. Un enfoque prctico. (Quinta ed.). Madrid, Espaa:
McGraw Hill. Pg. 503

aplicacin de comercio electrnico) puede elegirse un modelo de proceso

incremental
Cualesquiera de los modelos de proceso gil se pueden aplicar de manera
exitosa como un proceso IWeb. Sin embargo la efectividad de cualquier proceso
de ingeniera va a depender de su adaptabilidad. Esto es, la organizacin del
equipo de proyecto, los modos de comunicacin entre miembros del equipo, las
actividades de ingeniera y las tareas que deben realizarse, la informacin que
se recolecte y cree, y los mtodos empleados para producir un producto de alta
calidad deben estar adaptados a la gente que realiza el trabajo, el plazo y las
restricciones del proyecto, y al problema que se quiere resolver.
Pressman nos indica que antes de definir un marco de trabajo de proceso para
IWeb se debe reconocer que:
1. Las WebApps con frecuencia se entregan de manera incremental. Esto
es, las actividades ocurrirn de manera repetida conforme cada
incremento se someta a ingeniera y se entregue.
2. Los cambios ocurrirn frecuentemente. Ya sea como resultado de la
evaluacin de un incremento entregado o como consecuencia de
cambiar las condiciones de los negocios.
3. Los plazos son cortos. Esto aminora la creacin y revisin de voluminosa
documentacin de ingeniera, pero no excluye la simple realidad de que
el anlisis crtico, el diseo y la prueba deben registrarse en alguna
forma.
El funcionamiento en que se lleva a cabo este mtodo queda representado en
el siguiente diagrama.

Caractersticas

Toma las tcnicas de la ingeniera de software ms tiles para los

casos concretos del software web.
Adopta la filosofa del desarrollo gil permitiendo desarrollar software
de aplicacin enfatizado a la web de una manera ms rpida.

Enfatiza un enfoque de desarrollo riguroso que incorpora rpidos

ciclos de desarrollo.
Si la inmediatez y la evolucin continua son atributos principales de
la WebApp, un equipo de ingeniera Web debe elegir un modelo de
proceso gil que produzca liberaciones de WebApp a un ritmo
vertiginoso
Si una WebApp ser desarrollada durante un largo periodo (por
ejemplo, una gran aplicacin de comercio electrnico) puede elegirse
un modelo de proceso incremental
Los cambios ocurrirn frecuentemente. Ya sea como resultado de la
evaluacin de un incremento entregado o como consecuencia de
cambiar las condiciones de los negocios.
Los plazos que se han de considerar dentro de esta metodologa son
cortos.

Metodologas giles
Este tipo de metodologas se crean y disean para producir rpidamente un
software til. Este no se desarrolla como una sola unidad, sino como una serie
de incrementos, y cada uno de ellos incluye una nueva funcionalidad del
sistema. Pese a que existen muchos enfoques para el desarrollo gil (que se
desglosarn ms adelante), comparten algunas caractersticas
fundamentales24.
1. Los procesos de especificacin, diseo e implementacin estn
entrelazados. No existe una especificacin detallada del sistema, y la
documentacin del diseo se minimiza o es generada automticamente
por el entorno de programacin que se usa para implementar el sistema.
El documento de requerimientos del usuario define slo las
caractersticas ms importantes del sistema.
2. El sistema se desarrolla en diferentes versiones. Los usuarios finales y
los otros colaboradores del sistema intervienen en la especificacin y
evaluacin de cada versin. Ellos podrn proponer cambios al software y
nuevos requerimientos que se implementen en una versin posterior al
sistema.
3. Las interfaces de usuario del sistema se desarrollan usando con
frecuencia un sistema de elaboracin interactivo, que permita que el
diseo de la interfaz se cree rpidamente en cuanto se dibujan y colocan
conos de la interfaz. En tal situacin, el sistema puede generar una
interfaz basada en la web para un navegador o plataforma especfica.

24 Ian Somerville. Ingeniera de Software (9na Edicin) Pearson Education.

Mxico D.F. 2011.

Esta metodologa que se basa en valores, principios y prcticas bsicas. Los

cuatro valores son comunicacin, simpleza, retroalimentacin y valenta.
Kendall & Kendall definen las metodologas giles en 5 etapas:

Exploracin: Durante esta, se explorar el entorno para evaluar su

conviccin de que puede y debe lidiar con el problema mediante el
desarrollo gil, se crear el equipo y se evaluarn las habilidades de sus
miembros. Puede requerir desde algunas semanas, hasta algunos
meses, dependiendo de lo que conozca o no del equipo, y de la
tecnologa a utilizar. En esta etapa se practica con la estimacin del
tiempo necesario para realizar varias tareas, adems de que los clientes
tambin experimentan escribiendo historias de los usuarios, para que se
haga con el detalle suficiente como para que se pueda estimar de
manera competente la cantidad de tiempo para crear soluciones y
convertirla en un sistema.
Planeacin: Solamente requerir unos cuantos das. Se fijan fechas para
entregar soluciones a problemas empresariales ms estresantes. Si la
exploracin fue un xito, esta etapa debe de ser muy corta.
Iteraciones para la liberacin de la primera versin. Por lo general, estas
son iteraciones (ciclos de prueba, retroalimentacin y modificacin) de
aproximadamente tres semanas. Se enfocar en bosquejar toda la
arquitectura del sistema, aun y cuando slo est en forma de bosquejo o
esqueleto. Uno de los objetivos es realizar pruebas funcionales escritas
por el cliente a final de cada iteracin.
Puesta en Produccin. El ciclo de retroalimentacin se agiliza de manera
que en vez de recibir retroalimentacin por una iteracin cada tres
semanas, las revisiones de software se entregan en una semana. Se
pueden realizar sesiones informativas diarias para que todos sepan en lo
que se est elaborando. El producto se libera en esta fase.
Mantenimiento. Una vez liberad el sistema, si se pueden agregar
caractersticas, sugerencias del cliente, entre otras cosas, para ponerlos
en el sistema25.

Asimismo, este tipo de metodologas se rigen bajo 5 principios:

Participacin del cliente. Los clientes deben de intervenir estrechamente

durante el proceso de desarrollo.
Entrega Incremental. El software se desarrolla en incrementos y el
cliente especifica los requerimientos que se van a incluir en cada
incremento.
Personas, no procesos. Tiene que reconocerse y aprovecharse las
habilidades del equipo de desarrollo. Debe permitirse a los miembros del
equipo desarrollar sus propias formas de trabajar sin procesos
establecidos.

25 Kendall & Kendall. Anlisis y diseo de Sistemas. (8va Edicin). Prentice Hall. Mxico D.F. 2011.

Adoptar el cambio. Esperar a que cambien los requerimientos del

sistema y, de este modo, disear el sistema para adaptar esos cambios.
Mantener simplicidad. Enfocarse en la simplicidad tanto en el software a
desarrollar como en el proceso de desarrollo. 26

El enfoque ms utilizado del proceso gil es el de la programacin extrema

(XP). Dentro de este, Beck define un conjunto de cinco valores que establecen
el fundamento para todo trabajo realizado como parte de XP: comunicacin,
simplicidad, retroalimentacin, valenta y respeto. Todo esto utilizado como
motor para actividades, acciones, tareas especficas de XP. La comunicacin
eficaz requiere de colaboracin estrecha pero informal (verbal) entre clientes y
desarrolladores. Para alcanzar la simplicidad, XP exige a desarrolladores
disear slo las necesidades inmediatas, en lugar de considerar las del futuro.
El objetivo es crear un diseo sencillo que se implemente con facilidad en
forma de cdigo. La retroalimentacin se obtiene de tres fuentes: software
implementado, el cliente y otros miembros del equipo de software. XP usa la
prueba unitaria para ejecutar cada operacin de acuerdo con su funcionalidad
especfica.27
El proceso de XP usa un enfoque orientado a objetos. Su esquema es el
siguiente:

En la planeacin se recaban requerimientos que permite que los miembros

tcnicos del equipo entiendan el contexto del negocio para el software y
adquieran la sensibilidad de la salida y caractersticas principales y
funcionalidad que se requieren. Se crean historias del usuario que describen
la salida necesaria, funcionalidad y caractersticas del software a elaborar.
26 Ian Somerville. Ingeniera de Software (9na Edicin) Pearson Education. Mxico D.F. 2011.

27 Roger Pressman. Ingeniera de Software, Un enfoque Prctico. (7ma Edicin) Mc Graw Hill. Mxico
D.F. 2010

Dentro del diseo se sigue la regla de Mantenlo Sencillo. Siempre se prefiere

sobre una representacin ms compleja. Adems, gua a la implementacin de
una historia conforme se escribe: nada ms y nada menos. Se estimula el uso
de las tarjetas CRC, que identifican y organizan las clases orientadas a objetos
que son relevantes para el incremento actual de software. Estas son el nico
producto que se genera como parte del proceso XP. Si en el diseo de la
historia se muestra un problema de diseo difcil se recomienda la creacin
inmediata de un prototipo operativo de esa porcin del diseo. Entonces se
implementa y evala, llamado solucin en punta.
Antes de la codificacin, se desarrollan pruebas unitarias a cada historia que se
incluirn en la entrega en curso. Para despus empezar a programar. Un
concepto clave es la programacin en parejas. Se recomienda que dos
personas trabajen juntas en una estacin de trabajo con el objetivo de crear
cdigo para una historia, para as concentrarse slo en su historia y que el
desarrollo se haga de buena manera.
En las pruebas se hacen las pruebas unitarias para examinar el cdigo. A
medida que se organizan las pruebas individuales, las pruebas de integracin y
validacin del sistema pueden efectuarse diario, lo cual da al equipo una
indicacin continua del avance lanza seales de alerta si las cosas marchan
mal. Las pruebas de aceptacin XP, tambin llamadas pruebas del cliente, son
especificadas por el cliente y se centran en caractersticas generales del
sistema que son visibles y revisables por el cliente. 28
Otros modelos giles propuestos, pero menos usados son:
Desarrollo adaptativo de software (DAS)
Scrum
Mtodo de desarrollo de sistemas dinmicos (MDSD)
Cristal
Desarrollo impulsado por las caractersticas (DIC)
Desarrollo esbelto de software (DES)
Modelado gil (MA)
Proceso unificado gil (PUA)

Caractersticas

Se utilizan principalmente para producir rpidamente un software til.

No se desarrolla como una sola unidad, sino como una serie de
incrementos, que cada uno incluye una nueva funcionalidad del sistema.
Los procesos de especificacin, diseo e implementacin estn
entrelazados. No existe una especificacin detallada del sistema, y la

28 Roger Pressman. Ingeniera de Software, Un enfoque Prctico. (7ma

Edicin) Mc Graw Hill. Mxico D.F. 2010

documentacin del diseo se minimiza o es generada automticamente por

el entorno de programacin que se usa para implementar el sistema.
El documento de requerimientos del usuario define slo las caractersticas
ms importantes del sistema.
El sistema se desarrolla en diferentes versiones. Los usuarios finales y los
otros colaboradores del sistema intervienen en la especificacin y
evaluacin de cada versin. Ellos podrn proponer cambios al software y
nuevos requerimientos que se implementen en una versin posterior al
sistema.
Las interfaces de usuario del sistema se desarrollan usando con frecuencia
un sistema de elaboracin interactivo, que permita que el diseo de la
interfaz se cree rpidamente en cuanto se dibujan y colocan conos de la
interfaz. En tal situacin, el sistema puede generar una interfaz basada en
la web para un navegador o plataforma especfica.

Metodologa Emergente
Una metodologa es emergente si permite adaptar la forma de trabajo a las
condiciones del proyecto.
Tipos de sistemas
Se utiliza mayoritariamente en desarrollo de productos con innovaciones
importantes, y para sistemas de informacin empresarial.
Algunas de estas metodologas son:
ICONIX
Se define como un proceso de desarrollo de software prctico. Est entre la
complejidad de RUP y la simplicidad y pragmatismo de XP, sin eliminar las
tareas de anlisis y diseo que XP no contempla.

Es un proceso simplificado que unifica un conjunto de mtodos de orientacin

objetos con el objetivo de abarcar todo el ciclo de vida de un proyecto. Las tres
caractersticas fundamentales de ICONIX son:

Iterativo e incremental.
Trazabilidad
Dinmica del UML

Las tareas que se realizan en la metodologa ICONIX son:

Anlisis de requisitos
Anlisis y diseo preliminar
Diseo
Implementacin

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. 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.
FDD
Es un proceso diseador por Peter Coad, Erick Lefebvre y Jeff De Luca y se
podra considerar a medio camino entre RUP y XP, aunque al seguir siendo un
proceso ligero es ms similar a este ltimo. FDD est pensado para proyectos
con tiempo de desarrollo relativamente cortos (menos de un ao). Se basa en
un proceso iterativo con iteraciones cortas (2 semanas) que producen un
software funcional que el cliente y la direccin de la empresa pueden ver y
monitorizar. Un proyecto que sigue FDD se divide en 5 fases:
1.
2.
3.
4.
5.

Desarrollo de un modelo general.

Construccin de la lista de funcionalidades.
Plan de releases en base a las funcionalidades a implementar.
Disear en base a las funcionalidades.
Implementar en base a las funcionalidades.

Adaptative Software Development (ASD):

Este proceso consiste en un cambio de filosofa en las organizaciones pasando
de la transicin del modelo Comando-Control al modelo liderazgo-Colaboracin.
Lleva los conceptos de los Sistemas Adaptativos Complejos al campo de la
ingeniera de software en particular. Dada la complejidad inherente al software
concluye que la aplicacin de esta teora es esencial para el nuevo escenario
que plantea la economa global.

El ciclo de vida de ASD propone tres fases esenciales:

Especulacin
Colaboracin
Aprendizaje29

Caractersticas

Permite adaptar la forma de trabajo a las condiciones del proyecto.

Se utiliza mayoritariamente en desarrollo de productos con innovaciones
importantes, y para sistemas de informacin empresarial
Algunas de las metodologas ms representativas: ICONIX, CRYSTAL
METHODOLOGIES, FDD, ASD
Incertidumbre: la direccin indica la necesidad estratgica que se desea
cubrir, ofreciendo mxima libertad al equipo de trabajo.
Difusin y transparencia del conocimiento: alta rotacin de los miembros
de los equipos entre diferentes proyectos. Por otra parte, potenciar el
acceso libre a la informacin y documentacin.

Reingeniera
La reingeniera de software abarca el problema de reconstruccin de un
sistema cuando este ha sido modificado y adaptado tantas veces (y sin
apegarse a una metodologa de desarrollo especfica) que se ha vuelto
inestable. Normalmente y segn nos narra Pressman 30 estos sistemas siguen
funcionando, pero poder adaptarlos a las nuevas necesidades que van
surgiendo en la empresa se vuelve una tarea casi imposible.
El modelo de proceso de reingeniera incluye una estrategia operativa, sin
embargo es un proceso asociado a muchos riesgos y que puede generar
mayores costos, pues se tiene a personas y recursos invertidos en un proceso,
que si no es fundamental, representa un desperdicio.

29 Unidad II- Metodologas de desarrollo. (15 de Marzo de 2013). Recuperado

el da 13 de Febrero de 2015 de http://fgaith2.blogspot.mx/
30 Pressman, R. (2002). Ingeniera del Sotware: Un enfoque prctico. (5ta
Edicion) Mc Grawhill. CDMX.

Es por ello que Pressman recomienda considerar varios aspectos.

Antes de que se pueda iniciar la reconstruccin sera razonable

determinar si es necesario reconstruirla.
Antes de reconstruir el sistema, se debe tener la certeza de que la
estructura del mismo es dbil. Si es slida tal vez sea posible
remodelarla sin reconstruirla (a un costo mucho ms bajo y en mucho
menos tiempo).
Antes se debe tener la certeza de que se entiende cmo se construy el
sistema original.
Si se comienza a reconstruir slo se utilizarn las tecnologas ms
modernas y de larga duracin. Esto puede costar ms ahora, pero
ayudar a evitar un mantenimiento costos y tardado ms adelante.

La implementacin de estos principios requiere aplicar un modelo de proceso

de reingeniera del software que define 6 actividades.

Anlisis de inventarios. Las organizaciones de software deberan tener un

inventario de sus aplicaciones. El inventario tal vez no sea ms que un modelo
en una hoja de clculo que contenga informacin que proporcione una
descripcin detallada de las aplicaciones activas. Al ordenar esta informacin
segn su importancia, antigedad y facilidad de mantenimiento aparecen los
candidatos para la reingeniera.
Reestructuracin de documentos. La documentacin dbil es la marca de
muchos sistemas heredados.
1. Crear documentacin consume muchsimo tiempo. Si el sistema
funciona vivir con lo que se tenga. Si un programa que es
relativamente esttico est llegando al final de su vida til, es
improbable que experimente un cambio significativo. djelo ser!
2. La documentacin debe actualizarse, pero se tienen recursos
limitados. Se utilizar un enfoque de documentar cuando se

toque. Tal vez sea innecesario volver a documentar por completo

toda la aplicacin. En cambio, se documentan completamente
aquellas porciones del sistema que en la actualidad experimentan
cambios.
3. El sistema es crucial para el negocio y debe volver a
documentarse por completo. Incluso en este caso un enfoque
inteligente es recortar la documentacin a un mnimo esencial.
Ingeniera inversa. La ingeniera inversa es un proceso de recuperacin de
diseo. Las herramientas de ingeniera inversa obtienen informacin del diseo
de datos, arquitectnico y de procedimientos a partir de un programa
existente.
Reestructuracin de cdigo. El tipo ms comn de reingeniera es la
reestructuracin de cdigo. Llevar a cabo esta actividad requiere analizar el
cdigo fuente empleando una herramienta de reestructuracin. Se indican las
violaciones de las estructuras de programacin estructurada y entonces el
cdigo se reestructura. La documentacin de cdigo interno se actualiza.
Reestructuracin de datos. La arquitectura de datos actual se analiza con
minuciosidad y se definen los modelos de datos necesarios. Se identifican los
objetos de datos y los atributos, y despus se revisa la calidad de las
estructuras de datos existentes.
Cuando la estructura de datos es dbil, los datos se someten a reingeniera.
Puesto que la arquitectura de datos tiene una fuerte influencia sobre la
arquitectura del programa y los algoritmos que lo pueblan, los cambios a los
datos invariablemente resultarn en cambios arquitectnicos o al nivel de
cdigo.
Ingeniera directa. No solo recupera la informacin de diseo a partir del
software existente, sino que tambin utiliza esta informacin para alterar o
reconstruir el sistema existente con la finalidad de mejorar su calidad global.
En la mayora de los casos el software sometido a reingeniera vuelve a
implementar la funcin del sistema existente y tambin aade nuevas
funciones o mejora el desempeo global.

Caractersticas
Se encarga del problema de reconstruccin de un sistema cuando este

ha sido modificado y adaptado tantas veces que se ha vuelto inestable

Requiere tiempo, cuesta cantidades significativas de dinero y absorbe
recursos que de otro modo se ocuparan en problemas inmediatos.
Se compone de 6 actividades: Anlisis de inventarios, Reestructuracin
de Documentos, Ingeniera directa, Reestructuracin de datos,
Reestructuracin de cdigo, Ingeniera Inversa.
El proceso est planteado para ser lineal, sin embargo, pudiera ser
necesario repetir una o ms veces el mismo si no est claro.
Se caracteriza como una metodologa cclica.

Se debe evitar en la medida de lo posible, a no ser que el sistema sea

fundamental.
La documentacin se puede omitir dependiendo de la relevancia y
complejidad del software.

Herramientas de Comparacin
Es
incremental
Es evolutivo
Es iterativo

Es una
metodologa
clsica

Cascada

Increment
al

Evolutivo

Espiral

Prototipos

Basado en
Componentes

Ganar-ganar

Uni

No

Si

Si

Si

No

No

Si

Si

No
No

No
Si

Si
Si

Si
Si

Si
No

No
No

Si
Si

No
Si

Si

Si

Si

Si

Si

Si

No

No

Etapas de
las que se
compone

*Anlisis y
definicin de
requerimient
os
*Diseo del
sistema y
del software
*Implementa
cin y
prueba de
unidad.
*Integracin
y prueba del
sistema.
*Operacin y
mantenimie
nto

*Definir
esbozo de
requerimien
tos
*Asignar
requerimien
tos a los
incremento
s
*Disear la
arquitectur
a del
sistema
*Desarrollar
los
incremento
s del
sistema

*Esbozo de
la
descripcin
*Especificac
in
Generacin
de la
versin
inicial
*Desarrollo
Generacin
de las
versiones
intermedias

*Establecimie
nto de
objetivos
*Valoracin y
reduccin del
riesgo:
*Desarrollo y
Validacin

*Generacin
de prototipo
inicial.
*Validacin
*Generacin
del
prototipo
final.

*Planeacin

*Anlisis de
componentes
*Modificacin
de
requerimiento
s
*Diseo del
sistema con
reutilizacin
Desarrollo e
integracin

*Validacin
Generacin
de la
versin final

*Validar
Sistema

*No existe
gran
posibilidad
de
someterles a
cambios
durante el
desarrollo
del sistema.

*Cuando se
tiene una
fecha de
entrega
que es
imposible
de cambiar.
*Cuando la
dotacin de
personal no
est
disponible
para una
implementa
cin
completa
en la fecha
especificad
a.

*Cuando las
necesidades
de los
clientes
necesitan
ser
satisfechas
rpidament
e.

*La
inic

* La
de
elab
.

*La
con
n.

*La
tran

*La
prod

*Planear el
siguiente
ciclo y
actualizar el
plan de su
ciclo de vida,
incluyendo la
particin del
sistema en
subsistemas
para ser
considerados
en ciclos
paralelos.

*Integrar
los
incremento
s

*Cuando los
requerimient
os se
entienden
bien.

*Evaluar las
alternativas
con respecto
a los
objetivos y
restricciones
*Elaborar la
definicin del
producto y
proceso.

*Validar los
incremento
s

Recomenda
do para

*Elaborar los
objetivos,
restricciones
y alternativas
del proceso y
producto del
sistema y
subsistema.

* Puede
resultar til
para
desarrollar
sistemas de
software a
gran escala.
* Cuanto se
cuenta con las
habilidades
necesarias
para realizar
un anlisis de
costes.

* Cuando no
existe una
necesidad
inmediata,
pues la
metodologa
solo entrega
maquetas al
cliente.

* Cuando se
trata de
software que
no incluye
caracterstica
s novedosas.
* Cuando no
es tan
importante
que el
sistema sea
100% a la
medida.

* Tanto en
proyectos
pequeos
como en
mayores.
* Cuando la
minimizacin
de riesgos o
condiciones
de prdida y
la
maximizacin
de las
oportunidade
s o ganancias
es
fundamental

* De
de s
robu

*Cu
tien
dom
uso
nota
UML
mod

Se basa en

Metodolog
a
Increment
al

Metodologa
Evolutiva

Caracterst
icas ms
relevantes

* Define una
secuencia de
actividades,
donde la
estrategia
principal es
seguir el
progreso del
desarrollo de
software
haca puntos
de revisin
definidos
mediante
entregas
calendarizad
as

*Se centra
en la
entrega de
un producto
opcional
con cada
incremento.

*Se basa en
la idea de
desarrollar
una
implementa
cin inicial,
exponindol
a a los
comentarios
del usuario
y
refinndola
a travs de
las
diferentes
versiones
hasta que
se
desarrolla
un sistema
adecuado.
*El sistema
evoluciona
agregando
nuevos
atributos
propuestos
por el
cliente

*El software se
desarrolla en
una serie de
entregas
evolutivas,
llamadas
prototipos.

*Plantea la
utilizacin
de
prototipos
dentro del
proceso de
construcci
n del
sistema
informtico,
entendiendo
como tales
las primeras
versiones
de un
producto.

*Cada
detalle de
los requisitos
se conoce de
antemano
antes de
desarrollar el
software, y
los detalles
son estables
durante el
desarrollo.

*Cada
incremento
se escribe
sobre aqul
que ya ha
sido
entregado.

*Enfoque
cclico para el
crecimiento
incremental
del grado de
definicin de
un sistema y
su
implementaci
n.

*El prototipo
se emplea
para
determinar
los
requerimien
tos de un
sistema,
examinar
aspectos
tcnicos,
simular
formatos de
pantalla
entre otras
cosas.

Metodologa
Espiral

Met
a O
Fac

Extiende el

*Est
mod
proc
bas
prin
nte
esp
n d
requ
ntos
sist
med
caso
uso

modelo
espiral, por lo
que se sigue
trabajando en
base a ciclo.
Hace nfasis
en la
identificacin
de las
condiciones
de ganancia
para todas
las partes,
creando un
plan para
alcanzar las
condiciones
ganadoras y
los riesgos
correspondie
ntes.

*Sig
proc
itera
incr
l.

Comparacin de ventajas y desventajas

Metodologa
Metodolog
a en
Cascada

Modelo
incremental

Modelo
Evolutivo

Modelo en
Espiral

Modelo de
Prototipos

Ventajas

Es el mtodo ms extendido y utilizado, y, al ser

muy conocido, nos proporciona ventaja ante los
dems.

La documentacin se produce en cada fase, por lo

que de todo lo que se realice, existirn pruebas.

La misma documentacin cuadra con otros

modelos del proceso de ingeniera.

Los clientes no tienen que esperar hasta que el

sistema completo se entregue para sacar
provecho de l ya que el primer incremento
satisface los requerimientos ms crticos del
sistema.

Los clientes pueden utilizar los incrementos

iniciales como prototipos y obtener experiencia
sobre los requerimientos de los incrementos
posteriores al sistema.

Existe un bajo riesgo de un fallo total de proyecto.

Aunque se pueden encontrar problemas en
algunos incrementos, lo normal es que el sistema
se entregue de forma satisfactoria.

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.

Nos permite hacer validaciones de forma

creciente.

Retroalimentacin rpida a lo largo del proceso.

El sistema evolutivo agregando nuevos atributos

de acuerdo a las propuestas del cliente.

Permite valorar aspectos crticos y riesgos del

desarrollo.

Utiliza prototipos, que se van acercando a lo que

el cliente pida.

Es un enfoque realista para el desarrollo de

sistemas y de software a gran escala.

Los prototipos tambin funcionan como

mecanismo de reduccin de riesgos y adems,
permite aplicar el enfoque de hacer prototipos en
todo el ciclo de vida del producto.

Desventajas

Es muy inflexible al dividir el proyecto e

Se deben de hacer compromisos en las

por lo que hace difcil responder a los c
requerimientos del cliente.

Solamente se debe utilizar cuando los r

comprendan bien y sea improbable que
radicalmente durante el desarrollo del s

Los incrementos deben ser relativamen

ms de 20,000 lneas de cdigo) y cada
una funcionalidad del sistema.

Puede ser difcil adaptar los requerimie

incrementos de tamao apropiado.

Muchos de los sistemas requieren un co

que se utilizan en diferentes partes del

Puesto que los requerimientos no se de

hasta que un incremento se implement
identificar los recursos comunes que re
incrementos.

Desarrollo

Mayor productividad y Calidad.

Menor Coste y tamao de programas.
El prototipo es el documento contra el que
comprobar el buen funcionamiento del producto
final.
El prototipo puede verse como un contrato entre
tcnicos y clientes.
Reutilizacin del software. Nos lleva a alcanzar un

El proceso no es visible.
Sistema con estructura deficiente.
Se requieren herramientas y tcnicas e

Es muy difcil convencer a lo futuros us

responsables en el mbito de gestin d
informtico de que este enfoque que ev
sistema final es controlable.
Es necesario contar con habilidades y c
elevados para realizar un correcto anl

Existe una impaciencia en los clientes,

entrega una simple maqueta.
Decisiones de diseo vlidas para el pro
serlo para el producto final.
Si el tiempo invertido en el desarrollo d
elevado, el producto final puede perder

Genera mucho tiempo en el desarrollo d

basado en
component
es

Modelo
GanarGanar

Proceso
Unificado
(UP)

Ingeniera
Web

Metodolog
as giles

mayor nivel de reutilizacin de software.

Simplifica las pruebas. Permite que las pruebas
sean ejecutadas probando cada uno de los
componentes antes de probar el conjunto
completo de componentes ensamblados.
Simplifica el mantenimiento del sistema. Cuando
existe un dbil acoplamiento entre componentes,
el desarrollador es libre de actualizar y/o agregar
componentes segn sea necesario, sin afectar
otras partes del sistema.
Mayor calidad. Dado que un componente puede
ser construido y luego mejorado continuamente
por un experto u organizacin, la calidad de una
aplicacin basada en componentes mejorar con
el paso del tiempo.
Se busca que ambas partes ganen.
No necesita mucho tiempo de gestin.
Minimiza riesgos del proyecto.
Agrega objetivos de calidad.

Es basado en el lenguaje de modelado unificado

por lo cual puede adaptarse a cualquier tipo de
desarrollo.
Utiliza un tipo de proceso iterativo e incremental
que permite una mayor optimizacin en el
desarrollo de software y mayor comodidad a los
programadores.
Sus 5 fases principales ayudan a que la deteccin
de fallas y errores sea ms efectiva.
La fase de produccin permite que se monitoree
de manera continua el uso del software y se
evalen los defectos y requerimientos de cambios.
Adaptabilidad del desarrollo a nuevos requisitos o
nuevos cambios
Se reducen los riesgos de no obtener el producto
deseado
Aplica principios de desarrollo gil que son ms
eficaces que otras metodologas.
Puede combinarse con otras metodologas como
la basada en componentes para reutilizar cdigo.
Divide las tareas de programacin en Arquitectura
Cliente-Servidor

Como su nombre lo dice, solamente se

desarrollo basado en tecnologas web.
Es probable que se presenten muchos c
se elabora el software.
La documentacin que se genera es mu

Apropiado para entornos voltiles

Estar preparados para el cambio, significa
reducir su coste.
Planificacin ms transparente para nuestros
clientes, conocen las fechas de entrega de
funcionalidades. Vital para su negocio
Permitir definir en cada iteracin cuales son los
objetivos de la siguiente
Permite tener realimentacin de los usuarios

Delimitar el alcance del proyecto con n

Modelo costoso.
Requiere experiencia en la identificaci
Genera mucho trabajo adicional.
Cuando un sistema falla se pierde tiem
de la empresa.
Exige una cierta habilidad en los analis
difcil).

Este modelo requiere fuertes habilidade

Tiempo invertido en las negociaciones
Genera mucho tiempo en el desarrollo d
Resulta como un modelo muy costoso.
Requiere de mucha experiencia en la id
riesgos.
El mtodo de proceso unificado requier
dedicacin altos por lo que no es conve
proyectos pequeos.
Si el proceso no se aplica bien desde el
proceso unificado puede volverse muy
Se gasta una gran cantidad de tiempo e
proceso unificado de los proyectos.
Se basa mucho en la documentacin.

muy til.
La presin est a lo largo de todo el proyecto y
no en una entrega final

Metodolog
a
Emergente

Reingenier
a

Las metodologas emergentes motivan ms a los

equipos de trabajo.
El principal beneficio del diseo orientado a
objetos es que proporciona un mecanismo para
formalizar modelos de la realidad.
Evita malentendidos de requerimientos entre el
cliente y el equipo.
El uso del modelo orientado a objetos alienta la
reutilizacin no solo del software, sino de diseos
completos.
Proporcionan mejores resultados en los proyectos
de alto riesgo.

Brinda un enfoque con el cual estructurar la

necesidad de recomponer el software.
Reduce el costo de mantenimiento.
Incrementa la calidad del software final.
Por la naturaleza cambiante del software, se ha
vuelto indispensable para poder mantener
operativos sistemas muy antiguos.
Permite adaptar el sistema a las tecnologas ms
actuales.
Permite mantener funcionales sistemas vitales de
una empresa.

Problemas derivados de la comunicaci

comunicacin resulta difcil de preserva
tiempo y est sujeta a muchas ambige
Falta de calidad.
Probar el cdigo de forma constante no
de calidad, slo revela falta de anlisis

Aplicar reingeniera a un sistema de inf

cuando esta metodologa reduce los pro
sigue siendo costoso y genera una sobr
recursos.
Se requiere de una cierta habilidad par
anlisis
Existen riesgos asociados, si no se com
bien, la funcionalidad del sistema.
Se pueden perder mdulos completos d
quienes aplican la reingeniera, no cuen
experiencia suficiente para realizarla.

Observaciones
De lo anterior, podemos hacer algunas observaciones interesantes, por
ejemplo, si comparamos la relacin que existe entre la metodologa
evolutiva, y la de proceso unificado. Como vemos ambos siguen una
estructura de procesos incremental, ya que cada proceso se realiza uno por
uno, con la diferencia que el proceso unificado se tiene que realizar todo de
manera secuencial y en el evolutivo una vez que se termina una seccin del
software y ste ya se puede utilizar se hace disponible al cliente.

Otra cosa que los diferencia es el hecho que en el proceso unificado se puede
observar la arquitectura del sistema desde mltiples perspectivas cosa que en
el modelo evolutivo no se puede apreciar a simple vista ya que ste est
elaborado por partes.
Otra de las cosas que podemos analizar es la relacin que existe por ejemplo
entre la metodologa evolutiva y la espiral. Como vemos, la metodologa
espiral surge como una modificacin de la metodologa evolutiva. Hasta cierto
punto podramos considerarlo una mejora, debido a que en el caso de la
metodologa espiral se elimina el factor de inestabilidad que caracteriza a la
metodologa evolutiva en la cual el cdigo va perdiendo estructura
modificacin tras modificacin, mientras que en la espiral, el avance no est
sometido a tantas modificaciones estructurales graves que puedan
comprometerla.
Respecto a la metodologa incremental y las metodologas giles, vemos
que ambos son iterativos, su diferencia radica en que el incremental produce
porciones pequeas del software, y en el gil se basan sus iteraciones en
caractersticas generales que se le aaden a un sistema ya funcional. Otra
diferencia radica en que el incremental puedes usarlo para proyectos ms
completos que uno que se trabaje por metodologa gil. Adems, en la
metodologa incremental nos encontramos con que necesitamos conocer a
fondo los requisitos del sistema (para elaborar de buena manera los prototipos
que irn incrementando la capacidad del sistema), mientras que en la gil se
pide que los requisitos no sean tan extensos para que se pueda realizar
gilmente.
En cuanto a las metodologas de cascada e incremental podemos mencionar
que el modelo de cascada una vez iniciado no se detiene y por ende el tiempo
invertido en el desarrollo es menor, mientras que en el incremental, como ya
vimos, el proyecto se desarrolla haciendo avances por mdulos, entonces el
tiempo de desarrollo puede ser que se alargue un poco en caso de que se
presenten incrementos que no cumplan con las especificaciones requeridas.
Por otro lado el desarrollo en cascada no involucra al cliente, no hay
retroalimentacin y por lo tanto existe la posibilidad de que el sistema no sea
lo esperado, en cambio en el desarrollo incremental la retroalimentacin por
parte del cliente est muy presente cuando se hace la entrega de cada mdulo
o incremento, as se asegura que el cliente obtenga lo que realmente pide y
adems se reducen los riesgos de fallos.
Para seguir con nuestras observaciones, podemos comentar sobre la
metodologa basada en prototipos la cual consiste en detectar los
requerimientos del sistema a desarrollar para de esta forma crear un modelo
que satisfaga los aspectos tcnicos y poder traspasarlos a formatos de pantalla
acoplados a estos requerimientos. Por otro lado, el desarrollo basado en
componentes es extremadamente gil debido a que utiliza el reutilizamiento
de cdigo al tomar componentes de software previamente elaborados para

poder moldearlos a un marco que entre en contexto con el sistema y se adapte

de forma natural.
Es posible visualizar que estas dos metodologas comparten algunas
diferencias, debido a que la metodologa de Prototipos genera un diseo visual
y estructural con formatos de requerimientos del sistema bajo el cual
posteriormente se empezar a construir el sistema completo, mientras que por
otra parte el desarrollo Basado en Componentes se construye utilizando
estructuras ya hechas reutilizando cdigo para llegar a un producto final, es
cuestin de tomar un punto de vista amplio para poder visualizarlo en cierta
forma como procesos inversos en cuanto a la construccin de un sistema. De
igual forma, es posible trabajar en conjunto ambas metodologas para llevar un
desarrollo an ms prctico, utilizando el desarrollo Basado en Componentes
para realizar una estructura visual utilizando componentes grficos
previamente diseados y poder llegar a maquetar un Prototipo. Una vez hecho
esto es posible utilizar ms componentes complementar el modelo y
simplemente adaptarlo con un desarrollo basado en el Modelo de Prototipos
fcilmente. Ambas metodologas son muy agiles y prcticas, utilizadas
actualmente por muchas empresas debido a su rapidez y el gran nmero de
herramientas que permiten realizar el desarrollo bajo ellas.
Esto solo por realizar las observaciones que nos parecieron ms pertinentes y
necesarias.

Referencias
Weitzenfeld, A. (2005) Ingeniera de Software Orientada a Objetos con UML,
Java e Internet. Mxico: Thompson.
Sommerville, I. (2011) Ingeniera de Software (Novena ed.). Mxico: Pearson.
Pressman, R. (2002). Ingeniera del Sotware: Un enfoque prctico. (5ta Edicion)
Mxico: Mc Graw Hill
Valderrama, J. (1997). Informacin Tecnolgica. (1 edicin). Chile: La Serena.
Martnez, S. (2011). Metodologa de implementacin de ERP. (1 edicin).
Espaa: Pyme.
Areba, J. (2001). Metodologa del anlisis estructurado de sistemas. (2da
Edicin). Madrid, Espaa: Universidad Pontificia de Comillas.
Snchez, J. (2003). Ingeniera de Proyectos Informticos: actividades y
procedimientos. Universitat Jaume I
Selby, R. (2007). Software Engineering: Barry W. Boehm's Lifetime
Contributions to Software. USA. University of Southern California.
Galindo, M. (2010). Escaneando la informtica. Barcelona, Espaa: UOC
Jacobson, I., Booch, G & J.Rumbaugh. (1999). The Unified Software
Development Process. USA. Addison-Wesley

Kendall & Kendall. (2011). Anlisis y diseo de Sistemas. (8va Edicin). Mxico
D.F. Prentice Hall.
Terreros, J. C. (s.f.). Microsoft: Developer Network. Obtenido de Microsoft:
https://msdn.microsoft.com/es-es/library/bb972268.aspx
Metodologas todas. (2013). Recuperado el da 13 de Febrero de 2015 de
http://es.slideshare.net/thecarlosrock/metodologias-todas
Unidad II- Metodologas de desarrollo. (2013). Recuperado el da 13 de Febrero
de 2015 de http://fgaith2.blogspot.mx/