1、1.閱讀全部的CMM內容，選擇出你認為最有價值的十條關鍵實踐，并說明理由。（1）項目軟件負責人，設計/編程/測試人員、軟件版本管理員均已得到相應的培訓，具備了完成其職責所需要的知識和技能。理由：通過培訓，工作人員具有了一定的知識儲備，遇到困難能夠很快找到相應的解決措施，就可以很快上手，不至于在一個問題上耽誤太多時間。因此，為了達到統一的科學技術規范、標準化作業，通過目標規劃設定、知識和信息傳遞、技能熟練而進行培訓是十分必要的，這樣能減少所需工作時間，提高成員的開發能力和創新能力，從而降低人力成本；減少浪費，從而降低了開發成本。因此，參加培訓是十分必須的。（2）根據項目要求，建立軟件有關組（例如

2、工程組、軟件測試組等）。理由：通過建立相關組，各組可以各施其職，同步工作，提高工作效率。因為軟件開發時不可能一個人兼顧所有的方面，應該分成幾個模塊，只做好自己的然后和其他組協調就可以。如專人負責技術方案設計，專人負責數據，專人做技術層面的指導等。這樣權責分明，遇到問題能夠很快找到相應的負責組，解決問題的時間也將大大減少。 （3）確定設計、編程、測試人員，并實施三分離。理由：實現了三分離可以更加開闊人員的思維，防止由于思路固定而不能及時發現問題，更有助于激發員工的創新思維，使軟件更先進，更經得起考驗。贊同（4）根據項目軟件的質量需要確定本項目所采用的軟件開發方法。理由：確定好軟件開發所采用的開發

3、方法，就能盡早的做下步計劃，不至于到最后為選擇開發方法而浪費太多時間。目前已形成了八類軟件開發方法，開發時是選擇面向數據結構的開發方法還是面向對象的開發方法，直接會影響到小組的開發進度。要根據成員的擅長情況制定方法。 （5）軟件版本管理員，以及設計、編程、測試人員的職責明確。理由: 權責分明，遇到問題追究到人，會使項目開發更有計劃。完善制度，將責任明確到人，這樣才能明確目標，將工作細化，使成員做好自己的工作，認識到重要性，使開發過程能高效的進行。（6）制定正式評審規程、建立相應的評審機構。理由：項目評審工作就是對項目計劃執行情況以及未來計劃的新情況做一個評審，同時對項目的財務狀況及其它情況做一

4、個總結。另外，它可以為項目團隊在處理項目風險時提供機會，以獲得管理層的支持，同時也為項目團隊繼續開展項目工作提供在高層管理方面的認可。（7）根據項目實際情況，選定本項目應遵循的軟件過程標準、規范。理由：如果一個團隊中有了統一的過程，那么，大家的行為就會符合規范，從而提高團隊的整體能力。如果一個團隊缺乏執行規范化過程的活動，就會導致整個組織的混亂。為了消除軟件過程所常見的問題，建立軟件過程規范是必要的。軟件過程規范可以確保過程活動的一致性、有效性和持續性。（8）任命項目負責人。理由：項目負責人除了調配好小組成員，運用專業知識做整體質量的導向，控制項目的進度以外，還要與用戶協調，利用周邊人力資源做

5、項目規劃的流程安排，項目負責人要及時的發現程序開發中的困難和障礙，并且努力的及早的解決。一個項目從開始運作到最后完成，不論是合同的簽定、還是人員的調配、還是執行的安排，處處隱藏著不可預見的漏洞，因此需要項目負責人全局的掌控思維和能力。 （9）具有各階段活動所需要的軟/硬件環境、支持工具，并提供足夠的經費。理由：只有硬件基礎具備了，才能形成一個好的開發環境，同時經費也是基礎，要合理的制定經費計劃，保證開發過程順利進行。要做好軟件開發成本估算，這樣才能合理的開發。（10）項目軟件負責的職責明確。理由：責任是管理的基礎，明確了職責，才能使成員更加認真的做好自己的本職工作，同時將責任細分，在出問題后也

6、可以責任到人。2.軟件配置管理主要包括哪些？請詳細說明。（1）配置管理過程軟件配置管理（SCM）簡單而言就是管理軟件的變化。它屬于軟件工程過程，通常由相應的工具、過程和方法學組成。在整個過程管理的活動中占有很重要的位置。IEEE“軟件配置管理計劃標準”關于SCM論述如下。軟件配置管理由適用于所有軟件開發項目的最佳工程實踐組成，無論是采用分階段開發，還是采用快速原型進行開發，甚至包括對現有軟件產品進行維護。SCM通過以下手段來提高軟件的可靠性和質量。1）在整個軟件的生命周期中提供標識和控制文檔、源代碼、接口定義和數據庫等工件的機制。2）提供滿足需求、符合標準、適合項目管理及其他組織策略的軟件開發

7、和維護的方法學。3）為管理和產品發布提供支持信息，如基線的狀態、變更控制、測試、發布和審計等。軟件配置管理貫穿于項目的整個軟件過程中，與項目過程行為密不可分。一方面，對于在軟件過程中所產生的工作產品或變更請求通過配置管理活動進行管理，將有效的信息存儲在配置管理庫中。另一方面，項目人員可依賴配置管理活動獲取配置項的有效版本和歷史信息。軟件配置控制是軟件配置管理的核心工作。軟件配置控制主要包括對軟件的存取控制、版本控制、變更控制和產品發布等4個方面。（2）基線控制在軟件開發過程中，由于各種原因，可能需要變動需求、預算、進度和設計方案等，盡管這些變動請求中絕大部分是合理的，但在不同的時機做不同的變動

8、，其難易程度和造成影響差別比較大，為了有效的控制變動，軟件配置管理引入基線的概念。簡單地說，基線就是項目存儲庫中每個工件版本在特定時期的一個“快照”，它提供一個正式標志，隨后的工作基于這個標志進行，并且只有經過授權后才能變更這個標志。建立一個初始基線后，以后每次對它進行的變更都將記錄一個差值，直到建成下一個基線。基線是軟件生命期各階段末尾的特定點，也稱為里程碑。在這些特定點上，階段工作已結束，并且已經取得了正式的階段性產品。建立基線的概念是為了把各個階段的工作劃分的更加明確，使得本來連續開展的軟件工作在這些點上被割開，從而更加有利于檢驗和肯定階段性的成果。同時也有利于變更控制。有了基線的規定后

9、，就可以禁止跨越里程碑去修改另一階段“已凍結”的工作成果。就各種不同類型的基線而言，有一條較為特殊的基線，它是軟件過程中的第一條基線。它包含通過評審的軟件需求，因此稱之為“需求基線”。通過建立這樣一個基線，受控的系統需求成為進一步軟件開發的出發點，對需求基線的變更請求將受到慎重的評估和嚴格的控制。受控的需求還是對軟件進行功能評審的基礎。需求基線是整個軟件生命周期的起點和終結點。（3）版本控制版本控制是對系統不同版本進行標識和跟蹤的過程，是實行軟件配置管理的基礎，也是所有配置管理系統的核心功能。配置管理系統的其他功能大都建立在版本控制功能之上。版本控制主要分為版本的訪問與同步控制、版本的分支和合

10、并。1）版本的訪問和同步：一般來說，不同的工作空間是由不同的目錄來表示的，而對工作空間的訪問是由文件系統提供的文件訪問權限來加以控制的。版本的訪問控制：工作區域中的源文件是從庫中恢復得到的一個副本，該副本可以是“可寫”的，也可以是“可讀”的。對于“可寫”的副本來說，它就是真正的工作文件。而對于“可讀”的副本，它可以被視為軟件庫中源文件的一個緩沖副本，此時一般有兩種工作模式。在工作區域一旦有“讀”請求，則作一次恢復操作，獲得一個副本。當“讀”操作結束后，該副本被刪除。這樣就形成一種重復恢復，從而可以保證工作區域中的文件內容被更新為與軟件庫中的內容一致。針對上一種模式中重復恢復引起的較大時間代價，

11、不是每次“讀”操作都要求與軟件庫中發生交互，而是將重點放在工作區域上，僅當軟件庫中的內容發生更改時，才發生交互。版本同步控制：同步控制實際上是版本的檢入檢出控制。2）版本的分支和合并：版本分支的人工方法就是從主版本-稱為主干上復制的一份，并做上標記。在實行了版本控制之后，版本的分支也是一份復制，這時的復制過程和標記動作由版本控制系統自動完成。對于合并，在沒有版本控制的時候，一般是通過文件的比較來進行合并。在實行了版本控制之后，還是要通過文件的比較來進行合并，但是這時的比較工作可以由版本比較工具自動進行合并，自動合并后的結果需要人工檢查，才有很高的可靠性。 （4）變更控制在軟件過程中要產生許多變

12、更，比如配置項、配置、基線、構建的版本和發布版本等。對于所有的變更，都要有一個控制機制，以保證所有變更都是可控的、可跟蹤的和可重現的。為了有效地進行變更控制，需要規范相應的變更控制流程，變更控制流程主要分為7個階段，變更請求提交、接受、評估、決策、實現、驗證和完成。3.如何綜合運用過程管理的工具？ 在軟件過程活動中，要經歷不同的階段和涉及很多的過程域，為了有效的執行這些軟件過程活動，需要在整個軟件開發過程中引入相關工具。一般來說，實施軟件過程活動所需要的工具主要有下面幾種。l 需求管理工具l 面向對象的分析設計工具l 配置管理、變更管理工具l 軟件測試管理、缺陷跟蹤工具(1)需求管理工具一個優

13、秀的需求管理工具，可以有效地管理需求，提高需求管理工作流程的自動化程度，在項目實施中完整的、一致的管理好需求。IBM-Rational AnalystStudio：IBM-Rational AnalystStudio可以幫助更好地分析問題，更好地定義并交流問題的解決方案，用于可視化建模、需求和用例管理以及缺陷和變更請求跟蹤等。Telelogic DOORS：Telelogic DOORS-Enterprise Requirements Suite（DOORS/ERS）是基于整個軟件組織的需求管理系統，用來捕捉、鏈接、跟蹤、分析及管理信息，以確保項目與特定的需求及標準保持一致。DOORS/ERS

14、提供多種工具與方法對需求進行管理，可以靈活地融合到組織的軟件過程管理中。Borland Caliber：Borland Caliber是一個基于Web和用于協作的需求定義和管理工具，可以幫助分布式的開發團隊平滑協作，從而加速交付應用系統。Caliber輔助團隊成員溝通，有助于更好地理解和控制項目，較少錯誤和提升項目質量。(2)面向對象的分析設計工具IBM-Rational Rose是面向對象技術分析設計工具的代表，是可視化的建模工具。它采用“統一建模語言（UML）”的表示方法，在同一個模型中實現業務建模、對象建模和數據建模，使所有參與項目的成員都可以在統一的語言環境中工作于同一個模型之上，有利

15、于改善成員之間的溝通。其次，IBM-Rational Rose支持多種語言的代碼生成及雙向工程，可實現代碼和模型的互相轉換，并且可以將遺留代碼引入模型中。最后，IBM-Rational Rose帶有對設計元素進行測試的模塊工具，可以盡早發現設計中的問題，真正實現“質量從頭抓起”。(3)配置管理和變更管理工具在CMM標準中，明確規定了軟件配置管理以及變更請求管理的相關工作，主要包括以下兩方面。1）配置管理的主要工作包括通過創建軟件配置管理庫、定義配置項以及建立和維護軟件的基線。2）變更請求管理的主要工作包括控制和記錄配置項內容的變更，建立和維護一個系統并使其追蹤和管理變更請求及問題報告。常用的軟

16、件配置管理工具有國內青鳥軟件的JBCM、IBM-Rational的ClearCase和開源工具CVS。4.通過一個案例，說明一下如何運用IPD提高產品集成的質量。華為是國內第一家引進和實施IPD的公司，也是受益最大的國內企業。華為的IPD可以分為兩個大的階段，這兩個階段的效果有明顯差別；在IBM為華為提供IPD咨詢后，華為的IPD取得了巨大成功。（1）實施背景實施IPD之前，華為每年將銷售額的10%投入產品開發，但是研發費用浪費比例和產品開發周期仍然是業界最佳水平的兩倍以上。華為銷售額雖然連年增長，但產品的毛利率卻逐年下降，人均效益只有思科、IBM等企業的1/3-1/6。 產品開發流程處于企業

17、價值鏈最上游，這里出現的問題通過生產制造、銷售、交付、售后服務等下游環節會產生若干倍的放大。在分析采購業務系統時，華為就發現很多問題的根本出在產品開發過程中。因此，從產品開發入手，解決產品開發這一源頭上的問題，是提高產品投資收益和解決公司系統性問題的治本之舉。華為花巨資引進IPD，就是希望通過變革產品開發模式，縮短產品上市時間，降低費用，提升產品質量，最終能夠提高產品的盈利能力。IBM的專家認為，華為在產品研發方面的主要問題是概念與計劃階段合并在一起，研發活動缺乏計劃性和嚴格的評審。以前，華為經常是基本上沒有業務計劃，甚至在高層指示下就直接開始了開發。這導致產品與技術的開發重合，最后導致實用產

18、品遲遲推不出來。華為以前的評審往往是技術型而不是業務型，主要依靠主觀判斷來分析市場需求。由于評審和決策僅僅是出于主觀判斷，沒有符合市場需求的標準，結果造成產品不斷修改。（2）實施過程華為的IPD經過了兩個階段。第一階段從1998年初開始。當時華為開始自己摸索實施IPD，組織了項目組(主要由一批MBA構成)，拿出了一套基于IPD的研發體系變革方案，并進行了推廣實施。但這次IPD變革效果并不像人們預期的那樣，基本上是一次失敗的嘗試。后來華為經過分析決定請IBM作為咨詢方來幫助解決問題。華為在IBM的幫助下實施IPD是從1998年開始起步的。當年，由IBM為華為實施IPD提供咨詢，打破了華為以部門為

19、管理結構的模式，轉向以業務流程和生產線為核心的管理模式。僅此一項華為付給IBM的咨詢費達到了數千萬美元。根據IBM咨詢的方法論，華為IPD項目劃分為關注、發明和推行三個階段。在關注階段，進行了大量的“松土”工作，即在調研診斷的基礎上，進行反復的培訓、研討和溝通，使相關部門和人員真正理解IPD的思想和方法。發明階段的主要任務是方案的設計和選取三個試點PDT，按IPD進行運作。推廣階段是逐步推進的，先在50%的項目中推廣，然后擴大到80%的項目，最后推廣到所有項目。華為的IPD在剛開始起步時，各個產品的研發在組織架構上已經基本形成了PDT的雛形，各種計劃、文檔、研發活動也是按IPD的模式進行。但在

20、這個時期，只有華為與IBM配合成立的IPD項目組里的人對IPD有較為明確的理解。當時研發流程用的是所謂IPD1.0，IPD的實際效用沒有完全發揮出來。公司內部只是在研發活動的稱謂以及重要文檔的輸出上模仿PDT1.0流程的規定。IPD的核心組決策，IPMT的決策評審等關鍵措施并沒有施行，只是在兩個產品線上作試點。這個過程持續到了2001年，從2001年開始，華為規定，公司內30%的產品線必須嚴格按照IPD2.0流程運作，其他產品線繼續按照IPD1.0流程運行。2002年華為規定，到年底所有產品線必須完全按照PDT2.0的流程運作。此時，支撐PDT流程的相關人事制度，財務制度，以及績效考核制度等都

21、已建立起來。同時，華為公司從高層領導到基層產品研發管理者都對PDT的思想和流程有了比較清晰深入的認識，因此已經具備全面推行PDT的客觀條件。至2003年，華為的IPD已經從1.0版本升級到了3.0版本。（3）華為IPD構成華為的IPD主要由以下幾個部分組成：1）固化的結構化研發流程2）支持流程實施的跨部門團隊以前華為的產品開發完全是研發部門的事情，技術方向由關鍵人物來選擇。在IPD模式下，各部門都要有人參與到規劃和實施的過程里，組成跨部門的團隊IPMT與PDT(IPT)。跨部門的團隊基本上要在產品開發之前做出相關聯的規劃，并且在產品開發的過程中相互協調，以保證這個產品從始至終都是技術領先、成本

22、合理并且符合市場需求。華為共有約一百多個產品線，類似的產品線再一起組成一個大的產品線。每個大的研發產品線都有一個IPMT，他們是由總監級(現在改為產品線總裁)或者資深的產品專家組成，負責對旗下各個產品線的研發活動作關鍵環節(立項評估，計劃決策，實驗局評估等)的監控和評估。監控和評估的主要依據就是看這個產品研發成本投入和未來市場效益的比較，以及技術、資金、人力等方面的可行性。決策評審點：決策評審點實際上是一種喇叭口的結構。也就是通過仔細的調查、研究和分析之后篩選出最有潛力的項目，并且在“動手”之前盡可能地進行“瞄準”和計算“提前量”。使得最后進入開發階段的項目都是最健康和最明確的。應該說這種研發管道管理，是華為在以前最欠缺的。異步開發模式：IPD在開發過程中為華為第一次引進了“異步開發”的概念。這種流程實際上很好地使用了并行工程的思想，它比華為原來串行研發流程的效率要高很多。（4）實施成效華為IPD的實踐表明，IPD能夠加快產品開發速度，縮短產品上市時間，減少產品開發的投資失敗從而減少浪費，降低產品開發成本，增加收入，給客戶提供價廉物美的產品。 總的來說，IPD實施幾年來，華為逐漸建立起世界級的研發管理體系，形成了世界級的研發能力，優化了公司的整體運行，取得了明顯成效。5.針對一個過程管理模型（RUP,MSF,XP或者是面向