摘要:根據(jù)調(diào)查,屬于需求分析和軟件設(shè)計的錯誤和缺陷約占軟件錯誤的64%,而屬于程序代碼的錯誤僅占36%。因軟件錯誤的積累與放大效應(yīng),造成整個軟件業(yè)項目拖延的情況高達20%到60%。這些數(shù)據(jù)表明搞好需求調(diào)研分析及軟件設(shè)計是提高軟件質(zhì)量的基礎(chǔ)。以下是一些通過全面了解所有項目干系人的需求改進需求調(diào)研分析效果的體會。
關(guān)鍵字:項目干系人、需求、調(diào)研
在需求調(diào)研分析階段,項目組對客戶的整體組織結(jié)構(gòu)、有關(guān)人員及其關(guān)系、工作職責(zé)等沒有足夠了解以致于無法得到完整需求或最終經(jīng)權(quán)威用戶代表確認的需求。由于項目經(jīng)理和需求分析員的工作問題,客戶參與程度部不高,客戶方相關(guān)責(zé)任人不明確或?qū)Ψ秶托枨筘?zé)任心不強,提出的需求具有隨意性,項目前期對需求的確認不夠積極;或者是多個用戶代表各說各話、昨是今非但同時又希望軟件盡早交付;項目后期需求變化隨意,造成項目范圍的蔓延,進度的拖延,成本的擴大。
造成上述現(xiàn)象的原因是系統(tǒng)分析人員沒有全面了解所有項目干系人的需求,并按照重要性優(yōu)先級進行權(quán)衡取舍。全面的需求來自所有項目干系人。項目干系人STAKEHOLDER也有的翻譯成利益關(guān)系人、利害關(guān)系人、利益干系人、利益共享者、涉眾,如此等等,即所有可能受到項目結(jié)果重大影響的人。項目干系人即可能是項目的受益者,也是項目的風(fēng)險承擔(dān)者,甚至有可能是項目的受害者。項目干系人的需求包含明確的和隱含的,也可以分為NEED、WANT、WISH等不同層次。
不同的干系人其愿望和追求的目標往往相差甚遠,因此對項目干系人的愿望進行平衡可能是相當(dāng)困難的事情。例如政府部門準備建設(shè)的不少對群眾辦公的信息系統(tǒng),上層管理機關(guān)往往希望能夠采集盡可能多的信息項以便對數(shù)據(jù)進行多種多樣的統(tǒng)計分析,同時為了對信息進行有效控制而增加一些審批流程;基層對外辦公的窗口則因為辦公速度的壓力希望減少信息項的輸入量;甚至有些不良的基層客戶由于害怕建立透明度高的信息系統(tǒng)會影響他們的工作考核成績而消極地應(yīng)付,即所謂反需求;而客戶的客戶(辦事群眾)則希望相關(guān)政府機構(gòu)能夠簡化工作流程,加快辦事速度;一些客戶相關(guān)的管理機構(gòu)或組織也會制定一些有關(guān)的標準規(guī)范;作為項目干系人的公司領(lǐng)導(dǎo)層也可能會提出一些技術(shù)上、接口上、環(huán)境上的需求;甚至項目組本身因為技術(shù)、資源、進度等原因,需要對一些功能進行優(yōu)先級排序和取舍。雖然不是所有人的需求都是可以滿足的,特別是消極的反需求是不能接受的,但他們的需求都是應(yīng)當(dāng)考慮全面并進行平衡的。
軟件開發(fā)項目的目的就是實現(xiàn)項目干系人的需求和愿望。如果對項目所有干系人沒有進行足夠的溝通和影響,使其盡可能地參與項目,則可能因為項目開始時項目范圍和一些具體需求不夠完整清晰,也可能因為某個項目干系人后期因為認識的變化而提出新的需求,造成工期的延長,成本的增加,甚至項目的完全失敗。因此,應(yīng)當(dāng)從項目的啟動開始,需求分析員及其項目成員就要分清項目干系人包含哪些人和組織,通過溝通協(xié)調(diào)對他們施加影響,驅(qū)動他們對項目的支持,調(diào)查并明確他們的需求和愿望,減小其對項目的阻力,以確保項目獲得成功。以下是一些有效的措施:
1、盡快熟悉項目干系人全貌
有些項目在做需求調(diào)查時,由于受進度要求等客觀因素影響,需求分析員與建設(shè)單位的技術(shù)部門交流較多,向業(yè)務(wù)管理部門和實際使用者調(diào)查不夠深入,造成軟件試用后不得不再對需求做較大調(diào)整,"從頭再來"的部分比例很高,大大超過進度要求時間。因此,熟悉項目干系人全貌是進行需求調(diào)查的第一步,也是需求調(diào)查的基礎(chǔ)。在定制開發(fā)項目的項目干系人中,最重要的是建設(shè)單位中的人事組織、業(yè)務(wù)關(guān)系。最好是能夠用組織結(jié)構(gòu)圖畫出相關(guān)單位的組織結(jié)構(gòu);用責(zé)任矩陣確定各部分的調(diào)研對象;建立調(diào)研對象通訊錄以保證調(diào)研及分析期間及時的溝通。與此同時要注意項目干系人的主次關(guān)系,以便在他們之間的需求出現(xiàn)矛盾時能夠進行合理的取舍。
熟悉建設(shè)單位內(nèi)部相關(guān)部門的業(yè)務(wù)劃分及它們之間的相互關(guān)系,為功能分析準備了必要的資料, 同時可以熟悉用戶方的各類人員,并及時進行廣泛、有效的溝通與交流。特別要與客戶方業(yè)務(wù)與技術(shù)的規(guī)劃者和實際使用者進行深入探討,收集必要的原始資料,保證需求調(diào)查的完整性、正確性。
建設(shè)單位只是項目干系人中的一部分(當(dāng)然是主要的部分),為了更好地了解項目干系人全貌,還應(yīng)當(dāng)在建設(shè)單位組織結(jié)構(gòu)圖基礎(chǔ)上全體項目干系人結(jié)構(gòu)圖,以便更好更全面地進行需求調(diào)研分析。
2、詳細描述各項業(yè)務(wù),以利于讓所有客戶確認
盡可能全面詳細地調(diào)查并且描述原有系統(tǒng)和用戶希望將來系統(tǒng)具有的各項業(yè)務(wù)的流程,并將這些業(yè)務(wù)流程文檔化后與客戶進行討論,對描述錯誤或不準確不精確的進行修改,最終讓客戶進行確認。從近年來開發(fā)的軟件看,對業(yè)務(wù)處理過程了解的完整性和準確性非常重要。雖然對數(shù)據(jù)來說都是SIDUT(查增刪改傳),但具體業(yè)務(wù)都是分為若干步驟,每個步驟都有其業(yè)務(wù)名稱,同一步驟可能對多個數(shù)據(jù)集進行不同操作,需要調(diào)查了解清楚才能設(shè)計出適合各流程業(yè)務(wù)節(jié)點用戶業(yè)務(wù)特點和習(xí)慣的軟件,使開發(fā)出來的軟件更受歡迎。當(dāng)然在進行軟件概要設(shè)計時,要盡量排除業(yè)務(wù)流程的制約,即把流程中的各項業(yè)務(wù)結(jié)點工作作為獨立的對象,充分考慮他們與其他各種業(yè)務(wù)對象的接口,在流程之間通過業(yè)務(wù)對象的相互調(diào)用實現(xiàn)其業(yè)務(wù)流程,這樣,在業(yè)務(wù)流程發(fā)生有限的變化時,就能夠比較方便地修改系統(tǒng)程序而實現(xiàn)新的需求。
對于各項業(yè)務(wù)的調(diào)查可以通過對以下資料的收集整理分析,這些資料來自各種各樣的項目干系人:遵循的標準、組織發(fā)放的工作手冊、作業(yè)流程、有關(guān)業(yè)務(wù)的上級通知、有關(guān)業(yè)務(wù)的辦事指南、辦理業(yè)務(wù)時需要填寫的登記表、各種相關(guān)的統(tǒng)計報表及通過其他途徑收集的類似系統(tǒng)的介紹、技術(shù)資料等等。
3、可視化需求調(diào)研,引導(dǎo)各種客戶挖掘他們的需求
有的客戶因為自己缺乏計算機知識,無法提出完整準確、隱含的或潛在的需求。但若這些需求不能滿足將導(dǎo)致用戶的不滿。因此需求調(diào)研分析人員應(yīng)善于想用戶所想,不但要確定明確的需求,還要善于用啟發(fā)的方式與用戶探討隱含的或潛在的需求,并結(jié)合各種調(diào)研分析技術(shù)挖掘超出客戶期望的令人興奮的需求。這就要求需求調(diào)研分析員要盡快完整地熟悉相關(guān)業(yè)務(wù),從而能夠站在用戶的立場看待軟件需求,想用戶所想,做好業(yè)務(wù)與計算機之間的橋梁。利用可視化需求調(diào)研的方法可以很好地啟發(fā)用戶深入挖掘潛在的需求??梢暬枨笳{(diào)研就是使用圖表等工具來啟發(fā)引導(dǎo)用戶清楚地敘述需求,并且使需求更加全面完善。
對于高層領(lǐng)導(dǎo),可以提供系統(tǒng)總體框架圖;對于業(yè)務(wù)管理人員,可以用業(yè)務(wù)流程圖來描述新舊系統(tǒng)的業(yè)務(wù)流程;對于客戶中的技術(shù)人員,可以用數(shù)據(jù)流圖、實體關(guān)系圖或UML中的各種圖形對系統(tǒng)進行各種角度的描述;而對于業(yè)務(wù)管理人員、客戶中的技術(shù)人員、以及各層次各流程中的用戶,畫出用戶界面圖來進行需求挖掘,是個比較有效的溝通方式。
這里特別說明一下用戶界面的重要性。用戶界面的設(shè)計按理來說是軟件設(shè)計的責(zé)任,當(dāng)然客戶自己對界面有特別提出要求的除外。但是,如果把它提前到需求調(diào)研時(緊接著原有系統(tǒng)調(diào)研分析和系統(tǒng)模型完成之后)與客戶進行討論,則可以大大改善需求調(diào)研的效果。因此不少需求分析的著作把用戶界面說成是“設(shè)計層”的需求之一。因為這時客戶對于將來的系統(tǒng)還沒有一個形象上的概念,或者有一個模糊的預(yù)想的概念需要表述、驗證、明晰化、完善化。以筆者的經(jīng)驗,畫出用戶界面草圖與客戶進行討論,可以大大激發(fā)他們提供更為準確全面的需求。原來收集資料,描述業(yè)務(wù),說明系統(tǒng)模型到了山窮水盡的時候,這種方法可以達到柳暗花明又一村的效果。在《微軟項目:求生法則》的第8章“需求開發(fā)”中,從頭到尾都是圍繞著“使用者接口”(USER INTERFACE也可以翻譯成“用戶界面”)進行討論,如“建立簡單的使用者接口雛形”、“不斷修訂使用者接口雛型,直到使用者對軟件感到興趣盎然為止”、“完全擴展使用者接口”,同時還要“區(qū)分一份非使用者接口需求文件”,等等。因此,所謂需求就是“當(dāng)你按下各種相關(guān)按鈕(或輸入各種相關(guān)命令)時系統(tǒng)做什么”,所謂設(shè)計就是“當(dāng)你按下各種相關(guān)按鈕(或輸入各種相關(guān)命令)時系統(tǒng)怎么做”。雖然在英語中“接口”與“界面”實際是同一個單詞,但“接口”的含義似乎比“界面”來得廣泛,如功能之間的接口、與其他軟件的接口、與其他硬件的接口等等。需求的最終目的實際上是完整準確地描述系統(tǒng)需要的各種接口或“界面”,及它們的相互關(guān)系或與外部環(huán)境的關(guān)系,如界面中的某個按鈕按下去時,可能產(chǎn)生新的界面、新的按鈕、或者調(diào)用其他軟件硬件完成某些功能。自頂向下,把這些界面及涉及到的數(shù)據(jù)描述清楚,就是一份不錯的需求。
4、與其他項目小組成員共同協(xié)作、持續(xù)完善系統(tǒng)需求
需求文檔完成之后,并不是萬事大吉,把它扔給后面的設(shè)計人員就了事了。作為項目干系人之內(nèi)的項目組其他成員,對需求的有效性也起到某種程度的驗證作用。雖然軟件項目的生命周期按照各種開發(fā)模型有不同階段的劃分,但每個階段的結(jié)束不是簡單地把階段工作成果塞給下一階段的成員就可以了。特別是高科技的軟件開發(fā)項目,上一階段的工作成果往往要通過多次的溝通才能更為清晰地被下一階段成員接受,其有效性、合理性也要被下一階段的工作所檢驗,通過檢驗有時也有必要對上一階段的工作結(jié)果進行相應(yīng)的調(diào)整,需求更是如此。因此,無論是同一階段不同人員之間,或是不同階段人員之間都應(yīng)根據(jù)需要相互協(xié)作,相互配合,共同完成軟件開發(fā)任務(wù)。
參考文獻:
《實用軟件工程》第二版,鄭人杰、殷人昆、陶永雷等著
《微軟項目:求生法則》Steve McConnell著,余孟學(xué)譯
《軟件需求》Soren Lauesen著,劉曉暉譯
《軟件工程:實踐者的研究方法》(第5版)Roger S.Pressman著
本文作者郵箱:luls@dragonsoft.com.cn,lulsnet@21cn.com
【?發(fā)表評論?0條?】