Software Requirements. First Edition – MS Press. Chương 5 – Yêu cầu phần mềm và quản lý rủi ro

Tác giả: Karl E. Wiegers

Người dịch: Hoàng Xuân Thịnh

Dave, quản lý dự án của Chemical Tracking System tại Contoso Pharmaceuticals, đang có cuộc gặp với trưởng nhóm lập trình Helen và trưởng nhóm kiểm thử Ramesh. Tất cả đều đang vui mừng về dự án mới và họ nhớ lại một số vấn đề đã gặp trong dự án trước đây gọi là Pharm-Simulator.

“Hãy nhớ lại xem chúng ta đã không phát hiện ra người dùng ghét cái giao diện của Simulator như thế nào cho đến tận lần kiểm thử beta?” Helen hỏi. “Chúng ta đã mất 5 tuần để xây dựng lại hệ thống và kiểm thử lại. Tôi không hề muốn lặp lại việc đó một lần nữa.”

“Chả vui vẻ tí nào cả”, Dave nói. “Điều khó chịu nữa là người dùng nói họ muốn rất nhiều tính năng nhưng thực tế thì chả ai sử dụng sau này cả. Vậy hãy trao đổi với họ ít nhất 3 lần trước khi biết chúng ta có nên viết một tính năng nào đó, nếu không hãy bỏ nó đi ngay. Vớ vẩn thật!”

“Chúng ta đã xông vào Simulator quá sớm và không có đủ thời gian để viết các yêu cầu chi tiết,” Ramesh nhớ lại. “Một nửa thời gian của mấy ông kiểm thử là đi hỏi mấy ông lập trình xem chương trình có những tính năng nào để mà kiểm thử. Đến khi kiểm thử lại thấy là các chức năng mà mấy ông lập trình đã viết lại hoàn toàn  không phải là cái mà người dùng mong muốn.”

“Tôi thật sự bực bội khi bà quản lý bộ phận đề nghị xây dựng Pharm-Simulator đã ký trên bản yêu cầu mà chẳng hề đọc qua xem nó thế nào”, Dave thêm vào. “Cho đến khi chúng ta nhận được cả dòng thác các đề xuất và thay đổi yêu cầu từ những người thuộc bộ phận ấy. Chả có gì ngạc nhiên khi dự án chậm đến 4 tháng và chi phí thì hầu như tăng gấp đôi so với ngân sách. Nếu điều đó xảy ra lần nữa, chắc tôi điên mất!”

Ramesh đề nghị. “Hay là chúng ta lập một danh sách các vấn đề mà ta đã gặp trong Simulator từ đó ta dễ tránh được các vấn đề tương tự có thể có trong dự án Chemical Tracking System. Tôi đã đọc một bài báo về quản lý rủi ro phần mềm, họ khuyên chúng ta nên chỉ ra các rủi ro và phác thảo kế hoạch phòng ngừa chúng.”

“Tôi không biết về cái đó,” Dave nói. “Chúng ta đã học được rất nhiều từ Simulator và chúng ta đều không muốn các vấn đề tương tự như vậy từ dự án này nữa. Dự án này không lớn đến mức cần phải quản lý rủi ro. Nếu chúng ta viết ra những gì có thể gây rắc rối cho Chemical Tracking System thì điều đó có vẻ như là tôi không biết làm thế nào để thực hiện dự án một cách thành công. Tôi không muốn bất cứ những suy nghĩ trái chiều nào đối với dự án này. Chúng ta cần phải lập kế hoạch cho dự án thành công!”


Khi Dave nói ra đề xuất cuối cùng thì đúng là các kỹ sư phần mềm là những người lạc quan đáng khâm phục. Chúng ta thường hy vọng dự án tới sẽ được tiến hành suôn sẻ mặc dù chúng ta đã gặp vô số rắc rối khi thực hiện các dự án trước. Thực tế là có hàng tá các rắc rối ngăn cản dự án được tiến hành đúng như kế hoạch đã định. Vì vậy một lời khuyên hữu ích đối với các nhà quản lý là hãy định danh các rủi ro có thể có và hãy làm thế nào để phòng tránh chúng hơn là cứ cố ra vẻ lạc quan như vậy, trước hết là hãy bắt đầu với các rủi ro từ yêu cầu.

Một rủi ro là một tác động vào tiến trình dự án và có thể gây ra một số cản trở hoặc thậm chí làm thất bại dự án. Quản lý rủi ro – một best practice của công nghiệp phần mềm – là một quy trình định danh, đánh giá, kiểm soát rủi ro trước khi chúng có thể gây phiền phức cho dự án. Nếu một cái gì đó không mong muốn nhưng đã xảy ra và tác động xấu vào dự án thì cái đó không phải là rủi ro, đó là một hậu quả (issue) của rủi ro. Hãy giải quyết các vấn đề và hậu quả thông qua quy trình giám sát dự án.

Khó có thể dự đoán được độ chắc chắn xảy ra hay không xảy ra với mức độ nào của các rủi ro, nhưng quản lý rủi ro giúp bạn thực hiện các hành động để tối thiểu hóa khả năng xảy ra rủi ro. Quản lý rủi ro nghĩa là giải quyết các vấn đề tiềm tàng trước khi nó xảy ra và gây hậu quả xấu, hoặc gây ra khủng hoảng, nhằm tăng cơ may thành công của dự án. Các rủi ro nằm bên ngoài tầm kiểm soát của dự án cần được chỉ mặt, đặt tên ở mức quản lý thích hợp.

Do các yêu cầu đóng vai trò trung tâm trong các dự án phần mềm nên các nhà quản lý dự án cần định danh các rủi ro liên quan đến yêu cầu ngay từ sớm và có các kiểm soát thích hợp. Các rủi ro điển hình liên quan đến yêu cầu bao gồm không hiểu yêu cầu, không bao quát hết người dùng, sự không chắc chắn của phạm vi và mục tiêu của dự án, sự thay đổi liên tục các yêu cầu của dự án. Các nhà quản lý dự án chỉ có thể kiểm soát rủi ro yêu cầu thông qua sự hợp tác với khách hàng hoặc các đại diện của họ, ví dụ các nhân viên marketing. Các rủi ro yêu cầu cần được ghi thành tài liệu và lập kế hoạch giảm bớt hoặc loại bỏ.

Chỉ nhận biết rủi ro thì không làm mất rủi ro, vì vậy Chương này giới thiệu một số kỹ thuật quản lý rủi ro phần mềm. Một số yếu tố rủi ro có thể tăng nên cùng quá trình phát triển dự án và điều đó sẽ được mô tả trong phần sau của Chương này. Hãy sử dụng thông tin này để khởi động tiến trình tấn công các rủi ro yêu cầu trước khi chúng tấn công bạn.

I. CƠ SỞ CỦA QUẢN LÝ RỦI RO PHẦN MỀM (FUNDAMENTALS OF SOFTWARE RISK MANAGEMENT)

Dự án phải đối mặt với nhiều loại rủi ro, chưa kể các rủi ro liên quan đến phạm vi dự án. Phải phụ thuộc vào một đối tác bên ngoài là một rủi ro hay gặp, ví dụ một nhà thầu hoặc một dự án khác sản xuất ra các components được sử dụng lại. Quản lý dự án hay phải đối mặt với các rủi ro nảy sinh từ sự kém chính xác của các ước lượng trước khi tiến hành dự án. Các rủi ro liên quan đến công nghệ gây ra các nguy cơ to lớn khi phát triển dự án. Sự thiếu hiểu biết về các nguồn rủi ro cũng là nguồn gốc của rủi ro… Quản lý rủi ro giống như việc bạn đi trên một con tàu và từng lúc một bạn nhìn xa về phía chân trời để xem có núi băng nào không, nếu có thì kịp thời tránh va chạm với nó hoặc va chạm nhẹ nhất có thể, điều này quan trọng hơn là khả năng hành động nhanh với một niềm tin to lớn rằng tàu của bạn sẽ không thể bị chìm. Cũng như các quy trình khác, hãy cân chỉnh các hoạt động quản lý rủi ro theo kích thước dự án của bạn. Các dự án nhỏ có thể chỉ cần lập một danh sách quản lý rủi ro đơn giản, còn các dự án lớn thì cần phải lập kế hoạch quản lý rủi ro một cách chính thức.

1. CÁC YẾU TỐ CỦA QUẢN LÝ RỦI RO (ELEMENTS OF RISK MANAGEMENT)

Quản lý rủi ro là ứng dụng các công cụ và thủ tục thích hợp để kiềm chế rủi ro dự án trong một giới hạn có thể chấp nhận. Quản lý rủi ro đề xuất một cách tiếp cận tiêu chuẩn để định danh và tài liệu hóa các yếu tố rủi ro, đánh giá độ nghiêm trọng tiềm tàng của nó, đề xuất các chiến lược để giảm bớt rủi ro đó (Williams, Walker, and Dorofee 1997). Quản lý rủi ro bao gồm các hoạt động sau trong Hình 5-1.

Đánh giá rủi ro (risk assessment) là quy trình khảo sát một dự án để xác định các vùng rủi ro tiềm tàng. Trước hết là định danh rủi ro (risk identification) thông qua một danh sách các rủi ro thường gặp trong một dự án phần mềm và sẽ được mô tả sau trong chương này (Carr et al. 1993, McConnell 1996). Tiếp theo là phân tích rủi ro (risk analysis), nghĩa là bạn dự đóan tất cả các hậu quả (consequences) của các rủi ro đó. Sau cùng là ưu tiên hoá rủi ro (risk prioritization), nghĩa là bạn sẽ tập trung xử lý các rủi ro nghiêm trọng nhất thông qua khả năng phá hủy tiềm tàng của rủi ro (potential risk exposure). Khả năng phá hủy tiềm tàng của rủi ro là một hàm của 2 biến: thứ nhất là khả năng gánh chịu mất mát do rủi ro, thứ hai là độ lớn của các mất mát đó.

Tránh rủi ro (risk avoidance) là một cách để giải quyết rủi ro: không thực hiện những gì là rủi ro (don’t do the risky thing). Bạn có thể tránh rủi ro bằng cách không đảm trách các dự án rủi ro, bằng cách chỉ sử dụng các công nghệ đã được thực tế chứng minh thay vì các công nghệ mới xuất hiện, bằng cách loại trừ các tính năng sẽ đặc biệt gây khó khăn cho bạn sau này.

Nhưng thông thường bạn sẽ phải thực hiện các hoạt động kiểm soát rủi ro (risk control) để quản lý các rủi ro đã được xếp thứ tự ưu tiên. Lập kế hoạch quản lý rủi ro (risk management planning) là đưa ra một kế hoạch giải quyết mỗi rủi ro nghiêm trọng như những cách tiếp cận giảm bớt rủi ro (risk mitigation approaches), kế hoạch liên tục nghiệp vụ (contigency plans). Sau khi đã có các kế hoạch tránh rủi ro, hãy triển khai thực hiện chúng, hoạt động đó là phân giải rủi ro (risk resolution). Cuối cùng hãy giám sát tiến độ phân giải mỗi rủi ro thông qua hoạt động giám sát rủi ro (risk monitoring).

2. TÀI LIỆU HOÁ RỦI RO DỰ ÁN (DOCUMENTING PROJECT RISKS)

Bạn không chỉ đơn giản nhận biết các rủi ro đối với dự án mà còn cần phải tài liệu hoá và quản lý chúng sao cho bạn có thể thông báo về các hậu quả và trạng thái của chúng tới tất cả các stakeholders trong toàn bộ tiến trình dự án. Hình 5-2 là một mẫu tài liệu hoá một yếu tố rủi ro (risk item).

MẪU GIÁM SÁT YẾU TỐ RỦI RO

(RISK ITEM TRACKING TEMPLATE)

ID: <số hiệu của rủi ro>

Ngày phát hiện: <ngày rủi ro được định danh>

Ngày xử lý: <ngày rủi ro được đưa vào quản lý>

Mô tả: <mô tả rủi ro theo mẫu “điều kiện – hậu quả”>

Xác suất: <khả năng rủi ro trở thành hiện thực>

Ảnh hưởng: <sự phá hủy tiềm tàng nếu như rủi ro trở thành hiện thực>

Kế hoạch giảm bớt rủi ro: <một trong nhiều cách tiếp cận để kiểm soát, tránh, tối thiểu hoá, hoặc giảm bớt rủi ro>

Chịu trách nhiệm: <cá nhân chịu trách nhiệm phân giải rủi ro>

Ngày hoàn thành: <ngày dự kiến kế hoạch giảm bớt rủi ro được hoàn thành>

Hình 5-2 Mẫu giám sát mỗi rủi ro

Bạn có thể lưu trữ bảng này dưới dạng một bảng tính để dễ sắp xếp các rủi ro. Lưu giữ bảng này như tài liệu duy nhất về quản lý rủi ro trong toàn bộ dự án.

Dùng cách mô tả điều kiện – hậu quả (condition – consequense) khi bạn xây dựng tài liệu về các rủi ro. Nghĩa là, mô tả điều kiện mà bạn quan tâm, tiếp theo là hậu quả từ điều kiện đó – rủi ro đã trở thành một vấn đề thật sự. Thông thường, người ta chỉ mô tả các trạng thái rủi ro (risk state) như là các điều kiện (“khách hàng không thoả thuận về yêu cầu sản phẩm”) hoặc chỉ nói về hậu quả (“chúng ta chỉ có thể đáp ứng một trong bốn khách hàng chính”). Hãy ghép các câu này thành dạng điều kiện – hậu quả: “khách hàng không thỏa thuận về các yêu cầu sản phẩm, vậy chúng ta chỉ có thể đáp ứng một trong bốn khách hàng chính.” Một điều kiện có thể sinh ra một số hậu quả, hoặc một số điều kiện có thể sinh ra một hậu quả.

Đừng cố gắng lượng hoá các rủi ro quá chính xác. Mục đích của bạn chỉ là phân biệt và xếp hạng các rủi ro theo nguy cơ của chúng mà thôi. Bạn có thể làm đơn giản hơn bằng cách ước lượng cả xác suất và ảnh hưởng theo 3 cấp low, medium, low.

Sử dụng Kế hoạch giảm bớt rủi ro để xác định các hành động cần thiết nhằm kiểm soát rủi ro. Một số kế hoạch chú trọng giảm xác suất xảy ra rủi ro, số khác lại tập trung giảm bớt ảnh hưởng của rủi ro. Hãy cân nhắc chi phí khi lập kế hoạch, không cần phải tiêu 20.000 USD để lập kế hoạch cho một rủi ro đáng giá 10.000 USD. Gán mỗi kế hoạch cho một người chịu trách nhiệm và định ngày hoàn thành. Các rủi ro dài hạn hoặc phức tạp cần nhiều bước tiến hành.

Hình 5-3 minh hoạ một rủi ro mà nhóm dự án Chemical Tracking System đã thảo luận ở đầu Chương này.

VÍ DỤ VỀ MẪU GIÁM SÁT MỘT RỦI RO CỦA CHEMICAL TRACKING SYSTEM

ID: 1

Ngày phát hiện: 04/05/1999

Ngày xử lý: mở

Mô tả: người dùng không tham gia đầy đủ ở mức cần thiết khi suy luận yêu cầu, từ đó dẫn tới có thể phải làm lại giao diện người dùng sau khi kiểm thử beta.

Xác suất: 0,6

Ảnh hưởng: 7

Kế hoạch giảm bớt rủi ro:

  1. Thu thập các yêu cầu dễ nắm bắt và khả dụng ngay từ sơm trong giai đoạn 1.
  2. Tổ chức các phiên JAD với những người trợ giúp sản phẩm (product champions) để phát triển yêu cầu.
  3. Phát triển một nguyên mẫu giao diện người dùng tạm thời (throwaway user interface prototype) của các chức năng chính (core functionality) với sự giúp đỡ của những người trợ giúp sản phẩm và các chuyên gia tư vấn. Đề nghị người trợ giúp sản phẩm và những người dùng khác đánh giá nguyên mẫu.

Chịu trách nhiệm: Helen

Ngày hoàn thành: Hoàn thành phiên JAD ngày 16/6/1999

Hình 5-2 Mẫu giám sát mỗi rủi ro

Nhóm ước lượng xác suất và ảnh hưởng trên cơ sở các kinh nghiệm đã có từ các dự án trước. Hai cách tiếp cận giảm rủi ro đầu giảm xác suất xảy ra rủi ro bằng cách lôi kéo người dùng tham gia vào quy trình yêu cầu. Cách thứ ba là làm nguyên mẫu, cách này sẽ làm giảm bớt ảnh hưởng tiềm tàng của rủi ro bằng cách làm lại sớm giao diện người dùng.

3. LẬP KẾ HOẠCH QUẢN LÝ RỦI RO (PLANNING FOR RISK MANAGEMENT)

Một danh sách các rủi ro thì không phải là một kế hoạch quản lý rủi ro. Với một dự án nhỏ, bạn có thể bao hàm kế hoạch kiểm soát rủi ro vào kế hoạch tổng thể của dự án. Nhưng với một dự án lớn thì bạn phải có một kế hoạch quản lý rủi ro riêng. Kế hoạch này cần chỉ rõ vai trò và trách nhiệm của các hoạt động quản lý rủi ro.

Thông thường, các nhóm dự án lập kế hoạch hoạt động của họ nhưng họ lại thất bại trong việc sử dụng kế hoạch như là một hướng dẫn cách thực hiện dự án và kiểm soát các thay đổi. Đừng làm như thế với kế hoạch quản lý rủi ro!

II. CÁC RỦI RO LIÊN QUAN ĐẾN YÊU CẦU (REQUIREMENTS – RELATED RISKS)

Các yếu tố rủi ro mô tả trong các trang sau được tổ chức theo các giai đoạn của quy trình công nghệ yêu cầu: suy luận, phân tích, đặc tả, kiểm tra và quản lý (elicitation, analysis, specification, verification, management). Các kỹ thuật được đề xuất có thể giảm bớt xác suất biến rủi ro thành vấn đề, hoặc giảm bớt ảnh hưởng đến dự án nếu nó xảy ra.

1. SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION)

Tầm nhìn và phạm vi của sản phẩm (Product vision and scope)

Vấn đề đối với phạm vi dự án là các thành viên không có một hiểu biết chung, sáng rõ về mục đích của sản phẩm là gì. Ngay từ sớm khi bắt đầu dự án, bạn đã phải viết một tài liệu về tầm nhìn và phạm vi (vision and scope) chứa đựng các yêu cầu kinh doanh (business requirements), sử dụng tài liệu này làm cơ sở cho các quyết định liên quan đến sửa đổi và bổ sung các yêu cầu mới.

Thời gian dành cho phát triển yêu cầu (Time spent on requirements development)

Lịch biểu chặt chẽ thường gây áp lực cho các nhà quản lý khiến họ che đậy đi các yêu cầu do họ tin rằng nếu các lập trình viên không bắt đầu làm việc ngay thì họ sẽ không đáp ứng được lịch biểu. Các thông số của mỗi dự án biến đổi theo kích thước và miền ứng dụng của nó (hệ thống thông tin quản lý, phần mềm hệ thống, phần mềm quân sự…), nhưng người ta thấy thường các dự án tiêu tốn khoảng 15% nguồn lực (thời gian, con người, tiền bạc) cho các hoạt động phát triển yêu cầu (Rubin 1999). Hãy ghi chép lại thời gian mà bạn đã sử dụng cho các dự án cụ thể khác nhau để dùng nó làm tham số hiệu chỉnh các dự án tương lai của bạn.

Tính đầy đủ và tính đúng đắn của đặc tả yêu cầu (Completeness and correctness of requirements specification)

Để đảm bảo các yêu cầu mô tả đúng cái khách hàng cần, bạn hãy ứng dụng kỹ thuật use-case để suy luận các yêu cầu bằng cách tập trung vào các hành động thực hiện công việc (tasks) của người dùng. Hãy nghĩ ra các kịch bản sử dụng cụ thể, hãy viết các test cases từ các yêu cầu, hãy tạo ra các nguyên mẫu để các yêu cầu trở nên dễ nhận biết đối với người dùng và hãy suy luận dựa vào các phản hồi của họ. Hãy tranh thủ tình cảm của đại diện các khách hàng, để thanh tra (inspect) các đặc tả yêu cầu và các mô hình phân tích.

Yêu cầu cho sản phẩm mang tính sáng tạo cao (Requirements for hight innovative products)

Rất dễ dàng nhận định sai về phản ứng của thị trường đối với sản phẩm khi mới được tung ra. Hãy tập trung nhiều cho các hoạt động nghiên cứu thị trường, xây dựng các nguyên mẫu, sử dụng các nhóm định hướng khách hàng (customer focus groups) để đạt được ngay từ sớm và thường xuyên về viễn cảnh của sản phẩm mang tính sáng tạo (innovative product visions).

Định nghĩa các yêu cầu phi chức năng (Define nonfunctional requirements)

Do sự nhấn mạnh tự nhiên của nhóm phát triển vào chức năng của sản phẩm nên họ rất dễ xao lãng các yêu cầu phi chức năng. Hãy tham vấn khách hàng về các đặc tính chất lượng như hiệu năng (performance), khả năng sử dụng (usability), tính toàn vẹn (integrity) và độ tin cậy (reliability). Tài liệu hoá các yêu cầu phi chức năng và các tiêu chuẩn chấp nhận (acceptance criteria) càng chính xác càng tốt trong SRS.

Thỏa thuận của khách hàng về các yêu cầu sản phẩm (Customer agreement on product requirements)

Nếu có những khách hàng không thỏa thuận về những gì mà bạn cần xây dựng thì sẽ có ai đó không hài lòng khi nhận được sản phẩm. Vậy hãy xác định ai là khách hàng chính, hãy sử dụng những người trợ giúp sản phẩm để đảm bảo chắc chắn bạn có được ý kiến đầy đủ của tất cả khách hàng và những người liên quan đến sản phẩm. Hãy chắc chắn bạn trao đổi đúng người khi cần ra các quyết định liên quan đến yêu cầu.

Các yêu cầu không xác định (Unstated requirements)

Khách hàng sẽ ghi nhớ trong đầu họ các mong muốn mà họ không nói ra và vì vậy không được ghi thành tài liệu. Hãy xác định và ghi nhớ bất cứ cái gì khách hàng có thể đặt ra. Sử dụng các câu hỏi mở để khuyến khích khách hàng chia sẻ nhiều hơn ý nghĩ, ý tưởng và các quan tâm của họ, bạn sẽ thu nhận được nhiều hơn những gì bạn nghe thấy.

Các sản phẩm đang sử dụng được coi như là ranh giới yêu cầu (Existing product used as requirements baseline)

Phát triển yêu cầu không được coi trọng đối với các dự án tái xây dựng quy trình (reengineering projects) tức là các dự án nâng cấp. Các nhà phát triển thường được bảo là hãy sử dụng hệ thống đã có như là nguồn yêu cầu, “hãy loại trừ các lỗi đã biết và thêm các tính năng mới”. Nhà phát triển sẽ lượm lặt các yêu cầu mới thông qua tiến trình tái xây dựng sản phẩm hiện có. Tuy nhiên, tiến trình tái xây dựng là một cách thức làm việc không hiệu quả và không đầy đủ để phát hiện các yêu cầu, và sẽ không ai ngạc nhiên nếu hệ thống mới có những hạn chế y như hệ thống cũ. Hãy tài liệu hoá các yêu cầu mà bạn phát hiện thông qua tiến trình tái cơ cấu và đề nghị khách hàng soát xét các yêu cầu đó để đảm bảo chúng vẫn còn có ích.

Giải pháp được đề xuất từ nhu cầu (Solution presented as needs)

Các giải pháp do người dùng đề xuất có thể che lấp đi các nhu cầu thật sự của người dùng và khiến cho việc tự động hoá các quy trình nghiệp vụ (business process) không hiệu quả, hoặc gây áp lực khiến nhà phát triển đưa ra các thiết kế kém cỏi. Nhà phân tích cần phải “chui sâu” để hiểu được thật sự ngụ ý ẩn đằng sau các giải pháp mà khách hàng đề xuất là gì. Nhìn chung, khách hàng chỉ nên là người đề ra nhu cầu và chính người phát triển mới là người đề xuất giải pháp.

2. PHÂN TÍCH YÊU CẦU (REQUIREMENTS ANALYSIS)

Ưu tiên hoá yêu cầu (Requirements prioritization)

Đảm bảo mỗi yêu cầu, mỗi tính năng, mỗi use-case đều được ưu tiên hoá và được phân bổ vào một phiên bản cụ thể của sản phẩm hoặc được phân bổ vào một thời điểm thi công cụ thể (implementation stage). Đánh giá sự ưu tiên của mỗi yêu cầu mới trong sự tương quan với các yêu cầu đã có trước đây đòi hỏi bạn phải có các quyết định đánh đổi thông minh.

Các tính năng khó về mặt kỹ thuật (Technically difficult features)

Đánh giá tính khả thi của mỗi yêu cầu không chỉ diễn ra khi lập kế hoạch mà còn kéo dài cho đến tận khi thi công, do có những tính năng khó thực thi về mặt kỹ thuật, vì vậy bạn phải bám sát diễn biến thi công của dự án để từ đó ra các quyết định thích hợp đối với các tính năng này, các quyết định càng được đưa ra sớm thì càng tốt.

Các công nghệ, phương pháp, ngôn ngữ, công cụ, hoặc thiết bị phần cứng không quen thuộc (Unfamiliar technologies, methods, languages, tools, or hardware)

Đừng đánh giá quá cao khả năng nắm bắt nhanh của nhóm dự án đối với các công nghệ không quen thuộc, hãy xác định mức rủi ro cao khi bắt đầu một công nghệ mới.

3. ĐẶC TẢ YÊU CẦU (REQUIREMENTS SPECIFICATION)

Hiểu yêu cầu (Understanding requirements)

Các hiểu biết khác nhau về yêu cầu giữa nhà phát triển và khách hàng có thể dẫn đến những khoảng cách lớn về kỳ vọng, nghĩa là sản phẩm chuyển giao không đáp ứng được kỳ vọng của khách hàng. Các cuộc thanh tra chính thức tài liệu yêu cầu của các nhóm bao gồm nhà phát triển, kiểm thử viên, khách hàng, có thể làm giảm bớt rủi ro. Các nhà phân tích được đào tạo và có kinh nghiệm về yêu cầu sẽ đặt các câu hỏi đúng cho khách hàng  và viết các đặc tả tốt hơn. Mô hình và các nguyên mẫu thể hiện yêu cầu từ nhiều góc độ khác nhau sẽ để lộ ra các điểm mờ và các yêu cầu nhập nhằng.

Gây áp lực thời gian để thực hiện các TBDs (Time pressure to proceed despite TBDs)

Các yêu cầu chưa được làm rõ thường được đánh dấu TBD (to be determined), sẽ rất rủi ro nếu tiến hành thi công trên các yêu cầu đó. Hãy giao cho các cá nhân cụ thể trách nhiệm phân giải mỗi TBD, phân giải như thế nào và thời hạn phân giải.

Các thuật ngữ nhập nhằng (Ambiguous terminology)

Lập một bảng thuật ngữ (glossary) và từ điển dữ liệu để định nghĩa tất cả các thuật ngữ nghiệp vụ và kỹ thuật (business and technical terms) có thể được diễn giải khác nhau bởi những người đọc khác nhau. Trên thực tế, một thuật ngữ có thể có nghĩa chung, nghĩa kỹ thuật, hoặc nghĩa được xác định trong một phạm vi hẹp. Soát xét SRS có thể giúp những người tham gia đạt được một hiểu biết chung về các thuật ngữ chính.

Thiết kế được bao hàm trong yêu cầu (Design included in requirements)

Cách tiếp cận thiết kế được bao hàm trong SRS có thể đặt ra các ràng buộc không cần thiết về các lựa chọn có thể có đối với các nhà phát triển và có thể ngăn cản việc sáng tạo ra các thiết kế tối ưu. Soát xét các yêu cầu để chắc chắn SRS chỉ nhấn mạnh cái cần làm thay vì làm cái đó như thế nào.

4. KIỂM TRA YÊU CẦU (REQUIREMENTS VERIFICATION)

Các yêu cầu không được kiểm tra (Unverified requirements)

Nếu bạn kiểm tra chất lượng và tính đúng đắn của các yêu cầu trước khi bắt đầu thi công thì việc lập kế hoạch kiểm thử dựa trên yêu cầu, lập các nguyên mẫu sẽ giúp bạn giảm bớt các công việc phải làm lại trong dự án. Hãy lôi kéo khách hàng tham gia các cuộc kiểm tra yêu cầu. Thực hiện  các soát xét tăng dần, phi chính thức, ngoài các soát xét chính thức để phát hiện càng sớm càng tốt các vấn đề trong yêu cầu.

Sự thành thạo khi thanh tra yêu cầu (Inspection proficiency)

Nếu những người thanh tra yêu cầu không biết làm thế nào để thanh tra một cách đúng đắn các tài liệu yêu cầu và làm thế nào để góp phần vào các cuộc thanh tra hiệu quả thì các lỗi nghiêm trọng (serious defects) có thể không được phát hiện. Hãy đào tạo tất cả những người tham gia thanh tra tài liệu yêu cầu. Mời một thanh tra viên có kinh nghiệm làm việc này.

5. QUẢN LÝ YÊU CẦU (REQUIREMENTS MANAGEMENT)

Thay đổi yêu cầu (Changing requirements)

Các vấn đề phát sinh đối với phạm vi của sản phẩm thì có thể sử dụng tài liệu tầm nhìn và phạm vi (vision and scope) như là một chuẩn để chấp nhận thay đổi. Một quy trình suy luận yêu cầu mang tính hợp tác (collaborative) với sự mở rộng các thành viên tham gia có thể giảm bớt đến một nửa các vấn đề về yêu cầu (Jones 1996a). Các hướng dẫn thực hành kiểm soát chất lượng (quality control practices) có thể phát hiện ngay từ sớm các lỗi và làm giảm bớt số lượng các sửa đổi phải thực hiện sau này.

Quy trình thay đổi yêu cầu (Requirements change process)

Các rủi ro sẽ xuất hiện khi các đề xuất thay đổi xuất hiện trong SRS mà chẳng tuân theo một quy tắc nào cả. Bạn cần có một quy trình kiểm soát tất cả các thay đổi được đề xuất, quy trình như vậy bao gồm việc phân tích ảnh hưởng của các thay đổi được đề xuất, một ban kiểm soát thay đổi ra quyết định chấp thuận hay từ chối thay đổi, một công cụ hỗ trợ quản lý thay đổi được sử dụng để tăng hiệu quả làm việc.

Các yêu cầu không được thi công (Unimplemented requirements)

Ma trận lần vết yêu cầu giúp bạn không bỏ sót bất cứ yêu cầu nào khi thiết kế, thi công, kiểm thử. Nó cũng giúp bạn đảm bảo một yêu cầu sẽ không được thực hiện bởi nhiều nhà phát triển do sự thiếu thông tin đầy đủ trên dự án.

Mở rộng phạm vi dự án (Expanding project scope)

Nếu các yêu cầu được định nghĩa không đúng ngay từ đầu, thì phạm vi của dự án sẽ phải được mở rộng sau này. Các đặc tả mơ hồ về sản phẩm có thể tiêu tốn nhiều nỗ lực hơn là tiên liệu của bạn. Các nguồn lực của dự án được phân bổ theo các yêu cầu ban đầu có thể phải điều chỉnh cho đúng với phạm vi đích thực của dự án mà bạn đã biết rõ hơn. Để giảm bớt các rủi ro này, hãy lập kế hoạch dự án thành từng giai đoạn và tăng trưởng dần dần. Thực hiện chức năng cốt lõi trước, các chức năng khác sẽ được thực hiện dần trong các giai đoạn sau của dự án.

III. QUẢN LÝ RỦI RO CẦN THIẾT CHO BẠN (RISK MANAGEMENT IS YOUR FRIEND)

Một nhà quản lý dự án có thể sử dụng các phương pháp quản lý rủi ro để tăng khả năng nhận thức về các nguyên nhân khiến cho dự án trở nên tồi tệ. Các nhà quản lý dự án nên cân nhắc để chọn được những người thích hợp thực hiện công việc suy luận yêu cầu. Các nhà quản lý có kinh nghiệm sẽ chỉ thực hiện dự án khi đã có danh sách các rủi ro, ước lượng khả năng xảy ra của mỗi rủi ro và ảnh hưởng của nó tới toàn dự án.

Các bước tiếp theo
  • Định danh một số rủi ro liên quan đến yêu cầu mà bạn đang phải đối mặt trong dự án hiện tại. Đừng xác định các vấn đề hiện tại như là rủi ro, chỉ chú tâm vào những gì chưa xảy ra thôi. Tài liệu hoá các rủi ro theo khuôn mẫu điều kiện – hậu quả, hãy sử dụng template trong Hình 5-2. Hãy đề xuất ít nhất một cách tiếp cận giảm bớt rủi ro có thể cho mỗi rủi ro.
  • Hãy tổ chức một phiên tập kích não (brainstorming) về rủi ro với sự tham gia của các stakeholders đại diện cho nhà phát triển, marketing, khách hàng, và cấp quản lý. Hãy xác định càng nhiều càng tốt các rủi ro mà bạn có thể gặp. Đánh giá mỗi rủi ro về xác suất xuất hiện và ảnh hưởng tương đối của nó. Sắp xếp các rủi ro thành danh sách giảm dần theo độ xác suất rủi ro để từ đó thấy được 5 rủi ro lớn nhất. Hãy gán mỗi rủi ro cho một cá nhân để thực hiện các hành động giảm bớt rủi ro.
Advertisements

1 phản hồi

Filed under Quản lý yêu cầu phần mềm, Tủ sách Công nghệ thông tin

One response to “Software Requirements. First Edition – MS Press. Chương 5 – Yêu cầu phần mềm và quản lý rủi ro

  1. viettoo

    cảm ơn nhiều, dịch tiếp đi anh

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s