Ing. Diana Patricia Bedoya Ruiz

Presentación del tema: "Ing. Diana Patricia Bedoya Ruiz"— Transcripción de la presentación:

1 Ing. Diana Patricia Bedoya Ruiz
ANALISIS Y DISEÑO. Ing. Diana Patricia Bedoya Ruiz

2 BIBLIOGRAFIA BÁSICA Sahri Lawrence Pfleeger “Ingeniería de Software. Teoría y Práctica”. Prentice Hall. Pressman. "Ingeniería del Software 5ª Edición". McGraw Hill Bernd Bruegge, Allen h. Dutoit. “Ingeniería de Software Orientado a Objetos”. Prentice Hall. 2002 Sommerville, Ian. “Ingeniería de Software” Sexta edición. Addison Wesley

3 BIBLIOGRAFIA BÁSICA Weitzenfeld Alfredo. “Ingeniería de Software Orientado a Objetos con UML, Java e Internet”.Thomson. 2004 Builes V. Carlos A. “Notas acerca de Ingeniería de Software” Ed. Artes y Letras Ltda. Marzo 2008.

4 CONTENIDO Unidad 1: Descripción del Proceso de Desarrollo de Software
Introducción a UML Unidad 3: Metodologías de Desarrollo de Software Unidad 4: Construcción de Software

5 QUÉ ES SOFTWARE?

6 Qué es software (SW)? (1) Se refiere a los programas y datos almacenados en un computador. Los programas, dan instrucciones para realizar tareas al hardware o sirven de conexión con otro software. Los datos, solamente existen para su uso eventual por un programa. Hardware: Es la parte física en el cual existe el software. El hardware abarca todas las partes físicas de un computador. (CPU, monitor, Teclado, impresora, etc…)

7 Qué es software? (2) Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos asociados que forman parte de las operaciones de un sistema de computación. Extraído del estándar 729 del IEEE IEEE: Institute Electrical Electronics Engineers (Instituto de Ingenieros Eléctricos y Electrónicos)

8 Qué es Ingeniería de Software?
La ingeniería de Software es una disciplina de ingeniería que comprende todos los aspectos de la producción de Software.

9 Qué es software? (3) SOFTWARE (SW) HARDWARE (HW)

10 CARACTERISTICAS DEL SW (Frente al Hw)
Más difícil de medir, validar, verificar: - Elemento lógico, no físico. - Desarrollado, no ‘fabricado’. No se ‘estropea’, ¡pero se deteriora! - Deterioro por ‘cambios’ Mayoritariamente ‘cerrado’: - Tradicionalmente, usado todo o nada - Tradicionalmente, poco ensamblaje de componentes

11 Una comparación con la industria de la construcción…
Motivación. Una comparación con la industria de la construcción…

12 INDUSTRIA de la CONSTRUCCION INDUSTRIA del SOFTWARE
PEQUEÑOS PROYECTOS (pintar dormitorio de los niños) (pequeño programa) 1 día x 1 hombre (autodidacta) 1 día x 1 hombre (autodidacta) GRANDES PROYECTOS (El Nido, Pekín) Varios años x (Gran proyecto sw) Varios años x Contratistas, Contratistas, constructores, Empresas de desarrollo de software, arquitectos, ingenieros software, delineantes, obreros, analistas, albañiles, operadores, auditores, programadores, aficionados al arte … usuarios …

13 PROBLEMAS EN EL DESARROLLO DEL SW
Con el avance del hardware, existe la necesidad de aplicaciones más complejas. ⇒Se produjo un cambio en la relación entre el costo hardware/software Son problemas “tradicionales”: Incapacidad para estimar tiempo, costo y esfuerzo para el desarrollo de un producto software. Asignar roles  responsabilidades en el equipo de trabajo. Falta de calidad del producto software.

14 COMUNICACIÓN COMPLEJA EN EL DESARROLLO

15 CORRECCION DE ERRORES Objetivos Plan Medición y Seguim/.
Anticipar y Corregir RETROALIMENTACIÓN

16 CONCEPTOS PARA RECORDAR
Personas: Los que trabajan Producto: Lo que se obtiene Proyecto: La pauta a seguir para desarrollar un producto Proceso: La pauta a seguir para desarrollar un proyecto

17 EJEMPLOS EN UN TRAJE. Personas: El sastre Producto: El traje
Proyecto: La secuencia de acciones para hacer un traje concreto Proceso: Lo que aprende un sastre cuando aprende a hacer trajes

18 EJEMPLOS EN UNA CENA. Personas: Empleados de una empresa de comidas
Producto: La cena que se sirve Proyecto: La secuencia de acciones de servir una cena específica Proceso: Las instrucciones de la empresa sobre cómo se sirve una cena

19 EJEMPLOS EN EL SOFTWARE. Personas: Ustedes
Producto: La aplicación que desarrollan en un proyecto particular Proyecto: Secuencia de acciones que les permite lograr un proyecto particular Proceso: ???

20 EL PROCESO DEL SW Se fundamenta en la ingeniería de software (IS)
Puede observarse a través de diversas capas: Enfoque de calidad Procesos Métodos Herramientas

21 CAPAS DE LA IS Ingeniería de software . Herramientas Métodos
Modelo de Proceso Enfoque de Calidad

22 CAPAS DE LA IS Capa de calidad Capa de proceso
Base de cualquier proceso de ingeniería La IS se basa en calidad Mejores técnicas de construcción de software Capa de proceso Capa que une calidad y métodos Desarrollo racional de la IS Conjunto de actividades y resultados asociados que sirven para construir un producto software

23 CAPAS DE LA IS Capa de Métodos - Un método incluye:
Análisis de requisitos Diseño Construcción de programas Prueba Mantenimiento - Suelen estar bastante ligados al proceso Capa de herramientas - Soporte automático o semiautomático para el proceso y los métodos - Herramientas CASE: Computer Aided Software Engineering

24 VISIÓN GENERAL DE LA IS En IS entidad = software.
Soporte para la IS: modelo de proceso. Con independencia del modelo de proceso hay tres fases genéricas: Fase de definición Fase de desarrollo Fase de mantenimiento Cada una de estas fases se descompone en un conjunto de tareas

25 FASE DE DEFINICIÓN Centrada en el QUÉ
Se identifican los requisitos del sistema y software: Información a procesar Función y rendimiento deseados Comportamiento del sistema Interfaces establecidas Restricciones de diseño Tareas principales: Planificación del proyecto software Ingeniería de sistemas o de información Análisis de requisitos

26 FASE DE DESARROLLO Cómo han de diseñarse las estructuras de datos
Centrada en el CÓMO Se definen: Cómo han de diseñarse las estructuras de datos Cómo han de implementarse las funciones Cómo han de caracterizarse las interfaces Cómo debe traducirse el diseño a un lenguaje de programación Cómo ha de validarse el producto (pruebas, verificación) Tareas principales: Diseño del software Generación del código Pruebas del software

27 FASE DE MANTENIMIENTO Corrección: Corregir los defectos
Centrada en cambios que se pueda necesitar realizar sobre un producto. En esta fase se vuelven a aplicar las fases de definición y desarrollo, pero sobre software ya existente. Pueden producirse cuatro tipos de cambio: Corrección: Corregir los defectos Adaptación: Modificaciones por cambio en el entorno externo (CPU, SO, etc.) Mejora: Ampliar los requisitos funcionales originales, a petición del cliente. Prevención: Cambio para facilitar el cambio.

28 ACTIVIDADES DE SOPORTE
Se aplican a lo largo de todo el proceso del software. Ejemplos de actividades de soporte: Documentación Gestión de configuración Seguimiento y control del proyecto de software Revisiones técnicas formales Garantía de la calidad del software Gestión de reutilización Mediciones Gestión de riesgos

29 PROCESO DEL SOFTWARE Conjunto estructurado de actividades y resultados asociados requeridos para desarrollar un sistema de software. Especificación: Establecer los requisitos y restricciones del sistema. Diseño: Producir un modelo en papel del sistema. Implementación: Construcción del sistema de software. Validación: Verificar (por ejemplo mediante pruebas) que el sistema cumple con las especificaciones requeridas. Instalación: Entregar el sistema al usuario y asegurar su operabilidad. Evolución y mantenimiento: cambiar/adaptar el software según las demandas; reparar fallos en el sistema cuando sean descubiertos

30 CARACTERISTICAS DEL PROCESO
Entendible Visibilidad Grado en que las actividades del proceso proporcionan resultados Soportable por herramientas CASE Aceptabilidad Grado en que los desarrolladores aceptan y usan el proceso Fiabilidad Capacidad de evitar o detectar errores antes de que sean defectos Robustez Continuidad del proceso a pesar de los problemas Mantenible Capacidad de evolución para adaptarse Rapidez Velocidad en que el proceso puede proporcionar un sistema a partir de una especificación

31 CONSTRUCCION DE SOFTWARE
Desarrollar software es como construir un edificio: hay mucho que hacer antes del “verdadero” trabajo... Planificar minuciosamente Elegir materiales Establecer y respetar una temporización Inspeccionar frecuentemente la obra Los errores son muy costosos de reparar La dificultad depende del tamaño Los problemas de organización y gestión son tan complicados como los problemas técnicos

32 FASES DE DESARROLLO DE UN PROYECTO
Cliente Problema Especificación Diseño Implementación Producto

33 Los errores se propagan
Cada fase puede producir errores y estos a su vez se propagan y los costos se elevan: Problema mal planteado Especificación incorrecta (del problema mal planteado) Diseño inadecuado (Especificaciones incorrectas del problema mal planteado) Implementación incorrecta (Diseño inadecuado de…) No empieces a codificar hasta que sepas lo que estás haciendo.

34 El costo del error depende del proyecto

35 Si el proyecto es importante, planifica…

36 Definir bien el problema antes de empezar

37 Asegúrate de saber cuál es el problema

38 Especificación de la solución
Describe en detalle qué hace el sistema No describe cómo se hace Debe ser correcta Debe ser completa (contempla todos los casos) Emplea diagramas y notaciones formales Debe acomodar cambios (se producirán) “Las especificaciones son como el agua, es más fácil construir sobre ellas cuando se han congelado”

39 La especificación mejora la puntería

40 Diseño de la solución Describe cómo funciona el sistema
Define la estructura del sistema: - qué componentes existen - qué papel juega cada componente - cómo se relacionan los componentes Justifica las decisiones de diseño Emplea diagramas y notaciones formales Debe acomodar cambios (se producirán) Independiente del lenguaje, el S.O. y la máquina Guía la implementación

41 El diseño templa tu fuerza

42 CALIDAD DEL SW Las metodologías mejoran la calidad del Software:
- Internamente (desarrolladores) Externamente (usuarios) DESARROLLADOR USUARIO El software debe ser: Comprensible Legible Mantenible Flexible Portable Reutilizable Comprobable el software debe ser: Correcto Preciso Fácil de usar Eficiente Seguro Robusto

43 PRINCIPIOS DE DISEÑO Descomponer el sistema en módulos interconectados
entre sí.

44 PROPIEDADES COMUNES DE LOS MÓDULOS
Un módulo es siempre un contenedor de “recursos” con las siguientes propiedades: Ocultamiento de información Cohesión (Una Clase solo se dedique a una parte del negocio) Acoplamiento (Las clases no estén amarradas entre si) IDEA  dado un módulo, distinguir entre: - qué hace y cómo lo hace - su uso y su funcionamiento MÉTODO  descomponer los módulos en dos partes: - Interfaz - Implementación

45 Interfaz Vs. Implementación
IMPLEMENTACION Parte pública, visible del módulo Determina qué servicios se ofrecen al usuario Indica el modo de uso (“instrucciones”) Orientado al usuario Parte privada, oculta del módulo Determina cómo funcionan los servicios ofrecidos Oculta detalles no relevantes para el usuario Sólo el implementador puede acceder a la implementación

46 Interfaz Vs. Implementación
Interfaz Visible para el usuario Interfaz (visible, público) Implementación (Oculto, privado)

47 Nadie sabe que contiene la caja negra…

48 Tomado de Presentaciones para el modulo de Identificación del ciclo de Vida del software, Politécnico Jaime Isaza Cadavid, Docente Claudia Alejandra Rosero.