軟件工程71課件

第九講軟件項目計劃與管理成本估計的相關概念、方法和模型效益分析方法項目組織與計劃項目進度計劃與風險管理軟件質(zhì)量相關概念及軟件工程標準所謂管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定目標的過程。軟件項目管理在任何技術(shù)活動開始之前就已經(jīng)開始了，并且貫穿于軟件的整個生命周期。目前，雖然好的管理不一定能確保工程百分之百地成功，但是壞的管理或不適當?shù)墓芾砑夹g(shù)是一定會導致工程失敗——軟件交付使用的日期將大大拖后，實際成本比預期成本高很多，而且最終得到的軟件產(chǎn)品質(zhì)量低劣、很難維護。9.1度量軟件規(guī)模軟件項目管理過程從一組項目計劃活動開始，而第一項計劃活動就是“估算”。由于估算是所有其他項目計劃活動的基礎，而項目計劃為軟件工程指出了通往成功的道路，因此，必須充分重視估算活動。工作量估算和完成期限估算是項目計劃的基礎。為了估算軟件項目的工作量和完成期限，首先需要度量軟件的規(guī)模。為了使得對程序規(guī)模的估計值盡可能接近實際值，可以由多位有經(jīng)驗的軟件工程師分別獨立地作出估計。每個人都估計程序的最小規(guī)模（a）、最大規(guī)模（b）和最可能的規(guī)模（m），分別算出這三類規(guī)模的平均值，和之后，再用下式計算程序規(guī)模的估計值：（9.1）用代碼行技術(shù)度量軟件規(guī)模時，當程序較小時常用的單位是代碼行數(shù)（LOC），當程序較大時常用的單位是千行代碼數(shù)（KLOC）。1.代碼行技術(shù)的優(yōu)點用代碼行技術(shù)度量軟件規(guī)模時，當程序較小時常用的單位是代碼行數(shù)（LOC），當程序較大時常用的單位是千行代碼數(shù)（KLOC）。1.代碼行技術(shù)的優(yōu)點●代碼行是所有軟件開發(fā)項目都有的“產(chǎn)品”，而且很容易計算；●許多現(xiàn)有的軟件估算模型使用LOC或KLOC作為關鍵的輸入數(shù)據(jù)；●已有大量基于代碼行的文獻和數(shù)據(jù)存在。2.代碼行技術(shù)的缺點●源程序僅是軟件配置的一個成分，用它的規(guī)模代表整個軟件的規(guī)模似乎不太合理；●用不同語言實現(xiàn)同一個軟件產(chǎn)品所需要的代碼行數(shù)并不相同；●這種方法不適用于非過程語言。功能點技術(shù)功能點技術(shù)依據(jù)對軟件信息域特性和軟件復雜性的評估結(jié)果，估算軟件規(guī)模。這種方法用功能點（FP）為單位，度量軟件的規(guī)模。1.信息域特性功能點技術(shù)定義了信息域的5個特性，分別是輸入項數(shù)（Inp）、輸出項數(shù)（Out）、查詢數(shù)（Inq）、主文件數(shù)（Maf）和外部接口數(shù)（Inf）。2.估算功能點的步驟用下述三個步驟，可以估算出一個軟件的功能點數(shù)（即軟件規(guī)模）。（1）計算未調(diào)整的功能點數(shù)UFP首先，把產(chǎn)品信息域的每個特性（即Inp、Out、Inq、Maf和Inf）都分類成簡單級、平均級或復雜級。根據(jù)其等級，為每個特性都分配一個功能點數(shù)，例如，一個平均級的輸入項分配4個功能點，一個簡單級的輸入項是3個功能點，而一個復雜級的輸入項分配6個功能點。然后，用下式計算未調(diào)整的功能點數(shù)UFPUFP＝a1×Inp＋a2×Out＋a3×Inq＋a4×Maf＋a5×Inf

其中，ai（1≤i≤5）是信息域特性系數(shù)，其值由相應特性的復雜級別決定，如表9.1所示。表9.1信息域特性系數(shù)值復雜級別特性系數(shù)簡

單平

均復

雜輸入系數(shù)a1346輸出系數(shù)a2457查詢系數(shù)a3346文件系數(shù)a471015接口系數(shù)a55710（2）計算技術(shù)復雜性因子TCF這一步將度量14種技術(shù)因素對軟件規(guī)模的影響程度。這些因素包括高處理率、性能標準（例如，響應時間）、聯(lián)機更新等，在表9.2中列出了全部技術(shù)因素，并用Fi（1≤i≤14）代表這些因素。根據(jù)軟件特點，為每個因素分配一個從0（不存在或?qū)浖?guī)模無影響）到5（有很大影響）的值。然后，用下式計算技術(shù)因素對軟件規(guī)模的綜合影響程度DI：技術(shù)復雜性因子TCF由下式計算：TCF＝0.65+0.01×DI因為DI的值在0～70之間，所以TCF的值在0.65～1.35之間。8F8聯(lián)機更新9F9復雜的計算10F10可重用性11F11安裝方便12F12操作方便13F13可移植性14F14可維護性（3）計算功能點數(shù)FP功能點數(shù)FP由下式計算：FP＝UFP×TCF功能點數(shù)與所用的編程語言無關，因此，功能點技術(shù)比代碼行技術(shù)更合理一些。但是，在判斷信息域特性復雜級別及技術(shù)因素的影響程度時，存在相當大的主觀因素。9.2估算軟件開發(fā)工作量軟件估算模型使用由經(jīng)驗數(shù)據(jù)導出的公式來預測軟件開發(fā)的工作量，工作量是軟件規(guī)模的函數(shù)，工作量的單位通常是人月（pm）。支持大多數(shù)估算模型的經(jīng)驗數(shù)據(jù)，都是從有限個項目的樣本集采集來的，因此，沒有一個估算模型能夠適用于所有類型的軟件和開發(fā)環(huán)境。下面介紹三類典型的估算模型。1.面向KLOC的估算模型（1）Walston-Felix模型E＝5.2×(KLOC)0.91（2）Bailey-Basili模型E＝5.5＋0.73×(KLOC)1.16（3）Boehm簡單模型E＝3.2×(KLOC)1.05（4）Doty模型（在KLOC＞9的情況下）E＝5.288×(KLOC)1.0472.面向FP的估算模型（1）Albrecht&Gaffney模型E＝－13.39＋0.0545FP（2）Kemerer模型E＝60.62＋7.728×10－8FP3（3）Matson，Barnett和Mellichamp模型E＝585.7+15.12FP從上面給出的估算模型可以看出，對于相同的KLOC或FP值，用不同模型估算得出的結(jié)果并不相同。出現(xiàn)這種現(xiàn)象的主要原因是，這些模型都是僅根據(jù)若干個應用領域內(nèi)有限個項目的經(jīng)驗數(shù)據(jù)推導出來的，適用范圍有限。因此，應該根據(jù)當前項目的特點選擇適用的估算模型，并且根據(jù)實際情況適當?shù)卣{(diào)整估算模型。動態(tài)多變量模型動態(tài)多變量模型也稱為軟件方程式，它是根據(jù)從4000多個當代軟件項目中收集的生產(chǎn)率數(shù)據(jù)推導出來的。這種模型把軟件開發(fā)工作量看作是軟件規(guī)模和開發(fā)時間這兩個變量的函數(shù)。動態(tài)多變量估算模型的形式如下：E＝(LOC×B0.333／P)3×(1／t)4（9.2）當開發(fā)實時嵌入式軟件時，典型值是P＝2000；對于電信和系統(tǒng)軟件來說，P＝10000；對于商業(yè)系統(tǒng)應用，P＝28000。適用于當前項目的生產(chǎn)率參數(shù)，可以從歷史數(shù)據(jù)導出。應該注意，軟件方程式有兩個獨立的變量：①對軟件規(guī)模的估算值（用LOC表示）；②以月或年為單位的項目持續(xù)時間。從（9.2）式可以看出，開發(fā)同一個軟件（即LOC固定）的時候，如果把項目持續(xù)時間延長一些，則可降低完成項目所需要的工作量。COCOMO2模型COCOMO是構(gòu)造性成本模型（COnstructiveCOstMOdel）的英文縮寫。1981年B.W.Boehm在《軟件工程經(jīng)濟學》一書中首次提出了COCOMO模型，1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修訂版。它反映了這十多年來我們在成本估計方面所積累的經(jīng)驗和知識。COCOMO2給出了三個層次的軟件開發(fā)工作量估算模型，這三個層次的模型在估算工作量時，對軟件細節(jié)考慮的詳盡程度逐級增加。這些模型既可以用于不同類型的項目，也可以用于同一個項目的不同開發(fā)階段。COCOMO2的三個層次的估算模型分別是：●應用系統(tǒng)組成模型這個模型主要用于估算構(gòu)建原型的工作量，模型名字暗示在構(gòu)建原型時大量使用現(xiàn)有的構(gòu)件?！裨缙谠O計模型這個模型適用于體系結(jié)構(gòu)設計階段?！窈篌w系結(jié)構(gòu)模型這個模型適用于軟件產(chǎn)品的實際開發(fā)階段。E是開發(fā)工作量（以人月為單位），a是模型系數(shù)，KLOC是估計的源代碼行數(shù)（以千行為單位），b是模型指數(shù)，fi（i＝1～17）是成本因素。每個成本因素都根據(jù)它的重要程度和對工作量影響大小賦予一定數(shù)值（稱為工作量系數(shù)）。這些成本因素對任何一個項目的開發(fā)工作量都有影響，即使不使用COCOMO2模型估算工作量，也應該重視這些因素。Boehm把成本因素劃分成產(chǎn)品因素、平臺因素、人員因素和項目因素等四類。與原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述變化，這些變化反映了在過去十幾年中軟件行業(yè)取得的巨大進步：●增加了4個新成本因素，它們分別是要求的可重用性、需要的文檔量、人員連續(xù)性（即人員穩(wěn)定程度）和多地點開發(fā)。這個變化說明，這些因素對開發(fā)成本的影響日益增加?！衤匀チ嗽寄Ｐ椭性械?個成本因素，它們分別是計算機切換時間和使用現(xiàn)代程序設計實踐。現(xiàn)在，開發(fā)人員普遍使用工作站來開發(fā)軟件，批處理的切換時間已經(jīng)不再是問題。而“現(xiàn)代程序設計實踐”已經(jīng)發(fā)展成內(nèi)容更廣泛的“成熟的軟件工程實踐”的概念，并且在COCOMO2工作量方程的指數(shù)b中考慮了這個因素的影響?！衲承┏杀疽蛩兀ǚ治鰡T能力、平臺經(jīng)驗、語言和工具經(jīng)驗）對生產(chǎn)率的影響（即工作量系數(shù)最大值與最小值的比率）增加了，另一些成本因素（程序員能力）的影響減小了?！耥椖拷M的凝聚力這個分級因素表明了開發(fā)人員相互協(xié)作時可能存在的困難。這個因素反映了開發(fā)人員在目標和文化背景等方面相一致的程度，以及開發(fā)人員組成一個小組工作的經(jīng)驗?！襁^程成熟度這個分級因素反映了按照能力成熟度模型度量出的項目組織的成熟度。在原始的COCOMO模型中，僅僅粗略地考慮了前兩個分級因素對指數(shù)b之值的影響。工作量方程中模型系數(shù)a的典型值為3.0，應該根據(jù)歷史經(jīng)驗數(shù)據(jù)確定一個適合本組織所開發(fā)的項目類型的數(shù)值。9.3進度計劃不論從事何種技術(shù)性項目，實際情況都是，在實現(xiàn)一個大目標之前往往必須完成數(shù)以百計的小任務（也稱為作業(yè)）。這些任務中有一些是處于“關鍵路徑”之外的，其完成時間如果沒有嚴重拖后，則不會影響整個項目的完成時間；其他任務則處于關鍵路徑之中，如果這些“關鍵任務”的進度拖后，則整個項目的完成日期就會拖后。沒有一個普遍適用于所有軟件項目的任務集合，因此，一個有效的軟件過程應該定義一組適合于所從事的項目的“任務集合”。一個任務集合包括一組軟件工程工作任務、里程碑和可交付的產(chǎn)品。為一個項目所定義的任務集合，必須包括為最終獲得高質(zhì)量的軟件產(chǎn)品而應該完成的所有工作，但是同時又不能讓項目組負擔不必要的工作。項目管理者的目標是定義全部項目任務，識別出關鍵任務，跟蹤關鍵任務的進展狀況，以保證能及時發(fā)現(xiàn)拖延進度的情況。為了做到這一點，管理者必須制定一個足夠詳細的進度表，以便監(jiān)督項目進度，并控制整個項目。軟件項目的進度安排是一項活動，它通過把工作量分配給特定的軟件工程任務，并規(guī)定完成各項任務的起、止日期，從而將估算的工作量分布于計劃好的項目持續(xù)期內(nèi)。進度計劃將隨著時間的流逝而不斷演化。在項目計劃的早期，首先制定一個宏觀的進度安排表，標識出主要的軟件工程活動和這些活動影響到的產(chǎn)品功能。隨著項目的進展，把宏觀進度表中的每個條目都精化成一個詳細進度表。于是完成一個活動所必須實現(xiàn)的特定任務被標識出來，并安排好了實現(xiàn)這些任務的進度。估算開發(fā)時間通常，成本估計模型也同時為我們提供估算開發(fā)時間T的方程。與工作量方程不同，各種模型估算開發(fā)時間的方程非常類似，如下所示：（1）Walston-Felix模型T＝2.5E0.35（2）原始COCOMO模型T＝2.5E0.38（3）COCOMO2模型T＝3.0E0.33＋0.2×(b－1.01)（4）Putnam模型T＝2.4E1／3E為開發(fā)工作量（以人月為單位），T為開發(fā)時間（以月為單位）。用上列方程計算出的T值，代表正常開發(fā)時間?？蛻敉Ｍs短軟件的開發(fā)時間，顯然，為了縮短開發(fā)時間應該增加從事開發(fā)工作的人數(shù)。但是，經(jīng)驗告訴我們，隨著開發(fā)小組規(guī)模增大，個人的生產(chǎn)率將下降。出現(xiàn)這種現(xiàn)象主要有下述兩個原因：●當小組變得更大時，每個人需要用更多時間與組內(nèi)其他成員討論問題、協(xié)調(diào)工作，因此，通信開銷增加了?！袢绻陂_發(fā)過程中增加小組人員，則最初一段時間內(nèi)項目組總生產(chǎn)率不僅不會提高反而會下降。這是因為開始時新成員還不是生產(chǎn)力，而且在他們學習期間還需要花費小組其他成員的時間。綜合上述兩個原因，存在被稱為Brooks規(guī)律的下述現(xiàn)象：向一個已經(jīng)延期的項目增加人力，只會使得它更加延期。

事實上，做任何事情都需要時間。我們不可能用“人力換時間”的辦法無限制地縮短一個軟件項目的開發(fā)時間。Boehm根據(jù)經(jīng)驗指出，軟件項目開發(fā)時間最多可以減少至正常開發(fā)時間的75%。如果試圖把開發(fā)時間壓縮得太短，則成功的概率幾乎為0。甘特（Gantt）圖估算出完成軟件項目所需要的開發(fā)時間之后，就可以著手制定進度計劃了。Gantt圖是歷史悠久、應用廣泛的進度計劃工具，下面通過一個非常簡單的例子介紹這種工具。假設有一座陳舊的矩形木板房需要重新油漆。這項工作必須分三步完成：首先刮掉舊漆，然后刷上新漆，最后清除濺在窗戶上的油漆。假設一共分配了15名工人去完成這項工作，然而工具卻很有限：只有5把刮舊漆用的刮板，5把刷漆用的刷子，5把清除濺在窗戶上的油漆用的小刮刀。怎樣安排才能使工作進行得更有效呢?一種做法是首先刮掉四面墻壁上的舊漆，然后給每面墻壁都刷上新漆，最后清除濺在每個窗戶上的油漆。顯然這是效率最低的做法，因為總共有15名工人，然而每種工具卻只有5件，這樣安排工作在任何時候都有10名工人閑著沒活干。表9.5各道工序估計需用的時間（小時）

工序墻壁刮

舊

漆刷

新

漆清

理1或32312或4462

假設木板房的第2、4兩面墻的長度比第1、3兩面墻的長度長一倍，此外，不同工作需要用的時間長短也不同，刷新漆最費時間，其次是刮舊漆，清理（即清除濺在窗戶上的油漆）需要的時間最少。表9.5列出了估計每道工序需要用的時間。我們可以使用圖9.1中的Gantt圖描繪上述流水作業(yè)過程：在時間為零時開始刮第一面墻上的舊漆，兩小時后刮舊漆的工人轉(zhuǎn)去刮第二面墻，同時另5名工人開始給第一面墻刷新漆，每當給一面墻刷完新漆之后，第三組的5名工人立即清除濺在這面墻窗戶上的漆。從圖9.1可以看出12小時后刮完所有舊漆，20小時后完成所有墻壁的刷漆工作，再過2小時后清理工作結(jié)束。因此全部工程在22小時后結(jié)束，如果用前述的第一種做法，則需要36小時。圖9.1舊木板房刷漆工程的Gantt圖圖9.2標有里程碑的Gantt圖

為了醒目地表示里程碑，可以在Gantt圖中加上菱形標記，一個菱形代表一個里程碑，如圖9.2所示。圖9.3甘特圖進程時間計劃表工程網(wǎng)絡上一小節(jié)介紹的Gantt圖能很形象地描繪任務分解情況，以及每個子任務（作業(yè)）的開始時間和結(jié)束時間，因此是進度計劃和進度管理的有力工具。它具有直觀簡明和容易掌握、容易繪制的優(yōu)點，但是Gantt圖也有三個主要缺點：（1）不能顯式地描繪各項作業(yè)彼此間的依賴關系；（2）進度計劃的關鍵部分不明確，難于判定哪些部分應當是主攻和主控的對象；（3）計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。當把一個工程項目分解成許多子任務，并且它們彼此間的依賴關系又比較復雜時，僅僅用Gantt圖作為安排進度的工具是不夠的，不僅難于做出既節(jié)省資源又保證進度的計劃，而且還容易發(fā)生差錯。工程網(wǎng)絡是制定進度計劃時另一種常用的圖形工具，它同樣能描繪任務分解情況以及每項作業(yè)的開始時間和結(jié)束時間，此外，它還顯式地描繪各個作業(yè)彼此間的依賴關系。因此，工程網(wǎng)絡是系統(tǒng)分析和系統(tǒng)設計的強有力的工具。

在工程網(wǎng)絡中用箭頭表示作業(yè)（例如，刮舊漆，刷新漆，清理等），用圓圈表示事件（一項作業(yè)開始或結(jié)束）。注意，事件僅僅是可以明確定義的時間點，它并不消耗時間和資源。作業(yè)通常既消耗資源又需要持續(xù)一定時間。圖9.4舊木板房刷漆工程的工程網(wǎng)絡圖中：1—2刮第1面墻上的舊漆；2—3刮第2面墻上的舊漆；2—4給第1面墻刷新漆；3—5刮第3面墻上舊漆；4—6給第2面墻刷新漆；4—7清理第1面墻窗戶；5—8刮第4面墻上舊漆；6—8給第3面墻刷新漆；7—9清理第2面墻窗戶；8—10給第4面墻刷新漆；9—10清理第3面墻窗戶；10—11清理第4面墻窗戶；虛擬作業(yè)：3—4；5—6；6—7；8—9圖9.4是舊木板房刷漆工程的工程網(wǎng)絡。圖中表示刮第1面墻上舊漆的作業(yè)開始于事件1，結(jié)束于事件2。用開始事件和結(jié)束事件的編號標識一個作業(yè)，因此“刮第1面墻上舊漆”是作業(yè)1—2。在工程網(wǎng)絡中的一個事件，如果既有箭頭進入又有箭頭離開，則它既是某些作業(yè)的結(jié)束又是另一些作業(yè)的開始。例如，圖9.4中事件2既是作業(yè)1—2（刮第1面墻上的舊漆）的結(jié)束，又是作業(yè)2—3（刮第2面墻上舊漆）和作業(yè)2—4（給第1面墻刷新漆）的開始。也就是說，只有第1面墻上的舊漆刮完之后，才能開始刮第2面墻上舊漆和給第1面墻刷新漆這兩個作業(yè)。因此，工程網(wǎng)絡顯式地表示了作業(yè)之間的依賴關系。在圖9.4中還有一些虛線箭頭，它們表示虛擬作業(yè)，也就是事實上并不存在的作業(yè)。引入虛擬作業(yè)是為了顯式地表示作業(yè)之間的依賴關系。例如，事件4既是給第1面墻刷新漆結(jié)束，又是給第2面墻刷新漆開始（作業(yè)4—6）。但是，在開始給第2面墻刷新漆之前，不僅必須已經(jīng)給第1面墻刷完了新漆，而且第2面墻上的舊漆也必須已經(jīng)刮凈（事件3）。也就是說，在事件3和事件4之間有依賴關系，或者說在作業(yè)2—3（刮第2面墻上舊漆）和作業(yè)4—6（給第2面墻刷新漆）之間有依賴關系，虛擬作業(yè)3—4明確地表示了這種依賴關系。注意，虛擬作業(yè)既不消耗資源也不需要時間。估算進度畫出類似圖9.4那樣的工程網(wǎng)絡之后，系統(tǒng)分析員就可以借助它的幫助估算工程進度了。為此需要在工程網(wǎng)絡上增加一些必要的信息。首先，把每個作業(yè)估計需要使用的時間寫在表示該項作業(yè)的箭頭上方。注意，箭頭長度和它代表的作業(yè)持續(xù)時間沒有關系，箭頭僅表示依賴關系，它上方的數(shù)字才表示作業(yè)的持續(xù)時間。其次，為每個事件計算下述兩個統(tǒng)計數(shù)字：最早時刻EET和最遲時刻LET。這兩個數(shù)字將分別寫在表示事件的圓圈的右上角和右下角，如圖9.4左下角的符號所示。圖9.5舊木板房刷漆工程的完整的工程網(wǎng)絡（粗線箭頭是關鍵路徑）事件的最早時刻是該事件可以發(fā)生的最早時間。通常工程網(wǎng)絡中第一個事件的最早時刻定義為零，其他事件的最早時刻在工程網(wǎng)絡上從左至右按事件發(fā)生順序計算。計算最早時刻EET使用下述三條簡單規(guī)則：（1）考慮進入該事件的所有作業(yè)；（2）對于每個作業(yè)都計算它的持續(xù)時間與起始事件的EET之和；（3）選取上述和數(shù)中的最大值作為該事件的最早時刻EET。例如，從圖9.4可以看出事件2只有一個作業(yè)（作業(yè)1—2）進入，就是說，僅當作業(yè)1—2完成時事件2才能發(fā)生，因此事件2的最早時刻就是作業(yè)1—2最早可能完成的時刻。定義事件1的最早時刻為零，據(jù)估計，作業(yè)1—2的持續(xù)時間為2小時，也就是說，作業(yè)1—2最早可能完成的時刻為2，因此，事件2的最早時刻為2。同樣，只有一個作業(yè)（作業(yè)2—3）進入事件3，這個作業(yè)的持續(xù)時間為4小時，所以事件3的最早時刻為2＋4＝6。事件4有兩個作業(yè)（2—4和3—4）進入，只有這兩個作業(yè)都完成之后，事件4才能出現(xiàn)（事件4代表上述兩個作業(yè)的結(jié)束）。已知事件2的最早時刻為2，作業(yè)2—4的持續(xù)時間為3小時；事件3的最早時刻為6，作業(yè)3—4（這是一個虛擬作業(yè)）的持續(xù)時間為0，按照上述三條規(guī)則，可以算出事件4的最早時刻為EET＝max｛2＋3，6＋0｝＝6按照這種方法，不難沿著工程網(wǎng)絡從左至右順序算出每個事件的最早時刻，計算結(jié)果標在圖9.5的工程網(wǎng)絡中（每個圓圈內(nèi)右上角的數(shù)字）。事件的最遲時刻是在不影響工程竣工時間的前提下，該事件最晚可以發(fā)生的時刻。按慣例，最后一個事件（工程結(jié)束）的最遲時刻就是它的最早時刻。其他事件的最遲時刻在工程網(wǎng)絡上從右至左按逆作業(yè)流的方向計算。計算最遲時刻LET使用下述三條規(guī)則：（1）考慮離開該事件的所有作業(yè)；（2）從每個作業(yè)的結(jié)束事件的最遲時刻中減去該作業(yè)的持續(xù)時間；（3）選取上述差數(shù)中的最小值做為該事件的最遲時刻LET。例如，按慣例圖9.5中事件11的最遲時刻和最早時刻相同，都是23。逆作業(yè)流方向接下來應該計算事件10的最遲時刻，離開這個事件的只有作業(yè)10—11，該作業(yè)的持續(xù)時間為2小時，它的結(jié)束事件（事件11）的LET為23，因此，事件10的最遲時刻為LET＝23－2＝21類似地，事件9的最遲時刻為LET＝21－1＝20事件8的最遲時刻為LET＝min｛21－6，20－0｝＝15圖9.5中每個圓圈內(nèi)右下角的數(shù)字就是該事件的最遲時刻。關鍵路徑圖9.5中有幾個事件的最早時刻和最遲時刻相同，這些事件定義了關鍵路徑，在圖中關鍵路徑用粗線箭頭表示。關鍵路徑上的事件（關鍵事件）必須準時發(fā)生，組成關鍵路徑的作業(yè)（關鍵作業(yè)）的實際持續(xù)時間不能超過估計的持續(xù)時間，否則工程就不能準時結(jié)束。工程項目的管理人員應該密切注視關鍵作業(yè)的進展情況，如果關鍵事件出現(xiàn)的時間比預計的時間晚，則會使最終完成項目的時間拖后；如果希望縮短工期，只有往關鍵作業(yè)中增加資源才會有效果。機動時間不在關鍵路徑上的作業(yè)有一定程度的機動余地——實際開始時間可以比預定時間晚一些，或者實際持續(xù)時間可以比預計的持續(xù)時間長一些，而并不影響工程的結(jié)束時間。一個作業(yè)可以有的全部機動時間等于它的結(jié)束事件的最遲時刻減去它的開始事件的最早時刻，再減去這個作業(yè)的持續(xù)時間：機動時間＝(LET)結(jié)束－(EET)開始－持續(xù)時間對于前述油漆舊木板房的例子，計算得到的非關鍵作業(yè)的機動時間列在表9.6中。表9.6舊木板房刷漆網(wǎng)絡中的機動時間作

業(yè)LET（結(jié)束）EET（開始）持

續(xù)

時

間機

動

時

間2—462313—5116234—71861115—6128045—8158436—71812067—92012268—92015059—10211515

圖9.6舊木板房刷漆工程改進的Gantt圖之一圖中：粗實線代表由甲組工人完成的作業(yè)；斜劃線代表由乙組工人完成的作業(yè)9.4人員組織軟件項目成功的關鍵是有高素質(zhì)的軟件開發(fā)人員。然而大多數(shù)軟件產(chǎn)品規(guī)模都很大，以至單個軟件開發(fā)人員無法在給定期限內(nèi)完成開發(fā)工作，因此，必須把多名軟件開發(fā)人員組織起來，使他們分工協(xié)作共同完成開發(fā)工作。為了成功地完成軟件開發(fā)工作，項目組成員必須以一種有意義且有效的方式彼此交互和通信。如何組織項目組是一個管理問題，管理者必須合理地組織項目組，使項目組有較高生產(chǎn)率，能夠按預定的進度計劃完成所承擔的工作。經(jīng)驗表明，項目組組織得越好，其生產(chǎn)率越高，而且產(chǎn)品質(zhì)量也越高。除了追求更好的組織方式之外，每個管理者的目標都是建立有凝聚力的項目組。一個有高度凝聚力的小組，是一批團結(jié)得非常緊密的人，他們的整體力量大于個體力量的總和。一旦項目組開始具有凝聚力，成功的可能性就大大增加了。民主制程序員組民主制程序員組通常采用非正式的組織方式，也就是說，雖然名義上有一個組長，但是他和組內(nèi)其他成員完成同樣的任務，地位是平等的。在這樣的小組中，由全體組員討論決定應該完成的工作，協(xié)商解決重大的技術(shù)問題，并且根據(jù)每個人的能力和經(jīng)驗分配適當?shù)娜蝿?。民主制程序員組的主要優(yōu)點是，對發(fā)現(xiàn)錯誤抱著積極的態(tài)度，這種積極態(tài)度有助于更快速地發(fā)現(xiàn)錯誤，從而導致高質(zhì)量的代碼。民主制程序員組的另一個優(yōu)點是，小組成員享有充分民主，小組有高度凝聚力，組內(nèi)學術(shù)空氣濃厚，有利于攻克技術(shù)難關。因此，當有難題需要解決時，也就是說，當所要開發(fā)的軟件產(chǎn)品的技術(shù)難度較高時，采用民主制程序員組是適宜的。為了使少數(shù)經(jīng)驗豐富、技術(shù)高超的程序員在軟件開發(fā)過程中能夠發(fā)揮更大作用，程序設計小組也可以采用下一小節(jié)中介紹的另外一種組織形式。主程序員組美國IBM公司在20世紀70年代初期開始采用主程序員組的組織方式。主程序員組用經(jīng)驗豐富、技術(shù)好、能力強、會管理的程序員作為主程序員，同時，由人和計算機在事務性工作方面給主程序員提供充分支持，而且所有通信都通過一兩個人進行，以減少通信開銷。這種組織方式類似于外科手術(shù)小組的組織：主刀大夫?qū)κ中g(shù)全面負責，并且完成制定手術(shù)方案、開刀等關鍵工作，同時又有麻醉師、護士等技術(shù)熟練的專門人員協(xié)助和配合他的工作。

圖9.7主程序員組的結(jié)構(gòu)一個典型的主程序員組如圖9.7所示。該組由主程序員、后備程序員、編程秘書以及1～3名程序員組成。在必要的時候，該組還有其他領域的專家（例如，法律專家，財務專家等）協(xié)助?，F(xiàn)代程序員組民主制程序員組的最大優(yōu)點，是組員們都對發(fā)現(xiàn)程序錯誤持積極、主動的態(tài)度。主程序員組的組織方式與民主制程序員組很不相同，主程序員對每行代碼的質(zhì)量負責，必須參與全部代碼審查工作，但是，主程序員同時又是負責對小組成員進行評價的管理員，他參與代碼審查工作自然會把所發(fā)現(xiàn)的程序錯誤與小組成員的工作業(yè)績聯(lián)系起來，從而造成小組成員不愿意發(fā)現(xiàn)錯誤的心理。圖9.8現(xiàn)代程序員組擺脫上述矛盾的方法是，取消主程序員的大部分行政管理工作。上一小節(jié)已經(jīng)指出，很難找到一個既是高度熟練的程序員又是成功的管理員的人，取消主程序員的行政管理工作，不僅可消除組員不愿意發(fā)現(xiàn)錯誤的心理障礙，也使得尋找主程序員的人選不再那么困難。于是，實際的“主程序員”應該由兩個人共同擔任：一個技術(shù)負責人，負責小組的技術(shù)活動；一個行政負責人，負責所有非技術(shù)的管理決策。這樣的組織結(jié)構(gòu)如圖9.9所示。圖9.9現(xiàn)代程序員組由于程序員組的人數(shù)不宜過多，當軟件項目規(guī)模較大時，應該把程序員分成若干個小組，采用圖9.10所示的組織結(jié)構(gòu)。該圖描繪的是技術(shù)管理組織的結(jié)構(gòu)，非技術(shù)管理組織的結(jié)構(gòu)與此類似。由圖可以看出，產(chǎn)品作為一個整體其開發(fā)工作是在項目經(jīng)理的指導下進行的，程序員向他們的組長匯報工作，而組長向項目經(jīng)理匯報工作。當產(chǎn)品規(guī)模更大時，可以再增加中間管理層次。圖9.10大型項目的技術(shù)管理組織結(jié)構(gòu)把民主制程序員組和主程序員組的優(yōu)點結(jié)合起來的另一種方法，是在合適的地方采用分散做決定的方法，如圖7.10所示。這樣做有利于形成暢通的通信渠道，以便充分發(fā)揮每個程序員的積極性和主動性，集思廣益攻克技術(shù)難關。這種組織方式對于適合采用民主方法的那類問題（例如，研究性項目或遇到技術(shù)難題需要用集體智慧攻關）非常有效。盡管這種組織方式適當?shù)匕l(fā)揚了民主，但是上下級之間的箭頭（即管理關系）仍然是向下的，也就是說，是在集中指導下發(fā)揚民主。顯然，如果程序員可以指揮項目經(jīng)理，則只會引起混亂。圖9.11包含分散決策的組織方式9.5質(zhì)

量

保

證質(zhì)量是產(chǎn)品的生命，不論生產(chǎn)何種產(chǎn)品，質(zhì)量都是極其重要的。軟件產(chǎn)品開發(fā)周期長，耗費巨大的人力和物力，更必須特別注意保證質(zhì)量。軟件質(zhì)量的定義概括地說，軟件質(zhì)量就是“軟件與明確地和隱含地定義的需求相一致的程度”。更具體地說，軟件質(zhì)量是軟件與明確地敘述的功能和性能需求、文檔中明確描述的開發(fā)標準、以及所有專業(yè)開發(fā)的軟件都應該具有的隱含特征相符合的程度。上述定義強調(diào)了下述三個要點：（1）軟件需求是度量軟件質(zhì)量的基礎，軟件與對它的需求不一致就是質(zhì)量不高。（2）指定的標準定義了一組指導軟件開發(fā)的準則，如果沒有嚴格遵守這些準則，幾乎肯定會導致質(zhì)量不高。（3）通常，有一組沒有顯式描述的隱含需求（例如，軟件應該易學、易用、易維護）。如果軟件雖然滿足明確描述的需求，但卻不滿足隱含的需求，那么軟件的質(zhì)量仍然是值得懷疑的。從管理角度對軟件的質(zhì)量進行度量，可以把這些影響軟件質(zhì)量因素劃分成三組，它們分別反映用戶在使用軟件產(chǎn)品時的三種不同傾向或觀點。這三種傾向是：產(chǎn)品運行，產(chǎn)品修改和產(chǎn)品轉(zhuǎn)移。圖9.12描繪了軟件質(zhì)量因素和上述三種傾向（或稱為產(chǎn)品活動）之間的關系，圖9.12軟件質(zhì)量因素與產(chǎn)品活動的關系軟件質(zhì)量保證措施軟件質(zhì)量保證（SoftwareQualityAssurance，通?？s寫為SQA）的措施主要有，基于非執(zhí)行的測試（也稱為復審）、基于執(zhí)行的測試和程序正確性證明。復審主要用來保證在編碼之前各階段產(chǎn)生的文檔的質(zhì)量；基于執(zhí)行的測試需要在程序編寫出來之后進行，它是保證軟件質(zhì)量的最后一道防線；程序正確性證明使用數(shù)學方法來嚴格驗證程序是否與對它的說明完全一致。參加軟件質(zhì)量保證工作的人員，可以分成下述兩類?！褴浖こ處熗ㄟ^采用可靠的技術(shù)方法和度量、進行正式的技術(shù)復審以及完成計劃周密的測試來保證軟件質(zhì)量?！馭QA小組的職責是，輔助軟件工程小組以獲得高質(zhì)量的軟件產(chǎn)品。其從事的軟件質(zhì)量保證活動主要是計劃、監(jiān)督、記錄、分析和報告。簡而言之，SQA小組的作用是，通過確保軟件過程的質(zhì)量來保證軟件產(chǎn)品的質(zhì)量。1.技術(shù)復審的必要性正式技術(shù)復審的明顯優(yōu)點是，能夠較早地發(fā)現(xiàn)錯誤，防止錯誤被傳播到軟件過程的后續(xù)階段。統(tǒng)計數(shù)字表明，在大型軟件產(chǎn)品中檢測出的錯誤，有60%～70%屬于規(guī)格說明錯誤或設計錯誤。研究表明，正式技術(shù)復審在發(fā)現(xiàn)規(guī)格說明錯誤和設計錯誤方面的有效性高達75%。由于能夠檢測出并排除掉絕大部分的這類錯誤，復審過程將極大地降低后續(xù)開發(fā)和維護階段的成本。正式技術(shù)復審實際上是一類復審方法，包括走查（Walkthrough）和審查（Inspection）等具體方法。走查的步驟比審查少，而且沒有審查那樣正規(guī)。2.走查走查組由4～6名成員組成。以規(guī)格說明走查組為例，成員至少包括一名負責起草規(guī)格說明的人，一位負責該規(guī)格說明的管理員，一位客戶代表，以及下階段開發(fā)組（在本例中是設計組）的一名代表和SQA小組的一名代表。其中，SQA小組的代表應該作為走查組的組長。為了能發(fā)現(xiàn)重大的錯誤，走查組成員最好是經(jīng)驗豐富的高級技術(shù)人員。必須把被走查的材料預先分發(fā)給走查組每位成員。走查組成員應該仔細研究材料并列出兩張表：一張是該成員不理解的術(shù)語，另一張是他認為不正確的術(shù)語。走查組組長引導該組成員走查文檔，力求發(fā)現(xiàn)盡可能多的錯誤。走查組的任務僅僅是標記出錯誤而不是改正錯誤，改正錯誤的工作應該由該文檔的編寫組完成。走查主要有下述兩種方式。（1）參與者驅(qū)動法參與者按照事先準備好的列表，提出他們不理解的術(shù)語和認為不正確的術(shù)語。文檔編寫組的代表必須對每個質(zhì)疑做出回答，要么承認確實有錯誤，要么對質(zhì)疑做出解釋。（2）文檔驅(qū)動法文檔編寫者向走查組成員仔細解釋文檔。在此過程中走查組成員不時針對事先預備好的問題或解釋過程中發(fā)現(xiàn)的問題提出質(zhì)疑。這種方法可能比第一種方法更徹底，往往能檢測出更多的錯誤。經(jīng)驗表明，采用文檔驅(qū)動法時許多錯誤是由文檔講解者自己發(fā)現(xiàn)的。3.審查審查的范圍比走查更廣泛，它的步驟也比較多。通常，審查有5個基本步驟：（1）綜述由負責編寫文檔的一名成員向?qū)彶榻M成員綜述該文檔。在綜述會議結(jié)束時把文檔分發(fā)給每位與會者。（2）準備評審員仔細閱讀文檔。最好列出在審查中發(fā)現(xiàn)的錯誤的類型，并按發(fā)生頻率把錯誤類型分級，以輔助審查工作的進行。這樣的列表有助于評審員們把注意力集中到最常發(fā)生錯誤的區(qū)域。（3）審查評審組仔細走查整個文檔。和走查一樣，這一步的目的也是找出文檔中的錯誤，而不是改正它們。審查組組長應該在一天之內(nèi)寫出一份關于審查的報告。通常，每次審查會不超過90分鐘。（4）返工文檔的作者負責解決在審查報告中列出的所有錯誤及問題。（5）跟蹤審查組組長必須確保所提出的每個問題都圓滿地解決了（要么修正了文檔，要么澄清了被誤認為是錯誤的條回）。必須復查對文檔所做的每個修正，以確保沒有引入新的錯誤。如果在審查過程中返工量超過5%，則應該由審查組再對文檔全面地審查一遍。4.程序正確性證明測試可以暴露程序中的錯誤，因此是保證軟件可靠性的重要手段，但是，測試只能證明程序中有錯誤，并不能證明程序中沒有錯誤。因此，對于保證軟件可靠性來說，測試是一種不完善的技術(shù)，人們自然希望研究出完善的正確性證明技術(shù)。一旦研究出實用的正確性證明程序（即能自動證明其他程序的正確性的程序），軟件的可靠性將更有保證，測試的工作量將大大減少。但是，即使有了正確性證明程序，軟件測試也仍然是需要的，因為程序正確性證明只能證明程序功能是正確的，并不能證明程序的動態(tài)特性是符合要求的，此外，正確性證明過程本身也可能發(fā)生錯誤。正確性證明的基本思想是證明程序能完成預定的功能。因此，應該提供對程序功能的嚴格數(shù)學說明，然后根據(jù)程序代碼證明程序確實能實現(xiàn)它的功能說明。9.6軟件配置管理在開發(fā)計算機軟件的過程中，變化（或稱為變動）是不可避免的。如果不能適當?shù)乜刂坪凸芾碜兓?，勢必造成混亂并產(chǎn)生許多嚴重的錯誤。軟件配置管理是在計算機軟件整個生命期內(nèi)管理變化的一組活動。具體地說，這組活動用來：①標識變化；②控制變化；③確保適當?shù)貙崿F(xiàn)了變化；④向需要知道這方面信息的人報告變化。軟件配置管理不同于軟件維護。維護是在軟件交付給用戶使用后才發(fā)生的，而軟件配置管理是在軟件項目啟動時就開始，并且一直持續(xù)到軟件退役后才終止的一組跟蹤和控制活動。軟件配置管理的目標是，使變化更容易被適應，并且在必須變化時減少所需花費的工作量。變動通常可以分為兩類：第一類是為了改正小錯誤需要的變動，第二類是為了增加或刪掉某些功能，或者為了改變完成某個功能的方法而需要的變動。第一類變動是必須進行的，通常不需要從管理角度對這類變動進行審查和批準。但是，如果發(fā)現(xiàn)錯誤的階段在造成錯誤的階段的后面（例如，在實現(xiàn)階段發(fā)現(xiàn)了設計錯誤），那么使用標準的變動控制過程，把這個變動正式記入文檔，是十分必要的。這樣做有可能保證：所有受這個變動影響的文檔，實際上都做了相應的修改。第二類變動總是需要經(jīng)過從管理角度進行的審批過程。這類變動必須經(jīng)過某種正式的變動評價過程，以估計變動需要的成本和它對軟件系統(tǒng)其他部分的影響。如果變動的代價比較小，而且對系統(tǒng)其他部分沒有影響或影響很小，通常應該批準這個變動。反之，如果變動的代價比較高，或者影響比較大，則必須仔細權(quán)衡利弊，以決定是否進行這個變動；如果同意進行變動，還應該進一步確定由誰支付變動需要的費用。顯然，如果是用戶要求的改動，則用戶應該支付所需要的費用；否則，必須完成某種成本／效益分析，以確定變動可能帶來的效益是否大到值得進行這種變動的地步。應該把所做的變動正式記入文檔，并且相應地修改所有有關的文檔。高級管理人員應該注意防止在工程拖期或成本超過預算時，下級管理人員或開發(fā)人員為勉強按原定計劃進行而降低質(zhì)量要求的傾向。小結(jié)軟件工程包括技術(shù)和管理兩方面的內(nèi)容，是管理與技術(shù)緊密結(jié)合的產(chǎn)物。只有在科學而嚴格的管理之下，先進的技術(shù)方法和優(yōu)秀的軟件工具才能真正發(fā)揮出它們的威力。因此，軟件項目管理是大型軟件工程項目成功的關鍵。軟件項目管理從項目計劃開始，而第一項計劃活動就是估算。為了估算項目工作量和完成期限，首先需要預測軟件規(guī)模。度量軟件規(guī)模的常用技術(shù)主要有代碼行技術(shù)和功能點技術(shù)。這兩種技術(shù)各有優(yōu)缺點，應該根據(jù)軟件項目的特點及項目計劃者對這兩種技術(shù)的熟悉程度，選用適用的技術(shù)。根據(jù)項目的規(guī)模可以估算出完成項目所需的工作量，常用的估算模型有靜態(tài)單變量模型、動態(tài)多變量模型和COCOMO模型。為了做到較準確的項目估算，通常至少同時使用上述三種模型中的兩種。通過比較和協(xié)調(diào)使用不同模型得出的估算值，有可能得到比較準確的估算結(jié)果。雖然軟件項目估算并不是一門精確的科學，但是，把可靠的歷史數(shù)據(jù)和系統(tǒng)化的技術(shù)結(jié)合起來，仍然能夠提高估算的準確度。項目管理者的目標是定義所有項目任務，識別出關鍵任務，跟蹤關鍵任務的進展狀況，以保證能夠及時發(fā)現(xiàn)拖延進度的情況。為此，管理者必須制定一個足夠詳細的進度表，以便監(jiān)督項目進度并控制整個項目。常用的制定進度計劃的工具主要有Gantt圖和工程網(wǎng)絡兩種。Gantt圖具有歷史悠久、直觀簡明、容易學習、容易繪制等優(yōu)點，但是，它不能顯式地表示各項任務彼此間的依賴關系，也不能顯式地表示關鍵路徑和關鍵任務，進度計劃中的關鍵部分不明確。因此，在管理大型軟件項目時，僅用Gantt圖是不夠的，不僅難于做出既節(jié)省資源又保證進度的計劃，而且還容易發(fā)生差錯。工程網(wǎng)絡不僅能描繪任務分解情況及每項作業(yè)的開始時間和結(jié)束時間，而且還能顯式地表示各個作業(yè)彼此間的依賴關系。從工程網(wǎng)絡圖中容易識別出關鍵路徑和關鍵任務。因此，工程網(wǎng)絡是制定進度計劃的強有力的工具。通常，聯(lián)合使用Gantt圖和工程網(wǎng)絡這兩種工具來制定和管理進度計劃，使它們互相補充、取長補短。對任何軟件項目而言，最關鍵的因素都是承擔項目的人員。必須合理地組織項目組，使項目組有較高生產(chǎn)率?！白罴训摹毙〗M結(jié)構(gòu)取決于管理風格、組里的人員數(shù)目和他們的技術(shù)水平，以及所承擔的項目的難易程度。本章具體介紹了國外比較流行的民主制程序員組、主程序員組和現(xiàn)代程序員組的組織方式，討論了不同組織方式的優(yōu)缺點和適用范圍。軟件質(zhì)量保證是在軟件過程中的每一步都進行的“保護性活動”。軟件質(zhì)量保證措施主要有基于非執(zhí)行的測試（也稱為復審）、基于執(zhí)行的測試（即通常所說的測試）和程序正確性證明。軟件復審是最重要的軟件質(zhì)量保證活動之一，它的作用是，在改正錯誤的成本相對比較低時就及時發(fā)現(xiàn)并排除錯誤。走查和審查是進行正式技術(shù)復審的兩類具體方法。審查過程不僅步數(shù)比走查多，而且每個步驟都是正規(guī)的。由于在開發(fā)大型軟件過程中所犯的錯誤絕大多數(shù)是規(guī)格說明錯誤或設計錯誤，而正式的技術(shù)復審發(fā)現(xiàn)這兩類錯誤的有效性高達75%，因此是非常有效的軟件質(zhì)量保證方法。軟件配置管理是應用于整個軟件過程中的保護性活動，它是在軟件整個生命期內(nèi)管理變化的一組活動。qYnVkSgPdMaI7F3C0z)v&s!pXmUjRfOcK9H6E2B+y(u%rZoWlThQeNbJ8G4D1A-w*t$qYnVjSgPdLaI7F3C0y)v&s#pXmUiRfNcK9H5E2B+x(u$rZoWkThQeMbJ8G4D1z-w*t!qYnVjSgOdLaI6F3C0y)v%s#pXlUiRfNcK8H5E2A+x(u$rZnWkThPeMbJ7G4C1z-w&t!qYmVjRgOdL9I6F3B0y)v%s#oXlUiQfNcK8H5D2A+x*u$rZnWkShPeMaJ7G4C1z)w&t!pYmVjRgOcL9I6E3B0y(v%r#oXlTiQfNbK8G5D2A-x*u$qZnVkShPdMaJ7F4C1z)w&s!pYmUjRgOcL9H6E3B+y(v%r#oWlTiQeNbK8G5D1A-x*t$qZnVkSgPdMaI7F4C0z)v&s!pXmUjRfOcK9H6E2B+y(u%r#oWlThQeNbJ8G5D1A-w*t$qYnVkSgPdLaI7F3C0z)v&s#pXmUiRfOcK9H5E2B+x(u%rZoWkThQeMbJ8G4D1z-w*t!qYnVjSgOdLaI6F3C0y)v&s#pXlUiRfNcK9H5E2A+x(u$rZoWkThPeMbJ7G4D1z-w&t!qYmVjSgOdL9I6F3B0y)v%s#oXlUiQfNcK8H5D2A+x*u$rZnWkThPeMaJ7G4C1z-w&t!pYmVjRgOdL9I6E3B0y(v%s#oXlTiQfNbK8H5D2A-x*u$qZnWkShPdMaJ7F4C1z)w&s!pYmUjRgOcL9I6E3B+y(v%r#oXlTiQeNbK8G5D2A-x*t$qZnVkShPdMaI7F4C0z)w&s!pXmUjRfOcL9H6E2B+y(u%r#oWlThQeNbJ8G5D1A-w*t$qYnVkSgPdMaI7F3C0z)v&s!pXmUiRfOcK9H6E2B+x(u%rZoWlThQeMbJ8G4D1A-w*t!qYnVjSgPdLaI6F3C0y)v&s#pXlUiRfNcK9H5E2B+x(u$rZoWkThQeMbJ7G4D1z-w*t!qYmVjSgOdLaI6F3B0y)v%s#pXlUiQfNcK8H5E2A+x*u$rZnWkThPeMaJ7G4C1z-w&t!qYmVjRgOdL9I6F3B0y(v%s#oXlUiQfNbK8H5D2A+x*u$qZnWkShPeMaJ7F4C1z)w&t!pYmUjRgOcL9I6E3B+y(v%r#oXlTiQeNbK8G5D2A-x*u$qZnVkShPdMaJ7F4C0z)w&s!pYmUjRfOcL9H6E3B+y(u%r#oWlTiQeNbJ8G5D1A-x*t$qYnVkSgPdMaI7F3C0z)v&XlTiQfNbK8G5D2A-x*u$qZnVkShPdMaJ7F4C0z)w&s!pYmUjRfOcL9H6E3B+y(u%r#oWlTiQeNbJ8G5D1A-x*t$qYnVkSgPdMaI7F4C0z)v&s!pXmUjRfOcK9H6E2B+y(u%rZoWlThQeNbJ8G4D1A-w*t$qYnVjSgPdLaI7F3C0y)v&s#pXmUiRfNcK9H5E2B+x(u%rZoWkThQeMbJ8G4D1z-w*t!qYnVjSgOdLaI6F3C0y)v%s#pXlUiRfNcK8H5E2A+x(u$rZnWkThPeMbJ7G4C1z-w&t!qYmVjSgOdL9I6F3B0y)v%s#oXlUiQfNcK8H5D2A+x*u$rZnWkShPeMaJ7G4C1z)w&t!pYmVjRgOcL9I6E3B0y(v%r#oXlTiQfNbK8G5D2A-x*u$qZnWkShPdMaJ7F4C1z)w&s!pYmUjRgOcL9H6E3B+y(v%r#oWlTiQeNbK8G5D1A-x*t$qZnVkSgPdMaI7F4C0z)v&s!pXmUjRfOcL9H6E2B+y(u%r#oWlThQeNbJ8G5D1A-w*t$qYnVkSgPdLaI7F3C0z)v&s#pXmUiRfOcK9H5E2B+x(u%rZoWkThQeMbJ8G4D1z-w*t!qYnVjSgPdLaI6F3C0y)v&s#pXlUiRfNcK9H5E2A+x(u$rZoWkThPeMbJ7G4D1z-w&t!qYmVjSgOdL9I6F3B0y)v%s#oXlUiQfNcK8H5E2A+x*u$rZnWkThPeMaJ7G4C1z-w&t!pYmVjRgOdL9I6E3B0y(v%s#oXlTiQfNbK8H5D2A-x*u$qZnWkShPdMaJ7F4C1z)w&t!pYmUjRgOcL9I6E3B+y(v%r#oXlTiQeNbK8G5D2A-x*t$qZnVkShPdMaI7F4C0z)w&s!pXmUjRfOcL9H6E2B+y(u%r#oWlThQeNbJ8G5D1A-x*t$qYnVkSgPdMaI3B+y(v%r#oXlTiQeNbK8G5D2A-x*t$qZnVkShPdMaI7F4C0z)w&s!pXmUjRfOcL9H6E3B+y(u%r#oWlTiQeNbJ8G5D1A-x*t$qYnVkSgPdMaI7F3C0z)v&s!pXmUiRfOcK9H6E2B+x(u%rZoWlThQeMbJ8G4D1A-w*t!qYnVjSgPdLaI7F3C0y)v&s#pXmUiRfNcK9H5E2B+x(u$rZoWkThQeMbJ7G4D1z-w*t!qYmVjSgOdLaI6F3B0y)v%s#pXlUiQfNcK8H5E2A+x(u$rZnWkThPeMbJ7G4C1z-w&t!qYmVjRgOdL9I6F3B0y(v%s#oXlUiQfNbK8H5D2A+x*u$qZnWkShPeMaJ7F4C1z)w&t!pYmVjRgOcL9I6E3B0y(v%r#oXlTiQfNbK8G5D2A-x*u$qZnVkShPdMaJ7F4C0z)w&s!pYmUjRfOcL9H6E3B+y(u%r#oWlTiQeNbJ8G5D1A-x*t$qZnVkSgPdMaI7F4C0z)v&s!pXmUjRfOcK9H6E2B+y(u%rZoWlThQeNbJ8G4D1A-w*t$qYnVjSgPdLaI7F3C0y)v&s#pXmUiRfOcK91A-x*t$qZnVkSgPdMaI7F4C0z)v&s!pXmUjRfOcK9H6E2B+y(u%rZoWlThQeNbJ8G4D1A-w*