面向對象軟件開發(fā)過程初始階段第1頁，共28頁，2023年，2月20日，星期四提綱§7b.1POS案例§7b.2初始階段的主要工作§7b.3需求類型§7b.4用例模型：寫出實際語境中的需求§7b.5識別其他需求§7b.6從初始階段到細化階段2第2頁，共28頁，2023年，2月20日，星期四§7b.1POS案例POS系統(tǒng)：記錄銷售信息，處理支付過程，常用于零售店。系統(tǒng)包括：硬件：計算機，條碼掃描器軟件：與其他系統(tǒng)連接：第三方稅金計算器和庫存控制系統(tǒng)系統(tǒng)要求：相對容錯：庫存系統(tǒng)故障不影響銷售和付款，即：如果遠程服務（庫存系統(tǒng)）暫時中斷，系統(tǒng)必須能夠獲取銷售信息和處理現(xiàn)金付款，不至于營業(yè)癱瘓。多客戶終端：瘦客戶Web終端、PC、觸摸屏、無線PDA易于客戶化，如不同用戶在開始一個新的銷售或增加新商品時要求執(zhí)行一些額外的業(yè)務邏輯，系統(tǒng)應該靈活支持。3第3頁，共28頁，2023年，2月20日，星期四§7b.2初始階段的主要工作初始階段應該考慮以下問題：項目的構想怎么樣？商業(yè)案例是什么？可行性如何？購買還是開發(fā)？粗略估計一下成本，估計收益。項目是否停止或繼續(xù)進行？主要目標：只進行一定的研究，得到未來新系統(tǒng)的可行性以及實現(xiàn)系統(tǒng)總體目標的合理判斷，并確定是否值得繼續(xù)深入研究系統(tǒng)即可。（深入的研究是細化階段的工作）概括為：預見項目的范圍、構想和商業(yè)案例；項目相關人員是否就項目的構想達成基本的一致，項目是否值得繼續(xù)進行認真的研究。4第4頁，共28頁，2023年，2月20日，星期四§7b.2初始階段的主要工作初始階段的時間比較短暫，只要建立起初始的一般構想，并確定項目是否可行，是否值得細化研究就行。工件注解構想和商業(yè)案例描述高層的目標和約束、商業(yè)案例，并提供一個執(zhí)行摘要用例模型描述功能需求和相關的非功能需求(10%)補充規(guī)范描述其他需求術語表關鍵的領域術語風險列表和風險管理計劃描述業(yè)務、技術、資源和進度上的風險，以及如何減輕這些風險或該如何應對。原型和概念驗證闡明構想，驗證技術問題迭代計劃描述在第一次細化迭代中該做什么？階段計劃和軟件開發(fā)計劃對細化階段的持續(xù)時間和工作量進行低精度的猜測。開發(fā)涉及的工具、人員、培訓和其他資源。開發(fā)案例描述為本項目定制的統(tǒng)一過程的步驟和工件。在統(tǒng)一過程中，總需求為項目定制一些步驟或工件。5第5頁，共28頁，2023年，2月20日，星期四§7b.3需求類型需求就是系統(tǒng)必須提供的能力和必須遵從的條件。需求管理更推崇用“一種條理化的方法來尋找、記錄、組織和跟蹤系統(tǒng)不斷變化的需求”。需求類型：FURPS＋Function（功能）：特性、能力、安全性Usability（可用性）：人性化因素、幫助和文檔；Reliability（可靠性）：故障周期、可恢復性、可預測性；Performance（性能）：響應時間、吞吐量、準確性、有效性、資源利用率；Supportability（可支持性）：適應性、可維護性、國際化、可配置性。＋：一些輔助性和次要的因素。Implementation（實現(xiàn)）：資源限制、語言和工具、硬件等；Interface（接口）：與外部系統(tǒng)接口所加得約束；Operations（操作）：系統(tǒng)操作環(huán)境中的管理Package（包裝）Legal（授權）：許可證或其他方式。6第6頁，共28頁，2023年，2月20日，星期四§7b.4用例模型：寫出實際語境中的需求系統(tǒng)需求：為了滿足客戶使用系統(tǒng)的目的。用例：就是描述客戶如何使用系統(tǒng)來達到目的的一組情節(jié)。以此來發(fā)現(xiàn)和記錄系統(tǒng)的功能性需求。用例描述功能性需求的思想是由IvarJacobson在1986年提出來的，表達的主要思想是：在需求分析中專注于考慮系統(tǒng)怎么才能增加價值和實現(xiàn)目標。在面向用戶目標的語境中考慮系統(tǒng)的功能和特性，這是用例的分析關鍵。用例模型是文本文檔，UML中的用例圖只是給出了角色和用例的名稱和關系。7第7頁，共28頁，2023年，2月20日，星期四§7b.4用例模型：寫出實際語境中的需求黑箱用例Black-boxusecases——推薦使用將系統(tǒng)描述為具有某種職責,描述系統(tǒng)必須做什么（功能需求），而非如何做（設計），即：將系統(tǒng)看成一個黑箱，觀察系統(tǒng)的外部行為：如：系統(tǒng)記錄銷售信息√系統(tǒng)將銷售寫入數(shù)據(jù)庫×系統(tǒng)為銷售生成INSERTSQL語句××8第8頁，共28頁，2023年，2月20日，星期四§7b.4用例模型：寫出實際語境中的需求用例建模的基本過程：1.選擇系統(tǒng)邊界：POS作為一個系統(tǒng)，包含軟件、POS機、輸入終端等，收銀員、支付授權、稅金計算等不包括在系統(tǒng)之內。2.識別主要角色：主要角色：在使用系統(tǒng)服務的過程中滿足自己的用戶目標的那些參與者。找出用戶目標次要角色：為系統(tǒng)提供服務的那些參與者。說明外部接口和協(xié)議后臺角色：對用例的行為感興趣。保證找到并滿足所有必要的興趣。3.識別主要角色的目標一般來講：第2和第3步是同時進行的。9第9頁，共28頁，2023年，2月20日，星期四§7b.4用例模型：寫出實際語境中的需求誰或什么使用該系統(tǒng)？交互中，它們扮演什么角色？誰安裝系統(tǒng)？誰啟動和關閉系統(tǒng)？誰維護系統(tǒng)？與該系統(tǒng)交互的是其他什么系統(tǒng)？誰從該系統(tǒng)獲取信息，誰提供信息給系統(tǒng)？有什么事情發(fā)生在固定時間？角色：_______________角色職責：________________________________角色識別問題：_______________________________________________________________角色描述模板10第10頁，共28頁，2023年，2月20日，星期四§7b.4用例模型：寫出實際語境中的需求誰來啟動和停止系統(tǒng)？誰來進行用戶管理和安全管理？是否存在一個監(jiān)控進程，其在系統(tǒng)錯誤的時候能夠重啟系統(tǒng)？系統(tǒng)升級怎樣處理？主動升級還是被動升級？誰來管理系統(tǒng)？由于系統(tǒng)對時間事件進行響應，“時間”是否也是一個角色？誰來評估系統(tǒng)的活動或性能？誰來評估日志？日志是否能夠遠程獲取？上述問題能夠幫助我們找出容易遺漏的角色和目標11第11頁，共28頁，2023年，2月20日，星期四§7b.4用例模型：寫出實際語境中的需求收銀員：處理銷售、處理租賃、處理返回、入款、出款……經(jīng)理：啟動、關機……系統(tǒng)管理員：添加用戶、修改用戶、刪除用戶、安全管理、系統(tǒng)表管理……銷售活動分析系統(tǒng)：分析銷售數(shù)據(jù)和銷售表現(xiàn)……12第12頁，共28頁，2023年，2月20日，星期四§7b.4用例模型：寫出實際語境中的需求4.定義用例：一般來講，要為每個用戶目標定義一個基本業(yè)務過程（EBP）級別的用例。EBP：由一個人在某個時間某個地點執(zhí)行的一項任務，這項任務是對某一業(yè)務事件的反應，而且能夠增加可以度量的業(yè)務價值，并且能夠保持數(shù)據(jù)狀態(tài)的一致。用例分析時，應該專注于EBP級別的用例。如：“驗證身份”不是EBP級別的用例，是更低級別的用例，但是，由于它是很多EBP用例的前提或者一部分，所以可以單獨寫成用例。但是不要定義過多低級別上的用例，它們只是EBP中的一個步驟。具體步驟？用戶目標企業(yè)目標13第13頁，共28頁，2023年，2月20日，星期四§7b.4用例模型：寫出實際語境中的需求用例的表達簡潔用例：簡明扼要，通常用在主要場景。場景：是角色和系統(tǒng)之間的一系列特定的活動和交互，是用例的實例。臨時用例：非正式的段落格式。詳述用例詳述用例的格式主要參與者：項目相關人員及其興趣：把用例作為項目相關人員與系統(tǒng)之間的行為契約，從而界定系統(tǒng)必須做什么。前置條件：用例執(zhí)行前的條件。后置條件：用例執(zhí)行成功后的保證。14第14頁，共28頁，2023年，2月20日，星期四§7b.4用例模型：寫出實際語境中的需求主要成功場景：（基本流程、典型流程）場景一般記錄三種步驟：角色與系統(tǒng)之間的交互；驗證動作（通常由系統(tǒng)完成）系統(tǒng)完成狀態(tài)改變（如：記錄什么、修改什么）擴展：（替代流程）擴展由兩部分組成：條件和處理。以系統(tǒng)或角色能夠檢測到的某事物作為條件。特殊需求：與用例相關的非功能性需求質量屬性：性能、可靠性、易用性設計約束技術與數(shù)據(jù)的變化列表：描述技術上的設計約束，特別是有關I/O的技術。發(fā)生頻率待解決的問題15第15頁，共28頁，2023年，2月20日，星期四§7b.4用例模型：寫出實際語境中的需求用例：處理銷售主要參與者：收銀員項目相關人員及其興趣：前置條件：收銀員必須已經(jīng)被識別和授權后置條件：存儲銷售信息、準確計算稅金、更新賬目和庫存信息、記錄提成、生成收據(jù)、記錄支付授權服務的許可。主要成功場景：1.顧客攜帶商品到達POS機收費口2.收銀員開始一次新的銷售3.收銀員輸入商品標識4.系統(tǒng)記錄單件商品，并顯示該商品的描述、價格、累加值。價格可以根據(jù)一套定價規(guī)則來計算。

收銀員重復3～4步，直到商品輸入結束。5.系統(tǒng)顯示總值并計算稅金。6.收銀員請顧客付款。7.顧客支付，系統(tǒng)處理支付。8.系統(tǒng)記錄完整的銷售信息，并將銷售和付款信息發(fā)送到外部的記帳系統(tǒng)和庫存系統(tǒng)。9.系統(tǒng)打印收據(jù)10.顧客帶著商品和收據(jù)離開。……16第16頁，共28頁，2023年，2月20日，星期四§7b.4用例模型：寫出實際語境中的需求用例圖1.用例圖要簡單；2.用例的主要工作不是畫圖，而是寫出文本。收銀員支付授權服務處理銷售處理退貨收款分析活動17第17頁，共28頁，2023年，2月20日，星期四§7b.5識別其他需求用例模型只是描述了系統(tǒng)的功能性需求，其他需求放在下列工件中描述：補充規(guī)范：未在用例中描述的FURPS+需求。術語表：術語及其定義，還可以用作數(shù)據(jù)字典。構想（vision）：概述項目的遠景。構想用簡潔的語言表達項目總體想法，包括：項目為什么被提出？有哪些問題？有哪些項目相關人員？他們需要什么？以及提出了哪些解決方案等。定義了項目相關人員對待開發(fā)產(chǎn)品的見解，根據(jù)項目相關人員的主要需要和系統(tǒng)特性來規(guī)定。18第18頁，共28頁，2023年，2月20日，星期四§7b.5識別其他需求補充規(guī)范修訂歷史簡介功能性跨越許多用例的一般功能日志和錯誤處理可插入的業(yè)務規(guī)則安全性可用性人性因素可靠性可恢復性：外部服務發(fā)生錯誤的時候，盡量采用本地方法來解決，以使交易能夠完成。性能19第19頁，共28頁，2023年，2月20日，星期四§7b.5識別其他需求可支持性適應性可配置性實現(xiàn)約束采購的組件免費的開放源碼的組件接口值得注意的硬件及其接口軟件接口領域（業(yè)務）規(guī)則：規(guī)定一個領域或者業(yè)務如何操作，如：信用卡支付需要簽名。法律問題有關感興趣的領域信息20第20頁，共28頁，2023年，2月20日，星期四§7b.5識別其他需求構想修訂歷史簡介定位商業(yè)機會問題綜述產(chǎn)品定位綜述替代方案和競爭對手項目相關人員描述項目相關人員（非用戶）概述用戶概述項目相關人員主要的高級別目標和問題用戶級別目標用戶環(huán)境21第21頁，共28頁，2023年，2月20日，星期四§7b.5識別其他需求產(chǎn)品縱覽產(chǎn)品遠景優(yōu)點概述假設和依賴成本和定價授權和安裝系統(tǒng)特性概述系統(tǒng)特性是系統(tǒng)提供的一個外部可觀測到的服務，這種服務能夠直接滿足項目相關人員的需要。特性是系統(tǒng)能做的事情。系統(tǒng)會做<某特性>其他需求和約束22第22頁，共28頁，2023年，2月20日，星期四§7b.5識別其他需求術語表修訂歷史定義術語定義和相關信息別名23第23頁，共28頁，2023年，2月20日，星期四§7b.6從初始階段到細化階段初始階段的檢驗點：初始階段并非項目的需求階段，而只是一個簡短（為期1周）的步驟，用來決定項目的基本可行性、風險、范疇。細化階段進一步探討需求。初始階段的可能活動和工件包括：一個簡短的需求討論會（為期2天）；命名大多數(shù)的角色、目標和用例。用簡短格式書寫大部分用例；用詳細格式書寫10%～20%的用例，以更好地理解項目的范疇和復雜性。識別最具風險的質量需求。編寫構想和補充規(guī)范的第一個版本。風險列表概念驗證原型和特殊需求的技術可行性研究用面向用戶界面原型澄清功能性需求構想購買/構建/重用什么組件的建議，在細化階段完善組件高層候選架構和組件建議計劃第一次迭代候選工具列表24第24頁，共28頁，2023年，2月20日，星期四§7b.6從初始階段到細化階段細化是這樣的一系列迭代：開發(fā)團隊認真地研究、實現(xiàn)核心架構，闡明主要需求并處理高風險的問題。早期的迭代處理那些業(yè)務上重要的但不含技術風險的場景