需求分析與系統(tǒng)設(shè)計01課件

需求工程

需求分析與系統(tǒng)設(shè)計

整體概述概述二點擊此處輸入相關(guān)文本內(nèi)容概述一點擊此處輸入相關(guān)文本內(nèi)容概述三點擊此處輸入相關(guān)文本內(nèi)容關(guān)于本課程課程的本質(zhì)聽課的要求作業(yè)的要求與后繼課程的關(guān)系考試第一章軟件過程

本章目標(biāo)是從總體上描述軟件開發(fā)過程中的若干策略問題，介紹支撐現(xiàn)代軟件開發(fā)的過程和方法。了解軟件開發(fā)的本質(zhì)、社會基礎(chǔ)，以及業(yè)務(wù)系統(tǒng)的開發(fā)為何不能完全基于嚴(yán)格的工程和科學(xué)原則。學(xué)習(xí)軟件過程標(biāo)準(zhǔn)（CMM、ISO9000、ITIL）及服從框架（COBIT）。獲得策略系統(tǒng)規(guī)劃和方法（SWOT、VCM、BPR、ISA）的知識，以確保業(yè)務(wù)目標(biāo)能夠確定信息系統(tǒng)項目。認識到信息系統(tǒng)之間具有很大的差異，這種差異取決于信息系統(tǒng)能夠滿足的管理水平及其所具有的競爭優(yōu)勢。了解軟件開發(fā)的結(jié)構(gòu)化方法與面向?qū)ο蠓椒ǖ牟町?。學(xué)習(xí)軟件開發(fā)生命周期的各個階段及跨越生命周期的活動。了解現(xiàn)代及新興的軟件開發(fā)模型／方法（螺旋模型、IBMRational統(tǒng)一過程、模型驅(qū)動的體系結(jié)構(gòu)、敏捷軟件開發(fā)及面向方面的軟件開發(fā)）。了解7個實例研究，這些實例用于作為貫穿全書的例子和練習(xí)。第一章軟件過程

1.1軟件開發(fā)的本質(zhì)1.2系統(tǒng)規(guī)劃1.3三級管理系統(tǒng)1.4軟件開發(fā)生命周期1.5開發(fā)模型與方法1.6實例研究的問題陳述1.1軟件開發(fā)的本質(zhì)在關(guān)于信息系統(tǒng)（informationsystem，IS）管理的文獻中，充滿了項目失敗、逾期和超預(yù)算、有缺陷的解決方案，以及不可維護的系統(tǒng)等例子。雖然大量引用StandishChaos報告（聲稱有70％的軟件項目失敗）是有些夸張，但毋庸置疑的是，許多“成功的”系統(tǒng)（換句話說，就是已經(jīng)付款并交付給用戶的系統(tǒng)）被可靠性、性能、安全性、可維護性及其他問題所困擾。為了了解這些問題的原因，我們首先需要了解軟件開發(fā)的本質(zhì)。在一篇有代表性的論文中，闡述了軟件工程的本質(zhì)問題和意外事件。軟件工程的本質(zhì)問題體現(xiàn)在軟件本身所固有的困難中，我們只能承認這些困難——沒有獲得突破性進展或“銀彈”的方法。按照Brooks的說法，軟件工程的本質(zhì)問題是由軟件固有的復(fù)雜性、一致性、可變性和不可見性所導(dǎo)致的。1.1軟件開發(fā)的本質(zhì)軟件的“本質(zhì)困難”定義了軟件開發(fā)的不變事實。不變事實聲明軟件是一種創(chuàng)造性開發(fā)行為的產(chǎn)品——由工匠而不是優(yōu)秀藝術(shù)家所完成的行為意義上的一種工藝品或藝術(shù)品。在典型的情況下，軟件并不是制造業(yè)重復(fù)性行為的結(jié)果。1.1軟件開發(fā)的本質(zhì)一旦理解了軟件開發(fā)的不變事實，人們就應(yīng)該能夠處理軟件工程的意外事件——由于軟件生產(chǎn)實踐而帶來的困難，可以由人為的干涉來解決?？梢詫⒏鞣N“意外困難”分為3類：利益相關(guān)者。過程。建模。1.1軟件開發(fā)的本質(zhì)1.1軟件開發(fā)的本質(zhì)1.1.l軟件開發(fā)的不變事實1.1.2軟件開發(fā)的“意外事件”1.1.3開發(fā)還是集成1.1.1軟件開發(fā)的不變事實一些重要的軟件特性不易受到人為因素的影響，這些特性在所有的軟件項目中都保持不變，并需要在項目中得到承認。軟件開發(fā)的任務(wù)是確保不變事實不會失去控制，并且不要對項目施加任何過多的負面影響。1.1.1軟件開發(fā)的不變事實軟件本身就是復(fù)雜的。在現(xiàn)代軟件系統(tǒng)中，復(fù)雜性不過是軟件規(guī)模（如以代碼行表示）的函數(shù)，以及組成軟件產(chǎn)品的構(gòu)件之間相互依存關(guān)系的函數(shù)。1.1.1軟件開發(fā)的不變事實軟件的復(fù)雜性隨著軟件的應(yīng)用領(lǐng)域的性質(zhì)不同而不同。通常情況下，計算密集型應(yīng)用領(lǐng)域的軟件系統(tǒng)比數(shù)據(jù)密集型應(yīng)用領(lǐng)域的軟件系統(tǒng)的復(fù)雜性要低。數(shù)據(jù)密集型應(yīng)用系統(tǒng)包括電子商務(wù)，它是本書的主題。這樣的系統(tǒng)處理大量數(shù)據(jù)和業(yè)務(wù)規(guī)則，而這些數(shù)據(jù)和業(yè)務(wù)規(guī)則往往是不一致或不明確的。構(gòu)建能夠容納所有業(yè)務(wù)數(shù)據(jù)、規(guī)則和特殊情況的軟件一貫是困難的。1.1.1軟件開發(fā)的不變事實Brooks認為，另外3個重要特性（一致性、可變性及不可見性）加重了這種困難。應(yīng)用軟件必須與其所基于的特定硬件／軟件平臺相符合（一致），也必須與現(xiàn)有的信息系統(tǒng)相符合，并集成在一起。因為業(yè)務(wù)過程和需求是在不斷變化的，所以在建立應(yīng)用軟件時必須能夠容納變化。盡管應(yīng)用軟件提供了可見的輸出，但是負責(zé)輸出的代碼通常深深地隱藏在“不可見”的程序語句、二進制代碼庫，以及周邊的系統(tǒng)軟件中。1.1.1軟件開發(fā)的不變事實軟件是開發(fā)出來的，而不是成批制造出來的（Pressman2005）。當(dāng)然，我們不能否認，雖然軟件工程的發(fā)展為開發(fā)實踐引入了更多的確定性，但是并不能保證軟件項目的成功。這可以與傳統(tǒng)的工程分支相對比，如土木工程或機械工程。在傳統(tǒng)的工程中，產(chǎn)品（人工制品）是以數(shù)學(xué)般的精確來設(shè)計，然后利用機械和生產(chǎn)線來制造（通常為成批制造）的。1.1.1軟件開發(fā)的不變事實一旦將軟件產(chǎn)品開發(fā)出來，就能夠以最小的代價復(fù)制（成批制造），但是對于企業(yè)信息系統(tǒng)這種情況，從來都不需要復(fù)制軟件。每個系統(tǒng)都是獨特的，并且是為特定企業(yè)開發(fā)的。困難在于開發(fā)，而并不在于成批制造。因此，整個軟件生產(chǎn)的成本都在于它的開發(fā)。1.1.1軟件開發(fā)的不變事實為了降低軟件開發(fā)的工作量和成本，軟件產(chǎn)業(yè)以可復(fù)用軟件構(gòu)件的形式提供了部分解決方案，在開發(fā)過程中可以利用這些構(gòu)件。我們所面臨的挑戰(zhàn)是，將該解決方案的一個個小的部分組裝成一個連貫的企業(yè)系統(tǒng)，以滿足復(fù)雜業(yè)務(wù)過程的需要。1.1.1軟件開發(fā)的不變事實軟件實踐鼓勵從可定制的軟件框架或軟件包——商用成品軟件（commercialoff-the-shelf，COTS）解決方案或企業(yè)資源規(guī)劃（enterpriseresourceplanning，ERP）系統(tǒng)——來進行系統(tǒng)開發(fā)。然而，軟件框架只能提供常規(guī)的財務(wù)、制造或人力資源系統(tǒng)。這些常規(guī)的解決方案必須要適應(yīng)企業(yè)所期望和需要執(zhí)行的特定業(yè)務(wù)過程。必須要對這些業(yè)務(wù)過程進行定義，然后開發(fā)系統(tǒng)模型。雖然所強調(diào)的重點由“從零開始的開發(fā)”轉(zhuǎn)變到了“通過定制的軟件框架進行開發(fā)”，但是在這兩種情況下，軟件開發(fā)的真正本質(zhì)仍然是相同的。1.1.1軟件開發(fā)的不變事實必須為每個系統(tǒng)的最終解決方案創(chuàng)建概念性構(gòu)想（模型），以確保這些構(gòu)想能夠滿足組織的特定需要。一旦創(chuàng)建了這些概念性構(gòu)想，就可以對軟件框架的功能性進行定制，以符合概念性構(gòu)想。編程任務(wù)可能有所不同，但是需求分析和系統(tǒng)設(shè)計活動與那些從頭開發(fā)的軟件類似。畢竟，一個概念性構(gòu)想（模型）在許多可能的表示（實現(xiàn)）下是相同的。1.1.1軟件開發(fā)的不變事實同樣重要的是，一個組織不可能找到一個軟件框架來自動實現(xiàn)它的核心業(yè)務(wù)活動。電話公司的核心業(yè)務(wù)活動是電話技術(shù)，而不是人力資源或財務(wù)。因此，支持核心業(yè)務(wù)活動的軟件很少有機會依賴軟件構(gòu)件或框架。此外，支持其他業(yè)務(wù)活動（如財務(wù)）的軟件必須包含有針對性的或獨特的解決方案，來為組織提供競爭優(yōu)勢。就如Szyperski所評述的：“標(biāo)準(zhǔn)軟件包創(chuàng)建了一個公平的比賽場地，競爭只能來自其他領(lǐng)域?！?.1.1軟件開發(fā)的不變事實在各種情形下，開發(fā)過程都應(yīng)該利用構(gòu)件技術(shù)。構(gòu)件是軟件的一個可執(zhí)行單元，具有明確定義的功能服務(wù)）及與其他構(gòu)件之間的通信協(xié)議（接口）。可以對構(gòu)件進行配置來滿足應(yīng)用需求。最具影響力和最直接的竟?fàn)帢?gòu)件技術(shù)標(biāo)準(zhǔn)是Sun的J2EE／EJB和Microsoft的．NET。面向服務(wù)的體系結(jié)構(gòu)（Service-OrientedArchitecture，SOA）的相關(guān)技術(shù)提倡由服務(wù)——也就是運行的軟件實例（而不是構(gòu)件；必須在運行構(gòu)件之前加載、安裝、組合、部署和初始化）——來構(gòu)建系統(tǒng)。1.1.1軟件開發(fā)的不變事實軟件包、構(gòu)件、服務(wù)以及類似的技術(shù)并沒有改變軟件生產(chǎn)的本質(zhì)問題，尤其是需求分析與系統(tǒng)設(shè)計的原則和任務(wù)保持不變。能夠把標(biāo)準(zhǔn)的和客戶定制的構(gòu)件組裝成最終的軟件產(chǎn)品，而這個“組裝”過程仍然是一門藝術(shù)。正如Pressman所說：我們甚至沒有軟件“備件”來代替正在運行的系統(tǒng)中破損的構(gòu)件。1.1.2軟件開發(fā)的“意外事件”軟件開發(fā)的不變事實定義了軟件生產(chǎn)的本質(zhì)問題，并引發(fā)了軟件生產(chǎn)中的最大挑戰(zhàn)。極為重要的是，軟件開發(fā)中的“意外事件”并不會增加軟件產(chǎn)品的復(fù)雜性，也不會產(chǎn)生軟件產(chǎn)品的可支持性的潛在缺乏。可支持性（適應(yīng)性）由3個系統(tǒng)特征組成的集合來定義，包括軟件的可理解性、可維護性和可伸縮性（可擴展性）。1.1.2軟件開發(fā)的“意外事件”軟件開發(fā)的意外事件大部分可以歸因于信息系統(tǒng)即社會系統(tǒng)這樣的事實。它的成功或失敗依賴于：人、他們對系統(tǒng)的接受或支持、用于開發(fā)的過程、管理措施、軟件模型技術(shù)的利用等。1.1.2軟件開發(fā)的“意外事件”1.1.2.1利益相關(guān)者1.1.2.2過程1.1.2.3建模1.1.1.1利益相關(guān)者利益相關(guān)者是在軟件項目中存在利害關(guān)系的人。任何受到系統(tǒng)影響或?qū)ο到y(tǒng)開發(fā)產(chǎn)生影響的人，都是利益相關(guān)者。有兩組主要的利益相關(guān)者：客戶（用戶或系統(tǒng)所有者）。開發(fā)者（分析員、設(shè)計員、程序員等人1.1.1.1利益相關(guān)者在一般的交流中，術(shù)語“用戶”通常是指“客戶”。我們不能否認這樣的事實：術(shù)語“客戶”能夠更好地反映期望的含義。首先，客戶是為開發(fā)付款并負責(zé)決策的人。其次，即使客戶并不總是正確的，開發(fā)者也不能隨意改變或拒絕客戶的需求——對于任何沖突的、不可行的或非法的需求，都必須與客戶再次協(xié)商。1.1.1.1利益相關(guān)者信息系統(tǒng)是社會系統(tǒng)，它們是由人（開發(fā)者）為人（客戶）開發(fā)的。軟件項目的成功由社會因素所決定——技術(shù)則是次要的。技術(shù)低劣的系統(tǒng)在為客戶工作并使客戶獲益，這樣的例子有很多，反之則不然。對客戶沒有好處（被認為的或?qū)嶋H上的）的系統(tǒng)將會被拋棄，無論它具有多么輝煌的技術(shù)。1.1.1.1利益相關(guān)者在典型的情況下，軟件失敗的主要原因可以追溯到利益相關(guān)者。在客戶端，項目失敗是因為：客戶的需求被誤解了，或者沒有被完全捕獲?？蛻舻男枨蟾淖兊眠^于頻繁?？蛻魶]有準(zhǔn)備為項目提供足夠的資源?？蛻舨幌肱c開發(fā)者合作?？蛻魬延胁磺袑嶋H的期望。系統(tǒng)不再對客戶有利。1.1.1.1利益相關(guān)者項目也會因為開發(fā)者的不勝任而失敗。隨著軟件復(fù)雜性的增加，人們越來越認識到，開發(fā)者的技能和知識是至關(guān)重要的。良好的開發(fā)者能夠交付一個可接受的解決方案；卓越的開發(fā)者能夠更快、更廉價地交付一個更優(yōu)越的解決方案。如同F(xiàn)redBrooks的名言：“偉大的設(shè)計來源于偉大的設(shè)計者?！?.1.1.1利益相關(guān)者開發(fā)者的杰出和投入是最能夠促進軟件質(zhì)量和生產(chǎn)力的因素。為了確保軟件產(chǎn)品能夠成功地交付給用戶，而且更重要的是使用戶從中獲得生產(chǎn)效益，軟件組織必須對開發(fā)者使用正確的管理措施，即：雇傭最好的開發(fā)者。為現(xiàn)有的開發(fā)者提供持續(xù)的培訓(xùn)和教育。鼓勵開發(fā)者之間進行信息交流和互動，使他們互相促進。通過排除阻力以及將他們的精力引導(dǎo)到生產(chǎn)性工作中，來激勵開發(fā)人員。提供一個令人振奮的工作環(huán)境（這往往比偶爾加薪更重要）。將個人目標(biāo)同組織策略和目標(biāo)統(tǒng)一起來。強調(diào)團隊工作。1.1.1.2過程軟件過程定義在軟件生產(chǎn)和維護中所使用的活動和組織程序。過程的目標(biāo)是在開發(fā)中管理和改進協(xié)作并維持團隊，使團隊能夠向客戶交付符合質(zhì)量要求的產(chǎn)品，并在以后對產(chǎn)品提供適當(dāng)?shù)闹С帧?.1.1.2過程一個過程模型：聲明了所執(zhí)行活動的次序。詳細說明要交付哪些開發(fā)的人工制品，以及什么時候交付。將活動和人工制品分配給開發(fā)者。提供用來監(jiān)控項目進展、評估結(jié)果和規(guī)劃未來項目的標(biāo)準(zhǔn)。1.1.1.2過程不同于建模和編程語言，軟件過程不易被標(biāo)準(zhǔn)化。每個組織必須開發(fā)屬于它自己的過程模型，或者對通用的過程模板進行定制，例如著名的Rational統(tǒng)一過程”（RationalUnifiedProcess，RUP）模板。軟件過程是組織的整體業(yè)務(wù)過程的一個重要組成部分，它決定了組織在市場中的獨特性和競爭能力。1.1.1.2過程組織所采用的過程必須符合其開發(fā)文化、社會動態(tài)、開發(fā)者的知識和技能、管理方法、客戶的期望、項目規(guī)模，甚至是應(yīng)用領(lǐng)域的種類。由于所有這些因素都是可變的，組織可能需要將它的過程模型多樣化，并且為每個軟件項目創(chuàng)建變體。例如，依據(jù)開發(fā)者對建模方法和工具的熟悉程度，可能需要在過程中加入專題培訓(xùn)課程。1.1.1.2過程項目規(guī)模有可能對過程產(chǎn)生最大的影響。在小項目中（10個人左右的開發(fā)者），也許根本不需要正式的過程。這樣的小團隊可能會不拘形式地進行溝通，并且對變化做出響應(yīng)。然而在大項目中，一個非正式的通信網(wǎng)絡(luò)是不夠的，因此為了控制開發(fā)而明確定義的過程是必要的。1.1.1.2過程1.1.2.2.l迭代和增量過程1.1.2.2.2能力成熟度模型1.1.2.2.3ISO9000系列質(zhì)量標(biāo)準(zhǔn)1.1.2.2.4ITIL框架1.1.2.2.5COBIT框架1.1.2.2.l迭代和增量過程現(xiàn)代軟件開發(fā)過程總是迭代和增量的。系統(tǒng)模型通過分析、設(shè)計和實現(xiàn)階段而逐步完善和改造。在連續(xù)的迭代中增加細節(jié)，必要時還引入了變更和改進，而軟件模塊的增量版本則保持了用戶的滿意度，并且為尚在開發(fā)中的模塊提供重要的反饋。1.1.2.2.l迭代和增量過程可執(zhí)行代碼的構(gòu)造是以程序塊的形式交付給客戶，每次的下一個構(gòu)造都是在之前構(gòu)造上的增量。作為由系統(tǒng)必須滿足的一套功能性的用戶需求所決定的增量，并不會擴大項目的范圍。迭代是短期的——在數(shù)周中而非數(shù)月。用戶反饋是頻繁的，規(guī)劃是持續(xù)的，變更管理是生命周期中至關(guān)重要的一個方面，度量標(biāo)準(zhǔn)和風(fēng)險分析的定期收集設(shè)定了連續(xù)迭代的議程。1.1.2.2.l迭代和增量過程這個迭代和增量過程有各種各樣的變體，具有特殊意義的變體包括：螺旋模型。Rational統(tǒng)一過程（theRationalUnifiedProcess，RUP）。模型驅(qū)動的體系結(jié)構(gòu)（Model－DrivenArchitecture，MDA）。敏捷開發(fā)過程。面向方面的軟件開發(fā)。1.1.2.2.l迭代和增量過程由Boehm定義的螺旋模型，作為較新模型的參考點，包含了上面列出的3個模型。RUP是一個相對靈活的過程，它提供了一個支持環(huán)境（稱作RUP平臺），用各種各樣的文本模板、概念解釋、開發(fā)思路等來指導(dǎo)開發(fā)者。MDA基于可執(zhí)行規(guī)格說明的觀點——由模型和構(gòu)件生成軟件。敏捷開發(fā)提出了一個框架，在這個框架中，人與團隊的協(xié)作被認為比規(guī)劃、文檔及其他形式更加重要。面向方面的開發(fā)引入了有關(guān)橫切關(guān)注點（方面）的正交思想，并主張為這些關(guān)注點生產(chǎn)單獨的軟件模塊。每個方面（如軟件的安全性、性能或并發(fā)性）被視為一個獨立的開發(fā)問題，但是也必須謹慎地與系統(tǒng)其余的部分集成（編織）在一起。1.1.2.2.l迭代和增量過程迭代和增量過程的成功是以對系統(tǒng)體系結(jié)構(gòu)模塊的早期識別為基礎(chǔ)的。這些模塊應(yīng)當(dāng)有相似的規(guī)模、高度的內(nèi)聚和極小的重疊（耦合）。實現(xiàn)模塊的次序也很重要。如果模塊依賴于其他尚在開發(fā)的模塊中的信息或計算，那么它們可能無法發(fā)布。除非對迭代和增量開發(fā)進行規(guī)劃和控制，否則過程會淪為不能控制項目實際進度的“特別黑客”。1.1.2.2.2能力成熟度模型對每個組織來說，從事軟件生產(chǎn)的一個主要挑戰(zhàn)是改進其開發(fā)過程。當(dāng)然，要引入過程改進，組織就必須了解在當(dāng)前的過程中所存在的問題。能力成熟度模型（capabilitymaturitymodel，CMM）是一種用來進行過程評估和改進的流行方法。1.1.2.2.2能力成熟度模型CMM已經(jīng)由位于美國匹茲堡的卡內(nèi)基一梅隆大學(xué)的軟件工程學(xué)院（SEI）詳細說明。它原先被美國國防部用于評估組織的IT能力，以競標(biāo)國防合同。目前在美國及其他地方廣泛應(yīng)用于IT行業(yè)。1.1.2.2.2能力成熟度模型從本質(zhì)上說，CMM是一個由IT組織填寫的問卷調(diào)查表。問卷隨后進行核查和認證，并將組織分配到5個CMM級別中的一個。級別越高，組織的軟件過程越成熟。圖1-1定義了這些級別，給出了每個級別主要特征的簡短描述，并且指明了組織為了達到更高級別，而需要進行過程改進的主要領(lǐng)域。1.1.2.2.2能力成熟度模型1.1.2.2.2能力成熟度模型Arthur將成熟度級別稱為“通向軟件卓越的樓梯”。樓梯上的5個臺階是：混亂、項目管理、方法和工具、度量以及持續(xù)的質(zhì)量改進。經(jīng)驗表明，要上升一個成熟度級別需要數(shù)年的時間。大部分組織位于第1級，一些組織位于第2級；而位于第5級的組織寥寥無幾。1.1.2.2.2能力成熟度模型下面的幾個問題顯示了任務(wù)的艱巨。一個組織想要達到CMM的第2級，就必須對這些問題（以及更多問題）做出肯定的答復(fù)：軟件質(zhì)量保證功能是否有獨立于軟件開發(fā)項目管理的管理報告渠道？是否為涉及軟件開發(fā)的每個項目都提供了軟件配置的控制功能？在制定合同承諾前，是否有正式過程，用于每個軟件開發(fā)的管理審查？是否有制定軟件開發(fā)進度表的正式程序？是否有估算軟件開發(fā)成本的正式程序？是否對軟件代碼和收集的測試錯誤進行統(tǒng)計？高層管理是否有對軟件開發(fā)項目狀況進行定期審查的機制？是否有控制軟件需求變更的機制？1.1.2.2.3ISO9000系列質(zhì)量標(biāo)準(zhǔn)除了CMM，還有其他過程改進模型，特別受關(guān)注的是由國際標(biāo)準(zhǔn)化組織開發(fā)的ISO9000質(zhì)量標(biāo)準(zhǔn)系列。ISO標(biāo)準(zhǔn)應(yīng)用于質(zhì)量管理和過程，以生產(chǎn)優(yōu)質(zhì)產(chǎn)品。這些標(biāo)準(zhǔn)是通用的——它們應(yīng)用于任何行業(yè)和所有業(yè)務(wù)類型，包括軟件開發(fā)。1.1.2.2.3ISO9000系列質(zhì)量標(biāo)準(zhǔn)ISO9000標(biāo)準(zhǔn)系列的主要前提是：如果過程是正確的，那么過程的結(jié)果（產(chǎn)品或服務(wù)）也將是正確的?！百|(zhì)量管理的目標(biāo)是通過在產(chǎn)品中建立質(zhì)量而不是測試質(zhì)量來生產(chǎn)優(yōu)質(zhì)的產(chǎn)品”。1.1.2.2.3ISO9000系列質(zhì)量標(biāo)準(zhǔn)按照我們前面關(guān)于過程的討論，ISO標(biāo)準(zhǔn)并不強制執(zhí)行或具體指定過程。標(biāo)準(zhǔn)提供了必須完成什么的模型，而不是必須怎樣執(zhí)行活動的模型。一個組織請求ISO認證（也稱為注冊），就必須說明它是做什么的，做它所說明的事情，并且證明它已經(jīng)做了。1.1.2.2.3ISO9000系列質(zhì)量標(biāo)準(zhǔn)對于由ISO認證的組織來說，一個試金石是即使它的全部勞動力被替換掉了，它也應(yīng)該能夠生產(chǎn)優(yōu)質(zhì)產(chǎn)品或提供優(yōu)質(zhì)服務(wù)。為了這個目標(biāo)，組織必須文檔化并記錄它的所有正式活動，必須為每個活動定義書面程序，包括當(dāng)出現(xiàn)錯誤時或客戶抱怨時需要做什么。1.1.2.2.3ISO9000系列質(zhì)量標(biāo)準(zhǔn)同CMM一樣，只有ISO注冊員進行現(xiàn)場審核后，才能批準(zhǔn)ISO認證。之后，每隔一段時間將定期重復(fù)這些審核?？蛻粢螽a(chǎn)品和服務(wù)的供應(yīng)商通過認證，通過這種明確規(guī)定的競爭實力，組織被推動到這種認證體系之中。許多國家已經(jīng)采用了ISO9000作為他們的國家標(biāo)準(zhǔn)，這在歐洲尤為普遍。1.1.2.2.4ITIL框架從業(yè)務(wù)的視角來看，軟件（或信息技術(shù)——通常說IT）是一種正在快速成為商品的基礎(chǔ)架構(gòu)服務(wù)。IT對早期采納者來說，仍然是競爭優(yōu)勢的主導(dǎo)來源，但是這種優(yōu)勢的時間跨度比以往縮短了很多。原因有很多，包括開源軟件的存在、商業(yè)軟件的免費教育許可、迭代和增量軟件開發(fā)的周期縮短等。1.1.2.2.4ITIL框架越來越多的軟件僅僅是對業(yè)務(wù)解決方案的服務(wù)支持。我們所討論的是解決方案（服務(wù)）的交付，而不僅僅是軟件或系統(tǒng)的交付，業(yè)務(wù)和軟件之間相互影響的強度正是我們所需要的。需要對已交付的解決方案進一步管理。解決方案管理是指IT解決方案供應(yīng)管理的所有方面，這個事實在IT基礎(chǔ)架構(gòu)庫（ITInfrastructureLibrary，ITIL）——被最廣泛使用和接受的、用于IT服務(wù)管理的最佳實踐的框架——中得到了公認。1.1.2.2.4ITIL框架“對IT管理者的挑戰(zhàn)，是在業(yè)務(wù)合作伙伴中協(xié)調(diào)和工作，來提供高質(zhì)量的IT服務(wù)。這個目標(biāo)必須要達到，同時降低整體總擁有成本（totalcostofownership，TCO），并且經(jīng)常增加頻率、復(fù)雜性和變化量……IT管理就是高效率地和有效地全面利用4P：人（People）、過程（Process）、產(chǎn)品（Product）（工具和技術(shù)）及合作伙伴（Partner）（供應(yīng)商、銷售商和外包機構(gòu)）?！?.1.2.2.4ITIL框架圖1-2介紹了作為一項持續(xù)的服務(wù)改進方案（continuousserviceimprovementprogramme，CSIP）、用來實現(xiàn)解決方案管理的ITIL方法。CSIP方案以實現(xiàn)高水平業(yè)務(wù)目標(biāo)的決心為起點，接著檢查是否已經(jīng)達到了里程碑（可交付），并通過鞏固已達到的改進和持續(xù)任務(wù)循環(huán)而保持發(fā)展勢頭。1.1.2.2.4ITIL框架1.1.2.2.4ITIL框架在策略規(guī)劃和業(yè)務(wù)模型的使用中確定高水平的業(yè)務(wù)目標(biāo)，在當(dāng)前組織狀況的背景下分析目標(biāo)，以此來評估需要填補的差距。這樣的IT組織成熟度的評估應(yīng)包括：內(nèi)部審查、外部基準(zhǔn)和針對行業(yè)標(biāo)準(zhǔn)（如ITIL、CMM或ISO9000）的過程審查。1.1.2.2.4ITIL框架一旦完成了差距評估報告，就需要為CSIP制定業(yè)務(wù)實例。業(yè)務(wù)實例應(yīng)當(dāng)識別“速贏”（如果有的話），但是首先應(yīng)當(dāng)確定支持業(yè)務(wù)目標(biāo)的具體短期目標(biāo)，作為可度量目標(biāo)。配備了這些初步信息后，一個過程改進規(guī)劃就產(chǎn)生了。該規(guī)劃確定了應(yīng)遵循的范圍、方法和過程，以及CSIP項目的職權(quán)范圍。1.1.2.2.4ITIL框架CSIP的進展和性能評估依據(jù)一套可度量的里程碑、可交付性、關(guān)鍵性的成功因素（criticalsuccessfactor，CSF），以及關(guān)鍵績效指標(biāo)（keyPerformanceindicator，KPI）。雖然包括直接關(guān)系到商業(yè)利益的測量和度量是重要的，但是我們必須記得，優(yōu)質(zhì)業(yè)務(wù)的改進取決于軟件質(zhì)量因素。1.1.2.2.5COBIT框架ITIL致力于處理方案交付和管理的操作方面。COBIT（ControlObjectivesforInformationandrelatedTechnology，控制目標(biāo)信息和相關(guān)技術(shù)）是一個服從框架，并致力于處理解決方案管理的控制方面（COBIT2000）。1.1.2.2.5COBIT框架ITIL，CMM和ISO9000是過程標(biāo)準(zhǔn)，這些標(biāo)準(zhǔn)規(guī)定了組織在管理過程方面的要求，以提供優(yōu)質(zhì)的產(chǎn)品或服務(wù)。相比之下，COBIT則是一個產(chǎn)品標(biāo)準(zhǔn)，它側(cè)重于一個組織需要做什么，而不是需要如何去做。1.1.2.2.5COBIT框架COBIT的目標(biāo)對象并不是軟件開發(fā)者，而是高級IT經(jīng)理、高級業(yè)務(wù)經(jīng)理和審計師?！坝捎谒募墑e高，覆蓋面廣，并且因為它基于許多現(xiàn)有的實踐，常將COBIT稱為‘集成器’，將分散的實踐組織到一起，而同樣重要的是，它幫助將這些各種各樣的IT實踐連接到業(yè)務(wù)需求中去?！?.1.2.2.5COBIT框架COBIT框架是相當(dāng)具有規(guī)定性的。它將相關(guān)的IT工作組織到4個領(lǐng)域：規(guī)劃與組織。獲取與實現(xiàn)。交付與支持。監(jiān)控。1.1.2.2.5COBIT框架將控制目標(biāo)分配到這些領(lǐng)域。有34個高級別的控制目標(biāo)。同這些目標(biāo)關(guān)聯(lián)在一起的是一個審計指標(biāo)，它依據(jù)COBIT推薦的318個詳細控制目標(biāo)來評估IT過程。這些目標(biāo)是為保證管理和改進建議而服務(wù)的。1.1.2.2.5COBIT框架第1個領(lǐng)域——規(guī)劃與組織——是系統(tǒng)規(guī)劃活動（1．3節(jié)）。它把IT看作是組織策略和戰(zhàn)術(shù)規(guī)劃的一部分，關(guān)系到確定IT如何能夠以最佳方式對業(yè)務(wù)愿景和目標(biāo)的實現(xiàn)做出貢獻，也著眼于實現(xiàn)IT功能的短期規(guī)劃。它評估現(xiàn)有系統(tǒng)，進行可行性研究，分附資源，建立信息體系結(jié)構(gòu)模型，著眼于技術(shù)方向、系統(tǒng)體系結(jié)構(gòu)、遷移策略、IT功能的組織布置、數(shù)據(jù)和系統(tǒng)的所有權(quán)、人事管理、IT業(yè)務(wù)預(yù)算、成本和效益調(diào)整、風(fēng)險評估、質(zhì)量管理等。1.1.2.2.5COBIT框架第2個領(lǐng)域——獲取與實現(xiàn)——關(guān)系到IT策略的實現(xiàn)。它指出了滿足業(yè)務(wù)目標(biāo)和客戶需求的自動化解決方案，確定IT解決方案必須通過開發(fā)實現(xiàn)，還是可以通過獲取得到。并提出軟件開發(fā)過程或獲取過程。此領(lǐng)域不僅關(guān)注應(yīng)用軟件，也關(guān)注技術(shù)基礎(chǔ)架構(gòu)，描述了開發(fā)、測試、安裝和維護規(guī)程、服務(wù)要求和培訓(xùn)資料，并提出了變更管理措施。1.1.2.2.5COBIT框架第3個領(lǐng)域——交付與支持——包含IT服務(wù)的交付、由應(yīng)用系統(tǒng)進行的數(shù)據(jù)的實際處理（稱為應(yīng)用控制），以及必要的IT支持過程。它定義服務(wù)級別協(xié)議，管理第三方服務(wù)，處理性能和工作量，承擔(dān)持續(xù)服務(wù)的職責(zé)，確保系統(tǒng)安全，連接成本統(tǒng)計系統(tǒng)，教育和培訓(xùn)用戶，幫助和建議客戶，管理系統(tǒng)配置，處理問題和事件，管理數(shù)據(jù)、設(shè)備和操作。1.1.2.2.5COBIT框架第4個領(lǐng)域——監(jiān)控——隨著時間的推移，對IT過程的質(zhì)量及是否符合控制需求進行評估。此領(lǐng)域監(jiān)控過程，評估性能指標(biāo)和客戶滿意度，考慮內(nèi)部控制機制的充分性，獲得關(guān)于安全性、服務(wù)效果、遵守法律和職業(yè)道德的獨立保證等。1.1.2.3建模利益相關(guān)者和過程是成功三要素中的兩個，第3個要素是軟件建?！窜浖_發(fā)活動，這些活動被看作是軟件人工制品的建模。模型是來自現(xiàn)實的抽象，是現(xiàn)實的抽象表示。被實現(xiàn)和運行的系統(tǒng)也是現(xiàn)實的模型。1.1.2.3建模對人工制品建模必須進行溝通（使用語言）和文檔化（使用工具）。開發(fā)者需要一種語言來創(chuàng)建可視化模型和其他模型，并與客戶和同事進行討論。語言應(yīng)允許在不同抽象層面上構(gòu)建模型，在不同的細節(jié)層面上來表現(xiàn)所提出的解決方案。按照“一張圖片勝過千言萬語”的流行說法，語言應(yīng)當(dāng)具有強大的可視化構(gòu)件，還應(yīng)當(dāng)具有強大的說明性語義——也就是說，它應(yīng)當(dāng)允許在“說明性的”語句中捕獲“程序上的”含義。我們應(yīng)該能夠通過說明需要做“什么”，而不是需要“如何”去做，來進行溝通。1.1.2.3建模開發(fā)者還需要工具，或者更合適的說法是，為軟件開發(fā)過程提供的先進的、基于計算機的環(huán)境。這樣的工具和環(huán)境稱為計算機輔助軟件工程（Computer－AssistedSoftwareEngineering，CASE）。CASE使得在中央存儲庫中實現(xiàn)模型的存儲和檢索成為可能，并在計算機屏幕上進行模型的圖形和文字操作。在理想的情況下，存儲庫應(yīng)當(dāng)能夠為共享的多個用戶（多個開發(fā)者）提供對模型的訪問。1.1.2.3建模CASE存儲庫的典型功能有：協(xié)調(diào)對模型的訪問。促進開發(fā)者之間的合作。存儲模型的多個版本。識別版本間的區(qū)別。允許在不同的模型中共享相同的概念。檢查模型的一致性和完整性。生成項目報告和文檔。生成數(shù)據(jù)結(jié)構(gòu)和程序代碼（正向工程）。從已有的實現(xiàn)中生成模型（逆向工程）。1.1.2.3建模要注意的是，CASE所生成的程序只是一個代碼骨架——算法還需要由編程人員以通常的方式進行編碼。1.1.2.3建模1.1.2.3.1統(tǒng)一建模語言1.1.2.3.2

CASE和過程改進1.1.2.3.1統(tǒng)一建模語言“統(tǒng)一建模語言（UnifiedModelingLanguage，UML）是一種通用的、可視化的建模語言，用于對軟件系統(tǒng)的人工制品進行詳細說明、可視化、構(gòu)造和文檔化。它捕獲對必須構(gòu)建的系統(tǒng)的決策和理解，用于理解、設(shè)計、瀏覽、配置、維護和控制該系統(tǒng)的相關(guān)信息。它準(zhǔn)備為所有的開發(fā)方法、生命周期階段、應(yīng)用領(lǐng)域和媒體所使用。”1.1.2.3.1統(tǒng)一建模語言現(xiàn)在已是IBM一部分的Rational軟件公司開發(fā)了UML，它統(tǒng)一了早期方法和表示法中最佳的特征。1997年，對象管理組織（ObjectManagementGroup，OMG）批準(zhǔn)UML作為一種標(biāo)準(zhǔn)的建模語言。從那時起，UML就被IT產(chǎn)業(yè)所接受和廣泛接納并進一步開發(fā)。UML2．0版本在2005年被OMG采納。1.1.2.3.1統(tǒng)一建模語言盡管Rational提出了匹配過程，稱為Rational統(tǒng)一過程（RationalUnifiedProcess，RUP），但UML獨立于任何軟件開發(fā)過程。采用UML的過程必須支持一種面向?qū)ο蟮姆椒▉磉M行軟件生產(chǎn)。UML并不適合老式的結(jié)構(gòu)化方法，該方法導(dǎo)致系統(tǒng)由過程式編程語言來實現(xiàn)，例如COBOL。1.1.2.3.1統(tǒng)一建模語言UML也獨立于實現(xiàn)技術(shù)（只要它們是面向?qū)ο蟮模?，這使得UML在支持開發(fā)生命周期的詳細設(shè)計階段方面有點不足。然而，同樣的道理，它確實使UML對實現(xiàn)平臺中的特異性和頻繁變化富有彈性。1.1.2.3.1統(tǒng)一建模語言UML語言結(jié)構(gòu)允許為系統(tǒng)的靜態(tài)結(jié)構(gòu)和動態(tài)行為建模。系統(tǒng)被建模為一套合作的對象（軟件模塊），這些對象響應(yīng)外部事件來執(zhí)行為客戶（用戶）帶來利益的任務(wù)。特定的模型強調(diào)系統(tǒng)的某些方面，而忽略了在其他模型中被強調(diào)的那些方面。集成在一起的一套模型提供了對系統(tǒng)的完整描述。1.1.2.3.1統(tǒng)一建模語言UML模型可分為3組：狀態(tài)模型——描述靜態(tài)數(shù)據(jù)結(jié)構(gòu)。行為模型——描述對象協(xié)作。狀態(tài)變化模型——描述隨著時間的推移，系統(tǒng)所允許的狀態(tài)。1.1.2.3.1統(tǒng)一建模語言UML也包含少量的體系結(jié)構(gòu)構(gòu)造，為了迭代和增量開發(fā)而對系統(tǒng)進行模塊化。然而，UML并不主張任何特定的、系統(tǒng)能夠或應(yīng)當(dāng)遵守的體系結(jié)構(gòu)框架，這樣的框架會定義系統(tǒng)構(gòu)件的分層結(jié)構(gòu)，并詳細說明它們需要如何進行通信，因此，會與UML作為通用語言的目標(biāo)相矛盾。1.1.2.3.2

CASE和過程改進過程改進遠不只是引入新的方法和技術(shù)。事實上，在一個過程成熟度的低級別中，為組織引進新的方法和技術(shù)，更多的情況是弊大于利。1.1.2.3.2

CASE和過程改進當(dāng)CASE技術(shù)作為集成環(huán)境應(yīng)用時，就是一個很好的例子，這個集成環(huán)境為了生產(chǎn)出新的設(shè)計產(chǎn)品而允許多個開發(fā)者合作，并共享設(shè)計信息。這樣的CASE環(huán)境強行施加了某些過程，那么開發(fā)團隊就必須服從利用該技術(shù)。然而，如果開發(fā)團隊在以前沒能改進其過程，那么它極不可能吸收由CASE工具所規(guī)定的過程。結(jié)果，由新技術(shù)所提供的潛在的生產(chǎn)力和質(zhì)量增益將無法實現(xiàn)。1.1.2.3.2

CASE和過程改進這項評論并非是說CASE技術(shù)是具有風(fēng)險的業(yè)務(wù)，它只是用于驅(qū)動整個開發(fā)過程，并且在開發(fā)團隊沒有準(zhǔn)備好接受該過程時，才是有風(fēng)險的。然而，對于那些在自己的本地工作站上工作的個體開發(fā)者來說，在工具內(nèi)部使用同樣的CASE方法和技術(shù)總會帶來個體生產(chǎn)率和質(zhì)量的改進。在課堂上使用鉛筆和紙對軟件人工制品建?？赡苁怯幸饬x的，但是對于真正的項目來說，從來都沒有意義。1.1.3開發(fā)還是集成今天，只是使手工過程自動化來開發(fā)新的軟件系統(tǒng)幾乎是不存在的。大部分開發(fā)項目取代或擴展了現(xiàn)存的軟件解決方案，或?qū)⑺鼈兗蔀楦蟮摹⑻峁┬碌淖詣踊降慕鉀Q方案。因此，集成開發(fā)（相對于“從零開始”的應(yīng)用開發(fā)的立場）所進行的是使用相同迭代生命周期方法和生產(chǎn)相同軟件產(chǎn)品模型，差別就在于所強調(diào)的集成層次和使能技術(shù)。1.1.3開發(fā)還是集成我們將集成方法分為3大類型：面向信息和／或面向門戶的集成。面向接口的集成。面向過程的集成。1.1.3開發(fā)還是集成面向信息的集成依賴于源應(yīng)用系統(tǒng)和目標(biāo)應(yīng)用系統(tǒng)之間的信息交換。這是在數(shù)據(jù)庫或應(yīng)用程序接口（applicationprogramminginterface，API）層次上的集成，這種集成使信息具體化，以供其他應(yīng)用程序使用。1.1.3開發(fā)還是集成面向門戶的集成可以看作是一種特殊的面向信息的集成，將來自多個軟件系統(tǒng)的信息具體化到一個共同的用戶界面，具有代表性的是Web瀏覽器的門戶。區(qū)別是面向信息的集成關(guān)注信息的實時交換，而門戶則需要對來自后臺系統(tǒng)的具體化的信息進行人為干預(yù)。1.1.3開發(fā)還是集成面向接口的集成將應(yīng)用接口（即通過接口抽象定義的服務(wù)）連接在一起。接口顯示了一個應(yīng)用系統(tǒng)向其他應(yīng)用系統(tǒng)所提供的有益服務(wù)。面向接口的集成并不需要所參與的應(yīng)用系統(tǒng)的詳細業(yè)務(wù)過程可見。服務(wù)的供給可以是信息的（當(dāng)提供數(shù)據(jù)時），或者是事務(wù)的（當(dāng)提供一項功能時）。前者的確是一種基于信息集成的變種，而后者則需要修改源應(yīng)用系統(tǒng)和目標(biāo)應(yīng)用系統(tǒng)，或者有可能導(dǎo)致一個新的應(yīng)用系統(tǒng)（合成的應(yīng)用系統(tǒng)）。1.1.3開發(fā)還是集成面向過程的集成是將應(yīng)用系統(tǒng)連接在一起，方法是在現(xiàn)有應(yīng)用系統(tǒng)的已有過程集和數(shù)據(jù)集的頂部定義一個新的過程層?？梢哉撟C，這是一個最終的集成方案，使新的過程邏輯從參與應(yīng)用系統(tǒng)的應(yīng)用邏輯中分離出來，并可能產(chǎn)生一種新的解決方案，將以前手工執(zhí)行的任務(wù)自動化。面向過程的集成開始于建立新的過程模型，并假設(shè)被集成的應(yīng)用系統(tǒng)的內(nèi)部過程完全可見。面向過程的集成具有戰(zhàn)略高度，旨在提升現(xiàn)有的業(yè)務(wù)過程，并帶來競爭優(yōu)勢。1.2系統(tǒng)規(guī)劃必須對信息系統(tǒng)項目進行規(guī)劃，必須為初期的開發(fā)、改進或者排除而進行識別、分類、排序和選擇。問題是，哪種IS技術(shù)和應(yīng)用系統(tǒng)對業(yè)務(wù)的回報價值最大？在理想的情況下，所做的決定應(yīng)當(dāng)以定義良好的業(yè)務(wù)策略和仔細且有條不紊的規(guī)劃為基礎(chǔ)。1.2系統(tǒng)規(guī)劃可以通過各種策略規(guī)劃、業(yè)務(wù)建模、業(yè)務(wù)過程重組、策略調(diào)整、信息資源管理或諸如此類的過程來決定業(yè)務(wù)策略。所有這些方法承擔(dān)了研究組織中基本業(yè)務(wù)過程的任務(wù)，目的是為業(yè)務(wù)確定長遠的洞察力，然后優(yōu)先考慮能夠通過使用信息技術(shù)而得以解決的業(yè)務(wù)問題。1.2系統(tǒng)規(guī)劃這就是說，有許多組織——特別是許多小型組織——并沒有明確的業(yè)務(wù)策略。這樣的組織有可能會通過簡單地識別當(dāng)前最迫切需要處理的業(yè)務(wù)問題來決定信息系統(tǒng)開發(fā)。當(dāng)外部環(huán)境或內(nèi)部業(yè)務(wù)情況發(fā)生變化時，將不得不對現(xiàn)有的信息系統(tǒng)進行修改，甚至替換。這樣的運作模式允許小型組織快速地重新對當(dāng)前情況集中精力，利用新的機會和抵制新的威脅。1.2系統(tǒng)規(guī)劃大型組織經(jīng)受不起業(yè)務(wù)方向的不斷改變。事實上，它們往往因在同一業(yè)務(wù)線上的其他組織而決定方向。在某種程度上，它們能夠為當(dāng)前的需要塑造環(huán)境。然而，大型組織也必須仔細地考慮到未來，它們必須使用基于規(guī)劃的方法來識別開發(fā)項目。在典型的情況下，大型項目需要長時間來完成。它們太過麻煩，以至于不易被改變或替換。它們需要容納，甚至是瞄準(zhǔn)未來的機會和威脅。1.2系統(tǒng)規(guī)劃系統(tǒng)規(guī)劃可以通過多種方式來制定。一種傳統(tǒng)的方法稱為SWOT——優(yōu)勢、劣勢、機會、威脅（strength，weakness，opportunity，threat）。另一種流行的策略基于VCM——價值鏈模型（valuechainmodel）。用于制定業(yè)務(wù)策略的更加現(xiàn)代的方法稱為BPR——業(yè)務(wù)過程重組（businessprocessre-engineering）。也可以通過使用為ISA——信息系統(tǒng)體系結(jié)構(gòu)（informationsystemarchitecture）而設(shè)計的藍圖來評估一個組織的信息需求，這樣的藍圖可以通過對描述性框架進行類比而獲得，這在IT以外的學(xué)科中已經(jīng)得到證明，例如建筑業(yè)。1.2系統(tǒng)規(guī)劃所有的系統(tǒng)規(guī)劃方法都有一個重要的共同點：它們關(guān)心效果（做正確的事）而不是效率（做事正確）?！案行省币馕吨梢允褂矛F(xiàn)有的或更少的資源，以更快的速度完成相同的工作?！案行Ч币馕吨褂每蛇x擇的資源和想法來做一個更好的工作，也可以意味著通過創(chuàng)新來實現(xiàn)競爭優(yōu)勢。1.2系統(tǒng)規(guī)劃1.2.1SWOT方法1.2.2VCM方法1.2.3BPR方法1.2.4ISA方法1.2.1SWOT方法SWOT（優(yōu)勢、劣勢、機會、威脅）方法以調(diào)整組織的優(yōu)勢、劣勢、機會和威脅的方式來進行IS開發(fā)項目的識別、分類、排序和選擇。這是一個從確定組織使命開始的、自頂向下的方法。1.2.1SWOT方法使命陳述捕獲了一個組織的獨特性質(zhì)，并詳細說明它未來的愿景。在一個良好的使命陳述中，重點在于客戶的需要，而不在于組織所交付的產(chǎn)品或服務(wù)。1.2.1SWOT方法使命陳述和根據(jù)它開發(fā)的業(yè)務(wù)策略考慮了公司在管理、生產(chǎn)、人力資源、財務(wù)、市場和研發(fā)等領(lǐng)域中的內(nèi)部優(yōu)勢和劣勢。這些優(yōu)勢和劣勢必須被認可、同意并優(yōu)先考慮。一個成功的組織對它當(dāng)前的優(yōu)勢和劣勢要有良好的理解，以指導(dǎo)其業(yè)務(wù)策略的發(fā)展。1.2.1SWOT方法優(yōu)勢的例子包括：品牌和專利的擁有。在客戶和供應(yīng)商中良好的口碑。資源或技術(shù)的專有權(quán)。由于生產(chǎn)量、私有的專門技能、專有權(quán)利或伙伴關(guān)系而帶來的成本優(yōu)勢。1.2.1SWOT方法劣勢通常是潛在優(yōu)勢的缺乏。劣勢的例子包括：不可靠的現(xiàn)金流。員工的劣等技術(shù)基礎(chǔ)和對一些關(guān)鍵員工的依賴。欠佳的營業(yè)地點。1.2.1SWOT方法對內(nèi)部的企業(yè)優(yōu)勢和劣勢的識別是成功業(yè)務(wù)規(guī)劃的一個必要條件，而不是充分條件。組織在真空中無法運作——它依賴于外部的經(jīng)濟、社會、政治和技術(shù)因素。組織必須了解可利用的外部機會和可避免的外部威脅，這些是組織無法控制的因素，但對它們的認識是決定組織目的和目標(biāo)的基礎(chǔ)。1.2.1SWOT方法機會的例子包括：新的、更少限制的規(guī)章，撤除貿(mào)易壁壘。策略聯(lián)盟、合資或合并。作為新市場的互聯(lián)網(wǎng)。競爭對手的潰敗，以及因此而導(dǎo)致的市場開放。1.2.1SWOT方法任何對環(huán)境帶有負面影響的改變都是威脅。威脅的例子包括：與競爭對手的價格戰(zhàn)的潛在性。技術(shù)的變更超越了能夠消化吸收的能力范圍。產(chǎn)品或服務(wù)上新的稅收障礙。1.2.1SWOT方法組織在任何指定的時間都追求一個或幾個極少量的長遠目標(biāo)。目標(biāo)通常是長期的（3-5年），甚至是“永恒的”。典型目標(biāo)的例子是：改進客戶滿意度、引進新的服務(wù)、解決競爭威脅，或增加對供應(yīng)商的控制。每個策略目標(biāo)必須與具體的目標(biāo)聯(lián)系在一起，該目標(biāo)通常表現(xiàn)為年度目標(biāo)。例如，“改進用戶滿意度”的目標(biāo)可以由更快地（譬如說在兩周內(nèi)）履行客戶訂單的目標(biāo)而得到支持。1.2.1SWOT方法目的和目標(biāo)需要管理策略和實現(xiàn)這些策略的具體政策。這種管理手段會調(diào)整組織結(jié)構(gòu)、分配資源，并確定發(fā)展項目，包括信息系統(tǒng)。圖l-3顯示了與SWOT分析有關(guān)的概念及其關(guān)聯(lián)和派生規(guī)則。SWOT矩陣定義了一個組織在市場中的位置，并且將組織的能力與其運行所處的競爭環(huán)境相匹配。1.2.1SWOT方法1.2.2VCM方法VCM（價值鏈模型）通過分析組織中完整的活動鏈（從原材料到銷售及運送給客戶的最終產(chǎn)品）來評估競爭優(yōu)勢。在價值鏈方法中，產(chǎn)品或服務(wù)是將價值轉(zhuǎn)交給客尸的媒介。用“鏈”來比喻生動地說明了：其中一個鏈接弱，將導(dǎo)致整個鏈的崩潰。模型的目的是理解哪種價值鏈配置將產(chǎn)生最大競爭優(yōu)勢。IS開發(fā)項目可以針對哪些環(huán)節(jié)、操作、分配渠道、銷售方式等給出最具競爭力的優(yōu)勢。1.2.2VCM方法在最初的VCM方法中，組織的職能分為基本活動和支持活動。基本活動對最終產(chǎn)品創(chuàng)造或增加了價值，它們分為5個連續(xù)的階段：1）內(nèi)部物流——接受對產(chǎn)品或服務(wù)的投入。2）操作——使用投入來創(chuàng)造產(chǎn)品或服務(wù)。3）外部物流——將產(chǎn)品或服務(wù)分銷給買家。4）銷售和市場——引導(dǎo)買家購買產(chǎn)品或服務(wù)。5）服務(wù)——維護或提高產(chǎn)品或服務(wù)的價值。1.2.2VCM方法這5個階段利用相關(guān)的信息技術(shù)，并且得到有關(guān)的各類信息系統(tǒng)的協(xié)助，例如：1）為內(nèi)部物流服務(wù)的倉儲系統(tǒng)。2）為操作服務(wù)的計算機制造系統(tǒng)。3）為外部物流服務(wù)的運送和調(diào)度系統(tǒng)。4）為銷售和市場服務(wù)的訂購和發(fā)票系統(tǒng)。5）為服務(wù)而服務(wù)的設(shè)備維護系統(tǒng)。1.2.2VCM方法支持活動并不增加價值，至少不直接增加價值。它們?nèi)匀皇腔A(chǔ)的，卻不豐富產(chǎn)品。支持活動包括：行政管理和基礎(chǔ)架構(gòu)、人力資源管理、研發(fā)，以及大家很熟悉的IS開發(fā)。1.2.2VCM方法VCM是對策略規(guī)劃和確定IS開發(fā)項目有利的工具，反之亦然。無所不在的計算機化促進了業(yè)務(wù)改變，并且依次創(chuàng)造了效率、成本的降低和競爭優(yōu)勢。換句話說，IT能夠轉(zhuǎn)換一個組織的價值鏈，在IT和VCM之間可以建立自我加強的循環(huán)。1.2.2VCM方法Porter和Millar指出了一個組織可以利用IT機會的5個步驟：l）評估產(chǎn)品和過程的信息強度。2）評估IT在產(chǎn)業(yè)結(jié)構(gòu)中的角色。3）識別那些能夠使IT創(chuàng)造競爭優(yōu)勢的方式，并對其排序。4）考慮IT如何能夠創(chuàng)建新業(yè)務(wù)。5）制定一份利用IT的規(guī)劃。1.2.3BPR方法要使用系統(tǒng)規(guī)劃的BPR（業(yè)務(wù)過程重組）方法一般基于這樣一個前提：當(dāng)今的組織必須徹底地改造自己，并丟棄那些現(xiàn)在正在使用的功能分解、分層結(jié)構(gòu)和操作原則。這個概念由Hammer、Davenport和Short引入，它立即引起了人們的興趣和爭議。1.2.3BPR方法大多數(shù)現(xiàn)代組織被編入關(guān)注功能、產(chǎn)品或區(qū)域的縱向單元。這些結(jié)構(gòu)和工作風(fēng)格可以追溯到18世紀(jì)和AdamSmith的勞動力分工原則，以及隨之而產(chǎn)生的工作分裂。業(yè)務(wù)過程被定義為“采取一種或多種輸入、并創(chuàng)造對客戶有價值的輸出的活動集合”，沒有任何一個雇員或部門會對這樣的業(yè)務(wù)過程負責(zé)。1.2.3BPR方法BPR挑戰(zhàn)了Smith的勞動力分工的產(chǎn)業(yè)原則、分層控制和規(guī)模經(jīng)濟。在當(dāng)今世界，組織必須能夠迅速地適應(yīng)市場變化、新技術(shù)、競爭因素和客戶的要求等。1.2.3BPR方法業(yè)務(wù)過程必須跨越許多部門僵化的組織結(jié)構(gòu)的觀點已經(jīng)過時。組織必須關(guān)注業(yè)務(wù)過程，而不是個別的任務(wù)、工作、人員或部門功能。這些過程橫向跨越了業(yè)務(wù)，并且在與客戶的交互點上結(jié)束。“過程企業(yè)和傳統(tǒng)組織之間最明顯的區(qū)別是過程所有者的存在”。1.2.3BPR方法BPR的主要目的是在組織中從根本上重新設(shè)計業(yè)務(wù)過程（因此，有時將BPR稱為過程再設(shè)計）。必須對業(yè)務(wù)過程進行識別、流程化和改進。在工作流圖中對過程文檔化，并經(jīng)歷了工作流分析。工作流捕獲了業(yè)務(wù)過程中的事件、文檔和信息流，并且可以用來計算這些活動所花費的時間、資源和成本。1.2.3BPR方法Davenport和Short給BPR推薦了一種方法，此方法具有5個步驟：l）確定業(yè)務(wù)愿景與過程目標(biāo)（業(yè)務(wù)愿景來自使命陳述；目標(biāo)專注于成本和時間的減少、質(zhì)量改進、員工激勵和知識獲取等）。2）確定要再造的過程。3）了解并度量現(xiàn)有過程（為了避免過去的錯誤，并為過程再設(shè)計及過程改進建立基線）。4）識別信息技術(shù)（IT）杠桿，以及它們?nèi)绾文軌蛴绊戇^程再設(shè)計和改進。5）為新過程設(shè)計并建造原型（原型是一個工作流系統(tǒng)，是迭代和增量開發(fā)的主題）。1.2.3BPR方法在組織中實現(xiàn)BPR的主要障礙在于需要向傳統(tǒng)的縱向管理結(jié)構(gòu)中嵌入一個橫向過程。一個嚴(yán)肅的BPR首先需要改變組織，目的是使作為基礎(chǔ)組織單元的開發(fā)團隊成為中心，這些團隊負責(zé)一個或多個端到端的業(yè)務(wù)過程。1.2.3BPR方法有時候，一個徹底的改變是不能被接受的，傳統(tǒng)結(jié)構(gòu)不能在一朝一夕之間就被改變。徹底的推進會遭到反抗，從而有損于BPR的潛在好處。在這種情況下，組織仍然能夠受益于對其業(yè)務(wù)過程的建模，以及試圖只是改進而不是再造它們。業(yè)務(wù)過程改進（businessprocessimprovement，BPI）一詞用于描述一個改進的開端。1.2.3BPR方法一旦定義了業(yè)務(wù)過程，過程所有者就需要IT支持，來進一步改進這些過程的效率，從而引發(fā)了IS開發(fā)項目將精力集中于實現(xiàn)已被識別的工作流。在所有當(dāng)代的組織性能（例如質(zhì)量、服務(wù)、速度、成本、價格、競爭優(yōu)勢和靈活性）的估量中，BPR效果和IT效率的組合能夠帶來引人注目的改進。1.2.4ISA方法不同于前面已經(jīng)介紹的方法，ISA（信息系統(tǒng)體系結(jié)構(gòu)）是一種自底向上的方法，它為能夠適應(yīng)各種業(yè)務(wù)策略的IS解決方案提供了一種中立的系統(tǒng)結(jié)構(gòu)框架。因此，ISA方法并不包含系統(tǒng)規(guī)劃方法學(xué)——它簡單地提供了一個影響大多數(shù)業(yè)務(wù)策略的框架。1.2.4ISA方法ISA框架被描述成一個具有30個單元的表格，有5行6列。表中的行表示用于復(fù)雜工程產(chǎn)品（如信息系統(tǒng)）構(gòu)建的不同視角，這些視角就是5個IS參與者：1）規(guī)劃者——確定系統(tǒng)的范圍。2）所有者——定義企業(yè)概念模型。3）設(shè)計者——詳細說明系統(tǒng)物理模型。4）建造者——提供詳細的技術(shù)解決方案。5）承包者——提供系統(tǒng)構(gòu)件。1.2.4ISA方法表中的6列表現(xiàn)了每個參與者所從事的6種不同的描述或體系結(jié)構(gòu)模型。每個描述彼此都有很大的不同，但它們在本質(zhì)上又互相關(guān)聯(lián)著。描述提供了對每個參與者都很關(guān)鍵的6個問題的答案。A．這件事由什么構(gòu)成？（即IS實例中的數(shù)據(jù)）B．這件事是如何起作用的？（即業(yè)務(wù)過程）C．這件事位于何處？（即處理構(gòu)件的位置）D．誰與這件事一起工作？（即用戶）E．這件事何時發(fā)生？（即事件和狀態(tài)的調(diào)度）F．這件事為何而發(fā)生？（即企業(yè)的動機）1.2.4ISA方法這30個單元中的視角與描述相結(jié)合，提供了一個強有力的分類，為IS開發(fā)建造了一個完整的體系結(jié)構(gòu)?？v向視角可能在細節(jié)上有所不同，但更重要的是，它們在本質(zhì)上是不同的，并且使用了不同的建模表示法。不同的模型強調(diào)參與者的不同觀點。同樣，橫向描述是針對不同原因的——每項描述都回答了以上6個問題中的一個。1.2.4ISA方法ISA方法最具吸引力的特征來自它提供的框架，該框架具有足夠的靈活性，以適應(yīng)未來業(yè)務(wù)環(huán)境和資源的變化。這是因為ISA解決方案并不來自任何特定的業(yè)務(wù)策略，它只是一個為IS系統(tǒng)進行完整描述的框架。該框架來自很多已有的學(xué)科——一其中有些已經(jīng)有一千多年的歷史（如古典建筑學(xué)）。1.3三級管理系統(tǒng)與系統(tǒng)規(guī)劃有關(guān)的是，要認識到一個組織具有三級管理：1）策略級。2）戰(zhàn)術(shù)級。3）操作級。1.3三級管理系統(tǒng)這3個級別是由決策的獨特焦點、一套明確的IS應(yīng)用需求、需要從IT中得到的特定支持所刻畫的。系統(tǒng)規(guī)劃的任務(wù)是定義IS應(yīng)用系統(tǒng)和IT解決方案的混合體，使其在特定的時間點對組織最有效。表1-1定義了將決策級別匹配到IS應(yīng)用和IT解決方案時所涉及的問題。1.3三級管理系統(tǒng)1.3三級管理系統(tǒng)為組織提供了最大回報的IS應(yīng)用和IT解決方案處于策略級，然而這些也是最難實現(xiàn)的解決方案——它們使用“非常前沿的”技術(shù)，并要求非常純熟的技術(shù)和專門的設(shè)計。畢竟，這些是能夠給組織帶來市場競爭優(yōu)勢的系統(tǒng)。1.3三級管理系統(tǒng)另一方面，支持操作管理級的系統(tǒng)是相當(dāng)常規(guī)的，它使用傳統(tǒng)的數(shù)據(jù)庫技術(shù)，并經(jīng)常從預(yù)先封裝的解決方案中定制。這些系統(tǒng)不可能提供競爭優(yōu)勢，但是如果沒有它們，組織就無法正常運作。1.3三級管理系統(tǒng)每個現(xiàn)代組織都有一套完整的操作級系統(tǒng)，但只有管理得最好的組織才有一套綜合的策略級IS應(yīng)用系統(tǒng)。為高級別策略及戰(zhàn)術(shù)決策而存儲和檢索數(shù)據(jù)的主要技術(shù)，稱為數(shù)據(jù)倉庫。1.3三級管理系統(tǒng)表1-1的最后一列關(guān)聯(lián)了3個關(guān)鍵的IS概念——知識、信息和數(shù)據(jù)——伴隨著3個決策級別上的系統(tǒng)。這些關(guān)鍵概念的定義是：數(shù)據(jù)——代表著涉及業(yè)務(wù)活動的價值、質(zhì)量、概念和事件的原始事實。信息——增值事實；已經(jīng)被處理并概括為產(chǎn)品增值事實的數(shù)據(jù)，揭示了新的特征和趨勢。知識——對信息的理解，由經(jīng)驗或研究而獲得，并導(dǎo)致有效果和有效率地做事的能力，能夠存在于人的頭腦中（隱性知識），或者文檔化為一些結(jié)構(gòu)化的形式。1.3三級管理系統(tǒng)例如，一個電話號碼就是一個數(shù)據(jù)片段。根據(jù)地理區(qū)域或他們自己的客戶等級而進行的電話號碼分組，就導(dǎo)致了信息。理解如何在電話銷售中使用該信息引導(dǎo)人們購買產(chǎn)品，就是知識。Benson和Standing開玩笑地指出，決定不在半夜給某人打電話，就是智慧。更嚴(yán)肅地講，智慧有時被認為是最終的、關(guān)鍵的IS概念，它后來被定義為使用知識來做出良好判斷和決定的能力。1.3三級管理系統(tǒng)1.3.1事務(wù)處理系統(tǒng)1.3.2分析處理系統(tǒng)1.3.3知識處理系統(tǒng)1.3.1事務(wù)處理系統(tǒng)在決策操作級上的系統(tǒng)主類是聯(lián)機事務(wù)處理（OnLineTransactionProcessing，OLTP）系統(tǒng)。事務(wù)被定義為工作的一個邏輯單元，完成某一特定的業(yè)務(wù)任務(wù)，并在任務(wù)完成后保證數(shù)據(jù)庫的完整性。從事務(wù)的視角上來看，完整性意味著在事務(wù)完成其執(zhí)行后，數(shù)據(jù)保留了一致性和正確性。1.3.1事務(wù)處理系統(tǒng)事務(wù)處理系統(tǒng)天生就與數(shù)據(jù)庫技術(shù)關(guān)聯(lián)在一起。數(shù)據(jù)庫就是一個企業(yè)數(shù)據(jù)的中央存儲庫和每個企業(yè)的關(guān)鍵策略資源。數(shù)據(jù)庫系統(tǒng)具有關(guān)鍵職責(zé)，使任何數(shù)量的用戶和應(yīng)用程序都能夠并發(fā)地、多用戶地訪問數(shù)據(jù)。根據(jù)哪些數(shù)據(jù)可以并發(fā)訪問，哪些數(shù)據(jù)不可以并發(fā)訪問，以及在什么樣的條件下可以對數(shù)據(jù)進行修改的業(yè)務(wù)事務(wù)理念，對這種數(shù)據(jù)訪問權(quán)劃定界限（歸納）。1.3.1事務(wù)處理系統(tǒng)數(shù)據(jù)庫的規(guī)模以千兆字節(jié)級（Gb——10^9字節(jié)）甚至是兆兆字節(jié)級（Tb——10^12字節(jié)）來估算。因此，數(shù)據(jù)庫駐留在一個非易失性的（持久的）二級存儲上，例如磁盤或光盤。數(shù)據(jù)之所以被稱為是持久的，是因為它永久性地駐留在磁盤上，無論磁盤驅(qū)動器是否通電或者正在使用。1.3.1事務(wù)處理系統(tǒng)除了并發(fā)控制，確保數(shù)據(jù)庫總是能夠從軟件和硬件故障中恢復(fù)的事務(wù)理念是極其重要的。任何從故障中的恢復(fù)，都必須確保數(shù)據(jù)被返回（回滾）到事務(wù)開始前所存在的正確狀態(tài)。反過來說，一個故障事務(wù)可以自動重啟（前滾），以便完成一個新的、正確的、由事務(wù)處理邏輯所決定的狀態(tài)。1.3.1事務(wù)處理系統(tǒng)盡管數(shù)據(jù)庫狀態(tài)大體上是由各種在數(shù)據(jù)上執(zhí)行的事務(wù)的處理邏輯決定的，但是該邏輯也受到了企業(yè)范圍的業(yè)務(wù)規(guī)則的嚴(yán)格控制。這里介紹了由事務(wù)支配的應(yīng)用邏輯和由其他數(shù)據(jù)庫編程機制支配的業(yè)務(wù)邏輯之間的差別，即參照完整性約束和觸發(fā)器。例如，如果一個業(yè)務(wù)規(guī)則聲明了學(xué)生必須經(jīng)過必要的考試才能入學(xué)，那么就不允許應(yīng)用事務(wù)忽視該業(yè)務(wù)規(guī)則而使不符合資格的學(xué)生入學(xué)。1.3.1事務(wù)處理系統(tǒng)如前所述，數(shù)據(jù)庫是任何企業(yè)的關(guān)鍵策略資源。因此，數(shù)據(jù)庫技術(shù)通過確保只有通過認證和授權(quán)的用戶及應(yīng)用程序才可以訪問數(shù)據(jù)和執(zhí)行內(nèi)部數(shù)據(jù)庫程序（存儲過程），從而提供了保證數(shù)據(jù)安全性的機制。1.3.2分析處理系統(tǒng)處于決策的戰(zhàn)術(shù)級上的主要系統(tǒng)是聯(lián)機分析處理（OnLineAnalyticalProcessing，OLAP）系統(tǒng)。相對于導(dǎo)致數(shù)據(jù)改變的典型事務(wù)處理而言，分析處理通過對預(yù)先存在的歷史數(shù)據(jù)的分析來輔助決策。因此，分析處理系統(tǒng)并不要求詳細的銷售數(shù)據(jù)，而是試圖回答這樣的詢問：“與去年同月份中正常的銷售相比，我們從上個月針對女性客戶的某些產(chǎn)品的推廣銷售中獲得了多少利潤？”用于這種分析的歷史數(shù)據(jù)越多，做出的決策就會越可靠。1.3.2分析處理系統(tǒng)分析處理系統(tǒng)與數(shù)據(jù)倉庫技術(shù)聯(lián)系在一起。數(shù)據(jù)倉庫（datawarehouse）的創(chuàng)建方式通常是在一個或多個事務(wù)數(shù)據(jù)庫中提取數(shù)據(jù)的增量拷貝。數(shù)據(jù)倉庫總是增加新數(shù)據(jù)，而從不移除歷史數(shù)據(jù)。因此，數(shù)據(jù)庫倉庫很快就變得比從中提取數(shù)據(jù)的源數(shù)據(jù)庫大數(shù)倍。大型數(shù)據(jù)倉庫需要兆兆字節(jié)（Tb——10^12字節(jié)）甚至千兆兆字節(jié)（Pb——10^15字節(jié)）來進行存儲。數(shù)據(jù)倉庫的規(guī)模是個問題，但幸運的是，數(shù)據(jù)是靜態(tài)的——也就是說，它不會被改變（除了由于在原始數(shù)據(jù)庫中發(fā)現(xiàn)了錯誤的、不一致的或缺失的數(shù)據(jù)而導(dǎo)致的改變）。1.3.2分析處理系統(tǒng)作為戰(zhàn)術(shù)級管理者的需要和預(yù)期，分析系統(tǒng)為支持數(shù)據(jù)密集型的隨機查詢而設(shè)計，這里特別要求了數(shù)據(jù)倉庫技術(shù)。在數(shù)據(jù)倉庫技術(shù)的前端，可通過零編程訪問工具去查詢需要提供給管理者的數(shù)據(jù)。在數(shù)據(jù)倉庫技術(shù)的后端，需要創(chuàng)建和組織單個的數(shù)據(jù)倉庫，使得能夠輕松地對歷史的、詳細的和被適當(dāng)分割、預(yù)先匯總和預(yù)先封裝的數(shù)據(jù)進行查詢。1.3.2分析處理系統(tǒng)對數(shù)據(jù)的匯總和封裝構(gòu)成了數(shù)據(jù)倉庫的一個獨特特征，目的是給從源系統(tǒng)中提取的數(shù)據(jù)增加價值。匯總（聚集）對數(shù)據(jù)進行了選擇、連接和分組，目的是為終端用戶的直接訪問提供預(yù)估的措施和趨勢分析。封裝將操作數(shù)據(jù)和匯總數(shù)據(jù)轉(zhuǎn)變?yōu)楦杏玫母袷剑鐖D、圖表、表格和動畫。分割使用技術(shù)手段和用戶配置文件，來減少系統(tǒng)尋找查詢答案時需要掃描的數(shù)據(jù)量。1.3.2分析處理系統(tǒng)由于已經(jīng)證明創(chuàng)建大型的、堅如磐石的、存儲所有企業(yè)數(shù)據(jù)的數(shù)據(jù)倉庫是一項真正的挑戰(zhàn)，所以就涌現(xiàn)了其他相關(guān)技術(shù)。一個流行而實用的解決方案是建立數(shù)據(jù)集市（datamart）。與數(shù)據(jù)倉庫一樣，數(shù)據(jù)集市是致力于分析處理的專用數(shù)據(jù)庫；而與數(shù)據(jù)倉庫不同的是，數(shù)據(jù)集市只保留了與某個特別部門或業(yè)務(wù)功能相關(guān)的企業(yè)數(shù)據(jù)的一個子集。此外，數(shù)據(jù)集市傾向于主要保存被匯總的歷史數(shù)據(jù)，并在原始的存儲源上保留詳細的操作數(shù)據(jù)。1.3.2分析處理系統(tǒng)一種新興的趨勢是datawebhouse，它被定義為“一個在Web上實現(xiàn)的、不用中央數(shù)據(jù)存儲庫的、分布式的數(shù)據(jù)倉庫”。datawebhouse提供了一個關(guān)于從多個數(shù)據(jù)源中提取、清洗和加載大量潛在的、不一致的數(shù)據(jù)到單個數(shù)據(jù)存儲中的困難的自然答復(fù)，也為在企業(yè)局域網(wǎng)上的分析處理提供了一項可選技術(shù)。作為每個企業(yè)保衛(wèi)最森嚴(yán)的策略資產(chǎn)，它在互聯(lián)網(wǎng)上的潛在使用自然地被數(shù)據(jù)保密性和安全性的要求所限制。在這些局限以外，datawebhouse能夠提供非常有用的、對互聯(lián)網(wǎng)用戶行為的相關(guān)數(shù)據(jù)的解析分析（也就是所謂的數(shù)據(jù)點擊流）。1.3.3知識處理系統(tǒng)處于決策的戰(zhàn)略級上的主要系統(tǒng)是知識處理（knowledgeProcessing）系統(tǒng)。知識通常被定義為專門技能——作為經(jīng)驗的結(jié)果而累積的智力資本。如Rus和Lindvall所指出的，“隨著智力資本而來的主要問題是，它是有腿的，而且每天都走回家。以同樣的比率，行家走出門，外行走進門。無論許多軟件組織是否承認它，它們都面臨著維持競爭水平的挑戰(zhàn)，以贏得合同并履行承諾。1.3.3知識處理系統(tǒng)要維持當(dāng)前在企業(yè)信息系統(tǒng)（enterpriseinformationsystem，EIS）中的智力資本，必須對專門技能加以管理。知識管理必須有效地幫助組織在信息系統(tǒng)中發(fā)現(xiàn)、組織、分配和運用知識編碼。數(shù)據(jù)挖掘（datamining）屬于知識管理領(lǐng)域，它關(guān)注探索性的數(shù)據(jù)分析，來發(fā)現(xiàn)能夠（重新）發(fā)現(xiàn)知識和支持決策的關(guān)系及模式（可能是以前不知道的或被遺忘了的）。1.3.3知識處理系統(tǒng)數(shù)據(jù)挖掘的主要目的有：關(guān)聯(lián)（路徑分析）——在數(shù)據(jù)中發(fā)現(xiàn)一個事件導(dǎo)致另一個相關(guān)事件的模式。例如，預(yù)言哪些出租了物業(yè)的人有可能搬出租賃市場，并在不久的將來購買物業(yè)。分類——發(fā)現(xiàn)某事實是否落入了預(yù)定的、感興趣的類別中。例如，預(yù)言哪些客戶有可能具有最小的忠誠度，并可能變成另一個手機供應(yīng)商的客戶。聚類——與分類相似，但是種類并不是以前就知道的，它們由聚類方法發(fā)現(xiàn)，而不是由分析員人為具體指定。例如，預(yù)言對主動電話銷售的反應(yīng)。1.3.3知識處理系統(tǒng)伴隨OLAP系統(tǒng)，用于數(shù)據(jù)挖掘的數(shù)據(jù)主要來源于數(shù)據(jù)倉庫，而不是操作型數(shù)據(jù)庫。數(shù)據(jù)挖掘擴充了OLAP達到策略管理要求的能力，它提供了預(yù)測性而不是回顧性的模型，使用人工智能（artificialintelligence，AI）技術(shù)來發(fā)現(xiàn)數(shù)據(jù)中的趨勢、相關(guān)性和模式。它還試圖發(fā)現(xiàn)隱藏的和意外的知識，而不是預(yù)見到的知識，因為就是這些隱藏的和意外的知識，才對決策具有更多的策略價值。1.4軟件開發(fā)生命周期軟件開發(fā)存在生命周期。生命周期是活動的有序集合，其中的活動是每個開發(fā)項目都要從事和管理的。過程和方法就是生命周期實現(xiàn)的工具。生命周期包括：應(yīng)用建模方法。在軟件產(chǎn)品被轉(zhuǎn)化的序列中的精確階段——從最初的開始到逐步停止。方法（方法學(xué)）和相關(guān)的開發(fā)過程。1.4軟件開發(fā)生命周期典型的生命周期開始于對當(dāng)前形勢的業(yè)務(wù)分析和所提出的解決方案。對分析模型進行更加詳細的設(shè)計，設(shè)計之后就是編程（實現(xiàn)）。對客戶來說，要對系統(tǒng)的實現(xiàn)部分進行集成和部署。從這個意義上說，系統(tǒng)變得可運行（它支持日常業(yè)務(wù)操作）。為了成功運行，系統(tǒng)經(jīng)歷了維護任務(wù)。1.4軟件開發(fā)生命周期本書將精力集中在分析和設(shè)計上，順便提及了實現(xiàn)。冒著有些簡化的風(fēng)險來講，業(yè)務(wù)分析就是關(guān)于要做什么，而系統(tǒng)設(shè)計就是關(guān)于如何使用可利用的技術(shù)去做，實現(xiàn)則是關(guān)于落實去做（從某種意義上說，就是將有形的軟件產(chǎn)品交付給客戶）。1.4軟件開發(fā)生命周期1.4.1開發(fā)方法1.4.2生命周期的階段1.4.3跨越生命周期的活動1.4.1開發(fā)方法隨著現(xiàn)代圖形用戶界面（graphicaluserinterface，GUI）的出現(xiàn)，計算方法已經(jīng)引人注目地發(fā)生了變化。GUI程序是事件驅(qū)動的，并且是用戶從鍵盤、鼠標(biāo)或其他輸入設(shè)備而引發(fā)的，以隨機且不可預(yù)知的方式來執(zhí)行事件。1.4.1開發(fā)方法在GUI環(huán)境中，用戶（在很大程度上）控制著程序的執(zhí)行，反之則不然。在每個事件背后都有一個軟件對象，知道如何在程序執(zhí)行的當(dāng)前狀態(tài)下為該事件服務(wù)。一旦完成了服務(wù)，控制權(quán)就返回給用戶。1.4.1開發(fā)方法這個程序——用戶交互的現(xiàn)代風(fēng)格，需要一種不同的軟件開發(fā)方法。所謂的結(jié)構(gòu)化方法已經(jīng)很好地服務(wù)于傳統(tǒng)軟件，而現(xiàn)代GUI系統(tǒng)需要對象編程，那么對象方法則是設(shè)計這種系統(tǒng)的最佳方式。1.4.1開發(fā)方法1.4.1.1結(jié)構(gòu)化方法1.4.1.2面向?qū)ο蠓椒?.4.1.1結(jié)構(gòu)化方法系統(tǒng)開發(fā)的結(jié)構(gòu)化方法也稱為是功能性、過程性和強制性的方法，該方法在20世紀(jì)80年代得到了推廣（事實上是標(biāo)準(zhǔn)化了）。從系統(tǒng)建模的視角來看，結(jié)構(gòu)化方法基于兩種技術(shù)：為過程建模而使用的數(shù)據(jù)流圖（dataflowdiagram，DFD）。為數(shù)據(jù)建模而使用的實體關(guān)系圖（entityrelationshipdiagram，ERD）。1.4.1.1結(jié)構(gòu)化方法結(jié)構(gòu)化方法以過程為中心，并且使用DFD作為開發(fā)的驅(qū)動力。在該方法中，系統(tǒng)在功能分解活動中被分解為可管理的單元，同時將系統(tǒng)有層次地劃分為由數(shù)據(jù)流連接的業(yè)務(wù)過程。1.4.1.1結(jié)構(gòu)化方法很多年來，結(jié)構(gòu)化方法已經(jīng)從以過程為中心漸漸地進化到了更多地以數(shù)據(jù)為中心，這一點直接導(dǎo)致了關(guān)系數(shù)據(jù)庫模型的普及。DFD在結(jié)構(gòu)化開發(fā)中的重要性已經(jīng)有點消退，開發(fā)已經(jīng)傾向于ERD的數(shù)據(jù)中心技術(shù)。1.4.1.1結(jié)構(gòu)化方法DFD和ERD的組合提供了相對完整的分析模型，在一個理想的、獨立于軟件／硬件考慮的抽象層面上，捕獲所有的系統(tǒng)功能和數(shù)據(jù)。這種分析模型后來被轉(zhuǎn)變?yōu)樵O(shè)計模型，通常用關(guān)系數(shù)據(jù)庫術(shù)語來表達。接著就是實現(xiàn)階段了。1.4.1.1結(jié)構(gòu)化方法分析和設(shè)計的結(jié)構(gòu)化方法由許多特征來刻畫，其中有些與現(xiàn)代軟件工程并不統(tǒng)一。例如，結(jié)構(gòu)化方法：傾向于按照次序及轉(zhuǎn)換的方式，而不是迭代和增量的方式——也就是說，并不通過迭代細化和增量軟件交付來促進一個無縫的開發(fā)過程。傾向于交付僵化的解決方案來滿足已識別的業(yè)務(wù)功能集，但是將來很難對業(yè)務(wù)功能集進行擴展和延伸。采用從零開始的開發(fā)，不支持已存在構(gòu)件的復(fù)用。1.4.1.1結(jié)構(gòu)化方法在開發(fā)的過程中，方法的轉(zhuǎn)換性質(zhì)引入了相當(dāng)大的曲解初始用戶需求的風(fēng)險。由于設(shè)計模型和實現(xiàn)代碼中的過程式解決方案，需要不斷地權(quán)衡分析模型中說明性較強的語義，更加重了這種風(fēng)險（這是因為分析模型比基礎(chǔ)設(shè)計和實現(xiàn)模型具有更加豐富的語義）。1.4.1.2面向?qū)ο蠓椒ㄏ到y(tǒng)開發(fā)的面向?qū)ο蠓椒▽⑾到y(tǒng)分解成不同粒度的構(gòu)件，在分解的底部是具有對象的類。類通過各種關(guān)系連接在一起，并且通過發(fā)送消息進行通信，消息調(diào)用對象上的操作。盡管面向?qū)ο蟮某绦蛟O(shè)計語言早在20世紀(jì)70年代初就已經(jīng)存在了，但是系統(tǒng)開發(fā)的面向?qū)ο蠓椒ㄔ?0世紀(jì)90年代才流行起來。后來，對象管理組織批準(zhǔn)了支持該方法的一系列UML（統(tǒng)一建模語言）標(biāo)準(zhǔn)。1.4.1.2面向?qū)ο蠓椒ㄅc結(jié)構(gòu)化方法相比較，面向?qū)ο蠓椒▌t更加以數(shù)據(jù)為中心——它圍繞著類模型進行演化。在分析階段，并不需要定義類的操作，只需要定義類的屬性就可以了。然而，UML中用例的日漸重要性稍微地將重點從數(shù)據(jù)轉(zhuǎn)向了過程。1.4.1.2面向?qū)ο蠓椒ㄓ羞@樣一種感覺，開發(fā)者使用對象方法是因為對象范型的技術(shù)優(yōu)勢，例如抽象、封裝、復(fù)用、繼承、消息傳遞和多態(tài)性。的確，這些技術(shù)性能會帶來更大的代碼和數(shù)據(jù)的可復(fù)用性、更少的開發(fā)時間、程序員生產(chǎn)力的提高、軟件質(zhì)量的改進和更強的可理解性。然而，在吸引人的同時，對象技術(shù)的優(yōu)勢并不總是能夠在實踐中得以實現(xiàn)。不過，我們今天確實在使用對象，并且明天還將繼續(xù)使用它們，其原因與由現(xiàn)代交互式的、基于GUI的應(yīng)用系統(tǒng)所要求的事件驅(qū)動編程的需要有關(guān)。1.4.1.2面向?qū)ο蠓椒▽ο蠓椒餍械钠渌蚺c處理新興應(yīng)用的需要和對抗應(yīng)用積壓的首選方式有關(guān)（已經(jīng)超過了所規(guī)劃和商定的日期的若于軟件產(chǎn)品，仍然要被交付，尤其是在與現(xiàn)有遺留系統(tǒng)的擴展和集成的過程中）。要求對象技術(shù)應(yīng)用的兩個最重要的新種類，是工作組計算和多媒體系統(tǒng)。依靠知名的對象打包概念來停止應(yīng)用積壓增長的思想，已經(jīng)被證實既具有吸引力又是可行的。1.4.1.2面向?qū)ο蠓椒ㄏ到y(tǒng)開發(fā)的對象方法遵循迭代和增量過程。單個模型（以及單個設(shè)計文檔）在分析、設(shè)計和實現(xiàn)階段被“細化”。細節(jié)被增加到連續(xù)的迭代中，根據(jù)需要進行修改和求精，所選模塊的增量版本則保持了用戶的滿意度，并且為其他模塊提供了額外的反饋。1.4.1.2面向?qū)ο蠓椒ㄇ缶_發(fā)是可能的，因為所有的開發(fā)模型（分析、設(shè)計和實現(xiàn)）在語義上都很豐富，并且都基于同一種“語言”——基礎(chǔ)詞匯在本質(zhì)上是相同的（類、屬性、方法、繼承、多態(tài)性，等等）。然而要注意的是，只要實現(xiàn)是