|Software development process|
|Activities and steps|
|Requirements · Specification
Architecture · Design
Implementation · Testing
Deployment · Maintenance
|Agile · Cleanroom · DSDM
Iterative · RAD · RUP · Spiral
Waterfall · XP · Scrum · Lean
V-Model · FDD · TDD
Quality assurance (SQA)
User experience design
|Compiler · Debugger · Profiler
Integrated development environment
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.
Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma.
There are many specific agile development methods. Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. The only metric showing Agile method is more productive than other methods is a Dr. Dobb's Journal survey. 
Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations may be required to release a product or new features.
Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements.
Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.
Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.
No matter what development disciplines are required, each agile team will contain a customer representative. 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 problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals.
Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems from being hidden.
Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration.
Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility.
The modern definition of agile software development evolved in the mid-1990s as part of a reaction against "heavyweight" methods, perceived to be typified by a heavily regulated, regimented, micro-managed use of the waterfall model of development. The processes originating from this use of the waterfall model were seen as bureaucratic, slow, demeaning, and inconsistent with the ways that software developers actually perform effective work. A case can be made that agile and iterative development methods mark a return to development practice from early in the history of software development. Initially, agile methods were called "lightweight methods."
An adaptive software development process was introduced in a paper by Edmonds (1974). Notable early Agile methods include Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995). These are now typically referred to as Agile Methodologies, after the Agile Manifesto published in 2001.
In 2001, 17 prominent figures in the field of agile development (then called "light-weight methods") came together at the Snowbird ski resort in Utah to discuss ways of creating software in a lighter, faster, more people-centric way. They coined the terms "Agile Software Development" and "agile methods", and they created the Agile Manifesto, widely regarded as the canonical definition of agile development and accompanying agile principles. Later, some of these people formed The Agile Alliance, a non-profit organization that promotes agile development.
Agile methods are a family of development processes, not a single approach to software development. The Agile Manifesto states:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Some of the principles behind the Agile Manifesto are:
The manifesto spawned a movement in the software industry known as agile software development.
The functioning principles of Agile can be found in lean manufacturing and six sigma. These concepts include error proofing, eliminating waste, creating flow, adding customer value, and empowering workers. The concepts were first formally espoused in the 14 principles of the Toyota Way, the two pillars of the Toyota Production System (Just-in-time and smart automation), the 5S methodology, and Deming’s 14 points. These have been summarized in the seven points of lean software development.
Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methods. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined". A more accurate distinction is that methods exist on a continuum from "adaptive" to "predictive". Agile methods lie on the "adaptive" side of this continuum.
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 will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.
Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.
Agile methods have much in common with the "Rapid Application Development" techniques from the 1980/90s as espoused by James Martin and others.
Most agile methods share other iterative and incremental development methods' emphasis on building releasable software in short time periods. Agile development differs from other development models: in this model time periods are measured in weeks rather than months and work is performed in a highly collaborative manner. Most agile methods also differ by treating their time period as a timebox.
Agile development has little in common with the waterfall model. The Waterfall methodology is the most structured of the methods, stepping through requirements, analysis, design, coding, and testing in a strict, pre-planned, "all at once" sequence. Progress is often measured in terms of deliverable artifacts: requirement specifications, design documents, test plans, code reviews and the like.
A common criticism of the waterfall model is its inflexible division of a project into separate stages, where commitments are made early on, making it difficult to react to changes in requirements as the project executes. This means that the waterfall model is likely to be unsuitable if requirements are not well understood/defined or change in the course of the project.
Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early and continually improving it and/or adding further functionality throughout the life of the project. If a project being delivered under Waterfall is cancelled at any point up to the end, there is often nothing to show for it beyond a huge resources bill. With Agile, being cancelled at any point will still leave the customer with some worthwhile code that has likely already been put into live operation.
Some agile teams use the waterfall model on a small scale, repeating the entire waterfall cycle in every iteration. Other teams, most notably Extreme Programming teams, work on activities simultaneously.
"Cowboy coding" is the absence of a defined or structured method; i.e., team members do whatever they feel is right. The Agile approach is sometimes confused with cowboy coding due to its frequent re-evaluation of plans, emphasis on face-to-face communication, and relatively sparse use of documentation. However, Agile teams follow clearly defined, even rigid processes and controls (e.g., deadlines for completion of coding/testing); it is likely the flexibility and adaptability of the overall methodology which causes the confusion. Further, Agile controls offer stronger levels of accountability. The degradation of such controls or procedures can lead to activities that are often categorized as cowboy coding.
There is little if any consensus on what types of software projects are best suited for the agile approach. Many large organizations have difficulty bridging the gap between the traditional waterfall method and an agile one.
Some things that can negatively impact the success of an agile project are:
Several successful large scale agile projects have been documented. BT has had several hundred developers situated in the UK, Ireland and India working collaboratively on projects and using Agile methods. While questions undoubtedly still arise about the suitability of some Agile methods to certain project types, it would appear that scale or geography, by themselves, are not necessarily barriers to success.
Barry Boehm and Richard Turner suggest that risk analysis be used to choose between adaptive ("agile") and predictive ("plan-driven") methods. The authors suggest that each side of the continuum has its own home ground as follows:
Agile home ground:
Plan-driven home ground:
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 through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments determine a system development approach for a specific project situation.
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. 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 by Beck, has been reported on several occasions. A tailoring practice is proposed by Mehdi Mirakhorli which provides sufficient roadmap and guideline for adapting all the practices. RDP Practice is designed for customizing XP. This practice first time proposed as a long research paper in APSO workshop at ICSE 2008 conference and yet it is 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. The key assumption behind static method adaptation is that the project context is given at the start of a project and remains fixed during project execution. The result is a static definition of the project context. Given such a definition, route maps can be used in order to determine which structured method fragments should be used for that particular project, based on predefined sets of criteria. Dynamic method adaptation, in contrast, assumes that projects are situated in an emergent context. An emergent context implies that a project has to deal with emergent factors that affect relevant conditions but are not predictable. This also means that a project context is not fixed, but changing during project execution. In such a case prescriptive route maps are not appropriate. The practical implication of dynamic method adaptation is that project managers often have to modify structured fragments or even innovate new fragments, during the execution of a project (Aydin et al., 2005).
Some of the well-known agile software development methods:
Note: Although these are often considered methodologies in and of themselves, they are simply practices used in different methodologies.
Agile software development depends on some special characteristics possessed only by software, such as object technologies and the ability to automate testing. However, related techniques have been created for developing non-software products, such as semiconductors, motor vehicles, or chemicals. For more on them, see Flexible product development.
While agility can be seen as a means to an end, a number of approaches have been proposed to quantify agility. Agility Index Measurements (AIM) score projects against a number of agility factors to achieve a total. The similarly-named Agility Measurement Index , scores developments against five dimensions of a software project (duration, risk, novelty, effort, and interaction). Other techniques are based on measurable goals . Another study using fuzzy mathematics has suggested that project velocity can be used as a metric of agility. There are agile self assessments to determine whether a team is using agile practices.
While such approaches have been proposed to measure agility, the practical application of such metrics has yet to be seen.
The criticisms regarding insufficient software design and lack of documentation are addressed by the Agile Modeling method, which can easily be tailored into agile processes.
Agile software development has been criticized because it may not bring about all of the claimed benefits unless utilized by above average programmers; above average programmers create above average code regardless of the method used.
Agile does not readily lend itself to traditional project accounting practices, therefore financial forecasting is less predictable when with Agile development. 
With a passionate drive towards reducing, if not eliminating documentation, teams establish a direction that can be perceived as satisfying the core Agile Manifesto. As an individual team member, this direction provides for greater efficiency in the short term and provides for more rapidly observed delivery by the stakeholder. The dangers are the loss of recognition that systems/solutions change continually over time as well as team members. Software’s highly complex nature as well as aggressively becoming mission critical to businesses, demands more thorough understanding of decisions being made when changes are to take place. Without having designs or details on purpose and process, the effectiveness of the team diminishes and forces developers to go through the code to discover solutions. Current software industry trends support system solution reuse and the ability to have disparate data sources through SOA architecture. Knowledge of the business process in communication across different domains makes for greater difficulty when designs are unavailable as reference when change is to occur and the subsequent validation of the impact of that change for business risk management. The developer is forced to ‘trace’ through code invariably written by other programmers without the knowledge of purpose and direction. Essentially it is a balance that is needed to determine where documentation in fact ‘has value’ for the greater good of the business as a whole and often to the disadvantage of the initial development team trying to get the solution completed.
A reminder that the very first day a new solution is deployed, is the very first day it has become a legacy system ready for change.
Agile development has been the subject of several conferences. Some of these conferences have had academic backing and included peer-reviewed papers, including a peer-reviewed experience report track. The experience reports share industry experiences with agile software development.
As of 2006, experience reports have been or will be presented at the following conferences:
On February 11-13, 2001, at The Lodge at Snowbird ski resort in
the Wasatch mountains of Utah, seventeen people met to talk, ski,
relax, and try to find common ground and of course, to eat. What
emerged was the Agile Software Development Manifesto.
Representatives from Extreme Programming, SCRUM, DSDM, Adaptive
Software Development, Crystal, Feature-Driven Development,
Pragmatic Programming, and others sympathetic to the need for an
alternative to documentation driven, heavyweight software
development processes convened. Now, a bigger gathering of
organizational anarchists would be hard to find, so what emerged
from this meeting was symbolic a Manifesto for Agile Software
Development signed by all participants.
Taken from: "History: The Agile Manifesto"
So why bother with agile methodologies?
Alistair Cockburn did research about how a process influences project teams. He concludes that the larger a project team the more a process can influence the effectiveness of the project development. However it is the people in the project teams that repeatedly argue the process that is proposed to use. Alistair Cockburn summarizes this behaviour in his quote: “People trump process”. It is true that good enough people in a team can deliver a solution where no process can improve the quality of the outcome. The most interesting part that contributed to the manifestation of agile methodologies is the fact that people working together with good communication and interaction have the ability to perform at significant higher levels than operated on an individual basis. According to Cockburn this becomes apparent time and again in brainstorming and joint problem-solving sessions. This the reason agile methodologies can contribute to project teams by focusing on increasing both the individual competencies and the collaboration levels.
For further reading visit: URL:http://agilemanifesto.org
On February 11-13, 2001, seventeen people met at the Lodge in the Wasatch mountains of Utah, they initiated an agile manifesto.
They were :
The Agile manifesto encompassed the idea of several pre-existing methodologies including:
These authors all work for the software industry, and did a great distribution on agile software development. That’s the reason why they became participates for the Agile manifesto.
Agility is the ability to both create and respond to change in order to profit in a turbulent business environment - Jim Highsmith, Agile Software Development Ecosystems 
Such a general description allows a lot of room for debate as to whether a particular methodology is Agile or not. Where there is debate, it is fair to say that a methodology which doesn't have the following principles cannot consider itself Agile.
It's also fair to say that an Agile team that fails to realize any of these principles will struggle and probably fail.
Adaptive software development is a management to control software project for changeable requirement and short period project.
The three key point of adaptive software development are:
“The overriding, powerful, indivisible, predominant benefit of the Adaptive Development Life Cycle is that it forces us to confront the mental models that are at the root of our self-delusion. It forces us to more realistically estimate our ability.” - Jim Highsmith 
To view the Crystal Methods section, please click the following link:
What is DSDM?
DSDM is an example of an iterative (Agile) development model. DSDM approaches every step in the process to be completed only enough to be able to move to the next step. Since agile development is applied in situations where business requirements are likely to change, any further work would not benefit the overall process of delivery. The DSDM Consortium defines DSDM as a framework based on best practises that can be used to deliver new systems, which combines the most effective use of people's knowledge, tools and techniques to achieve tight project delivery timescales. The DSDM framework serves as a basis for a development and implementation process whether it is an IT project or a business change. The framework includes people (staff and skills), the technology that supports them (IT) and the processes that bind them all together (the business strategy).
The goal of DSDM is to target a demand for organizations to deliver working systems in shorter timescales. A typical DSDM project delivers an operational system within six months. The main emphasis however is that, according to the DSDM organization, most projects fail because of people issues rather than technology. Therefore the focus is providing people with guidelines to work together in a way that business goals are achieved successfully.
Because of the agile approach, DSDM build systems focus on the current needs in contrast to the traditional approach of going through all the perceived possibilities. Therefore, the resulting system is expected to better fit the business needs, be easier to test and be more likely to be accepted into the users' working practices.
The DSDM Framework Principles
The framework is based on nine initial principles which are applied in the different phases of the methodology:
Source: DSDM Consortium, underlying principles
The DSDM Framework Phases
The framework defines phases that apply to the process in the case of a new system development or the change of business processes. The core project process is preceded by the Pre-Project phase and end with the Post-Project phase:
Within DSDM the phases “Feasibility Study” and “Business Study” are firstly done in sequence. Because these phases set the foundation rules for the rest of the iterative and incremental development in the remaining phases, they must be before any other work is done in a project. With these first two core phases done, the other three phases can overlap and be merged in any other order appropriate to the project. When the project solution is delivered the project team will hand over the solution to the Post-Project phase. This final phase includes the process of maintaining the solutions operations and monitoring the performance to make sure that the business requirements have been met.
Figure 1. DSDM Phases
Within each phase the goal is to produce a minimum set of products. These products are often specific documentation with a defined criteria and purpose. As a result the achievement of every purpose can be assessed. The way these products are produced and what the content will be, is left open for the concerning organization or project to determine. Table 1 provides an overview of the activity and products that apply to the DSDM phases.
Table 1. DSDM activity and products
|Pre-Project||Ensures that only the right projects are started and setup correctly. Performs any initial project planning for the Feasibility Study.||No formally defined DSDM products|
|Feasibility Study||Determines if DSDM is the right approach for the project. Defines the problem to be addressed, the costs and technical feasibility.||
|Business Study||Focuses on the business processes affected as well as their information needs. Deliverable: Business Area Definition.||
|Functional Model Iteration||Refines the business-based aspects of the system building on the high-level processing and information requirements identified in the Business Study.||
|Design and Build Iteration||The system is engineered to a sufficiently high standard to be safely placed in the hands of the users. Deliverable: the Tested System.||
|Implementation||Involves training the users and transferring the system from the development environment to the operational environment. Deliverable: Increment Review Document||
Post-Implementation Review Report
For further reading visit: URL:http://www.dsdm.org/version4/2/public/default.asp
Feature Driven Development(FDD) is a model driven process of short iterations (two weeks). An overall model is established at the beginning of a project after which the project continues with a series of design by feature/build by feature iterations. A feature is a small and “useful in the eyes of the client” result.
FDD consists of five processes, three of which are per project, the other two being per feature.
This process involves the domain experts, chief architect and chief programmers. The main goal here is to establish the overall shape of the system. Classes and their inter relationships are defined.
This process involves the domain experts, chief architect and chief programmers. Its goal is to produce fine grained feature list. Essentially the model developed in process 1 is functionally decomposed into subject areas. Each subject area contains business activities and each business activity can be broken into a number of business steps. The categorisation of these steps forms the feature list.
The feature sets are sequenced into a high level plan and assigned to chief programmers.
A small set of features are designed by a feature team. Each feature is represented by a sequence diagram in UML. This diagram is the design deliverable and is peer reviewed by the feature team against the requirements.
The code for each feature is written by the members of the team who own the business classes affected by the functionality of that feature. The completed code is peer reviewed. Once the code has passed the review and been unit tested it is marked for inclusion in the system build.
FDD is built around a set of eight best practices each of which complements the other. The practices are not exclusive to FDD, but are used in a unique combination in FDD.
For each feature of the feature list there are six discrete milestones. Three of which belong to the Design by Feature process; Domain Walkthrough, Design, Design Inspection; and three which belong to the Build by Feature process; Code, Code Inspection, Promote to Build.
Although Robert Charette originally defined the principles of Lean Development, he has not been it's primary proponent nor has he contributed much to the body of work relating to Lean Software Development. Instead, Lean Software Development has mainly been popularized through the work of Mary and Tom Poppendieck. They describe in detail how to apply the principles of lean production to the software development process. They specify a set of seven principles and 22 tools to help realise those principles. (Charette lists twelve principles )
Since Lean Development derives it's principles and practices from Lean Production it is important to have an understanding of Lean Production (sometimes referred to as Lean Manufacturing).
The concepts and tools of Lean Production were laid out in Womack, Jones and Roos book "The machine that changed the World: The Story of Lean Production". Lean Production draws on several production processes including Toyota Production System (TPS), just-in-time manufacturing and inventory management as well as adding it's own ideas to the mix. One of the key ideas in Lean Production - eliminate waste - is drawn from TPS. TPS has an extensive definition for waste, breaking it down into seven categories and suggesting how to deal with each one. Lean Software development then is the application of the principles of Lean Production to the software process.
Lean Development allows companies to manage their risk and turn that risk into an opportunity. Robert Charette refers to this as "risk entrepreneurship" [Agile Software Development Ecosystems, Highsmith, 2002]. By proactively dealing with risk and adapting to changes in the market place brought about by circumstances and competitors a company can gain a competitive advantage. Lean Development enables software systems to adapt to this change rapidly, something that software systems are generally known for.
There are seven principles of lean development (though sometimes twelve are listed). Also, the naming of some of the principles has changed with time.
In Lean Software Development : An Agile Toolkit  the following principles are listed
(Titles in brackets are apparently newer names used in Implementing Lean Software Development )
In TPS, Taiichi Ohno analysed the concept of waste in great detail and categorised different types of waste, and ways of addressing them. In explaining Ohnos concept of waste, Poppendieck uses the phrase "anything with does not create value for a customer is waste" [ASDE, Highsmith] and when applied to software development this translates to implementation of features that are not core requirements, poor or missing requirements, administrative overhead and bureaucracy. Poppendieck maps Ohnos concepts of waste to software as follows:
|Manufacturing||Software Development !|
|In-Process Inventory||Partially Done Work|
Tools: Seeing Waste, Value Stream Mapping
Take advantage of the short iterations and feedback from customers to learn how to improve the product and the process. Present a choice of solutions as working prototypes rather than explore possible solutions. This way you limit choice as well as get a head start on the final solution.
Tools: Feedback, Iteration, Synchronization, Set-Based Development
In traditional software development processes, important decisions are made far in advance of implementation. Any mistakes made at the distant planning stage are amplified in implementation and their effect on the whole process. By deferring decisions to as late as possible the implications of mistakes are limited and you also can deal with change more easily.
Tools: Options Thinking, The Last Responsible Moment Making Decisions
Business success is often achieved by responding rapidly to change. A customer who needs a system for commercial applications wants that system as fast as possible. The faster you can deliver that system the greater the value to the customer and the greater the long term benefit to you. The concepts of this principle are related to the theory of Just-In-Time delivery.
Tools: Pull Systems, Cost of Delay, Queuing Theory
"An organization that respects software developers as professionals will expect them to design their own jobs with proper training, coaching, and assistance. It will expect them to improve continually the way they do their work as part of a learning process. Finally, it will give them the time and equipment necessary to do their jobs well. In a lean organization, the people who add value are the centre of organizational energy. Frontline workers have process design authority and decision-making responsibility; they are the focus of resources, information and training." [Chapter 5]
Instead of treating software developers as cogs in a wheel, respecting their needs and abilities will give them a sense of responsibility and increase their motivation, and ultimately benefits everyone. Tools: Self-Determination, Motivation, Leadership, Expertise
Perceived Integrity - the ability of the software to "delight" the customer by functioning well, and Conceptual Integrity - a sense of cohesiveness and integrity between different parts of the system are key demand of customers. Refactoring and Testing ensure that these goals are achieved.
Tools: Perceived Integrity, Conceptual Integrity, Refactoring, Testing
By choosing the right measures and interpreting the measures correctly we can find the root cause and source of defects in systems. The assumptions are that defects are caused by individuals when in fact they are the caused by the processes and procedures in the system. Also, most projects are made up of many sub-teams, vendors and contractors. A shared agreement and understanding of goals is of huge benefit for the project and company in the long term.
Tools: Measurements, Contracts
Extreme Programming (XP) was developed by Kent Beck in mid 90’s. As projects reduced in size and became more dynamic with rapidly changing requirements, there was a need for quick project development life-cycle. Since 70’s widely used approach had linear structure characteristic known as “Waterfall Model”, project scope was planned out at the beginning of the project life-cycle, in which changing requirements in the middle of the development, made it very costly. Frequently changing requirements by customers required for more agile approach.
XP is known as a methodology of Agile development. This is used in small, collocated project teams up to 10 members, more is probable. Development is flexible and lightweight. XP is based on twelve practices and four groups - collaboration, feedback, revision and respect.
Code is the most important part of XP, complete documentation is considered as a waste of assets. Simple code and design form the basis; this is understandable to programmers who join the team at the later stages. Peer programming complements it – what is obvious for one, is not for another, following the decisions is easy to understand the thought of the colleague.
There are twelve core practices in XP stated as a standard:
Scrum is a flexible process control for complex software project. It uses iterative and incremental practices on the software product. It is raised in 1995 by Advanced Development Methodologies,Inc, and has become popular after the Agile Alliance is created since 2001.
The hypothesis of Scrum is, at the begin of the product development, we could not definite the product’s final requirements. During the development duration, we need creation, develop, and get experience from mistakes, so there is no fixed procedure we can warrant the success. It seems like the Rugby football team, they have highest priority goal, familiar with the development process, have high self-control authority, and cooperate tightly, to ensure the develop team is going ahead to achieve their goals on every phase, every day.
One iteration lasts 30 days, it starts from the beginning of the new product’s requirements. The develop team must implement all functional parts which they select from the beginning. They have daily meeting, spend 15 minutes, to check the progress of every team number, to know what difficulties they met and try to resolve them as soon as possible.
The most advantage of Scrum would be its changeability. Scrum can take action when something changes, e.g. requirement change from marketing.
Because of the changeable requirements using Scrum development process, it makes a great challenge to feature testing team especially when they are under developing test case. Because of unfixed and often changed requirements in every unit Sprint, testers often need to re-work on develop test case in a short time.
Glossary of Scrum terms
(Material in this section is based on information available at Scrum Alliance)
Backlog: Backlog is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements.
Sprint: An iteration of work during which an increment of product functionality is implemented.
Sprint backlog: Defines the work for a sprint, represented by the set of tasks that must be completed to realize the sprint's goals, and selected set of product backlog items.
ScrumMaster: The ScrumMaster is a facilitator for the team and product owner.
Time-box: The duration time of daily meeting.
Sprint planning meeting: The Sprint planning meeting is a negotiation between the team and the product owner about what the team will do during the next sprint.
Daily Scrum meeting: A fifteen-minute daily meeting for each team member to answer three questions:
The ScrumMaster ensures that participants call sidebar meetings for any discussions that go too far outside these constraints. The Scrum literature recommends that this meeting take place first thing in the morning, as soon as all team members arrive.
Sprint review meeting: The team shows their achievement to their product owner during this sprint. It lasts 4 hours.
Sprint retrospective meeting: The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. It lasts 3 hours.
Ken Schwaber provides an informative and entertaining overview of SCRUM in this Google Tech Talk
The methodology chosen needs to be on a level that the company is willing to work with. Different levels have different requirements such as:
Extreme Programming (XP) is far more detailed than the other methodologies and defines programming practices, whereas the other methodologies are mainly involved with the project management and planning issues
The agile methodologies have different degrees of support for the different parts of the software development project's life-cycle.
The methodology to choose depends on:
All the above will determine firstly whether or not to take work with an Agile Methodology and secondly, which agile methodology to choose.
While only a few tools are exclusively applicable to Agile, many tools have been developed to meet the needs of Agile teams and have gone on to find wider audiences. Many of the tools listed here are either specific to Java, or were developed for and with Java but now support other languages. This is mainly due to the popularity of Java during the time that Agile methods were widely adapted. Many tools exist for other languages also.
Version control is a central configuration management activity in any Agile project. Code is written frequently and checked in every day at least. A reliable version control system is central to any agile project. There are dozens of version controls systems to choose from, only the most widely used are listed below, but even that doesn't approach a complete list
Unit Testing is one of the principles of XP and other Agile methodologies and a whole ecosystem of unit testing frameworks has sprung up around Unit tests test code functionality at the smallest possible level of granularity. In object oriented programming this is usually at the level of a single method. There are simply too many unit testing frameworks to list here however the most widely known is probably JUnit.
Mock Objects Mock Objects and unit testing are intrinsically linked. Mock object allow you to create simulations of dynamic complex objects so that dependent code can be reliably tested without having to manage the complex objects state and complexity. There are many mock objects libraries for each language, the list below is a brief selection of what's available:
Agile technique works well in collocated environments in relatively small developer teams four to ten people. Unlike ‘Waterfall’ model, ‘Agile’ development has iterative, burst characteristic, with a very little documentation and no set final plan of the project. This would not be suited for security critical, projects where dominates reliability.
If team is not collocated, weekly project meetings with customers or any other stakeholders impact the success of ‘Agile’ development. Collaboration is very important. ‘Agile’ principles propose face-to-face meetings; this is possible when the team members are collocated in the same premises. Significant setback is if members work from remote locations.
Extreme Programming practice is that refactoring should be performed regularly. Recoding existing code or changing the structure of the system, even discarding and writing brand new code, this is just not the most efficient way of using resources and assets. This could be prevented if the architecture of the system would be planned out at the beginning of the coding.
Most of the time programmer teams are formed by inexperienced engineers. ‘Agile’ development works well with experienced developers with a state-of-art coding. Supposing that less changes of the code should be done and the structure of the code need to be altered at the refactoring phase if the code would be written at their best practice.
‘Agile’ development is a very dynamic and elastic technique that could be applied in a variety of ways to different kinds of projects. Radically evolving technology creates a need for flexible ways of dealing with a new set of environments and rules. There is much scepticism in ‘Agile’ development, however the technique works well for many and they don’t want to discard it or apply heavy-weight development style instead. The set of ‘Agile’ tools and processes provided may be improved. Saying that current ‘Agile’ method is not final and it will be most definitely enhanced.