Contenido

2.1 Metodologías clásicas

2.1.1 Cascada

2.1.2 Incremental

2.1.3 Evolutivo

2.1.4 Espiral

2.1.5 Prototipos

2.1.6 Desarrollo basado en componentes

2.2 Otras Metodologías

2.2.1 Ganar-ganar

2.2.2 Proceso Unificado (UP)

2.2.3 Ingeniería Web

2.2.4 Metodologías Ágiles

2.2.5 Metodologías emergentes

2.3 Reingeniería

Evaluación

Examen 60% Tareas y trabajos 30% Participaciones 10% 100%

2.1 Metodologías clásicas

Ingeniería de software

2.1.1 CASCADA

Este modelo tiene una secuencia ordenada.

El trabajo de una etapa previa es la entrada del siguiente proceso.

Provee de un gran control sobre las fechas de entrega y entregables.

Establece criterios de entrada y salida en cada fase claramente

definidos.

Dado que provee pocos puntos de visibilidad da la impresión de que

es lento.

Daniel

Ingeniería de software.

Cascada

Ventajas

Excelente cuando se tiene un producto estable y se conoce la tecnología.

Es un método muy estructurado que funciona bien con gente de poca

experiencia.

Provee estabilidad en los requerimientos.

La planeación se puede hacer anticipadamente.

Para proyectos grandes.

Desventajas

Tiene poca flexibilidad.

Los proyectos en la práctica raramente siguen un flujo secuencial.

Siempre es difícil para el cliente mostrar todos los requerimientos

explícitamente y con mucha anticipación.

El cliente debe tener paciencia.

Es inflexible y no motiva al cambio.

Poco apropiado para aplicaciones para la toma de decisiones.

Los usuarios tienen una participación limitada.

Daniel

2.1.1 CASCADA

Ingeniería de software. 2.1.2 INCREMENTAL

Permite construir el proyecto en etapas incrementales en donde

cada etapa agrega funcionalidad.

Cada etapa consiste de análisis, diseño, codificación y pruebas.

Permite entregar al cliente un producto más rápido en

comparación del modelo de cascada.

Reduce los riesgos ya que:

Provee visibilidad sobre el progreso a través de sus nuevas

versiones.

Provee retroalimentación a través de la funcionalidad

mostrada.

Permite atacar los mayores riesgos desde el inicio.

Se pueden hacer implementaciones parciales si se cuenta con la

suficiente funcionalidad.

Las pruebas y la integración es constante.

El progreso se puede medir en periodos cortos de tiempo.

Resulta más sencillo acomodar cambios al acotar el tamaño de los

incrementos.

Se puede planear en base a la funcionalidad que se quiere

entregar primero.

Daniel

Incremental

Ventajas

• Los clientes no esperan hasta el fin del desarrollo para utilizar el

sistema. Pueden empezar a usarlo desde el primer incremento.

• Los clientes pueden aclarar los requisitos que no tengan claros

conforme ven las entregas del sistema.

• Se disminuye el riesgo de fracaso de todo el proyecto, ya que se

puede distribuir en cada incremento.

• Las partes más importantes del sistema son entregadas primero,

por lo cual se realizan más pruebas en estos módulos y se

disminuye el riesgo de fallos.

Daniel

Incremental

Desventajas

• El modelo Incremental no es recomendable para casos de

sistemas de tiempo real, de alto nivel de seguridad, de

procesamiento distribuido, y/o de alto índice de riesgos.

• Requiere de mucha planeación, tanto administrativa como

técnica.

• Requiere de metas claras para conocer el estado del proyecto.

Daniel

2.1.2 INCREMENTAL

Ingeniería de software. 2.1.3 Evolutivo

La idea detrás de este modelo es el desarrollo de una implantación del

sistema inicial, exponerla a los comentarios del usuario, refinarla en N

versiones hasta que se desarrolle el sistema adecuado.

Las actividades concurrentes son: especificación, desarrollo y

validación y se realizan durante el desarrollo de las versiones hasta

llegar al producto final.

Existen dos tipos de desarrollo evolutivo:

a) Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario

los requisitos hasta llegar a un sistema final. El desarrollo comienza con las

partes que se tiene más claras. El sistema evoluciona conforme se añaden

nuevas características propuestas por el usuario.

b) Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario

y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo

exploratorio, se comienza por definir los requisitos que no están claros para el

usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda

a terminar de definir estos requisitos.

Daniel

Ingeniería de software. 2.1.3 Evolutivo

Ventajas

La especificación puede desarrollarse de forma creciente.

Los usuarios y desarrolladores logran un mejor entendimiento del

sistema. Esto se refleja en una mejora de la calidad del software.

Es más efectivo que el modelo de cascada, ya que cumple con las

necesidades inmediatas del cliente.

Desventajas

Proceso no Visible: Los administradores necesitan entregas para medir

el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo

producir documentos que reflejen cada versión del sistema.

Sistemas pobremente estructurados: Los cambios continuos pueden

ser perjudiciales para la estructura del software haciendo costoso el

mantenimiento.

Para el rápido desarrollo se necesitan herramientas que pueden ser

incompatibles con otras o que poca gente sabe utilizar.

Este modelo es efectivo en proyectos pequeños o medianos con poco

tiempo para su desarrollo y sin generar documentación para cada

versión.

Daniel

2.1.3 EVOLUTIVO

Ingeniería de software

2.1.4 ESPIRAL

El modelo de desarrollo en espiral es actualmente uno de los más

conocidos y fue propuesto por Barry Boehm en 1986.

El ciclo de desarrollo se representa como una espiral, en lugar de una

serie de actividades sucesivas con retrospectiva de una actividad a otra.

Este modelo a diferencia de los otros toma en consideración

explícitamente el riesgo, esta es una actividad importante en la

administración del proyecto.

Utiliza un enfoque evolutivo para la ingeniería de software, puesto que le

permite al desarrollador y al cliente entender y reaccionar conforme a los

riesgos en cada nivel evolutivo. De igual forma, utiliza la creación de

prototipos como un mecanismo de reducción de riesgo. Y conserva

aquellas propiedades del modelo en cascada.

Daniel

Introducción a los sistemas de información.

Espiral

Ventajas

El producto avanza a pasos firmes solucionando riesgos en cada

iteración.

El producto termina con todos los riesgos resueltos.

Se pueden incluir otros métodos de desarrollo en las iteraciones.

A medida que el costo aumenta, los riesgos se reducen.

Se tienen puntos de control en cada interacción.

Desventajas

Es complicado.

Requiere de mucha administración.

Difícil de definir los objetivos, metas que indiquen que podemos

avanzar al siguiente ciclo.

Se puede caer en un desarrollo de nunca acabar.

Daniel

Ingeniería de software

2.1.5 PROTOTIPOS

Un prototipo es una versión preliminar de un sistema de información

con fines de demostración o evaluación.

Es un método menos formal de desarrollo.

El prototipo es una técnica para comprender las especificaciones.

Un prototipo puede ser eliminado.

Un prototipo puede llegar a ser parte del producto final.

Daniel

2.1.4 ESPIRAL

Introducción a los sistemas de información.

Prototipos

Ventajas Útiles cuando los requerimientos son cambiantes.

Cuando no se conoce bien la aplicación.

Cuando el usuario no se quiere comprometer con los requerimientos.

Cuando se quiere probar una arquitectura o tecnología.

Cuando se requiere rapidez en el desarrollo.

Desventajas No se conoce cuando se tendrá un producto aceptable.

No se sabe cuantas iteraciones serán necesarias.

Da una falsa ilusión al usuario sobre la velocidad del desarrollo.

Se puede volver el producto aún y cuando no este con los estándares.

Daniel

http://1.bp.blogspot.com/_yJq64Z_BgdE/Sutwbu95r5I/AAAAAAAAADY/m7ENZmWLnww/s1600-h/prototipo.jpg

Introducción a los sistemas de información. 2.1.6 DESARROLLO BASADO EN

COMPONENTES

El desarrollo de software basado en componentes (DSBC) describe,

construye y utiliza técnicas software para la elaboración de sistemas

abiertos y distribuidos mediante el ensamblaje de partes software

reutilizables.

El DSBC es utilizado para reducir los costes, tiempos y esfuerzos de

desarrollo del software, a la vez que ayuda a mejorar la fiabilidad,

flexibilidad y la reutilización de la aplicación final.

Es referida como una filosofía conocida como “compre, y no

construya” y que abogaba por la utilización de componentes

prefabricados sin tener que desarrollarlos de nuevo.

Etimológicamente hablando, el término “componente” procede de la

palabra cumponere, que en latín significa cum “junto” y ponere

“poner”.

Daniel

Introducción a los sistemas de información. 2.1.6 DESARROLLO BASADO EN

COMPONENTES

Brown 1999. El proceso esta dividido en cuatro etapas:

(a) La selección de componentes.

La “selección de componentes” es un proceso que determina que componentes

ya desarrollados pueden ser utilizados.

(b) La adaptación de componentes.

Debido a que los componentes son creados para recoger diferentes necesidades

basadas en el contexto donde se crearon, estos tienen que ser adaptados

cuando se usan en un nuevo sistema.

(c) El ensamblaje de los componentes al sistema.

A través de una infraestructura bien definida y un estilo determinado: Se procede

a unir los componentes por medio de sus interfaces

(d) La evolución del sistema.

Los componentes pueden evolucionar y actualizarse

Daniel

Introducción a los sistemas de información. 2.1.6 DESARROLLO BASADO EN

COMPONENTES

Desventajas

La sustitución de un componente por otro suele ser una tarea tediosa y que

consume mucho tiempo, ya que el nuevo componente nunca será idéntico al

componente sustituido, y antes de ser incorporado en el sistema, este debe ser

perfectamente analizado de forma aislada y de forma conjunta con el resto de

los componentes con los que debe ensamblar dentro del sistema.

Daniel

2.1.6 DESARROLLO BASADO EN

COMPONENTES