2.1 History
CESAM Agility is an agile model-based systems engineering framework, based both on real concrete applications & experiences in order to ensure practical applicability and on the CESAM model-based systems architecting framework (see [17] for more details). We already have defined the fundamentals of such a framework which, even if not fully formalized, was already used in several real development contexts in order to find quickly an optimal system that answers to all stakeholders’ needs. More specifically, we helped implementing since around three years several agile development loops in complex system development contexts such as automotive (e.g. development of new advanced driver assistance services), high tech (e.g. development of a new camera in Japan and of a smart site management system in China), energy (e.g. development of a smart energy distribution system) and aeronautics (e.g. mechanical engine design and manufacturing). In aerospace, the development of a new aircraft turbomachine was re-analyzed last year through a complete coarse grain agile loop achieved in 3 months: it allowed fixing the main known engineering and manufacturing issues through the understanding of the key relationships between product features and characteristics of the most important manufactured parts. A second experience at engine level confirmed the achievement of – 20 % of lead time, as experienced with the first project with the same customer.
Finally, we are working – since mid 2018 – within one of the key aircraft manufacturers in order to implement an ambitious transformation program at enterprise level, dedicated to the deployment through engineering, manufacturing and customer services of an agile development framework relying on model-based systems engineering. Note that these different experiences are of course confidential since they were all deployed on real development projects.
2.2 Key Features
2.2.1 Feature 1: Product / Organisation Alignement
Preliminary definition of a product reference architecture:
The first key element to enable agile engineering is an adequate product architecture. In this matter, it is key to construct first a generic reference product decomposition where the product is recursively decomposed into logical components which are as independent as possible from a functional & logical point of view. Such a decomposition will help reducing the functional & logical interfaces that are existing between product components, and consequently the issues linked to the concurrent design and the integration of these components. Such a generic reference product decomposition shall in particular contribute to amaximalist (“150 %”) high-level vision of the product of interest (or of a family of similar products if one is dealing with a product line approach) that include the definition of generic assets such as generic external & internal interfaces, generic needs and functional & constructional requirements, generic functional and logical architectures, etc.
Figure 1 – Reference functional-logical architecture of a single-aisle aircraft (Airbus A320)
An example of such a generic reference architecture – that we constructed on the basis of publicly available documentation – is provided in Figure 1 for an Airbus single aisle aircraft. Note that these reference architectures are key for providing a standard & shared way of presenting and analyzing different design alternatives when relevant. They are also a natural support for impact analyses, as far as they have a double functional and constructional nature.
Product / organisation alignment:
Based on the previous reference product architecture, a second key element towards agile engineering is the alignment of the multidisciplinary activities and of the generic reference product architecture. Organization shall indeed replicate the product architecture in order to provide the best agility all over the development process. Traditional activity organization is indeed often a source of tunnel effect due to the fact that teams are not functionally independent, not sufficiently autonomous and even sometimes too big to be mastered in an agile process. It is therefore often key to reorganize the development teams in order to mimic the reference product architecture in the organization.
As a consequence, a typical agile development organization shall be split into 2 – 3 or more layers according to product complexity and constraints. A typical 3 layers organization will for instance be decomposed into a system level, a sub-system level and a part level (this last one taking into account the part manufacturing constraints, typically for mechanical components). In this organization, each development team shall therefore be in charge of a unique component of the reference product decomposition of the product of interest, all components being covered by the different development teams. Note finally that one also has to identify “architects” that shall be in charge of synchronizing the development teams, both horizontally between the different disciplines and vertically between the different product layers. The resulting organizational model is illustrated in Figure 2.
Figure 2 – Agile organization resulting from a product / organization alignment
next pageTABLE OF CONTENTS
References
[17] CESAMES, CESAM: CESAMES Systems Architecting Method – A Pocket Guide, 134 pages, CESAMES, January 2017