Proof of Concept

In this project, you will implement a Proof of Concept (POC) of your chosen project.
The POC should demonstrate the core functionalities of your application, showcasing its potential and feasibility.

Remember, the POC is only a small part of your overall concept.

POC Scope Determination

At the end of week 5 TODO, you'll need to submit a POC scope suggestion by means of a feature list proposal.

The jury will help you align objectives and definitively set the scope for the POC.
During development, always consult with your group coaches to modify the POC scope, whether broader or more narrow.

No modifications to the scope are allowed without the explicit consent of the group coaches!

What do we expect?

You will be given four repositories on the http://gitlab.ti.howest.be space:

• A documentation repository
  All documents, links, diagrams, etc. related to the project should be here.
  There is a readme.md that contains all the general information and links. A template for this document can be found in the Resources section.
• A client repository
  The web client application connecting to the server.
• A server repository
  The server application containing the business logic and a web API
• A test environment repository
  A Docker solution that is able to run your entire solution

These repositories will hold all deliverable content, except for the daily standups, peer evaluations and retrospections (these are submitted on Leho).

All implementations must implement the mandatory requirements and customizable requirements as described below.

Mandatory requirements for all projects

The following are mandatory requirements that must be implemented in your project.
See the subsections of each repository (client, server, test environment) for specific details.

Not all mandatory topics are taught in class. You will need to do some self-study to implement them.
Don't worry, the POC scope is only a small part of your overall concept.

• The server adheres to the coding rules and principles thaught in the module OOA&SD
  • Must be implemented with .NET 10
  • The server must achieve 80% coverage (also branch coverage)
  • No sensitive data should be stored in the source code. Make use of dotnet secrets.
• The web client is a vanilla JS client or built with a front-end framework (Vue, React, ...).
  • The use of libraries to extend functionality is permitted; however, only limited technical support will be offered for the client.
• Docker:
  • Dockerize the client by building a working Dockerfile.
  • Dockerize the server by building a working Dockerfile
• CI
  • Build a gitlab-ci file for both the client & server that:
    • Publishes the source code to Sonar for quality checks
      • This is only for the server, no code quality checks are required for the client.
    • Dockerizes the application and pushes the image to the GitLab Docker registry
• The test environment is a Docker solution that is able to run your entire Adria solution. It should at least contain:
  • A database container (MySQL/PostgreSQL, ...)
  • A server container
  • A client container
  • A network to connect the containers
  • A volume to persist the database data

Customizable Requirements

In addition to the mandatory requirements, you need to implement some other technologies/principles listed below. Customization should fit the needs of your application.

Caution: proper feature integration into the product is required!
Again, don't add these as an afterthought, but as a useful contribution to your product.

You need to complete 5 points worth of topics including at least 1 topic with a weight of 2 points.

Any deviations need to be consolidated with the group mentors.

Topics

Publicly Accessible API

Document your publicly accessible API according to the OpenAPI specification.
This will be taught in the "Information Systems" module.

Remember that you are documenting the entirety of the concept here.
The objective is to consider which aspects of your solution you will expose to the public and how.
Not all endpoints or channels written in the API specification will be implemented. The implemented endpoints depend on the POC scope.

Endpoints not belonging to the POC must return a 'not implemented' error.

Bonus grades

Projects who go the extra mile will be awarded bonus points.
This is a scoring measure that is applied on top of the already existing score, ignoring any penalties that may be in effect.

Bonus grades will not be quantified beforehand, as they strongly depend on the level of implementation (detail and quality).
The exact amount will be determined ad hoc.

We'll be allocating bonus grades for:

• Teams who manage to get their POCs to work together (by using OpenAPI spec integration or based on the asyncAPI spec)
• Usefully implemented client side testing
• Awesome factor