CENG 306
Software Engineering
Week-3
Agile Software Development 1
SYLLABUS
Week 1: Introduction Week 8: Software testing
Week 2: Software processes Week 9: Software evolution
Week 3: Agile software development Week 10: Dependable systems
Week 4: Requirements engineering Week 11: Reliability engineering
Week 5: System modeling Week 12: Safety engineering
Week 6: Architectural design Week 13: Security engineering
Week 7: Design and implementation Week 14: Resilience engineering
MİDTERM FİNAL
2
Objectives
The objective of this chapter is to introduce you to agile software development methods.
When you have read the chapter, you will:
■ understand the rationale for agile software development methods, the agile manifesto, and the differences
between agile and plan-driven development;
■ know about important agile development practices such as user stories, refactoring, pair programming and
test-first development;
■ understand the Scrum approach to agile project management;
■ understand the issues of scaling agile development methods and combining agile approaches with plan-driven
approaches in the development of large software systems.
3
Agile Software Development
Businesses now operate in a global, rapidly changing environment.
They have to respond to new opportunities and markets, changing economic
conditions and the emergence of competing products and services.
Software is part of almost all business operations, so new software has to be
developed quickly to take advantage of new opportunities and to respond to
competitive pressure.
Rapid software development and delivery is therefore the most critical
requirement for most business systems.
Agile Software Development
Plan-driven software development processes are not available to rapid software
development.
As the requirements change the system design or implementation has to be reworked and
retested.
Agile Software Development
As a consequence, a conventional waterfall or specification-based process is usually a
lengthy one, and the final software is delivered to the customer long after it was originally
specified.
Agile Software Development
Therefore, for business systems in particular, development processes
that focus on rapid software development and delivery are essential.
Agile Software Development
Rapid software development became known as agile development or
agile methods.
These agile methods are designed to produce useful software quickly.
Agile Software Development
All of the agile methods that have been proposed share a number of common
characteristics:
İncremental development methods in which the increments are small, and,
typically, new releases of the system are created and made available to
Customers every two or three weeks.
They involve customers in the development process to get rapid feedback
on changing requirements.
They minimize documentation by using informal communications rather
than formal meetings with written documents.
Agile Software Development
• Agile approaches to software development consider
design and implementation to be the central
activities in the software process.
• They incorporate other activities, such as
requirements elicitation and testing, into design and
implementation.
• By contrast, a plan-driven approach to software
engineering identifies separate stages in the software
process with outputs associated with each stage.
• The outputs from one stage are used as a basis for
planning the following process activity.
Agile Methods
In the 1980s and early 1990s, there was a widespread view that:
the best way to achieve better software was through careful project planning,
formalized qualityassurance, use of analysis and design methods supported by
software tools, and controlled and rigorous software development processes.
This view came from the software engineering community that was responsible for
developing large, long-lived software systems such as aerospace and government
systems.
Agile Methods
Plan-driven approaches involve a significant overhead in planning,
designing, and documenting the system.
This overhead is justified when the work of multiple development teams
has to be coordinated, when the system is a critical system, and
whenmany different people will be involved in maintaining the software
over its lifetime.
Dissatisfaction with these heavyweight approaches to software
engineering led to the development of agile methods in the late 1990s.
These methods allowed the development team to focus on the software
itself rather than on its design and documentation.
12
Agile Methods
Agile methods have been particularly successful for two kinds of system
development.
1. Product development where a software company is developing a small or
medium-sized product for sale. Virtually all software products and apps are
now developed using an agile approach.
2. Custom system development within an organization, where there is a clear
commitment from the customer to become involved in the development
process and where there are few external stakeholders and regulations that
affect the software.
Agile Methods
All agile methods suggest that software should be developed and delivered
incrementally.
These methods are based on different agile processes but they share a set of
principles, based on the agile manifesto, and so they have much in common.
Agile development techniques
The ideas underlying agile methods were developed around the same time by a number of different
people in the 1990s.
However, perhaps the most significant approach to changing software development culture was the
development of Extreme Programming (XP).
Extreme Programming (XP)
1. Incremental development is supported through small, frequent releases of the
system.
2. 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.
2. Customer involvement is supported through the continuous engagement of the
customer in the development team. The customer representative takes part in the
development and is responsible for defining acceptance tests for the system.
3. 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.
16
Agile development techniques
4. Change is embraced through regular system releases to customers, test-first
development, refactoring to avoid code degeneration, and continuous integration
of new functionality.
5. 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.
17
Agile Practices of Extreme Programming (XP).
18
Agile Practices of Extreme Programming (XP).
19
Agile Development Practices
User stories
Software requirements always change.
To handle these changes, agile methods do not have a separate
requirements engineering activity.
Rather, they integrate requirements elicitation with development.
To make this easier, the idea of “user stories” was developed where a user
story is a scenario of use that might be experienced by a system user.
As far as possible, the system customer works closely with the
development team and discusses these scenarios with other team
members.
20
Agile Development Practices
User stories
The idea of user stories is a powerful one—people find it much easier to relate
to these stories than to a conventional requirements document or use cases.
User stories can be helpful in getting users involved in suggesting
requirements during an initial predevelopment requirements elicitation
activity.
21
Agile Development Practices
User stories
The principal problem with user stories is completeness.
It is difficult to judge if enough user stories have been developed to cover all
of the essential requirements of a system.
It is also difficult to judge if a single story gives a true picture of an activity.
Experienced users are often so familiar with their work that they leave
things out when describing it.
22
Agile Development Practices
Refactoring
A fundamental precept of traditional software engineering is that you
should design for change.
That is, you should anticipate future changes to the software and design it
so that these changes can be easily implemented.
Extreme programming, however, has discarded this principle on the basis
that designing for change is often wasted effort.
23
Agile Development Practices
Refactoring
Of course, in practice, changes will always have to be made to the code being
developed.
To make these changes easier, the developers of XP suggested that the code
being developed should be constantly refactored.
Refactoring means that the programming team look for possible improvements
to the software and implements them immediately.
When team members see code that can be improved, they make these
improvements even in situations where there is no immediate need for them.
24
Agile Development Practices
Refactoring
A fundamental problem of incremental development is that local changes
tend to degrade the software structure.
Consequently, further changes to the software become harder and harder
to implement.
In principle, when refactoring is part of the development process, the
software should always be easy to understand and change as new
requirements are proposed.
25
Agile Development Practices
Test-first development
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.
26
Agile Development Practices
Test-first development
Extreme Programming developed a new approach to program testing to
address the difficulties of testing without a specification.
Testing is automated and is central to the development process, and
development cannot proceed until all tests have been successfully
executed.
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.
27
Agile Development Practices
Pair programming
Another innovative practice that was introduced in XP is that programmers
work in pairs to develop the software.
The programming pair sits at the same computer to develop the software.
However, the same pair do not always program together.
Rather, pairs are created dynamically so that all team members work with
each other during the development process.
28
Agile Development Practices
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.
Many companies that have adopted agile methods are suspicious of pair
programming and do not use it.
Other companies mix pair and individual programming with an experienced
programmer working with a less experienced colleague when they have
problems.
29
Agile Project Management
In any software business, managers need to know what is going on and
whether or not a project is likely to meet its objectives and deliver the software
on time with the proposed budget.
Plan-driven approaches to software development evolved to meet this need.
Like every other professional software development process, agile
development has to be managed so that the best use is made of the time and
resources available to the team
30
Agile Project Management
To address this issue, the Scrum agile method was developed to provide a
framework for organizing agile projects and, to some extent at least, provide
external visibility of what is going on.
The developers of Scrum wished to make clear that Scrum was not a method
for project management in the conventional sense, so they deliberately
invented new terminology, such as ScrumMaster, which replaced names such
as project manager.
31
Scrum Terminology
32
Scrum Terminology
33
The Scrum software sprint cycle
34
Sorular?
35
