Você está na página 1de 12

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

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


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
UDUAL, Mxico, n. 52, enero-marzo 2012, pp. 37-47. ISSN 0041-8935

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

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


J. Cervantes Ojeda y Mara del Carmen Gmez Fuentes

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
UDUAL, Mxico, n. 52, enero-marzo 2012, pp. 37-47. ISSN 0041-8935

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

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


J. Cervantes Ojeda y Mara del Carmen Gmez Fuentes

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
UDUAL, Mxico, n. 52, enero-marzo 2012, pp. 37-47. ISSN 0041-8935

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

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


J. Cervantes Ojeda y Mara del Carmen Gmez Fuentes

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
UDUAL, Mxico, n. 52, enero-marzo 2012, pp. 37-47. ISSN 0041-8935

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

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


J. Cervantes Ojeda y Mara del Carmen Gmez Fuentes

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
UDUAL, Mxico, n. 52, enero-marzo 2012, pp. 37-47. ISSN 0041-8935

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