Ch04 Process

7/29/2019 Ch04 Process

1/24

within a Software Process

(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 1


2/24

development process u an overa p c ure o e qua y process

Identify the main characteristics of a quality

process visibility

anticipation of activities

feedback



3/24

Quality results from a set of inter-dependent activities

Analysis and testing are crucial but far from sufficient.

Testing is not a phase, but a lifestyle Testing and analysis activities occur from early in requirements

engineering through delivery and subsequent evolution. Quality depends on every part of the software process

software test and analysis is thoroughly integrated and



4/24

responsibilitiesdependability

usability

selecting and arranging activities

-important goals.



5/24

high dependability vs. time to market

better to achieve a reasonably high degree of dependability on

a tight schedule than to achieve ultra-high dependability on a

much longer schedule Critical medical devices:

etter to ac eve u tra- g epen a ty on a muc ongerschedule than a reasonably high degree of dependability on a

tight schedule



6/24

planned to detect each important class of.

Timeliness: Faults are detected at a point of

g everage as ear y as poss e Cost-effectiveness: Activities are chosen

depending on cost and effectiveness

cost must be considered over the wholedevelopment cycle and product life

the dominant factor is usually the cost of repeating


an ac v y roug many c ange cyc es.


7/24

Balances several activities across the whole

Selects and arranges them to be as cost-effective as

Improves early visibility

careful planning

ann ng s n egra o e qua y process



8/24

the question

How does our progress compare to our plan? Example: Are we on schedule? How far ahead or behind?

The quality process has not achieved adequate visibility

the software system before it reaches final testing quality activities are usually placed as early as possible

design test cases at the earliest opportunity (not ``just in time'')

uses analysis techniques on software artifacts produced before

actual code. motivates the use of proxy measures

Ex: the number of faults in design or code is not a true measure ofreliability, but we may count faults discovered in design


nspect ons as an ear y n cator o potent a qua ty pro ems


9/24

- -

that must be satisfied , . .,certificates

documents that must be produced



10/24

A com rehensive descri tion of the ualit rocess that

includes:

objectives and scope of A&T activities items to be tested features to be tested and not to be tested

staff involved in A&T constraints

pass an a cr ter a schedule

deliverables hardware and software requirements risks and contingencies



11/24

,....

Product qualities internal qualities (maintainability,....)

usefulness qualities: , , , ,

interoperability

dependability correctness, reliability, safety, robustness



12/24

A program is correct if it is consistent with its specification

seldom practical for non-trivial systems

Reliability: likelihood of correct function for some ``unit'' of behavior

relative to a specification and usage profile statistical approximation to correctness (100% reliable = correct)

preventing hazards

acceptable (degraded) behavior under extreme conditions



13/24

,

let traffic pass according

to correct pattern andcentral scheduling

Robustness safet :

Provide degradedfunction when possible;never signal conflictinggreens.

Blinking red / blinkingyellow is better than nolights; no lights is better


t an con ct ng greens


14/24

robust but notreliable but

safe: catastrophicfailures can occur

not correct:failures

occur rarel

Correct Safe

safe but not

correct:

correct butnot safe or

robust: theannoying

failures canoccu

specificationis inadequate



15/24

manual inspection techniques au oma e ana yses

can be applied at any development stage

particularly well suited at the early stages ofspecifications an design



16/24

can be a lied to essentiall an document requirements statements

architectural and detailed design documents program source code

may also have secondary benefits spreading good practices instilling shared standards of quality.

takes a considerable amount of time re-inspecting a changed component can be expensive

used primarily w ere ot er tec niques are inapp ica e where other techniques do not provide sufficient coverage



17/24

can be applied to some formal representations of

not to natural language documents

substituting machine cycles for human effort makes- .



18/24

Start as early as possible Early test generation has several advantages

Tests generated independently from code, when the

specifications are fresh in the mind of analysts The generation of test cases may highlight

ncons s enc es an ncomp e eness o ecorresponding specifications

specifications by the programmers



19/24

It is important to structure the process for Identifying the most critical persistent faults

tracking them to frequent errors

adjusting the development and quality processes toeliminate errors

Feedback mechanisms are the main ingredient

of the quality process for identifying andremoving errors



20/24

separate development and quality teams is common

indistinguishable roles is postulated by some

Different roles for development and quality?

mobility of people and roles by rotating engineers

projects is a possible option



21/24

Example of Allocation of

Responsibilities

we can allocate

Unit testing to the development team (requires detailed knowledge of the

code)

but the quality team may control the results (structural coverage)

Integration, system and acceptance testing to the quality team

but the development team may produce scaffolding and oracles

Inspection and walk-through to mixed teams

to quality and maintenance teams

Process improvement related activities


o ex erna spec a s s n erac ng w a eams


22/24

Allocation of Responsibilities and rewarding

mechanisms: case A allocation of res onsibilities

Development team responsible development m

easured with LOC per person month Quality team responsible for quality

possible effect

Development team tries to maximize productivity,without considering quality

ua y eam w no ave enoug resources or aquality products

product of bad quality and overall project failure



23/24

Allocation of Responsibilities and rewarding

mechanisms: case B

Development team responsible for both

possible effect

e pro em o case s so ve

but the team may delay testing for development

result

e ivery o a not u y teste pro uct an overaproject failure



24/24

must be sutiably planned and monitored

principles:

early activities feedback

aims at

reducin occurrences of faults assessing the product dependability before delivery

improving the process


Ch04 Process

Documents

Transcript of Ch04 Process