Make your own free website on Tripod.com
E-Clases
Ingenieria de Software II
Home
SIA: Definiciones
SIA: Centros de Cómputo
SIA: Areas de Administracion de un CC
SIA: Técnicas y sistemas de gestión de la innovación
Matematicas
SIA II - Proyecto
Códigos para Programadores
Bases de Datos I
Diseño Páginas Web
Curso de Ingles Diciembre 2003
Ingles Tecnico
CENAFOM - Computación 02076
Ingenieria de Software I
Ingenieria de Software II
Ingenieria de Software III
Ingenieria de Software IV
Ingenieria de Software V
Ingenieria de Software VI
Ingenieria de Software VII
Ingenieria de Software VIII
Ingenieria de Software IX
Ingenieria de Software X
Ingenieria de Software XI
Encuestas y Libro de Visitas
Sitios Web
De todo Un Poco
Servicio Tecnico
Nuestros Clientes
Trabajos
Introducción a la Programación

clases2.jpg

Modelos de Desarrollo de Software

Modelo construye y compone

Este es el primer modelo de ciclo de vida que se usó y probablemente el más usado. El software se desarrolla sin especificar requerimientos y sin diseño. Luego el software cambia tantas veces como sea necesario hasta que satisface al cliente. Esto trabaja muy bien para programas pequeños y sencillos, pero es completamente insatisfactorio para sistemas de software de cualquier tamaño. Ha sido demostrado que el costo de cambiar un producto de software es relativamente pequeño si el cambio se hace en las fases de requerimientos o diseño y crece mucho en fases posteriores. El mantenimiento también puede ser muy problemático para un sistema desarrollado bajo este escenario.

inge5.gif

Modelo construye y arregla

Modelo de cascada (waterfall)

  • Derivado de otros procesos de ingeniería en 1970.
  • Hace el proceso de desarrollo mas estructurado.
  • Expresa la interacción entre las fases subsecuentes.
  • El modelo original es estrictamente secuencial. Esto significa que cada fase debe terminar para que la siguiente pueda comenzar. El punto crítico es que una fase no ha terminado hasta que la documentación y/o otros productos asociados con esa fase hayan sido completados. Por lo tanto dos fases no se pueden empalmar en el tiempo.
  • No establece retroalimentación entre fases, ni redefinición de fases anteriores.

inge6.gif

Modelo de cascada

Modelo de cascada modificado

  • Se inventó para permitir retroalimentación y encimamiento entre fases.
  • Es un modelo iterativo y no lineal.
  • Para facilitar la terminación de metas y tareas, es normal congelar partes del desarrollo después de cierto punto en la iteración.
  • Se agregaron los pasos de verificación (checar que el sistema es correcto, construir el sistema correctamente) y validación (checar que el sistema cumple con los deseos del cliente, construir el sistema correcto).

inge7.gif

Modelo de cascada modificado

El modelo de la cascada (y el de la cascada modificada) son inflexibles en el particionamiento del proyecto en sus distintas fases. Sin embargo, generalmente reflejan la práctica de la ingeniería.

Modelo de construcción de prototipos

El paradigma de construcción de prototipos tiene tres pasos:

  1. Escuchar al cliente. Recolección de requisitos. Se encuentran y definen los objetivos globales, se identifican los requisitos conocidos y las áreas donde es obligatorio más definición.
  2. Construir y revisar la maqueta (prototipo).
  3. El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software.

inge8.gif

Modelo de construcción de prototipos

Este modelo es útil cuando:
  • El cliente no identifica los requisitos detallados.
  • El responsable del desarrollo no está seguro de la eficiencia de un algoritmo, sistema operativo o de la interface hombre-máquina.
Su principal desventaja es que una vez que el cliente ha dado su aprobación final al prototipo y cree que está a punto de recibir el proyecto final, se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional, porque lo más seguro es que el desarrollador haya hecho compromisos de implementación para hacer que el prototipo funcione rápidamente. Es posible que el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, que esté escrito en un lenguaje de programacion inadecuado.

Modelo RAD (Diseño Rápido de Aplicaciones)

Es un modelo de proceso de desarrollo de software de cascada que enfatiza un ciclo de desarrollo extremadamente corto. Este modelo se puede usar si:

  • Se comprenden bien los requisitos y se limita el ámbito del proyecto.
  • Es fácil dividir al sistema en módulos.
  • Se utiliza un enfoque de construcción basado en objetos reusables.
Tiene algunas desventajas:
  • Requiere recursos humanos suficientes como para crear el número correcto de equipos.
  • Necesita que el cliente y el desarrollador se comprometan en las actividades necesarias para completar un sistema en un tiempo corto.

Modelos evolutivos

Esta familia de modelos se utilizan en las siguientes circunstancias:

  • Si los requisitos cambian conforme el desarrollo avanza.
  • Si las fechas de mercado hacen imposible tener un producto completo y hay que introducir una versión limitada.
  • Si los requisitos centrales están bien definidos pero todavía hay que definir los detalles de las extensiones del producto.
  1. Modelo incremental

    • Combina elementos del modelo de cascada (aplicados repetitivamente) con la filosofía interactiva de construcción de prototipos.
    • El primer incremento es un producto esencial (núcleo), se afrontan requisitos básicos y muchas funciones extras (conocidas o no) quedan para los siguientes incrementos.
    • El cliente usa el producto central y en base a la utilización y/o evaluación se desarrolla un plan para el incremento siguiente.
    • Este proceso se repite hasta que se elabora el producto completo.
    • Es interactivo, al igual que el de construcción de prototipos y otros enfoques evolutivos. Pero a diferencia del modelo de construcción de prototipos, el modelo incremental entrega un producto operacional en cada incremento.
    • Es útil cuando la dotación de personal no está disponible para una implementación completa. El primer incremento se pueden implementar con pocas personas. Si el producto central es bien recibido, se puede añadir mas personal.

  2. Modelo de la espiral de Boehm

    • Combina los elementos controlados y sustemáticos del modelo de cascada con la filosofía interactiva de construcción de prototipos.
    • Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. El software se desarrolla en una serie de versiones incrementales.
    • Durante las primera iteraciones, la versión incremental puede ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema.
    • El modelo se divide en un número de actividades estructurales llamadas regiones de tareas que pueden ser de tres a seis. Pressman define las siguientes regiones de tareas:
      • Comunicación con el cliente.
      • Planeación. Define recursos, tiempo y otras informaciones relacionadas con el proyecto.
      • Análisis de riesgos. Evalúa riesgos técnicos y de administración.
      • Ingeniería. Construye una o más representaciones de la aplicación.
      • Construcción y adaptación. Construye, prueba, instala y proporciona soporte al usuario (p.e. documentación).
      • Evaluación del cliente.
    • Cada región tiene tareas que se adaptan a las características del proyecto.
    • El primer circuito de la espiral produce una especificación de productos; los pasos siguientes en la espiral se podrían usar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software.
    • Cada paso por la región de planificación produce ajustes en el plan del proyecto.
    • El costo y la planificación se ajustan según la reacción ante la evaluación del cliente.
    • A diferencia del modelo de vida clásico que termina cuando se entrega el software, el modelo en espiral se puede adaptar y aplicarse a lo largo de toda la vida del software.

    Su principal desventaja es que es nuevo (1988) y no se ha utilizado tanto como otros modelos de ciclo de vida. Además puede resultar difícil convencer a algunos clientes que el proceso es controlable.

inge9.gif

inge10.gif

Modelo tradicional de la espiral de Boehm

    1. Modelo de ensamblaje de componentes
    2. Incorpora muchas de las características del modelo en espiral. Es evolutivo y exige un enfoque interactivo para la creación de software.
    • La región de tarea de ingeniería comienza con la identificación de las clases candidatas, luego se buscan en la bliblioteca de clases, si existen entonces se vuelven a usar. Si alguna clase no existe, se construye y se deposita en la biblioteca de clases.
    • Su principal ventaja es la reutilización del software.

    1. Modelo de desarrollo concurrente
    2. En vez de confinar las actividades de ingeniería de software a una secuencia de pasos, define una red de actividades.
    • Todas las actividades de la red existen simultáneamente con otras.
    • Los sucesos generados dentro de una actividad, o en algún otro lado de la red de actividad, inician las transiciones entre los estados de otra actividad.
  • Modelo de métodos formales

    • Permiten especificar, desarrollar y verificar un sistema aplicando una notación rigurosa y matemática.
    • Eliminan muchos de los problemas que son difíciles de superar con otros paradigmas. La ambiguedad, la incompletez y la inconsistencia se pueden descubrir y corregir, no mediante una revisión, sino mediante la aplicación del análisis matemático.
    • Su principal desventaja es que requiere que el desarrollador y el cliente tengan conocimientos formales para poderlos aplicar y comunicarse entre sí.

    Técnicas de cuarta generación (4GT)

    • Permite especificar el software usando lenguajes especializados o notaciones gráficas que describan el problema.
    • Requiere usar alguna herramienta CASE (Computer-aided Software Engineering) con herramientas tales como: SQL (Structured Query Language), generador de reportes, base de datos, definidores de pantallas, generadores de código, generador de gráficas, hoja de cálculo, etc.
    • Idealmente el cliente describe los requisitos, que son traducidos inmediatamente a un prototipo operativo.
    • En aplicaciones pequeñas, se puede ir directamente a la implementación usando un lenguaje de cuarta generación (4GL).
    • El aplicaciones grandes, el uso de 4GL sin diseño provocará los mismos problemas que los otros paradigmas (poca calidad, mantenimiento pobre y mala aceptación del cliente).
    • El uso de 4GL permite al desarrollador centrarse en la representación de los resultados deseados.
    • Para transformar una implementación 4GT en un producto, el desarrollador debe dirigir una prueba completa, hacer una buena documentación y ejecutar el resto de las actividades de integración requeridas en los otros paradigmas. Además, el software desarrollado con 4GT debe ser construido de modo que facilite el mantenimiento.

    Enter content here

    WorldPrime Computacion (C) 2004