- Develop at least 3 use cases and no more than 6 that you will implement for your MVP.
- These should be accompanied with low fidelity sketches of UI where possible to illustrate your meaning.
- They should take into account your tech stack and architecture diagram in points 2 and 3
- These should adequately describe the use case for the teaching staff to refer back to for marking the remaining assignments in this course.
- Use cases must be recorded in BOTH the team repository and the team’s profile in the LearnSoftware App
- Use cases must be approved by CSC491/2600 teaching staff to be sufficiently complex for the course and sufficiently simple for the MVP stage of your product.
- Design your tech stack.
- Under your team’s profile, you will find the “Stack & Decisions” feature
- Using that feature, fill out your team’s intended tech stack by recording “decisions”
- These decisions may include tools you did not choose, or tools from which you are migrating
- It is required that these decisions are updated by adding new ones when you change your team’s stack. This acts like a ledger of decisions.
- Based on your use cases, discuss the product requirements with all members of your team. Once that is complete, with the technical members of your team, design an intended architecture diagram
- The diagram should not be highly detailed as you have just started. You’ll be using this to help guide your work.
- It should include all pieces of your production infrastructure (emails, databases, caches, servers, email, background jobs, ML models, etc)
- Include a short write up explaining anything that is not obvious
- Using the GitHub Projects feature, GitHub Issues, and GitHub Milestones record and intended roadmap.
- The roadmap should include implementation of all pieces of your infrastructure, testing infrastructure, and development environment. All items in your Stack Decisions should be accounted for as well.
- Setup a roadmap. The roadmap must go past the end of the term. The roadmap can include as much detail as you want with the following conditions:
- Pretend like you are planning a company, not a class project
- Must include your immediate next steps (short term up to end of the next month), medium term (up to 6 months in the future), and long term (6+ months).
- Must include plans to perform user research
- Must include low-fidelity plans for a launch date
- You fill in the gaps. Be careful not to go too detailed as we have limited knowledge still.
None of this information is set in stone. Provide a basic insight into your initial thought processes, change the repo and Stack Decisions as these insights evolve throughout the course.
An architecture digram can be made in many different applications. Some common ones you’ll probably come across are LucidChart, Google Drawing, and MermaidJS (programmatic, not super powerful). When it comes to your diagram, I expect it to make sense and be grouped logically. It should try to indicate similar pieces of the architecture and make the paths between nodes flow smoothly.
Below are 2 examples of the same architecture diagram. These are real diagrams that we made for the Slack Application at GitHub.
|This diagram, while it has all the pieces, failed to group the different systems together. The data sources (3rd party APIs) are even on different sides of the diagram. Logos are all different sizes, and arrows aren’t as smooth as they can be.||This diagram has all the same information, however we have logically grouped the pieces into data sources, data storage, and monitoring. This gives the reader a clear indication of intent and architecture. This diagram made sure the logos were all the same size as size could indicate something like important, which we were not trying to do here. We also reduced the clutter of the arrows and removed all angles. This makes the diagram far easier to read and understand|
Your diagram should follow these same principles. You do not need to include pieces of your stack that don’t touch production (e.g. GitHub), but should include all tools that do (like monitoring). You can see an alternative format in the F2019 team Klutch (you should note this repo came from a previous iteration of this course, so some of the instruction was different. If you are unsure about something, err on the side of caution and use this term’s instructions or ask me).
What is the purpose of this assignment?
This assignment helps you plan out the main use cases of your application and scope down the amount of work you can realistically achieve. The architecture diagram and stack choices help you to choose a good path, and are exercises often seen in industry when starting new services.
We expect all CSC491/2600 students to actively participate and have thoughtful discussions around which technologies to choose. Best practices lessons should be watched first in order to effectively complete this assignment.
You must create a release on your repo. This will give us a snapshot in time and allow us to grade it. See release body criteria and example below. Assignments without a coherent release body that follow the instructions in this assignment will be rejected and marked 1 day late.
Assignments are always due at 11:59:59pm Eastern Time.
Second, you must submit the release on the LearnSoftware application. You can find the submission location here: https://learnsoftware.engineering/my_assignments
Release bodies must include:
- Direct links to all submitted files
- A paragraph explaining the progress your team has made, and contents of this assignment
- Any additional paragraphs described in the assignment
- Summaries of issues made by your team since last release
- Summaries of changes to your roadmap, architecture, or use cases (changes to use cases must be approved by the instructor).
Questions or Concerns?
- I don’t like part of this assignment
- File an issue on this repo
- I need to clarify something about this assignment
- File an issue on this repo
- I need to clarify a question or ask something in private
- Email the course instructor or email the professor via the email on the homepage / README
- Describes 3-6 use cases that provide adequate complexity to showcase the teams skills
- Use cases are well defined and recorded on the team's profile on the LearnSoftware application
- Illustrates UI with low fidelity sketches where applicable
- Teaching Staff will approve use cases after submission. Use case approval will not affect grade, but students may be required to re-write some use cases if not approved.
|Stack Decisions||Team describes the main technologies the team intends to use in the LearnSoftware application. For every technology, there is also a decision record.|
Each decision provides thoughtful rhetoric on why this is a good decision for the team, leveraging ideas and concepts presented in lectures.
|Architecture Diagram||Incorparting all parts of the technologies in your Stack Decisions and adding adequate detail inside of those technologies (e.g. don’t just list React server when there’s major components to list), design an architecture diagram in the software of your choice.|
Include it in the team repo as an image or a PDF.
Diagram is clean and easily followed. Text can be sparingly leveraged.
|Roadmap||Roadmap clearly captures in-depth details of the short term future (next week weeks), some light details about the medium term (towards the end of the term), and high level goals for the future (past the end of the term).|
Roadmap is defined in GitHub Issues and labelled using labels, milestones, or projects.
Includes plans for user research.
|Participation & Teamwork (Individual Grade)||Effectively worked as a team member and shared equitable work load during this assignment.|
Communication was regular and effective & acted in accordance with team principles.
- Use cases will be approved during marking. You will be required to update them after submission if the use cases are not deemed acceptable. This will not impact your mark, unless it’s clear that little thought/effort was put into developing the use cases
- Use cases that are not submitted in BOTH the team repo and the team profile on the LearnSoftware App will be docked 1 day. This may seem tedious - it is. A system has not been developed to easily sync these 2 spots yet, so the ask is that you duplicate information. This sort of thing is common in the industry though, so it’s good practice ;)
- We must see issues from all students in 491, and comments from all students in your team (454 included). Failure for a collaborative approach to making issues may result in your grade being affected
- Issues cannot be just a title or title/1 sentence body. It is required that effort be put into the issues from all team members to show you are all planning. Check out this guide for help. This rule applies to all assignments going forward.
This scale is used for each line of the rubric above.
|Outstanding||100% of pts|
|Strong||80% of pts|
|Acceptable||60% of pts|
|Insufficient||40% of pts|
|Unacceptable||0% of pts|