Architect Playbook · OOA&D

Software
Development
Life Cycle

A cognitive visual framework for system thinkers — transforming SDLC theory into an interactive mental model for Object Oriented Analysis & Design.

Explore Phases →
01
Analysis
Understand the problem before solving it
→02
Design
Translate requirements into architectural blueprints
→03
Development
Turn architectural design into working, tested code
→04
Testing
Validate every behavior against its requirement
→05
Deployment
Release to the live production environment safely
→06
Maintenance
Sustain, evolve, and continuously improve the live system
→

Visual Overview

6 Phases · Roles at a Glance

Every phase has distinct stakeholders, inputs, and outputs. The cycle is iterative — not strictly linear.

01Analysis
  • →Product Owner
  • →Project Manager
  • →Business Analyst
  • →CTO
02Design
  • →System Architect
  • →UX/UI Designer
03Development
  • →Frontend Developer
  • →Backend Developer
04Testing
  • →Solutions Architect
  • →QA Engineer
  • →Tester
  • →DevOps
05Deployment
  • →Database Administrator
  • →DevOps
06Maintenance
  • →End Users
  • →Testers
  • →Technical Support
01
Analysis
Understand the problem before solving it
⚡ Layer A · Quick Scan

What is this phase?

Transform vague stakeholder expectations into precise, documented requirements. Define what the system must do — never how.

Key Output
Requirements Specification Document
📋 Layer B · Structured

Requirements Breakdown

  • Vision — The big picture & project goal
  • Functional Req. — What the system does
  • Non-Functional Req. — Performance, security, scale
  • Constraints — Hard limits & boundaries
  • Assumptions — Accepted unknowns
🧠 Layer C · Architect Notes

Decision Checkpoints

  • ▸ Is the vision clear to ALL stakeholders?
  • ▸ Are requirements measurable & testable?
  • ▸ Are constraints documented explicitly?
  • ▸ Have assumptions been validated?
  • ▸ Can non-functional reqs be measured?
Roles
Product Owner · Project Manager · Business Analyst · CTO
Key Question
What problem are we solving?
Next Phase Trigger
All requirements reviewed & signed off
Risk if Skipped
Building the entirely wrong system
02
Design
Translate requirements into architectural blueprints
⚡ Layer A · Quick Scan

What is this phase?

Convert functional requirements into system structures. Define the problem domain, establish boundaries, model use cases and define architecture decomposition.

Key Output
Architecture Blueprint + UML Diagrams
📋 Layer B · Structured

Design Activities

  • Problem Domain — Define system boundaries
  • Mission Use Cases — Core system purpose flows
  • System Use Cases — All user-system interactions
  • Actors — Who interacts with the system
  • Architecture Decomposition — Layers, modules, interfaces
🧠 Layer C · Architect Notes

Decision Checkpoints

  • ▸ Are domain boundaries drawn explicitly?
  • ▸ Are ALL actors (human & system) identified?
  • ▸ Do use cases cover every user goal?
  • ▸ Is architecture scalable for future req?
  • ▸ Are external interfaces & APIs defined?
Roles
System Architect · UX/UI Designer
Key Question
How will the system be structured?
Next Phase Trigger
Architecture reviewed & approved by team
Risk if Skipped
Unscalable, brittle codebase from day one
03
Development
Turn architectural design into working, tested code
⚡ Layer A · Quick Scan

What is this phase?

Implement the designed architecture. Frontend and backend teams build the system following the approved specifications, data models, and flowcharts.

Key Output
Working Source Code + Unit Tests
📋 Layer B · Structured

Build Activities

  • Entities (Data Model) — Define data structures
  • Flowchart — Implement application logic flow
  • Pseudocode — Plan logic before writing code
  • Sequence Diagrams — Object interaction ordering
  • Frontend + Backend — UI, APIs, business logic, DB
🧠 Layer C · Architect Notes

Decision Checkpoints

  • ▸ Does code match the approved architecture?
  • ▸ Are coding standards enforced via review?
  • ▸ Are edge cases and nulls handled?
  • ▸ Is unit test coverage adequate?
  • ▸ Is pseudocode written before coding?
Roles
Frontend Developer · Backend Developer
Key Question
Does the code correctly implement the design?
Next Phase Trigger
Feature-complete + code review passed
Risk if Skipped
Technical debt compounds rapidly
04
Testing
Validate every behavior against its requirement
⚡ Layer A · Quick Scan

What is this phase?

Systematically verify the system meets every requirement. Find and eliminate defects before they reach real users in production.

Key Output
Test Reports + Bug-free Release Candidate
📋 Layer B · Structured

Testing Types

  • Unit Testing — Individual component correctness
  • Integration Testing — Combined module behavior
  • System Testing — Full end-to-end flows
  • UAT — User acceptance validation
  • Performance — Load, stress, scalability
🧠 Layer C · Architect Notes

Decision Checkpoints

  • ▸ Are ALL use cases covered by tests?
  • ▸ Are non-functional reqs validated?
  • ▸ Are test cases traceable to requirements?
  • ▸ Is regression testing automated?
  • ▸ Has the product owner signed off UAT?
Roles
Solutions Architect · QA Engineer · Tester · DevOps
Key Question
Does the system do exactly what we promised?
Next Phase Trigger
All critical bugs resolved, coverage met
Risk if Skipped
Production failures & broken user trust
05
Deployment
Release to the live production environment safely
⚡ Layer A · Quick Scan

What is this phase?

Move the tested system into the live production environment. Configure infrastructure, run migrations, activate monitoring, and execute the go-live plan.

Key Output
Live System + Deployment Documentation
📋 Layer B · Structured

Deployment Activities

  • Environment Setup — Servers, config, secrets
  • Database Migration — Schema, seed data
  • CI/CD Pipeline — Automated release process
  • Smoke Testing — Post-deploy verification
  • Rollback Plan — Defined revert strategy
🧠 Layer C · Architect Notes

Decision Checkpoints

  • ▸ Is a rollback strategy clearly defined?
  • ▸ Are monitoring & alerts active?
  • ▸ Is deployment window communicated?
  • ▸ Are secrets & config secured?
  • ▸ Is data migration reversible?
Roles
Data Administrator · DevOps
Key Question
Is the system safely live for end users?
Next Phase Trigger
System stable in prod, users onboarded
Risk if Skipped
Data loss, downtime, security exposure
06
Maintenance
Sustain, evolve, and continuously improve the live system
⚡ Layer A · Quick Scan

What is this phase?

Monitor and keep the system healthy. Respond to user feedback, patch production bugs, and feed learnings into the next SDLC iteration.

Key Output
Patches · Updated Docs · Next Iteration Feed
📋 Layer B · Structured

Maintenance Types

  • Corrective — Fix reported production bugs
  • Adaptive — Adjust to environment changes
  • Perfective — Performance improvements
  • Preventive — Refactoring, reduce tech debt
🧠 Layer C · Architect Notes

Decision Checkpoints

  • ▸ Is monitoring surfacing real issues early?
  • ▸ Is user feedback channeled into backlog?
  • ▸ Are hotfixes following a proper process?
  • ▸ When does the next SDLC cycle start?
Roles
Users · Testers · Support
Key Question
Is the system still meeting real user needs?
Next Phase Trigger
Major new requirements identified
Risk if Skipped
System decay and user abandonment

OOA&D Process Pipeline

Analysis & Design Workflow

The structured pipeline from raw requirements to deployed architecture — each stage produces concrete artifacts that feed the next.

Requirements
  • · Vision
  • · Functional Requirements
  • · Non-Functional Requirements
  • · Constraints
  • · Assumptions
→
Problem Domain
  • · Define system boundaries
  • · Identify core entities
  • · Map domain relationships
  • · Establish scope limits
→
Use Cases
  • · Mission use-case
  • · System use-cases
  • · List all Actors
  • · Activity diagrams
→
Define Architecture
  • · Decompose architecture
  • · Define components
  • · Map interfaces
  • · Select patterns
→
Deployment
  • · Infrastructure setup
  • · CI/CD pipeline
  • · Environment config
  • · Go-live plan

Feedback Loops

Decision Flow System

The conditional logic an architect applies when something is wrong, incomplete, or ambiguous — and how to recover.

IF requirement is unclear
→ Return to Analysis. Re-engage stakeholders. Clarify vision and functional expectations before any design work begins.
IF architecture is unstable
→ Revisit Design. Decompose further. Validate the architecture against requirements again before resuming development.
IF use case is incomplete
→ Return to Design. Add missing actors, flows, or edge cases. Re-model before writing a single line of code.
IF a test fails
→ Return to Development. Fix root cause — not the symptom. Re-run the full regression suite before resubmitting for QA.
IF deployment fails
→ Execute Rollback Plan. Investigate root cause. Fix in Development → re-test → redeploy with confidence.
IF all checkpoints pass
→ Proceed to next phase. Document decisions and rationale. Notify stakeholders and update progress tracking.

Visual Artifacts

UML Diagram Zones

Each diagram type answers a specific architectural question. Use the right diagram for the right thinking problem.

Diagram not understood? Check Ch5 [Notation] first. Still unclear — search it. Reference is the priority, not memorization.
👥

Use Case

Who does what in the system

Design
🔄

Activity

Flow of activities & decisions

Analysis + Design
🧩

Class

Objects, attributes, relationships

Development
📨

Sequence

Time-ordered object interactions

Design + Dev
🔧

Component

System modules & their interfaces

Architecture
⚙️

State Machine

Object lifecycle & transitions

Design
🖥️

Deployment

Hardware & infrastructure layout

Deployment
© 2026