Software Specification-Basics of Software Engineering-Lecture Slides, Slides of Software Engineering

This lecture is part of lecture series for Software Engineering course. Prof. Prateek Aron delivered this lecture at Allahabad University. Its main points are: Software, Specification, Establishing, Process, Operation, Development, Feasibility, Elicitation, Validation, Analysis

Typology: Slides

2011/2012

Uploaded on 07/16/2012

sanaka
sanaka 🇮🇳

4.6

(21)

71 documents

1 / 25

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Recap from Last Lecture: Generic Software
Process Models
The Waterfall Model
Separate and distinct phases of specification and
development
Evolutionary Development
Specification and development are interleaved
Formal Systems Development (example - ASML)
A mathematical system model is formally transformed to an
implementation
Reuse-Based Development
The system is assembled from existing components
1 COMP201 - Software Engineering
docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19

Partial preview of the text

Download Software Specification-Basics of Software Engineering-Lecture Slides and more Slides Software Engineering in PDF only on Docsity!

Recap from Last Lecture: Generic Software

Process Models

 The Waterfall Model

 Separate and distinct phases of specification and

development

 Evolutionary Development

 Specification and development are interleaved

 Formal Systems Development (example - ASML)

 A mathematical system model is formally transformed to an

implementation

 Reuse-Based Development

 The system is assembled from existing components

Software Specification

 Software Specification: The process of establishing what

services are required and the constraints on the system’s

operation and development

 Requirements Engineering Process

 Feasibility study

 Requirements elicitation and analysis

 Requirements specification

 Requirements validation

Software Design and Implementation

The process of converting the system specification

into an executable system

 Software design

 Design a software structure that realises the specification

 Implementation

 Translate this structure into an executable program

 The activities of design and implementation are closely

related and may be inter-leaved

Design Process Activities

 Architectural design

 The sub-systems making up the system and their

relationships are identified and documented.

 Abstract specification

 For each sub-system, an abstract specification of its

operational constraints and services is produced.

 Interface design

 For each sub-system, an unambiguous interface with other

sub-systems is designed and documented

 Formal specification may be used in this stage (we study this later)

An Example System

 Consider the scenario of developing a Word processor

system.

 What are the major sub-systems?

 Graphical display, printing facilities, I/O operations,

spellchecking, ...

 How may we define an abstract specification for each?

How do the different sub-systems interact?

 Can you define specifications for components/data

structures and algorithms for one of the sub-systems?

The Software Design Process

Architectural design

Abstract specification

Interface design

Component design

Data structure design

Algorithm design

System architecture

Software specification

Interface specification

Component specification

Data structure specification

Algorithm specification

Requirements specification

Design activities

Design products

Programming and Debugging

 Programming and Debugging consist of translating a

design into a program and removing errors from that

program

 Programming is a personal activity - there is no

generic programming process, but there are good

programming practices and organisational standards

to be followed.

 Programmers carry out some program testing to

discover faults in the program and remove these

faults in the debugging process

The Debugging Process

Locate
error
Design
error repair
Repair
error
Re-test
program

The Testing Process

Sub-system testing

Module testing

Unit

testing

System testing

Acceptance testing

Component testing

Integration testing User testing

Testing Stages

 Unit testing

 Individual components are tested

 Module testing

 Related collections of dependent components are tested

 Sub-system testing

 Modules are integrated into sub-systems and tested. The focus

here should be on interface testing

 System testing

 Testing of the system as a whole. Testing of emergent

properties

 Acceptance testing

 Testing with customer data to check that it is acceptable

Software Evolution

Software is inherently flexible and can change.

 As requirements change through changing business

circumstances, the software that supports the business

must also evolve and change

 Although there has been a demarcation between

development and evolution (maintenance) this is

increasingly irrelevant as fewer and fewer systems are

completely new

 It is important to realise that maintenance costs are

sometimes several times the initial development costs of

the system.

System Evolution

Assess existing
systems
Define system
requirements
Propose system
changes
Modify
systems
New
system
Existing
systems

Case Technology

Case technology has led to significant improvements

in the software process though not the order of

magnitude improvements that were once predicted.

Why is this?

 Software engineering requires creative thought - this is not

readily automatable and the use of artificial intelligence to

provide support for design has not been successful.

 Software engineering is a team activity and, for large

projects, much time is spent in team interactions. CASE

technology does not really support such activities

CASE Classification

Classification helps us understand the different types

of CASE tools and their support for process activities

 Functional perspective

 Tools are classified according to their specific function

 Process perspective

 Tools are classified according to process activities that are

supported

 Integration perspective

 Tools are classified according to their organisation into

integrated units