A Taxonomy of Change

In SecureChange a taxonomy was developed to help to “scope” the project activities. The taxonomy had to have enough classification power to distinguish all project activities, show their similarities, and clarify their scope of investigation. The taxonomy has two main sides of classification:

• Problems: How things change,
• Solutions: How we deal with changes.

The following figure summarizes the taxonomy of change.

The categories of the classification can be defined as follows.

Time

• One-Off: Evolution is described by single transition, for example before and after a major overhaul of the customer application. Such change might be the results of many local changes but they are not explicitly described.
• Discrete: Evolution is explicitly represented by many steps, for example the interleaving of local changes in the overall system, or sequence of discrete events explicitly captured.
• Continuous: The properties of some systems components are described by a continuous function of time.

Nature

• Actual: The world has already changed wrt some SecureChange artefact, we need to update the description of the status quo.
• Expected: The change has not yet happened but it is going to happen. For example the roll-over of the app.
• Potential: This evolution is purely speculative. For example a customer wishing to investigate the risk related to two different architectural solutions.

Behavior

• Controllable: The customer can decide whether the evolution takes place or not, for example he can reject a proposed change in the model.
• Predictable: Evolution is independent from the designer but he can provide reliable estimates on whether certain changes will take place (this security requirement might be mandatory within 1 or 2 years).
• Observable: Evolution cannot be predicted however all changes that take place can be observed, and the system can be notified about it. We might include analysis of adversarial behavior (e.g., trusted and untrusted actor).

Change Attitude

• Plan: We analyze the possibilities in order to make decision on what to actually do in practice. For example studying the possible risks of a deployment and proposing countermeasures.
• Do: We deploy solutions that tackle the change that the customer is facing. For example by running a system that controls the update of a new application of the customer. Or by implementing a traceability mechanism for requirements and models.
• Check: We measure and evaluate the current changes. For example to see if our initial plans and estimates are actually met by the new system resulting from the evolution.
• Act: We react to the change on the basis of our checks, possibly restarting the process if we are not happy.

Artefact delivered

• Design: The artefact delivered by the SecureChange actor belongs to the design level such as a model of the system.
• Deployment: The artefact is used off-line and can only affect the actual run-time behavior of the system under control from the point of roll-over. However the system already exists and cannot be changed by the secure change solution.
• Execution: The artefact can modify the behavior of the system during execution, for example forbidding, enabling certain changes in the actual execution.

Using this taxonomy the various methods developed in the SecureChange project can be categorized in the following way.

This categorization helps us to position the different activities of the work packages, and give a clear picture about the relations of the developed methodologies.

Prof. Fabio Massacci, Università di Trento