1

Chapter 1

Software Engineering

Sem 3 & 4 2017

Mrs. Siti Nurliana Jamali

[email protected]
 2

Chapter 1 – Introduction
 3

Topics covered
Introduction to Software Engineering
Software process models
Iterative Process
Activity process
The Rational Unified Process
 An example of a modern software process.
 4

Introduction to Software Engineering

The economies of ALL developed nations are
dependent on software.
More and more systems are software controlled
Software engineering is concerned with
theories, methods and tools for professional
software development.
Costs on software represents a significant
portion of GNP in all developed countries.
 5

Software costs
Software costs often dominate computer system
costs. The costs of software on a PC are often
greater than the hardware cost.
Software costs more to maintain than it does to
develop. For systems with a long life,
maintenance costs may be several times
development costs.
Software engineering is concerned with cost-
effective software development.
 6

Software products
Generic products
 Stand-alone systems that are marketed and sold to
any customer who wishes to buy them.
 Examples – PC software such as graphics programs,
project management tools; CAD software; software for
specific markets such as appointments systems for
dentists.
Customized products
 Software that is commissioned by a specific customer
to meet their own needs.
 Examples – embedded control systems, air traffic
control software, traffic monitoring systems.
 7

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.
 8

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.
 9

Frequently asked questions about

software engineering
Question Answer
What are the key challenges facing Coping with increasing diversity, demands for reduced
software engineering? delivery times and developing trustworthy software.
What are the costs of software Roughly 60% of software costs are development costs,
engineering? 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
techniques and methods? managed 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
software engineering? and the possibility of developing highly distributed service-
based systems. Web-based systems development has led
to important advances in programming languages and
software reuse.
 10

Essential attributes of good software

Product characteristic Description

Maintainability 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
because software change is an unavoidable requirement of a
changing business environment.
Dependability and Software dependability includes a range of characteristics
security including reliability, security and safety. Dependable software
should not cause physical or economic damage in the event of
system failure. Malicious users should not be able to access or
damage the system.
Efficiency Software should not make wasteful use of system resources such
as memory and processor cycles. Efficiency therefore includes
responsiveness, processing time, memory utilisation, etc.

Acceptability 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.
 11

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, tools and methods to solve
problems bearing in mind 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.
 12

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.
 13

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 to be connected to a network.
Interactive transaction-based applications
 Applications that execute on a remote computer and are
accessed by users from their own PCs or terminals. These
include web applications such as e-commerce applications.
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.
 14

Application types (cont.)

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.
Entertainment systems
 These are systems that are primarily for personal use
and which are intended to entertain the user.
Systems for modelling and simulation
 These are systems that are developed by scientists
and engineers to model physical processes or
situations, which include many, separate, interacting
objects.
 15

Application types (cont.)

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.
 16

The Software Process

A structured set of activities required to develop a
software system.
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.
A software process model is an abstract representation
of a process. It presents a description of a process from
some particular perspective.
 17

Software Process Descriptions

When we describe and discuss processes, we
usually talk about the activities in these processes
such as specifying a data model, designing a user
interface, etc. and the ordering of these activities.
Process descriptions may also include:
 Products, which are the outcomes of a process
activity;
 Roles, which reflect the responsibilities of the people
involved in the process;
 Pre- and post-conditions, which are statements that
are true before and after a process activity has been
passed or a product produced.
 18

Plan-driven and agile processes

Plan-driven processes are processes where all
of the process activities are planned in advance
and progress is measured against this plan.
In agile processes, planning is incremental and
it is easier to change the process to reflect
changing customer requirements.
In practice, most practical processes include
elements of both plan-driven and agile
approaches.
There are no right or wrong software processes.
 19

Software Process Models

The waterfall model
 Plan-driven model. Separate and distinct phases of
specification and development.
Incremental development
 Specification, development and validation are added. May
be plan-driven or agile.
Reuse-oriented software engineering
 The system is assembled from existing components. May
be plan-driven or agile.
In practice, most large systems are developed using a
process that incorporates elements from all of these models.
 20

The Waterfall Model

 21

Waterfall Model Phases

There are separate identified phases in the waterfall
model:
 Requirements analysis and definition
 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance
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.
 22

Waterfall Model Problems

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.
 23

Incremental Development
 24

Incremental Development Benefits

The cost of accepting changing customer requirements
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.
 Customers are able to use and gain value from the
software earlier than is possible with a waterfall process.
 25

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.
 Unless time and money is spent on refactoring to
improve the software, regular change tends to
corrupt its structure. Incorporating further software
changes becomes increasingly difficult and costly.
 26

Reuse-oriented Software Engineering

Based on systematic reuse where systems are
integrated from existing components or COTS
(Commercial-off-the-shelf) systems.
Process stages
 Component analysis;
 Requirements modification;
 System design with reuse;
 Development and integration.
Reuse is now the standard approach for
building many types of business system.
 27

Reuse-oriented Software Engineering

 28

Types of Software Component

Web services that are developed according to
service standards and which are available for
remote invocation.
Collections of objects that are developed as a
package to be integrated with a component
framework such as .NET or J2EE.
Stand-alone software systems (COTS) that are
configured for use in a particular environment.
 29

Iterative Process
• 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
Iterative process models:
Software prototyping
Boehm’s spiral model
 30

Software Prototyping

A prototype is an initial version of a system used

to demonstrate concepts and try out design
options.
A prototype can be used in:
 The requirements engineering process to help
with requirements elicitation and validation;
 In design processes to explore options and
develop a UI design;
 In the testing process to run back-to-back tests.
 31

Benefits of prototyping
Improved system usability.
A closer match to users’ real needs.
Improved design quality.
Improved maintainability.
Reduced development effort.
 32

The Process of Prototype Development

 33

Prototype Development
May be based on rapid prototyping languages
or tools
May involve leaving out functionality
 Prototype should focus on areas of the product
that are not well-understood;
 Error checking and recovery may not be included
in the prototype;
 Focus on functional rather than non-functional
requirements such as reliability and security
 34

Throw-away Prototypes
Prototypes should be discarded after
development as they are not a good basis for a
production system:
 It may be impossible to tune the system to meet
non-functional requirements;
 Prototypes are normally undocumented;
 The prototype structure is usually degraded
through rapid change;
 The prototype probably will not meet normal
organisational quality standards.
 35

Incremental 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.
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.
 36

Incremental Development and Delivery

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.
 37

Incremental Delivery
 38

Incremental Delivery Advantages

Customer value can be delivered with each
increment so system functionality is available
earlier.
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.
 39

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.
 40

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.
No fixed phases such as specification or design
- loops in the spiral are chosen depending on
what is required.
Risks are explicitly assessed and resolved
throughout the process.
 41

Boehm’s Spiral Model of the Software

Process
 42

Spiral Model Sectors

Objective setting
 Specific objectives for the phase are identified.
Risk assessment and reduction
 Risks are assessed and activities 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.
 43

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.
 44

The Rational Unified Process (RUP)

• Team-Unifying Approach
The RUP unifies a software team by providing a common view of
the development process and a shared vision of a common goal
• Increased Team Productivity
▫ knowledge base of all processes
▫ view of how to develop software Tool
▫ modeling language Specialist
▫ Rational provides many tools Architect
Developer
Project
Management

Analyst Designer Tester

 45

What is a Workflow?
• A set of activities that is performed by the
various roles in a project
• Describes a meaningful sequence of activities
that produce a useful result (an artifact)
• Shows interaction between roles
 46

Workflows - 3 Key Elements

• Three key elements of each workflows:
▫ Artifacts
▫ Roles
▫ Activities
• Workflow Detail: Prepare Environment for Project
 47

THE RATIONAL UNIFIED PROCESS

(RUP)
A modern generic process derived from the
work on the UML and associated process.
Brings together aspects of the 3 generic
process models discussed previously.
Normally described from 3 perspectives
 A dynamic perspective that shows phases over
time;
 A static perspective that shows process activities;
 A proactive perspective that suggests good
practice.
 48

Phases in the Rational Unified

Process
 49

RUP Phases
Inception
 Establish the business case for the system, identify all
external entities (people and systems) that will interact with
the system.
Elaboration
 Develop an understanding of the problem domain and the
system architecture, develop project plan, identify key
project risks. Already have the requirements model for the
system(UML use cases are classified).
Construction
 System design, programming testing and documentation.
Transition
 Deploy the system in its operating environment, ensure the
system working correctly.
 50

RUP Good Practice

1. Develop software iteratively
 Plan increments based on customer priorities and
deliver highest priority increments first.
2. Manage requirements
 Clearly document customer requirements and
keep track of changes to these requirements.
3. Use component-based architectures
 Organize the system architecture as a set of
reusable components.
 51

RUP Good Practice (Cont.)

4. Visually model software
 Use graphical UML models to present static and
dynamic views of the software.
5. Verify software quality
 Ensure that the software meet’s organizational
quality standards.
6. Control changes to software
 Manage software changes using a change
management system and configuration
management tools.
 52

Summary: Best Practices of Software

Engineering
• The result is software that is
▫ On Time
▫ On Budget
▫ Meets Users Needs Analyst
Performance
Engineer
Develop Iteratively

Manage
Requirements
Use Component Developer
Best Architectures Tester
Project
Practices Model Visually Manager
Verify Quality

Control Release
Change
Engineer
 53

Computer Aided Software Engineering

(CASE)
• To support software process activities such as
requirements engineering, design, program
development and testing.
• Support by automating some process activities
and provide information on software that is
being developed.
• CASE technology available for most routine
activities in software process. Led to some
improvements in software quality and
productivity.
 54

Tool Type Example (CASE)

• Planning Tools – example: estimation tools,
PERT tools, spreadsheets.
• Editing Tools – example: diagram editors, word
processor, text editor.
• Language Processing Tools – example:
compilers, interpreters.
• Debugging Tools – example: interactive
debugging systems.
• Documentation Tools – example: page layout
program, image editors
 55

Key Points
Software engineering is an engineering discipline
that is concerned with all aspects of software
production.
Essential software product attributes are
maintainability, dependability and security, efficiency
and acceptability.
The high-level activities of specification,
development, validation and evolution are part of all
software processes.
The fundamental notions of software engineering
are universally applicable to all types of system
development.
 56

Key Points
There are many different types of system and
each requires appropriate software engineering
tools and techniques for their development.
The fundamental ideas of software engineering
are applicable to all types of software system.
 57

Key Points
Software processes are the activities involved in
producing a software system. Software process
models are abstract representations of these
processes.
General process models describe the organization
of software processes. Examples of these general
models include the ‘waterfall’ model, incremental
development and reuse-oriented development.
Iterative process models includes software
prototyping and Boehm’s spiral model.
 58

Key Points
The Rational Unified Process is a modern generic
process model that is organized into phases
(inception, elaboration, construction and transition)
but separates activities (requirements, analysis and
design, etc.) from these phases.
CASE technology provides automated support for
software processes. CASE tools support individual
process activities, workbenches support a set of
related activities, environments support all or most
software process activities.