Quasar 3.0 - Capgemini

Transcription

Quasar 3.0
A Situational Approach to Software Engineering
Quasar 3.0
A Situational Approach to Software Engineering
Version: 1.1 – Copyright ©2012 Capgemini.
This Patternbook is protected by copyright. The online version may be printed and distributed in
hardcopy free of charge. Any other duplication and distribution, as well as modifications, translations
and reproductions require the previous written approval of the copyright owner.
Quasar 3.0
Foreword
Quasar has for years symbolized and embodied the know-how of our top software
engineers. The sd&m school of software engineering thought has for years
developed the best engineers and run the most challenging projects.
Quasar 3.0 embodies and symbolizes the pursuit, renewal and development of this
glorious tradition. Now the Custom Software Development tradition matches
Capgemini’s own development heritage, and enriches it substantially – opening
new horizons for this know-how.
Quasar 3.0 and its situational approach illustrate the two ways we have to build on
our software engineering tradition.
The first one is the way of continuity. Engineering principles and engineering
discipline are always needed for good software development – from a complex
IBM 360 MVS / IMS application to the slickest app to be found in the store.
The second way is the way of change, to stay in tune with the new world of
technology. This requires radical moves – to cope with applications ranging from
well known trains and buses, to adventurous cars and scooters.
Allow me to congratulate and thank the authors and editors of this book: they
show the courage to innovate, and the stamina to build on years of applications
and systems intimacy.
Paris, December 2011
Pierre Hessler
Pierre Hessler joined Capgemini in 1993. In his various roles
he had a long and close relation with the former sd&m. Notably, he chaired its supervisory board as the representative of
Capgemini. He was appointed as a member of the Capgemini’s Board of Directors in May 2000; after leaving his general
management functions in 2002, he became a non-voting director. He entertains relations with some of Capgemini’s major
clients and is one of the fathers of TechnoVision (see [8]).
5
6
Quasar 3.0
Foreword
It’s well accepted that IT has become the key technology in all business areas in
the last decade. This phenomenon has broadened the market opportunities for our
business as an IT service provider. Somehow parts of IT have now become a
commodity. Therefore, the global market situation forces our potential and
current customers to ask for efficiency and timeliness of solutions for their
business requirements, which impact the IT. These requirements comprise a wide
range of different IT solutions from smart web-based applications to huge
integrated application landscapes, and from migrating long-standing legacy
applications to building applications based on novel technologies.
Thus, in order to stay competitive and to be successful in this highly dynamic IT
market, we as an IT solution provider had to evolve to meet our customers’
requirements. The driving force, in the past, was our software engineering and
architecture approach which mainly deployed a standardized model for designing
and implementing software solutions. We understand that this general-purpose
process model is still our foundation but it has to be enhanced to cope with the
diversity of our customers, their business domains, and the required IT solutions
aligned to the latest technology. This book contains an appropriate answer to the
changing situation and to the different diversity dimensions, for developing
customised IT solutions in an efficient and timely manner. It’s Quasar 3.0, a
customisable engineering model, which enables our software engineers to tailor
the methodical approach, for developing suitable IT-solutions for today’s business
requirements. Quasar 3.0 is an important step forward for the continuation of our
engineering-based approach to software development based on more than 20
years of software engineering experiences within our company. It has been
developed by our CSD Research team with support from many experienced
software engineers. It not only describes the maturity level of our software
engineers and the architect team. But, it is also in line with our tradition to share
our experiences with our customers, the software engineering community, and the
academic world. I’m absolutely convinced that this book will be of great benefits
to all of the interested stakeholders.
I would like to thank all the authors for their efforts in writing this book. Special
thanks go to Dr. Marion Kremer, our head of CSD Research, as well as to Prof.
Dr. Gregor Engels, our scientific director of CSD Research.
Munich, December 2011
Dr. Uwe Dumslaff
Chief Technology Officer and Member of the Management
Committee Application Services Capgemini Germany
7
8
Quasar 3.0
This book
Industrial software development has to cope with constantly increasing cost, time,
and quality requirements, which require an effective, efficient, and economic use
of available resources for developing novel IT-solutions. CSD Research as a
division of Capgemini Germany provides the software development methodology
Quasar as an answer to this challenge. Quasar stands for Quality Software
Architecture (see [32]). The goal of Quasar is to provide all methodical means for
software engineers and enterprise architects to produce their results in a very
professional way.
Quasar 3.0 adds the situational aspects to Quasar. It comprises of a tailoring
method, which allows customisation of a software development according to the
needs of a specific project situation. It supports to compose a set of methodical
building blocks into a full-fledged software development method. Thus, instead of
deploying a company-wide general-purpose software development method,
Quasar 3.0 comes along with the framework for the definition and use of
situation- and project-specific development methods. Therefore we also talk about
eee@Quasar (efficiency, effectiveness and efficiency of price), accentuating the
fact that efficiency etc. do mean different things in different contexts.
The objective of this book is twofold. First, it provides an overview of the basic
framework of Quasar 3.0, i.e. its customization method as well as its constituents
comprising domains, disciplines, and activities. Second, to illustrate its
distinctiveness compared with other development methodologies, we illustrate
some of the most notable features of Quasar 3.0 using examples of particular
engineering patterns for the development of IT landscapes and custom software
solutions. An extensive description of each of Quasar 3.0’s disciplines can be
found in separate documents that are referenced at the end of this book.
The aim is not to substitute good books on software engineering but to help
through the rising complexity in this area by providing concrete structuring means
based on concrete project experience.
Even if Quasar was originally developed for internal use at Capgemini, this book
will hopefully provide new insights to software engineers, both business architects
and technical architects undertaking software development in and outside
Capgemini.
This book describes the current version of our ongoing work. So if you are
interested in further information, please contact us.
We hope you will enjoy reading our book!
The team of authors
9
10
Quasar 3.0
Authors
Overall concept,
eee@Quasar,
Domains Design
and Development
Overall concept,
eee@Quasar
Prof. Dr. Gregor Engels
Dr. Marion Kremer
Prof. Dr. Gregor Engels is the Scientific
Director of CSD Research at Capgemini
and has a chair of computer science at the
University of Paderborn. His research
interests are software architectures,
model-based software development, and
quality assurance techniques.
Dr. Marion Kremer, a Computer Scientist
with a PhD in Computer Science, has been
working since 15 years in customer
projects in different roles with Capgemini
(former sd&m). She is heading CSD
Research since end of 2009. Her major
research interest is software engineering
and how it can help to effectively fulfil
customer needs.
11
Domains
Requirements
Engineering and
Analysis
Domains Design
and
Development
Thomas Nötzold
Thomas Wolf
Thomas Nötzold has been working since
25 years as a team and project lead,
software architect and consultant mainly
for banking and insurance companies. His
focus points are Requirements
Engineering, Specification and model
driven development.
Thomas Wolf has been working for
Capgemini since 11 years as a developer,
consultant and senior technical architect
mainly for the automotive industry. He
has designed frameworks that help in
building component oriented software for
large-scale projects. He leads a group of
top architects of Capgemini to distill their
experiences of building flexible and long
term software architectures into the
architecture guidelines for application
design of Capgemini.
Domain
Software
Configuration
Management,
Evolutionary
Quasar
Methodology
Domain
Software
Configuration
Management
Dr. Karl Prott
Jörg Hohwiller
Dr. Karl Prott has been working with
Capgemini since 1998 and was very
successful in designing and handling the
architecture for big software projects.
Furthermore he’s an expert for the service
oriented realization of cross application
processes and the design of complex
application landscapes.
Jörg Hohwiller has been working for
Capgemini since almost 10 years. He has
gained in-depth knowledge about all
phases of software engineering. His
passion is to design the software
architectures. Currently he is working on
the business process management
approach to increase the flexibility and
efficiency of IT solution development.
12
Quasar 3.0
Domain
Analytics
Domain
Analytics
Alexander Hofmann
Dr. Andreas Seidl
Alexander Hofmann is working as a
Business Area Head with Capgemini. His
area of focus are technical design and
project mangement for big software
development projects. In addition to this,
he leads the Competence Centre
Architecture. From 2006 - 2009 he was
heading the CSD Research department of
Capgemini, developing beside others
Quasar Analytics methods and tools.
Dr. Andreas Seidl has worked for
Capgemini as a test manager and business
analyst before joining CSD Research in
2010 to promote analytical quality
assurance.
Evolutionary
Quasar
Methodology
Domain
Enterprise
Dr. Diethelm Schlegel
Oliver F. Nandico
Dr. Diethelm Schlegel is a part of
Capgemini’s CSD Research team. In his
professional career of more than 20 years,
he has acquired expert know-how in many
different science fields like software
architecture, computer networks, IT
security, and project management. At the
moment, he explores the development of
methods and best practices in the area of
service oriented architectures and business
process management.
Oliver F. Nandico is a Certified Enterprise
Architect and works as Principal
Enterprise Architect at Business
Technology of Capgemini Germany,
where he leads a team of architects.
His 20 years of professional experiences
comprehend the shaping of architectures
of entire IT landscapes, the design of large
information systems and the introduction
of enterprise architecture management,
covering all aspects of architecture.
He also advises on the subjects of
enterprise integration as well as
architecture management and governance.
13
This book is based on the Quasar 2.0 - Software Engineering Patterns [13]. The
new version is in most parts intensively reworked and reorganized. Some chapters
are even new. So the domain structure is more aligned with RUP (especially in the
context of software configuration management), the offshore topic is integrated in
the other domains, the situational aspects are as well introduced as the BPM topic.
But, even if this book is definitely a rework of [13] it cannot and does not want to
hide its roots. Therefore we explicitly name the authors of the predecessor version
in this chapter as well.
Authors of [13]
Prof. Dr. Gregor Engels, Alex Hofmann
Bettina Duwe
Ralf S. Engelschall
Oliver Flöricke
Dr. Frank Salger
Melanie Wohnert (geb. Späth)
Johannes Willkomm
Thomas Wolf
14
Quasar 2.0 Overall Concept
Artifact Model, Measurement
Discipline
Development Subdomain,
Assembly, Configuration
Requirements Subdomain,
Analysis Discipline
Offshore CSD (OCSD) Domain,
Analytics Subdomain
Analytics Subdomain
Enterprise Domain
Design Discipline
Quasar 3.0
Contents
1
2
Motivation and Introduction
19
1.1
Demanding market requirements . . . . . . . . . . . . . . . . . .
19
1.2
Quasar 2.0: The History and Basic Concepts . . . . . . . . . . . .
20
1.3
Quasar 3.0: An Extension of Quasar 2.0 . . . . . . . . . . . . . .
22
1.4
Future prospects . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
1.5
Document Structure . . . . . . . . . . . . . . . . . . . . . . . . .
23
The Quasar 3.0 Framework
25
2.1
Domains and Disciplines: the Backbone of Quasar . . . . . . . .
25
2.2
Enterprise Architecture Management and System Development . .
28
2.3
The Situational Approach . . . . . . . . . . . . . . . . . . . . . .
29
2.3.1
Relevant Characteristics and Their Clusters . . . . . . . .
31
2.3.2
Definition of Types . . . . . . . . . . . . . . . . . . . . .
35
2.3.3
The Integration . . . . . . . . . . . . . . . . . . . . . . .
40
Usage of Quasar 3.0 in a concrete project . . . . . . . . . . . . .
41
2.4
3
4
The Requirements Domain
43
3.1
Basic Methodology . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.2
The Industrialised and the Manufactural Approach . . . . . . . .
46
3.3
Offshore Methodology . . . . . . . . . . . . . . . . . . . . . . .
48
The Analysis & Design Domain
49
4.1
The Analysis Discipline . . . . . . . . . . . . . . . . . . . . . . .
50
4.1.1
Basic Methodology . . . . . . . . . . . . . . . . . . . . .
50
4.1.2
Industrialized Methodology . . . . . . . . . . . . . . . .
50
4.1.3
Manufactural Methodology . . . . . . . . . . . . . . . .
55
4.1.4
Offshore Methodology . . . . . . . . . . . . . . . . . . .
56
The Design discipline . . . . . . . . . . . . . . . . . . . . . . . .
58
4.2
15
Contents
5
6
58
4.2.2
Industrialized and Manufactural Approach . . . . . . . .
63
4.2.3
Offshore Methodology . . . . . . . . . . . . . . . . . . .
64
67
5.1
Basic Methodology . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.1.1
The Implementation discipline . . . . . . . . . . . . . . .
67
5.1.2
The Debugging discipline . . . . . . . . . . . . . . . . .
71
5.2
Industrialized and manufactural Approach . . . . . . . . . . . . .
74
5.3
Offshore Methodology . . . . . . . . . . . . . . . . . . . . . . .
74
The SCM Domain
75
6.1
The Configuration Discipline . . . . . . . . . . . . . . . . . . . .
76
6.1.1
Version Control . . . . . . . . . . . . . . . . . . . . . . .
77
6.1.2
Issue Tracking . . . . . . . . . . . . . . . . . . . . . . .
79
6.1.3
Artefact Management . . . . . . . . . . . . . . . . . . . .
80
6.1.4
Version Identification . . . . . . . . . . . . . . . . . . . .
82
The Build & Deployment Discipline . . . . . . . . . . . . . . . .
83
6.2.1
Build Management . . . . . . . . . . . . . . . . . . . . .
83
6.2.2
Deployment Management . . . . . . . . . . . . . . . . .
88
The Release & Change Discipline . . . . . . . . . . . . . . . . .
91
6.3.1
Change Request Management . . . . . . . . . . . . . . .
92
6.3.2
Release Management . . . . . . . . . . . . . . . . . . . .
93
6.3
The Analytics Domain
97
7.1
98
7.2
16
Basic Methodology . . . . . . . . . . . . . . . . . . . . .
The Development Domain
6.2
7
4.2.1
The Quality Inspections discipline . . . . . . . . . . . . . . . . .
7.1.1
Basic Methodology . . . . . . . . . . . . . . . . . . . . . 100
7.1.2
Offshore Methodology . . . . . . . . . . . . . . . . . . . 103
The Measurement discipline . . . . . . . . . . . . . . . . . . . . 104
7.2.1
7.2.2
The Offshore Methodology . . . . . . . . . . . . . . . . . 108
Quasar 3.0
7.3
8
9
The Test discipline . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.3.1
7.3.2
Manufactural Methodology . . . . . . . . . . . . . . . . 118
The Evolutionary Approach
121
8.1
Impact on Requirements Engineering . . . . . . . . . . . . . . . 121
8.2
Impact on Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 122
8.3
Impact on Design . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.4
Impact on Development . . . . . . . . . . . . . . . . . . . . . . . 127
8.5
Impact on Software Configuration Management . . . . . . . . . . 128
8.6
Impact on Analytics . . . . . . . . . . . . . . . . . . . . . . . . . 130
8.7
Impact on Operations and Monitoring . . . . . . . . . . . . . . . 131
8.8
Impact on Project Management . . . . . . . . . . . . . . . . . . . 132
The Enterprise Domain
135
9.1
The Term Enterprise Architecture . . . . . . . . . . . . . . . . . 135
9.2
The Quasar Enterprise® Method . . . . . . . . . . . . . . . . . . 136
9.3
Architecture Context . . . . . . . . . . . . . . . . . . . . . . . . 139
9.4
The Business Architecture Discipline . . . . . . . . . . . . . . . 142
9.5
The Information Architecture Discipline . . . . . . . . . . . . . . 145
9.6
The Information System Architecture Discipline . . . . . . . . . . 148
9.7
The Technology Infrastructure Discipline . . . . . . . . . . . . . 154
A Appendix: Situational Software Engineering
157
A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
A.2 The framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
A.2.1 Development of the framework . . . . . . . . . . . . . . 160
A.2.2 Usage of the Framework . . . . . . . . . . . . . . . . . . 166
Bibliography
167
17
Contents
18
Quasar 3.0
1
1.1
Motivation and Introduction
Demanding market requirements
Capgemini’s customers employ modern and dynamic business models that
function in large IT landscapes. In order to stay competitive, they must be able to
quickly deliver innovative new business products to the dynamic market. The
ability to change business processes at frequent intervals is essential to their
success. Therefore, they need high-quality IT solutions which put them ahead of
the competition in the mission critical areas of their businesses.
All in all, information technology has become a key success factor for the fast
evolution in the business world.
Specifically, IT solutions must nowadays be able to respond to the following
requirements:
Alignment of business and IT: The IT landscape and its systems have to be
flexible enough so that they can support the rapid integration of new
business requirements. The software development approaches and
architectural design methodologies deployed must provide for the
transformation of business requirements into IT solutions.
Low cost of ownership: Build for change is the design principle that must
govern applications and IT landscapes, so that the cost of maintenance and
operation is minimized. Solutions have to be structured in accordance with
well-defined architectures that comprise replaceable standard and custom
components having clearly defined interfaces.
Decreased release time: Today, the release milestones for software production
are directly linked to our customer’s market milestones. Therefore, effective
software development processes and appropriate tools and methods are
needed.
Increased scope: Custom software solutions are being integrated into
large-scale, heterogeneous IT landscapes. Any software development
approach must be based on a global overview of an IT landscape that takes
into account both business requirements and IT requirements.
Increased diversity: Software solutions can be differentiated in an increasing
number of dimensions. They might be, e.g., web-based or embedded, used
by single or multiple users, used by experienced or occasional users,
deployed in local environments or in a network environment, stand-alone or
as part of an integrated solution. Thus, an effective and efficient software
development has to take into account this diversity of the software solution
to be developed.
19
Chapter 1. Motivation and Introduction
Increased complexity: The integration of standard package and custom software
solutions is becoming increasingly important. Software developers must be
familiar with both open-source and vendor product portfolios, as well as
effective techniques for enabling robust service-based integration with
custom software solutions.
Increased demand for standard compliance: In order to allow for legal
compliance, high interoperability, reusability as well as understandability of
components, the importance of using technology and language standards
for the realization of software solutions is constantly increasing.
Distributed software development: Today, software is being developed in
distributed teams. Our strategic decision with regard to production depth
permits attractive pricing models and addresses today’s increased
competition by offering flexible concepts for the distributed development of
software solutions. Additionally, our customers are demanding
collaborative delivery models that include more than one development
partner.
This list makes clear, that quality is not quality in an absolute sense and not in
every case a software is needed with a perfect algorithm. Therefore, in our sense
(and in the one of EN ISO 9000:2005) quality is a measure for reaching the
concrete requirements.
1.2
Quasar 2.0: The History and Basic Concepts
These changing and ever more competitive market requirements have a
substantial impact on the way that software is being developed. An industrialized,
engineering like software development process is needed to meet all these
requirements. Particularly, a high quality of developed software products have to
be guaranteed, where resources like budget, time and personnel are deployed in an
efficient, effective and cost-conscious way.
Capgemini has striven to develop high-quality custom software solutions since its
inception decades ago. Subsequently, an important asset has been the
company-wide agreement on the common architectural style for structuring
software systems that is known as Quasar (Quality Software Architecture, see
[32]).
As any industrial software development methodology needs to be based on
existing standards, e.g. process standards like RUP™ (s. [22] and [24]), quality
standards (ISO 9126), modelling standards (e.g. UML), architectural frameworks
like TOGAF or IAF, and de facto standards like ISTQB and ISAQB, Quasar 2.0 is
based on these open standards, too. This standards-driven approach is a central
issue for our customers.
To enable it to cope with today’s demanding market requirements, Quasar has
20
Quasar 3.0
been enhanced by transforming it from a design centric framework towards a fully
fledged software development methodology for custom software development
termed Quasar 2.0 (s. [13]).
According to RUP™ Quasar 2.0 is structured into domains like Requirements,
Analysis & Design (see figure 1.1). It offers concrete methodological guidelines
and tools for the entire software development process. Quasar 2.0 applies
particular construction techniques (light blue in figure 1.1) for designing,
developing, building and deploying both IT landscapes and custom applications,
as well as analytical techniques (dark blue in figure 1.1) for the parallel assurance
and control of quality.
Figure 1.1: Quasar 2.0 (reduced to the core)
©2011 Capgemini. All rights reserved.
The activities are the backbone of the disciplines. Each activity is characterized
by its interface, i.e. input and output artefacts, as well as several methodical
building blocks as accelerators like a method description, a set of best-practice
engineering patterns, tailored tools and utilities, and pre-fabricated software
components or frameworks.
The engineering patterns are the result of the intensive investigation and
identification of commonalities in development projects previously undertaken by
Capgemini, combined with the latest insights from software engineering research.
They make the method easily accessible and immediately usable, and differentiate
it from comparable generic approaches.
Quasar 2.0 separates the process-related aspects from the particular software
development methodology. The discipline-oriented structure permits a clear
separation of concerns with respect to tasks and responsibilities within the
21
development process. Accordingly, resources such as personnel, budget and time
are all expended in an optimized, cost efficient manner. We are able to offer
flexible process models that ensure a well-balanced, distributed delivery of
software components. We achieve a continuous alignment of requirements and
solutions that supports (if needed) traceable links between all development
artefacts, thereby preventing the possibility of an overlooked or misunderstood
functionality arising within a solution. Right from the beginning, our Build for
change approach takes future evolution into account, resulting in a low cost of
ownership. Accordingly, Quasar 2.0 does not represent a monolithic approach.
Instead concrete methodical building blocks can be exchanged if there is a need
for as for example in case a customer’s IT department insists on using a specific
tool in a customer project.
For further enhancement of efficiency (i.e. cost reduction) Capgemini added the
Rightshore® approach to our delivery model. This means we find the right shoring
model with resources onsite, from near-shore locations and from far-shore
locations. Going truly global adds a new class of problems: different languages,
cultures and time zones can have a major impact on a project. In order to cope
with requirements resulting from distributed and off-shore developments, Quasar
2.0 has been already enhanced with methodical elements to cope with the
increased risks associated with offshore projects. System specifications might not
be detailed enough for offshore developers because they lack contextual
information. Development is based on diverging understandings of what code
quality consists of. Project management is complicated due to differing estimation
methods on the part of the onshore and offshore teams. The handover of
deliverables and responsibilities between the distributed teams happens in an
unsynchronized and uncontrolled manner. Knowledge transfer becomes a major
issue. All this makes the development process more difficult to manage, and could
put the success of the project at risk. Thus, adapted and novel methods and tools
have been defined and added to Quasar 2.0 under the name Offshore Custom
Software Development Method (OCSD Method). This method enables to
effectively control production depth and to assure the overall quality during the
entire project across all sites.
1.3
Quasar 3.0: An Extension of Quasar 2.0
As we found that one methodology for software engineering projects does not fit
in all cases, Quasar 3.0 – described in this book – adds the situational approach
to Quasar 2.0. It supports an optimal choice between efficiency, effectiveness, and
cost-effectiveness resulting in economic development processes. The overall goal
is to provide a software development method for each project that fits best the
needs of that project while gaining as much standardization as possible.
To reach this situational dependency each of the methodical building blocks of
Quasar 2.0 mentioned above is tagged as usable for the situations it is appropriate
22
Quasar 3.0
for (multi tagging is possible). A step-wise selection process supports the
architect or project leader to compose a concrete method bundle out of these
methodical building blocks. In parallel he uses analogous criteria to identify the
right software development process model.
The offshore extension OCSD of Quasar 2.0 can be viewed as an approach to
react to the requirements of a special project’s situation, in this case of handling
offshore development. But, offshore projects are only an example of possible
diversity of a development project. Thus, the next step in enhancing and
improving Capgemini’s software development method is to generalize this idea
and to develop an extended methodology, termed Quasar 3.0, which consists of
methodical building blocks that can be composed into a concrete software
development process model and method according to the current project’s
situation.
Augmenting of specifications so far that a direct automatic interpretation becomes
possible breaks somehow the concept of artefacts being used as input to produce
something different as output of a concrete method. Augmenting of artefacts
results in input artefacts that are the same as the output artefacts for a given
domain. In addition at least part of the development is done implicitly within the
analysis. Therefore, the semantics of analysis and development change. To reflect
this appropriately we introduced an additional evolutionary approach to Quasar
3.0.
1.4
Future prospects
Quasar 3.0 is not an academic exercise, but the result of a joint effort on the part
of Capgemini as a whole. It has been defined and described by members of
Capgemini’s CSD Research team, which consists of experienced Capgemini
software engineers and architects. It has been reviewed and commented on by
numerous software engineers and IT architects working at Capgemini.
We are already sure that Quasar 3.0 is not the end of the methodology evolution.
As the used standards will be developed further, Quasar will change, too. This
book will help to go on with the joint effort, to improve our software engineering
methodology, to cope with future requirements of the business.
1.5
Document Structure
The following chapter describes in detail the structure of Quasar 3.0 and
introduces our situational approach for the engineering part of it. Using this as a
base we describe each of the engineering domains together with their artefacts and
the methodical building blocks in a structure reflecting the situational approach.
Hereby the focus of this book is not on all building blocks, but on patterns that
have to be thought of for efficient, effective and price economic software
23
development by using Quasar 3.0. The patterns provided are described in the
following way:
Pattern 1: Example Pattern
Short description of the Pattern
After the pattern itself we typically provide further information on this pattern, it’s
usability etc.
The evolutionary approach is dealt with in a separate chapter because of its
integrative structure over the domains. Lastly, we describe the Enterprise domain,
where we do not have the same situational structuring as in the other domains
because up to now we did not meet the need for that.
Capgemini follows an open book approach, sharing its knowledge and experience
of development methods with its customers. This is supported by an open
ontology in which all the terms used, plus the artefacts and responsibilities, are
defined. In conjunction with our customer’s input, this enables implementation of
well defined cooperation models, with a high level of transparency during the
development process; in other words, it helps everyone to speak the same
language.
In the appendix, you find more about the underlying conceptual and theoretical
framework.
24
Quasar 3.0
2
The Quasar 3.0 Framework
In this chapter we present our approach to situational software engineering,
Quasar 3.0.
2.1
Domains and Disciplines: the Backbone of Quasar
Traditional software engineering approaches, structure the tasks to be fulfilled in
an enterprise or a custom software development (CSD) project into domains. In
accordance with this we follow the IBM™ Rational Unified Process™ (RUP™),
both a Capgemini and an industry standard for this (s. [24] p. 45 and [22]). The
Quasar backbone is formed by its constituent disciplines. All Quasar disciplines
are grouped into subdomains and domains. Figure 2.1 details the Quasar 3.0
domain structure. It consists of four domains: Enterprise Architecture
Management (EAM), System Development (SD), Project Management (PM), and
Operations.
Figure 2.1: The Quasar 3.0 domain model
This structure covers other types of projects as well. In particular, Quasar may be
applied for projects where the solution is based on packages or the integration of
customised solutions with modernized legacy systems. This does not only apply
to new or different areas of software engineering, but for different methods and
tools provided for each discipline. Therefore, "System Development” is referred
to as the respective domain, and is not limited to custom solution development.
25
Chapter 2. The Quasar 3.0 Framework
The focus is on shaping the complete IT landscapes and the custom development
of individual systems. Currently maintenance or operations are not covered, but
are taken into consideration while defining our methodology and approach. This
results from the strong impact of these Quasar domains on the requirements for
the earlier phases.
Each of the Quasar 3.0 domains is structured into disciplines that consist of
activities. They operate on input artefacts which the project team uses to construct
the output artefacts. These transformation steps are supported by
discipline-specific
methods,
sets of best-practice engineering patterns,
tailored tools and utilities and
pre-fabricated software components or frameworks
These supporting elements are the building blocks of our methodology. For
special purposes we cluster them in sets, which then build the methodology for
the particular purpose.
The disciplines of the Enterprise Architecture Management (EAM) domain focus
on defining the requirements and architecture of an IT landscape while the custom
solution development disciplines support the development and deployment of an
individual software system.
Understanding the challenges and requirements of our customers is the purpose of
the Requirements Engineering domain, which incorporates the activities
necessary for professional requirements management.
Based on the resulting requirements artefacts, the disciplines of the Analysis &
Design domain include activities for modelling and structuring the solution.
The disciplines of the Development domain define activities for implementing and
debugging information systems efficiently.
Following this, applications are built and deployed by the activities of the
disciplines within the Software Configuration management domain. Additionally,
product deployment, release and change management are supported. The
resulting artefacts have to be constantly checked to ensure that they meet quality
requirements. This is a mission critical task especially in a distributed
development scenario.
The disciplines of the Analytics domain comprehend the associated quality
assurance activities.
26
Quasar 3.0
This structure of Quasar 3.0 domains and disciplines is quite similar to RUP™.
The differences between RUP™ and Quasar 3.0 result from the following reasons:
The Enterprise Domain includes the Business and Information architecture,
and exceeds the respective scope of RUP™, for details see section 2.2
Development relates to Implementation in RUP™ extended by Debugging
Analytics includes Test, but also includes additional activities
Deployment, Configuration and Change Management in RUP™ are
reorganized due to the System Development focus (see table 2.1):
In Quasar we recognise Build and Deployment Management instead
of just Deployment, because we think of Build being critical and
non-trivial
Configuration & Change Management are separated into
Configuration and Release & Change Management because of their
different nature
We skipped Environment because these activities are mapped to other
domains
We have added Operations because the operations requirements have to be
taken into account during analysis, design and analytics. To be compliant
with an industry standard, we choose ITIL [1] for structuring the
Operations domain. We have refrained from describing it in detail, as it is
not a part of the core Software Engineering
Project Management (PM) is structured according to PMI [28], considering
that we talk about relevant process groups instead of domains. The selected
software development process model guides the combination of all
activities within a discipline. The appendix shows further details. [7]
provides more information about our understanding of PM.
We have added an explicit super domain for the software development (SD) to
make the cooperation between domains within SD and process groups and
Operations more apparent.
RUP™
Deployment & Build
Configuration & Change Management
Quasar 3.0
Deployment
Configuration
Release & Change
Figure 2.2: Comparison of RUP™ and Quasar
27
2.2
Enterprise Architecture Management and System Development
To derive the right architectural decisions it is necessary to have a close look at
the entire IT-landscape. But, the design and evolution of an IT-Landscape cannot
be achieved without knowledge on the individual information systems.
Therefore, we see the Enterprise Architecture Management (EAM) and the
System Development as closely related.
One major task for the EAM is the description of business and information
architecture. In the context of IT landscape we see architecture principles which
we later apply within the system development model, i.e. Analysis and Design.
An example of such a principle: Ensure as little coupling as possible between the
domains while at the same time to be assured the domain is self-contained.
The level of detail for the EAM depends on its purpose. When the required level
of detail is achieved, the scope changes to individual solutions. The use cases
derived from information system services become the requirements for individual
information systems, regardless of being implemented as custom developed or a
package based solutions (see figure 2.3).
Figure 2.3: The constructive flow illustrates the transformation of content between the
disciplines
This process is similar to the one used for the design of a concrete system as we
have in both cases stepwise refinement (see figure 2.4).
28
Quasar 3.0
Figure 2.4: The Way from outside a system to the inside
The top down process for the development of an IT landscape alone is incomplete,
changes to the requirements discovered during the design of information systems
are to be fed back to the enterprise level.
This two way approach becomes crucial for the implementation of a service
oriented architecture, where common integration patterns are defined at the
enterprise level. Changing the functional scope of a service may affect the whole
IT landscape, e.g. considering BPM.
2.3
The Situational Approach
Our situational approach focuses on building individual information systems. We
do not differentiate on EAM projects, because up to now we use the same
methods and tools for all of them.
Our situational software engineering approach consists of various elements:
the software development process models and the software engineering
methods, tools etc. that are used to build the software in the given
environment/situation. These are methodical building blocks clustered
along with the Quasar 3.0 domain structure.
the software projects/systems themselves
We categorize all of them to govern the development process to achieve efficiency,
29
effectiveness and price economics (eee@Quasar). Our goal is to help identify the
right building block out of two or more given ones for a given situation. So we are
looking for the differentiation of production means on the one hand and of
systems on the other so that waste is avoided.
Figure 2.5 shows this in a more allegory way: we will not use a hammer for each
project, but only when appropriate. An example within software engineering: it
may be helpful to have more than one methodology for the analysis domain, to
deal with different situations like the function-identical migration of a software
system or the design of an innovative functionality together with the customer.
Figure 2.5: Building Blocks versus Systems (allegorical)
Based on our experience this results in a differentiation between a more
industrialized versus a more manufactural approach:
Industrialized Approach with a high degree of division of labour and
optimization of single steps and Therefore, efficiency, reproducibility,
traceability and standardization; with a parallel low in house production
depth
Manufactural Approach with focus on flexibility and creativity and only little
standardization
30
Quasar 3.0
In the following chapters we show which attributes are used to differentiate the
methodical building blocks and the systems and bring these elements into relation.
This chapter follows the approach presented in a more abstract way in the
appendix.
2.3.1
Relevant Characteristics and Their Clusters
We categorise our methodical building blocks along the following parameters:
Way of Requirements Engineering and Quality Assurance: In the case of a
Greenfield project, where there is no blueprint (= old system) and where
business requirements are still to be defined with the customer, requirement
engineering is methodically completely different from a migration project
where a 1:1 – replacement of an existing system is needed. The same is
valid in the case of configuration projects, where an existing (standard)
software is to be adapted, or in the case of integration projects, where a
multiplicity from existing services is composed into a new application. The
equivalent is valid for the other domains.
Necessary sustainability of architecture: Usually a project team with low skill
sets requires a much more strict packaging of extremely complex facts
which a highly skilled team could do without. This means methodical
building blocks are required in the first case, that guarantee, for example via
encapsulation, technical prototypes etc., a stable architecture with the
appropriate characteristics is developed. The same is valid, if high demands
are made at non functional requirements like performance etc. It is
meaningful here to take an explicit design phase into account with which
the architecture of the future system is developed and examined according
to the requirements. The super ordinate design principles are to be specified
in order to retain their consistency over the entire engineering process.
Necessary sustainability of technology: If we have to ensure that the
technology used for the system will have a longer life time than the usage
of proven and widely spread technology with slow upgrade cycles is
sensible. The underlying technical basis has also to be taken into account as
it is not helpful to upgrade the entire operating system for a minor business
change. One major challenge in this area is the forecast of the lifetime of
the used products. The usage of a framework that determines the entire
architecture of a system has to be well though of if the system has to be
used for 20 years and the source code for the framework is not accessible.
On the other hand it is not necessary to restrict oneself to "old fashioned”
technology if only short life time is required. This requirement is very often
difficult to realize because of the prerequisites especially for the user
interface where the complexity and appearance wanted very often can only
be gained efficiently with modern components and frameworks.
31
Kind and amount of necessary documentation: The sourcing in a project and
the maintenance phase determines heavily how much and what kind of
documentation is necessary. In purely onsite projects where all members
have at least a common cultural and linguistic understanding the
requirements for documentation are less than in projects where these
prerequisites do not hold or where the team members are staffed on phases
not on components (see [30]).
The same holds for the documentation of decisions. Depending on the
context it is sufficient to document only the decisions themselves or the
complete process has to be written down.
Complexity of project setting: This complexity results from the complexity of
the methodical building blocks, maximum team size and shoring concept. It
can be economically meaningful in a long-term project to use a more
complex development methodology with appropriate tools if this reduces
the pure developing and ramp up cost for new colleagues.
Similarly a team with 100 co-workers needs another methodology than one
with two colleagues, who sit at one table.
We differentiate several software development process model types (see [17]).
These models are based on industrial standards (see figure 2.6).
Figure 2.6: Different Software Development Process Models
32
Quasar 3.0
Agile: an evolutionary approach with time boxes, iterations, following the agile
manifesto and agile principles
Iterative: Sequence of non-overlapping development cycles (iterations) of less
than 3 months, prioritized by risk and business value
Incremental: Piece (increment) wise realization of functionality
From our experience it is clear that we do not have to look at the characterisation
of projects but at the systems and their environment, because we not only have to
take into account the initial project but the maintenance phase, too.
To find out which systems fit for the industrialized approach or the manufactural
approach we differentiate our systems along the characteristics in figure 2.7 on
page 34. The sourcing model hereby may include internal sourcing, so for
example if testers come from a different division.
33
Figure 2.7: Characteristics of systems
Structural Dimension
Business or Problem characteristics
degree of substitution of an existing
system (low=green field)
requirements dynamics
number of differentiating business services
problem size or number of services to
be provided
user interaction complexity
neighbouring systems complexity
dependency between components or
features
safety requirements
lifetime
environment / context
client culture
expected customer participation
possible degree of off-shore (low = all
on-shore)
possible degree of outsourcing (low =
inhouse)
possible acceptance of package-based
solutions / open source
priority of time vs. scope
sourcing concept
skill-level
team changes over life time
amount of necessary traceability of decisions
operations internal operations vs.
cloud (multi-tenant) vs. external)
necessary NFA’s (performance, reliability, etc.)
way of operations
Extremes
low - high
low - high
low - high
low - high
low - high
low - high
low - high
low - high
low - high
agile - plan-driven
low - high
low - high
low - high
low - high
time - scope
onsite - offshore
low - high
low - high
low - high
internal - external
low - high
centralized - distributed
34
Quasar 3.0
2.3.2
Definition of Types
We build clusters on the above characterised systems to get a manageable number
of system types. We use transport means to describe our system types following
[8]. So we identify two extremes:
The Scooter: To a considerable degree, these projects dynamically compile
and/or in the further life cycle repeatedly change the business requirements
together with the customer. The speed of the solution development and the
innovative character of the solution are of crucial importance, while a long
maintenance phase is not in the focus.
Typically we are not talking about small, standard Scooters but about
high-tech Scooters. This Scooter does not need to follow a fixed path but
can go in any direction. On the other hand as the focus of the Scooter does
not lie on efficiency only a few people or goods can be transported (to stay
within the metaphor). Here it is possible to replace reasonable efficiency
and thus speed up effectiveness: if required a development path is pursued,
which does not go into production, but helps the business to decide a
solution. Comprehensive documentation is of little help, due to the rapid
changes.
Typically this type of system comes along with a complex user interface,
which would preferentially require “state of the art” technology necessary
for the conversion and the development environment. Long term
architecture is not the criteria here as it would continuously alter as per the
current business requirement. It may be beneficial to use innovative
components and frameworks for building the system as sustainability of
these would be of minor importance. At the same time organically
fundamental architecture principles may not be neglected, because such
applications may also have high non-functional requirements. Furthermore
they are often embedded into a more complex application landscape, which
may no effected by all the applications changes.
It is often counter productive to aim for small unit cost prices (i.e. usually
small labour costs), as the high degree of innovation and the necessary
conversion speed requires the co-workers to work locally. At the same time
it can be very meaningful to invest into tools in order to achieve the desired
speed.
In the extreme version of this type, the assumed life time is relatively short.
If this changes and the implemented business functionality becomes more
stable, a re-implementation might be a good idea to get into the world of the
tanker.
35
The Train: Frequently we have a situation where a new system, which exhibits a
substantial life expectancy, has to be built to replace an already long
running core system. As a result of this, the maintenance is given weightage
and by extension even the related matters pertaining to sustainability.
Simultaneous, the team changes are counted on the basis of long
maintenance phase. So, clearly more effort is being invested in an
appropriate documentation. Simultaneous, here it is important to ensure
that technology, methodology and tools as well as the architecture are
suitable for sustainability and for team changes.
For this type of system, effectiveness and price economics are of central
importance, because a large number of goods or people are to be transported
(i.e. transaction to be executed, data volume to be managed and interfaces
to be served). Therefore, changes take much more time than in the case of
the Scooter. This is reflected in the visual needs of the railway network.
In reality, typically none of these two extremes really occurs. Instead, we often
have Trains with fast changing requirements for the GUI (graphical user
interface), sometimes even Scooters have a part (for example interfaces) where
stability is important. Therefore, we introduce two more types that are mixtures.
These help to differentiate in size and degree of requirements volatility.
The Overland Bus: This is the big mixture. This means it has a Train basis with
long lasting business components as well as components that are realized as
Scooters because it is quite clear from the beginning that here we will have
a lot of change in the business requirements over time. Metaphorically,
these changes are related to the WC, the bar and the coffee machine.
Overall, the Bus does not need the same kind of stable infrastructure as a
Train but typically comes along with a more or less stable timetable. For a
Bus, it is vital to define which components are of the Train type and which
ones are more of the Scooter type in the beginning of the project and to
choose the appropriate methodology (and perhaps software development
process model). Simultaneously it has to be taken into account, that we can
gain effort, speed and maintainability through homogeneity.
The Car: She is the little sister of the Bus. Here, it is usually not helpful to
distinguish in the methodology to be used because the possible synergy
effects are too little. It is better to decide in the beginning what type is the
more relevant and to choose the methodology accordingly.
These traffic means and their relationships are shown in figure 2.8. The graphical
representations of the different traffic means used here are taken from [8].
Again following [8] we introduce a fifth type of system, The Hub. The Hub does
not really provide business functionality of its own but builds the platform, to
which all other system types can be connected. Looking at it from the enterprise
36
Quasar 3.0
Figure 2.8: System types and their interdependencies in an overview
perspective, it implements the integration pattern for the entire landscape. From
an engineering point of view the Hub is a separate kind of system but the
development methodology needed in most cases has the same characteristics as
the Train because it must provide a lot of stability. Therefore, we do not look at it
in detail in the following discussion.
The situational approach follows the ideas described in the appendix (chapter A).
It contains both the industrialized and the manufactural methodology box as well.
As they both come from a more sequential approach (the classical one), we
additionally identified a more evolutionary approach.
Since long there has been the idea to produce a specification that can be directly
used as an executable (or interpretable) file. Up to now, this goal has not been
fully achieved, but there are steps in this direction: model driven development
(MDD) is very promising by generating specification, additional documentation,
and implementation from a single source. UML based approaches, however, may
cause problems with respect to round-trip engineering whenever the generated
artefacts need to be manually modified later on. Model changes could
automatically be incorporated into the generated artefacts as long as the
modification is kept apart from the generation results. But virtually no UML
based MDD tool kit sufficiently supports this separation leading to a lot of
unnecessary effort for adapting the generated artefacts. To prevent this, the source
has to be expressive enough to generate the full result without the need for
37
changing it manually afterwards. This is addressed by domain specific languages
(DSL) that are specific to particular domains and therefore, are very expressive in
this area. Such DSLs also include standardized notations for business processes or
business rules.
Using powerful BPM-Suites (BPMS) let the vision become true to model business
processes and make them fully executable based on the same model. This leads to
an evolutionary development approach in which all sub-domains work on the
same artefacts that are continuously enriched and refined. This leverages a large
gain in efficiency as well as more flexibility for changes, so we get the
relationships in figure 2.9.
Figure 2.9: Comparison of the different development approaches
However, the evolutionary approach does not fit in all cases. Especially, in
situations where only few business processes are to be materialised and they
change slowly, the evolutionary approach is perhaps not the right approach
because the BPMS is more expensive than the effort that can be saved over the
time. Another example are real time applications. Using a BPMS implies that the
solution cannot be optimised for very hard timing constraints. So again, we need a
selection method for finding the right model.
For our structuring purpose we find that the different methodology boxes are
connected to each other in the way described in figure 2.10.
Looking now at our methodology portfolio we get a characterization of all
elements (methods, tools, patterns) along with these methodology types. For sure
this characterization is not mutually exclusive. Therefore, we put all the elements
38
Quasar 3.0
Figure 2.10: The different methodologies are related to each other
that can be used with either methodology in the basic one. The basic methodology
contains the ontology. It consists of all the terms used, plus the various concepts,
artefacts and their interrelationships. Thus, it supports a common understanding
within and across different groups of stakeholders, i.e. project members both
onside and offshore plus our customers. While working in distributed teams, this
is a clear precondition for success. It also contains further elements, for
configuration management for example. Using different methodology and tools
for the industrialized and the manufactural approach would make it quite difficult
to build a Bus consistently. Together with the characterization of methodology
elements and the domain structure we get a multi- dimensional approach. To be
able to cope with this complexity we introduced a kind of tagging that allows to
assign a concrete element of the methodology with more than one methodology
type. Furthermore, our methodologies are divided into methods, tools, patterns
etc. (s. appendix A). This results in an additional tag.
Example: The Licence Management Method is tagged with ’Software
Configuration Management’, basic, industrialized, manufactural, offshore
and methodology. So searching in nearly all dimensions (beside BPM)
will provide the same asset.
Thus, it is quite easy to find everything that can be used for offshore delivery or
for the manufactural approach etc. Last but not least we can have more than one
39
asset (typically tools) for the same purpose simultaneously if this helps to fulfil
customer’s needs. On the other hand we can use our methods even if the customer
insists on having his own tool landscape.
Thus, this figure makes it clear that the offshore methodology does not stand
beside but it is seen as an addition to the sequential methodology.
We do not further differentiate the software development process models because
they are self-contained packages, so we take them as they are.
2.3.3
The Integration
On the basis of the above remarks we come to the correlation between systems
types, methodology and software development process model. Figure 2.11 shows
this schematically.
Figure 2.11: Correlation between the different methodologies and system types
Looking at the criteria for systems, software development process models and
methodical building blocks, it becomes quite clear that they match to each other
(otherwise there would be something wrong).
40
Quasar 3.0
2.4
Usage of Quasar 3.0 in a concrete project
On the basis of the approach described above we get one single pattern for the
usage of Quasar 3.0 in a concrete project.
Pattern 2: Categorize your project along with the system types
Be aware of the type of system you are building and choose actively the methodical building
blocks you plan to use along with the above criteria.
Determine the type of system you are going to develop in the proposal phase
itself. Look very carefully on all the system characteristics described above. On
the basis of the system type, build your methodology out of the system
development process and methodical building blocks.
In the following chapters, we provide the description of the activities with their
input/ output structures within a discipline and a lot of helpful patterns for the
enterprise and system development domains in Quasar 3.0. As we cannot provide
this information in this book in the above multi–dimensional structure, we
structure our following description along with the domains and disciplines and
note when a special aspect only holds for some kind of situation. This particularly
means that the OCSD methodology is an integral part of all domains (if there is a
relevant aspect). The only exception we make to this concept is for the
"Evolutionary Approach” chapter (see page 121), because here so many things are
different that it seemed more reasonable to describe this approach in a separate
chapter.
41
42
Quasar 3.0
3
The Requirements Domain
"I have a problem!"
These words, so often expressed by our customers, are the starting point of
virtually all our projects. The initial task in these projects is to identify the
problems our customers are struggling with. So the primary goals of this domain
are to elicit these problems, define the problem space and formulate concrete
requirements with respect to the problems. Requirements engineering is not an
easy task. It takes time, a lot of effort and does not come for free. So why is it so
important? Why not just start directly with the creation of the system
specification?
We need this domain and its results for three key reasons:
First, to get all stakeholders on the same page. As projects become larger, our
customers often do not have a consistent single view of the problem they are
trying to solve. A number of business divisions maybe involved as well as
several IT functions, often with conflicting views, which need to be aligned.
Second, to structure the problem space. The larger the project gets, the more
difficult it becomes to retain an overview. Requirements Engineering serves
to divide project scope into manageable parts, each aligned to a specific
business problem.
Third, to assure that the problem is fully understood. Before we begin to
define any solution – and software engineers often tend to proceed to the
solution too fast – we must ensure that we have correctly understood the
customer’s problem.
3.1
Basic Methodology
The Requirements Engineering discipline describes the problem space in terms of
what the customer expects from the system and its development, and what lies
outside its scope. To do this, the process is based on the artefacts that are
produced in the Quasar Enterprise domain such as business services, business
vision, business drivers and domains, plus the artefacts provided by the customer.
On the basis of this input, it is possible to describe the corresponding
requirements with respect to the application in a requirements specification.
Figure 3.1 shows the high level artefacts of the Requirement discipline.
The requirements specification embodies a vision of the system that orients all the
relevant stakeholders in a common direction. A detailed use case model describes
how the problem space can be structured. Functional requirements define the
measurable functional demands on the application. Quality requirements define
what fundamental properties and characteristics the application must have, e.g.
43
Chapter 3. The Requirements Domain
Figure 3.1: High level artefacts in the Requirements discipline
usability-related or performance-related properties. Finally, the architectural
requirements describe prerequisites that have to be met when defining an
appropriate solution, to ensure that the application fits into its future system
environment. These requirements are grouped together in figure 3.2 under
Application Requirements, while migration and integration requirements are
grouped together under Integrational Requirements.
We use the Quasar Requirements Engineering Methodology to define a
requirements specification of this type. This methodology provides a uniform
recommendation for requirements engineering that applies across all project
types. It defines the basic principles of requirements engineering, plus the tasks
necessary to achieve the goals of the discipline.
Pattern 3: Big picture first
Create a system vision to set the scope of the project.
Many development projects encounter scope creep right from the beginning. This
is especially true of complex development projects in which many stakeholders
have numerous different interests regarding the application. The system vision
(see figure 3.2) is therefore the initial component of the requirements
specification. It is a means of defining the scope and boundaries of the application
and of aligning all the stakeholders in a common direction.
44
Quasar 3.0
Figure 3.2: Structure of the system vision
The system vision describes what the application will basically become and steers
the development project in the desired direction, and enables a subsequent
successful and structured requirements engineering process design.
Pattern 4: Structure the problem area with use cases and scenarios
Employ use cases and scenarios to facilitate communication and to enhance the
documentation of functional and quality needs.
One of the biggest problems when creating a requirements specification is making
it comprehensible to all the project participants. Here, use cases and their
associated scenarios (see figure 3.3) are a good way to describe a user’s needs
with regards to the application. The reason is that they are written mostly in a
non-technical manner which allows all stakeholders to understand them easily.
Use cases describe how future users will use the application and offer a
non-technical route to understanding exactly how an application will support them
as they perform their daily business processes.
Additionally, we refer to use cases and scenarios not only in their "classic" sense
for describing the functionality of an application, but also for describing its
quality requirements (e.g. the maintainability-related requirements).
Furthermore, use cases effectively support project management in making initial
estimations of complexity and effort by means of the Use Case Point (UCP)
method, e.g. during initial pricing activities as part of a bidding process.
45
Figure 3.3: Use cases and scenarios
Pattern 5: Employ early prototyping to elicit Use Cases
Build a user interface prototype using simple tools early in the requirements engineering
process and iterate quickly to obtain a common understanding.
Supposing we start out a project from a blank slate, how do we arrive at use cases
and scenarios? Capgemini has developed a method and a set of tools to efficiently
support this task, called Rapid Design and Visualisation (RDV), see figure 3.4.
RDV is an innovative and structured way to specify software by visualising
requirements interactively and collaboratively early in the process, in order to
reduce risk, avoid rework, and build a system that users identify with. It employs
Scenario Definitions, Whiteboarding, Simulation and Stakeholder Reviews to
quickly arrive at visual representation of the project vision shared by all
stakeholders.
3.2
The Industrialised and the Manufactural Approach
In the requirements engineering discipline there is no elementary difference
between the two approaches. Yet there are minor deviations resulting from two
aspects: the level of detail and the degree of standardisation.
46
Quasar 3.0
Figure 3.4: Rapid Design and Visualization Process
Pattern 6: Determine early which level of detail is required
Think of all aspects like planned lifetime, volatility of requirements, maintenance team etc. (list
see chapter 2) to clarify necessary artefacts and level of detail during the bid phase.
The shorter the lifetime of the final product or the newer the business problem to
the client, the less detail will be needed from requirements engineering. It will be
more helpful to let the customer see results as early as possible. On the other hand,
important non-functional requirements must be known early and completely.
In general, the industrialised approach tends to need a higher level of detail due to
the longer lifetime of the product. At the same time, already existing knowledge
of the customer about his problem allows a more precise definition.
47
Pattern 7: Use business domain maps
There are many business contexts where some kind of standard approach for a business
problem is already established. Take this into account when gathering requirements and inform
yourself before getting too involved in the details.
Especially in the manufactural approach, there is a higher degree of standard
aspects because it makes no sense to develop everything from scratch. But
standardisation plays an increasingly important role for the industrialised
approach too. In many cases, it is common practice or even a customer
requirement to use a particular standard component.
We must be able to decide on the requirement level whether a package based
solution, a framework providing business functionality, or a prefabricated
component will be part of the solution. If not, we will get into trouble due to two
reasons:
The decision to incorporate prefabricated components covering certain
business functions has an impact on the requirements. Customers will need
to decide whether they want to stick to the full set of their original
requirements or whether they are perhaps willing to change their processes
to fit the features provided by the selected standard component.
In any case, it is not a good idea to start Requirements Engineering without
bearing in mind the environment of the future solution. Instead, we must
consider in which business areas standardisation is advanced enough to pose
a viable alternative to custom development. Business domain maps and
sound understanding of standard business topics help to prevent pointlessly
capturing requirements for aspects where standard components are usable.
3.3
Offshore Methodology
On the requirement level there is so far no need for an extension with offshore
aspects. The idea is to provide all requirements engineering onshore. Ambiguous
requirements will be identified during analysis and there enforce a step back to the
requirements engineering.
48
Quasar 3.0
4
The Analysis & Design
Domain
The Analysis & Design sub-domain aims at finding and precisely defining an
unambiguous solution for a set of requirements that are laid down for an
application system.
Firstly, a system specification is created based on the requirements that have been
identified and described in the previous Requirements sub-domain. The system
specification contains a full description of the solution from the business point of
view.
Secondly, the application’s technical architecture is laid down. Using the
requirements and the system specification, the technical framework is defined in
order to create an initial solution for the requested functionality.
Once the work of the Analysis & Design sub-domain is done, the subsequent
Development sub-domain can start on the completion of the solution.
Pattern 8: Enable Round trip
The methodologies and tools for analysis and design must be aligned and must allow round trip
engineering.
Often, new requirements are discovered while designing a solution. And typically
these new requirements arise when the analysis is partially complete (independent
of the project model).
Pattern 9: Align structure
The fewer explicit explanations are needed for the connection between analysis and design, the
better. The easiest way to reach this goal is to define design as a refinement of analysis, only
adding information, not changing the structure.
The original idea of writing the specification before building the design (first
what, second how) does not necessarily hold if an iterative project model is used.
At least the rough underlying design will be fixed in early iterations and has to be
taken into account in the Analysis during later iterations. This iterative process
becomes much easier if there is a structural alignment.
Defining a solution is very often no longer a pure custom development job. An
increasing challenge rises from the fact that more and more functionality is
provided by frameworks and prefabricated components. The architects (both the
49
Chapter 4. The Analysis & Design Domain
lead business analyst and the technical architect) have to arrive at a common
understanding where to use frameworks and prefabricated parts. These may not
only dominate the design but will also have consequences for the functionality
provided and its representation during the analysis. The more functionality these
components provide, the less it makes sense to discuss functionality with the
customer as if we were building a solution from scratch. Instead, we must be able
to explain what they will get from the chosen components and illuminate the
consequences. Delta specifications become more important.
We do not focus on this topic any more in this part of the book but show some of
the relevant aspects in the BPM chapter (8) because using a BPM suite is a good
example for the resulting changes.
4.1
4.1.1
The Analysis Discipline
Basic Methodology
The main focus of the Analysis discipline is the transformation of the problem
description into a system specification. The problem scope has already been
defined under the Requirements sub-domain. Now we transform the requirements
that were elicited into a system specification that is binding, complete, consistent
and comprehensible.
4.1.2
Industrialized Methodology
In order to create a system specification that includes all the required information
in a well-structured form that is comprehensible to all the project participants, we
use the Quasar Specification Methodology. The system specification describes
what the future system will do. It includes (among other artefacts):
a logical data model that defines the objects the system will act upon
use cases that define the possible interactions of the user with the system
dialog descriptions that allow the customer to see what the system will look
like
It is most relevant for projects with many participants, potentially spread over the
globe and working in different units and where the project is expected to have a
long life span with a large number of future releases.
The Quasar Specification Methodology comprises everything a system analyst
needs to know to create the system specification: information about basic
concepts like the meta model on which the methodology is built, the processes
that take place in the specification phase, and how the artefacts of a specification
are created based on the ideas of Concept and Form. In addition, a basic example
of the structure of a specification is given. Then, at a more practical level, the
50
Quasar 3.0
methodology explains how artefacts such as use cases or the data model must be
created. It defines exactly which information is needed for each artefact, provides
templates, and describes best practices.
In addition, the methodology provides tools for creating the specification
documents from models using Enterprise Architect, as well as background
reading and teaching material.
Figure 4.1 shows the high level artefacts in the Analysis discipline following this
approach.
Figure 4.1: High level artefacts in the Analysis discipline
51
Pattern 10: Master complexity
Use conceptual components to keep the complexity of the application under control.
Although the well-known basic principle of divide and conquer may be applied
during the implementation of a system, it is often wrongly disregarded during the
early phases. Even at this early stage it offers significant benefits:
Complexity becomes manageable.
The division of work is eased.
Conceptual components for organizing the project into sub-tasks and
sub-teams (i.e. team structure) can be used.
The systematic transition to system design is facilitated.
The entire development process is systematically oriented to the
architecture.
Knowing this, we strictly apply the divide and conquer concept in the
specification phase. The following figure 4.2 gives an impression of what the
conceptual components look like:
Figure 4.2: Example of conceptual components
Pattern 11: Strive for completeness
Create a functional overview to summarize the logical functionality of the application.
52
Quasar 3.0
While the basic (and detailed) elements like use cases and dialog specifications
are important, it is also necessary to see a complete picture of what will be
developed. This picture typically lives in the head of the chief designer, but
should also be available to all the project participants. More importantly,
customers need to know at the end of the specification phase whether the system
being designed is the one they actually want. However, this is hard to assess if
only the details are visible. Therefore, a big-picture perspective is needed. By
making the functional overview a required part of the system specification, the
Specification Methodology makes this perspective prominent.
The functional overview comprises the following aspects:
Expert solution idea: The fundamental solution approach being pursued in
the project.
Core concepts: Definition of key concepts and terms.
Solution sketch: Ideas about a possible solution, e.g. with the help of work
flows.
System overview (external/subsystem): Overview of the conceptual
components and interfaces to external applications.
Use case model overview: Process description of the product with the most
significant use cases.
Figure 4.3: Structural composition of the functional overview
With the help of the various elements of the functional overview, top-down
discussions are possible at any time.
53
Pattern 12: Drill down
Use a from high to low approach to avoid getting bogged down in details.
This principle embodies the notion that it is a big mistake to view the specification
phase as a large and monolithic block in which everything is specified in detail
right from the start. On the contrary, it is necessary to start first at the topmost
level, elicit the primary elements, create the first big-picture perspectives, and
only then get down to the details. And – most importantly – it is necessary to
pause occasionally and reflect on the progress made up to that point. To
encourage this kind of process, the Specification Methodology splits the
specification phase into two sub-phases:
Coarse-grained analysis
Detailed analysis
The aim of the coarse-grained analysis phase is first to produce the overviews, i.e.
the functional overview, system overview etc. To provide a basis for this phase,
work on aspects like the logical data model, use cases etc. will already be started
but will not be completed. In fact, work will often still be taking place on the
issues arising from the previous phase rather than on the components.
The important thing about the coarse-grained phase is that it ends with a
milestone. We use this milestone to designate a specific moment that enables an
evaluation to be made as to whether the project is on the right track. The work
completed so far is reviewed and presented to the customer. Moreover, this
milestone will be important if the customer commissions new work after this
phase: on the basis of the results reached so far, it will be possible to generate a
new estimate regarding the rest of the phase, or, if desired, the rest of the project.
Following the functional overview of the coarse-grained phase, the subsequent
detailed analysis phase drills down into the details.
In the detailed analysis phase, the remaining artefacts are created and everything
is finally put together; the dialog specifications are written, the use cases are
completed etc. Finally at this point, there is a complete switch to a
component-oriented view.
The phase ends with a milestone that includes the customer’s official acceptance
of the entire system specification. Only with this acceptance can the next project
phase start. See figure 4.4 for a summary of the tasks carried out during this phase.
Pattern 13: Use standards
Standardisations for different kinds of functionality and information exchange already exist on
the business level for interfaces, data models and reference architectures.
54
Quasar 3.0
Figure 4.4: Tasks and individual stages of the specification phase
Find out the aspects for which your client or the whole domain already uses
standard interfaces, data structures or reference architectures. Use them where
possible, this will help focus effort on those aspects where real business
differentiation for the customer is possible.
4.1.3
Manufactural Methodology
The manufactural approach follows the industrialized approach in many patterns
(such as divide and conquer). The main difference results from the level of detail
required from the specification before beginning the implementation. For
example, it may be very helpful to use a toolset for developing user interfaces that
provides output which can be integrated directly in the final system. Similar to the
Requirements subdomain, it may not be helpful to describe use cases in much
detail if the project is small, if users need to see the system before they can define
what they really want, or if no extensive need for maintenance is foreseeable.
55
4.1.4
Dealing with ambiguity and incompleteness is always a challenging task while
writing a specification. But geographic distance reduces team communication and
awareness, and therefore allows for more misinterpretations of specifications than
in co-located development settings. In other words, any ambiguity is magnified
when a specification is realized offshore. Also, the system specification is a
crucial communication hub between the onshore and the offshore team. Remote
teams do not have the same opportunity to ask for clarification from business
analysts or domain experts as those in co-located projects. Specification defects
will not easily be uncovered by the remote development team. And it is more
difficult to rectify these defects without the ability to use highly interactive means
of communication. The truth of the saying, "A software engineer’s most valuable
tool is a whiteboard", becomes more evident in offshore projects.
Pattern 14: Make specifications fit for offshore
Use a clear structure and be as explicit as possible.
Everybody in the team must understand the overall structure and its constituents:
What is a business rule? How do we use a use case?
Giving precise answers to these questions is critical to the mission. Although
offshore developers will be closely integrated into the team, they will sometimes
have different methodical backgrounds. So take into account the fact that they
may have different needs concerning the structure of a specification. Making a
specification fit for offshore involves clearly defining a single common
terminology and structuring it in a way that takes the offshore developers’
perspective into account. The Quasar Ontology is the foundation on which we
build a common terminology.
The onshore team not only has a lot of tacit knowledge about the content of a
specification, but a lot of implicit knowledge about meta information like the
mapping between parts of the specification and the high-level requirements. In
offshore projects, making this kind of structural knowledge explicit is paramount:
in large-scale offshore projects, the traceability of software artefacts becomes
even more important than in co-located settings, because many other disciplines
like testing depend on tracing information. Determining the impact of changes
requires elaborate tracing, especially if the changes affect some components that
are developed by offshore teams.
Offshore projects can pose genuinely new challenges. An example is the potential
language mismatch. Writing a specification in a foreign language is very difficult,
and translations can introduce inconsistencies.
56
Quasar 3.0
Pattern 15: Watch the language of your specification
Write consciously, and check translations for consistency.
If a specification document refers to the client on page 7, the customer on page 66
and the user on page 768, with all these terms meaning the same thing, it may
create problems. A comprehensive bilingual glossary started right from the
beginning of the project will save a lot of headaches here.
57
4.2
4.2.1
The Design discipline
Basic Methodology
On the basis of the requirements and system specifications, the Design discipline
tackles the construction of the solution. It comprises all the preliminary activities
needed to guarantee the efficient implementation of the system.
Design is the discipline under which artefacts such as architectural views and
models, programming guidelines and instructions, utilization strategies etc. are
developed. Three architectural perspectives have been established within
Capgemini:
Application architecture: This describes the structure of the software and its
function on the basis of a precise understanding of the logical sequences involved,
but as independently of the technology as possible and reasonable.
Technical architecture: This describes the runtime environment for the software
described in the application architecture. This means:
the technical solutions used in connection with the technical infrastructure
architecture contained in the system
the structure of the technical services
all other software components that are independent of the application.
Technical infrastructure architecture: The system’s technical infrastructure
(TI) comprises the physical devices (computers, network connections, printers
etc.), the installed system software (operating system, transaction monitor,
application server, interface software), including versions and patch levels, as well
as the interaction between the hardware and the system software. The TI
architecture also defines the programming languages employed.
Figure 4.5 shows the high level artefacts of the Design discipline.
Pattern 16: Apply a strictly component-oriented focus
Master complexity by structuring the problem area as individual components.
A component-oriented approach allows you to handle the business complexity of
the application, and to simultaneously implement the application.
Classes of object-oriented languages like Java or C] are not a suitable basic design
unit. They are too small. If such a class is used as the basic design unit, the result
is that large systems will be subdivided into countless classes and the
comprehensibility of the architectural principles employed will be completely
lost. Instead, the component has become established as a suitable design unit.
Components are considerably coarser than classes and are therefore suitable for
58
Quasar 3.0
Figure 4.5: High level artefacts in the Design discipline
designing large systems. Figure 4.6 shows there relations.
The Capgemini architecture guide [6] defines a construction model that shows
how component-oriented applications should be structured. We distinguish the
technical components of the technical infrastructure from the application
components that structure the application logic. Application components can be
grouped into subsystems in order to enable large projects to be handled. We
define various types of application components and specify how they can carry
out their respective tasks. In this way, the construction model becomes a blueprint
for the practical component-oriented design of an application.
Pattern 17: Make it simple
Define a clear, easy and uniform programming mode.
One of the important design objectives is embodied by the KISS principle. In its
polite form, KISS stands for "Keep it small and simple", and is thought to have
originated in NASA’s Apollo project. In software, it means reducing the
complexity of the systems to a minimum and ensuring that the structures
employed are clear, simple and traceable.
59
Figure 4.6: The structure of a component–oriented application
Pattern 18: Focus on the application architecture
This contains the application component model and is the basis for the implementation of the
business functionality.
This stage involves designing the application component model that contains all
the application components and the component interfaces which the application
components provide and use. It also indicates the data sovereignty the
components have over the entity types of the application. This model – the
application component model – is the building plan used by developers to
implement the application.
Pattern 19: Build for change
Pay attention to the 10 basic quality principles of architecture in order to build a system that
permits changes over the long term.
The Capgemini architecture guide defines 10 principles of software architecture
(separation of concerns, minimization of dependencies, information hiding,
homogeneity, zero redundancy, differentiation of software categories, layering,
design-by-contract, data sovereignty, re-use) that must be followed while
designing applications.
60
Quasar 3.0
Pattern 20: Use standards
Technical standardisations for different kinds of functionality and information exchange already
exist for interfaces, data models and reference architectures.
Find out the aspect for which your client or the whole technical domain already
uses standard interfaces, data structures or reference architectures. Use them
where possible, this will help to focus effort on those aspects where real business
differentiation for the customer is possible.
One example of such technical standard is our inhouse component "Quasar
Client" that provides an elaborated framework for developing complex client /
server applications. The focus hereby lies on the client side and its interaction
with the server. Using such components prevents the project from developing
standard technical functionality and concepts again and provides proved solutions.
In addition, the community available to answer queries is much bigger in case of
proved solution than in case of a project specific solution.
Pattern 21: Subdivide the application components into layers
The layers structure the components parts of an application component.
To subdivide the application components into layers, we assign each of its
components parts to a single layer. Consequently, an application component can
extend across multiple layers (see figure 4.7).
61
Figure 4.7: The five layers of an application and the communication rules
62
Quasar 3.0
4.2.2
Industrialized and Manufactural Approach
These two approaches are differentiated based on the duration for which the
resulting system has to live and the frequency at which the requirements will
change during this lifespan.
Pattern 22: Design your systems architecture along with life time aspects
Divide your system in spe along with life time aspects and clarify the non-functional needs of
each component. Invest effort in good architecture along with this differentiation and ensure that
components with different life time requirements and requirement volatility have clear interfaces.
No doubt, a good architecture following the above patterns helps avoid effort on
searching errors, stability and performance problems etc. But a good architecture
in the strong sense of the above pattern itself costs time and effort to develop and
follow. Therefore, it should be invested carefully. Typically, the systems we are
designing have both types of components, Scooter and Train.
Looking at a scooter-like system, where time for delivery is much more important
than life time, it is not advisable to spend too much time in reducing redundancies
etc. as described in Pattern (Pattern 18 and 19). The same holds if a component
has a long required life time but will often change its functionality in an
unforeseeable way. Second aspect resulting from the life time perspective applies
to the usage of prefabricated components, both frameworks and packages. The
longer an application lasts and the lesser it has to deal with the changes
beforehand, the better it is to avoid relying too much on fast changing
prefabricates. This results from two reasons: First, if our customer is forced to
invest in technically induced changes he will not be satisfied in the long term.
Same holds for us if we have to provide a team over a longer period. The more
complex the know how, the more ramp up time is required for new colleagues to
become productive. Therefore, each change within the team becomes expensive if
not anticipated in the design through encapsulation etc. On the other hand, using
prefabricates will be helpful in case an application has to be built very fast.
Pattern 23: Follow the design of your major prefabricates
If your system is developed based on an existing framework or package, do not try to overrule
the architectural structure.
Depending on the kind of prefabricate, the above mentioned pattern may or may
not be useful. If you are working with a framework that produces the entire
application for you out of your data definition, then trying to force this solution
into a three-tier application may not be helpful.
63
4.2.3
Similar to the Analysis discipline, there are some issues with designing software
that are always important but have an even higher impact in offshore projects.
For example, a component-based development. This is always important but in
offshore projects it quickly becomes obvious that cohesive components or
subsystems are critical for achieving efficient communication between distributed
teams. Therefore, for offshore topics, the aforementioned basic discussion holds
but so do the aspects particularly mentioned for the industrialized approach.
From a business point of view, cohesiveness is only one dimension to be
considered while crafting a component model. It is equally important to take the
management aspects into account from the outset. If the components are too
small, they will easily lead to management overhead and become an integration
nightmare. If they are too big, effective risk management is no longer possible.
Features or use cases that are subject to strict quality requirements should not be
spread across several components. And there are a lot more aspects to consider
for achieving a well-balanced component model as shown in figure 4.8
Figure 4.8: Architecting communication
Pattern 24: Design loosely coupled component based architectures
Build the team along with these components.
64
Quasar 3.0
The bottom line is to minimize communication for "component internals" but
support communication for the "big picture". Every type of instability is
magnified in offshore projects, as changes need more time to be replicated to the
offshore team. Stability is a crucial aspect in providing the foundations on which
the whole team organizes its work.
Pattern 25: Use a stable technical basis
No experiments with central frameworks and tools.
Learning about the newest cutting-edge frameworks and tools is always exciting,
especially for software engineers. However, in offshore projects stability and
maturity is important. For example, using a hot open-source OR-mapper which is
updated every few months (and patched every few weeks) can seriously disrupt an
offshore project.
Pattern 26: Team design
Jointly discuss and craft the design in order to distribute knowledge.
Depending on the experience of the offshore team and the complexity of the
component to be developed, the offshore or onshore team is responsible for the
component’s internal design. But in any case, the design deliverables are not
simply handed over with no discussion. Crafting them jointly, or carrying out
joint walkthroughs, is one of the most effective forms of knowledge transfer.
Cooperating during design is an important basis for the effective transfer of
responsibility for components or even entire subsystems. It helps the offshore
team to understand the architecture and to put their work into the overall context
of the system.
65
66
Quasar 3.0
5
The Development Domain
There is no software without code. Hence two basic disciplines are fundamental
to software development: Implementation, the constructive task of writing a code,
configuration mechanisms and data structures; and Debugging, the analytical task
of making the software functionally error-free and simultaneously ensuring that
non-functional requirements such as performance and security are met.
5.1
5.1.1
Basic Methodology
The Implementation discipline
Implementation is the software development discipline in which a software
product is actually developed using the output of the preceding design disciplines.
In implementation, there is no more abstraction from the resulting software
product. Instead, it is entirely concerned with specific low-level configuration,
code and data, and the processes of programming, documenting, patching,
refactoring and re-engineering programs. The main objective of this discipline is
to develop software products. We call the output of this discipline application
parts. With the build discipline, we develop software solutions that are based on
these application parts. Figure 5.1 shows the high level artefacts of the
Implementation discipline.
Pattern 27: People first, computers second
Write concise, uniform, well-structured and easily comprehensible programs, placing people
first, computers second.
Clean code means code with good quality. Good quality code helps to reduce, the
total amount of efforts required. To achieve this, it is essential to follow a concise
programming style; to use a uniform syntactical code style through the entire code
base; to clearly structure the program units; and to make the program control flow
easily comprehensible to the programmers. Always keep in mind that programs
have to be written so that people can easily read and change them.
For instance, use domain-specific data structures (e.g. Map<User, Profile>)
instead of generic ones (e.g. HashMap with Object that needs to be downcast).
Keep your solutions as simple, straightforward and appropriate to the problem as
possible, and do not complicate them more. Additionally, structure your code
primarily in accordance with what is appropriate for the application domain, not
as per technology preferences; use as little technology as possible, and only as
much technology as necessary.
67
Chapter 5. The Development Domain
Figure 5.1: High level artefacts in the Implementation discipline
68
Quasar 3.0
Pattern 28: Don’t repeat yourself
Always try to avoid redundancy and separate out reusable functionalities into self contained
program units in order to minimize change effort and to avoid code duplication that will lead to
maintenance problems in the long term.
Except for specific performance (speeding-up) and safety (fall-back) solutions,
redundancy is highly undesirable, as over the long term it can result in a
maintenance problems. Hence you should always try either to avoid any
accidental redundancy in configuration, code or data, or at least be prepared to
justify your intentional redundancy.
Pattern 29: Defensive programming
Let your programs be input forgiving, operation defensive and output precise and try to analysis
and focus on the possible errors cases.
The often-cited, but unfortunately rather bad clichè, garbage in, garbage out
(GIGO), is a feeble excuse for unexpected runtime behaviour and is acceptable for
single applications only. However, for multiple applications working closely
together, it is essential to be forgiving with regard to inputs, defensive during
operation, and precise with output. Only in this way can stabilise and secure the
operation to be achieved.
Additionally, when implementing the operations of your programs, focus on all
possible error cases first and on the valid cases second. Keep in mind that please
do not blindly catch errors when you don’t know how to handle! For instance, in
Java avoid including empty catch clauses just to make the compiler happy.
Instead, you should at least pass the caught exception back up the call chain.
Pattern 30: Balance code, configuration and data
Use the most suitable approach for implanting your tasks, but avoid highly configurable
solutions.
Every craftsman knows that if all you have is a hammer, every problem looks like
a nail. Programmers should remember that besides their hammer (imperative
code), their toolbox also contains two other, rather useful tools: configurations for
declaratively expressing scenarios, and data for holding factual information. Good
programmers always balance the use of these three tools when they develop their
solutions.
For instance, instead of directly hard-coding authorisation rules in your
application code, define a Domain Specific Language (DSL) for expressing your
69
authorisation rules, and use it to place all your rules into a configuration file. Or
even parse the configuration file and persist the rules as data inside your
application database.
But in any case, do not try to look too far into the future. Make those aspects
configurable where you know the need for configuration exists for today and
perhaps tomorrow, but do not try to configure everything possible.
Pattern 31: Step-by-step refinement and continuous refactoring
Grow your code base and implement it in distinct and continuous refactoring steps so that there
is no accidental increase in complexity, and ensure that refactoring is fully completed!
The art of programming is not about the ability to perform a straightforward
all-in-one top-down encoding of entire functionalities in a particular programming
language. This only works for very small and simple solutions.
Instead, good programming centres on the process of refining stepwise and
continuously refactoring pieces of code until the intended functionality is encoded
in a sufficiently complete manner.
Only with this incremental approach will you actually get through the
implementation of large and/or complex functionalities in practice. For instance,
you should first define the external API of your library, then implement the
corresponding method bodies, then fill in stubs and mock-ups to get your first test
cases working. Then implement the first-order functionalities, followed by the
second-order functionalities etc. Finally, add additional data assertions,
error-checking code and code documentation.
Pattern 32: Abstraction and generation
If possible, instead of manually developing, generate lower level code, configurations and data
out of higher level models.
Every application consists of a large amount of code, configurations and data. But
not all of this should be manually developed. If possible, model it in a more
abstract way at a higher level and then generate the derived lower-level artefacts.
This is especially the case if the required lower-level artefacts have to contain a lot
of boilerplate code and redundancies.
Pattern 33: Use existing algorithms
Try to abstract from your concrete problem and see whether there is a standard algorithm that
can be used.
70
Quasar 3.0
For many known problems within computer science, there are already well proved
algorithms with known characteristics. At least quite strong non-functional
requirements should make you use existing algorithms. This helps on the one side
with readability and on the other side with reliability.
Pattern 34: Analyse the problem before programming
Try to find out before coding whether the problem you have to solve in software is one with
reasonable complexity
Sometimes even for apparently simple problems, every algorithm for solving the
problem results in bad performance at least in some cases. Make sure before you
start programming that you understand the problem quite well and that you can
determine the complexity (in a computer science sense) of the problem. If the
problem comes along with high complexity then try to find simplifications for the
relevant cases. In the worst case this means that you should go back to the
analysis and clarify the relevant aspects with the business.
5.1.2
The Debugging discipline
Debugging is the analytical software-development discipline of determining and
locating the root cause of problems in a software implementation. Debugging is
concerned with functional faults, defects and side-effects, all non-functional
issues and the processes of code instrumentation, operation debugging, operation
logging, execution tracing and execution profiling. It is the primary discipline that
has to resolve the issues that the Test discipline has initially pinpointed. The main
objective of this discipline is to ensure that the software developed runs without
problems.
Figure 5.2 shows the high level artefacts of the Debugging discipline.
Pattern 35: Check the plug first
Do not be the victim of mistaken assumptions
Before directly jumping into the code base of an application, please always
question your assumptions first. It is important to know and validate the
assumptions that underlie a problem situation. For instance, do not blindly assume
that certain external services in the environment of an application are always
available.
71
Figure 5.2: High level artefacts in the Debugging discipline
Pattern 36: Use reproducible test cases
You can’t fix what you can’t reproduce, so always try to find a deterministic test case first.
You have to make the program fail for you, too. The best outcome is a
deterministic failure situation, but even nondeterministic failures are better than
not being able to reproduce the problem at all. Always keep in mind that usually
you cannot fix something effectively if you are unable to reproduce the original
problem, because blindly fixing a problem usually introduces a couple of new
ones.
Pattern 37: Change one thing at a time
Do not expose yourself to the conflicting side effects of changes.
You always have to isolate the key factor in a failure. For this, change one thing at
a time only and compare the changed application behaviour first. Never change
more than one thing during a particular investigation step, or your investigation
space will become larger than necessary and you will too easily fall prey to the
conflicting side effects of changes.
72
Quasar 3.0
Pattern 38: Be aware of instrumentation side effects
Instrumentation and debugging change the problem situation, so be prepared for this and do
not make incorrect comparisons.
It is necessary to understand that an instrumented and debugged program will
perform differently from the original one. Instrumentation (the addition of
symbols, source code references and extra run-time hooks) usually at least
implicitly changes run-time timings, and often also explicitly requires the
disabling of certain code optimizations. Accordingly, you should always perform
a single instrumentation and debugging operation at a time, and perform multiple
instrumentations and debugging operations in sequence.
Pattern 39: Use problem-solving heuristics
Leverage proven heuristics of problem solving for the debugging process.
You cannot apply a simplistic approach to problem-solving. Hence during
software debugging, it is useful to know and apply classic problem-solving
heuristics:
Analogy: does it help if I think in terms of a similar problem?
Generalization: does it help if I think more abstractly?
Specialization: does it help if I solve a special case first?
Variation: does it help if I change the problem situation or express the problem
differently?
Backward search: does it help if I look at the expected results and determine
which operations could bring me to them?
Divide and conquer: can I split the problem into more easily solvable partial
problems?
Reduction: can I transform the problem into another one for which a solution
already exists?
Backtracking: can I remember my path to the solution, and on failure track back
and attempt a new solution path? and
Trial-and-Error: as a last resort, can I just brute-force test all possibilities?
73
Pattern 40: Perform a layer-based profiling exercise
Architecture layers represent reasonable measurement points for profiling.
The task of performance profiling an application in order to find hot spots where
too much run-time is spent can be a complex one. Often the reason is that the
profiling tools used have no information concerning the domain specific
components contained in the architecture of the application. Therefore, try to
focus first on profiling the measurement points at the architectural boundaries of
your application. For instance, first profile each subsystem independently, then
profile the entire application.
5.2
Industrialized and manufactural Approach
The aspects we mentioned earlier for the design discipline also hold for the
development domain. Life time and volatility of requirements are also important
for good development.
5.3
In the development domain one major issue for offshore development is a
common understanding of what good software quality means. Nevertheless the
following patters may also be useful for all types of projects but are of special
importance for offshore development.
Pattern 41: Define quality measures for software in advance
For many software languages, rules already exist for good coding.
Define right from the beginning of your design activities the coding standards and
make clear how you are going to check the compliance. For getting a common
understanding it may be quite helpful to provide pair analysis of selected portions
of software. Actually this is an analytics activity as well (constructive analytics),
therefore we have duplicated this pattern because of its importance in the context
of offshore development.
74
Quasar 3.0
6
The Software Configuration
Management Domain
Software Configuration Management (SCM) identifies and tracks configurations,
builds, deployments, releases and changes of all artefacts required for building a
proper software system. The main purpose of SCM is to maintain integrity and
traceability throughout the whole software life cycle. Furthermore, it is a
supporting discipline for efficiency and quality in development, project
management, change management and operations. Figure 6.1 explains this model.
en
t
De
onfiguration Mana
ve
re C
gem
a
l
w
t
f
e
nt
So
A
n
Ma
an
ag
V
Tra I
M
em
en t
De p
n
me
l oy
l
ode
Sof
eM
twa
iplin
re C
Disc
onfigu
ration Management (SCM)
t
ns
ag
tio
an
ra
M
en
t
AV
em
en
ion
M
se
se
ea
ea
ue
sscking
t
n t i f i c at
s
ge
em
nt
ersio
ue
an
ag
a
m en
eq
eR
Ch
an
M
D
me
R el
&
n
I de
Ch a ng
tM
il d
lo y
R el
ld
ep
f igurat ion
Con
Version
Control
Bu
r
a gt e f a c t
eme
nt
ct
oje
Pr
B ui
t
e
ang
en
Ch
nt
ge
&
me
na
an
e
ag
m
M
na
m
ge
op
a
Figure 6.1: Software Configuration Management Discipline Model
O
pe
t
75
Chapter 6. The SCM Domain
As shown in chapter 2 and figure 6.1, Software Configuration Management
essentially consists of three main disciplines:
Configuration
Build & Deployment
Release & Change
Pattern 42: Start with a Software Configuration Management Plan
Especially in complex projects a plan for software configuration management helps you to save
budget and time by following the right procedures.
After reading the following sections about SCM, you will realise that SCM
requires various concepts and processes dependent on the distinct tasks. A plan
can help you to coordinate all activities and follow the right procedures within the
stipulated deadline. Refer to the IEEE 828 Standard for Software Configuration
Management Plans ([31]) to develop a proper plan.
In the following sections, the software configuration management disciplines are
discussed in further detail.
6.1
The Configuration Discipline
The configuration discipline is identifying and recording all assets of a software
product maintaining their history of changes over the time. It has the objective to
gain control and traceability throughout the entire lifecycle of the software
product. Configuration is composed out of the following sub disciplines that are
discussed in the upcoming sections:
Version Control
Issue Tracking
Artefact Management
Version Identification
It is recommended to think about and produce the four artefacts shown in figure
6.2. In sub-discipline Version Control, you will find a pattern for a recommended
branching and merging strategy. Hints for a proper repository structure can be
concluded from several patterns especially in Version Control and Artefact
Management. Issue Tracking includes patterns for an issue tracking concept. A
versioning concept helps to identify the proper versions of delivered products.
76
Quasar 3.0
Figure 6.2: High level artefacts in the Configuration discipline
6.1.1
Version Control
Version Control is identifying and persistently recording the source artefacts of a
software product. It has the purpose of systematically controlling changes to the
source artefacts in order to maintaining the integrity and traceability throughout
the life-cycle of the software product.
Pattern 43: Clear strategy for branching and merging
Follow a well-defined strategy for branching and merging your source artefacts. Balance
flexibility for development with stability during maintenance. However, keep the number of
parallel branches at a minimum.
Simply using a version control system (VCS) for managing your source artefacts
is not sufficient. You also have to follow a well-defined strategy for creating
branches and merging them. A typical VCS is generic and will not guide you or
restrict wrong merging directions. The overall goal of a version-control strategy is
to support the creation of high quality releases. Therefore, we distinguish between
release branches and feature branches and order them in a Change Flow Map (see
figure 6.3 and [19]) according their maturity in the manner of proximity to
production.
Fixing the production problems and similar stabilising changes will take place on
the branch closest to the next production release. Such changes are merged
77
continuously with less mature branches so they reach the mainline and potential
feature branches. After the release is shipped, the merging procedure is conducted
to ensure that all fixes reach the mainline.
New release branches are created from the mainline as late as possible but as soon
as required by changes for the succeeding release. On the other hand, feature
branches are used to decouple destabilising changes (experimental changes) and
should only be merged upwards if they are successfully completed. This is shown
in figure 6.3
Figure 6.3: Change Flow Map
Further, the branching and merging strategy will be aligned with the release
engineering phases. This is illustrated by the blueprint in figure 6.4. During the
initial development of a release, developers can create personal feature branches.
These are merged back into the original branch before testing phase. The
integration phase aims for stability and quality. Then the release is branched off to
build release candidates and finally the productive release while the mainline is
open for development of the succeeding release.
Pattern 44: Strict tagging
Create a tag for every release. Treat tags as strictly immutable.
Do not build releases from the trunk or release branch except for testing the build
78
Quasar 3.0
process. Instead create a tag named after the current product version and build the
release out of that tag. If there will be changes for the release after tagging, never
recreate or even modify tags. Instead, create a new version on the trunk and tag it
again. This implies that your version number schema contains a build-number
segment for such a purpose. So you do not have to change fix versions assigned to
issues or communicated to the customer (see also section 6.1.4).
Figure 6.4: Version control blueprint
6.1.2
Issue Tracking
Issue Tracking is identifying and persistently storing issues (problem tickets,
change-requests, etc.) with their metadata and thread of communications for the
purpose of tracking the possible long-term evolution, state transition and
assignment of the issues.
Pattern 45: Appropriate classification of issues
Define adequate metadata for your issue-tracking model and ensure that issues are properly
classified. However, if there is low acceptance to provide the data, then less could be more.
Ensure that the meta-model of your issue-tracking matches your project
requirements.
79
In particular, verify that you have the right options for the following
classifications:
Issue-type (bug, change-request, task [specification, design,
implementation, test])
Products and components (including build, deployment, your
business-components, technical products, etc.)
Affected release and target release (maintain drop-down choices vs. free
text)
Issue-states and according lifecycle (customized for your project and
depending on issue-type)
Pattern 46: Association of commits with issues
Define a simple but strict rule on how to link commit messages to your version-control with
associated issues of your issue-tracking.
The history of version-control and the history of issue-tracking contain important
information. Maximum value comes out of it, if they both are connected. E.g. for
reviewing commits, it typically saves a lot of time if the related issue is known.
This should be done by mapping commits with issues through their unique ID.
Some higher-level version control systems (VCS) already offer a dedicated field
for issue-ID in commits. Otherwise just follow this template for commit
messages:
#<issue-id>: <issue-title>
<actual message what has been done (e.g. fixed)>
Next, your issue-tracker can be integrated with your version-control system in
order to display the related commit history for an issue. Depending on your tool,
you may also think of adding the revision number containing the change or bug
fix. This helps identifying the build or version containing that fix.
Furthermore your IDE should be integrated with your version-control and
issue-tracker to support you with this associated commit messages. In an ideal
situation, you have no change without an issue and no commit without
issue-association. However, you have to consider, what is efficient and good
enough for your project.
6.1.3
Artefact Management
Artefact Management is managing release artefacts of own and foreign software
products. This includes the identification, persistent storage, dependency tracking,
80
Quasar 3.0
and the license management of all pristine release artefacts from the low-level
artefact to the deliverable products for the customer.
Pattern 47: Strictly versioned artefacts
Ensure that all artefacts carry the proper version in their filename and metadata.
Strictly apply the version number of each of your artefacts (from intermediate to
deliverable) to the filename and metadata. Ensure the same for third-party
artefacts that are integrated in your application. See also pattern 51.
Pattern 48: Do not put intermediate artefacts under version control
Place the input artefacts of your build process under version control, strictly avoid
version-control for any intermediate build-time artefacts, and consistently persist and archive all
final output artefacts.
From our experience, it makes no sense to have version control for temporary
intermediate files. Instead, it is important to control the versions of all source
input for the build process, e.g. source-code, scripts, compilers, and configuration
files. This is done by using a version control system. If you can guarantee the
same version of the complete environment and not only of the input artefacts, only
then you can be sure to reproduce the same final output artefacts. The final output
artefacts are deliverables of the project and need to be archived in a persistent
store.
Pattern 49: License compatibility check
Properly link the licenses of the artefact build to the software product. Ensure that no license
incompatibilities exist in the final product.
Nowadays software products integrate a lot of third party components. Especially
open source software has become popular and becomes a natural piece of
products. However, the massive utilisation of third party artefacts requires
extreme care according to their different terms of license. Otherwise, you easily
end up integrating two components with incompatible licenses. Tool support
helps to figure out which artefacts are included in which version (see pattern 56)
as well as to find obvious license incompatibilities (e.g. GPL component built into
a commercial closed-source product). However, only lawyers can do a positive
verification of complex situations. To prevent problems, check licenses from the
start when you are looking for a particular component from an external source.
81
Pattern 50: Domain-specific slicing
Align your configuration boundaries and granularity with those of the units in your
domain-specific architecture.
The configuration boundaries of your software product for edit-time, build-time,
and run-time should be aligned as much as possible with the domain-specific units
in your architecture. In particular, do not let your configuration be dictated by
your preference for using particular tools.
6.1.4
Version Identification
The sub discipline Version Identification ensures precise product identification
throughout its entire life-cycle. It is defining the structure, syntax and semantic of
version identifiers.
Pattern 51: Strong version identification
Use a syntactically and semantically strong scheme for identifying product versions
consistently, precisely and explicitly.
Precise product version identification is a prerequisite for effective management
of software configuration. It is essential to use an identification scheme that is
both syntactically and semantically robust. The use of rigorous syntax is
necessary for visual consistency and to enable automated processing. Clear
semantics is necessary for unambiguously expressing the nature and scope of a
particular product version.
The following template defines a common syntax for a version identifier.
<major>.<minor>.<micro>.<phase>.<build>.<date>
The segment <major> identifies the main version of your product. Often it is
identical with the main release number under which you are going to market it.
Well-known examples are "2010" for MS Office 2010. Major releases can be
incompatible with older releases and should have significant changes compared to
the previous major release.
The segments <minor> and <micro> are used for smaller functional changes of
a major release and for bug fixes. If you introduce both <minor> and <micro>,
then you can use them to distinguish the level of changes. Increment <minor>
for example can indicate that there have been changes influencing the API of the
product. So, it indicates that everyone using your product has to expect
adaptations before upgrading the product. Under this aspect, <micro> can be
incremented to indicate internal changes or fixes that do not require regression
82
Quasar 3.0
tests for systems using the product. This distinction may be difficult in complex
projects. So decide on a cost-benefit-ratio when you introduce this distinction.
The <phase> indicates the release engineering phase and the expected quality of
a release. Examples are test, release-candidate (RC), release (also GA, REL,
RTM, etc.), or update (U, SP, SR).
The previously discussed segments identify a planned functional feature set of a
release (e.g. for assignment of issues to be fixed for a release and for
communication of milestones to a customer). The version identification schema
should clearly define how to determine the next planned release version.
However, to build and deliver a planned release you may need multiple iterative
builds with unique identifiers. Therefore, additional technical segments are added.
The <build> segment is a number incremented for each build, independent of
whether the release will be delivered. It may be directly derived from the version
control system or from a counter of the build system. This segment is very
important for a clear distinction of your build results.
Finally the <date> segment concludes the date of building potentially including
the time. It is not required for identification but can be very helpful for human
interpretation. As an example the version identifier "3.5.3.RC.5678.20110817"
identifies the release-candidate "3.5.3" with the 5678th build that has been done
on Aug 17, 2011.
6.2
The Build & Deployment Discipline
The Build & Deployment discipline is about building a complete software product
out of its source artefacts and deploying the product on according target
environments. It consists of the following sub disciplines that are explained in the
next sections:
Build Management
Deployment Management
6.2.1
Build Management
Build Management is assembling a software product out of its source artefacts. To
achieve this, the processes of generation, transformation, dependency resolution,
compatibility checking and packaging are performed. The main objective of this
discipline is to build a software product step by step and bottom-up from its many
input artefacts, and thereby to generate a complete software product as deliverable
units for the Deployment Management sub discipline. Figure 6.5 shows the
artefacts of this discipline.
83
Figure 6.5: High-level artefacts in the Build Management sub discipline
Pattern 52: Automated build-process
Automate your build-process up to the generation of deliverable units.
Each manual step has to be documented and can be done inaccurate. Further, a
general requirement for the build-process is that it is reproducible and potentially
even audit-proof. Be lazy and automate!
The build-process is not just the compilation and assembly of some library. For
building a full release it starts with checking out the code base from the according
tag and goes up to the generation of the deliverables that are released and finally
provided to the customer. Design this process from the start and automate as
much as possible. However, you should be effective and do not try to automate
things that are intractable. For example, deploying the software and running
integration tests would be nice to automate but will be hard to do and does not
belong into the regular build-process. Although some integration tests may be
inappropriate for automation, follow the following pattern.
Pattern 53: Continuous integration
Integrate unit-tests into the build and do continuous integration.
Create unit tests for your code and have them integrated into the build-process.
84
Quasar 3.0
Then use a tool for continuous integration that watches your source code
repository and performs a build after changes have been committed. If
compilation of the code or tests got broken, the continuous integration sends an
email to according persons in the team. To avoid that everybody in the team starts
investigation of the problem in parallel, establish a small set of persons for this
purpose. Ensure that exactly one person is responsible for one certain problem at
a time. This person shall have the freedom to resolve or to delegate the problem
quickly.
Continuous integration should be permanent. The earlier you get feedback, in
case the build fails, the better this will save time to track down the reason. This is
especially important for offshore projects. Because of the time difference, the
team causing incompatible code might be asleep when the other team recognizes a
failed build. It might then be a lot of effort to determine the cause of the problem.
Pattern 54: Establish short system integration cycles
Short system integration cycles ensure the permanent fit for all system parts.
Despite the continuous integration, complex systems often can’t be built
completely every time. Reasons may be that build time would be too long or
integrating with other systems is too complex. In this case, ensure regular system
integration cycles. Weekly cycles could be good target. This pattern is especially
important in offshore projects where insight into the status and awareness of
colleagues’ workspaces is impeded. Integration cycles are well proved to monitor
the progress and quality of the system.
Pattern 55: Ensure hierarchical builds
Build software systems hierarchically step-by-step and bottom-up from smaller lower-level input
artefacts to larger higher-level output artefacts. This includes introducing only hierarchical
dependencies between artefacts. Furthermore, your repository structure should reflect this
hierarchy.
A software system consists of one or more domain-specific subsystems. A
subsystem consists of one or more components, and a component consists of one
or more modules and finally classes of code. Even if you do not distinguish all
these structuring types, it is a best practice to organize the system in a strong
hierarchy. This is a presumption for a hierarchical build.
This hierarchy is the basic physical structure of a software system, and is created
systematically in a bottom-up manner by building its larger and higher-level
artefacts out of its smaller and lower-level artefacts. This build approach even
allows the efficient building of very large software systems. If an artefact is
85
updated or rebuilt, only the parent artefacts must be rebuilt as consequence of
modifications in this substructure. Of course, this presumes that your
dependencies between artefacts (compare pattern 56) follow this hierarchy.
This is especially important for offshore projects or big projects with distributed
teams. A hierarchical system allows independent development of artefacts that are
in parallel sub-trees.
Pattern 56: Check dependencies
Explicitly track and resolve the transitive build-time dependencies between artefacts to ensure a
transparent and traceable build result.
Even average-sized software systems have extensive build-time dependencies
between their contained artefacts, especially those generated by frequently-used
third-party libraries and frameworks. Hence it is imperative to explicitly track and
transitively resolve all those dependencies during the hierarchical artefact building
process. This becomes more important when you are heading towards a release.
Tools like Maven and Ant/Ivy can even help to fully automate this process. You
get the most power if your tool supports transitive resolution of dependencies.
However, tiny mistakes in the dependencies of your own or third party artefacts
can cause unexpected results. E.g. if you update the version of a third party
artefact the new version might weave in new dependencies that are undesired but
would be build into your product. To reduce problems restrict modifications of the
dependency-management in your project to few team-members that are skilled
accordingly.
With this approach, the build is completely transparent and therefore traceable.
Additionally, only in this manner an automated build procedure can safely resume
a build at any step and (re)build the necessary artefacts only. Finally, this also
allows the precise checking of complete license compatibilities between your own
and all third party units (see pattern 49).
Pattern 57: Automated transformation and generation
Avoid handcrafting intermediate or output artefacts. Instead, try to generate such artefacts
automatically.
Leaf artefacts in the artefact build hierarchy are the ones you create yourself, and
comprise the actual input artefacts for building. By contrast, all intermediate and
final output artefacts should be built fully automatically. This can be done either
by generating them from scratch or by subjecting existing artefacts to format
transformation.
86
Quasar 3.0
Pattern 58: Build-time beats run-time
Try to perform as many sanity checks and transformations as possible during build-time. Do not
inadvertently delay them until run-time.
Whatever you can do during build-time should not be delayed until run-time.
Hence, you should use the build-time period to conduct as many sanity checks
and transformations as you can.
For instance, during build-time, try to pre-validate your configuration (e.g. XML)
and script files (e.g. Groovy), and to format-transform and generate artefacts (e.g.
image, localization and internationalization data).
Pattern 59: Domain-specific bundling
Bundle your domain artefacts in accordance with domain specifics in the architecture and the
expected change frequency.
In order to optimally support the Test and Build & Deployment disciplines always
try to bundle your build-time artefacts in accordance both with your architecture’s
domain specifics and the expected change frequency of the artefacts.
For instance, if your architecture contains a domain-specific subsystem, ensure
that it is available as a separate build artefact in order to allow it to be easily tested
separately. And if two artefacts have two completely different change frequencies
during Implementation or even Operations, it is advisable to keep them separate.
All platform-specific sections should also be bundled separately.
Pattern 60: Separate environment configuration
Keep the deliverables of your software product free of any environment specific configuration.
Separate environment specific configurations from configuration-packages and
keep your software-packages portable. This allows building of software-packages
only once and then deploying them to different environments for testing. After
successful tests, the exact same binary package can be deployed for production.
This will guarantee that the software going live has been properly tested.
The environment specific configurations can also be bundled as packages per
target environment. However, it is important that responsibility and maintenance
of these objects belong to the system operators instead of the development team.
87
6.2.2
Deployment Management
Deployment Management is provisioning, installing, updating, upgrading,
migrating and uninstalling software packages in defined environments. It has the
purpose of building and maintaining structured and reproducible software stacks
constrained by package dependencies and individual product life-cycles. The
main objective of this discipline is to ensure that a software product is available
for operation. The deployment units as output of the Build Management sub
discipline form the input to this discipline. Figure 6.6 shows the artefacts of this
discipline.
Figure 6.6: High-level artefacts in the Deployment Management sub discipline
Pattern 61: Take care of the entire software lifecycle
Focus on the entire lifecycle of a software product by covering the installation, update, upgrade,
migration, and removal tasks.
Deployment is concerned with more than the initial installation of software
products or the brute-force overwriting of an installation during updates and
upgrades. Instead, this discipline covers initial installation, any recurrent
automated updating with compatible bug- or security-fixed versions,
semi-automated regular upgrading with possibly incompatible new versions, the
migration of the entire installation to a different target environment, and the
residue-free removal of the entire software product at the end of its operational
life.
88
Quasar 3.0
If you are going to plan the first installation in a production environment, then you
should think about the succeeding installations.
Some tasks are easy during the initial installation stage, but may become difficult
later and vice versa. For the initial installation, you need not think about database
schema migration. This can be a very difficult and time-consuming task for the
installation of update releases. If you plan this in advance, you can introduce
guidelines, which will simplify the schema migration for later releases.
Additionally, it is necessary to ensure that the product installation, update,
upgrade, migration and removal procedures are deterministically repeatable. This
is independent of whether the process is executed manually or automatically. In
case of manual installation, a detailed documentation of the process is required for
repetitions. Shutting down servers or starting schema migrations are typical
manual tasks.
Pattern 62: Master the artefact dependencies
Explicitly track and resolve the transitive run-time dependencies between deployment artefacts
to ensure a transparent and traceable installation.
First, clearly distinguish between build-time, test, and run-time dependencies, as
they typically have to be resolved at different times (build versus deployment),
and plain build-time or test dependencies shall not be included in the release
package. Refer to the pattern 56 for further details with reference to this issue.
Pattern 63: Separate environments
Separate environments for development, test, acceptance, pre-production and production.
There are three types of fundamentally required environments: development, test and
production.
All software is executed in a particular environment. For Custom Solution
Development (CSD) we distinguish the following environments:
The development environment is used for editing source code and building
the software product in the context of a single developer’s work. It usually
hosts the Integrated Development Environment (IDE) of developers and is
located on the developers’ desktops or on a dedicated development server.
The test environment is used for regularly integrating the software product,
executing test cases and centrally reporting the results to the developer
team. It may also host the Continuous Integration (CI) service.
The acceptance environment is used for final acceptance tests. It should be
a production like environment and is usually provided by the customer.
89
The pre-production environment is used for preparing the going-live
process. The environment should be identical to the production
environment. It can be used for realistic load tests, or to reduce the
downtimes due to the installation of the new system or the new release.
The production environment is used for operating the software product in
its intended production context. It is owned and controlled by the customer.
According to the actual requirements, you may have even more environments
(especially in large projects) or you may omit the pre-production or even
acceptance environment. In projects without an acceptance environment, the
acceptance test is done in the test environment, that therefore needs to be a
production like environment. In case of the very first release, the acceptance test
can also be done in the production environment.
With or without a pre-production environment, you should always plan a
smoke-test before you release the new system. The smoke-test should ensure that
the most important functionality is in a good working condition.
Pattern 64: Deploy the complete software stack
During deployment, focus on complete software stacks instead of single software packages to
ensure that the external requirements of a software package are exactly fulfilled.
Normally, deployment is not only about the installation of a single product.
Nowadays, almost all software products have numerous external run-time
dependencies (application libraries, system services, run-time configurations,
shared databases, etc.). It is in the responsibility of architects and developers to
ensure that all these external run-time requirements are precisely known in
advance and fulfilled during deployment. Therefore, it is a good practice to focus
on the deployment of complete software stacks instead of single software
products.
Pattern 65: Involve operations
Perform production environment deployments hand-in-hand with the operations team and
domain experts to ensure a smooth going live process.
The deployment of the production environment must involve operations and your
customer’s domain experts. The reason is that service windows of operations and
the domain-related business processes have to be taken into account for glitch-free
deployment. All operation departments have regulations on how to deploy
software systems and what are the preconditions to deploy them into production.
This includes, for example, that the new software has to support specialised
90
Quasar 3.0
monitoring or logging features, or that it must offer some dictated services, for
shutting down or starting the server process.
Hence, for every smooth going live process, you must always ensure that the
deployment is truly performed hand-in-hand with these stakeholders. This
involves clearly communicating what version is being deployed, when it is
deployed, why it is deployed, what user-visible changes will be apparent
subsequently, etc.
Pattern 66: Make and follow a detailed deployment plan
A detailed plan is required for all subtasks of the deployment including all tasks that are
prerequisites for the deployment.
The deployment of complex software systems with potentially many interfaces to
neighboured or external systems is a task that should already start in the analysis
or design phase. Here you should e.g. think about questions like "In which order
shall old interfaces be replaced with new ones?" or "How to migrate the business
critical data?". Therefore, make a plan including topics as data migration,
database schema migration, software deployment, environment specific
configurations, fallback scenario, point of no return, smoke test, down times etc.
Important questions to be answered for each topic are:
How long does it take?
Who executes the steps and when?
What prerequisites have to be met?
What can be automated and what is better done manually?
From such a plan, you should systematically develop a detailed documented
deployment process. This deployment process should be used and improved
during each deployment in the test environment. That is your chance to be as sure
as possible that everything will work fine for the go-live.
6.3
The Release & Change Discipline
Release & Change is the steering discipline through which the stable delivery of a
software product is ensured. It combines both the management of complete
releases and the management of single change requests assigned to releases.
Figure 6.7 shows the high-level artefacts of this discipline. Therefore, Release &
Change is composed out of the sub disciplines Change Request Management and
Release Management.
91
Figure 6.7: High-level artefacts in the Release & Change discipline
6.3.1
Change Request Management
Change Request Management is managing the process of submission, recording,
analysing, assessing, judging, prioritising, scheduling, implementing, testing and
verifying changes to a software product in a controlled and coordinated manner
and within defined scope, quality, time and cost constraints.
Pattern 67: Establish a well-defined change request process
Clarify how the process from submitting to closing a change request works.
All software projects have to deal with less or mostly more unplanned requests for
changes – so called CRs (change requests). Without a well-defined process in
which all effects on the project are properly analysed and evaluated, a project is in
danger to miss its targets in time and budget. The process should define the
responsibilities for submitting CRs, updating CRs, evaluating the business benefit
of the CRs, estimating the cost and other effects on the project for the CR, and
also rejecting CRs. If the CR will be accepted, it must be assigned to a release,
designed, developed and tested. The typical states involved in the process will be
submitted, accepted, duplicate, rejected, assigned, resolved and closed.
Pattern 68: Aligned change management
Align the change request management of your project with the customers change management.
92
Quasar 3.0
Your project and product is changing with every release. On the other hand, the
customer has higher plans for changes of the entire enterprise that have impact on
your project. Only if these two go together and you have your change request
management in sync with the customers change management you will add high
value for your customer. Therefore, exchange with your customer about ongoing
changes on both sides. Be careful to distinguish ideas from plans on the political
level.
6.3.2
Release Management
Release Management is planning and controlling the development, stabilisation,
release and maintenance process of a particular software product version in order
to maximise the quality of the product version within the defined scope, time and
cost constraints.
In contrast with change request management, release management deals with
planned changes and implementation of all requirements in several releases. As
soon as the positive decision for a change request has been approved, the change
request becomes a part of the release management to decide the proper release
that shall contain the change.
Pattern 69: Distinguish several release types
A release should have a type indicating the scope of the change compared to the previous
release. This will help to determine the impact of an upgrade. Best practice is to distinguish
between major, minor and micro releases.
Differentiation between at least the following types of releases is recommended:
A micro release contains only bug fixes, no new features and has no
syntactical or semantical effect on interfaces. The result is that minimal
testing is required to upgrade to such a release.
Minor releases may have some new features and/or changes in the API. In
an ideal case, the interface changes are compatible with the previous
version. Therefore, you need more testing and more effort when deploying
a minor release than deploying a micro release.
Major releases have several completely new features and may be
incompatible with older releases. Therefore, you should not only test them,
but sometimes you will also have to adapt neighboured systems. So the
effort to introduce a major release is quite more than for a minor release.
Align the types of releases with your product manager and reflect them in
your version identification (see also pattern 51).
93
Pattern 70: Plan at least these engineering phases
Each release has to pass through all the typical software development phases: specification,
design, development, integration test, acceptance test, and production. This also includes
maintenance releases.
We consider the requirement engineering as done. Now for every release we start
with a specification phase. Even for micro releases consisting only of bug fixes,
you have to specify, which bugs have to be fixed. During the specification phase
the software is not modified. Especially for bug fixes and smaller changes, design
and development can go hand in hand. It is good, if the same person who
designed the solution also implements it. During design and development, the
product is initially implemented or modified. It can be unstable and incomplete.
This phase should not end before all requirements, change requests and assigned
bug fixes have been developed. It also includes the development tests and the
resulting bug fixes. For major releases this phase typically takes months, whereas
micro releases may only need days.
The integration test phase can start if all changes and new features are
implemented. A software release is built and installed in the suitable environment
where the tests take place. The target is to get a stable version. Identified bugs are
tracked and fixed in a new development cycle. If the tests pass, you can go on to
the next phase.
Start the acceptance test phase with a suitable version. The environment used for
acceptance should be as close to the production environment as possible. The final
release candidate is the last version of the acceptance test phase that is built before
deploying it to the production environment. No changes at all are allowed
between the final release candidate version and the release version. If you find
bugs in a release candidate, that will be fixed, then you have to build a new release
candidate and acceptance tests should be repeated. Therefore, automation of
integrative tests can save a lot of effort (see chapter 7). Normally you will only
find a few minor bugs in your release candidate. As explained, bug fixing mainly
requires a new test cycle. But at this point, the next step depends on the criticality
of your system and your estimation of costs versus risks. Think about the
following alternatives:
Fix some or all known minor bugs and schedule a new complete user
acceptance test cycle.
Fix some or all known minor bugs and schedule an incomplete user
acceptance test concentrating on the most important use cases and on tests
verifying that the bugs are fixed. Such a decision depends also on your
estimation of the quality of the system, because you will estimate the
probability of introducing a critical bug, which your incomplete test will not
show.
94
Quasar 3.0
A third alternative may be, not to fix minor bugs. Although highest possible
quality should always be your goal, in some special cases it might be better
to know of some minor bugs than to risk critical bugs, because there is no
time for a new complete acceptance test.
The last phase is the production phase. It starts with going live of the release. This
go-live may include critical and complex steps such as migration of data, which
also needs to be planned and tested before. If you have done a good job, it will be
stable and no bug fix releases required.
The above comments also apply for agile methods, but here the phases are not as
strict and separated.
Pattern 71: Customer interaction is the key
For custom solution development, a focus on close customer relationships is the key to
succeeding.
In contrast to the standard software, the customer is well known to the IT solution
provider in the custom solution development. A strict focus on close customer
relationships in the release activities and change request management is therefore
the key to success. This means that at least, release management and product
management activities must be performed hand-in-hand with the customer and his
domain experts.
95
96
Quasar 3.0
7
The Analytics Domain
Distributed development, variable production depth and the trend towards
complex and integrated software systems increase the complexity and size of our
projects. As the scale of the projects grows, it becomes increasingly difficult to
achieve transparency in the quality of the software of the implemented application
components or the overall completion grade.
However, achieving this transparency is essential. Only if we control time, budget
and quality equally, can we undertake projects successfully.
Quasar Analytics® derives its name from analytical quality assurance. The
Analytics subdomain replaces the RUP discipline test with three disciplines, viz.
Quality Inspection, Measurement and Test. In doing this, we emphasis that
dynamic testing has to be complemented by static quality assurance, i.e. manual
or automated reviews of code and documents, for effective quality control.
Another advantage of having three separate disciplines is that each discipline can
be aimed at different project phases and at a different audience. The following are
the three disciplines in detail:
Quality inspection for ensuring the sustainability of artefacts developed early in
the project life cycle, such as the requirements specification or the system
architecture. This discipline is aimed at the chief architects.
Measurement to ensure the ongoing control of quality. In this discipline, special
emphasis is given to the maintainability and reliability aspects of the
application being developed. This discipline is aimed at the chief technical
architects.
Tests for reliably assessing the quality of the application as early as possible in
the development process. Through testing we focus on functionality as well
as certain non-functional quality characteristics such as performance,
usability, security, robustness and portability. This discipline is aimed at the
test managers and to some extent at other testing roles.
With Quasar Analytics® , we provide tools and methods for actively controlling
quality. We receive early feedback about the stage of completeness and the quality
of the application being developed. As a result, we are able to recognize risks to
quality at an early stage, and we are therefore able to take remedial action in a
timely manner.
The methods, utilities and tools of the Quasar Analytics® disciplines bring
transparency to the quality and thus making it controllable during the entire life
cycle of the software project. One key success factor here is concentrating on
artefacts instead of merely assessing processes. Processes may be effective or not,
but the crux lies in the artefacts developed. We concentrate on making their
97
Chapter 7. The Analytics Domain
internal and external quality visible at all times to everyone that is involved in the
project.
7.1
The Quality Inspections discipline
The correct functionality of code is just one side of the quality coin. It can be
ensured by intelligent and structured testing. But as valuable as testing is, it is less
powerful for assessing the immanent qualities of code, such as maintainability.
This is where the automatic measurement of metrics proves its worth, such as in
relation to the compliance of the code with the high-level architecture. However,
such measurements can only be performed on real code. But an inferior
architecture can impede maintainability from the very beginning, and this
becomes very expensive if the architecture has to be changed only after thousands
of lines of code have been written. Error correction costs increase exponentially
over time as shown in figure 7.1. Fortunately, quality attributes like performance,
reliability or security can be assessed a lot earlier in the project life cycle. We
achieve this with our quality gates.
Figure 7.1: Why do we need quality gates?
At Capgemini, quality gates are comprehensive evaluations executed at specific
points in time in order to assess the maturity and sustainability of the artefacts
produced and the processes that have been followed in order to produce them.
The quality gates are carried out by external assessors. They are complemented
by management assessments and internal code reviews. Figure 7.2 shows the high
level artefacts of this discipline.
98
Quasar 3.0
Figure 7.2: High level Artefacts in the Quality Inspection discipline
99
7.1.1
Basic Methodology
Specifications for large-scale business information systems usually consist of
hundreds of use cases and business rules, dozens of dialogs and batch jobs, and
large concepts for multi-tenancy or access authorization. All in all, a complete
system specification can easily consist of a couple of thousand pages. If we
discover that a specification contains systematic errors only after it has been
completed in its entirety, the effort required to correct these errors can easily
mushroom. The same applies to software architectures. Although software
architecture descriptions are less voluminous than system specifications,
consistency and completeness are still a major issue. If quality requirements are
not taken into account by the architecture, the resulting system will not meet the
customer requirements. Such issues have effects that cut across various
boundaries, and usually large portions of the code base have to be corrected
afterwards. Consequently, we have to find errors before they propagate
systematically through the entire product. Otherwise, the resulting negative
ramifications can be disastrous.
Pattern 72: Conduct quality gates after the first third of a phase
At the latest, do so in the middle of the phase.
Another important reason for not waiting to conduct the quality gates only after a
detailed completion of a specification or architecture is to prevent the feeding
back of problems into the preceding discipline. For example, if it becomes clear
that the quality requirements in a system specification are not detailed enough to
construct the architecture properly, there must be immediate feedback to people
who specify the system (business analysts). If this happens too late, there is the
risk that the domain experts are no longer accessible and it is difficult or no longer
possible to retrieve the necessary information. Figure 7.3 shows the methods that
can be used here.
Pattern 73: Use active evaluation methods
Walkthroughs are complemented by tough test questions that truly pinpoint the weak spots.
As soon as a reviewer is able to lean back while the project members explain the
product of their work, his attention will slacken off. This is due to what we call
the cinema effect, or looking on and mentally drifting off instead of carefully
scrutinizing what is going on. If reviewers have to navigate through the work
product themselves, they will necessarily stumble across under-specifications
because the team members cannot "auto-complete" missing information that
resides only in the heads of the authors.
100
Quasar 3.0
Figure 7.3: Evaluation methods of the specification quality gate
Quality gates are not guided sightseeing tours, but tough reviewer-driven
assessments. To judge the viability of a work deliverable, the reviewers must be
able to understand the work deliverable on their own. Ultimately, every
programmer must be able to do this. We use different evaluation techniques, such
as specific checklists, walkthroughs or change scenarios, in order to obtain a
complete picture of the maturity of a work product.
Pattern 74: Use project-external reviewers for quality gates
Project-external senior architects are not "routine-blinded” or biased and have a broader
background.
Others will find an error more easily than the individual who produced it. The
basic idea of a walkthrough is shown in figure 7.4.
If someone invests a lot of effort into creating a work deliverable, he will have a
corresponding emotional investment in his product. But this makes it increasingly
less likely that he will be able to step back and assess his work with an unbiased
eye. This is why it is very important that work deliverables comprising the basis of
numerous downstream activities be evaluated by project-external senior architects.
This also provides valuable fresh insights and leverages the time-served
experience of such senior employees. We have often encountered situations in
which an assessor has exclaimed, "Hey, in my last project, I also used distributed
101
Figure 7.4: Basic idea of a walkthrough
caching. But after a couple of weeks I learned that this decision regarding the
architecture conflicted with our failover requirements. And you too have very
strict requirements of this sort".
Pattern 75: Concentrate on the quality 4 + 1
Efficiency, maintainability, reliability, usability and their tradeoffs.
Efficiency issues like performance almost always prove to be a challenge when
devising large and complex multi tier systems. They often compete directly with
maintainability and reliability. The most difficult thing is to get these tradeoffs
right from the customer’s perspective. Concentrating the evaluation on these
attributes and their mutual tradeoffs results in a very good cost/ benefit yield from
the quality inspection).
Beware of concentrating your inspection on issues that are easily assessable but
less critical. Taking system specifications as an example, it is much easier to
evaluate the structure and form of the specification: "Do they really use use cases?
Do they really comply with the specification method?" Of course, such checks are
important in their own right. But the really critical issues can most often be found
at the level of content. This is also where the active methods come into play.
Scrutinizing a use case with a walkthrough can reveal critical performance issues.
ATAM (architecture tradeoff analysis method) can reveal that a software
architecture might not support the business drivers. Change scenarios might shed
102
Quasar 3.0
light on insufficient tracing between work products. Poor traceability can
dramatically diminish the capability for conducting impact analysis, which in turn
can make effective change management impossible. Figure 7.5 shows the
advantages gained by using quality gates.
Figure 7.5: The advantages gained by using quality gates
7.1.2
Inspecting system specifications is one of the most effective and efficient quality
assurance techniques, as systematic defects can thus be detected early in the
project life cycle. As the clarification and resolution of specification issues at a
later stage is communication-intensive and is therefore heavily impeded by the
distributed nature of the team, such inspections become especially important in
offshore projects.
Pattern 76: Check your specification early and often
Concentrate on the offshore-specific challenges connected with specifications.
Rigorous inspections performed by senior architects external to the project are
important. We complement these with continuous peer-to-peer reviews. In
offshore projects, such reviews are carried out jointly by members of the onshore
and offshore teams. This increases the logistical effort required to prepare and
schedule the reviews, but pays off handsomely in terms of knowledge transfer and
team building.
103
Pattern 77: Use handover checkpoints to effectively delegate work
Bundle deliverables into work packages and check them from the recipients’ point of view.
Clearly defined handover checkpoints help us control the development process,
because they allow the transfer of responsibility in a defined manner. The
checkpoints ensure that the recipient team can safely start its work.
We use a clear definition of work package derived from the Quasar Ontology that
helps bundle cohesive and self-contained sets of work units. This helps regulate
the communication between distributed teams, as it reduces the need for
repeatedly chasing up missing information. In the so-called Work Package
Handover Checkpoint we also assess whether the team is employing precisely
defined acceptance criteria and quality objectives. This makes it clear when a
single work unit or a complete work package is finished, and forms the basis for
effective earned value analysis.
In the Result Handover Checkpoint, compliance of the work package results with
the defined criteria and objectives is checked. We also assess whether the work
package results were constructed on time and within budget. We evaluate how
potential deviations from the plan are being considered by the project
management, and whether their impact on the overall schedule is being estimated.
This continuously realigns the engineering disciplines with the management
disciplines.
Taken together, the notion of handover checkpoints and work packages supports
the clear handover of responsibilities based on precisely defined work packages,
allows earned value analysis, aligns the engineering disciplines and ensures
effective knowledge transfer in offshore projects. The handover checkpoints are
also the prerequisite for enabling the transfer of larger work packages and for
avoiding failure resulting from the micromanagement of the coding done by the
distributed teams.
7.2
The Measurement discipline
Unlike time or budget control, the systematic measuring and judging of software
quality is less straightforward. There are hardly any conventional methods and
tools that help assess the overall quality of the application. The Quamoco project
(s. [33]), for example, to which Capgemini contributed as one of the partners,
aimed at this goal. In software engineering, quality control is a challenging skill.
Software measurement is our answer to the requirement for ongoing quality
control. Quality control requires genuine transparency based on facts put into
context. We want to make software quality as tangible, transparent and provable
as possible at any point in time. Figure 7.6 shows the high level artefacts of the
Measurement discipline.
104
Quasar 3.0
Figure 7.6: High level artefacts in the Measurement discipline
On the basis of the quality requirements and a definition of what quality means for
your project or scope, you define indicators that are capable of assessing the
quality of your system in this defined context. You also select analysis patterns
that help to identify quality risks and provide interpretation aids.
The outcome is the assistance provided to the project management team for
assessing and evaluating the quality and the completion status of the software on
the basis of facts instead of mere gut feeling. It will help to provide an early
warning system for recognizing quality risks in the battle against software erosion.
7.2.1
Basic Methodology
Pattern 78: Specify your quality model
Take our standard quality model and tailor it to your needs. Use GQM to derive requirements
that are specific to your project.
Measurement is merely measurement and nothing more. It cannot improve your
software, the completion status or the software’s quality. So quality control
requires appropriate responses to be effective.
But how do you know when to respond? It is crucial to define what quality means
in relation to your project and which indicators are relevant for assessing this
quality. In other words, you have to define your quality model. A good way to
105
derive indicators is the goal-question-metric approach. You define the goal,
identify the concrete indicators that will ensure the goal is reached, and finally
define the metric for measuring these parameters. Some of these indicators may
originate from customer requirements. Most of these indicators do not need to be
reinvented; we provide a standard quality model that contains best-practice
recommendations.
The defined quality model should become an integral part of the development,
risk management and test guidelines. So team members have concrete rules that
proactively help to ensure quality.
If quality requirements are not met or do not exist, the project management team
needs to take action. Once they do, these actions in turn change the quality model.
So the quality model is not rigid and unchangeable, but needs to be adapted in
response to project developments and trends, changed awareness and improved
knowledge.
Pattern 79: Don’t measure everything
Use a small set of quality indicators with practical relevance for our software blood count.
What is important for software quality? Not everything can be measured; some
aspects cannot be easily measured at all some should not. Focus on metrics that
affect software quality in practice.
Choose the right scope. Some parameters require a risk-based approach.
Performance, for example, does not need to be measured across all functions, but
only in relation to performance-critical functionality. This functionality has to be
defined. Some parameters need to be measured thoroughly. The number of errors
or completion statuses can be interpreted correctly only if they are measured
across the entire system.
You do not have to reinvent these metrics. The software blood count is
accompanied by a set of proven metrics and quality indicators which cover a wide
range of the quality spectrum. You can adapt them or use them for your project as
they are. The most important indicators are surely code analysis, test and
architecture management indicators, project status figures and change rates. Be
aware that software measurement is not based on static code analysis alone.
Quality measurement requires a holistic perspective that considers all
quality-relevant sources of data. Figure 7.7 explains what we understand by
Capgemini Software Blood Count V2.0.
Take care to ensure that your metrics stay simple and understandable. Not
everybody is a metrics expert or is able to comprehend a sophisticated metric.
You need provable and simple figures that anyone with good software engineering
expertise can understand. Ultimately, the outcome will affect your project
106
Quasar 3.0
Figure 7.7: Capgemini Software Blood Count V2.0
processes, as it may require policies, process guidelines and process changes.
That will only be accepted by the team when you achieve practical and substantial
added value. Nobody will understand process changes just for the sake of
improving statistical values. Less is more in this case.
Speaking of the team, there is one more point to mention. Be aware while
defining quality indicators that the measured values will change their perceived
significance; people may be tempted to optimize them. If you measure the change
rate of lines of code, that number will decrease as soon as the people in your
project recognize its significance. But that will not necessarily improve your
software’s quality.
Pattern 80: Watch the trend
Continuously measure and understand trends – not just the absolute numbers, but their
direction.
Trends are more important than individual snapshots, especially for the early
recognition of quality deficiencies. The conclusions drawn from observing trends
are less vulnerable to the effect of temporary outliers, and are therefore more
reliable. Be aware that every metric interpretation has to take the context into
account. Some trends may be subject to multiple interpretations. Did the number
of defects which were found during system testing decrease because the latest
round of testing was ineffective, or did fewer defects slip past development into
107
the testing process? Make sure you understand what the data is telling you, but
don’t rationalize your observations away.
Experience and expertise can help you interpret the figures and trends correctly.
Detection patterns in tools like the software cockpit can be used to recognize
typical and recurring quality problems associated with certain metric
constellations. They help to identify quality risks. You will also find proven
recommendations for threshold values in the form of best practices and
preconfigured reports.
Pattern 81: Humans do it better
Quality is too complex to be measured automatically – the evaluation should be left to people
who know the context.
Some quality characteristics can only be vaguely measured. You will not be able
to fully quantify those kinds of quality parameters, so you should not even try.
Certainly, those kinds of characteristics should be considered, but they should be
treated as what they are, merely impressions of quality indicators, not quantitative
numbers. Only humans are able to place metric values into the context in which
they were measured.
Some tools build on automatically computed quality indices to give the software
quality a number. We don’t encourage this, because quality is inherently complex
and complicated, and cannot be presented as a single number. There is no simple
measure for overall software quality. Quality is the result of careful, creative
work, not a consequence of simply tuning software metrics.
Don’t forget: the measurement of quality indicators is just the beginning. It does
not in itself improve quality. That is achieved via the definition of the quality
model, the interpretation of the measurement results, the risk classification of
indicators and the implementation of appropriate measures to increase quality in
the event that action is needed.
7.2.2
The Offshore Methodology
What is code quality? Even within a single team in the same company, code
quality can mean something completely different to two different developers.
Again, this problem is further intensified in offshore projects where different
process models and engineering philosophies are applied. Code quality must be
defined early and explicitly.
108
Quasar 3.0
Pattern 82: Nail down code quality
The whole team must commit to a common code quality model.
Distributed working also makes it difficult to apply proven software engineering
practices like pair programming. Techniques like code reviews suffer from the fact
that its participants cannot sit next to each other. Thus, planning for code quality
becomes even more critical in distributed project settings, and must start early.
Pattern 83: Continuously review the code for comprehensibility
Concentrate on structuring it from the business logic point of view in order to enhance
maintainability.
In offshore projects, we especially review whether the code can be read and
structured from a business-logic perspective. This greatly increases the
maintainability of the code base.
A particularly important issue for offshore projects is to provide continuous
onshore support for the offshore colleagues. And bear in mind that some
colleagues might need some training before they start coding.
Pattern 84: Plan code quality assurance early
And continuously adapt it to the experience level of the developer.
Continuously adapting the code quality assurance plan is necessary to cope with
the increasing experience level as well as the potential attrition of the team. This
ensures an optimal cost/benefit factor of code quality assurance. Figure 7.8 shows
the code quality life cycle.
Pattern 85: Exploit the Software Cockpit to achieve transparency
Continuously monitor code quality and evaluate quality trends.
The Software Cockpit is not a tool for controlling or supervision. It is a powerful
tool for enabling the team to achieve a common understanding of where it actually
stands. It shows the overall status and uncovers hidden quality problems. All
these things are especially critical in offshore projects.
109
Figure 7.8: Code quality life cycle
7.3
The Test discipline
Testing yields transparency regarding software quality in a very different way than
other quality assurance measures do. Testing is the first hands-on experience of
the actual implemented system. For the first time in the life cycle of the software,
one knows for sure what the system really feels like. One can experience the
different system parts, dialogs and functions that were hitherto only described on
paper. And now the customer can judge much more easily how well the system
actually meets his expectations. Figure 7.9 shows the high level artefacts of the
Test discipline.
However, experiencing the system is not enough. Testing must estimate the
quality of the software, reliably and comprehensibly. The main goal of testing is to
lower the product risks. But you will not achieve certainty by just "trying out" the
software. That is why you need a structured and well thought-out testing process.
At Capgemini we structure this process in accordance with ISTQB1 in both test
levels and test activities. With regard to test levels, we distinguish between
component tests (also known as developer’s tests), subsystem tests, system tests
and acceptance tests. For the single test activities like test planning, the
Capgemini Test Methodology provides step-by-step descriptions. It also provides
checklists, templates and tool support for a quicker start in actual projects. In the
following, we describe the underlying principles.
1
ISTQB stands for "International Software Testing Qualifications Board" and is the international
de-facto standard for software testing.
110
Quasar 3.0
Figure 7.9: High level artefacts of the Test discipline
7.3.1
Basic Methodology
Pattern 86: Test early and continually
Have a separate test team systematically test the subsystems already during implementation
while involving the customer. Test the integration step by step.
Intensive testing is often performed only a few weeks before production. You may
sometimes hear the maxim First implement, then test, as early testing is often
associated only with the developer’s xUnit tests. However, if this approach is
followed you will end up with really late testing, which brings with it enormous
risks as shown in figure 7.10.
The intensity of the component (or xUnit) tests depends mostly on the time
pressure placed on the corresponding development team. The more pressure a
team is under, the more errors they will produce and, at the same time, the less
well thought-out their unit tests will be. This usually results in intensive xUnit
tests of cleanly programmed components and definitely not enough testing of the
error prone ones. Consequently most of the problems will come to light in the
system tests, just a few weeks before productive operation. At this point time is
short. Now you have almost no chance of resolving fundamental errors,
refactoring error-prone components or integrating additional and important
customer needs.
111
Figure 7.10: Late testing carries enormous risks
Therefore, we promote:
Goal setting and identification of critical test aspects for component testing
too, plus monitoring of the achievement outcomes.
Testing every subsystem as soon as it has been completed, by a separate test
team, using realistic test data, in parallel with the implementation.
Integrating subsystems and testing their integration step-by-step.
Performing non-functional tests as early as possible.
Involving your customer in the functional subsystem tests.
If you adhere to these fundamental rules, most of the functionality will be tested
concurrently with implementation and will thus be validated early and reliably.
Errors contained in single subsystems or their interfaces will be revealed early in
the process. Once implementation is complete, "only" the system test remains.
During this test, the test team can concentrate on testing the overarching
processes. Figure 7.11 makes clear that early and continual testing lowers risks.
All this is true not only for the functional tests but also for the non-functional
ones. As test manager, you have to ensure that important requirements regarding
performance or load testing are validated early. You should know these
requirements and adjust the project planning accordingly.
These early tests are the first indication of what the system really feels like. We
strongly recommend sharing this knowledge with the customer. You can do this in
different ways: via previews in the form of sub-system presentations, in hands-on
112
Quasar 3.0
Figure 7.11: Early and continual testing lowers risks
workshops, by writing and executing tests together, or even through simultaneous
operations that include the new application components alongside the system to
be replaced. This results in early benefit and valuable feedback about the system
being built. Only the customer can tell you how well the system actually meets his
expectations. And the earlier you find this out, the better.
Pattern 87: Perform risk-based testing
Set priorities for testing according to the product risks. Where there is high priority, automate
the derived test cases and test them as early as possible.
Complete testing is impossible for all non-trivial IT systems. Therefore, you have
to set priorities in order to focus your testing efforts as shown in figure 7.12.
Our test methodology helps you define a suitable number of test cases by focusing
on the product risks. Accordingly, the first process step is setting up a
prioritization matrix. In this matrix, the test manager evaluates the importance of
the project-relevant quality characteristic for the objects being tested. For
example, performance can be critical for one subsystem but insignificant for
another.
The prioritization matrix suggests appropriate test types for each quality
characteristic. Thus, you can use the matrix for the initial planning of what to test,
how intensively, and at what test level. A quality characteristic with a high
113
Figure 7.12: Priorities in testing help to focus on the critical parts oft he system
priority should end up in very structured derived test cases and with a high grade
of test automation. You can also reduce product risks by executing the
high-priority test cases as early as possible. Therefore, the test manager should
interact closely with the project manager, who should align the implementation
planning with the risk-based prioritization.
Time after time, we encounter objections such as, "In our project, everything is
important. Setting priorities doesn’t work for us.” However, keeping the product
risks under control is only possible when you consistently set your priorities.
Every project faces a risk of not completing on time or on budget. If you do not
set priorities, things are left to chance when time and budget pressures increase.
Ultimately, it will always make an important difference whether all the elements
of the system are 90% complete and are still full of defects, or whether certain
critical, central system elements are operating reliably while other, less critical
elements have not yet been intensively tested. Don’t delay priority decisions until
the end of the project, because by then you will have very little room for
manoeuvre left.
Pattern 88: Do preliminary tests at a subsystem level
Run preliminary tests first in order to estimate the quality of the software. If it is good enough,
carry out thorough testing. Otherwise, think about how to improve its quality.
Testing is not an appropriate method for substantially enhancing software quality.
114
Quasar 3.0
Often, testing exhausts both time and budget because of inadequate software
quality. Finding, reporting and administrating numerous defects is
time-consuming, and retesting them is even more so. The "Testing quality into
software" approach is often tried, but it is inefficient. If there is still high error
density in a subsystem or a system, other measures for enhancing software
quality, such as code reviews, are much better.
This is why we recommend assessing the quality of the (sub)system before
embarking on intensive testing. You can do this by a preliminary test. In this test,
you take a random sample of your test cases and count the errors found. From this
error count and the time invested you extrapolate the total testing time, thereby
obtaining a rough estimate of the (sub)system’s total error count. If the estimated
quality achieved is good enough, you proceed to test the (sub)system. Otherwise,
measures for improving the software quality will have to be taken.
Pattern 89: Draw up a two-stage test specification
First test aspects, then test cases.
A structured and well thought-out test design is a prerequisite of sufficient and
auditable test quality. A fundamental issue here is to split the test case
specification into two steps:
Step 1: Methodically develop test aspects from the specification. Test aspects
describe briefly what must be tested for a special use case, dialog, etc.
These aspects are captured in a list. Together with the analysts and the
customer, the testers prioritize the test aspects and assign them to the
planned test levels. While plausibility checks, for example, can already be
performed during the component test, single use cases can be tested in
subsystem tests, while complex processes must wait until the system test.
Step 2: For every high-priority test aspect, describe at least one test case as
shown in figure 7.13. If appropriate, automate it immediately.
With this two-stage test specification you can effectively avoid redundancies
between test cases at different test levels. Test aspects make comprehensible what
is tested, as well as when, why, and how intensively. The scope of testing and the
prioritization will be assured through early collaboration with the analysts and the
customer.
115
Figure 7.13: Derive test cases via test aspects
116
Quasar 3.0
Pattern 90: Use test automation
This is especially important for high-level functional tests.
Many people shy away from automating high-level functional tests. The reasons
for this are mostly inadequate tool expertise in the project, the fear of substantial
maintenance effort, and a lack of time. Many testers are still haunted by memories
of the early automation tools. Using these, it was necessary to adapt the
automated test cases or even re-record them after every tiny change to the GUI. At
that time, the maintenance effort expended during the execution of the tests
greatly exceeded the cost savings. Test automation tools have improved greatly
since those days. The recording of test cases is no longer restricted to GUI
coordinates, and recorded test cases can usually be read and modified, while many
tools now support the testing of different GUI types as well as databases and
direct function calls. Test automation has become an investment which – if used
correctly – is rewarding. Figure 7.14 motivates this.
It provides the following benefits:
Reduced time pressure and risks during the late project phases: With
automated test cases you can assure software quality much faster. When bug
Regression testing on late implemented bug fixes is therefore less critical.
More efficient protection against side effects.
Cost savings: While test automation initially costs more than writing
manual test cases, it pays off in the long run, because the execution of
automated test cases is less time-consuming. Normally, the break-even
point lies between 2 and 5 test runs. This number is reached in every
project, usually even with a single subsystem test.
Less monotonous manual testing.
Faster delivery for both releases and hot fixes.
In particular, you should not underestimate the flexibility achieved when
delivering follow-up releases and hot fixes. Without test automation, you must
either devote a large amount of test effort to hot fixes or accept a considerable
potential risk when releasing the hot fix for production. The bigger the system is,
the worse this dilemma becomes. As a system grows, the amount of old
functionality that has to be safeguarded increases with every release. If it is not
regression-tested there is a growing risk of unknown side effects and serious
errors occurring directly in production.
We therefore recommend performing test automation at an early stage and using it
throughout the life cycle of the project. To this end, it is indispensable to have a
clear test automation strategy that offers guidelines as to which test cases should
be automated, as well as when and how. The aim is not to achieve 100% test
117
Figure 7.14: Test automation pays off
automation. Instead, in most projects an automation level of 50-80% can be
effectively reached with intelligent test automation.
7.3.2
Manufactural Methodology
Agile Projects or projects with agile elements such as test driven development
(TDD) have become increasingly more relevant for us over the last couple of
years. We have conducted interviews with test managers involved in such projects
[11]. Besides this, we have spoken with professionals from the “Web Solutions
competence centre”. Especially, in the web engineering domain, agile practices
are popular. In addition, we contributed talks like [25] to conferences, where we
discussed the topic of typical testing problems in agile projects with other
industry companies. On the strength of our experience the test method we
developed for traditional projects can also be used in agile projects. To structure
the tests by the known test phases, test levels and test management topics is viable
in an agile environment as well. While the superstructure of the method prevails,
some elements have to be adapted in a way to cater for the demands of the agile
approach. We describe some of the identified patterns pertaining to the test phases
test planning and steering,
test design and
test execution.
118
Quasar 3.0
These patterns are primarily based on the agile approach of cross-functional teams
where developers do coding and testing and the techniques “short iterations” (two
to four weeks), “continuous integration” and “collective ownership”. The
following patterns combine the named agile elements with our test method.
Pattern 91: Scale testing with cross-functional integration team(s)
Additional integration team(s) keep(s) track of the high-level view of the system and its
requirements.
Agile methods emphasize the importance of individuals and their interactions.
The communication and collaboration of developer teams with more than nine
members are too complex. So in large projects we need to scale up teams with
parallelisation and integration to a higher level. In Scrum, the most common agile
methodology, this kind of scaling is called Scrum of Scrums. Team members of
lower level teams participate in higher level teams.
A proven practice is to have dedicated agile testers who assure quality with the
focus on testing and the progress towards “Done”. These testers should be
members of higher integration teams. The higher integration teams do not only
test, but they also code integration functionally, do bug fixing and refactoring to
form the complete system.
Pattern 92: Realize integration tests in additional iteration(s)
Consolidate high-level requirements in additional iteration(s) with a short offset.
High-level requirements cannot be realized by only one team. Integration teams
consolidate lower-level artefacts into higher-level artefacts. Corresponding
lower-level requirements are implemented by associated lower-level teams. All
teams write continuously unit, acceptance and non-functional tests according to
their definition of “Done”. They consider simplicity and separation of concerns.
Integration teams start their iteration with a short offset compared to the
lower-level teams. All associated lower–level teams start their iteration at the
same time. The iteration length is equal for all teams.
Pattern 93: Use the structured test design pattern for critical user stories
Test aspects are the key to synchronize collaborating teams.
One of our key findings is that the use of test aspects, as a means to synchronize
test levels, is not only applicable to but of paramount importance for testing in
agile projects. Therefore, dedicated agile testers design a test strategy by making a
119
trade-off between risks and effort and use structured test design to ensure that test
coverage meets prioritization of artefacts. Agile testers choose the right test
design method and derive the required test aspects for critical features. These test
aspects can then be implemented by lower-level teams. Such an approach
provides a framework which determines the appropriate granularity for the test
aspects and reduces the risk of implementing too many and wrong tests.
120
Quasar 3.0
8
The Evolutionary Approach
Business needs to quickly adapt to the fast changing market demands. Large IT
systems tend to slow down these changes, thus becoming the business snag. The
flexibility concerning such changes will be one of the major success factors, in the
future, eventually turning into a critical surviving factor to be competitive on the
market. As mentioned in chapter 2 of this book, the sequential methodology
would be too rigid for these purposes. Trends such as service oriented architecture
(SOA) and business process management (BPM) combined with business rule
management (BRM) allow evolutionary approaches and promise to get more
efficiency and flexibility. However, it is not sufficient to just follow hypes but to
have a strategy on how to combine new trends to an overall solution. There are
many patterns of the sequential methodology that are valid for the evolutionary
approach, too. Nevertheless, evolutionary software development requires chunks
of additional or variant methods. Here, we will go into more detail with respect to
these differences compared to the sequential methodology by describing the
individual domains and disciplines and defining new patterns where they are
useful and needed.
8.1
Impact on Requirements Engineering
As a matter of principle, the statements and patterns concerning requirements
engineering are relevant for evolutionary methodologies, too. Before modelling
business processes and business rules, the goals of our customers must be well
understood to fulfil their expectations to the maximum extent. It is necessary to
develop system visions formalizing this information in an appropriate way. One
possible solution in this context is the business motivation model (BMM) of the
Object Management group (OMG).
Pattern 94: Capture process goals
Describe process goals first e.g. using business motivation model (BMM) and associate them
with assets (processes, rules, etc.).
The goals and requirements shape the high-level view that is broken down into
use cases and main business processes. Main business processes get detailed by
sub-processes and business rules and services. By linking these artefacts with
use-cases and requirements, projects become structured and transparent. This is
very helpful for estimating, planning and monitoring.
121
Chapter 8. The Evolutionary Approach
Pattern 95: Manage goals in BPM-Suites
Goals, requirements, and use cases should be captured and mapped to processes and rules in
the BPM-Suite itself, if supported by the product. By doing so, future changes and maintenance
is improved because dependencies remain visible in the system itself.
If you are very familiar and efficient with the BPMS modeller you can even
directly capture the objectives (DCO) in workshops with the business department.
Otherwise use the whiteboard and transfer the results to the BPMS afterwards.
8.2
Impact on Analysis
Several BPMS products are based on more IT-centric notations like the business
process execution language (BPEL). As a result, business models have to be
converted before they can be executed. Afterwards, the generated IT models have
to be extended and modified. This leads to trouble in round-trip engineering when
the original process models have to be adapted to new business needs.
Pattern 96: One model approach
Create business-oriented process models and make the same models executable. Use a single
notation for modelling and execution. Our current suggestion is to use the standard BPMN 2.0.
The main idea of evolutionary software development is the existence of one
central model that is subsequently enriched by business and technical details until
it eventually becomes executable. As opposed to model driven development
(MDD), it does not need to be translated into another representation by generating
documentation or code. This implies the use of a single notation that is able to
express all these details and, on the other hand, can easily be executed by BPMS
products. Besides vendor specific languages fulfilling this requirement, the
business process model and notation (BPMN) is a prominent common notation
that is supported by a growing number of systems.
Pattern 97: Simple notation
Reduce the set of modelling elements to the required minimum to make the models more
understandable by business and IT.
Even by using a widespread notation, the individual BPMS products often lack
full support of all elements that are defined by the standard. In particular,
extensive notations like BPMN 2.0 contain a lot of constructs for special cases
that can be omitted without large impact on the expressiveness of the resulting
diagrams. Unfortunately, there is no commonly agreed subset. Moreover, many
122
Quasar 3.0
BPMS vendors undertake modifications of the syntax and semantics leading to
incompatible implementations. This hinders the exchange or even the migration
of business process models from one system to another. To minimize these
effects, it is recommended to use a well-defined subset of relevant modelling
elements. As an additional benefit, the models become more comprehensible.
Pattern 98: Use process layers
Structure process models on at least four layers: high-level, happy path, reality path, and fully
executable. It helps to make the models more manageable.
The one model approach is very helpful to facilitate future adaption of the
business processes. On the other hand, it runs the risk of overloading business
models with a lot of detailed information. This will be a serious drawback
because such models are difficult to understand and hard to maintain. It can be
compared with a JAVA application consisting of only one main method with
thousands of lines of code. The solution in respect of JAVA would be splitting the
code into packages, classes and methods. In the context of business process
models, the complexity can be reduced by structuring the models on multiple
layers using sub-processes. There are four important abstraction layers:
High-Level: In the first step, main business processes are collected and described
with a very high level of abstraction. This includes a suitable name for the
process, the process goal and summary, and the responsible owner(s) and
users. Further, a rough flow with the main steps in the process and the
relations between the main business processes are modelled with input and
output management.
Happy Path: The individual main business processes are detailed ignoring
special cases and exceptions in their execution. Only "best case" or "normal
case" behaviour is covered by this kind of model.
Real Path: The happy path model is enriched by exceptional business behaviour
(e.g. if an important information is not available).
Fully Executable: Unlike the other models containing only business details, this
layer introduces technical information needed for execution like process
variables, service calls, or user interfaces. This model depends on the
selected BPMS product and is vendor-specific.
The four layers can be divided again by structuring the happy path into
sub-processes or separating the fully executable model into several technical
aspects. Again, the realization of model layering depends on the elements and
artefacts of the individual modelling notation (for example, BPMN 2.0 offers
collapsible sub-processes).
123
Pattern 99: Separate processes and rules
Normally, BPM should always be combined with business rule management (BRM). Use
business processes for the flow and business rules for finer grained decisions.
Business processes need to be business-oriented and readable to business
departments. Therefore, implementation details should not be visible in the
process model. Here BRM helps as an additional layering to reduce complexity.
BRM deals with capturing, defining, and implementing business rules.
For example the process model should only show decisions in the language of the
business. The actual implementation of the decision is realized by a business rule
that gets connected to the decision element (gateway) in the process model (see
figure 8.1). BRM offers powerful concepts such as decision tables to realize such
decisions in a way that is readable to business departments.
Figure 8.1: Interaction of BPM and BRM
A very important aspect is to find the golden section between processes and rules
(see [21]). A lot of experience is necessary to achieve good interfaces. The right
combination increases the flexibility and maintainability of the solution.
Most BPMS products support BRM as an integrated solution. Otherwise, it is
possible to exhibit the rules as services that are invoked by the business process.
In both cases, it helps to make the process models more understandable.
124
Quasar 3.0
Pattern 100: Classify rule sets
Tag your high level rule sets with one of the four categories each: integrity, derivation, reaction,
or deontic. This classification helps to find and understand business rules.
BRM typically leads to a rich set of rules. To reduce complexity they should be
well structured and organized. This is done by grouping finer grained rules to
higher level rule sets. We further recommend classifying these rule sets into the
following categories (see [IntBpmBrm]):
Integrity rule set: They are used to ensure data consistency by defining
assertions that must always be satisfied and are permanently ensured.
Derivation rule set: They derive new knowledge from existing one, typically by
mathematical calculations that are assigned to variables in the data model.
Reaction rule set: They describe decisions that control the order of the process
steps.
Deontic rule set: They connect the organization model to activities in a process
(e.g. authorization rules or allocation of human tasks).
8.3
Impact on Design
The evolutional development of applications has major influence on the IT
architecture as it is based on service oriented architecture (SOA) and a BPMS
product. The services are accessible through some kind of integration mechanism
like enterprise service bus (ESB) or enterprise application integration (EAI).
Mostly, the BPMS is integrated into an enterprise portal or brings along its own
front end. Figure 8.2 shows the relations.
Pattern 101: SOA Alignment
Ensure that the services in the underlying SOA are tailored in accordance with the business
activities needed by the BPM models and vice versa.
Because the automation of BPM models are based on invocations of functions that
are implemented in the SOA it is important that activities and services are
corresponding to each other. Therefore, it makes sense to keep an eye on business
processes when defining domains and service interfaces in the underlying SOA
layer (see chapter 9).
125
Figure 8.2: BPM Reference Architecture
The BPMS itself can be divided into several parts:
Business modelling client: This component is mainly used by the business
architects to edit the process models and rules according to the business
needs.
Business process engine (BPE): This is the core component as it eventually
executes the process models, invokes underlying rules and services, and
realizes the human task management combined with user interface forms.
Business rule engine (BRE): The business rules are made available by the BRE
that implements the forward and/or backward chaining algorithms and
exposes their interfaces.
Business activity monitoring (BAM): The controlling uses BAM for
monitoring and reporting of running or finished process passes.
Large BPMS products contain all these parts whereas lightweight solutions –
especially open source frameworks – focus on a smaller subset. Nevertheless, it is
possible to combine multiple products to a holistic BPMS solution.
Pattern 102: BPMS Selection
Choose the appropriate BPMS product based on functional, technical, and economic aspects.
Perform selection early and start modelling based on the selected tool.
126
Quasar 3.0
BPMS products cover a wide scope including modelling, integration, monitoring,
reporting, and human workflow management. Therefore, the features of the
BPMS have large impact on the realization of the actual project and the whole
enterprise. In particular, processes and rules should be modelled in the targeted
BPMS product to avoid wasting effort. Even though BPMN 2.0 standardises well,
BPMS vendors provide more or less differing dialects. The translation between
notations is time-consuming and difficult. Furthermore, by using BPMS products
for modelling allows seamless integration of all relevant aspects like BRM or
BAM from scratch on. This leverages additional efficiency.
8.4
Impact on Development
In the context of the evolutional approach Development is mainly limited to
creation and succeeding enrichment of models representing business processes
and business rules. Indeed, this presumes several conditions about the technical
environment of the BPMS system:
Service orientated architecture (SOA): The services needed for the
implementation of automated processing are appropriately available. This
includes the connection to legacy applications by integration patterns like
EAI or individual adapters.
User interfaces (UI): There are UI components for input and output of
information needed by human centric activities. Ideally, they can be
accessed as UI services in the underlying SOA and integrated in the
enterprise portal. Often, the BPMS product brings along its own proprietary
mechanism, e.g. UI forms.
Master data management (MDM): The different domain specific data are well
defined and may be integrated to a holistic master data model. This is very
important whenever two self-reliant systems have to be integrated by the
BPMS solution. With growing complexity, the introduction of a MDM
system will be necessary.
Transaction management: There are mechanisms for transaction handling like
distributed transaction processing (DTP) or two-phase commit (2PC). More
often than not, existing systems lack transaction management support. This
means that alternative solutions or workarounds must be found. In large
service oriented environments compensation has proved to be a practical
solution.
If some of these requisites are not given, the project must realise them on its own.
This can range from designing UI forms in the BPMS itself over configuring
service adapters to initiating sub-projects for the implementation of new technical
or business system components. Once the effort is invested, flexibility is given to
make functional changes fast and cheap.
127
Pattern 103: Draft run
Individual draft runs of processes and rules after creation or update are helpful to find logical
and technical faults in early phases.
A wide range of BPMS products allow the execution of processes or rules before
the environment is completely available and the enrichment of the models has
been finished. This is very helpful in many ways. First, the business units can
approve the correctness of the model very soon. So, change requests arise early
reducing the effort to implement them. Second, additional components can be
developed in a more independent way. And last but not least, it is possible to
detect errors as soon as possible. Moreover, many BPMS tools even support
periodical execution of unit tests.
8.5
Impact on Software Configuration Management
In the context of the evolutional methodology and business process management,
a sound software configuration management is just as crucial for successful
projects as it is in the area of the sequential methodology. Moreover, the particular
patterns described in chapter 6 with respect to the basic and sequential approaches
are equally valid for evolutional software development, too. However, some new
challenges arise in the context of BPM (see [20]) that are addressed by the
following patterns.
Pattern 104: Versioning strategy
Establish a holistic strategy for versioning all relevant artefacts including a reliable mechanism
to keep them in sync. This also includes the whole relevant system environment.
Products like the BPMS have central roles in the resulting system architecture.
Thereby, process models and business rules are important artefacts for
development and execution. As a result functional changes are performed directly
inside the BPMS that brings its own versioning rather than in externally managed
source code. Hence, it gets difficult to maintain a unique versioning along the
complete system and keep everything in sync. If branches are needed or seamless
collaboration must be supported the situation becomes even more complicated. In
every case, there must be a clear strategy of how to establish an all-embracing
version management.
128
Quasar 3.0
Pattern 105: Use staging
Establish a staging process for developing, testing, and deploying new features. Thereby, the
environments must cover the complete architecture stack including processes, rules, services,
and even external components (e.g. cloud services).
Albeit it seems very easy to incorporate modifications directly into the running
system, changes must be tested before they are deployed for productive use. This
is valid for the evolutional methodology as well. As described in pattern 63, there
are different environments for development, testing, approval, and production
(DTAP) (see figure 8.3). Releases or versions of the product need to be staged
after successful test from one environment to another. This staging process has to
be implemented technically as well as organisational considering governance
aspects.
Figure 8.3: DTAP Environments in BPM Projects
Typically the BPMS is embedded into a complex system landscape consisting of
services, user interfaces, enterprise portals, and underlying data. So, each
environment should rather contain all components that are part of the complete
solution. This even involves cloud services.
Pattern 106: Service versioning
Be aware of software updates in the face of long lasting processes. Include versioning
information in service interfaces as prevention.
129
Typically business processes involve human interactions and therefore last a
longer period of time (especially if human interaction includes external
communication). By all means, processes can take several weeks or month until
completion. Now assume some change requires the modification of service
interfaces. In this case, it is not sufficient to change these service interfaces
together with the service invocations in the process models because there may be
process instances that have been started beforehand. So, they are running
according to the previous model using the old service definitions and expecting
the former behaviour.
In general, a service interface should be designed in a very stable way. However,
it is impossible to prevent changes at all. To remedy these problems, version
information should be added to the endpoint addresses of all services. This allows
providing current and previous versions simultaneously.
8.6
Impact on Analytics
Customers expect software solutions to be delivered at best quality. Therefore, it
must be kept in mind during development. This also holds true for evolutional
methodologies.
Pattern 107: Comprehensive unit testing
Unit tests should be executed for business rules, processes, and services. Additionally,
integration tests must be carried out periodically.
As mentioned above, it is possible to draft run business processes and rules in
many BPMS products . This feature can easily be used to introduce unit testing
for the individual models. It helps to detect errors in good time. Draft runs can
also be used to determine performance information like throughput or waiting
times. Some BPMS products even support the simulation of several functional or
technical aspects. This can be very helpful, to ensure compliance with critical
customer demands.
Pattern 108: Static model analysis
Use static analysis for measurement of your processes (BPMN-Q), rules, and services. At
least, perform regular model review sessions.
Additionally, it makes sense, to establish measurement to control and improve the
quality of the upcoming system. For programming languages like Java established
metrics and tools (checkstyle, findbugs, sonar, etc.) are available. Measuring the
quality of process models or business rules is currently rather challenging.
BPMN-Q (see for example [2]) is the first step towards this direction.
130
Quasar 3.0
Nevertheless, there is hardly a mechanism supported by any BPMS vendor. There
remains the possibility to perform manual model reviews for quality estimations.
It has to be mentioned that testing as well as measurement must take place on a
regular basis. Observing the trend of indicators is crucial for reacting fast on
problems and eventually achieving high quality results.
8.7
Impact on Operations and Monitoring
The main difference to the sequential methodology consists in the fact that most
BPMS products bring along some kind of monitoring and reporting. So, it can
simply be used and it is not necessary to develop it separately as part of the
solution. Sometimes, the indicators are hard coded and predefined. Commercial
BPMS tools normally can be extended and adapted to the actual needs in an easy
way.
Pattern 109: Operational prior to analytical
Pay attention to the effects of monitoring and reporting on the operative system performance.
In the case of very complex formulas, the indicator computation may lead to
significant load of either the server or the database. Then, it is advisable to use
concepts like mirror databases and redundant server instances to prevent the
operative system from being slowed or locked by concurrent monitoring or
reporting request. The most comprehensive solution is transferring all analytical
tasks into some kind of data warehouse system.
Monitoring processes using these mechanisms is very valuable, particularly since
it is available as part of the tool. It helps to detect processes that are overdue or
problems during the execution of liable services. Further, it gives an economical
basis to plan where to invest in further automation and where not. Based on this
information it is possible to relieve critical situations as early as possible.
Pattern 110: Define KPIs
KPIs are important for both technical and business aspects. They must be regarded and
developed as a part of the solution.
There are a couple of measured values that are important for the operative courses
of business.
Time: Such indicators should cover all aspects with respect to the throughput of
running processes like process duration, waiting times, number of parallel
process instances, and so on.
131
Quality: It is no advantage to run a lot of processes with high performance, if the
results of the processes are poor. Therefore, quality indicators like success
rate or explicit user feedback is of importance for BAM.
Model: This kind of indicators cope with aspects concerning the models itself.
For example, the invocation percentage of the individual activities gives
information of how to further optimize the process models.
Business: All business aspects like costs or efforts can be captured and reported
as KPIs, too.
The main indicators for the performance of an enterprise are called key
performance indicators (KPI). These are typically unique for a company.
Advanced tools providing BAM functionality allow defining these KPIs apart
from the predefined ones. Further it is important to distinguish two types of KPIs:
Reporting KPIs give a good view on the overall performance (e.g. gross
operating profit (GOP)). However poor values only indicate that something
is wrong and not the action required. These KPIs are reported per month,
quarter, or (half) year.
Operational KPIs are less aggregated and indicate what action is required in
case of a poor value (e.g. "product delivered overdue"). Such KPIs should
be reported frequently (e.g. on daily basis).
Pattern 111: Continuous improvement
Establish continuous improvement of your processes. As a rule, some common methodology
like the continuous improvement process (CIP), LEAN, or Six Sigma should be used.
Whenever an indicator reveals that the process should be improved by some kind
of measure this change should be analysed, implemented in the test environment,
approved, and finally deployed for production use. By monitoring and reporting
the KPI after deployment, it is possible to rate the implications of this change.
This leads to a continuous loop called BPM cycle (see figure 8.4).
8.8
Impact on Project Management
With respect to the project management approach, there is no common strategy in
combination with the evolutional methodology. Nevertheless, there are some
general aspects that arise in the context of business process management.
Pattern 112: BPM is agile
Manage BPM projects in an iterative or agile way. This allows the project to implement the BPM
cycle for continuous process optimization.
132
Quasar 3.0
Figure 8.4: BPM Cycle
Implied by the BPM cycle and because the model implementation is evolutionary,
the management of this kind of projects should be oriented towards iterative or
even agile approaches. This means to take smaller steps within shorter
time-frames. Such an approach becomes possible due to the flexibility gained with
BPM and BRM. The benefit is that you get early feedback and market delivery is
quicker. Driven by the BPM cycle using BAM, experiences from preceding
iterations will have direct influence to succeeding implementation scopes.
133
134
Quasar 3.0
9
9.1
The Enterprise Domain
The Term Enterprise Architecture
In IT, according to ISO/IEC 42010:2007, architecture is "the fundamental
organization of a system, embodied in its components, their relationship to each
other, the environment, and the principles governing its design and evolution"
(cited from [27]).
Referring to this comprehensive definition, people use different terms for different
types of architecture. Enterprise architecture, solutions architecture and even
Security or governance architecture as well as the more usual technical,
applications or business architecture are used in the similar manner.
In relation to the Quasar "Enterprise Domain", the system referred to here is the
"enterprise". According to TOGAF9, we consider Enterprise as a set of
organizational units with common goals. Thus, an enterprise may be a public
agency, a subsidiary of an international corporation or even a network of entirely
independent companies working together in supply chain.
Figure 9.1 illustrates how Capgemini relates these types of architecture to one
another, demonstrating the inclusion of Business Architecture within a full
Enterprise Architecture, as well as the need for Solution Architecture to span from
business to technology
Figure 9.1: Types of Architecture
135
Chapter 9. The Enterprise Domain
Enterprise architecture – like the IT of a company and all the operating functions
– is subject to the economic principle. By this principle, enterprise architecture
has to achieve provable benefits with respect to the goals of the enterprise that
exceeds the cost of these functions. Therefore, the organization of IT structures in
an enterprise follows a request triggered by some business cause. Below are some
examples of such causes triggering a change of the enterprise architecture:
Changes in the business strategy
Functional expansion or change of business areas
Merger or acquisition and divestitures or buy-outs
Changes in collaboration with the other companies
Utilizing new technology trends
Consolidating, simplifying and standardizing the application landscape
IT cost reduction
Enterprise architecture is never a means in itself or even generally accepted as
self-evident. Rather it has to continuously demonstrate its benefits for the
company. This does not prevent continuous improvement of the enterprise
architecture based on given business objectives.
Generally, it is the task of the enterprise architecture to organise the IT structure
of the company in such a way that the IT optimally supports the strategy and the
business goals of the enterprise.
9.2
The Quasar Enterprise® Method
Quasar Enterprise® is a comprehensive method, based on experience of many
years and projects for structuring the application landscape within the scope of
enterprise architecture. It is an approach and a roadmap based on the Integrated
Architecture Framework (IAF) Capgemini’s content framework for architecture.
Quasar Enterprise comprises proven procedures, methods and rules to create
artefacts and deliverables that describe the architecture of an enterprise as implied
by IAF as a content framework.
IAF distinguishes four architecture aspects (see [9]):
Business Architecture refers to business goals, business activities, and roles &
resources. Its outcome are models around process, organization, people and
resources.
Information Architecture deals with information structures and relationships. It
describes and defines what and how information is used and how it flows
around in the business.
Information System Architecture describes packaged or bespoke information
systems that will automate and support the processing of the information
used by the business.
136
Quasar 3.0
Technology Infrastructure Architecture describes the technology
infrastructure required to support the information systems architecture.
Additionally, IAF sees different abstraction levels for each architecture aspect (see
[9]):
The Contextual Level is about understanding the question "WHY" there is a
need for a new architecture and the context of the architecture. In the IAF,
the Contextual Level is about understanding WHY the architecture is
required, why the boundaries are set for the new architecture, the current
business and technology contexts (including the eco-system that the
organization relates to), understanding who the key stakeholders are, the
business objectives, success criteria, in short a set of information that will
provide the context for the architecture development.
The Conceptual Level is characterized by the "WHAT?" statement. It is about
answering the question "WHAT is needed to realize the business
objectives"? At the Conceptual Level, the requirements and objectives are
decomposed, ensuring all aspects of the scope are explored, issues are
identified and these issues are resolved without concern over how the
architecture will be realized.
The Logical Level is characterized by the "HOW" statement. It answers the
question "HOW can the architecture be structured and organised in an
optimal fashion to achieve the stated objectives". The Logical Level is
about setting the desired architecture state and structure in an
implementation independent manner.
The Physical Level is characterized by the "WITH WHAT" statement. It is about
determining the real world structure and is concerned with transforming the
logical level outcomes into an implementation-specific structure.
Figure 9.2 shows the relations between the different levels.
Within the Quasar Enterprise® , we see the different architecture aspects resulting
in different disciplines with their respective approaches for procedure, modelling
and evaluation. Here, we focus on the most important of them [9], [34], [12] and
[9] are referred for complete representations in the methodical approach.
The basic modelling principle of Quasar Enterprise® is the orientation to the
services as elements of modelling. At Quasar Enterprise, a service is a complete
and self-contained unit of work that is independent of the user – be it a human
being or an IT system – and is beneficial for the business.
Like TOGAF 9 and the aspects defined in IAF, different phases are defined in
Quasar Enterprise for a development plan of company architecture. They are as
follows:
137
Figure 9.2: The Integrated Architecture Framework IAF
Compiling the architecture context Architecture context includes business and
IT strategy as well as the architecture principles derived from them.
Essential for the concrete development plan for organization architecture
are the business goals that justify the change and are stated in the request
for architectural change. The architecture context is always comprehensive,
i.e. it compiles artefacts that form the basis for all the architecture aspects
like business, information and information system architecture as well as
technology infrastructure. In TOGAF 9, this phase corresponds more or
less to the Preliminary Phase and the phase "A. Architecture Vision".
Reviewing the business & information architecture Under the given business
and information architecture, Quasar Enterprise focuses on designing the
application landscape that is optimally aligned to this business and
information architecture. Thus, this phase deals with acceptance of business
and information architecture in a formal, consistent manner and covering
the development plan in the respective artefacts. The phase "B. Business
Architecture" of TOGAF 9 serves this purpose.
Modelling an ideal information system architecture Modelling the ideal
information system architecture is the core and the foundation of Quasar
Enterprise. The goal is to define the information system architecture in way
in which it can optimally support the guidelines from the architecture
context. The result consists of the logical information system components
and the information system services inside them.
138
Quasar 3.0
Information systems architecture is likewise a phase in TOGAF. TOGAF
differentiates here between application and data architecture, which IAF
and Quasar Enterprise do not, based on their service oriented approach.
TOGAF aims only at architectures that are to be implemented and thus
gives away designing a consistent ideal architecture as a model.
Assessment of the current information system architecture In order to
formulate necessary changes in the architecture corresponding to the given
request and according to set business goals, the enterprise architect must
have the necessary information about the existing, current information
system architecture and he assesses it.
Definition of the technology infrastructure The technology infrastructure
consists of all services that are not directly functionally determined but
necessary in IT to implement the information system architecture. This
applies to hardware and operating systems, and low-level software such as
databases, middleware, BPM systems, dialog controls, and much more.
Typically, "platforms" combine several components and their services, e.g.
in the form of an integration platform. Another form is the combination like
technology- stacks that are oriented to specific operating systems and
vendors. The integration architecture is a part of the technology
infrastructure. The integration architecture defines the technology
infrastructure services and their applications, which are necessary for the
coordination of different information system components. Hence, TOGAF
defines the phase "D. Technology Architecture".
Evolution – Planning and monitoring the architecture changes For planning
and monitoring the architecture development, Quasar Enterprise describes
the procedure for defining the to-be architecture that is derived from the
ideal and current architecture which is then implemented at a given point in
time. A roadmap describes the implementation of the to-be architecture
according to its dependencies and a defined schedule.
TOGAF describes these aspects in addition to modelling of to-be
architectures and migration plans in phase "E. Opportunities and
Solutions", phase " F. Migration Planning", phase "G. Implementation
Governance" and phase "H. Architecture Change Management" with
significant emphasis on architecture governance.
Figure 9.3 shows these relations.
9.3
Architecture Context
The cause, justification and approach for the actions of the architect shall be
defined across all disciplines of enterprise architecture and aligned with all
stakeholders. These are based on the business strategy, IT strategy and operating
model, reflecting market and industry trends as well as such emerging
139
Figure 9.3: The Quasar Enterprise Method and Roadmap (source: [12])
technologies and innovation in the company. This generally results in an
architecture vision and architecture principles, which guide the architecture
project and a clearly formulated within the request for the architecture project (see
figure 9.4).
Pattern 113: A statement of architecture work based on the business objectives always
precedes architecture work
Clarify the cause and the objective of the intended architectural work with respect to the
business objectives of the enterprise with all stakeholders, define and create alignment on
success criteria of the architecture work.
First understand the "Why", i.e. the business objectives to be supported, before
defining the approach to be taken or starting any architecture work.
Business objectives communicate what the enterprise wants to achieve within a
specified timeframe and set parameters and goals for all initiatives within the
organization. They identify the planned responses to business drivers, based on
taking advantage of opportunities and mitigating threats. Business objectives are
to be aligned with the overall business mission to ensure the basis for continued
business and measurement of planned change.
140
Quasar 3.0
Figure 9.4: Architecture Context
Business objectives ideally have clear goals, are measurable and achievable. They
are not necessarily totally financial but may include organizational aspects,
changes to the image or market etc.
The business objectives communicate the issues that the architecture will address
and the way the architecture will address them. The scope of the architecture
engagement has to be closely aligned to the business objectives and demonstrate
how the architecture supports their goals and measures.
Only if architects ensure that they fully understand the business objectives they
shall support, they will be able to construct solutions that are effective and worth
the effort.
A statement of architectural work not only provides direction, but identifies
stakeholders and sponsors for architecture work as well. So it not just gives the
rationale to the architect for his work, but shows the corporate consensus on this
work.
Relinquishing the statement of architecture work bears a high risk of the designed
architecture being irrelevant, which usually gives architecture a bad name and
turns out to be fatal for the architecture function.
Pattern 114: Derive and align a set of architecture principles to govern the architectural
work (see figure 9.5)
Based on business and IT strategy, business drivers and IT trends, common beliefs within the
enterprise and corporate culture, compile a set of architecture principles and detail them to
them become clear, consistent, complete and operational in the context of the intended
operational work.
141
A principle is an approach, a statement or a belief, which provides guidance. It
has to be stated unambiguously and comprehensible. The set of architecture
principles has to be mutually exclusive and collectively exhaustive. For each
principle, there is a rationale, and a prioritization with respect to other principles.
Architecture principles never state obvious or self-evident facts with respect to the
enterprise, its corporate culture and the point of view of stakeholders.
Architecture principles are derived from business requirements. Business
requirements state how a company needs to modify the actual situation to achieve
its business objectives.
Figure 9.5: Deriving Architecture Principles
9.4
The Business Architecture Discipline
Architects must understand the ways and means of how the enterprise does its
business and how this will change in future. Within the Quasar
Enterprise® approach, shaping the IT in alignment and supporting optimally the
business require a formal consistent compilation of the business architecture of
this enterprise.
The Business Architecture discipline takes contextual information referring to the
business as its input. This information includes the business drivers, the business
vision and mission, the business strategy and the operating model. In addition, the
business architecture requires the business objectives as set for the architecture
engagement and the derived architecture principles referring to the business.
142
Quasar 3.0
Output of business architecture activities are business dimensions, services and
objects. Business processes are implementations of business services and logical
components formed out of business services of a lower level. Figure 9.6 shows
these relations.
Figure 9.6: Business Architecture
Pattern 115: Identify business dimensions
Identify business features that distinguish the main business functions of the enterprise
otherwise serving the same purpose.
Business dimensions structure the business by specifying the distinctive features
of a business. Its characteristics to be regarded as relevant reflect the business
objectives of the company. Different organizational units covering the same
business function imply business dimensions.
Business dimensions are always rooted in the business strategy, especially in the
marketing strategy.
Examples of business dimensions:
Customers/brands: Different customer segments does a company address with
different brands
Products: Main product categories does a company offer
Customer channels: Channels by which the enterprise addresses its customers
and sells its products
Part of the value-add chain: Differentiation between self-produce and procured
goods
143
Pattern 116: Decompose business services
Decompose top level business functions recursively using a top-down approach until the
appropriate level of detail is achieved.
Architects need to focus on an external view of the business functions and
abstracting from internal details. Thinking in terms of services is the appropriate
paradigm for this situation. Services are managed business functions, which are
defined independently by a specific user, i.e. actor and provide an output relevant
to the business.
Following Capgemini’s IAF service concept, a service supports a clearly defined
goal, is executed by a role and consists of one or more activities. Therefore, we
get the relationship as shown in figure 9.7.
Figure 9.7: Business Service
The architect takes a top down approach on the business service decomposition
not to understand the business, but in order to limit the analysis to the required
extent. Starting point is the overall top level business services of the enterprise as
given by the business mission or reflected in the overall value chain. At each level
the architect details those services relevant to the business objectives and business
requirements of her or his engagement, i.e. the scope of the architecture
engagement (see figure 9.8).
There are two ways of refinement: On the one hand, this can be done along with
the business dimensions. On the other hand, the architect may consider a business
service as a logical business process component consisting of business services of
a lower level.
144
Quasar 3.0
Figure 9.8: Decomposing Business Services
Pattern 117: Identify major business objects
In reflecting the input and output of business services, identify major business objects as the
essential entities a business service is transforming.
Business objects are the real thing. Business services use and consume i.e. create,
transform and eliminate business objects. Different business services will use and
consume business objects in different ways. Generally business objects are
identified as input and output of business services.
Business objects may be or infer information objects. It may be architecturally
significant to understand these differences when structuring the architecture
components. So a business object is a non human resource used by the business
that is significant to the architecture.
9.5
The Information Architecture Discipline
For shaping the application landscape, the architect needs to know about
information flows and responsibilities for consistency, completeness and
correctness of information. The information architecture describes the information
on business uses, the information structure and relationships (see figure 9.9).
The contextual information, in the form of information architecture principles,
determines the information architecture. There is a close relationship between
information architecture and business architecture: For example, business services
145
Figure 9.9: Information Architecture
not just handle business objects, but they may add information as they transform
business objects into a certain state. On the other hand, information objects reflect
changes in the respective business objects (see figure 9.10).
Beware: Information is related to the business, it is not referring to data, which is
information handled by information systems.
Figure 9.10: Business Service and Information Services
146
Quasar 3.0
The outcome from the information architecture is typically a series of business
information components that describe what and how information is used, flows
around the business and stewardship on certain information.
Pattern 118: Determine information flows
Identify flows of information going from source to final destination
Information flows describe the use and communication of information. They are
about communication of information through the business irrespective of how that
is achieved. They usually go parallel with business services.
Analysis of information flows is useful in identifying issues on automation. For
example this analysis may reveal areas where there is significant
automated/manual change and areas potential for miscommunication. This will
provide a basis for analysis and optimization in the information systems support.
There is often confusion about the need for information flows, when they match
business processes very closely. This is very common when the business
objectives include the derivation of information system aspects of the architecture.
When a process is the starting point for analysis, the process gets analysed for the
information aspects of the activities of the process. The results in entities, which
are in effect parts of the information flow. Remember, that information flows
focus on information and not activities.
Pattern 119: Determine information flows
Identify information objects which contain the information on major business objects according
to their state. Assign the stewardship, i.e. the responsibility on consistency, correctness and
completeness, of those information objects
An information object is a source of information and subject of communication
for business services, independent of the media used. It describes the information
that is used or communicated within information flows.
Information objects are characterized by statements of the form "a blah is a blur
that bleeps", e.g. "an order is the request of a customer to supply an article".
Defining information objects in this way creates an ontology, that is the basis for
communication between business and IT.
It is crucial for the architecture to analyse and define the responsibility for the
correctness, consistency and completeness of information as reflected within
information objects.
147
9.6
The Information System Architecture Discipline
The Information System Architecture discipline is about analyzing and modelling
IT application landscapes (see figure 9.11).
Figure 9.11: Information System Architecture
The Information System Architecture discipline is based on the architecture
context and the outcomes of the business architecture and information architecture
analysis. In addition, the design of an IT landscape requires information on the
current IT landscape and the current project portfolio.
The Information System Architecture defines two set methods:
IT landscape assessment Based on the set business objectives and ensuing
requirements, the architect defines key indicators for IT applications and for
the IT application landscape as a whole. This way he can identify areas
with need for action and evaluate the effect of architectural changes and
measures. In applying this method for the current existing landscape as well
as for future target landscapes and even for ideal landscapes, the architect
shows the way he fulfils the business objectives and justifies the modelled
information system architecture.
IT landscape modelling Based on the architecture context, the outcome of
business and information architecture, and the current information system
architecture, the architect designs future information system architectures.
The outcome is information system services and components formed out of
these services, i.e. the model of an IT application landscape. To show a way
to implement a certain IT application landscape, the architect defines
architectural measures and transitional architectures which result in a
transformational roadmap.
148
Quasar 3.0
Pattern 120: Define the ideal information system architecture as a strategic target
The ideal landscape fulfils all present requirements and aligned with business and IT strategy. It
serves as a beacon for the architecture implementation governance, planning and work.
Architecture work needs endurance, persistence and tenacity. To avoid getting lost
in detail, urgent fire fighting and short term change, the architect needs a beacon
which leads his work. This is the purpose of designing an ideal information
system architecture, which exemplary fulfils the business requirements and is
aligned with both, business and IT strategy.
Though this ideal information system architecture can be realized in principle, it
will probably never get reality. The ideal information system architecture neither
takes the current information system architecture nor limitations by time, effort
and financial constraints into account. There is a reason to design an ideal
information system architecture instead of just go for a target architecture. In this
way, the architect can more easily identify and prioritize areas of change
according to their contribution to the business objectives by comparing the ideal
with the "as-is" information system architecture. The ideal information system
architecture provides the whole picture.
Pattern 121: Define the "To-Be" Information System Architecture as a state of the
information system architecture planned for and achievable at a certain point in time
Compile measures and a roadmap to achieve a state of the information system architecture
according to the "managed evolution" approach.
Based on the ideal and the current information system architecture, and
subsequently identified and prioritised areas of need for action, the architect
defines the "to-be" information system architecture to be achieved measure by
measure at a certain point in time. These measures form the architecture roadmap.
It is crucial, that this roadmap provides an approach balanced between realizing
short term business opportunities and following long term IT strategy goals. We
call this approach "managed evolution", which is shown in figure 9.12.
Pattern 122: Assess current, ideal and future Information System Architecture according
to the alignment with and the contribution to the business objectives
Assess an information system architecture by criteria which are derived from the business
objectives as they were stated in the architecture statement of work
Due to the complexity of an IT application landscape, an architect can collect a lot
of data which may lead to unnecessary efforts and bears the risk of getting lost in
detail. Therefore, the collection of data has to be focused.
149
Figure 9.12: The managed evolution of an IT landscape
The data to be collected refers to key indicators about the state of the application
landscape. As business objectives and requirements are defined measurable, the
key indicators should be defined up front and reflect these business objectives and
requirements.
For example, if the enterprise gives cost reduction of certain business transactions
as a business objective, the architect has to compile the cost of a (partial)
transaction within each involved IT application. Starting point for this will be the
overall run costs for an application and the number of transactions processed in a
certain time frame.
Usually, there are four main aspects for assessment of an IT application landscape.
Degree of standardization: Diversity will lead to high operating costs.
Therefore, the IT landscape should be as standardized as possible, i.e. using
as few technology stacks and platforms types of software packages etc.
Degree of complexity: Complexity will lead to increased project costs and an
increase in the number of errors. Complexity is decreased by reducing the
number of IT applications and the number of interfaces between them.
Degree of dependency: Tight coupling between systems leads to high
dependence between them. This results in extra cost when changing,
replacing or outsourcing systems. In addition, having loosely coupled
applications will result in higher availability.
150
Quasar 3.0
Total Cost: Every architecture change needs a business case, even "strategic"
measures have to provide financial value in the long run. The architect has
to reflect run costs as well as cost for future change, and has to take the net
present value of IT applications as assets into account.
Pattern 123: Define a domain model to bridge business and IT
Use a domain model as a structuring concept to link business architecture and information
system architecture artefacts (see figure 9.13)
Many companies still lack a link between business and IT. A domain model fills
this gap. It describes services in both the domain model and the IT applications
that automate these services, resulting in a common model that both business and
IT understand.
Domains in the context of the Quasar Enterprise methodology are abstract
structural elements which describe areas of the information system architecture,
where certain common approaches, principles, rules and points of view apply. In
this way, domains structure the IT application landscape by business aspects.
Figure 9.13: Create Domain Model
To design a domain model, identify appropriate domain candidates. Top level core
and supporting business services as well as major information objects are
candidates. Domain candidates derived from core business services may have to
be detailed by business dimensions. These candidates have to be further detailed
or merged according to the business point of view. This way the domain
151
candidates are finalized. The value of the domain model results from mapping
existing IT applications and information system services to the domains. The
methodology employs many domain specific reference models. Use them to
define the ideal and the "to-be" architecture There are many domain-specific
reference models available today which are derived from project experience.
For the Financial Service Provider, Logistic Service Provider, Insurance and
Automotive Production etc., industry domains, the reference models, help to
structure the business area and reduce the risk involved in modelling the
architectures.
Pattern 124: Derive Information System services from business services of the
appropriate granularity
An information system service will be the automated part of a business service really
implemented by means of the IT
The architect categorizes business and information services from the business and
information architecture according to their need for automation and the
enterprise’s ability to automate these services.
Figure 9.14: Business Services and Information System Services
Within the scope of the architecture engagement, i.e. within identified areas with
need for action and according to the business requirements, the architect decides
on the appropriate part of business services at the right degree of granularity to
ideally become information system services. These information system services
are the elements for modelling the information system architecture.
152
Quasar 3.0
Beware of the fact that by this approach, there is no hierarchy of information
system services, though one information system service may call another one.
To start modelling, these services are mapped to the right domain and are
categorized into:
Interaction services: Services which provide interaction on information mostly
with a human user, but also with other systems outside of the enterprise
Process services: These services provide consecutive calls to other services
Functional services: These services implement some kind of a more or less
complicated algorithm
Data portfolio services: Create, read, update and delete services on certain data
Pattern 125: Model logical Information System components by domain and service
category
A logical information system component is created by the grouping of one or more information
system services based on the mapping of those services to domains and category.
The logical information system components represent the "application"
components for a given solution alternative. They describe the implementation
independent solution for Information systems in terms of the ideal state.
We start with the modelling with all information system services in scope being
assigned to a domain and a category. One component candidate each is created for
the information system services of a domain and of a category. The component
candidates are formed according to functional criteria and refined in accordance
with the rules for the component design. Components should be designed such
that they have tight cohesion internally and have a low degree of coupling with
each other.
The physical information system components of the actual application landscape
are used to check the component candidates for completeness. The candidate
components are adapted where necessary. Then, they are given names that are
understood and accepted by those involved. They form the final components.
Logical information system components of different categories should only have
couplings in accordance with the reference architecture of the categorised
application landscape. The couplings between all components should form an
aligned acyclic graph. Logical information system components with services of
the category "data portfolio" represent data stewardship over the information
objects.
153
Figure 9.15: Logical Information System Components
9.7
The Technology Infrastructure Discipline
When managing the evolution of IT landscapes, architects need to decide how to
physically connect applications and where and how to use integration
infrastructures.
The Technology Infrastructure discipline focuses on the integration infrastructure
of an IT landscape. It describes best practices for how to physically connect
applications. It also offers a method for deciding on an integration infrastructure.
The Technology Infrastructure discipline uses the clients’ information about the
IT strategy and the existing technology infrastructure as one of its inputs.
Additionally, the "to-be" IT landscape is needed as input information for
modelling the IT infrastructure. The discipline will produce logical and physical
information on the technical infrastructure for integration purposes.
Pattern 126: Standardize the technical integration services
Use reference models for integration to structure and analyse the integration tasks.
If applications are physically connected there will be a set of technical integration
tasks that recur in many contexts. Technical transformation, functional
transformation and addressing the correct application are only some examples. In
154
Quasar 3.0
Figure 9.16: Technology Infrastructure Architecture
many IT landscapes, these recurring tasks are implemented redundantly in almost
every application.
When managing the evolution of an IT landscape, an architect needs to reduce the
redundancies by standardizing and even physically centralizing these technical
integration services.
Technology Infrastructure provides a reference model for integration and maps
this reference model onto the capabilities of different integration platforms. Using
this, an architect can easily structure the integration services needed by the
applications, and can easily map these services to existing integration
infrastructures.
Pattern 127: Take the two-step integration approach
Disentangle the interfaces first, take advantage of the implementation of integration
infrastructures second.
Integration infrastructures help to centralize technology infrastructure services.
However, introducing an integration infrastructure is usually expensive, and
business cases are rare. Therefore, architects prepare as many applications as
possible beforehand for the introduction of a standardized integration
infrastructure. In this way they can reduce investment risks and make the benefits
of Technology Infrastructure offers more visible.
Pattern 128: Patterns for integration make for robust physical integration
Use tried and tested patterns for integration to achieve at the best integration scenario in a
given context.
155
When architects design the physical integration of applications, they have to
balance many non-functional requirements that are often poorly compatible. For
example, an interface may be required to have high performance and
simultaneously be subjected to detailed monitoring. Addressing such
requirements is often a time-consuming and error-prone task.
Technology Infrastructure will provide recurring sets of non-functional
requirements and their corresponding solutions in what we call "patterns for
integration". Patterns for integration provide architects with tested
problem/solution pairs, which reduce the time required when seeking the solution
to a given problem and also lower the error rate. Figure 9.17 illustrates a solution
for combining custom software with software packages in a service-oriented way.
Figure 9.17: Solution pattern for the service oriented integration of custom developed
software with standard software packages
156
Quasar 3.0
A
A.1
Situational Software
Engineering: a Systematic
Approach
Introduction
In order to become a successful IT-supplier in the market, a situation-specific
combination of software development process model and methodical elements
have to be found that particularly guarantee high economy of software
development in each individual software development project. Hereby, the
following three factors affecting economy are in conflict (see figure A.1)
Effectiveness the correct activities are done (i.e. those are not performed
unnecessarily)
Efficiency the activities are carried out in the proper way without wasting any
resources
Economics of price Resources are used in such a way that the product of unit
cost prices and expenditure is as less as possible (i.e. it might be worth to
use even more expensive tool if thereby the expenditure for human
activities can be decreased)
Since no optimisation is possible at the same time with respect to all three factors,
it has to be guaranteed with each project that the balance between them is
purposefully achieved. An example for this is the architectural development. A
good architecture is mandatory, since it causes a lesser implementation effort, but
on the other hand it comes along with additional effort for its development. At the
same time typically the last minor optimisations do not bring large savings. Thus,
the balance must be found here between effectiveness and efficiency.
No software development process model and no methodology are automatically
suitable for each project situation. That means for the respective project situation
the ideal combination of process model and methodical building blocks has to be
selected. This observation lead already to the research theme of Situational
Method Engineering (see [35]) within the area of method engineering. Also in the
V-model XT (extreme Tailoring), such a situational adaption is already embodied
in the name. Here, tailoring means to select one of three pre-defined project types
to determine the methodical building blocks for a current project situation.
Recently, agile software development approaches became more popular in
industrial software development. B. Boehm and R. Turner ([3]) investigated the
differences and advantages between classical plan-driven and modern agile
157
Appendix A. Appendix: Situational Software Engineering
Figure A.1: Economics achieving the balance in Effectiveness, Efficiency and Economics
of Price
approaches. They identified a set of key factors, which are helpful, in order to
decide for one of the two approaches. These are
1.
2.
3.
4.
size of the software product and/or the team,
criticality of the software product in the employment context,
quality and experiences of the developers as well as
dynamics of requirements.
On this basis, Capgemini developed a tool for the selection of the right software
development process model (see [17]). Here, in particular the aspect of
architectural dependencies between features and system components as well as
timing aspects were added (see figure A.2). The selection tool supports the project
manager when allocating a project to a suitable software development process
model in accordance with the factors indicated in figure A.2 (agile = dark red,
plan-driven = dark-blue). In case, the project cannot be assigned clearly to a
plan-driven or agile process model (i.e. project characteristics are in the light blue
and/or light red range), the tool recommends a combination, whereby the possible
risks are indicated to the project manager (for details s. [17]).
Experiences with the selection tool show that project managers make now a more
conscious decision for the selection of a software development process model. At
the same time, experiences while using the selection tool show that project
managers have to be supported with the decision, which methodical building
blocks are to be used in which situation. Thus, an extension of the selection tool is
158
Quasar 3.0
Figure A.2: Key success factors in the selection method within Capgemini
required. In this chapter we present, what is the structure of required framework
for this enhanced selection tool.
This interaction between efficiency, effectiveness and economics of price reflects
itself in the new title eee@Quasar for the situational development method
(Quasar 3.0) of Capgemini. It has already been discussed within the scientific
community (s. [14]) and our customers within the “Kundenforum Architecture” in
2010. So here we present the updated version of this concept where all the
valuable hints have been integrated. In parallel this concept of situational
engineering for methodology has been integrated into the TechnoVision ([8]).
A.2
The framework
Our framework consists in two different streams. The first one is the development
of the actual framework, the second a methodology for the identification of the
right method bundle and process model for a concrete project. Figure A.3 gives an
overview over the framework.
159
Figure A.3: Our methodology to find the right correlation between a project and a methodology and process model
A.2.1
Development of the framework
The first step is to identify the methodical building blocks to be taken into account
as well the development process model types. The second is to find a
characterization of the methodical elements, project model and system types that
allow to look at the resulting activities and related artefacts not only from a
development point of view but as well from the later operations and maintenance.
One characteristic in this sense is the lifetime with the two possible extreme
instantiations:
no maintenance phase with new business requirements (example: online
game especially produced for a soccer championship)
very long maintenance phase with few changing business requirements
occurring (example: accounting system with standardized transactions)
Some methodical building blocks will support maintenance later and some will
not. In parallel, we identify the different characteristics of systems to be
considered. For sure there has to be a close interaction between these two steps.
On this basis we build groups both on the methodology side and on the system
side. The last step for building the methodical framework is to find the
correlations between methodical building blocks, software development process
models as well as system types. At least at this point the Quasar 3.0 methodology
and the system characterisations in chapter 2 are to be interpreted as a concrete
160
Quasar 3.0
example. For other environments, there are other possible methodologies as well
as other system characterisations.
On this basis, it can be decided for each project, in which class of project it falls
and therefore, which combination of process model and methodical elements is
suitable.
We will describe the steps in more details as follows. The concrete elaboration
within Quasar 3.0 is described in chapter 2.
Step1: Identification of the relevant elements
The first thing is to identify the types of projects taken into account. This step
seems at the first glance to be quite superfluous but it helps to get the right focus
and to prevent from finding the most generalised solution where the effort for the
methodology support is unacceptable.
Software development methodology is not to be developed in a green field
approach. In this area there are already a lot of existing methodical elements,
tools etc. Therefore, the next step is to identify which activities at all are to be
taken into account, which methodical elements can be used, and what are the
appropriate process models. In this step, it is helpful to use a (standardised)
approach for structuring the elements both of the methodology and of the process
model and to define a way to document the interaction between these elements.
These steps are closely related because we get another set of methodical building
blocks if we look at maintenance or initial build projects. Independent of this it is
quite easy to add more methodical elements or process models without the need
of restructuring the framework completely. Adding new types of projects is from
another quality and might have much more impact as it determines the next steps
strongly.
In our approach, each activity takes input artefacts and processes these under the
usage of methods, tools, utilities, components and patterns into output artefacts
(see figure A.4).
A method hereby is an established practise for fulfilling a given activity. Tools are
instruments for activity execution. They themselves are built of software but
typically do not become part of the solution. The last aspect holds also for utilities
but they are more auxiliary elements and do not need to be built in software.
Typical utilities in this sense are check lists, templates etc. Components are
prefabricates (not necessary software, but typically) that become part of the
solution. Here, we do not distinguish components and frameworks because this
differentiation does not help in this context. So we summarise both under the
component.
161
Figure A.4: Artefacts are input and output to activities
Example: The activity Write Specification takes the requirements and
uses our specification method and the Enterprise Architect as a tool to
provide at last the finalised specification.
For each activity there may be more than one method or tool and, in distinction
from Quasar 2.0, there can be different input and output artefacts depending on
the concrete method.
The activities are part of the disciplines which themselves are part of the domains.
Both domains and disciplines are structuring elements. If we use the terms
super-domain or sub-domain in this books, this should indicate relations between
domains, but in every case we are talking about domains.
The correlation between engineering model and software development process
models is reflected by the activities being also part of the software development
process model concept. The software development process model controls the
flow of activities. These two models are completed by the organisation and
foundation model (s. figure A.6).
To understand the dependencies better and interactions between the various
disciplines, see figure A.5. This presents the major output artefacts comprising the
links between the disciplines for the basic approach.
162
Quasar 3.0
Figure A.5: Artefact flow
163
The artefact flow shows different characteristics:
Constructive flow means that output artefacts from one discipline are used
in a constructive way by the next discipline and are further developed.
Analytical flow means that output artefacts from one discipline are used for
analytical purposes in the following discipline. They are required to derive
information about the software quality or its status.
Document flow means that output artefacts from one discipline are mainly
used for documentation purposes in the following discipline. The artefacts
are not involved further, but are needed as information input for the system
documentation.
With figure A.6 on page 165 it is quite clear, that the artefact flow does not need to
be all the same in every software development process model.
Step 2: Identification of the relevant characteristics
The step is vital for the whole framework and determines the whole structure of
the result and it may end in the need of additional methodical building blocks or
process models.
It is helpful for the definition of the characteristics to look first at the systems and
at the question where they differ. This could be as well
life cycle aspects of the products to be developed (software systems etc.)
because this strongly determines the needs for documentation etc. or
domain specific aspects because for example automotive applications may
need another handling as those for aviation.
Each methodical building block can be associated with one or more situational
aspects it is suited for. Situational aspects may be offshore, industrialised etc.
We create methodologies from these methodical building blocks under different
aspects. These methodologies can be brought into a structure themselves where
one can inherit from another. So it is advisable to have a basic methodology that
contains all elements that can be used in any situation as well as a methodology
for very special situations. For example we have a methodology that is well suited
for offshore development projects (our OCSD methodology). Figure A.6 shows
the complete interrelationships.
Step 3: Definition of clusters
On the basis of the above characteristics we build clusters on the methodology
side as well as on the system and process model side. Again the sub-steps are to
be taken in close interaction because the results must produce a common
164
Quasar 3.0
Figure A.6: The Metamodel of Quasar 3.0: The Ontology
understanding. Otherwise the next step will not be possible. In any case it is
helpful to have not too much different types because again the maintenance cost
for the framework will explode and probably the communication to the involved
colleagues will not work. Therefore, simple pictures will help more than a very
much elaborated concept.
Step 4: Matching system types to methodical building blocks and process
models
In this step, a matrix is build up that allows the correlation of system types,
methodologies and process models. Typically the mapping will not be mutually
exclusive as one method may help for more than one system type.
It is quite clear that the definition of the framework is nothing really static. It has
to be revised carefully if major changes in the assumptions (about methodology,
process models and systems criteria) occur. On the other hand this makes clear
that the framework must not be too elaborated to guarantee a reasonable kind of
sustainability.
165
A.2.2
Usage of the Framework
After defining the framework we can define a selection method that helps to find
the right elements for each project. Analogous to the above described first version
of a process model selection tool, also here it is taken into account that a current
system may not fulfil all characteristics of pre-defined system types.
Step 5: Choice of the project type
Based on the defined characteristics for a system of determination, the system type
results in aspects directly, in which the concrete project does not fit. Therefore, it
seems to be helpful to define one major system type for the system and to make
the deviations explicitly, so the whole project team can stick to this understanding.
Step 6: Choice of the methodology and process model
In the last step, the complete set of methodical building blocks and software
development process model is defined. Hereby it has to be ensured that the
necessary measures for risk reduction are taken in case the system to be built is
different from the standard.
166
Quasar 3.0
Bibliography
[1] APM Group Ltd. ITIL homepage. URL: http://www.itil-officialsite.com/
[cited December 2011].
[2] Ahmed Awad, Gero Decker, and Mathias Weske. Efficient compliance
checking using BPMN-Q and temporal logic. In Proceedings of the 6th
International Conference on Business Process Management, BPM ’08,
pages 326–341, Berlin, Heidelberg, 2008. Springer-Verlag.
[3] B. Boehm and R. Turner. Balancing Agility and Discipline: A Guide for the
Perplexed. Addison-Wesley Longman Publishing Co., Inc. Boston, MA,
USA, 2003.
[4] S. Brinkkemper. Method engineering: engineering of information systems
development methods and tools. In Information and Software Technology 38
(4), pages 275–280, 1996.
[5] Capgemini. Architecture and the Integrated Architecture Framework.
Capgemini, 2006. URL: http://www.capgemini.com/insights-andresources/by-publication/enterprise_business_and_it_architecture_and
_the_integrated_architecture_framework/ [cited December 2011].
[6] Capgemini. Architecture Guide. Capgemini, internal, 2010.
[7] Capgemini. The Engagement Manager’s Handbook. Capgemini, internal,
2011.
[8] Capgemini. From Train to Scouter. Capgemini, 2011. URL:
http://www.capgemini.com/technovision [cited December 2011].
[9] Capgemini Global Architects Community. Integrated Architecture
Framework Version 4.5 Reference Manual. Capgemini, 2009. URL:
http://www.capgemini.com/insights-and-resources/bypublication/enterprise_business_and_it_architecture_and
_the_integrated_architecture_framework/ [cited December 2011].
[10] Philip B. Crosby. Quality is free. McGraw-Hill Book Company, New York,
1979.
[11] Tobias Demandt. Evaluierung von Test First und Test Driven Development
für den Einsatz in Capgemini sd&m Projekten (Bachelor Thesis).
Technische Universität München, München, August 2008.
[12] G. Engels, A. Hess, B. Humm, O. Juwig, M. Lohmann, J.-P. Richter,
M. Voß, and J. Willkomm. Quasar Enterprise. dpunkt. verlag, Heidelberg,
Germany, 2008.
167
Bibliography
[13] G. Engels, A. Hofmann, and et al. Quasar 2.0: Software Engineering
Patterns. Capgemini sdm AG, internal, Munich, Germany, 2009.
[14] G. Engels and M. Kremer. Situational Software Engineering: Ein
Rahmenwerk für eine situationsgerechte Auswahl von
Entwicklungsmethoden und Vorgehensmodellen. In H.-U. Heiß, P. Pepper,
H. Schlinghoff, and J. Schneider, editors, Informatik 2011 – Informatik
schafft Communities, Berlin; Lecture Notes in Informatics (LNI) Proceedings Series of the Gesellschaft für Informatik, Volume P-192, page
469, Bonn, 2011. Gesellschaft für Informatik.
[15] G. Engels and St. Sauer. A meta-method for defining software engineering
methods. In G. Engels, C. Lewerentz, W. Schäfer, A. Schürr, and
B. Westfechtel, editors, Graph Transformations and Model-Driven
Engineering, LNCS 5765, pages 411–440, 2010.
[16] G. Engels, St. Sauer, and Chr. Soltenborn. Unternehmensweit verstehen unternehmensweit entwickeln: Von der Modellierungssprache zur
Softwareentwicklungsmethode. Informatik-Spektrum, 31(5), pages
451–459, 2008.
[17] M. Heinemann and G. Engels. Auswahl projektspezifischer
Vorgehensstrategien. In O. Linssen, T. Greb, M. Kuhrmann, D. Lange, and
R. Höhn, editors, Integration von Vorgehensmodellen und
Projektmanagement, pages 132–142. Shaker Verlag, 2010.
[18] Brian Henderson-Sellers and Jolita Ralyté. Situational method engineering:
State-of-the-art review. J. UCS, 16(3):424–478, 2010. URL:
http://www.jucs.org/jucs_16_3/situational_method_engineering_state.
[19] M. Hohenegger. A pattern-based approach to constructive and analytical
quality assurance of software configuration management (Master Thesis).
Technische Universität München, München, June 2011.
[20] J. Hohwiller and D. Schlegel. Software configuration management in the
context of bpm and soa. In H.-U. Heiß, P. Pepper, H. Schlinghoff, and
J. Schneider, editors, Informatik 2011 – Informatik schafft Communities;
Lecture Notes in Informatics (LNI) - Proceedings Series of the Gesellschaft
für Informatik, Volume P-192, Bonn, 2011. Gesellschaft für Informatik.
[21] J. Hohwiller, D. Schlegel, G. Grieser, and Y. Hoekstra. Integration of bpm
and brm. In Proc. 3rd International Workshop and Practitioner Day on
BPMN, Berlin, Heidelberg, 2011. Springer.
[22] IBM Corporation – Software Group. IBM™ Rational Unified Process™ ,
2007. URL: http://www-01.ibm.com/software/awdtools/rup/ [cited
December 2011].
168
Quasar 3.0
[23] I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software
Development Process. Addison-Wesley Professional, 1999.
[24] P. Kruchten. The rational unified process: an introduction, Third Edition.
Addison-Wesley – Pearson Education, 2004.
[25] Michael Mlynarski and Andreas Seidl. A collaborative test design approach
for unit tests in large scale agile projects (talk). In imbus Software-QS-Tag,
Nürnberg, November 2010.
[26] OMG. Software and Systems Process Engineering Metamodel Specification
(SPEM), Version 2.0, 2008. URL: http://www.omg.org/spec/SPEM/2.0/
[27] The Open Group. TOGAF Version 9, 2009. URL:
http://www.opengroup.org/togaf/ [cited December 2011].
[28] Project Management Institute. PMI homepage. URL: http://www.pmi.org/
[29] A. Rausch and M. Broy. Das V-Modell XT – Grundlagen, Erfahrungen und
Werkzeuge. dpunkt. verlag, Heidelberg, Germany, 2007.
[30] F. Salger, G. Engels, and A. Hofmann. Assessments in global software
development: A tailorable framework for industrial projects. In W. Visser
and I. Krüger, editors, Proc. ACM/IEEE 32nd Intern. Conf. on Software
Engineering, SE in Practice Track Cape Town, South Africa (ICSE’10), Vol.
2, pages 29–38. ACM, NY, USA, 2010.
[31] J. Scott, J. Brannan, G. Giesler, M. Ingle, S. Jois, et al. 828-2005 - IEEE
Standard for Software Configuration Management Plans. IEEE, 2005. URL:
http://standards.ieee.org/findstds/standard/828-2005.html [cited December
2011].
[32] J. Siedersleben. Moderne Softwarearchitektur: Umsichtig planen, robust
bauen mit Quasar. dpunkt. verlag, Heidelberg, Germany, 2004.
[33] Technische Universität München. QUAMOCO homepage. URL:
http://www.quamoco.de/ [cited December 2011].
[34] J. van’t Wout, M. Waage, H. Hartman, M. Stahlecker, and A. Hofman. The
Integrated Architecture Framework Explained. Spinger, 2010.
[35] R.J. Welke and K. Kumar. Method engineering: a proposal for
situation-specific methodology construction. In Cotterman and Senn,
editors, Systems Analysis and Design: A Research Agenda, pages 257–268.
Wiley, Chichester, 1992.
169
Bibliography
170
Contact:
Dr. Marion Kremer
Capgemini
CSD Research
Berliner Straße 76
63065 Offenbach
marion.kremer@capgemini.com
www.de.capgemini.com
CSD Research is part of the Capgemini Group’s Technology Services unit
About Capgemini
With around 120,000
people in 40 countries,
Capgemini is one of the
world’s foremost providers of consulting,
technology and outsourcing services.
The Group reported 2011 global
revenues of EUR 9.7 billion. Together
with its clients, Capgemini creates
and delivers business and technology
solutions that fit their needs and
drive the results they want. A deeply
multicultural organization, Capgemini
has developed its own way of working,
the Collaborative Business ExperienceTM,
and draws on Rightshore®, its worldwide
delivery model.
Learn more about us at
www.capgemini.com
Rightshore® is a trademark belonging to
Capgemini
Capgemini Deutschland Holding GmbH, Kurfürstendamm 21, D-10719 Berlin.
The information contained in this document is proprietary. Copyright © 2012 Capgemini. All rights reserved.

Quasar 3.0 - Capgemini

Transcription

Similar documents

Doing Business The Digital Way: How Capital One

Infrastructure Services

Fiche RHAccessV2

2012_Trifold copy

6-inwestycje spoleczne raport capgemini PL

Customer Service in 2020

Celigo - Calcey Technologies

texaco petronius

The Institute for Falsification (IFF)