Assignment 7 - Software

This is the final project for the course. You will deliver a functioning proof of concept.

• Initial Requirements
• Submission
• Questions or Concerns
• Rubric

Initial Requirements

1. Code
   • All code should be easily accessible in repos under the DCSIL organization
   • All repos should be linked to your team in the Learn Software App (Add a new repo here.)
   • All of your repos have been added to Code Climate. Your repo should maintain a minimum “B” average in “maintainability”.
     • This isn’t the best metric to ensure code quality, and in practice, you would use this to help inform a decision, not make a decision. In this case, checking a grade is a simple way for the teaching staff to gauge code quality without spending hours reviewing each repository.
2. It is required that the software be easily accessible:
   • If it is a web app, we should be able to visit a URL. Provide the teaching staff credentials with which to log in, if necessary
   • If it is a desktop app, we should be able to install it with the Mac/Windows Installer. We can support Mac and Windows applications, Linux-only applications will not be accepted.
   • If it is a mobile app, we should be able to install it with an iOS/Android installer. We can support iOS and Android to mark, there is a doc that can help here. Note: iOS can be a pain to deploy, as you need a certificate. Please record a video of the app in use if you do not have a certificate to available.
   • If your app, or part of your software, does not fit in one of the above categories, then please speak with the instructor before submission
   • If your app is not easily accessible, then you will receive a 0% for the evaluation of the running software
3. There should be tests. The tests should be sufficiently covering your code.
   • You must implement code coverage on your app and run it in CI.
   • You must upload to Code Climate as well. See the linked doc for log in details.
   • You must implement the code coverage uploading and code coverage in your CI.
4. There must be CI, Production, Exception Logging, and any requirements from previous assignments.
5. The application(s) is/are mostly dynamic. An MVP has been delivered and the main functionality has been entirely implemented. Very little is static (other than docs, and other content that needs to be static).
6. A demo video is provided to tell the teaching staff about the main flows of the app. Guide us in testing the apps out and seeing the amazing work you’ve done.
7. The application looks good and has a coherent layout and adheres to at least the WCAG 2.0 checklist Level A in this link.
   • Use this checklist to help you make sure you adhere to all requirements. It is also required
8. A short video (~1.5 to 3 min) with a short write up (some bullet points explaining the video) has been provided that indicates the flows that have been implemented.
   • The short write up should be adequately long enough to tell us what to expect and highlight what you think is important. It should be short and concise enough that we’re not bored reading it or lose understanding. (Tell a good story). Feel free to include images (and flow charts!!) if you feel they will help.
   • The write up should be a markdown file in the repository or the body of the release. If it is a markdown file include the path in the release body - While the video doesn’t require audio, I should be able to watch and follow along on the video so audio or text overlays are a must.

Dynamic Marking Guidelines that the teaching staff uses are also provided on the assignment page in the LearnSoftware application for reference. The teaching staff’s judgement is absolute, however, and these guidelines are only for reference.

Submission

You must also create a release on your repo where the code is located.

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.

The release does not need to include pull requests or commits from every member. The body does not even need any content, just ensure it is there and appropriately labelled.

Assignments are always due at 11:59:59pm Eastern Time.

You must submit the release on the LearnSoftware application. You can find the submission location here: https://learnsoftware.engineering/my_assignments

Release Body

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

Rubric

Notes

Things you’ll lose marks on

• Application
  • If you do not have a login system, you will lose 50% of marks for the application system
• Application
  • If you don’t provide credentials to log in and/or you don’t provide, you will be deducted all application section, design/accessibility section, etc as we cannot verify. Providing the Credentials/URL after the fact is considered 1 day late
  • If you don’t have Sentry hooked up and at least 1 exception sent, you will lose 5 application marks.
  • If you don’t have logging setup, you will lose 5 marks
• Test Coverage
  • Thresholds:
    • 60-65% = 10pts
    • 55-59.999% = 8pts
    • 50-54.999% = 5pts
    • < 50% = 0
  • If your application is not uploading test coverage to Code Climate and the DCSIL App, it will be considered to have a coverage of 0%
• Operational Excellence
  • There are a lot of checkboxes (CI, Exceptions, etc). These should all be done from previous assignments, but they should still be working. That said, the value of the section is small. This means that if any of the systems don’t work, you may lose most or all of the marks for this section.
  • For example, if bootstrap isn’t working on any operating system you will lose all marks in this section, or if you are missing exceptions you’d lose at least most marks in this section at the discretion of the teaching staff.
• Dynamic
  • It’s ok if you seed your database with static content from an ML model or something, it’s not ok if you hard code an HTML table or something. In the former, you would substitute real data and it would “just work”, in the latter nothing has been done besides making a UI.
• General
  • If you have n parts of the app (e.g. frontend, backend, data pipeline, etc.), regardless of if they are in different repos or just different folders, each section will be worth roughly (total marks worth) / (n parts of the app) for each part of the app.
  • If your code is not under the DCSIL organization, it will be considered as non-existent. You will receive a 0 for that part of your codebase.
  • If you do not provide login credentials for the application (or an easy registration system with instructions in the GitHub Release), you will receive 0 for application section
  • If your application cannot be easily run and evaluated (hosted on an accessible URL, mobile app installable, desktop app installable, etc.), it will be considered incomplete and receive a 0 on all parts that require us to run the software.
  • Failing to adhere to any of the requirements, even if it’s just “record the URL in a certain spot” will result in reasonable penalties. These kind of tedious tasks are in place to help the teaching staff mark, but they’re also going to show up sometimes in companies (so get used to them haha). We appreciate your help in making these assignments more streamlined to grade.
    • Some examples would be:
      • a point or 2 per URL, but we will default to assuming that system/tool/whatever doesn’t exist at first and mark accordingly
      • failing to include a service would be somewhere in the ballpark of 5 marks per service, but may impact other sections if that relies on it
• Design and Accessibility
  • Default Styles: The design doesn’t need to be state of the art, super modern, and feel like it’s been designed by a star designers but it does need to look decent.
  • Use a consistent colour scheme (recommend looking at a site like https://paletton.com, docs on this in the DCSIL app).
  • Use a framework/template like one of these, or design something that is coherent.
  • If you use something like Material UI or Bootstrap, you’re using components consistently and aren’t relying on the default colours
  • We want to give our users a nice experience, not confuse them. For example:
    • if you use a certain colour for indicating some state… use it consistently
    • if you use a component for navigation, use it consistently, don’t suddenly change what the user can expect on a page
    • if you have a standard layout, stick to it
    • Don’t suddenly shift a user’s expectations without really good reasons
  • DO NOT use only colour to represent items in graphs. Use overlays, icons, and more. Colour is not accessible to people with colourblindness, low contrast, etc. (do not use just red and green, for example, use icons too)

Rating Scale

This scale is used for each line of the rubric above.