1 / 87

ACI491: Ingeniería de Software

ACI491: Ingeniería de Software. Unidad 4: Estrategias de desarrollo. Contenidos. Introducción y aspectos generales del análisis estructurado. Flujos de datos, Diagramas de flujos de datos, Herramientas de los flujos de datos.

keene
Télécharger la présentation

ACI491: Ingeniería de Software

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ACI491:Ingeniería de Software Unidad 4: Estrategias de desarrollo

  2. Contenidos • Introducción y aspectos generales del análisis estructurado. • Flujos de datos, Diagramas de flujos de datos, Herramientas de los flujos de datos. • El diccionario de datos, Gráficos de procesos, Panorama lógico y consistencia. • Introducción y aspectos generales acerca de los prototipos. • Los usuarios con respecto a los prototipos, Impacto en la productividad. • Ventajas y desventajas del desarrollo de prototipos. • Etapas del modelo, Aspectos en el diseño físico. • Verificación y aspectos generales sobre el análisis orientado a objetos. • Diseño de sistemas, Diseño de Objetos, Aplicaciones UML.

  3. Objetivos Específicos • Identificar los diferentes modelos de análisis existentes. • Conocer y manejar las herramientas del análisis estructurado. • Conocer y manejar las herramientas del análisis orientado al objeto. • Evaluar el momento y factibilidad de la implementación de prototipos. • Conocer y manejar las herramientas orientadas al diseño de prototipos.

  4. Introducción • El objetivo del análisis estructurado es estructurar u organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada. • Se concentra en especificar lo que se requiere que haga el sistema o la aplicación. • No se establece como cumplirán los requerimientos o la forma en que implantaran la aplicación. Más bien permite que las personas observen los elementos lógicos separados de los componentes físicos. • Después de esto se puede desarrollar un modelo físico eficiente para la situación donde será utilizado.

  5. Causas para el estudio de Modelos • Costos asociados al desarrollo de software excesivamente elevados. • El comportamiento y funcionalidad del sistema actual es insatisfactorio.  Motivación de los ingenieros a desarrollar nuevos modelos de desarrollo, incluyendo prototipos, síntesis de software, software reutilizable,….

  6. Necesidades de las organizaciones • Definir las actividades necesarias en el desarrollo de un Sistema de Información. • Mantener una coherencia entre todos los proyectos de una misma organización. • Introducir puntos de control para realizar revisiones y controles de calidad, toma de decisiones. • Investigación de paradigmas o modelos de desarrollo.

  7. Aspectos generales del análisis estructurado • El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. • Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento, etc.). • Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado. • El análisis estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. • Éste análisis permite al analista conocer un sistema o proceso en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente.

  8. Aspectos generales del análisis estructurado • Los componentes del análisis estructurado • Símbolos gráficos: iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes. • Diccionario de datos: descripciones de todos los datos utilizados en el sistema. • Descripciones de procesos y procedimientos: declaraciones formales que emplean técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema. • Reglas: estándares para describir y documentar el sistema en forma correcta y completa.

  9. Análisis de Flujos de datos • Estudia el empleo de los datos para llevar a cabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas usa los diagrama de flujos de datos y los diccionarios de datos.

  10. Diagramas de flujos de datos • Un diagrama de flujo de datos (DFD) es un modelo lógico-gráfico para representar el funcionamiento de un sistema en un proyecto software. • Sus elementos gráficos son círculos, flechas, y rectángulos cerrados o abiertos. • Los cerrados representan entidades externas mientras que los abiertos describen almacenes o archivos. • Los círculos significan procesos y las flechas flujos de datos desde, o hacia, un proceso. • En un DFD también se utiliza la escritura. Los flujos, entidades externas y los almacenes se etiquetan con un nombre. Los procesos se etiquetan con un número y un verbo en infinitivo con objeto directo.

  11. Diagramas de flujos de datos • Un diagrama de flujo de datos puede ser profundizado expandiendo algunos de sus procesos en subprocesos, en este caso la etiqueta tendrá un número adicional. No hay un límite para el número de procesos. • Los diagramas derivados de los procesos principales se clasifican en niveles, los cuales son: • Nivel 0: Diagrama de contexto. • Nivel 1: Diagrama de nivel superior. • Nivel 2: Diagrama de detalle o expansión.

  12. Diagramas de flujos de datos • En el diagrama de contexto solo modela, o dibuja, el proceso principal del problema en cuestión con sus respectivas entidades. Cada proceso debe tener al menos una entrada y una salida (de datos). • En el diagrama de nivel superior se plasman todos los procesos que describen al proceso principal, o sea, éste se descompone en varios procesos. En este nivel aparecen los archivos, los cuales tienen la capacidad de almacenar o enviar datos para ser usados en los distintos procesos. • En el diagrama detalle se generan procesos provenientes del nivel anterior. • Cabe destacar que en el nivel 1 y 2 siempre los procesos deben tener las entradas y las salidas dadas en el diagrama de contexto.

  13. Diagrama de Contexto • Nivel 0

  14. Diagrama Nivel • Nivel 1

  15. Herramientas de flujos de datos • Microsoft Visio • Poseidon for UML • Visible Analyst • ProcessAnalyst de PowerDesigner • Esquemático (Schematic) • Miles más!!!

  16. Diagramas de entidad-relación

  17. Diccionario de datos • El diccionario de datos es un listado organizado de todos los datos que pertenecen a un sistema. • El objetivo de un diccionario de datos es dar precisión sobre los datos que se manejan en un sistema, evitando así malas interpretaciones o ambigüedades. • Define con precisión los datos de entrada, salida, componentes de almacenes, flujos, detalles de las relaciones entre almacenes, etc. • Los diccionarios de datos son buenos complementos a los diagramas de flujo de datos, los diagramas de entidad-relación, etc.

  18. Ejemplo de parte de un diccionario

  19. Gráficos de Procesos • La representación gráfica de procesos debe mostrar la relación existente entre las distintas partes de un proceso. • Ejemplos de diseñadores gráficos de Procesos • Microsoft Visio • JBoss jBPM

  20. Diagrama Gráfico de Proceso Proceso de Firma

  21. Representación gráfica de procesos • El gráfico representa el proceso de auditoría, desde la elección del grupo de trabajo hasta la evaluación del mismo.

  22. Consiste en realizar una visión introspectiva del sistema que se tiene actualmente en funcionamiento. De esta manera, es posible evaluar tanto sus alcances como sus limitaciones, lo que facilita mejorarle. Panorama lógico y consistencia

  23. El Proceso de Desarrollo de Sistemas ¿Qué se debe realizar? División del Producto Se fracciona el producto de modo que cada fragmento lo puede realizar un miembro del grupo de desarrollo.

  24. Pruebas ¿Que? ¿Como? División del Proceso • Implica dividir el desarrollo del sistemas en fases o etapas, y normalmente se habla de especificación, diseño y construcción. Realización

  25. Modelos de Ingeniería del software Existen algunos Modelos de Ingeniería del software:

  26. Definición de Ingeniería de Software • Se define como la disciplina tecnológica que incluye: • Desarrollo y mantenimiento sistemáticos de productos software que son desarrollados y modificados en el tiempo y con los costos estimados. • Gestión que no está dentro del dominio de la programación tradicional de un sistema.

  27. ¿Cómo se debe abordar el desarrollo de un Sistema?

  28. La Versión Ideal … A alguien se le ha ocurrido introducir Informática Requerimientos del Sistema Investigación Inicial, Identificación de Necesidades, Encuesta, etc. Estudio de Viabilidad Requerimientos del Software Análisis Especificación Diseño Preliminar y Detallado Diseño Especificación de diseño Codificación y Depuración Codificación Aplicación Test y pruebas previas a la OPERACIÓN Validación Instalación, Explotación OPERACIÓN Y MANTENIMIENTO

  29. El Cono de Helado USUARIOS Identificación Explotación de Necesidades Especificación CLIENTES Validación Esencial Especificación ANALISTA Empaquetado Física Diseño Integración DISEÑADORES Y CODIFICADORES Codificación

  30. El Modelo Real Identificación Explotación de Necesidades Especificación Validación Esencial Especificación Empaquetado Física Diseño Integración Codificación

  31. Requerimientos del Usuario Sistema Probado Encuesta Prueba de Sistema Subsistemas Análisis Probados Especificación Funcional Prueba de Necesidades de subsistema diseño Estudio Rendimiento Preliminar del HW Módulos Probados Configuración Especificación Final Diseño Prueba de del Sistema Detallado Unidad Módulos Especificación Codificados de los Codificación Programas Propuesta de Yourdon

  32. Ciclo de vida del Software • Marco de referencia que contiene: • los procesos. • las actividades y las tareas involucradas en el desarrollo. • la explotación y el mantenimiento de un producto de software. • Esto incluye la vida del sistema desde la definición de los requisitos hasta que finaliza su uso.

  33. DEFINICIONES CICLO DE VIDA: Conjunto de etapas que se han de llevar a cabo para crear, explotar y mantener un Sistema Informático. METODOS: Son las normativas que marcan las directrices que se han de seguir para llevar a cabo una tarea. Responde a la pregunta QUÉ. TECNICAS: Es un modo de representación para la solución de un problema concreto. Responde a la pregunta CÓMO.

  34. Herramientas y metodología • HERRAMIENTAS: Proporcionan un soporte automático o semi-automático para el proceso y para los métodos. • METODOLOGIA: Es un conjunto coherente de métodos y técnicas que cubren más de una etapa del ciclo de vida.

  35. Paradigmas o Modelos de desarrollo • Los paradigmas o modelos de desarrollo de Software son • estrategias de desarrollo para organizar las diversas etapas y actividades del ciclo de vida del software. • Describen las transiciones entre las etapas, especificando qué actividades desarrollar en cada momento. Selección de un modelo o paradigma específico dependiendo de la naturaleza del proyecto y/o aplicación, los métodos, las herramientas a utilizar, los controles y entregas que se requieren.

  36. Fases fundamentales • El trabajo asociado a la ingeniería de Software puede dividirse en tres fases fundamentales, independientemente del área de aplicación: • FASE DE DEFINICIÓN • FASE DE DESARROLLO • FASE DE MANTENIMIENTO

  37. Fase de Definición • Qué información ha de ser procesada • Qué función y rendimiento se desea • Qué comportamiento se espera del sistema • Qué interfaces van a ser establecidas • Qué restricciones de diseño existen • Qué criterios de validación se necesitan para esta fasedefinición.

  38. Definición … (2) • Dependiendo del paradigma o modelo se definen un conjunto específico de actividades, pero las tareas principales serán: • ingeniería de sistema o de información. • planificación del proyecto del software. • análisis de los requisitos.

  39. Fase de Desarrollo • Cómo se diseñan las estructuras de datos. • Cómo se implementara la función como unaarquitectura de software. • Cómo se caracterizarán las interfaces. • Cómo se traducirá el diseño en un lenguaje de programación. • Cómo se realizarán las pruebas

  40. Desarrollo … (2) Las tareas principales serán: • Diseño del software. • Generaciónde código. • Prueba del software.

  41. Fase de Mantenimiento • Fase centrada en el cambio que va asociado a: • La corrección de errores. • Las adaptaciones requeridas a medida que evoluciona el entorno del software. • Los cambios producidos por los requerimientos cambiantes del software.

  42. Mantenimiento … (2) • Podemos visualizar cuatro tipos de cambio: • Corrección. • Adaptación (Cambio de sistema operativo, reglas de la empresa,etc.). • Mejora. • Prevención (reingeniería).

  43. Mantenimiento … (3) Actividades a realizar • Gestión de riesgos. • Revisiones técnicas formales. • Mediciones. • Garantia de calidad del software. • Seguimiento y gestion del proyecto desoftware. • Gestión de reutilización.

  44. Fases o etapas del ciclo de vida • Si se desglosan las fases anteriores, encontramos las principales fases o etapas del ciclo de vida del software: • Identificación del sistema y definición de requerimientos • Análisis • Diseño • Desarrollo e implementación • Integración y prueba del software • Documentación • Entrenamiento y uso • Mantenimiento del software

  45. Principales Modelos de Desarrollo • Ciclo de vida en cascada o modelo tradicional (WaterFall). • Prototipo. • Modelo o ciclo de vida en espiral. • Programación Exploratoria. • Transformaciones formales. • Modelos de desarrollo orientados a objetos.

  46. Ciclo de vida en cascada o modelo Tradicional La finalidad de este modelo es establecer orden en el desarrollo de grandes productos de software. • Las diferentes etapas son procesadas de un modo lineal. • Es la base de muchos otros modelos, levemente mejorada y retocada a lo largo del tiempo. • Aún en nuestros días sigue siendo muy utilizado.

  47. Desarrollo en cascada (2) • Enfocado a especificar lo que el sistema ha de hacer (definición de requerimientos) antes de la construcción del sistema. • Define los componentes que van a interaccionar. • Gestiona la identificación de errores. • Genera un conjunto de documentos para más tarde son utilizados y permitir un buen chequeo y mantenimiento del sistema. • Reducir los costos de desarrollo y mantenimiento.

  48. Etapas del Ciclo de vida en cascada 1. Definición de requerimientos Estudio detallado de la situación actual del problema a tratar. Definición de los requerimientos que debe cumplir el nuevo sistema. 2. Análisis y diseño del sistema Descomposición modular del sistema. Descripción detallada de cada uno de los módulos y sus interrelaciones, todo ello para poder facilitar al máximo la fase de codificación.

  49. Etapas del ciclo de vida en cascada (2) 3. Implementación (codificación) Cada módulo como resultado de la fase anterior es traducido a la herramienta o lenguaje con el cual se construirá el sistema. 4. Integración y pruebas Verificación del correcto funcionamiento de cada módulo y todo el sistema una vez ha sido integrado. Detectar errores en la codificación, definiciones de requerimientos y de diseño. 5. Explotación y mantenimiento Garantizar el mantenimiento del sistema. Corrección de errores detectados en esta fase, adaptación del sistema a nuevos entornos.

  50. Etapas… ¿Cuál es la etapa que absorbe la mayoría de tiempo? La fase de explotación y mantenimiento, y es un costo adicional para el cliente.

More Related