International Journal of Scientific & Engineering Research, Volume 6, Issue 3, March-2015 716

ISSN 2229-5518

The Impact of Structured Methodologies on

Systems Development

Dr Faisal H. Nesayef

Department of Mathematics, College of Science, Kirkuk University, Kirkuk, Iraq

Abstract - The aim of this paper is to give an appreciation of System Development, investigating the traditional approach, and finally give a rationale for the development and introduction of the structured methodologies in systems development.

Index Terms - Human Activity, Information System, Information System Development Life Cycle, Multiview I, Multiview II, Socio- Technique, Structured Methodology , SSADM. System,

—————————— ——————————

Introduction

An information system within an organization starts with the establishment of a strategic information systems plan. The plan will specify priorities for formulating and developing such as system. The environment within which the organization functions is subject to continuous changes. Therefore, the system will also have to change.

1.1 Information System

According to [1], a system is defined as an organized way of conducting something specific. The system which involves sys- tems analysts is called Information System, and these are sys- tems involving computer applications.

Information Systems Development Life Cycle (ISDLC) is de- fined in [2], as information system projects which follow a logi- cal sequence of development phases. This is represented by tradi- tional waterfall model, in which each step usually occurs in a pre- defined order with a review at the end of each stage before the next step can be started. These steps are given in the following:

1. Feasibility Study 2. Requirements Analysis
3. Systems Analysis 4. Systems design
5. System Build 6. Implementation
7. Review and Maintenance

1.2 Methodology

The term “Methodology” is defined in [3] as a standard process followed by an organization to conduct all the steps necessary to analyse, design, implement and maintain information system. Most methodologies follow a software development lifecycle (SDLC). This is regarded as a strategy for developing new infor- mation systems, or replacing an existing system.

1.3 The Objective of Systems Development

According to [1], the objective of the system analysis develop- ment is to produce a system which satisfies the following crite- ria:-
1 The system is a reliable and satisfying the business require-
ments.
2 The system will do what the user requires. This is to meet the business objectives.
3 The cost of the system must be reasonable and justified.
4 The system is flexible and updateable for the minor changes according to the business requirements.
These objectives can be regarded as criteria against which any methodology can be examined. Based on these criteria the fol- lowing section identifies the problems facing systems develop- ment procedures.

1.4 Problems of System Development

In the early years the process of developing an Information Sys- tem suffered from a number of drawbacks as it was carried out mainly by computer specialists programmers, or systems analysts with insufficient knowledge of business needs and lack of consul- tation with the end users. A more structured framework was gradually developed which began to follow a logical sequence of well-defined stages or phases. Hence what is now called infor- mation systems development methodology (ISDM), was estab- lished aiming to develop information systems as far as possible to the field of business and engineering. In order to manage this development a suitable ISDM should be employed.
According to [4], in the early days the people who implemented computer systems were computer programmers who were not necessarily good communicators nor understood the user re- quirements. As a result, the product did not exactly meet the re- quirements of the user and therefore did not facilitate the compa- nies strategic objectives. In some cases the product used to be very expensive and arrived later than the expected date. The us- ers were frequently dissatisfied with the operational systems be- cause their needs had not been clearly identified by the new sys- tem.
Taking into account the criteria indicated in the previous section, on some occasions, a wrong system was delivered, or the system did not work properly accounting to their specifications. Lack of communications and consultation led to delivering a system which did not do what the user wanted it to do. Moreover, many errors were found after the system was implemented resulting in

IJSER © 2015 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 6, Issue 3, March-2015 717

ISSN 2229-5518

high cost and time delay, which was not compatible with the business strategic objectives.
Because the business requirements specifications were ignored, it was difficult to deliver a flexible system which could be updated according to the new functions requirements of the business or- ganization. Companies had few expert programmers who knew what they were doing. They were well paid because they were very difficult to replace. New entrants found it difficult to take over as there was little documentation, and limited techniques. The led to re-write the program from scratch to effect small changes in the user requirements because it was impossible to understand the program without sufficient documentation, partic- ularly if the original programmers had left the company.
There were few courses giving training facilitating analysis and design. This was a particular problem as applications become more complex. Most courses that were available were technical and designed to enable people to program the computer. Many programmers were better in programming than in being teach- ers/trainers, or in the analytical aspects of the job.
As a result, analysis and designed became gradually more im- portant for the purpose of development. There was a change of emphasis in many data processing departments. Some job titles changed to programmer-analyst, and systems analysts resulting in more than one role in the systems development process. To en- sure control of the running of the system, analysts act in a role between business analyst and technical analyst. Business analyst was concerned with organizational and business needs, and communicating these to the technical analysts who were con- cerned mainly with the design of the technical systems which would meet requirements of the organization.

1.5 The Need for Structured Methodology and Its Role

In the discussion of the above the problems of system develop- ment were identified, and it was noted that Structured methodol- ogies have evolved to help address these problems, e.g. the size of the system and its deviance from the user requirements will increase the cost of the developments dramatically. It is indicated in [1], that the discovery of an error at the implementations stage will cost between ten and one hundred times more to fix than if that error was uncovered in the analysis requirements.
The purpose of structured methodology is to provide a frame- work within which the systems development can produce an ef- fective solution to a business problem which requires the use of a computer system and a set of techniques. To achieve this, the methodology must do the following:
• Facilitate communication between all those involved within systems development, i.e, the managers, users, analysts, programmers, etc.
• Provide a set of techniques for standardization purpose.
• Effective review to identify errors in early stages
• Flexibility in business and technological changes.
• Enhance development strategy.
• Facilitate and participate in analysis of the business to address the business and user requirements.

1.6 Methodology and ISD Objectives

ISDM should satisfy objectives identified in the earlier section. Different methodologies are appropriate for different situations, so they can address different objectives. Some of these objec- tives are listed below:
1. The methodology should help the users specify their re- quirements and systems developers to analyse these re- quirements.
2. Provide a systematic method of development so that the progress can be effectively monitored.
3. Time and cost are important factors as the cost should be acceptable and the time spent on development should be limited.
4. Provide a mechanism ensuring that the system is well documented and easily maintained.
5. Flexibility for the changes faced at any stage of the de- velopment process and in the future.
6. Provide acceptance by those people affected by the sys- tem, e.g. The system liked by the stakeholders, who are managers, clients, auditors and users.

1.7 How Methodologies Differ

All structured methodologies have the same approach, but they differ in areas of:

1 The methodology and the business life cycle: This concerns the lifecycles coverage from strategy to implementation and support given to the projects tasks in terms of quality assur- ance and project management.

2 Philosophy of methodology: Science (divide and conquer)

or business (the whole is greater the sum of its parts).

3 The user role in methodology: Addressing the level of which the user is involved including the user participation.

4 The structuredness of the methodology: concerns availabil- ity of manuals and documentation.

5 The size of the system each methodology is aimed at. This is to assess the levels to which each methodology is appro- priate.

6 The techniques within the methodology: This is about the diagramming techniques chosen to address the functions, data and events of the system.

7 CASE tools: Examine the maturity and space of CASE tools support availability.

IJSER © 2015 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 6, Issue 3, March-2015 718

ISSN 2229-5518

2 Multiview

2.1 Multiview I

Multiview perceived ISD as a hybrid process involving computer specialists who build the system and the users. Multiview has been used in small scale projects. It is a contingency and flexible approach, as it is adopted according to the particular situation. Multiview provides a contingency approach within it (opposite to prescriptive).
It is regard in [1], that Multiview as a Methodology including the SSM.As a matter of fact Multiview takes a bit of everything (Multi-view).The philosophy is to move from general to the spe- cific, from conceptual to hard and from issue to task It has five stages where the outputs of each stage can be either input to the following stage or are major outputs of Multiviews is to address the issues such as:
• How can the computer facilitate the aims of an organiza- tion .
• How can it fit within the working environment.
• How can the employers communicate with the machine .
• Which IS processing function is going to be performed .
• Technical specification.
Multiview attempts to address all these questions ,and to involve all the role players (stakeholders).It covers issue –related ques- tions such as what is achieved by the company when installing a computer. It also covers task-related questions such as what jobs is the computer is going to do. The idea behind human computer involvement is that you cannot solve the problem until you know what the problem is. The five stages of multiview can be given in the following:

2.2 Analysis of Human Activity:

Initially Multiview uses soft system approaches to focus on the organization in terms of a better understanding of the problem area. It is based on forming a rich picture of a problem situation. The problem solver is usually the analyst or the project team. The rich picture is used to aid discussion better understanding of the problem by the stakeholders, then a holistic summary will be gathered.
In some cases, the output of this stage is an improved human ac- tivity system, and there will be no further stages necessary. It is that this stage conforms to the criteria drawn earlier, in accord- ance with the question.

2.3 Analysis of Information

The purpose of this stage is to analyse the entities and functions of the application. The input will be the root defini- tion/conceptual model from stage, which has the following pur- poses:

a. Development of the functional model to identify the main functions based on the root definition and DFD's develop- ment.

b. Development of entity model. The entities are identified and named and their relationships are established.

2.4 Analysis and Design of Socio-Technical Aspects

It takes the view that human consideration such as job satisfac- tion, task definition, ect., are just as important as technical con- siderations. The emphasis of this stage is on statement of alterna- tive systems (not on development), and on social and technical issues. The outcome will be the computer task requirements.

2.5 Design of the Human Computer Interface

So far the concerns were about what the system could do. We now consider how we achieve an implementation confirming to requirements. The emphasis is on the technical design of the hu- man-computer interface, and the technical systems alternatives. Also the way the user interacts with the computer in terms of input and output and whether the user accepts the system.

2.6 Design of the Technical Aspects

This stage deals with the specific technical requirements of the IS
being designed. It will consider the following:
• Computers
• Database
• Control and Security
• Maintenance
A number of technical criteria are analyzed and a complete sys- tem is produced

Figure (1) shows the stages involved in Multiview I

IJSER © 2015 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 6, Issue 3, March-2015 719

ISSN 2229-5518

3.1 Multiveiw II

The second version of Multiview was developed in 1996 on- wards. Development and refinement has been carried out from version 1 and the five stages are reduced to four-box structure consisting of the following:-

Organizational analysis –this is equivalent to human activity system analysis

Socio-technical aspects-similar to Multiview I

Technical Design and Construction-similar to stage 4 and 5 in

Multiview I

Multiview II provides a systematic guide to an IS development. The emphasis is placed upon each of the four parts of Multiview II and will change and modify in the light of practical experience and use. Multiview II contains new factors such as prototyping, RAD and DSDM and can be seen as continuous evolution of Multiview I.


Multiview II conforms to the criteria drawn earlier in this work. It is seen how essential it is to involve the user and looks at the sit- uation in a holistic manner other than a programmer developing a system without communication with other stakeholders e.g. man- agement, analysts, users, etc.
Organization Information Analysis
Analysis
The inter-relationship between the seven stage structure and five module of SSADM is given below:-
Table (1) Shows the connections between the seven stages of
SSADM

3.4 Techniques

It is indicated in [2], that the use of a range of techniques are ac- companied with the SSADM approach. One of the means of the analysis of the current system is DFD's. DFD's and LDS are used to provide a logical model of system requirements, and physical design is given with normalized tables and prototyping of the system front end. ELHS are used to help to check the design with end users
Deliver a system
Socio-technical Technical Design and
Aspects Construction
Figure (2) shows the activities involved in Multiview II

3.2 Structured Systems Analysis and Design Methodology

Version 4+(SSADM4+)

3.3 Overview

SSADM was established in 1981 and used as standard IS devel- opment method for UK government projects. Subsequently SSADM became the most popular UK business information sys- tem development methodology, [5]. Version 4+ became available in 1996 to meet the needs of large projects.
The structure of SSADM version 4+ is described in [4], in seven stages numbered from 0-6. These stages are placed in a 5 module framework with each module having its own set of planned time- scales.
Program design as a part of the life cycle is missing in the
SSADM V4+.

3.5 Support Availability

A lot of training, literature ,and other resources are available ow- ing the wide usage of SSADM in the UK. A number of case tools are also available to create diagrams and provide checking of consistency, e.g. SSADM select, etc. There are also many user groups and large number of practical guides exist.

IJSER © 2015 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 6, Issue 3, March-2015 720

ISSN 2229-5518

3.6 SSADM and the Users

SSADM concentrates on the functionality. As the user involve- ment is important, this is carried out during the analysis stage. The design can be checked when the system is tested . The user acceptance can be gained through prototyping which is carried out in stage 3 - Definition of Requirement. Logical models men- tioned earlier can also contribute in user acceptance.

3.7 Strength of SSADM

• Lots of user support in the form of guides, user groups, and training
• Tools and techniques that can be used within other in- formation system development methodologies.
• Availability of trained practitioners.
• Rigorous technique to ensure detailed analysis to ensure system quality.
• Ensures consistency and quality.

3.8 Limitations

• Largely costly in terms of time, staff requirements.
• Designed for large projects, may not be suitable for small projects.
• Rigid approach.
• The costly design flows only discovered in testing may need extensive re- engineering .

4. Comparison

The framework of comparison, and the purpose of comparison is to highlight the differences in techniques, approaches, and the framework between the methodologies. Comparison between methodologies are made under the following features:
• Methodology and the business lifecycle.
• The underlying philosophy of the methodology.
• The structuredness of the methodology.
• The user role in the methodology .
• The size of the system in the methodology aimed at .
• The techniques within the methodology ,eg CASE tools and the methodology
• Flexibility .
• Contingency.
• Documentation

5. Conclusion

To address the problem of the mix-up and who does what, and to follow a standard pattern in systems development was the ap- pearance of a formalized methodology to develop computer ap- plications . This was apparent and resolved by the adoption and introduction of SDLC.
Starting with a situation where the systems development was carried out by the programmer, appreciation of structured devel- opment methodologies was given. Investigation has been carried out into the traditional approach.
Given a set criteria for the successful methodology, the ad- vantages and limitations of Multiview and SSADM were cov- ered. The essay researched into the importance of human in- volvement in the system development and demonstrated the role of the stakeholders to conduct a system development. This is clearly obvious with the structured methodologies.
Finally, under a set of features and functions, a matrix method was implemented to compare Multiview and SSADM with refer- ence to the features of methodologies and reference to the quota- tion of the programmer's role in the system development ap- proach.

References

[1] D. Tudor and I. Tudor, (2010), The DSDM book, Atern Stu- dent workbook, Galatea Training Services Ltd.
[2] P. Bocij, D. Chafffey, A. Greasley, and S. Hickie, (1999), Business Information.Systems: Technology, Develop- ment and Management, Financial Times Management
[3] J. Hoffer, J. George and J. Valacich, (2011), Modern Systems

Analysis and Design (6th). Prentice Hall Publishing.

[4] D. Avison and Fitzgerald, (1998), The Information System
Development Methodologies, McGrow-Hill,
[5] P. Weaver, (1998), Practical SSADM Version 4+, Financial Times Management second Edition Cycle, McGraw- Hill.

IJSER © 2015 http://www.ijser.org