Project context within the curriculum

This project is the full and only assignment for the semester 3 module Analysis and Development project (6 ECTS). No retake is possible for this module.

This document is the single point of truth for the project. All important information about the project can be found here. From the project overview to the deliverables of the project. This document is the place to be. Please make sure you read this document carefully before starting the project.

This is a group assignment. You’ll be assigned into a predetermined group by the lecturers. Changing groups during the course of the project is not possible.

If you still have questions after reading this document, please contact the coaching team.

Planning overview

Semester planning

The project starts on Monday, September 21nd 2026 and ends on Friday, December 18th 2026 and is divided into different sprints.

Sprints

There will be a minimum of 4 sprints (=milestones) during this project.

You will need to create these milestones YOURSELF for your group in gitlab. Do this immediately (at the start of the project).

You CAN create more (intermediate) sprints if that works better for your group (especially during active development) and/or if your group coaches demands it.

Each sprint will have one or more deliverables.

Project day/week planning

Project work always occurs on Monday as scheduled on your class roster.
All students from each group are expected to be present at each session (not later than 9:00 arriving AND not before 16:00 leaving). You have a lunch break between 12:30 and 13:30.
During the project weeks you work from Monday until Friday (same hours as on Tuesdays).

There are no exceptions! If you have a valid reason to not be present, you need to communicate this with your group coaches and ask for permission for your absence at least 3 days before the session (except in case of illness or injuries, of course).

Topical experts will be availabe in the morning from 9:00 until 12:30.

A detailed planning can be found in the detailed planning document.

Additional classes

To assist you with creating all the required documentation, we will be teaching some classes within this course. Attendance is mandatory.

Most of these classes occur on Tuesday afternoons in the first five weeks.

The planning is as follows:

If there are no input sessions or the session is finished, you are expected to continue working on your project. There are no exceptions! If you have a valid reason to not be present, you need to communicate this with your group coaches and ask for permission for your absence at least 3 days before the session (except in case of illness or injuries, of course).

Detailed Planning

A summary of the project planning is listed below.

Any modifications to the schedule will be communicated through this document.

First five project days

First project week

Next four project days

Second project week

Coaching

Project leads

• Matthias Blomme (MBL) - (mailto:matthias.blomme@howest.be)
• Machteld De Groef (MDG) - (mailto:machteld.de.groef@howest.be)
• Thijs Martens (TM) - (mailto:thijs.martens@howest.be)
• Frédéric Vlummens (FVL) - (mailto:frederic.vlummens@howest.be)

Although all the teachers are regarded as project leads, it's easier to focus all general questions to one person Thijs Maertens

Keep technical questions to the topical experts, and non-technical questions to your group coaches.

Topical experts

The topical experts will handle your technical questions in their area of expertise. There will be at least two topical experts available every Monday from 9:00 till 12:30. Make sure you plan your questions carefully, as not every expert will be available at all times.

Group coaches

Every group will be assigned two group coaches, who will monitor the group's progress throughout the semester. The group coaches are your point of contact for all non-technical questions. Disputes, conflicts,... also need to be reported to the group coaches. If there is a group member that does not perform adequately, this information needs to be submitted timely to the group coaches, so that they can attempt to remedy it. 3 weeks before the project ends is NOT timely.

Summon by group coaches

The group coaches will summon the group on a regular basis to confer. You can interchange ideas, planning, and possible approaches. If there are questions that are too technical, the coaches will relay them to a topical expert.

A summon by the group coaches is a mandatory moment on which every group member's presence is required. Failure to comply will negatively impact your score. The summoning can happen at any time during the week from Monday to Friday between 9am and 4pm, it does not have to be on the allocated project working time. You will be notified at least three hours prior to its occurrence.

Evaluation

Scoring calculation

When executing a project, any aspect must meet minimal standards. This means that a very low score on any of the deliverables will impact the project vastly. The scoring principles of this course are designed so that your final score tends towards the weakest link, i.e. the one with the lowest score of all different items that are scored. Weakest link scoring would be: "your individual final score can't be higher than the lowest score on any of the items".

Your final score is determined based on the different number of deliverables, using the following distribution: [TODO: verify distribution]

• D1 Business Case including financial analysis: 15%
• D2 Project website: 5%
• D3 Analysis document: 30%
• D4 POC: 35%
• D5 Project work, peer evaluations and retrospections: 5%
• D6 Presentation for investors jury: 10%

Factors influencing the final score

There are many factors weighing on the final score for this module. Each part of the assignment is scored according to specific criteria. This score can be influenced by intermediate as well as end results of a certain portion.

A group score will be determined according to the principles listed above. From this group score, the individual score will deviate in positive or negative manner depending on the following factors.

Final customer pitch

[TODO: update to new vision of pitch] The presentation is an individually graded component, with the presentation itself as a baseline. Each group member will be scored individually for his performance during the presentation, measured on a number of factors.

Conduct and contribution

Your general conduct and contribution throughout the semester is monitored by the group coaches as well as assessed by your peers. Deviations, positive or negative, will impact your final individual score.

Inappropriate conduct may be a reason for immediate group exclusion (resulting in zero score for this module). The group coaches may come to this conclusion at his/her discretion, supported by the majority of the other group coaches.

Extreme sanctions

Group exclusion will be immediate in one of the following cases:

• Unprofessional or inappropriate conduct (see previous paragraph)
• Repeated signalling from group members to non- or malfunctioning in the group, either on a technical or quantitative level of you failing to meet generativity (see further for detailed procedure).
• After a second unexcused absence, on a rostered moment, a coaching moment, a presentation moment or any other project related moment where presence was mandatory. You may ask for an excuse for absence to your group coaches, and you're only excused if you have permission to be absent.

Exclusion from the group results in a zero score for the module, which has no retake!

Aim for generativity

Each student will be granted a generativity score. This score is used for your personal final score. The generativity score is based on your team work, helping others, communicating problems in time, and so forth. We expect everyone to behave as a team player: you need to aim for generativity (certainly watch the talk to understand what we are talking about). Generativity is not your personal productivity. On the contrary, it's about how you influence the productivity of others around you.

In the rare case of clear and obvious signs of highly negative generativity one may be excluded for the project, resulting in an individual zero score.

The procedure for exclusion is:

1. The team members have informed you that they are not ok with your team work and why. The group coaches are informed about what has been discussed and both parties confirm that this has happened. A plan of action to improve within a defined time frame is set up in the team and this is shared between all team members and the group coaches.

2. If there are no signs of substantial improvement within the defined time frame (confirmed by all other team members and the group coaches): a first official warning is given and the time frame is extended with one more week.

3. If there still are no signs of substantial improvement within that week (confirmed by all other team members and the group coaches): the student is excluded from the project (=zero score)

4. If there was improvement, but it lasts only for a certain period, and the generativity decreases again (confirmed by all other team members and the group coaches): a second official warning is given and there is one more week to catch up

5. If once again there are no signs of substantial improvement within a week or the improvement is again only temporary (confirmed by all other team members and the group coaches): the student is excluded from the project

6. The final score of the remaining group members will be adjusted accordingly, depending on the severity of the case and how negatively the incident has impacted the group work and project progress

Concept

Conceptual requirements

Your application needs to contain all conceptual requirements below. One requirement may take a larger focus than another, yet all are imperative. Failure to comply will result in a failed project!

Carefully consult with your group coaches to assert compliance.

All requirements are specified as generic as possible to optimally serve your imagination. User stories (in gitlab, on group level) are ideal to organise the way you wish to meet these requirements

Requirements

All requirements that are essential for all projects are listed below.

These requirements are mandatory for all projects.

Concept choice process

Projects

Deliverables

This section describes all the deliverables you need to provide during the course of the project.

We expect all of the following deliverables:

• Business case including financial analysis (documentation repo) Document describing in detail how you'll handle the launch of your first product and how you'll meet solvency requirements.
  This should be a Google Doc based on the Business Case template document (see the Resources section), which you link in the readme of the repo.
  Details on the contents of this document will be handled in the input sessions "Business Case and documentation".

• Project website (documentation repo)
  Marketing website showcasing your company and launch product.Link and admin credentials are provided in the readme of the repo.
  This is a Google site.
  Details on the contents of this website will be handled in the input sessions "Business Case and documentation"

• Analysis document (documentation repo)
  Document describing in detail the full analysis of your first product.
  This should be a Google Doc based on the Analysis template document (see the Resources section), which you link in the readme of the repo.
  All necessary information about the scope of your product (concept / personas / user stories / feature list) are provided as well as the schematics (flow charts / C4 diagrammes /UCD / ERD ….) to describe the project.
  Clickable wireframes and visual designs documenting the extent of the project including user testing reports.
  Use the Ethical Decision Making framework to argument at least 2 ethical dilemmas.
  All this will span the full renege of your concept’s scope, which will be far more extensive than the POC implementation thereof.

• Proof of Concept (POC) (client & server repo)
  Proof of concept of the software system with a working version of the project. Scope determined after approval of feature list proposal.
  Provide also a publicly accessible API documented by an OpenAPI and/or asyncAPI spec for consuming your application.

• Project work, peer evaluations and retrospections (Leho & in gitlab)
  Every project day starts with a daily standup.
  All your project management epics(=user stories)/issues/tasks (both technical and otherwise) must be created and assigned in gitlab. Each Team member will log their work time they perform under the correct issue.
  Throughout the semester, we will implement various peer assessments and reflections. These will be collected on Leho.

• Presentation for investors jury (documentation repo)
  Final presentation of your work, where you'll convince a jury to invest in your product.

Warning

Omission of a single deliverable will result in a failing score for the entire module.

Business Case

General

The business case document consists of several parts, which are detailed below.

Although you are allowed and even encouraged to use AI to finetune and flesh out your ideas, please do not hand in one large document purely AI-generated.

The idea is that you think about your business case and describe the outcome of that process as part of this deliverable.

Make sure to keep all prompts and add them as an appendix to your business case document.

Mandatory contents

D1.1. Your concept/product/service

Here you will detail what your concept is: what are you going to do and build (or provide as a service)? Make sure to include all the items specified in 2.1. Conceptual requirements (yes, you need to cover everything we’ve listed there). Don’t be restricted to text for this. Illustrate with charts, figures, whatever you need to get the message across. Also take into account the 2.2. Context restrictions.

Make sure your concept stands out!

In this section you should also explain how you came up with the idea: a short summary of the design thinking exercise.

Include links to both your Miro-board and your initial pitch (video). Make sure everything is accessible to us.

D1.2. Scope, user stories and (non-)functional requirements

Describe what your product's scope will be and also what it will not be.

Include buyer personas to think about and reflect on your product and determine the scope.

Although you will define your various user stories in Gitlab, include the five main user stories in this document and determine and describe the resulting (non-)functional requirements.

D1.3. People

In this section, describe the organisation of your company in more detail:

• Who will do what within the company?
• Will you be working with freelancers?
• Are you going to look for additional employees in the near future (or maybe say goodbye to specific employees after a specific period of time)?
• How are you going to handle all of this?
• ...

Reflect on the mock LinkedIn post and job vacancy ad you have created (make sure to include them in appendix): why did you choose those functions and redact them as such?

D1.4. Risk management

Setting up a project and/or enterprise brings with it certain risks. You will define the most important risks you might encounter and how you will handle/mitigate them, should they occur.

In your risk management plan, you will define the various risks associated with your project and how to mitigate (reduce) or eliminate them. How can you avoid the consequences of said risks?

Adria remains a perilous environment (e.g. toxic atmosphere, ...). Should the IT systems be corrupted, there might even be a risk of loss of life. Therefore, you should think carefully about this aspect of the project.

You will need to define at least two scenarios that might result in a security breach and one that might result in a system failure.

What data could be stolen? What systems could be impacted? How will you handle this?

You will also need to identify 2 additional risks, bringing the total of risks to review/build an action plan upon to 5. Per risk, identify its severity, impacts, action plan, etc.

Use the tools and templates provided as part of the Risk Management class to do so.

D1.5. Strategic partnerships

Your Adrian enterprise is not an island: you will work together with other parties, such as key partners, suppliers, ... To a certain extent, you will even depend on them. Therefore, you will need to identify these parties as well as the required resources provided by them.

How can they help you? Or how can you help each other? Make sure to also think about other Adrian enterprises (i.e. project groups) that can function as a strategic partner or supplier.

Analyse and describe what is in it for both parties.

D1.6. Marketing and sales

How will you attract customers and users? Determine your USP.

Write down a marketing strategy based on the marketing mix (4 Ps):

1. Product: what are the different layers of your product?
2. Price strategy: what is the smartest price?
3. Place: how will your product be distributed?
4. Promotion: how will you spread the word?

Also include your marketing reel (video link).

D1.7. Financials

D1.7.1. Financial calculations

We expect you to work out a financial plan for your business in which you estimate the revenue and the costs. The aim is of course to make profit in the long run, because natural selection of companies is universal.

The new Earth (since 2064) is unexplored territory, also in the area of accounting and law, so you can make use of your financial creativity (no taxes on Adria, so this is not equal to tax evasion!): think of disruptive innovations such as basic income, virtual banks, blockchains, crowdlending, etc, ...

As a minimum you need a calculated financial plan for 3 years on a monthly basis covering following topics:

• Revenue = P x Q

  P = Based on the P of Price in your marketing plan, you can of course combine strategies

  Q = This is the most difficult part of the calculation. Try to base your estimates on information that is as objective as possible. The main goal is that you are credible in front of the investors and that you are able to defend your numbers. Use comparisons with terrestian examples, use credible references/market studies, don’t exaggerate, … You can also make use of different scenarios to make your prediction of the future more realistic.

• Costs = Fixed Costs + Variable Costs

  • Fixed Costs

    • Sum up the necessary investments and calculate the monthly depreciation

    • Think of other fixed costs such as electricity, rent, wages, ...

  • Variable costs

    • Variable costs are costs that are dependent on the Q. This is not always easy to find but add as a minimum one variable cost to your calculation. (e.g. server costs)

• Break-even analysis Based on your summary of revenue and costs, do the following 2 break-even analysis:

  • How much do you have to sell to be profitable?

  • When will you be profitable?

D1.7.2. Finance mix

Probably you don’t have enough savings to do the necessary investments, so you have to look for external money. Explain your finance mix.

Appendices

You need to add the various appendices to support your business case document.

As mentioned earlier, it is mandatory to at least include an appendix with all AI prompts (ChatGPT, Copilot, ...) you used to enhance your ideas.

Also include screenshots of mock-ups, links to video and other interactive on-line materials.

Project website

About the website

Using Google Sites, hosted under the Howest domain (important!), you will build a public client-facing website.

You will present yourself as a company to the world.

The website is an integral part of the project assignment. Layout (is everything displayed in a clear fashion, do you adhere to your company branding, ...) and content (relevancy,...) will be graded, but you are not allowed to code the entire website itself manually using HTML/CSS/JS or server-side technologies.

There is no need to use paid hosting, nor do you need to purchase a custom domain.

Concepts

Basic concept and approach

What will you build and why are you building it?

Get across a clear picture of what your product is and what it will do. It is not necessary to go into as much detail as in the business case document itself. Think about the message you want to convey to potential customers or investors.

Website pages you should build as a result of this exercise:

• Home page
• Products/services page
• About us

Human resources

In this part, you will define the organisational structure of your Adrian enterprise:

1. How will you be organising your team?
2. Task distribution: who will do what?

Website pages you should build as a result of this exercise:

• Our team
• Job offers (include the vacancy and the LinkedIn mock-up)
• Contact us

Some notes

Also check out other companies'/startup's websites to determine their strengths and weaknesses.

Do not forget to include a message in the footer of the website that it is a fictitious company, part of an educational project! This is mandatory.

Analysis document

The following items need to be covered in detail in the analysis document.

Important note: you are allowed and even encouraged to use AI to finetune and flesh out your ideas. However, you must keep all the AI prompts and add them as an appendix to your analysis document.

Schematics

Describe the full concept in a collection of schematics, which can be suited to your needs. We expect at the very least:

• Minimum 3 flow charts for the most common flows a user will have for your solution. Mind that we do not want application descriptors (no press this button, then fill out that field), but generic actions/choices which span much further than just the interface interaction. Interaction is part of it, but not the whole. The level of detail is more global (remember Application Prototyping)

• One or several UCDs based on user stories. Those user stories should be created as epics in gitlab. Refer to those in your UCD's.

• A C4 diagram featuring at least a context and deployables diagram. You may add component diagrams for the items you find necessary, or omit them all together. Remember: the objective here is to get the message across, not to over-document

• An ERD describing the information model of the software system

• Any other schematic you may find useful to explain the concept. This does not need to be anything class-taught. If you find it useful, and it gets the message across, include it. Even if it’s concept art. (we like concept art)

Clearly mark on your documentation which elements will be included in the POC.

Wireframes and interactive visual designs

The wireframes deliverable will hold wireframes for the full concept, so your wireframes will be far more extensive than your POC. They are drawn on paper (mandatory).

For the visual designs you can use whatever you are comfortable with. This can be HTML & CSS, Figma, Sketch, Azure, Powerpoint, ... The designs must, however, be clickable (to be able to test them, cf. User testing reports) & high-fidelity.

Depending on your concept, you will need to design several interfaces. You need to create all necessary interfaces to elaborate your concept.

In 2080, we don’t think in “sizes”, but in “settings”. Most solutions will have a combination of several settings. We require at least two different settings, but depending on your concept, you might need more. Make sure you name every interface appropriately.

Consider the following use cases:

Example 1 Bad: Your concept is an event platform. Users can browse and pick events to attend. Choose a resolution that best fits the information you wish to display to the user.

Wireframe deliverable: A single wireframe, one with the full-fledged event browser, on a resolution of your choice -> Insufficient!! There’s only one setting here, expand the concept to fit multiple settings!

Example 1 Good: The concept is the same as above, but your application also offers users a way to connect with friends during the event. It will display a mini map of the event grounds, with your friends highlighted, including the route towards them.

Wireframe deliverable: Two wireframes, one with the full-fledged event browser, on a resolution of your choice (=high focus context in a primary setting) and another for the mini-map interface (notification-like context in secondary setting)

Example 2: Your concept is an incident logger for maintenance equipment in one of the subterranean facilities. There are two settings in this case: the first, where the worker logs the incidents on site. A small resolution is suitable for this, given the cramped environment in which the worker works, though he will be in high focus (many interactions, complex material, …)

The second setting for your solution is the overview dashboard, which is consulted by an overseer elsewhere in the facility (not down in the ducts), while the workers are logging the status of the machinery and possible incidents. S/he can initiate incident response procedures. This is also an interface which requires high focus.

Wireframe deliverable: Two wireframes, one for the worker logging setting and one for the dashboard overseer setting.

Example 3: Your concept is a rover rental service. The primary setting is an interface with features such as vehicle selection, rental dates, etc. A secondary setting also applies, as once the user is in the vehicle there’s a live “in air” assistant, which projects lifesize (un)docking instructions, route and other contextual information.

Wireframe deliverable: Two wireframes, one for rental setting and one for the driving setting.

As you see, the actual pixel size of the "screen" is irrelevant, as it can shrink and grow to your needs. Instead of thinking of size, think of context and setting first and adjust size accordingly. That is the size you’ll be developing for.

User testing reports

Your clickable mockups need to be validated by end users. Therefore, you are required to perform at least one user test with three different users that represent your target users determined in the personas. A template will be made available to jot down your findings and determine appropriate scenarios.

A minimum of three scenarios needs to be tested, but you can always include more should you see fit.

Ethical questions

Use the Ethical Decision Making framework to argument at least 2 ethical dilemmas according to the 5 taught principles including a final conclusion per dilemma.

User flow demonstration

Demonstrate the most important user flows by a screen recording while navigating / using your visual design. Make as many as are needed and provide them with a clear title.

You may precede the user flow screencast with a short explanation, textual or by means of graphics / flowcharts / … if you find this necessary.

Proof of Concept

The application contains a web client to handle user interaction and a server to power the back end.

All details about the POC are discussed in the section Proof of Concept.

Project work, peer evaluations and retrospections

Daily standups

At the start of each project day, the groups should have a "daily standup". You will discuss the following allocating an average speaking time of 1 minute per person:

• What did I work on previously and what is its state (Finished / still in development)?
• Did I experience any difficulties with it? If so, which?
• What will I be working on today?
• Do I expect any difficulties / will I be needing some help with a certain topic?

A team member with expertise in the element in question can already indicate this and can be an aid at a later stage.

In the project weeks the daily standups take place every day, during the regular class weeks every Tuesday.

You'll need to submit a summary of your daily standup on Leho. The submission should be done at the latest at 10:30 every project day.

Project work on Gitlab

All work, communication, deadlines, branching, … needs to be handled on the school's provided Gitlab repositories according to the best practices taught in current and past Applied Computer Sciences classes. If things are rusty, get out your old course material and brush up on your knowledge in order to comply with our rules.

In the first year, you were handed the milestones (=sprints) and the epics (=user stories). This year, you will need to create these yourselves in gitlab (on your group level).

Peer evaluations and retrospections

There will be several retrospections and peer evalaution assignments via Leho, which need to be completed.

PM on Gitlab

All work, communication, deadlines, branching, … needs to be handled on the school’s provided Gitlab repositories according to the best practices taught in current and past Applied Computer Sciences classes. If things are rusty, get out your old course material and brush up on your knowledge in order to comply with our rules.

In the first year, you were handed the milestones (=sprints) and the epics (=user stories). This year, you will need to create these yourselves in gitlab (on your group level).

Daily standups

At the start of each project day, the groups should have a "daily standup". You will discuss the following allocating an average speaking time of 1 minute per person:

• What did I work on previously and what is its state (Finished / still in development)?
• Did I experience any difficulties with it? If so, which?
• What will I be working on today?
• Do I expect any difficulties / will I be needing some help with a certain topic?

A team member with expertise in the element in question can already indicate this and can be an aid at a later stage.

In the project weeks the daily standups take place every day, during the regular class weeks every Thursday.

You'll need to submit a summary of your daily standup in the secured part of your site as a blog post. You can choose to either take notes, or record the standup itself and upload it as a video in the post. Don’t forget to add a title and every post should also have a ‘picture of the day’ with all the group members. The post should be published at the latest at 10:30am every project day.

Presentation

Read and apply the guidelines of the semester 2 presentation techniques course "Beter presenteren, is dat echt nodig?"

• Allocated time for the presentation is 20 mins and an additional 10 minutes question time
• Your audience consists of potential investors (private and government). Keep this in mind!
• Your presentation is in Dutch or English. Questions can always be answered in Dutch.
• Your presentation has the same look and feel as your application.
• You are free to choose which tools used to build the presentation (i.e. you are not limited to powerpoint slides). Conveying the story is the primary objective.
• You make sure the presentation is clear and only contains information that is relevant and interesting for your audience.

A few more tips:

• Everyone participates equally in the presentation.
• You bring a coherent story and you try to anticipate the audience's questions.
• You have a neat appearance, but don't exaggerate: you must still be yourself to some extent.
• Your attitude is of course very important; this means no ringing cell phone, no chewing gum, being polite, enthusiastic, … .
• The way in which you address the public is also important! Greet the investors, thank them for their attention and calmly answer questions, even if they may be formulated rather directly.
• You defend your project if you feel it is appropriate. However, when necessary you admit you made a mistake or you admit you do not know the answer to a specific question. The following sentence is always helpful in this kind of situation: “I have not yet looked at the matter from this point of view but that is certainly a valuable suggestion. (Don't overuse it ;).
• You use your non-verbal communication correctly and efficiently.

The entire group must participate in the final presentations before the Christmas leave. It goes without saying that your presentation is structured according to the guidelines of the semester 2 presentation techniques course.

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

Proof of Concept - Client

The client is the implementation of the agreed upon POC.

Only implement the POC, all the rest is fictional and for Adria documentation purposes only.

Starter Project

The start repository is empty.

The structure of this folder is your responsibility but you need to build a working client with Vue.js as framework.

Requirements

• Follow good practices from previous and current courses.
  • Create readable code
  • Write small functions
  • Ensure functions do one thing
  • Refactor code regularly
  • Follow the naming conventions for files, variables, functions, ...
• The web applications needs to use the Vue.js framework.
• The application should have least 3 reuasable components.
• The project structure and code should be follow using the Compositon API style (setup(), ref(), computed(), watch()).
• Dockerize the client application by building a working Dockerfile.
• Build your own 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
• Sonar quality gates should be green.
• No tests are required for the client application.

Prerequisites

• Docker desktop is installed on your machine.

Testing & quality checks locally

• In this project, the sonar is only updated through the build pipeline.
  • SonarQube Dashboard - Adria Server
  • SonarQube Dashboard - Adria Client

Production

In this project, there is no production environment.

There is only a test environment that will run on your local machine.

That's why it's important that the gitlab-ci.yml file is correctly configured to push the docker image to the howest docker registry (hcr.technet.howest.be).

The test environment will pull all images from the howest docker registry and run the Adria solution.

Useful configuration files and commands

To implement all beforementioned requirements, you will need at least the following configuration files and some basic commands.

Use and adapt them to your project structure and needs.

Environment files

Purpose: provide configuration settings to vite with an environment file.

Environment files are generally ignored by git.
You can add an .env.example that shows what kind of variables are available.

Create the following files on the root:

• .env.development
• .env.test

Each with content:

VITE_API_BASE_URL=http://localhost:8000

File: sonar-project.properties

Purpose: Configuration file for SonarQube analysis of the client project.

#CHANGE XX TO GROUP NUMBER e.g. XX -> 01
sonar.projectKey=2025.ad-project.adria.XX.client
sonar.projectName=2025.ad-project.adria.XX.client
sonar.host.url=https://sonarqube.ti.howest.be/
sonar.sources=src

File: package.json

Prupose: This file will be generated when you create a new Vue.js project using Vue CLI or vite.

You will need to update it to something like below, note the extra build scripts for building and pushing a vuejs container image.

REMOVE: the tsc scripts and dependencies if you are not using typescript.

Make sure to include scripts for SonarQube analysis.

{
  "name": "adria-client",
  "version": "0.0.0",
  "private": true,
  "type": "module",
  "engines": {
    "node": "^20.19.0 || >=22.12.0"
  },
  "scripts": {
    "dev": "vite",
    "build": "npm run type-check && npm run build-only",
    "build:test": "npm run type-check && vite build --mode test",
    "build:dev": "npm run type-check && vite build --mode development",
    "preview": "vite preview",
    "build-only": "vite build",
    "type-check": "vue-tsc --build",
    "serve": "vite preview"
  },
  "dependencies": {
    "vue": "^3.5.22",
    "vue-router": "^4.5.1"
  },
  "devDependencies": {
    "@tsconfig/node22": "^22.0.2",
    "@types/node": "^22.18.6",
    "@vitejs/plugin-vue": "^6.0.1",
    "@vue/tsconfig": "^0.8.1",
    "npm-run-all2": "^8.0.4",
    "typescript": "~5.9.0",
    "vite": "^7.1.7",
    "vite-plugin-vue-devtools": "^8.0.2",
    "vue-tsc": "^3.1.0"
  }
}

File: .gitlab-ci.yml
Purpose: GitLab CI configuration file for building, validating, and deploying the client application

This is a basic example, you need to adjust and extend it to your project structure and needs.

Note how the SonarQube step is uses a script that is defined in the package.json file.

WARNING Make sure the node_modules folders is NOT pushed, it will break the CI/CD.

image: registry.ci.infra.lan:5000/project-2:client-QA

stages:
  - QA
  - build

before_script:
  - ln -s /ci/node_modules .

SonarQube:
  stage: QA
  only:
    - main
  script:
    - node -v
    - npm run sonar-ci
# You will need to find a way to pass the sonar token to command npm run sonar-ci.
# The sonar token is available with the variable $SONAR_TOKEN
# Take an example from the server .gitlab-ci.yml file.

create-image:
  image: registry.ci.infra.lan:5000/ad-project:server-DEPLOY
  only:
    - main
  stage: deploy
  services:
    - name: docker:dind
  tags:
    - docker
  variables:
    DOCKER_TLS_CERTDIR: ""
  script:
# Extend the script so it builds and pushes the Docker image to the howest registry hcr.technet.howest.be

File: Dockerfile

Purpose: Dockerfile for containerizing the Vue.js client application.

This is a basic example, you need to adjust and extend it to your project structure and needs.

FROM node:22-alpine AS builder

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY . .

ARG BUILD_ENV=dev

RUN npm run build:${BUILD_ENV}

FROM nginx:alpine

COPY --from=builder /app/dist /usr/share/nginx/html

COPY nginx.conf /etc/nginx/conf.d/default.conf

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

File: .dockerignore

Purpose: ignore unwanted files/folders during docker build phase.

This is a basic generated example, extend if needed.

node_modules
dist
.git
.gitignore
.env.local
.env.*.local
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
lerna-debug.log*
.DS_Store
coverage
*.local
.vscode
.idea
*.suo
*.ntvs*
*.njsproj
*.sln
*.sw?
*.tsbuildinfo
README.md
docker-compose.yml
Dockerfile
.dockerignore

Command: Build and push Docker image locally

The build pipeline will build and push the Docker image to the howest docker registry.
However, you can also do this locally to speed up testing.

Try to understand the commands below.
Especially the --build-arg BUILD_ENV=test part in the build command.
This enviroment concept will be used in further semesters to differentiate between development, test and production builds.

Please use brainpower to adapt the commands to your needs.

Building an image

docker build --build-arg BUILD_ENV=test -t hcr.technet.howest.be/adria-client-group-XX:latest .

Pushing to the howest docker registry

docker push hcr.technet.howest.be/adria-client-group-00:latest

Running the client and server containers locally

To run the client and server locally, just execute the server and client projects from within their own IDEs or terminals.

Only do this during development. Integration testing should always be done using the test environment (see test environment documentation).

In real situations, it's not even common to run both client and server on the same machine.
Mostly, the client will mock the server using mock data. Take it as an extra challenge to implement this mocking mechanism in your client application.

Proof of Concept - Server

The server is the implementation of the agreed upon POC.

Only implement the POC, all the rest is fictional and for Adria documentation purposes only.

Starter Project

The start repository serves as the server-side starter project.

Requirements

• Ensure unit testing for both the application and domain layers.
  • Refer to the project document for detailed testing guidelines.
• Complete the docker-compose.yaml file with a mySQL database setup.
• Complete the .gitlab-ci.yml file with a job to dockerize and push the image to the docker registry.
• Correctly configure the .NET properties files.
  • appsettings.Test.json for the test environment.
    • The connection string should point to the database container defined in the docker-compose file.
  • appsettings.Development.json for the local development environment.
• Sonar quality gates should be green.

Prerequisites

• Ensure .NET 10 and docker desktop are installed on your machine.

Testing & quality checks locally

• In this project, the sonar is only updated through the build pipeline.
  • SonarQube Dashboard - Adria Server
  • SonarQube Dashboard - Adria Client

Running the project locally

1. Boot your database container.

docker compose -f config/docker/docker-compose.yml up -d

2. Run the server project with the command

 dotnet run --project src/AdProject.Main

Local Endpoints

• Database:
  • Connect to the mysql database with any MySQL client (e.g. DataGrip).
• Server Logs:
  • Available via terminal output.
• Swagger Interface:
  • Run the application and navigate to http://localhost:8000/swagger/index.html.
• Web Client Project:
  • Launch using an IDE like WebStorm/PhpStorm (refer to the client-side README).
• Server API:
  • Accessible at http://localhost:8000/api/.

Production

In this project, there is no production environment.

There is only a test environment that will run on your local machine. That's why it's important that the gitlab-ci.yml file is correctly configured to push the docker image to the howest docker registry.

In the end the test environment will pull all images from the howest docker registry and run solution.

Build Pipeline

• The build pipeline is partially pre-configured:

  • Executes unit tests on every push to the main branch.
  • Generates a SonarQube analysis.

• The build pipeline is not fully configured, the following tasks are still required:

  • Dockerizing the application.
  • Pushing the docker image to a howest docker registry.

Command: Build and push Docker image locally

The build pipeline will build and push the Docker image to the howest docker registry.
However, you can also do this locally to speed up testing.

Please use brainpower to adapt the commands to your needs.

Building an image

docker build -t hcr.technet.howest.be/adria-server-group-XX:latest .

Pushing to the howest docker registry

docker push hcr.technet.howest.be/adria-server-group-00:latest

Running the client and server containers locally

To run the client and server locally, just execute the server and client projects from within their own IDEs or terminals.

Only do this during development. Integration testing should always be done using the test environment (see test environment documentation).

In real situations, it's not even common to run both client and server on the same machine.
Mostly, the server api is tested by implementing integration tests or by using Swagger or any api testing tool (e.g. Postman).

Proof of Concept - Test Environment

This repository will contain the code to run the test environment for the Adria project.

Goal

The test environment is used to run the complete Adria solution on your local machine independently of any IDE or source code. It's meant to simulate a production environment as closely as possible.

Use this environment to do final testing of your application before the final delivery.

• Navigate to the root of this repository and run:

docker compose -f docker-compose.yml up -d

• Test your application through the web client or API (Swagger).

Starter Project

The start repository is empty.
Not all mandatory topics are taught in class.
You will need to do some self-study to implement them.

Prerequisites

Docker desktop is installed on your machine.

Requirements

• Create a working docker-compose file that runs the complete Adria solution.
  • Server runs on port 8000
  • Client runs on port 80
• The docker-compose file must contain at least:
  • A database container (MySQL)
  • A server container
  • A client container
  • A network to connect the containers
  • A volume to persist the database data
• This repository only contains Docker code.
• It must be possible to run the complete Adria solution with a single command:
  • The lecturer will clone your repository, navigate to the folder containing the docker-compose file and run the command

docker compose -f docker-compose.yml up -d

• No CI is required for this repository.

Start point

Start from this basis.

Note how an environment variable file is used to pass variables to the containers.

services:
  server.adria:
    image: hcr.technet.howest.be/adria-server-group-00:latest
    ports:
      - "8000:8000"
    networks:
      - adria-test
    env_file:
      - .adria-server.test.env
    depends_on:
      database.adria: 
        condition: service_healthy

  # client.adria:

  # database.adria:
    # Add a healtcheck to ensure the server only starts when the database is ready.
  

volumes:
  mysql_data:

networks:
  adria-test:
    ipam:
      config:
        - subnet: 10.30.0.0/16

Resources

TODO: FIX ALL URLS TO POINT TO THE RIGHT FILES

Presentations

• AD Project Briefing

Helpful repositories

• Projects
  • Find your project repository here.
• Web Technology Tutorials
  • Tutorials for some of the customizable requirements.

Templates

• AD Project - README.md for documentation repo
• AD Project - Analysis Document Template
• AD Project - Business Case Template
• AD Project - Usability Test Template

Overview of all Projects

We highly recommend collaborating on Adria.

Once all groups have established their websites, a comprehensive list will be made available here.