SWQA CBC Intro 2 4

Software Quality Assurance
Introduction for SV C BC
Materials used from

P730103- training materials S .Judmann
SWQA_CBC_Intro_2.1.ppt designed by F.Cantaretu, reworked by c. Hoffmann/H.Jacobsen from SV CBC based on P04906 , P04907 , P730135 (last change: 17.8.2004)
What is Quality Assurance
Quality Assurance: A set of activities designed to ensure

that the development process is adequate and that the
system will meet its objectives
source:
www.mosaicinc.com
Aspects:
• define activities
• ensure these activities are executed
© SQA_CBC - SW Quality Assurance 2

Software Quality Assurance - Overview
 Documents & SWQA Process introduction

 Review Method
 Software Metrics
 Software Audits
 Planning of SWQA
 SW Defect Analysis
6x

SW Process Description Overview
Siemens Process House
P730003b
SV Level including: P730103a * recommendations
SW SW Quality * templates
Review Procedure
Development Assurance * methods ...
Guideline Guideline
P730132a P730135a * recommendations

SV C BC Level
SW Development SW Quality * templates
Guideline Assurance Guideline * methods ...
SW
Project Level
Development
Plan

SWQA Project Organization
P730135a Software Quality Assurance Guideline for CBC


 Review Method
 Software Audits
6x

Review Method - Overview
 Why Reviews?
 Review Procedure
 Quality Assurance in SW Development Process
 Review Types
 Roles in Reviews
 Review Processes
 Recommendations

Why Reviews?
Review justification: Occurrence and Elimination of Defects
Cost related defect rate

75% of defects 80% of defects
Defect Defect recognition

generation and elimination
Source: Process
NMA Definition Development Manufacturing Testing Usage
planning
Planning phases Implementation phases Usage
Source: Review Seminar, ZPL 1 MPP 6, Mch P

Example: Root Cause of Errors

Why Reviews? Requirements from Normative References
Framework
ISO 9000
Automotive Business:
Development
ISO 9001 QS9000

QS9000
...
...
SW. Dev.
ISO 9000-3
“The supplier shall carry out reviews to ensure that the requirements are
met […].
The design or implementation process should not proceed until
 the consequences of all known deficiencies are satisfactorily resolved or
 the risk of proceeding otherwise is known.
Records of such reviews should be maintained”
ISO 9000-3, Section 5.6.4

Why Reviews? Targets
Avoid loops in the development process Save time and money
Recognize failures, risks …

as soon as possible Less changes in following phases
Information exchange between

interfaces Less problems
Documented way of proceeding

and results Being auditable and repeatable
Uncover
Uncovergaps,
gaps,failures,
failures,problems
problemsand
andrisks
risksin
indevelopment
development
"find
"findthe
theimportant
importanterrors"
errors"

Why Reviews? Review justification
• No 100 % coverage
• Both methods complement one
Review versus Test
another, they do not replace
each other
Review Test
Reviews are an important

means to improve the
software quality

Review Procedure – Characteristics of a Review
Phase 1 Phase 2 Phase 3 Phase 4
• planned
• formal
• documented
• systematic
• critical
The view back!
Checking of
the result(s)

Review Procedure - Quality Assurance during the Software Development
Development Process
Delivery to
System
(internal)
Requirements
Customer
relevant for SW
Software Software
S2 Requirements Validation Test Software S6
Specification Specification Validation
Software
Integrated
Requirements Software
Software
Specification Integration Test
Specification
Software
S3 Software
Module Test
Integration
S5
Design
Specification
Verified
SW Design Modules
Document
Module Verification
Coding (Operation level & S4
Module level) = Result/
Document
Code
= Activity
 Phase : Project-specific combination of several activities .They are the basic elements of a V-cycle.
The end of phase has to be given special consideration and may be a milestone.

Review Procedure - Review types
Document Reviews:
EoP Review n 1. Separate reviews of defined documents
2. General Technical Review,
Milestone n
combination of several documents
BoP Review n+1 Begin of Phase Review:

1. All prerequisites for next phase defined
DocR 1
DocR 2
... End of Phase Review:
1. Examination of the successful implementation
DocR general of all defined Document Reviews
EoP Review n+1 2. Examination of the Project Status, regarding
the requirements of the corresponding
milestone
Milestone n+1 3. Harmonization between involved departments

Review Procedure - Review types - Document review (DocR)
Permits:
 early error detection and correction for the SW product

 reduction of the error correction cost
 error prevention due to immediate feed-back to the author
 compliance with standards and existing rules
 know-how transfer among the participants
 minimization of the development time

Begin of Phase Review (BoPR)
Answers the following questions:
 is the next development-cycle defined / planned?

 content
 resources
 deadlines
 quality
 costs

End of Phase Review (EoPR)
Answers the following questions:
 have the development objectives been fulfilled?

(e.g., cost, delay, functionalities, quality, methodology)
 can the work products be improved? How?
 can the development process be improved? How?
 has the planned milestone been reached?

Review Procedure - Roles
The Author (Au): responsible for the review object (and its quality!)
 organizes the review:
- invitation - meeting (if necessary)

- distribution of the object and the supporting
?
documents
 provides the object to be examined
 states the main emphasis of the review
 supports on demand all participants
 acts in an `open-minded´ way
 reworks all items from the Comment List

The Moderator (Mo): responsible for carrying out the review
 coordinates the allocation of roles (with the author)
!
 checks if the object is ready for review
 acts as a facilitator
 write down and distribute the Comment List
 checks the rework from the Comment List
 write down and distribute the Review Report

The Reviewer (Re): responsible for the verification of the review object
 gets himself prepared in the object 

(according to the review criteria and main emphasis)
 checks and documents mistakes, shortcomings, risks,
unresolved items ….
 behaves in a way that the review is achieving its
objectives
 during the meeting, states all items he has found.

Review Procedure - Review Methods and when to apply them
unless defined differently in the SWDP
NO Safety YES
Critical
?
First / Last Release Intermediate Releases / First / Last Release

Intermediate Releases /
Changes Release
Changes Release
Type Type
Document Walk Trough Intensive

Walk Trough Inspection
Review (WT) (WT)
(DR) (II)
for minor changes a delta review may be done (if agreed by SWPL/SWQPE)

Review Procedure - Walkthrough - WT
Remark:
• this method can be used for Phase reviews
At least 3 participants: Author, moderator (also reviewer), reviewer
Preparation phase:
• Each reviewer works through the review object and records his comments (template
available)
Meeting:
• The moderator “guides” through the review object, by naming the unit to be discussed.
• The reviewers submit their comments.
• The recorder of the minutes records all weak spots, errors and open items in the
minutes.
• At the end of the meeting all participants decide whether a re-run of the review is
required.
• The deadline for the release of the document or the follow-on meeting is fixed.
After the Meeting:

• The author reworks the review object based on the statements in the review minutes.
Release of the document.

Review Procedure - Document Review (with commentary) - DR
Remarks:
• method appropriate:
1. for large and / or new documents
2. when a broad variety of feedback is needed
3. if the reviewers are at different locations or it is difficult to get them all to a
meeting
Steps:
• Each reviewer works through the review object and records his comments about
ambiguities, errors and defects in writing.( template available)
• At a fixed point of time, the comments are sent back to the author.
• The author compiles the comments in an error list and analyzes them with regard to
their implementation.
• The error list together with the evaluations is sent to every review participant.
• Up to a predetermined point of time the participants can send comments about the
evaluated list.
• The author reworks the review object with the aid of the evaluated error list.
• The author distributes the updated review object and the evaluated error list

Review Procedure- Intensive Inspection - II
At least 4 participants: Author, moderator, reader, inspector
Introduction meeting:
• The author introduces the inspectors to the inspection object. He provides an overview of the subject
matter and structure of the inspection object and the scope of the individual inspection meetings.
Preparation phase:
• Each inspector works through the inspection object alone with special attention to the duties/role
assigned to him. Each one records comments on ambiguities, errors/defects in writing.
Inspection meeting:
• The reader explains the inspection object in his own words.
• The participants formulate ambiguities or variations in understanding, defects and errors.
• In case of differences in understanding or lack of clarity with regard to the existence of an error, a brief
discussion will be held.
• If an issue remains unclear, it will be noted as an open item in the review protocol.
• At the end of the meeting all participants decide whether a re-run of the review is required.
After the meeting:
• The author reworks the review object based on the statements in the review minutes.

Software Reviews – SV CBC reviews overview (example) 1
Project Management Process
Review Review Distribution of Remark
object Part. Resp. When Method
reviewed object
(role) (role) (role) and
protocol
PM All review This is not a document but phase review.
SWGL participants Supporting documents (according to the BOP/SWDP
Project
BOP SWPM SWPM WT (incl. optional Review Checklist refer to intranet) have to be
start
QPE ones) reviewed and released as pre-condition by all
SWQPE SWD involved parties with the method valid for BOP.
PM All review
SWGL participants This is not a document but phase review.
Project
EOP SWPM SWPM WT (incl. optional The goal of this review is to check works defined at
end
QPE ones) BOP
SWQPE SWD
!
Note
Review participants marked as
underlined are mandatory,
others are optional
!
Note
Additional review participants
shall be chosen if this benefits
the review

Release Management Process
Review Review Distribution of Remark
object reviewed object
Part. Resp. (role) When Method (role) and protocol
(role)
PM
SWGL This is not a document but phase review.
Each release All review participants
SOR (1) SWPM SWPM WT Supporting documents: SOR Review
(start) (incl. optional ones)
QPE Checklist (refer to intranet)
SWQPE
PM
SWGL This is not a document but phase review.
Each release All review participants
EOR (1) SWPM SWPM WT Supporting documents: EOR Review
(end) (incl. optional ones)
QPE Checklist (refer to intranet)
SWQPE
!
Note
Review participants marked as
underlined are mandatory,
others are optional

Software Specification (Input documents for SW development)
Security Level Review Review Distribution of Remark
reviewed object
protocol
Customer
II: For first and last release
SWD
BOP All review WT: For intermediate releases
SWFR II
CRS Author Each participants (incl. and changes coming from the
SWPM WT
release optional ones) Change Mgmt. Process
SWTE
Only in case of modifications
SWQPE
Safety
Customer
II: For first and last release
SWD
BOP All review WT: For intermediate releases
SWFR II
SRS Author Each participants (incl. and changes coming from the
SWPM WT
SWTE
SWQPE
Customer
WT: For first and last release
SWD
BOP All review DC: For intermediate releases
SWFR WT
CRS Author Each participants (incl. and changes coming from the
SWPM DC
SWTE
SWQPE
Non safety
Customer
WT: For first and last release
SWD
BOP All review DC: For intermediate releases
SWFR WT
SRS Author Each participants (incl. and changes coming from the
SWPM DC
SWTE
SWQPE

Software Design
Security Level Review Review Distribution of Remark
reviewed object
protocol
SWD All review II: For first release
(<>author) participants (incl. WT: For other releases and
Each II
SWAD SWFR Author optional ones) changes coming from the
release WT
SWPM All SW Team Change Mgmt. Process
SWQPE SWQPE Only in case of modifications
Safety
SWD All review II: For first release
(<>author) participants (incl. WT: : For other releases and
Each II
SDD SWFR Author optional ones) changes coming from the
release WT
SWD All review WT: For first release

(<>author) participants (incl. DC: : For other releases and
Each WT
SWAD SWFR Author optional ones) changes coming from the
release DC
Non safety
SWD All review WT: For first release
(<>author) participants (incl. DC: : For other releases and
Each WT
SDD SWFR Author optional ones) changes coming from the
release DC

Coding
Security Review Review Distribution of Remark

Level object reviewed object
(role) and
Part. Resp. When Method protocol
(role) (role
)
Code
SWD
Complete Protocol or information
Source Code (<>author) Author II Only in case of modifications.
(each to SWQPE
SWQPE
release)
Safety
Code
Module SWD Static
Complete Protocol or information Only in case of modifications.
LINT/MISRA (<>author) Author Cross
(each to SWQPE Informal checking
report SWQPE check
release)
Code
Module SWD Static
Complete Protocol or information Only in case of modifications.
Non safety LINT/MISRA (<>author) Author Cross
(each to SWQPE Informal checking
report SWQPE check
release)

Module Testing

Level object reviewed object (role)
Part. Resp. When Method and protocol
(role) (role)
SWFR Before test

Safety SW module
SWD setup
& test Author DC SWQPE Only in case of modifications.
(<>author) (each
Non safety specification
SWQPE release)

Software Integration

Part. Resp. When Method and protocol
(role) (role)
SWD II: For last release

SW
(<>author) SWPM WT: : For other releases and
Integration Each II
SWFR Author changes coming from the
test release WT SWQPE
SWPM Change Mgmt. Process
specification
SWQPE Only in case of modifications
Safety
SWD
SW (<>author)
Last SWPM
Integration SWFR Author DC Informal checking
release SWQPE
test report SWPM
SWQPE
SWD WT: For last release

SW
(<>author) SWPM DR: : For other releases and
Integration Each WT
SWFR Author changes coming from the
test release DC SWQPE
SWPM Change Mgmt. Process
specification
SWQPE Only in case of modifications
Non safety
SWD
SW (<>author)
Last SWPM
Integration SWFR Author DC Informal checking
release SWQPE
test report SWPM
SWQPE

Software Validation

and protocol
Part. Resp. When Method
(role) (role)
Customer
SW SWFR
Validation SWD Each SWPM
Author WT
test (<>author) release SWQPE
specification SWPM
SWQPE
Safety
& SWFR
Non safety SW SWD
last SWPM
Validation (<>author) Author DC Informal checking
release SWQPE
test report SWPM
SWQPE
Static
System LINT For last SWPM
SWD Author cross Informal checking
report release SWQPE
check

Review Procedure - General rules & profit
 Preparation of participants
 Critical observation of development
results but no revision
 No judgment on the project team
The outcome
 Open discussion about review object
of a review  Questions of checklist can just touch a
depends
on your subject (further questions should result)
commitment!  No problem-solving discussion
(note suggestions for solutions)
 Let all participants get involved in
discussions
 Duration  2 hours / meeting

Support for reviews
Templates
– Invitation
– Comment List
– Status Sheet
 Checklists
– Current status daily
available
– Special checklists (kick
off, etc.)
 Proceeding guidelines

Review Procedure - Comment List (Templates)
Document Reviews: Microsoft Word

Document
Phase Reviews:
Microsoft Word
Document

Review Procedure - Type of Comment
Remark(R)
The requirements for document / code are basically fulfilled.

Eventually there are small non conformances, but they have
no influence on the required behavior of the
functionality (e.g. design/code optimization in terms of size
and or execution time which shall be planned and taken into
consideration for further releases)
Error(E)
There are: Risks / Malfunctions / Nonconformance that may

influence the specified behavior of the functionality. All
the errors have to be resolved in order to go to the next V Cycle
phase.

Review Procedure - Conclusion of a Review meeting
Phase Review Document Review

without / small lacks
green
One or more major non- finished without / small lacks
conformities are present, but for
all of them actions are planned
yellow that could resolve the non-
conformity in time for the release
not rework +
finished Follow Up-Review
At least one major non-conformity necessary
is present and resolving actions
can not be completed in time for
red the release. note: no colors for doc reviews!
In case the participants cannot agree on the color assigned to a

phase review, the color is defined by the SWQPE

Common Problems
● bad/incomplete selection of participants
● participants are not filled correctly (Copy/ Paste)
● naming rules are not considered (e.g. "Review Protocol", "SVVP_Mirror")
● one or two Open Items are left over
● SWQPE not informed (makes it tedious to update the status sheet)
● bad preparation (no preparation at all)
● unclear which reviews have to be performed
● only walk trough method known / applied
● No CM applied / storage location unclear
● Checklists are unknown / not used / incorrect used


 Review Method
 Software Audits
6x

Software Metrics - Why SW Metrics?
For
For the
theassessment
assessmentof
of

the
thesoftware
softwareproducts
products(e.g.
(e.g.number
numberof
ofbugs)
bugs)and
and
 the software development process itself (Spec freeze, delay, …)
 the software development process itself (Spec freeze, delay, …)
Each
Eachproject
projectshould
shouldcollect
collectsuitable
suitabledata
datatotocalculate
calculate
Software
SoftwareQuality
QualityIndicators
Indicators
(responsibility
(responsibilityof
of the
the Software
Software Project
Project Leader).
Leader).

Software Metrics - SW Measurement Process
Overview
Project A
data collection
SW metrics eva
measurement lu experience
definition planning inte ation storage
rva
l
metrics usage
project planning development process project completion

Software Metrics – CBC SW Quality Goals
•0 SAR with „top level“ status in a SW delivery to a customer
•Continuous improvement during SW development
•Low utilization of HW resources
Further information: M20015 Software Measurement Guideline/ P730135

Software Metrics
0 SAR with „top level“ status in a SW delivery to a customer
Number
Numberofofred
redphase
phasereviews
reviews ( (SWDP/SOR/EOR
SWDP/SOR/EOR) )


Number
Numberofoftechnical
technicalreviews
reviews( (SRS
SRS/ /SDD
SDD/ /Code
Code/ /MTS-ITS-VTS)

 MTS-ITS-VTS)
SW
SWspecification
specificationfreeze
freezedelay
delayafter
afterSOR
SOR(linked
(linkedtotocustomer
customerworks)

 works)
Number
Numberofofmain
mainspecification
specificationchanges
changesafter
afterSOR
SOR(linked
(linkedtotocustomer
customerworks)

 works)

Software Metrics
Continuous improvement during SW development
Cumulated
CumulatedSARs
SARsduring
duringdevelopment

 development
Who
Whofound
foundanomalies
anomalies(SAR)

 (SAR)
%%reuse
reuseatatSV
SVCCBC
BClevel
level) )


C umulated S AR ( Found/ c orrec ted)

50 S everi ty of def ec t s
14
Low
40 12 Medium
30
10 High
8 Top
20 Found 6
Unknown
10 4
Corrected
2
0
0
Unknown 14080200xx 14080201xx 14080202xx 14080203xx
C ause of def ects Code Who f ound anomalies

14 Customer
10
Design 12
8
Siemens
Spec 10
Unknown
6 Unknown 8
6
4
4
2 2
0
0

Software Metrics
Low utilization of HW resources
 ROM
 ROM
 RAM
 RAM
 EEPROM
 EEPROM
CPU
CPULOAD

 LOAD
Hard Ware Ressourc es

120%
100%
80% Used ROM
60% Used RAM
40% Used EEP ROM
20%
Used CP U Time
0%
14080200xx 14080201xx 14080202xx 14080203xx


 Review Method
 Software Audits
6x

Audits/Assessments ...
... check the compliance of the project to the process
Goals:
● detect possible quality-issues within the project
and define corrective actions
● detect issues within the process to trigger
improvements

Audits/Assessments
 internal (project, SV CBC, SV ...)

 external (customer)
Focus:
 get a realistic view on the project to identify areas of
improvement
vs.
 do a "good show" to increase the confidence of the
auditors that the project is doing a good job

Common Audits
Required for all projects
 baseline audit check the CM-baselines
 CM audit check the usage of the CM System
Required on internal demand

 internal project audit check conformance to the process of
a project
 internal CMMI audit check the maturity of the process
Required on customer demand

 external audits check the capability of the projects
or organization


 Review Method
 Software Audits
6x

Planning of Software Quality Assurance
Planning
PlanningSW
SWReviews
Reviews
•Plan does not contain any date. The concrete dates and the names of all involved persons
•Plan does not contain any date. The concrete dates and the names of all involved persons
Software
Softwarequality
quality
are given in the schedule planning.
are given in the schedule planning.
objectives
objectivesfor
forthe
the
•deviations and enhancements to the reviews are listed :
•deviations and enhancements to the reviews are listed :
project
project
•Reviews not performed
•Reviews not performed
•Reviews adapted for this project
•Reviews adapted for this project
QA
QAMetrics
Metrics
•Reviews additionally performed in this project
•Reviews additionally performed in this project
Software
6.5 Software Development
Quality Assurance Plan
Plan
Key
Keyactions
actions
necessary
necessaryfor
forSW
SW
quality
quality
Planning
PlanningSW
SW
Audits Software
Software
Audits
QA
QA
Reportin
Reportin
gg

Key actions 1
 The
Thequality
qualityof
ofthe
thesoftware
softwareofof aaproduct
product mainly
mainlydepends
dependson on
the
theperformance
performance of of specific
specific main
maintasks
tasks within
withinthe
the
software
softwaredevelopment.
development.
 These
Thesecan
canbebeassigned
assigned toto process
processareas,
areas,toto phases
phaseswithin
within
the
thedevelopment
developmentcycle
cycle or
orthe
thedevelopment
development ofof basic
basic
software
software which
whichisisused
usedwithin
withinthe
theproject.
project.

Key actions 2
 All
Allthe
theSW
SWdevelopment
developmentkey keyactions
actionsare
aredescribed
describedononP730135a
P730135aand
and
are
aremandatory
mandatory
–– IfIfaakey
keyaction
actionisisnot
notfulfilled
fulfilledthen
thenaadeviation
deviationprocess
processmust
mustbe
be
set
setup,
up,written
writtenin
inthe
theSWDP
SWDPand andapproved
approvedin inSWDP
SWDPreview
review
 The
Thekeys
keysaction
actionare
areclassified
classifiedby
bysubjects,
subjects,Topics
TopicsSubtopics
Subtopics
•• Examples
Examplesfor
fortopics:
topics:Project
Projectmanagement,
management,Configuration
Configuration
management….
management….
 Some
Someof
ofthe
thekey
keyactions
actionswill
willbe
bemeasured
measuredby
bymetrics
metrics

Key actions 3
 The Key Actions in Detail
Microsoft Word
Document

Tailoring of SWQ-activities (1)
Tailoring
 adapt the general process to the specific needs of a
project
 has to be documented in the SWDP (or related

documents, e.g. SW test strategy)
 has to be agreed between SWPM and SWQPE

 Process areas that are allowed to be tailored within the

SWDP are:
– SW quality objectives (only additional ones can be

defined; leaving out not allowed)
– Reviews (except those for safety critical review objects)
– Metrics
– Reports
– some restrictions exist

 Process areas that are not allowed to be tailored and

which therefore can not be left out are:
– Reviews for safety critical review objects

– Software QA Audits
– General tasks of SWQPE (e.g. tracking)


 Review Method
 Software Audits
6x

SW defect analysis (1)
is a
method to find the real reason for a bug (root cause)
to
find appropoiate countermeasures to prevent this kind
of bugs in the future

SW Defect analysis (2)
select scope e.g. bugs found by customer
gather data e.g. Change Synergy, interviews with SWD,
check effectiveness
SWPL, SWTE ...
classify data e.g. common phase, common reason
select typical bugs
develop countermeasures
evaluate countermeasures e.g. cost vs. assumed effectiveness
implement countermeasures


 Review Method
 Software Audits
6x

Where to find documents
 PMTQ Sitemap
– https://intranet.sba.siemensvdo.com/chassis_carbody/organization/bc/orga
nization/products/p3/pmtq/start.asp
 Process World overview

nization/products/p3/pmtq/SWDevProc/Start.asp?
load=ProcessWorld_en.asp
 PMTQ QA-pages
nization/products/p3/pmtq/SWQA/Start.asp

Thank you
for listening!

SWQA CBC Intro 2 4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SWQA CBC Intro 2 4

Uploaded by

Copyright:

Available Formats

Software Quality Assurance

Materials used from

Quality Assurance: A set of activities designed to ensure

© SQA_CBC - SW Quality Assurance 2

 Documents & SWQA Process introduction

© SQA_CBC - SW Quality Assurance 3

Siemens Process House

P730132a P730135a * recommendations

© SQA_CBC - SW Quality Assurance 4

P730135a Software Quality Assurance Guideline for CBC

© SQA_CBC - SW Quality Assurance 5

 Documents & SWQA Process introduction

© SQA_CBC - SW Quality Assurance 6

© SQA_CBC - SW Quality Assurance 7

Cost related defect rate

Defect Defect recognition

Planning phases Implementation phases Usage

Source: Review Seminar, ZPL 1 MPP 6, Mch P

© SQA_CBC - SW Quality Assurance 8

© SQA_CBC - SW Quality Assurance 9

ISO 9001 QS9000

© SQA_CBC - SW Quality Assurance 10

Avoid loops in the development process Save time and money

Recognize failures, risks …

Information exchange between

Documented way of proceeding

© SQA_CBC - SW Quality Assurance 11

Reviews are an important

© SQA_CBC - SW Quality Assurance 12

Phase 1 Phase 2 Phase 3 Phase 4

© SQA_CBC - SW Quality Assurance 13

© SQA_CBC - SW Quality Assurance 14

BoP Review n+1 Begin of Phase Review:

© SQA_CBC - SW Quality Assurance 17

 early error detection and correction for the SW product

© SQA_CBC - SW Quality Assurance 18

Answers the following questions:

 is the next development-cycle defined / planned?

© SQA_CBC - SW Quality Assurance 19

Answers the following questions:

 have the development objectives been fulfilled?

 can the work products be improved? How?

 can the development process be improved? How?

 has the planned milestone been reached?

© SQA_CBC - SW Quality Assurance 20

- invitation - meeting (if necessary)

© SQA_CBC - SW Quality Assurance 21

The Moderator (Mo): responsible for carrying out the review

 coordinates the allocation of roles (with the author)

© SQA_CBC - SW Quality Assurance 22

 gets himself prepared in the object 

© SQA_CBC - SW Quality Assurance 23

unless defined differently in the SWDP

First / Last Release Intermediate Releases / First / Last Release

Document Walk Trough Intensive

© SQA_CBC - SW Quality Assurance 24

At least 3 participants: Author, moderator (also reviewer), reviewer

After the Meeting:

Release of the document.

© SQA_CBC - SW Quality Assurance 25

Release of the document.

© SQA_CBC - SW Quality Assurance 26

At least 4 participants: Author, moderator, reader, inspector