Chươ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. “Chươ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. “Chương 3: Phươ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.
“Chươ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. 13 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Chươ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 14 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 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. 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ế).
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: 15 LUAN VAN CHAT LUONG download : add luanvanchat@agmail. 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". 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).
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.
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 gọ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 16 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com • 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 đượ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ử đượ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).
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ó.