System Development Methodologies
a framework for comparison

MSIS 488 - Information Systems Analysis - Fall, 2002


Abdellatif Benzzine

Table of contents


System development methodology

Components of a methodology

Criteria for system development methodologies comparison

Comparison of the waterfall methodology and SCURM methodology




The purpose of this paper is to define what a system development methodology is? and determine a framework for the comparison of any two system development methodologies. This framework will determine the criteria for comparison of any given methodologies.

First, we will well define a system development methodology, its major components and its main purpose, then we will list the criteria for the comparison study. In this paper we have the compariosn of two methodologies as a case study of two broads categories of system development methodologies, the waterfall and SCRUM.

Table of contents

System development methodology

In the following section we will focus on the definition of a system development methodology and give some background information on the essence of system development methodologies.

The whole purpose of system development is the enhancement of the productivity of the organization and the group of people working in that organization, as system development got bigger there was a need to systemize the process of system development and come up with a set of steps that are required for any system development.

The system development life cycle is a common methodology used in all most every organization, as the system development projects got bigger and the discipline of software enginnering begun to set some standards ot its own a lot of methodologies have seen light and were put together by organizations seeking success according to their own measurement of success.

Before we get to further details about various system development methodologies, we would like to give a basic definition of a sytem development methodology. it's " a standard process followed by an organization to conduct all the steps necessary to analyze, design, implement, and maintain information systems" [1]

A methodology is also defined as follows " A method describes the activities involved in defining, building, and implementing a system; a method is a framework. Since a method is a logical process for constructing systems (process), it is known as a metaprocess (a process for modeling processes). [2]

The definition does not mention the reason why the organizations want to follow those steps in system development, but it seems very obvious that one of the goals was to facilitate tracking problems whenever they might occur, and build better and successful systems.

Table of contents

Components of a methodology

As stated in the definitions above, the methodology is a process, a set of steps to follow in system development, it varies from organization to organization. But the main components of a methodology are the same. Among the components are tools ande techniques used in all phases of the development of the system.

A methodology has micro and macro components. The macro components define the overall flow and time-sequenced framework for performing work. The micro components include general design rules, patterns and rules of thumb. General design rules state properties to achieve or to avoid in the design or general approaches to take while building a system. Patterns are solutions that can be applied to a type of development activity; they are solutions waiting for problems that occur during an activity in a method. Rules of thumb consist of a general body of hints and tips.[3]

during the research for writing this paper we found that there are many methodologies and that all of them claim to be for benefit to various kind of projects. We found also that almost all methodologies was built to overcome a shortcome or a problem that the previous methodology can't or does not address very well. Every methodology is better than nothing and each of them improve on the other.

As an example we will cite the problem that most organizations have noticed about the waterfall methodology for system development. Most organizations claimed that this methodology does not allow for change incorporation. as stated by James Bach in his article .[4] Although the waterfall approach mandates the use of undefined processes, its linear nature has been its largest problem. The process does not define how to respond to unexpected output from any of the intermediate processes.[5]

To address this problem a research was launched at these companies ADM, and Easl to find a methodology that manage complexity and unpredictability by allowing a flexible incorporation of environmental changes during the project. A set of controls is developed and the probability of success is increased.

Table of contents

Criteria for system development methodologies comparison

Due to the fact that there are plenty of methodologies and some of them are proprietary, meaning that they are owned by the organization that put them together and uses them, It's quite difficult to put together a framework for a comparison study of methodologies.

To ovecome this difficulty, In the following section we would list and define some criteria that would be helpful for any IT professional involved in a system development project to choose among the existing methodologies to determine which one would fit the project he/she is working on based on a predefined objective.

So, all the criteria would be related to a component of a methodology or one of its phases. As stated in the definition above, a methodology is a set of steps to follow for a system development. One of the difference between the step by step methodologies and the SCURM [6] methodology is that the latter has only two defined processes planning and closure,whereas the waterfalls admit that all processes are defined and well known, and the various step are implemented in a linear fashion. So the first criteria of comparison would be

Processes definition

By process definition we mean does the methodology assume that every step in the development life cycle is well known? and that there is no room for environmental changes ? or does the methodology allow a big deal of flexibility in all stages of the development cycle to incorporate those changes that needs to be incorporated in the project before its closure.

Final product determination

Another criteria would be related to the final product. Does the methodology define the final product early on in the planning stage or does it define it during the project and close to project closure time

Project cost

This criterion is related to the estimation of the cost of the project and at what stage of the project it's done.

Project completion date

Estimation of a schedule of deliverable based on the estimation of the tasks to be accomplished. Is that done up front or as the project progresses?

Responsiveness to environment

This criterion measures the flexibility that the methodology allows to incorporate changes during the project, changes due to the environment, technology, competiotion or other.

Team dynamic and creativity

The steps predefined by the methodology could be an obstacle to creativity among teams, as the linear model suggests that some work needs to be done first by a small group and then the project moves to the next stage.This criterion try to measure the ability of allowing some team work and interactions among the team members.

Role of the upper management

Is management an obstacle in creating a better system, or is the role of management to empower the team by taking care of any obstacles that impact the team performance.

Training and knowledge

Does the methodology steps allow training and knowledge transfer during the project or does it put a limitations to what a team member can do and learn.

Probability of success

This criterion measures the probability of success [7] of a project using a certain methodology by embracing a certain degree of complexity and unpredictability.

(a successful project is defined as a system that is useful when delivered)

Table of contents

Comparison of a waterfall methodology and SCURM

Before jumping into the application of the framework above for the comparison of these two methodologies, we would like to define the waterfall methodology as well as the SCURM methodology.

Waterfall methodology is : " In the traditional waterfall methodology, first comes the analysis phase, then the design phase, followed by the implementation phase, with testing completing the process. The team that does each phase is different and there may be a management decision point at each phase transition. This methodology is called the waterfall methodology because each phase flows naturally into the next phase like water over a series of falls. [8]

SCURM is " A variation on Sashimi, an "all-at-once" approach to software engineering. Both Scrum and Sashimi are suited best to new product development rather than extended development. Sashimi originated with the Japanese and their experiences with the Waterfall model. They had the same problems with the Waterfall model as everybody else, so they adapted it to suit their own style. Realizing that speed and flexibility are as important as high quality and low cost they reduced the number of phases to four -- requirements, design, prototype, and acceptance -- without removing any activities, which resulted in overlap of the Waterfall phases. Then they made the four phases overlap. (Sashimi is a way of presenting sliced raw fish where each slice rests partially on the slice before it). Other companies took Sashimi one step further, reducing the phases to one and calling it Scrum. (A scrum is a team pack in Rugby, everybody in the pack acts together with everyone else to move the ball down the field). [9]

After reviewing the definitions of each methodology, it becomes clear that the problem with the waterfall methodology is that the phases are almost independent and the teams working in each phase are different which prevent the teams of taking benefit from the input that they can give to each other and enrich the work they are working on.

On the other hand, the SCRUM relies a lot on the process of team empowerment, the team is given a task and it's the management duty to take away the obstacles preventing the team from achieving their goal to realize the work they were asked to do.

For a comprehensive comparison between the two approaches, we will apply the framework defined in the previous section to the waterfall methodology and the SCRUM methodology. For easiness of reading we will combine the results in the following table.

Methodology Comparison [10]

Criteria of comparison Waterfall SCRUM
Process Definition Required Planning and closure only
Final Product determination Determined during planning Set during project
Project cost Determined during planning Set during project
Completion date Determined during planning Set during project
Responsiveness to environment During planning only Throughout the project
Team dynamic and creativity Limited Unlimited during iterations
Role of upper management A decision point at each transition Eliminating obstacles is the main function
Training and knowledge transfer Before the project Team work during the project
Probability of success Low High

Table of contents


In this paper we tried to build a grill of comparison for system development methodologies. We listed the criteria we judged are important for the evaluation of a system development methodology. methodolgies build upon each other and improve on each other, all methodologies have commun components, implementing a methodology is always better than having none.

The purpose of having a methodology is the increase of probability of success of a system development project. At certain point an organization might need to question the methodology they are using and opt for another one. But how can the organization decide on what methodology to use?

By using this grill of comparison IT professionals and system analyst can adopt a methodology versus another by examinig the 9 criteria we defined in this paper. As the example shows this framework for system development methodologies comparison sounds useful and can help in eliminating some alternatives.

Table of contents


1 Hoffer, Jeffrey A., George, Joey F., and Valacich, Joseph S. Modern Systems Analysis & Design, 2nd ed. Addison Wesley Longman, Inc., 1999. 24 p



4 James Bach. October 1995. "American Programmer"







Table of contents