NGHIÊN cứu, xây DỰ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

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

MAI VĂN THANH

NGHIÊN CỨU, XÂY DỰ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

Ngành: Kỹ thuật phần mềm
Chuyên ngành: Kỹ thuật phần mềm
Mã Số: 8480103.01

LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM
NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS. BÙI THẾ DUY
TS. NGÔ THỊ DUYÊN

Hà Nội – 2018


LỜI CẢM ƠN
Lời cảm ơn trân trọng đầu tiên tôi muốn dành tới PGS.TS. Bùi Thế Duy,
TS. Ngô Thị Duyên người thầy, người cô đã dìu dắt và hướng dẫn tôi trong suốt
quá trình làm luận văn, sự chỉ bảo và định hướng của thầy, của cô giúp tôi tự tin
nghiên cứu những vấn đề cần giải quyết của đề tài, để có những kiến thức phù
hợp áp dụng vào đề tài được giao nghiên cứu.
Tôi xin trân trọng cảm ơn Ban Giám hiệu và các Thầy, Cô Trường Đại
học Công nghệ, Đại học Quốc Gia Hà Nội đã tạo điều kiện cho tôi được học tập,
nghiên cứu và làm khóa luận một cách thuận lợi.
Tôi xin trân trọng cảm ơn sự hỗ trợ từ đề tài "Nghiên cứu ứng dụng công
nghệ đa phương tiện trong bảo tồn và phát huy di sản văn hoá phi vật thể" mã số

ĐTĐL.CN-34/16
Cuối cùng tôi xin chân thành cảm ơn Ban Giám đốc Trung tâm Quản lý
Chất lượng – Trường Đại học Công nghiệp Hà Nội đã tạo mọi điều kiện để tôi
được đi học và hoàn thành tốt khoá học
Mặc dù đã cố gắng rất nhiều, nhưng chắc chắn trong quá trình học tập
cũng như luận văn không khỏi những thiếu sót. Tôi rất mong được sự thông cảm
và chỉ bảo tận tình của các thầy cô và các bạn.
Tôi xin chân thành cảm ơn!
Hà Nội, tháng 11 năm 2018

Mai Văn Thanh

i


LỜI CAM ĐOAN
Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi, nội dung
được trình bày trong luận văn “Nghiên cứu, xây dự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” do tôi thực hiện dưới sự
hướng dẫn của PGS.TS. Bùi Thế Duy và TS. Ngô Thị Duyên. Tôi đã trích dẫn
đầy đủ các tài liệu tham khảo, công trình nghiên cứu liên quan ở trong nước và
quốc tế. Tất cả những tham khảo từ các nghiên cứu liên quan đều được nêu
nguồn gốc một cách rõ ràng từ danh mục tài liệu tham khảo trong luận văn.

Học viên thực hiện luận văn
(Ký và ghi rõ họ tên)

Mai Văn Thanh

ii

MỤC LỤC
Lời cảm ơn ............................................................................................................ i
Lời cam đoan ....................................................................................................... ii
Mục lục ................................................................................................................ iii
Danh mục các thuật ngữ ..................................................................................... v
Danh mục các bảng ............................................................................................ vi
Danh mục các hình ............................................................................................ vii
Mở đầu.................................................................................................................. 1
Chương 1. Tổng quan về quy trình phát triển phần mềm .............................. 6
1.1 Quy trình phát triển phần mềm ................................................................. 6
1.2 Các phương pháp phát triển phần mềm .................................................... 7
1.3 Một số quy trình phát triển phần mềm ..................................................... 9
1.4 Kết chương ............................................................................................. 22
Chương 2. Các phương pháp tạo mẫu, thiết kế tương tác người - máy ...... 23
2.1 Tổng quan về mẫu thiết kế ..................................................................... 23
2.2 Phương pháp và kỹ thuật tạo mẫu .......................................................... 24
2.2.1

Quá trình tạo mẫu (Software Prototyping).................................... 24

2.2.2

Các phương pháp tạo mẫu............................................................. 25

2.2.3

Các kỹ thuật xây dựng mẫu ........................................................... 28

2.2.4

Các công cụ tạo mẫu ..................................................................... 35

2.3 Ưu điểm nhược điểm của tạo mẫu .......................................................... 37
2.4 Tiêu chí đánh giá mẫu ............................................................................ 38
2.5 Kết chương ............................................................................................. 41
Chương 3. Nghiên cứu, xây dự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 .................................................................. 43
3.1 Phân tính mô hình người dùng ............................................................... 45
3.2 Áp dụng kỹ thuật tạo nguyên mẫu để đặc tả tương tác trong hệ thống .. 48
3.2.1

Chức năng đăng nhập hệ thống ..................................................... 48

3.2.2

Chức năng đăng ký tài khoản ........................................................ 49

3.2.3

Chức năng quản lý quyền.............................................................. 50

3.2.4

Chức năng quản lý hệ thống.......................................................... 51

3.2.5

Chức năng quản lý thư viện đa phương tiện ................................. 52

3.2.6

Chức năng xem một vở diễn ở dạng video 2D, 3D ...................... 53
iii


3.2.7

Chức năng quản lý khóa học ......................................................... 54

3.2.8

Chức năng quản lý môn học – chủ đề ........................................... 55

3.2.9

Chức năng quản lý bài giảng điện tử ............................................ 56

3.2.10 Chức năng quản lý người dùng ..................................................... 57
3.2.11 Chức năng người học đăng ký vào khóa học ................................ 58
3.2.12 Chức năng người học xem bài học................................................ 59
3.3 Phân tích, đánh giá mẫu.......................................................................... 60
3.3.1

Lập kế hoạch đánh giá mẫu........................................................... 60

3.3.2

Tổ chức phiên đánh giá và kết quả các phiên đánh giá ................ 62

3.3.3
Những hạn chế và các đề xuất cải tiến trong việc áp dụng xây
dựng mẫu lấy người dùng làm trung tâm .................................................... 63
3.4 Nghiên cứu, xây dựng hệ thống.............................................................. 64
3.4.1

Phân tích thiết kế ........................................................................... 64

3.4.2

Xây dựng hệ thống ........................................................................ 68

3.5 Kết chương ............................................................................................. 76
Kết luận .............................................................................................................. 77
Tài liệu tham khảo............................................................................................. 78

iv


DANH MỤC CÁC THUẬT NGỮ
Ký hiệu,
Tiếng anh
viết tắt
Agile
Agile Software Development
HTML
RAD

SEP

UAT
UCSD
XP

GUI

Chú giải
Phát triển phần mềm Agile

Hypertext Markup Language
Rapid Application

Mô hình phát triển nhanh

Development
Software development/

Quy trình phát triển phần mềm

Engineering Process
User acceptance test

Test case kiểm thử chấp nhận
Thiết kế lấy người dùng làm trung

User Center System Design

tâm

Extreme Programming

Lập trình cực hạn

Graphical User Interface

Giao diện đồ họa người dùng
Những nhân vật tiêu biểu trong
một số tích diễn của sân khấu

Vai mẫu

truyền thống

v


DANH MỤC CÁC BẢNG
Bảng 2.1 So sánh giữa các kỹ thuật tạo mẫu độ trung thực thấp ........................ 31
Bảng 2.2 So sánh giữa các kỹ thuật tạo mẫu mức độ trung thực cao ................. 35
Bảng 3.1 Phân loại mô hình người dùng trong hệ thống .................................... 46
Bảng 3.2 Mô tả các nhóm làm việc và nhiệm vụ ................................................ 46
Bảng 3.3 Xác định những nhu cầu của các đối tượng liên quan dựa trên yêu cầu
và chức năng hệ thống định xây dựng................................................................. 47
Bảng 3.4 Tạo kịch bản các nhiệm vụ đánh giá mẫu ........................................... 61
Bảng 3.5 Những góp ý, và kết quả đánh giá mẫu ............................................... 62

vi


DANH MỤC CÁC HÌNH

Hình 1.1 Mô hình thác nước ................................................................................. 9
Hình 1.2 Mô hình chữ V ..................................................................................... 11
Hình 1.3 Mô hình thử nghiệm tiến hóa ............................................................... 12
Hình 1.4 Mô hình xoắn ốc................................................................................... 13
Hình 1.5 Mô hình lặp và gia tăng ........................................................................ 15
Hình 1.6 Mô hình Scrum ..................................................................................... 16
Hình 1.7 Mô hình Agile ...................................................................................... 17
Hình 1.8 Mô hình XP .......................................................................................... 19
Hình 1.9 Mô hình phát triển nhanh ..................................................................... 21
Hình 2.1 Quá trình tạo mẫu (Software Prototyping)........................................... 24
Hình 2.2 Các bước thực hiện xây dựng nguyên mẫu .......................................... 26
Hình 2.3 Các bước thực hiện xây dựng mẫu tiến hóa ......................................... 27
Hình 2.4 Các bước thực hiện xây dựng mẫu gia tăng ......................................... 27
Hình 2.5 Các bước thực hiện xây dựng mẫu cực biên ........................................ 28
Hình 2.6 So sánh giữa mức độ trung thực từ thấp đến cao ................................. 28
Hình 2.7 Phác thảo nhanh một wireframes ......................................................... 29
Hình 2.8 Một thiết kế phác họa màn hình điện thoại .......................................... 30
Hình 2.9 Bảng phân cảnh tương tác và chức năng trên điện thoại ..................... 31
Hình 2.10 Nguyên mẫu tương tác có độ trung thực cao được tạo ra trong Adobe
XD ....................................................................................................................... 32
Hình 2.11 Kỹ thuật Wizard of Oz ....................................................................... 34
Hình 2.12 Kỹ thuật nguyên mẫu trình chiếu và video ........................................ 35
Hình 2.13 Các công cụ tạo mẫu .......................................................................... 36
Hình 3.1 Mô hình thiết kế lấy người dùng làm trung tâm .................................. 44
Hình 3.2 Bản phác thảo chức năng đăng nhập mức độ trung thực thấp ............. 49
Hình 3.3 Bản phác thảo chức năng đăng nhập mức độ trung thực cao .............. 49
Hình 3.4 Bản phác thảo chức năng đăng ký tài khoản mức độ trung thực thấp . 49
Hình 3.5 Bản phác thảo chức năng đăng ký tài khoản mức độ trung thực cao .. 50
Hình 3.6 Bản phác thảo của chức năng quản lý quyền độ trung thực thấp ........ 50
Hình 3.7 Bản phác thảo của chức năng quản lý quyền độ trung thực cao .......... 51

Hình 3.8 Bản phác thảo chức năng quản lý hệ thống trung thực thấp ................ 51
Hình 3.9 Bản phác thảo của chức năng quản lý hệ thống độ trung thực cao...... 52
Hình 3.10 Bản phác thảo của chức năng quản lý thư viện đa phương tiện trung
thực thấp .............................................................................................................. 52
Hình 3.11 Bản phác thảo của chức năng quản lý thư viện đa phương tiện trung
thực cao ............................................................................................................... 53
vii


Hình 3.12 Bản phác thảo chức năng xem một vở diễn ở dạng video 2D, 3D trung
thực thấp .............................................................................................................. 53
Hình 3.13 Bản phác thảo chức năng xem một vở diễn ở dạng video 2D, 3D trung
thực cao ............................................................................................................... 54
Hình 3.14 Bản phác thảo chức năng quản lý khóa học trung thực thấp ............. 54
Hình 3.15 Bản phác thảo chức năng quản lý khóa học trung thực cao............... 55
Hình 3.16 Bản phác thảo chức năng quản lý môn học trung thực thấp .............. 55
Hình 3.17 Bản phác thảo chức năng quản lý môn học trung thực cao ............... 56
Hình 3.18 Bản phác thảo chức năng quản lý bài giảng điện tử trung thực thấp . 57
Hình 3.19 Bản phác thảo chức năng quản lý bài giảng điện tử trung thực cao .. 57
Hình 3.20 Bản phác thảo chức năng quản lý người dùng trung thực thấp ......... 58
Hình 3.21 Bản phác thảo chức năng quản lý người dùng trung thực cao ........... 58
Hình 3.22 Bản phác thảo chức năng người học đăng ký vào khóa học trung thực
thấp ...................................................................................................................... 59
Hình 3.23 Bản phác thảo chức năng người học đăng ký vào khóa học trung thực
cao ....................................................................................................................... 59
Hình 3.24 Bản phác thảo chức năng người học xem bài học trung thực thấp .... 60
Hình 3.25 Bản phác thảo chức năng người học xem bài học trung thực cao ..... 60
Hình 3.26 Lược đồ các Use Case hệ thống ......................................................... 64
Hình 3.27 Lược đồ hoạt động thêm mới nội dung 3D ........................................ 64
Hình 3.28 Lược đồ hoạt động thêm mới nội dung video 2D .............................. 65

Hình 3.29 Lược đồ hoạt động thêm mới nội dung đa phương tiện, hình ảnh..... 65
Hình 3.30 Lược đồ hoạt động tra cứu, xem nội dung đa phương tiện ................ 66
Hình 3.31 Lược đồ hoạt động xây dựng bài giảng.............................................. 66
Hình 3.32 Lược đồ lớp ........................................................................................ 67
Hình 3.33 Lược đồ quan hệ giữa các bảng cơ sở dữ liệu.................................... 67
Hình 3.34 Tóm tắt quy trình xây dựng một video 3D......................................... 68
Hình 3.35 Chức năng thêm mới – upload nội dung video 3D ............................ 70
Hình 3.36 Cấu trúc lưu trữ các tệp tin video 3D sau khi người dùng tải lên hệ
thống .................................................................................................................... 72
Hình 3.37 Cấu trúc bảng dữ liệu video 3D của hệ thống .................................... 72
Hình 3.38 Danh sách thư viện video 3D ............................................................. 73
Hình 3.39 Màn hình biểu diễn 2 diễn viên là 2 cảnh video 3D cùng một thời
điểm ..................................................................................................................... 73
Hình 3.40 Màn hình biên tập bài giảng có hỗ trợ nhúng nội dung đa phương tiện
từ thư viện............................................................................................................ 75
Hình 3.41 Màn hình biên tập bài giảng có thể nhúng nội dung đa phương tiện từ
thư viện ................................................................................................................ 75
Hình 3.42 Màn hình xem nội dung bài giảng, so sánh giữa các diễn viên ......... 76

viii


MỞ ĐẦU
Trong đời sống của mỗi con người chúng ta và trong bản sắc của mỗi dân
tộc, văn hóa nói chung và di sản văn hóa nói riêng, luôn có vai trò, vị trí quan
trọng. Văn hóa không chỉ tạo nên nét độc đáo và sự khác biệt của mỗi dân tộc
mà văn hóa còn giúp cho đời sống văn hóa của cả xã hội thêm phong phú, đa
dạng. Cùng với sự phát triển và thay đổi từng ngày của xã hội hiện đại những
bản sắc, hoạt động văn hóa này ngày càng mai một và rất cần được bảo tồn. Có
rất nhiều hình thức bảo tồn, trong đó bảo tồn dưới dạng số hóa để lưu trữ trên

máy tính, lưu giữ làm tài liệu giảng dạy cho các thế hệ mai sau đã và đang thu
hút được rất nhiều nghiên cứu. Trên thế giới đã có nhiều công trình nghiên cứu
bảo tồn nội dung văn hóa phi vật thể sử dụng các công nghệ khác nhau với hai
hướng chính là hệ thống công nghệ nhằm truyền bá nội dung văn hóa phi vật thể
và hệ thống công nghệ hỗ trợ giảng dạy nội dung văn hóa phi vật thể.
Việc giảng dạy và truyền bá nội dung văn hóa phi vật thể phụ thuộc nhiều
vào việc truyền thụ trực tiếp giữa người dạy và người học. Các phương pháp
giảng dạy trực tiếp khó có thể truyền bá được các nội dung văn hóa phi vật thể
một cách rộng rãi, hơn nữa tài nguyên về con người cho việc giảng dạy cũng
như truyền thụ là hạn chế. Do đó, việc xây dựng hệ thống hỗ trợ giảng dạy theo
mô hình vai mẫu sẽ tạo ra một phương pháp học mới, ở đó người học có các
công cụ để xem và so sánh các diễn viên khác nhau diễn cùng một nhân vật. Từ
đó, tăng khả năng cảm thụ và tính sáng tạo của người học. Bên cạnh đó hệ thống
sẽ giúp bảo tồn và truyền bá nội dung văn hóa phi vật thể một cách rộng rãi.
Cũng chính vì lý do này mà tôi chọn và nghiên cứu đề tài “Nghiên cứu, xây
dự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”. Đề tài là một nội dung thực hiện trong dự án bảo tồn và phát huy di
sản văn hoá phi vật thể. Nhằm nâng cao chất lượng, tăng hiệu quả của việc giảng
dạy, bảo tồn và truyền bá nội dung văn hóa phi vật thể của dân tộc, đề tài được
đề xuất để giải quyết thực trạng giảng dạy tại các trường nghệ thuật, phục vụ
công tác đào tạo bậc đại học và cao đẳng về văn hoá nghệ thuật. Cụ thể là áp
dụng tại trường Đại học Sân khấu – Điện ảnh Hà Nội

1


Trường Đại học Sân khấu - Điện ảnh Hà Nội có sứ mạng đào tạo nguồn
nhân lực chất lượng cao, bồi dưỡng nhân tài trong các lĩnh vực sân khấu, điện
ảnh, nhiếp ảnh, múa, thiết kế mỹ thuật và truyền hình, góp phần xây dựng nền
văn hóa Việt Nam và thực hiện thành công các mục tiêu về hội nhập quốc tế.

Hiện nay nhà trường đang đào tạo 16 ngành đào tạo với các chuyên ngành khác
nhau tương ứng với các trình độ đào tạo khác nhau. Trong đó có các chuyên
ngành về Kịch về Sân khấu truyền thống: diễn viên Chèo, diễn viên Cải lương,
diễn viên Tuồng, diễn viên Kịch hát dân tộc, …
Công tác giảng dạy các loại hình sân khấu truyền thống tại trường hiện
đang theo hình thức truyền nghề, theo cách giảng viên dạy sinh viên trực tiếp
trên lớp phần lý thuyết và thể hiện các mẫu nhân vật theo vai mẫu, sau đó chia
các nhóm sinh viên tự học và tự biểu diễn, sinh viên sẽ tự học và trả bài ở các
buổi lên lớp tiếp theo. Với cách giảng dạy này người học mới thu nhận được
những kiến thức từ một phía và tạo ra những vai diễn dập khuôn, cứng nhắc,
thiếu sự cá tính và nét riêng của bản thân. Bên cạnh đó, công tác đào tạo bộ môn
kịch hát dân tộc còn bất cập: thiếu thốn trang thiết bị phục vụ giảng dạy và học
tập, tài nguyên người giảng dạy còn hạn chế, nên các phương pháp giảng dạy
trực tiếp chưa thể truyền bá được nội dung văn hóa phi vật thể một cách rộng
rãi. Những yếu tố này đã phần nào làm cho học sinh hụt hẫng, khiếm khuyết về
kiến thức và sinh ra những vai diễn “bản sao” của thầy, nghèo nàn, cứng nhắc,
thiếu cái riêng, độc đáo.
Để khắc phục những hạn chế trên Trường ĐH Sân khấu & Điện ảnh Hà
Nội đã thực hiện ghi hình (các tệp dữ liệu mẫu) trong các trích đoạn sân khấu
truyền thống, với sự trình diễn của các nghệ nhân, nghệ sĩ tài danh để đưa vào
giảng dạy cho sinh viên ngành kịch hát dân tộc của nhà trường. Tiến trình ghi
hình diễn ra tại cả ba miền ở nước ta với cả ba thể loại: chèo, tuồng, cải lương.
Tuy nhiên, việc áp dụng công nghệ thông tin vào hỗ trợ việc giảng dạy tại nhà
trường mới chỉ ở mức ghi hình các trích đoạn và giảng dạy cho sinh viên với các
thể loại: chèo, tuồng, cải lương, kịch hát dân tộc, múa rối...Với hình thức ghi
hình này chưa đáp ứng được nhu cầu của người học khi muốn xem các vở diễn ở
nhiều góc cảnh khác nhau, chưa hỗ trợ người học so sánh các ưu, nhược điểm
của từng diễn viên khi diễn cùng vai diễn trong cùng một vở diễn.

2

Bên cạnh đó những hạn chế về kỹ năng sử dụng máy tính của cán bộ giáo
viên trong nhà trường không đồng đều, cán bộ và giáo viên với nhiều độ tuổi
khác nhau.
Từ thực trạng trên, việc nghiên cứu xây dựng một hệ thống hỗ trợ giảng
dạy theo mô hình “vai mẫu” để giảng viên và người học dễ sử dụng, đạt hiệu
quả trong công tác giảng dạy và học tập là rất cần thiết. Để hiểu rõ hơn về mục
đích xây dựng hệ thống tôi xin trình bày về hai khái niệm đó là khái niệm “hệ
thống hỗ trợ giảng dạy” và khái niệm “vai mẫu”.
Vai mẫu là những nhân vật tiêu biểu trong một số tích diễn của sân khấu
truyền thống, được các thế hệ nghệ nhân, nghệ sĩ sáng tạo, thể hiện, đạt đến
chuẩn mực, được xem là khuôn mẫu nghệ thuật. Các vai mẫu này có thể do
nhiều diễn viên diễn khác nhau thể hiện cùng một nhân vật. Trong mỗi loại hình
nghệ thuật thì đều có các vai mẫu tiêu biểu. Ví dụ trong sân khấu chèo các vai
mẫu có thể nhắc đến như: Thị Kính, Thị Mầu, Xúy Vân, Mẹ Đốp, Lý Trưởng,…
Hệ thống hỗ trợ giảng dạy được hiểu là hệ thống được xây dựng giúp
công tác giảng dạy của giáo viên hiệu quả hơn, giúp người học phát huy khả
năng sáng tạo, tiếp thu kiến thức nhanh và học tập đạt kết quả cao.
Có nhiều hình thức hỗ trợ giảng dạy khác nhau như:
- Các hệ thống quản lý học tâp - Learning managerment Systems
(LMSs). Những hệ thống này hỗ trợ việc quản lý lớp học, danh sách
lớp, câu hỏi, bài tập và các học phần. Các hệ thống hỗ trợ hình thức
này có cả hệ thống nguồn mở và hệ thống trả phí phổ biến như
Moodle, BlackBoard/ WebCT….
- Các hệ thống cung cấp môi trường học tập ảo – Virtual learning
evironments (VLEs). Cung cấp môi trường học tập ảo thể hiện nội
dung bài học theo các kịch bản dựng sẵn. Các hệ thống này thường là
những hệ thống yêu cầu người dùng phải trả phí sử dụng. Nổi bật trong
hình thức này như: Second life, Open cobalt, OpenSimulator…

- Các hệ thống quản lý nội dung – Content management systems
(CMSs). Các hệ thống này cung cấp công cụ quản lý nội dung các bài
giảng, học phần, khóa học, nội dung đa phương tiện. Hiện nay có
nhiều hệ thống theo hình thức này.
3


- Các hệ thống học kết hợp – Blended and online learning. Các hệ thống
này sẽ áp dụng hình thức kết hợp giữa việc sinh viên lên lớp và kết
hợp học trực tuyến. Ví dụ: sinh viên học lý thuyết trực tuyến trên hệ
thống và tham gia thực hành trên lớp, hoặc ngược lại,…
- Các hệ thống blog, wikis… cũng có thể hỗ trợ giảng dạy
Hệ thống được xây dựng sẽ cung cấp những hình thức hỗ trợ giảng dạy
như: cung cấp môi trường học tập ảo, lưu trữ nội dung các khóa học, nội dung
các loại hình nghệ thuật, nội dung bài giảng, người học sẽ kết hợp việc học trên
lớp và học online trên hệ thống, bên cạnh đó hệ thống sẽ là thư viện tra cứu các
nội dung đa phương tiện của các loại hình nghệ thuật giúp việc bảo tồn và truyền
bá văn hóa phi vật thể tốt hơn và rộng rãi hơn.
Phần mềm hỗ trợ giảng dạy theo mô hình vai mẫu được xây dựng từ các
mẫu thiết kế tương tác người máy lấy người dùng làm trung tâm và ứng dụng
công nghệ đa phương tiện sẽ cung cấp những hình thức hỗ trợ giảng dạy như:
thể hiện các vai mẫu trên môi trường học tập ảo, công cụ xây dựng và lưu trữ
nội dung các khóa học, các loại hình nghệ thuật, nội dung các bài giảng… Sinh
viên sẽ kết hợp học lý thuyết trên lớp sau đó sử dụng phần mềm để tham khảo
áp dụng thực hành theo các vai mẫu.
Các mẫu thiết kế tương tác người máy lấy người dùng làm trung tâm được
xây dựng giúp giảm thời gian, chi phí tài nguyên dự án và tăng cường sự tham
gia của người dùng vào quá trình phát triển. Việc phần mềm ứng dụng công
nghệ đa phương tiện như (hình ảnh, văn bản, âm thanh, video 2D, video 3D),
đặc biệt ứng dụng công nghệ 3D vào hỗ trợ giảng dạy, cho phép người dùng chủ

động quản lý nội dung video 3D, nhúng nội dung video 3D vào bài giảng. Trong
khi các phần mềm khác hiện tại mới cho phép nhúng nội dung video 3D từ hệ
thống khác vào bài giảng. Bên cạnh đó phần mềm còn hỗ trợ việc biên tập nội
dung video 3D, cho phép kết hợp âm thanh và ghép nhiều cảnh diễn 3D vào
cùng một vở diễn, giúp tiết kiệm thời gian biên tập nội dung và tái sử dụng được
các cảnh diễn 3D.
Luận văn bao gồm những phần nội dung sau:
Chương 1. Tổng quan về quy trình phát triển phần mềm. Chương này
tổng hợp, tóm tắt tổng quan về các quy trình phát triển phần mềm. Để có thể lựa
chọn được quy trình phù hợp với dự án
4


Chương 2. Các phương pháp tạo mẫu, thiết kế tương tác người máy.
Chương này trình bày tổng quan về mục đích, vai trò, qui trình tạo mẫu. Phân
tích đánh giá, so sánh các phương pháp, các kỹ thuật tạo mẫu và các công cụ tạo
mẫu. Sau đó áp dụng phương pháp tạo mẫu, thiết kế tương tác người máy phù
hợp để xây dựng các mẫu thiết kế của phần mềm.
Chương 3. Nghiên cứu xây dựng phần mềm. Áp dụng kỹ thuật xây dựng
mẫu nhanh dựa trên phân tích lấy người dùng làm trung tâm vào quá trình phát
triển, nghiên cứu ứng dụng công nghệ đa phương tiện (văn bản, hình ảnh, âm
thanh, video 2D và 3D) vào hỗ trợ giảng dạy, đặc biệt ứng dụng công nghệ 3D

5


CHƯƠNG 1. TỔNG QUAN VỀ QUY TRÌNH PHÁT TRIỂN
PHẦN MỀM
Trong công nghệ phần mềm hiện nay có nhiều quy trình phát triển phần
mềm khác nhau, mỗi quy trình phát triển đều có ưu điểm và nhược điểm riêng.

Để phát triển phần mềm có thể áp dụng nhiều quy trình khác nhau, tuy nhiên
không phải mọi quy trình đều thích hợp cho mọi dự án. Vì vậy, việc lựa chọn
quy trình phát triển phần mềm thích hợp cho dự án sẽ quyết định sự thành công
của dự án. Trong chương này tôi sẽ trình bày tổng quan về quy trình phát triển
phần mềm, tổng hợp lại một số quy trình phát triển phần mềm, các ưu điểm và
nhược điểm của từng quy trình. Từ đó sẽ đề xuất áp dụng quy trình thích hợp
cho dự án. Dưới đây là nội dung chi tiết của chương.
1.1 Quy trình phát triển phần mềm
Vòng đời phần mềm (Software life-cycle): là thời kỳ tính từ khi phần mềm
được sinh (tạo) ra cho đến khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận
hành, bảo dưỡng cho đến khi loại bỏ). Quy trình phần mềm được phân chia
thành các pha chính gồm: phân tích, thiết kế, chế tạo, kiểm thử và bảo trì [3].
Quy trình phát triển phần mềm (Software development/Engineering
Process - SEP) là phương pháp phát triển hay sản xuất ra sản phẩm phần mềm.
Có thể nói quy trình phát triển phần mềm có tính chất quyết định để tạo ra sản
phẩm chất luợng tốt với chi phí thấp và năng suất cao [1, 3].
Thông thường một quy trình bao gồm những yếu tố cơ bản sau: Thủ tục
(Procedures), danh sách kiểm định (Checklists), hướng dẫn công việc (Activity
Guidelines), công cụ hỗ trợ (Tools) và biểu mẫu (Forms/templates) [1].

Có 4 công việc chính trong quy trình phát triển phần mềm gồm:
- Đặc tả yêu cầu (Requirements Specification): chỉ ra những “đòi
hỏi” cho cả các yêu cầu chức năng và phi chức năng.
- Phát triển phần mềm (Development): tạo ra phần mềm thỏa mãn
các yêu cầu được chỉ ra trong phần “đặc tả yêu cầu”.

6


- Kiểm thử phần mềm (Validation/Testing): để bảo đảm phần mềm

sản xuất ra đáp ứng những “đòi hỏi” được chỉ ra trong “đặc tả yêu
cầu”.
- Thay đổi phần mềm (Evolution): đáp ứng nhu cầu thay đổi của
khách hàng.
Tùy theo mô hình phát triển phần mềm, các nhóm công việc được triển
khai theo những cách khác nhau. Để sản xuất cùng một sản phẩm phần mềm
người ta có thể dùng các mô hình khác nhau. Tuy nhiên không phải tất cả các
mô hình đều thích hợp cho mọi ứng dụng.
1.2 Các phương pháp phát triển phần mềm
Trong thời gian gần đây, rất nhiều các phương pháp phát triển phần mềm
được đề xuất. Nhiều phương pháp đã được lý thuyết hoá thành các phương pháp
luận. Trong dự án công nghệ thông tin, một phương pháp luận có thể được hiểu
như là một tập các hoạt động thực tiễn được hệ thống hoá. Tuỳ theo phạm vi dự
án, điều kiện thời gian và nhiều yếu tố khác mà có thể lựa chọn áp dụng các
phương pháp khác nhau, hoặc kết hợp các phương pháp sao cho phù hợp. Các
mô hình, phương pháp phát triển phần mềm có thể được phân chia thành hai lớp
chính: các phương pháp truyền thống và các phương pháp phát triển nhanh.
Các phương pháp truyền thống là các phương pháp thiên về kế hoạch,
quá trình phát triển phần mềm phải tuân thủ quy trình một cách nghiêm ngặt.
Trong quá trình phát triển phần mềm, rất nhiều tài liệu được tạo ra, được xét
duyệt và đó là một yếu tố quan trọng trong quản lý rủi ro.
Với các phương pháp này, thì quá trình phát triển phần mềm giống như
sản xuất các mặt hàng công nghiệp khác. Những người phát triển thực hiện công
việc một cách nghiêm ngặt theo các chuẩn và quy trình, không yêu cầu sáng tạo
nhiều. Những người quản lý chỉ quan tâm đến việc tăng năng lực sản xuất và đạt
được một số mục tiêu như [3]:
- Giảm thiểu lỗi và làm sao cho mọi công việc diễn ra trơn tru.
- Cố gắng giữ ổn định (về tổ chức, về sản lượng...)
- Chuẩn hoá mọi thao tác và bắt buộc người thực hiện phải tuân theo
một cách nghiêm ngặt.

- Không cho phép sự sai sót.
7


Các phương pháp này thường áp dụng cho các dự án lớn. Một số phương
pháp tiêu biểu thuộc lớp này như: mô hình thác nước, mô hình chữ V, mô hình
xoắn ốc, mô hình lặp và gia tăng...
Các phương pháp phát triển nhanh được gọi với cái tên là Agile, theo
nghĩa là nhanh nhẹn, khéo léo trong hành động, là các phương pháp dựa trên các
quy trình phát triển nhanh. Điều này đặc biệt cần thiết trong lĩnh vực Internet và
truyền thông di động hiện đang phát triển rất nhanh chóng [12].
Các phương pháp phát triển nhanh ra đời cách đây không lâu. Nó được
bắt đầu bởi tuyên ngôn về các phương pháp phát triển phần mềm Agile được
đưa ra bởi một nhóm những người hoạt động trong lĩnh vực phần mềm vào năm
2001. Những người này đại diện cho các phương pháp như: Extreme
Programming (XP), Scrum, Crystal và các phương pháp khác cùng thống nhất
đưa ra một bản tuyên ngôn với những điểm chính sau [12]:
Chúng ta dần phát hiện ra những cách phát triển phần mềm tốt hơn bằng
cách thực hiện nó và giúp người khác thực hiện nó. Qua công việc này, chúng ta
thu được các giá trị:
- Các cá nhân và sự tương tác với nhau quan trọng hơn các quy trình và
các công cụ.
- Làm phần mềm quan trọng hơn việc lập tài liệu.
- Việc hợp tác với khách hàng quan trọng hơn việc ký kết hợp đồng.
- Đáp ứng thay đổi quan trọng hơn việc theo một kế hoạch.
Ở đây không có sự mâu thuẫn giữa các phương pháp truyền thống và các
phương pháp phát triển nhanh. Vấn đề là ở chỗ những điều mà các phương pháp
phát triển nhanh và các phương pháp truyền thống chú trọng vào là khác nhau.
Điểm chính của các phương phát phát triển nhanh là việc đáp ứng thay đổi trong
khi các phương pháp truyền thống tập trung vào kế hoạch.

Đối với dự án bảo tồn văn hóa phi vật thể nói chung và nội dung “Nghiên
cứu, xây dự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” nói riêng, việc áp dụng một trong các phương pháp nhanh sẽ phù
hợp hơn so với các phương pháp truyền thống.

8


1.3 Một số quy trình phát triển phần mềm
Mô hình thác nước (Waterfall Model) là mô hình hình phát triển phần
mềm áp dụng theo tính tuần tự của các giai đoạn phát triển phần mềm. Tức là
giai đoạn sau chỉ được thực hiện tiếp khi giai đoạn trước đã kết thúc và không
được quay lại giai đoạn trước để xử lí các thay đổi trong yêu cầu.
Năm 1970, Royce đã đưa ra khái niệm “mô hình thác nước” có thể sẽ
được cải tiến thành mô hình lặp với các pha theo thứ tự: Xác định các yêu cầu,
thiết kế, xây dựng (triển khai, mã hóa, viết code), liên kết, kiểm thử và chỉnh
sửa, cài đặt và bảo trì [1].
Nguyên tắc cơ bản của mô hình thác nước:
- Dự án được chia thành các giai đoạn tuần tự, có thể được chấp nhận
được một chút sự chồng chéo và quay lui trở lại giữa các giai đoạn
- Nhấn mạnh vào kế hoạch, tiến độ, thời gian mục tiêu để hoàn thành dự
án, ngân sách và thực hiện toàn bộ hệ thống cùng một lúc
- Được kiểm soát chặt chẽ thông qua việc sử dụng tài liệu bằng văn bản,
cũng như thông qua việc đánh giá chính thức và ký kết bởi người sử
dụng vào cuối giai đoạn trước khi bắt đầu giai đoạn tiếp theo

Hình 1.1 Mô hình thác nước

Hiện nay, tồn tại một số mô hình thác nước biến thể như mô hình của
Royce để phù hợp hơn với thực tế. Để giải quyết các vấn đề với mô hình thác

nước nguyên mẫu, các mô hình thác nước đã được chỉnh sửa và giới thiệu,
chẳng hạn như: “Mô hình thác nước với các pha chồng chéo, thác nước với các
dự án nhỏ và thác nước với giảm rủi ro”.

9


Mô hình này được sử dụng khi yêu cầu ổn định và không thay đổi thường
xuyên, phù hợp với các ứng dụng nhỏ, không có yêu cầu khó hiểu hoặc không rõ
ràng, môi trường ổn định, các công cụ và công nghệ được sử dụng là ổn định,
nguồn lực được đào tạo sẵn sàng.
Ưu điểm: đơn giản, dễ hiểu và sử dụng. Đối với các dự án nhỏ hơn, mô
hình thác nước hoạt động tốt và mang lại kết quả phù hợp. Vì các giai đoạn của
mô hình thác nước cứng nhắc và chính xác, một pha được thực hiện một lần, nó
rất dễ dàng để bảo trì. Các tiêu chí đầu vào và đầu ra được xác định rõ ràng, do
đó dễ dàng đánh giá chất lượng.
Nhược điểm: mô hình không thể chấp nhận thay đổi yêu cầu, sẽ trở nên rất
khó khăn để quay trở lại giai đoạn. Đối với các dự án lớn và phức tạp, mô hình
này không tốt vì yếu tố rủi ro cao hơn. Không thích hợp cho các dự án thường
xuyên thay đổi yêu cầu. Khi thử nghiệm được thực hiện ở giai đoạn sau, nó
không cho phép xác định những thách thức và rủi ro trong giai đoạn trước nên
chiến lược giảm thiểu rủi ro rất khó để chuẩn bị.
Mô hình chữ V (V-Shaped Model) hay mô hình xác minh (verification)
và mô hình xác nhận (validation) là một mở rộng của mô hình thác nước, thay vì
di chuyển xuống theo tuần tự các bước thì quy trình sẽ đi theo hình chữ V. Sự
khác biệt chính là việc lập kế hoạch kiểm tra sớm trong mô hình hình chữ V.
Đây là mô hình có kỷ luật cao và giai đoạn tiếp theo chỉ bắt đầu sau khi giai
đoạn trước hoàn thành [1, 3].
Xác minh (Verification): là một kỹ thuật phân tích tĩnh. Trong kiểm thử,
kỹ thuật này được thực hiện mà không phải chạy code. Nó bao gồm một số hoạt

động như xem lại (Review), kiểm tra (Inspection) và kiểm tra từ đầu tới cuối
(Walkthrough).
Xác nhận (Validation): là một kỹ thuật phân tích động, trong đó việc kiểm
thử được thực hiện bằng cách thực hiện code. Ví dụ bao gồm kỹ thuật kiểm tra
chức năng (Function) và phi chức năng (Non-function).
Trong mô hình chữ này các hoạt động phát triển và đảm bảo chất lượng
được thực hiện đồng thời. Kiểm thử được bắt đầu ngay từ giai đoạn lấy yêu cầu.
Các hoạt động xác minh và xác nhận đi liền với nhau được minh họa trong Hình
1.2. Trong quy trình phát triển theo mô hình chữ V điển hình, bên trái là các
hoạt động phát triển và bên tay phải là các hoạt động kiểm thử. Trong giai đoạn
10


phát triển cả việc xác minh và xác nhận được thực hiện cùng với các hoạt động
phát triển thực tế.

Hình 1.2 Mô hình chữ V

Mô hình này phù hợp với các dự án có yêu cầu được xác định và ghi lại rõ
ràng, các dự án được định nghĩa ổn định có quy mô vừa và nhỏ, các dự án ngắn,
các dự án có công nghệ không thay đổi và đội ngũ dự án hiểu rõ yêu cầu, không
có yều cầu mơ hồ hoặc không xác định.
Ưu điểm: quá trình phát triển và quy trình quản lý có tính tổ chức và hệ
thống, hoạt động tốt cho các dự án có quy mô vừa và nhỏ. Kiểm tra bắt đầu từ
khi bắt đầu phát triển vì vậy sự mơ hồ được xác định ngay từ đầu. Dễ dàng quản
lý vì mỗi giai đoạn có các mục tiêu và mục tiêu được xác định rõ ràng. Mỗi giai
đoạn có các sản phẩm cụ thể và một quá trình đánh giá.
Nhược điểm: không thích hợp cho các dự án lớn và phức tạp, dự án có các
yêu cầu thường xuyên thay đổi
Mô hình thử nghiệm tiến hóa phần mềm (Evolutionary Prototyping

Model) [3] đề cập đến việc xây dựng các nguyên mẫu ứng dụng phần mềm thể
hiện tính năng của sản phẩm đang được phát triển nhưng có thể không có sự
hoạt động logic chính xác của phần mềm gốc. Dựa vào những yêu cầu của
khách hàng người phát triển phần mềm sẽ xây dựng một mẫu thử ban đầu đưa
cho người sử dụng xem xét, sau đó tinh chỉnh qua nhiều mẫu thử cho đến khi
thỏa mãn yêu cầu người sử dụng thì dừng lại.
Sau đây là cách tiếp cận các bước để giải thích cách thiết kế một mẫu thử
nghiệm của phần mềm

11


Hình 1.3 Mô hình thử nghiệm tiến hóa

Xác định yêu cầu cơ bản: bước này liên quan đến việc hiểu được các yêu
cầu cơ bản về sản phẩm và đặc biệt nhất là về giao diện người dùng. Các chi tiết
phức tạp hơn của thiết kế bên trong và các khía cạnh bên ngoài như hiệu suất và
bảo mật có thể bỏ qua ở giai đoạn này.
Phát triển nguyên mẫu ban đầu: những nguyên mẫu ban đầu được phát
triển trong giai đoạn này, nơi yêu cầu rất cơ bản được giới thiệu và các giao diện
người dùng được cung cấp. Các tính năng này có thể không hoạt động chính xác
theo cách tương tự trong phần mềm thực tế khi phát triển, những nguyên mẫu
cung cấp cho khách hàng cái nhìn và cảm nhận về phần mềm sẽ như thế nào sau
khi phát triển
Đánh giá mẫu thử nghiệm: nguyên mẫu được phát triển sau đó được trình
bày cho khách hàng và các bên liên quan trong dự án. Phản hồi được thu thập có
tổ chức và được sử dụng để cải tiến thêm trong sản phẩm đang được phát triển.
Sửa đổi và nâng cao nguyên mẫu: phản hồi và ý kiến đánh giá được thảo
luận trong giai đoạn này và một số cuộc thương lượng diễn ra với khách hàng
dựa trên các yếu tố như: hạn chế về thời gian, về ngân sách và tính khả thi về

mặt kỹ thuật khi thực hiện. Các thay đổi được chấp nhận sẽ được kết hợp với
nguyên mẫu mới phát triển và chu kỳ lặp lại cho đến khi đáp ứng được kỳ vọng
của khách hàng.
Ưu điểm: tăng sự tham gia của người sử dụng vào sản phẩm ngay cả trước
khi phần mềm thực hiện. Kể từ khi một mô hình làm việc của hệ thống được
hiển thị, người sử dụng hiểu rõ hơn về hệ thống đang được phát triển. Giảm thời
gian và chi phí vì các lỗi có thể được phát hiện sớm hơn nhiều. Phản hồi của
người dùng nhanh hơn dẫn đến có các giải pháp tốt hơn. Thiếu sót chức năng thì
có thể được xác định một cách dễ dàng. Có thể xác định các chức năng khó hiểu.
12


Nhược điểm: có nguy cơ phân tích yêu cầu không đầy đủ do có sự phụ
thuộc quá nhiều vào mẫu thử nghiệm. Người dùng có thể bị nhầm lẫn giữa các
chức năng trong nguyên mẫu và hệ thống thực tế. Thực tế, phương pháp này có
thể làm tăng tính phức tạp của hệ thống vì phạm vi của hệ thống có thể mở rộng
ra ngoài kế hoạch ban đầu. Các nhà phát triển có thể thử sử dụng lại nguyên mẫu
hiện có để xây dựng hệ thống thực tế ngay cả khi nguyên mẫu không khả thi về
mặt kỹ thuật. Nỗ lực, chi phí đầu tư xây dựng nguyên mẫu có thể là quá nhiều
nếu nó không được theo dõi và quản lý đúng.
Học viên đã áp dụng mô hình thử nghiệm tiến hóa vào quá trình nghiên
cứu, xây dựng hệ thống hỗ trợ giảng dạy theo mô hình “vai mẫu” đối với kịch
hát dân tộc, bởi các ưu điểm của mô hình này giúp quá trình phát triển hệ thống
đạt được tiến độ, và chi phí, giúp quá trình đào tạo người dùng dễ dàng hơn.
Mô hình xoắn ốc (Spiral Model) [1-3] là sự kết hợp giữa mô hình thác
nước và mô hình tiếp cận lặp và nó có nhiều điểm giống nhau với mô hình gia
tăng. Mô hình này chú trọng vào phân tích rủi ro dự án. Mỗi giai đoạn trong mô
hình được bắt đầu với yêu cầu, mục tiêu thiết kế và kết thúc với việc khách hàng
kiểm tra tiến độ của từng giai đoạn.
Về cấu trúc, mô hình xoắn ốc có bốn giai đoạn. Một dự án phần mềm liên tục

đi qua các giai đoạn này trong các vòng lặp gọi là xoắn ốc.

Hình 1.4 Mô hình xoắn ốc

Các giai đoạn của mô hình xoắn ốc gồm:
Lập kế hoạch (Planning phase): thu thập, phân tích yêu cầu khách hàng
gồm các việc: ước lượng chi phí, lên lịch trình thực hiện dự án, xác định số
13


lượng nhân lực, môi trường làm việc, tìm hiểu yêu cầu hệ thống từ đó đưa ra các
tài liệu đặc tả để phục vụ cho việc trao đổi giữa khách hàng và phân tích hệ
thống sau này.
Phân tích rủi ro (Risk analysis phase): xác định rủi ro và đưa ra các giải
pháp thay thế. Một prototype sẽ được tạo ra ở cuối giai đoạn phân tích rủi ro.
Nếu có bất kỳ rủi ro nào được tìm thấy trong quá trình này thì các giải pháp thay
thế sẽ được đề xuất và thực hiện.
Thực thi kỹ thuật (Engineering phase): dự án được tiến hành viết mã, một
bản demo được phát triển trong giai đoạn này để có thể nhận được phản hồi của
khách hàng. Sau đó trong các vòng xoắn tiếp theo với độ rõ nét cao hơn về yêu
cầu và chi tiết thiết kế một mô hình làm việc của phần mềm được gọi là sản
phẩm được xây dựng với số phiên bản.
Đánh giá (Evaluation phase): khách hàng sẽ tham gia đánh giá công việc,
sản phẩm và đảm bảo rằng sản phẩm đáp ứng tất cả các yêu cầu đã đặt. Nếu có
bất kỳ yêu cầu thay đổi nào từ khách hàng, các giai đoạn sẽ được lặp lại. Đây là
giai đoạn quan trọng vì cần có sự phản hồi của khách hàng về sản phẩm trước
khi sản phẩm được phát hành.
Ưu điểm: cho phép các thành phần của sản phẩm được thêm vào, khi
chúng trở nên có sẵn. Điều này đảm bảo rằng không có xung đột với yêu cầu và
thiết kế trước đó. Một khía cạnh tích cực của phương pháp này là buộc người sử

dụng sự tham gia sớm vào quá trình phát triển hệ thống.
Nhược điểm: quản lý phức tạp và không thích hợp với các dự án nhỏ, ít
rủi ro. Cần có kĩ năng tốt về phân tích rủi ro. Yêu cầu thay đổi thường xuyên
dẫn đến lặp vô hạn. Đòi hỏi năng lực quản lí.
Mô hình lặp và gia tăng. Trong mô hình này, toàn bộ các yêu cầu được
chia thành nhiều bản xây dựng khác nhau. Trong mỗi lần lặp, mỗi môđun phát
triển đi qua các giai đoạn yêu cầu, thiết kế, thực hiện và kiểm thử. Mỗi phiên
bản phát hành tiếp theo sẽ có thêm các chức năng mới cho các phiên bản được
phát hành trước đó. Quá trình này tiếp tục cho đến khi hệ thống hoàn chỉnh và
đã sẵn sàng theo yêu cầu [3].
Phát triển lặp và gia tăng là sự kết hợp của cả thiết kế lặp lại, phương
pháp lặp và xây dựng mô hình gia tăng để phát triển. Trong quá trình phát triển
14


phần mềm, có thể tiến hành nhiều vòng lặp cùng một lúc. Quá trình này có thể
được mô tả như là một cách tiếp cận “tiến hóa” hoặc “tăng dần”.

Hình 1.5 Mô hình lặp và gia tăng

Ưu điểm: xây dựng và hoàn thiện các bước sản phẩm theo từng bước, có
thể nhận được phản hồi của người sử dụng từ những bản phác thảo, thời gian
làm tài liệu sẽ ít hơn so với thời gian thiết kế. Tìm ra các vấn đề ở giai đoạn phát
triển sẽ làm giảm chi phí thực hiện các biện pháp khắc phục lỗi, sai sót
Nhược điểm: mô hình này chỉ áp dụng cho các dự án phát triển phần mềm
qui mô lớn và cồng kềnh, bởi vì đối với hệ thống phần mềm nhỏ rất khó có thể
chia tách một hệ thống thành các bước gia tăng hay các mô-đun
Mô hình Scrum [11] là tập hợp các phương thức phát triển lặp và tăng
dần trong đó các yêu cầu cũng như giải pháp được phát triển thông qua sự liên
kết và cộng tác giữa các nhóm, giữa các chức năng. Agile chỉ là một mô hình

trên lý thuyết mà để triển khai nó đến thực tế thì cần phải có phương pháp cụ
thể, một trong các phương pháp được áp dụng rộng rãi là phương pháp Scrum.
Dự án sẽ được chia thành từng nhóm phát triển bao gồm: Product Owner,
Scrum Master và nhóm phát triển. Product Owner sẽ tạo ra một danh sách các
hạng mục cần phải phát triển theo độ ưu tiên cho sản phẩm được gọi là Product
Backlog. Dựa vào đó, một bản kế hoạch sẽ được lập để chia dự án thành các
Sprint tương ứng là các Sprint Backlog. Mỗi Sprint được kéo dài từ 1-4 tuần,
sau khi kết thúc kết quả sẽ được chuyển giao theo các hạng mục trong Sprint
Backlog và phải thỏa mãn định nghĩa hoàn thành đã được thống nhất trước đó.
Cuối cùng là sơ kết và cải tiến sprint sẽ được diễn ra, đưa ra phương pháp cải
tiến để có được hiệu quả tốt hơn.

15


Hình 1.6 Mô hình Scrum

Ưu điểm: là một mô hình hiện đại đang được ưa chuộng, bàn giao sản
phẩm một cách nhanh chóng liên tục cho khách hàng. Sự tương tác và yếu tố
con người được nhấn mạnh. Đề cao tính thích nghi liên tục thay đổi và làm mới.
Nhược điểm: mô hình này cần nguồn nhân lực có yếu tố chuyên môn kỹ
thuật cao. Dự án dễ đi chệch hướng khi khách hàng không đưa ra được kết quả
mong muốn cuối cùng. Chưa có được sự tập trung cần thiết vào thiết kế và tài
liệu cần thiết.
Mô hình Agile (Agile Software Development) [12] là một quy trình phát
triển phần mềm linh hoạt với ý tưởng khắc phục nhược điểm của các phương
pháp phát triển phần mềm truyền thống, với mục tiêu mang đến cho phần mềm
khả năng biến đổi, phát triển linh hoạt theo từng giai đoạn đơn giản đáp ứng
đúng yêu cầu của khách hàng.
Agile phát triển dựa trên quy trình phát triển lặp. Mỗi dự án được chia

thành nhiều giai đoạn nhỏ dễ dàng đáp ứng khi có yêu cầu thay đổi từ khách
hàng. Sản phẩm được bàn giao cho khách hàng theo từng giai đoạn, cứ mỗi khi
một mảng nhỏ được bàn giao, khách hàng có thể đưa ra các thay đổi hoặc yêu
cầu mới cho dự án và nhóm phát triển sẽ cập nhật sản phẩm theo đúng yêu cầu
của khách hàng mà không cần làm lại từ đầu.

16