l*his is made up of the steps shown in Figure C.8. Firstly steps are taken to ensure that the initial and final IS states arc 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.
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 w hat 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 w ith 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 arc 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 arc 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 ¿in adaptation strategy
The steps in this part of the adaptation planning process arc outlined in Figure C.9. Hav ing 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 (o an adaptation can also he 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 w ith 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 betw een developers and users - Joint Applications Development exemplifies this approach.
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.I and Table C.2.
Table C.l General heuristics of suitability of installation/construction approaches
Complexity Uncertainty one-shot incremental evolutionary normal simple certain uncertain complex certain uncertain tight simple certain uncertain
complex certain uncertain
'Heuristic' is defined as furthering investigation but otherwise unproved or unjustified' in the Longman Concise English Dictionary
Table C.2 General heuristics on the suitability of description
Situation is complex but information/business processes are relatively straight-forward
Information/business processes arc relatively complex
Situation is uncertain but participatory approach unsuitable
Situation is uncertain but personnel arc experienced and time-scales are adequate
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;
These 'first-cut* strategy options might he 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 participator) 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.
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.
The selection of the approaches w ill have a major influence on the positioning of decision points (or 'milestones9) 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 gencrically in EM. but they w ill 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.
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 w ith 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 deliver)' plan with its list of decision points and associated deliverable profiles w ill show which ones are needed.
Was this article helpful?
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.