ANALISIS DE SISTEMAS

Lic. Espinoza Robles Armando David.

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.

• 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

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

• 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

–

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

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

• 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

• 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

• 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

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

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

• 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

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

• 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

– 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

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

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

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

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

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

• 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

• 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

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

• 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

– 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 13.1.1.1 Introducción3.1.1.2 Entradas3.1.1.3 Procesamiento3.1.1.4 Salidas

3.1.2 Requisito Funcional 2-----------------------

3.1.n Requisito funcional n

• 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

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

• 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, matricialesSegún el enfoque de modelizacion:

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

• En la figura se define el contenido de una entidad definida en un diagrama E/R

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

• 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

Información

Función Tiempo

Perspectivas desde las que se puede modelizar un sistema.

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

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

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

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.

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

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

• 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

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

1Generar Pedido

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:

– 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

• 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

– 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

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

• 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 Destino Proceso Almacen Entidad ExternaExternaProceso Si Si SiAlmacen Si No NoEntidad Externa Si No No

Conexiones permitidas entre componentes de un DFD

ProcesoA

ProcesoB

Paso sincrono de información

ProcesoA

ProcesoBAlmacén Temporal

Paso asincrono de informacion

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

Flujo de consulta Flujo de Actualización

Flujo de Dialogo

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

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

Usuarios Gestionarpeticiones

Libros

Prestamos

Cliente

Gestionarpetición

Informe

Cliente

Informe a

cliente

Petición de

informe

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

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

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

• 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

Diagrama de Contexto

Diagrama 0 Gestión Sistema X

Diagrama 1 Diagrama 2

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

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