Design laboratory

Edition: Winter semester 2024/2025.

The Design Laboratory is a course where you will form a team to propose and execute a design idea. While the design is important, the primary focus is on the effort and processes required to build and manage the project. The objectives of this course include fostering teamwork skills, enhancing project management abilities, and developing proficiency in software development tools. You will be responsible for planning, organizing, and dividing the workload within your team, maintaining a log of your tasks, and documenting your work progress using software development tools. Throughout the course, you will enhance your problem-solving skills, improve your ability to collaborate effectively in a team setting, and gain hands-on experience with industry-standard tools. A wise design choice and reliable plan are crucial for a smooth journey through the semester.

During the course, you will be required to utilize the following software development tools as part of your workflow:

git for source code management,
Forgejo, a web based collaborative software development platform (software forge) tightly integrated with git.

If you are attending this course, please read this whole page carefully. In the case of any ambiguity in the content, it will be discussed at the introductory meeting.

Table of content

Staff

The laboratory staff consists of one instructor, Szymon Woźniak, that will supervise you during this course. Click for information about office hours or contact details.

Prerequisites

This course does not have a strict prerequisites. However, a fundamental knowledge obtained in the previous courses is essential for smoothly completing this course. The most important abilities you should have are the following:

self-study,
search for the information in the books, literature, and internet,
good programming and algorithmic skills.

Laboratory organization

In this section, you will find some details about laboratory organization throughout the semester. There are 14 regular meetings and additional 2 backup meetings for evaluation. There are four types of meetings. Types are as follows:

Introductory meeting (1 regular meeting),
Proposal meeting (2 regular meetings),
Project meeting (10 regular meetings).
Evaluation meeting (1 regular + 2 backup meetings).

Most of meetings are in the form of consultations, where you can come and discuss your project development with me. Although, sometimes I might invite you to review and discuss your work. In the following parts of this section, there is a short description of each meeting type. Finally, the procedure for signing in for a meeting is described.

The detailed schedule of the laboratory is available in section Schedule.

Introductory meeting

The purpose of the introductory meeting is to clarify any uncertainties regarding the laboratory's organization. Before attending, you should already be very familiar with the content of this page so that you can ask any questions needed to deepen your understanding of the course's principles. We can discuss various aspects such as the grading policy, design expectations, project execution, organization, schedule, what steps to take after this meeting concludes, etc. The only rule for this meeting is the following:

If you are unsure about something, ask.

This is the best time and place for questions, so come prepared.

Once we have discussed the laboratory's organization, there will be time to network with your peers. It will likely be the best opportunity to find potential team members, as it is the only meeting where all participants will be present in the same room at the same time.

Proposal meeting

These two meetings are in the individual or team consultation form where you can discuss anything related to your design idea with me. The purpose of the meetings is to help you prepare a suitable project proposal.

You should come to this meeting at least with preliminary design ideas, that you would like to develop in this course. In section Design expectations you can read more about expectations put on design ideas. It is recommended for preformed teams to prepare a draft version of the proposal.

If you plan to attend meeting, you are required to register in advance for each one. Check section Signing in for a meeting for details.

Project meeting

Project meetings are weekly meetings where you can meet with me to discuss progress or encountered difficulties, obtain assistance in planning the immediate steps, or consult whatever you like. Since the meeting duration might be relatively short, you should be well-prepared.

If you plan to attend the meeting, you are required to register in advance for each one. Check the section Sign in for a meeting for details.

Some Project meetings will also include the review. You will be notified about it beforehand via e-mail. So keep in mind that I can register you for a meeting for the purpose of the project review, even if you didn't plan to come.

Evaluation meeting

The evaluation meetings is a final review of the project, where you will have to demonstrate what have you achieved.

Signing in for a meeting

If you are interested in attending a particular meeting, the signing in procedure for each meeting is as follows:

Send me a message via e-mail stating that you would like to schedule an appointment. You should send your message before 17:00 o'clock the day before the day on which the meetings take place. According to current schedule the deadline for sign in is 17:00 Wednesdays. The title of the message should be something like that: [design-lab] Signing in for a meeting. The message should at least briefly explain the aim of our meeting, however if you do it in more detail, I will probably be in a better position to help you. If you plan to come with other team members, state who is coming with you.
After 17:00 o'clock, I will prepare detailed schedule of the meetings for the next day based on the messages received. In response to your message, I will send you the exact time slot of our meeting so that you do not have to wait in line. You can expect the reply from me between 17:00 and 20:00.

Very important remark

Don't forget to check the e-mail even if you didn't sign in for a particular meeting, since you can be invited for project review.

Schedule

The winter semester spans 20 weeks, providing ample time to accommodate all 14 scheduled meetings. The first first meeting is dedicated to an introduction and organizational matters. The following two meetings will focus on project proposal discussions. The next 10 meetings are reserved for consultations on project development and progress reviews. The remaining meetings will be used for the final evaluation of your project.

Additionally, the following notation was applied for dates:

Strike-through ~~dates~~ indicate canceled meetings due to various reasons.

Week	Lab nr	Date	Description
01	-	~~2024.10.03~~	No meeting due to deans' schedule.
02	01	2024.10.10	Introductory meeting.
03	02	2024.10.17	Proposal meeting#01.
04	03	2024.10.24	Proposal meeting#02.
05	-	~~2024.10.31~~	No meeting due to friday's schedule this day.
06	04	2024.11.07	Project meeting#01.
07	05	2024.11.14	Project meeting#02.
08	06	2024.11.21	Project meeting#03.
09	07	2024.11.28	Project meeting#04.
10	08	2024.12.05	Project meeting#05.
11	09	2024.12.12	Project meeting#06.
12	10	2024.12.19	Project meeting#07.
13	-	~~2024.12.26~~	No meeting due to the winter break.
14	-	~~2025.01.02~~	No meeting due to the winter break.
15	11	2025.01.09	Project meeting#08.
16	12	2025.01.16	Project meeting#09.
17	13	2025.01.23	Project meeting#10.
18	14	2025.01.30	Evalution meeting#01, basic term.
19	-	2025.02.06	Evalution meeting#02, second term (optional).
20	-	2025.02.13	Evalution meeting#03, third term (optional).

Grading policy

The laboratory uses a standard university grading scale, beginning with 2.0 as a failing grade and passing grades from 3.0 to 5.0 with a progression of 0.5. It progressively denotes students’ performance from satisfactory to very good. The final laboratory grade is calculated based on the grade coefficient $\sigma$ . In the following paragraphs, you will learn how to calculate this coefficient and the final laboratory grade.

During the semester, you will acquire points for performing graded tasks. The table below lists grade segments, their scopes and weights.

$i$	Grade segment	Segment scope	$\psi_i$
1	The proposal	Team	$0.10$
2	The review	Individual	$0.50$
3	The log	Individual	$0.25$
4	The report	Team	$0.15$

The assessment of the whole project is divided into four separate segments. Each segment is either in individual or team scope. The points within individual segments are assigned to each student and are based on individual performance. So as a result, each person within a team can obtain a different amount of points in those segments. On the other hand, points within team segments should be a result of collaborative effort and therefore each person within the team will receive the same amount of points. The laboratory grade coefficient $\sigma$ is calculated as weighted arithmetic mean using the following formula

\sigma = \left\lfloor P \cdot \left( \sum_{i=1}^{4} \frac{\omega_i}{\Omega_i} \cdot{} \psi_i \right) \cdot \left( \sum_{i=1}^{4} \psi_i \right)^{-1} \right\rfloor ,

where $\lfloor x \rfloor = \max \{ k \in \mathbb{Z} : k \leq x \}$ , $0 < P \le 100$ is a project coefficient, $\omega_i$ denotes the number of points that the student got from $i^{\mathrm{th}}$ segment, $\Omega_i$ denotes the maximal amount of points within the $i^{\text{th}}$ segment, while the contribution of the $i^{\text{th}}$ segment to the grade coefficient $\sigma$ is given by weight $\psi_i$ .

The project coefficient $P$ reflects overall quality of the design idea, its advancement, and how well the design idea match to the size of the team. The initial value of $P$ is estimated based on the proposal, so you will know where you stand. The final value of project coefficient $P$ is set during the evaluation meeting. By the rules, final value of the project coefficient can't be lower than its initial estimation.

In summary, the project coefficient depends solely on the design, all the other points you can collect during the semester depend on how you deliver and develop that design.

Note that the team must submit the proposal and the report to be eligible for a passing grade.

The final laboratory grade is strictly determined by a grade coefficient $\sigma$ and the table below presents the dependency between the final laboratory grade and a grade coefficient.

Final Grade	Interval
2.0	$\sigma \in (-\infty, 50)$
3.0	$\sigma \in [50, 60)$
3.5	$\sigma \in [60, 70)$
4.0	$\sigma \in [70, 80)$
4.5	$\sigma \in [80, 90)$
5.0	$\sigma \in [90, +\infty)$

The grading scale is set according to § 13. GRADING SCALE from the AGH University of Kraków study regulations, applicable from 1st of October 2023.

Honor code

You can use any books, papers, references, and publicly available implementations for ideas and code that you may want to incorporate into your project. However, you must clearly cite all your sources in your write up and source code. The project must be a result of work done by the team. Contributions of third-party are strictly forbidden.

If you are combining your project with the project from another course, you must receive permission from the laboratory instructor. In addition, you must provide:

Clear explanation in the proposal and report the exact contributions carried out in this project.
Separate reports for each course (include them in final submission as well).

Team formation

The project must be realized as a collaborative effort within a group of students. The permissible number of students in a team is up to four people, while the recommended number of students in a team is two people. The team should be formed by students with similar knowledge, technical skills, and coinciding design ideas.

The number of students in a team should be appropriately matched to the workload that design requires since it is expected that each team member commit similar work hours towards developing the project. Keep in mind that the larger the team, the more time will be needed to organize its work. Also, it will be more difficult to organize work within the team well and efficiently.

For teams larger than two members, it is recommended to select one member as a project architect (the mastermind of the project), whose job is to plan and coordinate work at a high level within the team. The project architect can obtain bonus points, if done well. If you select a project architect, please state it clearly in the proposal.

The official team formation is done by submitting your proposal.

Project details

Design expectations

The expectation for the design is that it must be implemented as software. This means that all functionalities and processes must be developed with a programming language in the form of a source code, that can be compiled or interpreted, and in the end, executed on a computing unit.

You are free to choose any subject of your design, and any technology stack to implement the design. However, some constraints must be followed.

Each design must address a problem using engineering techniques.
The outcome of the design must be evaluable in a well-defined, repeatable, and deterministic way.
The technology stack used to implement the design must be free and open-source.
Any two teams must not carry out the same design.

The problem you choose to solve does not necessarily need to be practical. It can be abstract, unconventional, or even far from practical. The key requirement is that your design applies engineering techniques to provide a solution. However, it is recommended that the design is both practical and useful.

The design should be simple since you as the team must complete it within one semester. Note that this does not imply that the design or its realization can be trivial. It should possess some challenges that you will have to face. It is recommended to use or combine at least a few engineering techniques in your project. The total workload per team member to complete assigned work is expected to be about 60 working hours.

The proposal

The project proposal is a document that tells what you are planning to do for the project. It introduces and discusses the design idea, formalizes the subject of your project, sets your goals, and plans your work. The potential reader of the proposal should grasp a good understanding of your design idea and the plan for its realization. The proposal must be no longer than four double-column pages with a font size of 10pt and must be written in the English language. You must use a specific template for the document.

A well-written proposal should include the information listed below, but is not necessarily limited to:

Project title.
List of team members.
Good introduction and background material on a problem you are solving with your design. Make a short discussion about why the problem is important and/or challenging in general but wider context.
Clear and precise problem formulation (or specification) with objectives.
A brief description of how you plan to solve it.
An approximate timeline of work (please refer to weeks from the laboratory schedule).
At least two milestones. The milestone is a feature list you state to complete due to a date. The feature list should state, as clear as possible, of what you want to accomplish by the milestone. The last milestone should correspond to completed design and its date should be set at least 7 days before assumed evaluation meeting.
Preliminary division of labor between the team members.
Technology stack with a short discussion about the choice.
References.

The organization of this document is at the discretion of the team and does not need to be done in the above order. However, the specified pieces of information are requested and should be included.

You should send complete proposal to me (laboratory instructor) via e-mail. The file format of the document must be Portable Document Format (PDF). Other formats are not accepted and will be automatically rejected. Only one team member should send a proposal, but do not forget to carbon copy (CC) the message to the other team members.

The deadline for sending proposal is 2024.11.06.

In the reply to the message, the team will obtain the proposal coefficient $\omega_1$ and the proposed project coefficient $P$ . The proposal will be graded according to the following criteria:

Introduction, topic review, discussion (20%)
Clear problem statement (15%)
Preliminary approach description (10%)
Project plan, milestones, division of labour (30%)
Technology stack discussion (10%)
Writing and formatting (15%)

The log

The log corresponds to the overall realization of the project plan, keeping the log, and consistency of the work throughout the semester. The main aspect of this segment is the log. The basic buildings blocks of The log are git commits and Forgejo's issues, pull request, and milestones. It should document your work progress and present how you organize your work. In other words, you should document what you are currently doing and what are you going to do in the near future by planning minor (incremental) tasks. The log should be maintained in such a way that a bystander reading the log can figure out more or less what is going on part of the project you are implementing. It is expected that on average you have at least a few minor contributions each week.

To keep your log in good condition, you are requested to use the following features of Forgejo:

issue tracker,
issue labels,
issue time tracking,
pull requests,
milestones,
projects,
each commit must be bound to the issues,
each commit must have a meaningful commit message,
each feature must be developed in separate branch,
each feature branch must be merged into main branch via pull request,
each pull request must be reviewed and approved by other team member.

It is very important to keep the log up to date in the context of the review. It is also recommended that all communication and discussions related to the development of the project be conducted through the issue tracker.

Remarks

Pay particular attention to handle correctly authorship of commits, since only the code committed by you will be considered as your contributions.

If at some point the code you commit to the repository is generated by other program, you must prepare a separate commit that include generated code, with a clear statement in commit's message that the code is generated by program. The message should also include all commands that generated the code.

The review

The project review is a oral colloquium in which the main topic is the contributions you have made. You should be able to smoothly present details of your already contributed work. It includes the ability to explain, modify, compile and run the code from your branches, branches you reviewed, and from the main branch. If I am not able to run the project during the review due to required computing platform, operating system, or other reasons, you have to provide a computing unit to run the project.

It is highly recommended that you maintain the quality and clarity of your contributions. Plan the structure of the project so that it makes logical sense. Use meaningful names in your project so that a bystander doesn't have to guess too much about what a particular element or variable is used for. Provide short auxiliary comments in your code so that one can deduce more quickly what a given block implements. It will help you not only during the review but also during the development of the project.

The report

The report is a summary of your design idea and a description of the result that the team produced. The main aim of the article is to introduce the potential reader to the problem, approaches to solve it, and evaluation of those approaches. It should also be a kind of own work review. Remember that the report should be neutral about the project. Reject the idea that you did the project and don't be afraid to criticize things that you think require it. Keep in mind that the report is not detailed documentation of the project describing every functionality. The write up should be self-contained and be structured similarly to a conference or journal paper. The report must be no longer than 10 double-column pages with a font size of 10pt, and it must be written in the English language. It is required to use a specific template for the document.

The following is just a suggestion for the scheme of the report, but it should be a good starting point for most projects:

Header: It should contain the project title and author’s names.
Abstract: It should briefly describe the content of the report, i.e., problem, approaches, and main results. There should be no more than 300 words.
Introduction: Good introduction and background material on the problem and the design. Discussion and try to refer to literature related to the problem. It should extend the introduction from the project proposal.
Problem formulation: A clear and precise formulation of the problem.
Methods, approaches, solutions: Describe and discuss approaches you decided to implement. Explain the reasons why you selected those particular methods. Compare pros and cons.
Evaluation: Describe and discuss the evaluation you performed to demonstrate the effectiveness of the employed methods. Define and explain evaluation metrics. Determine the impact of various components of your system.
Conclusions: Summarize your project. Distinguish key results.
Changes: Describe differences and changes between the initial design from the proposal and final result.
References: References to the literature.

The description of each bullet point is a suggestion of what is expected, but it should not limit the content of the article. Since it's the team's burden to write a report up, the team has the right to compose the article in another more suitable manner for the project. Keep in mind that a well-written proposal is a great starting point.

You should send the report to me (laboratory instructor) via e-mail. The file format of the document must be Portable Document Format (PDF). Other formats are not accepted and will be automatically rejected. Only one team member should send the report, but do not forget to carbon copy (CC) the message to the other team members. In the reply to the message, I will send you invitation for the evaluation meeting.

The deadlines for sending the report are the following:

2025.01.27 for the Evaluation meeting#01 (basic term).
2025.02.03 for the Evaluation meeting#02 (second term).
2025.02.10 for the Evaluation meeting#03 (third term).

As a result, the team will obtain coefficient $\omega_4$ . The report will be graded according to the following distribution:

Introduction and background (20%).
Description of the problem, solution, and evaluation (60%).
Report organization (10%).
Writing and formatting (10%).

Changelog

2024.11.12: Minor spelling corrections.
2024.10.07: Document published.