P17705: Goodbye, Goodbuy! Process Improvement
/public/

Preliminary Detailed Design

Table of Contents

Your website should document your journey through MSD, so include work-in-progress as well as latest results. Use pdf's for display whenever possible so that information is easily viewable without the need to download files and open applications. (Your EDGE file repository should still contain original editable files).

Content related to this node should go in the Detailed Design Documents directory unless you have made other arrangements with your guide ahead of time.

All template text must be removed prior to your Preliminary Detailed Design Review

Team Vision for Preliminary Detailed Design Phase

Summarize:

Prototyping, Engineering Analysis, Simulation

Iterative activities to demonstrate feasibility, including assumptions you made in your analyses or simulations. Have you completed sufficient analysis to ensure that your design will satisfy requirements? Have you included all usage scenarios in your modeling?

Feasibility: Prototyping, Analysis, Simulation

Between now and the end of the semester, your team will continue to add detail to your design, which will require more detailed analysis and prototyping to answer feasibility questions. Consider:

Purpose

  1. Confirm that the selected concepts can deliver functionality defined by the System Architecture.
  2. Define the optimal values of the most sensitive design parameters.
  3. Support the evaluation of your team's concepts with quantitative information.
  4. Make decisions about design drivers.

Instructions

  1. Instructions and EXAMPLE must be deleted before the Preliminary Detailed Design Review AND Identify an owner for this document.
  2. This document will be inspected at all project reviews during MSD1.
  3. At the subsystem design level, feasibility analysis and prototyping may still be relatively coarse. First order analysis, estimation, and rough physical mockups are to be expected. Detailed analysis on critical subsystems or components may be complete.
  4. Select the concepts that are expected to be most sensitive and/or problematic. These are usually concepts that will not be satisfied by COTS components.
  5. Define the transfer function that converts the concept/subsystem inputs into the desired outputs as a function of specific design parameters. This can be done via theoretical analysis or empirical prototyping. it is often useful for two or more team members to work together so that the work is checked and a clear understanding of these models is captured. Get help here from SMEs who should be able to alert your team to potential difficulties and possible solutions.
  6. Use the models to quantitatively specify the design parameter targets and acceptable ranges.
  7. Confirm that the concepts selected and the designs anticipated will generate the desired performance.
  8. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

  1. Engineering Requirements
  2. Concept Selection
  3. Results of preliminary prototyping, analysis, and simulation

Outputs and Destination

  1. A list of Design Parameters, Quantified Targets, and acceptable tolerances
  2. Sensitivity analysis
  3. Refined concept Selection
  4. Drawings, Schematics, Flow Charts, etc.

Drawings, Schematics, Flow Charts, Simulations

Your team should have completed a significant portion of your detailed design, but it will likely require revision based on feedback at your design review.

Purpose

Define instructions that will enable fabrication of the elements required to build and operate the entire system.

Instructions

  1. Instructions and EXAMPLE must be deleted before the Detailed Design Review AND Identify an owner for this document.
  2. This document will be inspected at all project reviews until the system is assembled and debugged.
  3. Define all geometries of interfaced subsystems
  4. Define detailed fabrication instructions for all unique parts.
  5. Call out all purchased parts
  6. Develop a software design that reflects operating flow charts and timing diagrams
  7. Adhere to all required design standards.
  8. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Input and Source

  1. Selected Concepts
  2. Feasibility Models
  3. System design and interface definitions

Output and Destination

  1. Complete hierarchy of design files from system level down to components
  2. Parts list
  3. Software design that specifies coding requirements
  4. Test plans, including expected performance vs. requirement and any applicable test standards (e.g., ASTM)

Bill of Material (BOM)

Purpose

Confirm that all expenses and contingencies are afforded by the project financial allocation

Instructions

  1. Instructions and EXAMPLE must be deleted before the first Detailed Design Review AND Identify an owner for this document.
  2. This document will be inspected at all project reviews until the system is assembled and debugged.
  3. Define all components to be fabricated or purchased.
  4. Define all other purchases to enable completion of the project, including operating supplies, with contingencies.
  5. Complete BoM template.
  6. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Input and Source

  1. PRP.
  2. Design Files.

Output and Destination

Completed BoM and Budget

Test Plans

Purpose

Demonstrate objectively the degree to which the Engineering Requirements are satisfied

Instructions

  1. Complete test plans specifying the data to be collected, instrumentation to be used, testing procedures and personnel who will conduct the tests.
  2. Plans should use data collected to define the accuracy of models generated during feasibility analysis.
  3. If your team's testing will involve human subjects, you must review the RIT Human Subjects Research Office "Protecting Human Subjects" page for details on securing approval for work with human subjects

Inputs and Source

  1. Engineering Requirements
  2. Feasibility Models
  3. Test standards (e.g., ASTM). The RIT library maintains an infoguide with links to standards databases, many of which provide industry-standard test procedures for a variety of components and systems.

Outputs and Destination

  1. Report that summarized the degree to which Eng Reqs are satisfied.
  2. Assessment of accuracy of feasibility models.
  3. IRB Submission, if applicable (allow at least 30 days for this to be reviewed - more time is idea, since the IRB outcome may be a request for you to modify your proposed test protocol)

Design and Flowcharts

This section should continue to be updated from your systems level design documentation.

Risk Assessment

Design Review Materials

Include links to:

It is appropriate for you to send your customer and guide a link to this page in preparation for the review. This will ensure that they know what you will be presenting and how to view all of your work. Any EDGE link should start with http://edge.rit.edu/edge/P1xxxx..... Using "http" instead of "https" will ensure that non-RIT stakeholders can view the content without being prompted for a DCE login and password.

Plans for next phase


Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Integrated System Build & Test with Customer Demo | Customer Handoff & Final Project Documentation