manual sdlc models i

G.C.Reddy (09247837478) [email protected]

Software Testing

Chapter I Software Development Life Cycle Models

Software: The instructions executed by a computer, as opposed to the physical device on which they run (the "hardware").

Software: Software is a set of programs; they take Inputs and provide Outputs.

Set of Instructions are called as Program.

A set of Programs are called Software unit/Component.

Integrated Units/components Called as a Software/System.

Software Testing:Testing: The process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.

G.c.Reddy- Knowledge Doc: GC 001 1

http://www.computer-dictionary-online.org/?q=hardware


Information TechnologyInformation Technology

Computer

Computer Hardware

Computer Software

Hardware Manufacturing

Hardware Testing

Hardware Testing

Software Development

Software Testing

Software

System SoftwareProgramming Software

System Software

Application Software

Operating Systems, Text Editors Banking ApplicationDevice Drivers, C, C++, Java, Spread Sheets Utilities COBOL, .Net Accounting S/wEtc... Etc... Etc…

Banking software MS Windows, MS Office,Insurance software Focus, Tally Etc…

Software Development:

I. Software Bidding: A Proposal to develop new software is called Software Bidding. In Software Application Development, the proposal comes from the specific customers.In Product development, Organization takes their own proposal.

G.c.Reddy- Knowledge Doc: GC 001

Software

Software Application Software Product

2


II. Kick off meeting: The CEO category People Conduct meeting with high level management and select a project manager to handle the new software development process.

III. Pin Document: The selected project manager prepares this document to estimate required people, required technologies, time and resources.Then he submits a report to CEO. The CEO conducts a review meeting to give green signal to project manager.

Software engineering: (SE) A systematic approach to the analysis, design, implementation and maintenance of software. It often involves the use of CASE tools. There are various models of the software life-cycle and many methodologies for the different phases.

Software Development Phases

Requirement Gathering

Analysis and Planning

Designing the software

Coding

Testing

Release & MaintenanceIn above SDLC model, single stage of Testing is available and conducts by developers. If any mistakes happen resolving is expensive, due to this reason organizations are concentrating on multiple stages of testing and separate testing Team to conduct System Testing.

Quality:

The meaning for the term quality has developed over time. Various interpretations are given below:

1. ISO 9000 - "Degree to which a set of inherent characteristic fulfills requirements"

2. "Fitness for use". Fitness is defined by the customer.

3. A two-dimensional model of quality. The quality has two dimensions: "must-be quality" and "attractive quality". The former is near to the "fitness for use" and the latter is what the customer would love, but has not yet thought about. Supporters characterize this model more succinctly as: "Products and services that meet or exceed customers' expectations".

4. "Value to some person".

Software quality: The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs.


http://en.wikipedia.org/wiki/Value_theory

http://en.wikipedia.org/wiki/Service_(economics)

http://en.wikipedia.org/wiki/Product_(business)

http://en.wikipedia.org/wiki/ISO_9000

http://www.computer-dictionary-online.org/?q=methodologies

http://www.computer-dictionary-online.org/?q=software%20life-cycle

http://www.computer-dictionary-online.org/?q=CASE

http://www.computer-dictionary-online.org/?q=software


Software Quality: Meet customer Requirements (Functionality). Meet customer expectations (Usability, Performance, Reliable etc...). Cost to purchase (Reasonable). Time to Market.

Software Quality Assurance:The monitoring and Measuring the Strength of development process is called SQA or Verification.

Software Quality Control:The validation of Product with respect to customer requirements is called SQC or Validation or Testing.Verification: Confirmation by examination and through the provision of objective evidence that specified requirements have been fulfilled. Validation: Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled.

Software Development Life Cycle Models

The waterfall model

The waterfall model derives its name due to the cascading effect from one phase to the other as is illustrated in Figure1.1. In this model each phase well defined starting and ending point, with identifiable deliveries to the next phase.

Note that this model is sometimes referred to as the linear sequential model or the software life cycle.



The model consists of six distinct stages, namely:

1. In the requirements analysis phase

(a) The problem is specified along with the desired service objectives (goals)

(b) The constraints are identified



2. In the specification phase the system specification is produced from the detailed definitions of (a) and (b) above. This document should clearly define the product function.

Note that in some text, the requirements analysis and specifications phases are combined and represented as a single phase.

3. In the system and software design phase, the system specifications are translated into a software representation. The software engineer at this stage is concerned with:

Data structure

Software architecture

Algorithmic detail and

Interface representations

The hardware requirements are also determined at this stage along with a picture of the overall system architecture. By the end of this stage the software engineer should be able to identify the relationship between the hardware, software and the associated interfaces. Any faults in the specification should ideally not be passed ‘down stream’

4. In the implementation and testing phase stage the designs are translated into the software domain

Detailed documentation from the design phase can significantly reduce the coding effort.

Testing at this stage focuses on making sure that any errors are identified and that the software meets its required specification.

5. In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. After this stage the software is delivered to the customer [Deliverable – The software product is delivered to the client for acceptance testing.]

6. The maintenance phase the usually the longest stage of the software. In this phase the software is updated to:



Meet the changing customer needs

Adapted to accommodate changes in the external environment

Correct errors and oversights previously undetected in the testing phases

Enhancing the efficiency of the software

Observe that feed back loops allow for corrections to be incorporated into the model. For example a problem/update in the design phase requires a ‘revisit’ to the specifications phase. When changes are made at any phase, the relevant documentation should be updated to reflect that change.

Advantages

Testing is inherent to every phase of the waterfall model

It is an enforced disciplined approach

It is documentation driven, that is, documentation is produced at every stage

Disadvantages

The waterfall model is the oldest and the most widely used paradigm.However, many projects rarely follow its sequential flow. This is due to the inherent problems associated with its rigid format. Namely:

It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses.

As The client usually only has a vague idea of exactly what is required from the software product, this WM has difficulty accommodating the natural uncertainty that exists at the beginning of the project.

The customer only sees a working version of the product after it has been coded. This may result in disaster if any undetected problems are precipitated to this stage.

The Spiral Model

The spiral model, illustrated in Fig. 1.7, combines the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model, therein providing the potential for rapid development of incremental versions of the software. In this model the software is developed in a series of incremental releases with the early stages being either paper models or prototypes. Later iterations become increasingly more complete versions of the product.



As illustrate in Fig 1.7, the model is divided into a number of task regions.

Depending on the model it may have 3-6 task regions (/framework activities) our case will consider a ‘6-task region’ model.

These regions are:

1. The customer communication task – to establish effective communication between

developer and customer.

2. The planning task – to define resources, time lines and other project related

information..

3. The risk analysis task – to assess both technical and management risks.



4. The engineering task – to build one or more representations of the application.

5. The construction and release task – to construct, test, install and provide user

support (e.g., documentation and training).

6. The customer evaluation task – to obtain customer feedback based on the

evaluation of the software representation created during the engineering stage and

implemented during the install stage.

The evolutionary process begins at the centre position and moves in a clockwise direction. Each traversal of the spiral typically results in a deliverable. For example, the first and second spiral traversals may result in the production of a product specification and a prototype, respectively. Subsequent traversals may then produce more sophisticated versions of the software.

An important distinction between the spiral model and other software models is the explicit consideration of risk. There are no fixed phases such as specification or design phases in the model and it encompasses other process models. For example, prototyping may be used in one spiral to resolve requirement uncertainties and hence reduce risks. This may then be followed by a conventional waterfall development.

Note that each passage through the planning stage results in an adjustment to the project plan (e.g. cost and schedule are adjusted based on the feedback from the customer, project manager may adjust the number of iterations required to complete the software….)

Each of the regions is populated by a set of work tasks called a task set that are adapted to characteristics of the project to be undertaken. For small projects the number of tasks and their formality is low. Conversely, for large projects the reverse is true.

Advantages of the Spiral Model

The spiral model is a realistic approach to the development of large-scale software products because the software evolves as the process progresses. In addition, the developer and the client better understand and react to risks at each evolutionary level.

The model uses prototyping as a risk reduction mechanism and allows for the development of prototypes at any stage of the evolutionary development.

It maintains a systematic stepwise approach, like the classic life cycle model, but incorporates it into an iterative framework that more reflect the real world.

If employed correctly, this model should reduce risks before they become problematic, as consideration of technical risks are considered at all stages.



Disadvantages of the Spiral Model

Demands considerable risk-assessment expertise

It has not been employed as much proven models (e.g. the WF model) and hence may prove difficult to ‘sell’ to the client (esp. where a contract is involved) that this model is controllable and efficient. [More study needs to be done in this regard]

The ‘V’ Model:

V-model: A framework to describe the software development life cycle activities from requirements specification to maintenance. The V-model illustrates how testing activitiescan be integrated into each phase of the software development life cycle.

V stands for Verification and validation.This model defining Development process with testing stages, this model extension of SDLC model.



Software Development Life Cycle Models

I was asked to put together this high-level and traditional software life cycle information as a favor for a friend of a friend, so I thought I might as well share it with everybody.

The General Model

Software life cycle models describe phases of the software cycle and the order in which those phases are executed. There are tons of models, and many companies adopt their own, but all have very similar patterns. The general, basic model is shown below:

General Life Cycle Model



Each phase produces deliverables required by the next phase in the life cycle. Requirements are translated into design. Code is produced during implementation that is driven by the design. Testing verifies the deliverable of the implementation phase against requirements.

Requirements

Business requirements are gathered in this phase. This phase is the main focus of the project managers and stake holders. Meetings with managers, stake holders and users are held in order to determine the requirements. Who is going to use the system? How will they use the system? What data should be input into the system? What data should be output by the system? These are general questions that get answered during a requirements gathering phase. This produces a nice big list of functionality that the system should provide, which describes functions the system should perform, business logic that processes data, what data is stored and used by the system, and how the user interface should work. The overall result is the system as a whole and how it performs, not how it is actually going to do it.

Design

The software system design is produced from the results of the requirements phase. Architects have the ball in their court during this phase and this is the phase in which their focus lies. This is where the details on how the system will work is produced. Architecture, including hardware and software, communication, software design (UML is produced here) are all part of the deliverables of a design phase.

Implementation

Code is produced from the deliverables of the design phase during implementation, and this is the longest phase of the software development life cycle. For a developer, this is the main focus of the life cycle because this is where the code is produced. Implementation my overlap with both the design and testing phases. Many tools exists (CASE tools) to actually automate the production of code using information gathered and produced during the design phase.

Testing

During testing, the implementation is tested against the requirements to make sure that the product is actually solving the needs addressed and gathered during the requirements phase. Unit tests and system/acceptance tests are done during this phase. Unit tests act on a specific component of the system, while system tests act on the system as a whole.

So in a nutshell, that is a very basic overview of the general software development life cycle model. Now lets delve into some of the traditional and widely used variations.

Waterfall Model

This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.



Waterfall Life Cycle Model

Advantages

Simple and easy to use. Easy to manage due to the rigidity of the model – each phase has specific deliverables

and a review process. Phases are processed and completed one at a time. Works well for smaller projects where requirements are very well understood.

Disadvantages

Adjusting scope during the life cycle can kill a project No working software is produced until late during the life cycle. High amounts of risk and uncertainty. Poor model for complex and object-oriented projects. Poor model for long and ongoing projects. Poor model where requirements are at a moderate to high risk of changing.

V-Shaped Model

Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation.

Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering.

The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together.



The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well.

The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

V-Shaped Life Cycle Model

Advantages

Simple and easy to use. Each phase has specific deliverables. Higher chance of success over the waterfall model due to the development of test

plans early on during the life cycle. Works well for small projects where requirements are easily understood.

Disadvantages

Very rigid, like the waterfall model. Little flexibility and adjusting scope is difficult and expensive. Software is developed during the implementation phase, so no early prototypes of the

software are produced. Model doesn’t provide a clear path for problems found during testing phases.

Incremental Model

The incremental model is an intuitive approach to the waterfall model. Multiple development cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up into smaller, more easily managed iterations. Each iteration passes through the requirements, design, implementation and testing phases.

A working version of software is produced during the first iteration, so you have working software early on during the software life cycle. Subsequent iterations build on the initial software produced during the first iteration.



Incremental Life Cycle Model

Advantages

Generates working software quickly and early during the software life cycle. More flexible – less costly to change scope and requirements. Easier to test and debug during a smaller iteration. Easier to manage risk because risky pieces are identified and handled during its

iteration. Each iteration is an easily managed milestone.

Disadvantages

Each phase of an iteration is rigid and do not overlap each other. Problems may arise pertaining to system architecture because not all requirements are

gathered up front for the entire software life cycle.

Spiral Model

The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.

Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase.

Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.



Spiral Life Cycle Model

Advantages

High amount of risk analysis Good for large and mission-critical projects. Software is produced early in the software life cycle.

Disadvantages

Can be a costly model to use. Risk analysis requires highly specific expertise. Project’s success is highly dependent on the risk analysis phase. Doesn’t work well for smaller projects.

And that’s it. If you have any input, especially your views on advantages and disadvantages of any particular model, feel free to leave them in the comments and I can add them to my copy.



Introduction

This purpose of this paper is to give the CISSP student an understanding of the Software Development Lifecycle (SDLC) models available to software developers. The student will also see examples of where each model is most appropriate for various types of software development projects. The models covered are the ones most likely to be included in CISSP exam questions.

Note that the SDLC acronym is also used to represent System Development Life Cycle. In many cases, a decision is made to purchase or outsource the software and associated hardware and network systems needed to implement a new application. This is often referred to as the "buy or build" decision. This paper focuses on the Software Development Life Cycle models, but most of the phases, terms, and issues discussed apply to both the "buy" and "build" process.

SDLC Models

To help understand and implement the SDLC phases (Project Initiation, Design Analysis, System Design Specification, Programming and Testing, Installation and Maintenance, and Destruction), various SDLC models have been created by software development experts, universities, and standards organizations. New SDLC models are introduced on a regular basis as new technology and new research (and sometimes new fads) requires new SDLC techniques. Recent new SDLC models include Extreme Programming and Agile Development. This paper looks at the most commonly known and used models and describes situations where the model is an appropriate choice.

Waterfall Model

The Waterfall Model is the oldest and most well-known SDLC model. The distinctive feature of the Waterfall model is its sequential step-by-step process from requirements analysis to maintenance.

The major weakness of the Waterfall Model is that after project requirements are gathered in the first phase, there is no formal way to make changes to the project as requirements change or more information becomes available to the project team. Because requirements almost always change during long development cycles, often the product that is implemented at the end of the process is obsolete as it goes into production. The Waterfall Model is a poor choice for software development projects where requirements are not well-known or understood by the development team. It might not a good model for complex projects or projects that take more than a few months to complete. Think about doing a home improvement project (such as new hardwood floors) for the first time and only being allowed to go the hardware store one time. The risk the project will fail is high.

What are good candidate software development projects for the Waterfall Model? Systems that have well-defined and understood requirements are a good fit for the Waterfall Model. For instance, a military system aiming an artillery shell is a system with a single, simple requirement; put the shell on the target. This also assumes that the developers have worked on similar systems in the past and are experts in the application domain (artillery fire control systems). To follow the home improvement example, after a visit to a home to get specifications, an experience flooring contractor could install new hardwood floors with only one trip to the hardware store. In this case, the risk of project failure is low.

Spiral Model



In response to the weaknesses and failures of the Waterfall SDLC Model, many new models were developed that add some form of iteration to the software development process. In the Spiral SDLC Model, the development team starts with a small set of requirements and goes through each development phase (except Installation and Maintenance) for those set of requirements. Based on lesson learned from the initial iteration (via a risk analysis process), the development team adds functionality for additional requirements in ever-increasing "spirals" until the application is ready for the Installation and Maintenance phase (production). Each of the iterations prior to the production version is a prototype of the application.

The advantage of the Spiral Model over the Waterfall Model is that the iterative approach allows development to begin even when all the system requirements are not known or understood by the development team. As each prototype is tested, user feedback is used to make sure the project is on track. The risk analysis step provides a formal method to ensure the project stays on track even if requirements do change. If new techniques or business requirements make the project unnecessary, it can be canceled before too many resources are wasted. In today's business environment, the Spiral Model (or its other iterative model cousins) is the most used SDLC model. An example application development project that would a good candidate for the Spiral Model is an online customer support system where it is not well-understood what services customers want or can accomplish online. Each iterative prototype helps answer the question, "Can and will customers use this system?" The Spiral Model also lets the development team build application domain experience with every iteration. In the home improvement project example, it would be like starting the hardwood flooring project in the upstairs hall to get experience with the flooring process in a low-risk area before moving to living areas where a mistake would be costly.

The Spiral Model combines elements of the Top-down and Bottom-up SDLC models that are discussed in the next sections.

Top-Down Model

The Top-down SDLC model was popularized by IBM in the 1970s, and its concepts are used in other SDLC models such as the Waterfall and Spiral Models previously discussed. In a pure Top-down model, high-level requirements are documented, and programs are built to meet these requirements. Then, the next level is designed and built. A good way to picture the Top-down model is to think of a menu-driven application. The top level menu items would be designed and coded, and then each sublevel would be added after the top level was finished. Each menu item represents a subsystem of the total application.

The Top-down model is a good fit when the application is a new one and there is no existing functionality that can be incorporated into the new system. A major problem with the Top-down model is that real system functionality is not added and cannot be tested until late in the development process. If problems are not detected early in the project, they can be costly to remedy later.

Bottom-Up Model

In the Bottom-up SDLC model, the lowest level of functionality is designed and programmed first, and finally all the pieces are integrated together into the finished application. This means that, generally, the most complex components are developed and tested first. The idea is that any project show-stoppers will surface early in the project. The Bottom-up model also encourages the development and use of reusable software components that can be used multiple times across many software development projects. Again, think of a menu driven system where the development starts with the lowest level menu items.



The disadvantage of the Bottom-up model is that an extreme amount of coordination is required to be sure that the individual software components work together correctly in the finished system. Few systems are developed purely from the Bottom-up model.

Hybrid Model

The Hybrid SDLC model combines the top-down and bottom-up models. Using the menu driven application example, the design team primarily works top down, but the development team identifies two types of lower level components to work on at the same time as the high-level components. The first type of low-level component would be existing software modules from other projects that can be reused in the new project. The other type of low-level component that would be developed early in the project would be software components with a high risk of failure. This approach allows the development team to make changes to the system early in the project if problems occur with the high-risk components. A new data access technique the team has not used before or a component that might require high amounts of CPU processing time is an example of a high-risk low-level component.

In reality, many of the SDLC models are a variation of the Hybrid Model. The Spiral Model is an example discussed previously.

Rapid Prototyping

With the demand for faster software development, and because of many well-documented failures of traditional SDLC models, Rapid Application Development (RAD) was introduced as a better way to add functionality to an application. The main new tenant of RAD compared to older SDLC models is the use of prototypes. After a quick requirements gathering phase, a prototype application is built and presented to the application users. Feedback from the user provides a loop to improve or add functionality to the application. Early RAD models did not involve the use of real data in the prototype, but new RAD implementations do use real data.

The advantage of Rapid Prototyping Models is that time-to-market is greatly reduced. Rapid Prototyping skips many of the steps in traditional SDLC models in favor of fast and low-cost software development. The idea is that application software is a "throw-away." If a new version of the software is needed, it is developed from scratch using the newest RAD techniques and tools.

The big disadvantage of the Rapid Prototyping Model is that the process can be to fast, and, therefore, proper testing (especially security testing) may not be done.

The Rapid Prototyping Model is used for graphical user interface (GUI) applications such as web-based applications. Extreme Programming (XP) is a modern incarnation of the Rapid Prototyping Model.

Object-Oriented Model

Object-oriented programming became popular 1990s with the increased use of Smalltalk, C++, and other new object-oriented programming languages. To take full advantage of object-oriented features (i.e. classes, inheritance, methods), the Object-oriented SDLC model was developed.

An important feature of Object-oriented (OO) systems is that software objects represent real-world objects. Objects are derived from Classes, and a class hierarchy allows objects to inherit characteristics from parent classes. This allows software object reuse, less coding,



encapsulation of functionality, and many other advantages. A major problem that arose with OO programming is that if the Class hierarchy is not properly designed, all the OO advantages disappear. The object-oriented model attempts to properly define and document the Class hierarchy from which all the system objects are created and object interactions are defined.

For example, in an accounts payable system for GIAC Bikes, GIAC Bikes is an Object. Spacely Space Sprockets is another Object (of class Supplier). Supplier is a Relationship between GIAC Bikes and Spacely Space Sprockets. A Supplier Class has Attributes such as Name, Address, and so on. The Relationship itself may be considered as an Object, having Attributes like Prime Supplier, and so forth. A Supplier Method may be Pay, Drop, Request Refund, and such.

Defining all the application Classes, Methods, Relationships, and Properties is very difficult. The object-oriented SDLC model provides the development team the tools to accomplish this task.

The object-oriented SDLC model has these phases that roughly correspond to the traditional SDLC phases noted in brackets:

1. Object-Oriented Requirements Analysis (OORA) [Design Analysis]: This is where classes of objects and the interaction between them are defined.

2. Object-Oriented Analysis (OOA) [Design Analysis]: In terms of object-oriented concepts, understanding, and modeling a particular problem within a problem domain.

3. Object-Oriented Design (OOD) [System Design Specification]: The object is the basic unit of modularity; objects are instantiations of a class.

4. Object-Oriented Programming (OOP) [Programming and Testing]: Emphasizes the employment of objects and methods rather than types or transformations, as in other programming approaches.

The Object-oriented SDLC model is characterized by its attempt to model real-world entities (such as company, account, employee) into abstract computer software objects and all the interactions that can take place between those objects.

Other Models

Other SDLC models include Model Driven Development, Chaos Model, Agile Programming Model, and many others. One significant trend in the development of new SDLC models is the integration of software design tools into the programming environment (such as Microsoft Visual Studio, IBM Rational Rose). The design team develops a graphical model of the system, and the tool automatically creates a running application.

Summary

SDLC models are tools that allow the development team to correctly follow the SDLC steps to create software that meets a business need. The SDLC models have evolved as new technology and new research have addressed weaknesses of older models. Ideas have been borrowed and adapted between the various models. The CISSP student should recognize the main SDLC model families of sequential (Waterfall), iterative (Spiral), rapid prototyping (RAD), and object-oriented. The student should recognize the characteristics of top-down and bottom-up development.

It is the responsibility of the CISSP to make sure development teams follows an SDLC model so that proper confidentiality, integrity, and availability controls are designed and built into the software application throughout the software life cycle.



The Distributed Agile Model

Since proponents of Agile processes prefer face-to-face conversation as the means for

communication within a development team, in the “distributed Agile model” – in which

members of an Agile team are situated in more than one workplace -- this may seem unlikely.

But Agile processes are not rule-bound; rather, they optimize for methods and dynamics by

which organizations are able to build, maintain, and apply systems of knowledge within

changeful, context-dependent, collaborative work situations.

So when we evaluate the viability of distributed Agile (DA), our concern is not whether it

complies with a particular definition of Agile, but whether it can support iterative, incremental,

and sustainable development; promote teamwork; promote self-management; adapt readily

to emergent changed requirements; and increase customer participation in the development

process. Based on my experience I would say DA is, in this sense, viable. But special measures

must be taken, especially in the area of communication. I will briefly describe those measures

in this paper.

First, though, it may be helpful to state some background. We worked with organizations who,

following their companies’ recommendation or mandate, had adopted Agile project

management, but also wanted to outsource their testing. We worked with start-ups who were

committed to Agile models for development and wanted to outsource within that model

because they had seen such extraordinary improvements in productivity and code stability.

We also worked with companies who were trying out whatever they thought might work better

than the cause of their current headache. I wish I could say that, for developing a website

using AJAX, for example, you do or you do not want to attempt DA. Or that if you are working

on the first release of a new product, you should stick to single-sited Agile. In fact there is very

little correlation between the type of project and the success or failure of DA. Failure is almost

certain, however, if team members do not understand that Agile is not about freedom from

documentation, or freedom from process (although it very well may be free from these), but is

about producing working software at short intervals using iterative processes that adapt to

emergent conditions without losing their purpose.

Some varieties of testing are a very good fit for DA, such as running full regression suites on

the most recent known-good build, performance testing, automation development, and end-

to-end testing. The home group (that is, the group that owns contact with company

management) works side-by-side with the developers, perhaps reviewing acceptance tests

and designing test cases that expand upon tests developed in test-driven development, and

the remote group covers non-functional testing.

One of the best fits for DA has been a sort of cluster of remote Scrums, where the home group

drives development of the core engine, while a remote group is spawned whenever an

adapter or significant new feature is required -- each remote group communicating closely

with one member of the home group who attends daily standups etc. I don’t recommend



trying this without doing due diligence; but it is useful to know that DA does work in a variety

of situations.

Here are a number of practices; I would not want to call them “best practices” because I am

certain they can be improved upon. Their strongest recommendation is that they have

consistently worked in a variety of projects deployed in a DA model.

Making Distributed Agile Work for you

Keep an inclusive test plan Even in straightforward Scrum, a backlog or schedule or

even a set of cards on the wall reminds everyone what tasks the team owns, i.e. must

accomplish in the current sprint (or series of sprints). This is of even greater

importance for DA; if there are multiple remote groups, while the “Scrum of Scrums”

structure is useful, it is not sufficient – the remote group will need something to refer to

in case the home group is unavailable.

Keep the customer engaged with both remote and home groups throughout

the project The temptation is to maintain contact with the remote group only, but

that would damage the remote group’s sense of belonging to a team, which is the

basis for communication. The customer should at least participate in conference calls.

Coordinate by “Scrum of Scrums” Represent each remote group in home group

through participation by one home group member who is in daily telephone contact (if

personal contact is impossible) with the remote group. Participation of remote groups

by conference call alone provides much weaker linkage.

Exchange remote and home group members within the team Ideally, remote

group members visit the home group for several days, and home group members visit

remote groups. Even if only one person from the home group visits a remote group for

a week or two, all members of both groups will tend to bond. This is especially useful if

the two groups are from markedly disparate cultures.

Communication protocol Since decisions regarding adoption of communication and

reporting protocols have a much greater impact in DA than in single-site Agile, they

should be discussed as part of pre-sprint planning, and any required hardware or

software resources obtained well in advance of sprint kick-off.

Defect management For large-scale projects using multiple Agile teams, while each

team tracks defects and their resolution during the sprint using a backlog or

programmatic equivalent (e.g. Rally), at the end of the sprint all fixed, resolved and

unresolved bugs should be moved into a defect database (e.g. Bugzilla) that tracks all

bugs across the project/product so that there are no loose ends. For example, from the

remote group handling regressions; and so that trending can be identified across

multiple groups and teams. While it is tempting for the remote group to enter all bugs

into the master defect database during the sprint, that defeats the task-based focus of

Agile.

Staff assessment Since every project has different resource needs, ensure that team

members have the needed skill-sets and experience. The team that put together



version 1.0 may not have what is needed for the features planned for 1.1. Somehow

remote groups are especially prone to issues of “inheritance”, where resource

qualifications are not re-assessed on a sprint-by-sprint basis.

Trust and feedback Because DA reduces communication bandwidth,

misunderstandings are rampant. Trust is critical to success. Trust enables the

exchange of constructive feedback and criticism. Establishing common non-work

interests helps a lot. The best social glue I have seen was when members of both the

home and remote groups followed World Soccer championships.

Access to resources Give everyone equal access to the same resources. Wikis are

helpful because their topic hierarchy can be changed on the fly,links can be shared

instantly, etc.

Avoiding process inheritance Because more process is required by DA to keep

home and remote groups in synch, processes are likely to be carried over from one

project to another. They will lose their “appropriate process for the project” attributes,

adding unnecessary baggage. While keeping everyone on the same page, it doesn’t

hurt to maintain a healthy skepticism for all process, verifying its need before adopting

it.

Documenting test results Although working code is an indicator of some degree of

accomplishment, it is never a replacement for documentation necessary to record what

tests have been completed, such as non-functional testing by the remote group in

areas like security and compliance.

Looping business analysts in to specify documentation Agile has a tendency to

reduce documentation to zero. Do not assume that the Agile team manager or the

team itself are capable of deciding how much documentation is required -- bring

business stakeholders into the pre-sprint discussion.

If a team realizes benefits in cost and quality while using Agile, it should not assume that

every aspect of Agile is responsible for its success. The key may be iterations alone, as

seemed to be the case in NASA’s Project Mercury. Success may have been due merely to

keeping management out of the picture while coding.

DA requires a little more coordination, regulation, and scheduling -- in other words a little

more discipline. Unless an Agile team is composed entirely of bright, experienced, self-

managing, team-supporting multiple-domain experts, you’ll need some degree of discipline

even if everyone sits around the same table for the entire sprint. DA is the same; but more so.

ii. Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.

There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks. Each iteration is an entire software project:


http://en.wikipedia.org/wiki/Software_engineering


including planning, requirements analysis, design, coding, testing, and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.

Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office sometimes referred to as a bullpen. At a minimum, this includes programmers and their "customers" (customers define the product; they may be product managers, business analysts, or the clients). The office may include testers, interaction designers, technical writers, and managers.

Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined.


http://en.wikipedia.org/wiki/Technical_writer

http://en.wikipedia.org/wiki/Bullpen

http://en.wikipedia.org/wiki/Software_testing

http://en.wikipedia.org/wiki/Requirements_analysis

manual sdlc models i

Documents