ELEMENTOS + ANALISTA = PRODUCTO

Transcripción

1 Tema 2.- ANÁLISIS DE SISTEMAS 1. INTRODUCCIÓN Un Sistema es un conjunto de elementos organizados para llevar a cabo algún método, procedimiento o control mediante el procesamiento de información. Los elementos de un sistema son: Software (Programas, estructuras de datos, procedimientos y documentación asociada). Hardware (Ordenador + periféricos). Personas (usuarios, operadores soft, operadores hard). Bases de Datos (Información organizada a la que accede el software). Documentación (Manuales, listados, impresos, etc que explican el uso del sistema). Procedimientos (Pasos que definen el uso de cada elemento del sistema, pasos a seguir). La ingeniería de sistemas informáticos, también llamada ingeniería de productos, es una actividad de resolución de problemas. Es el usuario quién nos impone los objetivos y define las restricciones del sistema, y a partir de aquí es el ingeniero de sistemas o analista de sistemas, quién desarrolla la solución al problema planteado, utilizando todos los elementos del sistema informático. ELEMENTOS + ANALISTA = PRODUCTO En los primeros momentos de creación de un sistema, no se tiene una visión muy clara de la función deseada, por ello, es el ingeniero de sistemas quien debe delimitar el sistema, identificando el ámbito de funcionamiento y el rendimiento deseados. Esto se hace aplicando funciones a cada uno de los elementos del sistema, y quién lo hace es el analista. En la asignación de funciones, vamos a asignar a cada elemento del sistema la función que le corresponda. A menudo se proponen y evalúan varias asignaciones. El ingeniero de sistemas también debe considerar soluciones estándar al problema (si ya existe algún sistema equivalente, o se pueden adquirir partes del producto a un tercero). Una vez consideradas las posibles asignaciones se elige una, que será la que más se adapte a nuestro sistema. 1

2 EJEMPLO: Almacén de una editorial SISTEMA: Gestión de Almacén Se quiere tener en todo momento actualizadas las existencias del almacén. Actualmente, los productos llevan una etiqueta identificativa y un código de barras. El almacén estará dispuesto por calles (A, B, C,...); en cada calle hay plantas (1, 2, 3,...) y en cada planta hay secciones (1,3,5,...; 2, 4, 6,...).Cada producto está localizable en una calle, planta y sección. ASCENSOR Tenemos que enterarnos bien de como funciona actualmente para poder optimizar al máximo Fichero A B C D E Los pedidos se sirven secuencialmente; se coge un pedido y se apartan todos los pedidos solicitados, preparándose el envío del material y emitiendo el albarán. Posibles soluciones : 1. Un operario coge el pedido y busca el material (acude a un fichero manual donde está la localización de los productos), actualiza el inventario y rellena el albarán. Elementos Personas + Documentación 2. Un operario coge el pedido, busca el material, utiliza un lector de código de barras que actualiza el inventario y lista el albarán. Elementos Personas + Documentación + Base de Datos + Hardware + Software 3. Un operario introduce los datos del pedido en el ordenador. Un robot recoge todo el material del pedido. El robot lo lleva a un lector de códigos de barras y se actualiza el inventario y se emite el albarán. 4. El operario lee el pedido a un robot con un dispositivo de reconocimiento de voz que le trae los productos. El robot tiene un dispositivo de conexión I/O con el ordenador central para recoger la información de la localización del producto y para actualizar el inventario. Cuando tiene toda la información de los productos hace una ordenación por localización con el fin de optimizar el tiempo. Emite los albaranes correspondientes. 2

3 También se debe considerar soluciones estándar al problema. Una vez consideradas las posibles asignaciones se elige una. 1. Informatizar Inventario. Informatizar localización. Albaranes de forma manual. Recogida del producto manual En estos tres casos 2. Inventario informatizado. la entrada de pedidos Localización informatizada. Albaranes informatizados. es manual. Recogida del producto manual. 3. Inventario informatizado. Localización informatizada. Albaranes informatizados 4. Todo informatizado con la entrada por escáner o reconocimiento de voz. 2. ANÁLISIS DEL SISTEMA El análisis del sistema se centra en todos los elementos del sistema, no sólo en el software. Objetivos del análisis del sistema: 1. Identificar las necesidades del cliente. 2. Evaluar la viabilidad del sistema. 3. Realizar un análisis técnico y económico. 4. Asignar funciones a los elementos del sistema. 5. Establecer restricciones de coste y tiempo. 6. Crear una definición del sistema que sea la base para todo el desarrollo posterior. Está comprobado que la inversión en tiempo y esfuerzo en el análisis de un sistema es muy importante en el proceso de desarrollo del sistema. Supone un coste del 20 al 40% del total de desarrollo del sistema. Está dirigido por el analista, y se considera un trabajo tan difícil y costoso por ser la transformación de un concepto dudoso, en un conjunto concreto de elementos tangibles que lo representan. Además durante el análisis la comunicación es excepcionalmente densa y abundan las oportunidades de mal entendimientos, omisiones y errores. También se puede dar el caso de que la percepción del sistema cambie a medida que avanza la actividad, invalidando el trabajo anterior. 3

4 2.1.- Identificación de las necesidades del cliente: El primer paso en el análisis de cualquier sistema, es la entrevista con el cliente, para identificar las necesidades. El analista junto con el cliente determinan los objetivos del sistema: La información a suministrar, La información a obtener Las funciones y rendimiento requerido. EL analista debe ser capaz de distinguir entre lo que el cliente necesita y lo que el cliente quiere. Si el producto a desarrollar se va a vender a muchos clientes, es aconsejable hacer un estudio de mercado, que dé una respuesta a las cuestiones siguientes: Cuál es el mercado potencial del producto.? Cómo es comparativamente este producto con los de la competencia.? Qué posición ocupa este producto en la línea general de producción de la compañía.? La información reunida durante el paso de identificación de necesidades es especificada en un documento conceptual del sistema, que en algunas ocasiones es preparado por el cliente antes de las reuniones con el analista Estudio de viabilidad. Todos los proyectos son realizables con recursos ilimitados y tiempo infinito, pero en condiciones reales no ocurre así. La viabilidad y el análisis de riesgo están relacionadas, si el riesgo del proyecto es alto, la viabilidad de producir software de calidad se reduce. Antes de desarrollar un proyecto, debemos considerar : Viabilidad Económica: (ANÁLISIS ECONÓMICO) Evaluación del coste del desarrollo frente al beneficio final producido. Viabilidad técnica: (ANÁLISIS TÉCNICO) Estudio de la funcionalidad, el rendimiento y las restricciones que puedan afectar a la posibilidad de realización de un sistema aceptable, es decir, si existe la posibilidad técnica de desarrollar el sistema. Viabilidad Legal: Determinación de cualquier infracción, violación o ilegalidad que pudiera resultar del desarrollo del sistema. Alternativas: Las distintas alternativas tienen diferentes las asignaciones de las funciones a los elementos del sistema, así el elegir una alternativa lleva implícitas las asignaciones. No es necesario realizar un estudio de viabilidad para sistemas en que la justificación económica es obvia, el riesgo técnico es bajo, se esperan pocos problemas legales y no existe una alternativa razonable. 4

5 El esfuerzo empleado en el análisis de la viabilidad de un proyecto, aunque lleve a la cancelación del mismo no es un esfuerzo en vano Análisis económico y técnico El análisis del coste-beneficio, ya estudiado en la viabilidad económica, es el más importante. Es muy complicado de realizar porque los criterios varían según las características del sistema, el tamaño del proyecto, la estrategia de amortización de esa inversión que lleve la empresa, etc. Además suele ocurrir que parte de los beneficios obtenidos de un sistema informático sean intangibles (mejoras de calidad, de condiciones de trabajo, etc.), por lo que son muy difíciles de estimar en cifras. El análisis técnico: comienza en la definición de la viabilidad técnica del sistema propuesto. Se deben considerar que tecnologías, métodos, algoritmos o procesos se requieren y como afecta al coste. Hay herramientas disponibles para realizar el análisis técnico, basadas en técnicas de optimización y modelos matemáticos (probabilidad, estadística, etc...), aunque no siempre es posible una evaluación analítica. 3.- MODELADO DE LA ARQUITECTURA DEL SISTEMA. Una vez asignadas las funciones del sistema informático, se crea un modelo del sistema donde queden reflejadas las interrelaciones entre los distintos elementos del sistema. Este modelo nos va a servir de base para los siguientes pasos del análisis y de diseño. Una característica común de la arquitectura de todos los sistemas es la transformación de la información del tipo: entrada - proceso salida. Hatley y Pirbhai han extendido esta visión para incluir: proceso de la interfaz de usuario y proceso de mantenimiento y autocomprobación. La documentación que acompaña a los diagramas que se han creado del sistema, describe la información de cada subsistema y el flujo de información entre ellos. Está compuesto de: 1. NARRATIVA DE MÓDULO: describe que hace el subsistema, que información procesa y como está relacionado con los otros subsistemas. Esto habrá que hacerlo para cada uno de los sistemas representado en los DFAs. 2. DICCIONARIO DE ARQUITECTURA: contiene una lista de los elementos de información que aparecen en el diagrama de flujo de la arquitectura y sus descripciones. Ejemplo : * Nombre del elemento de información: CB del libro * Descripción del elemento de información: CodLibro+CodAutor+FEdic * Tipo (Dato o Control): DATO 5

6 * Origen (Subsistema o Externo): Entidad EXTERNA Lector CB * Destino (Subsistema o Externo): Subsistema del lector de CB * Camino de comunicación: Bus de Datos 4.- ESPECIFICACIÓN DEL SISTEMA. Es el documento que describe la función y el rendimiento de un sistema informático, y las restricciones de desarrollo. Se limitan las asignaciones a los elementos del sistema, se describe la información que sirve de entrada y de salida al sistema. Va a servir como base para después hacer toda la ingeniería: * Hardware * Software * BD * Humana Resumiendo, contiene todo lo explicado anteriormente en este tema. 5. REVISIÓN DE LA ESPECIFICACIÓN DEL SISTEMA Aquí se evalúa la corrección de la definición contenida en la especificación del sistema. Esta revisión se realiza en dos partes: 1. Se realiza con el analista y el cliente comprobando que se ha definido correctamente el ámbito del proyecto, la funcionalidad, el rendimiento, los interfaces, el análisis del entorno y sobre todo hay que comprobar si los objetivos que el analista ha marcado y la percepción de los objetivos del sistema del mismo coinciden con los del cliente. Si esto no es así es que algún paso de los anteriores se ha realizado mal. 2. Tenemos que realizar la evaluación técnica de los elementos y funciones del sistema. Una vez finalizada la revisión de la especificación del sistema, se pasa al desarrollo de las ingenierías mencionadas anteriormente. Resumiendo, en este punto del desarrollo se ha conseguido : Identificar las necesidades del usuario. Determinar la viabilidad técnica y económica. Asignar las funciones y el rendimiento a los elementos del sistema. Desarrollar un modelo arquitectónico del sistema. Crear el documento de especificación del sistema. 6. ANÁLISIS DE REQUISITOS 6

7 El análisis de requisitos es un proceso de descubrimiento, refinamiento, modelado y especificación. Es la tarea de ingeniería de Software que establece un puente entre la asignación del software a nivel de sistema y el diseño del software. El análisis de requisitos facilita al ingeniero de sistemas la especificación de la función y del rendimiento del software, la descripción del interfaz con otros elementos del sistema y el establecimiento de las restricciones de diseño que debe considerar el software, por ello, se considera como un medio para valorar la calidad del software una vez construido. Tareas del análisis de requisitos: Reconocimiento del problema: saber cual es el problema y tener la misma idea de él que el cliente. El analista estudia la especificación del sistema siendo su objetivo reconocer los elementos básicos del problema tal y como los perciben el usuario y el cliente. Evaluación y síntesis: el analista se centra en que datos produce y consume el sistema, que funciones debe realizar este sistema, que interfaces están definidos y que restricciones se aplican al sistema. Modelado: vamos a elegir el tipo de modelo a utilizar. El analista va a crear modelos del sistema para entender mejor el flujo de datos y de control, el procesamiento funcional y el contenido de la información. Igual que antes, a partir de las plantillas representamos nuestro sistema en un entorno gráfico. A partir de este modelo sacaremos la especificación. Especificación: la forma ideal, si están bien todos los pasos anteriores, es que el analista desarrolle una especificación y sea revisada y aprobada por el cliente. Realmente, lo que ocurre es que se desarrolla de forma conjunta por el analista y el cliente. Se establecen los criterios de validación, que sirven para demostrar que se ha llegado a un buen entendimiento del sistema, y de la forma de implementar con éxito el software. De estas fases surgen dos documentos: * Especificación Formal de Requisitos * Manual del Usuario Preliminar: nos dice que es lo que va a ofrecer el programa Revisión: Se reúnen el analista y cliente, y se entregan los documentos creados anteriormente. En esta fase, siempre surge algún cambio que puede ser de: * Alguna función del Sistema * Datos del sistema * Rendimiento del sistema * Restricciones Este punto de análisis de requisitos es como el anterior con la comprobación del cliente. 7. PRINCIPIOS DE ANÁLISIS 7

8 En las dos últimas décadas se han desarrollado varios métodos de análisis y especificación del software. Cada método tiene su propia notación y un punto de vista únicos, pero todos tienen en común estos principios: Ámbito de información del problema. El software se construye para procesar datos: habrá una entrada, una manipulación de datos y una salida. Además de procesar datos se procesan sucesos, que son controlados por los datos de control. Un suceso representa un aspecto de control del sistema, que normalmente es un dato booleano (ej : señal de alarma). El ámbito de información contiene tres planteamientos diferentes de los datos y del control a medida que son procesados por un programa: Flujo de información. Contenido de información. Estructura de información. 1. FLUJO DE INFORMACIÓN: representa la manera de que los datos y el control cambian conforme se mueven a través de un sistema: INFO STMA. INFO STMA. INFO. TRANSFOR- TRANSFOR- ENTRADA MACION 1 INTERMEDIA MACION 2 SALIDA Ejemplo: FACTURA DE UN CLIENTE * INFORMACIÓN DE ENTRADA: Nombre del cliente * TRANSFORMACIÓN 1: Acceso a BD; de aquí sacamos CódigoCliente * INFORMACIÓN INTERMEDIA: NombreCliente, CódigoCliente,... * TRANSFORMACIÓN 2: Acceso a BD * INFORMACIÓN DE SALIDA: Factura 2. CONTENIDO DE LA INFORMACIÓN: representa los elementos de datos individuales que componen otros elementos mayores de información Ejemplo: FACTURA= Nombre del cliente + CódigoCliente + NombreProducto + CódigoProducto + PrecioProducto + etc. 3. ESTRUCTURA DE LA INFORMACIÓN: representa la organización interna de los distintos elementos de datos y de control (vectores, matrices, árboles,...) y las posibles relaciones entre las distintas informaciones. (Se debe recordar que la especificación de los tipos de datos corresponde a la fase de diseño). 8

9 7.2.- MODELADO. Hay distintas técnicas de modelado. Los métodos de análisis son realmente métodos de modelado. Creamos modelos de los sistemas para tener un mejor entendimiento del sistema a construir. El modelo debe ser capaz de modelar : la información que transformará el software, las funciones que permiten que se produzca esta transformación y el comportamiento del sistema a medida que se produce la transformación. Hay varios modelos de análisis dentro de los paradigmas: * Estructurado * Orientado a objetos PARTICIÓN. Normalmente los problemas son demasiado grandes y complejos, por ello se tiende a dividir en partes mas sencillas con relaciones entre ellas, de forma que el conjunto realice la función global. Establecemos una representación jerárquica de la función descomponiéndola en sus partes fundamentales de forma que se descubran los detalles de manera progresiva PLANTEAMIENTOS ESENCIALES Y DE IMPLEMENTACIÓN. El proceso de análisis debe ir de la información esencial al detalle de la implementación. El planteamiento esencial de los requisitos del software presenta las funciones que han de realizarse y la información que ha de procesarse, independientemente de los detalles de implementación. El planteamiento de implementación de los requisitos del software presenta algunos detalles de la implementación real de las funciones de procesamiento y de las estructuras de información. 9