Design Laboratory

Edition: Winter semester 2023/2024.

The Design Laboratory is a course where you have to establish a team, propose the design, and realize it. The main focus of this course is not the design itself, but the labor around the project. You will have to plan how to split and organize the work in the team, keep a log of your tasks, and document your work progress. The design itself is a secondary objective, but a wise design choice is crucial for a smooth journey through the semester.

During the coursework you will be required to use following software tools as a part of your workflow:

• git for source code management,

• Forgejo for web user interface for git and project management system.

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 lab instructor that will supervise you during the project. The table below lists the information about the laboratory staff as well the contact information.

• Szymon Woźniak (office hours, contact).

Laboratory organization

In this section, you will find some details about laboratory organization. There are 14 meetings in the semester and three types of them. Types are as follows:

• Introductory meetings (1 meeting),

• Proposal meetings (2 meetings),

• Project meetings (11 meeting).

Most of them are in the form of consultations, where you will discuss your project development with me. In the following parts of this section, there is a short description of each meeting type. Lastly, meeting sign-in procedure and the schedule of laboratory meetings is presented.

Introductory meeting

The purpose of the introductory meeting is to resolve any ambiguities and doubts about the organization of the laboratory. The meeting will be divided into two parts. The first part will focus on a discussion of the organization of the laboratory, the grading policy, and the organization of work during the semester. Next, we will talk about design expectations. The second part of this meeting will shortly discuss a source code management system (git) and a project management system embedded within Forgejo, that you will use during the semester.

Before this meeting, you should already have a fairly good familiarity with the content of this page.

Proposal meetings

These two meetings are in the individual or team consultation form where you can discuss your design idea and proposal 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 project proposal document.

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

Project meetings

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 Register for the meeting for details.

Some Project meetings will also include Project review. You will be notified about it beforehand in the meeting schedule. 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.

Registration for the meetings

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

1. I open an issue at the issue board of the repository 2023-org. The subject of the issue will be unambiguous. Moreover, it will contain the date and subject of the meeting from the schedule. The issue will be opened at least a few days before the meeting.

2. You are writing a reply to the issue. "I am in." is good enough. If you want to come in a group, please point it out in the post by mentioning other team members who will come with you. You can enroll until the schedule is published.

3. I publish the schedule of the meeting every Wednesday on which classes are held before noon. It will be published as a post in the original issue where you registered for the meeting. The schedule will specify the exact time of the meeting with each person/team.

Don't forget to check the schedule even if you didn't register for a particular meeting, since you can be invited for project review.

Schedule

The winter semester consists of 17 weeks. It allows us to realize all planned (14) meetings. The first meeting focuses on the introduction and organization. Next two will concern project proposal. The remaining meetings are allocated for the project meetings. Additionally, the following notation was applied for dates:

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

Week	Lab nr	Date	Subject
01	-	~~2023.10.04~~	No class due to Rector's hours.
02	01	2023.10.11	Introductory meeting
03	02	2023.10.18	Proposal meeting#01
04	03	2023.10.25	Proposal meeting#02
05	-	~~2023.11.01~~	No meeting due to All Saints' Day
06	04	2023.11.08	Project meeting#01
07	05	2023.11.15	Project meeting#02
08	06	2023.11.22	Project meeting#03
09	07	2023.11.29	Project meeting#04
10	08	2023.12.06	Project meeting#05
11	09	2023.12.13	Project meeting#06
12	10	2023.12.20	Project meeting#07
13	-	~~2023.12.27~~	Winter holidays
14	11	2024.01.03	Project meeting#08
15	12	2024.01.10	Project meeting#09
16	13	2024.01.17	Project meeting#10
17	14	2024.01.24	Project meeting#11 + final grading

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 weights, and theirs deadlines if exist.

$i$	Grade segment	Segment scope	$\psi_i$	$\Omega_i$	Deadline
1	Proposal	Team	$0.05$	10	2023.10.29
2	Work organization and progress	Individual	$0.40$	14	-
3	Project review	Individual	$0.35$	3	-
4	Article	Team	$0.20$	10	2024.01.23

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 contribution of the $i^{\text{th}}$ segment to the grade coefficient $\sigma$ is given by weight $\psi_i$, while $\Omega_i$ denotes the maximal amount of points of the $i^{\text{th}}$ segment. Deadlines are strict and exceeding the deadline is penalized by halving the points per each day of being late. The deadlines are by the end of a given day. 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 \cdot \rfloor$ is the floor function, $\omega_i$ denotes the number of points that the student got from $i^{\mathrm{th}}$ segment, and $0 < P \le 100$ is a project coefficient.

The project coefficient reflects overall quality of the design idea 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 is set when you finish the project. By the rule 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 that design.

Note that the team must submit the proposal and the article to be eligible for a passing grade. Additionally, the team may be requested to present and discuss the outcome of the project in person after final deadline if the assessment requires it.

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.

$j$	Final Grade	Interval
1	2.0	$\sigma \in (-\infty, 50)$
2	3.0	$\sigma \in [50, 60)$
3	3.5	$\sigma \in [60, 70)$
4	4.0	$\sigma \in [70, 80)$
5	4.5	$\sigma \in [80, 90)$
6	5.0	$\sigma \in [90, +\infty)$

The grading scale is the same as the AGH's study regulations require (article 13, "SKALA OCEN").

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. Under no circumstances are you allowed to look at another group’s code or incorporate their code into your project. 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 idea.

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 the 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 an project architect (the mastermind of the project), whose job is the plan and coordinate work at high-level within the team. The project architect can obtain bonus points within Work organization and progress grade segment. If you select project architect, please state it clearly in the project proposal.

The official team formation is done by submitting a project proposal.

Project details

In this section, you can find details about expectations from particular project segments.

Design expectations

You are free to choose any subject of your design. However, some constraints must be followed.

First, each design must solve some practical problem using engineering techniques. The outcome of the project must be evaluable in a well-defined, repeatable, and deterministic way. For example, designing an aesthetically pleasing user interface for some tool, where aesthetics are paramount, will not be a good design idea.

Secondly, 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.

Lastly, any two teams must not carry out the same design.

Project 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 organizes your work. The potential reader of the proposal should acquire 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).

• Two milestones and a statement, as clear as possible, of what you want to accomplish by first milestone and by the end of the project.

• 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 necessary and should be included.

You should send complete proposal to me (laboratory instructor) via email message by the deadline. The deadline for the proposal can be checked in the table, in Section Grading policy. The file format of the document must be Portable Document Format (PDF). Other formats are not accepted and will be automatically rejected.

As a result, the team will obtain the proposal coefficient $\omega_1$ and the proposed project grade 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 (5%)

• Writing and formatting (20%)

Work organization and progress

The work organization and progress segment 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 log is built with Forgejo issues and git commits. 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 and git:

• Issue tracker.

• Use issue labels.

• Milestones.

• Time tracking.

• Each commit must be bound to the issues.

• Each commit must have a meaningful commit message.

It is also recommended that all communication and discussions related to the development of the project be conducted through the issue tracker.

Project review

The project review is a short oral colloquium in which the main topic is the contributions you have made. You should be able to smoothly present and explain details of your already contributed work.

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

Article

The article 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 12 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 article 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.

The article should be committed into the root of the project repository by the deadline. The filename name of the article must be ARTICLE.pdf. The deadline can be checked in the table, in Section Grading policy. The file format of the document must be Portable Document Format (PDF). Other formats are not accepted and will be automatically rejected.

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

• 2023.10.12: Deadline for the project proposal to 29.10.2023.

• 2023.09.25: Document published.