Download - Modelos Procesos OxO

Modelos de Procesos para el

Desarrollo de Software Orientado a Objetos

Jonás A. Montilva C., Ph.D.

Modelos de Procesos para el Desarrollo de Software Orientado a Objetos

Contenidos

• Ciclos de vida del sofware y los modelos de procesos

• El papel de los modelos de procesos en el desarrollo de

software

• Modelos de procesos orientados a objetos

– El modelo unificado de Rational

– El modelo de Bruegge y Dutoit

– El modelo basado en la reutilización de componentes

• El estándar IEEE-1074

• El modelo de procesos WATCH

• Conclusiones


El Ciclo de Vida del Software• El software evoluciona a través de un ciclo de actividades:

Development Use

MaintenanceRetirement


Modelos de procesos de software

• Un modelo de procesos es una representación del ciclo de

vida del software

• Describe los procesos requeridos para desarrollar y/o

mantener software

– sigue un enfoque o paradigma determinado

• Un proceso es un conjunto estructurado de actividades

diseñado para alcanzar un objetivo establecido

Process

constraints

results or productsresources

control


Modelos de procesos de software• Procesos básicos del desarrollo de software:

– Análisis y especificación de requerimientos

– Diseño de software

– Implementación

– Pruebas de software

– Entrega del software

– Mantenimiento del software

• Un proceso de software puede ser definido o diseñado como una

jerarquía de procesos a diferentes niveles de abstracción:

P

Pi.mPi.1

PnPiP1 ...

...

...

Process Level

Activity Level

Task Level


El papel de los modelos de procesos

• Los modelos de procesos son la base fundamental para el diseño de un método de desarrollo de software

• Representan la estructura del método de desarrollo

Método

Modelo(s)

de ProcesosTécnicas

Lenguaje de

ModeladoHerramientas

El cómoEl qué Con qué


El papel de los modelos de procesos

• Un modelo de procesos es un marco

metodológico para:

– Reducir la complejidad del proceso de

desarrollo y mantenimiento de software

– Guiar al grupo de desarrollo y/o

mantenimiento

• El modelo da visibilidad al proyecto

– Ayudar al líder del proyecto a planificar y

controlar el proyecto

– Asegurar la producción de software de alta

calidad

– Mejorar el proceso de desarrollo de software

en una organización


Taxonomía de los modelos de procesos

• El enfoque de ingeniería de sistemas físicos

– El modelo de cascada

– El modelo V

– El modelo “Cleanroom”

• El enfoque evolutivo

– Modelos basados en prototipos

– El modelo de espiral

– El modelo incremental

– El modelo de versiones

– El modelo de sincronización y estabilización

• El enfoque formal

– El modelo de transformaciones

• El enfoque orientado a objetos

– El modelo de Booch

– El modelo unificado de Rational

• El enfoque de reutilización de software

– Los modelos basados en componentes reutilizables


Los modelos y métodos OO más conocidos

• Rational Unified Process (G.Booch, J. Rumbaugh, and I. Jacobson)

• OPEN: OO Process, Environment, and Notación usada (B, Henderson-Hellers)

• OSM: OO System Modeling ( R. Jackson, et al)

• SOMA: Semantic Object Modeling Approach (I,. Graham)

• RDD: Responsibility-Driven Design (R. Wirfs-Brock)

• CCR Cards: Class-Responsibility-Collaboration (N. Wilkinson)

• Fusion (D. Coleman, et al)

• OOAD: OO Analysis and Design (J. Martin and Odell)

• OOA/OOD (P. Coad and E. Yourdon)

• OMT: Object Modeling Technique (J. Rumbaugh, et al)

• Object Lifecycles (Shlaer and Mellor)

• OOSE: OO Software Engineering (I. Jacobson, et al)

• The Booch Method (G. Booch)


El modelo unificado de Rational

• Es un modelo de procesos OO desarrollado por Rational, Co.

• Un proyecto se desarrolla a través de una serie de ciclos

– Cada ciclo libera un producto al cliente

• Un ciclo consta de cuatro fases gerenciales:

– Comienzo (Inception):

• Definición de la idea o visión del producto final, su alcance y su factibilidad

– Elaboración:

• Planificación del proyecto, definición de las características del sistema y de su arquitectura, asignación de recursos

– Construcción:

• Desarrollo del sistema

– Transición:

• Instalación del sistema y su transición al ambiente de operación definitivo


El modelo unificado de Rational


El modelo de Bruegge and Dutoit

• Es un modelo OO con fines académicos descrito en:

– B. Brugge and A. Dutoit. Object –Oriented Software Engineering. Prentice-Hall, 2000.

• Utiliza el lenguaje de modelado unificado (Unified Modeling Language - UML)

• Procesos principales del modelo:

– Descubrimiento de Requerimientos

– Análisis

– Diseño del sistema

– Diseño de objetos

– Implementación

– Pruebas



• Descubrimiento de Requerimientos– Propósito:

• Definir los objetivos del sistema, su contexto y sus requerimientosfuncionales y no-funcionales

– Producto: • Modelo de Especificación del Sistema

– Notación usada:

• Diagramas de Casos de Uso en UML

• Análisis– Propósito:

• Producir un modelo del sistema en términos de sus objetos, atributosy relaciones

– Producto: • Modelo de Análisis

– Notación usada: • Diagramas de clases en UML


El modelo de Bruegge and Dutoit• Diseño del sistema

– Propósito: • Transformar el modelo de análisis en un modelo que defina la

arquitectura del sistema, sus estrategias de implementación y la plataforma de operación

– Producto: • Arquitectura del sistema y metas de diseño

– Notación usada: • Diagramas de clase y despliegue en UML

• Diseño de objetos– Propósito:

• Refinar el diseño del sistema y convertirlo en un modeloimplementable en la plataforma H/S seleccionada

– Producto: • Modelo Detallado de Objetos

– Notación usada: • Diagramas de clases, actividades, secuencias, objetos y

componentes en UML



• Implementación– Propósito:

• Traducir el modelo detallado a programas y documentos– Producto:

• Programas OO y documentación– Notación usada:

• Lenguaje de programación OO

• Pruebas– Propósito:

• Asegurar la calidad de aplicación a través de los procesos de verificación y validación

– Producto: • Una aplicación verificada y validada

– Notación usada: • Diagramas de clases, estado, casos de uso y secuencias en

UML


Modelos basados en componentes

• Incorporan la reutilización del software en el proceso de desarrollo de aplicaciones

• "Reutilización de software es el proceso de crear sistemas de software a partir de [activos de] software existentes, en lugar de desarrollarlo desde el comienzo" (Sametinger, 1997)

• Implican el reuso de activos de software en:

– la especificación,

– el análisis,

– el diseño,

– la implementación y

– las pruebas de una aplicación o sistema de software



• Un activo de software reutilizable puede ser:

– Un componente de software (p.ej., un módulo, una clase, un

procedimiento, una función, un subsistema, una aplicación)

– Una especificación de requerimientos

– Un modelo o especificación de diseño

– Un algoritmo

– Un patrón de diseño

– Una arquitectura de dominio

– Un esquema de base de datos

– Una especificación de prueba

– La documentación de un sistema

– Un plan



• ¿Qué es un componente de software reutililizable (CSR)?

– Son artefactos de software auto-contenidos y claramente

identificables que:

• describen y/o ejecutan funciones específicas,

• tienen interfaces claras,

• tienen una documentación apropiada y

• tienen un status de reuso definido.

[Sametinger, 1997]

• Un CSR se integra con relativa facilidad a

un sistema de software en desarrollo

a través de su interfaz.



• Dos modalidades de desarrollo:

– Desarrollo de software para reutilización

• Propósito: producir componentes de software reutilizable

• Emplea el modelo de procesos de la Ingeniería de

Dominios

– Desarrollo de software con reutilización

• Propósito: desarrollar aplicaciones reutilizando

componentes existentes

• Emplea el modelo de procesos de la Ingeniería de

Aplicaciones



Ingeniería de Aplicaciones

Especificación

de requerimentos

Análisis del

Dominio

Diseño del

Dominio

Desarrollo de

Componentes

Diseño de la

Arquitectura

Especificación

De Componentes

Adapt / Des.

Componentes

Búsqueda de

Componentes

Integración de

Componentes

modelos

de

análisis

diseños

genéricoscomponentes

Ingeniería de Dominios


El estándar IEEE-1074

• Un estándar para desarrollar modelos de procesos y métodos de desarrollo de software

• Proporciona un marcometodológico para el diseño de modelos y métodos

• Emplea tres nivelesjerárquicos:

– Grupos de procesos

– Procesos

– Actividades

Process Group Processes Life Cycle Modeling

Selection of a Life Cycle Model

Project Management

Project Initiation Project Monitoring and Control Software Quality Management

Pre-development

Concept Exploration System Allocation

Development

Requirements Design Implementation

Post-development

Installation Operation & Support Maintenance Retirement

Integral Process

Verification and Validation Software Configuration Management Documentation Development Training


El estándar

IEEE-1074

Concept

Exploration Process

System

Allocation Process

Requirements

Process

Design

Process

Implementation

Process

Installation

Process

Configuration

Mgmt. Process

Project

Initiation Process

Retirement

Process

Maintenance

Process

Operation &

Support Processes

S/W Quality

Mgmt. Process

Project Monitoring

& Ctrl. Processes

Verification &

Validation Processes

Documentation

Developm. Process

Training

Process

Development

ProcessesManagement

Processes

Integral

Processes


El Modelo de Procesos WATCH



• Es un modelo de procesos orientado al desarrollo

de proyectos de software de pequeño o mediano

tamaño

• Es la evolución de la metodología MEDSI [Montilva,

1985]

• Integra los mejores aspectos de los siguientes

modelos y métodos:

– MEDSI-OO

– El modelo espiral

– Desarrollo incremental y por versiones

– El método OO de Bruegge y Dutoit



• El estándar IEEE 1074 fue utilizado para crear

la estructura de procesos del modelo

• Emplea el UML como su lenguaje de

modelado

• Metáfora utilizada: el reloj (watch)



• Está estructurado en 4 grupos de procesos:

– Ingeniería de Métodos– Definición del Proyecto

– Adaptación y conversión del modelo de procesos en unmétodo

– Documentación del método de desarrollo

– Procesos Gerenciales

– Procesos de Desarrrollo

– Procesos de Post-desarrollo– Operación y soporte

– Mantenimiento

– Retiro



Procesos Gerenciales:

– Iniciación del proyecto

– Gerencia del Proyecto

– Gestión de la Calidad

– Gestión de la

Configuración

– Verificación & Validación

– Adiestramiento

– Documentación

Procesos de Desarrollo

– Análisis del Dominio de

Aplicación

– Descubrimiento de

Requerimientos

– Análisis & Especificación de

Requerimientos

– Diseño del Sistema

– Diseño de Componentes

– Implementación del Sistema

– Pruebas del Sistema

– Entrega del Sistema


El Modelo

de

Procesos

WATCH

Análisis del

Dominio

Descubrim. de

Requerim.

Anal. & Espec.

de

Requerim.

Diseño del

Sistema

Diseño de

Componentes

Implement. del

Sistema

Pruebas del

Sistema

Entrega del

Sistema

Procesos

Gerenciales

Procesos de

Post-Desarr.


Procesos GerencialesProceso Actividades

Gerencia del Proyecto Planificación del proyecto

Organización del grupo de desarrollo

Dirección del grupo de desarrollo

Administración del personal del grupo

Control del proyecto

Gestión de la Calidad del

S/W

Planificación de la calidad del S/W

Aseguramiento de la calidad del S/W

Gestión de la Configuración Planificación de la gestion de configuración

Control de la configuración

Verificación & Validación Planificación de la V & V

Revisiones de Productos

Pruebas de Software

Adiestramiento Planificación del Adiestramiento

Adiestramiento del grupo de desarrollo

Producción del material de adiestramiento

Documentación Planificación de la Documentación

Elaboración de la Documentación

Entrega de la Documentación


Las Fases de Proceso de Desarrollo

Análisis del

Dominio

Descubrim, de

Requerim.

Anál. & Espec.

de Requerim.

Diseno del

Sistema

Diseño de

Componentes

Implement.

del

Sistema

Pruebas del

Sistema

Entrega del

Sistema


Fase 1: Análisis del Dominio de Aplicación

• Objetivo:

– Que el grupo de desarrollo adquiera un conocimiento adecuado

del dominio de aplicación (el contexto del sistema)

• Producto:

– Modelo del Dominio de Aplicación

Identificar los

actores del

dominio

Validar el

modelo del

dominio

Documentar

el modelo del

dominio

Modelar los

objetos del

dominio

Definir el

dominio de la

aplicación

Modelar los

procesos del

dominio

Act. técnica

Act. gerencial


Fase 2: Descubrimiento de Requerimientos

• Objetivo:

– Descubrir y definir informalmente los requerimientos de

los usuarios del sistema

• Productos:

– Documento de Definición de Requerimientos (DDR)

– Prototipo de la interfaz Usuario/Sistema (U/S)

Descubrir

Requerim.

Funcionales

Validar el

DDR

Elaborar el

documento

DDR

Elaborar un

prototipo de

la interfaz U/S

Descubrir

Requerim.

No-funcionales


Fase 3: Especificación de Requerimientos

• Objetivo:

– Expresar los requerimientos de los usuarios de una

manera formal o técnica que pueda ser entendida, sin

ambiguedad, por los diseñadores del sistema

• Producto:

– Documento de Especificación de Requerimientos (DER)

Derivar el

Modelo de

Objetos

Validar el

DER

Elaborar el

DER

Consolidar los

modelos

Derivar el

Modelo

Dinámico

Refinar el

Modelo

Funcional


Fase 4: Diseño del Sistema

• Objetivo:

– Traducir los requerimientos del usuario en una solución de software:

• una especificación del diseño del sistema

• Producto:

– Documento del Diseño del Sistema (DDS)

Diseñar la

base de datos

Validar el

DDS

Elaborar el

DDS

Diseñar la

documentación

del sistema

Diseñar la

arquitectura

del sistema

Diseñar la

interfaz U/S


Fase 5: Diseño de Componentes

• Objetivo:

– Especificar en detalle el diseño de cada componente y conector

de la arquitectura del sistema

• Producto:

– Documento de Diseño de Componentes (DDC)

Validar el

DDC

Elaborar el

DDC

Diseñar los

componentes

no reutilizables

Seleccionar y

buscar

compon.

reutilizables

Adaptar los

componentes

reutilizables

Especificar los

servicios de

c/componente


Fase 6: Implementación del Sistema

• Objetivo:

– Traducir las especificaciones de diseño en un producto de software

– Verificar que los programas implementan el diseño y asegurar su calidad

• Productos:

– Un sistema parcialmente probado

– Documentación del sistema

Producir la

documentación

Validar el

sistema

Probar los

componentes

Probar la

integración de

componentes

Codificar los

componentes

Planificar las

pruebas


Fase 7: Pruebas del Sistema• Objetivo:

– Asegurar que el sistema hace lo que el cliente y los usuariosquieren que haga

• Producto:

– Un sistema validado que está listo para ser instalado

Realizar las

pruebas

no-funcionales

Realizar la

prueba de

aceptación

Realizar

pruebas

funcionales

Planificar las

pruebas


Fase 8: Entrega del Sistema

•Objetivo:

•Transferir el sistema de su ambiente de desarrollo a su ambiente de operación

•Producto:

•Un sistema instalado y en operación


Realizar las

pruebas de

instalación

Entregar el

sistema al

cliente

Instalar el

sistema

Adiestrar a

los usuarios

Adiestrar a l

personal

de soporte

Planificar las

pruebas


Conclusiones

• Principales características del modelo WATCH:

– Es simple

– Es completo

– Es adaptable

• Su estructura permite al grupo de desarrollo adaptar el modelo a las

características particulares del proyecto

• Puede ser utilizado como un marco referencial para mejorar los

procesos de desarrollo de software en organizaciones pequeñas y

medianas

• Ha sido utilizado en el desarrollo de proyectos académicos en los

departamentos de computación de

– La Universidad del Sur de Florida (Tampa, USA)

– La Universidad de Los Andes


•www.e-praxis.org

www.biosoftca.com

http://www.e-praxis.org/



http://www.biosoftca.com/

Download - Modelos Procesos OxO

Top Related