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
RUP - PracticesRUP - Practices
Develop Software iteratively
RUP - PracticesRUP - Practices
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.
RUP - PracticesRUP - Practices
Use component-based architectures
RUP - PracticesRUP - Practices
Visually model software
RUP - PracticesRUP - Practices
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
RUP - PracticesRUP - Practices
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
RUP � Life CycleRUP � Life Cycle
� Complete SW development model including tool support
� Disciplines � Business Modelling� Requirements� Analysis & Design� Implementation� Testing� Configuration & Change Management� Project Management � Environment
RUP � Life CycleRUP � Life Cycle
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 - ToolsRUP - Tools
� RUP is also the name of a Rational
Suite product very useful for
understanding the process and its
workproducts
RUP - ToolsRUP - Tools
� RUP Builder combines RUP's core
technology with the Plug-Ins you select
to help you create your customized
version of RUP
RUP - ToolsRUP - Tools
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
RUP - ExamplesRUP - Examples
� Medium � Ogre Nextgen Economic Modelling System� Two years, 15 people, Java technologies, an E20 project
RUP - ExamplesRUP - Examples
� Small � QUICKcheck point-of-sale� One year, six people, Java technologies
Common Mistakes & MisunderstandingsCommon Mistakes & Misunderstandings
� Superimposing Waterfall Ideas
Common Mistakes & MisunderstandingsCommon Mistakes & Misunderstandings
� Iteration doesn�t end in an integrated and tested baseline
Common Mistakes & MisunderstandingsCommon Mistakes & Misunderstandings
� Each iteration ends in a production release
Common Mistakes & MisunderstandingsCommon Mistakes & Misunderstandings
� Elaboration phase goal is to create a throwaway prototype
Common Mistakes & MisunderstandingsCommon Mistakes & Misunderstandings
� Development Case too complex; too many workproducts
Common Mistakes & MisunderstandingsCommon Mistakes & Misunderstandings
� Predictive planning
Common Mistakes & MisunderstandingsCommon Mistakes & Misunderstandings
� 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
Common Mistakes & MisunderstandingsCommon Mistakes & Misunderstandings
� 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
Top Related