日期：2021-05-27 09:23:30

分類：新聞動態

閱讀：59次

1、性能僅僅是很多設計因素之一

    關注軟件設計中的一個重要因素--性能，這好象也是用戶最關心的事情。一個性能不佳的軟件將不可避免被重寫。

但是你的設計還必須具有可靠性，可用性，便攜性和可擴展性。你應該在工程開始就應該定義并區分好這些因素，以便在工作中恰當使用。性能可以是，也可以不是優先級最高的因素，我的觀點是，給每個設計因素應有的考慮。

2、不要低估對軟件規模的需求

Internet 帶給我們的最大的教訓是你必須在軟件開發的最初階段就考慮軟件規模的可擴充性。今天只有100人的部門使用的應用程序，明天可能會被有好幾萬人的組織使用，下月，通過因特網可能會有幾百萬人使用它。

在軟件設計的初期，根據在用例模型中定義的必須支持的基本事務處理，確定軟件的基本功能。然后，在建造系統的時候再逐步加入比較常用的功能。在設計的開始考慮軟件的規模需求，避免在用戶群突然增大的情況下，重寫軟件。

3、管理接口

你應該在開發階段的早期就定義軟件模塊之間的接口。這有助于你的開發人員全面理解軟件的設計結構并取得一致意見，讓各模塊開發小組相對獨立的工作。一旦模 塊的接口確定之后，模塊怎樣實現就不是很重要了。從根本上說，如果你不能夠定義你的模塊“從外部看上去會是什么樣子”，你肯定也不清楚模塊內要實現什么。

4、走近路需要更長的時間

在軟件開發中沒有捷徑可以走?？s短你的在需求分析上花的時間，結果只能是開發出來的軟件不能滿足用戶的需求，必須被重寫。在軟件建模上每節省一周，在將來 的編碼階段可能會多花幾周時間，因為你在全面思考之前就動手寫程序。你為了節省一天的測試時間而漏掉了一個bug，在將來的維護階段，可能需要花幾周甚至 幾個月的時間去修復。與其如此，還不如重新安排一下項目計劃。避免走捷徑，只做一次但要做對。

5、不要信賴任何人

產品和服務銷售公司不是你的朋友，你的大部分員工和高層管理人員也不是。大部分產品供應商希望把你牢牢綁在他們的產品上，可能是操作系統，數據庫或者某個開發工具。

大部分的顧問和承包商只關心你的錢并不是你的工程。大部分程序員認為他們自己比其他人更優秀，他們可能拋棄你設計的模型而用自己認為更好的。只有良好的溝 通才能解決這些問題。要明確的是，不要只依靠一家產品或服務提供商，即使你的公司（或組織）已經在建模、文檔和過程等方面向那個公司投入了很多錢。

6、證明你的設計在實踐中可行

在設計的時候應當先建立一個技術原型， 或者稱為“端到端”原型。以證明你的設計是能夠工作的。你應該在開發工作的早期做這些事情，因為，如果軟件的設計 方案是不可行的，在編碼實現階段無論采取什么措施都于事無補。技術原型將證明你的設計的可行性，從而，你的設計將更容易獲得支持。

7、教育你的聽眾

你花了很大力氣建立一個很成熟的系統模型，而你的聽眾卻不能理解它們，甚至更糟－連為什么要先建立模型都不知道。那么你的工作是毫無意義的。

教給你開發人員基本的建模知識；否則，他們會只看看你畫的漂亮圖表，然后繼續編寫不規范的程序。另外， 你還需要告訴你的用戶一些需求建模的基礎知識。給 他們解釋你的用例和用戶界面模型，以使他們能夠明白你要表達地東西。當每個人都能使用一個通用的設計語言的時候，你的團隊才能實現真正的合作。

8、應用已知的模式

目前，我們有大量現成的分析和設計模式以及問題的解決方案可以使用。一般來說，好的模型設計和開發人員，都會避免重新設計已經成熟的并被廣泛應用的東西。 

9、研究每個模型的長處和弱點

目前有很多種類的模型可以使用,用例捕獲的是系統行為需求，數據模型則描述支持一個系統運行所需要的數據構成。你可能會試圖在用例中加 入實際數據描述， 但是，這對開發者不是非常有用。同樣，數據模型對描述軟件需求來說是無用的。每個模型在你建模過程中有其相應的位置，但是，你需要明白在什么地方，什么時 候使用它們。

10、在現有任務中應用多個模型

當你收集需求的時候，考慮使用用例模型，用戶界面模型和領域級的類模型。你設計軟件的時候，應該考慮制作類模型，順序圖、狀態圖、協作圖和最終的軟件實際物理模型。

程序設計人員應該慢慢意識到，僅僅使用一個模型而實現的軟件要么不能夠很好地滿足用戶的需求，要么很難擴展。

11、帶工具的傻瓜還是傻瓜

你給我CAD/CAM工具，請我設計一座橋。但是，如果那座橋建成的話，我肯定不想當第一個從橋上過的人，因為我對建筑一竅不通。使用一個很優秀的 CASE工具并不能使你成為一個建模專家，只能使你成為一個優秀CASE工具的使用者。成為一個優秀的建模專家需要多年的積累，不 會是一周針對某個價值 幾千美元工具的培訓。一個優秀的CASE工具是很重要，但你必須學習使用它，并能夠使用它設計它支持的模型。

12、理解完整的過程

好的設計人員應該理解整個軟件過程，盡管他們可能不是精通全部實現細節。開發是一個很復雜的過程，除了編程、建模、測試等你擅長工作外，還有很多工作要做。好的設計者需要考慮全局。必須從長遠考慮如何使軟件滿足用戶需要，如何提供維護和技術支持等。

13、技術會變，基本原理不會

如果有人說“使用某種開發語言、某個工具或某某技術，我們就不需要再做需求分析，建模，編碼或測試”。不要相信，這只說明他還缺乏經驗。拋開技術和 人的 因素，實際上軟件開發的基本原理自20世紀70年代以來就沒有改變過。你必須還定義需求，建模，編碼，測試，配置，面對風險，發布產品，管理工作人員 等 等。軟件建模技術是需要多年的實際工作才能完全掌握的。好在你可以從我的建議開始，完善你們自己的軟件開發經驗。

14、常做測試，早做測試

如果測試對你的軟件來說是無所謂的，那么你的軟件多半也沒什么必要被開發出來。建立一個技術原型供技術評審使用，以檢驗你的軟件模型。在軟件生命周期中，越晚發現的錯誤越難修改，修改成本越昂貴。盡可能早的做測試是很值得的。

15、把你的工作歸檔

不值得歸檔的工作往往也不值得做。歸檔你的設想，以及根據設想做出的決定；歸檔軟件模型中很重要但不很明顯的部分。 給每個模型一些概要描述以使別人很快明白模型所表達的內容。