Introduction to RUP & SPEM

RUP & SPEM

Modelos de Procesos y Metodologías de Ingeniería de software

Mayo de 2014

Universidad de CaldasFacultad de IngenieríasMaestría en Ingeniería Computacional

Welcome!

ContentIBM Rational Unified Process

Process Framework Theory

Tayloring

Some Model-Driven Theory

SPEM & UMA Metamodels

Eclipse Process Framework

Sources

•Gerard O’Regan, Introduction to Software ProcessImprovement, Springer 2011. ISBN 978-0-85729-171-4

•Ahmad K. Shuja and Jochen Krebs. IBM Rational UnifiedProcess Reference and Certification Guide: Solution Designer.IBM Press 2008. ISBN 9780131562929

•Per Kroll and Philippe Kruchten. Rational Unified Process MadeEasy- A Practitioner’s Guide to RUP. IBM Academic Intitiative.

•IBM Software Group. PRJ270: Essentials of Rational UnifiedProcess. 2003

•IBM Software Group. Basic Method Authoring with IBM RationalMethod Composer V7.5. IBM, 2009

Before…

What do you listened about RUP?

•It’s so difficult

•It’s misunderstood

•It’s rigorous

•It’s imposible to apply all

•It’s not suitable for small companies

•It’s old

•It’s for Rational Tools exclusively

Before…

What do you listened about RUP?

•It’s horrible

•It cannot be adapted

•There are so many artifacts

•It’s confusing

•…

•Among others

But…

Source: Estudio de la caracterización de productos y servicios de la industria de software y servicios asociados 2012 Fedesoft

Rational Unified Process - RUP

(Classical definition from common SE books)

“It is a visual modelling language for softwaresystems and provides a means of specifying,constructing, and documenting the object-oriented system. This facilitates theunderstanding of the architecture andcomplexity of the system”


(Sommerville – cool!! )

“The RUP is a phased model that identifies fourdiscrete phases in the software process.

However, unlike the waterfall model wherephases are equated with process activities, thephases in the RUP are more closely related tobusiness rather than technical concerns.”

Taking into account…

• UML: 1997

• RUP: 1999

Rumbaugh, J., et al.: The Unified SoftwareDevelopment Process. Addison Wesley(1999)


• RUP is a process frameworkfor successful iterative-incremental softwaredevelopment.

• It’s a very importantknowledge source for modernSoftware Engineering


• A software development approach that isiterative, architecture-centric and use-casedriven

• A well-defined and structured softwareengineering process

• A process product providing a customizableprocess framework

RUP vs the others

RUP vs the others (II)

• RUP as a traditional SW Process?

• Note that the up-front goals modelingcomponent may not be directly associatedwith any given software developmentmethodology but is there to ensurealignment between new softwareproducts or releases and the businessstrategy.

• One key of RUP is its strong businessalignement

Three central elements of RUP

• Key principles for business-drivendevelopment

• A framework of reusable method contentand process building blocks

• The underlying method and processdefinition language

RUP as Process Framework• A process framework can be defined as an incomplete

support structure in which another process can beorganized and developed. Therefore, you need to finisha process framework before you can apply it tospecific projects within an organization

• The RUP framework is defined by a family of method plug-ins from which, based on the unique business needs aswell as the context (technical and managementcomplexity), organizations are able to create their ownmethod configurations and tailored processes.

• RUP provides an architectural foundation and wealth ofmaterial from which a process definition can beconstructed, therefore enabling the adopting organizationto configure and extend that foundation as desired.

RUP ABC

• Adapt the process.

• Balance stakeholder priorities.

• Collaborate across teams.

• Demonstrate value iteratively.

• Elevate the level of abstraction.

• Focus continuously on quality

Develop only what is necessary

– Lean process, agility

Minimize paperwork

Be flexible

– Requirements, plan, usage of people,

etc…

Learn from earlier mistakes

– Feedback loops

– Process improvement

Revisit risks regularly

Establish objective, measurable criteria for

progress

Automate

– Support process with software

development tools

•Develop Iteratively

•Manage Requirements

•Use Component Architectures

•Model Visually (UML)

•Continuously Verify Quality

•Manage Change

RUP Best Practices & Key Principles

The Spirit of RUP

1. Attack major risks early and continuously… or they attack you

2. Ensure that you deliver value to your customer

3. Have a maniacal focus on working software

4. Accommodate change early in the project

5. Baseline an executable architecture early on

6. Build your system with components

7. Work closely together as one team

8. Make quality a way of life, not an afterthought

RUP Best Practices & Key Principles

•Needs not met

•Requirements churn

•Modules don’t fit

•Hard to maintain

•Late discovery

•Poor quality

•Poor performance

•Colliding developers

•Build-and-release

•Insufficient requirements

•Ambiguous communications

•Brittle architectures

•Overwhelming complexity

•Undetected inconsistencies

•Poor testing

•Subjective assessment

•Waterfall development

•Uncontrolled change

•Insufficient automation

Symptoms Root Causes Best Practices

•

•Ambiguous communications

•

•Undetected inconsistencies

•

•

•

•

•

•Develop Iteratively

•Manage Requirements

•Use Component Architectures



•Manage Change



•

•

•Modules don’t fit

•

•

•

•

•

•

RUP ArchitectureIterative Lifecycle Graph

In an iteration, you may walk through all disciplines

C

O

N

T

E

N

T

S

T

R

U

C

T

U

R

E T I M E

• The RUP provides an iterative and incrementalapproach to developing software.

• This iterative and incremental developmenthappens within iterations that occur within astructured lifecycle consisting of phases andmilestones.

• The RUP has four sequential phases: Inception,Elaboration, Construction, and Transition.

• Each of them plays a central role in managingiterative and incremental development projectsusing RUP.

• Each phase concludes with a major milestone

Phases and Milestones

• Phases are made up of iterations, and both phasesand iterations are important concepts to grasp forbuilding a concrete understanding of the RUP

• According to the RUP, a discipline is a collection ofrelated activities that are related to a major areaof concern.

• Based on which phase you are in, each iterationcontains activities from across different disciplines.

• Iterations are designed and executed withcertain goals in mind. Depending upon whichphase the iteration belongs to, the iterationgoals are aligned to accomplish the respectivemilestone.

Phases and Milestones

Inception: Know What to Build

Prepare vision document and initial business case

– Include risk assessment and resource estimate

Develop high-level project requirements

– Initial use-case and domain models (10-20%

complete)

Manage project scope

– Reduce risk by identifying all key requirements

– Acknowledge that requirements will change

Manage change, use iterative process

•Inception •Elaboration •Construction •Transition

Inception: Know What to BuildThe following are the primary Inception phase objectives:

To establish the project’s scope and boundary conditions

To identify the critical use cases of the system

To exhibit and demonstrate one candidate architecture

To estimate the overall cost and schedule for the project

To produce detailed estimates for the Elaboration phase

To estimate the potential risks

To prepare the support environment for the project

The Lifecycle Objectives milestone concludes the Inception

phase. At that point, a major decision is made on whether to

proceed with the project or cancel it


Detail requirements as necessary (~80% complete)

– Less essential requirements may not be fleshed out

Produce an executable and stable architecture

– Define, implement and test interfaces of major components

– Identify dependencies on external components and systems.

Integrate shells/proxies of them.

– Some key components will be partially implemented

– Roughly 10% of code is implemented.

Drive architecture with key use cases

– 20% of use cases drive 80% of the architecture

– Design, implement and test key scenarios for use cases


Elaboration: Know How to Build It

Verify architectural qualities

– Reliability: Stress test

– Scalability and Performance: Load test

Continuously assess business case, risk profile and

development plan



The Elaboration phase objectives are as follows:

To stabilize the architecture, requirements, and respective plans

To sufficiently mitigate risks to predictably determine project cost and schedule

To address all architecturally significant risks

To establish a baselined architecture

To produce an evolutionary prototype of production-quality components

Optionally, to produce throw-away prototypes to mitigate specific risks such as

design trade-offs, component reuse, and product feasibility

To demonstrate that the baselined architecture will support the requirements of the

system at a reasonable cost and in a reasonable time

To establish a supportive environment

The Lifecycle Architecture milestone concludes the Elaboration phase,

establishing a managed baseline for the architecture of the system and enabling

the project team to scale during the Construction phase.



Complete requirements and design model

Design, implement and test each component

– Prototype system and involve end users

– Incrementally evolve executable architecture to

complete system

Build daily or weekly with automated build process

Test each build

– Automate regression testing

– Load and stress test to ensure architectural integrity

Deliver fully functional software (beta release)

– Includes training material, user and deployment documentation

Produce release descriptions

Construction: Build The Product


Construction phase objectives can be briefly summarized as follows:

To minimize development costs through optimization of resource utilization by

avoiding unnecessary scrap and rework and by achieving a degree of parallelism

in the work of development teams

To achieve adequate quality as rapidly as is practical

To achieve useful executable versions (alpha, beta, and so on) as rapidly as

practical

To complete the analysis, design, development, and testing of all required

functionality

To iteratively and incrementally develop a complete product that is ready to

transition to its user community

To decide if the software, the sites, and the users are ready for the deployment of

the solution.

The Construction phase concludes with the Initial Operational Capability

milestone, which determines whether the product is ready to be deployed into a

beta-test environment.

Construction: Build The Product


Produce incremental ‘bug-fix’ releases

Update user manuals and deployment documentation

Update release descriptions

Execute cut-over

Conduct “post-mortem” project analysis

Transition: Deploy to End Users


Following are the primary objectives of the Transition phase:

To validate the new system against user expectations (by beta testing)

To train the end users and maintainers

If applicable, to roll out the product to marketing, distribution, and sales teams

To fine-tune the product by engaging in bug-fixing and creating performance and

usability enhancements

To conclude the assessment of the deployment baseline against the complete

vision and the acceptance criteria for the product

To achieve user self-supportability

To achieve stakeholder concurrence that deployment baselines are complete and

are consistent with the evaluation criteria of the vision.

The Product Release milestone concludes this phase. A decision is made

whether the objectives of the project were met.

Transition: Deploy to End Users


Iterative Development Phases

•Inception

•Time

•Elaboration •Construction •Transition

•Major Milestones

Inception: Understand what to build– Vision, high-level requirements, business case– Not detailed requirements

Elaboration: Understand how to build it – Baseline architecture, most requirements detailed– Not detailed design

Construction: Build the product– Working product, system test complete

Transition: Validate solution– Stakeholder acceptance

• In RUP, a discipline is defined as acategorization of activities based on similarity ofconcerns and cooperation of work effort.

• A discipline is a collection of activities that arerelated to a major area of concern (or “a field ofstudy”) within the overall project.

• In RUP, an activity is a process element thatsupports the nesting and logical grouping ofrelated process elements, such as a descriptorand subactivities, thus forming breakdownstructures.

RUP Disciplines

• In the RUP, a discipline refers to a specific area ofconcern (or a field of study, as mentioned earlier)within software engineering.

• In addition, disciplines in RUP allow you togovern the activities you perform within thatdiscipline.

• A discipline in RUP gives you all the guidance yourequire to learn not only when to perform agiven activity but also how to perform it.Therefore, disciplines in RUP allow you to bringclosely related activities under control.

RUP Disciplines (II)

The benefits provided by separating the RUP activitiesinto various disciplines are summarized as follows:

• Makes the activities easier to comprehend.

• Proves useful when customizing a given disciplineto meet the specific needs of the project or whendefining a set of organizational standard processes.

• Enables different roles to better and more effectivelyappreciate their responsibilities (in terms of thetasks/activities that they are responsible for) on agiven project.

• Allows Project Managers to more effectively monitorand control these activities.

RUP Disciplines (III)

• A discipline in RUP is a collection of activities that are related to amajor area of concern or field of study.

• Each activity is further decomposed into subactivities or one ormany tasks.

• Tasks require an input artifact or artifacts for their successfulexecution, and these in turn produce or refine some form of outputartifact(s).

• Note that these artifacts can include both document-based artifactsand executables. Each task has an associated role (or roles)responsible for performing that task.

• To provide additional support and guidance, each discipline in thebase RUP offers a set of standard template artifacts related to thatdiscipline.

• These artifacts, as well as the process, can be (and should be)customized/tailored for a given project or organization

ORACLES

A Structured Process: Role, Artifact,

Activity

•Distribute Behavior•Find Design•Classes

•Designer

•Use Case Realization

•Role •Activities

•Artifact •responsible for

Guidelines, Templates, Tool Mentors, …

•Distribute Behavior•Find Design•Classes

•Designer

•Use Case Realization •Use Case Template

•Rose Tool Mentor•Design Guideline

•Role •Activities

•Artifact •responsible for

• RUP models the when as workflows, and each discipline inRUP has a workflow. Like other workflows, a discipline’s workflowis a semi-ordered sequence of activities performed by specific rolesto achieve a particular goal.

• This semi-ordered nature of discipline workflows emphasizes thatthey cannot present the nuances of scheduling “real work,”because they cannot depict the optionality of activities or iterativenature of real projects.

• These workflows are part of RUP Framework, so, these constitutesguidance on a rich set of software engineering principles.

• It is applicable to projects of different size and complexity, as wellas to different development environments and domains. Thismeans that no single project or organization will benefit from usingall of RUP.

• It is important to understand that the sequence of activities ineach of the workflows is based on best practices

Workflows

Expressed as Workflows and Workflow

Details

According with Project Management Institute (PMI)

• The project’s work breakdown structure (WBS)provides the relationship among all the componentsof the project and the project deliverables.

• WBS is a deliverable-oriented hierarchicaldecomposition of the work to be executed by theproject team to accomplish the project objectivesand create the required deliverables.

• It organizes and defines the total scope of theproject. Each descending level represents anincreasingly detailed definition of the project work.

Workflow Breakdown Structure

• RUP adopts a slightly different view of WBS.Discipline WBS in RUP represents the activities-oriented hierarchical decomposition of the projecteffort specific to the respective discipline.

• Each descending level represents an increasinglydetailed definition of the project work.

• In the RUP, the WBS provides mostly fourdescending level of details.

• These levels include Discipline, Activity, Sub-Activity/Task, and Step.


• Activity is a process element that supports thenesting and logical grouping of related processelements such as descriptor and subactivities, thusforming breakdown structures.

• Task is a unit of work that a role may be asked toperform.

• Step is a content element used to organize tasksinto parts or subunits of work.

• Note that it is at the Task level that RUPassociates the roles and the artifacts produced,modified, or used.



Level of activity decomposition

Optimizing iterative and incremental development

RUP is Use-Case Driven DevelopmentA use case describes complete and meaningful services that your

system offers to users and other systems

Use cases drive the work through each iteration

– Planning of iterations

– Creation and validation of the architecture

– Definition of test cases and procedures

– Design of user interfaces and creation of user documentation

•Use-Case Model

•Analysis & Design Model

•Implementation Model

•Test Model

•Requirements

•realized by

•implemented by

•verified by

•Analysis & Design

•Implementation

•Test

RUP is Use-Case Driven Development

•Problem

•Solution Space

•Problem Space

•Needs

•Features

•Software

•Requirements

•Test Scripts•Design •User

Docs

•The Product

to Be Built

RUP metamodel

RUP Traceability

RUP Artifacts

RUP 4+1 View

• Applying all of RUP will likely result in aninefficient project environment, where teams willstruggle to keep focused on the important tasks andstruggle to find the right set of information.

• It is recommended that RUP be tailored to providean appropriate and customized process fordeveloping software.

• As an important component of tailoring the RUPframework, these workflows should be customized tosuit project or organizational needs. Thiscustomization might require redefining some of thesesequences

Tayloring

Factors that influence the configuring and tailoring ofRUP:

• Project complexity

• Organizational maturity

• Organization culture

• Regulatory compliance and policy requirements

• Development type

• Organization size

Tayloring (II)

Approaches for Adopting RUP

•Alternative 1: Use it as a knowledgebase

•Non-intrusive with minimal effort and risk

•No different than training, books, and magazines

•Alternative 2: Focused implementation aiming at fastresults

•Focused and incremental adoption with training andmentoring aiming at changing behavior - takes time andeffort

•Focus on critical areas first, it is not an all or nothing

•Use mentors / consultants to accelerate results

•Adopting RUP is a continuum between alternative 1 and 2

Tayloring (III)

Common Mistakes Adopting RUP

• Not coupling process improvement with business results

• Adopting too much of what is in RUP

• Customizing too much of RUP too early

• See https://wiki.aston.ac.uk/foswiki/pub/DanCornford/FinalYearProjectResources/RUP_Guide.pdf and

www.x-tier.com/public/RUPUPIn10EasySteps.doc

for guides of RUP adoption

Tayloring (IV)

Now, process tayloring, process specification and

process adaptation can be done by the power of

model driven initiatives and tools for process

edition (Eclipse Process Framework and IBM

Rational Process Composer).

• In November 2000 the OMG proposed a newapproach to interoperability named MDA™ (Model-Driven Architecture). MDA is one example of thebroader Model Driven Engineering (MDE) vision,encompassing many popular current researchtrends related to generative and transformationaltechniques in software engineering, systemengineering, or data engineering.

• Considering models as first class entities andany software artifact as a model or as a modelelement is one of the basic principles of MDE.

Model-driven

Source: Bézivin, J. (2006). Model Driven Engineering: An Emerging Technical Space. Generative andTransformational Techniques in Software Engineering. R. Lämmel, J. Saraiva and J. Visser, Springer Berlin /Heidelberg. 4143: 36-64.

• The OMG MDA initial proposal may be defined asthe realization of MDE principles around a set ofOMG standards like MOF, XMI, OCL, UML, CWM,and SPEM.

Model-driven (II)


• The IBM manifesto makes the claim that MDA-based approachesare founded on three ideas: Direct representation, Automationand Standards.

• Direct representation allows a more direct coupling of problems tosolutions with the help of Domains Specific Languages (DSLs).

• Automations means that the facets represented in these DSLs areintended to be processed by computer-based tools to bridgethe semantic gap between domain concepts andimplementation technologies and not only for meredocumentation.

• This should be complemented by the use of open standards thatwill allow technical solutions to interoperate

Model-driven (III)


Model-driven (IV)


•http://www.omg.org/mda/

Relations between MD* Acronyms

Source: Jordi Cabot. Clarifying concepts: MBE vs MDE vs MDD vs MDA. Available in http://modeling-languages.com/clarifying-concepts-mbe-vs-mde-vs-mdd-vs-mda/

MDA Consequences •From: http://www.omg.org/mof/

•Key: The MetaObject Facility(MOF) Specification is thefoundation of OMG'sindustry-standard environment where modelscan be exported from oneapplication, imported intoanother, transported acrossa network, stored in a repository and thenretrieved, rendered intodifferent formats (includingXMI, OMG's XML-basedstandard format for modeltransmission and storage), transformed, and used togenerate application code

MDA Consequences (II)

Source: http://www.modeliosoft.com/en/technologies/mda.html

MDA Consequences (II)

Source: http://www.jot.fm/issues/issue_2006_11/article4/

Note: XMI means XML Metadata Interchange

Source: Bézivin, J. and I. Kurtev Model-based Technology Integration with the Technical Space Concept.

Key: the Technical spaces concept

metametamodel level

metamodel level

model level

Real life level

MDA

MDA & Software Process?cd Logical Model

M3

M2

M1

M0

MetaObject Facility (MOF)

Software Process Engineering

Metamodel (SPEM) as a UML Profile

Template complete MOF-based

Metamodel M3

A defined process (RUP) from the

template M2

A specific customized implementation of

M1

Modeling Level

3: MetaObject

Facility

Modeling Level

2: Process

Metamodel

Modeling Level

1: Process Model

Modeling Level

0: Performing

process

Source: https://wiki.aston.ac.uk/foswiki/pub/DanCornford/FinalYearProjectResources/RUP_Guide.pdf

MOF

MDA & Software Process?

metametamodel level

metamodel level

model level

Real life level

SPEM

RUP SCRUM XP

Taylored Process

• A Metamodel is the construction of a collection of"concepts" (things, terms, etc.) within a certaindomain.

• A model is an abstraction of phenomena in the realworld;

• A metamodel is yet another abstraction, highlightingproperties of the model itself.

• A model conforms to its metamodel in the way thata computer program conforms to the grammar ofthe programming language in which it is written.

Metamodel (from Wikipedia)

http://en.wikipedia.org/wiki/Metamodeling

• The Software and Systems Process EngineeringMeta-model (SPEM) is a process engineeringmeta-model as well as conceptual framework, whichcan provide the necessary concepts for modeling,documenting, presenting, managing,interchanging, and enacting developmentmethods and processes.

• An implementation of this meta-model would betargeted at process engineers, project leads, projectand program managers who are responsible formaintaining and implementing processes for theirdevelopment organizations or individual projects.

SPEM Metamodel

SPEM’s Advantages

•To provide a standardized representation andmanaged libraries of reusable method content

•To support systematic development, management,and growth of development processes

•To support deployment of just the method contentand process needed by defining configurations ofprocesses and method content

•To support the enactment of a process fordevelopment projects

SPEM Introduction (I)

• Throughout the software industry there are a lotof great ideas and knowledge available abouthow to effectively develop software.

• Nowadays, development teams need and haveaccess to a wide range of information. Not onlydo they need to acquire detailed informationabout specific development technologies such asJava, Java EE, Eclipse, SOA technologies, .NET,as well as various development and toolenvironments

SPEM Introduction (II)

They also need to figure out how to organizetheir work along modern development bestpractices such as agile, iterative, architecture-centric, risk- and quality-driven softwaredevelopment.

SPEM Introduction (III)•Some problems development organizationsface when they leave their developers to findsuch information for themselves are

• Team members will not have centralized andeasy access to the same body of informationwhen they need it, i.e., different developersmight rely on different sources and versions ofthe same information

SPEM Introduction (IV)

•It’s difficult to combine and integrate contentand development processes that are madeavailable in their own proprietary format, asevery book and publication presents methodcontent and process using a differentrepresentation and presentation style

•It’s hard to define an organized andsystematic development approach that isright-sized to their needs, i.e., addresses theirspecific culture, standardized practices, andcompliance requirements.

SPEM

• SPEM

SPEM

• Evolution of CMMI

SPEM Editor (EPF)

SPEM Editor (EPF)

SPEM

Structure of the SPEM 2.0 Meta-Model

The SPEM 2.0 UML 2 Profile stereotypes defined in the Process Structure package

The SPEM 2.0 UML 2 Profile stereotypes defined in the Method Content package

The SPEM 2.0 UML 2 Profile stereotypes defined in the Process Structure package

The SPEM 2.0 UML 2 Profile stereotypes defined in the Process with Methods package

UMA (Unified Method Architecture)•UMA is an architecture to conceive, specify, andstore method and process metadata.

•UMA clearly separates Method Content definitionsfrom their application in delivery processes. It doesthis by defining the reusable core Method Contentin the form of general content descriptions and theproject-specific applications in the form of processdescriptions.

•A unified method architecture (UMA) meta-modelprovides a language for describing method contentand processes.

UMA

Method Content and Processare Separated

method = method content + process

Method content is the description of work that can be reused as key building blocks. Method content describes tasks, roles, work products, guidelines, and so on, that are involved in completing work.

Processes are the order of doing work. They provide the order for the method content. Processes will differ depending on project type, size, or other characteristics.

A Method provides both the descriptions of work and the order of work. A method is end-to-end, and is usable on a project. An example of a method is the RUP methodology.

Types of Method Content and ProcessProcess

Applies method content for assembly of many different executable processes

Specific to the scale or context of project (for example, develop from scratch versus maintain existing system, or formal and high ceremony versus agile and self-organizing)

Described with Breakdown Structures that refer to Method Content elements

Two types of processes

Delivery Process: end-to-end

Capability Pattern: reusable fragments (for example, the Inception iteration, shown in the image).

Method Content

Describes key reusable building blocks: Roles, Work Products, Tasks, and Guidance

Provides step-by-step guidelines by which specific goals are approached

Provides general development techniquesand practices, described independent of lifecycle. For example, “Analyze Use Case Behavior”, "Develop component model“, and so on.

Key:

UMA is contained in the actual version ofSPEM OMG Metamodel

Content Elements

UMA elements that describe the schemaelements for the static aspects of a process.

Content Elements

Role• A role is defined as a set of related skills, competencies,

and responsibilities. The people or tools in the rolesperform tasks and produce work products. For some tasksand work products, those in the roles are directlyresponsible for performing the tasks and producing thework products. For other tasks and work products, those inthe roles simply participate in accomplishing what’sneeded.

Content Elements

• Work Product

• Work products are produced, consumed, ormodified while a task is performed. Only onedesignated role is responsible for each workproduct.

Content Elements – WorkProduct

Artifacts

• Artifacts are tangible and can be nested in otherartifacts. For example, a software developmentplan is an artifact that contains the risk-list artifactamong others


Outcome

• An outcome is commonly intangible and notreused, which could be a state or result. Forexample, an outcome could be improvedperformance or a competed tool installation


Deliverable

• A deliverable is intended to be value provided tostakeholders internally or externally. A deliverableconsists of the other two work products: artifactsand outcomes. Deliverables are intended topackage content from other work products to beconsumed, for example, by stakeholders.

Content Elements

Task

• A task is an action performed by roles, associatedwith input and output (work products), and drivenby a goal. An example of a goal might be todevelop vision. The task describes the work tobe performed and commonly an optional set ofsteps.

Content Elements

Task

• Tasks usually last between a few hours and a fewdays and affect only a small number of workproducts. Because of their granularity, tasks areoften repeated in iterations and are often too smallfor planning purposes.

Content Elements

Step• A step represents the most granular unit of work to be

performed. It has a name and a textual description. Stepsare useful for breaking down tasks into more granularelements. They define tasks in greater detail and canseparate various aspects of the task. Even though stepsare typically conceptualized as being sequential, as part ofUMA, they are treated as optional and can be executed inany order that works to complete the task. As a generalrule of thumb, steps may call upon the performing role tothink, perform, or review

Content Elements

Guidance

• The Guidance add more details to a certainelement in a particular situation. The type ofguidance determines the content of the element.There is no limit on how many guidance elementsyou can attach to other elements. You can alsoassociate one guidance element with another.

Content Elements - Guidance

Checklist

• A checklist allows you to specify a set of statementsthat can be used to check the completion of a set ofactivities but can also be attached to work products.This guidance is especially useful for reviews andstatus checks.

Concept

• A concept guidance provides more context to keyideas used in the referenced element. For example,a concept for discipline might describe the basicprinciples, motivations, and advantages of groupingelements by disciplines.


Tool Mentor

• Tool mentors provide the technical and conceptualdetails to the user concerning how to apply the toolsto the situation outlined in the process.

Whitepaper

• This guidance element connects externally publishedpapers to the process, providing a larger scope onthe same concepts, different perspectives, andopinions. Whitepapers are commonly written andpublished independently and appear isolated fromthe process. Therefore, you can often add andremove them without consequence.


Guideline

• A guideline element supplies more in-depthinformation about the referenced element, such ashow to execute steps or complete work products.Guidelines are particularly useful for new users whoneed more assistance to complete their work.

• Guidance is a generic name for all kinds ofoptional elements attached to process or contentelements. A guideline is a specific instance orexample of it.


Template

• Template guidance elements provide a predefined structure toa work product. They are helpful for creating consistency in aproject through the use of similar work products.

Term Definition

• This guidance element defines and describes commonconcepts and puts them in a glossary. The individual termscan then be used in other content element descriptions toprovide guidance similar to an encyclopedia. The glossary isautomatically generated when the process is published andterm definitions are not attached to other content elementslike the rest of the guidance elements...


Roadmap

• Roadmap guidance elements are associated withactivities to guide the user through a complexprocess, providing a start-to-finish scenario

Supporting Material

• Any required guidance elements that do not fit thedefinition of any of the other guidance elements canbe described as supporting material. No specificintent is outlined other than the general purpose ofproviding a kind of guidance that can not be specifiedelsewhere.


Examples

• Examples show a practical application of a work product ortask. For instance, a project plan template becomes moredescriptive when a real example of the artifact isdemonstrated. Examples provide a hands-on application ofother content elements.

Report

• Report guidance elements describe the standards forpredefined forms and layouts of information. They are oftenused in combination with tool automation when the structureand content of the generated report requires specification.The report guidance also describes the information extractedfrom work products.


Estimation Consideration

• Each estimation consideration guidance offers additionalinformation about a specific estimation technique. It providessample situations in which the technique can be applied.Estimation consideration guidance elements usually referenceother elements that require cost, schedule, or work-effortestimation

Practice

• Practice guidance elements describe positive, provenstrategies that are applied in various situations. For example,the practice of iterative development impacts many tasks,work products, and roles and contributes to the overallsuccess of the project


Reusable Asset

• Assets are useful elements that provide value andquality. If a solution provides value in varioussituations in a certain context, it can be treated as areusable asset. A reusable asset might be, forexample, a design pattern that can then be directlylinked to a tool of choice (such as IBM RationalSoftware Architect)

Content Elements

Categories

• Categories are useful organizational and structuralaids that can be used to group content elements.

Content Elements – Categories

Discipline

• Discipline categories aid in allocating certain contentelements (that is, tasks, capability patterns, andguidance) to a certain area of concern.

Domain

• This category groups content elements based onresources, timing, or relationship. Compared todisciplines, domains can be broken down evenfurther, into subdomains, creating a domainhierarchy. Even though domains often group contentelements from the same discipline, such groupingsare not limited to intradiscipline content.

Content Elements - Categories

Role Set

• Even though both roles are grouped into differentdomains and disciplines, the roles are associatedwith management. You can use the role set tocategorize these roles and group them as managers.

Tool Category

• In the tool category, tool mentors are usually bundledtogether as a unit to provide one view of all the toolmentors used.

Process Elements

•Process elements organize content elementsinto activities and lifecycles and give thecontent a sequential structure. Theseelements help answer questions about whencontent elements occur, either sequentially orin parallel.

The advantage of separating theprocess elements from thecontent elements is that processengineers can assembleprocesses from existing contentelements based on the needs of aparticular project

Process Elements

Activities

• Method content (specifically tasks) is bundled intoactivities, which group a unit of work. In contrast totasks, activities are not considered methodcontent because they are work breakdownelements. Activities might contain otheractivities.

Iteration

• The iteration process element allows processengineers to group activities that are planned to berepeated more than once. Iterations represent aspecial form of activity.

Process Elements

Phase

• A phase element groups process elements into asignificant period in a project. Phases are oftenrelated to different views or project perspectives.They are a variation of an activity concept.

Process Elements

Capability Pattern

• Capability patterns are incomplete process fragments that cancontain activities and milestones. Grouping common processelements into capability patterns enables process engineersto reuse these process fragments and compose deliveryprocesses from them.

Delivery Process

• The intent of a delivery process is to publish and deploy whatis grouped so the user can eventually consume it. Deliveryprocesses are end-to-end project lifecycles assembled from aset of activities, phases, iterations, capability patterns, andmilestones.

Process Elements

Milestone

• Milestones are decision points. They might follow an activity, capability pattern, phase, or iteration to verify a certain situation followed by a decision. Milestones are often associated with metrics that compare a plan with the actual result.

Process Package

• For organizational purposes, process packagesgroup process elements into folders.

Process Diagrams

Workflow Diagram

• is a tailored version of the UML activity diagram,

• can contain a start and end point, decision nodes, links,activities, synchronization bars, task descriptors phases, andmilestones.

• The workflow diagram provides a high-level overview of theactivities and their sequence.

• The guards allow branching in certain situations, whereas thesynchronization bars demonstrate which activities areperformed in parallel.

• The user can drill down into each activity to retrieve an activitydetail diagram to get further details on the activity.

Process Diagrams - WorkflowDiagram

Process Diagrams

Activity Detail Diagram

• Gives a visual overview of the task descriptors withinan activity, the responsible role descriptorsassociated with the task descriptors, and the inputand output work product descriptor.

• A descriptor is basically a reference object inside aprocess that represents the occurrence of a methodcontent element, such as a task or work productinside an activity. It has its own relationships anddocumentation that defines the difference betweenthe default implementation and this particularoccurrence of the element in the process.

Process Diagrams - ActivityDetail Diagram

Process Diagrams

Work-Product Dependency Diagram

•The work-product dependency diagramillustrates the relationships and dependenciesamong various work products.

Process Diagrams

Work-Product Dependency Diagram

NowIBM proposes the Rational Process Library, The industry’smost robust collection of practices guidance

•Governance•Governance

•Governance

•Governance•Governance

Customizable Process Library

Rational Unified Process

Process Design & Management

IBM Practices

CMMI

GDD

SOA Gov

ITUP

Tooling

Author

Manage

Re-use

Configure

Tailor

Publish

Reporting

Deploy

Estimate

Over 100 practices and processes to leverage & customize…

IBM Rational Method Composer v7.5

Agile Core

Governance and Compliance

Quality Management

Requirements Management

Change & Release Management

Architecture Management

IBM Practices in key solution areas

Questions?

Thanks