UNIDAD ll METODOLOGIAS DE DESARROLLO

2.1 METODOLOGIA CLASICA

Tambin llamado el ciclo de vida clsico, sugiere un enfoque
sistemtico, secuencial hacia el desarrollo del software, que se
inicia con la especificacin de requerimientos del cliente y que
contina con la planeacin, el modelado, la construccin y el
despliegue para culminar en el soporte del software terminado.
El modelo en cascada es el paradigma ms antiguo para la
ingeniera del software. En aos anteriores sus practicantes han
cuestionado su eficacia. Entre los problemas que algunas veces
se encuentran al aplicar el modelo en cascada estn:
1. Es muy raro que los proyectos reales sigan el flujo
secuencial que propone el modelo. A pesar de que el modelo
lineal incluye iteraciones, lo hace de manera indirecta.
2. Con frecuencia es difcil para el cliente establecer todos los
requisitos de manera explcita. El modelo en cascada lo
requiere y se enfrentan dificultades al incorporar las dudas
en el inicio de muchos proyectos.
3. El cliente debe tener paciencia. Una versin que funcione
con los programas estar disponible cuando el proyecto
est muy avanzado. Un error ser peligroso si no se detecta
antes de la revisin del programa.

2.1.2 Incremental
Combina elementos del modelo en cascada aplicado en forma
iterativa.
El modelo incremental aplica secuencias lineales de manera
escalonada. Cada secuencia produce "incrementos" del software.
(ejemplo)
Al utilizar un modelo incremental el primer incremento es un paso
esencial. Es decir, se incorporan los requisitos bsicos, pero no
todas los complementos se incorporan. Se entrega al cliente el
software.
Por ejemplo, el software procesador de texto, desarrollado con el
paradigma incremental en su *primer incremento, podra realizar
funciones bsicas de administracin de archivos, edicin y
produccin de documentos.
*el segundo incremento, ediciones ms sofisticadas, y
tendra funciones ms complejas de produccin de documentos.
*el tercer incremento, funciones de correccin ortogrfica y
gramatical
*y en el cuarto, capacidades avanzadas de configuracin de
pgina.

2.1.3 Evolutivo
Consiste en una versin inicial que luego de exponerse va
evolucionando de acuerdo a las necesidades o nuevos
requerimientos por parte del cliente o del usuario final.
Se caracteriza por: La forma en que permiten desarrollar
versiones cada vez ms completas del software.
Modelos que se clasifican en esta categora:
+Construccin de prototipos
+Modelos en espiral
+Modelo de desarrollo concurrente

2.1.4 ESPIRAL
Representa en forma de espiral, una secuencia de
actividades. Este modelo fue originalmente propuesto por Boehm
en 1988, y se diferencia de los dems modelos por considerar el
riesgo.
El modelo en espiral para la ingeniera de software es actualmente
el enfoque ms realista para el desarrollo de software y de
sistemas a gran escala.
Utiliza un enfoque evolutivo, permitiendo al desarrollador y al
cliente entender y reaccionar ante los riesgos en cada nivel
evolutivo.

El ciclo de vida del modelo en espiral se divide en cuatro

sectores:
1. Definicin de objetivos. En esta fase se identifican las
restricciones del proceso y del producto, y dependiendo los

riesgos para
estratgicos

trazar

objetivos

respectivamente

planes

2. Evaluacin y reduccin de riesgos. Se hace un anlisis

detallado para cada riesgo y se establece los pasos para
reducirlos.
3. Desarrollo y validacin. Elige un modelo para el desarrollo del
sistema.
4. Planificacin. El proyecto se revisa y se decide si debe
continuar con un ciclo posterior de la espiral.

2.1.5 PROTOTIPOS
La construccin de prototipos pertenece a los modelos de
desarrollo evolutivo. El prototipo debe ser construido en poco
tiempo, usando los programas adecuados y no se debe utilizar

mucho dinero pues a partir de que este sea aprobado es que el

desarrollador puede iniciar el verdadero desarrollo del software.
La construccin de prototipos se puede utilizar como un modelo
del proceso independiente. Sin importar la forma en que ste se
aplique, el paradigma de construccin de prototipos ayuda al
desarrollador de software y al cliente a entender de mejor manera
cul ser el resultado de la construccin cuando los requisitos
estn satisfechos
Etapas:
Plan rpido.
Modelado, diseo rpido.
Construccin del Prototipo.
Desarrollo, entrega y retroalimentacin.
Comunicacin.

2.1.6 DESARROLLO BASADO EN COMPONENTES

El modelo de desarrollo basado en componentes incorpora
muchas de las caractersticas del modelo espiral. Es evolutivo
por naturaleza y exige un enfoque interactivo para la creacin del
software. Sin embargo, el modelo de desarrollo basado en
componentes configura aplicaciones desde componentes
preparados de software (clases).
El modelo de desarrollo basado en componentes conduce ala
reutilizacin del software, y la reutilizacin proporciona
beneficios a los ingenieros de software. Segn estudios de
reutilizacin, QSM Associates, Inc. Informa que el ensamblaje de
componentes lleva a una reduccin del 70 % del ciclo de
desarrollo un 84% del coste del proyecto y un ndice de
productividad del 26.2
El uso de este paradigma posee algunas ventajas:

1. Reutilizacin del software. Nos lleva a alcanzar un mayor nivel

de reutilizacin de software.
2. Simplifica las pruebas. Permite que las pruebas sean
ejecutadas probando cada uno de los componentes antes de
probar el conjunto completo de componentes ensamblados.
3. Simplifica el mantenimiento del sistema. Cuando existe un dbil
acoplamiento entre componentes, el desabollador es libre de
actualizar y/o agregar componentes segn sea necesario, sin
afectar otras partes del sistema.
4. Mayor calidad. Dado que un componente puede ser construido
y luego mejorado continuamente por un experto u organizacin,
la calidad de una aplicacin basada en componentes mejorar
con el paso del tiempo

2.2 OTRAS METODOLOGAS

2.2.1 GANAR-GANAR
Modelo basado en la negociacin entre el cliente y el
desarrollador verifica Funcionalidades, rendimiento, calidad, o
simplemente el gestor del proyecto.
Grupo de aplicacin
Se determina la viabilidad de un grupo apropiado de
aplicaciones. En este ciclo se refiri principalmente
en la determinacin que debe tener dicho proyecto.
Objetivos del ciclo de vida
Se desarrollan 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.
Arquitectura del ciclo de vida

 Alcanzar una capacidad operacional inicial para cada

etapa crtica del proyecto en el ciclo de vida del
software.
Capacidad de operacin inicial
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.
CICLOS
Elaboracin del sistema o subsistemas y los objetivos,
Restricciones y alternativas del proceso.
Evaluar las alternativas respecto a los objetivos y
restricciones.
Elaboracin de la definicin del producto y del
proceso.
Planificacin del prximo ciclo y actualizacin de la
planificacin
Del ciclo de vida.
VENTAJAS

Minimiza
Agrega

riesgos
objetivos

del
de

proyecto
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

Es un marco de desarrollo de software que se caracteriza por

estar dirigido por casos de uso, centrado en la arquitectura y por
ser iterativo e incremental.
Caractersticas

INTERACTIVO O INCREMENTAL
Fases: *Inicio *Elaboracin *Construccin *Transicin

Cada fase se subdivide en iteraciones. En cada iteracin se

desarrolla en secuencia un conjunto de disciplinas o flujos de
trabajos.

ITERACIONES
Es prctico dividir el esfuerzo de desarrollo de un proyecto de
software en partes mas pequeas o mini proyectos.
Cada mini proyecto es una iteracin que resulta en un
incremento.
Las iteraciones hace referencia a pasos en el flujo de trabajo, y
los incrementos a crecimientos en el producto.
Las iteraciones deben estar controladas. Esto significa que deben
seleccionarse y ejecutarse de una forma planificada.
Los desarrolladores basan la seleccin de lo que implementarn
en cada iteracin en dos cosas:
La iteracin trata en grupo de casos de uso que juntos
amplan la utilidad del producto desarrollado hasta ahora
La iteracin trata los riesgos ms importantes
En cada iteracin los desarrolladores identifican y especifican los
casos de uso relevantes, crean un diseo utilizando la
arquitectura seleccionada como gua, para implementar dichos
casos de uso. Si la iteracin cumple sus objetivos, se contina
con la prxima. Sino deben revisarse las decisiones previas y
probar un nuevo enfoque.
Las actividades se encadenan en una mini-cascada con un
alcance limitado por los objetivos de la iteracin

BENEFICIOS DEL ENFOQUE ITERATIVO

La iteracin controlada reduce el riesgo a los costes de un
solo incremento.
Reduce el riesgo de retrasos en el calendario atacando los
riesgos mas importantes primero.
Acelera el desarrollo. Los trabajadores trabajan de manera
ms eficiente al obtener resultados a corto plazo.
Tiene un enfoque ms realista al reconocer que los
requisitos no pueden definirse completamente al principio.
Utilizar iteraciones cortas de 2 a 4 semanas incrementa la
productividad del proyecto, dado que el equipo trabaja de forma
ms eficiente cuando tiene objetivos a corto plazo. As mismo,
con iteraciones cortas la precisin de las estimaciones aumenta.
El tamao depende de:
Los condicionantes del proyecto.
La necesidad de tener feedback ms o menos rpido.
Que no se degrade la relacin trabajo til / gestin operativa (por
ejemplo reuniones, actividades necesarias que no producen valor
directo, etc.).
Utilizar iteraciones regulares, de manera que todas sean un
timebox de la misma duracin.

DIRIGIDO POR CASOS DE USO

USUARIO
Alguien o algo como otro sistema fuera del sistema en
consideracin que interacta con el sistema que estamos
desarrollando
El Proceso Unificado usa el Lenguaje de Modelado Unificado
(UML) en la preparacin de todos los planos del sistema.

En el Proceso Unificado los casos de uso se utilizan para capturar

los requisitos funcionales y para definir los contenidos de las
iteraciones
CAPTURA DE REQUISITOS:
cul es el problema?
ANLISIS:
qu debe hacerse? qu sistema debemos construir?
IMPLEMENTACION:
cmo podemos solucionar el problema?
CODIFICACIN:
trasladar el diseo a programas...
PRUEBAS:
... que funcionen...
IMPLANTACIN:
... en un entorno productivo ...
MANTENIMIENTO:
... y que pueden estar sujetos a posibles modificaciones o
mejoras posteriores!
Es un fragmento de funcionalidad del sistema
proporciona el usuario un resultado importante

que

Representan los requisitos funcionales

Todos los casos de uso juntos representan un modelo de
casos de uso el cual describe la funcionalidad total del
sistema
Que debe hacer el sistema para cada usuario?
Pensar en trminos de importancia para el usuario

Los casos de uso no son solo una herramienta para especificar

los requisitos de un sistema.
GUAN EL PROCESO DE DESARROLLO
TAMBIN GUAN
SU DISEO
IMPLEMENTACIN
PRUEBA
Desarrolladores
Basndose en casos de uso crean una serie de modelos de
diseo e implementacin que lleva a cabo los casos de uso y
revisan cada uno de los sucesivos modelos para que sean
conformes al modelo de casos de uso.
Los ingenieros de prueba
Prueban la implementacin para garantizar que los componentes
del modelo de implementacin implementan correctamente los
casos de uso, es decir construyen sus casos de prueba a partir
de los casos de uso
Los casos de usos
Inician el proceso de desarrollo
Guan el proceso de desarrollo
Se desarrollan a la vez que la arquitectura del sistema y
esta influye en la seleccin de los casos de uso

CENTRADO EN LA ARQUITECTURA
La arquitectura software es parecido al papel que juega la
arquitectura en la construccin de edificios, ya que permite al
constructor ver la imagen completa antes de que comience la
construccin

La arquitectura
Incluye los aspectos
significativos

estticos

dinmicos

ms

Siguiere las necesidades de la empresa, como las perciben

los usuarios y los inversores y se refleja en los casos de
uso
Es una vista del diseo completo con las caractersticas
ms importantes resaltadas, dejando los detalles de lado
Se ve influida por muchos factores como:
La plataforma en que tiene que funcionar el software
Los bloques de construccin
consideraciones de implantacin

de

que

se

dispone

Sistemas heredados y requisitos no funcionales

El valor de una arquitectura depende de las personas que se
hayan responsabilizado de su creacin este proceso ayuda al
arquitecto a centrarse en los objetivos adecuados, como la:
Comprensibilidad
La capacidad de adaptacin al cambio
La reutilizacin

INGENIERIA WEB
Introduccin
Las metodologas, tcnicas y herramientas que se utilizan
en el desarrollo de Aplicaciones Web complejas y de gran
dimensin en las que se apoya la evaluacin, diseo,
desarrollo, implementacin y evolucin de dichas
aplicaciones, hacen referencia a la 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
EL PROCESO DE LA INGENIERA WEB
Caractersticas como inmediatez y evolucin y crecimiento
continuos, nos llevan aun proceso incremental y evolutivo,
que permite que el usuario se involucre activamente,
facilitando el desarrollo de productos que se ajustan mucho
lo que ste busca y necesita.
Qu es Ingeniera Web?
Ingeniera Web es el proceso utilizado para crear y mantener
aplicaciones y sistemas web de alta calidad, como tambin es una
filosofa idntica a ingeniera de software.
ETAPAS DE LA INGENIERA WEB
Proceso de Ingeniera Web
Formulacin: Identifica objetivos
alcance de la primera entrega

Establece

el

Planificacin: Genera estimacin de costo, Evaluacin

de riesgo, Calendario de desarrollo y fechas de entrega
Anlisis: Especifica los requerimientos e Identifica el
contenido
Modelizacin: Consta de dos partes:
1.-Diseo y produccin del contenido
2.-Diseo de la arquitectura, navegacin e interfaz del
usuario.

 Generacin de Pginas: Se integran arquitectura,

navegacin, e interfaz para la creacin ms visible del
proyecto: las pginas.
Test: Pruebas que buscan errores en todos los niveles:
Contenido, funcional, navegacional, etc.
Evaluacin del Cliente: Se integran arquitectura,
navegacin, e interfaz para la creacin ms visible del
proyecto: las pginas
EL EQUIPO DE INGENIERA WEB
Mescla una amplia variedad de talentos que deben trabajar como
equipo en un ambiente de proyecto con alta presin. Los plazos
son cortos y la tecnologa continua cambiando

METODOLOGAS EMERGENTES.
Metodologa: Es el conjunto de mtodos que se utilizan en una determinada actividad con
el fin de formalizarla y optimizarla. Determina los pasos a seguir y cmo realizarlos para
finalizar una tarea.
Emergente o el surgimiento hace referencia a aquellas propiedades o procesos de
un sistema.
La metodologa emergente es cuando si permite adaptar la forma de trabajo a las
condiciones del proyecto.
Por qu?

Modelos estudiados difciles de aplicar a la realidad.

Requisitos poco claros.
Requisitos poco estables.
Elevado costo de introducir cambios durante el desarrollo.
Elevado riesgo en contratos de desarrollo de software.

Ventajas
Las metodologas emergentes motivan ms a los equipos de trabajo.
El principal beneficio del diseo orientado a objetos es que proporciona un
mecanismo para formalizar modelos de la realidad.
Evita mal entendidos de requerimientos entre el cliente y el equipo.
El uso del modelo orientado a objetos alienta la reutilizacin no solo del software,
sino de diseos completos.
Proporcionan mejores resultados en los proyectos de alto riesgo.
Desventajas

Problemas derivados de la comunicacin oral.

Este tipo de comunicacin resulta difcil de preservar cuando pasa el

tiempo y est sujeta a muchas ambigedades.

Falta de calidad.

Probar el cdigo de manera constante no genera productos de calidad,

solo revela falta de anlisis y diseo.

Programacin eXtrema (XP).

La programacin extrema o eXtreme Programming (XP) es una metodologa formulada
por Kent Beck y Ian Sommerville.
Caractersticas.

Se diferencia porque pone ms nfasis en la adaptabilidad.

Software que funcione es ms importante que documentacin exhaustiva.

La respuesta ante el cambio es ms importante que el seguimiento de un plan.

Los 4 valores de la metodologa XP.

Simplicidad.
Se simplifica el diseo para agilizar el desarrollo y facilitar el mantenimiento.

Comunicacin.
Para los programadores el cdigo comunica mejor cuanto ms simple sea.

Retroalimentacin (feedback).
Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se
conoce en tiempo real.

Coraje o valenta.
Una de ellas es siempre disear y programar para hoy y no para maana.
Roles xp.
1. Programador
Debe existir una comunicacin y coordinacin adecuada entre los programadores y otros
miembros del equipo.
2. Cliente
El cliente escribe las historias de usuario y las pruebas funcionales para validar su
implementacin.
3. Encargado de pruebas (Tester)
El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.
4. Encargado de seguimiento (Tracker).
El encargado de seguimiento proporciona realimentacin al equipo en el proceso XP. Su
responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el
tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.
5.

Entrenador (Coach)

Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para
proveer guas a los miembros del equipo de forma que se apliquen las prcticas XP y se
siga el proceso correctamente.
6.
Consultor
Es un miembro externo del equipo con un conocimiento especfico en algn tema
necesario para el proyecto. Gua al equipo para resolver un problema especfico.
7. Gestor (Big boss)
Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente
creando las condiciones adecuadas. Su labor esencial es de coordinacin.
Ventajas y desventajas de la metodologa XP.
VENTAJAS:

Programacin organizada.

Menor taza de errores.

DESVENTAJAS:

Es recomendable emplearlo solo en proyectos a corto plazo.

REINGENIERA.
Es la transformacin sistemtica de un sistema existente dentro de una nueva forma de
realizar mejoramientos de calidad en unas operaciones, capacidad del sistema,
funcionabilidad, rendimiento o evolucionabilidad a bajo costo, agendas o riesgos para el
cliente.
Quien la hace la reingeniera?
En el mbito de software la reingeniera la realiza un ingeniero de software.
Por qu es importante?
Se vive en un mundo en cambio constante, las demandas acerca de las funciones de
negocios la tecnologa de la informacin que las soporta est cambiando a un ritmo que
impone una enorme presin competitiva en las organizaciones comerciales. Tanto en el
negocio como el software que soporta (o es) el negocio de redisearse para mantener el
ritmo.

 Anlisis de inventarios.
Las organizaciones de software deberan tener un inventario tal vez no sea ms
que un modelo en una hoja de clculo que contenga informacin que proporcione una
descripcin detalladas de las aplicaciones activas.
Al ordenador esta informacin de acuerdo con la importancia para el negocio,
antigedad, facilidad actualmente de mantenimiento y otros criterios localmente
importantesaparecen los candidatos para reingeniera.

Reestructuracin de documentos.
La documentacin dbil es la marca de muchos sistemas heredados
1. Crear documentacin consume muchsimo tiempo:
El sistema funciona vivir con lo que tenga. En algunos casos este es el enfoque
correcto. No es posible recrear documentacin para cientos de programas de
computadoras, si un programa es relativamente esttico est llegando al final de su vida
til, djalo ser!.
2. La documentacin debe actualizarse, pero se tiene recursos limitados:
Se documenta completamente aquellas porciones del sistema que en la actualidad
experimenta cambios, con el tiempo evolucionara una coleccin de documentacin til y
relevante.
3. El sistema es crucial para el negocio y de volver a documentarse por completo.
Incluso en este caso un enfoque inteligente es recortar la documentacin a un mnimo
esencial
CONSEJO:

Cree solamente tanta documentacin como necesite para entender el software, ni

una pgina ms.

Ingeniera inversa.
La ingeniera inversa es el proceso de recuperacin de diseo. Las herramientas de la
ingeniera inversa obtienen informacin del diseo de datos, arquitectnicos y de
procedimientos a partir de un programa existente.

Restauracin de cdigo.
Llevar a cabo esta actividad requiere analizar el cdigo fuente empleando 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.

Restauracin de Datos.
Es una actividad de reingeniera a gran escala. En la mayora de los casos, la
reestructuracin de datos comienza con una actividad de ingeniera inversa. La
arquitectura de datos actual se analiza con minuciosidad y se define los modelos de datos
necesarios, se identifican los objetivos de datos y los atributos, y despus se revisa la
calidad de las estructuras de datos existentes.

Ingeniera directa.
La ingeniera directa no solo recupera la informacin de diseo a partir del software
existente, tambin utiliza esta informacin para alterar o reconstruir el sistema existente
con la finalidad de mejorar su calidad global. En la mayora de los casos el software
sometido a reingeniera vuelve a implementar la funcin del sistema existente y tambin
aade nuevas funciones o mejoras en el desempeo global.