introduction to software engineering - · pdf filesoftware engineering contents: 1. unified...

Software Engineering

Contents:

1. Unified Modelling Language – 2

2. Software Testing – 66

3. Software Reliability – 142

4. Software Project Management – 160

5. Software Quality Management – 214

6. Software Maintenance and CASE – 350

7. Software Reuse – 439

8. Component Based Development – 461

KIDS Information Center 1

2

UML is a modelling language

Not a system design or development methodology

Used to document object-oriented analysis and design

Independent of any specific design methodology

Object

modelling using UML

KIDS Information Center

3

Based Principally on

OMT [Rumbaugh 1991]

Booch’s methodology[Booch 1991]

OOSE [Jacobson 1992]

Odell’s methodology[Odell 1992]

Shlaer and Mellor [Shlaer 1992]

UML


4

UML

UML

Booch

Methodology OOSE

OMT

Different object modelling techniques in UML


5

Model is required to capture only important aspects

UML a graphical modelling tool, easy to understand and construct

Helps in managing complexity

Why UML is required?


6

Nine diagrams to capture different views of a system

Provide different perspectives of the software system

Diagrams can be refined to get the actual implementation of the system

UML diagrams


7

Views of a system

User’s view

Structural view

Behavioral view

Implementation view

Environmental view

UML diagrams


8

UML diagrams

User’s View

-Use Case

Diagram

Structural View

- Class Diagram

- Object Diagram

Implementation View

- Component Diagram

Environmental View

- Deployment Diagram

Behavioural View

- Sequence Diagram

- Collaboration Diagram

- State-chart Diagram

- Activity Diagram

Diagrams and views in UML


9

NO

Use case model, class diagram and one of the interaction diagram for a simple system

State chart diagram in case of many state changes

Deployment diagram in case of large number of hardware components

Are all views required?


10

Use Case model

Consists of set of “use cases”

An important analysis and design artifact

Other models must confirm to this model

Not really an object-oriented model

Represents a functional or process model


11

Use Cases

Different ways in which system can be used by the users

Corresponds to the high-level requirements

Represents transaction between the user and the system

Define behavior without revealing internal structure of system

Set of related scenarios tied together by a common goal


12

Use Cases

Normally, use cases are independent of each other

Implicit dependencies may exist

Example: In Library Automation System, renew-book & reserve-book are independent use cases. But in actual implementation of renew-book, a check is made to see if any book has been reserved using reserve-book


13

Example of

Use Cases

For library information system

issue-book

Query-book

Return-book

Create-member

Add-book, etc.


14

Representation of

Use Cases

Represented by use case diagram

Use case is represented by ellipse

System boundary is represented by rectangle

Users are represented by stick

person icon (actor)

Communication relationship between actor and use case by line

External system by stereotype


15

Example of

Use Cases

Use case model

Tic-tac-toe game

Play Move

Player


16

Why develop

Use Case diagram?

Serves as requirements specification

Users identification helps in implementing security mechanism through login system

Another use in preparing the documents (e.g. user’s manual)


17

Factoring

Use Cases

Complex use cases need to be factored into simpler use cases

Represent common behavior across different use cases

Three ways of factoring

Generalization

Includes

Extends


18

Factoring Using

Generalization

Pay membership fee

Pay through library pay card Pay through credit card

Use case generalization


19

Factoring Using

Includes

Base use case

Use case inclusion

Common

use case

<<include>>

Base use case

Base use case Base use case Base use case

Base use case

<<include>>

<<include>>

<<include>>

<<include>>

Paralleling model


20

Factoring Using

Extends

Base

use case

Use case extension

Common

use case

<<extends>>


21

Class diagram

Describes static structure of a system

Main constituents are classes and their relationships:

Generalization

Aggregation

Association

Various kinds of dependencies


22

Class diagram

Entities with common features, i.e. attributes and operations

Classes are represented as solid outline rectangle with compartments

Compartments for name, attributes & operations

Attribute and operation compartment are optional for reuse purpose


23

Example of

Class diagram

Different representations of the LibraryMember class

LibraryMember

Member Name

Membership Number

Address

Phone Number

E-Mail Address

Membership Admission Date

Membership Expiry Date

Books Issued

issueBook( );

findPendingBooks( );

findOverdueBooks( );

returnBook( );

findMembershipDetails( );

LibraryMember

Member Name

Membership Number

Address

Phone Number

E-Mail Address

Membership Admission Date

Membership Expiry Date

Books Issued

LibraryMember


24

Association Relationship

Association between two classes

Library Member Book 1 * borrowed by


25

Aggregation Relationship

Represent a whole-part relationship

Represented by diamond symbol at

the composite end

Cannot be reflexive(i.e. recursive)

Not symmetric

It can be transitive


26

Aggregation Relationship

Representation of aggregation

Document Line 1 *

Paragraph 1 *


27

Composition Relationship

Representation of composition

Order 1 *

Item

Life of item is same as the order


28

Class Dependency

Representation of dependence between class

Dependent Class Independent Class


29

Object diagram

Different representations of the LibraryMember object

LibraryMember

Mritunjay

B10028

C-108, Laksmikant Hall

1119

Mrituj@cse

25-02-04

25-03-06

NIL

IssueBook( );

findPendingBooks( );

findOverdueBooks( );

returnBook( );

findMembershipDetails( );

LibraryMember

Mritunjay

B10028

C-108, Laksmikant Hall

1119

Mrituj@cse

25-02-04

25-03-06

NIL

LibraryMember


30

Interaction diagram

Models how groups of objects collaborate to realize some behaviour

Typically each interaction diagram realizes behaviour of a single use case


31

Interaction diagram

Two kinds: Sequence &

Collaboration

Two diagrams are equivalent but portrays different perspective

These diagram play a very important role in the design process


32

Sequence diagram

Shows interaction among objects as two-dimensional chart

Objects are shown as boxes at top

If object created during execution then shown at appropriate place

Objects existence are shown as

dashed lines (lifeline)

Objects activeness, shown as

rectangle on lifeline


33

Sequence diagram

Messages are shown as arrows

Message labelled with message name

Message can be labelled with control

information

Two types of control information:

condition ([]) & an iteration (*)


34

Example of

Sequence diagram

:Library

Boundary

:Library

Book

Renewal

Controller

:Library

Book

Register

:Book :Library

Member

renewBook

displayBorrowing

selectBooks

[reserved]

apology

confirm

find MemberBorrowing

bookSelected

* find

update

[reserved]

apology

confirm

updateMemberBorrowing

Sequence Diagram for the renew book use case KIDS Information Center

35

Collaboration diagram

Shows both structural and behavioural

aspects

Objects are collaborator, shown as boxes

Messages between objects shown as a solid

line

Message is shown as a labelled arrow placed near the link

Messages are prefixed with sequence

numbers to show relative sequencing


36

Example of

Collaboration diagram

:Library

Boundary

:Library

Book

Renewal

Controller

:Library

Book

Register

:Book

:Library

Member

1: renewBook

3: display

Borrowing

4: selectBooks

[reserved]

8: apology

12: confirm

2: findMemberBorrowing

5: book

Selected

6: * find

9: update

[reserved]

7: apology

10: confirm

updateMemberBorrowing

Collaboration Diagram for the renew book use case


37

Activity diagram

New concept, possibly based on event diagram of Odell [1992]

Represent processing activity, may not correspond to methods

Activity is a state with an internal action and one/many outgoing transition


38

Activity diagram

Can represent parallel activity and synchronization aspects

Swim lanes enable to group activities

based on who is performing them

Example: academic department vs. hostel


39

Activity diagram

Normally employed in business process modelling

Carried out during requirement analysis and specification

Can be used to develop interaction diagrams


40

Example of

Activity diagram

check

student

records

Academic Section

receive

fees

allot

room

receive

fees

allot

hostel

create

hospital

record

conduct

medical

examination

register

in

course

Accounts Section Hostel Office Hospital Department

issue

identity card Activity diagram for student admission procedure at IIT


41

State Chart diagram

Based on the work of David Harel

[1990]

Model how the state of an object changes in its lifetime

Based on finite state machine (FSM) formalism


42

State Chart diagram

Elements of state chart diagram

Initial State: Filled circle

Final State: Filled circle inside larger

circle

State: Rectangle with rounded corners

Transitions: Arrow between states, also boolean logic condition (guard)


43

Example of

State Chart diagram

Unprocessed

Order

Fulfilled

Order

Pending

Order

Accepted

Order

Rejected

Order

order received

[reject] checked [accept] checked

[some items not

available] processed

[all items

available]

newsupply

[some items available]

processed / deliver

Example: State chart diagram for an order object KIDS Information Center

44

Design Patterns

Standard solutions to commonly recurring problems

Provides a good solution to model

Pattern has four important parts

The problem

The context (problem)

The solution

The context (solution)


45

Example Pattern

Expert

Problem: Which class should be

responsible for doing certain things

Solution: Assign responsibility to the

class that has the information necessary to fulfil the required responsibility


46

Example Pattern

Creator

Problem: Which class should be responsible for creating a new instance of some class?

Solution: Assign a class C1 the responsibility to create class C2 if

C1 is an aggregation of objects of type C2

C1 contains object of type C2


47

Example Pattern

Controller

Problem: Who should be responsible

for handling the actor requests?

Solution: Separate controller object for

each use case.


48

Example Pattern

Facade

Problem: How should the services be requested from a service package?

Context (problem): A package (cohesive set of classes), example: RDBMS interface package

Solution: A class (DBfacade) can be created which provides a common interface to the services of the package


49

Example 1: Tic-Tac-Toe

Computer Game

A human player and the computer make

alternate moves on a 3 3 square.

A move consists of marking a previously unmarked square.

The user inputs a number between 1 and 9 to mark a square

Whoever is first to place three consecutive marks along a straight line (i.e., along a row, column, or diagonal) on the square wins.


50

Example 1: Tic-Tac-Toe

Computer Game

As soon as either of the human player or the computer wins, a message announcing the winner should be

displayed.

If neither player manages to get three consecutive marks along a straight line, and all the squares on the board are filled up,

then the game is drawn.

The computer always tries to win a game.


51

Example 1: Use Case Model

Tic-tac-toe game

Play Move

Player


52

Example 1: Sequence Diagram

:playMove

Boundary

:playMove

Controller :board

acceptMove

Sequence Diagram for the play move use case

move

checkMoveValidity

[invalidMove]

announceInvalidMove [invalidMove]

announceInvalidMove

[game over]

announceResult [game over]

announceResult

checkWinner

playMove

checkWinner

[game over]

announceResult [game over]

announceResult

getBoardPositions displayBoardPositions

[game not over]

promptNextMove


53

Example 1: Class Diagram

Board

int position[9]

checkMove Validity

checkResult

playMove

Controller

announceInvalidMove

announceResult

PlayMoveBoundary

announceInvalidMove

announceResult

displayBoard


54

Example 2: Supermarket Prize

Scheme

Supermarket needs to develop software to encourage regular customers.

Customer needs to supply his residence address, telephone number, and the driving licence number.

Each customer who registers is assigned a unique customer number (CN) by the computer.


55


Scheme

A customer can present his CN to the staff when he makes any purchase.

The value of his purchase is credited against his CN.

At the end of each year, the supermarket awards surprise gifts to ten customers who make highest purchase.


56


Scheme

Also, it awards a 22 carat gold coin to every customer whose purchases exceed Rs. 10,000.

The entries against the CN are reset on the last day of every year after the prize winner’s lists are generated.


57

Example 2: Use Case Model

Supermarket

Prize scheme

register

customer Customer

register

sales

select

winners

Sales Clerk

Manager

Clerk


58

Example 2: Sequence Diagram for

the Select Winners Use Case

:SelectWinner

Boundary

:SelectWinner

Controller

:Sales

History

:Sales

Record

:Customer

Register

Select

Winners

Sequence Diagram for the select winners use case

:Customer

Record

SelectWinners

announces

SelectWinners

*computeSales

*browse

[for each winner]

find WinnerDetails [for each winner]

browse


59


the Register Customer Use Case

:SelectWinner

Boundary

:SelectWinner

Controller

:Customer

Register

register

Sequence Diagram for the register customer use case

:Customer

Record

[duplicate]

displayCIN

*match

create

register

:Customer

Record

checkDuplicate

showError

generateCIN

register


60


the Register Sales Use Case

:Register

Sales

Boundary

:Sales

History

:Sales

Record

registerSales

Sequence Diagram for the register sales use case

RegisterSales

create

confirm

:Register

Sales

Controller

registerSales

confirm


61


the Register Sales Use Case

:Register

Sales

Boundary

:Sales

History

:Sales

Record

registerSales

Refined Sequence Diagram for the register sales use case

RegisterSales

create

confirm


62

Example 1: Class Diagram

SalesHistory

selectWinners

registerSales

SalesRecords

computerSales

browse

create

CustomerRegister

findWinnerDetails

register

salesDetails

CustomerRecord

browse

checkDuplicate

create

name

address

1

*

1

*


63

Summary

We discussed object-oriented concepts

Basic mechanisms: Such as objects,

class, methods, inheritance etc.

Key concepts: Such as abstraction,

encapsulation, polymorphism, composite objects etc.


64

Summary

We discussed an important OO language UML

Its origin, as a standard, as a model

Use case representation, its factorisation

such as generalization, includes and extends

Different diagrams for UML representation

In class diagram we discussed some relationships association, aggregation, composition and inheritance


65

Summary

Some more diagrams such as interaction diagrams (sequence and collaboration), activity diagrams, state chart diagram

We discussed OO software development process and patterns

In this we discussed some patterns example and domain modelling


Software Testing

67

Organization of this

Lecture

Introduction to Testing. White-box testing:

statement coverage path coverage branch testing condition coverage Cyclomatic complexity

Summary


68

How do you test a

system?

Input test data to the system.

Observe the output: Check if the system behaved as expected.


69

How do you test a

system?


70

How do you test a

system?

If the program does not behave as expected: note the conditions under which it failed. later debug and correct.


71

Errors and Failures

A failure is a manifestation of an error (aka defect or bug).

mere presence of an error may not lead to

a failure.


72

Test cases and Test

suite

Test a software using a set of carefully designed test cases:

the set of all test cases is called

the test suite


73

Test cases and Test

suite

A test case is a triplet [I,S,O]: I is the data to be input to the

system, S is the state of the system at

which the data is input, O is the expected output from the

system.


74

Verification versus

Validation

Verification is the process of determining:

whether output of one phase of development conforms to its previous phase.

Validation is the process of determining

whether a fully developed system conforms to its SRS document.


75

Verification versus

Validation

Aim of Verification:

phase containment of errors

Aim of validation:

final product is error free.


76

Verification versus

Validation

Verification:

are we doing right?

Validation:

have we done right?


77

Design of Test Cases

Exhaustive testing of any non-trivial system is impractical: input data domain is extremely large.

Design an optimal test suite: of reasonable size to uncover as many errors as

possible.


78


If test cases are selected randomly: many test cases do not contribute to the

significance of the test suite, do not detect errors not already detected

by other test cases in the suite.

The number of test cases in a randomly selected test suite: not an indication of the effectiveness of the

testing.


79


Testing a system using a large number

of randomly selected test cases:

does not mean that many errors in the system will be uncovered.

Consider an example:

finding the maximum of two integers x and y.


80


If (x>y) max = x; else max = y;

The code has a simple error: test suite {(x=3,y=2);(x=2,y=3)}

can detect the error, a larger test suite

{(x=3,y=2);(x=4,y=3); (x=5,y=1)} does not detect the error.


81


Systematic approaches are required to design an optimal test suite:

each test case in the suite should detect different errors.


82


Two main approaches to design test cases:

Black-box approach

White-box (or glass-box) approach


83

Black-box Testing

Test cases are designed using only functional specification of the software:

without any knowledge of the internal structure of the software.

For this reason, black-box testing is also known as functional testing.


84

White-box Testing

Designing white-box test cases:

requires knowledge about the internal structure of software.

white-box testing is also called structural testing.


85

Black-box Testing

Two main approaches to design black box test cases:

Equivalence class partitioning

Boundary value analysis


86

White-Box Testing

There exist several popular white-box testing methodologies:

Statement coverage

branch coverage

path coverage

condition coverage

mutation testing

data flow-based testing


87

Statement Coverage

Statement coverage methodology:

design test cases so that

every statement in a program is executed at least once.


88

Statement Coverage

The principal idea:

unless a statement is executed,

we have no way of knowing if an error exists in that statement.


89

Example

int f1(int x, int y){ 1 while (x != y){ 2 if (x>y) then 3 x=x-y; 4 else y=y-x; 5 } 6 return x; }


90

Branch Coverage

Test cases are designed such that:

different branch conditions

given true and false values in turn.


91

Branch Coverage

Branch testing guarantees statement coverage:

a stronger testing compared to the statement coverage-based testing.


92

Example

int f1(int x,int y){ 1 while (x != y){ 2 if (x>y) then 3 x=x-y; 4 else y=y-x; 5 } 6 return x; }


93

Example

Test cases for branch coverage can be:

{(x=3,y=3),(x=3,y=2), (x=4,y=3), (x=3,y=4)}


94

Condition Coverage

Test cases are designed such that:

each component of a composite conditional expression

given both true and false values.


95

Example

Consider the conditional expression ((c1.and.c2).or.c3):

Each of c1, c2, and c3 are exercised at least once, i.e. given true and false values.


96

Branch testing

Condition testing stronger testing than branch testing:

Branch testing stronger than statement coverage testing.


97

Condition coverage

Consider a boolean expression having n components:

for condition coverage we require 2n test cases.


98

Path Coverage

Design test cases such that:

all linearly independent paths in the program are executed at least once.


99

Linearly independent

paths

Defined in terms of

control flow graph (CFG) of a program.


100

Path coverage-based

testing

To understand the path coverage-based testing:

we need to learn how to draw control flow graph of a program.


101

Control flow graph

(CFG)

A control flow graph (CFG) describes: the sequence in which different instructions

of a program get executed. the way control flows through the program.


102

How to draw Control

flow graph?

Number all the statements of a program.

Numbered statements:

represent nodes of the control flow graph.


103

Example



104

Example Control Flow

Graph

1

2

3 4

5

6


105

How to draw Control

flow graph?

Sequence:

1 a=5;

2 b=a*b-1;

1

2


106

How to draw Control

flow graph?

Selection:

1 if(a>b) then

2 c=3;

3 else c=5;

4 c=c*c;

1

2 3

4


107

How to draw Control

flow graph?

Iteration:

1 while(a>b){

2 b=b*a;

3 b=b-1;}

4 c=b+d;

1

2

3

4


108

Path

A path through a program:

a node and edge sequence from the starting node to a terminal node of the control flow graph.

There may be several terminal nodes for program.


109

Independent path

Any path through the program:

introducing at least one new node:

that is not included in any other independent paths.


110

Independent path

It is straight forward:

to identify linearly independent paths of simple programs.

For complicated programs:

it is not so easy to determine the number of independent paths.


111

McCabe's cyclomatic

metric

An upper bound: for the number of linearly

independent paths of a program

Provides a practical way of determining: the maximum number of linearly

independent paths in a program.


112

McCabe's cyclomatic

metric

Given a control flow graph G, cyclomatic complexity V(G):

V(G)= E-N+2

N is the number of nodes in G

E is the number of edges in G


113


Graph

1

2

3 4

5

6


114

Example

Cyclomatic complexity = 7-6+2 = 3.


115

Cyclomatic complexity

Another way of computing cyclomatic complexity:

inspect control flow graph

determine number of bounded areas in the graph

V(G) = Total number of bounded areas + 1


116

Bounded area

Any region enclosed by a nodes and edge sequence.


117


Graph

1

2

3 4

5

6


118

Example

From a visual examination of the CFG:

the number of bounded areas is 2.

cyclomatic complexity = 2+1=3.


119


McCabe's metric provides: a quantitative measure of testing difficulty and the ultimate reliability

Intuitively, number of bounded areas increases

with the number of decision nodes and loops.


120


The first method of computing V(G) is amenable to automation:

you can write a program which determines the number of nodes and edges of a graph

applies the formula to find V(G).


121


The cyclomatic complexity of a program provides:

a lower bound on the number of test cases to be designed

to guarantee coverage of all linearly independent paths.


122


Defines the number of independent paths in a program.

Provides a lower bound:

for the number of test cases for path coverage.


123


Knowing the number of test cases required:

does not make it any easier to derive the test cases,

only gives an indication of the minimum number of test cases required.


124

Path testing

The tester proposes:

an initial set of test data using his experience and judgement.


125

Path testing

A dynamic program analyzer is used: to indicate which parts of the

program have been tested

the output of the dynamic analysis used to guide the tester in selecting additional test cases.


126

Derivation of Test

Cases

Let us discuss the steps:

to derive path coverage-based test cases of a program.


127

Derivation of Test

Cases

Draw control flow graph.

Determine V(G).

Determine the set of linearly independent paths.

Prepare test cases:

to force execution along each path.


128

Example



129


Diagram

1

2

3 4

5

6


130

Derivation of Test Cases

Number of independent paths: 3

1,6 test case (x=1, y=1)

1,2,3,5,1,6 test case(x=1, y=2)

1,2,4,5,1,6 test case(x=2, y=1)


131

An interesting application

of cyclomatic complexity

Relationship exists between:

McCabe's metric

the number of errors existing in the code,

the time required to find and correct the errors.


132


Cyclomatic complexity of a program:

also indicates the psychological complexity of a program.

difficulty level of understanding the program.


133


From maintenance perspective, limit cyclomatic complexity

of modules to some reasonable value.

Good software development organizations: restrict cyclomatic complexity of functions to a maximum of ten or so.


134

Summary

Exhaustive testing of non-trivial systems is impractical:

we need to design an optimal set of test cases

should expose as many errors as possible.


135

Summary

If we select test cases randomly:

many of the selected test cases do not add to the significance of the test set.


136

Summary

There are two approaches to testing:

black-box testing and

white-box testing.


137

Summary

Designing test cases for black box testing:

does not require any knowledge of how the functions have been designed and implemented.

Test cases can be designed by examining only SRS document.


138

Summary

White box testing:

requires knowledge about internals of the software.

Design and code is required.


139

Summary

We have discussed a few white-box test strategies.

Statement coverage

branch coverage

condition coverage

path coverage


140

Summary

A stronger testing strategy:

provides more number of significant test cases than a weaker one.

Condition coverage is strongest among strategies we discussed.


141

Summary

We discussed McCabe’s Cyclomatic complexity metric:

provides an upper bound for linearly independent paths

correlates with understanding, testing, and debugging difficulty of a program.


Software Reliability: 2

Alternate Definitions

Informally denotes a product’s trustworthiness or dependability.

Probability of the product working “correctly” over a given period of time.


Software Reliability

Intuitively: a software product having a large

number of defects is unreliable.

It is also clear: reliability of a system improves if

the number of defects is reduced.


Difficulties in Software

Reliability Measurement (1)

No simple relationship between: observed system reliability and the number of latent software

defects. Removing errors from parts of

software which are rarely used: makes little difference to the perceived

reliability.


Difficulty in Software


The perceived reliability depends to a large extent upon: how the product is used, In technical terms on its operation profile.


Software Reliability

Different users use a software product in different ways.

defects which show up for one user,

may not show up for another.

Reliability of a software product:

clearly observer-dependent

cannot be determined absolutely.


Difficulty in Software


Software reliability keeps changing through out the life of the product

Each time an error is detected and corrected


Hardware vs. Software

Reliability

Hardware failures: inherently different from software

failures.

Most hardware failures are due to component wear and tear: some component no longer functions as

specified.



Reliability

Software faults are latent:

system will continue to fail:

unless changes are made to the software design and code.



Reliability

When a hardware is repaired:

its reliability is maintained

When software is repaired:

its reliability may increase or decrease.


Reliability Metrics

A good reliability measure should be observer-independent,

so that different people can agree on the reliability.


Rate of occurrence of

failure (ROCOF):

ROCOF measures: frequency of occurrence failures. observe the behavior of a software

product in operation: over a specified time interval calculate the total number of failures during the interval.


Mean Time To Failure

(MTTF)

Average time between two successive failures:

observed over a large number of failures.


Mean Time to Repair

(MTTR)

Once failure occurs:

additional time is lost to fix faults

MTTR:

measures average time it takes to fix faults.


Mean Time Between

Failures (MTBF)

We can combine MTTF and MTTR:

to get an availability metric:

MTBF=MTTF+MTTR

MTBF of 100 hours would indicae

Once a failure occurs, the next failure is expected after 100 hours of clock time (not running time).


Probability of Failure on

Demand (POFOD)

Unlike other metrics

This metric does not explicitly involve time.

Measures the likelihood of the system failing:

when a service request is made.

POFOD of 0.001 means:

1 out of 1000 service requests may result in a failure.


Availability

Measures how likely the system shall be

available for use over a period of time:

considers the number of failures occurring during a time interval,

also takes into account the repair time (down time) of a system.


Failure Classes

Transient: Transient failures occur only for certain

inputs. Permanent:

Permanent failures occur for all input values.

Recoverable: When recoverable failures occur:

the system recovers with or without operator intervention.


Failure Classes

Unrecoverable:

the system may have to be restarted.

Cosmetic:

These failures just cause minor irritations,

do not lead to incorrect results.

An example of a cosmetic failure:

mouse button has to be clicked twice instead of once to invoke a GUI function.


Software Project

Management

Project planning

Once a project is found to be feasible, software project managers undertake project planning.

Project planning is undertaken and completed even before any development activity starts.


Essential activities in Project

Planning:

1) Estimating the following attributes of the project: Project size: What will be problem complexity in terms of

the effort and time required to develop the product? Cost: How much is it going to cost to develop the project? Duration: How long is it going to take to complete

development? Effort: How much effort would be required? The effectiveness of the subsequent planning activities is

based on the accuracy of these estimations.


2) Scheduling manpower and other resources

3) Staff organization and staffing plans

4) Risk identification, analysis, and abatement planning

5) Miscellaneous plans such as quality assurance plan, configuration management plan, etc.


Precedence ordering among

project planning activities


Problem in Project

Planning

Commitment to unrealistic time and resource estimates result in schedule slippage.

Schedule delays can cause customer dissatisfaction and adversely affect team morale.

However, project planning is a very challenging activity. Especially for large projects, it is very much difficult to make accurate plans.

A part of this difficulty is due to the fact that the proper parameters, scope of the project, project staff, etc. may change during the span of the project.


Solution: Sliding Window

Planning

Planning a project over a number of stages protects managers from making big commitments too early.

This technique of staggered planning is known as Sliding Window Planning.

Starting with an initial plan, the project is planned more accurately in successive development stages.

After the completion of every phase, the project managers can plan each subsequent phase more accurately and with increasing levels of confidence.


Responsibilities of a software

project manager

Overall responsibility of steering a project to success. The job responsibility of a project manager ranges from

invisible activities like building up team morale to highly visible customer presentations.

Activities can be broadly classified into project planning, and project monitoring and control activities.

It includes: project proposal writing, project cost estimation, scheduling,

project staffing, software process tailoring, project monitoring and control, software configuration management, risk management, interfacing with clients, managerial report writing and presentations, etc.


Skills necessary for software

project management

Theoretical knowledge of different project management techniques like cost estimation, risk management, configuration management

Good qualitative judgment and decision taking capabilities.

Good communication skills and the ability get work done.


Software Project

Management Plan (SPMP)

1. Introduction (a) Objectives (b) Major Functions (c) Performance Issues (d) Management and Technical Constraints 2. Project Estimates (a) Historical Data Used (b) Estimation Techniques Used (c) Effort, Resource, Cost, and Project Duration Estimates 3. Schedule (a) Work Breakdown Structure (b) Task Network Representation (c) Gantt Chart Representation (d) PERT Chart Representation


Software Project

Management Plan (SPMP)

4. Project Resources

(a) People

(b) Hardware and Software

(c) Special Resources

5. Staff Organization

(a) Team Structure

(b) Management Reporting

6. Risk Management Plan

(a) Risk Analysis

(b) Risk Identification

(c) Risk Estimation

(d) Risk Abatement Procedures

7. Project Tracking and Control Plan

8. Miscellaneous Plans

(a) Process Tailoring

(b) Quality Assurance Plan

(c) Configuration Management Plan


Project Estimation

techniques

Empirical estimation techniques

Heuristic techniques

Analytical estimation techniques


Empirical Estimation

Techniques

Based on making an educated guess of the project parameters.

Prior experience with development of similar products is helpful.

Although empirical estimation techniques are based on common sense, different activities involved in estimation have been formalized over the years.

Two popular empirical estimation techniques are: 1) Expert judgment technique

2) Delphi cost estimation


Expert Judgment Technique

An expert makes an educated guess of the problem size after analyzing the problem thoroughly.

Estimates the cost of the different components (i.e. modules or subsystems) of the system and then combines them to arrive at the overall estimate.

However, this technique is subject to human errors and individual bias.

For example, he may be conversant with the database and user interface parts but may not be very knowledgeable about the computer communication part.

A more refined form of expert judgment is the estimation made by group of experts.


Delphi cost estimation

It overcomes some of the shortcomings of the expert judgment approach.

Delphi estimation is carried out by a team comprising of a group of experts and a coordinator.

No discussion among the estimators is allowed during the entire estimation process.


Delphi cost estimation

The coordinator provides each estimator with a copy of the SRS document and a form for recording his cost estimate.

Estimators complete their individual estimates anonymously and submit to the coordinator.

The coordinator prepares and distributes the summary of the responses of all the estimators, and includes any unusual rationale noted by any of the estimators.

Based on this summary, the estimators re-estimate.

This process is iterated for several rounds.


Heuristic Techniques

It assumes that the relationships among the different project parameters can be modelled using suitable mathematical expressions.

Once the basic (independent) parameters are known, the other (dependent) parameters can be easily determined by substituting the value of the basic parameters in the mathematical expression.

Two classes:

1) single variable model and

2) multi variable model


Single variable estimation

models

It provides a means to estimate the desired characteristics of a problem, using some previously estimated basic (independent) characteristic of the software product such as its size.

Estimated Parameter =

e is the characteristic of the software which has already been estimated (independent variable)

c1 and d1 are constants determined using data collected from past projects (historical data).


Multivariable cost estimation

model

•Where e1, e2, … are the basic

(independent) characteristics of the

software already estimated, and c1, c2,

d1, d2, … are constants.

•Multivariable estimation models are

expected to give more accurate

estimates.


Project Types

Organic:

Routine project

Well understood domain

Team works well and efficiently together

Project expected to run smoothly

Typically a smaller system and smaller team

Embedded:

Difficulties expected

Project that is hard (control software for a nuclear plant, or spacecraft)

Team has little experience in domain

New or inexperienced team

Tend to be large projects with lots of constraints KIDS Information Center 179

Semidetached:

In the middle

Complex system, but something the company is familiar with

Teams may be made up of experienced and inexperienced members

System not huge, but not small either


Basic COCOMO Model

COnstructive COst MOdel

The basic COCOMO model gives an approximate estimate of the project parameters.


person-months (PM).

The effort estimation is expressed in units of person-months (PM).

An effort of 100 PM does not imply that 100 persons should work for 1 month nor does it imply that 1 person should be employed for 100 months, but it denotes the area under the person-month curve .

It is the area under the person-month plot.


person-months (PM)


Estimation of development

effort


Estimation of development

time


Example:

Assume that the size of an organic type software product has been estimated to be 32,000 lines of source code. Assume that the average salary of software engineers be Rs. 15,000/- per month. Determine the effort required to develop the software product and the nominal development time.


Intermediate COCOMO

model

The basic COCOMO model assumes that effort and development time are functions of the product size alone.

However, a host of other project parameters besides the product size affect the effort required to develop the product as well as the development time.

Therefore, in order to obtain an accurate estimation of the effort and project duration, the effect of all relevant parameters must be taken into account.


15 Cost Drivers

Boehm requires the project manager to rate these 15 different parameters for a particular project on a scale of one to three.

Then, depending on these ratings, he suggests appropriate cost driver values which should be multiplied with the initial estimate obtained using the basic COCOMO.


Classification of Cost

Drivers

Product: The characteristics of the product that are considered include the inherent complexity of the product, reliability requirements of the product, etc.

Computer: Characteristics of the computer that are considered include the execution speed required, storage space required etc.

Personnel: The attributes of development personnel that are considered include the experience level of personnel, programming capability, analysis capability, etc.

Development Environment: Development environment attributes capture the development facilities available to the developers. An important parameter that is considered is the sophistication of the automation (CASE) tools used for software development.


Complete COCOMO model

A major shortcoming of both the basic and intermediate COCOMO models is that they consider a software product as a single homogeneous entity.

However, most large systems are made up several smaller sub-systems.

These subsystems may have widely different characteristics.

For example, some subsystems may be considered as organic type, some semidetached, and some embedded.


Example

A distributed Management Information System (MIS) product for an organization having offices at several places across the country can have the following sub-components:

• Database part • Graphical User Interface (GUI) part • Communication part Of these, the communication part can be

considered as embedded software. The database part could be semi-detached

software, and the GUI part organic software.


Staffing level estimation

Once the effort required to develop a software has been determined, it is necessary to determine the staffing requirement for the project.

Norden and Putnam studied the staffing patterns of several R & D projects.


Norden’s Work

He found that the staffing pattern can be approximated by the Rayleigh distribution curve.

Norden represented the Rayleigh curve by the following equation:

E is the effort required at time t. E is an indication of the number of engineers (or the staffing level) at any particular time during the duration of the project

K is the area under the curve, and td is the time at which the curve attains its

maximum value. KIDS Information Center 199

Project scheduling

It involves deciding which tasks would be taken up when. Activities undertaken:

1. Identify all the tasks needed to complete the project.

2. Break down large tasks into small activities.

3. Determine the dependency among different activities.

4. Establish the most likely estimates for the time durations necessary to complete the activities.

5. Allocate resources to activities.

6. Plan the starting and ending dates for various activities.

7. Determine the critical path. A critical path is the chain of activities that determines the duration of the project.


Work breakdown structure

Work Breakdown Structure (WBS) is used to decompose a given task set recursively into small activities.

The root of the tree is labeled by the problem name.

Each node of the tree is broken down into smaller activities that are made the children of the node.

Each activity is recursively decomposed into smaller sub-activities until at the leaf level, the activities requires approximately two weeks to develop.


Work breakdown structure of

an MIS problem


Activity networks and critical

path method

WBS representation of a project is transformed into an activity network by representing activities identified in WBS along with their interdependencies.

An activity network shows the different activities making up a project, their estimated durations, and interdependencies.


Activity network

representation of the MIS

problem


Critical Path Method (CPM)

The minimum time (MT) to complete the project is the maximum of all paths from start to finish.

The earliest start (ES) time of a task is the maximum of all paths from the start to the task.

The latest start time is the difference between MT and the maximum of all paths from this task to the finish.

The earliest finish time (EF) of a task is the sum of the earliest start time of the task and the duration of the task.

The latest finish (LF) time of a task can be obtained by subtracting maximum of all paths from this task to finish from MT.

The slack time (ST) is LS – EF and equivalently can be written as LF – EF.


Slack Time

The slack time (or float time) is the total time that a task may be delayed before it will affect the end time of the project.

The slack time indicates the “flexibility” in starting and completion of tasks.

A critical task is one with a zero slack time. A path from the start node to the finish node containing only critical tasks is called a critical path.


Parameters for different tasks

of MIS Problem


Gantt chart

Used to allocate resources to activities (resource planning).

The resources allocated to activities include staff, hardware, and software.

A Gantt chart is a special type of bar chart where each bar represents an activity.

The bars are drawn along a time line. The length of each bar is proportional to the

duration of time planned for the corresponding activity.


Gantt chart for MIS

problem


PERT chart

PERT (Project Evaluation and Review Technique) charts consist of a network of boxes and arrows.

The boxes represent activities and the arrows represent task dependencies.

The boxes of PERT charts are usually annotated with the pessimistic, likely, and optimistic estimates for every task.


Gantt chart representation of a project schedule is helpful in planning the utilization of resources, while PERT chart is useful for monitoring the timely progress of activities.

Also, it is easier to identify parallel activities in a project using a PERT chart.


PERT chart representation of

the MIS problem


Software

Quality

Management

215

Plan of the Talk

Introduction to Quality Engineering.

Quality control and Quality Assurance

ISO 9000

SEI CMM

Summary KIDS Information Center

216

Introduction

Traditional definition of quality:

Fitness of purpose:

A quality product does exactly what the users want it to do.


217

Fitness of Purpose

Fitness of purpose for software products:

Satisfaction of the requirements specified in SRS document.


218

Fitness of Purpose

A satisfactory definition of quality for many products: A car, a table fan, a food mixer,

microwave oven, etc.

But, not satisfactory for software products. Why?


219

Quality for Software

Products

Consider a software product: Functionally correct:

Performs all functions as specified in the SRS document.

But, has an almost unusable user interface. Cannot be considered as a quality product.


220

Quality for Software

Products

Consider another example:

A product which does everything that users want.

But has an almost incomprehensible and unmaintainable code.

Will you call it a quality product?


221

Modern View of

Quality

Several quality factors are associated with a software product : Correctness

Reliability

Efficiency (includes efficiency of resource utilization)

Portability

Usability

Reusability

Maintainability


222

Correctness

A software product is correct:

If different requirements as specified in the SRS document have been correctly implemented.

Results are accurate.


223

Portability

A software product is said to be portable:

If it can be easily made to work

In different operating systems.

In different machines,

With other software products, etc.


224

Reusability

A software product has good reusability:

If different modules of the product can easily be reused to develop new products.


225

Usability

A software product has good usability:

If different categories of users (i.e. both expert and novice users) can easily invoke the functions of the product.


226

Maintainability

A software product is maintainable:

If errors can be easily corrected as and when they show up,

New functions can be easily added to the product,

Functionalities of the product can be easily modified.


227

Software Quality

Management System

Quality management system (or quality system):

Principal methodology used by organizations to ensure that the products have desired quality.


228

Quality System

A quality system consists of the following:

Managerial Structure

Individual Responsibilities.

Responsibility of the organization as a whole.


229

Quality System

Every quality conscious organization has an independent quality department:

Performs several quality system activities. Needs support of top management. Without support at a high level in a

company: Many employees may not take the quality

system seriously.


230

Quality System Activities

Auditing of projects

Development of: standards, procedures, and guidelines.

Production of reports for the top management: Summarizing the effectiveness of the

quality system in the organization.

Review of the quality system itself.


231

Quality System

A good quality system must be well documented.

Without a properly documented quality system,

Application of quality procedures become ad hoc,

Results in large variations in the quality of the products delivered.


232

Quality System

An undocumented quality system:

Sends clear messages to the staff about the attitude of the organization towards quality assurance.

International standards such as ISO 9000 provide:

Guidance on how to organize a quality system.


233

Evolution of Quality

Systems

Quality systems have evolved: Over the last six decades.

Prior to World War II: Accepted way to produce quality

products: Inspect the finished products

Eliminate defective products.


234


Systems

Since World war II, Quality systems of organizations

have undergone: Four stages of evolution.

Many advances came from Japanese: Helped resurrect Japanese economy.


235


Systems


236


Systems

Initial product inspection method:

Gave way to quality control (QC).

Quality control:

Not only detect the defective products and eliminate them

But also determine the causes behind the defects.


237

Quality Control (QC)

Quality control aims at correcting the causes of errors:

Not just rejecting defective products. Statistical quality control (SQC):

Quality of the output of the process is inferred using statistical methods.

In stead of inspection or testing of all products.


238

Quality Control (QC)

The next breakthrough:

Development of quality assurance principles.


239

Quality Assurance

Basic premise of modern quality assurance:

If an organization's processes are good and are followed rigorously:

The products are bound to be of good quality.


240

Quality Assurance

All modern quality paradigms include:

Guidance for recognizing, defining, analyzing, and improving the production process.


241

Total Quality Management

(TQM)

TQM advocates:

Continuous process improvements through process measurements.


242

Business Process

Reengineering

BPR:A term related to TQM.

Process reengineering goes a step further than quality assurance: Aims at continuous process

improvement.


243

Business Process

Reengineering

TQM focuses on reengineering of the software process.

Whereas BPR aims at reengineering the way business is carried out in any organization:

Not just software development.


244

Total Quality Management

(TQM)

TQM goes beyond documenting processes

Optimizes them through redesign.

Over the years the quality paradigm has shifted:

From product assurance to process assurance.


245

Implies introducing process changes to improve: Product quality

Reduce costs

Accelerate schedules.

Most process improvement work so far has focused on defect reduction.

Process

Improvement


246

Process

Attributes Pr o ce ss c ha rac t er is t i c

D e s cr i p t i on

U n d er st a n da b il i t y T o w h at ex t e n t is t h e p r o ce ss e x p lic i t l y d e f i n ed an d h o w ea sy i s it t o u n d er st an d t he pr oc e s s de f i n i t i o n?

V i s i b i l it y D o t he p r o c e ss ac t i v it i e s c u l mi na t e i n c l ea r r e s u l t s so t h a t t h e p r o g r e ss o f t he p r o c e ss i s ex t er n a l ly v is ib l e?

S u p p o r t a b il i t y T o w h at ex t e n t c a n C A S E t o o l s b e us ed t o s u p p o r t t h e pr oce ss ac t i v it i e s ?

A cce p ta b i l it y Is t h e d e f in e d pr oce ss acce p ta b l e t o a n d us a b le b y t h e e n g i nee rs r e s p o n si b l e f o r p r o d u ci n g th e s o f t w a r e p r o d u c t ?

R e li a bi l i t y Is t h e p r o ce ss d e s i g n e d i n s u c h a w a y t h at p r o c e ss e r r ors a r e a v o i de d o r t r a p pe d b e f o r e t he y r e s u l t i n pr o d uc t e r r ors ?

R o b us t n e ss C a n t he p r oc ess c o nt i n u e i n sp i t e o f u n ex p ect e d pr o b le ms ?

M a i n ta i na b i l it y C a n t he p r oc ess e v ol v e t o re f l e ct c ha n g i n g o rg an is at i o n al re q u i r e m e n ts o r i de n t i f i e d p r o c e ss i mp r o v em en ts ?

R a pi d i t y H o w f a s t c an th e p ro ce ss o f de l iv e r i n g a sys te m f r o m a g i v e n s p e ci f ic a ti o n be co mp le t ed ?


247

The Process Improvement

Cycle

Analyse

Measure

Change


248

Process measurement Attributes of the process are measured. Form a baseline for assessing improvements.

Process analysis The process is assessed and bottlenecks and

weaknesses are identified.

Process change Changes to the process that have been

identified during the analysis are introduced.

Process Improvement

Stages


249

A good process is usually required to produce a good product.

For manufactured goods, process is the principal quality determinant.

For design-based activity, other factors are also involved:

For example, the capabilities of the designers.

Process and Product

Quality


250

ISO 9000

ISO (international Standards Organization):

a consortium of 63 countries established to formulate and foster standardization.

ISO published its 9000 series of standards in 1987.


251

What is ISO 9000

Certification?

ISO 9000 certification:

Serves as a reference for contract between independent parties.

The ISO 9000 standard:

Specifies guidelines for maintaining a quality system.


252

What is ISO 9000

Certification?

ISO 9000 specifies:

Guidelines for repeatable and high quality product development.

Also addresses organizational aspects

Responsibilities, reporting, procedures, processes, and resources for implementing quality management.


253

ISO 9000

A set of guidelines for the production process.

Not directly concerned about the product it self.

A series of three standards:

ISO 9001, ISO 9002, and ISO 9003.


254

ISO 9000

Based on the premise:

If a proper process is followed for production:

Good quality products are bound to follow.


255

ISO 9001

Applies to:

Organizations engaged in design, development, production, and servicing of goods.

Applicable to most software development organizations.


256

ISO 9002

ISO 9002 applies to:

Organizations who do not design products: but are only involved in production.

Examples of this category of industries:

Steel or car manufacturing industries

Buy the product and plant designs from external sources: only manufacture products.

Not applicable to software development organizations.


257

ISO 9003

ISO 9003 applies to:

Organizations involved only in installation and testing of the products.


258

ISO 9000 for Software

Industry

ISO 9000 is a generic standard:

Applicable to many industries,

Starting from a steel manufacturing industry to a service rendering company.

Many clauses of ISO 9000 documents:

Use generic terminologies

Very difficult to interpret them in the context of software organizations.


259

Software vs. Other

Industries

Very difficult to interpret many clauses for software industry:

Software development is radically different from development of other products.


260

Software vs. Other

Industries

Software is intangible:

Therefore difficult to control.

It is difficult to control anything that we cannot see and feel.

In contrast, in a car manufacturing unit:

We can see a product being developed through stages such as fitting engine, fitting doors, etc.

One can accurately tell about the status of the product at any time.

Software project management is an altogether different ball game.


261

Software vs. Other

Industries

During software development:

The only raw material consumed is data.

For any other product development:

Lot of raw materials consumed

e.g. Steel industry consumes large volumes of iron ore, coal, limestone, etc.

ISO 9000 standards have many clauses corresponding to raw material control .

Not relevant to software organizations.


262

Software vs. Other

Industries

Radical differences exist between software and other product development:

Difficult to interpret various clauses of the original ISO standard in the context of software industry.


263

ISO 9000 Part-3

ISO released a separate document called ISO 9000 part-3 in 1991:

To help interpret the ISO standard for software industry.

At present:

Official guidance is inadequate.


264

ISO 9000: 2000

ISO 9001:2000: Combines the three standards 9001, 9002, and

9003 into one.

Design and development procedures are required: Only if a company does in fact engage in the

creation of new products.

The 2000 version sought to make a radical change in thinking: By actually highlighting the concept of process

management.


265

ISO 9000: 2000

Another goal is to improve effectiveness via process performance metrics:

Numerical measurement of the effectiveness of tasks and activities.

Continual process improvement and tracking customer satisfaction were made explicit.


266

Why Get ISO 9000

Certification?

Several benefits:

Confidence of customers in an organization increases.

If organization qualified for ISO 9001 certification.

This is especially true in the international market.


267

Why Get ISO 9000

Certification?

Many international software development contracts insist:

Development organization to have ISO 9000 certification.


268

Why Get ISO 9000

Certification?

Requires:

A well-documented software production process to be in place.

Contributes to repeatable and higher quality software.

Makes development process:

Focussed, efficient, and cost-effective


269

Why Get ISO 9000

Certification?

Points out the weakness of an organizations:

Recommends remedial action.

Sets the basic framework:

For development of an optimal process and TQM.


270

How to Get ISO 9000

Certification?

An organization intending to obtain ISO 9000 certification:

Applies to a ISO 9000 registrar for registration.

ISO 9000 registration process consists of several stages.


271

How to Get ISO 9000

Certification?

Application stage:

Applies to a registrar for registration.

Pre-assessment:

The registrar makes a rough assessment of the organization.


272

How to Get ISO 9000

Certification?

Document review and adequacy audit: Process and quality-related

documents.

The registrar reviews the documents.

Makes suggestions for improvements.


273

How to Get ISO 9000

Certification?

Compliance audit: The

registrar checks: Whether the suggestions made by

it during review have been complied.


274

How to Get ISO 9000

Certification?

Registration:

The registrar awards ISO 9000 certificate after successful completions of all previous phases.

Continued surveillance:

The registrar continues monitoring the organization periodically.


275

ISO 9000 Certification

An ISO certified organization : Can use the certificate for corporate

advertizements. Cannot use the certificate to advertize its

products. ISO 9000 certifies organization's process Not any product of the organization.

An organization using ISO certificate for product advertizements: Risks withdrawal of the certificate.


276

Summary of ISO 9001

Requirements

Management responsibility(4.1):

Management must have an effective quality policy.

The responsibility and authority of all those whose work affects quality:

Must be defined and documented.


277

Management

Responsibility(4.1)

Responsibility of the quality system.

Independent of the development process.

Can work in an unbiased manner.

The effectiveness of the quality system:

Must be periodically by audited.


278

Quality System (4.2) and

Contract Reviews (4.3):

A quality system must be maintained and documented.

Contract reviews (4.3): Before entering into a contract, an

organization must review the contract Ensure that it is understood, Organization has the capability for carrying out its obligations.


279

Design Control (4.4)

The design process must be properly controlled:

This includes controlling coding also.

A good configuration control system must be in place.


280

Design Control (4.4)

Design inputs must be verified as adequate.

Design must be verified.

Design output must be of required quality.

Design changes must be controlled.


281

Document Control (4.5)

Proper procedures for:

Document approval, issue and removal.

Document changes must be controlled.

Use of some configuration management tools is necessary.


282

Purchasing (4.6)

Purchased material, including bought-in software:

Must be checked for conforming to requirements.


283

Purchaser Supplied

Products (4.7)

Material supplied by a purchaser:

For example,

Client-provided software must be properly managed and checked.


284

Product Identification (4.8)

The product must be identifiable at all stages of the process.

In software development context this means configuration management.


285

Process Control

(4.9)

The development must be properly managed.

Quality requirements must be identified in a quality plan.


286

Inspection and Testing

(4.10)

In software terms this requires effective testing i.e.,

Unit testing, integration testing and system testing.

Test records must be maintained.


287

Inspection, Measuring and

Test Equipment(4.11)

If integration, measuring, and test equipments are used,

Must be properly maintained and calibrated.


288

Control of Nonconforming

Product (4.13)

In software terms, Keeping untested or faulty software out of released product, Or out of other places whether it might cause damage.


289

Corrective Action (4.14)

This is both about correcting errors when found:

Investigating why they occurred

Improving the process to prevent further occurrences.

If an error reoccurs despite the quality system:

The system needs improvement. KIDS Information Center

290

Handling (4.15) and Quality

Audits (4.17):

Handling (4.15) Deals with: Storage, packing, and delivery of the software product.

Quality Audits (4.17) : Quality system audit must be carried out to ensure its effectiveness.


291

Training (4.18)

Training needs must be identified and met.

Most items of ISO standard:

Are largely common sense.


292

Salient Features of ISO

9001 Requirements:

All documents concerned with the development of a software product:

Should be properly managed, authorized, and controlled.

Proper plans should be prepared:

Progress against these plans should be monitored.


293

Salient Features of ISO

9001 Requirements

Important documents independently checked and reviewed:

For effectiveness and correctness.

The product should be tested :

Against specification.

Several organizational aspects:

e.g., management reporting of the quality team.


294

Shortcomings of ISO 9001

Certification

ISO 9000 requires a production process to be adhered to:

But does not guarantee the process to be of high quality.

Does not give any guideline for defining an appropriate process.


295

Shortcomings of ISO

9001 Certification cont…

ISO 9000 certification process: Not fool-proof

No international accredition agency exists.

Likely variations in the norms of awarding certificates: Among different accredition agencies and among the registrars.


296


Certification (3)

Organizations qualifying for ISO 9001 certification:

Tend to downplay domain expertise.

Tend to believe that since a good process is in place,

Any engineer is as effective as any other engineer in doing any particular activity relating to software development.


297


Certification (4)

In manufacturing industry: Clear link between process quality and

product quality.

Once a process is calibrated: Can be run again and again producing

quality goods.

Software development is a creative process: Individual skills and experience is

significant. KIDS Information Center

298


Certification (5)

Many areas of software development are very specialized: Special expertize and experience

(domain expertize) required.

ISO 9001: Does not automatically lead to

continuous process improvement,

Does not automatically lead to TQM.


299


Certification (6)

ISO 9001 addresses mostly management aspects.

Techniques specific to software development have been ignored:

Configuration management

Reviews

Release builds

Problem Notification system

Intranets KIDS Information Center

300

SEI Capability Maturity

Model (CMM)

Developed by Software Engineering Institute (SEI) of the Carnegie Mellon University, USA: To assist the U.S. Department of

Defense (DoD) in software acquisition.

The rationale was to include: Likely contractor performance as a factor

in contract awards.


301


Model

Major DoD contractors began CMM-based process improvement initiatives:

As they vied for DoD contracts.

SEI CMM helped organizations:

Helped Improve quality of software they developed

Realized adoption of SEI CMM model had significant business benefits.

Other organizations adopted CMM. KIDS Information Center

302


Model

In simple words:

CMM is a model for apprising the software process maturity of a contractor into different levels.

Can be used to predict the most likely outcome to be expected:

from the next project that the organization undertakes.


303


Model

Can be used in two ways:

Capability evaluation

Software process assessment.


304

Capability Evaluation

Provides a way to assess the software process capability of an organization: Helps in selecting a contractor

Indicates the likely contractor performance.


305

Software Process

Assessment

Used by an organization to assess its current process:

Suggests ways to improve the process capability.

This type of assessment is for purely internal use.


306

SEI Capability

Maturity Model

The SEI CMM classifies software development industries into:

Five maturity levels.

Stages are ordered so that improvements at one stage provide foundations for the next.

Based on the pioneering work of Philip Crosby.


307


Model

Initial (1)

Repeatable (2)

Defined (3)

Managed (4)

Optimizing (5)


308

Level 1: (Initial)

Organization operates

Without any formalized process or project plans

An organization at this level is characterized by

Ad hoc and often chaotic activities.


309

Level 1: (Initial)

Software production processes are not defined,

Different engineers follow their own process

Development efforts become chaotic.

The success of projects depend on individual efforts and heroics.


310

Level 2: (Repeatable)

Basic project management practices Tracking cost, schedule, and functionality

are followed.

Size and cost estimation techniques: Function point analysis, COCOMO, etc.

used.

Production process is ad hoc:

Not formally defined

Also not documented.


311

Level 2: (Repeatable)

Process used for different projects might vary between projects:

Earlier success on projects with similar applications can be repeated.

Opportunity to repeat process exist when a company produces a family of products.


312

Level 3: (Defined)

Management and development activities: Defined and documented.

Common organization-wide understanding of activities, roles, and responsibilities.


313

Level 3: (Defined)

The process though defined: Process and product qualities are not measured.

ISO 9001 aims at achieving this level.


314

Level 4: (Managed)

Quantitative quality goals for products are set.

Software process and product quality are measured: The measured values are used to control

the product quality.

Results of measurement used to evaluate project performance: Rather than improve process.


315

Level 4: (Managed)

Organization sets quantitative quality goals.

World-wide about 100 organizations assessed at this level.


316

Level 5: (Optimizing)

Statistics collected from process and product measurements are analyzed: Continuous process improvement based

on the measurements. Known types of defects are prevented from

recurring by tuning the process

Lessons learned from specific projects incorporated into the process


317

Level 5: (Optimizing)

Identify best software engineering practices and innovations:

Tools, methods, or process are identified.

Transferred throughout the organization.

World-wide about 500 organizations have been assessed at this level.


318

Key Process Areas

Each level is associated with a key process area (KPA) identifies:

Where an organization at the previous level must focus to reach this level.


319

Level 2 KPAs

Software project planning:

Size, cost, schedule.

Project monitoring

Configuration management

Subcontract management


320

Level 3 KPAs

Process definition and documentation.

Reviews

Training program


321

Level 4 KPAs

Quantitative measurements.

Process management.


322

Level 5 KPAs

Defect prevention.

Technology change management.

Process change management.


323

Comparison Between ISO

9001 and SEI CMM

ISO 9001 awarded by an international standards body:

Can be quoted in official documents and communications.

SEI CMM assessment is purely for internal use.


324

Comparison Between ISO

9001 and SEI CMM

SEI CMM was developed specifically for software industry:

Addresses many issues specific to software industry.

SEI goes beyond quality assurance

Aims for TQM.

ISO 9001 correspond to SEI level 3.


325

Comparison Between

ISO 9001 and SEI CMM

SEI CMM provides a list of key areas:

On which to focus to take an organization from one level to the other

Provides a way for gradual quality improvements over several stages.

e.g trying to implement a defined process before a repeatable process: Counterproductive as managers are overwhelmed by

schedule and budget pressure.


326

CMMI (CMM

Integration)

CMMI is the successor of the CMM.

The CMM was developed from 1987 until 1997.

In 2002, CMMI Version 1.1 was released. Version 1.2 followed in August 2006.

The goal of the CMMI to integrate many different models into one framework. It was created by members of industry,

government and the SEI.


327

Remarks on Quality Model

Usage

Highly systematic and measured approach to software development process suits certain circumstances Negotiated software, safety-critical software, etc.

What about small organizations? Typically handle applications such as internet, e-

comm. Without an established product range, Without revenue base, experience on past projects,

etc. CMM may be incompatible


328

Small Organizations

Small organizations tend to believe:

We are all competent people hired to do a job, we can’t afford training.

We all communicate with one another.

Osmosis works because we are so close.

We are all heroes:

We do what needs to be done.

Therefore rules do not apply to us.


329

Small Organizations

Often have problems:

Undocumented requirements

Inexperienced managers

Documenting the product

Resource allocation

Training

Peer reviews KIDS Information Center

330

Small Organizations

A two week CMM-based appraisal is probably excessive:

Small organizations need to operate more efficiently at lower levels of maturity

Must first fluorish if eventually they are to mature


331

Personal Software

Process (PSP)

Based on the work of Humphrey.

PSP is a scaled down version of industrial software process:

Suitable for individual use.

Even CMM assumes that engineers use effective personal practices.


332

Personal Software

Process (PSP)

A process is the set of steps for doing a job.

The quality and productivity of an engineer Largely determined by his process

PSP framework: Helps software engineers to measure and

improve the way they work. KIDS Information Center

333

Personal Software Process

(PSP)

Helps developing personal skills and methods.

Estimating and planning method.

Shows how to track performance against plans.

Provides a defined process;

Can be fine tuned by individuals.

Recognizes that a process for individual use is different from that necessary for a team project.


334

Time Management

Track the way you spend time:

Boring activities seem longer then actual.

Interesting activities seem short.

Record time for:

Designing

Writing code

Compiling

Testing KIDS Information Center

335

Personal Software

Process (PSP)

Planning

Design

Code

Compile

Test

Postmortem

Logs

Project plan

summary


336

PSP-Planning

Problem definition Estimate max, min, and total LOC Determine minutes/LOC Calculate max,min, and total

development times Enter the plan data in project plan

summary form Record the planned time in Log


337

PSP-Design

Design the program. Record the design in specified format. Record the Design time in time

recording log.


338

PSP-Code

Implement the design. Use a standard format for code

text. Record the coding time in time

recording log.


339

PSP-Compile

Compile the program. Fix all the defects. Record compile time in time

recording log.


340

PSP-Test/Postmortem

Test: Test the program.

Fix all the defects found.

Record testing time in time recording log.

Postmortem: Complete project plan summary form with

actual time and size data.

Record postmortem time in time record.


341

Personal Software Process

(PSP)

PSP 0

PSP 1

PSP 2

PSP 3

Personal measurement

Basic size measures

Personal planning

Time and schedule

Personal quality management

Design and code reviews

Personal process

evolution


342

Six Sigma

Six sigma is a quantitative approach to eliminate defects: Applicable to all types of industry - from

manufacturing, product development, to service.

The statistical representation of Six Sigma quantitatively describes : How a process is performing.


343

Six Sigma

To achieve six sigma: A process must not produce more than 3.4

defects per million opportunities.

5 Sigma -> 230 defects per million.

4 Sigma -> 6210 defects per million.

Six sigma methodologies: DMAIC (Define, Measure, Analyze, Improve,

Control).

DMADV: (Define, Measure, Analyze, Design, Verify). KIDS Information Center

344

Six Sigma Methodologies

The methodologies are implemented by Green belt and Black belt workers: Supervised by Master black belt worker.

Pareto Chart: Simple bar chart to represent defect data

Identify the problems that occurs with greatest frequency

or incur the highest cost


345

Summary

Evolution of quality system: Product inspection

Quality control

Quality assurance

Total quality management (TQM)

Quality paradigm change: From product to process


346

Summary

ISO 9000:

Basic premise:

If a good process is followed

Good products are bound to follow.

Provides guidelines for establishing a quality system.


347

Summary

ISO 9000:

Series of three standards

9001, 9002, and 9003

9001 is applicable to software industry.


348

Summary

SEI CMM

Developed specially for software industry.

Classifies software organizations into five categories.

According to the maturity of their development process.

CMMI: Integrates existing quality techniques.


349

Current Trends

Many organizations have already tuned their process for:

Budget,

Schedule, and

Quality product.

Competition is challenging them to:

Reduce time for delivery

Adopt Six-Sigma methodology KIDS Information Center

350

Software Maintenance and

Computer Aided Software

Engineering (CASE)


351

Introduction

Software maintenance: any modifications to a software

product after it has been delivered to the customer.

Software maintenance is an important activity for many organizations.


352

Introduction

Maintenance is inevitable for almost any kind of product.

Most products need maintenance:

due to wear and tear caused by use.

Software products do not need maintenance on this count.


353

Introduction

Many people think

only bad software products need maintenance.

The opposite is true:

bad products are thrown away,

good products are maintained and used for a long time.


354

Introduction

Software products need maintenance for three reasons:

corrective

adaptive

perfective


355

Corrective

Corrective maintenance of a software product:

to correct bugs observed while the system is in use.

to enhance performance of the product.


356

Adaptive

A software product needs

maintenance (porting) when customers:

need the product to run on new platforms,

or, on new operating systems,

need the product to interface with new hardware or software.


357

Perfective

Perfective maintenance:

to support new features required by users.

to change some functionality of the system due to customer demands.


358

Maintenance Effort

Distribution

Perfective

Adaptive

Corrective


359

Causes for maintenance

During development:

Software not anticipated to last

very long (e.g., Y2K problem).

Rate of hardware obsolescence:

immortality of software products

maintenance necessary for

software performing low-level

functions. KIDS Information Center

360

Causes for

maintenance

Users want existing software to run on new platforms:

to run in new environments,

and/or with enhanced features.


361

Causes for

maintenance

Whenever other software it works with change: maintenance is needed to cope up

with the newer interface.

For instance, a software product may need maintenance when the operating system changes.


362

Software evolution

Every software product continues

to evolve after its development: through maintenance efforts.

Larger software products stay in operation for longer time: because of high replacement cost.


363

Laws of Maintenance

There will always be a lot of old software needing maintenance.

Good products are maintained, bad products are thrown away.


364

Laws of Maintenance

Lehman’s first Law:

“Software products must change continuously, or become progressively less useful.”


365

Laws of Maintenance

Lehman’s Second Law

“When software is maintained, its structure degrades,

unless active efforts are made to avoid this phenomenon.”


366

Laws of Maintenance

Lehman’s Third Law:

“Over a program’s life time,

its rate of development is approximately constant.”


367

Other Laws of

Maintenance

All large programs will undergo significant changes during operation phase of their life cycle,

regardless of apriori intentions.


368

Insufficient knowledge

Maintenance team is usually different from development team. even after reading all documents

it is very difficult to understand why a thing was done in a certain way.

Also there is a limit to the rate at which a person can study documents and extract relevant information


369

Bad image of

maintenance?

Maintainers are skilled not only in writing code:

proficient in understanding others’ code

detecting problems, modifying the design, code, and documentation

working with end-users


370

Maintenance

Nightmares

Use of gotos

Lengthy procedures

Poor and inconsistent naming

Poor module structure

Weak cohesion and high coupling

Deeply nested conditional statements

Functions having side effects


371

How to do better

maintenance?

Program understanding

Reverse engineering

Design recovery

Reengineering

Maintenance process models


372

Maintenance activities

Two types of activities:

Productive activities:

modification of analysis, design, coding, etc.

Non-productive activities:

understanding system design, code, etc.


373

Software Reverse

Engineering

By analyzing a program code, recover from it:

the design and the requirements specification.


374

Software Reverse

Engineering

Reverse engineering is an important maintenance technique: several existing software products

are unstructured,

lack proper documentation,

were not developed using software engineering principles.


375

Cosmetic changes

Reformat Program Assign Meaningful

Names

Simplify Conditions

Replace GOTOs Simplify

Processing


376

Cosmetic Changes

Reformat the program:

layout the program neatly.

Give more meaningful names to:

Variables, data structures, and functions.


377

Cosmetic Changes

Replace complex and nested

conditional expressions:

simpler conditional statements

whenever appropriate use case statements.


378

Software Reverse

Engineering

In order to extract the design: fully understand the code.

Automatic tools can be used to help derive:

data flow and control flow diagrams from the code.


379

Software Reverse

Engineering

Extract structure chart: module invocation sequence and data

interchange among modules.

Extract requirements specification:

after thoroughly understanding the code.

design has been extracted.


380

Software Maintenance

Process Models

Maintenance activities are not unique:

depend on the extent of modifications

required,

also, depend on condition of the product:

how structured it is,

how well documented it is, etc.


381

Software Maintenance Process

Model - 1

When the required changes are small and simple:

the code can be directly modified

changes reflected in all relevant documents.

more elaborate activities are required when required changes are not trivial.


382


Model - 1

Gather Change Requirements

Analyze Change Requirements

Devise Code Change Strategies

Apply Code Change Strategies

Update Documents Integrate and Test


383


Model 1

Start by gathering change requirements.

Analyze change requirements

formulate strategies for code change.


384


Model 1

Formulating strategies for code change: presence of few members of the

original development team helps in reducing cycle time,

especially for unstructured and inadequately documented code.


385


Model 1

Availability of a working old system at the maintenance site:

greatly helps the maintenance team

provides a good insight into the working of the old system

can compare the working of the modified system with the old system.


386


Model 1

Debugging the system under maintenance becomes easier:

program traces of both the systems can be compared to localize bugs.


387


Model -2

For complex maintenance projects, software reengineering needed:

a reverse engineering cycle followed by a forward engineering cycle.

with as much reuse as possible from existing code and other documents.


388

Maintenance Process

Model 2

Preferable when: amount of rework is significant

software has poor structure.

Can be represented by a reverse engineering cycle:

followed by a forward engineering cycle.


389

Software reengineering

Many aging software products belong to this category.

During the reverse engineering,

the old code is analyzed (abstracted) to extract the module specifications.


390


The module specifications are analyzed

to produce the design.

The design is analyzed (abstracted)

to produce the original requirements specification.

The change requests are then applied to the requirements specification:

arrive at the new requirements specification.


391


Forward engineering is carried out to produce the new code.

During design, module specification, and coding:

substantial reuse is made from the reverse engineered products.


392

Process model for Software

reengineering

Change Requirements

Requirements Specification

New Requirements Specification

Design

Code

Design

Code


393


Advantages of reengineering: produces better design than the original product,

produces required documents,

often results in higher efficiency.


394


Efficiency improvements are brought about by better design.

However, this approach is more costly than the first approach.

An empirical study indicates: process 1 is preferable when amount

of rework is no more than 15%.


395


Reengineering is preferable when:

amount of rework is high,

product exhibits high failure rate.

product difficult to understand.


396

Computer Aided Software

Engineering (CASE)

CASE tools help in software development and maintenance.

CASE is a much talked about topic in software industries.


397

CASE and Its Scope

CASE tool is a generic term: denotes any form of automated

support for software engineering.

In a more restrictive sense: a CASE tool automates some

software development activity.


398

CASE and Its Scope

Some CASE tools assist in phase-related tasks:

specification, structured analysis, design, coding, testing, etc.

Other tools help non-phase activities:

project management and configuration management.


399

Objectives of CASE

To increase productivity

To help produce better quality software at lower cost.


400

CASE Environment

Although individual CASE tools are useful: true power of a tool set can be realized only when:

all CASE tools are integrated together.


401

CASE Environment

Tools covering different stages of life cycle share information (data):

they should integrate through some central repository (store)

consistent view of development information.


402

CASE Environment

The central repository is the data dictionary:

contains definition of all

composite and elementary data items.

through this repository all CASE tools share information.


403

Programming Environment

A CASE environment helps: automate step-by-step methodologies.

In contrast to CASE environment:

a programming environment denotes tools supporting coding phase alone.


404

Schematic representation of

architecture of CASE environment

Central Repository

Consistency-

checker

Project Manageme

nt

Testing

Structured Design

Structured Analysis Configurati

on Manageme

nt

Document Generation

Coding Support


405

Benefits of CASE

A key benefit of using CASE environment:

cost saving through all developmental phases.

Studies carried out to measure the impact of CASE usage:

cost saving between 30% to 40%.


406

Benefits of CASE

Use of CASE tools leads to improvements in quality:

becomes easy to iterate through different software development phases.

chances of human error is reduced.

CASE tools help produce higher quality and consistent documents.


407

Benefits of CASE

Data relating to a software product are maintained in a central repository:

redundancy in the stored data is reduced.

chances of inconsistent documentation is reduced.


408

Benefits of CASE

CASE tools take drudgery out from software engineers’ work:

engineers need not manually check balancing of the DFDs

easily draw diagrams and produce documentation, etc.


409

Benefits of CASE

CASE tools lead to cost saving in software maintenance effort:

traceability and consistency checks,

systematic information capture during various development phases.


410

Benefits of CASE

Introduction of a CASE environment: impacts the style of working of engineers.

makes them oriented towards structured and

orderly approach.


411

Prototyping Support

Prototyping CASE tool: often used in graphical user interface (GUI) development,

supports creating a GUI using a graphics editor.


412

Prototyping Support

The user should be allowed to define:

data entry forms, menus and controls.

It should integrate with the data dictionary of a CASE environment.


413

Structured Analysis and

Design

A CASE tool should: support some standard structured

analysis and design technique.

support easy creation of analysis and design diagrams.

should provide easy navigation through different levels of design and analysis diagrams.


414

Structured Analysis and

Design

The tool must support completeness

and consistency checking.

The tool should disallow inconsistent operations:

but, it is difficult to implement such a feature.


415

Code Generation

As far as code generation is concerned:

expectations from a CASE tool is low.

The CASE tool should support:

generation of module skeletons in one or more popular languages.

Another reasonable requirement is traceability from source code to design.


416

Code Generation

It should automatically generate header information: copyright messages,

brief description of the module,

author name and date of creation, etc.


417

Code Generation

The tool should generate data records or structures automatically:

using data dictionary definitions.

It should generate database tables for relational database management systems.


418

Code Generation

The tool should generate code for user interface from the prototype:

for X window and MS window based applications.


419

Testing Support

Static and dynamic program analysis of programs.

It should generate test reports in ASCII format:

which can be directly imported into the test plan document.


420

Desirable Features

The tool should work satisfactorily

when many users work simultaneously.

The tool should support windowing interface:

Enable the users to see more than one diagram at a time.

Facilitate navigation and switching from one part to the other.


421

Documentation Support

The deliverable documents:

should be able to incorporate text and diagrams from the central repository.

help in producing up-to-date documentation.


422

Desirable Features

The CASE tool should integrate

with commercially available desk-top publishing packages.

It should be possible to export text, graphics, tables, data dictionary reports:

to DTP packages in standard formats such as PostScript.


423

Project Management

It should support collecting, storing, and analyzing information on the software project's progress:

such as the estimated task duration,

scheduled and actual task start, completion date, dates and results of the reviews, etc.


424

External Interface

The tool should allow exchange of information for reusability of design.

The information exported by the tool should preferably be in ASCII format.

The data dictionary should provide

a programming interface to access information.


425

Reverse Engineering Support

The tool should support: generating structure chart, DFD, and data dictionary from source code.

should populate the data dictionary from source code.


426

Data Dictionary Interface

Data dictionary interface should provide

viewing and updating the data definitions.

print facility to obtain hard copy of the viewed screens.

analysis reports like cross-referencing, impact analysis, etc.

it should support a query language.


427

Tutorial and Help

Successful use of CASE tools:

depends on the users’ capability to effectively use all supported

features.

For the first time users:

a computer animated tutorial is very important.


428

Tutorial and Help

The tutorial should not be limited to teaching the user interface part only:

The tutorial should logically classify and cover all techniques and facilities.

The tutorial should be supported by proper documentation and animation.


429

Towards Next Generation

CASE Tool

An important feature of next generation CASE tools:

be able to support any methodology.

Necessity of a CASE administrator for every organization:

who would tailor the CASE environment to a particular methodology.


430

Intelligent Diagramming

Support

Future CASE tools would

aesthetically and automatically lay out the diagrams.


431

The user should be allowed to:

integrate many different tools into one environment.

It is highly unlikely that any one vendor will be able to deliver a total solution.


CASE Tool


432

A preferred tool would support tune up:

user would act as a system integrator.

This is possible only if some data dictionary standard emerges.


CASE Tool


433

Customization Support

The user should be allowed to define new types of objects and connections.

This facility may be used to build some special methodologies.

Ideally it should be possible to specify the rules of a methodology to a rule engine:

for carrying out the necessary consistency checks.


434

Summary

We discussed some fundamental concepts in software maintenance.

Maintenance is the mostly expensive phase in software life cycle:

during development emphasize on maintainability to reduce the maintenance costs.


435

Summary

We discussed software reverse engineering: extract design from code.

Reengineering is a reverse engineering cycle:

followed by a forward engineering cycle


436

Summary

Maintenance process models:

Process model for small changes

Process model for reengineering

We also discussed:

applicability of process models to maintenance projects.


437

Summary

We discussed important features of present day CASE tools:

and the emerging trends.

Use of CASE tools is indispensable for large software projects:

where a team of software engineers work together.


438

Summary

The trend is now towards:

distributed workstation-based CASE tools.

We discussed some desirable features of CASE tools.


439

Software Reuse

Software is becoming very expensive:

a possible way to reduce cost:

reuse parts from previously made software.

assemble software from off-the-shelf components.


440

Software Reuse

Advantages of reuse also include:

reduced number of defects:

standard and well-tested components are reused.

reduced development time:

provide early market access for products.


441

Software reuse

Software development with reuse:

similar to an electronic engineer building an electronic circuit:

uses standard types of electronic ICs and other components.


442

What can be reused?

Specification Design Code Test cases At the most abstract level: knowledge


443

Reuse of Knowledge

More difficult compared to day-to-day reuse of knowledge:

developers vary over time and over projects

difficult to remember details of potentially reusable development knowledge.


444

Why almost no software reuse

so far?

Engineers working in industry often have a frustrated feeling: current system is similar to last few

systems they have already built

everything is being built from scratch

current system is behind schedule: no one has time to figure out what this

similarity really means.


445

Another complaint

In spite of having software components available for reuse:

programmers have preferred to create their own, because:

available components are difficult to understand

difficult to adapt to new application


446

Basic Issues in

Software Reuse

Component creation

Component indexing

Search

Understanding

Adaptation

Repository maintenance KIDS Information Center

447

Basic Issues

Component creation:

Identify reusable components

Component indexing:

classification of reusable components

so that they can be easily searched when we look for a component to reuse.


448

Basic Issues

Search:

search for right components in a database of components

requires a proper method to describe components


449

Basic Issues

Understanding: to decide whether we can use some component we need a precise and sufficiently complete understanding of what the component does.


450

Basic Issues

Adaptation:

A selected component may not exactly fit the problem at hand

Tinkering with the code is not satisfactory:

in any case justified only if thoroughly understood


451

Basic Issues

Repository maintenance:

component entering

tracking faulty components

new applications emerge

older applications become obsolete

components might need changes

obsolete components might have to be removed


452

Domain analysis

Aim:

identify reusable components for a problem domain.

identification of right kind of reusable information is a difficult problem.


453

Domain analysis

Domain analysis identifies: objects, operations and

relationship among them. Consider airline reservation: objects are

seats, flights, airports, crew, meal orders

Operations are scheduling a flight, reserving a seat, assigning a crew to a flight, etc.


454

Domain analysis

Analysis of an application domain: to identify the reusable components

Actual construction of reusable components for a domain is called domain engineering.


455

Reuse at organization level

Reusability should be a standard part in:

specification, design, implementation, test, etc.

Ideally there is a steady flow of reusable components:

in practice, things are not so simple.


456

Reuse at organization level

Extracting reusable knowledge from past projects: presents difficulties not

encountered in working with a current project

typically original developers are no longer available for consultation.


457

Summary

Basic issues in reuse: Component creation Component indexing Search Understanding Adaptation Repository maintenance


458

Summary

Creation of highly reusable components is a very difficult problem a promising approach is domain

analysis

Domain analysis: aims to identify reusable

components for a problem domain


459

Summary

Application generators:

translate specifications into application programs.

facilitate reuse

not very flexible, if new concepts need to be supported.


460

Summary

Reuse at organization level assess product’s potential for

reuse

refine product for greater reusability

integrate product with reuse repository


Component--based

development

Component--based

development

Component--based software engineering (CBSE) is an approach to software development that relies on software reuse.

It emerged from the failure of object--oriented development to support effective reuse. Single object classes are too detailed and specific.

Components are more abstract than object classes and can be considered to be stand--alone service providers.

Independent components specified by their interfaces. Component standards to facilitate component

integration. Middleware that provides support for component inter--

operability. A development process that is geared to reuse.


Definitions:

•• A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard.

•• A software component is a unit of composition with contractually A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third--parties.


Component models

A component model is a definition of standards for component implementation, documentation and deployment.

Examples of component models

EJB model (Enterprise Java Beans)

COM+ model (.NET model)

Corba Component Mode


Common Object Request

Broker Architecture (CORBA)

The Common Object Request Broker Architecture (CORBA) is a specification of a standard architecture for middleware.

Using a CORBA implementation, a client can transparently invoke a method on a server object, which can be on the same machine or across a network.


The middleware takes the call, and is responsible for finding an object that can implement the request, passing it the parameters, invoking its method, and returning the results of the invocation.

The client does not have to be aware of where the object is located, its programming language, its operating system or any other aspects that are not part of an object’s interface.


CORBA reference model

The CORBA reference model called Object Management Architecture (OMA )

The OMA is itself a specification (actually, a collection of related specifications) that defines a broad range of services for building distributed client-server applications.


Functions of Object

Request Broker (ORB)

ORB is the central component of the CORBA architecture.

The main responsibility of ORB is to transmit the client request to the server and get the response back to the client.

ORB abstracts out many procedures involved in service invocation and makes service invocation by client seamless and easy.

The main responsibilities of ORB are the following: • Server location

• Server state management

• Communication between clients and servers


The ORB must support a large number of functions in order to operate consistently and effectively.

The ORB implements much of these functionality as pluggable modules to simplify the design and implementation of ORB and to make it efficient.

ORB allows objects to hide their implementation details from clients.

This can include programming language, operating system, host hardware, and object location.


Commercial ORBs

There are several ORBs that are commercially available. • Visigenic: This is probably most popular one.

Netscape browser supports Visigenic. CORBA applications can be run using Netscape web browser. In other words, Netscape browser can act as client for CORBA applications. Netscape is extremely popular and there are several millions of copies installed on desktops across the world.

• IONa

• Orbix

• Java IDL


Component Object Model

(COM)

The main idea in the Component Object Model (COM) is that:

• Different vendors can sell binary components.

• Application can be developed by integrating off-the-shelf and proprietary components.

COM runs on a single computer.

The concepts used are very similar to CORBA.

The components are known as binary objects.


Distributed Component

Object Model (DCOM)

Distributed Component Object Model (DCOM) is the extension of the Component Object Model (COM).

The restriction that clients and servers reside in the same computer is released here.

So, DCOM and CORBA both operate on networked computers.

Here development is much easier as compared to CORBA development.

Many of the things are transparent to the programmer such as proxy generation, service invocation etc.


CORBA vs. COM/DCOM

If it is the case that all applications reside on PCs and are to run fully on Microsoft platforms then it will be better to use COM/DCOM because development would be much easier here. • If an application is to be developed for a

heterogeneous environment then it will be better to use CORBA.

• Microsoft is very strong on desktop applications i.e. GUI-based applications. Whereas, CORBA-based development is stronger on server side. Java Beans promise to overcome the shortcoming on desktop side i.e. the client part.
