A NAF-based proposition to leverage System Engineering change management in systems-ofsystems acquisition projects CSD&M 2015 Thomas RIGAUT
Description of the case Moving to Model-Based System Engineering is widely acknowledged as the key to make all stakeholders efficiently exchange technical data to better support their own activities. The case is even stronger in the context of systems-of-systems acquisition projects: diversity of stakeholders from different organizations, architecting at the center of engineering activities Strongest challenge of MBSE is making engineering team implement it into their projects and commit their stakeholders to create and exploit models.
Challenges to MBSE change management Besides overriding qualms into using new methods and tools, the main challenge of every MBSE change management strategy is defining who shall make the modelling effort, so that every stakeholder gets a return on his investment. In the context of design projects, modelling is a way to implement design activities of the specialty engineers. In the context of systems-of-systems acquisition projects, architecting models support study of architecting alternatives, description of operational need, specialty engineering analyses, follow-up of decision-makers objectives. Since architecture modelling supports architecting activities but don t implement them, return on investment is indirect and delayed in time.
Taking up the challenge In a systems-of-systems acquisition project context, taking up the MBSE change management challenge means: finding the right allocation of architecture modelling tasks between architects, specialty engineers, end users and their representatives and decision-makers; ensuring a return higher than the investment, for each stakeholder. ensuring a quicker as possible return on investment, for each stakeholder
How shall we build a solution to that challenge Any proposition to take up that challenge shall rest on: An analysis of which stakeholder provides each piece of data. An analysis of which stakeholder consumes each piece of data. A description of the tasks required to build an architecting referential able to receive from and feed such pieces of data to stakeholders. Our proposition consist in : defining a standard answer to these three issues based on the NAF standard; Giving architects guidelines to accommodate these standard answers to the context. Giving architects guidelines to make stakeholder consider MBSE as a way to provide them data they expect.
Standard answer provided through the NAF Four NAF aggregates to build one architecture referential: NPV/NCV to define high level objectives (decision-makers) NOV/NSV to define operational need from end users point of view (end users and their representatives) NSV/NTV to store design data and model alternative architectures (architects and specialty engineers). NAV & bridging views to organize modelling tasks and analyze the consistency of the architecture model (architects)
Prepare stakehoders to feed the referential Stakeholders shall be accustomed to near-to-naf concepts. Once shared, these concepts would be a common basis to feed the referential. Stakeholders are expected to provide taxonomies of architectural elements, but they should also be accustomed to standard graphical representations used in architecture modelling. With the help of SE tools experts, architects shall put up a NAF-implementing tool able to import these taxonomies and graphical representations.
Mechanism to feed the referential First simple guidelines are given to stakeholders: feed the referential with data you believe is relevant to the case. Second after a first round of feeding the referential, architects analyze data: he pinpoints consistency issues, blind spots, redundant pieces of data. Stakeholders are invited to give a look to the referential and indicate their interest for pieces of data relevant to their work. Basing upon these elements, architects would deliver a feedback to each stakeholder: what more data is expected from them? Who will exploit the data they produce? Who produces the same data? What consistency issues should he monitor, and with which stakeholder?
Levels of maturity to be reached during the change management First level of maturity: working groups are defined based on the feedback, so that stakeholders may develop synergies into producing data that is reviewed by architects. Stakeholders find and exploit data by reading the architecting model. Architects focus on ensuring consistency of data according to NAF metamodel. Second level of maturity: Deliverables are defined, that are generated from the architecting model. They are defined by stakeholders from their expectations, with the help of SE method and tools experts. Stakeholders directly feed the referential, in a configuration management context.
Exploiting the referential to feed the decisionmaking process A NAF-based architecture referential fed by stakeholders inputs is a strong basis to feed the decision-making process. Since high-level objectives (NCV/NPV) are traced to operational data (NOV/NSOV), then to technical data (NSV/NTV), the NAF-based architecture referential forms a skeleton to propagate performance evaluation from specialty engineering performance analysis and technical-operational scenarios simulation to high-level objectives. Key challenge for the architect consists in identifying whether the high-level objectives shall be reached by modifying architectural properties of the alternative (connectivity, proceeding of operational scenarios), or choosing another component for the design.
Defining workflows through modelling activities We have until now defined modelling activities of a system-of-systems acquisition project in a day-to-day way. To reach a higher maturity level in architecting activites, architects shall define development flows of the architecting referential and define which contributions are expected from each stakeholder in order to: Evaluate a new architecture alternative. Evaluate the impact of a specialty engineering issue on an architecture alternative. Evaluate how much a new operational need is covered by architecture alternatives. Prepare a trade-off dossier for descision-makers on a precise high-level issue.
Use case: example of synergy reachable at the first maturity level Dependability objectives Performance objectives Dependability evaluation Dysfunctional analysis Performance / Dependability trade-offs NSV/NTV referential: alternative designs Performance evaluation Components performance evaluation
Use case at the second maturity level Expression of executable representative scenarios used for simulation Performance evaluation through simulation CONOPS: technicaloperational scenarios Simulation of executable scenarios NCV : High-level objectives NOV referential: Operational scenarios NSV referential: Design alternatives Key technical characteristics Evaluation of high-level objectives satifaction level & trade-offs High-level operational scenatios (guidelines) Domain-specific performance & technological studies
Case study: structure the relation between the acquisition project team and the design team Our proposition extends to a case where most specialty engineers are outside the project acquisition team, and form a separate design team. Formally analyze who produces and provides which piece of data, and describe formally the tasks necessary to build a NAF-based architecting referential is an efficient way to externalize architecting activities to a design team. Yet formalize the first step of our proposition in a contract would prove uneasy (collect data, analyze consistency and provide feedbacks), so that to make the proposition work, this first step should be played inside the acquisition project team before contracting. It would allow to ensure stakeholders are ready to enter the MBSE workflow and validate their deliverable expectations before contracting.
Conclusion The author believe MBSE change management is a progressive activity that shall consider incremental maturity levels. The key is to prove on small perimeters to stakeholders they are to get a true return on investment; creating small synergies on these perimeters with assistance of SE methods and tools experts is an effective way to make slowly stakeholders override their qualms on MBSE. At the organization level, the main contribution to our proposition would be to stimulate and allocate resources to develop these small synergies.