se notes unit 1

8/9/2019 SE Notes Unit 1

1/76

1

.

PART A:

Unit 1: Overview

Topics covered

FAQs about software engineering

Professional and ethical responsibility Emergent system properties

system engg. and Organization

people and computer system

legacy system


2/76

2

Software engineering

The economies of ALL developed nations

are dependent on software.

More and more systems are software

controlled

Software engineering is concerned withtheories, methods and tools for

professional software development.

Expenditure on software represents a

significant fraction of GNP in all developedcountries


3/76

3

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


4/76

4

What is software?

What is software engineering?

What is the difference between softwareengineering and computer science?

What is the difference between software

engineering and system engineering?

FAQs about software engineering


5/76


6/76

6

What is software?

It is not just computer programming.

Computer programs and associated

documentation such as requirements,

design models and user manuals.

Software products may be developed for a

particular customer or may be developed for

a general market.


7/76


8/76

8

Software engineering is an engineering

discipline that is concerned with all aspects of

software production.

Software engineers should adopt a systematic

and organised approach to their work , use

appropriate tools and techniques depending on

the problem to be solved, the development

constraints and the resources available.

What is software engineering?


9/76

9

Computer science is concerned with theory and

fundamentals; software engineering is concerned

with the practicalities of developing and delivering

useful software.

Computer science theories are still insufficient to

act as a complete underpinning for softwareengineering (unlike e.g. physics and electrical

engineering).


engineering and computer science?


10/76

10

System engineering is concerned with all aspects

of computer-based systems development

including hardware, software and process

engineering.

Software engineering is part of this process

concerned with developing the software

infrastructure, control, applications and databases

in the system.System engineers are involved in system

specification, architectural design, integration and

deployment.


engineering and system engineering?


11/76

11

What is a 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 andits 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.


12/76

12

What is a 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

Waterfall;Iterative development;

Component-based software engineering.


13/76

13

What is a software process model?

.

Generic process models

Waterfall;

Evolutionary development;

Component-based software engineering

Formal transformation

System assembly from reusable components


14/76

14

What are the 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.


15/76

15

Activity cost distribution


16/76

16

Product development costs


17/76

17

What are software engineering methods?

Structured approaches to software development

which include system models, notations, rules,

design advice and process guidance.Component Description Example

Model descriptions Descriptions of system models object models,which should be produced data-flow model

Rules Constraints applied to system unique name in

model an entity

Recommendations Advice on good design practice sub-objects in a

objectProcess guidance What activities to follow Documentation


18/76

18

What is CASE ?

(Computer-Aided Software Engineering)

Software systems that 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 asprogramming, debugging and testing.

case tools may include code generator for

source codes


19/76

19

What are the attributes of good software?

The software should deliver the required

functionality and performance to the user

and should be maintainable, dependable

and acceptable.

MaintainabilitySoftware must evolve to meet changing

needs;

Dependability

Software must be trustworthy;


20/76

20

EfficiencySoftware should not make wasteful

use of system resources;

Acceptability

Software must accepted by theusers for which it was designed.

This means it must be

understandable, usable and

compatible with other systems.


21/76

21

What are the key challenges facing

software engineering?

Legacy Challenge

This is the challenge of maintaining and

updating old software with minimum

maintenance costs for continuous use.Heterogeneity

Developing techniques for building

software that can cope with

heterogeneous platforms andexecution environments in a

distributed network

.


22/76

22

Delivery

Developing techniques that lead to

faster delivery of software;

TrustDeveloping techniques that

demonstrate that software can be

trusted by its users


23/76

23

Professional and ethical responsibility

Software engineering involves widerresponsibilities than simply the application of

technical skills.

Software engineers must behave in an honestand ethically responsible way if they are to be

respected as professionals.

Ethical behaviour is more than simplyupholding the law.


24/76

24

Issues of professional responsibility

ConfidentialityEngineers should normally respect the

confidentiality of their employers or

clients irrespective of whether or not a

formal confidentiality agreement hasbeen signed.

Competence

Engineers should not misrepresent their

level of competence. They should notknowingly accept work which is out with

their competence.


25/76

25

Issues of professional responsibility

Intellectual property rights

Engineers should be aware of

local laws governing the use ofintellectual property such as

patents, copyright, etc. They

should be careful to ensure that

the intellectual property ofemployers and clients is

protected.


26/76

26

Computer misuse

Software engineers should not use their

technical skills to misuse other peoples

computers. Computer misuse ranges fromrelatively trivial (game playing on an

employers machine, say) to extremely

serious (dissemination of viruses)


27/76

27

The professional societies in the US have

cooperated to produce a code of ethical practice.

Members of these organisations sign up to the code

of practice when they join.

The Code contains eight Principles related to the

behaviour of and decisions made by professional

software engineers, including practitioners,educators, managers, supervisors and policy

makers, as well as trainees and students of the

profession.

ACM/IEEE Code of Ethics


28/76

28

Code of ethics - preamble

PreambleThe short version of the code summarizes

aspirations at a high level of the

abstraction; the clauses that are included in

the full version give examples and details ofhow these aspirations change the way we

act as software engineering professionals.

Without the aspirations, the details can

become legalistic and tedious; without the

details, the aspirations can become high

sounding but empty; together, the

aspirations and the details form a cohesive

code.


29/76

29

Software engineers shall commit themselves

to making the analysis, specification, design,

development, testing and maintenance of

software a beneficial and respected

profession. In accordance with their

commitment to the health, safety and welfareof the public, software engineers shall adhere

to the following Eight Principles:


30/76

30

Code of ethics - principles

PUBLIC

Software engineers shall

act consistently with the

public interest.

CLIENT AND EMPLOYERSoftware engineers shall

act in a manner that is in

the best interests of their

client and employerconsistent with the public

interest.


31/76

31

PRODUCT

Software engineers shall ensure that

their products and relatedmodifications meet the highest

professional standards possible.

JUDGMENT

Software engineers shall maintainintegrity and independence in their

professional judgment.


32/76

32

MANAGEMENT

Software engineering

managers and leaders shall

subscribe to and promote an

ethical approach to the

management of software

development andmaintenance.

PROFESSION

Software engineers shall

advance the integrity andreputation of the profession

consistent with the public

interest.


33/76

33

COLLEAGUES

Software engineers shall be fair to

and supportive of their colleagues.

SELF

Software engineers shall participate

in lifelong learning regarding thepractice of their profession and

shall promote an ethical approach

to the practice of the profession.


34/76

34

Ethical dilemmas-Examples

Disagreement in principle with the policies of

senior management.

Your employer acts in an unethical way andreleases a safety-critical system without

finishing the testing of the system.

Participation in the development of military

weapons systems or nuclear systems.


35/76

35

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

The properties and behaviour of system

components are inextricably inter-mingled


36/76

36

System categories

Technical computer-based systemsSystems that include hardware and software

but where the operators and operational

processes are not normally considered to be

part of the system. The system is not self-aware.

Socio-technical systems

Systems that include technical systems but

also operational processes and people who

use and interact with the technical system.

Socio-technical systems are governed by

organisational policies and rules.


37/76

37

Socio-technical system characteristics

Emergent propertiesProperties of the system of a whole that depend on

the system components and their relationships.

Non-deterministic

They do not always produce the same output when

presented with the same input because the systems

behaviour is partially dependent on human operators.

Complex relationships with organisational objectives

The extent to which the system supports

organisational objectives does not just depend on the

system itself.


38/76

38

Properties of the system as a whole ratherthan properties that can be derived from the

properties of components of a system

Emergent properties are a consequence ofthe relationships between system

components

They can therefore only be assessed and

measured once the components have beenintegrated into a system

Emergent properties


39/76

39

Examples of emergent properties

Property Description

Volume The volume of a system (the total space occupied) varies depending on how the

component assemblies are arranged and connected.

Reliability System reliability dependson component reliability but unexpected interactions can

cause new types of failure and therefore affect the reliability of the system.

Security The security of the system (its ability to resist attack) is a complex property thatcannot be easily measured. Attacks may be devised that were not anticipated by thesystem designers and so may defeat built-in safeguards.

Repairability This property reflects how easy it is to fix a problem with the system once it has been

discovered. It dependson being able to diagnose the problem, access the componentsthat are faulty and modify or replace these components.

Usability This property reflects how easy it is to use the system. It depends on the technicalsystem components, its operators and its operating environment.


40/76

40

Types of emergent property

Functional propertiesThese appear when all the parts of a system work

together to achieve some objective. For example, a

bicycle has the functional property of being a

transportation device once it has been assembled from

its components.Non-functional emergent properties

Examples are reliability, performance, safety, and

security. These relate to the behaviour of the system in

its operational environment. They are often critical for

computer-based systems as failure to achieve someminimal defined level in these properties may make the

system unusable.


41/76

41

System reliability engineering

Because of component inter-dependencies,

faults can be propagated through the system.

System failures often occur because of

unforeseen inter-relationships betweencomponents.

It is probably impossible to anticipate all

possible component relationships.

Software reliability measures may give a false

picture of the system reliability.


42/76

42

Influences on reliability

Hardware reliabilityWhat is the probability of a hardware

component failing and how long does it take to

repair that component?

Software reliabilityHow likely is it that a software component will

produce an incorrect output. Software failure is

usually distinct from hardware failure in that

software does not wear out.

Operator reliability

How likely is it that the operator of a system

will make an error?


43/76

43

Reliability relationships

Hardware failure can generate spurious signals

that are outside the range of inputs expected by

the software.

Software errors can cause alarms to be activated

which cause operator stress and lead to operator

errors.

The environment in which a system is installed

can affect its reliability.


44/76

44

Measurable and non-measurable properties

Properties such as performance and reliabilitycan be measured.

However, some properties are properties that the

system should not exhibit

Safety - the system should not behave in anunsafe way;

Security - the system should not permit

unauthorised use.

Measuring or assessing these properties is veryhard.


45/76

45

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.


46/76

46

The system engineering process

Usually follows a waterfall model because of the need forparallel 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.


47/76

47

The systems engineering process

Requirements

definition

System

design

Sub-system

development

SystemIntegration

System

Installation

System

Evolution

System

decommissioning


48/76

48

Inter-disciplinary involvement

Software Engg Electronic engg Mech.Engg

Structural

engg

ATC systems

enggUser Unterface

Civil engg Elec.Engg Architecture

Air Traffic Control


49/76

49

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-functionalrequirements for the system in general are

defined;

Undesirable characteristics. Unacceptable

system behaviour is specified.

Should also define overall organisational

objectives for the system.


50/76

50

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 thebuilding 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 eventssuch as fire and unauthorized intrusion.


51/76

51

System requirements problems

Complex systems are usually developed to

address wicked problems

1. Problems that are not fully understood;

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


52/76

52

The system design process

Partition

Requirements

Identify

Sub-system

Assign requirementsTo sub-systems

Specify sub-system

functionality

Define sub-system

interfaces


53/76

53

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.


54/76

54

System design problems

Requirements partitioning to hardware,

software and human components may involve a

lot of negotiation.

Difficult design problems are often assumed tobe readily solved using software.

Hardware platforms may be inappropriate for

software requirements so software must

compensate for this.


55/76

55

Requirements and design

Requirements engineering and system design

are inextricably linked.

Constraints posed by the systems 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.


56/76

56

Spiral Model of Requirements


57/76

57

System modelling

An architectural model presents an abstract

view of the sub-systems making up a system

May include major information flows betweensub-systems

Usually presented as a block diagram

May identify different types of functional

component in the model


58/76

58

Burglar alarm system

Movement

Sensors

Door

sensors

Alarm

Controller

SirenVoice

synthesisTelephone

Caller

External

Control

centre


59/76

59

Sub-system description

Sub system

Movement Sensor

Door sensors

Alarm ControllersSiren

Voice synthesizers

Telephone caller

Description

Detects movement in the room

Detect door opening

Controls the operation of the systemEmits an audible warning at the time ofintruder is suspected

Synthesizes voice message giving the

location of the intruderMake external call to security , policeetc.


60/76

60

Sub-system development Typically parallel projects developing thehardware, software and communications.

May involve some COTS (Commercial Off-the-

Shelf) systems procurement.

Lack of communication across implementationteams.

Bureaucratic and slow mechanism for

proposing system changes means that the

development schedule may be extended becauseof the need for rework.


61/76

61

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.


62/76

62

System installation

After completion, the system has to be installed inthe customers 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.


63/76

63

System evolution

Large systems have a long lifetime. They mustevolve to meet changing requirements.

Evolution is inherently costly

1. Changes must be analysed from a technical

and business perspective;

2. Sub-systems interact so unanticipated

problems can arise;

3. There is rarely a rationale for original design

decisions;

4. System structure is corrupted as changes are

made to it. Existing systems which must be maintained are

sometimes called legacy system.


64/76

64

System decommissioning

Taking the system out of service after its

useful lifetime.

May require removal of materials (e.g.

dangerous chemicals) which pollute theenvironment

Should be planned for in the system

design by encapsulation.

May require data to be restructured andconverted to be used in some other system.


65/76

65

Organisations/people/systems

Socio-technical systems are organizational

systems intended to help deliver some

organizational or business goal.

If you do not understand the organizational

environment where a system is used, the

system is less likely to meet the real needs ofthe business and its users.


66/76

66

Human and organisational factors

Process changes

Does the system require changes to the work

processes in the environment?

Job changesDoes the system de-skill the users in an

environment or cause them to change the way

they work?

Organisational changes

Does the system change the political power

structure in an organisation?


67/76

67

Organizational processes

The processes of systems engineering overlap

and interact with organizational procurement

processes.

Operational processes are the processesinvolved in using the system for its intended

purpose. For new systems, these have to be

defined as part of the system design.

Operational processes should be designed to beflexible and should not force operations to be done

in a particular way. It is important that human

operators can use their initiative if problems arise.


68/76

68

Procurement/developmentprocesses

Procurement

process

Development

Process

Operational

process


69/76

69

System procurement

Acquiring a system for an organization to meet some need

Some system specification and architectural design is

usually necessary before procurement

. You need a specification to let a contract for system

development. The specification may allow you to buy a commercial

off-the-shelf (COTS) system. Almost always cheaper than

developing a system from scratch

Large complex systems usually consist of a mix of off the

shelf and specially designed components. The procurementprocesses for these different types of component are usually

different.


70/76

70

The system procurement process

Adapt

Requirements

Choose

System

Invite

bids

Choose

Supplier

Survey

Existing

Systems

Issue for

Tenders

Select

TenderNegotiate

Contract forDevelopment

Custom system Requirement

Off the shelf requirement


71/76

71

Requirements may have to be modified to matchthe capabilities of off-the-shelf components.

The requirements specification may be part of thecontract for the development of the system.

There is usually a contract negotiation period toagree changes after the contractor to build asystem has been selected.

Procurement issues


72/76

72

The procurement of large hardware/softwaresystems is usually based around someprincipal contractor.

Sub-contracts are issued to other suppliersto supply parts of the system.

Customer liaises with the principal contractorand does not deal directly with sub-

contractors.

Contractors and sub-contractors


73/76

73

Contractor/Sub-contractor model


74/76

74

Legacy systems

Socio-technical systems that have been developedusing old or obsolete technology.

Crucial to the operation of a business and it is often too

risky to discard these systemsExamples:Bank customer accounting system;Aircraft maintenance system.

Legacy systems constrain new business processes andconsume a high proportion of company budgets.


75/76

75

Legacy system components

Hardware - may be obsolete mainframe hardware.

Support software - may rely on support software fromsuppliers who are no longer in business.

Application software - may be written in obsolete

programming languages.

Application data - often incomplete and inconsistent.

Business processes - may be constrained by software

structure and functionality.

Business policies and rules - may be implicit andembedded in the system software.


76/76

76

Socio Technical System

Business Processes

Application SoftwareSupport software

Hardware

se notes unit 1

Documents