Software development approaches

Every software development methodology has more or less its own approach to software development. There is a set of more general approaches, which are developed into several specific methodologies. These approaches are: -

Waterfall: linear framework type. Prototyping: iterative framework type Incremental: combination of linear and iterative framework type Spiral: combination of linear and iterative framework type Rapid Application Development (RAD): Iterative Framework Type Extreme Programming.

Waterfall

Iterative and Incremental development Develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental).

Incremental development slices the system functionality into increments (portions). In each increment, a slice of functionality is delivered through cross-discipline work, from the requirements to the deployment. The unified process groups increments/iterations into phases: inception, elaboration, construction, and transition

Iterative and Incremental development is at the heart of a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interactions in between.

Iterative and incremental development are essential parts of the Rational Unified Process, Extreme Programming and generally the various agile software development frameworks.

Agile software Overview

Agile software development is based on an Iterative and Incremental concept to software development, which is performed in a highly shared manner by self-organizing teams that readiness produces high quality software in a cost effective and timely manner, which meets the changing needs of its follower

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly.

An agile software project mean to be capable of releasing new software at the end of every iteration. In many cases, software is released at the end of each iteration. This is particularly true when the software is web-based and can be released easily. Including all of these at the end of every team re-evaluates project priorities.

In Agile points of view they take care of the following point: Individuals and interactions over all the process and development steps

Usually they take care of creating an engineering discipline for software development. They believe on the principles that might relate to the value of common sense, good people management principles. They provided all the necessary and supportive environment that need of the highly productive and motivated team for succeed and also allow the freedom to use of their (Development team) own development knowledge and skills and also encourage them to improve their skills and also trust them. These are basic human motivation principles and certainly not unique to the agile alliance.

Working software over large scope of documentation

The basic theme of agilites have not said that there is no need of the documentation but they are arguing against the concept of comprehensive documentation. Their main aim behind the minimal documentation could be the concept behind the documenting within the code was so simple while some of the software developer told that it means that no documentation but by agilities mind if the code was so simple; so well structured; and so neatly commented that it was intuitively easy to

follow. They think about how easy it would be to maintain old code if that code conformed to well

established structure and commenting standards. The agile methods do not preclude peer reviews or code walkthroughs. The same method followed agilites teams actually did these “processes,” think about how much less comprehensive the documentation would have to be.

Customer collaboration over contract negotiation

This value does not say no contracts. It acknowledges something to know to be true that requirements change. The idea behind the topic is only that development team should not create the long time period between engineer and the customer meeting the engineer should have to keep the customer close and the method that follow by the agile is about to regular contact between customer and the developer.

Responding to change over following a plan 

The main theme behind the successful software development of agile is that there is no need of the plan but responding to change is more precious in comparison to following the plan. According to Agile's if we have to make our software more user friendly and flexible to work with prefect structure then we should have adopt the changes according to time requirement.

Agile Principles :-

The group then went further to define the principles behind the Agile Manifesto. The Agile Principles are listed here:

1. Agile's take care of the customer through early and continuous delivery of useful software.

2. Agile's are ready to face any type of changing during the development.     

3. Agile's are much serious about to deliver software frequently as soon as possible.

4. Agile's basic rule is the cooperation and communication between the customer and developers.

5. Agile's build the projects around individuals motivation.

6. Agile's also take care of communication via face-to-face conversation.

7. Working software is the primary measure of progress.

8. They provide the simplicity in their project.

9. Continuous attention to technical excellence and good design.

10. Agile provide the working software it is the assessment of the progress.

11. The best requirements analysis and designs take care by trusted consider team.

12. As per the requirement they are ready for any changes.

Agile Methods:-

There are many agile methods and most of them try to minimize risk by developing software in limited time period called iterations and each iteration is like a mini software project of its own including all the necessary step to make a new functionality like analysis, planning, design, coding, testing and documentation.

All the methods used in agile are :-

1. Extreme Programming (or XP):- is a software engineering methodology, the most

prominent of several agile software development

methodologies (Beck 1999).

2. Scrum: - is an agile software development method for project management (Schwaber 1995 and by Schwaber and Beedle 2002).

3. Crystal Clear: - is a member of the Crystal family of methodologies as described by Alistair Cockburn and is considered an example of an agile or lightweight methodology (Cockburn 2002).

4. Feature Driven Development (Palmer and Felsing 2002).

5. The Rational Unified Process (Kruchten 1996; Kruchten 2000).

6. Dynamic development Method (Stapleton 1997),

7. Adaptive Software Development: - is a software development process that grew out of rapid application development work by Jim Highsmith and Sam Bayer in 2000.

8. Open basis Software development (O'Reilly 1999).

Important Things:-

Time boxing:-

Time boxing is a time management technique common in planning projects (typically for software development), where the schedule is divided into a number of separate time periods (timeboxes, normally two to six weeks long), with each part having its own deliverables, deadline and budget. Timeboxing is a core aspect of rapid application development (RAD) software development processes such as dynamic systems development method (DSDM) and agile software development.

Pair programming: -

Pair programming is an agile software development technique in which two programmers work together at one work station. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer (or navigator). The two programmers switch roles frequently.

Sprint (software development): -

A sprint is a time-boxed period of software development focused on a given list of goals (but with variable scope).The sprints are often held near conferences which most of the project team attend, but they can also be hosted by some involved party at their premises or some interesting location. Sprints can vary in focus. During some sprints people new to the project are welcomed and get an intensive hands-on introduction pairing with an experienced project member. The first part of such sprints is usually spent getting ready, presenting the tutorials, getting the network setup and CVS or Subversion checkouts working on everyone's computers. A different kind of sprint is where only the core team gathers and gets some important work done in a concentrated manner.

A significant benefit of sprinting is that the project members meet in person, socialize, and start to communicate more effectively than when working together remotely.

=====================================================================

Agile Method:-

Scrum Methodology:-

Scrum is an (agile approach to software development) iterative, incremental framework for project management and agile software development.

1. The Product Backlog: -

The Product Backlog is the master list of all functionality desired in the product.

2. The Release Backlog: -

Selected functions from Product Backlog list that we will release first.

3. The Sprint Backlog: -

The sprint backlog is the list of tasks that the Scrum team is committing that they will complete in the current sprint. Items on the sprint backlog are drawn from the Product Backlog/ Release Backlog, by the team based on the priorities set by the Product Owner and the team's perception of the time it will take to complete the various features. The sprint backlog is very commonly maintained as an Excel spreadsheet but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile. An example of the Sprint Backlog in Excel.

.4. The Product Owner: -

The Product Owner (typically someone from a Marketing role or a key user in internal development) prioritizes the Product Backlog . The Scrum Team looks at the prioritized Product Backlog and slices off the top priority items and commits to completing them during a sprint. These items become the Sprint Backlog. In return for their commitment to completing the selected tasks (which, by definition, are the most important to the product owner), the product owner commits that he or she will not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint it remains maniacally focused on the goal of that sprint.

5. ScrumMaster: -

The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster protects the team by making sure they do not over-commit themselves to what they can achieve during a sprint. The ScrumMaster facilitates the daily scrum and becomes responsible for removing any obstacles that are brought up by the team during those meetings. The ScrumMaster role is typically filled by a project manager or a technical team leader but can be anyone.

6. The Scrum Team: -

Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together." A typical Scrum team is 6-10 people but Jeff Sutherland has scaled Scrum up to over 500 people and I have used it with over 150.

7. The Daily Scrum Meeting: -

On each day of a sprint, the team holds daily meetings (“the daily scrum”). Meetings are typically held in the same location and at the same time each day. Ideally the daily scrums are held in the morning as they help set the context for the coming day's work. All team members are required to attend the daily scrum. Anyone else (for example, a departmental VP, a salesperson, or a developer from another project) is allowed to attend but is there only to listen. This makes the daily scrums an excellent way for a Scrum team to disseminate status information--if you're interested in hearing where things are at, attend that day's meeting. The daily scrum is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant sub-group immediately after the daily scrum. During the daily scrum each team member provides answers to the following three questions:

1. What did you do yesterday? 2. What will you do today? 3. Are there any impediments in your way?

8. Burn down Chart: -

The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.

A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed. It is often used in agile software development methodologies such as Scrum.

So Finally Scrum is:- Scrum is an agile approach to software development. Rather than a full process or

methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the team. This is done because the team will know best how to solve its problem. This is why, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as would be provided in most methodologies.

Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. The team is cross-functional so that everyone necessary to take a feature from idea to implementation is involved.

These teams are supported by two specific individuals: A Scrum Master and a Product owner. The ScrumMaster can be thought of as a coach for the team, helping team members use the Scrum framework to perform at their highest level. The product owner represents the business, customers or users and guides the team toward building the right product.

Scrum projects make progress in a series of sprints, which are time boxed iterations no more than a month long. At the start of a sprint, team members commit to delivering some number of features that were listed on the project’s product backlog. At the end of the sprint, these features are done--they are coded, tested, and integrated into the evolving product or system.

At the end of the sprint a sprint review is conducted during which the team demonstrates the new functionality to the product owner and other interested stakeholders who provide feedback that could influence the next sprint.

FLOW