Traa, J.W.A. - RUP vs. MSF - A Comparative Study

RATIONAL UNIFIED PROCESS
VS.
MICROSOFT SOLUTIONS FRAMEWORK:
A COMPARATIVE STUDY
By
Johan W.A. Traa

Erasmus University Rotterdam
The Netherlands
This master thesis is written by Johan W.A. Traa to graduate at the Erasmus University
Rotterdam for his master of Informatics & Economics.
Master Thesis
By
Johan W.A. Traa
254014jt
Final Version
Supervisors
Erasmus University Rotterdam
Flavius Frăsincar
LogicaCMG
Eric van der Laan
Also thanks to:
Dik Harbrecht – Interviewee LogicaCMG

Wouter Kers – Mentor LogicaCMG
Randy Miller – Founder of MSF
Mark Mooy – Competence Manager
Marco Pas – Architect LogicaCMG
Carlo Poli – Interviewee LogicaCMG
Eddy de Ridder – Department Manager LogicaCMG
Edward van Steenderen – TFS maintainer LogicaCMG
Jeroen Unger – Interviewee Microsoft
Ilske Verburg – Interviewee and reviewer LogicaCMG
2
3
ABSTRACT
For this thesis, which I write for the study Informatics & Economics at the Erasmus
University Rotterdam, The Netherlands, I am a trainee at LogicaCMG Rotterdam.
There are numerous ways for a software development organisation to create an

information technology solution for the customer. All go through a multistep procedure
from analysis of the system requirements through design, implementation and
completion. An organisation can just start building the solution without stable
fundament, or use their own well thought-out step-by-step procedure, but the most
proper way is to use a well-known successful software engineering process. A software
engineering process is a roadmap for a clear and safe journey to the IT-salvation of the
customer. It helps project teams address the most common causes of technology project
failure in order to improve success rate, solutions quality, business impact and create a
meaningful business solutions which meets the needs of the customer. An organisation
has the evaluate their conditions of guidance, because there are a lot of software
engineering process created in time, each with its own mindset, steps and structure.
This thesis makes a comparative study of two software engineering processes, namely
the commonly used IBM Rational Unified Process and the new Microsoft Solutions
Framework for Agile Software Development. Both software engineering processes have
the same objective, to create a solution that meets the needs and expectations of the
stakeholders. However, they have different approaches to reach their goal. The Rational
Unified Process focuses on the time schedules and budget to create a predictable and
disciplined software development environment. Microsoft Solutions Framework for
Agile Software Development does not believe in predictability, it considers the fact that
changes are inevitable and do occur during the software development life cycle.
Therefore, this software engineering process focuses on the ability to cope with changes
to create an adaptive and responsive environment. This dissertation compares the two
processes in three different points of view, namely their philosophy, focus in time and
work division, to discover their common grounds and differences. It makes also a
proposal on how to choose one of the two software engineering processes for a project
depending on the project characteristics.
Summarizing, the goal of this thesis is to explain the IBM Rational Unified Process and
the Microsoft Solution Framework for Agile Software Development, to identify the
common grounds and differences between the two software engineering processes, to
recognize the most suitable process for a project based on its characteristics.
4
CONTENTS
ABSTRACT ........................................................................................................................ 4
CONTENTS ........................................................................................................................ 5
GLOSSARY ........................................................................................................................ 7
ACRONYMS ..................................................................................................................... 11
CHAPTER 1 INTRODUCTION ...................................................................................... 12

1.1 Motivation ...................................................................................................... 13
1.2 Research Questions and Approaches.............................................................. 14
1.3 Scope .............................................................................................................. 15
1.4 Methodology................................................................................................... 16
1.5 Outline of the Dissertation.............................................................................. 16
CHAPTER 2 SOFTWARE ENGINEERING PROCESS ..................................................... 17

2.1 Introduction .................................................................................................... 17
2.2 The Sequential Process................................................................................... 19
2.3 The Iterative Process ...................................................................................... 21
2.4 The Agile Process........................................................................................... 22
CHAPTER 3 RATIONAL UNIFIED PROCESS ................................................................ 23

3.1 Introduction .................................................................................................... 23
3.2 Ten Essentials ................................................................................................. 24
3.3 Best Practices.................................................................................................. 27
3.4 Process Overview ........................................................................................... 30
3.4.1 The Phases.............................................................................................. 30
3.4.2 Workflow................................................................................................. 33
3.4.3 Disciplines .............................................................................................. 35
CHAPTER 4 MICROSOFT SOLUTIONS FRAMEWORK ................................................. 39

4.1 Introduction .................................................................................................... 39
5
Content
4.2 Foundational Principles .................................................................................. 41

4.3 Team Model.................................................................................................... 43
4.4 MSF for Agile Software Development........................................................... 45
4.4.1 Process Overview ................................................................................... 47
4.4.2 Tracks ..................................................................................................... 49
4.4.3 Advocacy Groups.................................................................................... 51
4.4.4 Cycles ..................................................................................................... 53
CHAPTER 5 RUP VERSUS MSF4ASD ....................................................................... 59

5.1 Introduction .................................................................................................... 59
5.2 Philosophy ...................................................................................................... 60
5.3 Focus in Time ................................................................................................. 71
5.4 Work Division ................................................................................................ 77
5.5 Conclusion ...................................................................................................... 81
CHAPTER 6 MICROSOFT VISUAL STUDIO 2005 TEAM SYSTEM ............................... 83

6.1 Introduction .................................................................................................... 83
6.2 Visual Studio 2005 Team System .................................................................. 84
6.2.1 Visual Studio 2005 Team System for Architects..................................... 86
6.2.2 Visual Studio 2005 Team System for Developers................................... 90
6.2.3 Visual Studio 2005 Team System for Testers.......................................... 94
6.2.4 Visual Studio 2005 Team Foundation Server....................................... 102
6.3 Best Principles .............................................................................................. 113
6.4 Conclusion .................................................................................................... 117
CHAPTER 7 CONCLUDING REMARKS ...................................................................... 119

7.1 Conclusions .................................................................................................. 119
7.2 Recommendations ........................................................................................ 123
REFERENCE .................................................................................................................. 124
APPENDIX ..................................................................................................................... 127

A The graphical representation of MSF4ASD ..................................................... 127
B The Process element of RUP ............................................................................ 133
C The Process elements of MSF4ASD ................................................................ 138
6
GLOSSARY
Agile software development
An adaptive change-oriented software development. Agile software development
assumes project change in its requirements, features and schedules.
Activity
An activity is a piece of work that an individual in his role performs, which produces a
meaningful result, called an artifact, in the context of the project.
Architecture
See software architecture.
Architectural view
A simplified description of a system from a particular point of view, covering only the
relevant aspects of this perspective.
Artifact
A piece of information that is produced, modified, or used by a process of the project
while working towards the final product.
Build
The compilation of all the files, libraries, or components into a new set of executables,
libraries, or components.
Checkpoint
A moment in the Microsoft Solutions Framework to check the status of the software
development project to control the project team is still on the right track to deliver a
solution that meets the needs and expectation of the stakeholders.
Component
A clearly defined separable, replaceable and reusable building block of computer
software system.
Component based architecture

An architecture based on independent, replaceable and modular components to reduce
complexity of the system and encourage the reuse of existing components.
7
Glossary
Development process
The process of developing computer software or system. This process can be supported
by using a software engineering process as guidance.
Discipline
A collection of activities that are all related to a major ‘area of concern’.
Framework
A flexible and scalable outline for software development projects that can be adapted to
meet the needs of the stakeholder, within a specific domain.
Increment
The difference between two software releases at the end of an iteration.
Integrated development environment

A computer program to help software programmers develop software.
Iteration
One cycle of a set of instructions to be repeated in the process until a specific result is
achieved.
Iteration assessment
An assessment, which concludes an iteration, to evaluate what goals are achieved or not
and why, and what lessons can be drawn from this iteration.
Iterative software development

A software development method using iterations. The iterations are to be repeated in the
development process until a specific result is achieved.
Method
A controlled and systematic way to accomplish a task or attain a goal.
Microsoft Solutions Framework

A framework, created by Microsoft, which provides guidelines for the stakeholders to
develop information technology solutions.
Milestone
A beforehand fixed point in a process at what a goal or task is achieved.
Model
A model is a simplification of the reality that helps us master a large, complex system
that cannot be comprehended in its entirety.
Programming language
A standardized language to program computer software. Examples of languages are C#
(CSharp), C++ and Java.
8
Glossary
Project development tool

A tool that supports the project aspects of the software development, like version
control, issue tracking and requirements control.
Rational Unified Process

A software engineering process, created by Rational, which provides a guideline for the
stakeholders to develop information technology solutions.
Refactoring
A disciplined technique to alter the structure of an existing code base to improve its
design quality while not changing any of its functional characteristics [9].
Release
A stable, executable version of the software and the accompanied peripherals necessary
to use this release.
Requirement
A condition or capability that a system must require [13].
Role
A role defines the behaviour and responsibilities of a resource, individual or a group of
individuals working together as a team to produce coherent artifacts.
Software architecture
A blueprint, a coherent set of abstract patterns guiding the structure and behaviour of
the system, in terms of the usage, functionality, performance, resilience, reuse,
comprehensibility, economic and technologic constraints and trade-offs [16].
Software development method

A structured organization of tasks, estimates, and guidelines that provide a systematic
approach or discipline to act out the software engineering process. Examples are Scrum,
Extreme programming, Feature Driven Development.
Software development plan

The software development plan is a comprehensive, composite artifact that gathers all
information required to manage the project. It encloses a number of artifacts developed
during the Inception phase and is maintained throughout the project.
Software development platform

A platform that combines the integrated development environment and project
development tools.
Software engineering process

A process describes who is doing what, how and when. A process that provides
guidance as to the order of a team's activities, to specify which artifacts should be
developed and when they should be developed, and directs the tasks of individual
developers and the team as a whole, and offers criteria for monitoring and measuring
the project's products and activities.
9
Glossary
Software platform
A set of agreements and prescribed standards for developing on the software
development platform to guide standardized development for computer software. For
example dotNet or J2EE.
Stakeholder
A person or representative who has a vested interest in the outcome of a project or
whose opinion must be accommodated. A stakeholder can be an end user, a purchaser, a
contractor, a developer, or a project manager.
Track
A phase in time of a project that is directed with Microsoft Solution Framework for
Agile Software Development.
Unified Modeling Language

A defined graphical language for visualizing, specifying, constructing, and documenting
the artifacts of a system into a model. The models are a blueprint of the system with
different views for different stakeholders.
Work item
An actionable unit of information that is produced, modified, or used by the MSF4ASD
process of the project while working towards the final product.
Work stream
A group of activities that are all related to a major ‘area of concern’ of the MSF4ASD.
10
ACRONYMS
ASD Agile Software Development
CMMI Capability Maturity Model® Integration
DSL Domain Specific Language
IDE Integrated Development Environment
IT Information Technology
MOF Microsoft Operations Framework
MSF Microsoft Solutions Framework
MSF4ASD Microsoft Solutions Framework for Agile Software

Development
MSF4CMMI MSF for Capability Maturity Model® Integration Process

Improvement
QSR Quality of Service Requirement
RUP Rational Unified Process
SDLC Software Development Life Cycle
SDP Software Development Platform
SEP Software Engineering Process
TFS Visual Studio 2005 Team Foundation Server
UML Unified Modeling Language
VSTS Microsoft Visual Studio 2005 Team System
11
Chapter 1
INTRODUCTION
According to the Standish Group in Chaos Report 2001 [32], system development
projects become more successful. Where in 1994 only 16% of application development
projects met the criteria for success, in 2000 this percentage is increase to 28%. They
say that in the year 2005 the success rate has increased again. The Chaos study of the
Standish Group shows that the time- and cost-overshooting of IT-project have decreased
from respectively 222% over the original time estimates in 1994 down to 63% and from
189% over the original cost estimates in 1994 down to 45% in the 2000 study. The
reasons for the increase in successful projects vary from lower average cost of a project,
improvement of software development platforms to monitor and control the processes,
and better trained project managers with better software engineering processes [32]. The
history perspective of success rate of IT-projects is shown in Figure 1-1.
However, do not be fooled with this increase of successful information technology

projects. In the year 2000 only 28% of all projects are completed on time and within
budget, with all features and functions originally specified. No less than 49% of the
projects are labelled as challenged, meaning that these projects are respectively
completed and operational, but over-budget, over the time estimate and with fewer
features than initially specified. The other 23% are known as failed, because the project
is cancelled before completion or never implemented. Also nowadays, most of the
projects have been overly estimated, the majority of these successful projects where
already 150% over budget before they even started. These facts indicate that software
development still has to improve [32].
12
Chapter 1 | Introduction
Figure 1-1 The resolution of the 30,000 applications projects in large, medium, and small cross-
industry U.S. companies tested by The Standish Group since 1994 [32].
As shown in Figure 1-1, still a big percent of the projects fail or are late and/or over
budget. The most important reasons of most of these failures are not the lack of fund or
technology, but the shortcoming of project management knowledge and executive
support. Without a well-defined software engineering process with a solid business
vision, projects can become an uncontrollable and reckless train [32].
There are intern and extern factors that stipulate the outcome of the IT-project. Extern
factors are uncontrollable aspects of an IT-project like the customer’s business
competition environment and government legislation. The intern factors can be
controlled by the customer and project team to positively influence the outcome of a
development process, factors like customer’s business processes, software engineering
processes and software development platforms. The Chaos Report shows the rise of the
software development, but the Promised Land is still a far away. It is wise to keep
researching in the field of software development. Therefore, this thesis addresses new
relevant research on software engineering processes and software development
platforms of an IT-project.
1.1 MOTIVATION
A software engineering process is a process that provides a disciplined approach of
assigning tasks and responsibilities for the stakeholders within a development
organisation. Stakeholders include for example the customer, project manager, architect
manager, developers and testers. Its goal is to ensure the development of high-quality
software that meets the needs of its customer and end-user, within bounded time
schedule and budget [14], [16]. The software engineering process refers to a
standardized, documented methodology like Waterfall processes [30], Rational Unified
Process [17] and Agile Software Development [10].
13
IBM has a software development platform, called IBM Rational, to support their
software engineering process. This group of tools enables system development teams to
define, configure, tailor, document and practice the Rational Unified Process for
developing a system [13]. Microsoft released a new software development platform at
the end of 2005. This new platform, called Visual Studio 2005 Team System, is a team-
oriented version of the Visual Studio integrated development environment (IDE) [8].
For the first time, this new version of the Microsoft IDE offers full support to the
software engineering process in comparison to older versions of the IDE. Microsoft
claims that it is expanded with software tools for, among other things, system analysis,
system design, version management and configuration management. Microsoft presents
the Agile Software Development as a new software engineering process, and claims that
Microsoft Visual Studio 2005 Team System fully supports this software engineering
process [22].
LogicaCMG mainly uses the Rational Unified Process (RUP) as software engineering
process for their ICT projects [17] and it utilizes the IBM Rational software
development platform to support this process. The projects that are based on the
Microsoft dotNet software development standard use the Microsoft Visual Studio IDE.
LogicaCMG wants to make a conversion from Microsoft Visual Studio 2003 to
Microsoft Visual Studio 2005 and possibly a shift from Rational Unified Process to
Microsoft Solutions Framework for Agile Software Development for some project. This
thesis must give LogicaCMG more insight about the MSF4ASD and Visual Studio 2005
Team System when shifting to the new software development platform and the agile
flavour of Microsoft Solutions Framework as described in the following research
problem.
Research problem
What are the common grounds and differences regarding the IBM Rational Unified
Process and the Microsoft Solutions Framework for Agile Software Development and
how are these supported by Microsoft Visual Studio 2005 Team System.
1.2 RESEARCH QUESTIONS AND APPROACHES

This dissertation solves the research problem, mentioned earlier, by answering several
questions:
Question 1 : What are the IBM Rational Unified Process and the Microsoft
Solutions Framework for Agile Software Development?
To understand the comparison of the IBM Rational Unified Process and Microsoft
Solutions Framework for Agile Software Development, one first has to understand what
a software engineering process is. This introduction explains generally relevant
characteristics of software engineering processes. Knowing this, the thesis describes the
principles, range of ideas, and the process procedures of the IBM Rational Unified
Process and the Microsoft Solutions Framework for Agile Software Development.
14
Question 2 : What are the common grounds and differences regarding the IBM
Rational Unified Process and the Microsoft Solutions Framework for Agile
Software Development?
The two SEPs, the IBM Rational Unified Process and the Microsoft Solutions
Framework for Agile Software Development, are compared in three different views.
Firstly, this thesis compares the two on their philosophy by evaluating the RUP’s best
practices and the MSF4ASD’s principles. Secondly, this thesis compares the two on
their time segmentation by evaluating the RUP’s phases and MSF4ASD’s tracks.
Thirdly, this thesis compares the two on their workload classification by evaluating the
RUP’s disciplines and MSF4ASD’s advocacy groups.
Question 3 When is the IBM Rational Unified Process or the Microsoft Solutions
Framework for Agile Software Development more appropriate to use?
The answer of Question 2 shows the common grounds and differences between the two
software engineering processes, and therefore this thesis is able to give a general advice
in which project situation the IBM Rational Unified Process or the Microsoft Solutions
Framework for Agile Software Development is more appropriate to use as guidance
during the development of the solution.
Question 4 : How are these common grounds and differences supported by

Microsoft Visual Studio 2005 Team System?
Finally, this thesis assays the identified common grounds and differences to the
Microsoft Visual Studio 2005 Team System to show how the Microsoft’s software
development platform supports the software engineering process.
This thesis explains what RUP and MSF4ASD imply by highlighting the principles,
essentials and procedures of the processes. This description together with the results of
the comparison of the two SEPs and the explanation on how these are utilised in
Microsoft’s VSTS, enables LogicaCMG to see what the impact and consequences are
when using Microsoft Solutions Framework for Agile Software Development as
software engineering process and Microsoft Visual Studio 2005 Team System as
software development platform instead of IBM Rational Unified Process and IBM
Rational Products.
1.3 SCOPE
In order to answer the research questions this thesis compares two software engineering
processes, namely Microsoft Solutions Framework for Agile Software Development and
Rational Unified Process, and researches Microsoft’s new software development
platforms, named Microsoft Visual Studio 2005 Team System. The research focus is on
high-level software engineering processes and software development platform, so for
example the detailed description of the artifacts and work items are out of the scope, to
ensure that this dissertation concerns on various kinds of software development projects.
Note that, the research does not embrace elements that are not part of a software
engineering process, like the costs of licenses, training and the personal preferences.
Also note that, this thesis does not judge which software engineering process and/or
15
software development platform is better, it gives a general suggestion in which project

situation one is more suitable or preferable.
1.4 METHODOLOGY
This dissertation uses literature, interviews, conferences and the Microsoft Visual
Studio 2005 Team System to answer the research questions and to solve the research
problem. The literature is obtained from the Erasmus University Rotterdam’s library,
electronic databases and internet. The interviewees are found in the companies which
are concerned during this research, mainly LogicaCMG, IBM and Microsoft, and they
are authorized to make the decision which software engineering process and software
development platform are used or they have experiences or knowledge in one of these
fields. The results of the literature research eventuate in a strong theoretical base of the
two SEPs and software development platform. The interviews, conferences and our
practice with Microsoft Visual Studio 2005 Team System give an insight of practical
experience in the field of software development.
1.5 OUTLINE OF THE DISSERTATION

The thesis has seven chapters and is divided in two parts, where the first part addresses
the software engineering processes; the second part addresses the software development
platform. Each chapter starts with a summary and introduction, followed by a detailed
description of the topic. Chapter 5 ends with the conclusion of the first part and Chapter
7 describes the overall concluding remarks.
Chapter 2 addresses the background information needed to understand what a software

engineering process generally implies. This chapter includes an introduction of software
engineering process and a description of relevant characteristics of a SEP, which relate
to the research in the next chapters. Chapter 3 and Chapter 4 answer research Question
1. Chapter 3 describes the Rational Unified Process on the basis of its ten essentials,
best practices, and process overview. Chapter 4 illustrates among other things the
Foundational Principles of Microsoft Solutions Framework and the Process Procedure
of Microsoft Solutions Framework for Agile Software Development. Chapter 5 answers
research Question 2 and Question 3. This thesis focuses on the similarities and
differences of the best practices, principles and process disciplines of the reviewed
SEPs. The chapter has an introduction, the comparison of the mindsets and process
procedures of the two SEPs and ends with a conclusion of the first part of the thesis.
The second part of this thesis addresses the software development platform in general
and the Microsoft Visual Studio 2005 Team System. Chapter 6 begins with an
introduction on what a software development platform implies and continues with
answering research Question 4 by examining the features of Microsoft Visual Studio
2005 Team System and describing how the mindsets of the SEP are supported. The last
chapter, Chapter 7 gives a summary of the main research results and indicates some
possible future research directions.
16
Chapter 2
SOFTWARE ENGINEERING
PROCESS
The software paradox ‘Deliver quality software and deliver it quickly’
emphasize the inconsistency of deploying the solution as soon as possible at
the customer’s environment and the stakeholders’ quality expectation of the
solution. A software development team can choose from a lot of software
engineering process to guide the team members during a software
development project to create a solution that meets the needs and
expectations of the stakeholders. This thesis divides software engineering
process into three types of processes, where each has a different philosophy,
time segmentation and workload classification.
First, the sequential process goes through the procedure of software
development as if the team is building a house, creating the solution step by
step as it is written in the blue print. This process leaves no room for changes
after the identification of the requirements to provide all the stakeholders
with a predictive project in time and costs [31].
Second, the iterative process divides the project into segment, to enable the
project team to cope with changes during the software development life cycle.
This ability causes the overall process to be less predictable to schedule time
and costs of the software development project [13].
Third, the agile process is built on the foundation of iterative software
development, but more strongly emphasize the ability to be adaptive. The
team develops the solution ad hoc through a close relationship with the
customer. Stakeholders have the opportunity to change their needs and
expectations during the whole software development life cycle [10].
2.1 INTRODUCTION
A software engineering process helps project teams address the most common causes of
technology project failure in order to improve success rate, solutions quality, business
impact and create a meaningful business solutions which meets the needs of the
customer. The process of developing systems goes through a multistep process from
analysis of the system requirements through design, implementation and completion.
This chapter gives a general impression of what a software engineering process implies
and addresses some characteristics of the process that are relevant for answering the
research questions.
17
Chapter 2 | Software Engineering Process
Although there are many software engineering processes, according to Sommerville

[31] the general software engineering process includes the following activities presented
from an architectural perspective. This means that the activities are described at a high
level project point of view.
1. Software specification. To define the functionality of the software and

constraints on its operation.
2. Software design and implementation. To plan and build the software inline with
the specification.
3. Software validation. To validate the software to ensure that it meets the

expectations of the customer.
4. Software evolution. To meet changing customer needs, the software must

evolve.
There is no ‘ideal’ process for developing a system for several reasons [22]. Different
technologies require different method of approach, every individual in the project team
is unique with his own preferences and knowledge and therefore every project team is
unique. Other reason is that the external needs vary, because the customer or his
business legislation has a preference of one SEP. Also projects itself have different
facets, like team size, fixed or variable price and non- or business critical. Every SEP
has its strengths and weaknesses that should be taken in consideration to get an
appropriate process [3].
Some examples of software engineering processes are a listed below:

Dynamic System Development Method (DSDM)
Extreme Programming (XP)
Feature Driven Development (FDD)
Microsoft Solutions Framework for Agile Software Development (MSF4ASD)
Rational Unified Process (RUP)
Spiral Model (SM)
Waterfall Model (WM)
Some processes aim for a predictive others aim for an adaptive way of software
development. Extreme predictive processes aim to control the process by planning and
establishing the requirements a priori to create a solid and predictable lifecycle. An
example of a predictive process is the Waterfall model. To create a predictable process,
one has to formulate as much aspects early in the lifecycle and freeze them in order to
baseline an unchangeable project planning. This sounds great, but it disables
stakeholders to change their needs and expectations for the future system after analyse
and design. On the other hand extreme adaptive processes are open-minded towards
changing the project’s constraints. An example of an adaptable process is eXtreme
Programming. They aim to manage and control the outcome of the project by allowing
the customer and other stakeholders to changes their thoughts of the solution. These
processes are harder to plan, but are able to cope with adaptability.
18
Figure 2-1 shows an arrangement of the mentioned software engineering examples by

predictability and adaptability [3], [15].
Figure 2-1 Processes categorized by predictive versus adaptive
An adaptive process is suggested when a project has to cope with uncertainties or

volatile requirements, the team has controllable, motivated en responsible members and
the customer is willing to get involved. When a project team is has a big scope and is
hard to control, has a fixed price and requirements, it is better to use a more predictive
process.
Scott W. Ambler classifies the software engineering processes in four categories,

namely code and fix, sequential, iterative, and agile processes [3]. This thesis uses this
categorization to explain the different insights of software engineering processes. The
software development approach in the first category is also known as ‘hacking’, ‘hack
and slash’, ‘immature development’ or ‘no-process at all’. These SEPs are branded to be
chaotic and often unplanned, and are usually used to develop throw-away prototypes. It
is said to be an ineffective approach to development by writing the application code
without putting much consideration into the solution. The code and fix category is not
further discussed in this thesis. The remaining categories are described in the next
paragraphs.
2.2 THE SEQUENTIAL PROCESS

Sequence development is a logic way to handle a development process. The project
team goes through the procedure of software development as if they build a house. First
they state the system’s requirements as building fundament, and then build the system
step by step on this basis. After each step is finished, the project team proceeds to the
next step in the process and does not look or go back.
19
The best-known sequential software engineering process is the waterfall model.

According to Kruchten in his book ‘The Rational Unified Process - An introduction’, a
sequence progress can be illustrated as shown in Figure 2-2.
Figure 2-2 The sequence process
Requirements analysis
Completely understand and identify the demands and constrains of the problem.
Design
Design a solution to satisfy the needs of all stakeholders.
Implementation
Implement the solution by writing the code and test the product.
Integration
Deliver and integrate the software product in the customer environment.
Sequential processes do not allow reversing to previous steps and correcting errors in
previous steps, so the rest of the SEP may be executed to the end with misconceived
assumptions, resulting in a system that does not meet the needs and expectations of the
customer. The project results in an unusable solution, because the team keeps on
building on a poorly constructed fundament. This is a conventional development
process and is nowadays not preferable to use for the reasons as described below.
Nowadays it is naïve to think that one can identify all requirements in the early phase of
the process and freeze them during the rest of the software engineering process. A
system can be too complex for humans to understand as a whole. We do not have the
ability to comprehend an overall detailed and precise view of the system’s possibilities
and desired capabilities. Therefore, it is necessary to reformulate the framed
requirements into more detail. More, due to progressive understanding, customers and
users of the future system will change their needs and expectations throughout the
process. They see other similar systems, get new insights of their business problem, and
are getting more familiar with the possibilities of the used technology when they see it
is transformed into an IT-solution. It is said that users do not really know what kind of
20
solution they want in advance, but they know what kind of solution they do not want
afterwards. One of the interviewees expressed this as followed, “Two weeks after the
system deployment, the customer knows what he really wants.”. Also, new technical
insights, new technologies or fluctuating businesses makes the system requirements
more uncertain. Another disadvantage of sequential processes is that the customer does
not see the tangible system until the end of the SEP when it is completely implemented,
resulting in a negative influence on the customer involvement and enthusiasm.
Summarizing, the most important reason not to use sequential oriented processes are as
followed. You have just one shot to analyse, design, develop, test and integrate the
system. If the project introduces new insights, techniques, tools or new people, the
sequence process gives you no latitude for learning and improvement.
2.3 THE ITERATIVE PROCESS

The previous paragraph introduced the classic software engineering process thoughts,
where the primary problem of this approach is that it pushes risk forward in time. An
alternative to the sequential process is the iterative process. This process is based on the
spiral model of Barry Boehm [7], where risks are identified in the beginning of the
process to be able to react as soon as possible as depicted in Figure 2-3. Iterative
approaches use risk, time and budget to plan and control the process of developing
software.
Figure 2-3 Risk reduction
There are various benefits of the iterative approach for software development. This
approach uncovers and fixes issues and risks early by receiving periodic user feedback.
The periodic feedback and testing provide the project team the ability to check the
project’s status and creates the stakeholders to be more involved by receiving concrete
21
sight of their solutions throughout the lifecycle of the project. Additional benefits are
that the team can progressively improve the process itself by applying the lessons
learned during the lifecycle, and the project workload is spread more evenly throughout
the project’s lifecycle. These benefits keep the project team focussed on the real needs
of the customer and end-user. Examples of iterative processes are Spiral Model1, Object
Oriented Software Process2, and Rational Unified Process. More details aspects of
iterative software development are described further on this dissertation.
2.4 THE AGILE PROCESS

Agile software engineering processes are built on the foundation of iterative
development. The agile process is a lightweight and people-oriented variant of an
iterative software engineering process. An agile process uses the stakeholders’ needs
and expectations rather than time and budget planning as primary process control
mechanism.
The ideology of the agile processes is described in the ‘Manifesto for Agile Software
Development’ [1]. It says that individuals and interactions are preferred over processes
and tools, working software over comprehensive documentation, customer collaboration
over contract negotiation, and responding to change over following a plan. Scrum3,
Feature Driven Development4, eXtreme Programming5, and Microsoft Solutions
Framework for Agile Software Development are examples of software engineering
processes that embraces the agile principles. More details aspects of agile software
development are described further on this dissertation.
Figure 2-4 Process types categorized by predictive versus adaptive
Summarizing, the sequential process is a predictable and planned SEP that freezes the
requirements and walks through the process step-by-step without looking back, where
there is no room for change requests. The iterative process plans, controls and measures
on time and budget to become as predictable as possible, but uses iterations to cope with
changes during the software development, where the stakeholders give the project team
feedback and requests for changes on a period base. The agile processes are less based
on time and budget planning, they prefer to control and measure the project on quality.
These lightweight processes do not focus on predictability but on adaptability instead.
Stakeholders have the opportunity to change their needs and expectations whenever
they want.
1
For more information see http://en.wikipedia.org/wiki/Spiral_model visited February 2006.
2
For more information see http://www.ambysoft.com/books/processPatterns.html visited February 2006.
3
For more information see http://www.controlchaos.com visited February 2006.
4
For more information see http://www.featuredrivendevelopment.com visited February 2006.
5
For more information see http://www.xprogramming.com visited February 2006.
22
Chapter 3
RATIONAL UNIFIED PROCESS
The IBM Rational Unified process is an iterative software engineering
process, which ensures the production of quality software that meets the
needs of its end-users, within a predictable schedule and budget.
RUP consists of ten essentials and six best practices to express the beliefs of
the IBM Rational iterative software development mindset. The process itself
is arranged in phases and iterations, which segments the process in time, and
disciplines, roles, workflows, activities, and artifacts which divides the work
of the process. The RUP is a formal and heavy software engineering process
that focuses on time and budget planning, to be a predictive process, and
uses iterations to cope with changes that are inline with the scope of the
project throughout the software development life cycle [12], [13].
3.1 INTRODUCTION
In 1997 the Three Amigo’s Grady Booch (IBM), James Rumbaugh (General Electric)
and Ivar Jacobson (Ericsson) gathered their knowledge of software engineering process
and created the Unified Process [16], later renamed as Rational Unified Process. The
Rational Unified Process (RUP) is a well known iterative software engineering process
(SEP) created by the Rational Software Corporation, now a division of IBM. It provides
a disciplined approach to assigning tasks and responsibilities within a development
organization [16] and makes the development team more productive by giving them
guidelines, templates and tool mentors for all critical software lifecycle activities [13].
RUP’s goal is to ensure the production of high-quality software that meets the needs of
its end users within a predictable schedule and budget [16].
Over the years, Rational has gained a base of knowledge and experience in the area of
software development. This information is expressed in the Ten Essentials, Best
Practices and the process itself, which are described in detail in the next sections of this
chapter.
23
Chapter 3 | Rational Unified Process
3.2 TEN ESSENTIALS

According to the RUP knowledge base [12], there is minimal set of elements a project
has to embrace not to fail definitely. Missing one of these elements increases the chance
the project ends unsuccessful. The following enumeration describes the essential
principles of an effective software engineering process.
1. Vision – Develop a Vision

2. Plan – Manage to the Plan
3. Risks – Identify and Mitigate Risk
4. Issues – Assign and Track Issues
5. Business Case – Examine the Business Case
6. Architecture – Design a Component Architecture
7. Product – Incrementally Build and Test the Product
8. Evaluation – Regularly Assess Results
9. Change Requests – Manage and Control Changes
10. User Support – Deploy a Usable Product
The essentials provide an introduction to each of the many of its Best Practices,
mentioned in 3.3 and Disciplines of the RUP, mentioned in 3.4.
VISION – DEVELOP A VISION

To end the project successful, you have to develop a product that meets your
stakeholders’ needs [12]. A clear vision helps the project team to identify all the
stakeholders’ needs and makes sure that the team has the same idea about the future
system [28].
RUP gives an extensive description on how to construct the Vision artifact. RUP’s
Vision artifact contains an enumeration of high-level requirements and design
constrains. It gives the reader an understanding of the system to be developed, is created
early in the Inception phase and evolves during the earlier portion of the lifecycle [12].
It also provides input for the project-approval process, and is therefore intimately
related to the Business Case. And finally, because the Vision communicates the
fundamental "why's and what's" of the project, it serves as a resource for validating
future decisions.
Creating the Vision Artifact and identify a set of requirements is the essence of the
Requirements discipline, and the Best Practice: Manage requirements. This beholds
analyzing the problem, understanding stakeholder needs, defining the system, and
managing the requirements as they change [12].
24
PLAN – MANAGE TO THE PLAN

“Let our advance worrying become advance thinking and planning.” -
Winston Churchill
The ‘Plan’ essential emphasizes the creation of a development plan. In RUP, the
Software Development Plan (SDP) is an artifact in the discipline project management
[12]. It aggregates all information required to manage the project and must be
maintained and updated throughout the project because of the changing character of
iterative software development [28]. The SDP is used to estimate the time (including
Project Plan and Iteration Plan), resource and tools needs and to measure the progress of
the project by comparing the estimated to the actual planning.
"Plan - Manage to the Plan" together with essentials Risks – Identify and Mitigate Risks,
Issues – Assign and Track Issues, Business Case – Examine the Business Case,
Evaluation – Regularly Assess Results captures the essence of the project management
discipline in RUP, which involves conceiving the project, evaluating scope and risk,
monitoring and controlling the project, and planning for and evaluating each iteration
and phase [28].
RISKS – IDENTIFY AND MITIGATE RISKS

RUP identifies and attacks the highest risk items early in the project. Every risk that is
identified must be accompanied with a mitigation plan and added in the Risk List, a
sorted list of known and open risks to the project sorted in decreasing order of
importance and associated with specific mitigation or contingency actions. The risks
and mitigation plans are the basis for the project’s activities and iterations, which at
every stage in the lifecycle the item with the highest level of risk is carried out [13].
ISSUES – ASSIGN AND TRACK ISSUES

Register the status of the activities and keep up the progress and improvements of the
product are important in any project. RUP tells this should be done by regular status
evaluation, which provide insight management, technical and project issues. RUP calls
this periodic evaluation Status Assessment, which provides a mechanism for controlling
everyone's expectations throughout the project lifecycle to ensure that the expectations
of all parties are synchronized and consistent. This status check of the project is like a
heartbeat for management attention. The status of the project has to be evaluated at
every beat, therefore the history of the project is captured and the remaining obstacles
can be planned to be removed [12], [28].
BUSINESS CASE – EXAMINE THE BUSINESS CASE

According to the RUP knowledge base, a project has to have a Business Case. The main
purpose of the Business Case is to develop an economic plan for realizing the project
Vision. It provides the economic constrains and the necessary information to determine
whether or not this project is worth investing in. The Business Case describes brief and
simple the arguments of the project’s right to exist and is reviewed and updated at every
25
critical milestone to see if the estimations are still accurate and the project is still worth
investing in [12].
ARCHITECTURE – DESIGN A COMPONENT ARCHITECTURE

RUP encourages the use of components in the architecture of the system. The
architecture of a software system is the organisation of the system’s components
interacting through interfaces. RUP provides a methodical, systematic way to design,
develop and validate a software component architecture, which belongs to the analysis
& design discipline.
RUP describes the architectural representation of the system in the Software

Architecture Document (SAD) in multiple views, where each view shows different set
of concerns and aspects of the system to different stakeholders. The SAD describes the
important aspects in different views to make sure that the team members only see the
information they need and are not overwhelmed with irrelevant information. It enables
team members to speak the same language and communicate effectively about
architecturally significant projects decisions [12], [28].
PRODUCT – INCREMENTALLY BUILD AND TEST THE PRODUCT

By means of iterative development, the product evolves step-by-step during the project
until the final product is created and meets the needs of all stakeholders. Every iteration
leads to an integration of one or more components to the executable product. By
developing the solution incrementally, one is able to test the solution more thoroughly
and efficiently. The testers are able to check a step of the solution for faults, bugs and
errors, while the developers can begin to build the next. RUP prescribes this parallel
testing during the building phase to discover flaws as early as possible. Flaws which are
discovered early are easier and less expensive to fix [12], [28].
EVALUATION – REGULARLY ASSESS RESULTS

For a project team it is important to regularly assess the product to the expectations of
the customer to measure the progress and confirm the project status. Periodic project
status evaluation makes sure that everyone stays on track that is mapped out path to lead
the project to success. These assessments identify the bottleneck and issues of the
software engineering process.
RUP introduces the Iteration Assessment to capture the results of an iteration. It verifies
the degree to which the evaluation criteria were met, determines the lessons learned, and
changes to be done. This object is an essential artifact of iterative development and
focuses not only on the product but also on the process issues [12], [28].
CHANGE REQUESTS – MANAGE AND CONTROL CHANGES

Changes occur during the project. To facilitate the control of the changes, it is essential
that the changes to any development artifact are proposed through Change Requests.
RUP uses Change Requests to document and track requests for a change to the product,
26
to provide the stakeholders a history of decisions, to ensure that the impact of the
potential changes are considered and understood by all the project members. Change
Request is an important aspect of project management and control; it ensures changes to
be well considered and controls the scope of the project. This essential is connected to
the Control changes to software best practice, and the project management,
configuration management disciplines [12].
USER SUPPORT – PROVIDE ASSISTANCE TO THE USER

Developing a product that meets the stakeholders’ needs and install it in the
environment of the customer is not enough to end a project successful. The end users
have to like and understand the system before they are willing to use it. Therefore, the
completion of a project not only includes product delivery, but also a user’s guide, a
brief overview of the product, a listing of what is new in this release, including bug
fixes and new features, notes about installation, upgrading, and product documentation
and a listing of known issues. Training materials and programmes may also be needed,
depending on the complexity of the product. The associated activities form the
Deployment Discipline.
This essential implies that delivering the software to the customer is not enough to end a
project successfully. The project team must provide the customer with documentation
and training to support the users [28].
3.3 BEST PRACTICES

The Rational Unified Process captures many of the best practices in modern software
development in a way that is suitable for a wide range of projects and organizations.
These practices are called ‘best practices’ because RUP identifies them to be commonly
used by successful organizations and solve at the root causes of software development
problems [13]. The six core best practices introduced in The Rational Unified Process -
An Introduction, Second Edition (2000) are as follows:
1. Develop software iteratively.

2. Manage requirements.
3. Use component-based architectures.
4. Visually model software.
5. Continuously verify software quality.
6. Control changes to software.
DEVELOP SOFTWARE ITERATIVELY

Today’s systems have large and complex structures, which make understanding the
whole system and all the requirements in advance almost impossible. Stakeholders, who
are not capable to understand the problem in advance, are not capable to enumerate the
requirements and risks of the solution in advance [13]. Iterative development allows a
project to progress in small controlled steps, called increments [35]. The iterations are
planned in objectives, milestones, definitions of tasks and responsibilities. They are
27
ordered to the level of risk, where at every stage in the lifecycle the iteration with the
highest level of risk is carried out [13].
The Rational Unified Process uses the iterative approach to allow the stakeholders to an
increasing understanding of the problem through refinements and to incrementally grow
an effective solution that meets the user’s expectations over multiple iterations [13].
Each iteration ends with an executable release, which enables frequent end-user
involvement and feedback. Therefore, problems are found in an early stage, reducing
risks of the project [13]. Another advantage of iterative development is that after every
iteration the status of the project is checked, so developers stay focussed and the
stakeholders are ensured that the project stays within agreed boundaries.
The iterative approach of the Rational Unified Process is a controlled process. An

iterative development approach allows an environment which can adapt and change its
requirements, features and schedules.
MANAGE REQUIREMENTS
The requirements for a system are the description of the services provided by the system
and its operational constraints. These requirements are partially written by the customer
and partially written by the development team. They are the desires of the customer,
such as placing an order or reporting a document, and constraints of the developer, e.g.
using a specific kind of database for placing the order.
The Rational Unified Process uses UML (use cases and scenarios) to identify, organize
and document the requirements of a system. The UML models give a simplistic view of
a complex structured system. UML is proven to be successful to guarantee that the
stakeholders do not lose touch with requirements during the development process [11].
USE COMPONENT-BASED ARCHITECTURES

A component is a clearly defined building block of a computer software system. It is an
element of the software that can be separated from the system and communicates
through well-defined interfaces [34].
Component-based architecture makes the system flexible; components are independent

of the system so that they easily can be added or replaced. It provides developers a clear
overview of the whole system and promotes more effective software reuse [34].
The Rational Unified Process supports component-based software development. It

provides a systematic approach to defining an architecture using new and existing
components [13]. Dividing a system also contribute to the RUP aspect to deliver an
executable release of the system at the end of every iteration.
28
VISUALLY MODEL SOFTWARE

A model is a simplification of the reality that helps us master a large, complex system
that cannot be comprehended in its entirety. Rational Software created the worldwide
adopted visual modeling standard, namely Unified Modeling Language [11]. The
Unified Modeling Language (UML) is a graphical language for visualizing, specifying,
constructing, and documenting the artifacts of a software-intensive system [16]. The
models are a blueprint of the system with different views for different stakeholders.
The Rational Unified Process describes how to develop and maintain visual models of
the system to clarify the structure and behaviour of architectures and components. It is a
guide to the effective use of the models like use-case models, business models, design
models, analysis models, and a test model [16].
CONTINUOUSLY VERIFY SOFTWARE QUALITY

The Rational Unified Process focuses on verifying and objectively assessing whether
the product meets the expected level of quality [16]. RUP provides a guideline to review
the quality with respect to the requirements based on reliability, functionality,
application performance and system performance. Quality verification is built into the
process, in all activities, including all stakeholders and is not treated as an afterthought
or a separate activity performed by a separate group [13].
CONTROL CHANGES TO SOFTWARE

During the project changes occur due to progressively understanding of the stakeholders
[16]. A well defined change management is mandatory to control the changes of the
needs and expectations of the stakeholders. The ability to manage change is making
certain that each change is acceptable and traceable. RUP proclaims that everyone is
well informed about the changes, to ensure that everything and everyone is in sync. The
process describes how to control, track and monitor changes to enable successful
iterative development [13].
29
3.4 PROCESS OVERVIEW
Figure 3-1 The Rational Unified Process
The horizontal axis represents time and shows the dynamic aspect of the process as it is
enacted, and it is expressed in terms of cycles, phases, iterations, and milestones [13].
The vertical axis represents the static aspect of the process: how it is described in terms
of activities, artifacts, workers and workflows [13].
3.4.1 THE PHASES

The software lifecycle is the course of life of a software product, which moves through
a multistep process from analysis of the system requirements through design,
implementation, maintenance and new releases. RUP breaks the software lifecycle
down into cycles, each cycle working on a new generation or release of the product.
This cycle is then broken into four sequential phases, namely,
1. Inception phase
2. Elaboration phase
3. Construction phase
4. Transition phase
Each phase consists of one or more iterations, depending on the kind of project. An
iteration is a complete development loop resulting in an executable product release. A
phase is completed with a well-defined milestone, as shown in Figure 3-2, to evaluate
whether the goals have been achieved, all stakeholders are being considered and the
actual expenditures correspond with the planned expenditures.
30
Figure 3-2 The four phases and milestones of a project
A pass through the four phases produces a generation of the software and is called a
development cycle [12]. Note that, the phases in the cycle are not similar in term of time
and effort, the construction phase usually takes the most effort and time.
INCEPTION PHASE
The goal of the inception phase is to achieve concurrence among stakeholders on all the
lifecycle objectives and to ensure that the project is both worth doing and possible to do.
It focuses on understanding the overall requirements and determining the scope of the
development effort [12], [28]. Therefore, it is primarily significant for new development
projects. Projects that enhance existing software have a brief inception phases, because
they are able to use and update the artifacts of the previous projects. During this phase
the scope of the project is formulated, a business case is created, a vision is defined and
the environment is prepared [12].
The Business Case provides the economic constrains and describes the arguments of the
project’s right to exist. Within the success criteria, risks and plans to attack these risks
are formulated, as well as the necessary resources, and major milestones are
documented. At every critical milestone, the Business Case is reviewed and updated to
see if the estimations are still accurate and the project is still worth investing in [16].
The Vision artifact creates a complete and shared view for all stakeholders of all the
desired requirements. It identifies all external entities that interact with the future
software, by creating all use cases of the project. It shows the fundamental "why's and
what's" of the project and can serves as a means for validating future decisions [16],
[28].
The inception phase ends when the criteria of the Lifecycle Objective Milestone are
met. The stakeholders have to understand all requirements, be united in the project
definition and cost/time schedules, and believe in the project intention.
ELABORATION PHASE
The goal of the elaboration phase is to baseline the architecture of the system to provide
a stable basis for the design and implementation activities in the construction phase. The
31
project‘s objectives, scope, architecture, the resolution of the major risks are examined
more thoroughly at a so-called “mile wide and inch deep” view [12].
During this phase the activities and resources that were identified in the inception phase
are planned, iteration plans are defined, the features are specified and a component-
based architectural prototype is produced. This prototype addresses the critical use
cases, identified in the inception phase, and exposes the highest technical risks of the
project. This prototype serves as a foundation to build the product in the next phase.
The activities of this phase have to ensure that the architecture, requirements and plans
are stable enough, that the risks are adequately mitigated, so the cost and time schedules
can be determined. Therefore the Lifecycle Architecture Milestone criteria are met, and
the project can proceed to the next phase of the development cycle [12], [13].
CONSTRUCTION PHASE
The goal of the construction phase is to clarify the remaining requirements and
constrains and to complete the translation from the Vision into a stable product based
upon the component-based architecture created in the previous phases [12], [16]. The
construction phase is most likely the longest phase of the project lifecycle.
The project transforms from developing intellectual property to developing a product,

where emphasize is placed on resource, control and process management to optimize
cost, schedules and quality [12]. In this phase the prototype evolves via iterations into
an operational product that meets the stakeholders’ needs [13].
At the end of the phase, the Initial Operational Capability Milestone determines whether
the product release is stable and mature enough to be handed to the end user [13].
TRANSITION PHASE
The goal of the transition phase is to ensure that the software has been completed to an
acceptable level of quality that meets the criteria of the Vision and therefore can be
hand over to its end users [12], [13].
The cycle has come to the end phase, which includes the activities of manufacturing,
delivering, maintaining the product, training and supporting the users until the project
objectives are met and the project can be placed into the hands of the end-users. The
product is fine tuned by fixing minor feature changes and thoroughly tested in
preparation for an extern release. The users’ environment is adjusted; converting the
operational database, configuring the hardware, parallel operating the product with the
legacy system. And additional, the user receives support documentation and possibly
training [13], [16].
32
When the objectives are achieved and the stakeholders are satisfied, the Product Release
Milestone is accepted. This closes the development lifecycle and another development
cycle can be started [13].
3.4.2 WORKFLOW
A process describes who is doing what, how, and when. The Rational Unified Process
describes these terms using four modeling elements, namely Roles, Activities, Artifacts
and Workflows [13]. The coherence between role, activity and artifact is shown in
Figure 3-3.
Figure 3-3 Role, Activity, Artifact [12]
Philippe Kruchten defines the role, activity and artifact in his book Rational Unified
Process, An introduction as follow.
A role, formerly known as workers, defines the behaviour and responsibilities of a

resource, individual or a group of individuals working together as a team to produce
coherent artifacts. A role is like a hat that an individual person can wear during the
project. There are some standard roles like system analyst, designer and test designer.
The system analyst conducts the requirements and use-case modeling by defining the
system’s functionality and scope. The designer is in charge of the system design in
terms of responsibilities, operations, attributes, and relationships of one or more classes.
The test designer is responsible for the scheduling, designing, executing and evaluating
system’s tests. Note that one person can play one or more roles during the project.
The behaviour of a role is expressed in activities. An activity is a piece of work that an

individual in his role performs, as illustrated in Figure 3-4, which produces a
meaningful result, called an artifact, in the context of the project. The activities have a
length of time of a few hours till a few days and some are repeatable to update and
refine a cohered artifact. The following are examples of activities: Plan an iteration –
performed by the role: Project Manager; Review the design – performed by the role:
Design Reviewer.
33
Figure 3-4 People, Roles and Activity
The responsibilities of a role are expressed in artifacts. An artifact is a piece of

information that is produced, modified, or used by a process. Artifacts are input and
output of the activities; the things the project produces or uses while working on the
product. Examples of artifacts are Use-Case Model, Business Case, Software
Architecture Document or the Source Code itself [13]. The roles that perform activities
produce a flow of artifacts, called a workflow.
A workflow is a sequence of activities that produces a result of observable value. A

workflow can be expressed in a model using for example UML. Figure 3-5 shows an
example of workflows’ dependencies in an activity diagram.
Figure 3-5 Example of workflow
RUP organizes the set of activities in workflows in different ways, namely Disciplines
and Workflow details. In the next section the thesis discusses the core disciplines of the
Rational Unified Process.
34
3.4.3 DISCIPLINES
RUP identifies nine disciplines that each describes a set of associated activities and
artifacts based upon a set of skills that are common in a general ICT project. These
disciplines are a way to arrange the activities and artifacts and are mainly used to
understand the project form a waterfall perspective [29]. A discipline's workflow is, like
other workflows, a semi-ordered sequence of activities which are performed to achieve
a particular result. RUP divides the disciplines into six engineering disciplines and three
supporting disciplines as shown in Figure 3-6.
Figure 3-6 The Rational Unified Process [12]
RUP knowledgebase describes each discipline in an Introduction, Concept, Workflow,

Activity Overview, Artifact Overview and Guidelines Overview. The introduction
illustrates the idea of the discipline and relationships to other disciplines; the concepts
illustrate the important key elements of the disciplines. Figure 3-7 shows the disciplines
in a RUP iteration where in each iteration the artifacts are evolved [29].
Figure 3-7 A RUP iteration [12]
35
BUSINESS MODELING
The purpose of this discipline is to understand the structure, business processes, the
problems, and to identify potential improvements of the demanding organization. The
processes, roles and responsibilities are defined in a model of the business based on the
Vision artifact. The business models show the structure and dynamics to ensure that all
stakeholders have the same understanding of the demanding organization [16], [29].
REQUIREMENTS
The activities in the requirements discipline establishes and maintains agreement with
the customers and other stakeholders on the system capabilities, user-interface, user
needs. It provides the project team a better understanding of the system requirements
and boundaries. The artifacts in this discipline are a basis for planning the technical
content of iterations and estimating cost and time to develop the system. The
requirements discipline describes how to create the Vision artifact and how to interpret
it into a use-case model. The use-case model and the supplementary specifications
define the detailed software requirements of the system [16], [29].
ANALYSIS & DESIGN

The analysis & design discipline translate the requirements into a detailed description to
implement the future system. To be able to make this translation, you have to
understand the system’s requirements and transform them into a system design by
identifying the best implementation strategy. A mandatory robust architecture is the
fundament for the Design Model artifact in the analysis and design discipline.
The analysis part translates the system’s functional requirements to a set of classes and
subsystems based on the use-cases. This Analysis Model is a rough sketch of the system
and has to be refined and evolve to be able to implement the system-to-be. In the design
part of the discipline the Analysis Model is expanded with the constraints imposed by
the non-functional requirements, the implementation environment, etc, into the Design
Model. The Design Model consists of a set of collaborations of model elements e.g. use-
cases that describe the behaviour of the system. The Design Model is the refinement of
the Analyse Model and is the primary artifact of the analysis & design discipline. The
design model is the essential input artifact for the activities in the implementation and
test disciplines. The Analyse & Design discipline links the requirements and the actual
implementation of the solution by creating a Design Model artifact [12], [16], [29].
IMPLEMENTATION
The activities of the implementation discipline imply the definition of a mutual
arrangement of subsystems organized in layers to implement the classes and objects in
components. The finished components are unit-tested and improved until they have an
acceptable level of quality to be integration into an executable system. The iterations of
the RUP enable the integration of components in an evolutionary approach throughout
the system’s lifecycle [12], [16].
36
TEST
The previous discipline has unit-tested the individual components and has integrated
them into the system. This discipline examines the system as a whole to assess the
product quality. It provides the project with a feedback mechanism to measure quality
and identify defects. Testing occurs in all phases of the RUP to enable continuously
feedback to improve the product as it is designed and built. The test includes verifying
the completeness and correctness of the implemented requirements, the integration and
interaction of components in the system, and conforming that all defects are addressed
before the system is deployed. Note that, the quality of the system is not obtained by
quality-assurance or tests. RUP uses the test discipline to provide periodic feedback on
quality measures of the product to the team members to enable them to improve the
quality of the solution [16], [29].
DEPLOYMENT
The deployment discipline embraces all the artifacts that are delivered to the end-users
or customers. It includes activities like beta testing, which implies testing the software
in the customer’s operational environment, the creation of a deployable package of the
solution, distribute and install it, and if necessary migrate the product with the existing
software or convert the legacy database. Additional, this discipline prescribes the
project team to write a users’ manual and train them on how to use the software [16].
CONFIGURATION & CHANGE MANAGEMENT

The purpose of the configuration & change management discipline is to track and
maintain the integrity of evolving project assets. During the software development life
cycle many labour-intensive artifacts are produces, which must be traceable and
available for reuse. Due to progressive understanding and change requests artifact must
be updated regularly. These different versions of artifacts must be controlled to keep
track of its location and history; what was the reason and who was responsible for
changing the artifact. Therefore the ability to trace and control the project artifacts is
important for the project team to understand the current state of the artifacts and the
whole solution. The discipline creates a configuration and change management
environment that keeps track of these project assets [12], [16].
PROJECT MANAGEMENT
A healthy software project has a balance of contradictive objectives, managing risks and
defeating constraints to deliver a product that meets the needs of the customers and the
end-users. Project manager plans the software development life cycle in two ways. One,
he generally plans the process as a whole in iterations to monitor the progress of an
iterative project. Two, he plans the next iteration with a risk-driver approach in detail.
This balance is created by the project management discipline by providing the project
with a framework for managing software-intensive projects and risk management,
practical guidelines for planning, staffing, executing, and monitoring projects [12], [16].
37
ENVIRONMENT
The purpose of this discipline is to support the project organization with both processes
and tools. It establishes an environment where the right tools, acquisition and process
are available and well configured to suite the organization. It is also responsible for the
technical services to support the process, like the IT-infrastructure, account
administration and regularly backup. In other words, the activities in the environment
discipline provide the project environment with the correct tools, processes, and
methods [12], [16].
38
Chapter 5 | RUP versus MSF4ASD
Chapter 4
MICROSOFT SOLUTIONS
FRAMEWORK
The Microsoft Solutions Framework for Agile Software Development is one
of the two software engineering processes of the Microsoft Solutions
Framework. This process is a very adaptive process that guides the software
development team during the implementation of an IT-solution with an ad
hoc planning and development mindset.
MSF4ASD consists of foundation principles and a team model to grow an
agile mindset within the project development team. The process itself is
arranged in tracks and cycles to segment the process in time, and advocacy
groups, roles, work streams and work items to divide the process suitable
small work tasks. The MSF4ASD is an informal, ad hoc, and responsive
software engineering process that focuses less on time and budget planning,
but more on a perfect end result and coping with changes [1], [10], [24].
4.1 INTRODUCTION
The Microsoft Solutions Framework was developed in 1993 and for the first time used
in 1994. It has aggregated guidance from well-known industry best practices for more
then decennia. MSF is relatively unknown by software developers, but this changes with
the introduction of Microsoft Solutions Framework version 4.0 in November 2005, by
the fusion of MSF and the latest version of the Microsoft’s software development
platform, named Microsoft Visual Studio 2005 Team System [18], [25].
Microsoft Solutions Framework (MSF) is a set of software engineering processes,

principles, and proven practices that enable developers to achieve success in the
software development life cycle (SDLC). MSF provides an adaptable guidance, based
upon experiences and best practices from inside and outside of Microsoft, to increase
the chance of successful deliverance of information technology solution to the customer
by working fast, decreasing the number of people on the project team, averting risk,
while enabling high quality results.
MSF 4.0 provides a higher-level framework of guidance and principles which can be
mapped to a variety of prescriptive process templates. It is structured in both descriptive
and prescriptive methodologies. The descriptive component is called the MSF 4.0
metamodel, which is a theoretical description of the SDLC best practices for creating
SDLC methodologies. Microsoft is of the opinion that organizations have diverging
dynamics and contrarily priorities during their software development; some
organizations need a responsively and adaptable software development environment, if
others need a standardized, repeatable and more controlled environment. To fulfil these
needs, Microsoft represent the metamodel of MSF 4.0 in two prescriptive methodology
39
Chapter 4 | Microsoft Solutions Framework
templates that provide specific process guidance, named Microsoft Solutions

Framework for Agile Software Development (MSF4ASD) and Microsoft Solutions
Framework for Capability Maturity Model Integration Process Improvement
(MSF4CMMI). Note that, these software engineering processes can be modified and
customized to the preferences of organization, customer and project team. The MSF 4.0
structure is illustrated in Figure 4-1.
Figure 4-1 MSF 4.0 structure
The MSF philosophy holds that there is no single structure or process that optimally
applies to the requirements and environments for all sorts of projects. Therefore MSF
supports multiple process approaches, so it can be adapted to support any project,
regardless of size or complexity [22]. This flexibility means that it can support a wide
degree of variation in the implementation of software engineering processes while
retaining a set of core principles and mindsets.
The Microsoft Solutions Framework Process Model consists of series of short

development cycles and iterations. This model embraces rapid iterative development
with continuous learning and refinement, due to progressive understanding of the
business and project of the stakeholders. Identifying requirements, product
development, and testing occur in overlapping iterations resulting in incremental
completion to ensure a flow of value of the project. Each iteration has a different focus
and result in a stable portion of the overall system.
40
The MSF for Agile Software Development uses the principles of the agile development
approach formulated by the Agile Alliance [1]. The MSF4ASD provides a process
guidance which focus on the people and changes. It includes learning opportunities by
using iterations and evaluations in each iteration [4]. The MSF4ASD is further
discussed in the next section, namely 4.4 MSF for Agile Software Development.
The Microsoft Solutions Framework for Capability Maturity Model® Integration

Process Improvement is a formal methodology for software engineering. Capability
Maturity Model® is created at the Software Engineering Institute of Carnegie Mellon
University6, and is a process improvement approach that provides organizations with the
essential elements of continuous process improvement7 resulting in a reduced SDLC,
improved ability to meet the cost and schedule targets, building products of high quality
[25]. The MSF4CMMI has extended the MSF4ASD guidance with additional formality,
reviews, verification and audit. This results in a SEP that relies on process and
conformance to process rather than relying purely on trust and the ability of the
individual team members. The MSF4CMMI has more mandatory documents and
reports than the agile version, and this more formal development process reduces risk on
large software projects and provides a measurable status. One of the benefits of using
the CMMI process is the standard evaluation by which we can compare the ability to
develop software in other organizations.
Summarizing, the Microsoft Solution Framework version 4.0 is a combination of a

metamodel which can be used as a base for prescriptive software engineering processes,
and two customizable and scalable software engineering processes. The MSF4ASD is
intended to be light weight, iterative and adaptable process. The MSF4CMMI have
more artifacts, more processes, more signoffs, more planning and is intended for
projects that require a higher degree of formality and ceremony. The MSF metamodel
consists of foundational principles, a team model and cycles and iterations, which are
described in the next sections of this thesis.
4.2 FOUNDATIONAL PRINCIPLES

This section revisits the seven foundational principles captured by the Microsoft
Solution Framework version 4.0. These principles are commonly used by developers
and managers and are generally recognized as common-sense elements for software
development project. They form the basis of the MSF software engineering process to
organizing people and processes. The principles are as follow:
1. Partner with customers

2. Foster open communications
3. Work toward a shared vision
4. Quality is everyone's job every day
5. Stay agile, adapt to change
6. Make deployment a habit
7. Flow of value
6
For more information see http://www.sei.cmu.edu/sei-home.html visited November 2005.
7
For more information see http://www.sei.cmu.edu/cmmi/cmmi.html visited November 2005.
41
Each principle is explained individually in the next sections.
PARTNER WITH CUSTOMERS

A key success factor is to know the real stakeholders business value of the solution.
Communicating and interacting with the customer identifies this business surplus value.
Regular meetings and evaluations between the project members and the customer make
sure that this value is kept in mind and that the solution evolves to the expectation of the
customer [24].
FOSTER OPEN COMMUNICATIONS

Information concerning the project has to be shared with all members of the team to
create a complete and optimal project environment. Each team member has his own
quality, ability and vision to the solution; and by sharing this information not only
reduces the chances of different visions of the solution, it also ensures that all members
can contribute knowledge to decrease project uncertainty and to create a better solution.
Communication between all stakeholders is the medium through which a shared vision
and performance objectives can be defined, measured, and achieved [22], [24].
WORK TOWARD A SHARED VISION

All stakeholders have to participate in the creation of a shared vision to ensure that
everyone understand and emphasize the same goals and ideas of the end-solution.
Through shaping the vision collectively, all stakeholders’ opinions are considered, so
the project decisions are not arbitrary. The vision statement has to be clear and
elevating, so it gives the project a more secure environment. Without a shared vision,
stakeholders may have conflicting ideas or views of the goals, value and outcome of the
project, that which may results in an unsatisfying and unwanted solution [22], [24].
QUALITY IS EVERYONE'S JOB EVERY DAY

The quality of the solution is a responsibility of all participants. For instance team
members perform both bug prevention and solution verification to assure that the
project has the required quality level. By means of preventive, detective and corrective
measures throughout of the lifecycle, flaws can be determined and fixed early in
software development life cycle to reduce the costs of patching up and to keep a high
quality level of the system [24].
STAY AGILE, ADAPT TO CHANGE

The current information technology is rapidly changing and becoming more innovative
to explore new grounds and new opportunities. These new grounds bring along more
uncertainty in the development project.
The bigger and more innovative a system is, the more uncertainties the development
project has during the system development life cycle. These uncertainties push the
project in a situation where establishing the conditions and constraints a priori is hard to
42
do. Nowadays, to define all the requirements and constraints of a project in advanced
becomes more an illusion. To demand certainty in a changing environment is unrealistic
and leads to unsuccessful project. Therefore, project members have to expect the
inevitable changes to be made during the lifecycle [22], [24].
MAKE DEPLOYMENT A HABIT

The project environment is changing and the team has to be agile to adapt to these
changes. This changing environment contributes to a more complex development
lifecycle, which can result in a disorderly and chaotic process, where nobody really
knows the overall status of the project. Each day ends with an executable product that is
ready to be deployed to protect it against unmanageable and unexpected situations and
to keep the team members focussed on the right vision. MSF says the project team must
get custom to create an executable and deployable product by developing the system
incrementally and practicing to deploy it, to keep a realistic view of the overall status of
the system [24].
FLOW OF VALUE
The project should be planned and executed to create a flow of value. Every step is
scheduled based on the delivery of increasing value to the customer. The activities are
prioritized in the order of adding business value in the solution to the customer.
Activities that do not add a customer value have to be minimized. This principle of
prioritize and incremental development ensures that every step has a positive effect to
the customer value and return on investment of the project.
4.3 TEAM MODEL

“All things will be produced in superior quantity and quality, and with
greater ease, when each man works at a single occupation, in accordance
with his natural gifts, and at the right moment, without meddling with
anything else.” - Plato
The Team Model is the part of the MSF that structures and organizes people and
activities, in line with the MSF principles mentioned earlier, as they share a common
project vision and focus on deploying the project, to positively influence the outcome of
a project. The team model consists of three fundamental beliefs, namely team of peers,
advocacy groups and stretch to fit.
The first key concept is the team of peers, which places equal value on each role in the
team model to create a non hierarchic balance. This emphasizes the idea that everyone
in the project team is equal to enable unrestricted communication, increase team
accountability and responsibility. Not like in a hierarchy, each role contributes to and is
responsible for their part of the quality of the overall solution. The team of peers is the
glue that holds the roles of the project together and is illustrated in Figure 4-2 as the
cycle through the advocacy groups [21], [24].
43
Figure 4-2 The Microsoft Solutions Framework Team Model [24]
While the entire team is responsible for the overall project’s success, MSF divides the
team model into seven groups. An advocacy group, as depicted in Figure 4-2, is a
cluster of coherent functional areas with its own goal and responsibilities. This
representation of a project team provides a good balance to ensure accountability and
focus [21], [24].
The Program Management group advocates for solution delivery, where the focus is to
deliver a solution within given projects constraints. This group is responsible to keep
the project on the right track. Architecture advocates for the system in the large to
ensure that the deployed solution will meet all qualities of service as well as the
business objectives and will be useful in the long term. It is responsible for the service,
technical considerations, and standards with which the solution will interoperate; the
infrastructure in which it will be deployed; its place in the business or product family;
and a roadmap of future version. In other words, the architecture advocacy group
focuses on the architectural aspects of the software engineering process. The primary
task of the Development group is building the solution. It ensures high-quality code by
writing maintainable, unit tested and clear design code and fixing the identified bugs.
Test advocates for the quality of the solution by looking for and notifying the project
team on aspects, bugs and errors which negatively influence the quality of the solution
from the customer and user perspective. Release Operations advocates for the correct
delivery and deployment of the solution into the customer’s environment to ensure
timely readiness and compatibility of the infrastructure for the solution. The User
Experience attends to enhance the users’ effectiveness in the way they work and
perform, by means of identifying the end-users and their needs, and communicating the
user’s feedback to the rest of the project team. Product Management has to understand
44
the customer’s incorporated business, communicate the customer’s needs to the team
members, and give the customer economic project satisfaction [21], [24], [25].
The MSF team model can be stretch to fit more projects with different characteristic in
different organizations. The roles of the MSF team model can be combined to fit small
project teams or further divided as teams develop larger solutions. Note that some roles
are unlikely or even not recommended to be merged, because it is important to preserve
the balances and controls in the team model to keep the accountability and focus that the
different advocacy groups provide. Where the Rational Unified Process has a big team
model and often has to be scaled down, the MSF has a small team model that can be
stretch to fit bigger projects [24].
The foundational principles and the team model are aspects of the descriptive meta-
process. As already mentioned this MSF 4.0 meta-process consists of a formal
prescriptive process, Microsoft Solutions Framework for CMMI Process Improvement
and an adaptive prescriptive process, Microsoft Solutions Framework for Agile
Software Development. This thesis compares the Rational Unified Process to the
Microsoft Solutions Framework for Agile Software Development on request of
LogicaCMG. The MSF4ASD is described in more details in the next section.
4.4 MSF FOR AGILE SOFTWARE DEVELOPMENT

“The BEST way to be agile is only to build what the consumer values and
nothing more” - David J. Anderson
Agile development methods have increasingly taken central stage in the last few years.
On February 11-13, 2001 a council of seventeen people, known as the Agile Alliance8,
created the Agile process model. The Agile Alliance is a non-profit organization that
supports individuals and organisations that use agile approaches to develop software.
Driven by the simple priorities articulated in the Manifesto for Agile Software
Development [1], agile development approaches deliver value to organizations and end
users fast and with high quality with the notion that people are more important than
process. The Manifesto for Agile Software Development emphasizes the following as
value of Agile Software Development (ASD):
Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Examples of agile methodologies are Scrum, Dynamic Systems Development Method,

Adaptive Software Development, Crystal and Feature Driven Development, but the best
known agile methodology is Extreme Programming. The Microsoft Solutions
Framework for Agile Software Development represents a version of the Microsoft
Solutions Framework that de-emphasizes formal project governance by embracing the
thoughts of the Manifesto for Agile Software Development. It focuses on collaborative
8
http://www.agilealliance.org visited at November 2005.
45
project teams who strive for a decisively software engineering process, which can cope
with a changing environment. It enables iterative software development enhanced with
features like risk management, release management and design for operations.
Microsoft Solutions Framework for Agile Software Development is a scenario-driven

by directly incorporating practices for handling quality of service requirements such as
performance and security. MSF4ASD is also context-based and uses a context-driven
approach to determine how to operate the project. This approach helps to create an
adaptive process that has the ability to cope with a changing environment.
The process of MSF4ASD is composed of tracks, advocacy groups and cycles. The
tracks are the time phases of the process and lead to governance checkpoints that creates
go/no go moments in the project. The seven advocacy groups of the MSF team model
are groups of combined work actions that are related to each other. The MSF4ASD
maps these seven constituencies onto six roles, explained in section 4.4.3, where each
role contributes a different part of the whole project. Where the tracks represent the
process in time, the advocacy groups represent the process in work activities. The cycles
describe the frequency with which activities, within the tracks and advocacy groups, are
performed or work products produced and updated to turn the project cycle as depicted
in Figure 4-3. The cycles are filled with relevant Work streams that are explained in the
next paragraph. Note that, a cell in the Figure 4-3 may contain more than one iteration
cycle.
Figure 4-3 Tracks, advocacy groups, and cycles
In the MSF4ASD, the non-functional and functional requirements of the system are
expressed in scenarios and quality of service requirements (QSR).
Functional requirements are statements of services the system should provide. It
prescribes the expected reaction to particular inputs and behaviour in particular
situations. In some cases, the functional requirements may also explicitly state what the
system should not do. A scenario explains a single path of user interaction through the
46
system and uncovers these functional requirements needed to run this single process of
the system. As a persona attempts to reach a goal, the scenario records the specific steps
that will take in attempting to reach that goal. A persona is a fictional individual who
represents a group of users of the future system and is used to classify the needs of an
entire customer segment by exploring the characteristics of one fictional individual such
as skills, abilities, needs, desires, working habits, tasks, and backgrounds. The personas
and scenarios have to be refined to keep up-to-date, as changes occur or new insights
are obtained. Non-functional requirements are constraints on the services or functions
offered by the system. They include timing constraints, constraints on the development
process and standards. Non-functional requirements often apply to the system as a
whole. They do not usually just apply to individual system features or services. The
quality of service requirements documents these non-functional requirements of the
system such as performance, load, availability, stress, accessibility, and maintainability.
These requirements usually take the form of constraints on how the system should
operate.
As already explained, a cycle consists of coherent work streams. Work streams are
groups of activities that flow logically together and are often associated with a particular
role. Every work stream contains of various activities that describes the work
instructions in detail for the concerned role. For example, the ‘Release a Product’ work
stream contains four activities and is the responsibility of the Release Manager role, as
depicted in Figure 4-4. Every activity in the work stream encloses prescriptive
instructions, e.g. create or update work products to obtain the goal of the work stream.
Figure 4-4 Work stream example: Release a Product [24]
The combination of cycles, work streams and activities create a process environment
where every role knows what, how and when he has to do his job.
4.4.1 PROCESS OVERVIEW

“To expect the unexpected shows a thoroughly modern intellect.” - Oscar
Wilde
This section gives a detailed description of the MSF4ASD process. It describes the
change of focus in time and the work division in different segments. Different iterations
have different focus as the project approaches the release phases of the SEP. Different
47
roles have different activities of representing the specific needs of its constituencies
[24].
A visually depiction of the process gives one a clear overview about the SEP.
MSF4ASD did not have a graphical representation of its process, like RUP does.
Therefore we conducted a graphical representation of Microsoft Solutions Framework
for Agile Software Development as shown in Figure 4-5. The comment of the architect
of the Microsoft Solutions Framework, Granville G. Miller9, on this graphical
representation of MSF4ASD was: “This is really good!” and “Fantastic job!”. The
procedure of accomplishing this illustration is summarized in appendix A.
Figure 4-5 The graphical representation of MSF4ASD
enacted, and it is expressed in terms of cycles, tracks, and governance milestones. The
vertical axis represents the static aspect of the process: how it is described in terms of
advocacy groups, roles, Work streams and activities. The undulated lines represent the
workload and amount of activities of a particular advocacy group in time during the
software development life cycle.
9 Granville “Randy” Miller is the architect of Microsoft’s agile software development process, Microsoft Solutions Framework for
Agile Software Development. He has two decades of experience in the commercial software industry and has spoken at many
international events, including XP200x, Conference On Object Oriented Programming Systems, Languages and Applications, Web
Services Edge, Software Development West, Microsoft TechEd, and others. His interests include software development technology
and agile software development. Miller is author of “Advanced Use Case Modeling” and “A Practical Guide to Extreme
Programming.”
48
4.4.2 TRACKS
The Microsoft Solutions Framework for Agile Software Development uses tracks to
phase the process. Tracks group the activities that lead to governance checkpoints,
which are illustrated in Figure 4-6. The governance concerns the control of time and
capital and not the execution of tasks or work, which are handled in the cycles that are
described further in this chapter.
Figure 4-6 Governance checkpoints [24]
After the end of each track five questions are asked to create “go/no go” moments. For
example after the Envision track the decision has to be taken if the product is built and
after the Stabilize track the project team has to decide if the product is ready to be
deployed. In the next sections the tracks of the MSF4ASD are explained individually in
terms of which roles and activities are concerned during this phase of the software
development life cycle [20], [25].
ENVISION
The Envision track addresses an important condition that is mandatory to end a project
successfully, namely the unification of the stakeholders behind a common vision of the
project. A project vision is a clear establishment of the end result and the purpose for
building it. A team without strict boundaries and goal is bound to lose track on building
a system that meets the needs and expectations of the stakeholders. A clear and
structured project goal is required to create a cooperating and motivated atmosphere
among the team members and customer. Also during the envisioning phase, the general
business requirements must be identified and analyzed, which are refined in each
iteration during the whole software development life cycle. This track ends with an
agreement between the project team and customer on the overall direction for the
project, a general identification of the features of the system, and general schedule for
the completion of the product [22], [24].
49
PLAN
In this phase it is intended to create the plans for the iterations and project. The iteration
plan is constructed by choosing the scenarios and quality of service requirements and
prioritizing the tasks within them that should be implemented in the upcoming iteration
based on its importance and workload. Once the team knows what to do, the project
manager creates the iteration plan based on the time to develop, test and fix bugs. This
track ends with the team accepting the plan of the work that will be done in the next
phase [24].
BUILD
During the build track, the implementation of thoughts and ideas of the system are
accomplished. The developers build the code in an orderly and structured way and once
implemented, they have to unit test their additional parts of the system to ensure quality.
The developers code the system incrementally and iteratively to obey the adaptive
characteristic of agile software development. Note that, while implementing the
scenarios and QSRs into code, the software development team needs to create
accompanying documentation [24].
STABILIZE
In this track of the software engineering process the tester stabilizes the current
implemented code of the solution. This stabilization implies that the tester runs the
appropriate tests to verify the quality of the system. He checks the overall system on
correct implementation of the scenarios and quality of service requirements, makes sure
that the bugs are fixed and reports the found errors. Once all requirements are
implemented and the system is stable enough to be released, the project continues to the
next phase [24].
DEPLOY
In this point in time of the project, the system is implemented, meets the needs of the
stakeholders and is ready to be deployed at the customer site. The deployment addresses
the packaging, installing and testing of the solution in the infrastructural environment of
the customer, delivering the appropriate documentations, like a user guide and
installation manuals, and customer’s acknowledgement of meeting the expected
business value [24].
50
CONTINUOUS
This track embraces the activities that are needed when a new release of the system is
wanted. The vision statement, scenarios and quality of service requirements are adjusted
and reformulated, and the lessons learned are documented to improve the process of
developing the next generation of the system. This track gives a good preparation to the
team members and other stakeholder for the start of the following project.
4.4.3 ADVOCACY GROUPS

The MSF team model is a coherence of advocacy groups and roles, as shown in Figure
4-7. Each individual member of the team has at least one role in the project. A role is
accountable for representing the specific needs of its constituencies. As mentioned
earlier, none is more important than another and provide the necessary checks and
balances to ensure that the team produces the right solution. Note that, constituencies
may be combined to fit small projects or expanded to scale larger projects [24].
Figure 4-7 The MSF for Agile Software Development team model [24]
PROGRAM MANAGEMENT - PROGRAM MANAGER

The project manager is responsible for keeping the project and delivering the solution
within the formulated project constraints, time schedule, budget and stakeholders’
expectations. Program management implies planning and scheduling activities like
developing project and iterations plans, monitoring and reporting status, and identifying
and mitigating risks, in other words plan and guide an iteration and the overall project.
The iteration plan is estimated based on a bottom up approach. The project manager
cooperates with business analyst to plan scenarios and quality of service requirements
for an iteration, with architects and developers to estimate the workload, and with
51
testers to plan their tests. Therefore, he is the role of centre of team-communication

[24].
ARCHITECTURE - ARCHITECT
The architect role of the Architecture advocacy group is responsible for designing the
foundations of the application into a software architecture that describes the
characteristics and construction of the system. The software architecture contains a
clean and simple internal structure for the key elements of the solutions to reduce the
complexity of the system by dividing it into clear and independent partitions. This
division enables the application to better handle changing requirements. Well-defined
software architecture also positively influences the reliability and maintainability of the
system and describes how to meet performance and security standards [22], [24], [25].
DEVELOPMENT - DEVELOPER
The developer role is occupied by people who implement the solution within the
specifications and planned time-schedule. They build the application in a way that it
meets the needs of the customer and is ready to deploy at the client’s environment. After
completion of a segment, developers perform a unit test to verify the proper
implementation of a unit of code to ensure the solution’s quality. The developer also
specifies the features of the physical design and advices the program manager with the
estimation of time and effort to complete a feature [24], [25].
TEST - TESTER
The tester’s main goal is to ensure that the solution meets the quality standards for the
product. They have to identify problems of the system that negatively influence the
project’s outcome and communicate the findings to the other team members. The testers
must understand the whole context of the project to be able to test the product to prove
that known functions work correctly and to discover new product issues. Once a bug is
found, the tester has to precisely communicate its impact on the product or business
processes and give a solution on how to solve the problem. After the developers report
that the bug is fixed, the testers examine and judge if it meets the quality standards [24].
RELEASE OPERATIONS - RELEASE MANAGER

Managing the rollout of the product by creating a release plan and choosing release
candidates to be shipped to or deployed in the customer environment is the task of the
release manager. The release manager role reviews and validates the amount of
functionality of the built, makes a release plan and documents the known limitations of
the solution in the release notes. He is also responsible for packaging the product to
enable a careless deployment at the customer’s site [22], [24].
USER EXPERIENCE & PRODUCT MANAGEMENT - BUSINESS ANALYST

The Business Analyst represents the User Experience and Product Management
constituencies and is the centre of communication between users and other stakeholders.
52
His goal is to define the customer’s business opportunity and how the solution will
serve it. Therefore, he has to understand the customer’s business problems and IT needs
to be capable to translate them into persona definitions, scenarios and quality of service
requirements (QSR) that the development team will use to build the application. The
business analyst captures and communicates the customer’s field of business and needs
in the vision statement in order to keep the team focused, creates the quality of service
requirements to capture the non-functional requirements and constraints on the
functionality of the system, and creates scenario’s to capture the functional requirements
of the system. MSF utilizes the just-in-time approach meaning that scenario’s and
quality of service requirements are written not in the early phases of the SDLC, but
when the developers are ready to implement them [22], [24], [25].
4.4.4 CYCLES
The previous sections describe the phases and the responsibilities of the team members
in the project. Taking this in consideration, this section describes when the activities
occur during a project and an iteration. During the course of the project, different
activities are executed at different times and with different frequencies. For example,
the document that describes the vision of the project is created once in the early stage of
the process, the project plan is revised often, and the source code of the software is
revised more often.
MSF 4.0 lays out the frequency of the activities in so-called cycles, which are illustrated
in Figure 4-8. Cycles describe the frequency and duration of performing the activities,
or creating and updating work items in a timely manner. The small cogwheel has a short
duration and turns quickly. The big cogwheel has a long duration and therefore turns
slowly.
Figure 4-8 The MSF 4.0 Cycles [24]
The check in, daily build and the accepted build together turn the cogwheel of an
iteration and all the iterations together turn the Project cogwheel.
PROJECT
The Work streams in the Project cycle capture the project vision, plan the iteration and
release a product. The project team must have a clear and shared vision of how the
53
solution meets the business needs of the customer and creates a cooperating and
motivated relation with stakeholders.
The business analyst is responsible for establishing of the project vision. Capturing the
vision in a vision statement and share this to all stakeholders is the most essential aspect
to keep a project focused. Once the vision is captured changes may occur during the
software development life cycle, then the business analyst has to realign the project to
the new vision. The shared vision categorizes usage patterns and goals of the end-users
by capturing personas. This fictional individual represents the needs and expectation a
of group users in different scenarios.
A project is partitioned into a number of iterations to organize the workload of the team
members. An iteration is a schedule of a set of tasks that occur in a fixed period of time.
The iteration length is the time that is needed to complete the tasks scheduled in the
iteration. It is established at the beginning of the project and is used for all iterations
throughout the project. The project manager determines the iteration length generally
expressed in weeks by examining the timely key factors like the delivery date of the
project, size of the scenarios, and integration time.
Once the solution has enough functionality and performance, it can be deployed at the
customer site. This means that the end-users are going to work with this release in their
environment for the first time. The release manager has to develop a release plan to
coordinate the delivery of the product. Once rolled out, he has to run a complete
regression test at the customer environment to identify the last bugs. He also has to
create so-called release notes, which describe the environment requirements, installation
details, new features, resolved bugs, and known defects with possible workarounds. The
track ends when the system is packaged to be easily installed, delivered and accepted by
the customer [20], [24], [25].
Figure 4-9 The Iteration cycle turns the Project cycle [24]
ITERATION
The iteration cycle is turned by the smaller cogwheels Accepted build, Daily build and
Check. The iteration cycles together turn the overall cycle Project, as illustrated in
Figure 4-9, to a delivery of the product that solves the customer’s problem.
First the architect has to create a solution architecture that has a simple structure for the
primary elements of the solution. This simple structural view of the system reduces the
complexity of the system, enables reusability of the components and makes the system
54
more flexible to changes. He partitions the system in logical parts and determines the
interfaces between them to enable parallel development. He has to develop two models,
namely the threat and performance model. A threat model documents the known
security threats to the system and expresses how to address them. The performance
model documents potential performance issues to the system and expresses how to
address them. Having this, the architect can now create an architectural prototype to
identify, address and reduce potential overall risks as early as possible in the project.
This prototype can be discarded once the issues have been addressed, or used as a basis
to work out the core architecture.
The business analyst creates quality of service requirements to capture the non-
functional requirements or constrains of the solution, such as platform, load, stress,
security, and performance. He also has to capture the functional requirements of the
solution in scenarios by determining the system’s goals. A scenario explains a single
path of user interaction through the system and the coherence is expressed through a
storyboard. Once both kinds of requirements are identified, he prioritizes and
documents them on the importance of each requirement. MSF uses the just-in-time
approach to write the scenarios and QSRs meaning that they are written when the
developers are ready to implement them. The scenarios and QSRs which adds the most
value to the customers business are implemented first in the upcoming iteration.
Once the QSRs and scenarios are described, the developers are being consulted to
estimate on how much time it costs to implement a development task. These
estimations, the vision statement and the iteration length are the foundation for planning
an iteration. This plan must have the right balance of scenarios, quality of service
requirements, and bug reparations for the upcoming iteration. After all, the amount of
work that can be realised in an iteration is limited.
The project manager is assigned to plan an iteration by first estimating the concerned
requirements for understanding how much effort they take. From there, he schedules the
iteration with the scenarios and QSRs and some time for fixing bugs. The scenarios and
QSRs are divided into development tasks for the developers for further understanding of
the work they have to accomplish. The iteration plan is finalized in a meeting of project
managers, business analysts and developers to be agreed upon and is published to the
project portal.
As the requirements are transformed into source code of the solution, the tester role
writes or updates tests in order to check them on bugs. A bug is an error in an already
implemented code that needs to be fixed. A scenario is tested through a so-called
validation test, which checks if the system functionalities match the specifications of the
realized scenarios. Testing a quality of service requirement demands performance,
security, stress, and load tests to be successfully completed. These tests check the
system’s response time and break points under normal and extreme pressure, and check
the system’s threats that are listed in the threat model. In this cycle the tester writes the
tests that are mentioned to verify the scenarios and QSRs.
When an iteration comes to an end, the project manager calls for a feedback meeting
with the developers, testers and business analysts to determine ways to improve the
development process and project environment to maximize productivity. After all, every
55
project and problem has its own unique characteristics. The project manager
incorporates the results of this meeting into the planning of the next iteration.
The project manager has the responsibility to guide the project to a successful result.
Therefore, the progress of the whole project and of each iteration has to be monitored
and reported constantly. He consults the tester about the finding and outcome of the
tests, like test effectiveness, bug rate, code coverage detail, and test result reports. These
help understanding the progress of the project. This project status check uncovers the
bottlenecks and roadblocks, risks and bugs, which are ordered a priority for the next
iteration [22], [23], [24], [25].
The next cycles together are inside and turn the previous iteration cogwheel as shown in
Figure 4-10.
Figure 4-10 The Check in, Daily build and Accepted build cycles turn the Iteration Cycle [24]
CHECK IN
The ‘Check in’ cycle is the smallest wheel of all cycles, because it has the shortest
duration and turns frequently. The developer begins his role to reproduce the identified
bugs to locate and get more information about the causes. Once enough insight is
collected, he fixes the bug, and updates and runs the concerned unit test to ensure that
the new code is correctly implemented and is ready to be integrated into the build.
After fixing bugs he begins to implement a development task that is assigned to him. A
development task is a small amount of development work that stems from a QSR or
scenario and adds new functionalities to the system. Once the task is finished, it must be
unit tested, reviewed, and integrated into the existing code base. Each build contains a
set of build notes that outlines all of the new changes of the solution. The concerned
QSR and scenario are then passed on to the tester [22], [24].
DAILY BUILD
At the end of each day, the developers compile the code elements of the system into a
single build. A build is the compilation of all the files, libraries, or components of the
solution into a new set of executables, libraries, or components. This new build must
pass the build verification tests to make sure the modifications work correctly and do
not cause problems. After that, build notes are created to document that the new features
and changes are accepted. These notes are used to monitor the progress of the project.
For instance, the more code has changed going from build A to build B, the less stable
and mature the overall system is [22], [24].
56
ACCEPTED BUILD
After merging all development results in a team build, the tester verifies the reported
bugs to be fixed correctly. In this cycle the tester actually runs the written test cases to
verify the quality of the fixed bugs. If the test case runs successfully, the bug can be
closed. Otherwise, the bug is reassigned back to the developer. Other reasons to close a
bug are if the bug is deferred to another release, demonstrated to be invalid, not
reproducible, or a duplicate of a bug already logged.
The tester also verifies the implemented quality of service requirements and scenarios in
the build by selecting and running the adequate tests, which have been written in the
iteration cycle. Once a test case is run, it is important to record the results against the
scenario or QSR. The last activity of the tester in this cycle is performing an exploratory
test. Exploratory testing is a systematic way of testing a product without a
predetermined set of written tests. The method provided in this guidance describes how
a product is tested from the point of view of a persona with the purpose of generating
new requirements in the scenarios and QSRs. When all the tests are finished, the tester
reports his results back to the rest of the project team [22], [24].
The cycles, the Work streams and roles that are described in this paragraph are
summarized in Table 4-1 to give a general overview.
Table 4-1 Cycles, Work streams and roles
The Microsoft Solutions Framework for Agile Software Development is a process for
projects with short lifecycles and results-oriented teams who can work without lots of
57
intermediate documentation. It also emphasizes the delivery of working software and

promotes customer validation as key success measures.
58
Chapter 5
RUP VERSUS MSF4ASD

RUP and MSF4ASD guide the project team in creating a solution that meets
the needs plus expectations of the customer to satisfy the stakeholders. The
way the two software engineering processes reach this goal has common
grounds and differences, in the field of the philosophy, focus in time and
work division. RUP wants to identify the requirements early in the process to
be able to focus on time and budget planning to create a predictive
development environment. MSF4ASD embraces ad hoc requirements
management to facilitate the project team with the ability to cope with
changes to create an adaptive and responsive environment.
5.1 INTRODUCTION
This chapter answers research Question 2 by examining the common grounds and
differences regarding the IBM Rational Unified Process and the Microsoft Solutions
Framework for Agile Software Development, both depicted in Figure 5-1. The two
SEPs are compared in three different points of view, namely their philosophy, focus in
time and work division.
Figure 5-1 RUP versus MSF4ASD
The first comparison contains the best practices of RUP and the foundation principles of
MSF4ASD. The criteria are captured by gathering all best practices and foundational
principles and examined in detail to create an enumeration of a so called ‘Best
Principles’. Both processes are marked to what degree they emphasize these best
principles. The second point of attention compares the division of time of both SEPs for
a project, represented as the horizontal axis of the graphics of Figure 5-1. The phases of
IBM Rational Unified Process are measured up to the tracks of the MSF agile. The third
comparison looks at the vertical axis of the graphic representations of the two software
59
engineering processes that represents the workload of the project. It compares the
disciplines to the advocacy groups, the roles and activities of both processes, workflows
to the work streams and artifacts to work products.
5.2 PHILOSOPHY
RUP’s Best Practices: MSF’s Principles:
Develop software iteratively Partner with customers

To develop the solution in small steps, To understand the customer’s business
where each step yielding a working value and to get user feedback.
system.
Manage requirements Foster open communications

To identify, organize and document the To share all information with all team
requirements of a system. members.
Use component-based architectures Work toward a shared vision

To provide developers with a clear To have an agreement of all team
overview of the whole system and members on the formulated solution.
promote more effective software reuse.
Visually model software Quality is everyone's job every day

To capture and show a simplified All roles are responsible for the quality
graphical model of the structure and of the solution.
behaviour of architectures and
components. Stay agile, adapt to change
To cope with the changing environment
Continuously verify software quality and customer’s needs.
To assure the solution meets the
requirements based on reliability, Make deployment a habit
functionality, application performance To create readiness to ship the solution
and system performance. at any time.
Control changes to software Flow of value

To keep the project changes under To create business added value.
control.
60
Table 5-1 RUP's Best Practices versus MSF's Principles
Table 5-1 is an enumeration of the RUP best practices and the MSF4ASD principles
with a short descriptive sentence. Putting the best practices of the IBM Rational process
and the foundation principles of the Microsoft Solutions Framework together and
eliminating duplicates, leads to the ten Best Principles in Table 5-2. Both processes are
marked to what degree they give emphasis to these ten main beliefs.
Table 5-2 The ten Best Principles
The next sections explain how RUP and MSF4ASD emphasize these ten best principles.
ITERATIVE SOFTWARE DEVELOPMENT

– How do you eat an elephant, one bite at the time! –
Nowadays it is not fare to assume that project teams know every aspect of the project
and the product to be built. Every system has uncertain elements during the software
engineering process. Customers have no stable and clear idea about their wanted
solution, developers are not familiar with the customers business, and even the business
61
environment can change. The uncertainty causes privies to understand the solution-to-
be-built progressively along the software development process.
RUP emphasizes iterative development to cope with progressive understanding. It

prescribes that the software engineering process goes through numerous iterations to
mitigate risks and develop incrementally. Each iteration ends with an executable
product release and is accompanied with peripherals elements and supporting artifacts
like release description, user documentation, plans, and updated models of the system.
An iteration is a pass through all the RUP disciplines, as shown in Figure 5-2, and the
duration vary depending on the size and nature of the project. The project manager uses
the Iteration Plan artifact to plan the iteration tasks and activities, to schedule resource
needs, and to track progress against the schedule. An iteration is concluded with a so-
called iteration assessment, where the results of the iteration are evaluated against the
criteria and objectives that were formulated in the iteration plan. During this assessment,
the project team also analyzes the project procedure to improve the SEP itself.
Figure 5-2 RUP’s iterative development procedure [12]
MSF4ASD develops software with a more strongly iteratively mindset than RUP. It
contains five cycles as already mentioned in Chapter 4, namely the Check In, Daily
Build, Accepted Build, Iteration, and Project as shown in Figure 5-3. The project cycle
is turned by the iteration cycles, which itself is turned by three smaller cycles, depicted
in the picture as cogwheels. The principles of MSF4ASD prescribe that the project team
develops the system in a context where the product should be ready to ship at any time
and to deliver these releases frequently by iterative software development. MSF4ASD
prescribes to keep iterations sizes small with a duration time of a couple of weeks to a
couple of months, preferable to the shorter timescale, and should result in a stable
segment of the overall system. MSF4ASD prescribes that the system to-be-built is
designed and implemented to be executable after each iteration. The process also
recommends the team to practise deploying the solution in the user environment. The
overall project is not only divided in iterations, but an iteration is also divided into
smaller feasible parts.
Figure 5-3 The MSF 4.0 Cycles [24]
62
Iterations allow the project team to reduce the margin of error in ones estimates and
provide fast feedback about the accuracy of your project plans. Both RUP and
MSF4ASD emphasize an iterative development process that is adaptable based on the
progressive understanding of the future product, but MSF4ASD embraces this mindset
more strongly.
REQUIREMENTS MANAGEMENT
Requirements management is a systematic approach to eliciting, organizing,
communicating, and managing the requirements of a system [16]. The project team has
to analyze and understand the customer’s business problem to acquire the stakeholders’
needs and expectations of the system. These needs and desires are translated in the
system’s requirements. The determined and agreed requirements provide a basis for the
planning, cost and time estimation of the project and to manage the scope of the system.
RUP prescribes a "use-case driven approach" for managing the requirements of the
system and form the basis for the entire development of the system. RUP prefers
defining the requirements in way that tells a story of how one may use the system and
are expressed visually in the Unified Modeling Language. RUP claims that this scenario
driven approach provides greater completeness and consistency, and also provides a
better understanding of the importance of a requirement from a user's perspective. The
IBM Rational process wants the identification of the functional and non-functional
requirements as early in the SEP as possible. This enables the project team to estimate
and plan the project early and precise, but makes the software engineering process
rough to cope with changes during the development of the system.
MSF4ASD does not acknowledge the need to identify and manage requirements in the
early phase of the SDLC. This agile flavour of the Microsoft Solutions Framework
embraces identifying and creating ad-hoc requirements and design. MSF4ASD
welcomes changing requirements, even late in development. The Agile Alliance claims
it does not make sense to define the system’s requirements beforehand, because they
will change during the development process. One of the principles behind the Agile
Manifesto is “The best architectures, requirements, and designs emerge from self-
organizing teams” [1]. Therefore, the team works on deliverables in a just-in-time (JIT)
manner during the SDLC, e.g. the scenario’s and quality of service requirements are not
written by the business analyst in the early phases of the SDLC, but when the
developers are absolutely ready to implement them. MSF4ASD captures the vision of
the project in a so-called Vision statement. It is a short, coherent statement that provides
the project team with a brief summary of the project background, the driving factors,
and the purpose for building the system at a high description level.
RUP wants many requirements to be identified at the beginning of the project and to
strictly manage them. They form a basis for the development and testing of the solution.
MSF4ASD has a more flexible attitude towards managing requirements as they come
along the software engineering process. Both SEPs are scenario-driven processes that
define their requirements in stories and express them visually.
63
COMPONENT-BASED ARCHITECTURE
A software architecture is a blueprint which describes the structure and behaviour of the
system [16]. Stakeholders lose overview of systems due to complexity and information
overload. Software architecture reflects the organization and the system interaction on a
high level to obtain a better overview of complex systems. The architecture is translated
into architectural models (a model is a simplistic view of the reality). Architectural
models help stakeholders to understand and shape the system by simplistic
representation and hiding unnecessary information and improve the communication and
understanding, by setting a common set of references and vocabulary, throughout the
project [13].
A component-based architecture is a software architecture based on independent,

replaceable, reusable and modular components to help to manage system’s complexity
[12]. A component is a building block that fulfils a clear functionality of computer
software systems. Component-based architectures stress the technique of problem
decomposition by splitting a complex problem into more understandable parts.
Therefore components have the potential to shorten the software engineering process
and reduce the development time and costs by obtaining an overview of the system and
encouraging reuse of the building blocks [34].
Risks and requirements of the stakeholders are the basis of the architecture in the
Rational Unified Process. RUP provides a methodological, systematic way to design,
develop, and validate a durable and understandable architecture, which can cope with
changes and promotes reuse of new and existing components [13]. The project team
identifies the candidate architectures in the inception phase. During the elaboration
phase the project team baseline a robust component-based architecture, this matures
during the rest of the lifecycle. RUP also provides a number of templates and activities
to determine an architectural description around the concept of multiple architectural
views. The iterative development approach enables the project team to progressively
identify components, and therefore progressively plan when they are developed, got off
shelve or bought.
MSF4ASD says that the architect is responsible to ensure success of the project by
designing the structural elements of the system based on the MSF4ASD scenarios. This
includes defining both the organizational structure of the system and the physical
structure of its deployment based on the system’s requirements [2]. It does not prescribe
a clear instruction, only short statements for the project team to achieve an agile
architecture that are mainly based on experience and common sense.
The architect role must partition the system to reduce complexity by problem
decomposition, create encapsulation and promote reuse of subsystems. The team has to
identify and agree upon the interfaces between the subsystems to enable the developers
to build the system parallel. Determining the system’s interfaces helps with the
integration of the subsystems. When the interface definitions are agreed, only the
highest level and external interfaces for the system are presented in the application
diagrams. When the system is divided in subsystems and their interfaces are moulded, a
threat model is created. A threat model describes the known security threats with their
countermeasures and prioritizes them on the impact they may cause to the solution.
64
MSF4ASD says to build the threat model early and to update it as the architecture and
system evolves each iteration of the lifecycle. After the threat model, the architect has to
create a performance model, which helps to identify and address potential performance
issues in the system and is based on the quality of service requirement. In the agile
flavour it is important to address project risk as soon as possible by creating an
architectural prototype early in the software engineering process. Creating prototypes
reduces overall project risk and uncertainties and makes planning and estimating more
accurate. Finally, the architect has to create the infrastructure architecture, which
defines the deployment environment of the system to ensure that the system is
deployable and quality of service requirements are met. This architecture also must be
updated each time the system evolves during the lifecycle.
The difference between RUP and MSF4ASD in regards of component-based

architecture is that RUP prescribes in detail how to create and update the architecture
and MSF4ASD describes briefly what should be done. Also RUP is more component
oriented than MSF4ASD, which only mentions problem decomposition and reuse of
subsystems.
VISUAL MODELING
Project members need to have an insight of the system and have to unambiguously
communicate decisions with other team members or other stakeholders. Visual
modeling is used to provide the project team with a better overall overview, because we
cannot comprehend such a system in its entirety. A model describes a system from a
particular perspective and helps the project team and other stakeholders to visualize,
specify, construct, and document the structure and behaviour of architectures and
components. Each model reflects different aspects by focussing on different relevant
information and activities.
The RUP uses the Unified Modeling Language (UML) to visually specify the system.
The UML is a widely accepted language that uses different models for different
stakeholders to express their interest and addresses all the important analysis, design
and implementation decisions. The software development and team communication is
driven by use-cases.
The MSF4ASD applies a different visual modeling language called Domain Specific
Language (DSL). According to Microsoft, UML is a too general language; every aspect
of the whole system is visualized in one language. The domain specific language is a
visual modeling language that is designed to be useful for specific set of tasks or
interests of the software engineering process and it lets project members design models
using domain related terms.
Both processes emphasize visual modeling to improve the team’s ability to manage
system complexity. But RUP also uses the models to communicate with team members
and stakeholders, where MSF4ASD communicates more face-to-face.
65
QUALITY ASSURANCE MANAGEMENT

The success of a software engineering process strongly depends on the delivery of
quality software [36]. The purpose of quality assurance management is to minimize the
presence of defects or fault in the product and process to reach a higher level of product
quality. Therefore, the project team has to continuously verify the quality of the product
and process. Quality is hard to define, because it is a vague and relative concept,
therefore a project needs clear-cut well-defined criteria and methods to measure the
quality of the product. High quality software is typically defined by quality attributes
like customer satisfaction based on budget, time and achieved requirements.
RUP verifies the quality of the product, artifacts, and process at the end of each iteration
through well-defined review procedure. This review includes an iteration assessment to
evaluate the course of the iteration; which targets are obtained, why things went wrong,
and collect feedback of the end-users. The outcome of the assessment is the primary
input for the next iteration planning activities. In RUP quality can be measured in many
ways, like use cases implemented or milestones completed, artifacts completed, and
discrepancy of planned and real schedules and budgets. RUP prescribes that the creation
of process and product quality is the responsibility of everyone in the project team and
therefore is integral to almost all project activities. The accountability of the quality is
only related to whom is directly involved in a specific process component or artifact.
The project manager role is responsible for managing, measuring, and achieving the
overall quality of the project [12].
One of the principles is to invest in quality, for that reason MSF4ASD defines quality as
an objective. This assurance is present in all principles, practices and activities, so
quality is continuously verified to ensure the project keeps on the right track. A team of
a MSF4ASD project consists of a so-called Team of Peers. This implies that no one of
the team members is more important than another. The participants have a shared
responsibility for the quality of the system, but are accountable for their own portion of
the overall system. By means of preventive, detective and corrective measures
throughout of the whole software engineering process, like code analysis and peer
reviews one can prevent flaws as well as maximize the testing to find flaws in order to
enforce a better quality of the system [24].
CHANGE MANAGEMENT
The conservative ‘waterfall’ approaches believe that the project team has the ability to
know all aspects of the solution in advance. Nowadays, as previously mentioned a
software engineering process is a creative process with accompanying uncertainties and
is subjected to change in its solution, process and environment. To demand a high level
of predictability in a changing environment is unrealistic and leads to unsuccessful
projects. The whole software development environment is a strong coherency, where
multiple developers are organized in teams on maybe different workplaces, working on
several different components, releases and products of the solution. Changes that are
made during the SEP may have deep impact on the various parts of the solution. Change
management enables the project team to cope with changing requirements and
66
environment due to progressive understanding by controlling and tracking of changes,

and versioning of the releases.
In RUP, the configuration & change management discipline prescribes how to control,
track and monitor changes to create an environment for coordinating the activities,
artifacts, iterations and releases of the SEP. Coupled with iterative software
development and requirements management, RUP provides a guidance for the project
team to be able to continuously monitor and control changes, to lay bare the
consequences of the change and to track the changes that were made. The submitted
changes have to be motivated and checked by the responsible role to be justified to the
project agreements. Accepted changes are not handled in the current iteration, but are
planned to be granted in the next iteration. Changes that have drastic impact on the
current iteration or product may cause the iteration to end premature, so the project team
can make the necessary changes before they begin at a new iteration. The RUP change
management is an extensive and prescriptive procedure.
MSF4ASD strives for an adaptable software development environment and therefore

harness change for the customer's competitive advantage. It makes the assumption that
continual changes from all stakeholders should be expected. This is enabled by means
of planning short iterations to achieve a quick reaction of the change request, and using
a team-of-peers to foster open communication to be able to identify the best founded
changes and understand the coupled impacts of the changes, to improve the quality of
the product or the process. Close interaction and communication between the customer,
end-users and project members helps to attentively monitor the possible changes that
have to be made to the product, process and environment. To stay agile and expect
change is a significant characteristic of the discussed variant of the Microsoft Solution
Framework. As stakeholders have lack of restrictions for bringing up changes,
MSF4ASD has an anarchistic attitude towards change management; more a ‘plan-as-
you-go’ attitude.
RUP uses a formal and strict change management to control and plan the adjustments,
where MSF4ASD has a lawless change management to give the stakeholders more
freedom of movement concerning changing aspects of the future solution by
establishing the needs and requirements within margins and instead of fixed points.
CUSTOMER INVOLVEMENT
Satisfying the customer is really the number one objective in a software engineering
process. At the end, a customer has to receive a system that has a surplus value for their
business process. The project team has to interact with the customer during the software
engineering process, at first to ensure that they understand and solve the customer’s
business problem and to control and validate the system releases, to achieve a business
value adding solution.
The RUP role model defines roles for the customer to stimulate customer involvement
during the software engineering process, and the project manager is the link between the
customer and the project team. RUP involves the customer to define, control and
validate the system’s requirements. This interaction occurs in beginning of the inception
67
and elaboration phase and at the end of an iteration to give feedback on the product
release.
MSF4ASD mentions that after the customer business problem is understood, the
customer involvement still has to be maximized to ensure that their expectations are
constantly aligned with the project through early and continuous delivery
of valuable software. Project members may take wrong assumptions when customers
are not able to provide feedback and check the status of their project. MSF describes
some techniques that support setting and managing the customer’s expectations like
delivering quality products frequently.
The MSF4ASD prescribes a more frequent interaction between the project team, the
customers and other stakeholders than RUP. RUP prescribes the team to communicate
on planned moments, during the iterations assessments at the end of an iteration, while
MSF4ASD recommends a continuous interaction with its customers.
OPEN COMMUNICATION
Communication is an important factor for having a successful software development
team and therefore a successful project. Developing a technologic solution is a creative
process done by humans and each individual has his own ability and perspective to the
project. In order to create a clear project status vision, to understand the business
problem and to prevent communication pitfalls, a software engineering process has to
have a well-formed communication structure between all stakeholders. As projects are
getting more complex, more open communication is necessarily to enable stakeholders
to notify their opinion, status and problem to each other, to create a shared vision and to
ensure and assure the project is on the right track.
The communication in RUP is mainly based on documentation and not on face-to-face

communication. High-level models like use cases are the main communication medium
between customer and project team, provided by the project manager. The only personal
communication in this software engineering process occurs at the end of the iteration in
an iteration assessment to evaluate the achieved objectives and failures of the iteration.
MSF4ASD believes that all project information has to be actively shared with all
stakeholders to create a project environment that maximizes members’ individual
contributions. Each team member has his own skills and vision towards the process and
solution. Sharing all knowledge ensures more members’ insight of the best solution to
decrease project uncertainty, creates a general agreed vision of the solution, as well as
everyone-is-equal aspect positively influence the team spirit. The regular planned open
communication becomes more important as projects increase in size and complexity and
is the medium through which a shared vision and performance objectives can be
defined, measured, and achieved [22], [24].
RUP uses a hierarchic team model and document-based information distribution on a

need-to-know basis to create communication flows. MSF4ASD uses the team-of-peers,
close interaction between stakeholders and the free flow of information to emphasize an
open and actively shared communication in the project.
68
SHARED VISION
A shared vision is needed to ensure that all members of the project understand the
customer’s business and how the IT-solution will help to achieve business value, and it
gives a clear understanding of its objectives to solve the customer’s business problem.
This collective mindset makes the software engineering process less amenable to
conflicting views, unnecessary labour, and communication flaws.
The best practices of RUP do not explicitly mention the need to create a shared vision.
Although in [28] is said that one of the minimal set of items a project will have if they
are truly following the ‘essence’ of the Rational Unified Process is to develop a vision.
This Vision artifact of the requirements workflow is created early in the Inception phase
and evolves during the earlier portion of the lifecycle. It documents the stakeholders’
view of the future product, specified in terms of the stakeholders’ fundamental needs
and features. Team members use this document to create a general understanding of the
stakeholders’ business problem and needs to create a shared vision of the future system.
Also MSF4ASD does acknowledge the need to capture the vision of the project by
writing a so-called Vision statement. It is a short, coherent statement that provides the
project team with a brief high level summary of the project background, the key driving
factors, and the purpose for building the system. Combine with its related activities, the
vision creates a solid foundation on which the project can be built. By means of so-
called personas, the vision statement gives the team members an understanding of the
end-users, their goals and their usage patterns. A persona is a fictional individual who
represents a group of users of the system to be developed and is used to classify the
needs of an entire customer segment by exploring the characteristics of one fictional
individual. MSF4ASD underlines that capturing and communicating this central vision
is the most important element to keep a project focused. The vision statement and the
project team composition of MSF4ASD, where everyone is treated equal and open
communication is applied, create a togetherness, because decisions are not arbitrary, but
are determined in a solidarity vision of the solution.
Both software engineering processes create a vision to ensure fulfilling the correct needs
of the customer, but MSF4ASD shares this more with the project team and stakeholders.
RUP has a more hierarchic and closed communication flow than MSF4ASD.
VALUE ADDING ACTIVITIES

Successful solutions must meet the customer’s needs to deliver business value.
Although many technology projects focus on the delivery of technology, technology is
not delivered for its own sake, the solution must provide tangible business value. The
project should be planned and executed to create a flow of value. Every step is
scheduled based on adding value to the system.
This best principle is not mentioned explicit in the best practices of RUP. RUP has risk
driven approach as it prioritizes the activity on the level of risk and not level of adding
business value. RUP prescribes that the activities with highest risk should be
implemented first. MSF4ASD prescribes that the activities are organized and prioritized
in the order of adding business value in the solution to the customer. Activities that do
69
not add a customer value have to be minimized. This principle of prioritize and
incremental development ensures that every step has a positive effect to the customer
value and return on investment of the project. The 'flow of value' is a key component of
agile methodologies. They want to deliver value to the customer throughout each
release, not just at the end.
CONCLUSION
Table 5-3 reflects a summary of process rating of the results of the comparison of the
Rational Unified Process best practices and the Microsoft Solutions Framework for
Agile Software Development principles. The rating is carried out by giving points to the
level of embracing the comparison criteria, where 1 represents a weak, 2 a moderate,
and 3 a strong accent of the criterion in the software engineering process.
Table 5-3 The best principles for RUP and MSF4ASD
Both RUP and MSF4ASD perform overall equally, only the processes emphasize
different best principles.
RUP is a strict and formal process, resulting in the possibility to plan, schedule and
control the project more accurately. Requirements and changes are managed in a
prescribed method to keep track and control of the progress of the solution. The team
develops the system on the basis of a component based architecture and communicates
on a need-to-know basis that is mainly based on documents. The customer and end-
users are involved in the SEP at prescribed moments to evaluate the product and to
feedback the change requests. These changes are well managed, but are restricted by
previously identified project boundaries.
The MSF4ASD is a flexible and informal software engineering process to maximally
support the will of the customer to create a business value adding solution. This agile
flavour of the MSF believes that system development is a creative process with
uncertainties, which causes stakeholders to understand the needed solution
progressively along the software development life cycle. It assumes that change requests
will appear along the way, and therefore less acknowledges the needs of requirements
management, change management, and architecture. By strong iterative software
development, the project team is able to build the product incrementally and implements
the changes when they occur. MSF4ASD emphasize great customer involvement to
continuously receive feedback and to create an environment, where changes can be
made all the time. The iterative software development, continuous customer
70
involvement, the equal status of team members and open face-to-face communication
allows the environment to be agile.
5.3 FOCUS IN TIME

RUP’s Phases: MSF4ASD’s Tracks:
Inception Envision
To specify the vision, its business case, To unify the stakeholders’ goals behind
and defining the scope of the project. a common vision of the project.
Elaboration Plan
To plan the activities and resources, and To understand and track the progress of
to specify the features and design the project and product.
architecture of the system.
Construction Build
To build the product and to evolve the To write and update the architecture,
vision, architecture, and planning until scenarios, QSRs, and to develop the
the system aligns with the agreements. system incrementally en iteratively.
Transition Stabilize
To hand the system over to its users by To verify and to close a bug to enable
deploying it in the user environment or stability of the system.
delivering it to the buyer with the
appropriate support, trainings and Deploy
documentation. To deploy the stable system in the
customers environment with
accompanying documentation.
Continuous
To identify the lessons learned and to
prepare for starting a project for a new
release.
71
Table 5-4 RUP's phases versus MSF’s Tracks
In the beginning of the project, the project members are brought together and for the
first time introduced to the stakeholders. The team gain knowledge of the business
problem and environment, the needs and expectations of the customer. This information
has to be documented and communicated, to create a complete and common vision
among all stakeholders.
The Rational Unified Process as well as Microsoft Solutions Framework for Agile
Software Development create respectively a so called vision artifact or vision statement
to ensure that all stakeholders have the same idea of the business problem and how the
solution solves it. Also both set boundaries to the project to scope the solution
environment, only RUP establishes the scope of the project in more detail to create
fixed boundaries. The scope of the agile project is wider to create an environment where
the solution has more freedom to move in order to align with altering wishes of the
customer.
Once the stakeholders know the business case of the project, the team has to identify
and understand which elements the system must have to solve the business problem.
The customer, end-users and other stakeholders notify the project team their wishes,
needs and expectations of the system. A RUP project team wants to obtain as much
information as soon as possible to create an overall planning and understanding of the
project. In the inception phase all requirements, overall cost and time estimations,
potential risks and candidate architectures are formulated. MSF4ASD has an agile
mindset, meaning that a MSF4ASD team thinks that it is not necessary to have all the
information in advance. The agile community believes that change is not only likely,
but it's inevitable. That is the reason the MSF4ASD uses the just-in-time (JIT) approach,
where an item is created when that item is needed. In the first track of the SEP, the
envision track, only the vision statement, persona’s and iteration length are determined
to create a go/no go to continue to the next track. The scenarios, quality of service
requirements, and architecture are created and updated right before they are
implemented. This attitude enables you to be flexible and cope with changes, but this
makes the whole project less suitable to plan.
Both use this period to study the customer’s business, problem and needs, to develop a
common accepted view of the project. Only RUP is more strict and formal to the scope
and the agreements of the project than MSF4ASD which is more flexible and open for
changes.
72
The planning period is for elaborating the ideas of the future product, estimating the
time and cost of the project, and reserving resources. Both processes use the vision as
basis to create system architectures, identify the non functional and functional
requirements and constraints. As mentioned earlier, RUP wants to know as much as
possible in advance, to be able to estimate and plan the project as a whole and in
iterations. At the end of the inception phase all the functional and non functional
requirements are identified. In the elaboration phase, the team baselines the architecture
and vision and makes a detailed risk-driven plan for the whole construction phase to
manage and control the rest of the process. MSF4ASD focus more on the planning of
the iterations than the overall project planning. It has the opinion that planning the
project as a whole is unnecessary, because it believes that it is a given fact that changes
occur during the project. Where RUP focuses on risk driven planning of the project,
MSF focuses more on quality driven planning of the next iteration.
The build period has in both processes the same purpose, to build the software product
in line with the expectations, needs and agreements of all stakeholders. This phase
really shows the benefits of iteratively and incrementally development, which both
processes embrace. Step by step, the product is build and verified to ensure that the
quality of the product is kept on a high level. In the software engineering processes this
is the most work and time consuming period of the software development life cycle.
Although this phase has the same purpose in both SEPs, they differ in approach.
RUP has created a planning for the whole project and iterations in the previous phases
of the SEP and focuses now on the actual building of the product using iterations. The
developers receive the needed use cases, functional description and the architecture to
certify the functionalities of the system they have to build. Each iteration ends with an
executable release and is shown to the stakeholders for frequent end-user involvement
and feedback. Also the project team organizes an iteration assessment to provide itself
and other stakeholders with information about the progress and status of the system and
document the lessons learned to ensure that the project is consistent with the
agreements.
The short-term vision mindset of MSF4ASD is shown the most during this period.
Same activities of the plan track belong to the first iteration, which continues throughout
the build track and is repeated as much as needed throughout the project. The iteration
cycle is also divided in the cycles accepted build, daily build, and check in to ensure
more iteratively software development. The time between the start of a project and the
actual building of the system is short, because of the lack of interest to know all the
requirements and to plan the project as a whole. For that reason, the agile team has to
begin the iteration with the creation or update of the solution architecture, quality of
service requirements, and scenario’s that are implemented in this iteration. After that, a
work day begins with a short meeting to talk about the status, progress and work-to-be-
done of the week. The developers implement their tasks and fix the possible bugs,
which is illustrated in the metaphor check-in cycle. All this is done in the context of the
belief that the product should be ready to ship at any time. Therefore, the check-in cycle
turns the cogwheel of the daily build, meaning that at the end of the day, the changed
code is integrated in a build. The daily build wheels together are followed by the
acceptation of the build, where the builds are extensively tested and verified to meet the
appropriate level of quality. The iteration ends with an overall review of the objectives
and progress of the project.
73
Of course both processes continue building the product until it is finished, but RUP uses
the agreements in the project documentation and MSF4ASD uses the feedback of the
stakeholders to determine the state of the product. RUP plans the project and iteration in
advance, while MSF4ASD is more short-sighted and plans only the next iteration ad
hoc. Also, an agile project is more divided into fragments than one embracing RUP.
Once the product is mature enough and has the quality level that is expected by the
customer and end-users, it is ready to be passed to the customer. Different products need
different transition approaches. For example, a new release of a widely spread
accountancy system on the retail market needs a more commercial approach, than a
tailored human resource management system, which the team most likely needs to
implement at the customer’s environment. But there are basic elements or strategies that
need to be done to successfully handover the product to the customer; Beta testing to
validate the new system against user expectations, parallel operation with the legacy
system that the product is replacing, conversion of operational database, give trainings
to users, write additional documentation, like manuals, installation and release notes,
and possibly roll out an advertising campaign. After the product is rolled out at the
customer site, issues usually arise that requires for developing a new release, correct
some problems, or finish features that were postponed. Once the product is handed to
the satisfied customer, RUP’s project cycle comes to an end. The MSF4ASD has an
extra period in its process, namely the continuous track. Its purpose is to review the
overall project, and identify new risks, bugs and personas for a good start of the follow
up project for a new generation of the system.
The transition phase of RUP has one or more iteration to release the product at the
customer’s site to deal with unexpected errors. Typically, this phase contains beta
releases, general availability releases, and bug-fix and enhancement releases.
MSF4ASD has to stabilize and deploy tracks to ensure that the system is correctly put
into the hands of the users. To minimize problems at the customer site, the agile team
designs the system to be deployed and practices deploying it in a development
environment continuously during the build phase. RUP tests this at the end of the
project in the transition phase using one or more iterations. RUP uses the iterations in
the transition track to ensure a fine product handover, and MSF4ASD ensures this
throughout the whole project.
RUP and MSF4ASD use certain check-moments in their process. RUP calls them
milestones and MSF4ASD calls them governance checkpoints. These are the moments
the team looks objectively at the project to decide to proceed, abort, or change the
course of it.
RUP measures the progress of the project at the end of each of the four phases. The first
ends the inception phase, the lifecycle objective milestone checks the existence of a
common idea of the solution among all stakeholders. The second ends the elaboration
phase, the lifecycle architecture milestone verifies the existence of stable vision,
requirements and architecture, and the identification of the major risks. The third
concludes the construction phase, the initial operational capability milestone validates if
the product is mature and stable enough to be deployed in the user community. The last
one wraps up the project lifecycle, the product release milestone measures the
contentment of the user. MSF4ASD measures the progress of the project at the end of
the six tracks. Each track concludes by answering the five governance checkpoints, each
of which focuses on a specific question to answer. The first question reviews the system
74
to meet the minimum acceptance level of functionality. The second question assesses
the progress of the project to meet the deadlines. The third question concerns the
evaluation of the level of quality. The fourth question addresses the project and
technical risks. The last one asks the team if they designed and created a solution that is
ready to deploy.
RUP and MSF4ASD periodically verify the project to be on the right track. The
difference is that RUP changes the validation focus in time, once a focus area is labelled
positive, RUP does not reconsider this later in the project. MSF4ASD has the same
criteria to check the project during the whole software engineering process.
CONCLUSION
The different focus in time during the software engineering process as RUP is illustrated
in Figure 5-4 and MSF4ASD in Figure 5-5.
Figure 5-4 RUP’s changing focus of the phases in time
Figure 5-5 MSF4ASD’s focus of the phases in time
In the early period of the project, RUP wants the vision and scope to be complete and
strict as possible, and MSF4ASD wants a vision that is kept open to cope with a
changing project environment. After the common vision both process begin with
75
planning. RUP focuses on the risk driven planning for the project as a whole, MSF
focuses more on quality with adaptable planning for the next iteration. RUP plans the
project and iteration in advanced, if MSF4ASD is more short-sighted and plans only the
next iteration ad hoc. Besides MSF4ASD projects are more divided into segments than
RUP in order to cope better with the inevitable changes. After the creation of the
planning both processes continue building the product until it is finished, but the two
have different building approaches. RUP uses the agreements in the vision as guidance
during the construction phases and MSF4ASD uses the feedback of the stakeholders to
determine the state of the product. During the building track, MSF4ASD continuously
considers and tests on deploying the product in the customer environment to minimize
unexpected deploying problems. The RUP SEP does not do this and therefore has to test
deploying the system in the transition phase. Also MSF has an extra period in their agile
SEP, namely the continuous track to prepare the team for a follow up release project of
the product. During the process both SEPs have checkpoints to review the status and
progress of the project. The difference is that RUP changes the focus of the checks as
the project proceeds and MSF4ASD asks the same five questions for each checkpoint.
76
5.4 WORK DIVISION

RUP’s Disciplines: MSF4ASD’s Advocacy groups:
Business Modeling Product Management

To understand customer's problems and To define the business opportunity and
to ensure a common project vision the application that will serve it.
among the stakeholders.
User Experience
Requirements To understand the needs and goals of
To establish and maintain agreements the user and translates those into
with stakeholders how the system persona definitions, scenarios, and
should work to satisfy the needs and quality of service requirements.
expectations of the end-users.
Architecture
Analysis & Design To design the organizational structure
To transform the requirements into a of the application and the physical
design to evolve in a robust architecture structure of the application and to
for the system. reduce complexity by dividing the
system into clean and simple partitions.
Implementation
To implement the design elements, to Development
unit test them, and to integrate the To implement the application as
results into an executable system. specified within the planned project
constraints.
Test
To validate the correct implementation Test
of the requirements and to find and To discover and communicate product
document defects in software quality. issues and to prove that known
functions are implemented correctly.
Deployment
To ensure that the software product is Release Operations
available for its end users. To manage the release of the product.
Configuration & Change Management Program Management

To control the changes to, and To keep the project within the agreed
maintains the integrity of project’s schedule and budget.
artifacts.
Project Management
To provide a framework and guidelines
for managing, planning, staffing,
executing, and monitoring projects.
Environment
To provide the software development
company with both processes and tools,
that supports the development team.
77
The processes arrange the workload of project into groups to cluster the activities that
are related to a major ‘area of concern’ of the project to create more overview of the
process. These clusters called workflows (RUP) or work streams (MSF) group the
sequential activities that lead to an artifact (RUP) or work product (MSF), or have the
same goal in the project. Each artifact of work product has one role that responsible for
it, and one role is responsible for multiple artifacts. The process elements of RUP and
MSF4ASD are illustrated in Figure 5-6 and enumerated in respectively appendix B and
C.
Figure 5-6 The RUP and MSF elements
The Rational Unified Process separates its process in nine disciplines to represent a
partitioning of all team members and activities. These nine disciplines consist of six
engineering disciplines and three supporting disciplines. The engineering workflows are
business modeling, requirement, analysis & design, implementation, test, and
deployment. The three supporting disciplines are configuration & change management,
project management, and environment. A discipline consists of an enumeration of
workflows, these workflows consist of relevant activities, and each activity is addressed
to a role. A team member occupies one or more roles in the project. Generally RUP
organizes the team model in thirty-one roles and MSF in six roles, each with its own
purpose and goal for the project. The responsibilities of each team member are usually
expressed in relation to certain artifacts that the role creates, modifies, or controls. The
Microsoft Solutions Framework for Agile Software Development breaks up its process
in seven advocacy groups, the product management, user experience, architecture,
development, test, release operations, program management. The team model of
MSF4ASD is a non-hierarchic structure of people and their activities are aligned to the
advocacy group. These seven constituencies are generally occupied by the six roles
which MSF4ASD identifies. In Table 5-5, the comparison of the disciplines and
advocacy groups are schematic reflected, and the ones connected with the double arrow
are considered to be equivalent.
As shown in Table 5-5, all the advocacy groups of the agile flavoured process are
represented in the disciplines of the RUP. However, RUP identifies two other points of
attention, namely the disciplines ‘configuration & change management’ to control the
changes to, and maintains the integrity of project’s artifacts and ‘environment’ to
provide the software development organization with both processes and tools, that
support the development team.
78
Table 5-5 RUP’s Disciplines versus MSF’s Advocacy Groups
The MSF4ASD does not recognize the need for a separate configuration & change
management advocacy group for two reasons. First, the agile SEP believes that not a
role or person is responsible for configuration and change management, every team
member has to stay agile and be adaptive. Second, in contrast with RUP, where most
requirements are identified and elaborated in detail in the early phase of the SEP,
MSF4ASD uses the JIT approach to provide the project with more freedom of
movement during the software development life cycle. The more elements are
established and written down in advance, the more changes will be made at a later
moment in the process.
The MSF4ASD also does not recognize the need for an environment advocacy group.
This discipline provides the RUP project team with the right tools and acquisition, and
configures and improves the SEP, to support the development organization with both
processes and tools. The lack of interest in environmental advocacy groups confirms the
thought that this SEP expects a continuous follow up projects for new generations of the
product, because it assumes that a development environment already exists.
The processes differ in the amount of roles in their software development process.
Where the RUP software engineering process identifies thirty-one roles, the light
weighted agile process has just six roles. In general, RUP’s high quantity of roles sees
that team members have to perform one or more roles. In other words, the team model
has to be scaled down to fit the project and the number of team members. The agile
team model has a different way to fit the project. Looking at the number of roles in
MSF4ASD, team members have more chance to fulfil one role or even share the same
role. One of the fundamental principles of the MSF team model is stretch to fit the scale
necessary for the specific project.
79
The amount of workflows, activities and artifacts of the RUP and the amount of Work
streams, activities and work products of MSF4ASD is an immense difference. The
project members of the agile flavour of MSF have to execute seventy-six activities that
are classified in its fourteen work streams to create and update the twenty-four
prescribed work products. In contrast, RUP has fifty-five workflows with one hundred
and forty-eight activities that create, use and update sixty-nine artifacts during its
SDLC. Again, this shows that RUP is a more heavy and formal software engineering
process than the MSF4ASD. MSF4ASD not only leaves more freedom of movement for
the stakeholders in the field of outcome of the project, but also the process of the project
itself.
CONCLUSION
The vertical axis of the two graphical representations in Figure 5-7 represents the
workload of the project during the two software engineering processes. Both processes
work to the same goal, but the way the work is arranged and accomplished is different.
The Rational Unified Process is a more prescriptive process than the Microsoft Solution
Framework for Agile Software Development. RUP identifies every element that may be
useful in the software development project in great detail. This complete enumeration
enables the project members to manage and control the workload of the project, and
therefore enables the team to estimate and plan the project in time and costs down to the
minutest detail. On the other hand, MSF4ASD is more adaptive and is more able to
cope with changes than RUP. MSF4ASD leaves more room for stakeholders to change
their needs, expectations, and even the process.
The disciplines in RUP cover the advocacy groups of the agile MSF, but RUP adds two
more points of interest, namely the disciplines configuration & change management and
environment. The first is not explicitly mentioned in MSF4ASD but is woven into the
whole process. It believes in a collective mindset of the configuration & change
management and uses the JIT approach during the whole process. The amount of roles
in the two processes differs impressively, RUP has thirty-one and MSF4ASD has six
roles. The role arrangement of the team member in RUP is handled differently than the
MSF4ASD. To use RUP in an average project, the process has to be scaled down,
80
meaning that team members have more than one role or some roles are left out of the
project. To use MSF4ASD in an average project, the process has to be stretched out to
fit, meaning that possibly the project has to be divided into subprojects.
Table 5-6 The quantity of elements in the two processes
As shown in Table 5-6, IBM Rational describes their process in detail. RUP is a more
formal and strict process, that estimates the cost and time of the project, then plans the
whole project and focuses on keeping the project on track to reach the pre-agreed
destination. The agile SEP of Microsoft has less handles established to give the project
members more freedom to flavour the process to their own taste or need. The
MSF4ASD is the younger, more playful and unbridled little brother of the more serious,
rusted and grown-up software engineering process of IBM Rational, which leaves less
room for margins and ad hoc changes for the stakeholders in the end-product and
process, but is more capable of planning on time and costs.
5.5 CONCLUSION
RUP and MSF4ASD strive for the same objective, to guide the project team in creating
a solution that meets the needs plus expectations of the customer and therefore satisfy
the stakeholders. The way the two software engineering processes reach this goal has
common grounds and differences, in the field of the philosophy, focus in time and work
division. This section summarizes the results of the three comparisons by combining
and presenting them in the answer to Question 3, namely “When is the IBM Rational
Unified Process or the Microsoft Solutions Framework for Agile Software Development
more appropriate to use?”. Which project situation is more appropriate to use RUP and
which to use MSF4ASD?
RUP is a formal and heavy software engineering process that focuses on time and
budget planning, to be a predictive process, and uses iterations throughout the software
development life cycle to cope with changes that are inline with the scope and vision of
the project. RUP is suitable for relatively average to large sized projects, and when
creating critical systems with no room for mistakes or errors, like a big budget
development project for satellite control system. The project team consists of a
significant amount of members and has a hierarchic structured team model, from
dependent immature juniors to expensive seniors with a lot of experience. The customer
must have a clear idea of his solution to enable the stakeholders to identify and
document the requirements in the early stage of the software development life cycle.
These demands must be agreed upon to create a clear scope of the project, but the team
leaves some freedom of movement for the stakeholders to request modest changes.
These agreements enable a more predictive project that focuses on time schedules and
budget planning. This project situation has a clear distinct customer and project team
81
relationship, where the customer and the team do not have the ability or time for
continuous interaction. Therefore the communication is based on documentation and the
feedback is obtained during the periodically planned assessments.
MSF4ASD is an informal, ad hoc, and responsive software engineering process that

focuses less on time and budget, but more on result and the ability to cope with changes.
MSF4ASD is suitable for relatively small to average sized projects with uncertain
dependencies. For instance, the customer does not really know what he wants due to
lack of knowledge or the system must support a fluctuating business process. The
amount of team members must be minimal to create an agile environment, which is
quick to respond to changes. The team must consist of more experienced, responsible
and mature participants that are able to work autonomously as the MSF team model
prescribes a team of peers without hierarchic supervision. This agile process is
appropriate for project with a fuzzy scope and unclear requirements, because it focuses
on being adaptive to cope with a changing environment using ad hoc planning and
requirements identification. The relationship between the project stakeholders is based
on trust and not on strict documented agreements, due to the fact that this software
engineering process gives more emphasis to the changing demands of the system and
less to time schedules and budgets. There must be a close interaction between the
project team members and the customer with a continuous flow of feedback on the
results and room for a discussion what to do next. And there is a face-to-face based
communication among stakeholders to create more direct and responsive contact during
the software development life cycle.
82
Chapter 6
MICROSOFT VISUAL STUDIO
2005 TEAM SYSTEM
“Application development is carried out by teams with various roles.
Traditionally, these roles have been services by point solutions, producing
output specific to their creator but not linked to coordinate with each other.
This exaggerates communications gaps that tool manufacturers are now
closely considering by delivering collaborative development environments
that integrate across the life cycle” [26]
6.1 INTRODUCTION
This chapter answers research Question 4 by assaying the results of Chapter 5, the
common grounds and differences regarding RUP and MSF4ASD, to the Microsoft
Visual Studio 2005 Team System to examine how they are supported by this software
development platform.
As software development become more complex and the development teams become
more distributed, the point of attention of software development tools shift from a focus
on individual productivity to team productivity [26]. Software development platforms
support this shift by integrating the collaboration and process capabilities with full life-
cycle development environments. In other words, software development platforms is a
combination of the ‘traditional’ integrated development environment and SDLC
supporting tools, that support activities like modeling, versioning, testing, etcetera.
Traditional software development processes used ‘waterfall’ styles to proceed the

project from step to step, and at every step the product is handed off from one team of
specialists to the next. Nowadays, organizations are more interested to iterative and
agile software development methods. A key feature of these processes is an increase in
collaboration among all team members. However, the methods of software development
are changed in time, the majority of the software development tools support only the
traditional methods by focussing on increasing the productivity of the individual team
member. This results in superfluous miscommunication among all stakeholders and
inefficient development of the end product. A collaborative SEP can only be
implemented when the project is supported by a collaborative software engineering
platform. Although iterative and agile development practices have been proved to
improve development productivity and customer satisfaction, a lot of organizations have
trouble to implement them due to mismatching development environment, the lack of
support for providing management and metric information, and the lack functionality to
interact among the team members [26]. Modern software engineering processes are
more iterative and collaborative, but traditional tools are functional oriented. The
83
Chapter 6 | Microsoft Visual Studio 2005 Team System
productivity has been optimized for individual role steps, but not for the entire
development process. The product moves forward through the project on an assembly
line, where step by step a new individual with a new tool works on a new part of the
solution. The project stakeholders must metaphoric sit around the solution, as illustrated
in Figure 6-1, and not next to one another.
Figure 6-1 Customer’s solution position in the Microsoft Solution Framework
Software development platforms, like Microsoft Visual Studio 2005 Team System,
embrace the collaborative mindset to develop a solution as a team and not as a group of
individuals.
6.2 VISUAL STUDIO 2005 TEAM SYSTEM

Microsoft introduced in November 2005 the Microsoft Visual Studio 2005 Team
System as new software development platform (SDP), that support the whole software
development life cycle. Microsoft claims that “it combines the powerful new role-based
tools, customizable processes and guidance and an integrated server to help teams drive
predictability, visibility, and control into their software development process.”10. A SDP
brings the software engineering process to the developer’s working environment,
creates more communication facilities and insight of the project status and the work to
be done without jumping between different applications and writing various
configuration scripts [23], [25].
Visual Studio 2005 Team System consists of the Visual Studio 2005 Team Edition for
Software Architects, Visual Studio 2005 Team Edition for Software Developers, Visual
10
Source: http://msdn.microsoft.com/vstudio/teamsystem/products/
84
Studio 2005 Team Edition for Software Testers, Visual Studio 2005 Team Foundation
Server, Visual Studio 2005 Team Test Load Agent, and MSF process guidance [23].
Figure 6-2 Visual Studio 2005 Team System products and features arrangement
Visual Studio 2005 Team Suite is a SDP that enables the project team to design,
develop and test the solution in an integrated environment to improve project overview,
communication, and efficiency [23].
The VS Team Edition for Software Architects enables the team with the ability to
visually model the service oriented applications, and validate them to the IT
environments, to improve the productivity and identification of problems between
development and deployment early in the SEP. The VS Team Edition for Software
Developers provides the team with an advanced integrated development environment to
write quality source code for the solution by checking the grammar of the code,
identifying security issues, performing unit testing, and detecting code coverage. The
VS Team Edition for Software Testers provides the team with tools for testing the
quality of the solution early in the software development life cycle. The VS Team
Foundation Server is the heart of the SDP that enables the collaboration mindset of
VSTS. The VS Team Test Load Agent provides the team with extra test load capacity
for the using the VS Team Edition for Software Testers.
In the next sections, this thesis explains the main features of the Visual Studio 2005
Team System by examining the three Visual Studio editions and the Team Foundation
85
Server. Note that, this thesis describes the features that are supported in VSTS and does
not describe the features that are missing in the Microsoft software development
platform.
6.2.1 VISUAL STUDIO 2005 TEAM SYSTEM FOR ARCHITECTS

The team has to design the system before implementing the system code. The
architecture of the system helps the team to understand and gives them a clear overview
of the system. Therefore, a well defined architecture of the solution is a crucial element
of a software engineering process.
The team has little costs during the planning and designing phases, but the project team
is committing to a much larger costs for the rest of the lifetime of the system. Eight
percent of the budget spent during design locked down 80 percent of the lifetime
product cost [5]. Therefore the architecture has to be well modelled in a common
language. This enables to project team just to focus on relevant system information and
to improve communication within the team and with other stakeholders.
Visual Studio 2005 Team System for Architects facilitates the architect in the project
team to model the system in different views using the logical datacenter designer, the
application designer, system designer and the deployment designer. These tools, called
Distributed System Designers, are a set of design tools in the architect edition of the
Microsoft’s software development platform, and help the architect to visualize the
future system and communicate this to the rest of the project team.
VSTS embraces a visually model-driven approach to design the solution. Microsoft

feels that the wide accepted Unified Modeling Language is too general for design
purposes. VSTS supports the domain specific language (DSL) that more precisely
targets the domain of the solution and provides the project team with for DSL designer
tools, namely logical datacenter designer, application designer, system designer, and
deployment designer [23], [25]..
LOGICAL DATACENTER DESIGNER

In the VSTS for architect, the architect creates the logical datacenter diagram to map the
customer’s infrastructure using the logical datacenter designer. The based idea of the
logical datacenter diagram is to capture the customer’s logical structure for the purpose
of communicating important information to the developer about the target deployment
environment. When uploaded on the Visual Studio 2005 Team Foundation Server, this
diagram validates other architectural work products and the implemented code against
the constraints of the customer infrastructure. Note that, this diagram can be reused for
other projects for that customer.
An example of a logical datacenter diagram is depicted in Figure 6-3. In this example

the infrastructure of the customer is represented as zones, servers and a windows client.
A zone is a logical datacenter boundary (physical, security, communication etc.) or
security and a logical server describes the application hosting characteristics of a type of
server.
86
Figure 6-3 Example of a logical datacenter diagram
The architect does not create new structure rules for the network, but maps the existing
into the diagram. This diagram ensures that the solution respects the settings and
constraints and ensures compatibility with the customer’s logical infrastructure. VSTS
also validates the architecture of the application itself to the logical datacenter diagram
of the customer network infrastructure.
Summarizing, the logical datacenter diagram is the blueprint, settings and constraints of
the infrastructure on which the future solution is deployed, that makes sure that the
implementation actually can be implemented at the customer’s site.
APPLICATION DESIGNER
The application designer is used to define or visualize applications in a visual studio
solution. This distributed system designer allows the architect to design the
configuration of the applications and the interactions to each other. The application
diagram represents the high level architecture for your applications.
87
An example of an application diagram is illustrated in Figure 6-4, where a windows

application is connected to a database and a web application hits a webservice which
itself is connected to the database.
Figure 6-4 Example of an application diagram
As shown, the application designer is not designing one application in detail, but
diagrams the system as a whole to illustrate how the elements of a system are connected
to each other. The connections are the traffic flow of a high level design of the
application, the deployable pieces of the application. The architect also can set and
constraint each connections and element to restrict and scope the solution’s architecture.
VSTS enables the project team to generate all applications designed in the application
diagram. In the example, VSTS will generate a windows application project called
CalcWinApp, a web project called CalcWebsite and a webservice project called
CalcWebService with a webservice called CalcSercive into the solution of the example.
SYSTEM DESIGNER
The system designer is used to define a specific configuration of applications and other
systems. The application diagram shows the developers how the applications are
designed and how they can connect with each other on a high level. The system diagram
zooms in and describes the developers how the applications and their connections
should be. A portion of the example system is represented in the Figure 6-5.
88
Figure 6-5 Example of a system diagram
The benefit of the system diagram is that a portion of the overall solution can be singled
out to enable the project team to create different configuration of different deployment
environments.
DEPLOYMENT DESIGNER
The deployment designer is the fourth and final architect designer. The architect uses
this designer to describe a deployment of the system in the customer’s logical datacenter
by binding applications within the solution to logical servers defined in the logical
datacenter diagram. The project team validates the application diagram and the
implemented code against the logical infrastructure of the customer.
The elements of the application diagram in Figure 6-3 are put into the logical datacenter
diagram in Figure 6-4 and resulting in a deployment diagram that is depicted in Figure
6-6.
89
Figure 6-6 Example of a deployment diagram
The deployment designer allows the architect to model the deployment of the system
into representation of the customer’s infrastructure by dragging and dropping the
applications into the logical datacenter diagram. Binding the application architecture to
the logical infrastructural representation validates the architectural design that the
solution is deployable.
Visual Studio 2005 Team System for Architects allows the architect to model the high
level architecture of the future system using four distributed system designers. Visually
modeling the architecture enables a better communication between the architects and
the developers. The architecture is integrated throughout the whole software
engineering process and allows the architect to create overview, rules and constraints
for the development of the system and enables a better handling of changes in the
system architecture.
6.2.2 VISUAL STUDIO 2005 TEAM SYSTEM FOR DEVELOPERS

VSTS provides the developer with an advanced IDE and supporting tools. These
functionalities help the developer to increase his efficiency, decrease the chance of bugs
and clean up his source code. The Visual Studio 2005 Edition for Software Developers
provides the developer with extra tools besides the IDE called Visual Studio 2005
90
Professional Edition. Tools like the class designer to graphically create class files, the
static code analyzer to write consistent source code, the unit testing tool to validate the
source code, the code coverage tool to verify that every source code line is tested, and
the code profiler to check the performance of the source code [23], [25]..
Note that, many VSTS sources mentions the dynamic code analyzer as a feature of the
VS edition for Software Develops, while this analyzer is unit testing, code coverage and
performance tools together. This thesis describes them individually, so this dynamic
code analyzer is left out of this section [33].
CLASS DESIGNER
VSTS enables the user to implement the source code in two ways. Firstly, just by
writing the code into the class source code files. Secondly, by implementing the source
code using the class designer.
Visual Studio 2005 Team System provides the project team with a graphical interface,
called class designer, for creating source code without the knowledge of program
language. The class designer of the Microsoft software development platform enables
the project team to model the business logic layer visually in a class diagram, as
illustrated in Figure 6-7. The project team can use this graphical view for documentation
and communication purposes among the project stakeholders to better understand the
underlying class files. It should be said that the class designer only creates the general
source code of the class files by implementing methods, properties, events and the
associate parameters. The developer still needs to write the actual instruction code
within the method.
Figure 6-7 An example of a Class Diagram
The class diagram stores no source code to solve a lot of reverse modeling problems and
to ensure that the class diagram and the class code file are synchronized. Figure 6-8
shows the only XML code of the class diagram, with properties of the diagram, and the
name and location of the actual “calculator.cs” class file.
91
Figure 6-8 XML code of the class diagram
The class designer facilitates a more easy way to design and model the business logic
layer using class diagrams. This also creates documentation to communicate among all
stakeholders for a better understanding of the system’s business logic.
STATIC CODE ANALYZER

The quality of the system’s source code depends on various aspects. One of these
aspects is that the code is written inline with general code rules. Team members have to
write their code in the same way with the same rules to create a common way to
implement the system. Reviewing and ensuring that all the source code respects the
coding agreements of the team or system development organization is hard to do. VSTS
has a functionality that enables the team members to validate their source code
automatically to general coding rules or company specific coding rules. This static code
analyzer finds errors in the code before it is compiled. It has a range of checks: from
style to code correctness to security issues to validate the consistency of the
implemented source code, as presented in Figure 6-9.
92
Figure 6-9 Screenshot of the static code analyzer
The static code analyzer enables the team to import or create own validation rules. The
analyzer is also customizable on which checks or rules to include in the analysis,
whether to report as error or warning to set the severity of the inconsequentialities, and
supports the creations of own rules and checks. All together increases the quality of the
code as it is written in a common and consistent way.
CODE PROFILER
Code profiling is the process of finding the bottlenecks and roadblocks of the
application as an executable version. This functionality of the VSTS for developers has
the purpose to enable developers to measure the performance of an executable
application and identify issues in the source code. The developer has the ability to
analyze the time and memory spends of the application, like identifying which methods
or classes are using most of the execution time. After the code profiler reports its
finding, as shown in Figure 6-10, the developer is able to prioritize which parts of the
source code needs to be optimized first, and which not to spend his time on.
93
Figure 6-10 Example of a report of the Code Profiler
6.2.3 VISUAL STUDIO 2005 TEAM SYSTEM FOR TESTERS

This edition of the Visual Studio 2005 Team System is for the testers in the project
team. After the architect has designed the solution and the developers created a build,
the tester has to validate the quality, performance and correctness of the product to meet
the customer’s expectations. The Visual Studio 2005 Team Edition for Software Testers
supports four types of tests, namely unit, manual, web, and load testing, which are
organized using the Test Manager of the Microsoft’s SPD.
The team can code and store the tests in projects within the solution, like the normal
source code projects. These test projects are designed to provide a container to hold all
tests. This interpretation offers tests the same functionalities as the source project
receive of VSTS. For example, the tests are placed in the source code control, can be
linked to work items, and the test results are saved on the foundation server for other
team members to review [23], [25].
In this section of the thesis describes the main functionalities of the test edition of VSTS
by creating and executing the four types of tests, organizing them in the test manager,
and explaining the results.
UNIT TESTING
After implementing the first method into the source code of the system, the developer
and/or tester has the opportunity to test its correctness by creating a unit test. A unit test
is a functional class method test by calling a method with the appropriate parameters,
exercise it and compare the results with the expected outcome to ensure the correctness
of the implemented code.
94
A unit testing functionality is built in VSTS, which enables the team to write and run
units tests. This way of testing the system creates an overlap of tasks and knowledge of
the developer and the tester role, because the tests are written using the same code as the
actual system source code. Normally, these unit tests are integrated in the system
solution as a project and just like the source code of the system, the unit testing code is
stored onto the team foundation server.
VSTS has the functionality to automatically generate unit test methods during the
implementation of the system class methods. Note that, VSTS creates classes with
testmethods and initiates variables, but the project team needs to refine these methods to
be useful tests. Figure 6-11 shows the generated unit test for validating the “Add”-
method of the calculator example.
Figure 6-11 Example of a generated unit testmethod
The generated code has to be revised to be a functional unit test for the “add”-method.
VSTS attends the user that variable a, b and expected has to be initialized to an
appropriate value. For example a is set on 20, b on 44 and expected on 64. If the actual
implemented method does not match the expected value, this test method will alert the
user with the error “CalcLogic.Calculator.Add did not return the expected value”. Note
that, VSTS adds the last code line to inform the user that this unit test is not revised and
may not be correct.
MANUAL TESTING
The oldest way to verify the correctness of the implemented code is the manual test. A
manual test is a list of test activities with descriptions that a tester performs step by step.
A project team uses manual tests, as portrayed in Figure 6-12, when the test steps are
complicated or unfit to be automated. An example of a test situation where a team may
95
decide to use a manual test is when they want to determine a component's behaviour
when network connectivity is lost.
Figure 6-12 An example of a manual test
The manual test in the Microsoft’s project development platform is in either MS Word
or text format as scripts for manual testing tasks. VSTS treats manual tests the same as
automated tests, they are checked in/out and is stored in the source control repository on
the Visual Studio 2005 Team Foundation Server, they are managed and run in the test
manager and the test results are shown in the test result explorer. As the manual test is
started in the test manager, the manual test description is shown as in Figure 6-12. It
will keep on the status ‘pending’ as the tester steps through the prescribed activities
until the he selects the result of the test. If the test fails, the tester is able to create a bug
work item to report the bug and associate this test to the work item.
WEB TESTING
Web testing is integrated into Visual Studio 2005 Team Edition for Software Testers to
verify the quality of web applications. A web test allows the tester to automate the
testing of a web-based application or interface by coding or recording the user and web
browser interactions into editable scripts.
VSTS supports two different types of web testing, the recorded and coded web test.
The first type of web test records the HTTP-traffic of the web application into editable
scripts, which enables the tester to play back the interactions. The tester can check web
page access, content or response by adding validation rules to the recorded web test.
96
Figure 6-13 shows the results of an executed recorded web test of the calculator
solution, where the user has loaded the webpage and hit the buttons after entering the
numbers 10 and 5 in the textboxes.
Figure 6-13 Example of a recorded web test
Each HTTP-traffic is recorded as a test line, which the tester can modify and enhance by
adding validation rules. In this example, four validations rules were added to check the
outcome of the four functions of the calculator. As shown in Figure 6-13 the third
“minus” test line fails, because the expected value of the result textbox in the validation
rule was not 3 but 5. Also, the VSTS facilitates the user to generate coded web tests out
of recorded web tests to be modified in more complex web tests. Just like the other tests,
the web tests are stored in test projects and are check in and out to the source code
control.
LOAD TESTING
The idea behind the load test is simulating that multiple users execute the logic of the
solution simultaneously. The primary goal of the load test is to discover scalability and
performance issues in the solution. Testing the solution also gives benchmark statistics
on performance as the solution modified or extended.
The tester creates a load test in the VSTS environment using a wizard that steps through
the process of defining a load test scenario. A scenario is a certain situation of the use of
97
the application and is defined with a load pattern, test mix, browser mix, and network
mix.
The load pattern defines how the load is applied to the application and has two flavours,
a constant and a step load definition. The constant load definition applies a continuous
load of users on the applications. For example, when the tester sets the maximum user
count setting on 50, the load test continuously simulates 50 users stressing out the
applications. This option is useful for peak usage testing and stability testing to see how
the system performs under constant peak stress. The step load definition starts the load
test with a small number of users and adds a predefined amount each step until the
maximum is reached, or the system performs badly, or the solution falls over. This
option is suitable for testing the performance limitations of the system, like the
maximum number of users is before the system falls.
The test mix defines which tests are included in the load test and how they are
distributed. The tester can select all the automated test types that are stored in the test
projects of the solution. When selecting more than one test, the tester needs to define
what percentage of the total load capacity should be executing each test, as shown in
Figure 6-14.
Figure 6-14 The New Load Test Wizard
The browser mix to define the kinds of browser to use for web tests. The browsers types
include various versions of Microsoft Internet Explorer, Netscape, Mozilla, Pocket
Internet Explorer, and smartphones profiles. The network mix defines the kinds of
network types are simulated, and ranges from LAN, dial-up through T3 connections for
the load test. After finishing the New Load Test Wizard, VSTS gives the tester an
overview of all properties of the load test as depicted in Figure 6-15.
98
Figure 6-15 Overview of a load test example
After defining the way to test the load on the system, the tester needs to identify what
information is important to collect during the test. Setting these so called counter sets is
a difficult task of the tester. Fortunately VSTS provides default counter sets to simplify
the creation of the load test.
Finally, the tester has to set the load test’s Run Settings, where it is decided how much
time the test needs to warm up, how long the test runs, and what the sample rate is. The
warming up time is the time between the start of the test and the first sample to be taken
of the counters. For example, the system starts slow the first minute due to the lack of
caching files and the tester does not want this warming up to influence the test results.
The sample rate is the time interval how often the counters are sampled. For instance,
the tester prescribes VSTS to take test data samples of the counters every ten seconds.
During the execution of the load test, the tester is able to monitor the counters in real
time and add or remove counters. The tests results, as shown in Figure 6-16, are
presented in tables and graphs, which also can be modified during the test run by adding
or removing counters.
99
Figure 6-16 The results of a load test
The test results are stored in a database or XML-file on the Visual Studio Team
Foundation Server to be available to all the team members or other stakeholders. From a
failed test, a tester is able to create a bug work item that is linked to these test results to
be addressed to a developer. The VSTS project portal website provides the managers
and other team members with extensive test and bug-tracking reports to track bug work
items.
TEST MANAGER
After the creation of the appropriate tests, one uses the test manager, as depicted in
Figure 6-17, to organize them in test lists. This allows the user to group and categorize
tests and execute them in an appropriate order.
100
Figure 6-17 The test manager and test results
Figure 6-17 shows that the test manager has a tree structure of the lists of all tests, like
load, manual, and unit test. New lists with different test or order can be created to
validate the written source code in different ways and angle. Figure 6-17 also shows the
test results of the checked tests in the test manager, where one of tests failed to pass due
to the error that the expected and actual outcome of the “MultiplyTest”-method are not
equal. As already mentioned earlier in this chapter, the user is now able to create a new
bug work item to inform the responsible team member to fix this error.
CODE COVERAGE
The code coverage functionality enables the software development team to see which
lines of code are touched during the tests to grade the quality of the tests and its results.
For example, a class file contains thousand lines of code and the tests only touches fifty
percent of them, the test and its results may not be as accurate as the team want it to be.
The code coverage functionality, as shown in Figure 6-18, is kind of quality indicator of
the tests in the system development project, and answers the question how much of the
source code are tested.
101
Figure 6-18 Code coverage in percentage and graphical representation
VSTS uses the code coverage functionality to inform the project team in percentage and
graphically how many lines of code is activated while running the tests. The project
manager may use this code coverage percentage as a check in policy to ensure better
code quality. For example, the class source code must run a number of unit tests and the
code coverage percentage must be over 80 to check in the source files onto the team
foundation server.
6.2.4 VISUAL STUDIO 2005 TEAM FOUNDATION SERVER

“Team Foundation Server (TFS) in Visual Studio Team System provides a cohesive
platform for software development and collaboration because it incorporates process
management, work item tracking, source code control, build automation, testing and
team controls with centralized reporting.”[23]
In other words, The Microsoft Visual Studio 2005 Team Foundation Server (TFS) is the
heart of the VSTS. It is the central organ of the software development projects that
stores and binds all information, sources, and documentation together to facilitate
project teams with better collaboration and communication opportunities. The Visual
Studio 2005 Team Foundation Server (TFS) is the collaboration hub of VSTS. It is the
102
central repository for your team assets and consists of four pillars and one reporting
element generates the information of the components, as presented graphically in Figure
6-19.
Figure 6-19 Elements of Team Foundation Server
PROJECT MANAGEMENT
In short, project management is tracking what is going on in the software development
project. A project manager wants to know what the other team members are doing to
plan, guide and predict the rest of the SEP. The project manager has to inquire the status
of the project; where are we and what should we do next? Are we still on the right
track? Are we meeting the requirements? Is this project failing? To answers these
questions, the project manager has have all kinds of lists; list of requirements, change
requests, customer requests, issues lists, bugs, et cetera. The MSF4ASD prescribes five
work items, namely a scenario, quality of service requirement, task, bug, and risk. The
Visual Studio software development platform enables the project team to record these
elements as work items centrally on the Visual Studio 2005 Team Foundation Server
[23], [25].
A project manager uses the work item lists to verify the status of the project, like the
amount of scenarios that need to be implemented or the amount of bugs that are need to
be solved. The project manager has the ability to organize the work of the project in
three ways, using the Team Explorer of VSTS, using MS Excel, or using MS Project.
VSTS has a pane within the IDE, named Team Explorer, which enables the team to
manage, view and change these work items using the VSTS Team Explorer, as
illustrated in Figure 6-20.
103
Figure 6-20 Work items in VSTS
The different queries on the work item database on the TFS present the team members
the relevant work items and its properties, such as title, date status, and name of the
team member that is responsible for the item. For example, the team explorer gives the
tester the ability to add a new bug work item, the developer the notification for fixing
this bug, and the project manager the information of the status of the bug.
As one can imagine, a project manager may dislike the use of the heavy SDP to manage
the work items. Therefore, VSTS has integrated MS Excel and MS Project to give the
project team the capability to organize the work items and to plan the project without
Visual Studio knowledge. As one can imagine, it is faster and easier to adjust work
items in MS Excel, as shown in Figure 6-21.
104
Figure 6-21 Work item list in MS Excel
Work items can be linked to each other or documents at the SharePoint site. For
example, a requirement work item can be linked to a scenario description or a bug work
item to a source code file. Another feature is the possibility to attach files to a work
item, like importing a screenshot of an error into a bug work item.
WORK ITEM TRACKING

As described in Chapter 4, a work item is an actionable unit of information that is
produced, modified, or used by a role or person of a software development team during
the execution of an activity. As the project team passes through the various stages of the
software engineering process, work items change, resolve or arise. This section explains
with a bug related example how VSTS facilitates the team with the dynamics of
changing and tracking work items during the development of a solution to improve the
project’s change management.
A tester discovers an error in the system, and therefore adds a bug work item to the team
project, as shown in Figure 6-22, with a description, assigns it to a specific developer,
gives a certain priority and adds a screenshot of the error.
Figure 6-22 Adding a work item
105
As the tester adds the work item, the rest of the team will be informed as well about this
work item. A developer can see this new bug, retrieve its information, possibly fix it,
state the bug as resolved, and give it back to the tester, who ensures that the bug is fixed
and then closes the bug. These state-changes of the bug work item are illustrated in
Figure 6-23.
Figure 6-23 Activities tracked by bug work item
As a work item alters during the SEP, it is important for the team to be able to track its
properties, like which user changed the work item on what date and time to which state
and for what reason. Visual Studio Team Foundation Server stores all the properties of
all work items in a database to give the team members the ability to track the transition
history of the work item in TFS, as shown in Figure 6-24.
Figure 6-24 Work item state history
The history of the work items can be viewed in the work item pane in the Visual Studio
IDE or using the web-based report manager, which is described later on this chapter.
SOURCE CODE CONTROL

VSTS enables the project team to build and manage multiple version of the solution at
the same time and enables developers to work on the same file simultaneously by
facilitating the team with a source code control functionality. The Team Foundation
Server’s Source Code Control has four primary features to support large, distributed
development teams working parallel at multiple projects, namely checking, branching,
merging, and shelving.
106
First feature is the checking in and out of the project files. A project team that consists
of multiple individuals and work together on the same solution needs to know who is
working and changing which classes, documents, or diagrams. The TFS controls who is
doing what to which file by prescribing that all the files that are stored on the TFS need
to be checked out of the TFS and a copy is stored on the individual workspace until the
files are checked in back on the TFS. For example, a developer wants to fix a bug that is
assigned to him and needs the relevant source code files and then check out these files
of the TFS. After he has fixed the bug, he changes the state of the bug work item into
resolved and then checks in the source file back on the TFS. VSTS not only combines
the source changes, the developer has the ability to give comments on his changes,
relates a work item to his changes, and as selected a notification of his check in is send
to the team members. VSTS facilitates the project manager to write so called check-in
policies to control the check in. These policies are rules that prescribe team members
what to do before checking in their changed files. For example, the changed source code
files need to pass test A and test B before the developer is allowed to check them in on
the TFS. If the developer is not able to check in his work, he has to opportunity to
shelve his work on the TFS, meaning that it is not officially checked in, but other team
members are allowed to unshelve it and improve it until it can be checked in. The ability
to set the unsuitable files, called a shelveset, aside on a shelf for later usage is the
second main feature of the source code control.
Other features of the source code control of the TFS are branching and merging.
Branching is to copy and backup a set of projects of the solution on the TFS, including a
version control, history, comments and all other project properties. This capability
allows multiple builds and release to be maintained efficiently and in the same overall
solution. The Visual Source Control Explorer enables team members to easily work
simultaneously on different branches a.k.a. versions of the solution, making different
revisions on different branches as illustrated in Figure 6-25.
Figure 6-25 Branching and Merging
Merging is the functionality in TFS that reconciles all changes made in one branch into
another branch. For example, when a bug fixed in branch 2.1.1 of the solution, the team
is able to merge this change into the targeted branch 2.2 automatically, as depicted in
Figure 6-25. Note that, TFS stores the project files, history and other properties to be
able to merge not only by blending code together, but also by merging additions,
deletions, undeletions, and renames from the source branch to the target branch.
107
BUILD AUTOMATION
A build is the compilation of all files, libraries, or components into a new set of
executables, libraries, or components. Development teams create builds to deploy them
into the customer environment, but most likely they create a build to verify that all files,
libraries and components that are check in onto the TFS by different individual team
members are able to work together as one solution. VSTS enables the team to manually
create a build using the Visual Studio IDE or create a full automated build solution with
the Team Build tooling. The project team has the opportunity to verify the check-ins
daily by running the build process, as shown in Figure 6-26, during the night and
checking the results the next day.
Figure 6-26 The build process
The build process on the build server is initialized manually or on a timely schedule.
Once VSTS triggers the team build server to build, generates a build name and retrieves
the right data and files from the team foundation server using the source control system.
The build server then compiles the solution and does a static code analysis to
consistency and quality of the code. Once the solution is compiled and did not fail the
static code analysis, the build server executes the tests that are defined in the build
script. The team is able to select all types of tests, except the manual test type, to be
executed during the build process. Once the solution passes these tests, related work
items are updated on the foundation team server and the code coverage and code churn
are calculated. Code churn is a percentage of how many lines of code are changed
compared to the previous version to shows the project team how healthy the source code
is. For instance, the more code has changed going from build A to build B, the less
stable and mature the overall system is. Finally, the test results, code coverage, code
churn and other build details are produced and represented in the build report, and the
build is published into the project environment. Summarizing, VSTS’s build manager
108
facilitates the project team to produce automatic daily builds of the solution, with
analyzing, testing, and reporting abilities, to reach a higher level of quality.
REPORTING
The views of the information on the TFS are role-driven, meaning that each role gets its
own relevant information and is not disorganised by irrelevant data of the development
process. The information is reported using the Team Explorer, Windows SharePoint
Services11 project portal, Microsoft Excel and Microsoft Project12 to create an insight
into the software development life cycle and to react on changes in the SEP [23]. The
reports are based on data from tool activity that is stored on the Visual Studio 2005
Team Foundation Server, like information of work items, version control, team builds,
and test results.
Team members who are using the one of Visual Studio Edition are able to reach the
reports that are facilitated by the chosen SEP via the Team Explorer, as shown in Figure
6-27. Note that, different SEP means possibly different reports.
Figure 6-27 The Team Explorer Reports
11
Windows SharePoint Services allows teams to create Web sites for information sharing and document
collaboration, benefits that help increase individual and team productivity. Windows SharePoint Services
is a component of the Windows Server 2003 information worker infrastructure and provides team
services and sites to Microsoft Office System and other desktop programs. It also serves as a platform for
application development. Including such IT resources as portals, team workspaces, e-mail, presence
awareness, and Web-based conferencing, Windows SharePoint Services enables users to locate
distributed information quickly and efficiently, as well as connect to and work with others more
productively. Source: http://www.microsoft.com/windowsserver2003/techinfo/sharepoint/overview.mspx
12
Microsoft Project (or MSP) is a project management software program developed and sold by
Microsoft which is designed to assist project managers in developing plans, assigning resources to tasks,
tracking progress, managing budgets and analyzing workloads. Source:
http://en.wikipedia.org/wiki/Microsoft_Project
109
Another way to reach the reports to analyze the state and health of the project is through
the report manager. Figure 6-28 shows the report manager’s main page with the
standard reports that are prescribed by the chosen SEP, namely the MSF4ASD process.
The information is presented in the reports textually and graphically as depicted in
Figure 6-29.
Figure 6-28 The Report Manager
As Figure 6-28 also is showing is that VSTS provides the team members with report
builder to create own customable reports and add them to the software engineering
process template. The user walks though a wizard to generate the correct queries for
retrieving the correct information from the TFS databases, and uses a report designing
to custom the standard report design.
110
Figure 6-29 Graphical representation of the bug rates
The most sophisticated way to retrieve information from the TFS is through the
advanced project portal. Note that every project has its own portal. Figure 6-30 gives an
idea about the graphical user interface of the Windows SharePoint Services team portal.
111
Figure 6-30 A Windows SharePoint Services project portal
The project portal is a browser-based sharing and collaboration tool that enables the
team to store and share files, have discussion forms, post announcements, and is strong
integrated with Microsoft Office 2003. In other words, it is a customizable dynamic
content project portal based on Windows SharePoint Services to enables users to create
and manage their own project sites and document repositories.
The Visual Studio 2005 Team Foundation Server is the glue that sticks all team
members with all their information together. It is the collaboration centre of the Visual
Studio Team System that enables the real benefits of the collective software
development as it is the central repository for all the team assets.
112
6.3 BEST PRINCIPLES

Microsoft claims to fully support the software engineering process. The previous
sections describe the functionalities and the possibilities of the Visual Studio software
development platform. This section of the thesis researches how VSTS supports the ten
‘best principles’, as listed in Table 6-1, that are identified in Chapter 5 as the ten overall
mindset of RUP and MSF.
Table 6-1 The ten Best Principles
ITERATIVE SOFTWARE DEVELOPMENT

Iterative software development allows a project to progress in small controlled steps to
cope with the fact that stakeholders, even the customer itself, progressive understand the
problem.
VSTS supports iterative software development on various methods. As the project team
initialize the SEP in VSTS, it has the ability to divide the SDLC in various iterations,
and assign work items to certain iterations and or areas using VSTS or MS Project, as
captured in Figure 6-31. The iterations represent the lifecycle stages into which a project
is divided such as planning, envisioning, development, etc. The areas represent a logical
division of project into feature areas and components. For example, the team divides the
project tasks as per logical architecture, like user interface layer, business layer and data
access layer.
Figure 6-31 Microsoft Project planning
113
The software developers are enabled with the ability to test early and frequent via unit
testing, while checking in and out the source code files onto the TFS. VSTS makes it
possible for the project team to create an automatically build process, that can be
executed on a timely schedule, for instance during the night. This ensures a stepwise
creating and validating software engineering process.
REQUIREMENTS MANAGEMENT
As a new project is setup in the VSTS, the project team has to choose which SEP is
used during the software development life cycle. After this initialization, VSTS creates
default work item as they are prescribes in the process template. Team members have
the ability to manage the requirements by adding new work items into the project and
changing the properties of work items using the Team Explorer, MS Excel, or MS
Project. These work items are centrally stored on the TFS to be distributed to all the
team members. Another requirements management feature is for the project manager to
set a check-in policy that forces team members link a work item to the files when
checking them in on the TFS.
COMPONENT-BASED ARCHITECTURE
VSTS provides the project team in the Visual Studio edition for Software Architects
with four architectural designers, namely the logical datacenter designer, application
designer, system designer, and deployment designer. The architect uses these distributed
system designers to create component-based architectural diagrams, which helps the
team to develop a blueprint of the solution before it is implemented in source code files.
The designers have the ability to generate source code files out of the diagrams and
interconnected the component-based diagrams and models to each other and to the
source code files that they represent. These connections control and check the developer
to write source code that is consistent with the component-based architecture of the
solution.
VISUAL MODELING
The Microsoft software development platform embraces the domain specific language
to design and model the solution using the distributed system designers. Other visual
modeling feature of VSTS is the class designer that makes possible to visually create the
source code of class files. The result is a class diagram that is a graphical representation
of the code structure in the class file. The graphical outputs of the designers are
distributed via the TFS to all stakeholders to work as a communication instrument to
explain the answer to the customer’s problem.
QUALITY ASSURANCE MANAGEMENT

VSTS provide the project team with many features to improve the quality of the
solution. By means of preventive, detective and corrective measures VSTS assures the
team members that they on the right track.
114
The functionalities as static code analysis, unit testing, and code profiles give the
developer more surety that his implemented source code is correct, clean and performs
inline with the quality of service requirements. The tester uses the test manager to
create, organize and execute all tests types, like unit tests, load test, manual tests, web
tests, to identify bugs and other performance issues. The team even can test the tests by
using the code coverage tool to ensure that an acceptable percentage of the source code
is tested. Note that, VSTS not only allows the tester to validate the quality, also the
developer is facilitated with testing tools to assure the quality of the solution. The ability
to create check in policies gives the team an extra assurance that the items on the TFS
have the right level of quality.
CHANGE MANAGEMENT
As changes occur during the software engineering process, two key elements of the SEP
changes along, namely the activities and task of the project team changes, and as the
work changes the files of the solution changes.
The team effort is represented in VSTS as work items which are centrally stored on the
Team Foundation Server and team members use the team explorer to look inside this
repository to see what work should be done. When a team member adds or edits a work
item, others will be informed as everybody uses the same information source. TFS also
records all changes that are made on the work item repository, to facilitate the team with
the history of the work items.
The Visual Studio 2005 Team Foundation Server has the capability to manage changes
to the solution itself using the source control system. This source control manages the
different versions of the source code, diagrams, and other files as changes are made to
the solution by the usage of the checking, branching, merging, and shelving
functionalities, as explained in the previous section of this chapter. Just like the work
items, the history of the changes on the different versions of solution is recorded to
enable the team to look back at the past.
CUSTOMER INVOLVEMENT
The software development team must have close interaction on a regularly basis with
the customer, just like Rational Unified Process and Microsoft Solution Framework
prescribes. The VSTS itself is a software development platform, which itself is not
appropriate to install at the customer sites. The customer just wants to know the status
of the project, like are there many bugs to fix or in which iteration is the project, and do
not want to set up a large SDP. VSTS only enables casual stakeholders to download the
team explorer as a lightweight standalone interface to the VS Team Foundation Server
to check in documentation, and read the project reports.
OPEN COMMUNICATION
Microsoft has build VSTS with a couple of mindsets. One is to improve the
communication within the software development team using one primary Visual Studio
environment. VSTS integrates the all kinds of messaging types, like requirements, tasks,
115
changes, accomplished work, announcements and bugs, into the team’s IDE. As all
files, diagrams, documentation and reports are stored centrally on the Visual Studio
2005 Team Foundation Server, all team members has the same sources and views and
use the identical open reporting tools, like team explorer, project portal.
Figure 6-32 Central information
Summarizing, as all team members are able to use the same repository, all information
is consist. As all team members are able to use the same reporting tools to view the
information, VSTS enables open communication.
SHARED VISION
All stakeholders need a shared vision to be able to work together as a team towards the
same goal. Therefore, everyone has to participate in the creation of that shared vision to
ensure that everyone understand and emphasize the same goals and ideas of the end-
solution. VSTS does not directly support the participation of all stakeholders to create
the vision documentation. VSTS does support open communication to inform and share
the targets of the solution to every stakeholder. The MSF processes, agile and CMMI,
that are available provides the team with template vision documentation, which can be
distributed to all team members, customers and other stakeholders.
VALUE ADDING ACTIVITIES

This best principle is supported by VSTS in two different ways. First one is the ability
for the project manager to organize and prioritize the work items of the solution. This
means that the project manager has to know what activities or work item adds the most
value. The project manager gets informed by the other team members as they are able to
modify the properties of the work item, like writing comments, and even filling in their
estimation how much time it takes to finish the item.
Another way, VSTS addresses activities that add value to the project is the code profiler
feature. This performance testing tool identifies the bottlenecks and roadblocks of the
compiled executable application. As the problems are presented, the developer is able to
prioritize which parts of the source code needs to be optimized first, and which parts he
does not need to spend his time on. For example, a class file has two method one small
and one big method. Normally, one may think to optimize the large method, but if the
116
code profiler reports that the small method is executed a lot and the other method just
one time, it is more interesting to optimize the small method.
6.4 CONCLUSION
The Microsoft Visual Studio 2005 Team Foundation Server is the heart of the software
development platform that provide the Team System editions with the correct
documents, libraries, source code files and other information. It enables the project team
to build and manage multiple version of the solution at the same time and enables
developers to work on the same file simultaneously by facilitating the team with a
source code control functionality. It provides the team with a central repository to
provide shared information and univocal communication to enable requirements and
change management. Visual Studio 2005 Team Edition for Software Architects
provides the team with features to visually model a component-based architecture. The
architect is able to design a blue print using diagrams to reduce the complexity of the
system, and to direct the project team while developing the solution. Visual Studio 2005
Team Edition for Software Developers facilitates the team besides the Visual Studio
2005 Professional IDE, with quality assurance functionalities. The developer is able to
run unit tests, and use the static code analyzer and code profiler to write orderly and
correct source code. Visual Studio 2005 Team Edition for Software Testers offers the
team with test tooling to verify the correctness and performance of the implemented
scenarios and quality of service requirements. The code coverage controls the quality of
the tests, like unit tests, web tests, and load test, and the test manager organizes them
into lists to execute them orderly.
Table 6-2 reflects the answer of research Question 4 : How are these common grounds
and differences supported by Microsoft Visual Studio 2005 Team System? The rating is
carried out by giving points to each of the ten best principles, where 1 represents a
weak, 2 a moderate, and 3 a strong level of the support in VSTS.
Table 6-2 The results of Question 4
As Table 6-2 illustrates, as already mentioned, VSTS well supports requirements

management, component-based architecture, quality assurance management, and change
management. The customer involvement and shared vision are supported at a minimum
level. Customer involvement and shared vision are best principles that are unsuitable to
117
be fully automated. Customer involvement implies the relationship between the project
team and customer. The shared vision implies one overall idea of the future system that
is accepted by all stakeholders.
Microsoft Visual Studio 2005 Team System is a software development platform that
supports most of the software development life cycle. It supports collaboration across
team members and software engineering process, and facilitates the ability to measure
and manage projects, boosting overall productivity and customer satisfaction.
118
Chapter 7
CONCLUDING REMARKS
A software engineering process is a process that describes who is doing what, how and
when in a project aiming at developing software. A process that provides guidance to
order the team's activities, to specify which artifacts should be developed and when they
should be developed, directs the tasks of individual developers and the team as a whole,
and offers criteria for monitoring and measuring the project's products and activities.
This thesis explains in great detail the IBM Rational Unified Process and the Microsoft
Solution Framework for Agile Software Development and identifies the common
grounds and differences between the two software engineering processes. These results
show when one is more appropriate to use than the other and how they are supported in
Microsoft Visual Studio 2005 Team System.
7.1 CONCLUSIONS
At the beginning of the thesis, in Chapter 1, we did ask four research questions. This
section summarizes the findings and gives the answers to the four research questions
that this research came up with in the different chapters of this dissertation.
Question 1: What are the IBM Rational Unified Process and the Microsoft
Solutions Framework for Agile Software Development?
In Chapter 2 this thesis described three procedures for developing a system, namely the
sequential, iterative and agile process, as an introduction to the two software
engineering processes.
The IBM Rational Unified Process description in Chapter 3 answers the first part of
research Question 1. RUP is an iterative software engineering process, which guides a
project team to produce a high quality solution that meets the needs and expectations of
the stakeholders within predictable time and budget plans. The guidance consists of ten
essentials, six best practices and a knowledge base website to articulate the thoughts and
beliefs of iterative software development.
RUP is a strict and formal process that arranges the project time in phases and iterations,
and the project labour in disciplines, workflows, activities, artifacts and roles to divide
the lifecycle into segments in order to create an iterative software development
environment. RUP focuses on time and budget planning to have a predictive process,
and uses iterations to cope with changes that are inline with the scope of the project
throughout the software development life cycle. The team develops the system on the
119
Chapter 7 | Concluding Remarks
basis of component based architecture and communicates on a need-to-know basis,

mainly based on documents. The customer and end-users evaluate the product to
provide feedback and request for changes on scheduled periodic iteration assessments.
These changes are well managed and restricted by formulated project boundaries that
are agreed upon in the early phase of the process.
Chapter 4 studied the Microsoft Solution Framework for Agile Software Development
to answer the second part of research Question 1. The MSF4ASD is a flexible and
informal software engineering process to maximally support the will of the customer to
create a business value adding solution. This agile flavour of the MSF believes that
system development is a creative process with uncertainties, which causes stakeholders
to understand their solution progressively in time. One of the interviewees expressed
this as followed, “Two weeks after the system deployment, the customer knows what he
really wants.”. MSF4ASD consists of foundation principles, team model and process
template to grow an agile mindset within the project development team.
The MSF4ASD is an informal and responsive software engineering process that
arranges the project time in tracks and cycles, and the project labour in advocacy
groups, work streams, work items and roles to divide the project in small work tasks to
create a flexible environment that focuses on ad hoc planning and requirements
management to cope with changes. This SEP considers change requests as a fact and
therefore minimizes the need to identify requirements and fully design the architecture
in advanced, as the project team builds the product incrementally and ad hoc.
MSF4ASD defines customer involvement using face-to-face communication with a
continuously flow of feedback to create a situation, where changes can be made all the
time. The iterative software development, continuous customer involvement, the equal
status of team members and open face-to-face communication allows the environment
to be agile.
Question 2: What are the common grounds and differences regarding the IBM
Rational Unified Process and the Microsoft Solutions Framework for Agile
Software Development?
RUP and MSF4ASD both guide the project team in creating a solution that meets the
needs of the customer to satisfy the stakeholders, but they differ in beliefs and process.
Chapter 5 compares the two software engineering processes in three ways, namely the
philosophy, the focus in time and work division of the SEPs.
120
The results of the comparative study show that RUP and MSF4ASD have overall
common grounds, this because they both are software engineering processes which
covers the same pathway using iterative software development to aim for the same goal,
namely to satisfy the need of the customer.
The differences between RUP and MSF4ASD are:
RUP is (1) a formal, strict and heavy software engineering process that wants to (2)
identify the requirements and architecture early in the process to be able to (3) focus on
planning the time schedules and budget to create (4) a predictive and ordered software
development environment.
MSF4ASD is (1) an informal, loosely, and light software engineering process that (2)
embraces ad hoc requirements management and architecture design to (3) facilitate the
ability to cope with changes to create (4) an adaptive and responsive environment.
Question 3: When is the IBM Rational Unified Process or the Microsoft Solutions
Framework for Agile Software Development more appropriate to use?
This thesis uses the results of research Question 2 to study which of the two software
engineering processes tends to be more appropriate for what kind of project. In Chapter
5 this thesis portrays two project descriptions, each with their own characterizations, to
explain when RUP and when MSF4ASD is more appropriate to be used as a software
engineering process.
The IBM Rational Unified Process is suitable for software development projects with
the following characterizations:
A project with a normal to large scope that needs a strict, formal and predictable
process which focuses on planning, fixed deadlines and budgets.
The team model has a hierarchic structure to control the average to large number of
persons in the project team.
The customer knows his demands, needs and expectations to create a business value
adding system. He is acquainted with the technological possibilities and boundaries.
The stakeholders are able to create a clear vision, identify stable requirements and
design a firm architecture in the early phases of the SEP.
RUP prescribes a strict change management to control the alterations and keep them
within the agreed project boundaries. The stakeholders are sure that the fixed
agreements will not change dramatically.
The customer and project team have a formal business relationship with a need for
lots of documentations. They do not have the time or capacity to interact closely and
therefore plan periodic meetings to exchange information and feedback.
121
The Microsoft Solutions Framework for Agile Software Development is suitable for
software development projects with the following characterizations:
A project with small to normal scope that needs a flexible, informal and adaptive
process which focuses on the needs and expectations of all stakeholders.
The project team has no clear hierarchic structure because the team is relative small
and the team members are skilled, have a great sense of responsibility and are able to
work autonomous.
The customer does not exactly know what he wants. His needs and expectations of
the solution are bound to change, as he is unfamiliar with the possibilities of the
technology, or how the system will support his business processes.
The requirements and architecture are uncertain and identified progressively during
the software development life cycle due to progressive understanding.
Customer and project team are closely connected and have a tight and truthful
relationship. They collaborate and use face-to-face communication to create the
mutual end result without the need for strict agreements and documentations.
Question 4: How are these common grounds and differences supported by

Microsoft Visual Studio 2005 Team System?
In Chapter 6 the Microsoft Visual Studio 2005 Team System is described in detail and
analyzed on how it supports the best principles of Chapter 5.
The best principles that embrace the adaptive mindset are well supported in VSTS. The
Microsoft Visual Studio 2005 Team Foundation Server has well defined requirements
management and change management functionalities, like source code control and work
item tracking. The Microsoft Visual Studio 2005 Edition for Software Architects gives
the architect the opportunity to design and continuous update the component-based
architecture of the system. This blue print is reusable and gives the developers a
window of capabilities to implement the needs of the customers. Another strong point is
the continuous management of quality assurance, for example the check in policies, the
support of different types of tests and the automation of the build process. The weak
point is the minimum support of the customer involvement and shared vision best
principles. VSTS has the ability to share project documents, reports and other
information, but has no direct functionality that stimulates customer involvement or
shared vision.
The VSTS strongest quality is the integration of all these features in one software
development platform, which improves the communication between all members of the
team. Adding the requirements management and change management support, makes
the Microsoft Visual Studio 2005 Team System a notorious competitive software
development platform.
122
7.2 RECOMMENDATIONS
This thesis compares the two software engineering processes on three different views,
the philosophy, focus in time and work division. This section describes several aspects
in which this work can be extended.
Beyond the SEP characteristics mentioned in the previous chapters, there are other
factors that play a roll while selecting the most suitable SEP for a certain company. This
thesis recommends future research on the following topics to recognize to the overall
most suitable software engineering process.
One research direction is to study the financial aspects for an organisation to use a
certain SEP. The following research activities are possible:
To identify the investments that the software development organisation needs to

make to put a software engineering process into practice. For instance the purchase
and configuration costs of a software development platform and training costs of the
employees.
To explore the savings one SEP will make for an organization. Research the return
on investment for an organisation for each individual SEP.
Another research direction is to study the impact of a SEP on the organisational

business processes. The following research activities are possible:
To research the internal processes that relates to the software engineering process
and the impact on them. Different SEP means different internal organisational
procedures to support the project teams.
To explore the effects on the organizational businesses process for a company to use
one organization wide standard SEP for every project instead of a different SEP for a
different project.
Another possible direction is related to the relationships of the project stakeholders.

Some possible research activities are:
To explore the consequences of different interactions and communications

procedures between the project team and the customer. Each SEP has its own way of
collaboration between the customer, project team and other stakeholders.
To study effects of transformation of the project teams. The team of people and how
they work together is a big factor in the project’s success. Using different SEPs
means using different team models.
123
REFERENCE
[1] AGILEALLIANCE (2001) Manifesto for Agile Software Development.
[2] AMBLER, S. W. (2005) Agile Architectural Modeling. Ambysoft Inc.
[3] AMBLER, S. W. (2006) Choose the Right Software Method for the Job.
Ambysoft Inc.
[4] ANDERSON, D. J. (2004) Agile Management for Software Engineering, Prentice

Hall PTR.
[5] ANDERSON, D. M. (2001) Design for Manufacturability: Optimizing Cost,

Quality, and Time-to-Market, CIM Press.
[6] BLAGOEV, R. (2005) Microsoft Solutions Framework versie 4. .Net magazine

for developers, 69 - 73.
[7] BOEHM, B. W. (1988) A Spiral Model of Software Development and

Enhancement. Computer, 21, 61-72.
[8] BRUYCKERS, G. D. (2004) Visual Studio 2005 Team System. dotNet magazine
for developers, 6, 4 - 6.
[9] FOWLER, M. (2002) Agile Development: What, Who, How, and Whether.
[10] FOWLER, M. (2003) The New Methodology.
[11] FOWLER, M. (2003) UML Distilled: A Brief Guide to the Standard Object
Modeling Language, Third Edition, Addison Wesley.
[12] IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational
Software Corporation.
[13] IBM (2005) Rational Unified Process – Best Practices for Software Development
Teams. Rational Software White paper. Rational.
[14] IVAR, J., GRADY, B. & JAMES, R. (1999) The unified software development
process, Addison-Wesley Longman Publishing Co., Inc.
124
Reference
[15] KRUCHTEN, P. (1996) A Rational Development Process. CrossTalk, 7.
[16] KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second

Edition, Addison-Wesley.
[17] LOGICACMG (2003) Resu!t Center. A LogicaCMG White Paper. LogicaCMG.
[18] LUKAWIECKI, R. (2005) MSF v4: What's New and Old in Microsoft Solutions
Framework v4. Microsoft Tech-Ed.
[19] MANDLIK, S. (2004) Comparing Microsoft Solution Framework & Rational

Unified Process. Wipro White paper. Microsoft.
[20] MICROSOFT (2002) MSF Process Model v. 3.1. Microsoft Solutions Framework
White paper. Microsoft.
[21] MICROSOFT (2002) MSF Team Model v. 3.1. Microsoft Solutions Framework
White paper. Microsoft.
[22] MICROSOFT (2003) Microsoft Solutions Framework version 3.0 Overview.

Microsoft Solutions Framework White paper. Microsoft.
[23] MICROSOFT (2005) Introduction to Visual Studio 2005 Team System.

Microsoft.
[24] MICROSOFT (2005) MSF for Agile Software Development, Beta, Build 100.
Microsoft Solutions Framework. Microsoft.
[25] MICROSOFT (2005), Visual Studio 2005 Team System – Reviewers Guide Beta
2. Microsoft.
[26] MURPHY, T. (2005) Driving Team Productivity Collaborative Development

Environments. A META Group White Paper. Stamford, META Group Inc.
[27] NERUR, S., MAHAPATRA, R. & MANGALARAJ, G. (2005) Challenges of

migrating to agile methodologies. Commun. ACM, 48, 72-78.
[28] PROBASCO, L. (2000) The Ten Essentials of RUP - The Essence of an Effective
Development Process. Rational Software White paper. Rational.
[29] RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified

Process - Student Manual, IBM Corporation.
[30] ROYCE, W. W. (1987) Managing the development of large software systems:

concepts and techniques. Proceedings of the 9th international conference on
Software Engineering. Monterey, California, United States, IEEE Computer
Society Press.
125
Reference
[31] SOMMERVILLE, I. (2004) Software Engineering (7th Edition), Pearson Addison

Wesley.
[32] THE STANDISH GROUP (2001) The Chaos Report. The Standish Group
International, Inc.
[33] VALK VAN DER, E. (2005) Code analysis in Visual Studio 2005. dotNet
magazine for developers, 9, 39 - 43.
[34] WAGUESPACK, L. & SCHIANO, W. T. (2004) Component-Based is

Architecture. Information Systems Management, 21, 53 - 60.
[35] WESSBERG, M. (2005) Introducing the IBM Rational Unified Process essentials
by analogy. developerWorks.
[36] ZUSER, W., HEIL, S. & GRECHENIG, T. (2005) Software quality development
and assurance in RUP, MSF and XP: a comparative study. Proceedings of the
third workshop on Software quality. St. Louis, Missouri, ACM Press.
126
APPENDIX
A THE GRAPHICAL REPRESENTATION OF MSF4ASD
During this research, we conducted a graphical representation of the Microsoft
Solutions Framework for Agile Software Engineering with the help of the architect of
the Microsoft Solutions Framework, Granville G. Miller13. In this appendix the
procedure is explained how I accomplished this illustration.
First we created a Microsoft Access database with all the elements of the Microsoft’s
agile software engineering process to get a solid base and overview for further
development of the graphical model. The elements, the advocacy groups, roles, work
streams, activities, work items, tracks and cycles, are placed in the database tables and
related to each other as illustrated in Figure 0-1.
Figure 0-1 The tables of the MSF4ASD database
These tables are used to produce two queries. The first query, named
qrAdvocacy_Role_Workstream_Activity_Track, connects all advocacy groups with the
right roles, work streams, activities, and tracks. The SQL-code of the
qrAdvocacy_Role_Workstream_Activity_Track query is as followed:
13 Granville “Randy” Miller is the architect of Microsoft’s agile software development process, Microsoft Solutions Framework for
Agile Software Development. He has two decades of experience in the commercial software industry and has spoken at many
international events, including XP200x, Conference On Object Oriented Programming Systems, Languages and Applications, Web
Services Edge, Software Development West, Microsoft TechEd, and others. His interests include software development technology
and agile software development. Miller is author of “Advanced Use Case Modeling” and “A Practical Guide to Extreme
Programming.”
127
Appendix
The second query we created is a pivot query of the previous query, named
qrMSF4ASD. It contains the advocacy groups, roles, work streams and activities in the
rows and the activities sorted by track as column headers. The query puts the name of
the track in the cells where the row activities and the track activities in the column
headers are the same. As a result, the query shows when an activity in which track
occurs. The SQL-code of the qrMSF4ASD query is as followed:
We exported the results of the last query to a Microsoft Office Excel sheet to get more
creative freedom. Now we have a spreadsheet with a vertical axis with all activities
ordered by the work streams of each advocacy group and a horizontal axis with all
activities ordered by tracks. We coloured the cells of the corresponding activities with a
different colour for each cycle an activity occurs, as the legend shows in Figure 0-2.
Figure 0-2 Cycle legend
In the next step we added the roles of MSF4ASD at the end of the track columns and
coloured per activity which role is responsible (red) or is consulted (green) for the
concerned activity. These actions result in an excel sheet as shown in Figure 0-3.
128
Appendix
Figure 0-3 Advocacies, roles, activities, tracks, cycles, responsibilities and consultations
After this we put all the coloured cells in a work stream beneath each other to create a
column with a height coupled with the amount of activities that take place in the work
stream or cycle as reflected in Figure 0-4.
129
Appendix
Figure 0-4 The activities columns per work stream or cycle
As already mentioned, the heights of the bars are linked to the amount of activities in
the concerned work stream or cycle. Up to now, the graphical model of MSF4ASD
contains only one of each cycle. The next step, we repeat some activities, reckon with
the frequency that the cycles occur, to generate an iterative software development
model. We heightened the workload-columns with one cell when a role is consulted for
an activity in a work stream. For example the activity ‘conduct retrospective’ in the
‘guide iteration’ work stream is the responsible of the project manager, but he consults
the developer, tester and business analyst and therefore we coloured an extra cell in the
rows of the concerned roles.
130
Appendix
Figure 0-5 The MSF4ASD model with iterative cycles
After this, we draw undulate lines that connect the bars and improve the picture in
Adobe Photoshop to produce the final graphical representation of the Microsoft
Solutions Framework for Agile Software Development as shown in Figure 0-6 on the
next page.
enacted, and it is expressed in terms of cycles, tracks, and governance milestones. The
vertical axis represents the static aspect of the process: how it is described in terms of
advocacy groups, roles, Work streams and activities. The undulated lines represent the
workload and amount of activities of a particular advocacy group in time during the
software development life cycle.
131
Figure 0-6 The graphical representation of MSF4ASD
B THE PROCESS ELEMENT OF RUP
Phases
Inception
Elaboration
Construction
Transition
Disciplines
Business modeling Test Project Management
Requirement Deployment Environment
Analysis & Design Configuration &
Implementation Change Management
Roles
Business-Process Integrator System
Analyst Project Manager Administrator
Business Designer Change Control Tool Specialist
System Analyst Manager Course Developer
Requirements Configuration Graphic Artist
Specifier Manager Tester
Software Architect Test Manager Test Analyst
Designer Deployment Test Designer
User-Interface Manager Reviewer
Designer Process Engineer Review Coordinator
Capsule Designer Management Technical Reviewer
Database Designer Reviewer Any Role
Implementer Technical Writer Stakeholder
Workflows
Assess Business Define the System Structure the
Status Manage the Scope of Implementation
Describe Current the System Model
Business Refine the System Plan the Integration
Identify Business Definition Implement
Processes Manage Changing Components
Refine Business Requirements Integrate Each
Process Definitions Perform Subsystem
Design Business Architectural Integrate the System
Process Realizations Synthesis Define Evaluation
Refine Roles and Define a Candidate Mission
Responsibilities Architecture Verify Test
Explore Process Refine the Approach
Automation Architecture Validate Build
Develop a Domain Analyze Behaviour Stability
Model Design Components Test and Evaluate
Analyze the Problem Design the Database Achieve Acceptable
Understand Mission
Stakeholder Needs Improve Test Assets
133
Appendix
Plan Deployment Management (CM) Plan for Next

Develop Support Environments Iteration
Material Manage Baselines & Manage Iteration
Manage Acceptance Releases Monitor & Control
Test Change and Deliver Project
Produce Deployment Configuration Items Close-Out Phase
Unit Monitor & Report Close-Out Project
Beta Test Product Configuration Items Prepare Environment
Package Product Manage Change for Project
Provide Access to Requests Prepare Environment
Download Site Conceive New for an Iteration
Plan Project Project Support
Configuration & Evaluate Project Environment During
Change Control Scope and Risk an Iteration
Create Project Plan the Project
Configuration
Activities
Capture a Common Capture a Common Incorporate Existing
Business Vocabulary Vocabulary Design Elements
Assess Target Structure the Use- Structure the
Organization Case Model Implementation
Set and Adjust Find Actors and Use Model
Objectives Cases Class Design
Maintain Business Manage Subsystem Design
Rules Dependencies Use-Case Design
Identify Business Develop Use-Case Analysis
Goals Requirements Design Testability
Structure the Management Plan Elements
Business Use-Case Detail the Software Design the User
Model Requirements Interface
Find Business Actors Detail a Use Case Prototype the User-
and Use Cases Construct Interface
Define the Business Architectural Proof- Capsule Design
Architecture of-Concept Database Design
Define Automation Assess Viability of Implement Design
Requirements Architectural Proof- Elements
Detail a Business of-Concept Execute Developer
Use Case Prioritize Use Cases Tests
Detail a Business Architectural Analyze Runtime
Entity Analysis Behaviour
Detail a Business Describe Implement
Worker Distribution Developer Test
Find Business Describe the Run- Implement
Workers and time Architecture Testability Elements
Enitities Identify Design Develop Installation
Develop Vision Mechanisms Artifacts
Elicit Stakeholder Identify Design Plan Subsystem
Requests Elements Integration
134
Appendix
Integrate Subsystem Review Change Launch

Plan System Request Development
Integration Confirm Duplicate or Process
Integrate System Rejected CR Prepare Templates
Promote Baselines Establish Change for the Project
Create Baselines Control Process Prepare Guidelines
Create Integration Set Up Configuration for the Project
Workspaces Management (CM) Develop
Develop Business Environment Development Case
Case Create Deployment Project Acceptance
Plan Phases and Unit Review
Iterations Report on Project Review
Identify and Assess Configuration Status Authority (PRA)
Risks Perform Project Review
Develop Iteration Configuration Audit Lifecycle Milestone
Plan Establish Review
Assess Iteration Configuration Iteration Acceptance
Report Status Management (CM) Review
Define Monitoring & Policies Iteration Evaluation
Control Processes Write Configuration Criteria Review
Develop Quality Management (CM) Iteration Plan
Assurance Plan Plan Review
Develop Problem Assess and Advocate Project Planning
Resolution Plan Quality Review
Develop Risk Assess and Improve Project Approval
Management Plan Test Effort Review
Develop Product Obtain Testability Develop Support
Acceptance Plan Commitment Materials
Compile Software Identify Test Develop Manual
Development Plan Motivators Styleguide
Develop Agree on the Support
Measurement Plan Mission Development
Prepare for Project Develop Deployment Select and Acquire
Close-Out Plan Tools
Prepare for Phase Manage Acceptance Set Up Tools
Close-Out Test Verify Tool
Handle Exceptions Manage Beta Test Configuration and
and Problems Verify Manufactured Installation
Monitor Project Product Develop Training
Status Release to Materials
Define Project Manufacturing Create Product
Organization and Provide Access to Artwork
Staffing Download Site Implement Test Suite
Initiate Project Define Bill of Execute Test Suite
Acquire Staff Materials Analyze Test Failure
Schedule and Assign Write Release Notes Implement Test
Work Tailor the Process Identify Test Ideas
Initiate Iteration for the Project Determine Test
Results
135
Appendix
Define Assessment Define Testability Review Code

and Traceability Elements Submit Change
Needs Identify Testability Request
Define Test Details Mechanisms Update Workspace
Identify Targets of Conduct Review Create Development
Test Organize Review Workspace
Verify Changes in Review the Business Update Change
Build Use-Case Model Request
Define Test Review the Business Deliver Changes
Approach Analysis Model Make Changes
Structure the Test Review
Implementation Requirements
Define Test Review the
Environment Architecture
Configurations Review the Design
Artifacts
Software Implementation Configuration
Requirement Model Management Plan
Vision Integration Build Configuration Audit
Glossary Plan Findings
Stakeholder Develop Test Business Case
Requests Test Strategy Software
Storyboard Test Results Development Plan
Software Test-Ideas List Iteration Plan
Requirements Test Suite Deployment Plan
Specification Test Log Risk List
Supplementary Test Plan Issues List
Specifications Test Data Work Order
Use-Case Model Test Script Project
Requirements Test Case Measurements
Management Plan Test Environment Iteration Assessment
Requirements Configuration Status Assessment
Attributes Workload Analysis Review Record
Software Model Development
Architecture Test Evaluation Process
Document Summary Development
Architectural Proof- Test Interface Infrastructure
of-Concept Specification Tools
Deployment Model Test Automation Development-
Reference Architecture Organization
Architecture Product Assessment
Design Model End-user Support Business Vision
Analysis Model Material Business Glossary
User-Interface Manual Styleguide Target-Organization
Prototype Change Request Assessment
Navigation Map Project Repository Business Goal
Data Model Workspace Business Rule
Build
136
Appendix
Business Use Case

Model
Supplementary
Business
Specification
Business Analysis
Model
Business
Architecture
Document
137
C THE PROCESS ELEMENTS OF MSF4ASD
Tracks
Envision
Plan
Build
Stabilize
Deploy
Continuous
Cycles
Check In
Daily Build
Accepted Build
Iteration
Project
Advocacy Groups
Product Management
User Experience
Architecture
Development
Test
Release Operations
Program Management
Roles
Business Analyst
Project Manager
Architect
Developer
Tester
Release Manager
Work Streams
Create Solution Build a Product Release a Product
Architecture Fix a Bug Close a Bug
Capture Project Implement a Test a Quality of
Vision Development Task Service Requirement
Create a Quality of Guide Iteration Test a Scenario
Service Requirement Guide Project
Create a Scenario Plan an Iteration
Activities
Partition the System Develop Create Infrastructure
Determine Interfaces Performance Model Architecture
Develop Threat Create Architectural Write Vision
Model Prototype Statement
Define Personas
138
Appendix
Refine Personas Perform a Unit Schedule Bug Fixing

Brainstorm Quality Test(FB) Allotment
of Service Refactor Code(FB) Divide Scenarios
Requirements Review Code(FB) into Tasks
Develop Lifestyle Integrate Code Divide Quality of
Snapshot(QSR) Changes(FB) Service
Prioritize Quality of Cost a Development Requirements into
Service Task Tasks
Requirements List Create or Update a Execute a Release
Write Quality of Unit Test(IDT) Plan
Service Requirement Write Code for a Validate a Release
Identify Security Development Task Create Release Notes
Objectives Perform Code Deploy the Product
Brainstorm Analysis Verify a Fix
Scenarios Perform a Unit Close the Bug
Develop Lifestyle TestIDT) Define Test
Snapshot(Sc) Refactor Code(IDT) Approach(QSR)
Prioritize Scenario Review Code(IDT) Write Performance
List Integrate Code Tests
Write Scenario Changes(IDT) Write Security Tests
Description Monitor Iteration Write Stress Tests
Storyboard a Mitigate a Risk Write Load Tests
Scenario Conduct Select and Run a
Start a Build Retrospective Test Case(QSR)
Verify a Build Review Objectives Open a Bug(QSR)
Fix a Build Assess Progress Conduct Exploratory
Accept Build Evaluate Test Metric Testing(QSR)
Reproduce the Bug Thresholds Define Test
Locate the Cause of Triage Bugs Approach(Sc)
a Bug Identify Risk Write Validation
Reassign a Bug Determine Iteration Tests
Decide on a Bug Fix Length Select and Run a
Strategy Estimate Scenario Test Case(Sc)
Code the Fix for a Estimate Quality of Open a Bug(Sc)
Bug Service Requirement Conduct Exploratory
Create or Update a Schedule Scenario Testing(Sc)
Unit Test(FB) Schedule Quality of
Service Requirement
Work Products
Application Diagram
Changeset
Class Diagram
Code
Iteration Plan
Load Test
Logical Datacenter Diagram
Manual Test
Persona
139
Appendix
Project Checklist
Prototype
Quality of Service Requirement List
Release Plan
Scenario Description
Scenario List
Storyboard
System Diagram
Team Build
Test Approach
Test Result
Threat Model
Unit Test
Vision Statement
Web Test
140

Traa, J.W.A. - RUP vs. MSF - A Comparative Study

Uploaded by

Copyright:

Available Formats

Traa, J.W.A. - RUP vs. MSF - A Comparative Study

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Traa, J.W.A. - RUP vs. MSF - A Comparative Study

Uploaded by

Copyright:

Available Formats

RATIONAL UNIFIED PROCESS

MICROSOFT SOLUTIONS FRAMEWORK:

Johan W.A. Traa

Johan W.A. Traa

Also thanks to:

Dik Harbrecht – Interviewee LogicaCMG

There are numerous ways for a software development organisation to create an

CHAPTER 1 INTRODUCTION ...................................................................................... 12

CHAPTER 2 SOFTWARE ENGINEERING PROCESS ..................................................... 17

CHAPTER 3 RATIONAL UNIFIED PROCESS ................................................................ 23

CHAPTER 4 MICROSOFT SOLUTIONS FRAMEWORK ................................................. 39

4.2 Foundational Principles .................................................................................. 41

CHAPTER 5 RUP VERSUS MSF4ASD ....................................................................... 59

CHAPTER 6 MICROSOFT VISUAL STUDIO 2005 TEAM SYSTEM ............................... 83

CHAPTER 7 CONCLUDING REMARKS ...................................................................... 119

REFERENCE .................................................................................................................. 124

APPENDIX ..................................................................................................................... 127

Component based architecture

Integrated development environment

Iterative software development

Microsoft Solutions Framework

Project development tool

Rational Unified Process

Software development method

Software development plan

Software development platform

Software engineering process

Unified Modeling Language

CMMI Capability Maturity Model® Integration

DSL Domain Specific Language

IDE Integrated Development Environment

MOF Microsoft Operations Framework

MSF Microsoft Solutions Framework

MSF4ASD Microsoft Solutions Framework for Agile Software

MSF4CMMI MSF for Capability Maturity Model® Integration Process

QSR Quality of Service Requirement

RUP Rational Unified Process

SDLC Software Development Life Cycle

SDP Software Development Platform

SEP Software Engineering Process

TFS Visual Studio 2005 Team Foundation Server

UML Unified Modeling Language

VSTS Microsoft Visual Studio 2005 Team System

However, do not be fooled with this increase of successful information technology

1.2 RESEARCH QUESTIONS AND APPROACHES

Question 4 : How are these common grounds and differences supported by

software development platform is better, it gives a general suggestion in which project

1.5 OUTLINE OF THE DISSERTATION

Chapter 2 addresses the background information needed to understand what a software

Although there are many software engineering processes, according to Sommerville

1. Software specification. To define the functionality of the software and

3. Software validation. To validate the software to ensure that it meets the

4. Software evolution. To meet changing customer needs, the software must

Some examples of software engineering processes are a listed below:

Figure 2-1 shows an arrangement of the mentioned software engineering examples by

Figure 2-1 Processes categorized by predictive versus adaptive

An adaptive process is suggested when a project has to cope with uncertainties or

Scott W. Ambler classifies the software engineering processes in four categories,

2.2 THE SEQUENTIAL PROCESS

The best-known sequential software engineering process is the waterfall model.