Suggested Schedule for your Build

It may seem like you have a lot of time to build your application - it isn’t a lot. This document aims to suggest a timeline to keep so you aren’t up until 5am the week prior to submission. Neither of us want that and it can be avoided with a bit of planning.

WeekWhat you should get doneMilestone
1Teams should be formed and selected. You should start talking about the problem and deciding on a projectTeam Selection
2Projects should be decided by end of this week. Pivots are still possible after the fact. Team should be finding normals and team principles should be adoptedTeam Principles
3Team will still be finding normal cadence of work. Team diversity assignment will force the rest of that. Project path should be decided this weekTeam Forming / Project Decision
4Hello World Application created based on project path. CI and tests setup (yes I know this is for A5, but I suggest doing it now. It’s easy to start early, harder to start later!). General A3 work startedGeneral Project Setup
5With the general project setup, you should focus on the lowest level needs first. For example, start your ML/Heuristic Model if applicable. Otherwise start understanding how to breakdown your problem. Form and in depth roadmapStart project, Roadmap formed
6Reading week. This week can be spent mostly as a break. Consider doing your UX research this week though, this should not take more than an hour or 2 of time to interview and summarizeUX Research
7Complete an basic layout of your project. An basic skeleton of the app should exist (e.g. login, API, dashboard) but not be functional. It’s expected to be all static at this pointStatic Project. Slowly completing roadmap items
8It’s go time. We’re after reading week and into the final stretch of the semester. You should be completing V1 your data models now, if applicable. Your application should be launched online, released as a mobile app, etc. Basic functionality should exist.Launch App, complete some basic functionality
9Assuming you have a couple use cases, swarm to complete one this weekComplete a use case
10Assuming you have a couple use cases, swarm to complete one this weekComplete a use case
11Assuming you have a couple use cases, swarm to complete one this weekComplete a use case
12Final touches. Bring together your main use cases and make sure they all work together. Ensure your test coverage and code quality is adequate. Video Presentation for the finalFinal Touches

Major Milestones

Suggested Work Format

While you have multiple people on your team, it is not advised to simply split the project into 2 parts and hope they fit together. If part of the team is unable to finish their part, you’ll be stuck with a half finished product that doesn’t function. Instead, if you split the parts up and work together you will be able to pick up the pieces of something were to happen.

This isn’t to say that you need to be an expert in all parts of the app, but you should be reviewing code and helping where you can.