1.1 Spec requirements - mariusb03/WebAndApplication-group-18 GitHub Wiki
limk to the original document:
Exam in IDATA2301 and IDATA2306
Versions
v1.0 – Initial revision, 2025-01-27.
Introduction
This document describes the examina*on in two courses:
- IDATA2301 Web technologies
- IDATA2306 Application development
The examina*on format of both courses is porIolio, which means that you submit a set of “assets” (files, links). The hand-in material in both courses is based on group projects developed throughout the semester. Therefore, part of the evaluation is common for both courses. However, each course has also separate elements which are basis for the examination. The following sections describe both the expected mandatory elements, optional features, deliverables to hand in as well as guidelines for grading.
Mandatory requirements – common
A complete website must be implemented, both the frontend and backend must support the whole process of product filtering:
- Landing page
- Product search (search form and search result list/grid)
- Choosing one specific product
- Product detail page (for the chosen product):
- Product image
- Product description
- Product price for the different providers
- Placing an order (this action may be different for the different project themes, you need to come up with a solution on what this means for your project, present it to the customer (teachers).
- Login form
- For logged in users:
- Regular users:
- Can add a product to their favorite list.
- Can see their favorite products.
- Admin users:
- Can show and hide a product. A hidden product does not show up on for the users.
- Regular users:
Non-func.onal requirements
- Students have worked in Sprints, with planning and reflection.
- Version control used for source code management.
- Regular work throughout the semester.
- Code quality according to the best practice.
- README file(s) for the project.
Mandatory requirements for frontend (IDATA2301)
- Design guideline developed and consistently followed. The guideline can be updated during the semester, but the resulting website must be in sync with the final guideline. Also, the style must be consistent across the whole website. For example, it is not good to have different styles for different buaons.
- Wireframes of page sections sketched.
- Semantic elements used (div and span are last resort).
- Responsive website, looking good on both desktop and mobile device.
- Accessibility and usability considered. Lighthouse tests passing (for usability, not necessarily for SEO, Performance and PWA).
- Some data loaded from a backend, using REST API calls.
- Some interaction with JavaScript – DOM element modifica*on.
- The website looks aesthetically pleasing. This is hard to judge and mainly is seen together with usability. For example, are the text sizes according to the best practice, are colors having good contrast, do they make sense for the theme?
- The style is fihng the given theme of the business.
Mandatory requirements for backend (IDATA2306)
- Necessary business logic implemented, supporting all the necessary user actions.
- REST API endpoints for fetching necessary data: products, etc.
- REST API endpoints supporting all four CRUD operations (Create, Read, Update, Delete) for at least one entity (even if all of them are not really used by the frontend)
- Users with (at least) three different roles (groups): visitors (unauthenticated),
authencated users and administrators. To make the tesng and exam grading easier,
create the following predefined users:
- Regular user: username: dave, password: Dangerous2024
- Administrator user: username: chuck, password: Nunchucks2024
- Authentication implemented with the following endpoints:
- An endpoint where users can authenticate (log in).
- 1+ endpoint accessible only to admins.
- 1+ endpoint accessible to both admins and regular users.
- 1+ endpoint accessible to everyone, including unauthenticated visitors.
- Both backend and frontend secured with HTTPS.
- Re-entrant test set – either Postman test collec*on or Java tests with MockMvc.
- API endpoint documentation – either with Swagger, or in another form. a. All endpoints listed. b. Short description of the endpoint: the URL, expected request parameters, response code and response data.
- Database password(s) and JWT secret key must be stored in environment (.env file or other files) outside of GIT. It is OK to store test-database user and password in GIT files (for automated testing), but not for production. This will be evaluated as part of good coding practice. Note: if you use GitHub actions for deployment (optional), store the usernames and passwords as GitHub secrets.
Deliverables to hand in
The following deliverables must be delivered in Inspera:
-
Link to source code GIT repository. If you used separate repositories for the frontend and backend, provide link to both of those. If during the semester several students had “their own project repository” (which is a rela*vely bad practice – you should have collaborated on the same repo instead), provide all of those.
-
README.md file(s) – at the root of the project folder. No need to hand in anything specifically, just make sure that you GIT repository contains a README file. You can have two separate READMEs (one for the backend, one for frontend) in the respective folders. The target audience for the README are developers and next students. Include the following in the README:
- A short description of the project
- “Gehng started” – how to run the project, what is necessary (environment variables, database(s))?
- One or a couple of screenshots of your website (for the frontend part).
-
Video presentation (video file) of the project, see content requirements below.
-
URL of the website in production. It is expected that the website is deployed on a server. The website must be accessible during the whole examination period (and eventual complaints (klagesensur)).
-
Sprint reports. No formal definition of the format. This can be, for example a markdown file stored in the same Git repository. You need to show:
- When did you work with the project – which weeks?
- What was the goal in each sprint?
- How was the work distributed among group members? Who got assigned to which tasks?
- What was accomplished in each sprint?
-
For IDATA2301 the following additional deliverables are required either as links to online-files or PDF files:
- Design guideline.
- Wireframes.
-
For IDATA2306 the following addi*onal deliverables are required:
- Database schema. Show the table and relations between them (PDF or PNG
file). You can generate the schema with different tools. For example, take
screenshot of “ER Diagram” in DBeaver. An example of what is expected:
- Database schema. Show the table and relations between them (PDF or PNG
file). You can generate the schema with different tools. For example, take
screenshot of “ER Diagram” in DBeaver. An example of what is expected:
-
Postman test collection(s) – either a link to the collections online or a .JSON file containing the test collection. If you wrote other types of API endpoint tests (for example, Java tests with MockMvc), write a comment about it instead of providing a link to the tests.