COMPARISON OF SYSTEM DEVELOPMENT METHODOLOGIES

METHODOLOGY DEFINITION

Methodology is a set of general principles that guide a practitioner or manager to the choice of particular method suited to a specific task or project.

SYSTEM DEVELOPMENT METHODOLOGY

System development methodology is a standardized development process that defines as a set of activities, method, best practices, deliverables and automate tools that systems developers and project manager are to use to develop and continuously improve information systems and software.

The systems development methodology is meant to provide a uniform approach to managing systems development while providing sufficient flexibility to choose the techniques and tools best suited for a specific task. It is to be used as a guideline to all of those involved in systems development, acquisition, implementation, and conversion. Each model defines the deliverables that are to be produced during the process as well as the tasks to be performed and who is to perform them. It also defines what should be created and what tasks are likely to be executed to create the deliverable.

A system development methodology “executes” the system development stage of the system life cycle. Consistent with the goal of CMM, methodologies ensure that:

· A consistent, reproducible approach is applied to all projects.
· There is reduced risk associated with shortcuts and mistakes.
· Complete and consistent documentation is produced from one project to the next.
· System analyst, designers and builders can be quickly reassigned between projects
because all use the same process.
· As development teams and staff constantly change, the result of prior work can be
easily and understood by those who follows.

In this paper, the discussion will involve 3 system development methodology which are:

- Rapid Application Development (RAD)
- Structured Systems Analysis And Design Methodology (SSADM)
- EXtreme Programming (XP)

RAPID APPLICATION DEVELOPMENT METHODOLOGY (RAD)

RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles. This has a number of distinct advantages over the traditional sequential development model.

RAD projects are typically staffed with small integrated teams comprised of developers, end users, and IT technical resources. Small teams, combined with short, iterative development cycles optimizes speed, unity of vision and purpose, effective informal communication and simple project management.

The fundamental principle of any RAD methodology is to delay producing detailed system design documents until after user requirements are clear. RAD methodology emphasize gaining user acceptance of the user system interface and developing core capabilities as quickly as possible, sacrificing computer efficiency for gain in human efficiency in rapid building and rebuilding working systems. On the other hand, RAD methodologies can overlook important software engineering principles. The result of which are inconsistent between system modules, noncompliance with standards, and lack of reusability of system components (Bourne, 1994).

There are 4 necessary pillars for the RAD approach:

· Tools such as prototyping software and CASE tools.
· People who must be trained in the right skills.
· A coherent methodology which spells out the proper task to be done in proper order.
· Support and facilitation of management.

RAD has been used successfully in many organizations and is currently gaining more formal support under the auspices of the DSDM consortium. The RAD approach however is not without its pitfalls. DSDM advocates that RAD is only suitable for certain kinds of applications, i.e. those which are interactive, with clear functionality at the user interface, have a clearly defined user group, are not computationally complex and have requirements which are not too detailed and fixed. DSDM advocates that RAD is not suitable for real-time or safety-critical applications or for applications where functional requirements have to be fully specified before any programs are written. Thus RAD would only appear to address part of the applications backlog. Applications suitable for RAD and those not would appear to be at opposite ends of a scale.


STRUCTURED SYSTEMS ANALYSIS AND DESIGN METHODOLOGY (SSADM)

SSADM is a methodology, used in the analysis and design stages of systems development. It was commissioned by the CCTA (Central Computing and Telecommunications Agency) in a bid to standardize the many and varied IT projects being developed across government departments.
Since 1981 SSADM has been further refined and version 4 was launched in 1990. SSADM is an open standard, i.e. it is freely available for use in industry and many companies offer support, training and Case tools for it.
SSADM revolves around the use of three key techniques, namely Logical Data Modeling, Data Flow Modeling and Entity/Event Modeling.

· Logical Data Modeling; This is the process of identifying, modeling and
documenting the data requirements of a business information system.
· Data Flow Modeling; This is the process of identifying, modeling and documenting
how data flows around a business information system.
· Entity Event Modeling; This is the process of identifying, modeling and
documenting the business events which affect each entity and the sequence in which
these events occur.

The SSADM method involves the application of a sequence of analysis, documentation and design tasks concerned with:

· Analysis of the current system / feasibility stage. Analyze the current situation
at a high level. A DFD Data Flow Diagram is used to describe how the current
system works and to visualize known problems.
· Outline business specification / requirements analysis stage. This stage consists
of 2 parts. The first part is researching the existing environment. In this part,
system requirements are identified and the current business environment is
modeled. Modelling conists of creating a DFD and LDS Logical Data Structure for
processes and data structures that are part of the system.

. In the second part, BSO Business Systems Options, 6 business options are
presented. One of the options is selected and built. As a result one of these
options (or indeed a hybrid solution) is adopted and refined. During stage 2 DFDs
and LDS are produced to support each business system option and the final chosen
option. The transition from stage 1 to stage 2 is a key part of SSADM, this is
where we move from a logical model of the current system to a logical model of the
required system, i.e. this is where the DFDs and LDS have to be refined to cater
new/changed requirements.
· Detailed business specification / requirements specification stage. To assist the
management to make a sound choice, a number of business system options, each
describing the scope and functionalities provided by a particular
development/implementation approach, are prepared and presented to them. These
options may be supported by technical documentation such as Work Practice Model,
LDM Logical Data Model and DFD. They also require financial and risk assessments
to be prepared, and need to be supported by outline implementation descriptions.
· Logical data design / logical system specification stage. In this stage,
technically feasible options are chosen. The development/implementation
environments are specified based on this choice.
· Logical process design / logical system specification stage. In this stage,
logical designs and processes are updated. Additionally, the dialogs are specified
as well. The following steps are part of this stage:
I. Define user dialogue
II. Define update processes
III. Define enquiry processes
· Physical design. The objective of this stage is to specify the physical data and
process design, using the language and features of the chosen physical environment
and incorporating installation standards. The following activities are part of
this stage:
I. Prepare for physical design.
II. learn the rules of the implementation environment
III. review the precise requirements for logical to physical mapping and plan
the approach.
IV. Complete the specification of functions.
V. Incrementally and repeatedly develop the data and process designs.

EXTREME PROGRAMMING (XP)

Extreme Programming is a discipline of software development based on four underlying principles:

· Simplicity
· Communication
· Feedback
· Courage.

It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.
XP is designed for use with small teams who need to develop software quickly in an environment of rapidly-changing requirements. It relies on clear communicative code and rapid feedback
The twelve XP practices are:
· The Planning Process, sometimes called the Planning Game.
The XP planning process allows the XP "customer" to define the business value of desired features, and uses cost estimates provided by the programmers, to choose what needs to be done and what needs to be deferred. The effect of XP's planning process is that it is easy to steer the project to success.

· Small Releases
XP teams put a simple system into production early, and update it frequently on a very short cycle.

· Metaphor
XP teams use a common "system of names" and a common system description that guides development and communication.

· Simple Design
A program built with XP should be the simplest program that meets the current requirements. There is not much building "for the future". Instead, the focus is on providing business value.

· Testing
XP teams focus on validation of the software at all times.

· Refactoring.
XP teams improve the design of the system throughout the entire development. This is done by keeping the software clean: without duplication, with high communication, simple, yet complete.

· Pair Programming
XP programmers write all production code in pairs, two programmers working together at one machine

· Collective Ownership
All the code belongs to all the programmers. This lets the team go at full speed, because when something needs changing, it can be changed without delay.

· Continuous Integration
XP teams integrate and build the software system multiple times per day. This keeps all the programmers on the same page, and enables very rapid progress.

· 40-hour Week
Tired programmers make more mistakes. XP teams do not work excessive overtime, keeping themselves fresh, healthy, and effective.

· On-site Customer
An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the programmers have them.

· Coding Standard.
For a team to work effectively in pairs, and to share ownership of all the code, all the programmers need to write the code in the same way, with rules that make sure the code communicates clearly.


DISCUSSION

Over many decades, IS methodologies have been developed and introduced specifically to overcome those problem of software development projects that were perceived to be important at the time. However, until now, no methodology has been wholly successful in fulfilling its objectives, partly because computing is a highly dynamic field, and the nature of both projects and their problems is constantly changing.
All system development methodologies are based from either adaptive methods or Predictive methods. An agile methodology such as eXtreme Programming fall under adaptive method while a waterfall based methodologies such as RAD and SSADM falls under predictive method.

While Adaptive methods focus on adapting quickly to changing realities, Predictive methods, in contrast, focus on planning the future in detail.

Since there are many methodologies available to be adopted, the biggest challenge faced by analyst is to select which methodology to use. To select an appropriate system development methodology for a project, an analyst need to identify the ability to develop system which offered by each methodology.

Each of system development methodologies discussed in this paper has their own approach and emphasize on different area or system development life cycle. The phases/ practices, key components, advantages and disadvantages are simplified by “Comparison of System Development Methodologies” table in Appendix A.


CONCLUSION

It is important to note that system development methodology is developing and it will be revised on an on-going basis. It is to act only as a guideline. Beyond this, the development teams are expected to tailor the deliverables and tasks to the specific project.

As each system development methodology has their own advantages and disadvantages, the selection of an appropriate methodology is necessary precursor to choosing the specific method to be followed. Simply to say, choosing the right methodology for the right project is important in helping to produce better quality product.


REFERENCES

1. Simon Bennet, Steve McRobb, Ray Farmer, Object Oriented System Analysis and Desing using UML, McGrawhill, 2006.
2. Jeffry L. whitten, Lonnie D. Bently, Kevin C. Dittman, System Analysis and Design Method, McGrawhill, 2004.
3. Jeffrey A. Hoffer, Joey F. George, Joseph S. Valacich, Modern System Analysis and Design, The Benjamin/ Cummings, 1996.
4. Jeffrey A. Hoffer, Joey F. George, Joseph S. Valacich, Modern System Analysis and Design, Prentice Hall, 2002.
5. Alan Dennis, Barbara Wixom, Systems Analysis Design, John Wiley & Sons, Inc., Second Edition.
6. Rapid application development,
http://en.wikipedia.org/wiki/Rapid_application_development
7. Development Methodolgy - RAD and JAD,
http://www.credata.com/research/methodology.html
8. What is Extreme Programming?
http://www.extremeprogramming.org/
9. Patrick Emery , The Dangers of Extreme Programming,
http://members.cox.net/cobbler/XPDangers.htm#_Toc530042778
10. XProgramming.com - An Agile Software development resource,
http://www.xprogramming.com/index.htm
11. SSADM, http://en.wikipedia.org/wiki/SSADM
12. Tim Hutchings, BSc, PGC Educational Development, MBCS,
http://www.comp.glam.ac.uk/pages/staff/tdhutchings
13. Structured Systems Analysis and Design Method,http://en.wikipedia.org/wiki/Structured_Systems_Analysis_and_Design_Methodology