Contenidos. Tema 3. El Método de desarrollo. El Proceso Unificado. Objetivos del tema. 3.1 Métodos actuales de desarrollo OO

Transcripción

1 Tema 3. El Método de desarrollo. El Proceso Unificado Miguel A. Laguna Contenidos 3.1 Métodos actuales de desarrollo OO Concepto de Método y Proceso Generaciones de métodos OO 3.2 El Proceso Unificado de Desarrollo o Unified Process UML no es suficiente Características del Proceso Unificado 3.3 Fases y disciplinas (o flujos de trabajo) Fases y puntos de control Disciplinas (flujos de trabajo) Artefactos 3.4 La fase de nicio (nception) 3.5 La fase de Elaboración 3.6 Las fases de Construcción y Transición Objetivos del tema Conocer las tendencias actuales en metodología de desarrollo y los esfuerzos de estandarización Conocer la propuesta del MAP: Métrica 3 Aprender los principios del Proceso Unificado de Desarrollo Aprender la diferencia ente fase y disciplina elacionar las técnicas de modelado de UML con las distintas fases y disciplinas del Proceso Unificado 3.1 Métodos actuales de desarrollo OO Concepto de Método Generaciones de Métodos OO: Métodos de primera y segunda generación Métrica 3, Procesos Ágiles y Proceso Unificado 1

2 Concepto de Método (o Metodología) esulta necesario establecer un enfoque sistemático y disciplinado para llevar a cabo un desarrollo software Definiciones: Una metodología de ingeniería del software es un proceso para producir software de forma organizada, empleando una colección de técnicas y convenciones de notación predefinidas (James umbaugh et al.) Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software (Mario Piattini et al.)...concepto de Método El desarrollo de un sistema se puede explicar también como: Una secuencia de modelados que ayuda a construir, a partir de la realidad, uno o varios modelos, derivados unos de otros, con el objetivo de lograr un modelo final o sistema. Y entonces: Un método es una guía que define las reglas de paso de un modelo a otro para evolucionar progresivamente hasta el modelo final. Modelado Lenguaje de Programación EALDAD Modelos Lenguaje de especificación MPLEMENTACÓN Los modelos son representaciones semánticas simplificadas de un sistema para analizarlo y comprenderlo a fin de diseñarlo mejor. Generaciones de Métodos OO Años 60 y 70: COBOL, FOTAN, C Métodos de análisis y diseño estructurados Años 80 y primeros 90: C++, Smalltalk, Ada Métodos OO de primera generación: OMT, Jacobson Finales de los 90: Java UML Métodos OO avanzados, Proceso Unificado 2

3 Métodos estructurados y......métodos orientados a objetos Análisis Diseño mplementación POCESOS DFD STD POGAMA Análisis Diseño mplementación DATOS Clases DE ELACONAL TABLAS Métodos OO (antes de UML) OMT (Object Modeling Technique) Métodos dirigidos por los datos (data-driven) - OMT (umbaugh et al. 1991) - FUSON (Coleman et al. 1994) Métodos dirigidos por responsabilidades (responsability-driven) - DD (Wirfs- Brock et al. 1990) - OBA ( ubin y Goldberg 1992) Métodos dirigidos por casos de uso (use case-driven) - OOSE/Objectory(Jacobson et al. 1992) Métodos dirigidos por estados (state-driven) - Shlaer y Mellor ( Shlaer y Mellor 1992) Desarrollado en General Electric a finales de los 80 El método OO más difundido antes de UML/UP Aunque tiene cuatro fases definidas, se centra de una forma especial en el análisis Presenta una continuidad respecto a las métodos estructurados El libro Object-Oriented Modeling and Design escrito por umbaugh et al. en 1991 es un best-seller mundial: umbaugh, James, Blaha, Michael, Premerlani, William, Eddy, Frederick, Lorensen, William. Modelado y Diseño Orientados a Objetos. Metodología OMT. 2ª eimpresión. Prentice Hall

4 ... OMT Método de Booch de clases de estados DFDs Es uno de los más conocidos En su versión de 1993 este método cubre las fases de análisis y diseño dentro de un desarrollo OO. Define una gran cantidad de símbolos para representar las distintas decisiones de diseño. Se definen dos tipos de procesos que describen los niveles en un desarrollo orientado al objeto: Macro procesos Micro procesos Booch, G. "Object-Oriented Analysis and Design with Applications", 2nd edition. Benjamin Cummings, Método de Booch... Método de Booch Diferencia: Modelos estático y dinámico Modelos lógico y físico Modelo dinámico Modelo Estático Modelo Lógico Estructura de clases Arquitectura de módulos Modelo Físico Estructura de objetos Arquitectura de procesos Clase Nombre de la clase Atributos Métodos() {restricciones} Nombre de la clase parametrizada Clase parametrizada Argumentos formales Clase utilidad Nombre de la clase utilidad Nombre de la clase instanciada Atributos Métodos() Argumentos actuales 4

5 OOSE (Jacobson)...OOSE: Casos de Uso Es un método que se basa en la idea de los casos de uso como forma de analizar los requisitos del usuario Aunque tiene su propia notación, lo más característico son los casos de uso El ciclo de vida es similar al modelo básico pero se empieza muy pronto con la interfaz de usuario: Análisis Construcción Pruebas Cliente remoto Giro por nternet <<extends>> Proceso de análisis: <<uses>> Giro Cliente local dentificación Especificación de requisitos Análisis de equisitos Análisis de obustez requisitos análisis Jacobson,., Christerson, M., Jonsson, P., Övergaad, G. Object Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, Métodos OO (después de UML) Evolución de métodos clásicos Métrica versión 3 Métodos ágiles extreme Programming (XP) Métodos marco adaptables OPEN Proceso Unificado (Unified Process) Métrica Versión 3 Cubre desarrollo estructurado y orientado a objetos Además del desarrollo, contempla procesos de Planificación y Mantenimiento Facilita la realización de los procesos de apoyo u organizativos Procesos principales de desarrollo en Métrica 3: Estudio de Viabilidad del Sistema Análisis del Sistema de nformación Diseño del Sistema de nformación Construcción del Sistema de nformación mplantación y aceptación 5

6 Métrica Versión 3 Métrica 3. Análisis n Métrica 3. Diseño n Objetivo : definir la arquitectura del sistema, el entorno tecnológico y la especificación detallada de los componentes del sistema Objetivo: obtención de una especificación detallada del sistema que satisfaga las necesidades de los usuarios y sirva de base para el posterior diseño del sistema Métrica 3. Construcción del Sistemas Se genera el código de los componentes, se desarrollan los procedimientos de operación y seguridad y se elaboran los manuales de usuario final y de explotación 6

7 extreme Programming (XP) Como reacción a los procesos muy burocratizados surgen los métodos ágiles Características de extreme Programming: Ciclos muy cortos de desarrollo Sistemas con funcionalidad mínima Únicamente las tareas de alta prioridad mportancia de las personas Conjunto de buenas prácticas : Programación por pares Pruebas continuas efactorización (refactoring) continua 3.2 El Proceso Unificado de Desarrollo (Unified Process) UML no es suficiente Características del Proceso Unificado Componentes de un Método Elementos de modelado Un conjunto fundamental de conceptos de modelado para capturar el conocimiento semántico sobre un problema y su solución Los conceptos de modelado son independientes de cómo se visualizan Notación Un conjunto de vistas y notaciones para presentar la información de modelado subyacente que permite a las personas examinarlos y modificarlos UML no es un método Personas, Equipos, Experiencia Proceso Tiene como cometido la formalización de las actividades relacionadas con la elaboración de sistemas software Experiencia Una colección de reglas y heurísticas para llevar a cabo el desarrollo Lenguaje de Modelado Proceso? 7

8 Qué es un Proceso? Dos elementos complementarios Describe un conjunto de actividades que deben realizarse en un determinado orden qué hacer, cómo hacerlo, cuando hacerlo y el motivo por el cual debe ser hecho Debe ser: Nuevos equisitos eproducible Definido Medible en cuanto a rendimiento Optimizable... Proceso software Sistema Nuevo UML Estándar OMG Proceso Unificado Proceso marco adaptable Estándar en fase de propuesta Antecedentes del Proceso Unificado Software Process Engineering Metamodel Unified Process 1999 ational Unified Process ational Objectory Process SPEM (2002) Estándares OMG OMG SPEM, 2002 ational Objectory Process UML Ericsson (Jacobson) 8

9 UP es un Proceso marco Características del Proceso Unificado Está dirigido por los casos de uso: Desde la especificación hasta el mantenimiento No existe un proceso Universal UP es flexible y extensible: Permite varias estrategias de desarrollo Se pueden definir diferentes conjuntos de productos Se pueden definir actividades y encargados de las mismas Se centra en la arquitectura: La arquitectura es prioritaria desde el principio hasta el final Se facilita el refinamiento progresivo de la arquitectura terativo e incremental: El trabajo se divide en iteraciones pequeñas en función de la importancia de los casos de uso y el análisis de riesgos Conducido por Casos de uso Centrado en la Arquitectura equisitos Análisis Diseño mplement. Pruebas Los casos de uso integran todas las actividades Capturar, clarificar y validar los casos de uso ealizar los casos de uso Verificar que se satisfacen los casos de uso La arquitectura describe los elementos fundamentales del sistema: Subsistemas Dependencias nterfaces Colaboraciones Nodos Clases activas... ncluye decisiones importantes sobre: Organización del sistema Elementos estructurales, interfaces y su comportamiento Composición y comportamiento de los subsistemas El estilo de la arquitectura que guía esta organización 9

10 Arquitectura: vistas Arquitectura y Modelos Los modelos son instrumentos para visualizar, especificar, construir y documentar la arquitectura del sistema Cada vista es una parte de un modelo casos de uso análisis diseño despliegue mplement. Pruebas Modelos Vista Lógica Vista de Procesos Vista de Casos de Uso Vista de ealización Vista de Despliegue (Philippe Kruchten) La arquitectura incorpora una colección de vistas de los modelos Vistas Estructura y función Proceso iterativo e incremental Casos de uso Arquitectura Los casos de uso especifican las funciones La arquitectura especifica la la estructura Los casos de uso y la arquitectura deben estar en equilibrio Funcionalidad del sistema...pero la característica fundamental de UP: Es un proceso iterativo Se basa en la ampliación y el refinamiento del sistema Una serie de desarrollos cortos (mini proyectos de 2 a 6 semanas, cada iteración reproduce el ciclo de vida a menor escala) No sólo se mejora sino que el sistema también crece: Proceso iterativo e incremental ncremento1 Análisis Diseño mplementación Prueba ncremento2 Análisis Diseño mplementación Prueba Tiempo 10

11 Proceso iterativo e incremental terativo: varias espirales El resultado de cada iteración es un sistema ejecutable (aunque sea incompleto y no esté listo para su instalación) Un sistema instalable requiere varias iteraciones Evolución de prototipos ejecutables Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes Concepto de time-boxing : cada iteración debe tener una duración fija (el máximo, 6 meses) En lugar de retrasar el final de una iteración se recomienda eliminar algunos de los requisitos (se dejan para la siguiente iteración) La realimentación del usuario es fundamental en este proceso El progreso es visible Etapa de ngeniería Etapa de Producción nicio Elaboración Construcción Transición Visión Arquitectura Versiones Beta Productos Cada iteración comprende: ncremental Planificación de la iteración (estudio de riesgos) Análisis de Casos de uso y escenarios Diseño de opciones arquitectónicas Codificación y pruebas. La integración del nuevo código con el existente de iteraciones anteriores se hace gradualmente durante la construcción Evaluación de la entrega ejecutable (evaluación del prototipo en función de las pruebas y de los criterios definidos) Preparación de la entrega (documentación e instalación del prototipo) Primero, la arquitectura, Después, se van añadiendo los detalles según avanza el desarrollo Etapa de ngeniería Etapa de producción nicio Elaboración Construcción Transición equisitos Diseño mplemen tación nstalación equisitos Diseño mplemen tación nstalación equisitos Diseño mplemen tación nstalación equisitos Diseño mplemen tación nstalación Gestión Gestión Gestión Gestión Visión Arquitectura Versiones Beta Productos 11

12 Gestión del riesgo El análisis de riesgos consiste en evaluar el proyecto, la tecnología y los recursos con el fin determinar y comprender la naturaleza y el origen de los riesgos Posibles riesgos: Comerciales (competencia, etc.) Financieros (económicos, etc.) Técnicos ( base tecnológica sólida y probada?) De desarrollo ( equipo experimentado?) Cada iteración se centra en los riesgos más importantes 3.3 Fases y disciplinas (o flujos de trabajo) Fases y puntos de control Disciplinas (Flujos de trabajo) Artefactos Elementos del Proceso Unificado Fases: Es preciso diferenciar temporalmente las fases del ciclo de vida La división temporal necesita... Puntos de control o hitos: Separan las etapas, las fases, las iteraciones Disciplinas o Flujos de trabajo: Organizan las actividades fundamentales de gestión y desarrollo Se pueden solapar en el tiempo. El resultado de las actividades de los flujos de trabajo son... Planificación temporal del proyecto UP propone una serie de ciclos de desarrollo: Hay que separar claramente la etapa de ngeniería de la etapa de Producción Cada una de las dos grandes etapas se dividen en fases Las fases se dividen en iteraciones iteración Ciclo de desarrollo fase Artefactos: Cualquier tipo de información producida por los desarrolladores de un sistema (diagramas UML, código, ejecutables, casos de prueba...) Se construyen de forma incremental Etapa de ngeniería Etapa de Producción 12

13 Etapas y fases del ciclo de vida Objetivos de las fases Etapa de ngeniería: equipos pequeños, actividades poco predecibles (análisis, viabilidad, planificación). Las fases son: nicio Elaboración Etapa de Producción: equipos grandes, actividades predecibles, menos riesgos (programación, pruebas). Las fases son: Construcción Transición nicio Elaboración Construcción Transición nicio del proyecto (inception) Define el ámbito y objetivos del proyecto Elaboración Define la funcionalidad y una arquitectura básica Construcción El producto se desarrolla a través de iteraciones Transición Se libera el producto y se entrega al usuario para su uso real tiempo Hitos Hitos principales y secundarios Los hitos son puntos de control en los cuales los participantes en el proyecto revisan el progreso del proyecto. nicio Elaboración Construcción Transición tiempo Se pretende: Sincronizar las expectativas y la realidad dentificar los riesgos Se evalua la situación global del proyecto Se necesitan: esultados tangibles para comparar con las expectativas Varios niveles: Hitos principales al final de cada fase Hitos secundarios final de cada iteración Visión Arquitectura básica Capacidad inicial elease elease elease elease elease elease elease elease Una iteración es una secuencia de actividades con un plan establecido y unos criterios de evaluación, cuyo resultado es una versión ejecutable (hito secundario) Producto final 13

14 Disciplinas o flujos de trabajo Fases, iteraciones y disciplinas Organizan las actividades fundamentales de gestión y desarrollo del proyecto Disciplinas de desarrollo: requisitos, análisis, diseño, implementación, pruebas, etc. Disciplinas: equisitos Análisis Fases nicio Elaboración Construcción Transición Disciplinas de gestión o soporte: gestión de proyecto, gestión de configuraciones, entorno, evaluación, etc. Diseño Al contrario de lo que ocurre con las fases, las distintas actividades del equipo de desarrollo se pueden solapar en el tiempo. mplementación Pruebas teraciones preliminares iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m+1 teraciones Fases y disciplinas: SPEM El detalle de cada disciplina La propuesta de proceso estándar admite distintas combinaciones de disciplinas y fases Pero hay que definir cada disciplina en detalle Disciplinas: nicio Elaboración Construcción Transición Disciplinas: nicio Elaboración Construcción Transición Modelado del negocio Modelado del negocio equisitos equisitos Diseño Diseño mplementación mplementación Prueba Prueba Despliegue Despliegue Gestión de la Configuración Gestión de la Configuración Gestión del Proyecto Gestión del Proyecto Entorno Entorno teraciones teraciones 14

15 Artefactos Disciplinas y modelos principales Definición de artefacto (o producto): Cualquier tipo de información producida por los desarrolladores de un sistema. equisitos casos de uso Los diagramas UML representan vistas de cada modelo Se construyen de forma incremental Análisis análisis Tipos de artefactos UML Código fuente Ejecutables Casos de prueba... Diseño mplementación diseño despliegue mplement. Los modelos son los artefactos básicos que producen las disciplinas (incluyen otros artefactos) Pruebas Cada disciplina se asocia con modelos Pruebas casos de uso de casos de uso Modelos de análisis y diseño de casos de uso casos de uso de clases de objetos casos de uso de clases de objetos análisis de componentes análisis de componentes diseño de despliegue diseño de despliegue despliegue de secuencia despliegue de secuencia mplement. Pruebas de colaboración de estados de actividades mplement. Pruebas de colaboración de estados de actividades 15

16 El Caso de desarrollo Ejemplo de un Caso de desarrollo El número de posibles diagramas, modelos, vistas, ficheros fuente, casos de pruebas, etc. es muy grande Disciplina Artefacto nicio Construcción Elaboración Transición Es preciso definir los artefactos que son necesarios en cada desarrollo concreto Uno de los artefactos iniciales es el Caso de desarrollo : Qué artefacto es necesario en cada disciplina En qué fase se crea En qué fases se actualiza equisitos Análisis Diseño mplementación casos de uso Visión Glosario l dominio análisis diseño Arquitectura datos implementación Esta posibilidad permite tanto desarrollos pesados como ágiles Pruebas Gestión del Proyecto Entorno pruebas Plan de desarrollo Caso de desarrollo La fase de nicio (nception) 3.4 La fase de nicio (nception) Al comenzar un proyecto hay que contestar algunas preguntas: Cuál es la visión del sistema? Es viable? Se puede comprar o hay que fabricar el sistema? Cuánto va a costar? Y, finalmente seguimos adelante o paramos? 16

17 Objetivos de la fase de nicio Criterios de evaluación de la fase El objetivo es desarrollar el análisis de negocio hasta el punto necesario para la puesta en marcha del proyecto Para ello, es necesario: Delimitar el alcance y objetivos del proyecto Definir la funcionalidad y capacidades del producto Tener una idea de la arquitectura (arquitectura candidata) educir los riesgos cuanto antes Hacer estimaciones iniciales de costes, agenda Al comienzo de la fase de nicio, se establecen: Una planificación provisional Los criterios de evaluación de la fase. Al final, tendremos que haber sido capaces de: Fijar el ámbito del sistema esolver ambigüedades en los requisitos Determinar una arquitectura candidata Mitigar los riesgos críticos Analizar las posibilidades de negocio (evaluar el caso de negocio ) Disciplinas en la fase de nicio Artefactos de la fase de nicio equisitos Enumerar los requisitos iniciales (características del sistema) Comprender el contexto del sistema epresentar los requisitos como casos de uso ecoger los requisitos no funcionales Análisis Análisis de la arquitectura Análisis de los casos de uso (de algunos representativos) Diseño Esbozo de la arquitectura mplementación Prototipo desechable? Pruebas No Artefacto Visión Lista de características Especificación adicional casos de uso Glosario Modelo inicial de dominio análisis diseño Prototipos (desechables) Plan de desarrollo Lista de riesgos Análisis de negocio Caso de desarrollo Descripción Grandes objetivos y restricciones equisitos no funcionales Describe los requisitos funcionales Terminología básica del dominio Define el contexto Esbozo inicial Validar la tecnología ecursos (incluye Plan de la 1ª iteración) iesgos posibles y forma de abordarlos Beneficios? Cómo vamos aplicar UP a este proyecto 17

18 Objetivos de la fase de Elaboración 3.5 La fase de Elaboración Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define la arquitectura básica Se planifica el proyecto considerando recursos disponibles Criterios de evaluación de la fase Al comienzo de la fase de Elaboración: Se planifica la fase y se forma el equipo Se establecen criterios de evaluación que habrá que cumplir al final: especto a los requisitos: Se han identificado? Se han detallado lo suficiente? En cuanto a la arquitectura: Satisface los requisitos? Es robusta? Los riesgos: Se han eliminado los críticos? Se ha completado la lista? Evaluar el proyecto: Se puede fijar un precio y una fecha de entrega? Disciplinas en la fase de elaboración equisitos Encontrar los casos de uso y actores Determinar la prioridad de los casos de uso Detallar los casos de uso Estructurar el modelo de casos de uso Construir prototipos de las interfaces de usuario Análisis Análisis de la arquitectura Análisis de los casos de uso Análisis de clases y paquetes Diseño Diseño de la arquitectura (estilo, subsistemas) Diseño de los casos de uso mplementación mplementación de la arquitectura base (para una fracción de casos de uso) ntegración del sistema (con bibliotecas de servicios, frameworks) Pruebas Planificar y diseñar las pruebas ealizar pruebas de integración y de sistema 18

19 Artefactos de la fase de Elaboración Artefacto Descripción 3.6 casos de uso dominio análisis diseño Arquitectura del sistema pruebas implementación La mayoría de los casos de uso Conceptos del dominio de clases de interacción de paquetes y clases deas fundamentales del diseño que se utilizará en el sistema Qué debe ser probado y cuándo ncluye diagramas de implementación y el código fuente disponible Las fases de Construcción y Transición Prototipos de la interfaz de usuario datos Todo lo relacionado con la interfaz Traducción a esquemas de bases de datos Fase de Construcción El producto se desarrolla a través de iteraciones Cada iteración involucra análisis, diseño e implementación La arquitectura básica se refina de manera incremental conforme se construye Gran parte del trabajo es programación y pruebas Se documenta tanto el sistema construido como el manejo del mismo Esta fase proporciona un producto construido junto con la documentación Al comienzo de esta fase, se asigna personal y se fijan los criterios de evaluación: Lista de casos de uso implementados Documentación inicial para los usuarios Disciplinas en la fase de Construcción equisitos Completar los casos de uso y el detalle de los mismos Desarrollar prototipos de interfaz de usuario Análisis Análisis de los casos de uso añadidos Análisis de clases Diseño Diseño de los casos de uso añadidos mplementación mplementación de la arquitectura mplementación de clases y subsistemas ealizar pruebas de unidad ntegración del sistema Pruebas Planificar y diseñar las pruebas ealizar pruebas de integración ealizar pruebas de sistema Evaluar las pruebas 19

20 Control en la fase de Construcción Artefactos de la fase de Construcción Además de las disciplinas técnicas, es preciso llevar a cabo labores de gestión: Control del análisis de negocio Evaluación de la fase de Construcción Planificación de la fase de Transición Artefacto casos de uso análisis diseño pruebas Arquitectura del sistema implementación pruebas Descripción Conjunto de artefactos producidos hasta ahora Arquitectura definitiva ncluye el código fuente Sistema ejecutable Versión con capacidad operativa inicial (V. Beta) Manual de usuario Versión inicial Análisis de negocio Plan de proyecto Situación actual del proyecto Plan para la fase de Transición Fase de Transición Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de instalación, configuración, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la información anterior Estas tareas se realizan también en iteraciones Disciplinas en la fase de Transición El esquema de actividades es distinto del resto de las fases: Preparar la versión de pruebas de aceptación a partir de la versión inicial nstalar la versión en los lugares elegidos ncluirá la migración de datos eaccionar a los resultados de las pruebas Fallos en un componente, un diseño, un caso de uso Problemas de fondo Adaptación del producto a entornos variados Al comienzo de la fase, se reasigna personal y se establecen los criterios de evaluación: Han sido capaces los usuarios de llevar a cabo todos los casos de usos? Ha superado el producto las pruebas de aceptación? Tiene el manual de usuario una calidad suficiente? Están listos los cursos de formación para los usuarios? Están los usuarios satisfechos? Cuándo acaba el proyecto? En un producto a medida, el punto clave son las pruebas de aceptación En un producto de venta masiva, el proyecto no acaba nunca realmente 20

21 Bibliografía ecomendada Lecturas complementarias Jacobson,., Booch, G., umbaugh, J. El Proceso Unificado de Desarrollo de Software. Addison-Wesley, Larman, C. UML y Patrones. ntroducción al Análisis y Diseño Orientado a Objetos. Prentice Hall, (existe una segunda edición en inglés de 2002) Ministerio de Administraciones Públicas. MÉTCA. Versión 3. Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información Beck, K. Una explicación de la Programación Extrema. Aceptar el cambio. Addison Wesley, Kruchten, P. The 4+1 view model of architecture, EEE Software, 12(6): November, oyce, W. Software Project Management. A Unified Framework. Addison Wesley, Kruchten, Philippe. "A Software Development Process for a Team of One", The ational edge. Feb SPEM oles, Work Products y Actividades Software Process Engineering Metamodel Miguel A. Laguna 21

22 SPEM: estructura SPEM: dependencias SPEM: Estructura del proceso SPEM: componentes de un proceso 22

23 SPEM: Ciclo de vida SPEM: notación (1) SPEM: notación (2) SPEM: notación (3) 23