Introduction%20to%20Software%20Engineering%20-%20CSA2030

1
Introduction to Software Engineering - CSA2030

• Dr. Ernest Cachia
• Department of Computer Science A. I.

2
Introduction

• Generic definition The building of software
  systems (coined 1960s).
• D. L. Parnas1987 The multi-person
  construction of multi-version software.
• Software engineering includes programming but is
  NOT programming.
• Thereforegood programmers are not necessarily
  good software engineers!

3
Summary of Course(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

4
(...cont.)Summary of Course

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

5
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

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

7
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
• BUTprogramming only is not enough for the
  development of large software systems!

8
A (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

9
The 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 the
• specified working
• parameters)
• Install it
• Test it (on site/in function)
• Maintain it

10
A 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

11
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

12
Software 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

13
Diagrams of SE context
The system
Flight control system
wires
sensors
All system components that are not software
indicators
controlling software
buttons
servo mechanisms
software component
recording media
alarms
computer h/w
14
Software Engineering roots (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

15
(...cont)Software Engineering roots(cont)

• With the introduction of High-level Languages the
  idea of a programmer was created - now the user
  need not be the machines programmer
• Nevertheless only specific user-requested tasks
  were still being programmed
• eg. a program for Johns problem would very
  likely not interest Mary at all.

16
(...cont)Software Engineering roots(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)

17
(...cont)Software 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

18
Problematic 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 indivduals
  style)
• Changes in requirements (however small) often
  created repercussions throughout every part of
  the system

19
When copying is 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?

20
Basic 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

21
The 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)

22
The basic requirements for a good 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.

23
The basic requirements for a good 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

24
Summary

• 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

25
Attempting 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

26
Some 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)

27
Some 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)

28
The 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

29
Important s/w process product 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
30
Classification 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.

31
Batch-Processing systems

• Main elements
• Data
• Database
• Transaction
• Security

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

32
On-line systems

• Main elements
• Result time limits
• Time-slicing
• Security

• Important aspects
• Response time range
• Stimulii to results relationships
• Communication design/security
• HCI design

33
Real-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 design

34
Embedded systems

• Important aspects
• Response timing relationships
• Response time to activity relationships
• Control protocol design
• Safety mechanisms

• Main elements
• Stringent timing
• Control
• I/O specifications
• System dependency
• Safety

Software component
Internal control
35
Distributed systems

• Important aspects
• Communication protocols
• Logical to physical process and data mapping
• Link reliability
• Individual process dependencies
• Data replication and redundency

• Main elements
• Process communication
• Process distribution
• Data distribution
• Network links

doing one task
36
Correctness

• 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)

37
Correctness example
standard libraries
38
Reliability

• 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

39
Robustness

• 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 systems nature
• Not included in system specification

40
Efficiency

• 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

41
Efficiency 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.

42
User friendliness aspects

• Please note THREE MAIN types of users

The software
The normal user
The operator user
The experienced user
43
User 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

44
Verifiability

• 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

45
Maintainability

• 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)

46
Aspects 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)

47
Reusability

• 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

48
Levels of software reuse
usage
Application-specific level
100
85
Domain-specific level
85
Information Management
Personnel
Logistics
20
Utilities, abstract data struc., GUI functions,
PL libraries, system services, I/O
functions, generic database services, etc.
Domain-independent level
20
0
49
Benefits gained by reuse

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

50
Internal and external resue
Reuse library
software
software
Another system
software
Development team
51
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 built
• Reuse 1 - x 100
• total objects used
• total object used
• Reuse leverage
• new objects built

(
)
(productivity aid index)
52
Reuse metrics (2) (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)

53
(...cont) 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)

54
(...cont) Reuse metrics (3)

• Balda-Gustafson (Modified COCOMO)
• (COCOMO COnstructive COst MOdel)
• Original COCOMO (LM aKDSIb)
• LM labour-months of effort
• a complexity coefficient
• b complexity exponent
• KDSI initial estimate of effort for thousands
  (K) of
• Delivered Source Instructions

55
(...cont) Reuse metrics (4)

• Balda-Gustafson modifications
• LM a1N1b a2N2b a3N3b a4N4b
• N1 KDSI for development of unique code
• N2 KDSI for code developed for reuse
• N3 KDSI for reused code
• N4 KDSI for modified and reused code

56
(...cont) Reuse metrics (5)

• The Balda-Gustafson simplification
• Basic assumption RCR 0.1 RCWR 2.0
• This implies 20 times more effort to build for
  reuse
• than to actually reuse
• (Remember, RCR is Relative Cost of Reuse
• RCWR is Relative Cost of Writing for Reuse)
• Therefore a2 20a3 a2 20ga1 a3 ga1
• (g relationship between effort for unique code
  and effort to
• reuse code - in the range of .0909 to .1739)

57
(...cont) Reuse metrics (6)

• Final (B-G) formula
• LM aN1b 20gaN2b gaN3b

58
Portability

• 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

59
Understandability

• 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

60
Interoperability

• 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

61
Productivity

• 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

62
Timeliness

• 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

63
Visibility

• 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

64
The overall structure of SE
Tools
Methodologies
Methods techniques
Principles
65
Software Requirements Definition

• Some terminology
• Requirements definition Natural language
  description of user services provided by system
• Requirements specification A more detailed
  description of the systems functions in
  technical terms
• Software specification An abstract description
  of the software itself. Mainly intended for
  software designers.

66
Specification types

• Operational
• Specifies system behaviour in terms of its
  internal (component) functions
• Descriptive
• Specifies the system in terms of a declaration
  of the its properties