Final Deliverable

This is the final summative deliverable of your project:

1. Final version of your code pushed to your GIT repositor(ies), with the final functional release tagged as FINAL.
2. Demo video of your project’s final features pushed to the course Gitlab repository, showing it deployed live in its expected environment.
3. Documentation for your project pushed to the course Gitlab repository.

Documentation

Create documentation that contains all the information someone needs to  maintain and upgrade your app — it should reflect the current state of the project, not an idealized or bug free version. It is fine to copy, and update, from versions of documentation on your Wiki if it is relevant.

1. At the top level of your repository, include the following basic files:
   • Icon.png square image that serves as your project’s logo
   • README.md file that includes (real-world guidelines):
     • your updated Executive Summary to explain the project’s purpose
     • its dependencies, such as other repositories or other technologies that host other parts of the project
     • instructions for how to deploy all parts of your project such that someone technical (possibly your future selves) can reproduce your app from scratch
   • RELEASE_NOTES.md file that lists
     • your project’s current functionality, including any known bugs, assumptions, or limitations
     • the platforms (OSes and their versions) it has been tested on
   • BACKLOG.md file that lists future features you would like to implement. If you have an active backlog on another platform, it is fine to copy those items over to this file.
   • LICENSE.txt file that includes the license text your team chose for the project
2. Within Gitlab, in a separate folder called doc, include two kinds of documentation for different audiences (these may be multiple files in different formats):
   • App Maintenance Documentation. for technical IT managers responsible for the installing and maintaining the running app in the form of:
     • install instructions, especially requirements or assumptions about the target environment
     • address ways to update or change key non-programming components of the app, such as database information, data files, resource links, phone numbers, server addresses, etc.
     • list all open source tools or libraries your project uses, their versions, and links to their associated licenses

     Do not forget to include necessary account and password information!

   • Technical Documentation. for programmers that need to modify the app in the form of comprehensive project code design documents, including:
     • in-code comments (especially your names!)
     • overall architecture design (you can generate a diagram from your code or this one)
     • database schema (you can generate a diagram from your database)

     Remember to include justifications for your primary design decisions!