Title

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

CHƯƠNG 1
GIỚI THIỆU VỀ PHÂN TÍCH & THIẾT KẾ HỆ THỐNG

01/2023
1
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

2
Dữ liệu (Data)

• Dữ liệu: 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 điểm của big data
• 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 ra hơn 10 terabytes mỗi 30

phút về thông tin các chuyến bay. Với hàng ngàn
chuyển bay mỗi ngày, dữ liệu lên đến nhiều Petabytes.
 Thông tin (Information)

• Thông tin: dữ liệu đã được xử lý, đặt trong ngữ

cảnh phù hợp, có ích cho người dùng.

Data Information
Data Processing

Data store
 Thông tin (Information)

• 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)

 Hệ thống (System)

• Hệ thống: 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

Hình 1: 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ị.
Hệ thống thông tin (Information System)
• 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 Cổ đông
System users
• Internal system users Người dùng nội bộ

• Clerical and service workers Nhân viên văn phòng & nhân viên
dịch vụ
• Technical and professional staff Nhân viên ký thuật & đội ngũ
nhân viên chuyên nghiệp
• Supervisors, middle managers, executive
managers người gim sát, quản lý cấp trung, giám đốc điều hành

• External system users người dùng ngoài

• Customers
• Suppliers
• Partners đối tác

• Employees: sales representatives, …

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)

Nhân viên thừa hành

Thực hiện nghiệp vụ
Các loại quyết định

• Ra quyết định: 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ý.

Các loại quyết định

❖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 khách để
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.
Các loại quyết định

❖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.
Các loại quyết định

❖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 là
quyết định bán cấu trúc, vì để 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.

• Thông tin đ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; thường là các thông tin 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á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.
• Các thông tin thường thu thập từ bên trong hệ thống và
đôi khi cần một ít thông tin ngoài.
• Do thu thập từ bên trong hệ thống và tương lai gần, nên
các thông tin chắc chắn và cụ thể hơn.
 Quản trị viên cấp thấp
• Liên quan đến 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 đảm bảo 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, …

• Thông tin hầu như có nguồn gốc từ bên trong công ty.
Đặc điểm thông tin ở cấp này là 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

hỗ trợ ra qđịnh nhóm

/ điều hành
ESS
GDSS

ES - DSS
chuyên gia, ra quyết định

hệ thống tri thức

MIS - KWS - OAS
tự động hóa cv văn phòng

TPS
xử lý giao dịch
 Phân loại HTTT: TPS

❖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 & 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

❖Hệ thống tự động hóa công việc văn phòng (Office

Automatic System - OAS): hỗ trợ việc tự động hóa các
công việc văn phòng: thư điện tử, lập lịch, nhắc việc, …

❖Hệ thống tri thức (Knowledge Work System - KWS): 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
❖Hệ thống thông tin quản lý (Management Information
System – MIS)
• Cung cấp 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ác thông tin cung cấp cho nhà quản lý có thể thực hiện:
✓ theo định kỳ
✓ 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
❖ Hệ hỗ trợ ra quyết định (Decision Support System - DSS)

• 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
❖Hệ chuyên gia (Expert System – 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ế.

❖Trí tuệ nhân tạo (Artificial Intelligence - 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

❖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

❖Hệ trợ giúp điều hành (Executive Support

System - ESS)

• 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): 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)
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

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

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

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)

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

Chọn lựa chiến Xác định cách phát triển hệ
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,
kiến trúc ứng dụng
Thiết kế giao diện Thiết kế input
Thiết kế output
Thiết kế cơ sở dữ Thiết kế CSDL, chọn lựa hệ
liệu quản trị CSDL, tối ưu hóa, …
Chiến lược thiết kế
Tài liệu thiết kế kiến trúc hạ
tầng của hệ thống
Tài liệu thiết kế giao diện
Tài liệu thiết kế CSDL

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

chương sau rõ hơn

Giai đoạn thi công (Implementation)

Hiện thực hệ thống

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

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

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

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: Focus vào nha, có phần mềm
dùng xây dựng lược đồ
• 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?

ưu: đơn giản, dễ hiểu

hiệu quả với dự án vừa và nhỏ

nhược: khó quay lại và thay đổi: nếu

ứng dụng đã chuyển sang giai đoạn
thử nghiệm và có thay đổi về yêu
cầu, gặp khó khăn để quay lại và
thay đổi nó.
ng dùng biết rõ nghiệp vụ khi qđịnh sử dụng
waterfall
Mô hình chữ V (V-Shaped model)

System

Requirement Acceptance Test

High level design System Test

Detailed design Unit Test

Construction
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)

65
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 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)
 Sự ra đời của Agile

* Dự án Phát triển phần mềm

Khó khăn Biến động Rủi ro Hạn chế

• Thu thập đầy • Công nghệ • Thay đổi hiển • Chia sẻ

đủ, chính xác • Con người nhiên • Cộng tác
yêu cầu • Môi trường kinh doanh • Quản lý sản • Kỹ thuật
• Lập kế hoạch • Yếu tố kỹ thuật xuất dựa trên • Công cụ
tốt ngay từ đầu sự tiên lượng
• Mở rộng
• Hướng phát
triển
Waterfall Agile
Xoắn ốc

1990 2001 70
 AGILE là gì?

 Agile là một phương pháp phát triển phần mềm linh hoạt,
là một hướng tiếp cận cụ thể cho quản lý dự án phần mềm.
Nó gồm một quá trình làm việc tương tác và tích hợp để có
thể đưa sản phẩm đến tay người dùng càng nhanh càng
tốt.

Rob Cole, Ed Scotcher (2016)

71
 Tuyên ngôn Agile

Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn
bằng cách thực hiện nó và giúp đỡ người khác thực hiện.

CÁ NHÂN VÀ SỰ TƯƠNG TÁC hơn là Quy trình và công cụ

PHẦN MỀM CHẠY TỐT hơn là Tài liệu đầy đủ

CỘNG TÁC VỚI KHÁCH HÀNG hơn là Đàm phán hợp đồng

PHẢN HỒI VỚI CÁC THAY ĐỔI hơn là Bám sát kế hoạch

Mặc dù các điều bên phải vẫn còn giá trị, nhưng chúng tôi
đánh giá cao hơn các mục ở bên trái.
72
 Cá nhân và sự tương tác

➢ Tự tổ chức

➢ Tự quản lý

➢ Duy trì động lực

Đảm bảo môi trường thuận lợi tương tác giữa các cá nhân

73
Phần mềm chạy tốt

Sản phẩm hoạt động tốt

Tập trung chuyển giao sản phẩm ngay từ giai đoạn đầu tiên

74
 Cộng tác với khách hàng

“Khách hàng là thượng đế”

➢ Khách hàng mong muốn ?

➢ Sản phẩm ?

➢ Tính năng: lợi ích & giá trị ?

➢ Chi tiết chính xác tính năng ?

• Team làm đúng mong muốn khách hàng

Khách hàng cùng tham • Tư vấn & điều chỉnh feedback kịp thời
gia phát triển sản phẩm
• Tối ưu hóa sản phẩm

75
 Phản hồi với các thay đổi

➢ Môi trường kinh doanh

➢ Công nghệ

➢ Nhân sự

➢ Deadline

Tập thích nghi thay đổi, feedback → giảm rủi ro, tối ưu hóa

76
 SCRUM

• Mọi tri thức đến từ kinh

nghiệm
Thuyết • Ra quyết định dựa trên
thực những gì đã biết
nghiệm
• Giảm thiểu rủi ro
• Tăng bước chính xác

• Không có kế hoạch chi tiết

cho hành trình

Kiểu bay • Vượt qua được hàng chục

Quan sát và thích nghi liên tục
thực nghiệm nghìn km/ năm nơi xa lạ điều kiện khí hậu, thức ăn, nơi trú ngụ
đàn chim
di cư
77
SCRUM

Team liên tục thăm dò và điều chỉnh hoạt động

→ giảm thiểu rủi ro
→ tối ưu hóa giá trị sản phẩm
78
 SCRUM

Minh bạch Giảm rủi ro

Tăng tin cậy
• Mục tiêu dự án Nâng cao chất lượng
• Yêu cầu khách hàng Chính xác trong quyết định
• Tiến độ
• Tài chính …

Vấn Điều Phát hiện điểm

chỉnh SCRUM bất thường
đề

Thích nghi Thanh tra

• Liên tục phát triển • Tạo tác
• hôm nay > hôm qua • Tiến độ

79
Scrum Framework

Scrum easy to understand difficult to master

Rob Cole, Ed Scotcher (2016)

80
The Sprint Lifecycle

Rob Cole, Ed Scotcher (2016)

81
Phân Biệt Agile, Scrum

 Agile là mindset, là  Scrum là framework,

cách suy nghĩ, là một là mô hình thực hiện
tư tưởng. để tạo ra được trạng
thái Agile.
“There is no failure, only feedback.”
Leanne Howard

82
Phân Biệt Waterfall & Scrum

83
Phân Biệt Waterfall & Scrum

Sprint Sprint Sprint Sprint

1 2 3 4

84
 Waterfall & Agile

Waterfall Agile
• Xác định được yêu cầu, không có • Có nhiều cơ hội thay đổi yêu cầu
thay đổi trong quá trình phát triển thường xuyên hơn
• Dễ quản lý, tuần tự và cứng nhắc • Linh hoạt, thay đổi bất kỳ
• Requiments định nghĩa một lần • Requiments có thể thay đổi
bởi các nhà phân tích kinh doanh thường xuyên
• SDLC: chi tiết không được thay • SDLC: chi tiết được thay đổi bất
đổi cứ lúc nào 85
Chọn Waterfall & Agile ???

Waterfall
• Dự án nhỏ, ngắn hạn
• Ít thay đổi về yêu cầu, không yêu cầu không rõ ràng
• Hiểu rõ yêu cầu dự án, kinh nghiệm với công nghệ
• Xác định hầu như không có rủi ro.

Agile
• Yêu cầu dự án chưa rõ ràng ngay từ đầu
• Mức độ rủi ro cao
• Khó lập kế hoạch dài hạn cho cả dự án
• Cần sự tham gia và tính tương tác của khách hàng
• Yêu cầu chức năng sẵn sàng thời gian ngắn.
86
ÔN TẬP

• 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

87
Q&A

88