ĐẠ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
PGS.TS. BÙI THẾ DUY
NGƯỜI HƯỚNG DẪN KHOA HỌC:
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ữ ...................................................................................................................... iv
Danh mục các bảng ............................................................................................................................... v
Danh mục các hình ............................................................................................................................... vi
Mở đầu ................................................................................................................................................... 1
Chương 1. Tổng quan về quy trình phát triển phần mềm................................................................. 4
1.1 Quy trình phát triển phần mềm ............................................................................................... 4
1.2 Các phương pháp phát triển phần mềm ................................................................................... 4
1.3 Một số quy trình phát triển phần mềm .................................................................................... 6
1.4 Kết chương ............................................................................................................................ 12
Chương 2. Các phương pháp tạo mẫu, thiết kế tương tác người - máy ......................................... 13
Tổng quan về mẫu thiết kế .................................................................................................... 13 2.1
Phương pháp và kỹ thuật tạo mẫu ......................................................................................... 13 2.2
Quá trình tạo mẫu (Software Prototyping) ................................................................ 13 2.2.1
Các phương pháp tạo mẫu ......................................................................................... 14 2.2.2
Các kỹ thuật xây dựng mẫu ....................................................................................... 15 2.2.3
Các công cụ tạo mẫu ................................................................................................. 18 2.2.4
2.3 Ưu điểm nhược điểm của tạo mẫu ........................................................................................ 18
2.4 Tiêu chí đánh giá mẫu ........................................................................................................... 19
2.5 Kết chương ............................................................................................................................ 21
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 ................................................................................................................................... 22
3.1 Phân tính mô hình người dùng .............................................................................................. 23
3.2 Áp dụng kỹ thuật tạo nguyên mẫu để đặc tả tương tác trong hệ thống ................................. 25
3.3 Phân tích, đánh giá mẫu ........................................................................................................ 25
Lập kế hoạch đánh giá mẫu ....................................................................................... 25 3.3.1
Tổ chức phiên đánh giá và kết quả các phiên đánh giá ............................................. 26 3.3.2
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 ..................................................................................................................... 27
3.4 Nghiên cứu, xây dựng hệ thống ............................................................................................ 28
Phân tích thiết kế ....................................................................................................... 28 3.4.1
Xây dựng hệ thống .................................................................................................... 32 3.4.2
3.5 Kết chương ............................................................................................................................ 35
Kết luận ................................................................................................................................................ 36
Tài liệu tham khảo .............................................................................................................................. 37
iii
DANH MỤC CÁC THUẬT NGỮ
Tiếng anh Chú giải
Ký hiệu, viết tắt Agile Agile Software Development Phát triển phần mềm Agile
HTML Hypertext Markup Language
RAD Rapid Application Development Mô hình phát triển nhanh
Software development/ Engineering SEP Quy trình phát triển phần mềm Process
UAT User acceptance test Test case kiểm thử chấp nhận
UCSD User Center System Design Thiết kế lấy người dùng làm trung tâm
Extreme Programming Lập trình cực hạn XP
Graphical User Interface Giao diện đồ họa người dùng GUI
Những nhân vật tiêu biểu trong một số tích Vai mẫu diễn của sân khấu truyền thống
iv
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........................................................... 16 Bảng 2.2 So sánh giữa các kỹ thuật tạo mẫu mức độ trung thực cao .................................................... 17
Bảng 3.1 Phân loại mô hình người dùng trong hệ thống ....................................................................... 23 Bảng 3.2 Mô tả các nhóm làm việc và nhiệm vụ .................................................................................. 24 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 ........................................................................................................................................ 24 Bảng 3.4 Tạo kịch bản các nhiệm vụ đánh giá mẫu .............................................................................. 26 Bảng 3.5 Những góp ý, và kết quả đánh giá mẫu ................................................................................. 27
v
DANH MỤC CÁC HÌNH
Hình 3.1 Lược đồ các Use Case hệ thống ............................................................................................. 28 Hình 3.2 Lược đồ hoạt động thêm mới nội dung 3D ............................................................................ 29 Hình 3.3 Lược đồ hoạt động thêm mới nội dung video 2D .................................................................. 29 Hình 3.4 Lược đồ hoạt động thêm mới nội dung đa phương tiện, hình ảnh ......................................... 30 Hình 3.5 Lược đồ hoạt động tra cứu, xem nội dung đa phương tiện .................................................... 30 Hình 3.6 Lược đồ hoạt động xây dựng bài giảng .................................................................................. 31 Hình 3.7 Lược đồ lớp ............................................................................................................................ 31 Hình 3.8 Lược đồ quan hệ giữa các bảng cơ sở dữ liệu ........................................................................ 32
vi
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
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.
1
Để 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.
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.
- 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
2
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
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
3
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”.
- 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
4
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.
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.
5
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.
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
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”.
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).
6
Ư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
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.
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
7
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.
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ố 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 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”.
Ư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ế.
8
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.
Ư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.
Mô hình Agile hoạt động dựa trên những tôn chỉ sau:
- Cá nhân và sự tương hỗ quan trọng hơn quy trình và công cụ.
- Phần mềm sử dụng được quan trọng hơn tài liệu về sản phẩm.
- Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng
- Phản hồi với sự thay đổi quan trọng hơn bám theo kế hoạch.
Các nguyên tắc của Manifesto Agile
Nguyên tắc 1: thỏa mãn yêu cầu của khách hàng thông qua việc giao hàng sớm và liên tục
Nguyên tắc 2: giao phần mềm chạy được cho khách hàng một cách thường xuyên (giao hàng
tuần hơn là hàng tháng)
Nguyên tắc 3: chào đón việc thay đổi yêu cầu, thậm chí là những thay đổi yêu cầu muộn
Nguyên tắc 4: khách hàng của dự án và đội phát triển phải làm việc cùng nhau hàng ngày
trong suốt dự án
Nguyên tắc 5: các dự án được xây dựng xung quanh những cá nhân có động lực. Cung cấp cho
họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc
9
Nguyên tắc 6: trao đổi trực tiếp mặt đối mặt là phương pháp hiệu quả nhất để truyền đạt thông
tin
Ưu điểm: Agile là một cách tiếp cận rất thực tế để phát triển phần mềm cho phép thúc đẩy làm
việc theo nhóm và đào tạo chéo. Các chức năng có thể được phát triển nhanh chóng và có thể demo nhanh với yêu cầu tài nguyên tối thiểu. Thích hợp với các dự án có yêu cầu cố định hoặc thay đổi, cung cấp các giải pháp làm việc từng phần.
Nhược điểm: không thích hợp để xử lý phụ thuộc phức tạp. Rủi ro hơn về tính bền vững, khả
năng bảo trì và khả năng mở rộng. Một kế hoạch tổng thể, người quản lý nhóm và quản lý dự án là cần thiết mà không có nó sẽ không hoạt động. Phụ thuộc rất nhiều vào sự tương tác của khách hàng, do đó nếu khách hàng không rõ ràng, nhóm có thể bị lái theo đúng hướng. Có một sự phụ thuộc cá nhân rất cao, vì có tài liệu tối thiểu được tạo ra. Việc chuyển giao công nghệ cho các thành viên mới trong nhóm có thể khá khó khăn do thiếu tài liệu
Mô hình XP (Extreme Programming) [7] là phương pháp phát triển phần mềm hướng đến việc nâng cao chất lượng phần mềm và khả năng đáp ứng với thay đổi yêu cầu người dùng. XP là một trong các phương pháp thuộc họ Agile, nó chủ trương đưa ra các bản phát hành thường xuyên thông qua các chu trình phát triển ngắn. Việc này là để nâng cao năng suất và tạo ra những thời điểm để tiếp nhận những yêu cầu người dùng mới.
Các giá trị trong XP:
- Giao tiếp (Communication): mọi người trong nhóm trao đổi trực diện hằng ngày, trong tất cả các công việc từ phân tích yêu cầu cho tới lập trình.
- Tính đơn giản (Simplicity): chỉ làm những gì cần thiết, không hơn. Làm những gì cần thiết cho hiện tại, không phải tương lai quá xa, với những bước nhỏ để cán đích và giản lược tối đa các sai sót.
- Phản hồi (Feedback): cam kết nghiêm túc để liên tục bàn giao các phần mềm chạy tốt vào cuối các phân đoạn (iteration) ngắn. Luôn có thể demo phần mềm chạy tốt từ sớm và thường xuyên, lắng nghe phản hồi từ các bên và thực hiện các điều chỉnh cần thiết.
- Tôn trọng (Respect): mọi người tự cảm thấy và được tôn trọng vì họ là những thành viên quan trọng của nhóm. Mỗi người đều đóng vai trò vào việc tạo ra các giá trị không kể công việc như thế nào.
- Can đảm (Courage): luôn nói đúng về tiến độ và ước lượng. Không cần thiết phải sợ điều gì bởi vì thành viên không làm việc một mình. Mỗi khi có thay đổi, nhóm sẽ có các hành động cần thiết để thích ứng. Can đảm trong việc vứt đi những gì không thực sự cần thiết nữa (mã nguồn, giấy tờ …)
Các nguyên tắc:
- Phản hồi nhanh (Rapid Feedback): luôn lắng nghe phản hồi từ nhiều phía, lấy được phản hồi một cách nhanh nhất, tìm hiểu chúng và đưa những hiểu biết đó vào trong hệ thống nhanh nhất có thể. Lập trình viên có thể học được cách thiết kế, lập trình, kiểm thử tốt nhất trong phạm vi từng phút chứ không phải hằng ngày, tuần hoặc thậm chí hằng tháng.
- Giả định đơn giản (Assume Simplicity): Đối xử với các vấn đề như thể chúng có thể giải quyết bằng những giải pháp đơn giản nhất.
10
- Thay đổi tiệm tiến (Incremental Change): không thay đổi cả “lố”, mà chỉ thay đổi một ít trong thiết kế, chức năng.
- Sống chung với thay đổi (Embracing Change): chiến thuật tốt nhất là tôn trọng tất cả các khả năng trong khi giải quyết các vấn đề áp lực nhất.
- Công việc chất lượng cao (Quality Work): phải luôn đầu tư để có được chất lượng công việc cao nhất, đến mức “hoàn hảo”
- Ưu điểm của mô hình này là đội dự án nhanh chóng nhận được phản hồi từ phía khách hàng. Những thay đổi cần thiết sẽ được áp dụng ngay trong lần lặp tiếp theo.
- Nhược điểm: khó có thể áp dụng XP trên các dự án có số lượng nhân viên lớn, không hiệu quả đối với những khách hàng ở xa đội ngũ phát triển.
Mô hình phát triển nhanh (Rapid Application Development- RAD) [8] chính là mô hình tăng
dần với chu kỳ phát triển cực ngắn. Để đạt được mục tiêu này, RAD dựa trên phương pháp phát triển trên cơ sở thành phần hóa hệ thống cùng với việc tái sử dụng các thành phần thích hợp. RAD thích hợp cho những hệ thống quản lý thông tin. Mô hình RAD phân phối các phân tích, thiết kế, xây dựng và các giai đoạn thử nghiệm vào một loạt các chu trình phát triển ngắn, lặp. Các giai đoạn khác nhau của mô hình RAD:
Mô hình hóa nghiệp vụ, cho sản phẩm được phát triển, thiết kế theo luồng thông tin và phân phối thông tin giữa các nghiệp vụ khác nhau. Một phân tích nghiệp vụ hoàn chỉnh được thực hiện để tìm ra những thông tin quan trọng cho hoạt động nghiệp vụ, làm thế nào để có được điều đó, như thế nào và khi nào thì thông tin được xử lý và những yếu tố nào thúc đẩy dòng thông tin thành công.
Mô hình hóa dữ liệu, thông tin thu thập được trong giai đoạn mô phỏng nghiệp vụ được xem xét và phân tích để tạo thành các bộ đối tượng dữ liệu quan trọng cho hoạt động nghiệp vụ. Các thuộc tính của tất cả các bộ dữ liệu được định nghĩa và xác định. Mối quan hệ giữa các đối tượng dữ liệu được thiết lập và xác định cụ thể liên quan đến mô hình nghiệp vụ.
Mô hình hóa quy trình, tập những đối tượng dữ liệu được xác định trong giai đoạn mô hình hóa dữ liệu được chuyển đổi để thiết lập luồng thông tin nghiệp vụ cần thiết để đạt được các mục tiêu nghiệp vụ cụ thể theo mô hình nghiệp vụ. Mô hình hóa quy trình cho bất kỳ thay đổi hoặc cải tiến đối với tập những đối tượng dữ liệu được xác định trong giai đoạn này. Mô tả quy trình để thêm, xóa, truy xuất hoặc sửa đổi một đối tượng dữ liệu được đưa ra
Xây dựng ứng dụng, hệ thống thực tế được xây dựng và mã hóa được thực hiện bằng cách sử dụng các công cụ tự động hóa để chuyển đổi mô hình quy trình và dữ liệu thành các nguyên mẫu thực tế.
Kiểm thử và nghiệm thu, thời gian thử nghiệm tổng thể được giảm xuống trong mô hình RAD vì các nguyên mẫu được kiểm tra độc lập giữa mỗi lần lặp. Tuy nhiên, luồng dữ liệu và giao diện giữa tất cả các thành phần cần phải được kiểm tra kỹ lưỡng với phạm vi kiểm tra hoàn chỉnh. Vì hầu hết các thành phần lập trình đã được thử nghiệm, nó làm giảm nguy cơ của bất kỳ vấn đề lớn nào.
Ưu điểm: RAD cho phép phân phối nhanh chóng vì nó giúp giảm thời gian phát triển tổng thể
do khả năng sử dụng lại các thành phần và phát triển song song. Có thể được áp dụng thành công cho các dự có sự môđun hóa rõ ràng
Nhược điểm: phụ thuộc vào các thành viên trong nhóm kỹ thuật để xác định các yêu cầu
nghiệp vụ. Không thích hợp với các dự án ít kinh phí vì chi phí cho việc lập mô hình và tạo mã tự
11
động rất cao, quản lý phức tạp. Thích hợp cho các dự án đòi hỏi thời gian phát triển ngắn hơn, yêu cầu sự tham gia của người dùng trong suốt vòng đời.
1.4 Kết chương
Chương này cung cấp một cái nhìn tổng thể về các yếu tố trong qui trình phát triển phần mềm.
Những yếu tố này thường là các nhân tố quan trọng ảnh hưởng đến chất lượng phần mềm và khả năng đáp ứng mong muốn của khách hàng. Việc lựa chọn áp dụng các phương pháp phát triển phần mềm phù hợp, sẽ tăng khả năng đáp ứng thay đổi nhanh để có thể đưa ra được sản phẩm phần mềm có chất lượng, thoả mãn mong muốn của khách hàng và đảm bảo tiến độ thực hiện. Đã có nhiều phương pháp phát triển phần mềm được đề xuất, luận văn đã phân tích, đánh giá ưu, nhược điểm và khả năng ứng dụng của từng phương pháp. Từ những nội dung trình bày trong chương 1, học viên đề xuất phương án áp dụng mô hình thử nghiệm tiến hóa vào quá trình xây dựng phần mềm hỗ trợ giảng dạy, bởi các ưu điểm của mô hình tăng sự tham gia của người dùng vào quá trình phát triển, giúp người dùng có cái nhìn ban đầu về hệ thống sẽ được phát triển, bên cạnh đó mô hình còn hỗ trợ việc hướng dẫn sử dụng, đặc biệt với đối tượng người sử dụng là những giảng viên lớn tuổi.
Để có thể áp dụng được mô hình thử nghiệm tiến hóa, trong chương 2 luận văn sẽ phân tích kỹ
và chi tiết hơn về phương pháp tạo mẫu, thiết kế tương tác người - máy cho phần mềm.
12
CHƯƠNG 2. CÁC PHƯƠNG PHÁP TẠO MẪU, THIẾT KẾ TƯƠNG TÁC NGƯỜI - MÁY
Thiết kế phần mềm là một công đoạn quan trọng trong quy trình phát triển phần mềm, giai đoạn này quyết định sự thành công hay thất bại của phần mềm. Việc xây dựng phần mềm theo mẫu thiết kế hướng tới việc tái sử dụng lại các mẫu thiết kế nhằm giảm chi phí thực hiện, tăng tính hiệu quả và tính nhất quán về bố cục phần mềm. Trong mô hình thử nghiệm tiến hóa, việc tạo mẫu thiết kế là công việc xuyên suốt của mô hình. Vì vậy, việc lựa chọn phương pháp thiết kế phù hợp với mô hình phát triển này sẽ giúp đạt hiệu quả về tiến độ, chi phí, tài nguyên của dự án. Nội dung chương này học viên sẽ tập trung giới thiệu tổng quan về mẫu thiết kế, các phương pháp và kỹ thuật tạo mẫu, ưu nhược điểm của việc tạo mẫu, các tiêu chí đánh giá mẫu. Từ các nội dung này học viên đề xuất phương pháp tạo mẫu thích hợp với mô hình đã lựa chọn. Nội dung chi tiết của chương học viên trình bày dưới đây.
2.1 Tổng quan về mẫu thiết kế
Ý tưởng dùng mẫu xuất phát từ ngành kiến trúc, Alexander, Ishikawa, Silverstein, Jacobson, Fiksdahl-King và Angel (1977) lần đầu tiên đưa ra ý tưởng dùng các mẫu chuẩn trong thiết kế xây dựng và giao thông. Họ đã xác định và lập sưu liệu các mẫu có liên quan để giải quyết các vấn đề thường xảy ra trong thiết kế các cao ốc. Mỗi mẫu này là một cách thiết kế, chúng đã được phát triển qua nhiều năm và như là các giải pháp cho các vấn đề trong lĩnh vực xây dựng thường gặp. Các giải pháp tốt nhất có được là qua một quá trình sàng lọc tự nhiên. Mẫu được xem là giải pháp tốt để giải quyết vấn đề xây dựng hệ thống phần mềm [4].
Mẫu thiết kế là khái niệm rộng và bao quát trong công đoạn thiết kế phần mềm. Cũng giống như các yêu cầu của thiết kế và phân tích hướng đối tượng việc sử dụng các mẫu cũng cần tái sử dụng được các giải pháp chuẩn đối với các vấn đề thường xuyên xảy ra. Mẫu thiết kế giúp thúc đẩy việc sử
dụng lại trong pha thiết kế vì mẫu cung cấp từ vựng chung cho thiết kế, cung cấp những phương tiện để hiểu thiết kế, và được tạo thành khối hợp nhất từ đó xây dựng những ứng dụng phức tạp hơn.
Mục đích của một nguyên mẫu là cho phép người sử dụng phần mềm đánh giá các đề xuất của
nhà phát triển cho việc thiết kế sản phẩm cuối cùng bằng cách thực sự thử chúng ở bên ngoài chứ không phải giải thích và đánh giá thiết kế dựa trên mô tả. Tạo nguyên mẫu cũng có thể được sử dụng bởi người dùng cuối để mô tả và chứng minh những yêu cầu chưa được xem xét và đó có thể là một yếu tố quan trọng trong mối quan hệ thương mại giữa các nhà phát triển và khách hàng của họ. Thiết kế tương tác nói riêng sử dụng rất nhiều nguyên mẫu phù hợp với mục tiêu đó. Tạo mẫu cũng có thể tránh được chi phí lớn và khó khăn trong việc thay đổi một sản phẩm phần mềm đã hoàn thành.
2.2 Phương pháp và kỹ thuật tạo mẫu
2.2.1 Quá trình tạo mẫu (Software Prototyping)
Các mẫu được sử dụng khi các yêu cầu phần mềm không thể được xác định tại thời điểm bắt đầu dự án, khi những người sử dụng không thể diễn đạt các yêu cầu của họ một cách rõ ràng. Mô hình phát triển phần mềm này rất phù hợp để phát triển “cảm nhận” hoặc giao diện sử dụng của hệ thống, bởi vì các đặc điểm này rất khó để miêu tả bằng tài liệu, mà thường thu được thông qua việc dùng thử nghiệm. Khi khách hàng yêu cầu chứng minh tính khả thi [5].
Bước 1: Xác định các yêu cầu cơ bản. Xác định các thông tin đầu vào và đầu ra mong muốn.
13
Bước 2: Phát triển nguyên mẫu ban đầu. Nguyên mẫu ban đầu được phát triển chỉ bao gồm
các giao diện người dùng
Bước 3: Xem xét, đánh giá các nguyên mẫu. Khách hàng và người dùng cuối, kiểm tra
nguyên mẫu và phản hồi để bổ sung tính năng hoặc thay đổi.
Bước 4: Sửa đổi và nâng cao mẫu thử nghiệm. Tại bước này sẽ sử dụng các phản hồi cùng
các chi tiết kỹ thuật và nguyên mẫu có thể được cải thiện. Đàm phán về những gì nằm trong phạm vi của hợp đồng, sản phẩm có thể là cần thiết. Nếu thay đổi được đề xuất thì có thể cần lặp lại các bước 3 và bước 4.
2.2.2 Các phương pháp tạo mẫu
Nguyên mẫu (Prototyping) [8] là một hệ thống có tính trình diễn, một mô hình làm việc
“nhanh và thô” của giải pháp cho hệ thống, nhằm kiểm tra một số chức năng nào đó. Có thể dùng giao diện người dùng miêu tả các thao tác khác nhau của hệ thống, nội dung có thể là mã cứng (hard- coded). Đây là một công cụ để thảo luận các khái niệm và có được sự đồng ý của người dùng sau trải nghiệm, nhưng nhóm phát triển vẫn phải hoàn toàn tạo ra hệ thống dựa trên bản vẽ. Vì lý do này, các bản vẽ này đôi khi được gọi là nguyên mẫu (Throwaway). Khi các giải pháp được đề xuất liên quan đến việc bổ sung các màn hình trực tuyến hoặc tạo ra các báo cáo, các nhà phân tích nghiệp vụ thường tạo ra những nguyên mẫu bao gồm storyboards, mô phỏng, hoặc mô hình. Việc tạo mẫu phần mềm có nhiều biến thể. Tuy nhiên, tất cả các phương pháp này được dựa trên hai hình thức tạo mẫu chính: nguyên mẫu (Throwaway Prototying) và mô hình tiến hóa (Evolutionary prototyping) [5].
Nguyên mẫu còn được gọi là mẫu cuối. Mẫu mô phỏng hay mẫu nhanh đề cập đến việc tạo ra một mô hình mà ở khâu cuối cùng mẫu sẽ được loại bỏ chứ không trở thành một phần của phần mềm cuối cùng. Sau khi hoàn thành việc thu thập yêu cầu sơ bộ, một mô hình làm việc đơn giản của hệ thống được xây dựng để hiển thị trực quan cho người sử dụng có thể thấy được hệ thống sẽ giống như khi được hoàn thành.
Với ưu điểm của phương pháp tạo mẫu này như tốc độ đưa ra nguyên mẫu nhanh, người dùng có thể tham gia vào quá trình xây dưng mẫu để đánh giá mẫu và kiểm tra tính năng của phần mềm nên học việc đã đưa ra đề xuất để áp dụng phương pháp tạo nguyên mẫu này vào quá trình xây dựng phần mềm.
Mẫu tiến hóa (Evolutionary prototyping) [5] là mẫu phát triển theo vòng đời, trong đó hệ thống được phát triển theo từng bước cho phép sửa đổi để đáp ứng với phản hồi của người dùng và khách hàng. Mẫu tiến hóa và mẫu mô phỏng là khá khác nhau. Mục tiêu chính khi sử dụng công cụ tạo mẫu tiến hóa là xây dựng một mẫu rất mạnh mẽ theo cấu trúc và liên tục tinh chỉnh nó. Lý do cho cách tiếp cận này là mẫu tiến hoá, khi được xây dựng, tạo thành trung tâm của hệ thống mới, những cải tiến và các yêu cầu tiếp theo sẽ được xây dựng.
Mẫu gia tăng (Incremental prototyping) [5] có thể được so sánh với 'khối xây dựng'; mỗi lần
gia tăng một thành phần mới được thêm vào hoặc tích hợp, dựa trên một giải pháp thiết kế tổng thể. Khi tất cả các thành phần được đưa ra, giải pháp đã hoàn tất.
Mẫu cực biên (Extreme prototyping) [5] là một quá trình kiến trúc để phát triển các ứng dụng, đặc biệt là các ứng dụng web, về nguyên mẫu ngày càng tăng. Ở mức độ cao, nó phân chia sự phát triển web thành ba giai đoạn riêng biệt. Giai đoạn đầu là nguyên mẫu tĩnh, bao gồm các trang HTML và có thể là một mô hình dữ liệu lôgíc hỗ trợ các trang đó. Giai đoạn thứ hai là một quá trình
14
mã hóa trong khuôn khổ web đã chọn của bạn, theo đó các màn hình có đầy đủ chức năng bằng cách sử dụng một lớp dịch vụ mô phỏng. Giai đoạn thứ ba là nơi mà các dịch vụ được thực hiện.
2.2.3 Các kỹ thuật xây dựng mẫu
Nguyên mẫu không nhất thiết giống sản phẩm cuối cùng mà hướng đến việc truyền tải cảm
giác và cảm nhận của sản phẩm cuối cùng. Mức độ trung thực của nguyên mẫu được chia ra các cấp độ từ thấp (Low Fidelity), trung bình cho tới cao (High Fidelity). Các mẫu thử nghiệm với độ trung thực thấp chủ yếu là mô phỏng bằng giấy còn mẫu thử nghiệm với độ trung thực cao chủ yếu là mô phỏng trên máy tính. Yếu tố quyết định trong độ tin cậy của nguyên mẫu là mức độ mà nguyên mẫu mô tả chính xác sự xuất hiện và tương tác của sản phẩm, chứ không phải mức độ mà mã và các thuộc tính vô hình khác đối với người dùng là chính xác. Mức độ trung thực thể hiện ở các khía cạnh như: thiết kế trực quan, nội dung, tương tác. Các nhóm sản phẩm chọn độ tin cậy của mẫu dựa trên mục tiêu tạo mẫu, tính đầy đủ của thiết kế và các tài nguyên có sẵn [4].
Mẫu thử nghiệm độ trung thực thấp là biểu diễn một cách nhanh chóng và dễ dàng để dịch các khái niệm thiết kế cấp cao thành các hiện vật hữu hình và thử nghiệm được. Vai trò đầu tiên quan trọng nhất của nguyên mẫu là kiểm tra và kiểm tra chức năng hơn là sự xuất hiện trực quan của sản phẩm.
Ưu điểm: lợi thế của việc tạo mẫu này là chi phí cực thấp. Tốc độ, có thể tạo một nguyên mẫu giấy nhanh cho phép các nhóm trao đổi các ý tưởng khác nhau mà không cần quá nhiều công sức, nhiều người có thể tham gia vào quá trình thiết kế và xây dựng ý tưởng.
Nhược điểm: không cho phép người dùng tương tác được được những gì có thể làm được hoặc không làm được. Một mẫu thử nghiệm độ trung thực thấp đòi hỏi nhiều trí tưởng tượng từ người dùng, hạn chế kết quả của việc kiểm tra người dùng đặc biệt với các nội dung chuyển tiếp phức tạp.
Bản phác thảo
Các kỹ thuật phác thảo (Sketched) [9] là cách hình dung và biểu diễn các ý tưởng thiết kế. Sau khi tạo ra các bản phác thảo ban đầu, những ý tưởng tốt nhất có thể được phát triển thêm bằng cách xây dựng các biểu diễn bằng bìa cứng của thiết kế, có thể được đánh giá bởi người dùng. Điều này sau đó có thể được phát triển bởi các kịch bản, phần mềm hoặc nguyên mẫu video.
Bản phác thảo tự do là cần thiết để đưa ra các ý tưởng trong giai đoạn đầu của thiết kế. Thông qua việc biểu diễn ý tưởng trên giấy, người thiết kế có thể hiệu chỉnh các tính năng. Ngoài việc sử dụng viết tay và bút chì, các bản phác thảo cũng có thể được thực hiện bằng phần mềm như: Paint và SILK. SILK cho phép các nhà thiết kế nhanh chóng phác hoạ một giao diện bằng điện tử và tương tác. Khi đó, các bản thảo sẽ được tạo ra nhanh hơn và rẻ hơn khi sử dụng các mẫu giấy và bút chì ở giai đoạn đầu. Nguyên mẫu tạo trên máy tính cho phép khám phá và thể hiện sự tương tác, tính nhất quán trong thiết kế.
Bảng phân cảnh
Bảng phân cảnh (Storyboard) [8] là mô tả đồ họa về sự xuất hiện bên ngoài của hệ thống dự
kiến mà không có chức năng hệ thống đi kèm. Bảng phân cảnh cung cấp ảnh chụp nhanh giao diện tại các điểm cụ thể trong tương tác để người dùng có thể xác định nhanh chóng nếu thiết kế đang đi đúng hướng
15
Bảng phân cảnh không yêu cầu nhiều về sức mạnh tính toán để xây dựng, trên thực tế, các
bảng phân cảnh sẽ thiếu tính thuyết phục nếu không có sự hỗ trợ của máy tính. Các mô tả đồ họa ngày nay được thiết kế với sự trợ giúp của máy tính thay vì bằng tay sẽ cung cấp hình ảnh động thô nhưng hiệu quả bằng cách tự động sắp xếp trình tự thông qua một loạt các bức ảnh chụp nhanh. Ví dụ như ứng dụng SILK cung cấp các chức năng kịch bản điện tử.
So sánh ưu nhược điểm giữa kỹ thuật sử dụng bảng phác thảo và bảng phân cảnh được thể
hiện trong Bảng 2.1
Bảng 2.1 So sánh giữa các kỹ thuật tạo mẫu độ trung thực thấp
Kỹ thuật Ưu điểm Nhược điểm
- Rất đơn giản và rẻ
- Phải tập trung cao ở mức khái niệm - Khó tưởng tượng để phát triển Bản phác thảo Sketched
- Chỉ có thể hiện thị hệ thống tương tác. - Phải có chuyên môn cần thiết về tương
- Đơn giản và rẻ - Người dùng có thể đánh giá trực tiếp của giao diện đầu tiên tác người máy Bảng phân cảnh Storyboard
Mẫu thử nghiệm mức độ trung thực cao xuất hiện và có chức năng giống với sản phẩm thực tế sẽ được đề xuất. Các nhóm thường tạo ra nguyên mẫu độ trung thực cao khi họ có hiểu biết chắc chắn về những gì họ sẽ xây dựng và họ cần hoặc thử nghiệm nó với người dùng thực hoặc nhận được sự chấp thuận thiết kế cuối cùng từ các bên liên quan.
Các đặc tính cơ bản của việc tạo mẫu độ trung thực cao bao gồm: Thiết kế trực quan, chi tiết tất cả các yếu tố giao diện, khoảng cách và đồ họa giống như một ứng dụng thực. Nguyên mẫu sẽ bao gồm hầu hết hoặc tất cả nội dung sẽ xuất hiện trong thiết kế cuối cùng và thể hiện được sự tương tác.
Ưu điểm: Nhận được những phản hồi hữu ích trong quá trình thử nghiệm khả năng sử dụng giống như sản phẩm thực. Điều này có nghĩa là trong các phiên thử nghiệm khả năng sử dụng, người tham gia kiểm tra sẽ có nhiều khả năng sử dụng một cách tự nhiên hơn như thể họ đang tương tác với sản phẩm thực. Mẫu thiết kế có thể dễ dàng thuyết phục khách hàng và các bên liên quan, phù hợp cho các cuộc giới thiệu demo với khách hàng với khả năng thể hiện ý tưởng rõ ràng về cách sản phẩm khi đưa vào hoạt động.
Nhược điểm: Chi phí thiết kế cao hơn cả về thời gian và tài chính.
Mô phỏng trên máy tính
Mô phỏng trên máy tính (Computer-based simulation) là nguyên mẫu mô phỏng trung thực
một số tương tác, tính năng của hệ thống dự định phát triển. Có ba cách tiếp cận để mô phỏng chức năng nguyên mẫu:
Nguyên mẫu theo chiều dọc (Vertical): Dựa trên nguyên mẫu cắt giảm về số lượng các tính
năng, chỉ hướng đến các chức năng chuyên sâu và các chức năng đã lựa chọn. Nguyên mẫu dọc cho phép người dùng thực hiện và kiểm tra một số nhiệm vụ quan trọng nhất.
Nguyên mẫu theo chiều ngang (Horizontal): Dựa trên nguyên tắc giảm mức độ chức năng hướng đến một hệ thống đầy đủ tính năng của giao diện hệ thống mà không có các chức năng cơ bản
16
thực sự. Ưu điểm chính của nguyên mẫu ngang là chúng có thể được thực hiện nhanh chóng với việc
sử dụng công cụ tạo mẫu và công cụ thiết kế màn hình, và chúng có thể được sử dụng để đánh giá giao diện nói chung.
Kịch bản (Scenario): Dựa trên nguyên tắc giảm cả số lượng các tính năng và mức độ chức năng. Giao diện người dùng được mô phỏng theo một kế hoạch đã có để đạt được kết quả cụ thể trong những trường hợp nhất định. Các kịch bản có thể dễ dàng được xây dựng, đánh giá sớm thiết kế giao diện để có được phản hồi của người dùng. Các công cụ phần mềm tạo mẫu phổ biến có thể kể đến như: RAPID, HyperCard, CHIRP. Bên cạnh đó, có rất nhiều ngôn ngữ thế hệ thứ tư dễ học và dễ sử dụng như: Smalltalk và Microsoft Visual Basic
Wizard of Oz
Kỹ thuật Wizard of Oz là một phương pháp thử nghiệm một hệ thống không tồn tại, cho phép các nhà thiết kế kiểm tra ý tưởng mà không cần thực hiện một hệ thống. Người dùng tương tác với màn hình, nhưng thay vì một phần của phần mềm đáp ứng các yêu cầu của người dùng, nhà phát triển đang ngồi ở màn hình khác mô phỏng hệ thống và tương tác với người dùng. Trình hướng dẫn có thể mô phỏng tất cả hoặc một phần của hệ thống chức năng. Khi thiết lập một mô phỏng Wizard of Oz cần những kinh nghiệm với các hệ thống đã được triển khai trước đó rất hữu ích để đạt những giới hạn thực tế lên "khả năng".
Nguyên mẫu trình chiếu và video
Nguyên mẫu trình chiếu và video (Slide shows and video prototyping) sử dụng các phương tiện truyền thông để tạo nguyên mẫu. Trong các trình chiếu, nguyên mẫu của storyboard được mã hoá
trên một máy tính với các công cụ phần mềm. Quá trình chuyển cảnh được kích hoạt đơn giản bởi đầu vào là người dùng thao tác. Các trang trình bày tạo thành nguyên mẫu ngang hoặc dọc đơn giản. Nguyên mẫu video loại bỏ những hạn chế của phần mềm. Không yêu cầu chỉnh sửa sau khi sản xuất hoặc bất kỳ chuyên môn đặc biệt nào trong sản xuất video. Tạo mẫu video không dừng lại ở việc ghi lại các ý tưởng thế kế, mà còn tạo ra một mô phỏng gợi ý về giao diện được đề xuất.
Cả hai kỹ thuật trình chiếu và tạo mẫu video đều cung cấp kiểu mô phỏng cuả hệ thống.
Chúng xuất hiện như một hệ thống thực sự mặc dù chúng chỉ hiển thị một số cảnh. Mô phỏng được hạn chế bởi một số nhiệm vụ được xác định trước chặt chẽ, và người dùng hầu như không tương tác với hệ thống.
Bảng 2.2 So sánh giữa các kỹ thuật tạo mẫu mức độ trung thực cao
Kỹ thuật Ưu điểm Nhược điểm
- Kiểm tra sâu trong các tình - Chỉ kiểm tra một phần giới hạn chức năng của hệ thống huống thực tế - Kiểm tra với các tác vụ của Nguyên mẫu theo chiều dọc người dùng
- Không thể thực hiện được các tác - Kiểm tra toàn bộ giao diện - Có thể thực hiện nhanh vụ Nguyên mẫu theo chiều ngang
- Dễ và rẻ tiền để xây dựng - Chỉ kiểm tra một phần giới hạn chức năng của hệ thống Kịch bản - Không thể thực hiện được các tác vụ
17
Wizard of Oz - Tiết kiệm thời gian lập trình - Tham gia chặt chẽ với người dùng giúp họ có thể hiểu biết thêm về hệ thống - Mọi thành viên cần được đào tạo để có thể hành động như máy tính Ít thực tế -
- Đơn giản - Mô phỏng hệ thống - Thiếu tính linh hoạt - Người dùng không thể tương tác với hệ thống Nguyên mẫu trình chiếu và video
2.2.4 Các công cụ tạo mẫu
Để việc tạo nguyên mẫu hiệu quả cần phải sử dụng các công cụ tạo mẫu. Các ngôn ngữ lập trình thế hệ thứ 4 (Visual Basic và ColdFusion) được sử dụng để tạo mẫu nhanh chóng thay cho các công cụ case tích hợp phức tạp. Với các ứng dụng trên nền web, các công cụ để tạo mẫu cũng phát triển, có thể kể đến như: Bootstrap, Foundation, AngularJS, Node JS, React Native…. Các công cụ trên cung cấp các công cụ cần thiết để xây dựng được một nguyên mẫu nhanh chóng từ ý tưởng. Các farmeworks này bao gồm một tập hợp các điều khiển, tương tác và hướng dẫn thiết kế cho phép các nhà phát triển nhanh chóng thử nghiệm các ứng dụng web [4].
Chương trình tạo màn hình, công cụ thiết kế. Các chương trình tạo màn hình cũng thường được sử dụng để giả lập hiển thị hệ thống cho người dùng. Các chức năng của hệ thống lúc này chưa hoạt động nhưng được hiển thị giả lập trên màn hình. Phát triển tương tác người máy sẽ là một phần quan trọng của nỗ lực phát triển vì người dùng sử dụng giao diện chủ yếu là hệ thống. Các công cụ phần mềm có thể tạo ra mã bằng cách kết hợp các thành phần môđun có sẵn nên có thể nhanh chóng cung cấp các chương trình với hành vi mong muốn, với số lượng mã hóa thủ công tối thiểu.
Ứng dụng định nghĩa hoặc phần mềm mô phỏng. Một lớp mới của phần mềm được gọi là định nghĩa ứng dụng hoặc phần mềm mô phỏng cho phép người dùng nhanh chóng xây dựng các mô phỏng hoạt hình nhẹ, sống động của một chương trình máy tính khác mà không cần viết mã. Phần
mềm mô phỏng ứng dụng cho phép cả người dùng kỹ thuật và phi kỹ thuật để trải nghiệm, thử nghiệm, hợp tác và xác nhận chương trình mô phỏng và cung cấp các báo cáo như chú thích, ảnh chụp màn hình và sơ đồ. Là một kỹ thuật đặc tả giải pháp, mô phỏng ứng dụng nằm giữa rủi ro thấp, nhưng giới hạn, văn bản hoặc bản vẽ dựa trên Mock-ups (hoặc wireframes) đôi khi được gọi là mẫu giấy dựa trên prototyping, và tốn nhiều thời gian, cho phép các chuyên gia phần mềm xác nhận các yêu cầu và lựa chọn thiết kế trước khi bắt đầu phát triển. Khi làm như vậy, rủi ro và chi phí liên quan đến việc triển khai phần mềm có thể được giảm đáng kể. Để mô phỏng các ứng dụng có thể sử dụng phần mềm mô phỏng để đào tạo trên máy tính, demo, và hỗ trợ khách hàng, ví dụ phần mềm Screencasting. Ngoài ra còn có nhiều công cụ chuyên dụng khác.
2.3 Ưu điểm nhược điểm của tạo mẫu
Ưu điểm: Giảm thời gian và chi phí trong quá trình phát triển. Cải thiện và tăng cường sự tham
gia của người sử dụng: nguyên mẫu yêu cầu sự tham gia của người sử dụng, cho phép họ nhìn thấy và tương tác với những mẫu thử nghiệm, để người dùng cung cấp phản hồi và thông số kỹ thuật tốt hơn, đầy đủ hơn. Nguyên mẫu được kiểm tra bởi người sử dụng, ngăn ngừa những hiểu lầm khi mất giao tiếp xảy ra, khi mà mỗi bên tin rằng bên khác hiểu những gì họ nói. Vì người dùng biết về những vấn đề liên quan đến nghiệp vụ trong lĩnh vực của họ tốt hơn bất cứ ai trong nhóm phát triển, khi gia tăng sự tương tác thì sản phẩm cuối cùng có chất lượng hơn cả về hữu hình và vô hình. Sản phẩm cuối cùng
18
có nhiều khả năng đáp ứng mong muốn của người dùng về giao diện, cảm nhận và hiệu suất. Người
dùng tích cực tham gia phát triển thì sẽ hiểu rõ hơn về hệ thống đang được phát triển. Các lỗi có thể được phát hiện sớm hơn với phản hồi người dùng nhanh hơn, dẫn đến có các giải pháp tốt hơn. Các chức năng khó có thể được xác định và hoàn thiện nhanh.
Nhược điểm: Việc tập trung vào một nguyên mẫu hạn chế có thể làm phân tâm các nhà phát
triển, dẫn đến phân tích sai hệ thống cuối. Các chi tiết kỹ thuật không đầy đủ sẽ khiến việc chuyển đổi các nguyên mẫu giới hạn thành các chức năng của dự án cuối cùng được thiết kế kém và khó bảo trì.
2.4 Tiêu chí đánh giá mẫu
Mỗi mẫu xây dựng có thể sẽ rất sáng tạo, nhưng nguyên mẫu cũng cần đánh giá một cách
khách quan thông qua các yếu tố khác nhau gồm: Giai đoạn thiết kế (đầu, giữa, cuối), tính mới của dự án (được xác định rõ ràng so với khảo sát), số người sử dụng dự kiến, tầm quan trọng của giao diện, chi phí sản phẩm và tài chính được phân bổ, thời gian hoàn thiện mẫu và kinh nghiệm của đội ngũ thiết kế và đội ngũ đánh giá [10].
Để đánh giá các giao diện mới hoặc sửa đổi giao diện được thực hiện khi khách hàng gửi phản hồi. Các buổi trình bày không chính thức cũng có thể nhận được một số phản hồi hữu ích, nhưng các đánh giá chuyên gia chính thức sẽ mang lại hiệu quả hơn. Phương pháp này phụ thuộc vào chuyên gia hoặc tư vấn. Các đánh giá của chuyên gia sau đó có thể được tiến hành thông báo ngắn gọn và nhanh chóng. Những điểm sau đây cần được người thiết kế quan tâm:
- Trong thiết kế sẽ không thể có sự hoàn hảo đối với hệ thống phức tạp, do đó kế hoạch phải bao gồm các phương pháp để tiếp tục sửa chữa các vấn đề phát sinh trong suốt vòng đời của một giao diện.
- Tại một số thời điểm quyết định việc thực hiện kiểm tra toàn diện các nguyên mẫu thiết kế
và phân phối các sản phẩm cuối.
- Các phương pháp kiểm tra thích hợp cho việc sử dụng các chức năng bình thường, nó thực sự hiệu quả khi phát hiện lỗi trong các tình huống không thể dự đoán trước khi sử dụng.
Nhận xét của chuyên gia có thể sớm hoặc muộn trong giai đoạn thiết kế. Kết quả có thể là một báo cáo chính thức với những vấn đề được xác định hoặc đề xuất thay đổi. Chuyên gia đánh giá cần phải đưa ra các gợi ý thận trọng bởi vì rất khó cho ai đó chỉ mới kiểm tra giao diện hiểu đầy đủ lý do thiết kế và lịch sử phát triển. Người đánh giá lưu ý các vấn đề có thể xảy ra để thảo luận với các nhà thiết kế. Có thể lựa chọn một trong nhiều phương pháp đánh giá chuyên gia:
Nguyên tắc đánh giá, kiểm thử. Là phương pháp kiểm tra kép, tìm kiếm các lỗi có thể đối với chương trình, giao diện. Các chuyên gia phê bình đánh giá một giao diện để xác định phù hợp với một danh sách ngắn các thiết kế thực nghiệm, chẳng hạn như tám quy tắc vàng: Chặt chẽ theo sự thống nhất chung, phục vụ khả năng sử dụng phổ thống, cung cấp thông tin phản hồi, thiết kế hộp thoại tiện
dụng và dễ hiểu, phòng tránh lỗi xảy ra trong quá trình sử dụng, cho phép dễ dàng thay đổi các hành động, hỗ trợ tập trung vào điểu khiển, giảm sự ghi nhớ của người sử dụng.
Hướng dẫn đánh giá: Giao diện được kiểm tra để phù hợp với tài liệu hướng dẫn tổ chức hoặc
tài liệu hướng dẫn khác. Bởi vì tài liệu hướng dẫn có thể chứa hàng nghìn bài viết, nên có thể cần có thời gian để các chuyên gia nhận xét làm chủ các nguyên tắc để xem xét một giao diện lớn.
19
Kiểm tra tính nhất quán. Các chuyên gia xác minh tính nhất quán trong một tập hợp các giao
diện, kiểm tra tính nhất quán của thuật ngữ, phông chữ, các phối màu, bố cục, định dạng đầu vào và đầu ra... trong giao diện cũng như trong tài liệu đào tạo và trợ giúp trực tuyến. Các công cụ phần mềm có thể giúp tự động hóa quá trình, cũng như kết hợp các từ và chữ viết tắt.
Định hướng nhận thức. Các chuyên gia mô phỏng cho người dùng thông qua giao diện để thực
hiện các tác vụ tiêu biểu, các kịch bản cụ thể. Phân chia kịch bản thành các kịch bản nhỏ hơn, mô phỏng tuân theo người dùng. Một số hình thức mô phỏng ngay trong cuộc sống của người sử dụng nên là một phần của quá trình đánh giá chuyên gia. Các hướng dẫn định hướng nhận thức đã được phát triển cho các giao diện có thể học bằng cách khám phá, nhưng chúng rất hữu ích ngay cả đối với các giao diện đòi hỏi phải đào tạo đáng kể.
Kiểm tra khả năng sử dụng. Các chuyên gia tổ chức một cuộc họp đánh giá, với một người
điều tiết, để mô tả, trình bày giao diện và thảo luận về những điểm mạnh và những điểm yếu của giao diện. Các thành viên của nhóm thiết kế có thể đưa ra bằng chứng về các vấn đề trong một định dạng đối lập. Kiểm tra khả năng sử dụng có thể là truyền đạt kinh nghiệm cho các nhà thiết kế và người quản lý mới làm quen, nhưng có thể mất nhiều thời gian hơn chuẩn bị và có nhiều nhân viên để thực hiện hơn là làm các loại đánh giá khác.
Lợi ích của việc đánh giá mẫu, các vấn đề về khả năng sử dụng tiềm năng có thể được phát hiện ở giai đoạn sớm trước khi quá trình phát triển hoàn tất. Người dùng sẽ hiểu sâu hơn về hệ thống, về những mong muốn của họ, và ấn tượng của họ về hệ thống. Phương pháp đánh giá được thực hiện thành các giai đoạn:
Giai đoạn lập kế hoạch:
1. Chọn các nhiệm vụ và nhóm người dùng quan trọng nhất để được kiểm tra (ví dụ:
thường xuyên nhất hoặc quan trọng nhất)
2. Chọn người dùng đại diện cho (các) nhóm người dùng. 3-5 người dùng đủ để xác định
các vấn đề chính
3. Xem xét việc sử dụng các tác vụ do người dùng định nghĩa, nơi người dùng được yêu
cầu xác định của họ trước kỳ thẩm định
4. Tạo kịch bản nhiệm vụ và nhập dữ liệu và viết hướng dẫn cho người dùng (trao đổi
với người sử dụng những gì để đạt được, chứ phải làm thế nào để làm điều đó).
5. Lập kế hoạch thời gian cho việc hướng dẫn, chạy thử và phỏng vấn sau khi chạy thử.
6. Mời các nhà phát triển quan sát các buổi họp nếu có thể. Một cách khác là quay video
các buổi, và cho các nhà phát triển chỉnh sửa clip về các vấn đề chính
7. Đối với một nguyên mẫu giấy một nhà thiết kế là cần thiết để đóng vai trò của "máy
tính
Giai đoạn chạy các phiên đánh giá
1. Chào mừng người dùng và đưa ra các hướng dẫn về nhiệm vụ
20
2. Đối với nguyên mẫu giấy, khi người dùng lựa chọn các tùy chọn trên mỗi màn hình, nhà thiết kế giải thích điều gì sẽ xảy ra, hoặc là trỏ tới màn hình tiếp theo hoặc trình bày màn hình kế tiếp cho người dùng
3. Không cung cấp bất kỳ gợi ý hoặc trợ giúp nào trừ khi người dùng không thể hoàn
thành nhiệm vụ
4. Quan sát sự tương tác và lưu ý bất kỳ vấn đề gặp phải
5. Người dùng có thể được nhắc hiển thị thiết kế trang của họ, họ nghĩ những yếu tố khác nhau có thể làm gì và họ mong đợi kết quả của hành động tiếp theo của họ như thế nào. Người dùng cũng có thể được yêu cầu đề xuất các yếu tố cá nhân có thể được cải thiện như thế nào
6. Phỏng vấn người sử dụng để đạt được ý kiến chung, và để hỏi về những vấn đề cụ thể
gặp phải
Kết quả của quá trình kiểm tra đánh giá: Tạo một danh sách các vấn đề về khả năng sử dụng, được phân loại theo tầm quan trọng và tổng quan về các loại sự cố gặp phải. Sắp xếp một cuộc họp với các nhà thiết kế để thảo luận và làm thế nào để mỗi vấn đề có thể được giải quyết
Trong quá trình xây dựng hệ thống, học viên cũng đã lập các kế hoạch đánh giá mẫu, áp dụng các tiêu chí đánh giá mẫu và tổ chức các phiên đánh giá mẫu trực tiếp tại Trường Đại học Sân khấu điện ảnh Hà Nội, từ đó có các cải tiến mẫu, phù hợp với người dùng.
2.5 Kết chương
Trong chương này, luận văn đã trình bày tổng quan về mẫu thiết kế, các phương pháp và kỹ thuật tạo mẫu trong thiết kế một hệ thống phần mềm. Học viên cũng đã tập trung phân tích, so sánh, đánh giá ưu, nhược điểm của các kỹ thuật xây dựng mẫu, trình bày các tiêu chí đánh giá mẫu. Trên cơ sở đánh giá các kỹ thuật và phương pháp tạo mẫu, học viên lựa chọn và đề xuất áp dụng phương pháp tạo mẫu nguyên mẫu kết hợp ứng dụng các kỹ thuật tạo mẫu với độ trung thực thấp và độ trung thực cao để xây dựng các nguyên mẫu của hệ thống. Vì phương pháp tạo nguyên mẫu này có ưu điểm sẽ nhanh chóng đưa ra được nguyên mẫu thử nghiệm của hệ thống cùng với mức độ trung thực của mẫu sẽ giúp người dùng hình dung, đánh giá và kiểm tra được các chức năng của phần mềm sẽ như thế nào. Bên cạnh việc áp dụng phương pháp tạo nguyên mẫu và các kỹ thuật tạo mẫu, học viên cũng đã lập các kế hoạch đánh giá mẫu, áp dụng các tiêu chí đánh giá mẫu để đánh giá các nguyên mẫu đã xây dựng của phần mềm. Cụ thể việc áp dụng phương pháp tạo mẫu nguyên mẫu, ứng dụng các kỹ thuật tạo mẫu và tổ chức các phiên đánh giá trong quá trình 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 học viên trình bày cụ thể trong nội dung chương 3 của luận văn này.
21
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
Trong chương này học viên sẽ trình bày 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. Học viên vận dụng các nội dung, kiến thức đã trình bày và thu nhận được từ chương 1 và chương 2 vào quá trình nghiên cứu xây dựng phần mềm.
Cụ thể trong chương 3 học viên sẽ áp dụng quy trình phát triển phần mềm theo mô hình thử nghiệm tiến hóa, áp dụng kỹ thuật xây dựng nguyên mẫu nhanh dựa trên phân tích lấy người dùng làm trung tâm của quá trình phát triển và 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à video 3D) đặc biệt ứng dụng công nghệ 3D vào hỗ trợ giảng dạy. Quá trình nghiên cứu phát triển được thực hiện qua các giai đoạn như sau.
Giai đoạn 1: Xác định yêu cầu cơ bản, khảo sát yêu cầu người dùng: giai đoạn này học viên thu
thập được các thông tin hiện trạng về việc ứng dụng công nghệ thông tin vào hỗ trợ giảng dạy tại trường Đại học Sân khấu Điện ảnh Hà nội, các loại hình sân khấu kịch hát dân tộc đang giảng dạy, các yêu cầu của người dùng, các mong muốn của người dùng. Từ đó học viên hiểu được cơ bản về yêu cầu của người dùng, và đặc biệt hiểu được giao diện của phần mềm sẽ cần xây dựng như thế nào để phù hợp với đối tượng người dùng.
Giai đoạn 2: Phát triển, xây dựng các nguyên mẫu ban đầu: trong giai đoạn này, từ những yêu cầu cơ bản của người dùng được thu thập ở giai đoạn 1, học viên áp dụng các kỹ thuật tạo mẫu nhanh, dựa trên phương pháp phân tích lấy người dùng làm trung tâm, sử dụng các công cụ tạo mẫu để đưa ra các nguyên mẫu ban đầu với mức độ trung thực thấp và độ trung thực cao của phần mềm.
Giai đoạn 3: Lên kế hoạch đánh giá nguyên mẫu: ở giai đoạn này, học viên đã sử dụng các nguyên mẫu đã xây dựng ở giai đoạn 2, lên kế hoạch, và xác định các tiêu chí đánh giá mẫu. Sau đó cùng nhóm nghiên cứu dự án tổ chức các buổi đánh giá trực tiếp tại đơn vị hưởng thụ. Kết thúc giai đoạn này, kết quả thu được là các phản hồi, góp ý của người dùng, và của các chuyên gia. Các ý kiến này được sử dụng để cải thiện các nguyên mẫu ban đầu. Và các nguyên mẫu được thống nhất xây dựng.
Giai đoạn 4: Xây dựng phần mềm, từ các nguyên mẫu đã đáp ứng được yêu cầu của người dùng ở giai đoạn trước, học viên đã xây dựng phần mềm ứng dụng công nghệ đa phương tiện vào hỗ trợ giảng dạy. Kết quả của giai đoạn này là phần mềm đã được xây dựng cung cấp các chức năng cho người sử dụng là giảng viên, sinh viên, cán bộ biên tập nội dung đa phương tiện.
Để xây dựng được hệ thống theo yêu cầu đã đề ra. Học viên đề xuất áp dụng những kiến thức thu nhận được ở chương 1 và chương 2 của luận văn này vào xây dựng hệ thống, đó là áp dụng quy trình phát triển phần mềm theo mô hình thử nghiệm tiến hóa và áp dụng phương pháp thiết kế nguyên mẫu lấy người dùng làm trung tâm (User Center System Design – UCSD), phương pháp thiết kế mẫu nguyên mẫu nhanh (Rapid Prototying) vào quá trình phát triển hệ thống, và xây dựng hệ thống hỗ trợ cho phép ứng dụng công nghệ đa phương tiện (ảnh, văn bản, âm thanh, video 2D, video 3D,…) đặc biệt hệ thống sẽ ứng dụng công nghệ 3D vào việc xây dựng bài giảng hỗ trợ giảng dạy.
Mô hình thiết kế đề xuất sẽ khắc phục được những nhược điểm cơ bản của các mô hình truyền thống bằng cách nâng cao vai trò của người sử dụng hệ thống. Ở mô hình này, người sử dụng được tham gia vào các giai đoạn của quá trình phát triển hệ thống và có các đánh giá phản hồi trở lại đối với đội ngũ phát triển, các phản hồi từ người sử dụng sẽ được dùng để cải tiến hệ thống.
22
Phương pháp thiết kế hệ thống lấy người sử dụng làm trung tâm đặt người sử dụng, mục đích,
nhu cầu và các hoạt động của họ vào trung tâm của quá trình phát triển và thiết kế. Yếu tố căn bản đảm bảo sự thành công của cách tiếp cận lấy người sử dụng làm trung tâm là quá trình lặp lại các giai đoạn thiết kế thay vì sử dụng một quá trình tuyến tính một chiều. Bên cạnh việc áp dụng mô hình thiết kế lấy người sử dụng làm trung tâm, luận văn cũng đề xuất phương pháp thiết kế mẫu nhanh vì phương pháp này giúp người sử dụng và đội phát triển có thể thử nghiệm hệ thống một cách nhanh chóng và có thể hỗ trợ đào tạo người dùng.
Với việc đề xuất xây dựng hệ thống ứng dụng công nghệ đa phương tiện như: dữ liệu ảnh, dữ
liệu văn bản, dữ liệu video 2D, dữ liệu video 3D, dữ liệu âm thanh, … vào xây dựng nội dung bài giảng sẽ có những ưu điểm, nhược điểm:
Ưu điểm:
- Giúp xây dựng các bài giảng với nội dung phong phú hấp dẫn người học, tăng khả năng hấp thụ và phát huy được khả năng sáng tạo của người học. Từ đó người học sẽ định hình các phong cách biểu diễn riêng không sinh ra những vai diễn “sao chép” đơn điệu.
- Nội dung đa phương tiện như ảnh, video 2D, dữ liệu âm thanh đa dạng, phong phú người
dùng có thể tự tạo ra các nội này bằng những cách đơn giản
- Với nội dung video 3D người học có thể xem được vai diễn ở nhiều góc cảnh diễn khác
nhau giúp người học có thể quan sát được các động tác chi tiết, cụ thể hơn
- Người học sẽ có nhiều vai mẫu với nhiều diễn viên diễn khác nhau để tham khảo
Nhược điểm:
- Nội dung video 3D còn hạn chế
- Việc thu thập, biên tập nội dung 3D tốn nhiều thời gian, công sức, và cần đến đội ngũ
chuyên gia
3.1 Phân tính mô hình người dùng
Để thực hiện phương pháp thiết kế mẫu nhanh, bước đầu tiên học viên hướng đến là phân loại
người dùng trong hệ thống. Học viên xác định các nhóm người dùng như sau:
Bảng 3.1 Phân loại mô hình người dùng trong hệ thống
Tên nhóm Mô tả Phân loại
Giáo viên, Sinh viên Nhóm chủ yếu
Nhóm thứ yếu Lãnh đạo Khoa Kịch hát dân tộc
Nhóm thứ ba Ban lãnh đạo nhà trường - Giáo viên: là những người giảng dạy trong trường. Giáo viên giảng dạy các chuyên ngành khác nhau, các loại hình nghệ thuật khác nhau. Giáo viên sử dụng hệ thống xây dựng các bài giảng hỗ trợ cho việc giảng dạy các loại hình kịch hát dân tộc. - Sinh viên: là những người học tập tại trường với các chuyên ngành khác nhau, trình độ khác nhau, họ sử dụng hệ thống để phục vụ trong quá trình học tập, tham khảo các bài học, các trích đoạn diễn…. - Lãnh đạo Khoa Kịch hát dân tộc là các cán bộ phụ trách quản lý Khoa, họ nhận kết quả báo cáo từ hệ thống và cung cấp những thông tin đầu vào của hệ thống. Lãnh đạo trường Đại học Sân khấu Điện ảnh, là ban giám hiệu nhà trường, họ sẽ chịu ảnh hưởng đến sự thành công hay thất bại của hệ thống Nhóm Đội thiết kế, Đội thiết kế, nhóm phát triển dự án, cán bộ phòng công nghệ thông tin,
23
thứ tư là những người tham gia xây dựng, phát triển, vận hành và bảo trì hệ thống nhóm phát triển dự án, cán bộ phòng CNTT
Qua quá trình thu thập yêu cầu của người dùng tại trường Đại học Sân khấu Điện ảnh Hà nội.
Học viên áp dụng mô hình người dùng trong thiết kế User skills and Task Match (USTM/CUSTOM) phân tích người liên quan trong mô hình thiết kế. Trong dự án phát triển hệ thống hỗ trợ giảng dạy, việc nhận dạng, xác định và chia nhóm người dùng trong hệ thống thành các nhóm. Xác định và mô tả các nhóm làm việc, một nhóm làm việc được xác định là nhóm những người có chung một nhiệm vụ. Như vậy các nhóm làm việc trong dự án bao gồm:
Bảng 3.2 Mô tả các nhóm làm việc và nhiệm vụ
Nhóm Xác định nhóm đối tượng Mô tả các cặp nhiệm vụ và đối tượng
Cán bộ quản lý Theo dõi tổng hợp báo cáo: cán bộ quản lý sẽ có các công việc liên quan đến theo dõi tổng hợp và báo cáo trên hệ thống Các cán bộ quản lý nhà trường, các cán bộ quản lý ở các Khoa, đơn vị trong trường sử dụng hệ thống để theo dõi tình hình xây dựng bài giảng của giáo viên, tình hình học tập của sinh viên, xem các báo cáo tổng hợp liên quan
Giáo viên Những giáo viên đang giảng dạy tại trường sử dụng hệ thống để hỗ trợ xây dựng bài giảng, theo dõi tình hình học tập của sinh viên trên hệ thống, xem các báo cáo liên quan Giảng dạy, xây dựng bài giảng: giảng viên sẽ có các hoạt động giảng dạy, xây dựng bài giảng trên hệ thống
Sinh viên
Nghiên cứu học tập: sinh viên sẽ có các hoạt động sử dụng hệ thống để nghiên cứu học tập các bài giảng, tham khảo tài liệu, video, ảnh Những sinh viên theo học các chuyên ngành trong các ngành đào tạo Kịch hát dân tộc với các trình độ khác nhau tại trường, sử dụng hệ thống trong quá trình nghiên cứu học tập các bài giảng, tham khảo các trích đoạn video, các tiết mục biểu diễn, nội dung đa phương tiện trên hệ thống.
Những cán bộ thuộc phòng Công nghệ thông tin, vận hành và bảo trì hệ thống. Quản trị hệ thống Bảo trì quản trị hệ thống: cán bộ quản trị hệ thống sẽ có các nhiệm vụ liên quan đến việc vận hành, bảo trì và quản trị hệ thống
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.
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
Nhóm Nhu cầu và chức năng của hệ thống
Cán bộ quản lý - Theo dõi được tình hình xây dựng bài giảng trên hệ thống - Trích xuất được các báo cáo…
Giáo viên
- Xây dựng được các bài giảng điện tử tích hợp nội dung đa phương tiện - Quản lý được các bài giảng do mình xây dựng - Upload và quản lý được các tệp dữ liệu trên hệ thống - Quản lý được các nội dung đa phương tiện của mình đã đưa lên hệ thống - Tìm kiếm các nội dung đa phương tiện đã đưa lên hệ thống - Quản lý được danh sách các học viên trong lớp…
24
Nhóm Nhu cầu và chức năng của hệ thống
Sinh viên
- Xem được các bài giảng do giáo viên cung cấp trên hệ thống - Tìm kiếm được nội dung các bài giảng mà mình quan tâm - Tìm kiếm được các nội dung đa phương tiện trên hệ thống - Xem và so sánh những vở diễn của người diễn khác nhau... - Xem cảnh diễn ở các góc diễn khác nhau.
Quản trị hệ thống
- Người dùng cần có tài khoản để đăng nhập vào hệ thống - Người dùng chỉ có thể xem được các bài giảng khi đã đăng nhập vào hệ thống - Chức năng giám sát các truy cập - Chức năng xem log các đăng nhập vào hệ thống - Quản lý các tin tức, thông báo trên hệ thống...
Áp dụng mô hình phân tích người dùng này giúp cho đội thiết kế và phát triển hệ thống hỗ trợ giảng dạy hiểu hơn về yêu cầu người dùng, hiểu rõ về những nhiệm vụ mà người dùng sẽ thao tác trên hệ thống và cho phép ghi lại toàn bộ những yêu cầu của người dùng. Khác với các mô hình khác chỉ tập trung vào các chức năng của hệ thống mà không để ý đến những khía cạnh nhu cầu người dùng.
Mô hình này còn giúp đội thiết kế và xây dựng hiểu được những trải nghiệm của người dùng. Giúp hệ thống được thiết kế thân thiện hơn, và khả dụng hơn trong quá trình áp dụng, triển khai hệ thống.
3.2 Áp dụng kỹ thuật tạo nguyên mẫu để đặc tả tương tác trong hệ thống
Hệ thống hỗ trợ giảng dạy theo mô hình vai mẫu áp dụng tại trường Đại học Sân khấu Điện ảnh Hà Nội được nhóm nghiên cứu và phát triển đề xuất xây dựng trên nền Web. Do đó, luận văn hướng đến việc áp dụng các kỹ thuật xây dựng mẫu nhanh đặc tả một số chức năng cơ bản của hệ thống trên nền Web sử dụng các kỹ thuật sau:
- Xây dựng các mẫu có độ trung thực thấp sử dụng bản phác thảo dùng công cụ Balsamiq
Mockups1, Wireframe Sketcher2.
- Xây dựng các mẫu có độ trung thực cao trên ngôn ngữ lập trình html (Hypertext Markup
Language)
3.3 Phân tích, đánh giá mẫu
Sau khi thiết kế các mẫu, nhóm nghiên cứu phát triển đề tài đã có các buổi trao đổi trực tiếp với người sử dụng gồm: Lãnh đạo Khoa Kịch hát dân tộc, các giáo viên trong khoa Khoa Kịch hát dân tộc và Sinh viên trường Đại học Sân khấu điện ảnh để ghi nhận những đánh giá của họ về các thiết kế của hệ thống có đáp ứng được nhu cầu của họ khi sử dụng.
3.3.1 Lập kế hoạch đánh giá mẫu
Quá trình tổ chức đánh giá mẫu được lập kế hoạch đánh giá các nguyên mẫu tại Trường Đại
học Sân khấu Điện ảnh như sau:
- Bước 1: Lựa chọn nhóm người dùng và các nhiệm vụ quan trọng nhất để kiểm tra gồm:
1 https://balsamiq.com/ 2 https://wireframesketcher.com/
25
+ Nhóm giảng viên với các chức năng xây dựng bài giảng, quản lý lớp học, khóa học, quản lý môn học, quản lý bài giảng.
+ Nhóm sinh viên với các chức năng xem bài giảng, tra cứu thông tin tham khảo, tra cứu thông tin nội dung đa phương tiện, xem các vở diễn video 2D, video 3D, chuyển các góc cảnh trong video 3D.
+ Cán bộ quản trị hệ thống với các chức năng quản trị hệ thống.
+ Cán bộ quản lý với các chức năng theo dõi tình hình xây dựng bài giảng, tổng hợp báo cáo, tình hình tham gia lớp học,....
- Bước 2: Chọn người dùng đại diện cho các nhóm người dùng. Gửi yêu cầu đề nghị đơn vị
thụ hưởng sắp xếp tổ chức buổi gặp và trao đổi với một số cán bộ, giáo viên, sinh viên trong khoa
- Bước 3: Xem xét việc sử dụng các tác vụ do người dùng định nghĩa, nơi người dùng được
yêu cầu xác định của họ trước kỳ thẩm định.
+ Liệt kê danh sách các chức năng cần người dùng định nghĩa.
+ Ghi rõ những yêu cầu cần thiết mà người dùng cần khi sử dụng các chức năng định
nghĩa.
- Bước 4: Tạo kịch bản các nhiệm vụ, nhập dữ liệu và viết hướng dẫn cho từng nhóm người
dùng như sau:
Bảng 3.4 Tạo kịch bản các nhiệm vụ đánh giá mẫu
Các kịch bản liên quan Nhóm người dùng
Giáo viên
Sinh viên
Cán bộ quản lý
Cán bộ quản trị hệ thống
- Chức năng tạo mới khóa học - Chức năng tạo mới môn học - Chức năng xây dựng bài giảng - Chức năng quản lý bài giảng... - Chức năng tra cứu thông tin tài liệu, video, nội dung đa phương tiện - Chức năng báo cáo thống kê… - Chức năng đăng ký vào các khóa học - Chức năng xem bài giảng - Chức năng tra cứu các tài liệu, video, nội dung đa phương tiện… - Chức năng xem các góc cảnh khác nhau trong vở diễn video 3D - Chức năng theo dõi tình hình xây dựng bài giảng - Chức năng báo cáo thống kê… - Chức năng xem danh sách các thành viên đăng nhập - Chức năng xem lịch sử đăng nhập hệ thống - Chức năng thêm mới người dùng - Chức năng phân quyền sử dụng
3.3.2 Tổ chức phiên đánh giá và kết quả các phiên đánh giá
Học viên và nhóm phát triển đã có những buổi chạy các phiên đánh giá, kết quả thu được là
các ý kiến đóng góp của người dùng về thiết kế, tương tác giữa người sử dụng và hệ thống. Các đóng góp chủ yếu xoay quanh các vấn đề người dùng muốn hệ thống càng dễ sử dụng càng tốt, các chức năng cần ít các thao tác để đơn giản cách sử dụng ví dụ như các chức năng hỗ trợ việc kéo thả, hạn chế dùng các câu từ gây khó hiểu, chú ý đến tính nhất quán của giao diện tương tác,...
26
Tất cả các ý kiến đóng góp của người dùng trong các phiên đánh giá được ghi lại và là cơ sở
tiến hóa, sửa đổi và nâng cấp các nguyên mẫu thiết kế trong quá trình tiếp theo.
Bên cạnh việc tổ chức các phiên đánh giá với người sử dụng, hệ thống còn được đánh giá bởi
các chuyên gia về thiết kế tương tác người máy.
Học viên đã xây dựng bảng các tiêu chí đánh giá nguyên mẫu, lấy ý kiến các chuyên gia về
tương tác người máy, người sử dụng là giảng viên và sinh viên trường Đại học Sân khấu Điện Ảnh Hà Nội.
Bảng 3.5 Những góp ý, và kết quả đánh giá mẫu
Góp ý Mẫu chức năng
Kết quả đánh giá Đạt yêu cầu Đạt yêu cầu Tạo mới khóa học Tạo mới môn học
Đạt yêu cầu Xây dựng bài giảng
Đạt yêu cầu
Đạt yêu cầu Nên có chức năng chọn nội dung đa phương tiện ở màn hình Xây dựng bài giảng Không nên để tên mặc định của hệ thống đối với các thành phần trên giao diện
Đạt yêu cầu
Đạt yêu cầu Quản lý bài giảng Quản lý nội dung đa phương tiện (video 2D, 3D, ảnh) Đăng ký vào các khóa học Đạt yêu cầu Xem bài giảng Đạt yêu cầu Tra cứu các tài liệu, video, nội dung đa phương tiện… Theo dõi tình hình xây dựng bài giảng
Đạt yêu cầu Đạt yêu cầu Đạt yêu cầu Đạt yêu cầu Đạt yêu cầu Đạt yêu cầu Báo cáo thống kê Quản lý người dùng Quản lý hệ thống Quản lý quyền Đăng nhập Đăng ký tài khoản
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
Về việc tổ chức các buổi đánh giá mẫu: Không dễ để có thể tập hợp bố trí được số lượng
người tham gia đánh giá mẫu cùng một thời điểm. Tôi đề xuất việc tổ chức các buổi đánh giá sẽ hợp lý hơn nếu như chia nhỏ phiên đánh giá thành các buổi đánh giá khác nhau, theo nhóm người sử dụng để việc thu thập ý kiến đánh giá được tập trung và hiệu quả. Có thể chia ra các nhóm đánh giá khác nhau, trong mỗi nhóm cần ít nhất một người của nhóm thiết kế với các kịch bản nhiệm vụ và hướng dẫn đã xây dựng trong giai đoạn lập kế hoạch đánh giá.
Trong quá trình đánh giá, những chức năng, nội dung dẫn đến việc người dùng hiểu nhầm vấn đề cần được chỉnh sửa luôn để tránh những giải thích dài, tránh những tranh luận gay gắt và mất thời gian, gây căng thẳng cho buổi đánh giá.
Trong kỹ thuật đánh giá có nhắc đến việc chỉ để người dùng thao tác, sau đó quan sát họ và ghi lại những khó khăn khi sử dụng người dùng gặp phải, tuy nhiên trong một số trường hợp cần hướng dẫn người dùng bắt đầu như thế nào. Với độ tuổi của giảng viên không đồng đều, và kỹ năng sử
27
dụng máy tính còn hạn chế thì việc hướng dẫn người dùng ngay từ khi bắt đầu phiên đánh giá là cần thiết và sau đó mới quan sát họ thao tác và ghi nhận ý kiến của họ.
Nên tạo những nguyên mẫu có khả năng tái sử dụng để giảm thời gian xây dựng mẫu và chi
phí xây dựng mẫu, dễ hướng dẫn sử dụng, đồng nhất về mặt thiết kế mẫu
3.4 Nghiên cứu, xây dựng hệ thống
3.4.1 Phân tích thiết kế
Lược đồ các trường hợp sử dụng theo ngôn ngữ UML
Hình 3.1 Lược đồ các Use Case hệ thống
Lược đồ hoạt động chức năng thêm mới video 3D
28
Hình 3.2 Lược đồ hoạt động thêm mới nội dung 3D
Hình 3.3 Lược đồ hoạt động thêm mới nội dung video 2D
29
Hình 3.4 Lược đồ hoạt động thêm mới nội dung đa phương tiện, hình ảnh
Hình 3.5 Lược đồ hoạt động tra cứu, xem nội dung đa phương tiện
30
Hình 3.6 Lược đồ hoạt động xây dựng bài giảng
Lược đồ lớp
Hình 3.7 Lược đồ lớp
31
Mô hình cơ sở dữ liệu
Hình 3.8 Lược đồ quan hệ giữa các bảng cơ sở dữ liệu
3.4.2 Xây dựng hệ thống
Từ những nguyên mẫu đã được xây dựng và đánh giá, học viên tiến hành xây dựng hệ thống.
Học viên lựa chọn công nghệ phát triển hệ thống ứng dụng trên nền tảng web, dùng ngôn ngữ lập trình C# .Net Framework, sử dụng cơ sở dữ liệu SQL Server để lưu trữ dữ liệu, sử dụng các thư viện Java Script cụ thể ở đây là thư viện Three.js để xử lý và biểu diễn dữ liệu 3D lên trình duyệt web, giao diện hệ thống sử dụng Bootstrap v3.3.2,…
Hệ thống hỗ trợ giảng dạy này được xây dựng có đặc điểm khác biệt so với những hệ thống
khác ở đặc điểm như: với các hệ thống khác thì mới chỉ dừng ở mức cho phép người dùng nhúng nội dung video 3D từ một hệ thống khác vào bài giảng. Còn đối hệ thống hỗ trợ giảng dạy này được xây dựng cung cấp chức năng cho phép người dùng chủ động quản lý được thư viện nội dung video 3D, cho phép nhúng các video 3D từ thư viện vào bài giảng, chức năng so sánh giữa các video 3D cùng vai diễn nhưng khác người diễn, chức năng so sánh giữa vai diễn trong video 2D với video 3D, các tiện ích xem – dừng – tua – đổi góc nhìn khi xem vở diễn video 3D, đặc biệt là chức năng hỗ trợ biên tập nội dung 3D (đóng gói dữ liệu từ các video 3D khác nhau kết hợp với nhạc nền thành một vở diễn và biểu diễn đồng thời các video 3D đó tại cùng thời điểm trên nền web). Tôi sẽ nói rõ hơn về ý tưởng và cách xử lý trong nội dung trình bày tiếp theo.
Trong quá trình xây dựng hệ thống, mục tiêu của hệ thống là sẽ ứng dụng được công nghệ đa phương tiện đặc biệt là công nghệ 3D vào giảng dạy, vì vậy nội dung 3D sẽ là một phần của hệ thống. Tuy nhiên việc thu thập và biên tập dữ liệu video 3D là quá trình tốn nhiều thời gian và công sức. Để hiểu rõ hơn về việc biên tập dữ liệu video 3D, tôi xin phác thảo tóm tắt quy trình xây dựng một video 3D vai mẫu.
Bước 1: Thu thập dữ liệu, trích xuất chuyển động của khung xương bằng các thiết bị như
sence, kinec.
32
Đầu vào của bước này là diễn viên mặc bộ trang phục có gắn các cảm biến, có kết nối với máy
tính. Khi diễn viên chuyển động thì cảm biển sẽ gửi các chuyển
động của diễn viên về máy tính. Đầu ra của bước này là tệp tin dữ liệu khung xương chuyển động với
định dạng .bvh, các hình ảnh diễn viên thực tế cùng trang phục, tệp tin dữ liệu âm thanh của quá trình ghi, hình ảnh sân khấu
Bước 2: Sử dụng Human Maker để dựng mô hình người, ở bước này có thể sử dụng những
mô hình người có sẵn. Đầu ra của bước này là mô hình người với định dạng .obj
Bước 3: Xây dựng sân khấu, ở bước này dùng các hình ảnh sân khẩu đã thu thập được ở bước
1 và các hình ảnh sân khấu thực tế tham khảo để dựng lên cảnh sân khấu 3D
Bước 4: Sử dụng Blender gắn mô hình người tạo ở bước 2 vào khung xương chuyển động thu
được ở bước 1, kết hợp dựng trang phục theo nhân vật cùng với các kỹ thuật phủ da cho mô hình người – (skinning), chỉnh sửa – (modifies), chuyển động vật lý – (physics simulations), để mô hình người và trang phục của nhân vật chuyển động theo khung xương. Kết quả của bước 4 là xuất được ra mô hình vai mẫu 3D chuyển động
Bước 5: Ghép mô hình vai mẫu 3D chuyển động ở bước 4 với sân khấu 3D xây dựng ở bước
3. Kết quả của bước này là xuất ra được vở diễn 3D với định dạng .glb
Khi theo dõi quy trình biên tập nội dung video 3D tôi thấy vấn đề hạn chế ở quy trình này đó là sẽ rất mất thời gian cho việc dựng video 3D, câu hỏi đặt ra là làm thế nào để tiết kiệm được thời gian của người biên tập nội dung, tái sử dụng được các đoạn video 3D đã xây dựng, chuyên biệt hóa từng công đoạn, hệ thống xây dựng lên sẽ giải quyết và hỗ trợ được vấn đề gì cho người biên tập nội dung video 3D?
Ý tưởng chia nhỏ công đọan dựng video 3D thành các cảnh khác nhau, tách các nội dung ra làm các cảnh trong đó mỗi người biên tập nội dung sẽ phụ trách làm một cảnh khác nhau, kết hợp với xử lý nhạc nền của cảnh diễn. Ví dụ: một người làm cảnh sân khấu, những người khác sẽ phân chia việc dựng các nhân vật trong vở diễn, và kết quả cuối cùng là các cảnh diễn 3D của mỗi người sẽ được tải lên hệ thống hỗ trợ giảng dạy, hệ thống sẽ ghép các cảnh diễn lại và biểu diễn thành một video 3D trên nền web. Việc này sẽ giải quyết được vấn đề như giúp tiết kiệm được thời gian xây dựng nội dung 3D, giúp tái sử dụng được các cảnh.
Từ ý tưởng trên, tôi nghiên cứu cách làm sao để hệ thống có thể thực hiện được ý tưởng đó, thể hiện cùng một lúc nhiều đoạn diễn video 3D trên nền web. Qua tìm hiểu tôi thấy hầu như các hệ thống và thư viện hiện tại chỉ hỗ trợ biểu diễn được một tệp tin dữ liệu 3D định dạng .glb tại một thời điểm (giống như khi chúng ta mở một tệp tin video trên chương trình chơi nhạc Windows media player), chưa có hệ thống nào cho phép mở đồng thời nhiều tệp tin video 3D.
Để thực hiện được ý tưởng của hệ thống, tôi cần xử lý việc tổng hợp, đóng gói thông tin của
vở diễn và biểu diễn tất cả các cảnh video 3D đó cùng một thời điểm. Đầu tiên tôi nghiên cứu xây dựng chức năng upload tệp tin, chức năng này cho phép khi người dùng upload tệp tin lên hệ thống, hệ thống sẽ tự động phân tích và phân loại kiểu dữ liệu là dữ liệu âm thanh hay dữ liệu các cảnh video 3D - dữ liệu âm thanh ở đây là tệp tin nhạc và tiếng hát của người diễn viên đã được thu lại ở bước 1 trong quy trình xây dựng nội dung video 3D, sau đó đóng gói các thông tin đó lại thành một tệp tin lưu trữ trên máy chủ đồng thời lưu trong cơ sở dữ liệu.
33
Chức năng này hoạt động và xử lý dữ liệu theo luồng sau: khi người dùng nhập các thông tin
mô tả như tiêu đề của vở diễn, chọn các tệp dữ liệu của vở diễn (dữ liệu hình ảnh, dữ liệu âm thanh, dữ liệu các cảnh diễn 3D kết quả của quy trình biên tập nội dung video 3D) và chọn lưu, hệ thống sẽ phân tích dữ liệu đầu vào các tệp được chọn có kiểu dữ liệu gì, sau đó tải các tệp tin đó lên thư mục lưu trữ trên máy chủ đồng thời ghi và đóng gói lại thông tin (tên tệp tin, vị trí lưu tệp tin) của các tệp tin đó vào một tệp tin dưới dạng json, tệp tin này sẽ đồng thời được tải lên thư mục lưu trữ trên máy chủ và hệ thống lưu tên tệp tin vào cơ sở dữ liệu, tệp tin json có cấu trúc như sau:
{
"bgm": "
Ví dụ:
{ "bgm": "files/3d/suyvan/suyvan.mp3", "gltf": ["files/3d/suyvan/scene.glb","files/3d/suyvan/scene1.glb"]
}
Trong đó:
bgm: tham số truyền vào là đường dẫn đến tệp tin nhạc nền
gltf: tham số truyền vào là đường dẫn đến các tệp tin video 3D
* : thể hiện là tham số đường dẫn có thể nhiều hơn 1 tệp tin
Sau khi tải dữ liệu lên hệ thống thành công, cấu trúc lưu trữ các tệp tin video 3D được lưu như
cây thư mục dưới đây.
Bước tiếp theo là cách biểu diễn các tệp tin cảnh video 3D đã được đóng gói đó ra nền web cùng một thời điểm.
Chức năng này hoạt động và xử lý dữ liệu theo luồng sau: khi người dùng chọn xem video 3D từ thư viện video 3D, hệ thống sẽ lấy thông tin video 3D mà người dùng chọn từ cơ sở dữ liệu, và đưa thông tin tệp tin đã đóng gói vào đoạn script.
Trong đó:
clip: là khai báo mới đối tượng video 3D
h3rURL : là đường dẫn đến tệp tin đóng gói trong chức năng upload tệp tin video
3D
prog: là quá tiến trình mà hệ thống tải các tệp tin lên
Hệ thống sử dụng thư viện Three.js và các hàm mở rộng để biểu diễn tất cả các cảnh trong tệp tin json đã đóng gói. Tệp tin json sẽ được đọc để lấy ra các thông tin của tệp tin nhạc, video 3D sau đó hàm mở rộng sẽ nối chúng vào thành một video 3D đầy đủ và biểu diễn lên trình duyệt web.
Với các chức năng trên, hệ thống đã hiện thực hóa được ý tưởng tổng hợp các cảnh diễn vào một vở diễn và thể hiện cùng lúc các cảnh diễn, giúp giảm được thời gian biên tập nội dung 3D, giúp tái sử dụng được các cảnh diễn.
Ngoài các chức năng hỗ trợ việc biên tập nội dung và biểu diễn cùng lúc nhiều nội dung 3D trên nền web, hệ thống cũng đã cung cấp các chức năng biên soạn bài giảng có hỗ trợ việc nhúng nội dung đa phương tiện và nội dung video 3D vào bài giảng, chức năng biên tập nội dung bài giảng có so sánh giữa các vai diễn trong video 3D với video 3D và giữa video 2D với video 3D, chức năng xem nội dung bài giảng,… dưới đây là một số hình ảnh chụp từ hệ thống.
3.5 Kết chương
Trong chương này, học viên đã áp dụng mô hình thiết kế lấy người dùng làm trung tâm (User Center System Design – UCSD), kỹ thuật tạo mẫu nhanh (Rapid Prototying) trong quá trình 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. Các mẫu thiết kế được xây dựng dựa trên hai mức độ là mẫu thiết kế có độ trung thực thấp và mẫu thiết kế có độ trung thực cao. Từ những mẫu đã xây dựng được, học viên đã tiến hành lên kế hoạch đánh giá các mẫu từ đó rút ra được những hạn chế và đề xuất các cải tiến phù hợp trong quá trình phát triển phần mềm sử dụng kỹ thuật tạo mẫu nhanh. Hệ thống được xây dựng dựa trên những mẫu đã xây dựng.
Học viên cũng đã nghiên cứu công nghệ để xây dựng hệ thống ứng dụng được công nghệ đa phương tiện. Các chức năng hỗ trợ quá trình biên tập nội dung video 3D, giúp tiết kiệm được thời gian 35
xây dựng nội dung video 3D, giúp tái sử dụng được các cảnh diễn 3D. Hỗ trợ giảng viên như các chức
năng hỗ trợ việc xây dựng bài giảng, cho phép tìm kiếm và nhúng nội dung đa phương tiện từ thư viện đa phương tiện, cho phép xây dựng nội dung bài giảng có tính chất so sánh. Đối với người học, hệ thống cho phép xem các vở diễn vai mẫu ở nhiều góc cảnh khác nhau, cho phép chơi – dừng – tua video 3D.
KẾT LUẬN
1. Những kết quả chính của luận văn
Luận văn cung cấp một cái nhìn tổng thể về các yếu tố trong qui trình phát triển phần mềm ảnh hưởng đến chất lượng phần mềm và khả năng đáp ứng mong muốn của khách hàng. Mỗi qui trình phát triển phần mềm đều có những ưu điểm và nhược điểm riêng, do đó cần phải phân tích hệ thống chi tiết trước khi lựa chọn qui trình xây dựng để có được sản phẩm phần mềm có chất lượng, thoả mãn mong muốn của khách hàng và đảm bảo tiến độ thực hiện.
Tìm hiểu, phân tích, so sánh, đánh giá ưu, nhược điểm của các kỹ thuật xây dựng mẫu trong
thiết kế một hệ thống phần mềm với các tiêu chí đánh giá.
Áp dụng mô hình thiết kế lấy người dùng làm trung tâm, kỹ thuật tạo mẫu nhanh trong 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. Các mẫu thiết kế được xây dựng dựa trên hai mức độ là mẫu thiết kế có độ trung thực thấp và mẫu thiết kế có độ trung thực cao. Từ những mẫu đã xây dựng được, học viên đã tiến hành lên kế hoạch đánh giá các mẫu từ đó rút ra được những hạn chế và đề xuất các cải tiến phù hợp trong quá trình phát triển phần mềm sử dụng kỹ thuật tạo mẫu nhanh.
Nghiên cứu công nghệ và xây dựng hệ thống ứng dụng được nội dung đa phương tiện (văn bản, hình ảnh, âm thanh, video 2D, video 3D) hỗ trợ vào việc giảng dạy, hỗ trợ cán bộ biên tập nội dung đa phương tiên, hỗ trợ giáo viên xây dựng bài giảng, hỗ trợ người học xem và học các vai mẫu video 3D.
2. Hướng phát triển của luận văn
Tiếp tục hoàn thiện qui trình tổ chức đánh giá các mẫu, xây dựng được mô hình kết hợp đánh giá mẫu giữa người dùng với người phát triển hệ thống để có thể nắm bắt, phản ánh tốt nhất những yêu cầu đối với từng mẫu.
Xây dựng được các khuyến nghị về các công cụ xây dựng các mẫu thiết kế với các mức độ
trung thực khác nhau dễ sử dụng, dễ thiết kế, dễ vận hành và dễ tương tác.
Xây dựng bổ sung được các chức năng tiện ích trên hệ thống hỗ trợ người dùng.
36
[1] Bùi Thế Duy (2005). Bài giảng môn “Tương tác người máy”
[2] Ngô Thị Duyên. Bài giảng môn “Thiết kế giao diện người dùng”
TÀI LIỆU THAM KHẢO Tiếng Việt
[3] Ghezzi, C., Jazayeri, M., & Mandrioli, D. (2002). Fundamentals of software engineering.
Tiếng Anh
[4] Tavolato, P., & Vincena, K. (1984). A prototyping methodology and its tool.
Prentice Hall PTR.
In Approaches to prototyping (pp. 434-446). Springer, Berlin, Heidelberg.
[5] Carr, M., & Verner,
(1997). Prototyping and J.
[6] Morris, D. (Ed.). (2013). Concise encyclopedia of software engineering (Vol. 1).
software development approaches. Department of Information Systems, City University of Hong Kong, Hong Kong, 319-338.
[7] Seffah, A., Gulliksen, J., & Desmarais, M. C. (Eds.). (2005). Human-centered software engineering-integrating usability in the software development lifecycle (Vol. 8). Springer Science & Business Media.
[8] Rome, N. Y. (1992). Software Prototyping and Requirements Engineering.
[9] Landay, J. A., & Myers, B. A. (1995, May). Interactive sketching for the early stages of user interface design. In Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 43-50). ACM Press/Addison-Wesley Publishing Co.
[10] Dix, A. (2009). Human-computer interaction. In Encyclopedia of database systems (pp.
Elsevier.
[11] Rising, L., & Janoff, N. S. (2000). The Scrum software development process for small
1327-1331). Springer, Boston, MA.
[12] Cockburn, A. (2002). Agile software development (Vol. 177). Boston: Addison-Wesley.
teams. IEEE software, 17(4), 26-32.
