軟件外包項(xiàng)目與需求工程

1、軟件外包項(xiàng)目與需求工程紹興電力局軟件項(xiàng)目外包管理實(shí)踐探討裘衛(wèi)星 浙江省紹興電力局312000摘 要：作者結(jié)合自身工作實(shí)踐，深入探討了在軟件外包項(xiàng)目管理過程中，如何有效地進(jìn)行“需求工程”的相關(guān)工作，從而保證承包商獲取完整并符合用戶真實(shí)意愿的項(xiàng)目需求，以及減少因需求變更失控帶來的可能危害。關(guān)鍵字：軟件外包項(xiàng)目、需求工程、需求開發(fā)、需求管理、ALESH系統(tǒng)一、 需求的重要性何為“需求”？廣泛的講，軟件項(xiàng)目中的需求源于用戶的一些“需要”，這些“需要”被分析、確認(rèn)后形成完整的文檔，該文檔詳細(xì)地說明了軟件產(chǎn)品“必須或應(yīng)當(dāng)”做什么。從重要性來看，軟件項(xiàng)目中“需求、設(shè)計(jì)、編碼、測試”四者哪個(gè)更重要？這個(gè)問題不

2、好回答。四者都是軟件開發(fā)過程中必不可少的環(huán)節(jié)，光做好其中一個(gè)環(huán)節(jié)并不能產(chǎn)生好的系統(tǒng)，但是做壞了其中任何一個(gè)環(huán)節(jié)，必定對系統(tǒng)產(chǎn)生壞影響。若從風(fēng)險(xiǎn)管理的角度講，我認(rèn)為需求開發(fā)和管理是最重要的環(huán)節(jié)。因?yàn)樾枨笫钱a(chǎn)品的根源，需求工作的優(yōu)劣對產(chǎn)品影響最大，而且會(huì)帶來最大的返工成本。舉例來說，軟件項(xiàng)目開發(fā)過程就像一條河流，如果河流的源頭（需求）被污染了，那么整條河流也就被污染了。開發(fā)軟件系統(tǒng)最困難的部分就是準(zhǔn)確說明開發(fā)什么。最困難的工作是編寫出詳細(xì)的需求，以及包括所有面向用戶、面向機(jī)器和其他軟件系統(tǒng)的接口。此工作一旦做錯(cuò)，將會(huì)給系統(tǒng)帶來極大的損害，并且以后的彌補(bǔ)也極為困難。二、 需求工作的問題分析電力行業(yè)這

3、幾年正迎來信息化建設(shè)新浪潮，每個(gè)電力企業(yè)每年都有大量的軟件項(xiàng)目需要開發(fā)，一些項(xiàng)目是由本企業(yè)自主開發(fā)，另外很大一部分是外包給其他軟件公司進(jìn)行開發(fā)，我們在這里可以將其稱為“軟件外包項(xiàng)目”。從我個(gè)人的了解和切身體會(huì)來看，國內(nèi)許多電力企業(yè)的軟件項(xiàng)目開發(fā)狀況并不理想，很多項(xiàng)目進(jìn)度反復(fù)延期、大量的返工、產(chǎn)品質(zhì)量總是不能滿足項(xiàng)目預(yù)期和用戶的要求。而作為信息化建設(shè)的主流模式，軟件外包項(xiàng)目更會(huì)因?yàn)榭绲赜?、溝通不到位、承包商不成熟、組織利益不同等原因而產(chǎn)生更多的問題。分析導(dǎo)致軟件項(xiàng)目失敗的眾多原因，其中最主要的一條就是項(xiàng)目的開發(fā)方和用戶方對“需求工作”不重視或缺少一套有效的方法論。一方面開發(fā)方的很多人員并不知道如

4、何把需求工作做好，而另一方面用戶方往往也忽略需求，不能積極提供完整詳細(xì)的需求說明，而且很多需求確認(rèn)或評審工作也是草草了事。為了改進(jìn)軟件項(xiàng)目以上所述現(xiàn)狀，紹興電力局從2004年起和上海沙迪克軟件有限公司一起就軟件外包項(xiàng)目開發(fā)管理過程進(jìn)行規(guī)范和整改，并取得了非常理想的成效。 我們首先來了解一下軟件外包項(xiàng)目中需求工作存在的種種問題。2.1 用戶說不清楚需求用戶說不清楚需求是普遍現(xiàn)象，這是讓開發(fā)商非常頭痛的問題。這種情況下，如果軟件承包商以此為借口草率地對待需求工作，會(huì)連累整個(gè)項(xiàng)目的開發(fā)。無論什么原因?qū)е掠脩粽f不清楚需求，承包商都必須設(shè)法搞清楚用戶的真實(shí)需求，這是他們的職責(zé)。2.2 態(tài)度問題相當(dāng)多軟件

5、承包商的開發(fā)人員習(xí)慣于被動(dòng)地對待需求工作。每當(dāng)遇到麻煩、挫折時(shí)，總是發(fā)牢騷，并找出用戶的很多問題。這是普遍現(xiàn)象，并不是承包商懶惰所造成的，而是不正確的觀念誤導(dǎo)了他們。很多承包商錯(cuò)誤地認(rèn)為：需求是用戶的事情，不是我們的事情。我們?yōu)橛脩糸_發(fā)軟件，難道用戶不該告訴我們應(yīng)當(dāng)開發(fā)什么嗎？如果用戶說不清楚需求或者經(jīng)常變更需求，因此引起的問題是用戶造成的，應(yīng)當(dāng)由他們自己負(fù)責(zé)。軟件承包商應(yīng)該讓自己的開發(fā)人員了解到：需求分析員的天職就是在有限的時(shí)間內(nèi)獲取準(zhǔn)確而細(xì)致的用戶需求，如果做不到就是失職，不要找借口。2.3 雙方對需求的誤解對用戶描述的需求，不同的人員可能有不同的理解。如果需求分析員誤解了需求，那會(huì)導(dǎo)致后

6、續(xù)的開發(fā)人員錯(cuò)誤的開發(fā)。不論是復(fù)雜的項(xiàng)目還是簡單的項(xiàng)目，需求分析員和用戶都有可能誤解需求，因此需求文檔和評審工作必不可少。2.4 用戶經(jīng)常變更需求需求變更通常會(huì)對項(xiàng)目的進(jìn)度、成本、資源產(chǎn)生很大的影響，這是軟件承包商非常畏懼的問題。很多情況下用戶方也具有不可推卸的責(zé)任，如：在項(xiàng)目初始階段不愿意認(rèn)真地整理需求、確認(rèn)需求，總是想著“以后反正可以修改，以后再說”，這樣做的結(jié)果可想而知，大量的需求變更，頻繁的返工，導(dǎo)致承包商喪失工作激情，以致項(xiàng)目最終不了了之。從以上列舉的幾點(diǎn)來看，要減少因?yàn)樾枨髮?dǎo)致項(xiàng)目失敗的幾率，需要軟件外包項(xiàng)目的雙方好好反省，認(rèn)真學(xué)習(xí)需求工作方法，建立一套有效的軟件項(xiàng)目需求開發(fā)管理過

7、程體系和方法。三、 需求工程的概念為了進(jìn)行有效的改進(jìn)，我們首先需要?jiǎng)澐植⒍x清楚需求相關(guān)工作的主要內(nèi)容及其目標(biāo)。上述闡述中多次提到的“需求工作”，指的是所有與需求直接相關(guān)的活動(dòng)，業(yè)界術(shù)語又稱為“需求工程”。需求工程中的活動(dòng)可以分為兩大類，一類屬于需求開發(fā)，另一類屬于需求管理。需求工程的結(jié)構(gòu)如下圖1所示。圖1：需求工程活動(dòng)分類需求開發(fā)的目的是通過調(diào)查和分析，獲取用戶需求并定義產(chǎn)品需求。需求開發(fā)過程域有3個(gè)主要活動(dòng)： 需求調(diào)查需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息，產(chǎn)生用戶需求說明書； 需求分析需求分析的目的是對各種需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫細(xì)節(jié)等。 需求定義需求定義的目的是根據(jù)需求

8、調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生產(chǎn)品需求規(guī)格說明書。系統(tǒng)設(shè)計(jì)人員將依據(jù)產(chǎn)品需求規(guī)格說明書開展系統(tǒng)設(shè)計(jì)工作。需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護(hù)需求與其他工作成果的一致性，并控制需求的變更。需求管理過程域有3個(gè)主要活動(dòng)： 需求確認(rèn)需求確認(rèn)是指開發(fā)方和客戶共同對需求文檔進(jìn)行評審，雙方對需求達(dá)成共識(shí)后做出書面承諾，使需求文檔具有商業(yè)合作效果。 需求跟蹤需求跟蹤是指比較需求文檔與后續(xù)工作產(chǎn)品之間的對應(yīng)關(guān)系，建立與維護(hù)“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。 需求變更控制需求變更控制是指依據(jù)“變更申請審批更改重新確認(rèn)”的流程處理需求的變更，防止需求

9、變更失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。四、 紹興電力局進(jìn)行“需求工程”改進(jìn)的實(shí)踐探討4.1 甲方需建立合理的項(xiàng)目組織結(jié)構(gòu)為了有效地進(jìn)行需求開發(fā)和管理活動(dòng)，我局根據(jù)企業(yè)自身特點(diǎn)配套建立一套職責(zé)清晰、分工明確的項(xiàng)目組織結(jié)構(gòu)。其中對于需求開發(fā)和管理工作，我們專門設(shè)置了“甲方需求聯(lián)絡(luò)員”這樣一個(gè)崗位，負(fù)責(zé)用戶需求的提出，以及向軟件承包商進(jìn)行用戶需求的解釋工作，如圖2。圖2：軟件外包項(xiàng)目組織結(jié)構(gòu)“甲方需求聯(lián)絡(luò)員”崗位的設(shè)置，保證了甲方有足夠的時(shí)間和人力資源用于用戶需求的獲取、整理、解釋和確認(rèn)工作，同時(shí)又做到了需求歸口統(tǒng)一，最終理解的一致性。對于軟件承包商而言，“甲方需求聯(lián)絡(luò)員”的設(shè)置大大減少了承包商需求分析員

10、組織協(xié)調(diào)的時(shí)間，便于最高效地獲取用戶的真實(shí)需求。4.2 從合同和項(xiàng)目計(jì)劃開始進(jìn)行改進(jìn)軟件承包商和用戶的合作關(guān)系對需求而言是至關(guān)重要的。因此，我們在軟件外包項(xiàng)目的合同和項(xiàng)目計(jì)劃階段，就要求明確雙方的合作關(guān)系，主要體現(xiàn)在：責(zé)任到人、職責(zé)明確、過程規(guī)范。甲方（發(fā)包方或用戶）： 明確需求聯(lián)絡(luò)員、典型和關(guān)鍵用戶； 項(xiàng)目前期盡可能從自身理解出發(fā)，整理出一份完整的用戶需求原始文檔； 要求積極配合乙方需求分析員進(jìn)行采訪，在不泄漏機(jī)密的前提下，盡可能地回答他們希望了解的問題； 要求積極配合乙方需求分析員共同評審需求文檔，確保需求文檔準(zhǔn)確地反映用戶真實(shí)的意愿； 不輕易變更需求。如果需要變更需求的話，按照“需求變更

11、控制規(guī)程”執(zhí)行，而非強(qiáng)迫承包商接受； 甲方將派專人（如：甲方SQA）負(fù)責(zé)對與需求工程有關(guān)的雙方活動(dòng)定期進(jìn)行檢查，如果發(fā)現(xiàn)問題向雙方提出并跟蹤其改進(jìn)結(jié)果； 如果條件允許的話，建議承包商為甲方舉辦有關(guān)需求工程的培訓(xùn)，以減少今后的摩擦，以使需求相關(guān)人員明白需求的重要性，以及忽視需求的危害性，從而使甲方積極友善地參加需求工程中的各項(xiàng)活動(dòng)。乙方（軟件承包商）： 要求乙方派遣合格的需求分析員和相關(guān)人員； 要求乙方采用用戶熟悉的語言和甲方提供的統(tǒng)一格式來描述需求，如一般情況下會(huì)要求乙方提供用戶需求說明書和產(chǎn)品需求規(guī)格說明書兩篇需求文檔； 如果甲方想變更需求，有權(quán)要求乙方對該變更將產(chǎn)生的影響進(jìn)行真實(shí)可信的評估

12、，以便甲方確定是否變更需求； 要求乙方完全遵循合同和項(xiàng)目計(jì)劃中約定的需求開發(fā)和管理過程進(jìn)行工作。4.3 規(guī)范軟件承包商的需求開發(fā)活動(dòng)為了確保承包商獲取項(xiàng)目的真實(shí)需求，我們對承包商的需求活動(dòng)進(jìn)行規(guī)范并進(jìn)行定期的跟蹤，要求他們按照規(guī)范執(zhí)行，并定期提交相關(guān)工作產(chǎn)品以便于我方進(jìn)行檢查。具體包括：需求開發(fā)活動(dòng)活動(dòng)內(nèi)容和相關(guān)工作產(chǎn)品1. 用戶需求調(diào)查 1.1 準(zhǔn)備調(diào)查確認(rèn)關(guān)鍵和典型用戶、確認(rèn)調(diào)查方式、準(zhǔn)備調(diào)查問卷、確認(rèn)調(diào)查對象。 1.2 調(diào)查與記錄調(diào)查用戶需求，隨時(shí)記錄調(diào)查過程中所獲取的需求信息。 1.3 分析需求信息分析已經(jīng)獲取的需求信息，消除錯(cuò)誤，歸納與總結(jié)共性的用戶需求。 1.4 撰寫用戶需求說明書

13、按照指定的文檔模板撰寫用戶需求說明書，主要內(nèi)容包括：產(chǎn)品介紹、用戶群體的特征、產(chǎn)品應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范、描述產(chǎn)品的功能性需求、描述產(chǎn)品的非功能性需求，如用戶界面、軟硬件環(huán)境、質(zhì)量等需求。2產(chǎn)品需求定義 2.1 細(xì)化并分析用戶需求對用戶需求說明書進(jìn)行細(xì)化，以便產(chǎn)生詳細(xì)的產(chǎn)品需求。此外，對比較復(fù)雜的用戶需求進(jìn)行建模分析，以幫助軟件開發(fā)人員更好地理解需求。 2.2撰寫產(chǎn)品需求規(guī)格說明書按照指定的文檔模板撰寫產(chǎn)品需求規(guī)格說明書，主要內(nèi)容包括：產(chǎn)品介紹、用戶群體的特征、定義產(chǎn)品的范圍、產(chǎn)品應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范、定義產(chǎn)品中的角色定義產(chǎn)品的功能性需求、定義產(chǎn)品的非功能性需求，如用戶界面、軟硬件環(huán)境、質(zhì)量等需

14、求。另外，為了更好了解每個(gè)需求的是否清晰、與其它工作產(chǎn)品的對應(yīng)關(guān)系，并便于跟蹤后續(xù)的完成情況，我們要求軟件承包商為需求進(jìn)行編號，并能夠通過一張索引表（如下表所示）了解以上的相關(guān)信息。需求編號功能子功能需求優(yōu)先度（高、中、低）對應(yīng)的用戶需求備注（依賴關(guān)系和清晰狀態(tài)等）Function AFunction A.1Function A.24.4 規(guī)范和改進(jìn)需求評審活動(dòng)對需求文檔進(jìn)行評審是保證項(xiàng)目質(zhì)量的關(guān)鍵活動(dòng)。我們將評審的方式分為兩類：一類是正式評審，主要由用戶方和承包商共同參與的評審；另一類是非正式評審，主要是軟件承包商內(nèi)部的評審。對于承包商提交的用戶需求說明書和產(chǎn)品需求規(guī)格說明書，一般情況下我們

15、都要求至少執(zhí)行一次正式評審，并安排在我方所在地進(jìn)行。對于非正式評審，我們都要求由承包商自己內(nèi)部進(jìn)行，但我們會(huì)跟蹤和抽查他們的評審過程和結(jié)論，希望他們能事先排除基本的錯(cuò)誤，明確主要問題，以提高后續(xù)正式評審的效率。對于正式評審活動(dòng)，往往會(huì)伴隨很多問題的產(chǎn)生，并嚴(yán)重影響了評審工作的執(zhí)行。針對這些問題，我們從自身實(shí)踐中摸索出一些比較好的解決辦法，說明如下： 評審工作“虎頭蛇尾”需求評審的確乏味，剛開始評審的時(shí)候大家都比較認(rèn)真，往往越到后面越馬虎，特別是需求文檔很長時(shí)，幾乎沒有人能夠堅(jiān)持到最后。針對以上問題，我局在自身的需求評審工作中通過以下幾點(diǎn)來進(jìn)行改進(jìn)：1、評審工作事先有計(jì)劃，并做好內(nèi)容分工。每部分

16、內(nèi)容都有專門的人員進(jìn)行負(fù)責(zé)，以減少每個(gè)人的閱讀工作量。2、作者就評審文檔的主要問題點(diǎn)事先和責(zé)任人進(jìn)行溝通，明確需要會(huì)上確認(rèn)的主要問題。這樣有助于提高評審效率，盡量減少評審時(shí)間。3、會(huì)議主持人事先強(qiáng)調(diào)需求評審工作的重要性，以提高參與評審人員的注意力和積極性。 評審工作量大需求評審的人員可能比較多，有時(shí)候讓這么多人聚在一起花費(fèi)比較長的時(shí)間開會(huì)并不容易。其實(shí)沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進(jìn)的過程，需求評審也可以分段進(jìn)行，這樣每次評審的時(shí)間比較短，參加評審的人員也少一些，組織會(huì)議就比較容易。 評審時(shí)容易“跑題”評審時(shí)如果會(huì)針對一個(gè)問題進(jìn)行激烈討論，而且會(huì)越扯越遠(yuǎn)，結(jié)果評審會(huì)議變成聊天會(huì)

17、議。此時(shí)，一方面主持人應(yīng)當(dāng)控制話題，避免大家討論與主題無關(guān)的東西；另一方面，對于有些問題“如何做，如何解決”這樣的討論，要做到適可而止，不要過多地談?wù)摷?xì)節(jié)，可以放在會(huì)后進(jìn)行，這樣有助于節(jié)約多數(shù)人的時(shí)間。 評審時(shí)過多的“爭論”很多評審會(huì)議上，往往會(huì)因?yàn)槟硞€(gè)問題難以達(dá)成共識(shí)，并分成“幾派”各據(jù)一方。此時(shí)，會(huì)議的主持人應(yīng)該參與進(jìn)行協(xié)調(diào)，建議大家站在他人的立場上進(jìn)行思考，這樣一般會(huì)很快找到適中的解決辦法。4.5 要求承包商建立需求跟蹤報(bào)告在我們對承包商的開發(fā)過程進(jìn)行跟蹤和檢查的過程中，我們經(jīng)常需要了解“產(chǎn)品需求是否反映所有用戶需求？”、“設(shè)計(jì)是否反映了產(chǎn)品需求？”、“需求是否有相應(yīng)的測試用例進(jìn)行測試？

18、”等等這些問題，并且承包商只有很好地處理了以上問題才能充分保證未來軟件產(chǎn)品的質(zhì)量。為此，我們會(huì)在一些重要項(xiàng)目中要求承包商及時(shí)建立“需求跟蹤報(bào)告”（如下表所示），這樣有助于后續(xù)我們執(zhí)行相關(guān)工作產(chǎn)品的審查工作。序號需求編號需求文檔（版本、日期）設(shè)計(jì)文檔（版本、日期）代碼（版本、日期）測試用例（版本、日期）缺陷標(biāo)題或標(biāo)識(shí)符，說明標(biāo)題或標(biāo)識(shí)符，說明文件名，標(biāo)題或標(biāo)識(shí)符，說明文件名，標(biāo)題或標(biāo)識(shí)符，說明缺陷編號001FR-A-0017.A.1用戶登錄成功XT-A001-01XT-A002-024.5建立需求變更控制過程 很多項(xiàng)目需求發(fā)生若干次變更似乎是不可避免的。很多情況下，是由于用戶和承包商對需求的了解越來越深入，原來定義的需求可能存在錯(cuò)誤或不足，因此需要變更需求。提出需求變更的動(dòng)機(jī)是好的，但管理不好往往會(huì)帶來很嚴(yán)重的負(fù)面影響，很多情況下會(huì)發(fā)生“變更帶來的好處遠(yuǎn)遠(yuǎn)小于因此導(dǎo)致的壞處”，如：原先好用的功能因?yàn)閭€(gè)別人的習(xí)慣問題被修改掉，導(dǎo)致大多數(shù)人難以使用；個(gè)別需求變更，導(dǎo)致開發(fā)工作大量返工，嚴(yán)重影響后續(xù)的測試工作，導(dǎo)致項(xiàng)目質(zhì)量低下甚至延期。為了有效地管理和控制需求變更，我局建立一套規(guī)范的需求變更控制過程，并做到： 需求變更提出用戶或承包商提出的變更均采用規(guī)定方式進(jìn)行提交（如：需求變更控制報(bào)告或沙迪