Por ejemplo, cuando una cadena de tiendas de abarrotes minoristas considera el uso del EDI (intercambio electrónico de datos) para comprobar los envíos de los proveedores a varias tiendas, se podría instalar un modelo a escala completa en una tienda para resolver cualquier problema antes de que el sistema se implemente en todas las demás tiendas. Otro es el de las instalaciones bancarias para la transferencia electrónica de fondos. Primero, se instala un prototipo a escala completa en una o dos sucursales con base en los patrones de uso de los clientes y en otros factores importantes.
Prototipo de características seleccionadas Una cuarta concepción de la elaboración de prototipos involucra la creación de un modelo funcional que incluya algunas, pero no todas, de las características que tendrá el sistema final. Una analogía seria que un nuevo centro comercial minorista abriera antes de que se terminara la construcción de todas las tiendas. Cuando se elaboran prototipos de los sistemas de información de esta manera, se incluyen algunas de las características principales, aunque no todas. Por ejemplo, en la pantalla podría aparecer un menú del sistema que muestre seis características: agregar un registro (característica 1), eliminar un registro (característica 3) y listar un registro (característica 5). Cuando se recurre a este tipo de elaboración de prototipos se evalúan exitosamente, se pueden incorporar en el sistema final más grande sin nesecidad de realizar demasiado esfuerzo en la interacción. Los prototipos hechos de esta forma son parte del sistema real. No son solo un modelo como en el caso de los prototipos no funcionales que se describieron antes.
ELABORACION DE PROTOTIPOS, RAD Y PROGRAMACION EXTREMA 153
ELABORACION DE PROTOTIPOS COMO UNA ALTERNATIVA AL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS
Algunos analistas argumentan que la elaboración de prototipos se debe considerar como una alternativa para el ciclo de vida del desarrollo d sistemas (SDLC). Recuerde que el SDLC, tratado en el capitulo 1, es un enfoque lógico y sistemático que se sigue en el desarrollo de sistemas de información. Las quejas relativas al proceso del SDLC se centran en dos preocupaciones interaccionadas. La primera preocupación es todo el tiempo que se requiere para pasar por el ciclo de vida del desarrollo. Conforme aumenta la inversión de tiempo del analista, el costo del sistema entregado se incrementa proporcionalmente. La segunda preocupación sobre el uso del SDLC es que los requerimientos del usuario cambian a través del tiempo. Los requerimientos del usuario evolucionan durante el considerable intervalo existente entre el análisis de los requerimientos del usuario y la fecha en que se entrega el sistema final. Por lo tanto, debido al extenso ciclo del desarrollo, el sistema resultante podría ser crítico por abordar deficientemente los requerimientos de información del usuario actual.
Un corolario al problema de mantenerse al tanto de los requerimientos de información es la teoría de que los usuarios realmente no saben lo que hacen o no lo desean sino hasta que vean algo tangible .en el SDLC tradicional, una vez que se entrega un sistema, con frecuencia es demasiado tarde para modificarlo. 154 ANALISIS DE LOS REQUERIMIENTOS DE INFORMACION
Para resolver estos problemas, algunos analistas proponen la elaboración de prototipos como una alternativa al ciclo de vida del desarrollo de sistemas. Cuando la elaboración de prototipos se usa de esta forma, el analista reduce efectivamente el tiempo entre la determinación de los requerimientos de información y la entrega de un sistema funcional. Además, el uso de elaboración de prototipos en lugar de SDLC tradicional podría resolver algunos problemas como el de identificar con presicion los requerimientos de información del usuario.
Ente las desventajas de sustituir el SDLC por la elaboración de prototipos esta la de configuración prematura de un sistema antes de que el problema u oportunidad en cuestión se entienda completamente. También, el uso de la elaboración de prototipos como una
Alternativa podría producir un sistema aceptado por grupos específicos de usuarios pero inadecuados para las necesidades globales del sistema. El enfoque que apoyamos aquí es usar la elaboración de prototipos como una parte del SDLC tradicional. Desde esta perspectiva, la elaboración de prototipos se considera como un método adicional y especializado para determinar los requerimientos de los usuarios.
COMO DESARROLLAR UN PROTOTIPO Los lineamientos de esta sección para desarrollar un prototipo son avanzados. El termino elaboración de prototipos se interpreta en el sentido de la ultima definición que se explico, es decir, un prototipo de características seleccionadas que incluirá algunas pero no todas no todas las características., uno que, si tiene éxito., será parte del sistema final que se entregue . Como se ilustra en la figura 6.2, la elaboración de prototipos es una excelente forma de obtener retroalimentación sobre el sistema propuesto y sobre la facilidad con que esta cumpliendo las necesidades de información de su usuario. El primer paso de la elaboración de prototipos es estimar los costos necesarios para la construcción de un modulo del sistema. ANALISIS DE LOS REQUERIMIENTOS DE INFORMACION 155
Si los costos del tiempo de programadores y analistas y los del equipo que utilizaran están dentro del presupuesto, se puede proceder a la elaboración del prototipo. La elaboración de prototipos es una excelente forma de facilitar la integración del sistema de información con el sistema principal de la organización.
LINEAMIENTOS PARA DESARROLLAR UN PROTOTIPO Una vez que se ha tomado la decisión de elaborar un prototipo, se deben observar cuatro lineamientos principales al integrar la elaboraron de prototipos con la fase de determinación de requerimientos del SDLC. 1. 2. 3. 4. Tabajar en modulos manejables. Costruir rapidamente el prototipo . Modificar el prototipo en interacciones sucesivas. Poner énfasis en la interfaz de usuario. Como puede ver, los linamientos sugieren acciones relativas al prototipo que necesariamente se interrelacionan .Cada uno de los lineamientos se explica en las sucesiones siguientes .
El trabajo en modulos manejables Cuando el prototipo de algunas delas caracteristicas de un sistema se integra para formar un modelo funcional, es indeisoensable que el analista trabaje en modulos manejables. Una ventaja evidente de la elaboración de prototipos es que no esnecesario ni deseable construir un sistema operativo completopara los propositos del prototipo.Un modulo manejables aquel que permite a los usuarios interactuar con sus caracteristicas clave pero que se puede Contruir de forma separada de otros modulos de sistemas .Lascaracteristicas del modulo que se juzgan de menor importancia se nomiten intecionalmenteen el prototipo inicial.
Contruccion rapidadel prototipo La rapidez es esncial para la elaboración exitosa del prototipo de un sistema de información.Recuerde que unas de las quejas expresadas en contra de el CDLC tradicionales es que el intervalo entre la descriminacion de requerimientos y a entrega de unsistema completo es demasiado largo para satisfacer eficazmente las cambiantes necesidades del usuario. Los analistas pueden usar la elaboración de prototipos con el fin de reducir esta brecha utilizando las tecnicas tradicionales de recopilación de información para determinar con presion 156 ANALISI DE LOS REQUEREMIENTOS DE INFORMACION
los requerimientos de infomacion que surgan sobre la marcha, y acontinuacion tomar rapidamente las desiciones que den lugar o un modelo funcional. De hecho, el usuario de y utiliza el sistema muy temprano en el SDLC en lugar de esperar hasta que el sistema se termine para practicar con èl. La preparación de un prototipo operacional, con rapidez y en las etapas tempranas del SDLC , permite al analista comprender mejor como desarrollar el resto del proyeto .Al mostrar a los usuarios en las primeras etapas del proceso como se ejecutan en la realidad algunas partes del sistema , la nelaboracion rapida de prototipos evita que se dediquen demaciados recursos aun proyecto que a la larga podria ser imposible de concretar .Mas adelante, cuando se explique el RAD, usted vera nuevamente la importancia de la construccion rapida de sistemas . Modificacion del prototipo Un tercer lineamiento para desarrollar el prototipo es que su construccion debe soportar modificaciones. Hacer un modificable el prototipo significa crearlo en modulos que no sean demasiado interdependientes. Si se observa este alineamiento, se encontrara menos resistencia cuando sea necesario realizar cambios al prototipo. Generalmente, el prototipo se modifica varias veces al pasar por diversas interaciones. Los cambios en el prototipodeben propisisar en el sistema se acerque cada vez mas a lo que los usuarios consideren importante. Cada modificacion necesita otra evaluacion por parte de los usuarios. El prototipo no es un sistema terminado. Abordar la face de elaboración de prototipos con la idea de que el prototipo requerira modificaciones es una actitud positiva que demuestra a los usuarios cuan necesaria es una retroalimentación para mejorar el sistema.
Tan solo tengamos un poco de paciencia. Creo que necesitamos incorporal alguna características mas, ante de entregarles el prototipo. De otra manera, este prototipo se urdirá por completo”, dice SAM Monroe, un miembro de su equipo de análisis de sistemas. Los cuatro miembros del equipo en están enfrascados en una reunión convocada con precipitación, y discuten acerca del prototipo que desarrollan para un sistema de información que servirá a los gerentes para supervisar y controlar la temperatura del agua, la cantidad de peces puestos a la venta y otros factores en un criadero comercial de peces”.“Ya tiene bastante que hacer. ¡Vaya!, el sistema empezó con cuatro características y ya llevamos nueve. Siendo como si estuviéramos nadando contra la corriente. Ello no necesita todo esto. Incluso ni lo quiere”, sostiene Belle Uga, segundo miembro del equipo de análisis del sistema. “No quiero polemizar, pero opino que tan solo les demos lo elemental. Ya tenemos suficiente de que preocuparnos a si como están las cosas”. “yo creo que Monroe tiene razón”, opina wally Ide, un tercer miembro del equipo, contra poniéndose un poco a Belle. “tenemos que darles lo mejor que podamos, aun cuando esto signifique retrasar el prototipo una cuantas semanas mas de lo que prometimos”. “De acuerdo,” responde Belle con cautela, “pero quiero que ustedes dos expliquen, a los gerentes del criaderos por que no les estamos entregando el prototipo. Yo no quiero hacerlo. Y no estoy seguro de que muerdan el anzuelo tan fácilmente”.Moroe contesta: “Bueno, creo que podemos hacerlo, pero tal vez no consigamos un buen trato a retrasarnos Wally coincide: “Es cierto. ¿Por que mostrar nuestros errores a todos? A demás, cuando vean el prototipo, se olvidarán de cualquier queja que tengan. Les encantara”. Belle saca de su cuaderno un memorando de su última reunión del 22 de septiembre. “Elaboraron de prototipos: la importancia del desarrollo rápido, conjuntar el equipo analista de usuarios, obtener una rápida retroalimentación para hacer las modificaciones…”La voz de Belle de desvanece, omitiendo los últimos puntos de la agenda. Después de esto comentarios, Moroe e Ide se miran desconsoladamente. Moroe habla primero: “supongo que hicimos el intento de entusiasmar a todos de que esperaban un prototipo. Y se involucraran desde el primer día”.pero las aguas aun están agitadas. ¿Qué crees que debemos hacer?”, le pregunta usted.
En su cualidad de cuarto miembro del equipo de análisis de sistemas, ¿que acciones cree que deban emprenderse? En uno o dos párrafos, envié un mensaje de correo electrónico a sus compañeros de equipo con la respuesta a las siguientes preguntas: ¿deben incorporarse mas características al prototipo del sistema del criadero antes de entregarlos a los gerentes para que experimenten con el? ¿Que tan importante es el desarrollo rápido del prototipo? ¿Cuales son las ventajas y desventajas de incorporar más características al prototipo o de entregarle al cliente un prototipo más elemental que el que se le prometió? Finalice su mensaje con una recomendación. mas de lo que queremos. No quiero complicar las cosas”.
EL PAPEL DEL USUARIO EN LA ELABORACION DE PROTOTIPOS Natural El papel del usuario en la elaboración de prototipo se puede resumir en dos palabras: intervención honrada. Sin en la intervención del usuario hay poca razón para elaborar el prototipo los comportamientos precisos y necesarios para interactuar con un prototipo pueden variar pero el usuario es fundamental en el proceso de la elaboración del prototipo comprendido la importancia que tiene el usuario en el éxito del proceso, los miembros del equipo del análisis del sistema deben propiciar y recibir de buena manera la retroalimentación y deben evitar su propia resistencia y cambiar el prototipo.
INTERACCION DEL PROTOTIPO Hay tres formas principales en la que un usuario pude ayudar en la elaboración de un prototipo Oportunidad de consultaría 6.3
EL CRIADERO DE PECES 1. Experimentando en el prototipo. 2. Dando reacciones sinceras sobre el prototipo. 3. Sugiriendo adiciones o eliminaciones al prototipo.
ELABORACIÓN DEL PROTOTIPO, RAD Y PROGRAMACION EXTREMA Capitulo 6 159
Los usuarios deben tener libertad para experimentar con el prototipo. En contraste con una simple lista de características del sistema, el prototipo permite a los usuarios la interacción real. Una forma de facilitar esta interacción es instalar un prototipo en un sitio Web interactivo
Enfoques pioneros de Martín para el RAD En la figura 6.5 usted puede ver nuestra coceptualizacion de la fases originales del RAD de james Martín en la primera fase Martín explica la planeacion de requerimiento. Aquí los usuarios de alto nivel deciden que funciones deben incluir la aplicación. En la segunda fase, llamada fase de diseño de usuarios, Martín caracteriza a los usuarios como ocupados en discutir los aspectos no técnicos del diseño del sistema, con la ayuda de los analistas. La fase del taller del diseño del RAD incorpora la fase del usuario y la de construcción es una, debido a que la naturaleza muy interactiva y visual del proceso de diseño y refinación esta ocurriendo de una forma interactiva y participativa. En la fase de construcción se realizan muchas actividades diferentes. Cualesquier diseño que se creen en la fase anterior se mejoran más con la herramienta del RAD. Tan pronto como las nuevas funciones esta disponibles, se muestran a los usuarios para la interacción, comentarios y revisión. Con las herramientas del RAD, los analistas pueden hacer cambios continuos en el diseño de las aplicaciones. La cuarta y última fase de Martín, la fase de cierre la aplicación recientemente desarrollada reemplazara a la anterior. Mientras esta ejecutándose en paralelo con la aplicación anterior, la nueva prueba, los usuarios son entrenados y los procedimientos de la organización se cambia antes de que ocurra el cierre.
Herramientas de software para el RAD Como usted podía esperar, por lo regular las herramientas de software para el RAD son las mas nuevas, con frecuencias orientadas a objetos. Algunos ejemplos son programas muy conocidos como Microsoft Acces, Microsoft Basic, visual C++Microsoft. Net. (Véase el capitulo 18 para una explicación mas detallada del enfoque orientado a objetos.) Una forma en que las herramientas difieren entre si esta en sus capacidades para dar soporte a las aplicaciones cliente/servidor (por ejemplo, MS Access no da soporte, Visual Basic si lo da) así como también su facilidad de uso y el nivel de conocimientos de programación que se requieren. La mayoría de las aplicaciones del RAD se usan para aplicaciones pequeñas basadas en PC, aunque su verdadero poder podría radicar en las aplicaciones cliente/ servidor que necesitan ejecutarse otra vez de múltiples plataformas. Aunque hay identificadas casi tantas fases diferentes del RAD así como hay analistas, las cuatros fases propuestas por Martín –planeacion de requerimientos, diseño del usuario, la construcción y cierre – son útiles. Examinemos cada una con más detalle, comparándolas y contrastándolas con la elaboración de las características de la elaboración prototipos clásica y el SDLC tradicional.
RAD EN COMPARACION CON EL SDLC En la figura 6.6 se puede comparar las fases del SDLC con aquellas detalladas para el RAD al principio de esta sección. Observe que el principal propósito del RAD es acortar el SDLC de esta forma responder mas rápidamente a los requerimientos de información dinámicos de las organizaciones. El SDLC toma un enfoque mas metódico y sistemático que asegura al integridad y exactitud y tiene compropósito la creación de sistemas que se integran en los procedimientos estándar de negocio y en la cultura.La fase del taller del diseño del RAD difiere de las fases de diseño estándar del SDLC, debido a que las herramientas de software de RAD se usan para general pantallas y exhibir Fase de planeacion de requerimientos Fase de diseño del usuario Fase de construcción Fase de cierre Figura 6.5 Fases del RAD de Martín
Identificar los objetivos y los requerimientos de información
Retroalimentación del usuario
Trabajar con los usuarios para diseñar el sistema Construir el sistema Usar los comentarios de los usuarios usuarios
Presentar el sistema El enfoque del RAD permite un desarrollo rápido. Identificar oportunidades y objetivos
Determinar los requerimientos de información., desarrollar diagramas E-R Analizar las necesidades de los sistemas, desarrollar DFDS y almacenes de datos Diseñar el sistema recomendado
Desarrollar y documentar el sistema Probar el sistema Presentar el sistema El enfoque SDLC permite un análisis sistemático cuidadoso, diseño y documentación de los sistemas Figura 6.6
El taller de diseño del RAD en comparación con el enfoque del SDLC ANALISSIS DE LOS REQUERIMIENTOS DE INFOTMACION 164
Identificar los objetivos y los requerimientos de información
Retroalimentación del usuario
Trabajar con los usuarios para diseñar el sistema Construir el sistema Usar los comentarios de los usuarios El enfoque del RAD permite un desarrollo rápido. Presentar el sistema Identificar oportunidades y objetivos
Desarrollar y documentar el sistema Desarrollar y documentar el sistema Desarrollar y Diseñar el sistema recomendado
El flujo global de funcionamiento de la aplicación. Así, cuando los usuarios aprueban este diseño, están conviviendo en una representación del modelo visual, no solo en un diseño conceptual representado en papel, como tradicionalmente se hace. La fase de implementación del RAD es, en muchas formas, menos estresantes que otras debido a que los usuarios han ayudado a diseñar los aspectos de negocios del sistema y saben perfectamente que cambios se harán. Ay pocas sorpresas, y el cambio es algo a lo que se le da la bienvenida. Con frecuencia, cuando se utiliza el SDLC y los analistas están separados de los usuarios, ay mucho tiempo entre el desarrollo y el diseño. Durante este periodo, los requerimientos pueden cambiar y los usuarios se pueden sorprender si el producto final es diferente del que se anticipo durante muchos meses. Cuando utilizar el RAD En su función de analista, necesita aprender tantos enfoques y herramientas como sea posible que lo ayuden a hacer mejor su trabajo. Ciertas aplicaciones y trabajo de sistemas darán lugar a ciertas metodologías. Considere utilizar RAD cuando: 1. su equipo incluya a programadores y analistas que tengan experiencia con el, y 2. haya razones de negocio urgentes para acelerar una parte del desarrollo de la aplicación; o 3. cuando este trabajando con una nueva aplicación de comercio electrónico y su equipo de desarrollo crea que el negocio puede beneficiarse ampliamente sobre sus competidores siendo innovador si esta aplicación esta entre la primera en aparecer en la Web; o 4. cuando los usuarios sean maduros y estén altamente comprometidos con las metas organizacionales Desventajas del RAD Las dificultades con el RAD, como con otras clases de elaboración de prototipos, se originan debido a que los analistas de sistemas intentan apresurar demasiado el proyecto. Suponga que se contratan dos carpintero parra construir dos cobertizos de almacenamiento para dos vecinos. El primer carpintero sigue la filosofía del SDLC, mientras que el segundo la del RAD. El primer carpintero es sistemático, cataloga cada herramienta, cada podadora y cada unos de los muebles del patio para determinar el tamaño correcto del cobertizo, diseña un plano del cobertizo y anota las especificaciones para cada parte de madera y hardware. El carpintero construye el cobertizo con poca perdida y tiene la documentación precisa sobre como fue construido el cobertizo por si cualquiera quisiera construir otro parecido, repararlo o pintarlo del mismo color. El segundo carpintero va directo al proyecto y calcula el tamaño del cobertizo, consigue un camión de madera y hardware, construye una estructura y discute con el dueño de la propiedad las modificaciones necesarias sino están disponibles ciertos materiales y hace un viaje para devolver la madera que no se usa. El cobertizo se construye rápidamente, pero si no se hace un plano nunca existe la documentación. PROGRAMACION EXTREMA La programación extrema (XP) es un enfoque de desarrollo de software (tratando el capitulo 3 ) que adopta lo que generalmente designamos como practica de desarrollo de software aceptable y las lleva al extremo. Por ejemplo, la retroalimentación es importante
Cuatro valores de XP Hay cuatro valores que crean un entorno en el cual se pueden servir adecuadamente diseñadores y negocios. Debido a que con frecuencia hay una tensión entre lo que los diseñadores hacen a corto plazo y lo que es comercialmente deseable a largo plazo, es importante que este consiente de apoyar valores que formaran una base para colaboral juntos en un proyecto de software. Como se muestra la figura 6.7, los cuatro valores son cumnicacion, sencillez y retroalimentación y valentía. Empecemos con la comunicación. Cada esfuerzo humano tiene la posibilidad de fallar en la comunicación. Los proyectos de los sistemas que requieren una actualización constante y un diseño técnico son especialmente propensos a dichos errores. Agregue a este proyecto fechas limite ajustadas, jerga especializada y el estereotipo de que los programadores prefieren hablar con las maquinas que con las personas, y usted tiene los ingrediente para algunos problema serios de comunicación. Los proyectos pueden ser retrasado; se puede resorber el problema equivocado; se castiga los programadores incluso por mensional a los Elaboración de prototipos, RAD y programación extrema Capitulo 6 165 para los programadores, analistas, diseñadores, usuarios y computadoras (como verán en el capitulo 14). Así que la programación extrema usa ciclo de retroalimentación cada vez más rápido e intenso, que proporcionan más información. La administración de proyeto es importante ( como se vio en el capitulo 3), de tal manera que la programación extrema intenta definir rapidamente un plan global del sistema, desarrollar y liberar rapidamente el software y posteriormente revisarlo continuamente para incorporarles caracteristicas adicionales. Los programadores, analistas y diseñadores ordinarios que trabajan independientemente y luego integran su trabajo logran resultados solidos; los programadores extremos que trabajan en parejas pueden ser excelentes. Pero la programación extrema no solo se basa en los resultados. Se basa en los valores principios y practicas. Ahora examinaremos como los valores y Principios de XP dan forma al desarrollo de sistemas extremos.
VALORES Y PRINCIPIOS DE LA PROGRAMACION EXTREMA Para la programación extrema es importante que se declaren los valores y principios que crean el contexto para la colaboración entre programadores y clientes. Para considerarse analistas de XP se debe apegar a los siguientes valores y principios desarrollados por Beck (2000).
simpleza
comunicación
valentia
retroalimentaci on valores de XP
gerentes que hay problemas; las personas abandonan o se unen al proyecto a la mitad sin estar al corriente; y así continua la letanía. Practicas típicas de XP tal como la programación en pareja (colaboración de dos programadores, descrita mas adelante en el capitulo), estimación de las tareas y las pruebas de software, requieren de una buena comunicación. Los problemas se resuelven rápidamente, los agujeros se tapan y la opinión débil se fortalece rápidamente a través de la interacción con otros en el equipo. Un instructor de XP, como se describió en el capitulo 3, esta presente para observar si alguien ha interrumpido la comunicación y para reunirlos. El segundo valor de la programación extrema es la simpleza. Cuando estamos trabajando en un proyecto de desarrollo de software, nuestra primera reacción 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 más sencilla que podemos hacer. La simpleza lleva tiempo, y es algo en lo que el instructor de XP podría ayudarle. El valor de XP de simpleza nos pide que hoy hagamos la cosa más sencilla, comprendiendo que mañana se podría cambiar un poco. Esto quiere un enfoque claro de las metas del proyecto y realmente es un valor básico. La retroalimentación es el tercer valor básico que es importante para tener un enfoque de la programación extrema. Cuando piensa en la retroalimentación en este contexto, es bueno considerar que esta se relaciona con el concepto de tiempo. Una retroalimentación buena y cocreta, que es útil para el programador, analista y cliente puede ocurrir en segundos, minutos, días, semanas o meses, dependiendo de lo que se necesita, quien esta comunicando y lo que se hará con dicha retroalimentación. Un colega programador podría encontrar un caso de prueba que hiciera que un código que usted escribió fallara. Esto
Realizado por: Yoldany [email protected] Politécnico de azua 164 parte 11
| Página siguiente |