Cách xây dựng tiêu chí thiết kế giải pháp

Trong kỹ thuật hệ thống, quá trình này gắn với việc xác định nhu cầu, yêu cầu và các đặc tính cần được kiểm chứng trong suốt vòng đời hệ thống. ISO/IEC/IEEE 29148 quy định một khuôn khổ cho hoạt động kỹ thuật yêu cầu đối với hệ thống, sản phẩm phần mềm và dịch vụ; ISO/IEC/IEEE 15288 cung cấp khung quy trình vòng đời hệ thống có sự tham gia của các bên liên quan.

Vì vậy, một tiêu chí thiết kế tốt không chỉ trả lời “giải pháp cần có gì?”, mà còn phải giúp trả lời “cần đạt mức nào, trong điều kiện nào, bị giới hạn bởi điều gì và kiểm tra bằng cách nào?”

Tiêu chí thiết kế giải pháp là gì?

Tiêu chí thiết kế giải pháp là tập hợp các điều kiện hoặc thước đo dùng để định hướng việc tạo ra và đánh giá một phương án giải quyết vấn đề.

Có thể hiểu theo chuỗi:

Mục tiêu → Yêu cầu → Ràng buộc → Tiêu chí → Phương án thiết kế → Kiểm tra

Trong đó:

·         Mục tiêu xác định kết quả cuối cùng cần đạt

·         Yêu cầu xác định những gì giải pháp phải đáp ứng

·         Ràng buộc xác định những giới hạn mà giải pháp phải tuân thủ

·         Tiêu chí chuyển các yêu cầu và ràng buộc thành cơ sở để thiết kế, so sánh và kiểm chứng

·         Phương án thiết kế là cách cụ thể được lựa chọn để đáp ứng các tiêu chí

Điểm quan trọng là tiêu chí không nên chỉ là những tính từ như “tốt”, “hiệu quả”, “an toàn” hoặc “linh hoạt”. Nếu một đặc tính có thể đánh giá khách quan, tiêu chí nên được gắn với chỉ số, ngưỡng, điều kiện hoặc phương pháp kiểm tra tương ứng.

INCOSE cũng nhấn mạnh việc xác định yêu cầu cần gắn với việc xác định các chỉ số hiệu năng, xác thực yêu cầu và mô tả cách thức kiểm chứng.

Tiêu chí được xây dựng từ mục tiêu, yêu cầu và ràng buộc như thế nào?

Điểm xuất phát không phải là danh sách tính năng của giải pháp mà là kết quả cần đạt.

1. Xác định mục tiêu cần đạt

Mục tiêu phải mô tả vấn đề hoặc kết quả mà giải pháp cần xử lý.

Ví dụ, nếu mục tiêu là giảm thời gian xử lý một quy trình, tiêu chí không nên dừng ở “giải pháp phải nhanh”. Cần chuyển mục tiêu đó thành một yêu cầu có thể đánh giá, chẳng hạn thời gian xử lý tối đa hoặc mức giảm thời gian kỳ vọng.

Mục tiêu càng rõ thì việc xác định tiêu chí càng ít phụ thuộc vào cảm nhận chủ quan.

2. Tách yêu cầu bắt buộc khỏi mong muốn cải thiện

Không phải mọi mong muốn đều có cùng mức độ ưu tiên.

Có thể phân loại thành:

·         Yêu cầu bắt buộc phải đáp ứng

·         Yêu cầu hiệu năng cần đạt

·         Yêu cầu về chất lượng

·         Yêu cầu về khả năng vận hành hoặc sử dụng

·         Yêu cầu pháp lý, tiêu chuẩn hoặc an toàn

·         Yêu cầu có tính ưu tiên nhưng có thể đánh đổi

Việc phân loại này giúp tránh tình trạng một tiêu chí phụ được đặt ngang hàng với điều kiện bắt buộc.

ISO/IEC/IEEE 29148 được xây dựng để hỗ trợ chính quá trình tạo lập và quản lý các yêu cầu trong vòng đời của hệ thống, sản phẩm và dịch vụ.

3. Xác định ràng buộc

Một giải pháp có thể đạt mục tiêu nhưng vẫn không khả thi nếu vi phạm ràng buộc.

Ràng buộc có thể đến từ:

·         Ngân sách

·         Thời gian

·         Công nghệ

·         Hạ tầng hiện có

·         Nguồn lực

·         Quy định pháp luật

·         Tiêu chuẩn kỹ thuật

·         Điều kiện vận hành

·         Khả năng tích hợp

·         Mức độ rủi ro chấp nhận được

Do đó, tiêu chí thiết kế phải phản ánh cả điều phải đạt và điều không được vượt qua.

Quy trình xây dựng tiêu chí thiết kế giải pháp

Một quy trình có thể triển khai theo sáu bước liên tiếp.

Bước 1: Xác định kết quả cần đạt

Mô tả rõ vấn đề, mục tiêu và kết quả mong muốn.

Câu hỏi cần trả lời là:

Sau khi giải pháp được triển khai, trạng thái nào được xem là thành công?

Nếu chưa trả lời được câu hỏi này, việc xây dựng tiêu chí thường sẽ bị kéo sang mô tả tính năng thay vì kết quả.

Bước 2: Chuyển mục tiêu thành yêu cầu có thể đánh giá

Mỗi mục tiêu cần được phân rã thành những yêu cầu cụ thể hơn.

Ví dụ:

Mục tiêu: giảm thời gian xử lý.

Có thể chuyển thành:

Yêu cầu: thời gian xử lý phải nằm dưới một ngưỡng xác định trong điều kiện vận hành đã quy định.

Cách viết này tạo ra một tiêu chí có thể kiểm tra thay vì một nhận xét chủ quan.

Bước 3: Xác định điều kiện và phạm vi áp dụng

Một tiêu chí không có điều kiện đi kèm có thể trở nên quá rộng.

Chẳng hạn, “hệ thống phải đáp ứng tải cao” chưa đủ rõ nếu không xác định:

·         Tải được đo như thế nào

·         Mức tải nào được xem là cao

·         Điều kiện đo

·         Thời gian duy trì

·         Mức hiệu năng tối thiểu cần giữ

Do đó, mỗi tiêu chí quan trọng nên có đối tượng, giá trị hoặc ngưỡng, điều kiện áp dụng và cách xác minh khi cần thiết.

Bước 4: Xác định phương pháp kiểm chứng

Một tiêu chí chỉ thực sự hữu ích khi có thể xác định được nó đã đạt hay chưa.

Các phương pháp có thể gồm:

·         Đo lường

·         Kiểm tra

·         Phân tích

·         Thử nghiệm

·         Đánh giá tài liệu

·         So sánh với tiêu chuẩn

·         Đối chiếu với dữ liệu vận hành

INCOSE phân biệt rõ các hoạt động verification và validation, trong đó thiết kế cần được kiểm tra so với yêu cầu thiết kế, còn hệ thống được xác nhận dựa trên việc nó có đáp ứng mục tiêu và nhu cầu trong môi trường sử dụng dự kiến hay không.

Bước 5: Kiểm tra xung đột và đánh đổi

Các tiêu chí thường không độc lập.

Ví dụ:

·         Tăng hiệu năng có thể làm tăng chi phí

·         Tăng độ dự phòng có thể làm tăng khối lượng

·         Tăng mức an toàn có thể làm giảm tốc độ

·         Giảm chi phí có thể ảnh hưởng đến độ bền

·         Tăng tính linh hoạt có thể làm hệ thống phức tạp hơn

Vì vậy, bộ tiêu chí phải cho thấy tiêu chí nào là bắt buộc, tiêu chí nào có thể tối ưu và tiêu chí nào có thể đánh đổi.

INCOSE xem việc xác định các chỉ số về hiệu năng, xác thực yêu cầu và quản lý rủi ro là những phần quan trọng trong quá trình phát triển yêu cầu.

Bước 6: Kiểm tra khả năng truy xuất

Mỗi tiêu chí quan trọng nên có thể truy ngược về nguồn gốc:

Mục tiêu → Nhu cầu → Yêu cầu → Tiêu chí → Thiết kế → Phương pháp kiểm chứng

Khả năng truy xuất giúp phát hiện hai lỗi phổ biến: tiêu chí không phục vụ mục tiêu nào và yêu cầu quan trọng nhưng chưa có tiêu chí tương ứng. INCOSE cũng đề cập traceability của yêu cầu từ cấp hệ thống xuống các phần tử phần cứng hoặc phần mềm như một nền tảng của quản lý yêu cầu.

Những nhóm tiêu chí mà giải pháp thường phải phản ánh

Không có một danh sách cố định phù hợp cho mọi bài toán. Nhóm tiêu chí phải phụ thuộc vào mục tiêu và bản chất của giải pháp. Tuy nhiên, một bộ tiêu chí thường cần xem xét các nhóm sau.

Hiệu năng

Phản ánh giải pháp phải thực hiện chức năng với mức độ nào.

Có thể biểu diễn bằng:

·         Thời gian đáp ứng

·         Công suất

·         Tốc độ

·         Độ chính xác

·         Khả năng xử lý

·         Mức tải

·         Tỷ lệ lỗi

Nếu có dữ liệu định lượng hoặc benchmark phù hợp, nên sử dụng chúng thay cho các mô tả như “nhanh”, “mạnh” hoặc “hiệu quả”.

Chất lượng và độ tin cậy

Phản ánh khả năng duy trì kết quả trong điều kiện sử dụng dự kiến.

Tiêu chí có thể liên quan đến:

·         Độ ổn định

·         Tần suất lỗi

·         Độ bền

·         Khả năng phục hồi

·         Thời gian hoạt động

·         Mức suy giảm theo thời gian

An toàn và rủi ro

Xác định những rủi ro nào phải được kiểm soát và mức rủi ro nào có thể chấp nhận.

Đây thường là nhóm tiêu chí có tính ràng buộc cao vì một phương án đạt hiệu năng nhưng không đáp ứng yêu cầu an toàn có thể bị loại ngay.

Chi phí và nguồn lực

Phản ánh giới hạn kinh tế của giải pháp:

·         Chi phí đầu tư

·         Chi phí vận hành

·         Chi phí bảo trì

·         Nguồn lực cần thiết

·         Chi phí vòng đời

Không nên chỉ dùng “chi phí thấp” nếu có thể xác định được ngân sách hoặc ngưỡng chi phí.

Khả năng triển khai và vận hành

Một giải pháp tốt trên thiết kế nhưng không thể triển khai trong môi trường thực tế thì chưa đáp ứng đầy đủ mục tiêu.

Có thể xem xét:

·         Khả năng tích hợp

·         Khả năng mở rộng

·         Khả năng bảo trì

·         Khả năng đào tạo và vận hành

·         Mức độ tương thích với hệ thống hiện có

Tuân thủ

Nếu bài toán chịu sự chi phối của tiêu chuẩn, quy chuẩn hoặc quy định pháp lý, đây có thể là tiêu chí bắt buộc.

ISO/IEC/IEEE 15288 đặt hoạt động phát triển hệ thống trong một khung vòng đời có sự tham gia của các bên liên quan và áp dụng cho nhiều loại hệ thống, từ hệ thống độc lập đến hệ thống tích hợp phức tạp.

Làm thế nào để biết một tiêu chí thiết kế đã đủ tốt?

Một tiêu chí có thể được kiểm tra qua năm câu hỏi.

Thứ nhất, nó có xuất phát từ mục tiêu hoặc yêu cầu thực tế không?

Nếu không truy được nguồn gốc, tiêu chí có nguy cơ chỉ là một đặc tính được thêm vào vì cảm tính.

Thứ hai, nó có đủ cụ thể để phân biệt đạt và không đạt không?

“Dễ sử dụng” yếu hơn một tiêu chí có cách đo hoặc điều kiện đánh giá rõ ràng.

Thứ ba, nó có thể kiểm chứng không?

Nếu không biết dùng phép đo, thử nghiệm, phân tích hay đối chiếu nào để xác minh, tiêu chí chưa đủ chặt.

Thứ tư, nó có điều kiện và giới hạn phù hợp không?

Một giá trị chỉ có ý nghĩa khi biết nó đúng trong hoàn cảnh nào.

Thứ năm, nó có tạo ra giá trị cho quyết định thiết kế không?

Nếu mọi phương án đều đáp ứng hoặc không đáp ứng được tiêu chí đó, tiêu chí có thể không giúp phân biệt các phương án.

Một yêu cầu tốt vì thế không chỉ cần rõ ràng mà còn phải phù hợp với cấp độ và mục đích sử dụng. INCOSE hiện có các hướng dẫn riêng về cách viết yêu cầu và các đặc tính của một tập yêu cầu được hình thành tốt.

Có thể biểu diễn tiêu chí thiết kế bằng cấu trúc nào?

Một cấu trúc thực dụng cho mỗi tiêu chí là:

Đối tượng đặc tính cần đạt mức/giới hạn điều kiện phương pháp kiểm chứng

Ví dụ về mặt cấu trúc:

Giải pháp phải đạt [đặc tính] ở mức [ngưỡng] trong [điều kiện], được xác minh bằng [phương pháp]

Cấu trúc này không phải công thức bắt buộc cho mọi lĩnh vực, nhưng giúp tránh các tiêu chí quá mơ hồ.

Khi có nhiều tiêu chí, nên lập một ma trận để theo dõi:

Giá trị của ma trận không nằm ở hình thức bảng mà ở khả năng duy trì mối liên hệ giữa lý do cần giải pháp và cách xác định giải pháp có đáp ứng hay không.

Tiêu chí thiết kế giải pháp được xây dựng tốt khi chúng tạo thành một chuỗi có thể truy xuất từ mục tiêu → yêu cầu → ràng buộc → tiêu chí → phương án → kiểm chứng. Mục tiêu xác định đích đến; yêu cầu mô tả điều phải đáp ứng; ràng buộc xác định giới hạn; còn tiêu chí biến những điều đó thành cơ sở cụ thể để thiết kế và đánh giá.

Vì vậy, câu hỏi quan trọng nhất khi xây dựng một tiêu chí không phải là “giải pháp này nên có đặc tính gì?”, mà là “đặc tính nào thực sự cần thiết để đạt mục tiêu, trong điều kiện nào, ở mức nào và chúng ta sẽ kiểm chứng nó bằng cách nào?” Khi trả lời được bốn câu hỏi đó, bộ tiêu chí sẽ có khả năng định hướng thiết kế thay vì chỉ mô tả một giải pháp đã được lựa chọn.