專案計劃與質量管理(轉)

專案計劃與質量管理
在可行性分析之後，專案計劃與質量管理將貫穿需求分析、系統設計、程式設計、測試、維護等軟體工程環節。

專案計劃是要提供一份合理的程式表，讓所有開發人員任務明確、步調一致，最終共同準時地完成專案。專案計劃是要付諸實施的，不象用嘴巴喊政治口號，可以很誇張。軟體的專案計劃重在“準確”而非“快速”。

提高質量是軟體工程的主要目標。但由於軟體開發是一種智力創作活動，很難象傳統工業那樣通過執行嚴格的操作規範來保證軟體產品的質量。世上最小心翼翼、最老實巴腳的程式設計師未必就能開發出高質量的軟體來。程式設計師必須瞭解軟體質量的方方面面（稱為質量因素），如正確性、效能、易用性、靈活性、可複用性、可理解性等等，才能在進行系統設計、程式設計時將高質量內建其中。軟體的高質量並不是“管理”出來的，實質上是設計出來的，質量的管理只是一種預防和認證的手段而已。

項 目 計 劃

做專案計劃，如同給一個待出生的嬰兒寫傳記那樣困難。如果允許專案結束後再寫計劃，那就輕鬆多了，並且可以100% 地準確。

歷史教訓讓我們明白一個道理：如果一萬年以後才會有一條陽光大道通向共產主義，那麼現在就不要忙著砸鍋鍊鋼趕英超美，免得在跑步奔向共產主義時把自己累死餓死。在做軟體的專案計劃時，應屏棄一切浮誇作風。只有“知已知彼”才能做出合理的專案計劃。這裡“知彼”是指要了解專案的規模、難度與時間限制。“知已”是指要了解有多少可用資源，如可呼叫的程式設計師有幾個？他們的水平如何？軟硬體設施如何？

知己知彼

首先要了解專案的規模、難度與時間限制，才可以確定應該投入多少人力、物力去做這個專案。在可行性分析階段就要考慮這個問題。但不幸的是，人們在陷入專案不能自撥之前總難以準確地估計專案的規模與難度。這裡經驗起到了最重要的作用。

專案的時間限制有兩類。第一類，專案應該完成的日期寫在合同中，如果延期了，則開發方要作出相應的賠償。第二類是開發自己的軟體產品，雖然只確定了該產品大致的發行日期並允許有延誤，但如果拖延太久則會失去商機造成損失。

專案的資源分為三類：“人”、“可複用的軟構件”和“軟硬體環境”。
（１）人是最有價值的資源。專案計劃的制定者要確定開發人員的名單，要根據他們的專長進行分工。

（２）可複用的軟構件是次有價值的資源。軟構件並非一定要用自己的，可以向專業的軟體供應商購買。

（３）軟硬體環境雖然不是最重要的資源，卻是必需的資源。原則上軟硬體環境只要符合專案的開發要求即可。有些專案可能要用到特殊的裝置，則要事先作好準備，以免用時找不到而擔擱了程式。

進度安排

有一位程式設計師忙著編寫程式，經理問他還需要多久才能完成。
“明天就可以完成。”程式設計師立即回答。
“我想這是不切實際的，實話實說，到底還要多少時間？”經理說。
“我還想加進一些新的功能，這需要花兩個星期。”程式設計師想了一會兒說。
“即使這樣也期望過高了，只要你編完程式時告訴我一聲，我也就滿足了。”經理說。

幾年以後，經理要退休了。在他去退休午餐會時，發現那位程式設計師正趴在機器旁睡覺：可憐的傢伙整個晚上都在忙於編寫那個程式。[James 1999]

程式設計師也期望每天早晨能在7:00準時起床，可老是一覺醒來就到中午了。專案落後於進度表乃是家常便飯，不必大驚小怪。以下一些事件經常會導致專案被延誤：

（1）上級領導主管臆斷，制定了不現實的期限。專案經理與程式設計師們被迫按照不合理的進度表開展工作。
（2）客戶的需求發生了變化，但沒有對進度表作出相應的修改。
（3）低估了專案的規模與難度，導致投入的人力和物力不足。
（4）並未預見到存在難以克服的技術障礙。
（5）並未預見到開發人員會發生問題，如生病，辭職等等。
（6）開發人員之間不能很好的交流、協作，導致各階段任務難以如期完成。

所以寫程式表不能象小學生寫決心書那樣充滿幻想。以下是一些有益的建議：

（1）制定進度表的人最好就是專案負責人，他最瞭解專案和開發人員。進度表要經過開發小組的討論，在得到大部數人的支援後才能實施。避免出現一廂情願的局面。

（2）進度安排並不見得一定要符合邏輯順序。應儘可能地先做技術難度高的事，後做難度低的事。也就是辛苦在前，輕鬆在後。

小時候我對一位老先生吃飯很感興趣：他總是先把一大盒的米飯吃光了，然後再幸福地品嚐一小盒菜。父母告訴我這是中國的傳統美德，叫“先苦後甜”。從此我銘記在心，按此道理去學習和工作。可如今在飯店裡，人們總是先把菜吃完了，最後才吃點米飯。天哪，生活真是太複雜了，我究竟該“先吃飯” 還是“先吃菜”？

（3）開發一個大的軟體專案，應該將進度表分為若干個里程碑。一個里程碑之內的多個任務可以同步進行。程式設計師極容易沉迷於技術，要麼樂不思蜀，要麼焦頭爛額。里程碑就象心靈的燈塔，使忙碌的人群不混亂，不迷失方向。

（4）進度表中必須留有緩衝時間，並將緩衝時間用到不確定的事情上。因為人們對即將要做的事情知之甚少，所以要留一些時間以防不測。Microsoft公司的一些開發小組甚至制定了“50% 緩衝規則”[Cusumano 1996]。對許多專案經理而言，容忍進度表中存在緩衝時間，不啻為觀念上的一個飛躍。

（5）如果發現專案應交付的期限非常不合理，就要跟領導或跟客戶據理力爭，請求放寬期限、調整進度。當客戶的需求發生變化時，就要對進度表作出相應的修正。不要覺得修改進度表很困難很麻煩，不修改才會產生真真的麻煩。很多人認為戒菸很困難，但馬克·吐溫曾說：“戒菸很容易，我一年就戒幾十次。”

零缺陷質量管理的觀念

“零缺陷”質量管理的觀念來源於一些國際上著名的硬體生產廠商。儘管軟體的開發與硬體生產有極大的差別，但我們仍可以從“零缺陷”質量管理中得到啟迪。“零缺陷”質量管理至少有兩個核心內容：一是高目標，二是可執行的規範。

高目標

人在做一件事情時，由於存在很多不確定的因素，一般不可能100% 地達到目標。假設平常人做事能完成目標的80%。如果某個人的目標是100分，那麼他最終成績可達80分。如果某個人的目標只是60分，那麼他最終成績只有48分。我們在考場上身經百戰，很清楚那些只想混及格的學生通常都不會及格，那些想得高分的學生也常為自己的失誤而捶胸頓足。

做一個專案通常需要多個人的協作。假設專案的總質量（最高為1）是十個開發人員的工作質量之積。如果每個人的質量目標是0.95，那麼十個人的累積質量不會超過0.19。如果每個人的質量目標是0.9分，那麼十個人的累積質量不會超過0.03。只有每個人都做到1，專案總質量才會是1。

如果沒有高目標，人的墮落就很快。如果沒有“零缺陷”的質量目標，也許缺陷就會成堆。

可執行的規範

實現100分顯然比實現80分要付出更多的努力。“零缺陷”質量目標不是隨心所欲提出來的，做得到才有意義。實現高目標需要一套可執行的規範來保證。

50年代末，全國掀起了“浮誇風”。為了實現畝產數萬斤推廣各種方法，害得全國鬧饑荒。想不到有數千年種糧經驗的幾億中國農民就這麼整齊地栽倒了。

好規範必須是本企業有能力執行的。一個普通企業照搬一流企業的規範未必行得通。軟體工程的規範很容易從書籍中找到，但有了這些規範並不表明就能把軟體做好。國內很多軟體公司根本沒有條件去執行業界推薦的軟體工程規範。社會主義初級階段的“草”與發達資本主義國家的“苗”的確有不同的培育方式。

軟體是如此的靈活，如果沒有規範來制約，就容易因無序的喜好而導致混沌；但規範如果太嚴密了，就會扼殺程式設計師生機勃勃的創造力。制定軟體規範是進退兩難的事。程式設計師必須深入瞭解軟體多方面的質量因素，把那些能提高軟體質量因素的各種規範植入腦中，才能在各個實踐環節自然而然地把高質量設計到軟體中。

軟體的質量因素

“執行正確”的程式就是高質量的程式嗎？

不貪汙的官就是好官嗎？

時下老百姓對一些腐敗的地方政府深痛惡絕，對“官”不再有質量期望。只要當官的不貪汙，哪怕毫無政績，也算是“好官”。也有一些精明的老百姓打出旗號：寧要貪汙犯，不要大笨蛋。相比之下，程式設計師是夠幸福的了。因為我們能通過努力，由自己來把握軟體的命運。那麼就不要輕易放棄提高軟體質量的權利了。

“執行正確”的程式不見得就是高質量的程式。這個程式也許執行速度很低並且浪費記憶體；也許程式碼寫得一塌糊塗，除了開發者本人誰也看不懂也不會使用。正確性只是反映軟體質量的一個因素而已。

軟體的質量因素很多，如正確性、精確性、可靠性、容錯性、效能、效率、易用性、可理解性、簡潔性、可複用性、可擴充性、相容性等等（還可以列出十幾個）。這些質量因素之間“你中有我，我中有他”，非常纏綿。如果程式設計師每天要面對那麼多質量因素咬文嚼字，不久就會迂腐得象孔乙已，並且有找不到女朋友的危險。

正確性與精確性

正確性與精確性之所以排在質量因素的第一位，是因為如果軟體執行不正確或者不精確，就會給使用者造成不便甚至造成損失。機器不會主動欺騙人，軟體執行不正確或者不精確一般都是人造成的。即使一個軟體能100% 地按需求規格執行，但是如果需求分析錯了，那麼對客戶而言這個軟體也存在錯誤。即使需求分析完全符合客戶的要求，但是如果軟體沒有100% 地按需求規格執行，那麼這個軟體也存在錯誤。開發一個大的軟體專案，程式設計師要為“正確”、“精確”四個字竭盡精力。

與正確性、精確性相關的質量因素是容錯性和可靠性。

容錯性首先承認軟體系統存在不正確與不精確的因素，為了防止潛在的不正確與不精確因素引發災難，系統為此設計了安全措施。在一些高風險的軟體系統，如航空航天、武器、金融等系統中，容錯性設計非常重要。

可靠性是指在一定的環境下，在給定的時間內，系統不發生故障的概率。可靠性本來是硬體領域的術語。比如某個電子裝置，一開始工作很正常，但由於工作中器件的物理性質會發生變化（如發熱），慢慢地系統就會失常。所以一個設計完全正確的硬體系統，在工作中未必就是可靠的。軟體在執行時不會發生物理性質的變化，人們常以為如果軟體的某個功能是正確的，那麼它一輩子都是正確的。可是我們無法對軟體進行徹底地測試，無法根除軟體中潛在的錯誤。平時軟體執行得好好的，說不準哪一天就不正常了，如“2000年”問題。因此把可靠性引入軟體領域是有意義的。我曾買了一本關於軟體可靠性的著作，此書充滿了數學公式。我發現以我目前的學歷實在難以看懂書上講了些什麼。請寬恕我的愚昧，我把此書給“供”起來，沒敢用筆畫一處記號。

效能與效率

使用者都希望軟體的執行速度高些（高效能），並且佔用資源少些（高效率）。舊社會地主就是這麼對待長工的：幹活要快點，吃得要少點。程式設計師可以通過優化演算法、資料結構和程式碼組織來提高軟體系統的效能與效率。優化的關鍵工作是找出限制效能與效率的“瓶頸”，不要在無關痛癢的地方瞎忙乎。如果你想職稱升得快，光靠增加課時能頂屁用；你就該一年寫它幾十篇文章，爭取破格升教授。

易用性

易用性是指使用者感覺使用軟體的難易程度。使用者可能是操作軟體的終端使用者，也可能是那些要使用原始碼的程式設計師。現代人的生活節奏快，幹啥事都想圖個方便。所以把易用性作為重要的質量因素無可非議。

導致軟體易用性差的根本原因是開發人員犯了“錯位”的毛病：他以為只要自己用起來方便，使用者也一定會滿意。俗話說“王婆賣瓜，自賣自誇”。當程式設計師向使用者展示軟體時，常會得意地講：“這個軟體非常好用，我操作給你看，……是很好用吧！”軟體的易用性要讓使用者來評價。當使用者真的感到軟體很好用時，一股溫暖的感覺油然而生，於是就用“友好”來評價易用性。

可理解性與簡潔性

可理解性表達了人們一種質樸的願望：我化錢買了它，總得讓我明白它是什麼東西。我小時候的一個夥伴在讀中學時，就因無法理解電荷之分正負，覺得很煩惱，便早早地綴學當工人。

可理解性也是對使用者而言的。開發人員只有在自己思路清晰時才可能寫出讓別人能理解的程式。程式設計時還要注意不可濫用技巧，應該用自然的方式程式設計。我們的確不知道自己的得意之舉究竟是錦上添花，還是畫蛇添足。就象蒸出一籠饅頭，在上面插一朵鮮花，本想弄點詩情畫意，卻讓人誤以為那是一堆熱氣騰騰的牛糞。

簡潔是一種美，不管是自己還是使用者都會有同感。在生活中，與簡潔對立的是“羅裡羅嗦”。中國小說中最“婆婆媽媽”的男人是唐僧。有一項民意調查：如果世上只有唐僧、孫悟空、豬八戒和沙僧這四類男人，你要嫁給哪一類？請列出優先順序。調查結果表明，現代女性毫不例外地把唐僧擺在老末。

一個原始的應用問題可能很複雜，但高水平的人就能夠把軟體系統設計得很簡潔。如果軟體系統臃腫不堪，它遲早會出問題。簡潔是人們對工作“精益求精”的結果。

廢話大師有句名言：“如果我令你過於輕鬆地明白了，那你一定是誤解了我說的話。”我最近有一種奇怪的體會：如果把學術文章寫得很簡潔，讓人很容易理解，它往往中不了；只有加上一些玄乎的東西，把本來簡單的弄成複雜的，才會增加投稿的命中率。事實上，我可以在5分鐘之內說清楚三年來讀博所做的工作，根本用不著寫100多頁的博士論文。我是在臨近畢業時，才發覺自己完全不適合讀博士學位。將來工作後，我一定要好好程式設計，重新做人。

可複用性與可擴充性

複用的一種方式是原封不動地使用現成的軟構件，另一種方式是對現成的軟構件進行必要的擴充後再使用。可複用性好的程式一般也具有良好的可擴充性。

質 量 檢 查

檢查是人們不信任自己和別人的一種行為。當某些事情涉及到利益分配時，更需要有檢查活動來保證公平。估計即使進入了共產主義社會，也少不了檢查。

質量檢查並不是要等到專案結束時才執行唯一的一次，應該在每個實踐環節都要執行。對應於進度表，在每個里程碑到達時執行質量檢查比較合理。質量檢查的內容有二：一是作出評審，是合格還是不合格？能打多少分？二是作出建議，對質量為什麼好為什麼差進行分析，以便“改差為好”、“好上加好”。

以下是人們經常採用的軟體質量檢查措施[Pressman 1999]：

（1）事先把檢查的主要內容製成一張表，使檢查活動集中在主要問題上。

（2）只評審工作，不評審開發者。評審的氣氛應該是融洽的。存在的錯誤應該被有禮貌地指出來，任何人的意見都不應被阻撓或小看。

（3）建立一個議事日程並遵循它。檢查過程不能放任自由，必須排照既定的方向和日程進行。

（4）不要化太多的時間爭論和辯駁。

（5）說清楚問題所在，但不要企圖當場解決所有問題。

（6）對檢查人員進行適當的培訓。

……

做好檢查工作並不是件容易的事。自古以來“上有政策，下有對策”。 虛假的質量檢查還不如不檢查，下面講兩個故事作為解釋。

故事一

不久前我回到西北那所讀了六年多的大學，驚奇地發現校園裡房前屋後長滿了待收割的小麥！這所大學是從事電子科技的，種小麥幹啥呀？朱總理曾講過：“目前國家糧食充足，再來三年自然災害也不怕。”現在國泰民安，似乎用不著“深挖洞，廣積糧”。我素知學校提創勤儉節約、自力更生，但與其種小麥還不如種蔬菜呢。老同學告訴我，種小麥是為了應付“211”工程（為21世紀選拔100所重點大學）的檢查團，因為“211”工程有較高的綠化指標。偏偏檢查趕在冬天，那時的西北極難長草。我那所大學本來就人多地少，地上一長草馬上就會被談戀愛的學生給折磨死。一到冬天，整個校園就光禿禿一片。用小麥綠化校園可謂千古絕筆，檢查團的那些權貴人士早已五穀不分，豈知所見的“草坪”乃是麥田。

檢查工作要預防被檢查者弄虛作假。

故事二

我上高中時，班裡舉行一次入團評審。侯選人中有幾位是好學生，有幾位是壞學生。我心想“伸張正義”的機會到了，絕不能讓壞蛋混進純潔的團裡。可天知道團支部書記是聰明絕頂還是蠢笨之極。他竟說：“班裡還有一些同學沒有入團，現在他們申請入團，有不同意的請舉手。”我們都不知道該怎麼辦了。書記接著說：“既然沒有人舉手反對，就表示全部同意，請大家鼓掌歡迎。”這次入團評審不到一分鐘就結束了，從此後我再也沒想過爭取入黨。

檢查工作要有科學的評審方式。

小 結

不知為什麼，國內很多大的企業都喊著要進世界500強。如果真的實現了，世界500強還不全被中國霸佔了。軟體的專案計劃和質量管理都不是用來喊叫的口號。做專案計劃時切忌“冒進”，不要指望在專案陷入困境後靠增加人手來解救。軟體的高質量主要是設計出來的，不是“管”出來的，更不能依賴質量檢查。為此程式設計師要充分了解軟體的質量因素，只有提高設計水平，才能開發出高質量的軟體。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21413/，如需轉載，請註明出處，否則將追究法律責任。