Modelos prescriptivos, Proceso Unificado y Desarrollo gil.

Hungria Berbesi Implantacin de Sistemas UNEFA Mrida

Nota
Esta presentacin ha sido elaborada netamente con fines

acadmicos. Se ha elaborado reusando presentaciones preexistentes y dems material extraido de internet , guiando el contenido por el libro de Roger Pressman, Ingeniera del Software, Sexta edicin, Mc graw Hill.

Construir una casa para FIDO

Que es Ingenieria??
Construir un rascacielos.

Puede hacerlo una sola persona Requiere: Modelado mnimo Proceso simple Herramientas simples

Vs.
Construido eficientemente y
en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas ms 3 sofisticadas

Proceso de desarrollo de software

Qu es el PDSW?
Conjunto de etapas con la intencin de lograr un objetivo:

en tiempo y presupuesto definido

Para asegurar calidad del software

Personas Producto

Proceso

Metodologas Introduccin
Resulta necesario establecer un enfoque sistemtico y disciplinado para

llevar a cabo un desarrollo software El uso de una metodologa permite el dominio del proceso descrito Una metodologa es el conjunto de mtodos que se siguen en una investigacin cientfica o en una exposicin doctrinal[RAE, 2001] Una metodologa software es un enfoque, una manera de interpretar la realidad o la disciplina en cuestin, que en este caso particular correspondera a la Ingeniera del Software Se elaboran a partir del marco definido por uno o varios ciclos de vida No existe un consenso entre los diversos autores sobre el concepto de metodologa

Desde una perspectiva de Ingeniera de Software, una metodologa

Describe cmo se organiza un proyecto
Establece el orden en el que la mayora de las actividades tienen

que realizarse y los enlaces entre ellas Indica cmo tienen que realizarse algunas tareas proporcionando las herramientas concretas e intelectuales
Con una metodologa se intentan cubrir las siguientes

necesidades [Piattini et al., 2004]

Mejores aplicaciones Mejor proceso de desarrollo

Establecer un proceso estndar en una organizacin

 Una metodologa es una aproximacin organizada y

sistemtica para el ciclo de vida del sistema o sus partes. Especifica las tareas individuales y sus secuencias [Palvia y Nosek, 1993] Conjunto de procedimientos, tcnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software [Piattini et al., 2004]

Se puede definir metodologa de Ingeniera del Software como

Un proceso para producir software de forma organizada,

empleando una coleccin de tcnicas y convenciones de notacin predefinidas[Rumbaugh et al., 1991] Confusin entre los trminos metodologa, mtodo y ciclo de vida por abuso del lenguaje tcnico Una metodologa puede seguir uno o varios modelos de ciclo de vida, esto es, el ciclo de vida indica qu es lo que hay que obtener a lo largo del desarrollo del proyecto, pero no cmo. Esto s lo debe indicar la metodologa Una metodologa es un concepto ms amplio que el de mtodo. As, se puede considerar a la metodologa como un conjunto de mtodos

Proceso Unificado
El Proceso Unificado es ms que un simple proceso [Jacobson

et al., 1999], es un marco de trabajo genrico que puede especializarse para una gran variedad de sistemas software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaos de proyectos
Caractersticas generales Est basado en componentes Utiliza UML [Booch et al., 1999; OMG, 2003] Caractersticas principales [Jacobson et al., 1999] Es un proceso conducido por casos de uso Est centrado en la arquitectura Es iterativo e incremental

 Un marco de trabajo genrico No existe un proceso universal Puede extenderse y especializarse para una gran variedad de

sistemas de software
Flexibilidad

Est basado en componentes

Permite gran variedad de estrategias de ciclo de vida

Se pueden definir diferentes conjuntos de productos Se pueden definir actividades y encargados de las mismas

 Selecciona qu artefactos producir Define actividades y stakeholders Modela conceptos

El producto que se obtiene es un sistema de software

El sistema lo componen todos los artefactos necesarios para

representarlo de forma comprensible Artefacto

Trmino general para cualquier tipo de informacin creada,

producida, cambiada o utilizada por los stakeholdersen el desarrollo del sistema. Puede ser
De ingeniera De gestin

El artefacto ms importante del Proceso Unificado es el

modelo Un sistema posee una coleccin de modelos y las relaciones entre ellos

 Un modelo es una abstraccin semnticamente

cerrada del sistema Los modelos recogen diferentes perspectivas del sistema (perspectivas de todos los stakeholders)

Modelos
Modelo de casos de uso Diagramas de casos de uso, secuencia, colaboracin y actividad Modelos de anlisis y diseo Diagramas de clases, objetos, secuencia, colaboracin y actividad Modelo de despliegue Diagramas despliegue, secuencia y colaboracin Modelo de implementacin Diagramas de componentes, secuencia y colaboracin Modelo de pruebas Todos los diagramas

Consultar Catlogo <<includes>>

EJEMPLO DE MODELO DE CASOS DE USO

Actualizar Catlogo

Persona

Reservar Libro

EncargadoBiblio
<<extends>>

Tomar Prstamo Copia Libro

- No disponible

<<extends>>

Tomar Prstamo Revista

Extender Prstamo
- No reservado

Socio
Devolver Copia Libro

Devolver Revista

TrabajadorBiblio

 El proceso de desarrollo de software es una definicin

de un conjunto completo de actividades necesarias para convertir los requisitos de usuario en un conjunto consistente de artefactos que conforman un producto software, y para convertir los cambios sobre esos requisitos en un nuevo conjunto consistente de artefactos El proceso hace referencia a un contexto que sirve como plantilla que pueda reutilizarse para crear instancias de ella (proyectos) Las actividades relacionadas conforman disciplinas o flujos de trabajo Su identificacin parte de la identificacin de los stakeholders y de los artefactos para cada tipo de stakeholder Describen como fluye el proceso a travs de los stakeholders

 Conducido por casos de uso

Los casos de usos guan el desarrollo del sistema 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 representa mediante vistas del modelo Se puede tomar como arquitectura de referencia el denominado modelo de

arquitectura de 4+1 vistas propuesto por Philippe Kruchten (1995)

Iterativo e Incremental

En cada iteracin se identifican y especifican los casos de uso relevantes, se

crea un diseo basado en la arquitectura seleccionada, se implementa el diseo mediante componentes y se verifica que los componentes satisfacen los casos de uso Si una iteracin cumple con sus objetivos se pasa a la siguiente En cada iteracin se va desarrollando el sistema de forma incremental

 Inicialmente los casos de uso se utilizan para la captura de

requisitos funcionales Durante el anlisis y el diseo se transforma el modelo de casos de uso mediante un modelo de anlisis en una estructura de clasificadores y realizaciones de casos de uso En cada iteracin, los casos de uso sirven de gua a travs del conjunto completo de disciplinas

 La caracterstica fundamental del Proceso Unificado es ser un

proceso iterativo

Se basa en la ampliacin y el refinamiento del sistema Una serie de desarrollos cortos (mini proyectos de 2 a 6

semanas, cada iteracin reproduce el ciclo de vida a menor escala) No slo se mejora sino que el sistema tambin crece: proceso iterativo e incremental

 El resultado de cada iteracin es un sistema ejecutable (aunque sea

incompleto y no est listo para su instalacin) Un sistema instalable requiere varias iteraciones Evolucin de prototipos ejecutables Los objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes Concepto de time-boxing
algunos de los requisitos (se dejan para la siguiente iteracin)

Cada iteracin debe tener una duracin fija (el mximo, 6 meses) En lugar de retrasar el final de una iteracin se recomienda eliminar

La realimentacin del usuario es fundamental en este proceso El progreso es visible

Centrado en la ARQUITECTURA
1

VISTA DEL MODELO DE CASOS DE USO DEL MODELO DEL DOMINIO / VISTA VISTA DEL DIAGRAMA DE CLASES

VISTA DEL MODELO DEL ANLISIS

: IU-1 : : 2: 1: 3: G r 4 () o

: : : 2: 1: 3: G r 4 () o

VISTA DEL MODELO DEL DISEO

+ VISTAS DEL MODELO DE IMPLEMENTACIN Y PRUEBAS

Mtodos giles (ii)

Las aproximaciones giles emplean procesos tcnicos y de gestin que

continuamente se adaptan y se ajustan a [Turk et al., 2002] Cambios derivados de las experiencias ganadas durante el desarrollo Cambios en los requisitos Cambios en el entorno de desarrollo La agilidad en el desarrollo del software no significa nicamente poner en el mercado o en explotacin los productos software ms rpidamente Esto choca frontalmente con los modelos de procesos tradicionales que son monolticos y lentos, centrados en una nica iteracin o ciclo de larga duracin Diversas aproximaciones XP (eXtreme Programming) [Beck, 2000], que ha originado toda una corriente de desarrollo extremo

Mtodos giles
En marzo de 2001, 17 crticos de los modelos exixtentes, convocados por Kent

Beck, que acababa de definir una nueva metodologa denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre los modelos de desarrollo de software. En la reunin se acu el trmino Mtodos giles para definir a aquellos que estaban surgiendo como alternativa a las metodologas formales, (CMMSW, PMI, SPICE) a las que consideraban excesivamente pesadas y rgidas por su carcter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo. Los integrantes de la reunin resumieron en cuatro postulados lo que ha quedado denominado como Manifiesto gil, que capturaba el espritu en el que se basan estos mtodos. Aunque como se ver ms adelante, en la actualidad hay aproximaciones que combinan lo mejor de ambos enfoques (formal y gil), hasta 2005, en cada lado sus defensores adoptaron posturas radicales, quiz ms ocupadas en descalificar a la contraria que en estudiarla y conocerla para mejorar la propia.

Estamos poniendo al descubierto mejores mtodos para desarrollar software, hacindolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

A los individuos y su interaccin El software que funciona La colaboracin con el cliente La respuesta al cambio

por encima por encima por encima por encima

de los procesos y las herramientas de la documentacin exhaustiva la negociacin contractual seguimiento de un plan

Aunque hay valor en los elementos de la derecha, valoramos ms los de la izquierda

eXtreme Programming (i) XP

Nuevo y controvertido enfoque de desarrollo de software basado en el modelo

incremental Est indicado para: Equipos de tamao mediano o pequeo Requisitos imprecisos y cambiantes Caractersticas El juego de la planificacin Versiones pequeas Metfora Diseo sencillo Hacer pruebas Refactorizacin Programacin en parejas Propiedad colectiva Integracin continua Cliente in-situ Estndares de codificacin

Extreme Programming
1. Simplicidad: simplifica el diseo. Para que sea mantenible necesario la refactorizacin del cdigo. simplicidad +autora colectiva del cdigo + la programacin por parejas ms grande el proyecto, todo el equipo conocer ms y mejor el sistema completo.

 2. Comunicacin
Cdigo comunica mejor mientras ms simple. Cdigo autodocumentado ms fiable que comentarios Pruebas unitarias muestran ejemplos concretos de como utilizar su funcionalidad. Programacin por parejas. Cliente forma parte del equipo de desarrollo. El cliente decide qu caractersticas tienen prioridad y siempre debe estar disponible para solucionar dudas.

 3. Retroalimentacin (feedback):

Cliente integrado en el proyecto: su opinin sobre el estado del proyecto se conoce en tiempo real. Ciclos que muestran resultados, ayuda a los programadores a centrarse en lo que es ms importante. Pruebas unitarias informan sobre el estado de salud del cdigo.

 4. Coraje o Valenta:
Programacin en parejas puede ser difcil de aceptar, parece como si la productividad se fuese a reducir a la mitad (beneficia en calidad sin repercutir en productividad) Coraje para implementar las caractersticas que el cliente quiere ahora sin caer en la tentacin de un enfoque ms flexible que permita futuras modificaciones. No se debe emprender el desarrollo de grandes marcos de trabajo (frameworks) mientras el cliente espera. La forma de construir marcos de trabajo es mediante la refactorizacin del cdigo en sucesivas aproximaciones.

 5. Respeto:

Aadido en la segunda edicin de Extreme Programming Explained Programadores no pueden realizar cambios que hacen que las pruebas existentes fallen que demore el trabajo de sus compaeros. Los miembros respetan su trabajo, buscan alta calidad en el producto y diseo ms ptimo para la solucin a travs de la refactorizacin del cdigo

Fin
Tareas: