Ôn tập thi lại SWR302 Fall 2024

Khi xây dựng hệ thống thông tin, việc tham gia của các bên liên quan, bao gồm cả chuyên gia dữ liệu, vào quá trình xác định yêu cầu dữ liệu là rất quan trọng. Điều này giúp đảm bảo một cái nhìn toàn diện về nhu cầu và phức tạp của dữ liệu. Bằng cách tham gia vào quá trình này, các chuyên gia dữ liệu có thể cung cấp kiến thức chuyên môn và kinh nghiệm để giúp xác định chính xác yêu cầu dữ liệu của hệ thống. Điều này giúp tránh những sai sót và nhầm lẫn trong quá trình thiết kế và phát triển hệ thống, từ đó đảm bảo hệ thống hoạt động chính xác và hiệu quả.

Một yêu cầu được định nghĩa tốt nhất là một nhu cầu hoặc mong muốn của doanh nghiệp để giải quyết một vấn đề hoặc đạt được một mục tiêu. Yêu cầu là một khái niệm quan trọng trong quản lý dự án và phát triển sản phẩm, giúp xác định rõ những gì cần được thực hiện để đáp ứng nhu cầu của khách hàng hoặc đạt được mục tiêu kinh doanh. Một yêu cầu thường bao gồm các yếu tố như: mục tiêu, yêu cầu chức năng, yêu cầu không chức năng, và các ràng buộc khác. Việc định nghĩa rõ ràng và chính xác yêu cầu giúp đảm bảo rằng dự án được thực hiện đúng hướng và đạt được kết quả mong muốn.

Một đại diện được chỉ định của một lớp người dùng cụ thể cung cấp các yêu cầu người dùng cho nhóm mà họ đại diện. Người đại diện này đóng vai trò quan trọng trong việc xác định và ưu tiên các yêu cầu của nhóm, đảm bảo rằng các yêu cầu này được thực hiện một cách hiệu quả và phù hợp với mục tiêu của nhóm. Họ cũng phải có khả năng giao tiếp và làm việc hiệu quả với các thành viên khác trong nhóm, cũng như với các bên liên quan khác.

Để tìm kiếm các quy tắc kinh doanh, bạn có thể tham khảo các nguồn sau: Thứ nhất, kiến thức phổ biến từ tổ chức, thường được thu thập từ những người đã làm việc với doanh nghiệp trong một thời gian dài và hiểu rõ chi tiết về cách thức hoạt động của nó. Điều này giúp bạn hiểu được quy trình và quy tắc kinh doanh của tổ chức. Thứ hai, hệ thống di sản (Legacy systems) chứa các quy tắc kinh doanh trong yêu cầu và mã nguồn của chúng. Điều này cho phép bạn hiểu được cách thức hoạt động của hệ thống và các quy tắc kinh doanh được áp dụng. Thứ ba, phân tích tài liệu hiện có, bao gồm các yêu cầu kỹ thuật từ dự án trước, quy định, tiêu chuẩn ngành, tài liệu chính sách doanh nghiệp, hợp đồng và kế hoạch kinh doanh. Điều này giúp bạn hiểu được quy tắc kinh doanh và cách thức hoạt động của doanh nghiệp. Tóm lại, việc tìm kiếm quy tắc kinh doanh là một quá trình phức tạp và đòi hỏi sự tham gia của nhiều nguồn lực khác nhau.

Trong câu hỏi này, chúng ta đang được hỏi về loại quy tắc kinh doanh được thể hiện trong một tuyên bố cụ thể. Tuyên bố này cho rằng nếu một khách hàng tiềm năng không phản hồi lại sau 30 ngày kể từ khi liên hệ lần đầu tiên, thì đó phải là một khách hàng tiềm năng lạnh và có thể được đánh dấu theo cách đó. Loại quy tắc kinh doanh được thể hiện ở đây là quy tắc suy luận (inference). Quy tắc suy luận là quy tắc kinh doanh cho phép hệ thống đưa ra kết luận hoặc quyết định dựa trên dữ liệu và thông tin đã có. Trong trường hợp này, hệ thống sẽ suy luận rằng khách hàng tiềm năng không phản hồi lại sau 30 ngày là một khách hàng tiềm năng lạnh và có thể được đánh dấu theo cách đó.

Các nhà vận động sản phẩm (product champions) đóng vai trò quan trọng trong quá trình phát triển sản phẩm. Họ có nhiệm vụ thu thập yêu cầu từ các thành viên của nhóm người dùng mà họ đại diện và giải quyết các mâu thuẫn không nhất quán. Đồng thời, họ cũng đóng vai trò là điểm liên hệ chính giữa các thành viên của một nhóm người dùng cụ thể và nhà phân tích kinh doanh của dự án. Điều này giúp đảm bảo rằng các yêu cầu của người dùng được hiểu và thực hiện chính xác.

Trong việc mô tả một trường hợp sử dụng, các điều kiện có khả năng ngăn cản trường hợp sử dụng thành công được gọi là ngoại lệ. Ngoại lệ là các điều kiện không mong muốn có thể xảy ra trong quá trình thực hiện một trường hợp sử dụng, chẳng hạn như lỗi dữ liệu, lỗi kết nối mạng, v.v. Khi xác định ngoại lệ, chúng ta cần phải xác định rõ nguyên nhân và cách giải quyết của chúng để đảm bảo rằng trường hợp sử dụng vẫn có thể hoạt động một cách hiệu quả. Ngoài ra, ngoại lệ cũng giúp chúng ta xác định các trường hợp sử dụng phụ, những trường hợp sử dụng có thể xảy ra nhưng không phải là trường hợp sử dụng chính.

Khi tham gia vào nhiều đại diện người dùng khác nhau thay vì chỉ dựa vào một đại diện duy nhất, chúng ta có thể đảm bảo được một cái nhìn toàn diện hơn về nhu cầu đa dạng của người dùng. Điều này giúp chúng ta hiểu rõ hơn về những mong muốn và kỳ vọng của người dùng, từ đó có thể thiết kế và phát triển sản phẩm hoặc giải pháp phù hợp hơn với nhu cầu của họ. Ngoài ra, việc tham gia vào nhiều đại diện người dùng còn giúp chúng ta nhận ra và giải quyết được những rủi ro tiềm ẩn mà chúng ta có thể bỏ qua nếu chỉ dựa vào một đại diện duy nhất.

Khi có mâu thuẫn giữa phát triển sản phẩm và khách hàng, cách giải quyết vấn đề này là rất quan trọng. Trước hết, chúng ta cần hiểu rằng khách hàng là người sử dụng sản phẩm và họ có nhu cầu, mong muốn cụ thể. Tuy nhiên, phát triển sản phẩm cũng cần phải đảm bảo rằng sản phẩm đó đáp ứng được các mục tiêu kinh doanh của công ty. Vì vậy, khi có mâu thuẫn, chúng ta cần phải cân nhắc và tìm ra giải pháp phù hợp nhất. Giải pháp tốt nhất là khách hàng được ưu tiên, nhưng phải đảm bảo rằng ưu tiên đó vẫn nằm trong phạm vi mục tiêu kinh doanh của công ty. Điều này giúp đảm bảo rằng sản phẩm đáp ứng được nhu cầu của khách hàng và vẫn đạt được mục tiêu kinh doanh.

Các tiêu chí chấp nhận (Acceptance Criteria) là một phần quan trọng trong quy trình phát triển phần mềm. Nó bao gồm các điều kiện cần được đáp ứng để một yêu cầu của người dùng được coi là đã được thực hiện đúng. Các tiêu chí chấp nhận thường bao gồm các yếu tố sau: - Đảm bảo phần mềm đáp ứng được các yêu cầu chức năng (functional requirements) của người dùng. Điều này có thể được thực hiện thông qua việc chạy các thử nghiệm chấp nhận (acceptance tests) được định nghĩa dựa trên các yêu cầu của người dùng. - Đảm bảo phần mềm đáp ứng được các yêu cầu không chức năng (nonfunctional requirements) như hiệu suất, bảo mật, độ tin cậy, v.v. - Theo dõi các lỗi và vấn đề mở (open defects and issues) để đảm bảo rằng phần mềm được phát triển và thử nghiệm một cách hiệu quả. - Các tiêu chí chấp nhận không bao gồm việc có giao diện người dùng (user interface) hiện đại hoặc theo xu hướng.

Trong Agile, Epic là một khái niệm quan trọng giúp định nghĩa mục tiêu và yêu cầu của dự án. Nó đại diện cho một nhu cầu của người dùng hoặc yêu cầu kinh doanh ở mức độ cao, có thể được chia nhỏ thành các câu chuyện người dùng (user stories) nhỏ hơn và dễ quản lý hơn. Ví dụ, một Epic có thể là 'Tăng cường trải nghiệm khách hàng' và được chia nhỏ thành các user stories như 'Tạo trang web mới', 'Tối ưu hóa quá trình thanh toán trực tuyến', v.v. Mục đích của Epic là giúp nhóm phát triển hiểu rõ yêu cầu và mục tiêu của dự án, từ đó có thể lập kế hoạch và triển khai các công việc cần thiết.

Trong các dự án Agile, một epic là một khái niệm quan trọng trong quản lý dự án. Nó được định nghĩa là một tập hợp các user story liên quan đến nhau, thường quá lớn để hoàn thành trong một chu kỳ phát triển (iteration) duy nhất. Điều này có nghĩa là epic có thể bao gồm nhiều user story khác nhau, và nó có thể được thực hiện trong nhiều chu kỳ phát triển khác nhau. Epic cũng có thể được coi là một trong những tính năng quan trọng nhất của dự án, vì nó thường liên quan đến các yêu cầu chính của khách hàng.

Mục tiêu chính của quản lý rủi ro trong các dự án phần mềm là xác định và đánh giá các mối đe dọa tiềm ẩn có thể ảnh hưởng đến dự án. Quá trình này giúp các nhà phát triển phần mềm nhận thức được những rủi ro tiềm ẩn và có thể chuẩn bị các biện pháp phòng ngừa hoặc giảm thiểu tác động của chúng. Bằng cách xác định các mối đe dọa tiềm ẩn, các nhà phát triển phần mềm có thể tạo ra các kế hoạch dự phòng và thực hiện các biện pháp để giảm thiểu rủi ro, từ đó đảm bảo dự án được thực hiện một cách hiệu quả và an toàn.

Để quản lý rủi ro hiệu quả, cần phải hiểu rõ các yếu tố cơ bản của quá trình này. Trong đó, có ba yếu tố quan trọng là đánh giá rủi ro (Risk assessment), kiểm soát rủi ro (Risk control) và giảm thiểu rủi ro (Risk reduction). Đánh giá rủi ro giúp xác định mức độ nghiêm trọng của rủi ro, từ đó có thể đưa ra quyết định về cách thức xử lý. Kiểm soát rủi ro liên quan đến việc thực hiện các biện pháp để ngăn chặn hoặc giảm thiểu rủi ro. Giảm thiểu rủi ro là quá trình tìm kiếm các giải pháp để giảm thiểu tác động tiêu cực của rủi ro. Ba yếu tố này thường được sử dụng cùng nhau để tạo thành một hệ thống quản lý rủi ro toàn diện.

Giải pháp yêu cầu theo dõi (requirements tracing) là một công cụ quan trọng trong quản lý dự án. Nó cho phép tạo liên kết giữa các nhiệm vụ trong kế hoạch dự án và tiến độ phát triển. Điều này giúp tăng cường theo dõi dự án, đảm bảo rằng các nhiệm vụ được thực hiện đúng theo kế hoạch. Ngoài ra, yêu cầu theo dõi còn giúp xác định các yêu cầu chưa được đáp ứng và cần phải bổ sung. Điều này giúp giảm thiểu chi phí phát triển và tăng cường chất lượng sản phẩm cuối cùng.

Để xử lý một yêu cầu thay đổi, có bốn nhiệm vụ cần được thực hiện. Trước hết, chúng ta phải đánh giá yêu cầu thay đổi (evaluate change request). Tiếp theo, chúng ta phải đưa ra quyết định thay đổi (make change decision). Sau đó, chúng ta phải thực hiện thay đổi (implement the change). Cuối cùng, chúng ta phải kiểm tra lại thay đổi (verify the change) để đảm bảo rằng nó đã được thực hiện đúng cách và không có lỗi nào.

Câu hỏi này yêu cầu bạn xác định thông tin không liên quan đến dự án được giao ngoài (outsourced projects). Các lựa chọn bao gồm: - Nó tận dụng kỹ năng phát triển có sẵn trong nội bộ. - Đó là khó khăn hơn để có được ý kiến của nhà phát triển về yêu cầu và để chuyển lại phản hồi của người dùng về phần mềm đã được giao cho nhà phát triển. - Cần có định nghĩa hợp đồng chính thức về yêu cầu, điều này có thể dẫn đến tranh chấp nếu sự khác biệt trong việc giải thích được phát hiện muộn trong dự án. Câu trả lời đúng là: Nó tận dụng kỹ năng phát triển có sẵn trong nội bộ. Vì dự án được giao ngoài thường không tận dụng kỹ năng phát triển có sẵn trong nội bộ mà thay vào đó là thuê ngoài để thực hiện.

Trong phát triển agile, các câu chuyện người dùng (user stories) và các câu chuyện lớn (epics) là hai khái niệm quan trọng. Câu chuyện người dùng là những tuyên bố ngắn gọn và rõ ràng về nhu cầu của người dùng, giúp khởi đầu cho các cuộc thảo luận chi tiết. Các câu chuyện lớn, hoặc epics, là những câu chuyện người dùng quá lớn để được triển khai trong một chu kỳ phát triển (iteration) duy nhất. Vì vậy, chúng thường được chia nhỏ thành nhiều câu chuyện người dùng nhỏ hơn để dễ dàng triển khai.

Trong quá trình phát triển phần mềm, yêu cầu (requirements) đóng vai trò quan trọng. Chúng không chỉ ảnh hưởng đến kế hoạch dự án mà còn tác động trực tiếp đến quá trình thiết kế và viết mã nguồn. Yêu cầu cũng giúp xác định các hoạt động kiểm tra và thử nghiệm, đảm bảo rằng sản phẩm cuối cùng đáp ứng được các tiêu chuẩn và yêu cầu đã được đặt ra. Vì vậy, yêu cầu (requirements) là nền tảng quan trọng để xây dựng một sản phẩm phần mềm chất lượng cao.

Các yếu tố sau đây có thể ngăn cản việc tái sử dụng yêu cầu. Yêu cầu được viết bằng ngôn ngữ tự nhiên có thể chứa các sự không rõ ràng, thiếu thông tin và giả định ẩn. Điều này có thể dẫn đến việc khó khăn trong việc hiểu và thực hiện yêu cầu. Vì vậy, việc tái sử dụng yêu cầu sẽ gặp khó khăn khi yêu cầu không được viết rõ ràng và chính xác.