Introduction to Software Engineering - CSA2030 Dr. Ernest Cachia Department of Computer Science & A. I

Introduction to Software Introduction to Software Engineering - CSA2030Engineering - CSA2030

Dr. Ernest Cachia

Department of Computer Science & A. I.

(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta

Slide

No.

2

Introduction Introduction Generic definition: “The building of

software systems” (coined ~1960s). D. L. Parnas[1987]: “The multi-person

construction of multi-version software”. Software engineering includes programming

but is NOT programming. Therefore…good programmers are not

necessarily good software engineers!


Slide

No.

3

Summary of CourseSummary of Course(cont…)(cont…)

The aim of this course is to acquaint attendees with some of the fundamental principles of the “still-teething” science of software engineering (SE)

The location and relation of SE with respect to other Computer Science disciplines will be clearly explained


Slide

No.

4

(...cont.)(...cont.)

Summary of CourseSummary of Course

It is hoped that this course will highlight the major trends, approaches and techniques used in the development of “sound” software systems.


Slide

No.

5

Who should you be?Who should you be? You should be equipped with the following:

– Interest in the subject area in general– Basic programming skills (nothing fancy)– Normal understanding of structured

programming principles (e.g. CSA1010)– Ability to think in a structured manner– Ability to adhere to discipline in your actions– Ability to keep an open mind in the face of

radically new approaches


Slide

No.

6

Software Engineering overview Software Engineering overview

The final goal of SE is to build a complete multi-application (usually commercial) software system of considerable complexity and of partial, ideally full, “provability”.

To attain such pretentious aims SE must also be able to effectively bring together the efforts of more than one individual to focus on (usually) one common system.


Slide

No.

7

The situation (till very lately) The situation (till very lately) Programming made substantial advances:

– Algorithm theory and studies– Data structure theory– Programming language design and application– Introduction of structured programming– Application and design of 4th Generation

languages

BUT…programming only is not enough for the development of large software systems!


Slide

No.

8

A (then) emerging problemA (then) emerging problem Software development done solely using

traditional programming techniques Computers become more popular - fast Their potential is better recognised Software demands become more serious Software sophistication rockets Sophistication requires more complex s/w Complex s/w is generally large in size Programming is targeted at user-specific

small-scale problems


Slide

No.

9

The engineering approachThe engineering approach

Comprehend its feasibility

Define it clearly as possible– structure (architecture)– I/O and constraints– working parameters– function

Design its overall structure

Design its components

Design its integration

Implement (actually build) it

Test it (according to thespecified working parameters)

Install it

Test it (on site/in function)

Maintain it


Slide

No.

10

A specific exampleA specific example Building a tuner (or any electronic device):

– must specify ALL component working parameters and tolerance levels

– rules to correctly locate components on board– ALL specs are standardised– ALL specs are universally understood

Building any software component:– we do not even know which exactly are the

parameters that need to be specified


Slide

No.

11

Available tools (h/w and s/w)Available tools (h/w and s/w)

Hardware:– Measuring instruments (meters, probes, scopes,

etc.)– Proven mathematical relationships– Adequate established specification standards

Software:– Sparse limited mathematical (formal) tools– Loads of subjective experience and judgment


Slide

No.

12

Software Engineering in contextSoftware Engineering in context

SE is only a small part of System Engineering

Most modern systems are made up of elements other than simply software

Software on its own is like a mind without a body - it cannot do anything physical

SE only effects the software component of any real-world system


Slide

No.

13

Diagrams of SE contextDiagrams of SE contextThe system Flight control system

softwarecomponent

All system components that are not software

wires

buttons

indicators

computer h/w

recording media

sensors

servo mechanisms

alarms

controllingsoftware


Slide

No.

14

Software Engineering roots Software Engineering roots (cont…)(cont…)

Main idea: Make the machine do something usefull BUT a while ago the application of computers was limited

Therefore there was a 1-to-1 (personal) relationship between user and machine to make it do only user-specific tasks– eg. Solve an equation, manipulate an array, etc.

Often ONLY THE USER WAS THE PROGRAMMER


Slide

No.

15

(...cont)(...cont)

Software Engineering rootsSoftware Engineering roots(cont…)(cont…)

With the introduction of High-level Languages the idea of a “programmer” was created - now the user need not be the machine’s programmer

Nevertheless only specific user-requested tasks were still being programmed– eg. a program for John’s problem would very

likely not interest Mary at all.


Slide

No.

16

(...cont)(...cont)

Software Engineering rootsSoftware Engineering roots(cont…)(cont…)

This separation of concerns introduced the notion of task specification with its associated mis-interpretation problems

The mid 60s saw the first attempts to build large scientific/commercial systems– OS360 (operating system for IBM 360

mainframe family machines)– UNIX (originally written in assembly language)


Slide

No.

17

(...cont)(...cont)

Software Engineering rootsSoftware Engineering roots Due to this flurry of activity in the mid 60s

serious problems started to emerge regarding the state of software development

The main realisation was that virtually everything associated with computing had a sound scientific basis - apart from software!

Coining of the terms “Software Engineering” and “Software Crisis”


Slide

No.

18

Problematic areasProblematic areas Tasks not well (or at all) understood by

everyone taking part in the global solution Very large communication overheads -

often exceeding actual coding Coding very subjective (according to

indivdual’s style) Changes in requirements (however small)

often created repercussions throughout every part of the system


Slide

No.

19

When copying When copying isis right right

Large complex systems were being created continually by engineers with relative ease– eg. bridges, factories, plants, aircraft, etc.

These systems seemed to be much more reliable than software systems

Why not emulate the way in which they are constructed? Why apply basic engineering practices to software development also?


Slide

No.

20

Basic Engineering PracticesBasic Engineering Practices

Process monitoring and management Process organisation and delegation Application of specific tools Availability/creation of proven theories Application of specific methodologies Development of standardised techniques


Slide

No.

21

The way aheadThe way ahead

The importance of software will always increase (well at least never decrease)– In the 60s the balance of h/w and s/w costs was

roughly 96% to 4% - no one really took software seriously

– In the early 90s it was 25% to 75% and rising– In 1985 $140 billion spent on software

development– In 1995 $750 billion (estimated)


Slide

No.

22

The basic requirements for a The basic requirements for a good programmergood programmer

Knowledge of data structures and algorithms Knowledge of at least one (preferably more)

programming languages in popular use A minimal ability to abstractly visualise a

specific task

COMPARE THESE WITH….


Slide

No.

23

The basic requirements for a The basic requirements for a good software engineergood software engineer

Be a decent programmer Understand requirements & translate them into

precise specifications Interface with the user on a non-technical basis Flexible in his/her application background Handle abstraction levels with ease Be able to create different models Have good planning/delegation abilities and be

able to easily communicate his/her thoughts


Slide

No.

24

SummarySummary The very nature of software itself has and will

change (progress?) Ways and means of developing better software

will result in better harnessing the potential of computing

The mastery of any process will only lead to an improvement in the quality of its product

Better quality usually breeds better productivity


Slide

No.

25

Attempting to qualify softwareAttempting to qualify software Very difficult if done un-scientifically Akin to qualifying human thought/reasoning Large amount of factors effecting s/w quality Large amount of aspects to a s/w product Very easy to qualify incorrectly Considerable degree of subjectivity in s/w

product S/w product prone to direct (un-specified)

modification


Slide

No.

26

Some general aspects of s/wSome general aspects of s/w Its development process Its end-products (with all their representative

attributes) Its interaction with humans (users, developers,

process managers, vendors, etc.) The nature of the real-world process it is to

model/simulate End-user feedback (on s/w product)


Slide

No.

27

Some quality aspects of softwareSome quality aspects of software Quality means different things to different

people– User (reliable, efficient, simple to use, etc.)– Producer (maintainable, verifiable, portable, etc.)– Manager (productive and controlled dev., etc.)

Main categories of s/w qualities are:– External (observable by system users)– Internal (structure used to obtain ext. qualities)


Slide

No.

28

The process makes the productThe process makes the product Process: “A series of activities undertaken

to achieve a stipulated entity” Product: “An entity resulting from a given

process” Quality applies to both process and product A software product (typically)

Implementation (executable/s) User manuals “Source” code Requirements statement/Design plan/Test data


Slide

No.

29

Important s/w process & Important s/w process & product qualitiesproduct qualities

Correctness (i/s) Reliability (e/s/p) Robustness (e/s/p) Efficiency (e/s/p) User friendliness (e/s) Verifiability (i/s) Maintainability (i/s/p)

Reusability (i/s) Portability (e/s) Understandability (i/s) Interoperability (i/s) Productivity (p) Timeliness (p) Visibility (p)

“e”- external quality; “i”- internal quality“s”- product quality; “p”- process quality


Slide

No.

30

Classification of s/w systemsClassification of s/w systems Batch Processing systems On-line systems Real-Time systems Embedded systems Distributed systems

Quality for each of the above can take on a different meaning.


Slide

No.

31

Batch-Processing systemsBatch-Processing systems Main elements:

Data Database Transaction Security

transaction 2

transaction 1

transaction n

Important aspects: Data integrity Data availability Data security Transaction efficiency HCI effectiveness

...pre-processing

and local storage

Processing andremote database


Slide

No.

32

On-line systemsOn-line systems Main elements:

Result time limits Time-slicing Security

Important aspects: Response time range Stimulii to results

relationships Communication

design/security HCI designterminal 1

terminal 2

terminal n

...

localswitching

(no processing) Remoteprocessing


Slide

No.

33

Real-Time systemsReal-Time systems Main elements:

Stringent timing Control I/O specifications Safety

Important aspects: Response timing

relationships Response time to

activity relationships Control protocol

design Safety mechanisms HCI designUser control

panel(s)

User controlpanel(s)

User controlpanel(s)

Controllingcomputer Controlled

devices

Controlleddevices

Controlleddevices


Slide

No.

34

Embedded systemsEmbedded systems Main elements:

Stringent timing Control I/O specifications System dependency Safety

Important aspects: Response timing

relationships Response time to

activity relationships Control protocol

design Safety mechanismssystem being controlled

Softwarecomponent

Internalcontrol


Slide

No.

35

Distributed systemsDistributed systems

Main elements: Process communication Process distribution Data distribution Network links

Important aspects: Communication protocols Logical to physical

process and data mapping Link reliability Individual process

dependencies Data replication and

redundency

process 1

process 2

process n

computer orprocessor n

computer orprocessor 2

computer orprocessor 1

doingonetask


Slide

No.

36

CorrectnessCorrectness At the basis of many other s/w qualities

eg. Reliability and robustness verifyability and performance

Relative to s/w functional specifications Is a mathematical property Must show equivalence between s/w and its

specification Experimental (through testing) Analytical (through formal verification) Usage of statically analytic tools (HL-languages and

modules of them)


Slide

No.

37

Correctness exampleCorrectness example

systemspecification

systemdesign

systemimplementation

High-levelprogrammin

glanguage

standardlibraries


Slide

No.

38

ReliabilityReliability

Considered to be a relative quality Direct consequence to system dependability In its complete form considered to be “ideal” Guarantees non-existant / disclaimers many Should imply correctness (not vice-versa) Assumes (ideally) correctly specified

requirements


Slide

No.

39

RobustnessRobustness

Should always be considered never ignored Not a specifiable quality (usually) Help in better understanding the process

being modelled (eg. sky-scraper technology) Depends considerably on the system’s nature Not included in system specification


Slide

No.

40

EfficiencyEfficiency Direct result of reliability and robustness Considered to be a relative quantity Can “make or break” a system Highly dependent on technology Effects system scalability Generically measured in terms of extremes

of algorithm time/space/etc. requirements Should be addressed BEFORE system

implementation


Slide

No.

41

Efficiency evaluation techniquesEfficiency evaluation techniques

Generic: Processing time, required space, data traffic, inter-process message traffic.

Measurement: External system monitors for data collection and subsequent evaluation.

Analysis: Application of queuing theory concepts to analyse model of actual system.

Simulation: Build a use a model to actually perform the same actions as the system.


Slide

No.

42

User friendliness aspectsUser friendliness aspects

Please note THREE MAIN types of users:

The software

The “normal” user The “operator” user

The “experienced” user


Slide

No.

43

User friendlinessUser friendliness How a system appeals to (different) users Very subjective software quality Human-Computer Interface is very relevant Software configuration issues (easy?) Performance is also relevant to “friendliness” GUI desgin issues (should be taken seriously) Standardisation increases user friendliness


Slide

No.

44

VerifiabilityVerifiability

Ease of software quality checking Not all qualities are of equal verifiability Could form part of user requirements Generally implies understandability Should be an implicit value in development


Slide

No.

45

MaintainabilityMaintainability Applies to “released” products Eats up around 65 to 75% of total s/w

development costs Existing software does not “ware out” - it

evolves! Existing sotware can be improved upon Not akin to hardware maintenance S/w maintenance can be classified as:

Corrective (sorting out persistent errors - 25%) Adaptive (due to changes in working env. - 20%) Perfective (improve system fuctionality - 55%)


Slide

No.

46

Aspects of maintainabilityAspects of maintainability Repairability (ease of defect correction)

– Exists at different levels (like old & modern h/w)– Direct consequence of good (modular) design– Funtional localisation aids repairability– Orthogonal to reliability

Evolvability (change/improve functionality)– Should undergo normal s/w development process– Requires in-depth study of original system– Should not deteriorate in time (i.e. after successive

releases)


Slide

No.

47

ReusabilityReusability Using existing products to construct new ones Important but not often used quality Directly impacts on evolvability Some examples:

The UNIX shell (command language interpreter) Programming language routine libraries Packages, routines, widgets, etc. in X windows Human knowledge reuse (?)

Considered a measure of general development process maturity


Slide

No.

48

Levels of software reuseLevels of software reuse

Utilities, abstract data struc., GUI functions, PL libraries, system services, I/O functions,

generic database services, etc.

20%

0%

Personnel InformationManagement

Logistics85%

20%

Domain-independent

level

Domain-specific

level

100%

85%

Application-specific

level

usage


Slide

No.

49

Benefits gained by reuseBenefits gained by reuse

Lower development costs Higher productivity (reduced cycle time) Lower training costs Easier maintenance Lower risk (higher reliability) Better interoperability Better portability


Slide

No.

50

Internal and external resueInternal and external resue

“Reuse”library A

nother systemsoftware

software

software

Developmentteam


Slide

No.

51

Reuse metrics (1)Reuse metrics (1) Banker et al. (1993-1994) metric:

Uses software “objects” (modules, routines, etc.) Does not account for object size (could be deceptive)

new objects builtReuse % = 1 - x

100% total objects used

total object usedReuse leverage =

new objects built

( )

(productivity aid index)


Slide

No.

52

Reuse metrics (2) Reuse metrics (2) (cont…)(cont…) Poulin-Caruso (IBM-1992) metric:

RSI Reuse % = x 100%

total statements(where RSI: Reused Source Instruction)

RCA = DCA + SCA(where R/D/SCA: Reuse/Development/Service Cost Avoidance)

DCA = RSI x (1 - RCR) x (new code cost)(where RCR: Relative Cost of Reuse)

SCA = RSI x (error rate) x (error cost)

Note: RSI implies:– Code components in loops count as only one reuse– Code from project/domain-specific libraries– Code from specific reuse libraries– Some code from utility libraries (depending on its nature)


Slide

No.

53

(...cont) (...cont) Reuse metrics (2)Reuse metrics (2)

total source statements + SIRBO RVA =

total source statements - RSI(where RVA: Reuse Value Added, SIRBO: Source Instructions Reused by Others)

SIRBO = (LOC per part) x (organisations using the part)(where LOC: Lines Of Code)


Slide

No.

54


Balda-Gustafson (Modified COCOMO)(COCOMO = COnstructive COst MOdel)

Original COCOMO: (LM = KDSILM = labour-months of effort

= complexity coefficient

= complexity exponent

KDSI = initial estimate of effort for thousands (K) of

Delivered Source Instructions


Slide

No.

55


Balda-Gustafson modifications

LM = 1N1 + 2N2

+ 3N3 + 4N4

1 = KDSI for development of unique code

2 = KDSI for code developed for reuse

3 = KDSI for reused code

4 = KDSI for modified and reused code


Slide

No.

56


The Balda-Gustafson simplificationBasic assumption: RCR = 0.1 & RCWR = 2.0This implies 20 times more effort to build for reusethan to actually reuse

(Remember, RCR is Relative Cost of Reuse &

RCWR is Relative Cost of Writing for Reuse)

Therefore: 2 = 203; 2 = 201; 3 = 1

relationship between effort for unique code and effort toreuse code - in the range of .0909 to .1739)


Slide

No.

57


Final (B-G) formula:

LM = N1 + 20N2

+ N3


Slide

No.

58

PortabilityPortability With respect to platform and operating

system characteristics Very dependent on the functional nature of

the software Can be partially achieved through reusability Could entail trade-offs in the form of non-

optimal usage of hardware or system resources


Slide

No.

59

UnderstandabilityUnderstandability

Has a direct impact on many important software qualities (eg. correctness, verifiability, maintainability, user-friendliness and visibility)

Helps control aspects of complexity Does not guarantee syntactic/semantic or

algorithmic comprehension


Slide

No.

60

InteroperabilityInteroperability

Common in hardware - not so in software(eg. stereo systems with CD technology vs. operating systems and CD technology)

Has a direct impact on productivity and evolvability

Related to interface standardisation Is the driving force behind the “open

system” approach


Slide

No.

61

ProductivityProductivity Generally refers to the software production

process Generally assumes team effort Has a direct impact on timeliness Depends considerably on software reuse Can be greatly increased through the use of

automated software engineering tools Calculated in terms of “function points” and

code size


Slide

No.

62

TimelinessTimeliness Generally refers to the software production

process The main culprit in “software crisis” Relatively not as “bad” as incorrectness Difficult to calculate accurately a priori to

actual software development Directly effected by system structuring to

aid incremental delivery


Slide

No.

63

VisibilityVisibility Generally refers to the software production

process Synonymous with transparency and

openness Directly effects productivity and timeliness Encourages correct and effective team work Helps qualify the software development

process Should always be up to date


Slide

No.

64

The overall structure of SEThe overall structure of SE

Tools

Methodologies

Methods + techniques

Principles


Slide

No.

65

Software Requirements Software Requirements DefinitionDefinition

Some terminology:– Requirements definition: Natural language

description of user services provided by system– Requirements specification: A more detailed

description of the system’s functions in “technical” terms

– Software specification: An abstract description of the software itself. Mainly intended for software designers.


Slide

No.

66

Specification typesSpecification types

OperationalSpecifies system behaviour in terms of its internal (component) functions

DescriptiveSpecifies the system in terms of a declaration of the its properties

Documents

Introduction to Software Engineering - CSA2030 Dr. Ernest Cachia Department of Computer Science & A. I