2. Phương pháp phân tích hệ thống thông tin dạng cứng

2. Phương pháp phân tích hệ thống thông tin dạng cứng

29-07-2025
Toanngo92
0 Comments

Mục lục

Phương pháp tiếp cận cứng trong phân tích hệ thống thông tin là gì?

1. Khái niệm

Phương pháp tiếp cận cứng (Hard Approach) trong phân tích hệ thống thông tin là cách tiếp cận mang tính cấu trúc cao, tuân theo một trình tự logic rõ ràng, đi kèm với quy tắc, hướng dẫn và tiêu chuẩn chặt chẽ. Đây là phương pháp phân tích theo lối truyền thống, nhấn mạnh vào sự chính xác, độ tin cậy, và khả năng lập tài liệu hệ thống hóa.

Khác với phương pháp mềm vốn linh hoạt và tập trung vào con người – hành vi – cảm nhận, phương pháp cứng coi hệ thống như một tập hợp các quy trình xử lý dữ liệu có thể đo lường và kiểm soát được.

2. Đặc điểm nổi bật

Tuân thủ trình tự rõ ràng: Từ nghiên cứu khả thi, đến phân tích, thiết kế, triển khai, kiểm thử và bảo trì – tất cả các bước đều phải thực hiện tuần tự.
Chuẩn hóa quy trình: Mỗi giai đoạn có đầu ra cụ thể, giúp dễ dàng kiểm soát và đánh giá tiến độ.
Tài liệu hóa chi tiết: Hệ thống được ghi chép đầy đủ, từ sơ đồ luồng dữ liệu, mô hình thực thể – mối quan hệ, cho đến quy trình nghiệp vụ.
Giảm thiểu rủi ro thay đổi: Vì các yêu cầu được xác định rõ từ đầu, nên việc thay đổi giữa chừng thường khó, nhưng đổi lại độ ổn định và tính kiểm soát cao.

3. Khi nào nên sử dụng phương pháp tiếp cận cứng?

Phương pháp này đặc biệt phù hợp với các hệ thống lớn, phức tạp và có độ rủi ro cao, ví dụ như:

Các hệ thống chính phủ (quản lý dân cư, thuế, bảo hiểm…).
Các hệ thống tài chính, ngân hàng, y tế – nơi mà độ chính xác, tuân thủ quy định và tài liệu hóa là bắt buộc.
Dự án triển khai nội bộ tại doanh nghiệp lớn, có quy trình nghiêm ngặt.

Tuy nhiên, phương pháp này cũng có thể áp dụng cho hệ thống doanh nghiệp quy mô nhỏ hơn, đặc biệt là khi doanh nghiệp có mục tiêu xây dựng hệ thống dài hạn, yêu cầu khả năng kiểm soát cao và đội ngũ có chuyên môn rõ ràng.

4. Ưu và nhược điểm

Ưu điểm:

Dễ đo lường tiến độ qua từng giai đoạn cụ thể.
Quản lý được phạm vi dự án rõ ràng từ đầu.
Dễ dàng kiểm tra chất lượng, bảo trì và nâng cấp sau này.

Nhược điểm:

Thiếu linh hoạt nếu yêu cầu thay đổi.
Người dùng thường tham gia ít, dẫn đến sản phẩm cuối không sát thực tế.
Thời gian triển khai dài, chi phí cao nếu cần sửa đổi giữa chừng.

5. Tóm tắt

Phương pháp tiếp cận cứng trong phân tích hệ thống là sự lựa chọn lý tưởng khi dự án cần độ chính xác cao, có cấu trúc ổn định, và cần được kiểm soát chặt chẽ. Tuy không phù hợp với mọi tình huống, nhưng nếu áp dụng đúng bối cảnh, đây là nền tảng giúp đảm bảo tính toàn vẹn và thành công cho hệ thống thông tin.

Ví dụ về các phương pháp tiếp cận cứng trong phân tích hệ thống

Sau khi hiểu khái quát về phương pháp tiếp cận cứng (Hard Approach), việc tìm hiểu các phương pháp cụ thể trong nhóm này giúp người học có cái nhìn thực tế hơn về cách tiếp cận được triển khai như thế nào. Dưới đây là một số phương pháp tiêu biểu đại diện cho phương pháp tiếp cận cứng:

1. SSADM (Structured Systems Analysis and Design Methodology)

SSADM là một trong những phương pháp phân tích hệ thống có cấu trúc phổ biến nhất tại Anh và nhiều quốc gia Châu Âu. Đây là phương pháp theo mô hình thác nước (waterfall), chia quá trình phát triển hệ thống thành các giai đoạn cụ thể từ nghiên cứu khả thi, phân tích, thiết kế đến triển khai và bảo trì.

📌 Tính chất nổi bật:

Mỗi bước phải hoàn thành trước khi chuyển sang bước tiếp theo.
Tài liệu hoá đầy đủ.
Thường dùng trong các dự án chính phủ, doanh nghiệp lớn.

2. Prototyping (Mẫu thử)

Mặc dù có tính linh hoạt, nhưng prototyping vẫn được xem là phương pháp cứng khi được triển khai theo mô hình có cấu trúc. Trong phương pháp này, một mẫu hệ thống được phát triển nhanh chóng để kiểm tra và xác minh các yêu cầu của người dùng.

📌 Ứng dụng:

Dự án có yêu cầu chưa rõ ràng.
Người dùng có thể tham gia đánh giá sớm và góp ý.

3. JAD (Joint Application Design)

JAD là phương pháp tiếp cận có cấu trúc cao để thu thập yêu cầu, tập trung vào các buổi làm việc trực tiếp giữa nhà phân tích, khách hàng và nhà phát triển. Phương pháp này hướng đến việc thống nhất các yêu cầu một cách nhanh chóng và có tổ chức.

📌 Ưu điểm:

Rút ngắn thời gian thu thập yêu cầu.
Tăng sự đồng thuận giữa các bên liên quan.

4. RAD (Rapid Application Development)

RAD nhấn mạnh tốc độ trong phát triển ứng dụng bằng cách chia nhỏ hệ thống thành các module có thể phát triển độc lập. Các module được thiết kế, kiểm thử và tích hợp liên tục.

📌 Điểm nổi bật:

Tốc độ triển khai nhanh.
Vẫn giữ được cấu trúc logic rõ ràng, nên được xếp vào nhóm tiếp cận cứng.

5. DSDM (Dynamic Systems Development Method)

DSDM mở rộng từ RAD, có thêm các nguyên tắc quản lý chất lượng, kiểm soát thay đổi và quy trình phát triển rõ ràng. Dù mang tính linh hoạt cao, nhưng DSDM vẫn dựa vào cấu trúc quy trình nên nằm giữa tiếp cận cứng và mềm.

6. Scrum và Agile

Scrum và Agile thường được xem là phương pháp linh hoạt (soft approach). Tuy nhiên, trong nhiều trường hợp – đặc biệt là khi được triển khai theo khung nghiêm ngặt và có kế hoạch sprint rõ ràng, chúng có thể trở thành những phương pháp tiếp cận cứng, nhất là trong giai đoạn phân tích yêu cầu.

📌 Chú ý:
Scrum chỉ thật sự trở thành phương pháp tiếp cận cứng khi các bước trong quy trình được lập kế hoạch và kiểm soát chặt chẽ.

7. Tổng kết

Phương pháp	Đặc điểm chính	Khi sử dụng
SSADM	Mô hình thác nước, tài liệu hóa chặt chẽ	Hệ thống lớn, yêu cầu ổn định
Prototyping	Làm mẫu thử, kiểm tra sớm yêu cầu	Khi yêu cầu chưa rõ
JAD	Thu thập yêu cầu qua họp nhóm	Cần thống nhất nhanh giữa các bên
RAD	Phát triển nhanh, chia module	Dự án cần triển khai nhanh
DSDM	Quản lý chặt chẽ, hỗ trợ linh hoạt	Dự án cần kiểm soát tốt chất lượng
Scrum/Agile	Chu trình lặp, tổ chức rõ ràng	Khi triển khai agile theo quy trình chuẩn

Trong phần tiếp theo, chúng ta sẽ đi sâu vào phương pháp SSADM – đại diện tiêu biểu nhất cho tiếp cận cứng – để hiểu rõ góc nhìn hệ thống, các bước triển khai cũng như ưu nhược điểm của phương pháp này.

SSADM – Phương pháp phân tích và thiết kế hệ thống có cấu trúc

1. SSADM là gì?

SSADM (Structured Systems Analysis and Design Methodology) là một phương pháp phân tích và thiết kế hệ thống thông tin có cấu trúc, được phát triển tại Vương quốc Anh vào những năm 1980. SSADM là biểu hiện tiêu biểu của phương pháp tiếp cận cứng trong lĩnh vực phát triển hệ thống.

Phương pháp này đặc trưng bởi mô hình tuyến tính (thác nước) – trong đó mỗi giai đoạn (như phân tích, thiết kế, triển khai…) phải được hoàn tất hoàn toàn trước khi chuyển sang bước tiếp theo.

2. Ba góc nhìn hệ thống trong SSADM

SSADM phân tích hệ thống dưới ba góc nhìn chính để đảm bảo toàn diện:

a) Process View (Góc nhìn quy trình)

Mô tả các chức năng mà hệ thống thực hiện.
Trình bày luồng dữ liệu giữa các chức năng.
Làm rõ cách dữ liệu biến đổi khi đi qua các bước xử lý.

b) Data View (Góc nhìn dữ liệu)

Tập trung vào việc mô tả cấu trúc dữ liệu, thông tin mà hệ thống lưu trữ và xử lý.
Bao gồm các thực thể (entities), thuộc tính (attributes) và quan hệ (relationships).

c) Event View (Góc nhìn sự kiện)

Mô tả các sự kiện từ môi trường bên ngoài làm kích hoạt hệ thống.
Trình bày tác động của các sự kiện lên dữ liệu và quy trình.

🎯 Ba góc nhìn này tương ứng với ba kỹ thuật cốt lõi của SSADM: Data Flow Diagram (DFD), Logical Data Model (LDM), và Entity-Event Modelling.

3. Ưu điểm của việc phân tích hệ thống qua ba góc nhìn

Tránh bỏ sót thông tin: Mỗi góc nhìn giúp soi chiếu hệ thống từ một khía cạnh riêng biệt.
Đảm bảo sự nhất quán: Các góc nhìn liên kết với nhau và kiểm tra chéo để đảm bảo không có mâu thuẫn.
Hỗ trợ thiết kế chính xác: Nhờ hiểu sâu cả về dữ liệu, quy trình và ngữ cảnh kích hoạt, người phân tích có thể thiết kế hệ thống tối ưu.

4. Vì sao SSADM vẫn còn được dùng?

Dù nhiều phương pháp hiện đại như Agile, DevOps đang trở nên phổ biến, SSADM vẫn được áp dụng trong những bối cảnh:

Cần sự ổn định, chính xác và tài liệu đầy đủ.
Dự án có quy mô lớn, yêu cầu khắt khe về kiểm tra, nghiệm thu, và tích hợp hệ thống.
Tổ chức cần tuân thủ chuẩn ISO, CMMI, hay tiêu chuẩn nhà nước.

5. Nhận định

SSADM không chỉ là một phương pháp kỹ thuật, mà còn là một hệ tư tưởng quản lý và kiểm soát hệ thống. Khi áp dụng đúng, nó giúp đảm bảo tính đầy đủ, nhất quán, và khả năng mở rộng của hệ thống thông tin trong tương lai.

Các bước trong quy trình SSADM (Structured Systems Analysis and Design Methodology)

SSADM được tổ chức như một chuỗi các bước tuần tự và chặt chẽ, thể hiện qua mô hình phát triển phần mềm dạng thác nước (Waterfall). Trong mô hình này, mỗi giai đoạn phải được hoàn thành đầy đủ và có tài liệu rõ ràng trước khi chuyển sang bước tiếp theo.

Dưới đây là 6 giai đoạn cơ bản trong SSADM:

1. Nghiên cứu khả thi (Feasibility Study)

✅ Mục tiêu:

Xác định xem dự án có khả thi hay không về mặt kỹ thuật, tài chính và xã hội.

🔍 Các hoạt động chính:

Đánh giá công nghệ: Hệ thống đề xuất có thể được xây dựng bằng công nghệ hiện tại không?
Phân tích chi phí – lợi ích (Cost-benefit analysis): Liệu đầu tư có xứng đáng với hiệu quả mang lại?
Xem xét tác động xã hội: Việc triển khai có ảnh hưởng tiêu cực đến nhân sự, quy trình, hoặc người dùng không?

📌 Kết quả: Một báo cáo nghiên cứu khả thi giúp ban lãnh đạo quyết định có nên tiếp tục dự án hay không.

2. Phân tích và xác định yêu cầu (Analysis and Requirements Specification)

✅ Mục tiêu:

Xác định chính xác các yêu cầu hệ thống từ phía người dùng và doanh nghiệp.

🔍 Các hoạt động chính:

Phân tích quy trình hiện tại (As-Is).
Phỏng vấn, khảo sát người dùng.
Lập tài liệu yêu cầu kỹ thuật (System Requirements Specification – SRS).

📌 Kết quả: Toàn bộ chức năng, dữ liệu, quy trình và ràng buộc kỹ thuật được mô tả rõ ràng và chuẩn hóa.

3. Thiết kế (Design)

✅ Mục tiêu:

Xây dựng bản thiết kế chi tiết cho hệ thống tương lai.

🔍 Các hoạt động chính:

Thiết kế giao diện người dùng.
Thiết kế cấu trúc dữ liệu, cơ sở dữ liệu.
Thiết kế các quy trình xử lý.
Xác định kiến trúc hệ thống (phân tán, client-server, v.v.).

📌 Kết quả: Một hồ sơ thiết kế hệ thống hoàn chỉnh, sẵn sàng để lập trình hoặc đấu thầu triển khai.

4. Triển khai (Implementation)

✅ Mục tiêu:

Đưa hệ thống vào vận hành thực tế trong tổ chức.

🔍 Các phương pháp triển khai:

Thay đổi trực tiếp (direct cutover): Ngừng hệ thống cũ, đưa hệ thống mới vào ngay.
Thay đổi dần (phased implementation): Chuyển dần từng phần chức năng.
Chạy song song (parallel running): Vận hành cả hai hệ thống để đối chiếu.

📌 Kết quả: Hệ thống bắt đầu được người dùng sử dụng trong môi trường thật.

5. Kiểm thử (Testing)

✅ Mục tiêu:

Đảm bảo rằng hệ thống hoạt động ổn định, đúng chức năng và không có lỗi nghiêm trọng.

🔍 Các loại kiểm thử:

Kiểm thử đơn vị (Unit Test): Kiểm tra từng thành phần nhỏ.
Kiểm thử tích hợp (Integration Test): Kiểm tra các thành phần khi làm việc chung.
Kiểm thử hệ thống (System Test): Kiểm tra toàn bộ hệ thống.
Kiểm thử chấp nhận (User Acceptance Test – UAT): Người dùng cuối xác nhận tính đúng đắn.

📌 Kết quả: Hệ thống được xác nhận là đủ điều kiện để đưa vào sử dụng chính thức.

6. Bảo trì (Maintenance)

✅ Mục tiêu:

Giữ cho hệ thống hoạt động ổn định, an toàn và thích ứng với thay đổi trong tương lai.

🔧 Hoạt động bảo trì bao gồm:

Sửa lỗi phát sinh sau khi đưa vào sử dụng.
Cập nhật hệ thống để phù hợp với quy định hoặc công nghệ mới.
Bổ sung tính năng theo yêu cầu người dùng.

📌 Giai đoạn bảo trì chiếm tỷ lệ lớn nhất về thời gian và chi phí trong toàn bộ vòng đời hệ thống.

💡 Tổng kết

Giai đoạn	Mục tiêu chính
Nghiên cứu khả thi	Đánh giá khả năng triển khai dự án
Phân tích & yêu cầu	Xác định rõ hệ thống cần làm gì
Thiết kế	Xây dựng bản thiết kế chi tiết
Triển khai	Đưa hệ thống vào hoạt động
Kiểm thử	Đảm bảo hệ thống đúng yêu cầu, không có lỗi
Bảo trì	Giữ cho hệ thống ổn định, thích ứng và cập nhật

Ưu điểm và nhược điểm của phương pháp SSADM

Phương pháp SSADM, với tính hệ thống và cấu trúc rõ ràng, đã trở thành chuẩn mực trong nhiều dự án phát triển hệ thống thông tin truyền thống. Tuy nhiên, như mọi phương pháp, SSADM có cả mặt mạnh và mặt hạn chế, đặc biệt trong bối cảnh các phương pháp linh hoạt (Agile) ngày càng phổ biến.

🔷 Ưu điểm của SSADM

1. Trình tự rõ ràng và có kiểm soát

SSADM yêu cầu hoàn tất từng bước trước khi chuyển sang bước kế tiếp. Điều này giúp đảm bảo không bỏ sót yêu cầu hay bước quan trọng nào, và giúp kiểm soát tiến độ một cách hiệu quả.

2. Dễ đo lường tiến độ

Với mỗi giai đoạn đều có mục tiêu rõ ràng và đầu ra xác định, người quản lý có thể dễ dàng theo dõi tiến độ dự án, phát hiện chậm trễ và điều chỉnh kịp thời.

3. Tài liệu hóa đầy đủ

Mỗi bước đều sinh ra tài liệu chi tiết: từ đặc tả yêu cầu, thiết kế hệ thống, đến tài liệu kiểm thử. Việc này giúp việc duy trì, bảo trì và chuyển giao hệ thống sau này trở nên dễ dàng.

4. Phù hợp với các tổ chức yêu cầu tuân thủ tiêu chuẩn

Các ngành như tài chính, chính phủ, y tế… thường yêu cầu hệ thống phải được xây dựng theo quy trình chuẩn hóa và có thể kiểm toán – SSADM là lựa chọn phù hợp.

🔶 Nhược điểm của SSADM

1. Thiếu linh hoạt

Vì mỗi bước phải hoàn thành hoàn toàn mới được tiếp tục, nên nếu trong quá trình phát triển có thay đổi yêu cầu, việc quay lại sửa đổi là rất tốn kém, thậm chí không khả thi.

🧠 Ví dụ: Nếu đã hoàn tất thiết kế mà phát hiện thiếu chức năng trong giai đoạn yêu cầu, việc quay lại sẽ gây chậm tiến độ và tăng chi phí đáng kể.

2. Ít sự tham gia của người dùng

Phương pháp SSADM thường tập trung vào phân tích kỹ thuật và quy trình nội bộ, khiến người dùng cuối bị tách rời khỏi quá trình phát triển. Điều này có thể dẫn đến sản phẩm cuối không sát với nhu cầu thực tế.

3. Triển khai chậm hơn các phương pháp hiện đại

SSADM không cho phép lặp lại hay phát triển theo chu trình nhỏ như Agile, khiến tổng thời gian triển khai thường dài hơn, khó thích nghi với môi trường kinh doanh thay đổi nhanh.

📊 Bảng so sánh tóm tắt

Tiêu chí	Ưu điểm (✔)	Nhược điểm (✘)
Tính hệ thống	✔ Rõ ràng, chặt chẽ	✘ Khó điều chỉnh khi thay đổi yêu cầu
Tài liệu hóa	✔ Chi tiết, dễ bảo trì	✘ Tốn thời gian và công sức
Phản hồi người dùng	✘ Hạn chế	✔ Agile làm tốt hơn
Thời gian triển khai	✘ Chậm hơn	✔ Nếu yêu cầu ổn định thì phù hợp
Độ phù hợp dự án lớn	✔ Rất tốt	✘ Không linh hoạt với startup hoặc MVP

📝 Kết luận

Phương pháp SSADM vẫn là một lựa chọn đáng tin cậy và vững chắc trong các dự án yêu cầu cấu trúc rõ ràng, quản lý rủi ro chặt chẽ và tài liệu đầy đủ. Tuy nhiên, nó không phù hợp với các dự án nhỏ, linh hoạt, cần phản hồi nhanh từ người dùng.

Các kỹ thuật chính trong SSADM

Trong phương pháp SSADM, việc phân tích và thiết kế hệ thống không chỉ dừng lại ở lý thuyết mà được triển khai bằng những kỹ thuật cụ thể, cho phép mô hình hóa, kiểm tra và đảm bảo tính toàn vẹn của hệ thống. Ba kỹ thuật chủ đạo trong SSADM gồm:

🔧 1. Mô hình hóa dữ liệu logic (Logical Data Modelling)

🎯 Mục tiêu:

Trình bày cấu trúc dữ liệu của hệ thống dưới dạng trừu tượng, phi vật lý – chưa gắn với bất kỳ nền tảng cơ sở dữ liệu cụ thể nào.

🔍 Thành phần chính:

Thực thể (Entity): Là đối tượng lưu trữ thông tin, ví dụ: Khách hàng, Đơn hàng.
Thuộc tính (Attribute): Là đặc điểm mô tả thực thể, ví dụ: Tên khách hàng, Mã đơn hàng.
Mối quan hệ (Relationship): Xác định sự liên kết giữa các thực thể, ví dụ: Khách hàng đặt nhiều đơn hàng.

📌 Mô hình này là nền tảng để chuyển thành thiết kế cơ sở dữ liệu sau này (ERD → DBMS).

🔁 2. Mô hình hóa luồng dữ liệu (Data Flow Modelling – DFD)

🎯 Mục tiêu:

Mô tả cách dữ liệu di chuyển và được xử lý trong hệ thống thông tin.

🔍 Thành phần DFD:

Process (Quy trình): Hoạt động xử lý dữ liệu (hình tròn/oval).
Data Flow (Luồng dữ liệu): Mũi tên chỉ hướng dữ liệu di chuyển.
Data Store (Kho dữ liệu): Nơi lưu trữ thông tin tạm thời hoặc lâu dài (hộp mở).
External Entity (Thực thể ngoài): Người hoặc tổ chức tương tác với hệ thống.

📌 DFD thường được phân cấp từ tổng quan (level 0) đến chi tiết (level 1, level 2…), giúp giảm độ phức tạp và tập trung vào từng quy trình nhỏ.

⏱ 3. Mô hình hóa sự kiện – thực thể (Entity/Event Modelling)

🎯 Mục tiêu:

Mô tả cách dữ liệu thay đổi theo sự kiện thời gian, hoặc tác động bên ngoài.

🔍 Nội dung phân tích:

Sự kiện (Event): Một hành động xảy ra và ảnh hưởng đến hệ thống, ví dụ: Khách hàng đặt hàng, Đơn hàng bị huỷ.
Ảnh hưởng lên thực thể: Mỗi sự kiện sẽ dẫn đến thay đổi dữ liệu trong các thực thể cụ thể.
Thứ tự xử lý: Phân tích trình tự xảy ra các sự kiện giúp hệ thống phản hồi đúng và hợp lý.

📌 Kỹ thuật này giúp hệ thống thích ứng với môi trường động, ví dụ như quy trình đặt hàng, thanh toán, cập nhật kho hàng…

🔄 Sự kết hợp giữa các kỹ thuật

Điểm mạnh của SSADM nằm ở việc liên kết ba kỹ thuật trên với nhau:

Dữ liệu (Data) → Quy trình (Process) → Sự kiện (Event)
Từ đó đảm bảo rằng thiết kế hệ thống không bị thiếu góc nhìn, và có thể kiểm tra chéo để phát hiện sai sót logic.

📌 Minh hoạ ví dụ nhỏ:

Một hệ thống quản lý đơn hàng:

Thực thể: Khách hàng, Đơn hàng, Sản phẩm
DFD: Luồng từ “Tạo đơn hàng” → “Kiểm tra kho” → “Gửi email xác nhận”
Sự kiện: Khách hàng bấm “Đặt hàng” → sinh ra đơn hàng mới

🧠 Tóm lại

Kỹ thuật	Mục tiêu	Đặc điểm nổi bật
Mô hình dữ liệu logic	Xây dựng cấu trúc dữ liệu	Tập trung vào thực thể và quan hệ
Mô hình luồng dữ liệu (DFD)	Hiểu và mô tả quy trình xử lý dữ liệu	Phân cấp từ tổng quan đến chi tiết
Mô hình sự kiện – thực thể	Phân tích hành vi thay đổi của hệ thống	Hỗ trợ xử lý hệ thống phản ứng theo sự kiện

Sơ đồ luồng dữ liệu (DFD) trong phân tích hệ thống

1. DFD là gì?

DFD (Data Flow Diagram) hay Sơ đồ luồng dữ liệu là công cụ trực quan dùng để mô hình hóa cách dữ liệu di chuyển trong một hệ thống thông tin, từ lúc dữ liệu vào cho đến khi được xử lý và tạo ra đầu ra.

DFD không mô tả thứ tự xử lý theo thời gian hay chi tiết phần mềm, mà tập trung vào:

Dữ liệu đến từ đâu?
Đi đâu?
Được xử lý như thế nào?
Lưu trữ ở đâu?

2. Vai trò của DFD

DFD là công cụ trung tâm trong phương pháp SSADM, với vai trò:

Minh họa cấu trúc logic của hệ thống.
Giúp phân tích viên, lập trình viên và người dùng hiểu rõ các dòng dữ liệu và cách hệ thống vận hành.
Là cơ sở để thiết kế mô-đun xử lý, giao diện và cơ sở dữ liệu.

3. Các thành phần chính trong DFD

Thành phần	Ký hiệu (hình ảnh)	Vai trò
Process	Hình oval / tròn	Quy trình xử lý dữ liệu, biến đổi đầu vào thành đầu ra
Data Store	Hộp mở 1 đầu ([])	Nơi lưu trữ dữ liệu (có thể là cơ sở dữ liệu hoặc tệp thủ công)
External Entity	Hình tròn nhỏ hoặc vuông	Tác nhân ngoài hệ thống (khách hàng, nhà cung cấp…)
Data Flow	Mũi tên có tên	Chỉ hướng dữ liệu di chuyển giữa các thành phần

4. Các cấp độ của DFD

DFD thường được xây dựng theo cấp độ từ khái quát đến chi tiết, gọi là phân rã (decomposition):

Level 0 (Context Diagram): Chỉ gồm 1 process chính (toàn hệ thống), các tác nhân ngoài và luồng dữ liệu tổng quan.
Level 1: Phân tách process chính thành các process con.
Level 2, 3,…: Tiếp tục phân tách các process con nếu cần chi tiết hơn.

📌 Cách phân rã này giúp tránh sơ đồ rối rắm, dễ hiểu và phù hợp với từng đối tượng xem xét (nhà quản lý, kỹ thuật viên, người dùng).

5. Các loại DFD

Loại DFD	Mục đích
Current Physical	Mô tả hệ thống hiện tại theo cách triển khai vật lý
Current Logical	Mô tả logic hoạt động hiện tại, không phụ thuộc công nghệ
Required Logical	Mô tả logic mong muốn của hệ thống mới
Required Physical	Mô tả cách triển khai vật lý hệ thống mới

6. Quy tắc khi vẽ DFD

✅ Các quy tắc chính:

Dữ liệu chỉ được truyền từ/đến Process, không được truyền thẳng giữa External Entity và Data Store.
Data Store phải được kết nối với Process, không được nối trực tiếp với nhau.
External Entity không được kết nối với nhau.
Mỗi luồng dữ liệu phải có tên rõ ràng, mô tả dữ liệu đang đi qua.

📌 Ký hiệu đánh số:

Mỗi Process nên được đánh số (1, 2, 3…) để quản lý và tham chiếu dễ dàng.
Data Store được mã hoá bằng chữ cái:
- D = File máy tính,
- M = Tệp thủ công,
- T = Tệp tạm thời, ví dụ: T1

7. Ví dụ minh hoạ

Hệ thống đặt hàng:

External Entity: Customer
Process: 1. Nhận đơn hàng, 2. Kiểm tra kho, 3. Xác nhận đơn
Data Store: D1: Danh sách sản phẩm, D2: Đơn hàng chờ xử lý
Luồng dữ liệu: Thông tin đặt hàng, Phản hồi kho, Xác nhận đơn

🧠 Với Level 0: chỉ có 1 process “Hệ thống đặt hàng”, kết nối với “Customer”.
Với Level 1: tách thành 3 process như trên để thể hiện logic chi tiết hơn.

8. Ưu điểm của DFD

Dễ hiểu: Không cần kiến thức lập trình, người dùng vẫn có thể hiểu sơ đồ.
Thể hiện ranh giới hệ thống rõ ràng.
Có thể phân cấp để dễ quản lý sơ đồ phức tạp.
Tập trung vào logic xử lý, tách rời yếu tố kỹ thuật.

📌 Tóm lược

Ưu điểm chính của DFD
✔ Trực quan, dễ đọc
✔ Thích hợp trình bày với người dùng không chuyên
✔ Giúp phát hiện sớm lỗi logic, thiếu dữ liệu
✔ Hỗ trợ mô hình hóa hệ thống lớn nhờ phân rã (decomposition)

Hướng dẫn xây dựng sơ đồ luồng dữ liệu (DFD)

Sau khi đã hiểu sơ lược về mục đích, cấu trúc và các cấp độ của DFD, để vẽ được một sơ đồ đúng và nhất quán, ta cần nắm chắc các ký hiệu, quy ước đặt tên, và nguyên tắc xây dựng. Điều này đảm bảo rằng sơ đồ không chỉ chính xác về mặt kỹ thuật mà còn dễ hiểu với người dùng cuối.

🔷 1. Ký hiệu sơ đồ DFD

✅ Luồng dữ liệu (Data Flow)

Ký hiệu: Mũi tên →
Mô tả: Biểu thị dữ liệu di chuyển từ điểm này sang điểm khác.
Quy ước:
- Mỗi luồng phải có tên mô tả ý nghĩa rõ ràng, ví dụ: Phiếu đặt hàng, Kết quả kiểm tra.
- Không được dùng tên chung chung như “Thông tin”, “Dữ liệu”.

✅ Process (Quy trình xử lý)

Ký hiệu: Hình oval hoặc hình tròn có ba phần:
- Số thứ tự (trên trái): Ví dụ: 1, 2.1
- Tên quy trình (dưới cùng): Diễn đạt hành động rõ ràng, ví dụ: Xử lý đơn hàng
- Vị trí hoặc người thực hiện (trên phải): Tùy chọn, ví dụ: Bộ phận bán hàng

📌 Quy tắc: Tên quy trình nên bắt đầu bằng động từ, thể hiện rõ hành động (xử lý, xác nhận, tính toán…).

✅ Data Store (Kho dữ liệu)

Ký hiệu: Hình chữ nhật mở một đầu [ ]
Cấu trúc tên:
- Có thể có mã tham chiếu như: D1: Đơn hàng, M2: Hồ sơ giấy, T1: File tạm
- Chữ cái đầu thể hiện loại lưu trữ:
  - D = dữ liệu trong hệ thống
  - M = tài liệu giấy
  - T = dữ liệu tạm thời

✅ External Entity (Tác nhân ngoài)

Ký hiệu: Hình tròn nhỏ, hình vuông, hoặc hình người đơn giản
Quy tắc:
- Gắn tên mô tả rõ ràng, ví dụ: Khách hàng, Nhà cung cấp.
- Nếu cần xuất hiện nhiều lần trên sơ đồ, nên đánh dấu ký hiệu phân biệt, ví dụ: Khách hàng a, Khách hàng b.
- Có thể thêm dấu sọc gạch chéo bên góc trái khi thực thể được lặp lại để tránh vẽ quá nhiều đường giao nhau.

🔶 2. Quy tắc thiết kế sơ đồ DFD

❗ Luồng dữ liệu chỉ được truyền từ/đến Process

Không được nối trực tiếp giữa:
- External Entity ↔ Data Store
- Data Store ↔ Data Store
- External Entity ↔ External Entity

✅ Mỗi Process phải có ít nhất:

Một đầu vào và một đầu ra dữ liệu.
Nếu Process không có dữ liệu đi vào, nó đang tạo ra dữ liệu bất hợp lý.

📌 Data Store:

Phải có ít nhất một luồng vào (ghi dữ liệu) và một luồng ra (đọc dữ liệu) kết nối với Process.

📌 External Entity:

Phải kết nối với ít nhất một process thông qua luồng dữ liệu.

📐 3. Hướng dẫn xây dựng một DFD đơn giản

Bước 1: Xác định các thực thể ngoài

Ai/cái gì tương tác với hệ thống? (Người dùng, nhà cung cấp, ngân hàng…)

Bước 2: Xác định các quy trình chính

Các hành động hoặc chức năng hệ thống cần thực hiện.

Bước 3: Xác định dữ liệu lưu trữ

Dữ liệu nào cần lưu lại giữa các bước? (Danh sách khách hàng, đơn hàng…)

Bước 4: Vẽ sơ đồ cấp độ 0 (Context Diagram)

Một process chính duy nhất, liên kết với các tác nhân ngoài.

Bước 5: Phân rã sơ đồ thành cấp độ 1, 2…

Tách process chính thành các bước con, tiếp tục mở rộng nếu cần.

Bước 6: Kiểm tra logic sơ đồ

Có luồng nào bị sai? Có quá nhiều kết nối chéo? Có process nào không có input/output?

💡 Mẹo khi thiết kế DFD hiệu quả

Sử dụng tên hành động rõ ràng cho Process (bắt đầu bằng động từ).
Tránh sơ đồ quá rối: Dùng phân cấp thay vì dồn mọi thứ vào một hình.
Ghi chú riêng các giả định nếu sơ đồ đơn giản hóa thực tế.
Duy trì tính nhất quán: Tên gọi trong DFD nên trùng với đặc tả hệ thống và tài liệu yêu cầu.

📌 Tổng kết nhanh

Thành phần	Quy tắc chính
Data Flow	Luôn có tên, không được kết nối trực tiếp 2 entity
Process	Có input và output, tên bắt đầu bằng động từ
Data Store	Kết nối với process, không được nối nhau trực tiếp
External Entity	Giao tiếp với hệ thống qua process duy nhất

Ví dụ minh hoạ: Hệ thống đặt hàng trực tuyến

🎯 Bài toán mô tả

Một cửa hàng trực tuyến muốn xây dựng hệ thống xử lý đơn hàng với các yêu cầu sau:

Khách hàng gửi đơn hàng.
Hệ thống kiểm tra tồn kho.
Nếu hàng có sẵn, xác nhận đơn và cập nhật kho.
Nếu hàng không đủ, thông báo từ chối đơn hàng.
Quản lý đơn hàng được lưu lại trong hệ thống.

Bước 1: Context Diagram (DFD Level 0)

✅ Mục tiêu: Mô tả toàn hệ thống như một “hộp đen”, chỉ thể hiện:

Ai tương tác với hệ thống?
Dữ liệu vào/ra là gì?

✏️ Thành phần

External Entities:
- Khách hàng
Process duy nhất:
- Hệ thống đặt hàng
Data Flows:
- Từ Khách hàng → Hệ thống: Đơn đặt hàng
- Từ Hệ thống → Khách hàng: Xác nhận đơn / Từ chối đơn

🖼️ Mô tả bằng lời

scssCopyEdit[Khách hàng]
    ↓     (Đơn đặt hàng)
[Process 0: Hệ thống đặt hàng]
    ↓     (Xác nhận / Từ chối)
[Khách hàng]

📌 Đây là sơ đồ khái quát, giúp người không chuyên cũng hiểu hệ thống hoạt động như thế nào ở mức tổng thể.

Bước 2: DFD Level 1 – Phân rã quy trình “Hệ thống đặt hàng”

✅ Mục tiêu: Làm rõ các bước xử lý chính bên trong hệ thống.

✏️ Các Process chính

1.1 Nhận đơn hàng
1.2 Kiểm tra tồn kho
1.3 Xác nhận đơn và cập nhật kho
1.4 Từ chối đơn hàng (nếu cần)

📚 Data Store

D1: Danh mục sản phẩm
D2: Đơn hàng

💬 External Entity vẫn là:

Khách hàng

📊 Luồng dữ liệu (một số ví dụ)

Từ	Đến	Tên luồng dữ liệu
Khách hàng	1.1	Đơn đặt hàng
1.1	1.2	Thông tin đơn hàng
1.2	D1	Truy vấn tồn kho
D1	1.2	Thông tin tồn kho
1.2	1.3	OK – Có đủ hàng
1.2	1.4	Không đủ hàng
1.3	D2	Lưu đơn hàng
1.3	Khách hàng	Xác nhận đơn
1.4	Khách hàng	Thông báo từ chối đơn

🧠 Giải thích logic xử lý

Tất cả đơn hàng đều được kiểm tra qua tồn kho.
Nếu hàng đủ: → Lưu vào D2, xác nhận đơn → cập nhật D1 (kho).
Nếu hàng thiếu: → Gửi thông báo từ chối đơn → không cập nhật kho.

🧾 Tóm lược cấu trúc sơ đồ

Thành phần	Tên
Process 1.1	Nhận đơn hàng
Process 1.2	Kiểm tra tồn kho
Process 1.3	Xác nhận đơn & cập nhật kho
Process 1.4	Từ chối đơn hàng
Data Store D1	Danh mục sản phẩm
Data Store D2	Danh sách đơn hàng
External	Khách hàng

✅ Lưu ý khi xây dựng DFD thực tế

Không nên dồn quá nhiều process vào 1 sơ đồ – hãy tách thành Level 2 nếu cần.
Mỗi process chỉ nên làm 1 việc rõ ràng.
Luồng dữ liệu cần mô tả tên đầy đủ, rõ nghĩa.

📌 Kết luận

Thông qua ví dụ hệ thống đặt hàng, ta thấy rằng:

Context Diagram cho cái nhìn tổng quát.
Level 1 DFD cho phép đi sâu vào logic xử lý.
Các thành phần (process, luồng, lưu trữ) luôn phải rõ ràng, đúng quy tắc.
DFD vừa dễ hiểu cho người dùng, vừa chi tiết cho nhà phát triển.

Các lỗi thường gặp khi vẽ sơ đồ DFD & cách khắc phục

Dù DFD là công cụ trực quan và dễ tiếp cận, nhưng trong thực tế và cả bài thi, rất nhiều người học mắc lỗi sai cơ bản làm mất điểm hoặc tạo ra sơ đồ sai logic. Việc nhận diện và khắc phục các lỗi này là bước quan trọng để nâng cao chất lượng phân tích hệ thống.

❌ 1. Kết nối sai giữa các thành phần

🔻 Lỗi:

Nối trực tiếp giữa hai Data Store.
Nối External Entity ↔ Data Store mà không qua Process.

✅ Cách khắc phục:

Luồng dữ liệu luôn phải đi qua Process.
- Ví dụ: Khách hàng → Đặt hàng → Cập nhật kho hàng
- Không được: Khách hàng → Danh mục sản phẩm

❌ 2. Không đặt tên hoặc đặt tên không rõ ràng cho luồng dữ liệu

🔻 Lỗi:

Mũi tên không có tên.
Dùng từ chung chung như “Dữ liệu”, “Thông tin”, “Tệp”.

✅ Cách khắc phục:

Mỗi luồng phải có tên mô tả chính xác dữ liệu đang truyền.
- Sai: → “Thông tin”
- Đúng: → “Thông tin đơn hàng đã xác nhận”

❌ 3. Process không có cả đầu vào và đầu ra

🔻 Lỗi:

Có Process mà không có mũi tên đi vào hoặc đi ra.
Hoặc tạo Process “tự sinh ra dữ liệu” không hợp lý.

✅ Cách khắc phục:

Mỗi Process phải có ít nhất một đầu vào và một đầu ra. Nếu không có – cần xem lại logic.

❌ 4. Không đánh số Process hoặc đánh số không phân cấp

🔻 Lỗi:

Tên Process chỉ là “Process A” hoặc “Bước 1” không có thứ tự rõ ràng.

✅ Cách khắc phục:

Dùng cách đánh số phân cấp:
- Level 1: 1.0, 2.0
- Level 2: 1.1, 1.2, 2.1…

🎯 Điều này giúp khi đọc sơ đồ, người khác biết mối quan hệ phân rã giữa các cấp DFD.

❌ 5. Không phân cấp rõ ràng giữa các cấp DFD

🔻 Lỗi:

DFD quá rối, đưa tất cả Process vào một sơ đồ duy nhất.
Không vẽ sơ đồ context (level 0), chỉ có Level 1.

✅ Cách khắc phục:

Bắt đầu với sơ đồ tổng thể (Context) → rồi phân rã thành Level 1, 2.
Mỗi cấp độ chỉ nên hiển thị số lượng process vừa đủ (3–7 process).

✅ Tiêu chí đánh giá một sơ đồ DFD đạt chuẩn

Nếu bạn đang chuẩn bị nộp bài thi hoặc xây dựng hệ thống, hãy tự kiểm tra sơ đồ DFD của mình theo bảng sau:

Tiêu chí	Mức độ quan trọng	Đã đạt? (✔/✘)
Có sơ đồ tổng quát (Context)	★★★★★
Mỗi luồng dữ liệu có tên rõ ràng	★★★★★
Không có kết nối sai logic	★★★★★
Mỗi Process có input & output	★★★★☆
Tên Process rõ ràng, có đánh số	★★★★☆
Phân cấp hợp lý giữa Level 0-1-2	★★★★☆
Số lượng Process phù hợp (≤7/lv)	★★★☆☆
Có ít nhất 1 Data Store	★★★☆☆

📌 Nếu bạn tự tick vào và đạt trên 80%, sơ đồ của bạn đã đạt chuẩn để nộp bài hoặc trình bày cho nhóm phát triển.

💬 Kết luận

Việc xây dựng DFD đúng không chỉ là vẽ sơ đồ đẹp – mà quan trọng là logic hệ thống phải rõ ràng, chính xác và dễ hiểu cho mọi đối tượng. Tránh những lỗi cơ bản kể trên sẽ giúp bạn thể hiện trình độ phân tích chuyên nghiệp, nhất là trong các môn học như Phân tích hệ thống thông tin hoặc khi làm việc với khách hàng trong thực tế.

Mô hình hóa Thực thể – Sự kiện (Entity/Event Modelling)

🎯 Mục tiêu của kỹ thuật

Trong phân tích hệ thống, ngoài luồng dữ liệu và cấu trúc dữ liệu, ta còn cần quan tâm đến cách hệ thống phản ứng với các sự kiện xảy ra trong môi trường hoạt động. Mô hình hóa thực thể – sự kiện (EEM – Entity/Event Modelling) được sử dụng để hiểu và mô tả mối quan hệ giữa các sự kiện và dữ liệu mà chúng tác động đến.

1. Khái niệm cơ bản

Thực thể (Entity): Là đối tượng dữ liệu chính trong hệ thống, ví dụ: Khách hàng, Đơn hàng, Sản phẩm.
Sự kiện (Event): Là một hành động hoặc tình huống xảy ra và ảnh hưởng đến hệ thống, ví dụ: Khách hàng đặt hàng, Thanh toán thành công, Đơn bị huỷ.
Tác động (Effect): Là những thay đổi mà sự kiện tạo ra đối với dữ liệu (tạo mới, cập nhật, xoá…).

📌 EEM trả lời cho câu hỏi: Dữ liệu nào bị thay đổi bởi sự kiện nào – và thay đổi ra sao?

2. Tại sao cần mô hình hóa thực thể – sự kiện?

Hệ thống là động, không chỉ xử lý dữ liệu tĩnh mà còn phải phản ứng với thay đổi trong thời gian thực.
Hiểu mối quan hệ này giúp ta:
- Lập quy trình xử lý sự kiện rõ ràng.
- Xây dựng hệ thống có khả năng theo dõi và ghi nhận lịch sử hành động.
- Tối ưu việc xử lý theo thời gian thực, đặc biệt với hệ thống như bán hàng, kho vận, tài chính…

3. Cách mô hình hóa thực thể – sự kiện

🔶 Bước 1: Xác định các thực thể chính

Dựa vào mô hình dữ liệu logic, ta xác định danh sách các thực thể cần theo dõi.
Ví dụ:

Khách hàng
Đơn hàng
Thanh toán

🔶 Bước 2: Liệt kê các sự kiện có thể xảy ra

Các sự kiện thường đến từ:

Người dùng (tạo đơn, cập nhật thông tin…)
Hệ thống (gửi thông báo, tự động xoá…)
Tác nhân bên ngoài (ngân hàng, đối tác…)

Ví dụ:

Đơn hàng được tạo
Đơn hàng bị huỷ
Đơn hàng được giao
Thanh toán không thành công

🔶 Bước 3: Xây dựng bảng thực thể – sự kiện

Sự kiện	Thực thể bị ảnh hưởng	Hành động trên thực thể
Đặt hàng	Đơn hàng, Sản phẩm	Tạo mới đơn, trừ tồn kho
Huỷ đơn hàng	Đơn hàng, Sản phẩm	Cập nhật trạng thái, hoàn tồn
Xác nhận thanh toán	Đơn hàng, Thanh toán	Cập nhật trạng thái thanh toán
Khách đăng ký tài khoản	Khách hàng	Tạo mới hồ sơ khách hàng

📌 Cột hành động nên mô tả rõ: Tạo mới, Cập nhật, Xoá, Liên kết dữ liệu…

4. Biểu diễn bằng sơ đồ (Event-Entity Matrix)

Ta có thể biểu diễn mối quan hệ bằng ma trận Sự kiện – Thực thể, với ký hiệu:

C: Create – tạo mới
R: Read – đọc/xem
U: Update – cập nhật
D: Delete – xoá

Ví dụ:

Thực thể ↓ / Sự kiện →	Đặt hàng	Huỷ đơn	Giao hàng	Thanh toán
Đơn hàng	C	U	U	U
Sản phẩm	R	U	U	R
Khách hàng	R			R
Thanh toán				C

5. Ưu điểm của kỹ thuật Entity/Event Modelling

Ưu điểm
✔ Hiểu rõ hệ thống phản ứng thế nào trước từng tình huống
✔ Làm cơ sở thiết kế hệ thống theo sự kiện (Event-driven architecture)
✔ Dễ dàng kiểm thử các luồng hoạt động và dự đoán lỗi
✔ Hỗ trợ thiết kế audit log, tracking và hệ thống cảnh báo

6. Ứng dụng trong thực tế

Dùng để xây dựng biểu mẫu Use Case, State Diagram, Activity Diagram.
Là nền tảng cho các hệ thống phản ứng thời gian thực, như: thương mại điện tử, hệ thống giao nhận, hệ thống CRM.
Giúp nhà phân tích xác định điểm đầu – điểm cuối của một quy trình một cách rõ ràng.

💡 Kết luận

Mô hình hóa thực thể – sự kiện là công cụ quan trọng để bổ sung khía cạnh “thời gian và hành vi” vào hệ thống thông tin, bên cạnh các mô hình tĩnh như DFD và mô hình dữ liệu logic. Đây là một kỹ thuật ít được chú ý nhưng lại cực kỳ hữu ích trong việc phát hiện ràng buộc nghiệp vụ và logic thay đổi trong thực tế.