Differences

This shows you the differences between two versions of the page.

--- project-wiki:design_reviews:subsystem_engineering_review [2023/08/19 21:26]
bdj2 Revise to emphasize the documents to be submitted
+++ project-wiki:design_reviews:subsystem_engineering_review [2023/08/30 16:23] (current)
bdj2 [Evaluation Rubrics]
@@ Line 87: / Line 87: @@
 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/998803361883|hardware or mixed projects]] and for [[https://byu.app.box.com/file/1010818483530|software projects]].
+The scoresheets used by the evaluators are available on Box for [[https://byu.app.box.com/file/1271492850609|hardware or mixed projects]] and for [[https://byu.app.box.com/file/1271491926396|software projects]].
@@ Line 93: / Line 93: @@
 <nodisp 16>
-NOTE TO INSTRUCTORS: This table is automatically created by [[https://byu.app.box.com/file/830893783568|ScoreSheetMaker.xlsm]].  Make the changes in ScoresheetMaker.xlsm so they will be
+NOTE TO INSTRUCTORS: This table is automatically created by [[https://byu.app.box.com/file/1281677015283|ScoreSheetMaker.xlsm]].  Make the changes in ScoresheetMaker.xlsm so they will be
 consistent with the scoresheets.
 </nodisp>
@@ Line 113: / Line 113: @@
 <nodisp 16>
-NOTE TO INSTRUCTORS: This table is automatically created by [[https://byu.app.box.com/file/830893783568|ScoreSheetMaker.xlsm]].  Make the changes in ScoresheetMaker.xlsm so they will be
+NOTE TO INSTRUCTORS: This table is automatically created by [[https://byu.app.box.com/file/1281677015283|ScoreSheetMaker.xlsm]].  Make the changes in ScoresheetMaker.xlsm so they will be
 consistent with the scoresheets.
 </nodisp>
@@ Line 122: / Line 122: @@
 |::: ^<html><small>Test Procedures  (1)</small></html> |<html><small>Test procedures are clearly defined. Test procedures are adequate for thorough testing of software modules. All modules have a test plan. Effectively under revision control. </small></html> |<html><small>Test procedures appear to be incomplete. One or two obvious tests that should be included are not. Most procedures are reproducible, but some are unclear. Somewhat under revision control. </small></html> |<html><small>Test procedures are haphazard and do not make sense. Test procedures are missing for several critical tests. Not under revision control. </small></html> |
 |::: ^<html><small>Test Results  (0.5)</small></html> |<html><small>Test results are clear and accurately recorded. May include links to videos of software running, if applicable.  </small></html> |<html><small>One or two test results are missing or unclear. Revision control is superficial. </small></html> |<html><small>Test results are missing with no explanation. Not under revision control. </small></html> |
-|::: ^<html><small>System Design Package, including System Design Package, including (at a minimum) a SBOM, diagrams, code documentation, and interface definitions.  (2.5)</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. Code is commented well and transferable. Artifacts are under effective revision control. </small></html> |<html><small>Software Bill of Materials is mostly complete. Some diagrams do not clearly convey architecture. Software organization is defined, and mostly follows the guidelines. Code is a bit confusing, but someone could pick it up after brief review. Interface definitions are mostly clear and present. Revision control is superficial. </small></html> |<html><small>Software Bill of Materials is lacking key elements. Diagrams are confusing, if present. Software architecture does not make sense. Code is difficult to follow and lacks helpful comments. Interface definitions are missing or unclear. Not under revision control. </small></html> |
+|Supporting Artifacts -- reviewers spot check ^<html><small>System Design Package, including System Design Package, including (at a minimum) a SBOM, diagrams, code documentation, and interface definitions.  (2.5)</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. Code is commented well and transferable. Artifacts are under effective revision control. </small></html> |<html><small>Software Bill of Materials is mostly complete. Some diagrams do not clearly convey architecture. Software organization is defined, and mostly follows the guidelines. Code is a bit confusing, but someone could pick it up after brief review. Interface definitions are mostly clear and present. Revision control is superficial. </small></html> |<html><small>Software Bill of Materials is lacking key elements. Diagrams are confusing, if present. Software architecture does not make sense. Code is difficult to follow and lacks helpful comments. Interface definitions are missing or unclear. Not under revision control. </small></html> |
-|Supporting Artifacts -- reviewers spot check ^<html><small>Completeness (1)</small></html> |<html><small>All necessary supporting artifacts are included.  There is nothing the reviewer felt should be included that is missing.  For Subsystem Engineering, likely supporting  artifacts include:<br>* Up-to-date Project Success Agreement<br>* Computer files used in testing work<br>* Other detailed artifacts that support your evaluation of the performance of the subsystems and 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>Completeness (1)</small></html> |<html><small>All necessary supporting artifacts are included.  There is nothing the reviewer felt should be included that is missing.  For Subsystem Engineering, likely supporting  artifacts include:<br>* Up-to-date Project Success Agreement<br>* Computer files used in testing work<br>* Other detailed artifacts that support your evaluation of the performance of the subsystems and 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 (1)</small></html> |<html><small>The supporting artifacts are clearly written, and allow the reader to create the subsystem, 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 (1)</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 (1)</small></html> |<html><small>Complies with all formatting requirements in the Student Book 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 0.1 made from ScoreSheetMaker revision 1.5</small></html>|||||
 ==== Mechanics ====

Capstone Project Wiki

User Tools

Site Tools

Differences

Page Tools