You are on page 1of 66


" # $%%&
Towards an agile methodology for
mechatronic one-off development

Fredrik Jonsson

! !! $%%&'
(&! )$&*
KTH Maskinkonstruktion
Examensarbete MMK2005:65 MDA253

Mot en lättanpassad metodik för utveckling av
engångsproducerade mekatroniksystem

Fredrik Jonsson
Godkänt Examinator Handledare
2005-11-01 Mats Hanson Mats Hanson
Uppdragsgivare Kontaktperson
Infineon Technologies AG
Mjukvara spelar en viktig roll i den multidisciplinära mekatronikdomänen, och
organisationer som eftersträvar att vara framgångsrika utvecklare av
mekatroniksystem är i behov av effektiva metodiker för mjukvaruutveckling.
Specifika karakteristika för mjukvaruutveckling och mjukvara medför att traditionella
metodiker typiskt inte återfinns i den kategorin.

Ur detta behov föddes de omvälvande lättanpassade metodikerna inom
mjukvaruindustrin. De lättanpassade metodikerna är iterativa, självminimerande, och
fokuserar på att skapa skickliga, kontinuerligt kunskapsinhämtande team som
sammarbetar med intressenter med målet att leverera mjukvara effektivt.

Denna rapport undersöker den inneboende naturen hos mekatronik- och
mjukvaruutveckling i syftet att identifiera likheter och skillnader mellan de två. Detta
med målet att visa att de lättanpassade metodikerna är intressanta ur ett
mekatronikperspektiv; mer precist, att positiva svar på följade frågor finns:

Q1: Är de lättanpassade metodikerna lämpliga för mjukvaruutveckling i
Q2: Är någon av de studerade lättanpassade metodikerna lämplig för
mekatronikutveckling i sin helhet?
Q3: Skulle det, baserat på grundläggande idéerna hos de lättanpassade metodikerna,
vara möjligt att designa en lättanpassad metodik inriktad på

Givet att mekatronikdomänen är omfattande, och att utvecklingsfall inom denna har
vitt skilda förutsättningar, är de positiva svaren förknippade med begränsningar.

För det första, olika utvecklingsfall är i behov av olika metodiker, särskilt inom ett
omfattande multidisciplinärt område som mekatronik. Alla utvecklingsfall som kan
sägas tillhöra kategorin utveckling av mektroniksystem för engångsproduktion är inte
lämpliga att angripa med lättanpassade metodiker.

För det andra, fördelarna som kan härledas till användning av en metodik framför en
annan måste analyseras och utvärderas från fall till fall. Alla fall kan omöjligt optimalt
täckas av en metodik.

Master of Science Thesis MMK2005:65 MDA253
Towards an agile methodology for mechatronic
one-off development

Fredrik Jonsson
Approved Examiner Supervisor
2005-11-01 Mats Hanson Mats Hanson
Commissioner Contact person
Infineon Technologies AG
Software plays an important role in the multidisciplinary mechatronic domain, and
organizations that aim to be successful in the development of mechatronic solutions
needs to have a development process that is efficient for software development. The
nature of software and software development implies that traditional engineering
methodologies are typically not in that category.

As a response to this, the iconoclastic agile methodologies where introduced within
the software industry during the last decade. The agile methodologies are iterative,
self-minimizing, and focuses on forming skilled, continuously learning teams that
collaborate with stakeholders with the aim to deliver software efficiently.

This paper investigates the nature of mechatronic one-off development and software
development in a search for similarities and differences between the two disciplines.
This in an effort to show that agile methodologies are interesting from a mechatronics
perspective, and that a positive answer to the following questions exists:

Q1: Are agile methodologies feasible for software development in a mechatronic
Q2: Are any of the studied agile methodologies feasible for overall mechatronic
Q3: Would it, based on the ideas from the agile software methodologies, be possible
to design an agile methodology targeting mechatronic development?

Given that the mechatronic domain is broad, and that development efforts within it are
subject to radically different conditions, the positive answers are subject to

First, different development efforts require different methodologies, and especially so
within a broad multidisciplinary area like mechatronics. Not all efforts that can be
sorted under the term mechatronic one-off development will be possible to undertake
using agile methodologies.

Second, the benefits derived from the usage of one methodology over another needs
to be evaluated on a case-to-case basis. Not all efforts will benefit from the usage of
one particular methodology.

Towards an agile methodology for mechatronic one-off development -1-
Table of contents -5-
Acknowledgements -7-
Motivation for the study -8-
Terminology and abbreviations - 10 -
Terminology - 10 -
Abbreviations - 10 -
Problem definition - 11 -
Limitations - 13 -
Related work - 14 -
Outline of the paper - 15 -
The characteristics of mechatronics - 16 -
Quality of mechatronic products - 17 -
Requirements - 18 -
Architectural design and modularization - 19 -
Technical Integration - 19 -
A glance at trade-offs and requirement changes - 20 -
The role of software in mechatronics - 21 -
Simulation and modeling in mechatronics - 22 -
Collaboration - 23 -
The mobile phone development cycle - 24 -
The development of an industrial robot - 24 -
The characteristics of mechatronics – a short summary - 27 -
The generic characteristics of software and software development - 29 -
The agile approach to software development - 32 -
Extreme Programming - 33 -
The Crystal family of agile methodologies - 35 -
On methodologies - 36 -
The Crystal Clear methodology - 38 -
Properties - 38 -
Strategies and Techniques - 39 -
Development Process and Roles - 40 -
Adaptive software development, a methodology for extreme projects - 41 -
Conclusions on agile methodologies - 49 -
Application of agile methodologies in a mechatronic context - 51 -
The system engineering perspective - 51 -
Agile from the product development perspective - 52 -
The methodological space - 53 -
Results of the juxtaposition of mechatronics and software development - 55 -
Requirements - 55 -
Design and modularization - 56 -
Support Tools - 56 -
Collaboration - 57 -
Complexity - 57 -
Agile methodologies in a mechatronic context – discussion - 58 -
Conclusions - 60 -
Proposed future research - 61 -
References - 62 -

Printed references - 62 -
Web references - 63 -
Appendix A. The mobile terminal development life cycle – a case study - 64 -

I would like to thank Holger Hoppe and the BI team at Infineon AG that initiated the
first half of this thesis project and provided much appreciated encouragement and
support along the way.

Professor Mats Hanson has provided advice and feedback of high quality on some of
the more difficult phases of the writing process. Without his advice, this thesis would
have been on different, less interesting, topics.

During the last couple of years, a large number of skilled professionals from the
military, the industry and the academia have influenced me in positive ways, and
shared their knowledge freely. For this, I am forever thankful.

Finally yet importantly, thanks and appreciation goes to my friends and family that
have bare with me and provided support during almost a year of thesis writing and
five years of studies.

! ,
Once upon time many engineers held what today would be called multidisciplinary
knowledge. During the last century however, the traditional engineering disciplines
(e.g. mechanical, civil, electrical, etc) have to a large extent been separated
[Petroski2002] in an effort to deal with ever increasing domain complexity; as
university curricula and as corporate departments. During the later decades on the
other hand, the market for products based on synergistically integrated components
originating from more than one of these traditional disciplines have grown drastically.
Such products are rapidly becoming increasingly complex – for example the number
of distinct system requirements for a mobile phone have increased from 300 to 6000
during the transition between typical 2.5 and 3:rd generation mobile terminals

In the development towards technically complex products that contain a large share of
novel technology, engineers with multidisciplinary education, knowledge and
experience have important roles to play. An important mean for these engineers are
compilations of methods that allow the work – specific for multidisciplinary product,
solution, or system development – to be carried out in a systematic, efficient and
repeatable way with minimized risks. In this context, the two terms “mechatronics”
and “methodology” are highly relevant, as will be further emphasized in the following
sections of this paper.

The term mechatronics emerged in literature during the late sixties and mechatronics
as engineering curricula have existed a few decades [Grimheden2002]. Mechatronics
can thus, in one aspect, be considered one of our youngest engineering disciplines; for
example computer science, and the related profession of software engineering, has
existed almost twice as long [Wikipedia1].

In the case of software engineering, prominent voices manifests that it took until only
a few years ago before useful methodologies1 where developed [Fowler1]. The initial
approach used in the software industry was that of ad-hoc design and realization.
Later, prediction-based, feed-forward methodologies adopted from construction
oriented engineering disciplines where applied to software development. What
became evident was that neither of these two approaches was very successful – or that
both were somewhat successful when applied on the extremes of what is today
considered a role model software development project in terms of scope, size and

The ad-hoc approach causes problems when complexity and team size increase. The
construction oriented methodologies served (and serves) its purpose in the other
extreme; extensive development efforts with stable requirements. A common opinion
among modern software methodologists is however that the nature of software
development is radically different compared to that of traditional engineering
disciplines, and as a result, that it is in general not appropriate to apply these
methodologies to problems in the software domain.

The term methodology is used as “how an organization repeatedly produces and delivers” at this time.

During the last decade, the software industry have instead strived towards
methodologies that focus on high quality feedback rather than exact feed-forward, and
a healthy balance between disciplined and skilled teams on one hand and rigid
methodologies on the other. As a result, alternatives are emerging in a rapid pace; for
example RUP2 and the family of agile methodologies, of which a subset is studied in
this text.

Despite the indication that methodologies should not be moved between contexts
without careful consideration, and the fact that broad topics require different
methodologies depending on the nature of the problem at hand, many interesting
concepts exist in the agile software development methodologies; concepts that could
very well be useful within the mechatronic context. According to the author, these
have the potential to provide significant benefits in terms of productivity, ability to
manage changes and risks while fostering learning and innovative environments and

Juxtaposition of mechatronics and software engineering is fruitful not only because
mechatronics per se contains software engineering as one of its cornerstones and
because the software industry has a ten year lead in the development of methods and
tools – but also because knowledge about software and an efficient software
development process provides invaluable competition benefits for companies that
develop multidisciplinary products:

“Companies that do not manage software development efficiently are destined to
fail. If your software strategy and development processes are strong, you can add
extra functionality to almost any product before rivals can respond.”[Stevens1998]

Rational Unified Process, [Wikipedia2]

The term software development is used to describe initial development or major re-
development of software. Maintenance (e.g. minor bug-fixes) is excluded when this
term is used. No distinction between software developed for mass-production and
one-off development efforts is considered necessary.

The term mechatronics is used to describe the characteristics of systems, products or
solutions based on synergistically integrated elements from the electrical, mechanical,
and software engineering domains.

The term mechatronic product development refers to the set of activities leading from
a market opportunity to the production, sale, and delivery of a mechatronic product3.

The term mechatronic prototype development refers to the development of a
functional and demonstrateable prototype, or using stricter terminology, a
comprehensive-physical prototype rather than the opposite, a focused-analytical
prototype [Ulrich1995].

The term mechatronic one-off development or mechatronic one-off product
development refers to the complete development of a product that will not be mass-
produced, and hence a situation where optimization for mass production, distribution
and sales are non-issues.

When the term mechatronic development is used, it explicitly refers to mechatronic
prototype development and mechatronic one-off development.

The term methodology is used as defined by Cockburn [Cockburn2003]:

"Any conventions and policies the team relies on to successfully deliver

Cockburn’s definition in turn is an expansion of the definition in the Marriam-
Webster dictionary:

“A body of methods, rules, and postulates employed by a discipline.”

! ! !
" " # ! ! !
$ $ ! !

Adopted from a product development definition proposed by [Ulrich1995].

- 10 -
- +
As the history of methodologies in the software industry, as well as numerous
examples from history in general, have taught humankind, one cannot take for granted
that something that works well in one context will work nearly as well in even a
slightly different one. The history does also indicate a limitation of the validity of
possible results from such experiments – it shows that it is naïve to overestimate the
validity and reproducibility of results where individual humans play the major roles.
Engineers try to address these issues by the use of methodologies – procedures,
processes, predictions, plans, documentation and careful follow up on metrics to name
but a few means. The struggle to achieve control is a compromise between rigidity
and bureaucracy on one hand and productivity on the other; resources spent on project
internal control elements could instead have been spent on actual deliverables4.

As an answer to overwhelming administration and bureaucracy, an unpredictable
environment and unpredictable but responsible humans, the family of agile
methodologies is characterized by taking a slightly different approach than the
traditional; some of the bureaucracy is eliminated, the responsibility is moved to
individuals, and emphasizes is put on adapting rather than predicting. The agile
methodologies are successfully practiced in the software industry, in various variants
that differ in completeness and feasibility for a given situation – some are strictly
designed for teams of a certain size working under certain circumstances [XP1] and
yet others are more flexible and can be adopted, or minimized, to suite the needs in a
vast variety of situations [Cockburn2003] [Highsmith2000]. The main benefits of
agile methodologies, it is argued, are minimization of risks caused by changing
environments, increased productivity, higher product quality and learning

In this paper, the results of literature- and case studies on the topics T1-T6 will be
presented. Based on these results, the aim is to provide answers to the questions Q1-
Q4. For each of the four questions the aim is also to investigate what the benefits from
a positive answer are in respective situation.

T1: The characteristics of mechatronics and mechatronic development,
T2: the role of software within mechatronics,
T3: the characteristics of software and software development,
T4: the similarities and differences between the two disciplines,
T5: methodologies in general, and
T6: agile software development methodologies in particular.

Q1: Are agile methodologies feasible for software development in a mechatronic
Q2: Are any of the studied agile methodologies feasible for overall mechatronic
Q3: Would it, based on the ideas from the agile software methodologies, be possible
to design an agile methodology targeting mechatronic development?

Artefacts delivered to the customer, such as documents, source-code and physical systems or objects.

- 11 -
Q4: If the answers to Q2 and Q3 are negative: Are individual concepts from agile
methodologies applicable in a mechatronic development context?

- 12 -
As indicated in previous sections the conclusions of this study will be limited to
mechatronic one-off development. Considered included in the term is also
mechatronic prototype development. Beside the basics meaning of the terms, defined
in the terminology and abbreviations section, the development efforts targeted in this
paper are assumed to have the following characteristics:

• Development of requirements is a part of the overall development effort.
• The customer together with the development team defines the requirements.
• The development team is assumed to be small to medium sized5,
multidisciplinary, and co-located6.
• A majority of the development efforts are undertaken in-house.
• The development effort is assumed to contain a significant share of software
• The development effort is assumed to contain a significant share of, for the
organization and/or in the context, novel technology.

These limitations are deliberately strict, but on the other hand relatively effortlessly
expanded. In this paper, the introduction of the modularization concept will decrease
the impact of the limitations imposed on the team setting. The introduction of a
system-engineering organizational model that reflects the modules will in turn relax
the limitations further and provide an overall context. Further expansions are left for
future research.

The sections that describe the result on the topics T1-T6 are intended to provide the
foundation needed for the argumentation in this paper and provide references for
further reading. These descriptions do not intend, nor claim, to be complete state of
the art descriptions of respective area.

Activities that might be included in a typical project life cycle but are not a part of, or
strictly related to, the technical development efforts (project initialization,
maintenance, education etc) are not explicitly covered, even if multi-release lifecycle
perspective on the development is sometimes used.

And most important, the aim of the paper is to introduce methods that have previously
not been used and documented in a mechatronic context. The paper aims to show that
these methods are relevant; to in any formal sense prove that they are better or more
efficient than any other practice is beyond the scope of this text.

A small to medium sized team is in this text regarded as team consisting of less than 15 persons.
As a matter of fact, the imposed limitations on team size and co-location are often considered parts of
optimal team characteristics: [Smith1991] [Cockburn2003]

- 13 -
This work takes a stand in a discussion around the term mechatronics much inspired
by [Hanson2001] and [Grimheden2002], with a focus on the multidisciplinary nature,
the team, and the integration aspects of mechatronics rather than the involvement of
specific disciplinary elements.

The work done by software methodologists contributes an interrelated family of
software development methodologies, as well as a generic body of knowledge on
methodologies, that constitutes a large part of the foundation for this paper
[Cockburn2005] [Highsmith2000] [XP1].

The results are put into context using a generic system engineering methodology as
outlined by [Stevens1998], and a product development methodology as outlined by
[Ulrich1995]. The work on system engineering also contributes important points
related to the nature of software, especially from a multidisciplinary development

- 14 -
The following chapter investigates the characteristics of mechatronics as an
engineering discipline, with emphasizes on its multidisciplinary nature, technical
integration, collaboration and the design process. The characterization has the sole
purpose to form a foundation for conclusions and argumentation within this
document. The topic selection is motivated using a discussion around the quality of
mechatronic systems. Included in the chapter are also sections on the role of
simulation, modeling and software within mechatronic engineering.

The aim of the chapter describing the generic characteristics of software and software
development is to provide the background that explains the ideas behind the agile
methodologies as well as to further highlight the role that software plays within the
mechatronics domain.

Hereafter, the agile approach is presented, including the overall agile concepts as well
as more in depth descriptions of three specific methodologies. The descriptions aim to
give an inspiring and representative, however not complete, picture of the concepts
and methodologies for someone who has not studied them previously.

In the chapter application of agile methodologies in a mechatronic context, typical
system engineering and product development methodologies are outlined in a search
for a methodological and organizational context where agile methodologies could be

The results from the juxtaposition of mechatronics and software development are
hereafter summarized, and the differences and similarities between the two disciplines
are identified and explained. These results and the following discussion serve as a
foundation for the conclusions presented in the paper.

- 15 -
To be able to have a fruitful discussion and draw conclusions about the mechatronic
development process an important prerequisite is to establish a common
understanding of the subject. Several authors have provided definitions of the term
that are similar, but with slightly different focus. This chapter takes a stand in the
most common elements of these definitions and investigates some of their
consequences. The aim is neither to provide a new definition of ‘mechatronics’ nor to
make a complete analysis, but to cover what is relevant for the argumentation and
conclusions within this document.

A common factor among most of the definitions [Colostate1] is that mechatronic
solutions are characterized by a synergetic co-existence of modules with their roots in
the mechanical, electrical and software engineering disciplines (and as a direct
consequence, that mechatronics engineering targets the design and realization of such
solutions). These characteristics are efficiently illustrated using a Venn diagram, as in
figure 1.

Electrical Engineering Mechanical Engineering


Software Engineering

Figure 1, Simple Venn diagram describing mechatronics

As indicated by the diagram, mechatronics as an engineering discipline covers an
extremely broad knowledge scope, and therefore a focus on the specifics of
mechatronics as one discipline7 – multidisciplinary requirements, modularization,
architectural design, integration and collaboration – is in this text considered more
rational than analysis of any specific multidisciplinary case. The centuries old trend
towards separated and highly specialized engineering disciplines, and on the other
hand, the trend towards increasingly complex products that involves a variety of

This can be compared with the thematic identity of mechatronics, as described by [Grimheden2002]
and [GrimhedenEvo].

- 16 -
technologies with their roots in different disciplines reinforces this approach further;
the importance of the studied activities and acts follow product complexity.

To exemplify and highlight the logic behind the selected focus, a brief discussion
about quality metrics for a mechatronic product is beneficial. The generic ISO
definition of quality serves as a useful starting point for any discussion about quality,
it reads:

“[Quality is:] The totality of characteristics of an entity that bear on its ability
to satisfy stated and implied needs.”

The definition clarifies that the quality of a product or a service cannot be judged by
looking only at the entity itself, but instead on the entity in its intended context or
environment – in other words, from a developer perspective the intended environment
needs to be understood so that the stated and implied needs8 can be fully captured.
Furthermore, for a modularized product the quality must be measured on the
integrated modules; meaning that it depends on the quality of overall requirements,
architectural design, integration, and only indirectly on the quality of individual

In the mechatronics domain as defined in this text, and in an environment that can be
considered static, the quality definition can thus be refined slightly without loosing
accuracy; by separating the module level and the system level in one dimension, and
on the other the requirement definition, the design, the realization, and the integration
efforts9. The total quality of a subsystem-based mechatronic product can thus be
illustrated as in figure 2.

Quality of a sub-system based product

Quality of system Quality of Quality of
level requirements architectural design integration

Quality of related
System level deliverables
Module level (Documentation,
configuration etc)
Implementation of individual
Design of individual modules Design of individual modules Implementation of individual
Quality of module
Design of individual modules Quality
Design of of individual
individual modules Quality of individual
level requirements module designs module realizations

Figure 2. Quality of a subsystem based, integrated system

It is important to notice that latent needs are often as important as explicit needs in determining
customer satisfaction. [Ulrich1995]
The sub-processes and their names are adopted from [Stevens1998]. No distinction is made between
user requirements and system requirements at this time.

- 17 -
In theory, the fulfillment of all stated and implied needs in a subsystem-based system
can now be said to depend on that:

• All the stated and implied needs on the system level are identified and
successfully transformed into system level requirements.
• An architectural design that covers all these requirements is developed. This
includes partitioning into subsystems.
• The system level requirements are assigned to the respective partition or
subsystem without losses or alterations.
• Individual subsystems are successfully designed to fulfill the associated subset
of requirements.
• The individual subsystem designs are successfully realized, i.e. the module
level requirements can be verified.
• The integration of subsystems is successful, i.e. the system level requirements
can be verified.
• Related artifacts and services are delivered with high quality

Note that “needs” have implicitly been discussed in terms of function, and that it has
been assumed that all needs can be fulfilled; both obvious simplifications. In practice,
functionality is associated with resources, and tradeoffs in terms of cost, time and
quality10 will be required in the journey towards an optimal set of deliverables. Both
stated and implied needs on the system level can however be seen as function, cost,
quality, or timeframe-related without rendering the above quality model useless.

It should also be noted that the phase division utilized in this example might not be
optimal for actual development; more steps might be used and these might not be
sequential. The representation do however provide the distinctions necessary for the
quality discussion, even if the following sections, describing the above and related
concepts, will neither assume a sequential development model nor that the mentioned
phases are used.

The first major step (not necessarily chronologically speaking) towards a successful
project outcome is the developer’s understanding of the customer’s11 stated and
implied needs on one hand, and on the other, the customer’s understanding of the
technical design space. In other words, communication and learning processes with at
minimum two actors12 that must strive towards a mutual understanding of
requirements and possibilities. The target outcome, at some point in time, is a
complete set of distinct requirements that describes both the boundaries for the
development effort and the user’s needs.

The function-cost-time triangle has transformed into the function-quality-cost-time square. Cockburn
puts it slightly different in [Cockburn2003:2]: The function-cost-time-process square – when quality is
not a variable, cutting bureaucracy and administration and trading it for team discipline makes the forth
Customer denotes users as well as other external stakeholders in this context.
At the highest possible level of abstraction, this process involves at minimum one customer and one
supplier role. The number of actual stakeholders in terms of (parts of) organizations or persons is
naturally larger.

- 18 -
As can be readily seen these two communication and learning processes goes hand in
hand, a little step at the time followed by communication and adjustments caused by
either a better understanding or a changing environment – an iterative process with a
high degree of interaction between several stakeholders. The efficiency of such
processes, as well as the quality of the outcome, relies heavily on efficient
communication. To facilitate communication, artifacts such as models, simulations
and prototypes are considered useful information conveyors.

While user and system requirements are distinguishable, and such a distinction is
often recommended, there are reasons why it is not made here. First, when
mechatronics is described as in this text, the core difficulty is that of cross-
organizational learning and communication. Second, it is arguable if a project with the
prescribed characteristics would benefit from such a distinction. One reason for
distinguishing user requirements from system requirements however is that system
requirements provides a transparent, traceable link between user requirements and
architectural design, that can be used to analyze the impact of trade-offs.

The word design has wide meaning and is used in many situations, for example
industrial design and engineering design [Johannesson2004]. In this text the term
architectural design refers to the overall design of a system [Stevens1998] – sub-
system partitioning as well as how the subsystems behave, relate to each other and to
the environment.

Partitioning and item-to-partition assignment is a common problem within a vast
number of areas, and a natural approach to complex technical design problems where
the technique is often referred to as modularization. In the mechatronics case, the sub-
system approach is feasible both because of the complexity of typical mechatronic
products and because of the multidisciplinary nature that in at least some occasions
allow modules to be limited to one discipline.

In the mechatronics domain, the partition problem answers what decoupled modules
should be in the design and the assignment problem answers what functionality that
should be implemented within the scope of each module. As can be readily seen, the
modularization is a large part of the architectural design, and has major impact on the
final characteristics of the product; development cost, upgradeability and
maintainability to name but a few critical aspects. Furthermore, modularization is also
an important concept for e.g. organizations with a larger portfolio of related products
because it provides the foundation for reuse, which in turn implies that different life
cycles can be used for different modules, possibly with origin in different disciplines.

One aspect of modularization worth special attention is the possibility to consolidate
change-prone functionality into a limited number of modules. If successful, such an
attempt can bring comprehensive benefits.

An example stating that the number of requirements for a mobile phone has increased
from 300 to 6000 between the 2.5 and 3rd generation [Kornby2005] was used earlier
in this text. The approach to cope with the increased complexity is clear in its
direction; the separation of engineering disciplines have fostered efficiency and deep

- 19 -
discipline specific knowledge and given birth to integrating disciplines such as
mechatronics and system engineering. This structure of competence and specialization
is to some extent visible in organizations and implies that the term integration should
be seen in both a human and a technical perspective, where in this text a subset of the
human perspective is discussed under the section labeled “collaboration”. From the
technical perspective; as the system complexity increases for a modular system, the
importance of the integration follow, and the impact of design mistakes revealed
during integration might end up being fatal. Therefore, technical integration is
discussed separately, even if some aspects of the discussion touch upon architectural

The engineering problem: Integration of subsystems with common interfaces needs to
be approached as a specification task, may it be formal or informal; it is necessary to
establish a common understanding of shared boundaries and the signals, or
information flows, crossing these. This process requires comprehensive knowledge
and understanding of the overall system, as well as the requirements on the same, to
be successful.

To believe that the theoretical part of the integration is completed after a mutual
understanding covering the distribution of functions across modules and their
common interfaces have been reached would however be naïve; the agreements that
describes requirements, architectural design, module boundaries and interface must all
be considered live agreements. As such, they are subject to optimization and re-
prioritization due to never-ending compromises and trade-offs in terms of cost, time,
functionality, usability and so forth as the knowledge about the system increases or
the needs changes.

From a practical perspective, actual integration of subsystem is the occasion that
verifies two things. First, that the interface related agreements have been concise and
up-to date so that the sub-systems can interface each other correctly. And second, that
the requirement and partition related agreements have been all-covering and concise,
indicated by successful validation of the requirements. To avoid that integration
happens only once during the development process, various techniques are used.
Comprehensive-physical prototypes are typically used in product development
[Ulrich1995]. For software on the other hand, near-continuous integration is possible
with little resource waste.

If one for a moment let “design” denote the architectural design, the modularization,
and the interfaces between modules altogether it becomes possible to discuss what
happens in the borderland between design and requirements.

The requirement gathering process was discussed in terms of a two party reciprocal
learning journey, where each party had to learn from the other to be able to provide
relevant feedback from within its own context. This process naturally takes time, and
concise requirements with clear priorities are produced incrementally. To complicate
the situation further, during the process the developer also needs to build knowledge
within her own context in the form of a design; because the consequences of the
requirements in terms of cost, usability etc can only be derived from the design.

- 20 -
The mutual dependencies outlined above are, in theory, addressed in early revisions of
the waterfall development model13. It is however important to note that as long as the
learning process is ongoing, there will be a need for refined trade-offs. We noted
earlier that prototypes, models and simulations are efficient communication artifacts,
and that integration of components is often only done once or twice. Thus, one must
ask oneself a few crucial questions: When is the learning process completed? And,
what are the consequences of tradeoffs reaching over several development phases?

Beside from the impact that learning has on the requirements and the design, the
impact of likely, or at least possible, changes in the solution environment, uniformly
distributed over the development timeframe, must also be considered. For product
prototypes targeting competitive markets, or one-off solutions that are supposed to
operate in agile business or industrial environments, successful management of such
changes is necessary to be able to produce the best possible deliverable at a given

During the development process, it is important to take into account that requirement
or design changes often have an impact on the rest of the system on the integration
level, and that failure to deal with this leads to the introduction of design flaws. The
detection of such flaws relies on sophisticated tools, which are not always available,
or participants that have very good overall knowledge of the system, the customer
requirements, the used technology and so forth.

Software is often the most flexible element in its context – be it a business process or
a mechatronic system – correctly designed software tends to require the least
resources (material-costs, man-hours) to be adapted to changing requirements. A
similar situation can be seen also when requirements are stable; implementation of
functionality in software is in general more resource efficient than a corresponding
hardware implementation. Consequently, software plays an important role in the
development of mechatronic systems.

In a case study of mobile terminal development following, numerous examples of the
benefits derived from software-implemented functionality will be demonstrated from
a product development, multi-release life cycle perspective. To name a few key
benefits; short time to market for new requirements, pay per functionality options,
after sales upgradeability, and reusability.

In the case of mechatronic one-off development, not all of the above benefits might be
relevant, but yet others are. The characteristics of software provides an obvious
approach to the module assignment problem described earlier, namely to assign as
much functionality as possibly to software sub-systems. The result of doing so is not
only a resource efficient design, but also one where the impact of erroneous design
decisions and the possible impact of high-risk design decisions are minimized during
the development. The fact that software is not associated with delivery lead-times or
material costs in a traditional sense also open up an opportunity for rapid and resource
efficient prototyping in uncertain areas.

The waterfall development model is a comprehensive and, at least in the software development
community, infamous sequential development model.

- 21 -
Given the described benefits of flexible and function-rich software implementations in
mechatronics, it is obvious that an efficient software development process tailored for
the mechatronic context is an important success factor for any mechatronics company
in a competitive market. A company that practices a poor software development
process will deliver most of its functionality later and at lower quality than it’s
competitors, and thus, will have difficulties to survive [Stevens1998].

In modern engineering, model-based simulation often plays a major role and provides
a possibility to iteratively test designs, realized as models, with cyclic feedback from
simulation. Simulation results, models and prototypes are also important artifacts
when seeking high quality feedback from stakeholders. Modeling and simulation is
often a prerequisite for traditional, feed-forward and predicting, engineering
methodologies targeting areas such as infrastructure construction, a domain of
engineering where humankind have millennia-long experience.

This said, it should be noted that the benefits of modeling and simulation together
cannot be compared with those of modeling alone, that might at best facilitate design
and serve as a mean for communication. Consider for a while source-code as a model;
would it make sense to trust that model without first compiling or testing it? Hardly,
the code is however an efficient way to demonstrate a conceptual solution to another
programmer. The situation for models at different abstraction levels is analogue.

For multidisciplinary system development, the situation is typically different
compared to the infrastructure engineering case – there is typically no millennia long
experience that have resulted in that mathematical analysis of the complete problem is
possible. Consequently, it is seldom possible to model and simulate the complete
system in any traditional sense, including the interaction between different
technologies on one hand and technology and unpredictable human users or
environments on the other. Even if methods and tools for the purpose are being
researched and developed, it is relevant to at least ask the question whether complete
modeling and simulation capabilities is a rational and realistic strive in all situations.

Studying state of the art in the area, a few noteworthy observations can be made. The
first is that on the disciplinary level modeling and simulation tools are often readily
available and parts of well-tested de-facto standard development methods. Examples
include CAD systems and simulators for electrical circuits.

Second, in certain multidisciplinary cases such as motion control, modeling and
simulation tools and techniques are available. The motion control case is special
because it does not require simulation of software – instead source-code is generated
based on a mathematical model.

Third, for software, tools and languages for modeling are often available, even if
simulation is in general not possible. On the other hand, using incremental or iterative
software development, continuous integration and builds can serve close to the same

- 22 -
Forth, for software and complete systems, modeling is often possible at some level
(e.g. UML14, SysML15). These modeling languages and related tools are being
improved rapidly, and sophisticated tools that allow visual design of software- (UML)
or system- (SysML) models often provide the capability to generate source-code that
at least reflects the software components of the model. Even if the usefulness of such
auto-generated code can be questioned, the models, independent of their level of
detail, are useful artifacts that facilitate the understanding of the architectural design
and function as platforms for human communication.

Evidently, a sound modeling and simulation strategy depend on the development
landscape; it cannot be taken for granted that for example usage of UML is an
advantage. Furthermore, it is important to notice that in a multidisciplinary
development effort, system optimization is the overall target, a target that does not
necessary go hand in hand with subsystem optimization.

Looking back at the previous section on changes and trade-offs; engineering efforts
where simulation is possible are typically centered on iterations of a ‘understand –
model/design – simulate’ cycle followed by realization and evaluation. During the
later two steps minor adjustments of even the perfect specification and design are
often necessary, but unplanned iterations covering parts of the realization are costly
and strictly unwanted unless in the form of (planned) prototypes. The impact of
removing the simulation from the iterative cycle makes the usefulness of the iterations
(in that context) questionable.

Therefore, the lack of a complete simulation solution has a large impact on the
process of validation of design and requirements. Even if components, also
multidisciplinary ones, of mechatronic systems can be modeled and simulated, the
integration and optimization of subsystems, and the interference of man and nature,
are often not covered and forces a non-traditional work process approach, or
alternatively, high risks.

Collaboration, according to the Merriam-Webster dictionary, is “to work jointly with
others or together, especially in an intellectual endeavor”. This section does not aim to
investigate the term, or how humans collaborate, much further – but to emphasize
what have been evident in the past sections; that many important aspects of
mechatronics are collaboration-intense by nature.

The requirements gathering process depends on collaboration between developers
from different disciplines and stakeholders, as does the design process and the
integration process, all linking back and forth to the others. During all these, efficient
collaboration is a key to progress and success. What is more, changes to previous
agreements are likely to happen during the development process, and any change
depends on collaboration to minimize the impact thereof. This situation might not be
very specific for mechatronics – the same applies for more or less any development
effort – but still, it is an important observation.

Unified modeling language, [UML1].
System modeling language, [SysML1].

- 23 -
Mentioned here are but a few specific cases where the development process relies
collaboration, or more specific, on that large amounts of information is transferred
between humans or organizations efficiently, accurately and reliably. A few means to
accomplish this have been touched upon earlier in this text, artifacts that help convey
information, and yet others are to be highlighted in the following chapters.

In appendix A, an article that describes the development cycle for state of the art
mobile phones is summarized. The article was published in Ericsson Review, Volume
82 2005 p 41, The EMP Story.

In the article, numerous benefits derived from software-implemented functionality on
highly modular platforms are exemplified from a product development, multi-release
life cycle perspective.

During the course of this master thesis project, an industrial robot were developed as
an assignment made for Infineon AG. Presented here is a short description of the
project, including some of the observations on the characteristics of mechatronics
made during the development. The complete project documentation can be obtained
from the author upon request.

The robot application was developed around a SCARA16 type robot arm and the scope
of development included mechanical design of the robot-tool and the platform for the
robot arm as well as the design and development of movement algorithms and user

Figure 3. An overview of the robot application. The platform for burn in boards is located in the
centre of the layout, and component repositories can be seen on the sides.

Selective Compliance Articulated Robot Arm

- 24 -
The developed solution targeted laboratory use, with the purpose to load and unload
burn in boards (BIB)17 with components mounted in reusable sockets. The
requirements stated that the solution should handle all the different
package/socket/BIB models used within the organization at the time, and be
configurable for future changes. Semiconductor components were to be moved
between three different repositories, situated in three different locations and having
different capacity, measurements and orientation. Given packages of different sizes,
BIBs from different manufacturers and variations in socket function and size, a vast
range of cases had to be accounted for. Another important requirement was that the
solution should handle subsets of complete repositories.

The requirements implied that the solution would require a sophisticated user
interface for run-time configuration, a flexible storage solution for parameters, i.e.
coordinates and movement algorithms, and a generic layer and interface for execution
of robot movement commands with arbitrary parameters.

Figure 4. One example of a burn in board (BIB). The possibility to slide the platform was
necessary due to the limited range of the robot arm.
The developed tool consisted of a pneumatic actuator that controlled a suction cup for
picking components, and an adjustable mechanical mechanism for the compression of
sockets before insertion or removal of components.

Burn in boards are used during accelerated ageing and test of semiconductor components. A typical
board measures approximately 0.5x0.5 metres and can hold hundreds of components in separate
sockets that need to be operated before insertion of removal of a component.

- 25 -
Figure 5. The pneumatic actuator is used to higher or lower the suction cup. The width of the
blocks that operate sockets can be adjusted using a trim screw.

The robot tool, the BIB platform and the component repositories was manufactured
by an external workshop. Generic designs were forced by the fact that many of the
design input parameters was uncertain during the first half of the project. On the other
hand, early delivery of the hardware was deemed vital for the project outcome
because any meaningful, end-to-end, functionality test depended on that the hardware
was in place.

Figure 6. One of the three dimensional repositories. The robot arm was used to slide the trays
within the cassette.
The robot manufacture specific programming language had to be used for the
execution of robot movement commands on a dedicated hardware platform, but was
deemed unsuitable for the complex logic needed to handle the run-time configuration

- 26 -
and the user interface. For that purpose a solution in java was developed. The java
software looked up movement parameters in a database and controlled the execution
of the movement commands using a serial communication interface towards the robot
controller. The software was designed to allow creation of arbitrary movement
algorithms, for any number of repositories with arbitrary parameters, using a web
interface towards the database.

Due to the broad selection of input parameter from the operating environment, the
logic for movement control rapidly grew complex; algorithms for rotating
components, operating in three-dimensional repositories, and handling the moving
BIB platform and the tool was needed, and the large variations in possible run-time
setups often rendered exceptions to generic attempts.

During the development, available portions of the solution was integrated and tested
on a weekly or sometimes daily basis. For the java software, an environment that
allowed an automated build and test procedure was configured. Of course, testing of
software that involved mechanical movement could not be fully automated, but still,
the near continuous integrating and testing approach was valuable:

• Numerous errors induced by newly developed functionality, into previously
well functioning areas, where caught and corrected early18.
• A large share of the functionality was tested using a larger set of input
parameters than would have been possible using a strictly sequential
development approach.

A few observations from the development have been hinted in the above text, a short
form summary concludes this section:

• Relatively non-complex technically solutions turns complex when they need
to operate in diverse environments.
• Software provides efficient means to handle this type of complexity.
• End-to-end testability for mechatronics systems depends on that most
components, or incarnations thereof, are available.
• When possible to use, an iterative approach to development, integration and
tests can bring significant benefits.

When studying the multidisciplinary aspects of mechatronics, activities such as
requirement gathering, modularization, architectural design and integration requires
attention as they are important for the quality of the outcome from a multidisciplinary
development effort.

Often, the requirement gathering and the overall design process needs to progress in
parallel, as an iterative multiparty learning journey. The importance of this process is
reinforced by the fact that tools that allows simulation of complete mechatronic
systems is often not available, and that end-to-end integration and test might not be
possible to accomplish until late in the development effort.

I.e. automated regression tests.

- 27 -
Software plays an important role in mechatronics; because it provide the possibility to
implement functionality relatively resource efficiently, and because functionality
implemented in software is relatively effortlessly adapted when changes occur.
Efficient usage of software in the architectural design can, to a limited extent,
compensate for the absence of simulation tools and minimize the possible impact of
high-risk design decisions. An efficient software development process provides a
major competitive advantage for companies that develop mechatronic solutions.

When studying the nature of the above activities, it becomes obvious that many of
them are collaboration intense, and thus, that efficient collaboration is another vital
competitive advantage.

- 28 -
To fully understand the course taken by the agile methodologies it is necessary to
highlight a few of the more important characteristics of software. The description
focuses on the initial development of software rather than a typical life cycle scenario
where a large amount of low intensive maintenance is typically included.

First of all, software development is extremely design focused. Considering source-
code a design document and comparing the compilation of source-code with a
construction process are both highly relevant similes. A few direct consequences
hereof are worth to notice as a foundation for the following discussion on agile
methodologies; software replication (construction!) is not assigned with any
significant costs, the programmer is the designer, and any update or bug fix is a
change to the design [Stevens1998].

Second, modern software is often complex, with numerous degrees of freedom:
Complex business logic, user interfaces, interfaces towards other systems and
component distribution going side by side with the need for adaptability or
configurability towards an often rapidly changing environment. What is more, from a
multidisciplinary perspective:

“Software is usually inherently complex. Software is particularly suitable for
handling some types of complexity – behavioral and dynamic. As a result, the
system complexity is preferentially put into software. A software program
may contain hundreds of thousands of lines of code, and thousands of active
fragments of code. A fault in any one can kill the system. The mechanical
components of a complex system have fewer parts, more uniformity between
those parts and – critically – those parts are usually passive, not active.”

Third, software is non-linear in its behavior; it cannot be taken for granted that a small
change in input results in a small change in execution path or output. One important –
and utmost unpleasant – consequence thereof is that complete verification of software
by testing is in general impossible [Thane2000]. As the pioneer computer scientist,
Edsger W. Dijkstra once put it:

“Program testing can be a very effective way to show the presence of bugs,
but is hopelessly inadequate for showing their absence.”19

Another consequence of the non-linearity is how software fails, unlike a mechanical
part that will typically function while it is within a certain tolerance gap; software
does typically not deteriorate slowly – it crashes abruptly and definite [Stevens1998].

Other, more or less, relevant Dijkstra quotes includes: "Object-oriented programming is an
exceptionally bad idea which could only have originated in California", "When there were no
computers programming was no problem. When we had a few weak computers, it became a mild
problem. Now that we have gigantic computers, programming is a gigantic problem" and finally, "You
must not give the world what it asks for, but what it needs."

- 29 -
On the other hand, sequential software is usually considered deterministic; its
behavior will not change over time [Thane2000].

Forth, most modern programming languages are so called object-oriented languages.
An object-oriented design can be directly transformed into object-oriented software
and vice versa. Object-orientated design can informally be described as modeling in
terms of encapsulated objects that has internal properties and internal or public
functions that allows interaction with these. The object-oriented design (as well as
structured programming to some extent) therefore includes the same type of
partitioning and assignment problem that was described as modularization in the
mechatronics context; partitioning into entities, and assignment of functionality and
data toward these entities. Besides from supporting the modularization technique by
design, object oriented languages do also support iterative development and
continuous integration by design – an architectural design can initially be realized as a
code skeleton that is thereafter iteratively refined to include needed algorithms and
data structures.

Fifth, software typically contains a large percentage off newly designed algorithms, as
put by Stevens et al:

“Software normally contains more novelty than physical systems. A house that
contained more than, say 10-20% of novel components would rightly be
regarded as a prototype, likely to fail. Software programs, even when they are
updates of existing systems, contain a large percentage of new code. The
combination of novelty and intrinsic complexity makes for high risk.”

In recent years, attempts have been made to separate design and “coding” within
software development, by the use of for example UML for the design and less skilled
coders for construction-like coding. Such an approach must be subject to at least two
questions [Fowler1]: Can you get a design that is capable of turning the coding into a
predictable construction activity? And if so, is cost of doing this sufficiently small to
make this approach worthwhile?

The answers to these questions are not in any way obvious, and tend to differ from
case to case. A few general observations can however be made: In for example civil
engineering the design-construction separation is efficient because of millennia long
design experience, possibility to undertake mathematical analysis of the design,
relatively stable requirements and availability of modeling tools. None of these holds
true in the role-model software case. To create a flawless design in UML is therefore
not an easy task, even for an experienced software engineer. It must also be noted that
the value of a “perfect” model depends on how large the relative share of the project
where it can be used is; in the civil example, construction can allocate 90% of the
resources while actual coding in a software lifecycle typically takes between 15% and
50% of the resources [McConnel1996].

If the software industry lags behind traditional engineering disciplines in terms of
modeling and simulation, the discipline often have a clear lead in process and
collaboration support tools such as version handling systems, automated document

- 30 -
generation tools, configuration management tools, requirement management tools,
automated build and test systems and so forth.

- 31 -
During the last decade a family of methodologies focused on productivity, change
tolerance and efficient communication and collaboration have emerged, and been
successfully applied, in the software industry. The main differences compared to the
traditional, construction oriented feed-forward, engineering methodologies are the
focus on adapting and learning rather than predicting and planning, and skilled
individuals rather than strict procedures – or simply put, people and environment
rather than process [Fowler1]. A common factor for the agile methodologies is that
they are relatively lightweight; striving to minimize the amount of bureaucracy,
focusing on productivity by relying on team discipline and capability rather than
rigorous processes [Fowler1]. The foundation and philosophy behind the
methodologies is summarized in the manifesto for agile software development

We are uncovering better ways of developing software by doing it and helping others
do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

A number of different methodologies that can be sorted under the agile label exist.
Even if they are well consolidated within the boundaries of the manifesto they tend to
have a slightly different focus. In the following section, three of them will be outlined
in more detail:

1. The minimalist “extreme programming” methodology with strict boundaries
and high demands on discipline.
2. The more comprehensive “crystal” family of methodologies with more relaxed
boundaries, founded to a large extent within the academia.
3. The adaptive software development methodology, in which hints that we are
moving towards a generic product development methodology can be seen.

The three different methodologies are presented using three different perspectives,
with the aim to cover the most important parts of the theoretical foundation behind the
practices without rendering the text repetitive and heavy to read. In this strive; the XP
description uses a developer perspective – exploring the practices without mentioning
much theory at all. The Crystal description looks upon methodology from a project
perspective, and the adaptive software development description from a management
and customer-supplier perspective.

The shift in focus is partly contained in the methodologies themselves, but also to
some extent a construct by the author; it is therefore of uttermost importance to

- 32 -
observe that the three different descriptions together intends to give a good overview
of the overall concepts, but one of the descriptions alone might not give a complete
picture of that methodology. Albeit, hopefully a useful and inspirational one. For the
complete descriptions, the works referred in respective section are highly

It should be mentioned that the agile methodologies (more specific, extreme
programming), while often successfully practiced, are controversial in the software
world. In the following sections, the description focuses on the pro arguments for
respective methodology and its practices. For a more comprehensive discussion about
the use of agile methodologies, the numerous books on the different methodologies
are considered a pro source of information, as are Cockburn’s academic papers
[Cockburn2003], while for example [Stephens2003] and [McBreen2003] are
prominent critics.

"# $
Extreme programming (XP) was founded by Kent Beck and has been around for
about ten years. XP is formed around a dozen of core practices that as a whole
describes the different phases of a complete software development process with
emphasizes on the core values of simplicity, communication, feedback, and courage.

XP is simple but constrained: It is deemed suitable for small (2-12 persons) co-located
teams, providing solutions that should fit in a rapidly changing or uncertain
environment. What is more, XP depends heavily on testability for the developed

The whole team. XP defines two mandatory team roles, the customer role and the
supplier role. The customer role is an important part of the co-located development
team and is responsible for the requirements and the project steering. Additional roles
such as testers, coaches or managers might very well exist within the project but are
not mandatory, and what is more important, these are typically not assigned to one
person but shared among the team members.

The planning game. At the start of each two-week iteration, a planning game session
is conducted. The outcome is an up to date but coarse overall project plan, and a more
detailed plan for the following iteration. The planning game concept consists of two
separate practices:
• Release Planning aims to produce or update the tentative plan that covers the
full project scope. The customer provides user stories that describe
functionality using enough detail for rough cost estimates. Using the cost
estimates provided by the developers combined with knowledge about the
relevance of each story the customer develops a plan indicating what features
should be in each release.
• Iteration Planning aims to refine the subset of the release plan that is relevant
for the following iteration, depending on the current status and priorities. The
customer role in iteration planning is similar to that of release planning, but
the developers provide more detailed, on a task level, cost estimates. When the

The information related to XP is gathered from [XP1] and [XP2].

- 33 -
customer is satisfied with the user stories contained within the release, each
developer is assigned a number of tasks that roughly equals the amount of
work she accomplished during the previous iteration.

These practices are simple, but in combination with the very short iterations, they
provide powerful steering as well as accurate progress metrics. Another important
practice in the context of planning is the use of spike solutions – the simplest possible
solution that verifies that an approach or technology will work – to evaluate concepts
and minimize risk related to difficult design decisions.

Customer tests. Along with user stories, the customer defines acceptance tests that
verify the functionality. The team develops the tests that are thereafter run frequently
using an automated test system, and thus continuously injects high quality feedback
and provides a highly relevant progress metric. The team strives to have all developed
tests running flawlessly at all times; the system is only allowed to become better,
never decline.

Small releases. At the end of each two-week iteration, running, tested software is
released to the customer. The customer gets access to the functionality she specified
as most important two weeks ago, and is given the opportunity to distribute and
evaluate the new version, and contribute high quality feedback to the development

Simple design. Design is considered a continuous activity in XP, as is requirement
gathering and refinement. Because a simple design is easier to improve than a
complex one, no solution is more complex than what is absolutely necessary. All
members of the development team are aware that changes in the requirements and the
design is likely, and that it is impossible to predict where a more complex solution
will later be necessary.

Pair programming. All production code in a XP project is written by two
programmers, which are both working on one computer. The obvious benefits of pair
programming are that all code is “peer reviewed” while it is written and that, by
moving people around, knowledge that would otherwise have been specialist,
propagates in the organization. What might not be so obvious is that two persons pair
programming is in general more productive than they would have been together if
they where not pair programming [Kessler2000].

Test driven development. In an XP iteration tests has a major role; before any actual
development is undertaken a set of tests that verifies the functionality are developed –
what is not tested does not exist. The actual testing is automated, and tests are run
many times a day. The approach have numerous benefits: It helps programmers
understand the task at hand before development, it leads rather effortlessly to nearly
100% test coverage and during re-designs, developers can verify their efforts using
the old test case and alterations to previously existing functionality will be
automatically verified.

Design improvement. The simple designs and the supporting tests make it possible to
undertake design improvements when needed, with a minimum of risk and effort

- 34 -
spent on verifying the changed code. The process of doing so is an integral part of XP
referred to as re-factoring.

“The re-factoring process focuses on removal of duplication (a sure sign of
poor design), and on increasing the "cohesion" of the code, while lowering the
"coupling". High cohesion and low coupling have been recognized as the
hallmarks of well-designed code for at least thirty years.” [XP1]

Continuous re-factoring maintains a simple design while the system complexity
grows, and thus helps to keep the development speed high.

Continuous integration. Integration of contributed code is typically done several
times a day, unveiling design flaws in interfaces between components and
functionality omissions that are not covered by the programmer’s tests. Continuous
integration also allows developers to carry out development in the most up to date
code-base available.

Collective code ownership. Traditionally, the person who originally developed a
piece of code “owns” it, and the owner is the only person that is allowed, and has the
knowledge, to make changes. In an XP team, any pair of programmers is allowed,
encouraged, and have enough knowledge, to change any code. Since developers
depend on each other’s code, collective ownership is an easy way to increases code
quality and reduces defects. Continuous testing and pair programming are
mechanisms that make it near risk free to allow this, even in large projects where it is
not possible to have full knowledge about code that someone else wrote.

Coding standard. A coding standard describes mainly how the code should be
formatted. This facilitates readability and support collective ownership.

System metaphor. A good system metaphor helps the team remember the nature of
the system. This basic understanding should be reflected in naming conventions and
documentation. Variable and class names should be given a context by the system

Sustainable pace. XP advocates normal workweeks and overtime only when it is
absolutely necessary. Benefits are expected in code quality, creativity and

As mentioned above the “Crystal” family of methodologies is rooted within the
academia, and thus based on an extensive theoretical foundation. Even if the research
is focused on software development, it contains many results of general interest, some
of which will be covered here. For the complete thesis, please see [Cockburn2003].
The description can be divided into two parts, of which the first will present results
related to methodologies and development teams in general, and the second will
provide a brief overview of the “crystal clear” methodology.

- 35 -
Cockburn stresses that different projects need different methodologies, there is no
single methodology suitable for all projects; an optimal agile methodology is one that
is minimal but sufficient [Cockburn2000]. Furthermore, he categorizes methodologies
and projects using staff size, system criticality and optimized quality as main
parameters. A number of other factors do also have an impact, such as team member

Four principles for categorizing a project are purposed [Cockburn2005:2]. These
provide a meritorious description of the tradeoffs involved in any team based effort,
and are outlined below.

Principle 1. A larger, as in more control elements, methodology is needed when more
people are involved.

Communications load
Effectiveness per person

Methodology size

Number of people involved

Figure 7. As the number of team members increase, the efficiency per person decreases,
communication becomes more demanding and a larger methodology is needed to ensure progress
and control. (Figure adapted from [Cockburn2005])
Principle 2. More publicly visible correctness (greater density) is called for on a
project with greater criticality, where more damage can result from an undetected

Principle 3. Weight is cost: a relatively small increase in methodology size or specific
density adds a relatively large amount to the cost of the project.

Heavyweight methodology
Number of people needed

Medium weight methodology

Lightweight methodology

Problem size

Figure 8. Communication burden increases with team size and lightweight methodologies uses
more informal communication, as a result, lightweight methodologies requires fewer people to
accomplish a task than heavyweight methodologies. (Figure adapted from [Cockburn2005])

- 36 -
Principle 4. The most effective form of communication (for the purpose of
transmitting ideas), is interactive, face-to-face.

2 People at

Communication efficiency

2 People on
2 People on
Audiotape Paper

Form of communication
Figure 9. Communication efficiency, for transmission of ideas. (Figure adapted from

The four principles are a small part of the foundation from which Cockburn presents
an important subset of his results in [Cockburn2005]:
1. Different projects need different methodology trade-offs.
2. Larger teams need more communication elements.
3. Projects dealing with greater potential damage need more validation elements.
4. A little methodology does a lot of good; after that, weight is costly.
5. Formality, process, and documentation are not substitutes for discipline, skill,
and understanding.
6. Interactive, face-to-face communication is the cheapest and fastest channel for
exchanging information.
7. Increasing feedback and communication reduces the need for intermediate
8. Concurrent and serial development exchange development cost for speed and
9. Efficiency is expendable in non-bottleneck activities.
10. "Sweet spots" speed development.

- 37 -
Based on the results, a methodology selection matrix for the methodologies in the
crystal family is presented:
Optimized for ...
Optimized for traceability
Optimized for productivity
(Defect causes loss of…)



money (E)

money (D)


1-4 6-20 20-40 50-100 100-200 200-500 500+

Number of people involved +- 20 %
Figure 10. Crystal methodologies selection matrix. (Figure adopted from [Cockburn2005])

The crystal family of methodologies, of which the “clear” variant is located in the
lower left corner in the figure above, prioritizes [Cockburn2005]:
• Safety in the project outcome,
• Efficiency in the development, and
• Habitability of the conventions.

To steer towards these priorities, seven properties to strive for are proposed in the
crystal clear case. Most of these are generic for the crystal family. The first three are
mandatory and the remaining four are recommended as they increase safety margins.

Frequent delivery is the first, and the single most important property. By delivering
demonstrateable software frequently, the team can expect the following advantages

• The sponsors get critical feedback on the rate of progress of the team.
• Users get a chance to discover whether their original request was for what
they actually need and to get their discoveries fed back into development.
• Developers keep their focus, breaking deadlocks of indecision.
• The team gets to debug their development and deployment processes, and gets
a morale boost through accomplishments.

- 38 -
Reflective improvement is about reflecting on the past and draw conclusions on hoe
to improve in the future. Time dedicated to the shared act of reflection (compare to
debriefings and postmortems) allows analysis of what was positive as well as not so
positive about the past and provides a necessary, triggering, incitement towards
change and improvement. Processes, individual behavior and other factors should be

“Osmotic communication means that information flows into the background hearing
of members of the team, so that they pick up relevant information as though by
osmosis.” [Cockburn2005] Osmotic communication is normally achieved by having
team members share the same room, and establishing a mood where it is natural that
members either tune-in or tune-out on a discussion or question. Osmotic
communication requires a co-located team (that is thus a requirement for the “clear”

Personal safety guarantees that all team members feel that they can talk to each other
about things that bother them.

Focus is characterized by that project organizations as well as the enterprise have
well-established missions and priorities, and that the organization is allowed to work
towards these.

Easy access to expert users makes it possible for the team to get direct and
continuous feedback on design decisions and the quality of ongoing work. Expert
users also provide the development team with live requirements.

A technical environment with automated tests, configuration management and
frequent integration materializes state of the art tool usage for both development and
deployment. In the section that describes extreme programming a more in depth
discussion on these concepts is provided.

Following, a set of strategies and techniques that, depending on the team, might be
useful in the efforts to achieve the seven properties are presented.

At the start of a new project a Crystal projects typically conducts an activity called
Exploratory 360°, where various aspects about the project, such as business value,
requirements, technology, team makeup, and process or methodology are
investigated. The exploratory 360° activity is somewhat similar to a traditional pre-

Preferably, early in the project the team can benefit from an Early Victory that
strengthens the team’s self-confidence and commitment. In the software case, an early
victory is typically running code that proves an uncertain technology choice or

One example of an early victory is a Walking Skeleton, a minimal implementation
that demonstrates an end-to-end function, proves the concept, and is demonstrateable.

- 39 -
From the walking skeleton and onwards, the system will need Incremental Re-
architecture to reach production quality. The background and benefits of using an
incremental approach to architecture are that, similar to the XP approach, the simplest
possible solution is the easiest to understand as well as the easiest and least risky to

To distribute key information about the project, such as progress, Information
Radiators are used. The information radiator is a large, visible information spot
(whiteboard, paper etc) that is continuously updated with information that team
members are interested in. A few other examples of information that could be
distributed this way are work assignments, number of passed tests or system models.

Methodology Shaping is an interview-based technique where information about team
member’s experience is collected and used as a foundation for shaping an initial
methodology for the project.

Reflection Workshop is a particular workshop format for reflective improvement.

Blitz Planning is a collaborative approach to relatively short term planning where
participants use cards that represents task and organizes these into a plan.

Delphi Estimation is a procedure to render estimates for a total project, in a more
sophisticated fashion than divide and guess.

Daily Stand-ups are daily meetings with a focus on distributing key information in
short time.

Agile Interaction Design is a design technique for usage-centered design.

Process Miniature is a technique that lets team members gain experience on a
process by running a complete but small, for example one day, mini-project.

Side-by-Side Programming has similarities with pair programming, but is less
intense. Instead of two persons working together on one workstation, side-by-side
programming involves to programmers working on separate workstations and on
separate code. They are however seated close enough to easily read each other’s
screens and discuss issues.

Burn Charts are time-functionality diagrams representing both planned and real
progress, similar to earned value diagrams.

A Crystal project is composed of iterative cycles including planning, development,
integration and reflection, similar to the other two described methodologies. The
Crystal Clear methodology description do also contains roles.

- 40 -
' #
James A. Highsmith21 describes an agile approach to software development from a
project management and market/supplier perspective in his book Adaptive Software
Development [Highsmith2000].

“Adaptive software development is a framework of concepts and practices
targeted for extreme projects”
“[The book] treats projects in a specific quadrant, projects that stretch the
limits of achievement, demanding both high speed and high change. That is, in
an environment where fundamental assumptions of decreasing returns,
equilibrium, and deterministic dynamics have to be replaced by increasing
returns, instability, and an inability to determine cause and effect.”

Even if Highsmith foremost targets software development it is interesting to note that
he, seemingly interchangeably, often uses the term “product development” to describe
the context where the practices are put to work. The connection between software
development and product development is important, and elaborated on in the
following sections.

Three different parts constitutes the described framework; the adaptive conceptual
model, the adaptive development model and the adaptive management model – where
the conceptual model:

“Formulates the mental model, the mindset, needed to effectively utilize the
development and management models.”

This summary will focus on the first two models, and do to a large extent follow the
outline of [Highsmith2000]. Citations are from the same source unless otherwise is

The theory behind the conceptual model is based on the research field of complex
adaptive systems (CAS), which provide explanation models relevant for a wide range
of scientific areas where traditional approaches have proved insufficient, such as
studies of economies, ecologies, weather, traffic, social organizations and cultures
[Dooley1]. The key components in a CAS are independent agents;

• who interact to create an ecosystem,
• whose interaction is defined by the exchange of information,
• whose individual actions are based on some system of internal rules,
• who self-organize in nonlinear ways to produce emergent results,
• who exhibit characteristics of both order and chaos, and
• who evolve over time. [Highsmith2000]

A. k. a Jim Highsmith

- 41 -
The CAS theory is used to describe markets and software development organizations
as complex environments. Notable is that in complex environments:

• “Adaptation is significantly more important than optimization.”
• “Emergence, characterized as arrival of the fittest, is significantly more
important than survival of the fittest.”

The concept of emergence is an important property of complex adaptive systems that
is applicable on both organizations and biological systems, and one the can be used as
an explanation model for how the total becomes larger than the sum of the parts when
multiple agents follow simple rules and thereby form complex patterns.

“Emergence is similar to innovation, problem-solving, and creativity; we have
a difficult time understanding how they happen, but the results are clear.”

The concept22 is efficiently illustrated using examples:

“Every great athlete, at some point, experiences being “in the zone”. Probably
the most famous example of this is Michael Jordan. When Jordan elevated his
game, the Chicago Bulls were nearly unbeatable. The same phenomenon can
be at work in product development. For example, in The soul of a new
machine, Tracy Kidder tells the story of a team of computer developers who
were in the zone – Kidder calls it a ‘groove’ – and who functioned as a team
that elevated its game to a level few outside the team thought possible.”

The next two relevant questions posed are related to the complex adaptive system:
What is a complex adaptive system and what are the characteristics of the
environments in which complex adaptive systems live?

John Holland addresses the first question [Holland1995]:

“A CAS is an ensemble of independent agents, who exists at multiple levels of
organization, who anticipates the future, and who form groups that occupy
diverse niches”.

The answer to the second question lies in a broader context; three different types of
environments are discussed within CAS theory [Highsmith2000]:

• The orderly,
• the chaotic, and
• the complex environment.

The orderly, or stable, environment is characterized by equilibrium; change is slow,
linear approximations are adequate and cause and effect can be observed. The chaotic
environment on the other hand can, for any practical purpose, be described as random.
The complex environments exist between these two, at “the edge of chaos”

Similar experiences are described as “flow” by [Csikszentmihalyi1990]

- 42 -
Residing on the edge of chaos is difficult but awarding balancing act, and an act that
plays a central role in the adaptive software development (ASD) methodology:

“Success goes to those who can hold anxiety, who can attune themselves to
paradox and uncertainty, and who can sustain creative tension. Innovation,
creativity, and emergent results are born in the transition zone at the edge of

It should be noted that the terminology used within CAS theory makes a clear
distinction between the words complex and complicated – a complicated project or
product is not necessarily a complex one.

Participants in extreme projects face yet other challenges that ASD aims to target, two
of them are mentioned in the above description of an extreme project; high speed and
high change. It is argued that a high speed of development is relatively easy while
frequent and high impact changes is the real challenge, and it is concluded that
success depends on methods and tools that; focuses on the results, the work-state
rather than the workflow, and that supports self-organization across virtual teams.
Furthermore, that:

“[The] structure of an organization’s collaborative network has significant
impact on its ability to produce emergent results and ultimately to its very
ability to adapt.”

Specifying the mission of the development endeavor
The adaptive development model is centered around a lifecycle that consists of work
states that focuses on speculation, collaboration and learning respectively, combined
with focus and de-focus cycles. The development cycle is iterative, cycling across the
work states in direction towards a carefully developed and well-established mission
description – the mission statement serves as the team’s compass in an uncertain

The mission statement consists of three different documents that answers basic
questions about the project and servers as a prioritization and decision making
platform; the project vision, the project data sheet and the product specification
outline. The level of detail within, or the format of, these artifacts are not formally
stated, the overall contents and purpose on the other hand are.

The project vision document should provide a summary of the business objectives,
product specification and market positioning and function as the foundation on which
to build the team’s commitment and set the focus. It typically contains a subset of the
following [Highsmith2000]:

• Project background
• A short project vision statement [Moore1991]:
1. For (target customer)
2. Who (statement of the need or opportunity)
3. The (product name) is a (product category)
4. That (statement of the key benefit – that is, compelling reason to buy)

- 43 -
5. Unlike (primary competitive alternative)
6. Our Product (statement of primary differentiation)
• Project scope
• Executive sponsor
• Product market positioning
• Internal and external customers
• Business functional objectives
• Technical performance objectives
• Project risks
• Staffing requirements
• Constraints
• Assumptions

The project data sheet contains an extremely distilled summary of the most important
aspects of the project and serves as a thumbnail description of the project for external
spectators as well as a focus guide aiding the project members. The following details
should be mentioned in the PDS [Highsmith2000].

• Clients/Customers
• Project objective statement
• Features
• Client benefits
• Performance/Quality attributes
• Architecture
• Issues/Risks
• Major project milestones
• Core team members

The Product specification outline provides the details necessary to get a good
overview of features and functionality, establishing project boundaries, and thereby
provides the foundation for refined iteration planning.

The three documents are however merely tools in the aim to establish a common
vision for the team and commitment toward the same target. Developing the
documents is considered easy in comparison with actually implementing them:

“Writing a mission statement is easy. Creating a sense of shared responsibility
for achieving the mission is very difficult. Building a shared vision in an
ongoing, never-ending, collaborative team effort.”

- 44 -
The Speculate-Collaborate-Learn Lifecycle
The adaptive development lifecycle consists of three overlapping phases, mindsets or
work-states: Speculate, collaborate and learn. Each iteration starts with what would
traditionally be referred to as planning – the speculation phase. The process flow is
outlined in figure 7.

Learning Loop

Project Adaptive Cycle Quality Final Q/A and
Initation Planning Review Release

Speculate Collaborate Learn

Figure 11. The adaptive life cycle, note that “learning” is used instead of “feedback”, indicating
that signals, deviations and a reference does not exist in their traditional meaning. (Figure
adopted from [Highsmith2000])
Knowledge about the characteristics of the overall adaptive development cycle is
essential to the understanding of the following sections that describes the work states.
The following paragraphs provide a brief overview.

First, adaptive cycles are mission-driven. The mission establishes the boundaries and
the direction for the project and the team has to explore the solution space, learn about
it, and refine vision of the projects outcome as it proceeds.

Second, adaptive cycles are component based. Components are sets of for example
related product features, similar to the module concept used in previous sections, and
are the most important measurement element in an adaptive plan even if traditional
tasks are also used. The usage of components facilitates context understanding and
gives a better picture of the product than a task-based approach.

Third, adaptive cycles are iterative. Iterative development is considered the most
rational approach to software development when the goal is uncertain and
requirement changes are frequent, even if a waterfall approach might be more
efficient the other case; when the goal is certain and the environment is stable.
Iterative development differs from sequential development notably in the mental
model that prevail within the project – redoing is more critical than doing and change
requests are considered positive – they are learning opportunities that guide the
project stakeholders towards a mutual product understanding. The greatest fear with
iterative development is that the development will start to oscillate without progress
rather than cycle towards a final solution that satisfies both the customer’s and the
developer’s requirements.

Fourth, adaptive cycles are time-boxed. The difference between a time-box and a
deadline lies mostly in our perception; a deadline is typically associated with a
specification of what that should be finished at the given time while a time-box

- 45 -
merely specifies what will happen23 at the specific date. Time-boxes are used to force
hard trade-off decisions, solution convergence and stakeholder learning.

Fifth, adaptive cycles are risk-driven and change-tolerant.

“Teams using adaptive software development assume that many aspects of a
project will change during the development. […] Creating change-tolerant
software – that is, software that is maintainable, enhenceable, and modifiable –
is a goal of adaptive software development.”

Furthermore, iterative developments strive towards minimizing risks by identifying
and eliminating them early.

The Speculation Work-state
Adaptive planning is formed around the three different types of iterations included in
the development model; the version loop produces a new rendition of a product, the
cycle loop produces a demonstrateable portion and makes the progress visible to the
customer, and the build loop produces interim portions of the product and make the
progress visible to the development team.

Adaptive cycles are planned using the following steps:

• Conduct the project initiation phase.
• Determine the project time-box.
• Determine the optimal number of cycles and the time-box for each.
• Write an objective statement for each cycle.
• Assign primary components to cycles.
• Assign technology and support components to cycles.
• Develop a project task list.

The Collaboration Work-state
Highsmith’s initial disclaimer on collaboration is that while collaboration is important
for the success of a team undertaking a demanding endeavor, collaboration is not a
“silver bullet” that can replace skilled individuals. On the other hand, it is claimed that
the myth of individualism24 makes collaboration more difficult.

Four different team descriptions are used, from [Constantine1995], and it is concluded
that while the “breakthrough model” would work for small adaptive projects, driven
by small co-located teams25, the “open model” is in general the most appropriate for
two reasons; its organizational scalability and its ability to take on a complete product
development cycle:

• Traditional hierarchical: The territory is familiar, sufficiently predicable, and
the requirements are reasonably well known.

E.g. delivery, customer presentation etc.
“The myth of individualism”, the “mythology of self” and the “self made man” are concepts deeply
rooted in our culture.
Note the similarity to the XP approach,

- 46 -
• Breakthrough: The project must develop a major innovation. Breakthrough
project environments are chaotic, random, and iconoclastic, and the project
structures can become very unstable as they get larger.
• Synchronized: The project’s success is dependent on shared vision and
common values. “The key to effectiveness … is full commitment by all
members to a sufficiently complex and well articulated vision of the mission
and methods of the group”. We often think of Japanese teams as well
• Open: The territory is turbulent and fluid. Success requires an open-ended,
flexible approach. “Adaptive collaboration is tailored for technical problem-
solving … what is important in this view of projects and progress is the
adaptive fit between how the team is working and what it is they are working

Collaborative groups are built around mutual core values; mutual- trust, respect,
participation and commitment. Mutual respect means that group members value
others contribution at all times.

Mutual trust the platforms for mutual trust are: honesty, groups members tells each
other the truth; safety, opinions are freely voiced; and dependability, group members
accomplishes assigned tasks.

Mutual participation allows all members to participate in an effort, even if their
participation is mutual rather than equal, and thus fostering diversity of ideas, which
leads to innovation.

Mutual commitment means shared as well as individual responsibility and ownership
in the product. Commitment to the mission, to the customer, to each other and to
oneself is the target and it is important to remember that:
“People perform work assignments while they volunteer commitment”.

The collaborative group’s main role in adaptive development is to create an
environment where emergent outcomes occur. Three main obstacles in the strive
towards successful such teams are considered the myth of individualism, the mental
model of survival of the fittest and the inefficient use of improved techniques,
practices and tools for group interaction.

The mood of successful collaborative groups is described as aggressive and

“[Successful collaborative groups are characterized by:] Behavior that is rough
and tumble, loud, argumentative, full of fiery passion, and enlivened by flaring

This description is expanded to include the Groan Zone; after divergent ideas have
been articulated, the group enters the groan zone in a strive towards sustainable
convergence. Adaptive teams groan a lot and it is not always a pleasant process, most
often however, sustainable progress is made.

- 47 -
The core values, the individuals and the management as well as the involved benefits
of success are keys to, and driving forces behind, efficient collaboration, where
modest consensus solutions and endless discussions are avoided. When a
collaborative group have formed, the challenge to keep it collaborate starts. In the
strive towards balancing on the edge of chaos, five control parameters for networks of
people, adopted from [Stacey1996], are presented:

• The rate of information flow. A risk in fast-moving industries is that of
overwhelming speed of information flow (speed rather than density). To
overly restrict the information flow from a management perspective takes
away one of the driving forces for emergence. Efficient communication is a
key to coping with high speed of information flow.

• Richness of connectivity is described as the number of connections between
people or groups and the type of data flow.
“Connectivity is a function of both content and context, content comes
from the data while context comes from the information and
experiences that help the recipient interpret and understand the data.”

• Level of contained anxiety. The characteristics of complex environments
create anxiety in most people.
“By containing anxiety rather than trying to eliminate emotional
distress we use it to our advantage. […] Innovative groups seem to be
able to balance on the precipice, without becoming either comatose or

• Degree of power differentials. To what extent managers delegate
responsibility, or allow team members to take on responsibility, is an
important control property:
“Exercise of power should be a balancing act – too little exercise of
power leads to confusion and endless consensus-building, while
excessive use of power restricts collaboration.”

Collaboration does not only involve the team, but also the stakeholders. A technique
worth to mention is Joint Application Development sessions, which are defined as:

“[A JAD session is a] facilitated workshop that brings together cross-
functional groups to build collaborative relationships capable of producing
high-quality deliverables during the life of a project.”

It is argued that collaboration is the best tool for dealing with high-change
environments. First, such environments require multiple individuals to manage
information, communication, decisions and changes. Second, the collaborating team,
and the nature of how individuals work within an adaptive organization, provide the
stable platform needed for solace and re-stoke.

- 48 -
The Learning Work state
Two types of learning are considered, the first type is described as enhancement,
maintenance, adhering, single loop, technical/task and training while the second as
anticipative, double-loop, innovative, proactive, and transformational. The first type is
in this context described as learning about things, and the second as learning about
oneself as person or organization26. Furthermore, a related distinction is made:

“Training is the acquisition of skills or information. Learning is an attitude.”

The core of the theory behind having a cyclic learning phase can be distilled into two
important points.

• “Success is not about what we know; it is about how we learn.” Traditional
organizations are poor at learning about them selves; and organizational and
personal self-awareness is considered another key factor, together with the
ability to collaborate, that facilitates adaptation to rapidly changing conditions.

• “Success is determined by the adequacy of the feedback, not by the accuracy
of the feed forward.” Traditionally relevant feedback and, associated re-doing,
is a result from deviations from the plan and a failure in the ability to predict.
Adaptive development has a focus optimizing accuracy and quality of
feedback, and thus, on re-doing.

Highsmith discusses two learning models, [Senge1990] and [Holland1995:2], and
continues with a number of practices, briefly summarized below, with the aim to
implement the learning models in an organization.

Customer focus-group reviews are facilitated meetings where customers explore a
working version of a deliverable, with developers present. The aims of a CFG
sessions is to render high quality feedback to the developers and to strengthen
customer-developer relations.

A software inspection is a collaborative defect identification technique where a few
developers inspect software targeting a specific class of defects. Software inspections
have been proven very efficient compared to other techniques with similar purpose.

Post-mortems are de-briefings where taken decisions are discussed and personal
feedback is given. In an adaptive development effort, post-mortems takes place after
each cycle with the aim to remove weaknesses in the next iteration.

The agile methodologies provide efficient techniques to put, often previously
theoretically well-established, principles into practice. Examples of this include close
customer collaboration, efficient communication and accurate capturing and
management of feedback.

Compare to Bloom’s learning domains; cognitive (knowledge), affective (attitude) and psychomotor

- 49 -
Additionally, they typically focus on feedback rather than feed-forward and re-doing
rather than doing. This facilitates continuous learning and design improvement within
well-established borders. As a result hereof, the traditional emphasizes on feed
forward processes is replaced with an intense focus on collaboration, communication,
skills and responsibility.

A common misconception about agile methodologies is that they ignore the benefits
of planning. Rather, agile methodologies advocate iterative plans that are realistic,
flexible and that focuses on deliverable items rather than anything else. This is a
deliberate choice, with the implications of the time-cost-function triangle in mind.

A similar awareness can be seen in other areas of agile methodologies. The
methodologists are aware of that too rigid (large and high density using Cockburns
terminology) methodologies are costly, and hence aim at balancing on the line where
just enough rigidity is used.

It is interesting to note the different focus of the three summarized methodologies.
While XP focuses heavily on procedures that rely on discipline and skilled individuals
to work well, Crystal Clear instead focuses on properties, and thus allows more
flexibility in team composition and methods used to achieve a good measurement for
each of the specified properties. A similar situation can be seen if the sensitivity of the
methodologies is studied: XP is likely to fail if any one of the more important
practices, for example automated test, cannot be made effective for some reason.
Crystal Clear and ASD are less sensitive. Similar to XP, a high sensitivity to
disturbances can also be suspected for most traditional methodologies.

Finally yet importantly, the agile methodologies takes into consideration that
engineers are in general professionals that are committed to their area of expertise,
willing to work hard and take responsibility for their work.

- 50 -
In the previous chapters it has been seen that the agile software development
methodologies provides sound techniques that could very well help to address some
of the major difficulties encountered during a mechatronic development process.

From this point: To be able to draw conclusions on agile methodologies within
mechatronics it is necessary to first have and idea about the context where they
possibly could be applied and, as a result, what their scope would be. Of course, these
questions lack generic answers; reality is much too intricate, and the methodologies
much too flexible, to allow that. Given the selected focus for the term mechatronics;
the focus on the characteristics of the complete system – the synergetic co-existence
of the modules – system engineering is relevant in the search for a context. On the
other hand, when it comes to the nature of the actual development, with the
characteristics assumed in this paper, a comparison with a typical product
development process is interesting. Even if the two are typically applied on problems
that differ slightly in their nature, the comparison between the two and agile
methodologies is fruitful, and allows mapping of critical aspects, as well as
identification of aspects that are not covered by a specific methodology.

Capability systems
User requirements Installation &
development definition validation
Core Product

ch Pro
ar po
ac s
Requ ser

Customer te ed

Supplier tic

System System
Integration & Integrated
development Requirements Architectural design
verification system
process definition
Prop ristics
Allocat ts

Components received




Components supplied
design, build &
Component design,build
design, build &
test &
test& & Components
development design, test

Figure 12 The customer-supplier system engineering process adapted from Stevens et al

The system engineering process builds upon multiple customer-supplier relations that
allow requirements, deliverables and feedback to be handled consistently within the
organization, and with clear interfaces towards the external customer. The process is
scaleable by the possibility to insert arbitrary number of system development
processes between the capability development and component development
processes, as shown in figure 9. This allows larger projects to use the model even if
the feasible number of abstraction layers is large.

- 51 -
Capability systems
User Program Installation
development requirements engineering and validation
Core Product




System Architectural Product Integration & Integrated
development requirements design engineering verification system

i on

Sub-system System Architectural Product Integration &
development sub-system
requirements design engineering verification sub-system

i on

Lower level sub-
system System Architectural Product Integration & Integrated
development requirements design engineering verification sub-system

Component Component sub-system
Component sub-system
development design, build &
process test

Figure 13 The layered system engineering model adapted from Stevens et al.
Studying the system engineering process leads to three observations.

• The system engineering and the agile methodologies (as presented in this
paper) targets projects of different size and different nature.
• Besides from this, the agile methodologies in large cover the same areas that
the system engineering process, nuances are present but the two are merely
different approaches to the same problem, and thus, that the two can be seen as
interchangeable in theory.
• The system engineering process is flexible and does not include practices on
the module level. In combination with the layering mechanism, from a system
engineering perspective, it is possible to consider using agile methodologies
for almost any subset of a development effort.

A typical product development process [Ulrich1995] covers a wider scope than the
agile methodologies, since areas such as marketing and preparation for mass
production are included. Stripped down however, similarities with both the system
development process and the agile methodologies can be seen, even if the focus is
different. It is relevant to note that the product development process outlined by
Ulrich and Eppinger is pronounced by the authors not to be intended for software
product development, but for products that are engineered, discrete and physical.

The product development process consists of five stages:
The concept development phase aims to identify market needs, generate and evaluate
conceptual solutions.

- 52 -
Next a system-level design is developed, covering product architecture, subsystem
partitioning, and functional specifications on the subsystem level.

The detailed design includes the complete specification of the product.

During the testing and refinement phase, prototypes are developed (sic) and

In preparation for mass-production, a product ramp-up phase concludes the product
development cycle.

Noteworthy is that Ulrich & Eppinger proposes a traditional approach to planning and
project management for the product development process.

Obviously, the system engineering and product development methodologies are both
relevant in the mechatronic domain. Yet, it can be argued that none of them covers
one-off mechatronic development in an optimal way.

The case against the system engineering methodology is that it is typically too
extensive for a small team, which is often considered an optimal setting, that it lacks
focus on product definition, and that it is sequential in its underlying nature even in its
concurrent or iterative variants.

The generic product development process on the other hand focuses on the product
definition and the optimization of the product concept; but targets neither software
intense products nor in house, one-off, manufacturing of products.

As a result hereof, it is sound to identify the methodological space where a specialized
methodology for mechatronic one-off development could exist. Such an approach is
shown in figure 10.

Software Development

Mechatronic Development

Product System
Development Engineering

Figure 14. The methodological space

- 53 -
The figure intends to illustrate several things:

• System engineering and product development are overlapping, typically both
disciplinary-wise and methodology-wise.
• Both software and mechatronic development exists to some extent within the
boundaries of the other two.
• Neither software nor mechatronic development is fully contained within the
boundaries of the other two.
• Software and mechatronic development share a common border in the figure,
which is a pedagogical construction that the reminder of this text is devoted to
prove correct.

- 54 -
, 0

The development processes for mechatronic- and software systems have many
similarities; both processes are intense in terms of design and collaboration, they have
been fostered as parts of young engineering disciplines, and both processes tends to
result in technically complex systems operating in complex environments, non of
which can be modeled or simulated accurately and completely. Furthermore, software
is often the integrating, and the most flexible component in its environment, and thus
the component that are most likely to be adapted when the environment or the
requirements change.

These similarities might not be unique for the two disciplines, but yet they are
relevant and the juxtaposition of the two serves its purpose – to identify methods that
are used in software methodologies and that could be beneficial in a mechatronic
development methodology

The requirement gathering process – its scope and feasible routines – depends greatly
on the nature of the development for any discipline or development effort. The range
from contractually specified requirements developed by the customer to product
development where a vision statement or vague idea might be the only initial
information requires drastically different approaches. Another important factor is the
amount of knowledge the parties have about each other’s businesses.

In absence of simulation it is, independently of the imposed nature of the development
effort, relevant to analyze the tangible uncertainty in requirements for the two studied
disciplines: Even if requirements are specified by the customer, they are likely to be
subject to re-prioritization depending on technology or solution choices, market or
environment development and knowledge build-up on both the customer and supplier
side. All these factors get more impact if the development ranges over a long period,
either due to a comprehensive development effort or due to multiple releases. In both
disciplines, obvious benefits can be seen in flexible requirement management.

The approaches taken by the different methodologies varies: while the agile
methodologies typically advocates close customer-developer proximity, informal
osmotic communication for incremental development of requirements and related
acceptance tests the system engineering process place distinct barriers between user
requirements and system requirements, that are both strictly documented and
traceable and advocates a near-serial approach. At least two main factors explains the
difference; for software, an unambiguous documentation of both user- and system-
requirements exists in the form of (test) source-code – and second – the system
development process typically targets larger projects, that might not be as easy to
partition into small modules as software is, as a result of modern programming
language design.

- 55 -
The sequential approach to requirements and design has obvious benefits when the
nature of the development allows it to be successfully applied. Critical factors towards
successful application of a sequential approach include:

• A reasonably stable environment
• A possibility to accomplish accurate and resource efficient design simulations
• Technology and design-space experience, both at the customer and the
developer side

For mechatronics and software, this is seldom the case. An approach with parallel
requirement and design processes are therefore often sound.

The impact of requirement changes is an important difference between the two
disciplines. That is, because hardware elements in mechatronics design are: 1) At
some point associated material costs and 2) often not developed and manufactured in-
house, and therefore subject to for example delivery times and market availability.
This dilemma can however be minimized by clever designs; implementing as many
change prone requirements as possible in software, and using as generic and flexible
hardware as possible.

Both software and mechatronic development includes a large share of design activity,
where the design as such is vital for the quality of the outcome, not only from a
customer or user perspective but also in terms of for example maintainability and
component reusability. As explained in previous chapters, any design activity is
difficult to plan and predict and benefits from continuous dialogue with stakeholders.
Furthermore, the quality of the overall design is typically not possible to evaluate
using simulations in the words traditional meaning.

Both disciplines are in their own sense modular by nature, mechatronics because of its
multidisciplinary characteristics, and software because modularization is supported,
encouraged, and often even cogent, by modern programming language and compiler
design. How the system is partitioned and how functionality is distributed across these
partitions have large impact on the quality of the design in both cases.

An important observation is that not all software is possible to modularize or
impossible to simulate, especially so within mechatronics where for example
embedded applications are often mentioned as a role model development effort. For
such systems it is not to be taken for granted that object oriented programming
languages are available. Another important case is that of motion control applications,
where mathematical models can be simulated and adjusted in a desktop environment
before auto-generated source-code is deployed on an embedded target system.

Even if the software development industry typically lacks practically useful tools for
simulation, the range of tools that supports development efforts in other ways is vast.
Areas well covered include requirement and deviation management, versioning,
version management, build and test automation, document generation, code
generation, debugging, profiling and code analysis. In the mechatronic case, the

- 56 -
mentioned tools are of course available for software development within
mechatronics, and yet other similar tools are available from a generic system
engineering perspective. It can however be suspected that such tools are not as
naturally introduced in a mechatronic engineering team as they are in software
engineering team.

What is more, various tools for modeling and simulation of mechatronic components,
such as motion control software, mechanical design and electronic design are
available, and methods that involve these are practiced with great benefits. Most
important however, simulation tools that can handle complete systems are generally
not available for neither of the two disciplines.

Collaboration is essential for most development efforts, so also for mechatronics and
software. Both have certain characteristics that reinforce the importance of
collaboration further; modular or multidisciplinary nature and unstable coupled

What is more, both disciplines are design focused, and as such benefits from close
collaboration with the customer and other stakeholders for knowledge transfer, design
decisions, changed requirements, prioritization and so on.

In the mechatronics case the multidisciplinary nature forces collaboration between
different engineering disciplines, which is complicated not merely because we are all
humans, but also because of differences in background, terminology, standards, tools
and techniques. In such settings, collaboration builds efficient cross-functional teams.

In the software case the same dilemma can often be seen, e.g. business software with
stakeholders within a large number of corporate functions.

In a previous section, describing the characteristics of software, it was explained why
software tend to be complex. In mechatronics, software is one of the major elements;
one that typically depends on several other subsystems to function, and in the other
direction, controls a number of other subsystems.

Software is not only complex but also flexible, and users, customers and developers
are aware of this. They use the knowledge to create increasingly flexible and powerful
products. In this strive; a large share of novel design and technology is typically made
used of in the solutions produced by the two disciplines.

These are a few of the aspects that render complex, or complicated, solutions that are
pushing state of the art, but are demanding and risk-prone from the viewpoint of all
stakeholders. One prerequisite towards minimizing the risks derived from complexity,
and a mean for building confidence, is efficient collaboration.

- 57 -
/1 ,
As has been shown in the previous chapters and compiled in the previous section,
software and mechatronics have much in common, and after all; software is one of the
cornerstones in mechatronics by definition. Beyond this, most similarities can be
derived from that the two disciplines are design focused, technology exploring and
collaboration intense.

The cornerstones of the three agile methodologies studied are slightly different sets
of, often well known, “best practices”, woven together as an entirety, that are made
use of consistently without adding more overhead than absolutely necessary; seamless
communication, near continuous feedback on quality and progress, frequent market
feedback, clear and well established aims and priorities and continuous verification
against requirements. This is made possible thanks to a high degree of automation, the
flexible nature of software, co-located small teams and customer availability.

Even if most of the principles and practices put to work by the agile methodologies
can alone be considered sound and rational, it is important to note that the benefits
from application of an incomplete set cannot be compared with the application of the
complete set without further analysis. The three described methodologies are based on
interacting practices, principles and values, and failure to implement one or a few of
them in a project setting might, in the worst case, render the approach far from
optimal. As mentioned elsewhere XP, and most traditional feed-forward
methodologies, are considered very sensitive for such disturbances, while Crystal and
ASD are extremely flexible in this sense.

That said, it has been shown that software and mechatronics have many important
characteristics in common, and that many of the agile concepts makes sense in the
mechatronic context, but the important questions are the ones stated previously:

Q1: Are agile methodologies feasible for software development in a mechatronic
Q2: Are any of the studied agile methodologies feasible for overall mechatronic
Q3: Would it, based on the ideas from the agile software methodologies, be possible
to design an agile methodology targeting mechatronic development?
Q4: If the answers to Q2 and Q3 are negative: Are individual concepts from agile
methodologies applicable in a mechatronic development context?

In the attempts to answer the first question, it is important to remember that software
as a part of mechatronic systems takes on many forms, ranging from low-level device
drivers in safety critical applications, via motion control software on embedded
systems, to graphical user interfaces in consumer electronics. In many, albeit not all,
of these development situations an agile development approach, possible tailored for
the specific situation, is definitely possible to use. Of course, it is important to keep
the limitations and focus of respective methodology in mind when studying it’s
applicability. Does the nature of the software to be developed, and the context where
it will be executed, allows continuous automated tests? Can a modern, self-

- 58 -
documenting and modular programming language be used? These are just a few
examples of case-to-case questions that need to be answered before a methodology is
designed or selected.

Yet another case-to-case question is if there are any benefits from using an agile
methodology. Given the broad spectra of the software used in mechatronics on one
hand, and the broad spectra of principles and practices contained within the agile
concept, the answer ranges from that application of agile principles can provide
significant benefits, to that application might very well be disadvantageous compared
to traditional approaches, even when deemed possible to use.

An example of the later is safety critical systems where minimization (or even
elimination) of defects is the most important, and vital, prioritization. On the other
hand, the mobile terminal case is considered a situation were a tailored agile
methodology could be very efficient; high pace and rapid and extensive changes due
to market expectations and hardware re-designs in combination with priority on being
the first actor on a competitive and expansive market to introduce new functionality.
On the other hand, the terminal case is also one where an obvious need to
systematically document requirements exists.

If XP is sensitive to such variations, the Crystal Clear and ASD methodologies are
designed to be flexible in that sense; focusing less on development details, and more
on the management and team level, they turn out to be more generic. This makes them
applicable in a broad scope of one-off development scenarios, including the ones
suggested by Q1 and Q2. These questions are therefore considered having a positive
answer, with reservations for that the methodologies might be incomplete or not
provide any benefits compared to a traditional methodology. This however must be
determined from case-to-case.

Even if these two methodologies are to some extent self-optimizing by nature, the
third question leaves room for complete optimization targeting mechatronics. A
methodology based on the agile principles, targeting mechatronics, could very well
have a slightly different focus and contribute new methods to the existing ones. Ideas
about the design of such a methodology do however require further research and are
beyond the scope of this paper.

- 59 -
2 ,
The importance of software within the mechatronic domain has been highlighted.
Based on this it has been argued that an efficient software development process within
the domain is an important competitive advantage, and that such a process needs to
target software specifically in any case, and software in a mechatronic context
specifically in some cases.

For this purpose, one category of methodology candidates has been studied, the agile
software methodologies, that in their nature are closer to a product development
process than a system engineering process.

A comparison between software development and mechatronic one-off development
have been undertaken with the aim to identify the similarities and differences between
the two efforts – both processes where identification of product characteristics and
requirements has an important role.

The results of the study can be distilled into a positive answer to the following three

Q1: Are agile methodologies feasible for software development in a mechatronic
Q2: Are any of the studied agile methodologies feasible for overall mechatronic
Q3: Would it, based on the ideas from the agile software methodologies, be possible
to design an agile methodology targeting mechatronic development?

Given that the mechatronic domain is broad, and that development efforts within it are
subject to radically different conditions, the positive answers are however subject to

First, different development efforts require different methodologies, and especially so
within a broad multidisciplinary area like mechatronics. Not all efforts that can be
sorted under the term mechatronic one-off development will be possible to undertake
using agile methodologies.

Second, the benefits derived from the usage of one methodology over another needs
to be evaluated on a case-to-case basis. Not all efforts will benefit from the usage of
one particular methodology.

- 60 -
- ,,
This paper is exclusively based on literature studies, and targets an area where little
research has been done previously. The results presented are therefore coarse, and
would benefit from refinement, expansion into contiguous development situations as
well as validation.

Given that the results can be validated by practical case studies, refinement with the
aim to identify the problem types where the usage of agile methodologies brings
benefits is purposed.

Second, evaluation of the benefits derived from the usage of these concepts, and
methodology optimization for mechatronics would be interesting.

- 61 -

[Cockburn2000] A. Cockburn, Balancing Lightweight with sufficiency, Cutter IT
Journal, December 2000, Volume 13, No. 12.

[Cockburn2003] A. Cockburn, People and methodologies in software development.
PhD thesis, 2003.

[Cockburn2003:2] A. Cockburn, Process: the Fourth Dimension, Humans and
Technology Technical Report TR 2003.02.

[Cockburn2005] A. Cockburn, Crystal Clear, 2005.

[Constantine1995] L. Constantine, Constantine on peopleware, 1995.

[Csikszentmihalyi1990] M. Csikszentmihalyi, Flow: The Psychology of Optimal
Experience, 1990.

[Grimheden2002] M. Grimheden & M. Hanson, Learning Mechatronics, Licentiate
thesis, 2002.

[GrimhedenEvo] M. Grimheden & M. Hanson, Mechatronics – the Evolution of an
Academic Discipline in Engineering Education.

[Hanson2001] M. Hanson, J. Wikander, M. Törngren, The science and education of
mechatronics engineering, 2001.

[Highsmith2000] J. Highsmith, Adaptive software development, 2000.

[Holland1995] J. Holland, Hidden Order: How adaptation builds complexity, 1995.

[Holland1995:2] John Holland, How adaptation builds complexity, 1995.

[Johannesson2004] H. Johannesson et al, Produktutveckling, 2004.

[Kessler2000] R. Kessler et al, Strengthening the case for pair programming, IEEE
Software, July/August 2000 (Vol. 17, No. 4), pp. 19-25.

[Kornby2005] Michael Kornby, Ericsson Review, The EMP Story, Volume 82, 2005.

[McBreen2003] P. McBreen, Questioning Extreme Programming, 2003.

[McConnel1996] S. McConnel, Rapid Development, 1996.

[Moore1991] G. Moore, Crossing the chasm, 1991.

[Petroski2002] Henry Petroski, Invention by design, 2002.

- 62 -
[Smith1991] P. Smith & D. Reinertsen, Developing products in half the time, 1991.

[Stacey1996] Ralph Stacey, Complexity and Creativity in Organizations, 1996.

[Senge1990] Peter Senge, The fifth discipline: The art & practice of the learning
organization, 1990.

[Stephens2003] M. Stephens, D. Rosenberg. Extreme Programming Refactored: The
Case Against XP, 2003.

[Stevens1998] R. Stevens et al, Systems Engineering, coping with complexity, 1998.

[Thane2000] H. Thane, Testing and Debugging of Distributed Real-Time Systems,
PhD thesis, 2000.

[Ulrich1995] Product design and development, Ulrich & Eppinger 1995.

[Waldrop1992] M. Waldrop, Complexity: The Emerging Science at the Edge of
Order and Chaos, 1992.


[Cockburn2005:2] A. Cockburn, A methodology per project,, accessed

accessed 2005-09-21.

[Dooley] K. Dooley,, accessed 2005-

[Fowler1], accessed

[Manifesto1], accessed 2005-10-20.

[SysML1] System modeling language,, accessed 2005-10-20.

[UML1] Unified modeling language,, accessed 2005-10-20.

[Wikipedia1], accessed 2005-07-11

[Wikipedia2] Rational Unified Process,, accessed 2005-07-15

[XP1], accessed2005-07-25

[XP2], accessed 2005-10-20

- 63 -
) /)3 +
1 ,
The following is a summary of an article describing the history of, and the success
factors behind, the mobile platform division at LM Ericsson AB. This article was
published in Ericsson Review, Volume 82 2005 p 41, The EMP Story.
[Ericsson Mobile Platforms (EMP) was established in worldwide. Six of the top handset manufactures use
2001, emerging from the R&D group that developed core mobile platforms from Ericsson.
technology for Ericsson’s mobile phones throughout the /…/
1990s. EMP provides terminal technology to customers EMP is the first company to provide commercially proven
who want to develop and produce mobile phones for the WCDMA, EDGE and GPRS platforms. This offers
GPRS, EDGE and WCDMA standards. significant benefits and synergies to customers who build
multiple products:
EMP develops extensive core technology in the form of • The key components are the same.
• integrated circuit design; • Applications can be reused with little effort
• platform software; because the development and test tools are the
• complete design of reference phones; and same.
• test software.] • Development lead-times can be shortened
Mobile phones have become increasingly complex since
the day of their introduction. As a consequence, only the /…/
largest mobile phone manufacture can currently afford to EMP offers a complete phone platform that contains all
develop and test the technology used in 2.5G (GPRS) and integrated circuits and software needed to build a GPRS,
3G (EDGE and WCDMA) phones. /…/ There are many EDGE or WCDMA phone. The platforms have passed
sources of technology for 2G phones, but only a handful of type approval testing and have been proven to work in
suppliers for 2.5G and 3G phones. every major network in the world. Because the platforms
/…/ provide all necessary system functionality (network
The biggest hurdle manufactures of 3G handsets must face access, data communications, and multimedia services)
is the development of technology. Besides supporting the they give customers a fast and safe way of launching new
latest functionality, the new handsets must also compete 2.5G and 3G products.
with mature 2G technology in terms of size, cost and
power consumption. EMP also offers extensive assistance with development
/…/ tools (development boards, software development kits, and
The role of operator businesses is evolving from provider integrated development environments), training,
of voice telephony to supplier of a variety of services that customization, industrialization, type approval, and
increase average revenue per user (ARPU). Examples of operator acceptance.
such services are downloadable ring tones and screen /…/
savers, SMS, MMS, and advanced data services such as e- A common system architecture supports every EMP
mail, web browsing and streaming. In the future they will platform. This architecture is continuously being evolved,
include downloadable music, digital TV, and other rich but special care is taken to maintain backward
content. Obviously, services of this kind call for much compatibility – a key requisite (for EMP and its
greater technical complexity in handsets and magnify the customers) is the reuse of prior investments, design
issue of interoperability between networks and other experience, interoperability testing, and software.
handsets. /…/
The system design (which continues to evolve) is based on
In addition, new functionality is being introduced in use-case analyses. /…/ The use-cases are broken down into
networks on a regular basis and new requirements for basic operations that can be quantified as real design
conformance type approval are added every three months. requirements around which the platform architecture is
Major operators must thus allocate significant resources to designed.
specify handset functionality and test compatibility. This
testing, in turn, can delay the introduction of new handsets The result is an architecture of five service stacks, similar
several months, resulting in loss of revenue both for the to the open system interconnection (OSI) reference model.
operator ad the handset supplier. A common abstraction layer serves the hardware; a layer
of common middleware services supports application
What is more, many operators are beginning to require that software.
the phones they sell contain their application software and Most of the components in EMP’s products are the same
sport a specific look and feel; that is regardless of supplier, regardless of the mobile standard they support. The only
all phones that target a given market segment must have differences are network access stacks and parts of the
the same capabilities and behaviour. hardware.
/…/ /…/
In a move to shore up and accelerate the development of In addition, customers need to be able to customize and
3G phones, Ericsson, the largest supplier of mobile differentiate their products. Therefore, EMP’s system
networks, is now making its 2.5G and 3G handset architecture allows for extensive changes to the reference
technology available to every handset manufacturer. EMP designs. Areas of customization include: Companion chip,
addresses the associated challenges and opportunities by external memory, video, 3D, dual OS, FM radio,
offering tried-and-tested 3G technology, services and synthezisers, stereo, camera, RF bands, low-cost memory,
training. security/DRM, dual displays, streaming and connectivity
/…/ (Bluetooth, IrDA, USB).
At year-end 2004, EMP had signed license and /…/
development agreements with fourteen customers New hardware, which has a long lead-time for EMP and
its customers, is usually introduced every 12 to 18 months

- 64 -
in conjunction with major software releases. EMP makes
the transition from one generation of hardware to the next
as easy as possible by retaining software compatibility
with customer applications. Customers may thus reuse past
past software investments to reach the market early with
new products.

To increase functionality, new software is introduced
every six months for each platform and customer
adaptation. In addition, EMP issues maintenance releases
every third month to coincide with mandatory network
functionality updates.

The release of a new platform or the revision of an existing
platform is a major undertaking in terms of development,
testing and logistics. In 2004, EMP released approximately
180 different customized platforms. Each release included
complete platform software, documentation, and an SDK.
EMP is unique in having a common code base for all its
reference platforms, regardless of whether the platform is
for GPRS, EDGE or WCDMA. This approach allows EMP
to develop and test all functionality once and then deploy it
across customer products. Every customer receives the
same functionality at the same time – and it has been
tested on target customer hardware. Error corrections and
changes are tested and implemented in the common code
base before they are deployed to customers in the
maintenance release.
The complexity of 3G phones is exemplified by the mind-
boggling amount of requirements specified for these
phones. In 2001, a GPRS phone had approximately 300-
400 system level requirements. By contrast, an advanced
3G phone has more than 6000 system level requirements
that must be understood and implemented in the platform.
Each quarter, EMP receives more than 5000 new
requirements from customers and operators.

The lead-time for complicated technology is often very
long. It typically takes 2-4 years to move from the
specification of a new integrated circuit to large volume
production. New software systems and architectures also
take 2-4 years to develop. Therefore, new requirements
must be captured as soon as possible. EMP does this in a
number of ways. [Active in standardization, close
cooperation with operators, customers and network
No product is complete without testing and verification.
The sheer size and complexity of modern mobile systems
makes it virtually impossible to develop standards and
specifications that are completely unambiguous and
consistent. In addition, to some extent implementation
errors are an inevitable part of all development work. As a
consequence, EMP follows a comprehensive test-and
verification process to ensure that the technology will
perform as expected in customer products. The cost of
rectifying an error increases dramatically in later stages of
development and production, so it is crucial to have a
complete strategy for testing at every level. EMP tests the
reference design in terms of design, integration, system
and customer-specific requirements.