martes, 30 de abril de 2013

PROCESOS DE SOFTWARE


Proceso para el desarrollo de software

Un proceso para el desarrollo de software, también denominado ciclo de vida del desarrollo de software es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe un enfoque diferente para diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un modelo de ciclo de vida un término más general que un determinado proceso para el desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software específicos que se ajustan a un modelo de ciclo de vida de espiral.
  • Primer modelo empleado.
  • También conocido como modelo clásico, modelo tradicional o modelo lineal secuencial.
  • El modelo en cascada puro difícilmente se utiliza tal cual, pues esto implicaría un previo y absoluto conocimiento de los requisitos, la no volatilidad de los mismos (o rigidez) y etapas subsiguientes libres de errores. Esto es utópico debido a que el software tiene un carácter evolutivo, cambiante y difícilmente es libre de errores.3
  • Si sufre algún cambio durante la ejecución en alguna etapa en el modelo en cascado puro implicaría empezar desde 0 todo el ciclo de nuevo, lo cual implica altos costos de tiempo y desarrollo.1
El modelo consta de las siguientes etapas:
  • Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios para los que va destinado el sistema. Se busca hacer esta definición lo más detallado posible.
  • Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican, se describen las abstracciones y relaciones de los componentes del sistema.
  • Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad.
  • Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.
  • Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.4
  • En lugar de usar el modelo en cascada puro, se produce alguna realimentación entre etapas, que no es completamente predecible ni rígida, así no afectando si hay cambios o evoluciones durante el ciclo de vida.
La interacción entre las etapas se muestra en la Figura 1.

EL MODELO EN ESPIRAL

Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.
El modelo en espiral fue desarrollado por Boehm, quien lo describe así:
El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.
Se caracteriza principalmente por:
Ø      Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.
Ø      Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.
El modelo espiral captura algunos principios básicos:
·         Decidir qué problema se quiere resolver antes de viajar a resolverlo.
·         Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
·         Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
·         No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
·         Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles. 
Funcionamiento del modelo Espiral


http://scruz334.blogspot.es/img/espiral.jpg

MODELO INCREMENTAL O EVOLUTIVO
Contiene las siguientes características:
Combina elementos del modelo lineal con la filosofía de creación de prototipos
El primer incremento a menudo es un producto esencial (núcleo)
A partir de la evaluación se planea el siguiente incremento y así sucesivamente
Es interactivo por naturaleza
Es útil cuando el personal no es suficiente para la implementación completa
El modelo incremental
MODELO DE PROTOTIPOS
Este modelo también denominado modelo de desarrollo evolutivo. Para comprender este modelo, comenzaremos con la definición de los objetivos globales para el software, después identificaremos los requerimientos que conocemos y los sitios del diseño en donde es necesaria más definición. Entonces planteamos con rapidez una iteración de construcción de prototipos y se presenta el modelado (en forma de un diseño rápido).
Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez más completas del software.
El diseño rápido se basa en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La iteració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.
CONSTRUCCION DE PROTOTIPOS
A menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. 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 humana – máquina, entonces en este caso cuando utilizamos la construcción de prototipos.

http://scruz334.blogspot.es/img/construcciondeprototipos.gif 
El paradigma de construcción de prototipos se inicia con la comunicación. El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en la forma de un diseño rápido). El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el usuario final. El diseño rápido conduce a la construcción de un prototipo. Después, el prototipo lo evalúa el usuario y con la retroalimentación se refinan los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo se desarrollador entienda mejor lo que se debe hacer.
VENTAJAS:
Ø      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.
Ø      No presenta calidad ni robustez.
Ø      Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniería.
DESVENTAJAS
A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construcción de prototipos se torna problemática por las siguientes razones:
Ø      El cliente ve funcionando lo que para el es la primera versión del prototipo que ha sido construido con “chicle y cable para embalaje”, y puede decepcionarse al indicarle que el sistema aun no ha sido construido.
Ø      El desarrollador puede caer en la tentación de aumentar el prototipo para construir el sistema final sin tener en cuenta los obligaciones de calidad y de mantenimiento que tiene con el cliente.

LINKS:
http://prototipos/Ingenieria%20de%20software%20-%20Monografias_com.htm
http://prototipos/Microsoft%20PowerPoint%20-%20Tema03.htm

No hay comentarios:

Publicar un comentario