Lab 7

Lab 7 — Final Integration, Demonstration and Code Review

Objectives

This laboratory is the final project session.

The objective is to demonstrate that the semester project is complete, reproducible, technically understood by the team and ready for evaluation.

Unlike the previous laboratories, this session is centered on:

• final integration;
• project demonstration;
• architecture explanation;
• code walkthrough;
• technical discussion;
• verification of tests and documentation;
• evaluation of project quality;
• final submission.

By the end of this laboratory, each team should be able to:

• run the project from a clean and documented setup;
• demonstrate the primary application workflow;
• explain the architecture of the project;
• explain the responsibility of the main modules;
• justify important design decisions;
• explain how errors are handled;
• explain how the project is tested;
• discuss one important technical problem encountered during development;
• identify known limitations;
• show that the repository is complete and clean;
• answer technical questions about its own implementation.

1. Final laboratory structure

A possible structure for the two-hour session is:

Time	Activity
0–10 min	Final setup and repository verification
10–80 min	Project demonstrations
80–105 min	Code walkthrough and technical discussion
105–115 min	Final repository and documentation checks
115–120 min	Submission confirmation

The exact timing depends on the number of teams.

2. What should be ready before the session

Before the final laboratory begins:

• the core feature set should be frozen;
• no P0 defects should remain;
• the main workflow should work end-to-end;
• tests should pass;
• installation instructions should be complete;
• the README should be up to date;
• known limitations should be documented;
• the repository should not contain secrets or unnecessary generated files;
• the team should have a stable demonstration scenario.

Lab 7 should not be used for major architecture changes.

3. Final project state

The expected state is:

implemented
    ↓
tested
    ↓
documented
    ↓
reproducible
    ↓
demonstrable
    ↓
explainable

A project that only runs on the original developer's machine is not yet ready for final evaluation.

4. Demonstration first, slides second

The primary evidence of a working project is the software itself.

The demonstration should focus on:

1. starting the application;
2. providing representative input;
3. executing the main workflow;
4. showing the output;
5. showing one relevant error condition;
6. explaining the result.

Slides may be used for context, but they should not replace a live demonstration.

5. Recommended demonstration structure

A concise demonstration can follow:

Problem
  ↓
Input
  ↓
Execution
  ↓
Result
  ↓
Failure case
  ↓
Short technical explanation

The demonstration should show the central objective of the project clearly.

6. Demonstration time

The demonstration should be concise.

A reasonable target is approximately:

5–8 minutes

depending on project complexity.

The objective is not to show every implemented feature.

Show the most important workflow reliably.

7. Demonstration reliability

Avoid a demonstration that depends on:

• unstable public services;
• unavailable hardware;
• unknown network connectivity;
• private local files;
• credentials not available during evaluation;
• large downloads;
• manually prepared state that cannot be reproduced.

If an external dependency is required, prepare a safe fallback demonstration strategy where possible.

8. Representative input

The demonstration should use input representative of the actual project.

For example:

Project type	Representative input
image processing	real or realistic image
data analysis	meaningful dataset
networking	valid application message or packet
hardware	real device or recorded representative data
monitoring	realistic metric stream
file processing	correctly structured input file

Avoid demonstrating only trivial toy input when the project is designed for a more realistic workload.

9. Show one error condition

A useful final demonstration includes one expected failure.

Examples:

• invalid input;
• missing file;
• malformed configuration;
• unavailable device;
• invalid packet;
• unsupported image format;
• timeout.

The goal is to show that the project handles predictable failure conditions deliberately.

10. Architecture explanation

Each team should be able to explain the architecture in approximately one or two minutes.

A good explanation identifies:

• inputs;
• main components;
• data flow;
• external dependencies;
• outputs.

For example:

CLI
 │
 ▼
Application service
 │
 ├── parser
 ├── processing pipeline
 └── storage
        │
        ▼
     output file

11. Architecture diagram

A simple architecture diagram is sufficient.

Avoid diagrams that show every function or variable.

Focus on major components.

Example:

main
 ├── config
 ├── service
 │    ├── model
 │    └── processor
 └── storage

12. Explain responsibilities

For each main module, the team should be able to complete:

This module is responsible for ...

For example:

Module	Responsibility
models.py	application data structures
services.py	central application logic
storage.py	persistent data access
protocol.py	message encoding and decoding
main.py	application startup and orchestration

13. Code walkthrough

The code walkthrough should not attempt to read the entire repository.

Choose the most important implementation path.

For example:

main()
  ↓
load configuration
  ↓
create service
  ↓
process input
  ↓
produce result

Explain how the main workflow maps to the source code.

14. What to show during code review

Useful areas include:

• application entry point;
• core processing logic;
• one important model or class;
• one error-handling path;
• one representative test;
• one external integration boundary.

Do not spend presentation time showing trivial boilerplate.

15. Explain one design decision

Each team should prepare one important design decision.

For example:

Why was composition used instead of inheritance?

Why was JSON selected for persistence?

Why was a pipeline separated into stages?

Why was dependency injection used?

Why was the protocol parser separated from network transport?

The answer should include the reasoning and trade-offs.

16. Design trade-offs

Most design decisions have advantages and disadvantages.

A useful explanation is:

We selected approach A because ...
The main advantage is ...
The main disadvantage is ...
Approach B was considered, but ...

Avoid claiming that a design has no disadvantages.

17. Explain one technical difficulty

Each team should identify one meaningful technical difficulty encountered during the project.

Examples:

• parsing an undocumented format;
• synchronizing hardware communication;
• handling malformed packets;
• managing asynchronous operations;
• correcting image-processing artifacts;
• making a component testable;
• debugging a dependency issue;
• designing data serialization.

The explanation should focus on the technical reasoning used to solve the problem.

18. Explain the debugging process

A useful structure is:

Observed behavior
      ↓
Hypothesis
      ↓
Diagnostic method
      ↓
Root cause
      ↓
Fix
      ↓
Regression test

This demonstrates engineering process, not only the final result.

19. Testing explanation

The team should be able to explain:

• what is tested;
• why those areas are important;
• what is not tested;
• which tests are unit tests;
• which tests are integration tests;
• how external dependencies are handled.

20. Show one representative test

For example:

def test_average_rejects_empty_list():
    with pytest.raises(ValueError):
        average([])

or:

def test_round_trip(tmp_path):
    path = tmp_path / "data.json"

    save_data(path, original)

    restored = load_data(path)

    assert restored == original

The test should demonstrate meaningful project behavior.

21. Tests should pass

Before the demonstration:

pytest

should complete successfully.

If some tests are intentionally skipped, the reason should be understood and documented.

22. Quality checks

Run the project's normal quality checks.

For example:

ruff check .
pytest

If static type checking is part of the project:

mypy src

If formatting is enforced:

ruff format --check .

23. Final clean installation test

The project should have been tested in a clean environment before Lab 7.

A typical procedure:

python -m venv clean-env
source clean-env/bin/activate

python -m pip install -e .

pytest
python -m project_name

If these steps fail, the project is not reproducibly packaged.

24. Windows clean setup

For Windows PowerShell:

python -m venv clean-env
clean-env\Scripts\Activate.ps1

python -m pip install -e .

pytest
python -m project_name

Document platform-specific requirements where necessary.

25. README final review

The README should contain at least:

Project name
Description
Main features
Requirements
Installation
Configuration
Running
Example usage
Testing
Architecture overview
Known limitations

Another developer should be able to start the project using only this information.

26. Repository structure

A final project may resemble:

project/
├── README.md
├── pyproject.toml
├── .gitignore
├── src/
│   └── project_name/
│       ├── __init__.py
│       ├── main.py
│       └── ...
├── tests/
│   └── ...
└── examples/
    └── ...

Not every project requires the same modules.

27. Repository cleanliness

The repository should generally not contain:

.venv/
__pycache__/
*.pyc
.pytest_cache/
.mypy_cache/
.ruff_cache/
.coverage
temporary output
real secrets
large accidental binaries

unless a specific generated artifact is deliberately required.

28. Git status

Before submission:

git status

should not show forgotten modifications or accidentally generated files.

29. Git history

Inspect:

git log --oneline --graph --decorate

The history should show meaningful development rather than one final upload.

Useful examples:

Add packet decoder
Implement device retry handling
Add regression tests for invalid frames
Refactor configuration loading
Document installation procedure

30. Final commit

A final commit may be something like:

Prepare final project release

but the repository should already contain meaningful previous commits.

31. Tagging a release

Optionally, create a final release tag.

For example:

git tag v1.0.0

If tags are used:

git push --tags

This is optional unless required by the course.

32. Version consistency

If the project uses a version:

[project]
version = "1.0.0"

ensure documentation and release tags do not contradict it.

33. Known limitations

Known limitations should remain visible in the final documentation.

For example:

## Known limitations

- Only PNG input is supported.
- Device reconnect requires application restart.
- The project has only been tested on Linux.

Do not remove limitations merely to make the project appear more complete.

34. Final acceptance test

Before presentation, execute one complete acceptance test.

Record:

Input:
Command:
Expected output:
Actual output:
Result:

The main workflow should pass.

35. Demonstration backup

For projects with fragile external dependencies, prepare a backup.

Possible backups include:

• representative recorded data;
• stored sample responses;
• local test server;
• simulated hardware interface;
• known-good sample images.

A backup should still demonstrate the project's own logic.

36. Do not fake the primary functionality

A backup may replace an unavailable external dependency.

It should not replace the actual project implementation.

For example:

acceptable:
recorded sensor data → real processing pipeline

not acceptable:
precomputed final output shown instead of processing

37. Technical questions

Students should be prepared for questions such as:

• Why is this component a class?
• Why is this function separate?
• Why does this module depend on that one?
• What happens if this file is missing?
• What happens if this network request times out?
• How is this behavior tested?
• What would need to change to support another input format?
• Which part was most difficult?
• Where is configuration stored?
• Why was this library selected?
• What is one limitation of the current implementation?

38. Questions about Python

The project discussion may also include concepts from Labs 1–4.

For example:

• difference between == and is;
• list/reference semantics;
• properties;
• dataclasses;
• inheritance versus composition;
• modules and packages;
• exceptions;
• context managers;
• type hints;
• pytest fixtures;
• parametrized tests;
• dependency injection.

The objective is to connect the project implementation to the Python concepts studied during the course.

39. Explain code ownership

Every team member should understand the main project architecture.

A student should not answer:

"I don't know; another team member wrote that file."

for central project functionality.

Specialization is reasonable, but the team should maintain shared understanding of the main system.

40. Team presentation

A possible team presentation structure is:

Part	Suggested content
1	problem and objective
2	architecture
3	live demonstration
4	important implementation detail
5	tests and reliability
6	limitation and future improvement

Keep the presentation technical and concise.

41. Project objective

The first explanation should answer:

What problem does this project solve?

A good answer should fit in one or two sentences.

Avoid beginning with a long list of technologies.

42. Technology is not the objective

Poor:

We used Python, NumPy, OpenCV,
JSON, Git and pytest.

Better:

The application processes thermal frames
and detects defective pixels automatically.

Technologies support the project objective; they are not the objective themselves.

43. Explain the data flow

A useful technical explanation follows the data.

For example:

camera frame
     ↓
decoder
     ↓
preprocessing
     ↓
analysis
     ↓
result
     ↓
storage/display

This often makes the architecture easier to understand than describing files in arbitrary order.

44. Explain external dependencies

Identify external boundaries explicitly.

Examples:

filesystem
network API
camera
serial device
database
third-party library
operating system

Explain how failure at these boundaries is handled.

45. Explain one invariant

An invariant is a condition expected to remain true.

Examples:

grade is always between 1 and 10
packet length matches header length
image width is always positive
device ID is unique
configuration is validated before startup

Explain where the invariant is enforced.

46. Explain one exception path

Students should be able to trace one error path.

For example:

missing file
    ↓
FileNotFoundError
    ↓
application boundary catches error
    ↓
user-friendly message
    ↓
application exits with failure

47. Explain one testability decision

Examples:

network client passed as dependency
file path passed as parameter
processing separated from input()
hardware access isolated in device.py
time source injected into function

Explain how the decision makes automated testing easier.

48. Explain one refactoring

The team should identify one area improved after the MVP.

For example:

Before:
main.py contained parsing,
processing and output.

After:
parser.py
processor.py
storage.py
main.py

Explain why the new structure is better.

49. Explain one regression test

A useful answer is:

We discovered that empty input caused
ZeroDivisionError.

We added a test for empty input,
then changed the function to raise
a meaningful ValueError.

This demonstrates a complete defect-fixing workflow.

50. Evaluation areas

A project may be evaluated across several dimensions.

Area	What is considered
functionality	Does the central application work?
correctness	Are results and behaviors correct?
architecture	Is the project structured coherently?
Python usage	Does the implementation use appropriate Python constructs?
robustness	Are expected failures handled?
testing	Are important behaviors tested?
code quality	Is the code readable and maintainable?
documentation	Can the project be installed and used?
Git workflow	Does the repository show meaningful development?
technical understanding	Can the team explain its implementation and decisions?

51. Functionality is necessary but not sufficient

A project that produces the correct output but contains:

• one giant file;
• no tests;
• hard-coded machine paths;
• undocumented dependencies;
• hidden credentials;
• unhandled errors;

is technically weaker than a project that also demonstrates software-engineering discipline.

52. Complexity is not automatically quality

Do not add complexity to appear advanced.

A smaller clear implementation is often better than:

• unnecessary inheritance;
• excessive abstraction layers;
• many external dependencies;
• unnecessary asynchronous code;
• complicated design patterns without a need.

Quality is not measured by the number of classes or libraries.

53. Pythonic implementation

The final implementation should reflect concepts from the course.

Examples include:

• direct iteration instead of unnecessary index loops;
• dataclasses for simple data models;
• context managers for resources;
• pathlib for paths;
• exceptions for meaningful failure conditions;
• modules with clear responsibilities;
• type hints where they improve interfaces;
• pytest for automated tests.

54. C++ translation should no longer dominate

By the final project, Python code should not look like a mechanical translation of C++.

For example:

Less idiomatic	More idiomatic
for i in range(len(values)): print(values[i])	for value in values: print(value)

The same principle applies at architecture level.

55. Final code review checklist

Before submission, review:

Area	Check
naming	names communicate intent
functions	no obvious excessively large functions remain
classes	responsibilities are coherent
modules	responsibilities are clear
globals	unnecessary mutable globals removed
errors	expected failures handled
logging	temporary debug output removed
paths	machine-specific paths removed
secrets	none committed
tests	suite passes
documentation	current and reproducible

56. Final testing checklist

Run:

pytest

Then, where configured:

ruff check .
ruff format --check .
mypy src

Finally run the main application manually.

57. Final demonstration checklist

Before presenting:

[ ] demo input available
[ ] application starts
[ ] dependencies installed
[ ] required hardware available
[ ] credentials/configuration available
[ ] output location writable
[ ] main workflow tested
[ ] failure example prepared
[ ] backup data available if needed

58. Final documentation checklist

[ ] README complete
[ ] installation tested
[ ] run command documented
[ ] configuration documented
[ ] test command documented
[ ] architecture explained
[ ] known limitations listed
[ ] sample input included where useful

59. Final repository checklist

[ ] git status clean
[ ] no .venv
[ ] no __pycache__
[ ] no secrets
[ ] no accidental large files
[ ] pyproject.toml correct
[ ] .gitignore correct
[ ] tests committed
[ ] documentation committed
[ ] final version committed

60. Final submission

The final submission should identify the repository and the final revision clearly.

A submission should not depend on an uncommitted local working tree.

The evaluated state should correspond to a specific commit.

Optional:

git rev-parse HEAD

can be used to record the exact commit identifier.

61. Submission commit

A possible final workflow is:

git status

pytest
ruff check .

git add .
git commit -m "Prepare final release"

git push

Only commit if there are actual final changes.

62. Avoid last-minute uncontrolled changes

Immediately before the final demonstration, avoid:

• changing architecture;
• upgrading dependencies without need;
• replacing working libraries;
• rewriting central functionality;
• merging experimental branches.

Last-minute changes introduce unnecessary risk.

63. If a defect appears during the final session

If a non-critical problem appears:

1. identify the scope;
2. avoid destabilizing unrelated code;
3. apply a minimal fix if safe;
4. rerun relevant tests;
5. document the issue if it cannot safely be fixed.

Do not perform a large redesign under presentation pressure.

64. If the demo fails

A failed demo should be approached technically.

Check:

environment
configuration
dependencies
input
external service
hardware
recent code changes
logs
traceback

If a prepared representative backup exists, it may be used to continue the technical discussion.

65. Future work

The final presentation may include a short future-work section.

Good examples:

• additional input formats;
• improved performance;
• GUI;
• hardware support;
• better deployment;
• more complete test coverage;
• additional algorithms.

Future work should not be used to disguise missing required functionality.

66. Lessons learned

Each team should be able to identify at least one useful technical lesson.

Examples:

Separating I/O from processing made testing easier.

Hard-coded paths created portability problems.

Regression tests prevented a previously fixed bug from returning.

A smaller dependency set simplified installation.

Composition made the hardware interface easier to replace in tests.

67. Individual understanding

Each student should be able to explain:

• the project objective;
• the architecture;
• the main workflow;
• at least one module in detail;
• at least one test;
• at least one error path.

The project should represent team work rather than isolated contributions that nobody else understands.

68. Suggested technical discussion

A final discussion may cover:

Why this architecture?

What alternative was considered?

What was the hardest technical issue?

What would fail first at larger scale?

Which dependency is most critical?

Which component is easiest to replace?

Which part has the strongest tests?

Which part still has the largest limitation?

69. Example final explanation

A concise technical explanation could be:

The application reads thermal frames through
the acquisition module.

Frames are passed to the processing pipeline,
which performs correction and analysis.

The pipeline is independent from the camera
interface, so tests can use stored frames.

Results are returned to the CLI and can also
be saved through the storage module.

Hardware failures are converted into
application-specific exceptions at the
device boundary.

This is more useful than describing source files in arbitrary order.

70. Final project maturity

A mature final project should demonstrate:

correctness
    +
structure
    +
testing
    +
robustness
    +
documentation
    +
technical understanding

No single category replaces the others.

71. Exercise 1 — Final architecture explanation

Prepare a diagram containing no more than approximately 5–8 major components.

For every component, write one responsibility.

Practice explaining the architecture in less than two minutes.

72. Exercise 2 — Main workflow walkthrough

Trace one real input through the project.

Document:

Input:
Entry point:
Modules involved:
Important transformation:
Output:

Use this path during the code walkthrough.

73. Exercise 3 — Design decision

Choose one design decision and document:

Decision:
Alternative:
Reason:
Advantage:
Disadvantage:

Be prepared to explain it during evaluation.

74. Exercise 4 — Technical difficulty

Document:

Problem:
Observed behavior:
Root cause:
Diagnostic method:
Solution:
Regression prevention:

Use a real difficulty from the project.

75. Exercise 5 — Test walkthrough

Choose one meaningful test.

Explain:

• what behavior it verifies;
• why the behavior matters;
• whether it is a unit or integration test;
• what would happen if the implementation were broken.

76. Exercise 6 — Error-path walkthrough

Choose one predictable failure.

Trace:

failure
  ↓
detection
  ↓
exception/error
  ↓
handling layer
  ↓
user/log output

77. Exercise 7 — Clean installation

Using a fresh environment:

1. install the project;
2. run the tests;
3. run the main workflow;
4. compare the process with the README.

Correct any discrepancy.

78. Exercise 8 — Final repository audit

Run:

git status
git log --oneline --graph --decorate

Confirm:

• final code is committed;
• tests are committed;
• documentation is committed;
• no sensitive data exists;
• no generated files are accidentally tracked.

79. Exercise 9 — Demonstration rehearsal

Perform the demonstration exactly as it will be shown.

Measure whether it is concise enough.

Record any manual step that could fail.

Simplify the demonstration where possible.

80. Exercise 10 — Final self-review

Answer:

What is the strongest part of the project?

What is the weakest part?

What is the most important limitation?

What would you improve with one more week?

Which technical decision are you most prepared to defend?

The answers should be based on the actual implementation.

81. Final evaluation checklist

Area	Final question
objective	Is the project goal clear?
functionality	Does the primary workflow work?
architecture	Can the structure be explained clearly?
Python	Is the implementation appropriate for Python?
robustness	Are expected failures handled?
testing	Are important behaviors tested?
reproducibility	Can the project be installed from documentation?
repository	Is the submitted state clean and complete?
documentation	Is usage sufficiently explained?
understanding	Can the team explain its own code and decisions?

82. Course summary

Across the seven laboratories, the progression has been:

Lab 1
Python syntax and idioms
        ↓
Lab 2
Object-oriented Python
        ↓
Lab 3
Modules, files, exceptions and typing
        ↓
Lab 4
Testing and software quality
        ↓
Lab 5
Project architecture and MVP
        ↓
Lab 6
Stabilization and release candidate
        ↓
Lab 7
Final integration and demonstration

The objective of the course is therefore not only to learn Python syntax.

It is to move from:

C/C++ programmer

toward:

Python software developer

who can write code that is:

• readable;
• modular;
• testable;
• robust;
• reproducible;
• maintainable.

83. Final principle

The final project should not only work. Another developer should be able to understand what it does, install it, run it, test it and modify it without depending on undocumented knowledge from the original authors.

84. Final submission checklist

Before leaving the final laboratory:

[ ] final repository pushed
[ ] final commit identified
[ ] tests pass
[ ] main workflow demonstrated
[ ] README complete
[ ] known limitations documented
[ ] repository clean
[ ] no secrets committed
[ ] project can be installed reproducibly
[ ] all team members understand the main architecture

The project is then ready for final submission.