Team documentation (research & technical report)

[canvali]

• [ ] An introduction that explains what your product prototype is, why the product is important and innovative and what problem it solves. - MAYA
• [ ] Justification for your prototype implementation choices, what you chose to implement, what you mocked up to illustrate functionality. Why you made the decisions you made. - MAYA
• [ ] A justified explanation of the tools and technologies you used and why these were the right ones to use. - LUCAS
• [ ] Position your prototype within the competitive landscape and justify your choices based in sound research. - DAVID
• [ ] Detail the team project management and collaboration processes you used and how you structured your work to achieve project goals. - ALI
• [ ] Detail the ethics, security and data privacy considerations relevant to your team project including a matrix of your identified risks, impacts and mitigations what eventuated and a reflection on what you would do in the future to limit these risks. - ALEX
• [ ] Detail your evaluation approach and reflect on what you learned from stakeholders. (see Ali for interview protocol, use previous diagrams, etc.) - DYLAN
• [ ] A conclusion that summarises the main points from the technical report with recommendations for future development of your prototype. - ALEX
• [ ] A consistently formatted bibliography of relevant reference material and attribution of all external sources used. This is expected to be of a higher standard for DECO7381 students. - ZOTERO (USE IEEE REFERENCING)
• [ ] If you have used ChatGPT, Copilot or equivalent, you team document must contain an appendix that lists all your prompts.

[canvali]

Mashuda:

We are using README in a general sense as the first thing someone looking at your project should read to get an idea of what is in your project submission (Bill of Materials). This can be a software, embedded systems, or hardware design project and what you put in this first file to read depends on your specific type of project, but it will also be the first thing your markers will read in the course. Therefore, it should briefly and concisely explain what is in the project. In the case of a software project, it would typically be a brief intro of the project, files and how to compile and run the code. In the case of a design project, it might include a brief into to the project, an outline of the files that contain your designs, diagrams etc in the project submission. In the case of an embedded system, you would give an intro to your project, the files containing your system designs and you might also have some embedded system code. Overall, your README needs to explain briefly what is in your submission files. By helping your markers with this overview to understand what is in your submission you contextualise what they are looking for them, but this is useful for anyone looking at your project without detailed knowledge of the specific project (eg. someone new to the project, or in the context of the course a second marker). The below link is from a software project context and I'm expecting teams to provide a text or Word file not markdown, but the article has some useful information on what makes a good README and a sample template that might be helpful. Remember though the README is not graded, it is in your interests to help your markers gain an overview of what's in your submission. https://www.mygreatlearning.com/blog/readme-file/#:~:text=The%20Readme%20file%20is%20often,about%20the%20patches%20or%20updates.

[canvali]

Mashuda:

Yes you do need to justify in your team documentation why you have designed the application in the way that you did, you may have used standards, how was your interaction storyboarded etc...

Yes, you do need to justify your decisions, this needs to be backed up by literature. There are two kinds of research, one is to back up your decisions and the other is to make clear the competitive landscape of other similar products on the market. For example, for a project that has a graphics component you might have decided to use unity rather than unreal - this might be justified because it has some specific assets that you needed to build upon that are relevant to your application (your'd reference these and justify the decision (ie. explain why it was a good decision to make). Now, lets say for argument's sake that you are developing a running app, there are plenty of other apps on the market for runners ( eg. Komoot and various others https://www.tomsguide.com/round-up/best-running-apps). Researching the competitive landscape is about determining what exists and how they compare with yours, ie. what about yours is new compared with everything else.

Yes you do need to bring up competing projects, you don't have as much space to detail this compared with DECO7381 so you aren't expected to do this to quite the same depth but yes, you do need to do this - its important to be aware of similar solutions and their relative merits. If there are no similar solutions out there then that is also ok, but you need to demonstrate that you know this.

at some point we probably need to go right back to the start of semester and compile all our sketches/planning/rationales into proper storyboards, user scenarios, etc with justification against design principles. can draw from our 2500 report?

[canvali]

Sanjana:

As for the competitive landscape thing - research existing platforms out there to manage schedules with families in mind. It's about trying to justify why your project is different from other existing solutions. Are any of the things that you've taken inspiration from useful to consider here?

need to "position our prototype within the competitive landscape". maybe compare & contrast against gcal, life360, whereabouts clock - anything else?