Distributed Application Critical Design Review (CDR) Checklist

Distributed Application
Critical Design Review (CDR) Checklist
Confidentiality Statement
This <document title> along with all attachments hereto shall be considered <company>’s Proprietary/Confidential Information
gantthead.com Distributed Application Critical Design Review (CDR) Checklist
Evaluate the software system design according to the items in this Review Checklist. All items must be evaluated according
to whether they meet requirements or will otherwise ensure acceptable functionality of system, with ratings being (a)
satisfactory, (b) passable with modification recommended, or (c) in critical need of modification. Check the appropriate box
for each item. All items should be treated as points for discussion leading to an evaluation and do not require explicit
answers in the Comments field. Items may be skipped or deemed N/A at the discretion of the Review Team.
The design must pass this Review and formal approval must be obtained before full-scale development of the system can
proceed.
System Name/ID:
Date of CDR:
CDR Participants:
Position Name E-mail

Project Manager
Executive Sponsor
Business System
Architecture Team Lead
Technical Architecture
Team Lead
Application Development
Team Lead
Business Analyst Team
Lead
Database Administrator
Business Area
Representative
©2007 gantthead.com 2
Section 1: Overall Application

Review Satisfactory Non-Critical – Critical – Comments
Item Modification Needs
Recommended Modification
How well is the
business solution
implemented by
the design?
Has the design
evolved
according to
requirements?
Overall high-
level architecture
design
Are there/have
there been
demonstrable
design
prototypes?
Section 2: Performance, Scalability, and Availability

Transaction
processing
architecture
Load balancing
across servers
Points of failure
and
backup/recovery
procedures
Prevention of
bottlenecks in the
architecture
How will the
system perform
for the expected
volume of total
users?
Is there adequate
capacity for the
expected volume
of concurrent
users?
Is the system
capable of
accommodating
user volume
growth over time?
Security
Single logon
support

Access to
intersystem
passwords
Are restrictions
on data supported
at required levels
of granularity
(table level,
system level, row
level and/or
object level)?
Will users always
have access to
their own data?
Are security
groups
supported? What
privileges do they
have? How are
they created and
administered?
Encryption
mechanisms
Is there a way to
pass credentials
between
components or
layers of the
architecture?
How secure is
user account
information?
Section 3: Application Development

Is a non-
proprietary or
mainstream
programming
language used?
What is the
runtime
environment?
Are there multiple
client platforms?
Are they
homogeneous?
Do special
interfaces need to
be built? Are
there multiple
types of
components
supported?
How is
configuration
management
addressed? Is
there a code
repository?
Are debuggers
available?

Do developers
need to modify
external system
components?
Will
modifications be
tracked and
documented?
Are there custom
API's? How do
they integrate into
the architecture?
Are business rules
external to the
architecture? Is
there a rules
engine?
Are the
constituent
program modules
designed with
consistency?
Are program
module
boundaries well
defined?
Does the design
have low
complexity?
Will the software
be maintainable?

Is each module
designed to be
minimally
impacted by
changes in other
modules?
Is the design
lean? Are all of
its parts strictly
necessary?
Section 4: Object and Information Management

How are objects
stored?
What DBMS's or
ODBMS's are
used?
How are objects
accessed?
What
mechanisms are
there for purging/
archiving/
restoring data and
objects?
How are
persistent objects
implemented?
What
mechanisms
handle updates,
performance
monitoring,
currency control
and locking?
How are business
transactions
implemented on
the persistent
objects?

Is object locking
optimistic,
pessimistic or
neither?
What data
structures are
used to represent
objects?
Can you add or
extend business
objects of the
architecture?
Can you include
external data
objects?
Is the database
documented using
a data model,
object model, or
neither?
Are tables used to
represent objects?
What non-object
data is stored in
the database?
How do you
access and update
the host data?
Are there risks
involved with
updates?

Is there a data
conversion
needed? Is there
any planning for
it?
Section 5: Communication
What networking
protocols are
supported?
Is there support
for remote users?
Is there support
for Internet
access?
Section 6: Operations, Administration and Maintenance (O, A & M)

Is vendor support
provided for the
databases,
components,
client software
and server
software?
How are new
releases
maintained/suppo
rted?
How are releases
tested?
How are releases
moved into
production?
Can a release be
aborted if
necessary?
Are multiple
databases needed
for test
environments?
Is it possible to
replicate the
production
environment in a
testing
environment?
Is it possible to
make individual
code changes?
Will users be
negatively
impacted by new
releases?
Are there
dependencies
between
components of
the architecture
that affect new
releases?
Is it possible to
troubleshoot an
error?
How are user
errors reported?
Are system errors
logged to a
central
repository?
Is there a
mechanism for
certifying the
finished
application?
Is there a batch
component to the
environment?
Are the batch
procedures
documented?
Section 7: User Interface

Overall quality of
usability features:
intuitiveness,
consistency,
online help,
integration with
windowing
system, skill level
adaptability
Is the screen
navigation
documented?
Is user session
context saved
between sessions?
Do online
transactions map
to logical units of
work committed
on the database?
Is the screen flow
controlled by the
user rather than
the system?
Are error
condition
messages
informative?
Can the interface
be customized by
users?
Section 8: Integration with Other Business Systems

With what other
systems does this
architecture
integrate?
Are integration
adapters needed?
How is
communication
with external
systems
achieved?
Can external
systems access
this system?
Will changes in
external systems
affect this
system?
Does this system
accommodate
external systems
when those
systems are
down?
Section 9: Approval/Rejection of Design

______ The [SYSTEM NAME/ID] has passed this Critical Design Review. It is approved for Development.
______ The [SYSTEM NAME/ID] has not passed this Critical Design Review. It is not approved for Development.
The following Issues must be resolved:
Additional Recommendations:
Signature of Executive Sponsor or Sponsor Representative

Distributed Application Critical Design Review (CDR) Checklist

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

Distributed Application Critical Design Review (CDR) Checklist

Uploaded by

Copyright:

Available Formats

Distributed Application

Critical Design Review (CDR) Checklist

Position Name E-mail

Section 1: Overall Application

Section 2: Performance, Scalability, and Availability

Review Satisfactory Non-Critical – Critical – Comments

Section 3: Application Development

Review Satisfactory Non-Critical – Critical – Comments

Review Satisfactory Non-Critical – Critical – Comments

Section 4: Object and Information Management

Review Satisfactory Non-Critical – Critical – Comments

Review Satisfactory Non-Critical – Critical – Comments

Section 6: Operations, Administration and Maintenance (O, A & M)

Section 7: User Interface

Section 8: Integration with Other Business Systems

Section 9: Approval/Rejection of Design

The following Issues must be resolved:

Signature of Executive Sponsor or Sponsor Representative

You might also like