Buscar en Gazafatonario IT

viernes, julio 20, 2012

Ventajas y Desventajas del Uso de Prototipos


Algunas Ventajas del uso de prototipos

1.       Permiten el desarrollo de un sistema a partir de requisitos poco claros o cambiantes. Esto ocurre con cierta frecuencia en muchos proyectos de software.
2.       Como información complementaria a los requisitos constituyen un gran apoyo a las estimaciones de esfuerzo de todas las áreas, incluyendo proveedores.
3.       Son más fáciles de abordar con los usuarios finales.
4.       El usuario participa más activamente en la construcción del producto de software (La Solución), ya que “lo puede ver” y, dependiendo del tipo de prototipo,  “utilizar” desde el primer momento.
5.       Se reduce el riesgo o la incertidumbre sobre la implementación del software.
6.       Su uso redunda en una mayor satisfacción del usuario con el producto final, ya que él o ella han participado activamente de su diseño.
7.       Proporciona al usuario un mayor conocimiento del sistema con una curva menor de aprendizaje.
8.       Permite a todos los involucrados entender bien y mejor el problema antes de la implementación final.

Algunas Desventajas del uso de prototipos

1.       El usuario quiere empezar a trabajar desde el primer momento con el prototipo para solucionar su problema particular, cuando el prototipo es solo un modelo de lo que será el producto.
2.       Los prototipos generan o pueden generar otro tipo de problemas si su presentación y discusión con los usuarios no es controlada: puesto que son modelos inconclusos, los usuarios suelen enfocarse en aspectos “superficiales” del prototipo que los pueden dejar inconformes luego de verlos por primera vez. También es posible que se pierda mucho tiempo, innecesariamente, tratando de hacer entender al usuario la finalidad real de los prototipos.
3.       Requiere participación activa del usuario, al menos, para evaluar el prototipo. Y mucho más involucramiento si queremos que participe en su creación.
4.       Una desventaja importante a tener en cuenta es la falta de experiencia que tienen muchos Analistas Funcionales en programación y en actividades de diseño de interfaces de usuario.

Revisar/Aprobar Prototipos en Vez de Requisitos/Casos de Uso

Los prototipos son una herramienta suplementaria a la especificación de requisitos (funcionales). Con esto en mente, es posible que los usuarios revisen y aprueben estos prototipos durante la fase inicial del proyecto. Más adelante, el usuario puede confirmar su grado de satisfacción por los prototipos, más cercanos al producto final.
La otra parte de la tarea, aunque igualmente importante, es que entonces será el Analista Funcional el encargado de verificar que la descripción de los prototipos corresponda a la especificación de los requisitos en su totalidad. Las cosas así, es evidente que se incrementa el esfuerzo de los Analistas, sobre todo en la etapa de Visión y Alcance del proyecto. No obstante, el proceso de construcción de software puede mejorarse con la inclusión de guías para la elaboración de prototipos en las distintas plataformas.

Recomendación para implantar el uso de prototipos en un proceso de software

Como siempre, la recomendación es realizar algunos pilotos controlados donde pongamos en práctica el uso de prototipos en distintos proyectos, donde podamos medir y analizar los resultados con el fin de tener mejores herramientas para tomar la decisión, no solo de incluir los prototipos como una práctica común y hasta obligatoria durante el ciclo de vida, sino para que estos sean revisados/aprobados por los usuarios, en vez de los requisitos y casos de uso.

15 comentarios:

  1. Excelente artículo. Gracias.
    Podría llegarse el caso a que un Prototipo bien implementado, pueda ser pasado a producción y que el usuario lo utilice?

    ResponderBorrar
    Respuestas
    1. Muy cierto,y gracias a esto pude ganar un concurso en el colegio excelente

      Borrar
  2. Antonio, los prototipos son solo eso, prototipos, moldes, una vez que comienzan a exhibir funcionalidad dejan de serlo, mucho más cuando ya están en producción, ya son productos en todo el sentido de la palabra. Lo que sí puede pasar es que un buen prototipo puede ser la genésis de un producto bien implementado.

    Salud@s,

    ResponderBorrar
  3. Hola como estas? me podrías explicas como el prototipo permite a todos los involucrados entender bien y mejor el problema antes de la implementación final.?

    ResponderBorrar
  4. Hola buenas noches me podrías explicar como el prototipo permite a todos los involucrados entender bien y mejor el problema antes de la implementación final.?

    ResponderBorrar
  5. Glenda, si comparamos la efectividad de la técnica del prototipo con las más tradicionales que incluyen solo documentación (texto y diagramas, quizás), la primera nos permite "visualizar" de manera temprana el producto o partes de este. No es lo mismo que te digan, por ejemplo, que "la pantalla de ingreso de facturas tandrá 10 campos", a que te muestren una imagen con la posible distribución de los campos, los nombres de los mismos, los tamaños aproximados que tendrán para que se realice la captura de datos, entre otros aspectos. Así sea en papel o en un tablero, este prototipo dice mucho más que si presentamos todo un compendio textual con los nombres de los campos, los tipos de datos, las longitudes de los mismos, etc.
    Este artículo lo escribí hace ya algunos años, incluso mucho antes se publicarlo en el Blog. Después me di cuenta que los métodos ágiles como Scrum posibilitan el que constryamos los productos en períodos cortos de tiempos (iteraciones o sprints) donde al final de cada período entregamos una parte del producto (incremento), pequeña pero funcional y de alta calidad, potencialmente distribuible, es decir, que se puede poner en producción.
    Este enfoque es aun mejor, porque el usuario final va entendiendo el producto a medida que ve partes de este funcionando (es mucho más que un prototipo) y así va direccionando lo que quiere del resto del producto.
    Sobre todo este asunto de métodos ágiles en general y de Scrum en particular he escrito mucho en este mismo Gazafatonario.
    Salud@s,

    ResponderBorrar
  6. Estimado, cual es la diferencia entre Prototipos el método incremental?

    ResponderBorrar
    Respuestas
    1. Estimado:

      En general, los prototipos permiten con anticipación tener una visual de lo que será el producto, al menos desde el punto de vista del diseño, pero no constituyen un producto en sí, ni parte de este.

      En cambio, el método incremental lo que dice es que cada período corto de tiempo (un día, una semana, dos semanas o algo así), entregamos parte del producto, el incremento, este es producto terminado y probado potencialmente distribuible, que se puede usar, que genera Valor para el negocio o la Organización, para los usuarios y del cual podemos recibir retroalimentación de los usuarios.

      En resumen, el prototipo no resuelve el problema del usuario, ni siquiera parte de este, mientras que el incremento sí, ya que es producto terminado.

      Puedes leer más sobre el método iterativo e incremental en:
      http://www.gazafatonarioit.com/2015/10/el-enfoque-iterativo-e-incremental-una.html

      Y en:
      http://www.gazafatonarioit.com/2014/11/agil-necesita-ser-tanto-iterativo-como.html

      Saludos,

      Borrar
  7. cuanto gastaria para hacer un prototipo

    ResponderBorrar
    Respuestas
    1. Estimado:

      En este otro artículo hablo un poco más de eso: http://www.gazafatonarioit.com/2012/07/el-uso-de-prototipos-en-el-ciclo-de.html

      Como verás allí, depende del tipo de prototipo que quieras elaborar. En cualquier caso, el tiempo y, por consiguiente, el costo de un prototipo es infinitamente menor al del producto que se quiere construir.

      Borrar
  8. Con la web de tipos de prototipos siempre estaremos informados y nos encantará poder conocer muchos temas importantes.

    ResponderBorrar
  9. estimaodos, ¿existe riesgos de hacer un prototipo?

    ResponderBorrar
    Respuestas
    1. Quizás uno de los riesgos latentes es que tardemos más tiempo del necesario elaborándolo o que tardemos más tiempo para recibir retroalimentación del mismo por parte de posibles usuarios o consumidores.

      Borrar