Metodología de Prototipado.

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.

Dentro del campo de la simulación, encontraron grandes dificultades en modelar la estructura y

actividad de los sistemas en estudio.

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).

El prototipo se prueba y modifica cuando es necesario, y los resultados se anotan en la revisión de

los bosquejos y los dibujos en funcionamiento. Los modelos tridimensionales CAD son tan exactos
que, con frecuencia, hacen innecesarios un prototipo físico.

Fases de la Metodología de Prototipado.

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.

 Aplicaciones Existentes (Comparación).

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.

 Especificaciones detalladas y Documentación.

 Después de analizar el paso correcto a seguir con el cliente se debe complementar desarrollando
todo el análisis documentado, con toda la información obtenida por el propio usuario que
determina que procesos de retroalimentación se debe incurrir, para mejorar y plantearle un
ciclo de vida de prototipo al sistema.

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.

 Detalle de las Especificaciones

La necesidad de establecer condiciones al momento de desarrollar el software, se debe tener

en conocimiento de forma detallada, de qué manera el cliente, comprenderá y analizará el
proceso de desarrollo.

 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.

3. Desarrollo del Prototipo.

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

Obteniendo un resultado simplificado según a las especificaciones deseadas y analizadas, el

software debe cumplir con ciertos estándares de desarrollo al momento de ser utilizado, el cual
solo puede ser determinado por el desarrollador y sus planificaciones establecidas con el
cliente.

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.

 Lenguajes no Procedimentales y de Consultas

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.

El procedimiento obtenido se concluye, verificando las salidas de software y las funciones

principales que cumplirá al momento de utilizarlo, ya que de este mismo saldrán nuevos datos,
el cual debe ser analizado nuevamente, porque son de retroalimentación en el sistema.
5. Implantación.

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.

El proceso de retroalimentación que establece este modelo es indispensable, ya que será

independiente de las acciones que se tome en cuenta y el desarrollo de información que
cumplirá el software, después de la construcción con los requisitos planificados desde un
comienzo.

6. Auditoria y Seguimiento.

Cumplir con la parte de comprensión y entendimiento que se desarrolla en el sistema, implica el

proceso de retroalimentación y mejoría para encontrar nuevos y determinados datos a
establecerse.

 Resultados Analizados.

Como el sistema cumple una serie de requisitos fundamentales al momento de al momento de

realizarlo, este debe ser evaluado, de tal manera que en encuentre un nuevo análisis de
desarrollo para que este funcione como retroalimentación, adaptable al cliente y desarrollador.

 Informes del Proceso.

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

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.
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.

EFECTIVIDAD

● Debe ser un sistema con el que se pueda experimentar

● Debe ser comparativamente barato(menor que el 10%)
 ● Debe desarrollarse rápidamente
● Énfasis en la interfaz de usuario
● Equipo de desarrollo reducido
● Herramientas y lenguajes adecuadas

VENTAJAS

● No modifica el flujo del ciclo de vida

● Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios
● Reduce costo y aumenta la probabilidad de éxito
● Exige disponer de las herramientas adecuadas
● 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

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

DESARROLLO EVOLUTIVO- prototipado rápido

Se basa en la creación de una implementación parcial de un sistema, para el propósito explícito de

aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida
tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando
que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentación sobre
lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado.

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.

Existen dos tipos de desarrollo evolutivo:

1. · Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los

requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene
más claras. El sistema evoluciona conforme se añaden nuevas características propuestas
por el usuario.
2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es
comprender los requerimientos del cliente y entonces desarrollar una definición mejorada
de los requerimientos para el sistema. El prototipo se centra en experimentar con los
requerimientos del cliente que no se comprenden del todo.

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

· La especificación puede desarrollarse de forma creciente.

· 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.

· Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que

pueden ser incompatibles con otras o que poca gente sabe utilizar.
Bibliografía

Ingenieria del Software 7ma. Ed. - Ian Sommerville

Unidad I. Diseño de Sistemas. Modelos Evolutivos: Incremental y Espiral. (3K1) UTN-FRT (2011).
Sommerville, 4.1.2 y 4.2