Software Development Methodologies
Software Development Methodologies
1. Introduction
2. Agile Software Development Methodology
3. Crystal Methods Methodology
4. Dynamic Systems Development Model Methodology
5. Extreme Programming (XP) Methodology
6. Feature Driven Development Methodology
7. Joint Application Development (JAD) Methodology
8. Lean Development (LD) Methodology
9. Rapid Application Development (RAD) Methodology
10. Rational Unified Process (RUP) Methodology
11. Scrum Methodology
12. Spiral Methodology
13. Systems Development Life Cycle (SDLC) Methodology
14. Waterfall (a.k.a. Traditional) Methodology
Introduction
A software development methodology or system development methodology in software engineering is a
framework that is used to structure, plan, and control the process of developing an information system.
There are the following methodologies:
Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which
typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all the
tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design,
coding, testing, and documentation. While iteration may not add enough functionality to warrant releasing the
product, an agile software project intends to be capable of releasing new software at the end of every iteration. At
the end of each iteration, the team reevaluates project priorities.
Agile methods emphasize realtime communication, preferably face-to-face, over written documents. Most agile
teams are located in a bullpen and include all the people necessary to finish the software. At a minimum, this
includes programmers and the people who define the product such as product managers, business analysts, or
actual customers. The bullpen may also include testers, interface designers, technical writers, and management .
Agile methods also emphasize working software as the primary measure of progress. Combined with the
preference for face-to-face communication, agile methods produce very little written documentation relative to
other methods.
Crystal Methods Methodology
Alistair Cockburn developed the Crystal Methods approach. His focus is on the people, interaction, community,
skills, talents, and communications with the belief that these are what have the first-order effect on performance.
Process, he says, is important, but secondary.
Cockburn's philosophy translate into a recognition that each team has a different set of talents and skills and
therefore each team should use a process uniquely tailored to it. And it means that the process should be
minimized - barely significant.
The use of the word “crystal” refers to the various facets of a gemstone - each a different face on an underlying
core. The underlying core represents values and principles, while each facet represents a specific set of
elements such as techniques, roles, tools, and standards. Cockburn also differentiates between methodology,
techniques, and policies. A methodology is a set of elements (practices, tools); techniques are skill areas such
as developing use cases; and policies dictate organizational “musts”.
The main goal of XP is to lower the cost of change in software requirements. With traditional system
development methodologies, like the Waterfall Methodology, the requirements for the system are determined and
often “frozen” at the beginning of the developmentproject. This means that the cost of changing the requirements
at a later stage in the project - something that is very common in the real-world can be very high.
XP Core Practices
The core practices of Extreme Programming, as described in the first edition of “Extreme Programming
Explained” can be grouped into four areas (12 practices) as follows:
Continuous Integration
Design Improvement
Small Releases
Shared understanding
Simple design
System metaphor
Collective code ownership
Coding standards or coding conventions
Programmer welfare
In the second edition of “Extreme Erogramming Explained” a set of corollary practices are listed in addition to the
primary practices.
The core practices are derived from generally accepted best practices, and are taken to extremes:
Interaction between developers and customers is good. Therefore, an XP team is supposed to have
a customer on site, who specifies and prioritizes work for the team, and who can answer questions as
soon as they arise. (In practice, this role is sometimes fulfilled by a customer proxy.)
If learning is good, take it to extremes: Reduce the length of development and feedback cycles. Test
early.
Simple code is more likely to work. Therefore, extreme programmers only write code to meet actual
needs at the present time in a project, and go to some lengths to reduce complexity and duplication in
their code.
If simple code is good, re-write code when it becomes complex.
Code reviews are good. Therefore XP programmers work in pairs, sharing one screen and keyboard
(which also improves communication) so that all code is reviewed as it is written.
Testing code is good. Therefore, in XP, tests are written before the code is written. The code is
considered complete when it passes the tests (but then it needs refactoring to remove complexity). The
system is periodically, or immediately tested using all pre-existing automated tests to assure that it
works. See test-driven development.
It used to be thought that Extreme Programming could only work in small teams of fewer than 12 persons.
However, XP has been used successfully on teams of over a hundred developers.
FDD proceeds to address the items above with this simple process (numbers in brackets indicate the project time
spent):
JAD focuses on the business problem rather than technical details. It is most applicable to the development of
business systems, but it can be used successfully for systems software. It produces its savings by shortening the
elapsed time required to gather a system's requirements and by gathering requirements better, thus reducing the
number of costly, downstream requirements changes. Its success depends on effective leadership of the JAD
sessions; on participation by key end-users, executives, and developers; and on achieving group synergy during
JAD sessions.
In contrast to the Waterfall approach, JAD is thought to lead to shorter development times and greater client
satisfaction, both of which stem from the constant involvement of the client throughout the development process.
On the other hand, with the traditional approach to systems development, the developer investigates the system
requirements and develops an application, with client input consisting of a series of interviews.
Rapid application development (RAD), a variation on JAD, attempts to create an application more quickly through
strategies that include fewer formal methodologies and reusing software components.
RAD (rapid application development) proposes that products can be developed faster and of higher quality by:
By contrast, RUP represents an iterative approach that is superior for a number of reasons:
It lets you take into account changing requirements which despite the best efforts of all project
managers are still a reality on just about every project.
Integration is not one “big bang” at the end; instead, elements are integrated progressively.
Risks are usually discovered or addressed during integration. With the iterative approach, you can
mitigate risks earlier.
Iterative development provides management with a means of making tactical changes to the product. It
allows you to release a product early with reduced functionality to counter a move by a competitor, or to
adopt another vendor for a given technology.
Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or
implemented than to recognize them during planning.
When you can correct errors over several iterations, the result is a more robust architecture.
Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating
panic on the eve of delivery.
Developers can learn along the way, and their various abilities and specialties are more fully employed
during the entire lifecycle. Testers start testing early, technical writers begin writing early, and so on.
The development process itself can be improved and refined along the way. The assessment at the end
of iteration not only looks at the status of the project from a product or schedule perspective, but also
analyzes what should be changed in the organization and in the process to make it perform better in the
next iteration.
Scrum Methodology
Scrum is an agile method for project management developed by Ken Schwaber. Its goal is to dramatically
improve productivity in teams previously paralyzed by heavier, process-laden methodologies.
Scrum is facilitated by a scrum master, whose primary job is to remove impediments to the ability of the team to
deliver the sprint goal. The scrum master is not the leader of the team (as they are self-organizing) but acts as a
productivity buffer between the team and any destabilizing influences.
Scrum enables the creation of self-organizing teams by encouraging verbal communication across all team
members and across all disciplines that are involved in the project. A key principle of scrum is its recognition that
fundamentally empirical challenges cannot be addressed successfully in a traditional “process control” manner.
As such, scrum adopts an empirical approach - accepting that the problem cannot be fully understood or defined,
focusing instead on maximizing the team's ability to respond in an agile manner to emerging challenges.
Spiral Methodology
The Spiral Lifecycle Model is a sophisticated lifecycle model that focuses on early identification and reduction of
project risks. A spiral project starts on a small scale, explores risks, makes a plan to handle the risks, and then
decides whether to take the next step of the project - to do the next iteration of the spiral. It derives its
rapiddevelopment benefit not from an increase in project speed, but from continuously reducing the projects risk
level - which has an effect on the time required to deliver it. Success at using the Spiral Lifecycle Model depends
on conscientious, attentive, and knowledgeable management .It can be used on most kinds of projects, and its
risk-reduction focus is always beneficial.
The spiral methodology extends the waterfall model by introducing prototyping. It is generally chosen over the
waterfall approach for large, expensive, and complicated projects.
1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a
number of users representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down
system, and represents an approximation of the characteristics of the final product.
4. A second prototype is evolved using four steps:
Evaluate the first prototype and identify its strengths, weaknesses, and risks.
Define the requirements of the second prototype.
Plan and design the second prototype.
Construct and test the second prototype.
5. At the project sponsor's option, the entire project can be aborted if the risk is deemed too great. Risk factors
might involve development cost overruns, operating-cost miscalculation, or any other factor that could result in a
less-than-satisfactory final product.
6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary,
another prototype is developed from it according to the fourfold procedure outlined above.
7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final
product desired.
8. The final system is constructed, based on the refined prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis
to prevent large-scale failures and to minimize downtime.
Often, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless
of the type of model chosen or devised for any application, and is usually done in parallel with the development
process. Some methods work better for specific types of projects, but in the final analysis, the most important
factor for the success of a project may be how closely the particular plan was followed.
The perceived advantages of the waterfall process are that it allows for departmentalization and managerial
control. A schedule is typically set with deadlines for each stage of development and a product can proceed
through the development process. In theory, this process leads to the project being delivered on time because
each phase has been planned in detail.
In practice, waterfall development often falls short of expectations as it does not embrace the inevitable changes
and revisions that become necessary with most projects. Once an application is in the testing stage, it is very
difficult to go back and change something that was not thought of in the concept stage. Alternatives to the
waterfall model include joint application development (JAD), rapid application development (RAD), sync and
stabilize, build and fix, and the spiral model.