Software Methodologies

Methodologie

Specifics

This model is simple and easy to understand and

use.
It is easy to manage due to the rigidity of the model
each phase has specific deliverables and a review
process.
In this model phases are processed and completed
one at a time. Phases do not overlap.
Waterfall model works well for smaller projects
where requirements are very well understood.

The V-model represents a software development

process which may be considered an extension of
the waterfall model. Instead of moving down in a
linear way, the process steps are bent upwards
after the coding phase, to form the typical V shape.
The V-Model demonstrates the relationships
between each phase of the development life cycle
and its associated phase of testing. The horizontal
and vertical axes represents time or project
completeness (left-to-right) and level of abstraction

Simple and easy to use.

Testing activities like planning, test designing
happens well before coding. This saves a lot of
time. Hence higher chance of success over the
waterfall model.
Proactive defect tracking that is defects are found
at early stage.
Avoids the downward flow of the defects.
Works well for small projects where requirements
are easily understood.

Waterfall method

V-model

Advantages

The waterfall model is a sequential design process, used

in software development processes, in which progress is
seen as flowing steadily downwards (like a waterfall)
through the phases of conception, initiation, analysis,
design, construction, testing, production/implementation
and maintenance.

Iterative method is a mathematical procedure that

generates a sequence of improving approximate
solutions for a class of problems. A specific
implementation of an iterative method, including
the termination criteria, is an algorithm of the
iterative method. An iterative method is called
convergent if the corresponding sequence
converges for given initial approximations.

In iterative model we can only create a high-level

design of the application before we actually begin
to build the product and define the design solution
for the entire product. Later on we can design and
built a skeleton version of that, and then evolved
the design based on what had been built.
In iterative model we are building and improving
the product step by step. Hence we can track the
defects at early stages. This avoids the downward
flow of the defects.
In iterative model we can get the reliable user
feedback. When presenting sketches and blueprints
of the product to users for their feedback, we are
effectively asking them to imagine how the product
will work.
In iterative model less time is spent on
documenting and more time is given for designing.

Agile software development is a group of software

development methods in which solutions evolve
through collaboration between self-organizing,
cross-functional teams. It promotes adaptive
planning, evolutionary development, early delivery,
continuous improvement, and encourages rapid
and flexible response to change.

Customer satisfaction by rapid, continuous delivery

of useful software.
People and interactions are emphasized rather than
process and tools. Customers, developers and
testers constantly interact with each other.
Working software is delivered frequently (weeks
rather than months).
Face-to-face conversation is the best form of
communication.
Close, daily cooperation between business people
and developers.
Continuous attention to technical excellence and
good design.
Regular adaptation to changing circumstances.
Even late changes in requirements are welcomed

Iterative

Agile

Kanban is a method for managing knowledge work with an

emphasis on just-in-time delivery while not overloading the
team members. In this approach, the process, from
definition of a task to its delivery to the customer, is
displayed for participants to see. Team members pull work
from a queue.

Kanban

Optimize inventory and reduce product

obsolescence.
Reduces waste and scrap
Provides flexibility in production
Increases Output
Reduces Total Cost
Improves Flow
Prevents overproduction
Places control at the operations level
Improves responsiveness to changes in demand
Lead time is kept to a minimum
Totally customer driven demand
Better machine utilisation
Reduced or eliminated queues
Limit the spaces for WIP to hide.
Quickly improve factory control and WIP reduction
efforts.

Scrum is a flexible, holistic product development strategy

where a development team works as a unit to reach a
common goal, challenges assumptions of the "traditional,
sequential approach" to product development, and
enables teams to self-organize by encouraging physical
co-location or close online collaboration of all team
members, as well as daily face-to-face communication
among all team members and disciplines in the project.

Scrum

Agile scrum helps the company in saving time and

money.
Scrum methodology enables projects where the
business requirements documentation is hard to
quantify to be successfully developed.
Fast moving, cutting edge developments can be
quickly coded and tested using this method, as a
mistake can be easily rectified.
It is a lightly controlled method which insists on
frequent updating of the progress in work through
regular meetings. Thus there is clear visibility of the
project development.
Like any other agile methodology, this is also
iterative in nature. It requires continuous feedback
from the user.
Due to short sprints and constant feedback, it
becomes easier to cope with the changes.
Daily meetings make it possible to measure
individual productivity. This leads to the
improvement in the productivity of each of the
team members.
Issues are identified well in advance through the
daily meetings and hence can be resolved in
speedily
It is easier to deliver a quality product in a
scheduled time.
Agile Scrum can work with any technology/
programming language but is particularly useful for
fast moving web 2.0 or new media projects.
The overhead cost in terms of process and
management is minimal thus leading to a quicker,
cheaper result.

Extreme Programing (XP)

RAD

Extreme programming (XP) is a software development

Customer focus increase the chance that the
methodology which is intended to improve software quality software produced will actually meet the needs of
and responsiveness to changing customer requirements
the users
The focus on small, incremental release decreases
the risk on your project:
by showing that your approach works and
by putting functionality in the hands of your users,
enabling them to provide timely feedback regarding
your work.
Continuous testing and integration helps to
increase the quality of your work
XP is attractive to programmers who normally are
unwilling to adopt a software process, enabling your
organization to manage its software efforts better.

Rapid application development (RAD) is both a

general term used to refer to alternatives to the
conventional waterfall model of software
development.RAD is especially well suited (although
not limited to) developing software that is driven by
user interface requirements. Graphical user
interface builders are often called rapid application
development tools.

Reduced development time.

Increases reusability of components
Quick initial reviews occur
Encourages customer feedback
Integration from very beginning solves a lot of
integration issues.

Disadvantages
Once an application is in the testing stage, it is very
difficult to go back and change something that was
not well-thought out in the concept stage.
No working software is produced until late during
the life cycle.
High amounts of risk and uncertainty.
Not a good model for complex and object-oriented
projects.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements
are at a moderate to high risk of changing.

Very rigid and least flexible.

Software is developed during the implementation
phase, so no early prototypes of the software are
produced.
If any changes happen in midway, then the test
documents along with requirement documents has
to be updated.

Each phase of an iteration is rigid with no overlaps

Costly system architecture or design issues may
arise because not all requirements are gathered up
front for the entire lifecycle

In case of some software deliverables, especially

the large ones, it is difficult to assess the effort
required at the beginning of the software
development life cycle.
There is lack of emphasis on necessary designing
and documentation.
The project can easily get taken off track if the
customer representative is not clear what final
outcome that they want.
Only senior programmers are capable of taking the
kind of decisions required during the development
process. Hence it has no place for newbie
programmers, unless combined with experienced
resources.

It is less effective in shared-resource situations.

Suppose the upstream station made several parts.
Then a request to make more of the part needed by
the downstream station will have to wait if other
parts have to be made. A buffer is needed to ensure
the downstream station doesn't run out meanwhile.
And, because each part needs a separate signaling
card, the system becomes more complex than if the
resources were dedicated.
Surges in mix or demand cause problems because
kanban assumes stable repetitive production plans.
It is less suited to industries where mix and volumes
fluctuate.
Kanban in itself doesn't eliminate variability, so
unpredictable and lengthy down times could disrupt
the system; poor quality in terms of scrap and
rework also affect its good functioning.
Kanban systems are not suited for manufacturing
environments with short production runs, highly
variable product demand, poor quality products,
and a multitude of product types.
A breakdown in the kanban system can result in the
entire line shutting down.
The throughput of a kanban system is not managed
but is instead a result of controlled WIP and known
cycle times.

Agile Scrum is one of the leading causes of scope

creep because unless there is a definite end date,
the project management stakeholders will be
tempted to keep demanding new functionality is
delivered.
If a task is not well defined, estimating project costs
and time will not be accurate. In such a case, the
task can be spread over several sprints.
If the team members are not committed, the project
will either never complete or fail.
It is good for small, fast moving projects as it works
well only with small team.
This methodology needs experienced team
members only. If the team consists of people who
are novices, the project cannot be completed in
time.
Scrum works well when the Scrum Master trusts the
team they are managing. If they practice too strict
control over the team members, it can be extremely
frustrating for them, leading to demoralisation and
the failure of the project.
If any of the team members leave during a
development it can have a huge inverse effect on
the project development
Project quality management is hard to implement
and quantify unless the test team are able to
conduct regression testing after each sprint.

XP is geared toward a single project, developed and

maintained by a single team.
XP is particularly vulnerable to "bad apple"
developers who:
don't work well with others
who think they know it all, and/or
who are not willing to share their "superior code
XP will not work in an environment where a
customer or manager insists on a complete
specification or design before they begin
programming.
XP will not work in an environment where
programmers are separated geographically.
XP has not been proven to work with systems that
have scalability issues (new applications must
integrate into existing systems).

Depends on strong team and individual

performances for identifying business requirements.
Only system that can be modularized can be built
using RAD
Requires highly skilled developers/designers.
High dependency on modeling skills
Inapplicable to cheaper projects as cost of modeling
and automated code generation is very high.