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

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)”之間的差別。6.3 在本章給出的所有風(fēng)險(xiǎn)檢查表中的條目中增加三個(gè)額外的問(wèn)題或主 題。6.4 你被要求建造一個(gè)軟件以支持一個(gè)低成本的視頻編輯系統(tǒng)。該系統(tǒng) 將錄像帶作為輸入設(shè)備，將視頻信息存在磁盤上，并允許用戶對(duì)已經(jīng)數(shù)字化 的視頻信息進(jìn)行各種編輯。對(duì)這類系統(tǒng)做一些調(diào)研，然后列出當(dāng)你開始啟動(dòng) 該項(xiàng)目以建造視頻編輯系統(tǒng)時(shí)，你將面臨的技術(shù)風(fēng)險(xiǎn)是什么。6.5 你是一家大型軟件公司的項(xiàng)目管理者。你被要求領(lǐng)導(dǎo)一個(gè)小組開發(fā)“下一代”字處理軟件(見 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 為圖 62 中的三個(gè)風(fēng)險(xiǎn)建立風(fēng)險(xiǎn)緩解策略及特定的風(fēng)險(xiǎn)緩解活動(dòng)。6.9 為圖 62 中的三個(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 為圖 62 中的三個(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)D 64 所示的風(fēng)險(xiǎn)參考水平值，該曲線是否總是如圖顯示的那么勻稱光滑，或者是否會(huì)有該曲線扭曲變形的情況存在？如果有，請(qǐng)舉出 一個(gè)例子。6.13 做一些關(guān)于軟件安全方面的研究，并寫一份簡(jiǎn)單的報(bào)告?？梢詤⒖糒EV95做為起點(diǎn)。6.14 描述五個(gè)軟件安全和危險(xiǎn)分析是主要關(guān)心對(duì)象的軟件應(yīng)用領(lǐng)域。第 7 章 項(xiàng)目進(jìn)度安排及跟蹤在六十年代后期，一位熱情的青年工程師受命為一個(gè)自動(dòng)制造應(yīng)用軟件 項(xiàng)目“編寫”計(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è)，想好了解決方法，就開始編寫代碼。兩周之后，老 板將他叫到辦公室詢問(wèn)項(xiàng)目進(jìn)展情況。“非常好，”工程師以年輕人的熱情回答道，“這個(gè)項(xiàng)目遠(yuǎn)比我想象的 簡(jiǎn)單。我差不多已經(jīng)完成了 75的任務(wù)。”老板笑了，說(shuō)道：“真是太棒了。”然后他囑咐年輕人繼續(xù)努力工作， 準(zhǔn)備好一周后再匯報(bào)一次工作進(jìn)度。一周之后老板將年輕人叫到辦公室，問(wèn)他說(shuō)：“現(xiàn)在進(jìn)度如何？” “一切順利，”年輕人回答說(shuō)，“但是我遇到了一些小麻煩。我會(huì)排除這些困難，很快就可以回到正軌上來(lái)?！薄澳阌X得在最后期限之前能否完成？”老板問(wèn)道。 “沒有問(wèn)題，”工程師答道?！拔也畈欢嘁呀?jīng)完成了 90?！?如果讀者在軟件領(lǐng)域中工作過(guò)幾年，你一定可以將這個(gè)故事寫完。毫不奇怪，青年工程師在整個(gè)項(xiàng)目工期內(nèi)始終停留在 90的進(jìn)度上，(在別人的幫助下)直到交付期限之后一個(gè)月才做完。在過(guò)去的 30 年間，這樣的故事被不同的軟件開發(fā)者重復(fù)了成千上萬(wàn)次。 我們不禁要問(wèn)：“為什么？”7.1 基本概念雖然軟件延期交付的原因很多，但是大多數(shù)都可以追溯到下面列出的一 個(gè)或多個(gè)根本原因上：一個(gè)不現(xiàn)實(shí)的截止期限，由軟件工程組以外的人所設(shè)立并強(qiáng)加給軟件工程組內(nèi)的管理者和項(xiàng)目開發(fā)者。客戶需求發(fā)生變化，而需求的變化沒有能夠反映在項(xiàng)目進(jìn)度的變化上。對(duì)工作量和/或完成該工作所需的資源數(shù)量估計(jì)不足。在項(xiàng)目開始時(shí)，沒有將可以預(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)目完成期限已經(jīng)司空見慣。有時(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)度安排的壓力并將這種壓力反映給施加壓力的一方”PAG85。 不妨舉例說(shuō)明，假定一個(gè)軟件開發(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àn)實(shí)。外部市場(chǎng)壓力決定了交付日期，屆時(shí)必須發(fā)布產(chǎn)品。 而(從事業(yè)前途的角度出發(fā))拒絕這一項(xiàng)目同樣是魯莽的。那么應(yīng)該怎么辦 呢？在這種情況下，推薦以下的處理步驟：1.使用從以前的項(xiàng)目中得到的數(shù)據(jù)，進(jìn)行詳細(xì)的估算。確定項(xiàng)目的估算 工作量和持續(xù)時(shí)間。2.使用增量過(guò)程模型(參見第 2 章)，制定一個(gè)軟件開發(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ì)分類表和以多種不同方式進(jìn)行的項(xiàng)目估算提 交給各位，你會(huì)注意到我已經(jīng)假設(shè)與以往的生產(chǎn)率相比有 20的提高，但是 我們?nèi)匀恢荒艿玫?14 個(gè)月而不是 9 個(gè)月的交付時(shí)間。”4.將增量開發(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ō)，增加更多的人手不會(huì)成比例的縮短完成項(xiàng)目所需的時(shí)間。并在總共 14 個(gè)月的時(shí)間內(nèi)發(fā)布這些功能。第三種選擇是不顧現(xiàn)實(shí)條件的約 束，而希望項(xiàng)目能夠在 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 ManMonth，見文 獻(xiàn)BRO95)一書的作者 Fred Brooks，“軟件項(xiàng)目的進(jìn)度是如何延遲的？” 他的回答即簡(jiǎn)單又深刻：“一天一次?！奔夹g(shù)性項(xiàng)目(不論它是涉及到水力發(fā)電廠建設(shè)，還是開發(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)目進(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è)不同的視角考察軟件開發(fā)項(xiàng)目的進(jìn)度安排。第一個(gè)視角，基于計(jì)算機(jī)的系統(tǒng)的最終發(fā)布日期已經(jīng)確定(而且不能更改)。軟件開發(fā)組織在 這一約束下將工作量分布在預(yù)先確定的時(shí)間框架內(nèi)。第二個(gè)視角，假定大致 的時(shí)間界限已經(jīng)討論過(guò)，但是最終發(fā)布日期是由軟件開發(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)行分解(參見第 3 章)。相互依賴性：各個(gè)被劃分的活動(dòng)或任務(wù)之間的相互關(guān)系必須是確定的。 有些任務(wù)必須順序發(fā)生；而其他的則可以并發(fā)進(jìn)行。有些活動(dòng)只有在其他活 在本章中后面將詳細(xì)討論“關(guān)鍵路徑”。動(dòng)產(chǎn)生的工作產(chǎn)品完成時(shí)才能夠開始，而其他的則可以獨(dú)立進(jìn)行。時(shí)間分配：必須為每個(gè)被調(diào)度的任務(wù)分配一定數(shù)量的工作單位(例如， 若干人天的工作量)。此外，必須為每個(gè)任務(wù)指定開始和結(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è)特定的小組成員來(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ù)審(參見第 8 章)并且得到認(rèn)可時(shí)，標(biāo)志著一個(gè) 里程碑的完成。隨著項(xiàng)目進(jìn)度的發(fā)展，上述每一條原則都會(huì)被用到。7.2 人員與工作量之間的關(guān)系在一個(gè)小型軟件開發(fā)項(xiàng)目中，只需一個(gè)人就可以完成需求分析、設(shè)計(jì)、 編碼和測(cè)試。隨著項(xiàng)目規(guī)模的增長(zhǎng)，必然涉及到更多的人員參與(我們幾乎不 可能負(fù)擔(dān)讓一個(gè)人工作十年來(lái)完成 10 人年工作量的奢侈！)。許多負(fù)責(zé)軟件開發(fā)工作的管理者仍然堅(jiān)信一個(gè)普遍存在的荒誕想法(參見第 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è)成功的軟件開發(fā) 項(xiàng)目而言絕對(duì)是必不可少的，但是每增加一條新的通信路徑就會(huì)增加額外的 工作量，從而需要更多的時(shí)間。7.2.1 一個(gè)例子讓我們來(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)原本可以用于軟件開發(fā) 的工作時(shí)間。由于增加了通信成本，我們將假定每增加一條通信路徑將會(huì)使 項(xiàng)目組的生產(chǎn)率(以 LOC 計(jì)算)降低 250 LOC/年。因此項(xiàng)目組的生產(chǎn)率為 20000 實(shí)際上由于與工作無(wú)關(guān)的會(huì)議、病假、休假和各種其他原因，可供分配的工作量要少于 3 人天。但是在本書中，我們將假定員工時(shí)間是 100可用的。(2506)18500LOC/年，比期望數(shù)字低了 7.5。 上述項(xiàng)目組承擔(dān)的為期一年的項(xiàng)目現(xiàn)在只剩下兩個(gè)月時(shí)間，但是已經(jīng)落后于進(jìn)度，這時(shí)又加入了 2 名工程師。于是通信路徑激增為 14，在交付之前 剩下的兩個(gè)月時(shí)間里，新增加成員的生產(chǎn)能力為 84021680 LOC。而目前 的項(xiàng)目組生產(chǎn)率為 200001680(25014)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ù)審(參見第 8 章)將得到更好的分析和設(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，我們可以看到在 完成項(xiàng)目的時(shí)間與投入項(xiàng)目中的人員的工作量之間存在著高度非線性關(guān)系。 交付的代碼(源代碼語(yǔ)句)行數(shù) L 與工作量和開發(fā)時(shí)間之間的關(guān)系可以用下面 的公式表示：LP (E/B)1/3t4/3其中 E 是以人月為單位的開發(fā)工作量；P 是一個(gè)生產(chǎn)率參數(shù)，它反映了 導(dǎo)致高質(zhì)量軟件工程工作的各種因素的綜合效果(P 通常取值在 2，000 到 28，000 之間)；B 是特殊技術(shù)因子，在 0.16 到 0.39 之間取值，是所生產(chǎn)軟件的規(guī)模的函數(shù)；t 是以月為單位的項(xiàng)目持續(xù)時(shí)間。 將上述軟件方程式重排，可以得到關(guān)于開發(fā)工作量 E 的計(jì)算公式：E L3/(P3t4) (7.1)其中 E 是在軟件開發(fā)和維護(hù)的整個(gè)生命周期內(nèi)所需的工作量(以人年計(jì) 算)，t 是以年計(jì)算的開發(fā)時(shí)間。通過(guò)引入平均勞動(dòng)力價(jià)格因素($/人年)，開 發(fā)工作量的計(jì)算公式還能夠與開發(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年，則公式(7.1) 中的模型所具有的高度非線性特性將導(dǎo)致如下結(jié)果：EL3/(P3t4)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ì)完成軟件開發(fā)所需人月(或者人年)的估算。一種推薦的在定義和開發(fā)階段之間的工作量分 布通常被稱為“40-20-40 規(guī)則”。40或者更多的工作量分配給前端的分 析和設(shè)計(jì)任務(wù)。類似比例的工作量用于后端測(cè)試。你可以推斷出編碼工作(大約 20的工作量)沒有被著重強(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的工作量，用 于分析或原型開發(fā)的工作量應(yīng)該與項(xiàng)目規(guī)模和復(fù)雜度成正比的增長(zhǎng)。通常有20到 25的工作量用于軟件設(shè)計(jì)，用于設(shè)計(jì)復(fù)審和隨之而來(lái)的迭代開發(fā)也 必須列入考慮之中。因?yàn)樵谲浖O(shè)計(jì)時(shí)投入了相當(dāng)?shù)墓ぷ髁?，隨后的編碼工作就變得相對(duì)簡(jiǎn) 單。15到 20的工作量就可以完成這一工作。測(cè)試和隨之而來(lái)的調(diào)試工作 將占用 30到 40的軟件開發(fā)工作量。軟件的重要性決定了所需測(cè)試工作的 份量，如果軟件系統(tǒng)是人命相關(guān)的(即，軟件錯(cuò)誤可能使人喪命)，就應(yīng)該考 慮分配更高的測(cè)試工作量比例。7.3 為軟件項(xiàng)目定義任務(wù)集合在第二章中，我們描述了多種不同的過(guò)程模型。這些模型為軟件開發(fā)提 供了不同的范型。如果不考慮一個(gè)軟件項(xiàng)目組選擇的是線性順序范型、迭代 開發(fā)模型、演化開發(fā)模型、并發(fā)開發(fā)模型還是組合使用這些模型，則過(guò)程模 型都是由一個(gè)任務(wù)集合組成的，它使得軟件項(xiàng)目組能夠定義、開發(fā)和最終維 護(hù)計(jì)算機(jī)軟件。沒有一個(gè)普遍適用于所有軟件項(xiàng)目的任務(wù)集合。適用于大型復(fù)雜系統(tǒng)的項(xiàng)目任務(wù)集合可能對(duì)于小型且相對(duì)簡(jiǎn)單的項(xiàng)目而言就過(guò)于復(fù)雜。因此一個(gè)有 效的軟件過(guò)程應(yīng)該定義一組“任務(wù)集合”，各個(gè)任務(wù)集合的設(shè)計(jì)可以滿足不 同類型項(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)用于不同類型的項(xiàng)目和不同的嚴(yán)格度。盡管 很難建立一個(gè)全面詳盡的分類結(jié)構(gòu)，但是大多數(shù)軟件組織接手的項(xiàng)目一般屬 于下述類型：概念開發(fā)項(xiàng)目：項(xiàng)目的目的是為了探索某些新的商業(yè)概念或者某種新技 術(shù)的應(yīng)用。新應(yīng)用開發(fā)項(xiàng)目：根據(jù)特定的客戶需求而承擔(dān)的項(xiàng)目。應(yīng)用增強(qiáng)項(xiàng)目：對(duì)現(xiàn)有軟件進(jìn)行最終用戶可察覺的功能、性能或界面的 修改。 現(xiàn)在對(duì)于大型軟件開發(fā)項(xiàng)目而言，通常多于 40的全部項(xiàng)目工作量用于分析和設(shè)計(jì)任務(wù)。因此從嚴(yán)格意義上講，“40-20-40”，的名稱已經(jīng)不再適用。應(yīng)用維護(hù)項(xiàng)目：以一種最終用戶不會(huì)立即察覺到的方式對(duì)現(xiàn)有軟件進(jìn)行 糾錯(cuò)、適應(yīng)或者擴(kuò)展。再工程項(xiàng)目：為了全部或部分重建一個(gè)現(xiàn)有(遺留)系統(tǒng)而承擔(dān)的項(xiàng)目。 即使在單一的項(xiàng)目類型中，也會(huì)有許多因素影響任務(wù)集合的選擇。當(dāng)將 這些因素綜合考慮時(shí)，就會(huì)構(gòu)成一個(gè)稱為“嚴(yán)格度”的指示量，它將應(yīng)用于所采用的軟件過(guò)程中。7.3.1 嚴(yán)格度即使只考慮某種特定類型的項(xiàng)目，所采用的軟件過(guò)程的嚴(yán)格度也會(huì)相當(dāng) 不同。嚴(yán)格度是眾多項(xiàng)目特性的函數(shù)。例如，小型的非主要商業(yè)性質(zhì)的項(xiàng)目 的嚴(yán)格度一般可以小于大型復(fù)雜的主要業(yè)務(wù)應(yīng)用程序。但是應(yīng)該注意到，所 有項(xiàng)目都必須以一種能夠按時(shí)得到高質(zhì)量的發(fā)布產(chǎn)品的方式來(lái)實(shí)施?？梢远?義如下的 4 種不同程度的嚴(yán)格度：隨意的：使用了所有過(guò)程框架活動(dòng)(參見第 2 章)，但只需要一個(gè)最小的 任務(wù)集合。一般情況下，將保護(hù)性任務(wù)最小化，并將文檔需求降低。所有基 本的軟件工程原則仍然都是適用的。結(jié)構(gòu)化的：在項(xiàng)目中將使用過(guò)程框架?？蚣芑顒?dòng)和適用于這種項(xiàng)目類型的相關(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)都將被采用，且要建立健壯的文檔。快速反應(yīng)的：該項(xiàng)目將使用過(guò)程框架，但是由于某種緊急情況的出現(xiàn)， 只應(yīng)用了那些為保持軟件系統(tǒng)質(zhì)量所必須完成的任務(wù)。在應(yīng)用程序/產(chǎn)品交付 給客戶之后再完成“回填工作”(即開發(fā)一套完整的文檔，進(jìn)行額外的復(fù)審)。 項(xiàng)目管理者必須開發(fā)一種系統(tǒng)化的方法用以選擇適用于特定項(xiàng)目的嚴(yán)格 度。為了做到這一點(diǎn)，需要定義項(xiàng)目適應(yīng)性準(zhǔn)則并計(jì)算“任務(wù)集合選擇因子”的值。7.3.2 定義適應(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開發(fā)者之間通信的容易程度。 緊急情況應(yīng)該非常罕見（在軟件工程的討論范圍內(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.PressmanAssociates ，Inc.的許可。欲知有關(guān)詳情，請(qǐng)發(fā)電子郵件給 .應(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) 高的項(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)該輸入到表 71 中。2.復(fù)審賦予每個(gè)適應(yīng)性準(zhǔn)則的加權(quán)因子。加權(quán)因子的取值在 0.8 到 1.2 之間，表明了對(duì)在當(dāng)前環(huán)境中開發(fā)的軟件類型而言特定適應(yīng)性準(zhǔn)則的相對(duì)重 要性。如果需要，則可以進(jìn)行修改，以反映當(dāng)前的環(huán)境。3.將表 7.1 中的等級(jí)分?jǐn)?shù)與加權(quán)因子相乘，再乘以表示當(dāng)前項(xiàng)目類型的條目點(diǎn)乘數(shù)。條目點(diǎn)乘數(shù)在 0 到 1 之間取值，表示該適應(yīng)性準(zhǔn)則與項(xiàng)目類型 之間的相關(guān)程度。對(duì)應(yīng)于各個(gè)適應(yīng)性準(zhǔn)則的相乘結(jié)果：等級(jí)分?jǐn)?shù)加權(quán)因子條目點(diǎn)乘數(shù)分別放入表 71 的“乘積”欄中。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 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) 7.3.4 解釋 TSS 值并選擇任務(wù)集合一旦計(jì)算好任務(wù)集合選擇因子，就可以使用下述的指南幫助你選擇一個(gè) 適用于項(xiàng)目的任務(wù)集合：任務(wù)集合選擇因子取值 嚴(yán)格度TSS1.2 隨意的1.0TSS3.0 結(jié)構(gòu)化的 TSS2.4 嚴(yán)格的兩個(gè)推薦任務(wù)集合之間的 TSS 取值的重疊是有意設(shè)定的，這用于說(shuō)明在進(jìn)行任務(wù)集合的選擇時(shí)，定義出精確的邊界是不可能的。在進(jìn)行最后的分析 時(shí)，應(yīng)該將任務(wù)集合選擇因子的取值、以往的經(jīng)驗(yàn)以及常識(shí)都作為項(xiàng)目任務(wù) 集合的選擇因素。表 72 顯示了在一個(gè)假想的項(xiàng)目中如何計(jì)算 TSS 的情況。項(xiàng)目管理者在“等級(jí)分?jǐn)?shù)”一欄中選擇等級(jí)分值，項(xiàng)目類型是“新應(yīng)用開發(fā)”。因此其條 目點(diǎn)乘數(shù)應(yīng)該從“新應(yīng)用”一欄中選擇。“乘積”一欄中條目的計(jì)算使用如 下公式等級(jí)分?jǐn)?shù)加權(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) 維護(hù) 再工程項(xiàng)目規(guī)模 2 1.20 1 2.4 用戶數(shù)量 3 1.10 1 3.3 業(yè)務(wù)關(guān)鍵性 4 1.10 1 4.4 壽命 3 0.9 1 2.7 需求穩(wěn)定性 2 1.2 1 2.4 易于通信 2 0.9 1 1.8 技術(shù)成熟度 2 0.9 1 1.8 性能約束 3 0.8 1 2.4 嵌入式/非嵌入式 3 1.2 1 3.6 項(xiàng)目人員配置 2 1.0 1 2.0 互操作 4 1.1 1 4.4 再工程因素 0 1.2 0 2.8任務(wù)集合選擇因子(TSS) 2.87.4 選擇軟件工程任務(wù)為了制定項(xiàng)目進(jìn)度安排，必須將任務(wù)集合分布在項(xiàng)目時(shí)間表上。如 7.3 節(jié)所述，任務(wù)集合將根據(jù)項(xiàng)目類型和嚴(yán)格度的不同而有所不同。7.3 節(jié)中的 每種項(xiàng)目類型都可以使用線性順序、迭代(如，原型模型)或者演化(如，螺旋 模型)等過(guò)程模型來(lái)實(shí)現(xiàn)。在某些情況下，項(xiàng)目類型可以從一種形式平滑的轉(zhuǎn) 換為另一種形式。例如，成功的概念開發(fā)項(xiàng)目通常會(huì)演化成為新應(yīng)用開發(fā)項(xiàng) 目，而新應(yīng)用開發(fā)項(xiàng)目結(jié)束之后，可能又開始了一個(gè)應(yīng)用增強(qiáng)項(xiàng)目。這種進(jìn) 程是自然且可預(yù)測(cè)的，而不論是采用何種過(guò)程模型來(lái)組織。作為一個(gè)例子， 下面我們將考慮概念開發(fā)項(xiàng)目的主要軟件工程任務(wù)。概念開發(fā)項(xiàng)目是在必須探索某些新技術(shù)是否可行時(shí)發(fā)起的。這種技術(shù)是否可行尚不可知，但是某個(gè)客戶(如營(yíng)銷部門)相信其潛在利益的存在。概念 開發(fā)項(xiàng)目的完成需要應(yīng)用下面所述的主要任務(wù)：確定概念范圍：確定項(xiàng)目的整體范圍。 初步的概念計(jì)劃：確定組織的能力，以承擔(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)概念 必須被賣給其他客戶或管理者時(shí)能夠用于“推銷”的目的?？蛻魧?duì)概念的反應(yīng)：向客戶索取對(duì)新技術(shù)概念的反饋，并以特定的客戶 應(yīng)用作為目標(biāo)?？焖贋g覽上述主要任務(wù)，你應(yīng)該不會(huì)有何詫異。實(shí)際上概念開發(fā)項(xiàng)目的軟件工程任務(wù)流程(以及其他所有類型的項(xiàng)目)與人們的常識(shí)相差無(wú)幾。 軟件開發(fā)組必須知道哪些任務(wù)是必須完成的(項(xiàng)目范圍)；項(xiàng)目組(或管理者)必須確定目前是否有人能夠進(jìn)行這一工作(計(jì)劃)；考慮與工作相關(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)品版本開發(fā)出來(lái)(技術(shù)轉(zhuǎn) 化)。有非常重要的一點(diǎn)需要注意，概念開發(fā)任務(wù)本質(zhì)上是迭代的。這就是說(shuō)， 一個(gè)實(shí)際的概念開發(fā)項(xiàng)目也許會(huì)通過(guò)多個(gè)有計(jì)劃的增量步驟得以實(shí)現(xiàn)，每個(gè) 步驟都被設(shè)計(jì)成能夠產(chǎn)生一個(gè)可供客戶評(píng)價(jià)的可發(fā)布版本。如果選擇使用線性過(guò)程模型，則每一個(gè)增量都被定義為如圖 71 所示的 一個(gè)重復(fù)序列。在每個(gè)序列中，將使用保護(hù)性活動(dòng)(參見第 2 章中的描述)； 監(jiān)控軟件質(zhì)量，且在每個(gè)序列的末尾，將產(chǎn)生一個(gè)可交付產(chǎn)品。隨著逐次迭 代的過(guò)程，可交付產(chǎn)品應(yīng)該向著在概念開發(fā)階段已經(jīng)定義的最終產(chǎn)品收斂。 如果選擇的是演化開發(fā)模型，則從任務(wù) 1.1 到 1.6 的分布應(yīng)該如圖 72 中所 示?？梢砸灶愃频姆绞蕉x和使用關(guān)于其他項(xiàng)目類型的主要軟件工程任務(wù)。7.5 主要任務(wù)的求精在 7.4 節(jié)中所描述的主要任務(wù)可以被用于定義項(xiàng)目的宏觀進(jìn)度表。例 如，概念開發(fā)項(xiàng)目中描述的任務(wù)可以用于定義該項(xiàng)目的任務(wù)網(wǎng)絡(luò)(參見 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ù)。任務(wù)精化可以使用大綱格式完成，但是在本書中將使用一種過(guò)程設(shè)計(jì)語(yǔ) 言來(lái)闡明“確定概念范圍”這一活動(dòng)的流程：任務(wù) I.1 確定概念范圍I.1.1 標(biāo)出需求、效益和潛在的客戶；I.1.2 定義所希望的輸出/控制和驅(qū)動(dòng)應(yīng)用程序的輸入事件； Begin 任務(wù) I.1.2I.1.2.1FTR：復(fù)審需求的書面說(shuō)明I.1.2.2 導(dǎo)出一個(gè)客戶可見的輸出/輸入列表 case of：mechanics mechanics質(zhì)量功能配置 與客戶會(huì)談，以劃分主要的概念需求； 會(huì)見最終用戶；觀察現(xiàn)有的解決問(wèn)題的方法和當(dāng)前的問(wèn)題解決過(guò)程； 復(fù)審以往的要求和抱怨； 過(guò)程設(shè)計(jì)語(yǔ)言與 14 章中討論的程序設(shè)計(jì)語(yǔ)言在語(yǔ)法上是類似的。 FTR 表示在此需要進(jìn)行一次正式的技術(shù)復(fù)審（參見第 8 章）mechanics結(jié)構(gòu)化分析 列出主要數(shù)據(jù)對(duì)象； 定義對(duì)象之間的關(guān)系； 定義對(duì)象的屬性； mechanics對(duì)象視圖 列出問(wèn)題類； 確定類層次和類連接； 定義各個(gè)類的屬性； endcaseI.1.2.3FTR：與客戶一起復(fù)審輸出/輸入，并在需要時(shí)進(jìn)行修改；endtask 任務(wù) I.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ì)見最終用戶；觀察現(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é)； 為最底層精化圖的功能書寫處理過(guò)程說(shuō)明； mechanics對(duì)象視圖 定義與各個(gè)類相關(guān)的操作/方法；endcaseI.1.3.3 與客戶一起復(fù)審功能/行為模型，并在需要時(shí)進(jìn)行修改；endtask 任務(wù) I.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任務(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è)開發(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è)概念開發(fā)項(xiàng)目的任務(wù)網(wǎng)絡(luò)示意圖。軟件工程活動(dòng)的并發(fā)本質(zhì)導(dǎo)致了若干重要的調(diào)度需求。由于并行任務(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)題。圖 73 中所示的任務(wù)網(wǎng)絡(luò)是宏觀的，注意到這一點(diǎn)非常重要。在一個(gè)詳 細(xì)的任務(wù)網(wǎng)絡(luò)(詳細(xì)進(jìn)度表的前驅(qū))中，應(yīng)該對(duì)圖 73 所示的各個(gè)活動(dòng)加以擴(kuò) 展。例如，應(yīng)該擴(kuò)展任務(wù) I.1，以顯示 7.5 節(jié)所述的精化中的所有詳細(xì)任務(wù)。7.7 進(jìn)度安排軟件項(xiàng)目的進(jìn)度安排與任何其他多任務(wù)工程工作的進(jìn)度安排幾乎沒有太 多的差別。因此，通用的項(xiàng)目進(jìn)度安排工具和技術(shù)不必做太多修改就可以應(yīng) 用于軟件項(xiàng)目?！俺绦蛟u(píng)估和復(fù)審技術(shù)(PERT)”和“關(guān)鍵路徑方法(CPM)”MOD83就是兩種可以用于軟件開發(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)目類型和任務(wù)集合的選擇。 任務(wù)之間的依賴關(guān)系可以使用任務(wù)網(wǎng)絡(luò)來(lái)定義。任務(wù)，有時(shí)也稱作項(xiàng)目的“工作細(xì)分結(jié)構(gòu)”(WBS)，其定義可以是針對(duì)整個(gè)產(chǎn)品，也可以是針對(duì)單個(gè)功能進(jìn)行的。PERT 和 CPM 兩種方法都提供項(xiàng)目工作定量劃分的工具，能支持軟件計(jì)劃 者(1)確定關(guān)鍵路徑一決定項(xiàng)目持續(xù)時(shí)間的任務(wù)鏈；(2)通過(guò)使用統(tǒng)計(jì)模型為 單個(gè)任務(wù)建立最有可能的時(shí)間估算；(3)計(jì)算為特定任務(wù)定義其時(shí)間“窗口” 的邊界時(shí)間。邊界時(shí)間的計(jì)算對(duì)軟件項(xiàng)目進(jìn)度的安排十分有用。比如說(shuō)，某個(gè)功能的 設(shè)計(jì)的推遲可能進(jìn)一步導(dǎo)致其他功能開發(fā)的拖后。RiggsRIG81描述了一 些能夠從 PERT 或 CPM 網(wǎng)絡(luò)中得到的重?5 謀囈縭奔洌海*1)某個(gè)任務(wù)的最早 開始時(shí)間是當(dāng)其所有前驅(qū)任務(wù)在最短的可能時(shí)間中完成時(shí)；(2)某個(gè)任務(wù)的最 晚開始時(shí)間是在不延遲項(xiàng)目最小完成時(shí)間的前提下，最晚啟動(dòng)該任務(wù)的時(shí) 間；(3)最早結(jié)束時(shí)間最早開始時(shí)間加上任務(wù)持續(xù)時(shí)間；(4)最晚結(jié)束時(shí) 間最晚開始時(shí)間加上任務(wù)持續(xù)時(shí)間；以及(5)總浮動(dòng)量在保證進(jìn)度的 前提下，調(diào)度任務(wù)時(shí)所允許的富余時(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。這類工具易于使用，且使得每一位軟件 項(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í)間和開始時(shí)間。此外，每一項(xiàng)任 務(wù)都必須被分配給特定的人員。上述輸入的結(jié)果之一是產(chǎn)生“時(shí)間表(Timeline Chart)”，也叫做“甘 特圖(Gantt Chart)”?？梢詾檎麄€(gè)項(xiàng)目建立一個(gè)時(shí)間表，也可以為各個(gè)項(xiàng)目 功能或各個(gè)項(xiàng)目參與者分別開發(fā)各自的時(shí)間表。表 73 給出了時(shí)間表的格式，該圖描述了一個(gè)新的字處理軟件產(chǎn)品中 “確定概念范圍”任務(wù)(參見 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í) 際的開始與結(jié)束日期、以及各種相關(guān)信息(參見圖 75)。項(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í)際開始日期與計(jì)劃開始日 期。與開發(fā)者進(jìn)行非正式會(huì)談，獲取他們對(duì)項(xiàng)目進(jìn)展及可能出現(xiàn)的問(wèn)題的 客觀評(píng)估。實(shí)際上，有經(jīng)驗(yàn)的項(xiàng)目管理者都會(huì)使用所有這些跟蹤技術(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ì)劃開始 實(shí)際開始 計(jì)劃結(jié)束 實(shí)際結(jié)束 人員分配 工作量分配 附注I.1.1 標(biāo)出需求和效益 會(huì)見客戶 wk1,d1 wk1,d1 wk1,d2 wk1,d2 BLS 2p-d 標(biāo)出需求和項(xiàng)目約束 wk1,d2 wk1,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,d3I.1.2 定義希望的輸出/控制 輸入(OCI) 確定鍵盤功能 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,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ì)使用一種稱為“時(shí)間盒”ZAH95的項(xiàng)目進(jìn)度安排和控制技術(shù)。時(shí)間盒策略認(rèn)識(shí)到完整 的產(chǎn)品可能難以在預(yù)定時(shí)間內(nèi)交付，因此，應(yīng)該選擇增量軟件開發(fā)范型，并 為每個(gè)增量的交付定義各自的進(jìn)度。接著，對(duì)與每個(gè)增量相關(guān)的任務(wù)實(shí)行時(shí)間盒技術(shù)。這意味著通過(guò)對(duì)增量的交付日期倒退著推算，來(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ù)開始。對(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)改正之。 愛挖苦人的人也許會(huì)想起一句諺語(yǔ)：“完成系統(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)目范圍和資源信息；(2)定義風(fēng)險(xiǎn) 并提出有關(guān)風(fēng)險(xiǎn)管理技術(shù)的建議；(3)定義管理復(fù)審的成本和進(jìn)度；(4)為與 項(xiàng)目相關(guān)的所有人員提供軟件開發(fā)的整體方法；(5)概述如何保證質(zhì)量及變化 的管理。表 7-5 給出了一個(gè)軟件項(xiàng)目計(jì)劃的大綱。針對(duì)不同的讀者，所顯示的成本和進(jìn)度可能有所不同。如果計(jì)劃只作為 內(nèi)部文檔使用，則應(yīng)該給出各種成本估算技術(shù)所得到的結(jié)果。當(dāng)計(jì)劃在組織 以外發(fā)布時(shí)，應(yīng)該給出一份經(jīng)過(guò)整合的成本細(xì)分表(結(jié)合了所有成本估算技術(shù) 的結(jié)果)。類似的，進(jìn)度信息的詳細(xì)程度也應(yīng)該隨讀者和計(jì)劃正式程度的不同 而有所不同。軟件項(xiàng)目計(jì)劃不必過(guò)于冗長(zhǎng)復(fù)雜，其目的是幫助確立軟件開發(fā)工作的有 效性。該計(jì)劃集中于“做什么”的一般性說(shuō)明和特定的“多少資源”與“多 長(zhǎng)時(shí)間”的說(shuō)明。軟件工程過(guò)程中的后續(xù)步驟將集中來(lái)完成項(xiàng)目的定義、開 發(fā)和維護(hù)。.引言 A.計(jì)劃的目的 B.項(xiàng)目范圍和目標(biāo)1.范圍說(shuō)明2.主要功能3.性能問(wèn)題4.管理及技術(shù)約束 .項(xiàng)目估算表 7 5 軟件項(xiàng)目計(jì)劃3.風(fēng)險(xiǎn)管理(意外事件計(jì)劃) .進(jìn)度 A.項(xiàng)目工作細(xì)分結(jié)構(gòu) B.任務(wù)網(wǎng)絡(luò) C.時(shí)間表(