Data : Analysis

Now that the project has been turned in, take a few hours to relax and reflect, then analyze your experience. It is important for you to review your past performance, analyzing its positive and negative aspects to maximize what you learn from this experience. The goal of this retrospective is to draw meaningful conclusions to help you learn from your past successes and failures. They are an integral part of a project because, if taken seriously, they can be an extremely productive method of improving your development practices.

Submission

Complete the following deliverables in the appropriate places as noted for each:

• Documentation: in your data_NETID repository, comment your public methods using Javadoc and complete the project DESIGN document (note, any part of this document can also be used within your analysis as appropriate)
• Project Reflection: complete this Google form, in which you analyze on the project's planning and progress and what you learned from doing this project
• Written Analysis: in your data_NETID repository, complete this template file using Gitlab's markdown format
• Code Review: during the course staff Office Hours, meet to review a specific class within your project and get feedback for how to improve

Specifications

Your analysis is your opportunity to demonstrate your knowledge of design concepts represented (or not) in the project's code. The course staff can readily identify the good and bad aspects of project's design, so we are looking to see if you can also acknowledge these as well. If it is also an honest and thoughtful reflection, it can also help you identify specific actions you can do to improve future projects.

Personal Project Report

This Google form represents your view of the project's planning and progress. Analyze your plan and how the project's outcome could be improved. Describe specific, important, events during the project's time line to justify your comments rather than general terms like "always late", "bad code", etc.

Design Review

This written report represents your personal view of how your program is organized and why it was done that way. It can be a chance for you to describe how you might fix a problem or refactor the design if you did not have time to actually change the code. If you think something is good, justify your opinion. If you think something is bad, justify your opinion, and suggest how to improve it. Use specific code examples and reasons related to principles discussed in class or in the readings rather than general terms like "clearly/obviously", "good/sucks", "elegant/ugly", or "like/hate". Note, since no design is perfect, including both pros and cons of a design (i.e., its trade-offs) or alternate designs you considered is highly encouraged.

• Status
  Reflect on the coding details of the project by reviewing the code.
  • Is the code generally readable (i.e., does it do what you expect, does it require comments to understand)? why or why not?
  • Describe two pieces of code in detail:
    • Describe the purpose of this code in the overall project.
    • What makes this code easy (or hard) to read and understand?
• Design
  Reflect on how the program is currently organized.
  
  • Describe the overall design of the program, without referring to specific data structures or actual code.
  • Justify why your overall code is designed the way it is or what issues you wrestled with if you think its design is lacking in some way.
  • Describe two specific steps you took to reduce the code duplication when implementing a new question.
• Alternate Designs
  Reflect on alternate designs for the project based on your analysis of the current design.
  • Describe two design decisions you made, or wish you had done differently, in detail:
    • What alternate designs were considered?
    • What are the trade-offs of the design choice (describe the pros and cons of the different designs)?
    • Which would you prefer and why (it does not have to be the one that is currently implemented)?

Code Review

Meet with one of the course staff to get specific feedback on a part of your project that is small enough to be separable, but functionally significant enough to have some interesting design element. It may be several classes that work together, e.g., a few classes that work together or a superclass and its sub-classes, but it should be no more than 200 lines of code to review. At this meeting, be prepared to describe this code's purpose and why you think it is well designed (or not if you want detailed feedback on why not).

Sign up online for a time to meet with the course staff — this must be done by the end of the day January 30.