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