1、與得乃Z上承軟件項目管理課程設計設計（論文）題目 軟件項目管理的具體內容學院名稱信息科學與技術學院專業名稱軟件工程學生姓名學生學號任課教師設計（論文）成績教務處制2015年07月04日目錄1、 摘要 32、 正文 32.1 軟件項目管理-軟件項目的計劃 42.2 軟件項目管理-軟件項目的控制 52.3 軟件項目管理-軟件項目管理的組織模式 62.4 軟件項目管理-軟件項目管理的內容 72.5 軟件項目管理-編寫軟件項目計劃書 82.6 軟件項目管理-軟件配置管理 82.7 軟件項目管理-人員組織與管理 93人月神話讀后感 111 、 摘要軟件項目管理的內容主要包括如下幾個方面：人員的組織與管理

2、，軟件度量，軟件項目計劃，風險管理，軟件質量保證，軟件過程能力評估，軟件配置管理 這幾個方面都是貫穿、交織于整個軟件開發過程中的，其中人員的組織與管理把注意力集中在項目組人員的構成、優化。關鍵詞： 軟件項目的計劃；軟件項目的控制；軟件項目管理的組織模式；軟件項目管理的內容；軟件項目計劃書；軟件配置管理；人員組織與管理；軟件過程能力評估2 、正文軟件項目管理的根本目的是為了讓軟件項目尤其是大型項目的整個軟件生命周期（從分析、設計、編碼到測試、維護全過程）都能在管理者的控制之下，以預定成本按期，按質的完成軟件交付用戶使用。而研究軟件項目管理為了從已有的成功或失敗的案例中總結出能夠指導今后開發的通用

3、原則，方法， 同時避免前人失誤。軟件項目管理的提出是在20 世紀 70 年代中期的美國，當時美國國防部專門研究了軟件開發不能按時提交，預算超支和質量達不到用戶要求的原因，結果發現70%的項目是因為管理不善引起的，而非技術原因。于是軟件開發者開始逐漸重視起軟件開發中的各項管理。到了 20 世紀 90 年代中期，軟件研發項目管理不善的問題仍然存在。據美國軟件工程實施現狀的調查，軟件研發的情況仍然很難預測， 大約只有10的項目能夠在預定的費用和進度下交付1995年，據統計，美國共取消了810 億美元的商業軟件項目，其中31的項目未做完就被取消，53的軟件項目進度通常要延長50%的時間，只有9的軟件項

4、目能夠及時交付并且費用也控制在預算之內。軟件項目管理和其他的項目管理相比有相當的特殊性。首先， 軟件是純知識產品，其開發進度和質量很難估計和度量，生產效率也難以預測和保證。其次，軟件系統的復雜性也導致了開發過程中各種風險的難以預見和控制。Windows這樣的操作系統有1500 萬行以上的代碼，同時有數千個程序員在進行開發，項目經理都有上百個。這樣龐大的系統如果沒有很好的管理，其軟件質量是難以想象軟件項目管理的內容主要包括如下幾個方面：人員的組織與管理，軟件度量，軟件項目計劃，風險管理，軟件質量保證，軟件過程能力評估，軟件配置管理 這幾個方面都是貫穿、交織于整個軟件開發過程中的，其中人員的組織與

5、管理把注意力集中在項目組人員的構成、優化； 軟件度量把關注用量化的方法評測軟件開發中的費用、生產率、 進度和產品質量等要素是否符合期望值，包括過程度量和產品度量兩個方面；軟件項目計劃主要包括工作量、成本、 開發時間的估計， 并根據估計值制定和調整項目組的工作；風險管理預測未來可能出現的各種危害到軟件產品質量的潛在因素并由此采取措施進行預防；質量保證是保證產品和服務充分滿足消費者要求的質量而進行的有計劃，有組織的活動；軟件過程能力評估是對軟件開發能力的高低進行衡量；軟件配置管理針對開發過程中人員、工具的配置、使用提出管理策略。因為大家對人力資源管理和軟件過程能力比較有興趣，下面就詳細的對這兩方面

6、展開討論。2.1 軟件項目管理- 軟件項目的計劃軟件項目計劃是一個軟件項目進入系統實施的啟動階段, 主要進行的工作包括 : 確定詳細的項目實施范圍、定義遞交的工作成果、評估實施過程中主要的風險、制定項目實施的時間計劃、成本和預算計劃、人力資源計劃等。軟件項目管理過程從項目計劃活動開始，而第一項計劃活動就是估算：需要多長時間、需要多少工作量、以及需要多少人員。此外，我們還必須估算所需要的資源（硬件及軟件）和可能涉及到的風險。為了估算軟件項目的工作量和完成期限，首先需要預測軟件規模。度量軟件規模的常用方法有直接的方法 LOC（代碼行），間接的方法 FP （功能點）。 這兩種方法各有優缺點，應該根據

7、軟件項目的特點選擇適用的軟件規模度量方法。根據項目的規模可以估算出完成項目所需的工作量，我們可以使用一種或多種技術進行估算，這些技術主要分為兩大類：分解和經驗建模。分解技術需要劃分出主要的軟件功能，接著估算實現每一個功能所需的程序規?；蛉嗽聰怠＝涷灱夹g的使用是根據經驗導出的公式來預測工作量和時間?？梢允褂米詣庸ぞ邅韺崿F某一特定的經驗模型。精確的項目估算一般至少會用到上述技術中的兩種。通過比較和協調使用不同技術導出的估算值，我們可能得到更精確的估算。軟件項目估算永遠不會是一門精確的科學，但將良好的歷史數據與系統化的技術結合起來能夠提高估算的精確度。當對軟件項目給予較高期望時，一般都會進行風險分析

8、。在標識、分析和管理風險上花費的時間和人力可以從多個方面得到回報：更加平穩的項目進展過程； 更高的跟蹤和控制項目的能力；由于在問題發生之前已經做了周密計劃而產生的信心。對于一個項目管理者，他的目標是定義所有的項目任務，識別出關鍵任務，跟蹤關鍵任務的進展情況，以保證能夠及時發現拖延進度的情況。為此， 項目管理者必須制定一個足夠詳細的進度表，以便監督項目進度并控制整個項目。常用的制定進度計劃的工具主要有Gantt 圖和工程網絡兩種。Gantt 圖具有悠久歷史、直觀簡明、容易學習、容易繪制等優點，但是，它不能明顯地表示各項任務彼此間的依賴關系，也不能明顯地表示關鍵路徑和關鍵任務，進度計劃中的關鍵部分

9、不明確。因此，在管理大型軟件項目時，僅用Gantt 圖是不夠的，不僅難于做出既節省資源又保證進度的計劃，而且還容易發生差錯。工程網絡不僅能描繪任務分解情況及每項作業的開始時間和結束時間，而且還能清楚地表示各個作業彼此間的依賴關系。從工程網絡圖中容易識別出關鍵路徑和關鍵任務。因此，工程網絡圖是制定進度計劃的強有力的工具。通常，聯合使用 Gantt 圖和工程網絡這兩種工具來制定和管理進度計劃，使它們互相補充、取長補短。進度安排是軟件項目計劃的首要任務，而項目計劃則是軟件項目管理的首要組成部分。 與估算方法和風險分析相結合，進度安排將為項目管理者建立起一張計劃圖。2.2 軟件項目管理- 軟件項目的控

10、制對于軟件開發項目而言，控制是十分重要的管理活動。下面介紹軟件工程控制活動中的質量保證和配置管理。其實上面所提到的風險分析也可以算是軟件工程控制活動的一類。而進度跟蹤則起到連接軟件項目計劃和控制的作用。軟件質量保證（SQA， Software Quality Insurance ）是在軟件過程中的每一步都進行的“保護性活動" 。SQAfc要有基于非執行的測試（也稱為評審）、 基于執行的測試（即通常所說的測試）和程序正確性證明。軟件評審是最為重要的SQA舌動之一。它的作用是，在發現及改正錯誤的成本相對較小時就及時發現并排除錯誤。審查和走查是進行正式技術評審的兩類具體方法。 審查過程不僅

11、步數比走審多，而且每個步驟都是正規的。由于在開發大型軟件過程中所犯的錯誤絕大數是規格說明錯誤或設計錯誤，而正式的技術評審發現這兩類錯誤的有效性高達75%，因此是非常有效的軟件質量保證方法。軟件配置管理（ SCM， Software configurationmanagemen） t 是應用于整個軟件過程中的保護性活動，它是在軟件整個生命周期內管理變化的一組活動。軟件配置由一組相互關聯的對象組成，這些對象也稱為軟件配置項，它們是作為某些軟件工程活動的結果而產生的。除了文檔、程序和數據這些軟件配置項之外，用于開發軟件的開發環境也可置于配置控制之下。一旦一個配置對象已被開發出來并且通過了評審，它就變

12、成了基線。對基線對象的修改導致建立該對象的版本。版本控制是用于管理這些對象而使用的一組規程和工具。變更控制是一種規程活動，它能夠在對配置對象進行修改時保證質量和一致性。配置審計是一項軟件質量保證活動，它有助于確保在進行修改時仍然保持質量。狀態報告向需要知道關于變化的信息的人，提供有關每項變化的信息。2.3 軟件項目管理- 軟件項目管理的組織模式軟件項目可以是一個單獨的開發項目，也可以與產品項目組成一個完整的軟件產品項目。如果是訂單開發，則成立軟件項目組即可；如果是產品開發，需成立軟件項目組和產品項目（負責市場調研和銷售），組成軟件產品項目組。公司實行項目管理時，首先要成立項目管理委員會，項目管

13、理委員會下設項目管理小組、項目評審小組和軟件產品項目組。項目管理委員會項目管理委員會是公司項目管理的最高決策機構，一般由公司總經理、副總經理組成。主要職責如下：（ 1）依照項目管理相關制度管理項目；（ 2）監督項目管理相關制度的執行；（ 3）對項目立項、項目撤消進行決策；（ 4）任命項目管理小組組長、項目評審委員會主任、項目組組長.項目管理小組項目管理小組對項目管理委員會負責，一般由公司管理人員組成。主要職責如下：（ 1）草擬項目管理的各項制度；（ 2）組織項目階段評審；（ 3）保存項目過程中的相關文件和數據；（ 4）為優化項目管理提出建議。項目評審小組項目評審小組對項目管理委員會負責，可下設

14、開發評審小組和產品評審小組，一般由公司技術專家和市場專家組成。主要職責如下：（ 1）對項目可行性報告進行評審；（ 2）對市場計劃和階段報告進行評審；（ 3）對開發計劃和階段報告進行評審；（ 4）項目結束時，對項目總結報告進行評審。軟件產品項目組軟件產品項目組對項目管理委員會負責，可下設軟件項目組和產品項目組。軟件項目組和產品項目組分別設開發經理和產品經理。成員一般由公司技術人員和市場人員構成。主要職責是：根據項目管理委員會的安排具體負責項目的軟件開發和市場調研及銷售工作。2.4 軟件項目管理- 軟件項目管理的內容從軟件工程的角度講，軟件開發主要分為六個階段：需求分析階段、概要設計階段、詳細設計

15、階段、編碼階段、測試階段、安裝及維護階段。不論是作坊式開發，還是團隊協作開發，這六個階段都是不可缺少的。根據公司實際情況，公司在進行軟件項目管理時，重點將軟件配置管理、項目跟蹤和控制管理、軟件風險管理及項目策劃活動管理四方面內容導入軟件開發的整個階段。在 20 世紀 80年代初，著名軟件工程專家B.W.Boehm總結出了軟件開發時需遵循的七條基本原則，同樣，在進行軟件項目管理時，也應該遵循這七條原則。它們是：（ 1 ）用分階段的生命周期計劃嚴格管理；（ 2）堅持進行階段評審；（ 3）實行嚴格的產品控制；（ 4）采用現代程序設計技術；（ 5）結果應能夠清楚地審查；（ 6）開發小組地人員應該少而精

16、；（ 7）承認不斷改進軟件工程實踐的必要性。2.5 軟件項目管理- 編寫軟件項目計劃書項目組成立的第一件事是編寫軟件項目計劃書，在計劃書中描述開發日程安排、 資源需求、項目管理等各項情況的大體內容。計劃書主要向公司各相關人員發放，使他們大體了解該軟件項目的情況。對于計劃書的每個內容，都應有相應具體實施手冊，這些手冊是供項目組相關成員使用的。2.6 軟件項目管理- 軟件配置管理是否進行配置管理與軟件的規模有關，軟件的規模越大，配置管理就顯得越重要。軟件配置管理簡稱SCMSoftware ConfigurationManagemen的縮寫）,是在團隊開發中，標識、 控制和管理軟件變更的一種管理。配

17、置管理的使用取決于項目規模和復雜性以及風險水平。目前軟件開發中面臨的問題: 在有限的時間、資金內，要滿足不斷增長的軟件產品質量要求；開發的環境日益復雜，代碼共享日益困難，需跨越的平臺增多；程序的規模越來越大；軟件的重用性需要提高；軟件的維護越來越困難。軟件配置管理應提供的功能:在 ISO9000.3 中， 對配置管理系統的功能作了如下描述：唯一地標識每個軟件項的版本；標識共同構成一完整產品的特定版本的每一軟件項的版本；控制由兩個或多個獨立工作的人員同時對一給定軟件項的更新；控制由兩個或多個獨立工作的人員同時對一給定軟件項的更新；按要求在一個或多個位置對復雜產品的更新進行協調；標識并跟蹤所有的措

18、施和更改；這些措施和更改是在從開始直到放行期間，由于更改請求或問題引起的。版本管理軟件配置管理分為版本管理、問題跟蹤和建立管理三個部分，其中 版本管理是基礎。版本管理應完成以下主要任務： 建立項目； 重構任何修訂版的某一項或某一文件； 利用加鎖技術防止覆蓋；當增加一個修訂版時要求輸入變更描述； 提供比較任意兩個修訂版的使用工具； 采用增量存儲方式； 提供對修訂版歷史和鎖定狀態的報告功能； 提供歸并功能； 允許在任何時候重構任何版本； 權限的設置； 晉升模型的建立； 提供各種報告。2.7 軟件項目管理- 人員組織與管理軟件開發中的開發人員是最大的資源。對人員的配置、調度安排貫穿整個軟件過程，人員

19、的組織管理是否得當，是影響對軟件項目質量的決定性因素。首先在軟件開發的一開始，要合理的配置人員，根據項目的工作量、所需要的專業技能，再參考各個人員的能力、性格、經驗，組織一個高效、和諧的開發小組。一般來說，一個開發小組人數在5 到 10 人之間最為合適，如果項目規模很大，可以采取層級式結構，配置若干個這樣的開發小組。在選擇人員的問題上，要結合實際情況來決定是否選入一個開發組員。并不是一群高水平的程序員在一起就一定可以組成一個成功的小組。作為考察標準，技術水平、與本項目相關的技能和開發經驗、以及團隊工作能力都是很重要的因素。 一個一天能寫一萬行代碼但卻不能與同事溝通融洽的程序員，未必適合一個對組

20、員之間通訊要求很高的項目。還應該考慮分幾個網站開發項目，小組中有頁面美工、后臺服務程序、數據庫幾個部分，應該合理的組織各項工作的人員配比。對于一個中型農技110 網站， 對數據采集量要求較高，一個人員配比方案可以是2 個美工、2 個后臺服務程序編寫、3 個數據采集整理人員。可以用如下公式來對候選人員能力進行評分，達到一定分數的則可以考慮進'以是我.打受慢星比R給。工第H用！其0支./1 不1aI:11|塞乂“目中不草 Ct或注力，tJC h私rifr M也人需MM* 溫之的尊女目對此號戰 力一定黑1 國下府fit 意贊正修霄紀乾*工也威力立不瘠麻鼻上身祐心出如語怦等* -目人施朗工“冷

21、七口 *56卜Ct "只舉戒可能力.雨口日印少時濯r汗也代科怦百作法的盧*ci的耳CI1畜修周* *琳 E卬r題也需，開，尸手工，狀X3L手W*以讓工史巴國麗_!Cl開翼姓，“楫泣事怦夏方亞國*0*嗡鬢阡班idWB P：*JIrt7J#西匕西入開發組，但這個公式不包含對人員數量配比的考慮Score=EWiCi(i=1to8)Ci是對項目組人員各項能力的評估。其值含義如下 在決定一個開發組的開發人員數量時，除了考慮候選 人素質以外，還要綜合考慮項目規模、工期、預算、開發環境等因素的影響，下面是一個基于規模、工期和開發環境的人員數量計算公式:L=Ck*K1/3*td4/3L:開發規模，以

22、代碼行LOC*度量td:開發時間K:人員數Ck:技術常數表示開發環境的優劣取值2000:表示開發環境差，沒有系統的開發方法，缺乏文檔規范化設計；取值8000:表示開發環境較好；取值11000:表示開發環境優。在組建開發組時，還應充分估計到開發過程中的人員風險。 由于工作環境、待遇、 工作強度、公司的整體工作安排和其他無法預知的因素，一個項目尤其是開發周期較長的項目幾乎無可避免的要面臨人員的流入流出。如果不在項目初期對可能出現的人員風險進行充分的估計， 作必要的準備，一旦風險轉化為現實，將有可 能給整個項目開發造成巨大的損失。以較低的代價進行及早的預防是降低這種人 員風險的基本策略。具體來說可以

23、從以下幾個方面對人員風險進行控制：a .保證開發組中全職人員的比例，且項目核心部分的工作應該盡量由全職人員 來擔任，以減少兼職人員對項目組人員不穩定性的影響。b.建立良好的文檔管理機制，包擴項目組進度文檔、個人進度文檔、版本控制 文檔、整體技術文檔、個人技術文檔、源代碼管理等。一旦出現人員的變動，比 如某個組員因病退出，替補的組員能夠根據完整的文檔盡早接手工作。c .加強項目組內技術交流，比如定期開技術交流會，或根據組內分工建立項目 組內部的開發小組，是開發小組內的成員能夠相互熟悉對方的工作和進度，能夠 在必要的時候替對方工作。d.對于項目經理，可以從一開始就指派一個副經理在項目中協同項目經理

24、管理項目開發工作，如果項目經理退出開發組，副經理可以很快接手。但是只建議在項目經理這樣的高度重要的崗位采用這種冗余復制的策略來預防人員風險，否則將大大增加項目成本。e.為項目開發提供盡可能好的開發環境，包括工作環境、待遇、工作進度安排等等， 同 時一個優秀的項目經理應該能夠在項目組內營造一種良好的人際關系 和工作氛圍。良好的開發環境對于穩定項目組人員以及提高生產效率都有不可忽視的作用。3、人月神話讀后感人月神話讀后感二十九年前(1975),舊M大型電腦之父 Fred Brooks出版一本書：”The Mythical Man-Month" 。收集了他在1960年代領導1000多人共同

25、發展OS/360大型軟件系統的心得和經驗。該書是論文集，其中有一篇文章叫 "The Mythical Man-Month",他就以此作為書名。在19561965之間，Brooks實際領導 舊M 360 大型電腦的開發計劃,包括硬體結構及龐大的OS/360作業系統在內,因之他具有IBM大型電腦之父白尊稱。由于 OS/360是多達1000位程式師共同合作的大 型軟件開發工作，讓他深刻了解到大型軟件開發的技術和管理上所面臨的種種 困難和挑戰。于是，他就將其領導開發OS/360軟件系統的經驗心得收集在這本書里。人們常拿Man-Month (多少人，做多少個月)來計算軟件的工作量，但

26、 是Brooks發現軟件的開發工作是需要人與人之間密切溝通的,使得設計工作不 易分割，所以Man-Month為單位的計算方法是有問題的(mythical)。也就得出 著名的Brooks法則對于進度已落后的軟件開發計劃而言，若再增加人力,只會讓其更力口落后。 (Adding manpowerto a late software project makes it later) 這是該書名稱的涵義?？赐甏藭?，我發現人月神話無處不在，其實在我們做軟件工程來說，此書已經滲透進去了。本書作者為人們管理復雜項目提供了頗具洞察力的見解，既有很多發人深省的觀點，也有大量的軟件工程實踐。本書對我觸動最大的，一是

27、保持設計的概念完整。無論對小軟件還是大軟件，都必須由一個設計師主導，最多兩個人討論來共同完成軟件的整體設計。作為一個軟件，一個系統，必須有一個清晰明確的概念模型，大家都在這個框架下工作，所有的創新發展都必須與基本的概念相吻合。具體的實現人員可以細化概念，但只有總設計者才有否定與發展基本概念的權力。需要注意的一點是，即使是總設計師一直是同一個人，他腦海中所認為理所當然的規則或者概念，很可能由于沒有明確的文檔化，而沒有成為所有開發者共同的概念。概念的完整性，對于很多小規模軟件，由于開發人員不多， 開發經理一般都能控制住所有的代碼，概念完整性在組織層面就維持住了。但要注意以后的Bug修改，功能擴展的

28、時候，也要時刻留意與最初的設計是否概 念上相容。對于大規模的軟件系統，則必須通過樹狀組織結構，層層控制，總設計師還是一到兩人，每一層都有對下層的絕對把握能力。二是“一個拿 2 倍工資的人，生產率可能是其他人的10 倍。 ”不知道其他公司的程序員們如何看。我覺得，作為公司，應該給最好的人最好的待遇，或者說給比目前更高的待遇。組建一個團隊，最好的就是那種精英團隊。微軟就是這種思路吧，把最聰明的人集中在一起，想不成功都難。三是進度落后與增加人力。向進度落后的項目中增加人手，只會使進度更加落后” 。以前，增加人手基本是挽救進度落后項目的主要辦法。這個辦法行不通的話，難道只有“加班”一條路了？如果不想加

29、班，不想削減功能，不想推遲發布日期，那么唯一的方法還是只有加人。加足夠的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能對原來的組織造成沖擊，或者對原來的設計有不同意見（特別是加入的人中有比較強大的設計者）。 那么， 就當作，新組建了一個團隊吧。交流，培訓新人，就設計達成一致，繼續向者目標前進。在此我說說我對書中印象最深的部分。焦油坑職業的樂趣：首先是一種創建事物的純粹快樂。其次，快樂來自于開發對其他人有用的東西。第三是真個過程體現出魔術般的力量將相互吻合的零部件組裝在一起。第四是學習的樂趣，來自于這項工作的的非重復特性。最后，樂趣還來自于工作在如此輕易駕馭的介質上。編程非常

30、有趣，在于它不僅滿足了我們內心深處進行創造的渴望，而且還愉悅了每個人內在的情感。當你看到一段段代碼編寫成功之后轉變成一個可以運行的軟件界面，這種從無到有的快樂是無法替代的； 同時它可以通過有形的介質（編程工具）將你心里的各種奇思妙想轉換為現實。 每個項目的開發是獨一無二的，每次的開發都能得到不同的體會和經驗。這是非常寶貴的。職業的苦惱：編程最困難的部分，是將做事的方式往追求完美的方向調整。軟件的編碼要求是非常挑剔的，一個字母的錯誤都會導致整個程序無法實現，而前期編碼不能做到嚴謹細致，會導致后期陷入無休止的改錯中，想想從幾千行甚至上萬行的代碼中尋找一個細微的錯誤，那是讓人奔潰的。其次是由他人來設

31、定目標，供給資源，提供信息。由于客戶一般都非專業的人員，所以他們所提供的需求表述可能是不準確的， 會導致需求的不斷變更，導致后期的編碼階段無法高效進行。所以在需求階段需要做好需求分析，盡可能的去完善客戶的需求，防止給后期造成困擾。同時客戶對項目的完成時間和資源的提供可能是不合理的，只是出于商業目的的考慮， 并沒有考慮到實際開發所需要的時間，這個往往會導致不停的加班趕工，同時項目組也需要與客戶進行協商溝通，把項目完成時間控制在雙方都可接受的范圍內。既能達到客戶的要求，也不至于自己手忙腳亂，最終陷入死循環。對于系統編程人員來說，對他人的依賴是一件非常痛苦的事。他依靠的其他人的程序，而往往這些程序設

32、計的并不合理，實現拙劣，發布不完整或者文檔記錄很糟糕。所以編程人員不得不花時間去研究和修改，而他們在理想情況下本應該是可靠完整的，所以項目開發應該設定統一的規范，每個程序都要按照規范來編寫源代碼和文檔。這樣才能在交接的時候其他的成員才能快速消化你的工作，然后進行后續的任務。下一個煩惱，概念的設計是有趣的，但尋找瑣碎的bug卻只是一項重復性的枯燥的活動。伴隨著創造性活動的，往往是枯燥沉悶的時間和艱苦的勞動，編程也不例外。在調試過程中,bug的出現往往是不可避免的,而 bug的尋找往往是很枯燥的，但又必須去進行，所以對于這種煩悶枯燥但又必須進行的工作，是讓人非常無奈的。最后一個煩惱，也是最無奈的，當投入了大量的辛苦勞動，產品在即將完成或終于完成的時候，已經顯得陳舊過時了。可能是同事和競爭對手已經有了更新，更好的構思。這就要求項目開發必須做好對市場的調查，同時也要安排合理的開發時間。避免冗長的時間導致項目最終成果已經過時。焦油坑的部分是最讓人印象深刻的，它系統的描述了軟件開發的樂趣和煩 惱，而針對這些煩惱所提出來的各種應對措施就是軟件項目管理。外科手術隊伍項目經理在項目的初期必