Adaptation planning

An acquisition process as described above could involve several individual adaptations that might take place in sequence - see Figure C.3 above - or in parallel. For each of these adaptations, an adaptation plan will need to be formulated. The way in which this is built up follows a characteristic EM risk-driven approach.

Figure C.7 provides an outline of adaptation planning. Each of the steps in that outline will now be examined in turn. As an example, let us take a relatively small adaptation. As part of a wider acquisition, an organization needs to have user documentation for a new information system written in German for use by the German part of the organization. In this environment, the work practices vary from country to country and so a simple translation of the English language version would not be adequate. It is decided to contract this work out.

Risk Analysis

This is made up of the steps shown in Figure C.8. Firstly steps are taken to ensure that the initial and final IS states are adequately described and documented. In the example where German language documentation is to be produced, the question would be: 'what documents are available upon which to base the German user document?' A problem could be that at the moment the final shape of the system is still not completely known.

Figure C.7 Steps in Adaptation planning.

Risk analysis

Risk analysis

Figure C.8 The steps in risk analysis.

Once the start and end points of the adaptation have been clarified, the situational factors in the problem area have to be assessed. These are the factors that could make the adaptation difficult to carry out. An example in our German language documentation case is that the users of the information system belong to a number of different groups of staff who are each using the system in a rather different way. Hence what might be good documentation for one set of users might not suit the needs of another group.

To assist in the identification of risk, EM identifies two broad categories of risk: those to do with complexity and those to do with uncertainty. Some activities are inherently risky simply because they are large and complex. On the other hand, the source of risk might not be the level of detail involved but the uncertainty of those details. For example, it could be that the application is in an area where the requirements are constantly changing because of environmental impacts. In the case of the German version of the user documentation, for example, it could be that the system that the documentation is trying to describe is itself subject to frequent change.

These elements of uncertainty and complexity could be inherent in the system to be delivered or adapted (that is, the target domain) or in the processes that are going to be carried out to deliver or adapt the system (that is, the project domain).

Within the project domain, the uncertainty and complexity factors can be further categorized as being related to the nature of the tasks that need to be carried out, the structure of the project, the actors involved, and the technology to be employed.

Each risk that is identified is given a rating as 'high', 'medium' or 'low'. EM provides a list of the commonly occurring risks under each of the categories and sub-categories mentioned above.

EM now specifies a step where the analyst in some way summarizes these risk factors in order to obtain some general judgement of the overall complexity and uncertainty of the adaptation. Unfortunately, EM does not provide guidance on how this is to be done. It is also not clear why this is done at this point and not after the final two steps in the risk analysis procedure that assess the probability of each risk's occurring and its possible impact, thus identifying the critical risks in the adaptation.

Design of an adaptation strategy

The steps in this part of the adaptation planning process are outlined in Figure C.9. Having identified the potential risks in the adaptation, counter-measures can now be contemplated. EM provides some guidelines as to the kind of measures to be used against certain types of threat, although there is no claim that the advice by any means exhausts this subject.

With the example of producing German language user documentation, a risk was identified that the base system could change. This could be interpreted as an example of the generic risk 'evolving requirements'. EM suggests as possible counter-measures the implementation of a stringent change control procedure to discourage unnecessary changes, and measures to make sure that delivered products are easy to change. The latter suggestion could be implemented by, for example, having supporting documentation that cross-referenced the user documentation to the system specification so that the effect of changes in the base system could be quickly traced through to user documentation. The user documentation might also be structured to make use of appendixes for details such as error messages, which are likely to change.

Figure C.9 Design of an adaptation strategy.

The risks to an adaptation can also be dealt with at a higher level by considering the overall approach to the adaptation project. This will influence:

• the description approach;

• the construction approach;

• the installation approach.

The description approach is concerned with the method to be used to describe the systems involved. This is divided by EM into a cognitive approach and a social approach.

One of the two alternative cognitive modes is analytical where information about the system is abstracted into simplified views that focus on certain aspects of the system to the exclusion of others. For example, in SSADM, the Logical Data Structure (LDS) is an abstraction of the data needed by a system. On the other hand, the experimental mode, as its name implies, elicits information by using experiments to learn about the system. The use of prototypes is a central technique in this mode. The analytical and experimental modes are not mutually exclusive.

The social approach is the way that the developers and users work together. This can be either in an expert-driven or a participatory mode. In the expert-driven mode, systems analysts, or the equivalent, will fact-find among the users and then go away and, on their own, produce the system description. In the participatory mode, the descriptions are produced in a joint effort between developers and users - Joint Applications Development exemplifies this approach.

'Heuristic' is defined as 'furthering investigation but otherwise unproved or unjustified' in the Longman Concise English Dictionary

Situational factor Installation/construction approach

Schedules

Complexity Uncertainty one

'-shot incremental evolutionary

normal

simple

certain uncertain

complex

certain uncertain

tight

simple

complex

certain uncertain

Table C.2

General heuristics on the suitability of description

Expert-driven

Participatory

Analytical

Situation is complex but information/business processes are relatively straight-forward

Information/business processes are relatively complex

Experimental

Situation is uncertain but participatory approach unsuitable

Situation is uncertain but personnel are experienced and time-scales are adequate

Each of the cognitive approaches can be used in conjunction with either of the social approaches.

In common with ISO 12207, EM offers advice on whether a one-shot, incremental, or evolutionary approach would be best. The distinctive feature of EM is that it distinguishes between construction and installation. It allows, for example, for a system to be built in increments but to be installed in one shot - or vice versa.

As well as the one-shot, incremental and evolutionary options in relation to construction and installation, EM provides guidance on whether, geographically, installation should be carried out in all locations in one step, or in stages where groups of locations are dealt with in turn.

The general heuristics provided by EM about the most suitable approach to description, construction and installation are shown in Table C.l and Table C.2.

Table C.l General heuristics of suitability of installation/construction approaches

Situational factor Installation/construction approach

EM suggests that these options be considered in the following order:

1. installation - system coverage (that is, one-shot, incremental, evolutionary);

2. installation - geographical coverage;

3. construction;

4. description.

These 'first-cut' strategy options might be revised in the light of the more detailed heuristics that are provided by EM. For example, although the general heuristic guidance might point to an analytical/expert-driven approach, because of the importance of winning and maintaining the support of the users for the new system, you might decide to plump for a more participatory approach.

While the adoption of a particular approach to the adaptation could have reduced some risks, it is possible that it can generate completely new ones - the impact of the strategy has to be scrutinized to remove this possibility.

Project control

Finally, advice is offered about how the project would be most appropriately controlled. The project control options to be considered here relate to the frequency of decision points, the degree of formality needed in the control process and the question of customer responsibilities - for example, who should have the responsibility for user training: the supplier of the adaptation or the customer?

These decisions have to be made in respect of control of three different kinds: development control, which is concerned with the progress of the project, quality control, and configuration control.

Plan decision points

The selection of the approaches will have a major influence on the positioning of decision points (or 'milestones') in the project lifecycle. For example, decision points would seem to fall naturally at the end of each increment where an incremental approach is adopted, and at the end of each iteration with an evolutionary approach. The nature of the initial and final IS states will also influence the placement of decision points - the further apart they are in the system lifecycle, the more decision points will need to be planned.

For each decision point, the deliverables that are needed for that milestone and the decisions that will have to be taken at that point will have to be recorded. These deliverables are defined generically in EM, but they will have to be mapped to the types of product created by the suppliers' chosen methodology. This is discussed as a separate topic below.

The final guidance proffered by EM consists of the criteria that can be applied to assess the appropriateness of the proposed adaptation plan.

C.8 Method bridging

The outcome of these EM activities is an adaptation plan, which identifies decision points and the deliverables that supply the information upon which the decisions are to be taken. These decision points and deliverables have to be reconciled with the development methodology that is proposed.

EM recognizes six views of an information system.

1. The business information view, which defines the data that is used by the business and how it changes over time.

2. The business process view, which identifies the business processes that are carried out and the rules to which they conform, and how they relate to the goals of the business.

3. The work practice view, which describes how people actually execute the business processes, using the business information that is to hand.

4. The computer system data view, which describes how the business information requirements are actually implemented in the computer system.

5. The computer system function view, which identifies the transactions that users can carry out using the computer system.

6. The computer system architecture view, which describes the actual way in which the software is segmented and structured.

For each of these views, there are identified a number of properties that are essential pieces of information about the view. In the case of the business information view, for instance, the items of information held, their value ranges and the relationships among them are all properties.

For the methodology it is proposed to use, say Information Engineering, the particular products that document those properties should now be identified. It could well be that a methodology does not provide some of the information that is required (it appears, for example, that some of the modifications introduced in the latest version of SSADM have been introduced to remedy deficiencies identified by EM). On the other hand, it might be that not all products of a methodology are required by a particular adaptation - the delivery plan with its list of decision points and associated deliverable profiles will show which ones are needed.

C.9 Conclusions

It will be interesting to see how widespread the adoption of Euromethod will be. It could be that, ironically, the name itself will restrict its adoption as non-European developers might automatically ignore it! It was suggested at one point that an alternative name, which was less parochial, such as 'EMpathy' might be better.

Another disadvantage of the method is the sheer size of the documentation and the obscurity of some of its terminology. Standards documents are never a riveting read but EM particularly suffers in this respect.

Despite this, we have found that there is a lot of worthwhile material in EM. Its strength is that it attempts to give practical advice about how the decisions are to be taken, rather than just stating what the decisions are. We would look forward to the development of a more user-friendly version as time goes on.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment