DiVA comes with a methodology that covers the whole process of specifying, deployment and change of configurations. The DiVA lifecycle (see "DiVA Lifecycle" in "Related Items") is made of four steps that can be repeated several times in an incremental way if an overall spiral lifecycle is chosen.

The first step in the DiVA lifecycle is to elicit the adaptation requirements of a system. We will focus on identifying variations that may occur at runtime as well as identifying co-existing, co-dependent variants. Another focus will be on understanding the trade-offs of alternative transformation paths and understanding the effect of making changes to a specific configuration (or other configurations that may be co-existent and co-dependent on it).

The second step is to build an operational model of the adaptation layer based on the requirements. An operational model is a representation of the underlying reality in the form of a model, including behavioural aspects that are described using operational semantics. The adaptation layer plays a role similar to that of a controller in the control theory. The model of the adaptation layer has a clear interface with the underlying system and platform. This interface is itself described as a model exposing sensors and actuators. In DiVA the adaptation actuators provide inspection and manipulation of crosscutting features by means of aspect-oriented techniques, and hence, adaptation can be managed more effectively. These sensors and actuators are equipped with "contracts" that clearly define assumptions/guarantees of the interaction between the adaptation layer and the system and platform layer.

The third step is to validate the model of the adaptation layer with respect to several operational profiles simulating various aspects of the application and platform behaviour. This is accomplished using recent advances in executable meta-modelling by having simulation runs of the operational model of the adaptation layer connected to the operational profiles. Errors in the adaptation policy can be detected when contracts between the adaptation layer and the system layer are violated.

The fourth step is to use MDE technology to automatically translate the model of the interface with the underlying system and platform to a concrete API on the platform. At the same time, it also translates (through either compilation or embedded interpretation) the model of the adaptation layer into a concrete runtime adaptation layer using the above API.