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

pháp cũng đưa ra các biểu đồ được nhóm sử dụng tạm thời trong các cuộc họp, các buổi hội thảo nội bộ (TEMPS). Việc áp dụng phương pháp mô hình hoá không chỉ giúp cho quá trình phân tích vấn đề trở nên rõ ràng và có tính hệ thống mà còn quan trọng hơn khi nhóm phát triển cần phân chia thành nhiều nhóm phụ hoặc trong trường hợp có thay đổi về nhân sự trong nhóm. 55 Chương 3. Phương pháp thu thập yêu cầu 3.1. Tiếp cận các bên liên quan Chủ sản phẩm (Product Owner) cần kết hợp chặt chẽ với các Bên liên quan nhằm đảm bảo sản phẩm có trải nghiệm người dùng tốt (UX) với các tính năng phù hợp. Điều đầu tiên PO cần xác định đúng các Bên liên quan và có chiến lược cụ thể khi làm việc với họ. Tôi đề xuất sử dụng Lưới Tầm ảnh hưởng-Độ quan tâm (Power-Interest Grid), bảng này chia các bên liên quan thành các nhóm và tương ứng với mỗi nhóm PO sẽ có các cách tiếp cận tương ứng. 3.1.1. Xác định các bên liên quan Scrum định nghĩa của các bên liên quan như sau: Các bên liên quan là tất cả các bên quan tâm tới dự án, không bao gồm: Chủ sản phẩm (Product Owner), nhóm phát triển và Scrum Master. Như vậy ở hình dưới đây thì Senior Management, Marketing and Sales là các thành viên nội bộ nhưng cũng có thể là các bên liên quan. Hình 21: Vai trò trung tâm của chủ sản phẩm đối với các bên liên quan và nhóm phát triển Để xác định các bên liên quan, người phân tích cần liệt kê tất cả những người có thể hỗ trợ họ trong quá trình phát triển, phát hành và chuyển giao sản phẩm. Như vậy các bên liên quan trong dự án Hệ thống phần mềm Giảng dạy Kịch hát dân tộc Trường Đại học Sân khấu Điện ảnh bao gồm: 56 1. Ban lãnh đạo nhà trường ĐH Sân khấu Điện ảnh 2. Cán bộ quản lý khoa Kịch hát dân tộc – ĐH Sân khấu Điện ảnh 3. Giảng viên 4. Sinh viên 5. Hội đồng Khoa học và Công nghệ 6. Cán bộ Phòng CNTT trường ĐH Sân khấu Điện ảnh 7. Đại diện đơn vị cung cấp nội dung 8. Người dùng ẩn danh 3.1.2. Phân tích các bên liên quan Khi đã xác định được các bên liên quan, chúng tôi thực hiện các bước phân tích họ để xác định cách làm việc với họ như thế nào. Đây là nỗ lực của Product Owner nhằm thu hút sự quan tâm và dành lấy thời gian của các bên liên quan. Một kỹ thuật phân tích các bên liên quan phổ biến là Lưới Tầm ảnh hưởng-Độ quan tâm (Power-Interest Grid) nhằm đánh giá các bên liên quan bằng cách tính đến tầm ảnh hưởng và sự quan tâm của họ tới dự án. Một bên liên quan thường quan tâm đến sản phẩm nếu sản phẩm đó ảnh hưởng đến cá nhân họ. Người có tầm ảnh hưởng cao nếu người đó có thể ảnh hưởng đến quyết định sản phẩm hoặc tính năng sản phẩm. Bảng 2: Lưới Tầm ảnh hưởng-Độ quan tâm (Power-Interest Grid) lý thuyết Mỗi nhóm bên liên quan ở bảng trên đòi hỏi mức độ tham gia khác nhau như giải thích sau. 57 3.1.3. Cộng tác với các Player Player là bên liên quan có tầm ảnh hưởng lớn và độ quan tâm cao tới dự án. Những cá nhân này là đối tác quan trọng đối với các Product Owner. Do đó, PO nên cộng tác chặt chẽ với họ, bằng cách mời họ tham gia các buổi họp chiến lược sản phẩm (Product Strategy) và các hội thảo lộ trình (Roadmaping Workshop) và các cuộc họp đánh giá Sprint (Sprint Review Meeting). Mục đích để duy trì sự quan tâm về sản phẩm trong suy nghĩ của họ, tận dụng những ý tưởng và kiến thức của họ và thiết lập một mối quan hệ chặt chẽ và tạo dựng sự tin tưởng với họ. Ngoài ra Player có tầm ảnh hưởng lớn vì vậy việc đồng bộ về mặt thông tin với các cá nhân này vô hình cũng giúp duy trì tính đồng bộ đối với các bên liên quan khác. Cũng cần nhớ rằng sự hợp tác này đòi hỏi khả năng lãnh đạo vì vậy PO cần cởi mở và hợp tác nhưng cũng phải ra quyết định cùng lúc. Mục tiêu xây dựng sự đồng thuận với các Player nhưng cũng không ngại từ chối. Không cố gắng làm vừa lòng tất cả các bên mà cần can đảm để đưa ra quyết định nếu không có thỏa thuận nào có thể đạt được. 3.1.4. Thu hút sự quan tâm các Subject Subject là những cá nhân có độ quan tâm cao nhưng có ít tầm ảnh hưởng. Họ cảm thấy bị ảnh hưởng bởi sản phẩm và muốn gây ảnh hưởng đến sản phẩm nhưng họ không thể phủ quyết hoặc thay đổi quyết định về sản phẩm. Các Subject có thể là các đồng minh tuyệt vời, họ có thể giúp Product Owner nâng cao sự hiểu biết và tính cạnh tranh cho sản phẩm của bạn. PO cần duy trì vai trò và mối quan tâm của họ thường xuyên, ví dụ bằng cách mời họ tham gia các Sprint Review Meeting và khuyến khích họ chia sẻ phản hồi của họ. Nhưng đừng mắc lỗi khi nói "Đồng ý" với mọi ý tưởng và đề nghị các Subject nêu lên. Sử dụng Product Strategy và Product Roadmap để đánh giá liệu một ý tưởng có hữu ích hay không. 3.1.5. Thao khảo ý kiến của các Context Setter hay Referee Những người có sự quan tâm thấp nhưng có quyền lực cao được gọi là những Context Setter hay Referee. Họ ảnh hưởng đến bối cảnh của sản phẩm nhưng họ ít quan tâm đến sản phẩm. Đảm bảo rằng Context Setter cảm thấy rằng quan điểm, mối quan tâm và ý tưởng của họ được lắng nghe và hiểu. Thường xuyên tham khảo ý kiến của họ, ví dụ, bằng cách mở cuộc họp riêng. Điều này đảm bảo rằng những ý tưởng và mối quan tâm của họ được lắng nghe và nó giúp tránh những bất đồng sau này. Đừng để Context Setter bối rối và không cho 58 phép họ ra quyết định. Hãy mạnh mẽ, can đảm để nói không ngay cả khi phải đối mặt với một bên liên quan đầy quyền lực. 3.1.6. Thông báo thông tin tới Crowd Crowd là các bên liên quan với sự quan tâm thấp và quyền lực thấp. Vì họ không quan tâm đến sản phẩm của bạn và không có khả năng ảnh hưởng đến quyết định của sản phẩm nên thông thường cần phải thông báo thông tin dự án cho các cá nhân này bằng cách cho phép họ truy cập vào trang web wiki của sản phẩm hoặc cập nhật những bước phát triển quan trọng dưới hình thức của một bản tin, bài báo. 3.1.7. Lưới Tầm ảnh hưởng-Độ quan tâm (Power-Interest Grid) Bảng 3: Lưới Tầm ảnh hưởng-Độ quan tâm (Power-Interest Grid) của dự án Nhóm Tên bên liên quan Mức độ tương tác Tần suất tương tác Kỹ thuật tương tác Players Cán bộ quản lý khoa Kịch hát dân tộc – ĐH Sân khấu Điện ảnh Giảng viên Cộng tác (Collaborate) Once per sprint Collaborative workshops bao gồm: Strategy và Roadmap workshops, sprint review meetings Subjects Sinh viên Người dùng ẩn danh Thu hút sự quan tâm (Involve) Monthly Sprint review meetings Context Setters Ban lãnh đạo nhà trường ĐH Sân khấu Điện ảnh Hội đồng Khoa học và Công nghệ Tham khảo (Consult) Quarterly Gặp riêng (One-on- one meetings) Crowd Phòng CNTT trường ĐH Sân khấu Điện ảnh Thông báo (Inform) Quarterly Newsletter 59 3.2. Bộ câu hỏi phỏng vấn các bên liên quan (Q&A) Các câu hỏi (Question – Q) được đặt ra bởi tôi, đứng trên vai trò là một Chủ sản phẩm (Product Owner). Các câu trả lời (Answer – A) được ghi nhận từ đại diện các bên liên quan tương ứng với từng tiểu mục ở Phụ lục I. Bộ câu hỏi phỏng vấn các bên liên quan (Q&A). 3.3. Xây dựng User Story, Product Backlog 3.3.1. Xây dựng các Epic Epic là những User Story lớn ở mức thô với độ ưu tiên thấp. Chúng quá lớn để thực hiện trong một bước lặp (Increment) duy nhất và do đó chúng cần phải được tổng hợp thành các User Story nhỏ hơn. 3.3.1.1. Form mẫu dùng để ghi các Epic như sau 60 3.3.1.2. Danh sách các Epic Nội dung các Epic được liệt kê chi tiết tại Phụ lục II. Danh sách các Epic 3.3.2. Xây dựng các User Story 3.3.2.1. Phân nhóm các người dùng cùng User Story “Người dùng” bao gồm: 1. Người dùng ẩn danh (Anonymous User) 2. Người dùng đã xác thực (Authorized User) a. Sinh viên b. Giảng viên c. Cán bộ Phòng CNTT trường ĐH Sân khấu Điện ảnh 61 3.3.2.2. Danh sách các User Story Nội dung các User Story được liệt kê chi tiết tại Phụ lục III. Danh sách các User Story 3.3.3. Scrum Taskboard: SPRINT_2017_03_03 62 3.3.4. Bảng Kanban 3.4. Tóm lược Chương này tôi trình bày việc xác định các bên liên quan tham gia trực tiếp hay gián tiếp tới hệ thống và chia thành các nhóm với các cách tiếp cận khác nhau. Ở bước đầu của quá trình phân tích, tôi cùng nhóm nghiên cứu và phát triển dự án xây dựng bộ câu hỏi phỏng vấn các bên liên quan nhằm thu được cái nhìn tổng quan hay "Big Picture" về yêu cầu của dự án. Từ các buổi nói chuyện nhằm thu nhận các câu trả lời từ các bên liên quan, chúng tôi đã xây dựng được Product Backlog là đầu vào cho các Sprint đầu tiên. Qua mỗi Sprint, Product Backlog được làm mịn và chuyển hóa thành các User Story bao gồm các đầu việc (task) và các tiêu chí chấp nhận (acceptance criteria). Tất cả các đơn vị yêu cầu này đều được quản lý và thể hiện qua Scrum Taskboard nhằm phục vụ nhóm phát triển xây dựng mã nguồn và các đơn vị kiểm thử tương ứng. 63 Chương 4. Phân tích & Thiết kế Hệ thống 4.1. Phân tích hệ thống 4.1.1. Mô tả quy trình nghiệp vụ Quy trình nghiệp vụ chính mà hệ thống được xây dựng để hỗ trợ bao gồm: 1. Quá trình giảng dạy kịch hát dân tộc tại Trường Đại học Sân khấu Điện ảnh HN. 2. Quá trình học tập các loại hình kịch hát dân tộc của sinh viên tại trường. 3. Quá trình tìm kiếm thông tin của những người có quan tâm tới các nội dung dữ liệu đa phương tiện về kịch hát dân tộc. Trong đó bộ môn kịch hát dân tộc bao gồm các tập quán, các hình thức thể hiện, biểu đạt, tri thức, kỹ năng và kèm theo đó là những công cụ, đồ vật, đồ tạp tác và các không gian văn hóa có liên quan mà cộng đồng, các nhóm và trong một số trường hợp là các cá nhân công nhận và xem đó là loại hình văn hóa kịch hát dân tộc. Trong đó Giảng viên là người xây dựng nội dung bài giảng bộ môn kịch hát dân tộc và là người trực tiếp giảng dạy sinh viên tại lớp bằng các phương pháp như: 1. Giảng dạy lý thuyết thông qua nội dung văn bản, nội dung âm thanh, hình ảnh qua các đoạn phim được ghi lại. 2. Giảng dạy thực hành bằng cách biểu diễn diễn mẫu, truyền nghề. 3. Là người đánh giá, chấm điểm sinh viên trong quá trình học môn học. Trong đó Sinh viên là người tiếp thu, thực hành các kiến thức, kỹ năng từ giảng viên bộ môn Kịch hát dân tộc truyền đạt. 4.1.2. Đề xuất quy trình tin học hóa Qua quá trình làm việc với bên thụ hưởng phần mềm là Trường Đại học Sân khấu Điện ảnh Hà Nội, nhóm nghiên cứu thực hiện đề tài khoa học công nghệ đã đề xuất kiến trúc phần mềm nền web được cài đặt trên một hệ thống phân tán bao gồm các chức năng chính sau: 64 4.1.2.1. Chức năng phần mềm chính Chức năng xem một vở diễn ở dạng video 2D Khi chọn chức năng xem một vở diễn ở dạng video 2D, người sử dụng được cung cấp các tiện ích sau: Xem đồng thời video mẫu khác nhau của cùng vở diễn đã chọn: Với tiện ích này, phần mềm sẽ hiển thị đồng thời các video mẫu khác nhau của cùng một vở diễn, cho phép so sánh giữa các người diễn. Xem một vở diễn đồng thời từ các góc quay khác nhau: Với tiện ích này, phần mềm sẽ hiển thị đồng thời các video từ các góc quay khác nhau của cùng một “vai mẫu”. Tiện ích này giúp cho người sử dụng quan sát được người diễn ở các góc nhìn khác nhau, từ đó có được thông tin đầy đủ hơn về “cách diễn” của người đó. Chức năng tìm kiếm trong thư viện video Khi chọn chức năng tìm kiếm trong thư viện video, người sử dụng được cung cấp tiện ích tìm kiếm video theo từ khóa: 1. Người sử dụng nhập từ khóa liên quan đến video cần tìm 2. Phần mềm sẽ hiển thị danh sách các video dựa trên từ khóa nhận được 3. Người sử dụng có thể chọn video muốn xem trong danh sách các video tìm được dựa trên từ khóa được cung cấp. Chức năng lọc, phân loại theo vở diễn, theo diễn viên, theo động tác cơ bản 1. Người sử dụng chọn tiêu chí lọc, phân loại video (theo vở diễn, theo diễn viên, hay theo loại hình động tác cơ bản) 2. Phần mềm sẽ hiển thị danh sách các video dựa trên tùy chọn của người sử dụng 3. Từ danh sách các video được hiển thị, người sử dụng có thể chọn xem một video cụ thể nếu muốn. Chức năng xem vở diễn ở dạng video 3D Phần mềm cung cấp chức năng cho phép người sử dụng chọn xem một vở diễn ở dạng video 3D. Với chức năng này, người sử dụng có thể xem một vở diễn trong không gian ba chiều và có thể chọn xem vở diễn ở các góc nhìn khác nhau. 65 Chức năng xây dựng bài giảng điện tử Khi sử dụng chức năng này, người dùng có thể xây dựng bài giảng điện tử có nội dung đa phương tiện gồm phần chữ (text), hình ảnh, âm thanh. Phần mềm cung cấp các chức năng: 1. Người dùng có thể đưa văn bản vào bài giảng 2. Người dùng có thể chèn dữ liệu video (2D, 3D) vào bài giảng 3. Người dùng có thể thêm, sửa, xóa dữ liệu video, 3D, văn bản vào các bài giảng đã được xây dựng 4.1.2.2. Chức năng phần cứng chính Hệ thống phần mềm được cài đặt trên môi trường phân tán đề xuất bao gồm:  1 máy chủ web Apache Tomcat 9  1 máy chủ cơ sở dữ liệu chạy HĐH Linux, Hệ QT CSDL PostgreSQL  1 máy chủ lưu trữ tập tin FTP File Storage chạy HĐH Linux  Tại các lớp học được trang bị: 1 Desktop Computer hoặc Laptop; 1 Máy chiếu Projector; Hệ thống loa âm thanh 4.2. Các yêu cầu của phần mềm 4.2.1. Định nghĩa các thuật ngữ Nội dung Ý nghĩa Bài giảng Mỗi môn học các các bài giảng tương ứng của các Giảng viên biên soạn bao gồm tập hợp các Nội dung Đa phương tiện được thiết kế để truyền tải tới Học viên. Cấu trúc bài giảng Cấu trúc chương trình học của Môn học của Giảng viên tương ứng. Đăng ký Nội dung 3D chuyển động Đăng ký Nội dung 3D chuyển động Đơn vị cung cấp nội dung Là các đơn vị như Bộ Văn hóa, Thể thao và Du lịch, và các cơ quan liên quan, các đơn vị này cung cấp kho tư liệu về văn hóa phi vật thể được sử dụng làm nội dung chính của hệ thống. 66 Giảng viên Là người biên soạn nội dung Bài giảng, theo dõi việc học của các Học viên. Học viên Là người sử dụng theo dõi các Bài giảng, các Nội dung Đa phương tiện cũng như Nội dung 3D chuyển động trên hệ thống. Loại hình Nghệ thuật biểu diễn Là các hình thức nghệ thuật: Nghệ thuật biểu diễn sử dụng cơ thể, tiếng nói và sự có mặt của chính nghệ sĩ làm phương tiện trình diễn trước công chúng. Môn học Là môn học của một Loại hình Văn hóa Nghệ thuật tương ứng. Người dùng Người dùng là người dùng cuối sử dụng hệ thống, bao gồm: Người quản trị, Giảng viên, học viên. Người quản trị Là người đảm bảo hoạt động của hệ thống được thông suốt, họ thường không tham gia, không sử dụng chức năng ở mức nghiệp vụ ứng dụng. Nhãn nội dung Các Nội dung Đa phương tiện được đánh nhãn phục vụ cho việc tìm kiếm, phân loại. Nội dung Môn học Các giảng viên biên soạn các Nội dung Môn học khác nhau cho từng Môn học tương ứng. Phiên làm việc Một khi Người dùng đăng nhập hệ thống, Người dùng đã tạo ra một Phiên làm việc. Phiên làm việc này kết thúc khi người dùng thực hiện Đăng xuất hệ thống. Quyền người dùng Quyền người dùng đại diện cho đơn vị giới hạn chức năng sử dụng, bao gồm việc được phép/không được phép truy cập vào một trang chức năng. Tài khoản Người dùng Là toàn khoản lưu thông tin, cấu hình liên quan tới Người dùng tương ứng. Vở diễn Người nghệ sĩ biểu diễn một điệu múa, một điệu nhảy truyền thống hay người nghệ sĩ đó đang thực hiện một vở diễn. Dữ liệu 3D chuyển động Dữ liệu thể hiện chuỗi các hành động dữ ra từ Vở diễn. Dữ liệu Đa phương tiện Bao gồm video, file âm thanh, hình ảnh, văn bản, ... được thu lại liên quan tới nội dung văn hóa phi vật thể của dân tộc. Hệ thống 3DRecognization Là hệ thống thực hiện nhiệm vụ trích xuất Dữ liệu 3D chuyển động từ Dữ liệu Đa phương tiện. Khung xương 3D Dữ liệu khung xương của nhân vật đang thực hiện điệu nhảy. Yêu cầu Nội dung 3D chuyển động Là đầu vào của hệ thống 3DRecognization. 67 4.2.2. Tài liệu tham khảo STT Tên tài liệu 1 Bài giảng bộ môn kịch hát dân tộc Trường Đại học Sân khấu Điện ảnh HN 2 Nội dung thông tin từ website: 3 Các bài viết, tiểu luận về bộ môn kịch hát dân tộc cũng như nhóm ngành Văn hoá Nghệ thuật 4.2.3. Các yêu cầu ban đầu  Là phần mềm hỗ trợ giảng dạy cho giảng viên, hỗ trợ học tập cho sinh viên, cho phép giảng dạy và học tập theo hình thức “vai mẫu” thông qua các dữ liệu tích hợp video, âm thanh, hình ảnh, chuyển động 3D, bài giảng dạng văn bản.  Kế thừa kho tư liệu về văn hóa phi vật thể của Bộ Văn hóa, Thể thao và Du lịch, và các cơ quan liên quan. o Hỗ trợ Đơn vị cung cấp nội dung nhận các yêu cầu nội dung, upload Nội dung đa phương tiện theo yêu cầu tương ứng. o Hỗ trợ quá trình nhận dữ liệu và lưu trữ dữ liệu vào hệ thống bằng nhiều hình thức khác nhau như Người dùng chuyển dữ liệu cho bộ phận kỹ thuật của Trường Đại học Sân khấu Điện ảnh, sau đó bộ phận kỹ thuật sẽ tổng hợp vào lưu vào hệ thống hoặc người dùng upload dữ liệu và nhập các thông tin mô tả về tệp dữ liệu, sau đó dữ liệu được kiểm duyệt và hiển thị.  Hệ thống cho phép thể hiện nội dung được xây dựng từ tập Dữ liệu Đa phương tiện bao gồm: Tệp video 2D, video 3D, âm thanh, hình ảnh, và văn bản.  Hệ thống được xây dựng trên nền web (Web-based) và được sử dụng trong môi trường Internet.  Hệ thống cho phép xem và so sánh giữa những vở diễn của các người diễn khác nhau hoặc cùng một vở diễn hoặc người diễn nhưng ở các góc quay khác nhau.  Hệ thống cho phép lọc, tìm kiếm nội dung với các tiêu chí khác nhau như: Người diễn, tên vở diễn, nội dung trong bài giảng,  Hệ thống cho phép phân loại nội dung với các tiêu chí khác nhau như theo: Độ dài, người diễn, tên vở diễn, nội dung trong bài giảng, động tác cơ bản trong vở diễn, ... 68  Hệ thống cho phép thêm, sửa, xóa tài nguyên bao gồm các Dữ liệu Đa phương tiện (Video 2D, video 3D, tệp âm thanh, hình ảnh, văn bản) một cách thuận lợi.  Hệ thống cho phép xây dựng bài giảng điện tử gồm các phần viết lý luận tích hợp với dữ liệu video, âm thanh, hình ảnh cho một số loại hình kịch hát dân tộc  Hệ thống cho phép xây dựng một số dữ liệu chuyển động 3D về một số loại hình kịch hát dân tộc theo hình thức “Vai mẫu”.  Hệ thống cung cấp bộ công cụ tái tạo chuyển động từ các loại hình kịch hát dân tộc, văn hóa phi vật thể trên các mô hình 3D.  Hệ thống cho phép đánh giá, góp ý từ người học đối với các vai diễn mẫu.  Hệ thống cho phép quản lý danh sách học viên tham gia các lớp học.  Hệ thống cho phép phân quyền chức năng đối với các nhóm người dùng cụ thể.  Hệ thống có thể quản trị bởi nhóm người dùng có kiến thức phần mềm cơ bản.  Hệ thống cần đảm bảo tính sẵn sàng của dữ liệu sau nhiều năm hoạt động. 4.2.4. Mô hình phân rã chức năng của hệ thống Các yêu cầu được mô hình hoá theo các khối chức năng, phi chức năng chính bao gồm: Hình 22: KEEP Package Diagram cho yêu cầu chức năng và phi chức năng 69 4.2.5. Yêu cầu Chức năng 4.2.5.1. Người sử dụng hệ thống Bảng 4: Người sử dụng hệ thống 4.2.5.2. User Story Bảng 5: Danh sách User Story ID User Story Mức độ Tác nhân Hành động ST-1 Là một Người dùng (Người quản trị, Giảng viên, Sinh viên, Người dùng ẩn danh) Tôi có thể xem toàn bộ nội dung bao gồm Dữ liệu: Video 2D, video 3D, âm thanh, hình ảnh, văn bản về loại hình kịch hát dân tộc. 10 pts ST-2 Là một Người dùng ẩn danh Tôi có thể đăng nhập hệ thống để sử dụng các chức năng tương ứng với Quyền người dùng hiện tại. 8 pts ST-3 Là một Người dùng đã đăng nhập hệ thống Tôi có thể đăng xuất hệ thống. 8 pts ST-4 Là một Người quản trị Tôi có thể sử dụng các chức năng để theo dõi các log hệ thống, nhận các thông báo lỗi hệ thống, clean tài nguyên hệ thống 5 pts ST-5 Là một Giảng viên Tôi có thể biên soạn bài giảng sử dụng Dữ liệu Đa phương tiện bao gồm: Dữ liệu video 2D, 3D, dữ liệu âm thanh, hình ảnh và dữ liệu dạng văn bản. 10 pts Người sử dụng Mô tả Người quản trị hệ thống (Admin) Là người cán bộ thuộc Phòng Công Nghệ Thông Tin; Trường Đại học Sân khấu Điện ảnh Hà Nội Giảng viên Là giảng viên Trường Đại học Sân khấu Điện ảnh Hà Nội Sinh viên Là sinh viên Trường Đại học Sân khấu Điện ảnh Hà Nội Người dùng ẩn danh Là những người dùng chưa đăng nhập hệ thống Đại diện đơn vị cung cấp nội dung Là đại diện của những Đơn vị cung cấp nội dung 70 ST-6 Là một Người dùng đã đăng nhập hệ thống Tôi có thể upload Dữ liệu và nhập thông tin mô tả về dữ liệu vào hệ thống 8 pts ST-7 Là một Người quản trị Tôi có thể kiểm duyệt Dữ liệu được người dùng lưu vào hệ thống nhưng chưa được hiển thị tới toàn bộ người dùng cuối 5 pts ST-8 Là một Người dùng đã đăng nhập hệ thống Tôi có thể gửi yêu cầu cung cấp Dữ liệu Đa phương tiện phục vụ cho quá trình giảng dạy và học tập 5 pts ST-9 Là một Người dùng thuộc nhóm Đơn vị cung cấp nội dung Tôi có thể nhận các yêu cầu nội dung, upload Nội dung đa phương tiện theo yêu cầu tương ứng. 5 pts ST-10 Là một người dùng đã đăng nhập hệ thống Tôi có thể xem và so sánh giữa những vở diễn của các người diễn khác nhau hoặc các góc quay khác nhau 10 pts ST-11 Là một người dùng đã đăng nhập hệ thống Tôi có thể tìm kiếm nội dung với các tiêu chí khác nhau như: Người diễn, tên vở diễn, nội dung trong bài giảng, 10 pts ST-12 Là một người dùng đã đăng nhập hệ thống Tôi có thể đánh giá, góp ý một chủ đề Kịch hát dân tộc hoặc một nội dung bài giảng 5 pts ST-13 Là một Người dùng đã đăng nhập hệ thống Tôi có thể lọc, phân loại nội dung với các tiêu chí khác nhau như theo: Độ dài, người diễn, tên vở diễn, nội dung trong bài giảng, động tác cơ bản trong vở diễn, ... 10 pts ST-14 Là một Người dùng đã đăng nhập hệ thống Tôi có thể thêm, sửa, xóa nội dung thuộc Quyền người dùng được phép. 10 pts ST-15 Là một Người dùng đã đăng nhập hệ thống Tôi được cung cấp công cụ phần mềm để có thể xem hoặc cấu hình Dữ liệu Chuyển động 3D về một số loại hình kịch hát dân tộc theo hình thức “vai mẫu”. 10 pts 71 4.2.5.3. Các yêu cầu liên quan tới quản lý nội dung giảng dạy, học tập Hình 23: KEEP Package Diagram cho yêu cầu chức năng quản lý nội dung giảng dạy, học tập 4.2.5.4. Các yêu cầu chung của hệ thống Hình 24: KEEP Package Diagram cho yêu cầu chức năng chung của hệ thống 72 4.2.6. Yêu cầu Phi chức năng Các Yêu cầu Phi chức năng (Non-Functional requirements) được sử dụng để nêu rõ tập hợp các yêu cầu chung được định nghĩa thêm ở mức hệ thống, mức nghiệp vụ (Business Level), là những yêu cầu không ở mức chức năng (Functional Level). Hình 25: KEEP Package Diagram cho yêu cầu phi chức năng 73 4.3. Thiết kế hệ thống 4.3.1. Mô hình tổng thể Hệ thống Mô hình tổng thể hệ thống phải được mô tả dưới dạng hình vẽ và có diễn giải đầy đủ với các nội dung của mô hình kiến trúc logic và mô hình kiến trúc vật lý 4.3.1.1. Mô hình kiến trúc logic Mô tả mối quan hệ, luồng trao đổi dữ liệu giữa các phân hệ trong hệ thống và giữa các phân hệ này với các hệ thống bên ngoài như: Hệ thống skda.edu.vn Web Server, và các hệ thống của các Đơn vị cung cấp nội dung (có thể bổ sung sau này). Hình 26: KEEP Component Diagram Người dùng tương tác với hệ thống thông qua giao diện Web 74 Hình 27: Mô hình kiến trúc logic 4.3.1.2. Mô hình kiến trúc vật lý Mô tả các thành phần vật lý có liên quan của hệ thống như máy chủ, máy trạm, kết nối mạng, máy in, thiết bị cầm tay và cách thức tương tác, kết nối giữa các thành phần vật lý này. 75 Hình 28: KEEP Network Diagram Kiến trúc vật lý của hệ thống 4.3.2. Thiết kế chi tiết 4.3.2.1. Tác nhân tham gia Hệ thống (Actor) Hình 29: KEEP Package Diagram cho tác nhân tham gia hệ thống Người quản trị Giảng v iên Sinh v iên Người dùng ẩn danh Đại diện Đơn v ị cung cấp nội dung 76 4.3.2.2. Bảng mô tả chi tiết Use Case Bảng 6: Bảng mô tả chi tiết Use Case Tên Usecase: Mức độ BMT: Tác nhân chính: Tác nhân phụ: Mô tả Usecase: Điều kiện để bắt đầu Usecase: Điều kiện để kết thúc Usecase: Trình tự các sự kiện trong quá trình hoạt động của Usecase: Hoàn cảnh sử dụng thành công cơ bản: Hoàn cảnh sử dụng phụ (thay thế) trong trường hợp không thành công: Hành động liên quan sẽ xảy ra sau khi Usecase kết thúc: Các yêu cầu phi chức năng: Các Biểu đồ mô tả có liên quan đến: Ghi chú: Mức độ BMT theo 3 cấp: Bắt buộc, Mong muốn, Tuỳ chọn 4.3.2.3. Biểu đồ về các trường hợp sử dụng theo ngôn ngữ UML Bao gồm các biểu đồ sau: 1. Biểu đồ Use Case tổng quát và chi tiết 2. Đối với mỗi Usecase, cần mô tả: a. Activity diagram của từng Use Case; riêng đối với các Use Case chỉ có một trường hợp sử dụng thì không cần xây dựng Activity Diagram b. Biểu đồ cộng tác (Collaboration diagram) (tùy chọn) c. Biểu đồ tuần tự (Sequence diagram) (tùy chọn) d. Biểu đồ trạng thái (State diagram) (tùy chọn) 3. Biểu đồ lớp (Class diagram): Nêu các lớp chính của hệ thống và mối quan hệ giữa các lớp này. 4. Biểu đồ gói (Package diagram) (tùy chọn) 5. Biểu đồ thành phần (Component diagram) (tùy chọn) 6. Biểu đồ triển khai (Deployment diagram) (tùy chọn) 77 1. Quản trị Hệ thống Hình 30: KEEP Package Diagram cho các Use Case Quản trị Hệ thống Hiển thị Log hệ thống Gửi cảnh báo Lỗi hệ thống Hiển thị trạng thái Tài nguyên hệ thống Đánh lại chỉ mục Tài nguyên Clean Database Cache Clean Web Servlet Cache Thu gom rác, giải phóng bộ nhớ Cấu hình Tham số Hệ thống Thiết lập Giao diện Người dùng Cấu hình Tích hợp Mạng xã hội KIểm tra Tốc độ Trước v à Sau quá trình Đánh lại Chỉ mục Tạo lỗi Hệ thống v à Theo dõi Phản hồi So sánh Trạng thái Tài nguyên v ới OS commands Kiểm tra RAM trước v à sau Quá trình Thu gom, giải phóng Người quản trị (from Tác nhân tham gia Hệ thống) «invokes» «invokes» «invokes» «invokes» 78 2. Quản lý Quyền người dùng Hình 31: KEEP Package Diagram cho các Use Case Quản lý Quyền người dùng Người quản trị (from Tác nhân tham gia Hệ thống) Thêm, sửa, xóa Quyền người dùng Gán Rule cho từng Quyền người dùng Quản lý Rule Phân quyền Người dùng Phân quyền Trang theo Quyền người dùng Kiểm tra khi thực hiện Xóa, sửa quyền Người dùng Kiểm tra sự thay đổi khi Gán, hủy gán Rule Kiểm tra giới hạn quyền Người dùng khi Sửa, xóa Rule Kiểm tra giới hạn quyền Người dùng sau khi Phân quyền Kiểm tra giới hạn quyền truy cập Trang «invokes» «invokes» «invokes» «invokes» «invokes» 79 3. Quản trị Người dùng a. Quản trị Người dùng diagram Hình 32: KEEP Package Diagram cho các Use Case Quản trị Người dùng Quản trị Người dùng A Hiển thị Thông tin chi tiết Tài khoản Đóng Tài khoản Người dùng Hiển thị các Tạc vụ quá khứ Xóa Người dùng Hiển thị Lịch sử Người dùng Đăng nhập Giảng viên (from Tác nhân tham gia Hệ thống) Người quản trị (from Tác nhân tham gia Hệ thống) Sinh viên (from Tác nhân tham gia Hệ thống) Tạo Tài khoản Người dùng Quản lý Tạc vụ Người dùng Gán thông tin Người dùng cho từng Tạc vụ, Dữ liệu Kiểm thử v ới toàn bộ Tạc v ụ, Dữ liệu «extend» «include» «invokes» «extend» «extend» 80 b. Hiển thị Lịch sử Người dùng Hình 33: TEMP Sequence Diagram cho Use Case Hiển thị Lịch sử Người dùng c. Hiển thị Thông tin chi tiết Tài khoản Hình 34: TEMP Sequence Diagram cho Use Case Hiển thị Thông tin chi tiết Tài khoản :View History retrieveAccountDetails() loadAccountHistory() :Hiển thị Thông tin chi tiết Tài khoản ref Hiển thị Lịch sử Người dùng ref Hiển thị các Môn học đang tham gia 81 d. Hiển thị các Tạc vụ quá khứ Hình 35: TEMP Sequence Diagram cho Use Case Hiển thị các Tạc vụ trong quá khứ e. Xóa Người dùng Hình 36: TEMP Sequence Diagram cho Use Case Xóa Người dùng :View Prev ious Actions loadPreviousActions () loadAccountDetails() :Delete User ref Close Account select Delete User command() retrieveAccountDetails() 82 f. Đóng Tài khoản Người dùng Hình 37: TEMP Sequence Diagram cho Use Case Đóng Tài khoản g. Đăng nhập Hình 38: TEMP Sequence Diagram cho Use Case Đăng nhập CheckOrdersAccountDetails :Close AccountConfirm return confirmation () loadAccountDetails() get confirmation() markAccountClosed() get confirmation() return confirmation () checkForOutstandingOrders() :LoginAcount:Login ValidateUser(String, String) Login() 83 4. Quản lý Thông tin chung Hình 39: KEEP Package Diagram cho các Use Case Quản lý Thông tin chung Người quản trị (from Tác nhân tham gia Hệ thống) Quản lý Đơn v ị cung cấp nội dung Quản lý Chuyên ngành Quản lý Môn học Quản lý Nghệ sĩ Quản lý Nhãn nội dung Quản lý Loại hình Nghệ thuật Quản lý Lớp học Quản lý Học v iên Lớp học Kiểm tra ảnh hưởng sau khi Sửa, xóa Môn học Kiểm tra ảnh hưởng sau khi Sửa, xóa Lớp học «invokes» «invokes» 84 5. Quản lý Dữ liệu Đa phương tiện a. Quản lý Dữ liệu Đa phương tiện_Người quản trị diagram Hình 40: KEEP Package Diagram cho các Use Case Quản lý dữ liệu Đa phương tiện_Người quản trị Người quản trị (from Tác nhân tham gia Hệ thống) Kiểm duyệt Dữ liệu Đa phương tiện Liệt kê Dữ liệu Đa phương tiện Đăng ký Thu thập Dữ liệu Đa phương tiện Lưu v à Quản lý Dữ liệu Đa phương tiện Thêm mới Dữ liệu Đa phương tiện Cập nhật Danh mục Dữ liệu Đa phương tiện Hiển thị Dữ liệu Đa phương tiện Trình diễn Dữ liệu 3D Đánh giá song song nhóm Dữ liệu Đa phương tiện Kiểm tra giới hạn Quyền người dùng v ới Dữ liệu đã/chưa kiểm duyệt Kiểm tra Tính toàn v ẹn, dư thừa Dữ liệu Kiểm tra thay đổi Dữ liệu Khung xương, Dữ liệu Lớp da «trace» «trace» «trace» 85 b. Quản lý Dữ liệu Đa phương tiện_Giảng viên diagram Hình 41: KEEP Package Diagram cho các Use Case Quản lý Dữ liệu Đa phương tiện_Giảng viên Giảng v iên (from Tác nhân tham gia Hệ thống) Kiểm duyệt Dữ liệu Đa phương tiện Liệt kê Dữ liệu Đa phương tiện Đăng ký Thu thập Dữ liệu Đa phương tiện Lưu v à Quản lý Dữ liệu Đa phương tiện Thêm mới Dữ liệu Đa phương tiện Cập nhật Danh mục Dữ liệu Đa phương tiện Hiển thị Dữ liệu Đa phương tiện Trình diễn Dữ liệu 3D Đánh giá song song nhóm Dữ liệu Đa phương tiện Kiểm tra giới hạn Quyền người dùng v ới Dữ liệu đã/chưa kiểm duyệt Kiểm tra Tính toàn v ẹn, dư thừa Dữ liệu Kiểm tra thay đổi Dữ liệu Khung xương, Dữ liệu Lớp da «trace» «trace» «trace» 86 c. Quản lý Dữ liệu Đa phương tiện_Sinh viên diagram Hình 42: KEEP Package Diagram cho các Use Case Quản lý Dữ liệu Đa phương tiện_Sinh viên Kiểm duyệt Dữ liệu Đa phương tiện Liệt kê Dữ liệu Đa phương tiện Đăng ký Thu thập Dữ liệu Đa phương tiện Lưu v à Quản lý Dữ liệu Đa phương tiện Thêm mới Dữ liệu Đa phương tiện Cập nhật Danh mục Dữ liệu Đa phương tiện Hiển thị Dữ liệu Đa phương tiện Trình diễn Dữ liệu 3D Đánh giá song song nhóm Dữ liệu Đa phương tiện Kiểm tra giới hạn Quyền người dùng v ới Dữ liệu đã/chưa kiểm duyệt Kiểm tra Tính toàn v ẹn, dư thừa Dữ liệu Kiểm tra thay đổi Dữ liệu Khung xương, Dữ liệu Lớp da Sinh v iên (from Tác nhân tham gia Hệ thống) «trace» «trace» «trace» 87 6. Quản lý Bài giảng a. Quản lý Bài giảng_Người quản trị diagram Hình 43: KEEP Package Diagram cho các Use Case Quản lý Bài giảng_Người quản trị Biên soạn Nội dung bài giảng Người quản trị (from Tác nhân tham gia Hệ thống) Xây dựng Cấu trúc Bài giảng Cập nhật Nội dung Bài giảng Xóa Nội dung Bài giảng Tìm kiếm Nội dung Bài giảng Đánh giá Nội dung Bài giảng Quản lý Nhóm chuyên gia Quản lý Nhóm người học Phân loại Nội dung Bài giảng Hiển thị Nội dung Bài giảng Kiểm tra ảnh hưởng Xóa Nội dung Bài Giảng Kiểm tra Hiển thị Nội dung Bài giảng Kiểm tra ảnh hưởng thay đổi Cấu trúc Bài giảng Kiểm tra ảnh hưởng Thay đổi Nội dung Bài giảng «trace» «invokes» «trace» «trace» 88 b. Quản lý Bài giảng_Giảng viên diagram Hình 44: KEEP Package Diagram cho các Use Case Quản lý Bài giảng_Giảng viên Biên soạn Nội dung bài giảng Giảng v iên (from Tác nhân tham gia Hệ thống) Xây dựng Cấu trúc Bài giảng Cập nhật Nội dung Bài giảng Xóa Nội dung Bài giảng Tìm kiếm Nội dung Bài giảng Đánh giá Nội dung Bài giảng Quản lý Nhóm chuyên gia Quản lý Nhóm người học Phân loại Nội dung Bài giảng Hiển thị Nội dung Bài giảng Kiểm tra ảnh hưởng Xóa Nội dung Bài Giảng Kiểm tra Hiển thị Nội dung Bài giảng Kiểm tra ảnh hưởng thay đổi Cấu trúc Bài giảng Kiểm tra ảnh hưởng Thay đổi Nội dung Bài giảng «invokes» «trace» «trace» «trace» 89 c. Quản lý Bài giảng_Sinh viên diagram Hình 45: KEEP Package Diagram cho các Use Case Quản lý Bài giảng_Sinh viên Biên soạn Nội dung bài giảng Sinh v iên (from Tác nhân tham gia Hệ thống) Xây dựng Cấu trúc Bài giảng Cập nhật Nội dung Bài giảng Xóa Nội dung Bài giảng Tìm kiếm Nội dung Bài giảng Đánh giá Nội dung Bài giảng Quản lý Nhóm chuyên gia Quản lý Nhóm người học Phân loại Nội dung Bài giảng Hiển thị Nội dung Bài giảng Kiểm tra ảnh hưởng Xóa Nội dung Bài Giảng Kiểm tra Hiển thị Nội dung Bài giảng Kiểm tra ảnh hưởng thay đổi Cấu trúc Bài giảng Kiểm tra ảnh hưởng Thay đổi Nội dung Bài giảng «trace» «trace» «trace» «invokes» 90 d. Biên soạn Nội dung bài giảng Hình 46: TEMP Sequence Diagram cho Use Case Biên soạn Nội dung bài giảng 4.3.3. Thiết kế Cơ sở dữ liệu 4.3.3.1. Mô hình cơ sở dữ liệu Mô tả phương án xây dựng CSDL với các nội dung: Tên CSDL: PostgreSQL_FolkDance Database Sơ đồ mô tả mối quan hệ giữa các bảng: Giảng viên (from Tác nhân tham gia Hệ thống) Màn hình biên soạn Danh sách video 3D, 2D Nội dung Bài giảng LH Adapter loop loop Thêm video 3D() Thêm video 2D() 91 Hình 47: KEEP Class Diagram mô tả mối quan hệ giữa các bảng 92 Các Bảng của CSDL cần đặc tả các thông tin như bảng sau: Tên bảng: [tên bảng] – [Giải thích tên bảng] STT Tên trường Kiểu dữ liệu và kích thước Ràng buộc dữ liệu Ý nghĩa Ghi chú 1..n Khoá chính, khoá ngoại... 4.3.3.2. Giải pháp xây dựng và vận hành CSDL  Mô tả phần mềm quản trị CSDL PostgreSQL  Mô tả giải pháp sao lưu dữ liệu định kỳ; Giải pháp phục hồi CSDL khi có sự cố. 4.3.4. Thiết kế giao diện Mô tả thiết kế các giao diện cơ bản của phần mềm ứng dụng, bao gồm: Giao diện chính, giao diện nhập liệu, giao diện thống kê, báo cáo và giao diện quản trị hệ thống. Chi tiết về các prototype được xây dựng trong quá trình thiết kế giao diện được tôi trình bày tại Phụ lục IV. Danh sách các Prototype 4.4. Tóm lược Nội dung chính của chương này là kết quả của quá trình phân tích, thiết kế hệ thống và xây dựng tài liệu dự án nhằm đạt được các thoả thuận với khách hàng. Công việc xây dựng tài liệu đặc tả yêu cầu người dùng và tài liệu đặc tả yêu cầu hệ thống không phù hợp với hướng tiếp cận vấn đề của Agile tuy nhiên các biểu đồ hệ thống trực quan (KEEPS) thu được sau quá trình này giúp cho việc trao đổi nội bộ cũng như với các bên liên quan trong các cuộc họp, buổi hội thảo trở nên dễ dàng và khoa học. Sau quá trình phân tích hệ thống giai đoạn đầu, tôi đề xuất sử dụng Liferay portal làm nền tảng (platform) của hệ thống quản trị nội dung. Liferay giúp rút ngắn thời gian phát triển và giúp nhóm sớm có được các bản mẫu (prototype) ở Sprint đầu tiên, qua đó giúp nhóm phát triển có được các phản hồi từ khách hàng. 93 KẾT LUẬN Luận văn được xây dựng tập trung vào nghiên cứu các kỹ thuật trong Kỹ nghệ yêu cầu. Cách tiếp cận chúng là khác nhau cho từng phương pháp phát triển phần mềm và trong luận văn tôi tập trung vào phương pháp Agile Scrum. Tôi chọn Scrum vì thực tế đã chứng minh đây là công cụ hiệu quả trong việc đổi mới, sáng tạo, đảm bảo chất lượng sản phẩm và khả năng thành công của dự án. Ngoài ra, lý do chính là phương pháp này đã hệ thống lại một cách hoàn chỉnh quá trình xử lý yêu cầu người dùng và đưa tác nhân người dùng vào làm trọng tâm của quá trình phát triển sản phẩm. Agile Scrum đề cao quá trình phát triển và kiểm thử phần mềm hơn là các công tác liên quan như xây dựng tài liệu dự án cũng là yếu tố để tôi nghiên cứu thêm các phương pháp nhằm tinh gọn công cụ mô hình hoá UML nhằm sử dụng nó hợp lý trong các buổi họp có sự tham gia của người dùng hay các buổi họp chỉ trong nội bộ các thành viên nhóm phát triển. Và kết quả của quá trình xây dựng luận văn được tóm tắt thành các phần như sau: Thứ nhất, tôi nghiên cứu lý thuyết các kỹ nghệ yêu cầu cổ điển trong các mô hình Xã hội – Kỹ thuật (Socio – Technical model) như: USTM, CUSTOM VÀ OSTA cùng với các phương pháp khác như Phương pháp Hệ thống mềm (Soft Systems Methodology), Phương pháp Thiết kế hợp tác (Participatory Design) và phương pháp phát triển phần mềm truyền thống Waterfall. Sau đó, từ thực nghiệm thông qua các dự án Agile tôi đã tham gia, tôi xác định điểm chung của Agile so với phần còn lại từ đó đi tìm câu trả lời vì sao dự án Agile có tỉ lệ thành công cao hơn nhiều so với dự án truyền thống thông qua cách giải quyết của phương pháp này với các vấn đề về tổ chức gặp phải khi áp dụng hệ thống phần mềm hay các vấn đề khi yêu cầu người dùng không rõ ràng cụ thể hoặc phát sinh thay đổi, phát sinh yêu cầu mới trong quá trình phát triển. Thứ hai, tôi nghiên cứu vai trò và trách nhiệm của Chủ sản phẩm (Product Owner), quá trình mà họ làm việc cùng các Bên liên quan, cũng như các thành viên trong nhóm phát triển, và cách họ quản lý vòng đời của một yêu cầu người dùng đi từ các Epic, các Product Backlog sau đó được làm mịn dần qua từng Sprint để chuyển hoá thành các đầu việc, là đầu vào cho quá trình coding và xây dựng test case. Thứ ba, để trình bày một chức năng hay một vấn đề của hệ thống một cách khoa học không thể chỉ sử dụng Prototype và Mockup và quá trình xây dựng tài liệu dự án dù không là yếu 94 tố quan trọng trong Agile nhưng vẫn cần thiết cho quá trình nghiệm thu hoặc quá trình bảo trị hệ thống. Vì vậy tôi đã nghiên cứu hướng áp dụng phù hợp kỹ thuật mô hình hoá UML vào các buổi họp với khác hàng cũng như các cuộc họp nội bộ giữa các thành viên trong đội dự án, các sơ đồ UML được chia làm 2 nhóm KEEPs và TEMPs với mục tiêu là tối thiểu hoá, chỉ sử dụng những sơ đồ cần thiết nhất. Tôi đã áp dụng kiến thức này vào việc xây dựng Bản đặc tả yêu cầu người dùng và Bản đặc tả yêu cầu hệ thống của Phần mềm Giảng dạy Kịch hát dân tộc Trường Đại học Sân khấu Điện ảnh. Thứ tư, trong các UML Diagram, các phần tử có thể thừa kế hay nói cách khác các phần tử trong các Diagram có mối quan hệ với nhau và để đảm bảo các phần tử này được quản lý một cách hướng đối tượng và có thể sử dụng lại được, tôi đề xuất sử dụng công cụ Enterprise Architecture – EA. Ngoài ra EA đặc biệt nên dùng với các dự án phức tạp và các vấn để được trình bày qua nhiều các cuộc họp giữa các bên yêu cầu các Diagram cần thay đổi và chia sẻ xuyên suốt quá trình thực hiện dự án. Thứ năm, nắm vững kiến thức về Liferay Portal và vận dụng framework này làm nền tảng để hiện thực các yêu cầu chức năng liên quan tới quản trị nội dung trong dự án E-Learning. Điều này giúp nhóm nghiên cứu tập trung vào các bài toán xây dựng vai mẫu 3D và các vấn đề liên quan. 95 DANH MỤC TÀI LIỆU THAM KHẢO 1. Bill Opdyke, Dennis Mancl, Steve Fraser (2010), “Architecture in an Agile world, 2010”, SPLASH workshop 2. Craig Larman (2007), “Applying UML and Patterns: An Introduction to Object- Oriented Analysis and Design and Iterative Development” 3. Jack Reeves (1992), “What is Software Design?” 4. Kenji Hiranabe (2015), “Modeling in the Agile age”, Change Vision, Inc 5. Lee Ackerman (2011), “Agile Modeling: Enhancing Communication and Understanding” 6. Martin Fehrenbach, "A Survey on Requirements Elicitation" 7. Martin Fowler (2004), “Is Design Dead?” 8. Martin Fowler (1997), “The Almighty Thud” 9. Scott Ambler (2002), “Agile Modeling”, John Wiley & Sons Ltd. 10. Steve McConnell (1996), Rapid Development 11. Roman Pichler (2016), “Epics and Ready Stories” 12. Roman Pichler (2016), “User Story Modelling” 13. Roman Pichler (2016), “User Stories or Use Cases?” 96 PHỤ LỤC Phụ lục I. Bộ câu hỏi phỏng vấn các bên liên quan (Q&A) Cán bộ quản lý khoa Kịch hát dân tộc Q: Hiện tại trường đang đào tạo các loại hình Sân khấu truyền thống nào? A: Sân khấu, Kịch hát dân tộc, Múa, Tuồng, Chèo, Cải lương Q: Từ trước tới nay, nhà trường đã áp dụng CNTT vào các công tác đào tạo chưa? A: Từ năm 2012 đến nay, Viện Sân khấu - Điện ảnh thuộc Trường ĐH Sân khấu & Điện ảnh Hà Nội đã thực hiện ghi hình (file 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. Đến nay, nhiều trích đoạn sân khấu đã được ghi hình thành công với những vai mẫu quen thuộc của nghệ thuật chèo truyền thống như Thị Mầu, Thị Kính, Lưu Bình - Dương Lễ, Châu Long... Q: Phần mềm giảng dạy có áp dụng cho toàn bộ các khoa không? A: Chỉ áp dụng cho khoa Kịch hát dân tộc, các khoa khác không áp dụng hệ thống này. Q: Các loại hình đó có bao nhiêu giảng viên giảng dạy, truyền nghề? Tổng bao gồm 22 người cho bộ môn Nghệ thuật sân khấu bao gồm: Giảng viên cơ hữu có khoảng 10 người; Giảng viên thỉnh giảng có hơn 10 người có phương pháp giảng dạy tương tự Giảng viên cơ hữu. Q: Các loại hình đó có bao nhiêu sinh viên theo học? A: Mỗi khoá học có 4 năm học, trung bình mỗi năm có 25 học sinh cho chuyên ngành chèo, cải lương. Từ năm 2017, chèo tăng thêm 50 sinh viên, cải lương tăng thêm 40 sinh viên. Q: Cơ sở vật chất trong lớp học bao gồm những gì? 97 A: Nhà trường có trang bị Wifi nhưng độ ổn định không cao. Hiện tại ở các lớp học (Sân khấu) chỉ trang bị: Kho quần áo, phục trang, đạo cụ, cảnh trí, sân khấu riêng, màn hình, đầu video. Nhà trường sẵn sàng trang bị máy tính và các thiết bị cần thiết để sử dụng phần mềm. Q: Hệ thống có xây dựng nhằm hỗ trợ cho việc học tại nhà của sinh viên không? A: Cần hỗ trợ cả việc học tại trường và tại nhà. Q: Phần mềm có có phần vào việc đánh giá quá trình học tập của sinh viên không? Nếu có sẽ dựa trên những tiêu chí nào? A: Giáo viên đánh giá và chấm điểm thông qua các vai diễn trực tiếp và vẫn theo cách đánh giá cũ. Chắc chắn sẽ không sử dụng phần mềm này trong quá trình đánh giá. Q: Kỹ năng sử dụng phần mềm của các thầy cô có đồng đều không, có bao nhiêu người không thể sử dụng phần mềm? A: Cần có các buổi đào tạo, hướng dẫn sử dụng phần mềm vì kỹ năng CNTT của giảng viên không đồng đều, có nhiều giảng viên lớn tuổi. Q: Có bắt buộc sử dụng phần mềm này trong quá trình giảng dạy và học tập không? A: Không bắt buộc, chỉ được xem là một công cụ phục vụ cho quá trình giảng dạy và học tập. Q: Phần mềm có nhằm hỗ trợ Giảng viên biên soạn bài giảng không? A: Có hỗ trợ. Q: Phần mềm cần xây dựng bộ dữ liệu: Video, âm thanh, hình ảnh, tài liệu để sử dụng vào quá trình xây dựng Bài giảng, vậy dữ liệu được upload khi nào? A: Cần hỗ trợ giảng viên upload trực tiếp hoặc Giảng viên làm việc với phòng CNTT của khoa. Q: Hệ thống có xây dựng chức năng như một trang tin, blog phục vụ Giảng viên, Sinh viên đăng các tin bài liên quan tới việc học không? 98 A: Có, mục đích tạo ra hệ thống không chỉ cho việc dạy và học mà góp phần bản tồn văn hoá, truyền bá rộng rãi. Phần mềm sẽ cần liên kết với hệ thống website của trường cũng như các đơn vị khác. Giảng viên Khoa kịch hát dân tộc Q: Thầy, cô đang giảng dạy những môn nào? Loại hình nghệ thuật nào? Q: Mỗi buổi học thường diễn ra bao lâu? A: 1 đến 4 tiết học trong một buổi. Q: Loại hình Thầy, Cô đang giảng dạy có những vai diễn nào? Vở diễn nào? Có tư liệu về những vai diễn đó không? Q: Những vai diễn Thầy, Cô giảng dạy có nhiều diễn viên thể hiện không? Diễn viên nào là tiêu biểu nhất? A: Có nhiều diễn viên, trung bình có 3 diễn viên cho một vai mẫu. Q: Các vai mẫu nào điển hình có trong giáo trình đào tạo? A: Thị Mầu, Thị Kính, Lưu Bình - Dương Lễ, Châu Long, Mẹ mõ lý trưởng, Q: Thầy, Cô đang giảng dạy các vai diễn đó cho sinh viên như thế nào? A: Dạy sinh viên lý thuyết; Biểu diễn mẫu các nhân vật vai mẫu; Phân nhóm sinh viên và yêu cầu nhóm tự biểu diễn; Có thể quay video về nhà xem; Sinh viên trả bài ở các buổi tiếp theo. Q: Cách giảng dạy đó có thuận lợi gì và khó khăn gì? A: Thuận lợi là sinh viên được lên lớp và trực tiếp học cách biểu diễn của giảng viên. Khó khăn như thiếu trang thiết bị phục vụ học tập; Đội ngũ giảng viên dạy chuyên môn là những nghệ sĩ thực sự có tài năng thì hiếm hoi; Phương pháp truyền nghề theo vai mẫu thiếu khoa học, thiếu “chất lửa” nghề nghiệp; 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. 99 Q: Sử dụng phần mềm để xây dựng toàn bộ bài giảng của môn học có đáp ứng đầy đủ nội dung muốn truyền tải không? A: Đáp ứng được nếu thể hiện được đầy đủ sắc thái của diễn viên ở nhiều góc độ. Ví dụ: Thể hiện được sắc thái của ánh mắt, khuôn mặc, dáng đi, điệu bộ, cử chỉ, Q: Thay vì biểu diễn trực tiếp, hoặc trình chiếu video của các Nghệ sĩ tới sinh viên, việc sử dụng nhân vật vai mẫu 3D có mang lại hiệu quả giảng dạy cao hơn không? A: Cần hỗ trợ song song, mang đến cho người học càng nhiều cách tiếp cận càng tốt. Sinh viên Q: Bạn đang học cách diễn của các Nghệ sĩ như thế nào? Q: Cách học đó có hiệu quả và dễ tiếp thu không? Q: Với cách học cũ bạn đang gặp khó khăn gì? A: Chỉ được theo dõi giảng viên biểu diễn khi lên lớp; Góc nhìn nhân vật hạn chế nên khó theo dõi toàn bộ động tác, cử chỉ, ánh mắt Q: Hệ thống phần mềm mới sẽ cho phép bạn so sánh giữa các người diễn khác nhau, các động tác tiêu biểu của người diễn. Theo bạn giao diện người dùng cho chức năng này nên trình bày như thế nào? Q: Bạn có thường xem video, youtube phục vụ cho quá trình học không? Q: Bạn tìm tài liệu học tập qua kênh nào? Việc tìm kiếm có dễ dàng không? Q: Hệ thống sẽ cho phép bạn tìm kiếm vai diễn mẫu theo thể loại, nhân vật mẫu, vai diễn dưới dạng 2D và 3D bạn thấy thế nào? Q: Hệ thống cho phép lọc, phân loại nội dung với các tiêu chí khác nhau như theo: độ dài, theo người diễn, tên vở diễn, động tác cơ bản, nội dung trong bài giảng, ...; bạn thấy thế nào? Q: Bạn mong muốn có những nguồn dữ liệu, thông tin nào trong quá trình học? 100 Q: Cách học các vai diễn như thế nào là hiệu quả đối với bạn? Q: Bạn có muốn một thư viện dữ liệu đa phương tiện giúp bạn có thể so sánh các vai diễn của các Nghệ sĩ khác nhau không? Q: Nếu sử dụng HTTT để đánh giá quá trình học tập của bạn, bạn nghĩ như thế nào về điều đó? Q: Các bạn mong muốn tích hợp hệ thống với mạng xã hội như Facebook, Twitter để cá nhân hoá nội dung, hoặc xây dựng blog cá nhân không? Ban lãnh đạo nhà trường ĐH Sân khấu Điện ảnh Q: Nếu có một HTTT mới, quá trình Đào tạo có thể thay đổi, áp dụng không? A: Có, nhà trường muốn đa dạng cách học tập cho sinh viên, đổi mới cách giảng dạy của giảng viên cho phù hợp với thực tiễn xã hội Nhân viên Phòng CNTT Q: Nhà trường hiện có những hệ thống phần mềm nào? Hệ thống bao gồm những thiết bị gì? A: Chỉ có website của nhà trường. 101 Phụ lục II. Danh sách các Epic 1. Epic: Người dùng cần một phần mềm hỗ trợ cho việc giảng dạy và học tập 102 2. Phần mềm cần kế thừa kho dữ liệu của các đơn vị liên quan 3. Áp dụng công nghệ 3D vào việc học, giảng dạy 103 4. Phân nhóm người dùng với các chức năng khác nhau 5. Phần mềm phục vụ mọi người quan tâm tới Kịch hát dân tộc và có thể sử dụng trên nhiều thiết thiết bị 104 6. Người dùng muốn đăng tin bài, thảo luận về các nội dung Văn hoá Nghệ thuật 7. Phần mềm cần có tài liệu kỹ thuật và hướng dẫn sử dụng 105 Phụ lục III. Danh sách các User Story 1. LÀ MỘT người dùng, TÔI MUỐN xem vở diễn 2D 2. LÀ MỘT người dùng, TÔI MUỐN xem đồng thời các video mẫu khác nhau của cùng một vở diễn đã chọn ĐỂ tôi so sánh giữa các người diễn với nhau 106 3. LÀ MỘT người dùng, TÔI MUỐN xem một vở diễn ở các góc quay khác nhau ĐỂ tôi quan sát người diễn ở các góc quay khác nhau 4. LÀ MỘT người dùng, TÔI MUỐN sử dụng toàn bộ dữ liệu văn hóa phi vật thể của Bộ Văn Hóa, Thể Thao và Du Lịch và các cơ quan liên quan ĐỂ phục vụ cho việc học, nghiên cứu 107 5. LÀ MỘT người dùng, TÔI MUỐN tìm kiếm các nội dung đa phương tiện 6. LÀ MỘT người dùng, TÔI MUỐN lọc các nội dung đa phương tiện theo các "vai mẫu", theo diễn viên, theo loại hình động tác cơ bản 108 7. LÀ MỘT người dùng, TÔI MUỐN phân loại các nội dung đa phương tiện theo các "vai mẫu", theo diễn viên, theo loại hình động tác cơ bản 8. LÀ MỘT người dùng, TÔI MUỐN xem vở diễn ở dạng 3D ĐỂ chọn xem vở diễn ở các góc nhìn khác nhau 109 9. LÀ MỘT người dùng đã xác thực, TÔI MUỐN làm việc với những chức năng phù hợp với vai trò của mình 10. LÀ MỘT người dùng đã xác thực, TÔI MUỐN lưu vết những thông tin của các lần sử dụng trước đó 110 11. LÀ MỘT giảng viên hoặc sinh viên, TÔI MUỐN đăng các blog có nội dung về Kịch hát dân tộc 12. LÀ MỘT giảng viên hoặc sinh viên, TÔI MUỐN góp ý kiến cá nhân cho các blog tôi quan tâm 111 13. LÀ MỘT giảng viên, TÔI MUỐN biên soạn bài giảng sử dụng các nội dung đa phương tiện về Kịch hát dân tộc 112 Phụ lục IV. Danh sách các Prototype 1. Màn hình Đăng nhập 2. Màn hình Quản lý Quyền người dùng 113 3. Màn hình Cập nhật Người dùng 4. Màn hình Tạo mới Trang 114 5. Màn hình Upload Dữ liệu đa phương tiện 6. Màn hình Quản lý Dữ liệu đa phương tiện 115 7. Màn hình Soạn thảo Bài giảng chế độ trực quan 8. Màn hình Soạn thảo Bài giảng chế độ HTML 116 9. Màn hình Hiển thị Bài giảng 10. Màn hình Tìm kiếm 117 11. Màn hình Hiển thị vai mẫu 3D 12. Màn hình Quản trị hệ thống