Descargar la presentación
La descarga está en progreso. Por favor, espere
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.
Presentaciones similares
© 2024 SlidePlayer.es Inc.
All rights reserved.