Lecture 3

Agile Software Development

Objectives
The objective of this chapter is to introduce you to agile software development methods.
After this lecture, student 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.

Reference Reading

• Roger. S. Pressman, ―Software Engineering, A Practitioner’s Approach‖, 8th

edition, 2015
• Chapter 5: Agile Development
• Iron Sommerville, ―Software Engineering‖, Global Edition, 10th edition, 2016
• Chapter 3: Agile Software Development
• Rajib Mall, ―Fundamentals of Software Engineering‖, 4th Edition, 2014
• Chapter 2: Software Life Cycle Models

1. Introduction

The agile software development model was proposed in the mid-1990s to overcome the
serious shortcomings of the waterfall model, i.e., difficulties in handling change requests
from customers during product development, and the unreasonably high cost and time that is
incurred while developing customized applications.
The agile model was primarily designed to help a project to adapt to change requests
quickly. Thus, a major aim is to facilitate quick project completion. One characteristic is
its ability to reduce the costs of change through the software process.
But, how is agility achieved in these models? Agility is achieved by fitting the process
to the project, i.e. removing activities that may not be necessary for a specific project. Also,
anything that wastes time and effort is avoided.

- 58 -
1.1 What is agility in the context of software engineering work?
Agility is more than an effective response to change. It encourages team structures and
attitudes that make communication (among team members, between technologists and
business people, between software engineers and their managers) more facile. It emphasizes
rapid delivery of operational software and deemphasizes the importance of intermediate
work products (documentation); it adopts the customer as a part of the development team
and works to eliminate the ―us and them‖ attitude that continues to pervade many software
projects; it recognizes that planning in an uncertain world has its limits and that a project
plan must be flexible.

1.2 Agility and the Cost of Change

In the conventional software development process, the cost of change increases
nonlinearly as a project progresses shown in figure 3.1, solid black curve. Consider the
change requirements such as a modification to the architectural design of the software, the
design and construction of three new components, modifications to another five components,
the design of new tests, and so on. Costs escalate quickly, and the time and cost required to
ensure that the change is made without unintended side effects is nontrivial.
A well-designed agile process can ―flattens‖ the cost of change curve (Figure 3.1,
shaded, solid curve), allowing a software team to accommodate changes late in a software
project without dramatic cost and time impact. But, how does the agile process reduce the
cost and time impact? The agile process uses the incremental delivery. When incremental
delivery is coupled with other agile practices such as continuous unit testing and pair
programming, the cost of making a change is reduced.

Figure 3.1: Change costs as a function of time in development

- 59 -
2. Agile Principles
Since agility is an effective response to change, the agile development process must be
adaptable to manage the changing project and technical conditions. Therefore, the agile
software process must adapt incremental development strategy and produces software
increments (executable prototypes or portions of an operational system) in short time
periods. This iterative approach requires customer feedback on evaluation of software
increment regularly.
To deliver software increment to the customer as rapidly as possible, agile developers
must recognize that requirements will change and work together with customers to get
feedback. An agile team should be a ―self-organizing team‖, i.e., one that can develop well-
structured architectures that lead to solid designs and customer satisfaction. Team members
should involve with motivated individuals, who communicate face-to face and work in an
environment that is conducive to high quality software development. Part of the team is
considered to work with the intent of improving the primary goal, i.e., the working software
that meets customer needs is their primary goal.
A central principle of the agile model is the delivery of a software increment to the
customer after a short period of time. A few other principles that are central to the agile
model are discussed below.

Figure 3.2: The principles of agile methods

3. Agile Development Methods

Agile methods are incremental 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.

- 60 -
 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. The distinctions
between Plan-driven and Agile approaches are shown in figure 3.3.
The Plan-driven 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 with formal documents used to
communicate between stages of the process.

(a) Plan-based

(b) Agile approach

Figure 3.3: Plan-driven and Agile Development

All of the agile methods that have been proposed share a number of common
characteristics:
1. The processes of specification, design and implementation are interleaved. There is
no detailed system specification, and design documentation is minimized or
generated automatically by the programming environment used to implement the
system. The user requirements document is an outline definition of the most
important characteristics of the system.
2. The system is developed in a series of increments. End-users and other system
stakeholders are involved in specifying and evaluating each increment. They may
propose changes to the software and new requirements that should be implemented in
a later version of the system.
3. Extensive tool support is used to support the development process. Tools that may
be used include automated testing tools, tools to support configuration management,
and system integration and tools to automate user interface production.

- 61 -
 Please note that agile model is being used as an umbrella term to refer to a group of
development processes. These processes share certain common characteristics, but do have
certain subtle differences among themselves. A few popular agile SDLC models are the
following:
• Crystal
• Extreme programming (XP)
• Scrum
• Dynamic Systems Development Method ( DSDM)
• Agile Modeling
• Agile Unified Process (AUP)
• Feature-driven development
• Lean Development.

We discussed some popular agile methods in detail later. In Agile practices,

development process supports continual change to new releases of the product or app in
response to new business requirements. Agile methods may be suitable for -

1. Product development where a software company is developing a small or medium-

sized systems and software product for sale.
• Agile methods were developed by small programming teams that could work
together in the same room and communicate informally.
• As the system requirements change, rework is essential and, the specification and
design have to change with the program.

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 rules and regulations that affect the software.

Agile methods may not be suitable for –

1. Stable requirements Project:
• Projects with stable requirements that only few changes will occur.
• Example: The development of mission critical or safety critical systems, the
traditional SDLC models are usually preferred to ensure reliability.

2. Large and complex systems/software development

• Example: systems engineering involves a significant overhead in planning,
designing, and documenting the system which might take up to 10 years from
initial specification to deployment. More time is spent on how the system should
be developed than on program development and testing.

- 62 -
4. Extreme Programming (XP)
Extreme Programming (XP), one of the most widely used approaches to agile software
development and it was proposed by Kent Beck in 1999. XP intended to accept and respond to
changing customer requirements.
Extreme Programming (XP) takes an 'extreme' approach to iterative development:
• New versions may be built several times per day;
• Increments are delivered to customers every 2 weeks;
• All tests must be run for every build and the build is only accepted if tests run successfully.

4.1 The Extreme Programming (XP) Process

Extreme Programming uses an object-oriented approach. XP describes four basic
activities within the software development process.

1) Planning - Listening and understanding the customer

2) Design - Designing, or refactoring, an application framework to reduce unnecessary
dependencies between features and uses virtually no notation and produces few work
products.
3) Coding - Writing the program code using pair programming where two people work
together writing code and testing
4) Testing - Testing the software, regularly and automatically

In XP, 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. To
achieve this, XP use development methodologies such as;

1) Pair programming, with two developers working together

2) Common code standards (documentation, naming conventions, whitespace)
3) An understandable system metaphor, where all classes and functions names should be
understandable.

4.2 The XP Activities

The XP activities includes four main framework activities. Figure 3.4 illustrates the XP
process and its four framework activities. Key XP activities are
(1) Planning
(2) Design
(3) Coding
(4) Testing.

These activities are discussed detail in the following paragraphs.

- 63 -
 Figure 3.4: The Extreme Programming (XP) Process

4.2.1 Planning
• The planning activity begins with listening—a requirements gathering activity that
enables the technical members of the XP team to understand the business context for
the software and to get a broad feel for required output and major features and
functionality.
• Listening leads to the creation of a set of ―stories‖ (also called ―user stories‖) that
describe required output, features, and functionality for software to be built.
• Each story is written by the customer and is placed on an index card. The
customer assigns a value (i.e., a priority) to the story based on the overall business
value of the feature or function.
• For example, in figure 3.5, a user story about a library software can be:
• A library member can issue a book.
• A library member can query about the availability of a book.
• A library member should be able to return a borrowed book.
• The XP team then assesses each story and assigns a cost—measured in
development weeks—to it.
• If the story is estimated to require more than three development weeks, the
customer is asked to split the story into smaller stories and the assignment of value
and cost occurs again.

- 64 -
• It is important to note that new stories can be written at any time.
• Customers and developers work together to decide how to group stories into the
next release (the next software increment) to be developed by the XP team.
• Once a basic commitment (agreement on stories to be included, delivery date, and
other project matters) is made for a release.
• The XP team orders the stories that will be developed in one of three ways:
(1) all stories will be implemented immediately (within a few weeks),
(2) the stories with highest value will be moved up in the schedule and implemented
first,
(3) the riskiest stories will be moved up in the schedule and implemented first.

Figure 3.5: An Index cards for the Library System Stories

• After the first project release (also called a software increment) has been delivered,
the XP team computes project velocity that is the number of customer stories
implemented during the first release. Figure 3.6 shows the software release cycle of
the XP.
• Project velocity can then be used to
(1) help estimate delivery dates and schedule for subsequent releases and
(2) determine whether an over commitment has been made for all stories across the
entire development project.

• As development work proceeds, the customer can add stories, change the value of an
existing story, split stories, or eliminate them.
• The XP team then reconsiders all remaining releases and modifies its plans
accordingly.

- 65 -
 Figure 3.6: The XP software release cycle

4.2.2 Design.
• XP design follows the KIS (keep it simple) principle.
• The design provides implementation guidance for a story as it is written—nothing
less, nothing more using CRC cards.
• CRC (class-responsibility-collaborator) cards identify and organize the object
oriented classes that are relevant to the current software increment.
• CRC cards are the only design work product produced as part of the XP process.
• If a difficult design problem is encountered to the design a story, create an
operational prototype of that portion of the design. Called a spike solution, the
design prototype is implemented and evaluated.
• XP encourages refactoring—a construction technique that is also a design technique.
• Refactoring is the process of changing a software system in such a way that it does
not alter the external behavior of the code yet improves the internal structure. It is a
disciplined way to clean up code [and modify/simplify the internal design] that
minimizes the chances of introducing bugs.
• In essence, when you refactor you are improving the design of the code after it has
been written. The intent of refactoring is to control these modifications by suggesting
small design changes that ―can radically improve the design‖.
• XP design process occurs both before and after coding starts. Refactoring means
that design occurs continuously as the system is constructed.

4.2.3 Coding.
• XP develops a new approach, called test-first development, where you write the
tests before you write the code.
• After stories design work is done, the team does not move to code, but develops a
series of unit tests for each of the stories in the current release (software
increment).

- 66 -
• Once the unit test has been created, the developer is better able to focus on what
must be implemented to pass the test. Nothing extraneous is added (KIS).
• Once the code is complete, it can be unit-tested immediately.
• A key concept during the coding activity is pair programming where two people
work together at one computer workstation to create code for a story.

Test-first development
• Instead of writing code, writing tests for that code that means programmer can run
the test while the code is being written and discover problems during development.
Figure 3.7 shows example test case for the library system ―return book‖ story.
• Unit testing focuses on an individual software component, exercising the
component’s interface, data structures, and functionality in an effort to uncover errors
that are local to the component.
• Writing tests defines both an interface and a specification of behavior for the
functionality being developed. Problems of requirements and interface
misunderstandings are reduced.
• Test-first development requires there to be a clear relationship between system
requirements and the code implementing the corresponding requirements.

Figure 3.7: Example Test case description for library system: ―return book‖

Pair programming in XP
• Two people work together at one computer workstation to create code for a story.
• Provide a mechanism for real-time problem solving and real-time quality
assurance.
• Each person takes on a slightly different role. For example,
• one person might think about the coding details of the design while

- 67 -
 • the other ensures that coding standards that satisfy the unit test to validate
the code against the story.
• The code is then integrated with the work of others

4.2.4 Testing
• In this phase, each story is individually tested with test cases and combines them
with other developed stories and performs the integration test.
• In XP development, the individual unit tests, integration and validation testing of the
system can occur on a daily basis.
• The unit tests should use an automated test framework, e.g. Junit is a system that
makes it easy to write executable tests and submit a set of tests for execution.
• A regression testing strategy is used whenever code is modified (refactoring).
• XP acceptance tests, also called customer tests, are specified by the customer and
focus on overall system features and functionality that are visible and reviewable by
the customer.
• Acceptance tests are derived from user stories.

4.3 How XP Supports Agile Principles

This is how XP supports agile principles:
• Incremental development is supported through small, frequent system releases.
• Customer involvement means full-time customer engagement with the team.
• People not process through pair programming, collective ownership, and a process
that avoids long working hours.
• Change supported through regular system releases.
• Maintaining simplicity through constant refactoring of code.

Figure 3.8 lists the extreme programming (XP) agile practices. In practice, the application
of Extreme Programming practices is more difficult than anticipated. It cannot be readily
integrated with the management practices and culture of most businesses. Therefore,
companies adopting agile methods pick and choose those XP practices that are most
appropriate for their way of working. Sometimes these are incorporated into their own
development processes but, more commonly, they are used in conjunction with a
management focused agile method such as Scrum.

- 68 -
 Figure 3.8: The Extreme Programming (XP) Agile Practices

5. Scrum Process
• Scrum is a very popular agile software development method that was conceived by
Jeff Sutherland and his development team in the early 1990s. Further development on
the Scrum methods was performed by Schwaber and Beedle.
• Scrum emphasizes the use of a set of software process patterns that have proven
effective for projects with tight timelines, changing requirements, and business
criticality.
• It focuses on providing a framework for agile project organization.
• It does not mandate the use of specific development practices such as pair
programming and test-first development.

- 69 -
 • In the scrum model, a project is divided into small parts of work that can be
incrementally developed and delivered over time boxes that are called sprints.
• The development activities within a scrum process include the framework
activities: requirements, analysis, design, evolution, and delivery.
• A set of development activities in scrum process are: Backlog, Sprints, Scrum
meetings.
• Scrum model was intended for use with co-located teams where all team members
could get together every day in stand-up meetings.

5.1 The Scrum Activities

• The Scrum team is a self-organizing interdisciplinary team consisting of a product

owner, a Scrum master, and a small (three to six people) development team.
• The principle Scrum artifacts are the product backlog, the sprint backlog, and the
code increment.
• Development proceeds by breaking the project into a series of incremental prototype
development periods 2 to 4 weeks in length called sprints.
• The overall flow of the Scrum process is illustrated in Figure 3.9. The starting point
for the Scrum sprint cycle is the product backlog. Development iteration, called
Sprints are usually two to four weeks long. At the end of each Sprint, team makes
the scrum meeting.
• The Scrum activities include Backlog, Sprints and Meetings, Scrum Review
Meeting and Sprint Retrospective

Figure 3.9: The Scrum Process

- 70 -
5.1.1 Backlog

• A prioritized list of project requirements or features that provide business value for
the customer.
• A backlog item could be a complete user story or it could simply be an instruction
such as ―Refactor user interface code‖ that if the team decide on the refactoring to be
done.
• Items can be added to the backlog at any time (this is how changes are introduced)
with the approval of the product owner and the consent of the development team.
• The product owner assesses the backlog and updates priorities as required.

5.1.2 Sprints

• The sprint backlog is the subset of product backlog items selected by the product
team to be completed as the code increment during the current active sprint.
• The increment is the union of all product backlog items completed in previous
sprints and all backlog items to be completed in the current sprints.
• The development team creates a plan for delivering a software increment
containing the selected features intended to meet an important goal as negotiated with
the product owner in the current sprint.
• Most sprints are time-boxed to be completed in 3 to 4 weeks (typically 30 days).
• Changes (e.g., backlog work items) are not introduced during the sprint. Hence, the
sprint allows team members to work in a short-term, but stable environment.

5.1.3 Scrum Meetings

• The Scrum master serves as facilitator to all members of the Scrum team. She runs
the daily Scrum meeting and is responsible for removing obstacles identified by
team members during the meeting. She coaches the development team members to
help each other complete sprint tasks when they have time available. She helps the
product owner find techniques for managing the product backlog items and helps
ensure that backlog items are stated in clear and concise terms.
• The daily Scrum meetings are short (typically 15-minute) meetings held daily by
the Scrum team to synchronize team members’ activities and make plans for the
next 24 hours. The Scrum master and the development team always attend the daily
Scrum. Some teams allow the product owner to attend occasionally.
• Three key questions are asked and answered by all team members:
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?

- 71 -
 • Meetings declare sprint backlog items complete or done. When the team considers all
sprint backlog items complete, the team may decide to schedule a demo and review
of the completed increment with the product owner.

5.1.4 Scrum Review Meeting

• The Scrum Review Meeting occurs at the end of the sprint when the development
team has judged the increment complete. The sprint review is often time-boxed as a
4-hour meeting for a 4-week sprint. The Scrum master, the development team, the
product owner, and selected stakeholders attend this review.
• The product owner may accept the increment as complete or not. If it is not accepted,
the product owner and the stakeholders provide feedback to allow a new round of
sprint planning to take place.
• This is the time when new features may be added or removed from the product
backlog. The new features may affect the nature of the increment developed in the
next sprint.

5.1.5 Sprint Retrospective

• Before beginning another sprint planning meeting, the Scrum master will schedule a
3-hour meeting (for a 4-week sprint) with the development team called a sprint
retrospective.
• The Scrum master leads the meeting and encourages the team to improve its
development practices to become more effective for the next sprint.
• During this meeting the team discusses:
o What went well in the sprint
o What could be improved
o What the team will commit to improving in the next sprint
• At the end of this sprint retrospective meeting, the team should have a good idea
about the improvements needed in the next sprint and be ready to plan the increment
at the next sprint planning meeting.

6. Dynamic Systems Development Method

• Dynamic Systems Development Method (DSDM) method is an agile software

development approach that use of incremental prototyping in a controlled project
environment.
• DSDM use an iterative software process in which each iteration follows the
80/20 percent rule. That is, the project focuses on that 80 percent to provide the
most features as quickly as possible. The remaining 20 percent of the features are left
for later releases. In another words, only enough work (80 percent of the most

- 72 -
 features) is required for each increment to facilitate movement to the next
increment. The remaining detail (20 percent of the features) can be completed later
when more business requirements are known or changes have been requested and
accommodated.
• The DSDM life cycle includes the four stages: feasibility study, functional model,
design and build, and implementation.
• The DSDM life cycle begins with a feasibility study (to determine whether the
project is possible) that establishes basic business requirements and constraints and
is followed by a business study (to decide whether the project is worth the
expense) that identifies functional and information requirements. Before the project
can start, identify possible projects, getting executive approval and commitment, and
receiving funding.

Figure 3.10: The DSDM life cycle with four stages

• DSDM then defines three different iterative cycles:

1. Functional model iteration—produces a set of incremental prototypes with
iterative cycle to gather additional requirements by eliciting feedback from users
as they exercise the prototype. (Note: All DSDM prototypes are intended to
evolve into the deliverable application.)
2. Design and build iteration—revisits prototypes built during the functional
model iteration. The design and build iteration occur concurrently.

- 73 -
 3. Implementation—places the latest software increment (an ―operationalized‖
prototype) into the operational environment. It should be noted that
(1) the increment may not be 100 percent complete or
(2) changes may be requested as the increment is put into place.
• In either case, DSDM development work continues by returning to the functional
model iteration activity.
• Figure 3.10 shows the normal flow for the project life cycle phase. The arrows show
the normal sequence of events; although the project can move between any of the
functional model, design and build, and implementation stages if necessary. For
example, if the design and build stage uncovers a fundamental problem, the project
could move back to the functional model stage.

7. Agile Unified Process

• The Agile Unified Process (AUP) is an agile version of the Unified Process (UP)
described in lecture 2, “Iterative Models.”
• AUP adopts a ―serial in the large‖ and ―iterative in the small‖.
• By ―serial in the large,‖ means AUP sequentially follows the normal four phases
of the Unified Process: inception, elaboration, construction, and transition.
• By ―iterative in the small,‖ means that AUP performs each of those phases
iteratively.
• Within each of the activities, the team iterates to achieve agility and to deliver
meaningful software increments to end users as rapidly as possible.

Figure 3.11: All the seven AUP disciplines occur simultaneously in different amounts.

- 74 -
• Each AUP iteration addresses the following activities:
• Modeling. UML representations of the business and problem domains are
created. However, to stay agile, these models should be ―just barely good
enough‖ to allow the team to proceed.
• Implementation. Models are translated into source code (an executable
program).
• Testing. Like XP, the team designs and executes a series of tests to uncover
errors and ensure that the source code meets its requirements.
• Deployment. focuses on the delivery of a software increment and the acquisition
of feedback from end users.
• Configuration and project management. In AUP, it addresses change
management, risk management, and the control of any persistent work products
that are produced by the team. Project management tracks and controls the
progress of the team and coordinates team activities.
• Environment management. Supports the project by making sure the team has
everything it needs such as hardware, software, training, manuals, caffeine, and
administrative support. It coordinates a process infrastructure that includes
standards, tools, and other support technology available to the team.

Figure 3.12: AUP Project Release Schedules

- 75 -
 • One big difference between UP and AUP is that UP is designed to produce a single
release while AUP can produce many agile releases.
• Figure 3.12 shows a possible AUP release schedule. The internal builds are iterations
that aren’t released to the users. Only some of the iterations end in production builds
that are deployed.
• In 2012, Scott Ambler stopped work on AUP in favor of DAD. The Disciplined
Agile Delivery (DAD) decision process framework is a people‐first, learning-
oriented hybrid agile approach to IT solution delivery. It has a risk‐value delivery
life cycle, is goal‐driven, is enterprise aware, and is scalable.”

8. Summary of Agile Methods

There are also dozens (if not hundreds) of other agile methodologies. Some methods
descended from others, and there are even methods built as mashups of other methods. An
agile philosophy for software engineering stresses four key issues:

1. Self-organizing teams that have control over the work they perform,
2. Communication and collaboration between team members and between
practitioners and their customers,
3. A recognition that change represents an opportunity, and
4. An emphasis on rapid delivery of software that satisfies the customer.

Agile process models have been designed to address each of these issues. Agile process
models define their own framework activities and select different points of emphasis. The
reality is that no agile method is perfect for every project. Agile developers work on self-
directed teams and are empowered to create their own process models.

9. Problems with Agile Methods

Agile methods are most appropriate for new software development rather than for
software maintenance.
1. Lack of formal / product documentation
• it leaves scope for confusion and important decisions taken during different
phases can be misinterpreted at later points of time by different team members.
• it becomes difficult to get important project decisions such as design decisions to
be reviewed by external experts.
• when the project completes and the developers disperse, maintenance can
become a problem.
2. Keeping customers involved
• using an agile approach to maintenance is keeping customers involved in the
process.
• Customer representatives are likely to lose interest in the system.
- 76 -
 • Therefore, it is likely that alternative mechanisms, such as change proposals be
adapted.
3. Development team continuity
• Agile methods rely on team members understanding aspects of the system
without having to consult documentation.
• When agile development team is broken up, then this implicit knowledge is lost
and it is difficult for new team members to build up the same understanding of
the system and its components.

***************************************************************************

Exercises

(1) Describe agility (for software projects) in your own words.

(2) Explain the important features of the agile software development model.
(a) Compare the advantages and disadvantages of the agile model with iterative
waterfall and the exploratory programming model.
(b) Is the agile life cycle model suitable for development of embedded software?
Briefly justify your answer.
(3) What are the principles of Agile methods?
(4) Distinguish between a Plan-driven and Agile Development approach.
(5) Briefly explain the agile software development model. What types of software
projects for which the agile model would be suitable and what project for which the
agile model would not be appropriate.
(6) How does the XP method support agile principles?
(7) Describe the XP concepts of refactoring and pair programming in your own words.
(8) Extreme programming expresses user requirements as stories, with each story
written on a card. Discuss the advantages and disadvantages of this approach to
requirements description.
(9) Briefly explain the extreme programming (XP) SDLC model. Identify the key
principles that need to be practiced to the extreme in XP. What is a spike in XP?
Why is it required?
(10) Which life cycle model would you recommend for developing an object-oriented
software? Justify your answer.
(11) What do you understand by pairwise programming? What are its advantages over
traditional programming? Briefly explain the scrum process model. What is a
sprints in scrum? How often scrum meeting are held and who lead the meeting?
(12) Briefly explain the DSDM- dynamic systems development method. What is 80/20
percent rule in DSDM? Identify the iterative cycles in DSDM.

- 77 -
(13) Briefly explain the agile unified process (AUP) model. What is mean by ―serial in
the large‖ and ―iterative in small‖ in AUP? Identify activities in each AUP
iteration?

********************* End of Lecture 3 **************************

The more that you read, the more things you will know.
The more that you learn, the more places you will go.
Dr. Sesus

- 78 -