軟件開發(fā)的管理和控制　　

　　軟件開發(fā)是一項很復(fù)雜的工作，對于軟件開發(fā)的管理和控制，現(xiàn)在有一門專門的學科：軟件工程。在這方面有許多國家標準和國際標準。許多公司也有相應(yīng)的文檔模版，及相關(guān)規(guī)定?，F(xiàn)在不談技術(shù)角度來規(guī)范軟件開發(fā)的管理和控制，從管理和實踐的角度來探討軟件開發(fā)的管理和控制應(yīng)遵循的的一些原則。
　　對于軟件開發(fā)項目中，經(jīng)常出現(xiàn)兩種極端情況，一種是創(chuàng)造了新的生產(chǎn)率和質(zhì)量的紀錄；一種則完全是一場災(zāi)難,不是被取消就是拖延很長時間。前者如在很短的時間內(nèi)，為了趕進度，在幾乎不可能的時間內(nèi)開發(fā)出一套軟件產(chǎn)品，創(chuàng)造了軟件開發(fā)的記錄，滿足了上級所要求的上機日期，由于開發(fā)時間太短，過于倉促，上機時，問題百出，試運行時間長達幾個月或一年半載的，而且程序一改再改，維護工作量大。后者，如某套系統(tǒng)未弄清楚需求，或因設(shè)計問題，開發(fā)失敗。通過提煉這些成功和失敗的例子,軟件項目成功或失敗的根本原因可能會更清晰一些。
　　在討論這些原因之前,我們先來說明一下什么情況可以稱為失敗的軟件項目。
　　1. 由于費用超支或計劃執(zhí)行超時而終止。
　　2. 完成計劃的時間或費用超過了原計劃的50%。
　　3. 由于質(zhì)量或性能上的原因引起和客戶的糾紛。

　　下面我們將按其影響大小的順序排列說明5種錯誤的實踐方式。
　　錯誤1:沒有軟件項目開發(fā)的歷史數(shù)據(jù)
　　缺乏軟件開發(fā)的歷史數(shù)據(jù)是大多數(shù)軟件項目失敗的關(guān)鍵所在, 這樣的結(jié)論也許使很多人感到吃驚,但事實就是如此。沒有一個可靠的軟件開發(fā)的歷史數(shù)據(jù)會使項目經(jīng)理,程序員,客戶對于軟件開發(fā)的過程缺少清醒的認識。
假設(shè)現(xiàn)在你正在管理一個軟件項目,而這個項目還沒有一個公司在36個月內(nèi)完成。作為一個負責的經(jīng)理,你作了一個比較細致和保守的估計,然后告訴你的客戶和你的手下說你認為這個項目需要36-38個月完成。然而常常有這樣的情況發(fā)生：你的客戶和程序員要求把時間壓縮到18個月。客戶一方面希望軟件盡早投入使用而產(chǎn)生經(jīng)濟效益,一方面也想壓縮項目時間作為一個討價還價的籌碼;而程序員一方面可能過于自信,一方面盡早結(jié)束項目也能使他們多賺點錢。而此時你的手頭上也沒有一個可靠的軟件開發(fā)的歷史數(shù)據(jù),在他們的壓力下你同意了18個月的計劃,于是一場災(zāi)難開始了。
　　在項目的開始階段你發(fā)現(xiàn)計劃被拖延了,于是開始向程序員們施加壓力,要求他們加快進度,程序員為了追求進度而不得不把其它指標放在一邊,這些問題不斷的積累下來而項目經(jīng)理卻蒙在鼓里。到了項目中后期這些質(zhì)量問題會不斷暴露出來,而且互相關(guān)聯(lián)并且難以解決,甚至有些是系統(tǒng)設(shè)計的問題,這時才發(fā)現(xiàn)好多模塊要推倒重來,18個月完成計劃變成了天方夜譚。雖然上面只是一個虛擬的例子,但在實際中這種情況比比皆是。問題的關(guān)鍵就在于軟件開發(fā)的歷史數(shù)據(jù)是反映軟件開發(fā)隊伍的能力的標尺,沒有了這個標尺,就無法對軟件的開發(fā)過程有一個清醒的認識。

　　錯誤2:不重視使用軟件費用估值工具軟件和計劃工具軟件
　　軟件開發(fā)方法述評
　　60年代中期開始爆發(fā)了眾所周知的軟件危機。為了克服這一危機，在1968、1969年連續(xù)召開的兩次著名的NATO會議上提出了軟件工程這一術(shù)語，并在以后不斷發(fā)展、完善。與此同時，軟件研究人員也在不斷探索新的軟件開發(fā)方法。至今已形成八類軟件開發(fā)方法。

　　一、Parnas方法
　　最早的軟件開發(fā)方法是由Ｄ．Parnas在1972年提出的。由于當時軟件在可維護性和可靠性方面存在著嚴重問題，因此Parnas提出的方法是針對這兩個問題的。首先，Parnas提出了信息隱蔽原則：在概要設(shè)計時列出將來可能發(fā)生變化的因素，并在模塊劃分時將這些因素放到個別模塊的內(nèi)部。這樣，在將來由于這些因素變化而需修改軟件時，只需修改這些個別的模塊，其它模塊不受影響。信息隱蔽技術(shù)不僅提高了軟件的可維護性，而且也避免了錯誤的蔓延，改善了軟件的可靠性?，F(xiàn)在信息隱蔽原則已成為軟件工程學中的一條重要原則。
　　Parnas提出的第二條原則是在軟件設(shè)計時應(yīng)對可能發(fā)生的種種意外故障采取措施。軟件是很脆弱的，很可能因為一個微小的錯誤而引發(fā)嚴重的事故，所以必須加強防范。如在分配使用設(shè)備前，應(yīng)該取設(shè)備狀態(tài)字，檢查設(shè)備是否正常。此外，模塊之間也要加強檢查，防止錯誤蔓延。
　　Parnas對軟件開發(fā)提出了深刻的見解。遺憾的是，他沒有給出明確的工作流程。所以這一方法不能獨立使用，只能作為其它方法的補充。

　　二、SASA方法
　　1978年，E．Yourdon和L．L．Constantine提出了結(jié)構(gòu)化方法，即SASD方法，也可稱為面向功能的軟件開發(fā)方法或面向數(shù)據(jù)流的軟件開發(fā)方法。1979年TomDeMarco對此方法作了進一步的完善。
　　Yourdon方法是80年代使用最廣泛的軟件開發(fā)方法。它首先用結(jié)構(gòu)化分析（SA）對軟件進行需求分析，然后用結(jié)構(gòu)化設(shè)計（SD）方法進行總體設(shè)計，最后是結(jié)構(gòu)化編程（SP）。這一方法不僅開發(fā)步驟明確，SA、SD、SP相輔相成，一氣呵成，而且給出了兩類典型的軟件結(jié)構(gòu)（變換型和事務(wù)型），便于參照，使軟件開發(fā)的成功率大大提高，從而深受軟件開發(fā)人員的青睞。

　　三、面向數(shù)據(jù)結(jié)構(gòu)的軟件開發(fā)方法
　　Jackson方法
　　1975年，M．A．Jackson提出了一類至今仍廣泛使用的軟件開發(fā)方法。這一方法從目標系統(tǒng)的輸入、輸出數(shù)據(jù)結(jié)構(gòu)入手，導(dǎo)出程序框架結(jié)構(gòu)，再補充其它細節(jié)，就可得到完整的程序結(jié)構(gòu)圖。這一方法對輸入、輸出數(shù)據(jù)結(jié)構(gòu)明確的中小型系統(tǒng)特別有效，如商業(yè)應(yīng)用中的文件表格處理。該方法也可與其它方法結(jié)合，用于模塊的詳細設(shè)計。
Jackson方法有時也稱為面向數(shù)據(jù)結(jié)構(gòu)的軟件設(shè)計方法。
　　Warnier方法
　　1974年，J．D．Warnier提出的軟件開發(fā)方法與Jackson方法類似。差別有三點：一是它們使用的圖形工具不同，分別使用Warnier圖和Jackson圖；另一個差別是使用的偽碼不同；最主要的差別是在構(gòu)造程序框架時，Warnier方法僅考慮輸入數(shù)據(jù)結(jié)構(gòu)，而Jackson方法不僅考慮輸入數(shù)據(jù)結(jié)構(gòu)，而且還考慮輸出數(shù)據(jù)結(jié)構(gòu)。

　　四、問題分析法
　　PAM問題分析法。PAM（ProblemAnalysisMethod）是80年代末由日立公司提出的一種軟件開發(fā)方法。
　　PAM方法希望能兼顧Yourdon方法、Jackson方法和自底向上的軟件開發(fā)方法的優(yōu)點，而避免它們的缺陷。它的基本思想是：考慮到輸入、輸出數(shù)據(jù)結(jié)構(gòu)，指導(dǎo)系統(tǒng)的分解，在系統(tǒng)分析指導(dǎo)下逐步綜合。這一方法的具體步驟是：從輸入、輸出數(shù)據(jù)結(jié)構(gòu)導(dǎo)出基本處理框；分析這些處理框之間的先后關(guān)系；按先后關(guān)系逐步綜合處理框，直到畫出整個系統(tǒng)的PAD圖。從上述步驟中可以看出，這一方法本質(zhì)上是綜合的自底向上的方法，但在逐步綜合之前已進行了有目的的分解，這個目的就是充分考慮系統(tǒng)的輸入、輸出數(shù)據(jù)結(jié)構(gòu)。
　　PAM方法的另一個優(yōu)點是使用PAD圖。這是一種二維樹形結(jié)構(gòu)圖，是到目前為止最好的詳細設(shè)計表示方法之一，遠遠優(yōu)于NS圖和PDL語言。
　　這一方法在日本較為流行，軟件開發(fā)的成功率也很高。由于在輸入、輸出數(shù)據(jù)結(jié)構(gòu)與整個系統(tǒng)之間同樣存在著鴻溝，這一方法仍只適用于中小型問題。

　　五、面向?qū)ο蟮能浖_發(fā)方法
　　面向?qū)ο蠹夹g(shù)是軟件技術(shù)的一次革命，在軟件開發(fā)史上具有里程碑的意義。
　　隨著OOP（面向?qū)ο缶幊蹋┫騉OD（面向?qū)ο笤O(shè)計）和OOA（面向?qū)ο蠓治觯┑陌l(fā)展，最終形成面向?qū)ο蟮能浖_發(fā)方法OMT(LbjectModellingTechnique）。這是一種自底向上和自頂向下相結(jié)合的方法，而且它以對象建模為基礎(chǔ)，從而不僅考慮了輸入、輸出數(shù)據(jù)結(jié)構(gòu)，實際上也包含了所有對象的數(shù)據(jù)結(jié)構(gòu)。所以O(shè)MT徹底實現(xiàn)了PAM沒有完全實現(xiàn)的目標。不僅如此，OO技術(shù)在需求分析、可維護性和可靠性這三個軟件開發(fā)的關(guān)鍵環(huán)節(jié)和質(zhì)量指標上有了實質(zhì)性的突破，徹底地解決了在這些方面存在的嚴重問題，從而宣告了軟件危機末日的來臨。
　　自底向上的歸納
　　OMT的第一步是從問題的陳述入手，構(gòu)造系統(tǒng)模型。從真實系統(tǒng)導(dǎo)出類的體系，即對象模型包括類的屬性，與子類、父類的繼承關(guān)系，以及類之間的關(guān)聯(lián)。類是具有相似屬性和行為的一組具體實例（客觀對象）的抽象，父類是若干子類的歸納。因此這是一種自底向上的歸納過程。在自底向上的歸納過程中，為使子類能更合理地繼承父類的屬性和行為，可能需要自頂向下的修改，從而使整個類體系更加合理。由于這種類體系的構(gòu)造是從具體到抽象，再從抽象到具體，符合人類的思維規(guī)律，因此能更快、更方便地完成任務(wù)。這與自頂向下的Yourdon方法構(gòu)成鮮明的對照。在Yourdon方法中構(gòu)造系統(tǒng)模型是最困難的一步，因為自頂向下的"頂"是一個空中樓閣，缺乏堅實的基礎(chǔ)，而且功能分解有相當大的任意性，因此需要開發(fā)人員有豐富的軟件開發(fā)經(jīng)驗。而在ＯＭＴ中這一工作可由一般開發(fā)人員較快地完成。在對象模型建立后，很容易在這一基礎(chǔ)上再導(dǎo)出動態(tài)模型和功能模型。這三個模型一起構(gòu)成要求解的系統(tǒng)模型。
　　自頂向下的分解
　　系統(tǒng)模型建立后的工作就是分解。與Yourdon方法按功能分解不同，在OMT中通常按服務(wù)（Service）來分解。服務(wù)是具有共同目標的相關(guān)功能的集合，如I／O處理、圖形處理等。這一步的分解通常很明確，而這些子系統(tǒng)的進一步分解因有較具體的系統(tǒng)模型為依據(jù)，也相對容易。所以O(shè)MT也具有自頂向下方法的優(yōu)點，即能有效地控制模塊的復(fù)雜性，同時避免了Yourdon方法中功能分解的困難和不確定性。
　　OMT的基礎(chǔ)是對象模型
　　每個對象類由數(shù)據(jù)結(jié)構(gòu)（屬性）和操作（行為）組成，有關(guān)的所有數(shù)據(jù)結(jié)構(gòu)（包括輸入、輸出數(shù)據(jù)結(jié)構(gòu)）都成了軟件開發(fā)的依據(jù)。因此Jackson方法和PAM中輸入、輸出數(shù)據(jù)結(jié)構(gòu)與整個系統(tǒng)之間的鴻溝在OMT中不再存在。OMT不僅具有Jackson方法和PAM的優(yōu)點，而且可以應(yīng)用于大型系統(tǒng)。更重要的是，在Jackson方法和PAM方法中，當它們的出發(fā)點--輸入、輸出數(shù)據(jù)結(jié)構(gòu)（即系統(tǒng)的邊界）發(fā)生變化時，整個軟件必須推倒重來。但在OMT中系統(tǒng)邊界的改變只是增加或減少一些對象而已，整個系統(tǒng)改動極小。
　　需求分析徹底
　　需求分析不徹底是軟件失敗的主要原因之一。即使在目前，這一危險依然存在。傳統(tǒng)的軟件開發(fā)方法不允許在開發(fā)過程中用戶的需求發(fā)生變化，從而導(dǎo)致種種問題。正是由于這一原因，人們提出了原型化方法，推出探索原型、實驗原型和進化原型，積極鼓勵用戶改進需求。在每次改進需求后又形成新的進化原型供用戶試用，直到用戶基本滿意，大大提高了軟件的成功率。但是它要求軟件開發(fā)人員能迅速生成這些原型，這就要求有自動生成代碼的工具的支持。
　　OMT徹底解決了這一問題。因為需求分析過程已與系統(tǒng)模型的形成過程一致，開發(fā)人員與用戶的討論是從用戶熟悉的具體實例（實體）開始的。開發(fā)人員必須搞清現(xiàn)實系統(tǒng)才能導(dǎo)出系統(tǒng)模型，這就使用戶與開發(fā)人員之間有了共同的語言，避免了傳統(tǒng)需求分析中可能產(chǎn)生的種種問題。
　　可維護性大大改善
　　在OMT之前的軟件開發(fā)方法都是基于功能分解的。盡管軟件工程學在可維護方面作出了極大的努力，使軟件的可維護性有較大的改進。但從本質(zhì)上講，基于功能分解的軟件是不易維護的。因為功能一旦有變化都會使開發(fā)的軟件系統(tǒng)產(chǎn)生較大的變化，甚至推倒重來。更嚴重的是，在這種軟件系統(tǒng)中，修改是困難的。由于種種原因，即使是微小的修改也可能引入新的錯誤。所以傳統(tǒng)開發(fā)方法很可能會引起軟件成本增長失控、軟件質(zhì)量得不到保證等一系列嚴重問題。正是OMT才使軟件的可維護性有了質(zhì)的改善。
　　OMT的基礎(chǔ)是目標系統(tǒng)的對象模型，而不是功能的分解。功能是對象的使用，它依賴于應(yīng)用的細節(jié)，并在開發(fā)過程中不斷變化。由于對象是客觀存在的，因此當需求變化時對象的性質(zhì)要比對象的使用更為穩(wěn)定，從而使建立在對象結(jié)構(gòu)上的軟件系統(tǒng)也更為穩(wěn)定。
　　更重要的是OMT徹底解決了軟件的可維護性。在OO語言中，子類不僅可以繼承父類的屬性和行為，而且也可以重載父類的某個行為（虛函數(shù)）。利用這一特點，我們可以方便地進行功能修改：引入某類的一個子類，對要修改的一些行為（即虛函數(shù)或虛方法）進行重載，也就是對它們重新定義。由于不再在原來的程序模塊中引入修改，所以徹底解決了軟件的可修改性，從而也徹底解決了軟件的可維護性。OO技術(shù)還提高了軟件的可靠性和健壯性。

　　六、可視化開發(fā)方法
　　可視化開發(fā)是90年代軟件界最大的兩個熱點之一。隨著圖形用戶界面的興起，用戶界面在軟件系統(tǒng)中所占的比例也越來越大，有的甚至高達60～70％。產(chǎn)生這一問題的原因是圖形界面元素的生成很不方便。為此Windows提供了應(yīng)用程序設(shè)計接口API（Application Programming Interface），它包含了600多個函數(shù)，極大地方便了圖形用戶界面的開發(fā)。但是在這批函數(shù)中，大量的函數(shù)參數(shù)和使用數(shù)量更多的有關(guān)常量，使基于Windows API的開發(fā)變得相當困難。為此Borland C++推出了Object　Windows編程。它將API的各部分用對象類進行封裝，提供了大量預(yù)定義的類，并為這些定義了許多成員函數(shù)。利用子類對父類的繼承性，以及實例對類的函數(shù)的引用，應(yīng)用程序的開發(fā)可以省卻大量類的定義，省卻大量成員函數(shù)的定義或只需作少量修改以定義子類。
　　Object Windows還提供了許多標準的缺省處理，大大減少了應(yīng)用程序開發(fā)的工作量。但要掌握它們，對非專業(yè)人員來說仍是一個沉重的負擔。為此人們利用Windows API或Borland C++的Object Windows開發(fā)了一批可視開發(fā)工具。
　　可視化開發(fā)就是在可視開發(fā)工具提供的圖形用戶界面上，通過操作界面元素，諸如菜單、按鈕、對話框、編輯框、單選框、復(fù)選框、列表框和滾動條等，由可視開發(fā)工具自動生成應(yīng)用軟件。
　　這類應(yīng)用軟件的工作方式是事件驅(qū)動。對每一事件，由系統(tǒng)產(chǎn)生相應(yīng)的消息，再傳遞給相應(yīng)的消息響應(yīng)函數(shù)。這些消息響應(yīng)函數(shù)是由可視開發(fā)工具在生成軟件時自動裝入的。
　　國內(nèi)的軟件公司大多數(shù)是處在"十幾條槍,一個手工作坊"的水平上,在承接軟件開發(fā)的項目之后往往是幾位骨干人物討論之后對費用和進度作一個大致的估計,然后就開始進入項目的執(zhí)行。這種方法帶有明顯的主觀性。在作一個精確的軟件費用估計和作一個比較現(xiàn)實的項目開發(fā)計劃時需要考慮許多因素。對于一個大的軟件項目,用手工作費用估計和作計劃是不能勝任的?，F(xiàn)在國外市場上有大約50種商業(yè)軟件費用估計工具包和大約100種商業(yè)項目計劃工具包,使用他們作精確的估計比手工的估計更可能獲得成功。常用的軟件費用估計工具軟件有Checkpoint,Colomo,Estimacs,Price_s,Slim。 常用的項目管理軟件有MS Project,Primavera,Project Manager*s Workbench,Timeline。把這二種工具軟件聯(lián)合使用可以互為補充,幫助經(jīng)理駁回客戶和程序員的無理要求并且能精確的控制項目的執(zhí)行。

　　錯誤3:忽視用戶的需求的變動
　　盡管最初的用戶需求在簽定開發(fā)合同時已經(jīng)包含在需求說明書中,但在整個開發(fā)周期中期望用戶的需求一直保持不變是不大可能的,因為用戶對于如何應(yīng)用計算機軟件并沒有一個成熟的經(jīng)驗。在項目進行中用戶的需求會不斷的增長,一般情況下用戶的需求以每月1%的速率增加,如果一個項目在12個月內(nèi)完成,最終將有超過10%的改動,如果項目要持續(xù)36個月,最后將增加1/3的功能。每月1%也只是一個經(jīng)驗數(shù)據(jù),一個缺乏計算機應(yīng)用經(jīng)驗的用戶會更頻繁的改變和增加他的要求。因此在作項目的費用和時間估計時一定要考慮用戶需求的變化。一種比較明智的方法是在簽定開發(fā)合同時把用戶需求的改動和經(jīng)濟利益掛鉤,如果用戶增加或改動了需求,那么軟件的交付日期可以推遲,費用也應(yīng)增加。

　　錯誤4:忽視監(jiān)督項目的進度 　
　　到目前為止,軟件產(chǎn)業(yè)還沒有一個標準的項目進度的檢查標準。一個比較清晰的尺度是用已經(jīng)實現(xiàn)的軟件功能反映項目的進度。但這種方法是否就是最科學的衡量標準,現(xiàn)在還不能定論,畢竟在一個軟件項目中軟件功能只是一個主要而非全部的任務(wù)。因此一個項目經(jīng)理在監(jiān)控項目執(zhí)行時不應(yīng)該只關(guān)注實現(xiàn)的軟件功能,還要關(guān)心文檔,測試,技術(shù)支持這些因素。在實際工作中我們經(jīng)常聽到經(jīng)理或程序員說這樣的話:"項目已經(jīng)完成了90%",這種結(jié)論帶有明顯的主觀性,一個優(yōu)秀的項目經(jīng)理不應(yīng)該被手下的判斷所迷惑,而應(yīng)該按照一個比較客觀的標準去深入檢查。

　　錯誤5:忽視設(shè)計復(fù)查和代碼復(fù)查
　　很多程序員習慣于這樣一種工作方式:只做不想。他們更關(guān)心每天可以寫多少行代碼,完成幾個模塊。在這種態(tài)度下,他們都很不愿意復(fù)查自己的工作,而習慣于在軟件測試階段把隱藏的錯誤改正過來。但設(shè)計復(fù)查和代碼復(fù)查在大型的軟件項目中已經(jīng)有30年的應(yīng)用歷史,而且已經(jīng)被證明在設(shè)計和代碼編寫階段的復(fù)查比軟件測試更能有效的消除錯誤,一些經(jīng)驗數(shù)據(jù)表明,在設(shè)計和代碼復(fù)查時發(fā)現(xiàn)的錯誤是在同等工作量下軟件測試發(fā)現(xiàn)的錯誤的兩倍。

　　結(jié)論:
　　軟件開發(fā)是一個帶有一定風險的工作,為了把風險降到最低, 在項目的執(zhí)行中項目經(jīng)理必須嚴格的監(jiān)督項目的進度,對程序員不愿復(fù)查的壞習慣要給予糾正。項目經(jīng)理必須要從軟件開發(fā)的歷史數(shù)據(jù)和輔助工具包提供的數(shù)據(jù)中作出精確的估計,在作估計時他應(yīng)該考慮為不斷變化的用戶需求留出富余量。