INFORMATION SYSTEM DEVELOPMENT

MÔN: HỆ THỐNG THÔNG TIN QUẢN LÝ

Mã lớp học phần: 21C1INF50900804
Giảng viên phụ trách: ThS. Hồ Thị Thanh Tuyến

Nhóm 6:
1. Đặng Thùy Linh - 31201024544
2. Đỗ Quỳnh Như - 31201027048
3. Nguyễn Quỳnh Như - 31201026423
4. Đặng Ngọc Quang - 31201022681
5. Đỗ Hoàng Thạch Thảo - 31201020927

MỤC LỤC

1
 MỤC LỤC

LỜI CAM KẾT ................................................................................................. 4

DANH MỤC TỪ VIẾT TẮT ........................................................................... 5
DANH MỤC BẢNG BIỂU ............................................................................... 6
12.1 CÁC QUY TRÌNH NGHIỆP VỤ, HỆ THỐNG THÔNG TIN VÀ
ỨNG DỤNG ĐƯỢC PHÁT TRIỂN NHƯ THẾ NÀO? ................................ 9
12.1.1 Mối liên hệ, điểm khác biệt giữa quy trình nghiệp vụ, hệ thống
thông tin và ứng dụng (applications) ........................................................... 9
12.1.2 Các quy trình phát triển và mục đích sử dụng các quy trình này 10
12.2 CÁC TỔ CHỨC SỬ DỤNG CÔNG CỤ BPM NHƯ THẾ NÀO? ..... 11
12.2.1 Khái niệm chi tiết về quy trình nghiệp vụ ...................................... 11
12.2.2 Tại sao các quy trình nghiệp vụ cần được quản lý? ...................... 11
12.2.3. Các hoạt động trong BPM .............................................................. 12
12.2.4. Một số lợi ích chính của BPM: ....................................................... 16
12.3 SỬ DỤNG KÝ HIỆU MÔ HÌNH HÓA QUY TRÌNH NGHIỆP VỤ
(BPMN) TRONG XÂY DỰNG QUY TRÌNH .............................................. 17
12.3.1. BPMN là gì ....................................................................................... 17
12.3.2. Sự cần thiết của các ký hiệu tiêu chuẩn ......................................... 18
12.3.3. Mục đích của BPMN ....................................................................... 18
12.3.4. Lợi ích của BPMN ........................................................................... 19
12.4 VÒNG ĐỜI PHÁT TRIỂN HỆ THỐNG PHẢI TRẢI QUA CÁC
GIAI ĐOẠN NÀO? ......................................................................................... 22
12.4.1 XÁC ĐỊNH HỆ THỐNG ................................................................. 24
12.4.1.1 Xác định rõ mục tiêu và phạm vi của hệ thống: ...................... 24
12.4.1.2 Đánh giá mức độ khả thi: .......................................................... 24
12.4.1.3 Thành lập đội dự án:.................................................................. 25
12.4.2 XÁC ĐỊNH YÊU CẦU: .................................................................... 26
12.4.2.1 Các nguồn của yêu cầu: ............................................................. 26
12.4.2.2 Vai trò của prototype: ................................................................ 27
12.4.2.3 Chấp thuận yêu cầu: .................................................................. 27
12.4.3 THIẾT KẾ CÁC THÀNH PHẦN CỦA HỆ THỐNG................... 27

2
 12.4.4 THI HÀNH HỆ THỐNG ................................................................. 29
12.4.4.1 Kiểm thử: .................................................................................... 29
12.4.4.2 Sự chuyển đổi hệ thống: ............................................................ 30
12.4.5 BẢO TRÌ HỆ THỐNG ..................................................................... 31
12.4.6. Lợi ích của SDLC: ........................................................................... 37
12.5 CHÌA KHÓA THÀNH CÔNG CỦA DỰ ÁN SDLC LÀ GÌ? ............. 37
12.6 LÀM THẾ NÀO SCRUM CÓ THỂ KHẮC PHỤC ĐƯỢC CÁC VẤN
ĐỀ CỦA SDLC? .............................................................................................. 43
12.6.1 Các Nguyên tắc của Phương pháp Phát triển Agile là gì? ............ 44
12.6.2 Quy trình Scrum là gì? ..................................................................... 45
12.6.3 Làm thế nào để các yêu cầu thúc đẩy quá trình Scrum? .............. 48
12.6.4 So sánh giữa quy trình phát triển truyền thống Mô hình Thác
nước (SDLC) và SCRUM (Agile) ............................................................... 51
12.7. 2026? ........................................................................................................ 53
TÀI LIỆU THAM KHẢO .............................................................................. 54

3
 LỜI CAM KẾT

Nhóm thực hiện xin cam kết tiểu luận này do nhóm tôi xây dựng, xử lý, không
có sự sao chép từ bất kỳ bài viết của bất cứ tổ chức và cá nhân nào khác. Các
số liệu nêu trong tiểu luận là trung thực, các thông tin có nguồn gốc rõ ràng và
được trích dẫn đầy đủ theo quy định.

Nhận xét của giáo viên Tác giả tiểu luận

Nhóm 6

4
 DANH MỤC TỪ VIẾT TẮT

Ký hiệu chữ viết Dịch nghĩa

STT Chữ viết đầy đủ
tắt
Quản lý quy trình
1 BPM Information systems
nghiệp vụ
Business Process Ký hiệu hóa quy
2 BPMN
Modeling Notation trình nghiệp vụ
3 IS Information Systems Hệ thống thông tin
4 LC Letter of Credit Thư tín dụng
Systems Development Vòng đời phát triển
5 SDLC
Life Cycle hệ thống

5
 DANH MỤC BẢNG BIỂU

Các bảng được sử dụng:

Bảng 12.1 - Phạm vi của các quy trình phát triển (Giáo trình – Figure 12-3) .. 11
Bảng 12.2 - Hoạt động Thiết kế và Thi hành 5 thành phần của hệ thống (Giáo
trình – Figure 12-14) ......................................................................................... 31
Bảng 12.3 - Nguyên tắc phát triển Agile (Scrum) ............................................ 44
Bảng 12.4 - Cơ bản về Scrum ........................................................................... 46
Bảng 12.5 - Ví dụ về yêu cầu và các nhiệm vụ................................................. 49
Bảng 12.6 - Tóm tắt các kỹ thuật ước lượng trong Srcum ............................... 50
Bảng 12.7 - So sánh Mô hình thác nước (SDLC) và Scrum ............................. 52
Các sơ đồ được sử dụng:
Sơ đồ 12.1 - 5 giai đoạn của SDLC .................................................................. 23
Sơ đồ 12.2 - Giai đoạn Xác định hệ thống ........................................................ 24
Sơ đồ 12.3 – Giai đoạn Xác định yêu cầu ......................................................... 26
Sơ đồ 12.4 - Giai đoạn Thiết kế các thành phần của hệ thống ......................... 28
Sơ đồ 12.5 - Giai đoạn Thi hành hệ thống ........................................................ 29
Sơ đồ 12.6 - Giai đoạn Bảo trì hệ thống ........................................................... 31
Các hình được sử dụng:
Hình 12.1 - Quy trình đặt vé du lịch ................................................................... 9
Hình 12.2 - Hệ thống thông tin kế toán ............................................................ 10
Hình 12.3 - Mô hình As-is của một shop bán hàng online ............................... 13
Hình 12.4 - Lợi ích về chất lượng của BPM theo nghiên cứu của BearingPoint
........................................................................................................................... 17
Hình 12.5 - Các ký hiệu .................................................................................... 18
Hình 12.6 - Hình minh họa ............................................................................... 18
Hình 12.7 - Quy trình đặt hàng nguyên bản...................................................... 20
Hình 12.8 - Quy trình kiểm tra tín dụng khách hàng ........................................ 21
Hình 12.9 - Mô hình thác nước ......................................................................... 36
Hình 12.10 - Mô hình chữ V ............................................................................. 36

6
Hình 12.11 - Mô hình Agile .............................................................................. 36
Hình 12.12 - Mô hình xoắn ốc .......................................................................... 37
Hình 12.13 - Sơ đồ Gantt cho giai đoạn xác định ............................................. 38
Hình 12.14 - Sơ đồ Gantt về giai đoạn xác định của dự án trong WBS ........... 39
Hình 12.15 – Biểu đồ Gantt thể hiện sự phân chia công việc cho các nhân sự 40
Hình 12.16 - Các động lực chính của phát triển hệ thống ................................ 41
Hình 12.17 - Quy trình Scrum .......................................................................... 47

7
 LỜI CẢM ƠN

Đầu tiên, nhóm 6 xin gửi lời cảm ơn chân thành đến Trường Đại học Kinh tế
thành phố Hồ Chí Minh đã đưa môn Hệ thống thông tin quản lý vào chương
trình giảng dạy, Đặc biệt, nhóm xin gửi lời cảm ơn sâu sắc đến giảng viên bộ
môn – ThS. Hồ Thị Thanh Tuyến vì đã luôn tận tình hướng dẫn, truyền đạt
những kiến thức quý báu trong suốt quá trình học tập. Thông qua bài tiểu luận
này, nhóm 6 xin trình bày những gì mình đã tìm hiểu và học hỏi được thông
qua bộ môn Hệ thống thông tin quản lý.
Do vốn kiến thức của mỗi thành viên trong nhóm còn nhiều hạn chế và khả
năng tiếp thu thực tế còn nhiều bỡ ngỡ nên khó tránh khỏi sai sót, thiếu chính
xác trong quá trình làm bài, nhóm rất mong được cô xem xét và góp ý để bài
tiểu luận được hoàn thiện hơn.

Kính chúc cô sức khỏe và thành công trên con đường giảng dạy.

8
Dù vai trò của bạn là gì, điều quan trọng là bạn phải hiểu cách các quy trình
và hệ thống được phát triển và quản lý.

12.1 CÁC QUY TRÌNH NGHIỆP VỤ, HỆ THỐNG THÔNG TIN VÀ ỨNG
DỤNG ĐƯỢC PHÁT TRIỂN NHƯ THẾ NÀO?
12.1.1 Mối liên hệ, điểm khác biệt giữa quy trình nghiệp vụ, hệ thống thông
tin và ứng dụng (applications)
Quy trình nghiệp vụ (quy trình kinh doanh) là một mạng lưới các hoạt động
tạo ra giá trị bằng cách biến đầu vào thành đầu ra.
Quy trình nghiệp vụ bao gồm một hoặc nhiều hoạt động. Mỗi hoạt động bao
gồm nhiều nhiệm vụ và các hoạt động này thường liên quan mật thiết đến hệ
thống thông tin.

Hình 12.1 - Quy trình đặt vé du lịch

Hệ thống thông tin (IS) là một tập hợp phần cứng, phần mềm, dữ liệu, thủ
tục và con người tương tác với nhau để tạo ra thông tin.
 Mỗi hệ thống thông tin sẽ có 5 thành phần và đồng thời cũng chứa một
thành phần phần mềm.

9
 Hình 12.2 - Hệ thống thông tin kế toán
Ứng dụng là sự kết hợp của các thành phần phần cứng, phần mềm và dữ liệu
để đáp ứng một loạt các yêu cầu. (ví dụ ứng dụng: web, apps, …)
Nói chung, một quy trình nghiệp vụ đơn lẻ liên quan đến một hoặc nhiều hệ
thống thông tin. Hệ thống thông tin hỗ trợ nhiều quy trình nghiệp vụ. Hơn nữa,
mỗi hệ thống thông tin đều hỗ trợ ít nhất một quy trình nghiệp vụ.
***Lưu ý: Không phải tất cả các hoạt động của quy trình đều sử dụng hệ thống
thông tin. Một phần hoặc toàn bộ quy trình nghiệp vụ có thể được thực hiện thủ
công.
Tóm lại
1. Các quy trình nghiệp vụ, hệ thống thông tin và ứng dụng có các đặc điểm
và thành phần khác nhau.
2. Một quy trình nghiệp vụ không cần liên quan đến bất kỳ hệ thống thông
tin nào, nhưng một hệ thống thông tin liên quan đến ít nhất một quy trình
nghiệp vụ.
3. Mỗi hệ thống thông tin đều có ít nhất một ứng dụng vì mọi hệ thống thông
tin đều có một thành phần phần mềm.
12.1.2 Các quy trình phát triển và mục đích sử dụng các quy trình này
Quản lý quy trình nghiệp vụ (BPM) là một kỹ thuật được sử dụng để tạo
ra các quy trình kinh doanh mới và quản lý các thay đổi đối với các quy trình
hiện có. Trong hầu hết các trường hợp, BPM được sử dụng để quản lý sự phát
triển của các quy trình nghiệp vụ hiện có từ phiên bản này sang phiên bản cải
tiến hơn.

10
 Vòng đời phát triển hệ thống (SDLC) là một quy trình có thể được sử dụng
để phát triển cả hệ thống thông tin và ứng dụng. SDLC đạt được sự nổi bật vào
những năm 1980 khi Bộ Quốc phòng Hoa Kỳ yêu cầu tất cả các dự án phát triển
phần mềm và hệ thống đều phải sử dụng quy trình này. SDLC phổ biến, nổi tiếng
và thường được sử dụng, tuy nhiên nó cũng thường phát sinh nhiều sự cố.
Scrum là một quy trình phát triển mới, được tạo ra để khắc phục các sự cố
xảy ra khi sử dụng SDLC. Scrum đủ mạnh để nó có thể được sử dụng trong việc
phát triển (và thích ứng) các quy trình nghiệp vụ, hệ thống thông tin và ứng dụng.
Các quy trình phát triển
BPM SDLC Scrum
Quy trình
 
nghiệp vụ
Phạm vi Hệ thống
 
thông tin
Ứng dụng  
Bảng 12.1 - Phạm vi của các quy trình phát triển (Giáo trình – Figure 12-3)

12.2 CÁC TỔ CHỨC SỬ DỤNG CÔNG CỤ BPM NHƯ THẾ NÀO?

12.2.1 Khái niệm chi tiết về quy trình nghiệp vụ
Quy trình nghiệp vụ: Mạng lưới các hoạt động, kho lưu trữ, vai trò, nguồn
lực và các luồng tương tác với nhau để hoàn thành một chức năng kinh doanh.
Trong đó:
➢ Hoạt động là tập hợp các nhiệm vụ liên quan đến việc nhận đầu vào và
tạo ra đầu ra.
➢ Kho lưu trữ là một tập hợp của một cái gì đó.
Ví dụ: nơi chứa hàng tồn kho được gọi là kho lưu trữ hàng tồn và một cơ
sở dữ liệu là một kho dữ liệu.
➢ Vai trò (roles): tập hợp các hoạt động
➢ Nguồn lực (resources): con người hoặc ứng dụng máy tính được gán cho
các vai trò.
➢ Luồng (flow): có thể là một luồng kiểm soát (control flow) chỉ đạo thứ
tự của các hoạt động hoặc một luồng dữ liệu (data flow) cho thấy sự di
chuyển của dữ liệu giữa các hoạt động và kho lưu trữ.
12.2.2 Tại sao các quy trình nghiệp vụ cần được quản lý?
Có ba lý do: cải thiện chất lượng quy trình, thích ứng với những thay đổi của
công nghệ và thích ứng với những thay đổi trong các nguyên tắc kinh doanh cơ
bản.
• Cải thiện chất lượng quy trình

11
Chất lượng quy trình có hai thước đo: hiệu suất (sử dụng các nguồn lực) và hiệu
quả (hoàn thành chiến lược). Lý do rõ ràng nhất để thay đổi một quy trình là nó
có các vấn đề về hiệu quả hoặc hiệu suất.
• Thay đổi công nghệ
Khi công nghệ mới thay đổi bất kỳ hoạt động nào của quy trình nghiệp vụ một
cách đáng kể, toàn bộ quy trình cần được đánh giá lại. Đây cũng là một lý do
khác để quản lý các quy trình.
• Thay đổi các nguyên tắc cơ bản trong kinh doanh
Một sự thay đổi đáng kể trong bất kỳ yếu tố nào sau đây có thể dẫn đến nhu cầu
sửa đổi các quy trình nghiệp vụ:
➢ Thị trường (ví dụ: loại khách hàng mới, thay đổi về đặc điểm của khách
hàng)
➢ Dòng sản phẩm
➢ Chuỗi cung ứng
➢ Chính sách của công ty
➢ Cấu trúc công ty (ví dụ: sáp nhập, mua lại)
➢ Quốc tế hóa
➢ Môi trường kinh doanh (ví dụ: những thay đổi trong việc ưu tiên kiểm tra
tín dụng)
12.2.3. Các hoạt động trong BPM
Ba lý do kể trên đòi hỏi những thay đổi trong quy trình nghiệp vụ cho dù tổ
chức có nhận ra nhu cầu đó hay không.
Bốn hoạt động cơ bản của việc quản lý quy trình nghiệp vụ - một quy trình
theo chu kỳ dùng để tạo ra, đánh giá và sửa đổi các quy trình nghiệp vụ một cách
có hệ thống – bao gồm: Mô hình hóa quy trình, Tạo ra các thành phần, Triển khai
quy trình và Đánh giá kết quả.
• Mô hình hóa quy trình:
Chu trình này bắt đầu bằng việc tạo ra một mô hình của quy trình nghiệp vụ hiện
có, được gọi là mô hình hiện tại (As – is model). Sau đó, những người dùng
doanh nghiệp có chuyên môn tham gia, đánh giá các mô hình và thực hiện các
cải tiến.

12
 Hình 12.3 - Mô hình As-is của một shop bán hàng online
*** Làm thế nào để cải thiện quy trình nghiệp vụ?
Quy trình nghiệp vụ có thể được cải thiện bằng cách thay đổi cấu trúc của
quy trình, gia tăng nguồn lực hoặc cả hai.
Nếu cấu trúc quy trình được thay đổi, một mô hình của quy trình sửa
-
đổi sẽ được xây dựng.
- Hai cách phổ biến để gia tăng nguồn lực vào quy trình là chỉ định
nhiều người hơn để xử lý các hoạt động và tạo ra/sửa đổi hệ thống
thông tin.
• Tạo các thành phần:
Sau khi đã có mô hình, bước tiếp theo là tạo các thành phần hệ thống. Trong hoạt
động này, nhóm sẽ thiết kế các thay đổi đối với quy trình nghiệp vụ.
➢ Nếu quy trình có sự xuất hiện của hệ thống thông tin mới hoặc có những
thay đổi đối với hệ thống thông tin hiện có thì các dự án phát triển hệ
thống mới sẽ được tạo và quản lý ở giai đoạn này.
➢ Đối với những hoạt động có liên quan đến hệ thống thông tin, các thủ tục
(procedures) cần được tạo ra để cho phép người dùng hoàn thành các
nhiệm vụ của họ.
• Triển khai quy trình:
Tại đây, các tác nhân sẽ được làm quen với các hoạt động và thủ tục mới. Việc
chuyển đổi quy trình thường vấp phải sự kháng cự của nhân viên, do đó một hoạt
động quan trọng trong quá trình triển khai là xoa dịu sự kháng cự của nhân viên.
Không dừng lại ở đó, các tổ chức tạo ra chính sách, thủ tục và ủy ban để liên tục
đánh giá hiệu quả của quy trình kinh doanh. Hiệp hội Kiểm tra và Kiểm soát Hệ
thống Thông tin đã tạo ra một bộ tiêu chuẩn thực hành được gọi là COBIT (Mục

13
tiêu Kiểm soát Thông tin và Công nghệ liên quan) thường được sử dụng trong
giai đoạn đánh giá của chu trình BPM.
• Đánh giá kết quả:
Khi quá trình đánh giá chỉ ra rằng có một lượng lớn nhu cầu cần thay đổi đã gia
tăng đáng kể, chu trình BPM được lặp lại.
BPM hiệu quả cho phép các tổ chức đạt được cải tiến quy trình liên tục. Hiệu
quả của quy trình được giám sát liên tục và các quy trình được điều chỉnh khi
cần thiết.
Tóm lại, BPM có thể hiểu như là chúng ta đang tác động, cải thiện một quy
trình nghiệp vụ từ đầu đến cuối bằng cách phân tích nó, mô hình hóa cách thức
hoạt động trong các kịch bản khác nhau đồng thời thực hiện các cải tiến, giám
sát quy trình để liên tục tối ưu hóa nó. Kết quả là ta thu được một quy trình chất
lượng hơn trước.
➔ Ví dụ về BPM:
Trước những khó khăn hiện hữu như nợ xấu, rủi ro tín dụng tăng cao, chi phí
hoạt động lớn, cạnh tranh ngày càng trở nên mạnh mẽ, ngân hàng MB Bank đang
gánh chịu áp lực rất lớn về việc cải tiến qui trình nghiệp vụ.

Để có thể cải tiến quy trình hiện có, MB Bank đã lựa chọn sử dụng công cụ BPM.
Tại MB Bank, BPM được ứng dụng ở các nghiệp vụ cụ thể như: khởi tạo và quản
lý các khoản vay, phê duyệt tín dụng tập trung, chuyển tiền, quản lý các khoản
nợ. Sau đây là quy trình mở LC của MB Bank trước và sau khi áp dụng BPM:

* Qui trình mở LC cổ điển:

+ Bước 1: Tiếp xúc khách, Chuyên viên khách hàng tiếp nhận yêu cầu của
khách hàng, cho khách hàng điền “Phiếu đề nghị mở LC” và thu thập bản sao
các thông tin của khách hàng: Giấy đăng ký kinh doanh, giấy ủy nhiệm giao dịch,
Giấy đăng ký con dấu, …

+ Bước 2: Phê duyệt tại chi nhánh: Chuyên viên khách hàng chuyển toàn
bộ hồ sơ bản cứng cho Lãnh đạo phụ trách chi nhánh phê duyệt. Tại bước này
trong trường hợp lãnh đạo chi nhánh vắng mặt thì hồ sơ sẽ phải đợi đến khi nào
lãnh đạo có mặt mới được duyệt dẫn đến khách hàng phải chờ đợi mất thời gian.

14
 + Bước 3: Soạn hợp đồng LC; Sau khi hồ sơ yêu cầu mở LC của khách
hàng được duyệt, toàn bộ bản cứng được niêm phong và chuyển phát nhanh lên
bộ phận soạn thảo tại hội sở hoặc trụ sở vùng. Tại bước này, ngân hàng đã không
thể thao tác gì với bộ hồ sơ trong khoảng thời gian hồ sơ đang trên đường chuyển
phát nhanh, đồng thời cũng tồn tại nguy cơ thất lạc hồ sơ và lộ thông tin khách
hàng.

+ Bước 4: Lãnh đạo bộ phận soạn thảo kiểm tra lại nội dung hợp đồng với
khách hàng và nội dung LC và chấp thuận chuyển các tài liệu về chi nhánh để
ký kết với khách hàng. Lại một lần nữa thời gian của ngân hàng bị lãng phí trong
khi khách hàng đang rất cần phát hành nhanh LC để tiến hành các thủ tục xuất
nhập khẩu.

+ Bước 5: Ký kết hợp đồng; Chi nhánh nhận tài liệu về hợp đồng, LC
chuyển khách hàng ký.

+ Bước 6: Duyệt hợp đồng. Tình huống rủi ro tương tự với bước 2.

+ Bước 7: Kiểm tra hợp đồng. Tình huống rủi ro tương tự bước 3

+ Bước 8: Phê duyệt phát hành LC

- Tại tất cả các bước 2, 3, 4, 5, 6, 7, 8 các thành viên tham gia quy trình đều có
thể trả hồ sơ về bước trước đó (và điều này thường xuyên xảy ra) để cấp dưới bổ
sung nội dung và trong trường hợp này, bước 3, 5, 7 có thể làm mất rất nhiều
thời gian của ngân hàng và đặc biệt có thể gây thiệt hại nghiêm trọng cho khách
hàng vì mất cơ hội làm ăn. Nhìn vào cách thực hiện quy trình trên ta có thể thấy
mô hình quy trình nghiệp vụ sẽ tốn rất nhiều thời gian và phát sinh nhiều rủi do
tại quá trình luân chuyển hồ sơ giữa các bước.

* Với qui trình mở LC trên BPM hiện đại:

+ Bước 1: Chuyên viên khách hàng gặp gỡ khách hàng thu thập hồ sơ tại địa
điểm của khách hàng sau đó dùng smartphone scan nội dung hồ sơ lên hệ thống
BPM và thực hiện chuyển hồ sơ sang bước 2.

15
+ Bước 2: Ngay lập tức hệ thống gửi email hoặc nhắn tin báo lãnh đạo chi nhánh
là có hồ sơ mới cần phê duyệt. Lãnh đạo có thể xem nội dung hồ sơ trên Ipad
hoặc trên laptop thông qua giao diện Web, từ đây lãnh đạo chi nhánh có thể yêu
cầu bổ sung thông tin ngay lập tức trong khi chuyên viên khách hàng vẫn ở tại
địa điểm của khách hàng. Nếu hồ sơ đạt yêu cầu lãnh đạo nhấn nút phê duyệt
trên giao diện lập tức hồ sơ được chuyển sang bước 3 cùng với các thông tin mà
chuyên viên khách hàng của chi nhánh đã scan từ khách hàng.

+ Bước 3: Soạn hợp đồng LC

+ Bước 4: Lãnh đạo bộ phận soạn thảo kiểm tra lại nội dung hợp đồng với khách
hàng và nội dung LC và chấp thuận chuyển các tài liệu về chi nhánh để ký kết
với khách hàng.

+ Bước 5: Ký kết hợp đồng: Chi nhánh nhận tài liệu về hợp đồng, LC chuyển
khách hàng ký.

+ Bước 6: Duyệt hợp đồng.

+ Bước 7: Kiểm tra hợp đồng.

+ Bước 8: Phê duyệt phát hành LC

- Các bước 3,4,5,6,7,8 hồ sơ không hề phải chuyển bất kỳ bản cứng nào, mọi
thông tin đều di chuyển qua môi trường mạng giúp thời gian luân chuyển hồ sơ
gần như bằng không và rùi ro giảm xuống mức thấp hơn (Chỉ còn rủi ro về an
ninh mạng).

Nhìn chung, BPM đã giúp MB Bank xác định cách triển khai, giám sát và đo
lường tài nguyên của công ty. Từ đó nâng cao hiệu quả và năng suất, giảm chi
phí và giảm thiểu sai sót cũng như rủi ro.

12.2.4. Một số lợi ích chính của BPM:

• Cải tiến, tối ưu hóa và xây dựng các quy trình một cách khoa học và hiệu
quả. Đồng thời, các luồng nghiệp vụ được xây dựng theo định hướng quy
trình này sẽ giúp tổ chức tiết kiệm nguồn lực, chí phí cũng như thời gian

16
 xử lý giao dịch, chuyển hướng dịch vụ của tổ chức theo định hướng khách
hàng.
• Giúp tổ chức tinh gọn hệ thống biểu mẫu, giảm thiểu số lượng mẫu biểu
cần quản lý.
• Nhìn ra được các mục tiêu lớn hơn cho tổ chức
• Hướng tới chuyển đổi kỹ thuật số
• Giúp doanh nghiệp xây dựng cơ cấu phân công công việc linh hoạt, phù
hợp.

Hình 12.4 - Lợi ích về chất lượng của BPM theo nghiên cứu của
BearingPoint

12.3 SỬ DỤNG KÝ HIỆU MÔ HÌNH HÓA QUY TRÌNH NGHIỆP VỤ

(BPMN) TRONG XÂY DỰNG QUY TRÌNH
Một trong 4 giai đoạn quan trọng nhất của BPM là xây dựng mô hình quy
trình kinh doanh (model business processes), hay cách hiểu đơn giản hơn là thiết
kế bảng vẽ kế hoạch. Mô hình này là cơ sở để hiểu quy trình hoạt động hiện tại
và là tư liệu để thiết kế các quy trình mới.
Trong phần này, chúng ta sẽ học về các ký hiệu tiêu chuẩn trong thiết kế bảng
vẽ kế hoạch.
12.3.1. BPMN là gì
BPMN là tập hợp các ký hiệu mô hình hóa quy trình nghiệp vụ. Nó được
dùng để mô hình hóa các bước của quy trình kinh doanh theo kế hoạch từ đầu
đến cuối để quản lý quy trình kinh doanh, mô tả trực quan một chuỗi chi tiết các
hoạt động kinh doanh và các luồng thông tin cần thiết để hoàn thành một quy
trình.

17
12.3.2. Sự cần thiết của các ký hiệu tiêu chuẩn
Khi hai công ty hợp tác với nhau, nếu họ có cách định nghĩa hoạt động khác
nhau thì sẽ tạo ra mâu thuẫn. Để giải quyết mâu thuẫn này, một tập đoàn tiêu
chuẩn công nghiệp máy tính tên Nhóm quản lý đối tượng (Object Management
Group – OMG) đã tạo ra một tập hợp các thuật ngữ và ký hiệu đồ họa tiêu chuẩn
để ghi lại các quy trình kinh doanh. Tập hợp đó được gọi là Ký hiệu mô hình hóa
quy trình kinh doanh (Business Process Modeling Notation – BPMN).
Mô tả đầy đủ về BPMN nằm ngoài phạm vi của văn bản này. Tuy nhiên, các ký
hiệu cơ bản rất dễ hiểu.

Hình 12.5 - Các ký hiệu

Hình 12.6 - Hình minh họa

12.3.3. Mục đích của BPMN

Là cầu nối thông tin giữa các bên liên quan trong quy trình nghiệp vụ, hướng
đến những người triển khai quy trình, cung cấp thông tin đầy đủ, chi tiết để triển
khai chính xác. Nó cung cấp một tiêu chuẩn và ngôn ngữ chung cho các bên liên

18
quan. Thu hẹp khoảng cách giữa kế hoạch và triển khai thực tế bằng cách cung
cấp đủ chi tiết và rõ ràng vào chuỗi các hoạt động kinh doanh.
12.3.4. Lợi ích của BPMN
➢ Cho phép nắm bắt và ghi lại quy trình nghiệp vụ của một tổ chức một
cách rõ ràng và nhất quán.
➢ Giúp doanh nghiệp xác định rõ được quy trình nghiệp vụ thông qua
các sơ đồ quy trình nghiệp vụ được biểu diễn bằng bộ ký hiệu của
BPMN.
➢ Cho phép giao tiếp và hợp tác dễ dàng hơn để đạt được mục tiêu của
một quy trình hiệu quả từ đó tạo ra kết quả chất lượng cao.
Sơ đồ mà chúng ta sử dụng ở đây được gọi là Lưu đồ (swim-lane layout).
Trong lưu đồ sẽ chia ra nhiều làn (lane), mỗi làn sẽ là một vai trò trong quy trình
kinh doanh (khách hàng, người bán, nhà sản xuất…).
Trong hình 7, ta có 5 làn tương ứng với 5 vai trò, tất cả các hoạt động của
một vai trò được hiển thị trong làn của vai trò đó. Lưu đồ giúp đơn giản hóa sơ
đồ quy trình và tập trung vào sự tương tác lẫn nhau giữa các vai trò của sơ đồ.
Trong hình 7 cũng cho thấy có hai loại mũi tên. Mũi tên nét đứt biểu diễn
hướng đi của tin nhắn và thông tin. Mũi tên nét liền thể hiện hướng đi của của
quy trình. Theo như hình 7, khách hàng gửi yêu cầu báo giá (request for
quotation) tới nhân viên bán hàng (salesperson) theo mũi tên nét đứt. Người nhân
viên đó sẽ chuẩn bị bảng giá và báo giá cho khách hàng và ta có thể theo dõi
hướng đi của quy trình theo hình trên.
Hình kim cương đại diện cho quyết định và thường được thể hiện bằng một
câu hỏi Có – Không. Hai mũi tên đi ra khỏi hình kim cương mang tên Có và
Không. Ta có thể thấy một vài Activities có mang dấu cộng (+). Điều này nghĩa
là có thêm một quy trình phụ và quy trình phụ này sẽ được giải thích chi tiết hơn
trong một lưu đồ khác.

19
Ví dụ: Quy trình đặt hàng nguyên bản (As-Is Business Order Process) hình
12.7 SGK

Hình 12.7 - Quy trình đặt hàng nguyên bản

20
Minh họa về quy trình phụ (hình 12.8 SGK)

Hình 12.8 - Quy trình kiểm tra tín dụng khách hàng
Đôi khi, biểu đồ BPMN được sử dụng để cân nhắc các lựa chọn thay thế cho
quy trình thảo luận và đánh giá. Một ứng dụng khác là ghi lại các quy trình để
đào tạo nhân viên, hoặc cung cấp thông tin cơ sở cho quy trình phát triển hệ
thống và ứng dụng.

21
12.4 VÒNG ĐỜI PHÁT TRIỂN HỆ THỐNG PHẢI TRẢI QUA CÁC GIAI
ĐOẠN NÀO?
Vòng đời phát triển hệ thống (Systems development life cycle-SDLC) là
một quy trình truyền thống dùng để phát triển các hệ thống thông tin và phần
mềm. SDLC được chia thành nhiều giai đoạn khác nhau tùy thuộc vào từng nơi.
Một vài tổ chức sẽ dùng mô hình gồm 8 giai đoạn, một vài nơi khác chia thành
7 giai đoạn. Nhưng ở đây ta sẽ xem xét SDLC dưới 5 giai đoạn:
1. Xác định hệ thống
2. Xác định yêu cầu
3. Thiết kế các thành phần của hệ thống
4. Thi hành hệ thống
5. Bảo trì hệ thống

+ Đầu tiên, việc hoạch định chiến lược kinh doanh xác định nhu cầu về hệ thống
thông tin mới sẽ dẫn đến việc bắt đầu SDLC (Giả sử rằng các nhà quản trị xác
định rõ rằng công ty sẽ đạt được các mục tiêu trong ngắn hạn và dài hạn chỉ khi
xây dựng một hệ thống thông tin mới).
+ Giai đoạn đầu của SDLC, các nhà phát triển sẽ dựa vào nhu cầu hệ thống của
các nhà quản trị để xác định rõ hệ thống mới này. Kế hoạch dự án xác định được
sẽ là đầu vào cho giai đoạn tiếp theo – xác định yêu cầu.
+ Tại giai đoạn này, các nhà phát triển sẽ xác định các đặc tính và chức năng của
hệ thống mới. Đầu ra của giai đoạn này là các yêu cầu đã được phê duyệt. Những
yêu cầu này sẽ trở thành đầu vào cho việc thiết kế các thành phần của hệ thống.
+ Ở giai đoạn 4, các nhà phát triển sẽ thi hành, kiểm nghiệm và lắp đặt hệ thống
mới này.
+ Cuối cùng, qua thời gian, người dùng sẽ phát hiện những lỗi, sai lầm và những
vấn đề phát sinh mới. Không những thế họ cũng phát sinh những nhu cầu mới
về sự thay đổi. Những phương án sửa chửa và những yêu cầu mới sẽ là đầu vào
cho giai đoạn bảo trì hệ thống. Giai đoạn bảo trì này sẽ tái khởi động lại toàn
bộ quá trình, do đó quá trình này được xem như một chu trình.
Sơ đồ sau sẽ cho ta thấy tổng quan cách các giai đoạn này liên kết với nhau:

22
Sơ đồ 12.1 - 5 giai đoạn của SDLC

23
Sau đây ta sẽ tìm hiểu chi tiết về các giai đoạn này:
12.4.1 XÁC ĐỊNH HỆ THỐNG

Sơ đồ 12.2 - Giai đoạn Xác định hệ thống

Để đáp ứng nhu cầu về hệ thống thông tin mới, tổ chức sẽ chỉ định một vài nhân viên,
có thể là trong diện bán thời gian thành một nhóm để xác định hệ thống, đánh giá mức
độ khả thi và lên kế hoạch cho dự án. Đối với các tổ chức lớn thì phòng hệ thống thông
tin sẽ dẫn dắt nhóm và nhóm sẽ gồm cả người dùng và các chuyên gia về hệ thống thông
tin. Còn trong các tổ chức nhỏ hơn nhóm sẽ được dẫn dắt bởi quản lý của phòng hệ
thống thông tin.
12.4.1.1 Xác định rõ mục tiêu và phạm vi của hệ thống:
Như bảng trên chúng ta đã thấy, bước đầu tiên là xác định rõ mục tiêu và phạm vi
của hệ thống thông tin mới này. Hệ thống thông tin được tạo ra nhằm tạo điều kiện
cho chiến lược cạnh tranh của doanh nghiệp thông qua việc nâng cao quy trình kinh
doanh. Do đó, nhóm phát triển trong bước này phải định rõ mục tiêu và mục đích của
hệ thống.

12.4.1.2 Đánh giá mức độ khả thi:

Khi đã xác định được mục tiêu và phạm vi của hệ thống, bước tiếp theo là đánh giá
mức độ khả thi. Mục đích của bước này nhằm loại bỏ những dự án không hợp lí trước

24
khi thành lập đội dự án và tuyển dụng một lượng lớn nhân công cho dự án này. Chúng
ta sẽ có 4 khía cạnh cần phải đánh giá: Chi phí, lịch trình, công nghệ và tổ chức.
(Lưu ý: Bởi vì quá trình phát triển một hệ thống thông tin rất khó để lên kế hoạch tài
chính và lên lịch trình, dự báo về chi phí và lịch trình chỉ mang tính tương đối).
• Tính khả thi về chi phí (cost feasibility) là một đánh giá xem liệu các lợi ích
dự kiến mà hệ thống mang lại có bảo đảm cho chi phí phát triển và vận hành nó
không. Trong một số trường hợp, nó còn bao gồm việc xem xét dự án đấy có
được hoàn thành trong ngân sách đã cho hay không.
• Tính khả thi về lịch trình (schedule feasibility): Giống như tính khả thi về chi
phí, tính khả thi về lịch trình rất khó để xác định vì thời gian để hoàn thành hệ
thống không đoán định chính xác được.
• Tính khả thi về công nghệ (technical feasibility) quan tâm đến vấn đề các công
nghệ hiện hành có đáp ứng được nhu cầu của hệ thống hay không.
• Tính khả thi về tổ chức (organizational feasibility) xem xét việc liệu rằng
phần mềm khi ra mắt có phù hợp với truyền thống, văn hóa làm việc, điều lệ hay
yêu cầu pháp lý của tổ chức hay không.

12.4.1.3 Thành lập đội dự án:

Nếu như dự án đã được xác định là khả thi, bước tiếp theo sẽ là thành lập một đội
dự án. Thông thường đội này sẽ bao gồm chuyên gia về hệ thống thông tin và đại diện
phía người dùng. Những nhân sự tiêu biểu của đội này bao gồm nhà quản lý, nhà phân
tích kinh doanh, nhà phân tích hệ thống, lập trình viên, chuyên viên kiểm thử phần mềm
và người dùng.
Thành phần của nhóm có thể thay đổi theo thời điểm phát triển của hệ thống:
➢ Trong quá trình định nghĩa yêu cầu, công việc sẽ chú trọng vào phân tích hệ
thống và phân tích kinh doanh.
➢ Trong quá trình thiết kế và vận hành, công việc chủ yếu được thực hiện bởi các
lập trình viên, nhà kiểm thử và nhà thiết kế cơ sở dữ liệu.
➢ Quá trình tích hợp và chuyển đổi sẽ được tăng cường với nhà kiểm thử và người
dùng.
Người dùng có sự ảnh hưởng rất lớn đến quá trình phát triển hệ thống. Tùy thuộc
vào quy mô và bản chất dự án, người dùng có thể tham gia vào dự án toàn thời gian hay
bán thời gian. Điểm quan trọng là người dùng phải ảnh hưởng tích cực và nắm
quyền sở hữu xuyên suốt quá trình phát triển hệ thống.
Nhiệm vụ đầu tiên của nhóm được thành lập là lên kế hoạch cho dự án. Các thành
viên trong nhóm cần chỉ định nhiệm vụ cần hoàn thành, phân công nhân sự, xác định
các yếu tố phụ thuộc nhiệm vụ và lên lịch trình.

25
12.4.2 XÁC ĐỊNH YÊU CẦU:
Xác định yêu cầu của hệ thống là công việc quan trọng nhất trong cả quá trình.
Nếu yêu cầu được xác định sai, hệ thống sẽ hoạt động sai. Nếu yêu cầu được xác định
chính xác, công việc phát triển hệ thống sẽ trở nên dễ dàng hơn và tỷ lệ thành công cao
hơn.

Sơ đồ 12.3 – Giai đoạn Xác định yêu cầu

12.4.2.1 Các nguồn của yêu cầu:
Đầu tiên chúng ta sẽ đi tìm hiểu yêu cầu là gì. Ví dụ trong thiết kế web, yêu cầu là
nội dung và định dạng của trang web đó, chức năng các nút trên trang, cấu trúc và nội
dung báo cáo, các trường và lựa chọn trong mục nhập dữ liệu. Yêu cầu không chỉ bao
gồm về việc thành quả đạt được mà cả tần suất và tốc độ công việc được hoàn
thành. Một số yêu cầu quy định khối lượng dữ liệu được lưu trữ và xử lý.
Thông thường, nhà phân tích hệ thống phỏng vấn người dùng và ghi lại kết quả theo
một số cách nhất quán. Kỹ năng phỏng vấn và đặt vấn đề rất quan trọng vì người dùng
thường khó có thể mô tả rõ những gì họ muốn và cần. Những người phân tích hệ thống
dày dặn kinh nghiệm thường biết cách thực hiện những cuộc phỏng vấn để có thể làm
rõ những yêu cầu của người dùng.
Như chúng ta có thể thấy ở sơ đồ trên, những nguồn yêu cầu bao gồm những hệ
thống hiện hành cũng như các trang web, form/report/querrie, tính năng và chức năng
của các ứng dụng mới mà hệ thống cần có.
Đôi khi, chúng ta quá tập trung vào phần mềm và các thành phần của dữ liệu mà bỏ
quên những thành phần khác. Ví dụ: khi nói đến phần cứng có thể có các vấn đề nảy
sinh như sau: Có nhu cầu hoặc hạn chế đặc biệt nào cho phần cứng không?

26
 Tương tự, nhóm cũng nên xem xét những yêu cầu về thủ tục và nhân sự như: Kiểm
soát kế toán có cần những thủ tục để tách bạch nghĩa vụ và quyền hạn hay không? Nói
tóm lại, tất cả yêu cầu về thành phần của hệ thống thông tin mới nên đều được
xem xét.

12.4.2.2 Vai trò của prototype:

Bởi vì người dùng tương lai của hệ thống thường gặp khó khăn trong việc hiểu và
đề cập đến các yêu cầu bằng lời hay phác thảo ra nó, một prototype vận hành tốt sẽ cung
cấp những trải nghiệm trực tiếp cho họ. Khi họ làm việc với prototype, người dùng sẽ
đánh giá khả năng sử dụng và ghi nhớ tính năng và chức năng mà họ quên đề cập đến.
Không những thế, prototype cung cấp căn cứ cho việc đánh giá khả thi về công nghệ và
tổ chức của hệ thống.
Để trở nên hữu dụng, prototype phải hoạt động. Prototype cần cung cấp cho người
dùng trải nghiệm sử dụng hệ thống để thực hiện nhiệm vụ của họ.
Prototype có thể khá đắt đỏ để tạo nên nhưng mức chi phí này thường được chấp
nhận không chỉ vì sự rõ ràng và hoàn thiện của yêu cầu mà còn vì các thành phần của
prototype có thể có thể được tái sử dụng trong hệ thống vận hành.
Thật không may, nhà phát triển hệ thống phải đối mặt với tình trạng khó xử khi tài
trợ cho prototype: “Chúng ta cần prototype để tìm kiếm nguồn vốn và chúng ta cần
nguồn vốn để tạo ra prototype”. Không có giải pháp thống nhất nào cho tình trạng này
ngoại trừ việc áp dụng trực giác và kinh nghiệm. Qua đây ta thấy tầm quan trọng của kĩ
năng giải quyết các vấn đề đặc biệt.

12.4.2.3 Chấp thuận yêu cầu:

Sau khi các yêu cầu đã được xác định, người dùng phải duyệt và chấp thuận chúng
trước khi quá trình tiếp diễn. Thời điểm ít tốn kém và dễ dàng để thay đổi hệ thống nhất
là giai đoạn yêu cầu. Thay đổi các yêu cầu vào giai đoạn thực hiện có thể mất rất nhiều
thời gian để làm lại các thành phần của phần mềm và cấu trúc dữ liệu.

12.4.3 THIẾT KẾ CÁC THÀNH PHẦN CỦA HỆ THỐNG

27
 Sơ đồ 12.4 - Giai đoạn Thiết kế các thành phần của hệ thống
Mỗi 5 thành phần của hệ thống đều được thiết kế trong giai đoạn này. Nhóm sẽ thiết
kế mỗi hệ thống bằng cách phát triển các lựa chọn thay thế nhau, đánh giá các lựa chọn
này với yêu cầu đặt ra và lựa chọn trong số các phương án này. Chính vì thế độ chính
xác của yêu cầu rất quan trọng ở đây do nếu các yêu cầu chưa hoàn thành hoặc sai,
chúng sẽ là các tiêu chí sai lầm để đánh giá các lựa chọn.
Bảng trên cho ta thấy thiết kế các nhiệm vụ liên quan đến 5 thành phần của hệ thống
thông tin.
• Với phần cứng, nhóm sẽ xác định thông số kỹ thuật cần thiết cho hệ thống (Lưu
ý nhóm sẽ không thiết kế phần cứng kiểu CPU hay các ổ đĩa).
• Thiết kế phần mềm phụ thuộc vào nguồn của phần mềm. Với các phần mềm,
nhóm phải xác định các sản phẩm tiềm năng và đánh giá chúng theo các yêu cầu.
+ Đối với các phần mềm bán sẵn có lựa chọn thay thế, nhóm xác định các sản
phẩm được mua ngoài giá bán và xác định các thay đổi cần thiết.
+ Đối với các phần mềm được thiết kế tùy ý, nhóm sẽ sản xuất tài liệu thiết kế
để viết mã phương trình.
Nếu như dự án bao gồm việc xây dựng cơ sở dữ liệu thì trong giai đoạn này, nhà
thiết kế cơ sở dữ liệu sẽ chuyển dổi mô hình dữ liệu sang thiết kế cơ sở dữ liệu bằng các
kỹ thuật. Nếu dự án liên quan đến các phần mềm bán sẵn, các cơ sở dữ liệu nhỏ cần
được thực hiện; phần mềm cần được mã hóa để hoạt động với các thiết kế cơ sở dữ liệu
đã có từ trước.
Thủ tục thiết kế thì có chút khác biệt, tùy thuộc vào dự án là một phần của quá trình
quản lý quy trình kinh doanh hay quá trình phát triển hệ thống.
• Nếu là quá trình quản lý quy trình kinh doanh, thì quy trình kinh doanh đã được
thiết kế sẵn, và mọi thứ cần làm là tạo ra một quy trình để sử dụng các phần
mềm.

28
 • Nếu là quá trình phát triển hệ thống, thì quy trình để sử dụng hệ thống cần được
phát triển và cả quy trình kinh doanh xung quanh hệ thống nếu cần thiết.
Đối với con người, thiết kế bao gồm các mô tả chi tiết công việc cho các vai trò
khác nhau. Các mô tả này sẽ thể hiện chi tiết các trách nhiệm, kĩ năng cần thiết, các quá
trình huấn luyện được đòi hỏi,...

12.4.4 THI HÀNH HỆ THỐNG

Thuật ngữ thi hành hệ thống có hai ý nghĩa. Ý nghĩa thứ nhất là chỉ thi hành các
thành phần của hệ thống. Nó còn có ý nghĩa khác là thực hiện các hệ thống thông tin và
những quy trình kinh doanh sử dụng hệ thống đó. Bảng sau sẽ cho ta thấy chi tiết các
nhiệm vụ của quy trình này theo cả hai cách hiểu. Nhiệm vụ trong giai đoạn thi hành hệ
thống này bao gồm xây dựng và kiểm thử các thành phần của hệ thống, chuyển đổi
người dùng sang hệ thống mới và có thể cả quy trình kinh doanh mới.

Sơ đồ 12.5 - Giai đoạn Thi hành hệ thống

12.4.4.1 Kiểm thử:
Kiểm thử là một quá trình quan trọng, cần nhiều thời gian và đắt đỏ. Một kế hoạch
kiểm thử là một bản mô tả chính thức chi tiết về các phản hồi của hệ thống đối với các
trường hợp sử dụng và lạm dụng. Trong quá trình này, các nhà phát triển xây dựng từng
thành phần độc lập của hệ thống.
• Cài đặt và kiểm tra các phần cứng.
• Cấp phép và cài đặt các chương trình có sẵn và sẽ thích ứng, tùy chỉnh các
chương trình nếu cần thiết.

29
 • Tìm kiếm tài liệu, duyệt và kiểm tra các thủ tục và xây dựng các chương trình
đào tạo.
• Cuối cùng tổ chức sẽ thuê và đào tạo các nhân sự cần thiết.
Khi các thành phần đã được kiểm tra một cách độc lập, toàn bộ hệ thống sẽ được
kiểm thử và tất cả sẽ được chuyển đổi sang hệ thống mới.

12.4.4.2 Sự chuyển đổi hệ thống:

Khi hệ thống đã vượt qua được quá trình thử nghiệm, tổ chức sẽ lắp đặt hệ thống
mới này. Thuật ngữ “sự chuyển đổi hệ thống” thường được sử dụng nhằm ngụ ý rằng
quá trình chuyển đổi quy trình kinh doanh từ hệ thống cũ sang hệ thống mới. Lưu ý rằng
sự chuyển đổi chỉ dùng cho hệ thống mới hoặc trong một số trường hợp, bao gồm cả
quy trình kinh doanh mới. Có 4 loại quy trình chuyển đổi là: Thí điểm, theo từng giai
đoạn, song song và “liều lĩnh”. 3 lựa chọn đầu thường được các công ty áp dụng. Các
công ty sẽ tránh sự liều lĩnh ở lựa chọn 4.
+ Về lắp đặt thí điểm: tổ chức sẽ thi hành toàn bộ hệ thống/quy trình kinh doanh
mới ở một một phòng ban nhất định. Ưu điểm của hình thức này là nếu hệ thống gặp
thất bại, hậu quả sẽ chỉ giới hạn ở một số phần mà hệ thống được lắp đặt.
+ Lắp đặt từng giai đoạn: toàn bộ hệ thống/quy trình kinh doanh mới sẽ được lắp
đặt theo từng quy trình. Khi một thành phần hoạt động tốt, tổ chức sẽ lắp đặt và kiểm
thử các thành phần khác cho đến khi toàn bộ hệ thống được lắp đặt. Với những hệ thống
được tích hợp chặt chẽ, cần được lắp đặt với các công nghệ khác.
+ Lắp đặt song song, toàn bộ hệ thống/quy trình kinh doanh mới sẽ hoạt động song
song với các hệ thống/quy trình kinh doanh cũ cho đến khi toàn bộ hệ thống đã được
thử nghiệm và vận hành hoàn toàn. Lắp đặt song song tốn rất nhiều chi phí, do vậy ta
cần phải làm việc đáng kẻ để điều hòa hoạt động của hệ thống mới và hệ thống cũ.
+ Cuối cùng là lắp đặt “liều lĩnh” (Hay còn gọi là lắp đặt trực tiếp). Với phương
án này, tổ chức ngưng hoạt động các hệ thống cũ và chuyển đổi sang hệ thống mới. Nếu
hệ thống mới thất bại, toàn bộ công việc sẽ bị ngưng trệ. Do đó, tổ chức nên tránh
chuyển đổi bằng phương án này. Có một ngoại lệ là hệ thống mới không làm gián đoạn
hoạt động của tổ chức nếu nó không thành công.
Sau đây là bảng tóm tắt hoạt động thiết kế và thi hành 5 thành phần của hệ thống:
Phần cứng Phần mềm Dữ liệu Thủ tục Nhân sự
Chọn các Phát triển
Thiết kế
phần mềm Thiết kế cơ các bản mô
Xác định các thủ tục
có sẵn. sở dữ liệu tả chi tiết
thông số vận hành
Thiết kế Thiết kế và và các cấu công việc
kỹ thuật và thủ tục
tùy chỉnh trúc có liên vận hành
phần cứng. cho người
lại nếu cần quan. và người
dùng.
thiết. dùng.

30
 Cấp phép
và cài đặt
Tìm kiếm
các chương
tài liệu,
trình có
Tạo cơ sở duyệt và
sẵn và sẽ
Cài đặt và dữ liệu. kiểm tra Tuyển
thích ứng,
kiểm tra Điền dữ các thủ tục dụng và
Thi hành tùy chỉnh
các phần liệu và và họ xây đào tạo
các chương
cứng. kiểm thử dựng các nhân công.
trình nếu
dữ liệu. chương
cần thiết.
trình đào
Kiểm thử
tạo.
chương
trình.
Bảng 12.2 - Hoạt động Thiết kế và Thi hành 5 thành phần của hệ thống (Giáo trình
– Figure 12-14)
12.4.5 BẢO TRÌ HỆ THỐNG

Sơ đồ 12.6 - Giai đoạn Bảo trì hệ thống

Bảo trì trong hệ thống thông tin không phải là sửa chữa hệ thống hay điều chỉnh hệ
thống thay đổi theo yêu cầu. Bảng trên cho ta thấy các nhiệm vụ trong giai đoạn bảo trì
này:
Đầu tiên, cần phải có một phương tiện để theo dõi cả lỗi và cải tiến để đáp ứng các
yêu cầu. Với các hệ thống nhỏ, tổ chức sẽ sử dụng hệ thống xử lý văn bản để theo dõi
các lỗi và nhu cầu cải tiến. Tuy nhiên nếu hệ thống trở nên lớn hơn, các lỗi và yêu cầu

31
cải tiến cũng tăng lên, nhiều tổ chức thấy cần thiết để xây dựng một cơ sở dữ liệu để
theo dõi các yêu cầu này. Cơ sở dữ liệu này còn ghi lại người báo cáo sự cố, người sẽ
sửa chữa sự cố hay cải tiến, tình trạng công việc đó và liệu bản sửa lỗi hoặc cải tiễn đã
được kiểm tra và xác minh bởi người khởi tạo hay chưa.
Thông thường, các nhân sự hệ thống thông tin sẽ sắp xếp mức độ ưu tiên của vấn
đề theo tính nghiêm trọng của nó. Họ sẽ sữa chữa các vấn đề ưu tiên càng sớm càng tốt
và họ sẽ sửa chữa các vấn đề ít nghiêm trọng hơn khi thời gian và nguồn lực cho phép.
Bởi vì sự cải tiến là sự thích ứng với các yêu cầu mới, nhà phát triển thường ưu tiên
các yêu cầu cải tiến hơn và tách bạch với sửa chữa các lỗi. Quyết định cải tiến bao gồm
các quyết định kinh doanh rằng liệu tỷ suất lợi nhuận sinh ra có chấp thuận được hay
không.
➔ Ví dụ về các giai đoạn trong SDLC

Case study lần này liên quan đến việc lựa chọn một gói phần mềm của một bệnh viện
khu vực có quy mô vừa (bệnh viện General Hospital) để sử dụng trong phân khúc Home
Health. General sở hữu một Trung tâm chẩn đoán chỉnh hình, một bệnh viện phục hồi
chức năng, bốn phòng khám chăm sóc ban đầu, một trung tâm sức khỏe và thể hình
(một trong những trung tâm lớn nhất cả nước với hơn 70.000 mét vuông và 7.000 thành
viên), một trung tâm phục hồi vết thương, khu Trung tâm Trị liệu và Chăm sóc Tại nhà
– Home Health (tâm điểm của nghiên cứu này). Bên cạnh đó, Có hơn 120 bác sĩ trong
đội ngũ nhân viên y tế đang hoạt động, hơn 1.400 nhân viên và hơn 100 tình nguyện
viên (“General Hospital”, 2010).

Chăm sóc sức khỏe tại nhà (Home Health), là việc chăm sóc sức khỏe được thực hiện
tại nhà. Thay vì phải đi đến bệnh viện, bệnh nhân tự đo huyết áp (hoặc nhịp tim, mức
đường huyết, v.v.) bằng một thiết bị được nối gần giường của họ ở nhà. Kết quả được
truyền đến bệnh viện (hoặc trong trường hợp này là Cơ sở Y tế Tại nhà gần General
Hospital) theo phương thức điện tử và ngay lập tức được xử lý, kiểm tra và giám sát bởi
nhân viên trực tiếp.

Ngoài ra, có một tính năng Lifeline có sẵn cho người cao tuổi hoặc những người ở nhà
khác. Thiết bị này bao gồm một nút đeo trên vòng cổ hoặc vòng tay mà bệnh nhân có
thể ấn vào nếu họ cần hỗ trợ (“Home Health”, 2010). Định kỳ, bác sĩ lâm sàng (ví dụ:
y tá, nhà vật lý trị liệu, v.v.) sẽ đến thăm bệnh nhân tại nhà của họ để theo dõi tiến trình
của họ và thực hiện kiểm tra và bảo trì định kỳ đối với công nghệ.

32
Giờ đây, ban giám đốc bệnh viện cần một phần mềm để tạo điều kiện và giúp điều phối
bộ phận Home Health tại nhà trong công việc kinh doanh của họ.

Xác định hệ thống

Thứ nhất, bộ phận Home Health của General Hospital đã được tổ chức lại thành một
đơn vị trực thuộc riêng biệt nằm gần bệnh viện chính (có cơ sở độc lập).

Thứ hai, các phần mềm họ đang sử dụng đã có tuổi đời ít nhất là bảy năm và chỉ đơn
giản là không thể theo kịp tất cả những thay đổi trong thực tiễn lập hóa đơn cũng như
các yêu cầu và thanh toán của Medicare. Do đó, ngoài các tiêu chí mong muốn cụ thể
của phần mềm (được mô tả trong phần sau), có 2 mục đích rõ ràng: 1) Hiện đại hóa hoạt
động của họ với công nghệ hiện tại; và 2) Cung cấp dịch vụ chăm sóc bệnh nhân tốt
nhất hiện có cho khách hàng của họ trong lĩnh vực Home Health.

Đánh giá mức độ khả thi:

Tính khả thi về công nghệ: Chúng ta có các nguồn lực và cơ sở hạ tầng cần thiết để hỗ
trợ phần mềm nếu nó được mua lại không? => Cơ sở hạ tầng CNTT của General đã quá
đầy đủ và cập nhật liên quan đến việc hỗ trợ phần mềm mới

Tính khả thi về chi phí: Chúng ta có đủ nguồn tài chính để trả cho nó, bao gồm cả hỗ
trợ và bảo trì không? => Giám đốc công nghệ thông tin Sẵn sàng chi 250000 USD

Tính khả thi về hoạt động, tổ chức: Chúng ta có các cá nhân được đào tạo thích hợp để
có thể vận hành và sử dụng phần mềm không? => Nhân viên hỗ trợ và người dùng cuối
tiềm năng đã được đào tạo bài bản và nhiệt tình về việc áp dụng công nghệ mới

Phân tích yêu cầu:

Một trong những yêu cầu quan trọng nhất là tương thích với MEDITECH, kế đến là
OASIS Analyzer và một số điều “Phải có” khác của phần mềm mới: Các mô-đun lập
hóa đơn và tài khoản phải thu đặc biệt được điều chỉnh cho phù hợp với Home Health;
cổng thông tin bác sĩ; tối ưu hóa lịch trình; và cuối cùng không kém phần quan trọng,
hệ thống phải thân thiện với người dùng.

Một số hạng mục khác cần quan tâm trong giai đoạn này là:

33
Có các mô-đun khác có sẵn không (ví dụ: tài chính, y tế, bệnh viện tế bần; các ứng dụng
để đồng bộ hóa hệ thống với PDA (Trợ lý kỹ thuật số cá nhân) hoặc điện thoại thông
minh)?

Có một bản trình diễn web có sẵn để xem trực tuyến; hoặc tốt hơn nữa là có cơ hội tham
gia trình diễn trực tiếp phần mềm trong điều kiện thực tế hoặc mô phỏng không?

Cuối cùng, là đánh giá từng nhà cung cấp như một người vào vòng chung kết tiềm năng.
Ví dụ: Nhà cung cấp A có Nhóm triển khai / Cài đặt để hỗ trợ giai đoạn triển khai phần
mềm. Nhà cung cấp C đã tài trợ một Hội nghị người dùng hàng năm, nơi người dùng
có thể chia sẻ kinh nghiệm sử dụng sản phẩm, cũng như cung cấp phản hồi để đưa vào
các bản phát hành trong tương lai. Để đạt được điều đó, Nhà cung cấp C cũng có đại
diện người dùng trong Ban cố vấn sản phẩm của họ. Nhà cung cấp E đưa ra lựa chọn
"điện toán đám mây", trong đó sản phẩm được lưu trữ trong trung tâm dữ liệu của họ.
(Người mua tiềm năng không cần phải chọn giải pháp hỗ trợ web). Sản phẩm của nhà
cung cấp E là một phần của giải pháp doanh nghiệp và có thể được đồng bộ hóa với
PDA hoặc điện thoại thông minh.

Thiết kế

Như đã lưu ý trước đây, đối với nghiên cứu điển hình cụ thể về lựa chọn phần mềm này,
các nhà nghiên cứu không phải tiến hành từng bước của SDLC vì các sản phẩm phần
mềm đã tồn tại, giai đoạn Thiết kế của SDLC đã được thực hiện bởi các nhà cung cấp.
Do đó, sau khi cẩn thận phân tích tất cả các sản phẩm, tính năng, ưu và nhược điểm
cũng như chi phí và lợi ích liên quan đến từng sản phẩm, giờ đây việc cần làm là đưa ra
lựa chọn: phân tích danh sách năm nhà cung cấp tiềm năng thành hai nhà cung cấp có
thể đáp ứng các nhu cầu được đưa và cho thấy sự quan tâm nhiều nhất.

Sự lựa chọn

Ban lãnh đạo điều tra đã sắp xếp một cuộc họp khác với các bên liên quan chính của bộ
phận Home Health của General. Vì họ là những người sẽ sử dụng hệ thống trong tương
lai gần, việc lựa chọn chỉ có ý nghĩa khi họ tham gia trong toàn bộ quá trình. Sau khi
xem xét cẩn thận, quyết định được đưa ra đó là sẽ mời Nhà cung cấp B đến thăm địa
điểm và buổi mô phỏng.

34
Nhà cung cấp B rất chuyên nghiệp, lịch sự, nhanh chóng và tận tâm trong chuyến thăm
của họ. Một lợi thế rất lớn là mô hình kinh doanh chính của họ tập trung vào phần mềm
Home Health. Ngược lại, một nhà cung cấp khác (không có trong danh sách 5 người
ban đầu của chúng tôi) đã đến và trình bày rất bóng bẩy, theo lời của Giám đốc. Tuy
nhiên, công ty này có rất nhiều mối quan tâm hàng tỷ đô, trong đó phần mềm Home
Health chỉ là một phần nhỏ. Do đó, lựa chọn đã được thực hiện với Nhà cung cấp B.

Không may, sản phẩm của nhà cung cấp B không tương thích với Meditech, đây là một
trong những tiêu chí quan trọng nhất để lựa chọn. Tuy nhiên, thông qua việc sử dụng
một công ty phần mềm trung gian có kinh nghiệm đáng kể trong việc thiết kế giao diện
để sử dụng trong môi trường Meditech, vấn đề đã được giải quyết và một giải pháp tùy
chỉnh đã được phát triển và đưa vào sử dụng. Nhà cung cấp phần mềm trung gian đã
kinh doanh với General trước đây và do đó, họ đã quen với nhu cầu của họ.

Thi hành

Bộ phận Home Health của General đã tiến hành Lắp đặt song song trong khoảng 60
ngày trước ngày “hoạt động”. Các bác sĩ lâm sàng sẽ “nhập hai lần” hồ sơ bệnh nhân
và dữ liệu nhập viện vào cả hệ thống cũ và hệ thống mới để đảm bảo rằng cơ sở dữ liệu
mới đã được điền vào, đồng thời duy trì việc chăm sóc bệnh nhân với sản phẩm cũ cho
đến khi sử dụng được. Giám đốc của cơ sở Chăm sóc tại nhà lưu ý rằng quá trình này
mất nhiều thời gian hơn dự kiến nhưng rất xứng đáng về lâu dài. Sau khi đến ngày "hoạt
động", hệ thống mới hoạt động khá tốt, với một lượng gián đoạn tối thiểu.

Việc đào tạo nhân viên được bắt đầu hai tuần trước ngày "hoạt động". Các bác sĩ lâm
sàng đã phải thực hiện một cuộc thăm khám trực tiếp với một trong những bệnh nhân
của họ bằng cách sử dụng hệ thống mới. Vì vậy, họ đã có kinh nghiệm với nó trong môi
trường thực hành trước khi chuyển sang sản phẩm mới và cam kết toàn thời gian.

Bảo trì

Nâng cấp phần mềm (được nhà cung cấp gọi là “tải mã”) được thực hiện sáu tuần một
lần. Giám đốc báo cáo rằng những tiến bộ này không làm gián đoạn hoạt động hàng
ngày. Giám đốc cũng cho biết tất cả người dùng cuối, bao gồm y tá, nhà vật lý trị liệu,
bác sĩ và các nhân viên khác, rất hài lòng với hệ thống mới và nhìn chung, không có bất

35
kỳ phàn nàn nào về nó. General kỳ vọng sẽ sử dụng phần mềm này trong tương lai gần,
không có kế hoạch bắt tay vào một dự án tầm cỡ khác trong một thời gian khá dài.

MỘT SỐ MÔ HÌNH CỦA SDLC

Mô hình thác nước - Waterfall
Thác nước là một mô hình SDLC được chấp nhận rộng rãi. Trong mô hình tuyến tính
này, kết quả của một giai đoạn đóng vai trò là đầu vào cho giai đoạn tiếp theo.
Mô hình SDLC này đòi hỏi nhiều tài
liệu, với các giai đoạn trước đó ghi lại
những gì cần được thực hiện trong các
giai đoạn tiếp theo. Tuy nhiên, nó dễ bị
trì hoãn và có thể dẫn đến các vấn đề lớn
phát sinh cho các nhóm phát triển dù chỉ
với các chi tiết nhỏ chưa hoàn thiện
trong một giai đoạn nào đó.
Hình 12.9 - Mô hình thác nước

Mô hình chữ V trong SDLC

Mô hình này tương tự như mô hình thác nước, nó thể hiện sự phụ thuộc của từng giai
đoạn trong SDLC. Sự khác biệt ở đây là chúng được biểu diễn dưới dạng hình chữ V
chứ khộng phải là mô hình tuyến tính. Với mô hình chữ V, toàn bộ qui trình được chia
thành hai nhóm giai đoạn tương ứng
nhau: phát triển và kiểm thử. Mỗi giai
đoạn phát triển sẽ kết hợp với một giai
đoạn kiểm thử tương ứng.
Mô hình này hoạt động tốt cho các dự án
đòi hỏi nhiều sự kiểm soát và có các yêu
cầu được xác định rõ ràng và không thay
đổi.
Hình 12.10 - Mô hình chữ V

Mô hình Agile trong SDLC

Mô hình Agile ưu tiên các chu kỳ phát hành
nhanh và liên tục, sử dụng các thay đổi nhỏ
nhưng gia tăng giữa các bản phát hành. Điều
này dẫn đến nhiều lần lặp lại và nhiều thử
nghiệm hơn so với các mô hình khác. Về mặt
lý thuyết, mô hình này giúp các nhóm giải
quyết các vấn đề nhỏ khi chúng phát sinh Hình 12.11 - Mô hình Agile

36
thay vì bỏ sót chúng cho đến các giai đoạn phức tạp hơn của một dự án.
Hạn chế của mô hình này là quá chú trọng vào tương tác với khách hàng có thể dẫn dự
án đi sai hướng trong một số trường hợp.
Mô hình xoắn ốc
Mô hình xoắn ốc là một mô hình phức tạp nhất trong số các mô hình SDLC những cũng
là phương pháp linh hoạt nhất. Mô hình SDLC này giúp nhóm áp dụng các yếu tố của
một hoặc nhiều mô hình quy trình như thác nước
(Waterfall) hoặc Agile, v.v.
Trong phương pháp xoắn ốc, không phải mọi dự
án đều có số vòng lặp giống nhau. Khi bắt đầu
mỗi vòng lặp hoặc giai đoạn, nhóm phải xem xét
lại các mục tiêu và rủi ro của dự án, phát triển
phiên bản tiếp theo của sản phẩm, sau đó xem
xét và lập kế hoạch cho giai đoạn tiếp theo.
Bởi vì nó rất năng động và linh hoạt, cần phải
biết rõ ai phụ trách từng dự án, cách xác định số
lượng vòng lặp và giai đoạn nào cần được lặp lại. Hình 12.12 - Mô hình xoắn ốc
12.4.6. Lợi ích của SDLC:
• Nó cung cấp cơ sở để lập kế hoạch, lập lịch trình và ước tính dự án

• Cung cấp một khuôn khổ cho một tập hợp các hoạt động và các sản phẩm tiêu
chuẩn
• Nó là một cơ chế để theo dõi và kiểm soát dự án
• Tăng khả năng hiển thị của lập kế hoạch dự án cho tất cả các bên liên quan có
liên quan của quá trình phát triển
• Tăng và nâng cao tốc độ phát triển
• Cải thiện quan hệ khách hàng
• Giúp bạn giảm thiểu rủi ro dự án và chi phí kế hoạch quản lý dự án

12.5 CHÌA KHÓA THÀNH CÔNG CỦA DỰ ÁN SDLC LÀ GÌ?

5 Yếu tố chủ yếu dẫn đến sự thành công của SDLC
- Tạo cấu trúc phân chia công việc (WBS).
- Ước tính thời gian và chi phí.
- Tạo lập kế hoạch dự án.
- Điều chỉnh kế hoạch thông qua sự đánh đổi.
- Quản lý các thách thức phát triển.

1. Tạo cấu trúc phân chia công việc (WBS)

37
 Chiến lược quan trọng cho dự án SDLC là phân chia và chinh phục. Hầu
hết các dự án thường rất lớn và phức tạp cũng như mất nhiều thời gian để thực
hiện. Vì vậy các nhà quản lý sẽ chia dự án thành các nhiệm vụ nhỏ hơn để dễ
dàng ước tính và quản lý. Mỗi nhiệm vụ nên đạt đến đỉnh điểm của một hoặc
nhiều kết quả được gọi là giao phẩm (deliverables). Ví dụ về giao phẩm có thể
kể đến là: tài liệu, báo cáo, thiết kế, nguyên mẫu, ... Nếu giao phẩm không được
xác định, không thể biết liệu nhiệm vụ đã được hoàn thành hay chưa.
Để các nhiệm vụ được giao trong dự án được rõ ràng và rành mạch thì cần
tạo ra một cấu trúc phân chia công việc (WBS) - là một hệ thống phân cấp các
nhiệm vụ cần thiết để thực hiện một dự án.

Hình 12.13 - Sơ đồ Gantt cho giai đoạn xác định

2. Ước tính thời gian và chi phí
Các tổ chức thực hiện nhiều cách tiếp cận khác nhau. Một là tránh hoàn toàn các vấn
đề về lịch trình và không bao giờ phát triển các hệ thống và phần mềm trong nhà. Thay
vào đó, họ cấp phép các gói (packages), chẳng hạn như hệ thống ERP, bao gồm cả quy
trình kinh doanh và các thành phần của hệ thống thông tin.
Nhưng điều gì sẽ xảy ra nếu không có gói phù hợp tồn tại? Trong trường hợp này,
các công ty có thể thừa nhận sự bất khả thi của việc lên lịch ngày hoàn thành toàn bộ hệ
thống và sử dụng kết quả tốt nhất mà họ có thể nhận được.
Cách tiếp cận thứ ba là cố gắng lên lịch cho dự án phát triển bất chấp mọi khó khăn.
Một số kỹ thuật ước lượng khác nhau có thể được sử dụng.

38
 • Nếu dự án tương tự như một dự án trong quá khứ, dữ liệu lịch trình từ dự án quá
khứ đó có thể được sử dụng để lập kế hoạch.
• Nếu không có dự án trong quá khứ như vậy, các nhà quản lý phải đưa ra những
ước tính tốt nhất mà họ có thể. Các quy trình, thủ tục, cơ sở dữ liệu và các thành
phần khác phải được ước tính bằng các phương pháp khác nhau.
3. Tạo lập kế hoạch dự án.
Kế hoạch dự án là một danh sách các nhiệm vụ trong WBS, được sắp xếp để tính
đến các phụ thuộc của nhiệm vụ, với thời lượng và nguồn lực được áp dụng. Một số
nhiệm vụ không thể được bắt đầu hoặc kết thúc cho đến khi các nhiệm vụ khác được
hoàn thành. Ví dụ: không thể đặt dây điện trong nhà cho đến khi xây xong bức tường.
Chúng ta có thể xác định mối quan hệ phụ thuộc giữa các nhiệm vụ trong dự án trong
phần mềm lập kế hoạch như Microsoft Project, và nó sẽ sắp xếp kế hoạch sao cho phù
hợp.

Hình 12.14 - Sơ đồ Gantt về giai đoạn xác định của dự án trong WBS
Biểu đồ Gantt trên đây hiển thị các nhiệm vụ, ngày tháng và tính phụ thuộc giữa các
nhiệm vụ.
Người dùng đã nhập tất cả các nhiệm vụ từ WBS và đã chỉ định thời hạn cho mỗi
nhiệm vụ. Ngoài ra người dùng cũng đã chỉ định tính phụ thuộc của các nhiệm vụ. Hai
mũi tên màu đỏ xuất hiện từ nhiệm vụ 4, Define system boundaries, cho biết rằng nhiệm
vụ Review results cũng như Assess feasibility không thể bắt đầu cho đến khi nhiệm vụ
Define system boundaries được hoàn thành. Các phụ thuộc nhiệm vụ khác cũng được
hiển thị.
Đường găng là chuỗi các hoạt động xác định được ngày sớm nhất mà dự án có thể
hoàn thành. Ngày sớm nhất được xác định bằng cách xem xét con đường dài nhất thông
qua mạng lưới các hoạt động. Chú ý đến tính phụ thuộc của nhiệm vụ với nhau, người

39
lập kế hoạch sẽ gộp các nhiệm vụ càng nhiều càng tốt. Những nhiệm vụ không thể được
gộp lại thêm nữa sẽ nằm trên đường găng.
Hình 12.14 cho thấy các nhiệm vụ trên đường găng màu đỏ. Hãy xem xét phần đầu
tiên của WBS. Người lập kế hoạch dự án chỉ định rằng nhiệm vụ 4 không thể bắt đầu
cho đến 2 ngày trước khi nhiệm vụ 3 kết thúc. (Đó là ý nghĩa của mũi tên màu đỏ xuất
hiện từ nhiệm vụ 3.) Cả nhiệm vụ 5 và nhiệm vụ 8 đều không thể bắt đầu cho đến khi
nhiệm vụ 4 hoàn thành. Nhiệm vụ 8 sẽ mất nhiều thời gian hơn nhiệm vụ 5 và 6, và do
đó, nhiệm vụ 8, không phải nhiệm vụ 5 hoặc 6, đang nằm trên đường găng. Do đó,
đường găng đến thời điểm này là các nhiệm vụ 3, 4 và 8. Bạn có thể theo dõi đường
găng qua phần còn lại của WBS bằng cách làm theo các nhiệm vụ được hiển thị bằng
màu đỏ, mặc dù toàn bộ WBS và đường găng không được hiển thị.

Hình 12.15 – Biểu đồ Gantt thể hiện sự phân chia công việc cho các nhân sự
Sử dụng Microsoft Project hoặc một ứng dụng tương tự, có thể phân công nhân sự
cho các nhiệm vụ và quy định phần trăm thời gian mà mỗi người dành cho một nhiệm
vụ. Hình 12.15 là một biểu đồ Gantt thể hiện sự phân chia công việc cho các nhân sự.
Ví dụ ở đây là Eleanore chỉ làm việc 25% thời gian cho nhiệm vụ 3; Lynda và Richard
làm việc toàn thời gian. Ngoài ra, người ta có thể ấn định chi phí cho từng người và tính
toán ngân sách lao động cho từng nhiệm vụ cũng như tổng thể WBS. Họ có thể gán tài
nguyên cho các nhiệm vụ và sử dụng Microsoft Project để phát hiện và ngăn chặn hai
nhiệm vụ sử dụng cùng một tài nguyên. Chi phí tài nguyên cũng có thể được chỉ định
và tổng hợp.
Các nhà quản lý có thể sử dụng đường găng để thực hiện phân tích đường găng.
• Đầu tiên, hãy lưu ý rằng nếu một nhiệm vụ đang trên đường găng và nhiệm vụ
đó tiến hành trễ thì dự án sẽ bị trễ theo. Do đó, các nhiệm vụ trên đường găng
không được phép chậm tiến độ nếu dự án phải được giao đúng thời hạn.

40
 • Thứ hai, các nhiệm vụ không nằm trên con đường găng có thể tiến hành muộn
đến thời điểm mà chúng sẽ trở thành một phần của đường găng. Vì vậy, cho đến
một thời điểm, có thể lấy tài nguyên từ các nhiệm vụ không trên đường găng để
rút ngắn các nhiệm vụ trên đường găng.
Phân tích đường găng là quá trình mà người quản lý dự án gộp lịch trình bằng cách
di chuyển các nguồn lực, điển hình là con người, từ các nhiệm vụ không đường găng
sang các nhiệm vụ trên đường găng.
4. Điều chỉnh kế hoạch thông qua đánh đổi.
Thường sau khi hoàn thành xong một dự án nào đó thì sẽ gặp phải lời phản hồi về
thời gian quá lâu hay chi phí cho dự án là quá nhiều. Do đó, phản ứng đầu tiên đối với
một kế hoạch dự án là cố gắng giảm thời gian và chi phí. Phải lưu ý xem xét làm thế
nào để có thể giảm bớt lịch trình và chi phí một cách có trách nhiệm? Đó là phải cân
nhắc sự đánh đổi. Sự đánh đổi là sự cân bằng của 3 yếu tố quan trọng: yêu cầu, chi
phí và thời gian.

Hình 12.16 - Các động lực chính của phát triển hệ thống
Để hiểu được thách thức của sự cân bằng này, hãy xem xét việc chế tạo một thứ
tương đối đơn giản - chẳng hạn như vòng cổ. Vòng cổ càng cầu kỳ thì càng mất nhiều
thời gian. Càng ít công phu thì càng ít thời gian. Hơn nữa, nếu chúng ta trang trí vòng
cổ bằng kim cương và đá quý thì sẽ tốn kém hơn. Chúng ta có thể tóm tắt ví dụ trên
như trong hình 12.16. Sự đánh đổi tương tự cũng tồn tại trong việc xây dựng bất cứ thứ
gì: nhà cửa, công trình, tàu thủy, …và hệ thống thông tin.
Mối quan hệ giữa thời gian và chi phí phức tạp hơn. Thông thường, chúng ta có
thể giảm thời gian bằng cách chỉ tăng chi phí lên đến một điểm nhất định. Ví dụ,
chúng tôi có thể giảm thời gian sản xuất một cái tàu bằng cách thuê thêm lao động. Tuy
nhiên, tại một số thời điểm, sẽ có rất nhiều người lao động làm việc trên tàu đến mức
họ sẽ cản đường nhau và thời gian hoàn thành cái tàu sẽ thực sự tăng lên. Trong định
luật Brooks đã có một câu nói "Việc thêm nhân lực vào một dự án muộn sẽ làm cho nó

41
muộn hơn". Điều này xảy ra một phần là do các thành viên mới trong nhóm cần được
đào tạo bởi các thành viên hiện tại trong nhóm.
Trong một số dự án, chúng ta có thể giảm chi phí bằng cách tăng thời gian. Ví
dụ, nếu buộc phải trả cho người lao động thời gian gấp rưỡi (thanh toán cho một công
nhân với mức lương cao gấp 1,5 lần so với giờ thông thường của họ) để làm thêm giờ,
chúng ta có thể giảm chi phí bằng cách loại bỏ thời gian làm thêm giờ. Tuy nhiên, sự
đánh đổi này không phải lúc nào cũng đúng. Kéo dài thời gian dự án có nghĩa là chúng
ta cần phải trả lương nhân công trong một thời gian dài hơn; do đó, thêm thời gian cũng
có thể làm tăng chi phí.
Hãy xem xét sự đánh đổi này liên quan đến hệ thống thông tin như thế nào. Giả sử
lịch trình ban đầu cho biết hệ thống sẽ hoàn thành sau 3 năm. Tuy nhiên nếu yêu cầu
bắt buộc dự án phải hoàn thành sau 2 năm, cần phải rút ngắn tiến độ. Có thể tiến hành
rút ngắn theo hai cách: giảm yêu cầu (loại bỏ các chức năng và tính năng) hoặc thêm
lao động (thuê thêm nhân viên, ...) Quyết định chọn cái nào sẽ đều rất khó khăn và đầy
rủi ro. Sử dụng sự đánh đổi, kế hoạch WBS có thể được sửa đổi để rút ngắn lịch trình
hoặc giảm chi phí. Nhưng họ không thể được giảm bớt bởi quản lý.
5. Quản lý các thách thức phát triển
Với sự chứng thực và phê duyệt của ban quản lý và kế hoạch dự án, giai đoạn tiếp
theo là thực hiện nó. Kế hoạch WBS cuối cùng được ký hiệu là baseline WBS (tạm
dịch đường cơ sở trong WBS). Đường cơ sở này hiển thị các nhiệm vụ đã lên kế
hoạch, tính phụ thuộc giữa các nhiệm vụ, thời lượng và phân bổ tài nguyên. Khi
dự án tiến hành, nhà quản lý dự án có thể nhập ngày thực tế, giờ lao động và chi phí tài
nguyên. Tại bất kỳ thời điểm nào, các ứng dụng lập kế hoạch có thể được sử dụng để
xác định xem tiến độ của dự án là nhanh hay chậm và chi phí thực tế của dự án so với
chi phí cơ sở là như thế nào.
Tuy nhiên, không có gì diễn ra theo đúng kế hoạch, dự án càng lớn và khoảng thời
gian phát triển càng dài thì càng có nhiều thứ vi phạm kế hoạch. Khi đó cần xem xét 4
yếu tố quan trọng sau:
1. Phối hợp
2. Tính phi kinh tế quy mô
3. Quản lý cấu hình
4. Sự kiện bất ngờ
Các dự án phát triển, đặc biệt là các dự án quy mô lớn, thường được tổ chức thành
nhiều nhóm phát triển hoạt động độc lập. Việc điều phối công việc giữa các nhóm độc
lập này có thể khó khăn, đặc biệt nếu các nhóm có vị trí địa lý hoặc ở các quốc gia khác
nhau. Một WBS chính xác và đầy đủ sẽ tạo điều kiện thuận lợi cho việc phối hợp, nhưng
không có dự án nào tiến hành chính xác theo WBS. Sự trì hoãn xảy ra, sự phụ thuộc của
các nhiệm vụ không xác định hoặc không mong muốn xảy ra giữa các nhiệm vụ.

42
 Một vấn đề khác là tính phi kinh tế quy mô. Số lượng tương tác giữa các thành viên
trong nhóm tăng lên theo cấp số nhân với số lượng thành viên trong nhóm. Cuối cùng,
dù một dự án được quản lý tốt đến đâu, tính phi kinh tế quy mô sẽ xuất hiện.
Khi dự án tiến hành, việc quản lý cấu hình của sản phẩm công việc trở nên khó khăn.
Ví dụ, khi xem xét các yêu cầu, Nhóm phát triển đưa ra tuyên bố ban đầu của các yêu
cầu. Các cuộc họp với người dùng tạo ra một tập hợp các yêu cầu đã được điều chỉnh.
Giả sử một sự kiện xảy ra sau đó đòi hỏi một phiên bản yêu cầu khác. Sau khi cân nhắc,
giả sử nhóm phát triển quyết định bỏ qua một phần lớn các yêu cầu thay đổi do sự kiện
này gây ra. Tại thời điểm này, có bốn phiên bản khác nhau của các yêu cầu. Nếu các
thay đổi đối với các yêu cầu không được quản lý cẩn thận, các thay đổi từ bốn phiên
bản sẽ bị trộn lẫn và dẫn đến nhầm lẫn và không theo một trật tự nào. Không ai sẽ biết
yêu cầu nào mới là chính xác ở thời điểm hiện tại.
Thuật ngữ quản lý cấu hình đề cập đến một tập hợp các chính sách quản lý, thực
hành, và các công cụ mà nhà phát triển sử dụng để duy trì quyền kiểm soát các tài
nguyên của dự án. Các tài nguyên đó bao gồm tài liệu, lịch trình, thiết kế, và bất kỳ tài
nguyên nào khác cần thiết để hoàn thành dự án. Quản lý cấu hình rất quan trọng, việc
mất quyền quản lí đối với cấu hình của dự án rất tốn kém và gây gián đoạn và có thể
dẫn đến việc chấm dứt hợp đồng đối với các nhà quản lý dự án cấp cao.
Thách thức lớn cuối cùng đối với quản lý dự án quy mô lớn là các sự kiện bất ngờ.
Dự án càng lớn và kéo dài thì khả năng bị gián đoạn do một sự kiện không lường trước
càng lớn. Ví dụ: một cơn bão có thể phá hủy một văn phòng; công nghệ sẽ thay đổi; các
đối thủ cạnh tranh có thể làm điều gì đó khiến dự án trở nên quan trọng hơn (hoặc ít
hơn); hoặc công ty có thể bị bán và ban quản lý mới có thể thay đổi các yêu cầu và ưu
tiên.
Bởi vì phần mềm là công cụ tư duy, nên tinh thần làm việc và hợp tác giữa các thành
viên trong nhóm là rất quan trọng. Chẳng hạn, việc các thành viên trong nhóm tranh cãi
nảy lửa với nhau về một vấn đề nào đó, hay họ chế nhạo và nói xấu lẫn nhau xảy ra
trong công ty, … Những sự kiện bất ngờ và kì lạ đó làm sao chúng ta không thể biết
trước, hay viết nó vào trong WBS được? Những sự kiện không lường trước như vậy
khiến việc quản lý dự án trở nên khó khăn, nhưng cũng vô cùng hấp dẫn!

12.6 LÀM THẾ NÀO SCRUM CÓ THỂ KHẮC PHỤC ĐƯỢC CÁC VẤN ĐỀ
CỦA SDLC?
Quy trình vòng đời phát triển hệ thống (SDLC) không được ưa chuộng trong cộng
đồng phát triển hệ thống, chủ yếu vì hai lý do:
• Bản chất của SDLC phủ nhận điều mà mọi nhà phát triển có kinh nghiệm đều
biết là đúng: các yêu cầu hệ thống không rõ ràng và luôn thay đổi; có rất nhiều
rủi ro không thể tiên lượng trước được.
• Tiến trình SDLC đi theo một trình tự tuyến tính và mô hình Thác nước
(Waterfall) là mô hình SDLC truyền thống nổi tiếng và được nhiều người biết
đến rộng rãi nhất. Trình tự tuyến tính nghĩa là khi yêu cầu thay đổi, toàn bộ các

43
 bước thiết kế và phát triển, kiểm thử, viết lại tài liệu…phải tiến hành lại. Kết quả
là sản phẩm làm ra không đúng yêu cầu của khách hàng, bị trễ thời gian, hoặc
quá ngân sách.
Tóm lại, SDLC giả định rằng các yêu cầu không thay đổi, điều mà tất cả những ai
đã từng ở tham gia dự án phát triển đều biết là sai và rất rủi ro cho doanh nghiệp tài trợ
cho dự án đó.
12.6.1 Các Nguyên tắc của Phương pháp Phát triển Agile là gì?
Trong 40 năm qua, nhiều lựa chọn thay thế cho SDLC đã được đề xuất, bao gồm
mô hình RAD (Rapid Application Development), quy trình hợp nhất, lập trình cực đoan,
Scrum, và những giải pháp khác. Các kỹ thuật này đã giải quyết các vấn đề của SDLC
và vào đầu thế kỷ trước, triết lý của họ đã kết hợp lại thành cái được gọi là Phát triển
Agile, có nghĩa là một quá trình phát triển tuân theo các nguyên tắc trong Hình 12-20 .
Scrum là một kỹ thuật Agile và cũng tuân thủ các nguyên tắc này.
◆ Expect, even welcome, changes in requirements
◆ Frequently deliver working version of the product
◆ Work closely with customer for the duration
◆ Design as you go
◆ Test as you go
◆ Team knows best how it's doing/how to change
◆ Can be used for business processes, information
systems, and applications development
Bảng 12.3 - Nguyên tắc phát triển Agile (Scrum)
• Nguyên tắc 1
Scrum và các kỹ thuật Agile khác mong đợi và thậm chí hoan nghênh sự thay đổi.
Bởi vì các hệ thống được tạo ra để giúp các tổ chức và mọi người đạt được chiến lược
của họ, và các yêu cầu càng thay đổi, thì chúng càng tiến gần đến việc tạo điều kiện cho
các chiến lược. Kết quả đạt được tốt hơn và làm hài lòng hơn cho cả người dùng và
nhóm phát triển.
• Nguyên tắc 2
Scrum và các quy trình phát triển Agile khác được thiết kế để thường xuyên cung cấp
các phiên bản hoạt động của một số phần của sản phẩm. Thường là từ 1 đến 8 tuần
và không lâu hơn. Và vào cuối kỳ, họ sẽ có một số sản phẩm có thể sử dụng được cũng
như có giá trị đối với doanh nghiệp.

Do đó, không giống như SDLC, các kỹ thuật Agile mang lại lợi ích sớm và thường
xuyên hơn. Với SDLC thì không có giá trị nào được tạo ra cho đến phần cuối cùng của
quy trình. Xét về giá trị thời gian của tiền bạc, chỉ riêng đặc điểm này đã khiến các kỹ
thuật Agile trở nên đáng kỳ vọng hơn.
• Nguyên tắc 3:
Nhóm phát triển sẽ làm việc, hợp tác chặt chẽ với khách hàng cho đến khi dự án kết
thúc. Một người biết các yêu cầu nghiệp vụ phải luôn có mặt và có khả năng trình bày
rõ ràng, làm rõ chi tiết về các yêu cầu để đảm bảo rằng nhóm hiểu được mục đích và

44
giá trị của ứng dụng đối với khách hàng. Ngoài ra, khách hàng cần có mặt để kiểm tra
sản phẩm đang phát triển.
• Nguyên tắc 4:
Là một nguyên tắc khó chấp nhận với nhiều nhà phát triển do thay vì thiết kế hệ thống
hoàn chỉnh ngay từ đầu, thì chỉ những phần của thiết kế cần thiết để hoàn thành công
việc mới được thực hiện trước. Đôi khi đây được gọi là thiết kế đúng lúc. Nhìn bề
ngoài thì nó không hiệu quả, tuy nhiên kinh nghiệm cho thấy rằng có quá nhiều đội ngũ
đã xây dựng các thiết kế công phu và hoàn chỉnh nhưng hóa ra nó hoàn toàn không thực
tế khi các yêu cầu thay đổi.
• Nguyên tắc 5:
Tiến hành kiểm tra là hiển nhiên nếu nhóm phát triển liên tục cung cấp các phiên bản
của sản phẩm. Thử nghiệm ban đầu được tiến hành giữa các thành viên của nhóm nhưng
cũng liên quan đến khách hàng doanh nghiệp.
• Nguyên tắc 6:
Các nhóm phát triển biết họ đang hoạt động tốt như thế nào. Họ biết khá rõ điểm
mạnh, điểm yếu, điểm nghẽn và các vấn đề trong quy trình. Nguyên tắc này là một phần
của phương pháp luận phát triển Agile. Vào cuối mỗi cột mốc có thể phân phối hoặc
một số cột mốc (ngắn) khác, nhóm phát triển họp mặt để đánh giá hoạt động của nó và
cách nó có thể cải thiện.
• Nguyên tắc 7:
Các phương pháp luận phát triển Agile là phương pháp chung. Chúng có thể được áp
dụng để tạo ra các quy trình kinh doanh, hệ thống thông tin và ứng dụng.
12.6.2 Quy trình Scrum là gì?
Scrum là một phương pháp phát triển Agile được phát triển bởi Jeff Sutherland, Jeff
McKenna và John Scumniotales cho một dự án tại Easel Corporation và được những
người khác mở rộng trong 15 năm qua. Scrum là một thuật ngữ bóng bầu dục và lần
đầu tiên được sử dụng để làm việc theo nhóm trong một bài báo trên Harvard Business
Review, được viết bởi Hirotaka Takeuchi và Ikujiro Nonaka. Trong bóng bầu dục,
Scrum là sự tập hợp của một đội thành một vòng tròn để bắt đầu lại trận đấu sau khi
phạm lỗi hoặc sau các gián đoạn khác.
Cơ bản về Scrum
Như đã biết thì Scrum là một loại quy trình phát triển Agile có các đặc điểm cụ thể
được thể hiện như sau:
◆ Requirements list drives process
◆ Each work period (1 to 4-8 weeks):
- Select requirements to consider
- Determine tasks to perform-select requirements to deliver
- Team meets daily for 15 min (stan-up)
. What I did yesterday
. What I’m going to do today
. What’s blocking me
- Test frequently
- Paired work possible

45
 - Minimal documentation
- Deliver (something) that works
- Evaluate team’s work process at end of period (and say
thanks)
◆ Rinse and repeat until
- Customer says we’re done
- Out of time
- Out of money
◆ Three principal roles
- Product owner (business professional who represent
customer)
- Scrum master
- Team members (7±2 people)
Bảng 12.4 - Cơ bản về Scrum
Scrum là một khung quản lý dự án được áp dụng rất rộng rãi. Đầu tiên, quy trình
được thúc đẩy bởi một danh sách ưu tiên các yêu cầu được tạo bởi người dùng và nhà
tài trợ kinh doanh. Khoảng thời gian làm việc của Scrum được chia theo từng phân đoạn
lặp liên tiếp nhau được gọi là Sprint, mỗi 1 giai đoạn (sprint) chỉ làm 1 số lượng yêu
cầu nhất định. Sprint có thể ngắn nhất là 1 tuần nhưng với tất cả các phương pháp Agile,
không bao giờ dài hơn 8 tuần. Và nó thường từ 2-4 tuần.
Mỗi giai đoạn làm việc, nhóm sẽ chọn các hạng mục ưu tiên hàng đầu mà họ sẽ cam
kết thực hiện trong giai đoạn đó. Mỗi ngày làm việc bắt đầu với một cuộc họp kéo dài
15 phút, trong đó mỗi thành viên trong nhóm tuyên bố:
• Những gì họ đã làm trong ngày qua
• Họ sẽ làm gì trong hôm nay
• Các yếu tố nào đang cản trở tiến độ của người đó
Việc kiểm tra được thực hiện thường xuyên, có thể nhiều lần mỗi ngày. Đôi khi,
chủ doanh nghiệp của dự án cũng tham gia vào việc kiểm tra hàng ngày. Trong một số
trường hợp, các thành viên trong nhóm làm việc theo cặp
Tài liệu tối thiểu được chuẩn bị. Kết quả công việc của nhóm không phải là thiết kế
hay các tài liệu khác mà là một phiên bản hoạt động của các yêu cầu đã được chọn khi
bắt đầu mỗi sprint.
Vào cuối mỗi sprint, phiên bản làm việc của sản phẩm được giao cho khách hàng,
nếu muốn thì họ có thể đưa nó vào sử dụng tại thời điểm đó, ngay cả khi ở trạng thái
chưa hoàn thiện. Sau khi sản phẩm được giao, nhóm họp mặt để đánh giá quy trình của
chính mình và thực hiện các thay đổi khi cần thiết.

46
 Các thành viên
trong nhóm có cơ hội để
bày tỏ sự cảm ơn và
nhận được sự công
nhận đối với công việc
của cấp trên tại các cuộc
họp này.
Khi nào thì hoàn
thành? Hình 12.17 - Quy trình Scrum
Công việc tiếp tục
theo chu kỳ lặp lại của các sprint cho đến khi một trong ba điều kiện được đáp ứng:
• Khách hàng hài lòng với sản phẩm được tạo ra và quyết định chấp nhận sản phẩm,
ngay cả khi một số yêu cầu vẫn chưa được thỏa mãn.
• Dự án hết thời gian.
• Dự án hết tiền.
Không giống như SDLC, nếu một dự án Scrum chấm dứt vì giới hạn thời gian hoặc
ngân sách, khách hàng sẽ có một số kết quả hữu ích cho thời gian và tiền bạc họ đã sử
dụng. Nó có thể không phải là phiên bản sản phẩm đầy đủ như mong muốn, nhưng nó
có thể tạo ra giá trị cho các nhà tài trợ dự án (giả sử các yêu cầu được xác định và ưu
tiên một cách chính xác).
Ba vai trò chính
Trong Scrum, có ba vai trò: Product Owner, Development Team, và Scrum Master.
Tất cả hợp thành Nhóm Scrum.
• Người sở hữu sản phẩm (Product Owner):
Vai trò này chịu trách nhiệm tối ưu hóa lợi nhuận trên đầu tư (ROI – Return On
Investment) thông qua việc quyết định các tính năng của sản phẩm, đánh giá và sắp xếp
độ ưu tiên của từng hạng mục, những hạng mục có độ ưu tiên cao thì sẽ được đưa vào
phát triển trước, những hạng mục có độ ưu tiên thấp hơn thì sẽ được phát triển sau.
• Người điều phối (Scrum Master):
Là một vai trò then chốt giúp nhóm Scrum làm việc hiệu quả bằng cách tuân thủ nguyên
lý, các kỹ thuật và quy tắc của Scrum. Scrum Master không phải là người quản lý của
Nhóm mà là một lãnh đạo theo phong cách phục vụ (Servant Leader)
• Nhà phát triển (Development Team):
Là đội ngũ trực tiếp làm ra sản phẩm, họ bao gồm các chuyên gia có nhiệm vụ chuyển
giao phần tăng trưởng ở cuối mỗi Sprint. Các Nhà phát triển không có sự phân chia các
chức danh chuyên môn đặc thù cho từng thành viên, ví dụ như: kiểm thử viên, lập trình

47
viên, chuyên gia thiết kế, chuyên gia cơ sở dữ liệu,… mà tất cả đều được gọi chung là
Nhà phát triển. Việc này giúp nâng cao tính sở hữu tập thể, trách nhiệm tập thể và bình
đẳng giữa các thành viên.
12.6.3 Làm thế nào để các yêu cầu thúc đẩy quá trình Scrum?
Scrum được phân biệt với các phương pháp luận phát triển Agile khác bởi cách nó
sử dụng các yêu cầu để thúc đẩy việc lập kế hoạch và lập lịch trình. Đầu tiên, các yêu
cầu được chỉ định theo một cách cụ thể, phổ biến là thể hiện các yêu cầu về việc Ai làm
gì và Tại sao.
Ví dụ: Một yêu cầu được thể hiện như sau:
“Là một bác sĩ, tôi muốn xem hồ sơ tập thể dục của một bệnh nhân để tôi có thể
đảm bảo rằng cô ấy đang tuân theo đơn thuốc của mình”.
Mỗi yêu cầu trong số này chỉ định Ai (bác sĩ) Làm gì (xem dữ liệu tập thể dục của
bệnh nhân) và Tại sao (đảm bảo rằng cô ấy đang tuân theo đơn thuốc của mình).
Chủ sở hữu sản phẩm tạo ra các yêu cầu và một số yêu cầu sẽ được ưu tiên hơn. Ví
dụ, một trong hai yêu cầu trên sẽ được đánh giá có mức độ quan trọng cao hơn yêu cầu
còn lại. Khi các yêu cầu còn lại có mức độ quan trọng bằng nhau, nhóm sẽ thỏa mãn
yêu cầu có ưu tiên cao hơn trước. Điều này cũng có nghĩa là nếu dự án hết thời gian
hoặc tiền bạc, các yêu cầu có ưu tiên cao nhất sẽ được hoàn thành đầu tiên.
Tạo nhiệm vụ yêu cầu
Khi một yêu cầu được đưa ra, nhóm phát triển họp để tạo ra các nhiệm vụ phải được
hoàn thành để đáp ứng yêu cầu đó. Công việc này được thực hiện trong hoạt động Chọn
các yêu cầu để cung cấp.
Bảng sau cho thấy tám nhiệm vụ cần được thực hiện để hoàn thành một yêu cầu
của ví dụ trên:
Requirement:
“As a doctor, I want to view the patient’s exercise records so
I can make sure she is following her prescription”
Tasks:
1. Authenticate the doctor
2. Obtain patient identifying data from doctor
3. Determine this doctor is authorized to view this
patient’s records
4. Read the database to obtain exercise record
5. Read the database to obtain most recent
prescription record
6. Format the data into a generic format
7. Determine the type of mobile device the doctor is
using
8. Format the generic report into a report for that

48
 mobile device
Bảng 12.5 - Ví dụ về yêu cầu và các nhiệm vụ
Trong phần hoạt động Chọn yêu cầu để cung cấp, các nhiệm vụ cho các yêu cầu bổ
sung có thể được thực hiện trong giai đoạn này cũng sẽ được tạo.
Nhiệm vụ được tạo trong cuộc họp nhóm cho phép các thành viên đưa ra phản hồi
của mình. Một thành viên trong nhóm có thể sẽ nghĩ ra một nhiệm vụ cần phải thực hiện
mà các thành viên khác không nghĩ đến. Hoặc thành viên trong nhóm sẽ nhận ra rằng
một nhiệm vụ cụ thể chưa hoàn thành, hoặc có thể thực hiện được theo một cách khác
hoặc không thực sự cần phải hoàn thành.
Lên lịch tác vụ
Cho đến nay, Scrum là một ý tưởng hay và là một trong nhiều quy trình Agile được
sử dụng nhiều. Tuy nhiên, điều làm cho Scrum trở nên đặc biệt là cách các nhiệm vụ
được lên lịch.
Phương pháp luận của Scrum thừa nhận rằng rất khó để các nhà phát triển xác định
thời gian thực hiện một nhiệm vụ. Tuy nhiên, các nhà phát triển khá giỏi trong việc xác
định một thứ gì đó sẽ mất bao lâu so với thứ khác. Vì vậy, mặc dù một nhà phát triển
có thể kém trong việc ước tính thời gian cần thiết để thực hiện. Ví dụ, Nhiệm vụ 2 trong
Hình 12-23, người đó có thể sẽ chính xác khi nói rằng Nhiệm vụ 2 sẽ mất gấp đôi thời
gian so với Nhiệm vụ 1, hoặc một tỷ lệ khác.
Vì vậy, theo quy trình Scrum, một khi các nhiệm vụ được biết đến với một tập hợp
các yêu cầu nhất định, bước tiếp theo là gán cho mỗi nhiệm vụ một điểm độ khó, được
gọi là điểm (point). Nhiệm vụ dễ nhất có điểm là 1. Một nhiệm vụ lâu hơn năm lần được
cho điểm 5, v.v. Khi tất cả các nhiệm vụ đã nhận được điểm, điểm sẽ được cộng lại
thành tổng cho yêu cầu.
Scrum bao gồm một số kỹ thuật khác nhau để ấn định điểm. Ý chính của những kỹ
thuật này là đạt được điểm số của nhóm bằng cách áp dụng kiến thức chuyên môn của
nhóm trong một quy trình tạo phản hồi lặp đi lặp lại.
Cam kết hoàn thành nhiệm vụ
Khi các nhóm làm việc cùng nhau, họ sẽ biết được tổng số điểm công việc mà họ
có thể hoàn thành trong mỗi sprint. Thuật ngữ đó được gọi là vận tốc (velocity) của
nhóm. Nhóm sử dụng tốc độ của họ để xác định số lượng yêu cầu mà họ có thể cam kết
hoàn thành trong giai đoạn tiếp theo.
Tất nhiên trong khoảng thời gian đầu thì nhóm nghiên cứu sẽ không biết vận tốc của
họ. Trong trường hợp đó, các thành viên cấp cao sẽ cần phải dự đoán. Dự đoán đó có
thể còn mơ hồ, nhưng sẽ tốt hơn khi cả đội tích lũy được kinh nghiệm. Không giống
như SDLC, ít nhất có hy vọng cơ sở rằng, theo thời gian, ước tính sẽ được cải thiện.

49
 Giả sử 5 yêu cầu trong danh sách các yêu cầu ưu tiên của một nhóm có tổng cộng
125 điểm. Nếu một đội biết vận tốc của mình là 100 điểm trong một sprint, thì đội đó
biết rằng mình không thể làm được cả 5 yêu cầu. Tuy nhiên, nếu tổng số điểm của 4
yêu cầu cao nhất, chẳng hạn như 80 điểm, thì họ có thể cam kết thực hiện 4 yêu cầu đó,
cộng với một số yêu cầu khác. Trong trường hợp này, nhóm sẽ trao đổi với chủ sở hữu
sản phẩm và hỏi xem có yêu cầu nào thấp hơn trong danh sách ưu tiên có thể được thực
hiện đối với 20 điểm năng lực hiện có hay không. Kỹ thuật ước lượng này được tóm tắt
như sau:

1. Team assigns 1 point to simplest task

2. Times to deliver working tasks are compared
to each other and assigned points (points are Fibonacci
numbers). Use:
a. Team estimation
b. Planning poker Bảng 12.6 - Tóm tắt các kỹ thuật
c. Other ước lượng trong Srcum
3. Using past experience, team computers its
velocity ... number of point it can accomplish per scrum
period
4. Working with product owner, team selects
tasks for the upcoming scrum period, constrained by its
velocity

Hocus-pocus?
Nếu bạn chưa tham gia vào quá trình phát triển phần mềm hoặc hệ thống, quá trình
này nghe có vẻ giống như vô nghĩa, bịp bợm. Tuy nhiên, có hai đặc điểm rất quan trọng
khiến nó không phải như vậy.
• Thứ nhất, Scrum là một phương pháp kết hợp vòng lặp và phản hồi để lập lịch
trình và làm việc, đây là một cách để một nhóm cùng nhau tạo ra thứ gì đó vượt
quá những gì mà mỗi thành viên có thể làm riêng lẻ.
• Thứ hai, Scrum cung cấp một khuôn khổ cho quá trình học hỏi. Khi một nhóm
làm việc ngày càng nhiều và có nhiều giai đoạn scrum cùng nhau, họ học hỏi
ngày càng tốt hơn cách chỉ định điểm và ngày càng hiểu được vận tốc thực của
họ là gì.

50
 Nhưng scrum không thể đảm bảo rằng dự án sẽ tạo ra một sản phẩm chất lượng cao,
đúng thời hạn và phù hợp với ngân sách. Tuy nhiên, là một giải pháp thay thế cho SDLC
truyền thống, Scrum có thể hạn chế tổn thất tài chính tiềm ẩn và tạo ra kết quả đáng kể
chỉ trong vài tuần.

12.6.4 So sánh giữa quy trình phát triển truyền thống Mô hình Thác nước (SDLC)
và SCRUM (Agile)

Mô hình Thác nước SCRUM

Thời gian chuyển giao Dựa trên thời gian dự án Từ 2-4 tuần
tổng thể
Kích thước nhóm Số thành viên nhóm là Chia nhỏ các nhóm lớn
tập trung, quy mô nhóm thành các nhóm nhỏ, từ
có thể thay đổi từ 2 đến 2 đến 8 thành viên,
100 thành viên. nhóm có sự phối hợp và
cộng tác cao.
Thay đổi yêu cầu + Phải dựa vào các điều + Thích ứng với những
khoản của hợp đồng. thay đổi.

+ Chi phí cho một thay + Chi phí cho một thay
đổi có thể rất cao nếu đổi thấp hơn, phạm vi
thay đổi có tác động lớn được xác định khi thời
đến thiết kế. gian chuyển giao nhỏ
hơn.
Độ ưu tiên Nhấn mạnh vào việc Tập trung vào việc thực
thực hiện các xây dựng hiện các yêu cầu có giá
đã được đưa ra trong yêu trị quan trọng trước tiên.
cầu.
Làm tăng việc có những Giảm nguy cơ các tính
tính năng được xây dựng năng không sử dụng
mà không đem lại giá trị. được / không được sử
dụng.
Dự án Các dự án mà đã có tất Dự án chưa có mục tiêu
cả tài liệu (từ đầu đến cuối rõ ràng và yêu cầu
cuối), và không cần phải phải đổi mới liên tục
thay đổi gì khi thực hiện
Quy trình Các giai đoạn được hoàn Bao gồm các loại hoạt
thành một cách tuần tự. động giống như
Khi đã bước sang giai Waterfall nhưng thay vì
đoạn sau thì sẽ không triển khai dưới dạng các
thể quay lại giai đoạn giai đoạn tuần tự, các
trước đó. Output (đầu ra) yêu cầu được chia ra
của giai đoạn trước sẽ là thành nhiều giai đoạn,
mỗi giai đoạn sẽ hoàn

51
 input (đầu vào) của giai thành một số tính năng
đoạn sau. nhất định.
Ưu điểm Dễ tiếp cận, ứng dụng và Tính linh hoạt cao, phù
quản lý, phù hợp các dự hợp với những dự án
án ngắn hạn, quy mô phức tạp, có nhiều yêu
nhỏ và ít thay đổi yêu cầu.
cầu đặt ra.
Nhược điểm Sự kém linh hoạt và gần Không phải là phương
như không thể điều pháp hữu ích cho các dự
chỉnh. án phát triển nhỏ.
Bảng 12.7 - So sánh Mô hình thác nước (SDLC) và Scrum
12.6.5. Lợi ích nổi bật của Scrum:

▪ Cải thiện chất lượng phần mềm một cách hiệu quả.

▪ Rút ngắn thời gian phát hành phần mềm, mang đến những trải nghiệm sử dụng
sản phẩm nhanh chóng và chất lượng cho khách hàng.

▪ Thúc đẩy tinh thần đồng đội, tối ưu hóa hiệu quả và nỗ lực của nhóm phát triển.

▪ Gia tăng tỷ suất hoàn vốn đầu tư (ROI).

▪ Tạo độ tin cậy, hài lòng của khách hàng.

▪ Kiểm soát tiến độ của dự án tốt, liên tục cải tiến và hạn chế rủi ro không mong
muốn khi xây dựng sản phẩm.

Scrum được sử dụng phổ biến trên toàn thế giới. Có thể kể đến một số thương hiệu lớn
đã sử dụng Scrum như: Facebook, Google, Microsoft, Daily Mail, Spotify, Twitter,
cùng một số trường đại học, …

➔ Ví dụ về Gmail được phát triển bằng cách sử dụng bộ khung làm việc là
Scrum

Gmail là một dự án do nhà phát triển của Google bắt đầu với ý tưởng phát triển email
dựa trên web. Để phát triển điều này, họ đã làm việc với phương pháp cắt dọc, một số
nhóm scrum được thành lập để đạt được mục tiêu bao quát của chương trình.

Các nhóm scrum làm việc trong các sprint đồng bộ trên các nhiệm vụ khác nhau và sau
đó các mô-đun đó được tích hợp với nhau thông qua nhóm scrum tích hợp sau mỗi
sprint.
52
Nhóm scrum tích hợp đã sở hữu nhóm scrum chuyên dụng, chủ sở hữu sản phẩm, bậc
thầy về scrum cho mỗi nhiệm vụ.

Cách hoạt động của quy trình này:

• Nhóm scrum riêng biệt phát triển chức năng cho chức năng soạn thảo.

• Một nhóm khác đã làm việc trên chức năng kiểm tra chính tả.

• Nhóm thứ ba phát triển chức năng tìm kiếm.

Nhóm scrum tích hợp thực hiện công việc phát triển để tích hợp các chức năng với nhau
thành một gói mà nhóm tích hợp Gmail có thể tích hợp vào toàn bộ mô-đun Email.

12.7. 2026?
Từ nay đến 2026, có thể thấy rằng hệ thống thông tin ngày càng phát triển, thậm chí
thế hệ trẻ ngày nay khá thành thạo trong việc sử dụng thiết bị điện tử.
Các ứng dụng sẽ dễ dàng thay đổi và tiện dụng hơn. Các nhà cung cấp phần mềm
biết rằng chìa khóa cho sự phát triển trong tương lai của họ không phải là có một giải
pháp tốt nhất mà là có một giải pháp sẵn sàng phù hợp với phong cách riêng của khách
hàng của họ. Trong vòng 10 năm tới, tốc độ phát triển ứng dụng tăng mạnh.
Bản chất của ngành công nghiệp sẽ thay đổi. Chẳng hạn như sản phẩm NoSQL
DBMS (chương 5) được phát triển riêng để đáp ứng nhu cầu của họ.
Cuối cùng, điều quan trọng nhất trong phát triển hệ thống thông tin vẫn là phản hồi
của người dùng.

53
 TÀI LIỆU THAM KHẢO

1. Tổng quan về quản lý quy trình doanh nghiệp (BPM). (n.d.). Truy xuất từ
https://www.cask.vn/tin-chi-tiet/tong-quan-ve-quan-ly-quy-trinh-doanh-nghiep-
bpm
2. Nguyen Thanh Dong. (2019, ngày 23 tháng 7). BPM (Business Process
Management) là gì? Truy xuất từ https://viblo.asia/p/bpm-business-process-
management-la-gi-bJzKmwvPl9N
3. SDLC: Các giai đoạn & Mô hình của Vòng đời Phát triển Phần mềm. (n.d.).
Truy xuất từ https://ichi.pro/vi/sdlc-cac-giai-doan-mo-hinh-cua-vong-doi-phat-
trien-phan-mem-234877250586705
4. Hà Vân. (2021, ngày 30 tháng 10). Các giai đoạn và phương pháp trong vòng
đời phát triển phần mềm. Truy xuất từ https://itguru.vn/blog/cac-giai-doan-va-
phuong-phap-trong-vong-doi-phat-trien-phan-mem-sdlc/
5. Trà My. (n.d.). Scrum là gì? Scrum mang lại lợi ích gì cho việc phát triển phần
mềm hiện nay? Truy xuất từ https://wiki.tino.org/scrum-la-gi/
6. Scrum Master. (Jan 11, 2018). Gmail Development by using Scrum. Truy xuất từ
https://medium.com/@scrum.master/gmail-development-by-using-scrum-
3018d0109ccd
7. McMurtrey, M. (2013). A Case Study of the Application of the Systems
Development Life Cycle (SDLC) in 21st Century Health Care: Something Old,
Something New? Truy xuất từ
https://quod.lib.umich.edu/j/jsais/11880084.0001.103/--case-study-of-the-
application-of-the-systems-development?rgn=main;view=fulltext

54
8. Quỳnh Hương. (n.d.). Bài toán quản lý quy trình (BPM) và ứng dụng trong thực
tế. Truy xuất từ https://123docz.net//document/2595897-bai-toan-quan-ly-quy-
trinh-bpm-va-ung-dung-trong-thuc-te.htm
9. [Update 2021] Scrum là gì? Cách áp dụng mô hình Scrum hiệu quả nhất. (2021).
Truy xuất từ
https://hocvienagile.com/agipedia/tong-quan-ve-
scrum/?fbclid=IwAR3PZtIQ45HqZn_cekWwFAgMMdJWXccjdFRVN8_WZ
Qmbr8Ckk2xj1KRqHs8
10. Nguyen Thi Phuong Linh. (2018, ngày 12 tháng 7). Scrum và quy trình phát triển
phần mềm truyền thống (SDLC). Truy xuất từ
https://viblo.asia/p/scrum-va-quy-trinh-phat-trien-phan-mem-truyen-thong-
sdlc-WAyK8MneZxX?fbclid=IwAR3x6J7usmlUKogJ2-7Do-
MflhQTwqjCJR_uFgwwjXc9qbJLmDZGfq80eTw
11. Ganesh, K. (n.d.). Scrum vs Traditional SDLC Waterfall. Truy xuất từ
https://www.clariontech.com/blog/scrum-vs-traditional-sdlc-
waterfall?fbclid=IwAR2CTjRMcFjXtKYrbshzHeOLzNePFdn9CILC9PBV6_
Ve6pFR6LjMSq2ri6E
12. BPMN – Ký hiệu và mô hình hóa quy trình nghiệp vụ. (n.d.). Truy xuất từ
https://movan.vn/bpmn-ky-hieu-va-mo-hinh-hoa-quy-trinh-nghiep-vu/
13. Ban biên tập nội dung BAC. (2020). Tổng quan về BPMN dành cho Business
Analyst. Truy xuất từ https://www.bacs.vn/vi/blog/kien-thuc/tong-quan-ve-
bpmn-danh-cho-business-analyst-11002.html
14. Kroenke, D., & J.Boyle, R. (2016). Using MIS (Ninth Edition). New York:
Pearson.

55