MULTIVIEW - The Methodology explained.

1 Methodology Defined.

2. Multiview.

2.1 What it's all about.

3. Stages of Multiview.

3.1 Analysis of Human Activity.

3.2 Analysis of Information.

3.3 Analysis and Design of Socio-Technical aspects

3.4 Design Human Computer Interface.

3.5 Design of Technical aspects.

4. Strengths and Weaknesses of Multiview

4.1 Strengths.

4.2 Weaknesses.

5. Usage and Applicability.

5.1 Usage

5.1.1 Purpose of using Multiview.

5.1.2 Those who use it.

5.1.3 Solutions it provides.

5.2 Applicability.

5.2.1 User requirements.

5.2.2 User familiarization.

5.2.3 Boundary definition.

5.2.4 Processes Analysis.

5.2.5 Computer Application.

5.2.6 Human Computer Interface.

5.2.7 Maintenance.

5.2.8 Control.

5.2.9 Recovery Issues.

6. The MERISE methodology.

6.1. Stages

6.1.1 Strategic Planning.

6.1.2 Preliminary Study.

6.1.3 Detailed Study.

6.1.4 Fundamental Design.

6.1.5 Technical Design.

6.1.6 Development.

6.1.7 Coding of Programs.

6.1.8 Implementation.

6.2 The Levels of MERISE.

6.3 How MERISE compliments Multiview.

A Methodology is a collection of procedures, techniques, tools, and documentation that helps system developers in their efforts to implement successful information systems. The methodology will consist of phases, which in themselves consist of sub-phas es, they will guide the developers in their choice of techniques that might be appropriate in each stage of the project and will also help to plan, manage, control and evaluate the information system project.

A methodology is more than just a collection of the above. Methodologies vary according to their philosophical perspective/view. Each methodological approach will favor a certain kind of outcome depending on the developer's assumptions, stemming from t heir philosophy on what they think constitute to a good information system.

Methodologies differ greatly and often address different objectives; but there are certain common features that most of them abide to. Here are a few:

How a project is to be broken down.

What tasks are to be carried out at each stage?

Critical success factors. (i.e. producing a successful system).

What constraints are to be applied?

Deciding the people to be involved.

How the project should be managed and controlled.

What support tools may be used.

Specifies the training needs of the users.

A methodology is a set of principles of method, which in any particular situation has to be reduced to a method uniquely suited to that particular situation [Checkland 1981]. The term methodology is not apt in the context of systems development; the te rm ‘method’ is perfectly adequate to cover everything that is meant by methodology [Flynn 1992].

Another way to look at methodologies could be the fact that they are products, in most cases within the commercial environment and usually consist of:

Manuals.

CASE tools.

Technical help.

Prototypes, and so on.

2.1 What it's all about.

Multiview attempts to address many of the real world issues. It includes stages, which relates to the human and social dimensions as well as the technical aspects, which are emphasized in the latter part of the paper. It attempts to address questions r elated to the organisation on a whole, the people working within the organisation the human computer interaction, the various functions that the information system has to carry out and the technical specification for

performing those functions.

It is a contingency approach, which means that the techniques and tools described in the framework and chosen in a particular problem situation will depend on the circumstances where it is applied. It is a flexible framework, which provides an alternat ive to choosing between different methodologies. The tools and techniques within the framework are chosen and adjusted according to a particular problem.

Unlike most methodologies which are suited for either large or small system, Multiview is good for both small and large systems equally, although the way the project is handled would be different .It offers the analyst a flexible approach to the organi zational problems in terms of which methodology is best suited for that situation. It is not the perfect methodology, as finding the perfect methodology is a far fetch idea. Nevertheless since it covers both the human and

technical aspect of organizations it looks like the perfect choice. There is a clear connection between the analyst, methodology and the situation. Figure 3.1. shows connection between the analyst, methodology and the situation.

The skill of the analyst undergoing a project with Multiview has to be taken into account because it could be deceiving due to its similarity to other methodologies. It is flexible but should not be under estimated, the authors of Multiview claim that it is not simply a mixture of available techniques and tools, but one which has been tested and works in practice.

The methodology covers five different stages of systems analysis and design, each with its own appropriate view of the problem, and each with the best available method for tackling that aspect of the problem. These stages account to the description 'multi-view'.

The stages of the methodology and the inter-relationship between them are shown in Figure 3.1. The boxes refer to the analysis-orientated stages and the circles show the design-orientated stages. The arrows between them describe the int

er-relationships. Some of the outputs of one stage will be used in a following stage. The dotted arrows show other major outputs.

Analysis of human activity.

Analysis of information (sometimes called information modeling).

Analysis and design of the socio-technical aspects.

Design of the human-computer interface.

Design of the technical aspects.

The five different views are appropriate to the progressive development of an analysis and design project, covering all

aspects required answering the vital questions of users. These five views are necessary to form a system, which is c

omplete in both technical and human terms. The five stages move from the general to the specific, from the conceptual

to hard fact and from issue to task. Outputs of each stage either become inputs to following stages or are major outputs

of the methodolo gy. Projects using the Multiview methodology do not always develop from stage 1 through to stage 5.

The methodology can be used flexibly, as appropriately needed for each situation.

The main purpose, problem themes, and the creation of a statement about what the information system will be and what it will do are the initial considerations. The second stage is to analyze the entities and functions of the system desc ribed in stage one. This is carried out independently of how the system will develop. A number of diagrammatic aids are discussed which are used in the process.

The philosophy behind the third stage is that people have a basic right to control their own destinies and that if they are allowed to participate in the analysis and design of the systems that they will be using, then implementation, acceptance and operation of the system will be enhanced. This stage emphasises the choice between alternative systems, according to important social and technical considerations. The fourth stage is concerned with the technical requirements of the user interface. The design of specific dialogues will depend on the background and experience of the people who are going to use the system, as well as their information needs.

Finally, the design of the technical subsystem concerns the specific technical requirements of the system to be designed, and therefore such aspects as computers, databases, control and maintenance.

The outputs of the methodology, shown as dotted arrows are listed in Figure 3.2, together with the information that they provide and the questions that they answer.

‘Human activity’ is the general term used to cover any sort of organisation, for example, an individual, a company, a department within a larger organisation, a club or a voluntary body. All these may consider using a computer for there

information systems. The central focus of this stage analysis is to search for a particular view (or views). This Weltanschauung (sometimes also called ‘Assumptions’ or ‘World View’) will form the basis for describing the system

requirements and will be carried forward to further stages in the methodology. This worldview is extracted from the problem situation through debate on the main purpose of the organisation concerned.

First the problem solver (the analyst or the project team), with extensive help from the problem owner (the person or group on whose behalf the analysis has been commissioned), forms a rich picture of the problem situation. This picture

can be used to help the problem solver better understand the problem situation. The rich picture diagram is also very useful to simulate debate, and it can be used as an aid to discussion between the problem solver and the problem

owner. There are usually a number of iterations made during this process until the ‘final’ form of the rich picture is decided. The process here consists of gathering, shifting and interpreting data. Drawing the rich picture diagram,

example of which is given in fi gure 3.3, is a subjective process.

From the rich picture the problem solver extracts problem themes, that is, thing noticed in the picture that are, or may be, causing problems and/or it is felt worth looking at in more detail. The picture may show conflicts betwe en two

departments, absences of communication lines, shortages of supply and so on. Taking these problem themes, the problem solver imagines and names relevant systems that may help to relieve the problem theme. Several different

relevant systems s hould be explored to see which is the most useful. Once a particular view or root definition (is a concise, tightly constructed description of a human activity system which states what the system is [Checkland 1981]) has been decided upon, it can be devel oped and refined. Thus, by using the CATWOE checklist, the root definition can be analyzed by checking that all necessary elements have been included.

When the problem owner and the problem solver are satisfied that the root definition is well formed, a conceptual model (is a diagram of the activities showing what the system, described by the root definition, will do) of the system is constructed by listing the ‘minimum list of verbs covering the activities which are necessary in a system defined in the root definition’. At this stage, therefore, we have a description in words of what the system will be (the root definition) and a dia gram of the activities of what the system will do (the conceptual model).

The completed conceptual model is then compared to the representation of the ‘real world’ in the rich picture. Differences between the actual world and the model are noted and discussed with the problem owner. Possible changes

are debat ed, agendas are drawn up and changes are implemented to improve the problem situation.

The purpose of this stage is to analyze the entities and functions of the application. Its input will be the root definition and conceptual model of the proposed system, which was established in stage 1 of the process. Two phases are in volved:

(a) Development of the functional model.

(b) Development of an entity model.

a.Development of the functional model

The first step in this model is to identify the main function. This is always clear in a well-formed root definition. This main function is then broken down into sub-functions (functional decomposition), until sufficiently comprehensive level is achieved. This occurs when the analyst feels that the functions cannot be usefully broken down further. This is achieved after about four to five sub-function levels, depending on the complexity of the situation. A series (numbers) of data flow diagrams, is developed from this hierarchical model. The hierarchical model and data flow diagrams are the major inputs into stage 3 of the methodology, which is the analysis and design of the socio-technical system.

(b) Development of an entity model

In developing an entity model, the problem solver extracts and names entities from the area of concern. Relationships between entities are also established. The preceding stage in the methodology, the analysis of the human activity

systems, should have already given this necessary understanding and have laid a good foundation for this second stage. The entity model can then be constructed. The entity model, following further refinement, becomes a useful input into

stages 4 and 5 of the Multiview methodology.

The philosophy behind this stage is that people have a basic right to control their own destinies and that, if they are allowed to participate in the analysis and design of the systems that they will be using, then the implementation, a

cceptance and operation of the system will be enhanced. It takes the view therefore that human considerations, such as job satisfaction, task definition, moral and so on, are just as important as technical considerations. The task for the problem solver i s to produce a ‘good fit’ design, taking into account people and their needs and the working environment on the one hand, and the organizational structure, computer systems and the necessary work tasks on the

other.

The central concern at this stage is the identification of alternative: alternative social arrangements to meet social objectives and alternative technical arrangements to meet technical objectives. All the social and technical alternatives are brought together to produce socio-technical alternatives. These are ranked, first, in terms of their fulfillment of the

above objectives, and second, in terms of costs, resources and constraints – again both social and technical – associated with each objective.

The outputs of this stage are the computer task requirements, the role-set, the people tasks and the social aspects. These outputs become inputs to the next stage of the methodology, that is, the design of the human-computer interface.

The role-set, the people tasks and the social aspects are also major outputs of the methodology.

The inputs of this stage are the entity model derived in stage 2 of the methodology, and the computer tasks, role-set and people tasks derived in stage 3. This fourth stage concerned with the technical design of the human-computer interface and makes specific decisions on the technical systems alternatives. The ways in which users will interact with the computer will have an important influence on whether the user accepts the system.

A board decision will relate to whether to adopt batch or on-line facilities. In on-line systems, the user communicates directly with the computer through a terminal or workstation. In a batch system, transactions are collected, input to the computer, and processed together when the output is produced. This is then passed to the appropriate user. Considerable time may elapse between original input and response.

Once human-computer interfaces have been defined, the technical requirements too fulfil these can also be designed. These technical requirements become the output of this stage and the input of stage 5, the design of technical subsystem

s. The human-computer interface definition becomes a major output of the methodology.

The inputs to this stage are the entity model from stage 2 and the technical requirements from stage 4. The former describes the entities and relationship for the whole area of concern, whereas the latter describes the specific technical requirements of the system to be designed.

After working through the first stages of Multiview, the technical requirements have been formulated with both social and technical objectives in mind and also after consideration of an appropriate human-computer interface. Therefore, n

ecessary human considerations are already both integrated and interfaced with the forthcoming technical subsystems.

At this stage, therefore, a largely technical view can be taken so that the analyst can concentrate on efficient design and the production of a full systems specification. Many technical criteria are analyzed and technical decisions mad e which will take into account all the previous analysis and design stages. The final major outputs of the methodology might include:

The application subsystem which is concerned with performing the functions which have been computerized from the function chart.

The information retrieval subsystem, which is for responding to inquiries about data, stored in the system. The database in which all the data are organized. The database maintenance subsystem, which permits, updates to the data and provides the information necessary to check for data errors.

The control subsystem which checks for user, program, operator and machine errors and alerts the system to their presence.

The recovery subsystem, which allows the system to be repaired after an error, has been detected. The monitoring subsystem, which keeps track of all system activities for management, purposes.

These subsystems cover all the things that have to be done by the computer system and the people operating it. These parts, or subsystems, may be implemented in different ways and in different combinations.

A Multiview can be referred to as a frame work, which is an overview, used to understand the problem situation and its related technical and human characteristics and needs. It is a contingency framework, which emphasizes contingent approach within the methodology rather than between methodologies.

It helps to focus; and helps in the increase in structure and progressive development of information systems. Multiview provides a detailed study on the organisation by looking at it main purpose and problem areas. Large teams

of analysts on a complex situation can use it and an individual system analyst working on a small system development can also use it.

Multiview methodology covers computer-related questions and also matters relating to people and business functions. Multiview provides a set of tools and techniques that can be adjusted to suit a particular problem. Tools such as a rich picture, Data flow diagram, entity models, etc…

The system analyst to form a diagrammatic representation or a pictorial form of the organisation can use tools such as the rich picture; it can be used to show the interaction, gathering, shifting and the interpreting of data. This tool explain what the organisation is about, the conflicts in the organisation. Other tools are the Data Flow Diagram (DFD) which is used to show a sequence of event.

Multiview gives some key definitions of the purposes, which are furthered by human activity system. It takes peoples interest into consideration, seeks to fit the computer into peoples’ lives, it allows users to participate in the analysis and design o f the system they will be using. Some tools in Multiview aids user and analysts to predict the future environment so to better define the social-technical alterations. The Multiview is compared with reality.

Clients/users are shown a proposed model by what is called a conceptual model; it is drawn together as a system to perform the organisation objectives, known as a system chart. A medium of communication between the architect and the clients enables the right design to be selected. The Multiview

is concerned with the job satisfaction of users; it seeks to reduce the frustrations in the present working system.

In this methodology the skills of different analysts and the situation in which they are constrained to work is taken into account for the system being developed. Another strength of Multiview is that users are rated in three categories, trained operators, routine users and casual users. The Multiview recognizes technology, task people and the organisation. Participation enables valuable knowledge and skills of the workforce to be incorporated in the final system.

With the aid of the people in the organisation the analysts will be familiar with the organisation, task and people which the system must fit. Making users participate in the systems development will show commitment and confidence in the final installed system if they have had a hand in its development. Participation of users in system development ensures job satisfaction.

Participation will enhance the methodology in use for systems development.

Multiview provides a complete solution to problems of information system analysis and design. It is a flexible approach to systems development in the sense that it provides an alternative to choosing between different methodologies. Its stages are parallel to those of the other methodologies.

It seeks the development of a complete system covering both technical and human terms with human and computer interface issues. It places a great deal of emphases on the technical and human views.

Multiview has caused great user dissatisfaction with computer systems. They can only see a working system only after implementation; too much time is spent on the development stage. The Multiview is time consuming. Multiview as a methodology takes time to learn. Some stages of the methodology are sometimes omitted and others are carried out in a different sequence from what is expected. Multiview is sometimes not fully explored, the use of the techniques often va ry. In some situations the tools and techniques are not appropriate to the problem situation.

Multiview is more users oriented, sometimes users do not want to participate, or they may not co-operate fully, which means that it is not possible to interview all members of staff/users. A full analysis of the human activity may no be

carried out. Multiview often does not give sufficient guidance. The background of analyst and users can affect the system development phase.

Multiview has been criticized for being over complex, there are five stages and they all have sub stages. It specifies in great detail every possible task that might conceivably be thought to be relevant, all of which is expected.

Multiview requires significant skills in its use and processes; the skills are often difficult to acquire which is vital to the system analyst developing system. In some occasion the objective of the system being developed is displaced due to the methodology. The Multiview can be used to predict future environment; this can lead to invalid assumptions being made.

There are some circumstances where Multiview is not particularly suitable, it cannot be used for all problem situations.(Avison D. E. and A.T. Wood-Harper 1990)

A series of iterations, which are not shown in the classical model, does not exhibit the step by step, top-down nature of the waterfall model. Stages are carried out in a different sequence from that expected. Multiview requires a high level of partici pation for the development of a successful information system.

Because it is a multi view approach, it covers computer-related questions and also matters relating to people and business functions. The usage and ways in which Multiview operates are the key tools to its success so far.

It aids analysts in defining issues related and tasks related areas of an organization. An issue related question could be;

"what do we hope to achieve for the company by introducing computers?". A task related question is; "what job is the computer go ing to have to do?" Multiview is used to understand the distinction between the two and also enable analysts address such important issues.

Multiview could be used in the analysis of human activity. The very general term human activity is used to cover any sort of organization, for example an individual, a company, a club and so on. The methodology enables us to focus a

particular view of human activity concerns. This Weltanschauung or assumption or worldview aids in forming the basis for describing the system requirements. These assumptions are the main purpose of the organization.

Multiview could also be used so as to provide the problem owner with a rich picture of the problem situation. The picture would represent a subjective and objective perception of the problem situation in a diagrammatic and pictorial

form, showing the structure of the process and their relation to one another. This is a useful part of the methodology because elements of the rich picture would include the clients of the system. These aids in explaining the problem areas and the likely places that would b e charged or that needs serious attention.

The use of data flow diagrams (DFDs) helps to break down complexities to less complex situations. Each DFD would show the sequence of events explicitly. The DFDs as well as any hierarchical model are the major steps in defining how problems would be solved. Multiview also acts as a very good methodology by the use of Entity models. In developing an entity model, the problem solver extracts and names entities from the are of concern. Relationships between entities

are also established so as to be more explicit to the problem owner. A good model will require a good understanding of the problem situation in order to decide which entities are important.

A major use of this framework is the analysis and design of the socio technical aspects (user involvement). It gives the user basic rights to control the flow of the implementation to suite their requirements. It is believed that the acceptance and ope ration of the system will be enhanced. Human considerations such as job satisfaction, task definition, morale and so on are just as important technical considerations.

Here we would like to illustrate the contingency aspects of Multiview, that is, choice of tools and techniques within the framework and the adaptation of the structure of the methodology to suit the needs of particular situation. The first phase of Multiview is an analysis of human activity. Our familiarization process could have two strands. We can carry out a survey of computer applications for the organization as well as talk to professionals working there. If it is obvious from our survey that there is no existing IS that could be used 'off the peg', then we would have to develop our own.

Having established that it is necessary to develop an IS, we have to consider possible frameworks and discuss them with management of the organization. Thus the methodology which is appropriate for the application area and flexible

enough is Multiview. There should also be consideration for prototyping. This facilitates the demonstration of aspects of a potential system to be made without any irreversible work being done on the real system.

Reviewing and correcting of DFDs, EMs.

Quality: Mutual agreement on settings.

Cost: Determined according to scope of project.

Improve business status and needs.

Satisfactory Human Computer Interface.

Rapid Application Development teams.

Designers of GUI.

Systems analysts and market researchers.

Students: undergraduates and 'over' graduates.

Evaluators.

Organizations using it. How does it further their aim.

People using it. How it fits into their activities.

Input and Output. How users relate to it.

Performance: Information processing.

Technicalities: Framework handling all the above.

When the system builder presents the system for acceptance testing, the analyst and user have to ask the question:

"Does the system meet the requirements?" More accurately they have to ask the following questions:

Does the system actually work, or are their bugs in programs?

Does it handle the whole of the information model?

Are all entities and functions in there?

Does it accept the socio-technical objectives?

Are the people using it happy? Human computer interaction.

Is it supporting the human activity system?

5.2.2 User Involvement from Scratch

A quick delivery of the skeletal working system can be made which will test out design principles of the system with users, who can then be involved particularly in the construction of the new system. "A prototype can be used as a tangible starting point for discussions. It might be possible to use the prototype as a basis for operational systems; it becomes the operational system after much iteration when users regard it as being satisfactory. We also have to set the requirements in such a way that it is also useful to various professional groups and managers". [Avison, D.E., Shah, H.U. and Wilson, D.N. 1994]

Investigation of the organization must be solidly carried out, in particular by discussing the application are with key members of staff, and possible drawing of business boundaries around the area affected by the IS. Deciding on a

boundary is a delica te issue and must be confirmed with the client. Use of rich picture, DFDs, Entity models.

In order to apply this framework we need to look at the involvement of the construction of a requirements definition, again in terms of data collection and outputs, set out by the system owners. People with a 'say' in the project include staff groups, management and clients. User views are recorded via interviews and group sessions led by the users themselves. This is an application method of Multiview. Users are encouraged to experiment with prototypes to determine which approach would be the most app ropriate. Issues to be considered include:

When is the system most usable

Who would use it most

Would it be highly acceptable

How is it used and what would be the end product?

What it would do for the organization.

The task that has to be done (from the function chart); for example, time table for certain members of staff and daily diary sheets, work allocations and the detailed function within each. The data that has to be collected during each

transaction (from the entity/event model); for example the staff's name and address is collected, and the details of each client are collected when transactions are logged. The type of input method (from the socio-technical design stage); for example, data recording on ha nd held recorders or on paper forms.

The sort of computer system that would be used (from the socio-technical stage); for example, the prototype, a minicomputer system capable of processing batches of data coming from the workers (including direct input from the data recorders) and with o n-line inquiry facilities. The nature of the dialogue that would have to take place and the style would be appropriate to each (from the human computer interaction); for example, menu mode for application selection

and forms mode for data entry and for re trieval of individual items.

Maintenance must be considered during the application phase, activities that have to take place in order to keep the data up to date and correct. This is concerned with transactions; amendments, deletions and insertions of the application structures of the data. The response will give proof that the data has been stored. Procedures need to be provided to:

Insert new records

Amend existing records

Delete old records

Procedure proof lists

Many of the insertions, amendments and deletions will be carried out as part of some application.

Control is an important aspect of any application, but has particular importance in the environment because inaccurate information could lead to incorrect treatment (or worse) and there are privacy implications, as the system will contain personal data . There are many aspects of control in a computer system which must be considered if the system is going to prove useful. In this section we are concerned with the controls that are built into the system and its operation. For applicability reasons we kno w what the system is supposed to be doing, we need to build features into the system that ensure that these requirements are being fulfilled.

Before any system is applied great concern must be put into the recovery stage of the project. Computer systems will break down due to software and hardware failures. During applicability, specification takes into account preparation for

the failures and the recovery from failures when they have been corrected. Understanding the possible problems and how to solve them by client would be considered during this stage. Though it is possible to build recovery routines for common mistakes into the programs and procedures, and then train a few 'trouble shooters' who have freer access to data and procedures and can therefor correct any unusual errors. The users must know the procedures to undergo after

an error has occurred.

Multiview is applicable under various situations. The analyst(s) have to understand the business needs and technical requirements of the system and its users. Hence they apply Multiview in circumstances such as...

---- When application area is not clearly defined.

---- When the organization isn't familiar with IS.

---- Manual system not meeting requirements anymore.

---- Users interest in IS development stages.

---- Upgrading current IS.

Merise is a widely used and rapidly growing methodology within the EEC. It was developed in France in the early eighties. It is now the foremost methodology applied within the Information systems development in France.

There are however variations in the Merise technique; differing through the approach to model design and in the vocabulary used.

There are two approaches to Merise

The first approach proposed for Merise consists of six stages, which follow consecutively.

The objective to this stage is to identify the goals of the business with its information systems requirements. This is done by breaking down the business into domains. For instance a company may consist of the following domains:

Purchasing

Research and Development

Manufacturing.

Sales and distribution.

Personnel.

Quality control.

Finance.

The next step involves identifying activities within the business which are usually shown in terms of strategic operations like designing products, selling them, buying new material, managing staff and distributing products. After the above domains and operations have been identified operations are allocated to their corresponding domains:

Sales and distribution Selling and delivering products.

It is further necessary to identify the critical success factors based on the operation/domain pairings. Then proceed to identifying the information systems needs of the domain.

The objective of this stage is to examine each of the identified domains in the previous stage separately and an in-depth study of how the project is to be implemented and ways that they interface.

The detailed study is carried out ‘project’ by ‘project’ and can be broken down to two main stages.

This consists of developing a file of alternatives from aspects of the preliminary study report. The file takes stock of the existing situation and by taking into account the direction of management. To suggest alternative scenarios of the organization that it wishe3s to implement in order to reach the future target, which has been fixed for the current project.

The project team then draws up requirement specification for users. The use of modern technology and tools of modeling and prototyping.

This stage develops the technical architecture of the various transaction programs or batch streams and the physical data models necessary for their execution. The expected results are the requirement specification for development, which is an indispen sable file to software productivity.

This stage involves programs being coded. Teams are established and support given. The project specifications come from the technical design and the detailed study.

The development consists of three parts;

Testing and debugging

Integration of the transactions and the batch streams.

Time is devoted to debugging programs and integrating as to analysis and design.

The implementation of the new applications requires great deal of time. The implementation involves;

Setting up and initializing databases

Possible installation of new computer hardware and software.

Writing-up user manuals

Training users

Parallel running

Cutover to the new system.

The maintenance of applications will prolong their life and keep them up to date until they are obsolete. Maintenance requires considerable vigor and organization within the business implying the appointment of specialized staff and the contr9ol of var ious versions of the applications and their associated documentation.

The second design approach of Merise aims to deign the Information systems requirements for each domain of the business be following a modeling logic consisting of three levels;

Conceptual, Logical/Organizational and Physical

The three levels of Merise corresponds to different concerns

Conceptual

The information system is represented independently of its organization and of the physical and computing means that it could use. The aims of this level are to answer the questions what? And to understand the essence of the problem.

The rules evidenced at the conceptual level are the ‘management rules’ of the domain under the analysis e.g.

A teacher can give only one type of lesson

A man can be married to several women

PT = PU * Q

All orders should be written

The two models proposed by Merise of the conceptual level are the conceptual data model (CDM) and the conceptual

processing model (CPM).

Logical/Organizational level

At the logical level all the organizational alternatives are identified in order to discover who will do what, where, when and how the processing will be carried out.

The objective of this level is to answer the questions who? Where? when?, why?, and how?.

The rules brought to light at the logical/organizational level are the organizational rules of the domain under analysis.

E.g.

Delivering should start at 9 a.m.

The financial director must check any order

Physics lectures must always take place in room 101

The two models proposed by Merise at the conceptual; level are the logical data model (LDM) and the Logical

processing model (LPM).

Physical level

At the physical level all the technical alternatives are identified which make it possible to

define all the computing needs.

The objective of then physical level is to answer the questions with what means?

The rules brought to light at the physical level and the ‘technical rules’. The Merise method the approach by levels is used at all stages order to model the Information system.

Merise is a predominantly soft methodology; thus its approach is human centered. Merise emphasizes on not neglecting the human factor, in doing so the following pointers are taking into account.

It is necessary to learn the skill of motivation people before embarking on the project. In doing so the people must know the gains in using Merise in terms of competence, quality and maintenance. It is also necessary to have a team

well trained in Mer ise and not to forget the users who should be involved and also trained. Besides for the project to succeed its necessary to have the project leader with good experience in Merise to instill confidence.

Another factor considered is that of the three cycles. The three cycles, which are the life cycle, an abstraction cycle without which anything works and of course the decision cycle. This clearly defines the stages of the project or the size of the pr oject.

Yet another factor is to make people accept the Merise formalization. In doing so Merise discourages the use of heavy handedness and encourages pragmatism. It should also be noted that Merise could be customized and adapted.

Adopting good tools is a further factor considered in Merise. This factor discourages the use of drawing by hand instead of the more productive application generators it is also necessary to install a common dictionary to store the designers specifications

Last but not least factor is that the Merise project must have a leader, as should all projects. The leader is required to plan the various task of the project and to decide who must do what, where and when and to follow the progression of the work whi lst controlling it at regular intervals.

1. Checkland, P. (1981) Systems Thinking, Systems Practice.

3rd Edition, Wiley, Chichester.

2. Avison, D.E., Shah, H.U. and Wilson, D.N. (1994) Information Systems Development Methodologies: a classification according to problem situations. Journal of Information Technology, 11.

3. Avison, D.E and Fizgerald, G., (1997) Information Systems Development: Methodologies, Techniques and Tools.

2nd Edition.

4. Jackson, M.A., (1977) Systems Development. Prentice Hall, 4th Edition, Hemel Hampstead.

5. Flynn, D.J., (1992) Information Systems Requirements - Determination and Analysis. McGraw-Hill, Maidenhead,

Berkshire.