軟件項目論文

序論：寫作是一種深度的自我表達。它要求我們深入探索自己的思想和情感，挖掘那些隱藏在內心深處的真相，好投稿為您帶來了一篇軟件項目論文范文，愿它們成為您寫作過程中的靈感催化劑，助力您的創作。

軟件項目論文:淺析軟件項目管理中人員流動風險的管理

論文關鍵詞:軟件項目　風險管理　策略　監控

論文摘要:在軟件項目管理中，頻繁的人員流動是軟件項目的一個風險，為了緩解這種風險，項目管理者必須建立一套策略來降低人員流動，同時，還需要監控某些因素，這些因素可以提供風險是否正在變高或變低的指示，通過這種監控管理，妥善地處理風險事故造成的不利后果，最終實現項目的總體目標。

一、引言

在軟件公司中，技術人員的流動性一直處于比較高的水平，因此給公司帶來了很大的損失，要想改變這種現狀在短期內恐怕難以做到。但這個問題又一直困擾著公司的項目管理者，特別是與軟件項目組人員組織相關的頻繁的人員流動給軟件項目帶來了極大的風險。那么，認識到這種風險后，怎樣來對這種風險進行有效的控制，采取主動行動，創造條件，盡量擴大風險事件的有利后果，妥善地處理風險事故造成的不利后果，最終實現項目的總體目標，這是本文筆者要討論的問題。

軟件風險是指軟件開發過程中及軟件產品本身可能造成的傷害或損失。風險關注項目未來的發展，這意味著風險涉及選擇及選擇本身包含的不確定性，在軟件開發過程及軟件產品都要面臨各種決策的選擇。風險是介于確定性和不確定性之間的狀態，是處于無知和完整知識之間的狀態。同時，風險將涉及思想、觀念、行為、地點等因素的改變。

一般來說，在軟件項目中，存在以下一般性風險:(1)產品規模風險—與要建造或要修改的軟件的總體規模相關的風險;(2)商業影響風險—與管理或市場所加諸的約束相關的風險;(3)客戶相關風險—與客戶的素質以及開發者和客戶定期通信的能力相關的風險;(4)過程風險—與軟件過程被定義的程度以及它們被開發組織所遵守的程度相關的風險;(5)技術風險—突破技術的極限極具挑戰性和令人興奮，但這也是有風險的;(6)開發環境風險—與用以建造產品的工具的可用性及質量相關的風險;(7)與人員及經驗相關的風險—與參與工作的軟件工程師的人數、穩定性、總體技術水平及項目經驗相關的風險。

二、降低風險可采取的策略

如果軟件項目組對于風險采取主動的策略，則“避免”永遠是最好的目標。這可以通過建立一個風險緩解計劃來達到。在軟件項目中，頻繁的人員流動被標注為一個項目風險，基于以往的歷史和管理經驗，人員流動的概率為70 %，被預測為對于項目成本及進度有嚴重的影響。而軟件項目中，人員的頻繁流動又是一個無法改變的現實，為了緩解這個風險，項目管理者必須建立一個策略來降低人員流動?？刹扇〉牟呗匀缦?

1.找出人員流動的原因?？梢耘c項目現有人員一起探討人員流動的原因，比如是否公司提供的工作條件不如人意、報酬偏低、競爭激烈等。找出原因后，提出解決問題的策略，在可能的范圍內改善工作條件，至于報酬，不可能無限地增加，可以把工作業績和報酬掛鉤，提高員工的工作積極性，適當控制競爭的程度，最重要的一點是要培養員工對公司的歸屬感。

2.在項目開始之前，分清哪些是可控的，哪些是不可控的原因，采取行動以緩解那些在管理控制之下的原因，“預防”總比“救治”更主動。

3.一旦項目啟動，假設會發生人員流動并采取一些技術措施以保證當人員離開時的工作連續性。

4.對項目進行良好組織，使得每一個開發活動的信息能被廣泛傳播和交流，定期召開項目組工作協調會議，隨時掌握項目的進展情況。

5.定義文檔的標準，并建立相應的機制，以確保文檔能被及時建立。

6.對所有工作進行詳細復審，使得不止一個人熟悉該項工作。

7.對于每一個關鍵的技術人員都指定一個后備人員。

三、降低風險的監控因素

1.隨著項目的進展，風險監控活動開始進行。項目管理者監控某些因素，這些因素可以提供風險是否正在變高或變低的指示。在項目組的人員管理中，應該監控下列因素:(1)項目組成員對項目壓力的一般態度;(2)項目組的凝聚力;(3)項目組成員彼此之間的關系;(4)與報酬和利益相關的潛在問題;(5)在公司內及公司外工作的可能性。

2.除了監控上述因素之外，項目管理者還應該監控風險緩解步驟的效力。例如:上述風險緩解步驟要求定義“文檔的標準，并建立相應的機制，以確保文檔能被及時建立”。如果有關鍵的人物離開了項目組，項目管理者應該仔細地監控這些文檔，以保證文檔內容正確，當新員工加人該項目時，能為他們提供必要的信息，這是保證工作連續性的條件。

3.風險管理及意外事件計劃假設緩解工作已經失敗，風險變成了現實。繼續前面的例子，假定項目正在進行中，有一些人宣布將要離開。如果按照緩解策略行事，則有后備人員可用，因為信息已經文檔化，有關知識已經在項目組中廣泛進行了交流。此外，項目管理者還可以暫時重新將資源調整到那些需要人的地方去，并調整項目進度，從而使新加人的成員能夠趕上進度。同時，要求那些要離開的人員停止工作，進人“知識交接模式”。

總之.當對軟件項目期望值很高時，一般都會進行風險分析。不過，即使進行這項工作，大多數軟件管理者都是非正式地和表面地完成它。用在標識、分析、管理風險上的時間可以從多個方面得到回報:更加平穩的項目進展過程;較高的跟蹤和控制項目的能力;因為周密計劃而產生的信心。

四、總結

風險管理意味著危機還沒有發生之前就對它進行處理，這就提高了項目成功的機會和減少了不可避免風險所產生的后果。實踐經驗證明，最成功的項目就是采取積極的步驟對要發生或即將發生的風險進行管理。對任何一個軟件項目，可以有最佳的期望值，但更應該要有最壞的準備，“最壞的準備”在項目管理中就是進行項目的風險管理。

軟件項目論文:淺談軟件項目管理的決策支持系統

論文關鍵詞：軟件項目管理 軟件可靠性 決策支持系統

論文摘要：本文在解釋軟件項目管理和決策支持系統的基礎上，分析出軟件項目管理的局限性，進而說明應用軟件項目管理的決策支持系統的必要性。最后從軟件項目管理的角度來分析決策支持系統的目標，以及軟件項目管理的決策具有多級性。

隨著現代科技的發展，計算機應用于各個領域的管理，各個領域需要用軟件系統擴展和提高自己的業務。針對不同的行業和產業，研制出了不同的項目管理軟件。項目管理軟件主要完成的項目管理活動分為管理活動和工程活動兩類。例如:項目立項評審:評估項目立項條件是否具備，如相關部門移交資料是否齊全，客戶信息是否完整，團隊成員是否恰當等等;項目計劃評審:評估項目計劃合理性，是否與公司其他項目資源和運營目標沖突(回款):SCM(項目配置管理、Software Configuration Management):系統管理和項目有關的各類文檔和軟件版本，確保項目的惟一性資料信息被留存，可隨時追溯項目各階段關鍵文檔記錄(例如備忘錄)。工程活動包括項目要獲得實質性進展必須要做的工作，例如寫計劃，做需求調研，寫解決方案，變更項目范圍，項目啟動大會，項目例會，項目里程碑會議，項目緊急事件處理會議，項目備忘錄，項目驗證，項目培訓，項目小范圍試運行，項目驗收報告等等都是工程活動。

軟件項目管理能完成若干事情，但是，由于軟件開發過程以及應用過程中，諸多因素會造成軟件的不可靠性，例如:1.需求分析定義錯誤。如用戶提出的需求不完整，用戶需求的變更未及時消化，軟件開發者和用戶對需求的理解不同等等。2.設計錯誤。如處理的結構和算法錯誤，缺乏對特殊情況和錯誤處理的考慮等。3.編碼錯誤。如語法錯誤，變量初始化錯誤等。4.測試錯誤。如數據準備錯誤，測試用例錯誤等。5、文檔錯誤。如文檔不齊全，文檔相關內容不一致，文檔版本不一致，缺乏完整性等。另外程序代碼錯誤，也可以造成軟件的不可靠性。程序代碼一個最直觀的特性是長度，另外還有算法和語句結構等，程序代碼越長，結構越復雜，其可靠性越難保證。所以提高可靠性從原理上看就是要減少錯誤。而決策支持系統(Decision Support System，簡稱 DSS)正好可以解決這些問題，它能很好的將那些微結構或無結構、不確定和零散的關聯因素有機的綜合起來，進行分析、比較和定量化，給決策者以支持，減少了決策的主觀性。可見，研究并開發一個軟件工程項目質量決策支持系統(Decision SupportSystem For Software Engineering Project Quality，簡稱SEPQDSS)對于軟件企業的管理者，對于企業開發出高質量的軟件產品，對于企業的長期發展來說都是至關重要和必要的。

這里所說的決策支持系統(decision support system，簡稱dss)是指輔助決策者通過數據、模型和知識，以人機交互方式進行半結構化或非結構化決策的計算機應用系統。決策支持系統作為一種新興的信息技術，能夠為企業提供各種決策信息以及許多商業問題的解決方案，從而減輕了管理者從事低層次信息處理和分析的負擔，使得他們專注于最需要決策智慧和經驗的工作，因此提高了決策的質量和效率。

決策的進程一般分為4個步驟:發現問題并形成決策目標、用概率定量地描述每個方案所產生的各種結局的可能性、決策人員對各種結局進行定量評價，一般用效用值來定量表示、綜合分析各方面信息。決策支持系統的基本特征:對準上層管理人員經常面臨的結構化程度不高、說明不夠充分的問題:把模型或分析技術與傳統的數據存取技術及檢索技術結合起來;易于為非計算機專業人員以交互會話的方式使用;強調對環境及用戶決策方法改變的靈活性及適應性;支持但不是代替高層決策者制定決策。

決策支持系統的靈魂是先進的管理思想。一個成功的DSS應用，應該融合了優秀的管理思想，能給應用者提供分析和解決問題的有效的方法論。DSS中所包含的計算機軟硬件技術，則是將這種管理思想和方法論具體表現出來，從而讓DSS用戶在使用過程中能夠貫徹這種管理思想、實踐這種方法論。組織整體的管理績效因此而得到提高。這從另一角度說明，應用者必須首先整合自己的管理思路，提升管理意識，明確通過DSS將實現的管理目標，才能開始DSS的實施。

從軟件項目管理的角度來講，決策支持系統的目標是使軟件的功能更好地滿足客戶的要求，并且能在規定的時間內，在預計的資金下，開發出一個高效率，質量和可靠性能夠滿足要求的軟件。具體包括以下五方面:軟件功能完備(軟件的需求完備)，資金控制在計劃之內，時間控制在計劃之內，軟件的效率和可靠性符合要求，人員之間能夠合理協調達到最好的效率。

軟件項目管理的決策具有多級性。因此，決策制定程序是比較復雜的。一般來說可分為三個層次:第一層，決策路線層，反映了由決策任務的提出、多級決策、批準實施的全過程;第二層，決策工作層，由決策對象進入某一個部門開始，到送出這個部門截止的部門內部處理;第三層，決策分析層，指一個部門內單個決策者或決策小組分析問題所處的環境、確定目標，并提出方案(設計)、評價分析及解決方案抉擇和實施反饋的具體步驟。

由此可見，決策支持系統在軟件項目管理中的應用是非常必要而且有其重要價值的。

軟件項目論文:淺談軟件項目管理中的階段收尾管理

論文關健詞：軟件項目管理　收尾管理階段管理

論文摘要：在實際軟件項目管理中，階段性的收尾管理工作往往不被大家重視，其實階段管理收尾工作也是非常重要的。本文從階段評審，文檔記錄等方面來闡述軟件項目管理中階段收尾管理的重要性

隨著計算機和信息產業的發展軟件產品的規模也是越來越龐大，隨著軟件規模的擴大軟件人員的增加軟件項目管理的復雜性增大，各個軟件企業都意識到將項目管理的理念引入到軟件開發活動中開始對開發過程進行有效的管理又所謂“IT項目管理”或“軟件項目管理’軟件項目管理就是為了使軟件項目能夠按照預定的成本、進度、質量的順利完成而對成本、人員、進度、質量、風險等進行分析和管理的活動。隨著軟件開發規模及開發隊伍的逐漸增大軟件開發活動不再是像過去的幾個開發人員就可解決的事情，它需要使用開發規范或開發流程控制來約束每個開發人員、測試人員和維護人員的工作.以保證每個項目組成員按開發計劃及進度準時、保質完成自己的任務。軟件項目管理的各個過程主要包括二需求管理范圍管理任務分解規模估算成本管理進度計劃質量計劃配置管理計劃，風險計劃文檔管理團隊建設，跟蹤控制收尾管理項目結束。項目收尾管理作為項目結束前的最后管理工作也顯得及其重要一般包括合同收尾和管理收尾兩部分。合同收尾就是項目管理人員與客戶對照合同一項項的核對審核是否完成了合同所要求的內容是否達到合同所提出的指標或條件也就是我們通常所講的客戶驗收管理收尾就是對于項目組內部把做好的項目文檔、代碼、與客戶交流的文件等歸檔保存對項目中遇到的問題及解決方法、有效的創新技術進行及時地總結，對外宣稱項目結束轉入維護期把相關的產品說明及技術文檔轉到維護組。

一、階段收尾管理

軟件項目結束的狀態:

1.正常結束。2提前結束3延期結束4暫停。5取消(因變更或不可完成)。軟件開發是一項復雜的系統工程牽涉到各方面的因素在實際工作中經常會出現各種各樣的問題甚至面臨失敗。而如何總結、分析失敗的原因得出有益的教訓.這對一個公司來說則是今后項目中取得成功的關鍵。

以前會聽說過這樣的項目:客戶驗收后項目活動就隨之收場，項目資料沒有認真歸納總結不是束之高閣就是缺失不全但是當新項目啟動時.面對新的項目問題項目組成員才發現:其實這類問題以前也遇到過，但是卻無法找到相應的解決方案資料只好再投入人力、時間甚至金錢來重新經歷一遍為什么相同的問題會重復出現，究其根源是因為缺少項目總結也就是說沒有做好項目收尾工作。那么是不是我們只能等到項目結束或收尾時才能開始進行項目總結文檔保存的工作呢:當然不是在軟件項目管理的各個階段我們都可以做收尾管理工作，也就是階段收尾管理工作。

二、階段收尾管理的重要性

在實際軟件項目管理中.階段性的收尾管理過程和工作往往不被大家重視其實階段性的收尾管理工作也是非常重要的。階段收尾管理工作的重要性主要體現在如下幾個方面:

1進度管理中的里程碑每個項目都是由若干個相對獨立的任務鏈組成的軟件項目也是如此。只有在任何一條任務鏈都已經優化的基礎上才可能進行系統的全面的優化因此保證每條任務鏈的效率是整個項目進度完成的前提和基礎.只要能保證里程碑事件的按時完成，整個項目的進度也就有了保障。那么我們在里程碑點都來做些什么呢:

在計劃好的階段管理工作中.收集項目的最新信息和數據.并將這些數據與項目計劃進行比較，來判定項目的階段效率，進度是提前了還是落后了，成本是在控制中還是超支了?質量是否符合要求?？蛻魧﹄A段工作結果滿意么，及時總結經驗與教訓.同時及時發現項目存在的或潛在的問題以便近早采取糾正措施這就是階段管理工作中的收尾管理，所以說階段收尾管理是進度中的里程碑是整個項目進度優化的前提和基礎。

2溝通管理中的契機溝通是保持項目順利進行的潤滑劑。與傳統項目相比軟件項目具有較高的技術含量和較大的風險。參與軟件項目建設的用戶并不都是軟件開發專家.他們具有豐富的業務經驗但是很少能了解軟件開發的技術.隨著項目工作進程的深入就會有許多新的問題出現與客戶的及時有效溝通更顯得尤為重要。軟件項目是客戶和用戶共同面對的項目只有雙方的積極參與才能促進項目的成功，而只有進行有效的項目溝通管理才能確保用戶的積極參與。一個階段的項目工作完成后與客戶一起就前一段時間的工作進行總結和檢查是十分必要的。一方面可以及時了解客戶對項目工作的滿意程度及時統計、分析客戶對項目的意見.為下一階段工作的順利進行提供了保障另一方面有些因工作繁忙未能及時簽署的文件，也盡快找客戶給予簽字確認。當雙方出現糾紛時，只有雙方簽字的文字記錄才是最有用、最有說服力的證據。

3收尾管理的基礎。一個項目階段的工作剛完成時項目組成員都保留著最新的階段記錄如階段文檔或最新的代碼版本這個時候收集起米是非常容易的時間隨著人員的變動或者項目的需求變更有些項目成員可能離開了項目組那時再去收集他們保存的文檔資料就非常困難了，甚至有些記錄永遠也找不到了。好多大的軟件開發項目跨幾年的時間項目經理可能已經換了幾任客戶的項目主管也換了幾位最后項目收尾管理時的文檔收集、總結的工作，就是在階段收尾管理的基礎上來確保每個階段的文檔、資料都能按時完整地保存、歸檔。只有階段管理收尾提供的數據信息越真實、越準確.才能保證在項目最終收尾時客觀評定項目的績效總結的經驗教訓和文檔資料才有真正借鑒的價值總而言之.作為一個好的項目經理，一定要重視進度中的里程碑事件抓住與客戶溝通的契機做好項目階段工作的總結收尾工作如何做好這些工作呢。也就是要做好項目階段管理收尾工作。階段收尾管理工作是保證項目成功的重要管理手段它和項目的其他工作一樣應該納入項目計劃并按計劃落實。

軟件項目論文:淺論系統動力學的軟件項目進度管理

論文摘要：軟件項目管理中存在復雜的不確定性和非線性性，特別在進度管理當中。文章采用系統動力學的方法模擬了兩階段軟件項目的實施過程，該模型可以對項目的完成時間進行有效的預測，同時還討論了人員的分配對項目進度的影響。

論文關鍵詞：軟件項目管理；進度管理；系統動力學；預測；人員分配

為解決“軟件危機”，學術界和業界將項目管理理論借鑒到軟件開發中，誕生了軟件項目管理。眾所周知進度管理、質量管理和成本管理為軟件項目管理主要內容。在進度管理中，一般都采用傳統項目管理方法，如甘特圖、關鍵路徑法和計劃評審技術，它們都建立在項目可以分解為獨立的工序上，而在實際軟件項目管理中，各個階段(工序)之間是相互聯系的，如前一階段未發現的錯誤會影響到后一階段的實施，同時當后一階段發現前一階段有錯誤時需要前一階段返工，等等如此現象很多，這種相互影響往往是非線性的，這在傳統的網絡圖中難以表達，也超出了管理者頭腦能達到的理解范圍。

20世紀50年代麻省理工學院的Forrester教授創立的系統動力學為解決動態復雜問題提供了一種可行的理論、觀點、方法與工具。

1系統動力學概述

20世紀50年代Forrester教授將計算機科學和反饋控制理論應用于社會、經濟等系統的研究。

20世紀紀70年代，系統動力學逐漸發展成為一種了解和認識人類動態復雜系統的研究方法。2O多年來王其藩教授等學者參與了系統動力學在中國的應用研究工作，并做出了重要貢獻。

系統動力學在軟件項目管理中應用比較少見，用系統動力學的方法討論了時間和成本估算，用系統動力學方法研究了項目目標進度的設定對項目表現的影響。討論了系統動力學方法在項目風險管理中的運用，特別是在管理項目風險動態復雜性方向的特色和優勢。

系統動力學強調以閉環的觀點方法來認識和解決問題，這也決定了它采用反饋環路式的建模方法，即通過分析行為模式背后的反饋環路結構，改變結構中相關變量的值，了解不同策略下的不同行為模式，來完成策略的優化。

系統動力學強調反饋環路的結構關系、時間延遲、信息放大對系統行為的影響，其中結構關系表示系統各組成結構之間的相互關系，時間延遲表示決策行動落后于信息的獲得，信息放大表示隨著流程與時間的推移，某些信息會被放大，它對決策行為的影響會隨之被放大。

2模型的建立

軟件項目管理往往包括多個階段，這些階段之間是相互聯系的，彼此構成網絡。但是兩階段間的關系是問題的基礎，故以2階段軟件項目開發為例。模型基于如下假設：①每個階段開發都存在一定的錯誤，這些錯誤一部分在本階段被改正，一部分需要到下一階段才能發現。②在每個階段發現錯誤的機率與從事調試的人員多少有關。③上一階段遺留的錯誤影響下一階段的開發以及調試。④每個階段的人員是固定的，開發人數多必然導致調試人數少。⑤項目的進度為第一階段開發，調試，第二階段開發，第一階段返工、第二階段調試。其中第一階段返工與第二階段調試是并行的。

2．1狀態變量以及之間的銜接

模型中的狀態變量共有5個，“毛開發量1”，“已更改項目1”，“返工項目”，“毛開發量2”，已“更改項目2”分別表示第一階段的開發、調試、返工，第二階段的開發，調試，其關系如圖1。

只有上述5個工序都完成，該項目才算完成，圖2用輔助變量“整個項目進度”表示了研究關心的項目進度情況。

2．2速率變量的設定

模型中共有5個速率變量，其設置分別為：實際開發速率1=剩余工作量影響1×開發速率1×開發人效率×開發人數1。

調試1一調試人數1×調試效率×剩余錯誤影響1×時間銜接1。

實際開發速率2一開發人效率×開發2×剩余工作量影響2×時間銜接2。

調試2一調試人數2×調試效率×剩余錯誤影響2×上階段錯誤×時間銜接3返工=調試人數1×調試效率×剩余遺留錯誤影響。

需要說明的是：“剩余工作量影響”、“剩余錯誤影響”、“剩余遺留錯誤影響”。這三個影響主要采用了如圖3的參考模式。

其中“剩余工作量(錯誤)影響”說明當工作開始時工作速率比較低，當工作解決尾聲時速率也比較低，中間速率最快；“剩余遺留錯誤影響”表示當第一階段遺留的錯誤越多，第二階段的速率越慢；這符合實際情況。

其它輔助變量的設置不再贅述，該模型的整體流圖如圖4所示。

3項目進度的估算

建立好模型后，通過設置常量和決策變量可以對系統進行模擬。這里令第一階段和第二階段的人員都為20人，第一階段和第二階段的預計工作量都為1000，錯誤率為0．2，第一階段開發人員為10，調試人員為10，第二階段開發人員為7，調試人員為13，模擬得到的項目進度如圖5所示。

從圖5可以看出在整個工程160(天)完成，并且在第35(天)第一階段初次完成開發，在70天完成調試，在125天完成第二階段初次開發，在160天完成第一階段的返工和第二階段的調試。

4人員分配對項目進度的影響

從模型流圖(圖4)可看出，問題的決策變量是每個階段人員的分配以及人員的工作效率。提高工作效率自然會加快進度，這不需要討論，這里主要研究人員分配，特別是第一階段的人員分配對整個項目進度的影響。

模型假設第一階段遺留給第二階段的錯誤的多少取決于第一階段從事調試人數，即：階段1遺留錯誤一錯誤一(錯誤×調試人數1作用)。

其中“調試人數1作用”采用了“S型曲線”參考模式，表示調試人數很少時發現錯誤的概率小，隨著人數增加發現錯誤概率迅速提升，到人數趨于飽和時概率趨于穩定。

在第一階段遺留錯誤對第二階段的影響上，以對第二階段的調試工序的影響為例來說明，模型假設第二階段的調試中能逐步發現第一階段的遺留錯誤，故而交給第一階段返工，同時第二階段的調試繼續進行，并且調試的速度受到第一階段剩余遺留錯誤的影響，即：調試2一調試人數2×調試效率×剩余錯誤影響2×上階段錯誤×時間銜接3。

圖6分別模擬了總人員為20人的前提下第一階段開發人員為5、10、15、18共四種情況對應的整個項目的進度。從圖中可以看出開發人員為15時進度最快，開發人員過多(18人)和過少(5人)都會導致項目進度的增加，這符合現實情況。導致這樣的原理在于：當開發人員過少，則延長了開發過程；當開發人員過多，必然導致調試人員過少，雖然第一階段的開發過程時間縮短了，但是勢必增加調試過程的時間，以及增加遺留錯誤進而影響下一階段的進度。故而有一個適中的人員分配方案。

5結束語

軟件項目管理系統是一個動態的復雜系統。采用系統動力學的方法有助于分析系統的變化行為，文中的模型主要分析了在總人員不變的情況下人員分配在兩階段項目管理當中的影響。由于實際當中人員可能是變動的，如除了正常的人員流動外，管理者可能通過觀察項目的進度人為的調整人數。還有在實際中影響進度的因素很多，如人員更替、工作效率、經濟資源等，同時這些因素是互相藕合的，如何更細致考慮這些影響因素從而準確的模擬進度管理需要深入研究。

軟件項目論文:淺談軟件項目實訓中的人員選擇與管理

論文關鍵詞 軟件高職　項目實訓　人員選擇　人員管理

論文摘要 項目實訓是軟件高職教育課程體系中的重要環節。結合軟件高職項目實訓中人員管理的實際情況進行分析和論證，同時給出實訓人員選擇與管理工作的基本原則和方法，并總結其中的一些基本經驗。

隨著國家大力發展職業教育的政策的出臺，職業教育在全國范圍逐漸興起，軟件高職教育作為職業教育的一個重要組成部分，為國家和地方培養了大量的具有較強動手能力的一線人才，創造出巨大的生產力，帶動整個IT行業的發展，推動經濟和社會的進步。項目實訓作為軟件高職教育課程體系中的一個重要環節，無論是對學生理論知識的拓展還是動手能力的培養都起到至關重要的作用。目前，福建省的軟件高職項目實訓還處于初級發展階段，無論在項目設置上還是在管理方式上都存在不足。筆者結合實際教學和管理經驗，對軟件高職實訓中的人員管理方式和方法做初步的分析和探討。

1 人員的選擇

教育的宗旨是以學生為本，平等地對待每一位學生，讓他們在最大程度上發揮潛力。但是實訓工作畢竟帶有一種企業模擬性質，學校注重教育公平，而企業更關注開發效率和項目成本，這兩者在一定程度上是此消彼長的對立面。因此，如何通過合理的人員選擇和配置，找到既能平等地對待每個學生，又能夠最大限度地提高項目團隊開發效率的平衡點，是實訓項目管理人員所急需解決的現實而又棘手的問題。以下是筆者在實踐中探索并采用的2種較為合理的人員選擇與配置方案。

1.1 T&R式自由組合法這里的T指的是Test，即測試，包括技術筆試和專業面試。在兩項測試之后應形成一個比較合理的量化指標，該指標應著重突出候選人員的技術能力和團隊意識，公布所有候選人員的各項量化指標。為保護學生的隱私，在公布時可以用編號取代學生的真實姓名。這里的R指的是rate，即比例。項目管理人員可以預先設定好小組成員結構的技術等級比例，參照學生的綜合得分情況，按照1:2:1的高中低3個層次分布比例較合理。這種做法既可以避免單純比例式自由組合給學生帶來的盲目性，也能夠比較真實地反映學生的能力水平，可以科學地、客觀地組建起較為高效的團隊，從而能夠在后續階段提高團隊整體工作效率，也為管理工作帶來方便。

1.2 T&R交互式人員確定法首先尋找若干名班委組成評審組，項目管理人員或教師負責領導該評審組；接著參照T&R方法得出候選人員的各項評估指標和綜合指標，以及小組結構比例；然后由評審小組成員進行數據分析并結合每個成員實際情況確定各小組的組成人員。將初步形成的分組名單公布告知各候選人員，征求每位成員意見，由評審小組跟持反對意見的候選成員進行當面的會議式的溝通，進行合理的調整，經此步驟之后形成最終分組名單并公布。這樣做實現候選成員與管理人員之間的交互，能夠把純粹的硬性考核成績指標轉化為“考核成績指標＋交互式分析”。這樣較為客觀且人性化的評判方式，既能夠得到較為真實的數據，又能夠吸納學生合理的意見或看法，從而利于更科學的人員選擇。

2 人員的管理

美國心理學家亞伯拉罕·馬斯洛把人的需求分成生理需求、安全需求、社交需求、尊重需求和自我實現需求5類，依次由較低層次到較高層次排列，在管理中他建議通過滿足人的需求來激發他們。

在學校實訓的項目組中，成員的生理需求和安全需求都基本能夠得以滿足，因此，保證成員的社會需求、受尊重需求和自我實現需求的滿足，對管理者來說有十分重要的意義。1）滿足組員的社會需求就是為組員提供相互交往的時間和場所。實訓項目的交流不應僅局限在小組的范疇，應鼓勵小組與小組間的相互交流，條件具備的話可以組織學校跟學校間類似項目組間的交流。形式可以多樣化，如電子郵件、組建QQ群、網絡會議、座談會和技術講座等互動方式。2）為了滿足組員受尊重的需求，應該讓他們感到在項目小組中受到人格上的尊重，技術長處被認可。對于參加實訓的學生來說，對他們做出的成績給予充分的肯定就是一種簡便高效的方式，如針對某個技術環節開展一次技能比賽，或者開展評審會定期對項目階段成果進行評估，對優秀團隊及其成員進行表彰等。3）為滿足組員自我實現的需求，應該在項目取得一定成果的基礎上，分配給組員具有一定挑戰性和難度的任務，這些任務不能超過學生能力的范圍，同時給他們提供課外的輔導以提高他們解決這些問題的技能。任務的完成情況可以作為附加評審內容納入學生最終的實訓綜合成績中去，給學生超越自我的動力。

3 團隊的管理

3.1 增強小組凝聚力一個有強大凝聚力的小組是最高效的小組，小組中的成員在思想上能夠形成共同的準則，在工作中能夠緊密配合和協調，組員跟組員之間能夠互相學習、相互關照，從而消除隔閡，用集體的力量解決許多工作中的問題。增強小組凝聚力的方式有許多，如給小組起個性化的名字、開展游戲或者室內或戶外運動等方式增進組員間的溝通。另外，提高小組組員的責任感、誠信度以及保障他們的知情權、提供發展的空間等，都是增強小組凝聚力的有效方法。

3.2 增強小組溝通溝通作為軟件開發過程中的重要環節，對于開發效率的提高和團隊的整體發展具有決定性的意義。1）適當的小組規模。在編制小組成員時應考慮到人數對溝通的影響，成員太少，溝通容易但不利于開發效率；反之，成員過多會使得溝通變得十分困難，從而使效率嚴重下降，因此，合理的人員安排才是關鍵。根據經驗，一個實訓小組以4～8個為宜，其中6人組最為合適。2）合理的性別比例。如果小組中的組員性別均相同，可能會導致沖突，使得溝通無法正常進行，所以在確定小組結構時應注意男女比例的控制。對于軟件開發類實訓項目而言，小組中的男女比例應控制在3:1左右，其中女性組員可以作為小組的協調員。3）適當的小組負責人。小組負責人除了領導小組工作外，還負責協調小組成員之間的溝通。受尊重的小組負責人可以提高小組凝聚力和工作效率，無論對自身的進步還是對整個團隊的發展來說都是大有裨益的。

軟件項目論文:關于工作流的軟件項目管理系統的設計與實現

論文摘要：本文介紹了一個基于工作流技術而研制的軟件項目管理系統。文章首先描述了傳統軟件項目管理系統的不足之處，提出用工作流的方法來設計軟件項目管理系統，然后介紹了一些理論基礎。文中重點闡述了系統的設計結構和所采用的一些技術，并給出了部分的具體實現方法。

論文關鍵詞：工作流，JMS，項目管理，SPP，建模，工作流網

1前言

2O世紀7O年代以來，為了解決軟機危機，改進軟件過程能力，計算機科學家提出了軟件工程的概念，將系統化的、規范化的、可度量的方法用于軟件開發、運行和維護的過程。近些年來，隨著計算機技術的進一步發展，相應的使用軟件工程方法的軟件項目管理系統也有了顯著的發展。但是，由于開發流程中存在的不確定性以及項目變化等因素，這些系統也暴露出一些不足之處。

傳統的軟件項目管理系統，一般是由圖形用戶接口(GUI)，應用程序和數據庫組成，用戶通過GUI向應用程序發出請求，應用程序處理這些用戶請求，并且訪問數據庫，返回用戶所要求的結果。這種模型在流程穩定的時候是可以滿足需要的，它的缺點在于：

1)建模過程是之前設定好的，無法改變；

2)缺乏柔性，系統開始運行之后，預先定義好的條件就無法改變了；

3)可擴展性較差，如果想要增加或者修改相應的功能，整個系統必須重新開發。

目前，對工作流技術的研究以及相關產品的開發是國內外學者研究的熱點問題之一，很多管理系統都采用工作流技術來克服上述問題。工作流起源于生產組織和辦公自動化領域，它是針對日常工作中具有固定程序的活動而提出的概念。目的是通過將工作分解成定義良好的任務、角色，按照一定的規則和過程來執行這些任務并對它們進行監控，達到提高辦事效率、降低生產成本、提高企業生產經營管理水平和企業競爭力的目標。

WFMC給出的工作流定義是：工作流是一類能夠完全或者部分自動執行的經營過程，它根據一系列過程規則，文檔、信息或任務能夠在不同的執行者之間進行傳遞與執行，以實現整體的業務目標。而這正適合于軟件開發過程管理，基于上述的理由，我們結合江蘇省十．五攻關“工作流技術的研究和應用”項目，研究并開發了基于工作流的軟件項目管理系統CMMFlow，目前已應用于軟件能力成熟度模型(CMM)的管理，其效果相當良好。

2理論基礎

2．1 CMMI3級精簡并行過程(SPP)模型

利用工作流技術可以設計和建立一個工作流環境，在此系統中，我們使用CMMI3級精簡并行過程(SPP)模型來支持軟件過程實施。

SPP把產品生命周期劃分為產品概念、產品定義、產品開發、產品測試、用戶驗收和產品維護等6個階段，包含項目管理、項目研發和機構支撐等3類過程、19個過程域。其中項目管理過程包含立項管理、結項管理、項目規劃、項目監控、風險管理和需求管理等六個過程域；項目研發過程包含需求開發、技術預研、系統設計、實現和測試、系統測試、Beta測試、客戶驗收和項目技術評審等8個過程域；機構支撐過程包含配置管理、質量保證、培訓管理、外包與采購管理以及服務與維護等5個過程域。

我們把每一個過程域都看成是一個流程，其中過程域之間的關系是線性為主，并行、迭代為輔。每個過程域包含若干原子活動。通過建立活動與角色以及角色與具體用戶的關聯，即可建立一個可執行的業務過程模型。

2．2基于petri網的可視化建模工具

在這個系統中，我們的建模工具是使用工作流網和XP—DL共用的策略，采用的是擴展的Petri網，對最終用戶來說，足可視化的圖形建模工具。為符合WfMC規范，工作流機裝入的模型用XPDL存儲，可使用XPDL和Petri網兩種表示形式，驗證是使用Petri網形式。

在Petri網的基礎上，Aalst提出了工作流網(WF-net)的概念，其定義如下：

一個Petri網PN=(P，T，F)被稱為工作流網，當且僅當它滿足下面兩個條件：

1)PN有兩個特殊的庫所：i和0。庫所i是一個起始庫所，即·i= ；庫所O是一個終止庫所，即O·= 。

2)如果在PN中加入一個新的變遷t，使t連接庫所。與i，即·t·={0)，t·={i)，這時所得到的PN是強連接的。

下面我們給出一個用工作流網定義工作流的簡單例子，例子描述的是軟件立項管理的工作流過程。

根據工作流網的基本定義，通過使用不同類型的基本組件和觸發機制，對立項管理進行建模，得到如圖1所示的工作流網模型。

基本流程如下：立項建議小組進行立項調查，然后進行項目構思和可行性分析，在完成之后進行立項申請，然后立項審查小組對此立項進行審查，決定是否同意立項。如果否決，則必須重新進行立項建議，如果同意立項，進入項目籌備階段，流程結束。

3系統設計

3．1設計思路

整個系統構架采用B／S模式，參照J2EE框架，主要分為四層：

1)展現層：主要包含客戶瀏覽器端和Web服務器端的applet，jsp和servlet，負責和用戶交互，接收數據，顯示結果等。

2)商業邏輯：用于處理展現層從用戶端接受到的數據，包含了控制應用處理的所有規則，同工作流執行服務通訊，并且將展現層和數據服務層連接起來。

3)工作流執行服務：是流程運行和管理的核心組件，包括工作流機和任務表管理器。

4)數據服務：負責提供對數據的存儲和讀取服務。

此外，在系統設計的過程中還采用了以下的技術：

1)J2EE框架

J2EE體系包括javaserverpages(JSP)，javaSERVLET，enterprisebean，WEBsevrice等技術，提供了一個企業級的計算模型和運行環境用于開發和部署多層體系結構的應用。它通過提供企業計算環境所必需的各種服務，使得部署在J2EE平臺上的多層應用可以實現高可用性、安全性、可擴展性和可靠性。J2EE中多數標準定義了接口，例如JNDI，JDBC等，這使得遵循這些標準的不同開發者之間的模塊可以無縫地互連。

2)JMS

JAVA消息服務(JMS)定義了Java中訪問消息中間件的接口。JMS只是接口，并沒有給予實現，實現JMS接口的消息中間件稱為JMSProvider。

在JMS中，每個客戶機連接到一個為發送和接收消息提供框架的消息傳遞程序?？蛻魴C需知曉消息格式和消息目的地。根據JMSAPI，消息傳遞分為兩種模式，點對點和／訂閱模式。

點到點消息傳遞方法使用下列工具，如消息隊列、發送方(或消息制作者)和接收方(或消息消費者)?？蛻魴C將發向特定接收方的消息發送到唯一的隊列。當接收客戶機從特定隊列抽取消息時，它發出確認消息，表明消息已處理。隊列將保留所有消息，直至接收方收到消息或消息到期。／預訂消息傳遞方法使用者、訂戶和主題的概念。客戶機將消息發送到主題或內容層次結構。為了接收到消息，消息消費者必須預訂此主題。因此，對于這種方法，可以將消息制作者作為者，而消息消費者則是訂戶。JMS供應商將多個者發來的消息分發到主題和此主題的多個訂戶。

點對點模式適用于使用集中式工作流機的系統，對于大規模的分布式應用，／訂閱模式則相當有效，但是，在保證各個分布式工作流機的一致性問題上則稍有難度。

3．2系統結構與功能特點

CMM軟件項目管理系統的系統結構如圖2所示，它主要由過程建模工具，工作流機，任務表管理器，web服務，客戶端和數據庫接口等組成，該系統的各功能特點是：在這個系統中，我們使用瀏覽器作為客戶端，通過Http請求與Webserver交互，Websevrer再將收到的請求加以處理，判斷哪些是應當丟棄的，哪些應該交由工作流執行服務處理，并將處理后的結果發送給工作流執行服務器。工作流機收到Webserver傳送過來的數據后，會根據消息的具體內容繼續執行流程或者將流程掛起或是結束流程的運行，并且更新任務表管理器的內容，在需要的時候調用相應的應用程序來完成任務的需要。在過程建模工具中建立，修改，刪除的模型將通過存儲過程來修改數據庫中已存儲的模型。

websevrer和工作流執行服務也都要通過存儲過程來訪問數據庫。各部分的功能特點描述如圖2。

1)建模工具：使用基于Petri網的建模方法來對企業經營過程進行過程定義，將經營過程轉化為工作流引擎可以執行的形式。同時還提供對過程模型進行分析，測試的工具。

2)工作流機：工作流引擎是工作流平臺的核心，它是業務流程的任務調度器，從某種程度上看，工作流機也是業務資源管理器。它的主要作用是實例化及執行過程模型、為過程和活動的執行進行導航、與外部過程交互完成各項活動、維護工作流控制數據和工作流相關數據等。

3)任務表管理器：過程模型中的每個活動都被看作是一個由計算機自動執行的任務或由用戶手動執行的任務，任務表管理器負責對這些任務的監視和維護。

4)Web服務：包含了用于處理用戶請求和顯示結果的jsp和sevrlet，其主要工作是將客戶端與工作流執行服務連接起來。

5)客戶端客戶端是基于瀏覽器方式的瘦客戶端，方便管理員管理整個工作流管理系統的運行過程，和一般用戶管理和執行分配給自己的任務。

6)數據庫接口：實現了底層的數據存儲，包括過程定義，工作流控制數據，工作流相關數據，企業組織模型等工作流管理系統運行過程中必須的信息。

4系統的一些實現技術

4．1任務的自動分配和觸發機制

可以根據模型定義自動地分配任務，當一個過程實例運行的時候，活動可以根據模型定義自動分配到指定接收者，并且，有關完成此活動所需要的數據也會傳遞給相應的接收者，從而提高業務過程執行效率。模型中使用角色機制，不指定具體人員，這樣，人員變更不至于引起模型的變動。系統支持遲后綁定，即可以在活動運行的時刻才確定此活動由誰來完成。

流程從使能到運行的控制，采用觸發機制，分為人工觸發、自動觸發、消息觸發和時間觸發。人工觸發一般是用戶從任務表中選取其中一項任務來完成，自動觸發是一些通過程序自動執行的過程，一旦使能就被觸發，消息觸發是指系統外部的消息到達觸發，如Email，時間觸發是由定時器來觸發。

4．2活動信息的統計

系統可以通過對活動信息統計，并將活動的運行狀況和統計信息存儲在數據庫內。通過提供有關工作量的信息，可以在建模的時候預測所需要的時間，并且在活動結束時計算任務完成情況，與初始模型進行對比，生成相應的圖表以判斷工作效率，輔助決策經營。除系統提供的幾個基本統計模型之外，用戶也可以利用系統提供的工具，自行擴展新的模型來完成工作量信息統計和生成對比圖表。

結論根據軟件過程管理的需求，以工作流技術為核心，J2EE技術為支撐，結合SPP模型，文章給出了一個軟件管理系統的體系結構和其中的一些技術實現。但是，為了更好地實施軟件過程控制和度量，我們發現，還有一些問題需要進行深入的研究。

首先，軟件過程模型的建立就要結合具體的實際情況，需要深人了解整個軟件過程，并根據不同的需要修改模型來完成資源的動態配置和管理。另外，關于分布式工作流機之間的通訊和一致性問題也是相當重要的問題，需要擬定合適的策略來實現資源優化調度。

軟件項目論文:項目管理理論中關于軟件項目外包采購管理的探討

摘要：本文分析了目前軟件外包采購管理的重要意義和目前的形勢，提出基于“雙贏”策略的軟件外包采購思想。在項目管理理論、CMM和ISO9000的基礎上，提出和細化了軟件項目外包采購管理的總體框架和具體操作內容。旨在通過對軟件外包項目采購的選擇購買、跟蹤與控制、評估驗收和項目后處理等過程的研究，來提高軟件外包采購的項目管理水平，滿足承包方對分承制方產品在質量、進度和成本等方面的要求和對外包過程的有效控制，為軟件項目外包采購管理人員提供具體的操作過程。

一、基本概念和背景

項目管理理論是一門綜合多門學科的新興研究領域，共有九大知識領域，包括項目集成管理、項目范圍管理、項目時間管理、項目費用管理、項目質量管理、項目人力資源管理、項目溝通管理、項目風險管理和項目采購管理。項目采購管理是指需要從執行組織以外獲得貨物和服務的過程。通常把貨物和服務稱為產品，把買方稱為業主或對應分承制方的總承包商，而賣方稱為承包商、廠商或供應商。項目采購管理一般包括以下主要過程：采購計劃編制，詢價計劃編制，詢價，承包商選擇，合同管理，合同收尾[ 1 ].對于軟件產品，一般采購可以分為兩大類，一類是對已經在市場流通的軟件產品進行采購。例如，某企業想做信息化建設項目，涉及到數據庫，那么它就可以在目前市面流行通用的幾種廠家和種類的數據庫中選擇。例如Oracle公司的Oracle數據庫，Microsoft公司的SQL Sever，IBM公司的DB2數據庫等等。然后根據自己的需求，通過詢價、簽合同、安裝培訓等過程來購買此類產品。這種采購過程基本已經形成幾套通用的解決方案，比較簡單，中國企業在處理這類產品的采購時，大部分都處理的較好。個別的企業由于需求分析不清晰，培訓工作不到位等原因，也會產生購買的產品不適用，或不會用的情況。另外一類軟件產品采購的形式是外包采購。它是指在市場上沒有出現現成的產品或者沒有適合自己企業需求的產品的情況下，需要以定制的方式把項目（功能模塊）承包給其他企業。例如某企業需要實施企業資源計劃項目（ERP），雖然可以購買BAAN軟件，但是基于本企業業務流程的管理軟件必須定制，對于各個原有孤立島的集成軟件，無法購買現成的產品，必須自己開發或外包給別的公司。

二、軟件項目外包采購管理的意義

許多大型復雜工程項目的實施需要業主、總承包商、分承制商、供應商和開發制造商等共同合作來完成。因此在任何甲方和乙方之間必不可少的涉及到部分子項目（功能模塊）的采購活動。目前社會中，企業的信息化、網絡化建設正在世界范圍內展開。誰先進行信息化改造，誰就早日適應社會發展的要求，獲得巨額利潤。大規模的企業信息化建設形成了龐大的軟件產品市場，促進了軟件業的發展。許多項目龐大復雜、高風險并且涉及高科技信息領域，在客觀上使企業需要采購和外包許多產品，包括軟件產品。主觀上，在經濟全球一體化形式下，這種外包采購作為采購活動的一種特殊的、更為復雜的形式，在企業中更為普遍存在。企業為了在日益競爭的社會環境中增強自身的核心競爭力，需要根據企業的特點，專門從事某一個領域或幾個領域的業務，在某個業務領域內形成自己的核心業務，把企業內部的智能和資源集中在那些有核心競爭優勢的活動上；把一些非自己擅長的業務領域的子項目和功能模塊外包給有實力和優勢的公司，才有利于加快項目的完工進度，降低風險，優化資源配制，保證項目質量，降低成本，創造更高的價值。

以電信行業為例，愛立信公司2000年底宣布把手機生產的絕大部分業務外包給新加坡的Flextronics公司，專注于移動通信網絡設備業務。原因是愛立信的移動通信網絡設備的銷售占愛立信公司銷售額的54%，利潤達90%以上，占有全球的移動通信市場分額高達30%，而手機生產的投資回報率很底，甚至出現虧損情況。對于愛立信而言，手機生產“外包”是在信息化時代的戰略調整，希望通過外包生產，調整投資結構，使手機降低成本并且盡快盈利，集中精力穩定和拓展電信業的新市場。出于同樣目的，美國的摩托羅拉公司也表示將外包部分地區的手機生產業務。作為手機市場份額最大的諾基亞，在專注于手機生產業務的同時，大力開發周邊產業。希望以手機業務帶動相關產業的發展。從三大公司的投資趨勢，可以看出，“外包”作為一種先進的國際專業化的生產方式正被一些大公司越來越多的采用。我國正處在信息化建設的高速發展階段，必然會有越來越多的企業由于自身的能力限制或業務發展的戰略選擇，將采取業務“外包”的生產方式。

就軟件項目外包采購的市場來說，2000年是企業信息化實施的第一年，國內企業，特別是大型企業的信息化項目開始運作。行業信息化改造重點將由原來的電信、金融、海關等行業轉向交通、制造、醫療等傳統行業。這些行業由于自身計算機技術水平和業務發展重點的原因，將會把大量的軟件項目外包給軟件公司。根據CCID的統計（軟件可以分成平臺軟件、中間軟件和應用軟件），2000年中國軟件市場中應用軟件的銷售額為147億元，占軟件總市場份額的63.9%.預計到2005年，計算機信息服務和軟件市場銷售額增長到1750億元。屆時我國軟件項目“外包”市場潛力可想而知。

三、軟件外包采購管理存在的問題

雖然在傳統行業，許多工程項目的采購活動，例如機械工程項目或建筑工程項目等等已經形成比較成熟的管理體制和標準。但是軟件項目的外包管理工作并不象其他行業那樣順利。

軟件工程項目管理引起廣泛注意源于20世紀70年代中期，當時發現70%的項目是因為管理不善而引起。20世紀90年代中期，美國的軟件開發仍然很難預測，大約只有10%的項目能夠在預定的費用和進度下交付。商用軟件通常只有9%（中小型軟件公司有16%）的軟件項目能夠及時交付且費用并不超支。

這里有多方面的原因：軟件產品作為一種特殊商品形式，具有高度不可測量性和高度柔性；軟件企業開發能力還不太成熟，軟件開發大多數還處于手工作坊方式，軟件研發企業有其自身的運做方式，人為因素比重大，不好量化管理。由于不確定因素太多，許多軟件開發企業對于自己的項目都難以精確控制進度、質量、資源和成本，那么對于業主來說，想對外部企業（例如分承制商）保持良好控制力的難度就更大了。再加上具有技術優勢的軟件開發商一般集中在幾個科技發達的大城市，與業主的距離遠，相互的交流不方便，因此許多軟件采購項目的實際應用效果都差強人意：不適用，進度超期，性能達不到標準，成本太高等等情況時有發生。

軟件項目外包采購的成功與失敗不僅僅影響到當前軟件項目的質量、成本和工作進度，而且關系到企業信息化建設整個項目的整體結構、性能以及進度，意義重大。特別是當軟件項目作為整體項目計劃關鍵路徑的一個環節，軟件項目采購的進度直接影響整體項目的進度，并且總成本將成指數級增加。由于軟件采購的情況特別復雜，涉及的學科領域不僅是科學技術上的，還有商業上的和觀念上的，軟件項目外包采購管理水平的高低，將直接關系到企業整個信息化建設進程。因此軟件項目采購管理作為項目管理理論中一個新的研究課題，有必要給予足夠的重視。

四、目前軟件外包采購管理情況

美國項目管理協會的“項目管理知識體系指南”（PMBOK）[1]、美國卡內基-梅隆大學軟件工程研究所的“軟件能力成熟度模型”（CMM）[2，3]和國際標準ISO9000-3[4]中雖然對外包采購管理的流程有過論述，但是他們指出的只是外包采購管理的一般原則；雖然人們可以結合自身企業特點實施標準，具有一定靈活性，但是事物的另一對立面就是操作過程不具體。這給軟件產品的外包采購管理者帶來具體操作上的困惑。另外PMBOK體系原則上是應用在各個行業的，缺乏針對軟件領域的特點做專門的論述。ISO 9000-3系列和CMM雖然是針對軟件領域的標準，但是ISO 9000-3的最大的特點是只告訴你要按規定做，不強調效果和后續改善，不強調經驗積累和后評估。從這個意義上講ISO9000注重水平的評估，不太強調提高企業成長的過程，因此對于提高企業的管理水平意義不大；CMM雖然旨在強調企業的過程能力的持續改進，但是它重點強調軟件的開發過程管理和產品管理，缺乏軟件的分發、轉交和服務等方面的管理標準，所以也有一定的局限性。

五、基于“雙贏”策略的軟件外包采購思想

本文作者在集成美國項目管理協會的“項目管理知識體系指南”（PMBOK）和美國卡內基-梅隆大學軟件工程研究所的“軟件能力成熟度模型”（SW- CMM，SA-CMM）和ISO9000-3中關于外包采購的宗旨的基礎上提出“雙贏”策略的軟件外包采購思想。

“雙贏”策略的軟件外包采購思想旨在利用雙方業務能力互補，通過共同合作完成軟件外包項目，達到“雙贏”的目的，促進雙方業務總體能力的提高。這種“雙贏”策略要求雙方在以下方面達成共識：雙方共同關注過程控制，才能保證有效結果；只能成功，不能指望依靠懲罰手段來收回采購成本，軟件外包采購項目的失敗對整個項目帶來的損失是巨大的；在合作過程中，建立對分承制商關系的管理體系，作為以后合作的基礎；重視開發過程的風險評估和采購項目后評估，使得雙方業務能力得到持續提高。

傳統的外包采購中，采購方只關心分承制商產品的進度和質量，以為只要分承制商按期、按質交貨，就可以圓滿結束此次采購活動。有些項目盡管前期進度和質量滿足合同要求，但是許多是以高投入、高負荷、高消耗等手段來保證的，這給后期帶來極高的風險。在階段評審中，如果采購方對分承制商開發過程中的費用投入、人員負荷、資源消耗、組織結構變化等漠不關心，因此就不能及早預見風險、控制風險。很難想象，后期在費用透支、人員疲憊或流失嚴重的情況下，分承制商仍能保證產品質量和進度。這種情況下，采購方只能要么加大投入，要么終止合同，并要求賠償，要么延期驗收等等。其副作用可想而知。而分承制商為了減少損失，根據博弈論中子博弈精練納什均衡原理，必然采取降低質量要求，減少投入的策略，來加快進度。結果最終還是采購方遭受損失。

六、軟件項目外包采購管理過程

為了保證軟件外包采購項目的順利進行，本文作者在上訴理論體系和“雙贏”采購策略的基礎上，提出和細化了軟件項目外包采購的總體框架和具體操作內容，旨在為軟件項目外包采購管理人員提供具體的可操作過程。

對于本采購過程，如果業主方由于行業、人員等原因，沒有健全的監控部門，可以聘請具有軟件監理職責的公司，或者總承包給具有一定軟件工程監控能力的公司。這時的總承包公司角色相當于本文提到的采購部。

軟件項目的整個外包采購過程可以分為十個工作階段，包括總體項目需求分析和設計、子項目的需求分析、廠商選擇、分承制商開發、業主階段評估、交驗測試、安裝、培訓、維護，后評價。

在開始外包采購之前，首先業主要完成項目的總體需求規格說明書和承包項目的需求說明書。一般承包項目的需求分用戶需求和分配需求。對于分承包商來說，業主對軟件項目所提出的需求通稱“用戶需求”。對于業主來說，系統總體分配給軟件的系統需求通稱“分配需求”。如何作好子項目的需求分析和管理，請參閱《軟件需求》，詳見參考文獻5.然后業主把需求說明書交給采購組組織采購。采購部門收到需求說明書后，再補充質詢調查表、報價指南、綜合條款及條件等文件，組成采購質詢技術文件發往廠商進行質詢。采購部門在廠商質詢的基礎上，準備了廠商選擇和投標估價等技術文件后，向業主送審，提請業主批準和確認所選廠商。在廠商選擇和投標估價這兩個文件中，采購部根據擬采購的軟件對被質詢的至少三家以上的供應廠商，就技術開發成熟能力、資源（包括以有的產品、硬件、軟件、信息和已經過的培訓）、資格和信譽、過去的合作關系、價格、提供的售后服務（包括培訓和維護）、分承制方組織配置結構、與質詢要求的差異等方面，經過經濟技術和商業戰略角度出發進行全面評估，經過其他各部門（例如系統工程組、軟件工程組、質保組、財務組）審核后，列出供應廠商的優劣次序，擇其優者為該項目的供應廠商。采購部一般以月為單位向業主通報軟件采購情況。一般以招投標方式或內部評審的方式來確定分承制商。

分承制商在接到采購部的定貨以后，就可以進行工作說明書、用戶需求說明書、軟件需求規格說明書、軟件開發詳細計劃和成本概預算、測試計劃、質量控制方法、風險控制、擬采用的軟件工程標準和軟件生命周期等文檔的制作。然后分承制商把有關的技術資料文件通過業主的采購部送給業主進行校核和批準，然后才能開始開發。

業主在接到分承制商的上述材料后，組織系統工程部、軟件工程部、質保部、財務部、采購部、法律部就上述材料中的開發項目視圖和需求范圍、使用或需要購買的軟硬件、進度計劃和成本、測試計劃與案例、使用的技術和工程標準、人員配置等進行評審，并出具評審文件和風險評估、控制建議書。并由采購部制定采購項目監督評估計劃書。合格后，由采購部、質保部及法律人員與分承制商簽署詳細的軟件采購子合同。如需要對軟件項目投保，以此來降低風險，需要和分承制商協商后，納入合同文件。

分承制商在簽署合同后可以進行設計和開發。業主應該委派采購部監督分承制商的工作。采購部應該有計劃的組織質保部、軟件工程部的項目計劃管理人員和配置管理人員，定期對分承制商的開發活動進度、質量、成本等進行評估，并形成評估建議書。送審業主方的系統工程部、項目管理人員、分承制商的此項目的負責人。分承制方的項目負責人要對評估建議書的建議進行書面回復，并確保實施。

分承制方對所有需要采購的資源（軟件、硬件、人力資源等）負責進行檢驗；采購部有權在任何時候對分承制商所采購的資源進行驗證，使之符合所采用的規格說明書、規范、標準和其他技術文件所規定的要求，確保分承制商?？顚Ｓ茫㈤_發環境。在這個階段之前，采購部門和分承制商首先要確定由分承制商提供的驗證建議書，并作好準備工作，提交檢驗用的技術文件，包括廠商說明書、設備性能數據表、配制清單、試驗程序、檢驗技術要求。在檢驗的物質條件和技術條件均已準備妥善后，分承包商就可以向采購部并通過采購部向業主提出書面檢驗申請。一般分承包商可以提前三周通知采購部，由采購部提前兩周以書面形式向業主提出檢驗申請，由業主召集系統工程部、軟件工程部、質保部組成驗證組，在規定的時間、地點檢驗。通過檢驗后，分承包商進入項目開發階段；業主進入監控和評估階段。對于重大關鍵項目，業主可以派遣項目監督員短期或長期進駐分承包商單位。

由于作為外部單位，業主不便時刻監督項目的開發過程。雖然理論上需要把分承制商看作是自己的一個項目部門來對待，納入自己的進度控制和質量控制體系，但是客觀上由于分承制商與業主距離較遠，人員不熟悉，各自有自己的企業文化和管理體制，雙方之間的信息溝通不暢，業主難以實時監督分承制商的開發進程和質量。最好的辦法就是在分承制商的軟件項目的各個里程碑處和分承制商一起進行檢查和評估。軟件項目一般可以劃分成若干個里程碑（3-5個為益），分承制商需要提前一周通知采購部組織相關人員來評估。軟件項目的里程碑一般指產品設計趨于穩定，中間產品定義趨于明晰，項目開發組真正了解項目實際的關鍵技術難度和可行的進度計劃，開發活動停止，產品進入除錯和穩定、隨時可以的階段，或當產品設計被刪減、資源增加、進度延誤的時候。在評估軟件質量、進度和功能的同時，還要評估分承制商的人員工作負荷程度、風險、費用和資源消耗情況，并形成文檔。由采購部送審系統工程部、軟件工程部、項目管理部和分承制商的此項目負責人。

當產品進入交驗測試的時候，分承制商需要提前三周通知采購部，采購部于前兩周通知業主作好交驗的組織評估準備工作。這時業主組織系統工程部、軟件工程部、測試部、質保部和采購部，根據分承制商和業主在分承制商開發階段預先共同定義、評審并批準的測試計劃和驗收方案進行驗收測試，對需求規格說明書中的各項逐個詳細的測試。最后以書面的形式給出對整個軟件項目的測試評估報告。并對未通過驗收測試的軟件產品指定相應的補救措施和計劃。分承制商交付給業主方的軟件產品應當包括：源代碼、軟件開發計劃、仿真環境、軟件需求規格說明書、設計文檔、軟件測試計劃、軟件測試說明、驗收測試計劃、軟件使用手冊、軟件安裝手冊、軟件維護手冊。必要的話，還包括相關培訓計劃。

軟件采購的一個重要階段是交貨，也是目前經常忽略的階段。當所采購的軟件產品以及硬件運行環境在規定的時間到達采購部時候，采購部要以書面的形式通知業主交貨。業主對所交的整個軟件產品清單進行驗收，并事先通知采購部拆箱日期，要采購部和分承包商的代表按時到場。業主要在接到采購部交貨通知后一個月內，對所檢查驗收的整個軟件產品（包括相關的軟件、硬件及其附屬產品、文檔、技術資料等子合同中規定的產品）出具一份交貨證明，如果這些提交的軟件產品沒有受到損壞并與裝箱清單相一致，并在業主方環境運行良好；否則出具一份書面通知，說明在某個方面此產品損壞或與裝箱單不符，或在業主方提供的環境運行不良。此通知或證明應由采購部和分承制商代表簽署。如果在簽合同的時候，就規定分承制商負責安裝和調試，則相應的過程省略。

最后業主方由采購部把所有的文檔歸類封存，以備后續類似項目采購的參考查詢。同時采購部在兩個月之內以書面形式，對分承制商的技術開發成熟能力、資源（包括以有的產品、硬件、軟件、人力資源和已經過的培訓）、信譽、分承制方組織配置結構，管理能力和企業文化提交后評價報告，作為建立客戶關系管理（CRM）的依據。對于此次采購的經驗和教訓，包括進度控制、質量控制、成本控制、客戶關系控制、流程控制、風險控制等方面，采購部以文檔的形式在組內討論并保存。

七、結束語：

作為大型工程項目中的軟件子項目或者部分功能模塊的采購（外包），由于軟件開發的固有特性（風險大，柔性強，人為因素突出，結果不宜測量等），使軟件項目的外包采購管理變得十分復雜。如何控制分承制商的開發進度和質量等關鍵因素，需要在實踐中不斷探索，并針對具體公司和項目對采購過程有所裁剪。

軟件項目論文:Project 軟件與水利工程項目管理

摘 要：本文介紹了Project軟件的主要功能及基本使用方法，分析了當前水利工程建

設中 Project 軟件的應用情況，闡明了 Project 軟件在水利工程項目管理中的重要性。

關鍵詞：水利工程建設；進度計劃；資源分配

1 Project 軟件在工程建設中的作用

Project 是一個項目管理網絡計劃軟件，它是基于關鍵路徑法(CPM)和項目評審技術(PERT)兩種技術，主要用于大中型項目的計劃制定、評審、優化、資源合理調配和現場動態跟蹤的通用的肯定型網絡計劃軟件包。Project 提供了一套完整的項目描述和計算的方法及模型，通過這個軟件生成圖、表或文件。

1.1 快速地建立項目計劃

建立項目計劃，需要完成一份正確的網絡計劃圖，這至少需要一個星期的時間進行設計、參數計算、核對、成圖。如果需要在原方案上做些修改，就不得不重新算一遍。耗費更多的時間、人力、物力、財力，無法適應當前飛速發展的形勢。Project則能把這些工作都承擔起來，能輕松愉快地完成項目計劃的制定工作。如果需要修改、增刪、優化，只需要把修改的地方輸入給 Project，它會按新的意圖重新計算，在幾秒內就給出結果。而且 Project 會自動計算出關鍵路徑，計算每個任務的時差和整個項目的開工、完工日期，告訴能否如期竣工，資源分配是否合理。

1.2 按工期管好項目中的任務

Project 把一個任務劃分為四個階段進行管理，即：比較基準計劃(原始計劃)、當前計劃、實際計劃和待執行計劃(剩余計劃或未完成計劃)。它為每個階段的計劃都設置了數據域，用戶隨時都可以查看。比較基準計劃$原始計劃’里的計劃數據記錄了最初制定項目計劃時項目的狀態情況。這個計劃數據在項目調整過程中始終保持不變，無論何時需要原始計劃數據時都可以從這個計劃數據域中得到。

當前計劃是根據實際已經發生的計劃和任務間的制約關系面計算出來的，它作為整個計劃的重點向用戶提供了極為詳細的數據。例如開始時間、完成時間、工期、總時差、自由時差、工作量、費用等。

實際計劃是指已經開始實施，但未完成或已經全部完成的任務計劃。Project 設置“實際計劃”數據域，可使用戶把已經完成的工作和未完成的工作區分開來。而且一旦一個任務的實際計劃生效，Project 會按實際計劃自動修正當前計劃。并且據此計算和預測整個項目計劃。

待執行計劃是需要完成的剩余工作量，Project 會根據完

成情況自動計算剩余工作量。

總之，用戶把采集到的項目任務完成和變動情況輸入到Project 后，系統就按項目實際發生的數據進行整個項目計劃的計算，確定新的關鍵路徑，預測整個項目前景，使得項目動態跟蹤就變得非常容易。

1.3 對人員設備和資金資源進行分配

Project 把在完成項目任務活動中投入的人員、機械臺班設備和材料、資金等抽象化為“資源”，建立起資源庫。Project根據每個任務的資源使用情況計算整個項目的資源需求曲線，自動指出“超負荷分配”發生在那些任務上，能夠幫助用戶自動進行資源平衡，并能自動排出每個資源承擔的任務上的日程、工作量和成本表。

1.4 提供豐富圖表

Project 提供了與國際上接軌的單代號網絡圖，中國科學院計算所在 Project 配套的軟件 “中文伴侶”中開發了雙號網絡圖處理系統。

Project 把橫道圖和表結合在一起，這樣既能以圖形方式形象地查看任務信息，又能看到具體的數據，便于理解項目。橫道圖上不僅可以顯示出工序的關系線，而且工序信息也可直接顯示在橫道條的四周。

資源圖是以反映資源使用狀況為重點的信息，Project 為資源分析和跟蹤提供了8種圖形，即：資源需求曲線圖、資源工作量圖、資源累計工作量圖、超分配工作量圖、資源已經分配的百分數圖、資源當前可用工作量、成本圖、累計費用圖。

總之，Project 提供項目各個方面信息，使項目的管理更高效有序。無論用于項目投標、項目計劃的組織施工，還是對工程項目實行監理都是一個不可多得的軟件。

2

Project 與山西水利建設

近年來，我省的水利事業發展良好，按國家規定逐步實行了項目法人責任制、招標投標制、工程監理制，使工程項目管理日趨規范化。

隨著計算機技術的迅猛發展，應用計算機進行管理已成為必然。然而，在我省大多項目管理仍延用傳統的方式，依賴自己的老經驗，總認為不使用計算機輔助管理，工程也照樣能進行下去。盡管絕大多數項目部都購買了計算機，但大多數單位使用它打字、制表，由人工畫道改成“計算機畫道”，計算機沒能發揮出其強大優勢。項目施工單位用手工編制項目計劃不僅要耗費大量的時間及人力，而且經常是工程已經開工，計劃還沒有做好，使計劃管理總處于被動局面。然而，計算機在優化進度計劃方面及時、快速、準確、便捷等特點是人工無法比擬的。針對傳統管理的弊端，Project中文版為項目管理人員提供了眾多有實用價值的功能，以及簡單且方便的解決方法，使生產計劃人員能高效地處理這些變化。

在我國許多建筑單位選擇了Project，在應用過程中普遍反映這個軟件操作簡單，更改、調整非常方便，確實體會到該系統在建筑項目計劃的制定管理與信息交流等方面的強大功

能，嘗到了先進管理方式的甜頭，認識到工程項目施工中開展全面的計算機應用，實在是非常必要的。

在我國市場經濟發展日益完善的今天，建筑施工行業也面臨著優勝劣汰的競爭選擇。在激烈的市場競爭中，不允許任何企業偏安于一隅，任何一個擁有關鍵技術的小企業，都可以在很短時間里迅速成長為區域性的大企業，技術和管理的創新日益成為企業間競爭的根本，而一些大的水利工程已率先引用了先進管理軟件，如我省的引黃工程，利用P3作管理軟件。水利水電監理公司利用自己研制的軟件進行監理控制等。這僅僅是一個開始，我們應在掌握原有技術、經驗的基礎上，利用先進的管理軟件進行高效管理，這應該是山西水利發展方向。當然，把計算機用于工程項目施工管理不是一個簡單問題，對于選擇什么樣的工程項目管理軟件也是非常重要的。每項目工程都有各自的特點，Project作為微軟的最新項目管理產品，國外項目管理的首選軟件，在應用過程中，針對工程中的不同特點也會表現出一定的不足，但計算機用于工程項目施管理已成為發展的必然趨勢。計算機的強大功能必須得到充分發揮。這是我省水利項目管理的需要，也是水利事業發展的必然趨勢。

6

Project在工程建設中的前景展望

目前我國采用計算機進行工程項目管理的建筑施工單位還不太多，這主要是由于有些人還沒有認識到這個問題的重要性，有些人還沒有找到正確的方法，沒有建立和制定一套完整的適應計算機管理特點的管理體制，同時也說明把計算機用于工程施工管理不是一個簡單問題，它需要多方面的基礎知識和技能，需要從多方面努力。

科學技術是第一生產力，項目管理科學化是大勢所趨。Project軟件憑借其在項目管理方面所起的顯著作用，以及其操作簡單，跟蹤調整方便等特點，已在中國建筑市場占了一席之地，尤其是Project2000版的推出，使操作更為簡單、快捷，人機界面更趨完善，功能更為強大，這必將推進我國的工程項目管理進行一場高科技的改革，使其逐步與國際慣例接軌。現在已經有越來越多的人在關注這個軟件，國家也十分重視科技的推廣，尤其是水利部，專門組織培訓班，對全國水利單位人員進行Project項目管理軟件培訓，這將極大地推動軟件在水利行業的推廣應用。據說水利部將把是否利用Project軟件進行項目管理，是否有專職人員進行過Project軟件培訓，作為監理資質評審的條件之一，這充分體現了國家對該軟件的重視，這也將有利Project軟件在全國范圍內的推廣，該軟件在國內推廣將展現光明光景

軟件項目論文:關于軟件項目管理流程分析與設計

論文摘要：針對軟件項目和項目開發中的復雜性、易變性和不可預見性，研究了軟件項目管理流程方法設計了軟件項目運作過程的總體流程，分析了各階段流程的進入條件、主要工作過程和工作結果

論文關鍵詞：軟件過程；軟件項目管理；流程管理

1引言

長期以來，軟件項目高失敗率的狀況一直困擾著人們，研究表明，軟件項目失敗的原因主要有兩個：一是應用項目的復雜性；二是缺乏合格的軟件項目管理人才。實踐證明缺乏有效的項目管理是導致軟件項目失控的直接原因。軟件開發的風險之所以大，是由于軟件過程能力低，其中最關鍵的問題在于軟件開發組織不能很好地管理其軟件過程，從而使一些好的開發方法和技術不能起到預期的作用。

流程管理作為現代企業管理的先進思想和有效工具，隨著市場環境與組織模式的變化，在以計算機網絡為基礎的現代社會信息化背景下越發顯示出其威力和效用。流程管理不僅是一種管理技術，更體現了現代管理的思想。流程管理的重點是：理清和管理好所有主、支流程間的關系，使他們相互協調發揮應有的作用。流程管理增加了部門的透明度，管理的對象不是“部門”和“部門員工”的概念，而是以工序流程為管理對象，注重流程中每一個過程和效率以及和上下游工序的關系，管理重點在于整體流程的完整性和順暢性。目前，流程管理技術的研究已越來越受到人重視。

運用流程管理方法和技術進行軟件項日管理，可以有效地改變軟件過程管理混亂的局面首先塒軟件項目開發過程進行有效的、規范化的定義；其次，在軟件項目開發過程中，所有的活動過程均按照流程所規定的活動的邏輯關系、活動的實現方式來執行，這樣可以使得所有的活動有序和可控；第三，通過明確運作流程，使項目組人員迅速融入項目和開發過程中；第四，關注每個過程的“結果”，使軟件項目的所有工作產品均能得到有效的保存，保證了軟件產品完整性。

2流程的概念及在軟件項目管理中的作用

流程是由活動組成的?；净顒邮怯蓚€人或團體來完成的，它不需要進行其他的基本活動的轉化。流程的各個活動之間有著特定的流向，它包含著明確的起始活動與終止活動，因此是一個動態的概念。從結構上來看，流程有四個基本的構成因素：活動、活動的邏輯關系、活動的實現方式和活動的承擔者。流程與“一系列的活動或事件”，“結果”等概念密切相關。流程管理不僅是一種管理技術，更體現了現代管理的思想，原有的以控制、塔式組織為基礎的職能行政管理已經不能完全滿足于現代企業發展和市場競爭的需要，管理的發展沿著分工理論運行了上百年后，現在又重新回歸到整合與系統。

軟件項目生命周期的一系列的開發過程是各種各樣的流程活動：軟件項目的計劃編制、系統分析、慨要設計、詳細設計、程序編碼、測試與維護等活動過程都是一種流程活動：制定軟件項目管理流程，重點考慮以下幾點：

1)制定的流程能引導項目逐步走向成功；

2)制定的流程能適用軟件開發過程；

3)制定的流程能指導項目開發活動．有利于對項日開發活動的管理；

4)制定的流程能以苴觀的流程圖表示．能使項目組成員清楚的知道軟件開發與管理的過程和相互之間關系；

5)流程中的起始活動條件、終止活動條件明確、規范便于控制：

6)流程中的工作產品定義明確、可度趟，評價標準和方法具體、可操作

3軟件項目管理總體流程設計

在軟件項目開發管理過程中，不儀要努力實現項目的范圍、時間、成本和質量等目際，還必須協調整個項目過程，以滿足項目參與者及其他利益柑關者的需要和期望；隨著軟件規模和所涉及的領域不斷地擴大，軟件項目的管理越來越困難，縱觀所有失敗的軟件項目．基本原因是不能管理其軟件過程，在無紀律的、混亂的項目狀態下，組織不可能從較好的方法和工具中獲益。嚴謹的軟件過程控制管理不僅可以在每個階段回顧和糾正項目的偏差．別軟件項目的風險甚至果斷中止項目。且可以將人才流動所帶來的不利影響減少到最小。要進行有效的過程控制，必須明確軟件項目管理流程。

軟件項目管理總體流程設計為項目搜尋、立項、售前合同生成和合同執行等5個主要階段，分別以Pl、P2、P3、P4、P5表示；同時設計了立項完成、合同簽定、功能定義、軟件開發、項目驗收等5個里程碑，分別以TM1、TM2、TM3、TM4、TM5表示，如圖l所示。在這些流程中，合同執行流程是軟件項目管理的核心，其主要過程有：產品定義、軟件開發、測試執行、內部驗收、項目實施與驗收、項目維護．

4軟件項目管理總體流程分析

4．1項目搜尋

項目搜尋是項目立項的基礎，項目搜尋階段的主要任務包括市場信息收集，用戶需求跟蹤，對潛存的項目進行分析和篩選。

4．2項目立項

立項階段的主要任務是確認立項的理由，提出立項建議，提供合適的資金和資源，使立項建議成為正式項目。

4.3項目售前

售前階段從項目立項開始到項目合同的簽定結束，主要工作有：制定與客戶的交流計劃，詳細了解客戶的背景資料，了解客戶啟動項目的緣由、目的和期望，編制項目方案建議書，準備合同藍本。

4.4合同生成

合同生成階段的主要工作有：項目方案的評估與確定技術合同、商務合同的商定、評估與簽署。

4．5合同執行

合同執行是軟件項目管理流程的重點，可分為軟件開發、測試執行；內部驗收、項目驗收、系統維護等五個基本工作過程。

4.5．1軟件開發

軟件開發階段分為：需求調研、系統分析、系統設計、編碼、單元測試等過程。主要從三個方面進行管理：

1)制定項目計劃。軟件項目計劃是一個用來協調所有其他計劃，以指導項目執行和控制的可操作文件。它體現了對客戶需求的理解，是開展項日活動的基礎，也是軟件項目跟蹤與監控的依據。

2)確定開發過程。根據軟件項目和項目組的實際情況，建立起一個穩定、可控的軟件開發過程模型，并按照該過程來進行軟件開發

3)加強過程控制一過程控制主要包括過程管理、變更控制和配置管理，、

4．5．2測試與執行

項目測試的目的是儉查系統是否符合項目合同與任務書規定的要求、項目測試分集成測試和系統測試，主要進行功能測試、健壯性測試、性能一效率測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝／反安裝測試等測試過程在模擬運行環境中進行。

4.5.3內部驗收

項目完成集成測試和系統測試后進行項目內部驗收．主要有三個步驟：①文檔準備。項目經刪提交內部驗收計劃、項目開發總結報告、產品清單：財務主管提交項目財務預算報告。②內部驗收測試。內部驗收測試的測試內容與方法雖然與系統測試基本相同．但應站在用戶驗收的角度進行，因為它是試運行的基礎。通過這一步。為用戶驗收作充分的準備。③內部評審。對提交的所有文檔及測試結果進行內部評審，完成項目開發總結報告：

4，5，4項目試運行與驗收

試運行與用戶驗收階段的主要任務是，使所有的工作產品得到用戶的確認。主要工作有：①驗收前的準備。項目經理負責檢查產品的完整性。包括文卡當、介質和中間產品等，以確?，F場實施的成功；負責應用軟件的現場安裝調試，完成安裝調試總結報告；負責制定用戶驗收計劃，并得到客戶的確認。②用戶進行驗收測試和系統試運行，進行文檔和系統的移交。③用戶確認。項目經理負責與客戶協測，協助用戶進行項目驗收，形成用戶驗收報告。

4 5．5項目維護

軟件系統的維護分為兩大類：一類是糾錯性維護，由于前期的測試不可能暴露軟件系統中所有潛在的和隱含的錯誤，診斷和改正這些錯誤的過程為糾錯性維護。另一類是完善性維護，在軟件正常使用過程中，用戶還會不斷地提出新的需求，為了滿足用戶新的需求而增加軟件功能的活動稱為完善性維護。如果需求變更很大，那完善性維護將轉變為軟件新版本的開發。系統維護的宗旨就是提高客戶對軟件產品的滿意度。確保系統的正常運行是系統維護的根本目的。

4．6軟件項目管理的里程碑

項目的考核與評審是軟件項目管理流程控制的基礎，我們在整個流程中設定五個基線，即確定五個里程碑，它們分別是TM1：立項完成；TM2：合同簽訂；TM3：產品功能定義完成；TM4：軟件開發完成；TM5：驗收通過。

如圖1所示。各階段的主要的進入條件和相應的工作結果是里程碑是否達到的重要標志。

5結束語

本文設計的軟件項目管理總體流程及相關技術已成功運用在軟件項目的研發和管理中。通過將流程管理應用于軟件項目管理中，以設定軟件項目總體流程為主線，確定每個階段的主要流程和里程碑，并采用評價指標體系和一系列的模板和表格進行軟件項目開發過程的控制和管理，使軟件項目的成功率顯著提高。

實踐證明，針對企業和項目的實際情況，確定軟件項目運作流程，定義軟件工作產品，明確各階段的進入條件和退出條件，進行有效的流程控制與管理，大大的提高了軟件開發的效率和項目的成功率。

軟件項目論文:關于工作流的軟件項目管理系統的設計與實現

論文摘要：本文介紹了一個基于工作流技術而研制的軟件項目管理系統。文章首先描述了傳統軟件項目管理系統的不足之處，提出用工作流的方法來設計軟件項目管理系統，然后介紹了一些理論基礎。文中重點闡述了系統的設計結構和所采用的一些技術，并給出了部分的具體實現方法。

論文關鍵詞：工作流，JMS，項目管理，SPP，建模，工作流網

1前言

2O世紀7O年代以來，為了解決軟機危機，改進軟件過程能力，計算機科學家提出了軟件工程的概念，將系統化的、規范化的、可度量的方法用于軟件開發、運行和維護的過程。近些年來，隨著計算機技術的進一步發展，相應的使用軟件工程方法的軟件項目管理系統也有了顯著的發展。但是，由于開發流程中存在的不確定性以及項目變化等因素，這些系統也暴露出一些不足之處。

傳統的軟件項目管理系統，一般是由圖形用戶接口(GUI)，應用程序和數據庫組成，用戶通過GUI向應用程序發出請求，應用程序處理這些用戶請求，并且訪問數據庫，返回用戶所要求的結果。這種模型在流程穩定的時候是可以滿足需要的，它的缺點在于：

1)建模過程是之前設定好的，無法改變；

2)缺乏柔性，系統開始運行之后，預先定義好的條件就無法改變了；

3)可擴展性較差，如果想要增加或者修改相應的功能，整個系統必須重新開發。

目前，對工作流技術的研究以及相關產品的開發是國內外學者研究的熱點問題之一，很多管理系統都采用工作流技術來克服上述問題。工作流起源于生產組織和辦公自動化領域，它是針對日常工作中具有固定程序的活動而提出的概念。目的是通過將工作分解成定義良好的任務、角色，按照一定的規則和過程來執行這些任務并對它們進行監控，達到提高辦事效率、降低生產成本、提高企業生產經營管理水平和企業競爭力的目標。

WFMC給出的工作流定義是：工作流是一類能夠完全或者部分自動執行的經營過程，它根據一系列過程規則，文檔、信息或任務能夠在不同的執行者之間進行傳遞與執行，以實現整體的業務目標。而這正適合于軟件開發過程管理，基于上述的理由，我們結合江蘇省十．五攻關“工作流技術的研究和應用”項目，研究并開發了基于工作流的軟件項目管理系統CMMFlow，目前已應用于軟件能力成熟度模型(CMM)的管理，其效果相當良好。

2理論基礎

2．1 CMMI3級精簡并行過程(SPP)模型

利用工作流技術可以設計和建立一個工作流環境，在此系統中，我們使用CMMI3級精簡并行過程(SPP)模型來支持軟件過程實施。

SPP把產品生命周期劃分為產品概念、產品定義、產品開發、產品測試、用戶驗收和產品維護等6個階段，包含項目管理、項目研發和機構支撐等3類過程、19個過程域。其中項目管理過程包含立項管理、結項管理、項目規劃、項目監控、風險管理和需求管理等六個過程域；項目研發過程包含需求開發、技術預研、系統設計、實現和測試、系統測試、Beta測試、客戶驗收和項目技術評審等8個過程域；機構支撐過程包含配置管理、質量保證、培訓管理、外包與采購管理以及服務與維護等5個過程域。

我們把每一個過程域都看成是一個流程，其中過程域之間的關系是線性為主，并行、迭代為輔。每個過程域包含若干原子活動。通過建立活動與角色以及角色與具體用戶的關聯，即可建立一個可執行的業務過程模型。

2．2基于petri網的可視化建模工具

在這個系統中，我們的建模工具是使用工作流網和XP—DL共用的策略，采用的是擴展的Petri網，對最終用戶來說，足可視化的圖形建模工具。為符合WfMC規范，工作流機裝入的模型用XPDL存儲，可使用XPDL和Petri網兩種表示形式，驗證是使用Petri網形式。

在Petri網的基礎上，Aalst提出了工作流網(WF-net)的概念，其定義如下：

一個Petri網PN=(P，T，F)被稱為工作流網，當且僅當它滿足下面兩個條件：

1)PN有兩個特殊的庫所：i和0。庫所i是一個起始庫所，即·i= ；庫所O是一個終止庫所，即O·= 。

2)如果在PN中加入一個新的變遷t，使t連接庫所。與i，即·t·={0)，t·={i)，這時所得到的PN是強連接的。

下面我們給出一個用工作流網定義工作流的簡單例子，例子描述的是軟件立項管理的工作流過程。

根據工作流網的基本定義，通過使用不同類型的基本組件和觸發機制，對立項管理進行建模，得到如圖1所示的工作流網模型。

基本流程如下：立項建議小組進行立項調查，然后進行項目構思和可行性分析，在完成之后進行立項申請，然后立項審查小組對此立項進行審查，決定是否同意立項。如果否決，則必須重新進行立項建議，如果同意立項，進入項目籌備階段，流程結束。

3系統設計

3．1設計思路

整個系統構架采用B／S模式，參照J2EE框架，主要分為四層：

1)展現層：主要包含客戶瀏覽器端和Web服務器端的applet，jsp和servlet，負責和用戶交互，接收數據，顯示結果等。

2)商業邏輯：用于處理展現層從用戶端接受到的數據，包含了控制應用處理的所有規則，同工作流執行服務通訊，并且將展現層和數據服務層連接起來。

3)工作流執行服務：是流程運行和管理的核心組件，包括工作流機和任務表管理器。

4)數據服務：負責提供對數據的存儲和讀取服務。

此外，在系統設計的過程中還采用了以下的技術：

1)J2EE框架

J2EE體系包括javaserverpages(JSP)，javaSERVLET，enterprisebean，WEBsevrice等技術，提供了一個企業級的計算模型和運行環境用于開發和部署多層體系結構的應用。它通過提供企業計算環境所必需的各種服務，使得部署在J2EE平臺上的多層應用可以實現高可用性、安全性、可擴展性和可靠性。J2EE中多數標準定義了接口，例如JNDI，JDBC等，這使得遵循這些標準的不同開發者之間的模塊可以無縫地互連。

2)JMS

JAVA消息服務(JMS)定義了Java中訪問消息中間件的接口。JMS只是接口，并沒有給予實現，實現JMS接口的消息中間件稱為JMSProvider。

在JMS中，每個客戶機連接到一個為發送和接收消息提供框架的消息傳遞程序。客戶機需知曉消息格式和消息目的地。根據JMSAPI，消息傳遞分為兩種模式，點對點和／訂閱模式。

點到點消息傳遞方法使用下列工具，如消息隊列、發送方(或消息制作者)和接收方(或消息消費者)?？蛻魴C將發向特定接收方的消息發送到唯一的隊列。當接收客戶機從特定隊列抽取消息時，它發出確認消息，表明消息已處理。隊列將保留所有消息，直至接收方收到消息或消息到期。／預訂消息傳遞方法使用者、訂戶和主題的概念?？蛻魴C將消息發送到主題或內容層次結構。為了接收到消息，消息消費者必須預訂此主題。因此，對于這種方法，可以將消息制作者作為者，而消息消費者則是訂戶。JMS供應商將多個者發來的消息分發到主題和此主題的多個訂戶。

點對點模式適用于使用集中式工作流機的系統，對于大規模的分布式應用，／訂閱模式則相當有效，但是，在保證各個分布式工作流機的一致性問題上則稍有難度。

3．2系統結構與功能特點

CMM軟件項目管理系統的系統結構如圖2所示，它主要由過程建模工具，工作流機，任務表管理器，web服務，客戶端和數據庫接口等組成，該系統的各功能特點是：在這個系統中，我們使用瀏覽器作為客戶端，通過Http請求與Webserver交互，Websevrer再將收到的請求加以處理，判斷哪些是應當丟棄的，哪些應該交由工作流執行服務處理，并將處理后的結果發送給工作流執行服務器。工作流機收到Webserver傳送過來的數據后，會根據消息的具體內容繼續執行流程或者將流程掛起或是結束流程的運行，并且更新任務表管理器的內容，在需要的時候調用相應的應用程序來完成任務的需要。在過程建模工具中建立，修改，刪除的模型將通過存儲過程來修改數據庫中已存儲的模型。

websevrer和工作流執行服務也都要通過存儲過程來訪問數據庫。各部分的功能特點描述如圖2。

1)建模工具：使用基于Petri網的建模方法來對企業經營過程進行過程定義，將經營過程轉化為工作流引擎可以執行的形式。同時還提供對過程模型進行分析，測試的工具。

2)工作流機：工作流引擎是工作流平臺的核心，它是業務流程的任務調度器，從某種程度上看，工作流機也是業務資源管理器。它的主要作用是實例化及執行過程模型、為過程和活動的執行進行導航、與外部過程交互完成各項活動、維護工作流控制數據和工作流相關數據等。

3)任務表管理器：過程模型中的每個活動都被看作是一個由計算機自動執行的任務或由用戶手動執行的任務，任務表管理器負責對這些任務的監視和維護。

4)Web服務：包含了用于處理用戶請求和顯示結果的jsp和sevrlet，其主要工作是將客戶端與工作流執行服務連接起來。

5)客戶端客戶端是基于瀏覽器方式的瘦客戶端，方便管理員管理整個工作流管理系統的運行過程，和一般用戶管理和執行分配給自己的任務。

6)數據庫接口：實現了底層的數據存儲，包括過程定義，工作流控制數據，工作流相關數據，企業組織模型等工作流管理系統運行過程中必須的信息。

4系統的一些實現技術

4．1任務的自動分配和觸發機制

可以根據模型定義自動地分配任務，當一個過程實例運行的時候，活動可以根據模型定義自動分配到指定接收者，并且，有關完成此活動所需要的數據也會傳遞給相應的接收者，從而提高業務過程執行效率。模型中使用角色機制，不指定具體人員，這樣，人員變更不至于引起模型的變動。系統支持遲后綁定，即可以在活動運行的時刻才確定此活動由誰來完成。

流程從使能到運行的控制，采用觸發機制，分為人工觸發、自動觸發、消息觸發和時間觸發。人工觸發一般是用戶從任務表中選取其中一項任務來完成，自動觸發是一些通過程序自動執行的過程，一旦使能就被觸發，消息觸發是指系統外部的消息到達觸發，如Email，時間觸發是由定時器來觸發。

4．2活動信息的統計

系統可以通過對活動信息統計，并將活動的運行狀況和統計信息存儲在數據庫內。通過提供有關工作量的信息，可以在建模的時候預測所需要的時間，并且在活動結束時計算任務完成情況，與初始模型進行對比，生成相應的圖表以判斷工作效率，輔助決策經營。除系統提供的幾個基本統計模型之外，用戶也可以利用系統提供的工具，自行擴展新的模型來完成工作量信息統計和生成對比圖表。

結論根據軟件過程管理的需求，以工作流技術為核心，J2EE技術為支撐，結合SPP模型，文章給出了一個軟件管理系統的體系結構和其中的一些技術實現。但是，為了更好地實施軟件過程控制和度量，我們發現，還有一些問題需要進行深入的研究。

首先，軟件過程模型的建立就要結合具體的實際情況，需要深人了解整個軟件過程，并根據不同的需要修改模型來完成資源的動態配置和管理。另外，關于分布式工作流機之間的通訊和一致性問題也是相當重要的問題，需要擬定合適的策略來實現資源優化調度。

軟件項目論文:應用P3軟件為建設項目管理服務

摘要：三峽工程是一舉世囑目的工程建設項目，項目管理的任務其中包括進度控制的任務極其艱巨。業主單位確定應用P3軟件作為進度控制的輔助工具已近五年時間，取得了很大的成績，但還存在有待改進的地方。筆者有幸從93～96年，涉及此方面的工作，對合理地應......

關鍵詞：P3 建設項目 管理 服務

三峽工程是一舉世囑目的工程建設項目，項目管理的任務其中包括進度控制的任務極其艱巨。業主單位確定應用P3軟件作為進度控制的輔助工具已近五年時間，取得了很大的成績，但還存在有待改進的地方。筆者有幸從93～96年，涉及此方面的工作，對合理地應用P3強大的功能為項目管理，尤其是項目進度控制服務，提一點自己的看法?，F分述如下，作為拋磚引玉供有關部門參考。

1 統一規定網絡進度計劃的表達形式

三峽工程因其規模宏大，需要采用分項直接承發包制，業主將與多個獨立的承包商建立合同關系，如果承包商們在進度計劃表達形式上不統一，各自采用他們習慣的表達形式，對單個合同可能是可行的，但對整個三峽工程的進度控制而言，將產生混亂的而導致無法進行。

網絡計劃的類型有肯定型、非肯定型，隨機型、循環型等。在土建行業大多采用稱作關鍵線路法的肯定型計劃網絡。而該類型計劃網絡以其表達形式來分有：雙代號、單代號、與單代號搭接網絡等表達形式。從業主與監理方使用的網絡計劃大多是控制性進度網絡，以及考慮到工程建設項目的復雜程度與P3軟件所能支持網絡計劃的類型而言，以采用單代號搭接網絡最合適。由于它表達相同的計劃對象時，可以具有網絡的規模最小，表達最為簡潔的好處。因為它可免除用其肯定型計劃網絡時，為了表達活動之間的邏輯關系而需要增加虛活動和要把完整的須加細分的敝端。關于規定統一用搭接網絡的建議，必須取得建設各方的共識，并共同執行。只有這樣，才能把進度管理，納入統一的、可操作的進度控制模型之內。

2 分析管理環境，合理確定進度計劃網絡整體結構

進度計劃網絡的整體結構是指進度網絡系統中整個局部網絡之間聯系方式不同劃分結構類型。

在選擇進度計劃網絡的整體結構形式的時候，必須根據建設項目特點與管理模式出發予以考慮。從三峽工程業已招標發包的合同看，有的一個合同包含了若干個單項工程(如右岸一期工程合同)；有的則一個擴大單位工程包含了若干項合同，如永久船閘工程。因此，業主項目與監理單位均處在多個合同管理環境下工作。這大大增加了項目管理的難度與工程協調工作量。我們在確定網絡計劃整體結構時，都要與上述多項目管理環境相適應，并充分利用P3軟件所能提供的功能為前提。

關于進度計劃網絡的整體結構，可分為兩類，一類是多級網絡，如以三級網絡為例，其示意圖見圖1。

圖1 多級網絡示意圖

個工作(或稱活動)。因此，分解的詳細程度會直接影響網絡計劃中活動數目。過于詳細，則增大網絡圖的圖幅，不利于閱讀與管理；分解得過粗，則對進度控制缺乏必要的指導作用。WBS分解的詳細程度應考慮如下因素：

(1)WBS分解的詳細程度要與計劃進度的功用相協調，業主方的計劃進度主要用于進度控制，宜粗些。通常分解到分部工程(最多到分項工程)的層次即可；對承包商實施性的進度計劃所需的CWBS，可由承包商對其合同范圍工程，在業主方WBS框架基礎上根據需要，再自行細分；

(2)WBS的框架結構，要兼顧工程分標的具體要求。如永久五級船閘輸水工程，宜將其再分成上游輸水工程與下游輸水工程，以避免出現一個分解單元跨兩個合同的情況；

(3)分解的詳細程度，對整個工程各部份要做到基本一致，以便能正確確定網絡計劃中各活動之間的邏輯關系；

(4)WBS分解的詳細程度應使之對應的活動，在施工現場較易識別，有利于進度檢查與進度控制工作。

總之，WBS分解結構應有利于建設項目進度控制與其他項目管理的需要。

3.2 建立工程項目管理的組織分解結構(OBS)

為使項目管理機構管轄范圍清晰、職責分明，常用組織分解結構描述業主方管理機構的設置。并把它與WBS終層次的分解單元對應起來，即把WBS垂直樹與OBS水平樹按項目管理組織的管轄范圍，得出對應的交叉點，以明確其責任主體。OBS的詳細程度可分至具體責任人。

3.3 建立為項目管理服務和方便P3應用的代碼體系

設計出一好的代碼體系與代碼方案對于項目管理及相關軟件高效應用至關重要，它可使諸如統計、分類、校對、查詢、計劃的整合、計劃的拆分、數據組織、過濾等工作變得簡單方便。由于限于文章篇幅僅列項說明如下：

(1)為擬訂好WBS框架，建立統一的工程分解結構代碼符與詞典。并在最高層主網上輸入，以便為各層主、子網所共亨。

(2)為擬定好OBS框架，建立統一的組織分解結構代碼符與詞典，并在最高層主網上輸入，以便為各層主、子網所共亨。

(3)依照三峽工程分標設計，統一規定合同代號，并建立詞典。

(4)約定各標合同項目活動代碼，在單代號搭接網絡模型下，活動代碼為網絡中節點代碼，從活動代碼易于做到唯一性的易于閱讀網絡圖，建議活動代碼的前兩位為字母型(與合同代號一致)，后4位為數字型混合碼為宜。后4位阿拉伯數字均以0、5數字結尾，以便為以后網絡中增加活動留地。

(5)約定活動分類碼

活動分類碼實質上是把某些特性用活動分類碼的形式加以識別。P3可為活動提供20個分類碼，這些活動分類碼可以識別諸如：活動屬何種工程；活動所在的工程部位、高程；活動的承包單位；活動的監理單位；活動的業主管理單位；施工活動還是管理性質活動；以及想要識別的其它特性。業主方統一建立活動分類碼(包括代碼結構、碼值與詞典)供參與工程建設的有關單位所共亨。

(6)制定統一資源類別代碼

制定統一資源類別代碼的結構、碼值與詞典，資源包括：資金、勞力、各種材料、各種專用施工設備等。制定統一資源類別代碼，使各承包商以統一的代碼把資金、勞力、各種材料、各種專用施工設備的需要量載入網絡之中，不僅為承包商編制施工資源、配置計劃提供依據，同時也為業主方通過主～子網絡結構匯總各種資源的總量及其在時間上的分配提供方便。為業主的材料、設備的采購與供應，資金籌措，施工現場管理等提供信息支持。為了減少這方面的工作量，可僅對業主關心的資源進行，對承包商關心的資源可在其子網絡上自行定義。

4 制定運行規則，避免混亂發生

業主與多個承包商建立工程施工合同關系，共同為項目進度目標的實現各自承擔其相應的義務情況下，按照一定的準則，規定各方運行規則，是避免發生混亂所必須的，尤其是應用P3采用多層二階主～子網絡非直接傳遞結構模型時，尤為必要。其運行規則的內容概述如下：

(1)有關各方均應采用為業主方制定的代碼結構、碼值(符)、詞典。最好在最高層主網上輸入，以便為各層主、子網所共亨。

(2)為使在主～子網結構內運算協調，在運行進度計劃調整、更新時，必須確定相同的更新日期。所有的子網應使用相同的數據日期，以避免沖突與混亂；如果相同的數據日期不可能，應在主網更新、調整，使其數據日期在主～子網上同步；

(3)進度計劃調整、更新的數據日期，可統一規定在月支付后的某一天為宜；

(4)承包商在其子網上調整、更新進度計劃(增、刪活動、調整活動時間、改變活動邏輯關系等)，必須在其子網絡拷貝版上進行，然后交監理審批，經批準后才能作為正式的子網絡，并將原子網絡備份(存檔)以便恢復或查詢；

(5)經(4)所述步驟后，統一建立從合同到整個建設項目各層次的目標進度網絡，為事后的進度評價建立基準；

(6)各承包商對各自的進度進行評價時，均以經監理、業主審核確定的實際完成的工程質量為基礎進行，使進度評價建立在可靠的基礎之上；

(7)當在主網上增加不屬于子網絡的活動或里程碑日期時，應為主網絡定義一個前兩個字符的可與子網絡活動相區別的活動代碼符；

(8)業主、監理方為維護進度計劃系統的安全，還應建立如下規定：在網絡環境下，建立主網絡與子網絡的權限，及子網對主網絡存取、訪問的權限；用于所有子網絡工作日歷；用于調度/平衡計算如何選項的規定；資源、費用計算單位和小數點位數等。

5 擴大軟件使用范圍，發揮更大的作用

把P3軟件作為項目進度控制的輔助工具，可發揮如下作用：

(1)編制與優化項目總進度計劃與標段工程進度計劃，按需對進度計劃作出適時調整與更新；輸出各種圖表；

(2)計算時間參數，找出關鍵線路與關鍵活動；

(3)對實際進度與計劃進度作對比，得出偏差，評價實際進度。并在此基礎上，實現實際進度對計劃進度的跟蹤；

(4)匯總包括資金、材料、勞力、專用施工設備需用量計劃及其在時間上的分布，為項目資源供應提供信息支持；

(5)在上述基礎上，為制定中、短期進度計劃提供方便和依據。

筆者認為，還可以在以下方面擴大使用范圍，以充分發揮其P3功能：

(1)在合同管理方面，用于分析承包商提出的工期索賠要求與確定其索賠期限；

(2)為業主、監理在處理不同標段合同之間在進度上發生沖突時，提供最優調度的分析工具。即當不同標段間平行作業的活動會損害工程施工質量或危及安全時，可依據對項目目標實現最佳的原則，確定活動作業順序，而主～子網絡結構模型是最合適的分析模型；

(3)建立費用帳目把工程概算價格、合同價格、實際支出價格等載入網絡計劃之中，結合本國國情運用贏得值分析技術，還可在項目投資控制中發揮一定作用。

6 結束語

筆者所要闡明的是把P3軟件作為項目進度控制的輔助工具，決不是僅涉及軟件操作等純技術性的問題。從業主方角度而言，更為重要的是從組織性質工作入手，做好上面所述及的工作。在統一組織、指揮下才能充分發揮其軟件功能，為項目管理提供更好的服務。這猶如交響樂團在高水平樂隊指揮下才奏出美妙動聽的樂章一樣。筆者曾對大型建設項目使用P3軟件的情況進行一些調查，凡使用情況不理想的其癥結所在大多在于此。這是要引以為戒的。也是筆者寫此文的用意之所在。

軟件項目論文:項目管理理論中關于軟件項目外包采購管理的探討

摘要：本文分析了目前軟件外包采購管理的重要意義和目前的形勢，提出基于“雙贏”策略的軟件外包采購思想。在項目管理理論、CMM和ISO9000的基礎上，提出和細化了軟件項目外包采購管理的總體框架和具體操作內容。旨在通過對軟件外包項目采購的選擇購買、跟蹤與控制、評估驗收和項目后處理等過程的研究，來提高軟件外包采購的項目管理水平，滿足承包方對分承制方產品在質量、進度和成本等方面的要求和對外包過程的有效控制，為軟件項目外包采購管理人員提供具體的操作過程。

一、基本概念和背景

項目管理理論是一門綜合多門學科的新興研究領域，共有九大知識領域，包括項目集成管理、項目范圍管理、項目時間管理、項目費用管理、項目質量管理、項目人力資源管理、項目溝通管理、項目風險管理和項目采購管理。項目采購管理是指需要從執行組織以外獲得貨物和服務的過程。通常把貨物和服務稱為產品，把買方稱為業主或對應分承制方的總承包商，而賣方稱為承包商、廠商或供應商。項目采購管理一般包括以下主要過程：采購計劃編制，詢價計劃編制，詢價，承包商選擇，合同管理，合同收尾[ 1 ].對于軟件產品，一般采購可以分為兩大類，一類是對已經在市場流通的軟件產品進行采購。例如，某企業想做信息化建設項目，涉及到數據庫，那么它就可以在目前市面流行通用的幾種廠家和種類的數據庫中選擇。例如Oracle公司的Oracle數據庫，Microsoft公司的SQL Sever，IBM公司的DB2數據庫等等。然后根據自己的需求，通過詢價、簽合同、安裝培訓等過程來購買此類產品。這種采購過程基本已經形成幾套通用的解決方案，比較簡單，中國企業在處理這類產品的采購時，大部分都處理的較好。個別的企業由于需求分析不清晰，培訓工作不到位等原因，也會產生購買的產品不適用，或不會用的情況。另外一類軟件產品采購的形式是外包采購。它是指在市場上沒有出現現成的產品或者沒有適合自己企業需求的產品的情況下，需要以定制的方式把項目（功能模塊）承包給其他企業。例如某企業需要實施企業資源計劃項目（ERP），雖然可以購買BAAN軟件，但是基于本企業業務流程的管理軟件必須定制，對于各個原有孤立島的集成軟件，無法購買現成的產品，必須自己開發或外包給別的公司。

二、軟件項目外包采購管理的意義

許多大型復雜工程項目的實施需要業主、總承包商、分承制商、供應商和開發制造商等共同合作來完成。因此在任何甲方和乙方之間必不可少的涉及到部分子項目（功能模塊）的采購活動。目前社會中，企業的信息化、網絡化建設正在世界范圍內展開。誰先進行信息化改造，誰就早日適應社會發展的要求，獲得巨額利潤。大規模的企業信息化建設形成了龐大的軟件產品市場，促進了軟件業的發展。許多項目龐大復雜、高風險并且涉及高科技信息領域，在客觀上使企業需要采購和外包許多產品，包括軟件產品。主觀上，在經濟全球一體化形式下，這種外包采購作為采購活動的一種特殊的、更為復雜的形式，在企業中更為普遍存在。企業為了在日益競爭的社會環境中增強自身的核心競爭力，需要根據企業的特點，專門從事某一個領域或幾個領域的業務，在某個業務領域內形成自己的核心業務，把企業內部的智能和資源集中在那些有核心競爭優勢的活動上；把一些非自己擅長的業務領域的子項目和功能模塊外包給有實力和優勢的公司，才有利于加快項目的完工進度，降低風險，優化資源配制，保證項目質量，降低成本，創造更高的價值。

以電信行業為例，愛立信公司2000年底宣布把手機生產的絕大部分業務外包給新加坡的Flextronics公司，專注于移動通信網絡設備業務。原因是愛立信的移動通信網絡設備的銷售占愛立信公司銷售額的54%，利潤達90%以上，占有全球的移動通信市場分額高達30%，而手機生產的投資回報率很底，甚至出現虧損情況。對于愛立信而言，手機生產“外包”是在信息化時代的戰略調整，希望通過外包生產，調整投資結構，使手機降低成本并且盡快盈利，集中精力穩定和拓展電信業的新市場。出于同樣目的，美國的摩托羅拉公司也表示將外包部分地區的手機生產業務。作為手機市場份額最大的諾基亞，在專注于手機生產業務的同時，大力開發周邊產業。希望以手機業務帶動相關產業的發展。從三大公司的投資趨勢，可以看出，“外包”作為一種先進的國際專業化的生產方式正被一些大公司越來越多的采用。我國正處在信息化建設的高速發展階段，必然會有越來越多的企業由于自身的能力限制或業務發展的戰略選擇，將采取業務“外包”的生產方式。

就軟件項目外包采購的市場來說，2000年是企業信息化實施的第一年，國內企業，特別是大型企業的信息化項目開始運作。行業信息化改造重點將由原來的電信、金融、海關等行業轉向交通、制造、醫療等傳統行業。這些行業由于自身計算機技術水平和業務發展重點的原因，將會把大量的軟件項目外包給軟件公司。根據CCID的統計（軟件可以分成平臺軟件、中間軟件和應用軟件），2000年中國軟件市場中應用軟件的銷售額為147億元，占軟件總市場份額的63.9%.預計到2005年，計算機信息服務和軟件市場銷售額增長到1750億元。屆時我國軟件項目“外包”市場潛力可想而知。

三、軟件外包采購管理存在的問題

雖然在傳統行業，許多工程項目的采購活動，例如機械工程項目或建筑工程項目等等已經形成比較成熟的管理體制和標準。但是軟件項目的外包管理工作并不象其他行業那樣順利。

軟件工程項目管理引起廣泛注意源于20世紀70年代中期，當時發現70%的項目是因為管理不善而引起。20世紀90年代中期，美國的軟件開發仍然很難預測，大約只有10%的項目能夠在預定的費用和進度下交付。商用軟件通常只有9%（中小型軟件公司有16%）的軟件項目能夠及時交付且費用并不超支。

這里有多方面的原因：軟件產品作為一種特殊商品形式，具有高度不可測量性和高度柔性；軟件企業開發能力還不太成熟，軟件開發大多數還處于手工作坊方式，軟件研發企業有其自身的運做方式，人為因素比重大，不好量化管理。由于不確定因素太多，許多軟件開發企業對于自己的項目都難以精確控制進度、質量、資源和成本，那么對于業主來說，想對外部企業（例如分承制商）保持良好控制力的難度就更大了。再加上具有技術優勢的軟件開發商一般集中在幾個科技發達的大城市，與業主的距離遠，相互的交流不方便，因此許多軟件采購項目的實際應用效果都差強人意：不適用，進度超期，性能達不到標準，成本太高等等情況時有發生。

軟件項目外包采購的成功與失敗不僅僅影響到當前軟件項目的質量、成本和工作進度，而且關系到企業信息化建設整個項目的整體結構、性能以及進度，意義重大。特別是當軟件項目作為整體項目計劃關鍵路徑的一個環節，軟件項目采購的進度直接影響整體項目的進度，并且總成本將成指數級增加。由于軟件采購的情況特別復雜，涉及的學科領域不僅是科學技術上的，還有商業上的和觀念上的，軟件項目外包采購管理水平的高低，將直接關系到企業整個信息化建設進程。因此軟件項目采購管理作為項目管理理論中一個新的研究課題，有必要給予足夠的重視。

四、目前軟件外包采購管理情況

美國項目管理協會的“項目管理知識體系指南”（PMBOK）[1]、美國卡內基-梅隆大學軟件工程研究所的“軟件能力成熟度模型”（CMM）[2，3]和國際標準ISO9000-3[4]中雖然對外包采購管理的流程有過論述，但是他們指出的只是外包采購管理的一般原則；雖然人們可以結合自身企業特點實施標準，具有一定靈活性，但是事物的另一對立面就是操作過程不具體。這給軟件產品的外包采購管理者帶來具體操作上的困惑。另外PMBOK體系原則上是應用在各個行業的，缺乏針對軟件領域的特點做專門的論述。ISO 9000-3系列和CMM雖然是針對軟件領域的標準，但是ISO 9000-3的最大的特點是只告訴你要按規定做，不強調效果和后續改善，不強調經驗積累和后評估。從這個意義上講ISO9000注重水平的評估，不太強調提高企業成長的過程，因此對于提高企業的管理水平意義不大；CMM雖然旨在強調企業的過程能力的持續改進，但是它重點強調軟件的開發過程管理和產品管理，缺乏軟件的分發、轉交和服務等方面的管理標準，所以也有一定的局限性。

五、基于“雙贏”策略的軟件外包采購思想

本文作者在集成美國項目管理協會的“項目管理知識體系指南”（PMBOK）和美國卡內基-梅隆大學軟件工程研究所的“軟件能力成熟度模型”（SW- CMM，SA-CMM）和ISO9000-3中關于外包采購的宗旨的基礎上提出“雙贏”策略的軟件外包采購思想。

“雙贏”策略的軟件外包采購思想旨在利用雙方業務能力互補，通過共同合作完成軟件外包項目，達到“雙贏”的目的，促進雙方業務總體能力的提高。這種“雙贏”策略要求雙方在以下方面達成共識：雙方共同關注過程控制，才能保證有效結果；只能成功，不能指望依靠懲罰手段來收回采購成本，軟件外包采購項目的失敗對整個項目帶來的損失是巨大的；在合作過程中，建立對分承制商關系的管理體系，作為以后合作的基礎；重視開發過程的風險評估和采購項目后評估，使得雙方業務能力得到持續提高。

傳統的外包采購中，采購方只關心分承制商產品的進度和質量，以為只要分承制商按期、按質交貨，就可以圓滿結束此次采購活動。有些項目盡管前期進度和質量滿足合同要求，但是許多是以高投入、高負荷、高消耗等手段來保證的，這給后期帶來極高的風險。在階段評審中，如果采購方對分承制商開發過程中的費用投入、人員負荷、資源消耗、組織結構變化等漠不關心，因此就不能及早預見風險、控制風險。很難想象，后期在費用透支、人員疲憊或流失嚴重的情況下，分承制商仍能保證產品質量和進度。這種情況下，采購方只能要么加大投入，要么終止合同，并要求賠償，要么延期驗收等等。其副作用可想而知。而分承制商為了減少損失，根據博弈論中子博弈精練納什均衡原理，必然采取降低質量要求，減少投入的策略，來加快進度。結果最終還是采購方遭受損失。

六、軟件項目外包采購管理過程

為了保證軟件外包采購項目的順利進行，本文作者在上訴理論體系和“雙贏”采購策略的基礎上，提出和細化了軟件項目外包采購的總體框架和具體操作內容，旨在為軟件項目外包采購管理人員提供具體的可操作過程。

對于本采購過程，如果業主方由于行業、人員等原因，沒有健全的監控部門，可以聘請具有軟件監理職責的公司，或者總承包給具有一定軟件工程監控能力的公司。這時的總承包公司角色相當于本文提到的采購部。

軟件項目的整個外包采購過程可以分為十個工作階段，包括總體項目需求分析和設計、子項目的需求分析、廠商選擇、分承制商開發、業主階段評估、交驗測試、安裝、培訓、維護，后評價。

在開始外包采購之前，首先業主要完成項目的總體需求規格說明書和承包項目的需求說明書。一般承包項目的需求分用戶需求和分配需求。對于分承包商來說，業主對軟件項目所提出的需求通稱“用戶需求”。對于業主來說，系統總體分配給軟件的系統需求通稱“分配需求”。如何作好子項目的需求分析和管理，請參閱《軟件需求》，詳見參考文獻5.然后業主把需求說明書交給采購組組織采購。采購部門收到需求說明書后，再補充質詢調查表、報價指南、綜合條款及條件等文件，組成采購質詢技術文件發往廠商進行質詢。采購部門在廠商質詢的基礎上，準備了廠商選擇和投標估價等技術文件后，向業主送審，提請業主批準和確認所選廠商。在廠商選擇和投標估價這兩個文件中，采購部根據擬采購的軟件對被質詢的至少三家以上的供應廠商，就技術開發成熟能力、資源（包括以有的產品、硬件、軟件、信息和已經過的培訓）、資格和信譽、過去的合作關系、價格、提供的售后服務（包括培訓和維護）、分承制方組織配置結構、與質詢要求的差異等方面，經過經濟技術和商業戰略角度出發進行全面評估，經過其他各部門（例如系統工程組、軟件工程組、質保組、財務組）審核后，列出供應廠商的優劣次序，擇其優者為該項目的供應廠商。采購部一般以月為單位向業主通報軟件采購情況。一般以招投標方式或內部評審的方式來確定分承制商。

分承制商在接到采購部的定貨以后，就可以進行工作說明書、用戶需求說明書、軟件需求規格說明書、軟件開發詳細計劃和成本概預算、測試計劃、質量控制方法、風險控制、擬采用的軟件工程標準和軟件生命周期等文檔的制作。然后分承制商把有關的技術資料文件通過業主的采購部送給業主進行校核和批準，然后才能開始開發。

業主在接到分承制商的上述材料后，組織系統工程部、軟件工程部、質保部、財務部、采購部、法律部就上述材料中的開發項目視圖和需求范圍、使用或需要購買的軟硬件、進度計劃和成本、測試計劃與案例、使用的技術和工程標準、人員配置等進行評審，并出具評審文件和風險評估、控制建議書。并由采購部制定采購項目監督評估計劃書。合格后，由采購部、質保部及法律人員與分承制商簽署詳細的軟件采購子合同。如需要對軟件項目投保，以此來降低風險，需要和分承制商協商后，納入合同文件。

分承制商在簽署合同后可以進行設計和開發。業主應該委派采購部監督分承制商的工作。采購部應該有計劃的組織質保部、軟件工程部的項目計劃管理人員和配置管理人員，定期對分承制商的開發活動進度、質量、成本等進行評估，并形成評估建議書。送審業主方的系統工程部、項目管理人員、分承制商的此項目的負責人。分承制方的項目負責人要對評估建議書的建議進行書面回復，并確保實施。

分承制方對所有需要采購的資源（軟件、硬件、人力資源等）負責進行檢驗；采購部有權在任何時候對分承制商所采購的資源進行驗證，使之符合所采用的規格說明書、規范、標準和其他技術文件所規定的要求，確保分承制商?？顚Ｓ?，建立開發環境。在這個階段之前，采購部門和分承制商首先要確定由分承制商提供的驗證建議書，并作好準備工作，提交檢驗用的技術文件，包括廠商說明書、設備性能數據表、配制清單、試驗程序、檢驗技術要求。在檢驗的物質條件和技術條件均已準備妥善后，分承包商就可以向采購部并通過采購部向業主提出書面檢驗申請。一般分承包商可以提前三周通知采購部，由采購部提前兩周以書面形式向業主提出檢驗申請，由業主召集系統工程部、軟件工程部、質保部組成驗證組，在規定的時間、地點檢驗。通過檢驗后，分承包商進入項目開發階段；業主進入監控和評估階段。對于重大關鍵項目，業主可以派遣項目監督員短期或長期進駐分承包商單位。

由于作為外部單位，業主不便時刻監督項目的開發過程。雖然理論上需要把分承制商看作是自己的一個項目部門來對待，納入自己的進度控制和質量控制體系，但是客觀上由于分承制商與業主距離較遠，人員不熟悉，各自有自己的企業文化和管理體制，雙方之間的信息溝通不暢，業主難以實時監督分承制商的開發進程和質量。最好的辦法就是在分承制商的軟件項目的各個里程碑處和分承制商一起進行檢查和評估。軟件項目一般可以劃分成若干個里程碑（3-5個為益），分承制商需要提前一周通知采購部組織相關人員來評估。軟件項目的里程碑一般指產品設計趨于穩定，中間產品定義趨于明晰，項目開發組真正了解項目實際的關鍵技術難度和可行的進度計劃，開發活動停止，產品進入除錯和穩定、隨時可以的階段，或當產品設計被刪減、資源增加、進度延誤的時候。在評估軟件質量、進度和功能的同時，還要評估分承制商的人員工作負荷程度、風險、費用和資源消耗情況，并形成文檔。由采購部送審系統工程部、軟件工程部、項目管理部和分承制商的此項目負責人。

當產品進入交驗測試的時候，分承制商需要提前三周通知采購部，采購部于前兩周通知業主作好交驗的組織評估準備工作。這時業主組織系統工程部、軟件工程部、測試部、質保部和采購部，根據分承制商和業主在分承制商開發階段預先共同定義、評審并批準的測試計劃和驗收方案進行驗收測試，對需求規格說明書中的各項逐個詳細的測試。最后以書面的形式給出對整個軟件項目的測試評估報告。并對未通過驗收測試的軟件產品指定相應的補救措施和計劃。分承制商交付給業主方的軟件產品應當包括：源代碼、軟件開發計劃、仿真環境、軟件需求規格說明書、設計文檔、軟件測試計劃、軟件測試說明、驗收測試計劃、軟件使用手冊、軟件安裝手冊、軟件維護手冊。必要的話，還包括相關培訓計劃。

軟件采購的一個重要階段是交貨，也是目前經常忽略的階段。當所采購的軟件產品以及硬件運行環境在規定的時間到達采購部時候，采購部要以書面的形式通知業主交貨。業主對所交的整個軟件產品清單進行驗收，并事先通知采購部拆箱日期，要采購部和分承包商的代表按時到場。業主要在接到采購部交貨通知后一個月內，對所檢查驗收的整個軟件產品（包括相關的軟件、硬件及其附屬產品、文檔、技術資料等子合同中規定的產品）出具一份交貨證明，如果這些提交的軟件產品沒有受到損壞并與裝箱清單相一致，并在業主方環境運行良好；否則出具一份書面通知，說明在某個方面此產品損壞或與裝箱單不符，或在業主方提供的環境運行不良。此通知或證明應由采購部和分承制商代表簽署。如果在簽合同的時候，就規定分承制商負責安裝和調試，則相應的過程省略。

最后業主方由采購部把所有的文檔歸類封存，以備后續類似項目采購的參考查詢。同時采購部在兩個月之內以書面形式，對分承制商的技術開發成熟能力、資源（包括以有的產品、硬件、軟件、人力資源和已經過的培訓）、信譽、分承制方組織配置結構，管理能力和企業文化提交后評價報告，作為建立客戶關系管理（CRM）的依據。對于此次采購的經驗和教訓，包括進度控制、質量控制、成本控制、客戶關系控制、流程控制、風險控制等方面，采購部以文檔的形式在組內討論并保存。

七、結束語：

作為大型工程項目中的軟件子項目或者部分功能模塊的采購（外包），由于軟件開發的固有特性（風險大，柔性強，人為因素突出，結果不宜測量等），使軟件項目的外包采購管理變得十分復雜。如何控制分承制商的開發進度和質量等關鍵因素，需要在實踐中不斷探索，并針對具體公司和項目對采購過程有所裁剪。

軟件項目論文:關于軟件項目管理的控制研究

論文摘要：本文針對軟件開發中的進度延期、費用超標、質量低下等問題，探討了如何利用項目管理中的相關控制方法進行軟件開發過程控制。、論文在闡述軟件項目管理內容的基礎上，針對軟件項目的三要素分別進行了探討：進度控制、費用控制和質量控制，提出了幾種有效的軟件項目管理控制方法。這些研究對于加強我國軟件項目管理控制過程，降低開發成本，減少開發風險具有重要的意義。

論文關鍵詞：項目管理 進度控制 費用控制 質量控制 軟件開發

人類社會經歷了三次經濟革命從農業革命、工業革命到目前正在經歷的信息革命。信息化正在日益改變人們的思維方式和生活習慣。在推動信息化過程中，計算機及其軟件產品發揮著至關重要的作用。對于軟件項目的管理成為項目管理領域一個令人興奮的課題。本文將結合項目管理中的控制方法分析軟件項目管理控制的相關問題．以期提高軟件項目的開發效率。

1、關于軟件項目管理

1．1項目與項目管理

項目是一個旨在完成一個或一些獨特產品或服務的過程．它有著一系列被詳細描述的屬性。由于項目的獨特性和一次性特征，引伸出它的其他特點．如目標的確定性．成果的不可挽回性組織的臨時性和開發性等?；陧梖lI的這些特點．項目運作更加注重項目決策前的計劃以及對實施過程的控制，以減少項目運作的風險。項目管理是2O世紀50年代后期發展起來的一種計劃管理方法，它運用先進科學的管理方式．有效解決大型組織的效率低下和小型企業面臨的風險增加問題以組織的機動靈活．面向客戶和資源利用率高而被廣泛應用。在工程設計．施工軟件項目的開發、實麓中經常會遇到進度拖延．費用超支、質量不達要求等問題除去極少數是因為技術原因造成，絕大部分是源于僵化的管理和不當的管理方式。

1．2軟件項目管理

各軟件企業都在積極將軟件項目管理引入開發活動中．對開發實行有效的管理。從概念上講．軟件項目管理是為了使軟件項目能夠按照預定的成本．進度、質量順利完成．而對成本、人員、進度、質量、風險等進行分析和管理的活動。同時，隨著軟件開發規模及開發隊伍的逐漸增大，軟件開發不再是向過去那樣一二個開發人員即可解決的事情。迫切需要一種開發規范來規范每個開發人員、測試人員與支持人員的工作每個項目組成員按約定的規則準時完成自己的工作。同時采用規范化管理．專業分工也可以降低對開發人員的要求，從而降低產品研發成本。

2、軟件項目控制

2．1軟件項目控制

軟件項目跟蹤和監控包括對照已文檔化的估計、約定和計劃評審和跟蹤軟件完成情況和結果?；趯嶋H的完成情況和結果調整這些計劃。軟件項目的已文檔化的計劃(即軟件開發計劃，正如在軟件項目計劃關鍵過程區域中所描述的)用作跟蹤軟件活動傳送狀態和修訂計劃的基礎管理者監控軟件活動．主要通過在所選出的軟件工作產品完成時和在所選擇的里程碑處，將實際的軟件規模工作量成本和時間表與計劃相比較，來確定進展情況。當確定未實現軟件項目計劃時，采取糾正措施。這些措施可以包括修訂軟件開發計劃以反映實際的完成情況和重新計劃遺留的工作或者采取改進性能的措施。

2．2軟件項目控制的內容

軟件項目控制的目的是為軟件項目的過程提供足夠的能見度，從而可以在執行過程中發生對計劃的嚴重偏離時能夠采取適當的更正行為。軟件項目控制包括：a。追蹤軟件項目的進展于表現從而與所作的估計、承諾和計劃做出對比：b。追蹤軟件項目的風險；C。在發生對計劃的嚴重偏離時采取適當的更正行為。

2．3軟件項目控制步驟

由于軟件開發是處在一個開放的動態系統中，開發環境的不斷變化要求不斷修改項目計劃，以適應新的變化。此外項目經理及其組織在完成任務的過程中不可避免的要碰到這樣或那樣的問題．解決這些新的矛盾和問題均屬項目控制的范疇項目的預算和進度計劃只能為項目經理提供決策的依據．如果在項目實施過程中控制不?。茈y在限定的時間和預算要求下實現項目管理工作的目標。因此軟件項目控制的過程包括以下四個步驟：a、預測什么會發生——要做出開發計劃并建立工作標準b、查明什么正在發生——用建立的工作標準檢查當前的工作；c、正在(或已經)發生的實事同預測的結果進行比較——分析誤差產生的原因：d及時采取補救措施．以滿足項目目標，預算和進度的要求。

3、軟件項目控制具體操作

3．1軟件項目進度控制

為了確保軟件開發中的各項工作能按照計劃預定的日程順利完成．對項目的進度要進行控制。進度控制的過程是．在項目實施過程中，不斷地進行實際進度值與計劃值的比較、發現偏差、檢查分析其產生的原因，并采取相應的措施加以解決。

3．1．1進度控制流程

(1)進度控制的輸入

進度計劃。項目進度基準是項目測量和報告的基礎和標準。

實施報告。實施報告提供了有關項目進度發展實情。報告未來可能發生的進度問題。

變更要求。項目變更要有嚴格的申請和審批手續。

進度管理的技術和工具。

(2)進度管理的技術和工具

進度控制變更系統。為有效實現進度管理與控制．進度控制系統應設立實現重新計劃的全部功能。包括：文件設立．跟蹤即實施報告．變更評估等。

實施情況測量。項目進度控制系統中的一個重要組成部分是決定對遲發生的進度偏差是否采取糾偏措施。而實施情況報告提供了決策的主要信息。如變更分析．趨勢分析．已實現價值分析等。

糾偏計劃。很少有項目能完全按計劃進度進行為實現項目進度或總進度要求，在項目實施過程中．需要不斷對原計劃進行調整或增加新的工作內容。為此．需要不斷對實施的項目進行活動時間預測。修改活動過程．替代進度方案分析。

項目管理軟件。它的作用是跟蹤項目按計劃日期展開實際工作的情況．對照進度計劃分析進度現狀，找出進度的偏差．分析進度偏差對項目的影響．預測未來走勢

(3)項目進度控制的輸出

進度更新。包括對項目管理中任何進度信息的修改。進度調整是其中的一種．師隊員進度計劃中活動開始和結束時間的改變。糾偏行動。通過改變資源投入將實際進度拉回到計劃的行動過程。

從中獲得的教訓。有關進度偏差產生的原因。糾偏方案的評估與選擇以及其他方面的感受和教訓都應紀錄在案成為日后有用的歷史資料。

3．1．2進度控制方法

一般項目進度控制采用因果分析．分析用四步完成：

(1)明確問題。實際完成情況與項目里程碑相對照．確定是否超期．超期的部分是在哪里。

(2)查找產生該問題的原因。位從系統角度充分認識各方原因．應組織具有代表性任務人員并采用頭腦風暴法進行。項目主管要通過他領導的辦公室或小組，以及在各職能部門的人共同分析問題產生原因。

(3)確定個原因對問題產生的影響程度。對影響程度的評估可以采用專家小組打分的方法，事先確定權數．而后打分得出分析結果。

(4)畫出帶箭頭的魚刺圖。分析出原因后各部門各就其職針對問題提出解決方案．并實施。

3．1．3軟件項目進度控制具體措施

在實施進度計劃過程中，會有種種故障：客戶的需求進行了補充或修改；工作量估算不準，造成進度不平衡或是有人不遵從開發規范．導致產品出現缺陷；或是技術環節出現故障，這些問題往往是在進度計劃外出現的．一旦出現這些問題，項目進度不得不進行調整。開發過程中為了有效控制類似問題，可以采用以下輔助措施，控制進度按計劃執行：

(1)政策性措施。對于不遵從開發規范，人員不按時履行職責的．給予經濟或是職務上的處罰．這種措施應是建立在分配任務之前；

(2)人員安排。在各子項目接口處適當安排機動人員與機動時間。這一措施有賴于項目組織的機構設置能動性好。此處比較難解決的是人員業績評估．獎勵問題。

(3)技術措施，要想很好地執行進度計劃，需要事先有統一的規范例如開發語言的統一，文檔的歸類。這樣便于下一階段人員理解上一階段人員意圖，交流更加容易。

(4)信息流措施。該措施要求建立一個信息流系統．準時匯報項目進度．便于主控人員調整進度，并且保證信息流通順暢。避免開發期壓到最后造成嚴重拖工。

(5)資金措施。財務部門可以定期檢查各部門財務情況．控制資金流出時間．進而控制項目進度。這與后面要講到的三者權衡有密切關系。

3．2軟件項目費用控制

費用控制就是要保證各項工作要在他們各自的預算范圍內進行。其基礎是實現就對項目進行費用預算。整個項目費用應包括項目范圍規劃階段。軟件需求分析階段．原型設計階段開發階段．測試階段和項目投入使用后的使用階段所消耗費用的總和。軟件開發項目承擔公司為了完成項目目標和獲得更多的利潤．在實施項目過程中就要控制成本．在控制過程中，首先要擬定一個標準．即計劃值．然后進行實際至于計劃值的比較，確定實際值與計劃標準的偏差大?。员阍诖嘶A上采取各種措施糾正偏差．常用的分析工具是偏差分析。

偏差是指實際成本對相應計劃的偏離，成本偏差的數學公式為：

CV=BCWP-ACWP(負數CV表明出現超支；反之，則節資)(3—1)

其中：CV為成本偏差，BCWP為計劃工作預算，ACWP為完成工作實際成本。

在進行成本偏離計劃程度分析時，常用計劃偏差率反應時給予計劃的偏離程度。

CVP=CV／BCWP(3-2)

其中CVP為成本偏差率。

偏差值是控制分析中的一個關鍵參數，因而應向各級組織匯報。對于不同的項目或同一項目不同階段或不同管理層次，對偏差的控制程度不一樣，制定偏差允許值的方法也不同。由于隨著時間的推移風險減少了，因而偏差允許也可降低。

3．3軟件項目質量控制

對于軟件產品的項目質量控制應是事前有預控，過程有監控的主動控制閉環系統。(1)事前預控：根據影響質量因素多等特點．軟件項目質量必須事前預控，及根據軟件的類型和特點，以及以往類似項目的常發病和預防措施，對軟件項目質量提出事前預控措施，包括制定控制的計劃和程序，這是項目質量控制的前提。(2)過程監控：根據易產生質量波動和易產生系統因素變異等特點，軟件項目質量必須過程監控．即按照預控的計劃和程序，對工序、分項、單元的全過程進行過程監控．包括監測、檢查、控制和評定．這是項目質量控制的基礎。

4、結語

軟件開發項目在進度、費用和質量三方面均需要進行控制，因此還存在三因素的權衡問題。實踐中．需要在三方面均進行行之有效的控制措施才能確保項目完成情況與計劃最大限度的接近。本文提供了一些方法借鑒．對軟件開發項目控制有一定的實際意義。

軟件項目論文:淺談軟件項目實訓中的人員選擇與管理

論文關鍵詞 軟件高職　項目實訓　人員選擇　人員管理

論文摘要 項目實訓是軟件高職教育課程體系中的重要環節。結合軟件高職項目實訓中人員管理的實際情況進行分析和論證，同時給出實訓人員選擇與管理工作的基本原則和方法，并總結其中的一些基本經驗。

隨著國家大力發展職業教育的政策的出臺，職業教育在全國范圍逐漸興起，軟件高職教育作為職業教育的一個重要組成部分，為國家和地方培養了大量的具有較強動手能力的一線人才，創造出巨大的生產力，帶動整個IT行業的發展，推動經濟和社會的進步。項目實訓作為軟件高職教育課程體系中的一個重要環節，無論是對學生理論知識的拓展還是動手能力的培養都起到至關重要的作用。目前，福建省的軟件高職項目實訓還處于初級發展階段，無論在項目設置上還是在管理方式上都存在不足。筆者結合實際教學和管理經驗，對軟件高職實訓中的人員管理方式和方法做初步的分析和探討。

1 人員的選擇

教育的宗旨是以學生為本，平等地對待每一位學生，讓他們在最大程度上發揮潛力。但是實訓工作畢竟帶有一種企業模擬性質，學校注重教育公平，而企業更關注開發效率和項目成本，這兩者在一定程度上是此消彼長的對立面。因此，如何通過合理的人員選擇和配置，找到既能平等地對待每個學生，又能夠最大限度地提高項目團隊開發效率的平衡點，是實訓項目管理人員所急需解決的現實而又棘手的問題。以下是筆者在實踐中探索并采用的2種較為合理的人員選擇與配置方案。

1.1 T&R式自由組合法這里的T指的是Test，即測試，包括技術筆試和專業面試。在兩項測試之后應形成一個比較合理的量化指標，該指標應著重突出候選人員的技術能力和團隊意識，公布所有候選人員的各項量化指標。為保護學生的隱私，在公布時可以用編號取代學生的真實姓名。這里的R指的是rate，即比例。項目管理人員可以預先設定好小組成員結構的技術等級比例，參照學生的綜合得分情況，按照1:2:1的高中低3個層次分布比例較合理。這種做法既可以避免單純比例式自由組合給學生帶來的盲目性，也能夠比較真實地反映學生的能力水平，可以科學地、客觀地組建起較為高效的團隊，從而能夠在后續階段提高團隊整體工作效率，也為管理工作帶來方便。

1.2 T&R交互式人員確定法首先尋找若干名班委組成評審組，項目管理人員或教師負責領導該評審組；接著參照T&R方法得出候選人員的各項評估指標和綜合指標，以及小組結構比例；然后由評審小組成員進行數據分析并結合每個成員實際情況確定各小組的組成人員。將初步形成的分組名單公布告知各候選人員，征求每位成員意見，由評審小組跟持反對意見的候選成員進行當面的會議式的溝通，進行合理的調整，經此步驟之后形成最終分組名單并公布。這樣做實現候選成員與管理人員之間的交互，能夠把純粹的硬性考核成績指標轉化為“考核成績指標＋交互式分析”。這樣較為客觀且人性化的評判方式，既能夠得到較為真實的數據，又能夠吸納學生合理的意見或看法，從而利于更科學的人員選擇。

2 人員的管理

美國心理學家亞伯拉罕·馬斯洛把人的需求分成生理需求、安全需求、社交需求、尊重需求和自我實現需求5類，依次由較低層次到較高層次排列，在管理中他建議通過滿足人的需求來激發他們。

在學校實訓的項目組中，成員的生理需求和安全需求都基本能夠得以滿足，因此，保證成員的社會需求、受尊重需求和自我實現需求的滿足，對管理者來說有十分重要的意義。1）滿足組員的社會需求就是為組員提供相互交往的時間和場所。實訓項目的交流不應僅局限在小組的范疇，應鼓勵小組與小組間的相互交流，條件具備的話可以組織學校跟學校間類似項目組間的交流。形式可以多樣化，如電子郵件、組建QQ群、網絡會議、座談會和技術講座等互動方式。2）為了滿足組員受尊重的需求，應該讓他們感到在項目小組中受到人格上的尊重，技術長處被認可。對于參加實訓的學生來說，對他們做出的成績給予充分的肯定就是一種簡便高效的方式，如針對某個技術環節開展一次技能比賽，或者開展評審會定期對項目階段成果進行評估，對優秀團隊及其成員進行表彰等。3）為滿足組員自我實現的需求，應該在項目取得一定成果的基礎上，分配給組員具有一定挑戰性和難度的任務，這些任務不能超過學生能力的范圍，同時給他們提供課外的輔導以提高他們解決這些問題的技能。任務的完成情況可以作為附加評審內容納入學生最終的實訓綜合成績中去，給學生超越自我的動力。

3 團隊的管理

3.1 增強小組凝聚力一個有強大凝聚力的小組是最高效的小組，小組中的成員在思想上能夠形成共同的準則，在工作中能夠緊密配合和協調，組員跟組員之間能夠互相學習、相互關照，從而消除隔閡，用集體的力量解決許多工作中的問題。增強小組凝聚力的方式有許多，如給小組起個性化的名字、開展游戲或者室內或戶外運動等方式增進組員間的溝通。另外，提高小組組員的責任感、誠信度以及保障他們的知情權、提供發展的空間等，都是增強小組凝聚力的有效方法。

3.2 增強小組溝通溝通作為軟件開發過程中的重要環節，對于開發效率的提高和團隊的整體發展具有決定性的意義。1）適當的小組規模。在編制小組成員時應考慮到人數對溝通的影響，成員太少，溝通容易但不利于開發效率；反之，成員過多會使得溝通變得十分困難，從而使效率嚴重下降，因此，合理的人員安排才是關鍵。根據經驗，一個實訓小組以4～8個為宜，其中6人組最為合適。2）合理的性別比例。如果小組中的組員性別均相同，可能會導致沖突，使得溝通無法正常進行，所以在確定小組結構時應注意男女比例的控制。對于軟件開發類實訓項目而言，小組中的男女比例應控制在3:1左右，其中女性組員可以作為小組的協調員。3）適當的小組負責人。小組負責人除了領導小組工作外，還負責協調小組成員之間的溝通。受尊重的小組負責人可以提高小組凝聚力和工作效率，無論對自身的進步還是對整個團隊的發展來說都是大有裨益的。