軟件工程實施的幾個重要思想.doc

6.8 小結(jié)當(dāng)對軟件項目期望很高時，一般都會進(jìn)行風(fēng)險分析。不過，即使他們進(jìn) 行這項工作，大多數(shù)軟件項目管理者都是非正式地和表面上地完成它。花在 標(biāo)識、分析、和管理風(fēng)險上的時間可以從多個方面得到回報：更加平穩(wěn)的項目進(jìn)展過程；較高的跟蹤和控制項目的能力；由于在問題發(fā)生之前已經(jīng)做了 周密計劃而產(chǎn)生的信心。風(fēng)險分析需要占用大量項目計劃的工作量。標(biāo)識、預(yù)測、評估、管理、 及監(jiān)控都要花費時間。但這是值得的。引用中國 2500 多年前的兵法家孫子的 話：“知己知彼，百戰(zhàn)不殆”。對于軟件項目管理者而言，這個“彼”指的 就是風(fēng)險。思考題6.1 舉出五個其他領(lǐng)域的例子來說明與被動風(fēng)險策略相關(guān)的問題。6.2 描述“已知風(fēng)險”和“可預(yù)測風(fēng)險”之間的差別。6.3 在本章給出的所有風(fēng)險檢查表中的條目中增加三個額外的問題或主 題。6.4 你被要求建造一個軟件以支持一個低成本的視頻編輯系統(tǒng)。該系統(tǒng) 將錄像帶作為輸入設(shè)備，將視頻信息存在磁盤上，并允許用戶對已經(jīng)數(shù)字化 的視頻信息進(jìn)行各種編輯。對這類系統(tǒng)做一些調(diào)研，然后列出當(dāng)你開始啟動 該項目以建造視頻編輯系統(tǒng)時，你將面臨的技術(shù)風(fēng)險是什么。6.5 你是一家大型軟件公司的項目管理者。你被要求領(lǐng)導(dǎo)一個小組開發(fā)“下一代”字處理軟件(見 3.3.2 節(jié)的簡單描述)。為該項目建立一個風(fēng)險表。6.6 描述風(fēng)險因素和風(fēng)險驅(qū)動因子之間的不同。6.7 為項目風(fēng)險驅(qū)動因子建立一個加權(quán)方案。6.8 為圖 62 中的三個風(fēng)險建立風(fēng)險緩解策略及特定的風(fēng)險緩解活動。6.9 為圖 62 中的三個風(fēng)險建立風(fēng)險監(jiān)控策略及特定的風(fēng)險監(jiān)控活動。 確認(rèn)你已經(jīng)標(biāo)識出了你需要監(jiān)控的因素，并確定風(fēng)險發(fā)生的可能性是否在變 高或變低。6.10 為圖 62 中的三個風(fēng)險建立風(fēng)險管理策略及特定的風(fēng)險管理活動。6.11 你能否想到一種情況：一個高概率、高影響的風(fēng)險并不納入 RMMM 計劃的考慮之中？6.12 參照圖 64 所示的風(fēng)險參考水平值，該曲線是否總是如圖顯示的那么勻稱光滑，或者是否會有該曲線扭曲變形的情況存在？如果有，請舉出 一個例子。6.13 做一些關(guān)于軟件安全方面的研究，并寫一份簡單的報告。可以參考LEV95做為起點。6.14 描述五個軟件安全和危險分析是主要關(guān)心對象的軟件應(yīng)用領(lǐng)域。第 7 章 項目進(jìn)度安排及跟蹤在六十年代后期，一位熱情的青年工程師受命為一個自動制造應(yīng)用軟件 項目“編寫”計算機程序。選擇他的原因非常簡單，因為在整個技術(shù)小組中 他是唯一參加過計算機編程培訓(xùn)班的人。這位工程師對匯編語言的 IN 和 OUT 指令以及 Fortran 語言略知一二，但是卻根本不懂軟件工程，更不用說項目 進(jìn)度安排和跟蹤了。他的老板給了他一大堆相關(guān)的手冊，以及需要做些什么的口頭描述。年 輕人被告知該項目必須在兩個月之內(nèi)完成。他閱讀了這些手冊，想好了解決方法，就開始編寫代碼。兩周之后，老 板將他叫到辦公室詢問項目進(jìn)展情況?！胺浅：?，”工程師以年輕人的熱情回答道，“這個項目遠(yuǎn)比我想象的 簡單。我差不多已經(jīng)完成了 75的任務(wù)。”老板笑了，說道：“真是太棒了?！比缓笏麌诟滥贻p人繼續(xù)努力工作， 準(zhǔn)備好一周后再匯報一次工作進(jìn)度。一周之后老板將年輕人叫到辦公室，問他說：“現(xiàn)在進(jìn)度如何？” “一切順利，”年輕人回答說，“但是我遇到了一些小麻煩。我會排除這些困難，很快就可以回到正軌上來?！薄澳阌X得在最后期限之前能否完成？”老板問道。 “沒有問題，”工程師答道?！拔也畈欢嘁呀?jīng)完成了 90?！?如果讀者在軟件領(lǐng)域中工作過幾年，你一定可以將這個故事寫完。毫不奇怪，青年工程師在整個項目工期內(nèi)始終停留在 90的進(jìn)度上，(在別人的幫助下)直到交付期限之后一個月才做完。在過去的 30 年間，這樣的故事被不同的軟件開發(fā)者重復(fù)了成千上萬次。 我們不禁要問：“為什么？”7.1 基本概念雖然軟件延期交付的原因很多，但是大多數(shù)都可以追溯到下面列出的一 個或多個根本原因上：一個不現(xiàn)實的截止期限，由軟件工程組以外的人所設(shè)立并強加給軟件工程組內(nèi)的管理者和項目開發(fā)者。客戶需求發(fā)生變化，而需求的變化沒有能夠反映在項目進(jìn)度的變化上。對工作量和/或完成該工作所需的資源數(shù)量估計不足。在項目開始時，沒有將可以預(yù)測的和/或不可預(yù)測的風(fēng)險考慮在內(nèi)。事先無法預(yù)計的技術(shù)困難。事先無法預(yù)計的人力困難。由于項目組成員之間的交流不暢而導(dǎo)致的延期。項目管理者未能發(fā)現(xiàn)進(jìn)度拖后，也未能采取行動解決這一問題。 在軟件行業(yè)中，人們對過于樂觀的(即“不現(xiàn)實的”)項目完成期限已經(jīng)司空見慣。有時候設(shè)定截止時間的人認(rèn)為這樣的截止期限是合理的，但是常 識告訴我們，合理與否還必須由完成工作的人來判斷。 這個故事是我的自傳。7.1.1 關(guān)于“延遲”的評注拿破侖曾經(jīng)說過：“任何同意執(zhí)行一個他本人都認(rèn)為有缺點的計劃的指 揮官都應(yīng)該受到指責(zé)；他必須提出自己的反對理由，堅持修改這一計劃，最 終甚至提出辭職而不是使自己的軍隊遭受慘敗?！边@句話擲地有聲，值得軟 件項目管理者們深思。在第 5 和第 6 章中討論的估算和風(fēng)險分析活動，以及本章中涉及的進(jìn)度 安排技術(shù)，通常都需要在一個定義好的截止期限的約束之下實現(xiàn)。如果最樂 觀的估算都表明截止期限是不現(xiàn)實的，一個勝任的項目管理者就應(yīng)該“保護(hù) 其隊伍免受不適當(dāng)?shù)倪M(jìn)度安排的壓力并將這種壓力反映給施加壓力的一方”PAG85。 不妨舉例說明，假定一個軟件開發(fā)小組的任務(wù)是構(gòu)造一個醫(yī)療診斷儀器的實時控制器，該控制器需要在 9 個月之內(nèi)推向市場。在進(jìn)行了仔細(xì)的估算 和風(fēng)險分析之后，軟件項目管理者得到的結(jié)論是在現(xiàn)有人員條件下，需要 14 個月的時間才能完成這一軟件。這位項目管理者下一步該怎么辦？闖進(jìn)客戶的辦公室(這里的客戶非常可能是市場或銷售人員)并要求修改 交付日期似乎不太現(xiàn)實。外部市場壓力決定了交付日期，屆時必須發(fā)布產(chǎn)品。 而(從事業(yè)前途的角度出發(fā))拒絕這一項目同樣是魯莽的。那么應(yīng)該怎么辦 呢？在這種情況下，推薦以下的處理步驟：1.使用從以前的項目中得到的數(shù)據(jù)，進(jìn)行詳細(xì)的估算。確定項目的估算 工作量和持續(xù)時間。2.使用增量過程模型(參見第 2 章)，制定一個軟件開發(fā)策略，以能夠在規(guī)定的交付日期提供關(guān)鍵功能，而將其他功能的實現(xiàn)推到以后。將這一計劃 做成文檔。3.與客戶會談并(用詳細(xì)估算結(jié)果)來解釋為什么規(guī)定的交付日期是不現(xiàn)實的，一定要指出所有這些估算都是基于以往的項目實踐，而且一定要指出 為了在目前規(guī)定的交付期限完成項目，與以往相比在工作效率上必須提高的 百分比。做如下解釋將是恰如其分的：“我認(rèn)為在 XYZ 控制器軟件的交付日期方面存在一個問題，我已經(jīng)將一份以往項目中生產(chǎn)率的簡化明細(xì)分類表和以多種不同方式進(jìn)行的項目估算提 交給各位，你會注意到我已經(jīng)假設(shè)與以往的生產(chǎn)率相比有 20的提高，但是 我們?nèi)匀恢荒艿玫?14 個月而不是 9 個月的交付時間?！?.將增量開發(fā)策略作為可選計劃提交給客戶。 “我們有幾個選擇，而我希望各位能夠在這些選擇的基礎(chǔ)上做出決策。首先，我們可以增加預(yù)算，并引入額外的資源，以便使我們能夠在 9 個月時 間內(nèi)完成這一工作。但是應(yīng)該知道由于時間限制過于苛刻，這樣做將會增加 質(zhì)量差的風(fēng)險。第二個方案是，去掉一部分需求中所列出的軟件功能和特 性。由此得到功能稍弱的產(chǎn)品的最初版本，但是我們可以對外宣布全部功能， 如果提高的百分比為 10到 25，則實際上是有可能如期完成這一項目的。但更有可能的是，所需的隊伍效率的提高百分比要高于 50。這是不切實際的期望。 你還可以補充說，增加更多的人手不會成比例的縮短完成項目所需的時間。并在總共 14 個月的時間內(nèi)發(fā)布這些功能。第三種選擇是不顧現(xiàn)實條件的約 束，而希望項目能夠在 9 個月時間內(nèi)完成。結(jié)果是我們竭盡全力，但是卻無 法向用戶提供任何功能。我想你們會同意，第三種選擇是不可接受的。過去 的歷史和我們最樂觀的估算都表明這是不現(xiàn)實的，是在選擇一場災(zāi)難。”盡管這樣做會有些抱怨，但如果你給出了基于準(zhǔn)確的歷史數(shù)據(jù)的可靠估 算，那么最終的談判結(jié)果將可能是選擇 1 或者選擇 2。不現(xiàn)實的交付期限就 不存在了。7.1.2 基本原則曾經(jīng)有人請教著名的神秘的人月(The Mythical ManMonth，見文 獻(xiàn)BRO95)一書的作者 Fred Brooks，“軟件項目的進(jìn)度是如何延遲的？” 他的回答即簡單又深刻：“一天一次?！奔夹g(shù)性項目(不論它是涉及到水力發(fā)電廠建設(shè)，還是開發(fā)一個操作系統(tǒng)) 的現(xiàn)實情況是，在實現(xiàn)一個大目標(biāo)之前必須完成數(shù)以百計的小任務(wù)。這些任 務(wù)中有些是處于主流之外，其實現(xiàn)不會影響到整個項目的完成時間；其他任 務(wù)則位于“關(guān)鍵路徑”之上，如果這些“關(guān)鍵”任務(wù)的進(jìn)度拖后，則整個項 目的完成日期就會受到威脅。項目管理者的目標(biāo)是定義所有項目任務(wù)，識別關(guān)鍵任務(wù)，然后跟蹤關(guān)鍵任務(wù)的進(jìn)展以保證“一天一次”的發(fā)現(xiàn)進(jìn)度拖延情況。為了做到這一點，管 理者必須建立一個具有一定詳細(xì)程度的進(jìn)度表，使得項目管理者能夠監(jiān)督進(jìn) 度，并控制整個項目。軟件項目進(jìn)度安排是一種活動，它通過將工作量分配給特定的軟件工程任務(wù)，而將所估算的工作量分布于計劃好的項目持續(xù)時間內(nèi)。但是，進(jìn)度是 隨著時間的改變而不斷演化的，注意到這一點至關(guān)重要。在項目計劃的早期， 首先建立一個宏觀的進(jìn)度安排表。該進(jìn)度表標(biāo)識所有主要的軟件工程活動和 這些活動影響到的產(chǎn)品功能。隨著項目的進(jìn)展，宏觀進(jìn)度表中的每個條目都 被精化成一個“詳細(xì)進(jìn)度表”。于是(完成一個活動所必須實現(xiàn)的)特定軟件 任務(wù)被標(biāo)識出來，并進(jìn)行進(jìn)度安排?？梢詮膬蓚€不同的視角考察軟件開發(fā)項目的進(jìn)度安排。第一個視角，基于計算機的系統(tǒng)的最終發(fā)布日期已經(jīng)確定(而且不能更改)。軟件開發(fā)組織在 這一約束下將工作量分布在預(yù)先確定的時間框架內(nèi)。第二個視角，假定大致 的時間界限已經(jīng)討論過，但是最終發(fā)布日期是由軟件開發(fā)組設(shè)定的，工作量 以一種能夠最好地利用資源的方式加以分布，且在對軟件進(jìn)行仔細(xì)分析之后 才定義最終發(fā)布日期。但不幸的是，第一種情況發(fā)生的頻率遠(yuǎn)遠(yuǎn)高于第二種 情況。同軟件工程的所有其他領(lǐng)域一樣，有一些基本原則能夠指導(dǎo)軟件項目的 進(jìn)度安排：劃分：項目必須被劃分成若干可以管理的活動和任務(wù)。為了實現(xiàn)項目的 劃分，對產(chǎn)品和過程都需要進(jìn)行分解(參見第 3 章)。相互依賴性：各個被劃分的活動或任務(wù)之間的相互關(guān)系必須是確定的。 有些任務(wù)必須順序發(fā)生；而其他的則可以并發(fā)進(jìn)行。有些活動只有在其他活 在本章中后面將詳細(xì)討論“關(guān)鍵路徑”。動產(chǎn)生的工作產(chǎn)品完成時才能夠開始，而其他的則可以獨立進(jìn)行。時間分配：必須為每個被調(diào)度的任務(wù)分配一定數(shù)量的工作單位(例如， 若干人天的工作量)。此外，必須為每個任務(wù)指定開始和結(jié)束日期，這些日期 是與工作完成的方式相互依賴的(全職還是兼職)是工作方式的函數(shù)。工作量確認(rèn)：每個項目都有預(yù)定數(shù)量的人員參與。在進(jìn)行時間分配時， 項目管理者必須確保在任意時段中分配給任務(wù)的人員數(shù)量不會超過項目組中 的人員數(shù)量。例如，一個項目分配了 3 名員工參加(即，每天可分配的工作量為 3 人天)。在某一天中，需要完成 7 項并發(fā)的任務(wù)，每個任務(wù)需要 0.50 人天的工作量，在這種情況下，所分配的工作量就大于可用于分配的工作量。 定義責(zé)任：每個被調(diào)度的任務(wù)都應(yīng)該指定某個特定的小組成員來負(fù)責(zé)。 定義結(jié)果：每個被調(diào)度的任務(wù)都應(yīng)該有一個定義好的結(jié)果。對于軟件項 目而言，結(jié)果通常是一個工作產(chǎn)品(例如一個模塊的設(shè)計)或某個工作產(chǎn)品的一部分。通常將多個工作產(chǎn)品組合成“可交付產(chǎn)品”。定義里程碑：每個任務(wù)或任務(wù)組都應(yīng)該與一個項目里程碑相關(guān)聯(lián)。當(dāng)一 個或多個工作產(chǎn)品經(jīng)過質(zhì)量復(fù)審(參見第 8 章)并且得到認(rèn)可時，標(biāo)志著一個 里程碑的完成。隨著項目進(jìn)度的發(fā)展，上述每一條原則都會被用到。7.2 人員與工作量之間的關(guān)系在一個小型軟件開發(fā)項目中，只需一個人就可以完成需求分析、設(shè)計、 編碼和測試。隨著項目規(guī)模的增長，必然涉及到更多的人員參與(我們幾乎不 可能負(fù)擔(dān)讓一個人工作十年來完成 10 人年工作量的奢侈！)。許多負(fù)責(zé)軟件開發(fā)工作的管理者仍然堅信一個普遍存在的荒誕想法(參見第 1 章)：“即使進(jìn)度拖后，我們也總可以增加更多的程序員，并在后期跟 上進(jìn)度”。不幸的是，在項目后期增加人手通常產(chǎn)生一種破壞性影響，其結(jié) 果是使進(jìn)度進(jìn)一步拖延。后來增加的人員必須學(xué)習(xí)這一系統(tǒng)，而培訓(xùn)他們的 人員正是過去一直在工作著的那些人，當(dāng)他們進(jìn)行教學(xué)時，就不能完成任何 工作，而項目也進(jìn)一步被拖延。除去學(xué)習(xí)系統(tǒng)所需的時間之外，新加入人員將會增加人員之間通信的路徑數(shù)量和整個項目中通信的復(fù)雜度。雖然通信交流對于一個成功的軟件開發(fā) 項目而言絕對是必不可少的，但是每增加一條新的通信路徑就會增加額外的 工作量，從而需要更多的時間。7.2.1 一個例子讓我們來考慮一個有 4 名軟件工程師的項目，在單獨完成項目時，每個 工程師的工作能力都是每年生產(chǎn) 5000 LOC，而當(dāng)這 4 位工程師被編入一個項 目組時，有 6 條可能的通信路徑。每條路徑都將花費原本可以用于軟件開發(fā) 的工作時間。由于增加了通信成本，我們將假定每增加一條通信路徑將會使 項目組的生產(chǎn)率(以 LOC 計算)降低 250 LOC/年。因此項目組的生產(chǎn)率為 20000 實際上由于與工作無關(guān)的會議、病假、休假和各種其他原因，可供分配的工作量要少于 3 人天。但是在本書中，我們將假定員工時間是 100可用的。(2506)18500LOC/年，比期望數(shù)字低了 7.5。 上述項目組承擔(dān)的為期一年的項目現(xiàn)在只剩下兩個月時間，但是已經(jīng)落后于進(jìn)度，這時又加入了 2 名工程師。于是通信路徑激增為 14，在交付之前 剩下的兩個月時間里，新增加成員的生產(chǎn)能力為 84021680 LOC。而目前 的項目組生產(chǎn)率為 200001680(25014)18180LOC/年。盡管上述例子僅僅是對現(xiàn)實情況的粗略簡化，但是它足以揭示另一個關(guān) 鍵性的問題：參加軟件項目的工作人員數(shù)量與整體生產(chǎn)率之間的關(guān)系不是線 性的。那么基于上述的人員-工作關(guān)系，是不是說項目組會降低生產(chǎn)效率呢？如 果通信可以提高軟件質(zhì)量的話，答案斷然是“不”。實際上，由軟件工程小 組進(jìn)行的正式技術(shù)復(fù)審(參見第 8 章)將得到更好的分析和設(shè)計，更重要的 是，這樣可以降低直到測試階段才能發(fā)現(xiàn)的錯誤數(shù)量(從而減小測試的工作 量)。因此，如果以項目完成時間和客戶滿意程度來衡量，生產(chǎn)率和質(zhì)量都將 確實提高。7.2.2 一個經(jīng)驗關(guān)系請回憶一下在第 5 章介紹的“軟件方程式”PUT92，我們可以看到在 完成項目的時間與投入項目中的人員的工作量之間存在著高度非線性關(guān)系。 交付的代碼(源代碼語句)行數(shù) L 與工作量和開發(fā)時間之間的關(guān)系可以用下面 的公式表示：LP (E/B)1/3t4/3其中 E 是以人月為單位的開發(fā)工作量；P 是一個生產(chǎn)率參數(shù)，它反映了 導(dǎo)致高質(zhì)量軟件工程工作的各種因素的綜合效果(P 通常取值在 2，000 到 28，000 之間)；B 是特殊技術(shù)因子，在 0.16 到 0.39 之間取值，是所生產(chǎn)軟件的規(guī)模的函數(shù)；t 是以月為單位的項目持續(xù)時間。 將上述軟件方程式重排，可以得到關(guān)于開發(fā)工作量 E 的計算公式：E L3/(P3t4) (7.1)其中 E 是在軟件開發(fā)和維護(hù)的整個生命周期內(nèi)所需的工作量(以人年計 算)，t 是以年計算的開發(fā)時間。通過引入平均勞動力價格因素($/人年)，開 發(fā)工作量的計算公式還能夠與開發(fā)成本相關(guān)聯(lián)。這一方程式引出了一些有趣的結(jié)果?？紤]一個復(fù)雜的實時軟件項目，估計需要 33，000 LOC，12 個人年的工作量。如果為項目組分配 8 個人，項目 大約可以用1.3年時間完成。但是如果將交付時間延長到1.75年，則公式(7.1) 中的模型所具有的高度非線性特性將導(dǎo)致如下結(jié)果：EL3/(P3t4)3.8 人年這意味著通過將截止時間推遲 6 個月，我們可以將項目組人數(shù)從 8 降低到 4 人！這一結(jié)果的有效性有待考證，但是其含意卻十分清楚：通過在略為 延長的時間內(nèi)使用較少的人員，可以實現(xiàn)同樣的目標(biāo)。7.2.3 工作量分布 也可以做出以下辯駁：如果通信是高效的，就可以提高所進(jìn)行的工作的質(zhì)量，從而降低返工工作量，并提高每個項目組成員的生產(chǎn)率。辯駁成立！在第五章中討論的每種軟件項目估算技術(shù)最終都?xì)w結(jié)為對完成軟件開發(fā)所需人月(或者人年)的估算。一種推薦的在定義和開發(fā)階段之間的工作量分 布通常被稱為“40-20-40 規(guī)則”。40或者更多的工作量分配給前端的分 析和設(shè)計任務(wù)。類似比例的工作量用于后端測試。你可以推斷出編碼工作(大約 20的工作量)沒有被著重強調(diào)。 這種工作量分布只應(yīng)被當(dāng)作指導(dǎo)原則。各個項目的特點決定了其工作量分布。用于項目計劃的工作量很少超過 2到 3，除非提交給組織的項目計 劃費用極大，而且具有高風(fēng)險。需求分析大約占用 10到 25的工作量，用 于分析或原型開發(fā)的工作量應(yīng)該與項目規(guī)模和復(fù)雜度成正比的增長。通常有20到 25的工作量用于軟件設(shè)計，用于設(shè)計復(fù)審和隨之而來的迭代開發(fā)也 必須列入考慮之中。因為在軟件設(shè)計時投入了相當(dāng)?shù)墓ぷ髁?，隨后的編碼工作就變得相對簡 單。15到 20的工作量就可以完成這一工作。測試和隨之而來的調(diào)試工作 將占用 30到 40的軟件開發(fā)工作量。軟件的重要性決定了所需測試工作的 份量，如果軟件系統(tǒng)是人命相關(guān)的(即，軟件錯誤可能使人喪命)，就應(yīng)該考 慮分配更高的測試工作量比例。7.3 為軟件項目定義任務(wù)集合在第二章中，我們描述了多種不同的過程模型。這些模型為軟件開發(fā)提 供了不同的范型。如果不考慮一個軟件項目組選擇的是線性順序范型、迭代 開發(fā)模型、演化開發(fā)模型、并發(fā)開發(fā)模型還是組合使用這些模型，則過程模 型都是由一個任務(wù)集合組成的，它使得軟件項目組能夠定義、開發(fā)和最終維 護(hù)計算機軟件。沒有一個普遍適用于所有軟件項目的任務(wù)集合。適用于大型復(fù)雜系統(tǒng)的項目任務(wù)集合可能對于小型且相對簡單的項目而言就過于復(fù)雜。因此一個有 效的軟件過程應(yīng)該定義一組“任務(wù)集合”，各個任務(wù)集合的設(shè)計可以滿足不 同類型項目的要求。一個任務(wù)集合包括一組軟件工程工作任務(wù)、里程碑和交付產(chǎn)品，為了完成某一特定項目就必須完成這些任務(wù)。一個項目所選擇的任務(wù)集合必須為最 終獲得高質(zhì)量的軟件產(chǎn)品提供充分的規(guī)程要求，但同時又不能讓項目組負(fù)擔(dān) 不必要的工作。任務(wù)集合的設(shè)計應(yīng)該可以應(yīng)用于不同類型的項目和不同的嚴(yán)格度。盡管 很難建立一個全面詳盡的分類結(jié)構(gòu)，但是大多數(shù)軟件組織接手的項目一般屬 于下述類型：概念開發(fā)項目：項目的目的是為了探索某些新的商業(yè)概念或者某種新技 術(shù)的應(yīng)用。新應(yīng)用開發(fā)項目：根據(jù)特定的客戶需求而承擔(dān)的項目。應(yīng)用增強項目：對現(xiàn)有軟件進(jìn)行最終用戶可察覺的功能、性能或界面的 修改。 現(xiàn)在對于大型軟件開發(fā)項目而言，通常多于 40的全部項目工作量用于分析和設(shè)計任務(wù)。因此從嚴(yán)格意義上講，“40-20-40”，的名稱已經(jīng)不再適用。應(yīng)用維護(hù)項目：以一種最終用戶不會立即察覺到的方式對現(xiàn)有軟件進(jìn)行 糾錯、適應(yīng)或者擴展。再工程項目：為了全部或部分重建一個現(xiàn)有(遺留)系統(tǒng)而承擔(dān)的項目。 即使在單一的項目類型中，也會有許多因素影響任務(wù)集合的選擇。當(dāng)將 這些因素綜合考慮時，就會構(gòu)成一個稱為“嚴(yán)格度”的指示量，它將應(yīng)用于所采用的軟件過程中。7.3.1 嚴(yán)格度即使只考慮某種特定類型的項目，所采用的軟件過程的嚴(yán)格度也會相當(dāng) 不同。嚴(yán)格度是眾多項目特性的函數(shù)。例如，小型的非主要商業(yè)性質(zhì)的項目 的嚴(yán)格度一般可以小于大型復(fù)雜的主要業(yè)務(wù)應(yīng)用程序。但是應(yīng)該注意到，所 有項目都必須以一種能夠按時得到高質(zhì)量的發(fā)布產(chǎn)品的方式來實施?？梢远?義如下的 4 種不同程度的嚴(yán)格度：隨意的：使用了所有過程框架活動(參見第 2 章)，但只需要一個最小的 任務(wù)集合。一般情況下，將保護(hù)性任務(wù)最小化，并將文檔需求降低。所有基 本的軟件工程原則仍然都是適用的。結(jié)構(gòu)化的：在項目中將使用過程框架。框架活動和適用于這種項目類型的相關(guān)任務(wù)，以及為保證高質(zhì)量所需的保護(hù)性活動將得到應(yīng)用。SQA、SCM、 文檔和度量任務(wù)將以一種經(jīng)過優(yōu)化的有效方式進(jìn)行。嚴(yán)格的：整個過程將按照一種能夠確保高質(zhì)量的嚴(yán)格規(guī)程要求應(yīng)用于項目之中。所有保護(hù)性活動都將被采用，且要建立健壯的文檔。快速反應(yīng)的：該項目將使用過程框架，但是由于某種緊急情況的出現(xiàn)， 只應(yīng)用了那些為保持軟件系統(tǒng)質(zhì)量所必須完成的任務(wù)。在應(yīng)用程序/產(chǎn)品交付 給客戶之后再完成“回填工作”(即開發(fā)一套完整的文檔，進(jìn)行額外的復(fù)審)。 項目管理者必須開發(fā)一種系統(tǒng)化的方法用以選擇適用于特定項目的嚴(yán)格 度。為了做到這一點，需要定義項目適應(yīng)性準(zhǔn)則并計算“任務(wù)集合選擇因子”的值。7.3.2 定義適應(yīng)性準(zhǔn)則適應(yīng)性準(zhǔn)則用于確定一個項目中使用軟件過程的嚴(yán)格度。我們?yōu)檐浖?目定義了以下 11 條適應(yīng)性準(zhǔn)則：項目的規(guī)模。潛在的用戶數(shù)量。任務(wù)的關(guān)鍵性。應(yīng)用程序的壽命。需求的穩(wěn)定性。客戶與開發(fā)者之間通信的容易程度。 緊急情況應(yīng)該非常罕見（在軟件工程的討論范圍內(nèi)，發(fā)生這種情況的工作不應(yīng)該超過 10到 20）。緊急情況與項目工期緊張是不同的。 出現(xiàn)在本節(jié)中的適應(yīng)性準(zhǔn)則與后面一節(jié)出現(xiàn)的 TSS 計算都是根據(jù)自適應(yīng)的過程模型改編的。其復(fù)制 得到了 R.S.PressmanAssociates ，Inc.的許可。欲知有關(guān)詳情，請發(fā)電子郵件給 .應(yīng)用技術(shù)的成熟度。性能約束。嵌入式/非嵌入式特性。項目人員配置。再工程因素。每一條適應(yīng)性準(zhǔn)則都被賦予一定的等級分?jǐn)?shù)，取值在 1 到 5 之間。其中1 代表需要使用較小子集的過程任務(wù)，且整體的方法學(xué)及文檔需求為最小的 項目；而 5 則代表需要采用全部過程任務(wù)，且整體的方法學(xué)及文檔需求相當(dāng) 高的項目。7.3.3 計算任務(wù)集合選擇因子的值為一個項目選擇適當(dāng)?shù)娜蝿?wù)集合，應(yīng)該按照下述幾個步驟進(jìn)行：1.復(fù)審 7.3.2 節(jié)中給出的每個適應(yīng)性準(zhǔn)則，根據(jù)項目特點為它們賦予適 當(dāng)?shù)牡燃壏謹(jǐn)?shù)(從 1 到 5)。這些等級分?jǐn)?shù)應(yīng)該輸入到表 71 中。2.復(fù)審賦予每個適應(yīng)性準(zhǔn)則的加權(quán)因子。加權(quán)因子的取值在 0.8 到 1.2 之間，表明了對在當(dāng)前環(huán)境中開發(fā)的軟件類型而言特定適應(yīng)性準(zhǔn)則的相對重 要性。如果需要，則可以進(jìn)行修改，以反映當(dāng)前的環(huán)境。3.將表 7.1 中的等級分?jǐn)?shù)與加權(quán)因子相乘，再乘以表示當(dāng)前項目類型的條目點乘數(shù)。條目點乘數(shù)在 0 到 1 之間取值，表示該適應(yīng)性準(zhǔn)則與項目類型 之間的相關(guān)程度。對應(yīng)于各個適應(yīng)性準(zhǔn)則的相乘結(jié)果：等級分?jǐn)?shù)加權(quán)因子條目點乘數(shù)分別放入表 71 的“乘積”欄中。4.計算“乘積”欄中所有條目的平均值，并將結(jié)果放入標(biāo)記著“任務(wù)集 合選擇因子(TSS)”的空格中。這個值將用于幫助你選擇最適用于當(dāng)前項目的 任務(wù)集合。表 7 1 計算任務(wù)集合選擇因子適應(yīng)性準(zhǔn)則 等級分?jǐn)?shù) 權(quán)重 條目點乘數(shù) 乘積概念新應(yīng)用增強維護(hù)再工程 項目規(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ǐn)?shù)權(quán)重 條目點 乘積 乘數(shù) 概念新應(yī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 項目人員配置 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ù)集合一旦計算好任務(wù)集合選擇因子，就可以使用下述的指南幫助你選擇一個 適用于項目的任務(wù)集合：任務(wù)集合選擇因子取值 嚴(yán)格度TSS1.2 隨意的1.0TSS3.0 結(jié)構(gòu)化的 TSS2.4 嚴(yán)格的兩個推薦任務(wù)集合之間的 TSS 取值的重疊是有意設(shè)定的，這用于說明在進(jìn)行任務(wù)集合的選擇時，定義出精確的邊界是不可能的。在進(jìn)行最后的分析 時，應(yīng)該將任務(wù)集合選擇因子的取值、以往的經(jīng)驗以及常識都作為項目任務(wù) 集合的選擇因素。表 72 顯示了在一個假想的項目中如何計算 TSS 的情況。項目管理者在“等級分?jǐn)?shù)”一欄中選擇等級分值，項目類型是“新應(yīng)用開發(fā)”。因此其條 目點乘數(shù)應(yīng)該從“新應(yīng)用”一欄中選擇。“乘積”一欄中條目的計算使用如 下公式等級分?jǐn)?shù)加權(quán)因子條目點乘數(shù)TSS 的取值(“乘積”一欄中所有條目的平均值)是 2.8。使用上述的準(zhǔn)則， 管理者可以選擇使用結(jié)構(gòu)化的或嚴(yán)格的任務(wù)集合。在考慮了所有項目因素之 后，可以作出最終決策。表 7 2 計算任務(wù)集合選擇子：一個例子條目點乘數(shù) 乘積新應(yīng)用 增強 維護(hù) 再工程項目規(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 項目人員配置 2 1.0 1 2.0 互操作 4 1.1 1 4.4 再工程因素 0 1.2 0 2.8任務(wù)集合選擇因子(TSS) 2.87.4 選擇軟件工程任務(wù)為了制定項目進(jìn)度安排，必須將任務(wù)集合分布在項目時間表上。如 7.3 節(jié)所述，任務(wù)集合將根據(jù)項目類型和嚴(yán)格度的不同而有所不同。7.3 節(jié)中的 每種項目類型都可以使用線性順序、迭代(如，原型模型)或者演化(如，螺旋 模型)等過程模型來實現(xiàn)。在某些情況下，項目類型可以從一種形式平滑的轉(zhuǎn) 換為另一種形式。例如，成功的概念開發(fā)項目通常會演化成為新應(yīng)用開發(fā)項 目，而新應(yīng)用開發(fā)項目結(jié)束之后，可能又開始了一個應(yīng)用增強項目。這種進(jìn) 程是自然且可預(yù)測的，而不論是采用何種過程模型來組織。作為一個例子， 下面我們將考慮概念開發(fā)項目的主要軟件工程任務(wù)。概念開發(fā)項目是在必須探索某些新技術(shù)是否可行時發(fā)起的。這種技術(shù)是否可行尚不可知，但是某個客戶(如營銷部門)相信其潛在利益的存在。概念 開發(fā)項目的完成需要應(yīng)用下面所述的主要任務(wù)：確定概念范圍：確定項目的整體范圍。 初步的概念計劃：確定組織的能力，以承擔(dān)項目范圍所規(guī)定的工作。 技術(shù)風(fēng)險評估：評估與將要作為項目范圍的一部分而被實現(xiàn)的技術(shù)相關(guān)聯(lián)的風(fēng)險。概念證明：闡明新技術(shù)在軟件環(huán)境中的生命力。概念實現(xiàn)：以一種可以由客戶方復(fù)審的方式實現(xiàn)概念的表示，且當(dāng)概念 必須被賣給其他客戶或管理者時能夠用于“推銷”的目的。客戶對概念的反應(yīng)：向客戶索取對新技術(shù)概念的反饋，并以特定的客戶 應(yīng)用作為目標(biāo)?？焖贋g覽上述主要任務(wù)，你應(yīng)該不會有何詫異。實際上概念開發(fā)項目的軟件工程任務(wù)流程(以及其他所有類型的項目)與人們的常識相差無幾。 軟件開發(fā)組必須知道哪些任務(wù)是必須完成的(項目范圍)；項目組(或管理者)必須確定目前是否有人能夠進(jìn)行這一工作(計劃)；考慮與工作相關(guān)聯(lián)的風(fēng) 險(風(fēng)險評估)；以某種方式證明這種技術(shù)(概念的證明)；并且將這種技術(shù)用 原型的方式實現(xiàn)出來，從而使客戶能夠?qū)ζ溥M(jìn)行評價(概念實現(xiàn)和客戶評 價)。最后，如果這一概念是可行的，則必須將其產(chǎn)品版本開發(fā)出來(技術(shù)轉(zhuǎn) 化)。有非常重要的一點需要注意，概念開發(fā)任務(wù)本質(zhì)上是迭代的。這就是說， 一個實際的概念開發(fā)項目也許會通過多個有計劃的增量步驟得以實現(xiàn)，每個 步驟都被設(shè)計成能夠產(chǎn)生一個可供客戶評價的可發(fā)布版本。如果選擇使用線性過程模型，則每一個增量都被定義為如圖 71 所示的 一個重復(fù)序列。在每個序列中，將使用保護(hù)性活動(參見第 2 章中的描述)； 監(jiān)控軟件質(zhì)量，且在每個序列的末尾，將產(chǎn)生一個可交付產(chǎn)品。隨著逐次迭 代的過程，可交付產(chǎn)品應(yīng)該向著在概念開發(fā)階段已經(jīng)定義的最終產(chǎn)品收斂。 如果選擇的是演化開發(fā)模型，則從任務(wù) 1.1 到 1.6 的分布應(yīng)該如圖 72 中所 示?？梢砸灶愃频姆绞蕉x和使用關(guān)于其他項目類型的主要軟件工程任務(wù)。7.5 主要任務(wù)的求精在 7.4 節(jié)中所描述的主要任務(wù)可以被用于定義項目的宏觀進(jìn)度表。例 如，概念開發(fā)項目中描述的任務(wù)可以用于定義該項目的任務(wù)網(wǎng)絡(luò)(參見 7.6 節(jié))。我們在本章前面曾經(jīng)指出，必須將宏觀進(jìn)度表精化來創(chuàng)建一個詳細(xì)的項目進(jìn)度表。精化工作始于將每個主要任務(wù)分解為一組子任務(wù)(以及相關(guān)的工作 產(chǎn)品和里程碑)。作為任務(wù)分解的例子，我們考慮在 7.4 節(jié)中討論的“確定概念范圍”任 務(wù)。任務(wù)精化可以使用大綱格式完成，但是在本書中將使用一種過程設(shè)計語 言來闡明“確定概念范圍”這一活動的流程：任務(wù) I.1 確定概念范圍I.1.1 標(biāo)出需求、效益和潛在的客戶；I.1.2 定義所希望的輸出/控制和驅(qū)動應(yīng)用程序的輸入事件； Begin 任務(wù) I.1.2I.1.2.1FTR：復(fù)審需求的書面說明I.1.2.2 導(dǎo)出一個客戶可見的輸出/輸入列表 case of：mechanics mechanics質(zhì)量功能配置 與客戶會談，以劃分主要的概念需求； 會見最終用戶；觀察現(xiàn)有的解決問題的方法和當(dāng)前的問題解決過程； 復(fù)審以往的要求和抱怨； 過程設(shè)計語言與 14 章中討論的程序設(shè)計語言在語法上是類似的。 FTR 表示在此需要進(jìn)行一次正式的技術(shù)復(fù)審（參見第 8 章）mechanics結(jié)構(gòu)化分析 列出主要數(shù)據(jù)對象； 定義對象之間的關(guān)系； 定義對象的屬性； mechanics對象視圖 列出問題類； 確定類層次和類連接； 定義各個類的屬性； endcaseI.1.2.3FTR：與客戶一起復(fù)審輸出/輸入，并在需要時進(jìn)行修改；endtask 任務(wù) I.1.2I.1.3 為每項主要功能定義操作/行為； Begin 任務(wù) I.1.3I.1.3.1 FTR：復(fù)審在任務(wù) I.1.2 中得到的輸出和輸入數(shù)據(jù)對象； I.1.3.2 導(dǎo)出功能/行為模型；case of：mechanics mechanics質(zhì)量功能配置 與客戶會談，以復(fù)審主要的概念需求； 會見最終用戶；觀察現(xiàn)有的解決問題的方法和當(dāng)前的問題解決過程；建立一個功能/行為的層次結(jié)構(gòu)概要； mechanics結(jié)構(gòu)化分析 導(dǎo)出一個系統(tǒng)級別的數(shù)據(jù)流程圖； 精化數(shù)據(jù)流程圖，以便給出更多的細(xì)節(jié)； 為最底層精化圖的功能書寫處理過程說明； mechanics對象視圖 定義與各個類相關(guān)的操作/方法；endcaseI.1.3.3 與客戶一起復(fù)審功能/行為模型，并在需要時進(jìn)行修改；endtask 任務(wù) I.1.3I.1.4 把需要在軟件中得到實現(xiàn)的技術(shù)要素分離出來； I.1.5 研究現(xiàn)有軟件的可用性；I.1.6 定義技術(shù)可行性；I.1.7 對系統(tǒng)規(guī)模進(jìn)行快速估算； I.1.8 創(chuàng)建一個“范圍定義”； endtask 任務(wù) I.1任務(wù)和用過程設(shè)計語言進(jìn)行精化時標(biāo)注的子任務(wù)共同構(gòu)成了制定“確定 概念范圍”這一活動的詳細(xì)進(jìn)度表的基礎(chǔ)。7.6 定義任務(wù)網(wǎng)絡(luò)任務(wù)和子任務(wù)之間基于其間順序而存在相互依賴關(guān)系。而且當(dāng)有多個人 參與軟件工程項目時，多個開發(fā)活動和任務(wù)并行進(jìn)行的可能性很大。在這種情況下，必須協(xié)調(diào)多個并發(fā)任務(wù)，以保證它們能夠在后繼任務(wù)需要其工作成 果之前完成?！叭蝿?wù)網(wǎng)絡(luò)”是一個項目的任務(wù)流程的圖形表示。該網(wǎng)絡(luò)有時被用作在 自動項目進(jìn)度安排工具中輸入任務(wù)序列和依賴關(guān)系的機制。任務(wù)網(wǎng)絡(luò)的最簡 單形式(當(dāng)創(chuàng)建宏觀進(jìn)度表時使用)刻劃了軟件工程主要任務(wù)。圖 73 顯示了 一個概念開發(fā)項目的任務(wù)網(wǎng)絡(luò)示意圖。軟件工程活動的并發(fā)本質(zhì)導(dǎo)致了若干重要的調(diào)度需求。由于并行任務(wù)是 異步發(fā)生的，計劃者必須確定任務(wù)之間的依賴關(guān)系，以保證項目朝著最終完 成的方向持續(xù)發(fā)展。另外，項目管理者應(yīng)該注意那些位于關(guān)鍵路徑之上的任 務(wù)，也就是說，為了保證整個項目的如期完成，就必須保證這些任務(wù)能夠如 期完成。在本章的后面部分，我們將詳細(xì)討論這些問題。圖 73 中所示的任務(wù)網(wǎng)絡(luò)是宏觀的，注意到這一點非常重要。在一個詳 細(xì)的任務(wù)網(wǎng)絡(luò)(詳細(xì)進(jìn)度表的前驅(qū))中，應(yīng)該對圖 73 所示的各個活動加以擴 展。例如，應(yīng)該擴展任務(wù) I.1，以顯示 7.5 節(jié)所述的精化中的所有詳細(xì)任務(wù)。7.7 進(jìn)度安排軟件項目的進(jìn)度安排與任何其他多任務(wù)工程工作的進(jìn)度安排幾乎沒有太 多的差別。因此，通用的項目進(jìn)度安排工具和技術(shù)不必做太多修改就可以應(yīng) 用于軟件項目。“程序評估和復(fù)審技術(shù)(PERT)”和“關(guān)鍵路徑方法(CPM)”MOD83就是兩種可以用于軟件開發(fā)的項目進(jìn)度安排方法。兩種技術(shù)都是由較早的項目 計劃活動中已經(jīng)產(chǎn)生的信息來驅(qū)動的，這些信息包括：工作量的估算。產(chǎn)品功能的分解。適當(dāng)?shù)倪^程模型的選擇。項目類型和任務(wù)集合的選擇。 任務(wù)之間的依賴關(guān)系可以使用任務(wù)網(wǎng)絡(luò)來定義。任務(wù)，有時也稱作項目的“工作細(xì)分結(jié)構(gòu)”(WBS)，其定義可以是針對整個產(chǎn)品，也可以是針對單個功能進(jìn)行的。PERT 和 CPM 兩種方法都提供項目工作定量劃分的工具，能支持軟件計劃 者(1)確定關(guān)鍵路徑一決定項目持續(xù)時間的任務(wù)鏈；(2)通過使用統(tǒng)計模型為 單個任務(wù)建立最有可能的時間估算；(3)計算為特定任務(wù)定義其時間“窗口” 的邊界時間。邊界時間的計算對軟件項目進(jìn)度的安排十分有用。比如說，某個功能的 設(shè)計的推遲可能進(jìn)一步導(dǎo)致其他功能開發(fā)的拖后。RiggsRIG81描述了一 些能夠從 PERT 或 CPM 網(wǎng)絡(luò)中得到的重?5 謀囈縭奔洌海*1)某個任務(wù)的最早 開始時間是當(dāng)其所有前驅(qū)任務(wù)在最短的可能時間中完成時；(2)某個任務(wù)的最 晚開始時間是在不延遲項目最小完成時間的前提下，最晚啟動該任務(wù)的時 間；(3)最早結(jié)束時間最早開始時間加上任務(wù)持續(xù)時間；(4)最晚結(jié)束時 間最晚開始時間加上任務(wù)持續(xù)時間；以及(5)總浮動量在保證進(jìn)度的 前提下，調(diào)度任務(wù)時所允許的富余時間或回旋時間的總和。通過邊界時間的 計算可以確定關(guān)鍵路徑，并為管理者提供當(dāng)任務(wù)完成時評估進(jìn)展的量化方法。PERT 和 CPM 方法都已經(jīng)在多種自動工具中得到實現(xiàn)，這些工具在幾乎所 有個人電腦上都可以找到THE93。這類工具易于使用，且使得每一位軟件 項目管理者都可以使用前述的進(jìn)度安排方法。7.7.1 時間表在創(chuàng)建軟件項目進(jìn)度表時，計劃者將從一組任務(wù)(工作細(xì)分結(jié)構(gòu))入手。 如果使用自動工具，就可以用任務(wù)網(wǎng)絡(luò)或者任務(wù)大綱的方式輸入工作細(xì)分結(jié) 構(gòu)。然后為每一項任務(wù)輸入工作量、持續(xù)時間和開始時間。此外，每一項任 務(wù)都必須被分配給特定的人員。上述輸入的結(jié)果之一是產(chǎn)生“時間表(Timeline Chart)”，也叫做“甘 特圖(Gantt Chart)”。可以為整個項目建立一個時間表，也可以為各個項目 功能或各個項目參與者分別開發(fā)各自的時間表。表 73 給出了時間表的格式，該圖描述了一個新的字處理軟件產(chǎn)品中 “確定概念范圍”任務(wù)(參見 7.5 節(jié))的軟件項目進(jìn)度安排。所有的項目任務(wù) (對于“確定概念范圍”)都在左邊的欄中列出。水平條表示每個任務(wù)的持續(xù) 時間。當(dāng)日歷中同一時段中存在多個水平條時，就代表任務(wù)之間存在并發(fā)。 圖中的菱形表示里程碑。一旦輸入了生成時間表所需的信息，大多數(shù)軟件項目進(jìn)度安排工具都會生成“項目表”一個表格式的列表，列出所有項目任務(wù)、其計劃的及實 際的開始與結(jié)束日期、以及各種相關(guān)信息(參見圖 75)。項目表與時間表一 同使用，使得項目管理者能夠跟蹤項目的進(jìn)展情況。7.7.2 跟蹤進(jìn)度項目進(jìn)度為軟件項目管理者提供了一張進(jìn)度路線圖。如果被正確制定， 項目進(jìn)度表中應(yīng)該定義在項目進(jìn)展過程中必須被跟蹤和控制的任務(wù)及里程碑。項目跟蹤可 以通過以下方式得以實現(xiàn)：定期舉行項目狀態(tài)會議，由項目組中的各個成員分別報告進(jìn)度和問題。評估所有在軟件工程過程中所進(jìn)行的復(fù)審的結(jié)果。確定正式的項目里程碑(表 7-3 中的菱形)是否在預(yù)定日期內(nèi)完成。比較項目表(表 7-4)中列出的各項任務(wù)的實際開始日期與計劃開始日 期。與開發(fā)者進(jìn)行非正式會談，獲取他們對項目進(jìn)展及可能出現(xiàn)的問題的 客觀評估。實際上，有經(jīng)驗的項目管理者都會使用所有這些跟蹤技術(shù)。 軟件項目管理者使用“控制”的方法來管理項目資源、處理問題和指導(dǎo)項目參與者。如果一切順利(即，項目在預(yù)算范圍內(nèi)按進(jìn)度進(jìn)行，復(fù)審結(jié)果表 明的確取得了實際進(jìn)展，達(dá)到了各個里程碑)，則幾乎不必施加控制。但是如 果出現(xiàn)問題，項目管理者就必須施加控制，以便盡快解決問題。當(dāng)問題得到診斷之后，可能需要增加額外的資源以解決問題：如可能需要雇傭新員工， 或者需要重新定義項目進(jìn)度。表 7 4 一個項目表的例子工作任務(wù) 計劃開始 實際開始 計劃結(jié)束 實際結(jié)束 人員分配 工作量分配 附注I.1.1 標(biāo)出需求和效益 會見客戶 wk1,d1 wk1,d1 wk1,d2 wk1,d2 BLS 2p-d 標(biāo)出需求和項目約束 wk1,d2 wk1,d2 wk1,d2 wk1,d2 JPP 1p-d 建立產(chǎn)品說明 wk1,d3 wk1,d3 wk1,d3 wk1,d3 BLS/JPP 1p-d里程碑：定義產(chǎn)品說明wk1,d3 wk1,d3 wk1,d3 wk1,d3I.1.2 定義希望的輸出/控制 輸入(OCI) 確定鍵盤功能 wk1,d4 wk1,d4 wk2,d2 BLS 1.5p-d 確定語音輸入功能 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 定義功能 行為? ? ? ? ? ? ?在面對交付期限的巨大壓力時，有經(jīng)驗的項目管理者有時會使用一種稱為“時間盒”ZAH95的項目進(jìn)度安排和控制技術(shù)。時間盒策略認(rèn)識到完整 的產(chǎn)品可能難以在預(yù)定時間內(nèi)交付，因此，應(yīng)該選擇增量軟件開發(fā)范型，并 為每個增量的交付定義各自的進(jìn)度。接著，對與每個增量相關(guān)的任務(wù)實行時間盒技術(shù)。這意味著通過對增量的交付日期倒退著推算，來調(diào)整每項任務(wù)的進(jìn)度。在每項任務(wù)前后加上了一 個“盒子”，當(dāng)任務(wù)觸及其時間盒邊界時(正負(fù) 10的范圍內(nèi))，則該項任務(wù) 停止，下一任務(wù)開始。對于時間盒方法的第一個反應(yīng)通常是反面的：“如果工作尚未完成，我 們該如何繼續(xù)？”答案就隱藏在工作的完成方式中。在遇到時間盒的邊界時， 很可能任務(wù)的 90已經(jīng)完成。余下的 10工作盡管重要，但是可以(1)被推 遲到下一個增量中，或者(2)在以后需要時再完成。項目朝著交付日期逐步進(jìn) 展，而不是被某個任務(wù)“卡住”。 千萬注意：進(jìn)度延遲是某種潛在問題的癥狀。項目管理者的角色是論斷出潛在的問題，并采取行動改正之。 愛挖苦人的人也許會想起一句諺語：“完成系統(tǒng)的前 90需要 90%的時間，完成剩下的 10%也要用 90%的時間”。7.8 項目計劃軟件工程過程中的每一步驟都應(yīng)該產(chǎn)生可以被復(fù)審并能夠作為后續(xù)步驟 的基礎(chǔ)的工作產(chǎn)品。軟件項目計劃在計劃任務(wù)結(jié)束時產(chǎn)生，它給出了基線的 成本及進(jìn)度信息，這些信息將會在整個軟件工程過程中被使用。軟件項目計劃是一種面向廣大讀者的相對簡短的文檔。它必須能夠(1) 在軟件管理者、技術(shù)人員和客戶之間傳達(dá)項目范圍和資源信息；(2)定義風(fēng)險 并提出有關(guān)風(fēng)險管理技術(shù)的建議；(3)定義管理復(fù)審的成本和進(jìn)度；(4)為與 項目相關(guān)的所有人員提供軟件開發(fā)的整體方法；(5)概述如何保證質(zhì)量及變化 的管理。表 7-5 給出了一個軟件項目計劃的大綱。針對不同的讀者，所顯示的成本和進(jìn)度可能有所不同。如果計劃只作為 內(nèi)部文檔使用，則應(yīng)該給出各種成本估算技術(shù)所得到的結(jié)果。當(dāng)計劃在組織 以外發(fā)布時，應(yīng)該給出一份經(jīng)過整合的成本細(xì)分表(結(jié)合了所有成本估算技術(shù) 的結(jié)果)。類似的，進(jìn)度信息的詳細(xì)程度也應(yīng)該隨讀者和計劃正式程度的不同 而有所不同。軟件項目計劃不必過于冗長復(fù)雜，其目的是幫助確立軟件開發(fā)工作的有 效性。該計劃集中于“做什么”的一般性說明和特定的“多少資源”與“多 長時間”的說明。軟件工程過程中的后續(xù)步驟將集中來完成項目的定義、開 發(fā)和維護(hù)。.引言 A.計劃的目的 B.項目范圍和目標(biāo)1.范圍說明2.主要功能3.性能問題4.管理及技術(shù)約束 .項目估算表 7 5 軟件項目計劃3.風(fēng)險管理(意外事件計劃) .進(jìn)度 A.項目工作細(xì)分結(jié)構(gòu) B.任務(wù)網(wǎng)絡(luò) C.時間表(