métodos Ágiles para el desarrollo de software - …©todos Ágiles para el desarrollo de software...

Métodos Ágiles para el Métodos Ágiles para el

Desarrollo de SoftwareDesarrollo de Software

Rational Unified Process (RUP)Rational Unified Process (RUP)

RUP - IntroductionRUP - Introduction

� Rational Corporation

� Philippe Kruchten, Ivar Jacobson and others

� �Rational Approach� 1980s - 1990s + Objectory

process (Jacobson)

� Core initial development around 1995-1998

� First book: �The Unified Software Development

Process� by I. Jacobson 1999

RUP - PracticesRUP - Practices

� Develop Software iteratively

� Manage requirements

� Use component-based architectures

� Visually model software

� Continuously verify software quality

� Control changes to software


Develop Software iteratively


Manage requirements� Recommended method for organizing your functional

requirements: using use cases.

� Provides for greater completeness and consistency, and a better understanding of the importance of a requirement from a user's perspective.


Use component-based architectures


Visually model software


Continuously verify software quality

Quality is the characteristic of having demonstrated the achievement of

producing a product that meets or exceeds agreed-on requirements�as

measured by agreed-on measures and criteria�and that is produced by

an agreed-on process.�

Managing quality is done for these purposes:

� To identify appropriate indicators (metrics) of acceptable quality

� To identify appropriate measures to be used in evaluating and

assessing quality

� To identify and appropriately address issues affecting quality as

early and effectively as possible


Control changes to software Establishing a baseline

Determining which dependencies are important to trace

Establishing traceability between related items

Implementing change control.

RUP � Some compatible practices from RUP � Some compatible practices from other methodsother methods

� The planning game

� Test-first design and refactoring

� Continuous integration

� On-site customer

� Coding standards (RUP artifact is called �Programming guidelines�)

� Forty-hour weeks

� Pair programming

RUP � Practices that don�t scale wellRUP � Practices that don�t scale well

� Metaphor (for complex systems is not enough)

� Collective Ownership

� Refactoring

� Small Releases

RUP � Life CycleRUP � Life Cycle

� Phases (with Milestone objectives)

� Inception

� Elaboration

� Construction

� Transition

� Iterations: from 2 to 6 weeks


� Complete SW development model including tool support

� Disciplines � Business Modelling� Requirements� Analysis & Design� Implementation� Testing� Configuration & Change Management� Project Management � Environment


RUP � �Configuration & Change RUP � �Configuration & Change Management� disciplineManagement� discipline

RUP � Inception WorkflowRUP � Inception Workflow

RUP � Inception Workflow (zoom)RUP � Inception Workflow (zoom)

RUP � Elaboration WorkflowRUP � Elaboration Workflow

RUP � Elaboration RUP � Elaboration Workflow (zoom)Workflow (zoom)

Role:

Software architect

Activities:

Define Candidate Architecture

Refine architecture

Artifact:

Design Model

RUP � Construction WorkfloRUP � Construction Workflo

RUP � Construction RUP � Construction Workflow (zoom)Workflow (zoom)

Role

Developer

Activities

Develop component

Test and evaluate

Artifacts

Build

Test Evaluation Summary

RUP � Transition WorkflowRUP � Transition Workflow

RUP � Transition RUP � Transition Workflow (zoom)Workflow (zoom)

Roles

Implementer

Tester

Activities

Test & evaluate

Integrate system

Artifacts

Implementation Model

Las Fases y los Hitos del Proceso Las Fases y los Hitos del Proceso Unificado (UP)Unificado (UP)

Vista de UP desde los objetivos Vista de UP desde los objetivos planteados según los involucradosplanteados según los involucrados

Vista de UP desde las actividades Vista de UP desde las actividades realizadas según los involucradosrealizadas según los involucrados

ObjetivosObjetivos

� No alcanza con las tareas realizadas si no se logran los

objetivos planteados y no se logra controlar los riesgos !!!

Objetivos (2)Objetivos (2)

Condiciones necesarias para el trabajo Condiciones necesarias para el trabajo iterativoiterativo

� Cultura organizacional � Planes de negocio

� Recursos en tiempos

� Acuerdos y ventas

� Grupo de desarrollo � Actitud

� Lider planificando y siguiendo según riesgos

� Analistas y desarrolladores con requerimientos

� Definición de la arquitectura como basamento

� Monitoreo de la calidad de procesos y productos

� Organización cliente � Acuerdos

� Disposición de recursos

� Dinámica del negocio

Las Las metodologíasmetodologías de cascada de cascada

� Planear un proyecto de software es completamente distinto a

planear un proyecto en otra área de ingeniería

� Algunas conclusiones erróneas derivadas de estas

metodologías:

� Se puede desarrollar un producto haciendo una secuencia única de tareas

� Los requerimientos pueden ser completados y congelados en forma

temprana

� Todos los requerimientos tienen igual prioridad

� El diseño puede ser verificado sin construir y probar

� El proyecto puede ser planeado en detalle al comienzo del proyecto

� Todo lo importante puede conocerse al comienzo del proyecto

� Si se siguen los pasos preestablecidos se cumplirá con el Plan y se

mitigarán los riesgos como fue predicho al comienzo

Las Las metodologíasmetodologías de cascada (2) de cascada (2)

� Por qué son falsas estas conclusiones:

� En el desarrollo de Software se construye siempre componentes

diferentes en cada proyecto, no es una tarea repetitiva (dificultad

de estimaciones)

� Software es una respuesta a negocios que cambian

� Tecnología que soporta al desarrollo de software cambia

evolucionando todo el tiempo

� Unidad de trabajo ya no es un profesional sino el grupo de trabajo

debido a la complejidad de los negocios y de la tecnología

� Los diferentes roles trabajando simultaneamente suman valor al

producto

� Los riesgos condicionan el cumplimiento del Plan, el cual debe

adaptarse (compromiso)

� Las pruebas y entregas tempranas reducen los riesgos temprano

Claves del desarrollo iterativoClaves del desarrollo iterativo

� Iteración equivale a entrega

� Valor sumado en cada entrega (iterativo e incremental)

� Conducido por los casos de uso (Business driven)

� Objetivos, riesgos y evaluación por iteración

� Actitud del grupo de trabajo en cerrar la iteración

(compromiso, foco, honestidad, respeto, agilidad, colaboración)

� Responsabilidad de la conducción según las tareas

realizadas(requerimientos, arquitectura, evaluación, proyecto)

� Objetivos logrados mitigando riesgos es la mejor estrategia

� Claro entendimiento del proceso de desarrollo por parte de

todos los involucrados

� Grupo de desarrollo es una pequeña unidad organizacional con

reglas de funcionamiento y convivencia propias

Comparación entre la forma Comparación entre la forma tradicional (cascada) y la iterativatradicional (cascada) y la iterativa

RUP is a frameworkRUP is a framework

� RUP is a complete software development process

framework

� Labeling RUP as heavyweight in a pejorative way is

meaningless posturing.

� It is the implementation of RUP as a process that will

be heavyweight or lightweight, and they should be as

heavy or light as circumstances require it to be.

RUP - ToolsRUP - Tools

� Rational Suite includes may tools to help the workers in their activities:

- ClearQuest - Test Manager

- ClearCase - SoDA

- Requisite Pro - Project Console

- Rose - Robot

- PureCoverage - Purify

- Quantify - Test Factory


� RUP is also the name of a Rational

Suite product very useful for

understanding the process and its

workproducts


� RUP Builder combines RUP's core

technology with the Plug-Ins you select

to help you create your customized

version of RUP


Rational Rose XDE Developer Plus

Offers software designers and developers a rich set of model-driven development and runtime analysis capabilities for building quality J2EE-based and .NET-based software applications.

RUP � Roles & Responsibilities RUP � Roles & Responsibilities

� 30 roles called workers

� Architect, Designer, Design Reviewer, Configuration Manager, etc.

� Business modeling: Business-Process Analyst, Business Designer, Business-Model Reviewer,...

� Environment workflow: Course Developer, Toolsmith

RUP � Roles & ResponsibilitiesRUP � Roles & Responsibilities

CUSTOMER

� Stakeholder (customers,

product manager, ...)

MANAGEMENT

� Project Manager

� Process Engineer

OTHER

� Graphic Artist

� Technical Writer

DEVELOPMENT

� Implementer

� Tester

� Software Architect

� System Analyst

� DB Designer

� UI Designer

RUP � Roles & ResposibilitiesRUP � Roles & Resposibilities

RUP - ScopeRUP - Scope

� RUP developed to cater for the entire software production process

� Studies from Martin (1998), Smith (2001) examined potential of RUP for using it agilely

� Adoption phase is the key adjusting RUP towards agility

RUP - ExamplesRUP - Examples

� Large � Canadian Automated Air Traffic Control System� Ten years, 400 people, Ada and C++, an L400 life-critical

project


� Medium � Ogre Nextgen Economic Modelling System� Two years, 15 people, Java technologies, an E20 project


� Small � QUICKcheck point-of-sale� One year, six people, Java technologies

Common Mistakes & MisunderstandingsCommon Mistakes & Misunderstandings

� Superimposing Waterfall Ideas


� Iteration doesn�t end in an integrated and tested baseline


� Each iteration ends in a production release


� Elaboration phase goal is to create a throwaway prototype


� Development Case too complex; too many workproducts


� Predictive planning


� The team should do lots of modeling and UML diagrams, and use a CASE tool

� Need many tools

� Not conforming to the official UP workproduct names or phase names


� Software Architecture Document (SAD) �finished� before end of elaboration

RUP � Adoption strategies (part I)RUP � Adoption strategies (part I)

� Coaching

� Education

� Select an interesting pilot project (not a too risky one)

� Coach should be hands-on developer

� Coach leads the definition of the Development Case

RUP � Adoption strategies (part II)RUP � Adoption strategies (part II)

� �Armchair process engineers� should be avoided

� Start simple � add practices as iterations proceed

� �In-selling� of the UP practices by project members

� Move experienced members to 2nd generation of UP projects

� Project retrospective

RUP � Current researchRUP � Current research

� dX (Robert Martin, 1998): minimal version of RUP

� Agile Modeling (Ambler, 2002)

� Rational products are alive (through IBM)

RUP � QuestionsRUP � Questions

métodos Ágiles para el desarrollo de software - …©todos Ágiles para el desarrollo de software...

Documents