Software Engineering

Task Cards.

Coming up: An Agile Process 2

 Testing in XP
• one of the important differences between
incremental development and plan-driven
development is in the way that the system is
tested.
• With incremental development, there is no system
specification that can be used by an external
testing team to develop system tests.
• As a consequence, some approaches to
incremental development have a very informal
testing process, in comparison with plan-driven
testing.

Coming up: An Agile Process 3

 Testing in XP
• XP emphasizes the importance of program testing.
XP includes an approach to testing that reduces
the chances of introducing undiscovered errors into
the current version of the system.
• 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,
• 4. the use of automated testing frameworks.

Coming up: An Agile Process 4

 Testing in XP
• In XP 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.
• Writing tests implicitly defines both an interface and
a specification of behavior for the functionality
being developed.
• In test-first development, the task implementers
have to thoroughly understand the specification so
that they can write tests for the system. This means
that ambiguities and omissions in the specification
have to be clarified before implementation begins.
Coming up: An Agile Process 5
 Testing in XP
• 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 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.
• Acceptance testing is the process where the
system is tested using customer data to check that
it meets the customer’s real needs.

Coming up: An Agile Process 6

Testing in XP

Coming up: An Agile Process 7

 Testing in XP
• Relying on the customer to support acceptance test
development is sometimes a major difficulty in the
XP testing process.
• The customer may feel that providing the
requirements was enough of a contribution and so
may be reluctant to get involved in the testing
process.

Coming up: An Agile Process 8

 Testing in XP
• 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.

Coming up: An Agile Process 9

 Testing in XP
• Test-first development and automated testing usually
results in a large number of tests being written and
executed.
• However, this approach does not necessarily lead to
thorough program testing. There are three reasons
for this:
• 1. Programmers prefer programming to testing and
sometimes they take shortcuts when writing tests.
• 2. Some tests can be very difficult to write
incrementally.
• 3. It is difficult to judge the completeness of a set of
tests
Coming up: An Agile Process 10
 Pair Programming
• Another innovative practice that has been
introduced in XP is that programmers work in pairs
to develop the software.
• They actually sit together at the same workstation
to develop the software. However, the same pairs
do not always program together. Rather, pairs are
created dynamically so that all team members work
with each other during the development process.

Coming up: An Agile Process 11

 Pair Programming
• The use of pair programming has a number of
advantages:
• It supports the idea of collective ownership and
responsibility for the system.
• It acts as an informal review process because each
line of code is looked by at least two people it is a
much cheaper inspection process than formal
program inspections.
• It helps support refactoring, which is a process of
software improvement.

Coming up: An Agile Process 12

 Pair Programming
• You might think that pair programming would be less
efficient than individual programming.
• In a given time, a pair of developers would produce
half as much code as two individuals working alone
• There have been various studies of the productivity
of pair programmers
• Productivity with pair programming seems to be
comparable with that of two people working
independently.
• The reasons suggested are that pairs discuss the
software before development so probably have fewer
false starts and less rework.
Coming up: An Agile Process 13
 Pair Programming
• Furthermore, the number of errors avoided by the informal
inspection is such that less time is spent repairing bugs
discovered during the testing process.
• However, studies with more experienced programmers did
not replicate these results. They found that there was a
significant loss of productivity compared with two
programmers working alone.
• There were some quality benefits but these did not fully
compensate for the pair-programming overhead.
• 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. In itself, this may
make pair programming worthwhile.

Coming up: An Agile Process 14

 Agile project management
• The principal responsibility of software project
managers is to manage the project so that the
software is delivered on time and within the
planned budget for the project.
• 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.

Coming up: An Agile Process 15

 Agile project management
• However, it does not work well with agile methods
where the requirements are developed incrementally;
where the software is delivered in short, rapid
increments; and where changes to the requirements
and the software are the norm.
• This requires a different approach to project
management, which is adapted to incremental
development and the particular strengths of agile
methods.
• The Scrum approach is a general agile method but its
focus is on managing iterative development rather than
specific technical approaches to agile software
engineering
Coming up: An Agile Process 16
Agile project management

Coming up: An Agile Process 17

 Scrum
• Scrum does not prescribe the use of programming
practices such as pair programming and test-first
development. It can therefore be used with more
technical agile approaches, such as XP, to provide
a management framework for the project.
• There are three phases in Scrum. The first is an
outline planning phase where you establish the
general objectives for the project and design the
software architecture.

Coming up: An Agile Process 18

 Scrum
• This is followed by a series of sprint cycles, where
each cycle develops an increment of the system.
• Finally, 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.

Coming up: An Agile Process 19

 Scrum
• Key characteristics of Scrum are as follows:
• 1. Sprints are fixed length, normally 2–4 weeks.
• 2. The starting point for planning is the list of work to
be done on the project. During the assessment
phase of the sprint, this is reviewed, and priorities,
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.
Coming up: An Agile Process 20
 Scrum
• 4. 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.
• During this stage the team is isolated from the
customer and the organization, with all communications
channeled through the ‘Scrum master’.
• 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.

Coming up: An Agile Process 21