doc, 108kb
Upcoming SlideShare
Loading in...5
×
 

doc, 108kb

on

  • 399 views

 

Statistics

Views

Total Views
399
Views on SlideShare
399
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

doc, 108kb doc, 108kb Document Transcript

  • Critical Design Review Summary Description: The Critical Design Review (CDR) is a multi-disciplined product and process assessment to ensure that the system under review can proceed into system fabrication, demonstration, and test, and can meet the stated performance requirements within cost (program budget), schedule (program schedule), risk, and other system constraints. Generally this review assesses the system final design as captured in product specifications for each configuration item in the system (product baseline), and ensures that each product in the product baseline has been captured in the detailed design documentation. Product specifications for hardware enable the fabrication of configuration items. Product specifications for software (e.g. Software Design Documents) enable coding of a Computer Software Configuration Item (CSCI). Configuration items may consist of both hardware and software elements. For complex systems, a CDR may be conducted for each subsystem or configuration item. These incremental reviews would lead up to an overall system CDR. When incremental reviews have been conducted, the emphasis of the overall system CDR should be on configuration item functional and physical interface detail design, as well as overall system detail design requirements. CDR determines whether the hardware, human and software final detail designs are complete, and the project team is prepared to start the Execution and Build Phase. The subsystem detailed designs are evaluated to determine whether they correctly and completely implement all system requirements allocated to the subsystem, and whether the traceability of final subsystem requirements to final system detail design is maintained. At this review the project team shall also review the results of peer reviews on requirements and final detail design documentation, and ensure that latest estimates of cost (development, production, and support) are consistent with the detail design. A successful review is predicated on the project team’s determination that the subsystem requirements, subsystem detail design, results of peer reviews, and plans for testing form a satisfactory basis for proceeding into system fabrication, demonstration and test. The CDR should occur at the point in the Planning and Design Phase where the “build-to” baseline has been achieved, allowing production, and coding of software deliverables to proceed. Status: Mandatory - The Critical Design Review is the second of two critical checkpoints in the DPI System Life Cycle Framework. All system development and major application enhancement projects (including COTS integrations) must conduct a CDR to ensure that the automated system or application being designed is in conformance with ITS / DPI enterprise architecture and design standards. The actual conduct of the CDR will be somewhat dependent on the specific circumstances of the IT project. Timeframe: 1 of 11
  • The Critical Design Review is performed during the Planning and Design Phase when the System Developer has finally baselined the high-level system architectural design. Responsible Reviewing Component: The Chief Technology Office is the Technology Services (TS) component that has primary responsibility for the Critical Design Review and ensuring that the high-level system design aligns with ITS / DPI Enterprise Architecture. The NCDPI Enterprise Architect has primary responsibility for ensuring that the CDR is appropriately conducted. Primary Information Exchange Partners: The following are the primary stakeholders who participate or have an interest in the Critical Design Review: 1. System Developer 2. System Owner 3. Project Owner 4. DPI Project Manager 5. ITS Infrastructure hosting office 6. ITS Statewide Architecture office 7. DPI Enterprise Architect 8. DPI Chief Technology Officer (CTO) State Responsibilities: The DPI Project Manager is responsible for ensuring completion of the entrance requirements for the CDR. The first step is to determine the project readiness to proceed to the CDR and availability of the input documents (see below). The DPI Project Manager collaborates with the CTO in determining readiness for the CDR. The DPI Project Manager is responsible for preparing the agenda, scheduling, and facilitating / managing the CDR. If a system is being developed in-house without outside contractor resources, then the DPI developers are responsible for the contractor responsibilities described below. Representatives from the key stakeholder groups within TS are responsible for reviewing the input documents prior to the CDR and being prepared to present any critical issues during the CDR. The TS stakeholders are responsible for ensuring that assumptions, constraints, priorities, issues and risks based on their individual areas of subject matter expertise are identified and addressed during the CDR as appropriate. Within one week following the CDR, the participants and the stakeholders are to send their comments to the DPI Project Manager. The DPI Project Manager consolidates, collates, and sorts the comments by priority, area, etc. Comments regarding the CDR process should not be included in the consolidated comments. Upon completion of the CDR session(s), the DPI Project Manager is responsible for ensuring completion of the CDR Exit Criteria Checklist by all of the key TS stakeholder 2 of 11
  • groups and for tracking all critical issues to closure. The Project Manager is responsible for tracking (using the Request for Action forms) and resolution of all other actions resulting from the CDR. If appropriate, the Project Manager should offer to schedule and lead a CDR follow-up discussion between the Project Manager and the CDR stakeholders to discuss high priority comments and corrective actions. Final written responses to the comments are generally expected to be provided by the Project Manager within one week of that meeting, and shared with all of the CDR participants and stakeholders. The Project Manager is responsible for providing the completed CDR Summary Report and consolidated comments to the Chief Technology Officer, who will represent TS at the Executive Steering Committee (ESC). The Project Manager should also attend the ESC meeting to discuss the results of the CDR. The ESC will make a go / no go decision based on the recommendations provided by the CTO and the Project Manager. In cases where no ESC exists, the CTO will make the go / no go decision. Contractor Responsibilities: The following are the responsibilities that the System Developer has with regard to the CDR. If a contractor is tasked with developing the system, then these are the responsibilities of the development contractor. If the system is being developed in-house, then these are the responsibilities of the DPI developers. The System Developer who has technical knowledge of the proposed system architecture and the input documents shall: 1. Complete the CDR Entry Criteria Checklist prior to requesting a CDR. 2. Provide a high-level presentation to DPI stakeholders that addresses the following: a. Project Overview - Identification of overall project scope (includes Work Context Diagram from the Requirements Document) and schedule (includes emphasis on high-level milestones and the Release Plan if applicable); b. Design Drivers & Alternatives Considered - Identification of assumptions, constraints, priorities, key driving requirements, Preliminary Design Review Request for Actions, alternatives considered and associated limitations / advantages of each design alternative considered, which led to the proposed technical solution; c. System Architectural Design - Identification of key hardware, software (includes COTS), networking, telecommunication, and security components of the proposed system design, as well as all internal and external interfaces, and their relationships to each other depicted in a Communications Flow Diagram; d. Software Architectural Design - Identification of all Computer Software Configuration Items (CSCIs), Computer Software Components (CSCs) and Application Programming Interfaces (APIs) to include type, purpose and function for each; the interfaces, messaging, and protocols for those elements; and rationale for the software architectural design; 3 of 11
  • e. Requirements Traceability - Demonstration of backward traceability of the system and software architectural designs to the functional and nonfunctional requirements (i.e., reference Requirements Traceability Matrix provided in the System Design Document [SDD]) with focus on any requirements not met by the design; f. Data Overview - Description of data flows, data stores, data transformations and the logical and physical data models (if applicable), including identification of any privacy concerns; g. Enterprise Architecture Compliance - Identification of any deviations from or non-compliance with the State Enterprise Architecture, DPI Design Standards, and Section 508. h. Resource Sizing Estimates - Identification of anticipated number of users and their roles, and projected estimates of system resource needs for processors, memory, on-line storage, auxiliary storage, communications and network capacity; i. Risks & Mitigation Strategies - Identification of project, technical, security, and / or business risks with proposed mitigation strategies; and j. Issues - Identification of project and / or technical issues that require resolution. 3. Document the results / outputs from the CDR that are described below. Entrance Criteria / Inputs: The following artifacts, as required by the System Engineering Management Plan, are mandatory prerequisites to the Critical Design Review: 1. Business Risk Assessment. 2. Preliminary Design Review Request for Action (RFA) forms 3. Requirements Document(s) 4. System Design Description (SDD) 5. Software Requirements Specification 6. Software Design Description 7. Interface Requirements Specification 8. Interface Design Description 9. Updated version of Information Security (IS) Risk Assessment (RA) 10. Logical Data Model 11. Interface Control Document (ICD) 12. Database Design Description 13. Test Plans 14. Software Installation Plan 4 of 11
  • 15. System Security Plan (SSP) All prerequisite artifacts are to be provided to all of the CDR participants at least four weeks prior to the scheduled CDR session. Exit Criteria / Outputs: The following are the results / outputs that are to be documented from the Critical Design Review: 1. Assumptions 2. Constraints 3. Priorities 4. Issue Resolutions (if obtained, though this is not to be the focus during the CDR session; emphasis should be on identifying issues, not resolving them during the CDR session) 5. Unresolved Issues (prioritized as Critical (show-stoppers) or Non-Critical [opportunities for improvement]) 6. Risk Mitigation Strategies 7. Recommendations 8. Action Items 9. Next Steps All comments received from the CDR participants and stakeholders are to be recorded in the Request for Action form and sorted by priority. Another output of the CDR is the CDR Summary Report that document any critical issues that were identified that must be resolved before the IT project can move forward with detailed design and development activities. The CTO will sign the Report. Guidance: A best practice is to perform a Requirements Review prior to conducting a Critical Design Review. Review Process: The Project Manager has the System Developer complete the CDR Entry Criteria Checklist and then submits the completed checklist to the CTO along with the appropriate entrance artifacts. The CTO will then approve the scheduling of the CDR. The CDR will be conducted as one or more iterative review sessions attended by all of the key TS stakeholder groups, the System Developer, the Project Manager, and the System Owner. Additional participants may include ITS staff. The Project Manager and System Developer document the results / outputs of the CDR and follow-up to ensure that all actions and any unresolved issues identified during the CDR are satisfactorily addressed. The Project Manager ensures agreement of the CDR Exit Criteria Checklist by all of the key TS stakeholder groups and submits the completed checklist to the Chief Technology Officer (CTO). If an Executive Steering Committee 5 of 11
  • (ESC) exists for the IT project, then Project Manager and CTO will provide a summary of the results from the CDR along with an overall TS recommendation to the ESC in determining a go / no go decision for the IT project to continue moving forward. All "Critical" issues must be resolved before the IT project can proceed with detailed design and development activities. See CDR Process for a graphical depiction of the CDR process flow. Data Created / Modified: July 2007 Critical Design Review (CDR) Process Diagram of process 6 of 11
  • Critical Design Review Entry Criteria Checklist Satisfied Item Criteria Comments Yes / No Contract entry criteria satisfied (if 1 specified) Deliverables received sufficiently in advance of the design to permit review 2 (Typically 30 – 45 days prior to the design review) A Preliminary Design Review has been 3 successful completed. All PDR Request for Action (RFA) have 4 been responded to. All PDR Exit criteria key issues have 5 been satisfied. A review indicates the Requirements 6 Traceability Matrix (RTM) is sufficient to support the design review. A review indicates the Software 7 Requirements Specification is sufficient to support the design review. A review indicates the Interface 8 Requirements Specification is complete and under configuration management. A review indicates the Software Design 9 Description is sufficient to support the design review A review indicates the Interface Design 10 Description is sufficient to support the design review A review indicates the Database Design 11 Description is sufficient to support the design review 7 of 11
  • Satisfied Item Criteria Comments Yes / No Preliminary Test Plans for Software 12 integration and systems testing are available for review. A review indicates the Hardware Design 13 Description is sufficient to support the design review Risk assessments and risk mitigation 14 plans are formally addressed Agenda has been coordinated and 15 accepted Sponsor participation has been 16 coordinated. Technical specialists’ participation has 17 been coordinated 8 of 11
  • Critical Design Review Exit Criteria Checklist Satisfied Item Criteria Comment Yes / No Exit criteria stated in the contract has been 1 satisfied (if specified) The Requirements Traceability Matrix 2 (RTM) is acceptable The Software Requirements Specification 3 is acceptable. The Interface Requirements Specification 4 is acceptable. The Software Design Description is 5 acceptable. The Interface Design Description is 6 acceptable. The Database Design Description is 7 sufficient is acceptable. The Test Plans for Software integration 8 and systems testing are acceptable The Hardware Design Description is 9 acceptable. Risk assessments and risk mitigation plans 10 are formally addressed and are acceptable Copies of presentation materials have 11 been received. All Requests for Action (RFAs) have been 12 resolved and closed. Design review minutes have been 13 received, reviewed and are acceptable. The Design Review Chairperson has 14 released the Summary Report. 9 of 11
  • CDR Design Review Summary Report Format 1. Introduction 2. Participants 3. Entry Criteria Status 4. Design Review Results – The subparagraphs shall summarize the status of the design approach and discuss any issues or concerns. 5. Exit Criteria Status 6. Requirements to complete the CDR 7. Conclusion Signature of the DPI CTO 10 of 11
  • DESIGN REVIEW REQUEST FOR ACTION (RFA) PROJECT NAME: CONTRACTOR / VENDOR NAME: TYPE OF REVIEW: SUBJECT: ITEM NUMBER: ACTION (Include specific requirement) / INFORMATION REQUIRED ORIGINATOR’S NAME: ORGANIZATION: E-MAIL: PHONE: FAX: ACTION ASSIGNED: PRIORITY: SUSPENSE DATE: DISPOSITION: ACTION CLEARED CONTRACTOR SIGNATURE:__________________________ DATE:__________ STATE SIGNATURE:__________________________________DATE:__________ 11 of 11