Tema2

Análisis de Sistemas

TEMA 2Modelos de proceso del software

María N. Moreno GarcíaDepartamento de Informática y AutomáticaUniversidad de SalamancaUniversidad de Salamanca


ContenidosContenidos

1. Conceptos básicos2 P d l i l d id2. Procesos del ciclo de vida3. Modelos de proceso

Modelo clásicoModelo clásicoModelos iterativos basados en prototiposModelos evolutivosModelos en espiralDesarrollo rápido de aplicacionesModelos orientados a la reutilizaciónModelos orientados a la reutilizaciónModelos para sistemas orientados a objetosProcesos ágilesModelos de proceso de la Ingeniería Web

Modelos de proceso del software 2


Conceptos básicosConceptos básicos

Proceso del software: conjunto de actividades y resultados i d d l ió d d t ftasociados que conducen a la creación de un producto software

[Sommerville, 2002]Ciclo de vida del software: Aproximación lógica a la adquisición , p g q ,el suministro, el desarrollo, la explotación y el mantenimiento del software (norma IEEE 1074) [IEEE, 1999]El ciclo de vida incluyeEl ciclo de vida incluye

Ciclo de desarrollo del sistema Tiempo de vida del sistema

Modelo de ciclo de vida: Marco de referencia que contiene losModelo 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, b d l id d l i t d d l d fi i ió d l i itabarcando la vida del sistema desde la definición de los requisitos

hasta la finalización de su uso (norma ISO 12207-1) [ISO/IEC, 1995]Actividad: conjunto de tareasT ió t f t d lid


Tarea: acción que transforma entradas en salidas


Procesos del ciclo de vida (I)Procesos del ciclo de vida (I)

Procesos Principales Procesos de Soportep p

Adquisición

Suministro

Documentación

Gestión de la configuraciónSuministro

Explotación

Aseguramiento de la calidad

Verificación

ValidaciónDesarrollo

p

Mantenimiento

Resolución de problemas

Revisión conjuntaAuditoría

Procesos de la Organización

Resolución de problemas

Gestión

Mejora

Infraestructura

Formación


Procesos del ciclo de vida según la norma ISO 12207-1


Procesos del ciclo de vida (II)Procesos del ciclo de vida (II)Las actividades del ciclo de vida del software se pueden agrupar de la forma siguiente(norma ISO 12207-1) [ISO/IEC, 1995]

Procesos principalesAdquisición

Procesos de la organización (generales)Gestión

SuministroDesarrolloExplotación

GestiónMejoraInfraestructuraFormación

MantenimientoProcesos de soporte

Documentación Nuevos procesos (amendments 2002-2005)

Gestión de la configuraciónAseguramiento de la calidadVerificación

UsabilidadEvaluación de productosRecursos HumanosGestión de “assets”Verificación

ValidaciónRevisión conjuntaAuditoría

Gestión de assetsGestión de petición de cambiosGestión del programa de reutilizaciónIngeniería del dominio


AuditoríaResolución de problemas

g


Procesos del ciclo de vida (III)Procesos del ciclo de vida (III)

Procesos principales: Son los que resultan útiles a las personas i i i li l d ll l l t ió lque inician o realizan el desarrollo, la explotación o el

mantenimiento del software durante su ciclo de vidaProceso de adquisición: Actividades y tareas que se realizan para comprar un producto softwareProceso de suministro: Actividades y tareas que el suministrador realizaProceso de desarrollo: Contiene las actividades de análisis de requisitos, diseño, codificación, integración, pruebas e instalación y aceptaciónpProceso de explotación: Incluye la explotación del software y el soporte operativo a los usuariosProceso de mantenimiento: Aparece cuando el software necesitaProceso 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


mejora o adaptación


Procesos del ciclo de vida (IV)Procesos del ciclo de vida (IV)

Procesos de soporte: Sirven de apoyo al resto y se aplican en cualquier punto del ciclo de vidapunto del ciclo de vida

Proceso de documentación: Registra la información producida por un proceso o actividad en el ciclo de vidaProceso de gestión de la configuración: Aplica ciertos procedimientos y técnicas durante todo el ciclo de vida del sistemaProceso 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 establecidosespecificados y se ajustan a los planes establecidosProceso de verificación: Determina si los requisitos de un sistema o del software están completos y son correctosProceso de validación: Sirve para determinar si el sistema o software final

l l i it i tcumple con los requisitos previstos para su usoProceso 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 proyectoProceso de auditoría: Permite determinar en los hitos predeterminados si seProceso de auditoría: Permite determinar, en los hitos predeterminados, si se han cumplido los requisitos, los planes y el contratoProceso de resolución de problemas: Permite analizar y eliminar los problemas descubiertos durante el desarrollo, explotación, el mantenimiento u otro proceso


otro proceso


Procesos del ciclo de vida (V)Procesos del ciclo de vida (V)

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

P d tió A ti id d t é i dProceso 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 personalProceso de formación: Sirve para proporcionar y mantener al personal formado



Procesos del ciclo de vida (VI)Procesos del ciclo de vida (VI)

Proceso de adaptación: Sirve para realizar la adaptación básica de la norma ISO 12207 con respecto a los proyectos software Es necesarionorma ISO-12207 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 yBajo el punto de vista del contrato, el comprador y el proveedor negocian y firman un contrato, empleando los procesos de adquisición y suministroBajo el punto de vista de gestión, el comprador, el proveedor, el desarrollador, el operador y el personal de mantenimiento gestionan sus respectivos procesosoperador y el personal de mantenimiento gestionan sus respectivos procesos para el proyecto softwareBajo el punto de vista de explotación, el operador proporciona el servicio de explotación del software a los usuariosBajo 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



Modelos de procesoModelos de proceso

Modelos tradicionalesF d j t d f

Modelos orientados a la reutilizaciónFormados por un conjunto de fases o

actividades en las que que no tienen en cuenta la naturaleza evolutiva del software

reutilizaciónBasado en componentesProceso Unificado

Modelos para sistemassoftwareClásico, lineal o en cascadaEstructuradoBasado en prototipos

Modelos para sistemas orientados a objetosModelos con un alto grado de iteratividad y solapamiento entrep p

Desarrollo rápido de aplicaciones (RAD)

Modelos evolutivosSon modelos que se adaptan a la

iteratividad y solapamiento entre fases

De agrupamientoFuenteSon modelos que se adaptan a la

evolución que sufren los requisitos del sistema en función del tiempo

En espiral

Basado en componentesProceso Unificado

Procesos ágilespEvolutivoIncrementalModelo de desarrollo concurrente

gProgramación extrema (XP)Desarrollo de software adaptativoScrum, Crystal …



Modelos de proceso 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ísticasCa acte st casEstá compuesto por una serie de fases que se ejecutan secuencialmenteObtención de documentos como criterio de finalización de fase

Problemas de la progresiónProblemas de la progresión secuencial

Desconocimiento de las necesidades por parte del

Análisis

necesidades por parte del clienteInestabilidad de los requisitosNo se ven resultados hasta

Diseño

Codificaciónmuy avanzado el proyectoEfecto big bang próximo a la entrega Prueba


Ciclo de vida clásico


Modelos de proceso Modelo clásico (II)

Modelo satisfactorio sólo en desarrollos conocidos y establesEl desconocimiento y el riesgo suele ser alto en el desarrollo del softwareEl desconocimiento y el riesgo suele ser alto en el desarrollo del softwareLa 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 haciacorrecciones hacia arriba, en función de los descubrimientos realizados hacia abajoEstos retornos entre fases perturban la visión lineal dada por el ciclo de vida en cascadaLos retornos están limitados a fases adyacentes

Análisis

Diseño

Codificación

Prueba


Ciclo de vida clásico con realimentación


Modelos de proceso Modelos iterativos basados en prototipos (I)

Un prototipo es un modelo experimental de un sistema o de un componente de un sistema que tiene los suficientes elementos que permiten su uso

Objetivos:

Son un medio eficaz para aclarar los requisitos de los usuarios e identificar las características de un sistema que deben cambiarse o añadirse

Mediante el prototipo se puede verificar la viabilidad del diseño de un sistemaed a te e p otot po se puede e ca a ab dad de d se o de u s ste a

Características:Es una aplicación que funciona

Su finalidad es probar varias suposiciones con respecto a las características requeridas por el sistema

Se crean con rapidezSe crean con rapidez

Evolucionan a través de un proceso iterativo

Tienen un costo bajo de desarrollo



Modelos de proceso Modelos iterativos basados en prototipos (II)

Tipos de prototiposPrototipos desechables: El prototipo es una versión rudimentaria del sistema quePrototipos desechables: El prototipo es una versión rudimentaria del sistema que posteriormente es desechadaPrototipos evolutivos: El prototipo debe convertirse, eventualmente, en el sistema final usado (alternativa al ciclo de vida)sistema final usado (alternativa al ciclo de vida)Combinación de prototipos evolutivos y desechables (prototipado operativo):

Se aplican técnicas convencionales para los requisitos bien conocidos y se crea una ”línea base”línea baseCombinación de prototipos desechables y evolutivos para los requisitos poco conocidos

DESECHABLE EVOLUTIVO

Enfoque de desarrollo Rápido y sin rigor Riguroso

Qué construir Sólo las partes bl áti

Primero las partes bien entendidas. S b b ólidQué construir problemáticas Sobre una base sólida.

Directrices del diseño

Optimizar el tiempo de desarrollo Optimizar la modificabilidad

Objetivo


último Desecharlo Incluirlo en el sistema

Diferencias entre los prototipos desechables y evolutivos


Modelos de proceso Modelos iterativos basados en prototipos (III)

Prototipos desechablesCaracterísticas:

Se desarrolla código para explorar factores críticos para el éxito del sistemaLa implementación usa lenguajes y/o métodos de desarrollo más rápidos que los definitivosdefinitivosSe usa como herramienta auxiliar de la especificación de requisitos y el diseño:

Determinar la viabilidad de los requisitosvalidar la funcionalidad del sistemaEncontrar requisitos ocultos.qDeterminar la viabilidad de la interfaz de usuario.Examinar alternativas de diseño. Validar una arquitectura de diseño particular

Aplicaciones:p cac o esInterfaz de usuarioFormatos de informesFormatos de gráficosOrganización de bases de datosOrganización de bases de datosRendimiento de bases de datosPrecisión e implementación de cálculos complejosPartes con respuesta crítica en el tiempo en sistemas de tiempo real


Rendimiento de sistemas interactivosViabilidad de partes del sistema en las que no se tiene experiencia


Modelos de proceso Modelos iterativos basados en prototipos (IV)

Prototipado evolutivo (ciclo de vida iterativo)Características:

Enfoque de desarrollo que se utiliza cuando no se conoce con seguridad lo que se quiere construirSe comienza diseñando e implementando las partes más destacadas del sistemaLa evaluación del prototipo proporciona la realimentación necesaria para aumentar y refinar el prototipoEl prototipo evoluciona y se transforma en el sistema final

Concepto inicial

Diseño e implementación

del prototipo i i i l

Refinar el prototipo hasta que sea

aceptable

Completar y entregar el prototipo

inicial

Modelos de proceso del software 16Modelo de prototipado evolutivo


Modelos de proceso Modelos evolutivos

Características:S d ll i l t ió i i i l fi t é d dif t iSe desarrolla una implementación inicial y se refina a través de diferentes versionesLas actividades de especificación, desarrollo y validación se llevan a cabo concurrentemente y con realimentación entre ellasLa especificación se puede desarrollar de forma crecienteLa especificación se puede desarrollar de forma creciente

Problemas:El proceso no es visibleLos cambios tienden a corromper la estructura del softwareLos cambios tienden a corromper la estructura del softwareSe requieren herramientas y técnicas especiales

Especificación Versión inicial

Versiones Bosquejo de la Desarrollo

Validación Versión final

intermediasBosquejo de la

descripción


Validación Versión final


Modelos de proceso Modelos en espiral (I)

Ciclo de vida en espiralFue propuesto inicialmente por B. Boehm [Boehm, 1986, 1988]

Es un modelo de proceso de software evolutivo, que proporciona el potencial para el desarrollo rápido de versiones incrementales del software

CaracterísticasCaracterísticasPuede 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 i d t E l d l i i l d B h tregiones de tareas. En el modelo original de Boehm aparecen cuatro

regiones de tareasPlanificación, Análisis de riesgos, Ingeniería, Evaluación del cliente


El avance se realiza desde el centro de la espiral hacia el exterior


Modelos de proceso Modelos en espiral (II)

Determinar objetivos,alternativasy restricciones

Evaluar alternativas Identificar y resolver riesgos Análisis

de riesgo

AnálisisAnálisisde riesgo

Análisisde riesgo

Análisis Proto-Proto-ti 2

Proto-tipo 3

Plan de requisitos y del ciclo de vida

de riesgoProto-tipo 1

tipo 2 t po 3

SimulacionesOperación

Espec.requisitos Diseño

Diseño

Desarrollo, verificación del

Plan de desarrollo

Plan deintegración y prueba

Validaciónrequisitos

V & Vdiseño

Diseñodetallado

Codifi-cación

Pruebasunidad

Pruebas

Plan para la próxima fase

siguiente nivel del producto

Pruebasaceptación.Servicio.


Ciclo de vida en espiral [Boehm, 1988]


Modelos de proceso Modelos en espiral (III)

Modelo en espiral de Pressman [Pressman, 2002]Variante del modelo de Boehm con 6 regiones de tareas

Se define un eje con diferentes puntos de entrada para diferentes tipos de t

Análisis de riesgos

Planificación Análisis de riesgos

Planificación

proyectos

Comunicacióncon el cliente

riesgos Comunicacióncon el cliente

riesgos

Puntos de entrada al proyecto

Proyecto de mantenimiento de productos

ingeniería

Proyecto de mejora de productos

Proyecto de desarrollo de productos nuevos

P d d ll d

Evaluación del clienteEvaluación del cliente

Construcción y adaptación

Proyecto de desarrollo de conceptos


Modelo en espiral de Pressman


Modelos de proceso Modelos en espiral (IV)

Modelo win-win [Boehm et al., 1998]Extiende el modelo en espiral haciendo énfasis en las condiciones de éxito (ganancia) de todas las partes involucradas en el proyectoConsta de cuatro ciclos:Consta de cuatro ciclos:

Ciclo 0. Grupos de aplicación: Determinación de la viabilidad de un grupoCiclo 1. Objetivos del ciclo de vida de la aplicación: objetivos, prototipos, planes especificaciones de cada aplicación y arquitectura viableplanes, especificaciones de cada aplicación y arquitectura viableCiclo 2. Arquitectura del ciclo de vida de la aplicación: establecimiento de una arquitectura detallada y verificación de su viabilidadC C ó óCiclo 3. Capacidad de operación inicial: consecución de la capacidad para cada etapa crítica del proyecto

Cada ciclo se compone de cuatro actividades:Elaborar objetivos, restricciones y alternativasEvaluar alternativas respecto a los objetivos y restriccionesElaborar la definición del producto y del proceso


Elaborar la definición del producto y del procesoPlanificar el siguiente ciclo


Modelos de proceso 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ó comoApplication Development) o modelo de la caja de tiempo surgió como respuesta al modelo formal y al ciclo en espiralEnfatiza un ciclo de desarrollo extremadamente corto

M d l f i l 60 ó 90 díModelo funcional en 60 ó 90 díasNo es un modelo bien definido

Secuencia de integraciones de un sistema evolutivo o de prototipos que se revisan con el cliente descubrimiento de los requisitosCada integración se restringe a un período de tiempo bien definido (caja de tiempo)

C t í tiCaracterísticasModelo secuencial: Separación en fases de cada caja de tiempoIntegraciones constantesCentrado en el código más que en la documentaciónDesarrollo basado en componentesUso efectivo de herramientas y frameworks


Participación activa del usuario


Modelos de proceso

ModeladoEquipo nº 3Equipo nº 3

Desarrollo rápido de aplicaciones (II)

Cuando se utiliza en S.I. Automatizados, comprende las fases [Kerr

de gestiónModeladode datos

Modeladode procesos

Modeladode gestión

Equipo nº 2Equipo nº 2

comprende las fases [Kerr y Hunter, 1994]

Modelado de gestiónModeladode gestión

Gener. de aplicaciones

Pruebas yentrega

de gestiónModeladode datos

Modeladode procesos

Equipo nº 1Equipo nº 1

Modelado de datosModelado del procesoGeneración de

Modeladode datos

Modelado

Gener. de aplicaciones

Pruebas yentrega

Generación de aplicacionesPruebas y entrega

Modeladode procesos

Gener. de aplicacionesp

Pruebas yentrega

De 60 a 90 díasDe 60 a 90 días


Modelo DRA [Kerr y Hunter, 1994]


Modelos de proceso Desarrollo rápido de aplicaciones (III)

Las limitaciones de tiempo demandan un ámbito de escalasp

Si una aplicación de gestión puede modularse de forma que pueda completarse cada una de las funciones principales en p p p pmenos 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



Modelos de proceso Modelos orientados a la reutilización (I)

Enfoque de desarrollo que trata de maximizar la reutilización de software i t t [S ill 2002]existente [Sommerville, 2002]

Las unidades software reutilizables pueden ser de diferente tamaño:Sistemas de aplicaciones: se reutiliza la totalidad del sistema

Sin ningún cambio (reutilización de productos COTS)Desarrollo de familias de aplicaciones para plataformas diferentes o necesidades específicas

Componentes: la reutilización va desde subsistemas hasta objetos simplesFunciones: componentes de software que implementan una sola función

Familias de aplicaciones o líneas de productos: conjunto relacionado de aplicaciones que tiene una arquitectura común de dominio específico. Existen varios tipos de especialización:

De la plataforma: varias versiones de la aplicación se desarrollan para diferente plataformaDe la configuración: se crean diferentes versiones para manejar diversos dispositivos periféricos


De la funcionalidad: diferentes versiones para clientes con requisitos diferentes


Modelos de proceso Modelos orientados a la reutilización (II)

Desarrollo basado en componentes (I)C fi li i ti d t d ft dConfigura aplicaciones a partir de componentes de software preparados [Pressman, 2002]Enfoque iterativo y evolutivo [Nierstrasz, 1999]Se enmarca en un contexto más amplio: ingeniería del software basada enSe enmarca en un contexto más amplio: ingeniería del software basada en componentes

Análisis de Planificación Identificar

componentes Análisis de Planificación Identificar

componentes


riesgos candidatos

Buscar componentes en bibliotecas

Construir la iteración del

sistema


riesgos candidatos

Buscar componentes en bibliotecas

Construir la iteración del

sistema en bibliotecassistema

Extraer componentes disponibles

Poner nuevos componentes en biblioteca

en bibliotecassistema

Extraer componentes disponibles

Poner nuevos componentes en biblioteca

Evaluación del cliente

Construcción y adaptación de la ingeniería

Construir componentes

di ibl

disponiblesen biblioteca

Evaluación del cliente

Construcción y adaptación de la ingeniería

Construir componentes

di ibl

disponiblesen biblioteca


no disponibles no disponibles


Modelos de proceso Modelos orientados a la reutilización (III)

Desarrollo basado en componentes (II)p ( )Un componente es una unidad ejecutable e independiente

Los componentes publican su interfaz y todas las interacciones son a través de ella

Una interfaz que se suministra define los servicios que ofrece el componente

Una interfaz que se solicita especifica qué servicios deben estar disponibles

Para el desarrollo con reutilización:Debe ser posible encontrar los componentes re tili ables apropiadosDebe ser posible encontrar los componentes reutilizables apropiados

Se debe confiar en que los componentes que se utilizan se comportan conforme a lo especificado y son fiables

Los componentes deben tener documentación asociada para ayudar a comprenderlos y adaptarlos a una nueva aplicación



Modelos de proceso Modelos orientados a la reutilización (IV)

Ingeniería del software basada en componentes

Ingeniería del dominioDesarrollo basado en Análisis del Desarrollo de

l it tDesarrollo de

t

Ingeniería del dominio

Análisis del Desarrollo de l it t

Desarrollo de t

Ingeniería del dominio

El objetivo de la ingeniería del

Desarrollo basado en componentes

dominio la arquitectura del software

Modelo del d i i

componentes reutilizables

Modelo t t l

Artefactos/ componentes

tili bl

dominio la arquitectura del software

Modelo del d i i

componentes reutilizables

Modelo t t l

Artefactos/ componentes

tili blEl objetivo de la ingeniería deldominio es identificar, construir,catalogar y diseminar unconjunto de componentes de

Desarrollo basado en

dominio estructural reutilizables de la reserva

Cualificación de Actualización de componentes

Desarrollo basado en

dominio estructural reutilizables de la reserva

Cualificación de Actualización de componentesconjunto de componentes de

software que tienen aplicaciónen el software actual y futurod t d d i i d

basado en componentes

Diseño arquitectónico Análisis

componentes

Adaptación de componentes

Composición de

componentes

Software de aplicaciones

basado en componentes

Diseño arquitectónico Análisis

componentes

Adaptación de componentes

Composición de

componentes

Software de aplicaciones

dentro de un dominio deaplicación particular

[Presman 2001]

Composición de componentes

Ingeniería de componentes Comprobación

Composición de componentes

Ingeniería de componentes Comprobación


Ingeniería del software basada en componentes[Presman, 2001]


Modelos de proceso Modelos orientados a la reutilización (V)

Actividades de la ingeniería del dominioAnálisis del dominio:

Definir el dominio a investigarCategorizar los elementos extraídos del dominioRecoger una muestra representativa de las aplicaciones del dominioRecoger una muestra representativa de las aplicaciones del dominioAnalizar cada aplicación de la muestraDesarrollar un modelo de análisis para los objetosDefinir un lenguaje del dominio: hace posible la especificación y construcciónDefinir un lenguaje del dominio: hace posible la especificación y construcción posterior de aplicaciones dentro del dominio

Modelo del dominio: resultado de las actividades anterioresModelado estructural: Enfoque de ingeniería basado en tramas queModelado estructural: Enfoque de ingeniería basado en tramas que opera efectuando la suposición consistente de que todo dominio de aplicación posee tramas repetidas (de función, de datos y de comportamiento) que tienen un potencial de reutilización

Todo dominio de aplicación se puede caracterizar por un modelo estructuralUn modelo estructural es un estilo arquitectónico reutilizablePunto de estructura: estructura bien diferenciada dentro de un modelo

t t l ( é i li i li t b d d t t d ál l


estructural (genéricos: aplicaciones cliente, bases de datos, motores de cálculo, función de reproducción de informes, editor de aplicaciones)


Modelos de proceso Modelos orientados a la reutilización (VI)

Actividades del desarrollo basado en componentesActividades del desarrollo basado en componentes

Cualificación de componentes: Asegura que un componente candidato llevará a cabo la función necesaria, encajará en el estilocandidato llevará a cabo la función necesaria, encajará en el estilo arquitectónico del sistema y tendrá la calidad requeridaAdaptación de componentes: Elimina conflictos de integración

Enmascaramiento de caja blanca, gris o negraComposición de componentes: Ensambla componentes cualificados, adaptados y diseñados para la arquitectura , p y p qestablecidaIngeniería de componentes: Diseño de componentes para su reutilizaciónreutilizaciónActualización de componentes: El software actual se reemplaza a medida que se dispone de nuevas versiones de componentes



Modelos de proceso Modelos para sistemas OO (I)

CaracterísticasEliminación de las fronteras entre fases

Desarrollo basado en componentes reutilizablesDesarrollo 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 de proceso Modelos para sistemas OO (II)

Modelo de agrupamiento (I)Propuesto por Bertrand Meyer [Meyer, 1990]Concepto clave: AGRUPAMIENTO (cluster) [Meyer, 1999]

Unidad organizativa básicaUnidad organizativa básicaGrupo de clases relacionadas o, recursivamente, clustersrelacionadosU id d t l l d ll t d ú i d ll dUnidad natural para el desarrollo por parte de un único desarrolladorEvita el efecto todo-nada propio del modelo en cascada

Tiene un componente secuencial y un componente concurrentep y pExistencia de diferentes subciclos de vida (uno para cada cluster) que pueden solaparse en el tiempoCada subciclo de vida que gobierna el desarrollo de un cluster está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


Generalización


Modelos de proceso Modelos para sistemas OO (III)

Modelo de agrupamiento (II)Enfoque ascendente

La ocultación de la información posibilita la forma del modelo de clusters de ingeniería concurrente

Espec DisReaDisRea ValGenValGen Agrupamiento n

Tiem

po

Espec DisReaDisRea ValGenValGen

Espec DisReaDisRea ValGenValGen Agrupamiento 2

Espec DisReaDisRea ValGenValGen Agrupamiento 1

Tiempo


Distribución temporal de las fases de cada agrupamiento


Modelos de proceso Modelos para sistemas OO (IV)

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

P d d l d i l d idPropone dos modelos de ciclo de vidaPara el sistema completo

Para cada clase o módulo: Cada clase puede estar en una fasePara 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 de proceso Modelos para sistemas OO (V)

Modelo fuente (II)Utilización

Utilización

EvoluciónMantenimiento

Utilización

GeneralizaciónRe-evaluación

GeneralizaciónRe-evaluación

Pruebas

PruebasSistema Implemen-

tación

Prueba

DiseñoComponentesCodificación

PruebasUnitarias Diseño de

Componente

DiseñoConceptual

tación

Estudio de Análisis

DiseñoConceptual

Análisis

Conceptual

viabilidad yrequisitos

Piscina SW Piscina SW

Requisitos


Piscina SWModelo fuente para el sistema y para un componente


Modelos de proceso

El proceso unificado (I)Modelos para sistemas OO (VI)

Definido por Rational Software Corporation [Jacobson et al., 2000]Evolución del proceso Objectory de RationalUtilización de UML [Booch et al., 1999] como lenguaje de modelado[ , ] g jBasado en componentes

CaracterísticasConducido por casos de usoConducido por casos de uso

Los casos de uso 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 arquitecturaLa arquitectura se describe mediante diferentes vistas del sistema. Es i t t t bl it t bá i t li t tiimportante establecer una arquitectura básica pronto, realizar prototipos, evaluarla y finalmente refinarla durante el curso del proyecto

Iterativo e incrementalResulta práctico dividir los grandes proyectos en mini proyectos cada uno


Resulta práctico dividir los grandes proyectos en mini proyectos, cada uno de los cuales es una iteración que resulta en un incremento


Modelos de proceso

El proceso unificado (II)

Modelos para sistemas OO (VII)

El Proceso Unificado se repite a lo largo de una serie de ciclosCada ciclo consta de cuatro fases:

Inicio: se define el alcance del proyecto y se desarrollan los casos de negociocasos de negocioElaboración: se planifica el proyecto, se especifican en detalle la mayoría de los casos de uso y se diseña la

it t d l i tarquitectura del sistemaConstrucción: se construye el productoTransición: el producto se convierte en versión beta SeTransición: el producto se convierte en versión beta. Se corrigen problemas y se incorporan mejoras sugeridas en la revisión



Modelos de proceso

El proceso unificado (III)

Modelos para sistemas OO (VIII)

Dentro de cada fase se puede, a su vez, descomponer el trabajo en iteraciones con sus incrementos resultantesCada fase termina con un hito, cada uno de los cuales se caracteriza por la disponibilidad de un conjunto de componentes de softwarede software

Objetivos de los hitos:Toma de decisiones para continuar con la siguiente faseControlar el progreso del proyectoProporcionar información para la estimación de tiempo y recursos de proyectos sucesivosrecursos de proyectos sucesivos



Modelos de proceso

El proceso unificado (IV)

Modelos para sistemas OO (IX)

El proceso unificado (IV)Cada ciclo concluye con una versión del producto para los clientes

tiempotiempo

Inicio Elaboración Construcción Transición

Vista Vista Línea base de arquitectura

Línea base de arquitectura

Capacidadinicial

Capacidadinicial

Versión delproducto

Versión delproducto

Inicio Elaboración Construcción TransiciónInicio Elaboración Construcción Transición

Arqu.Iteración

... Des.Iteración

Des.Iteración

... Trans.Iteración

...PrelimIteración

... Arqu.Iteración

... Des.Iteración

Des.Iteración

... Trans.Iteración

...PrelimIteración

...


VersiónVersión VersiónVersión VersiónVersión VersiónVersión VersiónVersión VersiónVersión VersiónVersión


Modelos de proceso Modelos para sistemas OO (X)

El proceso unificado (IV)L it i di l l d l fl j d t b jLas iteraciones discurren a lo largo de los flujos de trabajo

FasesFlujos de trabajo Inicio Elaboración Construcción Transición

Requisitos

Inicio Elaboración Construcción Transición

Diseño

Análisis

Implementación

ite r. ite r. ite r. ite r. ite r. iter. ite r.

Pruebas

Iteraciones


#1 #2 #n #n+1 #n+2 #m #m+1

Iteraciones

preliminares


Modelos de proceso Procesos ágiles (I)

Los procesos ágiles constituyen un nuevo enfoque en el desarrollo de software cuyas principales características son:de software cuyas principales características son:

Menor énfasis en el análisis, diseño y documentaciónEquipos pequeñosDesarrollo incrementalDesarrollo incrementalProgramación (planificación temporal) en cajas de tiempoSupervivencia en un entorno caótico

L i i á il l té i d tióLas aproximaciones ágiles emplean procesos técnicos y de gestión que continuamente se adaptan y se ajustan a (Turk et al., 2002)

Cambios derivados de las experiencias ganadas durante el desarrollogCambios en los requisitos Cambios en el entorno de desarrollo

Diversas aproximacionesDiversas aproximaciones XP (eXtreme Programming) [Beck, 1999]Crystal [Alistair Cockburn, 1999]


Proceso Software Adaptativo [Jim Highsmith, 2000]Scrum [Schwaber, 1995]


Modelos de proceso Procesos ágiles (II)

Programación extrema (I) [Beck, 1999]Nuevo y controvertido enfoque de desarrollo de software basado en el modelo incrementalEstá indicado para p

Equipos de tamaño mediano o pequeñoRequisitos imprecisos y cambiantes

C t í tiCaracterísticas:El juego de la planificaciónVersiones pequeñas

Programación en parejasPropiedad colectiva

MetáforaDiseño sencilloHacer pruebas

Integración continuaCliente in-situEstándares de codificaciónp

RefactoringSegún Beck (2000) XP descansa sobre cuatro valores

Comunicación

Estándares de codificación

Realimentación


ComunicaciónSencillez

RealimentaciónValentía


Modelos de proceso Procesos ágiles (III)

Programación extrema (II)Dif i t ét d (B k 2000)Diferencia con otros métodos (Beck, 2000)

Su inmediata, concreta y continua realimentación de los ciclos cortosSu enfoque de planificación incremental, que rápidamente plantea un plan global que se espera que evolucione a lo largo de la vida del proyectoglobal que se espera que evolucione a lo largo de la vida del proyectoSu capacidad para programar de forma flexible la implementación de las funcionalidades, respondiendo a las necesidades cambiantes de los negociosSu confianza en las pruebas automatizadas, escritas por los programadores y los clientes para controlar el progreso del desarrollo, para permitir la evolución del sistema y captar los defectos lo antes posibleSu confianza en la comunicación oral las pruebas y el código fuente paraSu confianza en la comunicación oral, las pruebas y el código fuente para comunicar la estructura e intención del sistemaSu confianza en el proceso de diseño evolutivo que perdura mientras perdura el sistemaSu confianza en la colaboración estrecha entre programadores con habilidades normalesSu confianza en las prácticas que funcionan tanto con los instintos a corto plazo de los programadores como con los intereses a largo plazo del


plazo de los programadores como con los intereses a largo plazo del proyecto


Modelos de proceso Procesos ágiles (IV)

Desarrollo de software adaptativo (I) [Highsmith, 2000]

M d l á il d t ti b d l l b ió i t d lModelo ágil y adaptativo basado en la colaboración y orientado al desarrollo de sistemas complejosFases del ciclo de vida:

EspeculaciónInicio del proyectoPlanificación del ciclo adaptativo: enunciado, restricciones y requisitos básicos

Plan de lanzamiento: definición de un conjunto de ciclos (incrementos)

ColaboraciónConstruir la funcionalidad definida en la fase anteriorConstruir la funcionalidad definida en la fase anteriorUso de técnicas JAD (Joint Application Development) y trabajo colaborativo

AprendizajeRevisión de calidad al final de cada cicloRevisión de calidad al final de cada cicloAprendizaje

Grupos enfocadosRevisiones técnicas formales


Revisiones técnicas formalesPost mortem


Modelos de proceso Procesos ágiles (V)

Desarrollo de software adaptativo (II)



Modelos de proceso Modelo de proceso de la Ingeniería Web (I)

Las características de sistemas y aplicaciones basados en Web influyen enormemente en el proceso de Ingeniería Web (IWeb):influyen enormemente en el proceso de Ingeniería Web (IWeb):

Intensivas de redControladas por contenidoEvolución continuaInmediatezE tétiEstética …

El ciclo de desarrollo de una aplicación Web consta de las siguientes fases de ingeniería: g

Definición y análisis de los sistemas Web Diseño de los sistemas Web

Diseño arquitectónicoDiseño arquitectónico Diseño de la navegación Diseño de la interfaz

Pruebas de las aplicaciones Web


Pruebas de las aplicaciones Web


Modelos de proceso Modelo de proceso de la Ingeniería Web (II)

Modelo de Pressman (I) [Pressman, 2002]

PlanificaciónPlanificación

Análisis

FormulaciónDiseño del contenido

Diseño arquitectónico

IngenieríaProducción Diseño de

la navegación

Generación depáginas y

Evaluacióndel cliente

Diseño de lainterfaz

páginas ypruebas


Modelo de proceso de IWEB [Pressman, 2002]


Modelos de proceso Modelos de proceso de la Ingeniería Web (III)

Modelo de Pressman (II)Formulación: identificación de metas y objetivosPlanificación: estimación de costes, evaluación de riesgos y planificación temporal del proyectoAnálisis: establecimiento de requisitosIngeniería: dos grupos de tareas paralelasIngeniería: dos grupos de tareas paralelas,

Técnicas (diseño arquitectónico, de navegación y de interfaz)No técnicas (diseño del contenido y producción)( y p )

Generación de páginas y pruebasEl contenido se fusiona con los diseños arquitectónico, de navegación y de interfaz para elaborar páginas web ejecutables en HTML, JSP...Integración con el software intermedio (middleware) de componentes

Evaluación con el cliente: revisión de cada incremento y solicitud de


Evaluación con el cliente: revisión de cada incremento y solicitud de cambios


Modelos de proceso Modelos de proceso de la Ingeniería Web (IV)

Modelo de Pressman (III) [Pressman, 2006] Comunicación con el cliente:

Análisis de negocioF l ióFormulación

Planificación: definición de tareas y calendario para el desarrollo de un incrementoModelado: las actividades de análisis y diseño convencionales se adaptan y se funden con las específicas de las aplicaciones WebConstrucción: construcción y prueba de un incrementoDespliegue

C fi ió d l li ió bi t tiConfiguración de la aplicación para su ambiente operativoEntrega a los usuariosEvaluación


Las actividades se realizan siguiendo un flujo de proceso incremental


Modelos de proceso Modelos de proceso de la Ingeniería Web (V)

El proceso unificado en la Ingeniería Web (I)La clave para utilizar el Proceso Unificado en el desarrollo de aplicacionesLa clave para utilizar el Proceso Unificado en el desarrollo de aplicaciones Web la dan los casos de uso (Ward y Kroll, 1999)

Integran el marco de ingeniería, que ofrece el Proceso Unificado, con el proceso de diseño creativo que caracteriza a las aplicaciones Web Ofrecen una forma de expresar en términos comunes un entendimiento compartido del comportamiento esperado de la aplicación Web Juegan el papel de lengua franca en los proyectos software, es decir, son el lenguaje hablado por todos los implicados en la definición y el desarrollo del sistema Web

Integración del diseño creativo en el desarrolloRequisitosDiseño creativo

Prototipo inicial de IU WebGuías IUDiseño creativo

Mapa de navegaciónSimulación del diseño creativo

Guías IUPrototipo completo de IU WebMapa de navegación completo


Elementos de diseño Web


Modelos de proceso Modelos de proceso de la Ingeniería Web (VI)

El proceso unificado en la Ingeniería Web (II)



Modelos de proceso Modelos de proceso de la Ingeniería Web (VII)

El proceso unificado en la Ingeniería Web (III)R i itRequisitos

VisiónAcuerdo sobre los problemas que deben resolverseD fi i ió d l lí it d l i tDefinición de los límites del sistemaDescripción de las características más importantes del sistema

Modelo de casos de uso: documentación de los requisitos que permite a los usuarios articular sus necesidades (servicios del sistema)usuarios articular sus necesidades (servicios del sistema)

Los actores representan a los usuariosLos casos de uso representan los servicios

Especificación suplementaria: contiene los requisitos no funcionales. ConvieneEspecificación suplementaria: contiene los requisitos no funcionales. Conviene desarrollar un glosario con la terminología común del proyecto

Diseño creativo: guías iniciales de la interfaz de usuarioEl “humor del sitio”El humor del sitioCómo accederán los usuarios al sitio, qué navegadores usaránSi el sitio tendrá marcosLi it i d l d l iti


Limitaciones de color del sitioAspectos relativos a gráficos, animaciones...


Modelos de proceso Modelos de proceso de la Ingeniería Web (VIII)

El proceso unificado en la Ingeniería Web (IV)Mapa de navegación: representación jerárquica de la navegación deMapa de navegación: representación jerárquica de la navegación de los usuarios en el sitio (site map)

El número de niveles representa el número de clicks necesarios para llegar a una páginaa una páginaToma como referencia el modelo de casos de usoSe identifican “páginas lógicas” candidatas para la interfaz de usuario. Se representan en el análisis con el constructor UML boundary classp y



Modelos de proceso Modelos de proceso de la Ingeniería Web (IX)

El proceso unificado en la Ingeniería Web (V)Si l ió d l di ñ ti ti id d d t ti d d lSimulación del diseño creativo: actividad de prototipado de la interfaz de usuario de RUP

Se toma un caso de uso principal y se generan diseños alternativosSe construyen prototipos de los diseños seleccionados por losstakeholders

Elementos de diseño Web: imágenes gráficas discretas que seElementos de diseño Web: imágenes gráficas discretas que se ensamblan para construir la página web

Reutilización de componentes gráficos estándarIdentificación de componentes a partir de casos de usoSe crean en paralelo con el diseño inicial del prototipo de IU

Prototipo inicial de IU Web: actividad RUP de protototipado de laPrototipo inicial de IU Web: actividad RUP de protototipado de la interfaz de usuario

Soporta sólo una porción del sistemaSe utilizan los elementos de diseño identificados en la etapa anterior


Se utilizan los elementos de diseño identificados en la etapa anterior


Modelos de proceso Modelos de proceso de la Ingeniería Web (X)

El proceso unificado en la Ingeniería Web (VI)

Guías IU: actividad RUP de Guías de desarrollo de IUPrototipo completo de IU Web: extiende el prototipo inicial para cubrir todos los casos de usocubrir todos los casos de uso

Muestra la navegación completa entre pantallas y todos los elementos visuales del sitioLas páginas del prototipo se refinarán de forma iterativa en el desarrollo

Mapa de navegación completoMapa de navegación completoSe basa en el mapa inicial y en la definición completa de los casos de usoI l t d l á i / t ll d l t ti IU W bIncluye todas las páginas/pantallas del prototipo IU Web



Modelos de proceso Modelos de proceso de la Ingeniería Web (XI)

UWE (UML-based Web Engineering) (I)[Koch 2001; Hennicker y Koch 2000][Koch, 2001; Hennicker y Koch, 2000]

Desarrollo iterativo e incremental: basado en el Proceso unificado

Uso de UML: perfil UML propioCentrado en la sistematización y automatización:

áProceso sistemático de diseñoGeneración semiautomática de aplicaciones web a través de un framework de publicación XML (UWEXML)(UWEXML)

UWE comprende:Una notaciónUn métodoUn métodoUn metamodeloUn proceso de desarrolloUna herramienta CASE


Una herramienta CASE


Modelos de proceso Modelos de proceso de la Ingeniería Web (XII)

UWE (UML b d W bUWE (UML-based Web Engineering) (II)


Vista general del proceso UWE


BibliografíaBibliografíaAmbler, S. W. “In search of a generic SDLC for object systems”. Object Magazine, 4(6): 76-78, 1994.Beck, K. “Embracing Change with Extrem Programming”, IEEE Computer 32, pp. 70-77, 1999.Beck, K. “Extreme Programming Explained. Embrace Change”. Addison-Wesley, 2000. Birrel N D Ould M A “A practical Handbook for Software Development” Cambridge University Press 1985Birrel, N. D., Ould, M.A. A practical Handbook for Software Development . Cambridge University Press, 1985.Boehm, B. W. “A Spiral Model of Software Development and Enhancement”. ACM Software Engineering Notes,

11(4):22-42. 1986.Boehm, B. W. “A Spiral Model of Software Development and Enhancement”. Computer , 21(5): 61-72 , 1988.Boehm, B., Egyed, A., Port, D., Shah, A., Kwan, J., Madachy, R. “A Stakeholder Win-Win Approach to Software

E i i Ed ti ” A l f S ft E i i 6 295 321 1998Engineering Education”. Annals of Software Engineering , 6, 295-321, 1998.Booch, G., Rumbaugh, J., Jacobson, I. “El Lenguaje Unificado de Modelado”. Addison Wesley, 1999.Butler, J. “Rapid Application Development in Action”. Managing System Development, Applied Computer Research,

14(5):6-8. May, 1994.Cockburn, A. “Software Development as a Cooperative Game”, Humans and Tecnology inc., 1999.

htt // li t i kb / t l/ ti l / d / ft d l t ti ht lhttp://alistair.cockburn.us/crystal/articles/sdacg/softwaredevelopmentasacooperativegame.htmlGraham, I. “Métodos orientados a objetos”, Adison-Wesley, 1996.Hennicker, R. y Koch, N. “A UML-based Methodology for Hypermedia Design”. En Proceedings of the Unified Modeling

Language Conference (UML’2000). A. Evans y S. Kent (Eds.). Lecture Notes in Computer Science LNCS Vol. 1939. Páginas 410-424. Springer-Verlag, 2000.g p g g

Henderson-Sellers, B., Edwards, J. M. “The fountain Model for object-oriented systems development”, ObjectMagazine, julio/agosto, pp 71-79, 1993.

Henderson-Sellers, B., Edwards, J. M. “The object-oriented systems life cycle”, Communications of the ACM, 33(9): 143-159, 1990.

Highsmith, J., “Adaptive Software Development: A Colaborative Approach to Managing Complex Systems”, Dorset g , , p p pp g g p y ,House, 2000.

IEEE. “IEEE Software Engineering Standards Collection 1999 Edition. Volume 2: Process Standards”. IEEE Computer Society Press, 1999.

ISO/IEC. “Information Technology – Software Life Cycle Processes”. Technical ISO/IEC 12207:1995(E), 1995.



BibliografíaBibliografíaJacobson, I., Booch, G., Rumbaugh, J. “El Proceso Unificado de Desarrollo”, Addison Wesley, 2000.Kerr, J., Hunter, R. “Inside RAD”, McGraw-Hill, 1994.Koch, N.”Software Engineering for Adaptive Hypermedia Applications. Reference Model, Modeling Techniques and , g g p yp pp , g q

Development Process”. PhD. Thesis, Ludwig-Maximilians-Universität München, 2001.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, 1991.Martin, J. “Rapid Application Development”, Prentice Hall, 1991.Meyer B “La Nueva Cultura del Desarrollo de Software” Systems pp 12-13 Septiembre 1990Meyer, B. La Nueva Cultura del Desarrollo de Software , Systems, pp. 12-13. Septiembre, 1990.Meyer, B. “Construcción de software orientado a objetos”, Prentice Hall, 1999.Mills, H. D., Dyer, M., Linger, R. “Cleanroom Software Engineering”, IEEE Software, 4(5): 19-25. September 1987.Muller, P. A. “Modelado de objetos con UML”, Eyrolles-Ediciones Gestión 2000, 1997.Nierstrasz,O., Gibbs, S.J., Tsichritzis, D. “Component-Oriented Software Development”. CACM, 35(9): 160-165, 1992.Piattini, M.G. et al. “Análisis y diseño detallado de aplicaciones Informáticas de Gestión”, Rama, 1996. Pressman, R. S. “Ingeniería del Software, un enfoque práctico”, 5ª Edición. Mc Graw Hill, 2002.Pressman, R. S. “Ingeniería del Software, un enfoque práctico”, 6ª Edición. Mc Graw Hill, 2006.Royce, W. W. “Managing the Development of Large Software Systems: Concepts and Techniques”, In Proceedings

WESCON August 1970WESCON. August, 1970.Rumbaugh, J. “Over the waterfall and into the whirlpool”, JOOP, mayo, pp 23-26, 1992.Sommerville, I. “Software Engineering”, 6th ed., Addison Wesley, 2001.Schwaber, K. “SCRUM Development Process”. OOPSLA’95 Workshop on Business Object Design and Implementation,

http://www.tiac.netJusers/jsuthfoopsla/oo95summary.html, 10 Dee 95.Turk, D., France, R. y Rumpe, B. (2002) Limitations of Agile Software Processes. En Proceedings of 4th International

Conference on eXtreme Programming and Agile Processes in Software Engineering, XP2002. (Alghero, Sardinia, Italy, April 2002), pp. 43-46, 2002.

Ward, S. , Kroll, P., “Building Web Solutions with the Rational Unified Process: Unifying the Creative Design Process and the Software Engineering Process”, Rational Software & Context Integration white paper, 1999.


g g , g p p ,

Tema2

Documents

Transcript of Tema2