Agile Software Development

Module – 5

Agile Software Development

5.1 Coping with Change:-

• Change is inevitable in all large software projects. The system requirements change as
the business procuring the system responds to external pressures and management
priorities change.
• Change adds to the costs of software development because it means that work that has
been completed has to be redone. This is called rework.

• There are two related approaches used to reduce the costs of rework:
1. Change avoidance:- where the software process includes activities that can anticipate
possible changes before significant rework is required. For example, a prototype system
may be developed to show some key features of the system to customers.
2. Change tolerance:- where the process is designed so that changes can be
accommodated at relatively low cost. This involves some form of incremental
development. Proposed changes may be implemented in increments that have not yet
been developed.

• There are 2 ways of coping with change and changing system requirements.
1. System prototyping: - where a version of the system or part of the system is
developed quickly to check the customer’s requirements and the feasibility of some
design decisions.
• This supports change avoidance as it allows users to experiment with the
system before delivery and so refine their requirements.
• The number of requirements change proposals made after delivery is likely to
be reduced.
2. Incremental delivery:- where system increments are delivered to the customer for
comment and experimentation.
• This supports both change avoidance and change tolerance.
• It avoids the premature commitment to requirements for the whole system and
allows changes to be incorporated into later increments at relatively low cost.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 1

 Agile Software Development

5.1.1 Prototyping:-
• A prototype is an initial version of a software system that is used to demonstrate
concepts, try out design options, and find out more about the problem and its possible
solutions.
• A software prototype can be used in a software development process to help anticipate
changes that may be required:
1. In the requirements engineering process, a prototype can help with the
elicitation and validation of system requirements.
2. In the system design process, a prototype can be used to explore particular
software solutions and to support user interface design.
• A process model for prototype development is shown in Figure 5.1 below.

Stage 1:
1. The objectives of prototyping should be made explicit from the start of the
process.
2. These may be to develop a system to prototype the user interface, to develop a
system to validate functional system requirements, or to develop a system to
demonstrate the feasibility of the application to managers.
3. The same prototype cannot meet all objectives. If the objectives are left unstated,
management or end-users may misunderstand the function of the prototype.
Stage 2:
1. The next stage in the process is to decide what to put into and what to leave out
of the prototype system.
2. To reduce prototyping costs and accelerate the delivery schedule, we may leave
some functionality out of the prototype.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 2

 Agile Software Development

Example: To relax non-functional requirements such as response time and

memory utilization. Error handling and management may be ignored unless the
objective of the prototype is to establish a user interface.
Stage 3:
1. The final stage of the process is prototype evaluation. Provision must be made
during this stage for user training and the prototype objectives should be used
to derive a plan for evaluation.
2. Users need time to become comfortable with a new system and to settle into a
normal pattern of usage. Once they are using the system normally, they then
discover requirements errors and omissions.

Advantages:
1. Improved system usability.
2. A closer match to users’ real needs.
3. Improved design quality.
4. Improved maintainability.
5. Reduced development effort.

Disadvantages:
1. The prototype may not necessarily be used in the same way as the final system.
2. The tester of the prototype may not be typical of system users. The training time
during prototype evaluation may be insufficient.

Throw-away prototypes:-
Prototypes should be discarded after development as they are not a good basis for a
production system:
1. It may be impossible to tune the prototype to meet non-functional requirements,
such as performance, security, robustness, and reliability requirements, which
were ignored during prototype development.
2. Rapid change during development inevitably means that the prototype is
undocumented. The only design specification is the prototype code and is not
good enough for long-term maintenance.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 3

 Agile Software Development

3. The changes made during prototype development will probably have degraded
the system structure. The system will be difficult and expensive to maintain.
4. Organizational quality standards are normally relaxed for prototype development.

5.1.2 Incremental Delivery:-

• Incremental delivery (Figure 2.10) is an approach to software development where some

of the developed increments are delivered to the customer and deployed for use in an
operational environment.
• In an incremental delivery process, customers identify, in outline, the services to be
provided by the system.
• The allocation of services to increments depends on the service priority, with the highest-
priority services implemented and delivered first.
• The requirements for the services to be delivered in the first increment are defined in
detail and that increment is developed. During development, further requirements analysis
for later increments can take place but requirements changes for the current increment
are not accepted.
• Once an increment is completed and delivered, customers can put it into service.

Advantages:

1. Customers can use the early increments as prototypes and gain experience that informs
their requirements for later system increments.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 4

 Agile Software Development

2. Customers do not have to wait until the entire system is delivered before they can gain
value from it. The first increment satisfies their most critical requirements so they can use the
software immediately.
3. It is relatively easy to incorporate changes into the system.
4. As the highest-priority services are delivered first and increments then integrated, the most
important system services receive the most testing. This means that customers are less
likely to encounter software failures in the most important parts of the system.

Disadvantages:

1. Most systems require a set of basic facilities that are used by different parts of the system.
As requirements are not defined in detail until an increment is to be implemented, it
can be hard to identify common facilities that are needed by all increments.
2. Iterative development can also be difficult when a replacement system is being
developed. Users want all of the functionality of the old system and are often unwilling to
experiment with an incomplete new system. Therefore, getting useful customer
feedback is difficult.
3. The essence of iterative processes is that the specification is developed in conjunction
with the software. In the incremental approach, there is no complete system
specification until the final increment is specified. This requires a new form of contract,
which large customers such as government agencies may find difficult to accommodate.

5.2 Agile Methods and Agile Manifesto:-

• Dissatisfaction with the overheads involved in software design methods of the 1980s and
1990s led to the creation of agile methods. These methods:
▪ Focus on the code rather than the design
▪ Are intended to deliver working software quickly and evolve this quickly to meet
changing requirements.
• The aim of agile methods is to reduce overheads in the software process (e.g. by
limiting documentation) and to be able to respond quickly to changing requirements
without excessive rework.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 5

 Agile Software Development

Agile Manifesto:-
• We are uncovering better ways of developing 
 software by doing it and helping others

do it. 
 Through this work we have come to value:

▪ Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
• That is, while there is value in the items on 
 the right, we value the items on the left

more.

Principles of Agile Methods:-

Problems with Agile Methods:-

• It can be difficult to keep the interest of customers who are involved in the process.
• Team members may be unsuited to the intense involvement that characterizes agile
methods.
• Prioritizing changes can be difficult where there are multiple stakeholders.
• Maintaining simplicity requires extra work.
• Contracts may be a problem as with other approaches to iterative development.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 6

 Agile Software Development

5.3 Plan-driven and agile development

• Plan-driven development
▪ A plan-driven approach to software engineering is based around separate
development stages with the outputs to be produced at each of these stages
planned in advance.
▪ Not necessarily waterfall model – plan-driven, incremental development is
possible
▪ Iteration occurs within activities.
• Agile development
▪ Specification, design, implementation and testing are inter-leaved and the
outputs from the development process are decided through a process of
negotiation during the software development process.

The Figure below shows the distinctions between plan-driven and agile approaches to system
specification.

Technical, human, organizational issues:-

1. Is it important to have a very detailed specification and design before moving to

implementation?

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 7

 Agile Software Development

If so, you probably need to use a plan-driven approach.

2. Is an incremental delivery strategy, where you deliver the software to customers
and get rapid feedback from them, realistic?
If so, consider using agile methods.

3. How large is the system that is being developed?

Agile methods are most effective when the system can be developed with a small co-
located team who can communicate informally. This may not be possible for large systems
that require larger development teams so a plan-driven approach may have to be used.

4. What type of system is being developed?

Plan-driven approaches may be required for systems that require a lot of analysis
before implementation (e.g. real-time system with complex timing requirements).

5. What is the expected system lifetime?

Long-lifetime systems may require more design documentation to communicate the
original intentions of the system developers to the support team.

6. What technologies are available to support system development?

Agile methods rely on good tools to keep track of an evolving design

7. How is the development team organized?

If the development team is distributed or if part of the development is being
outsourced, then you may need to develop design documents to communicate across the
development teams.

8. Are there cultural or organizational issues that may affect the system
development?
Traditional engineering organizations have a culture of plan-based development, as
this is the norm in engineering.

9. How good are the designers and programmers in the development team?
It is sometimes argued that agile methods require higher skill levels than plan-based
approaches in which programmers simply translate a detailed design into code

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 8

 Agile Software Development

10. Is the system subject to external regulation?

If a system has to be approved by an external regulator (e.g. the FAA approve
software that is critical to the operation of an aircraft) then you will probably be required to
produce detailed documentation as part of the system safety case.

5.4 Extreme Programming

• Extreme programming (XP) is perhaps the best known and most widely used of the
agile methods.
• The name was coined by Beck (2000) because the approach was developed by pushing
recognized good practice, such as iterative development, to ‘extreme’ levels.
• For example, in XP, several new versions of a system may be developed by different
programmers, integrated and tested in a day.

Working:-
• In extreme programming, requirements are expressed as scenarios (called user
stories), which are implemented directly as a series of tasks.
• Programmers work in pairs and develop tests for each task before writing the code. All
tests must be successfully executed when new code is integrated into the system. There
is a short time gap between releases of the system.
• Figure 3.3 illustrates the XP process to produce an increment of the system that is being
developed.

Figure 3.3: The extreme programming release cycle

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 9

 Agile Software Development

Extreme Programming Principles/Practices:-

Figure 3.4: Extreme Programming Practices

Extreme programming involves a number of practices which reflect the principles of

agile methods:
• Incremental development is supported through small, frequent releases of the system.
Requirements are based on simple customer stories or scenarios that are used as a basis
for deciding what functionality should be included in a system increment.
• Customer involvement is supported through the continuous engagement of the
customer in the development team.
• People, not process, are supported through pair programming, collective ownership of
the system code, and a sustainable development process that does not involve
excessively long working hours.
• Change is embraced through regular system releases to customers, test-first
development, refactoring to avoid code degeneration, and continuous integration of new
functionality.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 10

 Agile Software Development

• Maintaining simplicity is supported by constant refactoring that improves code

quality and by using simple designs that do not unnecessarily anticipate future changes
to the system.

Story cards:-
• In an XP process, customers are intimately involved in specifying and prioritizing
system requirements. The system customer is part of the development team and
discusses scenarios with other team members.
• Together, they develop a ‘story card’ that encapsulates the customer needs. The
development team then aims to implement that scenario in a future release of the
software.
• An example of a story card for the mental health care patient management system is
shown in Figure 3.5. This is a short description of a scenario for prescribing
medication for a patient.

Figure 3.5: A prescribing medication story

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 11

 Agile Software Development

• The story cards are the main inputs to the XP planning process or the ‘planning
game’.
• Once the story cards have been developed, the development team breaks these down
into tasks (Figure 3.6) and estimates the effort and resources required for
implementing each task. This usually involves discussions with the customer to
refine the requirements. The customer then prioritizes the stories for implementation,
choosing those stories that can be used immediately to deliver useful business
support.

Figure 3.6: Examples of task cards for prescribing medication

Refactoring
• Programming team looks for possible software improvements and makes these
improvements even where there is no immediate need for them.
• This improves the understandability of the software and so reduces the need for
documentation.
• Changes are easier to make because the code is well-structured and clear.
• However, some changes require architecture refactoring and this is much more
expensive.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 12

 Agile Software Development

Examples of Refactoring
• Re-organization of a class hierarchy to remove duplicate code.
• Tidying up and renaming attributes and methods to make them easier to understand.
• The replacement of inline code with calls to methods that have been included in a
program library.

5.4.1Testing in XP

• Testing is central to XP and XP has developed an approach where the program is

tested after every change has been made.

• The key features of testing in XP are:

1. Test-first development,
2. Incremental test development from scenarios,
3. User involvement in the test development and validation, and
4. The use of automated testing frameworks.

Test-first development: -
• It is one of the most important innovations in XP.
• Instead of writing some code and then writing tests for that code, you write the tests
before you write the code. This means that you can run the test as the code is being
written and discover problems during development.
• This approach can be adopted in any process in which there is a clear relationship
between a system requirement and the code implementing that requirement.
• The story cards representing the requirements are broken down into tasks and the tasks
are the principal unit of implementation.
• It also avoids the problem of ‘test-lag’. This may happen when the developer of the
system works at a faster pace than the tester. The implementation gets further and
further ahead of the testing and there is a tendency to skip tests, so that the development
schedule can be maintained.
• Figure 3.7 is a shortened description of a test case that has been developed to check that
the prescribed dose of a drug does not fall outside known safe limits.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 13

 Agile Software Development

Figure 3.7: Test case description for dose checking

• The role of the customer in the testing process is to help develop acceptance tests for
the stories that are to be implemented in the next release of the system.
• For the story in Figure 3.5, the acceptance test would involve scenarios where
o (a) the dose of a drug was changed,
(b) a new drug was selected, and
(c) the formulary was used to find a drug.
• Test automation :- is essential for test-first development. Tests are written as
executable components before the task is implemented. These testing components
should be standalone, should simulate the submission of input to be tested, and should
check that the result meets the output specification.
• An automated test framework is a system that makes it easy to write executable tests
and submit a set of tests for execution.
• Junit (Massol and Husted, 2003) is a widely used example of an automated testing
framework.

• XP Testing difficulties:-

1. Programmers prefer programming to testing and sometimes they take short cuts
when writing tests. For example, they may write incomplete tests that do not check for all
possible exceptions that may occur.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 14

 Agile Software Development

2. Some tests can be very difficult to write incrementally. For example, in a complex user
interface, it is often difficult to write unit tests for the code that implements the ‘display
logic’ and workflow between screens.
3. It difficult to judge the completeness of a set of tests. Although you may have a lot of
systems tests, your test set may not provide complete coverage.

5.4.2Pair Programming
• In pair programming, programmers sit together at the same workstation to develop the
software.
• Pairs are created dynamically so that all team members work with each other during the
development process.
• The sharing of knowledge that happens during pair programming is very important as it
reduces the overall risks to a project when team members leave.

Advantages:
1. It supports the idea of collective ownership and responsibility for the system. This
reflects Weinberg’s (1971) idea of egoless programming where the software is
owned by the team as a whole and individuals are not held responsible for problems
with the code. Instead, the team has collective responsibility for resolving these
problems.
2. It acts as an informal review process because each line of code is looked at by at least
two people. Code inspections and reviews are very successful in discovering a high
percentage of software errors. However, they are time consuming to organize and,
typically, introduce delays into the development process. It is a much cheaper
inspection process than formal program inspections.
3. It helps support refactoring, which is a process of software improvement.

5.5 Agile Project management

• The standard approach to project management is plan-driven. Managers draw up a plan
for the project showing what should be delivered, when it should be delivered and who
will work on the development of the project deliverables.
• Agile project management requires a different approach, which is adapted to incremental
development and the particular strengths of agile methods.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 15

 Agile Software Development

• The Scrum approach (Schwaber, 2004; Schwaber and Beedle, 2001) is a general agile
method. Figure 3.8 is a diagram of the Scrum management process.

• There are three phases in Scrum.

1. An outline planning phase: - The general objectives for the project are established
and the software architecture is designed.
2. Sprint cycles:-where each cycle develops an increment of the system.
3. The project closure phase:- wraps up the project, completes required
documentation such as system help frames and user manuals, and assesses the
lessons learned from the project.
• The innovative feature of Scrum is its central phase, namely the sprint cycles. A Scrum
sprint is a planning unit in which the work to be done is assessed, features are selected for
development, and the software is implemented. At the end of a sprint, the completed
functionality is delivered to stakeholders.

• Key characteristics of this process are as follows:

1. Sprints are fixed length, normally 2–4 weeks. They correspond to the development
of a release of the system in XP.
2. The starting point for planning is the product backlog, which is the list of work to
be done on the project. During the assessment phase of the sprint, this is reviewed,
and priorities and risks are assigned. The customer is closely involved in this
process and can introduce new requirements or tasks at the beginning of each
sprint.
3. The selection phase involves all of the project team who work with the customer to
select the features and functionality to be developed during the sprint.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 16

 Agile Software Development

4. Once these are agreed, the team organizes themselves to develop the software.
Short daily meetings involving all team members are held to review progress and if
necessary, reprioritize work. The role of the Scrum master is to protect the
development team from external distractions.
5. At the end of the sprint, the work done is reviewed and presented to stakeholders.
The next sprint cycle then begins.
6. ‘Scrum master’ is a facilitator who arranges daily meetings, tracks the backlog of
work to be done, records decisions, measures progress against the backlog, and
communicates with customers and management outside of the team.
7. The whole team attends the daily meetings, which are sometimes ‘stand-up’
meetings to keep them short and focused. During the meeting, all team members
share information, describe their progress since the last meeting, problems that
have arisen, and what is planned for the following day. This means that everyone
on the team knows what is going on and, if problems arise, can replan short-term
work to cope with them.

Advantages of SCRUM:-

1. The product is broken down into a set of manageable and understandable chunks.
2. Unstable requirements do not hold up progress.
3. The whole team has visibility of everything and consequently team communication is
improved.
4. Customers see on-time delivery of increments and gain feedback on how the product
works.
5. Trust between customers and developers is established and a positive culture is created in
which everyone expects the project to succeed.

5.6 Scaling Agile Methods

• Agile methods are mostly used for the development of small and medium-sized
systems.
• Consequently, there has been a great deal of interest in scaling agile methods to cope
with larger systems, developed by large organizations.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 17

 Agile Software Development

Large software system development is different from small system development in a

number of ways:
1. Large systems are usually collections of separate, communicating systems, where separate
teams develop each system. Frequently, these teams are working in different places,
sometimes in different time zones. It is practically impossible for each team to have a view of
the whole system. Consequently, their priorities are usually to complete their part of the
system without regard for wider systems issues.
2. Large systems are ‘brownfield systems’ (Hopkins and Jenkins, 2008); that is they include
and interact with a number of existing systems. Many of the system requirements are
concerned with this interaction and so don’t really lend themselves to flexibility and
incremental development.
3. Where several systems are integrated to create a system, a significant fraction of the
development is concerned with system configuration rather than original code development.
This is not necessarily compatible with incremental development and frequent system
integration.
4. Large systems and their development processes are often constrained by external rules and
regulations limiting the way that they can be developed, that require certain types of system
documentation to be produced, etc.
5. Large systems have a long procurement and development time. It is difficult to maintain
coherent teams who know about the system over that period as, inevitably, people move on to
other jobs and projects.
6. Large systems usually have a diverse set of stakeholders. For example, nurses and
administrators may be the end-users of a medical system but senior medical staff, hospital
managers, etc. are also stakeholders in the system. It is practically impossible to involve all of
these different stakeholders in the development process.

There are two perspectives on the scaling of agile methods:

1. A ‘scaling up’ perspective, which is concerned with using these methods for developing
large software systems that cannot be developed by a small team.
2. A ‘scaling out’ perspective, which is concerned with how agile methods can be introduced
across a large organization with many years of software development experience.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 18

 Agile Software Development

Agile methods coping with large systems engineering:-

1. For large systems development, it is not possible to focus only on the code of the system.
You need to do more up-front design and system documentation. The software architecture
has to be designed and there has to be documentation produced to describe critical aspects of
the system, such as database schemas, the work breakdown across teams, etc.
2. Cross-team communication mechanisms have to be designed and used. This should involve
regular phone and video conferences between team members and frequent, short electronic
meetings where teams update each other on progress. A range of communication channels
such as e-mail, instant messaging, wikis, and social networking systems should be provided
to facilitate communications.
3. Continuous integration, where the whole system is built every time any developer checks
in a change, is practically impossible when several separate programs have to be integrated to
create the system. However, it is essential to maintain frequent system builds and regular
releases of the system. This may mean that new configuration management tools that support
multi-team software development have to be introduced.

It is difficult to introduce agile methods into large companies for a number of reasons:
1. Project managers who do not have experience of agile methods may be reluctant to accept
the risk of a new approach, as they do not know how this will affect their particular projects.
2. Large organizations often have quality procedures and standards that all projects are
expected to follow and, because of their bureaucratic nature, these are likely to be
incompatible with agile methods. Sometimes, these are supported by software tools (e.g.,
requirements management tools) and the use of these tools is mandated for all projects.
3. Agile methods seem to work best when team members have a relatively high skill level.
However, within large organizations, there are likely to be a wide range of skills and abilities,
and people with lower skill levels may not be effective team members in agile processes.
4. There may be cultural resistance to agile methods, especially in those organizations
that have a long history of using conventional systems engineering processes.

Haseeba Yaseen ,Asst.Prof Dept. of CSE, GAT Page 19