Aci491 ingenier a de software
This presentation is the property of its rightful owner.
Sponsored Links
1 / 50

ACI491: Ingeniería de Software PowerPoint PPT Presentation


  • 78 Views
  • Uploaded on
  • Presentation posted in: General

ACI491: Ingeniería de Software. Unidad 3: Proceso de Identificación de Requerimientos. Contenidos. Actividades en la determinación de requerimientos. Introducción a las técnicas para encontrar hechos. Muestreo de la documentación. Investigación y visita a instalaciones.

Download Presentation

ACI491: Ingeniería de Software

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Aci491 ingenier a de software

ACI491:Ingeniería de Software

Unidad 3:

Proceso de Identificación de Requerimientos


Contenidos

Contenidos

  • Actividades en la determinación de requerimientos.

  • Introducción a las técnicas para encontrar hechos.

  • Muestreo de la documentación. Investigación y visita a instalaciones.

  • Observación del entorno de trabajo, Entidades y ejemplos.

  • Análisis de decisiones, Árboles de decisión, Tablas de decisión.

  • Retroalimentación.

  • Prueba de Cátedra N° 1


Objetivos espec ficos de la unidad

Objetivos específicos de la unidad

  • Interiorizar al alumno en los distintas formas para realizar la identificación de requerimientos.

  • Identificar y manejar las diferentes técnicas para el análisis de requerimientos.


Introducci n

Introducción

  • En los clases precedentes hemos visto las fases del ciclo de vida del desarrollo de aplicaciones.

  • Estas fases son relativamente independientes del tipo de metodología que se siga.

  • Una metodología consiste en concretar el tipo de ciclo de vida que se va a seguir y la forma en la que se realizan las actividades dentro de cada etapa, ahora bien, las etapas tienen que seguir siendo las mismas sea cual sea la metodología; es necesario tener una fase de especificación porque se trabaja con los requisitos que proporciona el cliente.


Introducci n 2

Introducción (2)

  • Que una metodología utilice el ciclo de vida en cascada y que esto se haga solo al principio o que sea iterativa y haya varias mini-fases de este tipo es lo que distingue una de otra, pero esta actividad hay que realizarla de todas formas.

  • El diseño es otra fase que es necesaria sea cual sea la metodología por los mismos motivos.

  • La especificación es relativamente independiente de la metodología porque las técnicas de comunicación con el cliente son siempre las mismas, pero en el caso del diseño es donde las cosas empiezan a divergir.


Obtenci n de requisitos

Obtención de requisitos

  • Los métodos tradicionales en cualquier ingeniería requieren como primer paso la obtención de los requisitos en forma de especificaciones por parte del cliente.

  • Este problema habitualmente tiene complicaciones debidas al paso entre el lenguaje natural y los lenguajes más formales en ingeniería.

  • Por lo tanto la obtención de los requisitos es un paso complejo y que no tiene una solución sencilla.

  • Se suelen utilizar los métodos de pregunta-respuesta o los de cuestionarios plantilla para perfilar la versión inicial, pero se requieren sucesivas iteraciones (incluso con otras fases de desarrollo) antes de obtener unas especificaciones adecuadas.


Requisito

Requisito

  • Un requisito es una capacidad que el sistema debe tener porque el cliente lo ha pedido explícita o implícitamente.

  • Lógicamente, la determinación del conjunto de requisitos es el primer paso a dar en la construcción de una aplicación.

  • Existen dos subtareas en la obtención de los requisitos antes de pasar a la fase de diseño:

  • Análisis: El problema a resolver es la comprensión del problema del cliente y que características debe tener el producto.

  • Especificación: Traducir los requisitos a un documento con un formato concreto que pueda servir de entrada a la fase siguiente.


Dificultades

Dificultades

  • La obtención de requisitos es difícil por varias razones:

    • La naturaleza de los requisitos es cambiante.

    • Surgen nuevos requisitos en cualquier momento.

    • El cliente puede no tenerlos claros.

    • Pueden existir malos entendidos debidos a:

      • Falta de conocimientos por parte del equipo desarrollador sobre el problema.

      • Falta de conocimientos técnicos (informáticos) por parte del cliente para expresarse con claridad.


An lisis

Análisis

  • La clave es la comunicación con el cliente.

  • Para facilitar esta comunicación se han desarrollado varias técnicas:

    • entrevistas,

    • prototipos,

    • desarrollo conjunto de aplicaciones (JointApplicationDevelopment - JAD) y planificación conjunta de requisitos (JointRequirementsPlanning - JRP) y

    • casos de uso del UML.


Especificaci n

Especificación

  • Lo que se consigue aquí es un documento que especifica todos los requisitos.

  • Este documento tiene que tener estas propiedades:

  • Completitud: Están todos los requisitos.

  • Concisión: Es importante no hacer una novela, hay que contar lo que hay pero pensando que quien se lea el documento cobra por horas.

  • Legibilidad: Es similar al punto anterior, pero el sentido de este es la claridad.

  • Consistencia: No existen contradicciones internas.


Especificaci n 2

Especificación (2)

  • Facilidades de prueba: De algún modo se debe poder comprobar cada uno de los requisitos.

  • Facilidades de cambio: Es bastante probable que el documento cambie a lo largo del ciclo de vida.

  • Facilidades de seguimiento: Debe ser posible comprobar si se van cumpliendo los objetivos.

  • Factibilidad: Los objetivos definidos deben ser conseguibles a un coste “razonable”.


Tipos de requisitos

Tipos de requisitos

Requisitos funcionales:

  • Dicen qué debe hacer el sistema, en el sentido de servicios proporcionados al usuario.

    Requisitos no funcionales:

  • Hablan de características del sistema, como fiabilidad, mantenibilidad, sistema operativo, plataforma hardware, etc.


Requerimiento

Requerimiento

  • Característica que debe incluirse en un nuevo sistema.

  • La determinación de requerimientos es el estudio de un sistema para conocer cómo trabaja y dónde es necesario efectuar mejoras.

  • Los estudios de sistemas dan como resultado una evaluación de la forma como trabajan los métodos empleados y si es necesario o posible realizar ajustes.


Actividades

Actividades

En la determinación de requerimientos se realiza:

  • Anticipación: Prever las características del sistema con base en la experiencia previa. Esto puede llevar al analista a investigar áreas y aspectos que de otra manera no serían tomados en cuenta. También puede introducir un sesgo.

  • Investigación: Estudio y documentación del sistema actual utilizando técnicas para encontrar hechos, análisis de flujo de datos y análisis de decisión.

  • Especificación: Análisis de los datos que describen el sistema para determinar su desempeño: requerimientos que deben satisfacerse y estrategias para alcanzarlos.


Caracter sticas del nuevo sistema

Características del nuevo sistema

  • Los datos obtenidos durante la recopilación de hechos se analizan para determinar las especificaciones de requerimientos: descripción de las características del nuevo sistema.

  • Esta actividad tiene tres partes relacionadas entre si:

  • Análisis de datos basados en hechos reales.

  • Identificación de requerimientos esenciales.

  • Selección de estrategias para satisfacer los requerimientos.


Introducci n a las t cnicas para encontrar hechos

Introducción a las técnicas para encontrar hechos

  • Los analistas estructuran su investigación al buscar respuestas a cuatro preguntas importantes:

  • ¿Cuál es el proceso básico de la empresa?

  • ¿Cuáles datos utiliza ó produce este proceso?

  • ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?

  • ¿Qué controles de desempeño utiliza?


Comprensi n del proceso

Comprensión del proceso

  • ¿Cuál es la finalidad de esta actividad dentro de la empresa?

  • ¿Qué pasos se realizan para ejecutarla?

  • ¿Dónde se realizan estos pasos?

  • ¿Quiénes los realizan?

  • ¿Cuánto tiempo tardan?

  • ¿Con cuanta frecuencia?

  • ¿Quiénes emplean la información resultante? ¿Para qué?


Comprensi n del proceso 2

Comprensión del proceso (2)

  • El siguiente paso es detectar qué datos se utilizan para llevar a cabo cada actividad.

  • También debe determinarse la frecuencia y el volumen del proceso relacionado con cada actividad, así como su importancia dentro del conjunto de actividades de la empresa.


Requerimientos de las transacciones de los usuarios

Requerimientos de las transacciones de los usuarios

Deben formularse al menos estas preguntas:

  • ¿Qué forma parte de la transacción en proceso?

  • ¿Qué inicia la transacción?

  • ¿Quién inicia los pedidos? ¿Con qué propósito?

  • ¿Con qué frecuencia ocurren los pedidos?

  • ¿Qué volumen está asociado con cada pedido?

  • ¿Existen diferentes condiciones que afecten la forma en que se procesan los pedidos?

  • ¿Qué detalles son necesarios para procesar la transacción?

  • ¿Qué información se genera? ¿Cuáles datos se guardan?


Requerimientos de decisi n de los usuarios

Requerimientos de decisión de los usuarios

  • A diferencia de las actividades de transacción, las rutinas para decisiones no siguen un procedimiento específico, no son muy claras y es posible que los controles sean vagos.

  • Algunas preguntas adicionales son:

  • ¿Qué información se utiliza para tomar la decisión?

  • ¿Cuál es la fuente de esa información? ¿Qué sistemas de transacciones producen datos utilizados en el proceso de decisión? ¿Cuáles otras fuentes necesarias no pueden obtenerse del procesamiento de transacciones? ¿Cuáles datos se originan en fuentes externas a la organización?

  • ¿Cómo deben procesarse los datos para producir la información necesaria?

  • ¿Cómo debe presentarse la información?


Respuestas que deben obtenerse

Respuestas que deben obtenerse

  • Volumen

    • ¿Cuál es? Frecuencia. ¿Actividades cíclicas?

  • Control

    • Áreas que necesitan un control específico.

    • Métodos de control utilizados.

    • Criterios para medir y evaluar desempeño.

    • Detección de fallas en los controles.

    • Precauciones para seguridad y detección de actividades no apropiadas.

    • Detección de posibles métodos para evadir el sistema.


Respuestas que deben obtenerse 2

Respuestas que deben obtenerse (2)

  • Procesos

    • Pasos ó funciones que constituyen esta actividad.

    • Inicio y duración. Factores involucrados. Retrasos y sus causas.

    • Interacciones con otros elementos.

    • Costo de operación

    • Satisfacción de los objetivos específicos de la gerencia.


Respuestas que deben obtenerse 3

Respuestas que deben obtenerse (3)

  • Datos

    • Datos de entrada al sistema. Origen.

    • Forma en que se reciben y se almacenan.

    • ¿Cuáles datos se almacenan en el sistema ó como parte de las actividades del mismo?

    • ¿Quiénes utilizan la información generada por el sistema? ¿Con cuales fines?

    • ¿Qué es lo que no se utiliza?

    • ¿Existen datos desarrollados ó empleados sobre una base ad hoc?

    • Tablas de referencia, diagramas, codificaciones y abreviaturas empleadas.


Respuestas que deben obtenerse 4

Respuestas que deben obtenerse (4)

  • Otros

    • Procesos claves en el sistema. ¿por qué son importantes?

    • Influencias y obstáculos externos (de tipo político, etc.) que afectan la eficiencia del sistema.


Requerimientos de toda la organizaci n

Requerimientos de toda la organización

  • Evaluar implicaciones en otros departamentos.

  • Identificar dependencias existentes respecto a otros lugares de la organización.

  • Manejo de las excepciones: cómo las excepciones desafían los procedimientos típicos de la organización.

    • ¿Trabaja siempre el procedimiento que emplea y describe el usuario?

    • ¿Con cuanta frecuencia es necesario hacer una excepción al procedimiento?

    • ¿Falla el procedimiento?

    • ¿Siguen todos los empleados el mismo procedimiento?


Actividades en la determinaci n de requerimientos

Actividades en la determinación de requerimientos

  • Entrevistas

  • Análisis

  • Cuestionarios

  • Revisión de registros y reportes

  • Observación


Entrevistas

Entrevistas

  • Todo el mundo pasa por una entrevista en algún momento de su vida ya sea para un proceso de selección de personal, un examen de oposición o incluso una conversación con el jefe se podría considerar como una entrevista.

  • Aunque también existan otras técnicas, esta siempre la tendremos, al menos al inicio del proyecto.

  • Una entrevista tiene tres fases: Preparación, Desarrollo y Análisis.


Preparaci n

Preparación

  • Hay cuatro cuestiones que se han de tener en cuenta:

  • Documentación: El entrevistador se informa acerca del tema a tratar. Puede hacerlo de varias formas:

    • Estudiar la bibliografía sobre el tema.

    • Estudiar documentos sobre proyectos similares.

    • Inmersión dentro de la organización para la que se desarrolla el proyecto.


Preparaci n 2

Preparación (2)

  • Personal: Se seleccionan las personas a las que se va a entrevistar.

    • Directivos: Dan una imagen de alto nivel de la empresa. Puede ser útil para determinar la estructura arquitectónica de la aplicación.

    • Empleados: Dan una imagen de un grano más fino. Son los que pueden concretar las funciones a implementar.


Preparaci n 3

Preparación (3)

  • Determinar el objetivo de la entrevista. Previamente a la entrevista se pueden distribuir a los entrevistados cuestionarios sobre el tema a tratar y una introducción.

  • Logística: Temas prácticos acerca de como discurre la entrevista: lugar, hora, minimizar interrupciones, encontrar un momento en el que todos puedan ir, etc.


Desarrollo de la entrevista

Desarrollo de la entrevista

  • Consta de tres etapas:

  • Apertura: El entrevistador se presenta e informa al entrevistado de cuales van a ser los puntos tratados en la entrevista

  • Desarrollo: No debe durar más de dos horas. El entrevistado debería hablar el 80% del tiempo.

  • Terminación: Se hace un resumen de la información recogida para validar que es correcta y, de ser necesario, se cita para la siguiente entrevista. En cualquier caso se debe poder contactar de nuevo con el interesado, por ejemplo para aclarar algunos puntos. Se agradece al entrevistado que nos haya dedicado su tiempo.


T cnicas utilizadas para desarrollar la entrevista

Técnicas utilizadas para desarrollar la entrevista

  • Preguntas abiertas, también conocidas como de contexto libre. No se pueden contestar con “Si” o “No”. Ejemplo: ¿Cuál es la lista de pasos para dar de baja un producto? Más tarde se pasa a preguntas más concretas.

  • Forma de expresarse: Se deben evitar los tecnicismos que el entrevistado pueda no conocer.

  • Psicología: El problema fundamental de las entrevistas es que se trata con personas en vez de con máquinas, por eso la comunicación es de peor calidad. Hay que tener en cuenta las siguientes reglas entre muchas otras de la comunicación no verbal:


Reglas de comunicaci n para desarrollar la entrevista

Reglas de comunicación para desarrollar la entrevista

  • No insinuar que el entrevistado debería saber algo que no sabe para que no se ponga a la defensiva. También hay que dejar claro que los intereses del entrevistador son únicamente la adquisición de requisitos, no hacer un examen de conocimientos, y por tanto las lagunas que pueda tener no trascenderán a sus superiores.

  • Lenguaje del cuerpo: Dicen los psicólogos que el 90% de la comunicación es no verbal. Se debe estar atento a los signos que puedan denotar inseguridad en algunos temas para preguntar a otras personas.

  • Usar técnicas para mantener la atención del entrevistado.


Entrevista estructurada

Entrevista estructurada

Ventajas

  • Asegura términos uniformes en las preguntas para todos los entrevistados.

  • Fácil de administrar y de evaluar.

  • Mayor objetividad en la evaluación de preguntas y respuestas.

  • Se necesita poco entrenamiento del entrevistador.

  • Se obtienen resultados con entrevistas cortas


Desventajas

Desventajas

  • Costo de preparación alto

  • Posibilidad de que los entrevistados no acepten un nivel alto de la estructura y planteamiento de las preguntas.

  • Alto nivel de estructura no sea adecuada para todas las situaciones

  • Alto nivel de estructura disminuye espontaneidad o habilidad para seguir comentarios


Entrevista no estructurada

Entrevista NO estructurada

Ventajas

  • Mayor flexibilidad para modificar preguntas de acuerdo con la persona que se entrevista.

  • El entrevistador puede profundizar en áreas que aparezcan de manera espontanea durante la entrevista.

  • La entrevista puede proporcionar información respecto a áreas que no fueron consideradas al inicio.


Desventajas1

Desventajas

  • Uso ineficiente del tiempo por parte de los participantes

  • El entrevistador puede introducir sus propios sesgos en las preguntas ó al notificar sus resultados.

  • Se pudiera obtener información ajena al problema.

  • El análisis e interpretación de los resultados puede llevar bastante tiempo.

  • Se necesita mayor tiempo para reunir hechos esenciales.


An lisis1

Análisis

  • Se trata de ver como utilizar los conocimientos adquiridos durante la entrevista.

  • Para ello las actividades son:

    • Burocracia, como por ejemplo, pasar a limpio la entrevista.

    • Asimilación de la información: Se contrasta con otras entrevistas, bibliografía, etc. Se llega a conclusiones.

    • Evaluación de la entrevista: ¿Qué se quería conseguir y qué se ha conseguido?

  • Para validar una vez más la entrevista se puede mandar la documentación generada al entrevistado.


Muestreo de la documentaci n

Muestreo de la documentación

  • Varios tipos de registros y reportes pueden brindar información valiosa con respecto a las organizaciones y a sus operaciones.

  • Se revisa y analiza la información asentada respecto al sistema y sus usuarios.

  • Esta revisión puede realizarse introductoriamente al comienzo del estudio y después, para comparar las operaciones actuales.

  • Los registros pueden indicar qué está sucediendo.


Investigaci n y visita a instalaciones

Investigación y visita a instalaciones

  • Permite comprender el funcionamiento in situ de la organización.

  • El hallazgo de hechos constituye un reto y una oportunidad.


Observaci n del entorno de trabajo

Observación del entorno de trabajo

  • La observación permite ganar información que no puede obtenerse mediante otras técnicas.

  • Este método en mas útil cuando se debe conocer de una parte, la forma en que se manejan los documentos y se llevan a cabo los procesos, y de otra, si se siguen todos los pasos especificados.

  • La observación busca y evalúa la importancia de lo observado.


An lisis de decisiones

Análisis de decisiones

  • Cuando se analizan procedimientos y decisiones, el primer paso es identificar condiciones y acciones, conceptos comunes a todas las actividades.

  • Condiciones: Posibles estados de una entidad (persona, lugar, objeto, evento).

    Las condiciones cambian, por lo que se refieren como variables de decisión.

  • Acciones: Se determina que es lo que se hace cuando están dadas algunas condiciones.

    Las acciones son opciones, alternativas, que comprenden pasos, actividades ó procedimientos que pueden elegirse frente (como respuesta) a un conjunto dado de condiciones.


Herramientas para documentar procedimientos y decisiones

Herramientas para documentar procedimientos y decisiones

  • Algunas herramientas para estudiar procedimientos de operación y pasos a seguir para documentar las decisiones son:

  • Árboles de decisión

  • Tablas de decisión


Rboles de decisi n

Árboles de decisión

  • Es un diagrama que representa en forma secuencial condiciones y acciones

  • Muestra condiciones jerarquizadas y relaciones entre las condiciones

  • Árbol: raíz, condiciones y acciones

  • Beneficia a los analistas:

    • Describir condiciones y acciones correctas

    • Considerar la secuencia de las decisiones


Rboles de decisi n1

Árboles de decisión

  • Los árboles de decisión son herramientas excelentes para ayudar a realizar elecciones adecuadas entre muchas posibilidades.

  • Su estructura permite seleccionar una y otra vez diferentes opciones para explorar las diferentes alternativas posibles de decisión.

  • Los árboles de decisión son guías jerárquicas multivía donde los valores de las características son el criterio diagnóstico para evaluar.

  • La jerarquía se refiere a que la toma de una decisión o camino lleva a otra, hasta que todos los factores o características involucradas se hayan tomado en cuenta.

  • Es multivía porque pueden existir más de dos opciones y es una guía porque al responder una pregunta se llega a una decisión (Rossiter, 1997).


Tablas de decisi n

Tablas de decisión

  • Es una matriz de renglones y columnas que indican condiciones y acciones.

  • Las reglas de decisiones, incluidas en una tabla de decisión establecen el procedimiento a seguir cuando existen ciertas condiciones.

  • Este método se emplea desde mediados de la década de los 50, cuando fue desarrollado por General Electric para el análisis de funciones de la empresa como control de inventarios, análisis de ventas, análisis de créditos y control de transporte y rutas.

  • Se utiliza la tabla de decisión cuando existen muchas combinaciones.


Caracter sticas de las tablas de decisi n

Características de las Tablas de decisión

  • La tabla de decisión está integrada por cuatro secciones:

    • Identificación de Condiciones

    • Entradas de Condiciones

    • Identificación de Acciones

    • Entradas de Acciones

  • La Identificación de Condiciones señala aquellas que son relevantes.

  • Las Entradas de Condiciones, indican que valor, si es que los hay, se debe asociar para una determinada condición

  • Las entradas de Acciones muestran las acciones específicas del conjunto que deben emprenderse cuando ciertas condiciones o combinaciones de éstas son verdaderas.


Ejemplo de una tabla de decisi n

Ejemplo de una Tabla de Decisión.


Retroalimentaci n

Retroalimentación

  • La retroalimentación se produce cuando las salidas del sistema o la influencia de las salidas del sistemas en el contexto, vuelven a ingresar al sistema como recursos o información.

  • La retroalimentación permite el control de un sistema y que el mismo tome medidas de corrección en base a la información retroalimentada.

  • Esto es de uso frecuente para controlar el comportamiento dinámico del sistema.

  • Los ejemplos de la realimentación se pueden encontrar en la mayoría de los sistemas complejos, tales como ingeniería, arquitectura, economía, y biología.


Fuentes de informaci n

Fuentes de información

  • Análisis, Diseño y Mantenimiento del Software


  • Login