Architecture Decision Record
← Các mẫu bản ghi quyết định

Mẫu bản ghi quyết định của arc42

https://arc42.org/overview

1. Giới thiệu và Mục tiêu

Mô tả ngắn gọn về các yêu cầu, động lực, trích xuất (hoặc tóm lược) các yêu cầu. Ba (tối đa năm) mục tiêu chất lượng hàng đầu cho kiến trúc có mức ưu tiên cao nhất đối với các bên liên quan chính. Một bảng các bên liên quan quan trọng cùng kỳ vọng của họ đối với kiến trúc.

1.1 Tổng quan về yêu cầu

Nội dung

Mô tả ngắn gọn các yêu cầu chức năng, động lực, trích xuất (hoặc tóm lược) các yêu cầu. Liên kết tới các tài liệu yêu cầu (hy vọng là đã có), kèm thông tin về nơi tìm thấy chúng.

Động cơ

Từ góc nhìn của người dùng cuối, một hệ thống được tạo ra hoặc sửa đổi để cải thiện sự hỗ trợ cho một hoạt động kinh doanh và/hoặc nâng cao chất lượng.

Hình thức

Mô tả văn bản ngắn gọn, có thể ở định dạng trường hợp sử dụng dạng bảng. Nếu đã có các tài liệu yêu cầu, bản tổng quan này nên tham chiếu tới các tài liệu đó.

Hãy giữ các trích đoạn này ngắn nhất có thể. Cân bằng khả năng đọc của tài liệu này với sự trùng lặp tiềm ẩn so với các tài liệu yêu cầu.

1.2 Mục tiêu chất lượng

Nội dung

Ba (tối đa năm) mục tiêu chất lượng hàng đầu cho kiến trúc mà việc đáp ứng chúng có tầm quan trọng cao nhất đối với các bên liên quan chính. Chúng tôi thực sự muốn nói đến các mục tiêu chất lượng cho kiến trúc. Đừng nhầm lẫn chúng với các mục tiêu dự án. Chúng không nhất thiết giống nhau. Tiêu chuẩn ISO 25010 cung cấp một cái nhìn tổng quan tốt về các chủ đề tiềm năng đáng quan tâm.

Động cơ

Bạn nên biết các mục tiêu chất lượng của những bên liên quan quan trọng nhất, vì chúng sẽ ảnh hưởng đến các quyết định kiến trúc nền tảng. Hãy thật cụ thể về các chất lượng này, tránh những từ ngữ sáo rỗng. Nếu bạn, với tư cách kiến trúc sư, không biết chất lượng công việc của mình sẽ được đánh giá ra sao …

Hình thức

Một bảng với các mục tiêu chất lượng quan trọng nhất và các kịch bản cụ thể, sắp xếp theo mức ưu tiên.

1.3 Các bên liên quan

Nội dung

Tổng quan tường minh về các bên liên quan của hệ thống, tức là tất cả những người, vai trò hoặc tổ chức mà

  • nên biết kiến trúc

  • cần được thuyết phục về kiến trúc

  • phải làm việc với kiến trúc hoặc với mã

  • cần tài liệu về kiến trúc cho công việc của họ

  • phải đưa ra quyết định về hệ thống hoặc quá trình phát triển của nó

Động cơ

Bạn nên biết tất cả các bên tham gia phát triển hệ thống hoặc bị hệ thống ảnh hưởng. Nếu không, bạn có thể gặp những bất ngờ khó chịu về sau trong quá trình phát triển. Các bên liên quan này quyết định phạm vi và mức độ chi tiết của công việc và kết quả của bạn.

Hình thức

Bảng với tên vai trò, tên người và kỳ vọng của họ đối với kiến trúc và tài liệu của nó.

2. Ràng buộc

Bất cứ điều gì ràng buộc các nhóm trong các quyết định thiết kế và triển khai hoặc quyết định về các quy trình liên quan. Đôi khi có thể vượt ra ngoài từng hệ thống riêng lẻ và có hiệu lực với toàn bộ tổ chức và công ty.

Nội dung

Bất kỳ yêu cầu nào ràng buộc sự tự do của các kiến trúc sư phần mềm trong các quyết định thiết kế và triển khai hoặc quyết định về quy trình phát triển. Các ràng buộc này đôi khi vượt ra ngoài từng hệ thống riêng lẻ và có hiệu lực với toàn bộ tổ chức và công ty.

Động cơ

Các kiến trúc sư nên biết chính xác họ được tự do ở đâu trong các quyết định thiết kế và ở đâu họ phải tuân thủ ràng buộc. Các ràng buộc luôn phải được xử lý; tuy vậy, chúng có thể thương lượng được.

Hình thức

Các bảng ràng buộc đơn giản kèm giải thích. Nếu cần, bạn có thể chia nhỏ chúng thành ràng buộc kỹ thuật, ràng buộc tổ chức và chính trị, và quy ước (ví dụ hướng dẫn lập trình hoặc đánh phiên bản, quy ước tài liệu hoặc đặt tên)

3. Bối cảnh và Phạm vi

Phân định hệ thống của bạn với các đối tác giao tiếp (bên ngoài) (các hệ thống lân cận và người dùng). Chỉ rõ các giao diện bên ngoài. Được trình bày từ góc nhìn kinh doanh/miền (luôn luôn) hoặc góc nhìn kỹ thuật (tùy chọn)

Nội dung

Phạm vi và bối cảnh hệ thống - đúng như tên gọi - phân định hệ thống của bạn (tức là phạm vi của bạn) với tất cả các đối tác giao tiếp (các hệ thống lân cận và người dùng, tức là bối cảnh của hệ thống bạn). Qua đó nó chỉ rõ các giao diện bên ngoài.

Nếu cần, hãy phân biệt bối cảnh kinh doanh (đầu vào và đầu ra đặc thù miền) với bối cảnh kỹ thuật (kênh, giao thức, phần cứng).

Động cơ

Các giao diện miền và giao diện kỹ thuật với các đối tác giao tiếp là một trong những khía cạnh quan trọng nhất của hệ thống bạn. Hãy bảo đảm rằng bạn hiểu chúng hoàn toàn.

Hình thức

  • Các sơ đồ bối cảnh khác nhau

  • Danh sách các đối tác giao tiếp và giao diện của họ.

3.1 Bối cảnh kinh doanh

Nội dung

Đặc tả tất cả các đối tác giao tiếp (người dùng, hệ thống CNTT, …) kèm giải thích về đầu vào và đầu ra hoặc giao diện đặc thù miền. Tùy chọn, bạn có thể thêm các định dạng đặc thù miền hoặc giao thức giao tiếp.

Động cơ

Tất cả các bên liên quan nên hiểu dữ liệu nào được trao đổi với môi trường của hệ thống.

Hình thức

Mọi loại sơ đồ thể hiện hệ thống như một hộp đen và chỉ rõ các giao diện miền với các đối tác giao tiếp.

Hoặc (hay thêm vào đó) bạn có thể dùng một bảng. Tiêu đề của bảng là tên hệ thống của bạn, ba cột chứa tên đối tác giao tiếp, các đầu vào và các đầu ra.

3.2 Bối cảnh kỹ thuật

Nội dung

Các giao diện kỹ thuật (kênh và phương tiện truyền dẫn) liên kết hệ thống của bạn với môi trường của nó. Ngoài ra là ánh xạ đầu vào/đầu ra đặc thù miền tới các kênh, tức là giải thích đầu vào/đầu ra nào dùng kênh nào.

Động cơ

Nhiều bên liên quan đưa ra quyết định kiến trúc dựa trên các giao diện kỹ thuật giữa hệ thống và bối cảnh của nó. Đặc biệt các nhà thiết kế hạ tầng hoặc phần cứng quyết định các giao diện kỹ thuật này.

Hình thức

Ví dụ sơ đồ triển khai UML mô tả các kênh tới các hệ thống lân cận, cùng với bảng ánh xạ cho thấy quan hệ giữa các kênh và đầu vào/đầu ra.

4. Chiến lược Giải pháp

Tóm tắt các quyết định nền tảng và chiến lược giải pháp định hình kiến trúc. Có thể bao gồm công nghệ, phân rã cấp cao nhất, các cách tiếp cận để đạt được các mục tiêu chất lượng hàng đầu và các quyết định tổ chức liên quan.

Nội dung

Một bản tóm tắt ngắn và giải thích về các quyết định nền tảng và chiến lược giải pháp định hình kiến trúc của hệ thống. Chúng bao gồm

  • các quyết định về công nghệ

  • các quyết định về phân rã cấp cao nhất của hệ thống, ví dụ việc dùng một mẫu kiến trúc hoặc mẫu thiết kế

  • các quyết định về cách đạt được các mục tiêu chất lượng then chốt

  • các quyết định tổ chức liên quan, ví dụ chọn một quy trình phát triển hoặc giao một số nhiệm vụ cho bên thứ ba.

Động cơ

Những quyết định này là nền tảng cho kiến trúc của bạn. Chúng là cơ sở cho nhiều quyết định chi tiết hoặc quy tắc triển khai khác.

Hình thức

Hãy giữ phần giải thích các quyết định then chốt này ngắn gọn.

Nêu động cơ cho những gì bạn đã quyết định và vì sao bạn quyết định như vậy, dựa trên phát biểu vấn đề, các mục tiêu chất lượng và các ràng buộc chính. Tham chiếu các chi tiết trong các phần sau (phần 5 cho chi tiết cấu trúc, phần 8 cho các khái niệm xuyên suốt).

Bạn có thể dùng một danh sách các cách tiếp cận giải pháp hoặc một bảng.

5. Góc nhìn Khối xây dựng

Phân rã tĩnh của hệ thống, các trừu tượng hóa của mã nguồn, được thể hiện dưới dạng phân cấp các hộp trắng (chứa các hộp đen), đến mức chi tiết phù hợp.

Nội dung

Góc nhìn khối xây dựng cho thấy sự phân rã tĩnh của hệ thống thành các khối xây dựng (mô-đun, thành phần, hệ thống con, lớp, giao diện, gói, thư viện, framework, tầng, phân vùng, lớp tầng, hàm, macro, thao tác, cấu trúc dữ liệu, …) cũng như các phụ thuộc của chúng (quan hệ, liên kết, …)

Góc nhìn này là bắt buộc đối với mọi tài liệu kiến trúc. Giống như một ngôi nhà, đây là mặt bằng sàn.

Động cơ

Duy trì cái nhìn tổng quan về mã nguồn của bạn bằng cách làm cho cấu trúc của nó dễ hiểu thông qua trừu tượng hóa.

Điều này cho phép bạn giao tiếp với các bên liên quan ở mức trừu tượng mà không tiết lộ chi tiết triển khai.

Hình thức

Góc nhìn khối xây dựng là một tập hợp phân cấp các hộp đen và hộp trắng (xem hình bên dưới) và các mô tả của chúng.

5.1 Hộp trắng của toàn hệ thống

Ở đây bạn mô tả sự phân rã của toàn bộ hệ thống bằng mẫu hộp trắng sau. Nó bao gồm

  • một sơ đồ tổng quan

  • động cơ cho sự phân rã

  • mô tả hộp đen của các khối xây dựng được chứa. Với những mô tả này, chúng tôi đề xuất các phương án:

    • dùng một bảng để có cái nhìn tổng quan ngắn gọn và thực dụng về tất cả các khối xây dựng được chứa và giao diện của chúng

    • dùng một danh sách các mô tả hộp đen của các khối xây dựng theo mẫu hộp đen (xem bên dưới). Tùy theo lựa chọn công cụ của bạn, danh sách này có thể là các tiểu mục (trong tệp văn bản), các trang con (trong Wiki) hoặc các phần tử lồng nhau (trong công cụ mô hình hóa).

    • (tùy chọn:) các giao diện quan trọng không được giải thích trong mẫu hộp đen của một khối xây dựng, nhưng rất quan trọng để hiểu hộp trắng.

Vì có rất nhiều cách để chỉ rõ giao diện, chúng tôi không cung cấp mẫu cụ thể cho chúng.

Trong trường hợp tốt nhất, bạn chỉ cần các ví dụ hoặc chữ ký đơn giản.

5.2 Cấp 2

Ở đây bạn có thể chỉ rõ cấu trúc bên trong của (một số) khối xây dựng từ cấp 1 dưới dạng hộp trắng.

Bạn phải quyết định khối xây dựng nào của hệ thống đủ quan trọng để biện minh cho một mô tả chi tiết như vậy. Hãy ưu tiên tính liên quan hơn tính đầy đủ. Chỉ rõ các khối xây dựng quan trọng, bất ngờ, rủi ro, phức tạp hoặc hay thay đổi. Bỏ qua các phần bình thường, đơn giản, nhàm chán hoặc đã chuẩn hóa của hệ thống của bạn

5.2.1 Hộp trắng cho khối xây dựng 1

Chỉ rõ cấu trúc nội bộ của khối xây dựng 1.

Dùng mẫu hộp trắng (xem ở trên).

6. Góc nhìn Thời gian chạy

Hành vi của các khối xây dựng dưới dạng các kịch bản, bao quát các trường hợp sử dụng hoặc tính năng quan trọng, các tương tác tại các giao diện bên ngoài then chốt, vận hành và quản trị cùng hành vi lỗi và ngoại lệ.

Nội dung

Góc nhìn thời gian chạy mô tả hành vi và tương tác cụ thể của các khối xây dựng của hệ thống dưới dạng các kịch bản từ các lĩnh vực sau:

  • các trường hợp sử dụng hoặc tính năng quan trọng: các khối xây dựng thực thi chúng như thế nào?

  • các tương tác tại các giao diện bên ngoài then chốt: các khối xây dựng hợp tác với người dùng và các hệ thống lân cận như thế nào?

  • vận hành và quản trị: khởi chạy, khởi động, dừng

  • các kịch bản lỗi và ngoại lệ

Lưu ý: Tiêu chí chính để chọn các kịch bản có thể (chuỗi, quy trình công việc) là mức độ liên quan về mặt kiến trúc của chúng. Việc mô tả một số lượng lớn kịch bản là không quan trọng. Thay vào đó bạn nên lập tài liệu cho một tuyển chọn mang tính đại diện.

Động cơ

Bạn nên hiểu cách (các thể hiện của) các khối xây dựng trong hệ thống của bạn thực hiện nhiệm vụ và giao tiếp lúc chạy. Bạn chủ yếu sẽ ghi lại các kịch bản trong tài liệu để truyền đạt kiến trúc của mình cho các bên liên quan ít sẵn lòng hoặc ít có khả năng đọc và hiểu các mô hình tĩnh (góc nhìn khối xây dựng, góc nhìn triển khai).

Hình thức

Có nhiều ký hiệu để mô tả các kịch bản, ví dụ

  • danh sách các bước được đánh số (bằng ngôn ngữ tự nhiên)

  • sơ đồ hoạt động hoặc lưu đồ

  • sơ đồ tuần tự

  • BPMN hoặc EPC (chuỗi quy trình sự kiện)

  • máy trạng thái

  • v.v.

6.n Kịch bản Thời gian chạy n (1, 2, 3, v.v.)

Chèn sơ đồ thời gian chạy hoặc mô tả bằng văn bản về kịch bản.

Chèn mô tả các khía cạnh đáng chú ý của các tương tác giữa các thể hiện khối xây dựng được mô tả trong sơ đồ này.

7. Góc nhìn Triển khai

Hạ tầng kỹ thuật với các môi trường, máy tính, bộ xử lý, cấu trúc liên kết. Ánh xạ các khối xây dựng (phần mềm) tới các phần tử hạ tầng.

Nội dung

Góc nhìn triển khai mô tả:

  • hạ tầng kỹ thuật dùng để thực thi hệ thống của bạn, với các phần tử hạ tầng như vị trí địa lý, môi trường, máy tính, bộ xử lý, kênh và cấu trúc liên kết mạng cũng như các phần tử hạ tầng khác và

  • ánh xạ các khối xây dựng (phần mềm) tới các phần tử hạ tầng đó.

Thường các hệ thống được thực thi trong các môi trường khác nhau, ví dụ môi trường phát triển, môi trường kiểm thử, môi trường sản xuất. Trong những trường hợp như vậy, bạn nên lập tài liệu cho tất cả các môi trường liên quan.

Đặc biệt hãy lập tài liệu góc nhìn triển khai khi phần mềm của bạn được thực thi dưới dạng hệ thống phân tán với nhiều hơn một máy tính, bộ xử lý, máy chủ hoặc container hoặc khi bạn thiết kế và chế tạo các bộ xử lý và chip phần cứng của riêng mình.

Từ góc độ phần mềm, chỉ cần ghi lại những phần tử của hạ tầng cần thiết để cho thấy việc triển khai các khối xây dựng của bạn. Các kiến trúc sư phần cứng có thể đi xa hơn và mô tả hạ tầng ở bất kỳ mức chi tiết nào họ cần ghi lại.

Động cơ

Phần mềm không chạy mà không có phần cứng. Hạ tầng nền tảng này có thể và sẽ ảnh hưởng đến hệ thống của bạn và/hoặc một số khái niệm xuyên suốt. Do đó, bạn cần biết hạ tầng.

Hình thức

Có thể sơ đồ triển khai cấp cao nhất đã nằm trong mục 3.2 như bối cảnh kỹ thuật với hạ tầng của chính bạn như MỘT hộp đen. Trong mục này bạn sẽ phóng to hộp đen đó bằng các sơ đồ triển khai bổ sung.

  • UML cung cấp các sơ đồ triển khai để thể hiện góc nhìn đó. Hãy dùng nó, có thể kèm các sơ đồ lồng nhau, khi hạ tầng của bạn phức tạp hơn.

  • Khi các bên liên quan (phần cứng) của bạn thích các loại sơ đồ khác hơn sơ đồ triển khai UML, hãy để họ dùng bất kỳ loại nào có thể thể hiện các nút và kênh của hạ tầng.

7.1 Hạ tầng Cấp 1

Mô tả (thường bằng sự kết hợp của sơ đồ, bảng và văn bản):

  • sự phân bố hệ thống của bạn tới nhiều vị trí, môi trường, máy tính, bộ xử lý, .. cũng như các kết nối vật lý giữa chúng

  • lý giải hoặc động cơ quan trọng cho cấu trúc triển khai này

  • các đặc tính chất lượng và/hoặc hiệu năng của hạ tầng

  • ánh xạ các tạo phẩm phần mềm (khối xây dựng) tới các phần tử của hạ tầng

Với nhiều môi trường hoặc các triển khai thay thế, vui lòng sao chép phần đó của arc42 cho tất cả các môi trường liên quan. **

7.2 Hạ tầng Cấp 2

Ở đây bạn có thể đưa vào cấu trúc nội bộ của (một số) phần tử hạ tầng từ hạ tầng cấp 1.

Vui lòng sao chép cấu trúc từ cấp 1 cho từng phần tử được chọn.

8. Các khái niệm Xuyên suốt

Nhìn chung, các quy định chính và cách tiếp cận giải pháp liên quan đến nhiều phần (→ xuyên suốt) của hệ thống. Các khái niệm thường liên quan đến nhiều khối xây dựng. Bao gồm các chủ đề khác nhau như mô hình miền, các mẫu và phong cách kiến trúc, quy tắc sử dụng công nghệ cụ thể và các quy tắc triển khai.

Nội dung

Phần này mô tả các khái niệm xuyên suốt (thực hành, mẫu hình, quy định hoặc ý tưởng giải pháp). Các khái niệm như vậy thường liên quan đến nhiều khối xây dựng. Chúng có thể bao gồm nhiều chủ đề khác nhau.

Động cơ

Các khái niệm tạo nên cơ sở cho tính toàn vẹn khái niệm (tính nhất quán, đồng nhất) của kiến trúc. Do đó, chúng là đóng góp quan trọng để đạt được các chất lượng nội tại của hệ thống bạn.

Đây là nơi trong mẫu mà chúng tôi dành cho việc đặc tả mạch lạc các khái niệm như vậy.

Nhiều khái niệm trong số này liên quan đến hoặc ảnh hưởng tới một vài khối xây dựng của bạn.

Hình thức

Hình thức có thể đa dạng:

  • các bài viết khái niệm với bất kỳ cấu trúc nào

  • các triển khai ví dụ, đặc biệt cho các khái niệm kỹ thuật

  • các trích đoạn mô hình xuyên suốt hoặc kịch bản dùng ký hiệu của các góc nhìn kiến trúc

Cấu trúc của phần này

Chỉ chọn các chủ đề cần thiết nhất cho hệ thống của bạn và gán cho mỗi chủ đề một đề mục cấp 2 trong phần này (ví dụ 8.1, 8.2, v.v).

  • ĐỪNG CỐ GẮNG bao quát tất cả các chủ đề của sơ đồ nói trên.

Bối cảnh nền

Một số chủ đề trong hệ thống thường liên quan đến nhiều khối xây dựng, phần tử phần cứng hoặc quy trình phát triển. Có thể dễ truyền đạt hoặc lập tài liệu các chủ đề xuyên suốt như vậy tại một nơi tập trung, thay vì lặp lại chúng trong phần mô tả các khối xây dựng, phần tử phần cứng hoặc quy trình phát triển liên quan.

Một số khái niệm nhất định có thể liên quan đến mọi phần tử của hệ thống, số khác có thể chỉ liên quan đến một vài phần tử.

9. Các Quyết định Kiến trúc

Các quyết định kiến trúc quan trọng, tốn kém, then chốt, quy mô lớn hoặc rủi ro kèm theo lý do.

Nội dung

Các quyết định kiến trúc quan trọng, tốn kém, quy mô lớn hoặc rủi ro kèm theo lý do. "Quyết định" ở đây có nghĩa là chọn một phương án dựa trên các tiêu chí đã cho.

Hãy dùng phán đoán của bạn để quyết định xem một quyết định kiến trúc nên được lập tài liệu tại phần trung tâm này hay tốt hơn là lập tài liệu cục bộ (ví dụ trong mẫu hộp trắng của một khối xây dựng). Tránh các văn bản dư thừa. Tham chiếu phần 4, nơi bạn đã ghi lại các quyết định quan trọng nhất của kiến trúc.

Động cơ

Các bên liên quan của hệ thống nên có thể hiểu và lần theo các quyết định của bạn.

Hình thức

  • ADR (bản ghi quyết định kiến trúc) cho mọi quyết định quan trọng

  • danh sách hoặc bảng, sắp xếp theo tầm quan trọng và hệ quả hoặc

  • chi tiết hơn dưới dạng các phần riêng cho từng quyết định

Bối cảnh nền (về ADR)

Các mẩu tài liệu nhỏ hơn dễ đọc, dễ tạo và dễ bảo trì hơn. Khi nói đến các quyết định kiến trúc, các nhóm phát triển thường:

  • biết về quyết định, vì nó hiển thị ví dụ trong mã nguồn, nhưng

  • không biết động cơ đằng sau quyết định đó (xem Nygard 2011)

Do đó bạn nên lập tài liệu một vài quyết định quan trọng cùng với động cơ, lập luận của chúng

Đề xuất của chúng tôi về các quyết định

Hãy lưu giữ một bộ sưu tập các quyết định quan trọng về mặt kiến trúc, tức là các quyết định ảnh hưởng đến cấu trúc, các đặc tính chất lượng, các phụ thuộc và giao diện quan trọng (đặc biệt là bên ngoài), hoặc các kỹ thuật xây dựng (cảm ơn Michael Nygard vì đề xuất này).

10. Yêu cầu Chất lượng

Các yêu cầu chất lượng dưới dạng kịch bản, với cây chất lượng để cung cấp cái nhìn tổng quan cấp cao. Các mục tiêu chất lượng quan trọng nhất lẽ ra đã được mô tả trong phần 1.2. (mục tiêu chất lượng).

Nội dung

Phần này chứa tất cả các yêu cầu chất lượng liên quan.

Những yêu cầu quan trọng nhất trong số này đã được mô tả trong phần 1.2. (mục tiêu chất lượng), do đó ở đây chỉ nên tham chiếu chúng. Trong phần 10 này bạn cũng nên ghi lại các yêu cầu chất lượng ít quan trọng hơn, không tạo ra rủi ro cao khi chúng không được đáp ứng đầy đủ (nhưng có thể là điều đáng có).

Động cơ

Vì các yêu cầu chất lượng sẽ có nhiều ảnh hưởng đến các quyết định kiến trúc, bạn nên biết những chất lượng nào thực sự quan trọng đối với các bên liên quan của mình, theo cách cụ thể và đo lường được.

Thông tin thêm

Xem mô hình chất lượng Q42 đầy đủ tại https://quality.arc42.org.

10.1 Tổng quan Yêu cầu Chất lượng

Nội dung

Một bản tổng quan hoặc tóm tắt các yêu cầu chất lượng.

Động cơ

Thường chúng ta gặp hàng chục (hoặc thậm chí hàng trăm) yêu cầu chất lượng chi tiết. Trong phần tổng quan này bạn nên cố gắng tóm tắt, ví dụ bằng cách mô tả các danh mục hoặc chủ đề (như đề xuất của ISO 25010:2023 hoặc Q42

Nếu các mô tả tóm tắt này đã chính xác, đủ cụ thể và đo lường được, bạn có thể bỏ qua phần 10.2.

Hình thức

Dùng một bảng đơn giản trong đó mỗi dòng chứa một danh mục hoặc chủ đề và một mô tả ngắn về yêu cầu chất lượng. Ngoài ra, bạn có thể dùng sơ đồ tư duy để cấu trúc các yêu cầu chất lượng này.

Trong tài liệu, ý tưởng về cây thuộc tính chất lượng cũng đã được mô tả, đặt thuật ngữ chung “chất lượng” làm gốc và dùng sự tinh chỉnh dạng cây của thuật ngữ “chất lượng”. [Bass+21] đã giới thiệu thuật ngữ “Quality Attribute Utility Tree” cho mục đích này.

10.2 Các Kịch bản Chất lượng

Nội dung

Các kịch bản chất lượng làm cho các yêu cầu chất lượng trở nên cụ thể và cho phép quyết định xem chúng có được đáp ứng hay không (theo nghĩa tiêu chí chấp nhận). Hãy bảo đảm các kịch bản của bạn cụ thể và đo lường được.

Hai loại kịch bản đặc biệt hữu ích:

  • Các kịch bản sử dụng (còn gọi là kịch bản ứng dụng hoặc kịch bản trường hợp sử dụng) mô tả phản ứng lúc chạy của hệ thống với một kích thích nhất định. Điều này cũng bao gồm các kịch bản mô tả hiệu quả hoặc hiệu năng của hệ thống. Ví dụ: Hệ thống phản hồi yêu cầu của người dùng trong vòng một giây.

  • Các kịch bản thay đổi mô tả hiệu ứng mong muốn của một sửa đổi hoặc mở rộng hệ thống hoặc môi trường trực tiếp của nó. Ví dụ: Chức năng bổ sung được triển khai hoặc yêu cầu về một thuộc tính chất lượng thay đổi, và công sức hoặc thời lượng của thay đổi được đo lường.

Hình thức

Thông tin điển hình cho các kịch bản chi tiết bao gồm những điều sau:

Ở dạng ngắn (được ưa chuộng trong mô hình Q42):

  • Bối cảnh/Nền: Loại hệ thống hoặc thành phần nào, môi trường hoặc tình huống là gì?

  • Nguồn/Kích thích: Ai hoặc cái gì khởi xướng hoặc kích hoạt một hành vi, phản ứng hoặc hành động.

  • Chỉ số/Tiêu chí chấp nhận: Một phản hồi kèm thước đo hoặc chỉ số

Dạng dài của kịch bản (được SEI và [Bass+21] ưa chuộng) chi tiết hơn và bao gồm các thông tin sau:

  • ID Kịch bản: Mã định danh duy nhất của kịch bản.

  • Tên Kịch bản: Một tên ngắn, mô tả cho kịch bản.

  • Nguồn: Thực thể (người dùng, hệ thống hoặc sự kiện) khởi xướng kịch bản.

  • Kích thích: Sự kiện hoặc điều kiện kích hoạt mà hệ thống phải xử lý.

  • Môi trường: Bối cảnh vận hành hoặc điều kiện mà hệ thống trải qua kích thích.

  • Tạo phẩm: Các khối xây dựng hoặc phần tử khác của hệ thống bị ảnh hưởng bởi kích thích.

  • Phản hồi: Kết quả hoặc hành vi mà hệ thống thể hiện để phản ứng với kích thích.

  • Thước đo Phản hồi: Tiêu chí hoặc chỉ số dùng để đánh giá phản hồi của hệ thống.

Xem thêm

Kể từ tháng 1 năm 2023, arc42 cung cấp một mô hình chất lượng thực dụng, đề xuất gắn nhãn các yêu cầu chất lượng bằng các hashtag hoặc nhãn như #flexible, #efficient, #usable, #operable, #testable, #secure, #safe, #reliable.

11. Rủi ro và Nợ Kỹ thuật

Các rủi ro kỹ thuật hoặc nợ kỹ thuật đã biết. Những vấn đề tiềm ẩn nào tồn tại trong hoặc xung quanh hệ thống? Nhóm phát triển cảm thấy khổ sở về điều gì?

Nội dung

Một danh sách các rủi ro kỹ thuật hoặc nợ kỹ thuật đã được xác định, sắp xếp theo mức ưu tiên

Động cơ

“Quản lý rủi ro là quản lý dự án dành cho người trưởng thành” (Tim Lister, Atlantic Systems Guild.)

Đây nên là phương châm của bạn cho việc phát hiện và đánh giá có hệ thống các rủi ro và nợ kỹ thuật trong kiến trúc, điều mà các bên liên quan thuộc cấp quản lý (ví dụ quản lý dự án, chủ sở hữu sản phẩm) sẽ cần như một phần của phân tích rủi ro tổng thể và lập kế hoạch đo lường.

Hình thức

Danh sách các rủi ro và/hoặc nợ kỹ thuật, có thể bao gồm các biện pháp đề xuất để giảm thiểu, giảm nhẹ hoặc tránh rủi ro hoặc giảm nợ kỹ thuật.