Beruflich Dokumente
Kultur Dokumente
Introducción.
Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica
los requisitos detallados, proceso o salida. En otros casos el responsable del software puede no estar
seguro de la eficacia de un algoritmo, de la capacidad de adaptación de un sistema operativo o de
la forma en que debería tomarse la interacción hombre-máquina. En estas y en otras muchas
situaciones un paradigma de construcción de prototipos puede ofrecer el mejor enfoque.
Descripción.
El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan
rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que
el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como también la
solución que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre
en el desarrollo, este modelo se encarga del desarrollo de diseños para que estos sean analizados y
prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance
del producto, pero no se asegura su uso real.
Este modelo principalmente se lo aplica cuando un cliente define un conjunto de objetivos generales
para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada
procesamiento y salida, es decir cuando el responsable no está seguro de la eficacia de un algoritmo,
de la adaptabilidad del sistema o de la forma en que interactúa el hombre y la máquina. Este modelo
se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor
manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos.
Antecedentes.
A finales de los cuarenta y principios de los cincuenta, kristen Nygaard y Ole-Johan Dahl se unen a
un proyecto de cálculos de absorción por resonancia, para la construcción del primer reactor
nuclear.
En los sesenta Nygaard se fue al Norwegian Computing Center (NCC) para hacerle frente al reto,
posteriormente se unieron Dahl y Bjrn Myhrhaug.
Nygaard observo que varios proyectos civiles presentaban problemas metodológicos similares a los
que ellos enfrentaban en el ámbito militar.
Reseña Histórica.
En contraste con la ingeniería de software de la década de los setenta, que dio respuesta a proyectos
grandes pero con requisitos estables, la ingeniería de software de los ochenta reacciono a las
complicaciones resultantes de encontrarse con requisitos poco claros y dinámicos, dando lugar a la
construcción de prototipos.
El modelo de ciclo de vida de prototipos fue propuesto por Gomaa en 1984. Un prototipo es un
mecanismo para identificar los requisitos del software. La construcción de prototipos es un proceso
que facilita al ingeniero de software el desarrollo de la aplicación.
Funcionamiento
A menudo se construye un modelo tridimensional CAD o un modelo a escala para estudiar, analizar
y refinar un diseño. Un prototipo es un modelo en funcionamiento en tamaño real y construido de
acuerdo con todas las especificaciones finales (exceptuando tal vez de los materiales).
1. Definición de Especificaciones.
Cumplir con el proceso principal e inicial de desarrollar un sistema que cumpla con las necesidades
del cliente, determina el análisis y modelo que se puede mostrar en poco tiempo, con la planificación
que determina entre el analista y el cliente.
Planes de Trabajo
El desarrollo inicial que debe cumplir para llevar acabo un sistema concreto es el análisis general
y la idea principal que debe establecerse junto con el cliente, de una forma rápida y criteriosa,
ya que se determina el proceso a llevarse a cabo, por medio de un desarrollo de
retroalimentación en el software.
Una parte importante del análisis es que, se debe cumplir con ciertos requisitos indispensables
para desarrollar el software enlazado con el cliente, y esto se determina por otras aplicaciones
existentes que ayudan a determinar el proceso que se desea seguir, con los recursos que se
posee principalmente.
2. Diseño Conceptual.
El proceso de análisis debe estar enlazado con la determinación específica del sistema,
desarrollando el proceso manual de planeamiento y utilización de modelados que debe cumplir con
las necesidades del cliente específicamente.
Macromodelo de Actividades.
Con la planificación especifica del desarrollador y el cliente, se debe establecer los procesos y
pasos de realización del software con las especificaciones de retroalimentación de forma
documentada.
Herramientas de Modelado.
Determinamos que recursos se puede utilizar de acuerdo a las especificaciones que planifica el
desarrollador, cumpliendo con las características que brinda el cliente, cubriendo
completamente con las necesidades que se debe incurrir.
Una de las partes fundamentales en un software, es el proceso de programación por parte del
desarrollador, y más aún si está establecida por un proceso de metodología de prototipado, ya que
este tiene un estándar rápido según los recursos que se pueda poseer y determinar por medio de
este mismo y el cliente.
Descripción de entradas/salidas
Refiriéndose por partes a la arquitectura del sistema, este debe cubrir cada especificación de
cumplirá el sistema, ya que este mismo al ser ejecutado, solo cumplirá una función principal,
que utilizara el usuario, pero a su vez, internamente estará divido en varias funciones que
cumplen con sus propósitos específicos internos. (Sistemas de farmacia: venta, consultas,
reportes).
Modelo de datos
Estableciendo la capacidad de información determinado por el cliente, se debe cumplir con el
proceso de desarrollo de software (programación), cumpliendo con los estándares de este
mismo y la herramienta principales a utilizar, según los factores que debe cumplir este software.
Lenguajes de Desarrollo
Para que se establezca el desarrollo del software, el estándar principal que debe cumplir es las
herramientas adecuadas que se utilizara el desarrollador, ya que este debe ser adaptable y
complementario al resultado que se desee obtener en el cliente, ya que en esta parte la
retroalimentación cumplirá un papel importante al momento que sea programable (editable
según al lenguaje de programación).
Prototipo normalizado
4. Pruebas de usuario.
Por ser un modelo de prototipado rápido, este fue determinado con el cliente, el proceso y
desarrollo y la necesidad que debe cubrir, de la misma forma este deber ser probado por el usuario
(cliente), y establecer un punto de retroalimentación, ya que posea un ciclo de vida prototipado.
Prototipo normalizado
Para que el usuario pueda realizar el proceso de prueba según el resultado simplificado que se
obtuvo es necesario, el análisis determinado por el software. Ya que el desarrollador comprueba
los estándares que debe cumplir el sistema.
Trabajando de la mano con el usuario, este permitirá llevar a cabo las tareas de consulta o
modificación de los datos contenidos en las Bases de Datos del Sistema Gestor de Bases de
Datos, ya que es proceso de desarrollo es por medio de un modelo.
Datos Resultantes.
La importancia de esta parte son los aspectos de satisfacción que puede cumplir el sistema, ya que
el cliente analiza el proceso que lleva a realizar el software, pero no determinara el proceso de
entradas y salidas que produce dicho sistema.
Resultados Analizados.
6. Auditoria y Seguimiento.
Resultados Analizados.
Los resultados finales de la metodología del sistema, implicaran una serie de datos extras, el
cual es necesario un nuevo análisis completo para determinar los procesos finales obtenidos, y
encontrar una nueva mejora para determinar un servicio adaptable que cumpla con las
necesidades específicas que se tiene en el sistema.
PARADIGMA DE CONSTRUCCIÓN DE PROTOTIPO
EFECTIVIDAD
VENTAJAS
DESVENTAJAS
● Debido a que el usuario ve que el prototipo funciona piensa que este es el producto
terminado y no entienden que recién se va a desarrollar el software.
● El desarrollador puede caer en la tentación de ampliar el prototipo para construir el sistema
final sin tener en cuenta los compromisos de calidad y mantenimiento que tiene con el
cliente
Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y
complejas, hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante la fase de
operación. Los modelos “Iterativo Incremental” y “Espiral” (entre otros) son dos de los más
conocidos y utilizados del tipo 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.Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya
que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.
Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en
comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del
cliente, a la vez que él mismo entiende mejor sus propios requerimientos.
VENTAJAS
· 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.
Unidad I. Diseño de Sistemas. Modelos Evolutivos: Incremental y Espiral. (3K1) UTN-FRT (2011).
Sommerville, 4.1.2 y 4.2