MODULE 1: OVERVIEW OF

SOFTWARE ENGINEERING
 SOFTWARE
✧ Computer software is the product that software
professionals build and then support over the long term
✧ It encompasses
▪ Programs that execute within a computer of any size and
architecture,
▪ Content that is presented as the computer programs execute, and
▪ Descriptive information in both hard copy and virtual forms that
encompass virtually any electronic media

2
 Nature of Software
✧ Software takes on a dual role.
▪ It is a product, and at the same time, the vehicle for delivering a
product.
▪ As a product,
• It delivers the computing potential embodied by computer hardware
or more broadly, by a network of computers that are accessible by
local hardware
▪ As the vehicle used to deliver the product

3
 Nature of Software
✧ Software acts as the basis for
○ The control of the computer (operating systems),

○ The communication of information (networks), and

○ The creation and control of other programs (software tools

and environments)

✧ Software is not susceptible to the environmental maladies that

cause hardware to wear out.

4
 Failure Curves for Software
▪ In theory, the failure rate curve for software should
take the form of the “idealized curve”
• Undiscovered defects will cause high failure rates early
in the life of a program. However, these are
corrected, and the curve flattens.
▪ The idealized curve is an oversimplification of
actual failure models for software.
▪ However, the implication is clear - software doesn’t
wear out. But it does deteriorate!

5
 Failure Curves for Software
▪ During its life, software will undergo change.
▪ As changes are made, it is likely that errors
will be introduced, causing the failure rate
curve to spike as shown in the “actual curve”
▪ Before the curve can return to the original
steady-state failure rate, another change is
requested, causing the curve to spike again
▪ Slowly, the minimum failure rate level begins
to rise – the software is deteriorating due to
change.
6
 Nature of Software
✧ Another aspect of wear illustrates the difference between
hardware and software.
▪ When a hardware component wears out, it is replaced by a spare
part.
▪ There are no software spare parts.
▪ Every software failure indicates an error in design or in the process
through which design was translated into machine executable code.
▪ Therefore, the software maintenance tasks that accommodate requests for
change involve considerably more complexity than hardware
maintenance
7
 Software Application Domains
✧ Broad categories of computer software
▪ System software
▪ Application software
▪ Engineering/scientific software
▪ Embedded software
▪ Product-line software
▪ Web/Mobile applications
▪ Artificial intelligence software
✧ All the above categories of software present continuing
challenges for software engineers 8
 Software Engineering
✧ Software Engineering
▪ The application of a systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software; That is, the application of engineering to
software.
▪ The study of approaches related to the above process
✧ Software Engineering encompasses
▪ A process,
▪ A collection of methods (practice), and
▪ An array of tools that allow professionals to build high-quality computer software.
✧ Software engineers apply the software engineering process.
9
 Software Engineering
✧ Software Engineering is important because
▪ It enables us to build complex systems in a timely manner and with high quality
▪ It imposes discipline to work that can become quite chaotic
▪ It also allows the people who build computer software to adapt their approach in
a manner that best suits their needs.
✧ Steps in Software Engineering
▪ We build computer software like we build any successful product,
• By applying an agile, adaptable process that leads to a high-quality result, which meets
the needs of the people who will use the product.
• We apply a Software Engineering approach

10
 Software Engineering – Layers

✧ Software engineering is a layered technology.

▪ Any engineering approach (including software engineering) must rest on an
organizational commitment to quality. Total quality management
▪ The foundation for software engineering is the process layer.
• The software engineering process is the glue that holds the technology
layers together and enables rational and timely development of computer
software
11
 Software Engineering – Layers

▪ Software engineering methods

• Provide the technical know-how for building software.
• Methods encompass a broad array of tasks that include communication,
requirements analysis, design modeling, program construction, testing,
and support.
▪ Software engineering tools provide automated or semi-
automated support for the process and the methods
12
Early Approach-1960’s, 1970’s

There were many difficulties in the development of large

software systems during the 1960s and 1970s.

The term “software crisis” dates from that time. The

problems stemmed from an inability to apply the techniques
used to build small software systems to the development of
larger and more complex systems.

The typical way to develop small systems can be described

as “code-and-fix”.

But, there is no way to estimate time-scales or budgets.

There is no assessment of possible risks and design flaws.
Early Approach-1960’s, 1970’s

Recognising these problems, work was carried out

to understand the process of software development
and to transform it into a reliable and rigorous
discipline, like architecture or engineering.

An improved process should produce software that

is correct, reliable, usable and maintainable.

By understanding the process, it should be possible

to plan projects with more accurate predictions of
cost and time, and provide ways of monitoring
intermediate stages of project progress, to be able to
react and re-plan if a project begins to go off budget
or timescale.
● A process was defined as a
collection of work activities,
actions, and tasks that are
performed when some work
product is to be created. Each
of these activities, actions, and
tasks reside within a
framework or model that
defines their relationship with
the process and with one
another.
Software Process Framework

● A generic process framework for software engineering

defines five framework activities—communication,
planning, modeling, construction, and deployment. In
addition, a set of umbrella activities—project tracking
and control, risk management, quality assurance,
configuration management, technical reviews, and
others—are applied throughout the process
 The Software Process
✧ Software Process
▪ The systematic approach that is used in software engineering
▪ The set of activities, actions, and tasks that are performed to create some
work product
• An activity strives to achieve a broad objective
– Example: Communication with stakeholders
– It is applied regardless of the application domain, size of the
project, complexity of the effort, etc.
• An action encompasses a set of tasks that produce a major work product
• A task focuses on a small, but well-defined objective that produces a tangible outcome
– Example: Conducting a unit test

18
 The Software Process
✧ In the context of Software Engineering
▪ A process is not a rigid prescription for how to build computer
software.
▪ It is an adaptable approach that enables the people doing the work
(the software team) to pick and choose the appropriate set of work
actions and tasks

19
 Software Product
✧ Products or deliverables are the outcomes of a process
activity.
▪ For example, the outcome of architectural design (activity) may be
the software architecture model (deliverable)
✧ From the point of view of a software engineer, the work
products are
▪ The programs, documents, and data that are produced as a
consequence of the activities and tasks defined by the process

20
 Software Process – Basic Activities
✧ Four fundamental activities are common to all software
processes
▪ Software Specification
• Customers and engineers define the software that is to be produced and the
constraints on its operation
▪ Software Development
• The software that meets the specification is designed and
programmed for production
▪ Software Validation
• The software is validated to ensure that it does what the customer requires
▪ Software Evolution
• The software is modified to reflect changing customer and market
requirements 21
 Software Process Models
✧ A Software Process Model
▪ Also called as Software Development Life Cycle or SDLC
▪ A simplified representation of a software process
▪ Generic process models: High-level, abstract descriptions of software
processes that can be used to explain different approaches to software
development
• The Waterfall Model
• Incremental Development
• Integration and Configuration

22
 Waterfall Model

▪ In this approach, the fundamental process activities of specification,

development, validation, and evolution are represented as separate process
phases such as requirements specification, software design,
implementation, and testing, and maintenance.
23
 Waterfall Model
✧ Examples of software applications where waterfall model is
appropriate
▪ Embedded Systems
• It is not possible to delay decisions on the software’s functionality until it is
being implemented
▪ Critical Systems
• There is a need for extensive safety and security analysis of the
software specification and design.
• In such systems, the specification and design documents must be complete
so that this analysis is possible
▪ Large Software Systems
• Several companies are involved
• Complete specifications may be needed to allow for the
independent development of different subsystems 24
 Incremental Development

▪ This approach interleaves the activities of specification, development,

and validation.
▪ The system is developed as a series of versions (increments), with each version
adding functionality to the previous version.
25
 Incremental Development
✧ Advantages over the waterfall model
▪ Cost of implementing requirements changes is reduced
▪ It’s easier to get customer feedback on the development work that
has been done
▪ Early delivery and deployment of useful software to the customer is
possible

26
 Incremental Development
✧ Problems & Drawbacks
▪ The process is not visible. It’s not cost effective to produce documents
that reflect every version of the system
▪ System structure tends to degrade as new increments are added
▪ The problems become acute for large, complex, long-lifetime systems,
where different teams develop different parts of the system.
• Large systems need a stable framework or architecture
• Responsibilities of the different teams working on parts of the system need to be
clearly defined with respect to that architecture.
• This has to be planned in advance rather than developed incrementally

27
 Integration and Configuration
Reuse Oriented Software Engineering

▪ This approach relies on the availability of reusable components or systems.

▪ The system development process focuses on configuring these components
for use in a new setting and integrating them into a system.

28
 Reusable Software Components
✧ Three types of software components are frequently
reused
▪ Stand-alone application systems
• Configured for use in a particular environment
▪ Collections of objects
• Developed as a component or as a package to be integrated with a
component framework
▪ Web services
• Developed according to service standards

29
 Evolutionary Software Process Models
✧ Software, like all complex systems, evolves over a period
of time
✧ Business and product requirements often change as development
proceeds, making a straight-line path to an end-product
unrealistic
✧ Evolutionary models are iterative
✧ They are characterized in a manner that enables you to develop
increasingly more complete versions of the software.
30
 Evolutionary Software Process Models
✧ Two common evolutionary process models
▪ Prototype Software Development or Prototyping
▪ The Spiral Model

31
 Prototype Development
✧ Prototype - An early version of a software system
▪ Used to demonstrate concepts, try out design options, and find out
more about the problem and its possible solutions.
▪ Rapid, iterative development of the prototype is essential so that costs
are controlled and system stakeholders can experiment with the
prototype early in the software process

1/17/2023 Dr. Najumudheen E S F, Software Engineering 32

 Prototype Development
✧ A software prototype can be used in a software
development process to help anticipate changes that may
be required -
▪ In the Requirements Engineering process
• Prototype can help with the elicitation and validation of system
requirements.
▪ In the System Design process
• Prototype can be used to explore software solutions and in the
development of a user interface for the system.

33
 Prototype Development
✧ System prototypes
▪ Allow potential users to see how well the system supports their work.
▪ They may get new ideas for requirements and find areas of strength and
weakness in the software.
▪ They may then propose new system requirements
✧ A system prototype
▪ May be used while the system is being designed to carry out design
experiments to check the feasibility of a proposed design.
▪ Example: A database design may be prototyped and tested to check that it
supports efficient data access for the most common user queries
34
 Prototype Development Process
✧ A process model for prototype development

35
 Prototype Development Process
✧ The objectives of prototyping should be made explicit
from the start of the process. These may be
▪ To develop the user interface
▪ To develop a system to validate functional system requirements
▪ To develop a system to demonstrate the application to managers

36
 Prototype Development Process
✧ The next stage in the process is to decide
▪ What to put into and, perhaps more importantly, what to leave out
of the prototype system.
▪ To reduce prototyping costs and accelerate the delivery schedule, you
may leave some functionality out of the prototype
• You may decide 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

37
 Prototype Development Process
✧ The final stage of the process is Prototype Evaluation
▪ Provision must be made during this stage for user training
▪ Prototype objectives should be used to derive a plan for
evaluation

38
 Spiral Model

▪ Using the spiral model, software is

developed in a series of
evolutionary releases
▪ During early iterations, the release might
be a model or prototype
▪ During later iterations, increasingly more
complete versions of the engineered
system are produced

39
 Spiral Model
✧ Each phase in this model is split into four sectors (or quadrants).
✧ In the first quadrant, a few features of the software are identified (based on
its importance to the final product), and taken up for immediate
development
✧ With each iteration around the spiral (beginning at the center and moving
outwards), progressively more complete versions of the software are
developed
✧ Thus, implementation of the identified set of features forms a phase

40
 Spiral Model
✧ A prominent feature of the spiral model is handling
unforeseen risks that can show up much after the project has
started

41
 Spiral Model
✧ Prototyping Vs Spiral
▪ While the prototyping model provides explicit support for risk handling, the
risks are assumed to have been identified completely before the start of the
project.
▪ This is required since the prototype is constructed only at the start of the
project.
▪ In contrast, in the spiral model, prototypes are built at the start of
every phase.
▪ Each phase of the model is represented as a loop
• In each loop, one or more features of the product are elaborated and analyzed, and the
risks at that point of time are identified and are resolved through prototyping.
▪ Based on this, the identified features are implemented.
42
 Rapid Software Development

✧ Rapid development and delivery is now often the most

important requirement for software systems
▪ Businesses operate in a fast changing requirement, and it is practically
impossible to produce a set of stable software requirements
▪ Software has to evolve quickly to reflect changing business needs
✧ Plan-driven development is essential for some types of system,
but does not meet these business needs
✧ Agile development methods emerged in the late 1990s
▪ The aim was to radically reduce the delivery time for working software
systems
43
 What is Agile Development
✧ Program specification, design and implementation are
interleaved
✧ The system is developed as a series of versions or
increments with stakeholders involved in version
specification and evaluation
✧ Frequent delivery of new versions for evaluation
✧ Extensive tool support (e.g., automated testing tools) used
to support development.
✧ Minimal documentation - focus on working code 44
 Why Agile?
✧ Agile development isn’t a silver bullet
✧ Adopting agile development is not recommended to solely to
increase productivity
✧ Its benefits - even the ability to release software more frequently -
come from working differently, not from working faster
✧ When you consider using agile development, only one question
matters
▪ Will agile development help us be more successful?
▪ When you can answer that question, you’ll know whether agile development is
right for you
45
Plan-driven Vs Agile development

46
 Plan-driven Vs 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.
47
Plan-driven Vs Agile development

48
Plan-driven Vs Agile development

49
 Agile methods
✧ Dissatisfaction with the overheads involved in software
design methods of the 1980s and 1990s led to the creation
of agile methods.
✧ Agile development is a philosophy; It’s a way of thinking
about software development
✧ Agile methods are processes that support the agile
philosophy.
▪ Examples include Extreme Programming and Scrum.

50
 Agile methods
✧ Agile methods consist of individual elements called
practices
▪ Agile methods combine them in unique ways, accentuating those parts
that support the agile philosophy, discarding the rest, and mixing in a
few new ideas

51
 Agile methods
✧ Agile methods:
▪ Focus on the code rather than the design
▪ Are based on an iterative approach to software development
▪ 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 52
 Agile Manifesto
✧ The description of the agile philosophy is the Agile Manifesto, a collection
of 4 values and 12 principles
✧ 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.
53
 Agile Principles
Principles Description
Customer Our highest priority is to satisfy the customer through early and continuous delivery of
Satisfaction valuable software
Changing Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage
Requirements
Deliver Deliver working software frequently, from a couple of weeks to a couple of months,
Frequently with a preference to the shorter timescale
Customer Business people and developers must work together daily throughout the project
Collaboration
Build projects around motivated individuals.
Trust Give them the environment and support they need, and trust them to get the job done

Sitting The most efficient and effective method of conveying information to and within a
Together development team is face-to-face conversation

54
 Agile Principles
Principles Description
Working
Working software is the primary measure of progress
Software
Sustainable Agile processes promote sustainable development. The sponsors, developers,
Development and users should be able to maintain a constant pace indefinitely

Technical Continuous attention to technical excellence and good design enhances agility
Excellence
Simplicity - the art of maximizing the amount of work not done
Simplicity
- is essential
Self-Organizing The best architectures, requirements, and designs come from self-organizing teams
Teams
Adaptive At regular intervals, the team reflects on how to become more
Planning effective, then tunes and adjust its behavior accordingly

55
 The Road to Mastery
✧ Mastering the art of agile development requires real- world
experience using a specific, well-defined agile method
✧ Extreme Programming (XP) suits this purpose very well.
It has several advantages:
▪ XP is most complete when compared to other agile methods
▪ XP places a strong emphasis on technical practices in addition to the
more common teamwork and structural practices.
▪ XP has undergone intense scrutiny
▪ Well documented in the literature
▪ Its capabilities and limitations are very well understood 56
 The Road to Mastery
✧ To master the art of agile development, follow these steps:
▪ Decide why you want to use agile development. Will it make your team and
organization more successful? How?
▪ Adopt as many of XP’s practices as you can
▪ Follow the XP practices rigorously and consistently; If a practice doesn’t work,
try to follow the proposed approach more closely
• Teams new to XP often under apply its practices
• Expect to take 2 or 3 months to start feeling comfortable with the practices; another 2 to
6 months for them to become second nature
▪ As you become confident that you are practicing XP correctly, give it several months
• Start experimenting - Each time you make a change, observe what happens and make
further improvements.
57
 Extreme Programming
✧ One of the most astonishing premises of Extreme
Programming (XP):
▪ You can eliminate requirements, design, and testing phases as well
as the formal documents that go with them
✧ It's quite different from the way we typically learn to
develop software: many people dismiss it as a fantasy
✧ The traditional approach is: “we need more requirements,
design, and testing, not less!”
▪ That’s true - software projects do need more requirements,
58
design, and testing
 Introduction to XP
✧ XP emphasizes face-to-face collaboration
▪ This is so effective in eliminating communication delays and
misunderstandings that the team no longer needs distinct phases.
▪ This allows them to work on all activities every day - with
simultaneous phases

59
 Introduction to XP

✧ Using simultaneous phases, an XP team produces

deployable software every week
✧ In each iteration, the team analyzes, designs, codes, tests,
and deploys a subset of features
60
 Introduction to XP
✧ Analysis, design, coding, testing, and even deployment
occur with rapid frequency - simultaneously
✧ XP does it by working in iterations:
▪ Every week (or two weeks), the team does a bit of release planning, a bit of
design, a bit of coding, a bit of testing, and so forth
▪ They work on stories: very small features, or parts of features, that have
customer value
▪ Every (two) week, the team commits to delivering four to ten stories
▪ Throughout the week, they work on all phases of development for each story.
▪ At the end of the (two) week, they deploy their software for internal
review 61
 The XP Lifecycle
✧ Planning
✧ Analysis
✧ Design and Coding
✧ Testing
✧ Deployment

62
 The XP Process
✧ 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
63
 Extreme Programming Practices
✧ Incremental planning ✧ Small releases
✧ On-site customer ✧ Test first development
✧ Simple design ✧ Refactoring
✧ Pair programming ✧ Continuous integration
✧ Collective ownership ✧ Sustainable pace

64
 XP Lifecycle: Planning
✧ Incremental planning
▪ Requirements are recorded on “story cards”
▪ The stories to be included in a release are determined by the time
available and their relative priority
▪ The developers break these stories into development “tasks”

65
The XP Release Cycle

66
 User Stories
✧ 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
▪ A user story is a scenario of use that might be experienced by a
system user
✧ As far as possible, the customer works closely with the
development team and discusses these scenarios with other
team members 67
 User Stories
✧ Together, they develop a “story card” that briefly describes a
story 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 is shown
▪ A short description of a scenario for Prescribing Medication for a
patient

68
User Story – Example : Prescribing Medication

69
 User Stories to Tasks
✧ The development team then aims to implement that
scenario in a future release of the software.
✧ User stories may be used in planning system iterations
✧ Once the story cards have been developed, the
development team breaks these down into tasks and
estimates the effort and resources required for
implementing each task

70
Task Card – Examples : Prescribing Medication

71
 User Stories to Tasks
✧ 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.
✧ The intention is to identify useful functionality that can be
implemented in about two weeks, when the next release of
the system is made available to the customer
72
 XP Lifecycle: Planning
✧ Every XP team includes several business experts - the
On-site Customers - who are responsible for making
business decisions
✧ On-site Customers
▪ Point the project in the right direction by
• Clarifying the Project Vision
• Creating Stories
• Constructing a Release Plan and
• Managing Risks
▪ Should be available full time for the use of the XP team 73
 XP Lifecycle: Planning
✧ Programmers provide Estimates and Suggestions
▪ These are blended with customer priorities in a process called the
Planning Game
✧ On-site customers and Programmers
▪ Together as a team, strives to create small, frequent releases that
maximize value

74
 XP Lifecycle: Planning
✧ The planning effort is most intense during the first few
weeks of the project
✧ During the remainder of the project, customers continue to
review and improve the vision
✧ In addition to the overall release plan, the team creates a
detailed plan for the upcoming week at the beginning of each
iteration (Iteration Planning)

75
 XP Lifecycle: Analysis
✧ Rather than using an upfront analysis phase to define
requirements, on-site customers sit with the team full-
time.
✧ On-site customers
▪ May or may not be real customers depending on the type of project,
but they are the people best qualified to determine what the software
should do
▪ Are responsible for figuring out the requirements for the
software.
▪ Use their own knowledge as customers combined with traditional 76
 XP Lifecycle: Analysis
✧ When programmers need information, they simply ask
✧ Customers are responsible for organizing the programmers’
work, so they are ready when they ask for information
✧ Customers figure out
▪ The general requirements for a story before the programmers
estimate it
▪ The detailed requirements for the story before the programmers
implement it

77
 XP Lifecycle: Analysis
✧ Some requirements are tricky or difficult to understand
✧ Customers formalize these requirements, with the
assistance of testers, by creating customer tests
▪ Detailed, Automatically checked examples
✧ Customers and testers create the customer tests for a story
around the same time that programmers implement the story

78
 XP Lifecycle: Design and Coding
✧ Simple design
▪ Enough design is carried out to meet the current requirements and
no more
✧ Pair programming
✧ Small releases

79
 XP Lifecycle: Design and Coding
✧ Simple design
✧ Pair programming
▪ Developers work in pairs, checking each other's work and
providing the support to always do a good job
✧ Small releases

80
 XP Lifecycle: Design and Coding
✧ Simple design
✧ Pair programming
✧ Small releases
▪ The minimal useful set of functionality that provides business
value is developed first.
▪ Releases of the system are frequent and incrementally add
functionality to the first release

81
 XP Lifecycle: Design and Coding
✧ XP uses incremental design and architecture to
continuously create and improve the design in small
steps.
✧ This work is driven by Test-Driven Development (TDD), an
activity that inextricably weaves together testing, coding,
design, and architecture
✧ To support this process, programmers work in pairs
▪ Increases the amount of brainpower brought to bear on each task
▪ Ensures that one person in each pair always has time to think about
82
larger design issues
 XP Lifecycle: Design and Coding
✧ Programmers
▪ Are responsible for managing their development environment
▪ Integrate their code every few hours
▪ Ensure that every integration is technically capable of deployment
✧ To support this effort, programmers also maintain coding
standards and share ownership of the code
✧ The team shares a joint aesthetic for the code
▪ Everyone is expected to fix problems in the code regardless of who
wrote it
83
 Pair Programming
✧ Programmers sit together at the same computer to
develop the software.
✧ Pairs are created dynamically so that all team members work
with each other during the development process

84
 Pair Programming
✧ Advantages
▪ Helps develop common ownership of code and spreads
knowledge across the team
▪ Serves as an informal review process as each line of code is looked at
by more than one person
▪ Encourages refactoring to improve the software structure
▪ 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.
▪ There is some evidence that suggests that a pair working together
is more efficient than two programmers working separately
85
 XP Lifecycle: Testing
✧ XP includes a sophisticated suite of testing practices
✧ Each member of the team - programmers, customers, and
testers - makes his own contribution to software quality.
✧ Well-functioning XP teams produce only a handful of bugs per
month in completed work

86
 XP Lifecycle: Testing
✧ Extreme Programming developed a new approach to program
testing to address the difficulties of testing without a specification
✧ The program is tested after every change has been made
✧ Key features of testing in XP
▪ Test Driven Development (TDD). Also referred to as Test-First Development
▪ Incremental test development from scenarios
▪ User involvement in test development and validation
▪ Automated test harnesses are used to run all component tests each time that a
new release is built.

87
Test case description for dose checking

88
 Test Driven Development
✧ Test Driven Development
▪ Writing tests before code clarifies the requirements to be
implemented.
▪ Tests are written as programs rather than data so that they can be
executed automatically. The test includes a check that it has executed
correctly.
▪ An automated unit testing framework (such as Junit) is used to write
tests for a new piece of functionality before that functionality itself
is implemented
▪ All previous and new tests are run automatically when new
functionality is added, thus checking that the new functionality has 89
 XP Lifecycle: Testing
✧ Customer tests help ensure that the programmers’ intent
matches customers’ expectations
✧ Testers help the team understand whether their efforts are in
fact producing high quality code.
▪ Testers use exploratory testing to look for surprises and gaps in the
software
✧ Testers also explore the software’s non-functional
characteristics, such as performance and stability

90
 XP Lifecycle: Testing
✧ The team doesn’t perform any manual regression testing
✧ TDD and customer testing leads to a sophisticated suite of
automated regression tests
✧ When bugs are found, programmers create automated tests
to show that the bugs have been resolved

91
 XP Lifecycle: Deployment
✧ XP teams keep their software ready to deploy at the end of
any iteration
✧ They deploy the software to internal stakeholders every
week in preparation for the weekly iteration demo
✧ Deployment to real customers is scheduled according to
business needs

92
 XP Lifecycle: Deployment
✧ As long as the team is active, it maintains the software it has
released
✧ Depending on the organization, the team may also
support its own software
✧ In other cases, a separate support team may take over
✧ Similarly, when the project ends, the team may hand off
maintenance duties to another team
▪ In this case, the team creates documentation and provides
training as necessary during its last few weeks 93
 Other XP Practices
✧ Collective ownership
▪ The pairs of developers work on all areas of the system, so that no
islands of expertise develop, and all the developers take
responsibility for all of the code
▪ Anyone can change anything
✧ Continuous integration
✧ Sustainable pace
✧ Refactoring
94
 Other XP Practices
✧ Collective ownership
✧ Continuous integration
▪ As soon as the work on a task is complete, it is integrated into the
whole system.
▪ After any such integration, all the unit tests in the system must pass
✧ Sustainable pace
✧ Refactoring

95
 Other XP Practices
✧ Collective ownership
✧ Continuous integration
✧ Sustainable pace
▪ Large amounts of overtime are not considered acceptable
▪ Since, the net effect would reduce the quality of the code and
result in medium-term productivity
✧ Refactoring

96
 Other XP Practices
✧ Collective ownership
✧ Continuous integration
✧ Sustainable pace
✧ Refactoring
▪ Changing a software system in such a way that it does not alter the
external behavior of the code yet improves the internal structure.
▪ All developers are expected to refactor the code continuously as soon
as potential code improvements are found
▪ Keeps the code simple and maintainable 97
 Refactoring
✧ Conventional wisdom in software engineering is to
design for change.
▪ It is worth spending time and effort anticipating changes as this
reduces costs later in the life cycle.
✧ XP, however, maintains that this is not worthwhile as
changes cannot be reliably anticipated.
✧ Rather, XP proposes constant code improvement
(Refactoring) to make changes easier when they have to be
implemented
98
 Refactoring
✧ Programming team look for possible software improvements and
make 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 requires architecture refactoring, and this
is much more expensive.
99
 Refactoring
✧ Examples of Refactoring
▪ Reorganization 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

10
 The XP Team
✧ Team software development is different than working solo on
a project
▪ Information is spread out among many members of the team
✧ XP creates cross-functional teams composed of diverse people
who can fulfill all the team’s roles
✧ XP Teams
▪ Sit together in an open workspace
▪ At the beginning of each iteration, the team meets for a series of activities
▪ Also meet for daily stand-up meetings, which usually take five to ten minutes
each
10
 The XP Team
✧ XP Teams
▪ Other than the scheduled activities, everyone on the team plans his
own work
▪ Team members work out the details of each meeting when they need
to.
▪ Sometimes it’s as informal as somebody standing up and
announcing across the shared workspace that he would like to
discuss an issue
✧ This self-organization is a hallmark of agile teams
10
 XP Concepts
✧ XP has its own vocabulary. Some of the most common are:
▪ User Stories
▪ Iterations
▪ Velocity
▪ Refactoring
▪ Pair Programming

10
 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
✧ Agile project management requires a different approach, which is
adapted to incremental development and the practices used in agile
methods. 10
 Scrum
✧ Scrum is an agile method that focuses on managing iterative
development rather than specific agile practices
✧ 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.
✧ To make it clear that Scrum was not a method for project
management in the conventional sense,
▪ New terminologies such as ScrumMaster was invented, which replaced
names such as project manager 10
 Scrum
✧ There are three phases in Scrum
▪ The initial phase is an Outline Planning phase
• Establish the general objectives for the project and design the
software architecture
▪ This is followed by a series of Sprint Cycles
• Each cycle develops an increment of the system
▪ The Project Closure phase
• Wraps up the project
• Completes required documentation such as system help frames and user
manuals
• Assesses the lessons learned from the project 10
 Scrum Terminologies
✧ Development team
▪ A self-organizing group of software developers, which should be no more than 7 people
▪ They are responsible for developing the software and other essential project
documents
✧ Product backlog
▪ This is a list of ‘to do’ items which the Scrum team must tackle
▪ They may be
• Feature definitions for the software
• Software requirements
• User stories
• Descriptions of supplementary tasks that are needed, such as architecture definition or
user documentation.
10
 Scrum Terminologies
✧ Scrum
▪ A daily meeting of the Scrum team that reviews progress and
prioritizes work to be done that day.
▪ Ideally, this should be a short face-to-face meeting that includes the
whole team
✧ ScrumMaster
▪ Responsible for ensuring that the Scrum process is followed
▪ Guides the team in the effective use of Scrum
▪ Responsible for interfacing with the rest of the company
▪ Ensures that the Scrum team is not diverted by outside 10
 Scrum Terminologies
✧ Product owner
▪ An individual (or possibly a small group) whose job is to
• Identify product features or requirements
• Prioritize these for development and
• Continuously review the product backlog to ensure that the project
continues to meet critical business needs
▪ The Product owner can be a customer but might also be a product
manager in a software company or other stakeholder
representative.

11
 Scrum Terminologies
✧ Sprint
▪ A development iteration. Sprints are usually 2-4 weeks long.
✧ Velocity
▪ An estimate of how much product backlog effort that a team can cover
in a single sprint
▪ Understanding a team’s velocity helps to estimate what can be covered
in a sprint and provides a basis for measuring improving performance.

11
 Scrum Terminologies
✧ Potentially shippable product increment
▪ The software increment that is delivered from a sprint
▪ ‘Potentially shippable’ means that it is in a finished state
▪ No further work, such as testing, is needed to incorporate it into the
final product.

11
 Scrum Process
The Scrum process or Sprint Cycle is shown

11
 Scrum Sprint Cycle
✧ Sprints are fixed length, normally 2–4 weeks.
✧ Each process iteration produces a product increment that
could be delivered to customers
✧ The starting point for planning is the product backlog,
which is the list of work to be done on the project.

11
 Scrum Sprint Cycle
✧ The initial version of the product backlog may be derived
from
▪ A Requirements Document
▪ A List of User Stories, or
▪ Other description of the software to be developed
✧ The selection phase
▪ All the project team members work with the customer to select the
features and functionality from the product backlog to be developed
during the sprint.
11
 Scrum Sprint Cycle
✧ Once these are agreed, the team organize themselves to
develop the software.
✧ During this stage, the team is isolated from the customer and
the organization, with all communications channelled through
the ‘Scrum master’
✧ The role of the Scrum master is to protect the
development team from external distractions.
✧ At the end of the sprint, the work done is reviewed and
presented to stakeholders. The next sprint cycle then begins. 11
 Teamwork in Scrum
✧ The ‘Scrum master’ is a facilitator who
▪ Arranges daily meetings
▪ Tracks the backlog of work to be done
▪ Records decisions
▪ Measures progress against the backlog
▪ Communicates with customers and management outside of the team

11
 Teamwork in Scrum

✧ The whole team attends short daily meetings (Scrums)

where
▪ 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 re-plan short-term work to
cope with them.
11
 Scrum benefits
✧ The product is broken down into a set of manageable and
understandable chunks.
✧ Unstable requirements do not hold up progress.
✧ The whole team have visibility of everything and
consequently team communication is improved.
✧ Customers see on-time delivery of increments and gain feedback
on how the product works.
✧ Trust between customers and developers is established and a
positive culture is created in which everyone expects the project to
12
succeed.
 Practical problems with agile methods
✧ The informality of agile development is incompatible with the
legal approach to contract definition that is commonly used in
large companies.
✧ Agile methods are most appropriate for new software
development rather than software maintenance. Yet, majority of
software costs in large companies come from maintaining their
existing software systems.
✧ Agile methods are designed for small co-located teams, yet
much software development now involves worldwide
distributed teams. 12
 Contractual issues
✧ Most software contracts for custom systems are based around
a specification, which sets out what has to be implemented by
the system developer for the system customer.
✧ However, this precludes interleaving specification and
development as is the norm in agile development.
✧ A contract that pays for developer time rather than
functionality is required.
▪ However, this is seen as a high risk by many legal departments because
what has to be delivered cannot be guaranteed.
12
 Agile Maintenance
✧ Key problems are:
▪ Lack of product documentation
▪ Keeping customers involved in the development process
▪ Maintaining the continuity of the development team
✧ Agile development relies on the development team
knowing and understanding what has to be done.
✧ For long-lifetime systems, this is a real problem as the
original developers will not always work on the system.
12
 Agile and plan-driven methods
✧ Most projects include elements of plan-driven and agile
processes. Deciding on the balance depends on:
▪ Is it important to have a very detailed specification and design before
moving to implementation? If so, you probably need to use a
plan-driven approach.
▪ 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.
▪ 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 12
 System issues
✧ How large is the system being developed?
▪ Agile methods are most effective for a relatively small co-located team
who can communicate informally.
✧ What type of system is being developed?
▪ Systems that require a lot of analysis before implementation need a
fairly detailed design to carry out this analysis.
✧ What is the expected system lifetime?
▪ Long-lifetime systems require documentation to communicate the
intentions of the system developers to the support team.
12