ANALISIS DE SISTEMAS

1. ANALISIS DE SISTEMAS Lic. Espinoza Robles Armando David.

2. Análisis de Requisitos. • Introducción al Análisis de Requisitos.: • el análisis consiste en producir un documento de especificaciones de requisitos que describa lo que el futuro sistema debe hacer, pero no como debe hacerlo.por ello algunos autores lo llaman determinación de requisitos.

3. Definición: el análisis de requisitos es el proceso de estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema, de hardware o de software; así como su estudio y refinamiento. • Requisito: es una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo. Aplicado a los sistemas es los que debe cumplir o poseer un sistema para satisfacer un contrato, una norma o una especificación

4. La definición de los requisitos debe ser fruto del trabajo de usuarios y desarrolladores del softw, a través del análisis, esto es así por: • el cliente no suele entender el proceso de diseño y desarrollo del softw. Como para redactar una ERS( especificación de requerimientos de softw.) • los analistas no suelen entender completamente el problema del cliente.

5. La fase de análisis de requisitos consta de : • Definirlos requisitos de softw.: es una tarea iterativa para crear una especificación preliminar de requisitos, a partir de la información obtenida según las técnicas de recojo de información.(entrevista, JAD) • Definir los requisitos de Interfaces: del softw. Con el resto del sistema y el exterior. Como los usuarios, el hardware, otras aplicaciones. La interfaz con el usuario es critica para la facilidad de uso

6. Integrar los requisitos: es un documento de especificación y asignarles prioridades. El usuario tiene papel fundamental en la aprobación o no de los mismos. Así mismo se asigna prioridades en función de su importancia • otra manera de describir las actividades que se realiza en la fase de análisis de requisitos es: • Extracción o determinación de requisitos: los clientes descubren revelan, comprenden los requisitos que desean.

7. Análisis de Requisitos: proceso de razonamiento sobre los requisitos obtenidos en la etapa anterior, resolviendo posibles inconsistencias • Especificación de Requisitos. El proceso de registro de los requisitos, para lo que se puede recurrir al lenguaje natural, gráficos etc. • Validación de los requisitos.: los usuarios confirman que los requisitos especificados son validos, consistentes, completos.

8. Estas actividades no tienen que realizarse en secuencia ya que hay continuas iteraciones y solapamientos entre ellas, • su realización se apoyan en diferentes técnicas así: • para la extracción o determinación de requisitos se emplea técnicas de recogida de información (JAD, entrevistas etc). • Para el análisis y la especificación existen técnicas gráficas (DFD), análisis estructurado

9. Para la validación se recurre a la lista de comprobación de distintos aspectos de las especificaciones que suelen usarse con técnicas de revisión.

10. Especificación de requisitos de Software • Introducción: para comprender que es un ERS definiremos: • Especificación: es un documento que define de forma completa, precisa y verificable los requisitos, el diseño, el comportamiento de un sistema. • Software: conjunto de programas, procedimientos y documentación asociada a la operación de un sistema informático

11. La ERS se puede definir como documentación de los requisitos esenciales del software y de sus interfaces externas. • Las dos características fundamentales de una ERS son: • 1. Debe incluir información veraz, coherente con las necesidades reales del usuario • 2. Debe comunicar dicha información de forma eficaz, es decir de forma que se pueda comprender.

12. El ERS describe lo que hay que desarrollar, no el como, el cuando etc, esto implica: • 1. Describir correctamente todos los requisitos del software, sin incluir requisitos innecesarios. • 2. No describir ningún detalle del diseño del software, de su verificación o de la dirección del proyecto. • En definitiva, se trata de especificar lo que desea el usuario sin considerar como se va ha solucionar.

13. Características de una Buena ERS • 1. No ambigua • 2. Completa • 3. Fácil de verificar • 4. Consistente • 5. Fácil de modificar • 6. Facilidad para modificar el origen y las consecuencias de cada requisito • 7. Facilidad de utilización durante la fase de explotación y mantenimiento. • Analizaremos cada uno de estas características

14. No Ambigua. • Un requisito ambiguo se presta a distintas interpretaciones. Por los que un ERS no es ambiguo si cada requisito tiene una sola interpretación. • En caso que un termino es usado en distinto contexto debe incluirse en un glosario, donde se determina la forma exacta de su significado. • Los requisitos se describen en lenguaje natural, lo que implica un riesgo por su alto grado de ambigüedad.

15. Los analistas que especifiquen los requisitos con un lenguaje natural deben poner atención en no caer en ambigüedades. • Una alternativa ha este problema es el uso de un lenguaje formal de especificación de requisitos. • Completa: • una ERS esta completa si: • 1. Incluye todos los requisitos significativos del software • 2. Define la respuesta del softw, a todas las posibles clases de datos de entrada

16. 3. Esta conforme con cualquier estándar de especificación que se deba cumplir. • 4. Están etiquetadas y referenciadas en el texto todas la figuras, tablas y diagramas. También deben estar definida todos los términos y unidades de medida. • Cualquier ERS que utilice “por Determinar” (TBD) no esta completa. Hay veces que suele ser necesario usar un TBD, en este caso, se debe acompañar de: • una descripción de las condiciones que a causado el TBD para que la situación pueda resolverse

17. Una descripción de que hay que hacer para eliminar el TBD • Fácil de Verificar • una ERS es fácil de verificar si y solo si cualquier requisito al que se haga referencia se puede verificar fácilmente • Consistente. • Una ERS es consistente si y solo si ningún conjunto de requisitos descritos en ella son contradictorios o entran en conflicto, se puede presentar tres tipos de conflicto:

18. 1. Dos o mas requisitos pueden describir el mismo objeto real pero usan distintos términos. • 2. Las características especificadas de objetos reales pueden estar en conflicto • 3. Puede haber un conflicto lógico o temporal entre dos acciones determinadas • Fácil de Modificar • una ERS es fácilmente modificable si su estructura y estilo permiten que cualquier cambio en los requisitos se pueda hacer fácil, completa y consistente. La ERS debe:

19. Tener una organización coherente y manejable, con una tabla de contenidos, un índice y referencias cruzadas. • No ser redundantes; o sea, que el mismo requisito no aparezca en mas de un lugar de la ERS. • La redundancia en si no es un error pero puede conducir a errores. Como no es posible de evitar es mejor crear referencias cruzadas entre los requisitos.

20. Facilidad para identificar el Origen y las consecuencias de cada requisito (facilidad de traza). • Se dice que una ERS facilita las referencias con otros productos del ciclo de vida si establece un origen claro para cada uno de los requisitos y si posibilita las referencias de estos requisitos en desarrollos futuros. Se recomienda dos tipos de referencias: • 1. Referencias hacia atrás. Los requisitos referencian explícitamente sus fuentes en documentos previos.

21. 2. Referencia hacia delante. Depende de que cada requisito de la ERS tenga un nombre o numero de referencia único, que sirva para identificarlo en futuros documentos. • Cuando un requisito de la ERS representa una derivación de otro requisito, se debe facilitar la referencia hacia atrás como hacia delante.

22. Facilidad de utilización durante la fase de explotación y mantenimiento. • La ERS debe tener en cuanta la necesidad de mantenimiento, debido a que: • 1. El personal que no ha estado relacionado con el desarrollo del softw, se encarga del mantenimiento. Cuando las modificaciones son profundas se debe actualizar la documentación del diseño y requisitos, en este ultimo caso: • la ERS debe ser fácil de modificar

23. La ERS deberá proveer un registro de las características especiales de cada componente tales como: • su criticidad • su relación con necesidades temporales • su origen • 2. Gran parte de los conocimientos y de la información para el mantenimiento se dan por supuestos en la organización del desarrollo, pero suelen estar ausentes en la organización del mantenimiento

24. EVOLUCION DE LA ERS: • La ERS necesitara ser cambiada a medida que progrese el producto softw. Dos consideraciones a tener en cuenta en este proceso son: • 1. El requisito debe ser especificado de la forma mas completa posible • 2. Debe iniciarse un proceso formal para identificar, controlar, e informar de cambios proyectados tan pronto como sean identificados. De forma que permita: • A) suministrar una revisión precisa y completa del rastro de las modificaciones • B) permitir exámenes de fragmentos actuales y reemplazados de la ERS.

25. Una Estructura para la ERS. • Se presenta una sugerencia de estructura para la ERS. Cualquier ERS que este bien escrita debería incluir toda la información que aquí se expone: • 1. Introducción • 1.1 Objetivos • 1.2 Ámbito • 1.3 definición, siglas abreviaturas • 1.4 Referencias • 1.5 Visión global

26. 2. Descripción General • 2.1 Perspectiva del proceso • 2.2 Funciones del Proceso • 2.3 Características del Usuario • 2.4.Limitaciones Generales • 2.5 supuestos y dependencias 3. Requisitos específicos 3.1 Requisitos Funcionales 3.1.1 requisito Funcional 1 3.1.1.1 Introducción 3.1.1.2 Entradas 3.1.1.3 Procesamiento 3.1.1.4 Salidas 3.1.2 Requisito Funcional 2 ----------------------- 3.1.n Requisito funcional n

27. 3.2 requisitos de interfaz externa • 3.2.1 Interfase de usuario • 3.2.2 Interfaces hardware • 3.2.3 Interfase Software • 3.2.4 Interfaces de comunicaciones • 3.3 requisitos de Ejecución • 3.4 restricciones de Diseño • 3.4.1 Acatamiento de estándares • 3.4.2 Limitaciones de hardware • -------------- • 3.5 Atributos de calidad • 3.5.1 Seguridad • 3.5.2 Mantenimiento • --------------- • 3.6 Otros Requisitos • 3.6.1 Base de datos • 3.6.2 operaciones • 3.6.3 Adaptación de situación • Apéndices • Índice

28. Especificación de Requisitos de Interfaces • Uno de los aspectos mas importantes, es la especificación de las interfaces externas del softw., por su influencia en la facilidad de usopor ser lo que mas directamente percibe el usuario. • Las interfaces externas coinciden con lo que anteriormente se llamaba entradas y salidas del sistema. • En el caso de salidas, hablaremos de pantallas, listados, archivos etc. • En caso de entradas: encontramos teclados, censores, archivos etc.

29. La definición de interfaces de E / S tiene como objetivo la estabilización del modo en que el sistema va ha interactuar con el exterior del sistema. • VISION GENERAL DE LAS TECNICAS DE ESPECIFICACION • No existe un criterio definitivo para clasificar estas técnicas, sin embargo se puede clasificar bajo dos enfoques: Según la forma de presentación: pueden ser Graficas, textuales, matriciales Según el enfoque de modelizacion:

30. Clasificación según la forma de representación: Graficas: cada técnica usa una serie de iconos en el que cada uno representa un componente de un aspecto del modelo. Textuales: se usan para especificar con mas detalles los componentes definidos en los gráficos, mediante una gramática definida (seodocodigo) Marcos o Plantillas “templates” especifica la información relativa a un componente de un modelo que ha sido declarado en un diagrama. Se representa mediante un formulario ej.

31. ENTIDAD: Estudiante DESCRIPCION: Un estudiante es cualquier persona que esta matriculado en unas de la asignaturas ofertadas ATRIBUTOS: Nro.DNI, apellidos, nombre, dirección, provincia teléfono IDENTIFICADORES: Nro.DNI RESTRICCIONES: VOLUMEN MAXIMO DE OCURRENCIAS: 200 • En la figura se define el contenido de una entidad definida en un diagrama E/R

32. Matriciales: se consideran como técnicas de comprobación entre modelos, ya que permite estudiar referencias cruzadas. • Clasificación según el Enfoque de Modelizacion: • Se presentan tres perspectivas para examinar un sistema: • Función: que hace el sistema • Información: que información utiliza el sistema • Tiempo: cuando sucede algo en el sistema

33. Información Tiempo Función Perspectivas desde las que se puede modelizar un sistema.

34. Para cada perspectiva hay un conjunto de técnicas que se utiliza con frecuencia: • Dimensión de la Función: el diagrama de flujo de datos se utiliza para mostrar las funciones del sistema sus interfases. • Dimensión de la información : el diagrama E/R se utiliza para señalar las entidades y las relaciones entre ellas. • Dimensión del tiempo: la lista de eventos se utiliza para mostrar cualquier cosa que ocurra y sobre el que el sistema debe responder.

35. Las tres dimensiones generan planos los cuales son: • Plano Información Tiempo: se utiliza un diagrama de historia de vida de una entidad para mostrar el efecto del tiempo sobre una entidad de datos. • Plano Información Función: la principal técnica es el diagrama de flujo de datos que describe el uso de la información por un conjunto de funciones del sistema. • Plano función tiempo: aquí podemos incluir las redes de Petri y los diagramas de transición de estados, que muestra el efecto del tiempo sobre las funciones del sistema.

36. Al modelizar un sistema se suele dar mas importancia a una dimensión que a otra, para la construcción de un sistema basado en el mantenimiento de una BD, la dimensión mas afectada es la Información, para un sistema en tiempo real la dimensión predominante es el tiempo.

37. MODELIZACION DE FUNCIONES Diagrama de Flujo de datos: Concepto: es la técnica mas difundida en el análisis estructurado, permite a los analistas modelizar las funciones que debe realizar el sistema y los datos que fluyen entre ellas. A finales de los setenta DeMarco define esta técnica, que se apoya en otras como el diccionario de datos y las especificaciones de proceso.

38. Un DFD es un diagrama que representa el flujo de datos y las transformaciones que se aplican sobre ellos al moverse de la entrada a la salida. • El sistema se modelizara a través de un conjunto de DFD nivelados. En los que los niveles superiores definen las funciones del sistema de forma general, y los niveles inferiores definen estas funciones a niveles mas detallados.

39. Componentes de un DFD • Procesos: son componente funcionales del sistema • Almacenes: que representan datos almacenados o en reposo • Entidades externas: que representan la fuente y/o el destino de la información. • Flujo de datos: que representan los datos que fluyen entre las funciones.

40. Procesos (función o transformaciones) • El proceso representa una función que transforma los flujos de datos de entrada en uno o varios flujos de datos de salida. El termino proceso debe verse como una función que debe realizar el sistema. • La representación grafica varia pero la mas común es un circulo, en cuyo interior existe un numero y un nombre que debe cumplir con: • Ser lo mas representativo de la función • Ser breve, formado por un verbo seguido de un sustantivo

41. 1 Generar Pedido • El nombre y el numero del proceso deben ser unicos en el DFD

42. Almacén de datos: Representa información del sistema almacenada de forma temporal. Si los flujos de datos representan datos en movimiento, los almacenes representan en reposo. El almacén es un deposito lógico de almacenamiento, pude representar un cajón con papeles, un archivo manual, un archivo, una BD. Se representa por dos líneas paralelas y tiene las siguientes características:

43. Todos los almacenes de datos llevan un nombre • Un almacén se puede representar varias veces en un DFD • Dentro de un conjunto de DFD nivelados, el almacén se situara en el nivel mas alto, de los que sirven de interconexión. • Si en un DFD un almacén solo tiene conexión con un proceso, se dice que el almacén es local a ese proceso. • Un almacén tiene estructura simple cuando es de tipo registro. • El contenido de un almacén con estructura compleja se representa con un diag. E/R

44. Entidades Externas (terminadores) • es el componente del DFD que representa un generador o consumidor de información del sistema y que no pertenece al mismo.puede ser un subsistema, persona, departamento, organización, etc. • Podemos considerar una serie de aspectos referentes a la entidades externas: • son externos al sistema que se esta modelizando. Definen la interfaz entre el sistema y el mundo exterior

45. Las relaciones que haya entre las entidades externas no son objeto del estudio del modelo. • Se representan en el diagrama mediante un cuadrado en el que se indica un nombre en su interior. • Normalmente, las entidades externas solo van a aparecer en el DFD de mayor nivel, que se llamara diagrama de contexto. Departamento Compras Cliente

46. Flujos de datos • lo definimos como un camino a través del cual viajan datos de composición conocida de una parte del sistema a otra. • Representan los datos en movimiento en un momento. • Los flujos de datos son el medio de conexión de los restantes componentes del DFD. • Se representan mediante arcos dirigidos, en donde la flecha indica la dirección de los datos.

47. Flujo de datos discretos: • Flujos de datos continuo: • Los flujos de datos discretos: representan datos en movimiento • Los flujos de datos continuos: representan flujo de datos persistentes en el tiempo Conexiones permitidas entre componentes de un DFD

48. Paso sincrono de información Proceso B Proceso A Proceso B Proceso A Almacén Temporal Paso asincrono de informacion

49. Las diferentes conexiones que se pueden hacer entre procesos y almacenes son: Flujo de consulta Flujo de Actualización Flujo de Dialogo

50. El Flujo de Consulta: muestra la utilización de la información del almacén por el proceso para una de las siguientes acciones: • utilizar los valores de los atributos de una ocurrencia del almacén. • Comprobar si los valores de los atributos seleccionados cumplen unos criterios determinados. • El flujo de Actualización: indica que el proceso va a alterar la información mantenida en el almacén para: