Capstone Project Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
=====System Refinement Review and Final Design Report=====
<-subsystem_engineering_review|Subsystem Engineering Review^.:home|Design Reviews^Project Success Agreement->

System Refinement approval is granted when the desirability and transferability of
the design meet the minimum requirements for the end of System Refinement. The purpose of the System Refinement review is to answer the questions, “What is the complete system design?” and, “How well does the system meet the Key Success Measures and other requirements?” In preparation for the System Refinement review, the team will submit a draft of the Final Design Report. The
desirability and transferability are evaluated by a careful review of the draft
submitted by the team, followed by the System Refinement design review. After the review, the team will revise the Final Design Report and submit the final version by the due date listed in Learning Suite.

At the review, the team will give a short presentation that includes
the Project Objective Statement and a summary of the full system design and its evaluation.
Following the presentation, the reviewers and the team will discuss the desirability and
transferability of the design.  Suggestions for improvement will be considered.
The objective of the review is to strengthen the design by finding and making plans to
remove any weaknesses present.

The Report and the review should demonstrate that the design has evolved
enough to meet the requirements for the end of System Refinement.  The
artifacts should address the issues listed below.  Satisfactorily
addressing these issues constitute the minimum requirements for completion of
System Refinement.

The final submission of the Final Design Report should explicitly
reflect feedback given by the sponsor after the Final Design Presentation.

You should deliver the final version of the Final Design Report to your sponsor in PDF form and/or
printed form, as desired by your sponsor.  Ask them what they would like.  If
they would like a printed version, use your CAEDM group account to print it, and
use the spiral binding system in the Capstone office to bind the report.

NOTE: No reimbursements will be given for printing or binding charges.  You should use
CAEDM and the Capstone office to accomplish these functions.

See [[..:assignments:winter:checkout_clearance|Checkout Clearance]] for information on the printed documents
that are required for checkout.

==== Final Design Report ====

The purpose of the Final Design Report is to answer the questions, “What is the complete system design?” and, “How well does the system meet the Key Success Measures and other requirements?” The Final Design Report is a single PDF compilation containing the following:
  - A Final Design Report title page
  - A Table of Contents listing the Executive Summary and all of the included artifacts, but with no page numbers for the artifacts. The PDF compilation must have bookmarks for each of the Table of Contents entries.  See Formatting for an easy way to make these bookmarks. Individual artifacts should have page numbers. The page numbering of each artifact should start at 1.
  - The Executive Summary.  See the next section for more information.
  - PDF copies of each of the Primary Artifacts, as listed below.  Primary artifacts need not contain all of the details needed to reproduce the work, but should cite Supporting Artifacts that do contain these details.
  - PDF copies of each of the Supporting Artifacts for the review, as listed under the review questions. Supporting Artifacts will be evaluated by the graders only when they have questions they would like to answer.

All PDF files included in the package must be searchable for text, meaning they must not be scanned documents

The artifacts in the Final Design Report should be thoughtfully arranged in order to facilitate rapid access and understanding.

The Final Report should contain every artifact necessary to understand your project. It is expected that most of the artifacts previously submitted for the Subsystem Engineering Review
will be included in the Final Design Report for your Project.
The artifacts should be updated to reflect the current state of the design.

New writing for the Final Design Report will focus on the Executive Summary, the Written and Visual Description of the Design, and the Performance Summary for the system.

In previous years, a signature page was required with signatures of each team member. That document is no longer required.
==== Executive Summary ====


The Executive Summary is a two-page summary of the results of your
design work.  In addition to text, the summary may contain a few key
figures and/or tables that best show your work.  Detailed figures and tables
should be in the individual artifacts.

The primary audience for the Executive Summary is the management team for the sponsor.
It is not the liaison for your project; it is the managers of your liaison.
The Executive Summary should stand on its own and inform the management team of the
progress on your project, without reading any of the artifacts.  However, it should
be consistent with the artifacts and make it easy for management to know which
artifacts to peruse to get more information. Because it is so short, you should be concise and clear. Carefully consider what the target audience will want to know, and present that information as clearly as possible.

The Executive Summary should summarize the following topics:

  * //Introduction:// Appropriate (brief) background of the project.  Indicate why the project is important.  Share your project objective statement. Indicate the key success measures for the project.
  * //Brief description of design://  Briefly describe the design in words and with appropriate top-level pictures.  The description should not be a detailed definition.  The detailed definition is found in the artifacts.  The description should provide an overview of the design that will make it easy for the reader to understand the details found in the artifacts.  Refer to appropriate design artifacts as needed.
  * //Summary of final performance:// Summarize how well the design has been demonstrated to perform, compared with the key success measures and perhaps other important requirements.  Summarize available market response data. Summarize the kind of tests that were performed with prototypes or engineering models to measure or predict the performance. Refer to appropriate testing and analysis artifacts as needed.
  * //Conclusion and recommendations: // Holistically evaluate the desirability of the design based on the evidence present in the Executive Summary and the artifacts. Make recommendations for resolving any issues that have shown up in your testing. Discuss the next steps that the sponsor should take to move the product forward to release.

==== Artifacts to include in the report ====

The artifacts and the review should answer the questions, "What is the complete system design?" and, "How well does the system meet the Key Success Measures and other requirements?"  Satisfactory answers to these questions constitute the minimum requirements for completion of System Refinement.

=== Primary Artifacts ===
      * Written and visual description of design, including relevant subsystems and/or block diagrams.  Note this is a high-level, rather than detailed, artifact. It is more likely to contain renderings or flowcharts than engineering drawings.
      * Performance summary for the system, which refers to supporting artifacts as needed
      * System requirements matrix or Software Requirements Specification. For a System requirements matrix, include measured and/or predicted values for performance measures (refer to supporting artifacts as needed) and values for the market response (refer to supporting artifacts as needed)

=== Supporting Artifacts ===
      * System Design Package (including refined Bill of Materials and/or Software Bill of Materials).  Pay close attention to the details described on [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=111|pages 98 -- 100]] of [[https://byucapstone.byu.edu/mattson-sorensen.pdf|Product Development]].  This package should be complete and detailed enough that an independent production system could produce your design.
      * Up-to-date approved PSA, revised as necessary
      * Test results obtained using models and/or prototypes. Pay special attention to Figure 1 ([[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=44|Figure 2.12]] in the textbook) as you consider the test results needed.  Note that you will need validation testing (not just performance testing) for System Refinement approval. (Validation testing refers to the response to your product you obtain from market representatives, which may include your sponsor.)
      * Definitions of models and/or prototypes used in testing
      * Test procedures that were used to obtain the results listed above
      * Computer files used in the testing work
      * Other detailed artifacts that support assessing the performance of the system

[{{ project-wiki:design_reviews:approval.png | Figure 1: The stage approval process.  Performance testing and artifact checking are always done as part of approval.  Validation is always done at System Refinement and is often done at Concept Development (the Architecture Review). Validation is often not done at Subsystem Engineering, because the subsystem prototypes are not usually accessible for the market to evaluate.}}]


==== Evaluation Rubrics ====


The Final Design Report will be reviewed for how clearly and completely it answers the questions above (evaluation of
transferability).  The system design and tests presented in the Report will also be reviewed for their quality.

The rubrics used in the evaluation is shown below.  There are different rubrics for hardware or mixed projects and software projects.  Discuss with your pod instructor which rubrics you will use.

The scoresheets used by the evaluators are available on Box for [[https://byu.app.box.com/file/1271492699941|hardware or mixed projects]] and for [[https://byu.app.box.com/file/1271492411710|software projects]]. 


**Evaluation rubric for Final Design Report**
^Element ^ Item(weight) ^ Excellent (9-10) ^ Good (7-8) ^ Poor (0-6) ^
|::: ^<html><small>Project Success (3)</small></html> |<html><small>The reviewer's independent assessment of the product performance based on the Key Success Measures and the other performance measures in the PSA. The reviewer makes a best judgement of how well he or she believes the team has succeeded in meeting their desirability goals. The team provides their assessment of the expected performance in the Executive Summary. Your assessment should range from 0 to 10. </small></html> |<html><small>Reviewer believes project meets most Key Success Measures and other target values. </small></html> |<html><small>Reviewer believes project fails to meet significant Key Success Measures and other target values. </small></html> |
|Executive Summary ^<html><small>Completeness (0.5)</small></html> |<html><small> Contains all of the following topics, and they are thoughtfully and carefully presented: Title page, Introduction, Description of Design, Summary of Performance, Conclusion and Recommendations.  Stays within two-page length. </small></html> |<html><small> Contains most of the required items.  Some required items are missing or are of low quality.  Summary is 3 or 4 pages. </small></html> |<html><small> There are multiple missing items, or the items are haphazardly prepared and/or presented.  As presented, the Executive Summary appears to have little value to the team or the sponsor. Summary is 5 pages or more. </small></html> |
|::: ^<html><small>Summary of Performance (0.5)</small></html> |<html><small> Briefly and clearly summarizes the overall system performance.  Evidence of performance in the form of artifacts is referenced.  Has summary tables and/or figures copied from the primary artifacts as appropriate.  Performance is reported for all Key Success Measures and other target values.  </small></html> |<html><small> Summarizes the overall system performance.  Some evidence of performance in the form of artifacts is referenced.  Performance is reported for most Key Success Measures and other target values.  </small></html> |<html><small> Performance is poorly summarized.  Evidence for performance is missing.  Performance is not reported for Key Success Measures and other target values. </small></html> |
|::: ^<html><small>Conclusion and Recommendations (0.5)</small></html> |<html><small> Provides thoughtful and effective holistic desirability evaluation of the design.  Clearly identifies issues that need resolving.  Provides effective recommendations for resolving these issues. </small></html> |<html><small> Provides superficial holistic desirability evaluation.  Somewhat identifies issues.  Provides recommendations for resolving issues. </small></html> |<html><small> Missing or implausible holistic desirability evaluation.  Ignores or minimimizes issues that need resolving.  Recommendations are missing or ineffective. </small></html> |
|Primary Artifacts -- reviewers evaluate all ^<html><small>Written and visual description of the design (0.75)</small></html> |<html><small> Uses both words and images to clearly describe the design.  Defines the principal components and subsystems.  Provides an excellent introduction to the design as defined in the System Design Package.  Work is of high quality.  Properly under revision control. </small></html> |<html><small> Uses primarily words or images to define the design, with some lack of clarity.  Mentions the principal components and subsystems.  Provides somewhat of an introduction to the design as defined in the System Design Package.  Work is of acceptable quality.  Under revision control </small></html> |<html><small> Description of design is unclear.  Principal components and subsystems are poorly mentioned or missing. Poorly introduces the design defined in the System Design Package.    Work is of poor quality.  Not under revision control. </small></html> |
|::: ^<html><small>Performance summary for the system (0.75)</small></html> |<html><small> System performance is indicated for all Key Success Measures and for most performance measures.  Measurements and predictions have evidence in the form of artifacts.  The stated performance is consistent with target values.  Effectively under revision control. </small></html> |<html><small> System performance is indicated for all Key Success Measures and a few other performance measures.  Some evidence in the form of artifacts is provided for the stated performance.  Performance is close to target values.  Somewhat under revision control. </small></html> |<html><small> Little or no system performance is indicated.  Performance is asserted; little or no evidence supports the assertions.  Target values not met.  Not under revision control.   </small></html> |
|::: ^<html><small>System Requirements Matrix, including predicted values for system performance measures (0.5)</small></html> |<html><small> Matrix adds Measured Values to the values from Subsystem Engineering.  Matrix adds Market Response values (with supporting information for these values in supporting artifacts).  Meets all of the criteria for the requirements matrix information found in Table 7.1 or Table A.5 of the textbook. Matrix is under effective revision control.  If an alternative requirement specification is used, the measured system performance relative to the requirements is clearly included. </small></html> |<html><small> Matrix is mostly well done, but falls short of the listed criteria in one or two areas.  Measurements, Predictions, and/or Market Response appear superficial.  Revision control is superficial. </small></html> |<html><small> Matrix has some serious weaknesses that raise questions about its utility. Measurements, predictions, and market response are unbelievable or missing.  Not under revision control.   </small></html> |
|Supporting Artifacts -- reviewers spot check.  Most supporting artifacts will have been created previously, were reviewed as part of Subsystem Engineering, and are included for completeness. ^<html><small>System Design Package, including (at a minimum)  a BOM, system and subsystem assembly drawings, part drawings, and interface definitions. (1)</small></html> |<html><small> Drawing package is complete.  Bill of Materials is complete.  All custom parts have drawings.  All necessary logic, flow, block, wiring, and schematic diagrams are included.  Drawings follow approprite standards.  Drawings have been checked by someone other than the creator.  The entire system is specified. Software organization is clear and effective, and follows the guidelines in the Design Artifacts section of the Student Book.   Drawing package is under effective revision control. </small></html> |<html><small> Drawing package is mostly complete.  Bill of Materials is mostly complete.  Most custom parts have drawings.  Non-geometric drawings are mostly present.  Appropriate standards are mostly followed.  Drawing checking appears to have been somewhat superficial.  Key subsystems are specified.  Software organization is defined, and mostly follows the guidelines.  Revision control is superficial. </small></html> |<html><small>  Drawing package is substantially incomplete.  Many necessary drawings are missing.  Standards are followed poorly or ignored. Checking is minimal or nonexistent.   Software organization is not defined, or does not follow the guidelines. Not under revision control. </small></html> |
|::: ^<html><small>Test methods and results (0.45)</small></html> |<html><small>Test methods and results are included that demonstrate the system performance.  These artifacts typically include:<br>* Test results obtained using models and/or prototypes<br>* Test procedures used to obtain results in Primary Artifacts<br>* Computer files used in testing work<br>* Market response testing/evaluation work<br>Necessary artifacts are all included.  <br> </small></html> |<html><small> Most necessary artifacts are included.  One or two things the reviewer felt should be included are missing.   </small></html> |<html><small>  The testing artifacts are incomplete.  There are not enough supporting artifacts to support stage approval.   </small></html> |
|::: ^<html><small>Other supporting artifacts (0.3)</small></html> |<html><small> All other necessary supporting artifacts are included.  There is nothing the reviewer felt should be included that is missing.  For the Final Design Report, likely supporting  artifacts include<br>* Up-to-date Project Success Agreement<br>* Definitions of models and/or prototypes<br>* Vendor datasheets for off-the-shelf parts<br>* Other detailed artifacts that support your evaluation of the performance of the system<br> </small></html> |<html><small> Most necessary artifacts are included.  One or two things the reviewer felt should be included are missing. </small></html> |<html><small>  The secondary artifacts are incomplete.  There are not enough supporting artifacts to support approval. </small></html> |
|::: ^<html><small>Transferability (0.75)</small></html> |<html><small> The supporting artifacts are clearly written, and allow the reader to create the system, replicate a test and/or use a prototype to repeat the work.  The supporting artifacts have appropriate mechanics and are properly under revision control. </small></html> |<html><small> The supporting artifacts are somewhat clear.  They provide enough guidance to allow the reader to apply engineering judgment to create a subsystem, replicate a test and/or use a prototype to repeat the work.  The supporting artifacts have acceptable mechanics; the revision control is superficial. </small></html> |<html><small> Supporting artifacts are unclear and/or otherwise difficult to understand.  They provide insufficient information to allow the reader to create a subsystem, replicate a test, and/or use a prototype to repeat the work.  The artifact mechanics are unacceptable.  Revision control is missing. </small></html> |
|::: ^<html><small>Quality (0.5)</small></html> |<html><small> The supporting artifacts reflect thoughtful, appropriate engineering practice.  The correct activities were performed and properly reported in order to support approval.  The reviewer is confident in the information provided to support approval. </small></html> |<html><small> The supporting artifacts reflect engineering practice.  Some of the correct activities were performed and properly reported.  There is some data supporting approval, but it is not thorough or complete.  The reviewer may have some questions about the information provided to support approval. </small></html> |<html><small> The supporting artifacts reflect poor engineering practice.  There is missing evidence for some expected activities.  With the existing artifacts, the reviewer has insufficient information to make an informed judgment to approve stage completion. </small></html> |
| ^<html><small>Formatting (0.5)</small></html> |<html><small> Complies with all formatting requirements in the Capstone Wiki and is carefully and thoughtfully formatted.  Bookmarks and/or hyperlinks are provided to help the reader navigate the document. </small></html> |<html><small> Mostly complies with formatting requirements.  One or two documents need to be fixed to comply with formatting requirements </small></html> |<html><small> Shows little or no evidence of following formatting requirements.  Haphazard formatting, difficult to read.  </small></html> |
|<html><small>Rubric revision 1.6 made from ScoreSheetMaker revision 1.5</small></html>|||||






**Evaluation rubric for Final Design Report on Software Projects**
^Element ^ Item(weight) ^ Excellent (9-10) ^ Good (7-8) ^ Poor (0-6) ^
|::: ^<html><small>Project Success (3)</small></html> |<html><small>The reviewer's independent assessment of the product performance based on the Key Success Measures and the other performance measures in the PSA.  The reviewer makes a best judgement of how well he or she believes the team has succeeded in meeting their desirability goals.  The team provides their assessment of the expected performance in the Executive Summary. Your assessment should range from 0 to 10. </small></html> |<html><small> </small></html> |<html><small> </small></html> |
|Executive Summary ^<html><small>Completeness (0.5)</small></html> |<html><small> Contains all of the following topics, and they are thoughtfully and carefully presented: Title page, Introduction, Description of Design, Summary of Performance, Conclusion and Recommendations.  Stays within two-page length. </small></html> |<html><small> Contains most of the required items.  Some required items are missing or are of low quality.  Summary is 3 or 4 pages. </small></html> |<html><small> There are multiple missing items, or the items are haphazardly prepared and/or presented.  As presented, the Executive Summary appears to have little value to the team or the sponsor. Summary is 5 pages or more. </small></html> |
|::: ^<html><small>Summary of Performance (0.5)</small></html> |<html><small> Briefly and clearly summarizes the overall system performance.  Evidence of performance in the form of artifacts is referenced.  Has summary tables and/or figures copied from the primary artifacts as appropriate.  Performance meets all Key Success Measures and other target values.  </small></html> |<html><small> Summarizes the overall system performance.  Some evidence of performance in the form of artifacts is referenced.  Performance meets most Key Success Measures and other target values.  </small></html> |<html><small> Performance is poorly summarized.  Evidence for performance is missing.  Performance fails to meet Key Success Measures and other target values. </small></html> |
|::: ^<html><small>Conclusion and Recommendations (0.5)</small></html> |<html><small> Provides thoughtful and effective holistic desirability evaluation of the design.  Clearly identifies issues that need resolving.  Provides effective recommendations for resolving these issues. </small></html> |<html><small> Provides superficial holistic desirability evaluation.  Somewhat identifies issues.  Provides recommendations for resolving issues. </small></html> |<html><small> Missing or implausible holistic desirability evaluation.  Ignores or minimimizes issues that need resolving.  Recommendations are missing or ineffective. </small></html> |
|Primary Artifacts -- reviewers evaluate all ^<html><small>Written and visual description of the design (0.75)</small></html> |<html><small> Uses both words and images to clearly describe the design.  Defines the principal components and subsystems.  Provides an excellent introduction to the design as defined in the System Design Package.  Work is of high quality.  Properly under revision control. </small></html> |<html><small> Uses primarily words or images to define the design, with some lack of clarity.  Mentions the principal components and subsystems.  Provides somewhat of an introduction to the design as defined in the System Design Package.  Work is of acceptable quality.  Under revision control </small></html> |<html><small> Description of design is unclear.  Principal components and subsystems are poorly mentioned or missing. Poorly introduces the design defined in the System Design Package.    Work is of poor quality.  Not under revision control. </small></html> |
|::: ^<html><small>Performance summary for the system (0.75)</small></html> |<html><small> System performance is indicated for all Key Success Measures and for most performance measures.  Market response to the system is indicated.  Measurements and predictions have evidence in the form of artifacts.  The stated performance is consistent with target values.  Effectively under revision control. </small></html> |<html><small> System performance is indicated for all Key Success Measures and a few other performance measures.  Some market response values are shown.  Some evidence in the form of artifacts is provided for the stated performance.  Performance is close to target values.  Somewhat under revision control. </small></html> |<html><small> Little or no system performance is indicated.  Little or no market response is indicated.  Performance is asserted; little or no evidence supports the assertions.  Target values not met.  Not under revision control.   </small></html> |
|::: ^<html><small>Software Requirements Specification (0.5)</small></html> |<html><small> SRS is thorough and clear. All dependencies and interfaces are clearly defined. Features are clearly explained and understandable. Technical terms specific to the project (those that are not everyday language for those familiar with software design) are defined in the Glossary section.  </small></html> |<html><small> SRS is mostly well done, but falls short of the listed criteria in one or two areas.  Some parts appear superficial.  Revision control is superficial. </small></html> |<html><small> SRS has some serious weaknesses that raise questions about its utility. Some parts are unbelievable or missing.  Not under revision control.   </small></html> |
|Supporting Artifacts -- reviewers spot check.  Most supporting artifacts will have been created previously, were reviewed as part of Subsystem Engineering, and are included for completeness. ^<html><small>System Design Package, including System Design Package, including (at a minimum) a SBOM, diagrams, code documentation,  interface definitions, test procedures, and test results. (1)</small></html> |<html><small>Software Bill of Materials is complete. All necessary logic, flow, block, wiring, and schematic diagrams are included. Interfaces are clearly defined. Software organization is clear. Software code is well-commented and easily transferable. Artifacts are under effective revision control. </small></html> |<html><small>Software Bill of Materials is mostly complete. All necessary logic, flow, block, wiring, and schematic diagrams are included but leave a few questions. Interfaces are clearly defined. Software organization is mostly clear. Code might be slightly difficult to follow but could be figured out in minimal time. Artifacts are mostly under effective revision control. </small></html> |<html><small>Software Bill of Materials is clearing lacking pieces. Logic, flow, block, wiring, and schematic diagrams are missing or of poor quality. Interfaces are not clearly defined. Software is poorly organized. Code is difficult to follow and lacking useful comments. Artifacts are not under effective revision control. </small></html> |
|::: ^<html><small>Completeness (0.75)</small></html> |<html><small> All necessary supporting artifacts are included.  There is nothing the reviewer felt should be included that is missing.  For the Final Design Report, likely supporting  artifacts include<br>* Up-to-date Project Success Agreement            * Test procedures<br>* Test results <br>* Definitions of models and/or prototypes<br>* Computer files used in testing work<br>* Other detailed artifacts that support your evaluation of the performance of the system </small></html> |<html><small> Most necessary artifacts are included.  One or two things the reviewer felt should be included are missing. </small></html> |<html><small>  The secondary artifacts are incomplete.  There are not enough supporting artifacts to support approval. </small></html> |
|::: ^<html><small>Transferability (0.75)</small></html> |<html><small> The supporting artifacts are clearly written, and allow the reader to create the system, replicate a test and/or use a prototype to repeat the work.  The supporting artifacts have appropriate mechanics and are properly under revision control. </small></html> |<html><small> The supporting artifacts are somewhat clear.  They provide enough guidance to allow the reader to apply engineering judgment to create a subsystem, replicate a test and/or use a prototype to repeat the work.  The supporting artifacts have acceptable mechanics; the revision control is superficial. </small></html> |<html><small> Supporting artifacts are unclear and/or otherwise difficult to understand.  They provide insufficient information to allow the reader to create a subsystem, replicate a test, and/or use a prototype to repeat the work.  The artifact mechanics are unacceptable.  Revision control is missing. </small></html> |
|::: ^<html><small>Quality (0.5)</small></html> |<html><small> The supporting artifacts reflect thoughtful, appropriate engineering practice.  The correct activities were performed and properly reported in order to support approval.  The reviewer is confident in the information provided to support approval. </small></html> |<html><small> The supporting artifacts reflect engineering practice.  Some of the correct activities were performed and properly reported.  There is some data supporting approval, but it is not thorough or complete.  The reviewer may have some questions about the information provided to support approval. </small></html> |<html><small> The supporting artifacts reflect poor engineering practice.  There is missing evidence for some expected activities.  With the existing artifacts, the reviewer has insufficient information to make an informed judgment to approve stage completion. </small></html> |
| ^<html><small>Formatting (0.5)</small></html> |<html><small> Complies with all formatting requirements in the Capstone Wiki and is carefully and thoughtfully formatted.  Bookmarks and/or hyperlinks are provided to help the reader navigate the document. </small></html> |<html><small> Mostly complies with formatting requirements.  One or two documents need to be fixed to comply with formatting requirements </small></html> |<html><small> Shows little or no evidence of following formatting requirements.  Haphazard formatting, difficult to read.  </small></html> |
|<html><small>Rubric revision 1 made from ScoreSheetMaker revision 1.5</small></html>|||||


==== Review Mechanics ====

The mechanics of the System Refinement Review (and Final Design Report submission) are as follows:

  - No later than **10:00 AM  three class days** (not counting weekends or holidays) **ahead of the scheduled review**, the team submits the Final Design Report, as described above. The submission is done from the [[https://byucapstone.byu.edu/dashboard|Capstone dashboard]].  The evaluating coaches and the pod instructor will receive an email when the submission is completed.  If the submission is late, the evaluating coaches will not provide a grade for the initial submission.
  - No later than 8:00 AM  one class day (not counting weekends or holidays) ahead of the scheduled review, the two coaches who are assigned to evaluate the submission will complete their grading and written evaluation of the Final Design Report.  These evaluations will be available for    download from the Capstone website team summary page.  If the initial submission was late, grades will not be available, and the written evaluations may not be available before the review.
  - The team prepares an oral presentation no more than five minutes in length that includes the project objective statement and discusses why the team believes the architecture is ready for approval, including responses to the evaluator comments where appropriate.
  - At the System Refinement Review, the team will make their brief presentation and demonstrate prototypes used to test the performance of their final design.
  - The reviewers, the team, and the coach will discuss the answers to the questions as contained in the Final Design Report and the presentation for 18 minutes.  Weaknesses in the answers or the  report will be explored, and recommendations for improvement will be given.
  - After consulting with the evaluation coaches, the instructor will spend two minutes to communicate the results of the review to the team.  Possible results are:
    * **Stage approval is granted unconditionally**. When approval is granted, the team can choose to allow the existing grades to stand and let the initial submission serve as the final submission. Or the team may choose to make a revised submission as described below.
    * **Stage approval is conditionally granted, subject to the team making some required revisions**.  The team //must// clear the revisions with their pod instructor before approval is granted.  The team presents the revised submission directly to the pod instructor for approval. After receiving approval, the team submits the revised submission on the Capstone website.
    * **Stage approval is denied**.  The team will need to improve their work, schedule a new review, and        return to step 1.
  - When the team has received stage approval, they have completed all required Capstone approvals.
  - If the approval was conditional, the team //must// submit a revised copy of the Final Design Report after the revisions are approved.  The revised submission is due at **11:59 PM on the last day of classes** for the semester.  If no revised submission is received by the deadline, the team will receive a grade of zero for the stage.
  - If approval was unconditional, the team //may// submit a revised copy of the Final Design Report  to improve their grade.  The revised submission is due at **11:59 PM on the last day of classes** for the semester.   If no revised submission is received by the deadline, the grade on the initial submission will be used.
  - A revised submission must include the following:
    * A memo summarizing the changes to the Final Design Report, and indicating how these changes are responsive to the feedback received.  This memo should not include copies of the changed artifacts; it should just be a memo.
    * A final copy of the revised Final Design Report. \\ We ask for these items to facilitate the work of those who must evaluate  the resubmission. \\ The revised submission will be graded by the same two coaches who graded the initial submission, and the grades will replace the initial grades.
  - The average of the two coaches' scores will be the final grade for the stage.  However, if the difference in the coaches' scores for the stage is greater than or equal to seven points, the instructor will also grade the Final Design Report, and the median of the three scores will then be recorded as the final grade.

The final submission of the Final Design Report should explicitly
reflect feedback given by the sponsor after the Final Design Presentation.


==== Formatting ====

The Final Design Report should be formatted according to the instructions in [[..:artifacts:artifact_formatting|Artifact Formatting]].

If your sponsor requires a bound printed report, follow the additional instructions in [[Formatting Printed Reports]].

==== Delivering to your Sponsor ====
You should deliver the Final Design Report to your sponsor in PDF form and/or
printed form, as desired by your sponsor.  Ask them what they would like.  If
they would like a printed version, use your [[..:office_resources:office_resources#caedm_printing|CAEDM group account]] to print it, and
use the spiral binding system in the Capstone office to bind the report.

<html><div class="capnote">
NOTE: No reimbursements will be given for printing or binding charges.  You should use
CAEDM and the Capstone office to accomplish these functions.
</div></html>

====Examples====

Examples of Final Reports from previous Capstone teams can be found in the Box folder under Class Documents > Examples > W.6 Final Reports.  These are given as representative good examples, but are not perfect.
Capstone Project Wiki

User Tools

Site Tools

Page Tools
