A

SEMINAR REPORT ON
Google Balloon
Submitted in partial fulfillment of the requirement for the award of the degree
of
BACHELOR OF TECHNOLOGY
IN

COMPUTER SCIENCE & ENGINEERING

By
M Sai Krishna
(11K81A0584)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

St.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

ACKNOWLEDGEMENT
The 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)

ABSTRACT
Project Loon or Google Ballon is a research and development project being developed
by Google with the mission of providing Internet access to rural and remote areas. The project
uses high-altitude balloons placed in the stratosphere at an altitude of about 32 km (20 mi) to
create an aerial wireless network with up to 3G-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 the National 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 an Internet 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
during natural disasters to affected regions. Key people involved in the project include Rich
DeVaul, chief technical architect, who is also an expert on wearable technology; Mike Cassidy, a
project leader; and Cyrus Behroozi, a networking and telecommunication lead.

INDEX
1. Introduction

2. History
2.1.The Agile Software Development Manifesto
2.2.Evolutions

2
2
5

3. Overview

4. Philosophy
4.1.Adaptive v/s Predictive
4.2.Iterative v/s waterfall
4.3.Code v/s Documentation

7
7
8
9

5. Agile Methods

10

6. Agile Practices

11

7. Method tailoring

12

8. Comparison with other methods

8.1.RAD model
8.2.CMMI model

13
14

9. Agile Processes
9.1.Adaptive Software development
9.2.Extreme Programming

15
15
16

10. Implementing the Agile processes

18

11. Working of Agile SDLC model

11.1.
Concept Phase
11.2.
Warm Up phase
11.3.
Constructions Iterations
11.4.
Transition

19
19
19
19
20

11.5.
11.6.

Production
Retirement

20
21

12. Advantages and Disadvantages

22

13. Conclusion

23

14. References

24

LIST OF FIGURES
1.Test Ballon
5.1. Agile Methods
8.1.RAD Model
8.2.CMMI Model
9.1.Adaptive software development
9.2.Extreme Programming
11.2.Working of agile SDLC model
11.3.Constructive iterations

PAGE NUMBER
1
10
13
14
15
16
19
20

1. INTRODUCTION
Google is launching Internet-beaming antennas into the stratosphere aboard giant, jellyfishshaped 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. HISTORY
Incremental 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 Glib started publishing the concepts of evolutionary project management (EVO), which has
evolved into competitive engineering. During the mid- to late 1970s, Gielan lectured extensively
throughout the U.S. on this methodology, its practices, and its benefits.
So-called lightweight agile software development methods evolved in the mid-1990s in reaction
to the heavyweight waterfall-oriented methods, which critics called heavily regulated,
regimented, micromanaged and 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 the Snowbird resort in Utah to
discuss lightweight development methods. They published the Manifesto 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 interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Individuals and interactions

Using 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 software

In 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 ontime 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 change

Todays 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 Schwaber with 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 by Alistair Cockburn and Jim Highsmith wrote an
addendum of project management principles, the Declaration of Interdependence, to guide
software project management according to agile development methods.In 2009, a movement
spearheaded by Robert C Martin wrote an extension of software development principles,
the Software Craftsmanship Manifesto, to guide agile software development according
to professional conduct 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. OVERVIEW
There are many specific agile development methods. Most promote development, teamwork,
collaboration, and process adaptability throughout the life-cycle of the project.

Iterative, incremental and evolutionary

Most 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 communication

No 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 miditeration 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 cycle

A 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 focus

Specific 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. PHILOSOPHY
Compared 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. predictive

Development methods exist on a continuum from adaptive to predictive. Agile methods lie on
the adaptive side 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.
Predictive method, 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 a change control board to ensure they consider only the
most valuable changes.Risk analysis can be used to choose between adaptive (agile or value-

driven) and predictive (plan-driven) methods. Barry Boehm and Richard Turner suggest that
each side of the continuum has its own home ground, as follows:

Home grounds of different development methods

Agile methods

Plan-driven methods

Formal methods

Low criticality

High criticality

Extreme criticality

Senior developers

Junior developers (?)

Senior developers

Requirements change
often

Requirements do not
change often

Limited requirements, limited

features see Wirth's law

Small number of
developers

Large number of
developers

Requirements that can be modeled

Culture that responds to Culture that demands

change
order

Extreme quality

Fig 1: Home grounds of different development methods

4.2. Iterative vs. waterfall

One 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 the Waterfall model, there is
always a separate testing phase near the completion of an implementation phase. However, in
agile development and especially extreme 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. Scrum has 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 the lean startup concept.

4.3. Code vs. documentation

In a letter to IEEE Computer, 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 Ambler states 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 METHODS
Well-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 ban

The 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 Methods

6. AGILE PRACTICES
Agile 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 tracking

The Agile Alliance has provided a comprehensive online collection with a map guide to the
applying agile practices.

7. METHOD TAILORING
In 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 the DSDM method is
being used for this purpose and has been successfully tailored in a CMM context. Situationappropriateness 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 by Beck, has been
reported on several occasions. Mehdi Mirakhorli proposes a tailoring practice that provides a
sufficient road-map and guidelines for adapting all the practices. RDP Practice is 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 Model

Agile methods have much in common with the Rapid Application Development techniques from
the 1980/90s as espoused by James Martin and others. In addition to technology-focused
methods, customer-and-design-centered methods, such as Visualization-Driven Rapid
Prototyping developed by Brian Willison, work to engage customers and end users to facilitate
agile software development.

8.2. CMMI MODEL

In 2008 the Software Engineering Institute (SEI) published the technical report "CMMI or Agile:
Why Not Embrace Both" to make clear that the Capability Maturity Model Integration and Agile
can co-exist. Modern CMMI-compatible development processes are also iterative. The CMMI
Version 1.3 includes tips for implementing agile development and CMMI process improvement
together.

Fig 4: CMMI Model

9. AGILE PROCESSES
There are many agile processes; in this we will discuss adaptive software development and
Extreme programming.
9.1.

Adaptive Software Development

ASD (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 cycle

ASD 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 project

The 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 practices

Spike: 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 releases
XPs 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.
Refactoring
Refactoring 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 Practices
The 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 PROCESSES

One 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 feasibility
11.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 to initiate the project
by:

Garnering initial support and funding for the project.

Actively working with stakeholders to initially model the scope of the system.
Starting to build the team.
Modeling an initial architecture for the system.
Setting up the environment.
Estimating the project.

Fig 7: Working of Agile SDLC Model

11.3. Construction Iterations: 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 iterations

11.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.Production
The goal of the Production Phase is 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.Retirement
The goal of the Retirement Phase is 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. CONCLUSION

Agile 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 Model 5 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/ADifferentApp
roach.pdf
www.agilemodeling.com
www.wikipedia.com