introduction to software engineering csa2030
Download
Skip this Video
Download Presentation
Introduction to Software Engineering - CSA2030

Loading in 2 Seconds...

play fullscreen
1 / 66

Introduction to Software Engineering - CSA2030 - PowerPoint PPT Presentation


  • 59 Views
  • Uploaded on

Introduction to Software Engineering - CSA2030. Dr. Ernest Cachia Department of Computer Science & A. I. Introduction . Generic definition: “The building of software systems” (coined ~1960s). D. L. Parnas[1987]: “The multi-person construction of multi-version software”.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Introduction to Software Engineering - CSA2030' - nash


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
introduction to software engineering csa2030

Introduction to Software Engineering - CSA2030

Dr. Ernest Cachia

Department of Computer Science & A. I.

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!

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

summary of course cont
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

cont summary of course
(...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.

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

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.

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

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!

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

a then emerging problem
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

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

The engineering approach

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

a specific example
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

software engineering in context
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

diagrams of se context
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

software engineering roots cont
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

cont software engineering roots cont
(...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 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.

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

cont software engineering roots cont1
(...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)

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

cont software engineering roots
(...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”

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

problematic areas
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 indivdual’s style)
  • Changes in requirements (however small) often created repercussions throughout every part of the system

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

when copying is right
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?

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

basic engineering practices
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

the way ahead
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)

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

the basic requirements for a good programmer
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….

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

the basic requirements for a good software engineer
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

summary
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

attempting to qualify software
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

some general aspects of s w
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)

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

some quality aspects of software
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)

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

the process makes the product
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

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)

Important s/w process & product qualities

“e”- external quality; “i”- internal quality

“s”- product quality; “p”- process quality

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

classification of s w systems
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.

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

batch processing systems

transaction 1

transaction 2

.

.

.

Processing and

remote database

transaction n

pre-processing

and local storage

Batch-Processing systems
  • Important aspects:
      • Data integrity
      • Data availability
      • Data security
      • Transaction efficiency
      • HCI effectiveness
  • Main elements:
      • Data
      • Database
      • Transaction
      • Security

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

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

terminal 1

terminal 2

local

switching

(no processing)

.

.

.

Remote

processing

terminal n

On-line systems

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

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

User control

panel(s)

User control

panel(s)

User control

panel(s)

Controlling

computer

Controlled

devices

Controlled

devices

Controlled

devices

Real-Time systems

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

embedded 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 mechanisms

system being controlled

Embedded systems

Software

component

Internal

control

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

distributed 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 n

computer or

processor 1

computer or

processor n

process 2

computer or

processor 2

Distributed systems

doing

one

task

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

correctness example

system

specification

system

design

system

implementation

High-level

programming

language

Correctness example

standard

libraries

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

reliability
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

robustness
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 system’s nature
  • Not included in system specification

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

efficiency
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

efficiency evaluation techniques
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.

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

user friendliness aspects
User friendliness aspects
  • Please note THREE MAIN types of users:

The software

The “normal” user

The “operator” user

The “experienced” user

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

user friendliness
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

verifiability
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

maintainability
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%)

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

aspects of maintainability
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)

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

reusability
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

levels of software reuse
Levels of software reuse

usage

Application-specific

level

100%

85%

Domain-specific

level

85%

Information

Management

Personnel

Logistics

20%

Domain-independent

level

Utilities, abstract data struc., GUI functions,

PL libraries, system services, I/O functions,

generic database services, etc.

20%

0%

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

benefits gained by reuse
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

internal and external resue
Internal and external resue

“Reuse”

library

software

software

Another system

software

Development

team

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

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 built

Reuse % = 1 - x 100%

total objects used

total object used

Reuse leverage =

new objects built

(

)

(productivity aid index)

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

reuse metrics 2 cont
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)

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

cont reuse metrics 2
(...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)

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

cont reuse metrics 3
(...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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

cont reuse metrics 4
(...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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

cont reuse metrics 5
(...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

(grelationship between effort for unique code and effort to

reuse code - in the range of .0909 to .1739)

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

cont reuse metrics 6
(...cont) Reuse metrics (6)
  • Final (B-G) formula:

LM = aN1b + 20gaN2b + gaN3b

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

portability
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

understandability
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

interoperability
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

productivity
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

timeliness
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

visibility
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

the overall structure of se
The overall structure of SE

Tools

Methodologies

Methods + techniques

Principles

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

software requirements definition
Software Requirements Definition
  • 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.

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

specification types
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

(C) Dr. Ernest Cachia, 1997

Dept. of Computer Science and A. I., University of Malta

ad