Một phương pháp tốt để làm đánh giá kiến ​​trúc nhẹ là gì?

Tôi quen thuộc với các phương pháp đánh giá kiến ​​trúc như Phương pháp phân tích trao đổi kiến ​​trúc kỹ thuật (ATAM) và Phương pháp phân tích lợi ích chi phí theo định hướng kinh doanh (CBAM) . Tuy nhiên, các phương pháp này có quy mô khá lớn: chúng quy định một số phiên động não, thuyết trình, phát triển một loạt các kịch bản mô tả sự đánh đổi, v.v. được phát triển bởi một số ít các nhà phát triển (hoặc ít hơn), mặc dù chúng nhỏ, nhưng có một số hạn chế chất lượng khá dốc (hiệu suất, khả năng mở rộng, khả năng thích ứng).

Một thực tế điển hình tôi đã sử dụng trong quá khứ là có một nhà phát triển (hoặc kiến ​​trúc sư nếu một nhóm có một) để đưa ra kiến ​​trúc chung cho ứng dụng và sau đó thảo luận về bảng trắng với phần còn lại của nhóm, thường sử dụng một số ký hiệu giả UML dễ vẽ và dễ hiểu. Điều này thường dẫn đến phản hồi và một số lần lặp lại trên kiến ​​trúc. Nhưng nó có xu hướng hơi quá không chính thức khiến tất cả các loại giả định được đưa ra mà sau đó có thể trở thành quyết định sai lầm.

Các phương pháp như ATAM thường buộc tất cả các bên liên quan phải suy nghĩ sâu sắc về kiến ​​trúc, điều này dẫn đến các cuộc thảo luận cho đến khi mọi người ít nhất đồng ý về chính xác kiến ​​trúc là gì .

Có ai có kinh nghiệm làm việc đánh giá kiến ​​trúc nhẹ phía trước không? Nếu vậy, thực hành tốt là gì?

Chìa khóa để đánh giá nhẹ là đánh giá đúng thứ vào đúng thời điểm. Có hai cách mà tôi biết để làm điều này một cách hiệu quả. Với đánh giá dựa trên kịch bản, bạn sử dụng các kịch bản thuộc tính chất lượng và các trường hợp sử dụng để điều khiển đánh giá chỉ tập trung vào các thuộc tính chất lượng ưu tiên cao. Với đánh giá dựa trên rủi ro, bạn xác định rủi ro và để rủi ro đã xác định thúc đẩy các hoạt động thiết kế kiến ​​trúc của bạn.

Có hai cuốn sách tôi có thể khuyên bạn nên tìm hiểu hai cách tiếp cận (hơi liên quan) này.

Kiến trúc hệ thống chuyên sâu về phần mềm của Anthony Lattanze giới thiệu Phương pháp thiết kế trung tâm kiến ​​trúc và bao gồm các đánh giá dựa trên kịch bản trọng lượng nhẹ. Bạn có thể nhận ra Lattanze từ Hội thảo thuộc tính chất lượng của SEI và có những ý tưởng tương tự liên quan.

Kiến trúc phần mềm vừa đủ: Cách tiếp cận có rủi ro do George Fairbanks giới thiệu, một cách tiếp cận theo hướng rủi ro để thiết kế và đánh giá kiến ​​trúc của một hệ thống phần mềm. Ngoài ra còn có một số chương miễn phí có sẵn trên trang web của anh ấy nếu bạn muốn xem trước. Mặc dù các nguyên tắc trong cuốn sách này có thể áp dụng ngay lập tức, cách tiếp cận không đi kèm với một phương pháp cụ thể nên bạn sẽ cần kết hợp các ý tưởng từ các lĩnh vực khác. Tôi đặc biệt khuyến nghị phương pháp quản lý rủi ro liên tục của SEI để xác định / ưu tiên rủi ro.

Ý tưởng cơ bản đằng sau các phương pháp này là bạn giảm chi phí đánh giá (và thiết kế) bằng cách đánh giá khi bạn đi thay vì chờ đợi cho đến khi kết thúc. Mặc dù điều này chắc chắn nặng hơn một chút so với việc nói xung quanh một bảng trắng, nhưng nó không tốn kém như một ATAM hoàn toàn. Và nếu bạn cảm thấy thoải mái, bạn có thể chọn thực hành cherry để đáp ứng nhu cầu cụ thể của bạn.

Bất kể cách tiếp cận nào bạn sử dụng để thúc đẩy đánh giá, ý tưởng chung sẽ giống nhau ...

Trước khi bạn bắt đầu:

• Các kịch bản hoặc rủi ro thuộc tính chất lượng, được ưu tiên (có thể không chính thức nếu đó là tất cả những gì bạn có)
• Định nghĩa rõ ràng cho quyết định đi / không đi (làm thế nào để bạn biết kiến ​​trúc là "đủ tốt")
• Phần cắt gần đây nhất của mô tả kiến ​​trúc (hiện vật bạn đang đánh giá)

Ngồi xuống cho một phiên đánh giá:

• Kiến trúc sư trình bày tổng quan về kiến ​​trúc
• Đi qua một khung nhìn, cho thấy kịch bản hoặc rủi ro được thỏa mãn như thế nào
• Các vấn đề được ghi lại để khắc phục sau
• Vai trò và quy trình chung tương tự như được sử dụng để kiểm tra Fagan (kiến trúc sư hoặc tác giả, người điều hành, người ghi âm).
• Phiên có thể mất ít nhất một hoặc hai giờ tùy thuộc vào kích thước hệ thống của bạn.

Khi phiên kết thúc:

• Xem xét các vấn đề đã xác định và xác định xem các tiêu chí đi / không đi có được đáp ứng hay không. Nói chung phải mất khoảng 3 đánh giá để có được mọi thứ làm việc. Nếu không được đáp ứng, hãy tiếp tục tinh chỉnh và thử nghiệm (hoặc giảm thiểu rủi ro kiến ​​trúc).
• Đây không phải là đánh giá "tất cả hoặc không có gì" - các phần khác nhau trong kiến ​​trúc của bạn có thể "vượt qua" trong khi những phần khác vẫn cần được tinh chỉnh.

Để giúp bạn cảm nhận được cách tiếp cận dựa trên kịch bản có thể trông như thế nào, có một số tài liệu công khai từ một dự án capstone mà tôi đã làm trong trường học. Tài liệu này hơi thô, nhưng nó có thể giúp đưa ra một số ví dụ về cách tiếp cận dựa trên kịch bản trong bối cảnh của ACDM. Chúng tôi là một nhóm gồm 5 người và đã xây dựng một ứng dụng dựa trên web điển hình, khoảng 35 KLOC Java / GWT.

Tôi thích các cuộc thảo luận về bảng trắng không chính thức để bắt đầu. Tôi thích chỉ viết một phần của ứng dụng cần thiết ngày nay và sau đó dần dần để kiến ​​trúc xuất hiện trong quá trình thực hiện. Nó giống như "tìm kiếm kiến ​​trúc" hơn là cố gắng phát minh ra nó trước đó. Cách tiếp cận này không yêu cầu đánh giá trước nhiều và nó giúp bạn tập trung vào những gì quan trọng (cung cấp phần mềm làm việc).

Tất nhiên, nếu các yêu cầu phi chức năng của bạn yêu cầu nó (hạn chế về bộ nhớ, thời gian đáp ứng, số lượng người dùng đồng thời, v.v.), bạn phải cân nhắc điều đó khi triển khai hệ thống.