軟體開發的管理和控制 (轉)

軟體開發的管理和控制 (轉)[@more@]開發的管理和控制
作者：不詳
文章來源：/getc/200103/0314013.htm" target=_blank>  

---

 文章摘要: 
　　軟體開發是一項很複雜的工作，對於軟體開發的管理和控制，現在有一門專門的學科：軟體工程。在
這方面有許多國家標準和國際標準。許多公司也有相應的文件模版，及相關規定。本文從管理和實踐的角
度來探討軟體開發的管理和控制應遵循的的一些原則。 
 
--------------------------------------------------------------------------------

正文: 

軟體開發的管理和控制　　

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

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

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

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

　　二、?A方法
　　1978年，E．Yourdon和L．L．Constantine提出了結構化方法，即SASD方法，也可稱為面向功能的軟
件開發方法或面向資料流的軟體開發方法。1979年TomDeMarco對此方法作了進一步的完善。
　　Yourdon方法是80年代使用最廣泛的軟體開發方法。它首先用結構化分析（SA）對軟體進行需求分
析，然後用結構化設計（SD）方法進行總體設計，最後是結構化（SP）。這一方法不僅開發步驟明
確，SA、SD、SP相輔相成，一氣呵成，而且給出了兩類典型的軟體結構（變換型和事務型），便於參照，
使軟體開發的成功率大大提高，從而深受軟體開發人員的青睞。

　　三、面向資料結構的軟體開發方法
　　Jackson方法
　　1975年，M．A．Jackson提出了一類至今仍廣泛使用的軟體開發方法。這一方法從目標系統的輸入、
輸出資料結構入手，匯出程式結構，再補充其它細節，就可得到完整的程式結構圖。這一方法對輸
入、輸出資料結構明確的中小型系統特別有效，如商業應用中的表格處理。該方法也可與其它方法結
合，用於模組的詳細設計。
Jackson方法有時也稱為面向資料結構的軟體設計方法。
　　Warnier方法
　　1974年，J．D．Warnier提出的軟體開發方法與Jackson方法類似。差別有三點：一是它們使用的圖形
工具不同，分別使用Warnier圖和Jackson圖；另一個差別是使用的偽碼不同；最主要的差別是在構造程式
框架時，Warnier方法僅考慮輸入資料結構，而Jackson方法不僅考慮輸入資料結構，而且還考慮輸出資料
結構。

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

　　五、面向的軟體開發方法
　　物件導向技術是軟體技術的一次革命，在軟體開發史上具有里程碑的意義。
　　隨著（物件導向程式設計）向OOD（物件導向設計）和（物件導向分析）的發展，最終形成面向對
象的軟體開發方法OMT(LbjectModellingTechnique）。這是一種自底向上和自頂向下相結合的方法，而且
它以物件建模為基礎，從而不僅考慮了輸入、輸出資料結構，實際上也包含了所有物件的資料結構。所以
OMT徹底實現了PAM沒有完全實現的目標。不僅如此，OO技術在需求分析、可維護性和可靠性這三個軟體開
發的關鍵環節和質量指標上有了實質性的突破，徹底地解決了在這些方面存在的嚴重問題，從而宣告了軟
件危機末日的來臨。
　　自底向上的歸納
　　OMT的第一步是從問題的陳述入手，構造系統模型。從真實系統匯出類的體系，即物件模型包括類的
屬性，與子類、父類的繼承關係，以及類之間的關聯。類是具有相似屬性