Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
13 views

Introduction to Software Engineering & Programming (3)

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views

Introduction to Software Engineering & Programming (3)

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 73

INTRODUCTION TO

SOFTWARE ENGINEERING &


PROGRAMMING
DR. TIWALADE ODU
Objectives

• Introduction to the different software


development lifecycle (SDLC) phases used
in developing, delivering, and maintaining
software products.
• Acquisition of basic software development
skills.
• Understanding of common terminology used
in the software engineering field.
The notion of software engineering
was first proposed in 1968 at a
conference held to discuss what was
then called the software crisis.

It became clear that individual approaches to


program development did not scale up to large
and complex software systems. These were
unreliable, cost more than expected, and were
delivered late.

History of Throughout the 1970s and 1980s, a variety of


new software engineering techniques and

Software
methods were developed, such as structured
programming, information hiding, and object-
oriented development.
Engineering
Tools and standard notations were
developed which are the basis of
today’s software engineering.
Software engineering is essential for the
functioning of government, society, and
national and international businesses and
Introduction institutions.

Software systems are abstract and


intangible. They are not constrained by the
properties of materials, nor are they
governed by physical laws or by
manufacturing processes.

However, because of the lack of physical


constraints, software systems can quickly
become extremely complex, difficult to
understand, and expensive to change.
Introduction (Contd.)
• There are many different types of software system,
ranging from simple embedded systems to complex,
worldwide information systems.

• There are no universal notations, methods, or techniques


for software engineering because different types of
software require different approaches.

• There are still many reports of software projects going


wrong and of “software failures.”
Introduction (Contd.)
• There are still many reports of software projects going wrong and
of “software failures.”

• Increasing system complexity: As new software engineering techniques help


us to build larger, more complex systems, the demands change. Systems
have to be built and delivered more quickly; larger, even more complex
systems are required; and systems have to have new capabilities that were
previously thought to be impossible. New software engineering techniques
have to be developed to meet new the challenges of delivering more
complex software.

• Failure to use software engineering methods: It is fairly easy to write


computer programs without using software engineering methods and
techniques. Many companies have drifted into software development as their
products and services have evolved. They do not use software engineering
methods in their everyday work. Consequently, their software is often more
expensive and less reliable than it should be. We need better software
engineering education and training to address this problem.
Professional Software Development
• Lots of people write programs. People in business write
spreadsheet programs to simplify their jobs; scientists and
engineers write programs to process their experimental data;
hobbyists write programs for their own interest and enjoyment.

• However, most software development is a professional activity in


which software is developed for business purposes, for inclusion
in other devices, or as software products such as information
systems and computer-aided design systems.

• The key distinctions are that professional software is intended for


use by someone apart from its developer and that teams rather
than individuals usually develop the software. It is maintained
and changed throughout its life.
Professional Software Development (Contd.)
• Software engineering is intended to support professional
software development rather than individual programming.

• It includes techniques that support program specification,


design, and evolution, none of which are normally relevant
for personal software development.

• Software is not just the programs themselves but also all


associated documentation, libraries, support websites, and
configuration data that are needed to make these programs
useful.
Professional Software Development (Contd.)
• A professionally developed software system is often more
than a single program.

• A system may consist of several separate programs and


configuration files that are used to set up these programs.

• It may include system documentation, which describes the
structure of the system, user documentation, which
explains how to use the system, and websites for users to
download recent product information.

• This differentiates professional software development from


that of amateurs.
Software Engineering FAQs
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 should deliver the required functionality
good and performance to the user and should be maintainable,
software? dependable and usable.

What is software Software engineering is an engineering discipline that is


engineering? concerned with all aspects of software production from
initial conception to operation and maintenance.

What are the fundamental Software specification, software development, software


software engineering validation and software evolution.
activities?
Software Engineering FAQs
Question Answer
What is the difference between Computer science focuses on theory and fundamentals;
software engineering and software engineering is concerned with the practicalities of
computer science? developing and delivering useful software.

What is the difference between System engineering is concerned with all aspects of
software engineering and computer-based systems development including hardware,
system software and process engineering. Software engineering is
engineering? part of this more general process.

What are the key challenges Coping with increasing diversity, demands for reduced
facing software engineering? delivery times and developing trustworthy software.
What are the best software While all software projects have to be professionally
engineering techniques and managed and developed, different techniques are
methods? 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.
There are no methods and techniques that are good for
everything.
Professional Software Development (Contd.)
• Software engineers are concerned with developing
software products, that is, software that can be sold to
a customer.

• There are two kinds of software product:


• Generic products: These are stand-alone systems that are
produced by a development organization and sold on the open
market to any customer who is able to buy them. Examples?

• Customized (or bespoke) software: These are systems that are


commissioned by and developed for a particular customer.
Examples ?
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: Engineers make things work. They apply


theories, methods, and tools where these are appropriate. However,
they use them selectively and always try to discover solutions to
problems even when there are no applicable theories and methods.
Engineers also recognize that they must work within organizational
and financial constraints, and they must look for solutions within
these constraints.

• All aspects of software production: Software engineering is not


just concerned with the technical processes of software development.
It also includes activities such as software project management and
the development of tools, methods, and theories to support software
development.
Importance of Software Engineering
• Individuals and society are increasingly relying on
advanced software systems. Therefore there is a 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 professional
software systems rather than just write programs as a
personal programming project. Failure to use software
engineering method leads to higher costs for testing,
quality assurance, and long-term maintenance.
Essential Attributes of Good Software
• Acceptability: The developed software must be acceptable to the type of
users for which it is designed. This means that it must be understandable,
usable, and compatible with other systems that they use.

• Dependability and Security: Software dependability includes a range of


characteristics including reliability, security, and safety. Dependable
software should not cause physical or economic damage in the event of
system failure. The developed software has to be secure so that malicious
users cannot access or damage the system.

• Efficiency: The developed software should not make wasteful use of


system resources such as memory and processor cycles. Efficiency
therefore includes responsiveness, processing time, resource utilization,
etc.

• Maintainability: The developed software should be written in such a way


that it can evolve to meet the changing needs of customers. This is a
critical attribute because software change is an inevitable requirement of a
changing business environment.
Software Process
• A software process is a sequence of activities that leads
to the production of a software product. It is the
systematic approach that is used in software
engineering.

• Four fundamental activities are common to all software


processes.
Software Process (Contd.)
• 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.
Relationship between Software Engineering
and Computer Science
• Computer science is concerned with the theories and
methods that underlie computers and software
systems, whereas software engineering is concerned with
the practical problems of producing software.

• Some knowledge of computer science is essential for


software engineers in the same way that some knowledge
of physics is essential for electrical engineers.

• Computer science theory is often most applicable to


relatively small programs. Elegant theories of computer
science are rarely relevant to large, complex problems that
require a software solution.
Relationship between Software Engineering
and Systems Engineering
• System engineering is concerned with all aspects of
the development and evolution of complex
systems where software plays a major role.

• System engineering is therefore concerned with


hardware development, policy and process design, and
system deployment, as well as software engineering.

• System engineers are involved in specifying the


system, defining its overall architecture, and then
integrating the different parts to create the finished
system.
Software Engineering Diversity

• The most significant factor in determining which


software engineering methods and techniques are most
important is the type of application being developed.
Types of Application
• Stand-alone applications: These are application systems that run
on a personal computer or apps that run on a mobile device.
• They include all necessary functionality and may not need to be connected
to a network.
• Examples of such applications are office applications on a PC, CAD
programs, photo manipulation software, travel apps, productivity apps, etc.
• Interactive transaction-based applications: These are applications
that execute on a remote computer and that are accessed by
users from their own computers, phones, or tablets.
• These also include web applications such as e-commerce applications where
you interact with a remote system to buy goods and services.
• This class of application also includes business systems, where a business
provides access to its systems through a web browser or special-purpose
client program and cloud-based services, such as mail and photo sharing.
• Interactive applications often incorporate a large data store that is accessed
and updated in each transaction.
Types of Application (Contd.)
• Embedded control systems: These are software control
systems that control and manage hardware devices.
• Numerically, there are probably more embedded systems than
any other type of system.
• Examples of embedded systems include the software in a
mobile (cell) phone, software that controls antilock braking in a
car, and software in a microwave oven to control the cooking
process.
• Batch processing systems: These are business systems
that are designed to process data in large batches. They
process large numbers of individual inputs to create
corresponding outputs.
• Examples of batch systems are periodic billing systems, such as
phone billing systems, and salary payment systems.
Types of Application (Contd.)
• Entertainment systems: These are systems for personal use
that are intended to entertain the user.
• Most of these systems are games which may run on special-purpose
console hardware.
• The quality of the user interaction offered is the most important
distinguishing characteristic of entertainment systems.

• 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.
• These are often computationally intensive and require high-
performance parallel systems for execution.
Types of Application (Contd.)
• Data collection and analysis systems: These are systems that
collect data from their environment and send that data to
other systems for processing.
• The software may have to interact with sensors and often is installed
in a hostile environment such as inside an engine or in a remote
location.
• “Big data” analysis may involve cloud-based systems carrying out
statistical analysis and looking for relationships in the collected data.
• Systems of systems: These are systems, used in enterprises
and other large organizations, that are composed of a number
of other software systems.
• Some of these may be generic software products, such as an ERP
system.
• Enterprise resource planning (ERP) is a software system that runs an entire
business, supporting automation and processes in finance, human resources,
manufacturing, supply chain, services, procurement, e.t.c.
Software Engineering Ethics
• Like other engineering disciplines, software engineering is
carried out within a social and legal framework that limits the
freedom of people working in that area.
• A software engineer must accept that his job involves
broader responsibilities than applying technical skills.
• He must also behave ethically and morally responsible if he
is to be respected as a professional engineer.
• He should uphold the standards of honesty and integrity.
• He should not use his skills and abilities to behave in a
dishonest way or in a way that will bring disrepute to the
software engineering profession.
Software Engineering Ethics (Contd.)
• Areas where standards of acceptable behaviour are not bound by laws
but by the more tenuous notion of professional responsibility include:

• Confidentiality: He should respect the confidentiality of his employers or


clients regardless of whether a formal confidentiality agreement has been
signed.

• Competence: He should not misrepresent your level of competence. He should


not knowingly accept work that is outside his competence.

• Intellectual Property Rights: He should be aware of local laws governing the use of
intellectual property, such as patents and copyrights. He should be careful
to protect the intellectual property of his employers and clients.

• Computer Misuse: He should not use his technical skills to misuse other
people’s computers. Computer misuse ranges from relatively trivial (game
playing on an employer’s machine) to extremely serious (disseminating
viruses or other malware).
Software Processes
• A software process is a set of related activities that
leads to the production of a software system.

• The process used in different organisations depends


on the type of software being developed, the
requirements of the software customer, and the
skills of the people writing the software.

• The different software processes must all include, in


some form, the four fundamental software
engineering activities – software specification, software
development, software validation and software evolution.
Software Process Models
• A software process model (sometimes called a Software
Development Life Cycle or SDLC model) is a simplified
representation of a software process.
Software Process
Models (Contd.)
• The Waterfall Model
• The first published model of
the software development
process was derived from
engineering process models
used in large military systems
engineering.
• It presents the software • The waterfall model is an example of a plan-
development process in driven process.
several stages. • All the process activities are planned and
scheduled before starting software
• Because of the cascade from development.
one phase to another, this
model is known as the
waterfall model or software life
cycle.
The Waterfall Model (Contd.)
• The stages of the waterfall model directly reflect the fundamental
software development activities:
• 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 system specifications.

• System And Software Design: The systems design process allocates the requirements to
either hardware or software systems. It establishes an overall system
architecture. Software design involves identifying and describing the fundamental
software system abstractions and their relationships.

• Implementation And Unit Testing: The software design is realised as a set of programs
or program units during this stage. Unit testing involves verifying that each unit
meets its specifications.

• Integration And System Testing: The individual program units or programs are
integrated and tested as a complete system to ensure 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 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.
The Waterfall Model (Contd.)
• In principle, the result of each phase in the waterfall model is
one or more approved documents (“signed off”). The
following phase should not start until the previous phase has
finished.
• For hardware development, where high manufacturing costs
are involved, this makes sense. However, for software
development, these stages overlap and feed information to
each other.
• During design, problems with requirements are identified;
during coding, design problems are found, and so on.
• The software process, in practice, is never a simple linear
model but involves feedback from one phase to another.
The Waterfall Model (Contd.)
• The need for early commitment and system rework when changes
are made means that the waterfall model is only appropriate for
some types of systems:
• Embedded systems, where the software has to interface with hardware
systems. Because of the inflexibility of hardware, it is not usually possible
to delay decisions on the software’s functionality until it is implemented.

• Critical systems, where there is a need for extensive safety and security
analysis of the software specification and design. The specification and
design documents must be complete in these systems to make this analysis
possible. Safety-related problems in the specification and design are usually
costly to correct at the implementation stage.

• Large software systems that are part of broader engineering systems


developed by several partner companies. The hardware in the systems may
be developed using a similar model, and companies find it easier to use a
common model for hardware and software. Furthermore, where several
companies are involved, complete specifications may be needed to allow for
the independent development of different subsystems.
Software Process
Models (Contd.)
• Incremental Development
• Incremental development is
based on the idea of
developing an initial
implementation, getting
feedback from users and • It is now the most common approach for
others, and evolving the developing application systems and software
software through several products.
versions until the required • This approach can be either plan-driven, agile
system has been developed or, more usually, a mixture of these
approaches.
• Specification, development, • In a plan-driven approach, the system
and validation activities are increments are identified in advance; if an agile
interleaved rather than approach is adopted, the early increments are
separate, with rapid feedback identified. However, the development of later
increments depends on progress and customer
across activities. priorities.
Incremental Development (Contd.)
• Incremental software development, a fundamental part of
agile development methods, is better than a waterfall
approach for systems whose requirements are likely to
change during development.
• This is the case for most business systems and software
products.
• Incremental development reflects the way that we solve
problems. We rarely work out a complete problem solution in
advance but move toward a solution in a series of steps,
backtracking when we realise we have made a mistake.
• By developing the software incrementally, it is cheaper and
easier to make changes in the software as it is being
developed.
Incremental Development (Contd.)
• Incremental development has three significant advantages
over the waterfall model:
• The cost of implementing requirements changes is reduced. The
amount of analysis and documentation that has to be redone is
significantly 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 software
demonstrations and see how much has been implemented.
Customers find it difficult to judge progress from software design
documents.

• Early delivery and deployment of useful software to the customer is


possible, even if all of the functionality has not been included.
Customers can use and gain value from the software earlier than is
possible with a waterfall process.
Incremental Development (Contd.)
• The incremental approach has two problems:
• The process is not visible. Managers need regular deliverables to
measure progress. If systems are developed quickly, producing
documents that reflect every system version is not cost-effective.

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


Regular change leads to messy code as new functionality is added in
any way possible. It becomes increasingly difficult and costly to add
new features to a system. To reduce structural degradation and
general code messiness, agile methods suggest that you should
regularly refactor (improve and restructure) the software.
Software Process
Models (Contd.)
• Integration and Configuration
• In many software projects,
there is some software reuse.
• This often happens informally • Reuse-oriented approaches rely on a base of
reusable software components and an integrating
when people working on the framework for the composition of these
project know of or search for components.
code similar to what is
required. They look for these,
modify them as needed, and
integrate them with the new
code that they have developed.
Integration and Configuration (Contd.)
• Three types of software components are frequently reused:
• Stand-alone application systems that are configured for use in a
particular environment.
• These systems are general-purpose systems with many features, but they
must be adapted for use in a specific application.

• Collections of objects developed as a component or a package to be


integrated with a component framework such as the Java Spring
framework.

• Web services developed according to service standards and


available for remote invocation over the Internet.
Integration and Configuration (Contd.)
• The stages in this process are:
• Requirements Specification: The initial requirements for the system are
proposed. These do not have to be elaborated in detail but should
include 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 and if they are generally suitable for use in the
system.
Integration and Configuration (Contd.)
• The stages in this process are:

• Requirements Refinement: During this stage, the requirements are refined


using information about the reusable components and applications that
have been discovered. The requirements are modified to reflect the
available components, and the system specification is re-defined. Where
modifications are impossible, the component analysis activity may be
reentered to search for alternative solutions.

• Application System Configuration: If an off-the-shelf application system that


meets the requirements is available, it may be configured to create the
new system.

• Component Adaptation and Integration: If no off-the-shelf system exists,


individual reusable components may be modified and new components
developed. These are then integrated to create the system.
Integration and Configuration (Contd.)
• Reuse-oriented software engineering, based on
configuration and integration, has the obvious advantage of
reducing the amount of software to be developed and
reducing cost and risks.
• It usually also leads to faster delivery of the software.
• However, requirements compromises are inevitable, which
may lead to a system that does not meet the real needs of
users.
• Furthermore, some control over the system evolution is lost
as new versions of the reusable components are not under
the control of the organisation using them.
Process Activities - Software Specification
• Software specification or requirements engineering 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.
• Requirements engineering is a particularly critical stage of
the software process, as mistakes made at this stage
inevitably lead to later problems in the system design and
implementation.
• Before the requirements engineering process starts, a
company may carry out a feasibility or marketing 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.
Software
Specification (Contd.)
• Feasibility studies are short-
term, relatively cheap studies
that inform the decision of
whether or not to go ahead
with a more detailed analysis.
• The requirements engineering
process aims to produce an
agree requirements document
that specifies a system
satisfying stakeholder
requirements.
• Requirements are usually
presented at two levels of
detail.
• End-users and customers need a high-
level statement of the requirements;
• System developers need a more
detailed system specification.
Software Specification (Contd.)
• There are three main activities in the requirements engineering
process:
• Requirements Elicitation and Analysis: This is the process of
deriving the system requirements through observation of existing
systems, discussions with potential users and procurers, task
analysis, and so on.
• This may involve the development of one or more system models and
prototypes.
• These help to understand the system to be specified.
• Requirements Specification: Requirements specification is the
activity of translating the information gathered during
requirements analysis into a document that defines a set of
requirements.
• Two types of requirements may be included in this document.
• User requirements are abstract statements of the system requirements for the
customer and end-user of the system;
• System requirements are a more detailed description of the functionality to be
provided.
Software Specification (Contd.)
• Requirements Validation: This activity checks the
requirements for realism, consistency, and completeness.
• During this process, errors in the requirements document are
inevitably discovered. It must then be modified to correct these
problems.
Process Activities - Software Design and
Implementation
• The implementation stage of software development is the
process of developing an executable system for delivery
to the customer.
• 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 and, sometimes, the algorithms
used.
• Designers do not arrive at a finished design immediately
but develop the design in stages. They add detail asthey
develop their design, with constant backtracking to
modify earlier designs.
Software Design and
Implementation (Contd.)
• The general model of the
design process is an
abstract model of the
design process showing
the inputs to the design
process, process
activities, and the process
outputs.
• The design process
activities are both
interleaved and
A general model of the design process
interdependent.
Software Design and Implementation (Contd.)
• Four activities that may be part of the design process for
information systems:
• Architectural Design, where the overall structure of the
system, the principal components (sometimes called
subsystems or modules), their relationships, and how they
are distributed, are identified.
• Database Design, where the system data structures and
how these are to be represented in a database, are
designed.
• Interface Design, where the interfaces between system
components are defined.
• Component Selection and Design, where reusable
components are sought and, if no suitable components
are available, new software components are designed.
Process Activities - Software Validation
• Software validation or, more generally, verification and
validation (V & V) is intended to show that a system
both conforms to its specification and meets the
expectations of the system customer.
• Program testing, where the system is executed using
simulated test data, is the principal validation
technique.
• Validation may also involve checking processes, such
as inspections and reviews, at each stage of the
software process from user requirements definition to
program development.
Software Validation (Contd.)
• The figure shows a three-
stage testing process in
which system components
are individually tested, then
the integrated system is
tested.
• For custom software, Stages of Testing
customer testing involves
testing the system with real
customer data.
• For products that are sold as
applications, customer
testing is sometimes called
beta testing where selected
users try out and comment
on the software.
Software Validation (Contd.)
• The stages in the testing process are:
• Component Testing: The components making
up the system are tested by the people
developing the system.
• Each component is tested independently,
without other system components. Components
may be simple entities such as functions or
object classes or may be coherent groupings of
these entities.
• Test automation tools, such as JUnit for Java,
that can rerun tests when new versions of the
component are created, are commonly used
Software Validation (Contd.)
• System Testing: System components are
integrated to create a complete system.
• This process is concerned with finding errors that
result from unanticipated interactions between
components and component interface problems.
• It is also concerned with showing that the system
meets its functional and non-functional
requirements and testing the emergent system
properties.
Software Validation (Contd.)
• Customer Testing: This is the final stage in
the testing process before the system is
accepted for operational use.
• The system is tested by the system customer
(or potential customer) rather than with
simulated test data.
Process Activities - Software Evolution
• The flexibility of software is one of the main reasons why
more and more software is being incorporated into large,
complex systems.
• Historically, there has always been a split between the
process of software development and the process of
software evolution (software maintenance).
• Software development is considered as a creative activity
in which a software system is developed from an initial
concept through to a working system while software
maintenance is seen as dull and uninteresting.
• This distinction between development and maintenance is
increasingly blurry.
Software Evolution (Contd.)
• Rather than two separate processes, it is more realistic to
think of software engineering as an evolutionary process
where software is continually changed over its lifetime in
response to changing requirements and customer needs.

Software System Evolution


Coping with change
• Rapid software development and delivery are essential
for rapidly changing requirements in business systems.
• Rapid software development is known as agile
development or agile methods.
• These methods are designed to produce useful software
quickly.
• The following characteristics are common to all agile
methods:
Agile Software Development
• The processes of specification, design and implementation
are interleaved.
• There is no detailed system specification, and design
documentation is minimized or generated automatically by the
programming environment used to implement the system.
• The system is developed in a series of increments.
• End-users and other system stakeholders are involved in
specifying and evaluating each increment.
• They may propose changes to the software and new requirements
that should be implemented in a later version of the system.
• Extensive tool support is used to support the development
process.
AGILE
SOFTWARE
DEVELOPMENT

58
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
whose aim was to radically reduce the delivery time for
working software systems
AGILE DEVELOPMENT
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.
Minimal documentation – focus on working code

60
PLAN-DRIVEN
AND AGILE
DEVELOPMENT

61
PLAN-DRIVEN AND AGILE
DEVELOPMENT
Plan-driven development
 A plan-driven approach to software engineering is based on
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.
AGILE METHODS
Dissatisfaction with the overheads involved in software design
methods of the 1980s and 1990s led to the creation of 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 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.

63
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.
64
THE PRINCIPLES OF AGILE METHODS
Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.
65
AGILE METHOD APPLICABILITY
▪Product development where a software company is
developing a small or medium-sized product for sale.
 Virtually all software products and apps are now developed using an
agile approach
▪Custom system development within an organization,
where there is a clear commitment from the customer
to become involved in the development process and
where there are few external rules and regulations that
affect the software.
66
AGILE DEVELOPMENT
TECHNIQUES
67
A very influential agile method,
developed in the late 1990s, that
introduced a range of agile
development techniques.
Extreme Programming (XP) takes an
‘extreme’ approach to iterative
EXTREME development.
PROGRAMMING  New versions may be built several times per
day;
 Increments are delivered to customers every 2
weeks;
 All tests must be run for every build and the
build is only accepted if tests run successfully.

68
THE EXTREME
PROGRAMMING RELEASE
CYCLE
69
EXTREME PROGRAMMING PRACTICES (A)
Principle or practice Description
Incremental planning Requirements are recorded on story cards and 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’.
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.
Simple design Enough design is carried out to meet the current requirements and no
more.
Test-first development An automated unit test framework is used to write tests for a new piece
of functionality before that functionality itself is implemented.
Refactoring All developers are expected to refactor the code continuously as soon as
possible code improvements are found. This keeps the code simple and
maintainable.
70
EXTREME PROGRAMMING PRACTICES (B)
Pair programming Developers work in pairs, checking each other’s work and providing
the support to always do a good job.
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 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 be passed.
Sustainable pace Large amounts of overtime are not considered acceptable as the net
effect is often to reduce code quality and medium-term productivity

On-site customer A representative of the end-user of the system (the customer) should
be available full time for the use of the XP team. In an extreme
programming process, the customer is a member of the development
team and is responsible for bringing system requirements to the team
for implementation.

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

72
INFLUENTIAL XP PRACTICES
Extreme programming has a technical focus and is not
easy to integrate with management practice in most
organizations.
Consequently, while agile development uses practices
from XP, the method as originally defined is not widely
used.
Key practices
 User stories for specification
 Refactoring
 Test-first development
 Pair programming

73

You might also like