Change is inevitable for the environment of information systems (IS). Many problems arise from these changes ranging from communication problems among the stakeholders to conforming the IS to the changes. Maintaining an IS is increasingly difficult and expensive as more changes are incorporated. Hence IS failure is likely to be due to their not being flexible enough to handle change. Failures also relate to inadequacies in identifying future requirements. An IS that cannot be changed is essentially a failure.
The paper is divided into two parts; the first part looks at future requirements and their prediction while the second part discusses the future requirements and change can be incorporated into the system. A number of techniques for identifying future requirements, some formal and others informal have been presented in the paper i. e. : future analysis, risk analysis and lateral thinking. Using future analysis generates greater insight into the problem area, giving a better understanding of probable future scenarios and future requirements of an information system.
Using risk analysis, one may be able to identify “general responses” to several problems and get some idea of the trade-off between expected risks and costs. Some of the lateral thinking techniques can be used as tools within more formal techniques or can be used on their own as quicker alternatives. Some form of analysis of future requirements early in the information systems development process would be beneficial, as it is likely to produce more appropriate information systems and reduce maintenance costs.
Similarly, there are various techniques that can be used in making information systems more flexible. The techniques can be classified as good analysis, design, and programming practices. The paper presents information systems development as a whole and suggests a number of techniques which cover the stages of the development of an information system. The paper argues that it is impractical to generate a new methodology or to try and change all the existing methodologies in order to incorporate change.
Even if it was practical, it would probably not work, since the faults mostly have an ad hoc nature, resting on individual developers. It therefore proposes a framework of items and issues that should be considered at various stages in the development of an information system. The framework can be considered as part of a “code of practice” for developers and incorporates many of the tenets of good software practice.
If the future requirements and flexibility issues are addressed, such as in the framework provided, then the result is likely to be a more appropriate information system, able to successfully handle future changes. Question 2: The paper does a good job of first introducing a reader to the problems related to maintenance and change management of an IS and then moving on into how to identify possible changes and then how to engender the flexibility to incorporate these changes as and when they occur into the system.
It is rightly stated that identifying all possible changes or even a good percentage of them is not an easy task. It is this difficulty of identifying future requirements and the consequent inflexibility of information systems (IS) in the context of incorporating unperceived changes which make the maintenance process difficult and costly, and may lead to IS failure or obsolescence. According to the paper, IS changes may result from maintenance requirements; maintenance however has been defined in a broader context by the authors, which blurs the boundaries between bug fixing and enhancement.
Where run-time bug-fixing may be part of maintaining activities, it is wrong to suggest that the corrections needed due to unfulfilled requirements are also part of maintaining a system. A system which does not meet its requirements, however they may have been presented, is essentially an unsuccessful system that needs ‘correction’ not ‘maintenance’ per say which has nothing to do with future requirements or change identification.
The paper however is correct in stating that maintenance may be required in case of shifting requirements, where end users are not quite sure about what they want and want the IS to be changed only after having an initial experience with it. If however the requirements keep changing during the IS design and/or development stages, the resultant changes in the system will not be categorized as ‘maintenance’ but simply as a ‘rework’. The solution for such problems is to ‘freeze’ the requirements at a suitable point in time after thorough requirements analysis.
Many of the techniques discussed in the paper to anticipate future change scenario may in fact be used to identify the correct system requirements. Future analysis techniques given by the paper are fairly applicable. This paper discusses three techniques which might be used to help identify future requirements. One technique is Future Analysis; this involves identifying changes in technology, legal requirements, economic and environmental factors, attitudes and expectations and changes within the organization which may impact the system.
A multidisciplinary team may identify these changes using simulation, statistical forecasting and economic modeling based on whether they affect system logic, system traffic and whether the changes are short-term or long-term in nature. Once the changes have been identified, the development team can assess the under-development IS to determine which changes can occur, what impact they will have on the IS and what is their probability of occurrence.
As a result of this, target life span of the IS is identified along with an updated list of design objectives, parts of IS requiring extra flexibility built into them and a number of future scenarios that the design will have to cope with. The second technique presented by the paper is Risk Analysis. Where the paper defines the approach is considerable detail, it does not provide the meaning or definition of ‘risk’ in the context of IS. Unless it is known what to be considered as a ‘risk’, it will not be very meaningful to either identify risks or what to do to mitigate them in case they do occur.
The third technique presented in the paper is using lateral thinking. This technique includes: generation of alternatives, challenging assumptions, fractionation and brainstorming. De Bono (1970) identified the “natural” search for alternatives as something that we think we all do. But our natural search for alternatives is somewhat limited. The “lateral” search goes further and is aimed at producing as many alternatives as possible. As de Bono argues, “The most basic principle of lateral thinking is that any particular way of looking at things is only one from among many other possible ways.
In the lateral search one is looking for as many different alternatives as possible and these alternatives do not have to be reasonable. Having said that, the paper would have benefited its readers a great deal by presenting an example demonstrating how lateral thinking can be used to identify alternatives for an IS. The second lateral thinking technique involves challenging any assumptions made. A particular view, model, or pattern of a situation is made up of a structure of “basic” ideas. The basic ideas are building blocks from which more complex ideas (for example, a particular view of a situation) are generated.
It is usually taken for granted that these basic ideas are sound and they are seldom stated. One way of challenging assumptions is continually to ask “why” about aspects of a problem, with successive “why” questions directed at some aspect of the previous answers. The idea is not to “attack” the assumptions as wrong, but to restructure the pattern or problem area (that is, to move out of the self-imposed boundaries of the problem). Fractionation, another lateral thinking technique involves breaking down any situation into parts and then trying to reassemble the parts in a different way.
The divisions do not have to be equal, nor do they have to cover the whole of the situation, and it is acceptable if there is considerable overlap. The divisions can be fairly arbitrary and do not have to be logical. Brainstorming is a team activity aimed at generating a cross simulation of ideas. It is used in a semiformal setting to generate ideas, where the ideas of one person serve as a stimulus to generate further ideas from other people, which in turn serve as a stimulus for further ideas, and so on.
Judgment on the usefulness or validity of the ideas is “suspended” until the brainstorming session is completed. The aim is to get a free flow of ideas. There are however a number of problems in using lateral thinking techniques, such as: relying on the skills of the practitioner giving rise to lack of consistency, not being formal or controllable, not having a definite stopping point in some of the techniques etc. They are probably better used as a tool set within more formal techniques, such as future analysis or risk analysis, though they could be used on their own as quick alternatives.
Other techniques to predict changes also exist. One of them is to examine the past. . It is likely that the areas in information systems that required most change in the past will also require most changes in the future. Changes to software probably follow the 80/20 rule (or 90/10 rule), that is, 80% of changes are likely to be concerned with 20% of the software. The developers will need to examine records of past changes and extrapolate into the future. This may lead to further investigation; hence caution should be exercised to avoid analysis paralysis.
Another very simple method to identify future changes is to ask the question, “What is likely to change? ” This is a prerequisite to the other methods above, and is arguably the most powerful. Asking the question puts future considerations on the agenda. After discussing a number of techniques of future analysis and change prediction, the paper focuses on how to incorporate future change into the system. Many of the future requirements identified using the above techniques can be included in the IS design.
Some techniques for incorporating flexibility into the system design include modularity, simple and clear design, data abstraction, clear interfaces, defensive designing and programming and single point control, designing for expansibility, good programming practice, software reusability, human control points (HCPs) and proper and up-to date documentation. Monitoring tools can also be used. There is an ever-increasing array of tools available to help ease the maintaining process. Some perform a library function helping to control the maintenance of large information systems.
Others deal with aspects of testing, tracing program flows, or restructuring code, while yet others try to identify inconsistencies. Making cheap throw-away ISs is another option best suited for situations when the environment is highly unpredictable and volatile. Incorporating change should also be done at the development phase. Although flexibility to incorporate future changes is touched upon in some methodologies in little or more detail, future requirements are not explicitly incorporated in any detail in popular methodologies.
Prototyping (Dearnley and Mayhew, 1983; Agresti, 1991; Avison and Wilson, 1991) is sometimes cited as the answer to the problem of future requirements; however the potential of prototyping in this area might have been exaggerated, as prototyping often translates into rebuilding an IS from scratch. Prototyping does, however, have certain benefits such as aiding communication, reducing uncertainty, giving speed and cost savings, and providing a vehicle for learning and feedback and a focus for attention.
A prototype may be developed and refined until users’ requirements are met when the prototype is used as the operational system or as a basis for the development of the operational system using conventional methods. Prototyping is used to better identify current requirements. Further, though evolutionary prototyping consists of continually updating an existing information system to meet new requirements, it does so when they arise. Again, these are current requirements. More recent excitement has been generated regarding object oriented methods (de Champeaux and Faure, 1992; Walker, 1992).
These may offer more maintainable systems and increases in productivity through code reuse among other means. But object-oriented methods also do not address future analysis. The same can be said of artificial intelligence approaches, such as the “requirements apprentice” (Reubenstein, 1991), and formal executable specification languages, such as PAISLEY (Zave, 1991). It is impractical to create a “new” methodology which will solve all the future and maintainability problems. Indeed, solving the maintenance problem may imply creating other problems such as cost overruns, delays, uncertainty, and software instability.
The paper offers something akin to a framework or part of a “code of good practice” for the developers, to ensure that future considerations and flexibility are major considerations throughout the development of an information system. Various considerations can be incorporated into the lifecycle of any IS development methodology. In the analysis stage, examine the main motivations for having an information system. State and challenge the assumptions about the information system and its environment. Identify the urgency of the IS.
Consider future requirements, identifying what is likely to change using an appropriate technique from those discussed above. Identify tradeoffs for different courses of action. Identify areas of single-point control. In the design stage, keep defensiveness and expansion in mind. Design for flexibility and keep avenues open. State and challenge assumptions made during design. Ensure interfaces are defined and clear. Design with maintenance in mind. Use and maintain clear documentation about the information system.
In the production stage, keep the system modular, simple and clear. Use single-point control as much as possible and data abstraction. Use and maintain clear documentation and comments in the programs. There are various techniques in identifying future requirements, varying from the very formal to the informal. Some may consume considerable effort; others, only minor effort. Using future analysis generates greater insight into the problem area, giving a better understanding of probable future scenarios and future requirements of an information system.
Using risk analysis, one may be able to identify “general responses” to several problems and get some idea of the trade-off between expected risks and costs. Some of the lateral thinking techniques can be used as tools within more formal techniques or can be used on their own as quicker alternatives. Investigations into previous changes might reveal likely future changes. A most powerful technique, yet the simplest, is to ask the question, “What is likely to change?
” Some form of analysis of future requirements early in the information systems development process would be beneficial, as it is likely to produce more appropriate information systems and reduce maintenance costs. There are various techniques that can be used in making information systems more flexible. The techniques can be classified as good analysis, design, and programming practice. A framework of items has been proposed along with addressing issues that should be considered at various stages in the development of an information system.
The framework can be considered as part of a “code of practice” for developers and incorporates many of the tenets of good software practice. All in all, the framework provided by the paper is quite adaptable. It rightly suggests that future considerations and flexibility issues need to be on the agenda when developing an information system. If the future requirements and flexibility issues are addressed, such as in the framework provided, then the result is likely to be a more appropriate information system, able to handle future changes and so be more successful.Sample Essay of Paperial.com