開題報(bào)告-項(xiàng)目控制軟件的設(shè)計(jì)與實(shí)現(xiàn)

1、畢業(yè)設(shè)計(jì)（論文）材料之二（2）本科畢業(yè)設(shè)計(jì)（論文）開題報(bào)告題目：項(xiàng)目控制軟件的設(shè)計(jì)與實(shí)現(xiàn)Design and Implementation of Project Control 課 題 類 型：設(shè)計(jì) 實(shí)驗(yàn)研究 論文學(xué) 生 姓 名： 楊 芳 文 學(xué) 號(hào)： 3070701320 專 業(yè) 班 級(jí)： 計(jì)算機(jī)081班學(xué) 院： 計(jì)算機(jī)與信息學(xué)院 指 導(dǎo) 教 師： 王 勇開 題 時(shí) 間： 2012年 2月2012 年 2月 16日一、本課題的研究意義、研究現(xiàn)狀和發(fā)展趨勢(shì)隨著互聯(lián)網(wǎng)的發(fā)展，以及Web 2.0概念的逐步為大眾所接受，各種以“用戶生成內(nèi)容 (User Generated Content, UGC)

2、”為核心理念、強(qiáng)調(diào)個(gè)人之間的互聯(lián)與分享、建立在良好的用戶體驗(yàn)上的新一代網(wǎng)站如雨后春筍涌現(xiàn)出來(lái)。其中，以“軟件即服務(wù)(Software as a Service, SaaS)”為主導(dǎo)理念的網(wǎng)站是比較特別的一支。軟件即服務(wù)倡導(dǎo)的是將軟件部署為托管服務(wù)并通過(guò) 互聯(lián)網(wǎng)進(jìn)行訪問(wèn)，也就是我們通常聽到的把桌面軟件網(wǎng)絡(luò)化。由此，各種基于Web的項(xiàng)目控制軟件應(yīng)運(yùn)而生。項(xiàng)目控制的作用就是為了保證項(xiàng)目按照預(yù)期的項(xiàng)目目標(biāo)進(jìn)行，必須對(duì)項(xiàng)目的運(yùn)行情況和輸出進(jìn)行持續(xù)的跟蹤監(jiān)控，收集各種項(xiàng)目進(jìn)展信息，對(duì)收集的信息進(jìn)行分析，與預(yù)期的項(xiàng)目目標(biāo)進(jìn)行比較。在出現(xiàn)偏差時(shí)及時(shí)分析偏差原因，制定有效的糾正預(yù)防措施，落實(shí)糾正預(yù)防措施。項(xiàng)目的

3、特點(diǎn)是漸進(jìn)明晰的，特別地軟件開發(fā)項(xiàng)目更因?yàn)槠浣Y(jié)果的無(wú)形性、需求難以明確性、勞動(dòng)密集性和智力密集性，“漸進(jìn)明晰”這一特點(diǎn)更加顯著。在項(xiàng)目的初期，項(xiàng)目經(jīng)理或項(xiàng)目成員基本上不可能像建設(shè)一棟有形的建筑一樣，預(yù)想出項(xiàng)目實(shí)施過(guò)程中的所有情況（對(duì)于建筑行業(yè)來(lái)說(shuō)，不可預(yù)見的主要是一些不可抗力，如天氣、人員的流失、供貨的及時(shí)性）。所以，盡管已經(jīng)盡可能明確制定了項(xiàng)目目標(biāo)，并以此為目標(biāo)制定了盡可能周密的計(jì)劃，如果沒(méi)有對(duì)照項(xiàng)目計(jì)劃進(jìn)行嚴(yán)密的監(jiān)控，并及時(shí)調(diào)整計(jì)劃，不斷使計(jì)劃明晰化并符合實(shí)際，以盡可能地保證項(xiàng)目按照基準(zhǔn)計(jì)劃實(shí)施，并使計(jì)劃的變更盡可能地減少，那么項(xiàng)目就很難達(dá)到原先計(jì)劃中制定的目標(biāo)。這些目標(biāo)要同時(shí)兼顧進(jìn)度、質(zhì)

4、量、成本。 所以不僅要制定出好的項(xiàng)目計(jì)劃，更要進(jìn)行嚴(yán)密的項(xiàng)目控制。項(xiàng)目控制是項(xiàng)目經(jīng)理的一項(xiàng)重要職責(zé)，也是項(xiàng)目控制部門、項(xiàng)目成員、項(xiàng)目干系人的重要職責(zé)。 項(xiàng)目控制是IT行業(yè)的一個(gè)富有創(chuàng)新意義的領(lǐng)域，是針對(duì)特定的項(xiàng)目需求，以團(tuán)隊(duì)運(yùn)作的形式，有效地組織項(xiàng)目資源，通過(guò)對(duì)項(xiàng)目的管理和控制，實(shí)現(xiàn)項(xiàng)目的目標(biāo)。在我國(guó)IT行業(yè)起步較晚，但發(fā)展迅速，項(xiàng)目控制在IT行業(yè)的應(yīng)用還很不成熟，一般的、常規(guī)的組織管理方式已很難適應(yīng)，這是軟件開發(fā)中項(xiàng)目控制面臨的最大挑戰(zhàn)。在項(xiàng)目實(shí)施中往往會(huì)出現(xiàn)如下問(wèn)題：1、對(duì)項(xiàng)目控制認(rèn)識(shí)和重視不夠項(xiàng)目經(jīng)理或管理人員不十分了解項(xiàng)目控制的知識(shí)體系，所以在實(shí)際工作中沒(méi)有項(xiàng)目控制知識(shí)的指導(dǎo)，完全依靠

5、個(gè)人現(xiàn)有的知識(shí)技能，管理工作的隨意性、盲目性比較大。在軟件企業(yè)中，項(xiàng)目經(jīng)理主要是因?yàn)樗麄兡軌蛟诩夹g(shù)上獨(dú)當(dāng)一面，而管理方面特別是項(xiàng)目控制方面的知識(shí)比較缺乏。希望盡快推行和實(shí)施軟件項(xiàng)目經(jīng)理知識(shí)技能資格制度，各方面都能充分認(rèn)識(shí)項(xiàng)目控制的重要性，讓項(xiàng)目經(jīng)理自覺學(xué)習(xí)項(xiàng)目控制的知識(shí)和一些常用工具和方法。2、對(duì)項(xiàng)目的系統(tǒng)性把握不夠在軟件企業(yè)一些項(xiàng)目控制人員對(duì)項(xiàng)目總體計(jì)劃、階段計(jì)劃的作用認(rèn)識(shí)不足。項(xiàng)目經(jīng)理認(rèn)為計(jì)劃不如變化快，項(xiàng)目中也有很多不確定的因素，做計(jì)劃是走過(guò)場(chǎng)，因此制定總體計(jì)劃時(shí)比較隨意，造成計(jì)劃與控制管理脫節(jié)，無(wú)法進(jìn)行有效的進(jìn)度控制管理。其實(shí)制定計(jì)劃的過(guò)程就是一個(gè)對(duì)項(xiàng)目逐漸了解掌握的過(guò)程，通過(guò)認(rèn)真地制

6、定計(jì)劃，項(xiàng)目控制人員可以知道哪些要素是明確和重要的，哪些要素是要逐漸明確和次要的，通過(guò)漸近明細(xì)不斷完善項(xiàng)目計(jì)劃。制定計(jì)劃的過(guò)程，也是在進(jìn)度、資源、范圍之間尋求一種平衡的過(guò)程。因此，提高項(xiàng)目控制人員的計(jì)劃意識(shí)，加強(qiáng)對(duì)開發(fā)計(jì)劃、階段計(jì)劃的有效性，并進(jìn)行事前事后的評(píng)估。3、管理思想貫徹不到位 項(xiàng)目經(jīng)理如果沒(méi)有從總體上去把握管理整個(gè)項(xiàng)目，而是埋頭于具體的技術(shù)工作，造成項(xiàng)目組成員之間任務(wù)不均、資源浪費(fèi)。在軟件企業(yè)中，項(xiàng)目經(jīng)理大多是技術(shù)骨干，技術(shù)方面的知識(shí)比較深厚，但無(wú)論是項(xiàng)目控制知識(shí)，還是項(xiàng)目控制必備的技能、項(xiàng)目控制必備的素質(zhì)都有待補(bǔ)充和提高。同時(shí)由于工作分解結(jié)構(gòu)設(shè)計(jì)的缺乏合理性，項(xiàng)目任務(wù)無(wú)法有效、合理

7、地分配給相關(guān)成員，以達(dá)到“負(fù)載均衡”。因此加強(qiáng)項(xiàng)目經(jīng)理在項(xiàng)目控制知識(shí)方面的培訓(xùn)和考核，引導(dǎo)項(xiàng)目經(jīng)理更好地做好項(xiàng)目控制工作。 4、溝通的效率不高在項(xiàng)目中一些重要信息沒(méi)有進(jìn)行充分和有效的溝通。在制定計(jì)劃、意見反饋、情況通報(bào)、技術(shù)問(wèn)題或成果等方面與相關(guān)人員的溝通不足，造成各做各事、重復(fù)勞動(dòng)，甚至造成不必要的損失。在項(xiàng)目溝通管理方面：管理者要用70的時(shí)間用于與人溝通，而項(xiàng)目經(jīng)理需要花費(fèi)90或更多的時(shí)間來(lái)溝通。所以項(xiàng)目控制人員不但自己要把工作重點(diǎn)放在溝通上，而且要善于溝通，以提高溝通意識(shí)和溝通的效率。5、對(duì)付風(fēng)險(xiǎn)的策略不成熟 項(xiàng)目控制人員沒(méi)有充分分析可能的風(fēng)險(xiǎn)，對(duì)付風(fēng)險(xiǎn)的策略考慮比較簡(jiǎn)單。有些項(xiàng)目控制人

8、員沒(méi)有充分意識(shí)到風(fēng)險(xiǎn)管理的重要性，對(duì)計(jì)劃書中風(fēng)險(xiǎn)管理的章節(jié)簡(jiǎn)單應(yīng)付了事，隨便列出幾個(gè)風(fēng)險(xiǎn)和一些簡(jiǎn)單的對(duì)策，對(duì)于后面的風(fēng)險(xiǎn)防范起不到一定指導(dǎo)作用。項(xiàng)目風(fēng)險(xiǎn)管理是對(duì)項(xiàng)目潛在的意外損失進(jìn)行規(guī)劃、識(shí)別、估計(jì)、評(píng)價(jià)、應(yīng)對(duì)和監(jiān)控的過(guò)程，是對(duì)項(xiàng)目目標(biāo)的主動(dòng)控制手段。因此通過(guò)學(xué)習(xí)項(xiàng)目控制知識(shí)，掌握風(fēng)險(xiǎn)識(shí)別、量化、對(duì)策研究、反應(yīng)控制的工具和方法，加強(qiáng)對(duì)項(xiàng)目規(guī)劃中風(fēng)險(xiǎn)管理計(jì)劃的審核，提高項(xiàng)目組的風(fēng)險(xiǎn)管理意識(shí)。以上對(duì)軟件開發(fā)項(xiàng)目控制中容易出現(xiàn)的問(wèn)題的分析可能還不夠深入，無(wú)法列舉所有遇到或?qū)⒂龅降膯?wèn)題，解決辦法也只能在際情況中把握。 我國(guó)的許多軟件企業(yè)按項(xiàng)目方式運(yùn)作已有多年，在這期間，我國(guó)軟件企業(yè)進(jìn)行了不懈地探索，有

9、成功的經(jīng)驗(yàn)，也有失敗的教訓(xùn)，其中主要體現(xiàn)在以下幾個(gè)方面： 1、客戶滿意作為項(xiàng)目控制的最終目標(biāo) 客戶是項(xiàng)目的委托方，也是項(xiàng)目的受用方，如何使客戶對(duì)項(xiàng)目的最終結(jié)果感到滿意，是項(xiàng)目控制的一個(gè)核心問(wèn)題。為讓客戶滿意項(xiàng)目組要樹立以客戶為中心的觀念，項(xiàng)目控制的整個(gè)生命周期都要面向客戶，并把客戶滿意度作為衡量項(xiàng)目成敗的一個(gè)重要指標(biāo)，使項(xiàng)目組的利益與客戶的利益緊密地聯(lián)系在一起。項(xiàng)目的需求就是客戶的需求，它應(yīng)包括客戶的現(xiàn)實(shí)需求和潛在需求。信息技術(shù)的迅速發(fā)展，導(dǎo)致IT行業(yè)客戶需求的多樣性、多變性、不確定性和個(gè)性化。軟件產(chǎn)品或解決方案需要企業(yè)與客戶在充分溝通的基礎(chǔ)上，共同提取、挖掘，從而不斷逼近客戶的真正需求，客戶

10、與企業(yè)之間體現(xiàn)出很強(qiáng)的互動(dòng)性。2項(xiàng)目控制要面向結(jié)果，首先要面向人 項(xiàng)目控制要以人為本，項(xiàng)目經(jīng)理首先是人力資源經(jīng)理，對(duì)于知識(shí)密集型的軟件企業(yè)來(lái)說(shuō)，尤其如此。通過(guò)項(xiàng)目為員工提供平臺(tái)，通過(guò)員工的發(fā)展目標(biāo)與項(xiàng)目目標(biāo)的有機(jī)結(jié)合，使員工在項(xiàng)目的平臺(tái)上實(shí)現(xiàn)自我的價(jià)值。3項(xiàng)目控制的挑戰(zhàn)性和推動(dòng)力項(xiàng)目控制的實(shí)施，特別是全面推行項(xiàng)目控制，對(duì)于軟件企業(yè)而言，不是一改變，而是一種變革，是一項(xiàng)長(zhǎng)期性、艱巨性的任務(wù)。因此，企業(yè)首先要有開放的心態(tài)，要勇于改革，并能以長(zhǎng)遠(yuǎn)的眼光和勇氣正確對(duì)待項(xiàng)目開發(fā)中出現(xiàn)的問(wèn)題，不因暫時(shí)的困難和挫折而放棄。其次要有務(wù)實(shí)的態(tài)度，要有相應(yīng)的措施和落實(shí)的力度，推動(dòng)項(xiàng)目的進(jìn)程和開發(fā)效率的提高。 目前

11、，我國(guó)軟件開發(fā)和項(xiàng)目控制水平與美國(guó)、印度等國(guó)家相比還不高。而國(guó)外水平比較高的軟件公司軟件開發(fā)流程和項(xiàng)目控制十分規(guī)范，隨著世界范圍軟件業(yè)的發(fā)展，在我國(guó)已有越來(lái)越多的軟件公司重視流程和項(xiàng)目控制，軟件業(yè)的春天一定會(huì)來(lái)臨。二、研究方案及工作計(jì)劃設(shè)計(jì)目標(biāo)：搭建一個(gè)在線項(xiàng)目管理協(xié)作平臺(tái)，方便項(xiàng)目負(fù)責(zé)人對(duì)于項(xiàng)目的規(guī)劃、管理、任務(wù)分配和整體的把握，成員之間協(xié)作、溝通、分享資料和互相通知，以適應(yīng)項(xiàng)目和團(tuán)隊(duì)的快速變化和遠(yuǎn)程協(xié)作。功能描述：在線項(xiàng)目控制系統(tǒng)是部署于WEB服務(wù)器上的B/S架構(gòu)應(yīng)用系統(tǒng)。系統(tǒng)用戶可以使用設(shè)定的帳號(hào)登錄系統(tǒng)。系統(tǒng)提供項(xiàng)目管理、人員管理、任務(wù)列表和消息板功能。由項(xiàng)目管理員創(chuàng)建或是添加項(xiàng)目，添

12、加邀請(qǐng)項(xiàng)目成員加入到相應(yīng)的項(xiàng)目中，查看項(xiàng)目信息以及結(jié)束項(xiàng)目。 在人員管理功能模塊下項(xiàng)目管理員可以添加用戶，修改用戶基本信息，給用戶賦角色查看用戶信息，按角色查看用戶。 任務(wù)列表模塊則可以對(duì)任務(wù)進(jìn)行管理，如新建任務(wù)列表，在任務(wù)列表下添加任務(wù)，將任務(wù)分配給某個(gè)成員，設(shè)置任務(wù)的優(yōu)先級(jí)，設(shè)置任務(wù)的為完成，對(duì)任務(wù)進(jìn)行評(píng)論，按任務(wù)所有者過(guò)濾任務(wù)。 消息板模塊主要是實(shí)現(xiàn)成員間交流共享信息。成員可以發(fā)送消息，并選擇通知的成員，添加消息類別，添加消息評(píng)論，按類別查看消息。應(yīng)用系統(tǒng)角色和用戶：在線項(xiàng)目控制系統(tǒng)的角色分為部門經(jīng)理、項(xiàng)目經(jīng)理、小組長(zhǎng)、項(xiàng)目成員。系統(tǒng)包括各功能模塊如表1所示：表1 功能模塊說(shuō)明模塊名稱子

13、模塊功能描述項(xiàng)目管理 申請(qǐng)項(xiàng)目申請(qǐng)啟動(dòng)一個(gè)項(xiàng)目項(xiàng)目審核高層決定是否啟動(dòng)項(xiàng)目添加項(xiàng)目添加一個(gè)新項(xiàng)目結(jié)束項(xiàng)目 將一個(gè)項(xiàng)目設(shè)置為終結(jié) 查看項(xiàng)目信息查看項(xiàng)目完成情況，項(xiàng)目?jī)?nèi)容 邀請(qǐng)成員 邀請(qǐng)成員加入到項(xiàng)目中 人員管理 查看用戶信息查看已存在用戶信息用戶信息維護(hù)修改用戶信息添加用戶 添加新用戶給用戶賦角色 對(duì)已存在用戶賦予角色 分角色查看用戶 按不同的角色查看用戶 任務(wù)列表 新建任務(wù)列表 創(chuàng)建一個(gè)新的任務(wù)列表到項(xiàng)目中 在任務(wù)列表中添加任務(wù) 在任務(wù)類表中添加任務(wù) 設(shè)置任務(wù)優(yōu)先級(jí) 對(duì)任務(wù)設(shè)置優(yōu)先級(jí) 設(shè)置任務(wù)完成對(duì)任務(wù)進(jìn)行評(píng)論 分配任務(wù) 分配任務(wù)給成員消息板添加消息類別 添加消息 選擇消息通知成員選擇Emai

14、l通知 按類別查看消息 發(fā)表消息評(píng)論 針對(duì)該項(xiàng)目的任務(wù)量和完成時(shí)限，具體工作計(jì)劃如下：周次任務(wù)說(shuō)明第1周查閱資料，了解課題收集和閱讀相關(guān)資料文獻(xiàn)，確定相關(guān)開發(fā)技術(shù)第2周第3周撰寫開題報(bào)告第4周第5周需求分析完成用例圖、數(shù)據(jù)流圖、數(shù)據(jù)字典、ER圖等相關(guān)內(nèi)容。第6周第7周概要設(shè)計(jì)完成系統(tǒng)總體功能設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)第8周第9周詳細(xì)設(shè)計(jì)完成后臺(tái)編碼設(shè)計(jì)和前臺(tái)頁(yè)面設(shè)計(jì)，對(duì)每個(gè)模塊進(jìn)行單元測(cè)試第10周第11周第12周第13周測(cè)試與優(yōu)化完善、優(yōu)化系統(tǒng)，對(duì)項(xiàng)目進(jìn)行集成測(cè)試，使系統(tǒng)工作在最佳狀態(tài)第14周第15周第16周撰寫畢業(yè)設(shè)計(jì)論文第17周第18周準(zhǔn)備答辯和答辯第19周三、主要參考文獻(xiàn)1 羅鐵清,王瑩,王如龍.

15、 軟件項(xiàng)目管理流程分析與設(shè)計(jì)J. 計(jì)算技術(shù)與自動(dòng)化,2005,(03)2 朱利娜,周寧. 軟件項(xiàng)目管理的思考J. 平原大學(xué)學(xué)報(bào),2007,(02)3 楊智明. 軟件項(xiàng)目管理過(guò)程J. 科教文匯(下半月),2006,(09)4 陸偉. 軟件項(xiàng)目管理及其在中小規(guī)模開發(fā)中的實(shí)施J. 電腦知識(shí)與技術(shù), 2005,(08)5 郭國(guó)印,張秀偉,趙政文. 軟件項(xiàng)目管理技術(shù)分析研究J. 微處理機(jī),2007,(05)6 周慧. 論軟件項(xiàng)目管理J. 現(xiàn)代電子技術(shù),2003,(18)7 鄧杰超. 軟件項(xiàng)目管理探析J. 華南金融電腦,2007,(01)8 竇燕. 影響軟件項(xiàng)目管理關(guān)鍵因素的探討J. 燕山大學(xué)報(bào),2004

16、,(04)9 李凌. 軟件項(xiàng)目管理中的進(jìn)度控制問(wèn)題研究J. 中國(guó)科技信息,2005,(17) 10 陳麗杰. 淺析軟件項(xiàng)目管理中的需求管理J. 科技資訊, 2007,(14)11 席相霖.解析項(xiàng)目管理J.中國(guó)計(jì)算機(jī)用戶,2002,(11)12 武映峰.項(xiàng)目管理全接觸J.軟件工程師,2002,(04)13 Johanna Rothman. Manage It!M. 人民郵電出版社,200914 Frederick P.Brooks.Jr. The Mythical Man-Month. 清華大學(xué)出版社,2007外文文獻(xiàn)選譯The Mythical Man-MonthGood cooking fa

17、kes time. If you are made to wait, it is to serve you better, and to please you.MENU OF RESTAURANT ANTOINE. NEW ORLEANSMore software projects have gone awry for lack of calendar timethan for all other causes combined. Why is this cause of disaster so common?First, our techniques of estimating are po

18、orly developed. More seriously, they reflect an unvoiced assumption which is quite untrue,i.e., that all will go well.Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.Third, because we are uncertain of our esti

19、mates, software managers often lack the courteous stubbornness of Antoine's chef.Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.Fifth, when schedule slippage is recognized, t

20、he natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.Schedule monitoring will be the subject of a separate essay.Let us consider

21、 other aspects of the problem in more detail.OptimismAll programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy godmothers.Perhaps the hundreds of nitty frustrations drive away allbut those who habitually focus on the end goal. Perhaps

22、 it ismerely that computers are young, programmers are younger, andthe young are always optimists. But however the selection processworks, the result is indisputable: "This time it will surely run," or"I just found the last bug."So the first false assumption that underlies the sc

23、heduling of systems programming is that all will go well, i.e., that each task will hike only as long as it "ought" to take.The pervasiveness of optimism among programmers deserves more than a flip analysis. Dorothy Sayers, in her excellent book,The Mind of the Maker, divides creative acti

24、vity into three stages:the idea, the implementation, and the interaction. A book, then,or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mindof the author. It is realized in time and space, by pen, ink, andpaper, or by wir

25、e, silicon, and ferrite. The creation is completewhen someone reads the book, uses the computer, or runs theprogram, thereby interacting with the mind of the maker.This description, which Miss Sayers uses to illuminate notonly human creative activity but also the Christian doctrine of the Trinity, w

26、ill help us in our present task. For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. Thus it is that writing,experimentation, "working out" are essential disciplines for the theoretician.In many creative activities

27、the medium of execution is intractable.Lumber splits; paints smear; electrical circuits ring. These physical limitations of the medium constrain the ideas that may be expressed, and they also create unexpected difficulties in theimplementation.Implementation, then, takes time and sweat both because

28、of the physical media and because of the inadequacies of the underlying ideas. We tend to blame the physical media for most of our implement-tation difficulties; for the media are not "ours" in the way the ideas are, and our pride colors our judgment.Computer programming, however, creates

29、with an exceedingly tractable medium. The programmer builds from pure thought-stuff: concepts and very flexible representations thereof.Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our o

30、ptimism is unjustified.In a single task, the assumption that all will go well has a probabilistic effect on the schedule. It might indeed go as planned.for there is a probability distribution for the delay that will be encountered, and "no delay" has a finite probability. A large programmi

31、ng effort, however, consists of many tasks, some chained end-to-end. The probability that each will go well becomes vanishingly small.The'Man-MonthThe second fallacious thought mode is expressed in the very unit of effort used in estimating and scheduling: the man-month. Cost does indeed vary as

32、 the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.Men and months are interchangeable commodities only when a task can be pa

33、rtitioned among many workers with no communication among them (Fig. 2.1). This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.Fig. 2.1 Time versus number of workersperfectly partitionable taskWhen a task cannot be partitioned because of sequentia

34、l constraints,the application of more effort has no effect on the schedule(Fig. 2.2). The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have thischaracteristic because of the sequential nature of debugging.Fig. 2.2 Time versus number of workersunpar

35、titionable taskIn tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done. Therefore the best that can be done is somewhat poorer than an even trade of men for months (Fig. 2.3).Fig. 2.3 Time versus

36、number of workerspartitionable task requiring communicationThe added burden of communication is made up of two parts,training and inter- communication. Each worker must be trained in the technology, the goals of the effort, the overall strategy, and theplan of work. This training cannot be partition

37、ed, so this part ofthe added effort varies linearly with the number of workers.1Intercommunication is worse. If each part of the task must be separately coordinated with each other part/ the effort increases as n(n-I)/2. Three workers require three times as much pairwiseintercommunication as two; fo

38、ur require six times as much as two.If, moreover, there need to be conferences among three, four, etc.,workers to resolve things jointly, matters get worse yet. The addedeffort of communicating may fully counteract the division of theoriginal task and bring us to the situation of Fig. 2.4.Fig. 2.4 T

39、ime versus number of workerstask with complex interrelationshipsSince software construction is inherently a systems effortanexercise in complex interrelationshipscommunication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more me

40、n then lengthens, not shortens, the schedule.Systems TestNo parts of the schedule are so thoroughly affected by sequential constraints as component debugging and system test. Furthermore,the time required depends on the number and subtlety of the errors encountered. Theoretically this number should

41、be zero.Because of optimism, we usually expect the number of bugs to be smaller than it turns out to be. Therefore testing is usually the most mis-scheduled part of programming.For some years I have been successfully using the following rule of thumb for scheduling a software task:l/3 planningl/6 co

42、dingl/4 component test and early system testl/4 system test, all components in hand.This differs from conventional scheduling in several importantways:1. The fraction devoted to planning is larger than normal. Even so, it is barely enough to produce a detailed and solid specification,and not enough

43、to include research or exploration of totally new techniques.2. The half of the schedule devoted to debugging of completed code is much larger than normal.3. The part that is easy to estimate, i.e., coding, is given only one-sixth of the schedule.In examining conventionally scheduled projects, I hav

44、e found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose. Many of these were on schedule until and except in system testing.2Failure to allow enough time for system test, in particular, is peculiarly disastro

45、us. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date. Bad news, late and without warning, is unsettling to customers and to managers.Furthermore, delay at this point has unusually severe financial,as well as psychological, repercuss

46、ions. The project is fully staffed, and cost-per-day is maximum. More seriously, the software is to support other business effort (shipping of computers, operation of new facilities, etc.) and the secondary costs of delaying these are very high, for it is almost time for software shipment.Indeed, th

47、ese secondary costs may far outweigh all others. It is therefore very important to allow enough system test time in the original schedule.Gutless EstimatingObserve that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot gover

48、n the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choiceswait or eat it raw. Software customers have had the same choices.The cook has another choice; he can turn up the heat. The result is

49、 often an omelette nothing can saveburned in one part, raw in another.Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers.But false scheduling to match the patron's desired date ismuch more common in our discipline than els

50、ewhere in engineering.It is very difficult to make a vigorous, plausible, and jobriskingdefense of an estimate that is derived by no quantitativemethod, supported by little data, and certified chiefly by thehunches of the managers.Clearly two solutions are needed. We need to develop and publicize pr

51、oductivity figures, bug-incidence figures, estimating rules, and so on. The whole prof ession can only profit from sharing such data.Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches

52、are better than wishderived estimates.Regenerative Schedule DisasterWhat does one do when an essential software project is behind schedule? Add manpower, naturally. As Figs. 2.1 through 2.4 suggest, this may or may not help.Let us consider an example.3 Suppose a task is estimated at 12 man-months an

53、d assigned to three men for four months, and that there are measurable mileposts A, B, C, D, which are scheduled to fall at the end of each month (Fig. 2.5).Now suppose the first milepost is not reached until two months have elapsed (Fig. 2.6). What are the alternatives facing the manager?1. Assume

54、that the task must be done on time. Assume that only the first part of the task was misestimated, so Fig. 2.6 tells the story accurately. Then 9 man-months of effort remain, and two months, so 4V£ men will be needed. Add 2 men to the 3 assigned.2.Assume that the task must be done on time. Assum

55、e that the whole estimate was uniformly low, so that Fig. 2.7 really describes the situation. Then 18 man-months of effort remain,and two months, so 9 men will be needed. Add 6 men to the assigned.Figure 2.5Figure 2,6Figure 2.73.Reschedule. I like the advice given by P. Fagg, an experienced hardware

56、 engineer, "Take no small slips." That is, allow enough time in the new schedule to ensure that the work can be carefully and thoroughly done, and that rescheduling will not have to be done again.4.Trim the task. In practice this tends to happen anyway, once the team observes schedule slip

57、page. Where the secondary costs of delay are very high, this is the only feasible action.The manager's only alternatives are to trim it formally and carefully, to reschedule, or to watch the task get silently trimmed by hasty design and incomplete testing.In the first two cases, insisting that t

58、he unaltered task be completed in four months is disastrous. Consider the regenerative effects, for example, for the first alternative (Fig. 2.8). The two new men, however competent and however quickly recruited, will requiretraining in the task by one of the experienced men. If this takes a month, 3 man-months will have been devoted to work not in the original estimate. Furthermo