軟件開發(fā)過程中的常見問題及對策

1、軟件開發(fā)過程中的常見問題及對策正確的理解和管理需求及其變更問題 1: 從項目的需求搜集開始，業(yè)務(wù)專家搜集和提出基于整個業(yè)務(wù)的需求體 系，但是 在從初始的需求轉(zhuǎn)化為軟件特性和功能的過程中， 由于業(yè)務(wù)專家和技術(shù) 人員的溝通不充 分或者需求描述不完善，導(dǎo)致技術(shù)人員對需求的理解產(chǎn)生曲解， 從而影響該軟件完成后不 符合用戶提出的真實需求。項目組 在了 需求 來源不清 度，導(dǎo)致一些混問題 2: 從初始的業(yè)務(wù)需求轉(zhuǎn)化為軟件特性的過程中，缺乏有效的跟蹤和管理， 導(dǎo)致軟 件功能特性與用戶需求脫節(jié)。在任何一個 軟件開 花比較多的時間 重要的。這會減少大量 避免這種問題 3: 在項目過程中， 用戶提出改進(jìn)的需求或者

2、增加軟件功能和特性， 解需求后， 對軟件架構(gòu)進(jìn)行調(diào)整或者重構(gòu)， 但是如此頻繁的重復(fù)下來， 楚， 軟件規(guī)格書未反應(yīng)需求變化， 或者接受需求但未調(diào)整項目的整體進(jìn) 亂情況的發(fā)生。上述 1，2 個問題其實都是對需求跟蹤和管理機(jī)制的不完善引起的。 發(fā)過程中，都充分地強(qiáng)調(diào)了需求管理的重要性。因此，在項目初期，相對 做需求的搜集和跟蹤， 完善業(yè)務(wù)人員和技術(shù)人員的溝通機(jī)制是很 的由于曲解需求導(dǎo)致軟件不符合用戶需求從而返工造成的 人力和物力的浪費。情況產(chǎn)生的一種方式是， 在項目立項后， 由專人或 專門的團(tuán)隊 （這些人必須是了解該 項目業(yè)務(wù)領(lǐng)域的知識，并且有相關(guān)的技術(shù)經(jīng)驗 ） 搜集該項目的原始需求，然后和技術(shù)專家

3、 （或團(tuán)隊 ） 進(jìn)行充分的溝通和討論，保證 技術(shù) 專家對原始需求乃至一些用戶要求的細(xì)節(jié)有完整而正確的理解， 接著技術(shù)專 家就會根據(jù) 原始需求的文檔， 根據(jù)對需求的理解撰寫軟件規(guī)格書， 在寫的過程中， 應(yīng)該不斷讓業(yè)務(wù) 專家一定程度的參與 （例如審稿或一定程度的修訂，并且參與評 審） ，這樣的軟件規(guī)格 書才能為進(jìn)一步正確地進(jìn)行軟件分析設(shè)計提供素材和指導(dǎo)。對第 3 個問題，用戶提出的對軟件進(jìn)行改進(jìn)可能是經(jīng)常有的事情，遇到這種情 況，有兩 種處理辦法。一種辦法是用戶提出的改進(jìn)建議在下一個發(fā)布版本中實現(xiàn)。 但是用戶往往要 求能夠在當(dāng)前版本中進(jìn)行實現(xiàn)。 第二種辦法就是認(rèn)真考慮用戶用 戶的建議，用各種方法

4、來滿足用戶的需求，其中包括系統(tǒng)重構(gòu)。在這些過程中， 可能會造成一些混亂。 其實歸 根結(jié)底還是需求的跟蹤機(jī)制不完善引起的。 建議采 用需求和變更跟蹤工具 （ 比如 rational clearquest 來對需求和變更進(jìn)行全過程的跟 蹤，這樣在形成需求文檔的時候， 每個需求來源和其狀態(tài)都是非常清楚的。配置管理 配置管理占據(jù)了越來越重要的角色，對文檔，圖形，代碼和各種項目數(shù)據(jù)進(jìn)行 分類管理，并對不同的人擁有的權(quán)限進(jìn)行控制， 方便技術(shù)人員對其負(fù)責(zé)的配置項 進(jìn)行創(chuàng) 建，提交和修改， 提高項目整體的運(yùn)作效率。 但是在配置管理中也存在著 一些問題：問題 1: 沒有制定好 文檔 ，圖形，代碼應(yīng)放的位置，配置

5、項命名比較隨意，無 權(quán)限控 制，造成各配置項存放混亂，尋找不易。問題 2: 培訓(xùn)和支持不充分， 對配置管理工具的用法不了解。 目前配置管理工具 很 多，比如大家常用的 vss, 可能相對比較熟悉一些。但是諸如 CVS和 ClearCase 等工具， 由于軟件功能非常復(fù)雜， 并且對國內(nèi)用戶來說易用性比較差， 雖然功能 強(qiáng)大，但是沒有 真正派上用場。對第一個問題，在小型項目中可能尚不明顯，但是在大型項目中，由于各種文 檔，代碼 等非常多，如果不能進(jìn)行正確的配置管理，很有可能被弄得一團(tuán)糟。因 此，在項目啟動 后， 經(jīng)過技術(shù)人員之間的討論， 在配置項的命名規(guī)定， 目錄結(jié)構(gòu)， 存放位置等達(dá)成共 識， 因

6、為這些在具體使用上還和開發(fā)工具， 開發(fā)語言等是密切 相關(guān)的，在討論的時候也 應(yīng)充分考慮這些因素， 給技術(shù)人員在使用它們的時候提 供最大的便利。當(dāng)然，為了安全起見，大型項目中，權(quán)限的控制也是很重要的。 另外，在一些情況下，如果沒有權(quán)限控 制，項目成員可以隨意修改其它文件，這 樣可能會導(dǎo)致一些混亂情況的發(fā)生。第二個問題，對 ClearCase 等大型的配置管理工具，如果不作充分的研究和大 量的培 訓(xùn)， 對軟件配置和使用不當(dāng)， 缺乏對組織內(nèi)人員的統(tǒng)一培訓(xùn)， 因為配置管 理工具是幾 乎每個人都會用到的，這樣造成的問題會相當(dāng)多。在 ClearCase 中， 比如基線的概念， 可能很多人都不甚了解， 還有

7、動態(tài)視圖， 靜態(tài)視圖，集成視圖， 流 等，這些如果不能做充分而細(xì)致的培訓(xùn)， 技術(shù)人員會感到相當(dāng)?shù)睦Щ螅?如果支 持不到位 或在使用中的問題無法解決，會造成項目進(jìn)度的延遲乃至停滯。所以， 在對待此類問題 上， 培訓(xùn)和支持的工作是必不可少的， 雖然可能會在初期浪費一 些資源，但是磨刀不誤 砍柴功， 組織內(nèi)人員都掌握了強(qiáng)大工具的使用方法， 將會 極大地提高開發(fā)效率和節(jié)省時 間。文檔 國內(nèi)進(jìn)行軟件開發(fā)從最初的完全不重視文檔，到后來吸取無數(shù)的經(jīng)驗教訓(xùn)后， 對文 檔的重視又被提高到前所未有的地步。 但是不少公司對應(yīng)該寫多少文檔， 怎 么寫文檔不 能把握好， 因為技術(shù)人員往往對文檔方面的任務(wù)是抵觸的， 認(rèn)為

8、不如 多抽點時間專注在 技術(shù)方面， 寫文檔純粹是浪費時間。 但是文檔卻是必不可少的， 應(yīng)該怎樣處理好這種矛 盾呢 ? 事實上，這種矛盾天生就是難以化解的， 因為技術(shù) 人員對技術(shù)和相關(guān)情況最了 解， 其它人很難撰寫這些文檔， 項目經(jīng)理所需要做的 是，通過斟密的項目進(jìn)度安排，給 技術(shù)人員留出一些時間來書寫文檔（ 在工作時間而不是在加班時間里完成，否則難免會有怨言的 ），并在規(guī)定的進(jìn)度下進(jìn)行評 審。在 Rup和 Xp 中，對文檔的看法有些不一樣。在 RUP中，對文檔非常的重 視，每個階段都有 一些工件是必須要評審和交付的， 其中除了代碼外， 絕大部分 都是文檔，寫起來相當(dāng)費 時費力。而在 XP流程中

9、，強(qiáng)調(diào)的是通過代碼和面對面 的溝通，來加強(qiáng)團(tuán)隊的協(xié)作性， 文 檔除了一些設(shè)計性和需要保留的資源需要撰寫 外，只是起到一些輔助性的作用。但不管怎 樣，重要和必要的文檔總是要寫的。 讓每個技術(shù)人員了解文檔的重要性， 合理的分配和 預(yù)留寫文檔的時間， 都是可以 一定程度上化解矛盾的做法。如何保持工件的一致性 （同步 ）在軟件開發(fā)過程中， 不斷有新的工件產(chǎn)生， 而且有些工件隨著一些變更的發(fā)生， 就需 要進(jìn)行更新， 但工件數(shù)量太多， 一則維護(hù)更新不容易， 另外有些工件只是項 目結(jié)束后 參考性的資源， 立即更新也不必要， 求大求全則會一定程度上占用項目 資源，耽誤進(jìn) 度。因此，一個建設(shè)性的建議就是，對必要

10、的工件，如 需求規(guī)格 書，產(chǎn)品定義書，概要 設(shè)計書，詳細(xì)設(shè)計書 等工件是一定要根據(jù)項目和評審情況立即進(jìn)行修訂和更新的， 但是，對另外一些衍生的工件， 如用戶指南等工件， 雖然 在開發(fā)流程中， 可能是在每個階段都必要寫的， 但是卻可以在評審進(jìn)行前集 中進(jìn)行更新 一些，避免頻繁修訂造成的資源占用和進(jìn)度延遲。重視風(fēng)險管理 建立風(fēng)險管理體系，讓風(fēng)險意識貫穿整個流程體系，對不斷出現(xiàn)的可能的 風(fēng)險 進(jìn)行預(yù)測， 分析和討論對策， 劃分風(fēng)險級別， 采用各種方法來降低風(fēng)險變成現(xiàn)實 后對整個項目所造成的損失。風(fēng)險管理體系是一個項目預(yù)防可能潛在風(fēng)險的一個很好的保障方式，在項目初 期，根據(jù) 項目情況如資金， 人員和可

11、能的進(jìn)度對整個項目的風(fēng)險作一個預(yù)先的評 估，采用的方式 可以是以項目經(jīng)理為中心， 集體討論的形式來進(jìn)行。 在討論結(jié)束 后形成一份 risk list ，項目經(jīng)理經(jīng)理應(yīng)該不斷組織一些專題會議，由此整理出一份文檔， 即風(fēng)險管理文檔。 在項目進(jìn)行當(dāng)中， 隨著情況不斷變化， 項目 對風(fēng)險進(jìn)行討論， 并統(tǒng)一對策。 這樣在風(fēng) 險變成現(xiàn) 實后， 整個項目組不至于束手無策， 而是可以采取一些補(bǔ)救的措施來把 風(fēng)險可能造成的 損失降到最低。關(guān)于周報和月報 在很多公司中，都要求開發(fā)人員填寫周報和月報，以便在項目周會，月 總結(jié)上 了解每個人任務(wù)的進(jìn)展情況和對人員進(jìn)行考核。 但是技術(shù)人員總是對此類工作不 勝其煩，往往敷

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