在可行性分析之後，專案計畫與質量管理將貫穿需求分析、系統設計、程式設計、測試、維護等軟體工程環節。
專案計畫是要提供乙份合理的程序表，讓所有開發人員任務明確、步調一致，最終共同準時地完成專案。專案計畫是要付諸實施的，不象用嘴巴喊政治口號，可以很誇張。軟體的專案計畫重在「準確」而非「快速」。
提高質量是軟體工程的主要目標。但由於軟體開發是一種智力創作活動，很難象傳統工業那樣通過執行嚴格的操作規範來保證軟體產品的質量。世上最小心翼翼、最老實巴腳的程式設計師未必就能開發出高質量的軟體來。
程式設計師必須了解軟體質量的方方面面(稱為質量因素)，如正確性、效能、易用性、靈活性、可復用性、可理解性等等，才能在進行系統設計、程式設計時將高質量內建其中。軟體的高質量並不是「管理」出來的，實質上是設計出來的，質量的管理只是一種預防和認證的手段而已。
1、專案計畫
做專案計畫，如同給乙個待出生的嬰兒寫傳記那樣困難。如果允許專案結束後再寫計畫，那就輕鬆多了，並且可以100%地準確。
歷史教訓讓我們明白乙個道理：如果一萬年以後才會有一條陽光大道通向共產主義，那麼現在就不要忙著砸鍋煉鋼趕英超美，免得在跑步奔向共產主義時把自己累死餓死。在做軟體的專案計畫時，應屏棄一切浮誇作風。
只有「知已知彼」才能做出合理的專案計畫。這裡「知彼」是指要了解專案的規模、難度與時間限制。「知已」是指要了解有多少可用資源，如可呼叫的程式設計師有幾個?
他們的水平如何?軟硬體設施如何?
1.1知己知彼
首先要了解專案的規模、難度與時間限制，才可以確定應該投入多少人力、物力去做這個專案。在可行性分析階段就要考慮這個問題。但不幸的是，人們在陷入專案不能自撥之前總難以準確地估計專案的規模與難度。
這裡經驗起到了最重要的作用。
專案的時間限制有兩類。第一類，專案應該完成的日期寫在合同中，如果延期了，則開發方要作出相應的賠償。第二類是開發自己的軟體產品，雖然只確定了該產品大致的發行日期並允許有延誤，但如果拖延太久則會失去商機造成損失。
專案的資源分為三類：「人」、「可復用的軟構件」和「軟硬體環境」
(1)人是最有價值的資源。專案計畫的制定者要確定開發人員的名單，要根據他們的專長進行分工。
(2)可復用的軟構件是次有價值的資源。1.2.1節論述了復用軟構件可提高軟體的質量與生產率。軟構件並非一定要用自己的，可以向專業的軟體**商購買。
(3)軟硬體環境雖然不是最重要的資源，卻是必需的資源。原則上軟硬體環境只要符合專案的開發要求即可。有些專案可能要用到特殊的裝置，則要事先作好準備，以免用時找不到而擔擱了程序。
1.2進度安排
有一位程式設計師忙著編寫程式，經理問他還需要多久才能完成。
「明天就可以完成。」程式設計師立即回答。
「我想這是不切實際的，實話實說，到底還要多少時間?」經理說。
「我還想加進一些新的功能，這需要花兩個星期。」程式設計師想了一會兒說。
「即使這樣也期望過高了，只要你編完程式時告訴我一聲，我也就滿足了。」經理說。
幾年以後，經理要退休了。在他去退休午餐會時，發現那位程式設計師正趴在機器旁睡覺：可憐的傢伙整個晚上都在忙於編寫那個程式。
程式設計師也期望每天早晨能在7:00準時起床，可老是一覺醒來就到中午了。專案落後於進度表乃是家常便飯，不必大驚小怪。以下一些事件經常會導致專案被延誤：
(1)上級領導主管臆斷，制定了不現實的期限。專案經理與程式設計師們被迫按照不合理的進度表開展工作。
(2)客戶的需求發生了變化，但沒有對進度表作出相應的修改
(3)低估了專案的規模與難度，導致投入的人力和物力不足。
(4)並未預見到存在難以克服的技術障礙。
(5)並未預見到開發人員會發生問題，如生病，辭職等等。
(6)開發人員之間不能很好的交流、協作，導致各階段任務難以如期完成。
所以寫程序表不能象小學生寫決心書那樣充滿幻想。以下是一些有益的建議：
(1)制定進度表的人最好就是專案負責人，他最了解專案和開發人員。進度表要經過開發小組的討論，在得到大部數人的支援後才能實施。避免出現一廂情願的局面。
(2)進度安排並不見得一定要符合邏輯順序。應盡可能地先做技術難度高的事，後做難度低的事。也就是辛苦在前，輕鬆在後。
小時候我對一位老先生吃飯很感興趣：他總是先把一大盒的公尺飯吃光了，然後再幸福地品嚐一小盒菜。父母告訴我這是中國的傳統美德，叫「先苦後甜」。
從此我銘記在心，按此道理去學習和工作。可如今在飯店裡，人們總是先把菜吃完了，最後才吃點公尺飯。天哪，生活真是太複雜了，我究竟該「先吃飯」還是「先吃菜」?
(3)開發乙個大的軟體專案，應該將進度表分為若干個里程碑。乙個里程碑之內的多個任務可以同步進行。程式設計師極容易沉迷於技術，要麼樂不思蜀，要麼焦頭爛額。
里程碑就象心靈的燈塔，使忙碌的人群不混亂，不迷失方向。
(4)進度表中必須留有緩衝時間，並將緩衝時間用到不確定的事情上。因為人們對即將要做的事情知之甚少，所以要留一些時間以防不測。microsoft公司的一些開發小組甚至制定了「50%緩衝規則」[cusumano1996]。
對許多專案經理而言，容忍進度表中存在緩衝時間，不啻為觀念上的乙個飛躍。
(5)如果發現專案應交付的期限非常不合理，就要跟領導或跟客戶據理力爭，請求放寬期限、調整進度。當客戶的需求發生變化時，就要對進度表作出相應的修正。不要覺得修改進度表很困難很麻煩，不修改才會產生真真的麻煩。
很多人認為戒菸很困難，但馬克·吐溫曾說：「戒菸很容易，我一年就戒幾十次。」
2、零缺陷質量管理的觀念
「零缺陷」質量管理的觀念**於一些國際上著名的硬體生產廠商。儘管軟體的開發與硬體生產有極大的差別，但我們仍可以從「零缺陷」質量管理中得到啟迪。「零缺陷」質量管理至少有兩個核心內容：
一是高目標，二是可執行的規範。
2.1高目標
人在做一件事情時，由於存在很多不確定的因素，一般不可能100%地達到目標。假設平常人做事能完成目標的80%。如果某個人的目標是100分，那麼他最終成績可達80分。
如果某個人的目標只是60分，那麼他最終成績只有48分。我們在考場上身經百戰，很清楚那些只想混及格的學生通常都不會及格，那些想得高分的學生也常為自己的失誤而捶胸頓足。
做乙個專案通常需要多個人的協作。假設專案的總質量(最高為1)是十個開發人員的工作質量之積。如果每個人的質量目標是0.
95，那麼十個人的累積質量不會超過0.19。如果每個人的質量目標是0.
9分，那麼十個人的累積質量不會超過0.03。只有每個人都做到1，專案總質量才會是1。
如果沒有高目標，人的墮落就很快。如果沒有「零缺陷」的質量目標，也許缺陷就會成堆。
2.2可執行的規範
實現100分顯然比實現80分要付出更多的努力。「零缺陷」質量目標不是隨心所欲提出來的，做得到才有意義。實現高目標需要一套可執行的規範來保證。
50年代末，全國掀起了「浮誇風」。為了實現畝產數萬斤推廣各種方法，害得全國鬧飢荒。想不到有數千年種糧經驗的幾億中國農民就這麼整齊地栽倒了。
好規範必須是本企業有能力執行的。乙個普通企業照搬一流企業的規範未必行得通。軟體工程的規範很容易從書籍中找到，但有了這些規範並不表明就能把軟體做好。
國內很多軟體公司根本沒有條件去執行業界推薦的軟體工程規範。社會主義初級階段的「草」與發達資本主義國家的「苗」的確有不同的培育方式。
軟體是如此的靈活，如果沒有規範來制約，就容易因無序的喜好而導致混沌;但規範如果太嚴密了，就會扼殺程式設計師生機勃勃的創造力。制定軟體規範是進退兩難的事。程式設計師必須深入了解軟體多方面的質量因素，把那些能提高軟體質量因素的各種規範植入腦中，才能在各個實踐環節自然而然地把高質量設計到軟體中。
企業如何進行有效質量管理
一 質量效益平衡與質量成本效能問題的提出 質量問題實際上是乙個經濟問題，對企業而言，質量經濟性如從利益和成本兩個方面考慮就有 在利益方面，必須考慮提高利潤和市場占有率 在成本方面，須考慮由識別顧客需要和設計中的缺陷，包括不滿意的產品返工 返修 更換 重新設計 加工 生產損失 擔保和現場修理等發生的費...
IT專案如何進行質量控制
第三類，參與技術和管理評審參與技術和管理評審的目的是為了保證此類評審滿足專案要求，便於監督問題的解決。第四類，做sqa報告sqa活動的乙個重要內容就是報告對軟體產品或軟體過程評估的結果，並提出改進建議。sqa應將其評估的結果文件化。第五類，做sqa度量sqa度量是記錄花費在sqa活動上時間 人力等資...
IT專案如何進行質量控制
最後，根據具體情況採取合理的糾正措施。經過比較與分析，如果發現偏差，就要採取適當的措施進行糾正，讓專案實施回到正軌。可供選用的糾正措施包括重新制定專案計畫 重新安排專案步驟 重新分配專案資源 調整專案組織形式 調整專案管理方式等。一般而言，為了保證it專案不偏離正常軌道，按著既定計畫走向成功，保證糾...