軟件需求第5章-資料下載頁
2024-09-04 13:24本頁面
【導讀】員Helen和首席測試員Ramesh。他們對新項目都很有興趣，但他們也記得在以前一個稱作?！八幤贩抡妗钡捻椖恐杏龅降膯栴}。“的確是煩人，”Dave附和道。樣的交互導致編碼花費了預計時間的三倍，我們是不管好歹，編完了事，簡直是廢品！“我們太匆忙了，以至沒有時間寫詳細的需求說明”Ramesh回憶道?！皽y試人員有一半。一些功能根本就不是用戶所要求的。Dave補充道：“于是我們不斷遇到要求新的特性及各種變更，所以工程超期。學制品跟蹤系統(tǒng)中避免重蹈覆轍。正如Dave的最后一句話所反映的那樣，軟件工程師都是絕對的樂觀主義者。脅阻礙項目按計劃進行。與Dave的想法恰恰相反的是，軟件項目管理者必須要明確和控制。所謂風險是可能給項目的成功帶來威脅或損失的情況。發(fā)生的可能性或減少其帶來的影響。風險分析中，應檢查一些特定風險對項目可能造成的潛在后果。應急計劃、負責人和截止日期。少每項風險的執(zhí)行計劃。情況，可以定期地修訂先前風險清單的內(nèi)容和劃分的優(yōu)先級。
【正文】 ，用于定義所有的業(yè)務(wù)和技術(shù)詞匯，以防止它被不同的讀者理解為不同的意思。特別是要說明清楚那些既有普通含義又有專用領(lǐng)域含義的詞語。對 SRS的評審能夠幫助參與者對關(guān)鍵術(shù)語、概念等達成一致的共識。 需求說明中包括了設(shè)計 。包含在 SRS中的設(shè)計方法將對開發(fā)人員 造成多余的限制并妨礙他們進行最佳設(shè)計的創(chuàng)造性。仔細評審需求說明以確保它是在強調(diào)解決業(yè)務(wù)問題需要做什么，而不是在說怎么做。 需求驗證 未經(jīng)驗證的需求 。審查相當篇幅的 SRS這是有些令人沮喪的，這正如要在開發(fā)過程早期編寫測試用例一樣。但如果在構(gòu)造設(shè)計開始之前通過驗證基于需求的測試計劃和原型測試來驗證需求的正確性及其質(zhì)量，就能大大減少項目后期的返工現(xiàn)象。在項目計劃中應為這些保證質(zhì)量的活動預留時間并提供資源。從客戶代表方獲得參與需求評審的贊同（承諾），并盡早且以盡可能低的成本通過非正式的評審逐漸到正式評審來找出其存在 的問題。 審查的有效性 。如果評審人員不懂得怎樣正確地評審需求文檔和怎樣做到有效評審，那么很可能會遺留一些嚴重的不足之處。故要對參與需求文檔評審的所有團隊成員進行培訓，請組織內(nèi)部有經(jīng)驗的評審專家或外界的咨詢顧問來講座、授教以幫助使評審工作更加有效。 需求管理 變更需求 。將項目視圖與范圍文檔作為變更的參照基礎(chǔ)可以減少項目范圍的延伸。用戶積極參與的具有良好合作精神的需求獲取過程可把需求變更減少近一半（ Jones 1996a）。能在早期發(fā)現(xiàn)需求錯誤的質(zhì)量控制方法可以減少以后發(fā)生變更的可能。而為了減少需求變更的影響， 將那些易于變更的需求用多種方案實現(xiàn)，并在設(shè)計時更要注重其可修改性。 需求變更過程 。需求變更的風險來源于未曾明確的變更過程或采用的變動機制無效或不按計劃的過程來做出變更。應當在開發(fā)的各階層都建立變更管理的紀律和氛圍，當然這需要時間。需求變更過程包括對變更的影響評估，提供決策的變更控制委員會，以及支持確定重要起點步驟的工具。 未實現(xiàn)的需求 。需求跟蹤能力矩陣有助于避免在設(shè)計，結(jié)構(gòu)建立及測試期間遺漏的任何需求。也有助于確保不會因為交流不充分而導致多個開發(fā)人員都未實現(xiàn)某項需求。 擴充項目范圍 。如果開始未很好定義需求， 那么很可能隔段時間就要擴充項目的范圍。產(chǎn)品中未說明白的地方將耗費比預料更多的工作量，而且按最初需求所分配好的項目資源也可能不按實際更改后用戶的需求而調(diào)整。為減少這些風險，要對階段遞增式的生存期制定計45b3ab679e853e21c524018e30c33611 49 劃，在早期版本中實現(xiàn)核心功能，并在以后的階段中逐步增加實現(xiàn)需求。 風險管理是你的好助手 項目管理人員可以運用風險管理來提高對造成項目損失的條件的警惕，在需求獲取階段要有用戶的積極參與。精明的管理者不僅能認識到它能帶來風險的條件，而且將它編入風險清單，并依據(jù)以往項目的經(jīng)驗估計其可能性和影響。如果用戶一直沒有參與，風 險危害值將會擴大以至危害項目的成功。我曾說服管理人員把項目延期是由于缺少用戶的積極參與，我告訴他們不能把公司的資金投入一項注定要失敗的項目。 周期性的風險跟蹤能使管理人員保持對風險危害變化的了解，對那些并未得到完全控制的風險能得到高層管理人員的注意。他們要么開始采取一些矯正措施，要么不管風險，依舊按原業(yè)務(wù)決策思路進行。即使不能控制項目可能遇到的所有風險，但風險管理能使你看清形勢，做出的決策是有依據(jù)的。 下一步： ? 明確 你當前項目面臨的一些與需求有關(guān)的風險，不要把當前的問題當作風險，一 定要是那些還未發(fā)生的事情。將風險因素用條件 —— 結(jié)果形式編寫成文檔， 正如 圖 52模板所示的那樣。為每項風險推薦至少一種可能的降低風險的方法。 ? 召集代表開發(fā)、市場、客戶和管理各方面的風險承擔者召開風險“集體研討”會 議。盡力找出更多與需求有關(guān)的風險因素。估計每項風險發(fā)生的可能性及其影響 ， 并將兩者乘積起來得到風險危害值。通過按風險危害值降序排列找到最高的五項風險。為每項風 險安排一個負責人負責實施降低風險的活動。
公司管理相關(guān)推薦
鄂ICP備17016276號-1