Software Development Methodologies

by Project-Management.com May 1, 2015

Need a simple project management software to manage your team?
Check-out our valuable and unique Top 15 Web Applications 2015.
Ever heard of words like Agile, Scrum and Extreme Programming and you didnt know what
they mean? In the following article we are
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
der 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.

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 organizations 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