Unidad I

tema 2
ciclo de vida, ciclo de desarrollo, enfoques y orientaciones
historia del computador
definicin y descripciones del tipo de mtodos y trminos
ventajas y desventajas

Otros cursos y tutoriales: comercio electrnico, WAP, Webmaster

Pgina principal del grupo GeNeura
Tcnicas heursticas de resolucin de problemas: computacin evolutiva y redes neuronales
J. J. Merelo
1 Introduccin: problemas de bsqueda y tcnicas tradicionales
Si un problema est formulado de forma unvoca, y el espacio de todas las soluciones posibles es
conocido, un mtodo de bsqueda trata de encontrar las soluciones o soluciones que satisfagan el
enunciado del problema. Dicho as parece una tautologa, pero no todos los problemas son problemas
de bsqueda, ni todos los espacios de bsqueda se pueden definir tambin de forma unvoca.
Pero si resulta que efectivamente, un problema se puede efectuar como problema de bsqueda, en
muchos casos se puede reducir a un problema de hallar un mximo o mnimo, o sea, un ptimo. Slo va
a funcionar esto en el caso de que se pueda calcular la bondad de una solucin: la solucin del
problema ser aquella, o aquellas, que optimicen una funcin de bondad, ajuste, evaluacin o fitness;
en muchos casos, por lo tanto, un problema de bsqueda se puede reducir a un problema de
optimizacin (maximizacin o minimizacin). No siempre es as, pero cuando sucede hay que
congratularse y celebrarlo adecuadamente. La mayor parte de los problemas con los que trataremos en
este tutorial sern problemas de optimizacin.
1.1 Modelizacin de un problema
Generalmente, para resolver un problema del mundo real, no se trabaja directamente con el mundo real.
Para resolver el problema del viajante no se compra uno una Kangoo y se la a hacerse kilmetros, sino
que se hace un modelo del problema. En ese modelo, se extraen las caractersticas fundamentales del
mismo (como por ejemplo, la conocida simetra esfrica del caballo), y se eliminan todas las que son
accesorias, o que no tienen tanta importancia en el desarrollo del problema (o simplemente que nos
estorban). Cuando hemos tratado de resolver el problema del viajante de comercio, hemos tenido en
cuenta exclusivamente la distancia entre ciudades, sin considerar, por ejemplo, que para ir de una
ciudad a otra puede ser obligatorio pasar por una tercera, el estado de las carreteras, los diferentes
consumos de gasolina segn el trfico; ms o menos, viene a ser un problema de bruja con escoba
viajante de comercio, que recorre los espacios entre ciudades usando pasillos areos de escoba.

En otros casos, sobre todo si se trata de problemas puramente computacionales, el modelo se acerca
bastante ms al problema real. En un problema de colocacin de clases en un Instituto de enseanza
media, por ejemplo, todos o casi todos los factores pueden ser tenidos en cuenta: distancia entre las
clases, disponibilidad de los profesores, mximo nmero de horas por profesor, y el modelo se acercar
bastante a la realidad.
En todo caso, slo se puede resolver un problema si se tiene un modelo del mismo; la solucin al
problema real ser tanto ms adecuada cuanto ms cercano sea el modelo al problema real, pero, en
todo caso, la solucin a un problema lo es slo en el sentido que es una solucin al modelo del
problema.
En algunos casos, modelar el problema supone, de alguna forma, simplificarlo; incluso en casos en el
que el problema est formulado computacionalmente de forma completa, hace falta hacer
aproximaciones para hacer su resolucin ms simple usando un mtodo determinado. Una funcin no
diferenciable (como la funcin escaln de Heavyside) puede ser aproximada, por ejemplo, por una
funcin diferenciable con el objeto de aplicarle soluciones (como las que vamos o ver ms adelante)
que necesiten esa precondicin.
Siempre hay que tener en cuenta, sin embargo, que modelos diferentes del problema darn soluciones
diferentes del mismo. Pero siempre encontrar una solucin aproximada a un modelo exacto ser mejor
que encontrar una solucin exacta a un modelo aproximado. O casi siempre.

1.4 Componentes bsicos de la solucin a un problema

Como ya se sabe que se va a trabajar con un modelo de la solucin del problema, no con la solucin en
s, y generalmente con ese modelo se va a trabajar dentro del ordenador, hay que dar con la
representacin del problema ms adecuada, es decir, la estructura de datos que mejor se adapte a ese
modelo. Esto es tanto un problema de diseo como un problema de implementacin: se escoger la
estructura de datos ms adecuada para el mtodo de solucin del problema, y la estructura de datos ms
adecuada para el lenguaje y entorno sobre el que se est trabajando. Aunque inicialmente pueda parecer
que el paso de modelo a representacin es directo, no siempre es as. La representacin representa, casi
siempre, una simplificacin del modelo; por ejemplo, en el momento que se trabaje con nmeros de
coma flotante en el ordenador para representar nmeros reales ya estamos limitando la posible
precisin de la solucin; en la prctica, la precisin se adapta al problema, pero, en algunos casos, esta
falta de precisin puede introducir artefactos en la posible solucin.
En la mayor parte de los casos, la solucin al TSP se representa como una permutacin de una serie de
smbolos nicos, tantos como ciudades. Por ejemplo, si hay suertecilla y trabajamos con menos de
veintitantas ciudades, se puede usar el alfabeto, y podemos usar una cadena de caracteres ASCII para
representar la solucin (tambin se puede subir un punto en la escala de geekidad y usar una cadena de
caracteres UNICODE, que necesitan un par de bytes cada uno y se pueden usar ms ciudades). Si hay
ms, tendremos que usar algn otro tipo de estructura, como un vector o una lista de enteros. Se trata,
mayormente, de una decisin de implementacin, pero, en algunos casos, usar una representacin
inadecuada puede hacer ineficiente la resolucin de un problema.
Algunos mtodos de resolucin pueden exigir un tipo de representacin determinada, all ellos. En

general, un buen mtodo de resolucin debera ser capaz de manejar cualquier tipo de representacin.
Sobre esta representacin del problema, se calcula la funcin de evaluacin; lo que se pretende
habitualmente con la funcin de evaluacin es que su valor sea mximo (o mnimo) cuando se haya
alcanzado el objetivo del problema, a veces es denomina, por eso, funcin objetivo, de adecuacin, o,
tambin, usando el trmino en ingls, fitness. Y aunque la funcin de evaluacin viene dada por el
objetivo del problema, en muchos casos la funcin se modifica para tener en cuenta restricciones,
multimodalidad, o bien simplemente una serie de artefactos introducidos por el mtodo de resolucin
del problema.
Puede suceder tambin que la funcin objetivo no est definida en todo el espacio de bsqueda del
problema: en problemas con restricciones, combinaciones de valores de las variables del problema o
bien valores de estas variables dan lugar a un valor invlido de la funcin de evaluacin. Estos casos se
manejan de muchas formas diferentes: sustituyendo la funcin objetivo por otra funcin en la que estas
regiones "no alcanzables" sean alcanzables, o asignando un valor numrico al incumplimiento de la
restriccin. Depender del mtodo de resolucin del problema, y, en todo caso, cada tcnica tiene un
grado de xito diferente.
A partir de esta funcin de objetivo, se define el problema de bsqueda de la forma siguiente:
Un problema de bsqueda (y, equivalentemente, un problema de optimizacin), consiste en, dado un
espacio de bsqueda S junto con su parte alcanzable F S, encontrar un x F, tal que eval(x)
eval(y) para todo y F.
Puesto as, parece fcil, no? Se parte de una solucin o soluciones iniciales, y se van cambiando esas
soluciones o generando otras nuevas hasta que se encuentre la solucin deseada. La cosa no es tan fcil,
pero, en todo caso, cabe llamar la atencin sobre el hecho de que todos los mtodos de resolucin de
problemas necesitan una factora de soluciones (una forma de generar soluciones nuevas) y un taller de
soluciones, que genere soluciones nuevas a partir de las existentes. Las primeras se suelen llamar
generadores de soluciones, y las segundas, operadores de variacin. No todos los mtodos usan las
segundas, en todo caso. Pero si se usan, es conveniente tener presente una definicin de la vecindad de
cada punto del espacio de bsqueda; los operadores de variacin convierten un punto del espacio de
bsqueda en otro de forma aleatoria o siguiendo algn criterio (por ejemplo, tomando slo los puntos
que sean mejores objetivamente que los anteriores). Este concepto de vecindad es necesario para que
los operadores acten de forma ms o menos local, usando en cierto modo la informacin ya existente
en la solucin para generar otra nueva; si un operador convierte una solucin en otra lejos de la
primera, equivale, en la prctica, a generar una solucin aleatoria.
Las factoras y talleres representan dos formas diferentes de moverse por el espacio de bsqueda: una
factora explora, puesto que genera puntos en zonas del espacio que previamente no tienen porqu
haber sido visitadas; los talleres tambin exploran, porque generan soluciones nuevas, pero al hacerlo
en la cercana de soluciones ya existentes, explotan estas soluciones, sacndoles todo el partido posible,
para obtener una solucin mejor. La mayor parte de los algoritmos de bsqueda tratan de establecer un
equilibrio entre explotacin y exploracin, aunque muchos de ellos se inclinan hacia una mayor
exploracin (aleatoriedad) o explotacin (determinismo).

1.5 Tcnicas clsicas de resolucin de problemas

No es que sea el espacio ms apropiado para describir un mogolln de tcnicas un subapartado de un

captulo; cada una de estas tcnicas tienen una larga historia, y han servido durante mucho tiempo para
resolver muchos problemas de optimizacin. Desgraciadamente, este no es el tema de este tutorial, as
que le dedicaremos un poco a cada una de ellas. En general, todos los mtodos de bsqueda se dividen,
a grandes rasgos, en mtodos globales y locales. Los mtodos globales tratan de encontrar el mximo
global de un problema, mientras que los locales se concentran en la vecindad de la solucin generada
inicialmente, y, por tanto, necesitan alguna tcnica adicional, como comienzos mltiples, para acercarse
al mximo global. En general, los mtodos locales no tienen ninguna garanta de que el mximo
encontrado sea global, ni una medida del error en que se incurre dando como bueno el mximo
encontrado; los globales s suelen tener una de las dos cosas, o las dos (o ninguna, pero los venden as).
Algunos mtodos hbridos combinan algoritmos de los dos tipos; los mtodos exhaustivos, sin
embargo, no degan que se les escape la solucin fcilmente.
Los mtodos se dividen tambin en aquellos que trabajan, a cada paso, sobre soluciones completas, y
aquellos que no tienen una solucin completa hasta que han terminado. En el primer caso, normalmente
se procede de forma iterativa a mejorar una solucin; mientras que en el segundo, se puede ir acotando
la solucin, o bien asignndole valores a cada una de las variables de la solucin hasta que se asigna la
solucin final.
1.5.1 Bsqueda exhaustiva
Buscaminas, un ejemplo de problema que se puede resolver por bsqueda exhaustiva
En algunos problemas donde el espacio de bsqueda es suficientemente pequeo y enumerable, se
pueden usar mtodos de bsqueda exhaustiva o enumerativas: se examinan una por una todas las
soluciones posibles, y se da por buena aquella que tenga el mximo valor de la funcion objetivo.
En el caso del juego del mastermind, se enumeran una por una todas las combinaciones posibles de
colores para una longitud determinada, y se van tachando todas ellas que no cumplan las condiciones
puestas por el "orculo"; en cada caso, se juega aleatoriamente una de las soluciones que sea factible, y
se tachan las no factibles, con la ventaja de que no tienen porqu volver a aparecer en la bsqueda, y se
acota cada vez ms el espacio.
El problema con la bsqueda exhaustiva no slo es que no siempre sea factible, sino que su mal
comportamiento con respecto al aumento de tamao del espacio de bsqueda, y el hecho de que
necesite una cantidad de memoria de ordenador proporcional al tamao del problema, hace que no se
pueda aplicar en la mayor parte de los casos. Sin embargo, en algunos casos puede ser til; por
ejemplo, en la fase final de la resolucin del problema cuando el subespacio de bsqueda est
suficientemente acotado.
En todo caso, son problemas simples con relativamente pocos prerrequisitos: slo que el tamao del
espacio de bsqueda quepa en la memoria del ordenaodr; otros algoritmos, adems, tales como el
branch&bound o el A*, que elaboran una solucin completa a partir de una solucin parcial, necesitan
tambin una bsqueda exhaustiva. Y, con un poco de suerte, podemos usar tcnicas tales como el
backtracking para descartar partes del espacio de bsqueda que se van a recorrer.
1.5.2 Bsqueda local

Los algoritmos de bsqueda local parten de una solucin inicial, y, aplicndole operadores de
variacin, la van alterando; si la solucin alterada es mejor que la original, se acepta, si no lo es, se
vuelve a la inicial. El procedimiento se repite hasta que no se consigue mejora en la solucin.
Los procedimientos de bsqueda local ms usados son los basados en el gradiente: en este caso, el
operador de variacin selecciona una nueva solucin teniendo en cuenta la derivada de la funcin que
se quiere optimizar en el punto, tratando de ascender o descender usando el gradiente hasta llegar a un
punto de inflexin donde no se puede obtener ninguna mejora adicional.
Hillclimbing
Estos procedimientos se suelen llamar de hillclimbing, o de escalado de colinas; el mayor truco en ellos
consiste en escoger correctamente el tamao de paso para ascender y el punto de inicio. Pero se trata de
algoritmos de bsqueda locales, y, como tales, slo van a encontrar el mximo local ms cercano al
punto de inicio. Esto se puede resolver usando una estrategia de multicomienzo, pero, en todo caso, no
te garantizan que se encuentre, o incluso de acerque uno, al mximo global. En todo caso, tiene la
ventaja de que, en cada iteracin del algoritmo, se tiene una solucin vlida, aunque no tiene porqu ser
la mejor.
En el caso del TSP, un procedimiento de bsqueca local se denomina 2-opt. Consiste en escoger una
permutacin inicial aleatoria, e ir probando con todas las posibles soluciones en la vecindad de esta,
entendiendo como vecindad el conjunto de todos los recorridos que pueden ser alcanzados
intercambiando dos caminos no adyacentes en el recorrido original. Un recorrido reemplaza al original
si es mejor; una vez que no se puede mejorar un recorrido, se considera ptimo y se da como solucin.
El mejor algoritmo de bsqueda local conocido para el recorrido del viajante es el llamado LinKernighan. Es una variacin del anterior, permitiendo el nmero de caminos a intercambiar en cada
iteracin variar; adems, en vez de tomar cualquier mejora, prueba varias y se queda con la mejora de
ms valor.
1.5.3 Mtodos que usan soluciones parciales
Estos mtodos van construyendo soluciones variable a variable, no obteniendo una solucin completa
al problema hasta que todas las variables han sido asignadas. Uno de los mtodos ms conocidos son
los algoritmos voraces o greedy, que funcionan de la forma siguiente: para cada variable, se asigna
aqul valor que maximice alguna funcin de utilidad.
En el caso del TSP, un algoritmo voraz comenzara con una ciudad elegida aleatoriamente, y elegira la
ciudad ms cercana a sta. Para esta segunda ciudad, elegira la ms cercana, y as sucesivamente. En
este caso, el problema estara simplemente parametrizado con la ciudad inicial elegida.
Los algoritmos voraces sustituyen un criterio de optimalidad global por un criterio en cada paso; no
siempre los dos se corresponden, y por tanto, no tienen porqu hallar el mximo global del problema.
Otros mtodos consisten en dividir el problema general en problemas ms simples, y hallar la solucin
a estos problemas ms simples; el mtodo se denomina divide y vencers; en algunos casos, la solucin
a un problema de orden n puede venir resolver a otro problema de orden n-1, tal como sucede, por
ejemplo en el conocido problema de las torres de Hanoi.

ejemplo branch and bound

Algunos mtodos consisten en ir descartando partes del espacio de bsqueda, con el objeto de acotar
cada vez ms la solucin al problema. El branch and bound. Este mtodo imagina el espacio de
bsqueda como un rbol de decisin; en cada paso del algoritmo, se toma la decisin de podar las
ramas del rbol que parezcan menos prometedoras.
Este mtodo procede de la forma siguiente: se establece una cota inferior a la posible solucin (o
superior, si se trata de minimizar). Se va siguiendo una rama del rbol, hasta que se encuentra que la
solucin parcial es menor que esa cuota; en ese caso, se descarta la rama completa.
En el caso del recorrido del viajante, supongamos que hemos establecido que la cota superior es 200
kms. Se establece un rbol de la forma siguiente: tomando una ruta entre dos ciudades, pongamos AB,
se establecen dos ramas para una posible solucin con y sin esa ruta; a partir de ah, se hace lo mismo
con el resto de las rutas. Se van recorriendo las ramas, y si se encuentra que la suma parcial de las rutas
supera los 200 kms, se elimina esa rama y ya no se sigue recorriendo.
Si se ha organizado el espacio de bsqueda en forma de rbol, puede resultar importante la ordenacin
de las ramas, porque si se consigue colocar las ramas "mejores" antes, el algoritmo ser capaz de
encontrar la solucin con ms rapidez. Algoritmos como el A* toman este tipo de enfoque. En este
algoritmo, se usa un mtodo mejor-primero para recorrer las ramas, y un mtodo heurstico para
estimar el coste de las ramas que quedan por recorrer. La principal diferencia con el mtodo anterior es
que se usan heursticas para estimar valores de las ramas restantes, en vez de valores exactos.
Estos mtodos se pueden extender tambin a problemas de optimizacin numrica, en cuyo caso daran
cotas entre las cuales se moveran las soluciones. Pero si el espacio de bsqueda no se puede enumerar
bien, o si existe un nmero de variables excesivo, este tipo de algoritmos no suelen funcionar bien.
1.5.4 Mtodos de bsqueda global
Los mtodos de bsqueda global tratan de escaparse de los mximos locales, explorando com ms
eficiencia el espacio de bsqueda. Generalmente, aaden algn componente aleatorio a la bsqueda, de
forma que, si se encuentra un mnimo local, se salte a otro punto del espacio de bsqueda, donde pueda
haber otro mximo, posiblemente global.
Uno de los ms conocidos es el recocimiento simulado, o simulated annealing. A grandes rasgos,
consiste en un procedimiento de ascenso de gradiente, pero tal que no siempre se escoge la mejor
solucin; dependiendo de una temperatura, la probabilidad de escoger una solucin peor que la actual
va descenciendo con el tiempo, hasta que al final del algoritmo, cuando la temperatura es 0, se escoge
de forma determinista siempre la mejor solucin. Puesto en forma de algoritmo:
Inicial el procedimiento en un punto del espacio de bsqueda
Mientras no se cumpla la condicin de terminacin, mejorar la solucin actual, dependiendo de la
temperatura.
Actualizar la temperatura
Volver al paso segundo
La probabilidad de aceptar una nueva solucin xt+1 en vez de la antigua xt se suele expresar con

la frmula p(x,y,T)=1/(1+eeval(xt+1) - eval(xt)/T).

Al mtodo que se sigue para actualizar la temperatura se le suele denominar procedimiento de enfriado
o cooling schedule. Dependiendo de la temperatura, puede ser que se escojan soluciones peores, pero la
probabilidad de que suceda desciende con el tiempo y con la diferencia entre la evaluacin de las dos
soluciones. El truco, claro est, consiste en elegir una buena temperatura inicial y un procedimiento de
enfriado correcto.
El trmino annealing procede de la metalurgia, y en concreto de la fabricacin de espadas. En esta
pgina se describe el procedimiento de fabricacin de espadas antiguas, y cmo se usaba el
recocimiento para conseguir espadas flexibles que no se rompieran. En concreto, lo que consigue este
procedimiento es un cristal con pocas irregularidades, y con un bajo nivel de energa atrapada.
El recocimiento simulado es un mtodo de optimizacin bastante popular, simple de implementar, y
que funciona bien para muchos problemas. Ha sido aplicado, por ejemplo, para la optimizacin de la
disposicin de una pgina web o para resolver el juego del Mastermind. Si embargo, es una mala
eleccin de punto inicial o del esquema de enfriamiento puede dar al traste con su exploracin del
espacio global.
6.1 Computacin paralela distribuida
Generalmente, los multicomputadores o multiprocesadores se suelen clasificar segn la multiplicidad
de instrucciones y datos que tengan: pueden tener una o mltiples instrucciones, o uno y mltiples
datos. Sin embargo, lo ms habitual hoy en da es trabajar en un entorno de ordenadores heterogneos,
unido por redes con diferente mbito, y con sistemas operativos y modos de representacin de las
instrucciones y datos muy diferente. Por eso, desde el punto de vista del usuario, hay diferentes formas
de considerar este multicomputador heterogneo: como un slo ordenador virtual, que ejecuta los
programas de forma transparente sin que uno se entere muy bien dnde estn fsicamente, que es el
enfoque que, inicialmente, se propuso la librera PVM . Otro enfoque es considerar los diferentes
sistemas como una serie de procesos unidos por intercambio de mensajes, como hace la librera MPI, y
algunos lenguajes como el Java a travs de su interfaz RMI (Remote Method Invocation). En este
trabajo, se pareliza una librera de algoritmos evolutivos usando MPI. Otra librera, basada en la misma
EO y llamada ParadisEO, tambin usa MPI para distribucin de algoritmos evolutivos.
Este ltimo mtodo es el ms popular, por lo que la mayor parte de los algoritmos, especialmente
basados en poblaciones, actuales, consisten en enviar o recibir diferentes mensajes que incluyan o no
miembros de la poblacin y/o estadsticas, tratando de hacer el mnimo cambio posible a los algoritmos
tradicionales.
ltimamente estn surgiendo una serie de ideas en computacin distribuida, que se escapan a los
paradigmas tradicionales. La mayor parte de ellas intentan trabajar con un entorno heterogneo,
cambiante, y en el cual la CPU es un recurso relativamente abundante. Una idea interesante es la
denominada computacin en rejilla, o grid computing. La computacin en rejilla trata de aprovecharse
de los recursos computacionales (CPU, almacenamiento, transmisin) de cantidades ingentes de
ordenadores, proveyendo un interfaz que sea independiente de la realidad fsica de la red y de los
ordenadores, de forma que el usuario slo tenga que preocuparse por ejecutar su problema a travs de,
por ejemplo, una pgina web. La infraestructura de la rejilla se encarga de distribuir su problema, los
mtodos y los datos, por la rejilla, de forma que se aprovechen al mximo los recursos. Hay muchos
productos comerciales de computacin rejilla, as como algn esfuerzo de fuentes abiertas, tal como
OpenGRID.

Tambin es interesante tener en cuenta una tecnologa que se usa habitualmente para pirateo de todo
tipo de contenido: las redes entre iguales, o P2P, redes sin una topologa fija y sin un nmero de
elementos fijos, ni un servidor central, que permiten distribuir datos y servicios. Este tipo de
tecnologas estn empezando a ser usadas para clculo paralelo, usando, por ejemplo, los denominados
algoritmos epidmicos. Este enfoque es el que se toma en el proyecto DREAM (Distributed resource
evolutionary algorithm machine), un software para programar algoritmos evolutivos usando una
infraestructura P2P.
Por ltimo, los servicios web, que ofrecen un interfaz con una sintaxis y semntica conocida para usar
los servicios existentes en un ordenador, se pueden usar tambin para computacin distribuida; pueden
ser una implementacin posible para un sistema en rejilla, o para una red P2P, o simplemente un
interfaz para acceder a cualquier tipo de servicio. Los servicios web estn basados en el metalenguaje
XML. Por ejemplo, en en este artculo, se paraleliza un algoritmo gentico usando un protocolo
llamado SOAP (Simple Object Access Protocol), que permite intercambiar mensajes codificados en
XML entre diferentes procesos. En esta pgina se ofrece un servicio web para la ejecucin de
algoritmos evolutivos que usa tambin SOAP.
En resumen, el panorama actual de la computacin evolutiva presenta muchos tipos de entornos
diferentes en los cuales implementar algoritmos de bsqueda, y especialmente algoritmos evolutivos.
Para evaluar un algoritmo paralelo habitualmente se tienen en cuenta sus propiedades de escalado, es
decir, cmo se comporta segn se van aadiendo nuevos procesadores al grupo; habitualmente el
procesador ms lento suele ser el primero que interviene. Un escalado lineal se dara si la aceleracin
SP, definido como el tiempo que tarda el algoritmo en ejecutarse en P procesadores o speedup del
proceso es directamente proporcional al nmero de procesadores aadidos; sin embargo, lo ms normal
es que llegue un momento en el que aadir nuevos procesadores no mejora en absoluto las
prestaciones. La eficiencia EP se define como SP/P, y est relacionada con el aprovechamiento que se
hace del aadido de nuevas mquinas . En algunos (contados) casos puede suceder que se d un
escalado superlineal, es decir, que la aceleracin crezca ms rapidamente que el nmero de
procesadores aadidos, o la eficiencia es mayor que 1; suele suceder cuando la divisin en diferentes
procesadores interacciona positivamente con el algoritmo, ofreciendo una mejora superior a la que se
dara si se ejecutara en una sola mquina.

7 Optimizacin multiobjetivo
La optimizacin multiobjetivo (u optimizacin multicriterio, multiprestaciones o optimizacin
vectorial) (de la que hay un excelente tutorial de Carlos Coello se define como el problema de
encontrar un vector de variables de decisin que satisfacen unas restricciones y optimizan una funcin
vectorial cuyos elementos representan a la funcin objetivo. Estas funciones forman una descripcin
matemtica de criterios de evaluacin que generalmente estn en conflicto unos con otros. Por tanto, el
trmino "optimizar" implica encontrar una solucin que dara los valores de todas las funciones
objetivo aceptables para el diseador.
Es raro que exista un solo punto que satisfaga todas las funciones objetivo; normalmente se busca un
equilibrio al tratar con problemas de optimizacin multiobjetivo; por lo tanto, el concepto de ptimo es
diferente. El concepto ms normal de ptimo fue propuesto originalmente por Edgeworth, y ms

adelante por Pareto, y se suele denominar ptimo Pareto u ptimo tipo Pareto; un vector es ptimo
pareto si no existe ninguno cuyos valores sean mejores para cada uno de los componentes
(estrictamente, si son menores o iguales para todos, y al menos menor estricto para uno de ellos). Lo
ms habitual es que no exista un solo ptimo Pareto, sino un conjunto de ellos; a este conjunto de
solucione se le suele denominar conjunto no dominado, y a su grfico se le suele llamar frente Pareto.
Histricamente, ha habido muchas formas de resolver problemas de optimizacin multiobjetivo usando
algoritmos genticos. El ms inocente es la utilizacin de funciones agregativas, es decir, una
combinacin lineal de las diferentes funciones que se tienen que optimizar, asignndole a cada una un
peso. Se crea as una funcin de evaluacin que se puede usar directamente en cualquier mtodo de
seleccin de los algoritmos evolutivos. Sin embargo, no siempre funciona bien, es difcil establecer los
pesos, y es incapaz de generar todos los miembros de un frente de Pareto si da la casualidad de que es
cncavo.
8.1 Aprendizaje no supervisado
Los algoritmos de clasificacin no supervisados son aquellos que no requieren un etiquetado de cada
uno de los vectores de entrada; se suelen llamar tambin algoritmos auto-asociativos, porque asocian
entradas a ellas mismas. Una buena explicacin de estos algoritmos se halla en la FAQ de redes
neuronales.
El tipo ms comn de algoritmos de aprendizaje o clasificacin no supervisada son los algoritmos de
anlisis de grupos o clustering; estos algoritmos tratan de dividir las muestras del conjunto de entrada
en una serie de grupos con caractersticas comunes. Un algoritmo debe descubrir cules son estos
clusters, pero tambin cules son las caractersticas que define ese cluster y cuntos clusters hay; pero
ste ltimo es un problema que no tiene solucin fcil. Tambin se denominan algoritmos de
cuantizacin vectorial o VQ (vector quantization), pues se pueden usar para sustituir un elemento
perteneciente a un grupo por un representante de ese grupo, habitualmente llamado vector cdigo o
centro del grupo. La cuantizacin vectorial pretende reducir la cantidad de bits a transmitir en una lnea
de comunicaciones, al sustituir un vector por un cdigo que indica qu representante se est
transmitiendo; la tcnica, adems, suprime el ruido.

CICLO DE VIDA DEL SOFTWARE

Informtica
El Ciclo de Vida del Software
Modelo Concurrente. Modelo Espiral. Prototipado de Requerimientos. Desarrollo Evolutivo.
Desarrollo Incremental. Modelo Cascada
Ciclo de Vida del Software
Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se mueve un proyecto de
desarrollo de software.
El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde
entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 aos
atrs, el modelo cascada ha sido sujeto a numerosas crticas, debido a que es restrictivo y rgido, lo cual
dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo
de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software ms rpidamente,
o ms incrementalmente o de una forma ms evolutiva, o precediendo el desarrollo a escala total con
algn conjunto de prototipos rpidos.
Definicin de un Modelo de Ciclo de Vida
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el
desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de
transicin asociadas entre estas etapas.
Un modelo de ciclo de vida del software:
Describe las fases principales de desarrollo de software.
Define las fases primarias esperadas de ser ejecutadas durante esas fases.
Ayuda a administrar el progreso del desarrollo, y
Provee un espacio de trabajo para la definicin de un detallado proceso de desarrollo de software.
As, los modelos por una parte suministran una gua para los ingenieros de software con el fin de
ordenar las diversas actividades tcnicas en el proyecto, por otra parte suministran un marco para la
administracin del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos,
definir puntos de control intermedios, monitorear el avance, etc.

Alternativas de Modelos de Ciclo de Vida

Modelo Cascada
Este es el ms bsico de todos los modelos, y sirve como bloque de construccin para los dems
modelos de ciclo de vida. La visin del modelo cascada del desarrollo de software es muy simple; dice
que el desarrollo de software puede ser a travs de una secuencia simple de fases. Cada fase tiene un
conjunto de metas bien definidas, y las actividades dentro de una fase contribuye a la satisfaccin de
metas de esa fase o quizs a una subsecuencia de metas de la fase. Las flechas muestran el flujo de
informacin entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrs
representan la retroalimentacin.
El modelo de ciclo de vida cascada, captura algunos principios bsicos:
Planear un proyecto antes de embarcarse en l.
Definir el comportamiento externo deseado del sistema antes de disear su arquitectura interna.
Documentar los resultados de cada actividad.
Disear un sistema antes de codificarlo.
Testear un sistema despus de construirlo.
Una de las contribuciones ms importantes del modelo cascada es para los administradores,
posibilitndoles avanzar en el desarrollo, aunque en una escala muy bruta.
Modelo De Desarrollo Incremental
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de
reducir los riesgos es construir slo una parte del sistema, reservando otros aspectos para niveles
posteriores. El desarrollo incremental es el proceso de construccin siempre incrementando
subconjuntos de requerimientos del sistema. Tpicamente, un documento de requerimientos es escrito al
capturar todos los requerimientos para el sistema completo.
Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo
incremental no demanda una forma especfica de observar el desarrollo de algn otro incremento. As,
el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la
figura.
El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:
Construir un sistema pequeo es siempre menos riesgoso que construir un sistema grande.
Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos
planeados para los niveles subsiguientes son correctos.
Si un error importante es realizado, slo la ltima iteracin necesita ser descartada.

Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen
las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
Si un error importante es realizado, el incremento previo puede ser usado.
Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del
prximo incremento.
Modelo De Desarrollo Evolutivo
Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces
denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un
producto. Sin embargo, mientras que la aproximacin incremental presupone que el conjunto completo
de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son
completamente conocidos al inicio del proyecto.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos que son bien
comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una
implementacin parcial del sistema que recibe slo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a los
desarrolladores. Basada en esta retroalimentacin, la especificacin de requerimientos es actualizada, y
una segunda versin del producto es desarrollada y desplegada. El proceso se repite indefinidamente.
Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no
demanda una forma especfica de observar el desarrollo de algn incremento. As, el modelo cascada
puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y
evolutivo puede ser combinado tambin.
Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos
(incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan
cuando el sistema sea desplegado o desarrollado.
El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulacin de
documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada
paso debe ser registrado, la documentacin debe ser recuperada con facilidad, los cambios deben ser
efectuados de una manera controlada.
Modelo de Prototipado de Requerimientos.El prototipado de requerimientos es la creacin de una implementacin parcial de un sistema, para el
propsito explcito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una
manera rpida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos,
posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la
retroalimentacin sobre lo que a ellos les gust y no les gust acerca del prototipo proporcionado,
quienes capturan en la documentacin actual de la especificacin de requerimientos la informacin
entregada por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como
parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de
requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede servir su papel

inmediatamente antes de algn o todo el desarrollo incremental en modelos incremental o evolutivo.

El Prototipado ha sido usado frecuentemente en los 90, porque la especificacin de requerimientos para
sistemas complejos tienden a ser relativamente dificultoso de cursar. Muchos usuarios y clientes
encuentran que es mucho ms fcil proveer retroalimentacin convenientemente basado en la
manipulacin, desde un prototipo, en vez de leer una especificacin de requerimientos potencialmente
ambigua y extensa.
Diferente del modelo evolutivo donde los requerimientos mejor entendidos estn incorporados, un
prototipo generalmente se construye con los requerimientos entendidos ms pobremente.
En caso que ustedes construyan requerimientos bien entendidos, el cliente podra responder con "s, as
es", y nada podra ser aprendido de la experiencia.
Modelo Espiral
El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el
esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro
comienza. Adems, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:
Determinar qu quieres lograr.
Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los
riesgos y resultados finales, y seleccionar la mejor.
Seguir la alternativa seleccionada en el paso 2.
Establecer qu tienes terminado.

La dimensin radial en la figura refleja costos acumulativos incurridos en el proyecto.

Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un
conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos
la situacin y determinamos que los mayores riesgos son la interfaz del usuario. Despus de un
cuidadoso anlisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y
esperar lo mejor, escribir una especificacin de requerimientos y esperar que el cliente lo entienda, y
construir un prototipo), determinamos que el mejor curso de accin es construir un prototipo.
Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentacin til.
Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor
riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer slo despus de que el
sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximacin es
construir un incremento del sistema que satisfaga slo los requerimientos mejor entendidos. Hagmoslo
ya. Despus del despliegue, el cliente nos provee de retroalimentacin que dir si estamos correctos
con esos requerimientos, pero 50 nuevos requerimientos ahora se originarn en las cabezas de los
clientes. Y el tercer viaje alrededor de la espiral comienza.

El modelo espiral captura algunos principios bsicos:

Decidir qu problema se quiere resolver antes de viajar a resolverlo.
Examinar tus mltiples alternativas de accin y elegir una de las ms convenientes.
Evaluar qu tienes hecho y qu tienes que haber aprendido despus de hacer algo.
No ser tan ingenuo para pensar que el sistema que ests construyendo ser "EL" sistema que el
cliente necesita, y
Conocer (comprender) los niveles de riesgo, que tendrs que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatible.
Modelo Concurrente
Como el modelo espiral, el modelo concurrente provee una meta-descripcin del proceso software.
Mientras que la contribucin primaria del modelo espiral es en realidad que esas actividades del
software ocurran repetidamente, la contribucin del modelo concurrente es su capacidad de describir
las mltiples actividades del software ocurriendo simultneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algn
tiempo del proceso de desarrollo de software. Discutamos un poco tales casos:
Los requerimientos son usualmente "lneas de base", cuando una mayora de los requerimientos
comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseo. Sin
embargo, una vez que comienza el diseo, cambios a los requerimientos son comunes y frecuentes
(despus de todo, los problemas reales cambian, y nuestro entendimiento de los problemas
desarrollados tambin). Es desaconsejado detener el diseo en este camino cuando los requerimientos
cambian; en su lugar, existe una necesidad de modificar y rehacer lneas de base de los requerimientos
mientras progresa el diseo. Por supuesto, dependiendo del impacto de los cambios de los
requerimientos el diseo puede no ser afectado, medianamente afectado o se requerir comenzar todo
de nuevo.
Durante el diseo de arquitectura, es posible que algunos componentes comiencen a ser bien definidos
antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el
diseo detallado en esos componentes estables. Similarmente, durante el diseo detallado, puede ser
posible proceder con la codificacin y quizs regular testeando en forma unitaria o realizando testeo de
integracin previo a llevar a cabo el diseo detallado de todos los componentes.
En algunos proyectos, mltiples etapas de un producto se han desarrollado concurrentemente. Por
ejemplo, no es inusual estar haciendo mantencin de la etapa 1 de un producto, y al mismo tiempo estar
haciendo mantencin sobre un componente 2, mientras que se est haciendo codificacin sobre un
componente 3, mientras se realiza diseo sobre una etapa 4, y especificacin de requisitos sobre un
componente 5.
En todos estos casos, diversas actividades estn ocurriendo simultneamente. Eligiendo seguir un
proyecto usando tcnicas de modelacin concurrente, se posibilita el conocimiento del estado

verdadero en el que se encuentra el proyecto.

CICLO DE DESARROLLO DEL SOFTWARE
Proceso para el desarrollo de software
Un proceso para el desarrollo de software, tambin denominado ciclo de vida del desarrollo de software
es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos a seguir para el
establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe un
enfoque diferente para diferentes actividades que tienen lugar durante el proceso. Algunos autores
consideran un modelo de ciclo de vida un trmino ms general que un determinado proceso para el
desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software especficos que se
ajustan a un modelo de ciclo de vida de espiral.
Generalidades
La gran cantidad de organizaciones de desarrollo de software implementan metodologas para el
proceso de desarrollo. Muchas de estas organizaciones pertenecen a la industria armamentstica, que en
los Estados Unidos necesita un certificado basado en su modelo de procesos para poder obtener un
contrato.
El estndar internacional que regula el mtodo de seleccin, implementacin y monitoreo del ciclo de
vida del software es ISO 12207.
Durante dcadas se ha perseguido la meta de encontrar procesos reproducibles y predecibles que
mejoren la productividad y la calidad. Algunas de estas soluciones intentan sistematizar o formalizar la
aparentemente desorganizada tarea de desarrollar software. Otros aplican tcnicas de gestin de
proyectos para la creacin del software. Sin una gestin del proyecto, los proyectos de software corren
el riesgo de demorarse o consumir un presupuesto mayor que el planeado. Dada la cantidad de
proyectos de software que no cumplen sus metas en trminos de funcionalidad, costes o tiempo de
entrega, una gestin de proyectos efectiva es algo que a menudo falta.
Algunas organizaciones crean un grupo propio (Software Engineering Process Group, abreviado
SEPG) encargado de mejorar los procesos para el desarrollo de software en la organizacin.
Actividades del desarrollo de software
Actividades del proceso de desarrollo de software representados en el desarrollo en cascada. Hay
algunos modelos ms para representar este proceso.
Planificacin
La importante tarea a la hora de crear un producto de software es obtener los requisitos o el anlisis de
los requisitos. Los clientes suelen tener una idea ms bien abstracta del resultado final, pero no sobre
las funciones que debera cumplir el software.
Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un anlisis del mbito del
desarrollo. Este documento se conoce como especificacin funcional.
Implementacin, pruebas y documentacin
La implementacin es parte del proceso en el que los ingenieros de software programan el cdigo para

el proyecto.
Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta parte del
proceso tiene la funcin de detectar los errores de software lo antes posible.
La documentacin del diseo interno del software con el objetivo de facilitar su mejora y su
mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentacin de un API, tanto
interior como exterior.
Despliegue y mantenimiento
El despliegue comienza cuando el cdigo ha sido suficientemente probado, ha sido aprobado para su
liberacin y ha sido distribuido en el entorno de produccin.
Entrenamiento y soporte para el software es de suma importancia y algo que muchos desarrolladores de
software descuidan. Los usuarios, por naturaleza, se oponen al cambio porque conlleva una cierta
inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del
software.
El mantenimiento o mejora del software de un software con problemas recientemente desplegado,
puede requerir ms tiempo que el desarrollo inicial del software. Es posible que haya que incorporar
cdigo que no se ajusta al diseo original con el objetivo de solucionar un problema o ampliar la
funcionalidad para un cliente. Si los costes de mantenimiento son muy elevados puede que sea
oportuno redisear el sistema para poder contener los costes de mantenimiento.
Modelos de Desarrollo de Software
Los modelos de desarrollo de software son una representacin abstracta de una manera en particular.
Realmente no representa cmo se debe desarrollar el software, sino de un enfoque comn. Puede ser
modificado y adaptado de acuerdo a las necesidades del software en proceso de desarrollo. 1 Hay
varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales cuenta con pros y contras.
El proyecto debera escoger el ms apropiado para sus necesidades. En ocasiones puede que una
combinacin de varios modelos sea apropiado. Existen tres paradigmas de los modelos de desarrollo de
software:
1. Paradigma Tradicional:
Es uno de los paradigmas ms antiguo, se invent durante la creacin del mtodo estructurado. Si se
elige un proyecto, el mtodo varia en etapas.2 Como todo modelo, existen sus pros y contras al usar
este paradigmas:
Cuadro de ventajas y desventajas del uso del Paradigma tradicional.
Si se aplica este paradigma, unos de los principales problemas , es que las etapas realizadas no son
autnomas de las siguientes, creando una dependencia estructural y en el acaso de un error atrasara
todo el proyecto. Se tiene que tener pautas bien definidas, y que no se incurra a modificacin porque
implicara en que el software no cumpla con su ciclo de vida. Tener en cuenta que el cliente no se vea
afectado por la impaciencia.3
2. Paradigma Orientado a Objetos: Estos modelos se basan en la Programacin orientada a objetos; por
lo tanto, se refiere al concepto de clase, el anlisis de requisitos y el diseo. El modelo o paradigma

orientado a objetos posee dos caractersticas principales, las cuales son:

Permite la re-utilizacin de software.
Facilita el desarrollo de herramientas informticas de apoyo al desarrollo, el cual es simple al
implementarla en una notacin orientado a objetos llamado UML.4
3. Paradigma de Desarrollo gil: Es un paradigma de las Metodologas De Desarrollo basado en
procesos giles. Estos intentan evitar los tediosos caminos de las metodologas tradicionales
enfocndose en las personas y los resultados. Usa un enfoque basado en el Valor para construir
software, colaborando con el cliente e incorporando los cambios continuamente.5
Modelo de cascada
Artculo principal: Desarrollo en cascada
El modelo de cascada define las siguientes etapas que deben cumplirse de forma sucesiva:
Especificacin de requisitos
Diseo del software
Construccin o Implementacin del software
Integracin
Pruebas (o validacin)
Despliegue (o instalacin)
Mantenimiento
Siguiendo el modelo de cascada de forma estricta, slo cuando se finaliza una fase, comienza la otra.
En ocasiones se realiza una revisin antes de iniciar la siguiente fase, lo que permite la posibilidad de
cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones tambin se
utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una
fase se conocen frecuentemente con el trmino ingls "gate" (puerta). Este modelo desaconseja revisitar
y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha
sido fuente de crtica de los defensores de modelos ms flexibles.
Modelo de espiral
Artculo principal: Desarrollo en espiral
La principal caractersticas del modelo en espiral es la gestin de riesgos de forma peridica en el ciclo
de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave
de las metodologas del modelo de cascada y del desarrollo rpido de aplicaciones, pero dando nfasis
en un rea que para muchos no jug el papel que requiere en otros modelos: un anlisis iterativo y
concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala.
La espiral se visualiza como un proceso que pasa a travs de algunas interaciones con el diagrama de
los cuatro cuadrantes representativos de las siguientes actividades:
crear planes con el propsito de identificar los objetivos del software, seleccionados para
implementar el programa y clarificar las restricciones en el desarrollo del software;
Anlisis de riesgos: una evaluacin analtica de programas seleccionados, para evaluar como
identificar y eliminar el riesgo;
la implementacin del proyecto: implementacin del desarrollo del software y su pertinente
verificacin;

Modelo de espiral con nfasis en los riesgos, haciendo hincapi en las condiciones de las opciones y
limitaciones para facilitar la reutilizacin de software, la calidad del software puede ayudar como una
meta propia en la integracin en el desarrollo del producto. Sin embargo, el modelo en espiral tiene
algunas limitaciones, entre las que destacan:
El nfasis se sita en el anlisis de riesgo, y por lo tanto requiere de clientes que acepten este anlisis
y acten en consecuencia. Para ello es necesaria confianza en los desarrolladores as como la
predisposicin a gastar ms para solventar los temas, por lo cual este modelo se utiliza frecuentemente
en desarrollo interno de software a gran escala.
Si la implementacin del riesgo de anlisis afectar de forma esencial los beneficios del proyecto, no
debera utilizarse este modelo.
Los desarrolladores de software han de buscar de forma explcita riesgos y analizarlos de forma
exhaustiva para que este modelo funcione.
La primera fase es la bsqueda de un plan para conseguir los objetivos con las limitaciones del
proyecto para as buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso anlisis, y
si fuera necesario incluyendo la fabricacin de un prototipo. Si es imposible descartar algunos riesgos,
el cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los riesgos.
Por ltimo, se evalan los resultados y se inicia el diseo de la siguiente fase.
Desarrollo iterativo e incremental
Artculo principal: Desarrollo iterativo e incremental
El desarrollo iterativo recomienda la construccin de secciones reducidas de software que irn ganando
en tamao para facilitar as la deteccin de problemas de importancia antes de que sea demasiado tarde.
Los procesos iterativos pueden ayudar a desvelar metas del diseo en el caso de clientes que no saben
cmo definir lo que quieren.6
Desarrollo gil
Artculo principal: Desarrollo gil de software
El desarrollo gil de software utiliza un desarrollo iterativo como base para abogar por un punto de
vista ms ligero y ms centrado en las personas que en el caso de las soluciones tradicionales. Los
procesos giles utilizan retroalimentacin en lugar de planificacin, como principal mecanismo de
control. La retroalimentacin se canaliza por medio de pruebas peridicas y frecuentes versiones del
software.
Hay muchas variantes de los procesos giles:
En el caso de la programacin extrema (XP), las fases se realizan en pasos muy cortos (o
"continuos") con respecto al anterior. El primer paso (intencionalmente incompleto) por los pasos
puede ocurrir en un da o en una semana, en lugar de los meses o aos de cada paso completo en el
modelo en cascada. En primer lugar, se crean pruebas automatizadas para proveer metas concretas al
desarrollo. Despus se programa el cdigo, que ser completo cuando todas las pruebas se superan sin
errores, y los desarrolladores ya no sabran como mejorar el conjunto de pruebas necesario. El diseo y
la arquitectura emergen a partir de la refactorizacin del cdigo, y se da despus de programar. El
diseo lo realizan los propios desarrolladores del cdigo. El sistema, incompleto, pero funcional se
despliega para su demostracin a los usuarios (al menos uno de los cuales pertenece al equipo de
desarrollo). Llegado este punto, los profesionales comienzan a escribir las pruebas para la siguiente
parte del sistema de ms importancia.

Codificacin y correccin
El desarrollo de codificacin y correccin (en ingls "Code and fix") es, ms que una estrategia
predeterminada, el resultado de una falta de experiencia o presin que se ejerce sobre los
desarrolladores para cumplir con una fecha de entrega.7 Sin dedicar tiempo de forma explcita para el
diseo, los programadores comienzan de forma inmediata a producir cdigo. Antes o despus comienza
la fase de pruebas de software (a menudo de forma tarda) y los inevitables errores que se encuentran
han de eliminarse antes de poder entregar el software.
Orientado a la Reutilizacin
La reutilizacin de software es un proceso donde se recurre al uso de activos de software en las
especificaciones de anlisis, diseos, implementacin y pruebas de una aplicacin o sistemas de
software.8
La reutilizacin tiene ciertos Indicadores por ejemplo:
1. Entre el 40% y 60% de una aplicacin es reutilizable en otra.
2. Aproximadamente el 60% de una aplicacin administrativa es reutilizable.
3. Aproximademente el 75% de las funciones son comunes a ms de un programa.
4. Solo el 15% del cdigo encontrado en muchos sistemas es unico y novedoso a una aplicacin
especifica.
El rango general de uso recurrente esta entre el 15% y 85%.9
La reutilizacin tiene Principios como la existencia de parecidos en distintos sistemas de un mismo
dominio, donde el software puede representarse como una combinacin de mdulos y los sistemas
nuevos se puede caracterizar por diferencias respecto a los antiguos sistemas.10
Modelos de mejora de procesos
Capability Maturity Model Integration
El Capability Maturity Model Integration (CMMI), en espaol Integracin de Modelos de Madurez
de Capacidades es uno de los modelos lderes basados en mejores prcticas. Son evaluaciones
independientes las que confirman el grado con el que una organizacin siguen sus propios procesos,
que no evala la calidad de los procesos o del software que se produce. CMMI ha reemplazado a CMM
y tiene un mbito global, no slo en procesos destinados al desarrollo del software.
ISO 9000
ISO 9000 describe estndares para un proceso organizado formalmente para resultar en un producto
y los mtodos de gestin y monitoreo del progreso. Aunque este estndar se cre inicialmente para el
sector de produccin, los estndares de ISO 9000 tambin se han aplicado al desarrollo del software. Al
igual que CMMI, que una organizacin est certificada con el ISO 9000 no garantiza la calidad del
resultado final, slo confirma que se ha seguido los procesos establecidos.
ISO 15504

ISO 15504, tambin conocido como Software Process Improvement Capability Determination
(SPICE), en espaol Determinacin de la Capacidad de Mejora del Proceso de Software es un marco
para la evaluacin de procesos de software. Este estndar tiene como objetivo un modelo claro para
poder comparar procesos. SPICE se utiliza como en el caso de CMMI. Modela procesos para gestionar,
controlar, guiar y monitorear el desarrollo del software. Este modelo se utiliza entonces para medir lo
que una organizacin o proyecto hace durante el desarrollo del software. Esta informacin se analiza
para identificar puntos dbiles y definir acciones para subsanarlos. Tambin identifica puntos fuertes
que pueden adoptarse en el resto de la organizacin.
Mtodos formales
Los mtodos formales son soluciones matemticas para resolver problemas de software y hardware a
nivel de requisitos, especificacin y diseo. Ejemplos de mtodos formales incluyen el Mtodo B, la
red de Petri, la demostracin automtica de teoremas, RAISE y el VDM. Hay varias notaciones de
especificaciones formales, tales como el lenguaje Z. Ms generalmente, se puede utilizar la teora de
autmatas para aumentar y validar el comportamiento de la aplicacin diseando un sistema de
autmata finito.
Las metodologas basadas en los autmatas finitos permiten especificacin de software ejecutable y
evitar la creacin convencional de cdigo.
Los mtodos formales se suelen aplicar en software de aviacin, especialmente si es software de
seguridad crtico. Los estndares de aseguramiento del software de seguridad, tales como DO178B
demandan mtodos formales en el nivel ms alto de categorizacin (Nivel A).
La formalizacin del desarrollo de software est ganando en fuerza poco a poco, en otros mbitos, con
la aplicacin del lenguaje de especificacin OCL2.0 (y especializaciones tales como Java Modeling
Language) y particularmente con Model-driven Architecture, que permite la ejecucin de diseos,
incluso especificaciones.
Otra tendencia que est surgiendo en el desarrollo de software es la redaccin de especificaciones en
algn tipo de lgica (normalmente una variacin de FOL), para acto seguido ejecutar esa lgica como
si se tratase de un programa. El lenguaje OWL, basado en lgica descriptiva, es un buen ejemplo.
Tambin se est trabajando en enlazar un idioma natural de forma automtica con lgica, lgica que
puede ejecutarse. Ejemplo en este campo es el Attempto Controlled English, una lgica de negocios de
Internet, que no busca controlar el vocabulario o la sintaxis. Una caractersticas de los sistemas que
apoyan el vnculo bidireccional ingls-lgica y ejecucin directa de la lgica es que pueden explicar
sus resultados en ingls en un nivel de negocios o cientfico.

HISTORIA DEL COMPUTADOR