楊德仁，王曉峰，劉建平，韓 強(qiáng)

（1.寧夏醫(yī)科大學(xué) 理學(xué)院，寧夏 銀川 750004；2.北方民族大學(xué) 計(jì)算機(jī)科學(xué)與工程學(xué)院，寧夏 銀川 750021）

0 引言

軟件工程的難點(diǎn)在于軟件的復(fù)雜性［1］和軟件需求的不確定性［2］。前者可通過(guò)推遲實(shí)施及規(guī)范化軟件過(guò)程加以緩解［3］，后者可通過(guò)應(yīng)用敏捷框架來(lái)解決［2，4］。但規(guī)范化軟件過(guò)程容易導(dǎo)致設(shè)計(jì)麻痹問(wèn)題，敏捷化會(huì)導(dǎo)致論域模糊化等問(wèn)題。以用戶故事（User Stories）為線索，有機(jī)結(jié)合敏捷框架與傳統(tǒng)軟件過(guò)程不失為一種選擇性優(yōu)化方法，其應(yīng)用實(shí)踐（即工程實(shí)踐與教學(xué)實(shí)踐）值得探索［4］。

針對(duì)軟件開(kāi)發(fā)商過(guò)分注重軟件開(kāi)發(fā)周期的規(guī)劃與文檔化，而忽視了至關(guān)重要的問(wèn)題，即如何滿足客戶需求，2001 年17 位軟件領(lǐng)域的專家提出了敏捷概念，開(kāi)啟了敏捷開(kāi)發(fā)的新紀(jì)元，并頒布了敏捷開(kāi)發(fā)宣言。該宣言倡導(dǎo)：個(gè)人與交互勝過(guò)過(guò)程和工具；可工作的軟件勝過(guò)全面的文檔；客戶合作勝過(guò)合同談判；響應(yīng)變化勝過(guò)遵循計(jì)劃，其中3 條涉及客戶（用戶）及其需求。根據(jù)該宣言還制定了12 條敏捷原則［5］，其中大多數(shù)原則涉及客戶（用戶）及其需求或敏捷團(tuán)隊(duì)，諸如：盡早及持續(xù)性交付有價(jià)值的軟件以滿足客戶需求；擁抱需求變化，即使在開(kāi)發(fā)后期；通過(guò)敏捷過(guò)程以駕馭變化，為客戶贏得競(jìng)爭(zhēng)優(yōu)勢(shì)；在執(zhí)行項(xiàng)目過(guò)程中，業(yè)務(wù)人員和開(kāi)發(fā)人員必須每天協(xié)同工作；面對(duì)面的交流是向開(kāi)發(fā)團(tuán)隊(duì)內(nèi)外傳遞信息最有效率且效果最好的方法；敏捷過(guò)程提倡可持續(xù)開(kāi)發(fā)，投資者、開(kāi)發(fā)者和用戶應(yīng)維持穩(wěn)定的開(kāi)發(fā)速度；最好的架構(gòu)、需求和設(shè)計(jì)來(lái)自于自組織團(tuán)隊(duì)；團(tuán)隊(duì)需定期反省如何能更有效地工作，然后相應(yīng)調(diào)整其行為。其余原則涉及到產(chǎn)品的敏捷交付，諸如：頻繁地交付可工作的軟件，交付周期為幾周到幾個(gè)月，周期越短越好；項(xiàng)目建設(shè)要圍繞著有推動(dòng)力的團(tuán)隊(duì)成員，提供其所需的環(huán)境和支援，并給予信任；可工作的軟件是衡量項(xiàng)目進(jìn)度的主要標(biāo)準(zhǔn)；持續(xù)追求技術(shù)上的精益求精與良好的設(shè)計(jì)，以增強(qiáng)敏捷性；以簡(jiǎn)潔為本，這是盡量減少不必要工作量的藝術(shù)。

因此，敏捷框架的核心是以人為本的敏捷團(tuán)隊(duì)，需要用戶全程參與，以克服傳統(tǒng)軟件過(guò)程因用戶的有限參與而導(dǎo)致軟件產(chǎn)品與其需求不一致的問(wèn)題。用戶參與的驅(qū)動(dòng)力之一是講好用戶故事，從而更好地探索軟件需求及其解決方案［2］。例如，在Scrum 框架中把用戶故事作為其產(chǎn)品訂單（Product Backlog）項(xiàng)或沖刺訂單（SprintBacklog）項(xiàng)［6］，在看板中把用戶故事作為工作流中的在制品（Work In Progress/WIP）［7］。正是基于用戶故事，Scrum 團(tuán)隊(duì)可更好地評(píng)估與規(guī)劃sprint 計(jì)劃，以實(shí)現(xiàn)準(zhǔn)確的預(yù)測(cè)及更好的敏捷性，看板團(tuán)隊(duì)還可進(jìn)一步細(xì)化其工作流。

用戶故事及其成功應(yīng)用奠定了其在敏捷框架中的核心地位，也啟示著其在傳統(tǒng)軟件開(kāi)發(fā)過(guò)程中的擴(kuò)展性應(yīng)用，促進(jìn)了敏捷框架與傳統(tǒng)軟件開(kāi)發(fā)過(guò)程的融合。但實(shí)際上，應(yīng)用用戶故事并非一蹴而就，相關(guān)機(jī)制需要不斷進(jìn)行拓展與細(xì)化。

1 相關(guān)研究綜述

在軟件工程中，用戶（User）指軟件的使用者。用戶概念很重要，其是建模的視角之一，但也總是模糊不清，極易與客戶、角色等概念混淆。

在敏捷框架語(yǔ)境中，根據(jù)用戶故事的定義（參見(jiàn)2.1節(jié)），用戶基于角色敘述使用系統(tǒng)的故事。用戶是個(gè)抽象概念，不能一概而論，用戶因其角色而異。例如，業(yè)務(wù)人員及其客戶在使用購(gòu)物軟件時(shí)便扮演著不同角色。

UML 規(guī)定了用例用于捕獲軟件（系統(tǒng)）需求，即系統(tǒng)應(yīng)該做什么，其關(guān)鍵概念是參與者（Actors）、用例和主題［8］。主題代表用例所應(yīng)用的待建系統(tǒng)，與該主題交互的用戶、硬件及其它任何系統(tǒng)角色都被視為參與者。參與者并非具體的物理實(shí)體，而是實(shí)體所扮演的角色。實(shí)體包括人類用戶、外部硬件或其他系統(tǒng)。因此，一個(gè)實(shí)體可扮演多個(gè)角色，一個(gè)角色可由多個(gè)實(shí)體扮演。

Dines［9］提出軟件工程的三段論，即（業(yè)務(wù)）域工程、需求工程和軟件設(shè)計(jì)，建議在開(kāi)發(fā)早期要盡力羅列（業(yè)務(wù)）域涉眾（Stakeholder）及其角色和權(quán)益，并基于涉眾視角進(jìn)行建模。其還指出在整個(gè)工程期間，要基于具體論域，例如需求域、分析域和設(shè)計(jì)域，不斷更新與修正涉眾角色，尤其在需求啟發(fā)階段。

Peter 等［10］提出彩色UML 建模方法，并認(rèn)為（業(yè)務(wù)）域通用模型包括4 種基本架構(gòu)型（Archetypes），并用不同顏色表示。其中，時(shí)刻—時(shí)段（Moment-Interval/MI）代表待處理或跟蹤在某時(shí)刻或某時(shí)段內(nèi)發(fā)生的業(yè)務(wù)，以提醒建模者尋找問(wèn)題域中的重要時(shí)刻或時(shí)段，用醒目的粉色表示，因其將各組件聯(lián)系在一起，處于核心與靈魂地位。角色（Role）代表參與者的參與方式，用黃色表示。描述（Description）類似于目錄和類別，用藍(lán)色表示。角色扮演者（PartyPlaceThing/PPT）指?jìng)€(gè)人或組織、地點(diǎn)或事物，用綠色表示。PPT 和角色具有一對(duì)多與多對(duì)一關(guān)系，例如：一個(gè)事物在制造過(guò)程中扮演一個(gè)角色，而在營(yíng)銷過(guò)程中又扮演另一個(gè)角色，一個(gè)人可能既是雇員又是客戶，一個(gè)店面既可以是零售店，也可以是批發(fā)店。

Jacobson 等［11］提出的用例2.0 軟件方法以講故事和按片構(gòu)造系統(tǒng)為原則，并把用戶故事定義為用例切片以驅(qū)動(dòng)軟件開(kāi)發(fā)。在用例2.0 中，用戶故事被作為用例切片進(jìn)行迭代開(kāi)發(fā)，而失去了探索軟件需求的意義。

在上述方法中，角色的體現(xiàn)形式及應(yīng)用范圍不一，具體如表1 所示。

Table 1 Roles and corresponding manifestations and applications表1 角色及其體現(xiàn)形式與應(yīng)用范圍

Resketi 等［12］提出一種概括用戶故事的方法，借助于修正的詞和動(dòng)詞解析器，提取關(guān)鍵字與關(guān)鍵動(dòng)詞的集合，自動(dòng)生成用戶故事，之后由專家進(jìn)行改進(jìn)，以備在未來(lái)開(kāi)發(fā)相似的系統(tǒng)中重用。

用戶故事作為探索需求的基礎(chǔ)與手段，也被擴(kuò)展到傳統(tǒng)軟件開(kāi)發(fā)過(guò)程中?；贛DA 的模型轉(zhuǎn)化理念［13］，采用自然語(yǔ)言處理技術(shù)，Meryem 等［14］提出一種將用戶故事轉(zhuǎn)換為用例的過(guò)程，而忽視了用戶故事與用例不在一個(gè)抽象層次。Samia 等［15］探索直接從用戶故事提取設(shè)計(jì)層次類圖的方法，但這種類圖缺乏軟件的控制類和窗體類，其完整性值得商榷。

上述研究為應(yīng)用用戶故事奠定了基礎(chǔ)，但除Peter 等［10］的架構(gòu)型和Dines［9］的三段論外，其它研究均未涉及業(yè)務(wù)域。認(rèn)知與解決軟件的復(fù)雜性必須基于其應(yīng)用的業(yè)務(wù)域，這是彩色UML 建模、領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)［16］及三段論等新型軟件開(kāi)發(fā)方法所提倡的。

基于筆者提出的雙論域?qū)哟位浖？蚣埽?7］，本文擬探索用戶故事的來(lái)源、擴(kuò)展及其建模機(jī)制。

2 用戶故事及其分析

在軟件開(kāi)發(fā)與項(xiàng)目管理過(guò)程中，需要以日常語(yǔ)言或商務(wù)用語(yǔ)編寫(xiě)句子式的用戶故事。其只要求寫(xiě)出最有價(jià)值而不能被忘記的用戶期望，以幫助確定軟件需求、估算工作量以及與客戶溝通。

用戶描述是敏捷框架中最小的工作單元，其是從軟件用戶角度表達(dá)的最終目標(biāo)，而不是特性（用戶需求）。用戶故事是從最終用戶或客戶角度編寫(xiě)的針對(duì)軟件特性非正式、一般的解釋。用戶故事的目的是闡明一項(xiàng)工作將如何向客戶交付具體價(jià)值。

2.1 定義及其分析

用戶故事用簡(jiǎn)單語(yǔ)句來(lái)表示，其定義及模板為：As a［persona］，I［want to］，［so that］［2，4，7］，即：作為<某角色>，我<想做>，<以實(shí)現(xiàn)>。其語(yǔ)義如下所述：

作為某角色：描述在為誰(shuí)建造軟件，這不是頭銜職位，而是人物角色。團(tuán)隊(duì)?wèi)?yīng)該對(duì)該角色有共識(shí)，并希望采訪他以了解其工作方式。

想做：描述用戶意圖，即要達(dá)到的目的。其并非使用功能，也無(wú)實(shí)施細(xì)節(jié)，例如圖形用戶界面。

以便：描述待做的事情要符合的大局，即總利益或要解決的大問(wèn)題，這也是衡量其優(yōu)先度的標(biāo)準(zhǔn)。

值得注意的是，一個(gè)用戶故事只能有一個(gè)用戶角色且只做一件事，以便實(shí)現(xiàn)一個(gè)用戶目標(biāo)。

用戶故事描述用戶操作軟件的簡(jiǎn)單情境，以便開(kāi)發(fā)者與客戶進(jìn)行有效溝通，并盡快貼近用戶真實(shí)需求。通過(guò)這種對(duì)使用情境的描述，客戶可以輕松排定其優(yōu)先順序，即按照重要性依次為：必需部分（Must Have）、應(yīng)有部分（Should Have）和最好有部分（Nice to Have）。在敏捷迭代過(guò)程中，先做必需部分，再做應(yīng)有部分，可暫時(shí)不做最好有部分［4］。

2.2 INVEST 屬性

用戶故事有助于將關(guān)注點(diǎn)從編寫(xiě)需求轉(zhuǎn)移到討論需求。除書(shū)面語(yǔ)句外，其作為啟發(fā)需求的手段，本身只是一個(gè)約定，需要與用戶展開(kāi)一系列對(duì)話以探索并澄清需求。因此，Jeffries 等［18］總結(jié)了開(kāi)發(fā)用戶故事的“3C”原則，即卡片（Card）、對(duì)話（Conversation）和確認(rèn)（Confirmation）。要求把用戶故事寫(xiě)在記事卡上，以記錄概述、估算工作量等，在計(jì)劃或估算時(shí)則需要故事的細(xì)節(jié)性對(duì)話，以測(cè)試與驗(yàn)收方式確認(rèn)故事的完整性和正確性。

用戶故事應(yīng)具備6 個(gè)屬性，即獨(dú)立性、可協(xié)商性、有價(jià)值性、可預(yù)測(cè)性、短小精悍以及可測(cè)試性。Bill 使用這些屬性的首字符縮寫(xiě)詞INVEST 表示用戶故事的評(píng)估標(biāo)準(zhǔn)［19］。

獨(dú)立性：盡可能避免故事之間產(chǎn)生依賴關(guān)系，否則會(huì)導(dǎo)致優(yōu)先級(jí)和規(guī)劃問(wèn)題。

可協(xié)商性：故事是可協(xié)商的，不必是書(shū)面合同或者需求。

有價(jià)值性：讓用戶編寫(xiě)故事，確保故事有價(jià)值。

可預(yù)測(cè)性：開(kāi)發(fā)者應(yīng)能預(yù)測(cè)故事規(guī)模以及實(shí)施所需時(shí)間。

短小精悍：應(yīng)在一個(gè)沖刺周期內(nèi)完成，為此需要分解史詩(shī)級(jí)用戶故事，即epic。

可測(cè)試性：故事必須是可測(cè)試與驗(yàn)證的。

2.3 局限性

用戶故事通常只是口頭性描述而無(wú)法精準(zhǔn)反映出軟件需求，并因碎片化而呈現(xiàn)出一些局限性。具體而言，一是在現(xiàn)實(shí)中用戶所要非所需，即使所要是所需，軟件需求也會(huì)隨著市場(chǎng)變化而改變；二是在設(shè)計(jì)系統(tǒng)前，用戶故事其實(shí)只是用戶期盼；三是用戶故事沒(méi)有包含待更正的系統(tǒng)缺陷；四是層次不明，在系統(tǒng)開(kāi)發(fā)之前，其實(shí)只有業(yè)務(wù)工人及客戶，即用戶的體現(xiàn)因其論域而異；五是用戶故事只是零碎的使用情景設(shè)想，抽象層次不高，容易陷入細(xì)節(jié)而難免顧此失彼［4］，用戶故事也不同于用例，充其量只對(duì)應(yīng)于用例的常用路徑，而沒(méi)有顧及用例的備用路徑和容錯(cuò)路徑；六是用戶故事中的用戶與業(yè)務(wù)脫節(jié)而無(wú)法溯源。

因此，作為軟件需求的探索機(jī)制，用戶故事及其應(yīng)用需要進(jìn)行向上溯源與向下擴(kuò)展實(shí)踐探索。

3 用戶故事擴(kuò)展與應(yīng)用實(shí)踐

針對(duì)用戶故事的上述局限性，有必要探究其在軟件開(kāi)發(fā)過(guò)程中的各種體現(xiàn)形式及其實(shí)踐機(jī)制，以及源泉和演化機(jī)制。

3.1 用戶故事擴(kuò)展

若只從軟件使用層面描述用戶設(shè)想，用戶故事則顯得唐突和不足。其實(shí)，用戶故事并非只是涉及軟件用戶的故事，因此“用戶”應(yīng)擴(kuò)展為“角色”。遠(yuǎn)離業(yè)務(wù)的用戶故事無(wú)助于確定軟件需求，況且在業(yè)務(wù)層面上軟件用戶角色尚不存在，只有客戶角色和業(yè)務(wù)工人角色。客戶有業(yè)務(wù)需求，業(yè)務(wù)工人有滿足該需求的責(zé)任和義務(wù)，可借鑒銷售員角色加以實(shí)施。

在軟件需求層次，用戶有使用軟件的宏觀需求，即軟件功能。用戶來(lái)源于上述客戶和業(yè)務(wù)工人，此外還來(lái)源于軟件維護(hù)人員，而這種宏觀需求不能脫離其業(yè)務(wù)語(yǔ)境。在軟件分析層次，用戶有使用軟件的具體路徑，這便是傳統(tǒng)用戶故事或用例事件路徑的內(nèi)涵。如上所述，在用例2.0中，這種用戶故事被定義為用例切片［11］。在實(shí)施層面，開(kāi)發(fā)者通過(guò)編程以滿足用戶故事，測(cè)試者檢查軟件功能及其缺陷。其中，測(cè)試者來(lái)源于軟件用戶和開(kāi)發(fā)者。

經(jīng)上述拓展與細(xì)化，形成了一種擴(kuò)展的用戶故事（an Extended User Stories/EUS），既體現(xiàn)在不同層面（論域），又被分解為各論域中的相應(yīng)角色，例如業(yè)務(wù)層面的客戶與工人，以及軟件層面的用戶、開(kāi)發(fā)者與測(cè)試者，如圖1、圖2 所示。

相應(yīng)地，這種擴(kuò)展的用戶故事格式應(yīng)有所調(diào)整，例如：作為<客戶>，我<想>，<以便>；作為<業(yè)務(wù)工人>，<我想>，<以便>，依次類推。值得指出的是，這種故事還應(yīng)與其論域及層次性相吻合。

Fig.1 Schematic diagram of RUS and its application圖1 RUS 及其應(yīng)用示意圖

Fig.2 Schematic diagram of roles’overlap圖2 角色重疊性示意圖

3.2 EUS 角色及其演變

基于圖1 所示的角色來(lái)源及其重疊性，“用戶”角色的演變歷程如圖3 所示。軟件用戶來(lái)源于客戶和業(yè)務(wù)工人，測(cè)試者來(lái)源于開(kāi)發(fā)者和用戶。

Fig.3 Schematic diagram of“user”role and its evolution圖3 “用戶”角色及其演變示意圖

由圖3 可知，有些角色出現(xiàn)在不同層次上，其相應(yīng)的故事粒度也不同，換言之，EUS 具有層次性。例如客戶和工人出現(xiàn)在業(yè)務(wù)域的不同抽象層次上，其故事即要做的事情和目的則各不相同，在軟件域中的用戶故事也一樣。參見(jiàn)本文3.3 節(jié)的實(shí)踐集及其案例中的論述。

3.3 EUS 實(shí)踐路徑探索

在軟件工程項(xiàng)目實(shí)踐與教學(xué)實(shí)踐中，以EUS 為線索驅(qū)動(dòng)軟件開(kāi)發(fā)，相關(guān)路徑需要作進(jìn)一步探索。

3.3.1 EUS 工程實(shí)踐路徑

在業(yè)務(wù)域，業(yè)務(wù)客戶和業(yè)務(wù)工人是關(guān)鍵角色，有必要確定客戶的業(yè)務(wù)需求和業(yè)務(wù)工人的業(yè)務(wù)服務(wù)。在軟件需求域，軟件用戶是關(guān)鍵角色?；诳蛻?、業(yè)務(wù)工人和軟件管理者等視角，確定用戶角色及其軟件需求，這種需求是高層次的抽象需求。在軟件分析域，讓用戶敘述傳統(tǒng)意義下的用戶故事，并實(shí)施優(yōu)先度排序。

若有必要，在設(shè)計(jì)域，設(shè)計(jì)師設(shè)計(jì)軟件開(kāi)發(fā)的藍(lán)圖，例如面向?qū)ο蟮撵o態(tài)模型（類圖）、動(dòng)態(tài)模型（序列圖和狀態(tài)機(jī)圖）和數(shù)據(jù)庫(kù)表模型等。在實(shí)施域（編碼和測(cè)試），開(kāi)發(fā)者（程序員）進(jìn)行編碼，測(cè)試者制定測(cè)試案例并根據(jù)軟件分析域中的用戶故事（用例切片）進(jìn)行測(cè)試，以發(fā)現(xiàn)其缺陷。

3.3.2 EUS 教學(xué)實(shí)踐路徑

在軟件工程課程實(shí)踐中一般通過(guò)分組實(shí)施課程項(xiàng)目，以培養(yǎng)團(tuán)隊(duì)的協(xié)作精神。根據(jù)項(xiàng)目需要，小組成員在各個(gè)論域中扮演不同角色，以便講好相應(yīng)故事。若扮演角色有困難，可采用業(yè)務(wù)域的實(shí)踐集（參見(jiàn)3.3 節(jié)）或（頭腦）事件風(fēng)暴會(huì)議的形式［20］。

除扮演角色外，項(xiàng)目小組還應(yīng)設(shè)置組長(zhǎng)和秘書(shū)角色，以便協(xié)調(diào)團(tuán)隊(duì)工作并記錄設(shè)計(jì)結(jié)果。

3.4 基于論域的EUS 實(shí)踐集與門(mén)診業(yè)務(wù)案例

實(shí)踐集是敏捷框架的關(guān)鍵要素之一，有助于克服傳統(tǒng)軟件開(kāi)發(fā)過(guò)程中的設(shè)計(jì)麻痹問(wèn)題［2］。論域建模，即業(yè)務(wù)域、需求域、分析域和設(shè)計(jì)域建模都需要相應(yīng)的實(shí)踐集［4］?，F(xiàn)以業(yè)務(wù)域?yàn)槔?，探索并給出其實(shí)踐集。

3.4.1 業(yè)務(wù)域?qū)嵺`集框架

在業(yè)務(wù)域，用戶角色包括顧客、業(yè)務(wù)工人（可細(xì)分為主控業(yè)務(wù)工人、輔助業(yè)務(wù)工人）等，這些用戶故事描述相關(guān)涉眾（或稱為參與者）在業(yè)務(wù)域中的關(guān)鍵行為。相關(guān)故事其實(shí)在描述涉眾及其需求或事務(wù)（動(dòng)作），其中客戶故事分為業(yè)務(wù)需求故事和業(yè)務(wù)參與故事。實(shí)踐集主要包括以下內(nèi)容：

（1）責(zé)任驅(qū)動(dòng)設(shè)計(jì)。每個(gè)涉眾都有其需求或責(zé)任，在業(yè)務(wù)域中，實(shí)現(xiàn)客戶需求正是業(yè)務(wù)服務(wù)提供者的責(zé)任。各涉眾也有其責(zé)任或行為，主要分為事務(wù)級(jí)和動(dòng)作級(jí)兩個(gè)層次［21］。

（2）業(yè)務(wù)域建模風(fēng)暴。具體細(xì)化為業(yè)務(wù)目標(biāo)建模、業(yè)務(wù)狀態(tài)建模、業(yè)務(wù)事務(wù)建模及其編排、業(yè)務(wù)事務(wù)分解及其動(dòng)作建模等步驟。

（3）業(yè)務(wù)需求建模?；诳蛻粢暯菫榭蛻粜枨蠼?。

（4）業(yè)務(wù)狀態(tài)建模。基于業(yè)務(wù)實(shí)施過(guò)程中關(guān)鍵信息子（諸如單據(jù)和報(bào)表等）的變化，確定業(yè)務(wù)狀態(tài)及其轉(zhuǎn)化關(guān)系。

（5）業(yè)務(wù)事務(wù)建模及編排。為上述各轉(zhuǎn)化關(guān)系指定事務(wù)，通過(guò)事務(wù)的實(shí)施促使?fàn)顟B(tài)轉(zhuǎn)化，同時(shí)識(shí)別事務(wù)實(shí)施者即執(zhí)行人。事務(wù)其實(shí)隸屬于過(guò)程中的主體與變體，即人人都有責(zé)任。之后，確定事務(wù)順序和優(yōu)先級(jí)別，一般由主控業(yè)務(wù)工人確定，如門(mén)診業(yè)務(wù)中的坐診大夫。業(yè)務(wù)事務(wù)其實(shí)是業(yè)務(wù)過(guò)程的高級(jí)抽象，因此還需要進(jìn)行分解與細(xì)化，參見(jiàn)下述的動(dòng)作建模。

（6）動(dòng)作建模。參照事務(wù)三段論即準(zhǔn)備、執(zhí)行與遞交結(jié)果，將事務(wù)分解為動(dòng)作集［21］，再確定各動(dòng)作執(zhí)行者，其參考基線是價(jià)值鏈中的活動(dòng)。動(dòng)作還需要完善，如同函數(shù)需要參數(shù)化，動(dòng)作需要業(yè)務(wù)對(duì)象和信息子，其結(jié)果是業(yè)務(wù)過(guò)程模型。其中，業(yè)務(wù)對(duì)象是軟件對(duì)象的基礎(chǔ)，而業(yè)務(wù)需求者和參與者、信息子及其信息化處理是獲取軟件需求的基礎(chǔ)。

除普適性業(yè)務(wù)語(yǔ)言外，業(yè)務(wù)域建模還可采用UML、BPMN 或CMMN，甚至便簽，其它域的實(shí)踐集可參照業(yè)務(wù)域的實(shí)踐集制定［17］。

3.4.2 醫(yī)院門(mén)診業(yè)務(wù)實(shí)踐集案例

以醫(yī)院門(mén)診業(yè)務(wù)為例，列出其擴(kuò)展的用戶及其事務(wù)。擴(kuò)展的用戶角色為：客戶即患者，主業(yè)務(wù)工人為坐診大夫，輔助業(yè)務(wù)工人為收費(fèi)員、化驗(yàn)員、技師和護(hù)士等。相應(yīng)事務(wù)為患者就診、坐診大夫接診與治療、收費(fèi)員收費(fèi)、化驗(yàn)員化驗(yàn)、技師拍片或治療及護(hù)士引導(dǎo)等。

事務(wù)分解以化驗(yàn)為例，坐診大夫開(kāi)化驗(yàn)單，患者繳費(fèi)，化驗(yàn)員化驗(yàn)并給出結(jié)果［21］，其它事務(wù)可據(jù)此進(jìn)行相應(yīng)分解。

4 結(jié)語(yǔ)

軟件需求是軟件開(kāi)發(fā)的基礎(chǔ)，而軟件需求通常難以確定，即使用戶也難以表述清楚，加上市場(chǎng)競(jìng)爭(zhēng)等因素影響，軟件需求會(huì)不斷發(fā)生變化。在迭代開(kāi)發(fā)的基礎(chǔ)上，敏捷開(kāi)發(fā)旨在組建業(yè)務(wù)（用戶）代表全程參與的敏捷團(tuán)隊(duì)以擁抱需求變化。敏捷框架已成為軟件開(kāi)發(fā)的主流技術(shù)，旨在為用戶提供最大價(jià)值。團(tuán)隊(duì)用普適（業(yè)務(wù)）語(yǔ)言交流，以不斷提供的產(chǎn)品增量衡量項(xiàng)目進(jìn)展。但敏捷框架呈現(xiàn)出模型層次不明晰或縮水等現(xiàn)象，混淆了不同論域的元素，超出了人們理解與解決問(wèn)題的極限，違背了抽象與層次化設(shè)計(jì)原理，可能會(huì)弄巧成拙，增加軟件的偶然復(fù)雜性，進(jìn)而導(dǎo)致軟件開(kāi)發(fā)陷入“大泥球”。若基于傳統(tǒng)軟件開(kāi)發(fā)方法如責(zé)任驅(qū)動(dòng)的軟件開(kāi)發(fā)方法，融角色責(zé)任與軟件責(zé)任于一體進(jìn)行探索，則不失為一種有益嘗試，將是未來(lái)研究方向之一［22］。

目前一些知名的IT 國(guó)際咨詢機(jī)構(gòu)，如雅各布森國(guó)際、Rebecca Wirfs-Brock 協(xié)會(huì)都在進(jìn)行敏捷方法與傳統(tǒng)方法融合實(shí)踐的探索及推廣。這種敏捷框架與傳統(tǒng)軟件開(kāi)發(fā)過(guò)程的融合趨勢(shì)值得國(guó)內(nèi)業(yè)界、學(xué)術(shù)界和教育界重點(diǎn)關(guān)注［17］。