軟體架構師會選取將分析和設計的特定數量之情境和使用案例,以提議技術內容和後續的反覆順序。各開發小組將根據員工的可用性、客戶的交付項目需求、工具和 COTS 產品的可用性以及其他專案的需求,來完成和修正這項技術提議。
被視為「含架構重要性」的情境和使用案例(如構成架構的使用案例視圖),對它們的選擇是由以下所摘要的一些重要驅動因素來驅動的。
-
情境對關係人的好處:關鍵、重要、有用。
-
情境對架構的影響:無、延伸、修改。有可能關鍵性的使用案例對架構卻沒有什麼影響,而好處不大的使用案例卻會有很大的影響。好處不大卻會嚴重影響架構的使用案例,應該由專案管理人員來審查,因為可能會解除範圍。
-
將緩和的風險(效能、產品可用性,以及元件的適用性)。
-
架構涵蓋面的完成度(確定在詳述階段結束時,每個要開發的軟體片段都會在實作視圖中找到它的家)。
-
其他戰術目標或限制:向使用者提供示範,等等。
兩個情境有可能會涉及相同的元件,處理類似的風險。如果您先實作 A,之後,B 就不含架構重要性。如果您先實作 B,之後,A 就不含架構重要性。因此,這些屬性可能會相依於反覆次序,當排序有了改變,以及需求本身有了改變時,應該重新評估。
含架構重要性且未獲適當瞭解或有可能改變的使用案例,您應該設定它們的優先順序,以便進行分類,使它們穩定。在某些情況下,這表示在實作需求之前,應該做進一步的需求分析。在其他情況下,某種形式的原型可能最好。
|