SW Engg Unit 1

8/3/2019 SW Engg Unit 1

1/64

Unit 1 : Overview

Software Engineering


2/64

Topics covered

FAQs about software engineering

Professional and ethical responsibility

Socio -Technical Systems

Emergent system properties

Systems engineering Organizations, people and computer

systems

Legacy systems


3/64

Questions: UNIT 1

1.What are the attributes of good softwar& what are the challenges facingsoftware engineering

2. Describe 4 professional responsibilitiesof a software engineer

3.What is a socio technical system.

Describe its essential characteristics4.Explain the activities involved in system

design process


4/64

Questions: UNIT 1

5.What are emergent system properties?Give examples of each

6.D

escribe following(a) software, (b) Software engineering, (c

software product


5/64

FAQs about software

engineering What is software?

What is software engineering?

What is the difference betweensoftware engineering and systemengineering?

What is a software process?

What is a software process model?


6/64

FAQs about software

engineering What are the costs of software

engineering?

What are software engineeringmethods?

What is CASE (Computer-Aided SoftwareEngineering)

What are the attributes of goodsoftware?

What are the key challenges facing

software engineering?


7/64

What is software?

Computer programs and associateddocumentation such as requirements, designmodels and user manuals.

Software products may beGeneric - developed to be sold to a range

of different customers e.g. PC softwaresuch as Excel or Word.

Custom - developed for a single customeraccording to their specification.


8/64

Creating software

New software can be created by

Developing new programs,

Reusing existing software.

Configuring generic software systems


9/64

What is software engineering?

Software engineering is an engineeringdiscipline that is concerned with allaspects of software production.

Technical process of softwaredevelopment

Project management

Development of tools, methods to supportsoftware production


10/64

Difference between software engineering

and system engineering? System engineering is concerned with all

aspects of computer-based systemsdevelopment including hardware, software

and process engineering. Softwareengineering is part of this process

System engineers are involved in system

specification, architectural design, integrationand deployment. They are less concernedwith development of system components


11/64

What is a software process? A set of activities for development or

maintenance of software.

Generic activities in all software processes

are:Specification - what the system should do

and its development constraints

Development - production of the software

systemValidation - checking that the software is

what the customer wants

Maintenance - changing the software in


12/64

What is a software process

model? A simplified description of a software process

Generic process models

Waterfall;

Iterative development;

Component-based software engineering.


13/64

Software engineering methods

Function oriented methods

Object oriented methods


14/64

software engineering costs

Roughly 60% of costs are developmentcosts, 40% are testing costs.

F

or custom software, maintenance costsoften exceed development costs.( about 3times of development cost)

Costs vary depending on the type of system

being developed and the requirements ofsystem attributes such as performance andsystem reliability.


15/64

CASE (Computer-Aided Software

Engineering) Software systems that are intended to

provide automated support for softwareprocess activities.

CASE systems are often used for methodsupport.

Upper-CASE

Tools to support the early process activitiesof requirements and design;

Lower-CASE

Tools to support later activities such

as


16/64

What are the attributes of good software?

The software should deliver the requiredfunctionality and performance to the userand should be maintainable, dependable,

efficient and usable. Dependability

Software must be trustworthy. Should notcause physical or economic damage in case

of system failure Usability

Must be usable, without undue effort, bythe users. Should have appropriate user


17/64

What are the attributes of good software?

Efficiency

Software should not make wasteful use of

system resources;

Maintainability

Software must evolve to meet changingneeds;


18/64

Key challenges facing software

engineering Heterogeneity

Developing software that is flexible enough

to cope with

h

eterogeneous platforms andexecution environments;

Delivery

Challenge of shortening delivery times for

large & complex systems withoutcompromising quality


19/64

Key challenges facing software

engineering Trust

Developing techniques that demonstrate

th

at software can be trusted by its

users.


20/64

Professional and ethical

responsibility Software engineering involves wider

responsibilities than simply the application oftechnical skills.

Software engineers must behave in an ethicaland morally responsible way if they are to berespected as professionals.

Should not use their skills and abilities in away that brings disrepute to the softwareengineering profession


21/64

Issues of professional

responsibility Confidentiality

Engineers should normally respect theconfidentiality of their employers or clients

irrespective of whether or not a formalconfidentiality agreement has been signed.

Competence

Engineers should not misrepresent theirlevel of competence. They should notknowingly accept work which is outsidetheir competence.


22/64


responsibility Intellectual property rightsEngineers should be aware of local laws

governing the use of intellectual property

such as patents, copyright, etc. Theyshould be careful to ensure that theintellectual property of employers andclients is protected.


23/64


responsibility Computer misuseSoftware engineers should not use their

technical skills to misuse other peoples

computers. Computer misuse ranges fromrelatively trivial (game playing on anemployers machine, say) to extremelyserious (dissemination of viruses).


24/64

ACM/IEEE Code of Ethics

The professional societies in the US havecooperated to produce a code of ethicalpractice.

The Code contains eight Principles related tothe behaviour of and decisions made byprofessional software engineers


25/64

ACM/IEEE Code of Ethics

Software engineers shall committhemselves to making the analysis,specification, design, development, testing

and maintenance of software a beneficialand respected profession.

In accordance with their commitment tothe health, safety and welfare of the public,

Software engineers shall adhere to thefollowing Eight Principles.


26/64

Code of ethics - principles

PUBLIC

Software engineers shall act consistentlywith the public interest.

CLIENTAND EMPLOYER

Software engineers shall act in a mannerthat is in the best interests of their client

and employer consistent with the publicinterest.


27/64


PRODUCT

Software engineers shall ensure that theirproducts and related modifications meetthe highest professional standards possible.

JUDGMENT

Software engineers shall maintain integrity

and independence in their professionaljudgment.


28/64


MANAGEMENT

Software engineering managers andleaders shall subscribe to and promote anethical approach to the management ofsoftware development and maintenance.

PROFESSION

Software engineers shall advance theintegrity and reputation of the professionconsistent with the public interest.


29/64


COLLEAGUES

Software engineers shall be fair to andsupportive of their colleagues.

SELF

Software engineers shall participate inlifelong learning regarding the practice of

their profession and shall promote anethical approach to the practice of theprofession.


30/64

Socio-technical Systems


31/64

What is a system?

A purposeful collection of inter-relatedcomponents working together to achievesome common objective.

A system may include software, mechanical,electrical and electronic hardware and be

operated by people.


32/64

System categories

Technical computer-based systems

Systems that include hardware andsoftware but where the operators and

operational processes are not normallyconsidered to be part of the system.

Examples: TV, Mobile, PC


33/64

System categories

Socio-technical systems

Systems that include technical systems but

also operational processes and people whouse and interact with the technical system.Socio-technical systems are governed byorganisational policies and rules.

Examples: railway reservation system, Airtraffic control system


34/64

Socio-technical system

characteristics Emergent properties

Properties of the system as a whole rather

than associated wit

hindividualcomponents. They emerge only when

system components are integrated

Functional Emergent properties

Non Functional Emergent properties Reliability, Security, Repair ability,Usability


35/64


characteristics Non-deterministic

They do not always produce the same

output when presented with the same inputbecause the system behaviour is partiallydependent on human operators.


36/64


characteristics Complex relationships with organisational

objectives

The extent to which the system supportsorganisational objectives does not justdepend on the system itself.


37/64

Systems engineering

Specifying, designing, implementing, validatindeploying and maintaining socio-technicalsystems.

Concerned with:

Software

Hardware

Systems interaction withusers andenvironment

Limited sco e for rework durin s stem


38/64

Inter-disciplinary involvement

ATC systems

engineering

Electronic

engineering

Electrical

engineering

User interface

design

Mechanical

engineering

Architecture

Structural

engineering

Software

engineering

Civil

engineering


39/64

The systems engineering

process

System

integration

Sub-system

development

Systemdesign

Requirements

definition

System

installation

Systemevolution

System

decommissioning


40/64

System requirements

definition Three types of requirement defined at thisstage

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 objectives for the


41/64

System requirements

definition Should define why a system is being procured

for a particular environment.

E.g. Objective statement for fire & Intruder

detection system

To ensure that the normal functioning ofwork carried out in the building is notseriously disrupted by events such as fireand unauthorized intrusion.


42/64

The system design process

Partition

requirements

Identify

sub-systems

Assign requirements

to sub-systems

Specify sub-system

functionality

Define sub-system

interfaces


43/64

System requirements and

design Requirements engineering and system designare inextricably linked.

Constraints posed by the systems

environment and other systems limit designchoices. These choices may be specified inthe requirement.

As the design process proceeds we may

discover problems with existing requirementsand new requirements may emerge


44/64

System requirements and

design


45/64

System modelling

During Design activity systems are modelledas a set of components & relationshipsbetween them

An architectural model presents an overview of the sub-systems making up asystem

Usually presented as a block diagram


46/64

Burglar alarm system

Alarm

controller

Voice

synthesiser

Movement

sensors

Siren

Door

sensors

Telephone

caller

Externalcontrol centre


47/64

Sub-system description

Sub-syste m Desc ription

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 aud ible warning whenan intruder is suspected

Voicesyn thesiz er Synthesi zes a voic emessagegiving the loc ation of the suspe cte d intruder

T elephone caller Makes external c alls to notify sec urity, the police, etc.


48/64

ATC system architecture


49/64

Sub-system development

Sub systems are usually developed in parallel

Subsystem development may start anothersystem engineering activity Or if subsystem

is software then It may involve requirement,design, implementation, testing

Some of the subsystems can be COTS

Changes at a later stage is usually done insoftware as hardware changes are morecostly


50/64

Putting independently developmentsubsystems to make a complete system.

Big Bang approach

Incremental approach

Incremental approach is better, as

It is not feasible that all the subsystems

are available at a time

Reduces cost of error location

System integration


51/64

Once the integration is complete anextensive system testing takes place

Testing interfaces between the components

Testing the behaviour of the system as awhole

System integration


52/64

After completion, the system has to beinstalled in the customers environment.

Problems during system installation

Environmental assumptions may beincorrect;

May be human resistance to theintroduction of

a new system;System may have to coexist with

alternativesystems for some time;

System installation


53/64

System evolution/

Maintenance Large systems have a long lifetime. Duringtheir life, they are changed

To correct the errors in the original system

requirementTo implement new requirements that have

emerged

Organization have replaced old computerswith faster machines

Organization structure has changed


54/64

System evolution is costlyChanges must be analysed from a technical

and business perspective;

Changes to one system may adversely

affect the performance /behaviour of theother sub systems

Original design decisions are not recordedproperly, hence the person doing changes

have to spend time and figure that out

System structure gets corrupted aschanges are made to it.


55/64

System decommissioning

Taking the system out of service after itsuseful lifetime.

For hardware systems it may require removalof materials (e.g. dangerous chemicals)which pollute the environment

For software systems no physical

decommissioning problem .


56/64

System decommissioning

Sometimes software are used to assistdecommissioning . as they may identify thegood components

Sometimes data is still valuable then it has tobe restructured to be used in new systems


57/64

Organisations/people/systems

Socio-technical systems are organizationalsystems intended to help deliver someorganizational or business goal.

If we do not understand the organizationalenvironment where a system is used, thesystem is less likely to meet the real needs

of the business and its users and may berejected by the users and mangers of the

organization


58/64

Human and organisational

factors Process changesDoes 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 theway they work?

Organisational changes

Does the system change the political powerstructure in an organisation?


59/64

rocuremen/development/Operational

processes


60/64

The system procurement

process

Choose

supplier

Issue request

for bids

Choose

system

Adapt

requirements

Survey market for

existing systems

Let contract for

development

Negotiate

contract

Select

tender

Issue request

to tender

Off-the-shelf

system available

Custom system

required


61/64

Contractor/Sub-contractor

model


62/64

Legacy systems

Socio-technical systems that have beendeveloped in past using old or obsoletetechnology.

Crucial to the operation of a business and itis often too risky to discard these systems

Bank customer accounting system;

Aircraft maintenance system. Legacy systems constrain new business

processes and consume a high proportion ofcompany budgets.


63/64

Legacy system components

System

hardware

Business

processes

Application

software

Business policies

and rules

Support software

Application

data

ConstrainsUsesUsesRuns-onRuns-on

Embeds

knowledge ofUses


64/64

Layered model of Legacy system

Legacy system

Hardware

Support software

Application software

Business processes

Documents

SW Engg Unit 1