boy in green shirt
Photo by CDC on Pexels.com

[Class Report] System Development (Year 2) — Week 40

— Finalizing Documentation & Handover Design: The Skill of “Finishing” a Development Project —

In Week 40, we took the system whose quality we confirmed during the previous mini presentation session and worked on final documentation cleanup and handover design.
The theme was: making it a state where the next person can use it, fix it, and improve it without getting stuck.


■ Teacher’s Introduction: “Good development is completed with a good handover”

Mr. Tanaka: “A project isn’t finished just because the code runs.
It’s only complete when it’s in a form you can hand over to someone else.”

As real-world examples, the teacher compared:

  • Systems that became impossible to modify due to lack of documentation
  • Projects that could be handed over quickly because the README was well maintained

…and explained that the quality of handover directly affects development efficiency.


■ Today’s Goals

  1. Finalize the README to a level where a third party can use it at first glance
  2. Unify design documents, flowcharts, and ER diagrams into the latest version
  3. Create an operations/troubleshooting memo (operations notes)
  4. Complete the handover checklist

■ Exercise ①: Final README Polish

Each team opened their README and refined it from the following perspectives.

Required Items Included in the README

  • Project overview (what problem the system solves)
  • Runtime environment and prerequisites
  • Setup steps (create DB → run migrations → start the app)
  • Basic usage (by use case)
  • Common errors and how to fix them
  • Where logs are and how to read them
  • Folder structure explanation

Student A: “When I imagined ‘myself seeing this for the first time,’ I ended up adding more explanations.”


■ Exercise ②: Organizing and Updating Design Documents to the Latest Version

We consolidated the following materials into the latest, consistent set:

  • Requirements definition (user stories and acceptance criteria)
  • Class diagrams and sequence diagrams
  • ER diagram and table definitions
  • Notes on role separation between DAO / Service layers

Checkpoints

  • Whether the implementation and diagrams contradict each other
  • Whether unused classes or tables remain
  • Whether naming matches the code

Student B: “Fixing the diagrams made me realize there were ‘unnecessary features.’”


■ Exercise ③: Creating Operations Notes (Troubleshooting Memo)

We created operations notes that compile information needed “after it’s running.”

Examples of What We Wrote

  • Common issues and their causes
  • What to check when errors occur (logs → DB → settings)
  • Safe restart procedures
  • How to back up data
  • Settings that must not be touched

Student C: “It’s reassuring when it clearly says ‘don’t touch this.’”


■ Exercise ④: Building a Handover Checklist

Finally, we turned the must-check items for handover into a checklist.

Handover Checklist (Example)

  • [ ] The system can be started by reading the README
  • [ ] The DB structure matches the ER diagram
  • [ ] Key use cases can be reproduced
  • [ ] The log-checking procedure during errors is clear
  • [ ] Files to modify for future changes are explicitly identified

Passing all checks is the condition for calling the project “complete.”


■ Pair Handover Practice (Final Step)

Within each team, members switched roles and ran a handover drill where:
“The creator is not allowed to explain.”

  • Start the system using only the README and documents
  • Write down unclear points
  • Improve the documentation on the spot

Student D: “This ‘no explaining’ rule is insanely educational…”


■ Teacher’s Final Summary

“What you did today is
the skill of connecting your成果 (work/results) to the future.

Design, implementation, testing, improvement, and handover—
having experienced this entire flow,
you’re no longer just someone who ‘only builds.’”


■ Reflection Comments (Excerpts)

  • “I realized the importance of the README for the first time.”
  • “When you build with handover in mind, you notice weak points in the design.”
  • “I feel like team development includes how you finish as part of the job.”

■ Next Week Preview: Term Wrap-up & Reviewing Outcomes

Next week, we’ll look back on the entire term and work on:
portfolio organization, self-assessment, and connecting to the next school year (Year 3).
It’s an important milestone session before moving into areas like generative AI and external service integration.


Week 40 was about raising quality not through code, but through communication and transferability.
Students learned the real meaning of not ending at “build and done,” but preparing a system in a form that can be handed to the next person.

By greeden

Leave a Reply

Your email address will not be published. Required fields are marked *

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)