Luận văn Thạc sĩ Công nghệ thông tin: Phân tích và thiết kế 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

Chia sẻ: Yi Yi | Ngày: | Loại File: PDF | Số trang:117

Thêm vào BST

Báo xấu

51
lượt xem 9
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Đề tài nghiên cứu đề xuất dự án nghiên cứu ứng dụng công nghệ đa phương tiện và các kỹ thuật đồ họ máy tính, xử lý ̉ảnh, xử lý âm thanh, xử lý tín hiệu hiện đại kết hợp với các kỹ thuật phân tích, học máy để trích chọn về lưu trữ dữ liệu về các hình thức văn hóa phi vật thể.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Luận văn Thạc sĩ Công nghệ thông tin: Phân tích và thiết kế 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

ĐẠ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 2
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 3
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 4
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 CHƯƠNG 1. GIỚI THIỆU ..................................................................................................................12 1.1. MỤC ĐÍCH VÀ Ý NGHĨA CỦA ĐỀ TÀI ...........................................................................................12 1.2. ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU .......................................................................................13 1.3. 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 1.4. CẤU TRÚC LUẬN VĂN ................................................................................................................15 CHƯƠNG 2. CƠ SỞ LÝ THUYẾT .....................................................................................................16 2.1. 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 2.2. 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. 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 2.4. KỸ NGHỆ YÊU CẦU TRONG AGILE SCRUM .................................................................................31 2.4.1. Quá trình hình thành ............................................................................................................31 5
2.4.2. Vai trò của Chủ sản phẩm (Product Owner) trong Scrum ...................................................31 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 2.5. 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 2.5.3. Sử dụng KEEPS trong nhóm Scrum mở rộng .......................................................................54 2.5.4. Tóm lược ...............................................................................................................................54 CHƯƠNG 3. PHƯƠNG PHÁP THU THẬP YÊU CẦU ...................................................................55 3.1. 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 3.2. BỘ CÂU HỎI PHỎNG VẤN CÁC BÊN LIÊN QUAN (Q&A) ..............................................................59 3.3. 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 3.3.3. Scrum Taskboard: SPRINT_2017_03_03.............................................................................61 3.3.4. Bảng Kanban ........................................................................................................................62 3.4. TÓM LƯỢC .................................................................................................................................62 CHƯƠNG 4. PHÂN TÍCH & THIẾT KẾ HỆ THỐNG....................................................................63 4.1. 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 4.2. 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 6
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 4.4. TÓM LƯỢC .................................................................................................................................92 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 7
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 - Là một thoả thuận cơ sở để xác định điều kiện nghiệm thu hoàn DoD 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 Potentially Shippable Phần tăng trường chuyển giao được của sản phẩm Product Increment Internal Meeting Daily Meeting (Stand Meeting) – Cuộc họp nhóm hằng ngày Sprint Meeting – Cuộc họp Sprint Stakeholder Meeting Các cuộc họp với các bên liên quan như: Product Strategy – Cuộc họp chiến lược sản phẩm Roadmaping Workshop – Buổi hội thảo lộ trình Sprint Review Meeting – Cuộc họp đánh giá Sprint Danh mục chữ viết tắt Chức viết tắt Ý nghĩa PO Product Owner (Chủ sản phẩm) SAD Software Analysis and Design UAC User Acceptance Criteria 8
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 9
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 10
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. 11
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ó 12
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. 13
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. 14
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. 15
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 16
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: 17
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 Theo lý thuyết, các yêu cầu tốt nên có các tính chất sau:  Cần thiết – Cái cần phải nhắc đến nếu không hệ thống sẽ thiếu một phần tử quan trọng mà không một thành phần nào khác của hệ thống có thể bù lại được.  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 khi vẫn truyền đạt được nội dung cốt yếu của yêu cầu 18
 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ệ thống ngôn ngữ và thuật ngữ cho các khái niệm.  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 xem thêm tài liệu khác để có thể hiểu được nội dung của yêu cầu.  Đạ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 nguyên/thời gian có được  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 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). 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 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 đề đó. 20