Post on 13-Jun-2015
description
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
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