Analisis de sistemas
This presentation is the property of its rightful owner.
Sponsored Links
1 / 59

ANALISIS DE SISTEMAS PowerPoint PPT Presentation


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

ANALISIS DE SISTEMAS. Lic. Espinoza Robles Armando David. Análisis de Requisitos. Introducción al Análisis de Requisitos.:

Download Presentation

ANALISIS DE SISTEMAS

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


Analisis de sistemas

ANALISIS DE SISTEMAS

Lic. Espinoza Robles Armando David.


An lisis de requisitos

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.


Analisis de sistemas

  • 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


Analisis de sistemas

  • 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.


Analisis de sistemas

  • 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


Analisis de sistemas

  • 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.


  • Analisis de sistemas

    • 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.


    Analisis de sistemas

    • 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


    Analisis de sistemas

    • 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.


    Especificaci n de requisitos de software

    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


    Analisis de sistemas

    • 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.


    Analisis de sistemas

    • 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.


    Analisis de sistemas

    • 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


    Analisis de sistemas

    • 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.


    Analisis de sistemas

    • 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


    Analisis de sistemas

    • 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


  • Analisis de sistemas

    • 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:


  • Analisis de sistemas

    • 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:


  • Analisis de sistemas

    • 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.


  • Analisis de sistemas

    • 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.


    Analisis de sistemas

    • 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.


  • Analisis de sistemas

    • 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


    Analisis de sistemas

    • 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


  • Analisis de sistemas

    • 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.


    Analisis de sistemas

    • 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


    Analisis de sistemas

    • 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


    Analisis de sistemas

    • 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


  • Analisis de sistemas

    • 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.


    Analisis de sistemas

    • 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:


    Analisis de sistemas

    • 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.


    Analisis de sistemas

    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


    Analisis de sistemas

    • 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


    Analisis de sistemas

    Información

    Tiempo

    Función

    Perspectivas desde las que se puede modelizar un sistema.


    Analisis de sistemas

    • 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.


    Analisis de sistemas

    • 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.


    Analisis de sistemas

    • 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.


    Analisis de sistemas

    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.


    Analisis de sistemas

    • 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.


    Analisis de sistemas

    • 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.


    Analisis de sistemas

    • 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


    Analisis de sistemas

    1

    Generar Pedido

    • El nombre y el numero del proceso deben ser unicos en el DFD


    Analisis de sistemas

    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:


    Analisis de sistemas

    • 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


    Analisis de sistemas

    • 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


    Analisis de sistemas

    • 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


    Analisis de sistemas

    • 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.


    Analisis de sistemas

    • 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


    Analisis de sistemas

    Paso sincrono de información

    Proceso

    B

    Proceso

    A

    Proceso

    B

    Proceso

    A

    Almacén Temporal

    Paso asincrono de informacion


    Analisis de sistemas

    • Las diferentes conexiones que se pueden hacer entre procesos y almacenes son:

    Flujo de consulta

    Flujo de Actualización

    Flujo de Dialogo


    Analisis de sistemas

    • 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:


    Analisis de sistemas

    • Crear una nueva ocurrencia de una entidad o interrelacion existente en el almacén.

    • Borrar uno o mas ocurrencias de una entidad o interrelacion.

    • Modificar el valor de un atributo.

  • El Flujo de Dialogo: entre un proceso y un almacén representa, como mínimo, un flujo de consulta y un flujo de actualización que no tienen relación directa.


  • Analisis de sistemas

    Libros

    Usuarios

    Gestionar

    peticiones

    Prestamos

    Petición de

    informe

    Gestionar

    petición

    Cliente

    Informe

    Informe a

    cliente

    Cliente


    Analisis de sistemas

    • Como resumen, los flujos de datos tienen las siguientes características:

      • Tener un nombre representativo del contenido de la información que fluye a través de el

      • si los datos que viajan por el flujo de datos tienen distintos propósitos, entonces estos constituyen dos o mas flujos de datos.

      • El contenido de un flujo puede ser de varios tipos:

        • Elemento: es un flujo que contiene un dato elemental.

        • Grupo: es un flujo de dato discreto, con varios elementos de dato.

        • Par de dialogo

        • Multiple:


    Analisis de sistemas

    • Un flujo de datos se puede desdoblar en varios flujos o puede aparecer repetido varias veces.

  • Descomposición en niveles de un DFD

  • como el modelo de un sistema grande no se puede representar en una sola pagina mediante un DFD, la idea es representarlo por capas. Se sigue así una aproximación top down, en la que cada nivel proporciona una visión mas detallada de una parte definida en el nivel anterior. Esto genera una serie de ventajas tales como:


  • Analisis de sistemas

    • Ayuda a construir la especificación de arriba abajo

    • los distintos niveles pueden ir dirigidos a personas diferentes

    • facilita el trabajo de los analistas que pueden trabajar modelando funciones independientes del sistema.

    • Facilita la documentación del sistema

  • se comienza mediante un DFD denominado Diagrama de Contexto tiene solo un proceso que representa al sistema completo.


  • Analisis de sistemas

    • A continuación este diagrama se descompone en uno denominado diagrama de sistema, en el que se representan las funciones principales o subsistemas.

    • A continuación se descomponen cada uno de los procesos en nuevos diagramas con funciones mas simples. Así hasta que todas las funciones estén detalladas.

    • Por tanto un DFD queda definido por:

      • Diagrama de contexto diagrama de nivel 0

      • Niveles Medios: formado por el resto de diag.

      • funciones primitivas.procesos que no se explotan a nuevos DFD


    Analisis de sistemas

    Diagrama de Contexto

    Diagrama 0 Gestión Sistema X

    Diagrama 2

    Diagrama 1


    Analisis de sistemas

    • La decisión de no descomponer mas es responsabilidad del analista pero pueden definirse una serie de reglas:

      • cuando un requisito funcional se puede especificar en menos de una pagina, con lenj. De seudocodigo

      • cuando los procesos del diagrama tienen pocos flujos de datos de E/S

      • cuando al descomponer una función se pierde el significado de lo que hace la función.


    Analisis de sistemas

    • La metodología métrica recomienda analizar solo cuatro niveles de descomposición:

      • Nivel 0 : diagrama de contexto

      • Nivel 1: subsistema

      • Nivel 2: funciones de cada subsistema

      • Nivel 3. Funciones asociadas a cada uno de los eventos del sisitema

      • Nivel 4: procesos necesarios para el tratamiento de cada función.


  • Login