Towards An Agile Methodology For Mechatronic One-off Development Final

! "

#

$%%&

Towards an agile methodology for mechatronic one-off development by Fredrik Jonsson [email protected]

!

!! $%%&' (&! )$&* KTH Maskinkonstruktion SE-100 44 STOCKHOLM

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 Sammanfattning 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 mekatroniksammanhang? 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å mekatronikutveckling? 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. -3-

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 Abstract 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 context? Q2: Are any of the studied agile methodologies feasible for overall mechatronic development? 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 limitations. 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. -4-

+

Towards an agile methodology for mechatronic one-off development Table of contents Acknowledgements Motivation for the study Terminology and abbreviations Terminology Abbreviations Problem definition Limitations Related work Outline of the paper The characteristics of mechatronics Quality of mechatronic products Requirements Architectural design and modularization Technical Integration A glance at trade-offs and requirement changes The role of software in mechatronics Simulation and modeling in mechatronics Collaboration The mobile phone development cycle The development of an industrial robot The characteristics of mechatronics – a short summary The generic characteristics of software and software development The agile approach to software development Extreme Programming The Crystal family of agile methodologies On methodologies The Crystal Clear methodology Properties Strategies and Techniques Development Process and Roles Adaptive software development, a methodology for extreme projects Conclusions on agile methodologies Application of agile methodologies in a mechatronic context The system engineering perspective Agile from the product development perspective The methodological space Results of the juxtaposition of mechatronics and software development Requirements Design and modularization Support Tools Collaboration Complexity Agile methodologies in a mechatronic context – discussion Conclusions Proposed future research References

-5-

-1-5-7-8- 10 - 10 - 10 - 11 - 13 - 14 - 15 - 16 - 17 - 18 - 19 - 19 - 20 - 21 - 22 - 23 - 24 - 24 - 27 - 29 - 32 - 33 - 35 - 36 - 38 - 38 - 39 - 40 - 41 - 49 - 51 - 51 - 52 - 53 - 55 - 55 - 56 - 56 - 57 - 57 - 58 - 60 - 61 - 62 -

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

-6-

- 62 - 63 - 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.

-7-

!

,

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 [Kornby2005]. 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 criticality. 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. 1

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

-8-

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

2

Rational Unified Process, [Wikipedia2]

-9-

++ The term software development is used to describe initial development or major redevelopment 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 massproduced, 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 systems." Cockburn’s definition in turn is an expansion of the definition in the MarriamWebster dictionary: “A body of methods, rules, and postulates employed by a discipline.”

! " $ 3

" $

#

!

! !

!

! !

!

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 organizations. 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 Q1Q4. 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 context? Q2: Are any of the studied agile methodologies feasible for overall mechatronic development? Q3: Would it, based on the ideas from the agile software methodologies, be possible to design an agile methodology targeting mechatronic development?

4

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

5

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]

6

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

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

Mechatronics

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 7

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 modules. 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 level requirements

Quality of architectural design

Quality of integration Quality of related deliverables (Documentation, education, configuration etc)

System level Module level Design of individual modules Quality of module Design of individual modules level requirements

Design of individual modules Quality individual Design of of individual modules module designs

Implementation of individual

Implementation of individual modules Quality of individual modules module realizations

Figure 2. Quality of a subsystem based, integrated system

8 It is important to notice that latent needs are often as important as explicit needs in determining customer satisfaction. [Ulrich1995] 9 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.

10

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 dimension. 11 Customer denotes users as well as other external stakeholders in this context. 12 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 crossorganizational 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] – subsystem 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 subsystem 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 design. 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 reprioritization 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 time. 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. 13

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

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

14 15

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

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.

16

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.

17

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

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 sourcecode 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.” [Stevens1998] 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]. 19

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.” [Stevens1998] 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 [Manifesto1]: 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 recommended. 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 solution. 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 20

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 team. 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 metaphor. Sustainable pace. XP advocates normal workweeks and overtime only when it is absolutely necessary. Benefits are expected in code quality, creativity and productivity.

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 proximity. 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 defect. 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.

Number of people needed

Heavyweight methodology

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 -

Communication efficiency

Principle 4. The most effective form of communication (for the purpose of transmitting ideas), is interactive, face-to-face. 2 People at whiteboard 2 People on phone 2 People on email Videotape

Audiotape

Paper

Form of communication Figure 9. Communication efficiency, for transmission of ideas. (Figure adapted from [Cockburn2005])

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 deliverables. 8. Concurrent and serial development exchange development cost for speed and flexibility. 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:

Criticality (Defect causes loss of…)

Optimized for ... Optimized for traceability Optimized for productivity Life (L) Essential money (E) Discretionary money (D) Comfort (C) 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 [Cockburn2005]: • • • •

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 considered. “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” variant). 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 prestudy. 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 similar. 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 Rearchitecture 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 change. 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”

and

“[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.” [Highsmith2000]

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 stated. 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; • • • • • •

21

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” [Waldrop1992]. 22

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 chaos.” 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 environment. 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 Initation

Adaptive Cycle Planning

Speculate

Concurrent Component Engineering

Collaborate

Quality Review

Final Q/A and Release

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.

23

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. 25 Note the similarity to the XP approach, 24

- 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 synchronized. Open: The territory is turbulent and fluid. Success requires an open-ended, flexible approach. “Adaptive collaboration is tailored for technical problemsolving … 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 on”.

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 passionate: “[Successful collaborative groups are characterized by:] Behavior that is rough and tumble, loud, argumentative, full of fiery passion, and enlivened by flaring egos”. 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 psychotic.”

•

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 crossfunctional 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. 26

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

- 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 development process

User requirements definition

Installation & validation

Operational support systems

Customer Supplier

Component development process

System Requirements definition

Architectural design osed Prop ristics cte chara

System development process

ed Allocat ts men require

Customer Supplier

U Requ ser irem tens

Core Product ch Pro ar po ac s te ed ris tic s

Component Component Component design, build & Component design,build build & Component design, test & design,build build test& & design, test test test

Integration & verification

Integrated system Components received Components supplied

Components

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 development process

User requirements

Program engineering

Installation and validation

Operational support systems

Fe

tio n

Core Product

ba

Pa rti

ed ck

System development process

System requirements

Architectural design

Sub-system development process

on

System requirements

Architectural design

System requirements

i rtit

on

Integrated system

Product engineering

Integration & verification

Integrated Integrated Integrated sub-system sub-system sub-system

Product engineering

Integration & verification

Integrated Integrated Integrated Integrated sub-system sub-system sub-system sub-system

Feedback

Pa

Lower level subsystem development process

i rtit

Integration & verification

Feedback

Pa

Product engineering

Architectural design

c ba ed Fe k

Component development process

Component specification

Component design, build & test

Integrated Integrated Integrated Integrated sub-system sub-system sub-system Components sub-system

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 evaluated. 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 Development

System 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 systemrequirements 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 inhouse, 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 environments. 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 context? Q2: Are any of the studied agile methodologies feasible for overall mechatronic development? 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 questions: Q1: Are agile methodologies feasible for software development in a mechatronic context? Q2: Are any of the studied agile methodologies feasible for overall mechatronic development? 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 limitations. 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, http://alistair.cockburn.us/crystal/articles/mpp/methodologyperproject.html, accessed 2005-10-20. [Colostate1] http://www.engr.colostate.edu/~dga/mechatronics/definitions.html, accessed 2005-09-21. [Dooley] K. Dooley, http://www.eas.asu.edu/~kdooley/casopdef.html, accessed 200510-20. [Fowler1] http://www.martinfowler.com/articles/newMethodology.html, accessed 2005-07-11 [Manifesto1] http://agilemanifesto.org/, accessed 2005-10-20. [SysML1] System modeling language, http://www.sysml.org/, accessed 2005-10-20. [UML1] Unified modeling language, http://www.uml.org/, accessed 2005-10-20. [Wikipedia1] http://en.wikipedia.org/wiki/Computer_science, accessed 2005-07-11 [Wikipedia2] Rational Unified Process, http://en.wikipedia.org/wiki/Rational_Unified_Process, accessed 2005-07-15 [XP1] http://www.extremeprogramming.org/, accessed2005-07-25 [XP2] http://www.xprogramming.com, 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. worldwide. Six of the top handset manufactures use mobile platforms from Ericsson. /…/ EMP is the first company to provide commercially proven WCDMA, EDGE and GPRS platforms. This offers significant benefits and synergies to customers who build multiple products: • The key components are the same. • Applications can be reused with little effort because the development and test tools are the same. • Development lead-times can be shortened significantly,

[Ericsson Mobile Platforms (EMP) was established in 2001, emerging from the R&D group that developed core technology for Ericsson’s mobile phones throughout the 1990s. EMP provides terminal technology to customers who want to develop and produce mobile phones for the GPRS, EDGE and WCDMA standards. EMP develops extensive core technology in the form of • integrated circuit design; • platform software; • complete design of reference phones; and • test software.] 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 develop and test the technology used in 2.5G (GPRS) and 3G (EDGE and WCDMA) phones. /…/ There are many sources of technology for 2G phones, but only a handful of suppliers for 2.5G and 3G phones. /…/ The biggest hurdle manufactures of 3G handsets must face is the development of technology. Besides supporting the latest functionality, the new handsets must also compete with mature 2G technology in terms of size, cost and power consumption. /…/ The role of operator businesses is evolving from provider of voice telephony to supplier of a variety of services that increase average revenue per user (ARPU). Examples of such services are downloadable ring tones and screen savers, SMS, MMS, and advanced data services such as email, web browsing and streaming. In the future they will include downloadable music, digital TV, and other rich content. Obviously, services of this kind call for much greater technical complexity in handsets and magnify the issue of interoperability between networks and other handsets.

/…/ EMP offers a complete phone platform that contains all integrated circuits and software needed to build a GPRS, EDGE or WCDMA phone. The platforms have passed type approval testing and have been proven to work in every major network in the world. Because the platforms provide all necessary system functionality (network access, data communications, and multimedia services) they give customers a fast and safe way of launching new 2.5G and 3G products. EMP also offers extensive assistance with development tools (development boards, software development kits, and integrated development environments), training, customization, industrialization, type approval, and operator acceptance. /…/ A common system architecture supports every EMP platform. This architecture is continuously being evolved, but special care is taken to maintain backward compatibility – a key requisite (for EMP and its customers) is the reuse of prior investments, design experience, interoperability testing, and software. /…/ The system design (which continues to evolve) is based on use-case analyses. /…/ The use-cases are broken down into basic operations that can be quantified as real design requirements around which the platform architecture is designed.

In addition, new functionality is being introduced in networks on a regular basis and new requirements for conformance type approval are added every three months. Major operators must thus allocate significant resources to specify handset functionality and test compatibility. This testing, in turn, can delay the introduction of new handsets several months, resulting in loss of revenue both for the operator ad the handset supplier.

The result is an architecture of five service stacks, similar to the open system interconnection (OSI) reference model. A common abstraction layer serves the hardware; a layer of common middleware services supports application software. Most of the components in EMP’s products are the same regardless of the mobile standard they support. The only differences are network access stacks and parts of the hardware. /…/ In addition, customers need to be able to customize and differentiate their products. Therefore, EMP’s system architecture allows for extensive changes to the reference designs. Areas of customization include: Companion chip, external memory, video, 3D, dual OS, FM radio, synthezisers, stereo, camera, RF bands, low-cost memory, security/DRM, dual displays, streaming and connectivity (Bluetooth, IrDA, USB). /…/ New hardware, which has a long lead-time for EMP and its customers, is usually introduced every 12 to 18 months

What is more, many operators are beginning to require that the phones they sell contain their application software and sport a specific look and feel; that is regardless of supplier, all phones that target a given market segment must have the same capabilities and behaviour. /…/ In a move to shore up and accelerate the development of 3G phones, Ericsson, the largest supplier of mobile networks, is now making its 2.5G and 3G handset technology available to every handset manufacturer. EMP addresses the associated challenges and opportunities by offering tried-and-tested 3G technology, services and training. /…/ At year-end 2004, EMP had signed license and development agreements with fourteen customers

- 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 mindboggling amount of requirements specified for these phones. In 2001, a GPRS phone had approximately 300400 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 providers] /…/ 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.

65

66