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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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