ACI491: Ingeniería de Software

Presentación del tema: "ACI491: Ingeniería de Software"— Transcripción de la presentación:

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 Ejemplos de diseñadores 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 Panorama lógico y consistencia
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.

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 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. ¿Como? ¿Que? Pruebas 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 … Requerimientos del Sistema
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 Propuesta de Yourdon Encuesta Análisis diseño Preliminar Estudio
del HW Diseño Detallado Codificación Prueba de Unidad subsistema Sistema Requerimientos del Usuario Especificación Funcional Necesidades de Rendimiento del Sistema Configuración Final de los Programas Módulos Codificados Probados Subsistemas Probado

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 Responde a la pregunta QUÉ. Responde a la pregunta CÓMO.
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 fase definició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 una arquitectura 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 Las tareas principales serán: Diseño del software.
Desarrollo … (2) Las tareas principales serán: Diseño del software. Generación de 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 Podemos visualizar cuatro tipos de cambio:
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 Actividades a realizar Gestión de riesgos.
Mantenimiento … (3) Actividades a realizar Gestión de riesgos. Revisiones técnicas formales. Mediciones. Garantia de calidad del software. Seguimiento y gestion del proyecto de software. 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 ¿Cuál es la etapa que absorbe la mayoría de tiempo?
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.

51 Objetivos principales de cada una de las fases
Estudio del sistema actual y viabilidad del nuevo sistema. Identificación de usuarios relacionados. Estudio de su puesto de trabajo. Deficiencias actuales. Sugerencias para el futuro. Establecer los objetivos del nuevo sistema. Determinar la viabilidad proponiendo diversas soluciones. Planificación de desarrollo.

52 Objetivos … (2) 2. Análisis Especificación estructurada utilizando diferentes técnicas de diagramas para modelar el sistema nuevo, realizando también el estudio de la situación actual. 3. Diseño Establecer un conjunto de módulos e interfaces entre ellos, desglosando la especificación obtenida en la fase de análisis. Facilita la tarea de codificación, transformando los modelos lógicos a físicos.

53 Objetivos … (3) 4. Implementación Obtener un producto utilizando un lenguaje de programación y obteniendo una integración de los módulos. 5. Generación de pruebas de aceptación Especificación de un conjunto de pruebas. 6. Garantía de calidad. Obtener un producto de calidad. 7. Descripción de los procedimientos Toda la documentación necesaria para describir tanto los procesos como el producto resultante. 8. Instalación e implantación del nuevo sistema al entorno. Instalar el producto final.

54 Como se Representa: Definición de requerimientos Análisis y
Documentación Definición de requerimientos Análisis y Diseño del sistema Implementación Integración y Pruebas Explotación y Mantenimiento

55 Ciclo de vida en cascada: Desventajas
El establecimiento explícito de todos los requerimientos del sistema al principio del desarrollo. Poca flexibilidad para cambios en el sistema. No muestra interactividad entre fases. Nada hecho hasta el final. La validación de los requerimientos iniciales no se realiza hasta el final.

56 Implementación de modo ascendente
La implementación del sistema de un modo ascendente implica: primero las pruebas modulares después la de los subsistemas finalmente la del sistema completo Los problemas graves suelen encontrarse en la interfase entre subsistemas.

57 Modelo del Prototipo Utilizado principalmente en el desarrollo de sistemas donde existe un pobre conocimiento de los requerimientos o hay una rápida evolución de los mismos a través del tiempo. Captura de requerimientos  “diseño rápido” El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles al usuario. El prototipo es evaluado por el cliente y el usuario está autorizado para refinar los requerimientos del software a ser desarrollado.

58 Fases Análisis y especificación de los requerimientos del usuario.
Diseño e implementación de un prototipo. Énfasis en la interfase del usuario, equipo pequeño para minimizar los costos de comunicación. Utilización de herramientas de ayuda al desarrollo. Ejercicio del prototipo, refinamiento iterativo del prototipo. Refinamiento de los requerimientos. A partir de la fase 6 se sigue con el estándar del ciclo de vida.

59 Ciclo de vida de Prototipos Desechables
Es el siguiente: Aceptado Obtención Especificación Construcción Prototipo Ciclo de Vida Clásico Evaluación Cliente Mejora de la Especificación NO Aceptado

60 Prototipo

61 Prototipo: Desventajas
El diseño rápido indica muchas de las veces el utilizar fragmentos de programas ya existentes y herramientas que faciliten la rápida generación de programas, lo que puede llevar a: No se tiene en cuenta la calidad del software, ni su mantenimiento. Ineficiencia de los programas, utilización de recursos, utilización de lenguajes inadecuados.

62 Prototipo: ¿Para qué puede ser útil?
Cuando el cliente no sabe o no quiere revisar modelos abstractos de datos (DER o DFD) para la validación de los resultados que se van obteniendo. “No sé lo que quiero, pero lo reconoceré en cuanto lo vea”. Sistemas online, donde la importancia reside más en la interfaz de usuario que en los procesos.

63 Modelo o ciclo de vida en espiral
Se produce una cadena continua de productos, los cuales están disponibles para su examen y evaluación por parte del cliente. Provee mecanismos para asegurar la calidad del software. La reevaluación después de cada fase permite cambios en las percepciones de los usuarios, avances tecnológicos o perspectivas financieras.

64 Puntos Importantes Planificación:
Determinación de objetivos, alternativas, restricciones y elaboración del plan de desarrollo para el ciclo actual. Análisis de riesgos: Evaluación de las alternativas, identificación y resolución de riesgos. Se decide si se sigue o no con el proyecto. Ingeniería: Desarrollo del producto siguiendo un modelo: ciclo de vida o cascada, prototipo, etc... Evaluación por el cliente: Valoración de resultados

65 Modelo Espiral Determinar objetivos, Evaluar alternativas,
alternativas, restricciones identificar y resolver riesgos REVISIÓN Acuerdo Planificar las próximas Desarrollar, verificar fases

66 Ejemplo

67 Modelo o ciclo de vida en espiral: Ventajas
Intenta eliminar errores en las fases tempranas. Es el mismo modelo para el desarrollo y el mantenimiento. Provee mecanismos para asegurar la calidad del software. Trabaja bien en proyectos complejos, dinámicos e innovadores. La reevaluación después de cada fase permite cambios en las percepciones de los usuarios, avances tecnológicos o perspectivas financieras. La focalización en los objetivos y limitaciones ayuda a asegurar la calidad.

68 Modelo o ciclo de vida en espiral: Dominio
Dominio de aplicación Proyectos complejos, dinámicos, innovadores, ambiciosos, llevados a cabo por equipos internos (no necesariamente de software). Dominios de aplicación inapropiados Dominio de problemas fáciles: si el domino del problema está bien entendido y no hay mayores riesgos, es difícil y consume tiempo buscar riesgos donde no los hay.

69 Modelos de desarrollo Programación Exploratoria
Basado en el desarrollo de una implementación inicial, exponiéndola a la opinión del usuario y luego refinándola a través de muchas etapas hasta obtener un sistema adecuado. Aplicable en Sistemas en los que es difícil (o imposible) establecer una detallada especificación. (Ejemplo: Inteligencia Artificial) Forma de validación no medible, convirtiéndose en una apreciación subjetiva por parte del cliente. No puede ser utilizado en el desarrollo de grandes sistemas.

70 Modelos de desarrollo Programación Exploratoria

71 Modelos de desarrollo Transformaciones Formales
Definición formal de los requerimientos del sistema ir desarrollando metódicamente hasta llegar al sistema definitivo. Se puede demostrar la validación de los requerimientos. Ejemplos de aplicación: desarrollo de nuevos Sistemas Operativos, dispositivos médicos, desarrollo de aviónica, etc. La ambigüedad, lo incompleto y la inconsistencia se descubren y corrigen más fácilmente.

72 Ingeniería Inversa y Reingeniería
Consiste en analizar un programa y representarlo en un mayor nivel de abstracción que el código fuente. Se debe extraer información del diseño de datos, de la arquitectura y del detalle del mismo, para poder entenderlo. La Reingeniería no sólo recupera información sobre el diseño de un programa existente sino que utiliza esta información para reestructurar o reconstruir el programa existente, con vistas a adaptarlo a un cambio, a ampliarlo o a mejorar su calidad general.

73 Modelos de desarrollo Orientación a objetos
Primero se empezaron a utilizar los lenguajes de programación estructurados, que permiten la descomposición modular de los programas; esto condujo a la adopción de técnicas de diseño estructuradas y de ahí se paso al análisis estructurado. El paradigma orientado a objetos ha seguido el mismo camino: el uso de la Programación Orientada a Objetos (POO) ha modificado las técnicas de diseño para adaptarlas a los nuevos lenguajes y ahora se están empezando a utilizar técnicas de análisis basadas en esta nueva forma de desarrollar software.

74 Métodos orientados a objeto
Describen e implementan los sistemas de información desde un punto de vista más real.

75 Modelos de desarrollo Orientación a objetos (2)
La cultura implícita en los modelos usuales de ciclo de vida está basada en el “proyecto” ( y “Beneficios”), mientras que en el desarrollo orientado a objetos está basada en el “producto” (e “inversión”).

76 Términos más importantes en la orientación a objetos
Reusabilidad: Los nuevos Sistemas OO pueden ser creados utilizando otros sistemas OO ya existentes. Extensibilidad: Los nuevos sistemas OO son fácilmente ampliables, sin tener que retocar los módulos empleados en su construcción.

77 Características principales del enfoque orientado a objetos
Las características principales del enfoque orientado a objetos son, en primer lugar: Identidad: Los datos se organizan en entidades discretas y distinguibles llamadas objetos. Estos objetos pueden ser concretos o abstractos, pero cada objeto tiene su propia identidad. Dicho de otra forma: dos objetos son distintos incluso aún en el caso de que los valores de todos sus atributos coincidan. Dos manzanas pueden ser totalmente idénticas pero no por eso pierden su identidad: nos podemos comer una u otra.

78 Características principales del enfoque orientado a objetos (2)
Clasificación: Los objetos que tengan los mismos atributos y comportamiento se agrupan en clases. Todas las manzanas tienen una serie de atributos comunes: tamaño, peso, grado de maduración, y un comportamiento común: podemos coger una manzana, moverla o comerla. Los valores de los atributos podrán ser distintos para cada una de ellas, pero todas comparten los mismos atributos y comportamiento (las operaciones que se pueden realizar sobre ellas). Una clase es una abstracción que describe propiedades (atributos y comportamiento) relevantes para una aplicación determinada, ignorando el resto.

79 Polimorfismo El polimorfismo permite que una misma operación pueda llevarse a cabo de forma diferente en clases diferentes. Por ejemplo, la operación mover, es distinta para una pieza de ajedrez que para una ficha de damas, pero ambos objetos pueden ser movidos. Una operación es una acción o transformación que realiza o padece un objeto. La implementación específica de una operación determinada en una clase determinada se denomina método.

80 Herencia El concepto de herencia se refiere al compartir atributos y operaciones basada en una relación jerárquica entre varias clases. Una clase puede definirse de forma general y luego refinarse en sucesivas subclases. Cada clase hereda todas las propiedades (atributos y operaciones) de su superclase y añade sus propiedades particulares. La posibilidad de agrupar las propiedades comunes de una serie de clases en una superclase y heredar estas propiedades en cada una de las subclases es lo que permite reducir la repetición de código en el paradigma OO y es una de sus principales ventajas.

81 Etapas del Desarrollo OO
Fase Planificación y Especificación de Requerimientos Definir el Plan-Borrador. Crear el Informe de Investigación Preliminar. Definir los Requerimientos. Registrar Términos en el Glosario. Implementar un Prototipo. (opcional) Definir Casos de Uso (de alto nivel y esenciales). Definir el Modelo Conceptual-Borrador. Definir la Arquitectura del Sistema-Borrador. Refinar el Plan.

82 Etapas del Desarrollo OO (2)
Fase de Construcción: Análisis Definir Casos de Uso Esenciales en formato expandido. Refinar los Diagramas de Casos de Uso. Refinar el Modelo Conceptual. Refinar el Glosario. Definir los Diagramas de Secuencia del Sistema. Definir Diagramas de Estados. (opcional)

83 Etapas del Desarrollo OO (3)
Fase de Construcción: Diseño Definir los Casos de Uso Reales. Definir Informes e Interfaz de Usuario. Refinar la Arquitectura del Sistema. Definir los Diagramas de Interacción. Definir el Diagrama de Clases de Diseño. Definir el Esquema de Base de Datos. Fases de Implementación y Pruebas

84 Ejercicios ¿Qué es el análisis estructurado?
¿Qué es un prototipo de sistemas? ¿Cuál es la diferencia entre el método del ciclo de vida de desarrollo de sistemas y el análisis estructurado? ¿Se pueden vincular estos métodos? ¿Qué habilidades de un analista de sistemas no se aprenden en clases?

85 Tarea Para el proyecto en el que su equipo está trabajando:
Analice comparativamente las ventajas y desventajas del ciclo de vida clásico y el modelo de prototipos. ¿Utilizaría algún otro modelo? (Orientación a Objetos, Exploratorio, etc…) ¿Por qué? ¿Cuál sería la alternativa de la Corporación para el Fomento (CORFO) de Chile que sería de mayor factibilidad para emplear por su equipo como fuente de financiamiento?

86 Fuentes de información
Análisis, Diseño y Mantenimiento del Software Ian Sommerville: “Ingeniería del Software”, 7ma edición. Roger S. Presmann: “Ingeniería del Software: un Enfoque Práctico”, 5ta edición: Editorial McGraw-Hill, España James A. Senn: “Análisis y Diseño de Sistemas de Información”, Segunda Edición, Editorial McGraw-Hill, España, Eduard Yourdon: “Análisis Estructurado Moderno”. Primera Edición, Prentice Hall Hispanoamericana S.A México 1993. Kendall y Kendall: “Análisis y Diseño de Sistemas”, 3ra edición, Pearson Educación, 1997

87 Referencias en Internet
Ingeniería de software Herramientas del Análisis Estructurado Análisis Estructurado de Sistemas de Información (casos de estudio) Índice. “El analista de sistemas y el paradigma estructurado” Análisis y Diseño de Sistemas de Información. Metodología de James A. Senn Fernández “Desarrollo de sistemas de información: Una metodología basada en el modelado” Whitten, Bentley y Dittman “Systems Analysis and Design Methods”, 6/e Enlaces Web: Sistemas