Proceso de desarrollo de software

Introduccin
Un sistema informtico est compuesto por hardware y software. En cuanto al hardware, su produccin se
realiza sistemticamente y la base de conocimiento para el desarrollo de dicha actividad est claramente
definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra mquina construida
por el hombre. Sin embaro, respecto del software, su construccin y resultados han sido histricamente
cuestionados debido a los problemas asociados, entre ellos podemos destacar los siuientes !"#$
Los sistemas no responden a las e%pectativas de los usuarios.
Los proramas &fallan' con cierta frecuencia.
Los costes del software son dif(ciles de prever y normalmente superan las estimaciones.
La modificacin del software es una tarea dif(cil y costosa.
El software se suele presentar fuera del plazo establecido y con menos prestaciones de las
consideradas inicialmente.
)ormalmente, es dif(cil cambiar de entorno hardware usando el mismo software.
El aprovechamiento ptimo de los recursos *personas, tiempo, dinero, herramientas, etc.+ no suele
cumplirse.
Se,n el -entro E%perimental de .nenier(a de Software *-E.S+
"
, el estudio de mercado The Chaos Report
realizado por Standish /roup .nternactional
0
en "112, concluy que slo un "23 de los proyectos de
software son e%itosos *terminan dentro de plazos y costos y cumplen los requerimientos acordados+. 4tro
563 sobrepasa costos y plazos y cumple parcialmente los requerimientos. El resto ni siquiera llea al
t7rmino. 8lunas deficiencias comunes en el desarrollo de software son$
Escasa o tard(a validacin con el cliente.
.nadecuada estin de los requisitos.
)o e%iste medicin del proceso ni reistro de datos histricos.
Estimaciones imprevistas de plazos y costos.
E%cesiva e irracional presin en los plazos.
Escaso o deficiente control en el proreso del proceso de desarrollo.
)o se hace estin de riesos formalmente.
)o se realiza un proceso formal de pruebas.
)o se realizan revisiones t7cnicas formales e inspecciones de cdio.
El primer reconocimiento p,blico de la e%istencia de problemas en la produccin de software tuvo luar en
la conferencia oranizada en "129 por la -omisin de -iencias de la 4:8) en /armisch *8lemania+, dicha
situacin problemtica se denomin crisis del software. En esta conferencia, as( como en la siuiente
realizada en ;oma en "121, se estipul el inter7s hacia los aspectos t7cnicos y administrativos en el
desarrollo y mantenimiento de productos software. Se pretend(a acordar las bases para una inenier(a de
construccin de software. Se,n <ritz =auer !0# lo que se necesitaba era &establecer y usar principios de
ingeniera orientados a obtener software de manera econmica, que sea fiable y funcione eficientemente
sobre mquinas reales'. Esta definicin marcaba posibles cuestiones tales como$ >-ules son los
principios robustos de la inenier(a aplicables al desarrollo de software de computadora? >-mo
construimos el software econmicamente para que sea fiable? >@u7 se necesita para crear proramas de
computadora que funcionen eficientemente no en una mquina sino en diferentes mquinas reales?. Sin
embaro, dicho planteamiento adems deb(a incluir otros aspectos, tales como$ meAora de la calidad del
software, satisfaccin del cliente, mediciones y m7tricas, etc.
"
http$BBwww.ceis.clB/estacionB/estacion.htm *5.6.0CC6+
0
http$BBstandishroup.comB *5.6.0CC6+
D E.Letelier "
El &IEEE tandard !lossary of oftware Engineering Terminology' *Stad. 2"C."0F"11C+ ha desarrollado una
definicin ms completa para inenier(a del software !"#$ &*"+ La aplicacin de un enfoque sistemtico,
disciplinado y cuantificable para el desarrollo, operacin y mantenimiento del softwareG es decir, la
aplicacin de inenier(a al software. *0+ El estudio de enfoques en *"+'.
Eressman !"# caracteriza la .nenier(a de Software como &una tecnolo(a multicapa', ilustrada en la <iura
".
"igura #$ Capas de la Ingeniera de oftware%
Hichas capas se describen a continuacin$
-ualquier disciplina de inenier(a *incluida la inenier(a del software+ debe descansar sobre un esfuerzo
de oranizacin de calidad. La estin total de la calidad y las filosof(as similares fomentan una cultura
continua de meAoras de procesos que conduce al desarrollo de enfoques cada vez ms robustos para la
inenier(a del software.
El fundamento de la inenier(a de software es la capa proceso. El proceso define un marco de trabaAo
para un conAunto de reas clave, las cuales forman la base del control de estin de proyectos de
software y establecen el conte%to en el cual$ se aplican los m7todos t7cnicos, se producen resultados de
trabaAo, se establecen hitos, se aseura la calidad y el cambio se estiona adecuadamente.
Los mtodos de la inenier(a de software indican cmo construir t7cnicamente el software. Los
m7todos abarcan una ran ama de tareas que incluyen anlisis de requisitos, diseIo, construccin de
proramas, pruebas y mantenimiento. Estos m7todos dependen de un conAunto de principios bsicos
que obiernan cada rea de la tecnolo(a e incluyen actividades de modelado y otras t7cnicas
descriptivas.
Las herramientas de la inenier(a del software proporcionan un soporte automtico o semiFautomtico
para el proceso y los m7todos, a estas herramientas se les llama herramientas -8SE *-omputer&'ided
oftware Engineering+.
Hado lo anterior, el obAetivo de la inenier(a de software es lorar productos de software de calidad *tanto
en su forma final como durante su elaboracin+, mediante un proceso apoyado por m7todos y
herramientas.
8 continuacin nos enfocaremos en el proceso necesario para elaborar un producto de software.
El proceso de desarrollo del software
Un proceso de desarrollo de software tiene como propsito la produccin eficaz y eficiente de un producto
software que re,na los requisitos del cliente. Hicho proceso, en t7rminos lobales se muestra en la <iura 0
!6#. Este proceso es intensamente intelectual, afectado por la creatividad y Auicio de las personas
involucradas !J#. 8unque un proyecto de desarrollo de software es equiparable en muchos aspectos a
cualquier otro proyecto de inenier(a, en el desarrollo de software hay una serie de desaf(os adicionales,
relativos esencialmente a la naturaleza del producto obtenido. 8 continuacin se e%plican alunas
particularidades asociadas al desarrollo de software y que influyen en su proceso de construccin.
Un producto software en s( es compleAo, es prcticamente inviable conseuir un "CC3 de confiabilidad de
un prorama por pequeIo que sea. E%iste una inmensa combinacin de factores que impiden una
verificacin e%haustiva de las todas posibles situaciones de eAecucin que se puedan presentar *entradas,
valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el
hardware sobre el cual se eAecuta, etc.+.
Un producto software es intanible y por lo eneral muy abstracto, esto dificulta la definicin del producto y
sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que
los requisitos sean dif(ciles de consolidar tempranamente. 8s(, los cambios en los requisitos son
inevitables, no slo despu7s de entreado en producto sino tambi7n durante el proceso de desarrollo.
D E.Letelier 0
8dems, de las dos anteriores, siempre puede seIalarse la inmadurez de la inenier(a del software como
disciplina, Austificada por su corta vida comparada con otras disciplinas de la inenier(a. Sin embaro, esto
no es ms que un in,til consuelo.
Requisitos nuevos
o modificados
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software
Requisitos nuevos
o modificados
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software
"igura ($ proceso de desarrollo de software%
El proceso de desarrollo de software no es ,nico. )o e%iste un proceso de software universal que sea
efectivo para todos los conte%tos de proyectos de desarrollo. Hebido a esta diversidad, es dif(cil
automatizar todo un proceso de desarrollo de software.
8 pesar de la variedad de propuestas de proceso de software, e%iste un conAunto de actividades
fundamentales que se encuentran presentes en todos ellos !J#$
". Especificacin de software$ Se debe definir la funcionalidad y restricciones operacionales que debe
cumplir el software.
0. Diseo e Implementacin$ Se diseIa y construye el software de acuerdo a la especificacin.
6. Validacin$ El software debe validarse, para aseurar que cumpla con lo que quiere el cliente.
J. Evolucin$ El software debe evolucionar, para adaptarse a las necesidades del cliente.
8dems de estas actividades fundamentales, Eressman !"# menciona un conAunto de &actividades
protectoras', que se aplican a lo laro de todo el proceso del software. Ellas se seIalan a continuacin$
Seuimiento y control de proyecto de software.
;evisiones t7cnicas formales.
/arant(a de calidad del software.
/estin de confiuracin del software.
Ereparacin y produccin de documentos.
/estin de reutilizacin.
Kediciones.
/estin de riesos.
Eressman !"# caracteriza un proceso de desarrollo de software como se muestra en la <iura 6. Los
elementos involucrados se describen a continuacin$
Un marco comn del proceso, definiendo un pequeIo n,mero de actividades del marco de trabaAo
que son aplicables a todos los proyectos de software, con independencia del tamaIo o compleAidad.
Un conjunto de tareas, cada uno es una coleccin de tareas de inenier(a del software, hitos de
proyectos, entreas y productos de trabaAo del software, y puntos de arant(a de calidad, que permiten
que las actividades del marco de trabaAo se adapten a las caracter(sticas del proyecto de software y los
requisitos del equipo del proyecto.
Las actividades de proteccin, tales como arant(a de calidad del software, estin de confiuracin
del software y medicin, abarcan el modelo del proceso. Las actividades de proteccin son
independientes de cualquier actividad del marco de trabaAo y aparecen durante todo el proceso.
D E.Letelier 6
"igura )$ Elementos del proceso del software
4tra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es
establecer las relaciones entre elementos que permitan responder uin debe hacer u, !u"ndo y
!mo debe hacerlo !5#.
"igura *$ Relacin entre elementos del proceso del software
En la <iura J se muestran los elementos de un proceso de desarrollo de software y sus relaciones. 8s( las
interroantes se responden de la siuiente forma$
uin# Las Eersonas participantes en el proyecto de desarrollo desempeIando uno o ms ;oles
espec(ficos.
u# Un 8rtefacto
6
es producido por un ;ol en una de sus 8ctividades. Los 8rtefactos se especifican
utilizando )otaciones espec(ficas. Las Lerramientas apoyan la elaboracin de 8rtefactos soportando
ciertas )otaciones.
!mo $ !u"ndo# Las 8ctividades son una serie de pasos que lleva a cabo un ;ol durante el proceso de
desarrollo. El avance del proyecto est controlado mediante hitos que establecen un determinado estado
de terminacin de ciertos 8rtefactos.
6
Un artefacto es una pieza de informacin que *"+ es producida, modificada o usada por el proceso, *0+ define un rea de
responsabilidad para un rol y *6+ est suAeta a control de versiones. Un artefacto puede ser un modelo, un elemento de modelo o un
documento.
D E.Letelier J
La composicin y sincron(a de las actividades est basada en un conAunto de Erincipios y Ercticas. Las
Ercticas y Erincipios enfatizan ciertas actividades yBo la forma como deben realizarse, por eAemplo$
desarrollar iterativamente, estionar requisitos, desarrollo basado en componentes, modelar visualmente,
verificar continuamente la calidad, estionar los cambios, etc.
%odelos de proceso software
Sommerville !J# define modelo de proceso de software como &Una representacin simplificada de un
proceso de software, representada desde una perspectiva espec(fica. Eor su naturaleza los modelos son
simplificados, por lo tanto un modelo de procesos del software es una abstraccin de un proceso real.'
Los modelos en7ricos no son descripciones definitivas de procesos de softwareG sin embaro, son
abstracciones ,tiles que pueden ser utilizadas para e%plicar diferentes enfoques del desarrollo de software.
Kodelos que se van a discutir a continuacin$
-odificar y correir
Kodelo en cascada
Hesarrollo evolutivo
Hesarrollo formal de sistemas
Hesarrollo basado en reutilizacin
Hesarrollo incremental
Hesarrollo en espiral
!odificar $ corre&ir '!ode(and()i*+
Este es el modelo bsico utilizado en los inicios del desarrollo de software. -ontiene dos pasos$
Escribir cdio.
-orreir problemas en el cdio.
Se trata de primero implementar alo de cdio y lueo pensar acerca de requisitos, diseIo, validacin, y
mantenimiento.
Este modelo tiene tres problemas principales !M#$
Hespu7s de un n,mero de correcciones, el cdio puede tener una muy mala estructura, hace que
los arrelos sean muy costosos.
<recuentemente, a,n el software bien diseIado, no se aAusta a las necesidades del usuario, por lo
que es rechazado o su reconstruccin es muy cara.
El cdio es dif(cil de reparar por su pobre preparacin para probar y modificar.
%odelo en cascada
El primer modelo de desarrollo de software que se public se deriv de otros procesos de inenier(a !9#.
Nste toma las actividades fundamentales del proceso de especificacin, desarrollo, validacin y evolucin y
las representa como fases separadas del proceso.
El modelo en cascada consta de las siuientes fases$
". Hefinicin de los requisitos$ Los servicios, restricciones y obAetivos son establecidos con los
usuarios del sistema. Se busca hacer esta definicin en detalle.
0. HiseIo de software$ Se particiona el sistema en sistemas de software o hardware. Se establece la
arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los
componentes del sistema.
6. .mplementacin y pruebas unitarias$ -onstruccin de los mdulos y unidades de software. Se
realizan pruebas de cada unidad.
D E.Letelier 5
J. .nteracin y pruebas del sistema$ Se interan todas las unidades. Se prueban en conAunto. Se
entrea el conAunto probado al cliente.
5. 4peracin y mantenimiento$ /eneralmente es la fase ms lara. El sistema es puesto en marcha y
se realiza la correccin de errores descubiertos. Se realizan meAoras de implementacin. Se
identifican nuevos requisitos.
La interaccin entre fases puede observarse en la <iura 5. -ada fase tiene como resultado documentos
que deben ser aprobados por el usuario.
Una fase no comienza hasta que termine la fase anterior y eneralmente se incluye la correccin de los
problemas encontrados en fases previas.
"igura +$ ,odelo de desarrollo en cascada%
En la prctica, este modelo no es lineal, e involucra varias iteraciones e interaccin entre las distintas fases
de desarrollo. 8lunos problemas que se observan en el modelo de cascada son$
Las iteraciones son costosas e implican rehacer trabaAo debido a la produccin y aprobacin de
documentos.
8unque son pocas iteraciones, es normal conelar parte del desarrollo y continuar con las siuientes
fases.
Los problemas se deAan para su posterior resolucin, lo que lleva a que estos sean inorados o
correidos de una forma poco eleante.
E%iste una alta probabilidad de que el software no cumpla con los requisitos del usuario por el laro
tiempo de entrea del producto.
Es infle%ible a la hora de evolucionar para incorporar nuevos requisitos. Es dif(cil responder a
cambios en los requisitos.
Este modelo slo debe usarse si se entienden a plenitud los requisitos. 8,n se utiliza como parte de
proyectos randes.
Desarrollo evolutivo
La idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial, e%ponerla a los
comentarios del usuario, refinarla en ) versiones hasta que se desarrolle el sistema adecuado. En la <iura
2 se observa cmo las actividades concurrentes$ especificacin, desarrollo y validacin, se realizan durante
el desarrollo de las versiones hasta llear al producto final.
Una ventaAa de este modelo es que se obtiene una rpida realimentacin del usuario, ya que las
actividades de especificacin, desarrollo y pruebas se eAecutan en cada iteracin.
D E.Letelier 2
"igura -$ ,odelo de desarrollo e.oluti.o%
E%isten dos tipos de desarrollo evolutivo$
Hesarrollo E%ploratorio$ El obAetivo de este enfoque es e%plorar con el usuario los requisitos hasta
llear a un sistema final. El desarrollo comienza con las partes que se tiene ms claras. El sistema
evoluciona conforme se aIaden nuevas caracter(sticas propuestas por el usuario.
Enfoque utilizando prototipos$ El obAetivo es entender los requisitos del usuario y trabaAar para
meAorar la calidad de los requisitos. 8 diferencia del desarrollo e%ploratorio, se comienza por definir
los requisitos que no estn claros para el usuario y se utiliza un prototipo para e%perimentar con
ellos. El prototipo ayuda a terminar de definir estos requisitos.
Entre los puntos favorables de este modelo estn$
La especificacin puede desarrollarse de forma creciente.
Los usuarios y desarrolladores loran un meAor entendimiento del sistema. Esto se refleAa en una
meAora de la calidad del software.
Es ms efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del
cliente.
Hesde una perspectiva de inenier(a y administracin se identifican los siuientes problemas$
Eroceso no Oisible$ Los administradores necesitan entreas para medir el proreso. Si el sistema se
necesita desarrollar rpido, no es efectivo producir documentos que refleAen cada versin del
sistema.
Sistemas pobremente estructurados$ Los cambios continuos pueden ser perAudiciales para la
estructura del software haciendo costoso el mantenimiento.
Se requieren t7cnicas y herramientas$ Eara el rpido desarrollo se necesitan herramientas que
pueden ser incompatibles con otras o que poca ente sabe utilizar.
Este modelo es efectivo en proyectos pequeIos *menos de "CC.CCC l(neas de cdio+ o medianos *hasta
5CC.CCC l(neas de cdio+ con poco tiempo para su desarrollo y sin enerar documentacin para cada
versin.
Eara proyectos laros es meAor combinar lo meAor del modelo de cascada y evolutivo$ se puede hacer un
prototipo lobal del sistema y posteriormente reimplementarlo con un acercamiento ms estructurado. Los
subsistemas con requisitos bien definidos y estables se pueden proramar utilizando cascada y la interfaz
de usuario se puede especificar utilizando un enfoque e%ploratorio.
D E.Letelier M
Desarrollo formal de sistemas
Este modelo se basa en transformaciones formales de los requisitos hasta llear a un prorama eAecutable.
"igura /$ 0aradigma de programacin automtica%
La <iura M *obtenida desde !0C#+ ilustra un paradima ideal de proramacin automtica. Se distinuen
dos fases lobales$ especificacin *incluyendo validacin+ y transformacin. Las caracter(sticas principales
de este paradima son$ la especificacin es formal y eAecutable constituye el primer prototipo del sistema+,
la especificacin es validada mediante prototipacin. Eosteriormente, a trav7s de transformaciones
formales la especificacin se convierte en la implementacin del sistema, en el ,ltimo paso de
transformacin se obtiene una implementacin en un lenuaAe de proramacin determinado. , el
mantenimiento se realiza sobre la especificacin *no sobre el cdio fuente+, la documentacin es
enerada automticamente y el mantenimiento es realizado por repeticin del proceso *no mediante
parches sobre la implementacin+.
4bservaciones sobre el desarrollo formal de sistemas$
Eermite demostrar la correccin del sistema durante el proceso de transformacin. 8s(, las pruebas
que verifican la correspondencia con la especificacin no son necesarias.
Es atractivo sobre todo para sistemas donde hay requisitos de seuridad y confiabilidad importantes.
;equiere desarrolladores especializados y e%perimentados en este proceso para llevarse a cabo.
Desarrollo ,asado en reutili-acin
-omo su nombre lo indica, es un modelo fuertemente orientado a la reutilizacin. Este modelo consta de J
fases ilustradas en la <iura 1. 8 continuacin se describe cada fase$
". 8nlisis de componentes$ Se determina qu7 componentes pueden ser utilizados para el sistema en
cuestin. -asi siempre hay que hacer aAustes para adecuarlos.
0. Kodificacin de requisitos$ Se adaptan *en lo posible+ los requisitos para concordar con los
componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que
seuir buscando componentes ms adecuados *fase "+.
6. HiseIo del sistema con reutilizacin$ Se diseIa o reutiliza el marco de trabaAo para el sistema. Se
debe tener en cuenta los componentes localizados en la fase 0 para diseIar o determinar este
marco.
J. Hesarrollo e interacin$ El software que no puede comprarse, se desarrolla. Se interan los
componentes y subsistemas. La interacin es parte del desarrollo en luar de una actividad
separada.
D E.Letelier 9
Las ventaAas de este modelo son$
Hisminuye el costo y esfuerzo de desarrollo.
;educe el tiempo de entrea.
Hisminuye los riesos durante el desarrollo.
"igura 1$ 2esarrollo basado en reutili3acin de componentes
HesventaAas de este modelo$
Los &compromisos' en los requisitos son inevitables, por lo cual puede que el software no cumpla las
e%pectativas del cliente.
Las actualizaciones de los componentes adquiridos no estn en manos de los desarrolladores del
sistema.
Procesos iterativos
8 continuacin se e%pondrn dos enfoques h(bridos, especialmente diseIados para el soporte de las
iteraciones$
Hesarrollo .ncremental.
Hesarrollo en Espiral.
Desarrollo incremental
Kills !1# suiri el enfoque incremental de desarrollo como una forma de reducir la repeticin del trabaAo en
el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir
e%periencia con el sistema *ver <iura "C+. Es una combinacin del Kodelo de -ascada y Kodelo
Evolutivo.
;educe el rehacer trabaAo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones
hasta tener e%periencia en el sistema.
Hurante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo
del conocimiento que se tena sobre los requisitos a implementar. Si se tiene un buen conocimiento, se
puede optar por cascada, si es dudoso, evolutivo.
"igura 4$ ,odelo de desarrollo iterati.o incremental%
D E.Letelier 1
Entre las ventaAas del modelo incremental se encuentran$
Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Eueden empezar a usarlo
desde el primer incremento.
Los clientes pueden aclarar los requisitos que no tenan claros conforme ven las entreas del
sistema.
Se disminuye el rieso de fracaso de todo el proyecto, ya que se puede distribuir en cada
incremento.
Las partes ms importantes del sistema son entreadas primero, por lo cual se realizan ms pruebas
en estos mdulos y se disminuye el rieso de fallos.
8lunas de las desventaAas identificadas para este modelo son$
-ada incremento debe ser pequeIo para limitar el rieso *menos de 0C.CCC l(neas+.
-ada incremento debe aumentar la funcionalidad.
Es dif(cil establecer las correspondencias de los requisitos contra los incrementos.
Es dif(cil detectar las unidades o servicios en7ricos para todo el sistema.

Desarrollo en espiral
El modelo de desarrollo en espiral *ver <iura ""+ es actualmente uno de los ms conocidos y fue
propuesto por =oehm !M#. El ciclo de desarrollo se representa como una espiral, en luar de una serie de
actividades sucesivas con retrospectiva de una actividad a otra.
-ada ciclo de desarrollo se divide en cuatro fases$
". Hefinicin de obAetivos$ Se definen los obAetivos. Se definen las restricciones del proceso y del
producto. Se realiza un diseIo detallado del plan administrativo. Se identifican los riesos y se
elaboran estrateias alternativas dependiendo de estos.
0. Evaluacin y reduccin de riesos$ Se realiza un anlisis detallado de cada rieso identificado.
Eueden desarrollarse prototipos para disminuir el rieso de requisitos dudosos. Se llevan a cabo los
pasos para reducir los riesos.
6. Hesarrollo y validacin$ Se escoe el modelo de desarrollo despu7s de la evaluacin del rieso. El
modelo que se utilizar *cascada, sistemas formales, evolutivo, etc.+ depende del rieso identificado
para esa fase.
J. Elanificacin$ Se determina si continuar con otro ciclo. Se planea la siuiente fase del proyecto.
Este modelo a diferencia de los otros toma en consideracin e%pl(citamente el rieso, esta es una actividad
importante en la administracin del proyecto.
El ciclo de vida inicia con la definicin de los obAetivos. He acuerdo a las restricciones se determinan
distintas alternativas. Se identifican los riesos al sopesar los obAetivos contra las alternativas. Se eval,an
los riesos con actividades como anlisis detallado, simulacin, prototipos, etc. Se desarrolla un poco el
sistema. Se planifica la siuiente fase.
D E.Letelier "C
"igura #5$ ,odelo de desarrollo en Espiral
.!u"l es el modelo de proceso m"s adecuado/
-ada proyecto de software requiere de una forma de particular de abordar el problema. Las propuestas
comerciales y acad7micas actuales promueven procesos iterativos, donde en cada iteracin puede
utilizarse uno u otro modelo de proceso, considerando un conAunto de criterios *Eor eAemplo$ rado de
definicin de requisitos, tamaIo del proyecto, riesos identificados, entre otros+.
En la :abla " se e%pone un cuadro comparativo de acuerdo con alunos criterios bsicos para la seleccin
de un modelo de proceso !"C#, la medida utilizada indica el nivel de efectividad del modelo de proceso de
acuerdo al criterio *Eor eAemplo$ El modelo -ascada responde con un nivel de efectividad =aAo cuando los
;equisitos y arquitectura no estn predefinidos +$
D E.Letelier ""
%odelo de
proceso
)unciona con
re0uisitos $
ar0uitectura no
predefinidos
Produce software
altamente fia,le
1estin de
ries&os
Permite
correcciones
so,re la marcha
Visin del
pro&reso por
el !liente $ el
2efe del
pro$ecto
!odificar $
corre&ir
=aAo =aAo =aAo 8lto Kedio
!ascada =aAo 8lto =aAo =aAo =aAo

Evolutivo
e*ploratorio
Kedio o 8lto Kedio o 8lto Kedio Kedio o 8lto Kedio o 8lto
Evolutivo
prototipado
8lto Kedio Kedio 8lto 8lto
Desarrollo formal
de sistemas
=aAo 8lto =aAo a Kedio =aAo =aAo
Desarrollo
orientado a
reutili-acin
Kedio =aAo a 8lto =aAo a Kedio 8lto 8lto
Incremental =aAo 8lto Kedio =aAo =aAo
Espiral 8lto 8lto 8lto Kedio Kedio
Tabla #$ Comparacin entre modelos de proceso de software%
D E.Letelier "0
%etodolo&3as para desarrollo de software
Un proceso de software detallado y completo suele denominarse &Ketodolo(a'. Las metodolo(as se basan
en una combinacin de los modelos de proceso en7ricos *cascada, evolutivo, incremental, etc.+.
8dicionalmente una metodolo(a deber(a definir con precisin los artefactos, roles y actividades
involucrados, Aunto con prcticas y t7cnicas recomendadas, u(as de adaptacin de la metodolo(a al
proyecto, u(as para uso de herramientas de apoyo, etc. Labitualmente se utiliza el t7rmino &m7todo' para
referirse a t7cnicas, notaciones y u(as asociadas, que son aplicables a una *o alunas+ actividades del
proceso de desarrollo, por eAemplo, suele hablarse de m7todos de anlisis yBo diseIo.
La comparacin yBo clasificacin de metodolo(as no es una tarea sencilla debido a la diversidad de
propuestas y diferencias en el rado de detalle, informacin disponible y alcance de cada una de ellas. 8
randes rasos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos
en actividades de anlisis y diseIo, podemos clasificar las metodolo(as en dos rupos$ Ketodolo(as
Estructuradas y Ketodolo(as 4rientadas a 4bAetos. Eor otra parte, considerando su filosof(a de desarrollo,
aquellas metodolo(as con mayor 7nfasis en la planificacin y control del proyecto, en especificacin
precisa de requisitos y modelado, reciben el apelativo de Ketodolo(as :radicionales *o peyorativamente
denominada Ketodolo(as Eesadas, o Eeso Eesado+. 4tras metodolo(as, denominadas Ketodolo(as
Piles, estn ms orientadas a la eneracin de cdio con ciclos muy cortos de desarrollo, se dirien a
equipos de desarrollo pequeIos, hacen especial hincapi7 en aspectos humanos asociados al trabaAo en
equipo e involucran activamente al cliente en el proceso. 8 continuacin se revisan brevemente cada una
de estas cateor(as de metodolo(as.
%etodolo&3as estructuradas
Los m7todos estructurados comenzaron a desarrollarse a fines de los MCQs con la Eroramacin
Estructurada, lueo a mediados de los MCQs aparecieron t7cnicas para el HiseIo *por eAemplo$ el diarama
de Estructura+ primero y posteriormente para el 8nlisis *por eAemplo$ Hiaramas de <luAo de Hatos+. Estas
metodolo(as son particularmente apropiadas en proyectos que utilizan para la implementacin lenuaAes
de 6ra y Jta eneracin.
EAemplos de metodolo(as estructuradas de mbito ubernamental$ KE;.SE
J
*<rancia+, KN:;.-8
5
*EspaIa+, SS8HK
2
*;eino Unido+. EAemplos de propuestas de m7todos estructurados en el mbito
acad7mico$ /ane R Sarson
M
, Sard R Kellor
9
, Tourdon R HeKarco
1
e .nformation Enineerin
"C
.
%etodolo&3as orientadas a o,jetos
Su historia va unida a la evolucin de los lenuaAes de proramacin orientada a obAeto, los ms
representativos$ a fines de los 2CQs S.KUL8, a fines de los MCQs SmalltalUF9C, la primera versin de -VV por
=Aarne Stroustrup en "19" y actualmente Wava
""
o -X de Kicrosoft. 8 fines de los 9CQs comenzaron a
consolidarse alunos m7todos 4rientadas a 4bAeto.
En "115 =ooch y ;umbauh proponen el K7todo Unificado con la ambiciosa idea de conseuir una
unificacin de sus m7todos y notaciones, que posteriormente se reorienta a un obAetivo ms modesto, para
dar luar al Unified Kodelin Lanuae *UKL+
"0
, la notacin 44 ms popular en la actualidad.
8lunos m7todos 44 con notaciones predecesoras de UKL son$ 448H *=ooch+, 44SE *Wacobson+, -oad
R Tourdon, Shaler R Kellor y 4K: *;umbauh+.
8lunas metodolo(as orientadas a obAetos que utilizan la notacin UKL son$ ;ational Unified Erocess
*;UE+
"6
, 4EE)
"J
, KN:;.-8 *que tambi7n soporta la notacin estructurada+.
J
http$BBperso.clubFinternet.frBbrouardfBS/=H;merise.htm *M.5.0CC0+
5
http$BBwww.map.esBcsiBmetrica6B *M.5.0CC6+
2
http$BBwww.comp.lam.ac.uUBpaesBstaffBtdhutchinsBchapterJ.html *M.5.0CC6+
M
http$BBportal.newman.wa.edu.auBtechnoloyB"0infsysBhtmlBdfdnotes.doc *01.9.0CC6+
9
http$BBwww.yourdon.comBbooUsBcoolbooUsBnotesBwardmellor.html *01.9.0CC6+
1
http$BBwombat.doc.ic.ac.uUBfoldocBfoldoc.ci?Tourdon30<Hemarco *01.9.0CC6+
"C
http$BBantthead.comB/anttheadBprocessBprocessKainB","091,0F"0CC1F0,CC.html *01.9.0CC6+
""
http$BBAava.sun.comB *M.5.0CC6+
"0
http$BBwww.uml.orB *M.5.0CC6+
"6
http$BBwww.rational.comBproductsBrupBinde%.Asp *M.5.0CC6+
"J
http$BBwww.open.or.auB *"M.1.0CC6+
D E.Letelier "6
%etodolo&3as tradicionales 'no "&iles+
Las metodolo(as no iles son aquellas que estn uiadas por una fuerte planificacin durante todo el
proceso de desarrolloG llamadas tambi7n metodolo(as tradicionales o clsicas, donde se realiza una
intensa etapa de anlisis y diseIo antes de la construccin del sistema.
:odas las propuestas metodolicas antes indicadas pueden considerarse como metodolo(as
tradicionales. 8unque en el caso particular de ;UE, por el especial 7nfasis que presenta en cuanto a su
adaptacin a las condiciones del proyecto *mediante su confiuracin previa a aplicarse+, realizando una
confiuracin adecuada, podr(a considerarse Pil.
%etodolo&3as "&iles
Un proceso es il cuando el desarrollo de software es incremental *entreas pequeIas de software, con
ciclos rpidos+, cooperativo *cliente y desarrolladores trabaAan Auntos constantemente con una cercana
comunicacin+, sencillo *el m7todo en s( mismo es fcil de aprender y modificar, bien documentado+, y
adapta,le *permite realizar cambios de ,ltimo momento+ !""#.
Entre las metodolo(as iles identificadas en !""#$
E%treme Erorammin !2#.
Scrum *!"0#, !"6#+.
<amilia de Ketodolo(as -rystal !"J#.
<eature Hriven Hevelopment !"5#.
Eroceso Unificado ;ational, una confiuracin il *!"2#+.
Hynamic Systems Hevelopment Kethod !"M#.
8daptive Software Hevelopment !"9#.
4pen Source Software Hevelopment !"1#.
Referencias
!"# Eressman, ;, .nenier(a del Software$ Un enfoque prctico, Kc/raw Lill "11M.
!0# )aur E., ;andell =., Software Enineerin$ 8 ;eport on a -onference Sponsored by the )8:4 Scienc,
"121.
!6# Wacaboson, .., =ooch, /., ;umbauh W., El Eroceso Unificado de Hesarrollo de Software, 8ddison
Sesley 0CCC.
!J# Sommerville, .., .nenier(a de Software, Eearson Educacin, 0CC0.
!5# Letelier, E., Eroyecto Hocente e .nvestiador, HS.-, 0CC6.
!2# =ecU, Y., Una e%plicacin de la Eroramacin E%trema. 8ceptar el cambio, Eearson Educacin, 0CCC.
!M# =oehm, =. S., 8 Spiral Kodel of Software Hevelpment and Enhancement, .EEE -omputer ,"199.
!9# ;oyce, S., Kanain the developmento of lare software systems$ concepts and technique, .EEE
Sestcon, "1MC.
!1# Kills, L., 4Z)eill, H., :he Kanaement of Software Enineerin, .=K Systems, "19C.
!"C# Laboratorio .n. Soft., .nenier(a de software 0, Hepartamento de .nformtica, 0CC0.
!""# 8brahamsson, E., Salo, 4., ;onUainen, W., 8ile Software Hevelopment Kethods. ;eview and 8nalysis,
O::, 0CC0.
!"0# Schwaber, Y., Scrum Hevelopment Erocess. SorUshop on =usiness 4bAect Hesin and
.mplementation, 44ESL8Z15, "115.
!"6# Schwaber, Y., =eedle, K., 8ile Software Hevelopment Sith Scrum, Erentice Lall, 0CC0.
!"J# -ocUburn, 8., 8ile Software Hevelopment, 8ddison Sesley, 0CC0.
!"5# Ealmer, S. ;., <elsin, W. K., 8 Eractical /uide to <eature Hriven Hevelopment, Erentice Lall, 0CC0.
!"2# Yruchten, E., 8 ;ational Hevelopment Erocess, -rosstalU, "112.
!"M# Stapleton, W., Hynamic Systems Hevelopment Kethod F :he Kethod in Eractice, 8ddison Sesley, "11M.
!"9# Lihsmith, W., 8daptive Software Hevelopment$ 8 -ollaborative 8pproach, Horset Louse, 0CCC.
!"1# 4Z;eilly, :., Lessons from 4pen Source Software Hevelopment, 8-K, "111.
!0C# =alzer ;. ' #+ 6ear 0erspecti.e on 'utomatic 0rogramming. .EEE :ransactions on Software
Enineerin, vol."", n,m."", pinas "05MF"029, )oviembre "195.
D E.Letelier "J