Luận văn Thạc sĩ Công nghệ thông tin: 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 Trường Đại học Sân khấu điện ảnh

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trần Hữu Nguyên

Thiết kế, xây dựng hệ thống phần mềm giảng dạy kịch hát dân tộc Trường Đại học Sân khấu điện ảnh

LUẬN VĂN TỐT NGHIỆP THẠC SĨ HỆ CHÍNH QUY

Ngành: Công Nghệ Thông Tin

HÀ NỘI - 2017

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trần Hữu Nguyên

Thiết kế, xây dựng hệ thống phần mềm giảng dạy kịch hát dân tộc Trường Đại học Sân khấu điện ảnh

Ngành: Công Nghệ Thông Tin

Chuyên ngành: Kỹ Thuật Phần Mềm

Mã Số: 60480103

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

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

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

HÀ NỘI - 2017

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn này là công trình nghiên cứu của riêng tôi dưới sự hướng dẫn

khoa học của PGS. TS. Bùi Thế Duy, đồng hướng dẫn TS. Ngô Thị Duyên. Các số liệu, kết

quả được trình bày trong luận văn là chính xác và trung thực. Tôi đã trích dẫn đầy đủ nguồn

gốc các tài liệu tham khảo, công trình nghiên cứu liên quan. Ngoại trừ các trích dẫn này, luận văn hoàn toàn là công việc của cá nhân tôi.

Luận văn được hoàn thành trong thời gian tôi là học viên Khoa Công Nghệ Thông Tin, Trường Đại Học Công Nghệ, Đại Học Quốc Gia Hà Nội.

Hà Nội, ngày tháng 11 năm 2017

HỌC VIÊN

Trần Hữu Nguyên

LỜI CẢM ƠN

Trong quá trình học và xây dựng luận văn này, tôi nhận được sự giúp đỡ, hỗ trợ của các

thầy cô Ban Giám hiệu nhà trường và các đơn vị phòng ban Trường Đại học Công nghệ -

Đại học Quốc gia Hà Nội.

Đầu tiên, tôi xin gửi lời cảm ơn chân thành đến PGS. TS. Bùi Thế Duy, đồng hướng dẫn TS. Ngô Thị Duyên đã trực tiếp hướng dẫn tôi thực hiện luận văn này. Thầy, cô đã tận tình chỉ bảo, cung cấp cho tôi kiến thức, tài liệu cùng các phương pháp nghiên cứu, giải quyết vấn đề một cách khoa học từ đó giúp tôi sáng tỏ từng bước trong quá trình hoàn thiện luận

văn.

Tôi cũng xin bày tỏ lòng biết ơn tới các thầy cô giáo trong Phòng Thí nghiệm Tương tác

Người – Máy, Bộ môn Công Nghệ Phần Mềm, Bộ môn Các Hệ Thống Thông Tin, những

người đã đem trí tuệ, công sức của mình truyền đạt lại cho chúng tôi. Những kiến thức này

đã giúp ích rất nhiều cho tôi trong quá trình học tập và công tác.

Cuối cùng, tôi xin gửi lời cảm ơn đến gia đình và bạn bè, những người luôn bên tôi, động

viên và khích lệ tôi trong quá trình học và thực hiện đề tài nghiên cứu của mình.

HỌC VIÊN

Trần Hữu Nguyên

Mục lục

LỜI CAM ĐOAN ......................................................................................................................................... 3

LỜI CẢM ƠN ............................................................................................................................................... 4

DANH MỤC CÁC THUẬT NGỮ .............................................................................................................. 8

DANH MỤC CHỮ VIẾT TẮT ................................................................................................................... 8

DANH MỤC BẢNG BIỂU .......................................................................................................................... 9

DANH MỤC HÌNH VẼ ............................................................................................................................... 9

MỞ ĐẦU ..................................................................................................................................................... 11

1.1. 1.2. 1.3.

CHƯƠNG 1. GIỚI THIỆU .................................................................................................................. 12 MỤC ĐÍCH VÀ Ý NGHĨA CỦA ĐỀ TÀI ........................................................................................... 12 ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU ....................................................................................... 13 PHƯƠNG PHÁP NGHIÊN CỨU ...................................................................................................... 13 1.3.1. Phương pháp nghiên cứu Lý thuyết ...................................................................................... 13 1.3.2. Phương pháp nghiên cứu Thực nghiệm ................................................................................ 14 CẤU TRÚC LUẬN VĂN ................................................................................................................ 15

1.4.

2.1.

2.2.

CHƯƠNG 2. CƠ SỞ LÝ THUYẾT ..................................................................................................... 16 YÊU CẦU .................................................................................................................................... 17 2.1.1. Yêu cầu trong kỹ nghệ hệ thống và kỹ nghệ phần mềm ........................................................ 17 2.1.2. Một số nhân tố trong phát triển yêu cầu ............................................................................... 18 2.1.3. Các yêu cầu tốt ..................................................................................................................... 18 2.1.4. Khả năng kiểm thử ................................................................................................................ 19 2.1.5. Các thay đổi đối với các yêu cầu .......................................................................................... 19 2.1.6. Tính cần thiết của sự chính xác trong các yêu cầu phần mềm ............................................. 20 PHÂN TÍCH YÊU CẦU .................................................................................................................. 20 2.2.1. Các kỹ thuật chính ................................................................................................................ 20 2.2.2. Các vấn đề ............................................................................................................................ 21 2.2.3. Các giải pháp ........................................................................................................................ 22

2.3.

2.4.

KỸ NGHỆ YÊU CẦU TRUYỀN THỐNG .......................................................................................... 23 2.3.1. Bên liên quan ........................................................................................................................ 23 2.3.2. Các mô hình Xã hội – Kỹ thuật (Socio-technical models) .................................................... 24 2.3.3. Phương pháp các hệ thống mềm ........................................................................................... 29 2.3.4. Phương pháp Thiết kế hợp tác (Participatory Design) ........................................................ 29 2.3.5. Phương pháp nhân chủng học (Ethnographic Methods) ...................................................... 30 2.3.6. Tóm lược ............................................................................................................................... 30 KỸ NGHỆ YÊU CẦU TRONG AGILE SCRUM ................................................................................. 31 2.4.1. Quá trình hình thành ............................................................................................................ 31

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

2.5.

2.4.3. Quy trình và các cuộc họp trong Scrum ............................................................................... 33 2.4.4. Hướng tiếp cận các Bên liên quan (Stakeholder) ................................................................. 41 2.4.5. Làm mịn Product Backlog (Grooming Product Backlog) .................................................... 41 2.4.6. User Story và UML Use Case ............................................................................................... 44 2.4.7. User Story và Acceptance Criteria ....................................................................................... 45 2.4.8. Tốc độ thay đổi yêu cầu qua Release Burndown Chart ........................................................ 47 MÔ HÌNH HÓA TRONG DỰ ÁN AGILE .......................................................................................... 49 2.5.1. Phân loại nhóm mô hình KEEPS và TEMPS ........................................................................ 50 2.5.2. Các mô hình trong KEEPS ................................................................................................... 51 Sử dụng KEEPS trong nhóm Scrum mở rộng ....................................................................... 54 2.5.3. 2.5.4. Tóm lược ............................................................................................................................... 54

CHƯƠNG 3.

3.1.

3.2. 3.3.

PHƯƠNG PHÁP THU THẬP YÊU CẦU ................................................................... 55 TIẾP CẬN CÁC BÊN LIÊN QUAN................................................................................................... 55 3.1.1. Xác định các bên liên quan ................................................................................................... 55 3.1.2. Phân tích các bên liên quan.................................................................................................. 56 3.1.3. Cộng tác với các Player ....................................................................................................... 57 3.1.4. Thu hút sự quan tâm các Subject .......................................................................................... 57 3.1.5. Thao khảo ý kiến của các Context Setter hay Referee .......................................................... 57 3.1.6. Thông báo thông tin tới Crowd ............................................................................................ 58 3.1.7. Lưới Tầm ảnh hưởng-Độ quan tâm (Power-Interest Grid) .................................................. 58 BỘ CÂU HỎI PHỎNG VẤN CÁC BÊN LIÊN QUAN (Q&A) .............................................................. 59 XÂY DỰNG USER STORY, PRODUCT BACKLOG ......................................................................... 59 3.3.1. Xây dựng các Epic ................................................................................................................ 59 3.3.2. Xây dựng các User Story ...................................................................................................... 60 Scrum Taskboard: SPRINT_2017_03_03 ............................................................................. 61 3.3.3. 3.3.4. Bảng Kanban ........................................................................................................................ 62 TÓM LƯỢC ................................................................................................................................. 62

3.4.

CHƯƠNG 4.

4.1.

4.2.

PHÂN TÍCH & THIẾT KẾ HỆ THỐNG .................................................................... 63 PHÂN TÍCH HỆ THỐNG ................................................................................................................ 63 4.1.1. Mô tả quy trình nghiệp vụ ..................................................................................................... 63 4.1.2. Đề xuất quy trình tin học hóa ............................................................................................... 63 CÁC YÊU CẦU CỦA PHẦN MỀM .................................................................................................. 65 4.2.1. Định nghĩa các thuật ngữ ..................................................................................................... 65

4.2.2. Tài liệu tham khảo ................................................................................................................ 67 4.2.3. Các yêu cầu ban đầu ............................................................................................................ 67 4.2.4. Mô hình phân rã chức năng của hệ thống ............................................................................ 68 4.2.5. Yêu cầu Chức năng ............................................................................................................... 69 4.2.6. Yêu cầu Phi chức năng ......................................................................................................... 72

4.3.

THIẾT KẾ HỆ THỐNG .................................................................................................................. 73

4.3.1. Mô hình tổng thể Hệ thống ................................................................................................... 73 4.3.2. Thiết kế chi tiết ..................................................................................................................... 75 4.3.3. Thiết kế Cơ sở dữ liệu ........................................................................................................... 90 4.3.4. Thiết kế giao diện ................................................................................................................. 92 TÓM LƯỢC ................................................................................................................................. 92

4.4.

KẾT LUẬN ................................................................................................................................................. 93

DANH MỤC TÀI LIỆU THAM KHẢO .................................................................................................. 95

PHỤ LỤC .................................................................................................................................................... 96 PHỤ LỤC I. BỘ CÂU HỎI PHỎNG VẤN CÁC BÊN LIÊN QUAN (Q&A) .......................................................... 96 Cán bộ quản lý khoa Kịch hát dân tộc ................................................................................................ 96 Giảng viên Khoa kịch hát dân tộc ...................................................................................................... 98 Sinh viên.............................................................................................................................................. 99 Ban lãnh đạo nhà trường ĐH Sân khấu Điện ảnh ............................................................................ 100 Nhân viên Phòng CNTT .................................................................................................................... 100 PHỤ LỤC II. DANH SÁCH CÁC EPIC ........................................................................................................ 101 PHỤ LỤC III. DANH SÁCH CÁC USER STORY .......................................................................................... 105 PHỤ LỤC IV. DANH SÁCH CÁC PROTOTYPE ........................................................................................... 112

Danh mục các thuật ngữ

Thuật ngữ nghiệp vụ

Thuật ngữ Ý nghĩa

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

Thuật ngữ kỹ thuật

Thuật ngữ Ý nghĩa

Definition of Done - DoD

Là một thoả thuận cơ sở để xác định điều kiện nghiệm thu hoàn thành công việc của nhóm phát triển. Nếu một Tiêu chí chấp nhận (Acceptance Criteria) cần được nêu trong hầu hết các User Story thì chúng ta nên đưa vào mục tiêu chí chung này

KEEPS Các sơ đồ UML được nhóm phát triển giữ lại phục vụ cho các cuộc họp, hội thảo (workshop)

TEMPS Các sơ đồ UML được nhóm phát triển sử dụng trong các cuộc họp nội bộ và sẽ loại bỏ khi hoàn thành mã chương trình

Phần tăng trường chuyển giao được của sản phẩm

Potentially Shippable Product Increment

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

Stakeholder Meeting Các cuộc họp với các bên liên quan như:

Product Strategy – Cuộc họp chiến lược sản phẩm Roadmaping Workshop – Buổi hội thảo lộ trình Sprint Review Meeting – Cuộc họp đánh giá Sprint

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

Chức viết tắt

Ý nghĩa Product Owner (Chủ sản phẩm) PO

Software Analysis and Design SAD

User Acceptance Criteria UAC

Danh mục bảng biểu

BẢNG 1: MÔ TẢ USER STORY TRONG USE CASE ........................................................................................................... 45 BẢNG 2: LƯỚI TẦM ẢNH HƯỞNG-ĐỘ QUAN TÂM (POWER-INTEREST GRID) LÝ THUYẾT ............................................... 56 BẢNG 3: LƯỚI TẦM ẢNH HƯỞNG-ĐỘ QUAN TÂM (POWER-INTEREST GRID) CỦA DỰ ÁN ............................................... 58 BẢNG 4: NGƯỜI SỬ DỤNG HỆ THỐNG ............................................................................................................................. 69 BẢNG 5: DANH SÁCH USER STORY ............................................................................................................................... 69 BẢNG 6: BẢNG MÔ TẢ CHI TIẾT USE CASE .................................................................................................................... 76

Danh mục hình vẽ

HÌNH 1: 7 GIAI ĐOẠN CỦA PHƯƠNG PHÁP TRUYỀN THỐNG CÁC HỆ THỐNG MỀM ............................................................ 29 HÌNH 2: VAI TRÒ CẦU NỐI CỦA CHỦ SẢN PHẨM (PRODUCT OWNER) ............................................................................. 32 HÌNH 3: QUY TRÌNH SCRUM .......................................................................................................................................... 34 HÌNH 4: SỬ DỤNG CÁC CUỘC HỌP ĐỂ HOÀN THIỆN, ĐÁNH GIÁ YÊU CẦU ........................................................................ 37 HÌNH 5: SPRINT BURNDOWN CHART ............................................................................................................................. 38 HÌNH 6: VÒNG ĐỜI CỦA USER STORY ............................................................................................................................ 41 HÌNH 7: CÁC HOẠT ĐỘNG TRONG SPRINT VÀ QUÁ TRÌNH LÀM MỊN PRODUCT BACKLOG ............................................... 42 HÌNH 8: CÁC HOẠT ĐỘNG LÀM MỊN PRODUCT BACKLOG .............................................................................................. 42 HÌNH 9: LỢI ÍCH CỦA QUÁ TRÌNH LÀM MỊN PRODUCT BACKLOG ................................................................................... 44 HÌNH 10: QUÁ TRÌNH LÀM MỊN USER STORY ................................................................................................................. 46 HÌNH 11: CẤU TRÚC CỦA USER STORY ......................................................................................................................... 47 HÌNH 12: RELEASE BURNDOWN CHART CƠ BẢN ........................................................................................................... 48 HÌNH 13: RELEASE BURNDOWN CHART QUAN TÂM TỚI THAY ĐỔI YÊU CẦU Ở SPRINT HIỆN TẠI .................................... 48 HÌNH 14: RELEASE BURNDOWN CHART QUAN TÂM TỚI XU HƯỚNG THAY ĐỔI YÊU CẦU Ở CÁC SPRINT ......................... 49 HÌNH 15: MÔ HÌNH HÓA TRONG SCRUM VỚI KEEPS VÀ TEMPS .................................................................................. 50 HÌNH 16: CÁC KEEPS ARCHITECTURE BAO GỒM CÁC CLASS/PACKAGE DIAGRAM ...................................................... 51 HÌNH 17: CÁC KEEPS DOMAIN MODEL BAO GỒM CÁC CLASS DIAGRAM ..................................................................... 52 HÌNH 18: CÁC KEY USE CASE BAO GỒM CÁC USE CASE DIAGRAM .............................................................................. 53 HÌNH 19: CÁC KEY USE CASE BAO GỒM CÁC COMMUNICATION DIAGRAM .................................................................. 53 HÌNH 20: TIGER TEAM VÀ SUB TEAMS ........................................................................................................................... 54 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 ..................... 55 HÌNH 22: KEEP PACKAGE DIAGRAM CHO YÊU CẦU CHỨC NĂNG VÀ PHI CHỨC NĂNG ................................................... 68 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 ................ 71 HÌNH 24: KEEP PACKAGE DIAGRAM CHO YÊU CẦU CHỨC NĂNG CHUNG CỦA HỆ THỐNG ............................................. 71 HÌNH 25: KEEP PACKAGE DIAGRAM CHO YÊU CẦU PHI CHỨC NĂNG ............................................................................ 72 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 ......... 73 HÌNH 27: MÔ HÌNH KIẾN TRÚC LOGIC ............................................................................................................................ 74 HÌNH 28: KEEP NETWORK DIAGRAM KIẾN TRÚC VẬT LÝ CỦA HỆ THỐNG .................................................................... 75 HÌNH 29: KEEP PACKAGE DIAGRAM CHO TÁC NHÂN THAM GIA HỆ THỐNG .................................................................. 75 HÌNH 30: KEEP PACKAGE DIAGRAM CHO CÁC USE CASE QUẢN TRỊ HỆ THỐNG .......................................................... 77 HÌNH 31: KEEP PACKAGE DIAGRAM CHO CÁC USE CASE QUẢN LÝ QUYỀN NGƯỜI DÙNG ........................................... 78

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

MỞ ĐẦU

Ngành công nghệ phần mềm hình thành và phát triển được hơn nửa thế kỉ, tuy nhiên quá

trình phát triển và quản trị các dự án phần mềm chưa bao giờ hết thách thức và một trong

số đó là các vấn đề liên quan tới kỹ nghệ yêu cầu phần mềm. Việc hiểu sai yêu cầu, khó

thích nghi với các thay đổi hoặc không đồng bộ các thông tin đầu vào của dự án gây ảnh hưởng sống còn tới chất lượng sản phẩm cũng như tiến độ bàn giao.

Cá nhân tôi thời gian đầu của quá trình học và tham gia các dự án, tôi được tiếp cận với quy trình phát triển phần mềm truyền thống Waterfall, các dự án được lập kế hoạch cẩn thận,

được tiến hành với rất nhiều khâu trung gian, và thông thường khách hàng sẽ phải chờ đợi

cho tới khi hệ thống phần mềm hoàn thiện cơ bản. Các bên liên quan hầu như chỉ nhận được tài liệu dự án mà không được dùng thử, trải nghiệm và đưa ra các phản hồi cho các chức

năng đã hoàn thành. Việc không nắm được tiến độ các chức năng khiến khách hàng và các

bên liên quan tỏ ra sốt ruột, lo lắng và qua thời gian họ mất dần sự quan tâm tới dự án, và

kết quả tất yếu với hầu hết các dự án mới có nhiều yêu cầu nghiệp vụ đặc thù hoặc phải đấu

nối phức tạp thì sản phẩm bàn giao tới người dùng cuối là không đạt yêu cầu hoặc gặp rất

nhiều khó khăn trong quá trình tích hợp hoặc vận hành không ổn định.

Các dự án của những năm sau đấy, tôi được tiếp cận với phương pháp phát triển phầm mềm

Agile, cụ thể là Scrum và Kanban, ở một số dự án gần đây, nhóm phát triển phần mềm

chúng tôi sử dụng Scrumban. Sự thay đổi có thể dễ dàng nhận thấy giữa một dự án Waterfall

và dự án Agile là với Agile, chúng tôi phải tổ chức rất nhiều các cuộc họp, bao gồm các

cuộc họp nội bộ nhóm phát triển và các cuộc họp với các bên liên quan. Quá trình này lặp

đi lặp lại qua các Sprint nhằm thúc đẩy sự phát triển mối quan hệ bền vững giữa ban lãnh

đạo, các thành viên đội phát triển và người dùng. Việc duy trì một nhịp độ liên tục không giới hạn các buổi họp này giúp chúng tôi và các bên liên quan có chung một tầm nhìn về sản phẩm. Trong thời gian này tôi vẫn chưa dành nhiều công sức để nghiên cứu kỹ về lý

thuyết Agile, tôi chỉ tiếp cận nó theo một quy trình làm việc đã được tổ chức bởi Scrum Mater, nhưng tôi vẫn dễ dàng nhận ra được giá trị từ việc áp dụng Agile thông qua chất lượng sản phẩm và mức độ hài lòng của khách hàng qua từng dự án. Vì vậy tôi mong muốn qua luận văn này sẽ nghiên cứu sâu hơn phương pháp luận Agile và các thay đổi có giá trị mà nó tạo ra tới kỹ nghệ yêu cầu cũng như các thay đổi trong quy trình phát triển phần mềm.

Chương 1. Giới thiệu

1.1. Mục đích và ý nghĩa của đề tài

Ứng dụng khoa học, công nghệ vào việc nâng cao chất lượng giảng dạy các loại hình văn

hóa nghệ thuật là một trong những mục tiêu góp phần bảo tồn và phát huy các di sản văn

hóa phi vật thể trước xu thế toàn cầu hóa và hội nhập như hiện nay. Trên thực tế đã có nhiều

hệ thống phần mềm được xây dựng và áp dụng trong các trường Đại học khối Văn hóa Nghệ thuật nhưng vẫn tồn tại những hạn chế như không thỏa mãn đầy đủ các yêu cầu giảng

dạy và học tập hoặc vượt quá ngân sách và thời gian. Một trong những nguyên nhân chính

là các dự án không đầu tư thời gian và công sức ở khâu phân tích, thiết kế mà bắt tay vào

lập trình quá sớm. Việc không nắm rõ các yêu cầu của các bên liên quan hoặc thiếu các

phương pháp khoa học và yếu kém ở khả năng mô hình hóa các khối chức năng sẽ dẫn đến

việc xây dựng một hệ thống không đạt được các mục tiêu của dự án hoặc không như mong

đợi của người sử dụng.

Tôi đã từng đảm nhiệm các vai trò khác nhau trong nhóm phát triển phần mềm vì vậy tôi

muốn xây dựng cho mình các kỹ năng để trở thành một Chủ sản phẩm (Product Owner)

bằng việc củng cố phương pháp luận về kỹ nghệ yêu cầu cũng như kỹ năng thiết kế hệ

thống và cách thức tổ chức một dự án Agile phù hợp.

Trong luận văn này, mục tiêu thứ nhất tôi cần trình bày được các phương pháp quản lý yêu

cầu người dùng bao gồm việc thu thập, quản lý các yêu cầu người dùng và áp dụng các kiến

thức này trong quá trình quản lý các yêu cầu đầu vào trong dự án Scrum.

Song song với kỹ năng quản lý yêu cầu người dùng, mục tiêu thứ hai tôi cần trình bày được

phương pháp mô hình hóa trực quan và áp dụng hiểu quả phương pháp này trong dự án Scrum nhằm giúp các thành viên đội dự án hoặc khách hàng hiểu về hệ thống và giao tiếp

với nhau một cách logic có khoa học. Tôi cũng cần áp dụng kiến thức này vào quá trình xây dựng các biểu đồ kỹ thuật và các tài liệu đặc tả.

Sau quá trình phân tích yêu cầu ban đầu tôi xem xét việc sử dụng một Open Source Framework làm nền tảng để xây dựng hệ thống quản trị nội dung nhằm giúp giảm thiểu thời gian và nỗ lực của nhóm nghiên cứu đối với các yêu cầu của một hệ thống E-Learning thông thường, mặt khác phải là một framework đã trưởng thành, hoạt động ổn định và có

kiến trúc tốt nhằm đảm bảo quá trình phát triển tuân thủ các chuẩn và dễ dàng tích hợp, mở

rộng trong tương lai.

1.2. Đối tượng và phạm vi nghiên cứu

Quá trình nghiên cứu và xây dựng luận văn được tiến hành song song cùng quá trình thực

hiện dự án Xây dựng Hệ thống phần mềm hỗ trợ giảng dạy theo mô hình “vai mẫu” đối với

kịch hát dân tộc.

Các khâu trong quá trình phân tích, thiết kế bao gồm: Làm việc với các bên liên quan; Quản

lý yêu cầu; Theo dõi tiến độ thực hiện dự án; Tìm hiểu môi trường triển khai dự án; Tìm hiểu các hoạt động quản lý đào tạo, hoạt động dạy và học tại trường cho tới thời điểm hiệu

tại và đề xuất các khâu có thể cải tiến; đều được tôi cùng nhóm nghiên cứu thực hiện đề tài

khoa học công nghệ trường Đại học Công nghệ - Đại học Quốc Gia Hà Nội thảo luận cùng

với đại diện người dùng tại Trường Đại học Sân khấu Điện ảnh Hà Nội.

Các bước đều được thực hiện theo quy trình của các phương pháp và mô hình tôi đang

nghiên cứu dựa trên sự phối hợp và thống nhất chặt chẽ cùng đại diện khách hàng cũng như

người dùng cuối.

1.3. Phương pháp nghiên cứu

Trong quá trình xây dựng luận văn tôi sử dụng các phương pháp nghiên cứu sau:

1.3.1. Phương pháp nghiên cứu Lý thuyết

Là các phương pháp thu thập thông tin khoa học trên cơ sở nghiên cứu các văn bản, tài liệu đã có và bằng các thao tác tư duy logic để rút ra kết luận khoa học cần thiết.

Phương pháp phân loại và hệ thống hóa lý thuyết: Phân loại là sắp xếp các tài liệu khoa học theo từng mặt, từng đơn vị, từng vấn đề có cùng dấu hiệu bản chất, cùng một hướng phát triển. Hệ thống hóa là sắp xếp tri thức thành một hệ thống trên cơ sở một mô hình lý thuyết làm sự hiểu biết về đối tượng đầy đủ hơn.

Phương pháp Mô hình hóa: Là phương pháp nghiên cứu các đối tượng bằng cách xây

dựng mô hình gần giống với đối tượng, tái hiện lại đối tượng theo các cơ cấu, chức năng

của đối tượng.

1.3.2. Phương pháp nghiên cứu Thực nghiệm

Là các phương pháp tác động trực tiếp vào đối tượng có trong thực tiễn để làm rõ bản chất

và các quy luật của đối tượng.

Phương pháp phân tích tổng kết kinh nghiệm: Là phương pháp nghiên cứu và xem xét

lại những thành quả thực tiễn trong quá khứ để rút ra kết luận bổ ích cho thực tiễn và khoa

học.

Phương pháp thực nghiệm khoa học: Là phương pháp mà các nhà nghiên cứu chủ động

tác động vào đối tượng và theo dõi quá trình diễn biến sự kiện mà đối tượng tham gia để

hướng sự phát triển của chúng theo mục tiêu dự kiến của mình.

1.4. Cấu trúc luận văn

“Chương 1: Giới thiệu”, trình bày nội dung dự án “Xây dựng Hệ thống phần mềm hỗ trợ

giảng dạy theo mô hình “Vai mẫu” đối với kịch hát dân tộc”, trong dự án này tôi đã áp dụng các kiến thức về Kỹ nghệ yêu cầu, và phương pháp Agile là hướng tôi lựa chọn để xây dựng

luận văn này.

“Chương 2: Cơ Sở Lý Thuyết”, trình bày lý thuyết Yêu cầu người dùng và các vấn đề

ảnh hưởng tới quá trình thu thập yêu cầu. Tiếp theo là lý thuyết Kỹ nghệ yêu cầu truyền thống trong các mô hình Xã hội – Kỹ thuật. Sau đó tôi tập trung nói về Kỹ nghệ yêu cầu

được hệ thống và sử dụng trong phương pháp Agile Scrum. Cuối cùng tôi trình bày cách

thức áp dụng các kỹ thuật mô hình hóa UML trong các dự án Agile.

“Chương 3: Phương pháp thu thập yêu cầu”, trình bày kỹ thuật tiếp cận các Bên liên

quan nhằm thu thập yêu cầu. Sau đó tôi liệt kê các Epic, Product Backlog và các User Story

thu được sau các buổi trò chuyện, các cuộc họp với các Bên liên quan hoặc với nhóm phát

triển. Tôi cũng đưa ra ví dụ về Scrum Taskboard và bảng Kanban thu được ở một thời điểm

cụ thể trong quá trình thực hiện Sprint.

“Chương 4: Phân tích & Thiết kế Hệ thống” là kết quả của quá trình xây dựng tài liệu

dự án bao gồm: 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 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. Sau đấy tôi triển

khai nhanh các thiết kế thông qua việc xây dựng các prototype nhằm thu thập phản hồi từ

người dùng.

Cuối cùng là kết luận sau quá trình nghiên cứu, xây dựng luận văn và áp dụng các kiến thức này vào dự án.

Chương 2. Cơ Sở Lý Thuyết

Công nghệ đóng vai trò cầu nối trong mối quan hệ giữa người sử dụng và máy tính, nó được

sử dụng trong một ngữ cảnh cụ thể và bị ảnh hưởng bởi nhiều yếu tố trong ngữ cảnh đó.

Việc xác định các yếu tố này giúp người thiết kế cũng như nhóm phát triển xây dựng các

hệ thống công nghệ phần mềm phù hợp với tổ chức, đáp ứng được các yêu cầu của tổ chức đó.

Dựa trên các phương pháp phân tích, người thiết kế hệ thống cần xác định những người khác nhau bị ảnh hưởng bởi việc triển khai một hệ thống hay được gọi là các bên liên quan.

Nhu cầu của các bên liên quan là khác nhau và có thể phức tạp và mâu thuẫn vì vậy cần hệ

thống hoá chức năng thông qua việc sử dụng quy trình và phương pháp khoa học để đảm bảo tính hiệu quả, tính thực tiễn của hệ thống.

Chúng ta sẽ nghiên cứu kỹ hơn về bối cảnh sử dụng của tổ chức và thảo luận một số vấn đề

chung có thể ảnh hưởng đến việc chấp nhận công nghệ trong các tổ chức. Sau đó chúng ta

xem xét một số cách tiếp cận để mô hình hóa bối cảnh xã hội - tổ chức và yêu cầu của các

bên liên quan trong đó.

Thu thập yêu cầu là một phần quan trọng của tất cả các phương pháp kỹ thuật phần mềm

nhưng thường hoạt động này tập trung chủ yếu vào các yêu cầu chức năng của hệ thống -

những gì hệ thống phải có khả năng làm được - ít nhấn mạnh vào các vấn đề về con người,

các vấn đề phi chức năng như tính khả dụng và mức độ chấp nhận được, … Ngay cả khi

những vấn đề này được xem xét, chúng chỉ có thể phản ánh quan điểm của người quản lý

về nhu cầu của người dùng hơn là thu thập thông tin từ người dùng. Các mô hình yêu cầu

của các bên liên quan được xây dựng để đảm bảo sự cân bằng trong quá trình xây dựng yêu

cầu chức năng và yêu cầu phi chức năng bằng cách xác định nhu cầu của tất cả các bên liên quan, bao gồm cả người sử dụng và bất cứ ai khác bị ảnh hưởng bởi hệ thống, đặt trong bối cảnh mà hệ thống sẽ được sử dụng.

Tôi bắt đầu chương này bằng việc trình bày các khái niệm cơ bản về yêu cầu người dùng sau đó thảo luận về một số vấn đề phát sinh trong tổ chức khi áp dụng các giải pháp công nghệ mới. Tiếp đến tôi phác thảo một số mô hình và phương pháp có thể được sử dụng để nắm bắt quan điểm rộng hơn về yêu cầu của các bên liên quan, bao gồm các mô hình xã hội – kỹ thuật (Socio-Technical models), phương pháp các hệ thống mềm (Soft Systems

Methodology), thiết kế hợp tác (Participatory Design) và phương pháp nhân chủng học

(Ethonographic Approach).

Trọng tâm của luận văn này tôi tập trung tìm hiểu về quy trình xử lý yêu cầu người dùng

bằng phương pháp Agile Scrum kết hợp hiệu quả các công cụ mô hình hoá trong UML.

2.1. Yêu cầu

Trong các ngành kỹ thuật, một yêu cầu (Requirement) là một đòi hỏi được tài liệu hóa về

các chức năng và đặc điểm của một sản phẩm hoặc dịch vụ. Thuật ngữ này thường được

dùng trong các ngành kỹ nghệ hệ thống và kỹ nghệ phần mềm.

Trong cách tiếp cận truyền thống của ngành kỹ nghệ, các tập yêu cầu được dùng làm đầu

vào cho các giai đoạn thiết kết trong quá trình phát triển sản phẩm.

Pha phát triển các yêu cầu có thể được thực hiện sau một nghiên cứu tiền khả thi (Feasibility

Study), hoặc một pha phân tích khái niệm của dự án. Pha yêu cầu có thể được chia thành

các phần: thu thập yêu cầu (từ những người có vai trò quan trọng đối với sản phẩm/dịch

vụ), phân tích yêu cầu (kiểm tra tính nhất quán và hoàn chỉnh), định nghĩa yêu cầu (viết các

yêu cầu mang tính mô tả dành cho các nhà phát triển), và đặc tả (tạo cầu nối đầu tiên giữa các yêu cầu và thiết kế).

2.1.1. Yêu cầu trong kỹ nghệ hệ thống và kỹ nghệ phần mềm

Có ba loại yêu cầu: yêu cầu chức năng, yêu cầu phi chức năng (hay yêu cầu hiệu năng hoặc

yêu cầu chất lượng dịch vụ), và mục tiêu thiết kế.

Yêu cầu chức năng mô tả xem hệ thống phải làm gì, nghĩa là hệ thống phải có khả năng thực hiện những công việc gì. Ví dụ: "Hệ thống cần lưu trữ tất cả chi tiết về đơn đặt hàng

của khách hàng".

Yêu cầu phi chức năng là các ràng buộc về các loại giải pháp thỏa mãn các yêu cầu chức năng. Các yêu cầu này mô tả về chính hệ thống, và về việc nó cần thực hiện các chức năng của mình tốt đến mức độ nào, chẳng hạn yêu cầu loại này là yêu cầu về tính sẵn có, khả năng kiểm thử, khả năng bảo trì, và tính dễ sử dụng. Có thể chia các yêu cầu phi chức năng thành hai loại:

1. Ràng buộc về hiệu năng: chẳng hạn "hệ thống cần phục vụ liên tục từ 5 giờ sáng đến

9 giờ tối.", "mỗi đơn đặt hàng cần được lưu trữ trong tối thiểu 7 năm".

2. Ràng buộc về quá trình phát triển hệ thống: Thời gian, tài nguyên, chất lượng. Ví dụ: khi nào hệ thống cần hoàn thành (thời gian); tổng chi phí cho phát triển hệ thống (tài nguyên); cần áp dụng các tiêu chuẩn nào cho quá trình phát triển hệ thống, trong

đó có các phương pháp quản lý dự án và phát triển hệ thống (chất lượng).

Mục tiêu thiết kế là các hướng dẫn cho việc lựa chọn giải pháp. Có nhiều tính năng quan

trọng đối với một hệ thống, nhưng nhiều trường hợp không thể có giải pháp đạt được mọi tính năng ở mức tối ưu. Do đó cần có một thứ tự ưu tiên, tính năng nào cần được ưu tiên

hơn tính năng nào. Nếu khách hàng không mô tả thứ tự ưu tiên, nhà phát triển phần mềm

sẽ tự chọn thứ tự và thứ tự này có thể không phải cái mà khách hàng mong muốn.

Một tập hợp các yêu cầu định nghĩa các tính chất hay tính năng của hệ thống cần xây dựng.

Một danh sách yêu cầu 'tốt' thường tránh nói đến chuyện hệ thống cần thi hành các yêu

cầu bằng cách nào, mà để các quyết định dạng này cho người thiết kế hệ thống. Việc mô

tả cách cài đặt hệ thống được gọi là thiên kiến cài đặt (Implementation Bias).

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

Việc trình bày các yêu cầu ở một cách lý tưởng là rất khó. Người dùng khó hình dung được

hết những thông tin nào là cần thiết cho các nhà phát triển, và hai bên có thể không thực sự

hiểu các cách diễn đạt của nhau. Thông thường, người ta thuê Người dùng chuyên

gia (Expert User) làm cầu nối giữa người dùng và các nhà phát triển. Những người dùng

chuyên gia này có thể biểu đạt các yêu cầu chức năng sao cho chúng có thể dễ chuyển thành

một tính năng thiết kế của hệ thống, trong khi người dùng cuối (End User) vẫn hiểu được.

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

 Cần thiết – Cái cần phải nhắc đến nếu không hệ thống sẽ thiếu một phần tử quan

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

 Không mù mờ đa nghĩa – Chỉ có một cách hiểu  Ngắn gọn súc tích – Được diễn đạt bằng ngôn ngữ mô tả ngắn gọn và dễ hiểu, trong

trọng mà không một thành phần nào khác của hệ thống có thể bù lại được.

khi vẫn truyền đạt được nội dung cốt yếu của yêu cầu

 Nhất quán – Không mâu thuẫn với một yêu cầu khác; các yêu cầu sử dụng cùng hệ

 Hoàn chỉnh – Các nội dung được trình bày đầy đủ tại chỗ để người đọc không phải

thống ngôn ngữ và thuật ngữ cho các khái niệm.

 Đạt được – Một khối lượng thực tiễn có thể được thực hiện trong lượng tiền/tài

xem thêm tài liệu khác để có thể hiểu được nội dung của yêu cầu.

 Kiểm thử được – Phải có khả năng xác định xem yêu cầu đã được thỏa mãn hay

nguyên/thời gian có được

chưa bằng một trong 4 phương pháp duyệt (inspection), phân tích, trình diễn, hoặc kiểm thử (test).

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

Hầu hết các yêu cầu cần có khả năng kiểm thử được. Nếu không, phải sử dụng một phương

pháp kiểm định khác (ví dụ phân tích, duyệt lại thiết kế). Các yêu cầu kiểm thử được là một thành phần quan trọng của việc kiểm định (Validation).

Một số yêu cầu không thể kiểm thử được do chính cấu trúc của nó. Trong đó có các yêu

cầu nói rằng hệ thống cần luôn luôn hay không bao giờ thể hiện một tính chất nào đó. Việc

kiểm thử thích đáng cho các yêu cầu này sẽ cần đến một chu trình kiểm thử vô hạn. Những

yêu cầu như vậy cần được viết lại để nói về một khoảng thời gian có tính thực tế hơn.

Các yêu cầu phi chức năng không kiểm thử được có thể vẫn được giữ để làm tài liệu về chủ

ý của khách hàng; tuy nhiên, chúng thường dẫn đến các yêu cầu quy trình mà chúng được

xác định là một phương pháp thực tiễn cho việc thỏa mãn yêu cầu ban đầu. Ví dụ, một yêu

cầu phi chức năng rằng không được có các Backdoor có thể được thỏa mãn bằng cách thay

nó bằng một yêu cầu quy trình rằng cần sử dụng phương pháp lập trình cặp (Pair

Programming).

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

Theo thời gian, các yêu cầu có thể thay đổi. Trong trường hợp này, một khi đã được xác định và thông qua, các yêu cầu cần được đưa vào quy trình Kiểm soát thay đổi (Change Control). Với nhiều dự án, một số yêu cầu được thay đổi trước khi hệ thống được hoàn

thiện. Đặc tính này của các yêu cầu đã dẫn đến các nghiên cứu và thực hành về quản lý yêu cầu (Requirements Management).

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

Một số phương pháp luận Kỹ nghệ phần mềm hiện đại, chẳng hạn như Lập trình cực đoan (Extreme Programming), đã nghi ngờ sự cần thiết của các yêu cầu phần mềm được mô tả

chính xác - cái mà các phương pháp luận này coi là một cái đích di động. Thay vào đó, họ

mô tả các yêu cầu một cách phi hình thức bằng các "Câu chuyện người dùng" hay User

Story (Yêu cầu được viết ngắn gọn trong một cái thẻ nhỏ với nội dung giải thích một khía cạnh của những gì mà hệ thống cần làm), và tạo một chuỗi các trường hợp kiểm thử chấp

nhận (Acceptance Test Case) cho User Story này.

2.2. Phân tích yêu cầu

Phân tích yêu cầu là việc xác định các yêu cầu cho một hệ thống mới hoặc hệ thống đã triển

khai dựa trên các để xuất, mong muốn của những người có vai trò quan trọng đối với hệ

thống, chẳng hạn người sử dụng đưa ra. Việc phân tích yêu cầu có ý nghĩa quan trọng đối

với thành công của một dự án.

Quá trình phân tích yêu cầu một cách có hệ thống còn được gọi là kỹ nghệ yêu cầu (Requirements Engineering). Đôi khi nó còn được gọi một cách không thật chính xác

bằng những cái tên như thu thập yêu cầu (Requirements Gathering, Requirements Capture),

hoặc đặc tả yêu cầu (Requirements Specification). Thuật ngữ "phân tích yêu cầu" còn được

áp dụng cụ thể cho công việc thuần túy phân tích (thay vì các việc khác chẳng hạn như làm

rõ yêu cầu hay viết tài liệu yêu cầu).

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

Về khái niệm, việc phân tích yêu cầu bao gồm ba loại hoạt động sau:

Làm rõ yêu cầu (Eliciting Requirements): Giao tiếp với khách hàng và người sử dụng để

xác định các yêu cầu của họ.

Xem xét yêu cầu (Analyzing Requirements): Xác định xem các yêu cầu được đặt ra có ở tình trạng không rõ ràng, không hoàn chỉnh, đa nghĩa, hoặc mâu thuẫn hay không, và giải quyết các vấn đề đó.

Làm tài liệu yêu cầu (Recording Requirements): Các yêu cầu có thể được ghi lại theo

nhiều hình thức, chẳng hạn các tài liệu ngôn ngữ tự nhiên, các Tình huống sử dụng (Use

Case), Câu chuyện người dùng (User Story), hoặc các đặc tả tiến trình.

Pha phân tích yêu cầu có thể là một quá trình dài và khó khăn, cần đến nhiều kĩ năng tâm lý khéo léo. Các hệ thống mới làm thay đổi môi trường và các mối quan hệ giữa con người,

do đó điều quan trọng là phải xác định được tất cả những người có vai trò quan trọng, xem

xét tất cả các nhu cầu của họ và đảm bảo rằng họ hiểu được các hàm ý của hệ thống mới.

Các nhà phân tích có thể sử dụng một số kĩ thuật để làm rõ các yêu cầu của khách hàng. Trong lịch sử, các kỹ thuật này bao gồm các cuộc phỏng vấn, thành lập các Nhóm trọng

tâm (Focus Group) với các cuộc họp bàn về yêu cầu (Requirements Workshops), và tạo ra

các danh sách yêu cầu. Các kỹ thuật hiện đại hơn gồm có Tạo nguyên mẫu (Prototyping),

và Tình huống sử dụng (Use Case). Khi cần thiết, nhà phân tích sẽ kết hợp các phương

pháp này để thiết lập các yêu cầu chính xác của những người có vai trò quan trọng, nhằm

mục đích xây dựng một hệ thống thỏa mãn các yêu cầu doanh nghiệp.

2.2.2. Các vấn đề

2.2.2.1. Vấn đề về người dùng và khách hàng

Trong cuốn Rapid Development, Steve McConnell đã liệt kê một loạt các khả năng người

dùng có thể cản trở quá trình thu thập yêu cầu:

1. Người dùng không hiểu họ muốn gì 2. Người dùng không tuân theo một bộ yêu cầu đã được tài liệu hóa 3. Người dùng nhất định đòi hỏi các yêu cầu mới sau khi chi phí và kế hoạch phát triển

đã được hoạch định xong.

4. Mức độ giao tiếp với người dùng là thấp 5. Người dùng thường không tham gia các đợt thẩm định hoặc không thể tham gia. 6. Người dùng không hiểu kỹ thuật 7. Người dùng không hiểu quy trình phát triển.

Những điều này có thể dẫn tới tình huống khi yêu cầu người dùng liên tục thay đổi ngay cả khi việc phát triển hệ thống hay sản phẩm đã được bắt đầu.

2.2.2.2. Vấn đề về kỹ sư – nhà phát triển

Trong quá trình phân tích yêu cầu, các vấn đề sau có thể nảy sinh từ phía các kỹ sư và nhà phát triển.

Nhân viên kỹ thuật và người dùng cuối có thể có ngôn từ khác nhau. Kết quả là họ có thể

tin rằng họ hoàn toàn đồng thuận cho đến khi sản phẩm hoàn thiện được đưa ra.

Các kỹ sư và nhà phát triển có thể cố lái cho các yêu cầu khớp với một hệ thống hay mô hình sẵn có, thay vì phát triển một hệ thống theo sát nhu cầu của khách hàng

Việc phân tích có thể do các kỹ sư hoặc lập trình viên thực hiện, thay vì các nhân viên có

kỹ năng và kiến thức miền ứng dụng để có thể hiểu các nhu cầu của khách hàng một cách

đúng đắn

2.2.2.3. Vấn đề về tổ chức

Vấn đề mang tính tổ chức nhưng ảnh hưởng trực tiếp đến quá trình xây dựng hệ thống thông

tin cho tổ chức đó. Những yếu tố này thông thường bắt nguồn từ chức năng của hệ thống

và có thể liên quan đến những cá nhân không bao giờ sử dụng nó nhưng họ thường lại là

những tác nhân quyết định sự thành công hay thất bại của hệ thống phần mềm.

1. Sự không hợp tác từ người dùng cuối là người không ra quyết định cho việc áp dụng

hệ thống phần mềm vào tổ chức.

2. Phần mềm làm ảnh hưởng tới quyền hạn và quyền lợi của một hoặc nhiều các bên

liên quan.

3. Phần mềm xử lý cứng nhắc các quy trình nghiệp vụ mà tổ chức đang vận hành 4. Chi phí phải trả và lợi ích đạt được khi sử dụng phần mềm là không tương xứng

2.2.3. Các giải pháp

Một giải pháp đối với các vấn đề về giao tiếp là thuê các chuyên gia về doanh nghiệp hoặc chuyên gia phân tích hệ thống.

Các kỹ thuật được đưa ra trong thập kỉ 1990 như Tạo nguyên mẫu

(Prototyping), UML, Tình huống sử dụng (Use Case) và Phát triền phầm mềm linh hoạt (Agile software development) cũng đã được dùng làm giải pháp cho các vấn đề trên.

2.3. Kỹ nghệ yêu cầu truyền thống

Như chúng ta đã thấy, những vấn đề có thể xuất hiện khi một hệ thống được xây dựng mà

không có sự hiểu biết đầy đủ về tất cả những người sẽ bị ảnh hưởng bởi nó. Nhưng làm thế nào chúng ta có thể hiểu rõ hơn và hỗ trợ các tổ chức có cấu trúc phức tạp, khi các nhóm

làm việc và các nhu cầu của bên liên quan có khả năng mâu thuẫn lẫn nhau? Chúng ta bắt

đầu bằng cách thu thập và phân tích các yêu cầu, nhưng chúng ta cần phải làm việc này

trong hoàn cảnh mà các công việc của tổ chức vẫn đang diễn ra, có tính đến sự phức tạp của các mối quan tâm của các bên liên quan khác nhau và các cấu trúc và quy trình hoạt

động trong các nhóm làm việc.

Phần tiếp theo trình bày một số phương pháp tiếp cận: Mô hình kỹ thuật-xã hội (Socio-

Technical Modeling), phương pháp các hệ thống mềm (Soft Systems Methodology), thiết

kế hợp tác (Participatory Design), phương pháp nhân chủng học (Ethnographic Methods)

và điều tra theo ngữ cảnh (Contextual Inquiry). Các phương pháp này có hướng tiếp cận

hơi khác nhau cho cùng một vấn đề nhưng đều nhằm mục đích để hiểu được thực tế của bối

cảnh công việc và quan điểm khác nhau của các bên liên quan. Các phương pháp này cũng

cho thấy công nghệ có thể được triển khai thành công chỉ khi nó được thực hiện với một sự

hiểu biết về bối cảnh sử dụng. Trước khi chúng ta xem xét chi tiết hơn những phương pháp

tiếp cận này, chúng ta cần làm rõ ý nghĩa của thuật ngữ "Các bên liên quan".

2.3.1. Bên liên quan

Hiểu được các bên liên quan là yếu tố then chốt để tiếp cận tối đa các yêu cầu, vì trong một

môi trường tổ chức, nó không chỉ đơn giản là người dùng cuối bị ảnh hưởng bởi việc giới

thiệu công nghệ mới. Bên liên quan có thể được định nghĩa là bất cứ ai bị ảnh hưởng bởi

sự thành công hay thất bại của hệ thống. Các nhóm bên liên quan theo cách tiếp cận CUSTOM là:

 Các bên liên quan chính là những người thực sự sử dụng hệ thống - những người

dùng cuối.

 Các bên liên quan thứ cấp là những người không trực tiếp sử dụng hệ thống, nhưng nhận được kết quả từ nó hoặc cung cấp đầu vào cho nó (ví dụ như ai đó nhận được

báo cáo do hệ thống sản xuất).

 Các bên liên quan cấp cao là những người không thuộc hai nhóm đầu tiên nhưng những người trực tiếp bị ảnh hưởng bởi sự thành công hay thất bại của hệ thống (ví

dụ giám đốc có lợi nhuận tăng hoặc giảm tùy thuộc vào sự thành công của hệ thống).

Tạo điều kiện thuận lợi cho các bên liên quan là những người có liên quan đến việc thiết kế, phát triển và bảo trì hệ thống. Mục tiêu của nhóm thiết kế là đáp ứng nhu cầu của càng

nhiều bên liên quan càng tốt. Tuy nhiên, thực tế là nhu cầu của các bên liên quan thường là

mâu thuẫn với nhau.

2.3.2. Các mô hình Xã hội – Kỹ thuật (Socio-technical models)

Các mô hình Xã hội – Kỹ thuật sử dụng các phương pháp khác nhau nhằm nắm bắt yếu tố như:

 Vấn đề được giải quyết: Cần phải hiểu tại sao công nghệ này lại được đề xuất và các

vấn đề nó có thể giải quyết.

 Các bên liên quan bị ảnh hưởng, bao gồm Chủ yếu (Primary), Thứ yếu (Secondary), Hạng thứ ba (Tertiary) và Thực hiện (Facilitating), cùng với mục đích và nhiệm vụ

của những bên liên quan này.

 Các nhóm làm việc trong tổ chức, cả chính thức và không chính thức.

 Các thay đổi hoặc chuyển đổi sẽ được hỗ trợ.

 Công nghệ được đề xuất và cách thức hoạt động trong tổ chức. Những khó khăn bên

ngoài, các ảnh hưởng và các biện pháp thực hiện.

Thông tin được thu thập bằng các phương pháp như phỏng vấn, quan sát và tổ chức các

cuộc họp giữa các bên và phân tích tài liệu. Các phương pháp hướng dẫn quá trình thu thập

thông tin này và giúp nhà phân tích hiểu được những yêu cầu cần thiết cho quá trình phát triển dự án. Bằng cách cố gắng hiểu những vấn đề này, phương pháp tiếp cận Xã hội – Kỹ

thuật nhằm cung cấp một cái nhìn chi tiết về vai trò của công nghệ và các yêu cầu của việc triển khai thành công.

Sau đây tôi trình bày hai phương pháp Xã hội – Kỹ thuật USTM và OSTA để minh họa cách thức nó hoạt động trong thực tế.

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

1. USTM

Phương pháp USTM được chia thành 7 giai đoạn (Stage):

1. Business Case: Một thành viên của nhóm có trách nhiệm đối với Business Case và

đưa ra sự luận giải ban đầu cho hệ thống được đề xuất.

2. Nhóm làm việc: Mục tiêu của giai đoạn này là xác định các nhóm làm việc có liên quan đến hệ thống đề xuất. Sản phẩm của nhóm làm việc phụ thuộc vào mối quan

hệ của họ với hệ thống, và lựa chọn một nhóm công việc chính và mô tả của nó một

cách chi tiết.

3. Người dùng: Một danh sách người dùng chung được tạo ra, người dùng được phân loại theo mối quan hệ của họ đối với hệ thống đề xuất. Ba bộ vấn đề được xác định:

quan điểm tổ chức của người dùng, các thuộc tính cá nhân của người dùng chung,

và ‘typical day in life’ của người dùng chung thời điểm hiện tại và khi triển khai hệ

thống đề xuất.

4. Đối tượng: Nhóm được yêu cầu xác định các đối tượng liên quan đến hệ thống đề xuất, phân loại họ theo mối quan hệ của họ với hệ thống và tạo ra các cấu trúc đối

tượng ban đầu. Thủ tục xác định danh sách các đối tượng bao gồm hai bước: cùng

nhau tạo ra một danh sách các đối tượng bằng cách động não và cùng đánh giá và

đồng thuật về danh sách các đối tượng được chọn.

5. Nhiệm vụ: Một nhiệm vụ được định nghĩa là một hành động được thực hiện bởi một người dùng chung trên một đối tượng. Một danh sách các nhiệm vụ được tạo ra, các

nhiệm vụ này được tích hợp vào một sơ đồ phân cấp và các mối quan hệ giữa nhiệm

vụ và hệ thống được xác định.

6. Tương tác: Mục đích của giai đoạn này là hiểu mối quan hệ giữa người dùng chung, đối tượng và nhiệm vụ và để xác định sự khác biệt giữa người dùng, đối tượng và

nhiệm vụ khác nhau. Các thuộc tính được liệt kê để ràng buộc hệ thống cần phải hỗ trợ chúng nhưng không nêu rõ công nghệ nào cần sử dụng vào thời điểm này. 7. Hợp nhất: Mục đích của giai đoạn này là đánh giá lại Business Case và đưa ra quyết định cho các hành động tiếp theo. Ngoài ra, chất lượng của thông tin thu thập cũng được xác định ở giai đoạn này.

2. CUSTOM

CUSTOM là một phương pháp luận Xã hội – Kỹ thuật được thiết kế để sử dụng trong các

tổ chức nhỏ. Nó dựa trên phương pháp User skills and Task Match (USTM), nó được phát

triển để cho phép các đội thiết kế hiểu và ghi chép đầy đủ các yêu cầu của người sử dụng.

CUSTOM tập trung vào việc thiết lập các yêu cầu của các bên liên quan: Tất cả các bên liên quan được xem xét, không chỉ những người dùng cuối.

Nó được áp dụng ở giai đoạn thiết kế ban đầu khi sản phẩm chưa hình thành và có thể đang

chỉ là một cơ hội, do đó, sự nó tập trung vào kỹ thuật nắm bắt yêu cầu. Nó là một phương

pháp dựa trên biểu mẫu, cung cấp một bộ câu hỏi để áp dụng ở từng giai đoạn của nó.

Có sáu giai đoạn chính của việc thực hiện trong một phân tích CUSTOM:

1. Mô tả bối cảnh tổ chức, bao gồm các mục tiêu chính, đặc tính vật lý, bối cảnh chính

trị và kinh tế.

2. Xác định và mô tả các bên liên quan. Tất cả các bên liên quan cần được đặt tên, phân loại (Chủ yếu (Primary), Thứ yếu (Secondary), Hạng thứ ba (Tertiary) hoặc Thực

hiện (Facilitating)) và được mô tả trong các vấn đề cá nhân, vai trò của họ trong tổ

chức và công việc của họ. Ví dụ, CUSTOM giải quyết các vấn đề như động lực của

các bên liên quan, giảm thiểu, kiến thức, kỹ năng, quyền hạn và ảnh hưởng trong tổ

chức, công việc hàng ngày và vân vân.

3. Xác định và mô tả các nhóm làm việc. Một nhóm làm việc là bất kỳ nhóm người nào làm việc cùng nhau trên cùng một nhiệm vụ dù chính thức hay không chính thức.

Một lần nữa, nhóm làm việc được mô tả về vai trò của họ trong tổ chức và đặc điểm

của họ.

4. Xác định và mô tả các cặp đối tượng-tác vụ (Task-Object Pairs). Đây là những tạc vụ (Task) cần phải được thực hiện, cùng với các đối tượng (Object) được sử dụng để thực hiện chúng hoặc chúng được áp dụng.

5. Xác định nhu cầu của các bên liên quan. Các giai đoạn 2-4 được mô tả dưới dạng hệ thống hiện tại và hệ thống được đề xuất. Nhu cầu của các bên liên quan được xác định bằng cách xem xét sự khác nhau giữa hai hệ thống này. Ví dụ, nếu một bên liên quan được xác định là hiện đang thiếu một kỹ năng cụ thể được yêu cầu trong hệ thống đề xuất hơn là một nhu cầu để đào tạo được xác định.

6. Hợp nhất và kiểm tra các yêu cầu của các bên liên quan. Ở đây danh sách các bên liên quan cần được kiểm tra dựa trên các tiêu chí được xác định ở giai đoạn đầu.

Các giai đoạn từ 2 đến 4 được mô tả dưới dạng tình hình hiện tại (trước khi áp dụng kỹ

thuật mới) và tình hình đề xuất (sau khi triển khai). Các bên liên quan được yêu cầu bày tỏ quan điểm của họ không chỉ về vai trò và vị trí hiện tại của họ mà còn về những mong đợi

của họ trong bối cảnh những thay đổi sẽ được thực hiện. Bằng cách này, các mối quan tâm

và mục tiêu của các bên liên quan được xây dựng. Ngoài ra, xem xét tác động của công

nghệ đối với thông lệ làm việc (Giai đoạn 3) và các chuyển đổi sẽ được hỗ trợ bởi hệ thống đã được xác định (Giai đoạn 4).

Những thay đổi từ vị trí hiện tại đến vị trí đề xuất đại diện cho các vấn đề cần được giải

quyết để đảm bảo triển khai thành công, và những điều này được trình bày rõ ràng trong

các giai đoạn 5 và 6.

CUSTOM cung cấp cách thức hữu ích để xem xét các yêu cầu của các bên liên quan bằng

việc sử dụng các form và câu hỏi làm cho công việc này trở nên dễ dàng hơn, nhưng có thể

mất thời gian ban đầu để áp dụng. Đối với các tình huống ít phức tạp hơn, có sẵn một phiên

bản rút gọn của quá trình phân tích các bên liên quan CUSTOM. Phiên bản này cũng cung

Phiên bản rút gọn của CUSTOM phân tích các bên liên quan

cấp checklist cho các cuộc điều tra cho giai đoạn 2-4.

Câu hỏi CUSTOM điều tra một loạt các đặc điểm của các bên liên quan, như sau:

 Các bên liên quan phải đạt được những gì và làm thế nào để đo lường thành công?

 Các nguồn thu hút sự quan tâm của các bên liên quan là gì? Những nguồn gốc của

sự không hài lòng và căng thẳng?

 Người có liên quan có kiến thức và kỹ năng gì?

 Thái độ của các bên liên quan đối với công việc là như thế nào và công nghệ máy

tính là gì?

 Có bất kỳ thuộc tính làm việc nhóm (workgroup) nào của các bên liên quan ảnh

hưởng đến khả năng chấp nhận của sản phẩm không?

 Các đặc điểm về nhiệm vụ của các bên liên quan như tần suất làm việc, phân chia

công việc, và các lựa chọn thực hiện công việc?

 Người có liên quan phải xem xét các vấn đề cụ thể liên quan đến tính trách nhiệm,

tính bảo mật hay tính riêng tư?

 Các điều kiện vật lý mà bên liên quan đang làm việc là gì?

2.3.2.2. Open System Task Analysis (OSTA)

OSTA là một phương pháp tiếp cận Xã hội – Kỹ thuật khác nhằm mô tả những gì xảy ra

khi một hệ thống kỹ thuật được đưa vào môi trường làm việc có tổ chức. Giống như

CUSTOM, OSTA chỉ rõ khía cạnh xã hội và kỹ thuật của hệ thống. Tuy nhiên, trong khi CUSTOM các khía cạnh này được các nhà phân tích giới hạn trong quan điểm của các bên

liên quan thì trong OSTA họ lại nắm bắt thông qua việc tập trung vào các nhiệm vụ.

OSTA có tám giai đoạn chính:

 Nhiệm vụ chính mà công nghệ phải hỗ trợ được xác định theo mục tiêu của người

sử dụng.

 Nhiệm vụ đầu vào cho hệ thống được xác định. Đây có thể có các nguồn và hình

thức khác nhau mà có thể hạn chế thiết kế.

 Môi trường bên ngoài mà hệ thống này sẽ được giới thiệu bao gồm các khía cạnh

vật lý, kinh tế và chính trị.

 Các quá trình chuyển đổi trong hệ thống được mô tả bằng các hành động được thực

hiện trên các đối tượng hoặc cùng với các đối tượng.

 Hệ thống xã hội được phân tích, xem xét các nhóm làm việc hiện tại và các mối quan

hệ trong và ngoài tổ chức.

 Hệ thống kỹ thuật được mô tả dưới dạng cấu hình và tích hợp với các hệ thống khác.

 Các tiêu chí về sự hài lòng về hiệu quả hoạt động được xác lập, cho thấy các yêu cầu

xã hội và kỹ thuật của hệ thống.

 Hệ thống kỹ thuật mới được xác định.

OSTA sử dụng các ký hiệu quen thuộc với các nhà thiết kế, chẳng hạn như sơ đồ luồng dữ liệu và mô tả văn bản.

2.3.3. Phương pháp các hệ thống mềm

Phương pháp các hệ thống mềm (Soft Systems Methodology - SSM) cũng phát sinh trong cùng bối cảnh của phương pháp Mô hình Xã hội – Kỹ thuật nhưng nhìn nhận tổ chức như

là một hệ thống trong đó công nghệ và con người là thành phần. SSM có bảy giai đoạn và

có một sự phân biệt giữa các giai đoạn “Thế giới thực” (1-2, 5-7) và các giai đoạn của hệ

Hình 1: 7 giai đoạn của phương pháp truyền thống các hệ thống mềm

thống (3-4).

2.3.4. Phương pháp Thiết kế hợp tác (Participatory Design)

Thiết kế hợp tác là một triết lý bao gồm toàn bộ chu trình thiết kế. Đó là thiết kế tại nơi làm việc, nơi mà người sử dụng tham gia không chỉ là một người cung cấp các thông tin khi cần

thiết mà còn là một thành viên của đội thiết kế. Người dùng vì vậy là những người cộng tác tích cực trong quá trình thiết kế chứ không phải là những người tham gia thụ động mà sự tham gia của họ hoàn toàn do nhà thiết kế chi phối. Lập luận rằng người sử dụng là chuyên gia trong bối cảnh công việc và một thiết kế chỉ có thể có hiệu quả trong bối cảnh đó nếu các chuyên gia này được phép đóng góp tích cực vào quá trình thiết kế. Ngoài ra, việc giới

thiệu một hệ thống mới có thể thay đổi bối cảnh công việc và quy trình tổ chức và sẽ chỉ được chấp nhận nếu những thay đổi này được chấp nhận bởi người dùng. Thiết kế hợp tác

do đó nhằm mục đích tinh chỉnh các yêu cầu của hệ thống lặp đi lặp lại thông qua một quá

trình thiết kế trong đó người dùng đang tích cực tham gia.

Thiết kế hợp tác có ba đặc điểm cụ thể. Nó nhằm cải thiện môi trường làm việc và nhiệm

vụ bằng việc liên tục giới thiệu các thiết kế. Điều này làm cho bối cảnh thiết kế và đánh giá hoặc làm việc theo định hướng người dùng hơn là định hướng hệ thống. Thứ hai, nó được

đặc trưng bởi sự hợp tác: Người sử dụng bao gồm trong đội ngũ thiết kế và có thể đóng góp

cho mọi giai đoạn của thiết kế. Cuối cùng, cách tiếp cận là lặp đi lặp lại: Thiết kế phải được

đánh giá và sửa đổi ở từng giai đoạn.

2.3.5. Phương pháp nhân chủng học (Ethnographic Methods)

Tất cả các phương pháp truyền thống được xem xét ở trên đã bao gồm một số hình thức tư

vấn và quan sát của các bên liên quan. Tuy nhiên, trọng tâm của việc này là thu thập các

quan điểm của các bên liên quan hơn là nghiên cứu cách họ làm việc thực tế.

Dân tộc học dựa trên việc ghi lại chi tiết các tương tác giữa con người với môi trường. Nó

đặc biệt tập trung vào các mối quan hệ trong tổ chức và cách chúng ảnh hưởng đến bản chất

của công việc. Nhà phân tích sử dụng phương pháp này không tham gia tích cực vào tình

hình và không nhìn mọi thứ từ quan điểm của một cá nhân cụ thể. Mục đích là để hiểu được

tình hình từ bên trong khuôn khổ của tổ chức. Họ cố gắng đưa ra quan điểm khách quan về

tình hình của tổ chức. Họ báo cáo và không suy đoán, vì vậy thường không rõ ràng rằng

cách tiếp cận của họ có thể đóng góp vào việc thiết kế các hệ thống mới hay không.

2.3.6. Tóm lược

Trong phần này, tôi nói về các cách tiếp cận tổ chức xã hội để thu thập yêu cầu của các bên liên quan, bao gồm các mô hình xã hội – kỹ thuật, phương pháp hệ thống mềm, thiết kế hợp

tác và các phương pháp nhân chủng học. Các mô hình xã hội – kỹ thuật tập trung vào việc thể hiện song song cả khía cạnh con người và kỹ thuật của hệ thống để đạt được một giải pháp tương thích với nhau. Còn trong mô hình tổ chức SSM, người dùng là một phần, và được xem như một hệ thống. Phương pháp thiết kế hợp tác cho thấy người sử dụng không chỉ hoạt động trong việc sử dụng công nghệ mà còn trong việc thiết kế nó. Phương pháp

nhân chủng học đặt người dùng trong ngữ cảnh, cố gắng thu thập thông tin trên quan điểm không thiên vị về văn hoá làm việc và thực tiễn của người dùng.

2.4. Kỹ nghệ yêu cầu trong Agile Scrum

2.4.1. Quá trình hình thành

Vào đầu thế kỉ XX, các nghiên cứu cho quá trình phân tích yêu cầu tập trung vào việc con

người cần phải làm gì để thích ứng với những thay đổi về kỹ thuật, hay tương tác giữa

người và máy là quá trình mà con người đang ở thế bị động. Chủ nghĩa công nghệ quyết định, quan điểm cho thấy sự thay đổi xã hội chủ yếu là do kỹ thuật, tư tưởng mà các yếu tố

con người và xã hội là mối quan tâm thứ yếu ở thời điểm bấy giờ.

Những thập niên sau đó, quan điểm các mô hình Xã hội – Kỹ thuật (Socio-technical models)

có cách nhìn khác, nó phản ánh đúng vị trí công nghệ bằng việc nhấn mạnh rằng các hệ

thống làm việc bao gồm cả nhân lực và máy móc và đó là mối quan hệ tương hỗ. Mô hình

này cho rằng các thành phần liên quan đến hệ thống tương tác lẫn nhau vì vậy cần quan tâm

đến khía cạnh kỹ thuật, xã hội, tổ chức và con người trong thiết kế. Họ thừa nhận thực tế là

công nghệ không được phát triển một cách độc lập mà là một phần của môi trường tổ chức

rộng lớn hơn.

Thập kỉ 80 của thế kỉ XX chứng kiến thời kì khủng hoảng phương pháp luận phát triển phần

mềm, do tỉ lệ thất bại của các dự án phần mềm quá cao. Hàng loạt nỗ lực của các nhà thực

hành cũng như giới hàn lâm đã cố gắng tìm ra phương pháp hữu hiệu để đảm bảo tính hiệu

quả trong phát triển phần mềm.

Thập kỉ 90, nhiều phương pháp phát triển phần mềm với quy trình nhẹ (light weight) và

linh hoạt ra đời, như XP, Scrum, FDD, Crystal, ... và nhanh chóng được lan rộng.

Từ 11 - 13 tháng 2 năm 2001, 17 nhà phát minh và nhà thực hành đã họp nhau tại bang Utah, Hoa Kì, để thảo luận về hướng đi mới trong phương pháp luận phát triển phần mềm. Họ đã đi đến thống nhất và cho ra đời bản Tuyên ngôn Agile đánh dấu một xu thế mới trong

phát triển phần mềm. Đặc trưng quan trọng của Agile cũng như Scrum: Tiếp cận tăng trưởng lặp là tiền đề cho sự phát triển của kỹ nghệ yêu cầu hiện nay.

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

Chủ sản phẩm (Product Owner) chịu trách nhiệm tối đa hóa giá trị của sản phẩm và công việc của nhóm phát triển thông qua việc quản lý Product Backlog là một danh sách sắp thứ

tự tất cả những gì cần thiết của sản phẩm. Nó là nguồn yêu cầu duy nhất thể hiện các thay

đổi trong sản phẩm.

Để Product Owner thành công, cả tổ chức phải tôn trọng các quyết định của người này. Các

quyết định đó được hiển thị trong nội dung và thứ tự trong Product Backlog. Không ai ngoài Product Owner được phép yêu cầu nhóm phát triển làm gì khác và nhóm phát triển cũng

không được phép làm gì theo lời bất cứ người nào khác.

Là Product Owner, chúng ta nên trực tiếp giao tiếp với khách hàng và người dùng, nhóm

Hình 2: Vai trò cầu nối của Chủ sản phẩm (Product Owner)

phát triển và các bên liên quan khác (Key Stakeholders), như hình dưới đây cho thấy.

Ở trên là vai trò của các thành viên tham gia Scrum, bao gồm Product Owner, Scrum Master, và nhóm phát triển cho thấy Product Owner phải có mối quan hệ gần gũi và sự tin tưởng từ

các thành viên Scrum khác: Scrum xem Product Owner là cầu nối của đội Scrum rộng hơn. Điều này rất có ý nghĩa vì để hoàn thiện sản phẩm Product Owner cần tiếp thu kiến thức về các hoạt động tiếp thị và kinh doanh cũng như văn hóa của công ty trong quá trình làm việc với Senior Management, Marketing and Sales cũng như quá trình cộng tác với Scrum Master và nhóm phát triển.

2.4.3. Quy trình và các cuộc họp trong Scrum

2.4.3.1. Các đặc điểm

Các đặc điểm Agile Scrum sau đây đều ảnh hưởng trực tiếp tới phương pháp thu thập vào

quản lý yêu cầu:

Tăng trưởng và lặp Các phương pháp Agile phân chia công việc trong ngắn hạn, ở mỗi

chu trình đều có đầy đủ các công đoạn trong quy trình phát triển phần mềm và ở mỗi Sprint

đều có các bước phân tích yêu cầu hay làm mịn Product Backlog.

Giao tiếp thường xuyên một cách hiệu quả Product Owner đại diện cho nhóm phát triển làm việc cùng các bên liên quan của khách hàng. Product Owner có trách nhiệm làm rõ tất

cả các yêu cầu của các bên liên quan và truyền tải chúng tới các thành viên trong nhóm phát

triển.

Thích ứng và chấp nhận các thay đổi Các developer qua các buổi họp hằng ngày (Daily

Meeting) hoặc ở đầu hoặc cuối mỗi giai đoạn (Sprint Meeting) sẽ sao trao đổi với nhau để

cập nhật và đồng bộ trạng thái công việc, họ cần phải thích ứng ngay với tình huống mới

hoặc các yêu cầu hoặc thay đổi yêu cầu từ phía khách hàng.

Hướng tới chất lượng sản phẩm Liên kết chặt chẽ giữa nhóm phát triển và khách hàng

tạo nên một sản phẩm chất lượng, từ cách tiếp cận này rất nhiều kỹ thuật và công cụ được

sử dụng để nâng cao chất lượng sản phẩm, bao gồm các kỹ thuật: Test Unit Automation,

Build Automation, Deployment Automation, Aspect Oriented Programming, Design

Pattern, Code Refactoring, …

2.4.3.2. Quy trình Scrum

Chủ sản phẩm (Product Owner) tạo ra Product Backlog chứa các yêu cầu của dự án được sắp theo thứ tự ưu tiên. Nhóm phát triển sẽ hiện thực lần lượt các yêu cầu của Product Owner qua các Sprint với đầu vào là các hạng mục trong Product Backlog, đầu ra là các Phần tăng trưởng chuyển giao được của sản phẩm (Potentially Shippable Product Increment).

Scrum Master đảm bảo các sự kiện được diễn ra và người tham dự hiểu được mục đích của sự kiện. Scrum Master hướng dẫn mọi người luôn làm việc trong khuôn khổ thời gian được 33

phép. Trong cuộc họp các cuộc họp, Scrum Master tham dự như là một thành viên của

Hình 3: Quy trình Scrum

nhóm chịu trách nhiệm về quy trình.

2.4.3.3. Họp kế hoạch Sprint

Công việc trong Sprint được lên kế hoạch trong buổi Họp Kế hoạch Sprint (Sprint Planning

Meeting). Kế hoạch cho Sprint được tạo ra nhờ nỗ lực cộng tác của toàn bộ Nhóm Scrum.

Buổi Họp Kế hoạch Sprint được đóng khung trong 8 tiếng cho mỗi Sprint một tháng. Với

các Sprint ngắn hơn thì thời gian cho buổi họp được rút ngắn lại. Ví dụ như một Sprint hai

tuần có thể chỉ cần họp kế hoạch tới 4 tiếng là đủ.

Buổi Họp Kế hoạch Sprint có hai phần, mỗi phần chiếm một nửa khung thời gian. Hai phần của buổi Họp Kế hoạch Sprint lần lượt trả lời hai câu hỏi sau đây:

 Mục tiêu của Sprint này là gì?

 Sprint này phải chuyển giao cái gì?

 Làm sao để đạt được điều đó?

Phần Một: Phải làm gì trong Sprint này?

Trong phần này, nhóm phát triển làm việc để dự báo chức năng sẽ được phát triển trong

Sprint. Product Owner trình bày các hạng mục Product Backlog được xếp thứ tự cho nhóm

phát triển và toàn bộ Nhóm Scrum sẽ hợp tác để tìm hiểu công việc phải làm trong Sprint.

Đầu vào của buổi họp này là Product Backlog, phần tăng trưởng của sản phẩm gần đây nhất,

năng lực hiện có của nhóm phát triển trong Sprint tới và hiệu suất trong quá khứ của nhóm

phát triển. Số lượng hạng mục được chọn từ Product Backlog cho Sprint này sẽ hoàn toàn

phụ thuộc vào nhóm phát triển. Chỉ nhóm phát triển có thể đánh giá họ có thể hoàn thành

những gì trong Sprint tới đây.

Sau khi nhóm phát triển dự báo các hạng mục Product Backlog sẽ được chuyển giao trong

Sprint, Nhóm Scrum xác lập Mục tiêu Sprint. Mục tiêu Sprint có thể tạo ra một sợi dây ràng

buộc cho những nỗ lực của cả nhóm phát triển hướng đến một mục tiêu chung.

Phần Hai: Làm sao để hoàn thành công việc đã chọn?

Sau khi đã chọn công việc cho Sprint, nhóm phát triển quyết định cách thức để xây dựng

các chức năng sẽ có trong phần tăng trưởng “hoàn chỉnh” trong suốt Sprint. Các hạng mục

Product Backlog được lựa chọn cho Sprint cộng với kế hoạch để chuyển giao chúng được

gọi là Sprint Backlog.

Nhóm phát triển thường bắt đầu công việc bằng cách thiết kế hệ thống và các công việc cần

thiết để chuyển Product Backlog thành gói sản phẩm chạy được. Công việc có thể lớn nhỏ khác nhau. Tuy vậy, một lượng công việc vừa đủ được lên kế hoạch trong suốt buổi Họp

Kế hoạch Sprint cho nhóm phát triển sẽ dự báo những thứ có thể làm trong Sprint sắp tới.

Các công việc được lên kế hoạch trong những ngày đầu tiên của Sprint bởi nhóm phát triển sẽ được phân tách thành các đơn vị nhỏ hơn trong phạm vi một ngày hoặc nhỏ hơn nữa ở

cuối buổi họp.

Nhóm phát triển sẽ tự tổ chức để làm việc trên Sprint Backlog, cả khi lập kế hoạch lẫn thực thi kế hoạch trong suốt Sprint.

Khi nhóm phát triển lên kế hoạch, họ hướng mọi điều tới Mục tiêu Sprint. Trong suốt Sprint, các công việc cần làm đôi khi hơi khác so với kế hoạch ban đầu. Khi đó, nhóm phát triển sẽ cùng làm việc với Product Owner để xác định lại kế hoạch sao cho vẫn đạt được Mục

tiêu Sprint. Mục tiêu Sprint cung cấp sự linh hoạt cần thiết sao cho các chức năng cơ bản

vẫn được hoàn thành vào cuối Sprint.

Product Owner có thể giúp nhóm phát triển làm sáng tỏ các khúc mắc về các hạng mục

được lựa chọn trong Product Backlog, cũng như giúp nhóm đưa ra quyết định trong một số trường hợp đặc biệt. Nếu nhóm phát triển thấy có quá nhiều hoặc quá ít việc, họ có thể

thương lượng thêm với Product Owner về việc này. Nhóm phát triển cũng có thể mời một

số người khác tham dự để hỗ trợ một số vấn đề kĩ thuật hoặc chuyên môn.

Kết thúc buổi Họp Kế hoạch Sprint, nhóm phát triển phải biết cách giải thích cho Product

Owner và Scrum Master biết họ sẽ dự định làm việc như thế nào với tư cách một nhóm tự tổ chức để hoàn thành Mục tiêu Sprint và tạo ra phần tăng trưởng theo yêu cầu.

Mục tiêu Sprint

Mục tiêu Sprint (Sprint Goal) là một tập các mục tiêu cần đạt trong một Sprint sau khi triển

khai một phần của Product Backlog. Nó cung cấp các gợi ý để nhóm phát triển xây dựng

các Phần tăng trưởng (Increment). Mục tiêu Sprint cho phép nhóm phát triển có một số sự

linh hoạt nhất định về việc phải triển khai các chức năng như thế nào trong suốt Sprint. Các

hạng mục Product Backlog được chọn chuyển giao một chức năng đầy đủ có thể là một

Mục tiêu Sprint. Mục tiêu Sprint nên là một bộ các yêu cầu gắn kết khiến nhóm phát triển

làm việc cùng nhau thay vì phân rã mỗi người một việc.

Khi nhóm phát triển làm việc, họ sẽ ghi nhớ Mục tiêu này trong đầu. Để thỏa mãn Mục tiêu Sprint, họ sẽ triển khai các chức năng cũng như các kĩ thuật cần thiết. Nếu công việc phức

tạp hơn dự kiến thì họ có thể cộng tác với Product Owner để thương lượng lại về phạm vi

của Sprint Backlog trong Sprint.

Hình 4: Sử dụng các cuộc họp để hoàn thiện, đánh giá yêu cầu

2.4.3.4. Họp Scrum hằng ngày (Daily Scrum)

Cuộc họp Daily Scrum được đóng khung trong 15 phút để nhóm phát triển đồng bộ hóa các

hoạt động của thành viên và tạo lập kế hoạch cho 24 giờ tiếp theo. Điều này có được nhờ

việc thanh tra các công việc kể từ cuộc họp Daily Scrum trước và dự báo những công việc

sẽ được hoàn thành trước buổi họp lần sau.

Cuộc họp Daily Scrum được tổ chức tại cùng một địa điểm để giảm thiểu sự phức tạp không

cần thiết. Trong suốt cuộc họp, mỗi thành viên nhóm phát triển giải thích rõ:

 Tôi đã làm những gì kể từ hôm qua để giúp nhóm phát triển đạt mục tiêu Sprint?

 Tôi sẽ làm những gì hôm nay để giúp nhóm phát triển đạt được mục tiêu Sprint?

 Tôi có nhìn thấy vấn đề gì cản trở nhóm phát triển đạt được mục tiêu Sprint?

Nhóm phát triển sử dụng cuộc họp Daily Scrum để đánh giá tiến độ công việc hướng tới Mục tiêu Sprint và đánh giá xu hướng tiến triển của công việc trong Sprint Backlog. Cuộc

họp Daily Scrum tối ưu hóa khả năng để nhóm phát triển có thể đạt được Mục tiêu Sprint. Một số nhóm Scrum sử dụng công cụ phần mềm quán lý tiến độ như Atlassian Jira, quá

trình họ cập nhật khối lượng công việc còn lại (Remaining Effort) là thông tin đầu vào của

Hình 5: Sprint Burndown Chart

Sprint Burndown Chart.

Hằng ngày, nhóm phát triển có thể giải thích cho Product Owner và Scrum Master biết họ

định làm gì với tư cách là một nhóm tự quản để hoàn thành mục tiêu và tạo ra các phần tăng

trưởng cần thiết trong Sprint.

Scrum Master đảm bảo cho nhóm phát triển tham gia họp, nhưng chính nhóm phát triển

mới có trách nhiệm chính trong cuộc họp Daily Scrum. Scrum Master phải hướng dẫn cho

nhóm phát triển biết cách giữ cuộc họp ngắn gọn trong phạm vi khung thời gian 15 phút.

Scrum Master phải áp đặt quy tắc về việc chỉ có nhóm phát triển mới được tham gia cuộc

họp Daily Scrum.

Họp Daily Scrum sẽ cải tiến quá trình giao tiếp, lược bỏ các buổi họp hành không cần thiết,

nhận biết và loại bỏ các trở lực trong quá trình phát triển, nhấn mạnh và phát huy các quyết định nhanh chóng và nâng cao mức độ hiểu biết của nhóm phát triển về dự án. Cuộc họp này là chìa khóa của cơ chế thanh tra và thích nghi trong Scrum.

2.4.3.5. Sơ kết Sprint

Buổi Sơ kết Sprint (Sprint Review) được tổ chức khi Sprint kết thúc để rà soát lại phần tăng trưởng vừa làm ra trong Sprint đó và để thực hiện các biện pháp thích nghi đối với Product

Backlog nếu cần. Trong cuộc họp này, Nhóm Scrum và các bên liên quan sẽ trao đổi với

nhau về những gì vừa hoàn thành trong Sprint vừa rồi. Trên cơ sở đó và những sự thay đổi

trong Product Backlog trong suốt Sprint, người tham dự cuộc họp sẽ hợp tác để thảo luận về những công việc sắp triển khai. Đây là cuộc họp không trang trọng và việc trình bày về

gói tăng trưởng chủ yếu nhằm mục đích cung cấp các phản hồi hữu ích và khuyến khích sự

cộng tác giữa các bên. Cuộc họp này được đóng khung trong bốn giờ cho các Sprint có độ

dài một tháng. Sprint ngắn hơn thì thời gian họp rút bớt cho phù hợp. Buổi Sơ kết Sprint có một số đặc điểm sau:

 Product Owner mời mọi người tham dự bao gồm Nhóm Scrum và những người liên

quan

 Product Owner xác nhận phần nào là “Hoàn thành” và phần nào chưa “Hoàn thành”

 Nhóm phát triển thảo luận những điều thuận lợi trong Sprint vừa qua, những khó

khăn mà nhóm đã trải qua và cách thức giải quyết các vấn đề đó

 Nhóm phát triển trình diễn các phần việc đã “Hoàn thành” và trả lời các câu hỏi về

gói tăng trưởng

 Product Owner trao đổi về Product Backlog. Dựa trên tiến độ hiện thời, Product

Owner đưa ra dự đoán ngày hoàn thành dự án (nếu cần)

 Toàn bộ nhóm thảo luận về những gì sẽ làm, nhờ đó buổi Sơ kết Sprint cung cấp các

giá trị đầu vào cho buổi Họp Kế hoạch Sprint tiếp theo

 Xem xét lại thời gian biểu, tài chính, cơ sở vật chất, cũng như các yếu tố thị trường

cho bản phát hành dự kiến của sản phẩm.

Kết quả của cuộc họp Sơ kết Sprint là một bản Product Backlog đã được cập nhật, với các

hạng mục dự định sẽ được triển khai trong Sprint tới. Product Backlog có thể được điều chỉnh toàn diện để thích ứng với các cơ hội mới.

2.4.3.6. Cải tiến Sprint

Buổi họp Cải tiến Sprint (Sprint Retrospective) là cơ hội để Nhóm Scrum tự thanh tra và đưa ra kế hoạch cho các cải tiến trong Sprint tiếp theo.

Buổi họp Cải tiến Sprint được tổ chức ngay sau Sơ kết Sprint và trước khi cuộc Họp Kế

hoạch Sprint tiếp theo diễn ra. Cuộc họp này được đóng khung trong phạm vi ba giờ cho

các Sprint một tháng. Sprint ngắn hơn thì cuộc họp sẽ được rút ngắn lại cho phù hợp.

Mục đích của cuộc họp Cải tiến Sprint là để:

 Thanh tra lại tất cả các yếu tố trong Sprint vừa diễn ra, từ con người, các mối quan

hệ, quy trình và công cụ

 Nhận biết và xếp đặt lại các hạng mục chủ chốt đã được thực hiện tốt và các cải tiến

dự định

 Tạo ra một kế hoạch để triển khai các cải tiến cách thức làm việc của Nhóm Scrum.

Scrum Master khuyến khích Nhóm Scrum cải tiến, trong phạm vi khung làm việc Scrum,

quy trình phát triển và các biện pháp thực hành để nâng cao hiệu quả và thú vị cho Sprint

tiếp theo. Trong cuộc họp Cải tiến Sprint, Nhóm Scrum sẽ lập kế hoạch để gia tăng chất

lượng sản phẩm bằng việc định nghĩa lại Định nghĩa “Hoàn thành” khi cần thiết.

Kết thúc cuộc họp Cải tiến Sprint, Nhóm Scrum phải xác định được các cải tiến sẽ được

triển khai trong Sprint tới. Việc triển khai các cải tiến này chính là sự thích nghi của Nhóm

Scrum. Mặc dù các cải tiến có thể được triển khai tại bất kì thời điểm nào đó, cuộc họp Cải

tiến Sprint cung cấp một phiên làm việc chính thức để tập trung vào việc thanh tra và thích

nghi.

2.4.3.7. Tóm lược

Các cuộc họp diễn ra trong từng Sprint có sự tham gia của Chủ sản phẩm (Product Owner),

Scrum Master và nhóm phát triển bao gồm: Họp kế hoạch Sprint (Sprint Planning Meeting),

Họp Scrum hằng ngày (Daily Meeting), Họp sơ kết Sprint (Sprint Review Meeting), Họp cải tiến Sprint (Sprint Retrospective Meeting). Các cuộc họp này sẽ làm thay đổi các đơn

vị yêu cầu dùng User Story qua sơ đồ sau.

Hình 6: Vòng đời của User Story

2.4.4. Hướng tiếp cận các Bên liên quan (Stakeholder)

Các bên liên quan được chia thành 4 nhóm: Player, Subject, Context Setter (hay Referee)

và Crown phụ thuộc vào quyền lực, tầm ảnh hưởng và mức độ quan tâm tới dự án. Phần

này tôi sẽ trình bày lý thuyết và thực hành ở Chương 3. Phương pháp thu thập yêu cầu

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

Hoạt động làm mịn Product Backlog đảm bảo sản phẩm thường xuyên được hoàn thiện.

Điều này là cần thiết vì Product Backlog có thể thay đổi thông qua quá trình phát triển phần mềm và quá trình chuyển giao các Phần tăng trưởng chuyển giao được của phần mềm tới người dùng và các bên liên quan khác, như hình ảnh dưới đây minh hoạ.

Hình 7: Các hoạt động trong Sprint và quá trình làm mịn Product Backlog

Việc làm mịn Product Backlog là hoạt động thêm vào các chi tiết, ước lượng, và trình tự

của các hạng mục trong Product Backlog. Đây là quá trình liên tục, theo đó Chủ sản phẩm

(Product Owner) và nhóm phát triển thảo luận về các chi tiết của từng hạng mục. Trong

Hình 8: Các hoạt động làm mịn Product Backlog

suốt quá trình làm mịn này, các hạng mục liên tục được xem xét và rà soát cẩn thận.

2.4.5.1. Quá trình làm mịn Product Backlog diễn ra khi nào

Nhóm Scrum quyết định cách thức và thời điểm để làm mịn Product Backlog. Có những

nhóm có hoạt động làm mịn Product Backlog là một sự kiện diễn ra vào giữa Sprint để

chuẩn bị yêu cầu cho sprint tiếp theo. Tuy thế, các hạng mục Product Backlog có thể được

cập nhật tại bất kì thời điểm nào theo chủ quan của Product Owner. Sau đây tôi đưa ra bốn

lựa chọn cùng lợi ích và hạn chế của chúng.

Tuỳ chọn 1: Trong buổi Sprint Review Meeting kết thúc Sprint

Tuỳ chọn 2: Trong buổi họp Sprint Planning bắt đầu Sprint

Tuỳ chọn 3: Trong một buổi họp cụ thể sau buổi họp Sprint Planning

Tuỳ chọn 4: Liên tục trong quá trình thực hiện Sprint

2.4.5.2. Bao nhiêu thời gian cho quá trình làm mịn Product Backlog

Trung bình 1 Sprint kéo dài 2 tuần thường cần 2 – 4 tiếng cho quá trình làm mịn. Sản phẩm qua thời gian sẽ ổn định hơn, nỗ lực làm mịn Backlog cũng ít đi. Lý do cho điều này là sự

hiểu biết về sản phẩm càng ngày càng tăng và rủi ro càng ngày càng giảm vì vậy Project

Hình 9: Lợi ích của quá trình làm mịn Product Backlog

Team ít cần dựa vào phản hồi và thử nghiệm để nhận thức đúng các yêu cầu.

2.4.6. User Story và UML Use Case

User Story không thể xem là Use Case. Bởi vì các User Story không cung cấp thông tin chi

tiết để nhóm phát triển biết cần phải làm gì và làm như thế nào. Theo phương pháp Scrum

thì việc xây dựng Use Case là không cần thiết. Những thành viên trong nhóm phát triển lần

đầu tiên khi làm việc với Agile thường ngầm hiểu các User Story là các Use Case nhưng

thực ra chúng không thể thay thế cho nhau, User Story tập trung vào kết quả và lợi ích của

những gì nhà phân tích đang mô tả, trong khi Use Case mô tả cách hệ thống sẽ hoạt động

như thế nào. Một Use Case mô tả một tập hợp các tương tác giữa các hệ thống và một hoặc

nhiều tác nhân Actor (Trong đó Actor có thể là người, hoặc hệ thống khác). Chúng thường được tạo ra như là tài liệu dự án, và thường bao gồm các thông tin sau:

1. Use Case Title 2. Lý do / Mô tả / Mục tiêu 3. Tác nhân / Người dùng 4. Preconditions – Những điều kiện để Use Case được thực hiện 5. Standard Path và Main Success Scenario – Các bước thông thường 6. Alternate paths or Extensions - Các trường hợp phát sinh có thể xảy ra 7. Post Conditions – Những điều kiện cần đáp ứng ở cuối các bước

Lồng các User Story vào trong các Use Case đã xuất hiện ở nhiều dự án Agile. Họ xem

User Story chỉ là sự khởi đầu của một quá trình tìm hiểu những gì cả nhóm phát triển cần

Bảng 1: Mô tả User Story trong Use Case

phải thực hiện. Sau đây là ví dụ:

Nhưng Agile là một phương pháp phát triển linh hoạt, khi mà khách hàng và nhóm phát

triển tương tác với nhau liên tục, mỗi Sprint thường mất 1 đến 2 tuần làm việc, nhóm phát

triển thông qua các Groomed Product Backlog đã biết cần phải làm gì nên việc xây dựng

Use Case là hạn chế và chỉ cần thiết cho các xử lý phức tạp và cả đội cần phải có một tài

liệu kỹ thuật thống nhất. Sau đây tôi sẽ tóm tắt sự khác biệt giữa User Story và Use Case:

 Các User Story là nói về các nhu cầu của người dung

 Use Case là về hành vi sẽ xây dựng vào phần mềm để đáp ứng những nhu cầu đó

 User Story dễ dàng cho người sử dụng đọc hiểu

 Use Case mô tả một sự tương tác hoàn chỉnh giữa phần mềm và người sử dụng (hoặc

có thể là các hệ thống khác) và người sử dụng có thể không hiểu về nó

2.4.7. User Story và Acceptance Criteria

Mỗi User Story sau quá trình làm mịn cần phải đi kèm với một bộ các Tiêu chí chấp nhận (Acceptance Criteria) là các giới hạn ràng buộc cho quá trình coding và testing. Tiêu chí chấp nhận (Acceptance Criteria) là một công cụ nhằm đảm bảo rằng các sản phẩm được phát triển thực sự là những gì Product Owner hay khách hàng muốn. Mỗi User Story được đi kèm với một bộ các tiêu chuẩn mà xác định làm thế nào nó sẽ được kiểm tra và xác minh, để được chấp nhận.

Hình 10: Quá trình làm mịn User Story

Product Owner cùng các thành viên nhóm phát triển xây dựng những User Story trong và

các Tiêu chí chấp nhận (Acceptance Criteria) tương ứng trong Planning Meeting. Điều này

giúp các thành viên hiểu rõ hơn về yêu cầu này, sau đây là ví dụ với một User Story.

As a home banking user I want to make a money transfer So that I can pay the loan even if the bank is closed

Tôi sử dụng cú pháp GWT (Given When Then) để xây dựng các UAC như dưới đây:

Given [a specific condition] And [...] When [an event occurs] Then [outcome] And [...]

Sau đây là 3 kịch bản nghiệm thu cơ bản được sử dụng để kiểm tra và chấp nhận cho User

Story ở trên:

Kịch bản 1

Given that the account balance is € 2.000,00 And the user is trusted And the beneficiary bank account exists, When the transfer amount is € 800,00 And the security operation code is correct, Then the bank should transfer € 800,00 to the beneficiary And the account balance should be updated to € 1.200,00

Kịch bản 2

Given that the account balance is € 500,00 And the user is trusted And the beneficiary bank account exists, When the transfer amount is € 800,00

And the security operation code is correct, Then the bank should not operate any transfer And a message must displayed saying there are insufficient funds

Kịch bản 3

Given that the account balance is € 2.000,00 And the user is trusted And the beneficiary bank account exists, When the transfer amount is € 800,00 And the security operation code is NOT correct, Then the bank should not operate any transfer And a message must displayed saying the code is incorrect

Như vậy trong cùng một thời điểm các Tester có thể xây dựng các Test Case dựa trên các

Acceptance Criteria Scenario và Developer có một sự hiểu biết rõ ràng về chức năng họ

Hình 11: Cấu trúc của User Story

sắp sửa xây dựng và các điều kiện để chức năng đó được chấp nhận.

2.4.8. Tốc độ thay đổi yêu cầu qua Release Burndown Chart

Trong Scrum, Release Burndown Chart cho thấy một thông tin duy nhất là sự thay đổi của khối lượng công việc còn lại hay các item trong Product Backlog chưa hiện thực hóa. Vì vậy nó không thể hiện hết những gì có thể xảy ra trong một dự án.

Hình 12: Release Burndown Chart cơ bản

Trên biểu đồ burndown này, chiều cao của mỗi cột đại diện cho khối lượng công việc còn

lại của một Product Release. Khối lượng này được tính thông qua phép cộng các Story

Point của item tương ứng trong Backlog. Lúc bắt đầu Sprint 4, Product Owner đã thêm việc

vào. Các công việc được thêm vào được thể hiện ở đáy của cột ở Sprint thứ 4 vì vậy chiều

cao của cột ở Sprint 4 ngoài 95 còn có thêm -40, tương đương với 135 point còn lại. Trong

đó 40 Point đến từ các công việc mới. Trước khi bắt đầu sprint 6, Product Owner đã bỏ bớt

công việc. Cũng như các công việc được thêm, các công việc được bớt cũng được trừ vào

đáy của các cột. Điều này cho thấy rõ các công việc được cộng thêm hay bớt đi so với kế

hoạch ban đầu.

Có một phương pháp để dự kiến còn bao nhiêu Sprint cần thực hiện bằng cách vẽ 2 đường

Hình 13: Release Burndown Chart quan tâm tới thay đổi yêu cầu ở Sprint hiện tại

thẳng đi qua đỉnh và đáy của Sprint hiện tại như sau:

Một vấn đề ở phương pháp này không bao gồm tốc độ thay đổi yêu cầu trong dự án. Phương

Hình 14: Release Burndown Chart quan tâm tới xu hướng thay đổi yêu cầu ở các Sprint

pháp thứ hai là nối hai đỉnh và hai đáy của Sprint 1 với Sprint hiện tại như hình dưới đây:

2.5. Mô hình hóa trong dự án Agile

Scrum coi trọng quá trình viết mã chương trình và kiểm thử hơn là việc xây dựng tài liệu,

vì vậy cần một mô hình phù hợp để áp dụng các hoạt động mô hình hóa, điều này quan

trọng đặc biệt khi quá trình phát triển có sự tham gia của nhiều nhóm và họ cần sự hiểu biết

chung về hệ thống.

Một điểm mà Agile đã làm rõ là sự chuyển đổi giá trị từ tài liệu sang các cuộc trò chuyện.

Nhưng tài liệu làm cho các cuộc trò chuyện có hiệu quả và là cách tiếp cận mà chúng ta nên

thực hiện và nó phải là bộ các mô hình đơn giản nhất có thể và hoạt động bổ sung cho mã.

Một khía cạnh khác mà các mô hình có lợi thế hơn mã code là khả năng thể hiện trực quan.

Sau đây tôi trình bày phương pháp mô hình hóa phù hợp với các dự án Scrum, phương pháp này phù hợp với các giá trị và nguyên tắc của Agile nhưng vẫn tận dụng sức mạnh của mô

hình hóa. Tôi nhấn mạnh rằng các mô hình này phục vụ cho việc đối thoại chứ không phục vụ cho việc chuyển giao.

Hình 15: Mô hình hóa trong Scrum với KEEPS và TEMPS

2.5.1. Phân loại nhóm mô hình KEEPS và TEMPS

Các mô hình KEEPS cần duy trì bao gồm:

1. "Architecture" của hệ thống: Để nhóm phát triển có được một hình dung tổng quan

về toàn bộ cấu trúc hệ thống.

2. "Domain Model": Để giúp nhóm hiểu các khái niệm được sử dụng trong miền vấn

đề (Problem Domain).

3. "Key Use Cases": Để giúp nhóm hiểu các khái niệm đã sử dụng trong miền vấn đề

(Problem Domain).

KEEPS không chỉ bao gồm các mô hình kiến trúc hệ thống của nhóm phát triển mà còn hỗ trợ các từ vựng mà họ sử dụng trong cuộc họp và trong mã chương trình của họ như việc đặt tên cho các Class, Method, Variable, Field, dữ liệu, và cấu hình tham số. Nói cách khác,

các mô hình này không chỉ quan trọng cho nhóm để thiết lập một sự hiểu biết chung về toàn bộ hệ thống, mà còn để cả nhóm duy trì codebase phù hợp và có thể bảo trì sau này.

Mặt khác, cũng có các mô hình tạm thời TEMPS sẽ bị bỏ đi sau khi thông tin chứa đựng

trong nó đã được hiện thực thành mã chương trình. Các Class Diagram đơn giản với vài

Class và Sequence Diagram mô tả sự tương tác của chúng (thường được vẽ trên bảng trắng)

rơi vào các thể loại này. Các mô hình này cũng rất quan trọng để khuyến khích cuộc trò chuyện như không cần thiết phải giữ lại sau khi hoàn thành việc phát triển. Vì vậy, cốt lõi

của phương pháp mô hình hóa này là phân loại các mô hình thành hai loại – mô hình để giữ

và duy trì như là tài sản và mô hình được vẽ tạm thời để các cuộc trò chuyện hiệu quả. Xin

lưu ý rằng KEEPS cũng cần cập nhật theo thời gian. Trong phần tiếp theo, tôi sẽ đề xuất ba "Keeps" cho các nhóm Agile.

2.5.2. Các mô hình trong KEEPS

2.5.2.1. Các Architecture bao gồm các Class/Package Diagram

Architecture là một bài trình bày về cấu trúc của toàn bộ hệ thống. Nó thường được mô tả

bởi các Class Diagram hoặc Package Diagram nhưng ở Global layer. Các mô hình kiến trúc

như "MVC" (Model-View-Controller) có thể được chọn làm Global Architecture. Hình 16:

Các KEEPS Architecture bao gồm các Class/Package Diagram là một ví dụ về một kiến

Hình 16: Các KEEPS Architecture bao gồm các Class/Package Diagram

trúc được vẽ như là một Package Diagram dựa trên kiến trúc MVC.

2.5.2.2. Các Domain Model bao gồm các Class/ER Diagram

Một Domain Model mô tả khái niệm của không gian vấn đề mà ứng dụng hoạt động. Trong cấp độ giao tiếp của con người, từ vựng của Domain Model này được sử dụng trong toàn

bộ cộng đồng các bên liên quan bao gồm người sử dụng, các Domain Experts, các nhà phân

tích kinh doanh, các Tester và các nhà phát triển.

Ở khía cạnh lập trình, thông thường Domain Model (hoặc các thực thể - Entity) nằm trong package "M" trong kiến trúc logic nếu dự án chọn kiến trúc "MVC". Trong các ứng dụng

RubyOnRails, sơ đồ ER lại phù hợp hơn cho việc thể hiện Domain Model vì nó được tích

Hình 17: Các KEEPS Domain Model bao gồm các Class Diagram

hợp trực tiếp vào cơ sở dữ liệu quan hệ.

2.5.2.3. Các Key Use Case ba gồm các Use Case Diagram và

Sequence/Communication Diagram

Có hai lý do để KEEPS bao gồm các Use Case Diagram. Đầu tiên là các Developer thường đi vào coding chức năng và quên đi những người sử dụng hệ thống và những gì họ muốn đạt được với hệ thống. Các Use Case giúp họ nhớ lại quan điểm của người dùng và là một cách tốt để trò chuyện với người dùng, vì các tài liệu khác thường khó hiểu cho người dùng. Lý do khác là Key Use Case bao gồm các Sequence Diagram hoặc Communication Diagram mô tả các đối tượng trong hệ thống trong các tầng khác nhau trong kiến trúc làm

việc cùng nhau để đạt được mục tiêu của người dùng. Các Key Use Case không nhất thiết

Hình 18: Các Key Use Case bao gồm các Use Case Diagram

phải đầy đủ mà chỉ chọn những cái điển hình để có hình dung đơn giản.

Các Key Use Case diagram này không cần phải toàn diện nhưng phải nắm bắt được bối

cảnh của hệ thống. Use Case màu vàng "Create Class Diagram" được chọn làm Key Use

Hình 19: Các Key Use Case bao gồm các Communication Diagram

Case sử dụng Communication Diagram ở layer thấp hơn.

2.5.3. Sử dụng KEEPS trong nhóm Scrum mở rộng

Trong các buổi hội thảo mô hình hoá, Ken một thành viên của Đội Tiger (Hình 20: Tiger team và Sub teams) đang thực hiện hoạt động SAD thông qua các mô hình sử dụng phương

pháp hỏi đáp thông thường, Ken truyền đạt những ý tưởng cốt lõi và cấu trúc của hệ thống.

Anh ta có thể sử dụng Key Use Case để giải thích các thành phần của hệ thống hoạt động

như thế nào để đạt được mục đích sử dụng. Và anh ta cùng Sub Team 1 thiết kế một hoặc hai Use Case chính sử dụng mô hình TEMPS. Một phần quan trọng của buổi hội thảo phụ

là phản hồi. Ken trong Sub Team 1 và Tom trong Sub Team 2 đưa ra phản hồi cho đội Tiger

Hình 20: Tiger team và Sub teams

và thảo luận với các thành viên khác làm thế nào để mô hình KEEPS tốt hơn.

2.5.4. Tóm lược

Trong phần này, tôi đề xuất giải pháp mô hình hoá UML phù hợp với dự án Scrum bao gồm

các biều đồ mà nhóm cần lưu giữ trong suốt vòng đời của sản phẩm (KEEPS), ở các mốc dự án Chủ sản phẩm (Product Owner) cần tổ chức các buổi hội thảo mô hình hoá để truyền

đạt các ý tưởng trong thiết kế chức năng cũng như thiết kế hệ thống, và qua đó thiết lập một sự hiểu biết chung về hệ thống. Giải 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.

Chương 3. Phươ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

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

viên nội bộ nhưng cũng có thể là các bên liên quan.

Để 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:

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

Bảng 2: Lưới Tầm ảnh hưởng-Độ quan tâm (Power-Interest Grid) lý thuyết

tính năng sản phẩm.

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.

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

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. Lưới Tầm ảnh hưở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ần suất Kỹ thuật tương tác

tương tác tương tác

Cộng tác Once per Collaborative

(Collaborate) sprint workshops bao gồm:

Strategy và Roadmap

workshops, sprint 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

review meetings

Thu hút sự Monthly Sprint review meetings

tâm Subjects Sinh viên Người dùng ẩn danh quan (Involve)

Tham khảo Quarterly Gặp riêng (One-on- Context

(Consult) one meetings) 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ệ

Thông báo Quarterly Newsletter Crowd Phòng CNTT trường ĐH Sân khấu Điện ảnh (Inform)

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

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

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

3.3.4. Bảng Kanban

3.4. Tóm lượ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.

Chươ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 họ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:

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 thư 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 lọ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.

Chức năng xâ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

Đơ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.

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.

Họ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 học Là môn học của một Loại hình Văn hóa Nghệ thuật tương ứng.

Ngườ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.

Ngườ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 họ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 ngườ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 Ngườ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 phươ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.

thống 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. Hệ 3DRecognization

Dữ liệu khung xương của nhân vật đang thực hiện điệu nhảy. Khung xương 3D

Là đầu vào của hệ thống 3DRecognization.

Yêu cầu Nội dung 3D chuyển động

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

STT Tên tài liệu

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 1

Nội dung thông tin từ website: http://skda.edu.vn 2

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, ...

 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

Hình 22: KEEP Package Diagram cho yêu cầu chức năng và phi chức nă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:

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

Người sử dụng Mô tả

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 Người quản trị hệ thống (Admin)

Là giảng viên Trường Đại học Sân khấu Điện ảnh Hà Nội Giảng viên

Là sinh viên Trường Đại học Sân khấu Điện ảnh Hà Nội

Sinh viên Người dùng ẩn danh Là những người dùng chưa đăng nhập hệ thống

Là đại diện của những Đơn vị cung cấp nội dung

Đại diện đơn vị cung cấp nội dung

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

10 pts 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.

8 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.

Tôi có thể đăng xuất hệ thống. 8 pts ST-3 Là một Người dùng đã đăng nhập hệ thống

Là một Người quản trị 5 pts ST-4

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

Là một Giảng viên 10 pts ST-5

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.

8 pts 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

Là một Người quản trị 5 pts ST-7

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.

10 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, …

5 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

10 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”.

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

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),

Hình 25: KEEP Package Diagram cho yêu cầu phi chức năng

là những yêu cầu không ở mức chức năng (Functional Level).

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

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

của các Đơn vị cung cấp nội dung (có thể bổ sung sau này).

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.

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

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 phụ: Tác nhân chính:

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)

Hình 30: KEEP Package Diagram cho các Use Case Quản trị Hệ thống

1. Quản trị Hệ thống

Hình 31: KEEP Package Diagram cho các Use Case Quản lý Quyền người dùng

2. Quản lý Quyền người dùng

3. Quản trị Người dùng

Hình 32: KEEP Package Diagram cho các Use Case Quản trị Người dùng

a. Quản trị Người dùng diagram

Hình 33: TEMP Sequence Diagram cho Use Case Hiển thị Lịch sử Người dùng

b. Hiển thị Lịch sử Người dùng

Hình 34: TEMP Sequence Diagram cho Use Case Hiển thị Thông tin chi tiết Tài khoản

c. Hiển thị Thông tin chi tiết Tài khoản

Hình 35: TEMP Sequence Diagram cho Use Case Hiển thị các Tạc vụ trong quá khứ

d. Hiển thị các Tạc vụ quá khứ

Hình 36: TEMP Sequence Diagram cho Use Case Xóa Người dùng

e. Xóa Người dùng

Hình 37: TEMP Sequence Diagram cho Use Case Đóng Tài khoản

f. Đóng Tài khoản Người dùng

Hình 38: TEMP Sequence Diagram cho Use Case Đăng nhập

g. Đăng nhập

Hình 39: KEEP Package Diagram cho các Use Case Quản lý Thông tin chung

4. Quản lý Thông tin chung

5. Quản lý Dữ liệu Đa phương tiện

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ị

a. Quản lý Dữ liệu Đa phương tiện_Người quản trị 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

b. Quản lý Dữ liệu Đa phương tiện_Giảng 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

c. Quản lý Dữ liệu Đa phương tiện_Sinh viên diagram

6. Quản lý Bài giảng

Hình 43: KEEP Package Diagram cho các Use Case Quản lý Bài giảng_Người quản trị

a. Quản lý Bài giảng_Người quản trị diagram

Hình 44: KEEP Package Diagram cho các Use Case Quản lý Bài giảng_Giảng viên

b. Quản lý Bài giảng_Giảng viên diagram

Hình 45: KEEP Package Diagram cho các Use Case Quản lý Bài giảng_Sinh viên

c. Quản lý Bài giảng_Sinh viên diagram

Hình 46: TEMP Sequence Diagram cho Use Case Biên soạn Nội dung bài giảng

d. 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:

Hình 47: KEEP Class Diagram mô tả mối quan hệ giữa các bảng

Các Bảng của CSDL cần đặc tả các thông tin như bảng sau:

Tên bảng: [tên bảng] – [Giải thích tên bảng]

buộc Ý nghĩa Ghi chú STT Tên trường Kiểu dữ liệu và kích thước Ràng dữ liệu

chính, 1..n Khoá 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 lượ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.

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

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.

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?”

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ì?

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?

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, Mẹ 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.

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?

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à trường ĐH Sâ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ì?

100

A: Chỉ có website của nhà trường.

Phụ lục II. Danh sách các Epic

101

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

2. Phần mềm cần kế thừa kho dữ liệu của các đơn vị liên quan

102

3. Áp dụng công nghệ 3D vào việc học, giảng dạy

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

103

nhiều thiết thiết bị

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

104

7. Phần mềm cần có tài liệu kỹ thuật và hướng dẫn sử dụng

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

105

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,

106

nghiên cứu

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",

107

theo diễn viên, theo loại hình động tác cơ bản

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

108

góc nhìn khác nhau

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