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