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.
5.1.1 E N T R E V I S T A
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 tratan 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 mas útiles en la recabación 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 varia. 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 especifica 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 mas conocimientos no solamente de la información adquirida sino también de su importancia.
5.1.2 C U E S T I O N A R I O .
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.
Recabación de datos mediante cuestionarios
Para los analistas los cuestionarios pueden ser la única forma posible de relacionarse con un gran numero 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.
5.1.3 RECOPILACIÓN Y ANALISIS DE DOCUMENTOS
Recopilación de datos: Deberá dirigirse al registro de aquellos hechos que permitan conocer y analizar lo que realmente sucede en la unidad o tema que se investiga. Esto consiste en la recolección, síntesis, organización y comprensión de los datos que se requieren.
Se conocen dos tipos de fuentes:
1.Primarias: que contienen información original no abreviada ni traducida.
2.Secundarias: obras de referencia que auxilian al proceso de investigación.
Se conoce otra división que se conforma por las siguientes fuentes:
-Documentales
-De campo.
FICHAS BIBLIOGRÁFICAS, DE TRABAJO Y HEMEROGRÁFICAS
Las fuentes de recolección de datos son todos los registros de aquellos hechos que permitan conocer y analizar lo que realmente sucede en el tema que se investiga.
Concluida la parte preparatoria de la investigación se inicia la fase de recopilación de datos.
Para recabar la información existente sobre el tema, el investigador se auxilia de instrumentos como las fichas de trabajo; hay diversos tipos de fichas de trabajo como:
Fichas de trabajo para fuentes documentales, fichas de trabajo de una revista, fichas de trabajo de un periódico, para investigación de campo, para observación, fichas bibliográficas y hemerográficas.
ANÁLISIS E INTERPRETACIÓN DE INFORMACIÓN
La interpretación de los resultados de la indagación lleva inmediatamente a la solución.
El análisis del instrumento de recolección de información de campo (encuesta), fue utilizando el análisis individual de preguntas que se realiza con base en los porcentajes que alcanzan las distintas respuestas de cada pregunta.
Para llevar a cabo este tipo de análisis se diseño una forma donde se tabulan las respuestas en base a la cantidad de personas que contestaron cada respuesta y el porcentaje que representa del total de la muestra.
REDACCIÓN Y PRESENTACIÓN DEL INFORME
El objetivo del informe es presentar a los lectores el proceso que se realizó para presentar una solución al problema planteado, para lo cual es necesario hacer la presentación del problema, los métodos empleados para su estudio, los resultados obtenidos, las conclusiones a las que se llegaron y las recomendaciones en base a estas.
Con respecto a la estructura del informe, ésta es sencilla y sigue fielmente los pasos fundamentales del diseño de la investigación, ya que el informe debe ser la respuesta a lo planteado por el diseño de investigación.
5.1.4 OBSERVACION Y TECNICA STROBE
OBSERVACION ESTRUCTURADA DEL AMBIENTE (STROBE)
Confirma o niega la narración organizacional de entrevistas o cuestionarios.
La observación es sistemática:
1. Sigue una metodología estándar y una clasificación estándar para el análisis de los elementos organizacionales que influencian la toma de decisiones. 2. Permite que otros analistas apliquen el mismo marco de trabajo analítico a la misma organización. 3. Limita el análisis a la organización como existe durante la etapa de su ciclo actual de vida.
Elemento STROBE son 7:
1. Ubicación de la oficina. La ubicación de la oficia de un tomador de decisiones particular con respecto a las demás oficinas.
2. Ubicación del escritorio del tomador de decisiones. Proporciona pistas sobre el ejercicio de poder por el tomador de decisiones.
3. Equipo de oficina fijo. Se conforma de archiveros, libreros, etc.
4. Propiedades. Todo el equipo pequeño que se usa para procesar información (calculadoras, pantallas de video, lápices, etc.).
5. Revistas y periódicos del negocio. Estas revelan si el tomador de decisiones busca información externa o se apoya más en información interna.
6. Iluminación y color de la oficina. Nos indica la manera en que el tomador de decisiones recopila información.
7. Vestimenta usada por los tomadores de decisiones. El analista de sistemas puede obtener una comprensión de la credibilidad exhibida por los gerentes de la organización observando la vestimenta que usan en el trabajo.
Mediante el uso de STROBE el analista de sistemas puede obtener una mejor comprensión sobre la manera en que los gerentes recopilan, procesan, almacenan y usan información.
5.2 Herramientas CASE
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Ordenador) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, calculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.
Objetivos
1. Mejorar la productividad en el desarrollo y mantenimiento del software.
2. Aumentar la calidad del software.
3. Mejorar el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos.
4. Mejorar la planificación de un proyecto
5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.
6. Automatizar, desarrollo del software, documentación, generación de código, pruebas de errores y gestión del proyecto.
7. Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
8. Gestión global en todas las fases de desarrollo de software con una misma herramienta.
9. Facilitar el uso de las distintas metodologías propias de la ingeniería del software.
Clasificación
Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:
1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.
La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo que cubren:
• Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.
• Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación.
• Lower CASE (L-CASE), herramientas que semiautomatizan la generación de código, crean programas de detección de errores, soportan la depuración de programas y pruebas. Además automatizan la documentación completa de la aplicación. Aquí pueden incluirse las herramientas de Desarrollo_rápido_de_aplicaciones.
Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificación excluyente entre si, ni con la anterior:
• Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde análisis hasta implementación.
• Meta CASE?, herramientas que permiten la definición de nuestra propia técnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiéramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles.
• CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software.
• IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestión de proyectos y gestión de la configuración.
Por funcionalidad podríamos diferenciar algunas como:
• Herramientas de generación semiautomática de código.
• Editores UML.
• Herramientas de Refactorización de código.
• Herramientas de mantenimiento como los sistemas de control de versiones
5.2.1 Herramientas case estructuradas
Aparecieron a fines de los 60’s con la Programación Estructurada, posteriormente a
mediados de los 70’s extendidas con el Diseño Estructurado y a fines de los 70’s con el
Análisis Estructurado. Versiones más recientes incorporan Diagramas Entidad-Relación
y Diagramas de Transición de Estados.
Ejemplos de metodologías estructuradas impulsadas por organismos gubernamentales lo
constituyen: MERISE (Francia), METRICA (España), SSADM (Reino Unido).
Otras metodologías estructuradas en el ámbito académico y comercial son: Gane &
Sarson, Ward & Mellor, Yourdon & DeMarco y Information Engineering. Esta última
propuesta por James Martin pone un énfasis adicional en el modelado de datos y la
incorporación de los desarrollos informáticos dentro del contexto organizacional
(planificación, objetivos, etc.).
5.2.2 Herramientas case orientada a objetos
Su historia va unida a la evolución de los lenguajes de programación orientada a objeto,
los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80,
la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java. Sólo a
fines de los 80’s comenzaron a consolidarse algunas metodologías Orientadas a
Objetos.
Algunas de las más representativas en el ámbito comercial son: OMT de Rumbaugh,
OOAD de Grady Booch, OOSE de I.Jacobson, la propuesta por Peter Coad & Edward
Yourdon, la propuesta por S. Shaler & S.J. Mellor y la propuesta por J.Martin y
J.J.Odell. En los últimos años se ha realizado un esfuerzo de estandarización notacional
materializado en UML (Unified Modeling Language), el cual aglutina características de
algunas de las propuestas OO más conocidas. En 1997 UML fue aprobado como
notación estándar por el OMG.
5.3 Desarrollo de prototipos.
¿Qué es un Prototipo?
Es un modelo a escala o facsímil de lo real, pero no tan funcional para que equivalga a un productofinal, 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 Objetivo
Siempre 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 Prototipo
En 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 Prototipos
El 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 Prototipo
Reacciones Iniciales del Usuario
El profesional de Sistema por medio de la observación, evaluacióny 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.
3. Desarrollo de Prototipo
Problemas Candidatos
Para 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 naturalezadel 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 Prototipo
El desarrollo de un prototipo se lleva a cabo en forma ordenada a través de las siguientes etapas, Figura 1:
Identificación de Requerimientos Conocidos
El profesional de sistema identifica los requerimientos conocidos, generales, o características esenciales y determina el propósito del prototipo de la aplicación.
4. Estrategias para el Desarrollo de Prototipos
Se puede desarrollar un prototipo para cada uno de los componentes de la aplicación
Prototipos por Pantallas
La interface entre el sistema y el usuario es la pantalla de visualización, esta es el vehiculo para presentar la información tal como ésta es proporcionada al sistema o como es recuperada de éste.
Los prototipos de pantalla permite evaluar la posición de información sobre la pantalla, los encabezados, los botones, mensajes. Tambíen permite la reacción de los usuarios por la cantidad de información sobre la pantalla. La ceación de un prototipo de pantalla conduce a:
Que debe presentarse como información sobre la pantalla principal
Cuál pertence a una pantalla de detalle
Prototipos para Procedimientos de Procesamientos
Las 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.
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 iniciales 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 dificil: Dicha dificultad radica en manejar el prototipo como un proyecto dentro del Ciclo de Desarrollo de Sistema sin perder de vista cual era sus 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 imcompleto e inadecuado.
