1、軟件開發過程中的常見問題及對策正確的理解和管理需求及其變更問題1:從項目的需求搜集開始，業務專家搜集和提出基于整個業務的需求體系，但是在從初始的需求轉化為軟件特性和功能的過程中，由于業務專家和技術人員的溝通不充分或者需求描述不完善，導致技術人員對需求的理解產生曲解，從而影響該軟件完成后不符合用戶提出的真實需求。問題2:從初始的業務需求轉化為軟件特性的過程中，缺乏有效的跟蹤和管理，導致軟件功能特性與用戶需求脫節。問題3:在項目過程中，用戶提出改進的需求或者增加軟件功能和特性，項目組在了解需求后，對軟件架構進行調整或者重構，但是如此頻繁的重復下來，需求來源不清楚，軟件規格書未反應需求變化，或者接受

2、需求但未調整項目的整體進度，導致一些混亂情況的發生。上述1,2個問題其實都是對需求跟蹤和管理機制的不完善引起的。在任何一個軟件開發過程中，都充分地強調了需求管理的重要性。因此，在項目初期，相對花比較多的時間做需求的搜集和跟蹤，完善業務人員和技術人員的溝通機制是很重要的。這會減少大量的由于曲解需求導致軟件不符合用戶需求從而返工造成的人力和物力的浪費。避免這種情況產生的一種方式是，在項目立項后，由專人或專門的團隊（這些人必須是了解該項目業務領域白知識，并且有相關的技術經驗）搜集該項目的原始需求，然后和技術專家（或團隊）進行充分的溝通和討論，保證技術專家對原始需求乃至一些用戶要求的細節有完整而正確的

3、理解，接著技術專家就會根據原始需求的文檔，根據對需求的理解撰寫軟件規格書，在寫的過程中，應該不斷讓業務專家一定程度的參與（例如審稿或一定程度的修訂，并且參與評審），這樣的軟件規格書才能為進一步正確地進行軟件分析設計提供素材和指導。對第3個問題，用戶提出的對軟件進行改進可能是經常有的事情，遇到這種情況，有兩種處理辦法。一種辦法是用戶提出的改進建議在下一個發布版本中實現。但是用戶往往要求能夠在當前版本中進行實現。第二種辦法就是認真考慮用戶用戶的建議，用各種方法來滿足用戶的需求，其中包括系統重構。在這些過程中，可能會造成一些混亂。其實歸根結底還是需求的跟蹤機制不完善引起的。建議采用需求和變更跟蹤工具

4、（比如rationalclearquest球對需求和變更進行全過程的跟蹤，這樣在形成需求文檔的時候，每個需求來源和其狀態都是非常清楚的。配置管理配置管理占據了越來越重要的角色，對文檔，圖形，代碼和各種項目數據進行分類管理，并對不同的人擁有的權限進行控制，方便技術人員對其負責的配置項進行創建，提交和修改，提高項目整體的運作效率。但是在配置管理中也存在著一些問題：問題1:沒有制定好文檔，圖形，代碼應放的位置，配置項命名比較隨意，無權限控制，造成各配置項存放混亂，尋找不易。問題2:培訓和支持不充分，對配置管理工具的用法不了解。目前配置管理工具很多，比如大家常用的vss,可能相對比較熟悉一些。但是諸如

5、CVS和ClearCase等工具，由于軟件功能非常復雜，并且對國內用戶來說易用性比較差，雖然功能強大，但是沒有真正派上用場。對第一個問題，在小型項目中可能尚不明顯，但是在大型項目中，由于各種文檔，代碼等非常多，如果不能進行正確的配置管理，很有可能被弄得一團糟。因此，在項目啟動后，經過技術人員之間的討論，在配置項的命名規定，目錄結構，存放位置等達成共識，因為這些在具體使用上還和開發工具，開發語言等是密切相關的，在討論的時候也應充分考慮這些因素，給技術人員在使用它們的時候提供最大的便利。當然，為了安全起見，大型項目中，權限的控制也是很重要的。另外，在一些情況下，如果沒有權限控制，項目成員可以隨意修

6、改其它文件，這樣可能會導致一些混亂情況的發生。第二個問題，對ClearCase等大型的配置管理工具，如果不作充分的研究和大量的培訓，對軟件配置和使用不當，缺乏對組織內人員的統一培訓，因為配置管理工具是幾乎每個人都會用到的，這樣造成的問題會相當多。在ClearCase中，比如基線的概念，可能很多人都不甚了解，還有動態視圖，靜態視圖，集成視圖，流等，這些如果不能做充分而細致的培訓，技術人員會感到相當的困惑，如果支持不到位或在使用中的問題無法解決，會造成項目進度的延遲乃至停滯。所以，在對待此類問題上，培訓和支持的工作是必不可少的，雖然可能會在初期浪費一些資源，但是磨刀不誤砍柴功，組織內人員都掌握了強

7、大工具的使用方法，將會極大地提高開發效率和節省時間。0文檔國內進行軟件開發從最初的完全不重視文檔，到后來吸取無數的經驗教訓后，對文檔的重視又被提高到前所未有的地步。但是不少公司對應該寫多少文檔，怎么寫文檔不能把握好，因為技術人員往往對文檔方面的任務是抵觸的，認為不如多抽點時間專注在技術方面，寫文檔純粹是浪費時間。但是文檔卻是必不可少的，應該怎樣處理好這種矛盾呢？事實上，這種矛盾天生就是難以化解的，因為技術人員對技術和相關情況最了解，其它人很難撰寫這些文檔，項目經理所需要做的是，通過斟密的項目進度安排，給技術人員留出一些時間來書寫文檔（在工作時問而不是在加班時間里完成，否則難免會有怨言的），并在

8、規定的進度下進行評審。在Rup和Xp中，對文檔的看法有些不一樣。在RUP中，對文檔非常的重視，每個階段都有一些工件是必須要評審和交付的，其中除了代碼外，絕大部分都是文檔，寫起來相當費時費力。而在XP流程中，強調的是通過代碼和面對面的溝通，來加強團隊的協作性，文檔除了一些設計性和需要保留的資源需要撰寫外，只是起到一些輔助性的作用。但不管怎樣，重要和必要的文檔總是要寫的。讓每個技術人員了解文檔的重要性，合理的分配和預留寫文檔的時間，都是可以一定程度上化解矛盾的做法。如何保持工件的一致性（同步）在軟件開發過程中，不斷有新的工件產生，而且有些工件隨著一些變更的發生，就需要進行更新，但工件數量太多，一則

9、維護更新不容易，另外有些工件只是項目結束后參考性的資源，立即更新也不必要，求大求全則會一定程度上占用項目資源，耽誤進度。因此，一個建設性的建議就是，對必要的工件，如需求規格書，產品定義書，概要設計書，詳細設計書.等工件是一定要根據項目和評審情況立即進行修訂和更新的，但是，對另外一些衍生的工件，如用戶指南等工件，雖然在開發流程中，可能是在每個階段都必要寫的，但是卻可以在評審進行前集中進行更新一些，避免頻繁修訂造成的資源占用和進度延遲。重視風險管理建立風險管理體系，讓風險意識貫穿整個流程體系，對不斷出現的可能的風險進行預測，分析和討論對策，劃分風險級別，采用各種方法來降低風險變成現實后對整個項目所

10、造成的損失。風險管理體系是一個項目預防可能潛在風險的一個很好的保障方式，在項目初期，根據項目情況如資金，人員和可能的進度對整個項目的風險作一個預先的評估，采用的方式可以是以項目經理為中心，集體討論的形式來進行。在討論結束后形成一份risklist,項目經理由此整理出一份文檔，即風險管理文檔。在項目進行當中，隨著情況不斷變化，項目經理應該不斷組織一些專題會議，對風險進行討論，并統一對策。這樣在風險變成現實后，整個項目組不至于束手無策，而是可以采取一些補救的措施來把風險可能造成的損失降到最低。關于周報和月報在很多公司中，都要求開發人員填寫周報和月報，以便在項目周會，月總結上了解每個人任務的進展情況

11、和對人員進行考核。但是技術人員總是對此類工作不勝其煩，往往敷衍了事，填幾個比較大的任務（如開發XX系統等），而且一連幾周都是如此，這樣對了解項目進展和對人員考核的參考作用就失去了意義。雖然技術人員比較反感寫這類東西，但是還是必須要寫的。應該怎樣化解此類矛盾呢？實際上，這類任務主要是人的因素在發揮作用。要想達到有效性的目的，對項目成員進行一定程度的指導和培訓是必要的。例如，一種比較好的方法就是，可以推薦項目成員進行dailyplan一類每日計劃的編寫，每個人對每日工作任務進行劃分和規劃時間，然后在每日工作結束后對預先計劃和完成情況進行對比，并在下一個工作日進行改進。堅持下去，項目成員必然在工作計劃和完成情況問越來越接近，養成良好的習慣，這樣不僅在保障進度上人的正面因素可以被大大增強，而且在編寫周報和月報時就有所依據而不是匆匆了事，能夠發揮應有的效果。了解培訓的重要性在各類組織中，都會對員工進行一定程度的培訓。在項目立項過程中，就應該考慮人員配備情況。比較理想的情況當然是項目組每個成員都對該項目的技術了如指掌，對軟件開發流程比較了解，相互之間能夠進行充分的溝通，能充分理解溝通對象的意圖等等。但是理想