軟件需求第5章-展示頁
2024-09-16 13:24本頁面
【正文】 了冰 山，而不是以充足的信心認為船不會沉就以全速挺進。技術風險威脅著高度復雜或很前沿 (readingdge)的開發(fā)項目，缺乏知識是另一種風險源，以及參與者對所用的技術和應用領域很陌生等等。依賴于外界實體，例如一個轉包承攬者或生產重用部件的另一個項目就是一種常見的風險來源。運用這些信息可以使你在風險攻擊項目前處理風險。 不仔細研究是不能把風險攆走的，因此本章對需求風險管理進行簡略的介紹。項目管理者只能通過與客戶、或與客戶代表（如市場人員）的合作來控制需求風險。 45b3ab679e853e21c524018e30c33611 43 由于需求說明在軟件項目中扮演著一個核心的角色，故精明的項目管理者會在初期就指明與需求 相關的風險并積極地控制它們。這將提高項目成功的可能性且可減少不可避免的風險會造成的損失。 正如沒有人能確切地預測未來，風險管理也僅是讓你采取一些措施盡可能減少潛在問題發(fā)生的可能性或減少其帶來的影響。如果不期望的事已經(jīng)發(fā)生了，那就不再是風險，而是事實了。但這些潛在的問題可能會給項目成本費用、進度安排，或技術方面、產品質量、團隊工作效率等帶來較大的負面影響。 所謂風險是可能給項目的成功帶來威脅或損失的情況。帶來的事實卻是許多潛在威脅阻礙項目按計劃進行?！? 正如 Dave 的最后一句話所反映的那樣，軟件工程師都是絕對的樂觀主義者。我不想要任何消極想法影響項目。這個項目還沒有達到需要用風險管理的地步。我看了篇關于軟件風險管理的文章，上面介紹說我們應指出各種風險并說明了怎樣才能避免它們”。若再發(fā)生這樣的事，我肯定會被解雇了?！? “我特別感到麻煩的是，要求開發(fā)藥品仿真的管理者根本沒有看需求規(guī)格說明就在上面簽字確認了。“測試人員有一半的時間都在問程序員怎樣才能判斷他們的程序工作正常，以便能測試它?！? “的確是煩人，” Dave 附和道。 “還記得我們直到進入測試時才發(fā)現(xiàn)用戶對仿真程序的用戶界面極為不滿意嗎？”Helen 問道。45b3ab679e853e21c524018e30c33611 42 第五章 軟件需求與風險管理 負責 Contoso 制藥公司“化學制品跟蹤系統(tǒng)”的項目管理人員 Dave 會見他的首席程序員 Helen 和首席測試員 Ramesh。他們對新項目都很有興趣，但他們也記得在以前一個稱作“藥品仿真”的項目中遇到的問題。 “我們花了五周時間重新實現(xiàn)，重新測試，我可再不愿玩這樣的死亡游戲了?！巴瑯勇闊┑氖悄切┯脩籼岢鲆淮蠖褯]人用過的特性，這樣的交互導致編碼花費了預計時間的 三倍，我們是不管好歹，編完了事，簡直是廢品！” “我們太匆忙了，以至沒有時間寫詳細的需求說明” Ramesh 回憶道?？墒浅绦騿T設計的一些功能根本就不是用戶所要求的?！?Dave 補充道：“于是我們不斷遇到要求新的特性及各種變更，所以工程超期四個月，成本費用超出預算的一倍這也就不足為怪了?！? Ramesh建議道 ：“也許我們應該把在仿真項目中遇到的問題一一列出來以便我們能在化學制品跟蹤系統(tǒng)中避免重蹈覆轍。 “我可不那樣想” Dave 堅持道：“我們已從仿真項目學到了不少，我們不會再有那些問題了。如果要把我們可能犯的錯誤都寫下來，好像我連怎樣做軟件項目都不知道似的。我們必須為成功而制定計劃。我 們總是希望我們的下一個項目進行順利，而不管以前項目發(fā)生的問題。與 Dave 的想法恰恰相反的是，軟件項目管理者必須要明確和控制他們的項目風險，并且是要從需求工程的風險開始進行的。這種情況還并沒有發(fā)生以帶來問題，而你希望它永遠不會發(fā)生。而風險管理 —— 一種軟件工業(yè)的最佳方法 —— 就是在風險給項目帶來損失之前，就指明、評估 并加以控制風險。那只好通過項目事務 (ongoing)狀態(tài)跟蹤和校正過程來處理當前的問題。風險管理的意思是在一種擔憂轉變?yōu)槲C或實際困難之前處理它。對處于個人控制領域之外的風險應由相應層次的管理者來負責。典型的需求風險包括對需求的誤解，不恰當?shù)挠脩魠⑴c，不確定或隨意變更項目的范圍和目標，以及持續(xù)變更需求。合作編寫需求風險文檔，共同制定減輕風險的措施，增強客戶與開發(fā)人員之間的合作伙伴關系，這在第 2 章中已作介紹了。本章后面還會提到需求工程中常出現(xiàn)的一些風險
公司管理相關推薦
鄂ICP備17016276號-1