Software Engineering

Chapter one
Introduction

1
What is Software Engineering?
Software Engineering is
—the branch of computer science
—that creates practical, cost-effective solutions to
computing and information processing problems
—preferentially by applying scientific knowledge
developing software systems
+ Generic - developed to be sold to a range of different
customers
+ Custom - developed for a single customer according to their
specification

• ―The application of a systematic, disciplined, quantifiable

approach to the development, operation and
maintenance of software.‖ IEEE
Cont.
• Break down problems and solve them
—Plan, Design, create, test, iterate
—Design for errors & compensate

• Involves whole development cycle

—Implementation of a process that guarantees good
results
How does Software differ
from other engineering disciplines?
• Software is designed, not manufactured
—Production cost is paid up front
—small errors can have big consequences
• Software is malleable
—Can apply to huge variety of problems
• Software doesn’t wear out
—All problems are ―designed in‖
Costs of software engineering?

• Roughly 60% of costs are development costs,

40% are testing costs. For custom software,
evolution costs often exceed development costs
• Costs vary depending on the type of system being
developed and the requirements of system
attributes such as performance and system
reliability
• Distribution of costs depends on the development
model that is used
Software engineering methods
• Structured approaches to software development
whose aim is to facilitate the production of high-
quality software in cost-effective way.
• Model descriptions
– Descriptions of graphical models which should be produced
• Rules
– Constraints applied to system models
• Recommendations
– Advice on good design practice
• Process guidance
– What activities to follow
Attributes of good software?
• The software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and usable
• Maintainability
– Software must evolve to meet changing needs
• Dependability
– Software must be trustworthy
• Efficiency
– Software should not make wasteful use of system resources
• Usability
– Software must be usable by the users for which it was designed
The key challenges facing software
engineering
• Coping with legacy systems, coping with
increasing diversity and coping with demands
for reduced delivery times
• Legacy systems
—Old, valuable systems must be maintained and
updated
• Heterogeneity
—Systems are distributed and include a mix of
hardware and software
• Delivery
—There is increasing pressure for faster delivery of
software
CASE (Computer-Aided Software
Engineering)
• Software systems which are intended to provide
automated support for software process
activities. CASE systems are often used for
method support
• Upper-CASE
—Tools to support the early process activities of
requirements and design
• Lower-CASE
—Tools to support later activities such as programming,
debugging and testing
CASE classification
• Classification helps us understand the different types of
CASE tools and their support for process activities.
• Functional perspective
— Tools are classified according to their specific function.
• Process perspective
— Tools are classified according to process activities that are
supported.
• Integration perspective
— Tools are classified according to their organisation into
integrated units.
Professional and ethical responsibility
• 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.
Software process
• A set of activities whose goal is the development
or evolution of software
• Generic activities in all software processes are:
—Specification - what the system should do and its
development constraints
—Development - production of the software system
—Validation - checking that the software is what the
customer wants
—Evolution - changing the software in response to
changing demands
Software Specification
• The process of establishing what services are
required and the constraints on the system’s
operation and development.
• Requirements engineering process
—Feasibility study;
—Requirements elicitation and analysis;
—Requirements specification;
—Requirements validation.
The requirements engineering process
• Determining what clients need from software
—Problem space, not solution space
—May include quality attributes
– Performance, security, maintainability…
• Challenges
—Clients don’t know what they want
—Clients can’t express what they want
—Bound to change
– Better communication
– Better client
– Changes to environment
The requirements engineering process
System and Software Design(S/W
Development)
• Engineering solution that addresses requirements
• 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.
• Designs include
+ Architecture
+ interfaces
+ Components
+ Data structures
+ Algorithms
The software design process
Software validation
• Verification and validation (V & V) is intended to
show that a system conforms to its specification
and meets the requirements of the system
customer.
• Involves checking and review processes and
system testing.
• 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
The testing process
Testing stages
• Component or unit testing
—Individual components are tested independently;
—Components may be functions or objects or coherent
groupings of these entities.
• System testing
—Testing of the system as a whole. Testing of
emergent properties is particularly important.
• Acceptance testing
—Testing with customer data to check that the system
meets the customer’s needs.
Evolution(operation and Maintenance)
• Changing the software to fix defects meet new
requirements
• Most development today is really evolution
• Differs from initial development
—Significant investment in existing code
—Have to work within additional constraints
—Many SE techniques focus on making evolution easier
System evolution
Software process model
• A simplified representation of a software
process, presented from a specific perspective
• Examples of process perspectives are
—Workflow perspective - sequence of activities
—Data-flow perspective - information flow
—Role/action perspective - who does what
Generic process models
• The waterfall model
— Separate and distinct phases of specification and
development.
• Evolutionary development
— Specification, development and validation are interleaved.
• Component-based software engineering
— The system is assembled from existing components.
• Incremental delivery

• Spiral development
Classical Waterfall Model of S/W
Development
Iterative Waterfall Model of S/W Dev.
Problems with Waterfall
• Change is ubiquitous
—Occurs even during software development
—Unrealistic in most environments
– Requirements constantly changing
– Lessons learned in later stages affect earlier ones
• Useful applied where communication costs high
—Stable requirements
—Very large software systems
—Distributed teams
Evolutionary Dev.
• Based on the idea of developing an initial implementing,
exposing this to user comment and refining it though
version until adequate s/w is developed.
• Exploratory development
—Objective is to work with customers and to evolve a
final system from an initial outline specification.
Should start with well-understood requirements and
add new features as proposed by the customer.
• Throw-away prototyping
—Objective is to understand the system requirements.
Should start with poorly understood requirements to
clarify what is really needed.
Evolutionary Dev.
Evolutionary Dev.
• Problems
—Lack of process visibility;
—Systems are often poorly structured;
—Special skills (e.g. in languages for rapid prototyping)
may be required.
• Applicability
—For small or medium-size interactive systems;
—For parts of large systems
—For short-lifetime systems.
Component-based 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.
• This approach is becoming increasingly used as
component standards have emerged
Component-based development
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.
Incremental development
Incremental development
• 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.
Spiral development
• 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.
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
Spiral Model of S/W process
Benefits of Spiral Development
• Delivers initial value early
—Mitigates risk of failure
—Focus on high-priority functionality
• Frequent requirements refinement
—Uses feedback from one iteration to refine
requirements for the next
—Mitigates impact of change

Note: the Spiral model is driven by uncertainty

and change
When to use
• When project is large
• When releases need to be frequent
• When risk and cost evaluation is important
• When requirements are unclear and complex
• When changes may acquire any time
• For medium to high risk projects