軟件體系結構

4.軟件設計的風險2/1/20231?liqianmu@126.com2/1/20232?liqianmu@126.com1.程序員寫出自認為沒有Bug的代碼。2.軟件測試，發(fā)現(xiàn)了20個Bug。3.程序員修改了10個Bug，并告訴測試組另外10個不是Bug。4.測試組發(fā)現(xiàn)其中5個改動根本無法工作，同時又發(fā)現(xiàn)了15個新Bug。5.重復3次步驟3和步驟4。6.鑒于市場方面的壓力，為了配合當初制定的過分樂觀的發(fā)布時間表，產品終于上市了。7.用戶發(fā)現(xiàn)了137個新Bug。8.已經領了項目獎金的程序員不知跑到哪里去了。9.新組建的項目組修正了差不多全部137個Bug，但又發(fā)現(xiàn)了456個新Bug。10.最初那個程序員從斐濟給飽受拖欠工資之苦的測試組寄來了一張明信片。整個測試組集體辭職。11.公司被競爭對手惡意收購。收購時，軟件的最終版本包含783個Bug。12.新CEO走馬上任。公司雇了一名新程序員重寫該軟件。13.程序員寫出自認為沒有Bug的代碼。

2/1/20233?liqianmu@126.com2/1/20234?liqianmu@126.com3、Hoperun公司軟件過程改進

一、概述1．任務HOPERUN企業(yè)在進行軟件過程改進時，考慮到從企業(yè)當前的發(fā)展要求來看，軟件開發(fā)的質量及交貨已不是主要矛盾，基本上可以滿足用戶的要求。但是，如何提高軟件開發(fā)的生產率，使軟件開發(fā)能做到增加效益，則對企業(yè)顯得極為迫切。為了提高軟件開發(fā)的生產率及提高開發(fā)效益，成立了軟件過程小組(softwareengineeringprocessgroup，SEPG)負責軟件過程改進。具體任務有三：(1)鼓勵開發(fā)人員進行軟件過程改進；(2)對當前正在進行的軟件開發(fā)工作的軟件過程作出正確而詳細的描述及定義；(3)提出一種可行的工作計劃，讓開發(fā)人員遵循，以求改進軟件過程。2/1/20235?liqianmu@126.com3、Hoperun公司軟件過程改進

2．步驟SEPG采取的過程改進步驟如下：(1)對開發(fā)人員調研當前正在進行的軟件開發(fā)工作，用Petrinet描述其軟件過程。Petrinet中的transition表示軟件開發(fā)活動，token表示產品，place表示過程等待執(zhí)行活動的狀態(tài)。(2)深入分析Petrinet所代表的當前的軟件過程流圖，制定工作計劃，并估計在嚴格執(zhí)行工作計劃后，可能得到的效益。其后，工作計劃及效益估計都要經開發(fā)人員認可，認同其可行性，有效性。(3)按工作計劃對實際項目進行實施。(4)最后，分析實際效果后，肯定了“在測試階段總的工作量減少10％?！笨梢缘贸隹隙ㄟ^程改進有效果的結論。2/1/20236?liqianmu@126.com3、Hoperun公司軟件過程改進

二、項目概況該公司是進行一系列服務類外包軟件的開發(fā)。這些軟件有類似的結構，其基本結構如圖所示。整個系統(tǒng)可分為基本部分和應用部分兩大塊。其中對各個不同項目說來，實時管理及I／O部分是共同的，很少修改；對B，C，D，E，F(xiàn)，G模塊，在各個不同項目中只須對其進行少量修改；而模塊A和H，則要對其大部分進行修改。2/1/20237?liqianmu@126.com3、Hoperun公司軟件過程改進

2/1/20238?liqianmu@126.com3、Hoperun公司軟件過程改進

三、調查發(fā)現(xiàn)(1)企業(yè)的主要問題是如何減少開發(fā)費用。對質量及交付日期，目前用戶已基本滿意，所以不作主要改進的考慮。且數(shù)年來，管理人員已對如何減少費用進行不少改進，但收效甚微，所以這次過程改進應主要考慮這一點。(2)從企業(yè)管理的要求上來說，技術上決定采用瀑布模型。但發(fā)現(xiàn)實際執(zhí)行時，有些階段是平行的。要分析原因并解決管理要求與實際執(zhí)行之間的不一致問題。2/1/20239?liqianmu@126.com3、Hoperun公司軟件過程改進

四、軟件過程改進工作方法概況SEPG的軟件過程改進工作分三個階段，六個步驟，第一階段：描述當前的與改進的過程第一步：軟件開發(fā)過程包含許多活動，且相互交互作用，必須精確而形式化地描述。第二步：從當前軟件開發(fā)過程中收集的數(shù)據(jù)中指出費用、質量及進度方面的問題。例如，哪些活動需要大量費用，哪些影響質量(即導致許多出錯)都一一標出。SEPG與開發(fā)組討論原因。第三步：根據(jù)第二步的問題制定工作計劃：改進的過程流圖及改進的過程流中每一個活動的詳細實施方針。前者也用Petrinet描述，后者制定成文檔。此時各種新的軟件工程技術(如設計方法，評審技術，測試技術……)引進工作計劃，還采用一些過去的過程改進的經驗，如CMM的實踐等。2/1/202310?liqianmu@126.com3、Hoperun公司軟件過程改進

四、軟件過程改進工作方法概況SEPG的軟件過程改進工作分三個階段，六個步驟，第二階段：定量估計工作計劃的效益第四步：在執(zhí)行工作計劃前進行效益分析，評估對工作計劃的影響，若有幾個活動計劃，應提出對當前軟件開發(fā)最合適的計劃。2/1/202311?liqianmu@126.com3、Hoperun公司軟件過程改進

四、軟件過程改進工作方法概況SEPG的軟件過程改進工作分三個階段，六個步驟，第三階段：與開發(fā)人員協(xié)同工作進行改進活動第五步：開發(fā)者執(zhí)行新的軟件開發(fā)過程，此時SEPG對過程進行細致而經常性監(jiān)管。第六步：新的項目完成后，評估工作計劃。2/1/202312?liqianmu@126.com3、Hoperun公司軟件過程改進

具體的改進工作：第一步：精確而形式化地描述開發(fā)過程。SEPG對PRl，PR2項目開發(fā)人員進行訪問，構成項目開發(fā)過程的圖a所示的PetriNet(SEPG花了3個月進行這項工作)。其中FT&VT可細畫為圖(b)。實際上SEPG并沒有能夠直接得到這一過程流圖，因在開始時，開發(fā)者只是說出管理部門規(guī)定他們應該如何做的情況，但不是實際上開發(fā)人員所做的情況。所以SEPG花了三個月反復與開發(fā)人員討論，收集開發(fā)人員的工作數(shù)據(jù)——每項工作的人日數(shù)。了解在每個項目PRl、PR2上如何查出錯誤及錯誤的數(shù)目。再反映到圖上，畫出來給開發(fā)人員看。討論每個階段中開發(fā)人員做了什么，沒有做什么。最后，經開發(fā)人員同意：實際情況確實如圖上所呈現(xiàn)的那樣，才得到此過程流圖。2/1/202313?liqianmu@126.com3、Hoperun公司軟件過程改進

第二步：分析當前開發(fā)過程，指出問題。SEPG經分析，發(fā)現(xiàn)黑盒測試階段工作量極大。即在交付前的功能測試與驗證測試(FT&VT)是難于控制且極其混亂。在PRl、PR2中開發(fā)人員為處理這種混亂經常日以繼夜工作。為了度量這些問題，SEPG用三個公式來度量黑盒測試狀態(tài)。2/1/202314?liqianmu@126.com3、Hoperun公司軟件過程改進

對兩個項目的數(shù)據(jù)進行分析后，得到下表的過程狀態(tài)的度量值。

上表中M2一欄中的全部錯誤數(shù)指PG階段及以后的錯誤，可以看到M1：開發(fā)工作的一半工作量用于黑盒測試。M2：大部分錯誤(90％以上)是用黑盒測試發(fā)現(xiàn)的，說明開發(fā)效率十分低，從而產品質量可能很差。M3：數(shù)值相當大。說明質量并沒有達到一定的水平。系統(tǒng)中還存在大量錯誤時，在可以允許停止測試前，就開始了驗證測試VT。這說明對管理人員及開發(fā)人員來說，交付日期壓力太大，所以結果是只能日以繼夜工作。2/1/202315?liqianmu@126.com3、Hoperun公司軟件過程改進

為了了解問題發(fā)生的根源和制定解決問題的計劃，SEFG反復調查下列問題：(1)在黑盒測試中所修正的和發(fā)現(xiàn)的錯誤是哪一階段產生的。(2)如何復查源代碼。(3)如何進行白盒測試。經分析后，SEPG認為要改進以下問題：(1)大部分錯誤是在PG中造成的，是由黑盒測試發(fā)現(xiàn)錯誤且糾正錯誤。但在源碼審查時只查出極少錯誤。(2)在白盒測試時沒有查出或查出極少錯誤且白盒測試無記錄。主要原因是從管理上沒有明確嚴格的要求。白盒測試只是在FT階段開始前的業(yè)余時間內進行的。(3)雖然大多數(shù)人知道必須進行代碼審查及白盒測試，但因為準時交付的壓力太大，使他們不能正常執(zhí)行這些活動。2/1/202316?liqianmu@126.com3、Hoperun公司軟件過程改進

第三步：制定工作計劃。(SEPG用了約2個星期)過程改進的工作計劃包括新的過程流圖和進行工作的詳細指導原則。新的過程流圖如圖所示。2/1/202317?liqianmu@126.com提出的詳細指導原則強調了代碼審查，白盒測試等。具體內容如下：(1)堅決執(zhí)行實際有用的代碼審查，具體規(guī)定：1)每個人都要履行審查員的作用。2)以每個小時審閱代碼100一200行的速度進行審查，以保證代碼審查的質量。3)所有新編的或更動過的代碼行都必須審查。(2)引進單元測試工具，并對單元測試階段所發(fā)現(xiàn)的問題一律寫入報告。具體要求：1)所有新的及更動過的代碼都必須用工具測試。2)在UT階段，對發(fā)現(xiàn)及糾正過的錯誤也都必須記錄。(3)按軟件系統(tǒng)的結構進行集成測試。為了改進FT&VT階段，IT階段的具體要求為：1)按過程圖定義的次序完成IT階段的活動。2)在工作前必須明確地定義每個IT的測試項。3)在IT階段中發(fā)現(xiàn)及排除的錯誤必須記錄。(4)為了使代碼審查及UT階段的項目進度可控，負責人應對每個開發(fā)人員作以下要求：1)在代碼審查及UT階段中每個模塊的進展及發(fā)現(xiàn)錯誤數(shù)都必須記錄。2)定期向有關負責人員報告記錄內容。2/1/202318?liqianmu@126.com第四步：分析新計劃的效益：即如何節(jié)省開發(fā)費用。為了估計新的工作計劃的效益，用“實際PRl”代表真實的PRl，用“改進PRl”表示如果執(zhí)行改進工作計劃后的效果。為了比較兩者的區(qū)別，作如下假定：(1)“改進PRl”在PG及測試階段發(fā)現(xiàn)的錯誤與“實際PRl”在PG及測試階段發(fā)現(xiàn)的錯誤數(shù)全同。(2)在PG中進行代碼審查將查出全部錯誤的52．6％(數(shù)字根據(jù)文獻給出)。(3)通過白盒測試將查出全部錯誤的26．4％(數(shù)字根據(jù)文獻給出)。(4)通過FT將查出全部錯誤的15．9％(數(shù)字根據(jù)文獻給出)。(5)通過VT將查出全部錯誤的5．1％(數(shù)字根據(jù)文獻給出)。再按下述公式計算每個階段的效果：表示產品在階段i需要的總工作量i為PG，UT，IT，F(xiàn)T及VT之一2/1/202319?liqianmu@126.com表示產品在階段i需要的總工作量i為PG，UT，IT，F(xiàn)T及VT之一2/1/202320?liqianmu@126.com對比上述兩個表，得到“1-1083／1270＝0.147”。即可節(jié)省14．7％的工作量。因此此方案得到認可。決定按此執(zhí)行。2/1/202321?liqianmu@126.com第五步：執(zhí)行，監(jiān)管工作計劃及結果。SEPG向開發(fā)組詳細解釋存在的問題，工作計劃及其效益。項目管理人員批準按新的計劃啟動PR3，每個開發(fā)人員都很好理解工作目的(通過與SEPG許多非正式會議)。按此工作計劃完成后，計算M1，M2，M3，結果如表3—5所示。從表中發(fā)現(xiàn)：首先PR3的Ml改進比期望的小，但要注意在PR3中其他階段的工作量(即分母)也減小了。在M2上有極大改進，即差不多一半的錯誤在前面階段已查出。即在前一階段進行了質量保證，所以糾錯工作量可望減少。而在PR3中，從M3的值可看到VT開始時，質量是有保證的，軟件可按時交付。從實際數(shù)據(jù)中得到：在項目的測試階段，PR3的測試效率及生產率都比PRl有極大改進。總的效益約改進10％。2/1/202322?liqianmu@126.com第六步：為了更好說明軟件過程改進的效果，用“實際PR3”的數(shù)據(jù)與假定不執(zhí)行工作計劃的“想象PR3”進行比較。為此，作如下假定：(1)在PG以后及測試階段所發(fā)現(xiàn)的錯誤數(shù)相同。(2)“實際PR3”在PG及UT發(fā)現(xiàn)的所有錯誤(對“想象PR3”來說)，在FT時已發(fā)現(xiàn)且已糾正。(3)“想象PR3”中不進行代碼審查及UT。計算公式如前，而按“實際PR3”中的真實數(shù)據(jù)，結果如表3—6。二者比較，得到“1-1051／1192＝0.118”。即改進了11.8％?？紤]到FT&VT階段可能發(fā)生的混亂情況，改進的實際效益可能更大，應接近于以前的估計。2/1/202323?liqianmu@126.com五、HOPERUN公司軟件過程改進工作小結在進行軟件改進過程中，開發(fā)人員及管理人員都進行很好的合作，且互有好評，并且大家都理解到：(1)管理人員真正地理解到需要改進軟件過程。(2)由于SEPG與全體開發(fā)組經常進行許