Implementing ISO/IEC 12207 Standard using

Rational Unified Process

Sheila S. Reinehr Ricardo Balduino Cristina Â. F. Machado Marcelo S. Pessôa

Pontifícia Universidade Rational Software Companhia de Universidade de SP
Católica do Paraná IBM Software Group Informática do Paraná Escola Politécnica
Curitiba - Paraná – Brazil São Paulo - SP - Brazil Curitiba - Paraná – Brazil São Paulo – SP – Brazil

Abstract
Software Engineering is a relatively new discipline when compared to other more traditional
engineering disciplines, such as civil, mechanical and so on. Several frameworks dealing with quality
issues of software processes are being developed and implemented by software organizations in order
to become software development more closely related to an engineering project. One of the most
critical difficulties to implement them is how to interpret the generic statements of these models and
how to transform them in daily executable activities. The international Standard that deals with
software processes definition is the ISO/IEC 12207. As other generic frameworks, this Standard does
not prescribe any specific implementation life cycle model, method or tool. In the other hand,
commercial models and frameworks, such as the Rational Unified Process (RUP), prescribes detailed
implementation guidelines. This paper focuses on investigating how RUP can be used to implement the
ISO/IEC 12207 Standard.

Keywords: RUP, ISO/IEC 12207, software process, iterative and incremental approach, software
quality.

1 Introduction
Software Engineering is a relatively new easily implemented in practice. In the real world,
discipline when compared to other more organizations face lots of doubts in how to
established engineering disciplines such as civil, interpret and implement such frameworks in order
mechanical and so on. In order to evolve it, to be compliant to certification rules.
several frameworks dealing with quality issues of In the other hand, more specific software
the software processes have being developed. processes are being implemented by software
Among these frameworks, one of the most known organizations, with different levels of success.
and used is the Capability Maturity Model – One of these processes is the Rational Unified
CMM [5], developed and updated by the Process - RUP [3] developed to support the object
Software Engineering Institute (SEI). It provides, oriented approach using Unified Modeling
not only a framework that enables the Language (UML).
organization to define its processes, but also an The main difference between RUP and
evaluation method to guide an improvement more generic frameworks, such as ISO Standards
effort. Besides SEI framework, the International and CMM family, is the abstraction level. In the
Organization for Standardization (ISO) is also former, there are detailed activities, templates,
developing international standards to act as broad guidance and so on, enabling it to be more easily
frameworks to software processes definition and implemented in practice, but with narrower use.
improvement. The ISO standard which deals with The other ones stand in a higher abstraction level,
process definition is the ISO/IEC 12207:1995 - enabling them to be used in a broader variety of
Information Technology - Software Life Cycle organizations and purposes, although they require
Processes [1]. more interpretation effort.
One of the difficulties to deal with these This work aims at providing a way of
frameworks is that they are too generic to be implementing the ISO/IEC 12207 Standard,
considering its amendment published in late 2002, complete commercial product. This product
using RUP. includes: process descriptions, methods, tools,
This paper is organized as follow: section templates, guidelines, examples and white papers.
2 presents ISO/IEC 12207 and RUP separately, RUP is based on six best practices
section 3 presents how RUP can be used to identified by the authors in some software

• Develop Iteratively: the use of iterative

implement ISO/IEC 12207, section 4 presents the organizations:
conclusions.
approach to identify and eliminate risks

• Manage Requirements: to ensure resilience in

2 ISO/IEC 12207 and RUP before they threaten the project;

• Use Component Architectures: to make the

2.1 ISO/IEC 12207 the face of inevitable changes;
ISO/IEC 12207 was originally published
in 1995 [1], as a taxonomy for software life cycle architecture tangible to all practitioners and to

• Model Visually: to preserve high quality

processes. It was developed to allow the software facilitate reuse;
and business community to “speak the same
language”. The standard framework was architecture and to ensure proper

• Continuously Verify Quality: to ensure quality

conceived to be flexible, modular and adaptable communication among project members;
to the needs of the product to be constructed.

• Manage Change: to enable efficient parallel

It was organized in three sets of throughout the development life cycle;
processes: Primary Life Cycle Processes,
Supporting Life Cycle Processes and development within teams and across the
Organizational Life Cycle Processes. enterprise.
In 2002, it was published an amendment The process is divided into nine core
in order to incorporate received feedbacks to disciplines (Business Modeling, Requirements,
complement the original work [2]. The resulting Analysis and Design, Implementation, Test,
Deployment, Project Management, Configuration
• Basic: processes and sub-processes are
changes were classified as:
and Change Management and Environment) and
four life cycle phases (Initiation, Elaboration,
• New: processes and sub-processes are an
identical to the original Standard;
Construction and Transition).

• Extended: processes and sub-processes are

expansion to the original process definition;
3 How RUP implements ISO/IEC
• Component: processes and sub-processes are
elaborations of the existing ones; 12207
grouping of existing activities of the original As stated in previous sections, although
Standard. the Standard has a lot of processes, activities,
The Standard, including its amendment, tasks and outcomes, it does not prescribe any
is now composed of 22 processes, 95 activities, specific method or tool. In the other hand, RUP
325 tasks and 254 outcomes. It does not specify prescribes, not only activities related to the
how to execute these processes, leaving this to the development process, but also some methods,
organization. techniques and tools.
To facilitate the implementation of
2.2 Rational Unified Process (RUP) ISO/IEC 12207 using RUP it was chosen to
The concept of using a process to structure the work in tables, using as the basis the
implement the Unified Modeling Language original Standard and its amendment (which is
(UML) approach was formerly introduced by referred as Annex F or G in ISO/IEC 12207
Jacobson, Booch and Rumbaugh as The Unified activity column). Each Standard activity,
Process [4]. Some years later, it became the whenever it is possible, is related to RUP
Rational Unified Process (RUP), which is not discipline, workflow detail and activity.
only a software development process, but also a Additional comments are provided to help the
reader to understand how they fit or the reasons according RUP, in Table 2. As can be seen, they
why they do not fit. are almost all covered by RUP, with different
The Primary Life Cycle Processes of levels of completeness.
ISO/IEC 12207 standard are: Acquisition, Supply, The Organizational Processes of the of
Development, Operation and Maintenance. As ISO/IEC 12207 standard are: Management,
can be seen in Table 1, the best covered Primary Infrastructure, Improvement, Human Resources,
Process is the Development process. Asset Management, Reuse Program Management
The Supporting Life Cycle Processes of and Domain Engineering. They are detailed in
ISO/IEC 12207 standard are: Documentation, Table 3 and it can be seen that half of them are
Configuration Management, Quality Assurance, not covered in any level of detail.
Verification, Validation, Joint Review, Audit,
Problem Resolution, Usability and Product
Evaluation. These processes are analyzed,

Table 1. Primary Life Cycle Processes.

ISO/IEC 12207 RUP Analysis

•
(Process:Activity) (Discipline: Workflow Detail: Activity)
Acquisition: Requirements: Analyze the Fully covered. There is no specific Acquisition

•
Acquisition Problem: Develop Vision Process in RUP; however, the indicated activities
Initiation Project Management: Conceive allow one to reach the following goals of
New Project: Develop Business Acquisition Initiation: define acquisition needs,
define and analyze requirements, identify options
•
Case
Project Management: Evaluate and document an acquisition plan, including risks
Project Scope and Risk: Identify and methods to manage them.

•
and Assess Risks
Acquisition: Project Management: Develop Partially covered. There is no specific activity in
Acquisition Software Development Plan RUP regarding to proposal request for suppliers.
Preparation However, the results of the activities in the
(Annex F) workflow detail Develop Software Development
Plan can be used as input to make a proposal.
RUP does not provide criteria to select a supplier.
The Software Development Plan artifact should
be developed by acquirer in a proper level of
detail to generate a proposal for the supplier. The
supplier instead of the acquirer will execute the

•
Project Organization and Staffing activity.
Acquisition: Not covered There is no support in RUP for this activity.
Supplier Selection

•
(Annex F)
Acquisition: Project Management: Monitor and Fully covered. However, the supplier instead of
Supplier Control Project the acquirer will execute the Schedule and Assign
Monitoring Work activity.

•
(Annex F)
Acquisition: Project Management: Close-Out Fully covered. This activity in Standard is fully
Customer Project: Project Acceptance supported by mentioned activity in RUP.
Acceptance Review

•
(Annex F)
Supply: Initiation Requirements: Manage Changing Partially covered. There is no specific Supply
Requirements process in RUP. The goals of Initiation activity
(revise requirements of proposal and contract
agreement) can be partially covered by the
Manage Changing Requirements workflow detail.
Supply: • Not covered There is no specific activity in RUP.
Preparation of

•
Response
Supply: Contract Not covered There is no specific activity in RUP, although the
artifacts Vision and Software Development Plan

•
can be used as input to the contract.
Supply: Planning Project Management: Develop Fully covered. According to the Standard, a life-

•
Software Development Plan cycle model should be defined (if not stipulated in
Requirements: Manage the Scope contract). By using RUP, the adopted model is the
of the System iterative and incremental one. Critical
requirements should be allocated to initial
iterations in order to reduce risks.
The supplier should develop the whole Software
Development Plan artifact, including all

•
associated plans.
Supply: Execution RUP phases: Elaboration and Fully covered. According to the Standard, the

•
and Control Construction Execution activity invokes the Development
Project Management: Monitor and Process. It means executing Elaboration and
Control Project Construction phases of RUP. The Monitor and
Control Project workflow detail supports the

•
Control aspect.
Supply: Review Test Fully covered by Test discipline in RUP.

•
and Evaluation

•
Supply: Delivery Deployment Fully covered. The Deployment discipline
and Completion Project Management: Close-out describes the activities associated with ensuring
Project that the software product is available for its end
users. The Close-out Project workflow detail
provides the guidelines to properly conclude the

•
project.
Development: Environment: Prepare Fully covered. RUP provides a specific artifact
Process Environment for Project called Development Case. This artifact is used to
Implementation describe the RUP customization to be applied in

•
the project and its associated rationales.
Development: Business Modeling: Assess Fully covered. This activity in Annex F is related

•
Requirements Business Status to gathering, processing and tracking evolving
Elicitation Business Modeling: Describe stakeholders’ needs, which are fully supported by
(Annex F) mentioned workflow details.
•
Current Business
Business Modeling: Identify The main goal of Business Modeling discipline in
RUP is to understand the structure and the
•
Business Process
Business Modeling: Refine dynamics of the organization in which a system is
to be deployed, and to derive the system
•
Business Process Definitions
Business Modeling: Develop a requirements needed to support the target
organization.
•
Domain Model
Requirements: Analyze the

•
Problem
Requirements: Understand

•
Stakeholder Needs
Requirements: Managing
Changing Requirements
Development: • Business Modeling: Design Partially covered. This activity is related to

•
System Business Process Realizations transforming stakeholders’ requirements into
Requirements Business Modeling: Refine Roles system technical requirements, which is supported
Analysis by the remaining workflow detail of
•
and Responsibilities
Requirements discipline.
•
Requirements: Define the System
Requirements: Refine the System It is important to notice that the Standard uses the
Definition term system in a broader meaning. RUP is a
software development process, which means that

•
the term system is used to refer to software.
Development: Business Modeling: Explore Partially covered. According to the Standard, this

•
System Process Automation activity is related to defining and allocating
Architectural Analysis and Design: Define a system requirements among hardware, software

•
Design Candidate Architecture and manual-operations.
Analysis and Design: Refine the In the Explore Process Automation workflow
Architecture detail, RUP establishes what should be automated

•
by software.
Development: Analysis and Design: Analyze Fully covered. In this workflow detail, the
Software Behavior behavioral descriptions provided by the software
Requirements requirements are transformed into a set of

•
Analysis elements upon which the design can be based.
Development: Analysis and Design: Design Fully covered. This activity is fully supported by

•
Software Design Components RUP.
Development: Implementation: Structure the Fully covered. This activity is fully supported by

•
Software Implementation Model RUP.
Construction Implementation: Implement

•
Components
Development: Implementation: Plan the Fully covered. This activity is fully supported by

•
Software Integration RUP.
Integration Implementation: Integrate each

•
Subsystem
Development: Test: Test and Evaluate: Fully covered. In the Standard, the purpose of

•
Software Testing Implement Test this activity is to ensure that the integrated
Test: Test and Evaluate: Execute software product meets its defined requirements.
Test Suite The Integrate Each Subsystem workflow detail,
from Implementation Discipline, invokes the

•
specified workflow details from Test discipline.
Development: Implementation: Integrate the Partially covered. There is no specific activity in
System System RUP. According to the Standard, this activity
Integration means integrating software items, hardware items,
manual-operations and other systems, as
necessary. However, RUP only deals with
software system and subsystems. In order to be
compliant to the Standard, it is necessary to
review Business Modeling artifacts to have a

•
broader view of the Integration Plan.
Development: Test Fully covered. This activity is fully supported by

•
System Testing RUP.
Development: Deployment Fully covered. This activity is fully supported by
Software RUP.

•
Installation
Operation: Not covered There is no specific activity in RUP. Environment
Process discipline does not cover process implementation
Implementation for operational environment.
Operation: • Deployment: Manage Acceptance Fully covered. In RUP, the role responsible for
Operational Test: Manage Acceptance Tests managing acceptance tests in operational
Testing environment is the Deployment Manager, while in
the Standard this activity is carried on by the

•
operator.
Operation: Not covered There is no specific activity in RUP. RUP covers
Operational Use development process from inception to transition
(Annex F) to operational environment. After that, the users

•
carry on operational activities.
Operation: Not covered There is no specific activity in RUP. RUP does
Customer Support not cover assistance and consultation to the

•
(Annex F) customers.
Maintenance: Environment: Prepare Fully covered. RUP provides a specific artifact
Process Environment for Project called Development Case. This artifact is used to
Implementation describe the RUP customization to be applied in
the project and its associated rationales. It can be
either used to the development process or to the

•
maintenance process.
Maintenance: Configuration and Change Fully covered. RUP uses the Change Requests
Problem and Management: Manage Change artifact to document and track defects,

•
Modification Requests enhancement requests and any other type of
Analysis Requirements: Managing request for a change in the product. The benefit of
Changing Requirements: Manage Change Requests is that they provide a record of
Dependencies decisions and, due to their assessment process,
ensure that change impacts are understood across
the project.
Manage Dependencies activity assists in
managing the scope of the project and managing

•
changing requirements.
Maintenance: RUP phases: Elaboration and Partially covered. The Development Process in
Modification Construction the Standard is used to implement the
Implementation modifications. So, the same comments made to

•
the Development Process apply to this one.
Maintenance: Deployment: Manage Acceptance Fully covered. Deployment discipline describes

•
Maintenance Test: Manage Acceptance Tests the activities associated with ensuring that the
Review/ Project Management: Close-out software product is available for its end users and
Acceptance Project it is accepted.
Close-Out Project workflow detail provides the

•
guidelines to properly conclude the project.
Maintenance: Deployment: Plan Deployment: Partially covered. The Migration Plan is
Migration Develop Deployment Plan developed in RUP, but there are no activities to

•
describe how to implement this plan.
Maintenance: Not covered There is no specific activity in RUP. RUP does
Software not treat the retirement of the software in any of
Retirement its activities.
 Table 2. Supporting Life Cycle Processes.
ISO/IEC 12207 RUP Analysis

•
(Process:Activity) (Discipline: Workflow Detail: Activity)
Documentation: Environment: Prepare Fully covered. RUP provides a specific artifact
Process Environment for Project: Develop called Development Case. This artifact is used to
Implementation Development Case describe the RUP customization to be applied and
its associated rationales, including documentation
and reports that should be produced according to

•
project needs.
Documentation: Environment: Prepare Fully covered. In the Environment discipline all
Design and Environment for Project: Develop templates are defined and developed for the
Development Project-Specific Templates project.

Documentation: • All disciplines Fully covered. RUP provides templates for

Production artifacts to be created throughout software
development life cycle. It also suggests Rational
and other vendors’ tools to automate document

•
management.
Documentation: All disciplines Fully covered. Same comments of
Maintenance Documentation: Production.

Configuration • Configuration and Change Fully covered. RUP fully supports this activity.
Management: Management: Plan Project
Process Configuration and Change

•
Implementation Management Control
Configuration Configuration and Change Fully covered. In RUP, a configuration
Management: Management: Create Project CM management tool should control all artifacts
Configuration Environments: Set Up CM versions and baselines.

•
Identification Environment
Configuration Configuration and Change Fully covered. RUP fully supports this activity.
Management: Management: Manage Change

•
Configuration Requests
Control Configuration and Change
Management: Change and Deliver

•
Configuration Items
Configuration and Change
Management: Change and Deliver

•
Perform Configuration Audit
Configuration Configuration and Change Fully covered. RUP fully supports this activity.
Management: Management: Monitor and Report
Configuration Configuration Status

•
Status Accounting
Configuration Configuration and Change Fully covered. RUP fully supports this activity.
Management: Management: Monitor and Report
Configuration Configuration Status: Perform

•
Evaluation Configuration Audit
Configuration Configuration and Change Fully covered. RUP fully supports this activity.
Management: Management: Manage Baselines
Release and Releases: Create Deployment
Management and Unit
Delivery
Quality • Project Management: Develop Partially covered. In RUP the Project Manager
Assurance: Software Development Plan: role is responsible for creating the Quality
Process Develop Quality Assurance Plan Assurance Plan as part of the Software
Implementation Development Plan artifact.
The Standard establishes that the quality
assurance activities must be performed by
organizational independent individuals. In RUP
the quality assurance issue is implemented by
using reviews. However, RUP does not establish
that the reviews must be performed by
independent individuals as required by the
Standard. If all of those review activities were
performed by PRA – Project Review Authority, it

•
would be compliant to the Standard.
Quality Business Modeling: Refine Partially covered. The activity Manage

•
Assurance: Business Process Definition Acceptance Test holds the responsibility to ensure
Product Requirements: Manage Changing that the product satisfies its intended criteria as
Assurance Requirements: Review established in the artifact Product Acceptance

•
Requirements Plan. The same comments made to the process
Analysis and Design: Design implementation are valid here.

•
Components: Review the Design
Implementation: Implement

•
Components: Review Code
Deployment: Manage Acceptance

•
Test: Manage Acceptance Tests
Test: Validate Build Stability:

•
Execute Test Suite
Quality Not covered There is no specific activity in RUP. There is a
Assurance: specific activity related to produce the artifact
Process Develop Development Case which defines all
Assurance processes to be used in the project. However,
there is no activity related to verifying the actual

•
execution of the processes.
Quality Not covered There is no specific activity in RUP. This activity
Assurance: of the Standard refers to the ISO 9000 concept of
Quality Assurance Quality Assurance Systems. There is no specific

•
Systems activity in RUP regarding to such aspects.
Verification: Project Management: Develop Fully covered. The Standard states that the
Process Software Development Plan: Plan verification activities may be executed with
Implementation Phases and Iterations varying degrees of independence. RUP
implements the verification processes using
reviews. This activity provides the milestones of
each phase and iteration and the related review

•
procedures.
Verification: Business Modeling: Refine Fully covered. The Verification process of the

•
Verification Business Process Definition Standard includes verifying: the contract, the
Requirements: Manage Changing process, the requirements, the design, the code,
Requirements: Review the integration and the documentation.

•
Requirements
Analysis and Design: Design

•
Components: Review the Design
Implementation: Implement
Components: Review Code
Validation: • Project Management: Develop Fully covered. The Standard states that the
Process Software Development Plan: validation activities may be executed with varying
Implementation Develop Product Acceptance Plan degrees of independence. RUP implements the
validation processes using reviews. The Product
Acceptance Plan describes how the customer will
evaluate deliverable artifacts of a project to
determine if they meet a predefined set of

•
acceptance criteria.

•
Validation: Test discipline Fully covered. The Standard focuses validation by
Validation Project Management: Close-Out means of testing. The Test discipline, combined
Project: Project Acceptance with Close-Out project fully covers Standard
Review needs.

Joint Review: • Project Management: Develop Fully covered. This activity provides the
Process Software Development Plan: Plan milestones of each phase and iteration and the
Implementation Phases and Iterations related review procedures. The Standard does not
prescribe the mandatory involvement of the

•
customer.
Joint Review: Project Management: Monitor and Fully covered. Project Management discipline in
Project Control Project: PRA Project RUP has a role called Project Review Authority
Management Review. that performs the management review.

•
Reviews
Joint Review: Business Modeling: Refine Fully covered. These activities in RUP are related
Technical Business Process Definition: to reviewing artifacts, in order to validate
Reviews Review the Business Use-Case software products.

•
Model
Business Modeling: Refine Roles
and Responsibilities: Review the

•
Business Object Model
Requirements: Manage Changing
Requirements: Review

•
Requirements
Analysis and Design: Refine the

•
Architecture: Review Architecture
Analysis and Design: Design

•
Components: Review the Design
Implementation: Implement

•
Components: Review Code
Audit: Process Not covered There is no specific activity in RUP.
Implementation
Audit: Audit • Not covered There is no specific activity in RUP.
Problem • Project Management: Develop Fully covered. The Problem Resolution Plan
Resolution: Software Development Plan: provides a defined procedure for managing and
Process Develop Problem Resolution Plan resolving problems experienced during the
Implementation project, so appropriate corrective actions can be
taken.
Problem • Configuration and Change Fully covered. Detected problems are submitted
Resolution: Management: Manage Change by any role from development team. The owner of

•
Problem Requests: Submit Change Requests a request or the Change Control Board can update
Resolution Configuration and Change it. The Change Control Board makes reviews on
Management: Manage Change change requests. Corrective actions should be
Requests: Update Change taken.

•
Requests
Configuration and Change
Management: Manage Change
Requests: Review Change

•
Requests
Project Management: Monitor and
Control Project: Handle

•
Exceptions and Problems
Usability Not covered There is no specific activity in RUP. The focus of
the Usability process in the Standard is the
Human-Centred Design concept - driving the
development by the user needs. RUP does not
provide any specific process focused on this, it
only has a concept called User-Centred Design, in
the Requirements discipline. Traditional aspects
of usability are provided by the prototypes

•
developed in the Requirements discipline.
Product Project Management: Develop Fully covered. Acceptance criteria are defined,
Evaluation: Software Development Plan: the project is reviewed and closed-out.

•
Product Develop Product Acceptance Plan
Evaluation Project Management: Close-Out
(Annex F) Project: Project Acceptance

•
Review
Project Management: Close-Out
Project: Prepare for Project
Close-Out

Table 3. Organizational Life Cycle Processes.

ISO/IEC 12207 RUP Analysis

•
(Process:Activity) (Discipline: Workflow Detail: Activity)
Management: Environment: Prepare Partially covered. The Development Case artifact
Initiation and Environment for Project: Develop is used as means of tailoring the organizational
Scope Definition Development Case process to be applied to the project, including the
Project Management discipline.
The Management Process in the Standard focuses
on managing all processes and the Project
Management discipline in RUP focuses on

•
managing the development process.
Management: Project Management: Develop Fully covered. The Project Management
Planning Software Development Plan discipline holds a specific activity to develop the
Software Development Plan and its associated
sub-plans. It covers all planning aspects of the

•
Standard.
Management: Project Management: Monitor and Partially covered. The Monitor and Control
Execution and Control Project activity fully covers execution and control needs
Control of the development process of the Standard, but it
does not cover the other Standard processes.
Management: • Project Management: Manage Fully covered. Each RUP iteration and phase ends

•
Review and Iteration: Assess Iteration with a milestone including a formal Review in
Evaluation Project Management: Manage order to approve that iteration or phase. Besides,
Iteration: Iteration Acceptance RUP also has several activities related to artifacts

•
Review specific reviews.
Project Management: Close-Out
Phase: Life cycle Milestone

•
Review
Project Management: Close-Out
Project: Project Acceptance

•
Review
Management: Environment: Prepare Partially covered. In RUP the artifact
Organizational Environment for Project: Assess Development-Organization Assessment is
Alignment Current Organization produced in order to assess the current status of
(Annex F) the organization in terms of business, processes,
tools and people. But, it does not cover the full
Standard objective that is effectively aligning the

•
business goals.
Management: Not covered There is no specific activity in RUP. RUP focuses
Organization on the development process and does not provide
Management an organizational management process.

•
(Annex F)
Management: Project Management Fully covered.
Project
Management

•
(Annex F)
Management: Project Management: Develop Partially covered. The product quality aspect is
Quality Software Development Plan: fully covered by RUP practices. As RUP focuses
Management Develop Software Quality on the development process and does not provide

•
(Annex F) Assurance Plan an organizational quality management process,
Project Management: Develop the full quality aspect of the Standard is not
Software Development Plan: covered.
Define Monitoring and Control

•
Processes
Management: Project Management: Develop Partially covered. RUP covers the activity, mainly
Risk Management Software Development Plan: focusing on architectural risks mitigation. But,

•
(Annex F) Develop Risk Management Plan using the artifacts Risk Management Plan and
Project Management: Evaluate Risk List, it is possible to identify, monitor and
Project Risk and Scope: Identify control any kind of risk.

•
and Assess Risk
Project Management: Monitor and
Control Project: Monitor Project

•
Status
Management: Project Management: Develop Partially covered. The Project Management
Measurement Software Development Plan: discipline provides a specific activity to define a

•
(Annex F) Develop Measurement Plan Measurement Plan and also provides processes
Project Management: Develop for monitoring and controlling the measurement
Software Development Plan: process.
Define Monitoring and Control As RUP focuses on the development process and
does not provide an organizational process, the
•
Processes
Project Management: Monitor and full measurement aspect of the Standard is not
Control Project: Monitor Project covered.
Status
Infrastructure: • Environment: Prepare Fully covered. RUP fully supports this activity.
Establishment of Environment for Project: Select &

•
the Infrastructure Acquire Tools
Environment: Prepare
Environment for an Iteration: Set

•
up Tools
Environment: Prepare
Environment for an Iteration:
Verify Tool Configuration &

•
Installation
Environment: Support
Environment During an Iteration:

•
Support Development
Infrastructure: Environment: Support Fully covered. RUP fully supports this activity.
Maintenance of Development During an Iteration:

•
the Infrastructure Support Development
Improvement: Environment: Prepare Fully covered. The tailoring process for the
Process Environment for Project: Assess project is part of the following workflow details:

•
Establishment Current Organization Prepare Environment for Project and Prepare
Environment: Prepare Environment for an Iteration.
Environment for Project / Besides activity descriptions, RUP also provides
Iteration: Develop Development some guidelines and concepts in order to help

•
Case implementing and evaluating the processes. For
Environment: Prepare this specific case, RUP provides a concept called
Environment for Project Iteration: “Implementing a Process in an Organization”
Develop Project-Specific found in the Environment discipline.

•
Templates
Environment: Prepare
Environment for an Iteration:

•
Launch Development Case
Improvement: Environment: Prepare Fully covered. RUP provides an activity
Process Environment for Project: Assess specifically dedicated to assess current
Assessment Current Organization organization which means, among other things,
assessing its processes.
Besides activity descriptions, RUP also provides
some guidelines and concepts in order to help
implementing, evaluating and improving the
processes. For this specific case, RUP provides a
concept called “Implementing a Process in an
Organization” found in the Environment

•
discipline.
Improvement: Environment: Prepare Partially covered. RUP enforces the need of
Process Environment for Project: Assess process tailoring and improvement, producing, for

•
Improvement Current Organization this purpose, the artifact Development Case.
Environment: Prepare There is no specific activity in RUP regarding to
Environment for Project: Develop organizational process improvement. But, it
Development Case provides some guidelines and concepts in order to
help implementing, evaluating and improving the
processes. For this specific case, RUP provides
some concepts, found in the Environment
discipline, such as: “Implementing a Process in
an Organization”, “Process Quality”, and
“Process Configuration”.
Human • Not covered There is no specific activity in RUP.
Resources:
Process
Implementation
(Annexes F and

•
G)
Human Project Management: Manage Partially covered. This RUP activity addresses the
Resources: Iteration: Acquire Staff training needs to the project staff but RUP does
Define Training not provide an organizational policy to staff

•
Requirements training.
Human Project Management: Manage Partially covered. This RUP activity addresses the
Resources: Iteration: Acquire Staff recruitment of project staff but RUP does not
Recruit Qualified provide a systematic program for recruitment of

•
Staff staff.
Human Project Management: Monitor and Fully covered. This RUP activity addresses the
Resources: Control Project: Monitor Project performance evaluation once it compares the
Evaluate Staff Status planned effort and the actual effort spent on

•
Performance project activities.
Human Project Management: Develop Partially covered. Although RUP has activities
Resources: Software Development Plan: regarding to project staffing it does not provide
Establish Team Define Project Organization and any activity with an organizational concern.

•
Requirements Staffing
Project Management: Manage

•
Iteration: Acquire Staff
Human Not covered There is no specific activity in RUP.
Resources:
Knowledge

•
Management
Asset Not covered There is no specific activity in RUP.
Management

Reuse Program • Not covered There is no specific activity in RUP. RUP does
Management not provide a systematic program for reuse (only

•
at the project level).
Domain Business Modeling: Develop a Partially covered. RUP has a specific activity to
Engineering Domain Model develop a domain model, but it does not have any
other activity specifically related to asset
provision or asset maintenance.

4 Conclusions Other important aspect of the Standard

that is not covered by RUP is the legal issue
One of the most important differences involved in the acquirer-supplier relationship. The
between ISO/IEC 12207 and RUP is the focus Standard enforces the need of having a legal
level. The Standard is highly focused on the contract and RUP does not have any explicit
organizational level while RUP is mainly focused activity regarding to this issue.
on the project level. Although RUP processes can The subcontract management is also
be used by the whole organization, there is no barely treated by RUP. There are no activities
explicit activity driving this effort, as can be seen describing how to handle a subcontract
by the Standard activities in Table 3 – relationship.
Management: Organizational Alignment; Table 3 It can be observed in section 3 that there
- Management: Organization Management, Table are some processes of ISO/IEC 12207 that are
3 – Management: Quality Management. fully covered by RUP. This is the case of the
Development process which initiates with the
elaboration of the Development Case artifact, It can also be observed in section 3 that
describing the process to be used in the project; there are some processes of the Standard that are
and ends with the software installation executed not addressed by RUP. This is the case of the
thru the Deployment discipline. There is only one Operation process. As RUP has a development
concern: in order to be fully compliant to the perspective, it does not cover the operation, which
standard, RUP activities and artifacts should be is supposed to be carried on by the client. Other
used in a broader manner, considering the concept processes that are not covered by RUP includes:
of system, instead of simply software. There are Audit, Usability, Asset Management and Reuse
other processes fully covered by RUP as: Program Management.
Documentation, Configuration Management, Analyzing this work in detail it is
Verification, Validation, Joint Review, Problem possible to conclude that RUP can be used in
Resolution, Product Evaluation and order to implement ISO/IEC 12207 Standard but
Infrastructure processes. it must be extended and evolved in order to be
As also analyzed in section 3, there are fully compliant to the Standard requirements.
some processes of the Standard that are partially
covered by RUP. One of these processes is the 5. References
Acquisition process. RUP does not cover it in
sufficient detail and the reader must use the [1] ISO/IEC - International Organization For
artifacts only as basis to define the proposal and Standardization / International Electrotechnical
the legal contract. In the same line, RUP can not Comission. ISO/IEC 12207:1995(E) – Information
be directly mapped into Supply process activities technology – Software Life Cycle Processes. ISO/IEC,
of the Standard, but it provides some artifacts to 1995.
help the user to properly define needed outcomes.
The Maintenance process is almost all [2] ISO/IEC - International Organization For
Standardization / International Electrotechnical
covered by RUP, except by the retirement
Comission. ISO/IEC 12207:1995 / Amendment
activity. Here there is another important 1:2002– Information technology – Software Life Cycle
difference between them. RUP does not provide Processes – Amendment 1. ISO/IEC, 2002.
any activity regarding to the retirement of the
software product. It is mainly because RUP [3] KRUCHTEN, P. The Rational Unified Process –
focuses the Development process and not the An Introduction – Second Edition. Reading, MA:
Operation process. Addison-Wesley Publishing Company, 2000, 298 p.
Except by the organizational aspect,
previously stated, Quality Assurance process is [4] JACOBSON, IVAR; BOOCH, GRADY;
partially covered by RUP (considering that it RUMBAUGH, JAMES. The Unified Software
Development Process. Reading, MA: Addison-Wesley
must implement the ISO 9000 aspects). The
Publishing Company, 1999, 463 p.
Management process for the development process
is fully covered, but RUP does not have the [5] SOFTWARE ENGINEERING INSTITUTE - SEI.
broader management meaning of the Standard. Capability Maturity Model – Integrated –
The Human Resources process is almost all Systems/Software Engineering – CMMI-
covered but only at project level, not at SE/SW/IPPD/SS – Version 1.1, Continuous
organizational level (the knowledge management Representation, Volume I e II. Pittsburgh, PA:SEI,
activity is not covered by RUP). The Carnegie Mellon University, 2002.
Improvement and the Domain processes are also
partially addressed.
As can be noticed in this partially covered
cases, RUP does not have a direct mapping to the
Standard activities, what not necessarily means
that RUP does not address those issues. RUP has
a lot of concepts, guidelines and checklists that
help one to address them.