Tuesday, April 15, 2008

System Development Methodologies

The topic of my choice for my individual report is a critical thinking question from “lecture 2”. The question was ‘There are literally thousands of system development methodologies. Suggest some reasons why there might be so many.’

The question is true to its every word as there are literally thousands of system development methodologies. But before we can dig out the reasons as to why there might me so many we have to think about the ‘System development Methodology’ itself, what is it?

System Development Methodology is a general term applied to a variety of structured, organized processes for developing information technology and embedded software systems. (“http://en.wikipedia.org/wiki/System_Development_Methodology”)

It is the outline used for the planning, structure and to manage the development process of an information system.

Over the years, these frameworks or methodologies have developed and evolved into unique systems. Each having its own pros and cons, strengths and weaknesses for different kind of projects based on various technical, organizational, project and team considerations.

Some examples of such methodologies are:-

  • Avison & Fitzgerald (1991) describe a number of methodologies :
    • Gane and Sarsons (STRADIS),
    • IE (Information Engineering),
    • SSADM (Structured Systems Analysis and Design Methodology),
    • JSD (Jackson Systems Development),
    • SSM (Soft Systems Methodology),
    • ETHICS etc.

There are also others like the Cap Gemini SDM and SDM2 developed by PANDATA, or the Spectrum Structured by Spectrum Systems, and many more.

Although there are as many as thousands of System Development Methodologies available, there are a few which are recognised as acceptable by the DHS or Department of Health and Human Services USA, ‘The Waterfall’, ‘Prototyping’, ‘Incremental’, ‘Spiral’ and the ‘Rapid Action Development or (RAD)’ some of which I will be discussing in details for this report in the following pages.

WATERFALL

First off is the Waterfall. This is linear type framework which is comparable to the straight path from top to bottom like a ‘waterfall’. It is the most simple of all methodologies.

Basic principles:

A Project following the waterfall is separated into sequential phases, with some overlap and splash back acceptable between the phases. It emphasises on the time schedule, budgets and target dates of an entire system at ‘one’ time. Extensive written documentation and through formal reviews by the user is done to maintain tight control over the project life. This is done at the end of most phases before beginning the next phase.

Pros or strengths:

It is resource conserving and is very easy to measure the progress of the system development. The orderly sequence of development steps and strict controls for ensuring the adequacy of documentation and design reviews helps ensure the quality, reliability, and maintainability of the developed software.

The simplicity of this methodology makes it ideal for project managers and project teams with less experience. It is also good for teams with fluctuating compositions.

Cons or Weaknesses:

Inflexible, slow, costly and cumbersome due to significant structure and tight controls. Projects only progress forward, with only slight movement backward which leaves little room for use of iteration, which can reduce manageability if used.

Depends upon early identification and specification of requirements. The excessive documentation and keeping it updated as the project progresses is time-consuming.

Etc.

PROTOTYPING

Prototyping is an ‘Iterative’ type framework. Which means it can repeat a phase if required in the project at any point.

Basic principles:

It’s a complete yet not a stand-alone development methodology, but rather an advancement to manage selected portions of a larger, more traditional development methodology like a spiral or RAD. It reduces inherent risk by breaking a project into smaller segments and provide the flexibility to change in the development process.

Users are involved all through the process which increase the chances of user acceptance of the final implementation. Prototypes are mainly designed with the expectation of discarding it, but in some cases it is possible that the it evolves to meet the user needs. Small scale mock designs are developed following ‘iterative’ modifications until the prototype evolves the meet the user requirements.

Pros or strengths:

“Addresses the inability of many users to specify their information needs, and the difficulty of systems analysts to understand the user’s environment, by providing the user with a tentative system for experimental purposes at the earliest possible time.” (Janson and Smith, 1985)

“Can be used to realistically model important aspects of a system during each phase of the traditional life cycle.” (Huffaker, 1986)

Improves both user participation in system development and communication among

project stakeholders.

Cons or Weaknesses:

Approval process and control is not strict. Incomplete or inadequate problem analysis may occur whereby only the most obvious and superficial needs will be addressed, resulting in current inefficient practices being easily built into the new system.

The Rapid Action Development (RAD) is also similar to the Prototyping and follows the iterative framework.

SPIRAL

It is a unique methodology having a combined framework of linear and iterative frameworks.

Basic principles:

“Each cycle involves a progression through the same sequence of steps, for each portion of the product and for each of its levels of elaboration, from an overall concept-of operation document down to the coding of each individual program.” (Boehm, 1986)

Each trip around the spiral traverses four basic quadrants: (1) determine objectives, alternatives, and constraints of the iteration; (2) evaluate alternatives; identify and risks; (3) develop and verify deliverables from the iteration; and (4) plan the next iteration. (Boehm, 1986 and 1988)

Begin each cycle with an identification of stakeholders and their win conditions, and end each cycle with review and commitment. (Boehm, 2000)

Pros or strengths:

Increases risk avoidance. Useful in helping to select the best methodology to follow for development of a given software iteration, based on project risk.

It can incorporate Waterfall, Prototyping, and Incremental methodologies as special cases in the framework, and provide guidance as to which combination of these models best fits a given software iteration, based upon the type of project risk.

Cons or Weaknesses:

Challenging to determine the exact composition of development methodologies to use for each iteration around the Spiral. Highly customized to each project, and thus is quite complex, limiting reusability. A skilled and experienced project manager is required to determine how to apply it to any given project. There are no established controls for moving from one cycle to another cycle. Without controls, each cycle may generate more work for the next cycle.

The Incremental methodology also has the same combined framework as the spiral.

CONCLUSION

Every project, organisation or system has its own point of view to the road to development and success. Some are small and upcoming where the waterfall system might come in handy as it is small and simple. Thought this system might be cumbersome, it should be an easy task for the smaller and less experienced project teams and managers to handle.

Structural projects such as an architectural system can use the prototyping system.

The emergency evacuation and fallout of a country in case of disaster can use the RAD system which can be developed and monitored on the go.

So as per my discussions above, the reason I can conclude as to why there are so many System Development Methodologies is because all projects and systems require its own road to run. And not each method will be suitable for another one.

References:

“Introduction to Systems Analysis, Topic 19, Rapid Application Development”; J. R. McBride; Copyright 2002 Prentice-Hall, Inc.;

(http://www.csc.uvic.ca/~jmcbride/c375t19.pdf)

“A Survey of System Development Process Models”; Darryl Green and Ann DiCaterino; Center for Technology in Government; February 1998;

(http://www.ctg.albany.edu/publications/reports/survey_of_sysdev)

“System Development Life Cycle Models and Methodologies”; Paul Fisher, James McDaniel, and Peter Hughes; Canadian Society for International Health Certificate Course in Health Information Systems, Module 3: System Analysis & Database Development, Part 3: Life Cycle Models and Methodologies; (http://famed.ufrgs.br/pdf/csih/mod3/Mod_3_3.htm)

“System Development Methodologies for Web Enabled E-Business: A Customization

Paradigm”; Linda Night, Theresa Steinbach, and Vince Kellen; November 2001; (http://www.kellen.net/SysDev.htm)

“Rapid Application Development: A Review and Case Study”; Paul Beynon-Davies; Kane Thompson Centre; December 1998;

(http://www.comp.glam.ac.uk/SOC_Server/research/gisc/RADbrf1.htm)

No comments: