3）軟件監理組跟蹤和記錄軟件編碼產品的功能性和質量。跟蹤和記錄的內容有：
（1）跟蹤、累計的軟件編碼產品缺陷的數量、類型和嚴重程度
（2）軟件編碼產品工程活動的狀態
（3）有關問題嚴重性和持續時間的報告
（4）用于分析每個更改建議的工作量及匯總統計量
（5）按類別（如界面、安全性、系統配置、性能和可用性）被納入軟件基線的更改數量
三、軟件編碼監理的方法
1）定期審查軟件編碼的工程活動和工程進度。
2）根據實際需要對軟件編碼工程活動、工作進度進行審查。
3）對軟件編碼工程活動和產品進行評審和（或）審核，并報告結果。這些評審和（或）審核至少應包括：
● 軟件編碼工程任務的準備就緒和完成準則得到滿足。
● 軟件編碼符合規定的標準和需求。
● 已完成所需的測試。
● 檢測出的問題和缺陷已建立文檔，并被跟蹤和處理。
● 通過軟件編碼，對設計的跟蹤得以實施。
● 在軟件產品提交前，依據軟件基線驗證了用來管理和維護軟件的文檔。
四、軟件編碼走查的監理
程序實際上也是一種供人閱讀的文章，有一個文章的風格問題。應該使程序具有良好的風格。表現在：源程序文檔化，數據說明的方法，語句結構和輸入／輸出方法。所以在進行編碼監理時重點從一下幾個方面把握：
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）對軟件測試工程活動和產品進行評審和（或）審核，并報告結果。這些評審和（或）審核至少應包括：
● 軟件測試工程任務的準備就緒和完成準則得到滿足。
● 軟件測試符合規定的標準和需求。
● 已完成所需的測試。
● 檢測出的問題和缺陷已建立文檔，并被跟蹤和處理。
● 通過軟件測試，軟件產品符合軟件需求的要求。
● 在軟件產品提交前，依據軟件基線驗證了用來管理和維護軟件的文檔。