第八周作業

2022-05-21 11:06:08 字數 2509 閱讀 8649

所謂需求管理就是為有效地控制和管理需求更改地所進行的一系列活動。

開發人員在與提出更改的請求者(使用者)協商的基礎上,評估需求變更帶來的潛在影響及可能的成本和費用,然後實施更改,以及有效地管理需求規格說明文件和跟蹤更改需求的狀態。
控制對基準需求規格說明的變動;

保持專案計畫與需求一致;

控制單個需求的更改和需求規格說明文件的更改;

管理需求和需求間的聯絡。以及需求與設計和實現等方面的依賴關係;

跟蹤需求更改的狀態,控制多個需求同時更改的複雜性。

在實際的軟體開發中,對許多軟體專案中,一些需求的更改是不可避免的,原因是市場競爭、業務過程和組織機構的變化、軟體系統執行環境的變化等。但是不被控制的需求變更會使專案陷入困境,這是某些專案不能按進度執行或質量低劣的重要原因之一。
1) 建立所有的需求變更所應遵循的過程(包括變更步驟)。按此過程,當乙個變更需求在過程中某一步被拒絕後,則其後的步驟將不再予以考慮。

2) 對於未或批准的變更,除進行可行性論證外,不應再做其後的工作。

3) 對所提出的多個變更請求,應由專案變更小組委員會決定實現哪些變更,以及先後次序。

4)專案開發人員和使用者應該能了解已變更需求的情況。

5)不准隨意刪除和修改與需求變更請求和實現相關的原始文件。

6) 每乙個實施後的變更必須與乙個經核准的變更請求相對應

在需求變更請求中,有大的變更請求和小的變更請求之分,這主要是根據實施需求變更所涉及的範圍大小來決定的。對於所有的變更請求,不管其大小如何,都應通過控制過程來處理所有的變更。在實踐中,可以將一些小的、具體的需求變更請求交由開發人員來決定。但設計2人或2人以上(特別是介面問題)的需求變更則應通過變更控制過程來處理。

變更控制的步驟中,每步的工作任務明確,各步間是相互依賴的。

1)變更控制的啟動。啟動的條件是通過合適的渠道接受乙個合法的變更請求。

2)確定角色與責任。列出參與變更控制活動的專案組成員,並描述他們的職責和分配角色。

3)影響分析與評估。評估變更請求的技術可行性、代價和資源限制等,提供對變更請求的準確理解,幫助做出資訊量充分的變更批准決策。為了幫助評估員理解乙個需求變更的影響,可以設計乙個由一些問題組成的問題清單和受影響的軟體元素清單。從事影響分析的評估員在分析過程中根據問題給出量化的評估值,然後通過求和就可得到變更請求的綜合評估值。該綜合評估值為評估員決定是否實施變更提供了判斷的依據。當 評估員決定實施變更請求時,他們還必須估計變更對專案進度和費用的影響,為專案負責人和變更小組負責人提供判斷依據。

4)實施變更。當需求變更請求被採納後,開始對涉及的軟體系統實施更新。在實施更新的過程中,因具體情況不同,可能需修該一部分文件或**,如需求規格說明文件、設計文件和測試文件等,以及更改某些資料庫或檔案等。

5)驗證。主要是通過檢查來確保更新後的需求規格說明的正確性。一些用例、分析模型或測試用例等均能正確反應變更的各個方面,可以通過這些方法來支援驗證的工作。有時還可通過對軟體系統進行測試來驗證變更工作。

6)變更控制的結束。

版本控制是需求管理的乙個必要方面,也是容易忽視和出錯的方面。在變更實施過程中,需求規格說明文件需要修改,並建立新的版本。這就存在版本的控制問題,如稍不注意,就會導致軟體的開發和維護工作出錯。實際上,原程式的版本變更及多版本的管理也存在與此例類似的問題。因此,需求規格說明的每乙個版本必須統一確定,並保證開發人員必須知道和得到新的需求規格說明版本。為了有效地實施版本控制,可以遵循尋如下的版本控制策略。

1)為了減少困惑、衝突和不一致,只能允許指定的專人來更新和修改需求規格說明文件。

2)每乙個公布的需求規格說明文件的版本應該包括修改版本的歷史情況,如已修改的內容、修改的日期、修改人的姓名及修改的原因等。

3)根據修改工作量的大小,手工標記需求規格說明版本的每一次修改。

4)每個版本的需求規格說明必須是獨立說明的,以避免新舊版本的混淆

版本控制的策略有很多,應該根據具體情況進行控制。此外,有的還可借助於一些版本控制工具來實現版本管理。

對於乙個大型而複雜的軟體系統的需求規格說明,可能會面臨多個需求變更的情況。變更控制過程不可能同時對每個需求給予處理,故在長時間內,掌握和了解多個需求變更處理的情況,以及是否已完成更改的情況等,這在軟體開發過程和維護過程中是很重要的。為了便於管理和控制需求變更,對於乙個變更請求可用狀態圖來描述其在不同時間所處的狀態,以使各類人員知道更改的進度。
所謂需求跟蹤是指編制每個需求與系統元素之間聯絡(即可跟蹤資訊)的文件,其中,系統元素包括:其他需求、體系結構、設計部件、測試文件等。可跟蹤性就是指需求跟蹤的內容。為了實現可跟蹤性,必須統一地標識出每乙個需求,以便能明確地進行查閱。

此處根據需求系統元素之間聯絡的型別把可跟蹤性資訊粗略分為如下幾類:

有兩種技術可用於維護可跟蹤資訊:需求跟蹤表和可跟蹤性表。

隨著軟體工程技術的發展,需求管理的任務越來越繁重,迫切需要研製需求管理工具來自動化地管理需求,提高工作效率。ibm rational requisitepro、telelogic doorsreg和borland caliberrm等都是目前比較流行的需求管理工具,可以幫助團隊有效地管理軟體需求。

第八周作業

1 理解窗體的檔案含義及組織結構 如 form1.cs form1.designer.cs form1.resx 控制項的屬性 方法和事件。2 完全用 的方式在form1.cs檔案中建立乙個文字標籤物件label1,用 設定label1的parent location name text autos...

第八周作業

1 顯示統計占用系統記憶體最多的程序,並排序 2 編寫指令碼,使用 for 和 while 分別實現 192.168.0.0 24 網段內,位址是否能夠 ping 通,若 ping 通則輸出 success 若 ping 不通則輸出 fail 3 每週的工作日 1 30,將 etc 備份至 back...

第八周作業

本週是團隊專案的最後一周,我們的團隊專案也完成了大部分的工作。下面是我們近兩周的工作內容,以及我在這個團隊專案中的總結與心得體會。我們小組所進行的專案是仿照手遊 球球大作戰 製作3d的pc版遊戲。到目前為止,我們已經完成了大部分文件與編碼工作,還差測試文件的成型 其它文件的細節修改與一些bug的修補...