3. Mô hình hóa (Modelling) trong Agile Development
Mục lục
📘 Tại sao mô hình hóa quan trọng trong Agile?
🌟 Mở đầu
Trong bất kỳ quy trình phát triển phần mềm nào, giao tiếp là yếu tố sống còn. Trong môi trường Agile, điều này còn đặc biệt quan trọng hơn vì nhóm phát triển phải:
- Làm việc với thời gian giới hạn (Timeboxing),
- Giao hàng liên tục (Iterative),
- Thường xuyên nhận phản hồi từ người dùng (Customer Collaboration),
- Và thích nghi với thay đổi nhanh chóng (Embrace Change).
Chính vì vậy, mô hình hóa (modelling) trở thành một công cụ không thể thiếu – để biến những yêu cầu trừu tượng thành những hình ảnh trực quan, dễ hiểu và dễ kiểm chứng.
💬 1. Mô hình hóa là cầu nối giao tiếp
Agile khuyến khích giao tiếp mặt đối mặt, nhưng đôi khi lời nói không đủ – đặc biệt với các khái niệm kỹ thuật, luồng xử lý, hoặc kiến trúc hệ thống.
Lúc này, một sơ đồ đơn giản có thể thay thế hàng trang mô tả.
🔍 Ví dụ:
Một sơ đồ luồng dữ liệu (Data Flow Diagram – DFD) có thể giúp người dùng hiểu ngay hệ thống hoạt động như thế nào, thay vì đọc hàng loạt tài liệu phân tích.
⚠️ 2. Phát triển nhanh nhưng vẫn phải “đúng”
Agile thúc đẩy tốc độ. Nhưng nếu không kiểm soát, phát triển nhanh = phát triển sai nhanh hơn.
Mô hình hóa giúp:
- Xác minh yêu cầu ngay từ đầu
- Hiểu rõ mối quan hệ giữa các thành phần
- Xác định rủi ro về thiết kế, logic hoặc dữ liệu
Không mô hình hóa = dễ lệch hướng ngay từ đầu, dẫn đến:
- Sản phẩm không đúng yêu cầu
- Phải làm lại, sửa đổi tốn kém
- Trễ thời hạn hoặc vượt ngân sách
🧠 3. Giúp hình dung thứ chưa tồn tại
Khác với các ngành xây dựng hoặc cơ khí – nơi sản phẩm có thể nhìn thấy trước – phần mềm là thứ vô hình cho đến khi hoàn thành.
Mô hình hóa đóng vai trò như:
- Bản vẽ kiến trúc trước khi xây nhà
- Storyboard trước khi quay phim
- Prototype trước khi lập trình
💡 Nó giúp tất cả các bên – từ kỹ thuật đến kinh doanh – cùng nhìn thấy “chúng ta đang làm gì”, ngay cả khi sản phẩm chưa tồn tại.
🔁 4. Tăng hiệu quả trong vòng lặp phát triển (Iterative)
Agile sử dụng vòng lặp ngắn (sprint/timebox) để phát triển – và sau mỗi vòng cần cải tiến.
Mô hình hóa giúp:
- Đánh giá các thay đổi rõ ràng
- So sánh “trước – sau” dễ dàng
- Làm tài liệu đầu vào cho vòng lặp tiếp theo
Ví dụ: sơ đồ Use Case hoặc Wireframe giao diện được cập nhật qua mỗi sprint để phản ánh sự tiến hóa của sản phẩm.
📣 5. Nâng cao chất lượng giao tiếp trong nhóm và với khách hàng
Một trong những nguyên nhân lớn nhất khiến dự án thất bại là hiểu sai yêu cầu.
Mô hình hóa là công cụ để:
- Thống nhất hiểu giữa các bên
- Xác minh với người dùng
- Đưa ra phản hồi sớm, tránh “làm sai rồi mới biết”
Mô hình = “ngôn ngữ trung gian” giữa:
- Khách hàng (không kỹ thuật)
- Lập trình viên (kỹ thuật)
- Quản lý dự án (quản trị)
⚙️ 6. Tích hợp tốt với Agile Framework
Khác với Waterfall – nơi mô hình hóa chỉ làm đầu dự án, Agile yêu cầu mô hình hóa lặp lại, tinh chỉnh liên tục.
Nó phù hợp hoàn hảo với các khung Agile như:
- DSDM: mô hình hóa trong mọi giai đoạn của vòng đời
- Scrum: mô hình hóa thành đầu vào cho backlog refinement
- XP: mô hình hóa đơn giản hỗ trợ coding & refactoring
✅ Kết luận
📌 “Bạn không thể xây nhà mà không có bản vẽ – thì bạn cũng không nên xây phần mềm mà không có mô hình.”
Mô hình hóa không chỉ giúp nhóm Agile:
- Làm đúng ngay từ đầu,
- Giao tiếp hiệu quả,
- Phản hồi nhanh,
- Và kiểm soát tốt hơn,
Mà còn giúp khách hàng hiểu, góp ý và đồng hành cùng sản phẩm trong suốt vòng đời phát triển.
heo của bài viết, phân tích chi tiết nội dung “DSDM và vai trò của mô hình hóa” – trình bày theo phong cách ebook, có ví dụ và ứng dụng thực tiễn.
📘 DSDM và vai trò của mô hình hóa trong Agile Development
🧱 1. Mô hình hóa là một trong 5 kỹ thuật trụ cột của DSDM
Trong khung Agile DSDM (Dynamic Systems Development Method), mô hình hóa (Modelling) không chỉ là một lựa chọn – nó là một kỹ thuật bắt buộc.
DSDM xác định 5 kỹ thuật chính để triển khai dự án thành công:
- MoSCoW – Ưu tiên yêu cầu
- Timeboxing – Giao hàng đúng thời hạn
- Iterative Development – Phát triển lặp
- Facilitated Workshops – Họp định hướng
- Modelling – Mô hình hóa sản phẩm, luồng, quy trình
💡 Trong đó, mô hình hóa giữ vai trò cốt lõi trong cả thiết kế, giao tiếp và phản hồi – là cầu nối giữa các thành phần còn lại.
🎯 2. Mục tiêu chính của mô hình hóa trong DSDM
- Hiển thị những gì chưa tồn tại: thay vì nói suông, nhóm dùng mô hình để “vẽ ra” sản phẩm tương lai
- Minh bạch quy trình: tất cả các bên có thể cùng xem, góp ý và sửa đổi
- Giảm rủi ro sai sót: tránh hiểu sai yêu cầu từ sớm
- Hỗ trợ giao tiếp liên phòng ban: kỹ thuật – người dùng – tài chính – vận hành – nhân sự…
🖼 3. Mô hình hóa giúp chuyển hóa trừu tượng thành cụ thể
DSDM thường sử dụng các mô hình như:
- Storyboard: minh họa luồng người dùng
- Use Case: xác định hành vi người dùng
- Wireframe: giao diện khung
- Data Flow Diagram (DFD): luồng dữ liệu
- ERD (Entity Relationship Diagram): quan hệ dữ liệu
✅ Mỗi loại mô hình sẽ hỗ trợ cho từng giai đoạn cụ thể, giúp hình dung và phân tích chính xác.
🔄 4. Mô hình hóa trong suốt vòng đời phát triển
DSDM yêu cầu mô hình hóa không chỉ diễn ra ở đầu dự án, mà xuyên suốt toàn bộ vòng đời:
| Giai đoạn | Loại mô hình & Người thực hiện |
|---|---|
| Feasibility (tính khả thi) | Mô hình tổng thể: do Business Sponsor, Stakeholders xây dựng |
| Foundations (xây nền) | Mô hình hệ thống cấp cao: Technical Coordinator, Business Analyst |
| Exploration (khám phá) | Mô hình chi tiết: nhóm phát triển xây dựng và điều chỉnh |
| Engineering (thi công) | Mô hình kỹ thuật, logic xử lý: Developer, Architect thực hiện |
| Deployment (triển khai) | Giao diện thật, hệ thống kiểm thử: người dùng đánh giá |
📌 Mỗi mô hình ở mỗi giai đoạn giúp ra quyết định, kiểm tra giả định và cập nhật sản phẩm.
👥 5. Mô hình hóa là nền tảng của các buổi workshop
DSDM nhấn mạnh kỹ thuật Facilitated Workshops – nơi các bên họp và thống nhất các quyết định.
Các workshop chỉ hiệu quả khi:
- Có mô hình minh họa (thay vì nói suông)
- Có thể sửa mô hình ngay tại buổi họp
- Dùng mô hình để review – confirm – approve
💬 “Mọi người có thể không đồng ý về một ý tưởng trừu tượng, nhưng sẽ cùng hiểu một bản vẽ.”
🧭 6. Mô hình hóa đảm bảo bám sát các nguyên tắc DSDM
| Nguyên tắc DSDM | Cách mô hình hóa hỗ trợ |
|---|---|
| Tập trung vào nhu cầu kinh doanh | Mô hình giúp xác định rõ cái gì là cần thiết, không lan man |
| Giao hàng đúng thời hạn | Mô hình hóa nhanh giúp ra quyết định sớm |
| Cộng tác | Tạo điểm chung để các bên dễ phối hợp |
| Không đánh đổi chất lượng | Mô hình là công cụ kiểm tra yêu cầu, không bỏ sót |
| Phát triển lặp | Mô hình được cập nhật sau mỗi vòng phát triển |
| Giao tiếp liên tục | Mô hình là ngôn ngữ trực quan cho mọi phòng ban |
| Thể hiện kiểm soát | Nhìn vào mô hình là biết tiến độ, phạm vi, rủi ro ở đâu |
✅ Kết luận
📌 “Trong DSDM, nếu không có mô hình hóa – mọi thứ chỉ là phỏng đoán.”
Mô hình hóa không chỉ là một kỹ thuật – mà là bản chất tư duy trực quan của Agile:
- Làm rõ cái gì cần làm,
- Làm đúng ngay từ đầu,
- Và tạo cơ sở cho cải tiến liên tục.
Nó hỗ trợ mọi thành phần còn lại của DSDM, từ quy trình đến con người, từ kế hoạch đến phản hồi.
Sáu góc nhìn trong mô hình hóa – Đảm bảo toàn diện và định hướng rõ ràng
🧠 Tại sao cần nhiều góc nhìn?
Một mô hình chỉ thực sự hiệu quả khi thể hiện được đầy đủ khía cạnh của hệ thống: từ dữ liệu, chức năng, người dùng đến mục tiêu kinh doanh.
DSDM xác định rõ sáu góc nhìn (six perspectives) – còn gọi là 6W – giúp nhóm phát triển không bị bỏ sót thông tin và hiểu hệ thống một cách toàn diện.
📌 Tổng quan sáu góc nhìn:
| Góc nhìn | Câu hỏi chính | Nội dung thể hiện |
|---|---|---|
| WHAT | Chúng ta xử lý dữ liệu gì? | Dữ liệu, thông tin, quan hệ, quy tắc |
| HOW | Chúng ta làm như thế nào? | Quy trình, tính năng, đầu vào/ra |
| WHERE | Thực hiện ở đâu? | Địa điểm, hệ thống con, phân phối |
| WHO | Ai tham gia? | Người dùng, stakeholder, nhóm |
| WHEN | Khi nào xảy ra? | Sự kiện, thời gian, lịch biểu |
| WHY | Tại sao làm việc này? | Mục tiêu, chiến lược, động lực kinh doanh |
🔎 Phân tích từng góc nhìn
1. 📂 WHAT – Thông tin, dữ liệu và quan hệ
Đây là lớp “dữ liệu” của hệ thống.
Bao gồm:
- Loại thông tin nào sẽ được xử lý?
- Dữ liệu nào là bắt buộc, dữ liệu nào là tạm thời?
- Các quan hệ giữa thực thể (ERD)?
- Quy tắc xử lý dữ liệu?
✅ Mô hình liên quan: Entity Relationship Diagram (ERD), data dictionaries
2. 🔧 HOW – Quy trình, tính năng, chức năng
Đây là lớp “hành vi”.
- Hệ thống làm gì với dữ liệu?
- Những tính năng nào cần có?
- Dòng xử lý bắt đầu từ đâu? Đi qua những bước nào?
✅ Mô hình liên quan: Use Case Diagram, Flowcharts, Activity Diagram
3. 🌐 WHERE – Địa điểm và hệ thống con
Mô tả “vị trí vận hành” của quy trình.
- Các thao tác diễn ra ở phòng ban nào?
- Hệ thống nào xử lý phần nào?
- Có hệ thống phân tán không? (ví dụ: POS tại cửa hàng, trung tâm xử lý ở trụ sở)
✅ Mô hình liên quan: Deployment Diagrams, Network Layouts, Logical Architecture Maps
4. 👤 WHO – Con người liên quan
Đây là lớp “vai trò và trách nhiệm”.
- Ai sử dụng hệ thống?
- Ai phê duyệt, ai nhập dữ liệu, ai nhận kết quả?
- Có nhiều nhóm người dùng không?
✅ Mô hình liên quan: Swimlane Diagram, Role Maps, User Story Mapping
5. ⏰ WHEN – Sự kiện và thời điểm
Khi nào quá trình xảy ra? Có phụ thuộc thời gian không?
- Các sự kiện nào kích hoạt hệ thống?
- Có yêu cầu xử lý theo lịch không?
- Hành vi thay đổi theo ngày, ca làm việc, kỳ hạn không?
✅ Mô hình liên quan: Event Diagrams, Timeline Models, Gantt Chart (khi cần lập lịch triển khai)
6. 🎯 WHY – Mục tiêu và động lực
Tầng sâu nhất: tại sao chúng ta làm điều này?
- Mục tiêu kinh doanh là gì?
- Kết quả mong đợi? Chỉ số đo lường thành công?
- Tại sao thay đổi lại cần thiết ngay bây giờ?
✅ Tài liệu liên quan: Business Case, Value Stream Map, Strategic Alignment Matrix
🧩 Ứng dụng thực tiễn
Một mô hình tốt trong DSDM hay bất kỳ dự án Agile nào nên bao phủ ít nhất 4/6 góc nhìn, và lý tưởng là đầy đủ cả 6.
Ví dụ:
- WHAT & HOW là tầng kỹ thuật
- WHO & WHERE là tầng tổ chức
- WHEN & WHY là tầng chiến lược
💬 “Một sơ đồ đẹp nhưng không cho biết ai dùng, ở đâu, lúc nào, vì lý do gì – chỉ là mô hình kỹ thuật đơn lẻ.”
✅ Kết luận
6 góc nhìn trong mô hình hóa là la bàn định hướng cho tư duy hệ thống:
- Giúp đảm bảo không bị bỏ sót yêu cầu
- Tăng khả năng phản hồi, mở rộng hoặc điều chỉnh hệ thống
- Tạo nền tảng giao tiếp hiệu quả giữa nhiều phòng ban
📌 “Một bản vẽ chỉ có hình thì chưa đủ – nó cần trả lời được: cái gì, như thế nào, ở đâu, bởi ai, khi nào và tại sao.”
📘 Các loại mô hình phổ biến theo 6 góc nhìn – Chọn đúng công cụ cho đúng mục tiêu
📌 Mục tiêu
Không phải mô hình nào cũng phù hợp cho mọi góc nhìn. Việc chọn đúng loại mô hình cho từng loại yêu cầu sẽ giúp:
- Giao tiếp rõ ràng hơn với người dùng
- Lập trình viên hiểu rõ hơn yêu cầu
- Quản lý kiểm soát tốt hơn phạm vi và tiến độ
🗂 Tổng hợp mô hình theo 6 góc nhìn
| Góc nhìn | Câu hỏi chính | Mô hình phù hợp |
|---|---|---|
| WHAT | Dữ liệu là gì? | ERD, Data Dictionary, Logical Data Model |
| HOW | Làm như thế nào? | Use Case Diagram, Flowchart, Activity Diagram |
| WHERE | Ở đâu? | Deployment Diagram, Network Topology, Location Maps |
| WHO | Ai làm? | Role Map, Swimlane, User Story Mapping |
| WHEN | Khi nào? | Timeline, Event Diagram, Gantt Chart |
| WHY | Vì sao? | Business Case, Value Stream Map, Goal Model |
🔍 Phân tích theo từng loại mô hình
1. 🧱 Entity Relationship Diagram (ERD)
- Mục đích: Biểu diễn các thực thể dữ liệu và mối quan hệ giữa chúng.
- Phù hợp với: WHAT
- Dùng khi: Thiết kế cơ sở dữ liệu, phân tích dữ liệu đầu vào/ra
2. 🔄 Use Case Diagram
- Mục đích: Minh họa tương tác giữa người dùng và hệ thống
- Phù hợp với: HOW + WHO
- Dùng khi: Phân tích chức năng hệ thống từ góc nhìn người dùng
3. 📊 Flowchart
- Mục đích: Thể hiện trình tự bước xử lý (workflow)
- Phù hợp với: HOW + WHEN
- Dùng khi: Trình bày quy trình nghiệp vụ, logic xử lý
4. 🧑💼 Swimlane Diagram
- Mục đích: Phân chia vai trò theo luồng xử lý
- Phù hợp với: WHO + HOW
- Dùng khi: Giao tiếp nhiều phòng ban, nhiều trách nhiệm
5. 🌍 Deployment Diagram
- Mục đích: Mô tả các nút hệ thống và thành phần được triển khai ở đâu
- Phù hợp với: WHERE
- Dùng khi: Thiết kế kiến trúc hệ thống phân tán (web app, IoT,…)
6. 🧭 Value Stream Mapping
- Mục đích: Xác định chuỗi tạo giá trị trong hệ thống
- Phù hợp với: WHY + WHEN
- Dùng khi: Cải tiến quy trình, loại bỏ lãng phí
7. 📅 Gantt Chart / Timeline
- Mục đích: Quản lý thời gian và sự kiện chính
- Phù hợp với: WHEN
- Dùng khi: Lập kế hoạch tiến độ hoặc mô phỏng kịch bản xử lý
📌 Khi nào nên kết hợp nhiều mô hình?
Trong thực tế, không một mô hình nào là đủ. Bạn nên:
- Dùng Use Case + ERD + Flowchart để mô tả chức năng và dữ liệu
- Dùng Wireframe + UI Prototyping nếu có giao diện người dùng
- Dùng Role Map + Value Stream khi làm việc với nhiều phòng ban hoặc mục tiêu chuyển đổi
💡 Một bản Use Case mô tả hành vi, một sơ đồ ERD mô tả dữ liệu, và một Wireframe mô tả giao diện – sẽ giúp đội phát triển hình dung rõ hệ thống từ mọi góc.
✅ Kết luận
| Chọn đúng mô hình | Lợi ích |
|---|---|
| Theo góc nhìn phù hợp | Không bị rối thông tin |
| Gắn với đối tượng sử dụng | Người dùng dễ hiểu, kỹ thuật dễ triển khai |
| Kết hợp linh hoạt | Giao tiếp mạnh, phát triển hiệu quả |
📌 “Mỗi mô hình là một góc nhìn – phối hợp đúng cách sẽ cho bạn cái nhìn toàn cảnh.”
📘 Mô hình hóa theo vai trò – Ai dùng gì? Dùng khi nào?
📌 Tại sao cần phân vai trong mô hình hóa?
Trong một dự án phát triển theo Agile (đặc biệt là DSDM hoặc Scrum), không phải ai cũng cần hoặc hiểu toàn bộ các mô hình.
Việc chia mô hình theo vai trò giúp:
- Giao đúng thông tin cho đúng người
- Tránh gây rối, quá tải dữ liệu
- Tăng tốc độ phản hồi và ra quyết định
👥 Các vai trò chính trong dự án và mô hình tương ứng
Vai trò Mục tiêu Mô hình nên dùng Business Sponsor / Visionary Xác định chiến lược, mục tiêu dự án Value Stream Map, Business Case, WHY Models Product Owner / Business Analyst Phân tích yêu cầu, ưu tiên tính năng Use Case, User Stories, MoSCoW, Flowchart Solution Developer Thiết kế và xây dựng chức năng ERD, Class Diagram, Sequence Diagram, Activity Diagram Solution Tester / QA Kiểm thử, xác minh logic State Diagram, Test Scenario Flows UI/UX Designer Giao diện người dùng Wireframe, UI Prototype, User Journey Map Technical Architect Kiến trúc hệ thống Deployment Diagram, Component Diagram, Integration Map End Users / Stakeholders Phản hồi, góp ý Use Case, Wireframe, Flow mô tả đơn giản
🔄 Khi nào vai trò nào tham gia mô hình hóa?
Giai đoạn Vai trò chính Loại mô hình Feasibility Sponsor, Stakeholder Business Case, Value Stream Foundations BA, Architect High-Level Use Case, Flowchart, Architecture Map Exploration Dev, QA, BA Use Case, Activity Diagram, UI Prototype Engineering Dev, QA Class Diagram, Sequence, ERD Deployment Tester, End User Test Cases, UI Review, Operational Flows
🎯 Ví dụ thực tế: Dự án quản lý đào tạo
✅ Mục tiêu: Xây dựng hệ thống quản lý khóa học online cho trung tâm đào tạo
🧩 Mô hình theo vai trò:
- Sponsor → Xem Business Case (chi phí – lợi nhuận – phạm vi)
- Product Owner → Xem MoSCoW bảng tính năng: “Đăng ký khóa học” là Must Have
- BA → Vẽ Use Case: “Học viên đăng ký khóa học”, “Giảng viên upload bài”
- Developer → Xem ERD: bảng
Courses,Users,Enrollments- Tester → Vẽ luồng xử lý “Học viên quên mật khẩu” → kiểm thử exception case
- UX Designer → Thiết kế Wireframe cho trang dashboard
- Stakeholder → Nhìn sơ đồ Use Case để phản hồi
🛠 Cách quản lý mô hình hiệu quả theo vai trò
- Gắn mô hình với người dùng mục tiêu – ví dụ: mô hình cho PO phải dễ hiểu, tránh UML phức tạp
- Sử dụng màu, ký hiệu rõ ràng – giúp không chuyên cũng đọc được
- Cập nhật mô hình theo vòng lặp – không để mô hình cũ gây hiểu nhầm
- Đồng bộ mô hình và tài liệu thực tế (code, UI) – tránh mô hình chỉ là “trang trí”
✅ Kết luận
Việc mô hình hóa có mục tiêu, có đối tượng rõ ràng giúp:
- Tăng tính chính xác của thiết kế
- Giảm xung đột và hiểu sai
- Tăng tốc độ phê duyệt và phản hồi
📌 “Mô hình tốt không phải là phức tạp – mà là đúng người, đúng lúc, đúng cách.”
📘 Mini Case Study: Hệ thống quản lý học viên trực tuyến (Online Student Management System)
🎯 Mục tiêu dự án
Xây dựng một hệ thống giúp trung tâm đào tạo quản lý:
- Học viên
- Khóa học
- Lịch học
- Điểm danh
- Kết quả học tập
Dự án triển khai theo phương pháp Agile DSDM.
🔍 Giai đoạn 1: Feasibility (Tính khả thi)
Người tham gia: Business Sponsor, Project Manager, Stakeholders
| Nội dung | Mô hình tương ứng |
|---|---|
| Xác định mục tiêu kinh doanh | 🎯 Business Case – “Tăng hiệu suất vận hành và giảm thời gian nhập liệu 50%” |
| Phân tích chuỗi giá trị | 🔄 Value Stream Map – Từ đăng ký → học → đánh giá |
| Phạm vi ban đầu | 📦 Scope Overview Model – vẽ khối “Quản lý học viên”, “Lịch học”, “Điểm số” |
✅ Kết quả: Dự án khả thi, phạm vi ban đầu được xác định.
🧱 Giai đoạn 2: Foundations (Xây dựng nền tảng)
Người tham gia: Business Analyst, Technical Architect, Product Owner
| Nội dung | Mô hình tương ứng |
|---|---|
| Xác định tính năng | ✅ MoSCoW Prioritisation – “Quản lý học viên” là Must Have |
| Phân tích người dùng | 🧑🏫 Persona / Role Map – “Giảng viên”, “Quản trị viên”, “Học viên” |
| Kiến trúc hệ thống | 🧩 Deployment Diagram – Web frontend + MySQL + Server |
| Dòng xử lý tổng thể | 🔁 High-level Use Case Diagram – các ca sử dụng chính |
✅ Kết quả: Nắm được toàn bộ phạm vi hệ thống và kiến trúc kỹ thuật sơ bộ.
🔄 Giai đoạn 3: Exploration (Phân tích – thiết kế chi tiết)
Người tham gia: Solution Developer, UI/UX Designer, BA
| Nội dung | Mô hình tương ứng |
|---|---|
| Quy trình đăng ký khóa học | 🔄 Flowchart hoặc Activity Diagram |
| Thiết kế giao diện | 🎨 Wireframe + UI Prototype – trang Dashboard, trang Điểm danh |
| Quan hệ dữ liệu | 🧾 ERD – Entity Relationship Diagram – bảng Users, Courses, Enrollments |
| Tương tác người dùng | 👥 Use Case Diagram – cho từng vai trò |
✅ Kết quả: Các mô hình được dùng để tổ chức workshop góp ý với stakeholder, chốt luồng giao diện, dữ liệu và chức năng.
⚙️ Giai đoạn 4: Engineering (Lập trình & kiểm thử)
Người tham gia: Developer, Tester, QA, Product Owner
| Nội dung | Mô hình tương ứng |
|---|---|
| Thiết kế lớp xử lý | 🧱 Class Diagram – các entity Student, Course, Result |
| Trình tự hoạt động | ⏳ Sequence Diagram – từ nhập điểm → lưu DB → gửi thông báo |
| Kiểm thử quy trình | 📋 Test Scenario Flow – kiểm thử logic, exception case |
| Trạng thái người dùng | 🔄 State Diagram – đăng ký → đang học → hoàn tất |
✅ Kết quả: Hệ thống hoàn chỉnh về chức năng, có kiểm thử theo từng phần.
📦 Giai đoạn 5: Deployment (Triển khai và bàn giao)
Người tham gia: End Users, Operations, Trainer
| Nội dung | Mô hình tương ứng |
|---|---|
| Hướng dẫn người dùng | 📘 Annotated UI Screens – mô tả từng bước thao tác |
| Luồng vận hành chính thức | 🧭 Operational Flow – hỗ trợ nhập học, sắp xếp lịch học |
| Kịch bản sử dụng | 👤 Task Scenario Map – “Quản trị viên tạo lớp học” |
✅ Kết quả: Người dùng sử dụng được sản phẩm, có tài liệu hướng dẫn dựa trên mô hình.
✅ Tổng kết toàn bộ case study
| Giai đoạn | Mô hình chính |
|---|---|
| Feasibility | Business Case, Value Stream |
| Foundations | Use Case tổng quát, MoSCoW, Architecture Map |
| Exploration | Wireframe, ERD, Use Case chi tiết, Flowchart |
| Engineering | Class, Sequence, Test Scenario |
| Deployment | Task Scenario, UI Guide, Operational Flow |
📌 “Không cần mô hình hóa quá phức tạp – chỉ cần dùng đúng công cụ, đúng thời điểm, cho đúng người.”
