name given to a key from one entity that is repeated in another entity to form a link.
• What tasks are to be carried out at each stage;
• What outputs are to be produced;
• When actions or events are to be carried out;
• What constraints are to be applied;
• What support tools are to be utilized.
A methodology is often used as a project management tool to create a bet- ter end product, a better development process, and a standardized process. The two main types of IS methodologies are structured methodologies and behav- ioral methodologies. The life cycle that has been discussed in this chapter is characteristic of traditional structured methodologies. Examples of these would include Information Engineering and Structured Systems Analysis and Design Methods (SSADM). Structured methodologies, although not really scientific, tend to draw on the credibility of the scientific method.
Behavioral methodologies take an organizational perspective. The real complexity in an organizational setting comes about as a result of the interac- tion of the components of the system. The system encompasses such things as the people, technology, protocols, procedures, organizational culture and politics, and the wider business environment. The Soft Systems Methodology is perhaps the best known behavioral methodology used in information systems [2].
Examples of IS Methodologies Information Engineering
Information Engineering [1, 3] is a methodology that takes a data-driven approach. This means that data models and data modeling are at the heart not just of any one system but the organization as a whole. The enterprise-wide approach to systems development is also the reason why it puts such an empha- sis on systems planning. Process modeling is given some attention, but is not given the same priority as data modeling. The methodology is supported by a CASE tool called Information Engineering Workbench (IEW).
Object-Oriented Methodology
Although object-oriented development has much in common with the struc- tured approaches described in this chapter, it differs in that it focuses on the notion of objects that encapsulate both data and methods (processes). This means that objects can be developed and then reused in other parts of the sys- tem without worrying greatly about their internal structure [4]. For example,
suppose there is an object that is a picture. It could be developed to include the method to display it on the screen so that if the object is reused in another part of the system it carries with it the code to display it. The object acts as a self-contained feature of the system. Traditional structured techniques were developed when data was mainly text based. Increasingly, systems have to store multimedia information and object-oriented methods are seen as more appro- priate for handling these diverse forms of data [5].
Prototyping
Prototypes have been used by engineers for many years. They generally develop a small-scale working (or simulated) model of a product. In systems development a prototype is used to supplement the SDLC in order to define requirements and/or try out designs. Structured methodologies were seen to concentrate on documentation and were perceived as inflexible. If the users were uncertain about their requirements, the methodology became a barrier to the progress of the project. Developers became frustrated by this scenario and many ques- tioned the need for full documentation on all projects. Prototyping was seen as a partial solution to some of these problems. It relies on tools that enable the interface to be specified quickly. Examples of prototyping tools are Micro- soft Access, Visual Basic, and PowerBuilder. It can be used as part of rapid application development (RAD), the main aim of which is to quickly put together a system shell by using structured methods, JAD techniques, and prototyping methods. Four types of prototyping have been identified [6] as dis- cussed next.
Feasibility Prototyping
Feasibility prototyping is used to test the feasibility of a specific technology approach that might be used for an information system. For example, a univer- sity wants to improve its enrollment procedures. Too much time is spent on keying in the data. They think that students could possibly input the data directly into the computer system. Hence, a prototype is designed to test a range of student reactions to inputting their details of enrollment. In other words, it allows some input and simulates some basic searches. Based on the students’ reactions, the university can decide whether to go ahead or not.
Requirements Prototyping
Requirements prototyping is used to define the users’ requirements. It is used as a tool to encourage interaction between users and developers. The prototype is composed of screens that have menus, icons, and forms to illustrate the types
of data to be captured or output. Users can then use the screens as a prompt to give further information. The actual design of the screens is not really important.
Design Prototyping
The user interface of the system can be developed and shown to users. The users assess the ease of use, the layout, the order of input fields, help messages, and so on, and provide feedback to the developers who can then modify the prototype. After several iterations, the interface should be in line with what the users find acceptable to work with. However, the prototype may not become the finished system; another tool may be seen as more appropriate for imple- menting the software.
Implementation Prototyping
When the design prototype is extended to become the actual system, it is called an implementation prototype. It might not include certain editing and security features which can be added later.
Prototyping is not a return to development without a methodology and documentation. The process needs to be managed and ideally used alongside another methodology. It should be used with set objectives in mind, for exam- ple, for a small project or as part of the design of the interface of a large system.
It is not a panacea for all system development problems.
Soft Systems Methodology
The Soft Systems Methodology (SSM) grew out of dissatisfaction with struc- tured techniques for their underestimation of the issues associated with defining problems with the current systems and in defining a way forward.
Peter Checkland [2] developed the methodology not just as an information sys- tems methodology but as a general problem-solving approach. SSM has seven stages but has at its core the development of rich pictures and the ethos of empowering the users to decide on the acceptability and desirability of any changes to be made. The rich picture is a freeform sketch drawn by the user. It incorporates such things as concerns, challenges, issues, politics, and compe- tition. The SSM sessions are facilitated in such a way as to promote open discussion based on the idea that real progress cannot be made until the issues and concerns are acknowledged.
References
[1] Martin, J., Information Engineering, Vol. 1, Upper Saddle River, NJ: Prentice Hall, 1989.
[2] Checkland, P., Systems Thinking, Systems Practice, New York: John Wiley & Sons, 1981.
[3] Martin, J., Information Engineering, Vols. 2 and 3, Upper Saddle River, NJ: Prentice Hall, 1990.
[4] Graham, I., Object Oriented Methods, Reading, MA: Addison Wesley, 1994.
[5] Hawryszkiewycz, I., Systems Analysis and Design, Upper Saddle River, NJ: Prentice Hall, 1998.
[6] Whitten, J. L., L. D. Bentley, and V. M. Barlow, Systems Analysis and Design Methods, Homewood, IL: Richard D. Irwin, 1994.