Download - RATIONAL UNIFIED PROCESS VS - Donutsdocshare01.docshare.tips/files/692/6929978.pdfRational Unified Process A software engineering process, created by Rational, which provides a guideline

Transcript

RATIONAL UNIFIED PROCESS

VS.

MICROSOFT SOLUTIONS FRAMEWORK:

A COMPARATIVE STUDY

By

Johan W.A. Traa

Erasmus University Rotterdam

The Netherlands

2

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

3

4

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.

5

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

Content

6

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

7

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.

Glossary

8

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.

Glossary

9

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.

Glossary

10

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.

11

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

12

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].

Chapter 1 | Introduction

13

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].

Chapter 1 | Introduction

14

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.

Chapter 1 | Introduction

15

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

Chapter 1 | Introduction

16

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.

17

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.

Chapter 2 | Software Engineering Process

18

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.

Chapter 2 | Software Engineering Process

19

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.

Chapter 2 | Software Engineering Process

20

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

Chapter 2 | Software Engineering Process

21

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

Chapter 2 | Software Engineering Process

22

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 Programming

5, 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.

23

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.

Chapter 3 | Rational Unified Process

24

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].

Chapter 3 | Rational Unified Process

25

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

Chapter 3 | Rational Unified Process

26

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,

Chapter 3 | Rational Unified Process

27

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

Chapter 3 | Rational Unified Process

28

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.

Chapter 3 | Rational Unified Process

29

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].

Chapter 3 | Rational Unified Process

30

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.

Chapter 3 | Rational Unified Process

31

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

Chapter 3 | Rational Unified Process

32

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].

Chapter 3 | Rational Unified Process

33

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.

Chapter 3 | Rational Unified Process

34

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.

Chapter 3 | Rational Unified Process

35

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]

Chapter 3 | Rational Unified Process

36

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].

Chapter 3 | Rational Unified Process

37

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].

Chapter 3 | Rational Unified Process

38

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].

Chapter 5 | RUP versus MSF4ASD

39

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

Chapter 4 | Microsoft Solutions Framework

40

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.

Chapter 4 | Microsoft Solutions Framework

41

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.

Chapter 4 | Microsoft Solutions Framework

42

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

Chapter 4 | Microsoft Solutions Framework

43

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].

Chapter 4 | Microsoft Solutions Framework

44

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

Chapter 4 | Microsoft Solutions Framework

45

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.

Chapter 4 | Microsoft Solutions Framework

46

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

Chapter 4 | Microsoft Solutions Framework

47

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

Chapter 4 | Microsoft Solutions Framework

48

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

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, 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.”

Chapter 4 | Microsoft Solutions Framework

49

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].

Chapter 4 | Microsoft Solutions Framework

50

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].

Chapter 4 | Microsoft Solutions Framework

51

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

Chapter 4 | Microsoft Solutions Framework

52

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.

Chapter 4 | Microsoft Solutions Framework

53

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

Chapter 4 | Microsoft Solutions Framework

54

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

Chapter 4 | Microsoft Solutions Framework

55

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

Chapter 4 | Microsoft Solutions Framework

56

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].

Chapter 4 | Microsoft Solutions Framework

57

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

Chapter 4 | Microsoft Solutions Framework

58

intermediate documentation. It also emphasizes the delivery of working software and

promotes customer validation as key success measures.

59

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

Chapter 5 | RUP versus MSF4ASD

60

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:

Develop software iteratively To develop the solution in small steps,

where each step yielding a working

system.

Manage requirements To identify, organize and document the

requirements of a system.

Use component-based architectures To provide developers with a clear

overview of the whole system and

promote more effective software reuse.

Visually model software To capture and show a simplified

graphical model of the structure and

behaviour of architectures and

components.

Continuously verify software quality To assure the solution meets the

requirements based on reliability,

functionality, application performance

and system performance.

Control changes to software To keep the project changes under

control.

MSF’s Principles:

Partner with customers To understand the customer’s business

value and to get user feedback.

Foster open communications To share all information with all team

members.

Work toward a shared vision To have an agreement of all team

members on the formulated solution.

Quality is everyone's job every day All roles are responsible for the quality

of the solution.

Stay agile, adapt to change To cope with the changing environment

and customer’s needs.

Make deployment a habit To create readiness to ship the solution

at any time.

Flow of value To create business added value.

Chapter 5 | RUP versus MSF4ASD

61

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

Chapter 5 | RUP versus MSF4ASD

62

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]

Chapter 5 | RUP versus MSF4ASD

63

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.

Chapter 5 | RUP versus MSF4ASD

64

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.

Chapter 5 | RUP versus MSF4ASD

65

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.

Chapter 5 | RUP versus MSF4ASD

66

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

Chapter 5 | RUP versus MSF4ASD

67

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

Chapter 5 | RUP versus MSF4ASD

68

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.

Chapter 5 | RUP versus MSF4ASD

69

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

Chapter 5 | RUP versus MSF4ASD

70

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

Chapter 5 | RUP versus MSF4ASD

71

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:

Inception To specify the vision, its business case,

and defining the scope of the project.

Elaboration To plan the activities and resources, and

to specify the features and design

architecture of the system.

Construction To build the product and to evolve the

vision, architecture, and planning until

the system aligns with the agreements.

Transition To hand the system over to its users by

deploying it in the user environment or

delivering it to the buyer with the

appropriate support, trainings and

documentation.

MSF4ASD’s Tracks:

Envision To unify the stakeholders’ goals behind

a common vision of the project.

Plan To understand and track the progress of

the project and product.

Build To write and update the architecture,

scenarios, QSRs, and to develop the

system incrementally en iteratively.

Stabilize To verify and to close a bug to enable

stability of the system.

Deploy 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.

Chapter 5 | RUP versus MSF4ASD

72

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.

Chapter 5 | RUP versus MSF4ASD

73

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.

Chapter 5 | RUP versus MSF4ASD

74

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

Chapter 5 | RUP versus MSF4ASD

75

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

Chapter 5 | RUP versus MSF4ASD

76

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.

Chapter 5 | RUP versus MSF4ASD

77

5.4 WORK DIVISION

RUP’s Disciplines:

Business Modeling To understand customer's problems and

to ensure a common project vision

among the stakeholders.

Requirements To establish and maintain agreements

with stakeholders how the system

should work to satisfy the needs and

expectations of the end-users.

Analysis & Design To transform the requirements into a

design to evolve in a robust architecture

for the system.

Implementation To implement the design elements, to

unit test them, and to integrate the

results into an executable system.

Test To validate the correct implementation

of the requirements and to find and

document defects in software quality.

Deployment To ensure that the software product is

available for its end users.

Configuration & Change Management To control the changes to, and

maintains the integrity of project’s

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.

MSF4ASD’s Advocacy groups:

Product Management To define the business opportunity and

the application that will serve it.

User Experience To understand the needs and goals of

the user and translates those into

persona definitions, scenarios, and

quality of service requirements.

Architecture To design the organizational structure

of the application and the physical

structure of the application and to

reduce complexity by dividing the

system into clean and simple partitions.

Development To implement the application as

specified within the planned project

constraints.

Test To discover and communicate product

issues and to prove that known

functions are implemented correctly.

Release Operations To manage the release of the product.

Program Management To keep the project within the agreed

schedule and budget.

Chapter 5 | RUP versus MSF4ASD

78

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.

Chapter 5 | RUP versus MSF4ASD

79

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.

Chapter 5 | RUP versus MSF4ASD

80

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.

Figure 5-7 RUP versus MSF4ASD

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,

Chapter 5 | RUP versus MSF4ASD

81

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

Chapter 5 | RUP versus MSF4ASD

82

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.

83

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

Chapter 6 | Microsoft Visual Studio 2005 Team System

84

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/

Chapter 6 | Microsoft Visual Studio 2005 Team System

85

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

Chapter 6 | Microsoft Visual Studio 2005 Team System

86

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

87

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

88

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

89

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

90

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

Chapter 6 | Microsoft Visual Studio 2005 Team System

91

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

92

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

93

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

94

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

95

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

Chapter 6 | Microsoft Visual Studio 2005 Team System

96

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

97

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

Chapter 6 | Microsoft Visual Studio 2005 Team System

98

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

99

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

100

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

101

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

102

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

Chapter 6 | Microsoft Visual Studio 2005 Team System

103

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

104

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

105

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

Chapter 6 | Microsoft Visual Studio 2005 Team System

106

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

107

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

108

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

Chapter 6 | Microsoft Visual Studio 2005 Team System

109

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

Chapter 6 | Microsoft Visual Studio 2005 Team System

110

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

111

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

112

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

113

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

Chapter 6 | Microsoft Visual Studio 2005 Team System

114

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.

Chapter 6 | Microsoft Visual Studio 2005 Team System

115

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,

Chapter 6 | Microsoft Visual Studio 2005 Team System

116

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

Chapter 6 | Microsoft Visual Studio 2005 Team System

117

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

Chapter 6 | Microsoft Visual Studio 2005 Team System

118

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.

119

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

Chapter 7 | Concluding Remarks

120

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.

Figure 7-1 RUP versus MSF4ASD

Chapter 7 | Concluding Remarks

121

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.

Chapter 7 | Concluding Remarks

122

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.

Chapter 7 | Concluding Remarks

123

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.

124

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.

Reference

125

[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.

Reference

126

[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.

127

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.”

Appendix

128

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.

Appendix

129

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.

Appendix

130

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.

Appendix

131

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.

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, 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.

Figure 0-6 The graphical representation of MSF4ASD

133

B THE PROCESS ELEMENT OF RUP Phases

� Inception

� Elaboration

� Construction

� Transition

Disciplines

� Business modeling

� Requirement

� Analysis & Design

� Implementation

� Test

� Deployment

� Configuration &

Change Management

� Project Management

� Environment

Roles

� Business-Process

Analyst

� Business Designer

� System Analyst

� Requirements

Specifier

� Software Architect

� Designer

� User-Interface

Designer

� Capsule Designer

� Database Designer

� Implementer

� Integrator

� Project Manager

� Change Control

Manager

� Configuration

Manager

� Test Manager

� Deployment

Manager

� Process Engineer

� Management

Reviewer

� Technical Writer

� System

Administrator

� Tool Specialist

� Course Developer

� Graphic Artist

� Tester

� Test Analyst

� Test Designer

� Reviewer

� Review Coordinator

� Technical Reviewer

� Any Role

� Stakeholder

Workflows

� Assess Business

Status

� Describe Current

Business

� Identify Business

Processes

� Refine Business

Process Definitions

� Design Business

Process Realizations

� Refine Roles and

Responsibilities

� Explore Process

Automation

� Develop a Domain

Model

� Analyze the Problem

� Understand

Stakeholder Needs

� Define the System

� Manage the Scope of

the System

� Refine the System

Definition

� Manage Changing

Requirements

� Perform

Architectural

Synthesis

� Define a Candidate

Architecture

� Refine the

Architecture

� Analyze Behaviour

� Design Components

� Design the Database

� Structure the

Implementation

Model

� Plan the Integration

� Implement

Components

� Integrate Each

Subsystem

� Integrate the System

� Define Evaluation

Mission

� Verify Test

Approach

� Validate Build

Stability

� Test and Evaluate

� Achieve Acceptable

Mission

� Improve Test Assets

Appendix

134

� Plan Deployment

� Develop Support

Material

� Manage Acceptance

Test

� Produce Deployment

Unit

� Beta Test Product

� Package Product

� Provide Access to

Download Site

� Plan Project

Configuration &

Change Control

� Create Project

Configuration

Management (CM)

Environments

� Manage Baselines &

Releases

� Change and Deliver

Configuration Items

� Monitor & Report

Configuration Items

� Manage Change

Requests

� Conceive New

Project

� Evaluate Project

Scope and Risk

� Plan the Project

� Plan for Next

Iteration

� Manage Iteration

� Monitor & Control

Project

� Close-Out Phase

� Close-Out Project

� Prepare Environment

for Project

� Prepare Environment

for an Iteration

� Support

Environment During

an Iteration

Activities

� Capture a Common

Business Vocabulary

� Assess Target

Organization

� Set and Adjust

Objectives

� Maintain Business

Rules

� Identify Business

Goals

� Structure the

Business Use-Case

Model

� Find Business Actors

and Use Cases

� Define the Business

Architecture

� Define Automation

Requirements

� Detail a Business

Use Case

� Detail a Business

Entity

� Detail a Business

Worker

� Find Business

Workers and

Enitities

� Develop Vision

� Elicit Stakeholder

Requests

� Capture a Common

Vocabulary

� Structure the Use-

Case Model

� Find Actors and Use

Cases

� Manage

Dependencies

� Develop

Requirements

Management Plan

� Detail the Software

Requirements

� Detail a Use Case

� Construct

Architectural Proof-

of-Concept

� Assess Viability of

Architectural Proof-

of-Concept

� Prioritize Use Cases

� Architectural

Analysis

� Describe

Distribution

� Describe the Run-

time Architecture

� Identify Design

Mechanisms

� Identify Design

Elements

� Incorporate Existing

Design Elements

� Structure the

Implementation

Model

� Class Design

� Subsystem Design

� Use-Case Design

� Use-Case Analysis

� Design Testability

Elements

� Design the User

Interface

� Prototype the User-

Interface

� Capsule Design

� Database Design

� Implement Design

Elements

� Execute Developer

Tests

� Analyze Runtime

Behaviour

� Implement

Developer Test

� Implement

Testability Elements

� Develop Installation

Artifacts

� Plan Subsystem

Integration

Appendix

135

� Integrate Subsystem

� Plan System

Integration

� Integrate System

� Promote Baselines

� Create Baselines

� Create Integration

Workspaces

� Develop Business

Case

� Plan Phases and

Iterations

� Identify and Assess

Risks

� Develop Iteration

Plan

� Assess Iteration

� Report Status

� Define Monitoring &

Control Processes

� Develop Quality

Assurance Plan

� Develop Problem

Resolution Plan

� Develop Risk

Management Plan

� Develop Product

Acceptance Plan

� Compile Software

Development Plan

� Develop

Measurement Plan

� Prepare for Project

Close-Out

� Prepare for Phase

Close-Out

� Handle Exceptions

and Problems

� Monitor Project

Status

� Define Project

Organization and

Staffing

� Initiate Project

� Acquire Staff

� Schedule and Assign

Work

� Initiate Iteration

� Review Change

Request

� Confirm Duplicate or

Rejected CR

� Establish Change

Control Process

� Set Up Configuration

Management (CM)

Environment

� Create Deployment

Unit

� Report on

Configuration Status

� Perform

Configuration Audit

� Establish

Configuration

Management (CM)

Policies

� Write Configuration

Management (CM)

Plan

� Assess and Advocate

Quality

� Assess and Improve

Test Effort

� Obtain Testability

Commitment

� Identify Test

Motivators

� Agree on the

Mission

� Develop Deployment

Plan

� Manage Acceptance

Test

� Manage Beta Test

� Verify Manufactured

Product

� Release to

Manufacturing

� Provide Access to

Download Site

� Define Bill of

Materials

� Write Release Notes

� Tailor the Process

for the Project

� Launch

Development

Process

� Prepare Templates

for the Project

� Prepare Guidelines

for the Project

� Develop

Development Case

� Project Acceptance

Review

� Project Review

Authority (PRA)

Project Review

� Lifecycle Milestone

Review

� Iteration Acceptance

Review

� Iteration Evaluation

Criteria Review

� Iteration Plan

Review

� Project Planning

Review

� Project Approval

Review

� Develop Support

Materials

� Develop Manual

Styleguide

� Support

Development

� Select and Acquire

Tools

� Set Up Tools

� Verify Tool

Configuration and

Installation

� Develop Training

Materials

� Create Product

Artwork

� Implement Test Suite

� Execute Test Suite

� Analyze Test Failure

� Implement Test

� Identify Test Ideas

� Determine Test

Results

Appendix

136

� Define Assessment

and Traceability

Needs

� Define Test Details

� Identify Targets of

Test

� Verify Changes in

Build

� Define Test

Approach

� Structure the Test

Implementation

� Define Test

Environment

Configurations

� Define Testability

Elements

� Identify Testability

Mechanisms

� Conduct Review

� Organize Review

� Review the Business

Use-Case Model

� Review the Business

Analysis Model

� Review

Requirements

� Review the

Architecture

� Review the Design

� Review Code

� Submit Change

Request

� Update Workspace

� Create Development

Workspace

� Update Change

Request

� Deliver Changes

� Make Changes

Artifacts

� Software

Requirement

� Vision

� Glossary

� Stakeholder

Requests

� Storyboard

� Software

Requirements

Specification

� Supplementary

Specifications

� Use-Case Model

� Requirements

Management Plan

� Requirements

Attributes

� Software

Architecture

Document

� Architectural Proof-

of-Concept

� Deployment Model

� Reference

Architecture

� Design Model

� Analysis Model

� User-Interface

Prototype

� Navigation Map

� Data Model

� Build

� Implementation

Model

� Integration Build

Plan

� Develop Test

� Test Strategy

� Test Results

� Test-Ideas List

� Test Suite

� Test Log

� Test Plan

� Test Data

� Test Script

� Test Case

� Test Environment

Configuration

� Workload Analysis

Model

� Test Evaluation

Summary

� Test Interface

Specification

� Test Automation

Architecture

� Product

� End-user Support

Material

� Manual Styleguide

� Change Request

� Project Repository

� Workspace

� Configuration

Management Plan

� Configuration Audit

Findings

� Business Case

� Software

Development Plan

� Iteration Plan

� Deployment Plan

� Risk List

� Issues List

� Work Order

� Project

Measurements

� Iteration Assessment

� Status Assessment

� Review Record

� Development

Process

� Development

Infrastructure

� Tools

� Development-

Organization

Assessment

� Business Vision

� Business Glossary

� Target-Organization

Assessment

� Business Goal

� Business Rule

Appendix

137

� Business Use Case

Model

� Supplementary

Business

Specification

� Business Analysis

Model

� Business

Architecture

Document

138

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

Architecture

� Capture Project

Vision

� Create a Quality of

Service Requirement

� Create a Scenario

� Build a Product

� Fix a Bug

� Implement a

Development Task

� Guide Iteration

� Guide Project

� Plan an Iteration

� Release a Product

� Close a Bug

� Test a Quality of

Service Requirement

� Test a Scenario

Activities

� Partition the System

� Determine Interfaces

� Develop Threat

Model

� Develop

Performance Model

� Create Architectural

Prototype

� Create Infrastructure

Architecture

� Write Vision

Statement

� Define Personas

Appendix

139

� Refine Personas

� Brainstorm Quality

of Service

Requirements

� Develop Lifestyle

Snapshot(QSR)

� Prioritize Quality of

Service

Requirements List

� Write Quality of

Service Requirement

� Identify Security

Objectives

� Brainstorm

Scenarios

� Develop Lifestyle

Snapshot(Sc)

� Prioritize Scenario

List

� Write Scenario

Description

� Storyboard a

Scenario

� Start a Build

� Verify a Build

� Fix a Build

� Accept Build

� Reproduce the Bug

� Locate the Cause of

a Bug

� Reassign a Bug

� Decide on a Bug Fix

Strategy

� Code the Fix for a

Bug

� Create or Update a

Unit Test(FB)

� Perform a Unit

Test(FB)

� Refactor Code(FB)

� Review Code(FB)

� Integrate Code

Changes(FB)

� Cost a Development

Task

� Create or Update a

Unit Test(IDT)

� Write Code for a

Development Task

� Perform Code

Analysis

� Perform a Unit

TestIDT)

� Refactor Code(IDT)

� Review Code(IDT)

� Integrate Code

Changes(IDT)

� Monitor Iteration

� Mitigate a Risk

� Conduct

Retrospective

� Review Objectives

� Assess Progress

� Evaluate Test Metric

Thresholds

� Triage Bugs

� Identify Risk

� Determine Iteration

Length

� Estimate Scenario

� Estimate Quality of

Service Requirement

� Schedule Scenario

� Schedule Quality of

Service Requirement

� Schedule Bug Fixing

Allotment

� Divide Scenarios

into Tasks

� Divide Quality of

Service

Requirements into

Tasks

� Execute a Release

Plan

� Validate a Release

� Create Release Notes

� Deploy the Product

� Verify a Fix

� Close the Bug

� Define Test

Approach(QSR)

� Write Performance

Tests

� Write Security Tests

� Write Stress Tests

� Write Load Tests

� Select and Run a

Test Case(QSR)

� Open a Bug(QSR)

� Conduct Exploratory

Testing(QSR)

� Define Test

Approach(Sc)

� Write Validation

Tests

� Select and Run a

Test Case(Sc)

� Open a Bug(Sc)

� Conduct Exploratory

Testing(Sc)

Work Products

� Application Diagram

� Changeset

� Class Diagram

� Code

� Iteration Plan

� Load Test

� Logical Datacenter Diagram

� Manual Test

� Persona

Appendix

140

� 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