軟件項目開發(fā)流程書(1).doc_第1頁
軟件項目開發(fā)流程書(1).doc_第2頁
軟件項目開發(fā)流程書(1).doc_第3頁
軟件項目開發(fā)流程書(1).doc_第4頁
軟件項目開發(fā)流程書(1).doc_第5頁
已閱讀5頁,還剩6頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

軟件項目開發(fā)流程軟件項目開發(fā)流程 修改歷史修改歷史 日期日期作者作者修改內(nèi)容修改內(nèi)容 2003 03 12 新規(guī)制作 2003 5 18 人員職責的變更 內(nèi)容的變更 2003 12 4 針對 2004 年度制作最新工作內(nèi)容下的工作流程 2004 1 14 添加項目經(jīng)理管理被職員填寫下周日程表的規(guī)則 1 1概述概述 3 3 1 1目的 3 1 2內(nèi)容概述 3 2 2開發(fā)部日常管理流程具體實施方案開發(fā)部日常管理流程具體實施方案 3 3 2 1基本原則 3 2 2內(nèi)容概述 3 2 3內(nèi)容詳細描述 3 3 3開發(fā)部管理流程具體實施方案開發(fā)部管理流程具體實施方案 1010 3 1內(nèi)容概述 10 3 2開發(fā)部概要流程圖 12 3 3開發(fā)部管理人員工作流 12 3 4BUGSURVEY工作流 15 3 5項目分析工作流 15 3 6BETA后質(zhì)量保證工作流 15 3 7測試組BETA前工作流 15 3 8項目組基本工作流 15 3 9測試部 版前流程 19 4 4績效考核實施方案績效考核實施方案 2121 4 1總則 21 4 2流程圖 21 5 5開發(fā)部激勵和過失管理流程開發(fā)部激勵和過失管理流程 2424 5 1激勵管理系統(tǒng) 24 5 2過失管理系統(tǒng) 24 1概述概述 1 1目的目的 用標準化的流程來統(tǒng)一管理公司的運作 避免混亂 提高管理的質(zhì)量 在實施過程中 所有管理者能夠根據(jù)此統(tǒng)一的流程 總結(jié)經(jīng)驗 提高認識 加 強技術(shù)水平和管理水平 提高公司級的技術(shù)分析能力 為公司儲備一支分析隊伍 側(cè)重在需求理解和需 求分析 框架設計上的能力 對人員負責內(nèi)容上 明確化各自負責的內(nèi)容 提高工作效率 1 2內(nèi)容概述內(nèi)容概述 開發(fā)部日常工作流程 開發(fā)部管理流程 開發(fā)部績效考核流程 開發(fā)部激勵和過失管理流程 2開發(fā)部日常管理流程具體實施方案開發(fā)部日常管理流程具體實施方案 2 1基本原則基本原則 公司開發(fā)部力求建立公平公正的評價體系 嚴謹?shù)墓ぷ髁鞒潭x和及時的記錄 與反饋 規(guī)范職員活動 形成一個緊張有序的團隊 沒有一個明晰的流程和高效的反饋體系 就不可能把工作做好 但是 這需要 每個人按照規(guī)則把自己應該負責的那一部分高效完成 只有這樣才能保證整個 系統(tǒng)的順暢 同時 如果個人沒有完成自己的指責和按照規(guī)定填寫內(nèi)容 影響 的不單單是自己的工作而是整個系統(tǒng) 2 2內(nèi)容概述內(nèi)容概述 日報周報使用規(guī)則 目的注意是為了提高開發(fā)部整體的計劃能力 反饋能力和管理者的控制能力 同時提高整體職員參與公司管理的渠道 日?;顒拥姆椒?提供開發(fā)部工作流程外的突發(fā)事件的解決方法 2 3內(nèi)容詳細描述內(nèi)容詳細描述 2 3 1 日報日報 周報使用規(guī)則周報使用規(guī)則 1 日報 周報的使用 加強全體人員的計劃能力 做到我每天要做什么 今天項目經(jīng)理給我的安排是 什么 對應項目經(jīng)理和部長要知道每個人在做什么 只有這樣 才能保證控制 人員可以宏觀調(diào)控 而個人也不會不知所措 注意事項 1 周報哪怕只有一天也需填寫 保持統(tǒng)一性 2 開始時間必須為 22 00 結(jié)束時間為 23 00 內(nèi)容內(nèi)容負責人負責人填寫要求填寫要求監(jiān)督人監(jiān)督人違規(guī)處理違規(guī)處理 周報項目組長 技術(shù)分析技術(shù)分析 負責人負責人 測試組組測試組組 長長 項目進展整體狀況 本周已完成工作量及不能解決的 問題反饋 建議或提議 為每一個人員安排下周工作計劃 下周項目風險的預估 必須填寫 必須每周五 16 00 前填寫完畢 項目經(jīng)理沒有按時提交的 負責人扣除相應的 績效 日報開發(fā)部全 體人員 項目進展狀況 不能解決的問題反饋建議或提議 突發(fā)問題必須反饋 突發(fā)問題必須反饋 當天已完成工作量 明天工作量當天已完成工作量 明天工作量 安排安排 建議大家把工作安排填寫 有利 于提高自己的計劃能力和規(guī)劃能 力 同時能保證事情不會忘記 項目組長 2 目標功能的使用 為每一個程序員根據(jù)個人不同的能力和狀況設定目標 對于圓滿完成目標者進 行鼓勵 同時 保證公司的開發(fā)效果在可控制范圍內(nèi) 3開發(fā)部管理流程具體實施方案開發(fā)部管理流程具體實施方案 3 1內(nèi)容概述內(nèi)容概述 開發(fā)部從流程上主要分為以下幾方面 1 開發(fā)部管理人員工作流 2 BUG Survey 工作流 3 項目分析工作流 4 Beta 后質(zhì)量保證工作流 5 測試組 beta 前工作流 6 項目組運行基本工作流 開發(fā)部從實施人員角色劃分如下 項目組長 項目組長 統(tǒng)籌解決項目的全部事宜 進行項目的整體計劃的制定和實施 保證項目的可持續(xù) 發(fā)展和利潤率 項目經(jīng)理 項目經(jīng)理 對公司級的資源進行調(diào)配 同時進行開發(fā)部的整體計劃的制定和實施 保證開發(fā)部 的可持續(xù)發(fā)展和利潤率 技術(shù)設計負責人 技術(shù)設計負責人 統(tǒng)一協(xié)調(diào)分析組的工作 在對日項目分析組中 進行設計文檔的統(tǒng)一確認 在對中 方項目中 承擔需求的統(tǒng)一把關(guān)處理 同時負責分析組的日常工作安排的統(tǒng)籌 QAQA 統(tǒng)一管理項目質(zhì)量保證 監(jiān)督項目組各項活動有序開展 程序員 程序員 主要是負責項目按照分析文檔的實施 同時 在實施過程中優(yōu)化代碼結(jié)構(gòu) 提出合 理化建議 其中優(yōu)秀者可以作為 TeamLeader 負責具體組織工作和分析管理工作 測試員 測試員 負責公司測試流程的具體實施 要求掌握測試的技術(shù) 提出合理化建議 并保證整 個軟件的可靠度 翻譯人員 翻譯人員 負責中外文文檔的翻譯 要求工作嚴謹 保證質(zhì)量 在同客戶交流中 負責接待和 溝通 同時 在個人的發(fā)展意向中可以兼顧其它公司內(nèi)的常務工作 3 2開發(fā)部概要流程圖開發(fā)部概要流程圖 3 3開發(fā)部管理人員工作流開發(fā)部管理人員工作流 3 3 1 軟件開發(fā)管理體系構(gòu)成軟件開發(fā)管理體系構(gòu)成 參與人員參與人員 技術(shù)設計負責人 測試負責人 項目組長 管理主線 管理主線 管理人員去合適目前我們正在進行的總量有多少 檢收而為付款的有多少 實施完畢而沒有檢收的有多少 管理人員去看我們下周能夠接受的項目有多少 以便在每周五可以制定下 周的工作計劃 項目經(jīng)理可以看自己負責項目的基本參數(shù) BugBug 管理系統(tǒng) 管理系統(tǒng) 作為質(zhì)量控制過程實際結(jié)果的監(jiān)控 以便總結(jié)質(zhì)量的問題 進 行反饋 FileserverFileserver 文檔文檔 通過文檔管理和整理 保證全部職員能夠隨時的了解其他 項目的信息和相信內(nèi)容 同時 統(tǒng)一化文檔管理 為以后的發(fā)展提供素材 所 有的文檔主要包含如下幾種 HearingSheet 一個簡要的需求 重點在于強調(diào)這個需求的原因 前因后 果 UI 文件 設計文檔 東京和北京共同進行 估算報價書 問題收集表 所有的問題一定要集中在一個文檔內(nèi) 功能點文檔 一定要融合問題收集表內(nèi)對應答案的所有內(nèi)容 計劃文檔 要包含甘特圖 項目總結(jié)及績效分配方案 把項目總結(jié)作為重點進行 單體測試用例 按照模板進行 測試組測試用例 要保證最后的測試結(jié)果 確認測試用例 客戶確認 beta 版后障害書 項目確認者發(fā)送 按照同一格式進行書寫和填寫 beta 后障害 list 表 其中包含 bug 的簡單描述 bug 的類型確定和各部 門關(guān)于 bug 的總結(jié) 2 過程管理類 一個項目兩次會議 項目啟動會議和項目總結(jié)會議一個項目兩次會議 項目啟動會議和項目總結(jié)會議 項目啟動會議主要是講述項目的功能點 并據(jù)具體問題 進行嚴格的定義 說 明本項目所必須遵守的特殊規(guī)則 子功能間的前后順序 統(tǒng)一的接口定義 和 每個人在項目實施中應該注意的問題 項目總結(jié)會議和 MD 分配方案的確定 主要是根據(jù)項目實施的結(jié)果 進行集中 的討論 和諧而公平的團隊和諧而公平的團隊 公司其他方面的管理 就是為了加強管理 提倡量化 做 到各司其職 多勞多得 公平評價 提供機會給相應的人 3 3 2 管理人員注意事項管理人員注意事項 其中反饋機制的建立最關(guān)鍵 其中管理必須遵守以下規(guī)則 對象對象流程流程 編號編號 工作內(nèi)容工作內(nèi)容上流方上流方下流方下流方備注備注 項目經(jīng)理分配項目客戶負責人項目組長 解決人力矛盾項目組長 測試負責人 技術(shù)設計負責人 項目組長 測試負責人 技術(shù)設計負責 人 下流方人員負責把結(jié)果 反饋給東京擔當者 開發(fā)部經(jīng)理公司管理問題項目經(jīng)理 各級負責人 職員 全體職員一定要給問題提出者答 復 成為制度后頒布 組長分配項目項目經(jīng)理各個成員 項目人力調(diào)節(jié)無項目經(jīng)理如果出現(xiàn)空閑同時反饋 分部管理問題無開發(fā)部經(jīng)理 項目經(jīng)理項目分析和問題確認無客戶結(jié)果物概要需求文檔和 問題與回復整理文檔 項目里程碑信息反饋 項目開始時間 項目開始時間 alfa betaalfa beta 版本時間和版本時間和 原因 估算變更及原因原因 估算變更及原因 無項目經(jīng)理 組織團隊進行技術(shù)文檔 的書寫和維護 無測試部經(jīng)理測試部經(jīng)理 teamteam 所有成員所有成員 文檔列表如下 功能點文檔 問題收集 計劃書 單體測試用例 QA 監(jiān)督 svn 的執(zhí)行情況程序員 項目經(jīng)理 組長 監(jiān)督過程管理參數(shù)組長 項目經(jīng)理 整理所有項目文檔組長項目經(jīng)理 對日匯報表組長項目經(jīng)理 績效考核提供過程情況 匯總 組長項目經(jīng)理月度過程管理處理表 測試部經(jīng)理組織書寫測試用例項目經(jīng)理 功能 點文檔 東京 整理匯總 beta 版后 bug 分析表 項目經(jīng)理 提供 的完整的 后 障害書 所有管理者其中的技術(shù)分析和管理 分析及對東京的建議應 由項目負責人進行填寫 控制測試的結(jié)果 3 4BugsurveyBugsurvey 工作流工作流 參見 bugSurvey 工作規(guī)約 3 5項目分析工作流項目分析工作流 參見 項目分析工作規(guī)約 3 6BetaBeta 后質(zhì)量保證工作流后質(zhì)量保證工作流 參見 beta 后規(guī)作規(guī)約 3 7測試組測試組 betabeta 前工作流前工作流 3 8項目組基本工作流項目組基本工作流 3 8 1 概述概述 在項目進行過程中 要求能夠及時反饋 做好計劃安排 并調(diào)整這個人力的配 比 以達到最好的效果 3 8 2 對程序員的要求對程序員的要求 尤其在分析組成立前期 對分析組的設計書 盡可能提出建設性意見和設 計的問題 有利于提高項目分析能力 在功能實現(xiàn)上 主要和項目經(jīng)理的溝通 把類結(jié)構(gòu)設計和代碼向理想情況 努力 同時用公司內(nèi)的代碼規(guī)范作為自己的行動準則 在日常活動中 加強團體意識 加強責任感 3 8 3 對項目經(jīng)理的要求對項目經(jīng)理的要求 主要職責為 類設計的嚴格控制 保證整個軟件包的可維護性 項目過程管理 能夠緊密的控制整個項目的進程 發(fā)現(xiàn)項目中的各種風險 因素 盡早地把風險在項目中消除 硬性要求如下 1 每個項目 大于 10MD 正常項目 必須提供的文檔為功能點文檔 需求收集 單體測試用例 項目總結(jié)及 MD 最終分配方案文檔 2 每個項目 大于 10MD 正常項目 必須召開兩次會議 項目啟動會議主要為了統(tǒng)一項目的內(nèi)容規(guī)則和要求 同時把整體 邏輯和框架做簡要說明 項目總結(jié)會議 主要是評價每個成員的表現(xiàn)和項目完整的狀況和 質(zhì)量 總結(jié)失敗的經(jīng)驗教訓 同時根據(jù)評論的結(jié)果進行最后的 MD 的分配 整個團隊的建設和公司的管理工作 在項目管理中發(fā)現(xiàn)問題 把反映給公 司 以備在公司級別對整個流程和各個環(huán)節(jié)進行調(diào)整 3 8 4 流程圖流程圖 接收來自項目經(jīng)理 的項目通知 收到來自分析組概 要設計第一版的通 知 確定alfa和beta版 本 接收來自分析組詳 細設計第一版 項目啟動會議 功 能點和人員分配 項目的類結(jié)構(gòu)設計 項目組長和程序 員 編碼 項目中出現(xiàn)新問題 開發(fā)組內(nèi)代碼檢查 書寫單元測試用例 單元測試 提交alfa版本 項目總結(jié)會議 關(guān)注項目的分析進 程并做初步計劃 1 功能點文檔 2 問卷 功能點及問卷文檔 名確認及svn路徑 郵件通知測試 經(jīng)理 QA 對概要設計做初步 審核 郵件通知項目 經(jīng)理及測試負 責人 項目開 始時間 alfa 時間beta時間 上傳項目開始時 間 alfa時間beta 時間 計劃安排文檔 結(jié)合項目情況進行 計劃調(diào)整 制作項目安排計劃 表計劃表上傳SVN 項目經(jīng)理審批 要遵守編 碼規(guī)則和 類結(jié)構(gòu)方 案 郵件給文檔作 者 并通知項 目組長和項目 經(jīng)理 提交項目經(jīng)理 Bug管理系統(tǒng)錄入 代碼走讀記錄 制作單元測試文檔上傳SVN 路徑 文檔名格式 提交項目經(jīng)理 結(jié)果反映到單元測 試用例文檔中并上 傳SVN 郵件通知測試 組長 發(fā)送測試組 制作項目總結(jié)報告 上傳SVN 3 8 5 項目組文檔管理項目組文檔管理 原則 Comment A1 注意修正 所有文檔必須都放在 SVN 上 進行統(tǒng)一管理 同時 負責人在本地應保 留一份同樣的備份 細節(jié)描述 各路徑存放什么文件 項目項目內(nèi)容內(nèi)容備注備注 Spec 設計說明書 QuestionSheet 設計說明書的補充說明 設計說明書的各個版本 設計說明書一覽表 設計說明書一覽表要記錄所有文檔 變更的情況 并指明最后項目實施 與文檔之間的關(guān)系 Test case 項目組書寫的單體測試用例 測試組書寫的測試用例 東京發(fā)送的 confirm 測試用例 Schedule 針對項目實施的日程安排 對東京進行進度匯報的每個報表 Function Points 功能點文檔 All Bug Spec Beta 后障害書 針對此項目的 beta 后 bug 類型確定和經(jīng)驗匯總 完 畢后 應及時發(fā)送測試組項目經(jīng)理 UIHtml Demo Hearing Sheet 聯(lián)系分析組 如果有應該直接 copy FP Spec FP sheet 不同版本 FP change 表 FP 說明 記錄所有 FP 變更歷史 以備后期確認的 方便 3 9測試部測試部 版前流程版前流程 3 9 1 相關(guān)人員相關(guān)人員 測試部經(jīng)理 測試組成員 3 9 2 測試人員的要求測試人員的要求 一定要注意配合 因為 在此環(huán)節(jié) 一種好的描述方式和溝通方式將會直 接影響工作效率和工作質(zhì)量 所以 首先大家要注意 bug 管理系統(tǒng)的使用 方法和規(guī)則 同時 盡量采用統(tǒng)一的屬于進行描述 如果需要圖形輔助 也可以進行貼圖 加強需求理解能力 能夠盡快的理解文檔和功能測試用例 在工作中細致 耐心 有條理 同時對應 esm 系統(tǒng)需要測試部填寫的過程參數(shù)必

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論