軟件工程實(shí)施的幾個(gè)重要思想

1、6.8小結(jié)當(dāng)對(duì)軟件項(xiàng)目期望很高時(shí)，一般都會(huì)進(jìn)行風(fēng)險(xiǎn)分析。不過(guò)，即使他們進(jìn)行這項(xiàng)工作，大多數(shù)軟件項(xiàng)目管理者都是非正式地和表面上地完成它?；ㄔ跇?biāo)識(shí)、分析、和管理風(fēng)險(xiǎn)上的時(shí)間可以從多個(gè)方面得到回報(bào)：更加平穩(wěn)的項(xiàng)目進(jìn)展過(guò)程；較高的跟蹤和控制項(xiàng)目的能力；由于在問(wèn)題發(fā)生之前已經(jīng)做了周密計(jì)劃而產(chǎn)生的信心。風(fēng)險(xiǎn)分析需要占用大量項(xiàng)目計(jì)劃的工作量。標(biāo)識(shí)、預(yù)測(cè)、評(píng)估、管理、及監(jiān)控都要花費(fèi)時(shí)間。但這是值得的。引用中國(guó)2500多年前的兵法家孫子的 話：知己知彼，百戰(zhàn)不殆” 對(duì)于軟件項(xiàng)目管理者而言，這個(gè) 彼”指的 就是風(fēng)險(xiǎn)。思考題6.1舉出五個(gè)其他領(lǐng)域的例子來(lái)說(shuō)明與被動(dòng)風(fēng)險(xiǎn)策略相關(guān)的問(wèn)題。6.2描述已知風(fēng)險(xiǎn)”和可預(yù)測(cè)風(fēng)險(xiǎn)

2、”之間的差別。6.3在本章給出的所有風(fēng)險(xiǎn)檢查表中的條目中增加三個(gè)額外的問(wèn)題或主題。6.4你被要求建造一個(gè)軟件以支持一個(gè)低成本的視頻編輯系統(tǒng)。該系統(tǒng)將錄像帶作為輸入設(shè)備，將視頻信息存在磁盤(pán)上，并允許用戶對(duì)已經(jīng)數(shù)字化的視頻信息進(jìn)行各種編輯。對(duì)這類(lèi)系統(tǒng)做一些調(diào)研，然后列出當(dāng)你開(kāi)始啟動(dòng)該項(xiàng)目以建造視頻編輯系統(tǒng)時(shí)，你將面臨的技術(shù)風(fēng)險(xiǎn)是什么。6.5你是一家大型軟件公司的項(xiàng)目管理者。你被要求領(lǐng)導(dǎo)一個(gè)小組開(kāi)發(fā) 下一代”字處理軟件（見(jiàn)3.3.2節(jié)的簡(jiǎn)單描述）。為該項(xiàng)目建立一個(gè)風(fēng)險(xiǎn)表。6.6描述風(fēng)險(xiǎn)因素和風(fēng)險(xiǎn)驅(qū)動(dòng)因子之間的不同。6.7為項(xiàng)目風(fēng)險(xiǎn)驅(qū)動(dòng)因子建立一個(gè)加權(quán)方案。6.8為圖6-2中的三個(gè)風(fēng)險(xiǎn)建立風(fēng)險(xiǎn)緩解策略

3、及特定的風(fēng)險(xiǎn)緩解活動(dòng)。6.9為圖6-2中的三個(gè)風(fēng)險(xiǎn)建立風(fēng)險(xiǎn)監(jiān)控策略及特定的風(fēng)險(xiǎn)監(jiān)控活動(dòng)。確認(rèn)你已經(jīng)標(biāo)識(shí)出了你需要監(jiān)控的因素，并確定風(fēng)險(xiǎn)發(fā)生的可能性是否在變高或變低。6.10為圖6 2中的三個(gè)風(fēng)險(xiǎn)建立風(fēng)險(xiǎn)管理策略及特定的風(fēng)險(xiǎn)管理活 動(dòng)。6.11你能否想到一種情況：一個(gè)高概率、高影響的風(fēng)險(xiǎn)并不納入RMMM 計(jì)劃的考慮之中？6.12參照?qǐng)D6- 4所示的風(fēng)險(xiǎn)參考水平值，該曲線是否總是如圖顯示的 那么勻稱(chēng)光滑，或者是否會(huì)有該曲線扭曲變形的情況存在？如果有，請(qǐng)舉出一個(gè)例子。6.13做一些關(guān)于軟件安全方面的研究，并寫(xiě)一份簡(jiǎn)單的報(bào)告?？梢詤⒖?LEV95 做為起點(diǎn)。6.14描述五個(gè)軟件安全和危險(xiǎn)分析是主要關(guān)心

4、對(duì)象的軟件應(yīng)用領(lǐng)域。第7章項(xiàng)目進(jìn)度安排及跟蹤在六十年代后期，一位熱情的青年工程師受命為一個(gè)自動(dòng)制造應(yīng)用軟件項(xiàng)目 編寫(xiě)計(jì)算機(jī)程序。選擇他的原因非常簡(jiǎn)單，因?yàn)樵谡麄€(gè)技術(shù)小組中他是唯一參加過(guò)計(jì)算機(jī)編程培訓(xùn)班的人。這位工程師對(duì)匯編語(yǔ)言的IN和OUT指令以及 Fortran語(yǔ)言略知一二，但是卻根本不懂軟件工程，更不用說(shuō)項(xiàng)目進(jìn)度安排和跟蹤了。他的老板給了他一大堆相關(guān)的手冊(cè)，以及需要做些什么的口頭描述。年輕人被告知該 項(xiàng)目必須在兩個(gè)月之內(nèi)完成。他閱讀了這些手冊(cè)，想好了解決方法，就開(kāi)始編寫(xiě)代碼。兩周之后，老板將他叫到辦公室詢問(wèn)項(xiàng)目進(jìn)展情況。這個(gè)項(xiàng)目遠(yuǎn)比我想象的簡(jiǎn)單。我差不多已非常好，”工程師以年輕人的熱情回答

5、道, 經(jīng)完成了 75%的任務(wù)?！睖?zhǔn)備好一周后再老板笑了，說(shuō)道：真是太棒了。 ”然后他囑咐年輕人繼續(xù)努力工作, 匯報(bào)一次工作進(jìn)度。一周之后老板將年輕人叫到辦公室，問(wèn)他說(shuō)：現(xiàn)在進(jìn)度如何？ ” 一切順利，”年輕人回答說(shuō)，但是我遇到了一些小麻煩。我會(huì)排除這些困難，很快就可以回到正軌上來(lái)?！蹦阌X(jué)得在最后期限之前能否完成？”老板問(wèn)道。沒(méi)有問(wèn)題，”工程師答道。 我差不多已經(jīng)完成了 90%?！比绻x者在軟件領(lǐng)域中工作過(guò)幾年，你一定可以將這個(gè)故事寫(xiě)完。毫不 奇怪，青年工程師在整個(gè)項(xiàng)目工期內(nèi)始終停留在90%的進(jìn)度上，（在別人的幫助下）直到交付期限之后一個(gè)月才做完。在過(guò)去的30年間，這樣的故事被不同的軟件開(kāi)發(fā)者重復(fù)

6、了成千上萬(wàn)次。我們不禁要問(wèn)：為什么？ ” 7.1基本概念雖然軟件延期交付的原因很多，但是大多數(shù)都可以追溯到下面列出的一個(gè)或多個(gè)根本原因上：一個(gè)不現(xiàn)實(shí)的截止期限，由軟件工程組以外的人所設(shè)立并強(qiáng)加給軟件工程組內(nèi)的管理者和項(xiàng)目開(kāi)發(fā)者?？蛻粜枨蟀l(fā)生變化，而需求的變化沒(méi)有能夠反映在項(xiàng)目進(jìn)度的變化上。對(duì)工作量和/或完成該工作所需的資源數(shù)量估計(jì)不足。在項(xiàng)目開(kāi)始時(shí)，沒(méi)有將可以預(yù)測(cè)的和/或不可預(yù)測(cè)的風(fēng)險(xiǎn)考慮在內(nèi)。事先無(wú)法預(yù)計(jì)的技術(shù)困難。事先無(wú)法預(yù)計(jì)的人力困難。由于項(xiàng)目組成員之間的交流不暢而導(dǎo)致的延期。項(xiàng)目管理者未能發(fā)現(xiàn)進(jìn)度拖后，也未能采取行動(dòng)解決這一問(wèn)題。在軟件行業(yè)中，人們對(duì)過(guò)于樂(lè)觀的（即不現(xiàn)實(shí)的”項(xiàng)目完成期限

7、已經(jīng)司空見(jiàn)慣。有時(shí)候設(shè)定截止時(shí)間的人認(rèn)為這樣的截止期限是合理的，但是常識(shí)告訴我們，合理與否還必須由完成工作的人來(lái)判斷。 這個(gè)故事是我的自傳。7.1.1關(guān)于延遲”的評(píng)注拿破侖曾經(jīng)說(shuō)過(guò)：任何同意執(zhí)行一個(gè)他本人都認(rèn)為有缺點(diǎn)的計(jì)劃的指揮官都應(yīng)該受到指責(zé)；他必須提出自己的反對(duì)理由，堅(jiān)持修改這一計(jì)劃，最終甚至提出辭職而不是使自己的軍隊(duì)遭受慘敗?！边@句話擲地有聲，值得軟 件項(xiàng)目管理者們深思。在第5和第6章中討論的估算和風(fēng)險(xiǎn)分析活動(dòng)，以及本章中涉及的進(jìn)度安排技術(shù)，通常都需要在一個(gè)定義好的截止期限的約束之下實(shí)現(xiàn)。如果最樂(lè)觀的估算都表明截止期限是不現(xiàn)實(shí)的，一個(gè)勝任的項(xiàng)目管理者就應(yīng)該保護(hù) 其隊(duì)伍免受不適當(dāng)?shù)倪M(jìn)度安排

8、的壓力并將這種壓力反映給施加壓力的一方 ”:PAG85:。不妨舉例說(shuō)明，假定一個(gè)軟件開(kāi)發(fā)小組的任務(wù)是構(gòu)造一個(gè)醫(yī)療診斷儀器的實(shí)時(shí)控制器，該控制器需要在 9個(gè)月之內(nèi)推向市場(chǎng)。在進(jìn)行了仔細(xì)的估算和風(fēng)險(xiǎn)分析之 后，軟件項(xiàng)目管理者得到的結(jié)論是在現(xiàn)有人員條件下，需要14個(gè)月的時(shí)間才能完成這一軟件。這位項(xiàng)目管理者下一步該怎么辦？闖進(jìn)客戶的辦公室（這里的客戶非常可能是市場(chǎng)或銷(xiāo)售人員）并要求修改 交付日期似乎不太現(xiàn)實(shí)。外部市場(chǎng)壓力決定了交付日期，屆時(shí)必須發(fā)布產(chǎn)品。而（從事業(yè)前途的角度出發(fā)）拒絕這一項(xiàng)目同樣是魯莽的。那么應(yīng)該怎么辦呢？在這種情況下，推薦以下的處理步驟：1使用從以前的項(xiàng)目中得到的數(shù)據(jù)，進(jìn)行詳細(xì)的估算

9、。確定項(xiàng)目的估算工作量和持續(xù)時(shí)間。2使用增量過(guò)程模型（參見(jiàn)第2章），制定一個(gè)軟件開(kāi)發(fā)策略，以能夠在 規(guī)定的交付日期提供關(guān)鍵功能，而將其他功能的實(shí)現(xiàn)推到以后。將這一計(jì)劃做成文檔。3與客戶會(huì)談并（用詳細(xì)估算結(jié)果）來(lái)解釋為什么規(guī)定的交付日期是不現(xiàn) 實(shí)的，一定要指出所有這些估算都是基于以往的項(xiàng)目實(shí)踐，而且一定要指出為了在目前規(guī)定的交付期限完成項(xiàng)目，與以往相比在工作效率上必須提高的百分比。做如下解釋將是恰如其分的：我認(rèn)為在XYZ控制器軟件的交付日期方面存在一個(gè)問(wèn)題，我已經(jīng)將一份以往項(xiàng)目中生產(chǎn)率的簡(jiǎn)化明細(xì)分類(lèi)表和以多種不同方式進(jìn)行的項(xiàng)目估算提交給各位，你會(huì)注意到我已經(jīng)假設(shè)與以往的生產(chǎn)率相比有 20%的提高

10、，但是我們?nèi)匀恢荒艿玫?14個(gè)月 而不是9個(gè)月的交付時(shí)間。”4將增量開(kāi)發(fā)策略作為可選計(jì)劃提交給客戶。我們有幾個(gè)選擇，而我希望各位能夠在這些選擇的基礎(chǔ)上做出決策。首先，我們可以增加預(yù)算，并引入額外的資源，以便使我們能夠在 9個(gè)月時(shí) 間內(nèi)完成這一 工作。但是應(yīng)該知道由于時(shí)間限制過(guò)于苛刻，這樣做將會(huì)增加質(zhì)量差的風(fēng)險(xiǎn)。第二個(gè)方案是，去掉一部分需求中所列出的軟件功能和特性。由此得到功能稍弱的產(chǎn)品的最初版本，但是我們可以對(duì)外宣布全部功能， 如果提高的百分比為 10%到25%，則實(shí)際上是有可能如期完成這一項(xiàng)目的。但更有可 能的是，所需的隊(duì)伍效率的提高百分比要高于50%。這是不切實(shí)際的期望。 你還可以補(bǔ)充說(shuō)，

11、增加更多的人手不會(huì)成比例的縮短完成項(xiàng)目所需的時(shí)間。束，而希望項(xiàng)并在總共14個(gè)月的時(shí)間內(nèi)發(fā)布這些功能。第三種選擇是不顧現(xiàn)實(shí)條件的約 目能夠在9個(gè)月時(shí)間內(nèi)完成。結(jié)果是我們竭盡全力， 但是卻無(wú) 法向用戶提供任何功能。 我想你們會(huì)同意，第三種選擇是不可接受的。過(guò)去的歷史和我們最樂(lè)觀的估算都表明這是不現(xiàn)實(shí)的，是在選擇一場(chǎng)災(zāi)難?！北M管這樣做會(huì)有些抱怨，但如果你給出了基于準(zhǔn)確的歷史數(shù)據(jù)的可靠估算，那么最終的談判結(jié)果將可能是選擇1或者選擇2。不現(xiàn)實(shí)的交付期限就不存在了。7.1.2基本原則曾經(jīng)有人請(qǐng)教著名的神秘的人月 （The Mythical Man Mon th，見(jiàn)文 獻(xiàn)BRO95:） 一書(shū)的作者 Fred

12、 Brooks ,軟件項(xiàng)目的進(jìn)度是如何延遲的？ ”他的回答即簡(jiǎn)單又深刻： 一 天一次?！奔夹g(shù)性項(xiàng)目（不論它是涉及到水力發(fā)電廠建設(shè)，還是開(kāi)發(fā)一個(gè)操作系統(tǒng)）的現(xiàn)實(shí)情況是，在實(shí)現(xiàn)一個(gè)大目標(biāo)之前必須完成數(shù)以百計(jì)的小任務(wù)。這些任務(wù)中有些是處于主流之外，其實(shí)現(xiàn)不會(huì)影響到整個(gè)項(xiàng)目的完成時(shí)間；其他任 務(wù)則位于 關(guān)鍵路徑”之上，如果這些 關(guān)鍵”任務(wù)的進(jìn)度拖后，則整個(gè)項(xiàng)目的完成日期就會(huì)受到威脅。項(xiàng)目管理者的目標(biāo)是定義所有項(xiàng)目任務(wù)，識(shí)別關(guān)鍵任務(wù)，然后跟蹤關(guān)鍵任務(wù)的進(jìn)展以保證 一天一次”的發(fā)現(xiàn)進(jìn)度拖延情況。為了做到這一點(diǎn)，管理者必須建立一個(gè)具有一定詳細(xì)程度的進(jìn)度表，使得項(xiàng)目管理者能夠監(jiān)督進(jìn)度，并控制整個(gè)項(xiàng)目。軟件項(xiàng)目

13、進(jìn)度安排是一種活動(dòng)，它通過(guò)將工作量分配給特定的軟件工程任務(wù)，而將所估算的工作量分布于計(jì)劃好的項(xiàng)目持續(xù)時(shí)間內(nèi)。但是，進(jìn)度是隨著時(shí)間的改變而不斷演化的，注意到這一點(diǎn)至關(guān)重要。在項(xiàng)目計(jì)劃的早期，首先建立一個(gè)宏觀的進(jìn)度安排表。該進(jìn)度表標(biāo)識(shí)所有主要的軟件工程活動(dòng)和這些活動(dòng)影響到的產(chǎn)品功能。隨著項(xiàng)目的進(jìn)展，宏觀進(jìn)度表中的每個(gè)條目都被精化成一個(gè) 詳細(xì)進(jìn)度表”。于是（完成一個(gè)活動(dòng)所必須實(shí)現(xiàn)的）特定軟件 任務(wù)被標(biāo)識(shí)出來(lái)，并進(jìn)行進(jìn)度安排?？梢詮膬蓚€(gè)不同的視角考察軟件開(kāi)發(fā)項(xiàng)目的進(jìn)度安排。第一個(gè)視角，基于計(jì)算機(jī)的系統(tǒng)的最終發(fā)布日期已經(jīng)確定（而且不能更改）。軟件開(kāi)發(fā)組織在這一約束下將工作量分布在預(yù)先確定的時(shí)間框架內(nèi)。第

14、二個(gè)視角，假定大致的時(shí)間界限已經(jīng)討論過(guò)，但是最終發(fā)布日期是由軟件開(kāi)發(fā)組設(shè)定的，工作量以一種能夠最好地利用資源的方式加以分布，且在對(duì)軟件進(jìn)行仔細(xì)分析之后才定義最終發(fā)布日期。但不幸的是，第一種情況發(fā)生的頻率遠(yuǎn)遠(yuǎn)高于第二種 情況。同軟件工程的所有其他領(lǐng)域一樣，有一些基本原則能夠指導(dǎo)軟件項(xiàng)目的進(jìn)度安排：劃分：項(xiàng)目必須被劃分成若干可以管理的活動(dòng)和任務(wù)。為了實(shí)現(xiàn)項(xiàng)目的劃分，對(duì)產(chǎn)品 和過(guò)程都需要進(jìn)行分解（參見(jiàn)第3章）。有些任務(wù)必須順序相互依賴性：各個(gè)被劃分的活動(dòng)或任務(wù)之間的相互關(guān)系必須是確定的。 發(fā)生；而其他的則可以并發(fā)進(jìn)行。有些活動(dòng)只有在其他活 在本章中后面將詳細(xì)討論 關(guān)鍵路徑”。動(dòng)產(chǎn)生的工作產(chǎn)品完成時(shí)才

15、能夠開(kāi)始，而其他的則可以獨(dú)立進(jìn)行。時(shí)間分配：必須為每個(gè)被調(diào)度的任務(wù)分配一定數(shù)量的工作單位（例如，若干人天的工作量）。此外，必須為每個(gè)任務(wù)指定開(kāi)始和結(jié)束日期，這些日期是與工作完成的方式相互依賴的（全職還是兼職）是工作方式的函數(shù)。工作量確認(rèn)：每個(gè)項(xiàng)目都有預(yù)定數(shù)量的人員參與。在進(jìn)行時(shí)間分配時(shí)，項(xiàng)目管理者必須確保在任意時(shí)段中分配給任務(wù)的人員數(shù)量不會(huì)超過(guò)項(xiàng)目組中的人員數(shù)量。例如，一個(gè)項(xiàng)目分配了 3名員工參加（即，每天可分配的工作量為3人天）。在某一天中，需要完成7項(xiàng)并發(fā)的任務(wù)，每個(gè)任務(wù)需要0.50人天的工作量，在這種情況下，所分配的工作量就大于可用于分配的工作量。定義責(zé)任：每個(gè)被調(diào)度的任務(wù)都應(yīng)該指定某個(gè)

16、特定的小組成員來(lái)負(fù)責(zé)。定義結(jié)果：每個(gè)被調(diào)度的任務(wù)都應(yīng)該有一個(gè)定義好的結(jié)果。對(duì)于軟件項(xiàng)目而言，結(jié)果通常是一個(gè)工作產(chǎn)品（例如一個(gè)模塊的設(shè)計(jì)）或某個(gè)工作產(chǎn)品的一部分。通常將多個(gè)工作產(chǎn)品組合成可交付產(chǎn)品”。定義里程碑：每個(gè)任務(wù)或任務(wù)組都應(yīng)該與一個(gè)項(xiàng)目里程碑相關(guān)聯(lián)。當(dāng)一個(gè)或多個(gè)工作產(chǎn)品經(jīng)過(guò)質(zhì)量復(fù)審（參見(jiàn)第8章）并且得到認(rèn)可時(shí)，標(biāo)志著一個(gè)里程碑的完成。隨著項(xiàng)目進(jìn)度的發(fā)展，上述每一條原則都會(huì)被用到。7.2人員與工作量之間的關(guān)系在一個(gè)小型軟件開(kāi)發(fā)項(xiàng)目中，只需一個(gè)人就可以完成需求分析、設(shè)計(jì)、編碼和測(cè)試。隨著項(xiàng)目規(guī)模的增長(zhǎng)，必然涉及到更多的人員參與 （我們幾乎不 可能負(fù)擔(dān)讓一個(gè)人工作十年 來(lái)完成10人年工作量的奢

17、侈！）。許多負(fù)責(zé)軟件開(kāi)發(fā)工作的管理者仍然堅(jiān)信一個(gè)普遍存在的荒誕想法（參見(jiàn)第1章）:即使進(jìn)度拖后，我們也總可以增加更多的程序員，并在后期跟上進(jìn)度”。不幸的是，在項(xiàng)目后期增加人手通常產(chǎn)生一種破壞性影響，其結(jié)果是使進(jìn)度進(jìn)一步拖延。后來(lái)增加的人員必須學(xué)習(xí)這一系統(tǒng)，而培訓(xùn)他們的人員正是過(guò)去一直在工作著的那些人，當(dāng)他們進(jìn)行教學(xué)時(shí)，就不能完成任何工作，而項(xiàng)目也進(jìn)一步被拖延。除去學(xué)習(xí)系統(tǒng)所需的時(shí)間之外，新加入人員將會(huì)增加人員之間通信的路徑數(shù)量和整個(gè)項(xiàng)目中通信的復(fù)雜度。雖然通信交流對(duì)于一個(gè)成功的軟件開(kāi)發(fā)項(xiàng)目而言絕對(duì)是必不可少的，但是每增加一條新的通信路徑就會(huì)增加額外的工作量，從而需要更多的時(shí)間。7.2.1 一個(gè)

18、例子讓我們來(lái)考慮一個(gè)有 4名軟件工程師的項(xiàng)目， 在單獨(dú)完成項(xiàng)目時(shí)，每個(gè) 工程師的工作能力 都是每年生產(chǎn) 5000 LOC，而當(dāng)這4位工程師被編入一個(gè)項(xiàng)目組時(shí)，有 6條可能的通信路徑。每條路徑都將花費(fèi)原本可以用于軟件開(kāi)發(fā)的工作時(shí)間。由于增加了通信成本，我們將假定每增加一條通信路徑將會(huì)使項(xiàng)目組的生產(chǎn)率（以LOC計(jì)算）降低250 LOC/年。因此項(xiàng)目組的生產(chǎn)率為 20000實(shí)際上由于與工作無(wú)關(guān)的會(huì)議、 人天。但是在病假、休假和各種其他原因，可供分配的工作量要少于 3本書(shū)中，我們將假定員工時(shí)間是100 %可用的。 (250 >6) = 18500LOC/年，比期望數(shù)字低了7.5%。上述項(xiàng)目組承擔(dān)

19、的為期一年的項(xiàng)目現(xiàn)在只剩下兩個(gè)月時(shí)間，但是已經(jīng)落后于進(jìn)度，這時(shí)又加入了2名工程師。于是通信路徑激增為14，在交付之前 剩下的兩個(gè)月時(shí)間里，新增加成員的生產(chǎn)能力為840X2= 1680 LOC。而目前 的項(xiàng)目組生產(chǎn)率為 20000+ 1680 (250 >4)= 18180LOC/ 年。盡管上述例子僅僅是對(duì)現(xiàn)實(shí)情況的粗略簡(jiǎn)化，但是它足以揭示另一個(gè)關(guān)鍵性的問(wèn)題：參加軟件項(xiàng)目的工作人員數(shù)量與整體生產(chǎn)率之間的關(guān)系不是線性的。那么基于上述的人員-工作關(guān)系，是不是說(shuō)項(xiàng)目組會(huì)降低生產(chǎn)效率呢？如果通信可以提高軟件質(zhì)量的話，答案斷然是不”。實(shí)際上，由軟件工程小組進(jìn)行的正式技術(shù)復(fù)審(參見(jiàn)第8章)將得到更好的

20、分析和設(shè)計(jì)，更重要的是，這樣可以降低直到測(cè)試階段才能發(fā)現(xiàn)的錯(cuò)誤 數(shù)量(從而減小測(cè)試的工作量)。因此，如果以項(xiàng)目完成時(shí)間和客戶滿意程度來(lái)衡量，生產(chǎn)率和質(zhì)量都將確實(shí)提高。7.2.2 一個(gè)經(jīng)驗(yàn)關(guān)系請(qǐng)回憶一下在第 5章介紹的 軟件方程式” PUT92 L我們可以看到在完成項(xiàng)目的時(shí)間與投入項(xiàng)目中的人員的工作量之間存在著高度非線性關(guān)系。交付的代碼(源代碼語(yǔ)句)行數(shù)L與工作量和開(kāi)發(fā)時(shí)間之間的關(guān)系可以用下面的公式表示：L = P)(E/B)1/3t4/3其中E是以人月為單位的開(kāi)發(fā)工作量；P是一個(gè)生產(chǎn)率參數(shù)，它反映了導(dǎo)致高質(zhì)量軟件工程工作的各種因素的綜合效果(P通常取值在 2, 000到28,000之間);B是

21、特殊技術(shù)因子，在0.16到0.39之間取值，是所生產(chǎn)軟件的規(guī)模的函數(shù)；t是以月為單位的項(xiàng)目持續(xù)時(shí)間。將上述軟件方程式重排，可以得到關(guān)于開(kāi)發(fā)工作量E的計(jì)算公式：E= L3/(P314) (7.1)其中E是在軟件開(kāi)發(fā)和維護(hù)的整個(gè)生命周期內(nèi)所需的工作量(以人年計(jì) 算),t是以年計(jì)算的開(kāi)發(fā)時(shí)間。通過(guò)引入平均勞動(dòng)力價(jià)格因素($/人年)，開(kāi) 發(fā)工作量的計(jì)算公式還能夠與開(kāi)發(fā)成本相關(guān)聯(lián)。這一方程式引出了一些有趣的結(jié)果?？紤]一個(gè)復(fù)雜的實(shí)時(shí)軟件項(xiàng)目，估計(jì)需要33, 000 LOC , 12個(gè)人年的工作量。如果為項(xiàng)目組分配8個(gè)人，項(xiàng)目 大約可以用1.3年時(shí)間完成。但是如果將交付時(shí)間延長(zhǎng)到1.75年，則公式 1)中的

22、模型所具有的高度非線性特性將導(dǎo)致如下結(jié)果：E= L3/(P314)3.8 人年這意味著通過(guò)將截止時(shí)間推遲6個(gè)月，我們可以將項(xiàng)目組人數(shù)從8降低到4人！這一結(jié)果的有效性有待考證，但是其含意卻十分清楚：通過(guò)在略為 延長(zhǎng)的時(shí)間內(nèi)使用較少的人員，可以實(shí)現(xiàn)同樣的目標(biāo)。7.2.3工作量分布也可以做出以下辯駁：如果通信是高效的，就可以提高所進(jìn)行的工作的質(zhì)量，從而降低 返工工作量，并提高每個(gè)項(xiàng)目組成員的生產(chǎn)率。辯駁成立!在第五章中討論的每種軟件項(xiàng)目估算技術(shù)最終都?xì)w結(jié)為對(duì)完成軟件開(kāi)發(fā)所需人月（或者人年）的估算。一種推薦的在定義和開(kāi)發(fā)階段之間的工作量分布通常被稱(chēng)為“ 420-40規(guī)則”。40%或者更多的工作量分配給

23、前端的分析和設(shè)計(jì)任務(wù)。類(lèi)似比例的工作量用于后端測(cè)試。你可以推斷出編碼工作（大約20%的工作量）沒(méi)有被著重強(qiáng)調(diào)。這種工作量分布只應(yīng)被當(dāng)作指導(dǎo)原則。各個(gè)項(xiàng)目的特點(diǎn)決定了其工作量分布。用于項(xiàng)目計(jì)劃的工作量很少超過(guò)2%到3%,除非提交給組織的項(xiàng)目計(jì)劃費(fèi)用極大，而且具有高風(fēng)險(xiǎn)。需求分析大約占用10%到25%的工作量，用 于分析或原型開(kāi)發(fā)的工作量應(yīng)該與項(xiàng)目規(guī)模和復(fù)雜度成正比的增長(zhǎng)。通常有20%到25%的工作量用于軟件設(shè)計(jì)，用于設(shè)計(jì)復(fù)審和隨之而來(lái)的迭代開(kāi)發(fā)也必須列入考慮之中。因?yàn)樵谲浖O(shè)計(jì)時(shí)投入了相當(dāng)?shù)墓ぷ髁?，隨后的編碼工作就變得相對(duì)簡(jiǎn)單。15%到20%的工作量就可以完成這一工作。測(cè)試和隨之而來(lái)的調(diào)試工作將

24、占用30%到40%的軟件開(kāi)發(fā)工作量。軟件的重要性決定了所需測(cè)試工作的 份量，如果軟件系統(tǒng)是人命相關(guān)的（即, 軟件錯(cuò)誤可能使人喪命），就應(yīng)該考 慮分配更高的測(cè)試工作量比例。7.3為軟件項(xiàng)目定義任務(wù)集合在第二章中，我們描述了多種不同的過(guò)程模型。這些模型為軟件開(kāi)發(fā)提供了不同的范型。如果不考慮一個(gè)軟件項(xiàng)目組選擇的是線性順序范型、迭代開(kāi)發(fā)模型、演化開(kāi)發(fā)模型、并發(fā)開(kāi)發(fā)模型還是組合使用這些模型，則過(guò)程模型都是由一個(gè)任務(wù)集合組成的，它使得軟件項(xiàng)目組能夠定義、開(kāi)發(fā)和最終維護(hù)計(jì)算機(jī)軟件。沒(méi)有一個(gè)普遍適用于所有軟件項(xiàng)目的任務(wù)集合。適用于大型復(fù)雜系統(tǒng)的項(xiàng)目任務(wù)集合可能對(duì)于小型且相對(duì)簡(jiǎn)單的項(xiàng)目而言就過(guò)于復(fù)雜。因此一個(gè)有

25、效的軟件過(guò)程應(yīng)該定義一組 任務(wù)集合”，各個(gè)任務(wù)集合的設(shè)計(jì)可以滿足不同類(lèi)型項(xiàng)目的要求。一個(gè)任務(wù)集合包括一組軟件工程工作任務(wù)、里程碑和交付產(chǎn)品，為了完成某一特定項(xiàng)目就必須完成這些任務(wù)。一個(gè)項(xiàng)目所選擇的任務(wù)集合必須為最終獲得高質(zhì)量的軟件產(chǎn)品提供充分的規(guī)程要求，但同時(shí)又不能讓項(xiàng)目組負(fù)擔(dān)不必要的工作。任務(wù)集合的設(shè)計(jì)應(yīng)該可以應(yīng)用于不同類(lèi)型的項(xiàng)目和不同的嚴(yán)格度。盡管很難建立一個(gè)全面詳盡的分類(lèi)結(jié)構(gòu)，但是大多數(shù)軟件組織接手的項(xiàng)目一般屬于下述類(lèi)型：概念開(kāi)發(fā)項(xiàng)目：項(xiàng)目的目的是為了探索某些新的商業(yè)概念或者某種新技術(shù)的應(yīng)用。新應(yīng)用開(kāi)發(fā)項(xiàng)目：根據(jù)特定的客戶需求而承擔(dān)的項(xiàng)目。應(yīng)用增強(qiáng)項(xiàng)目：對(duì)現(xiàn)有軟件進(jìn)行最終用戶可察覺(jué)的功能

26、、性能或界面的修改。 現(xiàn)在對(duì)于大型軟件開(kāi)發(fā)項(xiàng)目而言，通常多于 務(wù)。因此從嚴(yán)格意義上講，“4020-40”，的名稱(chēng)已經(jīng)不再適用。40 %的全部項(xiàng)目工作量用于分析和設(shè)計(jì)任應(yīng)用維護(hù)項(xiàng)目：以一種最終用戶不會(huì)立即察覺(jué)到的方式對(duì)現(xiàn)有軟件進(jìn)行糾錯(cuò)、適應(yīng)或者擴(kuò)展。再工程項(xiàng)目：為了全部或部分重建一個(gè)現(xiàn)有（遺留）系統(tǒng)而承擔(dān)的項(xiàng)目。即使在單一的項(xiàng)目類(lèi)型中，也會(huì)有許多因素影響任務(wù)集合的選擇。當(dāng)將這些因素綜合考慮時(shí)，就會(huì)構(gòu)成一個(gè)稱(chēng)為 嚴(yán)格度”的指示量，它將應(yīng)用于所采用的軟件過(guò)程中。7.3.1嚴(yán)格度即使只考慮某種特定類(lèi)型的項(xiàng)目，所采用的軟件過(guò)程的嚴(yán)格度也會(huì)相當(dāng)不同。嚴(yán)格度是眾多項(xiàng)目特性的函數(shù)。例如，小型的非主要商業(yè)性質(zhì)的

27、項(xiàng)目的嚴(yán)格度一般可以小于大型復(fù)雜的主要業(yè)務(wù)應(yīng)用程序。但是應(yīng)該注意到，所有項(xiàng)目都必須以一種能夠按時(shí)得到高質(zhì)量的發(fā)布產(chǎn)品的方式來(lái)實(shí)施?？梢远x如下的4種不同程度的嚴(yán)格度：隨意的：使用了所有過(guò)程框架活動(dòng) （參見(jiàn)第2章），但只需要一個(gè)最小的 任務(wù)集合。一 般情況下，將保護(hù)性任務(wù)最小化，并將文檔需求降低。所有基本的軟件工程原則仍然都是適用的。結(jié)構(gòu)化的：在項(xiàng)目中將使用過(guò)程框架?？蚣芑顒?dòng)和適用于這種項(xiàng)目類(lèi)型的相關(guān)任務(wù)，以及為保證高質(zhì)量所需的保護(hù)性活動(dòng)將得到應(yīng)用。SQA、SCM、文檔和度量任務(wù)將以一種經(jīng)過(guò)優(yōu)化的有效方式進(jìn)行。嚴(yán)格的：整個(gè)過(guò)程將按照一種能夠確保高質(zhì)量的嚴(yán)格規(guī)程要求應(yīng)用于項(xiàng) 目之中。所有保護(hù)性活動(dòng)

28、都將被采用，且要建立健壯的文檔?？焖俜磻?yīng)的：該項(xiàng)目將使用過(guò)程框架，但是由于某種緊急情況的出現(xiàn)，只應(yīng)用了那些為保持軟件系統(tǒng)質(zhì)量所必須完成的任務(wù)。在應(yīng)用程序/產(chǎn)品交付給客戶之后再完成回填工作”即開(kāi)發(fā)一套完整的文檔，進(jìn)行額外的復(fù)審）。項(xiàng)目管理者必須開(kāi)發(fā)一種系統(tǒng)化的方法用以選擇適用于特定項(xiàng)目的嚴(yán)格度。為了做到這一點(diǎn)，需要定義項(xiàng)目適應(yīng)性準(zhǔn)則并計(jì)算任務(wù)集合選擇因子”的值。732定義適應(yīng)性準(zhǔn)則適應(yīng)性準(zhǔn)則用于確定一個(gè)項(xiàng)目中使用軟件過(guò)程的嚴(yán)格度。我們?yōu)檐浖?xiàng)目定義了以下11條適應(yīng)性準(zhǔn)則：項(xiàng)目的規(guī)模。潛在的用戶數(shù)量。任務(wù)的關(guān)鍵性。應(yīng)用程序的壽命。需求的穩(wěn)定性?？蛻襞c開(kāi)發(fā)者之間通信的容易程度。緊急情況應(yīng)該非常罕見(jiàn)（

29、在軟件工程的討論范圍內(nèi)，發(fā)生這種情況的工作不應(yīng)該超過(guò)10%到 20%）。緊急情況與項(xiàng)目工期緊張是不同的。 出現(xiàn)在本節(jié)中的適應(yīng)性準(zhǔn)則與后面一節(jié)出現(xiàn)的TSS計(jì)算都是根據(jù) 自適應(yīng)的過(guò)程模型改編的。其復(fù)制 得到了 R.S.Pressman& Associates , Inc.的許可。欲知有關(guān)詳情，請(qǐng)發(fā)電子 由E件給 info .應(yīng)用技術(shù)的成熟度。性能約束。嵌入式/非嵌入式特性。項(xiàng)目人員配置。再工程因素。每一條適應(yīng)性準(zhǔn)則都被賦予一定的等級(jí)分?jǐn)?shù)，取值在1到5之間。其中1代表需要使用較小子集的過(guò)程任務(wù)，且整體的方法學(xué)及文檔需求為最小的項(xiàng)目；而5則代表需要采用全部過(guò)程任務(wù)，且整體的方法學(xué)及文檔需求相當(dāng)

30、高的項(xiàng)目。7.3.3計(jì)算任務(wù)集合選擇因子的值為一個(gè)項(xiàng)目選擇適當(dāng)?shù)娜蝿?wù)集合，應(yīng)該按照下述幾個(gè)步驟進(jìn)行：1. 復(fù)審7.3.2節(jié)中給出的每個(gè)適應(yīng)性準(zhǔn)則，根據(jù)項(xiàng)目特點(diǎn)為它們賦予適當(dāng)?shù)牡燃?jí)分?jǐn)?shù)（從1到5）。這些等級(jí)分?jǐn)?shù)應(yīng)該輸入到表7- 1中。2. 復(fù)審賦予每個(gè)適應(yīng)性準(zhǔn)則的加權(quán)因子。加權(quán)因子的取值在0.8至U 1.2之間，表明了對(duì)在當(dāng)前環(huán)境中開(kāi)發(fā)的軟件類(lèi)型而言特定適應(yīng)性準(zhǔn)則的相對(duì)重要性。如果需要，則可以進(jìn)行修改，以反映當(dāng)前的環(huán)境。3. 將表7.1中的等級(jí)分?jǐn)?shù)與加權(quán)因子相乘，再乘以表示當(dāng)前項(xiàng)目類(lèi)型的條目點(diǎn)乘數(shù)。條目點(diǎn)乘數(shù)在0到1之間取值，表示該適應(yīng)性準(zhǔn)則與項(xiàng)目類(lèi)型之間的相關(guān)程度。對(duì)應(yīng)于各個(gè)適應(yīng)性準(zhǔn)則的相乘結(jié)

31、果：等級(jí)分?jǐn)?shù)X加權(quán)因子條目點(diǎn)乘數(shù) 分別放入表7- 1的乘積”欄中。4. 計(jì)算 乘積”欄中所有條目的平均值，并將結(jié)果放入標(biāo)記著任務(wù)集 合選擇因子（TSS）”的空格中。這個(gè)值將用于幫助你選擇最適用于當(dāng)前項(xiàng)目的任務(wù)集合。表7 - 1計(jì)算任務(wù)集合選擇因子適應(yīng)性準(zhǔn)則 等級(jí)分?jǐn)?shù) 權(quán)重 條目點(diǎn)乘數(shù) 乘積概念新應(yīng)用增強(qiáng)維護(hù)再工程項(xiàng)目規(guī)模 一1.20 0 1 1 1 1 用戶數(shù)量 一1.10 0 1 1 1 1 業(yè)務(wù)關(guān)鍵性一1.10 0 1 1 1 1 壽命一0.90 0 1 1 0 0 適應(yīng)性準(zhǔn)則等級(jí)分?jǐn)?shù)權(quán)重條目點(diǎn)乘積乘數(shù)概念新應(yīng)用增強(qiáng)維護(hù)再工程需求穩(wěn)定性一1.20 0 1 1 1 1 易于通信 一0.90

32、1 1 1 1 1 技術(shù)成熟度 一0.90 1 1 0 0 1 性能約束 0.80 0 1 1 0 1 嵌入式/非嵌入式 一1.20 1 1 1 0 1 項(xiàng)目人員配置 一1.00 1 1 1 1 1 互操作 一1.10 0 1 1 1 1 再工程因素 一1.20 0 0 0 0 1 任務(wù)集合選擇因子（TSS）734解釋TSS值并選擇任務(wù)集合一旦計(jì)算好任務(wù)集合選擇因子，就可以使用下述的指南幫助你選擇一個(gè)適用于項(xiàng)目的任務(wù)集合：任務(wù)集合選擇因子取值嚴(yán)格度TSSV 1.2隨意的1.0 V TSSV 3.0結(jié)構(gòu)化的 TSS >2.4嚴(yán)格的兩個(gè)推薦任務(wù)集合之間的TSS取值的重疊是有意設(shè)定的，這用于說(shuō)

33、明在進(jìn)行任務(wù)集合的選擇時(shí)，定義出精確的邊界是不可能的。在進(jìn)行最后的分析時(shí)，應(yīng)該將任務(wù)集合選擇因子的取值、以往的經(jīng)驗(yàn)以及常識(shí)都作為項(xiàng)目任務(wù)集合的選擇因素。表7 2顯示了在一個(gè)假想的項(xiàng)目中如何計(jì)算TSS的情況。項(xiàng)目管理者在等級(jí)分?jǐn)?shù)”一欄中選擇等級(jí)分值，項(xiàng)目類(lèi)型是新應(yīng)用開(kāi)發(fā)”。因此其條 目點(diǎn)乘數(shù)應(yīng)該從 新應(yīng)用”一欄中選擇。乘積”一欄中條目的計(jì)算使用如下公式等級(jí)分?jǐn)?shù)X加權(quán)因子條目點(diǎn)乘數(shù)TSS的取值（乘積”一欄中所有條目的平均值）是2.8。使用上述的準(zhǔn)則，管理者可以選擇使用結(jié)構(gòu)化的或嚴(yán)格的任務(wù)集合。在考慮了所有項(xiàng)目因素之后，可以作出最終決策。表7 2計(jì)算任務(wù)集合選擇子：一個(gè)例子條目點(diǎn)乘數(shù)乘積新應(yīng)用 增強(qiáng)

34、 維護(hù) 再工程項(xiàng)目規(guī)模 2 1.20 12.4用戶數(shù)量 3 1.10 13.3業(yè)務(wù)關(guān)鍵性 4 1.10 14.4壽命 3 0.9 12.7需求穩(wěn)定性 2 1.2 12.4易于通信 2 0.9 11.8技術(shù)成熟度 2 0.9 11.8性能約束 3 0.8 12.4嵌入式/非嵌入式 3 1.2 13.6項(xiàng)目人員配置 2 1.0 12.0互操作 4 1.1 14.4再工程因素 0 1.2 02.8任務(wù)集合選擇因子（TSS） 2.87.4選擇軟件工程任務(wù)為了制定項(xiàng)目進(jìn)度安排，必須將任務(wù)集合分布在項(xiàng)目時(shí)間表上。如7.3節(jié)所述，任務(wù)集合將根據(jù)項(xiàng)目類(lèi)型和嚴(yán)格度的不同而有所不同。7.3節(jié)中的 每種項(xiàng)目類(lèi)型都可

35、以使用線性順序、迭代（如，原型模型）或者演化（如，螺旋 模型）等過(guò)程模型來(lái)實(shí)現(xiàn)。在某些情況下， 項(xiàng)目類(lèi)型可以從一種形式平滑的轉(zhuǎn)換為另一種形式。例如，成功的概念開(kāi)發(fā)項(xiàng)目通常會(huì)演化成為新應(yīng)用開(kāi)發(fā)項(xiàng)目，而新應(yīng)用開(kāi)發(fā)項(xiàng)目結(jié)束之后，可能又開(kāi)始了一個(gè)應(yīng)用增強(qiáng)項(xiàng)目。這種進(jìn) 程是自然且可預(yù)測(cè)的， 而不論是采用何種過(guò)程模型來(lái)組織。作為一個(gè)例子， 下面我們將考慮概念開(kāi)發(fā)項(xiàng)目的主要軟件工程任務(wù)。 概念開(kāi)發(fā)項(xiàng)目是在必須探索某些新技術(shù)是否可行時(shí)發(fā)起的。這種技術(shù)是 否可行尚不可知，但是某個(gè)客戶（如營(yíng)銷(xiāo)部門(mén)）相信其潛在利益的存在。概念開(kāi)發(fā)項(xiàng)目的完成需要應(yīng)用下面所述的主要任務(wù)：確定概念范圍：確定項(xiàng)目的整體范圍。初步的概念計(jì)劃

36、：確定組織的能力，以承擔(dān)項(xiàng)目范圍所規(guī)定的工作。技術(shù)風(fēng)險(xiǎn)評(píng)估：評(píng)估與將要作為項(xiàng)目范圍的一部分而被實(shí)現(xiàn)的技術(shù)相關(guān) 聯(lián)的風(fēng)險(xiǎn)。概念證明：闡明新技術(shù)在軟件環(huán)境中的生命力。概念實(shí)現(xiàn)：以一種可以由客戶方復(fù)審的方式實(shí)現(xiàn)概念的表示，且當(dāng)概念必須被賣(mài)給其他客戶或管理者時(shí)能夠用于推銷(xiāo)”的目的?？蛻魧?duì)概念的反應(yīng)：向客戶索取對(duì)新技術(shù)概念的反饋，并以特定的客戶 應(yīng)用作為目標(biāo)。快速瀏覽上述主要任務(wù)，你應(yīng)該不會(huì)有何詫異。實(shí)際上概念開(kāi)發(fā)項(xiàng)目的軟件工程任務(wù)流程（以及其他所有類(lèi)型的項(xiàng)目）與人們的常識(shí)相差無(wú)幾。軟件開(kāi)發(fā)組必須知道哪些任務(wù)是必須完成的（項(xiàng)目范圍）；項(xiàng)目組（或管理者）必須確定目前是否有人能夠進(jìn)行這一工作（計(jì)劃）；考慮與

37、工作相關(guān)聯(lián)的風(fēng) 險(xiǎn)（風(fēng)險(xiǎn)評(píng)估）；以某種方式證明這種技術(shù) （概念的證明）；并且將這種技術(shù)用原型的方式實(shí)現(xiàn)出來(lái)，從而使客戶能夠?qū)ζ溥M(jìn)行評(píng)價(jià)（概念實(shí)現(xiàn)和客戶評(píng) 價(jià)）。最后，如果這一概念是可行的，則必須將 其產(chǎn)品版本開(kāi)發(fā)出來(lái)（技術(shù)轉(zhuǎn)化）。有非常重要的一點(diǎn)需要注意，概念開(kāi)發(fā)任務(wù)本質(zhì)上是迭代的。這就是說(shuō)，一個(gè)實(shí)際的概念開(kāi)發(fā)項(xiàng)目也許會(huì)通過(guò)多個(gè)有計(jì)劃的增量步驟得以實(shí)現(xiàn)，每個(gè)步驟都被設(shè)計(jì)成能夠產(chǎn)生一個(gè)可供客戶評(píng)價(jià)的可發(fā)布版本。如果選擇使用線性過(guò)程模型，則每一個(gè)增量都被定義為如圖7 - 1所示的 一個(gè)重復(fù)序列。在每個(gè)序列中，將使用保護(hù)性活動(dòng)（參見(jiàn)第2章中的描述）；監(jiān)控軟件質(zhì)量，且在每個(gè)序列的末尾，將產(chǎn)生一個(gè)可交付

38、產(chǎn)品。隨著逐次迭代的過(guò)程，可交付產(chǎn)品應(yīng)該向著在概念開(kāi)發(fā)階段已經(jīng)定義的最終產(chǎn)品收斂。如果選擇的是演化開(kāi)發(fā)模型，則從任務(wù)1.1到1.6的分布應(yīng)該如圖 7-2中所 示?？梢砸灶?lèi)似的方式定義和使用關(guān)于其他項(xiàng)目類(lèi)型的主要軟件 工程任務(wù)。7.5主要任務(wù)的求精在7.4節(jié)中所描述的主要任務(wù)可以被用于定義項(xiàng)目的宏觀進(jìn)度表。例女口，概念開(kāi)發(fā)項(xiàng)目中描述的任務(wù)可以用于定義該項(xiàng)目的任務(wù)網(wǎng)絡(luò)（參見(jiàn)7.6節(jié)）。我們?cè)诒菊虑懊嬖?jīng)指出，必須將宏觀進(jìn)度表精化來(lái)創(chuàng)建一個(gè)詳細(xì)的項(xiàng)目進(jìn)度表。精化工作始于將每個(gè)主要任務(wù)分解為一組子任務(wù)（以及相關(guān)的工作產(chǎn)品和里程碑）。作為任務(wù)分解的例子，我們考慮在7.4節(jié)中討論的 確定概念范圍”任 務(wù)。

39、任務(wù)精化可以使用大綱格式完成，但是在本書(shū)中將使用一種過(guò)程設(shè)計(jì)語(yǔ)言來(lái)闡明確定概念范圍”這一活動(dòng)的流程：任務(wù)I.1確定概念范圍1.1.1標(biāo)出需求、效益和潛在的客戶；1.1.2定義所希望的輸出/控制和驅(qū)動(dòng)應(yīng)用程序的輸入事件；Begin任務(wù)1.1.2I.1.2.1FTR :復(fù)審需求的書(shū)面說(shuō)明I.1.2.2導(dǎo)出一個(gè)客戶可見(jiàn)的輸出/輸入列表 case of: mechanics mechanics=質(zhì)量功能配置與客戶會(huì)談，以劃分主要的概念需求；會(huì)見(jiàn)最終用戶；觀察現(xiàn)有的解決問(wèn)題的方法和當(dāng)前的問(wèn)題解決過(guò)程；復(fù)審以往的要求和抱怨； 過(guò)程設(shè)計(jì)語(yǔ)言與 14章中討論的程序設(shè)計(jì)語(yǔ)言在語(yǔ)法上是類(lèi)似的。FTR表示在此需要進(jìn)

40、行一次正式的技術(shù)復(fù)審（參見(jiàn)第8章）mecha nics=結(jié)構(gòu)化分析列出主要數(shù)據(jù)對(duì)象；定義對(duì)象之間的關(guān)系；定義對(duì)象的屬性；mecha門(mén)9$=對(duì)象視圖列出問(wèn)題類(lèi)；確定類(lèi)層次和類(lèi)連接；定義各個(gè)類(lèi)的屬性；en dcaseI.1.2.3FTR :與客戶一起復(fù)審輸出/輸入，并在需要時(shí)進(jìn)行修改；en dtask 任務(wù) 1.1.2I.1.3為每項(xiàng)主要功能定義操作 /行為；Begin任務(wù)I.1.3I.1.3.1 FTR :復(fù)審在任務(wù)I.1.2中得到的輸出和輸入數(shù)據(jù)對(duì)象；I.1.3.2導(dǎo)出功能/行為模型；case of： mechanics mechanics=質(zhì)量功能配置 與客戶會(huì)談，以復(fù)審主要的概念需求；會(huì)見(jiàn)

41、最終用戶；觀察現(xiàn)有的解決問(wèn)題的方法和當(dāng)前的問(wèn)題解決過(guò)程；建立一個(gè)功能/行為的層次結(jié)構(gòu)概要；mechanics=結(jié)構(gòu)化分析 導(dǎo)出一個(gè)系統(tǒng)級(jí)別的數(shù)據(jù)流程圖；精化數(shù)據(jù)流程圖，以便給出更多的細(xì)節(jié)；為最底層精化圖的功能書(shū)寫(xiě)處理過(guò)程說(shuō)明；mecha nics=對(duì)象視圖定義與各個(gè)類(lèi)相關(guān)的操作/方法；endcaseI.1.3.3與客戶一起復(fù)審功能/行為模型，并在需要時(shí)進(jìn)行修改；en dtask 任務(wù) 1.1.3I.1.4把需要在軟件中得到實(shí)現(xiàn)的技術(shù)要素分離出來(lái)；I.1.5研究現(xiàn)有軟件的可用性；I.1.6定義技術(shù)可行性；I.1.7對(duì)系統(tǒng)規(guī)模進(jìn)行快速估算；I.1.8創(chuàng)建一個(gè) 范圍定義”；endtask任務(wù)I.1任

42、務(wù)和用過(guò)程設(shè)計(jì)語(yǔ)言進(jìn)行精化時(shí)標(biāo)注的子任務(wù)共同構(gòu)成了制定確定 概念范圍”這一活動(dòng)的詳細(xì)進(jìn)度表的基礎(chǔ)。7.6定義任務(wù)網(wǎng)絡(luò)參與軟件工程任務(wù)和子任務(wù)之間基于其間順序而存在相互依賴關(guān)系。而且當(dāng)有多個(gè)人 項(xiàng)目時(shí)，多個(gè)開(kāi)發(fā)活動(dòng)和任務(wù)并行進(jìn)行的可能性很大。在這種情況下，必須協(xié)調(diào)多個(gè)并發(fā)任務(wù)，以保證它們能夠在后繼任務(wù)需要其工作成果之前完成。任務(wù)網(wǎng)絡(luò)”是一個(gè)項(xiàng)目的任務(wù)流程的圖形表示。該網(wǎng)絡(luò)有時(shí)被用作在自動(dòng)項(xiàng)目進(jìn)度安排工具中輸入任務(wù)序列和依賴關(guān)系的機(jī)制。任務(wù)網(wǎng)絡(luò)的最簡(jiǎn)單形式（當(dāng)創(chuàng)建宏觀進(jìn)度表時(shí)使用）刻劃了軟件工程主要任務(wù)。圖73顯示了 一個(gè)概念開(kāi)發(fā)項(xiàng)目的任務(wù)網(wǎng)絡(luò)示意圖。軟件工程活動(dòng)的并發(fā)本質(zhì)導(dǎo)致了若干重要的調(diào)度需求

43、。由于并行任務(wù)是異步發(fā)生的，計(jì)劃者必須確定任務(wù)之間的依賴關(guān)系，以保證項(xiàng)目朝著最終完成的方向持續(xù)發(fā)展。另外，項(xiàng)目管理者應(yīng)該注意那些位于關(guān)鍵路徑之上的任務(wù)，也就是說(shuō)，為了保證整個(gè)項(xiàng)目的如期完成，就必須保證這些任務(wù)能夠如期完成。在本章的后面部分， 我們將詳細(xì)討論這些問(wèn)題。圖7-3中所示的任務(wù)網(wǎng)絡(luò)是宏觀的，注意到這一點(diǎn)非常重要。在一個(gè)詳細(xì)的任務(wù)網(wǎng)絡(luò)（詳細(xì)進(jìn)度表的前驅(qū)）中，應(yīng)該對(duì)圖 7-3所示的各個(gè)活動(dòng)加以擴(kuò)展。例如，應(yīng)該擴(kuò)展任務(wù)1.1，以顯示7.5節(jié)所述的精化中的所有詳細(xì)任務(wù)。7.7進(jìn)度安排軟件項(xiàng)目的進(jìn)度安排與任何其他多任務(wù)工程工作的進(jìn)度安排幾乎沒(méi)有太多的差別。因此，通用的項(xiàng)目進(jìn)度安排工具和技術(shù)不必做

44、太多修改就可以應(yīng)用于軟件項(xiàng)目。程序評(píng)估和復(fù)審技術(shù)（PERT） ”和 關(guān)鍵路徑方法（CPM） ” : MOD83 就 是兩種可以用于軟件開(kāi)發(fā)的項(xiàng)目進(jìn)度安排方法。兩種技術(shù)都是由較早的項(xiàng)目計(jì)劃活動(dòng)中已經(jīng)產(chǎn)生的信息來(lái)驅(qū)動(dòng)的，這些信息包括：工作量的估算。產(chǎn)品功能的分解。適當(dāng)?shù)倪^(guò)程模型的選擇。項(xiàng)目類(lèi)型和任務(wù)集合的選擇。任務(wù)之間的依賴關(guān)系可以使用任務(wù)網(wǎng)絡(luò)來(lái)定義。任務(wù)，有時(shí)也稱(chēng)作項(xiàng)目的工作細(xì)分結(jié)構(gòu)”（WBS）其定義可以是針對(duì)整個(gè)產(chǎn)品，也可以是針對(duì)單個(gè) 功能進(jìn)行的。PERT和CPM兩種方法都提供項(xiàng)目工作定量劃分的工具，能支持軟件計(jì)劃者確定關(guān)鍵路徑一決定項(xiàng)目持續(xù)時(shí)間的任務(wù)鏈；（2）通過(guò)使用統(tǒng)計(jì)模型為 單個(gè)任務(wù)建立

45、最有可能的時(shí)間估算；（3）計(jì)算為特定任務(wù)定義其時(shí)間窗口”的邊界時(shí)間。邊界時(shí)間的計(jì)算對(duì)軟件項(xiàng)目進(jìn)度的安排十分有用。比如說(shuō)，某個(gè)功能的設(shè)計(jì)的推遲可能進(jìn)一步導(dǎo)致其他功能開(kāi)發(fā)的拖后。Riggs : RIG81 描述了一 些能夠從 PERT或CPM網(wǎng)絡(luò)中得到的重？5謀囈縭奔洌海*1）某個(gè)任務(wù)的最早 開(kāi)始時(shí)間是當(dāng)其所有前驅(qū)任務(wù)在最短的 可能時(shí)間中完成時(shí)；（2）某個(gè)任務(wù)的最 晚開(kāi)始時(shí)間是在不延遲項(xiàng)目最小完成時(shí)間的前提下， 最晚啟動(dòng)該任務(wù)的時(shí)間；（3）最早結(jié)束時(shí)間一一最早開(kāi)始時(shí)間加上任務(wù)持續(xù)時(shí)間；（4）最晚結(jié)束時(shí) 間一一最晚開(kāi)始時(shí)間加上任務(wù)持續(xù)時(shí)間；以及（5）總浮動(dòng)量一一在保證進(jìn)度的 前提下，調(diào)度任務(wù)時(shí)所允許

46、的富余時(shí)間或回旋時(shí)間的總和。通過(guò)邊界時(shí)間的 計(jì)算可以確定關(guān)鍵路徑，并為管理者提供當(dāng)任務(wù)完成時(shí)評(píng)估進(jìn)展的量化方法。PERT和CPM方法都已經(jīng)在多種自動(dòng)工具中得到實(shí)現(xiàn)，這些工具在幾乎所有個(gè)人電腦上都可以找到THE93 :。這類(lèi)工具易于使用， 且使得每一位軟件 項(xiàng)目管理者都可以使用 前述的進(jìn)度安排方法。7.7.1時(shí)間表在創(chuàng)建軟件項(xiàng)目進(jìn)度表時(shí)，計(jì)劃者將從一組任務(wù)（工作細(xì)分結(jié)構(gòu)）入手。如果使用自動(dòng)工具，就可以用任務(wù)網(wǎng)絡(luò)或者任務(wù)大綱的方式輸入工作細(xì)分結(jié)構(gòu)。然后為每一項(xiàng)任務(wù)輸入工作量、持續(xù)時(shí)間和開(kāi)始時(shí)間。此外，每一項(xiàng)任務(wù)都必須被分配給特定的人員。上述輸入的結(jié)果之一是產(chǎn)生時(shí)間表（Timeline Chart）

47、，"也叫做 甘 特圖（Gantt Chart）?！笨梢詾檎麄€(gè)項(xiàng)目建立一個(gè)時(shí)間表，也可以為各個(gè)項(xiàng)目功能或各個(gè)項(xiàng)目參與者分別開(kāi)發(fā)各自的時(shí)間表。表73給出了時(shí)間表的格式，該圖描述了一個(gè)新的字處理軟件產(chǎn)品中確定概念范圍”任務(wù)（參見(jiàn)7.5節(jié)）的軟件項(xiàng)目進(jìn)度安排。所有的項(xiàng)目任務(wù)（對(duì)于 確定概念范圍”都在左邊的欄中列出。水平條表示每個(gè)任務(wù)的持續(xù)時(shí)間。當(dāng)日歷中同一時(shí)段中存在多個(gè)水平條時(shí)，就代表任務(wù)之間存在并發(fā)。圖中的菱形表示里程碑。一旦輸入了生成時(shí)間表所需的信息，大多數(shù)軟件項(xiàng)目進(jìn)度安排工具都會(huì) 生成項(xiàng)目表”個(gè)表格式的列表，列出所有項(xiàng)目任務(wù)、其計(jì)劃的及實(shí)際的開(kāi)始與結(jié)束日期、以及各種相關(guān)信息（參見(jiàn)圖7

48、5）。項(xiàng)目表與時(shí)間表一同使用，使得項(xiàng)目管理者能夠跟蹤項(xiàng)目的進(jìn)展情況。7.7.2跟蹤進(jìn)度項(xiàng)目進(jìn)度為軟件項(xiàng)目管理者提供了一張進(jìn)度路線圖。如果被正確制定，項(xiàng)目進(jìn)度表中應(yīng)該定義在項(xiàng)目進(jìn)展過(guò)程中必須被跟蹤和控制的任務(wù)及里程碑。項(xiàng)目跟蹤可以通過(guò)以下方式得以實(shí)現(xiàn)：定期舉行項(xiàng)目狀態(tài)會(huì)議，由項(xiàng)目組中的各個(gè)成員分別報(bào)告進(jìn)度和問(wèn)題。評(píng)估所有在軟件工程過(guò)程中所進(jìn)行的復(fù)審的結(jié)果。確定正式的項(xiàng)目里程碑（表7-3中的菱形）是否在預(yù)定日期內(nèi)完成。比較項(xiàng)目表（表7-4）中列出的各項(xiàng)任務(wù)的實(shí)際開(kāi)始日期與計(jì)劃開(kāi)始日期。與開(kāi)發(fā)者進(jìn)行非正式會(huì)談，獲取他們對(duì)項(xiàng)目進(jìn)展及可能出現(xiàn)的問(wèn)題的客觀評(píng)估。實(shí)際上，有經(jīng)驗(yàn)的項(xiàng)目管理者都會(huì)使用所有這些跟

49、蹤技術(shù)。軟件項(xiàng)目管理者使用控制”的方法來(lái)管理項(xiàng)目資源、處理問(wèn)題和指導(dǎo)項(xiàng)目參與者。如果一切順利（即，項(xiàng)目在預(yù)算范圍內(nèi)按進(jìn)度進(jìn)行，復(fù)審結(jié)果表明的確取得了實(shí)際進(jìn)展，達(dá)到了各個(gè)里程碑 ），則幾乎不必施加控制。但是如 果出現(xiàn)問(wèn)題，項(xiàng)目管理者就 必須施加控制，以便盡快解決問(wèn)題。當(dāng)問(wèn)題得到診斷之后，可能需要增加額外的資源以解決問(wèn)題：如可能需要雇傭新員工，或者需要重新定義項(xiàng)目進(jìn)度。表7 4 一個(gè)項(xiàng)目表的例子工作任務(wù)計(jì)劃開(kāi)始實(shí)際開(kāi)始計(jì)劃結(jié)束實(shí)際結(jié)束人員分配工作量分配附注1.1.1標(biāo)出需求和效益會(huì)見(jiàn)客戶 wk1,d1 wk1,d1 wk1,d2 wk1,d2 BLS 2p-d標(biāo)出需求和項(xiàng)目 約束 wk1,d2 w

50、k1,d2 wk1,d2 wk1,d2 JPP 1p-d 建立產(chǎn)品說(shuō)明 wk1,d3 wk1,d3 wk1,d3 wk1,d3 BLS/JPP 1p-d里程碑：定義產(chǎn)品說(shuō)明 wk1,d3 wk1,d3 wk1,d3 wk1,d31.1.2定義希望的輸出/控制 輸入(OCI)確定鍵盤(pán)功能 wk1,d4 wk1,d4 wk2,d2 BLS 1.5p-d 確 定語(yǔ)音輸入功能 wk1,d3 wk1,d3 wk2,d2 JPP 2p-d 確定交互模式 wk2,d1 wk2,d3 MLL 1p-d 確定文檔診斷 wk2,d1 wk2,d2 BLS 1.5p-d 確定其他 WP 功能 wk1,d4 wk1,

51、d4 wk2,d3 JPP 2p-d 做 OCI 文檔 wk2,d1 wk2,d3 MLL 3p-dFTR :與客戶復(fù)審 OCI wk2,d3 wk2,d3 all 3p-d按要求修改 OCI wk2,d4 wk2,d4 all 3p-d里程碑：定義 OCI wk2,d5 wk2,d5I.1.3定義功能行為在面對(duì)交付期限的巨大壓力時(shí)，有經(jīng)驗(yàn)的項(xiàng)目管理者有時(shí)會(huì)使用一種稱(chēng)為時(shí)間盒” ZAH95 的項(xiàng)目進(jìn)度安排和控制技術(shù)。時(shí)間盒策略認(rèn)識(shí)到完整的產(chǎn)品可能難以在預(yù)定時(shí)間內(nèi)交付，因此，應(yīng)該選擇增量軟件開(kāi)發(fā)范型，并為每個(gè)增量的交付定義各自的進(jìn)度。接著，對(duì)與每個(gè)增量相關(guān)的任務(wù)實(shí)行時(shí)間盒技術(shù)。這意味著通過(guò)對(duì)增量

52、的交付日期倒退著推算，來(lái)調(diào)整每項(xiàng)任務(wù)的進(jìn)度。在每項(xiàng)任務(wù)前后加上了一個(gè) 盒子”，當(dāng)任務(wù)觸及其時(shí)間盒邊界時(shí)（正負(fù)10%的范圍內(nèi)），則該項(xiàng)任務(wù) 停止，下一任務(wù)開(kāi)始。對(duì)于時(shí)間盒方法的第一個(gè)反應(yīng)通常是反面的：如果工作尚未完成，我們?cè)撊绾卫^續(xù)？ ”答案就隱藏在工作的完成方式中。在遇到時(shí)間盒的邊界時(shí)，很可能任務(wù)的90%已經(jīng)完成。余下的10%工作盡管重要，但是可以 （1）被推 遲到下一個(gè)增量中，或者 （2）在以后需要時(shí)再 完成。項(xiàng)目朝著交付日期逐步進(jìn)展，而不是被某個(gè)任務(wù)卡住”。 千萬(wàn)注意：進(jìn)度延遲是某種潛在問(wèn)題的癥狀。項(xiàng)目管理者的角色是論斷出潛在的問(wèn)題，并采取行動(dòng)改正之。 愛(ài)挖苦人的人也許會(huì)想起一句諺語(yǔ)：完成

53、系統(tǒng)的前90%需要90%的時(shí)間，完成剩下的10%也要用90%的時(shí)間”。7.8項(xiàng)目計(jì)劃軟件工程過(guò)程中的每一步驟都應(yīng)該產(chǎn)生可以被復(fù)審并能夠作為后續(xù)步驟的基礎(chǔ)的工作產(chǎn)品。軟件項(xiàng)目計(jì)劃在計(jì)劃任務(wù)結(jié)束時(shí)產(chǎn)生，它給出了基線的成本及進(jìn)度信息，這些信息將會(huì)在整個(gè)軟件工程過(guò)程中被使用。軟件項(xiàng)目計(jì)劃是一種面向廣大讀者的相對(duì)簡(jiǎn)短的文檔。它必須能夠（1）在軟件管理者、技術(shù)人員和客戶之間傳達(dá)項(xiàng)目范圍和資源信息；定義風(fēng)險(xiǎn)并提出有關(guān)風(fēng)險(xiǎn)管理技術(shù)的建議；（3）定義管理復(fù)審的成本和進(jìn)度；為與 項(xiàng)目相關(guān)的所有人員提供軟件開(kāi)發(fā)的整體方法；（5）概述如何保證質(zhì)量及變化的管理。表 7-5給出了一個(gè)軟件項(xiàng)目計(jì)劃的大綱。針對(duì)不同的讀者，所

54、顯示的成本和進(jìn)度可能有所不同。如果計(jì)劃只作為內(nèi)部文檔使用，則應(yīng)該給出各種成本估算技術(shù)所得到的結(jié)果。當(dāng)計(jì)劃在組織以外發(fā)布時(shí)，應(yīng)該給出一份經(jīng)過(guò)整合的成本細(xì)分表（結(jié)合了所有成本估算技術(shù)的結(jié)果）。類(lèi)似的，進(jìn)度信息的詳細(xì)程度也應(yīng)該隨讀者和計(jì)劃正式程度的不同而有所不同。軟件項(xiàng)目計(jì)劃不必過(guò)于冗長(zhǎng)復(fù)雜，其目的是幫助確立軟件開(kāi)發(fā)工作的有效性。該計(jì)劃集中于 做什么”的一般性說(shuō)明和特定的多少資源”與 多 長(zhǎng)時(shí)間”的說(shuō)明。軟件工程過(guò)程中的后續(xù)步驟將集中來(lái)完成項(xiàng)目的定義、開(kāi)發(fā)和維護(hù)。1. 引言A.計(jì)劃的目的 B.項(xiàng)目范圍和目標(biāo)1范圍說(shuō)明2. 主要功能3. 性能問(wèn)題4. 管理及技術(shù)約束n .項(xiàng)目估算表7 5軟件項(xiàng)目計(jì)劃3

55、.風(fēng)險(xiǎn)管理（意外事件計(jì)劃）IV .進(jìn)度A.項(xiàng)目工作細(xì)分結(jié)構(gòu)B.任務(wù)網(wǎng)絡(luò) C.時(shí)間表（甘特圖）D.資源表 V.項(xiàng)目資源 A.人員A.用于估算的歷史數(shù)據(jù)B.估算技術(shù)C.工作量、成本和持續(xù)時(shí)間的估算川.風(fēng)險(xiǎn)管理策略A. 風(fēng)險(xiǎn)表B.對(duì)需管理的風(fēng)險(xiǎn)的討論C.每個(gè)風(fēng)險(xiǎn)的 RMMM計(jì)劃1. 風(fēng)險(xiǎn)緩解2. 風(fēng)險(xiǎn)監(jiān)控B. 硬件和軟件資源 C.特殊資源W .人員組織A.項(xiàng)目組結(jié)構(gòu)（如果需要）B.管理報(bào)告 W .跟蹤及控制機(jī)制 A.質(zhì)量保證和控制B.變化管理和控制忸.附錄7.9小結(jié)進(jìn)度安排是計(jì)劃活動(dòng)的首要任務(wù)，而計(jì)劃活動(dòng)則是軟件項(xiàng)目管理的首要組成部分。與估算方法和風(fēng)險(xiǎn)分析相結(jié)合，進(jìn)度安排將為項(xiàng)目管理者建立起一張行路圖。進(jìn)度安排始于過(guò)程的分解。項(xiàng)目的特性被用于為需要完成的工作選擇一個(gè)適當(dāng)?shù)娜蝿?wù)集合