Software PDR Moodle Samples Review

Preliminary Design Review (PDR) Data Package Hand-in Submission HARDCOPY of Data Package for the PDR Pages: 10-15; A4 size Choice of software: any Content: format-arranged (example: power point)

Introduction PDR PDR: formal technical review Basic design approach to the computer software Big meeting held o After accomplishing the preliminary design efforts, and o The software top-level design specification (architectural design spec.) is written, o But prior to the start of detailed design.

Introduction - During PDR Principal software designer/manager gives a concise presentation of: a) What does he/she understand about the requirements of the system to be designed i.e. (the problem) b) How will he/she design the software to meet the requirements i.e. (the solution) Top-level design (e.g. the software structure) is presented to audiences consisting of o Both in-house, and o Customer management/engineering personnel.

The presentation - a "Data Package" Data package should be prepared for presentation in the review Usually the data package or a collection of data packages o (large software systems could involve several design groups each of them presents their own PDR data package) Format: usually a book is delivered to the customer o 2 weeks before the meeting o To allow for time to read it and prepare questions for the meeting.

Content of the data package Data package should contain the following sections: 1. Requirements i. Software run-time environment requirements ii. Software operational requirements: a) Functional requirements

2.

3.

4.

5.

6.

7.

8.

9.

b) Program and memory size requirements c) System timing requirements d) Other quantitative requirements, if any (E.g. reliability, fault detection and isolation, false alarm rate, etc.) Design Approach i. Architectural design approach used ii. Software structure/software tree iii. Main program control flow iv. Major subprogram control flow v. Special algorithm processing chart Data Base Design i. Sketches of data base structures (e.g. major tables, queues, lists, etc.) ii. Sketches of output formats (e.g. message format, fault reporting format, etc.) iii. Label naming conventions Estimations of design i. Program and memory size estimation ii. Processing time estimation iii. Other quantitative estimation, if any (design estimates that meet other quantitat ive requirements as listed in 1(ii)(d) above) Development Support Software (if any) List support software which require considerable effort to create (those that have impact on project cost and completion schedule): i. Dummy operating system (executive) ii. Test drivers and stubs iii. Simulators, etc. Software Documentation and Deliverables i. List of deliverable software packages ii. List of deliverable documentation Software Development Environment/Facilities i. Hardware facilities ii. Software tools Software development risk area (if any) i. Risk due to target hardware (availability, system limitations, etc., classify to high/moderate risks) ii. Risk due to development facilities (availability, familiarity/learning curve, etc., state high/low risks) iii. Risk due to other causes (personnel skills, contractual restrictions, etc., state high/moderate risks) Software Schedule Using a chart (e.g. Gantt chart) to show: i. Major milestones ii. Major task design/code/test schedule iii. Documentation completion date iv. Hardware/software inter-dependency v. Current project progress/status

The End