A SEMINAR REPORT ONGoogle BalloonSubmitted in partial
fulfillment of the requirement for the award of the degree of
BACHELOR OF TECHNOLOGYINCOMPUTER SCIENCE & ENGINEERINGByM Sai
Krishna(11K81A0584)
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERINGSt.MARTINs
ENGINEERING COLLEGE(Affiliated to JNTU, Hyderabad)DHULAPALLY (V),
QUTBULLAPUR (M), SECUNDERABAD
2014-2015
CERTIFICATE
This is to certify that the Seminar report titled SDLC BY AGILE
that is being submitted by Mr. M Sai Krishna(11K81A0584) , in
partial fulfillment of the requirements for the award of the degree
ofBachelor of Technology in Computer Science & Engineering is a
record of bonafide work carried out by him.The result of
investigation enclosed in this report have been verified and found
satisfactory.
HOD
ACKNOWLEDGEMENTThe satisfaction and euphoria that accompanies
the successful completion of any task would be incomplete without
the mention of the people who made it possible and whose
encouragement and guidance have crowned my efforts with success.I
extend my deep sense of gratitude to Principal, Dr.C. VenkataRamana
Reddy, St.Martins Engineering College, Dhulapally for permitting me
to undertake this Seminar.I am indebted to Mr. A.PRAKASH HOD,
Computer Science & engineering, St.Martins Engineering College,
Dhulapally, for his support and guidance throughout our
Seminar.Finally, I express thanks to one and all who have helped us
in successfully completing this Seminar. Furthermore I would like
to thank our family and friends for their moral support and
encouragement.
M Sai Krishna (11k81a0584)
ABSTRACTProject Loon or Google Ballonis aresearch and
developmentproject being developed byGooglewith the mission of
providingInternet accesstoruraland remote areas. The project
useshigh-altitude balloonsplaced in thestratosphereat an altitude
of about 32km (20mi) to create an aerial wireless networkwith up
to3G-like speeds.It was named Project Loon, since Google itself
found the very idea of providing internet access to the remaining 5
billion population unprecedented and "crazy." The balloons are
maneuvered by adjusting their altitude to float to a wind layer
after identifying the wind layer with the desired speed and
direction using wind data from theNational Oceanic and Atmospheric
Administration(NOAA). Users of the service connect to the balloon
network using a special Internet antenna attached to their
building. The signal travels through the balloon network from
balloon to balloon, then to a ground-based station connected to
anInternet service provider(ISP), then onto the global Internet.
The system aims to bring Internet access to remote and rural areas
poorly served by existing provisions, and to improve communication
duringnatural disastersto affected regions. Key people involved in
the project include Rich DeVaul, chief technical architect, who is
also an expert onwearable technology;Mike Cassidy, a project
leader; and Cyrus Behroozi, a networking and telecommunication
lead.
INDEX
1.Introduction1
2.History2
2.1.The Agile Software Development Manifesto2
2.2.Evolutions5
3.Overview6
4.Philosophy7
4.1.Adaptive v/s Predictive7
4.2.Iterative v/s waterfall8
4.3.Code v/s Documentation9
5.Agile Methods10
6.Agile Practices11
7.Method tailoring12
8.Comparison with other methods
8.1.RAD model13
8.2.CMMI model14
9.Agile Processes15
9.1.Adaptive Software development15
9.2.Extreme Programming16
10.Implementing the Agile processes18
11.Working of Agile SDLC model19
11.1.Concept Phase19
11.2.Warm Up phase19
11.3.Constructions Iterations19
11.4.Transition20
11.5.Production20
11.6.Retirement21
12.Advantages and Disadvantages22
13.Conclusion23
14.References24
LIST OF FIGURESPAGE NUMBER
1.Test Ballon1
5.1. Agile Methods10
8.1.RAD Model13
8.2.CMMI Model14
9.1.Adaptive software development15
9.2.Extreme Programming16
11.2.Working of agile SDLC model19
11.3.Constructive iterations20
1. INTRODUCTIONGoogle is launching Internet-beaming antennas
into the stratosphere aboard giant, jellyfish-shaped balloons with
the lofty goal of getting the entire planet online. Eighteen months
in the works, the top-secret project was announced Saturday in New
Zealand, where up to 50 volunteer households are already beginning
to receive the Internet briefly on their home computers via
translucent helium balloons that sail by on the wind 12 miles above
Earth. While the project is still in the very early testing stages,
Google hopes eventually to launch thousands of the thin,
polyethylene-film inflatables and bring the Internet to some of the
more remote parts of the globe, narrowing the digital divide
between the 2.2 billion people who are online and the 4.8 billion
who aren't.
Fig 1: Google Test Balloon
2. HISTORYIncremental software development methods trace back to
1957.In 1974, E. A. Edmonds wrote a paper that introduced an
adaptive software development process.Concurrently and
independently, the same methods were developed and deployed by the
New York Telephone Company's Systems Development Center under the
direction of Dan Gielan. In the early 1970s, Tom Glibstarted
publishing the concepts of evolutionary project management (EVO),
which has evolved intocompetitive engineering.During the mid- to
late 1970s, Gielan lectured extensively throughout the U.S. on this
methodology, its practices, and its
benefits.So-calledlightweightagile software development methods
evolved in the mid-1990s in reaction to
theheavyweightwaterfall-oriented methods, which critics called
heavily regulated, regimented,micromanagedand over-incremental.
Proponents of lightweight agile methods contend that they are
returning to development practices that were present early in the
history of software. 2.1. The Agile Software Development
Manifesto:In February 2001, 17 software developers (see below) met
at theSnowbirdresort inUtahto discuss lightweight development
methods. They published theManifesto for Agile Software
Development. We are uncovering better ways of developing software
by doing it and helping others do it? Through this work we have
come to value:Individuals and interactionsover Processes and
toolsWorking softwareover Comprehensive documentationCustomer
collaborationover Contract negotiationResponding to changeover
following a planThat is, while there is value in the items on the
right, we value the items on the left more. Individuals and
interactionsUsing adaptive process requires a very effective team
of developers. The team has to work well together to be more
effective. Face to face meetings have special importance in agile
processes. It is believed that people respond quicker and transfer
ideas more rapidly when talking face to face than they can when
reading or writing documentation. Extreme programming introduces
the concept of pair programming where two developers develop a
module together to provide much better and quicker output than the
same job done individually. The concept of synergy (i.e. the
interaction of two or more agents or forces so that the combined
effect is greater than the sum of their individual effects) takes
hold because a few designers, sharing a common space, working
together, can produce more code quicker than can the same
individuals working alone.In traditional methodologies treat people
as resources that are like replaceable part. As stated earlier they
say that individuals are not as important as their roles. They fail
to understand that each individual is dynamic and unpredictable.
When we are programming a computer, we are controlling a
predictable device. But when handling human beings this approach
fails. Treating individuals are replaceable resources reduces their
morale and they look for much better working environments.The
traditional approach is more suited to a factory where the workers
are not the most intelligent people or the best people to design
and be creative. So here the approach of separating the people who
plan the system and the people who construct is suited. But in
software industry the developers are intelligent, capable and
competent people so treating them in the same way does not help.
According to the Taylorist notion of a separate planning department
that decides how things work works only if planners understand how
to do the job than those doing it, if you have bright, motivated
people doing the job then this does not hold true. Another
important aspect of individuals and interactions is that the team
should be empowered to take all technical decisions. At times fast
decision making is needed, if we have to wait every time for the
management to approve it then it slows down the whole process of
development. So power of taking technical decisions must rest in
the hands of technical people. Reading we are advised that team
members and management must have an equal place in the project.
This does not mean that technical people will take the role of
management. Management will still retain its role of an enabler but
management should recognize the fact that development team can also
take technical decisions. Working softwareIn agile processes source
code is the single most important document while in the traditional
approach (big design upfront) the requirements document is the
single most important document. In big design upfront (BDUF) it is
possible to gather all the requirements upfront (beforehand), prior
to writing any code. This is a classical approach which works well
for mechanical industry where we gather all requirements, get the
customer to agree on them and then apply procedures to restrict
change. Gathering of requirements beforehand gives project a level
of predictability. This predictability has a value and is very
critical when the systems in consideration are Life critical
systems where big requirements change could be a disaster. For all
other systems this predictability adds a layer of documentation.In
this radically changing market it is not possible to gather
complete set of customer requirements that are stable and
unchanging. Customer is not always sure of what he wants. He gets a
better understanding of it only when he sees a working model or a
prototype of the system. This helps him to visualize the final
system better. Essentially In todays economy the fundamental
business forces are changing the value of software features too
rapidly. What might be a good set of requirements now, is not a
good set in six months.This means that as time passes the customer
might want to add some feature which at that time looks essential
to have.According to Agile processes link code and requirements
tightly together. Users of agile processes view requirements as
fluid and changing. XP (Extreme programming) introduces the idea of
simplicity. It means not to add unnecessary artifacts or activities
to a project. Eliminate everything not completely justified i.e.
never produce documents predicting the future as they have a
possibility of becoming outdated. According to the larger the
amount of documentation becomes, more effort is needed to find the
required information, and more effort to keep it up to date. For
example as the system evolves or some changes are made to it, there
arises a need to update the documentation that was made earlier.
The first document the maintainer will go through to fix a bug is
the source code rather than a pile of documents. So too much time
should not be wasted on documentation, rather source code should be
documented as good as possible. Making the code the actual design
permits developers to move into the coding phase more rapidly.
Customer Collaboration Whenever software development is done by a
separate firm the customers prefer fix price contracts in which
they specify their requirements, ask for a quotation of price, and
finally accept a price and leave the development to the firm. Agile
processes require customer to be on site. They need customer to
play an active part in the design process. Customer effectively is
on the development team and works closely with developers to
approve decisions and guiding the project through his perspective.
This role is different from the traditional role of the customer
and this change affects the business side of the project also.
Traditionally in a fixed price contract the development team
generates a set of requirements leading to a predictable outcome,
applying predictive processes to achieve goal. Agile methodologies
say that requirements can never be stable so the fixed price
development approach would not work in this case.This does not mean
we cannot budget what a project made using agile approach would
cost. Agile approach is to fix time, price, and to allow the scope
to vary in a controlled manner. As the customer has finer control
on the project making changes based on feedback. At every iteration
customer and development team can check the progress and decide
with the development team whether to alter the direction of
project. A different business model is required for such a setup.
Hence it is essential that customer and supplier arrive at a
business plan supporting customer collaboration over contract
negotiations. According to a predictive process is often measured
by how well it met its plan. A project on-time and on-cost is
considered to be a success. For agile software development the
question is business value-did the customer get software thats more
valuable to them than the cost put in. Good agile software will
build something different and better than the original plan
foresaw. Responding to changeTodays market is volatile and ever
changing making it impossible for a predictive process to work on
stable set of requirements. Responding to change than following the
laid out plan is what makes agile software development successful
in todays market. Software development is more of a design activity
so its hard to plan and price. For software development to be
predictable there is need for plenty of time, a large team, and
stable requirements which is not possible in small projects. The
problem with predictive processes is their difficult to map new
requirement to additional cost, as they cannot predict how much it
would cost to implement the new requirement.Software is intangible
in nature, it is difficult to see what value a software feature has
until we use it for real. Only after seeing the early prototype or
version can one understand what features are important what are
not. So this means that requirements should be changeable. For
example a new technology or standard comes up then the customer
would demand compliance with it which is the need of the hour for
the customer to use an up to date product. So our approach should
not be towards stopping change but to determine how to better
handle inevitable changes in project. External environmental
changes cause critical variations. Because we cannot eliminate
these changes, driving down the cost of responding to them is the
only viable strategy. The idea to respond to change is using an
iterative approach while developing where we produce working
versions of final software frequently that handle subset of
requirements. These working systems should be integrated in the end
to produce the final system. This is better than having documents
which can hide flaws. Untested code can also hide certain flaws.
But when we have people working on the system we can unearth flaws
faster.Co-located teams working together producing code instead of
high maintenance documentation can help increase productivity.
These teams with onsite customer will produce code that better
reflects the customers requirements.2.2. Evolutions:Later,Ken
Schwaberwith others founded the Scrum Alliance and created the
Certified Scrum Master programs and its derivatives. Schwaber left
the Scrum Alliance in the fall of 2009, and founded Scrum.org.In
2005, a group headed byAlistair CockburnandJim Highsmithwrote an
addendum ofproject managementprinciples, theDeclaration of
Interdependence,to guide software project management according to
agile development methods.In 2009, a movement spearheaded byRobert
C Martinwrote an extension ofsoftware developmentprinciples,
theSoftware Craftsmanship Manifesto, to guide agile software
development according toprofessionalconduct and mastery.In 2011 the
original Agile Alliance created the Guide to Agile Practices, an
evolving open-source compendium of the working definitions of agile
development terms, practices, and elements, along with
interpretations and experience guidelines from the world-wide agile
development community of practitioners.
3. OVERVIEWThere are many specific agile development methods.
Most promote development, teamwork, collaboration, and process
adaptability throughout the life-cycle of the project. Iterative,
incremental and evolutionaryMost agile development methods break
tasks into small increments with minimal planning and do not
directly involve long-term planning. Iterations are short time
frames (time boxes) that typically last from one to four weeks.
Each iteration involves a cross-functional team working in all
functions: planning, requirements, design, coding, unit testing,
and acceptance testing. At the end of the iteration a working
product is demonstrated to stakeholders. This minimizes overall
risk and allows the project to adapt to changes quickly. An
iteration might 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 might be
required to release a product or new features. Efficient and
face-to-face communicationNo matter what development disciplines
are required, each agile team contains a customer representative,
e.g., product owner in scrum. This person is appointed by
stakeholders to act on their behalf and makes a personal commitment
to being available for developers to answer mid-iteration
questions. At the end of every iteration, stakeholders and the
customer representative review progress and re-evaluate priorities
with a view to optimizing the return on investment (ROI) and
ensuring alignment with customer needs and company goals. In agile
software development, an information radiator is a (normally large)
physical display located prominently in an office, where passers-by
can see it. It presents an up-to-date summary of the status of a
software project or other product. The name was coined by Alistair
Cockburn, and described in his 2002 book Agile Software
Development. An indicator may be used to inform a team about the
current status of their project. Very short feedback loop and
adaptation cycleA common characteristic of agile development are
daily status meetings or "stand-ups", e.g. daily scrum (meeting).
In a brief session, team members report to each other what they did
the previous day, what they intend to do today, and what their
roadblocks are. Quality focusSpecific tools and techniques, such as
continuous integration, automated unit testing, pair programming,
test-driven development, design patterns, domain-driven design,
refactoring and other techniques are often used to improve quality
and enhance project agility.
4. PHILOSOPHYCompared to traditional software engineering, agile
development mainly targets complex systems and projects with
dynamic, deterministic and non-linear characteristics, where
accurate estimates, stable plans, and predictions are often hard to
get in early stages and big up-front designs and arrangements would
probably cause a lot of waste, i.e., are not economically sound.
These basic arguments and precious industry experiences, learned
from years of successes and failures, have helped shape agile
development's favor of adaptive, iterative and evolutionary
development.4.1. Adaptive vs. predictiveDevelopment methods exist
on a continuum fromadaptivetopredictive.Agile methods lie on
theadaptiveside of this continuum. One key of adaptive development
methods is a "Rolling Wave" approach to schedule planning, which
identifies milestones but leaves flexibility in the path to reach
them, and also allows for the milestones themselves to
change.Adaptive methods focus on adapting quickly to changing
realities. When the needs of a project change, an adaptive team
changes as well. An adaptive team has difficulty describing exactly
what will happen in the future. The further away a date is, the
vaguer an adaptive method is about what will happen on that date.
An adaptive team cannot report exactly what tasks they will do next
week, but only which features they plan for next month. When asked
about a release six months from now, an adaptive team might be able
to report only the mission statement for the release, or a
statement of expected value vs. cost.Predictivemethod, in contrast,
focuses on analyzing and planning the future in detail and caters
for known risks. In the extremes, a predictive team can report
exactly what features and tasks are planned for the entire length
of the development process. Predictive methods rely on effective
early phase analysis and if this goes very wrong, the project may
have difficulty changing direction. Predictive teams often
institute achange control boardto ensure they consider only the
most valuable changes.Risk analysiscan be used to choose between
adaptive (agileorvalue-driven) and predictive (plan-driven)
methods.Barry BoehmandRichard Turnersuggest that each side of the
continuum has its ownhome ground, as follows:
Home grounds of different development methods
Agile methodsPlan-driven methodsFormal methods
Low criticalityHigh criticalityExtreme criticality
Senior developersJunior developers (?)Senior developers
Requirements change oftenRequirements do not change oftenLimited
requirements, limited features seeWirth's law
Small number of developersLarge number of developersRequirements
that can be modeled
Culture that responds to changeCulture that demands orderExtreme
quality
Fig 1: Home grounds of different development methods4.2.
Iterative vs. waterfallOne of the differences between agile and
waterfall is that testing of the software is conducted at different
stages during the software development life-cycle. In theWaterfall
model, there is always a separatetesting phasenear the completion
of animplementation phase. However, in agile development and
especiallyextreme programming, testing is usually done concurrently
with coding, or at least, testing jobs start in the early days of
iteration. Because the testing phase is done in every small
iteration which develops a small piece of the software users can
frequently use those new pieces of software and validate the value.
After the users know the real value of the updated piece of
software, they can make better decisions about the software's
future. Having a value retrospective and software re-planning
session in each iteration. Scrumhas a maximum of one month for
iteration length helps the team continuously adapt its plans so as
to maximize the value it delivers.This iterative practice also
introduces a "product mindset" rather than Waterfall's 'project
mindset'. Software can be seen as a living organism, which actively
changes due to environmental change. As long as the software is
being used, especially when it has competitor(s), iterations in
agile software development drive the change.Because of the short
iteration style of agile software development, it also has strong
connections with thelean startupconcept.4.3. Code vs.
documentationIn a letter to IEEEComputer, Steven Rakitin expressed
cynicism about agile development, calling an article supporting
agile software development "yet another attempt to undermine the
discipline of software engineering" and translating "Working
software over comprehensive documentation" as "We want to spend all
our time coding. Remember, real programmers don't write
documentation." This is disputed by proponents of agile software
development, who state that developers should write documentation
if that's the best way to achieve the relevant goals, but that
there are often better ways to achieve those goals than writing
static documentation.Scott Amblerstates that documentation should
be "Just Barely Good Enough" (JBGE), that too much or comprehensive
documentation would usually cause waste, and developers rarely
trust detailed documentation because it's usually out of sync with
code, while too little documentation may also cause problems for
maintenance, communication, learning and knowledge sharing.
5. AGILE METHODSWell-known agile software development methods
and/or process frameworks include: Adaptive software development
(ASD) Agile modeling Agile Unified Process (AUP) Crystal Clear
Methods (Crystal Clear) Disciplined agile delivery Dynamic systems
development method (DSDM) Extreme programming (XP) Feature-driven
development (FDD) Lean software development Kanban (development)
Scrum Scrum banThe agile methods are focused on different aspects
of the software development life cycle. Some focus on the practices
(e.g. XP, pragmatic programming, and agile modeling), while others
focus on managing the software projects (e.g. Scrum). Yet, there
are approaches providing full coverage over the development life
cycle (e.g. DSDM, IBM RUP), while most of them are suitable from
the requirements specification phase on (FDD, for example). Thus,
there is a clear difference between the various agile methods in
this regard.
Fig 2: Agile Methods6. AGILE PRACTICESAgile development is
supported by a bundle of concrete practices suggested by the agile
methods, covering areas like requirements, design, modeling,
coding, testing, project management, process, quality, etc. Some
notable agile practices include: Acceptance test-driven
development(ATDD) Agile modeling Backlogs(Product and Sprint)
Behavior-driven development(BDD) Cross-functional team Continuous
integration(CI) Domain-driven design(DDD) Information radiators
(Scrum board, task board,burndown chart) Iterative and incremental
development(IID) Pair programming Planning poker Refactoring Scrum
meetings(Sprint planning, daily scrum, sprint review and
retrospective) Test-driven development(TDD) Agile testing Time
boxing Use case User story Story-driven modeling Retrospective
Velocity trackingThe Agile Alliance has provided a comprehensive
online collection with a map guide to the applying agile
practices.
7. METHOD TAILORINGIn the literature, different terms refer to
the notion of method adaptation, including 'method tailoring',
'method fragment adaptation' and 'situational method engineering'.
Method tailoring is defined as:A process or capability in which
human agents determine a system development approach for a specific
project situation through responsive changes in, and dynamic
interplays between contexts, intentions, and method
fragments.Potentially, almost all agile methods are suitable for
method tailoring. Even theDSDMmethod is being used for this purpose
and has been successfully tailored in aCMMcontext.
Situation-appropriateness can be considered as a distinguishing
characteristic between agile methods and traditional software
development methods, with the latter being relatively much more
rigid and prescriptive. The practical implication is that agile
methods allow project teams to adapt working practices according to
the needs of individual projects. Practices are concrete activities
and products that are part of a method framework. At a more extreme
level, the philosophy behind the method, consisting of a number of
principles, could be adapted (Aydin, 2004)extreme programming(XP)
makes the need for method adaptation explicit. One of the
fundamental ideas of XP is that no one process fits every project,
but rather that practices should be tailored to the needs of
individual projects. Partial adoption of XP practices, as suggested
byBeck, has been reported on several occasions.Mehdi
Mirakhorliproposes a tailoring practice that provides a sufficient
road-map and guidelines for adapting all the practices.RDP
Practiceis designed for customizing XP. This practice, first
proposed as a long research paper in the APSO workshop at the ICSE
2008 conference, is currently the only proposed and applicable
method for customizing XP. Although it is specifically a solution
for XP, this practice has the capability of extending to other
methodologies. At first glance, this practice seems to be in the
category of static method adaptation but experiences with RDP
Practice says that it can be treated like dynamic method
adaptation. The distinction between static method adaptation and
dynamic method adaptation is subtle.
8. COMPARISON WITH OTHER METHODS
8.1. RAD MODEL
Fig 3: RAD ModelAgile methods have much in common with theRapid
Application Developmenttechniques from the 1980/90s as espoused
byJames Martinand others. In addition to technology-focused
methods, customer-and-design-centered methods, such as
Visualization-Driven Rapid Prototyping developed byBrian Willison,
work to engage customers and end users to facilitate agile software
development.8.2. CMMI MODELIn 2008 theSoftware Engineering
Institute(SEI) published the technical report "CMMI or Agile: Why
Not Embrace Both"to make clear that theCapability Maturity Model
Integrationand Agile can co-exist. Modern CMMI-compatible
development processes are also iterative. TheCMMI Version
1.3includes tips for implementing agile development and CMMI
process improvement together.
Fig 4: CMMI Model
9. AGILE PROCESSESThere are many agile processes; in this we
will discuss adaptive software development and Extreme
programming.9.1. Adaptive Software DevelopmentASD (adaptive
software development) was developed by Jim Highsmith. It does not
discuss milestones, methods, and deliverables. ASD gives importance
on applying ideas originating in the world of complex adaptive
systems. ASD provides fundamental base to develop adaptive systems
from which arise agile and adaptive processes. Jim Highsmith states
that the premise of ASD is that outcomes are naturally
unpredictable, so we are wasting effort by planning for it.
Planning in the world of changing requirements will never be
successful. ASD replaces the evolutionary life cycle by adaptive
life cycle.
Fig 5: Evolutionary Life cycle & Adaptive Life cycleASD
recognizes the fact that there is no point in experimenting
endlessly in search of success. So the first phase of ASD is named
speculate rather than planning which is not suitable for
unpredictable world. Speculation means developing the good idea of
where the project is heading, and put mechanisms in place to adapt
to changing customer needs, changing technology and a changing
market. Collaboration replaces build because of ASDs recognition
that people are essential while making a successful product. The
customer collaborates in all activities of the software creation to
get what he needs from the system. Collaboration is the activity of
balancing: managing a project, such as configuration control and
change management, with creativity the act of trusting people to
find creative answers in an unpredictable environment. Learning
replaces revise because revise is backward looking. In the
evolutionary life cycle revise means that while change is necessary
it should be based on original plan i.e. change cannot question
original plan, it has to be in conformance with original plan.
Learning is the act of gaining knowledge through experience.
Learning is often discouraged in predictable environments; we may
lay out things in advance and then follow then in design. In
learning we can question all previous assumptions, using the
results to decide in which direction to move. ASD is not a
methodology but rather is an approach that must be adopted by an
organization when applying agile processes.In an adaptive
environment, learning challenges all stakeholders-developers and
their customers- to examine their assumptions and to use the
results of each development cycle to adapt to the next.As learning
is a continuous process designs and plans must change as
development proceeds.9.2. Extreme Programming
Fig 6: Extreme programming projectThe XP approach emphasizes
customer involvement and testing:Early on in the project, the team
focuses on exploration and release planning; customer sits and
writes stories, the programmers estimates them, the customer
chooses the order in which the stories should be implemented.
Later, there is more focus on exploration. The team works
iteratively; customer writes tests for the stories to be successful
and answers questions while programmers code. According to the four
basic building blocks (values) are Communication- Without
communications project schedules slip, quality suffers, and the
customers wants and needs are misinterpreted or overlooked.
Feedback- the need to check our results is important. Without
feedback project might fail. Feedback tells how the project is
doing while providing directions for future iterations. Feedback
tells us where our project stands and what mistakes were made so
that we dont make them again. Simplicity- Do not add unnecessary
artifacts or activities to a project. Eliminate everything not
completely justified. Courage-Putting faith in the people over the
process requires courage. It is important to realize, however, that
if processes do become more important than the people do, a project
is headed toward failure.The architecture of XP has following
components Spike Metaphor First Iteration Small releases
Refactoring Team practicesSpike: According to during the release
planning game, the team has the opportunity to do spikes: quick
throw away (and thrown away) exploration into the nature of the
solution.We decide the system approach based on the stories and
spikes. For example is the story is about managing orders on the
Internet then the solution we might think of contains an
application server, a web server, a database and a pair of
firewalls. The spikes one does in the early phase guides us to the
Deployment phase. Because spikes begin early on one can be prepared
with the installation of hardware and software needed, so that
project doesnt get halted because of inadequate resources.Metaphor:
An effective Metaphor helps guide your solution. In XP metaphor
acts as a conceptual framework and provides a descriptive system of
names. It identifies the key objects and their interactions. The
metaphor may change as ones understand the system better.First
iteration: The first iteration is the key in making the system come
together. From Extreme Programming explained (Kent Beck)The first
iteration puts the system in place. Pick stories for the first
iteration that will force one to create the whole system even if it
is in skeletal form. Small releasesXPs small releases help jell the
architecture quickly. As we are installing a few months work, we
are forced to get the essential structure together. We deliver the
stories most important to the user first. So we get immediate
feedback from the user which will help us correct the weak areas in
the architecture.RefactoringRefactoring is improving a computer
program by re-organizing its internal structure without altering
its external behavior. It helps us manage design without changing
the systems behavior; therefore, we dont risk the functionality of
our program while we improve its architecture.Team PracticesThe
software architecture document is useful only if it tells how
developers implement the things the system is supposed to do. XP
forges the Software Architecture Document that RUP (Rational
unified process) values, but still has architecture. Pair
programming helps ensure that the people know and use the approach
the team is using.
10. IMPLEMENTING AGILE PROCESSESOne of the most difficult tasks
involved with using agile processes is successfully introducing
them into an organization (i.e. overcoming resistance to existing
organizational structures). Part of [the BDUF] culture is the
creation of fiefdoms within the program organization. Adopting
[agile processes] will radically change the functions of the
organization within the program and consequently change the staff
and funding profiles of the organizations. The traditional roles
played by management, Quality and Assurance, test, financials, and
Software Engineers (SWE) will all change creating resistance to the
introduction of agile processes.Reading much knowledge is gained
concerning the problems experienced by organizations wanting to
transition to agile processes. Software Engineers (SWE) are either
overzealous or highly skeptical. Overzealous engineers may
misinterpret the meaning of agile, taking it to mean moving quickly
leading toward minimal discipline and turning the project into a
hacking free for all. It is important to understand that users of
agile processes are making decisions with forethought and reason.
On the other hand, there are SWE resisting agile processes because
they are strong proponents of design artifacts created using BDUF
processes and are most familiar working to a structured plan having
a defined time schedule. They do not believe using agile processes
produces quality products.Quality and Assurance (Q and A) and the
testing staff often resist agile processes because in the BDUF
environment they do not get much attention from management. In the
agile process environment, however, this changes because Q and A
and testing is a high profile activity occurring after each
iteration. Viewing this attention as micromanagement may cause them
to resist any change. Management, too, is often skeptical of agile
processes. They are uncomfortable with not having Gantt charts and
other documents used to manage projects. It is common for
management to judge the progress of a project by looking to see if
a particular document exists or not. Recall, these are artifacts
associated with BDUF processes and do not exist in similar form for
agile processes. Another area that causes distress for management
is not having a final commitment date of delivery, a bottom line
cost, and all features documented.Other areas causing resistance to
agile processes revolve around the lack of technical documentation
associated with agile process methods. Agile process critics point
out that the emphasis on code can lead to corporate memory loss
because there is little emphasis on producing good documentation
and models to support software creations and evolution of large,
complex systems. Noting these perceived shortcomings offered up by
organizations whose experience lays in BDUF processes there are,
however, organizations that do transition to agile processes
successfully employing them on software projects.
11. WORKING OF AGILE SDLC MODEL
11.1. The Concept Phase: Pre-Project Planning:The Concept Phase,
sometimes called Iteration -1, is the pre-project aspects of
portfolio management. During this phase you will: Define the
business opportunity. Identify a viable for the project. Assess the
feasibility11.2. Inception/Warm Up: Project Initiation: The first
week or so of an agile project is often referred to as "Iteration
0" (or "Cycle 0") or in The Eclipse Way the "Warm Up" iteration.
Your goal during this period is toinitiatethe project by: Garnering
initial support and funding for the project. Actively working with
stakeholders toinitially modelthe scope of the system. Starting to
build the team. Modeling aninitial architecturefor the system.
Setting up the environment. Estimating the project.
Fig 7: Working of Agile SDLC Model11.3. ConstructionIterations:
During construction iterations agilists incrementally deliver
high-quality working software which meets the changing needs of our
stakeholders. Collaborating closely with both our stakeholders and
with other developers. Implementing functionality in priority
order. Analyzing and designing. Ensuring quality. Regularly
delivering working solutions. Testing, testing, and yes,
testing.
Fig 8: Constructive iterations11.4. Transition: The "End
Game":During Transition, also known as the "end game" or
deployment, we release the solution into production. Not that for
complex systems the end game may prove to be several iterations,
although if you've done system and user testing during construction
iterations this likely won't be the case. There are several
important aspects to this effort: Final testing of the system.
Rework. Finalization of any system and user documentation.
Training. Deploy the system.11.5. ProductionThe goal of
theProduction Phaseis to keep systems useful and productive after
they have been deployed to the user community. This process will
differ from organization to organization and perhaps even from
system to system, but the fundamental goal remains the same: keep
the system running and help users to use it. Shrink-wrapped
software, for example, will not require operational support but
will typically require a help desk to assist users. Organizations
that implement systems for internal use will usually require an
operational staff to run and monitor systems.11.6. RetirementThe
goal of theRetirement Phaseis the removal of a system release from
production, and occasionally even the complete system itself, an
activity also known as system decommissioning or system sun
setting. Retirement of systems is a serious issue faced by many
organizations today as legacy systems are removed and replaced by
new systems. You must strive to complete this effort with minimal
impact to business operations. If you have tried this in the past,
you know how complex it can be to execute successfully. System
releases are removed from production for several reasons,
including: The system is being complete replaced. The release is no
longer to be supported. The system no longer needed to support the
current business model. The system is redundant. The system has
become obsolete.
12. ADVANTAGES AND DISADVANTAGES Advantages of Agile model:1.
Customer satisfaction by rapid, continuous delivery of useful
software.2. People and interactions are emphasized rather than
process and tools. Customers, developers and testers constantly
interact with each other.3. Working software is delivered
frequently (weeks rather than months).4. Face-to-face conversation
is the best form of communication.5. Close, daily cooperation
between business people and developers.6. Continuous attention to
technical excellence and good design.7. Regular adaptation to
changing circumstances.8. Even late changes in requirements are
welcomed
Disadvantages of Agile model:1. 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.2. There is lack of emphasis on necessary designing and
documentation.3. The project can easily get taken off track if the
customer representative is not clear what final outcome that they
want.4. 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.
13. CONCLUSIONAgile processes can improve both quality and
time-to-market but are they processes that all organizations can
effectively use? The answer to this question is probably no. There
is a decided preference among managers to choose BDUF processes
over agile ones. Large organizations have financial and
professional investments made in BDUF processes, business models
requiring fixed price contracts are mandated, and the strong
history of software engineering concepts and the industry wide
adoption of the Capability Maturity Model5 as the standard defining
software development practices make the adoption of agile processes
into some organizations doubtful [17]. Moreover, there may always
be a place for BDUF processes. Projects addressing life critical
systems must have a rigor often associated with BDUF processes.
With this rigor, however, comes a cost in both time and money to
manage the large overhead associated with the processes. Typically,
this is a cost most organizations can no longer sustain and remain
competitive. Possibly, with a lot of work, the answer to the
question may also be yes. Organizations may have to learn to use
agile processes. It may be necessary for their survival.The four of
the many different agile processes currently in use (Strictly
speaking, however, ASD is not a process like the others). Although
different in some aspects there are common threads flowing in all
of them. They speak of developing code sooner, they talk about
multiple iterations, the need for customer involvement, the
importance of people over process and, maybe the most important,
the need to adapt to change. It is imperative for organizations to
wake up to the fallacy of gathering all requirements upfront and
creating a rigid plan for implementing these requirements. Just
doing this will be a big step towards changing current development
practices.Agile processes are not a panacea and they are not easy
to implement. An important step to adopting an agile process
methodology is to read and embrace the philosophy discussed by Jim
Highsmith and his ASD (Advanced Software Development). Selecting a
process is, of course, dependent on the organization. From one
extreme, adopting XP, it is expected that the process will be
followed to the letter, (although the case study didnt and still
experienced a successful project). To the other extreme, using RUP
where the framework is so loosely defined many different processes
seem possible. A word of caution here: since RUP is so versatile it
is possible that what is ultimately adopted will be called agile
but, in fact, will be a BDUF process that is agile in name only.
Furthermore, all players, including developers, project managers,
test and Q and A departments, customers, financials, and upper
management must be in total agreement with using agile processes.
Without this commitment, failure is a strong possibility. While not
a panacea, agile processes can help an organization to better
compete in a volatile and rapidly changing market by helping to
deliver high quality software at a competitive price and in a
timely manner to a market moving at blinding speed.
REFERENCES Manifesto for Agile software development;
http://agilealliance.com Agile Software Development Processes- A
Different approach to Software
design;Keith,Everettehttp://www.agilealliance.com/articles/articles/ADifferentApproach.pdf
www.agilemodeling.com www.wikipedia.com