MODULE 1 :

Introduction to Software Engineering

Ref:
Book 1 - Ian Sommerville, Software Engineering, Pearson Education, Tenth edition, 2015.
Book 2 - Roger S. Pressman, Software Engineering : A practitioner’s approach, McGraw
Hill publication, Eighth edition, 2014
 MODULE 1 : Introduction to Software Engineering (7 hours)
Syllabus

► Introduction to Software Engineering - Professional software development,

Software engineering ethics

► Software process models - The waterfall model, Incremental development.

Process activities - Software specification, Software design and
implementation, Software validation, Software evolution. Coping with
change - Prototyping, Incremental delivery, Boehm's Spiral Model.

► Agile software development - Agile methods, agile manifesto - values and

principles. Agile development techniques, Agile Project Management.

► Case studies : An insulin pump control system. Mentcare - a patient

information system for mental health care.
 Introduction to Software Engineering
► We can’t run the modern world without software.
► More and more systems are being software controlled:
► More than 75% of the world’s population use a software-controlled,
Internet-enabled mobile phone.
► National infrastructures and utilities are controlled by computer-based
systems
► Most electrical products include a computer and controlling software.
► Industrial manufacturing and distribution is completely computerized, as is
the financial system.
► Entertainment, including the music industry, computer games, and film
and television, is software-intensive.
 Introduction to Software Engineering

► The economies of ALL developed nations are dependent on

software.

► Software engineering is essential for the functioning of

government, society and various national and international
businesses and institutions.

► There are many different types of software system,

► ranging from simple embedded systems to complex,
worldwide information systems.
 Introduction to Software Engineering

► As different types of software require different approaches,

there are no universal notations, methods, or techniques for
software engineering.
► An organizational information system
► A controller for a scientific instrument
► A graphics-intensive computer game

► All of these applications need software engineering;

► But they do not all need the same software engineering
methods and techniques.
 Introduction to Software Engineering

Factors causing Software project failure

► Increasing system complexity
► We need to build larger, more complex systems.
► Systems have to be built and delivered more quickly
► Systems should have new capabilities
► Failure to use software engineering methods
► It is fairly easy to write computer programs without using software
engineering methods and techniques.
► Many software development companies do not use software
engineering methods in their everyday work.
► Consequently, their software is often more expensive and less reliable
than it should be.
 Professional software development
► Software development is a professional activity
► Professional software is :
► intended for use by someone apart from its developer and
► usually developed by teams rather than individuals.
► maintained and changed throughout its life.

► Software engineering is intended to support professional

software development rather than individual programming.
► It includes techniques that support program specification,
design and evolution.
 Frequently asked questions about software engineering
Question Answer
What is software? Computer programs and associated documentation.
Software products may be developed for a particular
customer or may be developed for a general market.
What are the attributes of good software? Good software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and usable.
What is software engineering? Software engineering is an engineering discipline that is
concerned with all aspects of software production.
What are the fundamental software Software specification, software development, software
engineering activities? validation and software evolution.
What is the difference between software Computer science focuses on theory and fundamentals;
engineering and computer science? software engineering is concerned with the practicalities of
developing and delivering useful software.
What is the difference between software System engineering is concerned with all aspects of
engineering and system engineering? computer-based systems development including hardware,
software and process engineering. Software engineering is
part of this more general process.
 Frequently asked questions about software engineering
Question Answer
What are the key challenges facing software Coping with increasing diversity, demands for reduced
engineering? delivery times and developing trustworthy software.
What are the costs of software engineering? Roughly 60% of software costs are development costs, 40%
are testing costs. For custom software, evolution costs often
exceed development costs.
What are the best software engineering While all software projects have to be professionally managed
techniques and methods? and developed, different techniques are appropriate for
different types of system. For example, games should always
be developed using a series of prototypes whereas safety
critical control systems require a complete and analyzable
specification to be developed. You can’t, therefore, say that
one method is better than another.
What differences has the web made to The web has led to the availability of software services and
software engineering? the possibility of developing highly distributed service-based
systems. Web-based systems development has led to
important advances in programming languages and software
reuse.
 Product specification

► Generic products
► The specification of what the software should do is owned by
the software developer and decisions on software change are
made by the developer.

► Customized products
► The specification of what the software should do is owned by
the customer for the software and they make decisions on
software changes that are required.
 Essential attributes of good software
Product characteristic Description

Software should be written in such a way so that it can evolve to

meet the changing needs of customers. This is a critical attribute
Maintainability because software change is an inevitable requirement of a
changing business environment.
Software dependability includes a range of characteristics
including reliability, security and safety. Dependable software
Dependability and
should not cause physical or economic damage in the event of
security system failure. Malicious users should not be able to access or
damage the system.
Software should not make wasteful use of system resources such
Efficiency as memory and processor cycles. Efficiency therefore includes
responsiveness, processing time, memory utilisation, etc.

Software must be acceptable to the type of users for which it is

Acceptability designed. This means that it must be understandable, usable and
compatible with other systems that they use.
 Software Engineering
► Software engineering is an engineering discipline that is
concerned with all aspects of software production from the
early stages of system specification through to maintaining the
system after it has gone into use.
► Engineering discipline
► Using appropriate theories and methods to solve problems within
the organizational and financial constraints.
► All aspects of software production
► Not just technical process of development. Also project
management and the development of tools, methods etc. to
support software production.
Importance of software engineering

► More and more, individuals and society rely on advanced

software systems. We need to be able to produce reliable and
trustworthy systems economically and quickly.

► It is usually cheaper, in the long run, to use software

engineering methods and techniques for software systems
rather than just write the programs as if it was a personal
programming project. For most types of system, the majority
of costs are the costs of changing the software after it has
gone into use.
SOFTWARE PROCESS

A Software process is a sequence of activities that leads to the

production of a software product.
 Software process activities
A Software process is a sequence of activities that leads to the production of a
software product.

► Software specification, where customers and engineers define the

software that is to be produced and the constraints on its operation.

► Software development, where the software is designed and

programmed.

► Software validation, where the software is checked to ensure that it

is what the customer requires.

► Software evolution, where the software is modified to reflect

changing customer and market requirements.
General issues that affect most software
► Heterogeneity
► Increasingly, systems are required to operate as distributed systems
across networks that include different types of computer and mobile
devices.
► Business and social change
► Business and society are changing incredibly quickly as emerging
economies develop and new technologies become available. They
need to be able to change their existing software and to rapidly
develop new software.
► Security and trust
► As software is intertwined with all aspects of our lives, it is essential
that we can trust that software
Software Engineering diversity

► There are many different types of software system and

there is no universal set of software techniques that is
applicable to all of these.

► The software engineering methods and tools used

depend on the type of application being developed, the
requirements of the customer and the background of
the development team.
 Application types
► Stand-alone applications
► These are application systems that run on a local computer, such as a PC.
They include all necessary functionality and do not need a network
connection.
► Interactive transaction-based applications
► Applications that execute on a remote computer and are accessed by users
from their own PCs or terminals. Include web applications like e-commerce.
► Embedded control systems
► These are software control systems that control and manage hardware
devices. There are more embedded systems than any other type of system.
► Batch processing systems
► These are business systems, designed to process data in large batches. They
process large numbers of individual inputs to create corresponding outputs.
 Application types

► Entertainment systems
► These are systems that are primarily for personal use and which are
intended to entertain the user.
► Systems for modeling and simulation
► These are systems that are developed by scientists and engineers to
model physical processes or situations, which include many, separate,
interacting objects.
► Data collection systems
► These are systems that collect data from their environment using a set
of sensors and send that data to other systems for processing.
► Systems of systems
► These are systems that are composed of a number of other software
systems
Software Engineering Ethics
Software engineering ethics

► Software engineering involves wider responsibilities than

simply the application of technical skills.
► Software engineers must behave in an honest and ethically
responsible way if they are to be respected as
professionals.
► Ethical behaviour is more than simply upholding the law
but involves following a set of principles that are morally
correct.
SOFTWARE ENGINEERING ETHICS-AREAS

► Confidentiality
► Engineers should normally respect the confidentiality of their
employers or clients irrespective of whether or not a formal
confidentiality agreement has been signed.

► Competence
► Engineers should not misrepresent their level of competence.
They should not knowingly accept work which is outwith their
competence.
Issues of professional responsibility

► Intellectual property rights

► Engineers should be aware of local laws governing the use of
intellectual property such as patents, copyright, etc. They
should be careful to ensure that the intellectual property of
employers and clients is protected.
► Computer misuse
► Software engineers should not use their technical skills to
misuse other people’s computers. Computer misuse ranges
from relatively trivial (game playing on an employer’s machine,
say) to extremely serious (dissemination of viruses).
ACM/IEEE Code of Ethics

► The professional societies in the US have cooperated to

produce a code of ethical practice.

► Members of these organisations sign up to the code of

practice when they join.

► The Code contains 8 Principles related to the behaviour of

and decisions made by professional software engineers,
including practitioners, educators, managers, supervisors
and policy makers, as well as trainees and students of the
profession.
 The ACM/IEEE Code of Ethics
Software Engineering Code of Ethics and Professional Practice
► ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and Professional
Practices
PREAMBLE
► The short version of the code summarizes aspirations at a high level of the
abstraction; the clauses that are included in the full version give examples and details
of how these aspirations change the way we act as software engineering professionals.
Without the aspirations, the details can become legalistic and tedious; without the
details, the aspirations can become high sounding but empty; together, the aspirations
and the details form a cohesive code.
► Software engineers shall commit themselves to making the analysis, specification,
design, development, testing and maintenance of software a beneficial and respected
profession. In accordance with their commitment to the health, safety and welfare of
the public, software engineers shall adhere to the following Eight Principles:
 Ethical principles

1. PUBLIC - Software engineers shall act consistently with the public

interest.

2. CLIENT AND EMPLOYER - Software engineers shall act in a manner

that is in the best interests of their client and employer consistent
with the public interest.

3. PRODUCT - Software engineers shall ensure that their products

and related modifications meet the highest professional standards
possible.

4. JUDGMENT - Software engineers shall maintain integrity and

independence in their professional judgment.
 Ethical principles

5. MANAGEMENT - Software engineering managers and leaders shall

subscribe to and promote an ethical approach to the management of
software development and maintenance.

6. PROFESSION - Software engineers shall advance the integrity and

reputation of the profession consistent with the public interest.

7. COLLEAGUES - Software engineers shall be fair to and supportive

of their colleagues.

8. SELF - Software engineers shall participate in lifelong learning

regarding the practice of their profession and shall promote an
ethical approach to the practice of the profession.
CASE STUDIES
CASE STUDIES

► A personal insulin pump

► An embedded system in an insulin pump used by diabetics to maintain
blood glucose control.
► A mental health care patient management system
► A system used to maintain records of people receiving care for mental
health problems.
 Insulin pump control system
► Diabetes is a relatively common condition in which the human
pancreas is unable to produce sufficient quantities of a hormone
called insulin.
► Insulin metabolizes glucose (sugar) in the blood.
► The conventional treatment of diabetes involves regular injections
of genetically engineered insulin.

► An insulin pump is a medical system that simulates the

operation of the pancreas.
► The software controlling this system is an embedded system
that collects information from a sensor and controls a pump that
delivers a controlled dose of insulin to a user.
 Insulin pump control system

► Collects data from a blood sugar sensor and calculates the

amount of insulin required to be injected.

► The blood sensor measures the electrical conductivity of the blood

under different conditions and that these values can be related to
the blood sugar level.

► The problem is that the level of insulin required does not just
depend on the blood glucose level but also on the time of the last
insulin injection.
 Insulin pump control system

► Sends signals to a micro-pump to deliver the correct dose of

insulin.
► The insulin pump delivers one unit of insulin in response to a
single pulse from a controller.
► Therefore, to deliver 10 units of insulin, the controller sends 10
pulses to the pump.
Insulin pump hardware architecture
UML Activity model of the insulin pump
Essential high-level requirements

► Safety-critical system as low blood sugars can lead to brain

malfunctioning, coma and death; high-blood sugar levels have
long-term consequences such as eye and kidney damage.
► Essential high-level requirements
► The system shall be available to deliver insulin when required.
► The system shall perform reliably and deliver the correct
amount of insulin to counteract the current level of blood
sugar.
► The system must therefore be designed and implemented to
ensure that the system always meets these requirements.
 Mentcare:
A patient information system for mental health care

► The Mentcare is a medical information system that maintains

information about patients suffering from mental health problems
and the treatments that they have received.
► Most mental health patients do not require dedicated hospital
treatment but need to attend specialist clinics regularly where
they can meet a doctor who has detailed knowledge of their
problems.
► To make it easier for patients to attend, these clinics are not just
run in hospitals. They may also be held in local medical practices
or community centres.
 Mentcare

► Mentcare is an information system that is intended for use in

such clinics.
► It makes use of a centralized database of patient information
but has also been designed to run on a PC, so that it may be
accessed and used from sites that do not have secure network
connectivity.
► When the local systems have secure network access, they use
patient information in the database but they can download and
use local copies of patient records when they are disconnected.
The organization of the Mentcare system
 Mentcare Goals

► To generate management information that allows health

service managers to assess performance against local and
government targets.

► To provide medical staff with timely information to support the

treatment of patients.
 Key features of the Mentcare system
► Individual care management
► Clinicians can create records for patients, edit the information in the
system, view patient history, etc. The system supports data
summaries so that doctors can quickly learn about the key problems
and treatments that have been prescribed.
► Patient monitoring
► The system monitors the records of patients that are involved in
treatment and issues warnings if possible problems are detected.
► If a patient has not seen a doctor for some time, a warning may be
issued.
► Used to keep track of patients who have been sectioned and to ensure
that the legally required checks are carried out at the right time.
 Key features of the Mentcare system
► Administrative reporting
► The system generates monthly management reports showing
► the number of patients treated at each clinic,
► the number of patients who have entered and left the care system,
► number of patients sectioned,
► the drugs prescribed and their costs, etc.

► Users of the system include clinical staff such as doctors, nurses, and health
visitors (nurses who visit people at home to check on their treatment).
► Nonmedical users include receptionists who make appointments, medical
records staff who maintain the records system, and administrative staff who
generate reports.
 Mentcare system concerns

► Privacy
► It is essential that patient information is confidential and is never
disclosed to anyone apart from authorised medical staff and the
patient themselves.
► Safety
► Some mental illnesses cause patients to become suicidal or a
danger to other people. Wherever possible, the system should warn
medical staff about potentially suicidal or dangerous patients.
► The system must be available when needed otherwise safety
may be compromised and it may be impossible to prescribe the
correct medication to patients.
SOFTWARE PROCESS MODELS
The Software Process (Software Life Cycle)

► A Software Process is a set of related activities that leads to the

production of a software system.
► There are many different software processes but all involve:
► Specification – defining what the system should do;
► Design and implementation – defining the organization of the
system and implementing the system;

► Validation – checking that it does what the customer wants;

► Evolution – changing the system in response to changing customer
needs.
Software process descriptions

► Processes also include sub-activities such as requirements validation,

architectural design, unit testing, software configuration
management, project planning etc.

► Process descriptions may also include:

► Products :- the outcomes of a process activity;
► Roles :- reflect the responsibilities of the people involved in the
process;
► Pre- and post-conditions :- statements that are true before and after
a process activity has been enacted or a product produced.
Plan-driven and Agile Processes

► In Plan-driven Processes, all of the process activities are

planned in advance and progress is measured against this plan.

► In Agile Processes, planning is incremental and continual as the

software is developed. It is easier to change the process to
reflect changing customer requirements.

► Generally, most practical processes include elements of both

plan-driven and agile approaches.

► There are no right or wrong software processes; each approach is

suitable for different types of software.
 Software process models
(Software Development Life Cycle or SDLC model)

► A software process model is an abstract, simplified representation of a

process.
► Each process model represents a process from a particular perspective
and thus only provides partial information about that process.
► For example, a process activity model shows the activities and their
sequence but may not show the roles of the people involved in these
activities.
 Software process models
(Software Development Life Cycle or SDLC model)
► The waterfall model
► Fundamental process activities are represented as separate process
phases such as requirements specification, software design,
implementation and testing. Plan-driven model.
► Incremental development
► Specification, development and validation are interleaved. The system is
developed as a series of versions (increments), with each version adding
functionality to the previous version. May be plan-driven or agile.
► Integration and configuration
► The system is assembled from existing configurable components. May be
plan-driven or agile.
► In practice, most large systems are developed by incorporating elements
from all of these models.
The waterfall model ► It presents the software development
process as a number of distinct stages
(Phases) .
► Because of the cascade from one phase to
another, it is known as the waterfall model.
► The waterfall model is a plan-driven
process.
► In principle at least, you plan and schedule
all of the process activities before starting
software development.
Waterfall model Phases
There are separate identified phases in the waterfall model:
► Requirements analysis and definition : The system’s services,
constraints, and goals are established by consultation with system
users. They are then defined in detail and serve as a system
specification.
► System and software design : The systems design process
allocates the requirements to either hardware or software
systems. It establishes an overall system architecture.
► Implementation and unit testing : During this stage, the software
design is realized as a set of programs or program units. Unit
testing involves verifying that each unit meets its specification.
Waterfall model Phases
► Integration and system testing : The individual units are
integrated and tested as a complete system to ensure that the
software requirements have been met. After testing, the
software system is delivered to the customer.
► Operation and maintenance : Normally, this is the longest
life-cycle phase. The system is installed and put into practical
use. Maintenance involves correcting errors that were not
discovered in earlier stages of the life cycle, improving the
implementation of system units, and enhancing the system’s
services as new requirements are discovered.
Waterfall model problems
► The main drawback of the waterfall model is the difficulty of
accommodating change after the process is underway. In principle, a
phase has to be complete before moving onto the next phase.
► Inflexible partitioning of the project into distinct stages makes it
difficult to respond to changing customer requirements.
► Therefore, this model is only appropriate when the requirements are
well-understood and changes will be fairly limited during the design
process.
► Few business systems have stable requirements.
► The waterfall model is mostly used for large systems engineering
projects where a system is developed at several sites.
► In those circumstances, the plan-driven nature of the waterfall model
helps coordinate the work.
 Incremental development
► Incremental development is
based on the idea of
► developing an initial
implementation,
► getting feedback from
users and others, and
► evolving the software
through several
versions until the
required system has
been developed
► Specification, development and
validation activities are
interleaved rather than
separate, with rapid feedback
across activities.
Incremental development

► It can be either plan-driven or agile or sometimes, a mixture of both.

► It is the fundamental part of agile development methods.
► It is better than waterfall approach for systems whose requirements
are likely to change during the development process.
► business, e-commerce systems and software products

► Generally, the early increments of the system include the most

important or most urgently required functionality.
► The customer can evaluate the system at a relatively early stage in the
development to see if it delivers what is required. If not, then only the
current increment has to be changed and possibly new functionality
defined for later increments.
 Incremental development benefits

► The cost of accommodating requirements changes is reduced.

► The amount of analysis and documentation that has to be redone is much
less than is required with the waterfall model.

► It is easier to get customer feedback on the development work that

has been done.
► Customers can comment on demonstrations of the software and see how
much has been implemented.

► More rapid delivery and deployment of useful software to the

customer is possible, even if all of the functionality has not been included.
► Customers are able to use and gain value from the software earlier than is
possible with a waterfall process.
Incremental development problems

► The process is not visible.

► Managers need regular deliverables to measure progress.
► If systems are developed quickly, it is not cost-effective to produce
documents that reflect every version of the system.

► System structure tends to degrade as new increments are added.

► As new functionality is added in whatever way is possible, regular change
leads to structural degradation and general code messiness.
► It becomes very difficult and costly to add new features to a system.
► To reduce this, you should regularly refactor (improve and restructure)
the software.
Integration and Configuration

► Based on software reuse where systems are integrated from

existing components or application systems (sometimes called
COTS -Commercial-off-the-shelf systems).
► Reused elements may be configured to adapt their behaviour and
functionality to a user’s requirements
► Reuse is now the standard approach for building many types of
business system.
Types of reusable software

► Stand-alone application systems (sometimes called COTS) that

are configured for use in a particular environment.

► Collections of objects that are developed as a package to be

integrated with a component framework such as .NET or J2EE.

► Web services that are developed according to service standards

and which are available for remote invocation.
Reuse-oriented software engineering

► Requirements specification
► Software discovery and evaluation
► Requirements refinement
► Application system configuration
► Component adaptation and integration
 Key process stages

► Requirements specification
► It includes brief descriptions of essential requirements and
desirable system features.

► Software discovery and evaluation

► Given an outline of the software requirements, a search is made for
components and systems that provide the functionality required.
► Candidate components and systems are evaluated to see if they
meet the essential requirements
 Key process stages

► Requirements refinement
► The requirements are modified to reflect the available components
and applications and the system specification is re-defined.
► Application system configuration
► If an off-the-shelf application system that meets the requirements
is available, it may then be configured for use to create the new
system.
► Component adaptation and integration
► If there is no off-the-shelf system, individual reusable components
may be modified and new components developed. These are then
integrated to create the system.
Advantages and disadvantages

► Reduced costs and risks as less software is developed from

scratch
► Faster delivery and deployment of system
► But requirements compromises are inevitable so system may not
meet real needs of users
► Loss of control over evolution of reused system elements
Process activities
Process activities

► The four basic process activities of specification,

development (design and implementation), validation
and evolution are organized differently in different
development processes.
► In the waterfall model, they are organized in sequence, whereas in
incremental development they are inter-leaved.
Software specification/Requirements Engineering

► It is the process of understanding and defining what services are

required from the system and identifying the constraints on the
system’s operation and development.
► It is a critical stage of the software process as mistakes made at this stage
inevitably lead to later problems in system design and implementation.

► Requirements Engineering process produces an agreed requirements

document that specifies stakeholder requirements (at two levels):
► End users and customers need a high level statement of the requirements;
► System developers need a more detailed system specification.
The requirements engineering process
Software specification/Requirements Engineering

► Feasibility study
► To assess whether or not there is a need or a market for the software and
whether or not it is technically and financially realistic to develop the
software required.
► Make the decision of whether or not to go ahead with a more detailed
analysis
► Requirements elicitation and analysis
► What do the system stakeholders require or expect from the system?
► Observations from existing systems, discussions with potential users, task
analysis etc.
► This may involve the development of one or more models and prototypes
Software specification
► Requirements specification
► It is the activity of translating the information gathered during the
analysis activity into a document
► Two types of requirements
► User requirements : abstract statements of the system requirements
for the customer and end user of the system.
► System requirements : a more detailed description of the
functionality to be provided.
► Requirements validation
► Checking the validity of the requirements (consistency,
completeness etc.)
Software design and implementation

► The process of converting the system specification into an

executable system.
► Software design
► Design a software structure that realises the specification;
► Implementation
► Translate this structure into an executable program;
► The activities of design and implementation are closely related and may be
inter-leaved.
Software Design - A general model of the design process
Software design - output

► A software design is a description of

► the structure of the software to be implemented,
► the data models and structures used by the system,
► the interfaces between system components
► the algorithms used.
 Software design - inputs
► Software platform - the environment in which software will execute. It
includes the operating system, database, middleware, and other
application systems
► It is an essential input to the design process, as designers must decide how
best to integrate it with the software’s environment.

► The requirement specification is the description of the functionality of

the system and its performance and dependability requirements.

► data description must be an input to the design process so that the

system data organization to be defined.
Software design - Activities

► Architectural design, where you identify the overall structure of the

system, the principal components (sometimes called sub-systems or
modules), their relationships and how they are distributed.

► Interface design, where you define the interfaces between system

components. This interface specification must be unambiguous.

► Component selection & design, where you search for reusable

components and, if not available, design new software components.

► Database design, where you design the system data structures and
how these are to be represented in a database. Depends on whether an
existing database is to be reused or a new database is to be created.
System implementation

► The software is implemented either by developing a program /

programs or by configuring an application system.
► Design and implementation are interleaved activities for most
types of software system.
► Programming is an individual activity with no standard process.
► Normally, programmers carry out some testing of the code they
have developed.
► Debugging is the activity of finding (locating) program faults and
correcting these faults.
Software validation

► Verification and validation (V & V) is intended to show that a

system conforms to its specification and meets the expectations
of the system customer.
► Testing is the principal validation technique.
► System testing involves executing the system with test cases that
are derived from the specification of the real data to be
processed by the system.
► Validation also involves checking processes, such as inspections
and reviews.
 Stages of testing

► Component testing
► Individual components are tested independently; (component defects are
discovered early in the process)
► Components may be functions or objects or modules.
► System testing
► Testing of the system as a whole. (interface problems are found when the system
is integrated)
► Customer testing
► Testing with customer data to check that the system meets the customer’s needs.
Testing phases in a plan-driven software process (V - model of
development)
Testing phases in a plan-driven software process (V - model of
development)

► Test plans are developed from the system specification and design.
► The figure shows how test plans are the link between testing and
development activities.
► This is sometimes called the V-model of development (turn it on
its side to see the V).
► The V-model shows the software validation activities that
correspond to each stage of the waterfall process model.
Software evolution

► Software is inherently flexible and can change.

► As requirements change through changing business
circumstances, the software that supports the business must
also evolve and change.
► Although there has been a demarcation between development
and evolution (maintenance) this is increasingly irrelevant as
fewer and fewer systems are completely new.
Software evolution
Coping with change

► Change is inevitable in all large software projects.

► Business changes lead to new and changed system requirements
► New technologies open up new possibilities for improving
implementations
► Changing platforms require application changes
► Change leads to rework so the costs of change include both
rework (e.g. re-analyzing requirements) as well as the costs of
implementing new functionality
 Reducing the costs of rework
► Change anticipation, where the software process includes
activities that can anticipate possible changes before significant
rework is required.
► For example, a prototype system may be developed to show some key
features of the system to customers.

► Change tolerance, where the process is designed so that changes

can be accommodated at relatively low cost.
► This normally involves some form of incremental development. Proposed
changes may be implemented in increments that have not yet been
developed. If this is impossible, then only a single increment (a small part
of the system) may have be altered to incorporate the change.
Two ways of coping with change and changing system requirements

► System prototyping, where a version of the system or part of the

system is developed quickly to check the customer’s requirements and
the feasibility of design decisions. This is a method of change
anticipation as it allows users to experiment with the system before
delivery and so refine their requirements. The number of
requirements change proposals made after delivery is therefore likely
to be reduced.
► Incremental delivery, where system increments are delivered to the
customer for comment and experimentation. This supports both
change avoidance and change tolerance. It avoids the premature
commitment to requirements for the whole system and allows changes
to be incorporated into later increments at relatively low cost.
Software prototyping

► A prototype is an initial version of a system used to demonstrate

concepts, try out design options, and find out more about the
problem and its possible solutions.
► A prototype can be used in:
► The requirements engineering process to help with
requirements elicitation and validation;
► In design processes to explore particular software solutions and
to develop a UI design;
► In the testing process to run back-to-back tests.
Benefits of prototyping

► Improved system usability.

► A closer match to users’ real needs.
► Improved design quality.
► Improved maintainability.
► Reduced development effort.
The process model for prototype development
 Prototype development process

Establish Prototype objectives

► 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, or
► to develop a system to demonstrate the application to
managers.
► The same prototype usually cannot meet all objectives.
 Prototype development process

Define Prototype Functionality

► 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.
► Focus on functional requirements rather than non-functional
requirements such as reliability, security, response time and
memory utilization.
► Error checking and recovery may not be included.
 Prototype development process

Develop Prototype
► May be based on rapid prototyping languages or tools
► Prototype should focus on areas of the product that are not
well-understood.

Evaluate Prototype
► The final stage of the process is prototype evaluation.
► Provision must be made during this stage for user training, and
the prototype objectives should be used to derive a plan for
evaluation.
► Potential users can discover requirements errors and omissions.
Incremental development and delivery
► Rather than deliver the system as a single delivery, the development and
delivery is broken down into increments with each increment delivering part
of the required functionality.
► Incremental development
► Develop the system in increments and evaluate each increment before
proceeding to the development of the next increment;
► Normal approach used in agile methods;
► Evaluation done by user/customer proxy.
► Incremental delivery
► Deploy an increment for use by end-users;
► More realistic evaluation about practical use of software;
► Difficult to implement for replacement systems as increments have less
functionality than the system being replaced.
Incremental delivery
 Incremental development and delivery

► Is an approach to software development where some of the developed increments are

delivered to the customer and deployed for use in their working environment.
► In an incremental delivery process ,the customer identify the services to be provided by
the system.
► They identify which services are most/less important.
► User requirements are prioritised and the highest priority requirements are included in
early increments.
► Once the development of an increment is started, the requirements are frozen though
requirements for later increments can continue to evolve.
► Once an increment is completed and delivered, customers can put into service. This
means that they take early delivery of part of the system functionality.
► They can experiment with the system and helps to clarify their requirements for later
system increments.
► As new increments are completed ,they are integrated with the existing increments so
that functionality improves with each delivered increment.
Incremental delivery advantages

► Customers do not have to wait until the entire system is

delivered before they can gain value from it. They can use the
software immediately as the first increment satisfies their most
critical requirements.
► Early increments act as a prototype to help elicit requirements
for later increments.
► Lower risk of overall project failure.
► The highest priority system services tend to receive the most
testing.
Incremental delivery problems

► Most systems require a set of basic facilities that are used by

different parts of the system.
► As requirements are not defined in detail until an increment is to
be implemented, it can be hard to identify common facilities that
are needed by all increments.
► The essence of iterative processes is that the specification is
developed in conjunction with the software.
► However, this conflicts with the procurement model of many
organizations, where the complete system specification is part of
the system development contract.
Boehm’s spiral model

► Process is represented as a spiral rather than as a sequence of

activities with backtracking.
► Each loop in the spiral represents a phase in the process.
► The innermost loop might be concerned with system feasibility,
next is requirement definition, system design,….
► No fixed phases such as specification or design - loops in the
spiral are not fixed; chosen depending on what is required.
► Each loop in the spiral is split into four sectors.
Boehm’s spiral model
 Spiral model sectors
► Objective setting
► Specific objectives for that particular phase are identified.
► Constraints on the process and the product are identified and a detailed
management plan is drawn up.
► Project risks are identified.
► Alternative strategies, depending on these risks, may be planned.
► Risk assessment and reduction
► Risks are assessed and activities are put in place to reduce the key risks.
► Development and validation
► A development model for the system is chosen which can be any of the generic
models.
► Planning
► The project is reviewed and the next phase of the spiral is planned.
Boehm’s spiral model

► The spiral model combines change avoidance with change

tolerance.
► It assumes that changes are a result of project risks and includes
explicit risk management activities to reduce these risks.
► Risks are explicitly assessed and resolved throughout the process.
Spiral model usage

► Spiral model has been very influential in helping people think

about iteration in software processes and introducing the
risk-driven approach to development.
► In practice, however, the model is rarely used as published for
practical software development.
Agile Software Development
Rapid software development

► Rapid development and delivery is now often the most important

requirement for software systems
► 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 whose aim
was to radically reduce the delivery time for working software
systems
 Agile development

► Program specification, design and implementation are inter-leaved

► 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.
► Focus on new releases of system with minimal documentation
► by using informal communications rather than formal meetings
Plan-driven and agile development
Plan-driven and agile development

► Plan-driven development
► Identifies separate development 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.
► Iteration occurs within activities.
► Agile development
► Specification, design, implementation and testing are inter-leaved
► Iteration occurs across activities.
► Therefore, the requirements and the design are developed together
rather than separately
Agile methods

► Plan-driven approaches involve a significant overhead in

planning, designing, and documenting the system.
► 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.
Agile methods

► These 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 philosophy behind agile methods is reflected in the agile
manifesto ([Link] issued by the leading
developers of these methods.
 Agile manifesto

► We are uncovering better ways of developing software by doing it

and helping others do it. Through this work we have come to
value:
► Individuals and interactions over processes and tools
► Working software over comprehensive documentation
► Customer collaboration over contract negotiation
► Responding to change over following a plan
► That is, while there is value in the items on the right, we value
the items on the left more
 The principles of agile methods

Principle Description
Customers should be closely involved throughout the development
process. Their role is to provide and prioritize new system
Customer involvement
requirements and to evaluate the iterations of the system.

The software is developed in increments with the customer specifying

Incremental delivery the requirements to be included in each increment.

The skills of the development team should be recognized and

People not process exploited. Team members should be left to develop their own ways of
working without prescriptive processes.
Expect the system requirements to change and so design the system
Embrace change to accommodate these changes.
Focus on simplicity in both the software being developed and in the
Maintain simplicity development process. Wherever possible, actively work to eliminate
complexity from the system.
 Agile method applicability

► Agile methods have been particularly successful for two kinds of

system development.
► Product development where a software company is developing a
small or medium-sized product for sale.

► 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 stakeholsers and regulations that affect the software.
Agile development techniques
Extreme programming

Extreme Programming (XP) is an agile software development

framework that aims to produce higher quality software, and higher
quality of life for the development team
 Extreme programming : XP release cycle

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.
Extreme programming was an agile practices that were
summarized and reflect the principles of the agile manifesto:
► 1. Incremental development is supported through small, frequent
releases of the system. Requirements are based on simple customer
stories or scenarios that are used as a basis for deciding what
functionality should be included in a system increment.
► 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.
► 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.
Extreme programming practices
 XP practices
► User stories:
► Software requirements always change. In Agile methods , requirements
elicitation is integrated with development by the idea of “user stories”
where a user story is a scenario of use that might be experienced by a
system user.
► After the discussion of development team with customer, 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.
► 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.
► Cons:
► 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.
Example
► Refactoring:
► Changes will always have to be made to the code being developed.
Refactoring means that the programming team look for possible
improvements to the software and implements them immediately.
► Refactoring improves the software structure and readability and avoids the
structural deterioration that naturally occurs when software is changed.
 Test-first development:
► The key features of testing in XP are:
1. test-first development:
► Write test before write the code.

2. Incremental test development from scenarios,

► Develop each tasks, so that the development schedule can be maintained.
3. User involvement in the test development and validation, and

4. The use of automated testing frameworks.

Pair programming:
► 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.
Pair programming has a number of advantages.
1. It supports the idea of collective ownership and responsibility for the
system.
2. It acts as an informal review process because each line of code is looked at
by at least two people.
3. It encourages refactoring to improve the software structure.
Agile Project Management

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.
It focuses on providing a framework for agile project organization.
Scrum Process
The Sprint Cycle

► 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. —the list of items such as product features, requirements, user stories and engineering
improvement that have to be worked on by the Scrum team.

► Each sprint cycle lasts a fixed length of time, which is usually between 2 and 4 weeks. At the beginning
of each cycle, the Product Owner prioritizes the items on the product backlog to define which are the
most important items to be developed in that cycle.
► Sprints are never extended to take account of unfinished work. Items are returned to the product
backlog if these cannot be completed within the allocated time for the sprint.
► The whole team is then involved in selecting which of the highest priority items they believe can be
completed. They then estimate the time required to complete these items. To make these estimates,
they use the velocity attained in previous sprints, that is, how much of the backlog could be covered in
a single sprint. This leads to the creation of a sprint backlog—the work to be done during that sprint.
► The team self-organizes to decide who will work on what, and the sprint begins.
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 and communicates with customers and
management outside of the team.
► The whole team attends short daily meetings (scrum)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, there is no top-down direction from the Scrum
► At the end of each sprint, there is a review meeting, which involves the whole team.
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 succeed.
► For offshore development, the product owner is in a different country from
the development team, which may also be distributed. Figure shows the
requirements for Distributed Scrum