高級軟件系統(tǒng)架構(gòu)師培訓（思想與模式）

高級軟件系統(tǒng)架構(gòu)師培訓

第一章軟件架構(gòu)設計思想與體系創(chuàng)建

在軟件組織中，架構(gòu)師的作用是舉足輕重的。本課程針對企業(yè)開發(fā)最關(guān)注的問題深入

研討，抓住投入產(chǎn)出比這個企業(yè)的核心價值，討論架構(gòu)設計如何使這個核心價值得以實現(xiàn)。

我們認為，一個設計如果必須高手云集才能生產(chǎn)出符合質(zhì)量要求的產(chǎn)品，并不一定是好的架

構(gòu)。架構(gòu)設計的目標是力爭使用總體上能力一般的隊伍，通過組織和設計的力量，生產(chǎn)出符

合質(zhì)量要求的產(chǎn)品，從投資回報的角度，兩者效果是完全不一樣的。另一方面，由于需求變

更不可避免，而需求的變更必然造成設計調(diào)整進而造成總體投入的增加，這會極大的影響到

投資回報，所以我們必須研究架構(gòu)設計如何更好的適應變更，通過設計確保變更、維護與升

級的成本下降。對這一系列問題的深入思考，成為現(xiàn)代軟件架構(gòu)設計的核心思維。

軟件企業(yè)必須認真研究如何培養(yǎng)高水平的架構(gòu)人員，但僅僅把架構(gòu)設計作為一個孤立

的節(jié)點來討論，或者僅僅就架構(gòu)談架構(gòu)的在一個很窄的思維空間中研究問題是沒有意義的。

任何設計都來自于目的，我們應該把架構(gòu)設計放在整個項目過程的大環(huán)境下來研究，針對每

個關(guān)鍵節(jié)點對設計的影響特點進行研討，這樣才可能真正理解架構(gòu)設計真正精髓的東西，使

未來的設計工作就會變得極有主動性和想象力。

隨著經(jīng)濟全球化進程的不斷推進，知識經(jīng)濟的時代已經(jīng)到來。要增加軟件產(chǎn)品的國際

競爭力，軟件質(zhì)量作為企業(yè)發(fā)展的戰(zhàn)略問題變得越來越重要，軟件質(zhì)量正被視為軟件企業(yè)的

生命。軟件質(zhì)量管理開始在軟件組織內(nèi)全面開展，強烈的質(zhì)量意識正慢慢扎根于軟件技術(shù)和

管理人員的心靈深處，直至整個組織質(zhì)量文化的形成，所以，如何設計高質(zhì)量的軟件產(chǎn)品，

也成為軟件架構(gòu)設計的重要主題。

統(tǒng)計表明，軟件質(zhì)量問題80%是由需求分析和架構(gòu)設計兩個環(huán)節(jié)造成的，因此，在需

求分析的時候，我們必須研究如何充分理解用戶需求，給各方面提供充分而有效的信息，在

架構(gòu)設計上，研究如何盡可能利用已有信息，合理組織技術(shù)方案，把人和任務作為一個重要

因素進行考慮，在達到質(zhì)量需求的基礎(chǔ)上，使高的投資回報率成為可能，在項目過程管理上,

如何與架構(gòu)設計匹配協(xié)調(diào)，使技術(shù)方案的高質(zhì)量實現(xiàn)成為可能，同時對于產(chǎn)品線架構(gòu)和核心

資產(chǎn)庫構(gòu)建的理論、方法、組織和技術(shù)給于足夠的重視，這都需要項目經(jīng)理、分析師、架構(gòu)

師具有很高的水平。

架構(gòu)設計絕不是某個神秘人物冥思苦想然后又自鳴得意的產(chǎn)物，架構(gòu)設計應該是集體

智慧的成果，軟件設計與開發(fā)也應該是集體共通勞動的結(jié)果，重要的是各種相互矛盾的要求

的合理平衡，這都需要有非常良好的方法，把團隊的智慧集中起來，如何充分激發(fā)集體的智

慧，也是一個架構(gòu)設計師必須具備的能力。

影響這個課程主體的主要思想，是21世紀是軟件規(guī)模經(jīng)濟的時代，下圖表達了工具、

構(gòu)件和過程的三個基本技術(shù)的進步，圖中表達了在假定要求的質(zhì)量和人員等級不變的情況

下，投資回報（ROD的關(guān)系，縱坐標表達了實現(xiàn)軟件的單位成本（代碼行、功能點），橫

坐標表達了軟件規(guī)模，這里表示了隨著時代的進步，同樣規(guī)模的軟件成本在大幅下降，投資

回報在大幅上升。

，成本

相應的環(huán)境、規(guī)模和過程技術(shù)

統(tǒng)的過渡期現(xiàn)代實踐

環(huán)境/工具:定制環(huán)境/工具：商用、單獨的環(huán)境/工具：商用的、集成的

規(guī)橫：100%定制規(guī)模：30■于構(gòu)件規(guī)模：70罐于構(gòu)件

過程：專門的70%定制的30%定制

過程：可重復的過程：以管理的/以度量的

典型的項目性能

要鸚霜內(nèi)

落后于進度進度內(nèi)進度內(nèi)

伴隨著非常大型的項目，比如由系統(tǒng)組成的系統(tǒng)，長生命力的產(chǎn)品以及多個相似項目的

產(chǎn)品線，軟件組織將達到更好的經(jīng)濟規(guī)模。這種規(guī)模軟件經(jīng)濟的理念，對我的設計方法和思

路提出了和過去完全不同的要求，重用、復用和變更促成為重要的主題。

架構(gòu)設計應該從方法論的角度、從質(zhì)量屬性對架構(gòu)設計影響的角度、從建立可度量的

架構(gòu)質(zhì)量保證體系以及安全性和可擴展性的角度，在理論和實踐兩方面全方位研究問題。

1.1軟件架構(gòu)師的角色和應掌握的知識體系

一、軟件架構(gòu)的定義與問題

軟件架構(gòu)(softwarearchiecture)是,組有關(guān)如下要素的重要決策：

軟件系統(tǒng)的組織，構(gòu)成系統(tǒng)的結(jié)構(gòu)化元素，接口和它們相互協(xié)作的行為的選擇，結(jié)構(gòu)化

元素和行為元素組合成粒度更大的子系統(tǒng)的方式的選擇，以及指導這一組織(元素及其接口、

協(xié)作和組合方式)的架構(gòu)風格的選擇。

軟件架構(gòu)是對系統(tǒng)整體結(jié)構(gòu)設計的刻劃，包括全局組織與控制結(jié)構(gòu)，構(gòu)件間通訊、同步

和數(shù)據(jù)訪問的協(xié)議，設計元素間的功能分配，物理分布，設計元素集成，伸縮性和性能，設

計選擇等。

但是，所謂架構(gòu)其實并不僅僅指的是軟件產(chǎn)品體系結(jié)構(gòu)設計，它還包括管理架構(gòu)、過程

架構(gòu)以及質(zhì)量保證架構(gòu)等一系列問題的研究，因為高質(zhì)量軟件并不能只靠一個節(jié)點解決問

題，而是需要有一個全面的解決方案。

重要的是要知道，??個軟件系統(tǒng)的質(zhì)量，很大程度上是由架構(gòu)設計的質(zhì)量決定的，所以,

-2-

研究架構(gòu)設計的思想和方法，成為軟件設計領(lǐng)域中一個十分引人注目的問題。但是很長時間

以來，人們大都把目光關(guān)注在流程、方法、結(jié)構(gòu)原理甚至編碼的本身，而不太注意架構(gòu)設計

最本質(zhì)的東西，思考的深度也欠深入，結(jié)果，很多產(chǎn)品即使設計出來，后期運行中也是問題

百出。這就給我們提出了一個問題，架構(gòu)設計的核心思維到底是什么？什么是好的架構(gòu)設計

呢？

首先，任何軟件系統(tǒng)都是以滿足需求作為目的，所以，好的架構(gòu)設計必須以深入全面的

需求分析作為基礎(chǔ)，事實上架構(gòu)設計是沒有統(tǒng)一的模式的，任何模式只有針對問題才有意義。

作為架構(gòu)設計來說，必須對需求分析有足夠的理解，這樣才能有針對性地解決問題，才可能

設計出真正優(yōu)秀的產(chǎn)品來。但是，如果需求分析本身問題的信息就不足，那怎么可能設計出

解決問題到位的架構(gòu)來呢？

另一方面，任何架構(gòu)思想的實現(xiàn)，都依賴于好的項目管理。項目管理必須與架構(gòu)思想相

匹配才能發(fā)揮作用。一個好的架構(gòu)設計，必須關(guān)注成本，也必須關(guān)注時間，以期在約定的時

間內(nèi)、不超過規(guī)定的成本、生產(chǎn)出符合質(zhì)量要求的軟件產(chǎn)品來。因此，系統(tǒng)架構(gòu)師應該仔細

研究現(xiàn)代項目管理的思想和方法，吃透其中的精髓，根據(jù)自己的設計思想，提出項目管理的

解決方案。

談到項目管理，人們往往想到的是某種規(guī)范，某種文檔模版，甚至某種流程。當然這些

是重要的，不過，無論多么美好的規(guī)范，如果不能和自己的實際情況結(jié)合起來，尤其是和自

己的架構(gòu)特點結(jié)合起來，有的放矢的改進自己的過程，從而達到降低成本提高質(zhì)量的目的，

那什么樣的規(guī)范都是沒有意義的。

作為一個架構(gòu)師來說，上述的討論引發(fā)了三個核心思維，一個是架構(gòu)設計的源泉來自

于需求分析，第二個是架構(gòu)設計重心和特點來自于質(zhì)量需求（非功能性需求），第三個觀點

是，架構(gòu)的實現(xiàn)依賴于好的項目管理。因此，軟件架構(gòu)設計是一個系統(tǒng)工程，它需要系統(tǒng)構(gòu)

架師有很寬的知識面，從需求分析、架構(gòu)設計到類設計甚至代碼實現(xiàn)一直到項目管理都需要

有透徹的理解，這之間的關(guān)系是你中有我我中有你，是不可能截然分開的。必須說明，軟件

系統(tǒng)設計的方法不是一個僵化的規(guī)則，關(guān)鍵是在實踐中實事求是的摸索規(guī)律，從而找出符合

實際達到要求的設計來。

二、軟件復用和系統(tǒng)架構(gòu)

現(xiàn)代軟件架構(gòu)設計的原則來自于軟件復用，軟件復用是指重復使用“為了復用目的而設

計的軟件”的過程。在過去的開發(fā)實踐中，我們也可能會重復使用“并非為了復用目的而設

計的軟件”的過程，或者在一個應用系統(tǒng)的不同版本間重復使用代碼的過程，這兩類行為都

不屬于嚴格意義上的軟件復用。

通過軟件更用，在應用系統(tǒng)開發(fā)中可以充分地利用己有的開發(fā)成果，消除了包括分析、

設計、編碼、測試等在內(nèi)的許多重復勞動，從而提高了軟件開發(fā)的效率，同時，通過復用高

質(zhì)量的已有開發(fā)成果，避免了重新開發(fā)可能引入的錯誤，從而提高了軟件的質(zhì)量。

良好的軟件架構(gòu)提供了構(gòu)件組裝的基礎(chǔ)和上下文。一個典型的軟件架構(gòu)是由系統(tǒng)中的構(gòu)

件、連接和約束構(gòu)成的配置格局。從這個觀點看，架構(gòu)決不是概要設計，架構(gòu)設計本身就可

以看成一個項目，架構(gòu)的結(jié)果應該是一個可執(zhí)行、可驗證的產(chǎn)品，也必須通過評審，為最終

產(chǎn)品的復用與可持續(xù)發(fā)展打下框架上的基礎(chǔ)。

研究軟件構(gòu)架有利于發(fā)現(xiàn)不同系統(tǒng)的高層共性、保證靈活和正確的系統(tǒng)設計、對系統(tǒng)的

整體結(jié)構(gòu)和全局屬性進行規(guī)范約束、分析、驗證和管理。將構(gòu)架作為系統(tǒng)構(gòu)造和演化的基礎(chǔ),

可以實現(xiàn)大規(guī)模、系統(tǒng)化的軟件復用。

研究軟件架構(gòu)對于進行高效的軟件工程具有非常重要的意義：

-3-

Z通過對軟件架構(gòu)的研究，有利于發(fā)現(xiàn)不同系統(tǒng)在較高級別上的共同特性；

Z獲得正確的架構(gòu)對于進行正確的系統(tǒng)設計非常關(guān)鍵；

Z對各種軟件架構(gòu)的深入了解，使得軟件工程師可以根據(jù)一些原則在不同的軟件架構(gòu)

之間作出選擇。

從架構(gòu)的層次上表示系統(tǒng)，有利于系統(tǒng)較高級別性質(zhì)的描述和分析。特別重要的是，在

基于復用的軟件開發(fā)中，為復用而開發(fā)的軟件架構(gòu)本身就可以作為i種大粒度的、抽象級別

較高的軟件構(gòu)件進行復用，而且軟件架構(gòu)還為構(gòu)件的組裝提供了基礎(chǔ)和上下文，對于成功的

復用具有非常重要的意義。

軟件架構(gòu)研究如何快速、可靠地用可復用構(gòu)件構(gòu)造系統(tǒng)的方式，著眼于軟件系統(tǒng)自身的

整體結(jié)構(gòu)和構(gòu)件間的互聯(lián)。其中主要包括：軟件架構(gòu)原理和風格，軟件架構(gòu)的描述和規(guī)范，

特定領(lǐng)域軟件架構(gòu)，構(gòu)件如何向軟件構(gòu)架的集成機制等。

軟件開發(fā)實際上是從問題域向最終解決方案逐步映射和轉(zhuǎn)換的過程，而特定領(lǐng)域軟件架

構(gòu)（DSSA）和軟件架構(gòu)風格（ArchitecturalStyle）分別從問題域和軟件解決方案兩個方向提供了

若干經(jīng)過考驗的候選轉(zhuǎn)換路徑。

特定領(lǐng)域軟件架構(gòu)（DSSA）：

這是一個領(lǐng)域中的所有應用系統(tǒng)所共有的體系結(jié)構(gòu)，是針對領(lǐng)域模型中的領(lǐng)域需求給出

的解決方案，也是識別、開發(fā)和組織特定領(lǐng)域可復用構(gòu)件的基礎(chǔ)。在國內(nèi)外的金融、MIS、

通訊和軍事等領(lǐng)域中都開始注意到開發(fā)特定領(lǐng)域的軟件架構(gòu)和集成框架的重要性。

架構(gòu)風格（AS）:

這是根據(jù)系統(tǒng)結(jié)構(gòu)的組織模式確定了一組可以用于某種風格實例中的構(gòu)件和連接方案，

以及它們的拓撲結(jié)構(gòu)、組裝規(guī)則以及局部和全局約束，從而定義了一個面向系統(tǒng)結(jié)構(gòu)的架構(gòu)

家族。軟件架構(gòu)風格與面向?qū)ο蟮脑O計模式或框架一樣，為設計經(jīng)驗的復用提供了技術(shù)支持。

三、軟件架構(gòu)師的角色

盡管對軟件架構(gòu)師的角色有這樣或那樣的定義，但大體上下面幾個職責是必需的：

1、技術(shù)負責，解決方案的提供者；

2、與項目經(jīng)理合作，制定計劃，決定成員，組織團隊；

3、保證項目按計劃和走向完成；

由于設計是由需求驅(qū)動的，所以，掌握需求分析的技巧，是一個好的架構(gòu)師必備的能力。

事實上，現(xiàn)代迭代開發(fā)所有的驅(qū)動力都在于需求變更，如果架構(gòu)師不關(guān)注需求，不關(guān)注

和用戶的討論和溝通，那是很難設計出真正有用的東西來的。另一方面，架構(gòu)設計的結(jié)果主

要依賴于對質(zhì)量屬性的理解，不同的質(zhì)量需求往往可能得到一個完全不同架構(gòu)設計，所以架

構(gòu)師對質(zhì)量問題需要有一個透徹的理解。

軟件架構(gòu)設計是一個非常嚴肅、細致、敏感而且困難的工作，所以我們必須摒棄那些華

而不實的名詞堆砌，一點一滴認真做起，扎扎實實的努力，實實在在的積累經(jīng)驗，尤其是在

失敗中積累經(jīng)驗，這是一個軟件架構(gòu)師成功的必由之路。

1.3在信息技術(shù)戰(zhàn)略規(guī)劃（ITSP）中的軟件架構(gòu)

好的架構(gòu)設計，必須在信息系統(tǒng)戰(zhàn)略規(guī)劃（ITSP）的大環(huán)境下進行設計，才可能設計

出真正優(yōu)秀而且有價值的系統(tǒng)來，那么什么是信息系統(tǒng)戰(zhàn)略規(guī)劃呢？

信息技術(shù)戰(zhàn)略規(guī)劃（ITSP）的核心思想簡述如下：

在信息時代知識經(jīng)濟的背景下，正確的結(jié)合IT規(guī)劃，整合企業(yè)的核心競爭力，在新一

-4-

輪的產(chǎn)生、發(fā)展中取得更大的市場競爭力是必要的。

信息化的問題首先是企業(yè)管理層概念的問題。企業(yè)管理層的重視，和對信息化的高度認

同是企業(yè)信息化的關(guān)鍵所在。當前國內(nèi)很多企業(yè)管理層很關(guān)心資本運作的問題，而對很多國

企業(yè)而言，管理層最關(guān)心的是扭虧增盈。信息化建設投入大、周期長、見效慢、風險高，往

往不是企業(yè)需要優(yōu)先解決的問題，導致管理層對信息化的重視程度不夠，無法就信息化建設

形成共識

企業(yè)管理信息化必然帶來管理模式的變化，如果對這種變化不適應，有抵觸心態(tài)，或者

僅是為了形象問題，趕潮流搞信息化。或者由于國家提出信息化帶動工業(yè)化，信息化成為一

種時髦，信息化工程往往成為企業(yè)的形象工程。結(jié)果軟件架構(gòu)的設計僅僅是企業(yè)目前業(yè)務流

程的復制，并不可能給企業(yè)帶來實實在在的好處。

有些公司缺乏統(tǒng)一完整的IT方向，希望上短平快的項目，立竿見影，跳過系統(tǒng)的一些

必要發(fā)展階段，導致系統(tǒng)后繼無力，不了了之。由于方向不明確，企業(yè)內(nèi)部充斥著各種各樣

滿足于戰(zhàn)術(shù)內(nèi)容的小體系，并不能給企業(yè)帶來大的好處。

有些公司對信息化建設的出發(fā)點不明確，在各個方案廠商鋪天蓋地的宣傳下，不能很好

的把握業(yè)務主線，僅是為了跟隨潮流，既浪費了資源，同時也對后繼的信息化造成了不良的

影響，甚至直接導致“領(lǐng)導不重視”這樣的后果。

如今國家正在大力推廣企業(yè)信息化。然而人們大多從技術(shù)角度來談論信息化和評價解決

方案，他們往往脫離了企業(yè)的實際需要，以技術(shù)為本是不能根治企業(yè)疾病的。企業(yè)依然必須

明確自己的核心競爭力。明確一切的活動和流程都是圍繞讓核心競爭力升值的過程。IT規(guī)

劃意識如此，必須以企業(yè)核心、業(yè)務為本。再結(jié)合公司的實際情況。開發(fā)自己需要的系統(tǒng)。

信息化的建設難以對投入產(chǎn)出進行量化，難以進行績效評估，CIO們無法讓:企業(yè)管理切

實感受到信息化帶來的直接效益一一經(jīng)濟效益、社會效益。

戰(zhàn)略規(guī)劃是一套方法論，用于企業(yè)的業(yè)務和IT的融合以及IT自身的規(guī)劃。必須滿足如

下要求：

1.先進性：采用前瞻性、先進成熟的模型、方法、設備、標準、技術(shù)方案，使建議的企

業(yè)信息方案既能反映當前世界先進水平，滿足企業(yè)中長期發(fā)展規(guī)劃，又能符合企業(yè)當前的發(fā)

展步調(diào)，保持企業(yè)IT戰(zhàn)略和企業(yè)戰(zhàn)略的一致性。

2.開放性：為保證不同產(chǎn)品的協(xié)同運行、數(shù)據(jù)交換、信息共享，建議的系統(tǒng)必須具有良

好的開放性，支持相應的國際標準和協(xié)議。

3.可靠性：建議的系統(tǒng)必須具有較強的容錯能力和冗余設備份，整體可靠性高，保證不

會因局部故障而引起整個系統(tǒng)癱瘓。

4.安全性：建議規(guī)劃中必須考慮到系統(tǒng)必須具有高度的安全性和保密性，保證系統(tǒng)安全

和數(shù)據(jù)安全，防止對系統(tǒng)各種形式的非法入侵。

5.實用性：規(guī)劃中建議的系統(tǒng)相關(guān)必須提供友好的中文界面的規(guī)范的行業(yè)用語，并具有

易管理、易維護等特點，便于業(yè)務人員進行業(yè)務處理，便于管理人員維護管理，便于領(lǐng)導層

可及時了解各類統(tǒng)計分析信息。

6.可擴充性：規(guī)劃不僅要滿足現(xiàn)有的業(yè)務需要，而且還應滿足未來的業(yè)務發(fā)展，必須在

應用、結(jié)構(gòu)、容量、通信能力、處理能力等方面具有較強的擴充性及進行產(chǎn)品升級換代的可

能性。

為了實現(xiàn)這樣的規(guī)劃，我們必須注意到，軟件設計既是面對程序的技術(shù)，又是聚焦于人

的藝術(shù)，成功的軟件產(chǎn)品來自于合理的設計，而什么是合理的設計呢？

一個軟件架構(gòu)師最重要的問題，就是他所設計的產(chǎn)品必須是滿足企業(yè)戰(zhàn)略規(guī)劃的需求，

能夠幫助企業(yè)解決實際問題的，因此一個合理的設計，首先要想的是：

Who：為誰設計？

-5-

What：要解決用戶的什么問題？

Why：為什么要解決這些用戶問題？

這是一個被稱之為3W的架構(gòu)師核心思維，如果這個問題沒搞清楚，就很快的投入程序

編寫，那這樣的軟件在市場上是不可能獲得成功的。

Who?What?Why?這三個問題看似簡單，但實際上落實起來是非常困難的。我們經(jīng)常

會看到一些產(chǎn)品，看似想的面面俱到，功能強大，甚至和企業(yè)目前的業(yè)務吻合得非常好，但

為什么最終沒有給企業(yè)帶來實實在在的好處相反帶來麻煩呢？一個專家感覺非常得意、技術(shù)

上非常先進的系統(tǒng)，企業(yè)的使用者未見得感覺滿意，這些情況在我的實踐中屢見不鮮，即使

一些知名的公司在設計的產(chǎn)品，往往都不能很好地把握，這足以證明我們必須下功夫來面對

它。

那么，我們該怎么來做呢？

為誰設計，表達的是我們必須認真研究企業(yè)的業(yè)務領(lǐng)域，研究企業(yè)本身的工作特點，通

過虛心請教和深入研究，使我們對于企業(yè)本身的業(yè)務有深刻的理解，最后形成針對這個企業(yè)

的實事求是的解決方案。

要解決用戶的什么問題，表達的是我們必須把企業(yè)存在的問題提取出來，分析研究哪些

問題是可以用信息化技術(shù)來解決的，采用信息化技術(shù)以后，企業(yè)的業(yè)務流程需要做什么樣的

更改，以及這些更改會帶給企業(yè)什么樣的正面和負面的影響。僅僅用計算機來復制企業(yè)現(xiàn)有

業(yè)務流程是不可取的，關(guān)鍵是要做到因為信息系統(tǒng)的使用，使企業(yè)業(yè)務方式發(fā)生革命性的變

化，使信息系統(tǒng)成為企業(yè)業(yè)務不可分割的一部分，而不僅僅是輔助工具。

為什么要解決這些用戶問題，表達的是如何幫助企業(yè)產(chǎn)生可度量的價值，而這些價值是

在研究企業(yè)目前存在的問題的基礎(chǔ)上產(chǎn)生的，沒有這些價值的產(chǎn)生，軟件系統(tǒng)的投資是沒有

意義的。價值不可度量，企業(yè)領(lǐng)導者是不可能積極的支持信息化的。還要注意我們的設計必

須便于用戶使用，減少維護和培訓的資源消耗，而且制作生產(chǎn)工藝盡可能簡單，這就是設計

之本。

任何項目都是由項目的陳述開始的，在陳述的過程中比較難解決的問題是表達可度量的

價值，所謂可度量價值實際上是一個預估，只是說由于加入了信息系統(tǒng)，解決了過去存在的

問題，從預估的角度業(yè)務水平可能提升的一個度量數(shù)據(jù)。但并不等于說我管理依然是混亂的,

只要有了這個信息系統(tǒng)，什么事情都不要做就可以達到這個水平了，這實際上是不切實際的

幻想。所謂信息系統(tǒng)戰(zhàn)略規(guī)劃的本質(zhì)，并不是說信息系統(tǒng)可以包打天下，而是說在整體規(guī)劃

下的信息系統(tǒng)，提升了我們的組織管理水平，減少了不必要的環(huán)節(jié)，提高了效率，通過全方

位的努力，在可預測的未來，確實可以提升整體的經(jīng)濟效益，而且這個預測經(jīng)過努力是可以

達到的.

1.2經(jīng)典軟件開發(fā)生命周期與過程

軟件開發(fā)過程描述的是軟件構(gòu)造、部署還有維護的一種方法，成功的軟件設計過程更

多的是研究用戶和市場，而不是技術(shù)本身。

經(jīng)典的瀑布式過程大致的情況是這樣的：

1）收集市場數(shù)據(jù)，做市場分析。

2）確定用戶，與用戶交流，理解用戶，理解用戶的工作并與用戶建立良好的關(guān)系，以

便將來的設計和開發(fā)過程中經(jīng)常得到他們的反饋意見。

3）建立典型用戶群，通過對用戶工作的了解，發(fā)現(xiàn)和自己設計工作有關(guān)的典型用戶群。

這些典型用戶群應該能夠描述用戶工作中的一個或者幾個重要環(huán)節(jié)。

4）與用戶交流進一步細化典型用戶群，并寫出場景腳本。

-6-

5）確定軟件的主要功能。

6）確定這些功能的主次，并確定優(yōu)先級。

7）確定需求并寫出說明書。

8）由用戶群檢查需求說明書，看需求說明能不能滿足用戶的需要。

9）進行軟件架構(gòu)設計。

可以看出來，在這個過程中軟件分析占了軟件設計很大一部分工作量，用戶、市場、分

析、設計，是整個軟件設計中密不可分的幾個部分，這樣一個過程也稱之為“瀑布式”過程,

可以用圖形描述如下：

開始：問題，機會，指示,約束和目標

業(yè)務團體

問題陳述系統(tǒng)設討目標

工作陳述

范圍與構(gòu)思

范圍定義

問題進一步3

清晰化

結(jié)束：可使用的業(yè)務方案需求分析

文檔

需

生命周期階段求

陳

述

系統(tǒng)運行與維護

■

可4

運文檔

行高層設計

系

統(tǒng)8

安裝與發(fā)布軟

件

體

系

培訓材料與功能系統(tǒng)模塊、構(gòu)結(jié)

產(chǎn)品說明書7件與包6構(gòu)

集成與測試實現(xiàn)與測試

一、經(jīng)典項目階段

1,范圍定義階段

范圍定義主要考慮兩個問題：首先是項目值不值得考慮。如果項目值得考慮，則確定項

目的范圍、目標、約束和限制條件，所需的參與者、預算和進度。這里主要由問題、機會和

指示作為分析的根本。包括：

問題陳述：對問題、機會和指示的分類性描述，這是一個開發(fā)的合約。

約束條件：對約束條件的分類性描述。

在項目進行過程中，范圍通常會變化，通過記錄初始范圍，我們就為（預算和進度）范

圍蔓延建立了一個基線。

2,問題分析階段

問題分析階段是研究現(xiàn)有系統(tǒng)，分析發(fā)現(xiàn)的問題，促使項目團隊更深入的研究和理解引

發(fā)該項目的問題。分析員應該經(jīng)常發(fā)現(xiàn)新問題，并回答這樣一個問題：“解決這些問題的收

益是不是超過了構(gòu)造項目的開銷？”

比如，我們定義了如下的改進準則：

把訂單處理和交貨之間的時間減少三天。

這時系統(tǒng)增加的復雜度帶來的成本增加，是不是超過了我們能夠認可的極限？

-7-

我們也可以把改進目標考慮成一種升級準則，新系統(tǒng)的升級準則可以向管理者口頭匯

報，也可以進行正式的書面報告。

3,需求分析階段

需求分析的目的是回答下面這樣一些問題：

系統(tǒng)給用戶提供什么功能？必須收集什么數(shù)據(jù)？存儲什么數(shù)據(jù)？期望達到什么樣的性

能等級？也就是系統(tǒng)需要做什么，而不是怎么做。

需求分析階段需要定義業(yè)務需求，并且為它排序。需求分析也可能是開發(fā)階段中最重要

的階段。只有當設計人員完全理解了需求之后，才可以開始設計工作。

不過，要注意避免分析癱瘓，也就是過多的系統(tǒng)建模極大的延緩了實現(xiàn)系統(tǒng)方案的進度。

在這就要求需求分析階段，必須把握重點，解決最主要的問題。

把大問題切分為可以理解的小問題，是需求分析方法論的關(guān)鍵。

4,架構(gòu)設計階段

在這個階段主要需要建立系統(tǒng)模型，這個模型又稱之為邏輯設計模型。關(guān)于這個階段需

要注意的問題，將在后面詳述。這個階段主要是建立高層模型，系統(tǒng)和子系統(tǒng)的框架以及基

于服務的層等。

5,決策分析階段

當獲得業(yè)務需求和架構(gòu)系統(tǒng)模型以后，通常就具備了大量可選方案供我們決策分析，這

里提出一些有關(guān)問題：

系統(tǒng)應該多大程度上應用計算機處理技術(shù)。

我們是購買組件還是自己編制。

是使用局域網(wǎng)還是使用Webo

什么樣的信息系統(tǒng)技術(shù)，會對這個系統(tǒng)有用。

這兩個模型對于決策分析都是必要的輸入，特別是架構(gòu)多個備選方案，需要從項目團隊

不同的人那里，把不同的想法記錄下來，最后確定選定方案。

要把決策的原因記錄下來，其中包括：

技術(shù)可行性；

運行可行性；

經(jīng)濟可行性；

進度可行性；

風險可行性等。

6,物理設計和集成階段

這個階段也稱之為詳細設計，可以精細的把業(yè)務需求轉(zhuǎn)換為系統(tǒng)模型。設計的過程包括:

按規(guī)格說明設計：這是一種最經(jīng)典的方法，通過研究需求，生成設計的藍圖。

按原設計：通過構(gòu)造不完整但可以工作的程序或者子系統(tǒng)，由用戶和其他人員的反饋，

不斷地細化模型。實際上，通常是這兩種極端方法的組合。

7,構(gòu)造和測試階段

構(gòu)造和測試事實上就開始編碼，在基于構(gòu)件的設計和并行開發(fā)中，需要研究合理的測試

用例和技術(shù)標準。開發(fā)人員在編碼和測試中反映過來的問題是十分重要的，設計人員必須關(guān)

注這些問題，用于部分的合理化系統(tǒng)。

8,安裝和發(fā)布階段

新系統(tǒng)往往與企業(yè)目前的行為方式相背離，所以分析員需要提供從老系統(tǒng)到新系統(tǒng)的的

平穩(wěn)轉(zhuǎn)換方案，需要準備一個轉(zhuǎn)換方案，一般有一個平行使用期，在規(guī)定的時間，突然切換

到新系統(tǒng)。應該準備好用戶手冊和培訓手冊，必要的時候?qū)τ脩暨M行培訓。

事實上新系統(tǒng)會影響到原來的業(yè)務流程，分析員需要關(guān)注這種業(yè)務流程的變化對業(yè)務的

-8-

影響，以不斷調(diào)整的姿態(tài)保證新系統(tǒng)的正常接入。

9,運行和維護階段

一旦系統(tǒng)投入運行，就需要給運行提供不斷地系統(tǒng)支持，在項目預算的時候，一定要把

這筆費用計算進去。

在運行階段收集用戶反饋、表現(xiàn)出的問題以及業(yè)務需求的變化是十分重要的，這對早期

研發(fā)升級版本提供了支持。系統(tǒng)一旦到了退役期，就可以迅速啟碇一個新的系統(tǒng)開發(fā)過程來

建立新項目。這個時候，在這個階段收集到的信息，對新系統(tǒng)的設計及其有意義。

盡管現(xiàn)在有各種各樣推薦的過程，但是這個基本的框架對于構(gòu)造一個大型系統(tǒng)還是完全

有必要的，我們的思維還是需要在穩(wěn)定性和靈活性之間尋求平衡，包括開發(fā)過程也是如此。

二、軟件開發(fā)生命周期增量模型

上述線性的或者瀑布的模型往往帶來了很多問題，早期的模型要求在項目的第一階段，

在任何設計和實現(xiàn)工作之前，盡可能的推敲，把需求完全定義清楚，并把它穩(wěn)定下來，并且

實際開發(fā)前凍結(jié)需求，但歷史證明這種方式是失敗的，在項目很大的時候，凍結(jié)需求幾乎沒

有可能。

對瀑布模型的一?個關(guān)鍵性的改進，是所謂增量模型的出現(xiàn)。增量模型是指首先構(gòu)建部分

系統(tǒng)，再逐漸增加功能或者性能的過程。它降低了取得初始功能之前的成本，強調(diào)采用構(gòu)建

方法來幫助控制更改需求的影響，也提高了創(chuàng)建可操作系統(tǒng)的速度。

增量模型是綜合了瀑布模型和原型化的產(chǎn)物，提倡以功能漸增方式開發(fā)軟件，經(jīng)驗表明,

這種增量模型在特大型項目和小型項目中同樣適用。增量模型描述了為系統(tǒng)需求排定優(yōu)先級

然后分組實現(xiàn)的過程，每個后續(xù)版本都為先前版本增加了新功能。

在生命周期的早期階段（計劃、分析、設計），需要建立一個考慮了整個系統(tǒng)的架構(gòu)，

這個架構(gòu)應該是具有強的可集成性的，后續(xù)的構(gòu)件方式開發(fā)，都是建立在這個架構(gòu)之上。剩

下的生命周期階段（編碼、測試、交付），來實現(xiàn)每一個增量。

首先創(chuàng)建的應該是一組核心的功能，或者對于項目至關(guān)重要的最高優(yōu)先級的系統(tǒng)，或者

是能夠降低風險的系統(tǒng)。隨后基于核心功能反復擴展，逐步增加功能以提高性能。

這個過程也可以和其它模型結(jié)合（V型或者螺旋型），以降低風險和成本。

增量模型的優(yōu)點：

-9-

Z整個項目的資金不會被提前消耗，因為首先開發(fā)和交付了主要功能和高風險功能。

Z每個增量交付一個可操作的產(chǎn)品。

Z每次增量交付過程中獲取的經(jīng)驗，有利于后面的改進，客戶也有機會對建立好的模

型作出反應。

Z采用連續(xù)增量的方式，可把用戶經(jīng)驗融入到細化的產(chǎn)品，這比完全重新開發(fā)要便宜

得多。

Z“分而治之”的策略，使問題分解成可管理的小部分，避免開發(fā)團隊由于長時間的

需求任務而感到淚喪。

Z通過同一個團隊的工作來交付每個增量，保持所有團隊處于工作狀態(tài)，減少了員工

的工作量，工作分布曲線通過項目中的時間階段被拉平。

Z每次增量交付的結(jié)為，可以重新修訂成本和進度的風險。

Z便于根據(jù)市場作出反應。

Z降低了失敗和更改需求的風險。

Z更易于控制用戶需求，因為每次曾兩開發(fā)的時間很短。

Z由于不是一步跳到未來，所以用戶能逐步適應新技術(shù)。

Z切實的項目進展，有利于進度控制。

Z風險分布到幾個更小的增量中，而不是集中于一個大型開發(fā)中。

Z由于用戶能夠從早期的增量中了解系統(tǒng)，所以更加理解后面增量中的需求。

增量開發(fā)必須注意的問題：

Z良好的可擴展性架構(gòu)設計，是增量開發(fā)成功的基礎(chǔ)。

Z由于一些模塊必須在另一個模塊之前完成，所以必須定義良好的接口。

Z與完整的系統(tǒng)相比，增量方式正式的回顧和評審更難于實現(xiàn)，所以必須定義可行的

過程。

Z要避免把難題往后推，首先完成的應該是高風險和重要的部分。

Z客戶必須認識到總體成本不會更低。

Z分析階段采用總體目標而不是完整的需求定義，可能不適應管理。

Z需要更加良好的計劃和設計，管理必須注意動態(tài)分配工作，技術(shù)人員必須注意相關(guān)

因素的變化。

二、現(xiàn)代軟件開發(fā)管理原理

對架構(gòu)驅(qū)動的應用實踐的總結(jié)，就形成一系列現(xiàn)代軟件開發(fā)管理原則，這些現(xiàn)代原則與

經(jīng)典原則有很大的不同：

1,把過程建立在構(gòu)架優(yōu)先的基礎(chǔ)之上：這要求在交付資源進行全面展開之前，就在需

求、構(gòu)架等重大設計決策和生命周期計劃之間做出權(quán)衡。

2,建立一個能盡早面對風險的迭代式生命周期過程：對于今天高度復雜的軟件系統(tǒng)，

要按照順序定義著那個個問題，設計整個解決方案、構(gòu)造軟件和測試最終產(chǎn)品幾乎是不可能

的。這就需要使用一個迭代過程，這個過程的方法很多，關(guān)鍵是定義好關(guān)鍵的里程碑，以及

最終的目標，必須及早提出可能遇到的風險，以提高可預見性，避免昂貴的下游返工。

3,設計方法向強調(diào)基于構(gòu)件的開發(fā)轉(zhuǎn)變：從代碼行至上轉(zhuǎn)為基于構(gòu)件開發(fā)的思想，可

以大幅度減少開發(fā)的成本，構(gòu)件是一個己經(jīng)存在的代碼行內(nèi)聚集和，可以由原代碼、也可以

由可執(zhí)行文件的格式提供，并且有定義好的接口和行為。

4,建立一個變更管理環(huán)境：迭代開發(fā)的動態(tài)特性，需要很好的變更控制環(huán)境，包括在

共享產(chǎn)品上工作的不同團隊之間并發(fā)的工作流、客觀需要的控制基線等。

-10-

5,通過支持雙向工程的工具增強變更的自由度：雙向工程指的是位在不同格式（例如

需求規(guī)格說明、設計模型、源代碼、可執(zhí)行代碼、測試用例等）自動轉(zhuǎn)化并同步工作信息所

需要的?個環(huán)境支持，如果沒有這種實質(zhì)性的自動化支持，很難把迭代周期減少到可以管理

的時間內(nèi)。

例如：我們已經(jīng)很清楚，迭代開發(fā)中并非所有的場景都在第一次迭代中實現(xiàn)，一個復雜

的場景，往往要花6個月采用多次為期兩周的迭代來完成。每次迭代都處理新的場景或者場

景的某些部分。在這樣的情況下，必然出現(xiàn)了一個需求跟蹤的問題，人們?nèi)绾斡涗浻美哪?/p>

些部分已經(jīng)完成，哪些部分正在進行中，哪些部分還沒有涉及呢？這就需要用到需求工具。

像RequisitePro這些工具，可以使我們可以在迭代之間跟蹤用例的部分完成情況。這個工具

的使用很簡單也很有效。

6,用嚴格的、基于模型的符號標記系統(tǒng)：具有嚴格語義的模型符號系統(tǒng)極其有意義，

它可以減少人之上的歧義，UML就是一種很好的符號語言。

7,為過程配備工具進行客觀的質(zhì)量控制以及進展評估：必須對所有的中間產(chǎn)品進行質(zhì)

量評估，這些評估必須在度量的基礎(chǔ)上進行，這些評估是在整體工程制品質(zhì)量的基礎(chǔ)上派生

出來的。

8,使用基于演示的方法評估中間制品：把產(chǎn)品的當前狀態(tài)（不論是前期原型、基線架

構(gòu)或者是一個bate能力）轉(zhuǎn)換為一個可以在相關(guān)場景下運行的演示，促使人們把注意力更

早的集中在集成上，獲得對設計折衷的更加切實的理解，并且盡早消除構(gòu)架上的缺陷。

9,計劃在大量的使用場景中使用細節(jié)的進化等級進行中間發(fā)布：必須盡早的啟動軟件

管理過程，項目增量迭代的進化必須與現(xiàn)有的對需求和構(gòu)架的理解水平一致，因而采用內(nèi)聚

的使用場景（該場景是針對某些相互關(guān)聯(lián)的問題設置），就成為組織需求、定義迭代內(nèi)容、

評估實現(xiàn)和組織驗收測試的主要方法。

10,建立一個經(jīng)濟上具有伸縮性的可配置的過程：沒有一個過程是對所有軟件開發(fā)都

是合適的。一個實用的過程框架必須可以配置，以及支持更廣泛的應用，這個過程必須應用

共同的過程精神、廣泛的過程自動化以及共同的構(gòu)架模式和構(gòu)件來確保規(guī)模經(jīng)濟和投資回

報。

現(xiàn)代軟件開發(fā)過程已經(jīng)遠離了傳統(tǒng)的瀑布模型，盡管有一些變種，瀑布模型都要求開發(fā)

過程依賴于前一階段完成情況。而現(xiàn)代方法一般都要求在開發(fā)過程的前期迅速構(gòu)造起一個初

始版本，在這個版本中，強調(diào)的是高風險的領(lǐng)域、穩(wěn)定基本架構(gòu)、完善獲取的需求。接著，

開發(fā)就以迭代序列進行下去，構(gòu)建核心的構(gòu)架，直到達到期望的功能、性能和穩(wěn)健性的等級。

這種方法是通過不斷的集成和完善需求、構(gòu)架和計劃減少了風險，而不是到了系統(tǒng)快要交付

的時候，才驚訝的發(fā)現(xiàn)出現(xiàn)的錯誤。這種過程大大提高了管理上的難度，也需要管理者對問

題理解的更加深刻。

-11-

第二章需求抽取與業(yè)務建模

事實上架構(gòu)設計是不可能獨立存在的，架構(gòu)設計提供的是用戶需求的解決方案，所以一

個架構(gòu)師對需求分析的要點和關(guān)注點需要有深刻的理解，否則是不可能有好的架構(gòu)設計的。

什么是需求呢？產(chǎn)品為用戶在特定的背景中所必須滿足的約束就是產(chǎn)品的需求，需求的表達

一般是抽象的而且與技術(shù)無關(guān)的，這樣主要是避免對技術(shù)方案產(chǎn)生影響，但架構(gòu)設計的源泉

來自于需求過程，也就是說，合理而且正確的需求分析過程，是架構(gòu)設計過程的一個有機的

組成部分，所以，我們首先必須討論需求分析的領(lǐng)域建模的有關(guān)問題，我們必須搞清楚，什

么樣的需求過程才會給架構(gòu)設計提供足夠的信息呢？

需求工程包括需求抽取、需求分析和需求管理，整個過程必須給用戶方、管理方和設計

方提供足夠的而且是清晰的信息，對于分析方而言，各方面的要求主要集中在如下幾個方面:

2.1系統(tǒng)分析

一、從軟件缺陷的產(chǎn)生看需求的重要性

軟件的質(zhì)量問題往往表現(xiàn)為缺陷（bug）,軟件缺陷的產(chǎn)生主要有兩個原因：軟件產(chǎn)品的

特點和開發(fā)過程。例如：

需求不夠明確，開發(fā)人員不太了解需求，不知道應該“做什么”和“不做什么”，常常

做不合需求的事情，這方面的問題最多。

由于競爭激烈，過早使用新技術(shù)也容易產(chǎn)生問題。

有的企業(yè)為了在時間上取勝，認為實現(xiàn)很新、很酷的功能比質(zhì)量更重要，因此時間上安

排很緊，分析和設計的投入遠遠不夠，測試也不到位，這是產(chǎn)生軟件錯誤的主要原因之一。

除此以外，設計文檔不清楚，文檔本身就存在錯誤，溝通上存在問題，項目管理水平差,

都可能導致問題。概括起來可以有七項原因：

Z項目期限的壓力。

Z產(chǎn)品的復雜度。

Z開發(fā)人員的疲勞、壓力或者受到干擾。

Z缺乏足夠的知識、技能和經(jīng)驗。

Z不可解客戶的需求。

Z缺乏動力。

從軟件自身特點、團隊工作和項目管理等多個方面進一步分析，就比較容易確定造成軟

件缺陷的一些原因細節(jié)，歸納如下：

1,軟件自身特點造成的問題

-12-

Z需求不清楚，導致設計目標偏離客戶要求，從而引起功能或者產(chǎn)品特性上的缺陷。

Z系統(tǒng)結(jié)構(gòu)非常復雜，而又無法設計成一個良好的層次結(jié)構(gòu)或者組件結(jié)構(gòu)，結(jié)果導致

意想不到的問題或者維護、擴充上的困難。即使設計成良好的面向?qū)ο蟮南到y(tǒng)，由

于對象、類太多，很難完成多個對象相互作用的組合測試，而隱蔽著一些參數(shù)傳遞、

方法調(diào)用、對象狀態(tài)變化方面的問題。

Z新技術(shù)的采用，可能涉及實現(xiàn)沒有考慮到的技術(shù)與系統(tǒng)兼容性問題。

Z對程序的邏輯路徑或者數(shù)據(jù)范圍的邊界考慮不周，容易在邊界條件下出錯。

Z系統(tǒng)運行環(huán)境復雜，包括用戶的各種操作方式及各種輸入數(shù)據(jù)，容易引起一些特定

用戶環(huán)境下的問題，大用戶量或者大數(shù)據(jù)量，也可能引發(fā)負載問題。

Z對于一些實時系統(tǒng)，如果時間同步設計不精確，也可能帶來不協(xié)調(diào)、不一致的問題。

Z沒有考慮系統(tǒng)崩潰后系統(tǒng)的自我恢復或者數(shù)據(jù)的異地備份等問題，從而存在系統(tǒng)安

全性和可靠性的隱患。

Z由于通信端口多、存取加密手段的矛盾等，會造成系統(tǒng)安全性或適用性上的問題。

2,軟件項目管理的問題

z缺乏質(zhì)量文化，不重視質(zhì)量計劃，對質(zhì)量、資源、任務、成本等的平衡把握不好，

容易擠掉需求分析、評審、測試等時間。

z系統(tǒng)分析對客戶的需求不是太清楚，或者與用戶的溝通存在一些困難。

Z開發(fā)周期短，需求分析、設計、編碼與測試不能按照已經(jīng)定義好的過程進行，工作

不夠充分，效果也就不完善、不準確，錯誤也就比較多。開發(fā)周期短，還給各類開

發(fā)人員造成太大壓力，引起一些人為的錯誤。

Z開發(fā)過程不夠完善，存在太多的隨意性，缺乏嚴謹?shù)膹蛯徍驮u審機制，容易產(chǎn)生問

題。

Z文檔不完善，風險估計不足等。

3,團隊工作的問題

z不同階段的開發(fā)人員相互理解不一致，軟件設計人員對需求分析結(jié)果的理解有偏

差，編程人員對系統(tǒng)設計規(guī)格說明書中的某些內(nèi)容重視不夠，存在著誤解。

Z設計或者編程上的一些假定或者依賴性，事先沒有得到充分的溝通。

Z項目組成員技術(shù)水平參差不齊，新員工比較多，或者培訓不足也容易造成問題。

軟件缺陷雖然是由很多原因造成的，但從整個開發(fā)周期的統(tǒng)計結(jié)果來看，我們會意外的

發(fā)現(xiàn)規(guī)格說明書是軟件缺陷出現(xiàn)最多的地方，如下圖所示。

換句話說，需求分析的不到位，是產(chǎn)生軟件缺陷的最大原因。產(chǎn)生這種情況的原因如下:

Z用戶一般是非計算機專業(yè)人員，軟件開發(fā)人員與用戶溝通存在著比較大的困難，對

要開發(fā)的產(chǎn)品功能理解也不一致。

Z由于軟件產(chǎn)品還沒有設計、開發(fā)，完全靠想象去描述系統(tǒng)的實現(xiàn)結(jié)果，所以有些特

-13-

性還不夠清晰。

Z用戶的需求總是在不斷的變化，容易引起前后文、上下文的矛盾和需求描述的不一

致。

Z需求分析沒有得到足夠的重視，在規(guī)格說明書的設計和寫作上投入的人力、時間都

不足。

Z沒有在整個開發(fā)隊伍中進行充分的溝通，有時只有架構(gòu)師和項目經(jīng)理得到比較多的

信息。

因此，需求分析就顯得非常重要，因為如果事情說不清楚，就沒有辦法做好。按出現(xiàn)問

題的排位看，第二位是設計，第三位是編碼。如果從軟件開發(fā)各個階段造成缺陷的分布來看,

編碼以后階段的錯誤也要比前兩個階段少。正是對這個問題的理解，作為架構(gòu)設計人員來說,

有必要對需求分析的思想和方法有透徹的理解。

需求并不是加在項目上的額外負擔，實際上可以使項目的進行更加順利，如果還不太清

楚要構(gòu)建什么產(chǎn)品就開始構(gòu)建了，那項目出現(xiàn)問題幾乎是確定無疑的事情，但是，這并不等

于需要完全理解需求以后才可以構(gòu)建，也不意味著所有的需求都要寫成書面的形式，而是意

味著只有注意需求，才可能向用戶提交有用和可用的產(chǎn)品。

需求的表達常常是抽象的，以一種與技術(shù)無關(guān)的方式表達，這樣做的母的是為了避免解

決方案對技術(shù)產(chǎn)生影響，需求是對業(yè)務方面的說明，而不能有任何技術(shù)實現(xiàn)上的偏好，產(chǎn)品

設計的角色是把需求翻譯成一個計劃，按這個計劃就可以構(gòu)建出一個實體。

還有一點需要注意，好的需求意味著需求、設計和實現(xiàn)可以通過一系列的迭代循環(huán)來實

現(xiàn)，每次迭代都會得到一些有用的功能，如下圖所示。

風險承擔者的想法和需要

*產(chǎn)品設計

系統(tǒng)模型IJ設計規(guī)格說明書

所以，在產(chǎn)品構(gòu)建好以后，需求不會凍結(jié)，下面我們對幾個最重要的過程問題加以討論。

二、需求的主要內(nèi)容

需求是產(chǎn)品必須完成的事以及必須具備的品質(zhì)，它主要包括如下幾部分：

1,功能性需求

功能性需求是為了向風險承擔者提供的產(chǎn)品必須執(zhí)行的動作。功能性需求源自于風險承

擔者需要完成的工作，幾乎所有的動作，包括計算、檢察、發(fā)布或者其它動作，都可以是一

項功能需求。

功能性需求是用戶給定業(yè)務背景下必須要做的事情。

2,非功能性需求

-14-

非功能性需求描述了產(chǎn)品必需具備的屬性和品質(zhì)，在某些情況下，非功能性需求描繪了

諸如觀感、可用性、安全性和法律限制等需求，這些對于產(chǎn)品的成功是至關(guān)重要的。例如，

產(chǎn)品必需在0.25秒之內(nèi)便認出是朋友還是敵人。

非功能性需求通常在產(chǎn)品功能確定以后（但并非總是如此），也就是說，一旦知道產(chǎn)品

要做的事（功能性需求），就可以確定它的行為方式，它需要具備什么品質(zhì)，以及它的響應

速度、可用性、可讀性和安全性等。

3,限制條件

限制條件是全局性的需求，又稱之為“約束條件”，它可以是項目本身的限制，或者是

對產(chǎn)品最終設計的限制，比如：產(chǎn)品必需在新的稅務年度開始之前準備好。這個約束的效果

是，分析師必須對需求分析進行限制，只包括那些在最后期限能夠提供最大價值的需求。

又比如限制條件時針對產(chǎn)品最終設計和構(gòu)造的：產(chǎn)品運行在3G手機上。結(jié)果不滿足這

樣限制的解決方案是不可接受的。

所以，限制條件是另一種類型的需求。

三、需求演進

在項目開始的時候，需求分析師關(guān)注的是產(chǎn)品將要支持的業(yè)務（或者稱之為工作），在

這個階段，分析時研究場景及其它模型，幫助他們與風險承擔者討論在業(yè)務上應該在什么，

在這個問題上達成一致意見，這時候的需求可以稱之為“業(yè)務需求”。

隨著對業(yè)務理解的加深，風險承擔者對有助于自己工作的最佳產(chǎn)品做出了決定，現(xiàn)在需

求分析師開始確定產(chǎn)品的詳細功能，并且編寫“產(chǎn)品需求”。

非功能性需求幾乎是在同一個時間導出來的，與限制條件一起被記錄了下來。此時，需

求使用一種與技術(shù)無關(guān)的方式寫下來，它規(guī)定了產(chǎn)品應該為工作做些什么，但沒有規(guī)定工作

應該用什么技術(shù)來實現(xiàn)。

當對他們的理解有足夠的程度地時候，這些需求就可以交給設計者，他們添加產(chǎn)品的“技

術(shù)需求”，然后為構(gòu)建著提供最終的設計規(guī)格說明書。

-15-

2.2需求的過程定義

任何重要的工作都需要某種有序的過程，而且參與這項工作的人，必須知道為什么這個

過程中有些步驟是重要的，知道哪些部分對他們的項目具有特定的重要意義，這就需要對需

求過程進行定義。應當說明，這里我們定義的過程是為了得到提交產(chǎn)品的一個指南，而不是

一個一成不變的程序，更不是一個必須的“做事情的方式”，我們可以從中理解很多有用的

事情，從而更有效、更準確地收集需求。

需求過程在軟件開發(fā)過程中是一個關(guān)鍵過程域，它建立了一套需求收集、建模、分析、

和描述的循序、方法和模版，使需求可以以一種有序而深入的方式進行。但是沒有什么過程

是放之四海而皆準的，我們必須根據(jù)我們自己的實際情況來定義個改進我們的需求過程，我

們不希望拿著課程中的過程就直接使用，而是仔細分析，創(chuàng)建一個構(gòu)建相關(guān)產(chǎn)品的最佳方式，

根據(jù)需要調(diào)用這個過程，使它符合您的項目和組織機構(gòu)。

定義過程實際上就是定義軟件分析的業(yè)務，這是一個成熟的軟件組織必須要做的事情，

在這個總體過程的基礎(chǔ)之上，我們可以把每個過程在分解為相應的子過程，這樣就可以使我

們的思維活動變的可操作。事實上定義需求過程的本身，也是也是進行業(yè)務建模的一個訓練，

可以使用數(shù)據(jù)流圖（DFD）表達，箭頭表示數(shù)據(jù)的流動（或者過程的流動），DFD只用了5

個符號如下圖所示。

一步步地執(zhí)行指令，將愉入轉(zhuǎn)

過程成輸出（由人和機器兩者完成這項

工作）

從一處到另一處的數(shù)據(jù)流向

數(shù)據(jù)流,或者輸入輸出到一個過程的數(shù)

據(jù)流.

系統(tǒng)之外的數(shù)據(jù)源或目的.

存放數(shù)據(jù)的地方，強些數(shù)據(jù)

將在以.后使鵬.,通常和系統(tǒng)-聯(lián)系

圖中的一個數(shù)據(jù)實體相聯(lián)系.

當過程執(zhí)行的時候，外部實

實時連接（如信用

和所有高層圖一樣，圖中并不需要表示面面俱到的內(nèi)容，而只是把最重要的關(guān)系表達出

來，細節(jié)可以通過過程的分解來達到。

-16-

新的需求產(chǎn)品使用

客戶與演進

,主要風險

潛在風險承擔者

主要風險

整|SI初步估計

所需設施

為需求

制作原型

項目啟動

試蛉

求

用例?需求模版

能需求J

潛在需求產(chǎn)品戰(zhàn)

想法略討劃

和需要

7

4

復用需求

8［質(zhì)量關(guān)

、領(lǐng)域分接受的

I.后

需求

上拒絕的

I突

求

需求規(guī)

篁說明

項目

保存在復用庫

管理層

后面我們會圍繞這個過程中的重要的子過程仔細分析，分析這些過程的細節(jié)（將要表達

的過程都編了號），這樣就可以把問題越來越深、越來越透徹的研究和分析清楚，所以，這

個課程本身就是一個需求分析的訓練，從而得到需求分析的正規(guī)、詳盡而全面的知識。

需求過程是沒有終點的，當項目和產(chǎn)品的一部分已經(jīng)交付，用戶開始使用它的時候，演

進過程就開始了，人們會發(fā)現(xiàn)一些新的要求和用途，希望產(chǎn)品得到擴展，這就提出了新的需

求。正因為產(chǎn)品自身有一個演進的過程，就可以決定先構(gòu)建一個包含較少功能的早期版本，

然后通過所計劃的一系列發(fā)行版本來支持它。

同時也要注意圍繞這個過程的人，這些人為這個過程提供信息，或者從過程接收信息，

這些人有一部分是風險承擔者，也可以是對項目感興趣的團隊，他們具有收集產(chǎn)品須求所需

要的知識。

需求過程不僅僅適用于從頭開發(fā)產(chǎn)品的情況，對于迭代或者升級的產(chǎn)品也同樣適用，本

節(jié)的說們旨在對過程的各部分如何配合有個概貌的了解，但并不準備討論若干細節(jié)。

下面我們對主要子過程加以說明。

2.3項目啟動

項目啟動主要要確定三件事情：

z產(chǎn)品實現(xiàn)的目標以及確定范圍。

z發(fā)現(xiàn)和確定主要風險承擔者。

-17-

Z限制條件以及項目的可行性。

啟動會議對項目進行準備，并且在開始詳細的需求工作之前確保項FI的可行性。它的特

點是，主要風險承擔者（客戶、主要用戶）、首席分析師、技術(shù)業(yè)務專家以及其他對項目的

成功有關(guān)鍵作用的人聚在一起，對關(guān)鍵的項目問題達成一致意見。

由首席分析師協(xié)調(diào)整個小組，在啟動會議上，首先需要確定業(yè)務問題的范圍，參與者在

白板上畫出系統(tǒng)上向文模型，以及系統(tǒng)如何與外界聯(lián)系。

在業(yè)務問題差不多達成一致以后，小組開始確定風險承擔者（項目中的利益相關(guān)人）。

項目啟動也確認了項目的目標，小組也必須對項目是否值得開發(fā)，以及組織機構(gòu)的能力

等問題達成一致意見。

一、調(diào)查研究技術(shù)

調(diào)查研究事實上是一個需求獲取過程，在這個過程中，一定要注意的是不要把癥狀當成

問題，我們必須關(guān)注真正的問題到底在哪里，以期找到業(yè)務上的問題癥結(jié)所在。在分析和討

論的過程中，可以使用一種稱之為魚骨圖的方式，這是日本人首創(chuàng)的方法，它是一種確定、

探索、何描述問題及其原因和結(jié)果的圖形工具。

客戶拒絕

履行合同

例如，對于客戶拒絕履行合同的問題，可能有五個方面的原因，以及若干具體問題。在

討論會上，在白板上書寫這樣的圖可以加深對問題的理解（請用數(shù)碼相機拍下來）。利用這

樣的圖可以清楚地描述可能出現(xiàn)的問題和應對措施。

所謂調(diào)查研究，是通過研究、面談、調(diào)查表、抽樣以及其它技術(shù)來收集關(guān)于問題、需求、

偏好等問題的正式過程。在分析階段，系統(tǒng)分析員應該了解一個企業(yè)和系統(tǒng)的術(shù)語、問題、

機會、約束條件，以及優(yōu)先級。一般來說，不管項目如何，都會有一個框架幫組我們在早期

階段收集事實。

我們可以對現(xiàn)有的文檔、表和文件進行抽樣來收集事實。

也可以通過觀察工作環(huán)境甚至觀察工作中的人來收集事實。

或者通過精心制定的調(diào)查表來收集事實。

也可以通過和客戶面談來收集事實。

面談是一種重要的收集事實的方法，我們必須選擇被接見者，制訂問題方案，在面談中

學會聆聽對方的表達，并且能夠迅速抓住問題的本質(zhì)。

需求必須通過一種形式化的方法記錄和表達，以便于和客戶溝通。

二、范圍定義

-18-

高級系統(tǒng)分析員和項目經(jīng)理通常領(lǐng)導這個階段，在范圍定義階段我們需要做的事情是：

1,列出問題和機會：

需要關(guān)注以下幾個方面的問題：緊急程度（什么時間實現(xiàn)？），可見性（系統(tǒng)在多大程

度上對客戶或執(zhí)行管理層是可見的？），收益（新方案會增加或者減少多少支出？），優(yōu)先權(quán)

（那些問題是最重要的？如果預算出了問題，需要減掉哪些問題？），可能方案（用簡單的

方式表述：如，不改變令人滿意的事物、快速修復、對現(xiàn)有系統(tǒng)改進、重新設計現(xiàn)有系統(tǒng)、

設計一個新系統(tǒng)等等）

2,協(xié)商項目的初步范圍：

包括什么類型數(shù)據(jù)描述了正被研究的系統(tǒng)？正被研究的系統(tǒng)包括什么業(yè)務過程？系統(tǒng)

需要如何與其它用戶、地點或者其它系統(tǒng)接口？

注意，項目的范圍陳述可以描述成一個簡單的列表，但不需要定義列表中的項目，也不

十分關(guān)心精確的需求分析，尤其不關(guān)心任何費時的建?；蛘咴突?。

3,評估項目價值：

在這個任務中我們必須回答這樣的問題：