Introduction Lecture 9(30102012)

7/30/2019 Introduction Lecture 9(30102012)

1/44

System Engineering

LECTURE 9

ByUmm-e-Laila

1


2/44

Topics to be covered

System Engineering

-System Engineering Hierarchy

-Business Process Engineering

-Requirement Engineering

-System Engineering

2


3/44

Computer-based System

Software engineering occurs as a consequence of system engineering

System engineering may take on two different forms depending on theapplication domain

Business process engineeringconducted when the context of the workfocuses on a business enterprise

Product engineeringconducted when the context of the work focuses on aproduct 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 establishthe links that tie software to other elements of a computer-based system

3


4/44

System

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 thevarious parts

A method or plan of classification or arrangement

An established way of doing something such as a method or procedure

4


5/44

Computer-based System

Defined: A set or arrangement of elements that are organized to accomplishsome predefined goal by processing information

The goal may be to support some business function or to develop a product thatcan 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 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-basedsystem that may integrate other macro elements

The role of the system engineer is to define the elements of a specificcomputer-based system in the context of the overall hierarchy of systems

5


6/44

Computer-based System (continued)

A computer-based system makes use of the following four system elements thatcombine 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, interconnectivitydevices 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 softwareand persists over time

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

6


7/44

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)

7

"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"


8/44

System Engineering Hierarchy

8

WorldView

Domain

View

Element

View

Component

View


9/44

System Modeling

(at each view level) Defines the processes (e.g., domain classes in OO terminology) that serve

the needs of the view under consideration

Represents the behavior of the processes and the assumptions on which thebehavior is based

Explicitly defines intra-level and inter-level input that form links between

entities in the model

Represents all linkages (including output) that will enable the engineer tobetter understand the view

May result in models that call for one of the following

Completely automated solution

A semi-automated solution A non-automated (i.e., manual) approach

9


10/44


11/44

System Modeling with UML

The Uniform Modeling Language (UML) provides diagrams for analysis

and design at both the system and software levels

Examples

Use case diagrams

Activity diagrams Class diagrams

State diagrams

11


12/44

12

Business Process Engineering

uses an integrated set of procedures,methods, and tools to identify how

information systems can best meet the

strategic goals of an enterprise

focuses first on the enterprise and then onthe business area

creates enterprise models, data models and

process models

creates a framework for better informationmanagement distribution, and control


13/44

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'scomputing resources

Three different architectures must be analyzed and designed within thecontext of business objectives and goals

The data architecture provides a framework for the information needs of abusiness (e.g., ERD)

The application architecture encompasses those elements of a system thattransform objects within the data architecture for some business purpose

The technology infrastructure provides the foundation for the data andapplication architectures

It includes the hardware and software that are used to support the applicationsand data

13


14/44

Business Engineering Hierarchy

14

The Enterprise

A Business Area

Construction &integration

(Detailed View)

Information

System

Business

System Design

(element view)

Business Area

Analysis

(Domain View)

Information

Strategy Planning

(World View)


15/44

The BPE Hierarchy Information strategy planning (ISP) (world view)strategic goals definedsuccess factors/business rules identifiedenterprise model created

Business area analysis (BAA) (domain view)processes/services modeled

interrelationships of processes and data Business system design - Application Engineering

(element view)Software engineering

modeling applications/procedures that address (BAA) and

constraints of ISP Construction and delivery (detailed view)using CASE and 4GTs, testing

15


16/44

16

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, anddata

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

System component engineering happens next as a set of concurrentactivities that address each of the components separately

Each component takes a domain-specific view but maintains communicationwith the other domains

The actual activities of the engineering discipline takes on an element view

Analysis modeling allocates requirements into function, data, andbehavior

Design modeling maps the analysis model into data/class, architectural,

interface, and component design


17/44

17

Product Engineering Hierarchy

Product Requirements

Engineering

Hardware

Engineering

Software

Engineering

Database

Engineering

Construction

Human

Engineering

AnalysisModelingFunction

Data and

ClassesBehavior

Architectural

Design

Interface

Design

Component

Design

Data/Class

Design

Design

Modeling

System

Component

Engineering


18/44

Requirements Engineering

Challenge facing system and software engineers

How can we ensure that we have specified a system that:

Properly meets the customers needs

Satisfies the customers expectations

Requirements engineering provides mechanisms for: Understanding what the customer wants

analyzing need

assessing feasibility

negotiating a reasonable solution

specifying the solution

validating the specification

managing the transformation of the requirements into an operational

system

18


19/44

Requirements Engineering

The requirements engineering process can bedescribed in six steps:

Inception Elicitation

Elaboration

Negotiation

Specification Validation

Requirements management

19


20/44

20

Inception Task

During inception, the requirements engineer asks a set of questionsto establish

A basic understanding of the problem

The people who want a solution

The nature of the solution that is desired

The effectiveness of preliminary communication and collaborationbetween the customer and the developer

Through these questions, the requirements engineer needs to

Identify the stakeholders

Recognize multiple viewpoints

Work toward collaboration

Break the ice and initiate the communication


21/44

Requirements Elicitation

It might seem that this should be simple:

Ask the customer, users, and others:

What the objectives for the system are

What is to be accomplished

How the system fits the into the needs of the business

How the system will be used on a day-to-day basis

In fact it is hard!

Problems of scope Problems of understanding

Problems of volatility

21


22/44

Problems of Scope

The boundary of the system may be ill-defined Who is going to interact with the system? What other systems are involved? Exactly what functionality is the responsibility of

the system e.g. should a rostering system produce a telephone

directory?

The customer/user may specify unnecessarytechnical detail that may confuse overall

system objectives e.g. specifying OS, language, hardware, etc. for no

particularly good reason

22


23/44

Problems of Understanding

Customers/users may: Not be completely sure of what is needed, e.g.:

See what you can do to help us(Marketing director of textile business)

Try to improve the project(Director of British Aircraft Corporation, with reference to theConcorde project)

Have a poor understanding of the capabilities andlimitations of their computing equipment

Not have a full understanding of the problem domain Have trouble communicating needs to system engineer

Omit information believed to be obvious Specify requirements that conflict with needs of others Specify requirements that are ambiguous or untestable

23


24/44

Problems of Volatility

Requirements change over time Change is inevitable in most systems, due

to factors such as: Changes in customer organization, e.g.

new divisions, new products Changes in scale, e.g. Number of transactions per day Number of users Increased connection bandwidth

External changes

Changes in law (e.g. taxation) Changes in international standards (e.g. MPEG)

Customers get new ideas as they becomeaware of system possibilities

24


25/44

25

Elicitation Work Products

A statement of need and feasibility

A bounded statement of scope for the system or product

A list of customers, users, and other stakeholders who participated in

requirements elicitation

A description of the system's technical environment

A list of requirements (organized by function) and the domainconstraints that apply to each

A set of preliminary usage scenarios (in the form of use cases) that

provide insight into the use of the system or product under differentoperating conditions

Any prototypes developed to better define requirements

The work products will vary depending on the system, but

should include one or more of the following items


26/44

26

Elaboration Task

During elaboration, the software engineer takes the informationobtained during inception and elicitation and begins to expand andrefine it

Elaboration focuses on developing a refined technical model ofsoftware functions, features, and constraints

It is an analysis modeling task

Use cases are developed

Domain classes are identified along with their attributes and relationships

State machine diagrams are used to capture the life on an object

The end result is an analysis model that defines the functional,informational, and behavioral domains of the problem


27/44

27

Developing Use Cases

Step One Define the set of actors that will be involved in the story

Actors are people, devices, or other systems that use the system or product

within the context of the function and behavior that is to be described

Actors are anything that communicate with the system or product and that are

external to the system itself

Step Two Develop use cases, where each one answers a set of questions

(More on next slide)


28/44

28

Negotiation Task

During negotiation, the software engineer reconciles the conflictsbetween what the customer wants and what can be achieved givenlimited business resources

Requirements are ranked (i.e., prioritized) by the customers, users,and other stakeholders

Risks associated with each requirement are identified and analyzed Rough guesses of development effort are made and used to assess

the impact of each requirement on project cost and delivery time

Using an iterative approach, requirements are eliminated, combinedand/or modified so that each party achieves some measure ofsatisfaction


29/44

29

Specification Task

A specification is the final work product produced by therequirements engineer

It is normally in the form of a software requirements specification

It serves as the foundation for subsequent software engineering

activities It describes the function and performance of a computer-based

system and the constraints that will govern its development

It formalizes the informational, functional, and behavioralrequirements of the proposed software in both a graphical andtextual format


30/44

30

Validation Task

During validation, the work products produced as a result ofrequirements engineering are assessed for quality

The specification is examined to ensure that

all software requirements have been stated unambiguously

inconsistencies, omissions, and errors have been detected and corrected

the work products conform to the standards established for the process,the project, and the product

The formal technical review serves as the primary requirementsvalidation mechanism

Members include software engineers, customers, users, and other

stakeholders


31/44

Requirements Management

We have noted that changes in requirements:

are essentially unavoidable

will persist throughout the lifetime of the system

Requirements managementhelps the projectteam to identify, track and control requirements

and changes to them

This is closely related to configuration management Traceability tables are developed for

requirements

31


32/44

32

A Generic Traceability Table

A01 A02 A03 Aii

R01

R02

R03

Rnn


33/44

Traceability Tables

Features traceability table Show how requirements relate to customer-

observable system features Source traceability table

Identify the source of each requirement Dependency traceability table

Show relationships between requirements Subsystem traceability table

Categorise requirements according to subsystemsthey govern

Interface traceability table Shows how requirements relate to internal and

external system interfaces

33


34/44

System Modeling Process

Hartley-Pirbhai Modeling

System Context Diagram (SCD)

top level node in system hierarchy used to establish the boundary between

the system being implemented (system model template serves as its basis)

System Flow Diagram (SFD)refinement of the process and control functions from SCD, derived by

identifying the major subsystems and lines of information flow.

Initial SFD is becomes the top level node of a hierarchy of

more successively more detailed SFD's System Specification

developed by writing narrative description for each subsystem and

definitions for all data that flow between subsystems

34


35/44

System Modeling

Any computer-based system can be modeled

as a box with input > processing(in the box) >

output.

Hatley and Pirbhai extend this with

user interface processing

maintenance and self testing

features.

Hatley and Pirbhai have developed a template that

helps modelers describe the system

35


36/44

System Model Template

36


37/44

37

Conveyor Line Sorting System (CLSS)

CLSS must be developed such that boxes moving along a conveyor line will be

identified and sorted into one of six bins at the end of the line. The boxes will

pass by a sorting station where they will be identified. Based on an

identification number printed on the side of the box and a bar code, the boxes

will be shunted into the appropriate bins. Boxes pass in random order and are

evenly spaced. The line is moving slowly.

A desk-top computer located at the sorting station executes all CLSS software,

interacts with the bar-code reader to read part numbers on each box, interacts

with the conveyor line monitoring equipment to acquire conveyor line speed,

stores all part numbers sorted, interacts with a sorting station operator toproduce a variety of reports and diagnostics, sends control signals to the

shunting hardware to sort the boxes, and communicates with a central factory

automation system.


38/44

Architecture Flow Diagram

38


39/44

Architecture Flow Diagram

39


40/44

System Modeling with UML

Deployment diagrams Each 3-D box depicts a hardware element that is

part of the physical architecture of the system

Activity diagrams Represent procedural aspects of a system

element

Class diagrams Represent system level elements in terms of the

data that describe the element and the operationsthat manipulate the data

These and other UML models will be discussed later

40


41/44

41

Deployment Diagram

CLSS processor

Sort ing subsystem

Sensor data

acquisition subsystem

Operator display

shunt controller

Conveyor

Pulse tachBar code reader Shunt actuator

A i i Di


42/44

Activity Diagram

42

get conveyor speed

send shunt

cont ro l data

get shunt s ta t us read bar code

start conveyor l ine

determine b in locat ion

valid bar code

set f o r re ject b in

conveyor in motion

read bar code

get conveyor sta t us

produce report ent ry

conveyor stopped

invalid bar code

Cl Di


43/44

Class Diagram

43

Box

barcode

forwardSpeed

conveyorLocation

height

widthdepth

weight

contents

readBarcode()

updat eSpeed ()

readSpeed()

updat eLocat ion()readLocat ion()

get Dimensions( )

getWeight()

checkCont ents( )

class name

attributes

not e use of capit al

lett er for mult i-word

att ribute names

operat ions(parentheses at end

of name indicat e t he

list of attributes that the

operat ion requires)


44/44

Use-Case Diagram

homeowner

Arms/ dis armssystem

Acc ess es s ys tem

via Internet

Reconfigur es sensors

and related

system features

Responds to

alarm event

Encounters an

error condition

system

administrator

sensors

Documents

Introduction Lecture 9(30102012)