2.1.

3 MODELO EVOLUTIVO
El modelo evolutivo es una extensin al modelo incremental en la que
los incrementos se hacen de manera secuencial, en lugar de en
paralelo.10 Desde el punto de vista del cliente, el sistema evoluciona
segn vayan siendo entregados los incrementos. Desde el punto de vista
del desarrollador, los requerimientos que son claros al principio del
proyecto dictan el incremento inicial, mientras que los incrementos para
cada uno de los siguientes ciclos de desarrollo se clarifican a travs de la
experiencia de los incrementos anteriores.
Este modelo considera que el desarrollo de sistemas es un proceso de
cambios progresivos mediante deltas (cambios) de especificacin de
requerimientos.
El
modelo
evolutivo
es
tambin
conocido
como desarrollo
rpido
de
aplicaciones (en
ingls, RADrapid
application development), que se basa tradicionalmente en el uso de
prototipos (en ingls, rapid prototyping).
Un prototipo de software se considera como un medio para especificar
los requisitos y un enlace de comunicacin entre el usuario final y el
diseador, ayudando a reducir el riesgo de carecer de requerimientos
iniciales completos y estables.
Algunas de las creencias del modelo de cascada son la entrega
temprana de parte del sistema, aunque no estn completos todos los
requerimientos, ya que esto permite utilizarlo como herramienta para la
generacin de requerimientos faltantes, obteniendo beneficios para el
sistema mediante entregas iniciales mientras las entregas posteriores se
encuentran en desarrollo.

2.1.4 MODELO ESPIRAL

El modelo espiral, desarrollado durante la dcada de los aos 80, es una
extensin del modelo de cascada. A diferencia del modelo de cascada,
que es dirigido por documentos, el modelo espiral se basa en una
estrategia para reducir el riesgo del proyecto en reas de incertidumbre,
como tener requerimientos iniciales incompletos e inestables. El modelo
enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes
de proceder al siguiente ciclo. Cada ciclo comienza con la identificacin
de los objetivos, soluciones alternas y restricciones asociadas con cada
alternativa, y finalmente se procede a su evaluacin. Cuando se
encuentra que existe cierta incertidumbre, se utilizan diversas tcnicas
para reducir el riesgo de las distintas alternativas.
Cada ciclo del modelo espiral termina con una revisin que discute los
logros actuales y los planes para el siguiente ciclo. Al igual que el
modelo evolutivo, el modelo espiral incorpora una estrategia de uso de
prototipos como parte del manejo del riesgo.

Las creencias del modelo de espiral son que una actividad comienza
cuando se entienden los objetivos y riesgos involucrados, se usan las
herramientas que mejor reduzcan los riesgos basndose en la
evaluacin de soluciones alternas, todo el personal relacionado debe
involucrarse en una revisin que determine cada actividad (planeando y
comprometindose con las siguientes actividades) y el desarrollo se
incrementa en cada etapa, permitiendo prototipos sucesivos del
producto. Con algunas variantes, ste es el modelo de proceso ms
importante en la actualidad.
2.1.5 MODELO DE PROTOTIPOS
Un prototipo es una versin preliminar, intencionalmente incompleta o
reducida de un sistema. El uso de prototipos es una estrategia que
puede aplicarse en casi todas las actividades del proceso de software. El
propsito de los prototipos es obtener de manera rpida la informacin
necesaria como ayuda en la toma de decisiones.
Los siguientes son algunos tipos de prototipo:
Los prototipos de requisitos permiten que los usuarios perciban la
funcionalidad del producto final a travs del diseo de interfaces o
pantallas del sistema. El objetivo es ayudar a aclarar los requisitos y
solicitar nuevas ideas.
Los prototipos
de
anlisis permiten
generar
rpidamente
una
arquitectura general que considere las caractersticas principales del
sistema de acuerdo con la especificacin de requisitos.
Los prototipos de diseo permiten explorar y comprender la arquitectura
particular de un sistema para poder evaluar aspectos como cuellos de
botella (rendimiento y uso de memoria) o incoherencias en el diseo.
Los prototipos verticales permiten comprender parte de un problema y
desarrollar su solucin completa. Esto se hace generalmente cuando los
conceptos bsicos no estn bien comprendidos (por ejemplo, el
seguimiento de cierta metodologa).
Los prototipos de factibilidad permiten demostrar si es posible lograr
ciertos objetivos del proyecto (por ejemplo, aplicar una arquitectura
particular, conectarse a una base de datos bajo ciertas restricciones de
rendimiento, aprender a programar en cierto lenguaje en un tiempo
determinado o predecir los costos de desarrollo de un proyecto). Un
prototipo no es necesariamente un producto de calidad, que deba
mantenerse a largo plazo. Por el contrario, los prototipos a menudo son
creados y probados rpidamente, para luego ser descartados. Sin
embargo, es comn que, por presiones de tiempo, se trate de enviar un
prototipo al mercado (venderlo) como si ste fuera el producto final.

En general, siempre existir un conflicto entre un desarrollo rpido y un

producto de calidad. Las siguientes dos listas muestran algunas
consideraciones para el xito o fracaso de los prototipos.
Los prototipos tienen xito cuando se comprende su propsito y se usan
de manera adecuada, se comprende la tecnologa que va a utilizarse y
su relacin con el proceso de prototipos, se integra un grupo tcnico
apropiado para hacer el prototipo (lder de proyecto, documentador,
elaborador de prototipos de requisitos y anlisis, y elaborador de
prototipos de diseo), se evala al grupo y las entregas finales, se
involucra temprano en el proceso de software a los usuarios finales, se
est dispuesto a repetir el proceso de prototipos para comprender mejor
la arquitectura bsica, se establecen criterios de evaluacin apropiados
al comienzo de cada etapa de prototipos y se basa uno firmemente en
estos criterios para su terminacin y/o se construyen prototipos basados
en una biblioteca de cdigo reutilizable, controlada por el bibliotecario
asignado.
Los prototipos fallan cuando no se comprende qu es un prototipo y
cmo debe usarse, no se comprende el proceso lo suficientemente bien
como para organizar al grupo de manera adecuada, no se sabe hasta
cundo dejar de evolucionar el prototipo y comenzar de cero (as
extendiendo demasiado el proceso), no se sabe hasta cundo continuar
para tratar de lograr los criterios de evaluacin deseados (as
terminando prematuramente el proceso), no se utilizan ambientes o
herramientas de apoyo adecuados para el desarrollo particular, se cree
que un prototipo razonable es un producto aceptable y/o los prototipos
nunca terminan.
2.1.6 DESARROLLO BASADO EN COMPONENTES
Ingeniera de Software Basada en Componentes (ISBC)
Tradicionalmente los ingenieros del software han seguido un enfoque de
desarrollo descendente (top-Down) basado en el ciclo de vida en
cascada (anlisis-diseo implementacin) para la construccin de sus
sistemas, donde se establecen los requisitos y la arquitectura de la
aplicacin y luego se va desarrollando, diseando e implementando
cada parte software hasta obtener la aplicacin completa implementada.
La ISBC parte de la idea de la integracin de componentes software ya
existente
(Desarrollo ascendente o bottom-up). Las tecnologas de objetos
proporcionan el marco de trabajo tcnico, para la ingeniera de software,
para un modelo de proceso basado en componentes. El paradigma
orientado a objetos enfatiza la creacin de clases que encapsulan tanto

los datos como los algoritmos para manejar esos datos. Si se disean y
se implementan adecuadamente, las clases
Orientadas a objetos son reutilizables por diferentes aplicaciones.
Es la reutilizacin la que permite a los desarrolladores construir
aplicaciones sin partir desde cero, sino acercndose ms al modelo de
construccin de otras ingenieras, donde los productos se construyen en
base al ensamblaje y adaptacin de distintos componentes desarrollados
por terceros (como lo es la industria del hardware para computadoras).
Por ello requiere un conjunto de estndares, guas, procesos y prcticas,
para que se la considere como una ingeniera tal, y como una subdisciplina de la Ingeniera de Software.
Segn Pressman, La metodologa que propone entonces la Ingeniera
de Software Basada en Componentes (ISBC) (Figura 1) incorpora
muchas de las caractersticas del Modelo en Espiral. Es evolutivo2 por
naturaleza, y por ello exige tambin un enfoque iterativo para la
creacin del software.
Fases de Ingeniera y Construccin y Accin de ste modelo por una sola
fase de Construccin y adaptacin de la Ingeniera:
*Comunicacin con el cliente- las tareas requeridas para establecer
comunicacin entre el desarrollador y el cliente.
*Planificacin- las tareas requeridas para definir recursos, el tiempo y
otra informacin relacionadas con el proyecto.
*Anlisis de riesgos- las tareas requeridas para evaluar riesgos tcnicos
y de gestin.
*Construccin y adaptacin de la Ingeniera
*Evaluacin del cliente- las tareas requeridas para obtener la reaccin
del cliente segn la evaluacin de las representaciones del software
creadas durante la etapa de ingeniera e implementada durante la etapa
de instalacin.
Evoluciona con el tiempo, se crean versiones cada vez ms completas
del producto.

2.2 OTRAS METODOLOGAS

Metodologa SCRUM:

Es un marco de trabajo para la gestin y desarrollo de software basada

en un proceso iterativo e incrementalutilizado comnmente en entornos
basados en el desarrollo gil de software.
Aunque Scrum estaba enfocado a la gestin de procesos de desarrollo
de software, puede ser utilizado en equipos de mantenimiento de
software, o en una aproximacin de gestin de programas: Scrum de
Scrums.

Programacin extrema
La programacin
extrema o eXtreme
Programming (XP)
es
una
metodologa de desarrollo de la ingeniera de software formulada
por Kent Beck, autor del primer libro sobre la materia, Extreme
Programming Explained: Embrace Change (1999). Es el ms destacado
de los procesos giles de desarrollo de software.
En el siguiente diagrama nos muestra ciclo de entrega en la
programacin extrema.
Al igual que stos, la programacin extrema se diferencia de las
metodologas tradicionales principalmente en que pone ms nfasis en
la adaptabilidad que en la previsibilidad. Los defensores de la XP
consideran que los cambios de requisitos sobre la marcha son un
aspecto natural, inevitable e incluso deseable del desarrollo de
proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos
en cualquier punto de la vida del proyecto es una aproximacin mejor y
ms realista que intentar definir todos los requisitos al comienzo del
proyecto e invertir esfuerzos despus en controlar los cambios en los
requisitos.
Se puede considerar la programacin extrema como la adopcin de las
mejores metodologas de desarrollo de acuerdo a lo que se pretende
llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el
ciclo de vida del software.
Proceso unificado gil
El proceso unificado gil de Scott ambler o agile unified process (aup) en
ingls es una versin simplificada delproceso unificado de rational (rup).
Este describe de una manera simple y fcil de entender la forma de
desarrollar aplicaciones de software de negocio usando tcnicas giles y
conceptos que an se mantienen vlidos en rup. El aup aplica tcnicas
giles incluyendo desarrollo dirigido por pruebas (test driven
development - tdd), modelado gil, gestin de cambios gil, y
refactorizacin de base de datos para mejorar la productividad.

2.2.1GANAR-GANAR
El modelo ganar-ganar (en ingls, win-win) extiende el modelo espiral,
haciendo nfasis en la identificacin de las condiciones de ganancia para
todas las partes, creando un plan para alcanzar las condiciones
ganadoras y evitar los riesgos correspondientes. Se establecen las reglas
para definir el proceso de desarrollo del proyecto, tomando en cuenta
todas las partes implicadas. El modelo no necesita mucho tiempo de
gestin. Esto permite utilizarlo tanto en proyectos pequeos como
grandes.
Se consideran cuatro los ciclos, cada uno compuesto de cuatro
actividades.
Las cuatro actividades son: elaborar los objetivos, restricciones y
alternativas del proceso y producto del sistema y subsistema; evaluar
las alternativas con respecto a los objetivos y restricciones (identificando
y resolviendo las fuentes principales de riesgo en el proceso y producto);
elaborar la definicin del producto y proceso; y planear el siguiente ciclo,
actualizando el plan del ciclo de vida, incluyendo la particin del sistema
en subsistemas para ser considerados en ciclos paralelos, lo cual puede
incluir un plan para terminar el proyecto si es muy riesgoso o no es
factible, asegurando el compromiso de la administracin para continuar
segn lo planeado.
Una vez revisadas las actividades, los ciclos definen lneas especficas a
seguir. En el Ciclo 0 (grupos de aplicacin) se determina la viabilidad de
un grupo apropiado de aplicaciones.
En el Ciclo 1 (objetivos del ciclo de vida de la aplicacin) se desarrollan
los objetivos del ciclo de vida, incluyendo prototipos, planes y
especificaciones de aplicaciones individuales, y se verifica la existencia
de al menos una arquitectura viable para cada aplicacin. En el
Ciclo 2 (arquitectura del ciclo de vida de la aplicacin) se establece una
arquitectura del ciclo de vida detallado, se verifica su viabilidad, y se
determina que no existen riesgos mayores en satisfacer los planes y
especificaciones.
En el Ciclo 3 (capacidad de operacin inicial) se alcanza una capacidad
operacional inicial para cada etapa crtica del proyecto en el ciclo de
vida del software.
Las creencias del modelo son: crear software basado en componentes
para lograr mayor calidad en los sistemas de mayor tamao, escribir
software reutilizable para hacer eficiente el proceso de desarrollo, medir
la calidad del sistema como aspecto clave del desarrollo del producto,
lograr mayor calidad en el proceso de ensamblaje a partir de
componentes menores, usar tecnologas basadas en objetos como

aspecto bsico para lograr la calidad, producir sistemas rpidamente

(sencillos, confiables y de calidad) empleando procesos bien definidos,
utilizar el modelo espiral como base del proceso, hacer flexible el
proceso de creacin del software para lograr los objetivos generales de
eficiencia, involucrar al cliente mediante el manejo de prototipos y
analizar los riesgos en el proceso del desarrollo del software para
asegurar la calidad final del sistema.
En el sistema GA se basa principalmente en resolver los problemas que
puedan surgir en el software y as poder tener un mejor producto y uso
del mismo, para lograr esto se usaran los manuales de contingencia y de
mantenimiento.
Para justificar de una forma ms exacta el uso de dicho modelo en el
sistema GA es porque este modelo se basa principalmente del modelo
espiral el cual tiene una secuencias de actividades como son el anlisis,
diseo, pruebas, implementacin; el sistema GA utilizo todas
estas actividades para poder ser realizado con esto podemos destacar
que se podrn obtener a su vez las diferentes versiones que pueden ser
realizadas por medio de dichas actividades, ya que nuestro sistema
GA tendr diferentes actualizaciones que se enfocan en las versiones de
mismo. Tambin podemos destacar que nuestro sistema se basa en la
tecnologa gratuita para el software y esto a su vez mejor la calidad del
mismo, ya que el modelo Ganar-ganar se basa principalmente en la
calidad y eficiencia de un sistema.
2.2.2 PROCESO UNIFICADO (UP)
El proceso unificado (en ingls, UPunifi ed process) 13 es una
extensin al proceso objectory (del ingls object factory) ,14 que tiene
sus orgenes en la dcada de los aos 80. Estos modelos de proceso se
basan principalmente en la especificacin de requerimientos de un
sistema mediante casos de uso (maneras de utilizar un sistema).
El proceso unificado considera como aspecto esencial del desarrollo de
software una visin que parte de la arquitectura del sistema, siguiendo
un proceso iterativo e incremental. El proceso considera e integra
diferentes aspectos, como son los ciclos, fases, flujos de trabajo,
mitigacin de riesgo, control de calidad, administracin de proyecto y
control de configuracin. De manera adicional, el proceso unificado
considera las cuatro P del desarrollo de software: personas, proyecto,
producto y proceso.
El proceso unificado tiene las siguientes creencias: para construir un
sistema exitoso se debe conocer qu quieren y necesitan los usuarios

potenciales; al igual que la arquitectura, en la construccin, permite

disear edificios desde mltiples puntos de vista, estructura,
electricidad, etc., las arquitecturas de los sistemas de software deben
permitir visualizar un sistema desde mltiples perspectivas; y el
desarrollo de un producto de software comercial puede significar un gran
esfuerzo continuando por meses, aos o incluso ms, por lo que es
prctico dividir el trabajo en pedazos, donde cada iteracin resulta en un
incremento del proyecto.

2.2.3 INGENIERA WEB

Que es un navegador?
Un navegador, navegador red o navegador web (del ingls, web
browser) es una aplicacin de software que permite al usuario recuperar
y visualizar documentos de hipertexto, comnmente descritos en HTML.
2.2.4 METODOLOGAS GILES
Esta metodologa nace en febrero del 2001 en una reunin celebrada en
Utah EEUU.
Principales ideas de la metodologa gil:
Se encarga de valorar al individuo y las iteraciones del equipo ms que a
las herramientas o los procesos utilizados.
Se hace mucho ms importante crear un producto software que funcione
que escribir mucha documentacin.
El cliente est en todo momento colaborando en el proyecto.
Es ms importante la capacidad de respuesta ante un cambio realizado
que el seguimiento estricto de un plan
2.2.5 METODOLOGAS EMERGENTES
Primera aproximacin a la aplicacin de las metodologas SCRUM para
mejorar la eficacia de los procesos de la Vigilancia e Inteligencia
Competitiva, con la finalidad de obtener resultados pronto, con
requisitos cambiantes o poco definidos, siendo la innovacin, la
competitividad, la flexibilidad y la productividad factores fundamentales.
Metodologas de desarrollo Orientado a objetos, Diseo orientado a
objetos (OOD) de Grady Booch, tambin conocido como Anlisis y
Diseo Orientado a Objetos (OOAD). El modelo incluye seis diagramas:

de clase, objeto, estado de transicin, la interaccin, mdulo, y el

proceso.
Top-down programming, evolucionado en la dcada de 1970 por el
investigador de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo
Estructurado.
Proceso Unificado, es una metodologa de desarrollo de software, basado
en UML. Organiza el desarrollo de software en cuatro fases, cada una de
ellas con la ejecucin de una o ms iteraciones de desarrollo de
software: creacin, elaboracin, construccin, y las directrices. Hay una
serie de herramientas y productos diseados para facilitar la aplicacin.
Una de las versiones ms populares es la de Rational Unified Process.
2.3 RINGENIERA EN SOFTWARE
La reingeniera debe ser entendida como un proceso mediante el cual se
mejora un software existente haciendo uso de tcnicas de ingeniera
inversa y
reestructuracin de cdigo. Para llevar a cabo la reingeniera del
Software se puede realizar a travs del modelo Cclico. En algunas
ocasiones, estas actividades se producen de forma secuencial y lineal,
pero esto no siempre es as. Por ejemplo, puede ser que la ingeniera
inversa (la comprensin del funcionamiento interno de un programa)
tenga que producirse antes de que pueda comenzar la reestructuracin
de documentos.
La Reingeniera del software se puede definir como: modificacin de un
producto software, o de ciertos componentes, usando para el anlisis del
sistema existente tcnicas de Ingeniera Inversa y, para la etapa de
reconstruccin, herramientas de Ingeniera Directa, de tal manera que
se oriente este cambio hacia mayores niveles de facilidad en cuanto a
mantenimiento, reutilizacin, comprensin o evaluacin.
Cuando una aplicacin lleva siendo usada aos, es fcil que esta
aplicacin se vuelva inestable como fruto de las mltiples correcciones,
adaptaciones o mejoras que han podido surgir a lo largo del tiempo. Esto
deriva en que cada vez que se pretende realizar un cambio se producen
efectos colaterales inesperados y hasta de gravedad, por lo que se hace
necesario, si se prev que la aplicacin seguir siendo de utilidad,
aplicar reingeniera a la misma.
Entre los beneficios de aplicar reingeniera a un producto existente se
puede incluir:
Pueden reducir los riegos evolutivos de una organizacin.

Puede ayudar a las organizaciones a recuperar sus inversiones en

software.
Puede hacer el software ms fcilmente modificable
Ampla las capacidades de las herramientas CASE
Es un catalizador para la automatizacin del mantenimiento del software
Puede actuar como catalizador para la aplicacin de tcnicas de
inteligencia artificial para resolver problemas de reingeniera
PASOS DE LA REINGENIERIA DEL SOFTWARE
Anlisis de Inventario.- Todas las organizaciones de software deberan
tener un inventario de todas sus aplicaciones. El inventario tal vez no
sea ms que un modelo en una hoja de clculo que contenga
informacin que proporcione una descripcin detallada (tamao, edad,
importancia para el negocio) de las aplicaciones activas. Es importante
sealar que el inventario deber visitarse con regularidad, el estado de
las aplicaciones puede cambiar en funcin del tiempo y, como resultado,
cambiarn las prioridades para la reingeniera.
Restructuracin de cdigo.- Algunos sistemas heredados tienen una
arquitectura de programa relativamente slida, pero los mdulos
individuales han sido codificados de una forma que hace difcil
comprenderlos, comprobarlos y mantenerlos. En estos casos, se puede
reestructurar el cdigo ubicado dentro de los mdulos sospechosos.
Para llevar a cabo esta actividad, se analiza el cdigo fuente mediante
una herramienta de reestructuracin, se indican las violaciones de las
estructuras de programacin estructurada, y entonces se reestructura el
cdigo (esto se puede hacer automticamente). El cdigo reestructurado
resultante se revisa y se comprueba para asegurar que no se hayan
introducido anomalas. Se actualiza la documentacin interna del cdigo.
Restructuracin de datos.- Un programa que posea una estructura de
datos dbil ser difcil de adaptar y de mejorar. De hecho, para muchas
aplicaciones, la arquitectura de datos tiene ms que ver con la viabilidad
a largo plazo del programa que el propio cdigo fuente. A diferencia de
la reestructuracin de cdigo, que se produce en un nivel relativamente
bajo de abstraccin, la estructuracin de datos es una actividad de
reingeniera a gran escala. En la mayora de los casos, la
reestructuracin de datos comienza por una actividad de ingeniera
inversa. La arquitectura de datos actual se analiza minuciosamente y se
definen los modelos de datos necesarios. Se identifican los objetos de
datos y atributos y, a continuacin, se revisan las estructuras de datos a
efectos de calidad.
Ingeniera directa.- En un mundo ideal, las aplicaciones se reconstruyen
utilizando un motor de reingeniera automatizado. En el motor se
insertara el programa viejo, que lo analizara, reestructurara y despus

regenerara la forma de exhibir los mejores aspectos de la calidad del

software. Despus de un espacio de tiempo corto, es probable que
llegue a aparecer este motor, pero los fabricantes de CASE han
presentado herramientas que proporcionan un subconjunto limitado de
estas capacidades y que se enfrentan con dominios de aplicaciones
especficas. Lo que es ms importante, estas herramientas de
reingeniera cada vez son ms sofisticadas.
La Ingeniera directa, que se denomina tambin renovacin o
reclamacin, no solamente recupera la informacin de diseo de un
software ya existente, sino que, adems, utiliza esta informacin en un
esfuerzo por mejorar su calidad global. En la mayora de los casos, el
software procedente de una reingeniera vuelve a implementar la
funcionalidad del sistema existente, y aade adems nuevas funciones
y/o mejora el rendimiento global.