Model Driven Development
How to adopt and exploit the benefits of Model Driven Development (MDD).
One key common differentiator between successful and failed MDD implementations is not the specific tool acquired but instead the adoption requirements for process definition and implementation.
Abstract Solutions’ value to customers is to utilise our experience of helping people during hundreds of different MDD implementations.
Below details of how we would work with you in discreet stages to enable you to design a systems development process that is relevant and unique to each specific customer and allows you to automate that process with the relevant tools.
Of course, it is important that any process design activity be tailored to the specific needs of the deploying organisation, but a typical approach would consist of the following steps. This incremental approach is designed to limit a customer’s risk and financial exposure at each stage, and to help ensure that a business case can be made prior to the start of each new iteration.
1. Define the Requirements for System Development Process. This would typically be a two day workshop to capture and organise the key drivers for the system development process. This would include specifying the scope of requirements management and traceability, system design, component design (including electronic and hardware components where applicable), code generation and testing. This task would also identify aspects of the existing development process which are considered effective, and should therefore be preserved in the improved process. This is the first step in the systems development process. We document the workshop output requirements which can then be the input to stage 2.
2. Design the Process. This typically involves a few days spent constructing a metamodel showing the primary artefacts generated by the development process and their inter-relationships, along with one or more activity diagrams showing the process components that generate and use those artefacts. The requirements specified in step 1 form the primary input to this step, along with experience accumulated by the customer, Abstract Solutions and from other parts of the industry.
3. Automate and Industrialise the Process – Prototyping and Demonstration. This involves casting around for a set of suitable products, either in-house or COTS, which together can form a coherent tool chain to automate the development process as defined in steps 1 and 2. The candidate tool chains can be prototyped to establish their viability. The amount of time required for this step depends largely upon the number of candidate products to be evaluated, and the sophistication of the process to be automated.
4. Automate and Industrialise the Process – Deployment. This involves configuring and integrating the preferred tool chain to support the desired process.
5. Training and Rollout. This involves developing tailored training, typically based upon pre-existing material, to be delivered to the early adopters of the process / tool chain. It is usually prudent to select a small pilot project as a testing ground for the process prior to more widespread rollout.
The Abstract system development process embeds the key elements of the proven Harmony SE process for systems engineering, and the well-established Executable UML process for software engineering. It is founded on the principle that models need to be precise, so that they can be executed and tested as the system evolves. It can be deployed in a variety of project lifecycle models, from strict waterfall to agile. In the latter case, the executability of the models lends itself to continuous testing, integration and deployment that allows the project to manage risk and demonstrate progress throughout the lifecycle.
The key features of the process are:
- Lightweight end-to-end, fully traceable process covering systems engineering, software engineering, testing, deployment and maintenance;
- A coherent, orderly sequence of artefacts, with clearly defined rules and guidelines for deriving one artefact from another;
- Use of precise, executable models, to facilitate continuous customer feedback, testing and integration;
- A modelling style that promotes penetrating analysis of complex subject matters, by constructing models of the problem domain rather than models of a solution. This exposes misunderstandings early, and helps to reduce cost and risk;
- Platform independence, where appropriate, to promote model portability and longevity;
- Separation of concerns, achieved through domain partitioning, to promote reuse and simplicity;
- Generic modelling strategies, specifically designed to support reuse of business capabilities across multiple products in a product line by means of product specific configuration data and plugins;