se lecture 8 process

8/6/2019 SE Lecture 8 Process

1/25

Lecture 8

Software ProcessesIn Slight Detail


2/25

Learning Outcome

A little bit better understanding on the

software process.

In a bit of detail

All of the upcoming topics will be discussed

in greater detail in upcoming lectures.


3/25

I. Software specificationThe process of establishing what services

are required and the constraints on the

systems operation and development

Requirements engineering process

Feasibility study

Requirements elicitation and analysis

Requirements specification

Requirements validation


4/25

How Programs Are Usually

Written

The requirements

specification was

defined like this

The developers

understood it in

that way

This is how the

problem was

solved before.

This is how the

problem issolved now

That is the program after

debugging

This is how the program is

described by marketing

department

This, in fact, is what the

customer wanted ;-)


5/25

The requirements engineering process

e si i itstu

equirementse icit tion n

n sisequirements

speci ic tion

equirementsi tion

e si i itreport

stemmo e s

ser n s stem

requirements

equirements

ocument


6/25

II. Software design andimplementation

The process of converting the system

specification into an executable system

Software design

Design a software structure that realises the specification

Implementation

T

ranslate this structure into an executable program

The activities ofdesign and implementation are

closely related and may be inter-leaved


7/25

Design process activities

Architectural design

Abstract specification Interface design

Component design

Data structure design

Algorithm design


8/25

The software design process

rchitect radesign

stractspecification

nterfacedesign

Co ponentdesign

atastr ct r edesign

gorithdesign

stearchitect re

oftwarespecification

nterfacespecification

Co ponentspecification

ata

str ct r especification

gorithspecification

e ire entsspecification

esign actiities

esign prod cts


9/25

Design methods

Systematic approaches to

developing a software design

The design is usually documented as a setof graphical models

Possible models

Data-flow model Entity-relation-attribute model

Structural model

Object models


10/25

Programming and debugging

Translating a design into a program andremoving errors from that program

Programming is a personal activity - there is no

generic programming process

Programmers carry out some program testing

to discover faults in the program and removethese faults in the debugging process


11/25

The debugging process

Loc eerror

esignerror rep ir

ep ir error

e esprogr


12/25

III Software validation Verification and validation is intended to show

that a system conforms to its specification and

meets the requirements of the system customer

Involves checking and review processes and

system testing

System testing involves executing the system

with test cases that are derived from the

specification of the real data to be processed by

the system


13/25

The testing process

s stetesting

Mo e

testing

ni ttesting

stetesting

ccept ncetesting

o ponenttesting

ntegrtion testing ser testing


14/25

Testing stages

Unit testing Individual components are tested

Module testing

Related collections of dependent components are tested

Sub-system testing odules 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


15/25


16/25

IV Software evolution

Software is inherently flexible and can change.

As requirements change through changing businesscircumstances, the software that supports the business

must also evolve and change

Although there has been a demarcation betweendevelopment and evolution (maintenance) this is

increasingly irrelevant as fewer and fewer systems are

completely new


17/25

System evolution

ssess e istin

systems

e ine systeme ui ements

o ose systemn es

o i y

systems

Nesystem

istin

systems


18/25

Automated process support ( ASE)

Computer-aided software engineering (CASE) issoftware to support software development and

evolution processes

Activity automation

Graphical editors for system model

development

Data dictionary to manage design entities

GraphicalUI builder for user interfaceconstruction

Debuggers to support program fault finding

Automated translators to generate new versions

of a program


19/25

Case technology

Case technology has led to significant

improvements in the software process

though not the order of magnitudeimprovements that were once predicted

Software engineering requires creative

thought - this is not readily automatable

Software engineering is a team activity and, for

large projects, much time is spent in team

interactions. CASE technology does not really

support these


20/25

CASE classification

Classification helps us understand the

different types ofCASE 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 aresupported

Integration perspective

Tools are classified according to their organisation into

integrated units


21/25

Functional tool classificationTool ty e am leslanning tools T tools, estimation tools,

spreadsheets

diting tools Text editors, diagram editors, ordprocessors

hange management tools equirements traceability tools, change

control systemsonfiguration management tools ersion management systems, system

building tools

rototyping tools ery high-level languages,user interface generators

ethod-support tools esign editors, data dictionaries, codegenerators

anguage-processing tools ompilers, interpreters

rogram analysis tools ross reference generators, staticanalysers, dynamic analysers

Testing tools Test data generators, file comparators

ebugging tools Interactive debugging systems

ocumentation tools age layout programs, image editors

e-engineering tools ross-reference systems, program re-structuring systems


22/25

CASE integration

Tools

Support individual process tasks such as design

consistency checking, text editing, etc.

Workbenches Support a process phase such as specification or

design, ormally include a number of integrated

tools

Environments

Support all or a substantial part of an entire

software process. ormally include several

integrated workbenches


23/25

Tools, workbenches, environments

in le methoworkbenches

Gener l r oseworkbenches

lti methoworkbenches

n e s eci icworkbenches

ro r mmin Testinn lysis nesi n

nte r teenvironments

rocess centreenvironments

ilecom r tors

om ilersitors

nvironmentsWorkbenchesTools

technolo y


24/25

Key points

Software processes are the activities involved inproducing and evolving a software system. They

are represented in a software process model

eneral activities are specification, design and

implementation, validation and evolution

eneric process models describe the organisation

of software processes

Iterative process models describe the softwareprocess as a cycle of activities


25/25

Key points

Requirements engineering is the process of

developing a software specification

Design and implementation processes transform

the specification to an executable program Validation involves checking that the system

meets to its specification and user needs

Evolution is concerned with modifying the

system after it is in use

CASE technology supports software process

activities

se lecture 8 process

Documents