Transcript 下載/瀏覽
第14章 功能限定 碩專資管一甲 洪子原 學號:N9990021 指導老師:陳炳文 本章大綱 •專案早期: 功能簡化 –規格說明最小化 –需求篩選 –版本開發 •專案中期: 功能蔓延的控制 •專案後期: 功能削減 緒論 • 許多研究發現, 需求蔓延是造成費用和時間超出限制最普 遍的原因, 也是專案被取消的主因之一 • 事實上, 晚期破壞性的功能變更和軟體的進度延遲,這兩 者現象存在因果關係 • 一般在成功的專案裡, 會綜合使用功能限定的三種方法: 專案早期控制-功能簡化 專案中期控制-功能蔓延的控制 專案後期控制-功能削減 14.1專案早期控制-功能簡化 • 一個專案早期階段的功能限定主要就是別把不必要的功能 引入到產品的早期原型中 • Kerr&Hunter指出快速開發的訣竅,就是縮小範圍 • 縮小範圍的三種方式: – 規格說明最小化 – 需求篩選 – 版本開發 規格說明最小化 •再制定專案的需求時,遇到常見的問題就是 規格說明書需要詳細到什麼程度 •習慣性說法是愈詳細越好 規格說明最小化 •傳統規格說明的缺點: –浪費規格製作投入努力 •可能花費時間描述十分詳細的系統特徵，甚至包含 用戶不關心的特徵。 –退化 •專案中期的變更很快會導致需求說明書的過時。 –缺乏功效 •以十分詳細方式陳述系統需求並不足以保證系統的成功，系統 可以滿足規格說明書的條文，但結果可能令人不滿意。 –過度限制設計 •過度限定軟體可能迫使設計者和實施人員浪費大量時間 規格說明最小化 •撰寫一份最簡的規格說明,應該包含下列元素之一: –簡短的書面規格說明: •軟體文字描述,最好別超過10頁 –起程規格說明: •一次性規格說明,寫完後不做變更 •主要目的是使開發組、客戶、最終用戶對產品具有一共同的視 野。 –用戶手冊式規格說明: •撰寫用戶手冊以代替傳統的規格說明書，並要求軟體與手冊一 致。 –使用者介面雛形: •使用者介面雛行可作為實際的規格說明或對規格說明進行補充 規格說明最小化 –情節圖版 • 簡單的是最好的。當與客戶或最終用戶一起工作，在電腦螢幕上見到 軟體之前，一種快速的、簡易的方法就是在活動掛圖上繪製報告、畫 面和其它的圖形介面元素，並按此設計產品 –視覺陳述 •創造一個可視化陳述，以描述哪些應該放到產品中，哪些應該 可從產品中去掉,描述哪些應該從產品中去除是困難的,但這是 可視化陳敘的基本功能。 –產品主題 •創造一個產品的主題。主題是相對於視覺而定是控制功能的一 個好的機制。 規格說明最小化 最簡規格說明的優點 •改善士氣和動機 •機會和效率 •減少浪費人力 •縮短需求分析階段 最簡規格說明的風險 •忽略關鍵需求 •不清楚或不可能的目標 •鍍金(過度追求具挑戰性的新 領域) •缺乏對平行工作的支援 •增加開發者對特殊功能的依戀 •因短期錯誤的原因而使用最小 的規格說明 規格說明最小化 •使用最簡規格說明的關鍵成功因素: –僅當需求具有彈性時使用最小的規格說明 •此方法的成功取決於需求的彈性特徵，假如認為他的實際彈性 比真正表現出來的還小那麼在決定使用最簡規格說明的方法之 前先要採取步驟確定它的彈性。 –保持規格說明的最簡化 •不論採用其中哪種方法,需要弄清楚的目標之一是定義一個最 小的詳細需求。 使用最簡規格說明的關鍵成功因素 –獲取重要的需求 •雖然不必去嘗試獲取用戶不關心的需求，但是必須注意獲取所 有用戶關心的需求。 –採用彈性的開發方法 •所用的開發方法需要對錯誤進行即時的修正，採用取最簡規格 說明的方法比採用傳統的規格定義的方法更容易產生錯誤 使用最簡規格說明的關鍵成功因素 –關鍵用戶的參與 •為軟體尋找瞭解商務需求和組織需求的人，並使他們參與產品 的規格說明和開發中。 –關注圖形化的文件 •在圖表結構、樣本輸出和生動的雛形中的圖型比寫規格說明更 容易創造並且對用戶來說更有意義。 需求篩選(需求修正) 需求篩檢的工作原理 •在建立了一個產品規格之後,對照下列目標檢視規 格說明: –排除所有完全不必要的需求 –簡化所有比實際需求複雜的需求 –用更加容易得到(便宜)的操作替換所有原來的 操作 版本開發 •另一種完全刪除需求的情況是從當前的版 本刪除，可能為穩定的、完全的、理想的 專案策畫一組需求，但這個專案是分塊執 行的。那些以放入用於支援以後各塊模組 的整盒掛鉤 並不會在各塊模組中自己實作 14.2專案中期:功能蔓延的控制 •專案中期會有很多情況引起需求變化: –終端用戶 •由於不同的功能需求或是系統建造的過程中獲得了對 系統進一步的瞭解而希望變更需求。 –市場人員 •市場人員希望變化是因他們是以功能驅動去觀察市場。 –開發者 •他們希望變更是因為系統中每一個細節都蘊含著他們 情感和智力的投資。 14.2專案中期:功能蔓延的控制 •造成需求變化的重要原因如下: –殺手級應用程式綜合症 • 套裝軟體特別容易受此症狀影響 –不清楚或不可能的目標 • 為專案制訂一個野心勃勃的目標是一個很難抗拒的 事情,通常可能希望以最短的時間, 最少的費用開發 一個世界級的產品 14.2專案中期:功能蔓延的控制 •變更的影響:低估了變更對專案設計、程式 碼、測試、文件、用戶支援、培訓、組態 管理、人員分配、管理與溝通、計畫和追 蹤以及最終對進度、預算和產品品質所引 起的連鎖反應。 14.2專案中期:功能蔓延的控制 •完全停止變更是最好的 ,但在下列情況做 出變更是必需的: –當客戶不了解他們真正的需求 •再需求第一階段假設你的用戶瞭解他們的需求,再設計和程式 編碼開始前,假設對最初的需求真正了解,就可以拒絕對需求進 行變更。 –當你需要對客戶做出回應 •即使認為你的用戶對他們的需求瞭解的時候,還是應該保持軟 體的靈活性和操作的開放性。 14.2專案中期:功能蔓延的控制 –當市場快速變化 •在早期.企業需要進行變更時往往比現在的要慢,從計劃實現產 品細節到產品發佈需要2年時間。而現今大部份成功的產品常 常將大量的產品變更的實作放在開發周期的最後 –當你希望授權開發人員彈性調整一個自由度的 時後 •如果希望將部分有關產品概念的部分交給開發人員處理,就不 能在需求規格定義一完成就凍結 這個產品概念,應將部分內容開放,以變於篩選 14.2專案中期:功能蔓延的控制 •變更管理計劃的目標: –在可用時間裡,允許那些有助於產品生產的變更。 –允許那些受到變更建議影響的當事人對變更的進度計 劃、資原和產品的效果進行評價。 –向每一個計畫變更的專案周圍當事人通報對它的影響 的評價，以及是否被接受或拒絕。 –提供與專案內容有關的審核結果。 14.2專案中期:功能蔓延的控制 •變更的控制方法: –客戶導向的需求實踐 • 一個變更控制的策略是長是讓需要變更的數量保持最小與傳統的實踐 相比,用戶導向的需求蒐集的實踐是誘導真正需求得較好工作方法 –變更分析 • 可透過變更分析過程篩選出多餘的變更內容,提出有關變更對費用和 進度的影響,說明必須調整進度計劃，因為需要花費時間去分析新功 能需求。 –版本2 •建立一個未來需要增加內容的列表。 •可以理解只在版本1中沒這些特性,而在版本2中將會有。 –縮短發佈周期 •短的發佈周期•短的發佈周期能夠幫助建立信心 讓客戶相信他們關心的功能 最終會加到產品中 –變更委員會 •變更控制委員以被證明能夠有效阻止大型專案中需求蔓延 •並且對於小型專案也是有效的。 14.3專案後期:功能削減 •即使在專案前期的最小功能說明和專案中 期控制變更還是成功的,但仍可能發現在專 案結束時還是進度落後 •此時最有效的發法是刪除低優先等級的功 能,因也去除了進一步的實作、測試和文件 有關的工作量。(這方法常被微軟使用) 最大功效 •從需求文件中篩選,設計和實作將在產品中出現的 功能,然後有時間再將低優先等級的功能加進去,不 在把時間浪費在那些後期會被削減的功能上。 Thank you for your attention! Merry X’mas~~~~~~