在談到了我們與印度的差距，其中我認為值得考慮的有2件。1是印度軟體品質實現了6 sigma，也就是說每100萬行代碼只有3.4行錯誤，我們如何達到甚至超過印度軟體的品質。2是印度軟體品質依靠與軟體的重用，我們如何提高我們的軟體重用度。
軟體品質
我認為一個成功項目的評定標準有3個：1準時，2保證品質，3滿足客戶需求。目前軟體Team Dev存在的最大的問題就是在規定的議程內無法保證產品的品質。我想我們需要更多的時間來討論如何保證議程和品質。
我們現在有很多未知缺陷隱藏在項目開發中，我總結了各個項目評估。項目評估的大多數內容都是正面的，但我對項目評估的等級劃分有所擔憂。評估的結果可能隱藏著沒有被察覺問題。如果評估的每一項都分為：非常滿意，滿意，一般，不滿意，和非常不滿意，五等級。這樣的評估，對於不同性格的評估者會做出不同的結果。例如，性格溫和的人將不滿意的項評為一般，等等。項目評估是我們重要的客戶回函資訊。我們必須認真對待。如何評估的項目有不滿意，則都會得到我們的重視，但如何評為滿意和一般，其重視程度就會下降。得來的重要反饋資訊將會被忽視。所以我認為評估標準為滿意和不滿意兩項即可。對於不滿意的項目，希望客戶能多提寶貴意見。
在項目評估中，客戶的建議和意見多出現在專案管理，技術，成果的品質，語言幾個方面。這些方面幾乎涵蓋了項目開發的所有階段。那麼我們如何發掘問題的本質和改正，改進項目開發的流程。我閱讀了《6σ管理法》[1]一書，書中將品質改進分為以下幾個階段[1]。
定義-評估-分析-改進-控制
我認為它同樣適合我們找出問題的根源。
- 定義客戶需求 首先我們要瞭解並追蹤客戶的需求和他們的態度。可以通過項目評估系統收集客戶回函資訊。但目前項目評估系統沒有足夠的反饋資訊，並且似乎沒有使用這些反饋資訊。只有當我們分析客戶回函資料並據此採取行動之後，顧客反饋資料才是有用的。
調查客戶的需求和行為後，撰寫需求說明。需求說明是績效標準簡潔而全面的描述。
例如：需求說明
在項目開發過程中，使客戶滿意的因素是：
1）懂得編寫客戶需要的各種文檔；
2）文檔提交後的返工次數在1次以內；
3）客戶測試成果時出現的Defects在10個以內；
4）按規定的schedule內完成成果；
5）程式員具有在1天內解決2個以上Defects的能力；
6）語言水平達到2級以上。
需求說明首先設定合格需求說明或績效標準的目標。接著應當做到如下幾點[1]：
1．保證需求說明與項目相聯絡。
2．描述單個的績效標準或因素。應當清楚描述客戶需求的是什麼或他們要進行評估的是什麼---時間，成本，品質。
3．用可觀察的因素來描述客戶需求，或者用可評估的因素來表述客戶需求。應當將任何一個客戶需求，努力轉換常可觀察的東西。
4．設定產品或服務績效的“可接受”和“不可接受”標準。
5．需求說明應當與客戶回函相稱，或者由後者決定其有效性。寫需求說明是最重要的事情是：說明或具體需求應當滿足客戶的需求或期望。流程內的每一個需求應當能和外部客戶的需求保持一致。
定義需求說明後分析客戶需求並對其排序。顯然客戶的所有要求並不是同等重要，對於每一個客戶來說，其要求沒有被滿足時，不同客戶的反應也不是天生一樣的。我們可以把客戶的需求劃分成三種類型：
1．不滿意狀態或客戶的基本需求。客戶認為絕對需要滿足的需求包括一些因素，這些因素具有一些特徵，表現為一定的績效評估標準。如果滿足了客戶的這些需求，還不能說取得了“額外的信譽”；如果沒有滿足這些需求，客戶絕對不會滿意。例如：懂得編寫客戶需要的各種文檔；按規定的schedule內完成成果。
2．滿意狀態或者可變需求。在這類需求上，做的越好（壞），客戶對公司的評價就越高（低）。最常見的是成果的品質。成果提交後的返工次數越少，客戶的滿意成多越高。如果我們能保證基本需求，那麼，每一項流程改進活動就應優先集中精力於提高公司在品質提高上的能力和績效。
3．高興狀態或潛在需求。我們的成果的某些特徵或因素會超出客戶的期望值，或這些因素特徵是以沒有人提出過的需求為目標取向的。例如：我們為客戶開發的某個功能的效能比原系統效能提高了200%，某一個Batch Job已耗用時間減少到原系統已耗用時間的1/3等等。
另外在定義需求說明是我們還要注意：
要建立一個範圍較大的收集及使用客戶資訊體系。在這一點我們需要考慮是否改進客戶的反饋系統，使其能收集更多的資訊。
要儘力編寫出清楚的，可評估的，相關的需求說明。
不要不跟蹤，不評估公司針對客戶需求的績效。
- 評估公司當前績效 本階段的核心內容是評估目前的績效。評估步驟的主要任務有兩個要點：
1．對比客戶對產品和對公司服務方面的需求，評估公司商務程序的當前績效。
評估公司商務程序的當前績效首先要完全認識清楚客戶是如何評估公司的產品和服務的。我們的客戶根據以下因素來評估我們的產品和服務：
1． 專案管理方法；
2． 技術能力；
3． 產品和服務的品質；
4． 專案範圍管理能力；
5． 態度。
那麼平衡評估量的切實可行性和評估量的價值/有用性，可總結評估對象為：
1．每個階段所需時間，延期時間；
2．各種文檔的返工次數；
3．各個階段的Defects個數，原因；
4．測試階段的Defects個數，原因；
5．解決一個Defects的時間。
2．通過識別有關公司流程優勢，劣勢的資料，得出有效評估結論。
目前公司中可用的資料很多，例如：CMMI Defects文檔等等。但是，要保證我們選取的來源可以提供準確的資料，並且能夠代表我們想評估的工作流程，產品和服務。所以CMMI的文檔（撰寫過程中有保證其完美性的嫌疑。）是不能作為評估資料的。獲得這些評估對象的資料需要我們所有公司同僚的共同努力和認真對待。
- 分析問題 我們需要對資料分析和對流程分析。
資料分析：利用評估量和有關資料（已經收集的資料或在分析階段收集的新資料）來分辨問題模式，問題發展趨勢或其他一些有關因素，不管這些因素是推測出來的，還是證明/未證明的可能原因。
流程分析：深入調查並領會工作如何開展，從而辨別不一致的，不相關的或可能引起問題發生或導致問題發生的某些領域。
根據資料分析編寫原因的草稿：
例如：
1． 編碼階段經常延期是因為編碼階段所規定時間太少的原因，而測試階段的延期是因為編碼沒有完成而造成的連鎖反應；
2． 文檔返工的原因是沒有在提交之前作有效審查工作；
3． 編碼中的Defects引起的原因是馬虎，沒有經驗，沒有編程規範等；
4． Defects多出現的問題原因可分為：人為因素，技術問題，商務邏輯問題，開發標準問題。
繪製流程圖進行流程分析：
流程圖是最重要的一種方法。在流程圖中，繪圖這關注的主要焦點是改進，設計，評估和管理流程。流程圖的基本要素很簡單：一系列任務，決策點/檢查點，工作流程向。在繪製流程圖時，可能會發現：最有啟發性的資訊確實來自“繪製流程圖”階段。當一個流程被記錄下來並被有效確認之後，就可以分析一下一些特殊的問題領域：
不一致性。指交接工作做得不好。或者與客戶沒有很好的交流需求。
瓶頸。瓶頸指流程中某點的工作負載大大超過此處的處理能力，從而延緩了整個工作流程的進度。例如：編碼階段和測試階段。
冗餘現象。冗餘現象指在流程的兩個地方重複做的事情，也可以指兩項產生同時結果的具有相似性的活動。
返工周期。返工周期指產品需求在流程中加以修理，更正或修補。例如：文檔的返工，代碼的返工。
決策點/檢查點。指流程中的某些點，在此處，人們將做出選擇，進行評估，檢查或積極幹預流程活動（會產生可能的延誤）。
分析階段的注意事項：
1．要詳細闡述因果假說。
2．要對假說持懷疑的態度。
3．要運用嘗試和創造力。
4．不要把分析工作做得過細。
5．不要分析不足。
- 改進，提出、選擇並實施解決方案 解決方案說明。解決方案說明是一份清楚表述改進活動的建議性檔案。解決方案說明的價值在於：它能使人們對正在考慮中的各種建議有一個全域的概念和把握。
例如：
1． 解決文檔返工問題：制定文檔審查標準，根據CheckList進行自我審查和上級審查。
2． 解決編碼延期問題：在設計階段將部分已清楚的子模組提前進入編碼。在設計階段的初期就定義好介面的風格規範。
3． 編程出現的Defects問題：制定編程標準。製作自動標準審查軟體。
4． Defects的問題：敢於發現並記載錯誤(Defects)。不能迴避錯誤，或不能有避免提出Defects的觀念。越多的發現錯誤就越能有助於提高我們的品質。
改進階段的注意事項：
1．要尋找真正具有創新性的改進方案。
2．要把目標指向你的解決方案。
3．要實現做好細緻的規劃。
4．不要從開始就全面實施（方案）。
5．不要忘記進行評估。
- 持續改進 提供連續的評估量和措施以支援改進。為解決方案建立強有力的支援。
要做好檔案記錄以支援新流程。
要選擇一種評估兩間的平衡搭配來檢測流程績效。
要編製傳遞資訊間接迅速的評估報告。
要準備流程中一旦產生問題時的應對計劃。
不要對檔案記錄棄之不用。
不要忘記流程圖的存在。
定義-評估-分析-改進-控制的方法來源於6σ，但不管其名稱如何，其目的是讓我們能夠準確地找到並且根除潛在的問題，使我們的軟體達到無缺陷。我認為提高軟體品質到無缺陷的水平是我們永恒的目標，因此我們需要用一種可行有效方法協助我們逐步靠近這個目標。
軟體複用
如何提高軟體開發進度和品質？目前一個熱門的話題就是使用可重用的組件。印度通過使用可複用組件。成倍提高了其軟體開發的速度和品質。那麼我們為什麼沒有大量的使用可複用的組件呢。
- 軟體重用的困難在哪裡 目前我們存在一些困難阻礙了我們使用可複用的組件。
1．一切重頭開始的習慣
首先現在我們還沒有現成使用可複用組件的概念。大多數的程式員都習慣於重頭開發，從無到有的過程。這是一個觀念問題。要想普遍軟體重用的概念先要讓所有人習慣軟體重用的觀念。具體地說就是，軟體開發時的第一意識是尋找已存在的組件來實現需求。
2．不知道到哪去找組件
尋找需要有場所。我們現在還沒有儲存可複用組件的場所。所以我們必須先要建立一個組件庫。
3．沒有可重用的組件。
有了組件庫，我們就可以將組件儲存在組件庫裡。但是，如果組件庫裡沒有足夠的組件，那麼我們就找不到我們想要得組件。解決這一問題需要我們所有人的努力。我們要採用物件導向的方法，在開發軟體時以可複用的組件為單位，並及時將開發的組件存入組件庫。
4．即使有也不敢使用-品質
有缺陷的組件是不能使用的。因此在組件庫中的組件必須經過品質的審核。
總之，解決以上問題的方法就是採用組件庫管理系統和軟體重用的觀念以提高軟體的開發速度和品質。
- 開發組件庫管理系統迫在眉睫 關於組件庫管理系統的開發建議，詳見技術人生之我的碩士論文。
中國軟體業已經錯過獨立開發作業系統的年代，又錯過獨立開發資料庫的年代，不能再錯過軟體重用的年代。
