Tóm tắt về ATAM
- Chuẩn bị (thuyết trình)
- Trình bày ATAM
- Trình bày các động lực kinh doanh
- Trình bày kiến trúc
- Điều tra và phân tích (đánh giá các QAs chính)
- Xác định các phương pháp tiếp cận kiến trúc
- Tạo cây tiện ích thuộc tính chất lượng
- Phân tích các phương pháp tiếp cận kiến trúc
- Kiểm tra (kết quả cho đến nay đối với các bên liên quan)
- Động não và ưu tiên các tình huống
- Phân tích các phương pháp tiếp cận kiến trúc
- Báo cáo
- Trình bày kết quả
Bước 1: trình bày ATAM
- Trưởng nhóm đánh giá
- ATAM các bước ngắn gọn
- Các kỹ thuật được sử dụng để khơi gợi và phân tích
- Tạo cây tiện ích
- Khai thác và phân tích dựa trên kiến trúc
- Động não và sắp xếp thứ tự ưu tiên cho kịch bản
- Kết quả đánh giá
- Các tình huống được gợi ra và ưu tiên
- Các câu hỏi được sử dụng để hiểu và đánh giá kiến trúc
- Cây tiện ích của QA
- Rủi ro và không rủi ro được phát hiện
- Điểm nhạy cảm và sự cân bằng
Bước 2: Trình bày các động lực kinh doanh
- Mô tả
- Các chức năng quan trọng nhất của hệ thống
- Mọi ràng buộc về kỹ thuật, quản lý, kinh tế hoặc chính trị có liên quan
- Các mục tiêu kinh doanh và bối cảnh liên quan đến dự án
- Các bên liên quan chính
- Các động lực kiến trúc (các mục tiêu thuộc tính chất lượng chính)
Bước 3: Trình bày kiến trúc
- Do kiến trúc sư chính (hoặc nhóm kiến trúc)
- Cái gì: ( bản chất )
- Ràng buộc kỹ thuật (hệ điều hành, phần cứng, phần mềm trung gian)
- Các hệ thống khác mà hệ thống phải tương tác
- Phương pháp tiếp cận kiến trúc (chiến thuật) được sử dụng để đáp ứng các yêu cầu
- Định hướng các yêu cầu về kiến trúc, các đại lượng có thể đo lường được liên quan đến những yêu cầu này
- COTS và sự tích hợp của chúng
- Các tình huống ca sử dụng quan trọng nhất
- Các tình huống thay đổi quan trọng nhất
- Các vấn đề / rủi ro về việc đáp ứng các yêu cầu định hướng
Bước 4: Xác định các phương pháp tiếp cận kiến trúc
- Lập danh mục các mẫu và các cách tiếp cận khác có thể thấy rõ
- Dựa trên bước 3
- Làm cơ sở cho các phân tích sau này
- Về cơ bản
- Nhóm đánh giá thừa nhận những gì họ có được cho đến nay
Bước 5: Tạo cây tiện ích thuộc tính chất lượng
- Cái gì: Mục tiêu QA được trình bày chi tiết thông qua cây tiện ích thuộc tính chất lượng
- Các mục tiêu thuộc tính chất lượng quan trọng nhất
- Được xác định, ưu tiên, tinh chỉnh
- Được thể hiện dưới dạng các tình huống
- “Tiện ích” là một biểu hiện độ tốt tổng thể của hệ thống
- Các thuộc tính chất lượng tạo thành cấp độ thứ hai là các thành phần của tiện ích
Bước 5: Tạo cây tiện ích thuộc tính chất lượng phần tiếp theo
- Các tình huống được ưu tiên (X, Y)
- X biểu thị mức độ quan trọng của chúng
- Y biểu thị mức độ khó khăn đối với kiến trúc để đáp ứng kịch bản
- X, Y ∈ {H(igh), M(edium), L(ow)}
| Quality Attribute | Attribute Refinement | ASR |
| Performance | Transaction response time | A user updates a patient’s account in response to a change-of-address notification while the system is under peak load, and the transaction completes in less than 0.75 second. (H,M) |
| A user updates a patient’s account in response to a change-of-address notification while the system is under double the peak load, and the transaction completes in less than 4 seconds. (L,M) | ||
| Throughput | At peak load, the system is able to complete 150 normalized transactions per second. (M,M) | |
| Usability | Proficiency training | A new hire with two or more years’ experience in the business becomes proficient in Nightingale’s core functions in less than 1 week. (M,L) |
| A user in a particular context asks for help, and the system provides help for that context, within 3 seconds. (H,M) | ||
| Normal operations | A hospital payment officer initiates a payment plan for a patient while interacting with that patient and completes the process without the system introducing delays. (M,M) | |
| Configurability | User-defined changes | A hospital increases the fee for a particular service. The configuration team makes the change in 1 working day; no source code needs to change. (H,L) |
| Maintainability | Routine changes | A maintainer encounters search- and response-time deficiencies, fixes the bug, and distributes the bug fix with no more than 3 person-days of effort. (H,M) |
| A reporting requirement requires a change to the report- generating metadata. Change is made in 4 person-hours of effort. (M,L) | ||
| Upgrades to commercial components | The database vendor releases a new version that must be installed in less than 3 person-weeks. (H,M) | |
| Extensibility | Adding new product | A product that tracks blood bank donors is created within 2 person-months. (M,M) |
| Security | Confidentiality | A physical therapist is allowed to see that part of a patient’s record dealing with orthopedic treatment but not other parts nor any financial information. (H,M) |
| Integrity | The system resists unauthorized intrusion and reports the intrusion attempt to authorities within 90 seconds. (H,M) | |
| Availability | No downtime | The database vendor releases new software, which is hot-swapped into place, with no downtime. (H,L) |
| The system supports 24/7 web-based account access by patients. (L,L) |
Bước 6: Phân tích các phương pháp tiếp cận kiến trúc
- Kiểm tra
- Các tình huống được xếp hạng cao nhất (bước 5)
- Các kiểu kiến trúc được đề xuất để hiện thực hóa chúng (bước 4)
- Mục tiêu là để nhóm đánh giá tin rằng cách tiếp cận là phù hợp để đáp ứng các yêu cầu về thuộc tính cụ thể
- Hướng dẫn kịch bản
- Xác định và ghi lại tập hợp các điểm nhạy cảm và điểm cân bằng, rủi ro và không rủi ro
- Điểm nhạy cảm và điểm đánh đổi là rủi ro ứng viên
Bước 6 đầu ra
- Các phương pháp tiếp cận kiến trúc phù hợp với từng kịch bản cây tiện ích ưu tiên cao
- Các câu hỏi phân tích liên quan đến từng cách tiếp cận
- Được chỉ ra QA liên quan đến kịch bản
- Câu trả lời của kiến trúc sư đối với các câu hỏi
- Các rủi ro, không rủi ro, điểm nhạy cảm, điểm cân bằng được liên kết với việc đạt được một / nhiều QA liên quan đến các câu hỏi QA đã thăm dò rủi ro
Xem thêm ở Bước 6
- Cây tiện ích chỉ ra cách thăm dò kiến trúc
- Kiến trúc sư phản hồi với cách tiếp cận kiến trúc đáp ứng nhu cầu này
- Nhóm đánh giá có thể sử dụng các câu hỏi dành riêng cho QA để thăm dò cách tiếp cận sâu hơn
- Các câu hỏi dành riêng cho QA giúp nhóm
- Hiểu chi tiết cách tiếp cận và cách nó được áp dụng trong trường hợp
- Tìm kiếm những điểm yếu nổi tiếng bằng cách tiếp cận
- Tìm kiếm các điểm nhạy cảm và điểm cân bằng của phương pháp tiếp cận
- Tìm các tương tác và đánh đổi bằng các cách tiếp cận khác
Ví dụ về phân tích
Bước 7: Động não và ưu tiên các tình huống
- Cây tiện ích hiển thị quan điểm của kiến trúc sư về các thuộc tính chất lượng
- Ở đây, trọng tâm là quan điểm của các bên liên quan khác về các thuộc tính chất lượng và các tình huống dựa trên chúng
- Tình huống nào có ý nghĩa và quan trọng nhất đối với người dùng, v.v.
- Động não theo tình huống hoạt động tốt trong các nhóm lớn hơn
- Danh sách các kịch bản được ưu tiên so với các kịch bản cây tiện ích
Bước 7: Các tình huống động não
- Các tình huống ca sử dụng (Use case scenarios)
- Các bên liên quan mong đợi hệ thống được sử dụng như thế nào
- Các kịch bản tăng trưởng (Growth scenarios)
- Kiến trúc dự kiến sẽ thích ứng với sự phát triển và thay đổi như thế nào
- Các sửa đổi dự kiến, thay đổi về hiệu suất hoặc tính khả dụng, chuyển sang các nền tảng khác, tích hợp với phần mềm khác
- Kiến trúc dự kiến sẽ thích ứng với sự phát triển và thay đổi như thế nào
- Các tình huống khám phá (Exploratory scenarios)
- Các hình thức phát triển cực đoan, cách kiến trúc có thể bị căng thẳng bởi những thay đổi
- Các yêu cầu về tính khả dụng hoặc hiệu suất mới đáng kể, những thay đổi lớn về cơ sở hạ tầng hoặc sứ mệnh hệ thống
- Các hình thức phát triển cực đoan, cách kiến trúc có thể bị căng thẳng bởi những thay đổi
Bước 7: Mức độ ưu tiên
- Các bên liên quan đầu tiên hợp nhất các kịch bản mà họ tin rằng thể hiện cùng một hành vi / mối quan tâm của QA
- Sau đó, các bên liên quan bỏ phiếu về các kịch bản mà họ tin là quan trọng nhất
- Bình chọn là công khai
- Trưởng nhóm đánh giá sắp xếp các tình huống, phát hiện sự sụt giảm mạnh về số phiếu bầu và vạch ra ranh giới ở đó
Ví dụ về hệ thống điều phối xe
| # | Scenario | Votes |
| 4 | Tự động lập kế hoạch lại một nhiệm vụ đã cử đi trong vòng 10 phút. | 28 |
| 27 | Chia nhỏ việc quản lý một tập hợp các phương tiện trên nhiều địa điểm kiểm soát. | 26 |
| 10 | Thay đổi công cụ phân tích nhà cung cấp sau khi nhiệm vụ đã bắt đầu mà không cần khởi động lại hệ thống. | 23 |
| 12 | Nhắm lại một bộ sưu tập các phương tiện đa dạng để xử lý tình huống khẩn cấp trong vòng chưa đầy 10 giây sau khi có lệnh. | 13 |
| 14 | Thay đổi cơ chế phân phối dữ liệu từ CORBA sang một tiêu chuẩn mới đang phát triển với nỗ lực chưa đến sáu tháng của người. | 12 |
Các tình huống được xếp hạng cao với chú thích QA
| Scenario | # Votes | Quality Attributes |
| 4 | 28 | Performance |
| 27 | 26 | Performance, modifiability, availability |
| 10 | 23 | Modifiability |
| 12 | 13 | Performance |
| 14 | 12 | Modifiability |
Bước 7: So sánh
- Mức độ ưu tiên của kịch bản so với cây tiện ích
- Đồng ý hoặc không đồng ý
- Mỗi kịch bản được động não có mức độ ưu tiên cao được đặt trong nút lá thích hợp trong cây tiện ích
- Trước đó, hãy xác định các QAs mà kịch bản giải quyết
- Khi kịch bản cân não được đặt trong cây tiện ích:
- Kịch bản sẽ khớp và về cơ bản sao chép một nút lá đã tồn tại
- Kịch bản đi vào một lá mới của nhánh hiện có
- Tình huống không khớp với cành cây (QA chưa được tính đến trước đây)
Cây tiện ích so với Kịch bản
| Cây tiện ích | Kịch bản động não | |
| Các bên liên quan | Kiến trúc sư, trưởng dự án | Tất cả các bên liên quan |
| Quy mô nhóm điển hình | Người đánh giá, 2-3 nhân sự dự án | Người đánh giá, 5-10 nhân sự liên quan đến dự án |
| Mục tiêu chính | Gợi ý, đưa ra kết luận và ưu tiên các QA định hướng; cung cấp trọng tâm cho phần còn lại của đánh giá | Thúc đẩy giao tiếp với các bên liên quan để xác thực các mục tiêu QA được đưa ra thông qua cây tiện ích |
| Cách tiếp cận | Từ chung đến cụ thể; bắt đầu với QA, tinh chỉnh cho đến khi nổi lên kịch bản | Từ cụ thể đến chung; bắt đầu với các tình huống, xác định các QAs mà chúng thể hiện |
Các bên liên quan và Kiến trúc sư
- Kiến trúc sư nên có mặt khi đánh giá!
- Không thể xác định kiến trúc sư: rắc rối
- Kiến trúc sư nhìn thấy tất cả các bên liên quan cùng nhau, bước quan trọng
- Kiến trúc sư nhận các hạng mục để làm việc sau khi đánh giá
- Phải trình bày kiến trúc
- Xác định các loại bên liên quan và tên!
- Người đánh giá đề xuất các loại
- Khách hàng cung cấp tên
Bước 8: Phân tích các phương pháp tiếp cận kiến trúc
- Các kịch bản được xếp hạng cao nhất từ bước 7 được trình bày cho kiến trúc sư
- Kiến trúc sư giải thích cách các quyết định kiến trúc có liên quan góp phần hiện thực hóa từng kịch bản
- Các phương pháp tiếp cận kiến trúc đã được thảo luận trước đây nên đến ở đây
- Các hoạt động tương tự như trong Bước 6
- Lý tưởng nhất: chỉ thử nghiệm
- Nếu bước 7 không tạo ra bất kỳ tình huống ưu tiên cao nào chưa được đề cập
Bước 9: Trình bày kết quả
- Báo cáo bằng lời nói và các trang trình bày
- Báo cáo bằng văn bản
- Đầu ra:
- Các phương pháp tiếp cận kiến trúc được ghi lại
- Tập hợp các tình huống và mức độ ưu tiên của chúng từ quá trình động não
- Cây tiện ích
- Những rủi ro được phát hiện
- Các tài liệu không rủi ro
- Tìm thấy các điểm nhạy cảm và điểm cân bằng
Bước 9: Các chủ đề rủi ro
- Các rủi ro có thể được nhóm lại với nhau dựa trên một số mối quan tâm cơ bản chung, thiếu hụt hệ thống
- Ví dụ
- Tài liệu không được xem xét đầy đủ
- Tài liệu không đủ
- Tài liệu lỗi thời
- Không quan tâm đầy đủ đến khả năng sao lưu hoặc cung cấp tính sẵn sàng cao
- Hệ thống không thể hoạt động khi nhiều SW / HW khác nhau bị lỗi
- Tài liệu không được xem xét đầy đủ
- Chủ đề rủi ro <-> các động lực kinh doanh bị ảnh hưởng
- Phần kết thúc và rủi ro được chỉ ra cho ban quản lý