Reports
During the semester there will be one (1) written report. You may also choose to summarize content in a book instead of writing one of the research papers.
Sample Reports
- Functional Programming Design Patterns for OOD Programmers.pdf: A well done report with good formatting and argument development.
- OWASP Top 3 Security Risks - Haiti HHA: A very well done overview of the issues, investigation of the system, and analysis of the results.
Topics
First Report: Professional Responsibility
If this is your first time taking CMPT 415/416 with Dr. Brian, then your report must be broadly centred on professional responsibility. There is some flexibility about how you craft your report, and what you focus on. You should tie the topic back to the project you are working on to keep it grounded in something that is specifically applicable to your work this semester (as opposed to a general report written by some AI system). Some suggestions include:
- Code reviews: What role do they fill; what makes a good code review; how to improve ineffective code reviews.
- Design for testability, with specific reference to an area of the project that needs more testing.
- What factors lead to the success or failure of a projects created by students as part of a university course for external customers (such as non-profits).
- Look at security and the techniques the project uses to ensure security. Look at the the OWASP Top Ten list of security vulnerabilities and see how they apply to the project, and what the project does to mitigate these risks.
- Look at privacy and the laws around privacy where the product will be used. What techniques should be used to preserve privacy, and how could the product be improved.
- Look at reliability of web systems, and consider the reliability of the system you are working on. What level of reliability should it achieve? What level does it achieve? And how can it be tested and improved? Suggest what practical steps should be taken to improve its reliability.
- Test the security of the system in some way, such as penetration testing, cross-site-scripting, or the like. Write about what the type of tests performed, how the system handled those tests, and what changes are needed to the project.
The goals are for each student to...:
- learn about some implications of professional responsibility which interest them.
- analyze their project for how it satisfies (or not!) some aspect of professional responsibility.
- investigate and analyze the details about the technologies the project uses for this purpose.
Hopefully, this makes us better developers, and makes the projects better! For things you realize need fixing or improving, please create an issue in GitHub! If you find issues with the project, try and offer concrete suggestions/steps for improving the project.
Here are some places you might start
- Use Google Scholar for your searches to find peer reviewed articles as much as possible.
- Investigate your project to see what it does, and how it might fail.
Not your first report
If you have previously taken CMPT 415/416 with Dr. Brian, then for your report you can pick virtually any topic; you must clear your topic with me before write your report. Some ideas include:
- theoretical (ex: improved plain-text data compression algorithms, improving the reliability/security of a web application)
- project context (ex: effectiveness of e-health systems in developing countries)
- experimental report (ex: performance analysis of the system under different loads)
- project specific (ex: in-depth guide to how the deployment pipeline works, or user manual for the web app)
Your topic must not be:
- Summarizing information that would be found in a single textbook (ex: comparing three sort algorithms)
- Based mainly on subjective observation (ex: describing the personal experience of joy as you help someone debug a program)
If your report is useful for the project, please add it to the team's Google Drive folder.
If you like, one of your reports may be a summary of some computer science related book. Your report should summarize in the area of ~150-250 pages of the book. Please clear the topic with me before hand. Your summary should be at a reasonably high level of ideas learned, and presenting some of the justifications for those ideas. You should be mainly writing in your own words, but should also quote the book at least some times.
Format
LaTeX
You must write your reports using LaTeX and submit it as a PDF. Some suggested templates include the IEEE template(https://www.ieee.org/conferences/publishing/templates.html); however, other templates will work as well. Report must be in 2 columns.
Expected length
- 2500 +/- 500 words; fewer if features numerous figures or if it is a polished user-facing document such as a user manual.
- No real hard-cap on maximum length. If the topic you are covering requires longer, that is fine.
Citations
Research reports must cite external sources.
- You may use any citation style you like, and I won't be a stickler for getting it exact: as long as it's clear.
- I suggest use of the IEEE style where references are numbered and in-text citations look like [2, 3]. I'm not going to sweat the exact format of the bibliography at the end.
- When applicable, favour academic sources (Journals, text books) over other sources (blogs, company websites, news stories).
- Suggest Google Scholar for finding academic references.
- If your report is a user manual discussing just our product, you likely won't be referencing external sources, but will likely want to direct the user to quality external resources as needed (such as how to install an Android app). I would expect 2+ extra resource links.
- If your report is a guide, then having ~2 references is reasonable, plus links to external resources as applicable.
- If your report is discussing a topic which is covered in research, then you should have 4+ on-topic references.
- If presenting your own new ideas, clearly state that it is your idea. You should see if your new idea is supported in the academic literature.
- It is fine to more heavily rely on some sources than others, and it is fine for some of your sources to be non-academic sources if applicable for your topic.
Generative AI / ChatGPT
Overall, it is OK to use these tools to help you get started with ideas, or edit your text to improve your communication (much as a human editor would do). It is not OK for them to be used to skip in depth research or write any part of your content (the tools are not your co-author!). Unpermitted use of these tools is considered academic dishonesty, and will likely result in a mark of 0 on the report and a academic dishonesty report being filed with the university.
Generative AI, large language models (LLMs), and natural language processing (NLP) tools, such as ChatGPT or Grammarly, may be used for:
- Providing some broad suggestions about what points or ideas to research for the report.
- Providing short summaries of articles to see if reading part or all of the original article is useful. You may only cite papers for which you have read the original text (or a machine translation of it).
- Editing text for spelling and grammar.
- Minor changes to your wording to improve the clarity or flow of ideas.
These tools may not be used for:
- Generating or writing content of the report.
- Converting a bullet point list of ideas and facts into paragraphs for the report.
- Generating citations for the report.
If you use one of these tool, you must include a sentence or two at the end of your report stating how you use it. This is similar to requirements for submitting articles to academic journals.
Marking
-
20% Writing style, clarity, grammar.
-
80% Content quality, length.
-
If you are writing a report on a topic, you should use a formal writing style. OK to match the writing style to the document's target use (such as having the user manuals more friendly).
-
Marking is mostly done on the quality of the report overall and how well it meets the requirements.
-
Marks will be deducted for writing issues such as grammar or clarity of writing.
-
Do not include your student number in the document: it may be used by future teams as a reference and so don't include private information.
-
A very good report with nothing wrong is expected to get a grade of 90%. Above 90% is reserved for exceptional work.
-
Late policy for reports: Try to hand them in around the "due date"; however, within 10 days is fine for no penalty, you don't even need to ask me for permission. If it's going to be later than 10 days, please email me with your plan for getting it submitted.
Include in Project Docs
- If your document is of use to the team / project, ensure it gets mentioned in the project's documentation and included in the shared drive so that others may learn from it!
- If it's not of use to the project, no need to include it.