115
© 2011 by Taylor & Francis Group, LLC
12
Formal Reviews and Audits
Formal Reviews provide programs or projects the necessary steps to sup-
port applicable and scheduled milestones. ey also provide a forum for
design evaluation with experienced participants from other organizations
during design development. e purpose of these meetings is to review
the status of preparation for the formal design reviews and ensure that the
design review objectives are accomplished. Meeting representatives from
the responsible project groups and technical integration, and personnel
from any other aected groups will attend. Plans are discussed and devel-
oped for collection, sharing, and closure of action items from the review(s).
If customers are attending, involve them in developing appropriate plans
or actions discussed in the Formal Review. In Formal Reviews, presen-
tations and discussions are staged, and meeting attendance and action
items are recorded. Initiate and coordinate follow-up for each action item
assigned during the Formal Review. Upon resolution of each review action
item, provide appropriate information to the presenter.
In order to maximize quality, the following agenda items for Formal
Reviews are provided:
Introduction
Scope
Actions
Agreement
Meeting Closure
116  •  Soware Engineering Reviews and Audits
© 2011 by Taylor & Francis Group, LLC
12.1 SYSTEM REQUIREMENTS REVIEW
e functional baseline is comprised of the system and segment specica-
tions. It is established upon the baseline during the System Requirements
Review (SRR).e required documents are placed under high-level change
control. e functional baseline is augmented at subsequent lifecycle reviews
and is maintained and updated under conguration management control.
12.2 SYSTEM DESIGN REVIEW
At the System Design Review (SDR), change control is implemented to
the functional baseline. e functional baseline describes the system’s
functional, physical, and interface requirements, which consist of archi-
tectural, functional, and performance decomposition. Physical and func-
tional lines are determined by segment requirements.
12.3 SOFTWARE SPECIFICATION REVIEW
e purpose of the Soware Specication Review (SSR) is to demonstrate
to the customer the adequacy of the soware and interface requirements
to proceed into the design phase.
12.4 PRELIMINARY DESIGN REVIEW
e purpose of the Preliminary Design Review (PDR) is to determine if the
top-level design of the soware is mature and complete enough to advance
to the detailed design phase. During the Preliminary Design phase, the
system-level architecture, interfaces, and design are developed. A PDR is
held and approval is obtained before proceeding with the detailed design
phase. Activities include the following:
Establish and maintain Soware Development Library (SDL).
Establish corrective action process for developmental conguration.
Formal Reviews and Audits  •  117
© 2011 by Taylor & Francis Group, LLC
Attend PDR.
Exercise conguration control of developmental conguration
products.
12.5 CRITICAL DESIGN REVIEW
e purpose of the Critical Design Review (CDR) is to determine if the
detailed design of the soware is correct, consistent, and complete enough
for development to continue with coding and informal testing. is tech-
nical review is held to provide a detailed basis for verifying design integ-
rity and compatibility with CSCI requirements and assessment of formal
test preparation.
12.6 JOINT TECHNICAL REVIEWS
e Joint Technical Reviews, both formal and informal, are used through-
out the program lifecycle to review and assess technical product quality and
the development progress. Table12.1 summarizes the types of technical
TABLE12.1
Joint Technical Reviews
Description Commercial Standards Soware Standards
In-process joint technical
and management reviews
of interim work products
focus on program/project’s
development status,
approach, and risks:
System Requirements
Soware Development
Documentation Status
Soware Development
Folders
Soware Coding and
Testing
System Integration and
Testing
Hierarchical soware
designs are not imposed.
Accommodates soware
design methodologies for
analysis and design.
Ordering of activities is
dependent on lifecycle
model used for
incremental and
evolutionary standards.
Soware decomposed into
soware units,” which
may or may not be related
in a hierarchical manner.
Ordering of activities is
dependent on the soware
lifecycle model used to
describe incremental and
soware standards.
Addition to that area is the
Waterfall soware lifecycle
inuence.

Get Software Engineering Reviews and Audits now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.