| Week 1 | What Software Design Really Means | Design is the structure that lets working code survive change. | Bad Code Diagnosis | Pick an app you use often. Write 600–900 words explaining its likely modules, likely data, and three design choices the developers probably had to make. |
| Week 2 | Requirements, Constraints, and Acceptance Criteria | You cannot design well until you understand the problem well. | Requirement Recovery | Create a requirements document for a library system, inventory system, or student planner. Include at least 15 requirements and 8 acceptance criteria. |
| Week 3 | Decomposition, Modularity, Cohesion, and Coupling | Large systems become manageable when responsibilities are separated cleanly. | Modular Refactor Plan | Design a module breakdown for your capstone idea. Include at least six modules/classes and describe how they communicate. |
| Week 4 | Object-Oriented Design That Does Not Fight You | Classes should protect rules, express concepts, and collaborate cleanly. | Domain Modeling with Objects | Design a mini game object model with Player, Enemy, Weapon, Ability, and Level. Use composition for at least one behavior. |
| Week 5 | SOLID Part 1: SRP, OCP, and LSP | The first three SOLID principles help you avoid classes that break when requirements change. | SOLID Refactor: Reports | Refactor a payment, shipping, grading, or enemy-behavior example to use SRP and OCP. Include before/after code. |
| Week 6 | SOLID Part 2: Interfaces, Dependency Inversion, and Testability | Design improves when high-level rules stop depending directly on low-level details. | Notification System Design | Create a small service that depends on at least two abstractions. Explain which details are hidden behind those abstractions and why. |
| Week 7 | DRY, KISS, YAGNI, and Naming | Simple design is not lazy design. It is disciplined design. | Clarity Refactor | Take a small program you wrote before. Rename at least ten items and remove or simplify one unnecessary abstraction. Submit a reflection. |
| Week 8 | UML and Practical Design Diagrams | A useful diagram explains one idea clearly. | Diagram a Workflow | Create two diagrams for your capstone: one class/module diagram and one sequence diagram for the most important workflow. |
| Week 9 | Design Patterns Part 1: Strategy, Factory, Observer, Singleton | Patterns are tools for recurring design problems, not decorations. | Pattern Choice Lab | Implement Strategy, Factory, or Observer in a small example. Include a paragraph explaining what problem the pattern solves. |
| Week 10 | Design Patterns Part 2: Adapter, Decorator, Command, Repository, MVC/MVVM | Some patterns help connect systems, extend behavior, and separate application layers. | Repository and UI Separation | Build a small app screen using a service and repository. The UI should not directly own business rules. |
| Week 11 | Testing and Testable Design | If important behavior is hard to test, the design is probably telling you something. | Make It Testable | Write at least five tests for your capstone. Explain one design change you made because testing exposed a problem. |
| Week 12 | Software Architecture Basics | Architecture is the system’s big shape and its most important boundaries. | Architecture Sketch | Create an architecture diagram for your capstone and explain why you chose that structure. |
| Week 13 | Refactoring, Code Smells, and Technical Debt | Improve design without changing external behavior. | Refactor Safely | Write a refactoring plan for your capstone. Include what you would fix first and why. |
| Week 14 | Final Design Review and Professional Presentation | A designer must explain not only what was built, but why it was built that way. | Final Design Review | Submit final project code, README, diagrams, tests, and design reflection. Prepare a 7–10 minute presentation. |