0. Format

In a GitHub issue titled journal_2_<cwl> filed to your 310 journal repository (e.g., journal_<cwl>), answer the questions below (example issue title: journal_1_kdchin). 

IMPORTANT: If your journal is not submitted exactly this way, you will not receive credit; the ability to follow this straightforward instruction cannot be waived! The creation time / last edit for this issue must be before the submission deadline.

Your responses will be assessed by course staff for their thoroughness and completeness. Additionally, you will have a one-on-one reflection with your lab TA in the lab immediately following the journal submission deadline, based on your submitted written responses. Both the written and oral components will factor into your final bucket grade for this assignment.

1. Reflection

This part of the journal asks you to reflect on your development process for C2. It covers four Learning Areas: LA0: Process,  LA1: Testing,  LA: High Level Design and LA4: Construction & Refactoring.

1a) Groups often refactor or redesign their code during C2 to accommodate the new requirements. 

• How did your initial design for C1 change in your implementation for C2? Why did you decide to make this change, and how hard was it to do? If your design did not change significantly, why do you think it did not? Link to a PR or code that demonstrates this change, or one that was made easier by good design.

• What techniques or lessons did you learn about software design that you will use in the future?

• Name at least one design principle that your code exhibits, and link to it in your implementation.

1b) In Journal 1 you created user stories to plan your C2. How did this process affect your development? What parts about this planning strategy would you continue to use in the future, and which do you think were unnecessary?

1c) In C1, your implementation was at least partly driven by the tests you created during C0, a form of test-driven development. How did your development process change in C2 where you started without any C2-specific tests? 

2. Planning

In this section you will apply your learnings toward planning for C3. It covers the LA0: Process Learning Area.

2a) Design "Competition": Individually, create a storyboard for the frontend you wish to implement in C3. The storyboard must include at least 5 panels and demonstrate a user interaction with the frontend. Embed the picture of your storyboard in your journal file.

Next, show and discuss your storyboard with your teammate(s). The goal is to improve on your initially designed interaction through this discuss. Produce an improved version, and embed yours and your teammates' storyboards in your journal with a description of what you disucssed and improved. If you do not have a teammate or they are not available, please come to office hours to discuss with a TA and include the discussion points in your journal.

For an example on what a storyboard might look like see https://devsquad.com/blog/storyboard-design (scroll all the way to the bottom to 3 design storyboard examples)!

2b) User Stories: Individually, create at least 3 user stories that extend the functionality of your team's chosen frontend from the C3 specification and link to them from your journal. We encourage you to discuss and coordinate your stories with your teammates since you will implement all of your team's user stories together during C3, and demo them as a part of the oral discussion for Journal 3.

Each user story must be non-trivial and meaningfully contribute to the functionality of your frontend. The user stories you create form a binding contract with your lab TA about what you will implement in C3. Any changes to the user stories after submitting this journal must be negotiated with your TA; carefully consider the feasibility of your user stories by following the guidelines below.

User Story Guidelines

• Follow the Role-Goal-Benefit format with a clear Definition of Done that satisfies all of the INVEST principles. Ensure the story is detailed enough that another programmer, who is familiar with your codebase, could implement it directly from the description.

  • Identify the engineering tasks that are needed in order to implement the story in your project and include them as todo items within the issue. You may also choose to create separate sub-issues for these if it helps you decompose your tasks more easily!

  • Estimate how many hours the story will take to implement and set a realistic due date.

  • Post the user story as a GitHub Issue on your team's project repository.