CS 240 - Final Report

Due Fri Dec 20 at 5:00pm

Overview

Each development team will produce one last piece of documentation about the project. This report will compile and summarize the implementation work you have done this semester, as well as offer an opportunity for reflection on and analysis of the software engineering process. This document is intended to act as a final reference and description of your project--this report details what you've done and how you did it. Note that this final report will draw on elements and text of your previous reports (namely the requirements and design reports), but will be primarily new content.

Much of this report is analytical and reflective, rather than just descriptive. You should definitely have multiple people look at and consider each part, rather than simply dividing up the work and having one person analyze each section. Multiple heads are definitely better than one on this!

Objectives

Details

As with all documentation in this course, your report should be typeset using LaTeX---you are to turn in both the .tex source code as well as a final pdf.

Your report should include the below sections:

  1. Cover Page

    Include a cover page with the title of the document, the name of your project and module, the names of all your team members, and other metadata (such as the date and a document revision number, if appropriate).

  2. Project Summary

    This section should give a short (around a page) description of what project you implemented. This will likely include a brief description of the overall Edith system, as well as a more detailed summary of what your individual module does.

    • The summary should describe the system from the user's perspective--with the potential user being both the end-user and the other "developers" who would be utilizing your module. Thus you should focus on functionality, but feel free to include information about system workings.
    • This section can easily draw on the summaries you've written for other reports, though make sure your description is current and actually describes what you produced!
    • Again, this summary should likely be around a page in length.
  3. Development Procedures

    In this section, provide a brief discussion of your development process. Your goal is to explain your development and evaluate what worked and what didn't. You should be sure and address the following points:

    1. What kind of process model did you follow? (Likely this is a hybrid of multiple models we discussed in class). What components did you work on in what order? What was effective and not effective about your process and how you structured your development?
    2. What forms of testing did you include? How do you know if your program works? What forms of testing were effective or ineffective?
    3. Which team members were responsible for which components? This should be more than "everyone worked on everything"--who contributed what to the system?

    Be sure and address all parts of the questions.

    • Include plenty of specifics in your descrption. This section should basically explain what you did in the course in terms of the final project, with enough detail that a reader could understand what activities you did and how you spent your time. Imagine writing for someone who hadn't taken the course and was curious what you did.
    • A key part of this discussion is analyzing what worked and what didn't. Be sure and address why you think some part of the process model wasn't effecive for this project. For example: why or why didn't putting together a requirements document help?
    • This section will likely be between 1 and 3 pages in length.
  4. Requirements Evaluation

    Include a list of the functional and non-functional requirements for your project. What were the requirements, and how did you meet them? Be sure and explain how your project meets a particular requirement if it is not directly obvious (as will likely be the case for non-functional requirements). If any requirements were not met, be sure and explain why (with more detail than "we ran out of time").

    • Note that you do not need to include the full write-ups of your requirements; a simple list of names and brief descriptions would suffice.
    • In describing the requirements, be sure and consider (in writing!) which requirements were effective or helpful. What requirements were well defined? Which were not? What about the requirements may have made them effective or ineffective?
    • This is a good place to discuss if the requirements for your module changed over time
    • This will be one of the longer sections of your report--likely 3 to 5 pages.
  5. System Design & Architecture

    This section should provide a detailed explanation of your project's implementation. You should describe both the high-level architecture (classes, modules, etc), as well as lower-level design (notable method structures, etc).

    • Explain to me how your system and code work! This is basically a written version of the code walkthrough. I should be able to hand your code and this report to somebody who has never seen the project before (e.g., a 261 student with an understanding of JavaScript/PHP) and they should be able to understand how it is put together.
    • Include at least one appropriate UML Diagram. This might be a Class Diagram detailing object breakdowns, or a Sequence Diagram tracing the method calls (often appropriate for event-based programming)---you could even include both to help explain your program!
      • Other figures (e.g., screenshots of the interface) or tables (e.g., list of methods), could also be helpful.
    • This is a more descriptive than analytical section--but you need to include sufficient detail in that description.
    • This is the other long section of your report, likely 4 to 6 pages (including the diagrams and readable formatting).
  6. Individual Reflections

    This section will actually be 5 or 6 subsections--one written by each team member. In this section, each team member should individually reflect on the experience of developing this project, and what you'll take away from it. In particularly, you should consider:

    1. What challenges (both technical and organizational) did you encounter during development, and how did you overcome those challenges? What skills or considerations will you take away from this project for the future?
    2. How did you apply software engineering techniques to help you during development? What helped and what didn't (and why or why not)?
    3. What would you have done differently if you were to start this project over again? If you were to continue working on the project, how would you continue developing it?

    Each team member should contribute a reflection; you are welcome to reference and address other member's insights, but you will need to provide your own discussion.

    • Include plenty of details and specifics. Each person's reflection should be around 1 page long.
  7. Glossary and References

    Finally, be sure to define any technical terms you use, and to include links to any tools, packages, libraries, or systems that you mention in your document. Always cite others' work!

As always, make sure that you proofread and edit your report. It should be polished to a high sheen.

This report is due at 5:00pm on Friday, Dec 20th. That is the Friday of finals week. Note that I will be pulling from the master github repository at that time, and your report better be inside it!

Submitting

Your report should be committed to the master branch of project repository (put it in the the "docs" folder, with a title so that I can easily find it!)---be sure and upload both the .tex source code and the compiled pdf. Only one copy of the team's report needs to be committed (it doesn't matter who actually pushes out the commit).

Note that I am happy to look over early drafts (before the deadline!) and provide feedback.

And finally, each team member will also need to complete one last Peer Evaluation form by the paper deadline.

IMPORTANT NOTE: The final project's implementation (the code) is due Wednesday, Dec 18th at 11:59pm

Grading

Your final report will be graded on approximately the following criteria: