UNIVERSIDAD TÉCNICA DE COTOPAXI

Presentación del tema: "UNIVERSIDAD TÉCNICA DE COTOPAXI"— Transcripción de la presentación:

1 UNIVERSIDAD TÉCNICA DE COTOPAXI
ANÁLISIS Y DISEÑO DE SISTEMAS ESTRUCTURADOS

2 Técnicas efectivas para la toma de requerimientos
Hablando del Desarrollo, podemos comenzar diciendo que un gran número de los proyectos de desarrollo de sistemas fracasan por no realizar una adecuada definición, especificación, y administración de los requerimientos

3 DANDO COMO RESULTADO La insatisfacción del cliente
Escasa o nula participación del usuario Provocan Pobre definición de requerimientos Requerimientos ambiguos o inexactos DANDO COMO RESULTADO La insatisfacción del cliente La extensión de la duración del proyecto El fracaso total del mismo

4 Para conseguir un proyecto de software exitoso debes comprender el ámbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir. Para poder obtener buenos requerimientos, primero debemos definir que son, que los caracteriza y como pueden clasificarse. Hay muchas definiciones de Requerimiento, considero una de las más completas la siguiente: “Una capacidad necesitada por un usuario para resolver un problema o llevar a cabo un objetivo”

5 Lo siguiente es ver cuáles son las características que debe cumplir.
Necesario. Si se tiene alguna duda acerca de la necesidad del requerimiento, se pueden preguntar “¿Qué sería lo peor de no incluirlo?” Si no se encuentra una respuesta o cualquier consecuencia, entonces es probable que no sea un requerimiento necesario. Factible. El requerimiento deberá de ser totalmente factible y dentro de presupuesto, calendario y otras restricciones, si se tiene alguna duda de su factibilidad, hay que investigar, generar pruebas de concepto para saber su complejidad y factibilidad, si aun así el requerimiento es no factible hay que revisar la visión del sistema y replantear el requerimiento Completo. Un requerimiento esta 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 Verificable. Si un requerimiento no se puede comprobar, entonces ¿Cómo se sabe si se cumplió con él o no? Debe ser posible verificarlo ya sea por inspección, análisis de prueba o demostración. Cuando se escriba un requerimiento, se deberá de determinar los criterios de aceptación. Claro: 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. Priorizado. Categorizar el requerimiento nos ayuda a saber el grado de necesidad del mismo Esencial/Critico, Deseado, Opcional Verificable. Rastreable. La especificación se debe organizar de tal forma que cada función del sistema se pueda rastrear hasta su conjunto de requerimientos correspondiente. Facilita las pruebas y la validación del diseño Correcto. acuerdo entre dos partes. Contiene una sola idea. Modificable.

6 Ahora, los requerimientos los podemos agrupar en una pirámide de tipos para poderlos explicar:
Stakeholder es un término en inglés utilizado por primera vez en 1708 para determinar una persona o negocio que ha invertido dinero en algo 

7 Necesidades Dentro de la Pirámide de Requerimientos, situados en el punto más alto, se encuentran las necesidades de los Stakeholders, están orientadas a oportunidades (problemas) de Negocio las cuales deben de ser cubiertas de forma satisfactoria. Algunas de estas oportunidades desencadenan la realización de un sistema de Software.

8

9 Requerimientos de Software (requerimientos funcionales) Son las necesidades de los Stakeholders que requiere que el Sistema deba de cumplir de manera Satisfactoria. Son los que definen las funciones que el sistema será capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Es importante que se describa el ¿Qué? y no el ¿Cómo? se deben hacer esas transformaciones. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lógica y gran parte del código del sistema

10 Una vez que tenemos identificados los tipos de requerimientos que existen, y las características que deben cumplir, podemos comenzar con la descripción de las actividades que nos ayudarán a realizar una buena obtención de requerimientos. Ejemplo: No vamos a descubrir el hilo negro, ya está más que definido el proceso, solo hay que aprender a llevarlo adecuadamente. A este conjunto de actividades de le denomina Ingeniería de Requerimientos, el cual cumple un papel primordial en el proceso de Desarrollo de Software, es la que nos puede apoyar para lograr proyectos exitosos, se 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. Este proceso comprende cinco actividades de alto nivel

11 1. Obtención de Requerimientos
Esta fase representa el comienzo de cada ciclo. Es la parte más importante del proceso ya que todo lo que se obtenga en esta fase será la base para la construcción del sistema. Aquí, los analistas de requerimientos deberán trabajar junto al cliente para descubrir el problema que el sistema debe resolver. Previo a esto es importante que al empezar hagan una definición de quienes serán los involucrados en la definición de los requerimientos y sobre todo definir quien será el encargado de realizar las autorizaciones a los documentos que se obtengan en la fase previo acuerdo con el resto de los involucrados. Se debe especificar lo siguiente: Objetivo del sistema, y fechas tentativas del inicio y fin del proyecto Presentación del Equipo de Trabajo Presentación o definición de stakeholders (involucrados en la definición de los requerimientos y líder funcional, que es quien hace la autorización de los documentos en nombre de todo el equipo del cliente) Fechas tentativas de reuniones con el cliente (esto se usa cuando es una consultoría la que presta el servicio al cliente

12 Las actividades a contemplar durante esta etapa son:
2. Análisis de Requerimientos Es el segundo paso que nos dicta la Ingeniería de Requerimientos, implica refinar, analizar, y examinar/escudriñar los requerimientos obtenidos para asegurar que todos los clientes involucrados entienden lo que pidieron, y para encontrar errores, omisiones y otras deficiencias. En esta etapa se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos. Las actividades a contemplar durante esta etapa son:

13 3. Especificación de Requerimientos En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. Se documenta la descripción completa de las necesidades y funcionalidades del sistema que será desarrollado; describe el alcance del sistema y la forma como hará sus funciones, definiendo los requerimientos funcionales y no funcionales. En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede decir que la especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación.

14 4. Verificación de Requerimientos Lo que se debe hacer es realizar revisiones al documento, aplicarles pruebas de escritorio, etc. Aquí un ejemplo de puntos a revisar en los documentos obtenidos: ¿Están incluidas todas las funcionalidades requeridas por el cliente? (completa). ¿Existen conflictos en los requerimientos? (consistencia) ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua) ¿Esta cada requerimiento claramente representado? (entendible) ¿Puede ser los requerimientos implementados con la tecnología y presupuesto disponible? (factible) ¿Está la especificación escrita en un lenguaje apropiado? (clara) ¿Existe facilidad para hacer cambios en los requerimientos? (modificable) ¿Está claramente definido el origen de cada requerimiento? (rastreable) ¿Pueden ser los Requerimientos ser sometidos a pruebas cuantitativas? (verificable)

15 5. Aceptación de Requerimientos Este es un proceso donde los analistas involucrados se reúnen con el cliente y comienzan a dar una revisión formal al documento, esto es, comienzan a leer y explicar cada requerimiento, incluso se pueden apoyar nuevamente en prototipos en papel para que quede más claro el funcionamiento, esto con el fin de que todos estén en el mismo entendido de lo que se realizará para cada requerimiento. Una vez que todos estén de acuerdo se hace la aceptación/aprobación de la especificación de requerimientos, se realiza un compromiso formal de que lo contenga la Especificación será lo que se construya y se pide al cliente una aprobación formal vía correo electrónico o una firma sobre el documento físico

16 Técnicas para el Análisis de Requerimientos

17 Contenido temático Técnicas estructuradas para el análisis de requerimientos Características del análisis estructurado Especificación formal de datos Diagrama de flujos y control de datos Diccionario de datos Especificación de procesos Lenguaje natural Lenguaje estructurado Tablas de decisión Árboles de decisión

18 Contenido temático Técnicas orientadas a objetos para el análisis de requerimientos Características del análisis orientado a objetos Especificación formal de objetos Casos de uso Modelado de clases, responsabilidades y colaboraciones Definición de atributos Definición de servicios Prototipos rápidos para la determinación de requerimientos

19 Contenido temático Técnicas basadas en componentes Otras técnicas
Ingeniería del dominio Identificación y clasificación de los componentes reutilizables Caracterización de los componentes Otras técnicas

20 Técnicas estructuradas para el análisis de requerimientos
Características del análisis estructurado Especificación formal de datos Diagrama de flujos y control de datos Diccionario de datos Especificación de procesos Lenguaje natural Lenguaje estructurado Tablas de decisión Árboles de decisión

21 Características del análisis estructurado
¿Qué es el análisis estructurado? El objetivo que persigue es estructurar u organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada.

22 Características del análisis estructurado
Se concentra en especificar lo que se requiere que haga el sistema o la aplicación. No se establece como cumplirán los requerimientos o la forma en que implantaran la aplicación. Más bien permite que las personas observen los elementos lógicos separados de los componentes físicos. Después de esto se puede desarrollar un modelo físico eficiente para la situación donde será utilizado.

23 Características del análisis estructurado
Componentes: Símbolos gráficos (iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes) Diccionario de Datos (descripciones de todos los datos utilizados en el sistema) Descripciones de procesos y procedimientos (declaraciones formales que emplean técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema) Reglas (estándares para describir y documentar el sistema en forma correcta y completa)

24 Análisis del flujo de datos
Estudia el empleo de los datos en cada actividad, documenta los hallazgos con diagramas de flujo de datos y en los diccionarios de datos que describen de manera formal los datos del sistema y los sitios donde son utilizados.

25 Flujo de Datos -Proceso -Decisión -Datos -Documento -Conector
-Pantalla -Terminador -Datos almacenados

26 Flujo de Datos (Un ejemplo)
*Proceso de Evaluación Docente del Sistema de Gestión de Calidad en el ITSSP (2007)

27 Diccionario de Datos Es un catálogo, un dispositivo de los elementos de un sistema. Se desarrolla durante el análisis del flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema. Sus elementos se centran alrededor de los datos y en la forma en que están estructurados para satisfacer los requerimientos de los usuarios y las necesidades de la organización.

28 Razones para usar diccionarios de datos
Para manejar los detalles en sistemas grandes. Para comunicar un significado común para todos los elementos del sistema. Para documentar las características del sistema. Para facilitar el análisis de los detalles con la finalidad de evaluar las características y determinar donde efectuar cambios en el sistema. Para localizar errores y omisiones en el sistema.

29 Contenido del diccionario de datos
El diccionario contiene 2 tipos de descripciones para el flujo de datos dentro del sistema: Elemento de datos; son bloques básicos para todos los demás datos del sistema. Estructura de datos; es un grupo de datos elementales que están relacionados con otros y que en conjunto describen un componente del sistema.

30 Diagrama de Flujo de Datos (DFD)

31

32 DFD - EJEMPLO - Gestión Biblioteca (1)
Petición de libros Un usuario puede realizar una petición de uno o más libros a la biblioteca. Presenta el carnet de usuario de la biblioteca y una ficha en la que se detallan los libros pedidos. Tipos de préstamo Tiempo SALA El día de la petición AYUDANTE Una semana PROYECTO FIN CARRERA Quince días DOCTORADO Un mes Una vez entregados el carnet y la ficha, el sistema comprobará y aceptará la petición de los libros solicitados siempre que pueda satisfacer la petición, es decir, cuando haya ejemplares disponibles. Si se acepta la petición, se actualiza el número de unidades de los libros de la biblioteca y se guarda la ficha de préstamo.

33 Devoluciones de libros
Un usuario no puede realizar más peticiones hasta que no haya efectuado todas las devoluciones de la petición anterior. El usuario, para hacer la petición, necesita el carnet, que no se le entrega hasta que no haya devuelto todos los libros. Sí puede hacer una devolución parcial de los libros. Cuando un usuario realice una devolución, el sistema actualizará el stock de libros y comprobará la fecha de devolución de cada ejemplar para estudiar, en el caso de que la devolución se haga fuera de tiempo, la imposición de una sanción que tiene un coste de $ X por cada ejemplar y días de retraso en la devolución. En este caso, la sanción se emite cuando el usuario entrega el último ejemplar. El bibliotecario se encarga de las altas y bajas de los libros de la biblioteca.

34

35

36