第一篇：軟件項目管理報告案例

1．引言

1.1編寫目的

該文檔首先給出了整個系統的整體網絡結構和功能結構的概貌，試圖從總體架構上給出整個系統的輪廓，然后又對功能需求、性能需求和其它非功能性需求進行了詳細的描述。其中對功能需求的描述采用了UML的用例模型方式，主要描述了每一用例的基本事件流，若有備選事件流則描述，否則則省略。而且還給出了非常直觀的用例圖。這些文字和圖形都為了本文檔能詳細準確地描述用戶的需求，同時也為用戶更容易地理解這些需求的描述創造了條件。

1.2項目背景

a.所建議開發軟件的名稱：學生信息管理系統

b.項目的任務提出者：xxx學校。c.開發者：xxx軟件開發公司。d.用戶：全體師生。

e.實現軟件的單位：軟件3071軟件開發公司。f.項目使用的軟件：Microsoft access2003。g.系統：本軟件應使用Microsoft Windows xp。1.3定義

本文檔中沒有用到專門術語的定義和縮寫詞的原文。1.4參考資料

[1] 周佩德.《數據庫原理及應用》.電子工業出版社

[2] 劉炳文等，VISUAL BASIC程序設計——數據庫篇，1999 [3] 李光明.《Visual Basic編程實例大制作》.冶金工業出版社

[4] 李紅等編著，管理信息系統開發與應用，電子工業出版社，2003 [5] 軟件工程，人民郵電出版社，2002年3月第一版

[6] 康博工作室，張紅軍，王紅等縞著《Visual Basic中文版高級應用與開發指南》，人民郵電出版社，2001年4月第一版

[7] 林立軍，程斌，翁迪恩縞著《Visual Basic 數據庫開發指南》，西安電子科技大學出版社，2000年2月第一版

[8] 宋偉，吳建國等編著《中文Visual Basic編程基礎》，北京，清華大學出版社

2．可行性研究的前提

2.1要求

通過調查,要求系統需要有以下功能:

⑴

要求有良好的人機界面;

⑵

較好的權限管理;

⑶

原始數據修改簡單方便,支持多條件修改 ⑷

方便的數據查詢，支持多條件查詢;⑸

相應的權限下，刪除數據方便簡單，數據穩定性好；

⑹

數據計算自動完成，盡量減少人工干預;2.2目標 a.人力與設備費用的節省； b.處理速度的提高；

c.控制精度或生產能力的提高；

d.管理信息服務的改進； e.決策系統的改進； f.人員工作效率的提高。2.3條件、假定和限制

a.開發軟件運行的最短壽命為一年。b.進行系統方案選擇比較的期限：2周。c.經費來源和使用限制：自籌資金。

d.法律和政策方面的限制：本軟件公司版權所有，未經作者允許，非法傳播、復制，違者追究法律責任，后果自負。e.硬件CPU p3、內存256M.。f.軟件：access2003。

g.運行環境：本軟件應使用Windows2003、Windows xp操作系統。

h.開發環境：本軟件應使用Windows2003、Windows xp開發。i.開發軟件投入使用的最遲時間為2013年10月01日。2.4可行性研究方法

由于本系統管理的對象單一,都是在校學生，且每個數據內容具有較強的關聯性，涉及的計算過程不是很復雜。因此，比較適合于采用數據庫管理。且學校用于學生管理的微機都是PIII以上的機器，在存儲量、速度方面都能滿足數據庫運行的要求。在技術難度方面，由于有指導老師的指導和相關參考文獻，特別是網上資料，特別是參考其它程序的功能，因此完全可以實現

3．對現有系統的分析

3.1處理流程和數據流程 班級管理業務流程圖： 檔案管理業務流程圖： 課程管理業務流程圖： 成績管理業務流程圖 3.2工作負荷

現有系統所承擔的工作只能實現檔案管理的簡單功能，無法適應目前工作 中處理大量數據的功能。3.3費用支出

開發這個項目總需三個人，4臺計算機，一個可容納6、7個人的辦公室，必須有充足的物質做精神動力，每臺計算機上必須有所需要的軟件，比如：辦公軟件、數據庫軟件、截圖軟件等，必須有3000萬元的準備開支。3.4人員

數據庫管理人員1名，維護人員1名。

1、3.5設備

四臺計算機,一臺備用,一個工作室.一臺打印機,掃描儀一臺。3.6局限性

現有系統主要存在如下不足： 1）信息分散、共享性差 每個人的時間精力是有限的，大量的信息資源分散在不同的收集者手中，難于共享和發揮作用。還有就是用戶畢業和離職時需要到不同的地方開辦證明。2）信息的及時性、準確性差

數據的采集和處理部分靠人工，效率低、速度慢、滯后嚴重、反饋不及時，嚴重影響信息的反饋速度和質量，不能有效地、及時地提供基層決策需要的定量信息和領導決策需要的宏觀定性信息。

4．所建議技術可行性分析 4.1對系統的簡要描述

建議系統實現注冊、查詢等具體功能。4.2處理流程和數據流程

4.3與現有系統比較的優越性

系統實現學生教師查詢各種信息。4.4采用建議系統可能帶來的影響 4.4.1對現有軟件的影響

需將計算機升級為CPU P3、內存256M，添加一臺打印機。4.4.2對現有軟件的影響

需要將Windows升級為2000以上。4.4.3對系統運行的影響

（1）用戶的操作嚴格按照系統要求規程。

（2）要求創建系統管理員與普通用戶兩種登錄方式，分權限管理。

（3）數據應有系統管理員手動輸入系統，普通用戶無權輸入數據。

（4）對數據有保存要求，并且對數據存儲，恢復的處理。

（5）輸出報告以報表的形式打印出來。

（6）系統具有恢復和備份的功能。4.4.4對開發環境的影響

1、為了建立數據庫，要求提供詳細的數據資源。

2、為了開發和測驗所建議系統而需要的計算機資源：CPU P3、內存256M。

3、如數據涉及保密與安全問題，應由專人負責錄入。4.4.5對經費支出的影響

所建議系統的開發、設計經費開支：5000元。維持運行而需要的經費開支：1000元。4.5技術可行性評價

a.在限制條件下，完成功能目標的實現； b.利用現有技術，功能目標一定能達到；

c.對開發人員數量為5個人,每個人應對數據庫知識有明確的了解，我們的組員都具有這種能力,一定按期完成工作；

d.在規定的期限內，開發順利完成。5．所建議系統經濟可行性分析 5.1支出

5.1.1基建投資

1、房屋和設施：500元。

2、ADP設備：1000元。

3、數據通訊設備500元。

4、環境保護設備200元。5.1.2經常性支出

1、設備的租金和維護費用：500元。

2、數據的通訊方面的租金和維護費用500元。

3、人員的工資和獎金開支：3000元。

4、其他經常性的開支：2000元。5.2收益/投資比 收益/投資比為3:1.5.3投資回收周期 投資回收周期為半年.5.4敏感性分析

1、應盡量延長系統生存周期，可延長至3年。

2、應是有效數據全部錄入系統，使系統工作負荷量達到飽和。

3、應盡量提高系統的處理速度。

4、應提高設備和軟件的配置。6．社會因素可行性分析 6.1法律因素

如果發現有侵權行為,必進行嚴格的處罰,本公司版權所有,未經作者的允許，禁止非法傳播、復制，違者追究法律責任，后果自負。6.2用戶使用可行性

本系統使用比較簡單,適合普通用戶操作,只要用戶對說明書進行認真閱讀,都可了解。7．其他可供選擇的方案

方案有許多但本公司選擇了這套方案,他具有自己的優越感,運用編制菜單欄來省去代碼,這是界面有好起來,又降低了工作難度,進而宏的運用更簡化了工作難度。除提供的建議方案的具體功能外，還需增加網絡功能，未被推薦的理由是目前尚不具備開發條件，投入與效益不成比例。8.結論意見

結論意見可能是： a.可著手組織開發；

b.需待若干條件（如資金、人力、設備等）具備后才能開發； c.需對開發目標進行某些修改；

d.不能進行或不必進行（如技術不成熟，經濟上不合算等）； e.其他。

三 軟件項目計劃

1.引言

1.1 編寫目的

軟件項目開發是一項系統而復雜的工作，它需要一個團隊互相配合、分工協作。軟件項目管理系統可以規范一個軟件開發團隊的日常工作，提高工作效率。

為了很好的管理整個開發過程，同時預算整個開發過程的費用及時間的安排，給開發人員，管理人員一個參照物，明白自己在每一個階段所需要完成的任務，協助他們更好地完成開發工作。

預期的讀者：開發人員，項目經理，測試人員 1.2 背景

a.學生信息管理系統 b.提出者：項目經理，開發者：XXX開發團隊。1.3 定義

[列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。] 1.4 參考資料

[1] 周佩德.《數據庫原理及應用》.電子工業出版社

[2] 劉炳文等，VISUAL BASIC程序設計——數據庫篇，1999 [3] 李光明.《Visual Basic編程實例大制作》.冶金工業出版社

[4] 李紅等編著，管理信息系統開發與應用，電子工業出版社，2003 [5] 軟件工程，人民郵電出版社，2002年3月第一版

[6] 康博工作室，張紅軍，王紅等縞著《Visual Basic中文版高級應用與開發指南》，人民郵電出版社，2001年4月第一版

[7] 林立軍，程斌，翁迪恩縞著《Visual Basic 數據庫開發指南》，西安電子科技大學出版社，2000年2月第一版

[8] 宋偉，吳建國等編著《中文Visual Basic編程基礎》，北京，清華大學出版社 2.項目概述 2.1 工作內容 需求分析： 1~3個月 2 概要設計： 2~3個月 3 詳細設計： 2~3個月 4 編碼: 2~3個月 5 測試： 1個月 發布： 1個月 2.2 主要參加人員 參與者 個人情況

XX 軟件工程專業學生，熟悉java語言，數據庫編程 XX 軟件工程專業學生，熟悉C#語言 XX 軟件工程專業學生，有很好的網頁設計能力

XX 軟件工程專業學生，有良好的界面設計的能力和測試經驗 XX 專業為軟件工程，從事開發工作一年，能過獨立地完成小型項目的整個開發過程

2.3 產品 2.3.1 程序

名稱 編程語言 媒體形式 功能及能力

系統功能 C#+SQL Server 2000 文本 管理學生的學籍信息，統計學生的相關信息。學生信息的增加、修改、刪除、查詢 數據信息管理 C#+SQL Server 2000 文本 學生學籍信息管理，學生選課信息管理

基本業務 C#+SQL Server 2000 文本 學生注冊、學籍信息維護，學生選課，老師管理班級信息。

信息瀏覽與查詢 C#+SQL Server 2000 文本

管理員學生學籍信息瀏覽、查詢

數據庫 SQL Server 2000 數據庫文件 數據庫文件可以直接附加到本地的SQL Server 2000中的數據庫中

學生學籍管理系統 C#+SQL Server 2000 CD光盤

程序的運行文件，運行之后只要發布之后就可以了 2.3.2.文件

需求說明書，安裝指南，用戶操作手冊，預計可能出現故障及解決辦法 2.3.3.服務

培訓安裝：系統測試完畢之后，2012年10月10日至12日兩天的安裝和使用的培訓時間，主要是讓用戶適應本系統的運行環境與操作習慣 維護：系統出現故障時，用戶可參照手冊進行自行解決，如果解決不了，則派維護人員過去，系統的維護期2012年10月14日到2013年10月15日，超過期限將不再派人去維修 2.3.4.非移交的產品

整個系統全部的的代碼不必要給用戶，所使用的技術及參考的文獻也可以自己保留，以及該軟件所使用的技術文檔，這些都是不用給用戶的 3.實施計劃

3.1 工作任務的分解與人員分工 1需求分析

負責人： 汪國志 參與人：汪國志 2 概要設計

負責人：汪國志 參與人：汪國志 3 實現

負責人：汪國志

參與人：汪國志，XXX，XXX，XXX，XXX，XXX 4 測試

負責人：汪國志 參與人：汪國志 5 維護及用戶培訓 負責人：汪國志 參與人：汪國志 3.2 接口人員 負責人：汪國志 參與人：汪國志

職責:統一接口，使不同層之間能通信 3.3 進度 1 需求分析

開始時間：2012-10-01 完成時間：2012-12-30 所需資源：客戶的需求

完成標志：完成需求分析說明書 2 設計

開始時間： 2013-01-01 結束時間： 2013-03-01 所需資源： 需求分析說明書 完成標志： 概要設計說明書 3 編碼實現

開始時間： 2013-03-01 結束時間： 2013-06-01 所需資源： 概要設計說明書，設配 完成標志： 系統能順利運行 4 測試

開始時間： 2013-06-01 結束時間： 2013-08-01 所需資源： 能順利運行的系統 完成標志： 修復現存的bug 5 移交 開始時間： 2013-08-01 結束時間： 2013-10-01 所需資源： beta版系統 6 培訓 開始時間： 2013-10-01 3.4 預算

1.采購必要設備的投資： 網絡平臺的建設，包括了建設方式和聯網建筑物數等等方面去計算，這一塊需要200萬左右；

服務器與存儲系統，從發卡量和設備數量等估算，這一塊需要100萬左右； 射頻卡終端，包括讀寫器與POS機，這一塊需要20萬左右。2.開發系統的投資：

按目前市場上一卡通管理系統的開發價格來看，開發所需的投大概在50萬不等； 4.總計：:350萬左右； 3.5 關鍵問題

本系統的操作過程簡單，實現技術要求也不高，所以沒有要特別列出的關鍵問題 4.支持條件 4.1 運行環境

a.開發軟件運行的最短壽命為一年。b.進行系統方案選擇比較的期限：2周。c.經費來源和使用限制：自籌資金。

d.法律和政策方面的限制：本軟件公司版權所有，未經作者允許，非法傳播、復制，違者追究法律責任，后果自負。

e.硬件CPU p3、內存256M.。f.軟件：access2003。

g.運行環境：本軟件應使用Windows2003、Windows xp操作系統。h.開發環境：本軟件應使用Windows2003、Windows xp開發。4.2 需由用戶承擔的工作

數據庫的初始化需要用戶自己錄入，這個應該在測試之前完成，所以編碼之前，由開發人員做好數據庫，然后由用戶安排人錄入初始數據庫，且必須在2013年6月1日之前完成。4.3 需由外單位提供的條件

本項目希望得到委托商的資金支持，人員支持，如取需求時，能夠提供部分食堂為我們的測試的提供支持環境，還有技術支持 5.專題計劃要點

專題計劃 要點

合同計劃

在分析階段擬定合同書，分析階段一結束就簽訂合同，合同包括需求的定義，如出現任何問題，可以根據合同調解，以及費用的支付，在每個階段結束之后，委托方需支付開發方多少現金

測試計劃

包括單元測試，集成測試，系統測試計劃，主要參照開發文檔，擬定計劃，具體到輸入的格式，響應的時間，需求的確認

五 進度計劃風險列表

1.最常見的進度計劃風險

1）功能無限蔓延； 2）質量不定 3）計劃過于樂觀 4）設計欠佳 5）銀彈綜合癥 6）研發導向開發 7）人員薄弱 8）簽約商失敗；

10）研發人員與客戶的磨擦。2.進度計劃風險完整列表

2.1 計劃編制風險

1）計劃、資源和產品定義全憑客戶或上層領導口頭指令，并且不完全一致；

2）計劃是優化的，是“最佳狀態”； 3）計劃忽略了必要的任務；

4）計劃基于使用特定的小組成員，而那個小組成員其實指望不上。5）在限定的時間內無法建成已定規模大小的產品； 6）產品規模比估計的要大一些； 7）工作量大于估算數；

8）進度已經拖延的項目在重新評估時過于優化或忽視項目歷史； 9）過度的進度壓力造成生產率下降；

10）目標日期提前，但沒有相應地調整產品范圍或可用資源； 11）一個任務的延遲導致相關任務的連鎖反應；

12）涉足不熟悉的產品領域，花費在設計和實現上的時間比預期的要多。2.2 組織和管理

1）項目缺乏一個有凝聚力的最高領導人；

2）由于前期乏力，項目長時間被擱置； 3）解雇和削減開支導致項目小組能力下降；

4）僅由管理層或市場人員進行技術決策，導致計劃進度延長； 5）低效的項目組結構降低生產率；

6）管理層審查/決策的周期比預期時間長； 7）預算削減打亂項目計劃；

8）管理層做出了打擊項目組織積極性的決定； 9）非技術的第三方的工作比預期延長（如審批，采購等）； 10）計劃性太差，無法適應期望的開發速度；

11）項目計劃由于壓力而放棄，導致開發混亂、低效；

12）管理層強調英雄主義，而忽視客觀確切的狀態報告，這會降低發現和改正問題的能力。2.3 開發環境

1）設施沒有及時到位； 2）設施到位，但不配套； 3）設施擁擠、雜亂或者破損； 4）開發工具未能及時到位；

5）開發工具不如期望那樣有效，開發人員需要時間創建工作環境或切換新的工具；

6）開發工具的選擇不是基于技術需求，不能提供計劃要求的性能； 7）新開發工具的學習期比預期的長，內容繁多。2.4 最終用戶

1）最終用戶堅持新的需求；

2）最終用戶對于最后交付的產品不滿意，要求重新設計和重做； 3）最終用戶不買進項目產品，無法提供后續支持；

4）最終用戶的意見未被采納，造成產品最終無法滿足用戶期望，而必須重做。

2.5 客戶

1）客戶堅持新的需求；

2）客戶對規劃、原型和規格的審核/決策周期比預期長；

3）客戶沒有或不能參與規劃、原型和規格階段的審核，導致需求不穩定和耗時的重復；

4）客戶答復的時間比預期長（如回答需求中需澄清的問題）； 5）客戶堅持技術決策而導致進度計劃延長；

6）客戶對開發進度管理過細，導致實際進展變慢；

7）客戶提供的組件無法與開發的產品匹配，導致額外的設計和集成工作；

8）客戶提供的組件質量欠佳，導致額外的測試、設計和集成工作，以及額外的客戶關系管理工作；

9）客戶要求的支持工具和環境不兼容、性能差或者功能不完善，導致生產率降低；

10）客戶不接受交付的軟件，盡管它滿足了所有的規格； 11）客戶期望的開發速度是開發人員無法達到的。2.6 承包商

1）承包商沒有按承諾交付組件；

2）承包商遞交的組件質量低下無法接收，必須花時間改進質量；

3）承包商沒有買進項目開發需要的工具，進而無法提供需要的性能水平。

2.7 需求

1）需求已經成為項目基準，但變化還在繼續；

2）需求定義欠佳，而進一步的定義會擴展項目范疇； 3）添加額外的需求；

4）產品定義含混的部分比預期需要更多的時間。2.8 產品

1）錯誤發生率高的模塊需要比預期更多的測試、設計和實現工作；

2）校正質量低下不可接受的產品，需要比預期更多的測試、設計和實現工作。

3）在一個或多上新興領域推廣計算機技術使得計劃進度的延長不可預 4）由于軟件功能的錯誤，需要重新設計和實現；

5）開發額外不需要的功能（鍍金）延長了計劃進度；

6）要滿足產品規格與速度要求，需比預期更多時間，包括重新設計和實現的時間；

7）嚴格要求與現有系統兼容，需要進行比預期更多的測試、設計和實現工作；

8）要求與其他系統、復雜系統或不受本項目控制的系統相連，導致無法預料的設計、實現和測試工作。

9）要求在不同操作系統下運行將花費比預期更長的時間；

10）在不熟悉或未經檢驗的軟（硬）件環境中運行產生未預料的問題； 11）開發一種對組織全新的模塊將比預期花費更長的時間； 12）依賴正在開發中的技術將延長計劃進度。2.9 外部環境

1）產品依賴政府規章，而規章的改變將是不可預期的；

2）產品依賴草擬中的技術標準，而最后的標準將是不可預期的。2.10 人員

1）招聘人員所花時間比預期的長；

2）作為先決條件的任務不能按時完成（如培訓、其它項目）； 3）開發人員和管理層之間關系不佳導致決策緩慢，影響全局；

4）項目組成員沒有全身心投入項目，進而無法達到需要的產品性能水平；

5）缺乏激勵措施，士氣低下，降低了生產能力； 6）缺乏必要的規范，增加了工作失誤與重復工作；

7）某些人需要更多時間適應不熟悉的軟件工具和環境、硬件環境、編程語言；

8）項目結束前，合同制人員離開團隊，或雇員辭職；

9）項目后期加入新的開發人員，額外的培訓和溝通降低現有成員的效率；

10）項目組成員不能有效地一起工作；

11）由于項目組成員間的沖突，導致溝通不暢、設計欠佳、接口錯誤和額外的重復工作；

12）有問題的成員沒有調離項目組，損害了項目組其他成員的積極性； 13）項目的最佳人選未加入項目組；

14）項目的最佳人選已加入項目組，但因其他原因未能合理使用； 15）沒有找到項目急需的具有特定技能的人； 16）關鍵人物只能兼職參與； 17）項目人員不足；

18）任務的分配與人員技能不匹配； 19）人員工作的進展比預期的慢；

20）項目管理人員怠工導致計劃和進度失效；

21）技術人員怠工導致工作遺漏或質量低下，工作需要重做。2.11 設計與實現

1）設計過于簡單，無法確定主要事件，并導致重新設計和實現； 2）設計過于復雜，導致一些不必要的工作，影響實現效率； 3）設計質量低下，導致重復設計和實現

4）使用不熟悉的方法，導致額外的培訓時間，并重犯前期使用這種方法時導致的錯誤；

5）產品采用低級語言來實施，導致生產率比預期的低；

6）一些必要的功能無法使用現有的代碼和庫實現，開發人員必須使用新庫或自選開發所要的功能；

7）代碼和庫質量低下，導致需要額外的測試、錯誤修正或重做； 8）過高估計了增強型工具對計劃進度的節省量；

9）分別開發的模塊無法有效集成，需要重新設計或重做。2.12 過程

1）大量的紙面工作導致進程比預期的慢；

2）進程跟蹤不準確，導致無法預知項目是否已落后于計劃進度； 3）前期的質量保證行為不真實，導致后期的重復工作；

4）質量跟蹤不準確，導致無法得知影響進度的質量問題； 5）太不正規，導致溝通不足，質量問題和工作重做； 6）過于正規，導致過多耗時無用的工作；

7）向管理層撰寫進度報告占用的開發人員的時間比預期的多； 8）風險管理粗心，導致沒有發現重大的項目風險； 9）軟件項目風險管理花費的時間比預期的多。

第二篇：軟件項目管理實習報告

實習總結

從二零一二年七月九日開始到二零一二年七月二十日止，我們哈爾濱師范大學計算機系軟件項目管理專業全體同學去北京海輝集團雅思晟實訓中心開始我們的實習生活。

實習是每一個大學畢業生必須擁有的一段經歷，它使我們在實踐中了解社會、在實踐中鞏固知識。通過此次實習，我們將學校所學的會軟件知識與實際相結合起來，不僅讓我對整個軟件應用方面有了詳細而具體的認識，熟悉了軟件的具體工作對象，也縮短了抽象的課本知識與實際工作的距離。

在實習中，我在公司指導老師的熱心指導下，我積極參加小組討論，和組員們配合完成了我們小組的項目。簡短的實習生活，既緊張，又新奇，收獲也很多。通過實習，使我對java有了深層次的感性和理性的認識。

“紙上得來終覺淺，絕知此事要躬行。”在短暫的實習過程中，我深深的感覺到自己所學知識的膚淺和在實際運用中的專業知識的匱乏，剛開始的一段時間里，對一些工作感到無從下手，茫然不知所措，這讓我感到非常的難過。在學校總以為自己學的不錯，一旦接觸到實際才發現自己知道的是多么少，這時才真正領悟到“學無止境”的含義。通過實訓中心老師的課堂講解與企業化標準的培訓，使我加深了對自己專業的認識。從而確定自己以后的努力方向。要想在短暫的實訓時間內，盡可能多的學到東西，就需要我們跟老師或同學進行很好的溝通，加深彼此的了解。只有我們跟老師多溝通，讓老師更了解我們，才能跟真切的對我們進行培訓工作。由此，班級的文化“共享”就在生活中慢慢形成了。讓我們知道了團隊的力量。老師在實習周中所講的，都是課本上沒有而對我們又非常實用的東西，這又給我們的實訓增加了濃墨淡采的光輝。我懂得了實際生活中，專業知識是怎樣應用與實踐的。在這些過程中，我不僅知道了職業生涯所需具備的專業知識，而且讓我深深體會到一個團隊中各成員合作的重要性，要善于團隊合作，善于利用別人的智慧，這才是大智慧。靠單一的力量是很難完成一個大項目的，在進行團隊合作的時候，還要耐心聽取每個成員的意見，使我們的組合達到更加完美。

這次實訓帶給我太多的感觸，它讓我知道工作上的辛苦，事業途中的艱辛。讓我知道了實際的工作并不像在學校學習那樣輕松。軟件行業的工作人員工作不是一個人的事情，而是一個團隊的事情。軟件開發中有許多的問題如。

需求分析不充分.如果需求分析不清晰、不完整、太籠統或者不具有可測試性，那么軟件一定會出現問題。這就要求我們在動手開發之前一定要有完整的、詳細的、可維護的、可測試的需求分析，而且該需求分析一定要得到各方的認可。不切實際的計劃沒有充分考慮問題的復雜性，把一個龐大的工程限定在非常短的時間之內，出現問題是不可避免的。因此，我們應該拿出足夠多的時間作計劃、設計、測試、修改錯誤、回歸測試、整理文檔，不要把長時間熬夜作為軟件公司的家常便飯。不充分的測試在系統崩潰和用戶強烈抱怨之前，沒有人知道軟件是不是存在問題。因此要盡早地開展測試，問題修改之后要盡快地進行回歸測試，一定要給測試和修改問題留出足夠的時間。不斷增加新的特性在軟件開發完成之后，不斷有新的需求，這是最常見的問題。因此一定要最大限度地堅持最初的需求分析，如果萬不得已，確實需要增加新的需求，那么一定要更改相關的計劃。如果可能在設計階段最好使用快速原型法，讓用戶知道他們希望的系統是個什么樣子的，這樣可以在初期更好地聽從用戶的意見。交流不充分如果開發人員與開發人員之間、開發人員與項目管理組之間、項目組和用戶之間不能充分地交流的話，也會出現問題。因此，使用新聞組、電子郵件以及其他的網絡化的錯誤跟蹤工具等等方式來加強整個團隊的溝通和交流是必要的。

人非生而知之，雖然我現在的知識結構還很差，但是我知道要學的知識，一靠努力學習，二靠潛心實踐。沒有實踐，學習就是無源之水，無本之木。為了保證項目團隊按時保質地完成項目目標，便于項目團隊成員更好地了解項目情況，使項目工作開展的各個過程合理有序，因此以文件化的形式，把對于在項目生命周期內的工作任務范圍、各項工作的任務分解、項目團隊組織結構、各團隊成員的工作責任、團隊內外溝通協作方式、開發進度、經費預算、項目內外環境條件、風險對策等內容做出的安排以書面的方式，作為項目團隊成員以及項目干系人之間的共識與約定，項目生命周期內的所有項目活動的行動基礎，項目團隊開展和檢查項目工作的依據。

這次實訓讓我在一瞬間長大：我們不可能永遠呆在象牙塔中，過著一種無憂無慮的生活，我們總是要走上社會的，而社會，就是要靠我們這些年輕的一代來推動。這就是我們不遠千里來實訓的心得和感受，而不久后的我，面臨是就業壓力，還是繼續深造，我想我都應該好好經營自己的時間，充實、完善自我，不要讓自己的人生留下任何空白！

實訓中除了學到不少專業知識，也了解一些社會的現實性，包括人際交往，溝通方式及相關禮節方面的內容，對于團隊開發來說，團結一致使我深有體會。團隊的合作注重溝通和信任，不能不屑于做小事，永遠都要保持親和誠信，把專業理論運用到具體實踐中，不僅加深我對理論的掌握和運用，還讓我擁有了一次又一次難忘的開發經理，這是也是實訓最大的收獲。現在我對“一個人最大的財富是他的人生經歷和關系網絡”這句話非常的有感情，因為它確實幫了我們不少。除此課本上的知識畢竟有限。通過實訓，我班同學都有這樣一個感覺，課本上的理論知識與實際工作有很大差距，只有知識是遠遠不夠的，專業技能急需提高。從最初的笨手笨腳，到現在可以較熟練的按照流程開發軟件，這都與我班每個人的努力是分不開的。十幾天的實訓，教會了我們很多東西，同時也鍛煉了大家踏實、穩重的能力，每個人都很珍惜這來之不易的實訓機會。

在實際工作中經常會和不同的人打交道，然而他們的態度是不可恭維的，你會感覺到他的不耐煩以及他的高傲，所以這就需要學會溝通的方式及說話技巧，學會靈活面對。通過這十天的實訓，我班同學都收獲頗豐，總體來說對這次實訓還是很滿意的。盡管實訓很累，每天早出晚歸。但真的很感謝學校能夠提供我們這樣好的實訓機會，以及北京海輝集團雅思晟實訓中心給予我們的實訓平臺。我們深刻的了解到，只有經歷過，才知道其中的滋味。對于我而言，喜歡體驗生活，可以說通過這次實訓，真真切切的讓我了解了什么是軟件開發，什么是軟件工程，讓我對于軟件最初的觀點也有了本質性的改變！程序員不僅僅是一份職業，更是一份細心+一份耐心+一份責任心=人生價值的詮釋。即將走向工作崗位的我們更要不斷加強自己的專業技能，社會不會要一個一無是處的人，所以我們要更多更快的從一個學校人向社會人轉變。為此我們將會在以后的日子里繼續努力，不斷激勵經驗，不斷磨礪自己，早日走向工作崗位。

時間過的好快啊，為十二天的實訓生活即將結束了，短短的十二天讓我們收獲很大，專業知識、編程水平都有很大的提高。剛開始四天的高強度的課程安排讓我們受益匪淺；接下來的上機實訓又讓我們可以鞏固了課程。這讓我覺得實習生活充實而有意義。輔導老師配好了環境之后，我們開始了項目的制作，這次項目實訓算是自己小組間主要完成的項目。最后，自己的努力還是有收獲的，看著電腦上記錄得滿滿的代碼，看著自己的項目最終能夠運行成功，就覺得好神奇，很有成就感。

在本次的實訓中，除了讓我明白工作中需要能力，素質，知識之外，更重要的是學會了如何去完成一個任務，懂得了享受工作。當遇到問題，冷靜，想辦法一點一點的排除障礙，到最后獲取成功，一種自信心由然而生，這就是工作的樂趣。有時候也需要虛心請教，從別人的身上真得能學習到不自己沒有的東西，每一次的挫折只能使我更接近成功。除此以外，我還學會了如何更好地與別人溝通，如何更好地去陳述自己的觀點，如何說服別人認同自己的觀點。這次所學知識與實際的應用，理論與實際的相結合，讓我大開眼界。也是對以前所學知識的一個初審吧！這次實習對于我以后學習、找工作也真是受益菲淺，在短短的十多天中讓

我初步從理性回到感性的重新認識，也讓我初步的認識這個社會，對于以后做人所應把握的方向也有所啟發！相信這些寶貴的經驗會成為我今后成功的重要的基石。

在這次實訓中，我們以小組為單位開發項目。我們小組的項目是Super VCD一款簡單的音樂軟件。到目前為止，已經有很多種音樂軟件，大部分都是以復雜功能為主，實現復雜音樂的管理，但是有些用戶不需要那些功能繁瑣的軟件，只是需要一款能夠滿足用戶簡單的需求的音樂軟件。

我們所要做的是一款簡單的SuperVCD音樂軟件，能夠滿足用戶簡單的管理音樂需求，操作簡單。主要實現一些簡單音樂的管理。

根據了解，一些用戶對音樂軟件只有一些簡單的需求，主要有幾個方面，首先是對文件的管理，第二，是對專輯的詳細查詢。SuperVCD的實體有music.db,images文件，服務器，客戶端，用戶界面。服務器和music.db之間為一對一的關系，服務器可從music.db文件獲取音樂信息。images文件和服務器為多對一的關系，服務器可從images文件獲取圖片。服務器和客戶端是一對多的關系，一個服務器可開啟多個客戶端客戶端和用戶界面是一對一的關系，一個客戶端開啟一個用戶界面（不重復）。

我們按照老師的講解，分配了小組。在小組中我們選了組長。組長按照我們各自所擅長的分配了我們組員的任務，設置了一個虛擬貨幣，按照獎懲機制進行分發貨幣。在進行工作時我們相互配合，幫助。終于在我們努力和老師的指導下我們完成了老師布置的項目。老師為我們講解了軟件架構設計要達到的目標。

軟件架構設計要達到如下的目標：

可行性（Feasible）。架構具有可行性是架構設計的基石。

可靠性（Reliable）。軟件系統對于用戶的商業經營和管理來說極為重要，因此軟件系統必須非常可靠。

安全行（Secure）。軟件系統所承擔的交易的商業價值極高，系統的安全性非常重要。

可定制化（Customizable）。同樣的一套軟件，可以根據客戶群的不同和市場需求的變化進行調整。

可擴展性（Extensible）。在新技術出現的時候，一個軟件系統應當允許導入新技術，從而對現有系統進行功能和性能的擴展。

可維護性（Maintainable）。軟件系統的維護包括兩方面，一是排除現有的錯誤，二是將新的軟件需求反映到現有系統中去。一個易于維護的系統可以有效地降低技術支持的花費。可升級性（Scalable）。軟件必須能夠在用戶的使用率、用戶的數目增加很快的情況下，保持合理的性能。只有這樣，才能適應用戶的市場擴展得可能性。

客戶體驗（Customer Experience）。軟件系統必須易于使用。軟件的最終用戶很可能是不具有計算機專業技術的人員。

本部分設計主要涉及軟件系統的動態建模和系統類圖的詳細設計。軟件系統的動態模型分為交互模型和活動狀態模型，其中的交互模型主要由順序圖和協作圖構成，活動狀態模型主要包括活動圖和狀態圖。通過為軟件系統項目建立動態模型，從而產生體現系統動態行為的可視化分析結果，包括對象的時間特征和對象為完成目標任務而相互進行通信的機制、對象行為的改變和狀態變化情況，以及對象可能出現的各種活動狀態等信息。

“千里之行，始于足下”，這十幾天短暫而又充實的實習中，我認為對我走向社會起到了一個橋梁的作用，過渡的作用，是人生的一段重要的經歷，也是一個重要步驟，對將來走上工作崗位也有著很大幫助。向他人虛心求教，遵守組織紀律和單位規章制度，與人文明交往等一些做人處世的基本原則都要在實際生活中認真的貫徹，好的習慣也要在實際生活中不斷培養。

這次實習也讓我深刻了解到，在工作中和同事保持良好的關系是很重要的。做事首先要學做

人，要明白做人的道理，如何與人相處是現代社會的做人的一個最基本的問題。對于自己這樣一個即將步入社會的人來說，需要學習的東西很多，他們就是最好的老師，正所謂“三人行，必有我師”，我們可以向他們學習很多知識、道理。

通過實習能夠加強和鞏固理論知識，能夠在實踐中培養自己發現問題并運用所學知識分析問題和解決問題的能力，從而使我們在學校所學的知識能夠應用到實踐當中去。鍛煉自己的實習工作能力，適應社會能力和自我管理的能力，提前感受工作的感覺，為以后的就業打下一定的基礎。了解計算機軟件技術在應用情況、需求情況和發展方向及前景。在實習單位學到一些自己在學校難以學到的知識，為畢業設計的順利完成添磚加瓦。

回顧我的實習生活，感觸是很深的，收獲是豐碩的。通過實習，不僅培養了我的實際動手能力，也增加了我的實際操作經驗，對軟件項目管理專業所對應的工作也有了新的認識。實習讓我學到了很多在課堂上學不到的知識，也讓我更加看清自己的不足之處。通過這次實習，使我對今后的學習、發展方向有了更進一步的認識：學習不僅僅學的是理論知識，更重要的是學習如何將理論知識應用于實踐，學習將工作做到盡善盡美。

第三篇：軟件項目管理

軟件項目經理所需的素質

許多人都以為項目經理總是與“理想與光榮”相伴的，其實作為一個有志于改進中國軟件開發流程的項目經理來說，他們承擔的更多的是“艱辛與痛苦”。

一個優秀的軟件項目經理應該具備以下素質。

一、執著

可以這么說，在中國如果不執著是做不成任何事情的，因為在軟件開發流程中推行各種規范和管理制度的時候，你可能遇到各種各樣的阻力和障礙，如果沒有應付挫折的思想和準備，你是很難推行成功的。要知道這樣一個基本事實，項目管理成敗的關鍵是：如果你不堅持，誰也不會堅持下去的。指望領導的扶持和群眾的自覺是不可能的。只有堅定信念，努力打動別人，才能成功。

堅持到成功為止。只要決定上管理流程了，就不要后悔，唯有堅持，因為你拼命努力而實現了99%，你卻不知，最后當你決定放棄的時候也許就是你要成功之時。要知道你準備放棄的時候可能正是對方也準備放棄之時，唯有堅持，你才能成功

二、親和力

親和力是指你和團隊相互依賴，相互信任能力的大小。親和力是你領導團隊走向成功的基礎，如果一個團隊的向心力不夠，各自為政，那么失敗就會在身邊陪伴你。要團隊的每個成員都信任你，你必須要做到關心下屬，主動與下屬溝通，為下屬爭取合法權利等。關心下屬就是在日常工作中對下屬的工作狀況，發展方向進行指導，避免其走彎路；在生活中也對其身體狀況進行關心，促進身體和心理健康的恢復。

多找下屬溝通是消除誤會的潤滑劑，同時也是了解下屬內心真實想法唯一捷徑。做項目經理的人，在某些事情上的處理的確會與人不同，也難以令人理解。這個時候只有多與下屬溝通，逐步達成共識，爭取大家的理解和支持。記住，沒有下屬的理解和支持，你永遠無法實現項目管理的規范化。另外就是了解下屬的真實想法，經常了解一下下屬的真實想法有利于我們不斷改進和調整流程，使生產流程更加符合本團隊的實際。切記一點，做領導的一定要多尊重下屬的想法，并且與之溝通，若一味等下屬找自己，那么是一般下屬與之水火不容要攤牌時，才會與你溝通，這樣悔之晚矣。

為下屬爭取合法權利是項目經理的一項重要職責。敢負責任是項目經理基本素質，如果你不經常研究工作數據保障下屬的合法權益時，你就很難讓你的團隊保持高效率。

三、品德高尚

“一撇一捺是個人，世世代代學做人。”在這個世界上最難做的就是做個品德高尚的人。試想一個思想猥褻的人很難取得成功，即使靠鉆營取得也只是暫時的，他不可能取得長久的成功。只有品德高尚的人才能感染周圍的人，使團隊具有向心力，從成功走向成功。

人有三種，一種是仗勢欺人，一種是持才壓人，最后一種是以德服人。仗勢欺人的人自持地位高而指三道四，自然是不可能團結人，更不可能獲得成功；持才壓人的人自持學識高而盛氣凌人，或咄咄逼人。殊不知“聞到有先后，術業有專攻”，“尺有所長，寸有所短”，難以學到更高的知識，也就難以取得更大的成功。只有以德服人的人以自己的修養和品德感染人，勇于吃虧，樂于助人，以德報怨，只有這樣才能使你對立面德人都不忍心傷害你，團結到一切可以團結到的人，擁有這樣的環境，你怎么可能不成功。

勇于吃虧，首先要放下私心，如果一個人始終 圍著自己轉的人是不可能做到的。“人不為己，天誅地滅”是八十年代后出生的人心靈普遍反應；但是要記住人首先是社會中的人，如果脫離了社會，人恐怕已不會成其為人了。因此只有當你拋棄私心，主動為人，別人才會反過來支持你，幫助你。

樂于助人，是人類的一個良好品質，就象一首歌中所唱的“人字的結構就是相互支撐”。管理流程是不可能靠項目經理一個人維持的，必須要大家支持你。但是這卻需要你多幫助別人，別人才會幫助你。不管團隊成員發生什么事情，你要盡你所能去幫助他，這樣團隊才可能繼續前進。

以德報怨，可能是人最難做到的。中國人就強調“人若犯我，我必犯人”，其實在這回中不會有真正的仇敵，大家明爭暗斗的結果如果過20年后再去看的時候，保準一大半的人都會覺得不值得，許多人賭得就是一口氣，將自己成功的希望給湮滅了。當你能用寬容喝善良對待你對立面的人的時候，還有什么東西能阻擋你成功？

“得道多助，失道寡助；多助之至，天下順之，失道之至，親戚叛之；以天下之所順，攻親戚之所叛；故君子有不戰，戰必勝矣。”

四、口才

良好的口才是項目經理打動項目成員的必備武器，當你擁有良好的口才將會使你無往不利。當年希特勒就是用他那天才般的口才征服了德國，使他的《我的奮斗》貫徹到每一個德國人的心中，從而成立了第三帝國。

要使自己的項目管理思想貫徹到每一個項目成員心中，就必須要做到以下的演講原則：

1.根據項目成員的共同目標象他們制定演講內容，只有讓他們信服你才有意義；

2.調動聽眾的這種感官，訴之觸覺、視覺、聽覺，用黑板、姿勢來輔助你的內容。

3.不斷的總結效果，改進自己演講宣傳的接受度，如果效果不理想，嘗試換一個方式來表達.調動聽眾的這種感官，訴之觸覺、視覺、聽覺，用黑板、姿勢來輔助你的內容。

3.不斷的總結效果，改進自己演講宣傳的接受度，如果效果不理想，嘗試換一個方式來表達和描述。

4.讓聽眾學以至用，只有他們積極反饋，才能更深入的聽你的思想。

五、循序漸進

循序漸進，不急于求成是項目經理在項目管理中必需具備的品質，在中國CMM過程改進的熱潮中，真正實現CMM管理的企業屈指可數，而以CMM改進過程實質性為企業帶來質量提升和效益改進的公司更是寥落晨星。

為什么會出現這種情況？難道CMM真的不適應中國過情嗎？不是，絕對不是。是這些企業的項目經理太心急，連CMM2還不知道怎么回事就直奔CMM3，他們忽視了事務發展的客觀規律，凡事必須循序漸進。如果有一個企業在2年內通過了CMM4，我有十足的信心說，那是花錢買征；如果樂觀一點，一個中小企業從CMM1走到CMM2大約要2年時間，大型企業只會更長，不會更短，因為他們需要在培訓和溝通上付出更大的代價。

“循序漸進，循序漸進，再循序漸進。”這句巴斯德德經典名言同樣適用于我們項目管理領域，他將逐步把我們帶向成功。

六、持久求學

“書到用時方恨少，學至成時始知卑。”學無止境，我在生產實踐中發現，整個項目管理過程改進就是“學習-培訓-實施-發現問題-再學習”的循環過程，項目經理如果不學習將不能解決現實工作中出現的新問題，更不可能站在一個戰略的角度來解決問題。

事實上，求學也不能沒有目標，否則學到的知識太龐雜，而不能融會貫通，這樣的知識對實際工作指導甚少，真正的知識是一個目標體系，嚴格按照流程來一步步的掌握我們所需要的知識。

最后，我總結一下中國項目經理所必需掌握的知識：

1.專業知識：數據結構、關系數據庫、操作系統、軟件工程、編譯原理。（外國的項目經理可能不需要掌握）

2.管理知識：項目計劃、項目配置管理、成本核算、風險預估、績效考核。這是項目經理必須掌握的內容。

3.網絡知識：服務器的架構、各種服務的配置。因為管理的大廈是基于軟件的管理，沒有一個服務管理的網絡配合是不可以想象的。

4.“越過高峰，另一峰卻又現”，這是中國項目經理在持續求學中會不停的挑戰自我，向更高的山峰邁進。

七、敢負責任

一個人因為有責任才有生存的意義。一個人隨著年齡的增長，責任感也會愈來愈重。成年時，法律也會賦予一些年少時沒有的責任。同時地位逐漸提高，責任也會相對加重。

一個人惟有負責，才能產生做人的價值。所負責任愈大，價值就愈高。換句話說，有責任，生命才有意義。如果沒有感受到自己該負的責任，即使年齡超過20歲，也不算是一個成年人。

因此，經理就是要負責任，如果不負責任就可以不要經理了！項目經理關系到一個項目的成敗；對于公司他必須要承擔及時匯報項目進度、成本核算和質量系數的責任，同時也必須保證項目組成員績效考核，政策落實，預留人才儲備等責任，是整個項目中責任最大的人，如果沒有良好的心理素質和應對能力是無法擔負責任的。

實際工作中項目經理主要要負責項目組的人員安排調度、工作分配、工作審核、工作跟蹤、項目計劃、項目匯報總結、成本核算、利潤分配等職責。

八、以身作則

項目管理的一個重要工作就是定義各種規范和制定，但是這些規范和制度的執行除了靠項目經理的執著推行，口才宣傳，力主培訓、懲戒得當之外，關鍵還是在于項目經理的以身作則。如果項目經理自己都違反自己定義的條款的話，那么就別指望團隊會自覺遵守這些規定。

作為一個管理者以身作則是最基本的素質，千萬不要為自己違反規范和制度找各種借口，例如我我是公司只屬考核，我因為某某更重要的事情而不得不違反。“只許周宮放火，不許百姓點燈”的話，是無法將規范和制度推入人心的。項目經理如果違反了規范，只有當眾加重處罰，別無他法。

因此，鑒于規范制度的權威性主要還是靠項目經理自己，只有堅持以身作則，才能將自己優秀的管理思想貫穿下去，取得開發過程改進的成功。

九、要有威信

一個項目經理說話有沒有人聽，必須要靠威信，這種威信是靠自身的素質，而不是狐假虎威。靠高層領導的支持來強迫團隊執行項目制度過程的話，是注定會失敗的。因為團隊成員不信任你，表面服從，實際消極怠工，就足以讓流程實質癱瘓。

做事要有信用，說一不二，不能因為朋友關心就講情面。公是公，私是私。平時可以稀稀拉拉，關鍵問題決不手軟，不因為朋友關系妥協，這樣才能樹立威信，便于工作。

威信除了必要的威信之外，最主要的還是信用，項目經理在做事沒有絕對把握的時候千萬不要承諾，一旦承諾就無論如何一定要實現。否則，當實現不成功而丟失信用之后，再想讓團隊相信你，信任你就是非常困難的事情了。

十、善于總結

項目經理要善于總結，只有不斷的總結才能不停的完善自己，成功的事情總結經驗，失敗的事情要總結教訓，總結的過程就是不斷改進的過程，這也是CMM規范所必需的素質。

總結

總結的過程要多吸取別人的意見，不要武斷自己的結論。博人所長，綜合起來才算趨于完美。這個原因有二：其一，項目經理不是孤立的一個人，而是必須融于團隊之中，一個流程合不合理，不是由項目經理說了算，而是要由團隊的成員說了算，注意傾聽團隊成員的真實感受，不斷改進流程才能成功。中國的許多CMM改進失敗，并不是項目經理知識能力不夠，而是他們沒有一起與團隊總結，經多年經驗，我們發現大多數規范，必須要有一套合理的軟件支持才能成功，否則無論你的理想多先進，想靠程序員工作來提高過程質量的改進是不現實的。其二，“聞道有先后，術業有專攻”，項目經理不可能是全才，什么都懂。因此要和哪些與專攻方向不同的人一起總結。比如項目經理可能精通軟件開發流程的改進，但是卻不知道測試流程、網絡管理流程、品質保證流程的改進，而這些流程又直接作用于軟件開發流程。這個時候必須與測試人員、網管人員、質量保證人員共同探討，找出一條切實可行的改進方案。

第四篇：軟件項目管理案例分析20題

軟件項目管理案例分析

案例分析一

問題1：

本項目申請國家技術創新基金100萬元，但國家實際批準基金額度很可能會低于100萬元，“項目投資來源”中應當說明：當國家實際批準基金低于申請額度時，如何補足二者之間的差額以及由此所引起的地方匹配基金的差額。

應重新召開股東大會并討論以下議題：當國家實際批準基金低于申請額度時，公司是否愿意補足二者之間的差額以及由此引起的地方匹配基金的差額。

如果能夠通過，應在“項目投資來源”中加注：當國家實際批準基金低于申請額度時，公司承諾補足二者之間的差額以及由此引起的地方匹配基金的差額（附新的公司股東大會決議）。問題2：

A，B雙方以B方現有技術成果為基礎進一步合作開發，應明確以下幾個主要問題：（1）B方是以現有技術成果折價入股，還是將現有技術成果轉讓給A方；（2）如果是“技術轉讓”，應明確是“專利權轉讓”、“專利實施許可”、還是“技術秘密轉讓”？

（3）雙方是否已就合作開發的新技術成果的所有權、使用權以及利益分成問題達成一致意見？

雙方是否已正式簽訂“合作開發合同”或“技術轉讓合同”？ 問題3：

應主要從以下幾方面分析項目技術的成熟性：

（1）關鍵技術成熟性分析（包括采用的現有成熟關鍵技術、已攻克的關鍵技術、待研究的關鍵技術等）；

（2）項目采用的關鍵技術是否獲得國家、部門或地方科技計劃的支持（已獲得、尚未獲得）及計劃的名稱、獲得支持的時間；

（3）項目采用的關鍵技術是否通過技術鑒定（已鑒定、尚未鑒定）及鑒定單位、鑒定意見、鑒定時間。

案例分析二

問題1：

由項目執行偏差導致項目計劃變更的各種誘發因素稱為項目變更的內部因素。由項目目標變化導致項目計劃變更的各種誘發因素稱為項目變更的外部因素。問題2：

“B方首付資金未能按時交付”、“A方盲目確定進度目標”、“A方的前期設計有疏漏”、“A方編制的需求分析說明書未能準確、全面地表達B方的實際需求”、“B方自行負責的機房裝修誤期”、“A方開發人員跳槽”，屬于項目變更的內部因素。

“證監會要求上市公司執行新的會計制度”、“B方因機構重組改變了業務流程”、“B方提出增加合同審計功能”、“B方行業主管部門發布了新的行業ERP實施規范”，屬于變更的外部因素。問題3：

“A方盲目確定進度目標”、“A方的前期設計有疏漏”、“A方開發人員跳槽”，屬于A方責任。由此而增加的項目經費，由A方承擔。“需求分析時，B方表達不清，A方理解有誤，雙方溝通不夠，A方編制的需求分析說明了書未能準確、全面地表達B方的實際需求，而B方未能及時指正”，屬于雙方責任，由此而增加的項目經費，由A、B雙方協商分攤。

其余各條，無論B方是否負有責任，均應承擔由此而增加的項目經費。問題4：

對于由內部因素引起的變更請求，變更評估的重點是確定最優變更方案。而對于外部因素引起的變更請求，變更控制委員會應重點評估變更的必要性。

案例分析三

問題1：

（1）沒有清晰地了解到產品的范圍，導致項目后期需求的蔓延；

（2）沒有澄清模糊的項目范圍，在安裝服務器的問題上產生異議，最終增加了未計劃到的工作；

（3）沒有進行變更控制，以至于變更的結果不理想，導致反復地變更。問題2：

（1）變更工作沒有得到確認，導致工作的結果不能夠被認可；

（2）變更沒有得到有效地執行。尤其當同時發生多個變更的時候，如果沒有有效的控制很容易造成一些變更被忽略甚至遺漏；

（3）未控制的變更造成系統的混亂。軟件系統是一個復雜的系統，系統間很多部件都存在關聯，對其中某一部分進行更改可能會牽連到其他部分，造成整個系統的問題。

問題3：

范圍控制是范圍管理中重要的工作之一，范圍控制的主要目的是控制變更的結果；保證所有被請求的變更都可以得到有效的處理；協調所有同變更相關的工作、資源和交付成果，讓項目始終處在被控制的狀態。范圍控制的意義也在于此，通過范圍控制，可以減少范圍變更對項目造成的影響，降低風險，讓項目處在可控制可跟蹤的狀態。

案例分析四

問題1：

分解項目WBS的一般過程如下：（1）識別可交付成果及有關工作；（2）確定工作分解結構的結構與編排；

（3）將工作分解結構的上層分解到下層的組成部分；（4）為工作分解結構組成部分提出并分配標識編碼；（5）核實工作分解的程度是否必要且足夠。問題2：

創建項目WBS時需要注意以下四點：（1）分解出的工作是充分且必要的；

（2）工作的獨立性。即工作一旦開始，就可以在不中斷的條件下完成；

（3）工作完成度的可判斷性。即可以清楚地判斷工作是否已經開始，工作完成了多少，以及工作是否已完成。

（4）工作的交付成果。即工作完成后將得到什么樣的成果。問題3：

（1）在“同K企業負責人溝通后明確項目的范圍”中，小張進行了范圍定義的工作。之后小張又編寫《關于***系統第三方系統測評計劃備忘錄》的文檔，并發給企業K 負責人確認，讓項目范圍在各干系人中得到一致的認識。

（2）在“將配合第三方機構進行測評的工作加入到項目WBS”中，小張進行了范圍控制的工作。

案例分析五 案例分析六

案例分析七

問題1：

公司負責人不應該把單純的參數模型放在成本估計上，而要根據不同的情況，采用不同的方法，否則會使成本估計產生很大的偏差。

在做成本估計時建立參數模型只是其中一種方法。建立參數模型指在數學模型中運用項目特點（參數）來預測項目成本。建立參數模型的首要條件是建模所參考的歷史數據的精確性程度。

但是實際情況是該項目由于需要改動的那個過程中有很多工作不是很清晰，而且這過程還會對其他5個過程產生一些影響，影響的程度也沒有得到明確的界定。更重要的是，改動的流程過程占整個制造成本的36%,因此完全按照參數模型是不合適的。問題2：

由于王工程師能夠準確地獲得其他5個沒有改動過程的詳細成本信息，因此工程師在對已經明了的項目的5個過程應該采用建立參數模型法來對其進行成本估計。

而對那個需要改動的過程應該采用類比估算法，這是由于當對項目的詳細情況了解甚少時（例如在項目的初期階段），往往采用這種方法估算項目的總成本。問題3：

成本控制就是要保證各項工作要在它們各自的預算范圍內進行。成本控制的基本方法是規定各部門定期上報其成本報告，再由控制部門對其進行成本審核，以保證各種支出的合法性，然后再將已經發生的成本與預算相比較，分析其是否超支，并采取相應的措施加以彌補。有效的成本控制的關鍵是經常及時分析成本績效，盡早發現成本偏差和成本執行效率，這樣就能在情況變壞之前及時有效地采取措施。

成本控制包括查找正、負偏差的原因，它必須與其他控制過程緊密地結合起來。成本控制實質上就是監控成本的正負偏差，分析偏差產生的原因，及時采取措施以確保項目朝著有利的方向發展。主要方法有成本變更控制系統、績效衡量分析、項目績效審核、電腦化工具、偏差管理等。

案例分析八

案例分析九

問題1：

不明確需求就進行開發，造成項目開發無法制定相應的計劃。缺乏合理的項目開發計劃，就無法保證項目的質量。

如果由于某種客觀原因造成無法在軟件項目開發之前明確這個需求，需要對這個軟件項目進行階段劃分，在每個階段中明確部分需求，并制定相應的開發計劃。問題2：

該公司的張工應該盡可能早地明確整個軟件項目的需求，制定相應的計劃。

張工可以把整個項目的開發階段進行劃分，對每個階段的需求進行分析，制定計劃，執行計劃。

B銀行的趙工應該盡可能早地提出需求。

趙工在需求確定后如果需要變更請求，則要和張工一起協商，然后才能調整需求，并且對項目開發計劃也進行相應的調整。趙工應該和張工一起分析，明確每個項目開發階段的需求。問題3：

在項目的需求分析階段，項目負責人和需求提出者需要仔細研究整個項目的相關業務邏輯，了解整個項目的需求。在需求得到明確的前提下，制定相應的開發計劃。

在項目的實施階段，需要對每個階段的需求進行明確，制定相應的開發計劃。保證了每一個階段的開發質量，就能夠保證整個項目的質量。

案例分析十

問題1：

該軟件公司在明知原有系系統統已經投入使用的情況下，沒有提前分析升級的風險并告知客戶，此證券公司沒有制定升級計劃，沒有和客戶一起制定風險預案。

該證券公司在得知此軟件公司要對他們正在使用的系統進行升級的情況下，沒有主動向該軟件公司了解升級可能引發的問題，沒有制定必要的風險預案，以致出現問題時無法采取合理的補救措施，造成了一些損失。問題2：

現有系統由于一般已經投入使用，如果對其進行升級會有一定的風險。在進行升級以前，應該對其可能包含的風險和可能帶來的問題進行仔細分析和評估，并有針對性地制定風險預案和升級計劃。在升級失敗或者出現問題影響系統使用的情況下，應該實施風險預案來保證系統的正常使用，盡可能地減少損失。問題3：

軟件系統的升級和開發一樣，也要制定相應的開發計劃和質量保證計劃。如果缺少必要的計劃和質量保證措施，也會導致很大的問題。軟件系統升級如果出現質量問題，帶來的損失可能比開發過程中出現問題更嚴重。因為如果一個正在使用的系統出現問題或無法正常使用，可能帶來一定的經濟損失。因此我們必須像軟件開發一樣采取必要的質量保證手段來避免或盡可能地減少經濟損失。針對升級可能出現的風險，為了保險起見，需要制定一套或多套見險預案，并且進行預演，一般在出現問題時順利采取風險預案來盡可能減少或避免產生經濟損失。

案例分析十一

問題1：

由于人力資源計劃不合理或者客戶在開發過程中的一些突發原因造成人力資源計劃不足以應付項目的正常進行，項目管理人員則需要考慮增加人力資源。在組織內部因為人員緊張已經不能提供合適的開發人員，同時公司管理層不打算增加人員經費，項目組經過研究決定招聘一批實習生，這算是一個比較正常的解決問題的思路，但是由于是組織外的人員，所以會增加管理難度。同時由于在項目中期引入新的開發人員，也引入了新的風險：新的開發人員可能不能及時完成作為先決條件的任務（如培訓及其他項目）；新的開發人員和項目管理層之間關系不佳，導致決策緩慢，影響全局；由于在工資待遇方面和正式員工有較大差距，且缺乏激勵措施，士氣低下，降低了生產率；新的開發人員中某些人員需要更多的時間適應還不熟悉的軟件工具和環境；因為是在項目中后期加入新的開發人員，需進行培訓并逐漸與現有成員溝通，從而使現有成員的工作效率降低；由于項目成員之間發生沖突，導致溝通不暢、設計欠佳、接口出現錯誤和額外的重復工作；不適應工作的成員沒有調離項目組，影響了項目組其他成員的積極性；也許在所有新開發人員中沒有找到項目急需的具有特定技能的人，等等。以上這些因素都可能對項目進度造成很壞的影響，有較大的隱患，項目管理人員必須有效控制由此帶來的人員風險。問題2：

關于如何教育和引導剛加入公司的新雇員這個問題，隨著公司產品的多樣性和復雜性變得越來越棘手，而且新加入公司人員可能分別從事不同的工作，如程序員，程序經理，客戶支持工程師，針對不同的角色應該制定不同的方案。

越來越多的公司都試圖聘用能自學業務的人員，而不愿在培訓項目、正規條例和流程或詳細的產品記錄上的投資。還可以通過熟練員工來教育新新雇員，這些熟練員工有經長、某些領域的專家以及正式指定的指導教師，他們除了本職工作外還要擔負起教導新雇員的工作。這種方法使得大家覺得有權學習并自己決定學什么和不學什么，使得他們在公司里的作用靈活機動。例如對于程序經理的培訓：剛開始時，新雇員的任務可能是一個單獨的特性，并且在直到完成為止的這段時間內，都會有人對你進行密切地指導。隨后，當這種工作已做得相當熟練之后，便會在更大的特性組中從事類似的工作，但指導會少得多。一段時期后，受訓者會擁有一個小項目或一個大項目的一部分。同時，程序經理還可以受到一些正規的培訓，包括一個供選修的培訓項目。另外，還可以不定期舉行經驗推介會，屆時會有經驗豐富的程序經理介紹他們自已的經驗。假設你是一個新進入公司的開發員，那么在頭幾天里，你會與經理們以及來自其他專業部門的高級人員會面，你會聽到有關開發周期的一個方向性的簡介，然后開發經理會立即派給你一個單獨的任務或者讓你與特性小組一起工作，你還可能被介紹給愿意當指導教師的高級開發員。

一般而言，你開始會從事相對容易的特性編碼工作，這種工作需要的時間較少并且與其它特性關聯甚少，并且高級人員（特性組長、領域專家、指導教師）隨即非常仔細地檢查你編寫的代碼。此外對開發領域人員應該有更加正規的定向的培訓。例如，為新開發人員提供了幾個為時幾天的實習班，培訓他們處理開發過程、產品、工具和其它專題。此外對于客戶支持工程師的培訓也是十分重要的。這主要是因為顧客不僅僅是購買產品，他們還要享受到優質的售后服務。所以，訓練有素的客戶支持工程師對于保持公司良好形象和提高為顧客服務的能力是至關重要的。客戶支持工程師不必像開發員那樣有必備的職業教育，但他們必須關于本公司產品如何工作的知識，并且實際上要在某種產品上具有專業知識。新的客戶支持工程師在上崗之前，接受一段時間的專門培訓。培訓從基本的軟件產品開始，同時他們還接受交際技巧，包括如何與顧客打交道等方面的一般性訓練。作為定向培訓的一部分，他們還接電話，與導師一道工作（每位技術員有一位導師）。在他們被分配處理客戶的電話之前負責答復客戶來信。問題3：

對日軟件外包相對技術難度不高，但是質量要求相當苛刻，外包項目失敗的例子不少。以下就對日軟件外包常見的一些問題進行簡單探討。（1）日方SE認為理所當然的地方，很多細節不會在式樣書中明確寫出，或者說日方SE完全按照日本做設計的習慣寫式樣書，由于中日文化和思維習慣的差異，可能導致中國軟件開發人員對這些習慣問題理解有誤。

對策：積累經驗，參照同類系統，提QA表確認。

（2）在產品提交期間，對于某些BUG，可能會出現這樣的爭執：中方開發人員說是由于日方的式樣書沒有寫明確，式樣書不夠細致，日方設計人員說是中方理解式樣書不對，有些地方不寫也應該能自己理解。

對策：首先確保產品質量的交貨時間；加強雙方交流；加強測試。（3）有的項目是日方邊設計，需要中方同步開發，中方開發人員認為式樣書上寫多少就做多少沒有寫的就不做。

對策：加強項目的交流，主動提出設計思考讓日方人員確認是不是這樣的意思。（4）中方開發人員的日語熟練程度不夠。

對策：加強IT日語教育，開發人員至少達到能理解日語式樣書的水平；配置專業的日語翻譯輔助。

（5）對于一些中方開發人員在太在意的一些細節問題，例如：字體，顏色、對齊方式等，要求不夠嚴謹。

對策：強化質量意識，建立開發和測試規范。

（6）開發過程的規范性與開發人員的態度：日本企業的開發管理，講究中規中矩，非常重視文檔的規范化管理，力求做到“凡事必求有據”；而中國企業在文檔的規范化管理方面相對淡薄；日本企業項目管理對涉及的過程和文檔，規定了極其嚴格的次序和樣式，要求開發人員嚴格執行。而中國企業在具體執行方面，開發人員往往對這些規范和要求的遵照不夠嚴謹。

對策：完全按照客戶要求執行，包括文檔，如：開發進度報告、測試用例、測試報告等；加強開發過程管理，規范開發過程，引入CMM模式；加強軟件質量保證，如代碼評審、文檔審核、測試。

（7）中國企業的開發人員比較喜歡技術創新，在開發過程中對于一些技術問題提出自己的技術方案，可能會導致部分模塊技術實現方式與整體要求有差異。

對策：完全尊重日本客戶的文化和管理模式，積極提出技術建議；對于有要求遵照Sample代碼或對具體技術實現細節有嚴格要求的，開發人員必須嚴格遵循，不允許采用自已的技術實現；加強代碼審查（code review）。

（8）一些日本企業與中國企業的SE共同參與設計或交流的項目。

對策：在日本的合作伙伴企業派遣SE到項目現場進行設計；派遣中國SE到日本參與設計，設計完成后帶回中國開發；日本企業短期派遣SE到中國。（9）軟件外包知識產權保護與客戶保密問題。

對策：嚴格保護日本客戶商業秘密和知識產權；中國企業與日本企業簽訂保密協議；中國企業與開發人員簽訂保密協議。

（10）日本企業對中國企業開發進度的掌握。

對策：按照日本企業項目管理要求報告項目進度；分階段交付。（11）遠程協同合作開發的交流手段和方式。

對策：實時消息/語音/視頻交流，例如：MSN Messenger, Yahoo Mesenger、視頻會議系統、遠程控制、遠程協助、遠程調試；Email、FTP；相互人才派遣，人才交流。

案例分析十二

問題1：

在一個軟件產品整個的生命周期中，軟件產品發布之后便進入漫長的軟件維護階段，而對于一些行業軟件更是如此，后期的軟件維護是非常重要的一個環節。在維護過程中通常要涉及到開發人員在現場對代碼的維護，對數據和設備的維護，還可能需要根據用戶要求對軟件做相應的修改，有些可能涉及到重新開發或者發布新版本。當然后期維護也可能在一段時間內將會帶來相當豐厚的收入，保持良好的客戶滿意度也將變得非常重要。現場開發人員不僅僅是完成維護工作，而且更多的是需要通過和用戶溝通了解用戶在使用軟件過程中遇到的一些問題，幫助用戶正確認識軟件維護的目的，得到用戶的支持和協助，使軟件最大程度地幫助用戶提高其工作效率，創造經濟價值，在用戶中建立起良好的口碑。同時現場人員也應該積極收集和整理用戶提出的一些問題，善于總結和思考，將這些問題反饋給公司總部，將一些用戶期望的功能發布在下一個版本當中，并且完善舊有版本中的缺陷。從這個角色出發，現場人員在一定程度上扮演了市場人員的角色，并且是接觸最前線的用戶，他們在做維護的同時，可以體會到用戶使用軟件的感受，從而得到最準確的市場信息，同時現場開發人員又是公司形象代表，每次現場工作都代表著公司的形象，所以公司需要設置專門的培訓內容用于訓練員工在外如何保持公司的良好形象同時做好宣傳工作。問題2：

在軟件開發過程中，團隊協同開發，很容易出現軟件版本管理不善帶來的軟件系統故障。代碼經常會被新的版本替換而使某些開發人員的工作成果丟失。這樣不僅會打擊開發人員的工作熱情，也不利于責任的明確。在現場開發的過程中，由于缺乏監督和管理，這種情況會更加普遍，如項目現場為應急而擅自更改軟件代碼，而常常沒有將更改納入統一的版本管理，甚至只是開發人員的個人意見，并沒有通過項目管理層的同意，這種處理方法就很容易造成總部發行新版本軟件時，替換軟件而丟失了現場所進行更新的代碼，從而造成系統故障的反復出現。此外，由于現場維護一般都會涉及到大量用戶數據，程序的修改不僅會影響到軟件功能，更可能產生很多垃圾數據，這些都是用戶所不希望看到的，所以對現場代碼的更改要嚴格控制，并且及時和總部版本保持一致，如微軟公司出品的版本管理工具VSS就能夠做到WEB訪問，通過有效配置能夠有效控制現場版本。

案例分析十三

問題1：

作為為項目經理面對項目問題應從更深層次上思考，要遵循項目管理原理，而不是浮于事務本身。項目經理張強在項目開始時就應制定詳細的項目管理計劃，應先考慮好可能要進行的項目溝通并加以執行，而不是在出現問題時才去彌補。溝通不完整的項目過程，大多數會顧此失彼，進一步導致項目問題的發生。一言納之，張強的問題關鍵是沒有計劃，如果按軟件過程能力成熟度模型CMM評價，該項目組織只能是初始級。

造成項目問題的原因有以下幾點：

（1）溝通管理計劃沒有或不夠詳細；（2）沒有重視部門間橫向溝通；

（3）與客戶溝通不到位，客戶需求未能準確把握。問題2：

要實施高效的會議，首先是在會議前要有計劃，通常會議計劃來源于項目溝通管理計劃，準備階段通常按如下順序實施：

（1）決定會議的宗旨和類型；

（2）分析會議的因果：本次會議同本部門目標的關系？本次會議同上、下次會議的關系？什么事可能會影響對本次會議的興趣？

（3）明確涉及的、受影響的人和事；（4）制定會議成果說明；（5）決定要討論的主題；（6）決定會議角色分配；（7）決定會場布置；

（8）計劃會議議程表：非正式議程表、正式議程表（5W和1H）。

在會議過程中，有效地主持或參與會議則要注意按會議步驟逐項討論議程，總結決定。在會議中應鼓勵與會者積極參與，制止消極行為和不良意見。陳述信息要自信，態度要直接、坦率。對整個會議要注意掌握時間，記錄重要備忘事項和決定。

會議跟蹤也是一項重要工作。應自上而下逐級向必要的非與會者傳達會議信息,制定行動計劃完成分派的工作,確定計劃以跟蹤會上決定的工作進度。制定下次會議議程。問題3：

項目經理應明確自已的工作職責范圍，對項目相關資源的安排在制定溝通管理計劃時應有詳細的描述。對項目進度、項目成果應及時與公司高層領導或干系人溝通。項目組織應建有基于Internet的軟件開發交流平臺，從而能調度、跟蹤解決項目現場問題。

項目經理和項目人員應通過各種方式與客戶多作交流，如QQ，MSN、電話、電子郵件等。合適的組合是項目團隊中至少一人是客戶方的代表，項目初始時團隊成員應與客戶方的軟件使用人員經常地進行業務方面的交流。案例分析十四

問題1：

項目經理劉克勤的項目溝通管理是成功的。對于項目管理，除了掌握必備的項目基本方法和管理工具（如計劃制定、預算編制等），對項目背景和目標有清楚的理解和認識外，最重要的一點就是與人交往的技巧。成功項目經理和失敗項目經理的最大差別，可能就在于如何跟人打交道，如何跟客戶打交道，如何跟公司領導打交道，如何跟項目成員打交道。問題2：

項目經理劉克勤在項目過程中，團隊建設相當成功。他為團隊成員間建立紐帶，并通過各種行為加強信任和消除團隊合作的障礙。其中最值的借鑒是尊重團隊成員、采用多種方法溝通、進行深度對話。

案例分析十五

問題1：

我們都知道，信息應用系統的變更尤其頻繁，而頻繁的變更必然影響到信息工程項目的三大目標。通常與客戶接觸最多的是市場部項目經理，引導客戶需求對項目經理就非常關鍵，項目經理引導得好，項目的開發就會非常順利，反之，就會使項目組疲于奔命。

該項目中，市場部李工不斷地提出新的需求時，張工“來者不拒”、疲于奔命、不停地更新項目計劃，導致項目范圍無法確定，工期和成本不可控制，團隊成員工作目的也不明確。

風險應對策略一般分為四種：回避、轉嫁、減輕、接受。回避風險指改變項目計劃，以排除風險或條件，或者保護項目目標，使其不受影響。轉嫁風險指設法將風險的后果連同應對的責任轉移到第三方身上。減輕風險指設法把不利的風險事件的概率或后果降低至一個可接受的臨界值。采取此項技術表明項目班子已經決定不打算為處置某項風險而改變項目計劃，或者表明他們無法找到任何其他應對良策。該項目已經發生了嚴重的需求風險，張工采取補救措施應該包括減輕和接受。減輕風險的應對措施應能設法減輕風險的影響，其著眼點應放在影響程度最大的連接點上，張工應該與李工積極地溝通和談判，使他們明白本期工程的重要意義，并承諾本期工程不是交鑰匙項目，可為系統升級和擴容留有擴展接口，將來新的需求能夠通過后續工程逐步開發實現,李工同意本期工程只實現大家最為關注的功能指標和性能指標;最常見的接受風險的應對措施為預留應急儲備,或者簡稱儲備,包括為已知風險留出時間、資金或資源。為接受的風險所預留的儲備取決于按可接受風險水平計算所得影響的大小。張工應該申請啟動項目風險儲備金，通過增加資源成本、付出額外勞動使得項目回到正軌。問題2：

在設計系統架構時，項目管理經驗不足、關鍵技術不明確、系統擴展性不佳、產品兼容性有問題、軟件版本管理混亂等，均可能是影響系統正常運行的潛在隱患。在本期工程的機房設備平面設計中，張工團隊起初大部分機架式的小型機集中擺放在一片較小區域內，從表面上看，提高了機房平面空間的使用率，但是由于未充分考慮到設備散熱因素，造成了該區域的機房專用空調負荷過重而多次宕機。

后來，張工聘請了具備通信設計資質的專家負責工程設計，從機房空調、電源、布線、承重、消防等各個方面進行了詳盡的勘察和設計。透過專家編制的工程設計，張工團隊可以細致地了解有關機房設計的技術內涵和外延，并通過工程設計評審機制，一方面確立了工程設計的權威或指導作用，另一方面獲得了專家們的可靠技術承諾，實現了工程設計風險的良性轉移。問題3：

針對該項目的風險管理，提出以下幾點建議作為參考。

（1）推廣項目管理理念。項目團隊主動向項目干系人及周邊人介紹項目管理的先（2）

（3）

（4）進理念和方法，處處營造項目管理的氛圍。團隊成員積極參加項目管理培訓，將所學用于工作和生活之中，并加以總結和升華，提升自已的競爭力。有效管理項目風險。項目經理自始至終負責制定項目風險管理計劃和風險應對計劃，并在每次項目例會時重點討論項目風險，對風險發生概率和影響程度進行評估，由定性分析到定量分析，制定有效的預防、減輕或促進風險（機會）的應對方案。

多渠道溝通和談判。保證多渠道溝通機制暢通，采用橫向溝通方式和縱向溝通方式。靈活使用談判手段和技巧，收集和掌握足夠的有用信息，確保具有主動的話語權。處理好與項目干系人的關系，相互配合，實現共贏。

爭取高層領導支持。高層領導對于項目成敗至關重要。高層領導掌握項目團隊所需的任何資源。通過邀請高層領導參加項目啟動會、關鍵里程碑發布會、項目完工總結會等形式，既可以使高層領導關注項目、了解項目和推動項目，又可以提升項目及項目團隊地位，有利于項目成功，有利于個人職業生涯發展。

案例分析十六

問題1：

對于緊急重要風險1措施如下：保障工程進度要求，確保NSS、BSS軟件督導的調測力量；及時溝通，避免因為傳輸原因耽擱進度；確保工程質量，督導、督察人員將對合作方施工人員進行有效的指導和對工程質量進行有效監控。項目實施日報制，項目經理每日對省市公司網絡部進行工程匯報，對于因為用戶原因造成的進度耽擱明確指出來，分清雙方責任。

對于緊急重要風險2措施如下：公司研發中心MSC、BSC、BTS人員現場進行信令跟蹤，對切換不成功的原因進行定位，在A公司成立專門的小組，協助現場進行問題定位。如果是我方原因，中研相關部門進行程序修改，如果是對方原因則提供相關的信令分析文件，由項目經理和中研人員共同向局方解釋，要求愛立信修改相關程序。計劃工程的不同階段分別舉行三次移動公司、A公司、愛立信雙頻技術切換交流，討論雙方參數設置，移動公司負責總體監控雙方的實施工作；在城市郊區話務量較小地區，開通5個基站進行單站以及雙頻配合測試，為全網開通積累經驗。

對于緊急重要風險3措施如下：需要找到集團公司《關于建設中國移動1800M雙頻網的若干意見》文件原件，進行仔細分析，尋求解決方法。加強省公司高層的工作，通過客戶關系工作期望給A公司工作上提供支持。對此事向公司總部反映，看看是否通過北京分部的工作使移動集團公司有所松動或是有其他變通方法。

對于緊急重要風險4措施如下：公司對城市1800M頻段分地區進行測試，摸清干擾信號頻段，通過調整頻率規劃規避部分干擾，爭取多開通基站。了解目前使用1800M單位情況。協助移動與其進行交涉，爭取占用單位能進行頻率調整，解決1800M干擾問題。將此事匯報到移動公司高層，通過其與無委高層的溝通解決頻占費的問題，并通過無委清理被其他單位占用的1800M頻段。問題2：

該項目還存在以下幾個問題：

（1）A公司將競爭對手的競爭風險分析不全面。A公司僅僅是從技術上進行了風險防范，對于其他方面A公司卻沒有任何措施。

（2）對于1800M干擾的風險問題，A公司制定的計劃太松散，沒有引起足夠的重視。（3）對于1800M網絡的建設目的A公司理解有些偏差。

調整的風險應對計劃如下：（1）收集競爭對手問題，針對此提出A公司的解決方案。

（2）聯合市場部，加強高層項目推動，突出A公司網絡設備特點，建議用戶在省會城市引入競爭，盡快開始1800M工程建設。

（3）加強干擾解決推動監控，加快進度，項目經理進行全程跟蹤；

（4）對用戶進行雙頻網建設思路進行新的引導，列舉A公司在全國的雙頻網應用，列舉A公司開通基站的指標數據。

問題3：

（1）進行調研，確定流動原因。

（2）在項目開始前，把緩解這些流動原因的工作列入風險管理計劃。

（3）項目開始時，做好計劃一旦人員離開時便可執行，以確保人員離開后項目仍能繼續進行。

（4）制定文檔標準，并建立一種機制，保證文檔及時產生。

（5）對所有工作進行細致詳審，使更多人能夠按計劃進度完成自已的工作。（6）為每個關鍵性技術培養后備人員。

案例分析十七

問題1：

（1）對省內省外投標人提出了不同的資格要求。公開招標應該平等地對待所有投標人。

（2）乙單位提交保證金晚于規定時間,投標保證金是投標書的組成部分,應在投標截止日前提交。

（3）招標書發出時間為2004年12月15日，而投標截止時間為2004年12月30日，中間時間為15日，有違招投標法所要求的20日。

（4）投標截止時間與開標時間不同，《招投標法》規定開標應當在投標文件截止時間的同一時間公開進行。

（5）不應該是招標辦主持開標會。開標會應由招標人或其代理人主持。（6）重新招標時候評委應為5人以上單數。

案例分析十八

問題1：

企業A向第三方（監理公司C）泄露承建單位（IT公司B）的技術機密，違反合同簽訂時保密約定要求，該措施不妥。問題2：

項目不可分割，屬于一個整體，未經甲方企業A同意，此類項目不應分包。而公司B卻和公司D簽訂此項目的分包合同，很顯然，該合同無效。問題3：

企業A應該將公司B未付給公司D的所有款項（扣除保留金）付給公司D，并從應付給公司B的任何款項中如數扣回。

案例分析十九

知識產權是企業寶貴的無形資產，也是企業能夠持續發展的前提之一，某軟件公司A公司從事管理系統軟件開發，程序員張某參加了A公司開發管理系統軟件的工作，后辭職到另一個公司B公司任職。于是項目負責人將張某在該軟件作品上的開發者署名更改為他人。問題1：

按照《計算機軟件保護條例》的規定，自然人的軟件著作權的保護期限為自然人終生及死亡后50年.問題2：

知識產權一般都具有法定的保護期限，一旦保護期限屆滿，權利將自行終止，成為社會公眾可以自由使用的知識。商業秘密受法律保護的期限是不確定的，一旦為公眾所周知，即成為公眾可以自由使用的知識。問題3：

甲、乙兩人同時在同一時間就同樣的發明創造提交了專利申請,專利局將分別向各申請人通報有關情況,并對兩件申請都不授予專利權。這種情況是否合理？

對于同一時間申請專利的情況，專利局可分別向各申請人通報有關情況，請他們自已協商解決這一問題，如果雙方協商不成的，則兩件申請都不授予專利權。問題4：

該項目負責人張某侵犯了開發者張某的身份權及署名權。問題5：

目前，我國已形成了相對完備的知識產權保護的法律體系，對軟件形成一種綜合性的法律保護，如源程序和設計文檔作為軟件的表現形式受《中華人民共和國著作權法》保護，同時作為技術秘密又受《中華人民共和國反不正當競爭法》。

第五篇：軟件項目管理崗位競聘報告

競聘報告

尊敬的各位領導、各位同事：大家好！

今天我在這里，參加中心中層干部競聘會議，這是一次難得的機會，一次檢驗、學習、提高的機會。

首先，借此機會，簡單介紹一下我的情況，本人曾先后就讀于上海XX大學計算機實用技術專業和上海交通大學計算機科學與技術專業，1998年-2000年參加NIIT軟件學院海外課程進修，并獲得該軟件學院diploma證書，2002年獲得微軟認證高級軟件開發者MCSD證書。2001年進入XXXX中心，正式成為中心的一員。在中心工作期間，始終承蒙領導抬愛和提拔，同事們的支持和幫助！

參加這次競聘，我認為我具有以下幾方面的優勢：

1、長期的軟件開發工作經驗，我曾經在軟件開發的各個環節上進行工作，熟練掌握和應用目前軟件開發的幾大主流工具和數據庫存儲系統，熟悉軟件開發的標準和規范，累積了豐富的項目開發經驗，由于軟件開發工作本身的特殊性，使我在長期的工作中，養成了樂于學習、不斷適應、善于接受新的理念的工作和學習習慣。

2、豐富的項目管理工作經驗，在我進入軟件開發這個行業的十多年期間，我曾先后管理和完成了各類軟件項目的實施20余個，在項目管理的過程中體驗了軟件項目管理在執行過程中的各種情況和突發事件，積累了非常豐富的應對措施以及項目實施經驗。

3、熟悉目前軟件行業項目管理標準，在長期的實際工作中，本人熟悉了包括CMM，ISO級軟件項目標準，并善于進行項目計劃的制定，項目執行過程的流程改進，軟件的開發組織，軟件的質量保證以及項目文檔及數據的存檔管理工作。

對于今后工作的設想：

一、在中心整體戰略布局下，積極配合部門經理，完成部門任務

保證項目開發過程的質量，全面降低程序開發過程中的人力成本。在不影響正常項目進程的情況下，組織資源，通過質量檢查、節點評審、人力培訓，整理和管理部門有效的技術資產，提高軟件生命周期中的復用性，構建適用于本部門 1的軟件業務的技術管理體系；

(1)制定相關的涉及到技術管理的制度流程規范；

(2)組織部門技術監督和審查、考核；

(3)組織執行技術庫的構建，監督執行和推廣驗證技術管理的相關成果；

(4)組織相關技術、業務的培訓任務；

(5)定期向部門、中心匯報技術管理工作成果計劃、執行、評估結果；

(6)組織各個項目的過程評審活動；

(7)按照要求承擔售前組織管理工作；

(8)在技術管理工作中協調相關部門和各個項目之間協同；

二、制定技術管理體系和目標規劃

按照軟件部的規劃和部門未來前瞻性要求，緊密圍繞實際業務，統籌規劃、分布實施、立竿見影的原則，從制度規范流程、項目開發過程、人力規劃三個層面展開具體工作。

（1）制度規范流程

加大技術管理在部門軟件部制度規范體系中的體現，尤其是《考核及獎懲制度》、《項目經理制度》、《開發流程》、《實施流程》、等明確具體條款，項目歸檔備份和虛擬機服務器的管理；

（2）嚴格監控項目開發過程

監控項目經理在各具體項目執行過程中的技術管理工作：

? 檢查各項目組質量保障工作的進展情況，定期檢查、評估文檔編制、編碼規范，保證部門項目質量工作高質量、有序的完成；

? 組織項目階段性技術評審；

? 推廣應用各項有利于項目過程的各項實現輔助技術措施，例如：版

本管理（vss、cvs），bug工具（bugfree、excel），積極開展各項組內

交流學習；

明確要求項目經理在項目結束之后的總結歸納中，除了對項目進行系統分析之外，提交相關的開發經驗、開發框架、控件和關鍵算法。

對于項目過程中的各項信息，都作為中心軟件部共有的財產和資源，集中統一管理。

三、部門人力規劃

軟件部的員工都作為軟件最具活力的成分，必須引導幫助其進行合理的職業規劃。

主動調研部門人員的技術能力水平，制定人力培訓計劃。開展各項能力提升（培訓、交流等），促進軟件部員工技術能力體系穩步、快速的提升，改善具體工作執行能力；組建部門內專家團，匯聚技術精英，服務于部門，共享于部門。

四、檢查監督各項目質量工作

隨著軟件部業務的明確和不斷壯大，已完成和未完成、以及正在開始的項目數量越來越多，首先對以往各個項目的執行情況進行摸底。

（1）文檔是否齊全，依據的標準，是否按照部門要求；

（2）代碼設計是否規范，依據的標準，是否按照部門要求；

針對文檔和代碼兩項重點工作，在過程中監督和檢查各項目經理后續工作的質量執行情況。

五、組建專家團

參加項目專家團的人員僅限于在軟件項目領域里富有專業技術能力的骨干技術人員和管理經驗的項目管理人員。

項目專家團作為部門職能常設機構，負責處理的日常工作：議題的提出、專家團活動安排、意見匯總、提交活動報告、具體措施執行保障。

專家團主要承擔部門內臨時性任務，具體職責如下：

(1)承擔項目實施方案的論證（售前）；

(2)承擔對項目執行情況的檢查、評估和驗收工作：項目工作計劃及執行狀況、資源使用情況、項目節點性評審（需求、設計、開發、測試、驗收）；

(3)承擔領域為公司重點軟件項目的重要技術問題的咨詢和技術攻關工作；

(4)承擔部門內部日常的知識管理，技術培訓；

(5)參與部門項目運作過程中的制度、流程、規范修改性建議的提出；

(6)項目正常情況，專家團成員有組織的參與一線項目督察工作，檢查項目組各項工作的進展情況和重大決策的落實情況；

(7)項目出現緊急情況，專家團成員有組織的參與一線項目實際具體工作；

六、實現應用“知識庫管理”模塊

圍繞部門復用性管理的目標，部門項目的成果、經驗等顯式知識（業務介紹、技術構架、項目管理、解決方案）：

（1）架構

（2）控件

（3）模塊化類庫

（4）成果算法和函數

（5）開發經驗技巧

（6）開發性接口

（7）測試與實施技巧

著手集部門之力服務于項目，完成主體知識管理的具體工作。為創建今后的技術核心團隊以及產品化奠定基礎。

七、按照計劃進行部門培訓任務

為了落實今后幾年的任務，必須大力提高員工的能力，而培訓是目前提高能力的重要措施。另外，實施制度與規范、測試制度與規范將由實施組統籌安排。與各項目有關的業務培訓也將融合到各項目計劃之中，并由各項目經理統一安排。

最后我要感謝一下中心為我們提供了這樣一次公平競聘的平臺，給了我一次挑戰和展現自我的機會，我今天競聘的是軟件技術部項目總監崗位一職，假如我競聘成功，我將會認真地履行好我的職責，貫徹落實中心制定的目標，提升軟件項目管理的品質，規范項目開發的流程，提升員工的工作熱情！我有充分的自信和決心做好這項工作！

XX

2012年9月24日