Methodologies: What and Why?

Software engineering is the practice of using selected process techniques to improve the
quality of a software development effort. This is based on the assumption, subject to
endless debate and supported by patient experience, that a methodical approach to
software development results in fewer defects and, therefore, ultimately provides shorter
delivery times and better value. The documented collection of policies, processes and
procedures used by a development team or organization to practice software engineering
is called its software development methodology (SDM) or system development life cycle
(SDLC).
Methodology as Risk Management
The challenge in selecting and following a methodology is to do it wisely -- to provide
sufficient process disciplines to deliver the quality required for business success, while
avoiding steps that waste time, squander productivity, demoralize developers, and create
useless administrivia. The best approach for applying a methodology is to consider it as a
means to manage risk. You can identify risks by looking at past projects.
If your organization has been plagued by problems resulting from poor requirements
management, then a robust requirements management methodology would be well
advised. Once this problem has been solved, through a repeatable process, the
organization might then streamline its process, while ensuring that quality is maintained.
Every step along the system development life cycle has its own risks and a number of
available techniques to improve process discipline and resulting output quality. Moving
through the development life cycle, you might encounter the following major steps:

Project charter and business case

Definition of the business process and business requirements
Documentation of user, functional and system requirements
Top level architecture, technical approach, and system design
System decomposition into component and unit specifications and design
Coding, unit test planning, and unit test
Generation of test data for unit testing and system testing
System integration and testing
Implementation, delivery and cut-over
Training and user support
System upgrades and routine software maintenance

In addition, you might have support activities throughout the development effort such as:

Configuration management (version identification, baseline management and

change control)

Requirements management and tracability

Quality management (quality assurance, quality reviews, defect tracking)
System engineering reviews (requirements review, prelim. and critical design
reviews, etc.)
Support environment (development tools, libraries, files management, data
management)

Written guidance for all these steps would constitute the core of your methodology. You
can see how it wouldn't take long to fill a number of big binders with development
processes and procedures. Hence, the importance of selecting processes wisely - to
address known risks - keeping the methodology streamlined, and allowing for some
discretion on the part of the project team.
Question: How is a methodologist different from a terrorist?
Answer: You can negotiate with a terrorist. :)

Waterfall Methodology
All projects can be managed better when segmented into a hierarchy of chunks such as
phases, stages, activities, tasks and steps. In system development projects, the simplist
rendition of this is called the "waterfall" methodology, as shown in the following figure:

In looking at this graphic, which was for major defense systems developments, please
note this presumes that the system requirement have already been defined and scrubbed
exhaustively, which is probably the most important step towards project success.
Nevertheless, the graphic illustrates a few critical principles of a good methodology:

Work is done in stages,

Content reviews are conducted between stages, and
Reviews represent quality gates and decision points for continuing.

The waterfall provides an orderly sequence of development steps and helps ensure the
adequacy of documentation and design reviews to ensure the quality, reliability, and
maintainability of the developed software. While almost everyone these days disparages
the "waterfall methodology" as being needlessly slow and cumbersome, it does illustrate
a few sound principles of life cycle development.
Spiral Methodology:
While the waterfall methodology offers an orderly structure for software development,
demands for reduced time-to-market make its series steps inappropriate. The next
evolutionary step from the waterfall is where the various steps are staged for multiple
deliveries or handoffs. The ultimate evolution from the water fall is the spiral, taking
advantage of the fact that development projects work best when they are both incremental
and iterative, where the team is able to start small and benefit from enlightened trial and
error along the way.
The spiral methodology reflects the relationship of tasks with rapid prototyping,
increased parallelism, and concurrency in design and build activities. The spiral method
should still be planned methodically, with tasks and deliverables identified for each step
in the spiral.

Documentation:

The reality is that increased processes usually result in increased documentation. An

improved process produces intermediate work products that represent the elaboration of
the product design at each step in the development life cycle. Where possible,
documentation should be generated using automated tools, so outputs can contribute to
generation of code structures or help generate the code itself.
The difference between hacking and software engineering is professional discipline
applied with common sense. Software quality, reliability, and maintainability are
enhanced by having good documentation for requirements, architecture, interfaces,
detailed design, well-commented code, and good test procedures. Requirements
documentation practices should facilitate your customer's understanding and review of
the real requirements. Software project planning should include estimating the time and
resources to produce, review, approve, and manage such documentation products.
Sample Software Documentation Work Products

Capability Maturity Model Integration (CMMI)

Some years ago the Software Engineering Institute at Carnegie Mellon Institute in
Pittsburgh established standards and guidance for developing software engineering
disciplines and management. This was known as the Capability Maturity Model (CMM),
and its use has become widespread among mature software development organizations,
especially for those developing large scale software in a competitive procurement
environment. Government and corporate software customers have increasingly required
that proposals include information about a software development organization's certified
level of maturity. The CMM had recognized five steps towards organizational software
maturity:

Level 1 (Initial) - Processes are ad hoc and occasionally chaotic. Few processes are defined, and
success depends on individual effort and heroics. (A street-person with a laptop would be at Level
1.)

Level 2 (Repeatable) - Basic project management processes are established to track cost,
schedule and functionality. A process discipline is in place to repeat earlier successes on projects
with similar applications.
Level 3 (Defined) - Management and engineering processes are documented and integrated into a
standard software process. Projects use an approved, tailored version of the organizations
standard software process.
Level 4 (Managed) - Detailed measures of the software process and product quality are collected.
Processes and products are quantitatively understood and controlled.
Level 5 (Optimizing) - Continuous process improvement is aided by quantitative feedback from
the process and from piloting innovative ideas and technologies.

Around year 2000, the SEI introduced the next major evolution along this path calledCapability Maturity Model Integration (CMMI). This builds on the previous
CMM, which is now regarded as "legacy" and no longer supported. You can find
introductions to the CMMI and sample models at this Web link: SEI-CMMI models.

Spiral Model - A New Approach Towards

Software Development
The Waterfall model is the most simple and widely accepted/followed software
development model, but like any other system, Waterfall model does have its own pros
and cons. Spiral Model for software development was designed in order to overcome the
disadvantages of the Waterfall Model.

Enlarge Image
In last article we discussed about "Waterfall Model", which is one of the oldest and most
simple model designed and followed during software development process. But
"Waterfall Model" has its own disadvantages such as there is no fair division of phases in
the life cycle, not all the errors/problems related to a phase are resolved during the same
phase, instead all those problems related to one phase are carried out in the next phase
and are needed to be resolved in the next phase, this takes much of time of the next phase

to solve them. The risk factor is the most important part, which affects the success rate of
the software developed by following "The Waterfall Model".
In order to overcome the cons of "The Waterfall Model", it was necessary to develop a
new Software Development Model, which could help in ensuring the success of software
project. One such model was developed which incorporated the common methodologies
followed in "The Waterfall Model", but it also eliminated almost every possible/known
risk factors from it. This model is referred as "The Spiral Model" or "Boehms Model".
There are four phases in the "Spiral Model" which are: Planning, Evaluation, Risk
Analysis and Engineering. These four phases are iteratively followed one after other in
order to eliminate all the problems, which were faced in "The Waterfall Model". Iterating
the phases helps in understating the problems associated with a phase and dealing with
those problems when the same phase is repeated next time, planning and developing
strategies to be followed while iterating through the phases. The phases in "Spiral Model"
are:
Plan: In this phase, the objectives, alternatives and constraints of the project are
determined and are documented. The objectives and other specifications are fixed in
order to decide which strategies/approaches to follow during the project life cycle.
Risk Analysis: This phase is the most important part of "Spiral Model". In this phase all
possible (and available) alternatives, which can help in developing a cost effective project
are analyzed and strategies are decided to use them. This phase has been added specially
in order to identify and resolve all the possible risks in the project development. If risks
indicate any kind of uncertainty in requirements, prototyping may be used to proceed
with the available data and find out possible solution in order to deal with the potential
changes in the requirements.
Engineering: In this phase, the actual development of the project is carried out. The
output of this phase is passed through all the phases iteratively in order to obtain
improvements in the same.
Customer Evaluation: In this phase, developed product is passed on to the customer in
order to receive customers comments and suggestions which can help in identifying and
resolving potential problems/errors in the software developed. This phase is very much
similar to TESTING phase.
The process progresses in spiral sense to indicate iterative path followed, progressively
more complete software is built as we go on iterating through all four phases. The first
iteration in this model is considered to be most important, as in the first iteration almost
all possible risk factors, constraints, requirements are identified and in the next iterations
all known strategies are used to bring up a complete software system. The radical
dimensions indicate evolution of the product towards a complete system.
However, as every system has its own pros and cons, "The Spiral Model" does have its

pros and cons too. As this model is developed to overcome the disadvantages of the
"Waterfall Model", to follow "Spiral Model", highly skilled people in the area of
planning, risk analysis and mitigation, development, customer relation etc. are required.
This along with the fact that the process needs to be iterated more than once demands
more time and is somehow expensive task.

The Spiral Model: IT Project

Management Solutions
The Spiral Model is the neo approach in IT project system development and was
originally devised by Barry W. Boehm through his article published in 1985 "A Spiral
Model of Software Development and Enhancement".

Enlarge Image
The Spiral Model is the neo approach in IT project system development and was
originally devised by Barry W. Boehm through his article published in 1985 "A Spiral
Model of Software Development and Enhancement".
This model of development unites the features of the prototyping model with an iterative
approach of system development; combining elements of design and prototyping-instages. This model is an effort to combine the advantages of top-down and bottom-up
concepts highly preferential for large, exclusive, volatile, and complex projects.
The term "spiral" is used to describe the process that is followed in this model, as
the development of the system takes place, the mechanisms go back several times
over to earlier sequences, over and over again, circulating like a spiral.
The spiral model represents the evolutionary approach of IT project system development
and carries the same activities over a number of cycles in order to elucidate system
requirements and its solutions.
Similar to the waterfall model, the spiral model has sequential cycles/stages, with each
stage having to be completed before moving on to next.

The prime difference between the waterfall model and the spiral model is that the project
system development cycle moves towards eventual completion in both the models but in
the spiral model the cycles go back several times over to earlier stages in a repetitive
sequence.
Progress Cycles, IT Project Management Solutions
The progress cycle of this model is divided into four quadrants, and each quadrant with a
different purpose;
Determining Objectives (I)------------Evaluating Alternatives (II)
*************************************************************
Planning Next Phase (III)------------Planning Next Phase (IV)
First Quadrant: the top left quadrant determines and identifies the project objectives,
alternatives, and constrains of the project. Similar to the system conception stage in the
Waterfall Model, here objectives are determined with identifying possible obstacles and
weighting alternative approaches.
Second Quadrant: the top right quadrant determines the different alternatives of the
project risk analysis, and evaluates their task with each alternative eventually resolving
them. Probable alternatives are inspected and associated risks are recognized. Resolutions
of the project risks are evaluated, and prototyping is used wherever necessary.
Third Quadrant: the bottom right quadrant develops the system and this quadrant
corresponds to the waterfall model with detailed requirements determined for the project.
Fourth Quadrant: the bottom left quadrant plans the next phase development process,
providing opportunity to analyze the results and feedback.
In each phase, it begins with a system design and terminates with the client reviewing the
progress through prototyping.
The major advantage of the spiral model over the waterfall model is the advance
approach on setting project objectives, project risk management and project planning into
the overall development cycle. Additionally, another significant advantage is, the user can
be given some of the functionality before the entire system is completed.
The spiral model addresses complexity of predetermined system performance by
providing an iterative approach to system development, repeating the same
activities in order to clarify the problem and provide an accurate classification of
the requirement within the bounds of multiple constraints.

Edited by Bruce Cullen

Resources: Project Management - IT Project Management Solutions -IT Project
Management Tools
By Bharat Bista
By Nilesh Parekh

Spiral Methodology
The spiral methodology extends the waterfall model by introducing prototyping. It
is generally chosen over the waterfall approach for large, expensive, and complicated
projects.
At a high-level, the steps in the spiral model are as follows:
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:
1. Evaluate the first prototype and identify its strengths, weaknesses, and
risks.
2. Define the requirements of the second prototype.
3. Plan and design the second prototype.
4. 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-thansatisfactory 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.

If you're looking to hire a project manager with a strong software development

background, contact me and I'd be happy to discuss
your company's project needs and how I can address them.
RAD (rapid application development) proposes that products can be developed faster and
of higher quality by:

Using workshops or focus groups to gather requirements.

Prototyping and user testing of designs.
Re-using software components.
Following a schedule that defers design improvements to the next product
version.
Keeping review meetings and other team communication informal.

There are commercial products that include requirements gathering tools, prototyping
tools, software development environments such as those for the Java platform, groupware
for communication among development members, and testing tools. RAD usually
embraces object-oriented programming methodology, which inherently fosters software
re-use. The most popular object-oriented programming languages, C++ and Java, are
offered in visual programming packages often described as providing rapid application
development.
If you're looking to hire a project manager with a strong software development
background, contact me and I'd be happy to discuss
your company's project needs and how I can address them.
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. Its intended use is for management of software
development projects as well as a wrapper to other software development methodologies
such as Extreme Programming.
Scrum is characterized by:

A living backlog of prioritized work to be done.

Completion of a largely fixed set of backlog items in a series of short iterations or
sprints.
A brief daily meeting (called a scrum), at which progress is explained, upcoming
work is described, and obstacles are raised.
A brief planning session in which the backlog items for the sprint will be defined.
A brief heartbeat retrospective, at which all team members reflect about the past
sprint.

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.
If you're looking to hire a project manager with a strong software development
background, contact me and I'd be happy to discuss your company's project needs and
how I can address them.
References
Jim Highsmith, Agile Software Development Ecosystems
Ken Schwaber and Mike Beedle, Agile Software Development with Scrum