From algorithm to engineering thinking: a new model of teaching at the department
From algorithm to engineering thinking: a new model of teaching at the department
Below – how it works and how it looks like on the example of the discipline «Algorithms and data structures».
Why individual labs are no longer enough
What does it mean to learn an algorithm? Know the definition, reproduce the pseudocode, write a program in the laboratory, assess the complexity. All this is necessary, but it is not enough.
In laboratory work, the algorithm exists by itself. It works on prepared data, in isolation from any system, and the question «why is he here» simply does not arise. The higher education applicant passes the topic and proceeds to the next one.
Real understanding begins when it is necessary to determine where the algorithm is needed in a real system, why it is needed, what to compare it with, how to prove the correctness of the implementation and at what price the winnings are given. It is on this that the department builds a new model of teaching.
How the model works
A team of four to six higher education students receives not the task of «implementing the Huffman algorithm», but a complex system with resource, time and reliability limitations. To make it work, you have to combine data structures, greedy algorithms, dynamic programming, compression, a neural network, genetic algorithms, and cryptographic protection.
The key difference is that each algorithm appears not because this topic is in the course program, but because it does not solve a specific engineering problem without it.
The training logic changes as follows:
instead of «we studied the algorithm, → passed the topic» – «there was a problem, → found an algorithmic solution, → implemented, → checked, → compared, → made a conclusion».
The model is based on five principles.
Correctness first, then complexity. Higher education applicants do not start with a neural network or a genetic algorithm. First, the system must perform the simplest operation: input, processing, output, accurate recovery. Then one algorithm is added, tested separately, and after integration all previous tests are run again. A complex system grows out of a sequence of small correct steps.
The data format is set by the instructor, not the team. Each team receives a specification described to the bit and a set of reference files that its system is required to read correctly. Own transmitter and own receiver can have the same error and understand each other perfectly, so the real test is someone else's data. Due to the common format, systems of different teams can exchange data with each other.
The program should not be shown, but tried to be hacked. In a traditional laboratory, a higher education student is looking for an example on which everything works. Here the task is the opposite: to find a case in which your own program will break. Empty data, one item, zero budget, corrupted byte, incorrect password, truncated file. A higher education applicant gradually moves from the question «whether my program is launched» to a much more mature one «under what conditions can I trust its result».
A more sophisticated algorithm doesn't have to win. Dynamic programming can produce the same result as a simple greedy algorithm. The genetic algorithm may lose to a random search. A neural network may barely improve the system. This is not a failure of the project. Failure occurs when a higher education student cannot explain why this happened. The ability to set up an experiment, get a result and draw a reasonable conclusion from it is assessed, rather than the ability to adjust the desired figure in advance.
Reproducibility is assessed, not presentation. Before the defense, the team makes a clean run: a new environment, repository cloning, installing dependencies, tests, launch, experiment. The graphs in the report must be obtained from the final version of the code, and each experiment is accompanied by a record of the code version, input data and parameters. The other person should be able to repeat it.
Example: «Algorithms and Data Structures»
The team chooses one of three options: a secure, bandwidth-limited telemetry channel, a smart file archiver, or a priority event log replication system.
Let's take the first one. The device transmits telemetry to the ground station by a narrow channel, which loses packets and is listened to. The task seems to boil down to «compress and encrypt.» But in an emergency scenario, a situation arises that is not in the textbook.
Of the forty-seven packets, only thirty-two manage to transmit the channel. Seven more of them are lost on the way.
Slightly more than half of the data reaches the receiver. And here, for the first time, a higher education student is faced with the fact that the problem of the backpack is not an exercise from the collection. It is necessary to solve, What put in each batch when there is less space than data, and in what order send packages until the time budget is exhausted. Critical footage needs to get into early packs or it won't make it at all.
Next, the team compares the exact algorithm with a simple greedy one and gets a table like this:
| Data type | Greedy | Exact algorithm | Win |
| Natural text | 14,152 bits | 13,532 bits | 4,4 % |
| Source code | 24 128 | 22 161 | 8,2 % |
| Bitmap | 6 233 | 6 233 | 0 % |
| Already compressed data | 71 975 | 71 973 | 0 % |
Two zeros in this table are no less valuable than wins. The applicant for higher education should explain why, on regular data with long repetitions, greedy choices coincide with optimal ones, and there are practically no repetitions on already compressed data, so there is nothing to optimize. This is research work, not laboratory work.
(digits)
| Indicator | Value |
| Duration | 13 weeks |
| Composition of the team | 4–6 higher education students |
| Breakpoints | Slice 0 and three checkpoints |
| Semester assessment | 60 points: project (40) and laboratory (20) |
| Proportion of individual assessment | 70 out of 100 project points |
The last line is fundamental. Only thirty points out of a hundred are attributed to the overall quality of the product. The rest is the applicant's own area of responsibility, the history of his work in the repository, the effectiveness of his reviews of someone else's code and personal protection.
Therefore, «being in a team» is not enough to get points for someone else's work. Conversely, the team will not suffer because one did more than the other.
Our stance on artificial intelligence
The question that is most often asked today is whether AI will write everything for the graduate student?
We do not prohibit such tools. The ban does not work, and the ability to use them is part of modern engineering practice. But the use is allowed under three conditions.
First: the higher education applicant declares the use in the META-USAGE file – what tools, what requests, what fragments have been received and what has been changed in them. Secondly, he explains why he chose this particular method of application and what the alternatives were. Third, the main thing: he understands each fragment received and can explain how it works and how its correctness is checked.
The answer «this was written by the chat, I don't know how it works» means that this part of the work was not done by the higher education student.
Academic integrity acts as a multiplier before the final evaluation of the project, and not as a separate criterion. High scores for other items do not compensate for it.
The rule that we formulate for higher education students:
You can use the tool, but you cannot delegate to it the responsibility for understanding your own project.
What higher education student will be able at the end
These are the skills he then learns from the job requirements.
- Work according to a strict specification, when the format is not discussed and checked by someone else's data.
- Break down a large task into components with defined responsibilities.
- Write tests that look for a bug rather than confirm that everything is fine.
- Set up an experiment, measure and interpret the result, in particular zero.
- Justify the choice of the algorithm by complexity and measurements, and not by intuition.
- Work in a team on a professional process: task, branch, merger request, review, merger.
- Make the work reproducible so that it can be repeated without an author.
- Defend your own solution and adapt it when conditions change on the go.
The last point should be explained separately. In defense of a higher education student, they ask «why does a greedy algorithm not guarantee the optimum», and then change the condition: the budget has decreased by thirty percent, which will change in your algorithm and in the behavior of the system? Such a question cannot be learnedby heart.
What is changing for the teacher
The role of the teacher is also different. It does not just accept the work, but creates a controlled environment: a specification, its own reference implementation, correct and intentionally damaged files, a hidden selection for final verification, unified measurement rules.
Thanks to this, the rating is less dependent on the experience «the project looks good». Instead, it checks what can be checked: works or not, restores data accurately or not, passes checks or not, gives a better metric or worse.
What is new
Some elements of this approach have long been known and used in Ukrainian and world university education: team projects, version control, code review, automatic testing, checkpoints, comparison of algorithms.
Our contribution is not in each of these elements separately, but in the fact that they are consolidated into one holistic methodological system within one discipline: from the first statement of the problem to hidden assessment, mutual checks between teams and reproduction of the final result.
Looking through the open teaching materials, we find a lot of strong individual practices, but we did not come across a description of the course of algorithms organized as such a detailed formalized cross-cutting team project. This is where we see the methodological novelty of the approach.
Learn more
Guidelines for the implementation of the project, the conditions of all three options and examples of reference materials are available on the discipline page.
If you are a teacher and want to apply this model in your course or discuss the details of the assessment, write to us: we are sharing materials.
Department of Software Systems and Technologies