Técnica de relevamiento de datos Clase 07 http://computacion.cs.cinvestav.mx/~sperez/cursos/fis/Modelos.pdf https://prezi.com/gtglptv-v8lg/modelos-de-la-ingenieria-de-software/

TECNICAS PARA ENCONTRAR HECHOS

TECNICAS PARA ENCONTRAR HECHOS Entrevista Cuestionario Revisión de los registros Observación

ENTREVISTAS

ENTREVISTAS Reúne información proveniente de personas o de grupos Aunque algunos analistas prefieren la entrevista sobre otras técnicas, esta no siempre es la mejor fuente de datos sobre la aplicación. Este método puede ser de especial utilidad para reunir información de personas informales o que disponen de poco tiempo para llenar cuestionario

ENTREVISTAS Permite descubrir áreas mal comprendidas, expectativas poco realistas indicadores de resistencia hacia el sistema propuesto Es la mejor fuente de información cualitativa opiniones políticas descripciones subjetivas de actividades y problemas Puede clasificarse como Estructurada No estructurada

Tipos Entrevistas Estructuradas Entrevistas no estructuradas Utiliza preguntas estándar para todos Asegura términos uniformes de todos los entrevistados Fácil administrar y evaluar Disminuye la espontaneidad Entrevistas no estructuradas Formato pregunta-respuesta flexibles Apropiado para adquirir informaciones generales Anima a compartir sentimientos, ideas y creencias. El entrevistador puede introducir su punto de vista en las preguntas Uso ineficiente del tiempo

CUESTIONARIOS

CUESTIONARIOS El empleo de formatos estandarizados para las preguntas puede proporcionar datos mas confiables que otras técnicas Su amplia distribución asegura el anonimato, situación que conduce a respuestas mas honestas No permite observar las expresiones o reacciones del encuestado La respuesta puede ser muy limitada Posee costos de desarrollo y distribución Se utiliza cuestionario abierto para descubrir sentimientos, opiniones y experiencias generales

REVISION DE LOS REGISTROS

REVISION DE LOS REGISTROS Registros y reportes pueden proporcionar información valiosa con respecto a las organizaciones y a sus operaciones Incluyen revisiones de manuales de políticas, reglamentos y procedimientos estándares de operación

OBSERVACION

OBSERVACION Permite al analista ganar información que no se puede obtener por otras técnicas Información de primera mano sobre la forma que se efectúan las actividades Cuando se desea saber como se maneja los documentos

APRENDIENDO A ESCUCHAR “ Buena parte del éxito que usted obtenga como analista de sistemas depende de su capacidad para escuchar, para poner atención en lo que le dicen los usuarios, aun si ellos no expresan sus ideas con muchas palabras. Si no se obtienen requerimientos entonces es imposible satisfacerlos durante el diseño. Escuchar es una habilidad que debe desarrollarse ” James A. Senn

APRENDIENDO A ESCUCHAR Escoger un sitio tranquilo Tomar la iniciativa Cierre la puerta, adecue la iluminación,etc. Estar Preparado Aprenda la jerga de la especialidad que esta investigando. La incertidumbre crea dudas Evitar el uso de la jerga de los sistemas de información

Hallazgo de hechos: un reto y una oportunidad “ ...dar la consideración apropiada para desarrollar entrevistas, formular cuestionarios y conducir el estudio es un trabajo, un trabajo desafiante. No hay duda Por otro lado, obtener información ofrece al analista la oportunidad de ir mas allá del escenario de una organización ‘aprender la historia interna’, es descubrir como trabajan las cosas en la realidad en una nueva área de la información. James A. Senn

Especificación de Requisitos de Software (ERS)

Especificación de requisitos Es una descripción completa del comportamiento del sistema a desarrollar Incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software.

Especificación de requisitos Son las necesidades del producto que se debe desarrollar. En la fase de análisis de requisitos se deben identificar claramente estas necesidades y documentarlas. Como resultado de esta fase se debe producir un documento de especificación de requisitos en el que se describa lo que el futuro sistema debe hacer

Objetivos de la ERS. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado software. Ayudar a los desarrolladores a entender qué quiere exactamente el cliente. Servir de base para desarrollos de estándares de ERS particulares para cada organización.

Características de una buena ERS. Correcta. No ambigua. Completa. Verificable. Consistente Clasificada. Modificable. Explorable. Utilizable durante las tareas de mantenimiento y uso.

Ejemplo de Verificabilidad. No verificables: El producto debería funcionar bien. El producto debería tener una buena interfaz de usuario. Verificable: La salida se suministra dentro de los 20 segundos siguientes al evento E el 60% de las veces, y en los 30 segundos siguientes en el 100%

Clasificación de los requisitos Requisitos Funcionales (RF): Son los requisitos que tienen relación con la funcionalidad que envuelven aspectos de ejecución de negocio del producto de software y que tengan relación con operaciones de pantallas o informes del producto de software.

Clasificación de los requisitos Requisitos No-Funcionales (RN): En este tipo de requisitos son considerados las premisas o restricciones del sistema. 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.

Esquema de la ERS definida en el IEEE 830-1998. 1 Introducción 1.1 Propósito 1.2 Ámbito del Sistema 1.3 Definiciones, Acrónimos y Abreviaturas 1.4 Referencias 1.5 Visión general del documento 2 Descripción General 2.1 Perspectiva del Producto 2.2 Funciones del Producto 2.3 Características de los usuarios 2.4 Restricciones 2.5 Suposiciones y Dependencias 2.6 Requisitos Futuros 3 Requisitos Específicos 3.1 Interfaces Externas 3.2 Funciones 3.3 Requisitos de Rendimiento 3.4 Restricciones de Diseño 3.5 Atributos del Sistema 3.6 Otros Requisitos 4 Apéndices 5 Índice