1考情分析

根據(jù)對歷年的考試真題進(jìn)行分析，本章要求考生掌握以下幾個方面的知識：

（1）信息系統(tǒng)開發(fā)方法：信息系統(tǒng)的生命周期（各階段目標(biāo)及其主要工作內(nèi)容）、信息系統(tǒng)建設(shè)的原則、信息系統(tǒng)開發(fā)方法。

（2）軟件工程知識：軟件需求分析與定義、軟件設(shè)計(jì)、測試與維護(hù)等。

（3）面向?qū)ο笙到y(tǒng)分析與設(shè)計(jì)：面向?qū)ο蟮幕靖拍睢⒔y(tǒng)一建模語言（United Model Language，UML）、可視化建模等。

（4）信息系統(tǒng)規(guī)劃：大型信息系統(tǒng)的特點(diǎn)及應(yīng)用、信息系統(tǒng)規(guī)劃的核心步驟以及BSP的步驟和工具方法。

1.1本章重點(diǎn)

2考點(diǎn)精講

2.1 信息系統(tǒng)生命周期及開發(fā)方法和模型

1. 信息系統(tǒng)生命周期階段

信息系統(tǒng)按照其生命周期進(jìn)行劃分大致可分成以下5個階段：系統(tǒng)規(guī)劃階段（編寫成系統(tǒng)設(shè)計(jì)任務(wù)書）、系統(tǒng)分析階段（提出新系統(tǒng)的邏輯模型）、系統(tǒng)設(shè)計(jì)階段（設(shè)計(jì)新系統(tǒng)的物理模型，概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)）、系統(tǒng)實(shí)施階段（開發(fā)、測試、硬件采購、調(diào)試等）、系統(tǒng)運(yùn)行和維護(hù)階段。

2. 軟件開發(fā)方法

① 結(jié)構(gòu)化方法

結(jié)構(gòu)化方法屬于自頂向下的開發(fā)方法，其基本思想是“自頂向下，逐步求精”，強(qiáng)調(diào)開發(fā)方法的結(jié)構(gòu)合理性及所開發(fā)軟件的結(jié)構(gòu)合理性。結(jié)構(gòu)化開發(fā)方法提出了一組提高軟件結(jié)構(gòu)合理性的準(zhǔn)則，如分解與抽象、模塊獨(dú)立性、信息隱蔽等。針對軟件生存周期各個不同的階段，它包括了結(jié)構(gòu)化分析（Structured Analysis，SA）、結(jié)構(gòu)化設(shè)計(jì)（Structured Design，SD）和結(jié)構(gòu)化程序設(shè)計(jì)（Structured Programing，SP）等方法。

② 面向?qū)ο蠓椒?/p>

面向?qū)ο螅∣bject-Orient，OO）方法認(rèn)為，客觀世界是由各種對象組成的，任何事物都是對象，每個對象都有自己的運(yùn)動規(guī)律和內(nèi)部狀態(tài)。OO方法構(gòu)造的系統(tǒng)復(fù)用性好，與結(jié)構(gòu)化方法相比階段界限不明顯，符合人們的思維習(xí)慣，在大型項(xiàng)目的開發(fā)上具有一定的局限性，不能涉足系統(tǒng)分析以前的開發(fā)環(huán)節(jié)。

③ 面向服務(wù)的方法（Service-Orient，SO）

OO的應(yīng)用構(gòu)建在類和對象之上，隨后發(fā)展起來的建模技術(shù)將相關(guān)對象按照業(yè)務(wù)功能進(jìn)行分組，就形成了構(gòu)件的概念。從應(yīng)用的角度來看，組織內(nèi)部、組織之間各種應(yīng)用系統(tǒng)的互相通信和互操作直接影響著組織對信息的掌握程度和處理速度。如何使信息系統(tǒng)快速響應(yīng)需求與環(huán)境變化提高系統(tǒng)的可復(fù)用性、信息資源共享和系統(tǒng)之間的互操作性，成為影響信息化建設(shè)效率的關(guān)鍵問題，SO思維方式恰好滿足。

④原型法

原型是指模擬某種產(chǎn)品的原始模型。在系統(tǒng)開發(fā)中，原型是系統(tǒng)的一個早期可運(yùn)行的版本，反映最終系統(tǒng)的部分重要特性。如果在獲得一組基本需求說明后，通過快速分析構(gòu)造出一個小型系統(tǒng)，滿足用戶的基本要求。原型法的優(yōu)點(diǎn)主要在于能更有效地確認(rèn)用戶需求。從直觀上來看，原型法適用于那些需求不明確的系統(tǒng)開發(fā)。對于分析層面難度大、技術(shù)層面難度不大的系統(tǒng)，適合于原型法。

3. 軟件開發(fā)模型

對于開發(fā)模型知識點(diǎn)，要掌握軟件生命周期的概念、各種開發(fā)模型的特點(diǎn)和應(yīng)用場合。主要考查的開發(fā)模型有瀑布模型、增量模型、螺旋模型、噴泉模型、迭代模型、V模型、敏捷方法和統(tǒng)一過程等。

（1）瀑布模型。瀑布模型也稱為生命周期法，是結(jié)構(gòu)化方法中最常用的開發(fā)模型，它把軟件開發(fā)的過程分為軟件計(jì)劃、需求分析、軟件設(shè)計(jì)、程序編碼、軟件測試和運(yùn)行維護(hù)6個階段，規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。瀑布模型是最早出現(xiàn)的軟件開發(fā)模型，它提供了軟件開發(fā)的基本框架。瀑布模型的本質(zhì)是“一次通過”，即每個活動只做一次，最后得到軟件產(chǎn)品，也稱作“線性順序模型”或者“傳統(tǒng)生命周期”。瀑布模型有利于大型軟件開發(fā)過程中人員的組織與管理，有利于軟件開發(fā)方法和工具的研究與使用，從而提高了大型軟件項(xiàng)目開發(fā)的質(zhì)量和效率。然而軟件開發(fā)的實(shí)踐表明，軟件開發(fā)各項(xiàng)活動之間并非完全是自上而下的，因此，瀑布模型存在嚴(yán)重的缺陷，只適用于需求明確或很少變更的項(xiàng)目，例如二次開發(fā)或升級型的項(xiàng)目。

（2）螺旋模型。螺旋模型將瀑布模型和快速原型模型相結(jié)合，綜合了兩者的優(yōu)點(diǎn)，并增加了風(fēng)險分析。它以原型為基礎(chǔ)，沿著螺線自內(nèi)向外旋轉(zhuǎn)，每旋轉(zhuǎn)一圈都要經(jīng)過制定計(jì)劃、風(fēng)險分析、實(shí)施工程及客戶評價等活動，并開發(fā)原型的一個新版本。經(jīng)過若干次螺旋上升的過程，得到最終的系統(tǒng)。

（3）迭代模型。迭代包括產(chǎn)生產(chǎn)品發(fā)布（穩(wěn)定、可執(zhí)行的產(chǎn)品版本）的全部開發(fā)活動和要使用該發(fā)布必需的所有其他外圍元素。所以，在某種程度上，開發(fā)迭代是一次完整地經(jīng)過所有工作流程的過程：（至少包括）需求工作流程、分析設(shè)計(jì)工作流程、實(shí)施工作流程和測試工作流程。在迭代模型中，每一次的迭代都會產(chǎn)生一個可以發(fā)布的產(chǎn)品，這個產(chǎn)品是最終產(chǎn)品的一個子集。迭代模型適用于項(xiàng)目事先不能完整定義產(chǎn)品所有需求、計(jì)劃多期開發(fā)的軟件開發(fā)。在現(xiàn)代的開發(fā)方法中，例如XP、RUP等，無一例外地都推薦、主張采用能顯著減少風(fēng)險的迭代模型。

（4）V模型。在瀑布模型及其他的經(jīng)典模型中，測試常常作為亡羊補(bǔ)牢的事后行為，但也有以測試為中心的開發(fā)模型，那就是V模型。V模型宣稱測試并不是一個事后彌補(bǔ)行為，而是一個同開發(fā)過程同樣重要的過程，如圖1-5所示。

圖1-5 V模型示意圖

V模型描述了一些不同的測試級別，并說明了這些級別所對應(yīng)的生命周期中不同的階段。在圖1-5中，左邊下降的是開發(fā)過程各階段，與此相對應(yīng)的是右邊上升的部分，即測試過程的各個階段。請注意在不同的組織中，對測試階段的命名可能有所不同。

V模型的價值在于它非常明確地標(biāo)明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。

（5）敏捷方法。敏捷方法是從20世紀(jì)90年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法，以應(yīng)對快速變化的需求。是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法。它們的具體名稱、理念、過程、術(shù)語都不盡相同，相對于“非敏捷”，更強(qiáng)調(diào)程序員團(tuán)隊(duì)與業(yè)務(wù)專家之間的緊密協(xié)作、面對面溝通、頻繁交付新的軟件版本、緊湊而自我組織型的團(tuán)隊(duì)、能夠很好地適應(yīng)需求變化的代碼編寫和團(tuán)隊(duì)組織方法，也更注重人的作用。Scrum是一種迭代式增量軟件開發(fā)過程，通常用于敏捷軟件開發(fā)。

（6）統(tǒng)一過程。統(tǒng)一過程（Unified Process，UP）是一個通用過程框架，可以用于種類廣泛的軟件系統(tǒng)、不同的應(yīng)用領(lǐng)域、不同的組織類型、不同的性能水平和不同的項(xiàng)目規(guī)模。UP是基于構(gòu)件的，在為軟件系統(tǒng)建模時，UP使用的是UML。與其他軟件過程相比，UP具有三個顯著的特點(diǎn)，即用例驅(qū)動、以基本架構(gòu)為中心、迭代和增量。UP中的軟件過程在時間上被分解為四個順序的階段，分別是初始階段、細(xì)化階段、構(gòu)建階段和交付階段。每個階段結(jié)束時都要安排一次技術(shù)評審，以確定這個階段的目標(biāo)是否已經(jīng)達(dá)到。如果評審結(jié)果令人滿意，就可以允許項(xiàng)目進(jìn)入下一個階段。由于UP是由Rational公司提出來的，因此，也簡稱為RUP。

（7）各種軟件開發(fā)模型的特點(diǎn)比較

2.2軟件工程

軟件工程是指應(yīng)用計(jì)算機(jī)科學(xué)、數(shù)學(xué)及管理科學(xué)等原理，以工程化的原則和方法來解決軟件問題的工程，其目的是提高軟件生產(chǎn)率、提高軟件質(zhì)量、降低軟件成本。IEEE對軟件工程的定義是：將系統(tǒng)的、規(guī)范的、可度量的工程化方法應(yīng)用于軟件開發(fā)、運(yùn)行和維護(hù)的全過程及上述方法的研究。

1、需求分析

①需求類型

軟件需求是指用戶對新系統(tǒng)在功能、行為、性能、設(shè)計(jì)約束等方面的期望。需求是多層次的，主要包括業(yè)務(wù)需求（系統(tǒng)高層次目標(biāo)）、用戶需求（用戶視角）和系統(tǒng)需求（系統(tǒng)的角度看問題）。

在QFD（質(zhì)量功能部署）中將軟件需求分為三類，分別是常規(guī)需求、期望需求和意外需求（興奮需求）。

②需求分析工具

2、軟件架構(gòu)設(shè)計(jì)

軟件架構(gòu)為軟件系統(tǒng)提供了一個結(jié)構(gòu)、行為和屬性的高級抽象，由構(gòu)件的描述、構(gòu)件的相互作用、指導(dǎo)構(gòu)件集成的模式以及這些模式的約束組成。軟件構(gòu)件風(fēng)格：數(shù)據(jù)流風(fēng)格、調(diào)用/返回風(fēng)格、獨(dú)立構(gòu)件風(fēng)格、虛擬機(jī)風(fēng)格和倉庫風(fēng)格。

3、軟件設(shè)計(jì)

從工程管理角度來看，軟件設(shè)計(jì)可分為概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)兩個階段。

（1）概要設(shè)計(jì)。也稱為高層設(shè)計(jì)，即將軟件需求轉(zhuǎn)化為數(shù)據(jù)結(jié)構(gòu)和軟件的系統(tǒng)結(jié)構(gòu)。

（2）詳細(xì)設(shè)計(jì)。也稱為低層設(shè)計(jì)，即對結(jié)構(gòu)圖進(jìn)行細(xì)化，得到詳細(xì)的數(shù)據(jù)結(jié)構(gòu)與算法。

4、軟件測試

軟件測試是軟件質(zhì)量保證的主要手段之一，也是在將軟件交付給客戶之前所必須完成的步驟。目前，軟件的正確性證明尚未得到根本的解決，軟件測試仍是發(fā)現(xiàn)軟件錯誤和缺陷的主要手段。軟件測試的目的就是在軟件投入生產(chǎn)性運(yùn)行之前，盡可能多地發(fā)現(xiàn)軟件產(chǎn)品（主要是指程序）中的錯誤和缺陷。

① 軟件測試的分類

軟件測試可分為單元測試、集成測試、確認(rèn)測試、系統(tǒng)測試、配置項(xiàng)測試和回歸測試等。軟件測試的方法分為靜態(tài)測試（包括桌面檢查、代碼走查、代碼審查）和動態(tài)測試（白盒測試、黑盒測試）。

• 單元測試也稱為模塊測試，測試對象是可獨(dú)立編譯或匯編的程序模塊、軟件構(gòu)件或OO軟件中的類，目的是檢查每個模塊能否正確實(shí)現(xiàn)設(shè)計(jì)說明書中的功能、性能、接口和其他設(shè)計(jì)約束等條件，發(fā)現(xiàn)模塊內(nèi)可能存在的各種差錯。

• 集成測試目的是檢查模塊之間，以及模塊和已集成的軟件之間的接口關(guān)系，并驗(yàn)證已集成的軟件是否符合設(shè)計(jì)要求。

• 確認(rèn)測試主要用于驗(yàn)證軟件功能、性能和其他特性是否與用戶需求一致。

• 系統(tǒng)測試的對象是完整的、集成的計(jì)算機(jī)系統(tǒng)，系統(tǒng)測試的目的是在真實(shí)系統(tǒng)工作環(huán)境下，驗(yàn)證完整的軟件配置項(xiàng)能否和系統(tǒng)正確連接，并滿足系統(tǒng)/子系統(tǒng)設(shè)計(jì)文檔和軟件開發(fā)合同規(guī)定的要求。

• 配置項(xiàng)測試的對象是軟件配置項(xiàng)，配置項(xiàng)測試的目的是檢驗(yàn)軟件配置項(xiàng)與SRS的一致性。

• 回歸測試的目的是測試軟件變更后，變更部分的正確性和對變更需求的符合性，以及軟件原有的、正確的功能、性能和其他規(guī)定的要求的不損害性。

② 測試管理

（1）測試監(jiān)控管理

測試監(jiān)控的目的是為測試活動提供反饋信息和可視性。測試監(jiān)控的主要內(nèi)容如下：

• 測試用例執(zhí)行的進(jìn)度，只表明用例執(zhí)行的進(jìn)度，不表示測試的成功率；

• 缺陷存活時間，表明修改缺陷的效率；

• 缺陷的趨勢分析，按照測試執(zhí)行的時間順序，統(tǒng)計(jì)被發(fā)現(xiàn)的缺陷數(shù)量分布情況；

• 缺陷分布密度，需要考慮缺陷的優(yōu)先級和嚴(yán)重程度；

• 缺陷修改質(zhì)量，用于評價開發(fā)部門修復(fù)缺陷的質(zhì)量。

（2）測試工作效率與工作質(zhì)量考核

（3）測試風(fēng)險管理

在測試工作中，主要的風(fēng)險表現(xiàn)如下：

• 需求風(fēng)險。對軟件需求理解不準(zhǔn)確，導(dǎo)致測試范圍存在誤差，遺漏部分需求或執(zhí)行了錯誤的測試方式；

• 測試用例風(fēng)險。測試用例設(shè)計(jì)不完整，忽視了邊界條件、異常處理等情況，用例沒有完全覆蓋需求；測試用例沒有得到全部執(zhí)行，有些用例被有意或無意遺漏；

• 缺陷風(fēng)險。某些缺陷偶發(fā)，難以重現(xiàn)，容易被遺漏；

• 代碼質(zhì)量風(fēng)險。軟件代碼質(zhì)量差，導(dǎo)致缺陷較多，容易出現(xiàn)測試的遺漏；

• 測試環(huán)境風(fēng)險。有些情況下測試環(huán)境與生產(chǎn)環(huán)境不能完全一致，導(dǎo)致測試結(jié)果存在誤差；

• 測試技術(shù)風(fēng)險。某些項(xiàng)目存在技術(shù)難度，測試能力和水平導(dǎo)致測試進(jìn)展緩慢，項(xiàng)目延期；

• 回歸測試風(fēng)險?；貧w測試一般不運(yùn)行全部測試用例，可能存在測試不完全；

• 溝通協(xié)調(diào)風(fēng)險。測試過程中涉及的角色較多，存在不同人員、角色之間的溝通、協(xié)作，難免存在誤解、溝通不暢的情況，導(dǎo)致項(xiàng)目延期；

• 其他不可預(yù)計(jì)風(fēng)險。

5．軟件維護(hù)

軟件維護(hù)占整個軟件生命周期的60%～80%，維護(hù)的類型主要有以下4種：改正性維護(hù)、適應(yīng)性維護(hù)、完善性維護(hù)、預(yù)防性維護(hù)。

2.3面向?qū)ο蠓治雠c設(shè)計(jì)

1、基本概念

（1）對象。在計(jì)算機(jī)系統(tǒng)中，對象是指一組屬性及這組屬性上的專用操作的封裝體。一個對象通?？捎扇糠纸M成，分別是對象名、屬性和操作（方法）。

（2）類。類是一組具有相同屬性和相同操作的對象的集合。一個類通?？捎扇糠纸M成，分別是類名、屬性和操作（方法）。每個類一般都有實(shí)例，沒有實(shí)例的類是抽象類。

（3）繼承。繼承是在某個類的層次關(guān)聯(lián)中不同的類共享屬性和操作的一種機(jī)制。一個父類可以有多個子類，這些子類都是父類的特例。

（4）封裝。面向?qū)ο笙到y(tǒng)中的封裝單位是對象，對象之間只能通過接口進(jìn)行信息交流，外部不能對對象中的數(shù)據(jù)隨意地進(jìn)行訪問，這就造成了對象內(nèi)部數(shù)據(jù)結(jié)構(gòu)的不可訪問性，也使得數(shù)據(jù)被隱藏在對象中。

（5）消息。消息是對象間通信的手段、一個對象通過向另一對象發(fā)送消息來請求其服務(wù)。一個消息通常包括接收對象名、調(diào)用的操作名和適當(dāng)?shù)膮?shù)（如有必要）。

（6）多態(tài)性。多態(tài)性是指同一個操作作用于不同的對象時可以有不同的解釋，并產(chǎn)生不同的執(zhí)行結(jié)果。

2、UML

UML是一種定義良好、易于表達(dá)、功能強(qiáng)大且普遍適用的建模語言。它融入了軟件工程領(lǐng)域的新思想、新方法和新技術(shù)。它的作用域不限于支持面向?qū)ο蟮姆治雠c設(shè)計(jì)，還支持從需求分析開始的軟件開發(fā)的全過程。

UML2.0包括14種圖：

①類圖（class diagram）：描述一組類、接口、協(xié)作和它們的關(guān)系，靜態(tài)設(shè)計(jì)視圖，活動類給出了靜態(tài)進(jìn)程視圖；

②對象圖（object diagram）：描述一組對象和它們的關(guān)系，在類圖中所建立的事物實(shí)例的靜態(tài)快照；

③構(gòu)件圖（component diagram）：描述一個封裝的類和它的接口、端口以及由內(nèi)嵌的構(gòu)件和連接件構(gòu)成的內(nèi)部結(jié)構(gòu)；

④組合結(jié)構(gòu)圖（composite structure diagram）：它是類圖的變體，進(jìn)度設(shè)計(jì)實(shí)現(xiàn)視圖；

⑤用例圖（usecase diagram）：描述一組用例、參與者及它們之間的關(guān)系，在對系統(tǒng)的行為進(jìn)行組織和建模時非常重要；

⑥順序圖（sequence diagram）/序列圖：對象之間傳送消息的時間順序，是用來表示用例中的行為順序，是一種交互圖；

⑦通信圖（communication diagram）：是一種交互圖，強(qiáng)調(diào)收發(fā)消息的對象或參與者的結(jié)構(gòu)組織，也稱協(xié)作圖；

⑧定時圖（timing diagram）：也是一種交互圖，強(qiáng)調(diào)消息跨越不同對象或參與者的實(shí)際時間；

⑨狀態(tài)圖（state diagram）：描述一個狀態(tài)機(jī)，它由狀態(tài)、轉(zhuǎn)移、事件和活動組成；

⑩活動圖（activity diagram）：展示為計(jì)算機(jī)內(nèi)部一步步的控制流和數(shù)據(jù)流；

?部署圖（deployment diagram）：一種展示運(yùn)行時進(jìn)行處理的結(jié)點(diǎn)和在結(jié)點(diǎn)上生存的制品的配置圖；

?制品圖（artifact diagram）：展示了一組制品及它們之間的關(guān)系；

?包圖（package diagram）：包圖是包和包之間的關(guān)系構(gòu)成，是維護(hù)和控制系統(tǒng)總體結(jié)構(gòu)的重要建模工具，用于描述系統(tǒng)的分層結(jié)構(gòu)；

?交互概覽圖（interaction overview diagram）：活動圖和順序圖的混合物。

2.4 信息系統(tǒng)規(guī)劃

1、大型信息系統(tǒng)的特點(diǎn)

大型信息系統(tǒng)是指以信息技術(shù)和通信技術(shù)為支撐，規(guī)模龐大，分布廣闊，采用多級網(wǎng)絡(luò)結(jié)構(gòu)，跨越多個安全域，處理海量的、復(fù)雜且形式多樣的數(shù)據(jù)，提供多種類型應(yīng)用的大系統(tǒng)。特點(diǎn)包括：“兩大兩多一復(fù)雜”和跨地區(qū)。數(shù)據(jù)量和規(guī)模大、業(yè)務(wù)種類和用戶多、網(wǎng)絡(luò)結(jié)構(gòu)復(fù)雜。

2、信息系統(tǒng)規(guī)劃方法與工具

信息系統(tǒng)規(guī)劃（Information System Planning，ISP）是從企業(yè)戰(zhàn)略出發(fā)，構(gòu)建企業(yè)基本的信息系統(tǒng)架構(gòu)，對企業(yè)內(nèi)、外信息資源進(jìn)行統(tǒng)一規(guī)劃、管理與應(yīng)用，利用信息系統(tǒng)控制企業(yè)行為，輔助企業(yè)進(jìn)行決策，幫助企業(yè)實(shí)現(xiàn)戰(zhàn)略目標(biāo)。

ISP方法經(jīng)歷了三個主要階段，各個階段所使用的方法也不一樣。第一個階段主要以數(shù)據(jù)處理為核心，圍繞職能部門需求的信息系統(tǒng)規(guī)劃，主要的方法包括企業(yè)系統(tǒng)規(guī)劃法、關(guān)鍵成功因素法和戰(zhàn)略集合轉(zhuǎn)化法；第二個階段主要以企業(yè)內(nèi)部管理信息系統(tǒng)為核心，圍繞企業(yè)整體需求進(jìn)行的信息系統(tǒng)規(guī)劃，主要的方法包括戰(zhàn)略數(shù)據(jù)規(guī)劃法、信息工程法和戰(zhàn)略柵格法；第三個階段在綜合考慮企業(yè)內(nèi)外環(huán)境的情況下，以集成為核心，圍繞企業(yè)戰(zhàn)略需求進(jìn)行的信息系統(tǒng)規(guī)劃，主要的方法包括價值鏈分析法和戰(zhàn)略一致性模型。

企業(yè)系統(tǒng)規(guī)劃（Business System Planning，BSP）方法是IBM公司于20世紀(jì)70年代提出的一種方法，主要用于大型信息系統(tǒng)的開發(fā)。對大型信息系統(tǒng)而言，BSP采取的是自上而下的系統(tǒng)規(guī)劃，而實(shí)現(xiàn)是自下而上分步進(jìn)行。BSP方法是通過全面調(diào)查，分析企業(yè)信息需求，制定信息系統(tǒng)總體方案的一種方法。

其活動步驟為：項(xiàng)目確定后→開始準(zhǔn)備工作→定義企業(yè)過程→識別定義數(shù)據(jù)類→分析現(xiàn)有系統(tǒng)→確定管理部門對系統(tǒng)的要求→提出判斷和結(jié)論→（定義企業(yè)信息系統(tǒng)總體結(jié)構(gòu)→確定優(yōu)先順序）或評價信息資源管理工作→制定建議書和開發(fā)計(jì)劃→最后形成成果報(bào)告。

信息系統(tǒng)規(guī)劃工具：①為把企業(yè)組織結(jié)構(gòu)與企業(yè)過程聯(lián)系起來，可以采用過程/組織（Process/Organization，P/O）矩陣；

②為定義數(shù)據(jù)類，在調(diào)查研究和訪談的基礎(chǔ)上，可以采用實(shí)體法歸納出數(shù)據(jù)類。 實(shí)體法首先列出企業(yè)資源，再列出一個資源/數(shù)據(jù)（Resource/Data，R/D）矩陣；

③功能法也稱過程法可以用IPO（輸入-處理-輸出）圖表示；

④按照企業(yè)過程生成數(shù)據(jù)類關(guān)系填寫C（Create），使用數(shù)據(jù)類關(guān)系填寫U（User），形成U/C矩陣。

2.5 過程管理

CMMI分階段式和連續(xù)式，它們采用相同的24個過程域，邏輯上等價。注：CMMI1.2一共24個過程域，CMMI1.3一共22個過程域。

①CMMI階段式分組（側(cè)重組織的成熟度）

②CMMI連續(xù)式分組（側(cè)重組織的過程能力）

3章節(jié)問答

1、數(shù)據(jù)、信息及知識三者的概念與區(qū)別是什么？

答：數(shù)據(jù)是最基本的單位，是未經(jīng)組織的數(shù)字、詞語、聲音、圖像等；信息是以有意義的形式加以排列和處理的數(shù)據(jù)（有意義的數(shù)據(jù)）；知識是用于生產(chǎn)的信息（有意義的信息）。信息經(jīng)過加工處理、應(yīng)用于生產(chǎn)，才能轉(zhuǎn)變成知識。

2、結(jié)構(gòu)化開發(fā)方法、原型法與面向?qū)ο箝_發(fā)之間的優(yōu)缺點(diǎn)：

答：

（1）結(jié)構(gòu)化開發(fā)方法是一種面向數(shù)據(jù)流的開發(fā)方法，其基本思想是軟件功能的分解和抽象。結(jié)構(gòu)化系統(tǒng)開發(fā)方法（亦稱“生命周期法”）其優(yōu)點(diǎn)是：從系統(tǒng)整體出發(fā)，強(qiáng)調(diào)在整體優(yōu)化的條件下“自上而下”地分析和設(shè)計(jì)，保證了系統(tǒng)的整體性和目標(biāo)的一致性；遵循用戶至上原則；嚴(yán)格區(qū)分系統(tǒng)開發(fā)的階段性；每一階段的工作成果是下一階段的依據(jù)，便于系統(tǒng)開發(fā)的管理和控制；文檔規(guī)范化，按工程標(biāo)準(zhǔn)建立標(biāo)準(zhǔn)化的文檔資料。缺點(diǎn)：用戶素質(zhì)或系統(tǒng)分析員和管理者之間的溝通問題；開發(fā)周期長，難以適應(yīng)環(huán)境變化；結(jié)構(gòu)化程度較低的系統(tǒng)，在開發(fā)初期難以鎖定功能要求。

（2）原型法其優(yōu)點(diǎn)：符合人們認(rèn)識事物的規(guī)律，系統(tǒng)開發(fā)循序漸進(jìn)，反復(fù)修改，確保較好的用戶滿意度；開發(fā)周期短，費(fèi)用相對少；由于有用戶的直接參與，系統(tǒng)更加貼近實(shí)際；易學(xué)易用，減少用戶的培訓(xùn)時間；應(yīng)變能力強(qiáng)。缺點(diǎn)：不適合大規(guī)模系統(tǒng)的開發(fā)；開發(fā)過程管理要求高，整個開發(fā)過程要經(jīng)過“試用—反饋—修改”的多次反復(fù)；開發(fā)人員易將原型取代系統(tǒng)分析；缺乏規(guī)范化的文檔資料。

（3）面向?qū)ο箝_發(fā)方法其優(yōu)點(diǎn)是：分析、設(shè)計(jì)中的對象和軟件中的對象的一致性；實(shí)現(xiàn)軟件復(fù)用，簡化程序設(shè)計(jì)；系統(tǒng)易于維護(hù)；縮短開發(fā)周期。缺點(diǎn)：不易于大系統(tǒng)的開發(fā)。

（4）結(jié)構(gòu)化分析是面向數(shù)據(jù)流進(jìn)行需求分析的方法，在該階段力求尋找功能及功能之間的說明，它主要采用的工具是數(shù)據(jù)流圖DFD，利用DFD描述邊界和數(shù)據(jù)處理過程的關(guān)系。面向?qū)ο蠓椒ㄊ菑膬?nèi)部結(jié)構(gòu)上模擬客觀世界，其基本思想為：對象是對現(xiàn)實(shí)世界客觀實(shí)體的描述，均由其屬性和相關(guān)操作組成，是系統(tǒng)描述的基本單位。面向?qū)ο蠓治鲭A段是通過行為分析法認(rèn)定對象及它們之間的關(guān)系。

3、什么是需求跟蹤？其作用是？

答：

（1）需求跟蹤是指跟蹤一個需求使用期限的全過程，需求跟蹤包括編制每個需求同系統(tǒng)元素之間的聯(lián)系文檔，這些元素包括其他類型的需求、體系結(jié)構(gòu)，其他設(shè)計(jì)部件、源代碼模塊、測試、幫助文件等。需求跟蹤為我們提供了由需求到產(chǎn)品實(shí)現(xiàn)整個過程范圍的明確查閱的能力。

（2）需求跟蹤的目的是建立與維護(hù)“需求－設(shè)計(jì)－編程－測試”之間的一致性，確保所有的工作成果符合用戶需求。

（3）需求跟蹤有兩種方式：

正向跟蹤：檢查《產(chǎn)品需求規(guī)格說明書》中的每個需求是否都能在后繼工作成果中找到對應(yīng)點(diǎn)。

逆向跟蹤：檢查設(shè)計(jì)文檔、代碼、測試用例等工作成果是否都能在《產(chǎn)品需求規(guī)格說明書》中找到出處。

（4）正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護(hù)需求跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與后繼工作成果的對應(yīng)關(guān)系。

4、什么是SRS？它有哪些特點(diǎn)？應(yīng)該由誰來編寫SRS？

答：

（1）SRS（Software Requirements Specification）是軟件需求規(guī)格說明書的縮寫。SRS代表用戶和開發(fā)人員對軟件系統(tǒng)的共同理解，是軟件項(xiàng)目后期開發(fā)和維護(hù)的基礎(chǔ)，它不僅是系統(tǒng)測試和用戶文檔的基礎(chǔ)，也是所有子系列項(xiàng)目規(guī)劃、設(shè)計(jì)和編碼的基礎(chǔ)。SRS詳細(xì)記錄了用戶對軟件的功能需求和非功能需求。

（2）SRS的特點(diǎn)有：無歧義性；完整性；可驗(yàn)證性；一致性；可修改性；可追蹤性。

（3）SRS應(yīng)由開發(fā)者和客戶雙方聯(lián)合起草。SRS中每一個軟件需求是要求開發(fā)軟件產(chǎn)品的某些功能和性能的一個陳述。

5、什么是UML？UML模型圖的構(gòu)成？各UML圖及特征？

答：

（1）UML（Unified Modeling Language）為面向?qū)ο筌浖O(shè)計(jì)提供統(tǒng)一的、標(biāo)準(zhǔn)的、可視化的建模語言。適用于描述以用例為驅(qū)動，以體系結(jié)構(gòu)為中心的軟件設(shè)計(jì)的全過程。

（2）UML模型圖的構(gòu)成包括：

①事物（Things）：UML模型中最基本的構(gòu)成元素，是具有代表性的成分的抽象。

②關(guān)系（Relationships）：關(guān)系把事物緊密聯(lián)系在一起。

③圖（Diagrams）：圖是事物和關(guān)系的可視化表示。

6、面向?qū)ο蠓治鲋饕捎美Ｐ秃头治瞿Ｐ头謩e介紹了用例之間的關(guān)系和類之間的關(guān)系有哪些？

答：用例之間的關(guān)系：包含關(guān)系、擴(kuò)展關(guān)系、泛化關(guān)系；

類之間的關(guān)系：關(guān)聯(lián)關(guān)系、依賴關(guān)系、泛化關(guān)系、聚合關(guān)系、組合關(guān)系和實(shí)現(xiàn)關(guān)系。