Engineering processes are meant to sequence activities along intrinsic factors, as opposed to operational processes whose aim is to adapt activities to contexts. Whereas factors governing manufacturing processes depend upon the physical contingencies of material flows, the rationale behind software engineering processes is first and foremost governed by constraints on development flows, whose nature is essentially symbolic.
Development processes usually follow one of two schools: procedural or acrobatic. Procedural processes impose one-fits-all development frameworks and significant overheads to compensate for the misfits; acrobatic ones bet on responsibility, expertise and best practices but don’t say much about development artefacts. The challenge is to take the best of each: shared understanding of model contents, lean developpment processes, sound anticipations, reliable commitments, and traceability.
Architecture Driven Modelling takes source from OMG’s Model Driven Architecture. More generally, it follows the well accepted distinction between requirements, analysis, and design, and can be implemented with OMG’s Unified Modeling Language.
Analysis models describe the symbolic representations of business objects and processes. They use requirement models, which describe business objects and processes. They are used by design models, which specify how symbolic representations will be implemented as system objects; implementation and deployment are not considered here.
Given those layers, system engineering has to manage objectives pertaining to a three-pronged perspective:
- The business perspective is synchronic as it deals with the symbolic representation of context objects and processes. Since objectives, constraints, and risks change along their own time-frames, their symbolic representations must do the same; as a consequence system requirements must be continuously and consistently anchored to business contexts.
- The engineering perspective is diachronic as it deals with the implementation of system symbolic representation. Once rooted into requirements, the design and implementation of symbolic representations are only concerned with the life cycle of development artefacts.
- In between the architecture perspective is meant to be as invariant as core business concerns and corporate identities.
Given an architecture, both business and system models can be managed separately, each along its own timeframe, providing they don’t contradict architectural constraints.
Based upon the layered view of models, engineering processes can be built bottom-up from work units directly defined from development flows. As a consequence, they can be better fitted to tasks, assessed, and improved.
Taking inspiration from the Capability Maturity Model Integration (CMMI), the benefits of architecture driven modelling can be identified for product, project, and process areas:
- Traceability is obviously a starting point as it is a pre-requisite for streamlined engineering (product), portfolio and risk management (project), and application lifecycle management (process).
- Measurement comes close, with built-in unbiased estimators, project workloads, and process assessment.
- Quality management would clearly benefits from layered traceability and objective measurements, with built-in controls, non-regressive testing, and model-based validation.
- Reuse provides another path to quality, with patterns (product), profiles (project) and development strategies (processes).
- Finally, collaboration is to be facilitated between engineering processes targeting heterogeneous platforms, using different methodologies, across independent organizations.