Capstone Project Wiki

User Tools

Site Tools

Trace:
project-wiki:design_reviews:opportunity_development_review

Differences

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

Link to this comparison view

Next revision 		Previous revision
project-wiki:design_reviews:opportunity_development_review [2021/11/12 09:58]
127.0.0.1 external edit 		project-wiki:design_reviews:opportunity_development_review [2023/08/19 21:11] (current)
bdj2 [Evaluation]
Line 12: Line 12:
     - A summary of the [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=285|Requirements Matrix]], [[https://en.wikipedia.org/wiki/Software_requirements_specification|Software Requirements Specification]] or other Requirement Specification     - A summary of the [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=285|Requirements Matrix]], [[https://en.wikipedia.org/wiki/Software_requirements_specification|Software Requirements Specification]] or other Requirement Specification
     - A demonstration of the prototypes used to understand the problem, communicate with the market, communicate with the sponsor, get up to speed on relevant technology, or otherwise understand the challenge, the market requirements, and the relevant performance measures     - A demonstration of the prototypes used to understand the problem, communicate with the market, communicate with the sponsor, get up to speed on relevant technology, or otherwise understand the challenge, the market requirements, and the relevant performance measures
-    - The Project Milestones Table+    - Project Milestones Table
   - The Team Charter   - The Team Charter
  
-Following the presentation, the reviewers and the team will discuss the quality and transferability of the decisions captured in the submitted artifact. +Following the presentation, the reviewers and the team will discuss the quality and transferability of the decisions captured in the submitted artifacts. 
 Suggestions for improvement will be considered. Suggestions for improvement will be considered.
 The objective of the review is to ensure the team has a solid understanding of the design challenge  The objective of the review is to ensure the team has a solid understanding of the design challenge 
 and any relevant technology in order to support effective and appropriate concept development. and any relevant technology in order to support effective and appropriate concept development.
  
-==== Questions ====+==== Artifact Submission for Opportunity Development ====
  
-The artifacts and the review should answer the following questions.  Satisfactory answers to these questions constitute the minimum requirements for completion of +The artifacts submitted for the Opportunity Development review should answer the questions, "What are the design objectives and the complete product requirements? What are the schedule and resources allocated to achieve these objectives?" and, "How have you validated that the product requirements and Primary Artifacts are likely to be feasible and truly represent the market's and the sponsor's desires?" To answer these questions, the team should submit a pdf file containing the following artifacts:
-Opportunity Development. +
- +
-  - What are the design objectives and the complete product requirements? What are the schedule and resources allocated to achieve these objectives? +
     - Primary Artifacts:     - Primary Artifacts:
       * **Project Background**.  A brief description of the sponsor, the design challenges, and the project that allows the reader to understand what you are tasked with doing and why it is important.       * **Project Background**.  A brief description of the sponsor, the design challenges, and the project that allows the reader to understand what you are tasked with doing and why it is important.
       * **Project Objective Statement**, as described on pages [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=62|62]] and [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=273}|264-65]] of [[https://byucapstone.byu.edu/mattson-sorensen.pdf|Product Development]].       * **Project Objective Statement**, as described on pages [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=62|62]] and [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=273}|264-65]] of [[https://byucapstone.byu.edu/mattson-sorensen.pdf|Product Development]].
       * **[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=64|System Requirements Matrix]]** with sections A--D completed, organized according to the [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=239|Goal Pyramid]] on pages 230--31 of //Product Development//. You may find the template found on Box [[https://byu.app.box.com/file/676291641715|under Class Documents/Templates]] to be helpful in preparing your Requirements Matrix. \\ Be sure that your Requirements Matrix is consistent with the guidelines given on pages [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=271|262--63]], [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=283|274--75]], and [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=285|276--79]] of //Product Development//. \\ For some products, especially software-only products, it may be better to use a **[[https://en.wikipedia.org/wiki/Software_requirements_specification|Software Requirements Specification]]** instead of a Requirements Matrix.  Please consult with your coach and your pod instructor if you feel this applies to your team.       * **[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=64|System Requirements Matrix]]** with sections A--D completed, organized according to the [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=239|Goal Pyramid]] on pages 230--31 of //Product Development//. You may find the template found on Box [[https://byu.app.box.com/file/676291641715|under Class Documents/Templates]] to be helpful in preparing your Requirements Matrix. \\ Be sure that your Requirements Matrix is consistent with the guidelines given on pages [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=271|262--63]], [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=283|274--75]], and [[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=285|276--79]] of //Product Development//. \\ For some products, especially software-only products, it may be better to use a **[[https://en.wikipedia.org/wiki/Software_requirements_specification|Software Requirements Specification]]** instead of a Requirements Matrix.  Please consult with your coach and your pod instructor if you feel this applies to your team.
-      * A **Project Milestones Table** that describes the stages of development to be completed, the deliverables required for each stage, the intended completion date for each stage, and the anticipated budget for each stage.  It should also list other significant milestones that will help you reach your stage review readiness. +      * A **Project Milestones Table** that describes the stages of development to be completed, the deliverables required for each stage, the intended completion date for each stage, and the anticipated budget for each stage.  It should also list other significant milestones that will help you reach your stage review readiness. This table should include significant project milestones specific to your project (i.e., not just the dates of Capstone reviews). 
 +      * **Requirement validation results** indicating the sponsor's and/or market's acceptance of the final requirements as listed in the Requirements Matrix.  Refer to other Primary Artifacts and Supporting Artifacts as necessary.
     - Supporting Artifacts should include one or more of the following, or other similar artifacts:     - Supporting Artifacts should include one or more of the following, or other similar artifacts:
       * **[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=307|Market survey]]**, **[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=237|focus group]]**, and/or **[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=243|interview]]** procedures and results       * **[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=307|Market survey]]**, **[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=237|focus group]]**, and/or **[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=243|interview]]** procedures and results
Line 38: Line 36:
       * **[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=241|Internet]]** and/or **[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=261|patent]]** research reports       * **[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=241|Internet]]** and/or **[[https://byucapstone.byu.edu/mattson-sorensen.pdf#page=261|patent]]** research reports
       * White papers or other technical reports that relate to the project       * White papers or other technical reports that relate to the project
-  - How have you validated that the product requirements and Primary Artifacts are likely to be feasible and truly represent the market's and the sponsor's desires?  
-    - Primary Artifact: 
-      * Requirement validation results indicating the sponsor's and/or market's acceptance of the final requirements as listed in the Requirements Matrix.  Refer to other Primary Artifacts and Supporting Artifacts as necessary. 
-    - Supporting Artifacts should include one or more of the following: 
       * Reports on prototypes used to help the team, the market, and the sponsor better understand the challenges and goals of the project.  If no prototypes are used during Opportunity Development, it is difficult or impossible to obtain high-quality results.       * Reports on prototypes used to help the team, the market, and the sponsor better understand the challenges and goals of the project.  If no prototypes are used during Opportunity Development, it is difficult or impossible to obtain high-quality results.
       * Validation procedures used to obtain market feedback on completed requirements       * Validation procedures used to obtain market feedback on completed requirements
Line 61: Line 55:
 The submitted artifacts will be assessed for how clearly and completely they answer the questions above.  The requirements and validation included in the artifacts will also be assessed for their quality. The submitted artifacts will be assessed for how clearly and completely they answer the questions above.  The requirements and validation included in the artifacts will also be assessed for their quality.
  
-The rubric used in the evaluation is shown below.  A copy of the scoresheet used by the evaluators is available [[https://byu.app.box.com/file/831600112250|on Box]]. +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/1271482309938|hardware or mixed projects]] and for [[https://byu.app.box.com/file/1271491926396|software projects]]. 
  
 <nodisp 16> <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. consistent with the scoresheets.
 </nodisp> </nodisp>
Line 80: Line 76:
 |<html><small>Rubric revision 2.5 made from ScoreSheetMaker revision 1.5</small></html>||||| |<html><small>Rubric revision 2.5 made from ScoreSheetMaker revision 1.5</small></html>|||||
  
 +
 +
 +<nodisp 16>
 +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>
 +**Evaluation rubric for Opportunity Development stage (Software Projects)**
 +^Element ^ Item(weight) ^ Excellent (9-10) ^ Good (7-8) ^ Poor (0-6) ^
 +|Primary Artifacts -- reviewers evaluate all ^<html><small>Project Background (0.5)</small></html> |<html><small> Clearly and succintly presents the background of the project such that a technically literate reader with no knowledge of the project can understand the importance and the challenges of the project. </small></html> |<html><small> Presents the background of the project sufficiently to motivate reading the other artifacts. </small></html> |<html><small>  Is confusing or hard to read.  Provides little sense of importance of the project or technical challenges that may exist.  Hard to see why anyone would want to do the project. </small></html> |
 +|::: ^<html><small>Project Objective Statement  (0.5)</small></html> |<html><small> Clearly and succinctly describes the scope, schedule, and resources for the project. Is thoughtful and specific to the project. </small></html> |<html><small> Describes the scope, schedule, and resources for the project. Is generic or otherwise not carefully thought out. </small></html> |<html><small> Is missing one or more of the essential items.  Shows little or no understanding of the problem. </small></html> |
 +|::: ^<html><small>Software Requirements Specification (SRS) (2) (2)</small></html> |<html><small>Software Requirements Specification is professionally and thoughtfully prepared and thoroughly captures the requirements for the project. Requirements are clearly written. SRS is under effective revision control. Artifact has been checked by someone other than the author. All elements of specification are thoughtful and appear correct. </small></html> |<html><small>SRS is mostly well done but falls short of the listed criteria in one or two areas. Some elements of the specification appear to be superficial. Lacks some of the necessary requirements to ensure project success. Revision control is superficial. </small></html> |<html><small>SRS has some serious weaknesses that raise questions about its utility. In the opinion of the reviewer, the market requirements are a poor reflection of the actual market desires. In the opinion of the reviewer, the requirement specification is not sufficient to ensure successful project completion even if all of the listed specifications are met. Revision control is missing. </small></html> |
 +|::: ^<html><small>Project Milestone Table (0.5)</small></html> |<html><small>Table contains appropriate milestones for the project, including all required reviews and project-specific milestones that will help the project move forward. Table is thoughtfully and appropriately prepared and may be a high-resolution, readable image from team’s project management software. Effectively under revision control. </small></html> |<html><small>Table contains milestones for all required reviews. Table is not specific to the project and only contains Capstone assignment deadlines. Revision control is superficial. </small></html> |<html><small>Table is missing or is very superficial. Does not include all the required reviews. Revision control is missing. </small></html> |
 +|::: ^<html><small>Requirements Validation Results (1.5)</small></html> |<html><small>Appropriate efforts to validate the requirements with the market and/or the sponsor. There is clear evidence that specific feedback has been obtained showing the desirability of the requirements. The artifact contains test procedures and results (or links to supporting artifacts with test procedures and results) that clearly show the data obtained and the procedures used to obtain the data. The artifact is properly under revision control. </small></html> |<html><small>Report summarizes efforts to obtain feedback from the market and/or sponsor concerning the requirements. The evidence for external validation is present, but not fully compelling. Revision control is superficial. </small></html> |<html><small>Report is missing or is primarily focused on team evaluation of the the requirements, rather than on external evaluation by the market and/or sponsor.  Revision control is missing. </small></html> |
 +|Supporting Artifacts -- reviewers spot check ^<html><small>Market interaction artifacts (1.5)</small></html> |<html><small> Artifacts reporting on interactions with the market, such as market surveys, focus groups, or interviews (including both procedures and results) are carefully and clearly presented.  Enough detail is given to allow a third-party to repeat the interactions.  Artifacts are under effective revision control.  </small></html> |<html><small>Artifacts reporting on interactions with the market, such as market surveys, focus groups, or interviews (including both procedures and results) are  presented.  Enough detail is given to allow a third-party to repeat the interactions by using some judgment.  Revision control is superficial.   </small></html> |<html><small>Artifacts reporting on interactions with the market, such as market surveys, focus groups, or interviews (including both procedures and results) are missing or poorly presented.  Little or no detail about the market interactions is given.   Revision control is missing. </small></html> |
 +|::: ^<html><small>Prototyping artifacts (1.5)</small></html> |<html><small> Artifacts reporting on the making and using of prototypes to communicate with the market and sponsor and/or get up to speed on relevant technology are carefully and clearly presented. Enough detail is given to allow a third-party to repeat the use (but not the creation) of the prototypes.  Prototypes are appropriate for their intended use.  Prototypes have helped the team get real about the project.  Artifacts are under effective revision control.  </small></html> |<html><small>Artifacts on prototypes are presented.  Prototypes are somewhat appropriate for the intended use.  Prototypes seem to have reasonable purposes. A third party could recreate the use of the prototypes with the use of some engineering judgment. Revision control is superficial. </small></html> |<html><small>No artifacts on making and using prototypes are presented.  If used, prototypes are used in inappropriate ways.  Prototypes seem to have little purpose related to understanding or advancing the design.  Little or no information is given about how the prototypes are used. Revision control is missing. </small></html> |
 +|::: ^<html><small>Validation Artifacts (1.5)</small></html> |<html><small> Detailed artifacts showing methods and results of obtaining validation from the market and/or the sponsor, if needed to support the requirements validation results, are clearly and carefully presented. Artifacts are under effective revision control.  </small></html> |<html><small>The evidence for external validation is present, but not fully compelling.  Arifacts are somewhat unclear; significant judgment is required to interpret them. Revision control is superficial. </small></html> |<html><small>Necessary artifacts  are missing or are primarily focused on team evaluation of the the requirements, rather than on external evaluation by the market and/or sponsor.  Revision control is missing. </small></html> |
 +| ^<html><small>Formatting (0.5)</small></html> |<html><small>Is carefully and thoughtfully formatted.  Bookmarks and/or hyperlinks are provided to help the reader navigate the document.  Is free from grammatical errors.  If printed reports are desired by sponsor, complies with printed report formatting guidelines. </small></html> |<html><small> Mostly complies with formatting requirements.  One or two documents need to be fixed to comply with formatting requirements.  Has a few grammatical errors. </small></html> |<html><small> Shows little or no evidence of following formatting requirements.  Haphazard formatting, difficult to read.  Has many grammatical errors. </small></html> |
 +|<html><small>Rubric revision 0.4 made from ScoreSheetMaker revision 1.5</small></html>|||||
  
  
Line 87: Line 101:
 The mechanics of Opportunity Development reviews are as follows: The mechanics of Opportunity Development reviews 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 artifact package, as described above. The submission is done from the [[https://byucapstone.byu.edu/dashboard|Capstone dashboard]]. The review 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 **10:00 AM three class days** (not counting weekends or holidays) **ahead of the scheduled review**, the team submits the artifact package, as described above. The submission is done from the [[https://byucapstone.byu.edu/dashboard|Capstone dashboard]]. The review 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 review the team will complete their grading and written evaluation of the artifact package.  These evaluations will be available for download from the [[https://byucapstone.byu.edu/dashboard|Capstone dashboard]].  If the initial submission was late, grades will not be available, and the written evaluations may not be available before the review.     - 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 review the team will complete their grading and written evaluation of the artifact package.  These evaluations will be available for download from the [[https://byucapstone.byu.edu/dashboard|Capstone dashboard]].  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 they are ready for stage approval, including responses    to the evaluator comments where appropriate.     - 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 they are ready for stage approval, including responses    to the evaluator comments where appropriate.  
project-wiki/design_reviews/opportunity_development_review.1636736307.txt.gz · Last modified: 2021/11/12 09:58 by 127.0.0.1

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: Copyright Brigham Young University, all rights reserved
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki