「架構概念實證」有許多種形式,例如:
-
可能適用於解決方案的已知技術清單(骨架、型樣、可執行的架構)
-
採用 UML 等表示法,繪製解決方案概念模型的草圖
-
解決方案的模擬
-
可執行的原型
是否需要「架構概念實證」及應該採取何種形式,決策因素如下:
-
對領域的了解程度 - 如果不熟悉領域,則「架構概念實證」不僅可以找出可能的解決方案,還可以協助客戶和開發組織了解和釐清需求
-
系統的新穎性 - 如果開發組織先前已建構許多這種系統,則應該不需要做概念實證 - 根據現有的參考架構和技術,應該就足以判斷可行性
-
即使熟悉領域且系統有前例可循,也要確定任何需求是否絕對必要;例如,需要非常高的交易率或最大的可靠性
風險愈高,在「初始」階段需要投入這項架構綜合活動的成本愈大(期望從產生和評估的模型中獲到更具體的結果), 如此,才能讓所有關係人相信值得投入資金和進入「詳述」階段。
不過,必須認清,在此階段不可能完全消除風險。不應該為了進入現有的「詳述」階段而扭曲「初始」階段。
|