Cs 09010

MÔN: PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG
Chương 1
Giới thiệu về
phân tích và thiết kế hệ thống
Trần Quang Môn: PTTKHT

Chương 1: Giới thiệu Slide 1
Khoa Công Nghệ Thông Tin
Nội dung
◼ Các khái niệm cơ bản về hệ thống thông tin
◼ Các thành phần cấu thành hệ thống thông tin
◼ Tổ chức quản lý trong công ty và việc ra quyết định
◼ Phân loại hệ thống thông tin
◼ Vai trò, vị trí, kỹ năng của phân tích viên
◼ Chu kỳ phát triển hệ thống (SDLC)
◼ Các kỹ thuật và công cụ phát triển hệ thống
◼ Các phương pháp luận phát triển hệ thống

Dữ liệu (Data)
◼ Dữ liệu là các con số, văn bản, ký hiệu, … có thể
lưu trữ, truyền nhận. Là nguyên liệu thô để phân
tích, xử lý tạo thành thông tin
◼ Phân loại dữ liệu:
◼ Có cấu trúc (Structured)
◼ Ví dụ: các table trong CSDL quan hệ.
◼ Phi cấu trúc (Unstructured data)
◼ Vi dụ: Hình ảnh, âm thanh, file văn bản, … Trên 80%
dữ liệu trong doanh nghiệp hiện là dữ liệu phi cấu trúc
◼ Bán cấu trúc (Semi-structured data)
◼ Ví dụ: XML database ...

Dữ liệu lớn (Big data)
◼ Big Data là các tập dữ liệu có khối lượng lớn và phức tạp,
mà các ứng dụng xử lý dữ liệu truyền thống không có khả
năng thu thập, và xử lý tốt. Các dữ liệu này có thể bao gồm
dữ liệu có cấu trúc, bán cấu trúc, và phi cấu trúc
◼ Đặc điểm của big data (4V)
◼ Volume (khối lượng)
◼ Petabyte (1PB=1024TB), Exabyte (1EB=1024PB)
◼ Variety (tính đa dạng)
◼ Dữ liệu thu thập từ nhiều nguồn khác nhau, các dạng và kiểu dữ
liệu có cấu trúc khác nhau.
◼ Velocity (vận tốc)
◼ Tốc độ các dữ liệu được tạo ra và xử lý
◼ Veracity (tính xác thực)
◼ Chất lượng của dữ liệu thu được ảnh hưởng đến sự phân tích
Các ví dụ về Big data
◼ Sàn chứng khoán New York sinh ra dữ liệu giao
dịch khoảng 1 terabyte mỗi ngày
◼ Các mạng xã hội như Facebook trung bình phải
lưu mỗi ngày hơn 500 terabytes dữ liệu mới, chủ
yếu là hình ảnh, video, bình luận, …
◼ Một hãng bay có thể sinh 10 terabytes mỗi 30 phút
về thông tin các chuyến bay. Mỗi ngày với hàng
ngàn chuyển bay, dữ liệu lên đến nhiều petabytes

Thông tin (Information)
◼ Thông tin (Information): là dữ liệu đã được xử lý, đặt
trong ngữ cảnh phù hợp, có ích cho người dùng
◼ Một số đặc trưng của thông tin:
◼ Tính chính xác (Accuracy)
◼ Tính đầy đủ (Completeness)
◼ Tính kịp thời (Timeless)
Data Information
Data Processing
Data store

Hệ thống (System)
◼ Là tập hợp các phần tử (components) tác động lẫn
nhau, phối hợp hoạt động (work together) để đạt
được các mục tiêu (objectives) xác định.
Environment
Boundary
Feedback
Input Sub system 1 Sub system 2 Output
Sub system 3
Sơ đồ tổng quát hệ thống

Hệ thống thông tin (Information System)
◼ Hệ thống thông tin là tập hợp các thiết bị phần
cứng, phần mềm, hệ thống truyền thông, được tổ
chức lại để xử lý dữ liệu và phân bố thông tin phục
vụ cho các mục tiêu của một đơn vị.
◼ Các thành phần cấu thành một HTTT gồm:
◼ Phần cứng (Hardware)
◼ Phần mềm (Software)
◼ Dữ liệu (Data)
◼ Quy trình xử lý (Processes)
◼ Con người (People)

Hệ thống thông tin (Information System)
◼ Phân tích và thiết kế HTTT là công việc được thực

hiện một cách có hệ thống nhằm xây dựng mới
hoặc phát triển HTTT đã có, sao cho việc sử dụng
các tài nguyên của HTTT một cách hiệu quả nhất

Stakeholders

System users
◼ Internal system users
◼ Clerical and service workers
◼ Technical and professional staff
◼ Supervisors, middle managers, executive managers
◼ External system users
◼ Customers
◼ Suppliers
◼ Partners
◼ Employees: sales representatives, …

Stakeholders

Tổ chức quản lý trong công ty
QL chiến lược Quản trị viên cấp cao

(strategical)
QL chiến thuật Quản trị viên cấp trung

(tactical)
QL tác nghiệp Quản trị viên cấp thấp

(Operational)
Thực hiện nghiệp vụ Nhân viên thừa hành
Mô hình tổ chức quản lý trong công ty

Các loại quyết định
◼ Ra quyết định là hành động nhằm thay đổi trạng
thái hiện tại để đạt tới một trạng thái mong muốn.
◼ Phân loại quyết định dựa vào 2 yếu tố:
◼ Tiêu chuẩn ra quyết định.
◼ Dữ liệu cần thu thập và quy trình xử lý.

Quyết định có cấu trúc:
◼ Khi cả 2 yếu tố trên đều rõ ràng
◼ Ví dụ: Xử lý đơn đặt hàng quy định rõ là dựa vào

trị giá đơn đặt hàng và hạn mức tín dụng của từng
khách hàng để chấp nhận hay không đơn đặt hàng
của khách.
◼ Loại quyết định này có thể lập trình trên máy tính
để hỗ trợ ở mức tự động hóa cao.

Quyết định phi cấu trúc:
◼ Khi cả 2 yếu tố đều không rõ
◼ Ví dụ: Quyết định khi bỏ phiếu bình chọn bàn

thắng đẹp nhất.
◼ Nhiều quyết định phi cấu trúc dựa vào cảm tính và
kinh nghiệm ứng xử của người ra quyết định, cũng
như tác động của môi trường xung quanh.

Quyết định bán cấu trúc:
◼ Khi 1 trong 2 yếu tố là không rõ ràng, như dữ liệu
không thể lượng hóa được, hoặc không có thủ tục
chặt chẽ, hoặc các tiêu chuẩn ra quyết định không
đầy đủ.
◼ Ví dụ: quyết định tung sản phẩm mới ra thị trường.
Để ra quyết định này giám đốc phải căn cứ vào lợi
nhuận ước tính, đồng thời cũng phải xem xét đến
mức độ rủi ro, số liệu về dự báo nhu cầu thị trường

Quản trị viên cấp cao
◼ Thường quan tâm đến tổng thể của công ty.
◼ Vạch ra các kế hoạch dài hạn, mang tính chiến
lược (strategic), các kế hoạch này ảnh hưởng đến
sự tồn tại và phát triển của công ty.
◼ Ví dụ: Xác định thị trường thâm nhập, cấu trúc vốn?
(bao nhiêu vốn vay, vốn cổ phần, …).
◼ Các quyết định thường là phi cấu trúc hoặc bán
cấu trúc.
◼ Dữ liệu đa số thu thập từ bên ngoài vuợt khỏi tầm
kiểm soát của công ty; như dữ liệu về dự báo thị
trường, đổi mới công nghệ, …
Quản trị viên cấp trung
◼ Thường vạch ra các kế hoạch trung hạn (vài tháng
đến một năm), mang tính chiến thuật (Tactical),
nhằm đạt các mục tiêu kinh doanh đã hoạch định
◼ Ví dụ: phân phối nguồn tài nguyên trong công ty
◼ Các quyết định của cấp này thường là bán cấu
trúc hoặc có cấu trúc.
◼ Dữ liệu thường thu thập từ bên trong hệ thống và
đôi khi cần một ít từ bên ngoài. Do thu thập từ bên
trong hệ thống và tương lai gần, nên các dữ liệu
chắc chắn và cụ thể hơn

Quản trị viên cấp thấp
◼ Liên quan các hoạt động hàng ngày của công ty.
Các quyết định mang tính tác nghiệp (operational)
nhằm sử dụng hiệu quả nguồn tài nguyên hiện có
để hoàn thành các mục tiêu đã đặt ra.
◼ Ví dụ: kiểm soát tồn kho, tín dụng, thuê xe, …
◼ Các quyết định của cấp này thường là có cấu trúc
◼ Dữ liệu hầu như có nguồn gốc từ bên trong công
ty. Đặc điểm dữ liệu thường chi tiết và chắc chắn

Nhân viên tác nghiệp, thừa hành
◼ Thực hiện các công việc được giao, như tiếp nhận
và và nhập số liệu vào hệ thống.
◼ Họ thường chỉ yêu cầu HTTT phải vận hành dễ
dàng, nhanh chóng và thật chính xác

Phân loại HTTT

Phân loại HTTT
ESS
GDSS
ES - DSS
MIS - KWS - OAS
TPS

Phân loại HTTT: TPS
1. Hệ thống xử lý giao dịch (Transaction Processing
System – TPS):
◼ Là hệ thống được xây dựng để xử lý các giao dịch,
các công việc hàng ngày
◼ Thường khối lượng dữ liệu xử lý lớn
◼ Tuân theo quy trình nghiệp vụ với độ chính xác và
an toàn cao
◼ Các hệ thống này thường yêu cầu mức độ chi tiết
cao và dễ vận hành
◼ VD: Hệ thống bán hàng ở các siêu thị, …

Phân loại HTTT: OAS - KWS
2. Hệ thống tự động hóa công việc văn phòng (OAS)
và hệ thống tri thức (KWS)
◼ OAS (Office Automatic System): hỗ trợ việc tự động
hóa các công việc văn phòng như: thư điện tử, lập
lịch, nhắc việc, …
◼ KWS (Knowledge Work System): giúp tạo ra và phát
triển những thông tin, kiến thức mới. Hệ thống quản
lý tri thức tổ chức lại các kiến thức này, giúp các
nhân viên có thể chia sẻ kiến thức bất cứ nơi nào và
khi nào.
◼ VD: hệ trợ giúp đào tạo công nhân, …

Phân loại HTTT: MIS
3. Hệ thống thông tin quản lý (Management
Information System – MIS)
◼ Cung cấp những công cụ hỗ trợ cho nhà quản lý lấy
được các thông tin, phục vụ cho nhu cầu ra quyết
định hàng ngày của họ.
◼ Các thông tin cung cấp cho nhà quản lý có thể thực
hiện: (1) theo định kỳ, (2) bất cứ lúc nào khi có yêu
cầu hoặc tình huống đặc biệt
◼ Hệ thống này không tồn tại độc lập mà thường bao
hàm cả hệ thống TPS, nó phân tích các dữ liệu từ
hệ thống TPS đưa lên
◼ VD: Hệ thống quản lý khách sạn, quản lý kho, …
Phân loại HTTT: DSS
4. Hệ hỗ trợ ra quyết định (Decision Support System)
◼ Sử dụng các mô hình ra quyết định và cơ sở dữ liệu
chuyên môn hóa để đưa ra các phương án khác nhau,
các mô hình phân tích, mô phỏng cho nhà quản lý.
◼ Nguồn dữ liệu lấy từ TPS và các nguồn dữ liệu khác
bên ngoài công ty
◼ Quyết định cuối cùng vẫn là con người
◼ Câu hỏi thường ở dạng WHAT – IF và nhận được câu
trả lời kiểu tương tác (khác với câu trả lới dạng quy
định trước trong hệ MIS)
◼ VD: Hệ thống dự báo kinh tế, chẩn đoán bệnh từ xa, …

Phân loại HTTT: ES/AI
5. Hệ chuyên gia (Expert System – ES) và
Trí tuệ nhân tạo (Artificial Intelligence - AI)
◼ ES: Thu thập và sử dụng các kiến thức của các
chuyên gia chuyên ngành (domain expert) để giải
quyết các vấn đề phức tạp trong thực tế.
◼ AI: Là một lĩnh vực của hệ chuyên gia. Mục đích là
phát triển một máy tính có trí thông minh như con
người, có khả năng phân tích suy diễn, …

Phân loại HTTT: GDSS
6. Hệ hỗ trợ ra quyết định nhóm (Group Decision
Support System – GDSS)
◼ Cho phép một nhóm các nhà quản lý có thể phối
hợp với nhau, cùng nhau làm việc để xây dựng

các quyết định mang tính chiến lược.

Phân loại HTTT: ESS / EIS
7. Hệ trợ giúp điều hành (Executive Support System)
◼ Còn gọi là hệ thống thông tin giám đốc (EIS). Mục
đích của HT cung cấp cho giám đốc khả năng truy
cập dễ dàng và tức thời thông tin có chọn lọc (tình
trạng hiện thời và xu hướng), có tính quyết định
đến việc hoàn thành mục tiêu chiến lược của công
ty.

Vấn đề tích hợp hệ thống
◼ Các HTTT trong đơn vị phải được phối hợp hoạt
động với nhau
◼ Lý tưởng là hệ thống được xây dựng theo cách
tiếp cận top-down → cần có CIO hoạch định chiến
lược xây dựng HTTT ngay từ đầu
◼ Một số HTTT được xây dựng theo tiếp cận bottom-
up → tạo thành các ốc đảo thông tin → nhiều công
nghệ mới đang được giới thiệu để giải quyết tình
trạng khá phổ biến này

Sự thành công của hệ thống
◼ Mục tiêu chính phải đạt được là hệ thống sau khi
xây dựng phải mang lại các lợi ích cho nơi sử
dụng nó.
◼ Sự thành công của hệ thống phụ thuộc vào:
◼ HT có thỏa mãn các yêu cầu của người dùng
◼ Sự nỗ lực của những nhà chuyên môn có kinh
nghiệm
◼ Phân tích viên hệ thống
◼ Lập trình viên
◼ Người quản lý dự án
◼ …

Nguyên nhân thất bại của hệ thống
◼ Trên thực tế, số lượng dự án xây dựng hệ thống
thông tin rất nhiều, nhưng tỉ lệ thất bại (chủ yếu là
lãnh vực phần mềm) thường rất cao
◼ Qua khảo sát, người ta thấy được một số nguyên
nhân chính gây ra thất bại:
◼ Hiểu không đúng yêu cầu của người dùng
◼ Không thể thích ứng khi yêu cầu thay đổi
◼ Khó bảo trì, nâng cấp, mở rộng
◼ Phát hiện trễ các lỗi
◼ Các thành viên không phối hợp tốt
◼ …
Một số vấn đề cần quan tâm
◼ Để tránh các thất bại nêu trên, khi phát triển hệ
thống cần chú ý một số vấn đề sau:
◼ Phát triển hệ thống theo một quy trình đã được
chọn lựa thích hợp (VD: RUP, Scrum, …)
◼ Quản lý tốt các yêu cầu của người dùng
◼ Mô hình hóa hệ thống đầy đủ, rõ ràng → ngoài
việc đảm bảo xây dựng hệ thống hiện tại, còn giúp
dễ nâng cấp mở rộng sau này
◼ Thiết lập hệ thống kiểm định chất lượng
◼ …

Phân tích viên hệ thống
◼ Phân tích viên hệ thống (System analyst) là người
chịu trách nhiệm chính trong việc phân tích các
nghiệp vụ, nhận ra các cơ hội để cải tiến, thiết kế
và cài đặt hệ thống thông tin (HTTT) đạt được mục
tiêu trên.
◼ Để xây dựng hệ thống thành công, PTV cần hiểu
rõ phương pháp luận, nắm vững kỹ thuật và thực
hiện một cách sáng tạo các bước trong quy trình
phát triển hệ thống.

Vị trí của phân tích viên
Có yêu cầu biết lập trình
Người Khoảng trống Lập trình

dùng giao tiếp viên
Có yêu cầu phân tích và thiết kế biết lập trình
Người yêu cầu

Phân tích Thiết kế Lập trình
dùng Tư vấn viên Phản hồi viên
Hình 2 Vị trí của PTV

Vai trò của phân tích viên
◼ Là một chuyên gia tư vấn (Consultant):
Tư vấn về phần cứng, phần mềm, chức năng, cơ sở kỹ
thuật,… Các tư vấn này phải phù hợp với các yêu cầu kỹ
thuật của HT sắp xây dựng.
◼ Là một chuyên gia trợ giúp (Support Expert):
Là người trung gian giữa khách hàng và lập trình viên, PTV
hệ thống phải giải đáp mọi thắc mắc từ cả 2 phía để có thể
chuyển những yêu cầu trong thế giới thực thành HTTT
hoàn chỉnh
◼ Là tác nhân thay đổi (Agent of Change)
PTV có khả năng tác động để thay đổi quy trình vận hành
nhằm đưa CNTT vào ứng dụng cho đơn vị
Kỹ năng của phân tích viên
◼ Kiến thức kỹ thuật vững chắc: Nắm bắt tốt công
nghệ mới để có thể đưa ra các giải pháp thích hợp
trong các tình huống khác nhau
◼ Kỹ năng giao tiếp tốt: phải giao tiếp với nhiều loại
người khác nhau ở trong và ngoài công ty.
◼ Khả năng nắm bắt tốt các hoạt động nghiệp vụ
◼ Kỹ năng phân tích vấn đề tốt: Phát hiện nhanh và
chính xác các vấn đề cần giải quyết, tiên lượng tốt
các tình huống.

Kỹ năng của phân tích viên
◼ Kỹ năng trình bày (nói và viết tốt): trình bày
(presentation), viết bản ghi nhớ (memo), báo cáo
(report), tài liệu (documentation)
◼ Kỹ năng lãnh đạo: lập kế hoạch, đánh giá, quản lý
dự án, hướng dẫn và đôn đốc các thành viên trong
nhóm
◼ …

Nhóm phân tích dự án
◼ Các vai trò trong nhóm phân tích dự án
◼ Quản lý dự án (Project manager)
◼ Phân tích viên nghiệp vụ (Business analyst)
◼ Phân tích viên hệ thống (System analyst)
◼ Phân tích viên về cơ sở hạ tầng (Infrastructure
analyst)
◼ Phân tích viên quản lý các thay đổi hệ thống
(Change management analyst)

Chu kỳ phát triển hệ thống

và các phương pháp luận

Chu kỳ phát triển hệ thống
◼ SDLC - System Development Life Cycle
◼ Tương tự như việc xây 1 căn nhà.
◼ Trước hết, căn nhà sẽ được phác họa bằng những ý
tưởng cơ bản ban đầu (→ khởi tạo)
◼ Các ý tưởng được chuyển thành bản vẽ, và được
chỉnh sửa nhiều lần cho đến khi chủ nhà đồng ý đã mô
tả đúng những gì họ muốn (→ phân tích)
◼ Các bản vẽ được chuyển thành các bản thiết kế chi
tiết trong xây dựng (→ thiết kế)
◼ Căn nhà được xây dựng theo bản thiết kế (→ thi công)
◼ Thông thường sẽ có các điều chỉnh trong hoặc sau khi
căn nhà đã hoàn thành (→ vận hành và bảo trì)
Chu kỳ phát triển hệ thống (SDLC)
◼ Xây dựng hệ thống thông tin sẽ trải qua nhiều giai
đoạn (phase)
◼ Mỗi giai đoạn thường sẽ bao gồm nhiều bước thực
hiện (step)
◼ Mỗi bước sẽ sử dụng các kỹ thuật (technique)
khác nhau và tạo ra kết quả cụ thể của bước đó
(các bảng thiết kế, tài liệu, chương trình, …)

Các giai đoạn của SDLC
◼ Lập kế hoạch (Planning)
◼ Tại sao phải xây dựng hệ thống? (Why)
◼ Phân tích (Analysis)
◼ Hệ thống cần phải làm những gì? (What). Và các câu
hỏi Who, When, Where liên quan?
◼ Thiết kế (Design)
◼ Làm thế nào để hệ thống hoạt động? (How)
◼ Thi công (Implementation)
◼ Lập trình, thử nghiệm
◼ Vận hành và hỗ trợ (Operation and support)
◼ Đưa hệ thống vào vận hành
Các giai đoạn và sản phẩm của SDLC

Giai đoạn lập kế hoạch (Planning)
Tại sao phải xây dựng hệ thống? (Why)
Bước Kỹ thuật Kết quả
Xác lập mục tiêu, Xác định yêu cầu hệ thống Bảng yêu cầu hệ thống(System Request)
lợi ích của dự án
Phân tích khả thi Nghiên cứu tính khả thi về Báo cáo nghiên cứu khả thi (Feasibility
mặt: kỹ thuật, kinh tế và tổ Study)
chức
Xây dựng kế Xác định các công việc Bảng kế hoạch làm việc (Work Plan)
hoạch làm việc Ước lượng thời gian
Bố trí nhân sự Xây dựng kế hoạch về nhân Bảng kế hoạch nhân sự (Staffing Plan)
sự và các quy định của dự án Bảng quy định của dự án (Project Charter)
Điều khiển và chỉ Điều chỉnh ước tính ban đầu Biểu đồ GANTT,
đạo dự án Theo dõi các công việc Biểu đồ PERT/CPM
Điều phối dự án CASE tools
Quản lý phạm vi dự án Bảng đánh giá rủi ro
Giảm bớt rủi ro

Giai đoạn phân tích (Analysis)
Trả lời các câu hỏi What, Who, When, Where liên quan đến hệ thống?
Xác định chiến lược Phân tích các yêu cầu đã đặt ra Kế hoạch phân tích
phân tích
Thu thập thông tin Phỏng vấn, bảng câu hỏi, … Tất cả các thông tin liên
quan đến hệ thống
Mô hình hóa các Use case model Mô hình chức năng
yêu cầu chức năng (Function Hierarchy Diagram)
Mô hình hóa cấu Class diagram, Object diagram Mô hình cấu trúc
trúc (tĩnh) (Entity Relationship Diagram) Mô hình dữ liệu
Mô hình hóa hành Sequence diagram, Mô hình xử lý
vi (động) Collaboration diagram,
Statechart diagram
(Data Flow Diagram)

Giai đoạn thiết kế (Design)
Làm thế nào để hệ thống hoạt động? (How)

Chọn lựa chiến Xác định cách phát triển hệ Chiến lược thiết kế
lược thiết kế thống (mua, tự xây dựng, …)
Thiết kế kiến trúc Thiết kế phần cứng, mạng, Tài liệu thiết kế kiến trúc hạ
kiến trúc ứng dụng tầng của hệ thống
Thiết kế giao diện Thiết kế input Tài liệu thiết kế giao diện
Thiết kế output
Thiết kế cơ sở dữ Thiết kế CSDL, chọn lựa hệ Tài liệu thiết kế CSDL
liệu quản trị CSDL, tối ưu hóa, …
Thiết kế chương Program structure chart Tài liệu đặc tả các chương
trình Program specifications trình sẽ được viết

Giai đoạn thi công (Implementation)
Hiện thực hệ thống

Xây dựng Lập trình, Chương trình,
Kiểm tra thử nghiệm Kế hoạch thử nghiệm,
Tài liệu sử dụng,
Tài liệu kỹ thuật

Giai đoạn vận hành-hỗ trợ (operation-support)
Đưa hệ thống vào vận hành
Cài đặt Chọn lựa cách đưa hệ thống Kế hoạch chuyển đổi
vào vận hành Kế hoạch huấn luyện
Hỗ trợ Chiến lược hỗ trợ sau khi cài Kế hoạch hỗ trợ

đặt và vận hành hệ thống

Phương pháp tiếp cận phát triển hệ thống
◼ Có rất nhiều cách tiếp cận
◼ Mỗi phương pháp được xem xét dưới 2 khía cạnh
sau:
◼ Các bước thực hiện và sự tiếp nối của các bước
này trong quá trình phát triển
◼ Các công cụ để mô hình hệ thống

Một số phương pháp luận
◼ Các phương pháp hệ thống:
◼ MERISE (H.Tardieu, A.Rochfeld 1976)
◼ Các phương pháp chức năng hay có cấu trúc:
◼ SADT (douglas T.Ross, 1977)
◼ Phương pháp hướng sự kiện
◼ State Charts (D.Harel, 1987)
◼ Các phương pháp hướng dữ liệu:
◼ LCP, LCS (J.D.Warnier, 1969)
◼ Các phương pháp hướng đối tượng:
◼ OOAD (G.Booch, 1992-1993)
◼ UML + RUP + Rational Rose (G.Booch, J.Rumbaugh,
I.Jacobson, 1997)
Một số kỹ thuật phát triển
◼ JAD (Joint Application Development): Kỹ thuật xây
dựng nhóm cộng tác trong phát triển ứng dụng, bao
gồm nhiều thành viên thuộc nhiều lĩnh vực và cấp độ
quản lý
◼ RAD (Rapid Application Development): Kỹ thuật phát
triển nhanh ứng dụng
◼ Nổi lên từ những năm 1990s
◼ Nhờ sự xuất hiện các công cụ hỗ trợ (CASE tools)
◼ Các ngôn ngữ lập trình trực quan (visual) ngày càng
mạnh mẽ

CASE tools
◼ CASE – Computer- Aided System Engineering
◼ Là các công cụ hỗ trợ cho việc phát triển hệ thống
ở nhiều mức độ khác nhau
◼ Upper CASE tools: hỗ trợ việc mô hình hóa hệ
thống và tạo ra thiết kế luận lý cho hệ thống
◼ Lower Case Tool: giúp sinh mã nguồn chương trình
(code generator) từ các mô hình luận lý → đẩy
nhanh tốc độ phát triển hệ thống
◼ Tất cả các thiết kế được lưu trữ trong một kho gọi
là CASE repository

CASE tools
Business Analysis, Physical Implementation

modeling logical design design
Upper CASE Lower CASE
REPOSITORY
Diagram Metadata
Form Procedure
Report logic
Integrated CASE
Mô hình thác nước (waterfall model)
Ưu và nhược
điểm của mô hình
này?

Mô hình chữ V (V-Shaped model)
System
Requirement Acceptance Test
High level design System Test
Detailed design Unit Test
Construction

Mô hình phát triển song song
(Parallel Development)

Prototype
◼ Trong mô hình này người ta phát triển thành nhiều
phiên bản (version) gọi là các bản mẫu (prototype)
◼ Mỗi phiên bản sẽ tập trung giải quyết một số yêu
cầu của người dùng, và các vấn đề phát sinh trong
phiên bản trước
◼ Các nghiên cứu cho thấy thời gian có thể rút
xuống còn 45% so với mô hình thác nước.
◼ Đặc biệt thích hợp với các hệ thống mà quy trình
nghiệp vụ chưa thật ổn định

Prototype

Prototype
◼ Một prototype phải có các đặc điểm:
◼ Làm việc được trên các dữ liệu thực
◼ Có thể phát triển thêm để tiến tới HT cuối cùng
◼ Tạo lập nhanh và ít tốn kém
◼ Dùng để kiểm chứng các giả định về các nhu cầu
phải đáp ứng, các lược đồ thiết kế và logic của
chương trình
◼ Lợi ích của prototype:
◼ Chính xác hóa các nhu cầu phải đáp ứng
◼ Phát hiện các sai sót trong logic chương trình
◼ Đánh giá được hiệu năng của hệ thống
Throwaway Prototype

Mô hình tăng trưởng (Incremental model)
◼ Phiên bản đầu tiên sẽ phát triển phần lõi và nhóm
các chức năng quan trọng
◼ Sau khi mỗi phiên bản được đưa vào sử dụng, các
kết quả đánh giá sẽ được phản hồi và sử dụng để
lập kế hoạch cho chu trình con của phiên bản tiếp
theo
◼ Trong các phiên bản tiếp theo, các chức năng của
hệ thống sẽ lần lượt được bổ sung dần vào

Mô hình xoắn ốc (Spiral model)

Mô hình RUP (Rational Unified Process)

Agile - Scrum

Tuyên ngôn của Agile
◼ Cá nhân và sự tương hỗ quan trọng hơn quy trình
và công cụ
◼ Sản phẩm sử dụng được quan trọng hơn tài liệu
về sản phẩm
◼ Cộng tác với khách hàng quan trọng hơn đàm
phán hợp đồng
◼ Phản hồi với sự thay đổi quan trọng hơn bám theo
kế hoạch
Tuyên ngôn cũng nói rằng mặc dù những mục bên
phải vẫn có giá trị nhưng Agile đánh giá cao các mục
bên trái hơn
12 nguyên tắc
1. Thỏa mãn yêu cầu của khách hàng thông qua việc
giao hàng sớm và liên tục
2. Chào đón việc thay đổi yêu cầu, thậm chí là những
thay đổi yêu cầu muộn
3. Giao phần mềm chạy được cho khách hàng một cách
thường xuyên (giao hàng tuần hơn là hàng tháng)
4. Nhà kinh doanh và kỹ sư lập trình phải làm việc cùng
nhau hàng ngày trong suốt dự án
5. 5. Các dự án được xây dựng xung quanh những cá
nhân có động lực. Cung cấp cho họ môi trường và sự
hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công
việc
12 nguyên tắc
6. Trao đổi trực tiếp mặt đối mặt là phương pháp hiệu
quả nhất để truyền đạt thông tin
7. Phần mềm chạy được là thước đo chính của tiến độ
8. Phát triển bền vững và duy trì được nhịp độ phát
triển liên tục
9. Liên tục quan tâm đến kỹ thuật và thiết kế để cải tiến
sự linh hoạt
10. Sự đơn giản là cần thiết – nghệ thuật tối đa hóa
lượng công việc chưa hoàn thành
11. Nhóm tự tổ chức
12. Thích ứng thường xuyên với sự thay đổi

Các phương pháp agile

Scrum Process

Scrum Team

Ba vai trò
1. Product Owner (chủ sản phẩm):
◼ Là người chịu trách nhiệm về sự thành công của dự
án, người định nghĩa các yêu cầu và đánh giá cuối
cùng đầu ra của các nhà phát triển phần mềm.
2. Scrum Master:
◼ Là người có hiểu biết sâu sắc về Scrum và đảm bảo
nhóm có thể làm việc hiệu quả với Scrum.
3. Dev. Team (Đội phát triển):
◼ Một nhóm liên chức năng (cross-functional) tự quản
lý để tiến hành chuyển đổi Product Backlog item
thành chức năng của hệ thống.

Bốn cuộc họp
1. Sprint Planning (Họp Kế hoạch Sprint)
◼ Scrum sử dụng cách thức lập kế hoạch từng phần
và tăng dần theo thời gian. Việc lập kế hoạch không
diễn ra duy nhất một lần trong vòng đời dự án mà
được lặp đi lặp lại, thích nghi với các tình hình thực
tiễn trong tiến trình đi đến sản phẩm.
2. Daily Scrum (họp Scrum hằng ngày):
◼ Scrum Master tổ chức cho Đội sản xuất họp hằng
ngày trong khoảng 15 phút để nhóm phát triển chia
sẻ tiến độ công việc cũng như chia sẻ các khó khăn
gặp phải trong quá trình phát triển phần mềm suốt
một Sprint.
Bốn cuộc họp
3. Sprint Review (họp sơ kết Sprint):
◼ Cuối Sprint, nhóm phát triển cùng với Product
Owner sẽ rà soát lại các công việc đã hoàn tất
(DONE) trong Sprint vừa qua và đề xuất các chỉnh
sửa hoặc thay đổi cần thiết cho sản phẩm.
4. Sprint Retrospective (họp cải tiến Sprint):
◼ Dưới sự trợ giúp của Scrum Master, nhóm phát
triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và
tìm cách cải tiến quy trình làm việc cũng như bản
thân sản phẩm.

SCRUM
Attendees
Meeting Time Allocation Frequency Product Dev Scrum
owner Team master
Realease
As needed As needed X
Planning
Product backlog Max: 10% of th During the Sprint as
X X X
refinement Capacity of Dev Team needed
Spring Planning Max: 2 hours (2-week At the beginning of the
X X X
Topic I (What) Sprint) Sprint
Spring Planning Max: 2 hours (2-week At the beginning of the
X
Topic II (How) Sprint) Sprint
Daily Scrum During the Sprint as
Max: 15 minutes X
(Stand-up) needed
Spring Review
Max: 2 hours (2-week
(should be with At the end of the Sprint X X X
Sprint)
stakeholders)
Sprint Max: 15 hours (2- At the end of the Sprint
X X X
Retrospective week Sprint) & after major events

Các công cụ (artifacts) Scrum
1. Product backlog:
◼ Là danh sách ưu tiên các tính năng (feature), có
thể hiểu như là danh sách yêu cầu (requirement)
của dự án. Product Owner chịu trách nhiệm sắp
xếp độ ưu tiên cho từng hạng mục (Product
Backlog Item) trong Product Backlog dựa trên các
giá trị do Product Owner định nghĩa (thường là giá
trị thương mại).

2. Sprint backlog:
Đây là bản kế hoạch cho một Sprint; là kết quả của
buổi họp lập kế hoạch (Sprint Planning). Với sự kết
hợp của Product Owner, nhóm sẽ phân tích các
yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện
thực hóa các hạng mục trong Product Backlog
dưới dạng danh sách công việc (TO DO list)


Task

Chọn lựa cách tiếp cận thích hợp

Chương 2
Lập kế hoạch và
quản trị dự án CNTT

Chương 2: Lập kế hoạch và quản lý dự án Slide 1
Nội dung
◼ Tầm quan trọng của việc lập kế hoạch
◼ Đánh giá các yêu cầu hệ thống
◼ Khởi tạo và Xác định tầm vực hệ thống
◼ Nghiên cứu sơ bộ
◼ Phân tích tính khả thi của dự án
◼ Xây dựng kế hoạch làm việc
◼ Ước lượng nguồn lực: thời gian, chi phí, …
◼ Một số công cụ quản trị dự án: sơ đồ WBS,
GANTT, PERT/CPM, …

Hoạch định chiến lược
Các bước trong việc hoạch định chiến lược

Hoạch định chiến lưọc
◼ Phát biểu sứ mạng (mission statement)
◼ Các mục tiêu của công ty
◼ Các sản phẩm, dịch vụ, …
◼ Hướng phát triển của công ty
◼ Người có quyền lợi liên quan (stakeholder)
◼ Khách hàng
◼ Nhà cung cấp
◼ Nhân viên
◼ Cổ đông, …

Phân tích SWOT
◼ Điểm mạnh (Strength)
◼ Tận dụng như thế nào?
◼ Điểm yếu (Weakness)
◼ Khắc phục chúng như thế nào?
◼ Cơ hội (Opportunity)
◼ Làm thế nào đạt được chúng?
◼ Mối đe dọa (Threat)
◼ Giải quyết chúng như thế nào?

Phân tích SWOT
◼ Từ phân tích SWOT sẽ hình thành các chiến lược:
◼ Tận dụng thế mạnh và cơ hội để che các điểm yếu
◼ Khắc phục trước các yếu điểm, rồi mới sử dụng cơ
hội, ...
◼ Sự thành công, cũng là mục đích cuối cùng của việc
xây dựng HTTT là làm gia tăng lợi ích (lợi nhuận)
cho đơn vị.
◼ Vì vậy, hoạch định chiến lược trong việc xây dựng
HTTT trong đơn vị phải luôn luôn gắn chặt với chiến
lược phát triển chung của toàn đơn vị.

Các yếu tố ảnh hưởng đến dự án CNTT

Khởi tạo dự án (Project Initiation)
◼ Dự án được hình thành khi một người nào đó thấy
được cơ hội tạo ra các lợi ích cho đơn vị từ việc
ứng dụng công nghệ thông tin
◼ Người bảo trợ dự án (project sponsor) là nhân vật
chủ chốt trong việc đề xuất hoặc chấp nhận giải
pháp mới trong ứng dụng CNTT
◼ Hội đồng xét duyệt (approval committee) sẽ xem
xét từ nhiều góc độ để quyết định chấp thuận
những việc cần xây dựng, phát triển

Yêu cầu hệ thống (system request)
◼ Dự án sẽ được khởi tạo bằng một yêu cầu hệ
thống chính thức
◼ Yêu cầu hệ thống đưa ra có thể nhằm:
◼ Mở rộng hệ thống hiện tại
◼ Sửa chữa các lỗi của hệ thống hiện tại
◼ Xây dựng hệ thống mới
→ Cần xác định rõ ràng mục tiêu của dự án

Mẫu phiếu yêu cầu hệ thống
◼ Mẫu phiếu sử dụng cần đạt các yêu cầu:
◼ Tổ chức tốt
◼ Đảm bảo tính nhất quán
◼ Dễ hiểu, dễ sử dụng
◼ Có chỉ dẫn rõ ràng
◼ Trên phiếu thuờng gồm các thông tin sau:
◼ Tên dự án (Project name)
◼ Người tài trợ dự án (Project sponsor)
◼ Sự cần thiết (Business need)
◼ Chức năng (Functionality)
◼ Kết quả mong đợi (Expected value)
◼ Các ràng buộc (Constraints), …
Mẫu phiếu yêu cầu hệ thống
[Date]
SYSTEM REQUEST
Project Name:
Project Sponsor:
Name:
Department:
Phone: Email:
Business Need:
Functionality:
Expected Value:
Tangible:
Intangible:
Special Issues or Constraints:

Các lý do của yêu cầu hệ thống

Các lý do của yêu cầu hệ thống
1. Cải tiến dịch vụ
◼ Để phục vụ tốt hơn cho khách hàng và người sử dụng
2. Hiệu quả tốt hơn

◼ Truy xuất dữ liệu nhanh hơn, đáp ứng theo sự phát triển
của đơn vị, cần cấu hình phần cứng mạnh hơn
3. Giảm chi phí
◼ Chi phí vận hành và bảo trì
4. Thông tin nhiều hơn

◼ Cung cấp đầy đủ thông tin, hỗ trợ việc thay đổi yêu cầu
5. Kiểm soát tốt hơn

◼ Đảm bảo dữ liệu được chính xác và an toàn, mã hóa dữ
liệu, quyền truy cập của người dùng

Các bước nghiên cứu sơ bộ
◼ Mục đích:
Quyết định có nên tiếp tục dự án hay không ?
◼ Các bước nghiên cứu sơ bộ:
1. Hiểu rõ vấn đề
2. Xác định phạm vi dự án và các ràng buộc
3. Tìm hiểu thực tế (fact-finding)
4. Xác định tính khả thi của dự án
5. Ước tính thời gian và chi phí
6. Báo cáo với ban quản lý

Bước 1: Hiểu rõ vấn đề
◼ Xác định đúng bản chất của vấn đề và lý do của các
yêu cầu hệ thống
◼ Xác định vấn đề đã nêu có phải là vấn đề có thật
hay không
◼ Xác định rõ phạm vi khảo sát

Bước 2: Xác định phạm vi và các ràng buộc
◼ Phạm vi dự án (project scope)
◼ Xác định ranh giới và mức độ cho phép mở rộng

◼ Lưu ý hiện tượng dự án bị nới rộng dần (project creep)
◼ Các ràng buộc (constraint)
◼ Là các điều kiện mà hệ thống phải thỏa mãn, hoặc các
kết quả mà hệ thống phải đạt được
◼ Phân biệt giữa các loại ràng buộc:
◼ Hiện tại (present) và tương lai (future)
◼ Bên trong (internal) và bên ngoài (external)
◼ Bắt buộc (mandatory) và mong muốn (desire)

Bước 3: Tìm hiểu thực tế (fact-finding)
◼ Phân tích sơ đồ tổ chức (organization chart)
◼ Phỏng vấn
◼ Quan sát
◼ Thăm dò ý kiến người dùng
Bước 4: Xác định tính khả thi
◼ Khả thi về kỹ thuật, kinh tế và vận hành

Bước 5: Ước tính thời gian và chi phí
◼ Xác định các thông tin cần thu thập? nguồn của
các thông tin này? các khó khăn để thu thập và
phân tích các thông tin?
◼ Có cần phỏng vấn? số người phỏng vấn? mất thời
gian bao lâu? Ai thực hiện phỏng vấn và mất thời

gian bao lâu?
◼ Chi phí để phân tích các thông tin và báo cáo cho
ban quản lý
◼ Xác định chi phí và thời gian cho giai đoạn kế tiếp
◼ Xác định chi phí cho toàn dự án

Bước 6: Báo cáo cho ban quản lý
◼ Công việc cuối cùng là lập báo cáo gởi cho ban
quản lý
◼ Báo cáo cần trình bày
◼ Đánh giá về yêu cầu hệ thống
◼ Ước lượng chi phí và lợi ích
◼ Các đề nghị
◼ Ngoài báo cáo viết, PTV có thể còn được yêu cầu
có một buổi trình bày cho ban quản lý

Nghiên cứu khả thi (Feasibility Study)
◼ Được thực hiện nhằm hỗ trợ cho việc quyết định
có nên hình thành dự án này hay không ?
◼ Mục đích là nhận diện càng sớm càng tốt các dự
án không khả thi → giảm thiệt hại do thực hiện dự
án rồi phải hủy bỏ
◼ Tính khả thi có thể thay đổi theo thời gian:
◼ Các dự án không khả thi có thể được đề xuất lại.
Các dự án khả thi có thể bị hủy bỏ trong các giai
đoạn sau này

Phân tích tính khả thi
◼ Thường sẽ được phân tích dưới các góc độ:
◼ Khả thi về kỹ thuật (Technical feasibility)
◼ Khả thi về kinh tế (Economic feasibility)
◼ Khả thi về vận hành (Operational feasibility)
◼ Khả thi về lịch trình (Schedule feasibility)
◼ …

Khả thi về kỹ thuật
Nhằm trả lời câu hỏi : “Có thể làm được không?”
Tính khả thi kỹ thuật phụ thuộc vào:
◼ Ý kiến của đội ngũ kỹ thuật : sự quen thuộc đối với
ứng dụng, sự hiểu biết về lĩnh vực hoạt động
◼ Sự quen thuộc về kỹ thuật: mở rộng công nghệ
đang dùng, có sẵn thiết bị cần thiết
◼ Độ tin cậy của phần cứng và phần mềm
◼ Hiệu suất thích hợp với yêu cầu
◼ Khả năng đáp ứng yêu cầu phát triển của tương lai
◼ Độ lớn của dự án: số người tham gia, thời gian và
các đặc thù của hệ thống

Khả thi về kinh tế
Nhằm trả lời câu hỏi: “Có nên làm hay không?”
◼ Xem xét các lợi ích dự kiến mang lại so với chi phí
ước lượng sẽ phải bỏ ra cho việc phát triển, cài
đặt và vận hành hệ thống
◼ So sánh tỉ số Costs/ Benefits giữa các giải pháp
khác nhau
◼ Tính toán ROI (Return On Investment), NPV (Net
Present Value), …

Khả thi về kinh tế
◼ Cần lưu ý khi xem xét tính khả thi về kinh tế:
◼ Chi phí: chi phí một lần và chi phí duy trì
◼ Chi phí phát triển (phần cứng, phần mềm, bản quyền,
lương, …)
◼ Chi phí vận hành hàng năm
◼ Lợi ích:
◼ Lợi ích hữu hình (tangible cost)
◼ Lợi ích vô hình (intangible cost)
◼ Tính toán chi phí và lợi ích theo thời gian
◼ So sánh với chi phí nếu không xây dựng hệ thống

Phân tích chi phí và lợi ích
Chi phí Lợi ích
Hữu hình * *
* *
* *
Vô hình * *
* *
* *

Phân tích chi phí và lợi ích theo thời gian

Khả thi về vận hành
Nhằm trả lời câu hỏi: “Khi dự án được xây dựng
xong ? Có đưa vào vận hành được không?”
◼ Cần phân tích những người có ảnh hưởng đến dự
án (stakeholder) như các nhà quản lý, người dùng,

bộ phận máy tính, các tổ chức có liên quan, …
◼ Xem xét sự ủng hộ và phản đối của người dùng
◼ Nhân lực triển khai
◼ Sự ảnh hưởng đến hiệu suất, khách hàng và hoạt
động của công ty

◼ Lịch trình triển khai có hợp lý không?

FIG (Feasibility Impact Grid)
◼ Dùng để đánh giá sự ảnh hưởng của các yếu tố cải
tiến đối với hệ thống hiện tại → có cái nhìn tổng thể
việc cải tiến ảnh hưởng đến các mục tiêu của công
ty như thế nào
Mục tiêu 1 Mục tiêu 2 Mục tiêu 3 Mục tiêu 4
Bộ phận 1 * *
Hệ thống 1 Bộ phận 2 * * *
Bộ phận 3 * * -
Bộ phận 1 - -
Hệ thống 2 Bộ phận 2 * * *
Bộ phận 3 * -

Introdution
System Request
Summary
PRELIMINARY INVESTIGATION REPORT

Findings
Proposal to Upgrade
Online Order Tracking System
Information Technology Department

December 17, 2005 Recommend-
ations
Time and Cost

Estimates
Expected Benifits
Appendix

Đánh giá yêu cầu hệ thống
◼ Được thực hiện bởi hội đồng xét duyệt hệ thống
(systems review committee)
◼ Hội đồng sẽ:
◼ Xem xét từng yêu cầu hệ thống
◼ Thiết lập độ ưu tiên từng yêu cầu
◼ Đánh giá tính khả thi

Đánh giá yêu cầu hệ thống
◼ Tiêu chí để đánh giá thường dựa vào:
◼ Có làm giảm chi phí hoạt động ?
◼ Có làm tăng lợi ích cho đơn vị ?
◼ Tạo ra nhiều thông tin hơn ?
◼ Phục vụ khách hàng tốt hơn ?
◼ Thời gian hợp lý ?
◼ Kết quả lâu dài ?
◼ Sử dụng tài nguyên có sẵn ?
◼ Có bắt buộc phải thực hiện ?
◼ Các yếu tố hữu hình và vô hình ?
Quản trị dự án
◼ Quản trị dự án (Project management) là quá trình
lập kế hoạch và kiểm soát việc phát triển hệ thống
trong phạm vi thời gian cho phép, với chi phí thấp
nhất và đạt được các chức năng phù hợp
◼ Người quản trị dự án (project manager) là người
chịu trách nhiệm chính trong việc quản lý tất cả
các công việc và vai trò trong dự án, phối hợp một
cách hợp lý các nguồn lực này

Lập kế hoạch thực hiện
◼ Bao gồm các công việc sau:
◼ Xác định các công việc
◼ Ước lượng thời gian cho từng công việc
◼ Phân công nhân sự cho từng công việc
◼ Lên lịch thực hiện
◼ Xác định các điểm mốc
◼ Lập kế hoạch kiểm tra và điều khiển

Nhận diện các công việc
◼ Tiếp cận từ trên xuống(top-down)
◼ Nhận diện các công việc ở mức cao nhất (highest
level tasks)
◼ Chia nhỏ các công việc này thành các công việc
nhỏ hơn
◼ Phương pháp
◼ Sử dụng các danh mục chuẩn cho các công việc
◼ Xây dựng sơ đồ WBS

Sơ đồ cấu trúc phân việc
◼ WBS – Work Breakdown Structure
◼ Đây là sơ đồ quan trọng nhất và là cơ sở cho tất
cả các bước lập kế hoạch và giám sát khác
Dự án
A B C
A1 A2 A3 ,,,

Sơ đồ cấu trúc phân việc
Ví dụ:
◼ Giai đoạn phân tích hệ thống sẽ được chia thành
các công việc nhỏ hơn gồm: thu thập thông tin, xây
dựng sơ đồ dòng dữ liệu, chuẩn bị hồ sơ, …
◼ Việc thu thập thông tin lại được phân chia thành
các công việc: thực hiện phỏng vấn, lập bảng câu
hỏi (questionare), đọc các báo cáo của công ty,
giới thiệu prototype, xem xét phản hồi của đối tác
về prototye, …

Lập kế hoạch cho từng công việc
Work Plan Information Example
Name of task Perform economic feasibility

Start date ` Jan 05, 2001
Completion date Jan 19, 2001
Person assigned Mary Smith, sponsor
Deliverable(s) Cost-benefit analysis
Completion status Open
Priority High
Resources needed Spreadsheet
Estimated time 16 hours
Actual time 14.5 hours

Ước lượng dự án
◼ Dựa trên các thông tin của chuẩn công nghiệp
Planning Analysis Design Implementation
Industry
Standard
For Web 15% 20% 35% 30%
Applications
Time
Required 4 5.33 9.33 8
in Person
Months

Ước lượng về thời gian (Time Estimation)

Ước lượng thời gian
◼ Kích thước (Size)
◼ Số điểm chức năng (Function Points)
◼ Số dòng lệnh (Lines of Code)
◼ Công sức (Effort)
◼ Nhân sự / tháng (Person-months)
◼ Thời gian (Time)
◼ Số tháng (Months)

Ước lượng thời gian
◼ Mỗi công việc chi tiết sẽ được ước lượng thời gian
hoàn thành
◼ Gọi thời gian hoàn thành công việc là:
• B : trong trường hợp tốt nhất
• P : trong trường hợp thông thường
• W: trong trường hợp xấu nhất
◼ Thời gian ước lượng hoàn thành công việc được

tính bằng công thức:
(B + 4P + W) / 6

Sơ đồ GANTT
◼ Trục hoành: biểu diễn thời gian
◼ Trục tung: biểu diễn công việc.
◼ Mỗi công việc được biểu diễn bằng một thanh trên
đồ thị, chiều dài của thanh ứng với thời gian hoàn
thành công việc
◼ Ưu điểm: Đơn giản, dễ hiểu. Được sử dụng rộng
rãi trong hầu hết các dự án
◼ Nhược điểm: Chưa cho thấy rõ ràng mối quan hệ
giữa các công việc

Sơ đồ GANTT

Sơ đồ PERT
◼ Program Evalution and Review Technique
◼ Nút (node): Thời điểm bắt đầu hoặc kết thúc của
công việc được biểu diễn bằng một nút (gọi là sự
kiện). Mỗi nút có số hiệu duy nhất.
◼ Trong sơ đồ có một nút bắt đầu (Initial node)
và một nút kết thúc (terminal node)
◼ Công việc (Job): Mỗi công việc được biểu diễn
bằng một mũi tên. Phía trên mũi tên có một con số
biểu diễn thời gian hoàn thành công việc

Sơ đồ PERT
Sơ đồ GANTT
2
A, 4 C, 5
E, 6
1 4 5
D, 3
B, 2
3 Sơ đồ PERT

Sơ đồ PERT
◼ Đường dummy: Biểu diễn bằng mũi tên không liền
nét. Thời gian hoàn thành của đường dummy là 0.
◼ Được đưa vào để thuận tiện trong việc biểu diễn
logic của các công việc trong sơ đồ
2 2
Dummy
A, 4 A, 4
Dummy
1 4 1 4
C, 3 C, 3
B, 2 B, 2
3 3

Sơ đồ PERT
◼ ECT (Earliest Completion Time)
◼ Thời gian hoàn thành sớm nhất. Đây là thời gian cần
thiết tối thiểu để hoàn thành tất cả các công việc trước
của node này.
◼ LCT (Lastest Completion Time)
◼ Thời gian hoàn thành trễ nhất. Là thời gian tối đa được
phép để đạt đến node này mà không làm trễ dự án
◼ Slack Time
◼ Là thời gian được phép trễ so với kế hoạch ban đầu
◼ Slack Time = LCT - ECT

Sơ đồ PERT
ECT (Earliest Completion Time )

53
Event number 6
130
LCT (Lastest Completion Time)

Sơ đồ PERT
◼ Cách tính ECT:
◼ Tính từ trái sang phải. ECT của node bắt đầu là 0.
◼ Bằng ECT của node trước + thời gian hoàn thành công việc
◼ Nếu có nhiều node trước:
◼ Tính ECT của từng node trước + thời gian hoàn thành
CV
◼ Lấy giá trị lớn nhất trong các giá trị vừa tính
30 25 55
2 4 Tính ECT của node 4
•Từ node 2 là: 30 + 25 = 55
•Từ node 3 là: 15 + 35 = 50
35
15 → ECT của node 4 là 55
3

Sơ đồ PERT
◼ Cách tính LCT:
◼ Tính từ phải sang trái. LCT của node cuối bằng ECT của
node này.
◼ Bằng LCT của node sau - thời gian hoàn thành CV
◼ Nếu có nhiều node sau:
◼ Tính LCT của từng node sau - thời gian hoàn thành CV
◼ Lấy giá trị nhỏ nhất trong các giá trị vừa tính
55
4
65 Tính LCT của node 3
•Từ node 4 là: 65 - 35 = 30
35
15 •Từ node 5 là: 30 - 15 = 15
3 30
5 → LCT của node 3 là 15
15
15 30

Sơ đồ PERT/CPM
◼ CPM (Critical Path Method)
◼ Đường găng (Critical Path) là đường bao gồm các
công việc và các node có slack time bằng 0 (tức là
ECT bằng LCT)
◼ Các công việc nằm trên đường găng là các công
việc phải được giám sát chặt chẽ, vì chúng không
được phép trễ hạn. Khi một công việc trên đường
này bị trễ thì cả dự án cũng bị trễ theo.

Sơ đồ PERT/CPM
Programing
Programming Testing System Test
5 75
105 130
2 4 8 10
5 75 30 25
Plan & 70 105 130
Schedule
5
0 User Training
1 User Test
0
Hardware Write User 53 130 155
7 9 11
Deliverry Manual 110 130 25 155
Install 20
18 Hardware
18 28
3 5
65 10 75 Convert Files
25
53
6
130

Bài tập
Must Expected
Description Task
Follow Time (Days)
Draw data flow P - 9
Draw decision tree Q P 12
Revise tree R Q 3
Write up project S R,Z 7
Organize data dict T P 11
Do outputprototype X - 8
Revise output design Y X 14
Design database Z T,Y 5

Chương 3
Thu thập thông tin

Chương 3: Thu thập thông tin Slide 1
Phân tích hệ thống (System analysis)
◼ Mục tiêu:
◼ Hiểu rõ hệ thống
◼ Phát triển mô hình luận lý của hệ thống
◼ Tạo nền tảng vững chắc cho giai đoạn thiết kế
◼ Kết quả
◼ Tài liệu mô tả các yêu cầu của hệ thống (SRS -System
Requirements Specification document)
➔ Trả lời chủ yếu cho câu hỏi “WHAT?”

Phân tích hệ thống (System analysis)
Các công việc cần làm:
◼ Mô hình hóa yêu cầu
◼ Thu thập thông tin

◼ Phân tích các yêu cầu:
◼ Xây dựng sơ đồ chức năng
◼ Lập danh sách các yêu cầu hệ thống
◼ Mô hình hóa dữ liệu
◼ Mô hình hóa quá trình xử lý
◼ Chuẩn bị để chuyển tiếp sang giai đoạn thiết kế

Hiểu rõ vấn đề
◼ Lập trình viên thường có thói quen đi vào dự án và bắt
đầu lập trình ngay.
◼ Sau khi nghe người dùng nói về yêu cầu của họ, lập
trình viên thường nói với người dùng rằng: “Tôi đã hiểu
tất cả những gì mà bạn cần”. Đây là một cái bẫy cho
các lập trình viên.
◼ Phương pháp Agile cho thấy những nhà phát triển phải
làm việc với người dùng trong suốt dự án để hiểu
người dùng cần gì nếu muốn tránh bẫy này.
◼ User Story là một trong những công cụ tốt nhất để triển
khai việc này
User Story và Use Case

User Story
◼ User Story còn được gọi là Scenario (kịch bản) để mô
tả một yêu cầu từ người dùng.
◼ User Story được viết bằng ngôn ngữ của người dùng,
gần gũi với từ ngữ thường ngày của người dùng. Vì
vậy người dùng nào cũng có thể đọc và hiểu ngay.
◼ User Story thường được viết trên Card, giấy note, tài
liệu Words, Excels… tùy dự án.

User story
◼ Ta xét ví dụ sau:
“Chức năng tìm kiếm và thay thế trong trình soạn thảo
văn bản”
◼ Với User Story, ta có thể bắt đầu bằng cách viết ra một
tấm thẻ (card) như sau:

Use Case

Use Case
◼ Use case cũng gần giống như một User Story nhưng
tập trung sẽ mô tả cách tương tác giữa người dùng và
phần mềm.
◼ Use Case là một mô tả đầy đủ về tất cả những trường
hợp mà người dùng sử dụng phần mềm sẽ gặp phải.
◼ Người lập trình thông qua use case sẽ nắm bắt cách
người dùng tương tác với phần mềm để đạt kết quả
mong muốn.

Phải trả lời được các câu hỏi (5W + 1H)
◼ WHAT: Những thủ tục gì đang được thực hiện?
◼ WHO: Ai thực hiện các thủ tục đó?
◼ WHERE: Các hoạt động đang diễn ra ở đâu?
◼ WHEN: Thủ tục diễn ra khi nào?
◼ HOW: Thủ tục được thực hiện như thế nào?
◼ WHY: Tất cả các câu hỏi trên đều được tìm hiểu tại sao
phải như vậy?

Hệ thống hiện tại Hệ thống đề nghị
Cái gì đang thực hiện? Tại sao? Cái gì nên thực hiện?
(WHAT) (WHY) (WHAT)
Được thực hiện ở đâu? Tại sao? Nên thực hiện ở đâu?
(WHERE) (WHY) (WHERE)
Khi nào được thực hiện? Tại sao? Nên thực hiện khi nào?
(WHEN) (WHY) (WHEN)
Ai đang thực hiện? Tại sao? Ai nên thực hiện việc này?
(WHO) (WHY) (WHO)
Đang thực hiện thế nào? Tại sao? Nên được thực hiện thế nào?
(HOW) (WHY) (HOW)

Một số phương pháp thường sử dụng:
◼ Phỏng vấn (interview)
◼ Bản câu hỏi (questionnaire)
◼ Quan sát (observation)
◼ Khảo sát tài liệu (document review)
◼ Nghiên cứu (research)
◼ Lấy mẫu (sampling)
◼ …

Phỏng vấn
◼ Được sử dụng nhiều nhất
◼ Ưu điểm là cho kết quả và trang bị kiến thức cho người
phân tích trong một thời gian ngắn
◼ Các bước thực hiện:
◼ Xác định đối tượng phỏng vấn
◼ Xác định mục tiêu phỏng vấn
◼ Chuẩn bị câu hỏi và cấu trúc hỏi
◼ Chuẩn bị cho buổi phỏng vấn
◼ Thực hiện việc phỏng vấn
◼ Lập báo cáo buổi phỏng vấn
◼ Đánh giá buổi phỏng vấn

Phỏng vấn
B1: Xác định đối tượng phỏng vấn
◼ Chọn đúng người để phỏng vấn
◼ Bộ phận điều hành → hiểu mục đích, tổng quan về HT

◼ Bộ phận thực hiện → hiểu cách xử lý chi tiết nghiệp vụ
◼ Dựa vào sơ đồ tổ chức của công ty → tiến hành các
buổi phỏng vấn chính thức (formal)
◼ Cần tìm hiểu thêm cấu trúc phi chính thức (informal
structure) trong đơn vị
◼ Phỏng vấn nhiều người cùng lúc (group interview)
◼ Tiết kiệm thời gian, có cơ hội đánh giá mối quan hệ cá nhân
◼ Một số thông tin nhạy cảm khó thu thập. Trong buổi phỏng
vấn đôi khi chỉ xoay quanh một vài người
Phỏng vấn
B2: Xác định mục tiêu buổi phỏng vấn
◼ Xác định những lãnh vực cần thảo luận
◼ Liệt kê các sự kiện muốn thu thập
◼ Các ý tưởng, đề nghị cần đề xuất
◼ Nên hạn chế chỉ nên đặt 1 → 3 mục tiêu trong một buổi
phỏng vấn
◼ Một sai lầm thường gặp là do hiểu lầm mục tiêu là tìm
hiểu về mức độ tin học hóa trong đơn vị, nên phía
người dùng thường đưa người phân tích đi tham quan
các phòng máy, trình bày các dự án mạng, các dự tính
của phòng IT, …
Phỏng vấn
B3: Chuẩn bị câu hỏi
◼ Giúp PTV không bị lệch hướng khi phỏng vấn
◼ Thường chia làm 2 dạng câu hỏi:
◼ Câu hỏi mở (open-ended questions): để người được

phỏng vấn tự do trình bày các ý kiến của mình → có thể
thu được nhiều thông tin mới.
◼ VD: “Tại sao anh lại làm theo cách này?”
◼ Câu hỏi đóng (closed-ended questions): Câu trả lời đã
được giới hạn → lấy ngay thông tin cụ thể
◼ VD: “Loại đơn này sẽ được xử lý trong mấy ngày?”

Phỏng vấn
◼ Cấu trúc hỏi là thứ tự các câu hỏi sẽ được đặt ra trong
buổi phỏng vấn.
Thường có 3 dạng:
◼ Cấu trúc hình tháp (pyramid structure)
◼ Bắt đầu bằng câu hỏi đóng
◼ Mở rộng vấn đề bằng các câu
hỏi mở
◼ Kết thúc buổi phỏng vấn là
một câu hỏi mang tính tổng quát

Phỏng vấn
◼ Cấu trúc hình phễu (funnel structure)
◼ Bắt đầu bằng câu hỏi tổng quát
◼ Thu hẹp dần các vấn đề bằng
các câu hỏi đóng
◼ Kết thúc buổi phỏng vấn là
các câu hỏi mang tính đặc thù

Phỏng vấn
◼ Cấu trúc hình kim cương (diamond structure)
◼ Bắt đầu bằng câu hỏi đóng thông
thường để lấy số liệu
◼ Mở rộng vấn đề bằng các câu
hỏi mở
◼ Khi đã đạt được mục tiêu tổng quát
sẽ tiếp tục thu hẹp vào các vấn đề
chuyên sâu bằng các câu hỏi đóng
◼ Kết thúc buổi phỏng vấn là các câu
hỏi chuyên biệt

Phỏng vấn
B4: Chuẩn bị cho buổi phỏng vấn
◼ Xác định ngày giờ cụ thể
◼ Xác định địa điểm phỏng vấn (tại ngay chỗ làm việc
hay ở phòng họp, …)
◼ Thông báo nhắc nhở
◼ Gởi trước cho người được phỏng vấn các câu hỏi chủ
yếu và các yêu cầu về tài liệu để họ chuẩn bị

◼ Đọc trước các tài liệu liên quan đến công ty và các
nghiệp vụ cần phỏng vấn

Phỏng vấn
B5: Thực hiện cuộc phỏng vấn
◼ Tự giới thiệu
◼ Mô tả tổng quát dự án
◼ Giải thích mục tiêu của buổi phỏng vấn
◼ Đặt các câu hỏi theo thứ tự đã chuẩn bị
◼ Chú ý lắng nghe cẩn thận
◼ Tổng kết các điểm chính
◼ Chuẩn bị cho cuộc phỏng vấn kế tiếp

Phỏng vấn
B6: Lập báo cáo buổi phỏng vấn
◼ Trong buổi phỏng vấn nên ghi chép nhanh và ngắn gọn
các thông tin quan trọng
◼ Nếu sử dụng các phương tiện ghi âm, phải báo trước
với người được phỏng vấn
◼ Ghi lại cẩn thận các thông ghi đã ghi nháp thành báo
cáo chính thức
◼ Gởi báo cáo này cho người được phỏng vấn để họ xác
nhận lại các hiểu biết của chúng là là chính xác

B7: Đánh giá buổi phỏng vấn để rút kinh nghiệm

Bản câu hỏi
◼ Lợi điểm:
◼ Hữu hiệu khi cần thu thập thông tin từ nhiều người
◼ Giảm thời gian khảo sát
◼ Nhiều người có thể trả lời thằng thắn
◼ Nhược điểm
◼ Thường có chất lượng không cao do:
◼ Mẫu thiết kế không tốt → không hiểu rõ câu hỏi
◼ Tâm lý điền chiếu lệ
◼ Khó tìm hiểu các khái niệm nghiệp vụ mới

Bản câu hỏi
◼ Bản câu hỏi bắt đầu bằng tiêu đề (heading) giải thích
ngắn gọn mục đích
◼ Tiếp theo là các chỉ dẫn tổng quát về cách ghi phiếu
◼ Phần nội dung câu hỏi nên:
◼ Ngắn gọn và thân thiện
◼ Hướng dẫn rõ ràng
◼ Sắp xếp câu hỏi theo thứ tự hợp lý
◼ Tránh các câu hỏi có thể gây hiểu nhầm
◼ Hạn chế các câu hỏi mở
◼ Hạn chế các câu hỏi nhạy cảm
◼ Nhóm các câu hỏi có liên quan vào một phân nhóm
Khảo sát tài liệu
◼ Tìm hiểu các tài liệu liên quan đến hệ thống hiện tại
như các quy định của công ty
◼ Cần có bản sao của các mẫu biểu thực đang sử dụng
◼ Khảo sát các biểu mẫu trống
◼ Khảo sát các biểu mẫu đã điền số liệu
◼ Khảo sát các phần mềm đang sử dụng
◼ Cần lưu ý một số tài liệu đã bị lỗi thời

Quan sát
◼ Rất hữu hiệu để hiểu rõ các quy trình nghiệp vụ
◼ Nên đặt thêm các câu hỏi thích hợp để hiểu một cách
đầy đủ về hệ thống
◼ Quan sát tất cả các bước xử lý
◼ Ghi nhận xem xét tất cả các mẫu biểu, báo cáo
◼ Quan sát cách làm việc của từng người liên quan đến
nghiệp vụ
◼ Trao đổi với từng người để đánh giá tính đầy đủ, kịp
thời, chính xác và hữu ích của các mẫu biểu, báo cáo
◼ Chú ý hiệu ứng Hawthorne: năng suất làm việc thường
tăng lên khi một người biết rằng họ đang bị quan sát
Nghiên cứu
◼ Báo, tạp chí, sách
◼ Internet
◼ Các nhà cung cấp phần cứng và phần mềm
◼ Các hãng cung cấp tin
◼ Các nhóm tin
◼ Hội nghị chuyên đề, hội thảo
◼ Tham quan các nơi đang sử dụng HT tương tự

Lấy mẫu
◼ Là việc chọn lọc có hệ thống các phần tử tiêu biểu trong
một tập hợp cần khảo sát
◼ Có thể sử dụng để chọn người phỏng vấn, gởi bản câu
hỏi, chọn tài liệu khảo sát, …
◼ Các loại mẫu:
◼ Mẫu thích hợp (convenience sampling)
◼ Mẫu theo mục đích (purpose sampling)
◼ Mẫu ngẫu nhiên đơn giản (simple random sampling)
◼ Mẫu ngẫu nhiên phức tạp (complex random sampling)

Lập tài liệu
◼ Thông tin phải ghi chính xác
◼ Nguyên tắc cơ bản: ghi ra giấy
◼ Để lập tài liệu tốt cần:
◼ Ghi nhận thông tin càng sớm càng tốt
◼ Sử dụng phương pháp ghi nhận nhanh nhất
◼ Mô tả dễ hiểu
◼ Tổ chức tốt

Lập tài liệu
Các công cụ hỗ trợ lập tài liệu
◼ CASE tool
◼ Phần mềm xử lý văn bản (word processing)
◼ Bảng tính điện tử (spreadsheet)
◼ Cơ sở dữ liệu (database)
◼ Phần mềm trình diễn (presentation)
◼ Phần mềm quản lý thông tin cá nhân ( PIM - Personal
Information Manager)

Sơ đồ phân rã chức năng
◼ FHD: Functional Hierarchy Diagrams
◼ FDD: Functional Decomposition Diagrams
◼ BFD: Business Function Diagrams
◼ Thể hiện các nghiệp vụ bằng cách phân rã dần các
chức năng theo sơ đồ cây
◼ Các chức năng trong sơ đồ này về sau sẽ được cài đặt
thành các chương trình trong hệ thống
◼ Phân biệt với sơ đồ tổ chức (organization chart)

Sơ đồ phân rã chức năng (FHD)
Sô ñoà phaân raõ chöùc naêng cuûa moät heä thoáng thö vieän

Human resource management system
System Personnel Contract Statiscal System

Recruitment Self-Service
Desktop FIles Management Analysis Management
Roster for
Hiring Talent Pool Male/Female
Bulletin Board Contract Type current System Roles
Announcement Management Ratio Analysis
employee
Appointment Interview Employee Data Contract Roster for left System

Age Analysis
Approves Records Management Maintenence employee Administrator
Employee
Contract Employee Title Propotion Data
Staff Approval Change
Renewal contracts Analysis Dictionary
Management
Employee Employee
Personnel Contract
Turnover Information Data Backup
Deployment expiration
Management Inquiry
Employee Data
Data Recovery
Import/Export

Danh mục các yêu cầu hệ thống
System requirements checklist
◼ Bao gồm toàn bộ các yêu cầu phải được áp đặt lên hệ
thống
◼ Mỗi yêu cầu có thể sẽ được hiện thực trên hệ thống
dưới dạng: một chức năng của hệ thống, một ràng
buộc dữ liệu, một ràng buộc về nhập liệu, kết xuất…

Có thể phân loại theo:
◼ Yêu cầu về kết xuất (outputs)
◼ Yêu cầu về nhập liệu (inputs)
◼ Yêu cầu về xử lý (processes)
◼ Yêu cầu về hiệu suất (performance)
◼ Yêu cầu về kiểm soát (controls)

Kết xuất (outputs)
◼ Web site phải thống kê số lượng truy cập trực tuyến
mỗi 4 giờ, riêng giờ cao điểm thì thông kê hàng giờ
◼ HT tồn kho phải in ra báo cáo hàng ngày gồm: mã
hàng, tên hàng, đơn giá, số lượng trong kho, số lượng
đã phân phối, số lượng còn lại – sắp thứ tự theo mã
hàng
◼ HT mua hàng phải cung cấp danh sách các nhà cung
cấp với các cập nhật mới nhất

◼ …

Nhập liệu (inputs)
◼ Nhân viên sẽ quét thẻ vào thiết bị để đưa dữ liệu vào
HT chấm công
◼ Điểm của sinh viên sẽ được nhập vào HT bằng máy
quét, giáo viên giảng dạy phải ghi điểm đúng mẫu
◼ Tất cả các màn hình nhập phải thống nhất mẫu, trừ
màu nền có thể thay đổi bởi người sử dụng
◼ …

Quá trình xử lý (processes)
◼ HT quản lý học vụ phải cho phép truy cập điểm của
sinh viên dựa vào mã sinh viên hoặc tên sinh viên
◼ HT lương phải có thể tạo ra các báo cáo tính thuế thu
nhập của nhân viên
◼ HT nhân sự mới xây dựng phải giao tiếp được với HT
lương đang hoạt động
◼ …

Hiệu suất (performance)
◼ HT phải cho phép 25 người truy cập đồng thời
◼ HT phải hoạt động liên tục 24/24, hoạt động cả 7 ngày

trong tuần
◼ HT quản lý học sinh phải tạo ra danh sách lớp trong
vòng 5 giờ sau khi kết thúc đăng ký
◼ HT quản lý tồn kho phải đánh dấu tất cả mặt hàng sắp
hết trong vòng 1 giờ kể từ khi số lượng tồn kho thấp

hơn định mức tồn trữ tối thiểu theo quy định
◼ …

Điều khiển (controls)
◼ HT phải cung cấp chức năng bảo mật khi đăng nhập ở
mức hệ điều hành và cả mức ứng dụng
◼ Hồ sơ nhân viên chỉ cho phép nhân viên phòng nhân
sự sửa chữa, cập nhật
◼ Tất cả các giao dịch đều phải được ghi lại để theo dõi
◼ HT phải tạo tập tin nhật ký ghi nhận lại tất cả các lỗi
sai, mô tả lỗi, ngày tháng lỗi xuất hiện

◼ …

Scalability
◼ Scalability là khả năng điều chỉnh hệ thống, mở rộng
(hay thu hẹp) trong tương lai khi các yêu cầu nghiệp vụ
thay đổi
◼ Cần các thông tin về dữ liệu nhập, xuất và quá trình xử
lý trong hiện tại và dự báo mức phát triển trong tương
lai
◼ Khối lượng dữ liệu → quyết định phần cứng, phần mềm
◼ Khối lượng giao dịch → chi phí vận hành

Tổng chi phí sở hữu (TCO)
◼ TCO : Total Cost of Ownership
◼ Tổng chi phí sở hữu bao gồm tất cả các chi phí liên
quan đến dự án, cả chí phí trực tiếp lẫn gián tiếp
◼ Các chi phí gián tiếp đôi khi ẩn, khó phát hiện → hệ
thống ban đầu được đánh giá ít tốn kém có thể lại trở
thành hệ thống tốn kém nhất

CSF (Critical Successful Factor)
◼ Yếu tố thành công quan trọng (CSF) là các thông tin
bắt buộc hệ thống phải tổng hợp, theo dõi quản lý
được thì hệ thống mới được xem là đạt yêu cầu về
quản lý
◼ Người ta xác định CSF trong danh mục các yêu cầu hệ
thống
◼ VD: Trong bài toán quản lý kho, phải cho phép kiểm tra
số lượng tồn kho của từng mặt hàng bất kỳ lúc nào →
đây là CSF của bài toán

Kiểm tra chéo
◼ Trong “danh mục các yêu cầu HT” người ta đánh số thứ tự cho
từng yêu cầu:
(1) HT phải …
(2) HT phải …
……………….
◼ Lập bảng kiểm tra chéo danh sách này với sơ đồ phân rã chức
năng (FHD)
Chức năng Yêu cầu của người dùng
Theo dõi nhập hàng 1, 2, 3, …
Theo dõi xuất hàng 6, 7, 8, …
… …
→ Tất cả các yêu cầu trong “danh mục các yêu cầu HT” phải
xuất hiện đầy đủ trong bảng kiểm tra
Chương 4
Mô hình hóa
quy trình xử lý và dữ liệu

Chương 4: mô hình hóa quy trình và xử lý Slide 1
Tại sao phải mô hình?
◼ Tại sao các kỹ sư hàng không tạo mô hình máy
bay? Kỹ sư cầu đường làm mô hình cây cầu?
◼ Mục đích của những mô hình này là gì?
◼ Kỹ sư làm mô hình để xác định xem liệu thiết kế
của họ có hoạt động chính xác không?
◼ Kỹ sư hàng không làm mô hình máy bay và đưa
chúng vào các ống gió (wind tunnel) để xem chúng
có bay được không?
◼ Kiến trúc sư làm mô hình các tòa nhà để xem khách
hàng có đồng ý kiểu dáng như thế không?

◼ Tại sao kỹ sư hàng không không chế tạo ra máy
bay rồi thử nó xem có bay được không?
◼ Tạo sao kỹ sư cầu đường không cho xây cây cầu
rồi mới xem chúng có chịu được tải khi xe lưu
thông qua không?
◼ Bởi vì máy bay và cây cầu đắt hơn rất nhiều so với
mô hình.
◼ Chúng ta nghiên cứu các thiết kế bằng cách làm
mô hình nếu như việc làm mô hình rẻ hơn nhiều
lần so với việc chúng ta tạo ra vật thể thực.

◼ Mô hình được tạo để xác định xem một vật nào đó
có hoạt động không.
◼ Điều này ẩn chứa ý rằng mô hình có thể kiểm thử
được. Thật vô nghĩa nếu mô hình tạo ra mà ta
không thể thực hiện các phép kiểm thử trên nó.
◼ Nếu không đánh giá được mô hình, thì mô hình đó
không có giá trị.

Tại sao tạo mô hình phần mềm?
◼ Liệu có thể kiểm thử các lược đồ? Liệu tạo các
lược đồ có rẻ hơn và dễ kiểm thử hơn phần mềm
mà nó biểu diễn?
◼ Trong cả hai tình huống, câu trả lời không bao giờ
rõ ràng như lĩnh vực hàng không và cầu đường.
◼ Không có phương pháp chắc chắn nào để kiểm
thử các lược đồ
◼ Vẽ lược đồ dễ hơn là viết phần mềm, nhưng với
hệ số không lớn. Thật vậy, thay đổi mã nguồn dễ
hơn rất nhiều so với việc thay đổi một lược đồ.

Tại sao tạo mô hình phần mềm?
◼ Như vậy xây dựng lược đồ có hợp lý không?
◼ Thực ra, những lập luận trên nhằm giải thích rằng
lược đồ rất dễ bị dùng sai mục đích.
◼ Chúng ta sử dụng lược đồ khi chúng ta có một thứ
gì đó mà chúng ta dứt khoát phải kiểm thử nó, và
khi dùng lược đồ để kiểm thử thì rẻ hơn là dùng
mã nguồn để kiểm thử nó.
◼ Ví dụ tôi có một ý tưởng cho một thiết kế nào đó, và
muốn kiểm tra liệu các thành viên trong nhóm của
tôi có cho đấy là một ý tưởng đúng đắn không. Vì
vậy tôi vẽ lược đồ lên bảng và hỏi thành viên trong
nhóm để nhận phản hồi.
Công cụ mô hình hóa
◼ Các công cụ này có các đặc điểm chung sau:
◼ Sử dụng ký hiệu đồ họa (graphical symbol)
◼ Có cấu trúc (strutural) → phân cấp mô tả đến mức
thấp nhất
◼ Các công cụ thường dùng trong phương pháp phân
tích có cấu trúc là:
◼ Sơ đồ dòng dữ liệu (Data Flow Diagram – DFD)
◼ Sơ đồ thực thể - liên kết (Entity-Relationship
Diagram – ERD)
◼ Từ điển dữ liệu (Data Dictionary – DD)
◼ Đặc tả quá trình (Process Specification – PS)

Sơ đồ DFD
◼ Sơ đồ dòng dữ liệu (DFD - Data Flow Diagrams)
cho thấy cách dữ liệu di chuyển bên trong hệ
thống như thế nào. Ví dụ: dữ liệu phát sinh từ
đâu? di chuyển đến đâu? Các chức năng nào sử
dụng những dữ liệu nào? …
◼ Sơ đồ DFD chỉ xây dựng nên một mô hình luận lý
(logic), tức nó chỉ cho thấy hệ thống “LÀM GÌ ?”
mà không cho thấy “LÀM THẾ NÀO?”
◼ PTV không bị chi phối bởi việc tìm hiểu chi tiết
về mặt kỹ thuật hiện thực hệ thống có thể dẫn đến
mất tính tổng quát.

Các ký hiệu cơ bản trong DFD
◼ Có 4 ký hiệu cơ bản:
◼ Quy trình xử lý (process)
◼ Dòng dữ liệu (data flow)
◼ Kho dữ liệu (data store)
◼ Thực thể ngoài (external entity)
◼ Có 2 hệ thống ký hiệu thường dùng:

◼ Gane and Sarson
◼ Yourdon

Hệ thống ký hiệu của DFD

Thực thể ngoại (external entity)
◼ Biểu diễn các đối tượng nằm ngoài hệ thống
nhưng có tương tác với hệ thống, như cung cấp
dữ liệu cho hệ thống, hoặc nhận kết quả từ hệ
thống
◼ Các thực thể ngoại có thể là con người, tổ chức
hoặc một hệ thống khác
◼ Còn gọi là tác nhân đầu cuối (terminator).
◼ Thực thể ngoại cung cấp dữ liệu cho hệ thống là
“source” (nguồn)
◼ Thực thể ngoại nhận dữ liệu từ hệ thống là “sink” (đích)
◼ Có thể vừa là source vừa là sink

Thực thể ngoại (external entity)
Ký hiệu:
◼ Hình chữ nhật
◼ Tên thực thể ngoại là danh từ mô tả đối tượng

tương tác với hệ thống
◼ Một thực thể ngoại có thể được vẽ lại nhiều lần
trong sơ đồ để tránh các dòng dữ liệu cắt nhau →
nên có thêm dấu gạch chéo ở góc hình chữ nhật
để phân biệt
Khách hàng Khách hàng

Quy trình xử lý (process)
◼ Process biểu diễn cho một công việc xử lý dữ liệu
(data processing) trong hệ thống
◼ Trong sơ đồ DFD, process giống như một hộp
đen, không cho thấy các chi tiết xử lý bên trong
◼ Chi tiết xử lý sẽ được trình bày trong phần đặc tả
quá trình (PS – Process Specification)
◼ Ký hiệu:
◼ Hình chữ nhật tròn góc (hoặc hình tròn)
◼ Mỗi process sẽ có một số nhận dạng (ID)
◼ Tên process nên bắt đầu bằng một động từ

Dòng dữ liệu (data flow)
◼ Biểu diễn đường đi của dữ liệu từ thành phần này
đến thành phần khác trong hệ thống
◼ Ký hiệu:
◼ Đường thẳng có mũi tên ở một đầu để biểu diễn
chiều di chuyển của dữ liệu
◼ Mỗi dòng dữ liệu có một mã số nhận dạng (khi sử
dụng CASE tool)
◼ Tên dòng dữ liệu nên là một danh từ thể hiện nội
dung dữ liệu di chuyển trên đó

Dòng dữ liệu (data flow)
Ghi chú:
◼ Ký hiệu mũi tên ở hai đầu chỉ dòng dữ liệu có thể
di chuyển cả 2 chiều, với cấu trúc dữ liệu bên
trong giống nhau. Điều này thường chỉ xảy ra với
các dòng dữ liệu ra vào kho dữ liệu
◼ Tên dòng dữ liệu không nên đặt trùng nhau để
tránh nhầm lẫn khi mô tả từ điển dữ liệu sau này
◼ Tất cả các dòng dữ liệu đều phải có tên.
◼ Có thể không ghi tên cho các dòng dữ liệu ra vào

kho dữ liệu (vì nội dung trên các dòng này giống
như nội dung trong các kho)
Kho dữ liệu (data store)
◼ Biểu diễn nơi lưu trữ dữ liệu, để các process khác
nhau trong hệ thống sử dụng.
◼ Kho dữ liệu sau này sẽ được thiết kế để chuyển
thành cơ sở dữ liệu của hệ thống
◼ Ký hiệu:
◼ Hình chữ nhật mở một đầu bên phải (hoặc 2 đường
song song)
◼ Mỗi kho dữ liệu có một số nhận dạng (ID)
◼ Tên kho dữ liệu là một danh từ thể hiện nội dung
lưu trữ trong kho

Các lỗi sai về khái niệm
◼ Thực thể ngoại phải là các tác nhân có khả năng
trao đổi dữ liệu (thông tin) với hệ thống
Thông tin 1
đơn đặt hàng
Đơn đặt
hàng Lưu trữ đơn
đặt hàng
SAI
D1 Đơn đặt hàng
1
Đơn đặt hàng
Khách hàng
Xử lý đơn
đặt hàng
ĐÚNG

◼ Process mô tả một công việc, một chức năng xử lý
dữ liệu, không mô tả vị trí thực hiện công việc đó
Đơn đặt hàng 1

Đơn đặt hàng
của khách đã duyệt
Phòng SAI
Kinh Doanh

Đơn đặt hàng
của khách
Xử lý đơn
đã duyệt
ĐÚNG
đặt hàng

◼ Dòng dữ liệu và kho dữ liệu mô tả về mặt dữ liệu
(data) di chuyển và lưu trữ trong hệ thống, không
mô tả về mặt vật chất (material)
1
Nhà cung
cấp
gởi hàng
Nhận hàng
SAI
D1 Kho chứa hàng
Nhà cung Phiếu giao hàng Cập nhật

cấp phiếu giao ĐÚNG
hàng của
NCC D1 Phiếu giao hàng

Các lỗi sai thường gặp với process
◼ Quy tắc: process là công việc biến đổi dữ liệu đầu
vào (input) thành các dữ liệu đầu ra (output).
Vì vậy:
◼ Mỗi process phải có ít nhất một dòng dữ liệu vào và
ít nhất một dòng dữ liệu ra
◼ Dữ liệu đầu ra phải khác nội dung hoặc dạng thức
của dữ liệu đầu vào
◼ Vi phạm sẽ dẫn đến một số lỗi sai sau:

◼ Process chỉ có dòng dữ liệu ra, không có dòng dữ
liệu vào
→ process tự phát sinh (spontaneous genaration)
Báo cáo 2
Báo cáo
doanh thu
In báo cáo
tồn kho
SAI
hắng ngày

◼ Process chỉ có dòng dữ liệu vào, không có dòng
dữ liệu ra
→ lỗ đen (black hole)
Bảng điểm 3
Quy chế xử lý
năm học
Xử lý
học vụ
SAI
học vụ

◼ Các dòng dữ liệu vào của một process không đủ
để tạo các dòng dữ liệu ra
→ lỗ xám (gray hole)
Danh sách 4
Danh sách học
học sinh
Xếp loại
sinh đã xếp loại
SAI
học sinh

Các lỗi sai về liên kết các thành phần
◼ Không được có dòng dữ liệu trực tiếp giữa thực
thể ngoại và thực thể ngoại
Thanh toán
Phòng
Khách hàng
kế toán SAI
◼ Không được có dòng dữ liệu trực tiếp giữa kho dữ

liệu và kho dữ liệu → thêm process xử lý vào giữa
Hồ sơ lưu
D1 Hồ sơ nhân viên D1 Hồ sơ hưu

SAI

Các lỗi sai về liên kết các thành phần
◼ Không được có dòng dữ liệu trực tiếp giữa thực
thể ngoại và kho dữ liệu → thêm process xử lý vào
Đơn khiếu nại

Công dân
SAI
D1 Đơn khiếu nại
Đơn khiếu nại

Ban
lãnh đạo
SAI
D1 Đơn khiếu nại

Các bước xây dựng sơ đồ DFD
1. Từ các tài liệu nghiệp vụ xác định các thực thể
ngoại, các kho dữ liệu cần lưu trữ, các chức năng
của hệ thống, các dòng dữ liệu quan trọng
2. Xây dựng sơ đồ ngữ cảnh (context diagram)
3. Xây dựng sơ đồ DFD mức 0 (level 0)
4. Xây dựng sơ đồ DFD ở các mức chi tiết
5. Kiểm tra sơ đồ ở các cấp để phát hiện lỗi
6. Xây dựng sơ đồ DFD vật lý (physical DFD) từ sơ
đồ DFD luận lý (logical DFD)
7. Phân hoạch (partitioning) sơ đồ DFD vật lý

Sơ đồ ngữ cảnh (context diagram)
◼ Cho ta cái nhìn tổng quát về môi trường làm việc
của hệ thống → còn gọi là sơ đồ môi trường.
◼ Toàn bộ hệ thống được nhìn như một hộp đen →
biểu diễn bằng một process (đánh số 0)
◼ Tất cả các thực thể ngoại đều xuất hiện trong sơ
đồ này → không được phép vẽ thêm các thực thể
ngoại mới trong các sơ đồ ở các mức sau
◼ Tất cả các dòng dữ liệu trao đổi giữa hệ thống với
thực thể ngoại
◼ Trong sơ đồ ngữ cảnh không có kho dữ liệu

Sơ đồ ngữ cảnh
Một số quy ước:
◼ Toàn bộ sơ đồ ngữ cảnh phải nằm trọn trên một
trang giấy
◼ Tên của process trong sơ đồ ngữ cảnh nên là tên
của hệ thống
◼ Tên của thực thể ngoại và tên các dòng dữ liệu
nên ngắn gọn, dễ hiểu
◼ Các dòng dữ liệu không được cắt nhau


Sơ đồ DFD mức 0 (Diagram 0)
◼ Để xem xét chi tiết hơn nội dung bên trong của sơ
đồ ngữ cảnh.
◼ Sơ đồ mức 0 là sự phân rã của sơ đồ ngữ cảnh →
là sơ đồ con (child diagram) của sơ đồ ngữ cảnh
◼ Trong sơ đồ mức 0 sẽ chỉ ra các quy trình xử lý
chính, các dòng dữ liệu trao đổi giữa các quy trình
này, và các kho dữ liệu dùng chung giữa chúng.
◼ Sơ đồ mức 0 cần thể hiện lại đầy đủ các thực thể
ngoại và các dòng dữ liệu đã xuất hiện trong sơ đồ
ngữ cảnh

Ví dụ

Sơ đồ DFD mức 0
Một số vấn đề cần lưu ý:
◼ Mỗi process trong sơ đồ mức 0 sẽ được đánh số
ID lần lượt là 1, 2, 3, …
◼ Mỗi process ở mức này tương ứng với một chức
năng lớn trong hệ thống (thường tương ứng với
mức trên của sơ đồ FHD)
HT QL hàng hóa
QL hàng nhập QL hàng xuất QL tồn kho

0
XXX …… …… YYY
Hệ thống
QL hàng hóa
XXX …… …… YYY
Quản lý
hàng xuất
1 3
ddd
Quản lý Quản lý
hàng nhập tồn kho

Kho dữ liệu trong sơ đồ DFD mức 0
◼ Là các kho lưu dữ liệu dùng chung cho các chức
năng khác nhau trong hệ thống.
◼ Các lỗi sai thường gặp:
◼ Kho dữ liệu chỉ có dòng vào mà không có dòng ra,
hoặc chỉ có dòng ra mà không có dòng vào
◼ Kho dữ liệu chỉ có một process sử dụng nên chuyển
thành kho nội bộ của process
Lưu để Làm sao có

Kho nội dữ liệu
làm gì? bộ? này?

Dòng dữ liệu phân kỳ (diverging data flow)
◼ Là dòng dữ liệu trên đó chứa cùng một loại dữ liệu
và được chuyển đến cho nhiều vị trí khác nhau
trong sơ đồ.
1 2
Đơn đặt hàng đã duyệt
Xử lý Lập hóa đơn
đơn đặt hàng giao hàng

đã duyệt
Cập nhật
công nợ
khách hàng

◼ Về nguyên tắc: không chấp nhận một dòng dữ liệu
mà dữ liệu trên đó được tách thành nhiều dòng với
các nội dung khác nhau để chuyển đến các nơi
khác nhau
Data flow X
Data flow T Data flow Y

SAI
Data flow Z

◼ Một số tác giả và CASE tool chấp nhận sử dụng
các ký hiệu bổ sung (thay vì dùng process để tách
các dòng này)
Data flow X Data flow X
Data flow T Data flow Y Data flow T Data flow Y

=X+Y+Z = X or Y or Z
Data flow Z Data flow Z

Dòng dữ liệu hội tụ (converging data flow)
◼ Về nguyên tắc: không chấp nhận dòng dữ liệu mà
dữ liệu trên đó được kết hợp lại từ nhiều dòng dữ
liệu khác
Data flow X
Data flow Y Data flow T

SAI
Data flow Z

Dòng dữ liệu hội tụ (converging data flow)
◼ Giải pháp tương tự bằng cách sử dụng các ký hiệu
bổ sung (thay vì dùng process để kết hợp các
dòng này)
Data flow X Data flow X
Data flow Y Data flow T Data flow Y Data flow T
=X+Y+Z = X or Y or Z
Data flow Z Data flow Z

Các sơ đồ DFD mức thấp hơn
◼ Nhằm chi tiết hóa các quá trình còn mang tính tổng
quát, chưa thể dùng để thiết kế thành các thành
phần trong chương trình như: form, report, …
Một số quy tắc:
◼ ID của process trong sơ đồ con sẽ bao gồm ID của
sơ đồ cha + số thứ tự của process trong sơ đồ con
◼ VD: Khi phân rã process 2, thì các process trong sơ
đồ con sẽ được đánh số là 2.1, 2.2, 2.3, …
◼ Mỗi sơ đồ DFD (kể cả mức 0) chỉ nên có từ 7 – 9
process, và vẽ trên một trang giấy.

Tính phân mức (leveling)
◼ Là quá trình tăng dần mức độ chi tiết trong các sơ
đồ ở mức thấp hơn cho đến khi đạt được mức chi
tiết mong muốn, tức là tất cả các process trong sơ
đồ đều là nguyên tố (primitive process)
◼ Process nguyên tố là process chỉ còn bao gồm một
chức năng cụ thể, không thể tiếp tục phân rã được
nữa. Process này có thể chuyển giao để lập trình
viên viết chương trình.
◼ Cần tổ chức sơ đồ tránh tình trạng một process
phân rã quá sâu trong khi các process khác thì
việc phân rã lại dừng rất sớm

Tính cân bằng (balancing)
◼ Khi phân rã phải đảm bảo sự nhất quán giữa các
sơ đồ
◼ Các dòng dữ liệu vào và dòng dữ liệu ra của sơ đồ
cha phải được bảo toàn trong sơ đồ con

Vấn đề kho dữ liệu
◼ Kho dữ liệu có thể xuất hiện trong sơ đồ con mà
không cần xuất hiện trước đó trong sơ đồ cha. Đây
là trường hợp các kho dữ liệu cục bộ, chỉ có các
process trong sơ đồ con sử dụng mà thôi.

Một số vấn đề khác
1 2 Process "Xử lý
Khách hàng Đơn đặt ĐĐH đã ĐĐH" sau khi
hàng Xử lý duyệt Lập hóa
ĐĐH đơn duyệt đơn xong
sẽ gọi process
"Lập hóa đơn" để
thực hiện ngay
Process "Xử lý ĐĐH"

sau khi duyệt đơn
1 2
Đơn đặt
xong, chỉ lưu đơn đặt
Khách hàng
hàng Xử lý Lập hóa hàng đã duyệt lại.
ĐĐH đơn
Process "Lập hóa đơn"
sẽ đọc dữ liệu trong
kho để thực hiện sau
D1 Đơn đặt hàng này khi được gọi

Phân tích bottom-up
◼ Một số phân tích viên sử dụng chiến lược bottom-
up. Theo cách này ta sẽ nhận diện tất cả các
process nguyên tố, các kho dữ liệu, các dòng dữ
liệu và các thực thể ngoại.
◼ Sau đó ta sẽ nhóm các thành phần có quan hệ lại
với nhau để tạo thành các sơ đồ ở mức thấp
◼ Tiếp tục nhóm các sơ đồ mức thấp lại để tạo dần
thành các sơ đổ mức cao hơn.
◼ Tiến trình này được tiếp tục thực hiện cho đến khi
ta đạt được mức 0, rồi mức ngữ cảnh.

DFD luận lý và DFD vật lý
Đặc điểm Logical Physical
thiết kế
Mô hình mô Hoạt động nghiệp vụ Hệ thống sẽ cài đặt (hoặc
tả gì? như thế nào? đang vận hành) như thế nào?
Process thể Hoạt động nghiệp vụ Chương trình, module và các
hiện gi? thủ tục xử lý thủ công
Data store Các dữ liệu trong hệ Các tập tin vật lý và CSDL
thể hiện gì? thống, không quan
tâm cách lưu trữ
Loại data Các dữ liệu lưu trữ lâu Tập tin chính, tập tin giao
store dài trong hệ thống dịch, …
Kiểm soát Quan tâm các kiểm Quan tâm cả sự kiểm soát
hệ thống soát về nghiệp vụ tính hợp lệ của dữ liệu đầu
vào, bảo mật hệ thống, …
DFD luận lý
Customer D1 Price Customer
Items to Prices
purchase Payment Receipt
1 2 3 4
Items ID Compute Settle
Look Up Items and Amount Transaction
Identify Total Cost
Prices prices to be and Issue
Item of Order paid Receipt

DFD vật lý
UPC Price Temporary

D1 D2
Customer File Trans. File Customer
Items description Items prices
UPC
and Prices and subtotals
Items to code
purchase Items and Cash, Check Cash Register
Prices or Debit Card Receipt
1 2 3 4
UPC Settle
Pass Items Bar Code Look Up Items and Compute Amount Transaction
over scanner Prices Total Cost
prices to be and Issue
(manual) of Order paid Receipt

Từ điển dữ liệu
(Data Dictionary)

Chương 5: Từ điển dữ liệu Slide 1
Từ điển dữ liệu (Data Dictionary)
◼ Từ điển dữ liệu (DD) dùng để lưu các mô tả chi tiết
về các thành phần trong các sơ đồ được xây dựng
trong quá trình phân tích.
◼ Đây là kho trung tâm chứa tất cả các mô tả về hệ
thống. Từ đây có thể tạo ra nhiều báo cáo hữu ích
về hệ thống
◼ Trong các CASE tool các mô tả này thường chứa
trong một kho gọi là data repository

Cần lập tài liệu cho:
◼ Các dòng dữ liệu
◼ Các kho dữ liệu
◼ Cấu trúc dữ liệu (data structure) của các mẩu tin

◼ Các phần tử dữ liệu (data item)
◼ Các quy trình xử lý
◼ Các thực thể ngoại

Từ điển dữ liệu và DFD các mức
◼ Các thành phần trong từ điển dữ liệu sẽ thay đổi
theo mức của sơ đồ DFD tương ứng
◼ Từ điển dữ liệu được tạo theo cách tiếp cận từ
trên xuống
◼ Có thể dùng để kiểm tra tính cân bằng giữa DFD
mức trên và DFD mức dưới
◼ Trong CASE tools, từ điển dữ liệu là nơi chứa
thông tin để các công cụ sinh ra cơ sở dữ liệu và
các chương trình máy tính


Ví dụ
D1 Khách hàng
1
Đơn đặt hàng
Khách hàng Duyệt đơn
đặt hàng
D2 DM hàng hóa

Mô tả dòng dữ liệu
Bảng mô tả dòng dữ liệu

Số hiệu: 1 Tên: Đơn đặt hàng
Mô tả: Thông tin trên đơn đặt hàng do khách hàng gởi đến
Nguồn: Khách (Entity) Đích: xử lý đơn đặt hàng (Process)
Loại dòng dữ liệu:

 File  Screen  Report  Form  Internal
Cấu trúc dữ liệu: Đơn đặt hàng Tần suất: 100 đơn / ngày
Ghi chú: Có thể điền vào mẫu quy định, hoặc gởi qua fax, qua trang web của
công ty

Mô tả kho dữ liệu
Bảng mô tả kho dữ liệu
Số hiệu: D3 Tên kho: Đơn đặt hàng
Mô tả: Đơn đặt hàng của khách. Chỉ lưu các đơn hàng đã được chấp nhận
Các đặc trưng của kho
Loại :  Computer  Manual
Dạng:  Database  Indexed  Sequential  Direct
Kích thước mẫu tin: 200 (ký tự)
Số lượng mẫu tin: tối đa: 45 000 trung bình: 20 000
Tăng trưởng hàng năm: 6%
Cấu trúc dữ liệu: Đơn đặt hàng
Ghi chú: Chỉ lưu các đơn hàng trong năm. Cuối mỗi năm, các đơn hàng đã hoàn tất việc giao
hàng trong năm đó, sẽ được chép sang một tập tin khác (tập tin lịch sử) để lưu trữ, và xóa các
mẫu tin này đi trong kho đơn đặt hàng.

Mô tả cấu trúc dữ liệu
◼ Dùng để mô tả sự kết hợp của các thành phần dữ
liệu trong dòng dữ liệu (hoặc kho dữ liệu)
◼ Mô tả dựa vào các biểu mẫu thực tế đã thu thập
◼ Thường dùng các ký hiệu sau:
= Bao gồm
+ Và (and)
() Tùy chọn (option)
{ }𝑚
𝑛 Lặp lại từ m đến n lần
[] Chọn một trong các trường hợp (or)
| Dấu phân cách các chọn lựa

Ví dụ: mẫu đơn đặt hàng
Công ty An Hòa
123 Lý Thái Tổ, Q1, Tp.HCM
---oOo---
ĐƠN ĐẶT HÀNG

- Tên khách hàng: MSKH:
- Địa chỉ:
- Điện thoại:
STT Mã Tên hàng Đơn vị Số Đơn Thành tiền

hàng tính lượng giá
Phương thức giao hàng Tổng cộng:

 Khách nhận hàng tại kho Ngày …….tháng ……. năm …….
 Giao đến địa chỉ của khách Người đặt hàng
(ký tên)

Ví dụ về mô tả cấu trúc dữ liệu
Khách hàng Đơn đặt hàng
= mã khách hàng = mã số đơn đặt hàng
+ tên khách hàng + ngày đặt hàng
+ địa chỉ + thông tin khách hàng
+ (số điện thoại) + phương thức giao hàng
+ loại khách + { dòng chi tiết đơn đặt hàng }
+ định mức nợ + trị giá đơn đặt hàng
+ còn nợ
Dòng chi tiết đơn đặt hàng
Loại khách = mã số hàng hóa
=[A|B|C] + tên hàng hóa
+ số lượng
DM hàng hóa + đơn giá
= mã hàng hóa + thành tiền
+ tên hàng hóa
+ đơn vị tính Phương thức giao hàng
+ (ảnh) = [ Khách nhận hàng tại kho |
+ giá bán hiện tại giao đến địa chỉ của khách]

Mô tả thành phần dữ liệu
Bảng mô tả thành phần dữ liệu
Số hiệu: Tên: mã khách hàng
Mô tả: Tất cả các khách hàng của công ty đều được cấp một mã số để phân biệt. Khách sử
dụng mã này trong tất cả các giao dịch với công ty
Các đặc trưng của thành phần dữ liệu

Data type :  Character  Number  DateTime
Length: 6 Dec _______________________  Base
Input Format: 9(6) Output Format: 9(6)  Derived
Default value: __________________________________________________
Các ràng buộc dữ liệu:

_____________________________________________________
_____________________________________________________
Ghi chú: Mã khách sẽ được hệ thống cấp tự động mỗi khi cập nhật thông tin một khách
hàng mới

Mô tả thành phần dữ liệu
◼ Các ký hiệu dùng để mô tả định dạng (Format):
◼ X: Đại diện cho một ký tự bất kỳ
◼ 9: Đại diện cho một ký số
◼ Z: Hiển thị cả các số không ở bên trái của số
◼ . , / - v.v… : Các ký hiệu phân cách
◼ Việc mô tả cấu trúc dữ liệu của các kho dữ liệu,
cũng như mô tả các thành phần dữ liệu chính là cơ
sở để ta thiết kế cơ sở dữ liệu sau này.
◼ Việc mô tả các dòng dữ liệu còn giúp ta kiểm tra lại
tình chính xác của các lược đồ. Ví dụ phát hiện
các lỗ xám trong sơ đồ DFD
Đặc tả quy trình xử lý

(Process Specification)

◼ PS - Process Specification
◼ Là công cụ mô tả các quy trình xử lý bên trong của
một process trong sơ đồ DFD.
◼ Mục đích của PS là mô tả chính xác về nghiệp vụ
xử lý, tránh sự hiểu biết không rõ ràng, không đầy
đủ về một nghiệp vụ
◼ Có thể dùng mô tả quá trình nguyên tố cũng như
các quá trình xử lý ở mức trên

◼ Lưu ý: không phải mọi process đều phải đặc tả PS.
Người ta có thể không đặc tả cho các process sau:
◼ Process chỉ thực hiện việc nhập / xuất kho dữ liệu
(đọc/ghi file)
◼ Process chỉ thực hiện việc kiểm tra đơn giản về
tính hợp lệ của dữ liệu
◼ Process đã được lập trình rồi, nay chỉ sử dụng lại
(gọi hàm/ thủ tục thư viện)

Bảng đặc tả quy trình xử lý
Số hiệu: 1 Tên: Xử lý đơn đặt hàng
Mô tả: Tiếp nhận và kiểm tra đơn đặt hàng của khách. Nếu chấp nhận sẽ lưu
vào kho đơn đặt hàng
Dòng dữ liệu vào: Dòng dữ liệu ra:
• Đơn đặt hàng (khách gởi đến) • Đơn đặt hàng (lưu vào kho ĐĐH)
• TT hàng hóa (lấy từ kho TT hàng • TT hàng hóa (cập nhập kho TT Hàng
hóa) hóa)
Loại quá trình: Tên thủ tục / hàm sử dụng:
 Online  Batch  Manual ______________________________
Logic xử lý
(mô tả logic xừ lý bằng một trong các cách ở các slide sau)
Ghi chú:
Ta có thể mô tả logic xử lý của các quá trình bằng
các cách sau:
◼ Lưu đồ (Flow Chart)
◼ Tiếng Anh có cấu trúc (Structured Enghlish)
◼ Bảng quyết định (Decision Table)
◼ Cây quyết định (Decision Tree)
◼ …

Một số ký hiệu dùng trong Flow chart
Bắt đầu/
kết thúc
Nối đến 1
A5 trang khác
Công việc
Gọi một flow Nối trong

chart khác 1 cùng 1 trang
Nhập/ xuất
Các đường
tiến trình
Điều kiện

Lưu đồ (flow chart)
Cần cải tiến gì
trên lưu đồ này?
Nhận đơn đặt hàng
No Chấp nhận
Còn chi tiết ĐĐH? ĐĐH
Yes
Đọc 1 dòng chi tiết ĐĐH
Kiểm số lượng tồn của mặt

hàng này trong kho hàng hóa
No Yes
SL đặt > SL tồn? Từ chối ĐĐH

Tiếng Anh có cấu trúc (Structured English)
◼ Tập con của tiếng Anh chuẩn: sử dụng một số từ
vựng quy ước.
◼ Tương tự như viết mã giả (pseudo code)
◼ Sử dụng các cấu trúc điều khiển như:
◼ Cấu trúc rẽ nhánh
IF <condition> THEN
<statement 1>
[ELSE
<statement 2>]
END IF

Tiếng Anh có cấu trúc (structured English)
◼ Cấu trúc chọn
DO CASE
CASE <value 1> : <statement 1>
…
CASE <value n> : <statement n>
[ELSE <statement n+1>]
END CASE
◼ Cấu trúc lặp:
DO WHILE <condition>
<statement>
END WHILE
Ví dụ (cách tính hoa hồng)

Bảng quyết định (Decision Table)
◼ Cho thấy cấu trúc luận lý để ra quyết định trong
trường hợp phức tạp có nhiều điều kiện phối hợp
◼ Tất cả các trường hợp phối hợp giữa các điều kiện
đều được xác định → không bị sót tình huống
◼ Lập trình viên có thể dựa vào các mô tả này để
viết chương trình

Bảng quyết định (Decision Table)
Bảng được chia thành 4 vùng:
▪ Góc trên bên trái là các điều kiện (conditions)
▪ Góc dưới bên trái là các hành động (actions)
▪ Góc trên bên phải là sư phối hợp của các điều
kiện, gọi là các luật (rule)

▪ Góc dưới bên phải là sự chọn lựa hành động
tương ứng với các luật

Conditions Condition Alternatives
Actions Actions Entries

Ví dụ (tính hoa hồng)
PAY COMMISSION 1 2 3 4
EXTRA BONUS Y Y N N
PAYMENT TOTAL > $50,000 Y N Y N
Add 2% to COMMISSION PERCENT X
Add 1% to COMMISSION PERCENT X X
Output SPECIAL LETTER X X
Output AWARD LIST X X

Các bước xây dựng bảng quyết định
◼ B1: Xác định các điều kiện có thể có cho khối trên
bên trái
◼ B2: Xác định các hành động có thể chọn lựa cho
khối dưới bên trái
◼ B3: Xác định khả năng lựa chọn cho mỗi điều kiện.
◼ Trường hợp đơn giản, mỗi điều kiện chỉ có 2 lựa
chọn: Yes hay No → có 2n cột (luật)

◼ Mỗi điều kiện cũng có thể có nhiều chọn lựa

Các bước xây dựng bảng quyết định
◼ B4: Xác định tất cả các trường hợp phối hợp giữa
các điều kiện để tạo thành các luật (rule), mỗi luật
tương ứng với một cột ở khối trên bên phải.
◼ B5: Loại bỏ các luật mâu thuẫn, dư thừa, trùng lắp
◼ B6: Xác định cách chọn hành động cho từng luật
(tương ứng từng cột)
◼ B7: Thu gọn bảng quyết định (nếu được)

Ví dụ (tính chiết khấu)
Công ty K. có chính sách chiết khấu như sau:
◼ Tổng giá trị đơn hàng (công ty khuyến khích đặt
đơn hàng lớn thay vì đặt nhiều đơn hàng nhỏ vì dễ
phân phối và lập thời biểu vận chuyển): tiền chiết
khấu là 3% đối với các đơn hàng trên 5000$
◼ Nếu giao hàng trong vòng 50km sẽ được chiết
khấu 2% (do giảm chi phí phân phối)
◼ Trong trường hợp đã chiết khấu 3% (quy tắc 1) sẽ
chỉ chiết khấu 1% nếu giao hàng trong vòng 50Km

◼ Khách hàng đạt 100000$ (tổng tiền hàng mua
trong vòng 12 tháng qua) sẽ được chiết khấu thêm

2%
◼ Có 3 yếu tố ảnh hưởng đến chính sách:
◼ Tổng giá trị đơn hàng >5000$ không? (Y/N)
◼ Giao hàng < 50km không? (Y/N)
◼ Doanh thu đạt >= 100000$ chưa? (Y/N)
◼ Tương ứng với 3 điều kiện
◼ Mỗi điều kiện có 2 chọn lựa
◼ Có 23 = 8 cách phối hợp (luật)
◼ Có các mức chiết khấu: 1%, 2%, 3%
◼ Tương ứng với 3 hành động

Đơn hàng > 5000$ Y Y Y Y N N N N

Giao hàng < 50km Y Y N N Y Y N N
Doanh thu >= 100000$ Y N Y N Y N Y N
Chiết khấu 1% (giao hàng) x x
Chiết khấu 2% (giao hàng) x x
Chiết khấu 2% (doanh thu) x x x x
Chiết khấu 3% (đơn hàng) x x x x
Tổng hợp chiết khấu (%) 6 4 5 3 4 2 2 0

Thu gọn cột bảng quyết định
◼ Trong trường hợp có một số cột có cùng hành
động, các cột này có chung 1 số điều kiện; một
điều kiện khác lại không ảnh hưởng gì tới quyết
định này → dùng dấu '-' để đánh dấu
1 2 3 4 5 6 7 8
Điều kiện 1 Y Y Y Y N N N N
Điều kiện 2 Y Y N N Y Y N N
Điều kiện 3 Y N Y N Y N Y N
Hành động 1 x x x
Hành động 2 x x x x x

Thu gọn cột bảng quyết định
1 2 3 4 5 1 2 3 4
Điều kiện 1 Y Y N N N Y - N N
Điều kiện 2 Y N Y Y N Y N Y Y
Điều kiện 3 - - Y N - - - Y N
Hành động 1 x x x x
Hành động 2 x x x x x

Thu gọn hàng bảng quyết định
Trong một số trường hợp ta có thể xác định nhiều
chọn lựa cho một điều kiện (thay vì dùng Y/N) →
có thể giàm số hàng trong bảng quyết định
Đơn hàng < 1000$ Y Y Y Y N N N N
1000 <= Đơn hàng < 2000$ Y Y N N Y Y N N
2000 <= Đơn hàng Y N Y N Y N Y N
mâu thuẫn(loại)
Đơn hàng: A B C
Thu gọn + A: <1000$
hàng và cột + B: Từ 1000$ đến <2000$
+ C: Từ 2000$ trở lên
Cây quyết định (Decision tree)
◼ Biểu diễn dưới dạng đồ họa các chọn lựa để ra
quyết định
◼ Dễ hiểu và dễ xây dựng
◼ Được sử dụng để đặc tả cho các quá trình có cấu
trúc rẽ nhánh phức tạp, hoặc thứ tự thực thi của
các quyết định là quan trọng (bảng quyết định khó
diễn tả trong trường hợp này)

Cây quyết định (Decision tree)
Các bước xây dựng:
◼ Nhận diện tất cả các điều kiện và hành động
◼ Sắp xếp hành động và điều kiện theo thời gian
◼ Bắt đầu xây dựng từ trái sang phải. Sử dụng các
ký hiệu:
 : biểu diễn cho một hành động
 : biểu diễn cho một điều kiện
◼ Ở mỗi node phải xét tất cả các trường hợp có thể
xảy ra trước khi xét qua node kế (thứ tự thực thi
rất quan trọng)

Ví dụ
Quy trình bán hàng trong siêu thị:
◼ Nếu trị giá hàng <=50$ và khách trả tiền mặt thì
lập hóa đơn bán hàng; nếu khách trả bằng thẻ tín
dụng thì phải kiểm tra bằng thiết bị của siêu thị,
nếu hợp lệ thì bán hàng, nếu không hợp lệ thì giữ
lại và báo ngay với ban lãnh đạo
◼ Nếu trị giá hàng >50$ và khách trả tiền mặt thì lập
hóa đơn bán hàng; nếu trả bằng thẻ tín dụng thì
phải kết nối với ngân hàng để kiểm tra, nếu hợp lệ
thì bán hàng, nếu không hợp lệ thì giữ lại và báo
ngay với ban lãnh đạo

Ví dụ
Lập hóa đơn
3
Lập hóa đơn

2 6
Kiểm tra
4 thẻ 5
1 Báo BLĐ
7
Lập hóa đơn

9
Lập hóa đơn

8 12
Kết nối
10 11
ngân hàng
kiểm tra
Báo BLĐ
13

Tổng kết về PS
Cần chọn phương pháp thích hợp xây dựng PS:
◼ "Structured English" thích hợp khi logic quá trình
có vòng lặp hoặc sự liên hệ với người dùng là
quan trọng
◼ "Decision Table" thích hợp với logic có cấu trúc
điều kiện phức tạp hoặc để kiềm soát tránh các dư

thừa, mâu thuẫn
◼ "Decision Tree" thích hợp khi thứ tự thực thi của
các điều kiện là quan trọng

Cách tiếp cận 4 mô hình
Đưa vào các
Hệ thống hiện tại Hệ thống mới yêu cầu của
người dùng
Mức Hiểu hệ thống cũ Xác định hệ thống
luận lý đang làm gì? mới sẽ làm gì?
Mức Hiểu hệ thống cũ Xác định hệ thống mới

vật lý hoạt động thế nào? sẽ hoạt động ra sao?
Mô hình vật lý của HT hiện tại → Mô hình luận lý của HT hiện tại
→ Mô hình luận lý của HT mới → Mô hình vật lý của HT mới
Cách tiếp cận này cho phép ta nắm bắt tốt các chức năng
của hệ thống hiện tại trước khi thực hiện thay đổi
Tuy nhiên sẽ tốn thời gian và chi phí
Chương 5
Mô hình hóa
hướng đối tượng

Chương 5: mô hình hóa hướng đối tượng Slide 1
UML - Unified modeling language
◼ UML là ngôn ngữ mô hình hóa thống nhất bao
gồm những ký hiệu hình học, dùng mô hình hóa
trong phương pháp hướng đối tượng.
◼ UML dùng để:
◼ Trực quan hóa (Visualizing)
◼ Đặc tả (Specifying)
◼ Xây dựng (Constructing)
◼ Lập tài liệu (Documenting)
◼ UML còn được dùng làm công cụ giao tiếp giữa
người dùng, nhà phân tích, nhà thiết kế và nhà
phát triển phần mềm.
Lịch sử phát triển của UML
UML 2.0 (2004)
UML 1.5 (2003)
UML 1.3 (99)
UML 1.2 (98)
Chuẩn hoá bởi OMG UML 1.1 (11- 97)
UML 1.0 (1- 97)
UML 0.9 (96)
UML 0.8 (95) Các thành viên công nghiệp

OOSE (HP, IBM,Oracle, Microsoft,
Rational,…)
Booch OMT Các phương pháp khác

Các sơ đồ (diagram) của UML
UML 1.x có 9 loại Sơ đồ:
1. Sơ đồ Use case (Use Case Diagram)
2. Sơ đồ lớp (Class Diagram)
3. Sơ đồ đối tượng (Object Diagram)
4. Sơ đồ trạng thái (State Diagram)
5. Sơ đồ trình tự (Sequence Diagram)
6. Sơ đồ cộng tác (Collaboration Diagram)
7. Sơ đồ hoạt động (Activity Diagram)
8. Sơ đồ thành phần (Component Diagram)
9. Sơ đồ triển khai (Deployment Diagram)
UML 2.0 có 13 loại Sơ đồ:
Thêm các sơ đồ:
◼ Sơ đồ gói (Package Diagram)
◼ Sơ đồ cấu trúc đa hợp (Composite Structure Diagram)
◼ Sơ đồ tương tác tổng quát (interaction overview Diagram)
◼ Sơ đồ thời gian (Timing Diagram)
Ngoài ra:
◼ Sơ đồ trạng thái (statechart diagram) đổi tên thành sơ đồ
máy trạng thái (state machine diagram)
◼ Sơ đồ cộng tác (collaboration diagram) đổi tên lại là sơ đồ
giao tiếp (communication diagram)

Các sơ đồ được phân thành 2 nhóm:
◼ Nhóm sơ đồ cấu trúc (Structure Diagram):
◼ Sơ đồ lớp (Class Diagram)

◼ Sơ đồ đối tượng (Object Diagram)
◼ Sơ đồ thành phần (Component Diagram)
◼ Sơ đồ cấu trúc đa hợp (Composite Structure
Diagram)
◼ Sơ đồ triển khai (Deployment Diagram)
◼ Sơ đồ gói (Package Diagram)

◼ Nhóm sơ đồ hành vi (Behaviour Diagram)
◼ Sơ đồ Use case (Use Case Diagram)
◼ Sơ đồ hoạt động (Activity Diagram)
◼ Sơ đồ máy trạng thái (State Machine Diagram)
◼ Nhóm sơ đồ tượng tác (Interaction Diagram):
◼ Sơ đồ trình tự (Sequence Diagram)
◼ Sơ đồ giao tiếp (Comunication Diagram)
◼ Sơ đồ tương tác tổng quát (interaction overview Diagram)
◼ Sơ đồ thời gian (Timing Diagram)

Các góc nhìn (view) của UML
◼ Góc nhìn (view) chỉ ra những khía cạnh khác nhau
của hệ thống cần phải được mô hình hóa.
◼ Một góc nhìn không phải là một bản vẽ, mà là một
sự trừu tượng hóa bao gồm nhiều sơ đồ khác
nhau
◼ Mỗi góc nhìn sẽ chỉ ra một khía cạnh riêng biệt của
hệ thống, nhờ đó người ta có thể xây dựng nên
một bức tranh hoàn chỉnh về hệ thống.
◼ Mỗi nhóm người có liên quan đến hệ thống sẽ tập
trung chú ý vào một góc nhìn nào đó mà thôi

Các góc nhìn (view) của UML
Góc nhìn thiết kế Góc nhìn thực thi

(Logical view) (Component view)
Góc nhìn
use case
Góc nhìn quá trình Góc nhìn triển khai

(Concurrency view) (Deployment view)
Trần Quang
Chương 5: mô hình hóa hướng đối tượng Slide 5Môn:
- PTTKHT
Slide 10
Góc nhìn Use case (use case view)
◼ Là góc nhìn từ ngoài vào hệ thống.
◼ Đây là góc nhìn dành cho khách hàng, nhà thiết kế, nhà
phát triển, người kiểm thử. Nó mô tả các chức năng mong
đợi mà hệ thống phải đáp ứng cho người dùng
◼ Được mô tả qua các sơ đồ Use case (use case diagram)
và thỉnh thoảng cả các sơ đồ hoạt động (activity diagram).
◼ Góc nhìn Use case mang tính trung tâm. Hệ thống phải
cung cấp các chức năng mô tả trong góc nhìn này → có
ảnh hưởng đến tất cả các góc nhìn khác
◼ Góc nhìn này còn được sử dụng để thẩm tra (verify) hệ
thống xem có đúng với mong đợi của khách hàng ( "Đây có
phải là thứ bạn muốn?") cũng như có đúng với hệ thống đã
hoàn thành ("Hệ thống có hoạt động như đã đặc tả?”).
Góc nhìn thiết kế
◼ Còn gọi là góc nhìn logic (logical view)
◼ Chủ yếu dùng cho các nhà thiết kế và nhà phát triển.
◼ Đây là góc nhìn vào bên trong hệ thống. Nó chỉ ra chức năng
sẽ được thiết kế bên trong hệ thống như thế nào
◼ Nó mô tả cấu trúc tĩnh (lớp, đối tượng, và quan hệ) cũng như
sự tương tác động sẽ xảy ra khi các đối tượng gửi thông điệp
cho nhau để cung cấp chức năng đã định sẵn.
◼ Cấu trúc tĩnh được mô tả bằng các sơ đồ lớp (class diagram)
và sơ đồ đối tượng (object diagram).
◼ Cấu trúc động được mô tả trong các sơ đồ trạng thái
(statechart diagram), sơ đồ trình tự (sequence diagram), sơ
đồ tương tác (collaboration diagram), sơ đồ hoạt động
(activity diagram)
Góc nhìn quá trình
◼ Còn gọi là góc nhìn song hành (Concurrency View)
◼ Phản ánh các lộ trình điều khiển, các quá trình
(process) thực hiện, nó cho thấy sự hoạt động
song hành hay đồng bộ của hệ thống
◼ Góc nhìn này dành cho nhà phát triển và người
tích hợp hệ thống
◼ Bao gồm các sơ đồ động như: sơ đồ trạng thái
(statechart diagram), sơ đồ trình tự (sequence
diagram), sơ đồ cộng tác (collaboration diagram)
và sơ đồ hoạt động (activity diagram)

Góc nhìn thực thi
◼ Còn gọi là góc nhìn thành phần (Component view)
◼ Là góc nhìn đối với dạng phát hành của hệ thống vật
lý, bao gồm các thành phần và tập tin độc lập, được
lắp ráp theo các cách để tạo ra hệ thống chạy được.
◼ Thành phần ở đây là các module thuộc nhiều loại khác
nhau, sẽ được chỉ ra trong sơ đồ cùng với cấu trúc
cũng như sự phụ thuộc của chúng.
◼ Nó thường được sử dụng cho nhà phát triển và
thường bao gồm nhiều sơ đồ thành phần.
◼ Được thể hiện bằng các sơ đồ thành phần
(Component diagram)

Góc nhìn triển khai
◼ Góc nhìn triển khai (Deployment View) chỉ cho
chúng ta sơ đồ triển khai về mặt vật lý của hệ
thống, ví dụ các máy tính cũng như sự liên kết
giữa chúng với nhau.
◼ Góc nhìn triển khai dành cho các nhà phát triển,
người tích hợp cũng như người thử nghiệm hệ
thống và được thể hiện bằng các sơ đồ triển khai
(deployment diagram).
◼ Góc nhìn này cũng bao gồm sự ánh xạ các thành
phần của hệ thống vào cấu trúc vật lý; ví dụ như
chương trình nào hay đối tượng nào sẽ được thực
thi trên máy tính nào.
UML và chu trình phát triển phần mềm
Giai đoạn nghiên cứu sơ bộ:
◼ UML đưa ra khái niệm Use Case để nắm bắt các yêu
cầu của người sử dụng.
◼ Sơ đồ Use case (Use Case Diagram) dùng để mô tả
mối quan hệ cũng như sự giao tiếp với hệ thống.
◼ Trong sơ đồ Use case, các tác nhân (Actor) bên ngoài
quan tâm đến hệ thống sẽ được mô hình song song với

chức năng mà họ đòi hỏi từ hệ thống (tức Use case)
◼ Mỗi Use case trong tài liệu sẽ đặc tả yêu cầu của người
dùng: người dùng chờ đợi điều gì từ hệ thống mà

không để ý đến chức năng này sẽ được thực thi ra sao

Giai đoạn phân tích:
◼ Giai đoạn phân tích quan tâm đến việc trừu tượng hóa
◼ Phân tích viên tìm ra các lớp thành phần và mối quan hệ
giữa chúng → mô tả bằng sơ đồ lớp (class diagram)

◼ Sự cộng tác giữa các lớp nhằm thực hiện các Use case
cũng sẽ được mô tả nhờ vào các mô hình động
(dynamic models) của UML.
◼ Trong giai đoạn phân tích, chỉ các lớp tồn tại trong phạm
vi nghiệp vụ cần giải quyết (lớp phân tích) là được mô
hình hóa. Các lớp kỹ thuật cũng như giải pháp trong hệ
thống phần mềm, ví dụ các lớp giao diện người dùng,
v.v..., chưa cần quan tâm trong giai đoạn này.
Giai đoạn thiết kế:
◼ Kết quả của giai đoạn phân tích sẽ được mở rộng
thành các giải pháp kỹ thuật.
◼ Các lớp thiết kế được bổ sung để tạo thành hạ
tầng kỹ thuật: giao diện người dùng, các chức
năng để giao tiếp với các hệ thống khác, v,v....
◼ Giai đoạn thiết kế sẽ đưa ra kết quả là bản đặc tả
chi tiết (specification) dùng để xây dựng hệ thống.

Giai đoạn xây dựng:
◼ Trong giai đoạn xây dựng (lập trình), các lớp của giai
đoạn thiết kế sẽ được chuyển thành những dòng code

cụ thể trong một ngôn ngữ lập trình hướng đối tượng
cụ thể
◼ Khi tạo ra các mô hình phân tích và thiết kế trong
UML, cần tránh việc ngay lập tức biến đổi các mô hình
này thành các dòng code.
◼ Trong các giai đoạn trước, mô hình được sử dụng để
hiểu rõ ràng hệ thống, dễ giao tiếp và tạo nên cấu trúc

của hệ thống. Nếu vội vàng sa vào việc viết code có
thể sẽ gây trở ngại cho việc xây dựng mô hình chính
xác và đầy đủ.
Giai đoạn kiểm thử:
◼ Một hệ thống thường được thử nghiệm qua nhiều giai
đoạn và với nhiều nhóm thử nghiệm khác nhau
◼ Các nhóm sử dụng các loại sơ đồ UML khác nhau làm
nền tảng cho công việc của mình:

◼ Kiểm thử đơn vị (unit test) sử dụng sơ đồ lớp (class
diagram) và đặc tả lớp
◼ Kiểm thử nghiệm tích hợp (integration test) thường sử
dụng sơ đồ thành phần (component diagram) và sơ đồ
cộng tác (collaboration diagram)
◼ Kiểm thử hệ thống (system test) sử dụng sơ đồ Use
case (use case diagram) để đảm bảo hệ thống hoạt
động đúng như đã được định nghĩa từ ban đầu.
An overview of
UML diagrams
showing how
each diagram
leads to the
development
of other UML
diagrams

Sơ đồ Use case (Use Case Diagram)
◼ Sơ đồ Use case chỉ ra các tác nhân ngoài và mối liên hệ
giữa chúng với các Use case mà hệ thống cung cấp
◼ Một Use case là diễn tả một chức năng mà hệ thống có khả
năng cung cấp.
◼ Mỗi Use case có thể được đặc tả (ngoài sơ đồ) bằng một
văn bản, hay bằng một sơ đồ hoạt động
◼ Các Use case được miêu tả duy nhất theo hướng nhìn từ
ngoài vào của các tác nhân (hành vi của hệ thống theo như
sự mong đợi của người sử dụng)
◼ Các Use case chỉ đề cập hệ thống làm gì (WHAT) chứ
không mô tả chức năng được cung cấp sẽ hoạt động nội
bộ bên trong hệ thống ra sao (HOW)

Online shopping use case diagram

The Use-Case Diagram for Appointment System

Sơ đồ hoạt động (Activity Diagram)
◼ Sơ đồ hoạt động chỉ ra luồng dịch chuyển từ hành động
này sang hành động khác.
◼ Thường sử dụng để mô tả các hoạt động được thực hiện
trong một thủ tục, một use case. Cũng có thể dùng để mô
tả các dòng chảy giữa các Use case
◼ Sơ đồ hoạt động bao gồm các trạng thái hành động, chứa
đặc tả của một hoạt động cần phải được thực hiện (một
hành động - action). Một trạng thái hành động sẽ qua đi khi
hành động được thực hiện xong
◼ Sơ đồ còn có thể chỉ ra các quyết định, các điều kiện, cũng
như phần thực thi song song của các trạng thái hành động.
◼ Sơ đồ còn có thể chứa đặc tả cho các thông điệp được gửi
đi / nhận về giữa các thành phần của hành động
Business flow activity to process purchase order

Sơ đồ lớp (Class Diagram)
◼ Sơ đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống. vì
cấu trúc được mô tả luôn luôn đúng tại bất kỳ thời điểm nào
trong vòng đời hệ thống
◼ Lớp là đại diện cho các sự vật được xử lý trong hệ thống.
◼ Các lớp có thể quan hệ với nhau theo nhiều cách:
◼ Liên kết (associated - được nối kết với nhau),
◼ Phụ thuộc (dependent - một lớp này phụ thuộc vào lớp khác)
◼ Chuyên biệt hóa (specialized - một lớp này là một kết quả
chuyên biệt hóa của lớp khác)
◼ Đóng gói (packaged - hợp với nhau thành một đơn vị).
◼ Tất cả các mối quan hệ đó đều được thể hiện trong sơ đồ
lớp, cùng với cấu trúc bên trong của mỗi lớp, gồm thuộc
tính (attribute) và tác vụ (operation).
Sơ đồ đối tượng (Object Diagram)
◼ Giống như sơ đồ lớp. Sự khác biệt là sơ đồ đối tượng
chỉ ra các đối tượng thực thể của lớp, thay vì các lớp.
◼ Sơ đồ đối tượng là một bức tranh của hệ thống ở một
thời điểm nào đó (snapshot).
◼ Sơ đồ đối tượng dùng chung các ký hiệu của sơ đồ lớp,
trừ hai điểm: tên đối tượng được gạch dưới và tất cả
các kết nối cụ thể trong mối quan hệ đều được vẽ ra
◼ Sơ đồ đối tượng không quan trọng bằng sơ đồ lớp
◼ Sơ đồ đối tượng ít dùng, thường được dùng làm nền
cho sơ đồ cộng tác (collaboration / comunacation), nó
chỉ ra lối ứng xử động giữa các đối tượng.

User login controller UML object diagram

Sơ đồ trình tự (Sequence Diagram)
◼ Sơ đồ trình tự chỉ ra trình tự các thông điệp
(message) được gửi giữa các đối tượng dọc theo
trục thời gian
◼ Sơ đồ trình tự chứa một loạt các đối tượng được
biểu diễn bằng các đường thẳng đứng.
◼ Trục thời gian có hướng từ trên xuống dưới trong
sơ đồ, và sơ đồ chỉ ra sự trao đổi thông điệp giữa
các đối tượng khi thời gian trôi qua.
◼ Các thông điệp được biểu diễn bằng các đường
gạch ngang gắn liền với mũi tên (biểu thị thông
điệp) nối liền giữa những đường thẳng đứng thể
hiện đối tượng.
Sơ đồ giao tiếp (communication diagram)
◼ Tên cũ là sơ đồ cộng tác (Collaboration Diagram)
◼ Chỉ ra một sự cộng tác động, tương tự như sơ đồ trình tự
◼ Bên cạnh việc thể hiện sự trao đổi thông điệp (được gọi là
tương tác), sơ đồ còn chỉ ra các đối tượng và quan hệ của
chúng (được gọi là ngữ cảnh).
◼ Việc nên sử dụng sơ đồ trình tự hay sơ đồ giao tiếp thường
được quyết định theo nguyên tắc chung sau:
◼ Nếu thời gian hay trình tự là yếu tố quan trọng nhất cần
phải nhấn mạnh thì hãy chọn sơ đồ trình tự

◼ Nếu ngữ cảnh là yếu tố quan trọng hơn, chọn sơ đồ
giao tiếp
◼ Trình tự tương tác giữa các đối tượng được thể hiện trong
cả hai loại sơ đồ này.
Communication diagram for online bookshop

Sơ đồ máy trạng thái (State Machine Diagram)
◼ Tên cũ là sơ đồ trạng thái (State chart Diagram)
◼ Sơ đồ trạng thái thường là sự bổ sung cho đặc tả của
một lớp. Nó chỉ ra tất cả các trạng thái mà đối tượng
của lớp này có thể có, và những sự kiện (event) nào
sẽ gây ra sự thay đổi trạng thái
◼ Sự thay đổi trạng thái được gọi là dịch chuyển trạng
thái (State Transition). Có thể có một hành động liên
quan, xác định điều gì phải được thực hiện khi sự
chuyển đổi trạng thái này diễn ra.
◼ Sơ đồ trạng thái không cần phải vẽ cho tất cả các lớp,
mà chỉ những lớp mà đối tượng của nó có khả năng
ứng xử trước các sự kiện xảy đến tùy thuộc vào trạng
thái hiện tại của nó
Sơ đồ thành phần (Component Diagram)
◼ Sơ đồ thành phần chỉ ra cấu trúc vật lý của chương trình
dưới dạng các thành phần, và mối quan hệ giữa chúng
◼ Sơ đồ thành phần dùng trình bày góc nhìn thực thi của hệ
thống, được sử dụng trong việc lập trình cụ thể
◼ Một thành phần có thể là một tập tin nguồn (source code),
thành phần nhị phân (binary), thực thi (executable)
◼ Một thành phần chứa các thông tin về các lớp logic hoặc
các lớp mà nó thi hành, như thế có nghĩa là nó tạo ra một
ánh xạ từ góc nhìn logic vào góc nhìn thành phần.
◼ Thành phần cũng có thể được mô tả với bất kỳ loại giao
diện nào mà chúng bộc lộ, ví dụ giao diện OLE/COM, có
thể được nhóm lại với nhau thành từng gói (package)

Online shopping UML component diagram with
three related subsystems –
WebStore, Warehouses, and Accounting
Sơ đồ triển khai (Deployment Diagram)
◼ Sơ đồ triển khai trình bày kiến trúc vật lý của phần
cứng cũng như phần mềm trong hệ thống. Nó chỉ ra
từng máy tính cụ thể và từng trang thiết bị cụ thể (node)
và sự nối kết giữa chúng
◼ Bên trong các nút mạng (node), các thành phần thực thi
được (EXE) cũng như các đối tượng sẽ được xác định
vị trí để chỉ ra những phần mềm nào sẽ được thực thi
tại những nút mạng nào. Ta cũng có thể chỉ ra sự phụ
thuộc giữa các thành phần.
◼ Sơ đồ triển khai chỉ ra góc nhìn triển khai, mô tả kiến
trúc vật lý thật sự của hệ thống. Đây là góc nhìn rất
khác cách mô tả duy chức năng của góc nhìn Use case

Sơ đồ triển khai (Deployment Diagram)

Chương 6
Chuyển tiếp sang
giai đoạn thiết kế hệ thống

Chương 6: Chuyển tiếp sang giai đoạn thIết kế Slide 1
Nội dung
◼ Đánh giá chọn lựa giải pháp
◼ Mua sản phẩm có sẵn (package)
◼ Tự xây dựng (in-house)
◼ Các bước cần làm khi chọn giải pháp mua
◼ Các bước tiếp theo khi chọn giải pháp tự xây dựng
◼ Tổng quát giai đoạn thiết kế hệ thống

Đánh giá các giải pháp phần mềm
◼ Kết thúc giai đoạn phân tích → phát triển đầy đủ mô hình
logic của hệ thống dự kiến sẽ hình thành.
◼ Trước khi chuyển sang giai đoạn thiết kế người ta sẽ phải
đánh giá chọn lựa giải pháp thực hiện:
◼ In-house software: Tự phát triển bởi đội ngũ IT trong công ty
(phần mềm tự phát triển)
◼ Software package: Mua hoặc thuê từ các nhà cung cấp phần
mềm (phần mềm đóng gói)
◼ Có nhiều yếu tố ảnh hưởng đến quyết định này, trong đó
quan trọng là tổng chi phí sở hữu (TCO)

Đánh giá các giải pháp phần mềm

Một số thuật ngữ
◼ Software vendor: Công ty chuyên phát triển phần mềm để
bán.
◼ Value-added reseller (VAR): Công ty chuyên hiệu chỉnh các
sản phẩm phần mềm thương mại để bán lại theo các yêu
cầu riêng của từng khách hàng.
◼ Horizontal application: Các phần mềm tổng quát được sử
dụng cho nhiều loại hình công ty khác nhau. vd: phần mềm
kế toán, nhân sự,…
◼ Vertical application: Các phần mềm được sử dụng đặc thù
cho một loại hình doanh nghiệp (tổ chức). vd: phần mềm
thanh toán quốc tế trong ngân hàng

Các lý do để tự phát triển phần mềm
◼ Thỏa mãn các yêu cầu riêng của công ty:
◼ Sản phẩm đóng gói thường không đáp ứng được
◼ Hạn chế việc phải thay đổi các quy trình nghiệp vụ hoặc chính
sách kinh doanh:
◼ Nếu thay đổi quá nhiều người ta chọn giải pháp tự phát triển
◼ Đáp ứng yêu cầu giao tiếp với HT đang tồn tại
◼ Ví dụ hệ thống nhân sự phải giao tiếp được với hệ thống kế toán đang
hoạt động
◼ Phù hợp với công nghệ đang sử dụng tại công ty:
◼ Đang sử dụng phần cứng, công nghệ cũ, chưa thể nâng cấp → không thể
sử dụng các sản phẩm thương mại
◼ Phát triển nguồn lực nội bộ:
◼ Tạo lợi thế cạnh tranh, đáp ứng nhanh các tình huống khác nhau

Các lý do để mua phần mềm đóng gói
◼ Chí phí thấp
◼ Thời gian triển khai nhanh hơn
◼ Độ tin cậy và hiệu suất đã được kiểm chứng
◼ Đội ngũ nhân viên kỹ thuật cần ít hơn
◼ Nhận được sự nâng cấp sau này từ phía nhà cung cấp phần
mềm
◼ Chia sẻ được kinh nghiệm từ các công ty khác cùng sử
dụng phần mềm này

Mua và hiệu chỉnh gói phần mềm
Có 3 cách chọn lựa:
◼ Mua gói phần mềm cơ bản + các tùy chọn (option) cho phù
hợp với yêu cầu
◼ Thương lượng với nhà cung cấp phần mềm để họ chỉnh
sửa, mở rộng theo yêu cầu
◼ Mua gói phần mềm và tự hiệu chỉnh. Chọn cách này khi gói
phần mềm đã đáp ứng hầu hết yêu cầu

Lưu ý: việc hiệu chỉnh gói phần mềm có thể làm mất đi các ưu
điểm của việc mua gói phần mềm, như chi phí sẽ cao hơn,
thời gian triển khai kéo dài, độ tin cậy có thể giảm đi, việc
nâng cấp khi có phiên bản mới cũng không còn thuận lợi

Các giải pháp khác
◼ Nhà cung cấp dịch vụ ứng dụng (Application Service
Provider - ASP)
◼ ASP cho thuê các ứng dụng, được cung cấp dưới dạng các
dịch vụ
◼ Phía người sử dụng không cần phải thiết kế, cài đặt, bảo trì
phần mềm
◼ Dịch vụ do ASP cung cấp gọi là apllication hosting service
◼ ASP là một xu hướng hiện nay. Microsoft xem phần mềm như
là một dịch vụ (software as a service) → hosting các ứng dụng

◼ Outsourcing:
◼ Sử dụng các công ty bên ngoài (gọi là service provider) để xử
lý tạm thời hoặc lâu dài một phần công việc của công ty
◼ Nhiều công ty xem đây là một cách để giảm chi phí đầu tư cho
CNTT và có thể tiếp cận nhanh với sự thay đổi về công nghệ
◼ Thông tin nội bộ được ra ngoài cho nhà cung cấp dịch vụ →
cần có sự tin cậy
◼ Thích hợp với công ty mà khối lượng công việc bị dao động
thường xuyên → không phải lo lắng việc phải tuyển thêm
nhân viên IT trong giai đoạn cao điểm, rồi phải cho nghỉ trong
thời điểm ít việc

◼ Ứng dụng của người sử dụng (user application):
◼ Yêu cầu của người dùng đôi khi có thể thỏa mãn bằng cách
sử dụng các ứng dụng do người dùng tự phát triển
◼ Cài đặt các công cụ quen thuộc (như Microsoft Office), sau đó
bộ phận IT hỗ trợ việc kết nối vào hệ thống và trợ giúp người
dùng tự tạo ra các báo cáo, các form nhập liệu, …
◼ Thường ứng dụng dạng lại này rất uyển chuyển, tính thân
thiện cao
◼ Trong một số tính huống đây lại là giải pháp đơn giản, khá
hữu hiệu và ít tốn kém

Công việc của PTV ở các bước kế
◼ Công việc của PTV ở các bước tiếp theo sẽ phụ thuộc
vào việc chọn giải pháp mua hay tự phát triển
◼ Nếu chọn giải pháp tự phát triển: ta sẽ tiếp tục chuyển sang
thiết kế, … theo trình tự SDLC
◼ Nếu chọn giải pháp mua: thực hiện các bước chuẩn bị cho
việc mua sắm (procurement)
◼ Nếu chọn mua và hiệu chỉnh: thực hiện các bước mua sắm,
tuy nhiên phải đặc tả rõ ràng các hiệu chỉnh → một phần
của công việc thiết kế

Công việc của PTV ở các bước kế

Các bước để mua gói phần mềm
B1: Xác định các yêu cầu HTTT
B2: Xác định các nhà cung cấp phần mềm có năng lực
B3: Đánh giá các giải pháp phần mềm
B4: Thực hiện việc mua phần mềm
B5: Cài đặt phần mềm

◼ Nhận diện các tính năng chính của hệ thống
◼ Các CSF phải được thể hiện đầy đủ
◼ Ước lượng khối lượng hiện tại và sự gia tăng của hệ thống
trong tương lai
◼ Xác định khối lượng giai dịch và xử lý hiện tại
◼ Dự đoán sự thay đổi cho 3 – 5 năm tới
◼ Xác định các ràng buộc về phần cứng
◼ Ràng buộc về phần cứng hiện tại
◼ Các yêu cầu về nâng cấp hoặc đầu tư mới

◼ Chuẩn bị hồ sơ mời thầu
◼ RFP (Request For Proposal): là văn bản viết chính thức gởi
cho các nhà cung cấp, mô tả đầy đủ các tính năng yêu cầu
(thường khi ta chưa xác định sản phẩm hay gói phần mềm
nào sẽ dùng). Dựa vào văn bản này các nhà cung cấp sẽ
chuẩn bị hồ sơ dự thầu với các giải pháp và sản phẩm của họ
◼ RFQ (Request For Quotation): tương tự như RFP nhưng dùng
trong trường hợp ta đã xác định được sản phẩm, chủ yếu yêu
cầu chào giá

B2: Xác định các nhà cung cấp
◼ Liên hệ với các nhà cung cấp có năng lực
◼ Cần lưu ý đối với nhà quản lý đây là một sự đầu tư
◼ Cần quan tâm đến khả năng bảo trì và nâng cấp hệ thống sau
này
◼ Gởi RFP (hoặc RFQ) cho họ
◼ Việc xác định các nhà cung cấp có thể dựa vào:
◼ Các công ty tư vấn về CNTT
◼ Những người đã sử dụng các phần mềm tương tự
◼ Các báo, tạp chí có uy tín
◼ …

B3: Đánh giá lựa chọn
◼ Đánh giá từng phần hồ sơ dự thầu
◼ Chấm điểm và xếp hạng cho từng hạng mục. Thang điểm
đã được lập lúc chuẩn bị hồ sơ mời thầu. Thường có 3
phương pháp hay sử dụng:
◼ Xếp hạng theo giá trị tương đối so sánh với mục đó của
những người khác (vd: hạng 1,2,3,…)
◼ Sử dụng thang tỷ lệ cố định từ 0 đến 10. Tất cả các hạng mục
được xếp chỗ trên thang tỷ lệ mà không xét số lượng người
tham gia dự thầu
◼ Phương pháp nhị phân (1: đáp ứng, 0: không)

B3: Đánh giá lựa chọn
◼ Thường đánh giá trên các tiêu chí:
◼ Kỹ thuật
◼ Quản lý (kế hoạch, nhân sự, tính huống, …)
◼ Tài chánh
◼ Thông tin về công ty (công việc quá khứ, …)
◼ Một số việc thực hiện khi đánh giá
◼ Tìm hiểu thêm thông tin về những người đã dùng phần mềm
này
◼ Chạy thử nghiệm chương trình
◼ Kiểm tra Benchmark

B4: Mua phần mềm
◼ Khi mua phần mềm → ta không là sở hữu chủ của phần
mềm, mà chỉ mua bản quyền sử dụng (software license)
◼ Cần lưu ý license của các phần mềm khác có sử dụng trong
phần mềm ta mua (Vd: Phần mềm quản lý nhân sự dùng
Oracle → license của Oracle?)
◼ Có thể thực hiện thuê phần mềm → hợp đồng thuê (lease
agreement)
◼ Cần quan tâm thương lượng các hợp đồng bảo trì
(maintenace agreement)

B5: Cài đặt phần mềm
◼ Thời gian cài đặt phụ thuộc vào kích cỡ và độ phức tạp của
hệ thống
◼ Chiến lược cài đặt cần hoạch định trước, tránh không làm
ảnh hưởng nhiều đến công việc nghiệp vụ hàng ngày của
công ty
◼ Chuẩn bị đầy đủ các việc:
◼ Cấu hình hệ thống
◼ Đào tạo người sử dụng
◼ Chuyển đổi dữ liệu
◼ …

Nhóm đánh giá và lựa chọn giải pháp
◼ Đa số các công ty chọn lựa giải pháp phối hợp: một số phần
mềm mua, số khác bộ phận IT tự phát triển, một phần do
người dùng xây dựng → cần có PTV và cả người dùng tham
gia vào nhóm đánh giá và chọn lựa
◼ Mục tiêu của việc chọn lựa là có được sản phẩm với chi phí
thấp nhất
◼ Các đánh giá (được cho điểm và xếp hạng) sẽ chuyển cho
các nhà quản lý để có quyết định cuối cùng

Hoàn tất việc phân tích hệ thống
◼ Hoàn chỉnh hồ sơ phân tích
◼ Hồ sơ đặc tả các yêu cầu hệ thống cần được tổ chức và định
dạng tốt → phải dễ đọc, dễ sử dụng
◼ SRD - System Requirements Document
◼ SRS - Software Requirements Specification)
◼ Tài liệu này trở thành một phần trong hợp đồng → sau này
được sử dụng để đánh giá, nghiệm thu hệ thống
◼ Trình bày cho ban quản lý
◼ Ban quản lý có thể quyết định chọn lựa một giải pháp để
tiếp tục thực hiện hoặc dừng dự án

Chuyển sang giai đoạn thiết kế
◼ Khi bắt đầu chuyển sang thiết kế, ta phải đảm bảo không
còn mơ hồ và thiếu sót về bất kỳ điều gì trong hệ thống sắp
xây dựng (chỉ mang tính tương đối)
◼ Thiết kế luận lý (logical design) sẽ xác định các đặc điểm,
chức năng và mối quan hệ của các thành phần trong hệ
thống → còn gọi là essential model
◼ Thiết kế vật lý (physical design) là các bản mô tả cách thức
cài đặt, thực hiện hệ thống

Cân đối các yếu tố khi thiết kế
◼ Các mục tiêu thiết kế thường mâu thuẫn nhau → cần cân
nhắc để cân bằng chúng
◼ Hệ thống càng dễ sử dụng → lập trình càng phức tạp
◼ Hệ thống càng mềm dẻo → yêu cầu bảo trì càng cao
◼ Thỏa mãn yêu cầu người này → có thể không thỏa mãn được
yêu cầu người khác
◼ Cần cân nhắc giữa chất lượng, chi phí và thời gian
time
quality cost

Nội dung của giai đoạn thiết kế
◼ Thiết kế giao diện người dùng
◼ Thiết kế dữ liệu
◼ Thiết kế kiến trúc hệ thống
◼ Thiết kế chi tiết các module
◼ Thiết kế kiểm soát
Tổng thể
◼ Lập hồ sơ thiết kế Chi tiết
Thiết kế kiến trúc
Thiết kế kiến trúc
Thiết kế dữ liệu
Khía Thiết kế dữ liệu
cạnh
kỹ Thiết kế chức năng
thuật Thiết kế chức năng
Thiết kế thủ tục
Thiết kế kiểm soát

Làm bản mẫu (prototyping)
◼ Bản mẫu (prototype) là một phiên bản (version) của hệ
thống được xây dựng nhanh
◼ Giúp người sử dụng hiểu được hệ thống
◼ Giúp người sử dụng có thể kiểm tra mô hình hệ thống → chấp
nhận hoặc yêu cầu bổ sung, sửa đổi
→ lôi kéo người sử dụng tham gia vào tiến trình phân tích và
thiết kế hệ thống
◼ Sử dụng như một công cụ huấn luyện dần người sử dụng hệ
thống
◼ Giảm được các rủi ro khi triển khai hệ thống

Các cách tiếp cận xây dựng mẫu
Prototype được phát triển thành sản phẩm cuối cùng
Prototype là mô hình được người sử dụng chấp nhận

Một số công cụ xây dựng prototype
◼ Bộ tạo ứng dụng (application generator)

◼ Giúp sinh mã lệnh (code generator) từ các mô hình luận lý.
Các ngôn ngữ được sinh ra tùy hệ thống hỗ trợ như Visual
Basic, Visual C++, C#, Java, …
◼ Bộ tạo báo cáo (report generator)
◼ Bộ tạo màn hình (screen generator)
◼ Còn gọi là form generator
Các công cụ này thường sử dụng từ điển dữ liệu trong
repository của CASE tool để sinh tạo

Một số vấn đề cần lưu ý khi xây dựng prototye
◼ Tốc độ phát triển nhanh có thể phát sinh các vấn đề về

chất lượng
◼ Các yêu cầu như độ tin cậy, khả năng bảo trì, vấn đề
bảo mật có thể không đầy đủ
◼ Các hệ thống phức tạp rất khó quản lý bản mẫu
◼ Bộ phận phát triển thường chịu áp lực rất lớn về tiến độ
thực hiện khi phiên bản đầu tiên đã được đưa ra

Chương 7
Thiết kế nhập xuất
và giao diện người dùng

Chương 7: Thiết kế nhập xuất Slide 1
Nội dung
◼ Nguyên tắc thiết kế giao diện
◼ Các bộ nguyên lý Norman, Nielsen, …
◼ Thiết kế input
◼ Thiết kế output

Giao diện người dùng
◼ Hệ thống có giao diện không tốt, thường dẫn đến thất
bại (dù sản phẩm có nhiều tính năng tốt)
◼ Giao diện không tạo được phương thức giao tiếp đủ tốt
thì người dùng khó điều khiển hệ thống một cách hiệu
quả
◼ Giao diện không tạo đủ sự tin cậy, thì người dùng cũng
ngần ngại khi giao dịch
◼ Vì vậy, nhà thiết kế rất quan tâm đến giao diện và luôn
tìm cách giúp người dùng cảm thấy hài lòng nhất có
thể.

Hệ thống đặt người dùng làm trọng tâm
◼ Hệ thống đặt người dùng làm trọng tâm (User-centered)
◼ Trong các hệ thống trước đây, phòng IT đóng vai trò
trung tâm.
◼ Trong các hệ thống hiên nay, người dùng đóng vai trò
trọng tâm trong quá trình giao tiếp với hệ thống và xử lý
thông tin. Phòng IT chỉ chịu trách nhiệm hỗ trợ
IT User requests
Department For Information
Information
Data Input System
Processing-Centered System

◼ Quản lý thông tin đã được phát triển nhằm tập trung
vào việc truy xuất thông tin của người dùng, thay vì chỉ
đơn giản cung cấp thông tin.
◼ Các trọng tâm chính:
◼ Người dùng ở trong và ngoài công ty
◼ Người sử dụng giao tiếp với HT như thế nào
◼ HT hỗ trợ các hoạt động nghiệp vụ của công ty như thế
nào.

Internal Business
Users Transactions
Information Other
Data Input System Data Input
Customers Suppliers
User-centered System
Tương tác người - máy
◼ Tương tác người – máy (HCI - Human Computer
Interaction)
◼ Mô tả mối quan hệ giữa máy tính và người sử dụng
◼ Các khái niệm HCI áp dụng cho mọi thứ từ máy PC
đến hệ thống mạng toàn cục
◼ Mục tiêu chính là tạo ra thiết kế thân thiện với người
dùng (user friendly), dễ học và dễ sử dụng (easy to
learn and use).

Các nguyên tắc thiết kế
◼ Hiểu biết đầy đủ các nghiệp vụ
◼ Phải hiểu rõ nghiệp vụ, xác định hệ thống sẽ hỗ trợ như
thế nào cho từng cá nhân, phòng ban,…
◼ Có thể bắt đầu từ FDD
◼ Sử dụng tối đa hiệu ứng đồ họa
◼ Nhiều người khuyên rằng nên thiết kế tương tự giao diện
các ứng dụng của Microsoft vì hiệu quả, dễ học
◼ Hiểu rõ đối tượng người dùng
◼ Thường chia 3 cấp (level): Beginner, Intermediate và
Expert

Các nguyên tắc thiết kế
◼ Suy nghĩ theo cách của người dùng
◼ Sử dụng prototye để đạt được sự chấp nhận của người
dùng
◼ Thiết kế giao diện có tính toàn diện
◼ Từ giao diện chính có thể tương tác với các chức năng
trong hệ thống
◼ Tiếp tục quá trình phản hồi
◼ Lập tài liệu thiết kế giao diện

Hướng dẫn thiết kế giao diện
Giao diện thiết kế tốt là sự kết hợp:
◼ Khoa học lao động (Ergonomics): mô tả cách con
người làm việc, học tập và tương tác với máy tính.
◼ Mỹ học (Aesthetics): làm thế nào giao diện hấp dẫn và
dễ sử dụng
◼ Kỹ thuật về giao diện

Hướng dẫn thiết kế giao diện
◼ Để tạo ra các giao diện hiệu quả, người thiết kế phải
tuân thủ một số quy tắc nhất định
◼ Hiện nay có nhiều bộ nguyên tắc thường được áp
dụng:
◼ Bộ nguyên lý Norman
◼ 10 kinh nghiệm của Nielsen (Usability Heuristics)
◼ 16 nguyên tắc Tognazzini (bao gồm cả sự gợi ý và
luật Fitts)

Bộ nguyên lý Norman
◼ Được tạo bởi Donald A. Norman trong lúc nghiên cứu
về vấn đề tương tác giữa con người với máy tính trong
dự án "Design of Everyday Thigns" - DOET.
◼ Thường được các nhà thiết kế sử dụng để tích hợp và
đánh giá xem giao diện mà minh thiết kế có thực sự
hữu ích và giúp cho việc tương tác giữa người với máy
tính dễ dàng hơn hay không.

Bộ nguyên lý Norman
◼ Hoàn tất những yêu cầu từ phía người dùng
◼ Sử dụng cả "Knowledge in the Head" và "Knowledge in
the World“
◼ Đơn giản hóa tác vụ của người dùng
◼ Làm mọi thứ rõ ràng nhất có thể
◼ Thu hẹp khoảng cách thực thi và đánh giá
◼ Sắp xếp một cách đúng đắn
◼ Khai thác sức mạnh từ các biện pháp hạn chế
◼ Thiết kế phải tính đến lỗi
◼ Chuẩn hóa khi cần thiết

Các kinh nghiệm của Nielsen
◼ Được Jakob Nielsen giới thiệu năm 1995
◼ Đây là tập các nguyên lý mà ông đã nghiên cứu và
chứng minh rằng sẽ tốt cho một giao diện khi thiết kế
theo các quy tắc này.
◼ Về cơ bản thì các quy tắc do Nielsen đưa ra cũng khá
giống với bộ nguyên lý Norman trên, chỉ khác một chút
về cách diễn đạt và cách người ta đánh giá nó

Các kinh nghiệm của Nielsen
◼ Phù hợp sự chờ đợi: ◼ Quản lý lỗi

◼ Phù hợp thế giới thực ◼ Tránh lỗi
◼ Nhất quán và chuẩn ◼ Giảm tải những gì người
◼ Trợ giúp và tài liệu dùng cần nhớ
◼ Người sử dụng làm chủ ◼ Thông báo, kiểm tra và
phục hồi lỗi
◼ Người sử dụng điều
khiển UI và tự do ◼ Thiết kế đơn giản
◼ Trực quan trạng thái hệ ◼ Thẩm mỹ và đơn giản
thống
◼ Mềm dẻo và hiệu quả

Phù hợp với thế giới thực
◼ Nguyên tắc “Speak the user’s language”
◼ Tránh từ chuyên môn. Từ chuyên môn có thể sử dụng
khi users là chuyên gia trong lĩnh vực
◼ Khi user được quyền đặt tên trong UI thì họ phải được
tự do lựa chọn tên. Tránh giới hạn độ dài và nội dung.
◼ Giao diện để user nhập lệnh hay từ khóa tìm kiếm, UI
cần hỗ trợ tối đa các từ đồng nghĩa, vì user khác nhau
sẽ gọi đối tượng với các tên khác nhau.

Nhất quán
◼ Còn gọi là “Principle of Least Surprise”
◼ Không được làm users ngạc nhiên với cách mà lệnh và
đối tượng giao diện hoạt động.
◼ Những gì tương tự phải có hình dáng và hành vi tương
tự
◼ Loại nhất quán quan trọng khác là cách diễn đạt thông
qua toàn bộ UI
◼ Nếu dùng cả “share price”, “stock price”, “stock quote” thì
user sẽ do dự về 3 vấn đề khác nhau trong hệ thống

Nhất quán
◼ Nhất quán về thứ tự lệnh và đối số:
◼ Thứ tự danh từ-động từ trong GUI: user chọn đối tượng
sau đó chọn lệnh tác động trên đối tượng.
◼ Thứ tự động từ-danh từ: kích hoạt lệnh trước sau đó
chọn đối số
◼ Các loại nhất quán
◼ Nhất quán trong: nhất
quán ngay trong ứng dụng
◼ Nhất quán ngoài: nhất quán
giữa các ứng dụng cùng platform.

◼ Nhất quán ẩn dụ: nhất quán
trong việc chọn ẩn dụ

Trợ giúp và tài liệu
◼ Người dung thường không đọc trợ giúp và tài liệu cho
đến thời điểm trước khi sử dụng.
◼ Cẩm nang sử dụng và hướng dẫn trực tuyến là quan
trọng.
◼ Trợ giúp cần phải có các khả năng sau
◼ Tìm kiếm theo chủ đề
◼ Phù hợp ngữ cảnh
◼ Hướng nhiệm vụ
◼ Cụ thể
◼ Ngắn gọn

Người sử dụng làm chủ
◼ Nguyên tắc “Clearly Marked Exits”
◼ Phải cung cấp khả năng Undo
◼ Các thao tác cần nhiều thời gian thì phải có khả năng
hủy (cancelable)
◼ Tất các các hộp thoại nên có phím Cancel.

Trực quan trạng thái hệ thống
◼ Nguyên tắc “Feedback”
◼ Luôn thông báo Users về trạng thái của hệ thống.
◼ Các dấu hiệu (idioms)
◼ Thay đổi hình dạng con chạy
◼ Highlight.
◼ Thanh trạng thái và chỉ báo (progress).
◼ Không nên cài đặt “dày đặc” phản hồi
◼ Ví dụ hộp thoại không phù hợp.

Trực quan trạng thái hệ thống
◼ Khuyến cáo sử dụng
◼ Hành động < 0.1s, cảm giác xảy ra tức thì
◼ Hành động xảy ra trong khoảng 0.1-1.0s, người sử
dụng nhận ra hành động nhưng không cần phản hồi

◼ Hành động trong khoảng 1-5s, hiển thị “busy”
◼ Hành động kéo dài trên 5s, hiển thị Progress bar

Mềm dẻo và hiệu quả (Efficiency)
◼ Tạo “Shortcuts”
◼ Cần cung cấp các “đường tắt” để thực hiện các thao
tác thường xuyên
◼ Phím lệnh cấp tốc (Ctrl+C, Ctrl+B, Ctrl+O...)
◼ Viết tắt dòng lệnh
◼ Style
◼ Bookmarks
◼ Lịch sử thực hiện

Tránh lỗi
◼ Tránh lỗi
◼ Chọn bằng chuột thay vì nhập bàn phím.
◼ Ẩn các lệnh không cần thiết
◼ Các loại lỗi chính
◼ Lỗi mô tả: xảy ra khi hai hành động tương tự nhau
◼ Lỗi thu hút: khi hai hành động có giai đoạn bắt đầu khởi
động như nhau
◼ Lỗi phương thức: ví dụ với text editor vi, ở insert mode,
các phím ký tự được chèn vào tập tin văn bản, trong khi
ở command mode (mặc định), phím ký tự kích hoạt
editing commands.

Thông báo lỗi
◼ Chính xác: ví dụ không dùng “Cannot open file”, mà
nên sử dụng “Cannot open file named paper.docx”
◼ Nói bằng ngôn ngữ của người sử dụng
◼ Đưa ra hỗ trợ mang tính xây dựng. Tại sao xảy ra, loại
bỏ bằng cách nào.
◼ Lịch sự: không sử dụng “fatal error” và “illegal”

Giảm tải những gì người dùng cần nhớ
◼ Nguyên tắc “Minimize Memory Load”
◼ Sử dụng thực đơn, không sử dụng dòng lệnh
◼ Sử dụng Combo Box, không sử dụng Text Box nơi
chọn lệnh
◼ Sử dụng những lệnh chung những nơi có thể (ví dụ

Open, Save, Copy Paste)
◼ Tất cả các thông tin cần thiết phải được nhìn thấy.

Thẩm mỹ và đơn giản
◼ Nguyên tắc “Less is More”.

◼ Bỏ đi các thông tin, đặc trưng đồ họa và các tính chất
xa lạ, không cần thiết.
◼ Lựa chọn màu và font phù hợp
◼ Nhóm bằng dấu cách
◼ Gán các điều khiển hợp lý
◼ Sử dụng ngôn ngữ phù hợp, bố trí hợp lý

Sự đơn giản
◼ Sự hoàn thiện đạt được khi không còn gì để bổ sung và
không còn gì đáng phải bỏ đi
(Antoine de St-Exupery)
◼ Nguyên tắc "When in doubt, leave it out"
◼ Nguyên tắc "Keep it simple, stupid" (KISS)
◼ Các kỹ thuật để đạt được sự đơn giản
◼ Sự rút gọn (Reduction)
◼ Tính đều (Regularity)
◼ Nhiệm vụ kép (Double-Duty)

Nguyên tắc phối màu 60-30-10
◼ Luật 60 - 30 -10 là công cụ hiệu quả khi bạn sáng tạo
các ý tưởng thiết kế nhất là kết hợp với bánh xe màu,
nó làm màu sắc trở lên đẹp và hài hòa
◼ Trang trí một đối tượng với ba màu sắc khác nhau
thường tạo ra ấn tượng tốt về thị giác, mỗi màu sắc đã
mang trong nó một ý nghĩa và khi kết hợp với nhau tạo
ra sự đa dạng.

Nguyên tắc phối màu 60-30-10
◼ Với ba màu người ta thường phân ra:

Sự cân bằng về màu sắc
Khi phối màu nên chọn:

- Màu chủ đạo (Sd): dùng màu tint
- Màu cấp 2 (Ss): dùng màu tone
- Màu nhấn (Sa): dùng màu thuần khiết

Sự hài hòa của màu sắc
◼ Ngoài sự cân bằng màu áp dụng quy luật 60 - 30 - 10
trên, để đạt hiệu quả hơn cần thêm sự hài hòa giữa các
màu sắc với nhau.
◼ Sự hài hòa có được khi ta chọn màu theo các quy tắc
của bánh xe màu như đối xứng bổ sung, tam giác, tứ
giác màu ...

Phân biệt UX và UI
User Experience Design User Interface Design
(Thiết kế trải nghiệm (Thiết kế giao diện
người dùng ) người dùng)

Responsive Web Design
◼ Là xu hướng mới theo đó quy trình thiết kế và phát
triển web sẽ đáp ứng mọi thiết bị và môi trường của
người dùng theo các tiêu chí kích thước và chiều của
màn hình thiết bị.
◼ Để làm được điều đó chúng ta sẽ kết hợp linh hoạt kết
hợp các kỹ thuật flexible grid, responsive image và
CSS media query.
◼ Khi người dùng chuyển từ máy tính xách tay của họ
sang iPad hay iPhone, trang web sẽ tự động chuyển
đổi để phù hợp với kích thước màn hình và kịch bản xử
lý

Responsive Web Design
◼ Trang web sẽ tự động đáp ứng theo thiết bị của người
dùng. Ta không phải thiết kế nhiều trang web khác
nhau, do đó giảm thời gian cũng như chi phí thiết kế
web.

Single Page Application (SPA)
◼ Sử dụng SPA rất hiệu quả và tiết kiệm băng thông,
cũng như cho trải nghiệm người dùng tốt hơn
◼ Một số trang web sử dụng SPA: Google Maps, Gmail,
Facebook, GitHub, …
Bắt đầu duyệt web
Trả về trang HTML đơn giản bao

gồm layout, css, js, …
Gởi request AJAX cho yêu cầu chuyển trang
Trả về chỉ dữ liệu cần thiết của trang đó

Single Page Application (SPA)
◼ Với website truyền thống, toàn bộ trang web phải
load lại mỗi khi chuyển trang.
◼ Với SPA, khi duyệt lần đầu thì toàn bộ resource của
web bao gồm các file CSS, Javascript, master layout
hay cấu trúc web page sẽ được load.
◼ Ở những lần sau, khi chuyển trang client sẽ gửi
những ajax request để chỉ lấy nội dung dữ liệu cần
thiết. Việc này giúp giảm thời gian phải load lại toàn
bộ trang web, tiết kiệm băng thông cũng như thời
gian chờ.

Sketch - Wireframe - Mockup - Prototype
◼ Sketch là phác thảo nhanh
những ý tưởng của mình hoặc
đang brainstorming với nhóm.
Thường hay dùng bút lông vẽ
lên bảng trắng để trao đổi.
◼ Wireframe là bước kế tiếp, nó
chính xác bộ khung của UI.
Chưa cần quan tâm đến màu
sắc, font chữ, hiệu ứng; quan
trọng là cấu trúc và nhóm
thông tin mà nó thể hiện. Sử
dụng công cụ vẽ trực quan
như Balsamiq.
◼ Mockup thể hiện chi tiết hơn wireframe cả về màu sắc,
vị trí field, font chữ, hình ảnh,… thậm chí cả validation
của các trường dữ liệu. Wireframe chỉ thể hiện bố cục,
cấu trúc của màn hình là chủ yếu.

◼ Prototype có thể xem là “mẫu thử đầu tiên” của phần
mềm. Người dùng có thể tương tác trực tiếp như nhấn
nút, kéo thả, … Điều này giúp người dùng hình dung rõ
hơn về sản phẩm họ sẽ nhận được.
◼ Cần lưu ý Prototype khác với khái niệm bản beta là bản
đầy đủ chức năng, đã có thể sử dụng của một sản
phẩm. Còn prototype chỉ là phần mẫu thử trông "như
hàng thiệt” của sản phẩm.

Chương 8
Thiết kế cơ sở dữ liệu

Chương 8: ThIết kế cơ sở dữ liệu Slide 1
Nội dung
◼ Các mức thiết kế cơ sở dữ liệu
◼ ERD / Class Diagram
◼ Vấn đề chuẩn hóa dữ liệu
◼ Chỉ mục
◼ Vấn đề lưu trữ cơ sở dữ liệu ở mức vật lý
◼ Thiết kế hệ thống mã

Giới thiệu
◼ Cơ sở dữ liệu là nơi lưu trữ lâu dài dữ liệu của hệ
thống, phục vụ các chức năng của hệ thống.
◼ Dữ liệu phải được tổ chức tốt dựa trên hai tiêu chuẩn:
◼ Hợp lý: đầy đủ để cho các chức năng sử dụng, nhưng
cũng không được thừa
◼ Truy cập thuận lợi: tức là phải hỗ trợ tốt cho các chức
năng cập nhật, tìm kiếm, …

Các mức thiết kế CSDL
Mô hình mức Sơ đồ thực thể _

ý niệm liên kết (ERD)
Mô hình mức Lược đồ CSDL

luận lý quan hệ
Mô hình mức Lược đồ CSDL cụ

vật lý thể trên 1 DBMS
(Sinh viên xem lại môn CSDL)

Thiết kế dữ liệu ý niệm
◼ Sau giai đoạn phân tích, về mặt dữ liệu ta đã biết

những gì cần phải lưu trữ trong hệ thống (dựa trên
các kho dữ liệu trong DFD) và từng thành phần dữ
liệu của mỗi kho (cấu trúc dữ liệu của mỗi kho)
◼ Phân tích cấu trúc kho (data strucure) và các
đường truy nhập trong sơ đồ DFD → từ đó xây
dựng sơ đồ ERD

Sơ đồ DFD
D1 Khách hàng
1
Đơn đặt hàng
Khách hàng Duyệt đơn
đặt hàng
D2 DM hàng hóa

Cấu trúc dữ liệu các kho
Khách hàng Đơn đặt hàng

= mã khách hàng = mã số đơn đặt hàng
+ tên khách hàng + ngày đặt hàng
+ địa chỉ + thông tin khách hàng
+ {số điện thoại} + {dòng chi tiết đơn đặt hàng }
DM hàng hóa Dòng chi tiết đơn đặt hàng

= mã hàng hóa = mã số hàng hóa
+ tên hàng hóa + tên hàng hóa
+ đơn vị tính + số lượng
+ giá bán hiện tại + đơn giá
+ thành tiền

Xây dựng sơ đồ ERD
MSKH Tên khách MSĐH Ngày ĐH
Địa chỉ Khách ? Thông Đơn hàng

tin khách
Số ĐT Dòng chi tiết
ĐVT Đơn giá
MSHH ? MSHH Tên HH
Tên HH Hàng hóa Thành

tiền
ĐVT Giá bán

Xây dựng sơ đồ ERD
MSKH Tên khách MSĐH Ngày ĐH
Địa chỉ Khách Đặt Đơn hàng
Số ĐT
Đơn giá
Thành tiền
Có CTiết
MSHH ĐVT
Tên HH Hàng hóa
ĐVT Giá bán

CSDL ở mức logic
◼ KHÁCH (MSKH, TênKH, ĐịaChỉ)
◼ KHÁCH_ĐTHOẠI (MSKH, SốĐT)
◼ ĐƠN_HÀNG (MSĐH, NgàyĐH, MSKH)
◼ CHI_TIẾT_ĐƠN_HÀNG (MSĐH, MSHH,
SốLượng, ĐơnGiá, ThànhTiền)
◼ HÀNG_HÓA (MSHH, TênHH, ĐVT, Giá)

Chuẩn hóa CSDL
◼ Sau khi xây dựng được lược đồ CSDL, phân tích viên
sẽ tiếp tục tinh chỉnh để bản thiết kế đạt được hiệu suất
cao khi vận hành. Một số vấn đề cân nhắc:
◼ Chuẩn hóa CSDL: tối thiểu phải đạt dạng chuẩn 3
(3NF) → kiểm soát sự dư thừa dữ liệu
◼ Phi chuẩn hóa: là cách làm dư thừa dữ liệu trong thiết
kế nhằm cải thiện hiệu quả truy xuất, thông thường để
giảm bớt các kết nối giữa các bảng khi truy vấn dữ liệu.
Có thể tạo cột dư thừa, bảng dư thừa (trung gian)
◼ Xem lại môn cơ sở dữ liệu

Chuẩn hóa (normalization)
◼ Một lược đồ quan hệ thiết kế chưa tốt có thể dẫn đến
các vấn đề sau:
◼ Sự dư thừa dữ liệu (redundancy)
◼ Dị thường khi thêm vào dữ liệu (insertion anomaly)
◼ Dị thường khi cập nhật dữ liệu (update anomaly)
◼ Dị thường khi xóa dữ liệu (deletion anomaly)
◼ Chuẩn hóa lược đồ quan hệ là quá trình biến đổi lược
đồ thành các dạng có cấu trúc tốt hơn, tạo thuận lợi
cho việc khai thác sau này.

Quá trình chuẩn hóa
4NF
Thiết kế
BCNF
tốt
3NF
2NF
Thiết kế
1NF chưa tốt
Chưa chuẩn

Dạng chuẩn 1 (First Normal Form - 1NF)
◼ Định nghĩa:
◼ Lược đồ R được gọi là đạt dạng chuẩn 1 nếu mọi thuộc
tính của R đều chỉ chứa các giá trị nguyên tố (atomic value)
◼ Tức là lược đồ không còn thuộc tính đa trị (multi-value)
và thuộc tính phức hợp (composite-value)
◼ Ví dụ:
Thuộc tính
phức hợp
MSNV Họ Tên Đơn vị
MSNV Họ Tên Tổ PX
01 An Tổ 1 (PX May)
01 An 1 May
02 Minh Tổ 2 (PX May) 02 Minh 2 May
03 Tuấn Tổ 2 (PX Dệt) 03 Tuấn 2 Dệt
Chưa chuẩn Đã đạt dạng chuẩn 1

Dạng chuẩn 1 (1NF)
MSNV Họ Tên Điện thoại Thuộc tính

đa trị
01 An 8125432; 0903134231
02 Minh
Chưa chuẩn
03 Tuấn 8643214; 8643215
MSNV Họ Tên Điện thoại
01 An 8125432
Đã đạt
01 An 0903134231 dạng chuẩn 1
02 Minh
03 Tuấn 8643214
03 Tuấn 8643215
Dạng chuẩn 2 (Second Normal Form - 2NF)
Phụ thuộc hàm đầy đủ (full functional dependency):
◼ Y phụ thuộc hàm đầy đủ vào X, nếu:
◼ X →Y
◼  X'  X, mà X' →Y
Định nghĩa:
◼ Lược đồ R được gọi là đạt dạng chuẩn 2 nếu:
◼ R đã đạt dạng chuẩn 1
◼ Mọi thuộc tính không khóa của R đều phụ thuộc hàm đầy
đủ vào khóa của R

MSKHO MSHH TênHH SL tồn Đạt 1NF

Chưa đạt 2NF vì:
K1 H1 Bánh 100 + Khóa = {MSKHO, MSHH}
+ MSHH → TênHH
K1 H2 Kẹo 50 (TênHH là thuộc tính không
khóa, mà không phụ thuộc hàm
K2 H1 Bánh 200 đầy đủ vào khóa)
Tách
MSHH TênHH MSKHO MSHH SL tồn
H1 Bánh K1 H1 100 Đã đạt

dạng chuẩn 2
H2 Kẹo K1 H2 50
K2 H1 200

Dạng chuẩn 3 (Third Normal Form - 3NF)
Phụ thuộc hàm bắc cầu:
◼ X→A là phụ thuộc hàm bắc cầu, nếu:
◼ X →Z , nhưng Z →X
◼ Z →A với A  (X  Z)
Định nghĩa:
◼ Lược đồ R được gọi là đạt dạng chuẩn 3 nếu:

◼ Không tồn tại thuộc tính không khóa nào của R phụ
thuộc hàm bắc cầu vào khóa của R

Khóa = {MSHĐ}
MSHĐ NgàyHĐ MSKH TênKH Đạt 2NF
Chưa đạt 3NF vì:
01 1/1/05 K1 An + MSHĐ → MSKH
+ MSKH → TênKH
02 1/1/05 K2 Minh  MSHĐ → TênKH
03 2/1/05 K1 An (TênKH là thuộc tính không
khóa, lại phụ thuộc hàm bắc
Tách cầu vào khóa)
MSKH TênKH MSHĐ NgàyHĐ MSKH
K1 An 01 1/1/05 K1 Đã đạt
dạng chuẩn 3
K2 Minh 02 1/1/05 K2
03 2/1/05 K1

Dạng chuẩn Boyce-Codd (BCNF)
Định nghĩa:
◼ Lược đồ R được gọi là đạt dạng chuẩn BCNF nếu:

◼ Mọi phụ thuộc hàm X→A với A  X thì X là một siêu
khóa cùa R
Ghi chú:
◼ Người ta đã chứng minh nếu R đạt dạng chuẩn Boyce-
Codd, thì R cũng đạt dạng chuẩn 3

Dạng chuẩn Boyce-Codd (BCNF)
Ta có quy tắc:
+ Mỗi SV đăng ký học 1 môn học với 1 giáo viên (MSSV, MônHọc →GV)
+ Mỗi GV chỉ dạy 1 môn học (GV→MônHọc)
Khóa của quan hệ:
K1 = {MSSV, MônHọc} và K2 = {MSSV, GV}
Tất cả các thuộc tính đều là tham gia vào ít nhất 1 khóa → đã đạt 3NF
Chưa đạt BCNF vì có GV→MônHọc, mà GV không phải là một siêu khóa
MSSV MônHọc GV MSSV GV

GV MônHọc
01 M1 G1 01 G1
G1 M1
01 M2 G2 01 G2
G2 M2
02 M1 G3 02 G3
G3 M1
03 M1 G1 03 G1
Chưa đạt BCNF Đã đạt BCNF

Vấn đề phi chuẩn
◼ Việc phi chuẩn có thể dẫn đến sai sót như dữ liệu
không nhất quán. Vì vậy cần tạo thêm cơ chế để kiểm
soát (VD: thiết kế các trigger để kiểm tra ràng buộc
toàn vẹn hay tự động hóa một số công việc)
◼ Việc phi chuẩn nên xem xét trong một số ngữ cảnh
sau:
◼ Dữ liệu thường xuyên được truy vấn, yêu cầu truy xuất
nhanh
◼ Các bảng dữ liệu rất lớn và thường kết nối trong truy vấn
◼ Không phải quan tâm nhiều vấn đề lưu trữ

Vấn đề chỉ mục (index)
◼ Việc tạo chỉ mục giúp cho việc truy cập dữ liệu được
thực hiện nhanh hơn, đặc biệt đối với các bảng dữ liệu
lớn.
◼ Nhược điểm là tốn thêm không gian lưu trữ và thời gian
để bảo trì chỉ mục, mỗi khi dữ liệu trong bảng thay đổi
(thêm, xóa, sửa) → không nên lạm dụng lập chỉ mục
cho tất cả các cột trong bảng
◼ Xem lại môn quản trị cơ sở dữ liệu

Index
Table: NHANVIEN
MS Ten …
Index on Ten
101 Anh …
105 Minh …
#3 An 210 An …
#1 Anh 213 Binh …
#4 Binh
#2 Minh

Index
◼ Vấn đề reindex: mỗi khi có sự cập nhật (thêm, xóa,
sửa), hệ thống sẽ phải cập nhật lại index → làm chậm
hệ thống
Table: NHANVIEN
Index on Ten
MS Ten …
#3 An 101 Anh …
#1 Anh 105 Minh …
#5 Ba 210 An …
#4 Binh 213 Binh …
#2 Minh 316 Ba

Vấn đề chỉ mục (index)
◼ Một số gợi ý khi lập chỉ mục
◼ Khóa chính (primary) sẽ được tự động lập chỉ mục duy
nhất (Unique index)
◼ Lập chỉ mục cho các khóa ngoại (foreign key) để hỗ trợ
khi kết nối giữa các bảng
◼ Tạo chỉ mục cho các cột thường dùng để tìm kiếm, sắp
xếp, nhóm dữ liệu

Thiết kế mức vật lý
Để chuyển sang thiết kế chi tiết dữ liệu ở mức vật lý,
phân tích viên cần có những hiểu biết về:
◼ Cách tổ chức dữ liệu
◼ Đặc điểm của hệ thống tập tin và hệ thống cơ sở dữ
liệu
◼ Các thành phần và kiến trúc của hệ quản trị CSDL chọn
lựa để cài đặt

◼ Kho dữ liệu (data warehouse)
◼ Khai mỏ dữ liệu (data mining)
◼ …

Thiết kế mã
(Code Design)

Thiết kế mã
◼ Mã (code) là một tập hợp các ký tự (ký số) dùng thay
thế cho một dữ liệu.
◼ Lợi ích của mã
◼ Tạo định danh (khóa) duy nhất
◼ Thể hiện đặc tính và mối liên hệ giữa các dữ liệu
◼ Tiết kiệm vùng nhớ lưu trữ
◼ Giảm thời gian và lỗi khi nhập và truyền dữ liệu
◼ Giúp phân loại dữ liệu
◼ Tạo thuận lợi cho việc tìm kiếm
◼ Che dấu thông tin
◼ Thao tác dữ liệu hiệu quả hơn: trộn, sắp thứ tự, …

Các loại mã
Phân loại theo mục đích sử dụng:
◼ Theo dõi, phân biệt
◼ Mã tuần tự (sequence code)

◼ Mã dẫn xuất (derivation code)
◼ Phân loại
◼ Mã phân loại (classification code)
◼ Mã tuần tự khối (block sequence code)

Các loại mã
◼ Che dấu thông tin
◼ Mật mã (cipher code)
◼ Bộc lộ thông tin
◼ Mã với chữ số có nghĩa (significant code / faceted code)
◼ Mã viết tắt (abbreviation code) / mã gợi nhớ (mnemonic
code)
◼ Yêu cầu một tác vụ thích hợp
◼ Mã chức năng (function code / action code)

Mã tuần tự (sequence code)
◼ Là các số (hoặc chữ) lấy theo một thứ tự nào đó
◼ Ưu điểm:
MSNV Họ tên
◼ Đơn giản, dễ sinh mã
0001 Nguyễn văn An
◼ Ngắn và duy nhất
0002 Lê Thị Bình
◼ Nhuợc điểm:
0003 Lý Minh
◼ Không chứa thông tin có ích,
ngoại trừ thứ tự dữ liệu đưa vào hệ thống
◼ Không linh động
◼ Dễ bị tràn nếu thiết kế không cẩn thận

Mã khối tuần tự (block sequence code)
◼ Là sự mở rộng của mã tuần tự. Mỗi khối tương ứng với
một phân lớp dữ liệu
Range Field
000 - 099 General Works List
100 - 199 Philosophy, Psychology, Ethics
Bộ mã phân
200 - 299 Religion, Mythology
loại Dewey
300 - 399 Social Sciences dùng trong thư
400 - 499 Philology viện
500 - 599 Science
600 - 699 Applied Science
700 - 799 Fine Arts
800 - 899 Literature
900 - 999 History, Geography, Biography, Travel

Mã phân loại (category code)
◼ Còn gọi classification code
◼ Tạo nên các nhóm dữ liệu có quan hệ với nhau
◼ Định nghĩa các nhóm phải phù hợp với yêu cầu của
người dùng
◼ Phải cho phép mở rộng khi cần thêm dữ liệu mới
◼ Các mục phải rõ ràng
Mã loại Tên loại
A Giỏi
B Khá
C Trung bình
D Kém

Mã phân loại (category code)
Code Tax Deductible Item
I INTEREST PAYMENTS
M MEDICAL PAYMENTS
T TAXES
C CONTRIBUTIONS
D DUES
S SUPPLIES
S SUBSCRIPTIONS
C COMPUTER Duplicate codes
I INSURANCE
M MISCELLANEOUS
B SUBSCRIPTIONS
P COMPUTER are corrected by “forcing”
N INSURANCE the codes to fit
X MISCELLANEOUS
Cân nhắc khi xảy ra trùng lắp mã

Mã viết tắt (abbreviation code)
◼ Còn gọi mã gợi nhớ (mnemonic code)
◼ Sử dụng các ký tự gợi nhớ dữ liệu đầy đủ
◼ Chỉ sử dụng với lượng dữ liệu nhỏ (dưới 50 mục)
Mã tỉnh Tên tỉnh

LA Long An
AG An Giang
TG Tiền Giang
DN Đồng Nai

Mã ký số có nghĩa (significant digit code)
◼ Được chia thành nhiều khối, mỗi khối có ý nghĩa riêng
◼ Mỗi nhóm số biểu diễn cho một thuộc tính
◼ Cần cân nhắc số lượng ký số cho mỗi nhóm con → dễ
mở rộng cho các dữ liệu mới sau này
◼ Thường tổ chức dạng phân cấp (hierarchical block
code) : khối bên trái có ý nghĩa tổng quát, càng sang
phải càng có tính chi tiết
Mã vùng điện
thoại (ZIP code)

Mã dẫn xuất (derivation code)
◼ Chia thành nhiều vùng, mỗi vùng mang thông tin về
một thuộc tính của dữ liệu

Ưu nhược điểm của mã khối
◼ Ưu điểm:
◼ Chứa nhiều thông tin trong mã
◼ Cấu trúc thuận tiện cho việc khai thác, xử lý
◼ Dễ mở rộng
◼ Nhược điểm:
◼ Chiều dài của mã thường lớn (phụ thuộc số lượng thuộc tính
chứa bên trong)
◼ Cần dự phòng độ rộng của mỗi vùng để mở rộng
◼ Cân nhắc khi khóa là mã khối (vd: mã công chức có chứa
thông tin về đơn vị → khi chuyển đơn vị → ?)

Mật mã (cipher code)
◼ Sử dụng một từ khóa để mã hóa các số
◼ Vd: Cửa hàng dùng từ CAMPGROUND để mã hóa giá
bán sỉ. C → 1, A → 2, …, N →9, D → 0. Như vậy mã
GRAND chỉ giá bán là $562.90

Mã tác vụ (action code)
◼ Chỉ định các tác vụ được thi hành
◼ Vd: F2 → save, F5 → copy, F8 → delete

Mã tự kiểm tra (self-checking code)
◼ Sử dụng ký số để kiểm tra sự hợp lệ của các ký số còn
lại
◼ Có thể giúp phát hiện các lỗi sai khi sao chép hoặc
truyền số liệu

Luhn check (mod 10)
VISA cards start with “4″
MasterCard cards start with “5″
not perfectly divisible

by 10 → invalid

Quá trình thiết kế mã
◼ Xác định dữ liệu cần mã hóa
◼ Ưóc lượng khối lượng dữ liệu
◼ Xác định mục tiêu của mã
◼ Xác định phạm vi sử dụng
◼ Xác định chu kỳ sử dụng
◼ Xác định loại mã

Một số vấn đề lưu ý khi thiết kế mã
◼ Mã nên ngắn gọn
◼ Không tạo mã dài hơn cần thiết
◼ Cho phép mở rộng:
◼ Chuẩn bị sẵn một số vị trí dự phòng trong bộ mã để mở
rộng khi cần thiết
◼ Giữ bộ mã ổn định
◼ Việc thay đổi bộ mã dẫn đến rất nhiều phiền toái
◼ Mã phải duy nhất
◼ Mã dùng để nhận dạng → không được trùng

Một số vấn đề lưu ý khi thiết kế mã
◼ Sử dụng mã có thể sắp thứ tự được
◼ Đôi khi ta phải thêm các số 0 phía trước đề mã có thể
sắp thứ tự được
◼ Tránh mã có thể gây nhầm lẫn
◼ Vd: số không (0) và chữ "O", số một (1) và chữ L thường
( l ) hay chữ "I" hoa, …
◼ Tạo mã có ý nghĩa:
◼ Mã cần dễ nhớ, thuận tiện khi sử dụng
◼ Mỗi mã sử dụng cho một mục đích
◼ Không dùng một mã số cho cả phiếu nhập và phiếu xuất
◼ Giữ cho mã được nhất quán
◼ Vd: mã khách của phòng kinh doanh và phòng kế toán
Chương 9
Thiết kế kiến trúc ứng dụng

Chương 9: Thiết kế kiến trúc ứng dụng Slide 1
Nội dung
◼ Giới thiệu tổng quát
◼ Các kiến trúc thông dụng
◼ Data Warehouse
◼ Data Lake – Data LakeHouse

Phân hệ thống thành các hệ thống con
◼ Mỗi hệ thống con là một nhóm các chức năng của hệ
thống, nhằm giải quyết một vấn đề nào đó.
◼ Sự phân chia hệ thống thành hệ thống con nhằm giảm
bớt sự cồng kềnh, phức tạp của hệ thống → dễ xây
dựng, quản lý, bảo trì →có thể thiết kế, cài đặt độc lập,
song song.
◼ Trên thực tế sự phân chia này đã được thực hiện một
cách tự nhiên trong lúc phân tích
◼ Toàn bộ hệ thống là một thể thống nhất. Các phân hệ
phải tuân theo kiến trúc tổng thể một cách chặt chẽ, có
thể kết nối vào hệ thống một cách dễ dàng

Có nhiều cách nhóm để tạo thành hệ thống con
◼ Theo thực thể - dữ liệu: gom các chức năng liên quan
đến một thực thể nhất định.

◼ Ví dụ: “phân hệ quản lý khách hàng” bao gồm các chức
năng, nhận đơn đặt hàng, lập hóa đơn, thanh toán, …
◼ Theo sự kiện tiến trình nghiệp vụ (giao dịch): gom các
chức năng liên quan đến một giao dịch.
◼ Ví dụ: “phân hệ đăng ký môn học” bao gồm các chức
năng xử lý đăng ký môn học, xử lý đăng ký bổ sung/hủy,
…

◼ Theo các lý do thuận tiện
◼ Tạo thuận lợi cấu trúc kinh doanh
◼ Thích ứng với cấu hình phần cứng đang có
◼ Theo đặc điểm vị trí địa lý
◼ Phân cấp trách nhiệm trong đơn vị
◼ Tạo khả năng bảo mật
◼ Theo cấu trúc sản phẩm hay dòng sản phẩm của công ty
◼ …

Quy trình máy tính và quy trình thủ công
◼ Xác định xem các tiến trình, chức năng nào sẽ được xử
lý bằng máy tính, chức năng nào xử lý thủ công
◼ Sự phân định này có thể được thể hiện bằng đường
ranh giới trên sơ đồ phân tích. Hoặc dùng một ký hiệu
riêng cho các process thủ công
Máy tính Máy tính
Thủ công Thủ công

Thủ công

Quy trình máy tính và quy trình thủ công
◼ Chức năng thủ công cần được mô tả theo yêu cầu:
◼ Nội dung, tiến trình công việc với mục đích cần đạt, các
bước cần tiến hành và các yêu cầu của từng bước
◼ Xác định mức độ chính xác phải đạt
◼ Ấn định mức năng suất cần thiết, mức độ khéo léo và kỹ
năng cần có
◼ Hướng dẫn rõ cách xử lý khi có sai sót
◼ Chức năng được máy tính hóa sẽ được thiết kế chi tiết
trong các thiết kế module và dữ liệu

Lựa chọn kiến trúc ứng dụng
◼ Các mô hình kiến trúc:
◼ Chạy độc lập (stand-alone)
◼ Mô hình khách / chủ (client-server)
◼ Mô hình đa lớp (multi-tier)
◼ SOA, …
◼ Nhận diện các thành phần (component) chính của hệ
thống và cách giao tiếp của chúng với nhau:
◼ Thành phần quản lý dữ liệu (data management)
◼ Thành phần thể hiện dữ liệu (data presentation)
◼ Thành phần xử lý nghiệp vụ (business logic)

Quyết định lựa chọn kiến trúc
1. Có thể sử dụng kiến trúc tổng quát nào không?
2. Hệ thống được phân tán như thế nào?
3. Mẫu kiến trúc nào phù hợp?
4. Phương pháp nào được dùng để cấu trúc hóa hệ
thống?
5. Hệ thống được phân rã thành các module như thế
nào?
6. Chiến thuật điều khiển nào được sử dụng?
7. Thiết kế sẽ được đánh giá bằng cách nào?
8. Kiến trúc được viết thành tài liệu như thế nào?

Sự cần thiết của bản thiết kế kiến trúc
◼ Giao tiếp với các stakeholder
◼ Kiến trúc ứng dụng là một trọng tâm trong việc thảo luận
với các stakeholder
◼ Phân tích hệ thống
◼ Là cách phân tích xem hệ thống có đáp ứng được các
yêu cầu phi chức năng hay không
◼ Tái sử dụng
◼ Kiến trúc có thể được tái sử dụng cho nhiều hệ thống
khác.

Biểu diễn kiến trúc
Vision
system
Object Arm Gripper

◼ Thường dùng là các identification controller controller
system
sơ đồ khối để chỉ ra
các thực thể và quan
hệ giữa chúng Packaging
selection
system
Packing Conveyor
system controller
Kiến trúc một hệ thống điều khiển robot

Kiến trúc và đặc điểm của hệ thống
◼ Hiệu năng (Performance)
◼ Định vị các chức năng quan trọng và giảm thiểu giao tiếp
◼ Bảo mật (Security)
◼ Sử dụng kiến trúc phân tầng với các phần quan trọng được đặt ở các
lớp bên trong.
◼ An toàn (Safety)
◼ Định vị các thao tác liên quan đến an toàn trong một số ít các hệ
thống con.
◼ Tính sẵn sàng (Availability)
◼ Có thể thay thế, cập nhật các component mà không phải dừng hệ
thống, đảm bảo hệ thống hoạt động liên tục
◼ Tính dễ bảo trì (Maintainability)
◼ Dùng các component nhỏ,chi tiết,có thể thay thế được

Tái sử dụng kiến trúc
◼ Các hệ thống có cùng lĩnh vực thường có cấu trúc
tương tự nhau phản ánh những đặc điểm của lĩnh vực
đó.
◼ Các dòng sản phẩm ứng dụng được xây dựng dựa vào
một kiến trúc lõi với một số biến thể để thỏa mãn các yêu
cầu cụ thể của khách hàng.
◼ Kiến trúc của hệ thống có thể được thiết kế dựa vào
mẫu kiến trúc (architectural pattern)
◼ Các mẫu này chứa các đặc điểm chính của một kiến trúc
đã được sử dụng qua các hệ thống phần mềm khác
nhau.

Một số mô hình mẫu kiến trúc
◼ Mô hình Model-View-Controller (MVC)
◼ Mô hình MVP (Model – View – Presenter)
◼ Mô hình MVVM (Model – View – ViewModel)
◼ Mô hình kiến trúc phân tầng
◼ Mô hình Repository
◼ Mô hình client–server
◼ Mô hình pipe and filter
◼ …

Model-View-Controller (MVC)
Mô tả Tách riêng phần biểu diễn và phần tương tác ra khỏi dữ liệu hệ
thống. Hệ thống được cấu trúc hóa thành ba component logic
tương tác với nhau.
• Model component: quản lý dữ liệu hệ thống và các thao tác
trên dữ trên dữ liệu đó.
• View component: định nghĩa và quản lý cách dữ liệu được
biểu diễn tới người dùng như thế nào.
• Controller component: Quản lý tương tác người dùng ( ví
dụ như ấn phím, nhấp chuột, ...) và chuyển các tương tác
này tới View và Model.
Sử dụng khi nào Được sử dụng khi có nhiều cách biểu diễn và tương tác với
dữ liệu. Cũng được sử dụng khi chưa biết được các yêu cầu
tương lai cho tương tác và biểu diễn dữ liệu.
Ưu điểm Cho phép dữ liệu thay đổi độc lập với việc biểu diễn của nó và
ngược lại. Hỗ trợ biểu diễn theo nhiều cách khác nhau trên
cùng một dữ liệu.
Nhược điểm Có thể chứa code bổ sung và code sẽ phức tạp hơn khi mô
hình dữ liệu và mô hình tương tác đơn giản.

Tổ chức của mô hình MVC
Controller View View

selection
Maps user actions Renders model
to model updates Requests model updates
Selects view Sends user events to
User events controller
Change
notification
State State query
change
Model
Encapsulates application
state
Notifies view of state
changes

Kiến trúc ứng dụng Web sử dụng MVC
Browser
Controller View
Form to
display
HTTP request processing Dynamic page
Application-specific logic generation
Data validation Forms management
User events
Change
notification
Update Refresh request
request
Model
Business logic
Database

Kiến trúc DBMS tập trung (Centralized DBMS)
◼ Kết hợp tất cả mọi thành phần vào một máy chủ lớn,
bao gồm phần mềm DBMS, phần cứng, các chương
trình ứng dụng và phần mềm xử lý giao diện người
dùng
Terminals Display monitor Display monitor ... Display monitor

Network
Aplication program Terminal display control Text editors ...
SOFTWARE DBMS Compilers ...
Operating System
HARDWARE

Kiến trúc File-Server
◼ File-server kết nối với các máy trạm (workstation) qua
hệ thống mạng
◼ Cơ sở dữ liệu nằm trên file-server
◼ DBMS và các ứng dụng chạy trên các máy trạm
◼ Nhược điểm:
◼ Nghẽn mạng
◼ Có DBMS trên từng máy trạm
◼ Việc kiểm soát sự truy cập đồng thời, phục hồi dữ liệu và
tính toàn vẹn rất phức tạp

Kiến trúc File-Server

Kiến trúc client-server
◼ Các mô hình hệ thống phân tán chỉ ra cách dữ liệu và
các xử lý được phân tán trên nhiều component như thế
nào.
◼ Có thể được cài đặt trên một máy đơn.
◼ Tập hợp các server độc lập cung cấp các dịch vụ cụ
thể ví dụ như in ấn, quản trị dữ liệu, ...
◼ Tập hợp các máy trạm triệu gọi các dịch vụ này
◼ Hệ thống mạng cho phép người dung truy cập vào các
server.

Kiến trúc 2 lớp Client-Server

Kiến trúc 2 lớp Client-Server
Client Server
Fat User Business Data

client interface logic server
Thin User Business Data

client interface logic server
User Business Business Data

interface logic logic server

Kiến trúc 3 lớp (Three-Tier) Client-Server

Kiến trúc 3 lớp (Three-Tier) Client-Server
Ưu điểm:
◼ Thin client → yêu cầu ít hơn về phần cứng
◼ Ứng dụng được bảo trì tập trung
◼ Dễ dàng sửa chữa hoặc thay thế một lớp mà không
làm ảnh hưởng các lớp khác

◼ Phân tách các logic nghiệp vụ → dễ cài đặt để đạt sự
cân bằng hệ thống

Architecture Application User
Data
logic Interface
Sinh viên tự tìm hiểu thêm các mô hình khác

Service-Oriented Architecture
Web Web
Service Service Database Application
#1 #2
Enterprise Service Bus
Business Process
Orchestration

Data Warehousing

Data Warehouse là gì?
◼ Data warehousing là một CSDL được thiết kế nhằm
vào mục tiêu truy vấn và phân tích hơn là xử lý các
giao dịch.
◼ Thường chứa các dữ liệu lịch sử được lấy từ các dữ
liệu giao dịch (transaction data), và có thể bao gồm dữ
liệu từ nhiều nguồn khác nhau
◼ Môi trường datawarehouse bao gồm cả giải pháp ETL
(extraction, transportation, transformation, and loading),
OLAP (online analytical processing), data mining, các
công cụ phân tích phía client, và các ứng dụng khác
quản lý việc thu thập và chuyển dữ liệu đến người dùng

Các đặc điểm của data warehouse
◼ Subject Oriented
Data warehouses được thiết kế để giúp phân tích dữ
liệu → được xây dựng xoay quanh một chủ đề nào đó.
Ví dụ: “Sales” giúp trả lời các câu hỏi như “các khách
hàng tốt nhất trong năm là ai?”, …
◼ Integrated
Data warehouses sẽ lấy dữ liệu từ nhiều nguồn khác
nhau về và tích hợp thành một định dạng xác định nào
đó → phải giải quyết những vấn đề như xung đột về
tên, sự không nhất quán giữa các đơn vị đo lường, …

Các đặc điểm của data warehouse
◼ Nonvolatile
Một khi dữ liệu đã được đưa vào data warehouse thì nó
không thể thay đổi → vì mục đích của data warehouse
là giúp ta phân tích những gì đã xảy ra
◼ Time Variant
Để phát hiện các xu hướng trong hoạt động nghiệp vụ
cần một lượng dữ liệu lớn → quan tâm đến sự biến
động của dữ liệu theo thời gian. Điều này khác với hệ
thống OLTP (online transaction processing) do yêu cầu
về hiệu suất nên dữ liệu lịch sử thường chuyển sang
các kho lưu trữ khác

So sánh giữa data warehouse và OLTP
Một điểm cần lưu

ý là dữ liệu trong
data warehoudse
thường không
thuộc dạng chuẩn
3 (3NF), là dạng
chuẩn thường gặp
trong OLTP

Data Warehouse Architecture (Basic)

Data Warehouse Architecture
(with a Staging Area)

Data Warehouse Architecture
(with a Staging Area and Data Marts)

Data Lake
Data LakeHouse

Data Lake
◼ Data Lake là nơi lưu trữ một lượng lớn các dữ liệu có
cấu trúc (structured), bán cấu cấu (semi-structured) và
phi cấu trúc (unstructured).
◼ Kiến trúc của data lake nhằm cung cấp dữ liệu cho
nhiều loại người dùng khác nhau từ cấp quản lý, người
dùng cuối, các nhà khoa học dữ liệu, các phân tích
viên, ... do đó chất lượng của dữ liệu trong hồ rất quan
trọng.

Kiến trúc Data Lake

Data Lake
◼ Về mặt dữ liệu, Data lake giữ dữ liệu thô ở trạng thái
nguyên bản (raw data) chưa qua phân tích.
◼ Trong Data lake, tất cả các loại dữ liệu từ các nguồn
của hệ thống đều được lưu trữ, bao gồm cả các nguồn
dữ liệu như nhật ký web server, dữ liệu cảm biến, hoạt
động trên mạng xã hội, văn bản, hình ảnh, ...
◼ Data lake có thể lưu trữ cả các dữ liệu hiện không sử
dụng nhưng lại có thể cần thiết trong tương lai.
◼ Dữ liệu được lưu trữ ở dạng thô và luôn dễ dàng truy
cập, cho phép tái cấu trúc mà không có trở ngại nào.
◼ Data lake giúp tận dụng tính linh hoạt của dữ liệu.

Data Lake
◼ Khi có nhu cầu sử dụng dữ liệu để giải quyết các bài
toán nghiệp vụ, chỉ có những dữ liệu liên quan được
chọn lọc và phân tích để đưa ra đáp án. Cách tiếp cận
này gọi là "Schema on Read", giúp tiết kiệm thời gian
và chi phí cho tổ chức.
◼ Data lake phù hợp với người dùng thực hiện phân tích
chuyên sâu như các nhà khoa học dữ liệu. Với nhiều
loại dữ liệu đa dạng trong data lake, người dùng có khả
năng kết hợp nhiều loại dữ liệu khác nhau và đưa ra
các câu hỏi hoàn toàn mới cần được giải đáp.
◼ Hệ sinh thái Hadoop rất phù hợp với kiến trúc lưu trữ
này, và cũng giúp giảm chi phí lưu trữ.

Sự thay đổi của các mô hình kiến trúc dữ liệu

So sánh các mô hình kiến trúc dữ liệu

Data LakeHouse
◼ Kiến trúc Data LakeHouse đang được chấp nhận rộng
rãi dù chỉ mới xuất hiện gần đây.
◼ Nhiều nghiên cứu cho thấy đây là kiến trúc tốt cho các
hệ thống cơ sở dữ liệu lớn, sẽ được sử dụng nhiều
trong thời gian sắp tới và ổn định trong một thời gian
dài.

Chương 10
Hiện thực hệ thống
Cài đặt - vận hành - hỗ trợ

Chương 10: Hiện thực hệ thống Slide 1
Đảm bảo chất lượng
◼ Bảo đảm chất lượng là vô cùng quan trọng trong tất cả
các lãnh vực
◼ Mục tiêu chính của bảo đảm chất lượng là phát hiện và
tránh các lỗi càng sớm càng tốt
◼ Bảo đảm chất lượng có thể phát hiện
◼ Các yêu cầu không chính xác
◼ Các lỗi sai của thiết kế và lập trình
◼ Tài liệu không chính xác
◼ Việc kiểm tra không hiệu quả

Đảm bảo chất lượng
◼ Công nghệ phần mềm (software engineering)
◼ Chất lượng trong thiết kế phần mềm
◼ Thiết kế tốt
◼ Cấu trúc hiệu quả
◼ Lập tài liệu chính xác
◼ Kiểm tra cẩn thận
◼ International Organization for Standardization (ISO)
◼ Software Engineering Institute (SEI)
◼ Thành lập năm 1984
◼ Thành viên liên kết của Carnegie Mellon University
◼ CMM - CMMI

CMMI là gì
Là khung (framework) mô tả các thành phần chính

yếu của một quá trình phát triển phần mềm hiệu
quả
Khi tuân thủ tiêu chuẩn này sẽ làm đơn vị phát
triển phần mềm đạt các mục tiêu về chi phí, thời
gian, đảm bảo chức năng và chất lượng sản phẩm

Các mức của CMMI
Continuously improving process Optimising (5)
Predictable process Managed (4)
Standard, consistent process Defined (3)
Disciplined process Repeatable (2)
Initial (1)

Các bước chính của phát triển ứng dụng

Kiểm thử ứng dụng

Verification - Validation
◼ Kiểm định (Verification) là kiểm tra xem sản phẩm có
được xây dựng đúng quy trình không
◼ Thẩm định (Validation) là kiểm tra xem sản phẩm xây
dựng đúng yêu cầu của khách hàng không

Các mức độ kiểm thử

Kiểm tra ứng dụng
Phân tích yêu Đặc tả Kiểm tra Biên bản

cầu NSD yêu cầu NSD chấp nhận nghiệm thu
Kiểm tra
Hệ thống
hệ thống
Thiết kế kiến Lập kế hoạch
trúc ứng dụng kiểm tra
Kiểm tra
tích hợp
Thiết kế Viết kịch bản
tổng thể kiểm tra Kiểm tra
đơn vị CT
Thiết kế
Lập trình
chi tiết

Kiểm tra đơn vị chương trình (unit test)
◼ Kiểm tra từng chương trình riêng biệt
◼ Kỹ thuật hộp trắng (white box)
◼ Người lập trình biết rõ những gì diễn ra trong chương
trình, và đưa dữ liệu thử qua tất cả các nhánh trong
chương trình
◼ Kỹ thuật hộp đen (black box)
◼ Không biết những gì diễn ra trong chương trình, dữ liệu
kiểm thử đưa theo trình tự và tần suất như trong thực tế

Kiểm tra tích hợp (integration test)
◼ Nhằm kiểm tra sự phối hợp làm việc giữa các đơn
vị chương trình
◼ Có thể dùng program stub để mô phỏng việc nhận
điều khiển, các tham số vào, kết xuất dữ liệu từ
CSDL và trả kết quả ra → cho phép ta tích hợp
một thành phần chương trình nào đó mà chưa có
trong tay các thành phần khác.
◼ Có thể lựa chọn chiến lược tích hợp từ dưới lên
hay từ trên xuống

Kiểm tra hệ thống (system test)
◼ Kiểm tra toàn bộ hệ thống với tất cả các tình huống

có thể xảy ra.
◼ Kiểm tra từ nhiều góc độ khác nhau
◼ Kiểm tra khôi phục: sự cố làm hỏng hệ thống?
◼ Kiểm tra an toàn: các thâm nhập trái phép?
◼ Kiểm tra gay cấn: dữ liệu tăng đột biến?
◼ Kiểm tra tải: xử lý khối lượng dữ liệu lớn trong nhiều giờ
liên tục?
◼ Kiểm tra hiệu năng: tốc độ đáp ứng yêu cầu?

Kiểm tra chấp nhận (acceptance test)
− Đây là kiểm tra cuối cùng được tiến hành

− Phía người dùng chuẩn bị đầy đủ các thiết bị, môi
trường vận hành
− Alpha Test:
◼ Tiến hành tại môi trường của người phát triển, kiểm tra
trên số liệu mô phỏng và theo sự sắp đặt của người phát
triển
− Beta Test:
◼ Kiểm tra tại nơi sử dụng, trên môi trường thật, sử dụng
dữ liệu và tình huống thật

Kỹ thuật thiết kế test case
◼ Kỹ thuật phân lớp tương đương (Equivalence Class
Partitioning)
◼ Kỹ thuật phân tích các giá trị biên (Boundary value
analysis)
◼ Kỹ thuật dùng các bảng quyết ₫ịnh (Decision Tables)
◼ Kỹ thuật kiểm thử các bộ n thần kỳ (Pairwise)
◼ Kỹ thuật dùng bảng chuyển trạng thái (State Transition)
◼ Kỹ thật phân tích vùng miền (domain analysis)
◼ Kỹ thuật dựa trên đặc tả Use Case (Use case)
◼ Kỹ thuật dùng lược đồ quan hệ nhân quả (Cause-Effect
Diagram)

Lập tài liệu
◼ Nhằm giải thích hệ thống và hỗ trợ con người giao tiếp
với hệ thống
◼ Các loại tài liệu
◼ Tài liệu về chương trình
◼ Tài liệu về hệ thống
◼ Tài liệu về vận hành
◼ Tài liệu cho người sử dụng

Tài liệu về chương trình
◼ Program Documentation
◼ Bắt đầu từ giai đoạn phân tích và tiếp tục trong giai
đoạn thực hiện hệ thống
◼ Mô tả các quá trình và trình bày các báo cáo
◼ Lập trình viên cung cấp tài liệu cùng các ghi chú để dễ
hiểu và bảo trì chương trình
◼ Phân tích viên phải thẩm tra tài liệu về chương trình là
đầy đủ và chính xác

Tài liệu về hệ thống
◼ System Documentation
◼ Mô tả các chức năng của hệ thống và chúng được thực
hiện như thế nào
◼ Hầu hết tài liệu được chuẩn bị trong các giai đoạn phân
tích và thiết kế
◼ Tài liệu về hệ thống bao gồm
◼ Các mục trong từ điển dữ liệu
◼ Các sơ đồ DFD
◼ Các mô hình đối tượng
◼ Các dạng trình bày màn hình
◼ Các tài liệu nguồn
◼ Yêu cầu về hệ thống ban đầu
Tài liệu về vận hành
◼ Operations Document tation
◼ Được sử dụng trong môi trường máy tính lớn hoặc máy
tính mini với việc xử lý tập trung và lập thời biểu công
việc theo bó
◼ Tài liệu cho biết các nhóm điều hành CNTT chạy các
chương trình khi nào và như thế nào
◼ Ví dụ: bản chạy chương trình chứa thông tin cần thiết
để xử lý và phân phát kết xuất

Tài liệu cho người sử dụng
User Documentation thường gồm các mục sau:
◼ Tổng quan về hệ thống
◼ Mô tả tài liệu nguồn với các ví dụ tiêu biểu
◼ Các màn hình trình đơn và màn hình nhập dữ liệu
◼ Các bản báo cáo có sẵn với các ví dụ tiêu biểu
◼ Bảo mật và thông tin vết kiểm tra
◼ Trách nhiệm nhập, xuất và xử lý
◼ Các thủ tục giải quyết các thay đổi/vấn đề
◼ Các ví dụ ngoại lệ và các tính huống sai
◼ Các câu thường hỏi (FAQ)
◼ Phần trợ giúp giải thích và cập nhật sổ tay

Tài liệu cho người sử dụng
◼ Tài liệu trực tuyến có thể hướng dẫn người sử dụng và
giảm yêu cầu hỗ trợ trực tiếp
◼ Trợ giúp cảm ngữ cảnh
◼ Hướng dẫn theo cách tương tác
◼ Gợi ý và chỉ dẫn
◼ Siêu văn bản
◼ Tài liệu đã viết thường được cung cấp trong sổ tay
người sử dụng
◼ Người phân tích chuẩn bị tài liệu và người sử dụng
xem lại nó và tham gia vào việc viết sổ tay

Cài đặt - vận hành - hỗ trợ
◼ Lập kế hoạch triển khai
◼ Chuyển đổi hệ thống
◼ Quản lý cấu hình và thay đổi
◼ Các hoạt động hỗ trợ người sử dụng
◼ Sao lưu và phục hồi
◼ Các hoạt động bảo trì
◼ Quản lý vận hành hệ thống và hỗ trợ
◼ Quản lý hiệu suất hệ thống
◼ Vấn đề lỗi thời của hệ thống

Thay đổi hệ thống
◼ Thay đổi hệ thống (system changeover) là bỏ hệ thống
cũ đi vàvận hành hệ thống mới
◼ Có bốn cách tiếp cận chính:
◼ Thay đổi ngay lập tức (direct cutover)
◼ Vận hành song song (parallel operation)
◼ Vận hành thí điểm (pilot operation)
◼ Thay đổi từng giai đoạn (phased changeover)
◼ Mỗi cách tiếp cận có chi phí và các yếu tố rủi ro khác
nhau

Thay đổi hệ thống

Thay đổi ngay lập tức (direct cutover)
◼ Bỏ ngay lập tức hệ thống cũ và thay thế bằng hệ thống
mới
◼ Chi phí tương đối thấp vì chỉ có một hệ thống được vận
hành
◼ Rủi ro tương đối cao vì không có tùy chọn sao lưu
◼ Định thời là một yếu tố quan trọng cho các hệ thống có
chu kỳ xử lý định kỳ

Vận hành song song (parallel operation)
◼ Vận hành cả hai hệ thống mới và cũ cùng lúc trong một
khoảng thời gian nhất định để kiểm tra
◼ Dữ liệu được nhập vào cả hai hệ thống và thẩm tra các
kết quả
◼ Chi phí tương đối cao
◼ Rủi ro tương đối thấp vì có thể thẩm tra các kết quả và
có tùy chọn sao lưu
◼ Phương pháp không thực tế nếu hai hệ thống khác
nhau hoặc không thể hỗ trợ lẫn nhau

Vận hành thí điểm (pilot operation)
◼ Vận hành cùng lúc cả hai hệ thống cũ và mới, tại một
nơi được chọn làm thí điểm
◼ Các nơi còn lại của công ty tiếp tục sử dụng hệ thống
cũ
◼ Chi phí tương đối vừa phải vì chỉ có một nơi chạy cả
hai hệ thống
◼ Rủi ro cũng tương đối vừa phải

Thay đổi từng giai đoạn (phased changeover)
◼ Hệ thống được chia theo từng giai đoạn hoặc đơn thể
chương trình
◼ Thay đổi bằng cách áp dụng từng phần của hệ thống
cho toàn công ty
◼ Chi phí tương đối vừa phải vì hệ thống được thực hiện
theo từng giai đoạn
◼ Rủi ro cũng tương đối vừa phải

Chi phí và rủi ro

Đánh giá sau khi cài đặt thực hiện
◼ Tính chính xác, đầy đủ và kịp thời của các kết xuất
◼ Sự thỏa mãn của người sử dụng
◼ Tính tin cậy và tính bảo trì của hệ thống
◼ Đầy đủ các điều khiển của hệ thống và bảo mật
◼ Hiệu quả của phần cứng/hiệu suất của phần mềm nền
◼ Hiệu quả của hệ thống cơ sở dữ liệu
◼ Hiệu suất của nhóm công nghệ thông tin
◼ Tính đầy đủ và chất lượng của tài liệu
◼ Chất lượng và hiệu quả đào tạo
◼ Tính chính xác của việc đánh giá chi phí – lợi ích và
thời biểu phát triển

Cs 09010

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cs 09010

Uploaded by

Copyright:

Available Formats

MÔN: PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Input Sub system 1 Sub system 2 Output

Sơ đồ tổng quát hệ thống

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

◼ Phân tích và thiết kế HTTT là công việc được thực

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

QL chiến lược Quản trị viên cấp cao

QL chiến thuật Quản trị viên cấp trung

QL tác nghiệp Quản trị viên cấp thấp

Thực hiện nghiệp vụ Nhân viên thừa hành

Mô hình tổ chức quản lý trong công ty

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

◼ Ví dụ: Xử lý đơn đặt hàng quy định rõ là dựa vào

để hỗ trợ ở mức tự động hóa cao.

Trần Quang Môn: PTTKHT

◼ Ví dụ: Quyết định khi bỏ phiếu bình chọn bàn

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

MIS - KWS - OAS

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

hợp với nhau, cùng nhau làm việc để xây dựng

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

◼ Lập trình viên

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Có yêu cầu biết lập trình

Người Khoảng trống Lập trình

Có yêu cầu phân tích và thiết kế biết lập trình

Người yêu cầu

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Chu kỳ phát triển hệ thống

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Trần Quang Môn: PTTKHT

Làm thế nào để hệ thống hoạt động? (How)

Trần Quang Môn: PTTKHT

Hiện thực hệ thống

Bước Kỹ thuật Kết quả