如果是應用系統
- UI的結果必須正確，不能有顯示在使用者前的描述是和任一其他描述的事實衝突，也就是說盡量要做到系統有完整性。
例如說，明明使用者還可以透過同一台伺服器線上更新，卻將伺服器本身的錯誤推給網路問題。 - 如果有領域知識，要用圖形和文件妥善說明。
例如說，系統是應用在什麼地方，應該要先瞭解怎樣的相關知識。 - 盡力描述這個系統能做到的及不能做到的（在需求分析階段）。
尤其是不能做到的，例如以前有人要我們的專案管理系統可以掃毒... - 不要有任何系統設計相關文件。
使用者會產生用途的混淆，因為設計架構並不見得和應用的領域有關。例如說你大量使用哪一種設計樣式(Pattern)，但是你在你的設定檔裡也都是那種樣式的名詞，像是Proxy對於寫程式跟網路應用就代表了兩種實做上不一樣的東西。 - 錯誤要描述清楚，可能應該有自動回報錯誤的機制，或系統本身有良好的錯誤控制機制。
不要什麼都請洽系統管理員...
如果是系統框架(Framework)
- 框架的概念不應該有任何平台(任何OS或是任何程式語言)相依的描述，意思就是要完全抽象，或者只是單純說明領域知識。
因為框架的實做很有可能在不同的平台上，如果真的要和平台有關連，也盡量寫在安裝或操作文件內，而不是概念文件。如果有許多不同領域的抽象概念，那也應該事先解釋清楚和哪種領域關連。 - 使用的字詞應該盡量和既有IT領域相關名詞雷同(儘管被人罵作太簡單)，但這直接影響了接受度。
例如Datagrid的SRB他們提出Resource,Domain,Zone，但卻給他與字面了不同的定義，導致他們每一次都必須解釋這些是什麼。而ComputingGrid的Globus雖然複雜，名詞也很多，卻並沒有太改變字面上的意義，像ResourceManager確實如其名(但都比較經常被說是GRAM)。 - 如果創造名詞，在同一個版本內不應該超過一個
最讓我讚賞的就是驢子，一直到後來才出現Kad這樣的名詞，而他也不會告訴你他實做了什麼演算法。直到你開啟了進階選項，才有比較多的名詞是不常見的。而要說他的積分系統名詞比較多，但對使用者來說都是積分系統。 - 系統的目的要解釋清楚
很多系統確實都沒有依照原來的目的，而失去焦點。例如Install Shield就是我最近認為的一個過份複雜的系統。給使用者的資訊已經超出「建立安裝套件」許多，而總是圍繞在商業化行為。如果說系統的發展很快，那應該分做子系統而不是繼續合併在一起。
沒有留言 :
張貼留言