2.

2 OTRAS METODOLOGAS
2.2.1GANAR-GANAR
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.

Cada ciclo envuelve cuatro actividades principales:

Elaboracin del sistema o subsistemas
Restricciones y alternativas del proceso.

los

objetivos,

Evaluar las alternativas respecto a los objetivos y restricciones.

Identificar y resolver el mayor nmero de fuentes de producto y
Riesgos posibles.

Elaboracin

de

la

definicin

del

producto

del

proceso.

Planificacin del prximo ciclo y actualizacin de la planificacin

Del
ciclo
de
vida.
Ello
incluye,
si
es
necesario,
el
Particionamiento del sistema en subsistemas a desplegarse en
Paralelo. Puede incluir, adems, la definicin de un plan para
Finalizar el proyecto si ste es de riesgo demasiado alto o no es
Factible.

Las actividades iniciales del modelo se establecen de la siguiente manera:

Identificacin del sistema o claves de los directivos.

Determinacin de las condiciones de los directivos.
Negociacin de condiciones de todos los afectados.

CARACTERSTICAS
Introduce 3 hitos en el proceso llamados puntos de fijacin, que ayudan a
establecer la completitud de un ciclo de la espiral, y proporcionan hitos de
decisin antes de continuar el proyecto de desarrollo del software
define un conjunto de actividades de negociacin al principio de cada paso
alrededor de la espiral
Es visto como una variacin o una evolucin del modelo en espiral

VENTAJAS

Minimiza riesgos del proyecto

Agrega objetivos de calidad

DESVENTAJAS

Genera mucho tiempo en el desarrollo del sistema

Resulta como un modelo muy costoso
Requiere de mucha experiencia en la identificacin de los riesgos.

2.2.2 PROCESO UNIFICADO.

La metodologa de UP, es un mtodo iterativo de diseo de software que
describe cmo desarrollar software de forma eficaz, utilizando tcnicas
probadas en la industria.
El Proceso Unificado de Desarrollo de Software o simplemente Proceso
Unificado es un marco de desarrollo de software que se caracteriza por
estar dirigido por casos de uso, centrado en la arquitectura, enfocado en el
riesgo, y por ser iterativo e incremental.
El Proceso Unificado no es simplemente un proceso, sino un marco de
trabajo extensible que puede ser adaptado a organizaciones o proyectos
especficos.
El nombre Proceso Unificado se usa para describir el proceso genrico que
incluye aquellos elementos que son comunes a la mayora de los
refinamientos existentes. Es una metodologa orientada a conducir el
proceso de desarrollo de software en sus aspectos tcnicos; los flujos y
productos de trabajo de UP no incluyen la administracin del proyecto.

UP Divide El Trabajo De Desarrollo De Software En Cuatro Fases:

Fase de Inicio en UP:

En esta fase corresponde definir el negocio. Es la etapa donde se define la
factibilidad del proyecto a realizar, se representa el modelo de negocio,
visin y metas del proyecto, se identifican actores, conceptos de dominio y
deseos de usuario. Adicionalmente se complementa con la definicin de la
arquitectura preliminar, y estimaciones (imprecisas, preliminares) de plazos
y costos. Tambin se define la viabilidad del proyecto.

Fase de Elaboracin en UP
En la fase de elaboracin se obtiene la visin refinada del proyecto a
realizar, la implementacin iterativa del ncleo central de la aplicacin, la
resolucin de los riesgos ms altos, la identificacin de nuevos requisitos y
nuevos alcances, y estimaciones ms ajustadas. A esta altura existe la
posibilidad de detener el proyecto por complejidad tcnica.

Fase de Construccin en UP
La fase de construccin es la implementacin iterativa del resto de los
requisitos de menor riesgo y elementos ms sencillos. Es la evolucin hasta
convertirse en un producto listo, incluyendo todos los requisitos (100%),
para entregarse al Cliente. Al final de esta fase el sistema contiene todos
los casos de uso que el cliente y la direccin del proyecto han acordado. La
mayora de los casos de uso que no se desarrollaron en la fase anterior se
desarrollan en iteraciones, en grupos de requisitos o casos de uso durante
esta fase.
Fase de Transicin en UP
Es el periodo donde el producto es completamente entregado al cliente
para ser testeado y desplegado (instalado).

CARACTERSTICAS
Est dirigido por casos de uso (vase la seccin sobre UML).
Est centrado en la arquitectura (es decir, en una solucin de conjunto.
Tiene un ciclo de vida iterativo incremental (vase ms adelante).

VENTAJAS:
Su uso es libre (como decir barra libre, sin condiciones).
Hay excelentes textos, que explican la aplicacin de este proceso paso a
paso, como UML y patrones, de Craig Larman, publicado por PearsonPrentice Hall (Segunda Edicin, Madrid, 2003).

DESVENTAJA

Su uso es libre (como decir barra libre, sin condiciones).

Hay excelentes textos, que explican la aplicacin de este proceso paso a
paso, como UML y patrones, de Craig Larman, publicado por PearsonPrentice Hall (Segunda Edicin, Madrid, 2003).

 Es necesario aterrizar los conceptos, lo cual puede resultar un poco difcil

para quien no tenga experiencia en el uso de procesos de ingeniera de
software.

2.2.3 INGENIERA WEB

DEFINICION
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.

Caractersticas de la Ingeniera web

Caracterstica

Explicacin

Intensivas de Red

Por naturaleza utiliza una red, debe dar servicio a una

comunidad de clientes

Inmediatez

El tiempo que se tarda en comercializar un sistema web

es mucho ms rpido que otro tipo de software

Evolucin
Continua

A diferencia de una aplicacin de escritorio (que utilizan

actualizaciones planificadas), estas pueden tener
actualizaciones cada hora (en algunos casos)

Controlada por el
Contenido

Hace mucho uso de contenidos hipermedia ,para mostrar

textos, imgenes, videos, etc.

Seguridad

Por la disponibilidad a una gran cantidad de usuarios,

existen una

Esttica

Parte de su atractivo son su apariencia e interaccin

Intensi
vas de

Red
Esttica

Inmediatez

Ingeniera
Web
Evolucin
Continua

Seguridad

Controlada
por el
Contenido

Formulacin en la Ingeniera Web

Necesida
des del
negocio

Requisitos

Formulacin

Objetivos
y metas

Funciones
y
Caracterst
icas

Formulacin

Permite

Equipo

Clientes

Establecer

Metas y
Objetivos

MODELIZACIN

 Se compone de dos secuencias paralelas de tareas. Una consiste en el

diseo y produccin del contenido que forma parte de la aplicacin. La
otra, en el diseo de la arquitectura, navegacin e interfaz de usuario.

Es conveniente resaltar la importancia del diseo de la interfaz.

Independientemente del valor del contenido y servicios prestados, una
buena interfaz mejora la percepcin que el usuario tiene de stos.

PRUEBAS
Las pruebas busca errores a todos los niveles: contenido, funcional,
navegacional, rendimiento, etc.
El hecho de que las aplicaciones residan en la red, y que inter-operen en
plataformas muy distintas, hace que el proceso de test sea especialmente
difcil

EVALUACIN AL CLIENTE
El resultado final es sometido a la evaluacin del cliente y aceptacin por el
mismo.

CONCLUSIONES
La aplicacin de principios de ingeniera pueden evitar el caos potencial al
que nos enfrentamos, y poner bajo control el desarrollo de las aplicaciones
Web, minimizando riesgos y mejorando el mantenimiento y calidad.
El proceso de ingeniera comienza con la formulacin, planificacin que
estima el coste global, el anlisis de aspectos tcnicos y objetos de
contenido, la generacin de pginas mediante automatizacin y la
comprobacin.

2.2.4 METODOLOGAS GILES

Un poco de historia

En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino

gil. Aplicado al desarrollo de software. En esta reunin participan un grupo de 17
expertos de la industria del software, incluyendo algunos de los creadores o
impulsores de metodologas de software. Su objetivo fue esbozar los valores y
principios que deberan permitir a los equipos desarrollar software rpidamente y
respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se
pretenda ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que
se genera en cada una de las actividades desarrolladas.
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 es fue el Manifiesto gil, un documento que resume la filosofa .gil..

El Manifiesto gil.
Segn el Manifiesto se valora:
1. Al individuo y las interacciones del equipo de desarrollo sobre el
proceso y las herramientas. La gente es el principal factor de xito de un
proyecto software. Es ms importante construir un buen equipo que
construir el entorno. Muchas veces se comete el error de construir primero
el entorno y esperar que el equipo se adapte automticamente. Es mejor
crear el equipo y que ste configure su propio entorno de desarrollo en
base a sus necesidades.
2. Desarrollar software que funciona ms que conseguir una buena
documentacin. La regla a seguir es no producir documentos a menos que
sean necesarios de forma inmediata para tomar una decisin importante.
Estos documentos deben ser cortos y centrarse en lo fundamental.
3. La colaboracin con el cliente ms que la negociacin de un contrato.
Se propone que exista una interaccin constante entre el cliente y el equipo
de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha
del proyecto y asegure su xito.

4. Responder a los cambios ms que seguir estrictamente un plan. La

habilidad de responder a los cambios que puedan surgir a los largo del
proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.)

determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin

no debe ser estricta sino flexible y abierta.

Diferencias entre metodologas giles y no giles

Extreme Programming(XP)
Qu es la Programacin Extrema?
XP es una metodologa gil centrada en potenciar las relaciones interpersonales
como clave para el xito en desarrollo de software, promoviendo el trabajo en
equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un
buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el
equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad
en las soluciones implementadas y coraje para enfrentar los cambios. XP se
define como especialmente adecuada para proyectos con requisitos imprecisos y
muy cambiantes, y donde existe un alto riesgo tcnico.

Los principios y prcticas son de sentido comn pero llevadas al extremo, de ah

proviene su nombre. Kent Beck, el padre de XP, describe la filosofa de XP en sin
cubrir los detalles tcnicos y de implantacin de las prcticas. Posteriormente,
otras publicaciones de experiencias se han encargado de dicha tarea. A
continuacin presentaremos las caractersticas esenciales de XP organizadas en
los tres apartados siguientes: historias de usuario, roles, proceso y prcticas.

Las Historias de Usuario

Son la tcnica utilizada para especificar los requisitos del software. Se trata de
tarjetas de papel en las cuales el cliente describe brevemente las caractersticas
que el sistema debe poseer, sean requisitos funcionales o no funcionales. El
tratamiento de las historias de usuario es muy dinmico y flexible. Cada historia de
usuario es lo suficientemente comprensible y delimitada para que los
programadores puedan implementarla en unas semanas.

Roles XP
Los roles de acuerdo con la propuesta original de Beck son:
- Programador. El programador escribe las pruebas unitarias y produce el
cdigo del sistema.
- Cliente. Escribe las historias de usuario y las pruebas funcionales para
validar su implementacin. Adems, asigna la prioridad a las historias de
usuario y decide cules se implementan en cada iteracin centrndose en
aportar mayor valor al negocio.
- Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas
funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el
equipo y es responsable de las herramientas de soporte para pruebas.

Proceso XP
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos :
El cliente define el valor de negocio a implementar.
El programador estima el esfuerzo necesario para su implementacin.
El cliente selecciona qu construir, de acuerdo con sus prioridades y las
restricciones de tiempo.
El programador construye ese valor de negocio.
Vuelve al paso 1.

En todas las iteraciones de este ciclo tanto el cliente como el programador

aprenden. No se debe presionar al programador a realizar ms trabajo que el
estimado, ya que se perder calidad en el software o no se cumplirn los plazos.
De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega

del producto, para asegurarse que el sistema tenga el mayor valor de negocio
posible con cada iteracin.