面向?qū)ο筌浖_發(fā)過程初始階段

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

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