CAPITULO II METODOLOGIAS DE DESARROLLO

INTRODUCCION
2.1 METODOLOGIAS CLASICAS
Es difcil construir aplicaciones de tamao realista debido a su complejidad. El proceso
bajo el cual se construyen es un factor crucial para administrar esta complejidad.
La metodologa clsica es un trmino que se utiliza para hablar de los parmetros
tradicionales cientficos sin tomar en cuenta las innovaciones en el campo y est
demostrada su eficacia, por lo cual son usadas y aplicadas con relativa confianza.
Las metodologas clsicas son las siguientes:
2.1.1 MODELO DE CASCADA
El modelo de la cascada se desarroll entre las dcadas de los sesenta y setenta, y se
define como una secuencia de actividades, donde la estrategia principal es seguir el
proceso del desarrollo de software hacia puntos de revisin bien definidos mediante
entregas calendarizadas.
Consiste en el anlisis de requerimientos, el diseo, la implementacin, la integracin y
las pruebas.
- El analisis de requerimientos consiste en reunir las necesidades del producto y
casi siempre su salida es texto.
- El diseo describe la estructura interna del producto y suele representarse con
diagramas y texto.
- Implementacin significa programacin. El producto de esta etapa es el cdigo
de cualquier nivel, incluido el producido por sistemas de generacin automtica
de cdigo, lenguajes de cuarta generacin u otros.
- La integracin es el proceso de ensamblar las partes para completar el producto.
Estas etapas en realidad no se ejecutan en una secuencia estricta, ya que existe en
cierto traslape entre las partes del proceso. La razn de este traslape es que suele ser
poco practico completar totalmente una de estas etapas antes de comenzar la
siguiente. Las etapas que muestra la imagen siguente a menudo se aumentan con
etapas adicionales como las siguientes:


FIGURA 1.0 Secuencia de actividades para el modelo de cascada
- Anlisis conceptual: al principio del proceso, donde se define la filosofa global
del proyecto.
- Anlisis orientado a objetos entre el anlisis de requerimientos y de diseo,
donde se identifican las clases importantes.
- Pruebas unitarias y del sistema, que marcan la distincin entre probar las partes
de una aplicacin y de todo.
- Mantenimiento al final del proceso, donde se repara y modifica la aplicacin para
que contine siendo til.
Los procesos que emplean el diagrama en cascada repetidas veces se llaman
iterativos. No es necesario aplicar todos los pasos de la cascada en cada iteracin. A
continuacin se explican los procesos iterativos en espiral e incremental.
En la figura 1.0 muestra un diagrama del modelo de cascada que describe el orden de
las actividades de desarrollo del software.
Las siguientes caractersticas son las bases en las que se fundamenta el modelo
cascada:
Las metas se logran mejor cuando se tienen puntos de revisin bien
preestablecidos y documentados, dividiendo el desarrollo en actividades
secuenciales bien definidas.
Los documentos tcnicos son comprensibles para el usuario y administradores
no tcnicos.
Cada detalle de los requisitos se conoce de antemano antes de desarrollar el
software, y los detalles son estables durante el desarrollo.
Las pruebas y evaluaciones se realizan eficientemente al final del desarrollo.
El modelo de cascada inicialmente era bueno, ya que contena informacin lgica y
razonable. Posteriormente empez a tener conflictos ya que no explicaba como
modificar un resultado, es decir si llegaba a tener alguna corrupcin con el transcurso
del desarrollo del programa. Adems, el modelo toma demasiado tiempo en ver
resultados, lo que retrasa la deteccin de errores hasta el final. Mediantes estas series
de conflictos se generaron algunas dudas respecto a su utilidad, lo que provoco que no
se utilizara tal como se pensaba, esto llevo a los desarrolladores a utilizar variantes del
modelo bsico.
2.1.2 INCREMENTAL
En ocasiones es posible avanzar un proyecto con un proceso casi continuo. Este
modelo de proceso es en particular viable en las ltimas etapas del proyecto, cuando el
producto est en mantenimiento, o cuando el producto propuesto es muy similar al
producto desarrollado antes. Los incrementos pueden trabajarse en paralelo, pero es
difcil coordinarlo.
El modelo incremental es un desarrollo inicial de la arquitectura complete del sistema.
Desarrolla incrementos y versiones parciales del mismo. Cada incremento agrega
funcionalidad aadida o mejorada en el sistema. Cuando se completa una versin se
verifica e integra con la versin completa del sistema. El sistema se evalua con cada
incremento con con respecto al desarrollo de futuras versiones. Para que la secuencia
de desarrollo sea exitosa, es necesario definir algunas etapas que no requieran
cambiar los resultados anteriores al agregar nuevas. Es importante comprender al inicio
los requisistos completos del sistema, algo que normalmente es muy difcil de lograr.
Las siguientes caractersticas son en las que se basa el modelo incremental:
- La administracin de proyectos es ms fcil de lograr en incrementos ms
pequeos.
- Es ms fcil comprender y probar incrementos de funcionalidad ms que
pequeos.
- La funcionalidad inicial se desarrolla ms temprano, logrando resultados de
inversin en menor tiempo.
- Hay ms probabilidad de satisfacer el cambio en los requisitos de usuario
mediante incrementos del software en el tiempo. Que si fuera planeados todos a
la vez en un mismo periodo.
2.1.3 Modelo evolutivo
Se reconoce que el software, al igual que todos los sistemas complejos, evoluciona con
el tiempo. Los requisitos de gestin y de productos a menudo cambian conforme a que
el desarrollo proceda haciendo que el camino que lleva al producto final no sea real; las
estrictas fechas tope del mercado hacen que sea imposible finalizar un producto
completo, por lo que se debe introducir una versin limitada para cumplit la presin
competitiva y de gestin; se comprende perfectamente el conjunto de requisitos de
productos centrales o del sistema, pero todava se tienen que definir los detalles de
extensiones del producto o sistema.
El modelo evolucionario es una extensin al modelo incremental, donde los
incrementos se hacen de manera secuencial en lugar de un paralelo. Desde el punto
de vista del cliente, el sisma evoluciona segn se van entregando los incrementos.
Desde el punto de vista del desarrollador, los requerimientos que son claros al principio
del proyecto dictarn el incremento inicial, mientras que los incremento para cada uno
de los siguientes ciclos de desarrollo sern clasificados a travs de la experiencia de
los incrementos anteriores. El desarrollo evolutivo asume que los requerimientos estn
sujetos a cambios continuos y que la estrategia para enfrentar aquello pasa por un
reflujo, tambin continuo, de aquellos cambios. Un prototipo de software se considera
como un medio para especificar los requisitos y un enlace de comunicacin entre el
usuario final y el desarrollador lo que ayuda a reducir el riesgo de carecer de
requerimientos iniciales completos y estables.
Caractersticas del modelo evolutivo:
Se entrega temprano parte del sistema, aunque no estn completos todos los
requerimientos.
Se permite entregar parte del sistema como una herramienta para la generacin
de requerimientos faltantes.
Se obtiene beneficios para el sistema mediante entregas iniciales, mientas las
entregas posteriores estn en desarrollo.




Especificacin inicial
Desarrollo del producto







2.1.4 ESPIRAL
Es una extensin del modelo cascada. A diferencia del modelo cascada el modelo
espiral se basa en una estrategia para reducir el riesgo del proyecto en reas de
incertidumbre, como requerimientos iniciales incompletos e inestables. El modelo se
enfoca en los ciclos de trabajo. Cada ciclo comienza con la identificacin de los
objetivos, soluciones alternativas, restricciones asociadas con cada alternativa y se
procede a su evaluacin.
El modelo espiral reconoce la necesidad de pasar por la secuencia anlisis de
requerimientos, diseo, implementacin, pruebas ms de una vez. Existen varias
razones. Una importante es la necesidad de eliminar los riesgos. Otra razn es
construir una versin parcial preliminar del producto que se pueda mostrar al cliente
para obtener retroalimentacin; una razn ms es evitar la integracin de una base
de cdigo grande todo a la vez.
El modelo espiral se ajusta al avance de los proyectos tpicos: sin embargo,
requiere una administracin ms cuidadosa que la sencilla casacada. Este cuidado
adicional se debe al hecho de que la documentacin debe ser consistente siempre
que el proceso termina una iteracin completa. En particular, el cdigo debe
corresponde al diseo documentado y debe satisfacer los requerimientos
documentados.
Los beneficio del desarrollo en espiral exceden las desventajas. El ministerio de
defensa de estados unido reconoci esto en la dcada de los 80s y desecho la
suposicin anterior de que todos los proyectos de software se desarrollaron
siguiendo el proceso en cascada.
Cuando se identifica incertidumbre, se utilizan algunas tcnicas para reducir el
riesgo de las distancias opcionales. Cada ciclo del modelo de espiral termina con
una revisin que discute los logros actuales y los planes para el siguiente ciclo.
Implementacin uso y evaluacin
Re-especificacin
Versin del software

Diagrama conceptual del modelo de espiral

Al igual que el modelo evolucionario, el modelo de espiral incorpora una estrategia
de uso de prototipos como parte del manejo del riesgo.
Algunas caractersticas modelo de espiral son:
- Una actividad comienza cuando se entienden los objetivos y riesgos
involucrados.
- Basado en la evaluacin de soluciones alternas. Se usan las herramientas que
mejor reduzca los riesgos.
- Todo el personal relacionado debe involucrarse en una revisin que determine
cada actividad, planeando y comprometindose con las siguientes actividades.
- El desarrollo se incrementa en cada etapa , permitiendo prototipos sucesivos del
producto.




2.1.5 MODELO DE PROTOTIPOS
- El prototipo es el framework de actividades dedicada al desarrollo de software
prototipo, es decir, versiones incompletas del software a desarrollar.
-
-
-
-
-
-
-
-
-
-
-
-
-





FIGURA 2.0 Modelo basado en prototipos
- Como se muestra en la figura 2.0 el modelo de prototipos se divide en dos
partes fundamentales, el grupo compuesto por: Usuario/Diseador y el grupo
Sistema/Constructor.
- En el grupo usuario/diseador es la parte donde se obtienen todos los requisitos
que se necesitaran para el desarrollo del software, una vez obtenidos los
requisitos se pasara a la etapa del diseo global del sistema, donde se explicara
todo el diseo que contendr dicho software. Una vez obtenidos estos pasos
pasaremos a la siguiente etapa, la cual es llevada por la persona que construye
el sistema, l se encargara de hacer la construccin del prototipo para as poder
visualizar como funcionara el software, una vez que se haya aprobado el
prototipo pasaremos a la etapa del desarrollo donde se llevara a cabo la
programacin de dicho sistema. Teniendo el desarrollo del software se har una
refinacin del software es decir se purificara de los posibles errores que se
hayan podido presentar, obteniendo as el final del sistema.
- El para digma de este comienza con la recoleccon de requisitos. El desarrollador
y el ciente encuentran y definen los objetivos globlales para el software,
identifican los requisitos conocidos y las reas del esquema en donde es
obligatoria mas definicin. Entonces aparece un diseo rpido. El diseo rpido
se centra en una representacin de esos aspectos del software que sern
Obtencin de requisitos
Diseo Global
Construccin Prototipo
Desarrollo Prototipo
Refinamiento Prototipo
Sistema Terminado

GRUPO
USUARIO / DISEADOR
visibles para el usuario/ cliente ( por ejemplo: enfoques de entrada y formatos de
salida). El diseo rpido lleva a la construccin de un prototipo. El prototipo lo
evalua el cliente/ usuario y se utiliza para refinar los requisitos del software a
desarrollar. La iteracin ocurre cuando el prototipo se pone a punto para
satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el
desarrollador comprenda mejor lo que se necesita hacer.
-



2.1.6 Desarrollo basado en componentes
Las tecnologas de objetos proporcionan el marco de trabajo tcnico para un modelo de
proceso basado en componentes para la ingeniera del software. El paradigma
orientado a objetos enfatiza la creacin de clases que encapsulan tanto los datos como
los algoritmos que se utilizan para manejar los datos. Si se disean y se implementan
adecuadamente, las calses orientadas a objetos son reutilizables por las diferentes
aplicaciones y arquitecturas de sistemas basados en computadora.
Los nuevos componentes de software comerciales (NCSC), desarrollados por
vendedores que los ofrecen como productos, se pueden emplear cuando el software
esta en procesos de construccin. Estos componentes proporcionan funcionalidad
dirigida con interfaces bien definidas que permiten que el componente se integre en el
software.
El modelo de desarrollo basado en componentes (DBC) incorpora muchas de las
caractersticas del modelo en espiral. Es evolutivo por naturaleza y exige un enfoque
iterativo para la creacin del software. Sin embargo, el modelo configura aplicaciones a
partir de componentes de software empaquetados en forma previa.
Las actividades de modelado y construccin comienzan con la identificacin de los
componentes candidatos. Estos componentes se pueden disear como mdulos de
software convencionales o como clases o paquetes de clases orientados a objetos. Sin
importar la tecnologa que se aplique en la creacin de los componentes, el modelo de
desarrollo basado en componentes incorpora los siguientes pasos:
Los productos basados en componentes disponibles se investigan y evalan
para el dominio de aplicacin en cuestin.
Se consideran los aspectos de integracin de componentes.
Se disea una arquitectura de software para adaptar componentes.
Los componentes se integran en la arquitectura.
Se realizan pruebas detalladas para asegurar una funcionalidad apropiada.
Las clases creadas en los proyectos de ingeniera del software anteriores, se
almacenan en una biblioteca de clases o diccionario de datos.
Una vez identificadas las clases las clases candidatas, la biblioteca y se vuelven a
utilizar. Si una clase candidata no reside en la biblioteca, se aplican los mtodos
orientados a objetos. Se compone as la primera iteracin de la aplicacin a
construirse, mediante las clases extradas de la biblioteca y las clases nuevas
construidas para cumplir las necesidades nicas de la aplicacin. el flujo de proceso
vuelve a la espiral y volver a introducir por ltimo la iteracin ensambladora de
componentes a travs de la actividad de ingeniera .
2.2 Otras metodologas
2.2.1 Ganar-ganar
Extiende el modelo espiral haciendo enfasis en la identificacin de las condiciones de
ganancia para todas las partes crenado un plan para alcanzar las condiciones
ganadoras y 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, lo que permite utilizarlo tanto en
proyectos pequeos como mayores.
Define un conjunto de actividades de negociacin al principo de cada paso alrededor
de la espiral. Mas que una simple actidvdad de comunicacin con el cliente, se definen
las siguientes actividades:
1. Identificacin del sistema o subsistemas clave de los directivos.
2. Determinacin de las condiciones de victora de los directivos.
3. Negociacin de las condiciones de victoria de los directivos para reunirlas en
conjunto de condiciones ganar- ganar para todos losa fectados.
conseguidos completamente estos pasos iniciales se logra un resultado ganar- ganar
que ser el criterio clave para continuar con la definicin del sistema del software.
Se consideran cuatros ciclos, compuestos cada uno e cuatro actividades se detallan a
continuacin:
- Elaborar los objetivos, restricciones y alternativas del proceso y producto del
sistema y subsistema.
- Evaluar las alternativas con respecto a los objetivos y restricciones. Identificar y
resolver las fuentes principales de reisgo en el proceso y producto.
- Elaborar la definicin del producto y proceso.
- Planear el siguiente ciclo y actualizar el plan de su ciclo de vida, incluyendo la
particin del sistema en el subsistema para ser considerados en ciclos paralelos.
A esto tambien se adiere un plan para terminar el proyecto si es muy riesgoso o
no es factible. Asegurar el compromiso de la administracin para continuar
segn lo planeado.

Los ciclos definen lneas especficas a seguir:

Ciclo 0. Grupos de aplicacin. Se determina la viabilidad de un grupo apropiado de
aplicaciones.
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.
Ciclo 2. Arquitectura del ciclo de vida de la aplicacin.
Se establece una arquitectura del ciclo de vida detallado, se verifica la viabilidad y
determina que no existen riesgos mayores en satisfacer los planes y especificaciones.
Ciclo 3. Capacidad de operacin inicial.
Alcanzar una capacidad operacional inicial para cada etapa crtica del proyecto en el
ciclo de vida del software.
Las caractersticas del modelo son las siguientes:

- Crear software basado en componentes para incrementar la calidad en los
sistemas de mayor tamao.
- Escribir software reutilizable par 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 de espiral como base del proceso.
- Flexibilizar el proceso de creacin del software para lograr los objetivos
generales de eficiencia.
- Involucrar al cliente mediante el manejo de prototipos.
- Analizar los riesgos en el proceso del desarrollo del software para asegurar la
calidad al final del sistema
- .
Pasos del modelo ganar- ganar:
1. Identificar el siguiente nivel para los directivos.
2. Identificar las condiciones de victoria de los directivos.
3. Reunir las condiciones de victoria. Establecer los objetivos de restricciones y
alternativas del siguiente nivel.
4. Evaluar las alternativas del proceso y resolucin de riesgos.
5. Definir el siguiente nivel del producto y del proceso, incluyendo particiones.
6. Validar las definiciones del producto y del proceso.
7. Revisin y comentarios.
2.2.2 PROCESO UNIFICADO (UP)
El Proceso Unificado es un marco de desarrollo de software que se caracteriza por
estar dirigido por casos de uso, que tiene su origen en 1980, centrado en la
arquitectura y por ser iterativo e incremental. El refinamiento ms conocido y
documentado del Proceso Unificado es el Proceso Unificado de Rational o
simplemente RUP.
Debido a que los enfoques iterativos repiten todas las partes del proceso en cascada,
puede ser complicado describirlos. El UP es un proceso iterativo que intenta resolver
este problema con una clasificacin de iteraciones en cuatro grupos. Los interesados
son personas que tienen algo que perder segn el resultado del producto. Incluye a los
clientes, pero tambin a los usuarios, los capitalistas que arriesgan, los grupos de
usuarios y desarrolladores mismos. Las iteraciones de elaboracin establecen la meta
tcnica clave de seleccionar y confirmar una arquitectura. Las iteraciones de
construccin establecen el producto bsico, que todava requiere trabajo para liberarlo.
La meta de las iteraciones de transicin es preaparar la aplicacin para liberarla al
cliente.
Al clasificar las iteraciones de esta manera, el UP se puede describir en trminos de
una matriz. Igual que con la mayor parte de los procesos de anlisis y diseo con OO,
las etapas de la cascada mostradas por Jacobson et al. Tambien incluyen la etapa de
analiss. El anlisis consiste en esa parte del proceso de requerimientos en que las
clases bsicas de la aplicacin se seleccionan y relacionan.
Adems no muestra la etapa de integracin especifica que suele mostrar el proceso en
cascada clsico. Esto se debe a la creencia expresada por Booch que las aplicaciones
OO pueden y deben emplear la integracin continua. En otras palabras, al anadir
partes nuevas, se integran toda la aplicacin, y se elimina la necesidad de una etapa
de integracin designada.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo
extensible que puede ser adaptado a organizaciones o proyectos especficos. De la
misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo
extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular
del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los
dos nombres suelen utilizarse para referirse a un mismo concepto.
El proceso unificado sostiene sus bases en las siguientes caractersticas:
Para construir un sistema exitoso se debe conocer que quieren y necesitan los
usuarios potenciales.
El desarrollo de un producto de software comercial puede significar un gran
esfuerzo durante meses, e incluso aos. Es practico dividir el trabajo en etapas,
donde cada iteracin resulta en un incremento del proyecto.

2.2.3 Ingeniera web
La World Wide Web y el internet que la alimentan son, posiblemente, los desarrollos
ms importantes en la historia de la computacin. Estas tecnologas han llevado a
todos a la era de la informtica, adems se han convertido en parte integral de la vida
diaria en la primera dcada del siglo XXI.
La ingeniera web es la aplicacin de metodologas sistemticas, disciplinadas y
cuantificables al desarrollo eficiente, operacin y evolucin de aplicaciones de alta
calidad en la World Wide Web.
La ingeniera web se debe al crecimiento desenfrenado que est teniendo la Web est
ocasionando un impacto en la sociedad y el nuevo manejo que se le est dando a la
informacin en las diferentes reas en que se presenta ha hecho que las personas
tiendan a realizar todas sus actividades por esta va.
Desde que esto empez a suceder el Internet se volvi ms que una diversin y
empez a ser tomado ms en serio, ya que el aumento de publicaciones y de
informaciones hizo que la Web se volviera como un desafo para los (Ingeniera del
software) ingenieros del software, a raz de esto se crearon enfoques disciplinados,
sistemticos y metodologas donde tuvieron en cuenta aspectos especficos de este
nuevo medio.
2.2.4 METODOLOGIAS AGILES
A principios de la dcada de los noventa, surgi un enfoque que fue bastante
revolucionario para su momento ya que iba en contra de toda creencia de que
mediante procesos altamente definidos se iba a lograr obtener software en tiempo,
costo y con la requerida calidad. El enfoque fue planteado por primera vez por Martin y
se dio a conocer en la comunidad de Ingeniera de Software con el nombre de RAD o
Rapid Application Development. RAD consista en un entorno de desarrollo altamente
productivo, en el que participaban grupos pequeos de programadores utilizando
herramientas que generaban cdigo en forma automtica tomando como entradas
sintaxis de alto nivel.
La historia de las Metodologas giles y su apreciacin como tales en la
comunidad de la Ingeniera de Software tiene sus inicios en la creacin de una de las
metodologas utilizada como arquetipo: XP - eXtreme Programming, que nace de la
mente de Kent Beck.
Durante 1996, dada la poca calidad del sistema que se estaba desarrollando, Beck
decide tirar todo el cdigo y empezar de cero utilizando las prcticas que l haba ido
definiendo a lo largo del tiempo. El sistema, es puesto en operacin en Mayo de 1997.
Como consecuencia del xito de dicho proyecto.
Es as como que este tipo de metodologas fueron inicialmente llamadas metodologas
livianas, sin embargo, an no contaban con una aprobacin. Luego, con el pasar de
los aos, en febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace
formalmente el trmino gil aplicado al desarrollo de software.
Tras esta reunin se cre The Agile Alliance, una organizacin, sin nimo de lucro,
dedicada a promover los conceptos relacionados con el desarrollo gil de software
y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida
fue el Manifiesto gil, un documento que resume la filosofa gil.
2.2.4.1 EL MANIFIESTO AGIL
En el documento se plasmaron los siguientes puntos:
La prioridad es satisfacer al cliente mediante tempranas y continuas
entregas de software que le aporte un valor.
Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente
tenga una ventaja competitiva.
Entregar frecuentemente software que funcione desde un par de semanas a un
par de meses, con el menor intervalo de tiempo posible entre entregas.
La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del
proyecto.
Construir el proyecto en torno a individuos motivados. Darles el entorno y el
apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar
informacin dentro de un equipo de desarrollo.
El software que funciona es la medida principal de progreso.
Los procesos giles promueven un desarrollo sostenible. Los
promotores, desarrolladores y usuarios deberan ser capaces de mantener una
paz constante.
La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad.
La simplicidad es esencial.
Las mejores arquitecturas, requisitos y diseos surgen de los equipos
organizados por s mismos.
En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms
efectivo, y segn esto ajusta su comportamiento.
Algunos ejemplos de metodologas giles son: XP (Extreme Programming), Scrum,
Crystal Clear, DSDM (Dynamic Systems Development Method), FDD (Feature Driven
Development) y ASD (Adaptive Software Development).
2.2.5 METODOLOGIA EMERGENTE
Proceso.
Un proceso define quin hace qu, cundo y cmo para lograr un objetivo fijo. El xito de las
organizaciones est en gran medida en la correcta definicin y empleo de sus procesos.
Modelo de proceso.
Define cmo resolver la problemtica del desarrollo de sistemas de software. Para desarrollar
software se requiere solucionar ciertas etapas de su proceso, las cuales se conocen como el ciclo de
vida de desarrollo de software. No existe un solo modelo de proceso adaptable a cualquier proyecto,
pues el modelo de proceso depende del tipo particular de proyecto:

Primer proyecto de su tipo. Se crea desde cero, requiere de ms tiempo para especificarlo y
analizarlo, la incertidumbre crea riesgos adicionales.

Segundo proyecto de su tipo. Se busca agregar nueva funcionalidad a uno conocido.

Variacin de un proyecto. Se extiende un sistema ya existente, lo cual incluye introducir
componentes de software reutilizables como un marco de trabajo, crear nuevos componentes o
simplemente ampliar la aplicacin existente mediante nueva funcionalidad.

Proyecto de reescritura de legado. Se busca innovar o hacer una reingeniera de un sistema ya
existente, desarrollado bajo tecnologas anteriores y transformarlo a tecnologas nuevas.

Proyecto de creacin de software reutilizable. Se busca hacer uno o ms componentes de software
reutilizables, debe ser diseado de tal forma que se asegure de que el diseo sea lo suficientemente
general para ser usarse en otras situaciones desconocidas, por ello no hay muchos proyectos de ese
tipo.

Proyecto de mejora de sistema o mantenimiento. Se busca cambiar los componentes bsicos de un
sistema para apoyar a una nueva funcionalidad.

2.3 Reingeniera
Es un mtodo mediante el cual se redisea fundamentalmente los procesos principales
del negocio, de principio a fin, empleando toda la tecnologa y recursos
organizacionales disponibles, orientado por las necesidades y especificaciones del
cliente, para alcanzar mejoras espectaculares en medida crticas y contemporneas de
rendimiento, tales como costos, calidad, servicio y rapidez.
ste es un cambio radical en la forma en que se visualiza y estructuran los negocios,
que, a su vez, dejan de observarse como funciones, divisiones y productos, para ser
visualizados en trminos de proceso clave.
La reingeniera consiste en constituir un recreacin y reconfiguracin de las actividades
y procesos de la empresa, lo cual implica volver a crear y configurar de manera radical
l o los sistemas de la compaa a los efectos de lograr incrementos significativos, y en
un corto periodo de tiempo de respuesta, y calidad, lo cual implica la obtencin de
ventajas competitivas; es decir hace que las empresas se vuelvan ms competitivas.
Las etapas de la reingeniera son:
Preparacin: Definir las metas y los objetivos estratgicos que justifiquen la reingeniera
y los vnculos entre los resultado de la reingeniera y los resultado de la organizacin.
Identificacin: El propsito de esta etapa es el desarrollo de un modelo orientado al
cliente, identifica procesos especficos y que agregan valor.
Visin: El propsito de esta etapa es desarrollar una visin del proceso capaz de
producir un avance decisivo en rendimiento. La visin del nuevo proceso debe ser
comprensible para todo el personal, describir las caractersticas primarias del proceso,
debe ser motivadora e inspiradora.
Solucin: En esta etapa se produce un diseo tcnico y un disero cultural-
organizacional de la empresa. El diseo social necesariamente debe ser realizado al
mismo tiempo que el tcnico, pues para que un proceso sea eficaz, estos diseos
deben ser congruentes.
Transformacin: El propsito de esta etapa es realziar la visin del proceso
implementando el diseo de la esta anterior.