Software development methodologies

Ever heard of words like Agile, Scrum and Extreme Programming and you didn’t know what they mean? In the following article we are going to briefly examine the various software development methodologies that are used with a brief reference to some methodologies that were used in the past.

Agile

In order to develop software systems that are capable to change and satisfy continuous requirements, a ‘quick’ approach had to be defined. In the late 80s the RAD (Rapid Application Development) was developed that was an approach of developing systems ‘quickly’ (we need it now and we need it quick). The spiral (link to Wikipedia) system developing lifecycle is used for most part of the system (quickly developing prototypes and adding to them). However, latest, the term ‘RAD’ has been dropped and has been replaced by the word ‘Agile’ to represent better the intention of the project (a project must be ‘agile’). In ‘Agile’ projects, the system is divided and developed in parts and requirements can change anytime. Generally, Agile does not include a specific set of rules, but a ‘guideline’ to building ‘agile’ projects.

Image from: http://en.wikipedia.org/wiki/File:Agile_Software_Development_methodology.svg

Agile and software development (Scrum)

An Agile approach for software development is Scrum. Scrum includes roles and fixed duration meetings. If you ever get involved in a Scrum project you have to be prepared for the following:

  • 15 minute daily meetings involving solving problems and setting priorities
  • 30 day sprints in which a set of functions defined at the ‘product backlog’ are developed
  • A Sprint planning meeting that has 8 hours duration in order to define the product backlog items that are to be developed
  • A role of ‘ScrumMaster’ is set to someone, not to manage the project in a traditional way, but to ensure that all the teams and project members are aligned to the project goals
  • Collaboration is an important factor in Scrum projects. Teams should be able to opperate autonomus and collaboration between members and other teams is expected.

Generally Scrum can be considered as a set of timeboxed (fixed duration) actions (meetings and sprints) using the following artifacts:

  • Product backlog: The requirements document
  • Sprint backlog: The actions that have to be developed for the next sprint. The actions are derived from the requirements document and are planned at the Sprint meeting.

Read more at Agile and Scrum at Wikipedia
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Scrum_%28development%29

Extreme programming (Extreme Project Management)

Probably we are all familiar in one way or another of Extreme programming. Extreme programming is the quickest version of the Agile approach. XP involves working directly with customers to create and implement small pieces of software that have to be compelted in very short times. Developers usually work in pairs, with each one testing the others work. Because of the fact that the project must be developed in a very short time, there have to be strong coding guidelines to ensure quality. Another approach of extreme programming, is that large projects might be broken down into smaller ones in order to satisfy the extreme programming restrictions. Extreme programming is usually used when there are no set of requirements or the requirements are constantly changing and there is a short amount of time available for the project to finish.

The four main tasks that are involved in extreme programming are:

  • Listening
  • Designing
  • Coding and
  • Testing

Unit testing is used heavily in XP in order to ensure quality and unlike Scrum there are no specific set of timebox rules.

Read more on Extreme programming at Wikipedia:
http://en.wikipedia.org/wiki/Extreme_programming
and Cunningham & Cunningham, Inc:
http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap

Rational Unified Process

Rational Unified Process was developed from IBM in order to satisfy modern software projects. It does not include a set of strict rules but an adoptable framework that can be used on the whole or partly according to the organization’s needs. In other words, an organization can use any specific building blocks of Rational Unified Process (RUP) that it thinks might suit its needs.

The RUP defines the following:

  • Roles
  • Work products
  • Tasks

and follows the following practices:

  • Develop iteratively
  • Manage requirements
  • Use components
  • Model visually
  • Verify quality
  • Control changes

and the following iterative processes exist:
1.    Business modeling
2.    Requirements
3.    Analysis & design
4.    Implementation
5.    Test
6.    Deployment

Read more about RUP at IBM:
http://www-01.ibm.com/software/awdtools/rup/

Read more about RUP at Wikipedia:
http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process

No comments yet.

Leave a comment

Comment form

All fields marked (*) are required

Featured FREE Resource: