Prototipos - Apuntes 6 PDF

Preview

Summary

Download Prototipos - Apuntes 6 PDF

Description

PROTOTIPOS (Relacionado con un Modelo iterativo, incremental, sin llegar a ser un Modelo en Espiral) Existen algunas circunstancias en las que, por razones prácticas o contractuales, no se puede utilizar un proceso de entrega del software incremental. Se pueden conseguir algunos de los beneficios de un proceso de desarrollo incremental creando un prototipo del software. Cuando hablábamos del modelado en etapas o cascada, hablábamos de análisis estructurado Ahora, cuando hablamos de modelos evolutivos, estamos hablando de prototipos. Concepto: un prototipo es un modelo limitado que puede simular el comportamiento o características de una aplicación, tal representación puede definir ciertos aspectos o inclusive puede ser una primera versión del sistema a implementar, que se utiliza para probar opciones de diseño y, en general, informarse más del problema y sus posibles soluciones. Características bajo el dominio de referencia o la solución que pretende el usuario. Los prototipos del sistema permiten a los usuarios ver como este apoya su trabajo. Pueden adquirir nuevas ideas para los requerimientos y encontrar áreas fuertes y débiles en el software. Además, a medida que se desarrolla el prototipo, puede revelar errores y omisiones en los requerimientos propuestos. Aunque una función descrita en una especificación puede parecer útil y bien definida, cuando se combina con otras, el usuario puede comprobar que su visión inicial fue incorrecta o incompleta. La especificación del sistema podría modificarse para reflejar el cambio en la comprensión de los requerimientos. Ejemplo: un diseño de una base de datos puede ser prototipado y probado para verificar que las consultas más comunes de los usuarios tienen el acceso a los datos más eficiente. En caso de que lo usemos como metodología, ese prototipo va a ser una primera versión a implementar del sistema. Siempre se tiene que definir para que vamos a hacer el prototipo porque significa un costo. Una vez que se presente un prototipo las reacciones de los usuarios se recopilan a través de la observación, entrevistas y hojas de retroalimentación (posiblemente cuestionarios) diseñadas para obtener la opinión de cada persona sobre el prototipo a medida que interactúa con él. La información que se recopila en la fase de prototipos permite al analista establecer prioridades y redirigir los planes sin sufrir repercusiones graves, con un mínimo de interrupción. Debido a esta característica, la creación de prototipos y la planeación van de la mano.

Como funcionalidades en la ingeniería de software, podemos tomarlo de dos maneras: ¿Herramienta o Metodología? 

como metodología de desarrollo: tomamos pequeñas rutinas o pequeños programas ya en nuestras librerías, y con eso armamos un prototipo que se acerca las funcionalidades que el usuario nos pide y entregar en sucesivas iteraciones hasta llegar al sistema completo.

El prototipo evolutivo entrega a los usuarios finales un sistema funcionando. Se usa con los requerimientos que mejor se comprenden. 

como herramienta de desarrollo: debemos tener la idea que para que y con qué objetivo hacemos ese prototipo. Generalmente definimos un requerimiento medio confuso y no definido explícitamente y por medio de un prototipo salvamos ese requerimiento que no está bien explicado. Se dice que son desechables porque una vez aclaradas las cosas se desecha

El prototipo desechable valida o deriva los requerimientos del sistema. Se usa con los requerimientos que no se conocen bien. Periodo de vida corto.

COMO HERRAMIENTA. 







Definición de requerimientos: por ejemplo, si hay una funcionalidad de una app que necesita calcular los intereses que se cobran a un cliente según ciertas normas/políticas, puedo hacer un prototipo que cargue datos, calcule y hacer un listado para que el usuario verifique que los cálculos estan bien hechos, este prototipo seguramente ni siquiera grabe en una base de datos o directamente use datos como variables solamente, pero si necesito que cuando se carguen y procesen los datos necesito validar el correcto funcionamiento del cálculo, entonces me valida solo el cálculo, no realiza nada más. Definición de Interfaz con el Usuario: Se presenta el tipo de interfaz que quiere el usuario, se pueden presentar colores, tipos de letras, maquetados de pantallas para validar interfaces de usuarios. Definición de diseño de reportes: Como se deberá mostrar los reportes requeridos, si es a nivel gráfico, si es un listado, etc. Seguramente lo determinara el usuario final que va a procesar los reportes. Determinación de Funcionalidades: por ejemplo, las funcionalidades de altas, bajas y modificaciones (abm).

COMO METODOLOGIA. 

Iterativa: tiene que ser iterativa, tantos ciclos como sea necesario para llegar al final,





Incremental: una vez que genere un módulo, ese modulo cuando ya está implementado tiene que ir incrementado con funcionalidades iterativas, de Rapidez de construcción: para que el cliente constante que se avanza en el producto final.

Los prototipos son un medio excelente para obtener retroalimentación sobre el sistema propuesto y el grado en que cumple con las necesidades de información de sus usuarios, El primer paso de la creación de un prototipo es estimar los costos involucrados en la construcción de un módulo del sistema. Si los costos del tiempo de los programadores y del analista, así como los costos del equipo están dentro del presupuesto, se puede continuar con la construcción del prototipo. Ésta es una excelente manera de facilitar la integración del sistema de información en la cultura y sistema, más extensos, de la organización. Una vez tomada la decisión de crear un prototipo, hay que cumplir con cuatro lineamientos para integrar el prototipo en la fase de determinación de requerimientos Para trabajar con prototipos se tienen que tener consideraciones: - Trabajar con módulos manejables: los sistemas no deben ser demasiado grandes, debe ser un sistema pequeño/mediano para que podamos trabajar con módulos manejables de rápida codificación, rápido testeo y entrega rápida. Un módulo administrable permite a los usuarios interactuar con sus características clave y se puede construir por separado. Las características del módulo que se consideran menos importantes se dejan intencionalmente fuera del prototipo inicial. - Construir prototipos rápidamente: la creación rápida de prototipos evita comprometer recursos excesivos en un proyecto que tal vez llegue a fracasar. - Modificar el prototipo en iteraciones sucesivas: que el cliente no espere demasiado y que en cada una se corrijan errores producidos, que el equipo se vincule y entienda más las funcionalidades que pretende el cliente. El prototipo debe admitir modificaciones. Para lograr esto hay que crearlo en módulos que no tengan un alto grado de interdependencia. Si cumplimos con este lineamiento encontraremos menos resistencia cuando haya que modificar el prototipo - Enfatizar la interface del Usuario: La interfaz del usuario con el prototipo (y con el sistema, en última instancia) es muy importante. Como lo que realmente tratamos de lograr con el prototipo es hacer que los usuarios articulen con más detalle sus requerimientos de información, deben ser capaces de interactuar con facilidad con el prototipo del sistema. También deben ser capaces de ver cómo el prototipo les permitirá realizar sus tareas.

Además, es importante definir el objetivo del prototipo, ¿es una herramienta? ¿es una primera versión de la aplicación? la metodología la tenemos que escribir explícitamente antes de empezar el proyecto, puede ser que escribamos una metodología específica para el cliente y la aplicación, entonces debemos saber que la descripta se va a diseñar antes de escribir la primera línea de código.

Por ejemplo, algo a tener en cuenta es nuestro equipo de desarrollo, si manejan el desarrollo de prototipos sería prudente usarla como metodología, en cambio, si manejan metodología orientada a objetos, sería mejor usarla como herramienta. Nota: las que vemos nosotros, que son orientas a objetos, pero con fases definidas, seguramente la usamos como herramienta. Hacemos prototipos y podemos desecharlos, pero también usarlos, como subrutinas muy críticas que tenemos que testearlas bien bien bien, seguramente la usamos con prototipación, aunque la metodología que usemos no lo sea.

FACTORES PARA LA SELECCION DE HERRAMIENTAS     

Identificar la magnitud del prototipo. Evaluar los recursos de hardware y software disponibles. Evaluar el nivel y conocimiento de la herramienta del personal. Efectuar un estudio de costo-beneficio. Elegir las herramientas apropiadas.

hoy en dia las IDE tienen generadores de código *tamaño y complejidad del prototipo *no puedo hacer un prototipo viable sin tener los requerimientos de soft y hard que cuando quiera implementar el proto no ande . Puedo simular a misma estuctura del cliente? *para un programador junior la experiencia minima es de 2 años, un semi senior es 5 años. con la misma herramienta o versiones sucesivas, senior 10 años. Entonces el conocimiento de la herramienta y su rendimiento va a depender del conocimiento del personal que trabaje con esa herramienta, hacer un costo beneficio y ver las herramientas adecuadas. Evolución de las Herramientas: las primeras herramientas de generación de prototipos fueron llamadas RAD (Rapid Application Development) se basaron en los conceptos de James Martin desarrollados en la década de los noventa.

Hoy los lenguajes de cuarta generación llamadas también entornos de Desarrollo han integrado casi la totalidad de funcionalidades para la generación de Software. Herramientas en el mercado:

- Rational Rose - Poseidon - Netbeans - Eclipse - Genexus, etc.

COMO METODOLOGIA Desarrollo Orientado a Prototipos. Modelo de Desarrollo que pone énfasis en la etapa de Especificación de Requerimientos a través de la construcción de prototipos que aproximan al usuario a la idea final del sistema, con objeto de poder clarificar los requerimientos.

FASES DE LA METODOLOGIA     

Investigación Preliminar. Definición de los requerimientos del sistema. Diseño técnico. Programación y prueba. Operación y mantenimiento.

Investigación preliminar. Las metas principales de esta fase son: Determinar el problema y su ámbito, la importancia y sus efectos potenciales sobre la organización por una parte y, por otro lado, identificar una idea general de la solución para realizar un estudio de factibilidad que determine la posibilidad de una solución software. Definición de los requerimientos del sistema. El objetivo de esta etapa es registrar todos los requerimientos y deseos que los usuarios tienen en relación al proyecto bajo desarrollo. Esta etapa

es la más importante de todo el ciclo de vida, es aquí donde el desarrollador determina los requisitos mediante la construcción, demostración y retroalimentaciones del prototipo. (Por lo mismo esta etapa será revisada con más detalle luego). Cuando el equipo de desarrollo es interno a la empresa donde se hacen desarrollos y hay un jefe de proyectos que especifica una priorización de proyecto y con normas de prototipos es más fácil porque la definición es comprendida porque el equipo es interno, el lenguaje, las necesidades, el no tener que trasladarse hacia la empresa, hace que todo fluya más fácil ENTONCES los prototipos son muy recomendados cuando hay equipos de desarrollo interno. Lo más importantes es esto, entender lo que el usuario necesita y que en pocas iteraciones lograr código. No olvidar, que cada iteración tiene un costo asociado, y por cada una que no se entienda lo que quiere el cliente afecta mucho la comunicación. Diseño técnico. Durante la construcción del prototipo, el desarrollador ha obviado el diseño detallado. El sistema debe ser entonces rediseñado y documentado según los estándares de la organización y para ayudar a las mantenciones futuras. Esta fase de diseño técnico tiene dos etapas: -

-

Por un lado, la producción de una documentación de diseño que especifica y describe la estructura del software, el control de flujo, las interfaces de usuario y las funciones. Y como segunda etapa, la producción de todo lo requerido para promover cualquier mantenimiento futuro del software.

Programación y prueba. Es donde los cambios identificados en el diseño técnico son implementados y probados para asegurar la corrección y completitud de los mismos con respecto a los requerimientos. Operación y mantenimiento. La instalación del sistema en ambiente de explotación, en este caso, resulta de menor complejidad, ya que se supone que los usuarios han trabajado con el sistema al hacer las pruebas de prototipos. Además, el mantenimiento también debería ser una fase menos importante, ya que se supone que el refinamiento del prototipo permitiría una mejor claridad en los requerimientos, por lo cual las modificaciones posteriores serían menores. Si eventualmente se requiriese una mantención entonces el proceso de prototipado es repetido y se definirá un nuevo conjunto de requerimientos

Ampliando lo de definición de requerimientos… La fase más importante corresponde a la definición de requerimientos, la cual correspondería a un proceso que busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. La definición de requerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo: Subfase de la Definición de Requerimientos.  





Análisis grueso y especificación: El propósito de esta Subfase es desarrollar un diseño básico para el prototipo inicial. Diseño y construcción: El objetivo de esta Subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un sistema con la máxima funcionalidad, poniendo énfasis en la interface del usuario. Evaluación: Esta etapa tiene dos propósitos: extraer a los usuarios la especificación de los requerimientos adicionales del sistema y verificar que el prototipo desarrollado lo haya sido en concordancia con la definición de requerimientos del sistema. Si los usuarios identifican fallas en el prototipo, entonces e desarrollador simplemente corrige el prototipo antes de la siguiente evaluación. El prototipo es repetidamente modificado y evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El proceso de evaluación puede ser dividido en cuatro pasos separados: preparación, demostración, uso del prototipo y discusión de comentarios. En esta fase se decide si el prototipo es aceptado o modificado. Modificación: Esto ocurre cuando la definición de requerimientos del sistema es alterada en la sub-fase de evaluación. El desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios.

TIPOS DE PROTOTIPOS (según Kendal y Kendal), Somerville lo toma como desechable y no desechable nomas. 

Parchado: se trata de “juntar” distintas rutinas, las “emparcho” y ese sería nuestro prototipo inicial o uno desechable, básicamente son bibliotecas y rutinas. El primer tipo alude a la construcción de un sistema funcional, parchado o construido totalmente con parches. En ingeniería, a esta metodología se le conoce como “breadboarding”: crear un modelo funcional uniendo partes. En términos de sistemas de información, se trata de un modelo funcional, con todas las características necesarias, pero que es ineficiente. En esta instancia del prototipo, los usuarios pueden interactuar con el sistema y acostumbrarse a la interfaz y a los tipos de salidas disponibles. Sin embargo, los procesos de







recuperación y almacenamiento de información pueden ser ineficientes debido a que los programas se escribieron con rapidez, con el objetivo de que fuera funcional en vez de eficiente No operacional: se trata de llevarle al cliente un prototipo que no es operativo, puede generar problemas porque hay que explicarle al cliente que no es operacional. Por ejemplo, un módulo donde puedo ingresar y procesar listar datos, pero que no hace un update en base de datos. Entonces incorpora, ve listados, etc. pero como no es operacional puede ser que no se grabe en la base, entonces, hay que detallarle al usuario muy claramente que no se utiliza formalmente. Si o si es desechable. La segunda concepción de prototipo es la del modelo a escala no funcional, empleado para probar ciertos aspectos del diseño. Un ejemplo es el modelo a escala completa de un automóvil que se utiliza en pruebas de túnel de viento. El tamaño y la forma del automóvil son precisos, pero el automóvil no es funcional; se incluyen sólo las características esenciales para una prueba específica. Sería pertinente un modelo de escala no funcional para un sistema de información cuyas aplicaciones requirieran una codificación demasiado extensa como para incluirla en el prototipo, pero fuera útil hacerse una idea de la entrada y la salida necesarias solamente. En este caso, no se crearía un prototipo del procesamiento, debido al excesivo costo y tiempo requeridos. Los usuarios de todas formas podrían tomar decisiones en cuanto a la utilidad del sistema con base en el prototipo de la entrada y la salida. De primera serie: evolutivo e iterativo que finaliza en el sistema final y completo. La tercera concepción de los prototipos es la creación de un modelo a escala completa de un sistema, a lo que comúnmente se le conoce como piloto. Un ejemplo sería crear el prototipo del primer aeroplano de una serie y después ver si puede volar antes de construir un segundo aeroplano. El prototipo es completamente funcional; es una realización de lo que el diseñador espera sea una serie de aeroplanos con características idénticas. Este tipo de prototipo es útil cuando se planean muchas instalaciones del mismo sistema de información. El modelo funcional a escala completa permite a los usuarios experimentar una interacción realista con el nuevo sistema, al tiempo que minimiza el costo de solucionar los problemas que presenta. Por ejemplo, cuando una cadena de tiendas de abarrotes al menudeo intenta usar el intercambio electrónico de datos (EDI) para verificar los envíos de los proveedores en varios puntos de venta, se podría instalar un modelo a escala completa en una tienda, antes de implementar el sistema en las demás, con el fin de que surjan los potenciales problemas de EDI sólo ahí para resolverlos antes de que se extiendan en todos puntos de venta. De características seleccionadas: que frente a rutinas muy críticas puedo mostrar una característica específica, ejemplo el ABM, especifico un requerimiento que necesita validación.

La cuarta concepción de los prototipos es la creación de un modelo operacional que incluya sólo algunas características del sistema final. Una analogía sería un nuevo centro comercial que abra antes de terminar de construir todas las tiendas. Al crear prototipos de sistemas de información de esta forma, es posible incluir sólo algunas características esenciales. Por ejemplo, el prototipo de un sistema mostraría a los usuarios un menú de pantalla con seis características, agregar un registro, actualizar un registro, eliminar un registro, buscar una palabra clave en un registro, listar un registro o escanear un registro, aunque sólo tres de las seis características estarían habilitadas para usarse, de manera que el usuario pueda agregar un registro (característica 1), eliminar un registro (característica 3) y listar un registro (característica 5). La retroalimentación de los usuarios puede ayudar a los analistas a comprender lo que funciona y lo que no. También puede ayudar con las sugerencias sobre cuáles pueden ser las siguientes características a agregar. Mediante este tipo de creación de prototipos, el sistema se desarrolla en módulos, de manera que si los usuarios evaluaron positivamente las características presentadas, se pueden incorporar al sistema final sin tener que trabajar mucho para interconecta...