SZYMON M. WOŹNIAK

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:

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

  1. Design laboratory
  2. Staff
  3. Prerequisites
  4. Laboratory organization
    1. Introductory meeting
    2. Proposal meeting
    3. Project meeting
    4. Evaluation meeting
    5. Signing in for a meeting
  5. Schedule
  6. Grading policy
  7. Honor code
  8. Team formation
  9. Project details
    1. Design expectations
    2. The proposal
    3. The log
    4. The review
    5. The report
  10. Changelog

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:

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:

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:

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

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

WeekLab nrDateDescription
01-~~2024.10.03~~No meeting due to deans' schedule.
02012024.10.10Introductory meeting.
03022024.10.17Proposal meeting#01.
04032024.10.24Proposal meeting#02.
05-~~2024.10.31~~No meeting due to friday's schedule this day.
06042024.11.07Project meeting#01.
07052024.11.14Project meeting#02.
08062024.11.21Project meeting#03.
09072024.11.28Project meeting#04.
10082024.12.05Project meeting#05.
11092024.12.12Project meeting#06.
12102024.12.19Project meeting#07.
13-~~2024.12.26~~No meeting due to the winter break.
14-~~2025.01.02~~No meeting due to the winter break.
15112025.01.09Project meeting#08.
16122025.01.16Project meeting#09.
17132025.01.23Project meeting#10.
18142025.01.30Evalution meeting#01, basic term.
19-2025.02.06Evalution meeting#02, second term (optional).
20-2025.02.13Evalution 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.

iiGrade segmentSegment scopeψi \psi_i
1The proposalTeam0.10 0.10
2The reviewIndividual0.50 0.50
3The logIndividual0.25 0.25
4The reportTeam0.15 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

σ=P(i=14ωiΩiψi)(i=14ψi)1, \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 x=max{kZ:kx} \lfloor x \rfloor = \max \{ k \in \mathbb{Z} : k \leq x \} , 0<P1000 < P \le 100 is a project coefficient, ωi \omega_i denotes the number of points that the student got from ithi^{\mathrm{th}} segment, Ωi \Omega_i denotes the maximal amount of points within the ithi^{\text{th}} segment, while the contribution of the ithi^{\text{th}} segment to the grade coefficient σ\sigma is given by weight ψi\psi_i.

The project coefficient PP 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 PP is estimated based on the proposal, so you will know where you stand. The final value of project coefficient PP 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 GradeInterval
2.0σ(,50) \sigma \in (-\infty, 50)
3.0σ[50,60) \sigma \in [50, 60)
3.5σ[60,70) \sigma \in [60, 70)
4.0σ[70,80) \sigma \in [70, 80)
4.5σ[80,90) \sigma \in [80, 90)
5.0σ[90,+) \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:

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.

  1. Each design must address a problem using engineering techniques.

  2. The outcome of the design must be evaluable in a well-defined, repeatable, and deterministic way.

  3. The technology stack used to implement the design must be free and open-source.

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

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 ω1\omega_1 and the proposed project coefficient PP. The proposal will be graded according to the following criteria:

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:

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:

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:

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

Changelog