Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Bibliografía
Análisis y Diseño de Sistemas
Material Bibliográfico
Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur
Clase 4 – Modelos de Procesos Lic. María Mercedes Vitturini [
[email protected]]
Capítulos
Análisis Estructurado Moderno – Edward Yourdon.
2 - 3 - 9 - 10 - 11 12 - 13 y 14
Fundamentals of Software Engineering - Carlo Ghezzi.
1-2-3–4y7
Fundamentos de Base de Datos - Abraham Silberschatz
2y7
The RAISE Method
Sólo el capítulo 1
The RAISE Specification Language
Todo
El Proceso Unificado de Desarrollo de Software Jacobson, Booch, Rumbaugh
Sólo el capítulo 7
Object Oriented Modeling and Design - Rumbaugh
3-4-5-6-7-8 y9
1er. CUATRIMESTRE 2006 Análisis y Diseño de Sistemas - Clase 4
Repaso
Metodología z
Un modelo de proceso define el orden en el cual se realizan las actividades para construir software. z z
z
z
z
¿Cuánto tiempo debemos seguir haciendo una actividad? z
z z z z z z z
Análisis y Diseño de Sistemas - Clase 4
4
Personalizar el modelo de proceso
En el proceso de desarrollo de software se pueden distinguir siguientes actividades: z
Para encarar proyectos de desarrollo de software de medina/gran escala requiere de una metodología.
3
Repaso z
El orden de las distintas actividades Un marco para administrar proyectos, estimar recursos y controlar el proyecto.
¿Qué debemos hacer a continuación?
Es un proceso intelectual. El software se caracteriza por su alta inestabilidad. Análisis y Diseño de Sistemas - Clase 4
El modelo o metodología de desarrollo provee: z
Un modelo de proceso está compuesto por varias etapas. El proceso de producción de software establece las actividades para construir, entregar y hacer evolucionar al producto de software. Características del proceso de desarrollo de software: z
2
z
Análisis y definición de requerimientos. Diseño de sistemas. Diseño de programas. Implementación de programas. Pruebas unitarias. Pruebas de integración. Entrega del sistema. Mantenimiento. Análisis y Diseño de Sistemas - Clase 4
No existen dos proyectos iguales. Se debe personalizar el proceso para cada proyecto. z z
5
Depende del tipo de producto. Depende del tipo de proyecto.
Análisis y Diseño de Sistemas - Clase 4
6
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
1
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Personalizar el Proceso z
Personalizar el Proceso z
Depende de la relación equipo de desarrolloproducto: z z
z
z
Una consultora que desarrolla sistemas a medida. El departamento de sistemas que busca una solución para un área de la empresa. Una empresa de software que desarrolla una aplicación de uso general.
Análisis y Diseño de Sistemas - Clase 4
Depende del producto. Los productos por su parte tampoco son iguales: z z z
z
Un sistema de control de vuelos de un aeropuerto. Un sistema de gestión de ventas de pasajes aéreos. Un sistema de juegos en red. Un sistema operativo.
Las empresas definen los estándares para los entregables de cada etapa y métodos para cada etapa.
7
Análisis y Diseño de Sistemas - Clase 4
Modelo CASCADA
Modelo de CASCADA (MPC) z z
Las tareas se organizan en cascada, una después de la otra. El salida (output) de una etapa es la entrada (input) de la siguiente etapa. z z
z
Creado en los años ’70 en un proyecto de defensa de EEUU. Se usó para las primeras aplicaciones es crítica y compleja.
No incluídas originalmente
Las etapas a su vez se pueden dividir en actividades ejecutadas concurrentemente. Análisis y Diseño de Sistemas - Clase 4
9
Análisis y Diseño de Sistemas - Clase 4
z z
z
Depende de cada desarrollo. Se evalúan costos y beneficios de la aplicación. Cuanto más conocimiento se tenga del problema mejor. Sin embargo, no se le puede destinar demasiado tiempo. Incluye: z z z
z
z z
Una definición general del problema. Soluciones alternativas y beneficios esperados. Recursos requeridos, costos, tiempos, fechas de entrega para cada solución alternativa.
Salida: documento o estudio de factibilidad Análisis y Diseño de Sistemas - Clase 4
10
Ejemplo: Venta Electrónica de Material Bibliográfico (VEMB)
MPC – Estudio de Factibilidad z
8
11
Objetivo: proveer el servicio venta de libros vía Internet. Descripción: z La funcionalidad será de uso público, sin embargo se requiere que los clientes compradores se registren previamente. z Los clientes podrán consultar el catálogo de libros disponibles. Para ello contarán con mecanismos de búsqueda por ISBN, autor, título o área de interés. Opcionalmente podrán efectuar pedidos de compra por uno más libros. z El cliente podrá cancelar el pedido de compra en cualquier momento antes de confirmarlo. z Los pedidos de compras confirmados serán remitidos al final de cada día al departamento de ventas y notificados de su recepción al cliente vía mail. Análisis y Diseño de Sistemas - Clase 4
12
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
2
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
MPC – Análisis de requerimientos y especificación z z z
MPC – Análisis de requerimientos y especificación z
Identificar las calidades requeridas por la aplicación: funcionales y no funcionales. Identificar qué? y no cómo?. Salida: documento de especificación de requerimientos. z z z z
z z z
z
z z
13
z z z
z
z
Describir módulos y su relaciones. Especificar interfaces.
z
z z
z
z
z
Escribir programas en lenguajes de programación. Salida: conjunto de módulos implementados y probados. Se deben adoptar convenciones de programación. Según las necesidades se pueden incluir revisiones de código (debbuging y testeo y chequeos de performance). Análisis y Diseño de Sistemas - Clase 4
z z
Testeo de integración. Testeo del usuario. Testeo de volumen.
z
Se definen el conjunto de datos de prueba y el plan de prueba. Análisis y Diseño de Sistemas - Clase 4
14
16
MPC – Entrega y Mantenimiento
Realiza el ensamblaje de la aplicación. Se hace el testeo con usuarios reales (alfa test). z
z
15
MPC – Testeo de sistema e integración z
Análisis y Diseño de Sistemas - Clase 4
z
Las composición de las salidas son fijadas por la organización, de acuerdo a la metodología utilizada. Análisis y Diseño de Sistemas - Clase 4
Requerimientos funcionales. Requerimientos no funcionales. Requerimientos en el proceso de desarrollo, procedimientos de prueba, prioridades de funciones...
MPC – Codificación y testeo de módulos
Salida: documento de especificación de diseño. Descripción de la arquitectura. Dividir el sistema en módulos. Diseño preliminar y diseño detallado z
Datos - funciones - Control (comportamiento)
La salida debe identificar: z
MPC – Diseño y especificación z
Descripción en distintos niveles de abstracción. Separar en partes analizables. Modularidad horizontal: distintas visiones del software: z
Para verificar con el cliente. Documento de especificación: conciso, completo, entendible, no ambiguo y fácil de modificar. Plan de pruebas. Versión preliminar del manual del usuario. Análisis y Diseño de Sistemas - Clase 4
Separar, abstraer y particionar (principios de la ISW).
z
17
Se instala para usuarios seleccionados (beta test) y luego a clientes. El mantenimiento incluye todas las tareas luego del desarrollo. El costo de mantenimiento en muchos casos representa más del 60% del costo del producto. El 42% de los costos de mantenimiento se atribuyen a cambios en los requerimientos. Análisis y Diseño de Sistemas - Clase 4
18
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
3
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Sobre el mantenimiento z
z
z
MPC – Otras actividades z
El análisis de requerimientos es una fuente de serios problemas, especialmente en aplicaciones conducidas por el usuario. Muchos de los errores no se encuentran hasta que el sistema se entrega, esto es un problema ya que cuanto más tarde se encuentra un defecto más “caro” resulta corregirlo. El cambio es una propiedad intrínseca del software, pero es difícil incorporar. Análisis y Diseño de Sistemas - Clase 4
z z
z z
z
z
Análisis y Diseño de Sistemas - Clase 4
z
Problemas: z
z
Introduce disciplina al proceso. Pospone la implementación hasta que los objetivos estén claros. Es el paradigma más antiguo y más extensamente usado en ingeniería de software. Impone puntos de control claros. Análisis y Diseño de Sistemas - Clase 4
z z z z z 21
Análisis y Diseño de Sistemas - Clase 4
z
Algunas situaciones donde hoy podría optarse por aplicar el modelo de cascada incluyen: z z z
22
Motivación: las fallas de la primer versión de una aplicación inevitablemente conduce a la necesidad de rehacerla. HACERLO DOS VECES.
Problemas medianos/chicos. Problemas con requerimientos estables. Reingeniería de sistemas.
z
z
Análisis y Diseño de Sistemas - Clase 4
Introduce rigidez. Difícil la estimación de recursos. Es lineal y los proyectos reales raras veces siguen un modelo lineal. El usuario necesita conocer todos sus requerimientos. No provee anticipación al cambio. Basado en documentación. Parece burocrático. Los costos se trasladan al mantenimiento fácilmente. El cliente debe tener paciencia hasta ver resultados.
Modelos de Procesos Evolutivos
MPC – Ejemplos de aplicación z
20
MPC – Conclusiones
Contribuciones:
z
Definición de estándares. Tratamiento con recursos (personas).
19
z
z
Walk-through. Validación: la especificación se corresponde con los requerimientos. Verificación.
Administración z
Es un modelo conducido o guiado por la documentación.
z
Documentación. Control de calidad z
MPC – Conclusiones z
Dependiendo del tipo de desarrollo se pueden incorporar nuevas actividades (personalizar el proceso)
23
z
En la primer versión: prototipo.
z
En la segunda versión: cascada.
Problema: gap entre la definición de requerimientos y la distribución de la aplicación. Solución: aproximaciones flexibles, evolutivas o incrementales. Análisis y Diseño de Sistemas - Clase 4
24
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
4
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Modelos de Procesos Evolutivos z
z z
z
z
Entregar algo. Medir el valor agregado. Ajustar diseño y objetivos.
z
z
z
Mini-procesos de cascada. Propotipo evolutivo.
Requiere herramientas. Análisis y Diseño de Sistemas - Clase 4
Puede considerarse un modelo por si mismo. Objetivo: z
Cuidado: que no sea code & fix. Alternativas: z
z
z
Estrategia: z
z
Modelo de PROTOTIPO (MPP)
De la revisión de cada etapa puede resultar que se necesite revisar los requerimientos de las etapas anteriores.
25
Modelo de Prototipos
Análisis y Diseño de Sistemas - Clase 4
Comienza con la recolección de requisitos o requerimientos del sistema. z
z
27
Desarrollador y cliente definen los objetivos globales, identifican requisitos y áreas que requieren mayor definición.
Se elabora un diseño rápido, centrado en los aspectos del software que son visibles a los usuarios (enfoques de entrada y formatos de salida). Análisis y Diseño de Sistemas - Clase 4
28
Modelo EVOLUTIVO INCREMENTAL (MPEI)
MPP – Problemas del modelo Desventajas: z El cliente ve el prototipo y lo confunde con el sistema real. No entiende la necesidad de volver a hacerlo. z El equipo de desarrollo toma decisiones rápidas para poder construir el prototipo, que más tarde son difíciles de revertir (por ejemplo el lenguaje de programación). Análisis y Diseño de Sistemas - Clase 4
26
Modelo de Prototipos z
Análisis y Diseño de Sistemas - Clase 4
Investigación repetida de requerimientos y diseño. Reducir el riesgo que la aplicación no se ajuste a las necesidades del cliente.
29
z
Es un modelo cuyas etapas consisten de incrementos expandidos de un producto de software operativo, conducidos por la evolución determinada según la experiencia operativa.
z
Los incrementos se distribuyen a medida que se completan. Incremento integrado: es una unidad de software autocontenida que realiza algún propósito útil.
z
Análisis y Diseño de Sistemas - Clase 4
30
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
5
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Modelo Evolutivo Incremental
MPEI – Ejemplo z
Incremento 1 Análisis
Diseño
Código
Análisis
Entrega del 1er. incremento
Prueba
Diseño
Código
Prueba
Incremento 2
Un ejemplo de desarrollo incremetal para un procesador de textos: z
Entrega del 2do. incremento
z z
Análisis Incremento 3
Diseño
...
Código
Incremento 1: administración de archivos básicos y producción de documentos. Incremento 2: funciones de edición más sofisticadas. Incremento 3: corrección gramatical y ortográfica.
Prueba Entrega del 3er. incremento
z
Al primer incremento se lo denomina producto esencial.
Tiempo calendario Análisis y Diseño de Sistemas - Clase 4
31
Modelo Espiral (MPE) z
Análisis y Diseño de Sistemas - Clase 4
Modelo Espiral
El modelo combina las actividades del desarrollo con la gestión del riesgo, para minimizar y controlar el riesgo. Riesgo: circunstancias potencialmente adversas que pueden perjudicar el proceso de desarrollo y la calidad de los productos. z Administración del riesgo: disciplina cuyos objetivos son manejar y eliminar los ítems de riesgo del software antes que se transformen en amenaza. Es cíclico. Es un metamodelo.
z
z
Análisis y Diseño de Sistemas - Clase 4
33
Primera etapa: z
z
z
z
32
z
Identifica los objetivos de la porción del producto bajo consideración, en términos de calidades a lograr. Plantear alternativas: comprar, diseñar, o reusar y las restricciones a esas alternativas.
Segunda etapa: z
z
Se evalúan las alternativas y se identifican las áreas de riesgo potencial. La evaluación del riesgo puede requerir distintas clases de actividades a ser planificadas (simulación, prototipeo, etc.). Análisis y Diseño de Sistemas - Clase 4
34
Análisis y Diseño de Sistemas - Clase 4
36
Modelo Espiral z
Tercera etapa: z
Consiste del desarrollo y verificación del próximo nivel del producto. El proceso está conducido por el riesgo. z
z
Si los requerimientos se entienden bien, podría pensarse el modelo de cascada, como un modelo de espiral de una sola vuelta.
Cuarta etapa: z
Se revisan los resultados para planificar la próxima vuelta de espiral. Análisis y Diseño de Sistemas - Clase 4
35
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
6
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Modelo Espiral
Modelo Espiral
Ventajas z Constituye un enfoque realista del desarrollo de sistemas de software de gran escala. En la medida que progresa, desarrollador y cliente comprenden y manejan mejor los riesgos. z Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida de cascada, pero incorpora el marco de trabajo iterativo que refleja mejor el mundo real. z Considera los riesgos técnicos en todas las etapas, y aplicado adecuadamente, logra reducirlos. Análisis y Diseño de Sistemas - Clase 4
Desventajas: z Requiere de habilidades para la evaluación del riesgo, si un riesgo importante no se descubre pierde eficacia. z No existe demasiada experiencia en su uso.
37
Modelo Transformacional z
z
z
38
Modelo Transformacional z
Basado en especificaciones formales: el desarrollo de software como una secuencia de pasos que gradualmente transforma una especificación en implementación.
Etapas: z z
z
Se deben transformar requerimientos informales en especificaciones formales: métodos de especificación formal. Pretende reducir errores automatizando pasos del desarrollo. Análisis y Diseño de Sistemas - Clase 4
Análisis y Diseño de Sistemas - Clase 4
z
z
39
Modelo Transformacional
Especificación de requerimientos Optimización
Busca reusar componentes y construir componentes reusables. Los cambios se hacen en la especificación. Todo queda documentado. Garantiza resultados correctos. Análisis y Diseño de Sistemas - Clase 4
40
Modelo Transformacional Ejemplos: z Transformaciones automáticas para implementaciones recursivas en no recursivas. z Optimizadores de consultas.
Análisis y Diseño de Sistemas - Clase 4
41
Análisis y Diseño de Sistemas - Clase 4
42
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
7
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Modelo Transformacional
Resumen Modelo
Desventajas: z El desarrollo de modelos formales es caro y lleva tiempo. z Se requiere de estudios detallados y personal capacitado. z Es difícil utilizar el modelo como medio de comunicación con el cliente.
Análisis y Diseño de Sistemas - Clase 4
No es un modelo de desarrollo
Cascada
Documentación
Extremadamente rígido Tiene problemas de debugging e ntegración
Espiral
Riesgo
Metamodelo
Análisis y Diseño de Sistemas - Clase 4
44
Temas de la clase de hoy
Modelo Conducido
Transform acional
Observaciones
Prueba y error
43
Resumen ... Evolutivo
Conducido
Cod-Fix
Incremento
z
Observaciones
z
Con sólo implementación evolutiva, se corre el riesgo de descubrir tarde los errores de diseño. Utiliza prototipos Requiere herramientas de prototipeo
z z z
z
Cascada. Evolutivo. Transformacional. Espiral
Bibliografía z
“Fundamentals of Software Engineering”. Carlo Guezzi. Capítulos 7.
z
Especificación Aplicable a problemas pequeños y críticos. Utiliza técnicas de IA Análisis y Diseño de Sistemas - Clase 4
Ciclo de Vida.
Lecturas sugeridas. z
45
“Ingeniería del Software” – Un enfoque Práctico” R.Pressman. Capítulo 2. Análisis y Diseño de Sistemas - Clase 4
46
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
8