Prototipos Los prototipos son una visin preliminar del sistema futuro que se implantara.

La elaboracin de prototipos de un sistema de informacin es una tcnica valiosa para la recopilacin rpida de informacin especfica a cerca de los requerimientos de informacin de los usuarios. Los prototipos efectivos deben hacerse tempranamente en el ciclo de vida del desarrollo de sistemas, durante la fase de determinacin de requerimientos. En esta forma el analista esta buscando las reacciones iniciales de los usuarios y de la administracin hacia el prototipo, sugerencias de los usuarios sobre cambios o limpieza del sistema para el que construye un prototipo, posibles innovaciones y planes de revisin que detallan que parte del sistema necesita realizarse primero. Clases de prototipos Kendall propone cuatro clases de prototipos: Prototipos de remiendo Sistema que cumple con sus funciones pero se encuentra remendado o parchado, puede operar pero generalmente es ineficiente. Modelo a escala no funcional Son modelos que son construidos a escala, por lo general ms pequeos, que permiten evaluar ciertos aspectos de diseo, pero que no son funcionales en la realidad. Modelo a escala completa Se trata de un modelo "piloto". Se trata de un modelo real que servir como referencia a futuras versiones que de l se hagan. Un ejemplo es el de un sistema de informacin que una gran cadena de almacenes quiera establecer, ste seguramente ser probado en un almacn para que desde all pueda ser mejorado y luego implementado en otras tiendas. Modelo con ciertas caractersticas esenciales Es un sistema funcional que incluye algunas caractersticas de las que tendr el sistema final y que se completar a medida que pase el tiempo y las necesidades as lo requieran. Ventajas de los Prototipos 1. Cambio de un Sistema en Etapas Tempranas de sus Desarrollo: La elaboracin de prototipos satisfactoria depende de la retroalimentacin temprana y frecuente de los usuarios para que ayuden a modificar el sistema y hagan que tenga una respuesta ms gil a las necesidades actuales. Los cambios tempranos son menos caros que los cambios hechos posteriormente en el desarrollo del proyecto. 2. Desechado de Sistemas Indeseables: Una segunda ventaja del uso de prototipos como una tcnica para la recopilacin de informacin es la posibilidad de desechar un sistema que no es lo

que los usuarios y analistas esperaban. 3. Diseo de un Sistema para las Necesidades y Expectativas de los Usuarios: Una tercera ventaja de la elaboracin de prototipos es que el sistema que est siendo desarrollado debe ajustarse mejor a las necesidades y expectativas de los usuarios. Esto quiere decir que se pueden atacar las necesidades de usuarios y expectativas ms de cerca. Desventajas de los Prototipos 1. Puede ser bastante difcil el manejar el prototipo como un proyecto dentro de un esfuerzo para un sistema ms grande. 2. Es que si un sistema es muy necesario y es bienvenido rpidamente, puede ser aceptado el prototipo en sus estado sin terminar y presionando para que sea puesto en servicio sin los refinamientos necesarios. En este caso el prototipo no tendr las funciones necesarias y eventualmente cuando se de cuenta de la deficiencias se puede desarrollar un rechazo del usuario. Reacciones del Usuario Como el analista de sistemas que presenta un prototipo del sistema de informacin, usted estar muy interesado en las reacciones de los usuarios y la administracin ante el prototipo. Usted querr saber a detalle la manera en que reaccionan al trabajar con el prototipo, y que tan buen ajuste hay entre sus necesidades y las caractersticas del prototipo de sistema. Las reacciones son recopiladas por medio de observaciones, entrevista y formas de retroalimentacin (posibles cuestionarios), diseadas para recoger la opinin de cada persona acerca del prototipo cuando interacta con l. Por medio de estas reacciones de usuarios, el analista descubre muchas perspectivas en el prototipo, incluyendo si parece ser que a los usuarios les agrada el sistema y habr dificultades para la venta o implementacin del sistema. Enfoque de creacin de Prototipos El paradigma de creacin de prototipos puede ser cerrado o abierto. Al enfoque cerrado se denomina a menudo prototipo desechable. Este prototipo sirve como una basta demostracin de los requisitos. Despus se desecha y se hace una ingeniera de software con un paradigma diferente. Un enfoque abierto denominado prototipo evolutivo, emplea el prototipo como primera evaluacin del sistema terminado. Antes de poder elegir un enfoque abierto cerrado, es necesario determinar si se puede crear un prototipo como primera evaluacin del sistema terminado. Se pueden definir varios factores candidatos para la creacin de prototipos: rea de aplicacin complejidad caractersticas del cliente caractersticas del proyecto

En general cualquier aplicacin que cree pantallas visuales dinmicas, interacte intensamente con el ser humano o demande algoritmos o procesamiento de combinaciones que deba de manera progresiva, es un buen candidato para la creacin de prototipos. Pero sin embargo estas reas de aplicacin deben ponderarse con la complejidad de la aplicacin. Si una aplicacin candidata va a requerir el desarrollo de docenas de miles de lneas de cdigo antes de poder realizar cualquier funcin demostrable, es probable que sea demasiado compleja para la creacin de un prototipo. Como el cliente debe interactuar con el prototipo en fases posteriores, es esencial que: Se destinen recursos del cliente a la evaluacin y refinamiento del prototipo. El cliente pueda tomar decisiones inmediatas sobre los requisitos. Objetivo: El objetivo de un prototipo de papel no es probar o verificar lo bonito que es el diseo, sino que se trata de verificar si los usuarios son capaces de realizar sus tareas con la interfaz propuesta. La utilizacin de esta tcnica de prototipado no precisa incorporar avances tecnolgicos; slo es necesario que capture la funcionalidad del sistema y que comunique la informacin y sus interacciones adecuadamente. Esta tcnica de prototipado consiste en dibujar en un papel, sin entrar en grandes detalles estticos, las interfaces que se van a probar y valorar. Los diferentes estados de la interfaz se van dibujando en hojas separadas y mediante un proceso de ordenacin que el diseador determina permite que el usuario final interacte con este material simulando el funcionamiento del sistema. Por ejemplo, supongamos que tratamos de simular el comportamiento de una funcionalidad concreta de una aplicacin que se ejecuta en un PDA; los prototipos de papel sern las diferentes representaciones de las pantallas de tamao lo ms real posible que el usuario se encontrara como resultado de las diferentes interacciones que producira. Ventajas: Los problemas (funcionales y de usabilidad) se pueden descubrir en una etapa muy temprana del proceso de diseo, mucho antes de haberlos codificado. Favorece la comunicacin entre el equipo de diseo-desarrollo, los usuarios y los implicados. Favorece tambin la participacin de todos los miembros de los equipos multidisciplinarios proporcionando un soporte comunicativo entre las diferentes disciplinas. Son muy rpidos de construir y refinar, lo que permite realizar r interacciones de diseo. Los recursos consumidos son mnimos (materiales muy bsicos) y econmicos. Psicolgicamente es beneficioso para los usuarios. Resulta tan familiar para los usuarios que sin dudarlo intervienen en las modificaciones del diseo. El usuario, que es consciente de la facilidad y el bajo coste de prototipo, no se siente cohibido de proponer cualquier cambio. Resulta menos intimidante que un ordenador (ayuda a superar el fenmeno conocido como tecnofobia). El tiempo dedicado al proceso de codificacin es cero. No estn sujetos a restricciones impuestas por la tecnologa -arquitectura del sistema, la base de datos, el ancho de banda, el sistema operativo-, y a pesar de ello ayuda al equipo a anticipar problemas y decisiones derivadas de la tecnologa.

Puede servir como herramienta de marketing y para demostraciones de ventas. Inconvenientes. Por su simplicidad, los prototipos de papel no sirven para realizar evaluaciones detalladas del diseo. No puede simular la respuesta del sistema. En el momento de evaluarlo es fcil que se den por supuestas cosas que realmente no estn en el prototipo. No hay un consenso sobre cul debe ser el nivel de detalle que el prototipo debe implementar ni de la calidad grfica o de expresividad. La construccin de los prototipos de papel parece tan evidente que a menudo se menosprecian aspectos tan importantes como que el prototipo se asemeje al mximo en tamao y forma al dispositivo para el que estamos realizando -cuanto ms realista resulte el prototipo mejor ser la realimentacin de los usuarios- el prototipo, que suele llevar a rediseos posteriores que inutilizan los ya realizados.

DESARROLLO DE UN PROTOTIPO Cuando haya que decidir si hay que incluir la elaboracin de prototipos como parte del ciclo de vida de desarrollo de sistemas, el analista necesita considerar cul tipo de problema esta siendo resuelto y en qu forma el sistema presenta la solucin. LINEAMIENTOS PARA DESARROLLAR UN PROTOTIPO Una vez que se ha tomado la decisin de elaborar un prototipo, se deben observar cuatro lineamientos principales al integrar la elaboraron de prototipos con la fase de determinacin de requerimientos: 1. TRABAJAR EN MDULOS MANEJABLES Es cuando el prototipo de algunas de las caractersticas de un sistema se integra para formar un modelo funcional, es indispensable que el analista trabaje en mdulos manejables. Una ventaja evidente de la elaboracin de prototipos es que no es necesario ni deseable construir un sistema operativo completo para los propsitos del prototipo. Un modelo manejable es aquel que permite la interaccin con sus caractersticas principales, pero todava puede ser construido por separado de otros mdulos del sistema. Las caractersticas del mdulo que se consideran menos importantes son intencionalmente dejadas fuera del prototipo inicial. 2. CONSTRUIR EL PROTOTIPO RPIDAMENTE. La rapidez es esencial para la elaboracin exitosa del prototipo de un sistema de informacin. Recuerde que unas de las quejas expresadas en contra del SDLC tradicionales es que el intervalo entre la discriminacin de requerimientos y la entrega de un sistema completo es demasiado largo para satisfacer eficazmente las cambiantes necesidades del usuario. Los analistas pueden usar la elaboracin de prototipos con el fin de reducir esta brecha utilizando las tcnicas tradicionales de recopilacin de informacin para determinar con presin los

requerimientos de informacin que surjan sobre la marcha, y a continuacin tomar rpidamente las decisiones que den lugar o un modelo funcional. De hecho, el usuario debe utiliza el sistema desde muy temprano en el SDLC en lugar de esperar hasta que el sistema se termine para practicar con l. La preparacin de un prototipo operacional, con rapidez y en las etapas tempranas del SDLC, permite al analista comprender mejor cmo desarrollar el resto del proyecto. Al mostrar a los usuarios en las primeras etapas del proceso como se ejecutan en la realidad algunas partes del sistema, la elaboracin rpida de prototipos evita que se dediquen demasiados recursos a un proyecto que a la larga podra ser imposible de concretar. Ms adelante, cuando se explique el RAD, usted ver nuevamente la importancia de la construccin rpida de sistemas. 3. MODIFICAR EL PROTOTIPO EN INTERACCIN SUCESIVA. Un tercer lineamiento para desarrollar el prototipo es que su construccin debe soportar modificaciones. Hacer modificable el prototipo significa crearlo en mdulos que no sean demasiado interdependientes. Si se observa este lineamiento, se encontrar menos resistencia cuando sea necesario realizar cambios al prototipo. Generalmente, el prototipo se modifica varias veces al pasar por diversas interacciones. Los cambios en el prototipo deben propiciar que el sistema se acerque cada vez ms a lo que los usuarios consideren importante. Cada modificacin necesita otra evaluacin por parte de los usuarios. El prototipo no es un sistema terminado. Abordar la fase de elaboracin de prototipos con la idea de que el prototipo requerir modificaciones es una actitud positiva que demuestra a los usuarios cun necesaria es una retroalimentacin para mejorar el sistema

4. ENFATIZAR LA INTERFAZ DEL USUARIO La interfaz del usuario con el prototipo (y eventualmente con el sistema) es muy importante debido que lo que se esta tratando realmente de lograr con el prototipo es hacer que los usuarios muestren cada vez ms sus requerimientos de informacin, debe ser capas de interactuar fcilmente con el prototipo del sistema. El objetivo del analista es disear una interfaz que permita al usuario interactuar con el sistema con un mnimo de entrenamiento y que permita el mximo de control del usuario sobre las funciones representadas. VENTAJAS DE LOS PROTOTIPOS * Cambio de un Sistema en Etapas Tempranas de sus Desarrollo: La elaboracin de prototipos satisfactoria depende de la retroalimentacin temprana y frecuente de los usuarios para que ayuden a modificar el sistema y hagan que tenga una respuesta ms gil a las necesidades actuales. Los cambios tempranos son menos caros que los cambios hechos posteriormente en el desarrollo del proyecto. * Desechado de sistemas indeseables: Una segunda ventaja del uso de prototipos como una tcnica para la recopilacin de informacin es la posibilidad de desechar un sistema que no es lo que los usuarios y analistas esperaban.

* Diseo de un sistema para las necesidades y expectativas de los usuarios: Una tercera ventaja de la elaboracin de prototipos es que el sistema que est siendo desarrollado debe ajustarse mejor a las necesidades y expectativas de los usuarios. Esto quiere decir que se pueden atacar las necesidades de usuarios y expectativas ms de cerca. DESVENTAJAS DE LOS PROTOTIPOS 1. Puede ser bastante difcil el manejar el prototipo como un proyecto dentro de un esfuerzo para un sistema ms grande. 2. Es que si un sistema es muy necesario y es bienvenido rpidamente, puede ser aceptado el prototipo en sus estado sin terminar y presionando para que sea puesto en servicio sin los refinamientos necesarios. En este caso el prototipo no tendr las funciones necesarias y eventualmente cuando se de cuenta de la deficiencias se puede desarrollar un rechazo del usuario. PAPEL DEL USUARIO EN LOS PROTOTIPOS Hay tres formas principales en que un usuario puede ser de ayuda en la elaboracin del Prototipo. 1. Experimentando con el Prototipo: Los usuarios deben tener libertad para experimentar con el prototipo, y no una simple lista de caractersticas del sistema, el prototipo permite a los usuarios la realidad de la interaccin real. Los analista deben estar presente la mayor parte del tiempo en que se este experimentando con el prototipo. 2. Reaccionar Abiertamente ante el Prototipo: Si los usuarios se siente temerosos de hacer comentarios, o criticar lo que puede ser un proyecto consentido de superiores o iguales dentro de la organizacin, es poco probable que se de reacciones abiertas ante el prototipo. Una forma para aislarlos de influencias organizacionales no deseada es proporcionar un periodo privado, para que los usuarios interacten con y respondan al prototipo. El hacer que los usuarios se sienta lo suficientemente seguros para dar una reaccin abierta es parte de la realizacin entre los analista y usuarios que el equipo tiene que construir. 3. Sugiriendo adiciones y/o eliminaciones de Cambios al Prototipo: Un tercer aspecto del papel de los usuarios en la elaboracin de los prototipos es sugerir adiciones y/o eliminaciones a las caractersticas que se estn probando. El papel del analista es deducir tales sugerencias, asegurando a los usuarios que tal retroalimentacin que proporciona es tomada en serio, observando a los usuarios mientras interactan y realizando entrevistas cortas y especficas en relacin con su experiencia con el prototipo. EL DESARROLLO RPIDO DE APLICACIONES (DRA) Es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptacin a "Alta velocidad" en el que se logra el desarrollo rpido utilizando un enfoque de construccin basado en componentes. Si se comprenden bien los requisitos y se limita el mbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de informacin, el enfoque

DRA comprende las siguientes fases: 1. MODELADO DE GESTIN: El flujo de informacin entre las funciones de gestin se modela de forma que responda a las siguientes preguntas: Qu informacin conduce el proceso de gestin? Qu informacin se genera? Quin la genera? A dnde va la informacin? Quin la proceso? 2. MODELADO DE DATOS: El flujo de informacin definido como parte de la fase de modelado de gestin se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las caractersticas (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos. 3. MODELADO DE PROCESO: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de informacin necesario para implementar una funcin de gestin. Las descripciones del proceso se crean para aadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicacin entre los objetos. 4. GENERACIN DE APLICACIONES: El DRA asume la utilizacin de tcnicas de cuarta generacin. En lugar de crear software con lenguajes de programacin de tercera generacin, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automticas para facilitar la construccin del software. 5. PRUEBAS DE ENTREGA: Como el proceso DRA enfatiza la reutilizacin, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo. Obviamente la limitacin de tiempo impuesto en un proyecto DRA demanda "mbito en escalas". Si una aplicacin de gestin puede modularse se forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones puede ser afrontada por un equipo DRA diferente y ser integradas en un solo conjunto.

AL IGUAL QUE TODOS LOS MODELOS DE PROCESO, EL ENFOQUE DRA TIENE INCONVENIENTES: Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el numero correcto de equipos DRA. DRA requiere clientes y desarrolladores comprometidos en las rpidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran. No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modulizar adecuadamente. La construccin de los componentes necesarios para DRA ser problemtico. Si est en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA puede que no funcione. DRA no es adecuado cuando los riesgos tcnicos son altos. Esto ocurre cuando una nueva aplicacin hace uso de tecnologas

nuevas, o cuando el nuevo software requiere un alto grado de interoperabilidad con programas de computadora ya existentes. DRA enfatiza el desarrollo de componentes de programas reutilizables. La reutilizacin es la piedra angular de las tecnologas de objetos, y se encuentra en el modelo de proceso de ensamblaje. PROGRAMACIN EXTREMA La programacin extrema (XP) es un enfoque de desarrollo de software que adopta lo que generalmente designamos como prctica de desarrollo de software aceptable y las lleva al extremo. Por ejemplo, la retroalimentacin es importante para los programadores, analistas, diseadores, usuarios y computadoras. As que la programacin extrema usa ciclo de retroalimentacin cada vez ms rpido e intenso, que proporcionan ms informacin. La administracin de proyecto es importante de tal manera que la programacin extrema intenta definir rpidamente un plan global del sistema, desarrollar y liberar rpidamente el software y posteriormente revisarlo continuamente para incorporarles caractersticas adicionales. Los programadores, analistas y diseadores ordinarios que trabajan independientemente y luego integran su trabajo logran resultados slidos; los programadores extremos que trabajan en parejas pueden ser excelentes. Pero la programacin extrema no solo se basa en los resultados. Se basa en los valores principios y prcticas. Ahora examinaremos como los valores y Principios de XP dan forma al desarrollo de sistemas extremos. VALORES Y PRINCIPIOS DE LA PROGRAMACIN EXTREMA Para la programacin extrema es importante que se declaren los valores y principios que crean el contexto para la colaboracin entre programadores y clientes. Para considerarse analistas de XP se debe apegar a los siguientes valores y principios desarrollados por Beck 2000. CUATRO VALORES DE XP Hay cuatro valores que crean un entorno en el cual se pueden servir adecuadamente diseadores y negocios. Debido a que con frecuencia hay una tensin entre lo que los diseadores hacen a corto plazo y lo que es comercialmente deseable a largo plazo, es importante que est consciente de apoyar valores que formarn una base para colaborar juntos en un proyecto de software. Como se muestra en la figura los cuatro valores son comunicacin, sencillez y retroalimentacin y valenta. 1. LA COMUNICACIN. Es el primer valor bsico cada esfuerzo humano tiene la posibilidad de fallar en la comunicacin. Los proyectos de los sistemas que requieren una actualizacin constante y un diseo tcnico son especialmente propensos a dichos errores. Agregue a este proyecto fechas lmites ajustados, jerga especializada y el estereotipo de que los programadores prefieren hablar con las mquinas que con las personas, y usted tiene los ingredientes para algunos problemas serios de comunicacin. Los proyectos pueden ser retrasados; se puede resolver el problema equivocado; se castiga a los programadores incluso por mencionar a los gerentes que hay problemas; las personas abandonan o se unen al proyecto a la mitad sin estar al corriente; y as continua la letana. Prcticas tpicas de XP tal como la programacin en pareja (colaboracin de dos programadores), estimacin de las tareas y las pruebas de software, requieren de una buena comunicacin. Los problemas se resuelven rpidamente, los agujeros se tapan y la opinin dbil se fortalece rpidamente a travs de la interaccin con otros en el equipo. Un instructor de XP, esta presente para observar si alguien ha interrumpido la comunicacin y para reunirlos. 2. LA SIMPLEZA. Es el segundo valor bsico cuando estamos trabajando en un proyecto de desarrollo de software, nuestra primera reaccin es abrumarnos la complejidad y magnitud de la tarea. Sin embargo,

usted no puede correr si no sabe caminar, ni caminar si no sabe ponerse de pie. La simpleza en el desarrollo de software significa que empezaremos con la cosa ms sencilla que podemos hacer. La simpleza lleva tiempo, y es algo en lo que el instructor de XP podra ayudarle. El valor de XP de simpleza nos pide que hoy hagamos la cosa ms sencilla, comprendiendo que maana se podra cambiar un poco. Esto quiere un enfoque claro de las metas del proyecto y realmente es un valor bsico. 3. LA RETROALIMENTACIN Es el tercer valor bsico que es importante para tener un enfoque de la programacin extrema. Cuando piensa en la retroalimentacin en este contexto, es bueno considerar que esta se relaciona con el concepto de tiempo. Una retroalimentacin buena y concreta, que es til para el programador, analista y cliente puede ocurrir en segundos, minutos, das, semanas o meses, dependiendo de lo que se necesita, quien esta comunicando y lo que se har con dicha retroalimentacin. Un colega programador podra encontrar un caso de prueba que hiciera que un cdigo que usted escribi fallara.