軟件設計的最終目標是要取得最佳方案。“最佳”是指在所有候選方案中，就節(jié)省開發(fā)費用，降低資源消耗，縮短開發(fā)時間的條件，選擇能夠贏得較高的生產(chǎn)率、較高的可靠性和可維護性的方案。在整個設計的過程中，各個時期的設計結(jié)果需要經(jīng)過一系列的設計質(zhì)量的評審，以便及時發(fā)現(xiàn)和及時解決在軟件設計中出現(xiàn)的問題，防止把問題遺留到開發(fā)的后期階段，造成后患。
設計監(jiān)理總則
軟件設計監(jiān)理的基本準則包括： 審查提交的文檔是否齊全，審查文檔編制與描述工具是否符合規(guī)范。確定承辦單位提出的軟件總體結(jié)構(gòu)設計是否實現(xiàn)了軟件需求規(guī)格說明的要求，評價軟件設計方案與數(shù)學模型的可行性，評價接口設計方案和運行環(huán)境的適應性，審查軟件集成測試計劃的合理性和完備性，審查數(shù)據(jù)庫設計的完備性和一致性。并確定該階段文檔能否作為詳細設計的依據(jù)，決定可否轉(zhuǎn)入詳細設計階段。確認軟件詳細設計文檔的內(nèi)容符合軟件編碼的要求。
設計階段中監(jiān)理單位要盡可能與業(yè)主單位協(xié)調(diào)配合工作，聽取業(yè)主單位從業(yè)務角度出發(fā)提出的對開發(fā)方設計的意見。監(jiān)理單位主要從文檔的規(guī)范性、可實施性出發(fā)，以國家相關(guān)標準為依據(jù)，從軟件工程學的角度對承建單位提出意見與建議，配合業(yè)主單位工作，敦促承建單位做好工程項目的設計工作。在設計階段，監(jiān)理單位主要針對需求的覆蓋性及可跟蹤性、模塊劃分的合理性、接口的清晰性、技術(shù)適用性、技術(shù)清晰度、可維護性、約束與需求的一致性、可測試性、對軟件設計的質(zhì)量特性的評估、對軟件設計的風險評估、對比情況、文檔格式的規(guī)范性等幾個方面進行評審。在此過程中，業(yè)主單位也需要對設計文檔做檢查，主要在功能設計是否全面準確地反映了需求、輸入項是否完全與正確并符合需求、輸出項是否符合需求、與外界的數(shù)據(jù)接口是否完全與正確并符合需求、各類編碼表是否完全與準確并符合需求、界面設計是否符合需求、維護設計是否符合需求、各類數(shù)據(jù)表格式和內(nèi)容是否符合要求、是否存在其它有疑問的設計等幾個方面進行核查。
設計的評審內(nèi)容
（1） 可追溯性：即分析該軟件的系統(tǒng)結(jié)構(gòu)、子系統(tǒng)結(jié)構(gòu)，確認該軟件設計是否復蓋了所有已確定的軟件需求，軟件每一成分是否可追溯到某一項需求。
（2） 接口：即分析軟件各部分之間的聯(lián)系，確認該軟件的內(nèi)部接口與外部接口是否已經(jīng)明確定義。模塊是否滿足高內(nèi)聚和低耦合的要求。模塊作用范圍是否在其控制范圍之內(nèi)。
（3） 風險：即確認該軟件設計在現(xiàn)有技術(shù)條件下和預算范圍內(nèi)是否能按時實現(xiàn)。
（4） 實用性：即確認該軟件設計對于需求的解決方案是否實用。
（5） 技術(shù)清晰度：即確認該軟件設計是否以一種易于翻譯成代碼的形式表達。
（6） 可維護性：從軟件維護的角度出發(fā)，確認該軟件設計是否考慮了方便未來的維護。
（7） 質(zhì)量：即確認該軟件設計是否表現(xiàn)出良好的質(zhì)量特征。
（8） 各種選擇方案：看是否考慮過其它方案，比較各種選擇方案的標準是什么。
（9） 限制：評估對該軟件的限制是否現(xiàn)實，是否與需求一致。
（10） 其它具體問題：對于文檔、可測試性、設計過程，……，等等進行評估。
在這里需要特別注意：軟件系統(tǒng)的一些外部特性的設計，例如軟件的功能、一部分性能、以及用戶的使用特性等，在軟件需求分析階段就已經(jīng)開始。這些問題的解決，多少帶有一些“怎么做”的性質(zhì)，因此有人稱之為軟件的外部設計。
McGlanghlin給出在將需求轉(zhuǎn)換為設計時判斷設計好壞的三條特征：
① 設計必須實現(xiàn)分析模型中描述的所有顯式需求，必須滿足用戶希望的所有隱式需求。
② 設計必須是可讀、可理解的，使得將來易于編程、易于測試、易于維護。
③ 設計應從實現(xiàn)角度出發(fā)，給出與數(shù)據(jù)、功能、行為相關(guān)的軟件全貌。
以上三點就是軟件設計過程的目標。為達到這些目標，必須建立衡量設計的技術(shù)標準。
① 設計出來的結(jié)構(gòu)應是分層結(jié)構(gòu)，從而建立軟件成份之間的控制。
② 設計應當模塊化，從邏輯上將軟件劃分為完成特定功能或子功能的構(gòu)件。
③ 設計應當既包含數(shù)據(jù)抽象，也包含過程抽象。
④ 設計應當建立具有具有獨立功能特征的模塊。
⑤ 設計應當建立能夠降低模塊與外部環(huán)境之間復雜連接的接口。
⑥ 設計應能根據(jù)軟件需求分析獲取的信息，建立可驅(qū)動可重復的方法。
軟件設計過程根據(jù)基本的設計原則，使用系統(tǒng)化的方法和完全的的設計評審來建立良好的設計。一、概要設計的評審
軟件概要設計監(jiān)理的目的是對軟件概要設計有關(guān)內(nèi)容（重點是軟件的結(jié)構(gòu)、軟件的功能、軟件的結(jié)構(gòu)、接口設計、接口關(guān)系等）、概要設計過程、概要設計活動、文檔格式進行審查，確定承建單位提出的軟件總體結(jié)構(gòu)設計是否實現(xiàn)了軟件需求規(guī)格說明的要求，確認是否滿足要求；給出是否符合要求的結(jié)論；確定其可否作為軟件詳細設計的前提和依據(jù)。
二、詳細設計的評審
軟件詳細設計監(jiān)理的目的是對軟件詳細設計有關(guān)內(nèi)容（重點是軟件的算法、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)類型、異常處理、計算效率等）、詳細設計過程、詳細設計活動、文檔格式進行審查，確定承建單位提出的軟件詳細設計內(nèi)容是否實現(xiàn)了軟件概要設計的要求，確認是否滿足要求；給出是否符合要求的結(jié)論；確定其可否作為軟件編碼的前提和依據(jù)。
四、軟件編碼走查的監(jiān)理
程序?qū)嶋H上也是一種供人閱讀的文章，有一個文章的風格問題。應該使程序具有良好的風格。表現(xiàn)在：源程序文檔化，數(shù)據(jù)說明的方法，語句結(jié)構(gòu)和輸入／輸出方法。所以在進行編碼監(jiān)理時重點從一下幾個方面把握：
1） 源程序文檔化
（1） 符號名的命名
符號名即標識符，包括模塊名、變量名、常量名、標號名、子程序名、數(shù)據(jù)區(qū)名以及緩沖區(qū)名等等。這些名字應能反映它所代表的實際東西，應有一定實際意義。例如，表示次數(shù)的量用Times，表示總量的用Total，表示平均值的用Average，表示和的量用Sum等等。
名字不是越長越好，應當選擇精煉的意義明確的名字。必要時可使用縮寫名字，但這時要注意縮寫規(guī)則要一致，并且要給每一個名字加注釋。同時，在一個程序中，一個變量只應用于一種用途。
（2） 程序的注釋
夾在程序中的注釋是程序員與日后的程序讀者之間通信的重要手段。注釋決不是可有可無的。一些正規(guī)的程序文本中，注釋行的數(shù)量占到整個源程序的1／3到1／2，甚至更多。注釋分為序言性注釋和功能性注釋。
序言性注釋通常置于每個程序模塊的開頭部分，它應當給出程序的整體說明，對于理解程序本身具有引導作用。有些軟件開發(fā)部門對序言性注釋做了明確而嚴格的規(guī)定，要求程序編制者逐項列出。有關(guān)項目包括：程序標題；有關(guān)本模塊功能和目的的說明；主要算法；接口說明：包括調(diào)用形式，參數(shù)描述，子程序清單；有關(guān)數(shù)據(jù)描述：重要的變量及其用途，約束或限制條件，以及其它有關(guān)信息；模塊位置：在哪一個源文件中，或隸屬于哪一個軟件包；開發(fā)簡歷：模塊設計者，復審者，復審日期，修改日期及有關(guān)說明等。
功能性注釋嵌在源程序體中，用以描述其后的語句或程序段是在做什么工作，或是執(zhí)行了下面的語句會怎么樣。而不要解釋下面怎么做。要點：描述一段程序，而不是每一個語句；用縮進和空行，使程序與注釋容易區(qū)別；注釋要正確。
（3） 標準的書寫格式
視覺組織用空格、空行和移行來實現(xiàn)。恰當?shù)乩每崭瘢梢酝怀鲞\算的優(yōu)先性，減少發(fā)生編碼的錯誤；自然的程序段之間可用空行隔開；移行也叫做向右縮格。它是指程序中的各行不必都在左端對齊，都從第一格起排列，這樣做使程序完全分不清層次關(guān)系。對于選擇語句和循環(huán)語句，把其中的程序段語句向右做階梯式移行。使程序的邏輯結(jié)構(gòu)更加清晰。
2） 數(shù)據(jù)說明
在設計階段已經(jīng)確定了數(shù)據(jù)結(jié)構(gòu)的組織及其復雜性。在編寫程序時，則需要注意數(shù)據(jù)說明的風格。為了使程序中數(shù)據(jù)說明更易于理解和維護，必須注意以下幾點。
（1） 數(shù)據(jù)說明的次序應當規(guī)范化
數(shù)據(jù)說明次序規(guī)范化，使數(shù)據(jù)屬性容易查找，也有利于測試，排錯和維護。原則上，數(shù)據(jù)說明的次序與語法無關(guān)，其次序是任意的。但出于閱讀、理解和維護的需要，最好使其規(guī)范化，使說明的先后次序固定。
（2） 說明語句中變量安排有序化
當多個變量名在一個說明語句中說明時，應當對這些變量按字母的順序排列。帶標號的全程數(shù)據(jù)也應當按字母的順序排列。
（3） 使用注釋說明復雜數(shù)據(jù)結(jié)構(gòu)
如果設計了一個復雜的數(shù)據(jù)結(jié)構(gòu)，應當使用注釋來說明在程序?qū)崿F(xiàn)時這個數(shù)據(jù)結(jié)構(gòu)的固有特點。
（4） 語句結(jié)構(gòu)
在設計階段確定了軟件的邏輯流結(jié)構(gòu)，但構(gòu)造單個語句則是編碼階段的任務。語句構(gòu)造力求簡單、直接，不能為了片面追求效率而使語句復雜化。
比如：在一行內(nèi)只寫一條語句；程序編寫首先應當考慮清晰性；程序要能直截了當?shù)卣f明程序員的用意；除非對效率有特殊的要求，程序編寫要做到清晰第一，效率第二，不要為了追求效率而喪失了清晰性；首先要保證程序正確，然后才要求提高速度，反過來說，在使程序高速運行時，首先要保證它是正確的；避免使用臨時變量而使可讀性下降；讓編譯程序做簡單的優(yōu)化；盡可能使用庫函數(shù)；避免不必要的轉(zhuǎn)移；盡量采用基本的控制結(jié)構(gòu)來編寫程序；避免采用過于復雜的條件測試；盡量減少使用“否定”條件的條件語句；盡可能用通俗易懂的偽碼來描述程序的流程，然后再翻譯成必須使用的語言；數(shù)據(jù)結(jié)構(gòu)要有利于程序的簡化；程序要模塊化，使模塊功能盡可能單一化，模塊間的耦合能夠清晰可見；利用信息隱蔽，確保每一個模塊的獨立性；從數(shù)據(jù)出發(fā)去構(gòu)造程序；不要修補不好的程序，要重新編寫。
3） 輸入和輸出
輸入和輸出信息是與用戶的使用直接相關(guān)的。輸入和輸出的方式和格式應當盡可能方便用戶的使用。一定要避免因設計不當給用戶帶來的麻煩。因此，在軟件需求分析階段和設計階段，就應基本確定輸入和輸出的風格。系統(tǒng)能否被用戶接受，有時就取決于輸入和輸出的風格。輸入／輸出風格還受到許多其它因素的影響。如輸入／輸出設備（例如終端的類型，圖形設備，數(shù)字化轉(zhuǎn)換設備等）、用戶的熟練程度、以及通信環(huán)境等。不論是批處理的輸入／輸出方式，還是交互式的輸入／輸出方式，在設計和程序編碼時都應考慮下列原則：
（1） 對所有的輸入數(shù)據(jù)都要進行檢驗，識別錯誤的輸入，以保證每個數(shù)據(jù)的有效性；
（2） 檢查輸入項的各種重要組合的合理性，必要時報告輸入狀態(tài)信息；
（3） 使得輸入的步驟和操作盡可能簡單，并保持簡單的輸入格式；
（4） 輸入數(shù)據(jù)時，應允許使用自由格式輸入；
（5） 應允許缺省值；
（6） 輸入一批數(shù)據(jù)時，最好使用輸入結(jié)束標志，而不要由用戶指定輸入數(shù)據(jù)數(shù)目；
（7） 在交互式輸入時，要在屏幕上使用提示符明確提示交互輸入的請求，指明可使用選擇項的種類和取值范圍。同時，在數(shù)據(jù)輸入的過程中和輸入結(jié)束時，也要在屏幕上給出狀態(tài)信息；
（8） 當程序設計語言對輸入／輸出格式有嚴格要求時，應保持輸入格式與輸入語句的要求的一致性；
（9） 給所有的輸出加注解，并設計輸出報表格式。測試監(jiān)理
目前國內(nèi)信息ERP應用系統(tǒng)建設過程中，在此階段常發(fā)生未經(jīng)過嚴格系統(tǒng)測試就匆忙上線試運行的情況，這往往會造成不穩(wěn)定的新系統(tǒng)對實際工作環(huán)境的影響，在某些情況下會阻礙系統(tǒng)的正式上線運行。
因此監(jiān)理單位在此階段主要檢查承建單位是否按照設計中制定的規(guī)范與計劃進行測試。但切忌由監(jiān)理單位進行單元、集成或確認測試而取代開發(fā)方的內(nèi)部測試，這種方法并不能保證工程的質(zhì)量。
如果監(jiān)理單位具有豐富的測試工作資質(zhì)與經(jīng)驗，可以考慮在此階段由監(jiān)理方在業(yè)主單位、承建單位的配合下具體進行系統(tǒng)測試工作。由于監(jiān)理單位對工程建設啟動階段、需求分析階段、設計階段、實現(xiàn)階段的工作有深入的了解，由監(jiān)理單位進行系統(tǒng)測試工作往往能夠得到較好的效果。
一、軟件測試監(jiān)理的目標
1） 監(jiān)督和控制承建單位的軟件測試過程，確保軟件測試按照承建單位的測試文檔規(guī)范和業(yè)主的軟件要求實施；
2） 軟件測試反映出、記錄著軟件產(chǎn)品的真實情況；
3） 軟件測試的各個階段按計劃步驟實施；
4） 對于軟件測試反映出的問題能有效地按回歸測試規(guī)范進行處理；
5） 最后得到符合軟件任務書（或合同）要求的軟件產(chǎn)品集；
6） 軟件測試的進度與計劃保持一致性。
二、軟件測試監(jiān)理的活動
1） 監(jiān)督承建單位將合適的軟件測試工程方法和工具集成到項目定義的軟件過程中。
（1） 依據(jù)項目定義的軟件過程對軟件測試任務進行綜合。
（2） 選擇軟件測試可用的方法和工具，并將選擇專用工具或方法的理由寫成文檔。對備選方法和工具進行選擇的依據(jù)是：
機構(gòu)標準軟件過程
項目定義的軟件過程
現(xiàn)有的技術(shù)基礎
可得到的培訓
合同需求
工具的能力
使用的方便性和提供的服務
（3） 選擇和使用適合于軟件測試的配置管理模型。配置管理模型可能是：
入庫出庫模型
組合模型
事務處理模型
更改處理模型
（4） 將用于測試軟件產(chǎn)品的工具置于配置管理之下。
2） 監(jiān)督承建單位依據(jù)項目定義的軟件過程，對軟件測試進行開發(fā)、維護、建立文檔和驗證，以滿足軟件測試計劃要求。軟件測試由靜態(tài)測試、單元測試、集成測試、確認測試和系統(tǒng)測試組成。
（1） 可以客戶和最終用戶一同參與開發(fā)和評審測試準則。
（2） 使用有效方法測試軟件。
（3） 基于下列因素確定測試的充分性：
測試級別。測試級別有：單元測試、集成測試、確認測試和系統(tǒng)測試。
選擇的測試策略。測試策略有：功能測試（黑盒測試）、結(jié)構(gòu)測試（白盒測試）和統(tǒng)計測試。
欲達到的測試覆蓋。測試覆蓋方法有：語句覆蓋、路徑覆蓋、分支覆蓋和運行剖面覆蓋。
（4） 對每個級別的軟件測試，建立和使用測試準備就緒準則。確定測試準備就緒準則包括：
軟件單元在進入集成測試前已成功地完成了代碼的靜態(tài)測試和單元測試
在進入系統(tǒng)測試前，軟件已成功地完成了確認測試
在軟件進入系統(tǒng)測試前，已對測試準備就緒進行評審
（5） 每當被測試軟件或軟件環(huán)境發(fā)生變化時，則在各有關(guān)的測試級別上適當進行回歸測試。
（6） 對于測試計劃、測試規(guī)程和測試用例，準備使用前通過評審
（7） 管理和控制測試計劃、測試說明、測試規(guī)程和測試用例。
（8） 每當軟件需求、軟件設計或被測試代碼更改時，適當?shù)馗臏y試計劃、測試說明、測試規(guī)程和測試用例。
3） 監(jiān)督承建單位依據(jù)項目定義的軟件過程，計劃和實施軟件的確認測試。
（1） 基于軟件開發(fā)計劃，制定確認測試計劃并寫成文檔。
（2） 負責軟件需求、軟件設計、系統(tǒng)測試及驗收測試的人員，評審確認測試用例、測試說明和測試規(guī)程。
（3） 依據(jù)指定的軟件需求文檔和軟件設計文檔的指定版本，進行軟件確認測試。
4） 計劃和實施軟件系統(tǒng)測試，實施系統(tǒng)測試以保證軟件滿足軟件需求。
（1） 盡早分配測試軟件的資源，以做好充分的測試準備。所需的測試準備活動包括：
準備測試文檔
準備測試資源
開發(fā)測試程序
開發(fā)模擬程序
（2） 編制系統(tǒng)測試的計劃文檔，如果合適，該測試計劃由業(yè)主單位進行評審和認可。此測試計劃包括：
全面測試和驗證的方法
測試職責
測試工具、測試設備和測試支持需求
驗收準則
（3） 由一個獨立于軟件開發(fā)者的測試小組來計劃和準備所需的測試用例和測試規(guī)程。
（4） 在測試開始前，對測試用例建立文檔，并經(jīng)評審和認可。
（5） 依據(jù)已納入基線的軟件及其軟件任務書（或合同）和軟件需求文檔，實施軟件測試。
（6） 對測試中發(fā)現(xiàn)的問題建立文檔，并跟蹤到關(guān)閉。
（7） 建立測試結(jié)果文檔，并以此作為判斷軟件是否滿足需求的基礎。
（8） 管理和控制測試結(jié)果。
5） 軟件監(jiān)理組跟蹤和記錄軟件測試的結(jié)果。跟蹤和記錄的內(nèi)容有：
（1） 跟蹤、累計的軟件產(chǎn)品缺陷的數(shù)量、類型和嚴重程度
（2） 軟件測試工程活動的狀態(tài)
（3） 有關(guān)問題嚴重性和持續(xù)時間的報告
（4） 用于分析每個更改建議的工作量及匯總統(tǒng)計量
（5） 按類別（如界面、安全性、系統(tǒng)配置、性能和可用性）被納入軟件基線的更改數(shù)量
三、軟件測試監(jiān)理的方法
1） 定期審查軟件測試的工程活動和工作進度。
2） 根據(jù)實際需要對軟件測試工程活動進行跟蹤、審查和評估。
3） 對軟件測試工程活動和產(chǎn)品進行評審和（或）審核，并報告結(jié)果。這些評審和（或）審核至少應包括：
軟件測試工程任務的準備就緒和完成準則得到滿足。
軟件測試符合規(guī)定的標準和需求。
已完成所需的測試。
檢測出的問題和缺陷已建立文檔，并被跟蹤和處理。
通過軟件測試，軟件產(chǎn)品符合軟件需求的要求。
在軟件產(chǎn)品提交前，依據(jù)軟件基線驗證了用來管理和維護軟件的文檔。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://m.guhuozai8.cn/
相關(guān)文章
