Final Design Review and Professional Presentation

Learning Objectives

• Prepare a final design presentation.
• Explain tradeoffs clearly.
• Connect requirements to design choices.
• Reflect on design weaknesses and future improvements.

Lecture Notes

A final project is not just a demo. In a software design course, the student must explain the design behind the demo. What requirements shaped the system? What modules were created? Which responsibilities were separated? What design pattern was used, and why was it appropriate? What was deliberately kept simple?

A strong design review connects decisions to reasons. “I used a repository” is not enough. A better explanation is: “I used a TaskRepository interface because task storage may move from local storage to a server later, and it lets me test TaskService without browser storage.” That sentence shows context, design choice, and benefit.

Tradeoffs are the heart of design. Every design gives up something. A simple local app may be easy to deploy but weak for multi-device sync. A microservice architecture may scale teams but increase operational burden. A strategy pattern may support new behavior but add more files. Students should not pretend their design is perfect. Honest tradeoff discussion is a sign of maturity.

The final presentation should include requirements, architecture diagram, class or module diagram, important workflow, design principles used, pattern explanation, testing approach, refactoring decisions, and future work. The code does not need to be huge. A small, clean, explainable system is better than a large tangled one.

Professional communication matters. Use diagrams that can be read from the back of the room. Keep slides or pages focused. Use examples. Show one before/after design improvement. Explain one mistake made during development and how it was corrected. A designer who can reflect honestly is more valuable than one who claims every choice was perfect.

Worked Example: Weak vs strong design rationale

I used interfaces because interfaces are good.

I introduced PaymentGateway because checkout rules should not depend directly on one payment provider. This made the service easier to test with a fake gateway and would allow a second provider later without rewriting checkout logic.

Lab: Final Design Review

Scenario: Students review each other’s capstone projects before final submission.

Steps

1. Present the system in five minutes.
2. Show one diagram and one code example.
3. Explain one principle and one pattern used.
4. Receive peer feedback on clarity and design risk.
5. Revise final submission based on feedback.

Deliverables

• Presentation draft
• Peer feedback form
• Final revision note

Assignment

Submit final project code, README, diagrams, tests, and design reflection. Prepare a 7–10 minute presentation.

Discussion Prompts

• What makes a design explanation convincing?
• Why should students discuss weaknesses?
• How much code should appear in a final presentation?

Week 14 Quiz

Use these as quick checks after the lesson.

Student Notes

Saved in this browser only.