2.1. 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

Innovative aspect

Key to this new world is that your solution makes the life of the people better in the broad sense of the word. Learn from the past! Your product must be innovative that improves the quality of life and well-being of people on earth, big or small.

Visualisation component

Medium to large amounts of data need to be presented in a visually attractive way. These can be immersive gallery experiences, graphs, maps, …

Be creative!

User data collection

Your application needs to collect data from the user. Exactly which data, how much and how you’ll query for the necessary details, is up to you. The data needs to be stored server side, by means of one or more data stores.

In the POC, you have to use a database for your application, but for your concept, you may use as many different data stores as appropriate.

Usage incentive

We need a compelling reason for our users to keep using the application. Intrinsic motivation is the best kind of incentive, try to find out how for your application.

Domain specific

Each group is assigned a specific domain for which they must develop their POC. Collaboration with other groups for cross-domain work is encouraged. Changing or switching domains is not permitted. The different domains are:

1. Education & development
   After the catastrophes, large knowledge gaps remain and new generations must be educated quickly.
   POC idea: a holographic learning platform with AI mentors that revive forgotten Earth knowledge and train new skills needed for survival on Mars (e.g., ecosystem management, robotics).

2. Smart living & families
   Colony Adria must develop compact, energy-efficient, and stress-free housing.
   POC idea: An adaptive living module system that automatically adjusts to the number of residents, optimizes energy use, and creates a sense of “home” through personalized environments.

3. Active culture & fun
   On Adria but also on the other settlements, relaxation and recreation are vital to maintain mental health.
   POC idea: A virtual arena platform that combines sports, art, and music to keep colonists physically active while preserving Earth's cultural heritage.

4. Next-gen mobility
   Moving within and beyond Adria is dangerous due to radiation and rough terrain.
   POC idea:An autonomous transport pod system that safely navigates colonists through the colony or to research sites, including real-time guidance during "dust storms".

5. Healthy living
   Medical facilities are limited, and wellbeing is as important as treatment.
   POC idea: A nano-drone diagnostic network that continuously scans colonists for physical and mental health issues, connected to a digital wellbeing coach.

6. The green planet
   Rebuilding ecosystems on Earth is crucial for humanity's future.
   POC idea: An AI-driven bio-dome that simulates and regulates ecosystems (water, air, biodiversity) in real time to support sustainable agriculture and nature in Adria.

7. Safe communities
   Threats come from both outside (radiation, dust storms) and inside (conflicts).
   POC idea: A community trust system that uses AI to detect early tensions and deploys "mediation drones" to resolve conflicts, while smart sensors defend the colony from external dangers.

8. Food
   Food production must be local, circular, and sustainable.
   POC idea: A hybrid food printer that combines genetically enhanced seeds with 3D food-printing, enabling colonists to enjoy both classic Earth dishes and brand-new Martian recipes.

9. Resilient Economy
   Survival in Adria also depends on how people organize work, share resources, and build a fair economy that motivates innovation.
   POC idea: A resource exchange platform where colonists can trade skills, energy, or materials in a transparent way, supported by blockchain-like trust systems, ensuring collaboration and fairness.

2.2. Context - restrictions

Following restrictions apply to the project.

2.2.1. Earth: current settlements in 2084

The Entry Station

The Entry Station is the single point of entry for all lifeforms seeking residency on Adria, the first colony on Earth since the Global Disaster. There is a crew manning the station around the clock, but otherwise it is largely populated by "passer-by"s.
Quarantine procedure will require people to stay for a short period of time, both traveling on and off-planet. This means you'll get a short engagement from many users, but never for more than a couple of weeks. The range of people reached with any type of advertising is highest here.

Adria: the First colony

Adria, the First colony is where the magic’s at. This fully-operational colony is a small indicator of what life will be again on Earth.
Complete with extensive medical facilities, schools for the youngest, lush greenhouses, robuust research lab and extensive R&R amenities, this is the heart of Earth. There is need for expansion and diversification. The colony is looking for new souls and ideas to shape the Adria’s identity.

The Other colonies

Where Adria is fully operational, other colonies around the world are built to obtain the same objective. For now, those places are under construction.
People stay there for extended periods, lacking all the comfort from Adria, only the basic needs provide, sometimes for months. Work is the main focus of the populace, with medium breaks for much needed R&R (Rest & Relaxation), after travelling by the Earth Voyager to the Adria Colony.

Travel restrictions

Travel is only possible in the directions of the diagramme between the current settlements.

Other restrictions

Do not find yourself constrained by current technological limitations and assume the tech can handle it.
If you can think of it, it's possible with the exception of time travel, inter-dimensional travel and zombies - we are not yet in the year 3000.

2.2.2. Conventions and terminology

You may assume the following about current Adria’s life.

AdriaOS - One OS to rule them all

Do not concern yourself over compatibility between devices. There is one OS to rule them all, AdriaOS, which supports all resolutions for Adria’s approved devices. The hardware across these devices is consistent.

Adria's devices

All people (on Earth, on Mars, on the space station) have an implanted chip that is used for identification and monitoring (vital signs, localization, …).

Upon arrival all Adrians are given a device which can project an interactive interface of any size on any surface (or even lacking surface). They can also act as a trigger to activate nearby sensors to interact with the environment. It comes in the shape of a wristband, with the projection unit on top.

AdrianID

Every Adrian has an ID integrated into their chip and connected wristband. The individual's identity is validated upon arrival and encoded into the chip. As a result of this, all applications in the Adrian environment are required to use AdrianID for authentication. Registration or Login forms are forbidden by Adrian law!

AdriaCoin or the ADCO

All currency on Adria is handled via the blockchain-based AdriaCoin (ADCO). For calculations you can use the conversion of 1 ADCO = 1 EURO in 2025.

2.3. Concept choice process

Which software system to develop?

The current people on the Adria colony have already put out a list of absolutely necessary software systems (= Adria's Critical Apps) to be developed. You have to think of a non-existing solution within the domain you are assigned to.

In the second week every group has to pitch their topic.

You have to meet the conceptual requirements and convince the jury of your idea.

After the pitches have finished, you will get a GO or NO GO. If you get a NO GO, you should go back to the drawing board and come up with a better concept.

List of pre-determined Adria's Critical Solutions (can not be choosen)

• AdriaBook: Adria connector application (cfr facebook/other social media ) to connect the different people of Adria and other colonies. Connections to intergalactic citizens are not possible (Mars and space station). Earth only.

• Adria Rover rental: Rent a rover, complete with navigation system, designed to easily find your way around the surface of the Earth and toward the other colonies. Integration with weather app for danger alerts is mandatory. The application comes with a built-in function to simulate driving with the Adria rover and learn how to handle it before taking it out in the field.

• 24/7: Collection app for all events on Adria, what’s happening, when and where (and are you invited?)

• Mapp Store: Adria’s App store, collecting all available applications for AdriaOS devices

• Are you the Adrian I’m looking for?: Looking for a person with a certain skillset? Perhaps he can do a job for you or vice- versa? An upscaled linked-in with instant work opportunities. Think about constraints in this new environment. If a person needs to go under the colony or to another one, transport needs to be arranged etc.

• Adria's Auction House Produced/minded (and other) materials are available to all creative people of Adria. The auction house is the entry point to sell and buy Adria’s materials. Since the Adria’s community has a focus on sustainability, restoring/saving resources, this can be extended with suggestions for optimization of materials use.

• Adria Exchange: The Adria’s stock exchange. All these new companies building all these new products will probably be looking for investors. Develop a market place of them to trade, based on Terran stock markets though creative deviations are allowed.

Inspiration

There are plenty more today's Earth based applications you can modify to Adria's needs that haven't been listed above (Fitbit, find that person instead of that device, …) but nicer would be to look at things from an Adria's perspective and truly focus on what this new society needs.

Maybe you can think along the lines of applications such as a person's impact on Adria (everything from your excretion to how many plants you fertilise by it..). Colonisation requires progeny, how will we handle coupling? Is a Tinder/Grindr clone what we're looking for or can we match people in a different way? Can you integrate the physical world into it?

What about the world around Earth? Maybe there are deepsky objects that require our attention. What value would they have? How do we connect with the people on Mars?

When you start working on your concept for Adria 2084, it can be really useful to look at speculative stories that show both the power and the dangers of new technology.
The series Black Mirror is a great example: in the episode "Hated in the Nation" you see how automated systems can spiral out of control and create chaos, while in the "Arkangel" epsiode an overprotective AI makes a child blind to what danger really means. These stories remind you that technology isn't just exciting—it can also backfire if you don't think about risks.

Besides Black Mirror, you could also check out:

• Philip K. Dick's short stories (many of them inspired films like Minority Report and Blade Runner)
• The Matrix (how virtual worlds can distort reality)
• The Handmaid's Tale (how systems of control shape society)
• The Expanse (life in space colonies, politics, survival)
• Love, Death & Robots (short animated stories with both inspiring and dystopian tech ideas)

Use these as fuel for your imagination—but always ask yourself: what could go wrong if people in Adria rely too much on this technology?

Finally: do not find yourself constrained by current technological limitations and assume the tech can handle it. If you can think of it, it's possible (with the exception of time travel, inter-dimensional travel and zombies – we are not yet in the year 3000).

3. Deliverables

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

We expect all of the following deliverables:

• D1: 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".

• D2: 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"

• D3: 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.

• D4: Partial exam (Leho & exam repo)
  Over the course of the first 5 weeks, you will acquire knowledge of both client and server basic technologies related to the project through a combination of knowledge clips and self-study.
  In the first project week, you will complete an individual quiz/exam to assess their acquired knowledge. This will serve as a foundation, allowing you to confidently and smoothly transition into the development phase of the project.

• D5: 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.

• D6: 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.

• D7: 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.

D1: 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.

D2: 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.

D3: 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.

D4: Partial Exam

In order to make a smooth start to the development part, we expect students to spend the first five weeks studying the Vue.js framework and the server's start code on their own.

A Leho quiz which tests if you have enough knowledge of the client will be available on the first day of the first project week.

On the same day there will be a server exam in which you will need to add some basic features to the start code of the server in a structured manner. A start repository will be available.

Pratical information

• Date: 03/11/2025
• Duration: 3,5 hours
• Time: 09:00 until 12:30
• Parts:
  • client exam - 50% (1,5 hour)
  • server exam - 50% (2 hours)

Evaluation

Each component will stand for 50% of the score for the deliverable D4.
The results will be published on Leho no later than two weeks after the examination, using letter grades:

• A grade: 16/20 or more
• B grade: 14-15/20
• C grade: 12-13/20
• D grade: 11-12/20
• E grade: 7-8-9/20
• F grade: 6/20 or less

If you scored an E or F, you must retake the exam(s) in January 2026, provided that you have passed all other deliverables.

Important

• Any form of communication between students or other parties is strictly forbidden.
• This is an individual exam. Any discovery of irregularity (e.g., phone use, peeking, copying, hacking, use of social media clients, etc.) will, in accordance with the Education and Examination Regulations (EER), result in notifying both the involved student(s) and the chairman of the examination committee.
• After completing the exam, it is forbidden to publish the assignment or solution in any way other than the designated repository on gitlab.ti.howest.be.
• Question-driven AI is forbidden.
• Make sure all applications that could potentially open/start or be interpreted as an attempt at fraud (Outlook, Messenger, Facebook, etc.) are closed before the start of the exam!

Partial exam: client

The client exam is a Leho quiz (in lockdown browser) which tests if you have enough knowledge of Vue.js. Nevertheless, real practice is needed to pass the exam.

In this exam you are going to prove that you have the necessary skills to develop the client project with useful features.

• Type: Leho quiz in Lockdown browser
• Date: 03/11/2025
• Duration: max 1,5 hour
• Time: 11:00 - 12:30. If you finished the server exam, you can start with the client examen.

How to prepare

!Complete the learning paths of Vue.js on vueschool.io!

• Learning path "Vue.js 3 fundamentals with the Composition API"
• Learning path "Vue component fundamentals with the Compositon API"

Each path consists of a serie of videos (total of 1 hour per path). Make sure you understand everything and try the code yourself!

Make sure that you also have a look at the official site: vuejs.org, especially the Docs section (Tutorial and Examples) and the Playground.

Evaluation

• The points to be earned are mentioned in the partial exam document.

Partial exam: server

In this exam you are going to prove that you have the necessary skills to extend the server project with useful features.

• Type: Open book / individual
• Date: 03/11/2025
• Duration: max 2 hours
• Time: 9:00 - 11:00 (at the latest)

This document describes what to expect, how to prepare.

How to prepare

!Study the server tutorial!

Server tutorial

Explore the example server repository in depth

Example server repository

Try to extend the example server repository with new features.

This will help you to understand how to extend the server project.

Below are some possible examples.

Requirements

• You must follow the folder structure and way of working like discussed in the Leho video's.
• The code must compile.
  • Not compiling code will result in a 0.
• You may not change the provided unit tests.
  • These will be overwritten with the correct tests.
• The result must be pushed to your own repository on Gitlab.

Allowed

• You are allowed to use the internet to search for information.
• You are allowed to use AI to help you write code (code completion). Question-driven AI is forbidden.
• You are allowed to use the code from the lessons and example repositories.

Evaluation

• The points to be earned are mentioned in the partial exam document.

Goal

You will be asked to implement 2 use cases and make the provided unit tests pass.

Use case 1: Adding a new feature

In this type of use case you will be asked to change something in the domain. You will need to:

• Change/add something in the domain layer.
• Write an appropriate use case.
• Create unit tests.
• Extend the infrastructure layer with
  • A new web api end point

Use case 2: Getting some useful information

In this type of use case you will be asked to add a new query to the domain. You will need to:

• Write an appropriate use case.
• Make the provided unit tests pass.
• Extend the infrastructure layer with
  • A new web api end point

D5: 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.

D6: 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.

D7: 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.

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

4.1. 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 strcuture 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.

4.2. 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.

It offers the foundational structure for an OpenAPI web server with a mySQL database.

Working in this folder structure with .NET 8 and minimal web api's is mandatory.

Requirements

• Adhere to the project structure as detailed in the Leho instructional videos and example server.
  • Please review example repository and these videos thoroughly.
• 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.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 8 and docker desktop are installed on your machine.
• Agree with your team on a database credentials and update the files:
  • src/Adria.Main/appsettings.Development.json
  • config/docker/docker-compose.yml

Security

In this project, there is sensitive information such as database credentials. This is not done securely on purpose to facilitate easy setup for students. In a real-world scenario, sensitive information should be managed using secure methods such as environment variables or secret management tools.

If you have choosen the sensitive information self study topic, please ensure that you implement secure handling of sensitive information in your project. You've seen this in the module OOA&SD.

Push notifications

If you have chosen the push notifications self study topic, please ensure that you implement push notifications in the corresponding parts of your project.

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/Adria.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 the Adria 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.

Configuring Properties

• Local properties: src/Adria.Main/appsettings.Development.json
• Test properties: src/Adria.Main/appsettings.json

Database Management

• Do not manipulate the database manually
  • Use the Migrations and Seeders scripts in the infrastructure/persistence folder.
• The database will be recreated (Migration) and repopulated (Seeder) every time you run the API.

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.

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

Already partially configured. Extend it to dockerize and push the image to the howest docker registry.

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.

Already provided, adapt it to your project structure and needs.

File: docker-compose.yml

Purpose: Docker Compose file to set up the server application along with a database.

Empty file provided, adapt it to your project structure and needs.

services:
  taskly-db.adria:
    image: mysql:latest
    environment:
      MYSQL_ROOT_PASSWORD: adria
      MYSQL_DATABASE: taskly
      MYSQL_USER: adria
      MYSQL_PASSWORD: adria
    ports:
      - "3306:3306"
    volumes:
      - mysql_data:/var/lib/mysql

volumes:
  mysql_data:

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).

4.3. 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