República bolivariana de Venezuela

Ministerio del poder popular para la educación

Universidad nacional experimentar de las fuerzas armadas.

“UNEFA”

VI semestre de ingeniería de sistema.

Sección; “U”.

Trabajo.

PROFESOR: ALUMNO:

IVAN Santaella Odalys.

RICCIARI Muñoz Arnaldo.

Mora Argenis.

Ocumare del tuy; Edo, MIRANDA

TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN

Los analistas utilizan una variable de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionario, inspección de registros y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa. A continuación se verán cada una de ellas.

Entrevista

Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responde pueden ser gerentes o empleados, los cuales son usuarios actuales del

Sistema, existen usuarios potenciales del sistema propuesto o aquellos que proporcionaran datos o serán afectadas por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos.

Recabar datos mediante la entrevista.

La entrevista es una forma de conversación, ¡no interrogación! Al analizar las características de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre es sistema los analistas pueden conocerlos datos que no están disponibles en ninguna otra forma.

En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la información son importantes. La información cualitativa esta relacionada con opiniones, políticas y descripciones cuantitativas trata con números, frecuencia o cantidades. A menudo las entrevistas dan la mejor fuente de información cualitativa; los otros métodos tienden a ser más útiles en la recaudacion de datos cuantitativos.

Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. Como resultado de esto las entrevistas pueden descubrir rápidamente malos entendidos, falsas expectativas o incluso resistencia potencial para las aplicaciones en desarrollo; mas aun a menudo es más fácil calendarizar una entrevista con los gerentes del alto nivel, que pedirles que llenen cuestionarios.

Determinación del tipo de entrevista.

La estructura de las entrevistas varía. Si el objetivo de la entrevista radica en adquirir información general, es conveniente elaborar una serie de preguntas sin estructura, con una sección de preguntas y respuestas libres. La atmósfera abierta y de fácil flujo de esta modalidad proporciona una mayor oportunidad para conocer las actitudes, ideas y creencias de quien responde. Sin embargo, cuando los analistas necesitan adquirir datos más específicos sobre la aplicación o desean asegurar una alta confiabilidad en las respuestas a las preguntas que han propuesto a sus entrevistados, las entrevistas estructuradas son mejores.

Las entrevistas estructuradas utilizan preguntas estandarizadas. El formato de respuestas para las preguntas puede ser abierto o cerrado; las preguntas para respuesta abierta permiten a los entrevistados dar cualquier respuesta que parezca apropiada. Con las preguntas para respuestas cerradas se proporciona al usuario un conjunto de respuestas que se pueda seleccionar. Todas las personas que responden se basan en un mismo conjunto de posibles respuestas.

La confiabilidad es solo una consideración en la selección del método de entrevista. Los analistas también deben dividir su tiempo entre desarrollar preguntas para entrevistas y analizar las respuestas. Las entrevistas no estructuradas requieren menos tiempo de preparación, porque no se necesita tener por anticipado las palabras precisas de las preguntas. Sin embargo, analizar las respuestas después de las entrevistas lleva más tiempo que con las entrevistas estructuradas. De cualquier manera, el mayor costo radica en la preparación, administración y análisis de las entrevistas estructuradas para preguntas cerradas.

Dado que un numero de personas se seleccionara para la entrevista, los analistas deben tener cuidado de incluir aquellas personas que tienen información que no se podrá conseguir de otra forma. Durante las primeras etapas de un estudio de sistemas, cuando los analistas determinan

La factibilidad del proyecto, con frecuencia las entrevistas solo se aplican a la gerencia o personal de supervisión. Sin embargo, durante la investigación detallada en donde el objetivo es descubrir hechos específicos, opiniones y conocer como se manejan las operaciones desempeñadas actualmente, las entrevistas se aplican en todos los niveles gerenciales y de empleados y dependen de quien pueda proporcionar la mayor parte de la información útil para el estudio. Así, los analistas que estudian ala administración de inventarios pueden entrevistar a los trabajadores del embarque y de recepción, al personal del almacén y a los supervisores de los diferentes turnos, es decir, aquellas personas que realmente trabajan en el almacén; también entrevistaran a los agentes más importantes.

Realización de la entrevista.

La habilidad del entrevistador es vital para el éxito en la búsqueda de hechos por medio de la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparación del objetivo de una entrevista específica como de las preguntas por realizar a una persona determinada.

El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. La falta de estos factores puede reducir cualquier oportunidad de éxito. Por ejemplo, un analista que trabaja en la aplicación enfocada a la reducción de errores probablemente no tendría éxito si llegar a una oficina de gerencia de nivel medio con la presentación equivocada, por ejemplo, si dijera, “hola, fui enviado para encontrar una forma de mojar el rendimiento y de reducir los errores que presentan aquí. O la introducción: “Estamos aquí para resolver su problema”, es igualmente mala. Es imaginable la rapidez con la que va a responder ser irrita y se molesta con un enfoque de este tipo.

A través de la entrevista, los analistas deben preguntarse así mismos las siguientes interrogantes:

¿Qué es lo que me esta diciendo la persona?

¿Por qué me lo esta diciendo a mí?

¿Qué se esta olvidando?

¿Qué espera esta persona que haga yo?

Si se considera cada elemento de la información contra estas preguntas, los analistas tendrán más conocimientos no solamente de la información adquirida sino también de su importancia.

Cuestionario

Los cuestionarios proporcionan una alternativa muy útil para las entrevistas; sin embargo, existen ciertas características que pueden ser apropiadas en algunas situaciones e inapropiadas en otras.

Recaudación de datos mediante cuestionarios

Para los analistas los cuestionarios pueden ser la única forma posible de relacionarse con un gran número de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo largos estudios en varios departamentos, se puede distribuir los cuestionarios a

todas las personas apropiadas para recabar hechos con relación al sistema. Por supuesto, no es posible observar las expresiones o relaciones de quienes responden a los cuestionarios.

También las preguntas estandarizadas pueden proporcionar datos más confiables. Por otra parte, las características anteriores también son desventajas de los cuestionarios. Aunque su aplicación puede realizarse con un mayor numero de individuos, es muy rara una respuesta total. Puede necesitarse algún seguimiento de los cuestionarios para motivar al personal que responda; todas las respuestas se encontraran en una proporción entre el 25 o 35%, que es lo más común.

Selección de formas para cuestionarios.

El desarrollo y distribución de los cuestionarios es caro; por lo tanto, el tiempo invertido en esto debe utilizarse en una forma inteligente. También es importante el formato y contenido de las preguntas en la recopilación de hechos significativos.

Existen dos formas de cuestionarios para recabar datos; cuestionario abierto y cerrados, y se aplican dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlos. Con frecuencia se utilizan ambas formas en los estudios de sistemas.

Cuestionarios abiertos.

Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos, opiniones y experiencias generales; también son útiles al explorar el problema básico, por ejemplo, un analista que utiliza cuestionarios para estudiar los métodos de verificación de crédito, en un medio ambiente de ventas al a menudeo, podría recabar mas información provechosa de una pregunta abierta de este tipo: ¿Cómo podría simplificarse y mejorarse el proceso de verificación de crédito para los clientes?

Cuestionarios cerrados.

El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el mejor método para obtener información sobre los hechos. También fuerza a los individuos para que tomen una posición y forma de opinión sobre los aspectos importantes.

Etapas en el desarrollo de un cuestionario

Los cuestionarios bien hechos no se desarrollan rápidamente, llevan tiempo y mucho trabajo. La primera consideración se encuentra en determinar el objetivo del cuestionario. ¿Qué datos quiere conocer el analista a través de su uso? El analista define como utilizar los cuestionarios a fin de obtener los hechos al considerar la estructura mas útil para el estudio y la más sencilla de entender por parte de los interrogados.

Lleva tiempo desarrollar preguntas bien elaboradas y deben siempre probarse y modificarse, si es necesario, antes de que imprima una forma final y se distribuya.

Selección de quienes recibirán el cuestionario

Aquellas personas que reciban el cuestionario deben seleccionarse de a cuerdo con la información que puedan proporcionar. Escribir o imprimir un cuestionario no significa que se pueda distribuir ampliamente sin un análisis previo. Lo pueden contestar personas no calificadas y si el cuestionario no es anónimo, y no será posible retirar sus respuestas de la muestra. La realización de esto también es desgastante y cara.

Observación

¡Ver es creer! Observar las operaciones le proporciona la analista hechos que no podría obtener de otra forma.

Recopilación de datos mediante la observación

Leer en relación con una actividad del negocio le proporciona al analista una dimensión de las actividades del sistema. Entrevistar personal, ya sea directamente o a través de cuestionarios, también le ayuda y le dice algo más. Ninguno de los dos métodos da una información completa; por ejemplo, leer en relación con un viaje en jet no reproduce la experiencia de volar a unos 30 mil pies de altura.

La observación proporciona información de primera mano en relación con la forma en que se llevan a cabo las actividades. Las preguntas sobre el uso de documentos, la manera en la que se realizan las tareas y si ocurren los pasos específicos como se pre-establecierón, pueden contestarse rápidamente si se observan las operaciones.

Cuando observar

La observación es muy útil cuando el analista necesita ver de primera mano como se manejan los documentos, como se llevan a cabo los procesos y si ocurren los pasos especificados. Saber que buscar y como guiar su significado, también requiere de experiencia. Los observadores con experiencia captan quien utiliza los documentos y si encuentran dificultades; también están alertas para detectar documentos o registros que no se utilizan.

Muestreo

Con frecuencia, en muchas empresas la información ya se encuentra disponible para que el analista conozca las actividades u operaciones con las cuales no esta familiarizado. Muchos tipos de registros e informes son accesibles si el analista sabe donde buscar. En la revisión de registros, los analistas examinan datos y descripciones que ya están escritos o registrados y en relación con el sistema y los departamentos de usuarios. Esta forma de encontrar datos

puede servir como presentación del analista, si se realiza al iniciar el estudio, o como un termino de comparación de lo que sucede en el departamento con lo que los registros presentan como lo que debería suceder.

Recopilación de datos por medio de la inspección de registros.

El termino “registro” se refiere a los manuales escritos sobre políticas, regulaciones y procedimientos de operaciones estándar que la mayoría de las empresas mantienen como guía para gerentes y empleados. Los manuales que documentan o describen las operaciones para los procesos de datos existentes, o sistemas de información que entran dentro del área de investigación, también proporcionan una visión sobre la forma en la que el negocio debería conducirse. Normalmente muestran los requerimientos y restricciones del sistema (como cantidad de transacciones o capacidad de almacenamiento de datos) y características de diseño (controles y verificación del procesamiento).

Los registros permiten que los analistas se familiaricen con algunas operaciones, oficinas de la compañía y relaciones formales a las que debe darse apoyo. No obstante, no muestran como producen de hecho las actividades, donde se ubica el poder verdadero para las decisiones, o como se realizan las tareas en la actualidad. Los otros métodos con objeto de encontrar datos estudiados en esta sección son más eficaces para proporcionar al analista este tipo de información.

Selección de los registros para revisión

En la mayor parte de las empresas los manuales de estándares sobre procedimientos de operación usualmente son obsoletos; a menudo no se mantienen al corriente lo suficiente para señalar los procedimientos existentes. Los diagramas de organización muestran como las diferentes unidades deberían relacionarse con otras; pero muchas no reflejan las operaciones actuales.

Actividades obligatorias:

Explique brevemente la realización de la entrevista

Liste cuatro situaciones que hagan adecuado el uso de cuestionarios.

¿Cómo debe ser la selección de quien recibirá el cuestionario? Defina lo que significa muestreo

Actividades sugeridas:

Liste tres razones sobre el porqué la observación es útil para el analista de sistemas en la organización Explique brevemente la fase de muestreo.

¿Qué tipos de información deben ser buscados en las entrevistas?

Recursos para ampliar el tema

Pags. 79–82, 109–123, 147–163, 175–181, Análisis y diseño de sistemas, Kendall & Kendall, 3ª edición, ed. Pearson educación, 1997.

Autoevaluación

¿Qué es la entrevista?

¿Para que sirven los comentarios?

¿En que momento es útil observar?

¿Qué es el muestreo o para que sirve?

2. Prototipo

¿Qué es un Prototipo?Es un modelo a escala o facsímil de lo real, pero no tan funcional para que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final. Proporcionando una retroalimentación temprana por parte de los usuarios acerca del Sistema.

Importancia de Definir su ObjetivoSiempre se debe establecer cual es su objetivo, ya que un prototipo puede ser útil en diferentes fases del proyecto, por ello su objetivo debe ser claro. Durante la fase de análisis se usa para obtener los requerimientos del usuario. En la fase de diseño se usa para ayudar a evaluar muchos aspectos de la implementación seleccionada.

Propósitos del PrototipoEn la fase de Análisis de un proyecto, su principal propósito es obtener y validar los requerimientos esenciales, manteniendo abiertas, las opciones de implementación. Esto implica que se debe tomar los comentarios de los usuarios, pero debemos regresar a sus objetivos para no perder la atención.En la fase de Diseño, su propósito, basándose en los requerimientos previamente obtenidos, es mostrar las ventanas, su navegación, interacción, controles y botones al usuario y obtener una retroalimentación que nos permite mejorar el Diseño de Interfaz.

Características de los PrototiposEl proceso de desarrollo y empleo de prototipos tiene las siguientes características:

El prototipo es una aplicación que funciona Los prototipos se crean con rapidez

Los prototipos evolucionan a través de un proceso iterativo

Los prototipos tienen un costo bajo de desarrollo

Información Obtenida con el uso del PrototipoReacciones Iníciales del UsuarioEl profesional de Sistema por medio de la observación, evaluación y la retroalimentación, obtendrá como reaccionan los usuarios al trabajar con el prototipo, y que tan conveniente es el acoplamiento entre las necesidades y las características modeladas en el sistema. A través de la recopilación de tales reacciones, el profesional, irá descubriendo nuevas perspectivas del prototipo, incluso si los usuarios se encuentran satisfechos con él, o si habrá dificultades para vender o implantar el sistema.

SugerenciasLas sugerencias son el fruto de la relación de los usuarios con el prototipo, las sugerencias aportadas por el usuario indican al profesional porque caminos dirigirse para refinar el prototipo, modificarlo o depurarlo, de forma que satisfaga mejor las necesidades de los usuarios.

InnovacionesLas innovaciones son aquellas características nuevas del sistema que no fueron contempladas previamente a la interacción con el prototipo.

PrioridadesLa información que se obtiene con el uso de prototipos permite al profesional establecer prioridades y reorientar sus planes de una manera menos costosas y con un mínimo de contratiempo.Una de las peores cosas que le puede pasar a un profesional es diseñar e implantar un sistema que el usuario no necesita, ni desean.

3. Desarrollo de Prototipo

Problemas CandidatosPara decidir si el prototipo debe incluirse o no Ciclo de Desarrollo de Sistema de Información, el profesional considera los siguientes factores:

Problemas no estructurado, novedosos y complejos, de información personalizada del usuario, ya que sus salidas no son predecibles y definidas

Problemas de ambiente Inestable, el profesional también debe evaluar el contexto del sistema

Experiencia en diseños similares

No se conocen los requerimientos, la naturaleza del sistema es tal que existe poca información con respecto a las características que debe tener el nuevo sistema para satisfacer las necesidades del usuario

Los requerimientos deben evaluarse, se conocen los requerimientos aparentes de información pero es necesario verificarlos y evaluarlos

Costos altos, donde la inversión involucra gran cantidad de recursos financieros y humanos.

Altos riesgo, la evaluación inexacta de los requerimientos o el desarrollo incorrecto ponen en peligro a la organización

El usuario, donde no está dispuesta examinar modelos en papel, o no sabe lo que quiere pero lo reconocerá cuando lo vea.

Tecnologías Nuevas, la falta de experiencia en el uso de dichas tecnologías, junto con el deseo de instalar nuevas tecnología hace que sea propicio el uso del prototipo.

Etapas del PrototipoEl desarrollo de un prototipo se lleva a cabo en forma ordenada a través de las siguientes etapas, Figura 1:

Identificación de Requerimientos ConocidosEl profesional de sistema identifica los requerimientos conocidos, generales, o características esenciales y determina el propósito del prototipo de la aplicación.

Desarrollo de un ModeloEn esta etapa se explica el método iterativo y las responsabilidades a los usuarios ya que el usuario participa directamente en todo el proceso. La rapidez con la que se genera el sistema es esencial para que no se pierda el estado de ánimo sobre el proyecto y los usuarios puedan comenzar a evaluar la aplicación con la mayor brevedad posible. El profesional de sistema para construcción inicial del prototipo emplea cualquier herramienta, como Lenguajes de Cuarta Generación, Generadores de Reportes, Generadores de Pantallas

En el desarrollo de un prototipo se preparan los siguientes componentes:

El lenguaje para el diálogo o conversación entre el usuario y el sistema Pantallas y formatos para la entrada de datos

Módulos esenciales de procesamientos

Salida del sistema

La incorporación en la interfaz de entrada/salida de características representativas de las que serán incluidas en el sistema final permite una mayor exactitud en el proceso de evaluación.

Revisión del PrototipoEs responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación. La experiencia con el sistema bajo condiciones reales permite la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, o también la eliminación de características innecesarias. El profesional de sistema captura la información sobre lo que le gusta y lo que le desagrada a los usuarios. Esta información tiene influencia en la siguiente versión del prototipo, la cual se presenta modificada, refinada.

IteraciónLos dos últimos etapas descriptas anteriormente se repiten varias veces hasta que estén usuarios y profesionales de sistema de acuerdo en que el prototipo ha evolucionado lo suficiente o que una iteración mas no traerá beneficios adicionales.

Prototipo TerminadoCuando el prototipo está terminado, es decir, tenemos la información que buscamos seguimos en el punto donde habíamos quedado dentro del Ciclo de Desarrollo de Sistema.

4. Estrategias para el Desarrollo de Prototipos

Se puede desarrollar un prototipo para cada uno de los componentes de la aplicación

Prototipos por PantallasLa interface entre el sistema y el usuario es la pantalla de visualización, esta es el vehículo para presentar la información tal como ésta es proporcionada al sistema o como es recuperada de éste. Los prototipos de pantalla permiten evaluar la posición de información sobre la pantalla, los encabezados, los botones, mensajes. También permite la reacción de los usuarios por la cantidad de información sobre la pantalla. La creación de un prototipo de pantalla conduce a:

Que debe presentarse como información sobre la pantalla principal Cuál pertenece a una pantalla de detalle

Prototipos para Procedimientos de ProcesamientosLas funciones de procesamiento incluye entradas, cálculos, recuperar información y actividades de salidas. Como los datos pocas veces son ingresados de la forma correcta o en la secuencia válida, es por ello que la aplicación se diseña para asegurar la detección de errores.El objetivo es determinar si los procedimientos de aplicación fueron desarrollados adecuadamente.La evaluación de los procedimientos y la observación de errores y equivocaciones cometidas por los individuos cuando emplean el prototipo, pueden sugerir la adición de características de manejo de errores que no se habían anticipado.

Prototipos de Funciones BásicasPara determinar los requerimientos de una aplicación no es necesario desarrollar todos los módulos del sistema, sino los básicos, son aquellos que forman el núcleo de la aplicación.Incluye las funciones primarias de la aplicación como edición y validación, y excluye las secundarias como el manejo de archivos que no forman parte del procesamiento esencial.Por ejemplo:Una aplicación de Reclamos de una venta, tendrá módulos de:

Recepción de la información de la venta que se reclama Validación del número de factura

Recuperación de la venta

Generación de Nota de Crédito

Y pueden omitirse por ejemplo:

La impresión de la Nota de Crédito Registro de esta operación

5. Roles

Rol del UsuarioEl papel del usuario con el prototipo puede resumirse en compromiso y honestidad. Si carece de compromiso pocos son los motivos para desarrollar un prototipo, ya que el usuario es el pivote del proceso de desarrollo y evaluación. Los usuarios interactúan con el prototipo teniendo las siguientes responsabilidades:

Utilizar y evaluar el prototipo las veces que sea necesario Identificar mejoras

Sugerir las característica no deseadas

Describir los requerimientos de datos

Describir la salida deseada

Rol del Profesional de SistemaEl papel del profesional de sistema no solo debe construir el prototipo sino también que debe:

Crear el clima adecuado al usuario para que este se exprese sin temor alguno Familiarizar al usuario con el prototipo

Crear el plan para el desarrollo del prototipo

Construir la versión inicial

Evaluar las reacciones del usuario y plasmar las modificaciones en una nueva versión

6. Ventajas y Desventajas

Existen ventajas relevantes en el uso del Prototipo:

Modificación del Sistema en Etapas tempranas de su desarrollo: El éxito del uso del prototipo depende de qué tan pronto y con que frecuencia se reciba la retroalimentación del usuario para hacer cambios y adecuarlos a las necesidades actuales. Los cambios iníciales durante el desarrollo de un proyecto son menos

costosos que si se realizan en etapas tardías, como el prototipo puede cambiar varias veces la flexibilidad y adaptabilidad son su esencia, la pauta del cambio la da la retroalimentación, la cual nos permite conocer la opinión del usuario sobre cambios a la entrada o salida de un proceso, que al evaluarla nos permite obtener los requerimientos y mejorar el sistema.

El desarrollo de prototipos implica una inversión en tiempo y en dinero, siempre pero siempre es menor a la del sistema completo. Los problemas y descuidos de sistemas son más fáciles de detectar en un prototipo.

Eliminación de sistemas indeseables: Por permitir recopilar información nos permite eliminar un sistema que no llegó a ser lo que esperaban de él los usuarios. La inversión de tiempo y dinero se destaca pero es menor que la del sistema completo. Se toma esta decisión cuando el sistema no es útil o no satisface los objetivos que se propuso el equipo de desarrollo, es una decisión dificil pero evita seguir gastando dinero y tiempo en un proyecto inservible.

Diseño de Sistemas acorde a las necesidades y expectativas de los usuarios: El uso del prototipo hace que los sistemas se ajusten a las necesidades de los usuarios. Se reduce el intervalo de tiempo desde que se relevan los requerimientos y el sistema concluido. Permite que los usuarios se involucren desde el principio y lo hace participar en forma activa, de esta forma hacen suyo el proyecto, siendo los principales promotores del éxito.

El prototipo cuenta con las siguientes desventajas:

Administración difícil: Dicha dificultad radica en manejar el prototipo como un proyecto dentro del Ciclo de Desarrollo de Sistema sin perder de vista cual era su propósito.

Adoptarlo como el sistema final: Los usuarios y profesionales de sistemas pueden considerar al prototipo como el sistema final cuando aún es incompleto e inadecuado.

ELABORACIÓN 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.

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 precisión 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.

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. Trabajar en módulos manejables.2. Construir rápidamente el prototipo.

3. Modificar el prototipo en interacciones sucesivas.

4. Poner énfasis en la interfaz de usuario.

Como puede ver, los lineamientos sugieren acciones relativas al prototipo que necesariamente se interrelacionan .Cada uno de los lineamientos se explica en las sucesiones siguientes.

El trabajo en módulos manejables- Cuando el prototipo de algunas de las características de un sistema se integra para formar un modelo funcional, es indispensable que el analista trabaje en módulos manejables. Una ventaja evidente de la elaboración de prototipos es que no es necesario ni deseable construir un sistema operativo completo para los propósitos del prototipo. Un módulo manejable es aquel que permite a los usuarios interactuar con sus características clave pero que se puede contruir de forma separada de otros módulos de

sistemas. Las características del módulo que se juzgan de menor importancia se omiten intencionalmente en el prototipo inicial.

Construcción rápida del prototipo- La rapidez es esencial para la elaboración exitosa del prototipo de un sistema de información. Recuerde que unas de las quejas expresadas en contra del CDLC tradicionales es que el intervalo entre la discriminación 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 elaboración de prototipos con el fin de reducir esta brecha utilizando las técnicas tradicionales de recopilación de información para determinar con presión los requerimientos de información que surjan sobre la marcha, y a continuación tomar rápidamente las decisiones 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 cómo 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 elaboración rápida de prototipos evita que se dediquen demasiados recursos a un proyecto que a la larga podría ser imposible de concretar. Más adelante, cuando se explique el RAD, usted verá nuevamente la importancia de la construcción rápida de sistemas.

Modificación del prototipo. Un tercer lineamiento para desarrollar el prototipo es que su construcción debe soportar modificaciones. Hacer un modificable el prototipo significa crearlo en módulos que no sean demasiado interdependientes. Si se observa este alineamiento, 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 más a lo que los usuarios consideren importante. Cada modificación necesita otra evaluación por parte de los usuarios.

El prototipo no es un sistema terminado. Abordar la fase de elaboración de prototipos con la idea de que el prototipo requerirá modificaciones es una actitud positiva que demuestra a los usuarios cuán necesaria es una retroalimentación para mejorar el sistema.

EL PAPEL DEL USUARIO EN LA ELABORACIÓN DE PROTOTIPOS

El papel del usuario en la elaboración de prototipo se puede resumir en dos palabras: intervención honrada. Sin 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 comprendida 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.

INTERACCIÓN DEL PROTOTIPO

Hay tres formas principales en la que un usuario pude ayudar en la elaboración de un prototipo

1. Experimentando en el prototipo.2. Dando reacciones sinceras sobre el prototipo.

3. Sugiriendo adiciones o eliminaciones al prototipo.

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 conceptualización de la fases originales del RAD de James Martin; en la primera fase Martin explica la planeación de requerimiento. Aquí los usuarios de alto nivel deciden qué funciones deben incluir la aplicación.

En la segunda fase, llamada fase de diseño de usuarios, Martin 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 está ocurriendo de una forma interactiva y participativa.

En la fase de construcción se realizan muchas actividades diferentes. Cualquier diseño que se cree en la fase anterior se mejora más con la herramienta del RAD. Tan pronto como las nuevas funciones están 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 Martin, la fase de cierre, la aplicación recientemente desarrollada reemplazará a la anterior. Mientras está ejecutándose en paralelo con la aplicación anterior, la nueva prueba, los usuarios son entrenados y los procedimientos de la organización se cambian 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 capítulo 18 para una explicación más detallada del enfoque orientado a objetos.)

Una forma en que las herramientas difieren entre sí está 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 Martin –planeación 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 COMPARACIÓN CON EL SDLC

En la figura 6.6 se pueden 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 más rápidamente a los requerimientos de información dinámicos de las organizaciones. El SDLC toma un enfoque más metódico y sistemático que asegura la integridad y exactitud y tiene como propó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 generar pantallas y exhibir

El taller de diseño del RAD en comparación con el enfoque del SDLC

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, y2.

3. haya razones de negocio urgentes para acelerar una parte del desarrollo de la aplicación; o

4. cuando esté 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 está entre la primera en aparecer en la Web; o

5. 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 carpinteros 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 uno 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 pérdida y tiene la documentación precisa sobre cómo 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 si no 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.

PROGRAMACIÓN EXTREMA

La programación extrema (XP) es un enfoque de desarrollo de software (tratando el capítulo 3) que adopta lo que generalmente designamos como práctica de desarrollo de software aceptable y las lleva al extremo. Por ejemplo, la retroalimentación es importante para los programadores, analistas, diseñadores, usuarios y computadoras (como verán en el capítulo 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 proyecto es importante ( como se vio en el capitulo 3), de tal manera que la programación extrema intenta definir rápidamente un plan global del sistema, desarrollar y liberar rápidamente el software y posteriormente revisarlo continuamente para incorporarles características adicionales. Los programadores, analistas y diseñadores ordinarios que trabajan independientemente y luego integran su trabajo logran resultados sólidos; 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 prácticas. Ahora examinaremos como los valores y Principios de XP dan forma al desarrollo de sistemas extremos.

VALORES Y PRINCIPIOS DE LA PROGRAMACIÓN 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).

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 esté consciente de apoyar valores que formarán una base para colaborar juntos en un proyecto de software. Como se muestra la figura 6.7, los cuatro valores son comunicación, 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 límite ajustado, jerga especializada y el estereotipo de que los programadores prefieren hablar con las máquinas que con las personas, y usted tiene el ingrediente para algunos problemas serios de comunicación. 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 letanía.

Prácticas 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.