Andrei.ulmamei: Pagină nouă: = Lab 7 — Final Integration, Demonstration and Code Review = == Objectives == This laboratory is the final project session. The objective is to demonstrate that the semester p...

2026-09-26T10:40:37Z

Pagină nouă: = Lab 7 — Final Integration, Demonstration and Code Review = == Objectives == This laboratory is the final project session. The objective is to demonstrate that the semester p...

Pagină nouă

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

__TOC__

== 1. Final laboratory structure ==

A possible structure for the two-hour session is:

{| class="wikitable" style="width:100%;"
! 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:

<syntaxhighlight lang="text">
implemented
↓
tested
↓
documented
↓
reproducible
↓
demonstrable
↓
explainable
</syntaxhighlight>

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:

# starting the application;
# providing representative input;
# executing the main workflow;
# showing the output;
# showing one relevant error condition;
# 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:

<syntaxhighlight lang="text">
Problem
↓
Input
↓
Execution
↓
Result
↓
Failure case
↓
Short technical explanation
</syntaxhighlight>

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

== 6. Demonstration time ==

The demonstration should be concise.

A reasonable target is approximately:

<syntaxhighlight lang="text">
5–8 minutes
</syntaxhighlight>

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:

{| class="wikitable" style="width:100%;"
! 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:

<syntaxhighlight lang="text">
CLI
│
▼
Application service
│
├── parser
├── processing pipeline
└── storage
│
▼
output file
</syntaxhighlight>

== 11. Architecture diagram ==

A simple architecture diagram is sufficient.

Avoid diagrams that show every function or variable.

Focus on major components.

Example:

<syntaxhighlight lang="text">
main
├── config
├── service
│ ├── model
│ └── processor
└── storage
</syntaxhighlight>

== 12. Explain responsibilities ==

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

<syntaxhighlight lang="text">
This module is responsible for ...
</syntaxhighlight>

For example:

{| class="wikitable" style="width:100%;"
! Module
! Responsibility
|-
| <code>models.py</code>
| application data structures
|-
| <code>services.py</code>
| central application logic
|-
| <code>storage.py</code>
| persistent data access
|-
| <code>protocol.py</code>
| message encoding and decoding
|-
| <code>main.py</code>
| 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:

<syntaxhighlight lang="text">
main()
↓
load configuration
↓
create service
↓
process input
↓
produce result
</syntaxhighlight>

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:

<syntaxhighlight lang="text">
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?
</syntaxhighlight>

The answer should include the reasoning and trade-offs.

== 16. Design trade-offs ==

Most design decisions have advantages and disadvantages.

A useful explanation is:

<syntaxhighlight lang="text">
We selected approach A because ...
The main advantage is ...
The main disadvantage is ...
Approach B was considered, but ...
</syntaxhighlight>

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:

<syntaxhighlight lang="text">
Observed behavior
↓
Hypothesis
↓
Diagnostic method
↓
Root cause
↓
Fix
↓
Regression test
</syntaxhighlight>

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:

<syntaxhighlight lang="python">
def test_average_rejects_empty_list():
with pytest.raises(ValueError):
average([])
</syntaxhighlight>

or:

<syntaxhighlight lang="python">
def test_round_trip(tmp_path):
path = tmp_path / "data.json"

save_data(path, original)

restored = load_data(path)

assert restored == original
</syntaxhighlight>

The test should demonstrate meaningful project behavior.

== 21. Tests should pass ==

Before the demonstration:

<syntaxhighlight lang="bash">
pytest
</syntaxhighlight>

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:

<syntaxhighlight lang="bash">
ruff check .
pytest
</syntaxhighlight>

If static type checking is part of the project:

<syntaxhighlight lang="bash">
mypy src
</syntaxhighlight>

If formatting is enforced:

<syntaxhighlight lang="bash">
ruff format --check .
</syntaxhighlight>

== 23. Final clean installation test ==

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

A typical procedure:

<syntaxhighlight lang="bash">
python -m venv clean-env
source clean-env/bin/activate

python -m pip install -e .

pytest
python -m project_name
</syntaxhighlight>

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

== 24. Windows clean setup ==

For Windows PowerShell:

<syntaxhighlight lang="powershell">
python -m venv clean-env
clean-env\Scripts\Activate.ps1

python -m pip install -e .

pytest
python -m project_name
</syntaxhighlight>

Document platform-specific requirements where necessary.

== 25. README final review ==

The README should contain at least:

<syntaxhighlight lang="text">
Project name
Description
Main features
Requirements
Installation
Configuration
Running
Example usage
Testing
Architecture overview
Known limitations
</syntaxhighlight>

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

== 26. Repository structure ==

A final project may resemble:

<syntaxhighlight lang="text">
project/
├── README.md
├── pyproject.toml
├── .gitignore
├── src/
│ └── project_name/
│ ├── __init__.py
│ ├── main.py
│ └── ...
├── tests/
│ └── ...
└── examples/
└── ...
</syntaxhighlight>

Not every project requires the same modules.

== 27. Repository cleanliness ==

The repository should generally not contain:

<syntaxhighlight lang="text">
.venv/
__pycache__/
*.pyc
.pytest_cache/
.mypy_cache/
.ruff_cache/
.coverage
temporary output
real secrets
large accidental binaries
</syntaxhighlight>

unless a specific generated artifact is deliberately required.

== 28. Git status ==

Before submission:

<syntaxhighlight lang="bash">
git status
</syntaxhighlight>

should not show forgotten modifications or accidentally generated files.

== 29. Git history ==

Inspect:

<syntaxhighlight lang="bash">
git log --oneline --graph --decorate
</syntaxhighlight>

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

Useful examples:

<syntaxhighlight lang="text">
Add packet decoder
Implement device retry handling
Add regression tests for invalid frames
Refactor configuration loading
Document installation procedure
</syntaxhighlight>

== 30. Final commit ==

A final commit may be something like:

<syntaxhighlight lang="text">
Prepare final project release
</syntaxhighlight>

but the repository should already contain meaningful previous commits.

== 31. Tagging a release ==

Optionally, create a final release tag.

For example:

<syntaxhighlight lang="bash">
git tag v1.0.0
</syntaxhighlight>

If tags are used:

<syntaxhighlight lang="bash">
git push --tags
</syntaxhighlight>

This is optional unless required by the course.

== 32. Version consistency ==

If the project uses a version:

<syntaxhighlight lang="toml">
[project]
version = "1.0.0"
</syntaxhighlight>

ensure documentation and release tags do not contradict it.

== 33. Known limitations ==

Known limitations should remain visible in the final documentation.

For example:

<syntaxhighlight lang="text">
## Known limitations

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

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

== 34. Final acceptance test ==

Before presentation, execute one complete acceptance test.

Record:

<syntaxhighlight lang="text">
Input:
Command:
Expected output:
Actual output:
Result:
</syntaxhighlight>

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:

<syntaxhighlight lang="text">
acceptable:
recorded sensor data → real processing pipeline

not acceptable:
precomputed final output shown instead of processing
</syntaxhighlight>

== 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 <code>==</code> and <code>is</code>;
* 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:

<syntaxhighlight lang="text">
"I don't know; another team member wrote that file."
</syntaxhighlight>

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:

{| class="wikitable" style="width:100%;"
! 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:

<syntaxhighlight lang="text">
What problem does this project solve?
</syntaxhighlight>

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:

<syntaxhighlight lang="text">
We used Python, NumPy, OpenCV,
JSON, Git and pytest.
</syntaxhighlight>

Better:

<syntaxhighlight lang="text">
The application processes thermal frames
and detects defective pixels automatically.
</syntaxhighlight>

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:

<syntaxhighlight lang="text">
camera frame
↓
decoder
↓
preprocessing
↓
analysis
↓
result
↓
storage/display
</syntaxhighlight>

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

== 44. Explain external dependencies ==

Identify external boundaries explicitly.

Examples:

<syntaxhighlight lang="text">
filesystem
network API
camera
serial device
database
third-party library
operating system
</syntaxhighlight>

Explain how failure at these boundaries is handled.

== 45. Explain one invariant ==

An invariant is a condition expected to remain true.

Examples:

<syntaxhighlight lang="text">
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
</syntaxhighlight>

Explain where the invariant is enforced.

== 46. Explain one exception path ==

Students should be able to trace one error path.

For example:

<syntaxhighlight lang="text">
missing file
↓
FileNotFoundError
↓
application boundary catches error
↓
user-friendly message
↓
application exits with failure
</syntaxhighlight>

== 47. Explain one testability decision ==

Examples:

<syntaxhighlight lang="text">
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
</syntaxhighlight>

Explain how the decision makes automated testing easier.

== 48. Explain one refactoring ==

The team should identify one area improved after the MVP.

For example:

<syntaxhighlight lang="text">
Before:
main.py contained parsing,
processing and output.

After:
parser.py
processor.py
storage.py
main.py
</syntaxhighlight>

Explain why the new structure is better.

== 49. Explain one regression test ==

A useful answer is:

<syntaxhighlight lang="text">
We discovered that empty input caused
ZeroDivisionError.

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

This demonstrates a complete defect-fixing workflow.

== 50. Evaluation areas ==

A project may be evaluated across several dimensions.

{| class="wikitable" style="width:100%;"
! 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;
* <code>pathlib</code> 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:

{| class="wikitable" style="width:100%; table-layout:fixed;"
! style="width:50%;" | Less idiomatic
! style="width:50%;" | More idiomatic
|-
|
<syntaxhighlight lang="python">
for i in range(len(values)):
print(values[i])
</syntaxhighlight>
|
<syntaxhighlight lang="python">
for value in values:
print(value)
</syntaxhighlight>
|}

The same principle applies at architecture level.

== 55. Final code review checklist ==

Before submission, review:

{| class="wikitable" style="width:100%;"
! 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:

<syntaxhighlight lang="bash">
pytest
</syntaxhighlight>

Then, where configured:

<syntaxhighlight lang="bash">
ruff check .
ruff format --check .
mypy src
</syntaxhighlight>

Finally run the main application manually.

== 57. Final demonstration checklist ==

Before presenting:

<syntaxhighlight lang="text">
[ ] 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
</syntaxhighlight>

== 58. Final documentation checklist ==

<syntaxhighlight lang="text">
[ ] README complete
[ ] installation tested
[ ] run command documented
[ ] configuration documented
[ ] test command documented
[ ] architecture explained
[ ] known limitations listed
[ ] sample input included where useful
</syntaxhighlight>

== 59. Final repository checklist ==

<syntaxhighlight lang="text">
[ ] 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
</syntaxhighlight>

== 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:

<syntaxhighlight lang="bash">
git rev-parse HEAD
</syntaxhighlight>

can be used to record the exact commit identifier.

== 61. Submission commit ==

A possible final workflow is:

<syntaxhighlight lang="bash">
git status

pytest
ruff check .

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

git push
</syntaxhighlight>

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:

# identify the scope;
# avoid destabilizing unrelated code;
# apply a minimal fix if safe;
# rerun relevant tests;
# 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:

<syntaxhighlight lang="text">
environment
configuration
dependencies
input
external service
hardware
recent code changes
logs
traceback
</syntaxhighlight>

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:

<syntaxhighlight lang="text">
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.
</syntaxhighlight>

== 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:

<syntaxhighlight lang="text">
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?
</syntaxhighlight>

== 69. Example final explanation ==

A concise technical explanation could be:

<syntaxhighlight lang="text">
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.
</syntaxhighlight>

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

== 70. Final project maturity ==

A mature final project should demonstrate:

<syntaxhighlight lang="text">
correctness
+
structure
+
testing
+
robustness
+
documentation
+
technical understanding
</syntaxhighlight>

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:

<syntaxhighlight lang="text">
Input:
Entry point:
Modules involved:
Important transformation:
Output:
</syntaxhighlight>

Use this path during the code walkthrough.

== 73. Exercise 3 — Design decision ==

Choose one design decision and document:

<syntaxhighlight lang="text">
Decision:
Alternative:
Reason:
Advantage:
Disadvantage:
</syntaxhighlight>

Be prepared to explain it during evaluation.

== 74. Exercise 4 — Technical difficulty ==

Document:

<syntaxhighlight lang="text">
Problem:
Observed behavior:
Root cause:
Diagnostic method:
Solution:
Regression prevention:
</syntaxhighlight>

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:

<syntaxhighlight lang="text">
failure
↓
detection
↓
exception/error
↓
handling layer
↓
user/log output
</syntaxhighlight>

== 77. Exercise 7 — Clean installation ==

Using a fresh environment:

# install the project;
# run the tests;
# run the main workflow;
# compare the process with the README.

Correct any discrepancy.

== 78. Exercise 8 — Final repository audit ==

Run:

<syntaxhighlight lang="bash">
git status
git log --oneline --graph --decorate
</syntaxhighlight>

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:

<syntaxhighlight lang="text">
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?
</syntaxhighlight>

The answers should be based on the actual implementation.

== 81. Final evaluation checklist ==

{| class="wikitable" style="width:100%;"
! 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:

<syntaxhighlight lang="text">
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
</syntaxhighlight>

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

It is to move from:

<syntaxhighlight lang="text">
C/C++ programmer
</syntaxhighlight>

toward:

<syntaxhighlight lang="text">
Python software developer
</syntaxhighlight>

who can write code that is:

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

== 83. Final principle ==

<blockquote>
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.
</blockquote>

== 84. Final submission checklist ==

Before leaving the final laboratory:

<syntaxhighlight lang="text">
[ ] 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
</syntaxhighlight>

The project is then ready for final submission.

Lab 7 - Revizia istoricului

Andrei.ulmamei: Pagină nouă: = Lab 7 — Final Integration, Demonstration and Code Review = == Objectives == This laboratory is the final project session. The objective is to demonstrate that the semester p...