LABORATORIO

DE ANÁLISIS I

Lic. Galia Serruya

Universidad Atlántida Argentina
Prototipo

Un PROTOTIPO DE SOFTWARE es una

implementación parcial o posible de un nuevo

producto propuesto.
Prototipo

El prototipo:

Se desarrolla rápidamente y con

bajo presupuesto.

Es un modelo del SW a construir.

Prototipos
Prototipo

Se utiliza cuando hay gran incertidumbre sobre

los requerimientos o cuando se requiere un
feedback temprano del usuario.

Se puede combinar con otras técnicas (base

para un grupo de discusión) o como base de un
cuestionario.
Prototipo

Ciclo para un prototipo:

Se arma el prototipo.

Se le entrega al usuario para que lo use.

Retroalimentación. Se identifican
requerimientos y se realizan las
modificaciones propuestas.

Se repiten los pasos mientras sea necesario.

Prototipo

¿Cuándo usar un prototipo?

Si no hay conocimiento sobre los

requerimientos.

Cuando el usuario no tiene idea de lo que

necesita.

Al utilizar nuevas tecnologías.

Si no se puede determinar la viabilidad de

un proyecto.
Prototipo

Algunos resultados posibles:

Se deshecha al terminar la identificación de

requerimientos.

Evoluciona para convertirse en la aplicación.

Se determina la inviabilidad de un proyecto.

Prototipo
Un prototipo tiene varios objetivos:
Clarificar y completar los requerimientos: La
evaluación de un prototipo permite identificar
problemas con los requerimientos.

Explorar alternativas de diseño, cuando es usado

como herramienta de diseño.

Evolucionar hasta el producto final, cuando es

usado como herramienta de construcción.

Facilitar la validación de los requerimientos.

Prototipos
La principal razón de un prototipo es resolver las
incertidumbres en una fase temprana del proceso
de desarrollo. Tener esto en cuenta para decidir
qué prototipar.

Es útil para revelar y resolver problemas de

ambigüedad e incompletitud en los
requerimientos. También cuando las
características del Sw son desconocidas o en parte
no identificables.
Prototipos

Distintos tipos de prototipos:

Horizontales: En general son de interfaz de usuario
(prototipo de comportamiento). Se lo llama horizontal
porque no profundiza en las distintas capas que puede
tener el producto a desarrollar. Es la “carcaza”. Suele
demostrar las opciones de funcionalidad que tendrá el
sistema, el look and feel de las pantallas, etc. No
realizan ninguna acción real, se simulan.
Prototipos

Verticales: Se los llama también estructurales porque

implementan una parte de la funcionalidad, desde la
interfaz de usuario hasta los servicios.

Se usan cuando se tiene incertidumbre sobre un

diseño de arquitectura, o de una determinada BD. Se
construyen para evaluar también requerimientos de
respuesta y para reducir riesgos en el diseño.
Prototipos
Descartables (exploratorios): Se construyen para resolver
incertidumbre, mejorar la calidad de los requerimientos.
Como se descartan una vez cumplido el propósito deben
poder ser construidos rápidamente y tan barato como sea
posible. No son construidos con calidad, pues prima la
rapidez y el costo.

Son riesgosos desde el punto de vista que debe quedar

bien claro que es descartable. Y no debemos ceder ante la
presión del usuario / cliente de agregar más funcionalidad
que la necesaria para cumplir con el objetivo con el que
fue creado.
Prototipos

Evolutivos: A diferencia del anterior constituye

una base para el desarrollo del producto, el cual
se va construyendo incrementalmente. Es parte
del ciclo de vida en espiral. Debe ser construido
con calidad. Lleva más tiempo que el descartable.
Prototipos

Cómo pueden construirse los prototipos?

Pueden ser en papel o electrónicos.

En papel: económico y rápido.

Electrónicos: dependiendo del tipo de prototipo

elegido se utilizan diferentes herramientas: una
herramienta de diseño de pantallas, lenguajes de
scripting, lenguajes de programación.
Prototipos
Para la fase de Requerimientos: ¿qué tipo de
prototipo es factible construir?
Es necesario guiar al usuario en la ejecución del prototipo
para que lo pueda evaluar.

Preguntas a responder:
Cumple con la funcionalidad esperada?

Hay alguna funcionalidad omitida?

Hay condiciones de error que no se ven en el prototipo?

Hay funcionalidad innecesaria?

Cómo se ve la navegación?

Hay tareas demasiado complejas?

Prototipos

Factores de Éxito:

Incluir las tareas de prototipación en el plan del

proyecto.

Dejar claro el objetivo.

No prototipar requerimientos ya comprendidos.

No esperar que el prototipo reemplace la ERS.

Prototipos
Los pasos para el proceso iterativo:
Identificar requerimientos que el usuario conoce.

Construir un prototipo.

Es evaluado por el cliente para una retroalimentación.

Refinar los requisitos del software, ajustar el prototipo para

satisfacer las necesidades del cliente. Si es necesario volver a
comenzar una nueva iteración.

Esto permite que al mismo tiempo el desarrollador

entienda mejor lo que se debe hacer y el cliente vea
resultados a corto plazo.
Ventajas
Es útil cuando el cliente no identifica los requisitos
detallados de entrada, procesamiento o salida.

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.

Ayuda al desarrollador de software y al cliente a entender

de mejor manera cuál será el resultado de la construcción
cuando los requisitos estén satisfechos.
Prototipos - Riesgos
El mayor riesgo con un prototipo electrónico descartable es que
el usuario piense que ya está el sistema, cuando aún queda la
fase de construcción y prueba.

Otro riesgo es el de focalizarse en la interfaz de usuario en vez

de hacerlo en la funcionalidad.

Un tercer riesgo es que el usuario lo vea con mala performance

y no le guste, cuando en realidad no es el sistema real.

Y por último, balancear costo – beneficio. Hacer un prototipo

puede llevar tiempo y consume presupuesto del proyecto.
Conclusiones
A pesar de que tal vez surjan problemas, la construcción de
prototipos puede ser un paradigma efectivo para la ingeniería
del software. La clave es definir las reglas del juego desde el
principio; es decir, el cliente y el desarrollador se deben
poner de acuerdo en que:
El prototipo se construya y sirva como un mecanismo para la
definición de requisitos.

El prototipo se descarte, al menos en parte.

Después se desarrolle el software real con un enfoque de

calidad.
Preguntas