Template for Final Report Document – Software Engineering Capstone Project
Version 2020-1

This template serves as the basis for writing the project Final Report Document. Make a copy of it and rename the file XXX_Project_Final_Report_v1.docx where XXX is the name of the project. Then, edit the document according to the directions below.

If the document needs to be modified or updated during the course of the project, create a new version of it (v2, v3, etc. in the name of the file) and summarize the changes in the versions tracking table below. Don’t forget to update the document version number in the page headers. When turning in the Final Report Document for grading, submit two printed copies of it (in color if necessary) bound or in a binder.

How to use this template:

All text in black – must be left as is.

All text in <red between angle brackets> must be replaced with appropriate text in black (and without the angle brackets)

All text in blue italics are instructions or examples and must be removed from the document.

Any paragraph that appears inside a blue shaded box is instructions and must be removed from the document (including the boxes on this page).

Do not delete sections or paragraphs from the document.

- Any section that is not applicable to the project should be filled in with “Not applicable”

- Any section that is undecided should be filled in with “To be decided” or “TBD”

Keep the document’s style and format (including full justification), in particular the styles for “Normal”, Headings 1, 2, 3, “Caption”, and TOC 1, 2, 3.

Keep the document header and footer, including the page numbering

All figures must be accompanied by a number and a descriptive caption beneath them. Example caption: Figure 5: Flow Chart. We recommend using the automatic numbering features of MS Word (using the Caption style). Make sure all figures are readable and clear!

All tables must be accompanied by a number and a descriptive caption above them. Example caption: Table 2: Project Participants. We recommend using the automatic numbering features of MS Word (using the Caption style).

Create the table of contents, list of figures, and list of tables using the automatic generation feature of MS Word.

Content from external programs, external documents, or source code can be included in the document using one of the following methods:

Copy/Paste the content into the appropriate place in the document

Add the content as an appendix at the end of the document (number the appendix and include it in the table of contents), e.g. Section 8.1: Algorithm for Calculating X. Reference the appendix in the appropriate place in the document.

Include the content in another file and submit it with the document (add the external file to the list of references at the end of the document), e.g. ABC-Testing-Plan.docx. Reference the external file in the appropriate place in the document.

<Project Name> Project

Software Engineering Department

Achi Racov School of Engineering

Kinneret Academic College

<Year> Academic Year

Final Report

Version <Version number>

Submission Date: <Date>

Project Team
<Student Name>, ID <ID Number>, <Department/Major> <Student Name>, ID <ID Number>, <Department/Major>
Customer
<Name of the company/organization/person for whom the project is to be performed>
Industrial Advisor(s)
<Industrial Advisor Name>, <Position>, <Company or organization> <Industrial Advisor Name>, <Position>, <Company or organization>
Academic Advisor(s)
<Academic Advisor>, <Department>, <Institution> <Academic Advisor>, <Department>, <Institution>

List of versions of this document. After every major change, submission, or feedback from an advisor, increase the version number, write the date, and summarize the changes from the previous version.
Versions Table

Version	Date	Summary of changes from previous version
1	Initial version

Table of Contents

This table of contents is generated automatically by MS Word. Update it every time you make a change to the document. You can update it by right clicking on the table of contents and selecting “Update Field”.

1	Introduction	7

1.1	Project Background	7

1.2	Problems and Challenges	7

1.3	Solution Approach	7

1.4	Results	7

1.5	Solution Environment	7

2	Theoretical Background	8

2.1	Sources	8

2.2	Potential External Customers/Users	8

3	Technical Summary	8

3.1	Design and Implementation Considerations	8

3.2	Logical planning and execution	9

3.3	Physical implementation and deployment	10

4	Project Execution	10

4.1	Actual timeline	10

4.2	Integration and Operation	10

4.3	Tests	10

4.4	Maintenance and Support	11

5	Self-Evaluation, Reflection, Conclusions	11

6	Second-Language Project Brief	12

6.1	Project Background	12

6.2	Problem Statement and Solution Approach	12

6.3	Testing and Integration	12

6.4	Results	12

7	References	12

8	Appendices	12

List of Figures

The list of figures is generated automatically by MS Word. Update it every time you make a change to the document. You can update it by right clicking on the table of contents and selecting “Update Field”.

Figure 1: Solution environment	7

Figure 2: Screen shot 1	10

List of Tables

The list of tables is generated automatically by MS Word. Update it every time you make a change to the document. You can update it by right clicking on the table of contents and selecting “Update Field”.

Table 1 : Fulfillment of high-level requirements	9

Introduction

This is the Final Report for the <Project name> project that was performed as an industrial capstone project. The project developed the <system/software> in accordance with the Charter document [1] and Specification & Design document [2] referenced below.

Project Background

A short summary, between one half to one page, that details the need that led to the project, the main goals, the main attributes, the main milestones, and any other critical information that served as the foundation for the project.

Problems and Challenges

Explain the primary problems that were to be solved by the project. What challenges did the project team face in planning, designing, and implementing the solution?

Solution Approach

The approach the project team used to implement the solution. Examples: integration of commercial off-the-shelf products, use of open-source libraries and tools, building a demonstration prototype, incremental/iterative development with an evolving prototype.

Results

A brief description of the results achieved by the solution approach from the previous section. Example: built a prototype that led to a production-ready system, released X versions of the software, built a service library.

Solution Environment

Solution environment An explanation accompanied by a figure of the system, business processes, business units, or external organizations that interface with the developed solution. Clearly mark the parts that were developed as part of the project.

Figure 1: Solution environment

If the project or system does not interface with external systems, give a schematic figure that shows the actors/units that work with the system, what they input to the system, and what output they receive from it.

Theoretical Background

This section includes information necessary to understand the project, its essence, and how it was implemented.

Sources

A list of academic articles, books, textbooks, technical documents, web sites, and other resources that guided the project team in designing and implementing the system. Include all of the sources in the References section below (include URLs, if applicable) and put citations to the references here (numbered, between square brackets (e.g., RFC 3541 was used for … [3]). Write 1-3 sentences about the primary lessons or message for the project learned from each source.

Potential External Customers/Users

List external academic and industrial organizations or actors (including other business units within the customer’s organization) that may be interested in the project or its results. This does not include bodies or actors who were directly involved in the creation or development of the project. Do not include the project’s advisors, customer, developers, or any other actor or stakeholder in the project listed in Specification & Design document.

Write at least 2 such external entities. For each, write 1-3 sentences about what the organization or actor would be interested in with respect to the project.

Technical Summary

This section contains the design of the solution that was detailed in the Specification & Design document [2]. It was implemented in the manner described in the following subsections.

If any significant changes to the design or specification of the project during the course of the work, go back and edit the Specification & Design document [2] and submit a final, updated version of it. You will informally describe the changes that took place in the upcoming sections.

Design and Implementation Considerations

Explain the decisions that were made during the planning and writing of the technical documents and how they affected the final results of the project. The explanation should be informal; do not go to the level of detail of the Specification & Design document. Rather, write enough text (about 10 lines) to give the reader a good understanding of what mode of thought the project team had when designing and building the system.

Return to the high-level requirements table from the Charter document and explain how each requirement was addressed in the final product. If a requirement was not met, explain textually why it was not fulfilled.

Include the final, detailed requirements table as an appendix to this document below.

Table 1 : Fulfillment of high-level requirements

#	Requirement	Type (F/NF)	Critical (Y/N)	Priority (H/M/L)	Difficulty (H/M/L)	Fulfillment method
Critical requirements should be between one third and half of all requirements	Ensure that priority is distributed evenly over the requirements	A large number of requirements with H difficulty makes project completion riskier

Type: F = Functional requirement, NF = Non-functional requirement (e.g. reliability, availability, information security, etc.)
Critical: Fulfilling all critical requirements is required to complete the project.
Priority: How important is it to address the requirement in the project’s timetable. H = High, M = Medium, L = Low
Difficulty: H = High, M = Medium, L = Low.

Logical planning and execution

Explain the assumptions the logical planning and design were based on, as described in the Specification & Design, and the important changes, additions, and removals that took place during the planning process. Explain what the motivation for each such change was. If the system includes a user interface, include a complete set of screen shots of the system in use. For each screen shot, explain what the system accomplishes in the screen shown and include a trackback to the detailed requirements.

If the system did not include a user interface, give detailed instructions for how to operate it (integration with other system, calls to other services, operational steps, etc.) You may reference a separate User Manual if you created one.

Screen shot 1

Figure 2: Screen shot 1

Physical implementation and deployment

Explain the assumptions that the physical planning and design were based on, as described in the Specification & Design document and the important changes, additions, and removals that took place during the planning process. Explain what the motivation for each such change was.

Refer to figures in the Specification & Design document as necessary (there is no need to reproduce them here). Include here any informal, marketing, or accessory figures that help explain the physical deployment of the system as necessary.

Project Execution

Actual timeline

Give the actual project timeline in the form of a Gantt chart created with MS Project. This is in contrast to the planned project timeline that was in the Charter. Use the same format for both Gantts to allow comparison (i.e. create a Gantt chart with MS Project that shows the dates, resources, work hours as they actually were, up until project conclusion). Explain any significant differences between the planned and actual timelines. For instance: why activities took longer or shorter than expected, why activities were done in a different order than planned, why activities were added or removed.

Integration and Operation

Describe how the project’s results were integrated into the existing systems (e.g. gradual integration, integration first into a test environment).

Tests

Report the results of the various levels of testing performed on the system, in accordance with the test plan from the Specification & Design. The results must include what elements were tested, the steps for the test, the number of times the tests were performed, any steps taken to fix tests that initially failed, and regression tests performed after fixes were applied.

Emphasize the acceptance tests that were performed to ensure that the project’s results were approved for use and decisions that were based on their results. If the testing plan was written in accordance with the proposed format in the Specification & Design, copy the table(s) from the Specification & Design and add columns with the names “Actual Results” and “Pass/Fail.”

If there are acceptance tests that failed and remain unfixed (i.e. “known bugs”), list them here along with any work-arounds that users can use to avoid the bugs.

If the testing report is long, it is recommended to move it to an appendix below or to make it a separate document included with the final project submission.

Maintenance and Support

Explain what support the project team gave during the course of the project. Also explain who will maintain and support the system developed after the project’s completion. If you wrote a “Programmers Guide” as a separate document (and you are encouraged to do so), add it as a supporting document in the project submission, add it to the references list below, and add a citation to it here (number between square brackets, e.g. [3]).

Self-Evaluation, Reflection, Conclusions

This section must contain self-evaluation of the project by the project team. Reflect on the performance of the project and its conclusion. The self-evaluation should reflect on the following issues (at least):

What did you expect the hardest part of the project to be? The easiest part? Were your expectations correct?

What help did you get from advisors (academic, industrial) and other employees of the customer?

How much did the preparation of the Charter and Specification & Design documents help you with your project and its performance? Did you need to go back and update/change them during the course of the project or after its completion?

If you were going to do the project all over again, what would you have done differently?

What do you think should be the measure of the project’s success or failure?

Additionally, write a conclusions section (2-3 paragraphs) that includes lessons learned, the primary achievements of the project, goals or targets not achieved, advice for future projects, and what the team members personally gained from the project.

Second-Language Project Brief

If the project was performed in an environment where English is not the primary language, this section should be written in the primary local language to give non-English speakers a summary of the project. The brief should be 2 pages long.

Project Background

Information about the background for the project, the customer, the business or organizational need for the project, and the project’s goals.

Problem Statement and Solution Approach

List the problems that the project was created to solve. Explain the solution approach chosen, the software development process chosen, and the project milestones.

Testing and Integration

Explain how the system was tested. Did it meet the expected tests? Explain how the system was integrated into other systems at the customer.

Results

A statement of the results from the project. What software, systems, tools, hardware, servers, clients, etc. were changed or updated. Explain which goals the project achieved and which goals were not achieved. Explain how the customer’s business processes or systems are affected by the results of the project.

References

A numbered list of documents and other sources using full bibliographical entries (use APA or IEEE style). Every time one of the documents is mentioned in the body of the Final Report, cite the document using the source’s number between square brackets (e.g. [3]). You may use MS Word’s “Manage Sources” feature to do this automatically. If the reference is an external document, some associated documentation, or an external resource (excluding websites or online resources), include a copy of the reference in the project submission package as well.

Project charter for <Project name>, Version <version number>.

Specification & Design for <Project name>, Version <version number>.

Appendices

Any additional material related to the project that does not fit into the previous sections can be added here in separate sections (Appendices). Common appendices include:

Final detailed requirements list (recommended)

User guide (if not in a separate file)

Programmers guide (if not in a separate file)

Thank you letters

Important sections of code/pseudocode

Configuration information

Each appendix should be numbered as a sub-section (e.g. 8.1 Important algorithms and code, 8.2 Thank you letters, 8.3 Configuration information).

If the information is too long for an appendix, put it in a separate file, submit it along with the project, and add it to the list of references above.