軟件項目策劃計劃與質(zhì)量管理

1、第三章 項目打算與質(zhì)量治理在可行性分析之后，項目打算與質(zhì)量治理將貫穿需求分析、 系統(tǒng)設(shè)計、程序設(shè)計、測試、維護等軟件工程環(huán)節(jié)。項目打算是要提供一份合理的進程表，讓所有開發(fā)人員任務(wù) 明確、步調(diào)一致，最終共同準時地完成項目。項目打算是要付諸 實施的，不象用嘴巴喊政治口號，能夠?qū)ｉT夸張。軟件的項目打 算重在“準確”而非“快速”。提高質(zhì)量是軟件工程的要緊目標。但由于軟件開發(fā)是一種智 力創(chuàng)作活動，專門難象傳統(tǒng)工業(yè)那樣通過執(zhí)行嚴格的操作規(guī)范來 保證軟件產(chǎn)品的質(zhì)量。世上最小心翼翼、最老實巴腳的程序員未 必就能開發(fā)出高質(zhì)量的軟件來。 程序員必須了解軟件質(zhì)量的方方 面面（稱為質(zhì)屋因素），如正確性、性能、易用性、

2、靈活性、可 復(fù)用性、可理解性等等，才能在進行系統(tǒng)設(shè)計、程序設(shè)計時將高 質(zhì)量內(nèi)建其中。軟件的高質(zhì)量并不是“治理”出來的，實質(zhì)上是設(shè)計出來的，質(zhì)量的治理只是一種預(yù)防和認證的手段而已。3.1 項 目 計 劃做項目打算，如同給一個待出生的嬰兒寫傳記那樣困難。假 如同意項目結(jié)束后再寫打算，那就輕松多了，同時能夠100% 地準確。歷史教訓(xùn)讓我們明白一個道理：假如一萬年以后才會有一條 陽光大道通向共產(chǎn)主義，那么現(xiàn)在就不要忙著砸鍋煉鋼趕英超 美，免得在跑步奔向共產(chǎn)主義時把自己累死餓死。 在做軟件的項 目打算時，應(yīng)屏棄一切浮夸作風(fēng)。只有“知已知彼”才能做出合 理的項目打算。那個地點“知彼”是指要了解項目的規(guī)模、

3、難度 與時刻限制?！爸选笔侵敢私庥卸嗌倏捎觅Y源，如可調(diào)用的 程序員有幾個？他們的水平如何？軟硬件設(shè)施如何？知己知彼首先要了解項目的規(guī)模、難度與時刻限制，才能夠確定應(yīng)該投入多少人力、 物力去做那個項目。 在可行性分析時期就要考慮 那個問題。 但不幸的是， 人們在陷入項目不能自撥之前總難以準確地可能項目的規(guī)模與難度。那個地點經(jīng)驗起到了最重要的作用。項目的時刻限制有兩類。第一類，項目應(yīng)該完成的日期寫在 合同中，假如延期了，則開發(fā)方要作出相應(yīng)的賠償。第二類是開 發(fā)自己的軟件產(chǎn)品， 盡管只確定了該產(chǎn)品大致的發(fā)行日期并同意 有延誤，但假如拖延太久則會失去商機造成損失。項目的資源分為三類： “人”、“可

4、復(fù)用的軟構(gòu)件”和“軟硬件環(huán)境”，如圖3.1所示。(1)人是最有價值的資源。項目打算的制定者要確定開發(fā)人員的名單，要依照他們的專長進行分工。(2) 可復(fù)用的軟構(gòu)件是次有價值的資源。節(jié)論述了復(fù)用軟構(gòu)件可提高軟件的質(zhì)量與生產(chǎn)率。軟構(gòu)件并非一定要用自己 的，能夠向?qū)I(yè)的軟件供應(yīng)商購買。(3) 軟硬件環(huán)境盡管不是最重要的資源，卻是必需的資源。原 則上軟硬件環(huán)境只要符合項目的開發(fā)要求即可。 有些項目可能要 用到專門的設(shè)備， 則要事先作好預(yù)備， 以免用時找不到而擔擱了進程3. 軟硬件環(huán)境圖3.1項目的資源進度安排有一位程序員忙著編寫程序， 經(jīng)理問他還需要多久才能完成。“改日就能夠完成。”程序員立即回答?！拔?/p>

5、想這是不切實際的，實話實講，到底還要多少時刻？”經(jīng)理講。“我還想加進一些新的功能，這需要花兩個星期?！背绦騿T想了一會兒講?！凹词谷绱艘财谕^高了，只要你編完程序時告訴我一聲， 我也就滿足了。 ”經(jīng)理講。幾年以后，經(jīng)理要退休了。在他去退休午餐會時，發(fā)覺那位 程序員正趴在機器旁睡覺： 悲傷的家伙整個晚上都在忙于編寫那 個程序。 James 1999程序員也期望每天早晨能在 7:00 準時起床， 可老是一覺醒來 就到中午了。項目落后于進度表乃是家常便飯，不必大驚小怪。 以下一些事件經(jīng)常會導(dǎo)致項目被延誤： （1）上級領(lǐng)導(dǎo)主管臆斷，制定了不現(xiàn)實的期限。項目經(jīng)理與程 序員們被迫按照不合理的進度表開展工作。

6、（ 2）客戶的需求發(fā)生了變化， 但沒有對進度表作出相應(yīng)的修改。 （3）低估了項目的規(guī)模與難度，導(dǎo)致投入的人力和物力不足。（4）并未預(yù)見到存在難以克服的技術(shù)障礙。（5）并未預(yù)見到開發(fā)人員會發(fā)生問題，如生病，辭職等等。（6）開發(fā)人員之間不能專門好的交流、協(xié)作，導(dǎo)致各時期任務(wù) 難以如期完成。因此寫進程表不能象小學(xué)生寫決心書那樣充滿幻想。以下是 一些有益的建議： （1）制定進度表的人最好確實是項目負責人，他最了解項目和 開發(fā)人員。 進度表要通過開發(fā)小組的討論， 在得到大部數(shù)人的支 持后才能實施。幸免出現(xiàn)一廂情愿的局面。（2）進度安排并不見得一定要符合邏輯順序。應(yīng)盡可能地先做 技術(shù)難度高的事，后做難度低

7、的事。也確實是辛苦在前，輕松在 后。小時候我對一位老先生吃飯專門感興趣：他總是先把一大盒 的米飯吃光了， 然后再幸福地品嘗一小盒菜。 父母告訴我這是中 國的傳統(tǒng)美德，叫“先苦后甜” 。從此我銘記在心，按此道理去 學(xué)習(xí)和工作?？涩F(xiàn)在在飯店里，人們總是先把菜吃完了，最后才 吃點米飯。天哪，生活真是太復(fù)雜了，我究竟該“先吃飯” 依 舊“先吃菜”？（ 3）開發(fā)一個大的軟件項目， 應(yīng)該將進度表分為若干個里程碑。 一個里程碑之內(nèi)的多個任務(wù)能夠同步進行。 程序員極容易沉迷于 技術(shù)，要么樂不思蜀，要么焦頭爛額。里程碑就象心靈的燈塔， 使忙碌的人群不混亂，不迷失方向。4）進度表中必須留有緩沖時刻，并將緩沖時刻用

8、到不確定的情況上。 因為人們對立即要做的情況知之甚少， 因此要留一些時 刻以防不測。 Microsoft 公司的一些開發(fā)小組甚至制定了 “50%緩 沖規(guī)則” Cusumano 1996 。對許多項目經(jīng)理而言，容忍進度表 中存在緩沖時刻，不啻為觀念上的一個飛躍。（5）假如發(fā)覺項目應(yīng)交付的期限特不不合理，就要跟領(lǐng)導(dǎo)或跟 客戶據(jù)理力爭，請求放寬期限、調(diào)整進度。當客戶的需求發(fā)生變 化時， 就要對進度表作出相應(yīng)的修正。 不要覺得修改進度表專門 困難專門苦惱， 不修改才會產(chǎn)生真確實苦惱。 專門多人認為戒煙 專門困難，但馬克吐溫曾講：“戒煙專門容易，我一年就戒幾十次。”3.2 零缺陷質(zhì)量治理的觀念“零缺陷”

9、質(zhì)量治理的觀念來源于一些國際上聞名的硬件生 產(chǎn)廠商。 盡管軟件的開發(fā)與硬件生產(chǎn)有極大的差不， 但我們?nèi)阅?夠從“零缺陷”質(zhì)量治理中得到啟迪。 “零缺陷”質(zhì)量治理至少 有兩個核心內(nèi)容：一是高目標，二是可執(zhí)行的規(guī)范高目標人在做一件情況時，由于存在專門多不確定的因素，一般不 可能 100% 地達到目標。假設(shè)平常人做事能完成目標的80%。假如某個人的目標是 100 分，那么他最終成績可達 80 分。假如某 個人的目標只是 60 分，那么他最終成績只有 48 分。我們在考場 上身經(jīng)百戰(zhàn)，專門清晰那些只想混及格的學(xué)生通常都可不能及 格，那些想得高分的學(xué)生也常為自己的失誤而捶胸頓足。做一個項目通常需要多個人的協(xié)作。假設(shè)項目的總質(zhì)量（最 高為 1）是十個開發(fā)人員的工作質(zhì)量之積。假如每個人的質(zhì)量