SOFTWARE ENGINEERING

CS 2301
Dr.K.M.ANANDKUMAR
Associate Professor / CSE
UNIT - 1
SOFTWARE PRODUCT AND PROCESS

Introduction – S/W Engineering Paradigm – Verification

– Validation – Life Cycle Models – System Engineering –
Computer Based System – Business Process
Engineering Overview – Product Engineering Overview.
Verification & Validation
• Verification: “Am I building the product right?”
checking a work product against some standards and
conditions imposed on this type of product and the
process of its development.
– Requirements are verified by the analysts mainly

• Validation: “Am I building the right product?”

checking a work product against higher-level work
products or authorities that frame this particular
product.
– Requirements are validated by stakeholders
WIN WIN Spiral Model
• The Win-Win spiral approach is an extension
of the spiral approach. The phase in this
approach is same as the phase in the spiral
approach. The only difference is that at the
time of the identifying the requirements, the
development team and the customer hold
discussion and negotiate on the requirements
that need to be included in the current
iteration of the software.
WIN WIN Spiral Model
• The approach is called Win-Win because it is a
winning situation for the development team
and also for the customer. The customer wins
by getting the product that fulfills most of the
requirements while the development team
wins by delivering software which is
developed with all the requirements
established after negotiations with the
customer. The Win-Win approach is generally
used when you have time-bound releases.
WIN WIN Spiral Model
System Engineering
- Computer-based system
- System engineering process
- “Business process” engineering
- Product engineering
What is a system?
• A purposeful collection of inter-related components
working together to achieve some common
objective.
• A system may include software, mechanical,
electrical and electronic hardware and be operated
by people.
• System components are dependent on other system
components
Introduction
• Software engineering occurs as a consequence of system
engineering
• System engineering may take on two different forms
depending on the application domain
– “Business process” engineering – conducted when the context of the
work focuses on a business enterprise
– Product engineering – conducted when the context of the work
focuses on a product that is to be built
• Both forms bring order to the development of computer-
based systems
• Both forms work to allocate a role for computer software and
to establish the links that tie software to other elements of a
computer-based system
Introduction
• System (Webster)
– A set or arrangement of things so related as to form a
unity or organic whole
– A set of facts, principles, rules. etc., … to show a logical
plan linking the various parts
– A method or plan of classification or arrangement
– An established way of doing something such as a method
or procedure
Computer-based System
• Defined: A set or arrangement of elements that are
organized to accomplish some predefined goal by
processing information
• The goal may be to support some business function
or to develop a product that can be sold to generate
business revenue
• A computer-based system makes use of system
elements
• Elements constituting one system may represent one
macro element of a still larger system
Computer-based System
• Example
– A factory automation system may consist of a numerical
control machine, robots, and data entry devices; each can
be its own system
– At the next lower hierarchical level, a manufacturing cell is
its own computer-based system that may integrate other
macro elements
• The role of the system engineer is to define the
elements of a specific computer-based system in the
context of the overall hierarchy of systems
Computer-based System
• A computer-based system makes use of the
following four system elements that combine in a
variety of ways to transform information
– Software: computer programs, data structures, and
related work products that serve to effect the logical
method, procedure, or control that is required
– Hardware: electronic devices that provide computing
capability, interconnectivity devices that enable flow
of data, and electromechanical devices that provide
external functions
– People: Users and operators of hardware and
software
– Database: A large, organized collection of information
that is accessed via software and persists over time
Computer-based System
• The uses of these elements are described
in the following:
– Documentation: Descriptive information
that portrays the use and operation of the
system
– Procedures: The steps that define the
specific use of each system element or the
procedural context in which the system
resides
Systems engineering
• Specifying, designing, implementing,
validating, deploying and maintaining socio-
technical systems.

• Concerned with the services provided by the

system, constraints on its construction and
operation and the ways in which it is used.
The system engineering process
• Usually follows a ‘waterfall’ model because of the
need for parallel development of different parts of
the system
– Little scope for iteration between phases because
hardware changes are very expensive. Software may have
to compensate for hardware problems.
• Inevitably involves engineers from different
disciplines who must work together
– Much scope for misunderstanding here. Different
disciplines use a different vocabulary and much
negotiation is required. Engineers may have personal
agendas to fulfil.
The systems engineering process
Inter-disciplinary involvement

Software Electro nic Mech an ical

engin eering engin eering engin eering

Structural ATC systems User in terface

engin eering engin eering design

Civ il Electrical
Architecture
engin eering engin eering
 System requirements definition
• Three types of requirement defined at this
stage
– Abstract functional requirements. System
functions are defined in an abstract way;
– System properties. Non-functional requirements
for the system in general are defined;
– Undesirable characteristics. Unacceptable system
behaviour is specified.
• Should also define overall organisational
objectives for the system.
System objectives
• Should define why a system is being procured
for a particular environment.
• Functional objectives
– To provide a fire and intruder alarm system for the
building which will provide internal and external
warning of fire or unauthorized intrusion.
• Organisational objectives
– To ensure that the normal functioning of work
carried out in the building is not seriously
disrupted by events such as fire and unauthorized
intrusion.
System requirements problems
• Complex systems are usually developed to
address wicked problems
– Problems that are not fully understood;
– Changing as the system is being specified.
• Must anticipate hardware/communications
developments over the lifetime of the system.
• Hard to define non-functional requirements
(particularly) without knowing the
component structure of the system.
The system design process
• Partition requirements
– Organise requirements into related groups.
• Identify sub-systems
– Identify a set of sub-systems which collectively can meet the system
requirements.
• Assign requirements to sub-systems
– Causes particular problems when COTS are integrated.
• Specify sub-system functionality.
• Define sub-system interfaces
– Critical activity for parallel sub-system development.
The system design process
System design problems
• Requirements partitioning to hardware,
software and human components may involve
a lot of negotiation.
• Difficult design problems are often assumed
to be readily solved using software.
• Hardware platforms may be inappropriate for
software requirements so software must
compensate for this.
Requirements and design
• Requirements engineering and system design
are inextricably linked.
• Constraints posed by the system’s
environment and other systems limit design
choices so the actual design to be used may
be a requirement.
• Initial design may be necessary to structure
the requirements.
• As you do design, you learn more about the
requirements.
Spiral model of requirements/design
System modelling
• An architectural model presents an abstract
view of the sub-systems making up a system
• May include major information flows between
sub-systems
• Usually presented as a block diagram
• May identify different types of functional
component in the model
Burglar alarm system
Sub-system description

Sub-system Description
Movement sensors Detects movement in the rooms monitored by the system
Door sensors Detects door opening in the external doors of the building
Alarm controller Controls the operation of the system
Siren Emits an audible warning when an intruder is suspected
Voice synthesizer Synthesizes a voice message giving the location of the suspected intruder
Telephone caller Makes external calls to notify security, the police, etc.
ATC system architecture
Sub-system development
• Typically parallel projects developing the
hardware, software and communications.
• May involve some COTS (Commercial Off-the-Shelf)
systems procurement.
• Lack of communication across implementation
teams.
• Bureaucratic and slow mechanism for
proposing system changes means that the
development schedule may be extended because of
the need for rework.
System integration
• The process of putting hardware, software and
people together to make a system.
• Should be tackled incrementally so that sub-
systems are integrated one at a time.
• Interface problems between sub-systems are
usually found at this stage.
• May be problems with uncoordinated deliveries
of system components.
System installation
• After completion, the system has to be
installed in the customer’s environment
– Environmental assumptions may be incorrect;
– May be human resistance to the introduction of
a new system;
– System may have to coexist with alternative
systems for some time;
– May be physical installation problems (e.g.
cabling problems);
– Operator training has to be identified.
System evolution
• Large systems have a long lifetime. They must evolve
to meet changing requirements.
• Evolution is inherently costly
– Changes must be analysed from a technical and business
perspective;
– Sub-systems interact so unanticipated problems can arise;
– There is rarely a rationale for original design decisions;
– System structure is corrupted as changes are made to it.
• Existing systems which must be maintained are
sometimes called legacy systems.
System decommissioning
• Taking the system out of service after its
useful lifetime.
• May require removal of materials (e.g.
dangerous chemicals) which pollute the
environment
– Should be planned for in the system design by
encapsulation.
• May require data to be restructured and
converted to be used in some other system.
System Engineering Process
• The system engineering process begins with a world view;
the business or product domain is examined to ensure that
the proper business or technology context can be established
• The world view is refined to focus on a specific domain of
interest
• Within a specific domain, the need for targeted system
elements is analyzed
• Finally, the analysis, design, and construction of a targeted
system element are initiated
• At the world view level, a very broad context is established
• At the bottom level, detailed technical activities are
conducted by the relevant engineering discipline (e.g.,
software engineering)
36
System Engineering Process

"Always design a thing by considering it in

its next larger context – a chair in a room,
a room in a house, a house in an environment,
and environment in a city plan"

37
Business Process Engineering
• “Business process” engineering defines
architectures that will enable a business to
use information effectively
• It involves the specification of the
appropriate computing architecture and
the development of the software
architecture for the organization's
computing resources

38
Business Process Engineering
• Three different architectures must be analyzed
and designed within the context of business
objectives and goals
– The data architecture provides a framework for the
information needs of a business (e.g., ERD)
– The application architecture encompasses those
elements of a system that transform objects within the
data architecture for some business purpose
– The technology infrastructure provides the foundation
for the data and application architectures
• It includes the hardware and software that are used to
support the applications and data

39
Business Process Engineering
World
View

Domain
View

Element
View

Component
View

40
 Product Engineering
• Product engineering translates the customer's desire
for a set of defined capabilities into a working
product
• It achieves this goal by establishing a product
architecture and a support infrastructure
– Product architecture components consist of people,
hardware, software, and data
– Support infrastructure includes the technology required to
tie the components together and the information to
support the components
• Requirements engineering elicits the requirements
from the customer and allocates function and
behavior to each of the four components
41
 Product Engineering
• System component engineering happens next as a
set of concurrent activities that address each of the
components separately
– Each component takes a domain-specific view but
maintains communication with the other domains
– The actual activities of the engineering discipline takes on
an element view
• Analysis modeling allocates requirements into
function, data, and behavior
• Design modeling maps the analysis model into
data/class, architectural, interface, and component
design
42
Product Engineering Hierarchy
Product Requirements
Engineering
System
Human Hardware Software Database Component
Engineering Engineering Engineering Engineering Engineering

Data and Analysis

Function Behavior
Classes Modeling

Data/Class Architectural Interface Component Design

Design Design Design Design Modeling

Construction

43