第三章 項目計劃與質量管理
在可行性分析之后，項目計劃與質量管理將貫穿需求分析、系統設計、程序設計、測試、維護等軟件工程環節。
項目計劃是要提供一份合理的進程表，讓所有開發人員任務明確、步調一致，最終共同準時地完成項目。項目計劃是要付諸實施的，不象用嘴巴喊政治口號，可以很夸張。軟件的項目計劃重在“準確”而非“快速”。
提高質量是軟件工程的主要目標。但由于軟件開發是一種智力創作活動，很難象傳統工業那樣通過執行嚴格的操作規范來保證軟件產品的質量。世上最小心翼翼、最老實巴腳的程序員未必就能開發出高質量的軟件來。程序員必須了解軟件質量的方方面面（稱為質量因素），如正確性、性能、易用性、靈活性、可復用性、可理解性等等，才能在進行系統設計、程序設計時將高質量內建其中。軟件的高質量并不是“管理”出來的，實質上是設計出來的，質量的管理只是一種預防和認證的手段而已。
3.1 項 目 計 劃
做項目計劃，如同給一個待出生的嬰兒寫傳記那樣困難。如果允許項目結束后再寫計劃，那就輕松多了，并且可以100% 地準確。
[[ 歷史教訓讓我們明白一個道理：如果一萬年以后才會有一條陽光大道通向共產主義，那么現在就不要忙著砸鍋煉鋼趕英超美，免得在跑步奔向共產主義時把自己累死餓死]]。在做軟件的項目計劃時，應屏棄一切浮夸作風。只有“知已知彼”才能做出合理的項目計劃。這里“知彼”是指要了解項目的規模、難度與時間限制�！爸选笔侵敢私庥卸嗌倏捎觅Y源，如可調用的程序員有幾個？他們的水平如何？軟硬件設施如何？
3.1.1 知己知彼
首先要了解項目的規模、難度與時間限制，才可以確定應該投入多少人力、物力去做這個項目。在可行性分析階段就要考慮這個問題。但不幸的是，人們在陷入項目不能自撥之前總難以準確地估計項目的規模與難度。這里經驗起到了最重要的作用。
項目的時間限制有兩類。第一類，項目應該完成的日期寫在合同中，如果延期了，則開發方要作出相應的賠償。第二類是開發自己的軟件產品，雖然只確定了該產品大致的發行日期并允許有延誤，但如果拖延太久則會失去商機造成損失。
項目的資源分為三類：“人”、“可復用的軟構件”和“軟硬件環境”，如圖3.1所示。（１）人是最有價值的資源。項目計劃的制定者要確定開發人員的名單，要根據他們的專長進行分工。
（２）可復用的軟構件是次有價值的資源。1.2.1節論述了復用軟構件可提高軟件的質量與生產率。軟構件并非一定要用自己的，可以向專業的軟件供應商購買。
（３）軟硬件環境雖然不是最重要的資源，卻是必需的資源。原則上軟硬件環境只要符合項目的開發要求即可。有些項目可能要用到特殊的設備，則要事先作好準備，以免用時找不到而擔擱了進程。
1. 人
2. 可復用的軟構件
3. 軟 硬 件 環 境
圖3.1 項目的資源
3.1.2 進度安排
有一位程序員忙著編寫程序，經理問他還需要多久才能完成。
“明天就可以完成�！背绦騿T立即回答。
“我想這是不切實際的，實話實說，到底還要多少時間？”經理說。
“我還想加進一些新的功能，這需要花兩個星期�！背绦騿T想了一會兒說。
“即使這樣也期望過高了，只要你編完程序時告訴我一聲，我也就滿足了�！苯浝碚f。
幾年以后，經理要退休了。在他去退休午餐會時，發現那位程序員正趴在機器旁睡覺：可憐的家伙整個晚上都在忙于編寫那個程序。[James 1999]
程序員也期望每天早晨能在7:00準時起床，可老是一覺醒來就到中午了。項目落后于進度表乃是家常便飯，不必大驚小怪。以下一些事件經常會導致項目被延誤：
（1）上級領導主管臆斷，制定了不現實的期限。項目經理與程序員們被迫按照不合理的進度表開展工作。
（2）客戶的需求發生了變化，但沒有對進度表作出相應的修改。
（3）低估了項目的規模與難度，導致投入的人力和物力不足。
（4）并未預見到存在難以克服的技術障礙。
（5）并未預見到開發人員會發生問題，如生病，辭職等等。
（6）開發人員之間不能很好的交流、協作，導致各階段任務難以如期完成。
所以寫進程表不能象小學生寫決心書那樣充滿幻想。以下是一些有益的建議：
（1）制定進度表的人最好就是項目負責人，他最了解項目和開發人員。進度表要經過開發小組的討論，在得到大部數人的支持后才能實施。避免出現一廂情愿的局面。
（2）進度安排并不見得一定要符合邏輯順序。應盡可能地先做技術難度高的事，后做難度低的事。也就是辛苦在前，輕松在后。
小時候我對一位老先生吃飯很感興趣：他總是先把一大盒的米飯吃光了，然后再幸福地品嘗一小盒菜。父母告訴我這是中國的傳統美德，叫“先苦后甜”。從此我銘記在心，按此道理去學習和工作�？扇缃裨陲埖昀�，人們總是先把菜吃完了，最后才吃點米飯。天哪，生活真是太復雜了，我究竟該“先吃飯” 還是“先吃菜”？
（3）開發一個大的軟件項目，應該將進度表分為若干個里程碑。一個里程碑之內的多個任務可以同步進行。程序員極容易沉迷于技術，要么樂不思蜀，要么焦頭爛額。里程碑就象心靈的燈塔，使忙碌的人群不混亂，不迷失方向。
（4）進度表中必須留有緩沖時間，并將緩沖時間用到不確定的事情上。因為人們對即將要做的事情知之甚少，所以要留一些時間以防不測。Microsoft公司的一些開發小組甚至制定了“50% 緩沖規則”[Cusumano 1996]。對許多項目經理而言，容忍進度表中存在緩沖時間，不啻為觀念上的一個飛躍。
（5）如果發現項目應交付的期限非常不合理，就要跟領導或跟客戶據理力爭，請求放寬期限、調整進度。當客戶的需求發生變化時，就要對進度表作出相應的修正。不要覺得修改進度表很困難很麻煩，不修改才會產生真真的麻煩。很多人認為戒煙很困難，但馬克·吐溫曾說：“戒煙很容易，我一年就戒幾十次�！�
3.2 零缺陷質量管理的觀念
“零缺陷”質量管理的觀念來源于一些國際上著名的硬件生產廠商。盡管軟件的開發與硬件生產有極大的差別，但我們仍可以從“零缺陷”質量管理中得到啟迪�！傲闳毕荨辟|量管理至少有兩個核心內容：一是高目標，二是可執行的規范。
3.2.1 高目標
人在做一件事情時，由于存在很多不確定的因素，一般不可能100% 地達到目標。假設平常人做事能完成目標的80%。如果某個人的目標是100分，那么他最終成績可達80分。如果某個人的目標只是60分，那么他最終成績只有48分。我們在考場上身經百戰，很清楚那些只想混及格的學生通常都不會及格，那些想得高分的學生也常為自己的失誤而捶胸頓足。
做一個項目通常需要多個人的協作。假設項目的總質量（最高為1）是十個開發人員的工作質量之積。如果每個人的質量目標是0.95，那么十個人的累積質量不會超過0.19。如果每個人的質量目標是0.9分，那么十個人的累積質量不會超過0.03。只有每個人都做到1，項目總質量才會是1。
如果沒有高目標，人的墮落就很快。如果沒有“零缺陷”的質量目標，也許缺陷就會成堆。
3.2.2 可執行的規范
實現100分顯然比實現80分要付出更多的努力�！傲闳毕荨辟|量目標不是隨心所欲提出來的，做得到才有意義。實現高目標需要一套可執行的規范來保證。
50年代末，全國掀起了“浮夸風”。為了實現畝產數萬斤推廣各種方法，害得全國鬧饑荒。想不到有數千年種糧經驗的幾億中國農民就這么整齊地栽倒了。
好規范必須是本企業有能力執行的。一個普通企業照搬一流企業的規范未必行得通。軟件工程的規范很容易從書籍中找到，但有了這些規范并不表明就能把軟件做好。國內很多軟件公司根本沒有條件去執行業界推薦的軟件工程規范。[[社會主義初級階段的“草”與發達資本主義國家的“苗”的確有不同的培育方式。]]
軟件是如此的靈活，如果沒有規范來制約，就容易因無序的喜好而導致混沌；但規范如果太嚴密了，就會扼殺程序員生機勃勃的創造力。制定軟件規范是進退兩難的事。程序員必須深入了解軟件多方面的質量因素，把那些能提高軟件質量因素的各種規范植入腦中，才能在各個實踐環節自然而然地把高質量設計到軟件中。
3.3 軟件的質量因素
“運行正確”的程序就是高質量的程序嗎？
不貪污的官就是好官嗎？
時下老百姓對一些腐敗的地方政府深痛惡絕，對“官”不再有質量期望。只要當官的不貪污，哪怕毫無政績，也算是“好官”。也有一些精明的老百姓打出旗號：寧要貪污犯，不要大笨蛋。相比之下，程序員是夠幸福的了。因為我們能通過努力，由自己來把握軟件的命運。那么就不要輕易放棄提高軟件質量的權利了。
“運行正確”的程序不見得就是高質量的程序。這個程序也許運行速度很低并且浪費內存；也許代碼寫得一塌糊涂，除了開發者本人誰也看不懂也不會使用。正確性只是反映軟件質量的一個因素而已。
軟件的質量因素很多，如正確性、精確性、可靠性、容錯性、性能、效率、易用性、可理解性、簡潔性、可復用性、可擴展性、兼容性等等（還可以列出十幾個）。這些質量因素之間“你中有我，我中有他”，非常纏綿。如果程序員每天要面對那么多質量因素咬文嚼字，不久就會迂腐得象孔乙已，并且有找不到女朋友的危險。
為了便于理解，可以參照武俠小說中的武學分類，將質量因素粗略地分成幾大派。你想那武學源源流長，相互滲透，誰能數得清有多少江湖派別。但想在道上混，總得知道六大門派：“少林派”、“武當派”、“峨嵋派”、“華山派”、“昆侖派”和“崆峒派”。軟件質量因素的分類如圖3.2所示。其中“正確性與精確性”排在首位，地位如同“少林派”與“武當派”；而“性能與效率”，“易用性”，“可理解性與簡潔性”和“可擴展性與可復用性”亦是舉足輕重的質量因素，地位仿佛“峨嵋派”，“華山派”，“昆侖派”和“崆峒派”，排名不分前后。其它的質量因素總可以在圖3.2中找到合適的親緣關系，本節不再一一細表。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
