Software Engineering Lecture

8/8/2019 Software Engineering Lecture

1/118

1

Software EngineeringSoftware Engineering

ByBy

A. Sai KishoreA. Sai Kishore

Assistant ProfessorAssistant Professor

Department of Computer ApplicationsDepartment of Computer Applications

BRECWBRECW


2/118

2

What is Software?What is Software?

Software is a set of items or objects

that form a configuration that

includes

programs documents

operating procedures...


3/118

3

What is Engineering?What is Engineering?

Engineering is the discipline, art and profession of

acquiring and applying scientific, mathematical,

economic, social, and practical knowledge to design and

build systems that realize solutions to the needs of

society.


4/118

4

What is Software Engineering?What is Software Engineering?

Software Engineering is an Engineering discipline

which is concerned with all aspects of software

production.


5/118

5

Softwares Dual RoleSoftwares Dual Role

Software is a productSoftware is a product

Software is a vehicle for delivering a productSoftware is a vehicle for delivering a product


6/118

6

Characteristics of SoftwareCharacteristics of Software

software is developed or engineeredsoftware is developed or engineered

not manufacturednot manufactured

software doesnt wear outsoftware doesnt wear out software can be reusedsoftware can be reused


7/118

7

A Layered TechnologyA Layered Technology

Software Engineering

a quality focusa quality focus

process modelprocess model

methodsmethods

toolstools


8/118

8

A Process FrameworkA Process Framework

Process frameworkProcess framework

Framework activitiesFramework activities

work taskswork taskswork productswork products

milestones & deliverablesmilestones & deliverables

QA checkpointsQA checkpoints

Umbrella ActivitiesUmbrella Activities


9/118

9

Umbrella ActivitiesUmbrella Activities

Software project managementSoftware project management

Formal technical reviewsFormal technical reviews

Software quality assuranceSoftware quality assurance

Software configuration managementSoftware configuration management

Work product preparation and productionWork product preparation and production

Reusability managementReusability management

MeasurementMeasurement

Risk managementRisk management


10/118

10

Framework ActivitiesFramework Activities

CommunicationCommunication

PlanningPlanning

ModelingModeling Analysis of requirementsAnalysis of requirements DesignDesign

ConstructionConstruction Code generationCode generation

TestingTesting

DeploymentDeployment


11/118

11

The CMMIThe CMMI

The CMMI defines each process area in terms ofThe CMMI defines each process area in terms of

specific goals and the specific practices required tospecific goals and the specific practices required to

achieve these goals.achieve these goals.

Specific goalsSpecific goals Specific practicesSpecific practices


12/118

12

The Primary Goal ofAny SoftwareThe Primary Goal ofAny Software

Process:Process: High QualityHigh Quality

Remember:Remember:

High quality = project timelinessHigh quality = project timeliness

Why?Why?

Less rework!Less rework!


13/118

13

Prescriptive ModelsPrescriptive Models


14/118

14

The Waterfall ModelThe Waterfall Model

Co i at io

la i

Modeli

Co t r t ioe lo e t

anal

sis

si nc

t st

roje t i i t iat io

re ire e t atheri e

ti ati

hed li

tra i

deli

er

ort

f e e d a


15/118

15

The Incremental ModelThe Incremental Model

o m m n

c a t

o n

l a n n

n!

M o d e l

n!

o n"

t r

c t

o n

#

e $ l o % m e n t

d e l

& e r% '

e e d

(

a c

)

0

1

0

l23

i3

4

5 3

i6

1

7 8

4

5

9

5 3

9

i # 1

i # 2

@

A

liB A C D E

F

1G

H

iI P C A Q A I

H

@

A

liB

A CD

E

F

2I

@

iI P C A Q A I

H

@

A

liB A C D E

F

nt h iR S T U V U R

t

i t #n

proj t cal ar t i

C o m m un i c a t i o n

P l a n n i n g

M o d e l i n g

C o ns t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

ana lWX

iX

des iY

n code

t e s t

C o m m un i c a t i o n

P l a n n i n g

M o d e l i n g

C o ns t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

ana lW s is

des iY

nc o d e

t e s t


16/118

16

The RAD ModelThe RAD Model

o i t io

l i

Modelibusi

ess ma

b

eli

gb

c

tc

ma

b

eli

gd

ra e

ess ma

b

eli

g

o t r t iocom

d

o

e

t reusec

ut omc

t iccode ge

erc

t io

t est i

g

De lo e t

60 - 90 d

Te m # 1

Model i f gbusi

h

ess model ih

g

di

ti

model ih

g p

rocess model ih

g

qo

f rt r

s tt io

f

comp

oh

eh

t reusei

ut omi

t ic code

geh

eri

t ioh

t es t ih

g

M o d e liu v

bus iw

es s m o d e l iw

g

dx

tx

m o de l iw

g

yroc es s m o d e l i

wg

ou

t r

t iou

c o my

ow

ew

t reus e

x

u t o mx

t ic c o de

gew

e rx

t iow

t es t iw

g

Te m # 2

Te m # n

i

t eg r

t io

delivery

feedb

ck


17/118

17

Evolutionary Models: PrototypingEvolutionary Models: Prototyping

Co uni at ion

u i

plan

Const ru t ionof

prototype

Mo d e l i n g

u i

des ign

elivery

e ed a

D pl nt

communication

Quickplan

ModelingQuick design

Construction

of prototype

Deploymentdelivery &feedback


18/118

18

Evolutionary Models: The SpiralEvolutionary Models: The Spiral

mm ni ati n

plannin

m lin

n tr ti npl m nt

li ry

f a

start

analy i

i n

t t

timati n

h lin

ri analy i


19/118

19

inceptioninception

The Unified Process (UP)The Unified Process (UP)


20/118

20

Software RequirementsSoftware Requirements


21/118

21

Types of requirementTypes of requirement

User requirementsUser requirements

Statements in natural language plus diagrams of the services theStatements in natural language plus diagrams of the services the

system provides and its operational constraints. Written forsystem provides and its operational constraints. Written for

customers.customers. System requirementsSystem requirements

A structured document setting out detailed descriptions of theA structured document setting out detailed descriptions of the

systems functions, services and operational constraints. Definessystems functions, services and operational constraints. Defines

what should be implemented so may be part of a contractwhat should be implemented so may be part of a contract

between client and contractor.between client and contractor.


22/118

22

Functional and nonFunctional and non functional requirementsfunctional requirements

Functional requirementsFunctional requirements Statements of services the system should provide, how the systemStatements of services the system should provide, how the system

should react to particular inputs and how the system should behave inshould react to particular inputs and how the system should behave inparticular situations.particular situations.

NonNon--functional requirementsfunctional requirements constraints on the services or functions offered by the system such asconstraints on the services or functions offered by the system such as

timing constraints, constraints on the development process, standards,timing constraints, constraints on the development process, standards,etc.etc.

Domain requirementsDomain requirements Requirements that come from the application domain of the system andRequirements that come from the application domain of the system and

that reflect characteristics of that domain.that reflect characteristics of that domain.


23/118

23

Requirements completeness and consistencyRequirements completeness and consistency

In principle, requirements should be both complete andIn principle, requirements should be both complete and

consistent.consistent.

CompleteComplete

They should include descriptions of all facilities required.They should include descriptions of all facilities required.

ConsistentConsistent

There should be no conflicts or contradictions in the descriptionsThere should be no conflicts or contradictions in the descriptions

of the system facilities.of the system facilities.

In practice, it is impossible to produce a complete andIn practice, it is impossible to produce a complete and

consistent requirements document.consistent requirements document.


24/118

24

NonNon functional classificationsfunctional classifications

Product requirementsProduct requirements

Requirements which specify that the delivered product must behave in aRequirements which specify that the delivered product must behave in a

particular way e.g. execution speed, reliability, etc.particular way e.g. execution speed, reliability, etc.

Organisational requirementsOrganisational requirements Requirements which are a consequence of organisational policies andRequirements which are a consequence of organisational policies and

procedures e.g. process standards used, implementation requirements,procedures e.g. process standards used, implementation requirements,

etc.etc.

External requirementsExternal requirements

Requirements which arise from factors which are external to the systemRequirements which arise from factors which are external to the system

and its development process e.g. interoperability requirements,and its development process e.g. interoperability requirements,

legislative requirements, etc.legislative requirements, etc.


25/118

25

Requirements measuresRequirements measuresProperty Measure

Speed Processed transactions/second

User/Event response time

Screen refresh time

Size M Bytes

Number of ROM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failure

Probability of unavailability

Rate of failure occurrence

Availability

Robustness Timeto restart after failure

Percentage of events causing failure

Probability of data corruption on failure

Portability Percentage of target dependent statements

Number of target systems


26/118

26

User requirementsUser requirements

Should describe functional and nonShould describe functional and non--functionalfunctional

requirements in such a way that they are understandablerequirements in such a way that they are understandable

by system users who dont have detailed technicalby system users who dont have detailed technical

knowledge.knowledge. User requirements are defined using natural language,User requirements are defined using natural language,

tables and diagrams as these can be understood by alltables and diagrams as these can be understood by all

users.users.


27/118

27

Problems with natural languageProblems with natural language

Lack of clarityLack of clarity

Precision is difficult without making the document difficult toPrecision is difficult without making the document difficult to

read.read.

Requirements confusionRequirements confusion Functional and nonFunctional and non--functional requirements tend to be mixedfunctional requirements tend to be mixed--up.up.

Requirements amalgamationRequirements amalgamation

Several different requirements may be expressed together.Several different requirements may be expressed together.


28/118

28

Guidelines for writing requirementsGuidelines for writing requirements

Invent a standard format and use it for all requirements.Invent a standard format and use it for all requirements.

Use language in a consistent way. Use shall forUse language in a consistent way. Use shall for

mandatory requirements, should for desirablemandatory requirements, should for desirable

requirements.requirements.

Avoid the use of computer jargon.Avoid the use of computer jargon.


29/118

29

System requirementsSystem requirements

More detailed specifications of system functions,More detailed specifications of system functions,services and constraints than user requirements.services and constraints than user requirements.

They are intended to be a basis for designing theThey are intended to be a basis for designing the

system.system. They may be incorporated into the system contract.They may be incorporated into the system contract.


30/118

30

Problems with NL specificationProblems with NL specification

AmbiguityAmbiguity The readers and writers of the requirement must interpret theThe readers and writers of the requirement must interpret the

same words in the same way. NL is naturally ambiguous so thissame words in the same way. NL is naturally ambiguous so thisis very difficult.is very difficult.

OverOver--flexibilityflexibility The same thing may be said in a number of different ways in theThe same thing may be said in a number of different ways in the

specification.specification.

Lack of modularisationLack of modularisation NL structures are inadequate to structure system requirements.NL structures are inadequate to structure system requirements.


31/118

31

Alternatives to NL specificationAlternatives to NL specification

Notation Descri tion

Structured natural

language

This approach depends on de ining standard orms or templates to express the

requirements speci ication.

Design

descriptionlanguages

This approach uses a language like a programming language but with more abstract

eatures to speci y the requirements by de ining an operational model o the system.This approach is not now widely used although it can be use ul or inter acespeci ications.

Graphical

notations

graphical language, supplemented by text annotations is used to de ine the

unctional requirements or the system. n early example o such a graphical

language was SADT. ow, use-case descriptions and sequence d iagrams arecommonly used .

athematicalspeci ications

These are notations based on mathematical concep ts such as inite-state machines orsets. These unambiguous speci ications reduce the arguments between customer and

contractor about system unctionality. Howeve r, most customers dont understandormal speci ications and are reluctant to accept it as a system contract.


32/118

32

The requirements documentThe requirements document

The requirements document is the official statement ofThe requirements document is the official statement of

what is required of the system developers.what is required of the system developers.

Should include both a definition of user requirements andShould include both a definition of user requirements and

a specification of the system requirements.a specification of the system requirements.

It is NOT a design document. As far as possible, itIt is NOT a design document. As far as possible, it

should set of WHAT the system should do rather thanshould set of WHAT the system should do rather than

HOW it should do itHOW it should do it


33/118

33

IEEE requirements standardIEEE requirements standard

Defines a generic structure for a requirements documentDefines a generic structure for a requirements document

that must be instantiated for each specific system.that must be instantiated for each specific system.

Introduction.Introduction.

General description.General description. Specific requirements.Specific requirements.

Appendices.Appendices.

Index.Index.


34/118

34

Requirements document structureRequirements document structure

PrefacePreface

IntroductionIntroduction

GlossaryGlossary

User requirements definitionUser requirements definition System architectureSystem architecture

System requirements specificationSystem requirements specification

System modelsSystem models

System evolutionSystem evolution

AppendicesAppendices

IndexIndex


35/118

35

Requirements EngineeringRequirements Engineering

ProcessesProcesses


36/118

36

Feasibility studiesFeasibility studies

Requirements elicitation and analysisRequirements elicitation and analysis

Requirements validationRequirements validation

Requirements managementRequirements management

The requirements engineering processThe requirements engineering process


37/118

37

Feasibility studiesFeasibility studies

A feasibility study decides whether or not the proposedA feasibility study decides whether or not the proposed

system is worthwhile.system is worthwhile.

A short focused study that checksA short focused study that checks

If the system contributes to organisational objectives;If the system contributes to organisational objectives;

If the system can be engineered using current technology andIf the system can be engineered using current technology and

within budget;within budget;

If the system can be integrated with other systems that are used.If the system can be integrated with other systems that are used.


38/118

38

Elicitation and analysisElicitation and analysis

Sometimes called requirements elicitation orSometimes called requirements elicitation or

requirements discovery.requirements discovery.

Involves technical staff working with customers to findInvolves technical staff working with customers to find

out about the application domain, the services that theout about the application domain, the services that thesystem should provide and the systems operationalsystem should provide and the systems operational

constraints.constraints.

May involve endMay involve end--users, managers, engineers involved inusers, managers, engineers involved in

maintenance, domain experts, trade unions, etc. Thesemaintenance, domain experts, trade unions, etc. Theseare calledare called stakeholders.stakeholders.


39/118

39

Process activitiesProcess activities

Requirements discoveryRequirements discovery Interacting with stakeholders to discover their requirements.Interacting with stakeholders to discover their requirements.

Domain requirements are also discovered at this stage.Domain requirements are also discovered at this stage.

Requirements classification and organisationRequirements classification and organisation Groups related requirements and organises them into coherentGroups related requirements and organises them into coherent

clusters.clusters.

Prioritisation and negotiationPrioritisation and negotiation Prioritising requirements and resolving requirements conflicts.Prioritising requirements and resolving requirements conflicts.

Requirements documentationRequirements documentation Requirements are documented and input into the next round ofRequirements are documented and input into the next round of

the spiral.the spiral.


40/118

40

ATM stakeholdersATM stakeholders

Bank customersBank customers

Representatives of other banksRepresentatives of other banks

Bank managersBank managers

Counter staffCounter staff Database administratorsDatabase administrators

Security managersSecurity managers

Marketing departmentMarketing department

Hardware and software maintenance engineersHardware and software maintenance engineers Banking regulatorsBanking regulators


41/118

41

ViewpointsViewpoints

Viewpoints are a way of structuring the requirements toViewpoints are a way of structuring the requirements to

represent the perspectives of different stakeholders.represent the perspectives of different stakeholders.

Stakeholders may be classified under differentStakeholders may be classified under different

viewpoints.viewpoints. This multiThis multi--perspective analysis is important as there isperspective analysis is important as there is

no single correct way to analyse system requirements.no single correct way to analyse system requirements.


42/118

42

Types of viewpointTypes of viewpoint

Interactor viewpointsInteractor viewpoints People or other systems that interact directly with the system. InPeople or other systems that interact directly with the system. In

an ATM, the customers and the account database are interactoran ATM, the customers and the account database are interactorVPs.VPs.

Indirect viewpointsIndirect viewpoints Stakeholders who do not use the system themselves but whoStakeholders who do not use the system themselves but who

influence the requirements. In an ATM, management andinfluence the requirements. In an ATM, management andsecurity staff are indirect viewpoints.security staff are indirect viewpoints.

Domain viewpointsDomain viewpoints Domain characteristics and constraints that influence theDomain characteristics and constraints that influence the

requirements. In an ATM, an example would be standards forrequirements. In an ATM, an example would be standards forinterinter--bank communications.bank communications.


43/118

43

LIBSYS viewpoint hierarchyLIBSYS viewpoint hierarchy


44/118

44

InterviewingInterviewing

In formal or informal interviewing, the RE team putsIn formal or informal interviewing, the RE team putsquestions to stakeholders about the system that they usequestions to stakeholders about the system that they useand the system to be developed.and the system to be developed.

There are two types of interviewThere are two types of interview Closed interviews where a preClosed interviews where a pre--defined set of questions aredefined set of questions are

answered.answered.

Open interviews where there is no preOpen interviews where there is no pre--defined agenda and adefined agenda and arange of issues are explored with stakeholders.range of issues are explored with stakeholders.


45/118

45

ScenariosScenarios

Scenarios are realScenarios are real--life examples of how a system can belife examples of how a system can be

used.used.

They should includeThey should include

A description of the starting situation;A description of the starting situation;

A description of the normal flow of events;A description of the normal flow of events;

A description of what can go wrong;A description of what can go wrong;

Information about other concurrent activities;Information about other concurrent activities;

A description of the state when the scenario finishes.A description of the state when the scenario finishes.


46/118

46

Use casesUse cases

UseUse--cases are a scenario based technique in the UMLcases are a scenario based technique in the UML

which identify the actors in an interaction and whichwhich identify the actors in an interaction and which

describe the interaction itself.describe the interaction itself.

A set of use cases should describe all possibleA set of use cases should describe all possibleinteractions with the system.interactions with the system.

Sequence diagrams may be used to add detail to useSequence diagrams may be used to add detail to use--

cases by showing the sequence of event processing incases by showing the sequence of event processing in

the system.the system.


47/118

47

EthnographyEthnography

A social scientists spends a considerable time observingA social scientists spends a considerable time observing

and analysing how people actually work.and analysing how people actually work.

People do not have to explain or articulate their work.People do not have to explain or articulate their work.

Social and organisational factors of importance may beSocial and organisational factors of importance may beobserved.observed.

Ethnographic studies have shown that work is usuallyEthnographic studies have shown that work is usually

richer and more complex than suggested by simplericher and more complex than suggested by simple

system models.system models.


48/118

48

Requirements checkingRequirements checking

ValidityValidity. Does the system provide the functions which. Does the system provide the functions which

best support the customers needs?best support the customers needs?

ConsistencyConsistency. Are there any requirements conflicts?. Are there any requirements conflicts?

CompletenessCompleteness. Are all functions required by the. Are all functions required by thecustomer included?customer included?

RealismRealism. Can the requirements be implemented given. Can the requirements be implemented given

available budget and technologyavailable budget and technology

VerifiabilityVerifiability. Can the requirements be checked?. Can the requirements be checked?


49/118

49

Requirements reviewsRequirements reviews

Regular reviews should be held while the requirementsRegular reviews should be held while the requirements

definition is being formulated.definition is being formulated.

Both client and contractor staff should be involved inBoth client and contractor staff should be involved in

reviews.reviews. Reviews may be formal (with completed documents) orReviews may be formal (with completed documents) or

informal. Good communications between developers,informal. Good communications between developers,

customers and users can resolve problems at an earlycustomers and users can resolve problems at an early

stage.stage.


50/118

50

Requirements evolutionRequirements evolution


51/118

51

Enduring and volatile requirementsEnduring and volatile requirements

Enduring requirementsEnduring requirements. Stable requirements derived. Stable requirements derived

from the core activity of the customer organisation. E.g.from the core activity of the customer organisation. E.g.

a hospital will always have doctors, nurses, etc. May bea hospital will always have doctors, nurses, etc. May be

derived from domain modelsderived from domain models Volatile requirementsVolatile requirements. Requirements which change. Requirements which change

during development or when the system is in use. In aduring development or when the system is in use. In a

hospital, requirements derived from healthhospital, requirements derived from health--care policycare policy


52/118


53/118

53

System modelsSystem models


54/118


55/118

55

Analysis ModelAnalysis Model > Design Model> Design Model

A lysis Model

use-c

ses- text

use-c

sedi

gr

ms

ctivity di

gr

ms

swim l

edi

gr

ms

d

t

flowdi

gr

ms

co

trol-flowdi

gr

ms

rocessi

g

rr

tives

flo

ori e nt e d

e l e

e nt s

e

a

i ora le l e

en t s

lass

ased

e l e

e nt s

s

e na ri o

ased

e l e e n t s

cl

ssdi

gr

ms

lysis

ck

ges

CRC modelscoll

bor

t io

di

gr

ms

st

tedi

gr

ms

seque

cedi

gr

msD a t a /

lass Des ign

A rh it e

t

ra l Des ign

In t e r fa

e D e s i g n

o

o n e nt -

e

e l Des ign

esig Model


56/118

56

Design PrinciplesDesign Principles

The design process should not suffer from tunnel vision.The design process should not suffer from tunnel vision.

The design should be traceable to the analysis model.The design should be traceable to the analysis model.

The design should not reinvent the wheel.The design should not reinvent the wheel.

The design should exhibit uniformity and integration.The design should exhibit uniformity and integration.

The design should be structured to accommodate change.The design should be structured to accommodate change. Design is not coding, coding is not design.Design is not coding, coding is not design.

The design should be assessed for qualityThe design should be assessed for quality

The design should be reviewed to minimize conceptualThe design should be reviewed to minimize conceptual

(semantic) errors.(semantic) errors.


57/118


58/118

58

ArchitectureArchitecture

The overall structure of the software and the ways inThe overall structure of the software and the ways inwhich that structure provides conceptual integrity for awhich that structure provides conceptual integrity for asystem.system.

Structural properties.Structural properties. -- defines the components of a system (e.g., modules, objects,defines the components of a system (e.g., modules, objects,

filters)filters)

ExtraExtra--functional properties.functional properties. -- performance, capacity, reliability, security,performance, capacity, reliability, security,

adaptability, and other system characteristics.adaptability, and other system characteristics.

Families of related systems.Families of related systems. -- the design should have the ability to reusethe design should have the ability to reuse


59/118

59

PatternsPatternsDesign Pattern TemplateDesign Pattern Template

Pattern namePattern namedescribes the essence of the pattern in a short but expressive namedescribes the essence of the pattern in a short but expressive name

IntentIntentdescribes the pattern and what it doesdescribes the pattern and what it does

AlsoAlso--knownknown--asaslists any synonyms for the patternlists any synonyms for the pattern

MotivationMotivationprovides an example of the problemprovides an example of the problem

ApplicabilityApplicabilitynotes specific design situations in which the pattern is applicablenotes specific design situations in which the pattern is applicable

StructureStructuredescribes the classes that are required to implement the patterndescribes the classes that are required to implement the pattern

ParticipantsParticipantsdescribes the responsibilities of the classes that are required to implementdescribes the responsibilities of the classes that are required to implement

the patternthe pattern

CollaborationsCollaborationsdescribes how the participants collaborate to carry out theirdescribes how the participants collaborate to carry out their

responsibilitiesresponsibilities

ConsequencesConsequencesdescribes the design forces that affect the pattern and the potentialdescribes the design forces that affect the pattern and the potential

tradetrade--offs that must be considered when the pattern is implementedoffs that must be considered when the pattern is implemented

RelatedpatternsRelatedpatternscrosscross--references related design patternsreferences related design patterns


60/118

60

Modular DesignModular Design

easiert ild,easiert ange,easiert fix...


61/118


62/118

62

WhyInformation Hiding?WhyInformation Hiding?

reduces the likelihood of side effectsreduces the likelihood of side effects

emphasizes communication throughemphasizes communication through

controlled interfacescontrolled interfaces

results in higher quality softwareresults in higher quality software


63/118

63

Stepwise RefinementStepwise Refinement

open

walk to door;reach for knob;

open door;

walk through;close door.

repeat until door opensturn knob clockwise;if knob doesn't turn, then

take key out;find correct key;insert in lock;

endif

pull/push doormove out of way;end repeat

AbstractionAbstraction-- Suppress of low level detailsSuppress of low level details

RefinementRefinement-- Description of low level detailsDescription of low level details


64/118


65/118


66/118

66

Why Architecture?Why Architecture?

The architecture is not the operational software. Rather, it isThe architecture is not the operational software. Rather, it isa representation that enables a software engineer to:a representation that enables a software engineer to:

(1)(1)analyze the effectivenessanalyze the effectiveness

(2)(2) consider architectural alternatives at a stage whenconsider architectural alternatives at a stage when

making design changes is still relatively easy, andmaking design changes is still relatively easy, and

(3) reduce the risks associated with the construction of the(3) reduce the risks associated with the construction of thesoftware.software.


67/118

67

Architectural StylesArchitectural Styles

DataData--centered architecturescentered architectures

Data flow architecturesData flow architectures

Call and return architecturesCall and return architectures

ObjectObject--oriented architecturesoriented architectures Layered architecturesLayered architectures

Each style describes a system category that encompasses:Each style describes a system category that encompasses:

(1)(1) aa set of componentsset of components

(2)(2) aa set of connectorsset of connectors

(3)(3) constraintsconstraints

(4)(4) semantic modelssemantic models


68/118

68

DataData--Centered ArchitectureCentered Architecture


69/118

69

Data Flow ArchitectureData Flow Architecture


70/118

70

Call and Return ArchitectureCall and Return Architecture


71/118

71

Layered ArchitectureLayered Architecture


72/118

72

Architectural PatternsArchitectural Patterns

ConcurrencyConcurrencyapplications must handle multipleapplications must handle multiple

tasks in a manner that simulates parallelismtasks in a manner that simulates parallelism

PersistencePersistenceData persists if it survives past theData persists if it survives past the

execution of the process that created it.execution of the process that created it.

DistributionDistribution the manner in which systems orthe manner in which systems orcomponents within systems communicate withcomponents within systems communicate with

one another in a distributed environmentone another in a distributed environment

AA brokerbrokeracts as a middleacts as a middle--man between the clientman between the client

component and a server component.component and a server component.


73/118

73

Architectural Context DiagramArchitectural Context Diagram


74/118

74

Architectural ContextArchitectural Context

tar t y t m:

S rity F n ti n

p rh m n r

Saf h mPr t

Int rn t ay t m

r illan

f n ti n

n r

ntr l

pan l

n r


75/118

75

Modeling

Component

Modeling

Component LevelLevelDesignDesign


76/118

76

Interface DesignInterface Design

Easy to use?Easy to use?

Easy to understand?Easy to understand?

Easy to learn?Easy to learn?


77/118

77

Interface DesignInterface Design

lack of consistencylack of consistency

too much memorizationtoo much memorization

no guidance helpno guidance helpno context sensitivityno context sensitivity

poor responsepoor response

Arcane unfriendlyArcane unfriendly

TypicalDesi ErrorsTypicalDesi Errors


78/118


79/118

79

UserInterface Design ModelsUserInterface Design Models

User modelUser model a profile of all end users of thea profile of all end users of the

systemsystem

Design modelDesign model a design realization of the usera design realization of the user

modelmodel Mental model (system perception)Mental model (system perception) the usersthe users

mental image of what the interface ismental image of what the interface is

Implementation modelImplementation model the interface look andthe interface look and

feel coupled with supporting information thatfeel coupled with supporting information that

describe interface syntax and semanticsdescribe interface syntax and semantics


80/118

80

Interface Design PatternsInterface Design Patterns

Patterns are available forPatterns are available for

The complete UIThe complete UI

Page layoutPage layout

Forms and inputForms and input TablesTables

Direct data manipulationDirect data manipulation

NavigationNavigation

SearchingSearching

Page elementsPage elements

ee--CommerceCommerce


81/118

81

Design IssuesDesign Issues

Response timeResponse time

Help facilitiesHelp facilities

Error handlingError handling

Menu and command labelingMenu and command labeling

Application accessibilityApplication accessibility

InternationalizationInternationalization


82/118

82

Design Evaluation CycleDesign Evaluation Cycle

preliminarydesign

buildprototype #1

interface

evaluationis studied by

designer

designmodifications

are made

buildprototype # n

interface

userevaluate'sinterface

Interface designis complete


83/118

83

ObjectObject--oriented Designoriented Design


84/118

84

Advantages ofOODAdvantages ofOOD

Easier maintenance. Objects may beEasier maintenance. Objects may be

understood as standunderstood as stand--alone entities.alone entities.

Objects are potentially reusable components.Objects are potentially reusable components.

For some systems, there may be an obviousFor some systems, there may be an obviousmapping from real world entities to systemmapping from real world entities to system

objects.objects.


85/118

85

The Unified Modeling LanguageThe Unified Modeling Language

Several different notations for describing objectSeveral different notations for describing object--orientedoriented

designs were proposed in the 1980s and 1990s.designs were proposed in the 1980s and 1990s.

The Unified Modeling Language is an integration ofThe Unified Modeling Language is an integration of

these notations.these notations. It describes notations for a number of different modelsIt describes notations for a number of different models

that may be produced during OO analysis and design.that may be produced during OO analysis and design.


86/118

86

Employee object class (UML)Employee object class (UML)


87/118


88/118

88

Software TestingSoftware Testing

Testing is the process of exercising aTesting is the process of exercising a

program with the specific intent of findingprogram with the specific intent of finding

errors prior to delivery to the end user.errors prior to delivery to the end user.


89/118


90/118

90

Testing StrategyTesting Strategy

We begin by We begin by testingtesting--inin--thethe--smallsmall and move towardand move toward

testingtesting--inin--thethe--largelarge


91/118

91

Unit TestingUnit Testing

interfaceinterface

local data structureslocal data structures

boundary conditionsboundary conditions

independent pathsindependent paths

error handling pathserror handling paths

modulemoduleto beto betestedtested

test casestest cases


92/118

92

Integration Testing StrategiesIntegration Testing Strategies

Options:Options:

the big bang approachthe big bang approach

an incremental construction strategyan incremental construction strategy


93/118

93

Top Down IntegrationTop Down Integration

top module is tested withtop module is tested withstubsstubs

stubs are replaced one atstubs are replaced one ata time, "depth first"a time, "depth first"

as new modules are integrated,as new modules are integrated,some subset of tests is resome subset of tests is re--runrun

AA

BB

CC

DD EE

FF GG


94/118

94

BottomBottom--Up IntegrationUp Integration

drivers are replaced one at adrivers are replaced one at atime, "depth first"time, "depth first"

worker modules are grouped intoworker modules are grouped intobuilds and integratedbuilds and integrated

AA

BB

CC

DD EE

FF GG

clustercluster


95/118

95

Sandwich TestingSandwich Testing

Top modules areTop modules are

tested with stubstested with stubs

Worker modules are grouped intoWorker modules are grouped intobuilds and integratedbuilds and integrated

AA

BB

CC

DD EE

FF GG

clustercluster


96/118

96

Smoke TestingSmoke Testing

A common approach for creating dailyA common approach for creating dailybuilds for product softwarebuilds for product software


97/118

97

High Order TestingHigh Order Testing

Validation testingValidation testing Focus is on software requirementsFocus is on software requirements

System testingSystem testing

Focus is on system integrationFocus is on system integration

Alpha/Beta testingAlpha/Beta testing Focus is on customer usageFocus is on customer usage

Recovery testingRecovery testing forces the software to fail in a variety of ways and verifies that recovery isforces the software to fail in a variety of ways and verifies that recovery is

properly performedproperly performed Security testingSecurity testing

verifies that protection mechanisms built into a system will, in fact, protect itverifies that protection mechanisms built into a system will, in fact, protect itfrom improper penetrationfrom improper penetration

Stress testingStress testing

executes a system in a manner that demands resources in abnormal quantity,executes a system in a manner that demands resources in abnormal quantity,frequency, or volumefrequency, or volume

Performance TestingPerformance Testing

test the runtest the run--time performance of software within the context of an integratedtime performance of software within the context of an integratedsystemsystem


98/118

98

The Debugging ProcessThe Debugging Process

test casestest cases

resultsresults

DebuggingDebugging

suspectedsuspectedcausescauses

identifiedidentifiedcausescauses

correctionscorrections

regressionregressionteststests

new testnew testcasescases


99/118

99

Consequences ofBugsConsequences ofBugs

damagedamage

mildmildannoyingannoying

disturbingdisturbingseriousserious

extremeextremecatastrophiccatastrophic

infectiousinfectious

Bug TypeBug Type

Bug Categories:Bug Categories: functionfunction--related bugs,related bugs,systemsystem--related bugs, data bugs, coding bugs,related bugs, data bugs, coding bugs,design bugs, documentation bugs, standardsdesign bugs, documentation bugs, standardsviolations, etc.violations, etc.


100/118

100

Project RisksProject RisksWhatcango wrong?Whatcangowrong?Whati thelikelihood?Whati thelikelihood?Whatwillthedamagebe?Whatwillthedamagebe?

Whatcanwedoaboutit?Whatcanwedoaboutit?


101/118

101

Reactive Risk ManagementReactive Risk Management project team reacts to risks when they occurproject team reacts to risks when they occur

mitigationmitigationplan for additional resources in anticipationplan for additional resources in anticipation

of fire fightingof fire fighting

fix on failurefix on failureresource are found and applied whenresource are found and applied whenthe risk strikesthe risk strikes


102/118

102

Proactive RiskM

anagementProactive RiskM

anagement formal risk analysis is performedformal risk analysis is performed

organization corrects the root causes of riskorganization corrects the root causes of risk

examining risk sources that lie beyond the bounds of theexamining risk sources that lie beyond the bounds of the

softwaresoftware


103/118

103

RISK

Risk Management ParadigmRisk Management Paradigm

controlcontrol

identifyidentify

analyzeanalyze

planplan

tracktrack


104/118

104

Risk ComponentsRisk Components

performance riskperformance riskthe degree of uncertainty that thethe degree of uncertainty that the

product will meet its requirements and be fit for itsproduct will meet its requirements and be fit for its

intended use.intended use.

cost riskcost riskthe degree of uncertainty that the projectthe degree of uncertainty that the projectbudget will be maintained.budget will be maintained.

support risksupport riskthe degree of uncertainty that the resultantthe degree of uncertainty that the resultant

software will be easy to correct, adapt, and enhance.software will be easy to correct, adapt, and enhance.

schedule riskschedule riskthe degree of uncertainty that the projectthe degree of uncertainty that the project

schedule will be maintained and that the product will beschedule will be maintained and that the product will be

delivered on time.delivered on time.


105/118

105

Building a Risk TableBuilding a Risk Table

RiskRisk ProbabilityProbability ImpactImpact RMMMRMMM

RiskRisk

MitigationMitigationMonitoringMonitoring

&&

ManagementManagement


106/118

106

mitigationmitigationhow can we avoid the risk?how can we avoid the risk?

monitoringmonitoringwhat factors can we track that willwhat factors can we track that will

enable us to determine if the risk is becoming moreenable us to determine if the risk is becoming moreor less likely?or less likely?

managementmanagementwhat contingency plans do we havewhat contingency plans do we haveif the risk becomes a reality?if the risk becomes a reality?

Risk Mitigation, Monitoring,Risk Mitigation, Monitoring,

and Managementand Management


107/118

107

Recording Risk InformationRecording Risk Information


108/118

108

A Good ManagerMeasuresA Good ManagerMeasures

measurementmeasurement

What do weWhat do weuse as ause as abasis?basis? size? size? function? function?

project metricsproject metrics

process metricsprocess metricsprocessprocess

productproduct

product metricsproduct metrics


109/118

109

Process MetricsProcess Metrics

QualityQuality--relatedrelated

focus on quality of work products and deliverablesfocus on quality of work products and deliverables

ProductivityProductivity--relatedrelated

Production of workProduction of work--products related to effort expendedproducts related to effort expended

Statistical SQA dataStatistical SQA data

error categorization & analysiserror categorization & analysis Defect removal efficiencyDefect removal efficiency

propagation of errors from process activity to activitypropagation of errors from process activity to activity

Reuse dataReuse data

The number of components produced and their degree of reusabilityThe number of components produced and their degree of reusability


110/118

110

Measuring QualityMeasuring Quality

CorrectnessCorrectness the degree to which a program operatesthe degree to which a program operates

according to specificationaccording to specification

MaintainabilityMaintainabilitythe degree to which a program isthe degree to which a program is

amenable to changeamenable to change IntegrityIntegritythe degree to which a program is imperviousthe degree to which a program is impervious

to outside attackto outside attack

UsabilityUsabilitythe degree to which a program is easy to usethe degree to which a program is easy to use

C t f Q litC t f Q lit


111/118

111

Cost of QualityCost of Quality

Prevention costsPrevention costs includeinclude quality planningquality planning

formal technical reviewsformal technical reviews

test equipmenttest equipment

TrainingTraining

Internal failure costsInternal failure costs includeinclude

reworkrework repairrepair

failure mode analysisfailure mode analysis

External failure costsExternal failure costs areare

complaint resolutioncomplaint resolution

product return and replacementproduct return and replacement

help line supporthelp line support warranty workwarranty work


112/118

112

Software Quality AssuranceSoftware Quality Assurance

FormalTechnicalReviews

TestPlanning& Review

Measurement

Analysis&

Reporting

ProcessDefinition &Standards


113/118

113

What Are Reviews?What Are Reviews? a meeting conducted by technical people fora meeting conducted by technical people for

technical peopletechnical people

a technical assessment of a work producta technical assessment of a work product

created during the software engineeringcreated during the software engineering

processprocess

a software quality assurance mechanisma software quality assurance mechanism

a training grounda training ground


114/118

114

What Reviews Are NotWhat Reviews Are Not

A project summary or progress assessmentA project summary or progress assessment

A meeting intended solely to impart informationA meeting intended solely to impart information

A mechanism for political or personal reprisal!A mechanism for political or personal reprisal!


115/118


116/118

St ti ti l SQASt ti ti l SQA


117/118

117

Statistical SQAStatistical SQA

ProductProduct

& Process& Process

measurement

... an understandingofhowto improve quality...

Collect information on all defectsFind the causes of the defectsMove to provide fixes for the process


118/118

SixSix--Sigma for Software EngineeringSigma for Software Engineering

The term six sigma is derived from six standard deviationsThe term six sigma is derived from six standard deviations3.4 instances3.4 instances

(defects) per million occurrences(defects) per million occurrencesimplying an extremely high qualityimplying an extremely high quality

standard.standard.

The Six Sigma methodology defines three core steps:The Six Sigma methodology defines three core steps:

DefineDefine

MeasureMeasure

AnalyzeAnalyze

Existing system with improvementsExisting system with improvements

ImproveImprove

Control

New system Design

Verify

Software Engineering Lecture

Documents