What Do You Mean by Agile Development of A S/W Proj.? Explain Best Practice For Agile Development With Example?
What Do You Mean by Agile Development of A S/W Proj.? Explain Best Practice For Agile Development With Example?
What Do You Mean by Agile Development of A S/W Proj.? Explain Best Practice For Agile Development With Example?
Agile Software Development has proven itself to be one of the most effective
methodologies to develop application software. One of the challenges to the Agile
Software Development approach can be the integration of non‐object oriented sub‐
systems, such as MySQL, Oracle, or other relational database management system
(RDBMS). RDBMS require mapping code to translate between the object model and the
relational model of the database, generally known as “object to relational mapping” (OR
mapping, ORM). Managing and maintaining the mapping is not only time consuming, but
the RDBMS and its schema is often managed under rather restrictive, and potentially
“non‐agile” policies. In addition, data already stored in an RDBMS may become
inconsistent with the changes in the application made by the Agile development team.
The purpose of this white paper is to examine and compare RDBMS with several object
persistence methods within the context of Agile Software Development. We will quantify
and qualify the impact of these methods on the overall velocity and success of an agile
application development project. We believe that there are significant financial and time‐
to‐market advantages in selecting true object persistence tools and methodologies over
traditional relational database system in order to maintain an agile development
approach. In other words, true object persistence tools and methodologies are
necessary to reap true agile development benefits, and therefore achieve the business
advantages of this development process.
Agile software development (also called “agile”) isn’t a set of tools or a single
methodology, but a philosophy
put to paper in 2001 with an initial 17 signatories. Agile was a significant departure from
the heavyweight
document-driven software development methodologies—such as waterfall—in general
use at the time.
While the publication of the “Manifesto for Agile Software Development” didn’t start the
move to agile
methods, which had been going on for some time, it did signal industry acceptance of
agile philosophy. A
recent survey conducted by Dr. Dobb’s Journal shows 41 percent of development
projects have now adopted agile
methodology, and agile techniques are being used on 65 percent of such projects.
Agile methods break tasks into small increments with minimal planning, and do not
directly involve long-term planning. Iterations are short time frames ("timeboxes") that
typically last from one to four weeks. Each iteration involves a team working through a
full software development cycle including planning, requirements analysis, design,
coding, unit testing, and acceptance testing when a working product is demonstrated to
stakeholders. This helps minimize overall risk, and lets the project adapt to changes
quickly. Stakeholders produce documentation as required. An iteration may not add
enough functionality to warrant a market release, but the goal is to have an available
release (with minimal bugs) at the end of each iteration. Multiple iterations may be
required to release a product or new features.
Agile methods emphasize face-to-face communication over written documents when the
team is all in the same location. When a team works in different locations, they maintain
daily contact through videoconferencing, voice, e-mail, etc.
Most agile implementations use a routine and formal daily face-to-face communication
among team members. This specifically includes the customer representative and any
interested stakeholders as observers. In a brief session, team members report to each
other what they did yesterday, what they intend to do today, and what their roadblocks
are. This standing face-to-face communication prevents problems being hidden.
History
The modern definition of agile software development evolved in the mid-1990s as part of
a reaction against "heavyweight" methods, perceived to be typified by a heavily
regulated, regimented, micro-managed use of the waterfall model of development. The
processes originating from this use of the waterfall model were seen as bureaucratic,
slow, demeaning, and inconsistent with the ways that software developers actually
perform effective work. A case can be made that agile and iterative development
methods mark a return to development practice from early in the history of software
development. Initially, agile methods were called "lightweight methods."
Principles
9.Simplicity
10.Self-organizing teams
Agile methodologies embrace iterations. Small teams work together with stakeholders to
define quick prototypes,
proof of concepts, or other visual means to describe the problem to be solved. The team
defines the
requirements for the iteration, develops the code, and defines and runs integrated test
scripts, and the users
verify the results. (See Figure) Verification occurs much earlier in the development
process than it would
with waterfall, allowing stakeholders to fine-tune requirements while they’re still relatively
easy to change.
Figure. A generic agile development process features an initial planning stage, rapid
repeats of the iteration stage, and some
form of consolidation before release
Key Agile Practices
Automated builds - on anything but the smallest projects having an automated build
process is essential. Manual builds are liable to be both fragile and specific to a single
machine - and time lost to making those builds work is time lost to development and
testing. Even if you have to take time out to create an automated build environment it's
time you'll get back later. It also makes it simpler to ensure that you have a standardised
build that everyone on a project can share. Key tools: Ant, Maven, Nant.
Continuous integration - If you've got an automated build in place the next thing is to go
for continuous integration. Waiting for weeks on end before you integrate code from
different team members is a recipe for disaster. Of course an automated build and
continuous integration environment pre-supposes version control (or Software
Configuration Management to give it a more formal and impressive name). The sooner
that you identify integration errors the sooner you can fix them. Key tools: CruiseControl,
CruiseControl.Net
Unit testing - How do you minimise those integration errors? Use unit-tests so that code
changes do not break existing functionality. Test-driven development is a key feature in
many Agile methodologies for a good reason. In a highly fluid environment with multiple
developers, shifting requirements and changing priorities it's essential to ensure that
what worked yesterday works today. Key tools: Junit (and other xUnit tools such as
NUnit, HTTPUnit etc), MockObjects.
Refactoring - Martin Fowler popularised the term refactoring in his book of the same
name. It essentially boils down to code changes which improve the structure and clarity
of the code without necessarily changing the functionality. Many Agile methodologies
specifically attack the idea of code ownership - in this view all code belongs to all
developers, who are free to improve the code when they feel it's necessary. Refactoring
support now exists in many IDEs, such as Eclipse, NetBeans, Visual Studio etc. Note
that refactoring without having unit tests in place is like doing a tightrope walking act
wearing a blindfold and without a safety net. Key tools: Eclipse, NetBeans, IntelliJ IDEA,
Visual Studio.NET.
Iterative development - Iterative development and short release cycles are both key agile
processes. Short development cycles mean that working software is delivered quickly to
the client so that feedback and changes to requirements are identified before too much
has been invested in driving down the wrong road. There are also positive effects in
terms of team working - the short cycle means that teams get used to working together
through the whole define - develop - deliver cycle. Some Agile methodologies, such as
Scrum, posit a particular length of development cycle, others are more flexible but still
caution against anything too long (>3 months).
Agile methods
1.Agile Modeling
4.DSDM
8.Getting Real
10.Scrum