Implementación de los Requerimientos en el nuevo sistema

Implementación de los Requerimientos en el nuevo sistema La importancia de especificar e implementar los requerimientos en el nuevo sistema está determinada por lo siguiente: 1. Los Errores: si hay alguno que se escinden sin percatarnos durante la fase de especificación de requerimientos, son difíciles de localizar, manejar y arreglar si se descubren durante las fases posteriores del desarrollo. Normalmente, los errores que se descubren más tarde en el ciclo de vida del proyecto de desarrollo de software, tendrán un costo más elevado para repararlos. 2. Entender los requerimientos es una fase crucial. Ya que cualquier error que se oculta en esta fase tiende a propagarse a otras fases como diseño y codificación. Aquí, estos errores tienden a sufrir transformaciones que hacen que descubrir la fuente original del error sea difícil. 3. La fase de requerimientos involucra muchas comunicaciones entre los involucrados con el sistema y los desarrolladores. Esta es la fase más propensa a que se introduzcan varios errores. 4. Se deben tomar las precauciones en la fase de requerimientos para asegurar de que las especificaciones están libres de hechos (aseveraciones) incorrectos, de omisión de detalles, inconsistencias y ambigüedades en los requerimientos. 5. Un aumento significativo de costo y tiempo en los proyectos de desarrollo de software pueden atribuirse a los errores e insuficiencias en la fase de análisis de requerimientos. Un sistema de software exhibe un comportamiento que puede ser visto por un observador externo, tal como un usuario. Este comportamiento externo es usualmente lo que caracteriza una funcionalidad específica del software. Es diferente del comportamiento interno que se observa, a través del uso de memoria durante la ejecución o el estado de variables usadas. Una vez que es capaz de generar el comportamiento externo completo del software a ser desarrollado, se puede decir que la fase de requerimientos para el nuevo software está cerca de su final. La descripción completa del comportamiento externo del software se documenta. Este especifica todas las interfaces entre el software y el entorno del software. El entorno del software consiste de computadoras, productos de hardware, productos de software y los usuarios humanos. Esta descripción completa se registra en una Especificación de Requerimientos de Software (SRS). Una (SRS) es un documento que contiene una descripción completa de lo que el software hará, sin describir cómo lo hará. Es muy importante entender que los requerimientos son una descripción completa de lo que el software hará, sin describir cómo lo hará. Una (SRS) es un documento que contiene una descripción completa del comportamiento externo de un producto de software y puede ser detallado o general. Esto depende de la naturaleza del software a ser desarrollado y también de la persona que escribe la (SRS). Estudio de Requerimientos Un estudio de requerimientos comienza con la comunicación entre el cliente y el ingeniero de requerimientos. La tarea del cliente es comunicar los requerimientos al ingeniero de requerimientos y la tarea del ingeniero de requerimientos es descubrir todos los requerimientos, estructurarlos y escribir la especificación de requerimientos después de entender las necesidades del cliente. Esta comunicación no es tan fácil como aparenta y se llena a menudo de problemas de varias clases. Los problemas en la comunicación pueden ocurrir si el dominio a ser explorado requiere experiencia para entenderlo, si el lenguaje de la comunicación tiene brechas, y si la efectividad de la comunicación es pobre, etc. Las siguientes son algunas de las actividades principales que deben ser parte del estudio de los requerimientos. Se observa que estas actividades no necesitan ser emprendidas en una manera secuencial.  Examinar el escenario.  Arreglar la primera cita o reunión con los clientes.  Procurar entender la misión de la organización.  Procurar familiarizarse con la estructura de la organización e identificar a los diversos involucrados con el sistema.  Utilizar la reunión para establecer credibilidad con los clientes y ganar su confianza.  Elaborar un documento preliminar que resuma los diferentes pasos en la operación del sistema actual describiendo claramente los límites del sistema, las entradas, las salidas y las interfaces del sistema.  Describir claramente los límites del sistema, las entradas, las salidas y las interfaces.  Desarrollar un documento que indique claramente el problema.  Recopilar todos los datos necesarios y relevantes de la organización.  Verificar la comprensión del problema revisando los documentos que se han preparado con los clientes.  Poner la disponibilidad de la gerencia el informe de evaluación del escenario.  Estudiar detalladamente el sistema existente.  Conducir las entrevistas con profundidad con los diferentes involucrados con el sistema para los aspectos específicos del sistema actual.  Desarrollar una clara comprensión del flujo de datos y la lógica operacional del sistema y de un conjunto preliminar de requerimientos basados en el estudio del sistema existente.  Desarrollar el documento de especificación de requerimientos del software (SRS) basado en los nuevos requerimientos.  La definición del problema y el estudio del sistema existente, establecen las bases para la enumeración del nuevo conjunto de requerimientos.  Especificar la funcionalidad del conjunto de requerimientos.  Especificar los requerimientos referentes al desempeño y restricciones. Fase de los requerimientos y creación de los prototipos. En la fase de los requerimientos, un prototipo puede ser construido y dado a un usuario o a un cliente potencial para trabajar con él, para hacer lo siguiente:  Determinar la viabilidad del requerimiento.  Validar que una función en particular es realmente necesaria.  Descubrir los requerimientos faltantes.  Determinar la viabilidad de una interfaz de usuario. Una vez que haya servido a los propósitos mencionados, el prototipo es usualmente desechado y por lo tanto se denomina prototipo desechable. Con el uso de un prototipo, los clientes podrán proporcionar requerimientos más enfocados. El equipo que está conduciendo el estudio de los requerimientos puede ahora proceder a terminar la Especificación de Requerimientos de Software (SRS). Determinación de los niveles de automatización Las herramientas automáticas de estimación permiten al planificador estimar costos y esfuerzos, así como llevar a cabo análisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la selección del personal. Aunque existen muchas herramientas automáticas de estimación, todas exhiben las mismas características generales y todas requieren de una o más clases de datos. A partir de estos datos, el modelo implementado por la herramienta automática de estimación proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duración, y en algunos casos la planificación temporal de desarrollo y riesgos asociados. En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo requerirá y cuanta gente estará implicada. Además el planificador debe predecir los recursos de hardware y software que va a requerir y el riesgo implicado. Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos de las tres técnicas referidas anteriormente. Mediante la comparación y la conciliación de las estimaciones obtenidas con las diferentes técnicas, el planificador puede obtener una estimación más exacta. La estimación del proyecto de software nunca será una ciencia exacta, pero la combinación de buenos datos históricos y técnicas puede mejorar la precisión de la estimación. Técnicas y Herramientas para la Recolección de datos La recolección de datos se refiere al uso de una gran diversidad de técnicas y herramientas que pueden ser utilizadas por el analista para desarrollar los sistemas de información, los cuales pueden ser la entrevistas, la encuesta, el cuestionario, la observación, el diagrama de flujo y el diccionario de datos. Todos estos instrumentos se aplicarán en un momento en particular, con la finalidad de buscar información que será útil a una investigación en común. En la presente investigación trata con detalle los pasos que se debe seguir en el proceso de recolección de datos, con las técnicas ya antes nombradas. TÉCNICAS PARA HALLAR DATOS Los analistas utilizan una variedad de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionarios, inspección de registros (revisión en el sitio) 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. LA ENTREVISTA Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán más adelante. Sin embargo, las entrevistas no siempre son la mejor fuente de datos de aplicación. Dentro de una organización, la entrevista es la técnica más significativa y productiva de que dispone el analista para recabar datos. En otras palabras, la entrevista es un intercambio de información que se efectúa cara a cara. Es un canal de comunicación entre el analista y la organización; sirve para obtener información acerca de las necesidades y la manera de satisfacerlas, así como concejo y comprensión por parte del usuario para toda idea o método nuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpatía con el personal usuario, lo cual es fundamental en transcurso del estudio. Preparación de la Entrevista 1. Determinar la posición que ocupa de la organización el futuro entrevistado, sus responsabilidades básicas, actividades, etc. (Investigación). 2. Preparar las preguntas que van a plantearse, y los documentos necesarios (Organización). 3. Fijar un límite de tiempo y preparar la agenda para la entrevista. (Psicología). 4. Elegir un lugar donde se puede conducir la entrevista con la mayor comodidad (Psicología). 5. Hacer la cita con la debida anticipación (Planeación). Conducción de la Entrevista 1. Explicar con toda amplitud el propósito y alcance del estudio (Honestidad). 2. Explicar la función propietaria como analista y la función que se espera conferir al entrevistado. (Imparcialidad). 3. Hacer preguntas específicas para obtener respuestas cuantitativas (Hechos). 4. Evitar las preguntas que exijan opiniones interesadas, subjetividad y actitudes similares (habilidad). 5. Evitar el cuchicheo y las frases carentes de sentido (Claridad). 6. Ser cortés y comedio, absteniéndose de emitir juicios de valores. (Objetividad). 7. Conservar el control de la entrevista, evitando las divagaciones y los comentarios al margen de la cuestión. 8. Escuchar atentamente lo que se dice, guardándose de anticiparse a las respuestas (Comunicación). Secuela de la Entrevista 1. Escribir los resultados (Documentación). 2. Entregar una copia al entrevistado, solicitando su conformación, correcciones o adiciones. (Profesionalismo). 3. Archivar los resultados de la entrevista para referencia y análisis posteriores (Documentación). Recabar datos mediante la Entrevista La entrevista es una forma de conversación, no de interrogación, al analizar las características de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre el sistema, los analistas pueden conocer datos que no están disponibles en ningún otra forma. En las investigaciones de sistema, las formas cualitativas y cuantitativas de las informaciones importantes. La información cualitativa está relacionada con opinión, política y descripciones narrativas de actividades o problemas, mientras que las descripciones cuantitativas tratan con números frecuencia, o cantidades. A menudo las entrevistas pueden ser la mejor fuente de información cualitativas, los otros métodos tiende a ser más útiles en la recabación de datos cuantitativos. Son valiosas las opiniones, comentarios, ideas o sugerencia en relación a como se podría hacer el trabajo; las entrevistas a veces es la mejor forma para conocer las actividades de las empresas. La entrevista pueden descubrir rápidamente malos entendidos, falsa expectativa o incluso resistencia potencial para las aplicaciones de desarrollo; más aún, a menudo es más fácil calendarizar una entrevista con los gerentes de alto nivel, que pedirle que llenen cuestionario. Determinación del tipo de Entrevista La estructura de la entrevista varía. Si el objetivo de la entrevista radica en adquirir información general, es conveniente elaborar una serie de pregunta sin estructura, con una sesión de preguntas y respuesta libres Las entrevistas estructuradas utilizan pregunta estandarizada. El formato de respuestas para las preguntas pueden ser abierto o cerrado; las preguntas para respuestas abierta permiten a los entrevistados dar cualquier respuesta que parezca apropiado. Pueden contestar por completo con sus propias palabras. Con las preguntas para respuesta cerradas se proporcionan al usuario un conjunto de respuesta que se pueda seleccionar. Todas las personas que respondes se basan en un mismo conjunto de posibles respuestas. Los analistas también deben dividir el tiempo entre desarrollar preguntas para entrevistas y analizar respuesta. La entrevista no estructurada no requiere menos tiempos de preparación, porque no necesita tener por anticipado las palabras precisas de las preguntas. Analizar las respuestas después de la entrevista lleva más tiempo que con la entrevista estructuradas. El mayor costo radica en la preparación, administración y análisis de las entrevistas estructuradas para pregunta cerradas. Ejemplos de las preguntas abiertas y cerradas en la entrevista estructurada FORMA DE PREGUNTA ABIERTA FORMA DE PREGUNTA CERRADA Ejemplo: obtener la información sobre las características de diseños críticas para los empleados. “algunos empleados han sugerido que la mejor forma para hacer eficiente el procesamiento de pedidos es instalar un sistema de computadora que maneje todos los cálculos..." Bajo estas circunstancias ¿apoyaría usted el desarrollo de un sistema de este tipo? Ejemplo: obtener la información sobre las Características de diseño críticas para los empleados. “La experiencia le ha proporcionado una amplia visión en cuanto a la forma en la que la empresa maneja los pedidos..." Me gustaría que usted contestara algunas preguntas específicas en relación en lo anterior: -¿Qué etapas trabajas bien?¿cuáles no -¿En donde se presenta la mayor parte del problema? - ¿Cuándo ocurre un atraso, cómo se maneja? Entre otros Selección de Entrevistados Realizar entrevistas toma tiempo; por lo tanto no es posible utilizar este método para recopilar toda la información que se necesite en la investigación; incluso el analista debe verificar los datos recopilados utilizando unos de los otros métodos de recabación de datos. La entrevista se aplican en todos los niveles gerencial y de empleados y dependa de quien pueda proporcionar la mayor parte de la información útil para el estudio los analistas que estudian la administración de inventarios pueden entrevistar a los trabajadores del embarque y de recepción, al personal de almacén y a los supervisores de los diferentes turnos, es decir. Aquellas personas que realmente trabajan en el almacén, también entrevistarán a los gerentes más importantes. Realización de Entrevista La habilidad del entrevistador es vital para el éxito en la búsqueda de hecho por medio de la entrevista. La buena entrevista depende 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, analista que trabaja en la aplicación enfocada a la reducción de errores (captado por la gerencia de alto nivel) probablemente no tendría éxito si llegara a una oficina de gerencia de nivel medio con la presentación equivocada, ejemplo "Estamos aquí para resolver su problema". A través de la entrevista, los analistas deben preguntarse a sí mismo las siguientes preguntas: o ¿Qué es lo que me está diciendo la persona? o ¿Por qué me lo está diciendo a mí? o ¿Qué está olvidando? o ¿Qué espera está persona que haga yo? Entrevista estructurada Entrevista no estructurada VENTAJAS -Asegura la elaboración uniforme de las preguntas para todos los que van a responder. -Fácil de administrar y evaluar. -Evaluación más objetiva tanto de quienes responden como de las respuestas a las preguntas. -Se necesita un limitado entrenamiento del entrevistador. -Resulta en entrevistas más pequeñas. -El entrevistador tiene mayor flexibilidad al realizar las preguntas adecuadas a quien responde. -El entrevistador puede explotar áreas que surgen espontáneamente durante la entrevista. -Puede producir información sobre área que se minimizaron o en las que no se pensó que fueran importantes. DESVENTAJAS -Alto costo de preparación. -Los que responden pueden no aceptar un alto nivel en la estructura y carácter mecánico de las preguntas. -Un alto nivel en la estructura puede no ser adecuado para todas las situaciones. -El alto nivel en las estructuras reduce responder en forma espontánea, así como la habilidad del entrevistador para continuar con comentarios hacia el entrevistado. -Puede utilizarse negativamente el tiempo, tanto de quien responde como del entrevistador. -Los entrevistadores pueden introducir sus sesgos en las preguntas o al informar de los resultados. -Puede recopilarse información extraña -El análisis y la interpretación de los resultados pueden ser largos. -Toma tiempo extra recabar los hechos esenciales. ¿Qué es una encuesta? Nuestra "sociedad", requiere un rápido y preciso flujo de información sobre las preferencias, necesidades y comportamiento de sus miembros. Es en respuesta a esta necesidad crítica de información por el gobierno, el comercio y las instituciones sociales que tanta confianza se pone en las encuestas. Hoy en día la palabra "encuesta" se usa más frecuentemente para describir un método de obtener información de una muestra de individuos. Esta "muestra" es usualmente sólo una fracción de la población bajo estudio. Por ejemplo, antes de una elección, una muestra de electores es interrogada para determinar cómo los candidatos y los asuntos son percibidos por el público… un fabricante hace una encuesta al mercado potencial antes de introducir un nuevo producto… una entidad del gobierno comisiona una encuesta para obtener información para evaluar legislación existente o para preparar y proponer nueva legislación. No tan sólo las encuestas tienen una gran variedad de propósitos, sino que también pueden conducirse de muchas maneras, incluyendo por teléfono, por correo o en persona. Aún así, todas las encuestas tienen algunas características en común. A diferencia de un censo, donde todos los miembros de la población son estudiados, las encuestas recogen información de una porción de la población de interés, dependiendo el tamaño de la muestra en el propósito del estudio. En una encuesta bona fide, la muestra no es seleccionada caprichosamente o sólo de personas que se ofrecen como voluntarios para participar. La muestra es seleccionada científicamente de manera que cada persona en la población tenga una oportunidad medible de ser seleccionada. De esta manera los resultados pueden ser proyectados con seguridad de la muestra a la población mayor. La información es recogida usando procedimientos estandarizados de manera que a cada individuo se le hacen las mismas preguntas en mas o menos la misma manera. La intención de la encuesta no es describir los individuos particulares quienes, por azar, son parte de la muestra sino obtener un perfil compuesto de la población. Una "encuesta" recoge información de una "muestra." Una "muestra" es usualmente sólo una porción de la población bajo estudio. El estándar de la industria para todas las organizaciones respetables que hacen encuestas es que los participantes individuales nunca puedan ser identificados al reportar los hallazgos. Todos los resultados de la encuesta deben presentarse en resúmenes completamente anónimos, tal como tablas y gráficas estadísticas. ¿Cuán grande debe ser la muestra? El tamaño de muestra requerido en una encuesta depende en parte de la calidad estadística necesaria para los establecer los hallazgos; esto a su vez, está relacionado en cómo esos hallazgos serán usados. Aún así, no hay una regla simple para el tamaño de muestra que pueda ser usada en todas las encuestas. Mucho de esto depende de los recursos profesionales y fiscales disponibles. Los analistas frecuentemente encuentran que una muestra de tamaño moderado es suficiente estadística y operacionalmente. ¿Cuáles son algunos métodos comunes de Encuestas? Las encuestas pueden ser clasificadas en muchas maneras. Una dimensión es por tamaño y tipo de muestra. Las encuestas pueden ser usadas para estudiar poblaciones humanas o no humanas (por ejemplo, objetos animados o inanimados, animales, terrenos, viviendas). Mientras que muchos de los principios son los mismos para todas las encuestas, el foco aquí será en métodos para hacer encuestas a individuos. Muchas encuestas estudian todas las personas que residen en un área definida, pero otras pueden enfocar en grupos particulares de la población -niños, médicos, líderes de la comunidad, los desempleados, o usuarios de un producto o servicio particular. Las encuestas también pueden ser conducidas con muestras locales, estatales o nacionales. Las encuestas pueden ser clasificadas por su método de recolección de datos. Las encuestas por correo, telefónicas y entrevistas en persona son las más comunes. En los métodos más nuevos de recoger datos, la información se entra directamente a la computadora ya sea por un entrevistador adiestrado o aún por la misma persona entrevistada. Un ejemplo bien conocido es la medición de audiencias de televisión usando aparatos conectados a una muestra de televisores que graban automáticamente los canales que se observan. Las encuestas son una fuente importante de conocimiento científico básico. Las encuestas por correo, a través de entrevistas telefónicas o en persona son las más comunes. Las encuestas por correo pueden ser de costo relativamente bajo. Como con cualquier otra encuesta, existen problemas en usar este método si no se presta suficiente atención a obtener niveles altos de cooperación. Estas encuestas pueden ser más efectivas cuando se dirigen a grupos particulares, tal como suscriptores a una revista especializada o a miembros de una organización profesional. Las entrevistas telefónicas son una forma eficiente de recoger ciertos tipos de datos y se están usando con cada vez mayor frecuencia. Se prestan particularmente bien a situaciones donde es necesario obtener resultados oportunos y cuando el largo de la encuesta es limitado. Las entrevistas en persona en el hogar u oficina de un participante son mucho más caras que las encuestas telefónicas o por correo. Estas pueden ser necesarias especialmente cuando se debe recoger información compleja. Algunas encuestas combinan varios métodos. Por ejemplo, una encuestadora puede usar el teléfono para identificar participantes elegibles (tal como localizar individuos mayores elegibles para Medicare) y luego hacer cita para una entrevista en persona. ¿Qué preguntas hacemos en una Encuesta? Podemos clasificar las encuestas también por su contenido. Algunas encuestas enfocan en las opiniones y actitudes (tal como las encuestas pre-eleccionarias), mientras que otras se preocupan por características o comportamiento reales (tal como la salud de las personas, vivienda, gastos del consumidor o hábitos de transportación). Muchas encuestas combinan preguntas de ambos tipos. Los participantes pueden ser preguntados si han oído ó leído sobre algún asunto… qué saben sobre él… su opinión… con cuanta firmeza sienten y por qué… su experiencia sobre el asunto… y ciertos datos personales que ayudará al analista a clasificar sus respuestas (tal como edad, género, estado civil, ocupación y lugar de residencia). Las preguntas pueden ser abiertas ("¿Por qué siente así?"), o cerradas ("¿Aprueba usted o desaprueba?"). Los entrevistadores pueden solicitar al participante que evalúe un candidato político o un producto usando alguna escala, o pueden solicitarle que ordene varias alternativas. Como los cambios en actitudes o comportamiento no pueden establecerse confiablemente con una sola entrevista, algunas encuestas usan un diseño de panel, en el cual los mismos participantes son entrevistados en dos ocasiones o más. Tales encuestas son usadas comúnmente durante una campaña electoral o para trazar la salud de una familia o su patrón de compras durante un período de tiempo. ¿Quién trabaja en las Encuestas? El trabajador de encuestas mas conocido por el público es el entrevistador que llama por teléfono, el que aparece en la puerta del hogar o el que detiene a personas en un centro comercial. Tradicionalmente, las entrevistas para encuestas, aunque requieren ocasionalmente largos días de trabajo en el campo, eran hechas principalmente por personas empleadas a tiempo parcial. Por lo tanto este tipo de empleo era particularmente adecuado para personas que no deseaban empleo a tiempo completo o que querían suplementar su ingreso regular. Cambios en el mercado de trabajo y en el nivel de automatización de las encuestas han comenzado a alterar este patrón -aumentando el número de encuestadores que buscan trabajar a tiempo completo. La experiencia no es usualmente requerida para un empleo de entrevistador, aunque las destrezas básicas en el uso de computadoras adquieren cada día más importancia. La mayoría de las organizaciones que hacen investigación proveen su propio adiestramiento para la labor del entrevistador. Los requisitos principales para entrevistar están la habilidad para acercarse a personas extrañas (en persona o por teléfono), para El trabajador de encuestas mejor conocido por el público es el entrevistador pero hay muchos otros. Persuadirles a participar y para recoger los datos necesarios siguiendo las instrucciones al pie de la letra. Menos visible, pero de igual importancia es el personal de la oficina, quienes -entre otras cosas- planifican la encuesta, seleccionan la muestra, supervisan las entrevistas, procesan los datos recogidos, analizan los datos e informan los hallazgos de la encuesta. En la mayoría de las organizaciones de investigación por encuestas, el personal gerencial habrá tomado cursos graduados de métodos de encuestas y poseen grados universitarios avanzados en estadísticas, sociología, psicología, mercadeo, alguna materia afín ó poseerán experiencia equivalente. Los supervisores de nivel intermedio y los asociados de investigación frecuentemente tendrán trasfondos académicos similares a los gerentes o habrán avanzado desde las filas de los entrevistadores, oficinistas o codificadores sobre la base de su competencia y experiencia. ¿Qué sobre la confidencialidad e integridad? La confidencialidad de los datos suministrados por los participantes es una preocupación primordial de todas las organizaciones respetables que hacen encuestas. Varias organizaciones profesionales que tienen que ver con métodos de encuestas tienen un código de ética (como la Asociación Estadística Americana) que establecen reglas para mantener la confidencialidad de las respuestas en encuestas. La política recomendada para que las organizaciones de encuestas salvaguarden la confidencialidad incluye: • Usar códigos numéricos para vincular al participante con su cuestionario y guardar la información sobre el vínculo nombre-código en un lugar aparte. • Negarse a proveer los nombres y direcciones de los participantes en la encuesta a cualquier persona fuera de la organización de encuestas, incluyendo a sus clientes. • Destruir cuestionarios e información que pueda servir para identificar los participantes luego que sus respuestas se hayan entrado a la computadora. • Omitir los nombres y direcciones de los participantes en la encuesta de los archivos de computadora usados para análisis. • Presentar tabulaciones estadísticas usando categorías amplias para que los participantes individuales no puedan ser identificados. La confidencialidad de los datos suministrados por los participantes es una preocupación primordial de todas las organizaciones de encuesta respetables. ¿Cuáles son nuestras preocupaciones potenciales? La calidad de una encuesta es determinada en gran medida por su propósito y por la forma en que es conducida. Las encuestas deben llevarse a cabo únicamente para obtener información estadística sobre algún tema. No deben ser diseñadas para producir resultados predeterminados o como un artificio para mercadeo o para actividades similares. Cualquier persona a quien se le solicite que responda a una encuesta de opinión o que se preocupe por los resultados debe primero decidir si las preguntas que se hacen son justas. Otra violación importante de la integridad ocurre cuando lo que parece ser una encuesta es efectivamente un vehículo para estimular donaciones a alguna causa o para crear una lista de direcciones para mercadear productos. Cuestionario Los cuestionarios proporcionan una alternativa muy útil para la entrevista; si embargo, existen ciertas características que pueden ser apropiada en algunas situaciones e inapropiadas en otra. Al igual que la entrevistas, deben diseñarse cuidadosamente para una máxima efectividad. Recabació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 en relación al sistema. En mayor parte de los casos, el analista no verá a los que responde; no obstante, también esto es una ventaja porque aplican muchas entrevista ayuda a asegurar que el interpelado cuenta con mayor anonimato y puedan darse respuestas mas honesta ( y menos respuestas prehechas o estereotipadas). También las preguntas estandarizadas pueden proporcionar datos más confiables. Selección de formas para cuestionarios El desarrollo y distribución de los cuestionarios; 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: cuestionarios abiertos y cerrados, y se aplican dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlas. Con frecuencia se utilizan ambas formas en los estudios de sistemas. Cuestionario Abierto 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, es un medio. El formato abierto proporciona una amplia oportunidad para quienes respondan escriba las razones de sus ideas. Algunas personas sin embargo, encuentran más fácil escoger una de un conjunto de respuestas preparadas que pensar por sí mismas. Cuestionario Cerrado 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 método para obtener información sobre los hechos. También fuerza a los individuos para que tomen una posición y forma su opinión sobre los aspectos importantes. La OBSERVACIÓN Otra técnica útil para el analista en su progreso de investigación, consiste en observar a las personas cuando efectúan su trabajo. Como técnica de investigación, la observación tiene amplia aceptación científica. Los sociólogos, sicólogos e ingenieros industriales utilizan extensamente ésta técnica con el fin de estudiar a las personas en sus actividades de grupo y como miembros de la organización. El propósito de la organización es múltiple: permite al analista determinar que se está haciendo, como se está haciendo, quien lo hace, cuando se lleva a cabo, cuanto tiempo toma, dónde se hace y por que se hace. "¡Ver es creer! Observar las operaciones la proporciona el analista hechos que no podría obtener de otra forma. Tipos de Observación El analista de sistemas puede observar de tres maneras básicas. Primero, puede observar a una persona o actitud sin que el observado se dé cuenta y su interacción por aparte del propio analista. Quizá esta alternativa tenga poca importancia para el análisis de sistemas, puesto que resulta casi imposible reunir las condiciones necesarias. Segundo, el analista puede observar una operación sin intervenir para nada, pero estando la persona observada enteramente consciente de la observación. Por último, puede observar y a la vez estar en contacto con las personas observas. La interacción puede consistir simplemente en preguntar respecto a una tarea específica, pedir una explicación, etc. Preparación para la observación 1. Determinar y definir aquella que va a observarse. 2. Estimular el tiempo necesario de observación. 3. Obtener la autorización de la gerencia para llevar a cabo la observación. 4. Explicar a las personas que van a ser observadas lo que se va a hacer y las razones para ello. Conducción de la observación 1. Familiarizarse con los componentes físicos del área inmediata de observación. 2. Mientras se observa, medir el tiempo en forma periódica. 3. Anotar lo que se observa lo más específicamente posible, evitando las generalidades y las descripciones vagas. 4. Si se está en contacto con las personas observadas, es necesario abstenerse de hacer comentarios cualitativos o que impliquen un juicio de valores. 5. Observar las reglas de cortesía y seguridad. Secuela de la observación 1. Documentar y organizar formalmente las notas, impresionistas, etc. 2. Revisar los resultados y conclusiones junto con la persona observada, el supervisar inmediato y posiblemente otro de sistemas. Diagrama de Flujo Es una representación pictórica de los pasos en proceso. Útil para determinar cómo funciona realmente el proceso para producir un resultado. El resultado puede ser un producto, un servicio, información o una combinación de los tres. Al examinar cómo los diferentes pasos es un proceso se relacionan entre sí, se puede descubrir con frecuencia las fuentes de problemas potenciales. Los diagramas de flujo se pueden aplicar a cualquier aspecto del proceso desde el flujo de materiales hasta los pasos para hacer la venta u ofrecer un producto. Con frecuencia este nivel de detalle no es necesario, pero cuando se necesita, el equipo completo de trabajo más pequeño puede agregar niveles según sea necesario durante el proyecto. ¿Cuándo se utiliza un Diagrama De Flujo? Cuando un equipo necesita ver cómo funciona realmente un proceso completo. Este esfuerzo con frecuencia revela problemas potenciales tales como cuellos de botella en el sistema, pasos innecesarios y círculos de duplicación de trabajo. Algunas aplicaciones comunes son: Definición de Proyectos: • Identificar oportunidades de cambios en el proceso. • Desarrollar estimados de costos de mala calidad. • Identificar organizaciones que deben estar representadas en el equipo. • Desarrollar una base común de conocimiento para los nuevos miembros del equipo. • Involucrar a trabajadores en los esfuerzos de resolución de problemas para reducir las resistencias futuras al cambio. Identificación de las causas principales: • Desarrollar planes para reunir datos. • Generar teorías sobre las causas principales. • Discutir las formas de estratificar los datos para el análisis para identificar las causas principales. • Examinar el tiempo requerido para las diferentes vías del proceso. Diseño de soluciones • Describir los cambios potenciales en el proceso y sus efectos potenciales. • Identificar las organizaciones que será afectadas por los cambios propuestos. Aplicaciones de soluciones: • Explicar otros el proceso actual y la solución propuesta. • Superar la resistencia al cambio demostrando cómo los cambios propuestos simplificarán el proceso. Control (retener las Ganancias): • Revisar y establecer controles y monotonías al proceso. • Auditar el proceso periódicamente para asegurar que están siguiendo los nuevos procedimientos. • Entrenar a nuevos empleados. ¿Cómo se Utiliza? La metodología para prepara un Diagrama de Flujo es; 1. PROPÓSITO: analizar como se pretende utilizar el Diagrama de Flujo. Exhibir esta hoja en el pared y consultarla en cualquier momento para verificar que se Diagrama de Flujo es apropiado para las aplicaciones que se pretende. 2. DETERMINAR EL NIVEL DE DETALLE REQUERIDO. 3. DEFINIR LOS LIMITES: después de establecer los límites del proceso, enumerar los resultados y los clientes en el extremo derecho del diagrama. 4. UTILIZAR SÍMBOLOS APROPIADOS: utilizando los símbolos apropiados para el Diagrama de Flujo, presentar las respuestas como los primeros pasos en el diagrama. 5. HACER PREGUNTAS: para cada input, haga preguntas como: o ¿Quién recibe el input? o ¿Qué es lo primero que se hace con el input? 1. DOCUMENTAR: cada paso en la secuencia, empezando con el primer (ó último) paso. Para cada paso, hacer preguntas como: o ¿Qué produce este paso? o ¿Quién recibe este resultado? o ¿Qué pasa después? o ¿Alguno de los pasos requiere de inputs que actualmente no se muestran? 1. COMPLETAR: continuar la construcción del Diagrama de Flujo hasta que se conecte todos los resultados (outputs) definidos en el extremo derecho del diagrama. Si se encuentra un segmento del proceso que es extraña para todos en el salón, se deberá tomar nota y continuar haciendo el diagrama. 2. REVISIÓN: Preguntar: o ¿Todos los flujos de información encajan en los inputs y outputs del proceso? o ¿El Diagrama muestra la naturaleza serial y paralela de los pasos? o ¿El Diagrama capta de forma exacta lo que realmente ocurrió, a diferencia de la forma cómo se piensa que las cosas deberías pasar o como fueron diseñadas originalmente? o DETERMINAR OPORTUNIDADES Nota: El Diagrama de flujo final deberá actuar como un registro de cómo el proceso actual realmente opera. Indicar la fecha. Aunque hay literalmente docenas de símbolos especializados utilizados para hacer Diagrama de Flujos, se utiliza con más frecuencia los siguientes: Las "líneas de flujos" son utilizadas para representar el progreso de los pasos en la secuencia. La punta de la fecha indica la dirección del flujo del proceso. Otros dos símbolos que no son utilizados tan comúnmente y que pueden ser útiles son: El "Símbolo del documento" representa la información escrita pertinente al proceso. El "Símbolo de la Base de Datos" representa información almacenada electrónicamente con respecto al proceso Consejos para la construcción / Interpretación: Si un Diagrama de Flujo se construye de forma apropiada y refleja el proceso de la forma que realmente opera, todos los miembros del equipo poseerán un conocimiento común, exacto del funcionamiento del proceso. Adicionalmente, el equipo no necesita invertir el tiempo y la energía en observar el proceso físicamente cada vez que se quiera identificar problemas para trabajar, discutir teorías sobre las causas principales, examinar el impacto de las soluciones propuestas o discutir las formas para mantener las mejoras. Los Diagramas de Flujo pueden ayudar a un equipo en su tarea de diagnóstico para lograr mejoras. Uno de sus usos es el de ayudar a un equipo a generar teorías sobre las posibles causas principales de un problema. El Diagrama de Flujo se dibuja en una pared de la sala de reuniones. El equipo que investiga un problema redacta una descripción del problema en un pedazo pequeño del papel y lo pega en el Diagramas de Flujo en el punto, en el proceso donde el problema se ha detectado. El equipo luego discute cada uno de los pasos en el proceso antes del punto donde el problema se ha detectado, y produce teorías sobre las cosas que podrían salir mal en el paso del proceso de forma sistemática a medida que producen teorías sobre las posibles causas principales del problema. Otro uso de un Diagramas de Flujo es el de ayudar a un equipo a identificar las formas apropiadas para separar los datos para su análisis. Por ejemplo, considérese el problema de analizar los tiempos de reparación. Una rápida revisión de los Diagramas de Flujo puede sugerir un número de grupos posibles que pueden explicar el tiempo que se necesita para hacer reparación. Relación con otras herramientas: Los Diagramas de Flujo de procesos generalmente se relacionan con: • Mapa de Relaciones • Mapa de Proceso Interfuncional (Cross-Funcional) Diccionario de datos Los diccionarios de datos son el segundo componente del análisis del flujo de datos. En sí mismos los diagramas de flujo de datos no describen por completo el objeto de la investigación. El diccionario de datos proporciona información adicional sobre el sistema. Esta sección analiza que es un diccionario de datos, por qué se necesita en el análisis de flujo de datos y como desarrollarlo. Se utilizará el ejemplo del sistema de contabilidad para describir los diccionarios de datos. Un diccionario de datos es una lista de todos los elementos incluido en el conjunto de los diagramas de flujo de datos que describen un sistema. Los elementos principales en un sistema, estudiados en las secciones anteriores, son el flujo de datos, el almacenamiento de datos y los procesos. El diccionario de datos almacena detalles y descripciones de estos elementos. Si los analistas desean conocer cuántos caracteres hay en un dato, con qué otros nombres se le conocen en el sistema, o en donde se utilizan dentro del sistema deben ser capaces de encontrar las respuestas en un diccionario de datos desarrollado apropiadamente. El diccionario de dato se desarrolla durante el análisis de flujo de datos y ayuda el analista involucrado en la determinación de los requerimientos de sistemas. Sin embargo, como se verá más adelante, también el contenido del diccionario de datos se utiliza durante el diseño del sistema. En informática, base de datos acerca de la terminología que se utilizará en un sistema de información. Para comprender mejor el significado de un diccionario de datos, puede considerarse su contenido como "datos acerca de los datos"; es decir, descripciones de todos los demás objetos (archivos, programas, informes, sinónimos...) existentes en el sistema. Un diccionario de datos almacena la totalidad de los diversos esquemas y especificaciones de archivos, así como sus ubicaciones. Si es completo incluye también información acerca de qué programas utilizan qué datos, y qué usuarios están interesados en unos u otros informes. Por lo general, el diccionario de datos está integrado en el sistema de información que describe. Descripción de los Datos en el Diccionario Cada entrada en el diccionario de dato consiste en un conjunto de detalles que describen los datos utilizados o producidos en el sistema. Cada artículo se identifica por un nombre de dato, descripción, sinónimo y longitud de campo y tiene valores específicos que se permiten para éste en el sistema estudiado. Nombre de los Datos Para distinguir un dato de otro, el analista les asigna nombre significativos que se utilizan para tener una referencia de cada elemento a través del proceso total de desarrollo de sistemas. Por lo tanto, debe tenerse cuidado para seleccionar, en forma significativa y entendible, los nombres de los datos, por ejemplo la fecha de factura es más significativa si se llama FECHA FACTURA que si se le conoce como ABCXXX. Descripción de los Datos Establece brevemente lo que representa el dato en el sistema; por ejemplo, la descripción para FECHA-DE-FACTURA indica que es la fecha en la cual se está preparando la misma (para distinguirla de la fecha en la que se envió por correo o se recibió. Las descripciones de datos se deben escribir suponiendo que a gente que los lea no conoce nada en relación del sistema. Deben evitarse termino especiales o argot, todas las palabras deben se entendible para el lector Alias Con frecuencia el mismo dato puede conocerse con diferentes nombres, dependiendo de quien lo utilice. El uso de los alias debe evitar confusión. Un diccionario de dato significativo incluirá todos los alias. Longitud de campo Cuando las características del diseño del sistema se ejecuten más tarde en el proceso de desarrollo de los sistemas, será importante conocer la cantidad de espacio que necesita para cada dato. Valores de los datos En algunos procesos solo se permiten valores de datos específicos. Por ejemplo, en muchas compañías con frecuencia los números de orden de compra se proporcionan con un prefijo de una letra para indicar el departamento del origen. Registro de las descripciones de datos Dadas que las descripciones se utilizarán en forma repetitiva a través de una información y después, durante el diseño, se sugiere un formato fácil para utilizar que simplifique el registro y los detalles de consulta cuando se necesiten. 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. 1.9.1 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. 1.9.2 ENCUESTA, CUESTIONARIO Y ENTREVISTA *Entrevista: esta herramienta consiste básicamente en reunirse una o varias personas y cuestionarlas en forma adecuada para obtener información. *Cuestionario: están constituidos por series de preguntas escritas, predefinidas, secuenciadas y separadas por capítulos o temática específica. *Encuesta: la recolección de información se hace a través de formularios, los cuales tienen aplicación en aquellos problemas que se pueden investigar por métodos de observación, análisis de fuentes documentales y demás sistemas de conocimiento. 1.10 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. 1.11 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. La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas. La razón principal para escoger este tema se fundamentó en la gran cantidad de proyectos de software que no llegan a cumplir sus objetivos. En nuestro país somos partícipes de este problema a diario, en donde se ha vuelto común la compra de sistemas extranjeros, para luego "personalizarlos" supuestamente a la medida de las empresas. Tal "personalización", la mayoría de las veces, termina retrasando el proyecto en meses, o incluso en años. La problemática del año 2000 trajo como consecuencia una serie de cambios apresurados en los sistemas existentes; cambios que, desde mi punto de vista, no fueron bien planificados. El reemplazo de plataformas y tecnologías obsoletas, la compra de sistemas completamente nuevos, las modificaciones de todos o de casi todos los programas que forman un sistema, entre otras razones, llevan a desarrollar proyectos en calendarios sumamente ajustados y en algunos casos irreales; esto ocasiona que se omitan muchos pasos importantes en el ciclo de vida de desarrollo, entre estos, la definición de los requerimientos. Estudios realizados muestran que más del 53% de los proyectos de software fracasan por no realizar un estudio previo de requisitos. Otros factores como falta de participación del usuario, requerimientos incompletos y el cambio a los requerimientos, también ocupan sitiales altos en los motivos de fracasos. Con este trabajo se pretende alcanzar los siguientes objetivos: • Resaltar la importancia que tiene la Ingeniería de Requerimientos dentro del ciclo de desarrollo. • Dar a conocer las diferentes alternativas que existen para identificar requerimientos. • Ayudar a comprender la diferencia que existe entre las diferentes técnicas utilizadas en la IR. • Minimizar las dudas que se tiene sobre los casos de uso. • Mostrar la utilización de herramientas CASE dentro de la administración de requisitos ¿Qué son Requerimientos? Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE . (1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2). Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc. Características de los requerimientos Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes. Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas. Dificultades para definir los requerimientos • Los requerimientos no son obvios y vienen de muchas fuentes. • Son difíciles de expresar en palabras (el lenguaje es ambiguo). • Existen muchos tipos de requerimientos y diferentes niveles de detalle. • La cantidad de requerimientos en un proyecto puede ser difícil de manejar. • Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros. • Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. • Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas. • Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. • Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto. Ingeniería de Requerimientos vs. Administración de Requerimientos El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa. A continuación se darán algunas definiciones para ingeniería de requerimientos. "Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema" Boehm 1979. "Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987. "Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987. "Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software Importancia de la Ingeniería de Requerimientos Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son: • Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. • Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios. • Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE. • Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.). • Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso. • Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto. Personal involucrado en la Ingeniería de Requerimientos Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan roles específicos dentro de la planificación del proyecto; el conocimiento de cada papel desempeñado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR. No conocer estos intereses puede ocasionar una comunicación poco efectiva entre clientes y desarrolladores, que a la vez traería impactos negativos tanto en tiempo como en presupuesto. Los roles más importantes pueden clasificarse como sigue: • Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; están familiarizados con los procesos específicos que debe realizar el software, dentro de los parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los manuales de usuario. • Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado. Ellos proporcionan al equipo técnico los detalles y requerimientos de las interfaces del sistema. • Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, éstas personas son las responsables de la administración de cambios, de la implementación y resolución de anomalías. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado. • Analistas y programadores: Son los responsables del desarrollo del producto en sí; ellos interactúan directamente con el cliente. • Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente. Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseñadores de base de datos, entre otros. Puntos a considerar durante la Ingeniería de Requerimientos Aunque la lista no está completa, se enumeran los puntos más importantes. Objetivos del negocio y ambiente de trabajo Aunque los objetivos del negocio están definidos frecuentemente en términos generales, son usados para descomponer el trabajo en tareas específicas. En ciertas situaciones IR se enfoca en la descripción de las tareas y en el análisis de sistemas similares. Esta información proporciona la base para especificar el sistema que será construido; aunque frecuentemente se añadan al sistema tareas que no encajan con el ambiente de trabajo planificado. El nuevo sistema cambiará el ambiente de trabajo, sin embargo, es muy difícil anticipar los efectos actuales sobre la organización. Los cambios no ocurren solamente cuando un nuevo software es implementado y puesto en producción; también ocurren cuando cambia el ambiente que lo rodea (nuevas soluciones a problemas, nuevo equipo para instalar, etc.). La necesidad de cambio es sustentada por el enorme costo de mantenimiento; aunque existen diversas razones que dificultan el mantenimiento del software, la falta de atención a la IR es la principal. Frecuentemente la especificación inicial es también la especificación final, lo que obstaculiza la comunicación y el proceso de aprendizaje de las personas involucradas; esta es una de las razones por las cuales existen sistemas inadecuados. Punto de vista de los clientes Muchos sistemas tienen diferentes tipos de clientes. Cada grupo de clientes tiene necesidades diferentes y, diferentes requerimientos tienen diferentes grados de importancia para ellos. Por otro lado, escasas veces tenemos que los clientes son los mismos usuarios; trayendo como consecuencia que los clientes soliciten procesos que causan conflictos con los solicitados por el usuario. Diferentes puntos de vistas también pueden tener consecuencias negativas, tales como datos redundantes, inconsistentes y ambiguos. El tamaño y complejidad de los requerimientos ocasiona desentendimiento, dificultad para enfocarse en un solo aspecto a la vez y dificultad para visualizar relaciones existentes entre requerimientos. • Barreras de comunicación La ingeniería de requerimientos depende de una intensa comunicación entre clientes y analistas de requerimientos; sin embargo, existen problemas que no pueden ser resueltos mediante la comunicación. Para remediar esto, se deben abordar nuevas técnicas operacionales que ayuden a superar estas barreras y así ganar experiencia dentro del marco del sistema propuesto. • Evolución e integración del sistema Pocos sistemas son construidos desde cero. En la práctica, los proyectos se derivan de sistemas ya existentes. Por lo tanto, los analistas de requerimientos deben comprender esos sistemas, que por lo general son una integración de componentes de varios proveedores. Para encontrar una solución a problemas de este tipo, es muy importante hacer planeamientos entre los requerimientos y la fase de diseño; esto minimizará la cantidad de fallas directas en el código. • Documentación de requerimientos Los documentos de ingeniería de requerimientos son largos. La mayoría están compuestos de cientos o miles de páginas; cada página contiene muchos detalles que pueden tener efectos profundos en el resto del sistema. Normalmente, las personas se encuentran con dificultades para comprender documentos de este tamaño, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de especificación de gran tamaño, pues difícilmente una persona puede memorizar los detalles del documento. Esto causa problemas y errores que no son detectados hasta después de haberse construido el sistema. Actividades de la Ingeniería de Requerimientos En el proceso de IR son esenciales diversas actividades. En este documento serán presentadas secuencialmente, sin embargo, en un proceso de ingeniería de requerimientos efectivo, estas actividades son aplicadas de manera continua y en orden variado. Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo, las actividades de la IR varían tanto en número como en nombres. La tabla #1 muestra algunos ejemplos de las actividades identificadas para cada proceso. A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades mostradas en la tabla anterior, podemos identificar y extraer cinco actividades principales que son: • Análisis del Problema • Evaluación y Negociación • Especificación • Validación • Evolución Análisis del Problema El objetivo de esta actividad es entender las verdaderas necesidades del negocio. Antes de describir qué pasos deben cumplirse en esta actividad, debemos tener una definición clara del término "Problema" . "Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean”. Aquí vemos nuevamente la importancia que tiene una buena comunicación entre desarrolladores y clientes; de esta comunicación con el cliente depende que entendamos sus necesidades. A través de la definición de problema, podemos ver entonces que la actividad de "Análisis del Problema" tiene por objetivo que se comprendan los problemas del negocio, se evalúen las necesidades iniciales de todos los involucrados en el proyecto y que se proponga una solución de alto nivel para resolverlo. Durante el análisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio. Estos pasos son los siguientes Comprender el problema que se está resolviendo: Es importante determinar quién tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista. Veamos la siguiente necesidad: "El cliente se queja mucho por la enorme fila que debe formar para realizar una transacción bancaria". Perspectiva del cliente = Pérdida de tiempo Perspectiva del banco = Posibles pérdidas de clientes Posibles soluciones pueden ser, determinar por qué demoran los cajeros, colocar una nueva caja (implica contratación de nuevos cajeros), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado), realizar transacciones por otros medios (teléfono, internet, mediante cajeros automáticos, autobancos, etc). Como puede verse, múltiples soluciones aplican para el mismo problema, sin embargo, sólo una de ellas será la más factible. Las soluciones iniciales, deben ser definidas tomando en cuanta tanto la perspectiva técnica como la del negocio. Construir un vocabulario común: Debe confeccionarse un glosario en dónde se definan todos los términos que tengan significados comunes (sinónimos) y que serán utilizados durante el proyecto. Por ejemplo, las palabras pignoración, retención, valor en suspenso, custodia, garantía, entre otras, son utilizadas para referirse a la acción de dejar una prenda (puede ser cualquier forma de ahorros) como garantía de una deuda adquirida. La creación de un glosario es sumamente beneficiosa ya que reduce los términos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunión están en la misma página, además de ser reutilizable en otros proyectos. Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas a medida que avanza el proyecto. Las necesidades de cada afectado, son discutidas y sometidas a debate durante de ingeniería de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la información necesaria para especificar un sistema adecuado. Definir los límites y restricciones del sistema: Este punto es importante pues debemos saber lo que se está construyendo, y lo que no se está construyendo, para así entender la estrategia del producto a corto y largo plazo. Debe determinarse cualquier restricción ambiental, presupuestaria, de tiempo, técnica y de factibilidad que limite el sistema que se va a construir. Evaluación y negociación de los requerimientos La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una evaluación de los mismos antes de definir si son adecuados para el cliente. El término "adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades técnicas y económicas, a la vez que se buscan resultados completos, correctos y sin ambigüedades. En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstracción y descomposición de cada problema presentado. Los principales pasos de esta actividad son: Descubrir problemas potenciales: En este paso se asegura que todas las características descritas en el punto 1.1 estén presentes en cada uno de los requerimientos, es decir, se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes, etc. Clasificar los requerimientos: En este paso se busca identificar la importancia que tiene un requerimiento en términos de implementación. A esta característica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirán las actividades de diseño y prueba de cada requisito. La prioridad de cada requerimiento dependerá de las necesidades que tenga el negocio. En base a la prioridad, cada requerimiento puede ser clasificados como mandatorio, deseables o innecesarios. Un requerimiento es mandatorio si afecta una operación crítica del negocio. Si existe algún proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un requerimiento deseable; y si se trata de un requerimiento informativo o que puede esperar para fases posteriores, el requerimiento es catalogado como innecesario. Una vez hecha esta categorización de los requerimientos, puedo tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusión de un requerimiento, también debe analizarse su costo, complejidad, y una cantidad de otros factores. Por ejemplo, si un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por más que éste sea sólo deseable. Evaluar factibilidades y riesgos: Involucra la evaluación de factibilidades técnicas (¿pueden implementarse los requerimientos con la tecnología actual?); factibilidades operacionales (¿puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades económicas (¿ha sido aprobado por los clientes el presupuesto?). En la actividad de evaluación y negociación, se incrementa la comunicación entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos: • Documentar todos los requerimientos a un nivel de detalle apropiado. • Mostrar todos los requerimientos a los involucrados en el sistema. • Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos. • Establecer las relaciones entre requerimientos que indiquen dependencias. • Negociar con flexibilidad para que exista un beneficio mutuo. • Enfocarse en intereses y no en posiciones. Especificación de Requisitos de Software (SRS) La especificación de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripción completa de las necesidades y funcionalidades del sistema que será desarrollado; describe el alcance del sistema y la forma en como hará sus funciones, definiendo los requerimientos funcionales y los no funcionales. En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra información que sirva de soporte y guía para fases posteriores. Es importante destacar que la especificación de requisitos es el resultado final de las actividades de análisis y evaluación de requerimientos; este documento resultante será utilizado como fuente básica de comunicación entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementación del sistema. Los clientes y usuarios utilizan la SRS para comparar si lo que se está proponiendo, coincide con las necesidades de la empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El personal de pruebas elaborará las pruebas funcionales y de sistemas en base a este documento. Para el administrador del proyecto sirve como referencia y control de la evolución del sistema. La SRS posee las mismas características de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada característica de la SRS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere verificable, cada requerimiento definido en ella debe ser verificable; para que una SRS se considere modificable, cada requerimiento debe ser modificable y así sucesivamente. Las características de la SRS son verificadas en la actividad de Validación, descrita en el punto 3.4. La estandarización de la SRS es fundamental pues ayudará, entre otras cosas, a facilitar la lectura y escritura de la misma. Será un documento familiar para todos los involucrados, además de asegurar que se cubren todos los tópicos importantes. Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia plantilla. En el anexo #1 se muestra una plantilla completa para la especificación de requisitos. Validación de Requisitos La validación es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; además revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes. En este punto es necesario recordar que la SRS debe estar libre de errores, por lo tanto, la validación garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad. No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos. La evaluación verifica las propiedades de cada requerimiento, mientras que la validación revisa el cumplimiento de las características de la especificación de requisitos. Evolución de los requerimientos Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cómo los objetivos de la organización pueden cambiar, por lo tanto, Es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolución es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto. Los requerimientos cambian por diferentes razones. Las más frecuentes son: • Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas. • Porque cambió el problema que se estaba resolviendo. • Porque los usuarios cambiaron su forma de pensar o sus percepciones. • Porque cambió el ambiente de negocios. • Porque cambió el mercado en el cual se desenvuelve el negocio. Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una característica en particular, modificación que a la vez puede tener impacto en otros requerimientos. Por esto, la administración de cambios involucra actividades como establecer políticas, guardar históricos de cada requerimiento, identificar dependencias entre ellos y mantener un control de versiones. Tener versiones de los requerimientos es tan importante como tener versiones del código, ya que evita tener requerimientos emparchados en un proyecto Entre algunos de los beneficios que proporciona el control de versiones están: • Prevenir cambios no autorizados. • Guardar revisiones de los documentos de requerimientos. • Recuperar versiones previas de los documentos. • Administrar una estrategia de "releases". • Prevenir la modificación simultánea a los requisitos. En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos. BIBLIOGRAFIA Guía de Ingeniería de Software de IBM, Libro Nº 1, Ingeniería De software, IBM Corpration, Inc. Año 2006