Introduction to software engineering csa2030
This presentation is the property of its rightful owner.
Sponsored Links
1 / 66

Introduction to Software Engineering - CSA2030 PowerPoint PPT Presentation


  • 36 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Introduction to Software Engineering - CSA2030

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


  • Login