軟件需求工程

SoftwareRequirementsEngineering

第四章改進需求過程

第3章介紹了幾十種需求工程中的好方法，你應當考慮在實踐中應用它們。把理論方法付諸實踐是改進軟件過程（process）的核心所在。從根本上說，改進過程包括使用更多有效的方法避免使用過去使用過的令人頭痛的方法。然而，改進之路卻是從失敗、錯誤開始，還要歷經諸如受人為抵制的影響及因任務的時間緊迫導致改進被擱置這樣的挫折。軟件開發過程的改進有以下兩個目標

1、解決在以前項目或目前項目中遇到的問題

2、防止和避免你可能在將來的項目中遇到的問題把理論方法付諸實踐是改進軟件過程（process）的核心所在。避免使用過去使用過的令人頭痛的方法。改進之路是從失敗、錯誤開始，還要歷經諸如受人為抵制的影響及因任務的時間緊迫導致改進被擱置這樣的挫折。需求與其他主要項目過程和風險承擔者之間的關系1.需求與其他項目過程的關系需求與其他項目過程的關系

1)制定項目計劃需求是制定項目計劃的基礎。因為開發資源和進度安排的估計都要建立在對最終產品的真正理解之上。通常，項目計劃指出所有希望的特性不可能在允許的資源和時間內完成，因此，需要縮小項目范圍或采用版本計劃對功能特性進行選擇。2)項目跟蹤和控制監控每項需求的狀態，以便項目管理者能發現設計和驗證是否達到預期的要求。如果沒有達到，管理者通常請求變更控制過程來進行范圍的縮減。需求與其他項目過程的關系

3)變更控制在需求編寫成文檔并制定基線以后，所有接下來的變更都應通過確定的變更控制過程來進行。變更控制過程能確保：*變更的影響是可以接受的。*受到變更影響的所有人都接到通知并明白這一點。*由合適的人選來作出接受變更的正式決定。*資源按需進行調整。*保持需求文檔是最新版本并是準確的更新文檔。需求與其他項目過程的關系

4)系統測試用戶需求和功能需求是系統測試的重要參考。系統測試可以驗證計劃中所列的功能是否按預期要求實現了。同時，也驗證了用戶任務是否能正確地執行。5)用戶編制文檔產品的需求是編寫文檔的重要參考低質量和拖延的需求會給編寫用戶文檔帶來極大的困難。需求與其他項目過程的關系

6)構造軟件項目主要產品是交付可執行軟件，而不是需求說明文檔。需求文檔是所有設計、實現工作的基礎。要根據功能要求來確定設計模塊，而模塊又要作為編寫代碼的依據。采用設計評審的方法來確保設計正確地反映了所有的需求。而代碼的單元測試能確定是否滿足了設計規格說明和是否滿足了相關的需求。跟蹤每項需求與相應的設計和軟件代碼。2.軟件需求對其他項目風險承擔者影響當軟件開發隊伍改變需求過程時，與其他項目風險承擔者溝通的接口也會發生變化。圖4-2說明了一些外部組織功能，這些功能是通過一定的接口與軟件開發隊伍聯系的，這些接口對項目需求活動起著重要作用。軟件需求對其他項目風險承擔者影響

為能順利進行這些接口操作，要與其他領域的合作者多交流，讓他們知道你的改進想法和調整計劃。要向他們說明改進后的新過程會帶來什么好處。如在改進過程中需要獲得合作時，可以從這樣的談話開始：“這些是我們曾經經歷過的問題，而我們認為進行這些變更將會有助于問題的解決。向各個功能領域的人說明你從他們那里所需要獲取的信息和幫助，從而有助于成功地開發整個產品。在開發過程中要遵從開發組與其他功能領域之間重要交流接口的規范和內容，如系統需求規格說明文檔或市場需求文檔。詢問其他組織需要從開發隊伍中獲取什么以有助于他們的工作。技術可行性方面哪些能幫助市場部更好地完成產品計劃？什么樣的需求狀態報告能使管理者更充分地看清楚項目的進展情況？與系統工程部之間怎樣合作才能確保系統需求在軟、硬件間的分配合理？努力在開發組和其他需求過程風險承擔者之間建立合作關系以便所有人都能更有效地促進項目成功。軟件需求對其他項目風險承擔者影響

許多反對是由于不了解情況而引起的恐懼所造成的，因此一開始就要給他們說清楚為什么要作這些變更，變更后他們將受到怎樣的影響，將會帶來什么好處以及為什么你在過程改進一開始就需要他們的參與等等。下面是一些你可能遇到抵制的情況：需求變更控制過程被看成很難進行而被丟棄。要確保變更過程真正能起作用。如果新的過程不能帶來更好的結果，那大家將會“繞道而行”了。開發人員把編寫和審查需求文檔看作是浪費時間的官僚做法，妨礙他們的“真正工作”—編寫代碼。向他們講清一旦發生重寫代碼所帶來的慘重代價，開發和管理人員將更能明白為什么需要做好需求工作。項目費用沒有和開發過程聯系起來，開發小組可能會缺少變更的動力。如果目標是通過創建高質量產品以減少技術支持費用，技術支持管理者可能會感到受到威脅。3軟件過程改進的基礎堅持四條改進軟件過程的原則1、改進過程應該是革命性的、徹底的、連續的、反復的。2、人們和組織機構都只有在他們獲得激勵時才愿意改變。3、過程變更是面向目標的。4、將改進活動看作是一些小項目4過程改進周期評估當前采用方法1、自我評價問卷

設計自我評價問卷是一種系統方法，它能以較低費用對當前過程進行評估2、來自外部的顧問客觀地評估你目前的軟件開發方法。 這種正式過程的評估方法要以一種已建立的過程改進框架工作為基礎，如軟件工程研究所（CMU/SEI1995）開發的軟件功能成熟度模型（CMM）。評估者將會檢查軟件開發和管理過程，而不限于需求活動。要根據你想通過的過程改進取得的業務目標來選擇評估方法，不要過多擔心是否滿足CMM或其它專用模型的需求。制定改進活動計劃1、將過程改進活動看做是項目，在評估后制定一個活動計劃。戰略計劃+戰術計劃2、采用簡單易于獲得的過程改進活動計劃模板3、以一個項目A來實驗(pilot)變更控制過程。4、以實驗反饋為基礎修改變更控制過程。5、評估問題跟蹤工具并選擇其一來支持變更控制過程。6、定制并購買問題跟蹤工具以支持變更控制過程。7、在組織中使用新的變更控制過程和工具。需求活動計劃模板項目名稱:___________________________編制日期:________

預計所有活動的結束日期:______________

目標:說明業務方面的目標，而不是過程變更方面的成功的標志:

對組織影響的范圍：

參與的人:

姓名角色時間責任

__________________________________________________

跟蹤和報告過程:

說明怎樣跟蹤計劃中的活動條目進展及報告其狀態結果等 依賴關系,風險,和約束條件:

明確對計劃成功有幫助或有阻礙的各種外部因素 （3-10個）活動編號:__負責人:_____預計日期:______

活動的描述:______產物:______需要的資源:______運用在實驗中獲取的經驗來調整新技術，這樣將它運用于整個目標群體時，改進活動會更有效果。請銘記下面這些關于引導實驗的建議：選擇實驗參與者不應該對過程改進持有強烈的反對意向。確定用于評估實驗的標準，使得到的結果易于解釋。通知那些需要知道實驗是什么以及為什么要實施的工程風險承擔者。考慮在不同的項目中實驗新過程的不同部分。用這個方式可使更多的人嘗試新方法，因此能提高認知水平，增加反饋信息。作為評估的一部分工作，詢問實驗參與者，如果他們不得不回頭采用他們原有的工作方法，他們會覺得怎樣。評估結果1、過程改進周期的最后一步就是評估已經實施的活動及取得的成果。2、其中最重要的一步是評估新的實施過程是否帶來了期望的結果。下次是否需要稍作變更3、要接受學習曲線的事實5.需求過程的積累材料檢查清單清單列出各項活動，交付的結果和其它應注意或驗證的條目。檢查清單是用來提示記憶的，有助于確保處于忙碌中的工作人員不要忽略重要細節。實例一種特定類型工作產品的代表，積累起能在你組織中運用的更好的實例。計劃概括說明怎樣完成目標與完成時需要什么樣的文檔。方針確立活動期望、產品期望和交付產品期望的指導原則。過程都應遵從的方針。需求過程的積累材料過程描述完成某個活動的任務順序或步驟，說明要執行的任務及其在項目中所扮演的角色。不要包括示范信息。過程描述一組完成某些目的活動文檔的定義。過程描述應包括過程目標、里程碑、參與者和執行任務的適合時間、交流步驟，期望結果以及與過程相關的輸入和輸出數據（Caputo1998）。模板一種完成整個工作產品的指導方式。重要工程文檔的模板提醒你檢查是否遺漏了什么。一個結構很好的模板提供了許多捕獲和組織信息的欄目(slot)。模板中包含的指導信息將幫助文檔作者有效地使用它。需求開發過程的積累材料需求開發過程的積累材料*項目視圖與范圍模板*需求開發過程*需求分配過程*使用實例模板*軟件需求規格說明模板*需求優先級確定過程*SRS和使用實例審查清單需求管理過程的積累材料需求管理過程的積累材料*變更控制過程*變更控制委員會過程*需求變更影響分析檢查清單和模板