introducción al análisis y diseño orientado a objetos ... · introducción concepto de sistema,...
TRANSCRIPT
Introducción al Análisis y Diseño Orientado a Objetos
Especificación de Requerimientos
Historia
Aparece el termino Ing. del SW por primera
vez
Promovió OTAN
Crisis del Software
Problemas de Desarrollo
Presupuestos
Tiempos
Daños Propiedad
Perdida Vidas
Solucionar Crisis SW
Costos elevados de propiedad y
Mtto.
Proyectos no exitosos
Fallan requerimientos
Internet
Aplicados de diseño y
desarrollo
Adaptación de aplicaciones a ambiente web
Bajo Costo SW
Metodologías Ligeras
Creciente demanda SW
Mejores técnicas de desarrollo
1955-1965 1960-1980 1985-1989 1990-1999 2000-ACT
IntroducciónConcepto de sistema, conjunto de cosas que ordenadamente relacionadas entre sí contribuyen a un determinado objeto.
Los sistemas informáticos están compuestos por ordenadores y sus periféricos. Clasificándose en:• Sistemas Hardware, son los elementos materiales, los que se pueden tocar.• Sistemas Software, los programas que gobiernan el funcionamiento del computador.
El objetivo de los sistemas informáticos es el tratamiento de la información: almacenamiento, elaboración y presentación de datos. De esta forma se automatizan determinadas acciones.
Problemática (1)
Este término fue introducido a finales de los 60 a raíz de la crisis del software.
• Planificación y estimación de costos.• ERS.• Gestión del Riesgo.• Seguimiento.• Recursos.• Alcance y Responsabilidades.• Arquitectura.
Para superar la crisis:Aparición de metodologías concretas de desarrolloConcepción de la Ingeniería del Software como disciplinaTrabajo en equipo y especialización (analistas, programadores, ...)
Problemática (2)Vuelo 501 del ARIANE-5
(4 de Junio de 1996) ejemplo sobre el daño ocasionado por
software mal diseñado es el de la explosión de la lanzadera Ariane-5, cuando a 40 segundos después de la iniciación de la secuencia de
vuelo, la lanzadera se desvió de su ruta, se partió y explotó. En el proyecto global se invirtieron 10
años de construcción y 7 mil millones de euros, lo que supuso
un duro golpe para la Agencia Espacial Europea (ESA)
Problemática (3)
A-320 de Air France(26 de junio de 1988)
Durante una presentación en elmeeting de Habsheim, cerca de
Mulhouse (Francia), un A-320 de AirFrance se estrella en el bosque, al finalde la pista. Habrá tres muertos y una
centena de heridos.Justo después, el mundo se pregunta
las causas del accidente del aviónanunciado como "el más seguro del
mundo".Una de las causas se le atribuye a unerror en el software de navegación
Problemática (4)
Mariner 1(28 de Julio de 1962)
Cómo un solo error de código le costó a la NASA 150 millones de dólaresUn guión en las instrucciones del
programa de guiado del cohete provocó la desviación del Atlas y tuvo que
enviarse un comando para su autodestrucción a los 4 minutos y 53
segundos de su lanzamiento
Problemática (5)
Definición
3
La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos (software).
• Mejorar la calidad de los productos de software.
• Aumentar la productividad y trabajo de los ingenieros del software.
• Facilitar el control del proceso de desarrollo de software.
• Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.
• Definir una disciplina que garantice la producción y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.
Ciclo de Vida
Requisitos Análisis Diseño
Implementación Integración Pruebas
Documentación Mantenimiento
Porque el AOO ?
Un proyecto software no consiste sólo en programar.
Necesitamos saber cuáles son las necesidades del cliente. Identificar los requisitos, anotarlos, analizarlos, validarlos.
Necesitamos diseñar una solución, y hacer “los planos” del software: Diseño de la arquitectura, detallado, de datos, …
Hay que asegurarse de que el software funciona:
Pruebas de unidad (a nivel de método y clase), de integración, del sistema, de aceptación, etc.
Hay que mantener el software. Documentación (de cada una de las fases), coherencia entre los productos de las distintas fases (ej. código
vs. diseños).
Análisis Orientado a Objetos Centrarse en el “qué”.
Identificar los requisitos: documentos de análisis. Entrevistas.
Identificar requisitos funcionales y no funcionales (ej.: rendimiento, fiabilidad)
Especificar los requisitos: documento de especificación de requisitos. Documento técnico. Organización y clasificación de los requisitos.
Analizar: Modelos de análisis. Estudio de posibles escenarios: casos de uso.
Otras técnicas: fichas CRC, orientados al flujo, etc.
Validar.
Análisis Orientado a Objetos El análisis y diseño orientado a objetos (ADOO) es un enfoque
de análisis en ingeniería de software que modela un sistema
como un grupo de objetos que interactúan entre sí1. Este
enfoque representa un dominio absoluto en términos de
conceptos compuestos por verbos y sustantivos, clasificados de
acuerdo a su dependencia funcional. Todo sistema de
información requiere de artefactos o componentes (clases) para
llevar a cabo tareas, es de gran importancia dentro de la
ingeniería de software tener un buen "análisis y diseño" para un
mejor desarrollo, que conlleva a qué tan "escalable" sea un
sistema de información.
Análisis Orientado a Objetos En este método de análisis y diseño se crea un conjunto de
modelos utilizando una notación acordada como, por ejemplo,
el lenguaje unificado de modelado (UML).
ADOO aplica técnicas de modelado de objetos para analizar los
requerimientos para un contexto (por ejemplo, un sistema de
negocio, un conjunto de módulos de software) y para diseñar
una solución para mejorar los procesos involucrados.
Análisis Orientado a Objetos No está restringido al diseño de programas de computadora,
sino que cubre sistemas enteros de distinto tipo. Las
metodologías de análisis y diseño más modernas son "casos de
uso" guiados a través de requerimientos, diseño,
implementación, pruebas, y despliegue.
El lenguaje unificado de modelado se ha vuelto el lenguaje de
modelado estándar usado en análisis y diseño orientado a
objetos.
Análisis Orientado a Objetos – Modelos de Analisis
Análisis Orientado a Objetos
17
Modelos de Análisis. Basado en Escenarios.
Modelo de
Análisis: Modelo
Modelo Funcional:
Modelo
Modelo de
Objetos: Modelo
Modelo
Dinámico: Modelo
Modelo funcional: casos de uso y escenarios.
Modelo de Objetos: diagramas de clases y objetos.
Modelo dinámico: diagramas de secuencia,…
ESPECIFICACION DE REQUERIMIENTOS
Cada uno de los modelos del proceso de desarrollo del softwarepropuestos, incluye actividades que apuntan a la captura derequerimientos.
Por lo tanto, la comprensión del propósito y la función del sistemacomienza con un atento examen de los requerimientos.
Definición de Requerimiento
Cuando el Cliente solicita que se desarrolle un sistematiene algunas nociones de lo que debe hacer.
Por está razón cada sistema basado en software tiene un propósito, usualmenteexpresado con algo que el sistema debe hacer.
Un Requerimiento “es una característica del sistema o una descripción de algoque el sistema es capaz de hacer con el objeto de satisfacer el propósito delsistema”.
Definición de Requerimiento
Es decir, los requerimientos son lo que losclientes/usuarios esperan que haga el sistema.
Los analistas, por lo tanto, deben entender el problema de los usuarios en su culturay con su lenguaje y construir el sistema que resuelve sus necesidades.
En si el objetivo del análisis de requerimientos es resolver el problema.
Requerimientos v/s Diseño
Los requerimientos definen el Qué (el problema) delsistema.
El Diseño define el Cómo (la solución).
Durante el análisis de requerimientos no se consideran descripcionesespecificas de la implementación como requerimientos, a menos que elcliente lo pida (Ej.: bases de datos especificas, lenguajes deprogramación, etc.).
Los requerimientos, por lo tanto deben centrarse en el cliente/usuario yel problema.
Documentos de Requerimientos
Existen dos documentos que emanan del análisis derequerimientos:
Definición de requerimientos
Es un documento que debe escribirse en términos que el cliente pueda entender. Esdecir, este documento es un listado completo de todas las cosas que el cliente esperaque haga el sistema propuesto.
Este documento es escrito en forma conjunta por elcliente y el desarrollador.
Documentos de Requerimientos
Especificación de requerimientos
Documento que reitera la definición de los requerimientos en los términos técnicosapropiados para el desarrollador del diseño de un sistema.
Es la contrapartida técnica al documento de definición de requerimientos y es escrito porlos analistas de requerimientos.
A veces un único documento puede servir para ambos propósitos, lo que lleva a unentendimiento común entre clientes, analistas de requerimientos y diseñadores.
Pero a menudo se necesitan ambos documentos.
Documentos de Requerimientos
Es muy importante, que al usar ambos documentos exista uncorrespondencia directa entre cada requerimiento del documento dedefinición y aquellos documentos en la especificación.
Esto para que la visión del cliente este unida a la de los desarrolladores (estose logra gracias a la gestión de configuración).
Clasificación de Requerimientos
Según el Tipo los requerimientos se clasifican en:
Requerimientos funcionales.
Requerimientos no funcionales.
Requerimientos del Dominio.
Según a quien van dirigidos se clasifican en:
Requerimientos del Usuario.
Requerimientos del Sistema.
Clasificación de Requerimientos
Requerimientos funcionales
Describen la funcionalidad o los servicios que se espera que el sistema proveerá.Dependen del tipo de software, del sistema que se desarrollo y de los posiblesusuarios.
Cuando se expresan como Requerimientos del usuarios, se definen de forma general.
Cuando se expresan como requerimiento del sistema describen con detalle la función deéste, sus entradas y salidas, excepciones, etc.
• Ejemplo de Requisitos Funcionales:
Como ejemplo le presentamos los requerimientos funcionales de una cafetería:
• El cliente vera los productos que están disponibles
• Los precios de los alimentos serán visibles
• Se pedirá los alimentos en un lugar específico (tanto empaquetados como por preparar) y pagaran en el mismo lugar (caja)
• Los alimentos empaquetados se entregaran en la caja
• Los alimentos a preparar se pedirán en su lugar asignado
• Fruta, gelatinas,etc.
• Tortas, hamburguesas, etc.
• Los clientes recibirán sus productos una vez terminado el proceso
• Se podrá pedir el servicio de calentamiento para alimentos
• El administrador podrá ver las ganancias
• Los vendedores entregaran los alimentos empaquetados
• Los ayudantes de los cocineros entregaran los alimentos para preparar
• El administrador se encargara de los proveedores
Clasificación de Requerimientos
Requerimientos no funcionales
Son los requerimientos que no se refieren directamente a las funcionesespecíficas que entrega el sistema, sino a las propiedades emergentes deéste, como la fiabilidad, la respuesta en el tiempo y la capacidad dealmacenamiento.
Muchos requerimientos no funcionales se refieren al sistema como un todo másque a rasgos particulares del mismo.
A menudo son mas críticos que los funcionales. Mientras que un incumplimientode un requerimiento funcional degrada el sistema, el de un requerimiento nofuncional del sistema lo inutiliza.
Clasificación de Requerimientos
Requerimientos no funcionales se clasifican en:
Del producto: especifican comportamiento del producto. Ej.: de desempeño en larapidez de ejecución del sistema, cuanta memoria se requiere; los de fiabilidad quefijan la tasa de fallas para el sistema sea aceptable, los de portabilidad y deusabilidad.
Organizacionales: se derivan de las políticas y procedimientos existentes en laorganización del cliente y del desarrollador. Ej.: estándares en los procesos quedeben utilizarse, requerimientos de implementación como los lenguajes deprogramación o el método de diseño a utilizar.
Clasificación de RequerimientosRequerimientos no funcionales
Externos: cubre todos los requerimientos que se derivan de los factores externos al sistema yde su proceso de desarrollo. Ej.: requerimientos de interoperabilidad, requerimientos legales,requerimientos éticos.
Un problema común con los requerimientos no funcionales es que algunas veces son difíciles deverificar.
De forma ideal los requerimientos no funcionales se deben expresar de manera cuantitativautilizando métricas que se puedan probar de forma objetiva. En la práctica, es difícil. El costo esmuy alto.
Clasificación de Requerimientos
Requerimientos del dominio
Se derivan del dominio del sistema más que de las necesidades especificas del usuario.
Son importantes debido a que a menudo reflejan los fundamentos del dominio de laaplicación. Si estos no se satisfacen es imposible que el sistema trabaje de formasatisfactoria.
Estos se expresan utilizando un lenguaje especifico del dominio de la aplicación que amenudo es difícil de comprender. Ej.: operación para calcular desaceleración del tren,para un sistema de control de trenes.
Proceso: Ingeniería de Requerimientos
Estudio de factibilidad
Obtención y Análisis de
Requerimientos
Especificación de
Requerimientos
Validación de
Requerimientos
Informe de
factibilidad
Actividades
Especificación de
Requerimientos
Documentode
Requerimientos
Modelo delSistema
Artefactos
• Proceso de Ingeniería de Requerimientos
Participación
del usuario
Estudio de
factibilidad
Obtención y
análisisEspecificación Validación
Requerimientosdel usuario
Retroalimentacióndel usuario
Especificaciónde requerimientos
Modelos a validarpor el usuario
Modelo derequerimientosConocimiento
Necesidad de másconocimiento
Resultado devalidación
Verificación de
Requerimientos
Comprensión
del dominio
Recolección de
Requerimientos
Priorización
Resolución de
conflictos
Clasificación
Especificación de
Requerimientos
DOCUMENTO DE
REQUERIMIENTOS
PROCESO DE OBTENCION
Y ANÁLISIS DE
REQUERIMIENTOS
