Capstone Project Wiki

Early in the Concept Development stage, a concept is selected that is believed to meet the design needs. At this point the Concept Review is held to show how the concept is a good choice. However, the selection of the concept is not the end of Concept Development. As described on page 67 of Product Development, Concept Development is only complete when a high-quality, verified system architecture has been completed.

The Architecture Review takes place near the end of Fall Semester. The purpose of the review is to answer the questions, “What is the architecture for the system and each of the subsystems, and how do the elements combine to meet the system requirements?” and “How have you demonstrated that the defined architecture is correct, and ensures that the final product will meet its requirements?” Your review will be scheduled to accommodate the team, the instructor, and the review coaches. In preparation for the Architecture Review, you will prepare a draft version of the Fall Semester Design Report. The final version of the report will be submitted after the review, according to the schedule on Learning Suite.

The system architecture at the end of Concept Development includes the following components.

1. An accurate, unambiguous, transferable definition of the selected product concept, where enough detail is provided about the spatial and structural relationships of the principal subsystems that basic cost, size, weight, and feasibility estimates can be made. There should also be a transferable demonstration of how the concept's parts and its whole meet the opportunity.
2. The decomposition of the system into major components or subsystems. See page 71 and page 78 of Product Development.
3. The definition of the interfaces between the systems. See pages 71--72 and pages 78--79 of Product Development.
4. Requirements clearly stated using requirements matrices or software requirements specifications for each of the subsystems, as appropriate for your project. The subsystem requirements should be derived from the performance measures of the system. See page 69 and pages 78--82 of Product Development.
5. Target values for the system and each of the subsystems, as appropriate for your project. See pages 69--70 and page 128 of Product Development.

NOTE: If your project is simple enough that subsystems are not necessary, you do not need to include either the decomposition or the subsystem requirements matrices. However, you should explain why you believe no subsystems are necessary.

The primary purpose of the Fall Semester Design Report is to make this chosen system architecture transferable.

The submission used for the Architecture Review is the Fall Semester Design Report. The purpose of the Fall Semester Design Report is to answer the questions, “What is the architecture for the system and each of the subsystems, and how do the elements combine to meet the system requirements?” and “How have you demonstrated that the defined architecture is correct, and ensures that the final product will meet its requirements?” The Fall Semester Design Report is a single PDF compilation containing the following:

1. A Fall Semester Design Report title page
2. 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 Artifact 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.
3. The Executive Summary. See the next section for more information.
4. PDF copies of each of the Primary Artifacts, as listed below. The Primary Artifacts provide a high-level description of the chosen architecture and the state of the project. Primary artifacts need not contain all of the details needed to reproduce the work but should cite Supporting Artifacts that do contain these details.
5. 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.
6. All PDF files included in the package must be searchable for text, meaning they must not be scanned documents

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

A signature page was required in previous years for the report, but is no longer required. However, a signature page is required for the Project Success Agreement. The Project Success Agreement should be included in this report.

The Executive Summary for the Fall Semester Design Report is a two-page top-level summary of the results of your design work. In addition to text, the summary may contain a few summary figures and/or tables that best show your work. The Executive Summary supplements, rather than replaces, the individual artifacts.

The Executive Summary is formatted as a report, not an artifact. It does not have a title block or list of referenced documents.

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 for 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 brief, you will need to be very concise and carefully consider what information is most important for your target audience to know.

The Primary Artifacts contain more detail than the Executive Summary. The principle you should follow is that the Summary summarizes the artifacts (which contain the full details).

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.
• Summary of Selected Architecture: Briefly describe the selected concept in words and with appropriate top-level pictures. Also describe the selected system decomposition. The description should not be a detailed definition. The detailed definition is found in the artifacts. The description should provide an overview of the concept 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 Architecture Justification: Explain why the selected architecture is appropriate. There are likely two elements to this justification:
  1. A summary of concept selection matrices and/or other decision methods that demonstrate you have considered a relatively large number of concepts and the selected concept is judged to be among the best at meeting the requirements. You will refer to one or more concept selection artifacts for details. You will also refer to the decomposition associated with the selected concept.
  2. A summary of testing, coupled with modeling, that allows you to predict how well the performance of the system you intend to design meets the requirements, especially the Key Success Measures. Testing will require you to create a system prototype at the best fidelity possible within available resources. You will refer to artifacts that define the prototype, the testing procedures, and the results. You will also refer to artifacts for the models used to predict performance.

The artifacts in your report should answer the questions, “What is the architecture for the system and each of the subsystems, and how do the elements combine to meet the system requirements?” and “How have you demonstrated that the defined architecture is correct, and ensures that the final product will meet its requirements?” The documents described below will help you to answer these questions.

These artifacts should be higher-level documents that summarize and draw conclusions from the more detailed material in the supporting artifacts.

• System architecture definition that describes the architecture of the system and any subsystems and defines the key technologies that will be used in these elements. It should also identify which parts of the architecture are off-the-shelf and which are custom designed.
• Requirements matrix (or other requirement specification) for the system and for each defined subsystem. Each matrix should include target values for all performance measures.
• Architecture selection (or justification) document that explains why the architecture was chosen. It should show that the architecture is expected to lead to a desirable design. Normally, this evolves from the Concept Selection Report prepared for the Concept Review, with information on subsystems and interfaces added.
• Prototype testing and modeling reports whose results demonstrate that a final design based on your concept is likely to achieve the target values
• Approved Project Success Agreement. This agreement formalizes the understanding between the team, the sponsor, and the Capstone administration about how project success will be evaluated. The team, sponsor, pod instructor, and External Relations negotiate the agreement. The team submits the agreement to the External Relations Manager via the capstonereports@byu.edu email address, and the External Relations Manager obtains sponsor approval of the Project Success Agreement.
• Updated Project Milestones Table

Supporting Artifacts may include the following, plus any other necessary artifacts (if the information is sufficiently included in the Primary Artifacts, you may not need all of the supporting artifacts). See page 68 of Product Development for more information on these artifacts.

• Concept screening and/or scoring matrices with justification for ratings
• Justification of target values that are less than ideal due to necessary tradeoffs
• Definitions of models and/or prototypes used in testing
• Test procedures used to obtain the results listed above
• Computer files used in the testing work
• Geometric and other appropriate definition of the concept. This is the beginning of the System Design Package. The characteristics of a complete System Design Package are listed under the Supporting Artifacts for the Subsystem Engineering Review.
• System decomposition.
• Subsystem interface definitions.
• Preliminary Bill of Materials. It is very important that the BOM contains information about long-lead-time items. It is in your best interest to order long-lead-time items as early in Fall semester as possible, so they can be shipped over the semester break. It is also helpful to identify the major custom-designed components of your design so you can get started ASAP on their design.
• List of concepts considered, preferably including structure and/or organization showing how concepts are related
• Evaluation of concept set Novelty, Variety, Quantity, and Quality

The Fall Semester Design Report will be reviewed for how clearly and completely it answers the questions above. The concept and tests presented in the artifacts 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 hardware or mixed projects and for software projects.

Evaluation rubric for the Fall Semester Design Report

Evaluation rubric for the Fall Semester Design Report (Software Projects)

The mechanics of the Architecture Review (and Fall Semester Design Report submission) are as follows:

1. No later than 10:00 AM three class days (not counting weekends or holidays) ahead of the scheduled review, the team submits the Fall Semester Design Report, as described above. The submission is done from the 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.
2. 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 Fall Semester 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.
3. 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.
4. At the Architecture Review, the team will make their brief presentation and demonstrate prototypes used to test the performance of and/or demonstrate the feasibility of the system concept.
5. The reviewers, the team, and the coach will discuss the answers to the questions as contained in the Fall Semester 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.
6. 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.
7. When the team has received stage approval, they proceed to Subsystem Engineering beginning with the Winter Planning Review.
8. If the approval was conditional, the team must submit a revised copy of the Fall Semester 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.
9. If approval was unconditional, the team may submit a revised copy of the Fall Semester 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.
10. A revised submission must include the following:
    • A memo summarizing the changes to the Fall Semester Design Report, and indicating how these changes are responsive to the feedback received. This memo should not have the changed artifacts attached; it should just be a memo.
    • A final copy of the revised Fall Semester 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.
11. 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 Fall Semester Design Report, and the median of the three scores will then be recorded as the final grade.

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

The Final Design Report should be formatted according to the instructions in Artifact Formatting.

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

You should deliver the Fall Semester 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.