Instrucciones Sql Server

Modelos de desarrollo de software

características comunes características principales Ventajas desventajas

Modelo en cascada Análisis

El analista y el cliente definen todos los requerimientos y su especificación detallada

Diseño

A partir del análisis se diseñan las estructuras de datos, bases de datos, interfaces y procedimientos para dar solución a los requerimientos del cliente.

Codificación

El diseño se traduce a código para la generación del software.

Pruebas

Se hace la revisión del código para comprobar que no tenga errores y realice lo esperado de acuerdo al diseño y al detalle del requerimiento.

Mantenimiento

Esta etapa se realiza después de la entrega del software y sirve para asegurar que el sistema siga funcionando y se da seguimiento a las mejoras que el cliente solicite.

Planear un proyecto antes de embarcarse en él.

Definir el comportamiento externo deseado del sistema antes de diseñar.

Documentar los resultados de cada actividad.

Diseñar un sistema antes de codificarlo

Testear un sistema después de construirlo

Ayuda a localizar errores en las primeras etapas del proyecto a un bajo Costo.

Cuando la revisión determina que el proyecto no está listo para pasar a la siguiente

Las actividades están relacionadas secuencialmente

Cada etapa tiene una entrada y una salida

Es rígido y sistemático: La entrada de una actividad es la salida de la etapa anterior, por lo cual no se puede dar inicio a la siguiente fase.

Es monolítico: Existe una única fecha de entrega.

La implementación se pospone hasta que no se comprendan los objetivos.

Los documentos a entregar rigen el proceso de software Las fases que contempla el modelo de la cascada son al Análisis y especificación de requerimientos, diseño, codificación, integración y pruebas, liberación y mantenimiento.

Es más sencillo planear las actividades del ciclo completo.

La calidad del producto es alta.

Permite trabajar con personal inexperto.

Es el modelo más conocido

Es fácil de aprender.

Una de las contribuciones más importantes del modelo cascada es para los administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.

Ayuda a minimizar los gastos de la planificación ya que no Son necesarios.

Los proyectos reales no siempre siguen el orden que propone este modelo, los cambios pueden causar confusión al equipo del proyecto por la poca interacción que propone el modelo.

Es difícil que el cliente (quien solicitó la construcción del proyecto) exponga todos los requerimientos, y en este modelo se requiere que desde el comienzo del proyecto sean definidos

El cliente deberá ser paciente, ya que verá alguna versión del trabajo hasta que el proyecto esté muy avanzado, y cualquier error que detecte será cada vez más difícil y costoso corregirlo.

Este tipo de modelo genera estados de “bloqueo” cuando una etapa sufre algún retraso, algunos miembros del equipo deberán esperar a otros para completar su actividad.

Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificación o prueba) pueden ser catastróficos para un proyecto grande.

No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos (etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos es luego difícil de acomodar.

El cliente debe tener paciencia ya que el software no estará disponible hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser desastroso, implicando reinicio del proyecto con altos costos

Modelo de construcción de prototipos Recolección de requisitos. Analista y cliente definen la especificación de requerimientos.

Diseño rápido. Se hace el diseño del prototipo.

Construcción del prototipo. En cualquiera de las herramientas seleccionadas.

Evaluación del prototipo. Cliente y usuario revisan el prototipo y generan observaciones.

Refinamiento del prototipo. Las observaciones del cliente y usuarios sirven para mejorar el prototipo que nuevamente es construido y regresa al paso 2.

El ciclo concluye cuando el cliente y el usuario no tienen más observaciones y además el prototipo es claro para el analista y el equipo de desarrollo.

Un prototipo es también un modelo a escala, pero no tan funcional como para que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final, proporcionando una retroalimentación temprana por parte de los usuarios

El prototipo es una aplicación que funciona.

Los prototipos se crean con rapidez.

Los prototipos evolucionan a través de un proceso iterativo.

Los prototipos tienen un costo bajo de desarrollo No modifica el flujo del ciclo de vida.

Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios

Reduce costos y aumenta la probabilidad de éxito.

Exige disponer de las herramientas adecuadas.

Permiten evaluar el objeto antes de que entre en producción para detectar Errores, deficiencias, etc.

Cuando el prototipo está suficientemente perfeccionado en todos los sentidos requeridos y alcanza las metas para las que fue pensado, el objeto puede empezar a producirse.

El prototipo se usa para obtener

Los requerimientos del usuario. Su principal propósito es obtener y validar los requerimientos esenciales, manteniendo abiertas Las opciones de implementación.

Esto implica que se deben tomar los comentarios de los usuarios, pero también se debe volver a los objetivos para no perder la Atención.

El cliente puede confundir las primeras versiones del prototipo con el producto final.

El cliente puede desilusionarse al saber que los prototipos no son el producto y que este aún no se ha construido.

Se requiere compromiso y trabajo del cliente para estar revisando los prototipos.

No se sabe exactamente cuánto será

...