ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trần Hữu Nguyên

Thiết kế, xây dựng hệ thống phần mềm giảng dạy
kịch hát dân tộc Trường Đại học Sân khấu điện ảnh

LUẬN VĂN TỐT NGHIỆP THẠC SĨ HỆ CHÍNH QUY
Ngành: Công Nghệ Thông Tin

HÀ NỘI - 2017


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trần Hữu Nguyên

Thiết kế, xây dựng hệ thống phần mềm giảng dạy
kịch hát dân tộc Trường Đại học Sân khấu điện ảnh
Ngành: Công Nghệ Thông Tin
Chuyên ngành: Kỹ Thuật Phần Mềm
Mã Số: 60480103

LUẬN VĂN TỐT NGHIỆP THẠC SĨ CÔNG NGHỆ THÔNG TIN

Cán bộ hướng dẫn: PGS. TS. Bùi Thế Duy

Cán bộ đồng hướng dẫn: TS. Ngô Thị Duyên


Người – Máy, Bộ môn Công Nghệ Phần Mềm, Bộ môn Các Hệ Thống Thông Tin, những
người đã đem trí tuệ, công sức của mình truyền đạt lại cho chúng tôi. Những kiến thức này
đã giúp ích rất nhiều cho tôi trong quá trình học tập và công tác.
Cuối cùng, tôi xin gửi lời cảm ơn đến gia đình và bạn bè, những người luôn bên tôi, động
viên và khích lệ tôi trong quá trình học và thực hiện đề tài nghiên cứu của mình.

HỌC VIÊN
Trần Hữu Nguyên

2


Mục lục
LỜI CAM ĐOAN ......................................................................................................................................... 1
LỜI CẢM ƠN ............................................................................................................................................... 2
DANH MỤC CÁC THUẬT NGỮ .............................................................................................................. 6
DANH MỤC CHỮ VIẾT TẮT ................................................................................................................... 6
DANH MỤC BẢNG BIỂU .......................................................................................................................... 7
DANH MỤC HÌNH VẼ ............................................................................................................................... 7
MỞ ĐẦU ....................................................................................................................................................... 9
CHƯƠNG 1.

GIỚI THIỆU .................................................................................................................. 10

1.1.

MỤC ĐÍCH VÀ Ý NGHĨA CỦA ĐỀ TÀI .......................................................................................... 10

1.2.



Một số nhân tố trong phát triển yêu cầu .............................................................................. 16

2.1.3.

Các yêu cầu tốt ..................................................................................................................... 16

2.1.4.

Khả năng kiểm thử ............................................................................................................... 17

2.1.5.

Các thay đổi đối với các yêu cầu ......................................................................................... 17

2.1.6.

Tính cần thiết của sự chính xác trong các yêu cầu phần mềm ............................................. 18

2.2.

PHÂN TÍCH YÊU CẦU.................................................................................................................. 18

2.2.1.

Các kỹ thuật chính ................................................................................................................ 18

2.2.2.

Các vấn đề ............................................................................................................................ 19


Tóm lược............................................................................................................................... 28

2.4.
2.4.1.

KỸ NGHỆ YÊU CẦU TRONG AGILE SCRUM ................................................................................ 29
Quá trình hình thành ............................................................................................................ 29
3


2.4.2.

Vai trò của Chủ sản phẩm (Product Owner) trong Scrum .................................................. 29

2.4.3.

Quy trình và các cuộc họp trong Scrum ............................................................................... 31

2.4.4.

Hướng tiếp cận các Bên liên quan (Stakeholder) ................................................................ 39

2.4.5.

Làm mịn Product Backlog (Grooming Product Backlog) .................................................... 39

2.4.6.

User Story và UML Use Case .............................................................................................. 42

3.1.

PHƯƠNG PHÁP THU THẬP YÊU CẦU................................................................... 53

TIẾP CẬN CÁC BÊN LIÊN QUAN .................................................................................................. 53

3.1.1.

Xác định các bên liên quan .................................................................................................. 53

3.1.2.

Phân tích các bên liên quan ................................................................................................. 54

3.1.3.

Cộng tác với các Player ....................................................................................................... 55

3.1.4.

Thu hút sự quan tâm các Subject ......................................................................................... 55

3.1.5.

Thao khảo ý kiến của các Context Setter hay Referee ......................................................... 55

3.1.6.

Thông báo thông tin tới Crowd ............................................................................................ 56


TÓM LƯỢC ................................................................................................................................. 60

CHƯƠNG 4.
4.1.

PHÂN TÍCH & THIẾT KẾ HỆ THỐNG ................................................................... 61

PHÂN TÍCH HỆ THỐNG ............................................................................................................... 61

4.1.1.

Mô tả quy trình nghiệp vụ .................................................................................................... 61

4.1.2.

Đề xuất quy trình tin học hóa ............................................................................................... 61

4.2.

CÁC YÊU CẦU CỦA PHẦN MỀM .................................................................................................. 63

4.2.1.

Định nghĩa các thuật ngữ ..................................................................................................... 63

4.2.2.

Tài liệu tham khảo ................................................................................................................ 65

4.2.3.


Thiết kế Cơ sở dữ liệu .......................................................................................................... 88

4.3.4.

Thiết kế giao diện ................................................................................................................. 90

4.4.

TÓM LƯỢC ................................................................................................................................. 90

KẾT LUẬN ................................................................................................................................................. 91
DANH MỤC TÀI LIỆU THAM KHẢO .................................................................................................. 93
PHỤ LỤC .................................................................................................................................................... 94
PHỤ LỤC I. BỘ CÂU HỎI PHỎNG VẤN CÁC BÊN LIÊN QUAN (Q&A) ......................................................... 94
Cán bộ quản lý khoa Kịch hát dân tộc ............................................................................................... 94
Giảng viên Khoa kịch hát dân tộc ...................................................................................................... 96
Sinh viên ............................................................................................................................................. 97
Ban lãnh đạo nhà trường ĐH Sân khấu Điện ảnh ............................................................................. 98
Nhân viên Phòng CNTT ..................................................................................................................... 98
PHỤ LỤC II. DANH SÁCH CÁC EPIC .......................................................................................................... 99
PHỤ LỤC III. DANH SÁCH CÁC USER STORY ......................................................................................... 103
PHỤ LỤC IV. DANH SÁCH CÁC PROTOTYPE .......................................................................................... 110

5


Danh mục các thuật ngữ
Thuật ngữ nghiệp vụ
Thuật ngữ

Product Increment
Internal Meeting

Daily Meeting (Stand Meeting) – Cuộc họp nhóm hằng ngày
Sprint Meeting – Cuộc họp Sprint

Stakeholder Meeting Các cuộc họp với các bên liên quan như:
Product Strategy – Cuộc họp chiến lược sản phẩm
Roadmaping Workshop – Buổi hội thảo lộ trình
Sprint Review Meeting – Cuộc họp đánh giá Sprint

Danh mục chữ viết tắt
Chức viết tắt

Ý nghĩa

PO

Product Owner (Chủ sản phẩm)

SAD

Software Analysis and Design

UAC

User Acceptance Criteria
6



HÌNH 22: KEEP PACKAGE DIAGRAM CHO YÊU CẦU CHỨC NĂNG VÀ PHI CHỨC NĂNG................................................... 66
HÌNH 23: KEEP PACKAGE DIAGRAM CHO YÊU CẦU CHỨC NĂNG QUẢN LÝ NỘI DUNG GIẢNG DẠY, HỌC TẬP ................ 69
HÌNH 24: KEEP PACKAGE DIAGRAM CHO YÊU CẦU CHỨC NĂNG CHUNG CỦA HỆ THỐNG ............................................. 69
HÌNH 25: KEEP PACKAGE DIAGRAM CHO YÊU CẦU PHI CHỨC NĂNG ............................................................................ 70
HÌNH 26: KEEP COMPONENT DIAGRAM NGƯỜI DÙNG TƯƠNG TÁC VỚI HỆ THỐNG THÔNG QUA GIAO DIỆN WEB ......... 71
HÌNH 27: MÔ HÌNH KIẾN TRÚC LOGIC ............................................................................................................................ 72
HÌNH 28: KEEP NETWORK DIAGRAM KIẾN TRÚC VẬT LÝ CỦA HỆ THỐNG .................................................................... 73
HÌNH 29: KEEP PACKAGE DIAGRAM CHO TÁC NHÂN THAM GIA HỆ THỐNG .................................................................. 73
HÌNH 30: KEEP PACKAGE DIAGRAM CHO CÁC USE CASE QUẢN TRỊ HỆ THỐNG .......................................................... 75
HÌNH 31: KEEP PACKAGE DIAGRAM CHO CÁC USE CASE QUẢN LÝ QUYỀN NGƯỜI DÙNG ........................................... 76
7


HÌNH 32: KEEP PACKAGE DIAGRAM CHO CÁC USE CASE QUẢN TRỊ NGƯỜI DÙNG ...................................................... 77
HÌNH 33: TEMP SEQUENCE DIAGRAM CHO USE CASE HIỂN THỊ LỊCH SỬ NGƯỜI DÙNG............................................... 78
HÌNH 34: TEMP SEQUENCE DIAGRAM CHO USE CASE HIỂN THỊ THÔNG TIN CHI TIẾT TÀI KHOẢN ............................... 78
HÌNH 35: TEMP SEQUENCE DIAGRAM CHO USE CASE HIỂN THỊ CÁC TẠC VỤ TRONG QUÁ KHỨ .................................. 79
HÌNH 36: TEMP SEQUENCE DIAGRAM CHO USE CASE XÓA NGƯỜI DÙNG ................................................................... 79
HÌNH 37: TEMP SEQUENCE DIAGRAM CHO USE CASE ĐÓNG TÀI KHOẢN .................................................................... 80
HÌNH 38: TEMP SEQUENCE DIAGRAM CHO USE CASE ĐĂNG NHẬP ............................................................................. 80
HÌNH 39: KEEP PACKAGE DIAGRAM CHO CÁC USE CASE QUẢN LÝ THÔNG TIN CHUNG .............................................. 81
HÌNH 40: KEEP PACKAGE DIAGRAM CHO CÁC USE CASE QUẢN LÝ DỮ LIỆU ĐA PHƯƠNG TIỆN_NGƯỜI QUẢN TRỊ ..... 82
HÌNH 41: KEEP PACKAGE DIAGRAM CHO CÁC USE CASE QUẢN LÝ DỮ LIỆU ĐA PHƯƠNG TIỆN_GIẢNG VIÊN ............. 83
HÌNH 42: KEEP PACKAGE DIAGRAM CHO CÁC USE CASE QUẢN LÝ DỮ LIỆU ĐA PHƯƠNG TIỆN_SINH VIÊN ................ 84
HÌNH 43: KEEP PACKAGE DIAGRAM CHO CÁC USE CASE QUẢN LÝ BÀI GIẢNG_NGƯỜI QUẢN TRỊ .............................. 85
HÌNH 44: KEEP PACKAGE DIAGRAM CHO CÁC USE CASE QUẢN LÝ BÀI GIẢNG_GIẢNG VIÊN ..................................... 86
HÌNH 45: KEEP PACKAGE DIAGRAM CHO CÁC USE CASE QUẢN LÝ BÀI GIẢNG_SINH VIÊN ........................................ 87
HÌNH 46: TEMP SEQUENCE DIAGRAM CHO USE CASE BIÊN SOẠN NỘI DUNG BÀI GIẢNG............................................. 88
HÌNH 47: KEEP CLASS DIAGRAM MÔ TẢ MỐI QUAN HỆ GIỮA CÁC BẢNG ...................................................................... 89


lượng sản phẩm và mức độ hài lòng của khách hàng qua từng dự án. Vì vậy tôi mong muốn
qua luận văn này sẽ nghiên cứu sâu hơn phương pháp luận Agile và các thay đổi có giá trị
mà nó tạo ra tới kỹ nghệ yêu cầu cũng như các thay đổi trong quy trình phát triển phần
mềm.
9


Chương 1. Giới thiệu
1.1. Mục đích và ý nghĩa của đề tài
Ứng dụng khoa học, công nghệ vào việc nâng cao chất lượng giảng dạy các loại hình văn
hóa nghệ thuật là một trong những mục tiêu góp phần bảo tồn và phát huy các di sản văn
hóa phi vật thể trước xu thế toàn cầu hóa và hội nhập như hiện nay. Trên thực tế đã có nhiều
hệ thống phần mềm được xây dựng và áp dụng trong các trường Đại học khối Văn hóa
Nghệ thuật nhưng vẫn tồn tại những hạn chế như không thỏa mãn đầy đủ các yêu cầu giảng
dạy và học tập hoặc vượt quá ngân sách và thời gian. Một trong những nguyên nhân chính
là các dự án không đầu tư thời gian và công sức ở khâu phân tích, thiết kế mà bắt tay vào
lập trình quá sớm. Việc không nắm rõ các yêu cầu của các bên liên quan hoặc thiếu các
phương pháp khoa học và yếu kém ở khả năng mô hình hóa các khối chức năng sẽ dẫn đến
việc xây dựng một hệ thống không đạt được các mục tiêu của dự án hoặc không như mong
đợi của người sử dụng.
Tôi đã từng đảm nhiệm các vai trò khác nhau trong nhóm phát triển phần mềm vì vậy tôi
muốn xây dựng cho mình các kỹ năng để trở thành một Chủ sản phẩm (Product Owner)
bằng việc củng cố phương pháp luận về kỹ nghệ yêu cầu cũng như kỹ năng thiết kế hệ
thống và cách thức tổ chức một dự án Agile phù hợp.
Trong luận văn này, mục tiêu thứ nhất tôi cần trình bày được các phương pháp quản lý yêu
cầu người dùng bao gồm việc thu thập, quản lý các yêu cầu người dùng và áp dụng các kiến
thức này trong quá trình quản lý các yêu cầu đầu vào trong dự án Scrum.
Song song với kỹ năng quản lý yêu cầu người dùng, mục tiêu thứ hai tôi cần trình bày được
phương pháp mô hình hóa trực quan và áp dụng hiểu quả phương pháp này trong dự án
Scrum nhằm giúp các thành viên đội dự án hoặc khách hàng hiểu về hệ thống và giao tiếp

Là các phương pháp thu thập thông tin khoa học trên cơ sở nghiên cứu các văn bản, tài liệu
đã có và bằng các thao tác tư duy logic để rút ra kết luận khoa học cần thiết.
Phương pháp phân loại và hệ thống hóa lý thuyết: Phân loại là sắp xếp các tài liệu khoa
học theo từng mặt, từng đơn vị, từng vấn đề có cùng dấu hiệu bản chất, cùng một hướng
phát triển. Hệ thống hóa là sắp xếp tri thức thành một hệ thống trên cơ sở một mô hình lý
thuyết làm sự hiểu biết về đối tượng đầy đủ hơn.

11


Phương pháp Mô hình hóa: Là phương pháp nghiên cứu các đối tượng bằng cách xây
dựng mô hình gần giống với đối tượng, tái hiện lại đối tượng theo các cơ cấu, chức năng
của đối tượng.

1.3.2. Phương pháp nghiên cứu Thực nghiệm
Là các phương pháp tác động trực tiếp vào đối tượng có trong thực tiễn để làm rõ bản chất
và các quy luật của đối tượng.
Phương pháp phân tích tổng kết kinh nghiệm: Là phương pháp nghiên cứu và xem xét
lại những thành quả thực tiễn trong quá khứ để rút ra kết luận bổ ích cho thực tiễn và khoa
học.
Phương pháp thực nghiệm khoa học: Là phương pháp mà các nhà nghiên cứu chủ động
tác động vào đối tượng và theo dõi quá trình diễn biến sự kiện mà đối tượng tham gia để
hướng sự phát triển của chúng theo mục tiêu dự kiến của mình.

12


1.4. Cấu trúc luận văn
“Chương 1: Giới thiệu”, trình bày nội dung dự án “Xây dựng Hệ thống phần mềm hỗ trợ
giảng dạy theo mô hình “Vai mẫu” đối với kịch hát dân tộc”, trong dự án này tôi đã áp dụng

khác nhau bị ảnh hưởng bởi việc triển khai một hệ thống hay được gọi là các bên liên quan.
Nhu cầu của các bên liên quan là khác nhau và có thể phức tạp và mâu thuẫn vì vậy cần hệ
thống hoá chức năng thông qua việc sử dụng quy trình và phương pháp khoa học để đảm
bảo tính hiệu quả, tính thực tiễn của hệ thống.
Chúng ta sẽ nghiên cứu kỹ hơn về bối cảnh sử dụng của tổ chức và thảo luận một số vấn đề
chung có thể ảnh hưởng đến việc chấp nhận công nghệ trong các tổ chức. Sau đó chúng ta
xem xét một số cách tiếp cận để mô hình hóa bối cảnh xã hội - tổ chức và yêu cầu của các
bên liên quan trong đó.
Thu thập yêu cầu là một phần quan trọng của tất cả các phương pháp kỹ thuật phần mềm
nhưng thường hoạt động này tập trung chủ yếu vào các yêu cầu chức năng của hệ thống những gì hệ thống phải có khả năng làm được - ít nhấn mạnh vào các vấn đề về con người,
các vấn đề phi chức năng như tính khả dụng và mức độ chấp nhận được, … Ngay cả khi
những vấn đề này được xem xét, chúng chỉ có thể phản ánh quan điểm của người quản lý
về nhu cầu của người dùng hơn là thu thập thông tin từ người dùng. Các mô hình yêu cầu
của các bên liên quan được xây dựng để đảm bảo sự cân bằng trong quá trình xây dựng yêu
cầu chức năng và yêu cầu phi chức năng bằng cách xác định nhu cầu của tất cả các bên liên
quan, bao gồm cả người sử dụng và bất cứ ai khác bị ảnh hưởng bởi hệ thống, đặt trong bối
cảnh mà hệ thống sẽ được sử dụng.
Tôi bắt đầu chương này bằng việc trình bày các khái niệm cơ bản về yêu cầu người dùng
sau đó thảo luận về một số vấn đề phát sinh trong tổ chức khi áp dụng các giải pháp công
nghệ mới. Tiếp đến tôi phác thảo một số mô hình và phương pháp có thể được sử dụng để
nắm bắt quan điểm rộng hơn về yêu cầu của các bên liên quan, bao gồm các mô hình xã
hội – kỹ thuật (Socio-Technical models), phương pháp các hệ thống mềm (Soft Systems
14


Methodology), thiết kế hợp tác (Participatory Design) và phương pháp nhân chủng học
(Ethonographic Approach).
Trọng tâm của luận văn này tôi tập trung tìm hiểu về quy trình xử lý yêu cầu người dùng
bằng phương pháp Agile Scrum kết hợp hiệu quả các công cụ mô hình hoá trong UML.


dụ: khi nào hệ thống cần hoàn thành (thời gian); tổng chi phí cho phát triển hệ thống
(tài nguyên); cần áp dụng các tiêu chuẩn nào cho quá trình phát triển hệ thống, trong
đó có các phương pháp quản lý dự án và phát triển hệ thống (chất lượng).
Mục tiêu thiết kế là các hướng dẫn cho việc lựa chọn giải pháp. Có nhiều tính năng quan
trọng đối với một hệ thống, nhưng nhiều trường hợp không thể có giải pháp đạt được mọi
tính năng ở mức tối ưu. Do đó cần có một thứ tự ưu tiên, tính năng nào cần được ưu tiên
hơn tính năng nào. Nếu khách hàng không mô tả thứ tự ưu tiên, nhà phát triển phần mềm
sẽ tự chọn thứ tự và thứ tự này có thể không phải cái mà khách hàng mong muốn.
Một tập hợp các yêu cầu định nghĩa các tính chất hay tính năng của hệ thống cần xây dựng.
Một danh sách yêu cầu 'tốt' thường tránh nói đến chuyện hệ thống cần thi hành các yêu
cầu bằng cách nào, mà để các quyết định dạng này cho người thiết kế hệ thống. Việc mô
tả cách cài đặt hệ thống được gọi là thiên kiến cài đặt (Implementation Bias).

2.1.2. Một số nhân tố trong phát triển yêu cầu
Việc trình bày các yêu cầu ở một cách lý tưởng là rất khó. Người dùng khó hình dung được
hết những thông tin nào là cần thiết cho các nhà phát triển, và hai bên có thể không thực sự
hiểu các cách diễn đạt của nhau. Thông thường, người ta thuê Người dùng chuyên
gia (Expert User) làm cầu nối giữa người dùng và các nhà phát triển. Những người dùng
chuyên gia này có thể biểu đạt các yêu cầu chức năng sao cho chúng có thể dễ chuyển thành
một tính năng thiết kế của hệ thống, trong khi người dùng cuối (End User) vẫn hiểu được.

2.1.3. Các yêu cầu tốt
Theo lý thuyết, các yêu cầu tốt nên có các tính chất sau:
•

•
•

Cần thiết – Cái cần phải nhắc đến nếu không hệ thống sẽ thiếu một phần tử quan
trọng mà không một thành phần nào khác của hệ thống có thể bù lại được.

thành phần quan trọng của việc kiểm định (Validation).
Một số yêu cầu không thể kiểm thử được do chính cấu trúc của nó. Trong đó có các yêu
cầu nói rằng hệ thống cần luôn luôn hay không bao giờ thể hiện một tính chất nào đó. Việc
kiểm thử thích đáng cho các yêu cầu này sẽ cần đến một chu trình kiểm thử vô hạn. Những
yêu cầu như vậy cần được viết lại để nói về một khoảng thời gian có tính thực tế hơn.
Các yêu cầu phi chức năng không kiểm thử được có thể vẫn được giữ để làm tài liệu về chủ
ý của khách hàng; tuy nhiên, chúng thường dẫn đến các yêu cầu quy trình mà chúng được
xác định là một phương pháp thực tiễn cho việc thỏa mãn yêu cầu ban đầu. Ví dụ, một yêu
cầu phi chức năng rằng không được có các Backdoor có thể được thỏa mãn bằng cách thay
nó bằng một yêu cầu quy trình rằng cần sử dụng phương pháp lập trình cặp (Pair
Programming).

2.1.5. Các thay đổi đối với các yêu cầu
Theo thời gian, các yêu cầu có thể thay đổi. Trong trường hợp này, một khi đã được xác
định và thông qua, các yêu cầu cần được đưa vào quy trình Kiểm soát thay đổi (Change
Control). Với nhiều dự án, một số yêu cầu được thay đổi trước khi hệ thống được hoàn
thiện. Đặc tính này của các yêu cầu đã dẫn đến các nghiên cứu và thực hành về quản lý yêu
cầu (Requirements Management).
17


2.1.6. Tính cần thiết của sự chính xác trong các yêu cầu phần mềm
Một số phương pháp luận Kỹ nghệ phần mềm hiện đại, chẳng hạn như Lập trình cực đoan
(Extreme Programming), đã nghi ngờ sự cần thiết của các yêu cầu phần mềm được mô tả
chính xác - cái mà các phương pháp luận này coi là một cái đích di động. Thay vào đó, họ
mô tả các yêu cầu một cách phi hình thức bằng các "Câu chuyện người dùng" hay User
Story (Yêu cầu được viết ngắn gọn trong một cái thẻ nhỏ với nội dung giải thích một khía
cạnh của những gì mà hệ thống cần làm), và tạo một chuỗi các trường hợp kiểm thử chấp
nhận (Acceptance Test Case) cho User Story này.


Các nhà phân tích có thể sử dụng một số kĩ thuật để làm rõ các yêu cầu của khách hàng.
Trong lịch sử, các kỹ thuật này bao gồm các cuộc phỏng vấn, thành lập các Nhóm trọng
tâm (Focus Group) với các cuộc họp bàn về yêu cầu (Requirements Workshops), và tạo ra
các danh sách yêu cầu. Các kỹ thuật hiện đại hơn gồm có Tạo nguyên mẫu (Prototyping),
và Tình huống sử dụng (Use Case). Khi cần thiết, nhà phân tích sẽ kết hợp các phương
pháp này để thiết lập các yêu cầu chính xác của những người có vai trò quan trọng, nhằm
mục đích xây dựng một hệ thống thỏa mãn các yêu cầu doanh nghiệp.

2.2.2. Các vấn đề
2.2.2.1. Vấn đề về người dùng và khách hàng
Trong cuốn Rapid Development, Steve McConnell đã liệt kê một loạt các khả năng người
dùng có thể cản trở quá trình thu thập yêu cầu:
1. Người dùng không hiểu họ muốn gì
2. Người dùng không tuân theo một bộ yêu cầu đã được tài liệu hóa
3. Người dùng nhất định đòi hỏi các yêu cầu mới sau khi chi phí và kế hoạch phát triển
đã được hoạch định xong.
4. Mức độ giao tiếp với người dùng là thấp
5. Người dùng thường không tham gia các đợt thẩm định hoặc không thể tham gia.
6. Người dùng không hiểu kỹ thuật
7. Người dùng không hiểu quy trình phát triển.
Những điều này có thể dẫn tới tình huống khi yêu cầu người dùng liên tục thay đổi ngay cả
khi việc phát triển hệ thống hay sản phẩm đã được bắt đầu.

19


2.2.2.2. Vấn đề về kỹ sư – nhà phát triển
Trong quá trình phân tích yêu cầu, các vấn đề sau có thể nảy sinh từ phía các kỹ sư và nhà
phát triển.
Nhân viên kỹ thuật và người dùng cuối có thể có ngôn từ khác nhau. Kết quả là họ có thể

không có sự hiểu biết đầy đủ về tất cả những người sẽ bị ảnh hưởng bởi nó. Nhưng làm thế
nào chúng ta có thể hiểu rõ hơn và hỗ trợ các tổ chức có cấu trúc phức tạp, khi các nhóm
làm việc và các nhu cầu của bên liên quan có khả năng mâu thuẫn lẫn nhau? Chúng ta bắt
đầu bằng cách thu thập và phân tích các yêu cầu, nhưng chúng ta cần phải làm việc này
trong hoàn cảnh mà các công việc của tổ chức vẫn đang diễn ra, có tính đến sự phức tạp
của các mối quan tâm của các bên liên quan khác nhau và các cấu trúc và quy trình hoạt
động trong các nhóm làm việc.
Phần tiếp theo trình bày một số phương pháp tiếp cận: Mô hình kỹ thuật-xã hội (SocioTechnical Modeling), phương pháp các hệ thống mềm (Soft Systems Methodology), thiết
kế hợp tác (Participatory Design), phương pháp nhân chủng học (Ethnographic Methods)
và điều tra theo ngữ cảnh (Contextual Inquiry). Các phương pháp này có hướng tiếp cận
hơi khác nhau cho cùng một vấn đề nhưng đều nhằm mục đích để hiểu được thực tế của bối
cảnh công việc và quan điểm khác nhau của các bên liên quan. Các phương pháp này cũng
cho thấy công nghệ có thể được triển khai thành công chỉ khi nó được thực hiện với một sự
hiểu biết về bối cảnh sử dụng. Trước khi chúng ta xem xét chi tiết hơn những phương pháp
tiếp cận này, chúng ta cần làm rõ ý nghĩa của thuật ngữ "Các bên liên quan".

2.3.1. Bên liên quan
Hiểu được các bên liên quan là yếu tố then chốt để tiếp cận tối đa các yêu cầu, vì trong một
môi trường tổ chức, nó không chỉ đơn giản là người dùng cuối bị ảnh hưởng bởi việc giới
thiệu công nghệ mới. Bên liên quan có thể được định nghĩa là bất cứ ai bị ảnh hưởng bởi
sự thành công hay thất bại của hệ thống. Các nhóm bên liên quan theo cách tiếp cận
CUSTOM là:
• Các bên liên quan chính là những người thực sự sử dụng hệ thống - những người
dùng cuối.
• Các bên liên quan thứ cấp là những người không trực tiếp sử dụng hệ thống, nhưng
nhận được kết quả từ nó hoặc cung cấp đầu vào cho nó (ví dụ như ai đó nhận được
báo cáo do hệ thống sản xuất).
21





2.3.2.1. User skills and Task Match - USTM/CUSTOM methodology
1.

USTM

Phương pháp USTM được chia thành 7 giai đoạn (Stage):
1. Business Case: Một thành viên của nhóm có trách nhiệm đối với Business Case và
đưa ra sự luận giải ban đầu cho hệ thống được đề xuất.
2. Nhóm làm việc: Mục tiêu của giai đoạn này là xác định các nhóm làm việc có liên
quan đến hệ thống đề xuất. Sản phẩm của nhóm làm việc phụ thuộc vào mối quan
hệ của họ với hệ thống, và lựa chọn một nhóm công việc chính và mô tả của nó một
cách chi tiết.
3. Người dùng: Một danh sách người dùng chung được tạo ra, người dùng được phân
loại theo mối quan hệ của họ đối với hệ thống đề xuất. Ba bộ vấn đề được xác định:
quan điểm tổ chức của người dùng, các thuộc tính cá nhân của người dùng chung,
và ‘typical day in life’ của người dùng chung thời điểm hiện tại và khi triển khai hệ
thống đề xuất.
4. Đối tượng: Nhóm được yêu cầu xác định các đối tượng liên quan đến hệ thống đề
xuất, phân loại họ theo mối quan hệ của họ với hệ thống và tạo ra các cấu trúc đối
tượng ban đầu. Thủ tục xác định danh sách các đối tượng bao gồm hai bước: cùng
nhau tạo ra một danh sách các đối tượng bằng cách động não và cùng đánh giá và
đồng thuật về danh sách các đối tượng được chọn.
5. Nhiệm vụ: Một nhiệm vụ được định nghĩa là một hành động được thực hiện bởi một
người dùng chung trên một đối tượng. Một danh sách các nhiệm vụ được tạo ra, các
nhiệm vụ này được tích hợp vào một sơ đồ phân cấp và các mối quan hệ giữa nhiệm
vụ và hệ thống được xác định.
6. Tương tác: Mục đích của giai đoạn này là hiểu mối quan hệ giữa người dùng chung,
đối tượng và nhiệm vụ và để xác định sự khác biệt giữa người dùng, đối tượng và