Taxonomia de Modelos en Ingenieria de Software

Universidades
ISSN: 0041-8935
udual1@servidor.unam.mx
Unin de Universidades de Amrica Latina y el
Caribe
Organismo Internacional
Cervantes Ojeda, J.; Gmez Fuentes, Mara del Carmen

Taxonoma de los modelos y metodologas de desarrollo de software ms utilizados
Universidades, vol. LXII, nm. 52, enero-marzo, 2012, pp. 37-47
Unin de Universidades de Amrica Latina y el Caribe
Distrito Federal, Organismo Internacional
Disponible en: http://www.redalyc.org/articulo.oa?id=37326902005
Cmo citar el artculo

Nmero completo
Ms informacin del artculo
Pgina de la revista en redalyc.org
Sistema de Informacin Cientfica

Red de Revistas Cientficas de Amrica Latina, el Caribe, Espaa y Portugal
Proyecto acadmico sin fines de lucro, desarrollado bajo la iniciativa de acceso abierto
Universidades
UDUAL, Mxico, n. 52, enero-marzo 2012, pp. 37-47. ISSN 0041-8935
Taxonoma de los modelos y metodologas de

desarrollo de software ms utilizados
J. C e r va n t e s O j e da
M a r a d el C a r m en G m e z Fu en t e s
Doctores en ciencias de la computacin en la Universidad Autnoma Metropolitana, Unidad Cuajimalpa, Mxico.
Correo-e: jcervantes@correo.cua.uam.mx
Resumen
Abstract
A travs de una recopilacin y anlisis de los principales
Based on a survey and analysis of the main existing Soft-
modelos de desarrollo de software existentes, propone-
ware Development models, this paper describes a pro-
mos una taxonoma que los integra con el fin de facilitar la
posal of a new taxonomy that integrates these models in
eleccin de un modelo apropiado para cada proyecto en
order to facilitate the task of choosing a suitable model
particular. Una buena eleccin de modelo (correctamente
for each particular project. A good choice of a model (if
aplicado) ahorra tiempo y mejora la calidad de los siste-
used in the right way) saves time and improves the qua-
mas que se producen. Sin embargo, la amplia variedad de
lity of the produced systems. Though, the wide variety of
modelos y metodologas en el mundo del desarrollo de
models and methodologies in the Software development
software, dificulta esta eleccin. La taxonoma propuesta
world makes this choice difficult. The proposed taxonomy
presenta un panorama general de los modelos y metodo-
presents a general view of the most accepted models and
logas ms aceptados y los agrupa en categoras. Discuti-
methodologies and groups them in categories. We discuss
mos las caractersticas ms representativas de cada una de
the most representative properties of each category.
estas categoras.
Key words
Palabras clave
Software engineering, taxonomy of software development
Ingeniera de software, taxonoma de modelos de desarrollo de software, ciclo de vida del software.
models, software life cycle.
37

J. Cervantes Ojeda y Mara del Carmen Gmez Fuentes
1 Introduccin
38
Citando a Platn, el comienzo es la parte ms difcil del
se tiene bien claro lo que se va a hacer. La fase de reque-
trabajo. Podramos agregar que tambin es la parte
rimientos es una parte esencial que no puede dejar de
ms importante, al menos en proyectos de desarrollo de
ser atendida con el debido cuidado y esfuerzo. Adems
software. Podemos afirmar que el xito de los proyectos
de la mala especificacin de requerimientos, otra de las
de software depende en gran medida de que tengan un
importantes causas del fracaso de los proyectos de soft-
buen inicio. Uno de los factores clave para un buen inicio
ware es la mala eleccin de un modelo de desarrollo para
es que la eleccin del modelo de desarrollo se adece a
los mismos. Pensamos que el presente trabajo contribuye
las caractersticas y circunstancias del proyecto. La elec-
a que esta eleccin se haga con una mejor perspectiva
cin y aplicacin correcta de un modelo de desarrollo
de las caractersticas de los modelos existentes que, a
de software permite ahorrar tiempo y mejorar la calidad
nuestro juicio, son los ms importantes.
de los sistemas que se producen. Sin embargo, la amplia
En la seccin 2 de este trabajo, definimos los con-
variedad de modelos y metodologas en el mundo del
ceptos de proceso y modelo de desarrollo de software
desarrollo de software, hace que no sea sencillo elegir el
as como su relacin con el concepto de ciclo de vida. Se
modelo ms apropiado para un proyecto especfico, sobre
describen los antecedentes de modelos abstractos. En
todo cuando la definicin de estos modelos y metodolo-
la seccin 3 proponemos una taxonoma que clasifica
gas se encuentra dispersa en varios libros, artculos y sitios
los modelos de desarrollo de software. Adems, en la
de internet. Proponemos una taxonoma que condensa
seccin 4 mencionamos las ventajas y desventajas de las
toda esta informacin y que brinda un panorama general
categoras de modelos en esta taxonoma.
de los modelos existentes con sus ventajas y desventajas.

Hasta donde tenemos noticia, no se ha hecho un trabajo
similar a ste desde 1994 (Blum, 1994). El surgimiento de
2 Antecedentes
importantes modelos y metodologas desde entonces a

la fecha amerita una nueva clasificacin que incluya los
ms importantes en la actualidad.
2.1 Relacin entre proceso, modelo y ciclo de vida

del software
Se han hecho estudios acerca de los fracasos en los

proyectos de software, por ejemplo (Mangione, 2003) y
Un proceso de desarrollo de software es el conjunto
(McManus & Wood, 2004). Actualmente siguen existiendo
estructurado de las actividades requeridas para realizar
proyectos de software que fracasan en los que se involu-
un sistema de software. Estas actividades son: especifica-
cran miles o millones de dlares para su realizacin. En la
cin de requerimientos, diseo, codificacin, validacin
mayora de los casos el fracaso se debe a que el tiempo
(pruebas) y mantenimiento. Al proceso de desarrollo
utilizado para el desarrollo del proyecto hace que ste
de software tambin se le conoce como ciclo de vida
se convierta en no viable. El fracaso de proyectos de
del software porque describe la vida de un producto
software algunas veces ha implicado la prdida de mu-
de software; primero nace con la especificacin de los
chsimo dinero o incluso la prdida de vidas humanas por
requerimientos, luego se lleva a cabo su implantacin,
entregar productos defectuosos (Pfleeger & Atlee, 2006:
que consiste en su diseo, codificacin y pruebas, pos-
37-38; Weitzenfeld, 2004:3-13). El tiempo de desarrollo de
teriormente el producto se entrega y sigue viviendo
un producto de software se extiende mucho cuando no
durante su utilizacin y mantenimiento. En este ciclo se

establece una comunicacin interactiva entre cliente y
Universidades
desarrollador en la que el primero solicita servicios y el
*Diseo del sistema y del software. Durante el proceso
segundo propone soluciones. El ciclo de vida del sistema
de diseo del sistema se distinguen cuales son los
de software termina cuando ste se deja de utilizar. Por
requerimientos de software y cuales los de hardware.
otra parte, un modelo de desarrollo de software es una
Despus se establece una arquitectura completa del
representacin abstracta de este proceso (Sommerville,
sistema. Durante el diseo del software se identifican
2005:60). Un modelo de desarrollo de SW determina el
los subsistemas que componen el sistema y se describe
orden en el que se llevan a cabo las actividades del pro-
cmo funciona cada uno y las relaciones entre stos.
ceso de desarrollo de SW, es decir, es el procedimiento
*Implementacin y validacin de unidades. Consiste
que se sigue durante el proceso. Al modelo de desarrollo
en codificar y probar los diferentes subsistemas por
tambin se le llama paradigma del proceso.
separado. La prueba de unidades implica verificar

que cada una cumpla su especificacin (proveniente
2.2 Antecedentes de modelos abstractos
del diseo).
*Integracin y validacin del sistema. Una vez que se
Hay una gran variedad de paradigmas o modelos de
prob que funciona individualmente cada una de las
desarrollo de software. Los libros ms conocidos de
unidades, stas se integran para formar un sistema
ingeniera de software (Braude, 2003:21-33; McConnell,
completo que debe cumplir con todos los requeri-
1997: 148-167; Pfleger, 2002: 54-66; Pressman, 2002: 20-
mientos del software. Cuando las pruebas del sistema
30; Sommerville, 2005: 60-69; Weitzenfeld, 2004: 50-64)
completo son exitosas, ste se entrega al cliente.
explican slo los que consideran ms importantes y el
*Funcionamiento y mantenimiento. El sistema se instala
problema en ellos es que las opiniones acerca de cul es
y se pone en funcionamiento prctico. El manteni-
la lista de modelos que debe considerarse son diversas.
miento implica corregir errores no descubiertos en
Sommerville (Sommerville, 2005: 60-69), clasifica todos
las etapas anteriores del ciclo de vida y mejorar la
los procesos de desarrollo de software en tres mode-
implantacin de las unidades del sistema para darle
los o paradigmas generales que no son descripciones
mayor robustez (y no nuevas funcionalidades).
definitivas de los procesos del software, sino, ms bien,
b) Modelos de desarrollo evolutivo. Los modelos
son abstracciones de los modelos que se pueden utilizar
evolutivos son iterativos. Se caracterizan por la forma
para desarrollar software, y son los siguientes.
en que permiten a los ingenieros de software desa-
a) Modelos en cascada. Las actividades fundamen-
rrollar versiones cada vez ms completas del sistema.
tales del proceso de desarrollo de software se llevan
Los modelos evolutivos iteran sobre las actividades de
a cabo como fases separadas y consecutivas. Estas
especificacin, desarrollo y validacin. Un sistema inicial
actividades son: especificacin (anlisis y definicin de
se desarrolla a partir de los requerimientos prioritarios
requerimientos), implantacin (diseo, codificacin,
o los que estn mejor definidos. Esta primera versin
validacin) y mantenimiento. Los modelos en cascada
se refina en una nueva iteracin con las peticiones del
constan bsicamente de 5 fases que son:
cliente para producir un sistema que satisfaga sus ne-
*Anlisis y definicin de requerimientos. Se trabaja con
cesidades. Sommerville define dos tipos de desarrollo
los clientes y los usuarios finales del sistema para de-
evolutivo:
terminar el dominio de aplicacin y los servicios que
b.1) Desarrollo exploratorio. Se le presenta al cliente
debe proporcionar el sistema as como sus restriccio-
el desarrollo de la parte de los requerimientos que se
nes. Con esta informacin se produce el documento
entendi bien para recibir sus comentarios y as refinar
de Especificacin de Requerimientos del Sistema.
el sistema hasta que se logra desarrollar el sistema

adecuado.
39

b.2) Prototipos desechables. Para descubrir o terminar de comprender los requerimientos del cliente
alternativas.
se construye un prototipo con funcionalidad simulada
Diseo del sistema con reutilizacin. Se disea o
y, si ste no es lo que el cliente espera, se construye
se reutiliza un marco de trabajo para el nuevo sistema
otro prototipo (posiblemente desde cero) con una
teniendo en cuenta los componentes que se reuti-
definicin mejorada de los requerimientos para el sis-
lizan y los componentes que sern completamente
tema. El diseo del prototipo va evolucionando segn
nuevos.
se vayan entendiendo los requerimientos, aunque la
Desarrollo e integracin. El software que no se
funcionalidad siga siendo simulada. Cuando se aclaran
tiene disponible y que no se puede adquirir exter-
los requerimientos se completa la funcionalidad segn
namente se desarrolla integrando los componentes
el ltimo prototipo.
reutilizables disponibles. En este modelo, la integracin
c) Modelos de componentes reutilizables. Se

basa en la existencia de un nmero significativo de
40
el anlisis de componentes para buscar soluciones
de los sistemas es parte del desarrollo ms que una

actividad separada.
componentes reutilizables. El reuso de los compo-
Los tres paradigmas o modelos de procesos gen-
nentes tiene como finalidad usar de nuevo ideas,
ricos: cascada, evolutivo y componentes reutilizables,
arquitecturas, diseos o cdigo de una aplicacin para
se utilizan ampliamente en la prctica actual de la
construir otras. El proceso de desarrollo del sistema se
ingeniera del software. No se excluyen mutuamente
enfoca en integrar estos componentes en el sistema,
y a menudo se utilizan juntos, especialmente para el
en lugar de desarrollarlos desde cero.
desarrollo de sistemas grandes (Sommerville, 2005:
Segn Sommerville (2005:64), en la mayora de
61). El problema es que en la literatura no se hace una
los proyectos existe algo de reutilizacin de software.
clasificacin explcita que ubique cada modelo o me-
Por lo general, esto sucede informalmente cuando las
todologa dentro de alguna de estas clases abstractas.
personas que trabajan en el proyecto conocen dise-
En la siguiente seccin hacemos esta clasificacin para
os de cdigo similares al requerido. Los buscan, los
los modelos ms representativos.
modifican segn lo creen necesario y los incorporan

en el sistema. Las etapas de especificacin de requerimientos y de validacin son comparables con los
otros procesos, sin embargo, las etapas intermedias en
3 Taxonoma propuesta de modelos de

desarrollo
el proceso orientado a la reutilizacin son diferentes.

Estas etapas son:
A continuacin (ver la figura 1) proponemos la clasifi-
Anlisis de componentes. Consiste en encontrar
cacin de los modelos y metodologas concretos ms
componentes que sirvan para desarrollar la Especifica-
citados en la literatura en cinco clases abstractas: Casca-
cin de Requerimientos. En general, los componentes
da, Evolutivos, Minimizacin de Desarrollos, Hbridos y
que se utilizan slo proporcionan parte de la funciona-
giles. Los dividimos en Modelos Tradicionales (tambin
lidad requerida por lo que se necesita modificarlos.
llamados pesados), que son los que promueven la dis-
Modificacin de requerimientos. Con la informa-
ciplina por medio de la planificacin y la comunicacin
cin que se tiene de los componentes ya identificados,
escrita, y los Metodologas giles, que dan prioridad a
se analizan los requerimientos. Si es posible, se modi-
la interaccin entre los individuos y a la comunicacin
fican los requerimientos para que concuerden con los
con el cliente.
componentes disponibles. Si las modificaciones no

son posibles entonces se lleva a cabo nuevamente
Universidades
Figura 1: Clasificacin de modelos concretos en clases abstractas.

Modelo Abstracto
Modelos Concretos
Pura
Con fases solapadas
En Cascada
Con subproyectos
Con reduccin de riesgos
Espiral
Entrega por etapas o incremental
Tradicionales o Pesados
Entrega evolutiva o iterativo
Evolutivos
Diseo por planificacin

Cascada en V
Minimizacin de Desarrollos
Hbridos
Componentes Reutilizables
Diseo por herramientas
Proceso Unificado Racional
Otros
Programacin extrema
SCRUM
Metodologas giles
Desarrollo dirigido por pruebas

Desarrollo dirigido por Caractersticas
Agile, Lean, Crystal, , etc.
3.1 En Cascada
completado el diseo global) que se pueden desarrollar

en paralelo e integrarlos todos al final, conserva el carcter
Al modelo abstracto En Cascada pertenecen los siguien-
secuencial de las actividades. En el modelo de cascada
tes: cascada puro, cascada con fases solapadas, cascada
con reduccin de riesgos se controla el riesgo en la fase
con subproyectos y cascada con reduccin de riesgos
de requerimientos con una espiral que los identifica y
(Braude, 2003:24-26; McConnell, 1997: 148-159; Pfleger,
mitiga y prev la posibilidad de retroceder en la secuencia
2002: 55-57; Pressman, 2002: 23-27; Sommerville, 2005:
de actividades pero las mantiene en el mismo orden que
62-63; Weitzenfeld, 2004: 50-51). Todos estos modelos se
una cascada pura.
caracterizan por una secuenciacin serial de las siguientes actividades: anlisis y definicin de requerimientos,
3.2 Evolutivos
diseo, codificacin, validacin y mantenimiento. Adems, en todos ellos se produce una documentacin
A la clase abstracta de modelos Evolutivos pertenecen:
completa del sistema. El modelo en cascada con fases
espiral, entrega por etapas o incremental, entrega evo-
solapadas permite hacer actividades de la siguiente fase
lutiva o iterativo, diseo por planificacin y cascada en
en paralelo a las ltimas actividades de la fase anterior
V (Braude, 2003:26-28; McConnell, 1997:153-165; Pfleger,
sin romper la secuenciacin de las fases. El modelo de
2002: 57-67; Pressman, 2002: 23-27; Sommerville, 2005:
cascada con subproyectos, aunque divide el proyecto
63-64 y 66-69; Weitzenfeld, 2004: 51-54). Los modelos
en subproyectos ms pequeos (a partir de que se ha
evolutivos tienen la particularidad de visitar las diferentes
41

etapas de desarrollo varias veces segn sea necesario
ticas recopiladas de un conjunto grande de proyectos
pero en un orden especfico, es decir, no se prevn retro-
exitosos. Es una metodologa que llama al proceso de
cesos en la secuencia. Al modelo de entrega por etapas
desarrollo de software: Rational Unified Process (RUP) que
Pfleeger y Atlee le llaman implementacin incremental
en espaol es Proceso Unificado Racional. El RUP es un
porque se entrega el software en partes pequeas, pero
modelo de proceso Hbrido ya que rene elementos de
utilizables, llamadas incrementos. Al modelo de entrega
modelos de procesos genricos (Sommerville, 2005:76).
evolutiva Pfleeger y Atlee le llaman iterativo, en el que
Adems propone buenas prcticas para la especificacin
se entrega el esqueleto de un sistema completo desde
y el diseo. El proceso unificado se describe desde tres
el principio, y luego se va rellenando la funcionalidad
perspectivas:
de cada subsistema con cada versin nueva.
1.- Una perspectiva dinmica.- Muestra las fases (tambin

llamadas etapas) del modelo sobre el tiempo, stas son:
3.3 Minimizacin de desarrollos
inicio, elaboracin, construccin y transicin.

2.- Una perspectiva esttica.- Muestra las actividades
42
En la clase de modelos de Minimizacin de desarrollos
que tienen lugar durante el proceso de desarrollo, se
podemos encontrar: componentes reutilizables y desa-
denominan flujos de trabajo, stos son: modelado del
rrollo por herramientas (Braude, 2003:21-22; McConnell,
negocio, requerimientos, anlisis y diseo, implemen-
1997: 165-167; Pressman, 2002: 22, 28; Sommerville, 2005:
tacin, pruebas, despliegue, gestin de configuracin
60-69; Weitzenfeld, 2004: 50-64). Con estos modelos se
y cambios, gestin del proyecto y entorno.
saca ventaja de elementos desarrollados previamente y

se caracterizan por aumentar la importancia (respecto a
3.- Una perspectiva prctica.- Sugiere buenas prcticas a

utilizar durante el proceso.
otros modelos) de esta reutilizacin y disminuir la impor-
En cuanto a la perspectiva prctica, se recomien-
tancia del cumplimiento estricto de los requerimientos
dan seis buenas prcticas aconsejables en el desarrollo
con la idea de acelerar el proceso de desarrollo. Se le
de sistemas: Desarrollar el software de forma iterativa
ofrece al cliente primero lo que es fcilmente entregable
(entregando primero los requerimientos ms importan-
y, solamente en caso de ser necesario, se propone un
tes), Gestionar los requerimientos (analizando el impacto
desarrollo nuevo. En el diseo por herramientas, por
de los cambios en el sistema antes de aceptarlos y docu-
ejemplo, se trata de hacer uso de herramientas que estn
mentando los cambios aceptados), Utilizar arquitecturas
ya disponibles y, a partir de un conjunto de funcionali-
basadas en componentes (en la mayor medida posible),
dades soportadas por stas, ofrecer al cliente la mayor
modelar el software visiblemente ( con modelos grficos
parte posible de las funcionalidades que requiera. En el
como UML), verificar la calidad del software, controlar
desarrollo por componentes reutilizables se parte de un
los cambios del software y gestionar los cambios del
sistema previamente desarrollado y, a partir de algunas
software usando herramientas de gestin de configu-
de sus definiciones de requerimientos, de partes de
raciones.
diseos y de grupos de guiones de prueba o de datos,
El Proceso Unificado no es un proceso apropiado
se desarrolla el nuevo sistema con la idea de reducir el
para todos los tipos de desarrollo, sin embargo repre-
tiempo desarrollo y costos.
senta una nueva generacin de procesos genricos

(Sommerville, 2005: 78). Las innovaciones ms impor-
3.4 Hbridos
tantes son la separacin de fases y los flujos de trabajo,

y el reconocimiento de que la utilizacin del software
IBM Rational (IBM, Rational Unified Process) propone
en un entorno de usuario es parte del proceso. Las fases
el desarrollo de software basado en las mejores prc-
(o etapas) son dinmicas y tienen objetivos. Los flujos
Universidades
de trabajo son estticos y son actividades tcnicas que
utilizarse durante el desarrollo para alcanzar los objetivos
no estn asociadas con fases nicas sino que pueden
de cada fase.
Figura 2 Combinacin de las fases (o etapas) con los flujos de trabajo en el Proceso Unificado
En la figura 2 se muestra una visin global de cmo
y definicin del alcance del proyecto. Al final de la
se combinan las fases dinmicas del proceso unificado,
elaboracin: se entrega la arquitectura del sistema.
con los flujos de trabajo estticos. Adems se ilustra que
En cada iteracin de la construccin: se entrega un
en cada fase puede haber varios incrementos.
producto con la funcin anterior ms el incremento
Los requerimientos se trabajan desde la fase de ini-
correspondiente a la nueva iteracin, de tal forma
cio, y muy especialmente durante la fase de elaboracin,
que al final de la construccin se obtiene la versin
pues el objetivo es tener claro por lo menos un 80% del
inicial del sistema con capacidad operacional, es
sistema que se requiere construir (Wiegers, 2006: 31).
decir, con toda la funcionalidad requerida. Al final de
Las caractersticas del Proceso Unificado segn

(Ambler, 2005) son:
la transicin: se entrega el producto completamente

funcional.
Visto a lo largo de todo el proyecto, es serial en el
Aunque el RUP fue concebido inicialmente para
tiempo: comienza con la etapa de inicio, luego la etapa
sistemas orientados a objetos, en algunos casos vale
de elaboracin, despus la etapa de construccin y al
la pena aplicarlo a situaciones no orientadas a objetos
final la etapa de transicin.
y obtener de todas formas algunas de las ventajas del
Visto en cada etapa es iterativo: la etapa puede estar

compuesta de varias entregas. Hay entregas parciales
del producto, las funcionalidades se van incluyendo
de manera incremental.
Se apoya en buenas prcticas probadas en innumerables proyectos exitosos para una gran variedad
de dominios.
Al final de cada una de las etapas del Proceso Unificado se debe entregar un producto importante
(hito): Al final del inicio: se entregan los objetivos
RUP como son:

Hacer frente a los riesgos de cambios en los requerimientos,
Disminuir el riesgo financiero al hacer entregas parciales de software funcional que puede probarse y ser
evaluado por el cliente.
Se puede adaptar para administrar el proceso con los
niveles de flexibilidad y rigor necesarios para cada
situacin en particular.
43

3.5 Las metodologas giles
elaborar un plan y seguirlo ya que, segn esta filosofa,

es imposible anticipar todos los requerimientos desde el
Hasta ahora hemos hablado de las llamadas metodolo-
44
inicio del desarrollo (Pfleeger & Atlee, 2006:59).
gas tradicionales, las cuales se basan en la disciplina y
West & Grant (West & Grant, 2010) realizaron un es-
el orden, sin embargo, por ms que en los ltimos aos
tudio sobre los mtodos y metodologas ms utilizados
han evolucionado diversas metodologas para asegurar
en la industria del software durante el 2008 y el 2009.
un mejor control del proceso, los clientes quedan fre-
Segn los resultados, en el 2008 algunas metodologas
cuentemente insatisfechos con el resultado (Aguilar,
giles ocuparon el primer lugar, stas fueron: SCRUM (Pa-
2002:1). Si bien, la mala administracin es la principal causa
zderski, 2010) programacin extrema, llamada en ingls
detectada en los fracasos en los proyectos de software,
XP: eXtreme Programming (Aguilar, 2002), Desarrollo
algunos tambin atribuyen el fracaso a la metodologa
Dirigido por Pruebas, llamado en ingls TDD: Test-Dri-
empleada para su desarrollo. Las metodologas giles
ven development (Arajo, 2007), Delgado o Menudo,
surgen como otra alternativa de desarrollo para contra-
conocido como Lean (Poppendieck & Poppendieck,
rrestar estos fracasos. Las prcticas que recomiendan
2003), Desarrollo Dirigido por Caractersticas, llamado en
son algunas veces opuestas a lo recomendado por las
ingls FDD: Feature Driven Development (Anderson,
metodologas tradicionales. La metodologas giles se
2004) y Modelado gil (Ambler, 2008). En segundo lugar
basan en un desarrollo iterativo e incremental en muy
se utilizaron modelos iterativos y en tercer lugar el mo-
breves ciclos y un diseo inicial simple (Arajo, 2007:2).
delo en cascada. Otras metodologas giles y el Proceso
Segn estudios recientes, las metodologas giles tienen
Unificado tuvieron una participacin muy pequea. En el
una gran aceptacin en la industria del software (West
2009, los resultados fueron muy similares, el 35% de 1,298
& Grant, 2010), sin embargo, segn sus fundadores, stas
encuestados utilizaron metodologas giles (destacaron
slo son aplicables cuando se dan las siguientes condi-
las mismas que en el 2008), el 21% utiliz mtodos iterati-
ciones (Fowler, 2000):
vos y el Proceso Unificado y el 13.4% utiliz el cascada. Es
Proyectos pequeos y equipos con menos de 100
interesante mencionar que el 30.6% de los encuestados
personas.
no utilizaron ninguna metodologa formal.
Requerimientos cambiantes.
Equipo de desarrollo competente.
Cliente dispuesto a participar con el equipo.
En febrero de 2001 se emiti el Manifiesto para el
4 Eleccin del modelo de desarrollo de

software
desarrollo gil del software (Manifesto, 2001) en el cual se

estipulan las caractersticas que debe tener un desarrollo
La eleccin de un modelo de ciclo de vida errneo puede
gil. Las metodologas giles valoran ms a los individuos
dar lugar a la omisin de tareas y a una secuenciacin
y las interacciones entre stos que a los procesos y a las
inapropiada de las mismas, lo cual va en contra de la
herramientas. Se fomenta ms la comunicacin cara a
planificacin y eficiencia del proyecto. La eleccin de un
cara que la documentacin, de tal manera que el tiempo
modelo apropiado tiene el efecto contrario, asegurando
se emplea en producir software que funciona en lugar
que todo el esfuerzo se utiliza eficientemente (McCon-
de usarlo para producir documentacin. Se le da ms
nell, 1997: 501).
nfasis a la colaboracin con el cliente en los aspectos
Puesto que la necesidad de un proyecto se genera
claves del desarrollo que a la negociacin del contrato y
a partir del surgimiento de requerimientos, la naturaleza
se concentran en la respuesta a los cambios en lugar de
de stos es uno de los aspectos importantes para la eleccin del modelo de desarrollo. Los requerimientos estn
Universidades
estrechamente relacionados con la eleccin del modelo
que para sistemas pequeos los procesos evolutivos son
para desarrollar el proyecto.
ms aceptados otros.
En los modelos tipo cascada, los requerimientos
En los modelos evolutivos, los requerimientos se
tienen que estar bien definidos desde el inicio del pro-
trabajan al inicio de cada iteracin para aumentarlos,
yecto y la probabilidad de que cambien debe ser mnima.
corregirlos o redefinirlos. En estos modelos se complica
Cabe mencionar que esto aplica, tanto al desarrollo de
mantener actualizada y correcta la documentacin. Ade-
sistemas nuevos, como al desarrollo de modificaciones
ms, en sistemas muy grandes, cada nueva adicin puede
sobre un sistema existente. Pfleeger & Atlee (Pfleeger
implicar que el cdigo se corrompa debido a una mala
& Atlee: 2006: 145) recomiendan adems el uso de un
administracin de los cambios. En este tipo de procesos, la
modelo en cascada cuando los requerimientos estn
especificacin de requerimientos se desarrolla junto con
fuertemente acoplados o cuando son complejos, es decir,
el software, esto puede crear conflictos en las organiza-
cuando no es sencillo separar los requerimientos para
ciones en las que la especificacin de requerimientos es
desarrollarlos uno por uno, ya que se corre el riesgo de
parte del contrato (Sommerville, 2005:66). Los procesos
que el desarrollo de unos no sea compatible con la de
evolutivos permiten mostrar al cliente una versin parcial
otros. Otro caso en el que el modelo en cascada es viable,
preliminar que permita obtener retroalimentacin y evite
es cuando muchas personas participan en el proyecto, ya
problemas con la integracin de un cdigo muy grande.
sea porque el proyecto es grande (en cuyo caso ya se ha
Para que este modelo sea til se debe poder comenzar
justificado el uso de un modelo tipo cascada) o porque
con algunos requerimientos prioritarios y dejar para los
se requiere de la colaboracin de especialistas. En estos
ciclos posteriores los dems requerimientos, adems hay
casos es mucho ms sencillo el uso de modelos tipo
que contar con la participacin del usuario, quien debe
cascada ya que resulta muy importante tener procedi-
dedicar tiempo a evaluar y retroalimentar las entregas
mientos de control estrictos y una comunicacin formal
parciales (Braude, 2007:27). Los modelos evolutivos como
y disciplinada entre los participantes. Una recomendacin
el espiral o el incremental tienen grandes ventajas: los
importante (McConnell, 1997) es que no se aumente el
clientes pueden comenzar a utilizar un sistema que tiene
nmero de participantes cuando los tiempos de entrega
los requerimientos prioritarios para ponerlo a prueba y re-
son cortos ya que solamente se logra que la organizacin
portar sus fallas. De esta manera aumenta la probabilidad
se complique debido a lo complejo de la comunicacin
de entregar un software que opere satisfactoriamente.
entre las personas. Si el tiempo de entrega es muy impor-
Adems se facilita la recoleccin de mtricas acerca del
tante entonces no se recomienda el uso de modelos tipo
proceso en cada iteracin. Sin embargo (Sommerville,
cascada. Solamente cuando la calidad del producto sea
2005: 67) recomienda que el cdigo no rebase las 20,000
prioritaria sobre el tiempo de entrega es bueno adoptar
lneas en cada incremento y a veces puede ser difcil
uno de estos modelos (Pfleeger & Atlee, 2006: 145).
adaptar los requerimientos del cliente al tamao apropia-
En suma, los modelos tipo cascada son recomen-
do de un incremento. Braude (Braude, 2006: 27) seala
dables para: requerimientos bien definidos y que no
un punto importante: con el propsito de optimizar la
cambian; requerimientos fuertemente acoplados o com-
productividad en equipo, con frecuencia es necesario
plejos; proyectos donde interviene una gran cantidad
comenzar una nueva iteracin antes de que la anterior
de personas y, cuando es ms importante entregar un
haya terminado, esto no slo dificulta la coordinacin
sistema funcionando correctamente que cumplir con una
de la documentacin, sino que dificulta la coordinacin
fecha de entrega preestablecida. Un estudio realizado
de los cambios en los diferentes mdulos del sistema
por Califa (2000) confirma que para sistemas grandes, los
cuando un requerimiento tiene impacto en varios de
desarrolladores prefieren el modelo en cascada, mientras
estos mdulos.
45

En los modelos de minimizacin de desarrollos, las

funcionalidades de los componentes o mdulos deben
46
(West & Grant, 2010), el RUP no es uno de los modelos

ms utilizados.
ser similares a las nuevas funcionalidades que se requie-
Las metodologas giles estn pensadas para
ren, de tal forma que el esfuerzo en modificar los compo-
afrontar el problema de los requerimientos inciertos
nentes base no sea tan alto que el proceso se entorpezca
o cambiantes, las entregas iniciales tienen el objetivo
en lugar de agilizarse. Se considera una buena prctica
de desarrollar los requerimientos esenciales del cliente.
en la ingeniera de software hacer diseos modulares ya
Con el uso de estas primeras versiones se comprende
que stos tienen el potencial de la reutilizacin de algunas
mejor el problema a solucionar y emergen nuevos
de sus partes (Braude, 2006: 21-22), sin embargo, esto no
requerimientos que son cubiertos en entregas poste-
es fcil. Cuando se adopta este modelo, normalmente se
riores. Adems, la entrega continua de nuevas versio-
negocia con el cliente para hacer modificaciones a sus
nes permite hacer frente a los cambios de ltima hora.
requerimientos con la finalidad de que stos se adapten
Cada entrega contiene requerimientos determinados al
a los componentes base. Es muy importante cuidar que
momento. El riesgo de ste tipo de metodologas es la
estas modificaciones no produzcan un sistema que no
carencia del documento de Especificacin de Requeri-
cumpla con las necesidades reales de los usuarios. La
mientos. Por ejemplo, en la programacin extrema, y en
calidad de un sistema basado en reutilizacin de com-
el Desarrollo Dirigido por Pruebas la documentacin de
ponentes depender mucho de la robustez de stos y el
los requerimientos se sustituye por casos de prueba
mantenimiento del sistema estar limitado por la facilidad
que el sistema debe pasar cuando se implantan ciertos
de acceso que se pueda tener para modificarlos.
requerimientos. Esta escasa documentacin dificulta
El Proceso Unificado Racional (RUP) es un modelo
hacer cambios al sistema cuando ya se borraron, agre-
hbrido que pretende sacar las ventajas de los modelos
garon o modificaron requerimientos anteriores sobre
cascada, evolutivos y las de los de componentes reutiliza-
los que influyen estos nuevos cambios. Adems, si la
bles. Como se mencion en la seccin 2, visto a lo largo de
documentacin de los requerimientos en los casos de
todo el proyecto, es decir, desde una perspectiva dinmi-
prueba es pobre, posiblemente surgirn malos enten-
ca, el RUP es serial en el tiempo, tal y como el modelo en
didos en su implantacin o modificacin (Pfleeger &
cascada. La parte evolutivo/iterativa en la que se descom-
Atlee, 2006: 145).
pone cada una de las etapas, reduce riesgos y es hasta
El modelo de desarrollo que se adopte depende
cierto punto flexible en los cambios de requerimientos.
de cada proyecto ya que cada uno tiene necesidades
La reutilizacin de componentes que se fomenta con este
diferentes. Hay que tomar en cuenta la capacidad y
modelo permite reducir costos y tiempo de desarrollo. El
experiencia del personal en el tipo de proyecto a de-
uso del Lenguaje de Modelado Unificado: UML (Booch
sarrollar para elegir algn mtodo especfico. La canti-
et al., 1999) asociado al RUP, facilita el anlisis y el diseo
dad de personal con el que se cuenta tambin puede
de los componentes del sistema. Sus procedimientos de
llegar a ser decisivo. No es necesario limitar la eleccin
control de calidad y control de cambios contribuyen a la
a un solo modelo de desarrollo, pues en algunos casos
produccin de un software satisfactorio. Sin embargo, el
es mejor combinar varios modelos (Braude, 2006:33,
RUP es un modelo complicado, se requiere de una alta
Sommerville, 2005: 61). Los estudios de West & Grant
capacitacin del administrador del proyecto para llevarlo
(2010) informan que un alto porcentaje de las empre-
a buen trmino. Adems, los miembros del equipo de
sas de software decide mezclar modelos tradicionales
desarrollo tambin deben tener una alta capacitacin
con metodologas giles. Por otra parte, hay que tomar
en el uso de este complejo modelo, probablemente
en cuenta que, independientemente del modelo que
este sea el motivo por el cual, segn estudios recientes
se elija, descuidar la calidad del proyecto en sus fases
Universidades
iniciales implica un desperdicio de esfuerzo al corregir

los errores al final, justo cuando es ms caro (McConnell,
1997:13). Esto no significa que el inicio sea lo importante
pero s que es lo ms importante y decisivo para que un
proyecto tenga xito.
5 Conclusiones
Para aumentar las probabilidades de xito de los proyectos de software es necesario hacer un esfuerzo adicional
en su inicio. Consideramos que la eleccin de un modelo de desarrollo adecuado es un aspecto clave para
iniciar un proyecto de software correctamente, ya que
un modelo que no se adapte al proyecto entorpece su
desarrollo. La nueva taxonoma propuesta en este trabajo
aclara muchas dudas surgidas de la investigacin de la
amplia variedad de modelos de desarrollo de software.
Las principales ventajas y desventajas de cada una de las
categoras en esta taxonoma proporcionan una perspectiva general que facilita la eleccin de l o los modelos
convenientes para cada proyecto en particular. La utilidad
de este tipo de trabajos es evidente y resulta necesario
que se sigan haciendo peridicamente para lograr un
mayor entendimiento entre tericos y practicantes de la
ingeniera de software.
Braude, Eric (2007). Ingeniera de software, una perspectiva orientada a

objetos, Mxico: Alfaomega.
Blum, Bruce (1994). A taxonomy of software development methods, en
Communications of the ACM, v.37 Issue 11, U.S.A.
Fowler, Martin (2000). The new methodology. http://www.martinfowler.
com/articles/newMethodology.html. Traduccin al espaol. http://
www.programacionextrema.org/articulos/newMethodology [21
de Julio de 2011].
IBM, Rational Unified Process. Best Practices for Software Development
Teams, en Rational Software white paper TP026B, n.11/01.
Jackson Michael (1998). Software Requirements & Specifications, a lexicon
of practice, principles and prejudices. Essex: ACM press/AddisonWesley.
Khalifa Mohamed, Verner June M. (2000). Drivers for Software Development Method Usage, en IEEE Transactions on Engineering
Management, v. 47, n.3, pp. 360-369.
Mangione Carmine (2003). Software Project Failure: The Reasons, The
Costs, http://www.cioupdate.com/reports/article.php/1563701/
Software-Project-Failure-The-Reasons-The-Costs.htm [21 de Julio
de 2011].
Manifesto for Agile Software Development (2001), http://www.agilemanifesto.org [21 de Julio de 2011].
McConnell, S. (1997). Desarrollo y gestin de proyectos informticos, Espaa:
McGraw Hill y Microsoft Press.
McManus John & Wood-Harper Trevor. A study in project failure.
The chartered institute for IT, http://www.bcs.org/server.
php?show=ConWebDoc.19584 [21 de Julio de 2011].
Norris & Rigby (1994). Ingeniera de Software explicada, Mxico: MegabyteNoriega editores.
Pazderski P. (2010). Agile through SCRUM, Software Process Consultant
Inc. 26 May 2010 CQAA Lunch & Learn.
Pfleeger, Shari, Atlee Joanne (2002). Ingeniera de software, Teora y prctica, Buenos Aires: Pearson Education, Buenos Aires.
_____________________ (2006). Software Engineering, Theory and
practice. Third edition, New Jersey U.S.A.: Pearson Prentice Hall.
Referencias
Poppendieck, Mary and Poppendieck Tom (2003). Lean Software Development, an Agile Toolkit, by Addison-Wesley Professional.
Ambler, Scott (2005). A Managers Introduction to The Rational Unified

Process (RUP), http://www.ambysoft.com/downloads/managersIntroToRUP.pdf [22 de Julio de 2011].
Pressman, Roger (2002). Ingeniera del Software: Un enfoque prctico, 5

edicin, Espaa: McGraw Hill.
__________ (2008). The Object Primer, 3rd Edition: Agile Model Driven
Development with UML 2, U.S.A.: Cambridge University Press.
Anderson, David (2004). Feature-Driven Development: towards a TOC,
Lean and Six Sigma solution for software engineering, Theory of
Constraints, International Certification Organization, Microsoft.
Aguilar Sierra Alejandro (2002). Introduccin a la programacin extrema,
en Revista Digital Universitaria, v.(3), n.4, Mxico: UNAM.
Arajo Alejandro (2007). Test Driven Development: Fortalezas y Debilidades. Montevideo-Uruguay: Instituto de Computacin, Fac. de
Ingeniera. UDELAR.
Booch Grady, Rumbaugh Jim, & Jacobson Ivar (1999). The Unified Modeling
Language User Guide. Addison-Wesley.
Sommerville, Ian (2005). Ingeniera del Software, 7 Ed., Madrid: Pearson

Addison Wesley.
Weitzenfeld, Alfredo (2004). Ingeniera de Software Orientada a Objetos
con UML, Java e Internet. Mxico: Editorial Thomson.
West, Dave and Grant Tom (2010). Agile Development: Mainstream
Adoption Has Changed Agility. Trends in Real-World Adoption Of
Agile Methods. Application Development & Program Management
Professional, January, Forrester Research Inc., http://www.mendeley.com/research/agile-development-mainstream-adoptionchanged-agility/ (27 de Julio de 2011).
Wiegers, Karl (2006). More about software requirements. U.S.A.: Microsoft
Press.
47

Taxonomia de Modelos en Ingenieria de Software

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Taxonomia de Modelos en Ingenieria de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Universidades

Cervantes Ojeda, J.; Gmez Fuentes, Mara del Carmen

Disponible en: http://www.redalyc.org/articulo.oa?id=37326902005

Cmo citar el artculo

Sistema de Informacin Cientfica

Taxonoma de los modelos y metodologas de

A travs de una recopilacin y anlisis de los principales

Based on a survey and analysis of the main existing Soft-

modelos de desarrollo de software existentes, propone-

ware Development models, this paper describes a pro-

mos una taxonoma que los integra con el fin de facilitar la

posal of a new taxonomy that integrates these models in

eleccin de un modelo apropiado para cada proyecto en

order to facilitate the task of choosing a suitable model

particular. Una buena eleccin de modelo (correctamente

for each particular project. A good choice of a model (if

aplicado) ahorra tiempo y mejora la calidad de los siste-

mas que se producen. Sin embargo, la amplia variedad de

lity of the produced systems. Though, the wide variety of

modelos y metodologas en el mundo del desarrollo de

models and methodologies in the Software development

software, dificulta esta eleccin. La taxonoma propuesta

world makes this choice difficult. The proposed taxonomy

presenta un panorama general de los modelos y metodo-

presents a general view of the most accepted models and

logas ms aceptados y los agrupa en categoras. Discuti-

methodologies and groups them in categories. We discuss

mos las caractersticas ms representativas de cada una de

the most representative properties of each category.

models, software life cycle.

Taxonoma de los modelos y metodologas de desarrollo de software ms utilizados

Citando a Platn, el comienzo es la parte ms difcil del

se tiene bien claro lo que se va a hacer. La fase de reque-

trabajo. Podramos agregar que tambin es la parte

rimientos es una parte esencial que no puede dejar de

ms importante, al menos en proyectos de desarrollo de

ser atendida con el debido cuidado y esfuerzo. Adems

software. Podemos afirmar que el xito de los proyectos

de la mala especificacin de requerimientos, otra de las

de software depende en gran medida de que tengan un

importantes causas del fracaso de los proyectos de soft-

buen inicio. Uno de los factores clave para un buen inicio

ware es la mala eleccin de un modelo de desarrollo para

es que la eleccin del modelo de desarrollo se adece a

los mismos. Pensamos que el presente trabajo contribuye

las caractersticas y circunstancias del proyecto. La elec-

a que esta eleccin se haga con una mejor perspectiva

cin y aplicacin correcta de un modelo de desarrollo

de las caractersticas de los modelos existentes que, a

de software permite ahorrar tiempo y mejorar la calidad

nuestro juicio, son los ms importantes.

de los sistemas que se producen. Sin embargo, la amplia

En la seccin 2 de este trabajo, definimos los con-

variedad de modelos y metodologas en el mundo del

ceptos de proceso y modelo de desarrollo de software

desarrollo de software, hace que no sea sencillo elegir el

as como su relacin con el concepto de ciclo de vida. Se

modelo ms apropiado para un proyecto especfico, sobre

describen los antecedentes de modelos abstractos. En

todo cuando la definicin de estos modelos y metodolo-

la seccin 3 proponemos una taxonoma que clasifica

gas se encuentra dispersa en varios libros, artculos y sitios

los modelos de desarrollo de software. Adems, en la