華鑫置業（集團）股份****
一、目的和作用
本流程詳細規定軟體開發程的各個階段及每一階段的任務、要求、交付檔案，使整個軟體開發過程階段清晰、要求明確、任務具體，實現軟體開發過程的標準化。
二、適用範圍
公司的資訊系統開發產品均適用。
三、適用物件
開發管理人員，系統開發人員，系統維護人員
四、軟體開發流程
4.1可行性研究與計畫
4.1.1實施
a. 軟體開發部分析人員進行市場調查與分析，確認軟體的市場需求
b. 在調查研究的基礎上進行可行性研究，寫出可行性報告
c. 評審和審批，決定專案取消或繼續
d. 若專案可行，制訂初步的軟體開發計畫，建立專案日誌
e. 根據市場環境、公司軟硬體情況**十大風險因素
4.1.2 文件
a. 應交付的文件
1） 可行性研究報告
2） 初步的軟體開發計畫
3） 十大風險列表
4） 軟體專案日誌
b. 提交步驟
1） 適用於以後各階段的文件提交。
2） 專案相關文件用管理工具進行版本管理，相關書寫人員可根據各文件模板形式撰寫文件，正式提交的文件以存入軟體管理伺服器相關目錄時間為準。以後每次修改都應註明修改內容。
4.2需求分析
4.2.1實施
a. 調查被開發軟體的環境
b. 軟體開發提出的需求進行分析並給出詳細的功能定義
c. 做出簡單的使用者原型，與使用者共同研究，直到使用者滿意
d. 對可利用的資源（計算機硬體、軟體、人力等）進行估計，制定專案進度計畫（可有相應的緩衝時間）
e. 制定詳細的軟體開發計畫
f. qa部門制訂質量控制計畫和測試計畫
g. 編寫初步的使用者手冊
h. 評審
4.2.2要求
a. 必須以執行環境為基礎
b. 應有使用者指定人員參加
c. 需求說明書必須明確，並經過使用者確認
4.2.3交付文件
a. 軟體需求說明書
b. 使用者手冊(概要)
c. 更新後的軟體開發計畫
d. 專案進度計畫
e. qa計畫
f. 測試計畫*
g. 更新後的十大風險列表
h. 軟體日誌
4.2.4審批
a. 經評審通過的各項內容形成相應的文件後，提交給專案經理審核確認
b. 軟體需求說明書經開發組長確認後再提交給專案經理進行審核確認。
4.3概要設計
4.3.1實施
a. 確定目標系統的總體結構
1) 對於大型系統，可按主要的軟體需求劃分成子系統，然後為每個系統定義功能模組及各功能模組間的關係，並描述各子系統的介面介面
2) 對於一般系統，可按軟體需求直接定義目標系統的功能模組及各功能模組間的關係
b. 給出每個功能模組的功能描述，資料介面描述，外部檔案及各功能模組部的關係
c. 設計資料庫或資料結構
d. 制定各階段開發的目標（以下稱里程碑）計畫
e. 制訂第乙個里程碑的測試計畫
f. 評審
4.3.2要求
a. 在設計目標系統的整體結構時，應力爭使其具有好的形態，各功能模組間應滿足低耦合度，而各功能模組內應滿足高內聚度。功能模組的作用範圍應在其控制範圍之內。
b. 在設計目標系統的總體結構時，應降低模組介面的複雜性，提高目標系統的可靠性
4.3.3交付文件
a. 概要設計說明書
b. 資料庫/資料結構設計說明書
c. 更新後的使用者手冊
d. 更新後的專案進度計畫
e. 更新後的十大風險列表
f. 更新後的軟體開發計畫
g. 更新後的軟體專案日誌
4.3.4補充說明
a. 測試程式的編寫需與開發組長協商根據開發小組和qa小組的工作量確定由qa組還是由開發組完成
b. 每乙個里程碑又可分為詳細設計、實現、組裝測試、確認測試、發布、交接等階段。
4.3.5審批
a. 經評審通過的各項內容形成相應的文件後，提交給專案經理審核確認
b. 資料庫/資料結構設計說明書、概要設計說明書經開發組長確認後還須提交給專案經理進行審核確認。
4.4詳細設計
4.4.1實施
a. 將概要設計產生的構成軟體系統的各個功能模組逐步細化，形成若干個程式模組（可程式設計模組）
b. 確定各程式模組之間的詳細介面資訊
c. 撰寫擬定單元測試計畫
d. 評審
4.4.2要求
a. 確定程式模組內的資料流或控制流，對每個程式模組必須確定所有輸入、輸出和處理功能。
b. 規定符號的使用，確定命名規則。
4.4.3文件
a. 詳細設計說明書
b. 單元測試計畫
4.4.4審批
a. 經評審通過的各項內容形成相應的文件後，提交給專案經理審核確認。
b. 詳細設計說明書經開發組長確認後還須提交給專案經理進行審核確認。
4.5實現
4.5.1實施與要求
a. 對每個程式模組用所選定的程式語言進行編碼，寫出的程式應該是結構良好、清晰易讀、且與設計一致，符合公司編碼規範
b. 單元測試：開發人員按單元測試計畫對自己編寫的程式進行測試
c. 程式設計及單元測試過程用管理軟體進行版本管理，主要由專案組長負責
管理。4.5.2交付文件
單元測試報告
4.5.3審批
所有文件必須提交給專案經理審核確認。
4.6組裝測試
4.6.1實施
a. 開發組單元自測完成後，填寫測試申請單連同要測試產品清單交給qa
b. 相關qa人員根據提交申請單將源程式、文件等拷貝到測試中產品目錄
c. 執行測試計畫中所有要求的組裝測試
d. 對測試結果進行分析，生成當前問題列表（buglist），返回專案組長
e. 開發人員經過分析，修復並自測完畢，生成bug修復報告，返回qa
f. 完成：反覆直至qa通過。
4.6.2要求
a. 組裝測試應保證模組間無錯誤的連線
b. 應對軟體系統或子系統的輸入/輸出能力進行測試，使其達到設計要求
c. 應測試軟體系統或子系統正確能力和經受錯誤的能力
4.6.3交付文件
a. 執行的軟體系統源程式清單
b. 組裝測試計畫
c. 當前問題列表（buglist）
d. bug修復報告
e. 組裝測試分析報告
4.6.4審批
所有文件必須提交給專案經理審核確認。
4.7確認測試
4.7.1實施
a. 模擬的環境中進行強度測試，即在事先規定的乙個時期內執行軟體的所有功能，以證明該軟體無嚴重錯誤
b. 執行測試計畫中的所有確認測試
c. 使用使用者手冊，以進一步證實其實用性和有效性，並改正其中的錯誤
d. 對測試結果進行分析，生成當前問題列表（buglist）
e. 反覆查詢bug原因，直到修復
f. 對所有檔案進行整理
4.7.2要求
a. 全部系統儲存量、輸入及輸出通道，以及處理必須有足夠的餘量
b. 全部預期結果、測試結果及測試資料全部存檔
c.交付文件
1) 確認測試計畫
2) 更新後的使用者手冊
3) 更新後的專案進度計畫
4) 更新後的十大風險列表
5) 更新後的軟體專案日誌
6) 測試產品清單
7) 當前問題列表（buglist）
8) bug修復報告
4.7.4 補充說明
a. qa部門將測試清單中缺少的文件也列入buglist
b. 對於測試中重現與未重現的bug均要有說明
4.7.5 審批
所有文件完成後須提交給專案經理審核確認。
4.8發布
4.8.1過程
a. 經測試合格的產品qa填寫發布申請表連同發布文件一起提交給qa經理、開發組長、專案經理
b. qa經理、開發組長、專案經理審核發布申請
c. qa人員將發布產品（包括源程式、執行檔案及相關文件）放入發布中產品目錄並生成安裝程式
4.8.2 文件
a. 當前版本說明
b. 發布文件
c. 使用者手冊
d. 安裝手冊
e. 發布產品檢查清單checklist
f. 發布產品審批文件
g. 更新後的軟體日誌
4.8.3 審核
所有發布文件須經qa部、開發組長、專案經理審核確認。
4.9 交接
參見交接流程。
資訊系統開發與管理
2010年1月高等教育自學考試 資訊系統開發與管理試題課程 04757 一 單項選擇題 本大題共15小題，每小題2分，共30分 1.梅特卡夫法則認為網路的價值與結點數的平方成正比，這反映了系統的 的價值 a.穩定性 b.開放性 c.層次性 d.整體性 2.作業層的資料結構通常為 a.結構化 b.非結...
庫存管理資訊系統開發
系統分析 2.1需求分析與可行性分析 2.1.1需求分析 通過大量的調查，我們了解到當前的該廠的業務由於採用的是手工管理，賬目繁多，加之幾個倉庫距離較遠，庫管員 計畫員和有關領導相互之間的資訊交流困難，使得物資 效率低下，影響生產。同時每月的月末報表會耗費大量的大力，且由於手工處理容易造成失誤，從而...
4757資訊系統開發與管理
1.1 管理資訊系統的概念及其發展 1 管理資訊系統是管理和資訊科技不斷融合的產物，是資訊化的具體表現形式和主要內容 2 管理資訊系統是乙個以資訊科技為工具，具有資料處理 控制和輔助決策功能的資訊系統 1.2 管理資訊系統的分類 1 按核心業務活動分類 電子業務系統 服務於組織的內部管理 電子政務系...