Lecture 4

Seite 1

Objectives of reviews

Detect error

Identify new risks

Deviations

Exchange of knowledge

Promote development methods

Formal design review

Peer review

Expert opinion

Participants

Inspection

MITD

Walkthrough

ACUMS

Difference:

Participants

- Superiors

Authority

- Authority

Authority

FDR

- Superiors with managerial authority

Peer Review

- No authority

When is expert useful?

When there is insuffivcient manpower

The professionals not available

Professional disagreement

Contract Reviews

sTAGES

Revies the final proposal draft and the documents on which it is based

Contract Draft Review

Reviews the contract draft basis of the proposal

Objectives of Contract Review:

Proposal Draft Review:

Formal relationship established with customer

ements have been clarified and documented

Alternatives of the project can be found

Contract Draft Review

No unclarified issues remain

understandings are documented

No changes are found

What affect extent of contract review>

Project size

Acquaintance

Number of additional organizations

Difficulties

Time constraint

Invest working hours, manpower

Methods to conduct a major contract review

Part of the proposal preparation schedule

Carried out by a team

Contract review leader leads

Importance of carrying it out for inernal projects

Loose relationship, failure

Adequate procedure should be maintained

Seite 2

Lecture 5

Reliability definition (PET)

Failure free operation

Specified time

Specified Environment

Purpose

FAILURE, FAULT

Failure

Faults do not necessarily cause failures.

Improving reliability

Fixing the fault at the part of the software that is used frequently

FORMAL METHODS

Proven that the software that follows formal methodsconforms to the specification

Forces a detailed analysis of the system

It may not actually improve, because...

The specification may not follow what the customer wants

May hide problems because users don't understand

Reliablility vs Efficiency

Reliability >, Efficiency <

To make it reliable, redundant code must be added

Which is more important?

Reliability!

Computers are already fast

Unreliable software will be discarded

Harder to improve unreliable system than inefficient one

Software failure cost

Reliability Metrics

Hardware metrics is for component failures

Software metrics is for design failures

Reliability Metrics Type

POFOD

Likelihood the software will fail in a number of request

E.g. 1 out of 1000 is 0.001=pofod

ROCOF

Frequency of occurence

e.g.: 0.02 is 2 failures in each 100 operational time units

MTTF

Time between failures

MTTF of 500 = time between failures is 500

Availability

How likely the system is available for use

0.998 means it is available

So what is time units?

Raw time

Calendar time (those that ave pattern

Number of transactions (on demand)

Reliability Specs

Operational profile is important

Dynamic, reliability

Failure classes

pr cunt

Steps to reliability specs

Consequences of system failures

Partition it to classes

Use approppriate metric

Statistical testing

Testing software for reliability

Seite 3