軟體專案開發的文件編寫標準化 (轉)
專案開發的文件編寫標準化
在專案開發過程中,應該按要求編寫好十三種文件,文件編制要求具有針對性、精確性、清晰性、完整性、靈活性、可追溯性。
◇ 可行性分析報告:說明該專案的實現在技術上、經濟上和社會因素上的可行性,評述為了合理地達到開發目標可供選擇的各種可能實施方案,說明並論證所選定實施方案的理由。
◇ 專案開發計劃:為軟體專案實施方案制訂出具體計劃,應該包括各部分工作的負責人員、開發的進度、開發經費的預算、所需的及軟體資源等。
◇ 軟體需求說明書(軟體規格說明書):對所開發軟體的功能、、介面及執行環境等作出詳細的說明。它是在使用者與開發人員雙方對軟體需求取得共同理解並達成的條件下編寫的,也是實施開發工作的基礎。該說明書應給出資料邏輯和資料採集的各項要求,為生成和維護資料做好準備。
◇ 概要設計說明書:該說明書是概要實際階段的工作成果,它應說明功能分配、模組劃分、的總體結構、輸入輸出以及介面設計、執行設計、資料結構設計和出錯處理設計等,為詳細設計提供基礎。
◇ 詳細設計說明書:著重描述每一模組是怎樣實現的,包括實現演算法、邏輯流程等。
◇ 使用者操作手冊:本手冊詳細描述軟體的功能、效能和使用者介面,使使用者對如何使用該軟體得到具體的瞭解,為操作人員提供該軟體各種執行情況的有關知識,特別是操作方法的具體細節。
◇ 測試計劃:為做好整合測試和驗收測試,需為如何組織測試製訂實施計劃。計劃應包括測試的內容、進度、條件、人員、測試用例的選取原則、測試結果允許的偏差範圍等。
◇ 測試分析報告:測試工作完成以後,應提交測試計劃情況的說明,對測試結果加以分析,並提出測試的結論意見。
◇ 開發進度月報:該月報系軟體人員按月向管理部門提交的專案進展情況報告,報告應包括進度計劃與實際執行情況的比較、階段成果、遇到的問題和解決的辦法以及下個月的打算等。
◇ 專案開發總結報告:軟體專案開發完成以後,應與專案實施計劃對照,總結實際執行的情況,如進度、成果、資源利用、成本和投入的人力,此外,還需對開發工作做出評價,總結出和教訓。
◇ 軟體維護手冊:主要包括軟體系統說明、程式模組說明、操作環境、支援軟體的說明、維護過程的說明,便於軟體的維護。
◇ 軟體問題報告:指出軟體問題的登記情況,如日期、發現人、狀態、問題所屬模組等,為軟體修改提供準備文件。
◇ 軟體修改報告:軟體產品投入執行以後,發現了需對其進行修正、更改等問題,應將存在的問題、修改的考慮以及修改的影響作出詳細的描述,提交審批。
可行性分析報告
1 引言1.1 編寫目的:闡明編寫可行性研究報告的目的,提出讀者。1.2 專案背景:應包括
● 所建議開發軟體的名稱
● 專案的任務提出者、開發者、使用者及實現軟體的單位
● 專案與其他軟體或其他系統的關係。1.3 定義:列出文件中用到的專門術語的定義和縮寫詞的原文。1.4 參考資料:列出有關資料的作者、標題、編號、發表日期、出版單位或資料來源,可包括
● 專案經核准的計劃任務書、合同或上級機關的批文
● 與專案有關的已發表的資料
● 文件中所引用的資料,所採用的軟體標準或規範2 可行性研究的前提2.1 要求:列出並說明建議開發軟體的的基本要求,如
● 功能
● 效能
● 輸入/輸出
● 基本的資料流程和處理流程
● 與保密要求
● 與軟體相關的其他系統
● 完成日期2.2 目標:可包括
● 人力與裝置費用的節省
● 處理速度的提高
● 控制精度或生產力的提高
● 管理資訊服務的改進
● 決策系統的改進
● 人員工作的提高2.3 條件、假定和限制:可包括
● 建議開發軟體執行的最短壽命
● 進行顯然方案選擇比較的期限
● 經費來源和使用限制
● 法律和政策方面的限制
● 硬體、軟體、執行環境和開發環境的條件和限制
● 可利用的資訊和資源
● 建議開發軟體投入使用的最遲時間2.4 可行性研究方法2.5 決定可行性的主要因素3 對現有系統的分析3.1 處理流程和資料流程3.2 工作負荷3.3 費用支出:如人力、裝置、空間、支援性服務、材料等項開支3.4 人員:列出所需人員的專業技術類別和數量3.5 裝置3.6 侷限性:說明現有系統存在的問題以及為什麼需要開發新的系統4 所建議技術可行性分析4.1 對系統的簡要描述4.2 與現有系統比較的優越性4.3 處理流程和資料流程4.4 採用建議系統可能帶來的影響
● 對裝置的影響
● 對現有軟體的影響
● 對使用者的影響
● 對系統執行的影響
● 對開發環境的影響
● 對經費支出的影響4.5 技術可行性評價:包括
● 在限制條件下,功能目的是否達到
● 利用現有技術,功能目的是否達到
● 對開發人員數量和質量的要求,並說明能否滿足
● 在規定的期限內,開發能否完成5 所建議系統經濟可行性分析5.1 支出5.2 效益5.3 收益/投資比5.4 投資回收週期5.5 敏感性分析:指一些關鍵性因素,如:
● 系統生存週期長短
● 系統工作負荷量
● 處理速度要求
● 裝置和軟體變化對支出和效益的影響等的分析6 社會因素可行性分析6.1 法律因素:如
● 合同責任
● 侵犯專利權
● 侵犯版權6.2 使用者使用可行性:如
● 使用者單位的行政管理
● 工作制度
● 人員素質等能否滿足要求7 其他可供選擇的方案
逐個闡明其它可供選擇的方案,並重點說明未被推薦的理由。
8 結論意見
● 可著手組織開發
● 需等待若干條件具備後才能開發
● 需對開發目標進行某些修改
● 不能進行或不必進行
● 其它
專案開發計劃
1 引言1.1 編寫目的:闡明編寫可行性研究報告的目的,提出讀者物件1.2 專案背景:應包括
● 專案的委託單位、開發單位和主管部門;
● 該軟體系統與其他系統的關係。1.3 定義:列出文件中用到的專門術語的定義和縮寫詞的原文1.4 參考資料:可包括:
● 專案經核准的計劃任務書、合同或上級機關的批文
● 文件所引用的資料、規範等
● 列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源;2 專案概述2.1 工作內容:簡要說明專案的各項主要工作,介紹所開發軟體的功能、效能等;若不編寫可行性研究報告;則應在本節給出較詳細的介紹;2.2 條件與限制: 闡明為完成專案應具備的條件、開發單位已具備的條件以及尚需創造的條件。必要時還應說明使用者及分合同承擔的工作、完成期限及其他條件與限制。2.3 產品2.3.1程式:列出應交付的程式名稱、使用的語言及形式。2.3.2文件:列出應交付的文件。2.4 執行環境:應包括硬體環境、軟體環境。2.5 服務:闡明開發單位可向使用者提供的服務。如人員培訓、、保修、維護和其他執行支援。2.6 驗收標準3 實施計劃3.1 任務分解:任務的劃分及各項任務的負責人。3.2 進度:按階段完成的專案,用圖表說明開始時間、完成時間。3.3 預算3.4 關鍵問題:說明可能影響專案的關鍵問題,如裝置條件、技術難點或其他風險因素,並說明對策。4 人員組織及分工5 交付期限6 專題計劃要點
如測試計劃、質量保證計劃、配置管理計劃、人員培訓計劃、系統安裝計劃等。
軟體需求說明書
1 引言1.1 編寫目的:闡明編寫需求說明書的目的,指明讀者物件。1.2 專案背景:應包括
● 專案的委託單位、開心單位和主管部門;
● 該軟體系統與其他系統的關係。1.3 定義:列出文件中所用到的專門術語的定義和縮寫詞的願文。1.4 參考資料:可包括
● 專案經核准的計劃任務書、合同或上級機關的批文
● 文件所引用的資料、規範等
● 列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源2 任務概述2.1 目標2.2 執行環境2.3 條件與限制3 資料描述3.1 表態資料3.2 動態資料:包括輸入資料和輸出資料。3.3 描述:給出使用資料庫的名稱和型別。3.4 資料詞典3.5 資料採集4 功能需求4.1功能劃分4.2功能描述5 效能需求5.1 資料精確度5.2 時間特性:如響應時間、處理時間、資料轉換與傳輸時間、執行時間等。5.3 適應性:在操作方式、執行環境、與其他軟體的介面以及開發計劃等發生變化時,應具有的適應能力。6 執行需求6.1 使用者介面:如螢幕格式、報表格式、選單格式、輸入輸出時間等。6.2 硬體介面6.3 軟體介面6.4 故障處理7 其他需求
如可使用性、安全保密、可維護性、可移植性等。
概要設計說明書
1 引言1.1 寫目的:闡明編寫概要設計說明書的目的,指明讀者物件。1.2 專案背景:應包括
● 專案的委託單位、開發單位和主管部門
● 該軟體系統與其他系統的關係。1.3 定義:列出本文件中所用到的專門術語的定義和縮寫詞的願意。1.4 參考資料:
● 列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源
●專案經核准的計劃任務書、合同或上級機關的批文;專案開發計劃;需求規格說明書;測試計劃(初稿);使用者操作手冊
● 文件所引用的資料、採用的標準或規範。2 任務概述2.1 目標2.2 需求概述2.3 條件與限制3 總體設計3.2 總體結構和模組外部設計3.3 功能分配:表明各項功能與程式結構的關係。4 介面設計4.1 外部介面:包括使用者介面、軟體介面與硬體介面。4.2 內部介面:模組之間的介面。5 資料結構設計6 邏輯結構設計
所有文件的統一封面格式如下頁所示。
7 物理結構設計8 資料結構與程式的關係9 執行設計9.1 執行模組的組合9.2 執行控制9.3 執行時間10 出錯處理設計10.1 出錯輸出資訊10.2 出錯處理對策:如設定後備、效能降級、恢復及再啟動等。11 安全保密設計12 維護設計
說明為方便維護工作的設施,如維護模組等。
詳細設計說明書
1 引言1.1 編寫目的:闡
明編寫詳細設計說明書的目的,指明讀者物件。1.2 專案背景:應包括專案的來源和主管部門等。1.3 定義:列出本文件中所用到的專門術語的定義和縮寫詞的願意。1.4 參考資料:
● 列出有關資料的作者、標題、編號、發表日期、出版單位或資料來源
●專案經核准的計劃任務書、合同或上級機關的批文;專案開發計劃;需求規格說明書;概要設計說明書;測試計劃(初稿);使用者操作手冊
● 文件所引用的資料、軟體開發的標準或規範。2 總體設計2.1 需求概述2.2 軟體結構:如給出軟體系統的結構圖。3 程式描述3.1 逐個模組給出以下說明:
● 功能
● 效能
● 輸入專案
● 輸出專案3.2 演算法:模組所選用的演算法。3.3 程式邏輯:詳細描述模組實現的演算法,可採用:標準流程圖;PDL語言;N-S圖;判定表等描述演算法的圖表。3.4 介面
● 儲存分配
● 限制條件3.5測試要點:給出測試模組的主要測試要求。
使用者操作手冊
1 引言1.1 編寫目的:闡明編寫手冊的目的,指明讀者物件。1.2 專案背景:說明專案的來源、委託單位、開發單位及和主管部門。1.3 定義:列出手冊中使用的專門術語的定義和縮寫詞的願意。1.4 參考資料:
● 列出有關資料的作者、標題、編號、發表日期、出版單位或資料來源
● 專案經核准的計劃任務書、合同或上級機關的批文;專案開發計劃;需求規格說明書;概要設計說明書;詳細設計說明書;測試計劃
● 文件中所引用的其他資料、採用的軟體工程標準或軟體工程規範。2 軟體概述2.1 目標2.2 功能2.3 效能2.4 資料精確度:包括輸入、輸出及處理資料的精度。2.5 時間特性:如響應時間、處理時間、資料傳輸時間等。2.6 靈活性:在操作方式、執行環境需做某些變更時軟體的適應能力。3 執行環境3.1 硬體
● 列出軟體系統執行時所需的硬體最小配置,如型號、主存容量
● 外儲存器、、記錄格式、裝置型號及數量
● 輸入、輸出裝置
● 資料傳輸裝置及資料轉換裝置的型號及數量。3.2 支援軟體
● 名稱及版本號
● 語言編譯系統或系統的名稱及版本號
● 資料庫管理系統的名稱及版本號
● 其他必要的支援軟體4 使用說明4.1 安裝和初始化:給出程式的儲存形式、操作命令、反饋資訊及其做含意、表明安裝完成的測試例項以及安裝所需的軟體工具等。4.2 輸入:給出輸入資料或引數的要求。
● 資料背景:說明資料來源、儲存媒體、出現頻度、限制和質量管理等。
● 資料格式:如長度、格式基準、標號、順序、分隔符、詞彙表、省略和重複、控制。
● 輸入舉例。4.3 輸出:給出每項輸出資料的說明。
● 資料背景:說明輸出資料的去向、使用頻度、存放媒體及質量管理等。
● 資料格式:詳細闡明每一輸出資料的格式,如首部、主體和尾部的具體形式。
● 舉例4.4 出錯和恢復:給出出錯資訊及其含意;使用者應採取的措施,如修改、恢復、再啟動。4.5 求助查詢:說明如何操作。5 執行說明5.1 執行表:列出每種可能的執行情況,說明其執行目的。5.2 執行步驟:按順序說明每和執行的步驟,應包括:5.3 執行控制5.4 操作資訊:執行目的、執行目的、操作要求、啟動方法、預計執行時間、操作命令格式及說明、其他事項;5.5輸入/輸出檔案:給出建立或更新檔案的有關資訊,如:檔案的名稱及編號;記錄媒體;存留的目錄;檔案的支配:說明確定保留檔案或廢棄檔案的準則,分發檔案的物件,戰勝硬體的優先順序及保密控制等。5.6 啟動或恢復過程6 非常規過程
提供應急戒非常規操作的必要資訊及操作步驟,如出錯處理操作、向後備系統切換操作及維護人員須知的操作和注意事項。
7 操作命令一覽表
按字母順序逐個列出全部操作命令的格式、功能及引數說明。
8 程式檔案(或命令檔案)和資料檔案一覽表
按檔名字母順序或按功能與模組分類順序逐個列出檔名稱、識別符號及說明。
9 使用者操作舉例
測試計劃
1 引言1.1 編寫目的:闡明編寫測試計劃的目的並指明讀者物件。1.2 專案背景:說明專案的來源、委託單位及主管部門。1.3 定義:列出測試 計劃中所用到的專門術語的定義和縮寫詞的原意。1.4參考資料:列出有關資料的作者、標題、編號、發表日期、出版單位或資料來源,可包括:專案的計劃任務書、合同或批文;專案開發計劃;需求規格說明書;概要設計說明書;詳細設計說明書;使用者操作手冊;本測試計劃中引用的其他資料、採用的軟體開發標準或規範。
2 任務概述2.1 目標2.2 執行環境2.3 需求概述2.4 條件與限制3 計劃3.1 測試方案:說明測試方法和選取測試用例的原則。3.2 測試專案:列出組裝測試和確認測試中每一項測試的內容、名稱、目的和進度。3.3 測試準備3.4 測試機構及人員:測試機構名稱、負責人和職責。4 測試專案說明4.1 按順序逐個對測試專案做出說明4.1.1 測試專案名稱及測試內容4.1.2 測試用例4.1.3 輸入:輸入的資料和輸入命令。4.1.4 輸出:預期的
輸出資料。4.2 步驟及操作4.3 允許偏差:給出實測結果與預期結果之間允許偏差的範圍。4.4 進度4.5 條件:給出項測試對資源的特殊要求,如裝置、軟體、人員等。4.6 測試資料:說明項測試所需的資料。5 評價5.1 範圍:說明所完成的各項測試說明問題的範圍及其侷限性。5.2 準則:說明評論測試結果的準則。
測試分析報告
1 引言1.1 編寫目的:闡明編寫測試分析報告的目的並指明讀者物件。1.2 專案背景:說明專案的來源、委託單位及主管部門。1.3定義:列出測試分析報告中所用到的專門術語的定義和縮寫詞的原意。1.4參考資料:列出有關資料的作者、標題、編號、發表日期、出版單位或資料來源,可包括:專案的計劃任務書、合同或批文;專案開發計劃;需求規格說明書;概要設計說明書;詳細設計說明書;使用者操作手冊;測試計劃;測試分析報告所引用的其他資料、採用的軟體工程標準或工程規範。2 測試計劃招待情況2.1 機構和人員:給出測試機構名稱、負責人和參與測試人員名單。2.2 測試結果:按順序給出每一測試專案的:實測結果資料;與預期結果資料的偏差;該項測試表明的事實;該項測試發現的問題。3 軟體需求測試結論
按順序給出每一項需求測試的結論。包括:證實的軟體能力;侷限性(即項需求未得到充分測試的情況及原因。
4 評價4.1 軟體能力:經過測試所表明的軟體能力。4.2 缺陷和限制:說明測試所揭露的軟體缺陷和不足,以及可能給軟體執行帶來的影響。4.3 建議:提出為彌補上述缺陷的建議。4.4 測試結論:說明能否透過。
開發進度月報
1 報告時間及所處的開發階段2 工程進度2.1 本月內的主要活動2.2 實際進展與計劃比較3 所用工時
按不同層次人員分別計時。
4 所用機時
按所用計算機機型分別計時。
5 經費支出
分類列出本月經費支出專案,給出支出總額,並與計劃比較。
6 工作遇到的問題及採取的對策7 本月完成的成果8 下月的工作計劃9 特殊問題
專案開發總結報告
1 引言1.1 編寫目的:闡明編寫總結報告的目的並指明讀者物件。1.2 專案背景:說明專案的來源、委託單位、開發單位及主管部門。1.3 定義:列出報告中所用到的專門術語的定義和縮寫詞的原意。1.4參考資料:列出有關資料的作者、標題、編號、發表日期、出版單位或資料來源,可包括:專案的計劃任務書、合同或批文;專案開發計劃;需求規格說明書;概要設計說明書;詳細設計說明書;使用者操作手冊;測試計劃;測試分析報告;本報告引用的其他資料、採用的開發標準或開發規範。2 開發結果2.1 產品:可包括列出各部分的程式名稱、源程式行數(包括註釋行)或目標程式位元組數及程式總計數量、儲存形式;產品文件名稱等。2.2 主要功能及效能2.3 所用工時:按人員的不同層次分別計時。2.4 所用機時:按所用計算機機型分別計時。2.5 進度:給出計劃進度與實際進度的對比。2.6 費用3 評價3.1 生產率評價:如平均每人每月生產的源程式行數、文件的字數等。3.2 技術方案評價3.3 產品質量評價4 經驗與教訓
軟體維護手冊
1 引言1.1 編寫目的:闡明編寫手冊的目的並指明讀者物件。1.2 專案背景:說明專案的提出者、開發者、使用者和使用場所。1.3 定義:列出報告中所用到的專門術語的定義和縮寫詞的原意。1.4 參考資料:列出有關資料的作者、標題、編號、發表日期、出版單位或資料來源,及保密級別,可包括:使用者操作手冊;與本專案有關的其他文件。2 系統說明2.1 系統用途:說明系統具備的功能,輸入和輸出。2.2 安全保密:說明保密方面的考慮。2.3 總體說明:說明系統的總體功能,對系統、子系統和作業做出綜合性的介紹,並用圖表的方式給出系統主要部分的內部關係。2.4 程式說明:說明系統中每一程式、分程式的細節和特性。2.4.1 程式1的說明
● 功能:說明程式的功能。
● 方法:說明實現方法。
● 輸入:說明程式的輸入、媒體、執行資料記錄、執行開始時使用的輸入資料的型別和存放單元、與程式初始化有關的入口要求。
● 處理:處理特點和目的,如:用圖表說明程式的執行的邏輯流程;程式主要轉移條件;對程式的條件;程式結束時的出口要求;與下一個程式的通訊與聯結(執行、控制);由該程式產生並茶館處理程式段使用的輸出資料型別和存放單元;程式執行儲存量、型別及儲存位置等。
● 輸出:程式的輸出。
● 介面:本程式與本系統其他部分的介面。
●表格:說明程式內部的各種表、項的細節和特性。對每張表的說明至少包括:表的識別符號;使用目的;使用此表的其他程式;邏輯劃分,如塊或部,不包括表項;表的基本結構;設計安排,包括表的控制資訊。表目結構細節、使用中的特有性質及各表項的標識、位置、用途、型別、編碼表示。
● 特有的執行性質:說明在使用者操作手冊中沒有提到的執行性質。2.4.2程式2的說明
與程式1的說明相同。以後的其他各程式的說明相同。3 操作環境3.1 裝置:逐項說明系統的裝置配置及其特性。3.2 支援軟體:列出系統使用的支援軟體,包
括它們的名稱和版本號。3.3 資料庫:說明每個資料庫的性質和內容,包括安全考慮。3.3.1總體特徵:如識別符號、使用這些資料庫的程式、靜態資料、動態資料;資料庫的儲存媒體;程式使用資料庫的限制。3.3.2結構及詳細說明
● 說明該資料庫的結構,包括其中的記錄和項。
● 說明記錄的組成,包括首部或控制段、記錄體。
● 說明每個記錄結構的欄位,包括:標記或標號、欄位的字元長度和位數、該欄位的允許值範圍。
● 擴充:說明為記錄追加欄位的規定。4 維護過程4.1 約定:列出該軟體系統設計中所使用全部規則和約定,包括:程式、分程式、記錄、欄位和儲存區的標識或標號助記符的使用規則;圖表的處理標準、卡片的連線順序、語句和記號中使用的縮寫、出現在圖表中的符號名;使用的軟體技術標準;標準化的資料元素及其特徵。4.2 驗證過程:說明一個程式段修改後,對其進行驗證的要求和過程(包括測試程式和資料)及程式週期性驗證的過程。4.3 出錯及糾正方法:列出出錯狀態及其糾正方法。4.4 專門維護過程:說明文件其他地方沒有提到的專門維護過程。如:維護該軟體系統的輸入輸出部分(如資料庫)的要求、過程和驗證方法;執行程式庫維護系統所必需的要求、過程和驗證方法;對閏年、世紀變更的所需要的臨時性修改等。4.5 專用維護程式:列出維護軟體系統使用的後備技術和專用程式(如檔案恢復程式、淘汰過時檔案的程式等)的目錄,並加以說明,內容包括:維護作業的輸入輸出要求;輸入的詳細過程及在硬裝置上建立、執行並完成維護作業的操作步驟。4.6 程式清單和流程圖:引用或提供附錄給出程式清單和流程圖。
軟體問題報告
1 登記號
由軟體配置管理部門為該報告規定一個唯一的、順序的編號。
2 登記日期
軟體配置管理部門登記該報告的日期。
3 問題發現日期
發現該問題的日期和時間。
4 活動
在哪個階段發現的問題,分為單元測試、組裝測試、確認測試和執行維護。
5 狀態
在軟體配置記錄中維護的動態指示,狀態表示有:正在複查"軟體問題報告",以確定將採取什麼行動;"軟體問題報告"已由指定的人去進行處理;修改已完成,並經過測試,正準備交給主程式庫;主程式庫已經更新,主程式庫修改的重新測試沿未完成;做了重新測試,問題再現;做了重新測試,所做的修改無故障,"軟體問題報告"被關閉;留待以後關閉。6 報告人
填寫"軟體問題報告"人員的姓名、地址、電話。7 問題屬於什麼方面
區分是程式的問題,還是模組的問題,或是資料庫的問題,檔案的問題。也可能是它們的某種組合。
8 模組/子系統
出現的模組名。如果不知是哪個模組,可標出子系統名,儘量給出細節。
9 修訂版本號
出現問題的模組版本。
10 磁帶
包含有問題的模組的主程式庫的磁帶的識別符號。
11 資料庫
當發現問題時所使用資料庫的識別符號。
12 檔案號
有錯誤的檔案的編號。
13 測試用例
發現錯誤時所使用測試用例的識別符號。
14 硬體
發現錯誤時所使用的計算機系統的標識。
15 問題描述/影響
問題症兆的詳細描述。如果可能,則寫明實際問題所在。也要給出該問題對將來測試、介面軟體和檔案等的影響。
16 附註
記載補充資訊。
軟體修改報告
1 登記號
由軟體配置管理部門為該報告規定的編號。
2 登記日期
軟體配置管理部門登記"軟體修改報告"的日期。3 時間
準備好"軟體修改報告"的日期。4 報告人
填寫該報告的作者。
5 子系統名
受修改影響的子系統名。
6 模組名
被修改的模組名。
7 "軟體問題報告"的編號
被"軟體修改報告"處理或部分處理的"軟體問題報告"的編號。如果某"軟體問題報告"的問題只是部分被處理,則在編號後附以p,如1234p。8 修改
包括程式修改、檔案更新、資料庫修改或它們的組合。
9 修改描述
修改的詳細描述。如果是檔案更新或資料庫修改,還要列出檔案更新通知或資料庫修改申請的識別符號。
10 批准人
批准人簽字,正式批准進行修改。
11 語句型別
程式修改中涉及到的語句型別,包括:輸入/輸出語句類、計算語句類、邏輯控制語句類、資料處理語句類(如資料傳送、存取語句類)。12 程式名
被修改的程式、檔案或資料庫的名字。
13 老修訂版
當前的版本/修訂本標識。14 新修訂版
修改後的版本/修訂本標識。15 資料庫
如果申請資料庫修改,則給出資料庫的識別符號。
16 資料庫修改報告
資料庫修改申請號。
17 檔案
如果要求對檔案進行修改,則給出檔案的名字。
18 檔案更新
檔案更新通知單的編號。
19 修改是否已測試
指出已對修改做了哪些測試,如單元、子系統、組裝、確認和執行測試等,並註明測試成功與否。
20 "軟體問題報告"是否給
出問題的準確描述
回答'是'或'否'。21 問題註釋
準確地敘述要維護的問題。
22 問題源
指明問題來自於哪裡,如軟體需求說明書、設計說明書、資料庫、源程式等。
23 資源
完成修改所需資源的估計,即總的人時數和計算機時間的開銷。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-992090/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 軟體開發專案文件系列之二如何撰寫專案建設方案
- 軟體開發專案文件系列之十五如何撰寫專案結項報告
- 軟體開發專案文件系列之九如何撰寫測試方案
- 軟體開發專案文件系列之十六如何撰寫系統運維方案運維
- 軟體開發專案文件系列之一文件綜述
- 軟體開發專案文件系列之五如何撰寫需求規格說明書
- 軟體開發專案文件系列之十三如何撰寫使用者操作手冊
- weblogic中介軟體軟體上線標準化部署Web
- 從react轉職到vue開發的專案準備ReactVue
- 敏捷開發專案管理軟體敏捷專案管理
- 敏捷開發,如何編寫架構文件敏捷架構
- ?用 Laravel 開發的一個輕鬆的 Markdown 文件編輯專案Laravel
- 專案管理,如何做到流程標準化專案管理
- 哪款專案管理軟體的文件管理功能好?專案管理
- [程式設計] AI助力軟體專案正向生成,註釋編寫的革命程式設計AI
- 開發框架文件體系化的思考框架
- 免費版軟體文件檔案格式轉換
- 軟體開發公司的專案管理怎麼做專案管理
- Windows 專案的 CMakeLists 編寫Windows
- MarkDown文件的編寫
- 文件編寫
- WordPress開發入門09:WordPress編碼標準
- 如何為開發專案編寫規範的README檔案(windows),此文詳解Windows
- 提升團隊效率:高質量軟體設計文件的編寫方法
- 分析如何使用專案管理軟體管理軟體開發團隊專案管理
- 如何定義專案的成功標準?
- 關於軟體專案開發的分析與設計
- 如何避免軟體開發專案中的需求管理陷阱?
- 淺析軟體開發專案的前期溝通工作
- 2022國產敏捷開發專案管理軟體敏捷專案管理
- Linux已成為世界最大軟體開發專案Linux
- Json檔案轉換為Excel檔案!涉及讀檔案,時間戳轉化,寫文件JSONExcel時間戳
- 管理CRM軟體選購的標準
- 軟體工程國家標準軟體工程
- 專案客製化文件
- [譯] 元件化開發利器:Web Components標準元件化Web
- 透過介面標準化ABAP OO開發
- 手寫程式語言-如何為 GScript 編寫標準庫
- 軟體編寫風格