中文字幕二区_国产精品免费在线观看_黄色网站观看_人人草人人澡_日本真实娇小xxxx

編者按：

　　 作為軟件開發(fā)人員或者軟件系統(tǒng)客戶，相信都遭遇過因為需求變更而需要修改系統(tǒng)的情況，一般說來客戶會要求改變界面，改變操作方式，甚至改變業(yè)務(wù)，客戶甚至會說：“當時我是那樣要求的，不過現(xiàn)在我們的業(yè)務(wù)調(diào)整了”…這時需要中斷正在進行的工作，需要查證以往的資料，需要修正計劃，需要……

　　 在本期的月刊中，我們將圍繞著“需求變更”這個主題展開討論，希望對各位開發(fā)能有所幫助。讓我們先來看一個需求變更的典型案例：

　　 Steven剛出任項目經(jīng)理，并承接了一個中型軟件項目。公司再三叮嚀他一定要尊重客戶，充分滿足客戶需求。項目開始比較順利，但進入到后期，客戶頻繁的需求變更帶來很多額外工作。Steven動員大家加班，保持了項目的正常進度，客戶相當滿意。
　　但需求變更卻越來越多。為了節(jié)省時間，客戶的業(yè)務(wù)人員不再向Steven申請變更，而是直接找程序員商量。程序員疲于應(yīng)付，往往直接改程序而不做任何記錄，很多相關(guān)文檔也忘記修改。很快Steven就發(fā)現(xiàn)：需求、設(shè)計和代碼無法保持一致，甚至沒有人能說清楚現(xiàn)在系統(tǒng)“到底改成什么樣了”。版本管理也出現(xiàn)了混亂，很多人違反配置管理規(guī)定，直接在測試環(huán)境中修改和編譯程序。但在進度壓力下，他也只能佯裝不知此事。但因頻繁出現(xiàn)“改好的錯誤又重新出現(xiàn)”的問題，客戶已經(jīng)明確表示“失去了耐心”。
　　而這還只是噩夢的開始。一個程序員未經(jīng)許可擅自修改了核心模塊，造成系統(tǒng)運行異常緩慢，大量應(yīng)用程序超時退出。雖然最終花費了整整3天的時間解決了這個問題，但客戶卻投訴了，表示“無法容忍這種低下的項目管理水平”。更糟糕的是，因為擔心系統(tǒng)中還隱含著其他類似的錯誤，客戶高層對項目的質(zhì)量也疑慮重重。
　　隨后發(fā)生的事情讓Steven更加為難：客戶的兩個負責人對界面風格的看法不一致，并為此發(fā)生了激烈爭執(zhí)。Steven知道如果發(fā)表意見可能會得罪其中一方，于是保持了沉默。最終客戶決定調(diào)整所有界面， Steven只好立刻動員大家抓緊時間修改�？珊髞懋斅犝f因修改界面而造成了項目一周的延誤后，客戶方原來發(fā)生爭執(zhí)的兩人這次卻非常一致，同時氣憤地質(zhì)問Steven：“為什么你不早點告訴我們要延期！早知這樣才不會讓你改呢！”Steven很無耐，疑惑自己到底錯在哪里了。

段落導(dǎo)航：

　　 為了方便大家的閱讀，我們將本期內(nèi)容進行了合理的分類，您可以使用下面的鏈接瀏覽您感興趣的主題。　　

• 對軟件需求和需求變更的理解
• 需求變更的原因
• 需求變更的代價
• 減少需求變更
• 如何控制需求變更
• 需求變更的管理
• 實施需求變更管理需要遵循以下六大原則
• 應(yīng)對之道
  　　
  

對軟件需求和需求變更的理解

　　 軟件需求是整個軟件項目的最關(guān)鍵的一個輸入，和傳統(tǒng)的生產(chǎn)企業(yè)相比較，軟件的需求具有模糊性、不確定性、變化性和主觀性的特點，它不像生產(chǎn)汽車、電腦等硬件的需求，是有形的、客觀的、可描述的、可檢測的。軟件需求是軟件項目最難把握的問題，同時又是關(guān)系項目成敗的關(guān)鍵因素，因此對于需求分析和需求變更的處理十分重要。

　　 需求變更會給項目帶來巨大的風險,會導(dǎo)致項目的成本費用增加、開發(fā)周期延長、產(chǎn)品質(zhì)量下降及團隊工作效率下降等不良后果，因而軟件開發(fā)項目中應(yīng)該盡量減少需求變更的出現(xiàn)頻率。然而由于政府對特定軟件的相關(guān)要求、用戶部門市場戰(zhàn)略的調(diào)整、工業(yè)界的發(fā)展等因素都可能帶來需求的變更，而這些因素往往不可避免。在軟件開發(fā)過程中如果只有一條真理的話，那一定是：需求的變化是永恒的，需求不可能是完備的。因而，對于需求變更應(yīng)該正確的對待，盡量將其負面影響降低到最低。

返回導(dǎo)航

需求變更的原因

　　 需求包括業(yè)務(wù)需求、用戶需求和功能需求。業(yè)務(wù)需求（Business Requirement ）反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，用戶需求（User Requirement ）描述了用戶使用產(chǎn)品必須完成的任務(wù)，功能需求（Functional Requirement ）定義了開發(fā)人員必須實現(xiàn)的軟件功能。

　　 會導(dǎo)致需求變更的原因會有很多，如老板臨時改變想法、項目預(yù)算增加或減少、客戶對功能的需求改變等。在IT項目中，變更可能來自方案服務(wù)商、客戶或產(chǎn)品供應(yīng)商等，也可能來源于項目組內(nèi)部。在軟件系統(tǒng)開發(fā)過程中，有很多問題都是由于在需求分析階段沒有正確地收集、編寫、協(xié)商、修改產(chǎn)品真實需求而產(chǎn)生的，造成這樣的狀況有以下幾方面的基本原因:

需求變更的代價

　　 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，項目開發(fā)人員應(yīng)該分析這些新需求對項目現(xiàn)階段帶來的風險，得出雙方實現(xiàn)變更需求的需要的成本，包括時間、人力、資源等等方面。

　　 變更都是有代價的，應(yīng)該評估一下變更的代價和對項目的影響，在評估代價并且與客戶討論的過程中，要讓客戶了解變更的后果，變更之后面臨最大的問題就是項目延期，讓客戶一起做判斷：“我可以修改，但您能接受后果嗎？”�，F(xiàn)在會出現(xiàn)三種可能：客戶接受延期這一后果，開發(fā)人員按客戶要求做出相應(yīng)修改，讓客戶知道為此需要付出延期的代價；如果客戶認為代價太大，那開發(fā)人員就不必修改了，可以記錄下需求，待到下一版本再做修改；客戶不接受變更的代價，導(dǎo)致項目夭折。 如果客戶不知道你為變更付出的代價，對你的辛苦便難以體會，以致沒完沒了的提出新的變更。

減少需求變更

　　正如前文所說，需求變更往往是不可避免的。通常是項目負責人員花費了大量的氣力避免需求變更，可最后需求變更總是會出現(xiàn)。但是這并不意味著項目開發(fā)人員不應(yīng)該做這方面的工作，項目開發(fā)人員對于需求變更的正確態(tài)度應(yīng)該和軟件測試的態(tài)度一樣，在需求變更發(fā)生之前盡量減少需求變更，以將需求變更帶來的風險降低到最低。項目開發(fā)人員切忌在項目設(shè)計之前試圖消除需求變更，這樣做往往費力不討好。

　　相比于需求開發(fā)人員而言，客戶可能對需求變更認識不足，認為他們出錢，程序員或軟件開發(fā)公司就要為它服務(wù)，因此客戶對需求變更往往更加肆無忌彈，將需求變更視為兒戲，隨個人喜好隨意變更需求。因此，在需求人員同用戶代表或用戶部門主管人員接觸時，就應(yīng)該向他們挑明態(tài)度，和他們協(xié)商好，特別是應(yīng)該讓他們清楚軟件的定價應(yīng)該與軟件的功能相關(guān)，以及需求隨意變更所帶來的風險的承擔者應(yīng)該由客戶和項目開發(fā)者共同承擔。通過這樣做，讓客戶在需求分析之前就盡量對他們所需要的功能有個整體的了解和確定的思路，而不是等到程序員開始編碼了，才提出以前原本在需求分析時就可以提出的需求。

　　讓客戶明白減少需求變更的重要性后，需求分析人員應(yīng)該采取合適的方法同客戶交流，幫助他們明確他們的需求。需求分析人員和客戶的關(guān)系不應(yīng)該僅僅是記錄人員和需求提供者，他們的關(guān)系應(yīng)該更多的是戰(zhàn)略合作伙伴關(guān)系。雖然需求分析人員和客戶存在著服務(wù)商和顧客的關(guān)系，但是他們有著一個共同的目標：開發(fā)出適合客戶需求的軟件，因此需求分析人員除了記錄客戶提出的需求以外，還應(yīng)和用戶討論，提出一些建議，使用合適的工具幫助客戶提出需求。在需求分析時，盡量多的召集需求研討會，邀請開發(fā)人員和客戶共同協(xié)商探討，在研討會上允許任意的提出需求，并將這些需求整理成檔后由客戶代表和需求分析人員共同商議可選的功能，這樣能夠盡量使得需求完備。在需求開發(fā)時，開發(fā)人員采用原型的方法啟發(fā)客戶思考功能需求也不失為一個好辦法。

　　雖然需求不可能是完備的、變更不可能沒有的，但是在項目開始設(shè)計時使得需求盡可能完備還是應(yīng)該的，也是值得的，完備需求的過程也就相應(yīng)的減少了因為需求不清楚而產(chǎn)生變更的幾率。

返回導(dǎo)航

　　按照現(xiàn)代項目管理的概念，一個項目的生命周期分為啟動、實施、收尾三個過程。需求變更的控制不應(yīng)該只是項目實施過程考慮的事情，而是要分布在整個項目生命周期的全過程。為了將項目變更的影響降低到最小，就需要采用綜合變更控制方法。綜合變更控制主要內(nèi)容有找出影響項目變更的因素、判斷項目變更范圍是否已經(jīng)發(fā)生等。

　　進行綜合變更控制的主要依據(jù)是項目計劃、變更請求提供了項目執(zhí)行狀況信息的績效報告。為保證項目變更的規(guī)范和有效實施，通常項目實施組織會有以下幾種措施：

（1）項目啟動階段的變更預(yù)防

　　對于任何項目，變更都無可避免，也無從逃避，只能積極應(yīng)對，這個應(yīng)對應(yīng)該是從項目啟動的需求分析階段就開始了。對一個需求分析做得很好的項目來說，基準文件定義的范圍越詳細清晰，用戶跟項目經(jīng)理扯皮的幌子就越少。如果需求沒做好，基準文件里的范圍含糊不清，被客戶抓住空子，往往要付出許多無謂的犧牲。如果需求做得好，文檔清晰且又有客戶簽字，那么后期客戶提出的變更就超出了合同范圍，需要另外收費。這個時候千萬不能手軟，這并非要刻意賺取客戶的錢財，而是不能讓客戶養(yǎng)成經(jīng)常變更的習慣，否則后患無窮。相對于需求來說，什么WBS、風險管理、計劃進度都是次要的，只要需求做好了就會一帆風順。

（2）項目實施階段的需求變更

　　成功項目和失敗項目的區(qū)別就在于項目的整個過程是否是可控的。項目經(jīng)理應(yīng)該樹立一個理念——“需求變更是必然的、可控的、有益的”。項目實施階段的變更控制需要做的是分析變更請求，評估變更可能帶來的風險和修改基準文件�？刂菩枨鬂u變需要注意以下幾點：

　　需求一定要與投入有聯(lián)系，如果需求變更的成本由開發(fā)方來承擔，則項目需求的變更就成為必然了。所以，在項目的開始，無論是開發(fā)方還是出資方都要明確這一條：需求變，軟件開發(fā)的投入也要變。

　　需求的變更要經(jīng)過出資者的認可，這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。

　　小的需求變更也要經(jīng)過正規(guī)的需求管理流程，否則會積少成多。在實踐中，人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過程，認為降低了開發(fā)效率，浪費了時間。但正是由于這種觀念才使需求逐漸變?yōu)椴豢煽�，最終導(dǎo)致項目的失敗。

　　精確的需求與范圍定義并不會阻止需求的變更。并非對需求定義得越細，就越能避免需求的漸變，這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恒的，并非需求寫細了，它就不會變化了。

　　注意溝通的技巧。實際情況是用戶、開發(fā)者都認識到了上面的幾點問題，但是由于需求的變更可能來自客戶方，也可能來自開發(fā)方，因此，作為需求管理者，項目經(jīng)理需要采用各種溝通技巧來使項目的各方各得其所。

　　在開發(fā)上盡量根據(jù)情況采用多次迭代的方式進行項目的開發(fā)，在每次迭代的同時讓客戶參與和使用軟件，對下一步的開發(fā)做出建議爭取在項目前期有效的減少后期可能出現(xiàn)的變更情況。

（3）項目收尾階段的總結(jié)

　　能力的提高往往不是從成功的經(jīng)驗中來，而是從失敗的教訓(xùn)中來。許多項目經(jīng)理不注重經(jīng)驗教訓(xùn)總結(jié)和積累，即使在項目運作過程中碰得頭破血流，也只是抱怨運氣、環(huán)境和團隊配合不好，很少系統(tǒng)地分析總結(jié)，或者不知道如何分析總結(jié)，以至于同樣的問題反復(fù)出現(xiàn)。

　　事實上，項目總結(jié)工作應(yīng)作為現(xiàn)有項目或?qū)眄椖砍掷m(xù)改進工作的一項重要內(nèi)容，同時也可以作為對項目合同、設(shè)計方案內(nèi)容與目標的確認和驗證。項目總結(jié)工作包括項目中事先識別的風險和沒有預(yù)料到而發(fā)生的變更等風險的應(yīng)對措施的分析和總結(jié)，也包括項目中發(fā)生的變更和項目中發(fā)生問題的分析統(tǒng)計的總結(jié)。

返回導(dǎo)航

需求變更的管理

　　需求變更是因為需求發(fā)生變化。根據(jù)軟件工程思想，需求說明書一般要經(jīng)過論證，如果在需求說明書經(jīng)過論證以后，需要在原有需求基礎(chǔ)上追加和補充新的需求或?qū)υ行枨筮M行修改和削減，均屬于需求變更。

　　需求變更的出現(xiàn)主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什么。用戶常常以為自己清楚，但實際上他們提出的需求只是依據(jù)當前的工作所需，而采用的新設(shè)備、新技術(shù)通常會改變他們的工作方式;或者要開發(fā)的系統(tǒng)對用戶來說也是個未知數(shù)，他們以前沒有過相關(guān)的使用經(jīng)驗。隨著開發(fā)工作的不斷進展，系統(tǒng)開始展現(xiàn)功能的雛形，用戶對系統(tǒng)的了解也逐步深入。于是，他們可能會想到各種新的功能和特色，或?qū)σ郧疤岢龅囊筮M行改動。他們了解得越多，新的要求也就越多，需求變更因此不可避免地一次又一次出現(xiàn)。

　　這時，如果開發(fā)團隊缺少明確的需求變更控制過程或采用的變更控制機制無效，抑或不按變更控制流程來管理需求變更，那么很可能造成項目進度拖延、成本不足、人力緊缺，甚至導(dǎo)致整個項目失敗。當然，即使按照需求變更控制流程進行管理，由于受進度、成本等因素的制約，軟件質(zhì)量還是會受到不同程度的影響。但實施嚴格的軟件需求管理會最大限度地控制需求變更給軟件質(zhì)量造成的負面影響，這也正是我們進行需求變更管理的目的所在。

返回導(dǎo)航

實施需求變更管理需要遵循以下六大原則

（1）建立需求基線，需求基線是需求變更的依據(jù)。在開發(fā)過程中，需求確定并經(jīng)過評審后（用戶參與評審），可以建立第一個需求基線。此后每次變更并經(jīng)過評審后，都要重新確定新的需求基線。

（2）制訂簡單、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個控制流程進行控制。同時，這個流程具有一定的普遍性，對以后的項目開發(fā)和其他項目都有借鑒作用。

（3）成立項目變更控制委員會（CCB）或相關(guān)職能的類似組織，負責裁定接受哪些變更。CCB由項目所涉及的多方人員共同組成，應(yīng)該包括用戶方和開發(fā)方的決策人員在內(nèi)。

（4）需求變更一定要先申請然后再評估，最后經(jīng)過與變更大小相當級別的評審確認。

（5）需求變更后，受影響的軟件計劃、產(chǎn)品、活動都要進行相應(yīng)的變更，以保持和更新的需求一致。

（6）妥善保存變更產(chǎn)生的相關(guān)文檔。

返回導(dǎo)航

應(yīng)對之道

　　需求變更控制一般要經(jīng)過變更申請、變更評估、決策、回復(fù)這四大步驟。如果變更被接受，還要增加實施變更和驗證兩個步驟，有時還會有取消變更的步驟。針對變更控制流程，在實際工作中總結(jié)出了軟件開發(fā)人員在需求變更管理實踐中的幾點對策：

　　優(yōu)先排序 分批實現(xiàn)　每個需求的重要性是不同的。由于資源或技術(shù)條件的限制，會顯得“僧多粥少”，因此不可能把所有的需求一次完成。怎么辦？把每個需求按照對效益的貢獻打個分，排出個優(yōu)先級來，優(yōu)先級高的需求先實現(xiàn)，低的到一下版式本實現(xiàn)。由于不斷有新的需求進來，有的需求可能永遠沒有機會被子實現(xiàn)，但不緊，還是要記錄下來，并一起參加排序，保證在每個版本發(fā)布時重要的需求先得到滿足。每個需求的實現(xiàn)是需要花時間的，沒人有百分百的把握預(yù)估得很清楚，但借鑒過去的經(jīng)驗可以大概估算出人力成本，然后根據(jù)開發(fā)人員和開發(fā)周期得出可用人力投入作為上限。從優(yōu)先級高的需求中挑，直到挑中的人力成本總和剛剛低于可用投入上限，這樣得出的就是需求的錄取榜。今后的軟件開發(fā)規(guī)劃也會以此為依據(jù)，分期分批地在不同的回合中實現(xiàn)。最合理的不一定是優(yōu)先級最高的，也就是說不一不定是最先考慮的，“經(jīng)濟為本”是指導(dǎo)優(yōu)先排序的最終原則。

　　相互協(xié)作　很難想像遭到用戶抵制的項目能夠成功。在討論需求時，開發(fā)人員與用戶應(yīng)該盡量采取相互理解、相互協(xié)作的態(tài)度，對能解決的問題盡量解決。即使用戶提出了在開發(fā)人員看來"過分"的要求，也應(yīng)該仔細分析原因，積極提出可行的替代方案。

　　充分交流　需求變更管理的過程很大程度上就是用戶與開發(fā)人員的交流過程。軟件開發(fā)人員必須學(xué)會認真聽取用戶的要求、考慮和設(shè)想，并加以分析和整理。同時，軟件開發(fā)人員應(yīng)該向用戶說明，進入設(shè)計階段以后，再提出需求變更會給整個開發(fā)工作帶來什么樣的沖擊和不良后果。

　　安排專職人員負責需求變更管理　有時開發(fā)任務(wù)較重，開發(fā)人員容易陷入開發(fā)工作中而忽略了與用戶的隨時溝通，因此需要一名專職的需求變更管理人員負責與用戶及時交流。

　　合同約束　需求變更給軟件開發(fā)帶來的影響有目共睹，所以在與用戶簽訂合同時，可以增加一些相關(guān)條款，如限定用戶提出需求變更的時間，規(guī)定何種情況的變更可以接受、拒絕接受或部分接受，還可以規(guī)定發(fā)生需求變更時必須執(zhí)行變更控制流程。

　　區(qū)別對待　隨著開發(fā)進展，有些用戶會不斷提出一些在項目組看來確實無法實現(xiàn)或工作量比較大、對項目進度有重大影響的需求。遇到這種情況，開發(fā)人員可以向用戶說明，項目的啟動是以最初的基本需求作為開發(fā)前提的，如果大量增加新的需求（雖然用戶認為是細化需求，但實際上是增加了工作量的新需求），會使項目不能按時完成。如果用戶堅持實施新需求，可以建議用戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項依據(jù)。同時，還要注意控制新需求提出的頻率。

　　選用適當?shù)拈_發(fā)模型　采用建立原型的開發(fā)模型比較適合需求不明確的開發(fā)項目。開發(fā)人員先根據(jù)用戶對需求的說明建立一個系統(tǒng)原型，再與用戶溝通。一般用戶看到一些實際的東西后，對需求會有更為詳細的解釋，開發(fā)人員可根據(jù)用戶的說明進一步完善系統(tǒng)原型。這個過程重復(fù)幾次后，系統(tǒng)原型逐漸向最終的用戶需求靠攏，從根本上減少需求變更的出現(xiàn)。目前業(yè)界較為流行的疊代式開發(fā)方法對工期緊迫的項目的需求變更控制很有成效。

　　用戶參與需求評審　作為需求的提出者，用戶理所當然是最具權(quán)威的發(fā)言人之一。實際上，在需求評審過程中，用戶往往能提出許多有價值的意見。同時，這也是由用戶對需求進行最后確認的機會，可以有效減少需求變更的發(fā)生。

　　變更控制流程如圖所示。

返回導(dǎo)航

后記：

　　對于軟件開發(fā)項目來說,開發(fā)的過程中不可避免的會出現(xiàn)需求變更，發(fā)生變更的環(huán)節(jié)也比較多，因此變更控制顯得格外重要。變更控制對項目成敗有重要影響，項目開發(fā)之前要明確定義，開發(fā)過程中要嚴格執(zhí)行。對變更控制的目的并不是控制變更的發(fā)生，而是對變更進行管理，以便更好的處理變更，確保變更有序進行，從而減少因為需求變更而帶來的損失，加快項目的開發(fā)速度。

動感體驗:

　　您是否愿意更多的了解NoahWeb？是否愿意全面深入的體會和了解NoahWeb？是否愿意參與到“真實”的開發(fā)團隊中使用NoahWeb進行實際的項目開發(fā)，在“實戰(zhàn)”中，與其他同仁組成的開發(fā)團隊一起感受NoahWeb的魅力，點擊這里回答幾個簡單的問題，讓我們了解你的想法，讓我們帶給你更多精彩。