SWR302 - Phần 18: Cải tiến quy trình yêu cầu và quản lý rủi ro

Để thay đổi tư duy của đội ngũ dự án về những đau khổ mà tổ chức và khách hàng đã trải qua do vấn đề về yêu cầu, chúng ta cần tránh sử dụng ví dụ không phù hợp. Ví dụ không phù hợp là thể hiện chi phí bằng đơn vị có ý nghĩa đối với tổ chức nhưng không liên quan đến thực tế. Ví dụ như thể hiện chi phí bằng đơn vị vị trí khách hàng, điều này không giúp đội ngũ dự án hiểu được những đau khổ thực sự mà tổ chức và khách hàng đã trải qua. Thay vào đó, chúng ta nên sử dụng ví dụ thể hiện chi phí bằng đơn vị có ý nghĩa đối với tổ chức, chẳng hạn như thời gian, sự không hài lòng của khách hàng, hoặc cơ hội kinh doanh bị mất mát.

Mô hình yêu cầu kỹ thuật (Software Requirements Specification - SRS) là một tài liệu mô tả chi tiết các yêu cầu của hệ thống. Nó được tạo ra trong quá trình phát triển yêu cầu, khi các yêu cầu được xác định, phân tích và xác thực. Vì vậy, SRS thuộc về tài sản quá trình phát triển yêu cầu (Requirements Development Process Assets).

Các khu vực tiềm ẩn rủi ro được liệt kê dưới đây. Hãy xác định khu vực nào thuộc về các phân ngành kỹ thuật của quy trình thu thập yêu cầu (elicitation processes) trong kỹ thuật yêu cầu.

Đáp án đúng gồm ba ý: "Risk assessment", "Risk avoidance" và "Risk control". Quản lý rủi ro (risk management) trong dự án phần mềm gồm ba nhóm việc chính: risk assessment (đánh giá rủi ro) nhận diện, phân tích xác suất và tác động rồi xếp ưu tiên các rủi ro; risk avoidance (né tránh rủi ro) là chọn cách làm khác để rủi ro không còn xảy ra được, chẳng hạn không nhận một yêu cầu quá mạo hiểm; risk control (kiểm soát rủi ro) gồm lập kế hoạch đối phó, thực hiện biện pháp và theo dõi rủi ro suốt dự án. Phương án "Risk reduction" không sai về nghĩa vì giảm thiểu rủi ro là việc thường làm, nhưng nó là một biện pháp cụ thể nằm bên trong kiểm soát rủi ro, không phải một thành phần ngang hàng với ba nhóm trên.

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.

Các nguyên tắc cải tiến quy trình phần mềm bao gồm việc thay đổi mục tiêu, ưu tiên sự đóng góp tập thể và cải tiến liên tục. Trong đó, ưu tiên đóng góp cá nhân hơn là sự hợp tác tập thể không phải là một nguyên tắc của cải tiến quy trình phần mềm. Điều này là vì sự hợp tác và đóng góp tập thể thường được coi là một phần quan trọng của quy trình phần mềm hiệu quả. Ngoài ra, việc ưu tiên sự hợp tác và đóng góp tập thể có thể giúp tăng cường sự sáng tạo, giảm thiểu sai sót và cải thiện hiệu suất công việc. Vì vậy, nguyên tắc này không phù hợp với các nguyên tắc cải tiến quy trình phần mềm.

Một chiến lược tránh rủi ro (risk avoidance) là việc không tham gia vào hoạt động có rủi ro. Điều này có nghĩa là bạn sẽ tránh hoàn toàn hoạt động có khả năng gây ra thiệt hại hoặc tổn thất. Ví dụ, nếu bạn đang xem xét việc đầu tư vào một công ty có lịch sử không tốt, chiến lược tránh rủi ro sẽ là việc không đầu tư vào công ty đó. Thay vào đó, bạn sẽ tìm kiếm các cơ hội đầu tư khác an toàn hơn. Chiến lược tránh rủi ro thường được sử dụng khi rủi ro có thể gây ra thiệt hại nghiêm trọng và không thể được kiểm soát.

Các khu vực tiềm ẩn rủi ro thuộc về các chuyên ngành kỹ thuật yêu cầu là: - Chọn lọc ưu tiên yêu cầu: Đây là quá trình xác định mức độ quan trọng của từng yêu cầu để quyết định ưu tiên thực hiện chúng. - Đặc điểm khó khăn về kỹ thuật: Các tính năng khó khăn về kỹ thuật có thể dẫn đến rủi ro về thời gian, chi phí và chất lượng của dự án. Các quá trình xác minh là: - Chọn lọc ưu tiên yêu cầu và Đặc điểm khó khăn về kỹ thuật đều là các quá trình xác minh trong kỹ thuật yêu cầu.

Mô hình yêu cầu phần mềm (Software Requirements Specification - SRS) là một tài liệu kỹ thuật mô tả các yêu cầu của hệ thống phần mềm. Nó được sử dụng để xác định và mô tả các yêu cầu của hệ thống phần mềm, bao gồm cả các yêu cầu chức năng và không chức năng. Mô hình này thường được sử dụng trong quá trình phát triển phần mềm để đảm bảo rằng các yêu cầu của khách hàng được hiểu và thực hiện đúng. Vì vậy, mô hình yêu cầu phần mềm thuộc về quá trình phát triển yêu cầu phần mềm.

Đáp án đúng: "Increase the complexity of requirements". Cải tiến quy trình yêu cầu nhằm giảm làm lại, giảm chi phí và tăng giá trị dự án mang lại; làm yêu cầu phức tạp hơn đi ngược mục tiêu đó, vì yêu cầu tốt phải rõ ràng, súc tích và dễ kiểm chứng, nên đây là điều không phải mục tiêu. "Improve the accuracy of project estimates" là mục tiêu đúng: yêu cầu đầy đủ và ổn định giúp ước lượng công sức và thời gian sát hơn. "Reduce the cost of creating and maintaining software" cũng đúng vì lỗi yêu cầu phát hiện muộn rất tốn kém để sửa, nên làm yêu cầu tốt từ đầu cắt giảm chi phí cả lúc phát triển lẫn bảo trì. "Increase the value delivered by projects" đúng vì khi hiểu đúng nhu cầu, đội tập trung xây những gì thật sự mang lại giá trị cho khách hàng và tổ chức.

Đáp án đúng: "By considering both the likelihood of occurrence and potential impact of risks". Trong quản lý rủi ro, mỗi rủi ro được đánh giá theo xác suất xảy ra và mức tác động nếu xảy ra; tích của hai đại lượng (độ phơi nhiễm rủi ro, risk exposure) dùng để xếp hạng, nhờ đó nhóm tập trung giảm thiểu những rủi ro vừa dễ xảy ra vừa gây hại lớn. Phương án "By focusing on risks that are least likely to occur" sai vì dồn sức vào rủi ro ít xảy ra là ngược với mục đích ưu tiên. Phương án "By ignoring potential impact and only considering likelihood" sai vì một rủi ro ít khả năng nhưng hậu quả nặng vẫn có thể cần ưu tiên cao, bỏ qua tác động sẽ đánh giá lệch. Phương án "By assuming that all risks are equally important" sai vì coi mọi rủi ro như nhau là không xếp ưu tiên gì cả, nguồn lực giảm thiểu bị dàn trải.

Đáp án đúng: "To identify underlying issues in current practices". Root cause analysis (phân tích nguyên nhân gốc) là kỹ thuật dùng khi cải tiến quy trình yêu cầu: từ một vấn đề quan sát được, như nhiều lỗi do yêu cầu hay thay đổi liên tục, hỏi tiếp tại sao nhiều lần hoặc vẽ sơ đồ xương cá để tìm nguyên nhân sâu xa trong cách làm hiện tại, rồi chọn thực hành mới nhắm đúng nguyên nhân đó thay vì chữa triệu chứng. "To prioritize changes" sai vì xếp ưu tiên thay đổi là việc của ban kiểm soát thay đổi, dựa trên giá trị và chi phí, không phải mục đích của phân tích nguyên nhân gốc. "To assess stakeholder satisfaction" sai vì đo mức hài lòng dùng khảo sát hay phản hồi; kết quả đó có thể là triệu chứng đầu vào nhưng không phải điều kỹ thuật này tìm ra. "To define the scope of the project" sai vì phạm vi dự án được xác định qua tầm nhìn, sơ đồ ngữ cảnh, danh sách tính năng, không liên quan tới cải tiến quy trình.

Đáp án đúng: "To evaluate their effectiveness on a small scale". Trong chu trình cải tiến quy trình yêu cầu, sau khi đánh giá hiện trạng và thiết kế quy trình mới, tổ chức nên chạy thử (pilot) trên một dự án hoặc nhóm nhỏ trước khi áp dụng rộng; việc này cho thấy quy trình có hiệu quả thật không, bộc lộ chỗ cần điều chỉnh với rủi ro thấp và tạo bằng chứng thuyết phục người khác. Phương án "To ensure they are perfect before implementation" sai vì không quy trình nào hoàn hảo, thí điểm nhằm học hỏi và cải tiến dần. Phương án "To skip feedback from participants" ngược lại hoàn toàn, vì phản hồi của người tham gia chính là đầu ra quý nhất của thí điểm. Phương án "To create an abstract understanding without practical testing" sai vì thí điểm chính là kiểm nghiệm thực tế, không phải hiểu biết trừu tượng.