• Author / Uploaded
• Oscar Angeles Sánchez

Citation preview

MODELO/ METODOLOGIA

Cascada

AÑO Y CREADO R Winston W. Royce 1970

ETAPAS

CARACTERISTICAS

VENTAJAS

DESVENTAJAS

APLICACION

 Definición de requisitos.  Diseño del sistema y software  Implementación y prueba de unidades  Integración y prueba del sistema  Funcionamiento y Mantenimiento.

 Se debe comprobar el Software después de unirlo y antes de operarlo.  Es el más utilizado  Deben desarrollarse todas las fases  Las fases continúan hasta que los objetivos se han cumplido

 Realiza un buen funcionamiento en equipos débiles y productos maduros, por lo que se requiere de menos capital y herramientas para hacerlo funcionar de manera óptima.  Es un modelo fácil de implementar y entender.  Está orientado a documentos.  Es un modelo conocido y utilizado con frecuencia.

 Un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.  El proceso de creación del software tarda mucho tiempo ya que hasta que el software no esté completo no se opera. Esto es la base para que funcione bien.  Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y programación del código afectado, aumentando los costos del desarrollo.

Es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase.

Barry Boehm 1986

Espiral

Para cada ciclo:  Determinar objetivos  Análisis del riesgo  Desarrollar y probar  Planificación

 Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente.  Este modelo es el indicado para desarrollar software con diferentes versiones actualizadas como se hace con los programas modernos de PC´s.  La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos.  Este es el enfoque más realista actualmente.

 No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su funcionalidad.  En la terminación de un producto desde el final de la primera iteración es muy factible aprobar los requisitos.  Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos presentados tempranamente y existe la forma de poder corregirlos a tiempo.

 Existe complicación cuando se evalúa los riesgos.  Se requiere la participación continua por parte del cliente.  Se pierde tiempo al volver producir inicialmente una especificación completa de los requerimientos cuando se modifica o mejora el software.

Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel del modelo en espiral. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos.

Gomaa 1984

 Planeación  Modelado  Construcción del

Prototipo  Desarrollo  Entrega y

retroalimentación  Comunicación

con cliente  Entrega del

desarrollo final

Prototipos

Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

 Este modelo es útil

cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.  También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina  Se puede reutilizar el código.

 Administración difícil: Dicha dificultad radica en manejar el prototipo como un proyecto dentro del Ciclo de Desarrollo de Sistema sin perder de vista cuál era su propósito.  Adoptarlo como el sistema final: Los usuarios y profesionales de sistemas pueden considerar al prototipo como el sistema final cuando aún es incompleto e inadecuado.  El desarrollador y el cliente tienen poca comunicación al inicio del proceso.  Surgen cambios imprevistos que retrasan el progreso del prototipo.

Consiste básicamente en que en base a los requerimientos y necesidades que tiene el cliente, se realiza de forma rápida un prototipo, este no vendrá completo ni mucho menos terminado, pero si permitirá contar con las bases necesarias para que cualquier programador pueda seguir trabajando en el hasta llegar al código final.

SAGE 1956

Desarrollo por etapas

 Plan Operativo  Especificación de requisitos  Especificación funcional  Diseño  Implementaci ón  Integración  Validación y verificación  Mantenimient o

Es un modelo en el que el  Requiere poca software se muestra al sofisticación para cliente en etapas los directivos y refinadas sucesivamente. desarrolladores. De esta manera se  Permite desarrolla las capacidades modificaciones a más importantes, medio camino. reduciendo su tiempo de Requiere poco construcción del tiempo de gestión. producto  Genera un sistema altamente fiable y con amplio desarrollo.  Permite una funcionalidad útil en manos del cliente sin tener la aplicación finalizada.  Proporciona signos tangibles de progreso.

 Estar sometido a una planificación predefinida.  Trabaja con poca compresión sobre la arquitectura.  Trabaja con poca identificación de los requerimientos de diseño.  Debe entregarse una etapa para continuar con la siguiente.  Este modelo no es viable sin una planificación adecuada.

El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código.

Mills 1980

Incremental

 Requerimientos  Definición de las tareas y las iteraciones  Diseño de los incrementos  Desarrollo del incremento  Validación de incrementos:  Integración de incrementos  Entrega del producto

 El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos.  Se basa en la filosofía de construir incrementando las funcionalidades del programa.  Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software

 Mediante este  Cada fase de una modelo se genera iteración es rígida y software operativo no se superponen de forma rápida y con otras. en etapas  Pueden surgir tempranas del ciclo problemas referidos de vida del a la arquitectura del software. sistema porque no  Es un modelo más todos los requisitos flexible, por lo que se han reunido, ya se reduce el coste que se supone que en el cambio de todos ellos se han alcance y requisitos. definido al inicio  Es más fácil probar y depurar en una iteración más pequeña.  Es más fácil gestionar riesgos.  Cada iteración es un hito gestionado fácilmente

Este modelo se centra en la entrega de un producto operativo con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación.

James Martin 19801990

RAD

 Modelado de Gestión  Modelado de Datos  Modelado de Proceso  Generación de aplicaciones  Pruebas de entrega

 El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering).  Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.

 Comprar puede ahorrar dinero en comparación con construir.  Los entregables pueden ser fácilmente trasladados a otra plataforma.  El desarrollo se realiza a un nivel de abstracción mayor.  Visibilidad temprana.  Mayor flexibilidad.  Menor codificación manual.  Mayor involucramiento de los usuarios.  Posiblemente menos fallas.  Posiblemente menor costo.  Ciclos de desarrollo más pequeños.

 Comprar puede ser más caro que construir.  Costo de herramientas integradas y equipo necesario.  Progreso más difícil de medir.  Menos eficiente.  Menor precisión científica.  Riesgo de revertirse a las prácticas sin control de antaño.  Más fallas (por síndrome de “codificar a lo bestia”).  Prototipos pueden no escalar, un problema mayúsculo.  Funciones reducidas (por “timeboxing”).  Dependencia en componentes de terceros: funcionalidad de más o de menos, problemas legales.

Esta metodología propone un proceso de desarrollo de "software" que permite que se creen sistemas de computadoras utilizables en un periodo de tiempo entre 60 a 90 días. RAD es un ciclo de desarrollo diseñado para crear aplicaciones de computadoras de alta calidad de las que acontecen en corporaciones grandes. El desarrollo de aplicaciones enfrenta una transformación fundamental. Hace cinco años un proyecto para desarrollar una aplicación tomaba un periodo de entre 18 a 24 meses; actualmente, con la práctica del modelo RAD toma entre 1 a 3 meses.

Davis Sitaram década de 1990

Concurrente

   

Organización Comunicaciones Especificación Desarrollo de producto

 Provee una meta Excelente para descripción del proyectos en los proceso del software. que se conforman El modelo grupos de trabajo concurrente tiene la independientes. capacidad de  Proporciona una describir las múltiples imagen exacta del actividades del estado actual de un software ocurriendo proyecto simultáneamente.  La mayoría de los modelos de procesos de desarrollo del software son dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrará en el proceso de desarrollo. Un modelo de proceso concurrente está dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.

 Si no se dan las condiciones señaladas no es aplicable.  Si no existen grupos de trabajo no se puede trabajar en este método

El modelo de desarrollo concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una división de sistemas y una división de componentes.

IBM Corporati on, de propieda d de Rational Software en 2003.

RUP

   

Inicio Elaboración Construcción Transición

 Los autores de RUP d  Las ventajas de este estacan que el proces modelo son la o de software reducción de propuesto por RUP ti riesgos en el ene tres característica proyecto, la s garantía de calidad, esenciales: estádirigid y la integración o por los Casos de Us entre lo que es o, está centrado en la propiamente arquitectura, y es desarrollo con iterativo e increment mantenimiento de al. software (a base de  1. Proceso dirigido po ir iterando en cada r Casos de Uso fase, combinando  2. Proceso actividades de uno y centrado en la arquit otro tipo). ectura  3. Proceso iterativo e in cremental  4. Estructura Dinámic a del proceso. Fases e iteraciones

 Como desventajas, podemos señalar que requiere una gran previsión sobre lo que va a ocurrir (para poder controlarlo) y que genera abundante trabajo adicional (y costes asociados) de documentación y comunicación, con lo que no suele resultar práctico para proyectos pequeños.

En RUP se han agrupado las actividades en grupos lógicos definiéndose 9 flujos de trabajo principales, los 6 primeros son conocidos como flujos de ingeniería y los tres últimos como flujos de apoyo. o Modelo del Negocio o Requerimiento o Análisis y Diseño o Implementación o Prueba (Testeo o Instalación o despliegue o Administración del proyecto o Administración de configuración y cambios o Ambiente

Ikujiro Nonaka y Takeuchi 1986

SCRUM

 1. Planificación del sprint  2. Etapa de desarrollo  3. Revisión del sprint  4.Retroalimentaci ón

 Gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación, retorno de inversión, mitigación de riesgos, productividad y calidad, alineamiento entre cliente y equipo, por último, equipo motivado.  Se hace uso de equipos autodirigidos y autoorganizados.  Se realiza a diario una reunión de Scrum, que es una reunión de avance diaria que no dura más de 15 minutos con el objetivo de obtener realimentación sobre las tareas del equipo.

 Entregables en tiempo y forma, puedes ir enviando entregables al cliente mientras vas atacando los objetivos más sencillos, eso te hace ganar tiempo para atacar los objetivos más complejos.  el ScrumMaster tiene el conocimiento necesario para lograr el objetivo primario y secundario por lo cual puede ir controlando el proyecto y delegando roles.  Cada persona sabe que es lo que tiene que hacer y no es necesario estar reorganizando una y otra vez los Tracks de cada persona.

 Algunos miembros de tu equipo pueden saltar pasos importantes en el camino rápido para llegar al “sprint” final.  El cliente siempre va a esperar los informes con la fecha exacta, y muchas veces los va a pedir antes, cuando capaz no pudiste avanzar en nada.  Demasiadas Reuniones para poco avance, a veces es muy cansador y estresante reunirse demasiadas veces por el mismo tema, algunos van perdiendo el interés en el proyecto.

En la actualidad, los proyectos se desarrollan en contextos muy versátiles. Son más complejos que antes, frente a unas exigencias del cliente y del mercado mucho más variables, y con una incertidumbre elevada. Por eso, la aplicación del método Scrum se ha extendido como la pólvora en numerosos sectores, fuera del mundo del desarrollo de software

Kent Beck 1999

XP

   

Planeación Diseño Codificación Prueba

 Metodología liviana de desarrollo de software  Conjunto de prácticas y reglas empleadas para desarrollar software  Basada en diferentes ideas acerca de cómo enfrentar ambientes muy cambiantes  Originada en el proyecto C3 para Chrysler  En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto un poco cada vez, a través de todo el proceso de desarrollo

 Da lugar a una programación sumamente organizada.  Ocasiona eficiencias en el proceso de planificación y pruebas.  Cuenta con una tasa de errores muy pequeña.  Fomenta la comunicación entre los clientes y los desarrolladores.  Facilita los cambios.  Permite ahorar mucho tiempo y dinero.  Puede ser aplicada a cualquier lenguaje de programación.  El cliente tiene el control sobre las prioridades.  Se hacen pruebas continuas durante el proyecto.  La XP es mejor utilizada en la implementación de nuevas tecnologías.

 Es recomendable emplearla solo en proyectos a corto plazo.  En caso de fallar, las comisiones son muy altas.  Requiere de un rígido ajuste a los principios de XP.  Puede no siempre ser más fácil que el desarrollo tradicional.

Diseñar, implementar y programar lo más rápido posible, hasta en casos se recomienda saltar la documentación y los procedimientos tradicionales. Se fundamenta en la capacidad del equipo para comunicarse entre sí y las ganas de aprender de los errores propios inherentes en un programador. La gran ventaja de XP es su increíble capacidad de respuesta ante imprevistos, aunque por diseño es una metodología que no construye para el largo plazo y para la cual es difícil documentar. XP es un método estupendo para equipos extremadamente pequeños que se centran en un solo cliente.

Jim Highsmit h 1998

DAS

 Especulación  Colaboración  Aprendizaje

 Iterativo  Orientado a los componentes de SW  Tolerante a los cambios  Guiado por los riesgos  La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo

 Sirve para aprender  Los errores o de los errores y cambios que no son volver a iniciar el detectados en ciclo de desarrollo reuniones  Utiliza información anteriores a tiempo, disponible acerca de afecta la calidad del cambios para producto y a su mejorar el costo total comportamiento  Dado a que es una del SW metodología ágil  Promulga implica no realizar colaboración, la procesos que son interacción de requeridos en las personas metodologías tradicionales

ASD resalta que las aproximaciones secuenciales en cascada solo funcionan en entornos bien conocidos. Pero como los cambios ocurren frecuentemente en el desarrollo software, es importante usar un método tolerante a cambios. El primer ciclo de un proyecto ASD suele ser corto, asegurando que el cliente está involucrado y confirmando la viabilidad del proyecto. Cada ciclo termina con una revisión en grupo enfocada al cliente. Durante las reuniones de revisión, se estudia la aplicación funcionando. El resultado de las reuniones son peticiones de cambio documentadas.