軟件開發(fā)過程中的常見問題及對策_第1頁
軟件開發(fā)過程中的常見問題及對策_第2頁
軟件開發(fā)過程中的常見問題及對策_第3頁
全文預(yù)覽已結(jié)束

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

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

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

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

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

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

6、沒有權(quán)限控制,項目成員可以隨意修改其它文件,這樣可能會導致一些混亂情況的發(fā)生。 第二個問題,對ClearCase等大型的配置管理工具,如果不作充分的研究和大量的培訓,對軟件配置和使用不當,缺乏對組織內(nèi)人員的統(tǒng)一培訓,因為配置管理工具是幾乎每個人都會用到的,這樣造成的問題會相當多。在ClearCase中,比如基線的概念,可能很多人都不甚了解,還有動態(tài)視圖,靜態(tài)視圖,集成視圖,流等,這些如果不能做充分而細致的培訓,技術(shù)人員會感到相當?shù)睦Щ?,如果支持不到位或在使用中的問題無法解決,會造成項目進度的延遲乃至停滯。所以,在對待此類問題上,培訓和支持的工作是必不可少的,雖然可能會在初期浪費一些資源,但是磨

7、刀不誤砍柴功,組織內(nèi)人員都掌握了強大工具的使用方法,將會極大地提高開發(fā)效率和節(jié)省時間。文檔國內(nèi)進行軟件開發(fā)從最初的完全不重視文檔,到后來吸取無數(shù)的經(jīng)驗教訓后,對文檔的重視又被提高到前所未有的地步。但是不少公司對應(yīng)該寫多少文檔,怎么寫文檔不能把握好,因為技術(shù)人員往往對文檔方面的任務(wù)是抵觸的,認為不如多抽點時間專注在技術(shù)方面,寫文檔純粹是浪費時間。但是文檔卻是必不可少的,應(yīng)該怎樣處理好這種矛盾呢? 事實上,這種矛盾天生就是難以化解的,因為技術(shù)人員對技術(shù)和相關(guān)情況最了解,其它人很難撰寫這些文檔,項目經(jīng)理所需要做的是,通過斟密的項目進度安排,給技術(shù)人員留出一些時間來書寫文檔(在工作時間而不是在加班時間

8、里完成,否則難免會有怨言的),并在規(guī)定的進度下進行評審。在Rup和Xp中,對文檔的看法有些不一樣。在RUP中,對文檔非常的重視,每個階段都有一些工件是必須要評審和交付的,其中除了代碼外,絕大部分都是文檔,寫起來相當費時費力。而在XP流程中,強調(diào)的是通過代碼和面對面的溝通,來加強團隊的協(xié)作性,文檔除了一些設(shè)計性和需要保留的資源需要撰寫外,只是起到一些輔助性的作用。但不管怎樣,重要和必要的文檔總是要寫的。讓每個技術(shù)人員了解文檔的重要性,合理的分配和預(yù)留寫文檔的時間,都是可以一定程度上化解矛盾的做法。如何保持工件的一致性(同步)在軟件開發(fā)過程中,不斷有新的工件產(chǎn)生,而且有些工件隨著一些變更的發(fā)生,就

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

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

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論