4. Proof of Concept

In this project, you will implement a Proof of Concept (POC) of your chosen concept.
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, 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 Adria 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.

• Coding guidelines: use all good practices from previous and current courses. Don't forget:

  • Create readable code
  • Write small functions
  • Ensure functions do one thing
  • Refactor code regularly
  • Pass Sonar quality checks

• The web client is a Vue.js application. The use of libraries to extend functionality is permitted; however, only limited technical support will be offered when choosing a library not covered in the curriculum.

  • The web applications needs to be build with Vue-components and the Composition API.
  • Docker:
    • Dockerize the client application by building a working Dockerfile.
  • CI
    • Build a gitlab-ci file that:
      • Publishes the source code to Sonar for quality checks
      • Dockerizes the client application and pushes the image to the GitLab Docker registry

• The server is a .NET 8 solution which uses minimal Web APIs to provide the necessary communication with the client.
  The startup project is written in a predefined structure.

  • Students must work within this structure. No boilerplate code can be removed.
  • Tests: Only test the application layer and domain layer.
    • Develop tests as you write the code. Adding them as an afterthought is pointless and a waste of valuable resources.
    • As usual, we will be integrating SonarQube for automated code quality checks, for both client and server code.
      • Coverage: > 95% (aim for this target)
      • Bugs, vulnerabilities, code smells, duplication: Sonar must pass
  • Docker:
    • The database of the server must run in a Docker container. Use the provided docker-compose.yaml file to start the database.
    • It must be possible to dockerize the server application. A working Dockerfile is provided. Adapt this file if you change the project structure.
  • CI:
    • Extend the provided .gitlab-ci.yml file to build and push the Docker 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)
  • 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.

Some of the topics are class-taught, others require self-study. Take a look at the tutorials of the module Web Technology

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