Tema 2 Modelos de proceso del software

Transcripción

1 Tema 2 Modelos de proceso del software 1. Conceptos básicos 2. Procesos del ciclo de vida Procesos principales Procesos de soporte Procesos de la organización Modelo clásico Iterativo Variantes del ciclo de vida iterativo Ciclo de vida en espiral Modelo de métodos formales Desarrollo rápido de aplicaciones Modelo de desarrollo concurrente Programación extrema Modelos para sistemas orientados a objetos De agrupamiento Fuente Remolino Pinball Basado en componentes Proceso Unificado 1 María N. Moreno García 1. Conceptos básicos Proceso del software: conjunto de actividades y resultados asociados que conducen a la creación de un producto software [Sommerville, 2001] Ciclo de vida del software: Aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software (norma IEEE 1074) [IEEE, 1999] El ciclo de vida incluye Ciclo de desarrollo del sistema Tiempo de vida del sistema Modelo de ciclo de vida: 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, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso (norma ISO ) [ISO/IEC, 1995] Actividad: conjunto de tareas Tarea: acción que transforma entradas en salidas Objetivos Proporcionar una estrategia de desarrollo y un enfoque sistemático en la realización de las actividades de desarrollo y mantenimiento de un sistema Ayudar a fijar objetivos Permitir un seguimiento de las necesidades de recursos 2

2 2. Procesos del ciclo de vida (I) Las actividades del ciclo de vida del software se pueden agrupar de la forma siguiente (norma ISO ) [ISO/IEC, 1995] Procesos principales Adquisición Suministro Desarrollo Explotación Mantenimiento Procesos de soporte Documentación Gestión de la configuración Aseguramiento de la calidad Verificación Validación Revisión conjunta Auditoría Resolución de problemas Procesos de la organización (generales) Gestión Procesos Principales Procesos de Soporte Mejora Adquisición Documentación Infraestructura Suministro Gestión de la configuración Formación Aseguramiento de la calidad Explotación Desarrollo Mantenimiento Verificación Validación Revisión conjunta Auditoría Resolución de problemas Procesos de la Organización Gestión Mejora Nuevos procesos (amendment ) Usabilidad Evaluación de productos Recursos Humanos Gestión de assets Gestión del programa de reutilización Ingeniería del dominio Infraestructura Formación 3 2. Procesos del ciclo de vida (II) Procesos principales: Son los que resultan útiles a las personas que inician o realizan el desarrollo, la explotación o el mantenimiento del software durante su ciclo de vida Proceso de adquisición: Actividades y tareas que se realizan para comprar un producto software Proceso de suministro: Actividades y tareas que el suministrador realiza Proceso de desarrollo: Contiene las actividades de análisis de requisitos, diseño, codificación, integración, pruebas e instalación y aceptación Proceso de explotación: Incluye la explotación del software y el soporte operativo a los usuarios Proceso de mantenimiento: Aparece cuando el software necesita modificaciones, ya sea en el código o en la documentación asociada, debido a un error, una deficiencia, un problema o la necesidad de mejora o adaptación 4

3 2. Procesos del ciclo de vida (III) Procesos de soporte: Sirven de apoyo al resto y se aplican en cualquier punto del ciclo de vida Proceso de documentación: Registra la información producida por un proceso o actividad en el ciclo de vida Proceso de gestión de la configuración: Aplica ciertos procedimientos y técnicas durante todo el ciclo de vida del sistema Proceso de aseguramiento de la calidad: Aporta la confianza de que los procesos y los productos software del ciclo de vida cumplen los requisitos especificados y se ajustan a los planes establecidos Proceso de verificación: Determina si los requisitos de un sistema o del software están completos y son correctos Proceso de validación: Sirve para determinar si el sistema o software final cumple con los requisitos previstos para su uso Proceso de revisión conjunta: Sirve para evaluar el estado del software y sus productos en una actividad del ciclo de vida o una fase de un proyecto Proceso de auditoría: Permite determinar, en los hitos predeterminados, si se han cumplido los requisitos, los planes y el contrato Proceso de resolución de problemas: Permite analizar y eliminar los problemas descubiertos durante el desarrollo, explotación, el mantenimiento u otro proceso 5 2. Procesos del ciclo de vida (IV) Procesos de la organización (generales): Los emplea una organización para llevar a cabo funciones tales como la gestión, la formación del personal o la mejora del proceso Proceso de gestión: Actividades y tareas genéricas que puede emplear cualquier organización que tenga que gestionar sus procesos, incluyendo planificación, seguimiento y control, y revisión y evaluación Proceso de infraestructura: Establece la infraestructura necesaria para cualquier otro proceso Proceso de mejora: Sirve para establecer, valorar, medir, controlar y mejorar los procesos del ciclo de vida del software Proceso de formación: Sirve para proporcionar y mantener al personal formado 6

4 2. Procesos del ciclo de vida (V) Proceso de adaptación: Sirve para realizar la adaptación básica de la norma ISO con respecto a los proyectos software. Es necesario comprender los procesos, las organizaciones y sus relaciones bajo diferentes puntos de vista Bajo el punto de vista del contrato, el comprador y el proveedor negocian y firman un contrato, empleando los procesos de adquisición y suministro Bajo el punto de vista de gestión, el comprador, el proveedor, el desarrollador, el operador y el personal de mantenimiento gestionan sus respectivos procesos para el proyecto software Bajo el punto de vista de explotación, el operador proporciona el servicio de explotación del software a los usuarios Bajo el punto de vista de ingeniería, el desarrollador o el personal de mantenimiento llevan a cabo sus respectivas tareas de ingeniería para producir o modificar los productos software Bajo el punto de vista de soporte, los grupos (tales como el de la gestión de la configuración, el aseguramiento de la calidad...) proporcionan servicios de apoyo a otros grupos en el cumplimiento de tareas únicas y específicas 7 Modelos tradicionales Formados por un conjunto de fases o actividades en las que que no tienen en cuenta la naturaleza evolutiva del software Clásico, lineal o en cascada Estructurado Iterativo o basado en prototipos Desarrollo rápido de aplicaciones (RAD) Modelos evolutivos Son modelos que se adaptan a la evolución que sufren los requisitos del sistema en función del tiempo En espiral Evolutivo Incremental Modelo de desarrollo concurrente Modelos para sistemas orientados a objetos Modelos con un alto grado de iteratividad y solapamiento entre fases De agrupamiento Fuente Remolino Pinball Basado en componentes UP 8

5 3.1. Modelo clásico (I) Conocido también como modelo lineal o en cascada Versión original se debe a W. W. Royce [Royce, 1970], apareciendo después numerosos refinamientos Características Está compuesto por una serie de fases que se ejecutan secuencialmente Obtención de documentos como criterio de finalización de fase Problemas de la progresión secuencial Desconocimiento de las necesidades por parte del cliente Inestabilidad de los requisitos No se ven resultados hasta muy avanzado el proyecto Efecto big bang próximo a la entrega Ciclo de vida clásico Modelo clásico (II) El modelo en cascada se representa frecuentemente en forma de V (de ahí que se le conozca también como ciclo en V) Demuestra que el desarrollo de las pruebas se efectúa de manera síncrona con el desarrollo del programa Esta aproximación permite probar lo que debía hacerse y no lo que se ha hecho Presenta una implantación ascendente Implica un gran número de dificultades Análisis validado por Pruebas funcionales Diseño Pruebas de integración Codificación Pruebas unitarias Aplicación Representación en V del ciclo de vida clásico 10

6 3.1. Modelo clásico (III) Modelo satisfactorio sólo en desarrollos conocidos y estables El desconocimiento y el riesgo suele ser alto en el desarrollo del software, debido La linealidad no se corresponde con la realidad Los retornos de información entre las fases se hacen necesarios para incorporar correcciones hacia arriba, en función de los descubrimientos realizados hacia abajo Estos retornos entre fases perturban la visión lineal dada por el ciclo de vida en cascada Los retornos están limitados a fases adyacentes Ciclo de vida clásico con realimentación Modelo iterativo (I) Características del ciclo iterativo [Muller, 1997] Se basa en la evolución de prototipos ejecutables, mesurables y evaluables Se van incorporando cambios en cada iteración Exige más atención e implicación de todos los actores del proyecto Minicascada Cada iteración reproduce el ciclo de vida en cascada, pero a una escala menor Los objetivos de cada iteración se establecen en función de la evaluación de las iteraciones precedentes Las fases tradicionales se cubre gradualmente en las diversas iteraciones Las actividades internas se solapan porque dentro de una iteración no necesitan terminarse de golpe, siendo la transición entre dos actividades progresiva Análisis N veces Fases Diseño Codificación Integración Planificación Análisis Diseño Codificación Evaluación Transición Entrega progresiva 12

7 3.2. Modelo iterativo (II) Evaluación de las iteraciones Deben definirse criterios de evaluación de las iteraciones Una iteración se marca por etapas intermedias que permitan medir los progresos. Debe haber al menos dos etapas Revisión inicial: fija los objetivos y criterios de la iteración Revisión de evaluación: valida los resultados Mitos sobre el ciclo de vida iterativo [Muller, 1997] El ciclo de vida iterativo favorece los apaños El ciclo de vida iterativo engendra problemas El ciclo de vida iterativo e incremental exige recomenzar n veces hasta que el resultado sea el adecuado El ciclo de vida iterativo es una excusa para no planificar y gestionar un proyecto El ciclo de vida iterativo sólo concierne a los desarrolladores El ciclo de vida iterativo favorece siempre añadir nuevas necesidades, sin fin 13 Ciclo en b 3.3. Variantes del ciclo de vida iterativo (I) Variante más sencilla del ciclo de vida iterativo La forma b fue identificada por Birrel y Ould [Birrel y Ould, 1985] Concentra las iteraciones sobre la construcción Cuando no se conocen todos los requisitos desde el principio, o se desea modificar aspectos arquitectónicos, se pueden añadir bucles a las fases iniciales Los ciclos son rápidos y la integración continua El objetivo de este modelo es suprimir el efecto big bang de una fase de integración al final del ciclo Se adapta a aplicaciones modestas o bien definidas Estudio de oportunidad Elaboración Estudio de oportunidad Elaboración Integración Construcción Integración Construcción Dos versiones del ciclo en b 14

8 3.3. Variantes del ciclo de vida iterativo (II) Ciclo en O Surge cuando las ramas secundarias del ciclo en b toman mayor relevancia que su flujo principal Deriva del ciclo en espiral de Boehm [Boehm, 1988], siendo descrito por P. Kruchten [Kruchten, 1991] Las iteraciones comprenden el análisis y el diseño Estudio de oportunidad Definición de la iteración Elaboración Evaluación Construcción Integración Ciclo en O Ciclo de vida en espiral (I) Fue propuesto inicialmente por B. Boehm [Boehm, 1986], [Boehm, 1988] Es un modelo de proceso de software evolutivo, que proporciona el potencial para el desarrollo rápido de versiones incrementales del software Características Puede considerarse como un metamodelo de proceso Principalmente, reúne características del modelo clásico y de prototipos Aparece el análisis de riesgo Se divide en un número de actividades estructurales, también denominadas regiones de tareas. Normalmente existen entre tres y seis En el modelo original de Boehm aparecen cuatro regiones de tareas Planificación, Análisis de riesgos, Ingeniería, Evaluación del cliente En [Pressman, 1998] se presenta una variante con seis regiones de tareas Comunicación con el cliente, Planificación, Análisis de riesgos, Ingeniería, Construcción y adaptación, Evaluación del cliente El avance se realiza desde el centro de la espiral hacia el exterior 16

9 3.4. Ciclo de vida en espiral (II) Determinar objetivos, alternativas y restricciones Plan para la próxima fase Plan de requisitos y del ciclo de vida Plan de desarrollo Plan de integracion y prueba Analisis de riesgo Analisis de riesgo Analisis de riesgo Analisis de riesgo Prototipo 1 Prototipo 2 Operacion Espec. requisitos Validacion requisitos V & V diseño Servicio. Evaluar alternativas Identificar y resolver riesgos Prototipo 3 Simulaciones Pruebas unidad Pruebas aceptación. Diseño Prototipo operativo Diseño detallado Codificación Desarrollo, verificación del siguiente nivel del producto Ciclo de vida en espiral [Boehm, 1988] Ciclo de vida en espiral (III) Ciclo de vida en espiral [Pressman, 1998] 18

10 3.5. Modelo de métodos formales Permiten especificar, desarrollar y verificar un sistema aplicando una notación matemática Algunas organizaciones de desarrollo de software aplican una variación de este enfoque, llamado ingeniería del software de sala limpia [Mills et al., 1987], [Dyer, 1992] Ventajas La ambigüedad, lo incompleto y la inconsistencia se descubren y se corrigen fácilmente Los métodos formales de diseño sirven como base para la verificación de programas Sirven de base para la generación automática de código Barreras para su implantación El desarrollo es bastante caro y lleva mucho tiempo El estudio de los métodos es costoso Es difícil establecer modelos como mecanismo de comunicación con los clientes Desarrollo rápido de aplicaciones (I) El modelo de desarrollo rápido de aplicaciones, DRA (RAD Rapid Application Development) o modelo de la caja de tiempo surgió como respuesta al modelo formal y al ciclo en espiral Enfatiza un ciclo de desarrollo extremadamente corto Modelo funcional en 60 ó 90 días No es un modelo bien definido Secuencia de integraciones de un sistema evolutivo o de prototipos que se revisan con el cliente descubrimiento de los requisitos Cada integración se restringe a un período de tiempo bien definido (caja de tiempo) Características Modelo secuencial: Separación en fases de cada caja de tiempo Integraciones constantes Centrado en el código más que en la documentación Desarrollo basado en componentes Uso efectivo de herramientas y frameworks Participación activa del usuario 20

11 3.6. Desarrollo rápido de aplicaciones (II) Cuando se utiliza en S.I. Automatizados, comprende las fases [Kerr y Hunter, 1994] Modelado de gestión Modelado de datos Modelado del proceso Generación de aplicaciones Pruebas y entrega Equipo nº 1 Modelado de gestión Equipo nº 2 Modelado de gestión Modelado de datos Equipo nº 3 Modelado de gestión Modelado de procesos Modelado de datos Modelado de procesos Modelado de datos Modelado de procesos Gener. de aplicaciones Pruebas y entrega Gener. de aplicaciones Pruebas y entrega Gener. de aplicaciones Pruebas y entrega De 60 a 90 días Modelo DRA [Kerr y Hunter, 1994] Desarrollo rápido de aplicaciones (III) Las limitaciones de tiempo demandan un ámbito de escalas Si una aplicación de gestión puede modularse de forma que pueda completarse cada una de las funciones principales en menos de tres meses, es un candidato del DRA. Cada una de estas funciones puede ser afrontadas por un equipo DRA diferente y ser integradas en una sola aplicación Inconvenientes [Butler, 1994] Los proyectos grandes necesitan los recursos humanos suficientes para crear el número correcto de equipos Se requiere de un compromiso de las partes involucradas 22

12 3.7. Modelo de desarrollo concurrente Propuesto por Davis y Sitaram [Davis y Sitaram, 1994] Características Representación mediante un conjunto de actividades, tareas y estados asociados a ellas Todas las actividades existen concurrentemente, pero residen en estados diferentes Define una serie de acontecimientos que disparan transiciones de estado a estado para cada una de las actividades de la ingeniería del software Ninguna Ninguna Actividad de análisis Bajo Bajo desarrollo desarrollo Cambios Cambios en en espera espera Bajo Bajo revisión Bajo revisión Bajo modificación En En línea línea base base Hecho Hecho Un elemento del modelo de desarrollo concurrente Programación extrema La programación extrema [Beck, 1999] es un nuevo y controvertido enfoque de desarrollo de software basado en el modelo incremental Este nuevo enfoque es el precursor de una nueva corriente denominada el modelado ágil Está indicado para Equipos de tamaño mediano o pequeño Requisitos imprecisos y cambiantes Características: El juego de la planificación Versiones pequeñas Metáfora Diseño sencillo Hacer pruebas Refactoring Programación en parejas Propiedad colectiva Integración continua Cliente in-situ Estándares de codificación 24

13 3.9 Modelos para sistemas OO (I) Características Eliminación de las fronteras entre fases Desarrollo basado en componentes reutilizables Desarrollo iterativo e incremental Las tareas de cada fase se realizan de forma iterativa Existe un ciclo de desarrollo que permite la evolución del sistema Alto grado de iteración y solapamiento El sistema se divide en un conjunto de particiones que se van desarrollando e integrando de forma incremental Se pueden combinar con modelos tradicionales Modelos para sistemas OO (II) Modelo remolino Definido por James Rumbaugh [Rumbaugh, 1992] Las metodologías de desarrollo no ofrecen una visión real del ciclo de vida en el desarrollo orientado al objeto El ciclo de vida de un desarrollo orientado al objeto es desordenado, involucrando múltiples iteraciones interrelacionadas El modelo en cascada asume una sola dimensión de iteración, consistentes en la fase de proceso Pueden identificarse otras dimensiones Amplitud: tamaño del desarrollo, por ejemplo en número de elementos Profundidad: referida al nivel de abstracción o detalle Madurez: grado de compleción, corrección y elegancia Alternativas: Diferentes soluciones a un problema Alcance: Propósitos y objetivos del sistema, ya que los requisitos van cambiando a lo largo del proyecto Las diferentes dimensiones pueden anidarse de varias formas Ejemplo: profundidad - madurez - amplitud Desarrollo multiciclo en forma de remolino en lugar de una cascada 26

14 3.9 Modelos para sistemas OO (III) Modelo Pinball (I) Propuesto por Ambler [Ambler, 1994] Modelo muy didáctico El pinball refleja la forma que se desarrolla Pelota Proyecto o subproyecto Jugador Equipo de desarrollo De forma iterativa se procede a encontrar clases, atributos, métodos y relaciones (actividades que pueden englobarse en la fase de análisis) y definir colaboraciones, herencia, agregación y subsistemas (actividades de diseño), y por último se pasa a la programación, prueba e implementación Como en el pinball los pasos se pueden dar en cualquier orden y de forma simultánea Modelos para sistemas OO (IV) Modelo Pinball (II) Dos estilos de juego A lo seguro Con tecnologías y métodos probados Al límite Con más riesgo (se pueden conseguir beneficios espectaculares) Proceso iterativo 28

15 3.9 Modelos para sistemas OO (V) Modelo de agrupamiento (I) Propuesto por Bertrand Meyer [Meyer, 1990] Concepto clave: AGRUPAMIENTO (cluster) [Meyer, 1999] Unidad organizativa básica Grupo de clases relacionadas o, recursivamente, clusters relacionados Unidad natural para el desarrollo por parte de un único desarrollador Evita el efecto todo-nada propio del modelo en cascada Tiene un componente secuencial y un componente concurrente Existencia de diferentes subciclos de vida (uno para cada cluster) que pueden solaparse en el tiempo Cada subciclo de vida que gobierna el desarrollo de un cluster está formado por Especificación, Diseño, Implementación, Verificación/Validación y Generalización Modelos para sistemas OO (VI) Modelo de agrupamiento (II) Enfoque ascendente La ocultación de la información posibilita la forma del modelo de clusters de ingeniería concurrente Tiempo Espec DisRea ValGen Agrupamiento n Espec DisRea ValGen Agrupamiento 2 Espec DisRea ValGen Agrupamiento 1 Tiempo Distribución temporal de las fases de cada agrupamiento 30

16 3.9 Modelos para sistemas OO (VII) Modelo fuente (I) Definido por Henderson-Sellers y Edwards en 1990 [Henderson- Sellers y Edwards, 1990] Representa gráficamente el alto grado de iteración y solapamiento que hace posible la tecnología de objetos Propone dos modelos de ciclo de vida Para el sistema completo Para cada clase o módulo: Cada clase puede estar en una fase diferente del ciclo de vida durante el desarrollo del sistema El modelo permite la integración del análisis de dominio: identificación, análisis y especificación de requisitos comunes de un dominio de aplicación específico Modelos para sistemas OO (VIII) Modelo fuente (II) Mantenimiento Evolución Utilización Pruebas Sistema Pruebas Unitarias Codificación Componentes Diseño Conceptual Análisis Estudio de viabilidad y requisitos Piscina SW Generalización Re-evaluación Utilización Prueba Implementación Diseño de Componente Diseño Conceptual Modelo fuente para el sistema y para un componente Análisis Requisitos Piscina SW Generalización Re-evaluación 32

17 3.9 Modelos para sistemas OO (IX) Desarrollo basado en componentes (I) Configura aplicaciones a partir de componentes de software preparados [Pressman, 2001] Enfoque iterativo y evolutivo [Nierstrasz, 1999] Se enmarca en un contexto más amplio: ingeniería del software basada en componentes Modelos para sistemas OO (X) Desarrollo basado en componentes (II) El objetivo de la ingeniería del dominio es identificar, construir, catalogar y diseminar un conjunto de componentes de software que tienen aplicación en el software actual y futuro dentro de un dominio de aplicación particular [Presman, 2001] Ingeniería del software basada en componentes 34

18 3.9 Modelos para sistemas OO (XI) Desarrollo basado en componentes (III) Cualificación de componentes: Asegura que un componente candidato llevará a cabo la función necesaria, encajará en el estilo arquitectónico del sistema y tendrá la calidad requerida Adaptación de componentes: Elimina conflictos de integración Enmascaramiento de caja blanca, gris o negra Composición de componentes: Ensambla componentes cualificados, adaptados y diseñados para la arquitectura establecida Ingeniería de componentes: Diseño de componentes para su reutilización Actualización de componentes: El software actual se reemplaza a medida que se dispone de nuevas versiones de componentes Modelos para sistemas OO (XII) El proceso unificado (I) Definido por Rational Software Corporation [Jacobson et al., 2000] Evolución del proceso Objectory de Rational Utilización de UML [Booch et al., 1999] como lenguaje de modelado Basado en componentes El sistema software en construcción está formado por componentes software interconectados a través de interfaces bien definidas Características Conducido por casos de uso Los casos de usos se implementan para asegurar que toda la funcionalidad se realiza en el sistema y verificar y probar el mismo. Como los casos de uso contienen las descripciones de las funciones, afectan a todas las fases y vistas Centrado en la arquitectura La arquitectura se describe mediante diferentes vistas del sistema. Es importante establecer una arquitectura básica pronto, realizar prototipos, evaluarla y finalmente refinarla durante el curso del proyecto Iterativo e incremental Resulta práctico dividir los grandes proyectos en mini proyectos, cada uno de los cuales es una iteración que resulta en un incremento 36

19 3.9 Modelos para sistemas OO (XIII) El proceso unificado (II) El Proceso Unificado se repite a lo largo de una serie de ciclos Cada ciclo consta de cuatro fases: Inicio: se define el alcance del proyecto y se desarrollan los casos de negocio Elaboración: se planifica el proyecto, se especifican en detalle la mayoría de los casos de uso y se diseña la arquitectura del sistema Construcción: se construye el producto Transición: el producto se convierte en versión beta. Se corrigen problemas y se incorporan mejoras sugeridas en la revisión Dentro de cada fase se puede, a su vez, descomponer el trabajo en iteraciones con sus incrementos resultantes Cada fase termina con un hito, cada uno de los cuales se caracteriza por la disponibilidad de un conjunto de componentes de software Objetivos de los hitos: Toma de decisiones para continuar con la siguiente fase Controlar el progreso del proyecto Proporcionar información para la estimación de tiempo y recursos de proyectos sucesivos Modelos para sistemas OO (XIV) El proceso unificado (III) Cada ciclo concluye con una versión del producto para los clientes Inicio Elaboración Construcción Transición tiempo Vista Línea base de arquitectura Capacidad inicial Versión del producto Inicio Elaboración Construcción Transición Prelim Iteración... Arqu. Iteración... Des. Des. Iteración Iteración... Trans. Iteración... Versión Versión Versión Versión Versión Versión Versión 38

20 3.9 Modelos para sistemas OO (XV) El proceso unificado (IV) Las iteraciones discurren a lo largo de los flujos de trabajo Fases Flujos de trabajo Requisitos Inicio Elaboración Construcción Transición Análisis Diseño Implementación Pruebas Iteraciones preliminares ite r. #1 ite r. #2 iter. #n iter. #n+1 ite r. #n +2 iter. #m iter. #m +1 Iteraciones 39 Bibliografía Ambler, S. W. In search of a generic SDLC for object systems. Object Magazine, 4(6): 76-78, Beck, K. Embracing Change with Extrem Programming, IEEE Computer 32, pp , Birrel, N. D., Ould, M.A. A practical Handbook for Software Development. Cambridge University Press, Boehm, B. W. A Spiral Model of Software Development and Enhancement. ACM Software Engineering Notes, 11(4): Boehm, B. W. A Spiral Model of Software Development and Enhancement. Computer, 21(5): 61-72, Booch, G., Rumbaugh, J., Jacobson, I. El Lenguaje Unificado de Modelado. Addison Wesley, Butler, J. Rapid Application Development in Action. Managing System Development, Applied Computer Research, 14(5):6-8. May, Davis, A., Sitaram, P. A concurrent Process Model for Software Development, Software Engineering Notes, ACM Press, 19(2): 38-51, Dyer, M. The Cleanroom Approach to Quality Software Development. Wiley, Graham, I. Métodos orientados a objetos, Adison-Wesley, Henderson-Sellers, B., Edwards, J. M. The fountain Model for object-oriented systems development, Object Magazine, julio/agosto, pp 71-79, Henderson-Sellers, B., Edwards, J. M. The object-oriented systems life cycle, Communications of the ACM, 33(9): , IEEE. IEEE Software Engineering Standards Collection 1999 Edition. Volume 2: Process Standards. IEEE Computer Society Press, ISO/IEC. Information Technology Software Life Cycle Processes. Technical ISO/IEC 12207:1995(E),

21 Bibliografía Jacobson, I., Booch, G., Rumbaugh, J. El Proceso Unificado de Desarrollo, Addison Wesley, Kerr, J., Hunter, R. Inside RAD, McGraw-Hill, Kruchten, P. Un processus de développement de logiciel itératif et centré sur lárchitecture, Proceedings of the 4th International Conference on Software Engineering. Toulouse, Paris, Martin, J. Rapid Application Development, Prentice Hall, Meyer, B. La Nueva Cultura del Desarrollo de Software, Systems, pp Septiembre, Meyer, B. Construcción de software orientado a objetos, Prentice Hall, Mills, H. D., Dyer, M., Linger, R. Cleanroom Software Engineering, IEEE Software, 4(5): September Muller, P. A. Modelado de objetos con UML, Eyrolles-Ediciones Gestión 2000, Nierstrasz,O., Gibbs, S.J., Tsichritzis, D. Component-Oriented Software Development. CACM, 35(9): , Piattini, M.G. et al. Análisis y diseño detallado de aplicaciones Informáticas de Gestión, Rama, Pressman, R. S. Ingeniería del Software, un enfoque práctico, 4ª Edición. Mc Graw Hill, Pressman, R. S. Ingeniería del Software, un enfoque práctico, 5ª Edición. Mc Graw Hill, Royce, W. W. Managing the Development of Large Software Systems: Concepts and Techniques, In Proceedings WESCON. August, Rumbaugh, J. Over the waterfall and into the whirlpool, JOOP, mayo, pp 23-26, Sommerville, I. Software Engineering, 6 th ed., Addison Wesley,