Thuộc tính chất lượng khác gì so với yêu cầu chức năng?

Yêu cầu chức năng xác định hệ thống thực hiện những công việc gì cụ thể (như tính toán hóa đơn hoặc gửi thư điện tử), trong khi thuộc tính chất lượng xác định hệ thống thực hiện các chức năng đó tốt đến mức nào (như tốc độ phản hồi, mức độ an toàn và khả năng hoạt động liên tục).

Kịch bản thuộc tính chất lượng gồm những thành phần nào?

Một kịch bản thuộc tính chất lượng chuẩn hóa gồm sáu thành phần chính: nguồn kích thích, tác nhân kích thích, môi trường hoạt động của hệ thống, đối tượng chịu tác động, phản hồi kỹ thuật của hệ thống và thước đo phản hồi cụ thể có thể định lượng được.

Tại sao các thuộc tính chất lượng luôn phải đánh đổi lẫn nhau?

Các quyết định thiết kế kiến trúc nhằm tối ưu hóa một thuộc tính chất lượng thường tạo ra ràng buộc tiêu cực lên thuộc tính khác. Ví dụ, tăng cường các lớp mã hóa bảo mật có thể làm suy giảm thời gian đáp ứng của hệ thống, đòi hỏi kiến trúc sư phải cân bằng mức độ ưu tiên theo mục tiêu thực tế.

Thuộc tính chất lượng (quality attribute) là gì?

Thuộc tính chất lượng (quality attribute) là đặc tính đo lường hoặc định lượng được của một hệ thống phần mềm, biểu thị mức độ hệ thống thỏa mãn các nhu cầu và kỳ vọng phi chức năng từ phía các bên liên quan. Khác với các yêu cầu chức năng mô tả trực tiếp những tác vụ mà phần mềm phải thực thi, thuộc tính chất lượng phản ánh cách thức và mức độ hiệu quả mà hệ thống thể hiện trong suốt quá trình vận hành cũng như bảo trì. Bài viết này trình bày chi tiết về bản chất khái niệm, cấu trúc phân loại theo các tiêu chuẩn kỹ thuật phần mềm, phương pháp đặc tả bằng kịch bản kiến trúc, các quyết định đánh đổi kỹ thuật và bối cảnh ứng dụng thực tiễn trong kỹ nghệ phần mềm hiện đại.

Bản chất và khái niệm nền tảng trong kiến trúc phần mềm

Trong kỹ nghệ phần mềm, kiến trúc hệ thống không đơn thuần là sự kết hợp ngẫu nhiên của các module mã nguồn mà là cấu trúc nền tảng được định hình nhằm hiện thực hóa các thuộc tính chất lượng mong muốn. Các yêu cầu chức năng thường có thể được đáp ứng thông qua nhiều cấu trúc thiết kế khác nhau, nhưng chính các thuộc tính chất lượng như độ tin cậy, hiệu năng hoạt động, tính bảo mật và khả năng bảo trì mới là yếu tố quyết định lựa chọn mẫu kiến trúc phù hợp.

Theo nghiên cứu của Fairbanks (2023), kiến trúc phần mềm thực chất là một tập hợp các khái niệm trừu tượng giúp kỹ sư tư duy và định hướng các phẩm chất của hệ thống trong suốt vòng đời xây dựng và tiến hóa. Khi các kỹ sư thiết kế phần mềm, việc hiểu rõ các thuộc tính chất lượng giúp họ xây dựng một chuỗi liên kết có chủ đích từ mục tiêu nghiệp vụ cấp cao xuống đến từng thành phần mã nguồn chi tiết.

Các thuộc tính chất lượng thường được chia thành hai nhóm chính dựa trên vòng đời của hệ thống phần mềm:

Thuộc tính trong thời gian vận hành (Runtime Quality Attributes): Bao gồm những đặc tính chỉ có thể quan sát, đo lường và đánh giá khi hệ thống đang chạy thực tế, ví dụ như tính sẵn sàng, hiệu năng xử lý, tính an toàn và khả năng phục hồi sau sự cố.
Thuộc tính trong thời gian phát triển và bảo trì (Design-time / Development-time Quality Attributes): Bao gồm những đặc tính liên quan đến cấu trúc tĩnh của mã nguồn và thiết kế hệ thống, ảnh hưởng trực tiếp đến năng suất làm việc của đội ngũ kỹ sư, ví dụ như tính module hóa, khả năng tái sử dụng, khả năng kiểm thử và khả năng bảo trì.

Yêu cầu có ý nghĩa kiến trúc và mô hình đồng tiến hóa

Không phải mọi yêu cầu trong tài liệu đặc tả đều có tầm ảnh hưởng ngang nhau đối với cấu trúc hệ thống. Các yêu cầu tạo ra tác động đo lường được và định hình trực tiếp lên cấu trúc phần mềm được gọi là yêu cầu có ý nghĩa kiến trúc (Architecturally Significant Requirements, ASR). Trong một khảo sát thực nghiệm quy mô lớn, Chen, Ali Babar và Nuseibeh (2013) đã tiến hành phỏng vấn chuyên sâu 90 chuyên gia phần mềm đến từ hơn 500 tổ chức khác nhau, đại diện cho hơn 1448 năm kinh nghiệm tích lũy trong ngành công nghiệp phần mềm. Kết quả nghiên cứu chỉ ra rằng các thuộc tính chất lượng phi chức năng là một trong những chỉ dấu quan trọng hàng đầu của các yêu cầu có ý nghĩa kiến trúc, đồng thời nhấn mạnh việc nhận diện sớm các yêu cầu này là điều kiện tiên quyết để ngăn ngừa các khiếm khuyết kiến trúc tốn kém.

Mối quan hệ giữa yêu cầu và kiến trúc cũng không diễn ra theo trình tự một chiều tuyến tính. Cleland-Huang và các cộng sự (2013) đã mô tả mô hình Twin Peaks nhằm làm nổi bật quá trình phát triển đồng thời và tương hỗ liên tục giữa không gian bài toán (yêu cầu) và không gian giải pháp (kiến trúc). Theo mô hình này, việc khám phá và tinh chỉnh các thuộc tính chất lượng giúp định hình kiến trúc, đồng thời các ràng buộc kiến trúc lại làm lộ rõ thêm những yêu cầu phi chức năng mới cần được xem xét.

Phân loại thuộc tính chất lượng theo chuẩn mực quốc tế

Để tạo ra một ngôn ngữ chung giữa các kỹ sư phần mềm, quản lý dự án và các bên liên quan, các tổ chức tiêu chuẩn quốc tế đã xây dựng các khung phân loại chất lượng sản phẩm phần mềm. Điển hình trong số đó là bộ tiêu chuẩn quốc tế ISO/IEC 25010 thuộc hệ thống SQuaRE (Systems and software Quality Requirements and Evaluation).

Arvanitou và các cộng sự (2017) đã thực hiện một nghiên cứu lập bản đồ hệ thống phân tích tổng cộng 154 công trình nghiên cứu ban đầu về các thuộc tính chất lượng trong giai đoạn thiết kế. Nghiên cứu đã đối chiếu các thuộc tính được nghiên cứu với khung chuẩn ISO/IEC 25010 và chỉ ra rằng khả năng bảo trì là thuộc tính chất lượng cấp cao thu hút sự quan tâm nghiên cứu lớn nhất của cộng đồng kỹ thuật phần mềm, phản ánh tầm quan trọng sống còn của việc kiểm soát chi phí bảo trì trong vòng đời hệ thống.

Trong phiên bản tiêu chuẩn ISO/IEC 25010 ban hành năm 2011 (phiên bản được Arvanitou và cộng sự đối chiếu năm 2017), mô hình chất lượng sản phẩm bao gồm tám đặc tính chất lượng. Đến phiên bản cập nhật sửa đổi ISO/IEC 25010:2023, tiêu chuẩn đã chính thức bổ sung Tính an toàn (Safety) thành đặc tính chất lượng sản phẩm cấp cao độc lập, nâng tổng số lên chín đặc tính nhằm đáp ứng các yêu cầu khắt khe của các hệ thống điều khiển tự động và an toàn sinh mạng hiện đại.

Các nhóm thuộc tính chất lượng cốt lõi thường được đánh giá bao gồm:

Nhóm thuộc tính chất lượng	Mô tả bản chất kỹ thuật	Ví dụ thước đo định lượng
Hiệu năng hoạt động (Performance Efficiency)	Mức độ hệ thống đáp ứng về mặt thời gian và tài nguyên phần cứng khi xử lý khối lượng công việc xác định.	Thời gian phản hồi tính bằng mili-giây, thông lượng giao dịch trên giây, tỷ lệ chiếm dụng bộ nhớ.
Tính tương thích (Compatibility)	Khả năng hai hoặc nhiều hệ thống hoặc thành phần trao đổi thông tin và cùng chia sẻ môi trường phần cứng hoặc phần mềm.	Tỷ lệ thông điệp chuẩn hóa truyền thành công, khả năng tương tác liên thông giữa các giao thức.
Độ tin cậy (Reliability)	Mức độ hệ thống duy trì hoạt động chính xác trong những điều kiện xác định suốt một khoảng thời gian nhất định.	Thời gian trung bình giữa các lần hỏng hóc, tỷ lệ phục hồi thành công sau lỗi hệ thống.
Tính bảo mật (Security)	Mức độ hệ thống bảo vệ thông tin và dữ liệu, đảm bảo quyền truy cập chỉ dành cho các đối tượng được ủy quyền.	Thời gian phát hiện xâm nhập, tỷ lệ xác thực thành công, mức độ tuân thủ kiểm toán an toàn.
Khả năng bảo trì (Maintainability)	Mức độ dễ dàng và hiệu quả mà hệ thống có thể được sửa đổi, thích ứng hoặc nâng cấp bởi đội ngũ kỹ sư.	Độ kết dính module, mức độ ghép nối giữa các thành phần, độ phức tạp chu trình của mã nguồn.
Tính an toàn (Safety)	Khả năng hệ thống kiểm soát và giảm thiểu các trạng thái rủi ro có thể gây nguy hại cho con người hoặc môi trường xung quanh.	Tỷ lệ kích hoạt cơ chế ngắt an toàn khi có sự cố, mức độ toàn vẹn của trạng thái dừng khẩn cấp.

Đặc tả thuộc tính chất lượng bằng kịch bản kiến trúc

Một trong những sai lầm phổ biến nhất trong kỹ nghệ phần mềm là mô tả thuộc tính chất lượng bằng những tuyên bố mơ hồ và không thể kiểm chứng, chẳng hạn như "hệ thống phải có tính bảo mật cao" hoặc "phần mềm cần phản hồi nhanh". Những phát biểu định tính này không thể dùng làm căn cứ để đưa ra quyết định thiết kế kiến trúc hay đánh giá mức độ đạt yêu cầu.

Kế thừa từ phương pháp phân tích kiến trúc dựa trên kịch bản (SAAM) do Kazman, Abowd, Bass và Clements (1996) khởi xướng, Viện Kỹ nghệ Phần mềm (SEI) sau đó đã chuẩn hóa cấu trúc kịch bản thuộc tính chất lượng (Quality Attribute Scenario) gồm sáu thành phần chặt chẽ:

Nguồn kích thích (Source of stimulus): Thực thể khởi tạo kích thích, có thể là người dùng nội bộ, tác nhân bên ngoài hệ thống hoặc lỗi phần cứng ngẫu nhiên.
Tác nhân kích thích (Stimulus): Điều kiện hoặc sự kiện tác động lên hệ thống, chẳng hạn như một yêu cầu giao dịch mới, một sự cố mất kết nối mạng hoặc một cuộc tấn công từ chối dịch vụ.
Môi trường (Environment): Trạng thái của hệ thống khi sự kiện kích thích xảy ra, ví dụ như trạng thái vận hành bình thường, trạng thái quá tải hoặc trạng thái đang bảo trì.
Đối tượng chịu tác động (Artifact): Thành phần hoặc toàn bộ hệ thống tiếp nhận kích thích, ví dụ như dịch vụ xác thực, cơ sở dữ liệu phân tán hoặc kênh truyền thông tin.
Phản hồi (Response): Hành động cụ thể mà hệ thống thực hiện để xử lý kích thích, chẳng hạn như ghi nhật ký cảnh báo, chuyển tải sang nút dự phòng hoặc từ chối kết nối bất thường.
Thước đo phản hồi (Response measure): Tiêu chí có thể lượng hóa được dùng để xác định phản hồi có đạt yêu cầu hay không, ví dụ như hoàn tất chuyển đổi dự phòng trong khoảng thời gian xác định hoặc đảm bảo dữ liệu không bị thất thoát.

Mô hình định lượng và công thức toán học trong đánh giá chất lượng

Trong kỹ thuật hệ thống, nhiều thuộc tính chất lượng quan trọng được lượng hóa thông qua các mô hình toán học và lý thuyết xác suất thống kê. Điển hình là tính sẵn sàng (Availability), một khía cạnh cốt lõi của độ tin cậy hệ thống.

Tính sẵn sàng $A$ của một hệ thống phần mềm trong trạng thái dừng ổn định được định nghĩa chuẩn xác theo lý thuyết độ tin cậy là tỷ lệ giữa thời gian trung bình vận hành đến khi xảy ra sự cố và tổng thời gian chu kỳ bao gồm cả thời gian phục hồi sửa chữa:

A = \frac{\text{MTTF}}{\text{MTTF} + \text{MTTR}}

Trong đó, đại lượng $\text{MTTF}$ là thời gian trung bình vận hành đến khi xảy ra sự cố (Mean Time To Failure), phản ánh độ bền vững và khả năng hoạt động không lỗi của hệ thống; còn đại lượng $\text{MTTR}$ là thời gian trung bình để phục hồi hệ thống sau sự cố (Mean Time To Repair), phản ánh hiệu quả của các cơ chế phát hiện và khắc phục lỗi kiến trúc. Khi một hệ thống đạt được thiết kế kiến trúc có khả năng tự phục hồi nhanh chóng, giá trị $\text{MTTR}$ tiến dần về giá trị nhỏ, từ đó nâng cao tính sẵn sàng tổng thể $A$ .

Tương tự, đối với hiệu năng hoạt động, định luật Little trong lý thuyết hàng đợi cung cấp mối quan hệ toán học cơ bản giữa số lượng yêu cầu trung bình đang nằm trong hệ thống $L$ , tốc độ xuất hiện yêu cầu trung bình $\lambda$ và thời gian phản hồi trung bình của mỗi yêu cầu $W$ :

L = \lambda W

Ở trạng thái cân bằng dừng, biểu thức này giúp các kiến trúc sư định cỡ kích thước hàng đợi và dự báo thời gian phản hồi tương ứng với tốc độ yêu cầu đến, từ đó thiết lập các chiến lược điều tiết tải hoặc phân bổ tài nguyên máy chủ phù hợp.

Quyết định đánh đổi và chiến lược kiến trúc

Một nguyên lý căn bản của kỹ nghệ phần mềm là không tồn tại một kiến trúc hoàn hảo thỏa mãn tối đa tất cả các thuộc tính chất lượng cùng một lúc. Mọi quyết định thiết kế đều là một sự đánh đổi (trade-off) có chủ đích:

Đánh đổi giữa Bảo mật và Hiệu năng: Việc áp dụng nhiều lớp mã hóa dữ liệu phức tạp, xác thực đa yếu tố và kiểm tra chữ ký số tại mọi điểm giao tiếp giữa các dịch vụ giúp nâng cao tính bảo mật, nhưng đồng thời làm gia tăng độ trễ tính toán và giảm thông lượng xử lý của hệ thống.
Đánh đổi giữa Tính sẵn sàng và Tính nhất quán: Trong các hệ thống phân tán, nguyên lý CAP chỉ ra rằng việc duy trì tính sẵn sàng cao khi có sự phân mảnh mạng buộc hệ thống phải chấp nhận tính nhất quán cuối cùng thay vì tính nhất quán tức thời.
Đánh đổi giữa Khả năng bảo trì và Hiệu năng: Việc áp dụng triệt để các tầng trừu tượng hóa, đóng gói và mẫu thiết kế giúp mã nguồn trở nên dễ đọc, dễ kiểm thử và dễ bảo trì, nhưng có thể tạo ra chi phí phụ trội do các lời gọi hàm gián tiếp lặp lại nhiều lần.

Để định hướng các thuộc tính chất lượng, các kiến trúc sư áp dụng các chiến thuật kiến trúc (Architectural Tactics). Ví dụ, đối với hiệu năng, các chiến thuật phổ biến gồm quản lý nhu cầu tài nguyên thông qua giới hạn tần suất gọi (rate limiting) và sử dụng bộ nhớ đệm (caching). Đối với độ tin cậy, các chiến thuật bao gồm phát hiện lỗi qua nhịp tim (heartbeat), ngăn chặn lỗi lan truyền qua mẫu ngắt mạch (circuit breaker) và phục hồi lỗi qua sao lưu dự phòng.

Phương pháp đánh giá kiến trúc phần mềm

Để kiểm tra xem kiến trúc được lựa chọn có đáp ứng đầy đủ các thuộc tính chất lượng mục tiêu hay không trước khi tiến hành triển khai mã nguồn trên diện rộng, các phương pháp đánh giá kiến trúc đã được phát triển. Tiêu biểu là phương pháp phân tích đánh đổi kiến trúc (Architecture Tradeoff Analysis Method, ATAM) kế thừa trực tiếp từ phương pháp SAAM do Kazman và các cộng sự (1996) khởi xướng.

Quy trình đánh giá tập trung vào việc thu thập các bên liên quan, xây dựng cây tiện ích thuộc tính chất lượng (Quality Attribute Utility Tree), tạo dựng các kịch bản thử nghiệm và phân tích cấu trúc kiến trúc đối chiếu với từng kịch bản. Kết quả của quá trình đánh giá là bản đồ xác định các điểm nhạy cảm (sensitivity points) - nơi mà một thay đổi nhỏ trong kiến trúc có thể tác động lớn đến một thuộc tính chất lượng, và các điểm đánh đổi (tradeoff points) - nơi mà quyết định thiết kế ảnh hưởng tích cực đến thuộc tính này nhưng tiêu cực đến thuộc tính khác.

Ứng dụng thực tế và bối cảnh chuyển đổi số tại Việt Nam

Trong bối cảnh ngành công nghệ thông tin tại Việt Nam đang phát triển mạnh mẽ với các hệ thống chuyển đổi số quy mô quốc gia, cổng dịch vụ công trực tuyến và các nền tảng tài chính điện tử, việc quản lý bài bản các thuộc tính chất lượng đóng vai trò vô cùng thiết thực. Các hệ thống ngân hàng số và thương mại điện tử phục vụ hàng triệu người dùng đòi hỏi tính sẵn sàng và khả năng chịu tải cao, đặc biệt trong các thời điểm giao dịch cao điểm.

Việc áp dụng các tiêu chuẩn chất lượng như ISO/IEC 25010 giúp các doanh nghiệp phần mềm tại Việt Nam chuẩn hóa quy trình thẩm định chất lượng, xây dựng các bài kiểm thử tải định lượng và nâng cao năng lực cạnh tranh trong các dự án phát triển phần mềm phức tạp.

Hạn chế và những vấn đề còn mở

Mặc dù các khung lý thuyết về thuộc tính chất lượng đã tương đối hoàn thiện, việc áp dụng trong thực tiễn kỹ nghệ phần mềm vẫn đối mặt với nhiều thách thức chưa được giải quyết triệt để:

Khoảng cách giữa đặc tả và kiểm chứng liên tục: Trong các mô hình phát triển linh hoạt (Agile) và vận hành tích hợp liên tục (DevOps), việc tự động hóa kiểm thử các thuộc tính chất lượng phức tạp như khả năng bảo trì cấu trúc hoặc tính an toàn vẫn chưa đạt mức hoàn toàn tự động, dẫn đến nguy cơ tích tụ nợ kỹ thuật kiến trúc qua các chu kỳ phát hành nhanh.
Sự xuất hiện của các hệ thống học máy và trí tuệ nhân tạo: Khi các thành phần phần mềm truyền thống được thay thế bởi các mô hình học máy, các thuộc tính chất lượng mới như tính công bằng (fairness), tính diễn giải được (explainability) và tính bền vững trước dữ liệu đối kháng (adversarial robustness) đặt ra những bài toán đánh giá kiến trúc mới mà các khung phân loại truyền thống chưa bao quát đầy đủ.
Đo lường năng lượng và tính bền vững: Yêu cầu về tính bền vững xanh và tiết kiệm năng lượng của phần mềm đang trở thành một thuộc tính chất lượng mới cần được lượng hóa chặt chẽ trong thiết kế các hệ thống tính toán đám mây quy mô lớn.