第一篇：旅游商品購物系統(tǒng)的分析與設計作業(yè)

旅游商品購物系統(tǒng)的分析與設計

2.2 現(xiàn)有旅游商品購物網(wǎng)站分析

目前我國旅游商品購物的網(wǎng)絡化、信息化仍處于起步階段，相關的專業(yè)網(wǎng)站并不是很多。國內目前主要的旅游商品網(wǎng)站多以地方來區(qū)分，如中國旅游商品網(wǎng)、貴州旅游商品網(wǎng)、海南旅游商品網(wǎng)等。

選取某一典型網(wǎng)站進行以下內容分析：（作業(yè)1）

因為中國旅游商品網(wǎng)更加具有代表性，因此選取中國旅游商品網(wǎng)作為典型網(wǎng)站進行分析：

? 網(wǎng)站主要功能

（1）搜索功能：在網(wǎng)站首頁就有按分類的模糊搜索，同時也附有高級搜索，對于目標明確或目標不甚明確的客戶都有幫助。

（2）論壇功能：對于買家賣家都有一個評論的地方，可以給游客一些指導

性意見，也能讓賣家在論壇上更好的推廣產(chǎn)品。

（3）站內公告：在首頁的站內公告上，發(fā)布一些旅游景點的熱門消息，給

前來網(wǎng)站的游客一些關于旅游景點的貼心信息。比如，最新公告：“安徽省鄉(xiāng)村環(huán)境優(yōu)美 有助于旅游業(yè)發(fā)展”，這樣的信息首先會讓顧客對安徽有個不錯的印象，會促使他去瀏覽關于安徽的產(chǎn)品，從而促進商品買賣及推動安徽的旅游業(yè)發(fā)展。

（4）產(chǎn)品宣傳功能：在網(wǎng)站首頁上，有“特推產(chǎn)品”“經(jīng)典收藏”的鏈接，里面都是熱門商品的目錄，（5）客服功能：客服中內容分為買家，賣家兩塊區(qū)域，符合一般購物網(wǎng)站的分類方式?？头行脑O有：注冊認證、我是賣家、我是賣家、支付方式、舉報投訴、相關規(guī)則及聯(lián)系客服各列，為有所需求的顧客提供了人性化的便利。

（6）服務支付功能：提供最后的支付平臺，是購物網(wǎng)站的基礎。

（7）商品展示功能：點擊商品，進入商品展示頁面，有商品的簡介及相冊

可供參考。

? 系統(tǒng)優(yōu)點

（1）有英語導航，因為中國很多旅游景點都是以中國歷史文化等為噱頭，因此，中國的特色產(chǎn)品，對于外國游客有著更多的吸引力，而他們來

中國旅游更是困難，因此，旅游商品網(wǎng)站的英文版是將中國旅游產(chǎn)品

業(yè)推向全球。

（2）關聯(lián)展示：相似的產(chǎn)品和輔助產(chǎn)品推薦，給顧客更多的選擇。? 系統(tǒng)缺點

（1）商品展示不夠，僅有商品產(chǎn)地、商品數(shù)量及瀏覽量，對于商品的更多說明不夠詳細，頁面雖然簡潔大方，但是以藍色調為主，讓人缺少購買欲望。、（2）地區(qū)加盟站目前僅有4個區(qū)域，與所列的34個地區(qū)相比略顯單薄，應加強對此的工作，才不枉“中國旅游商品網(wǎng)”的名號。

（3）許多鏈接還不完善，如論壇、供求等，點入是無法找到該頁，讓游客對此網(wǎng)站失去信心。

（4）鏈接過于不明了，如果想要找到一些關于企業(yè)的訊息，需要點入“我的商務室”才能找到，對于首次登陸的游客而言，過于隱秘，而且對于網(wǎng)站的布局也不清楚。

（5）部分產(chǎn)品缺貨，易引起顧客對于網(wǎng)站的不信任。

2.3 擬開發(fā)旅游商品購物系統(tǒng)的定位與功能

1、系統(tǒng)的定位與特點

本系統(tǒng)是為了滿足廣大個人旅游消費者對于足不出戶購買到上海及周邊地區(qū)旅游商品所設計的網(wǎng)上超市式的旅游商品購物系統(tǒng)，同時以上海地區(qū)旅游信息介紹為特色功能，輔以有關上海旅游的文章和新聞，幫助用戶對有關上海旅游商品的方方面面有所了解，體現(xiàn)系統(tǒng)定位在上海旅游商品的特點。

本旅游商品購物系統(tǒng)與其他已有的旅游商品網(wǎng)站的區(qū)別有：（作業(yè)2）

（1）本旅游商品購物系統(tǒng)僅針對于上海的旅游景點及商品搭建平臺。并選擇適合自己的旅游路線。

（2）除了旅游商品之外，還提供與各旅游景點合作，提供訂票服務。

（3）對于上海知名旅游景點有專門的網(wǎng)頁做鏈接，并且信息介紹，讓顧客更

加了解上海，不僅對于商品有圖片展示，對于旅游景點也提供較多的圖片。

（4）價格宣傳區(qū)：定期有特價、促銷活動，并且也有類似于一元秒殺區(qū)，以提高網(wǎng)站知名度及游客點擊率。

（5）對于訂票和商品購買，都有團購優(yōu)惠。

2、系統(tǒng)功能規(guī)劃（作業(yè)3：根據(jù)相關提示給出具體功能的簡要說明）

前臺子系統(tǒng)：主要為客戶進行相關服務。包括上海旅游商品信息、會員信息管理、旅游商品選購、購物車管理、查看訂單、旅游商品文化、旅游商品世界等。后臺子系統(tǒng)：專門為系統(tǒng)管理員設計，以方便其對旅游商品日常交易情況、客戶注冊情況、系統(tǒng)運行情況、訂單處理情況等進行實時管理，來保證整個系統(tǒng)的健康運行。主要包括管理員登錄、旅游商品管理、訂單管理等。

前臺子系統(tǒng)：主要為客戶進行相關服務。

上海旅游商品信息管理：對上海知名旅游景點做信息簡介，并有大量的圖片展示，并提供旅游推薦路線多條，以供游客選擇。如網(wǎng)站上有實體店鋪，將公布實體店的具體方位、公交線路、聯(lián)系方式。

會員信息管理：會員將分為買家和賣家兩類。買家主要信息管理包括聯(lián)系方式、配送地址、買賣歷史信息等，賣家信息包括實體店地址、真實姓名、實體店營業(yè)執(zhí)照、店鋪地址及店鋪信息以及物流。

購物車管理：買家可以一次性購買多件商品，放入購物車同時支付款項。查看訂單：買家可以查詢賣家是否已經(jīng)發(fā)貨，如果有條件可以查詢目前訂單所處的位置，還有多久能夠到達。賣家可以查詢買家是否已下訂單，及支付情況。

后臺子系統(tǒng)：專門為系統(tǒng)管理員設計，以方便其對旅游商品日常交易情況、客戶注冊情況、系統(tǒng)運行情況、訂單處理情況等進行實時管理，來保證整個系統(tǒng)的健康運行。

三、旅游商品購物系統(tǒng)分析

3.1 市場需求分析（略）

3.2 系統(tǒng)需求分析

1、系統(tǒng)功能需求分析（作業(yè)4：補充完整相應各需求分析內容）使用用例分析的方法，按照系統(tǒng)前臺，系統(tǒng)后臺進行用例分析。

2、系統(tǒng)性能需求分析

3、系統(tǒng)可靠性需求分析

4、系統(tǒng)可管理性需求分析

5、系統(tǒng)靈活性需求分析

6、差錯處理需求分析

第二篇：網(wǎng)上購物系統(tǒng)系統(tǒng)分析

一、系統(tǒng)流程分析

(1)普通用戶分為注冊會員用戶和非會員用戶。進入網(wǎng)站首頁，會員用戶登錄成功后具有查看商品信息并訂購商品、查看訂購信息、查看公告信息、修改個人信息等權限；非會員用戶不用登錄，只能查看商品信息、公告信息，不能訂購商品．只有注冊成為會員用戶并成功登錄后。方可訂購商品。

(2)部門管理員只可以對本部門銷售的商品的分類、商品品牌和商品信息進行管理，也可對自己的個人信息進行管理維護。

(3)總管理員可以對商城銷售的商品大類、各部門的管理員、公告信息和客戶訂單進行管理．并可以修改個人信息和密碼。

圖1-1 系統(tǒng)流程示意圖

二、系統(tǒng)數(shù)據(jù)庫設計

本系統(tǒng)客觀存在的實體有：管理員(gly)、注冊會員用戶user)、商品種類(spzl)、商品子類(splx)、商品品牌(ppxx)、商品(sp)、商城公告(board)。共7個實體，圖2-1 網(wǎng)上購物全局E-R圖

三、邏輯結構設計

管理員：包括管理員編號、注冊名、密碼、真實姓名、地址、電話、E-mail、其他。當管理員編號為“0000”時，代表系統(tǒng)總管理員，其他編號為對應的部門管理員。注冊會員用戶信息：包括用戶ID、姓名、密碼、性別、地址、手 機號、電話、E—mail。

商品種類：包括商品種類編號，商品種類名稱。每一個商品種類可以有多個商品子類。商品子類：包括子類編號、子類名稱、指標名稱I、指標名稱

2、指標名稱

3、指標名稱

4、指標名稱5。5個指標名稱中分別存

放每一子類商品的5個主要的指標名稱。

商品品牌：包括品牌編號、品牌名稱、品牌生產(chǎn)商、業(yè)務聯(lián)系 信息。

商品：包括商品編號、商品名稱、商品型號、商品指標值

1、商品指標值

2、商品指標值3，商品指標值

4、商品指標值

5、參考銷售單價、上市日期、圖片、簡介。5個商品指標值巾分別存放各商品的具體指標參數(shù)值。

商城公告信息：包括公告編號、公告標題、公告內容、發(fā)布時閱。

商品銷售信息：包括訂單編號、用戶編號、商品種類編號、商品分類編號、商品品牌編號、商品編號、訂購日期、訂購數(shù)量、實際銷售價、用戶確認、發(fā)貨日期、管理員確認。

四、數(shù)據(jù)庫邏輯結構設計

1．公告信息表（題目，內容，時間，編號，提交人）

2．商品類別表（編號，類別，名稱，序號，廠家，包裝類型，銷售價格，進貨價格，商品簡介，瀏覽次數(shù)，銷售數(shù)量，相關圖片）

3．購物車表（編號，用戶名，商品編號，訂購時間，訂購數(shù)量，銷售價格，用戶確認，訂單號，提交時間，管理員確認）

4．用戶投訴表（投訴編號，投訴時間，用戶名，訂單號，投訴內容，處理結果，處理標志）5．用戶信息表（用戶名，用戶密碼，用戶姓名，性別，地址，電子郵件地址，固定電話，移動電話）

6．管理員表（用戶名，密碼，用戶姓名）

五、模塊功能設計

（1）顧客注冊，登錄模塊

顧客可以通過填寫注冊信息注冊成為會員，會員注冊，登錄需要填寫附加碼，保證 系統(tǒng)的安全性。會員登錄后才能進行購物，購物車的管理與意見反饋，為登錄的會員或 未注冊的顧客只能檢索與瀏覽商品信息。(2)購物車模塊

顧客輸入帳號與密碼登錄后便可以進行購物車的管理，可以查看購物車，將商品添 加到購物車中，也可以刪除購物車中的商品，修改購物車中商品的數(shù)量，在線下訂單及 訂單查看。

(3)商品檢索，瀏覽模塊，特價商品檢索，瀏覽模塊

顧客可以根據(jù)不同的商品種類瀏覽商品信息(如商品名稱，商品圖片，商品型號，價格，生產(chǎn)廠商，生產(chǎn)日期等)，也可以輸入關鍵字進行商品檢索。顧客可以根據(jù)不同 的商品種類瀏覽特價商品信息(如商品名稱，商品圖片，商品型號，價格，生產(chǎn)廠商，生產(chǎn)日期等)，也可以輸入關鍵字進行特價商品檢索。(4)顧客留言模塊

顧客登錄成功后，進入反饋信息界面，可以發(fā)表自己的意見或建議。(5)后臺登錄模塊

系統(tǒng)管理員輸入帳號，密碼和附加碼可以登錄后臺界面，登錄驗證模塊根據(jù)輸入的 帳號密碼識別不同角色的管理員，然后進入不同的后臺管理模塊，賬號密碼輸入錯誤后 給出錯誤提示并要求從新輸入。(6)訂單管理模塊

訂單管理員登錄后，可以根據(jù)日期范圍，訂單完成狀態(tài)，訂單編號等取得訂單列表 與查看某訂單的詳情，也可以修改訂單的完成狀態(tài)及訂單中的商品或數(shù)量，還可以刪除 訂單本身及訂單中的商品。(7)商品管理模塊

商品管理員可以查看商品種類和商品信息，也可以新增，修改，刪除商品的種類和 商品本身。

(8)特價商品管理模塊

該模塊也和商品管理模塊一樣，商品管理員可以查看特價商品種類和信息，也可以 新增，修改，刪除商品的種類和特價商品本身，并且可以將商品列為特價商品以及將特 價商品修改為一般商品(9)會員管理模塊

會員管理員登錄后，可以根據(jù)注冊時間范圍，會員級別及會員D取得會員列表，然后對某個會員可以進行詳細資料的查看，級別調整與刪除操作；也可以根據(jù)留言時間 范圍，回復狀態(tài)及會員D取得留言列表，然后對某個留言進行內容查看，回復與刪除 操作。

(10)系統(tǒng)用戶管理模塊

系統(tǒng)管理員登錄后，可以根據(jù)用戶列表進行用戶詳細資料的查看，新增用戶，修改 用戶與刪除用戶操作。論文

1． 網(wǎng)上購物系統(tǒng)的開發(fā)背景+可行性分析（經(jīng)濟，技術）2． 系統(tǒng)需求

3． 系統(tǒng)設計+系統(tǒng)分析、實現(xiàn) 4． 系統(tǒng)工作流程 5．

第三篇：信息系統(tǒng)分析、設計與管理作業(yè)答案

1、簡述信息系統(tǒng)的組成市場營銷 賴政恒 201040700090

答：信息系統(tǒng)由以下七大部分組成：

1.計算機硬件系統(tǒng)

2.計算機軟件系統(tǒng)

3.數(shù)據(jù)及基存儲介質

4.通信與計算機網(wǎng)絡設施

5.非計算機系統(tǒng)的信息收集和處理設備

6.規(guī)章制度

7.工作人員

2、信息系統(tǒng)在組織管理中的主要作用和組織對信息系統(tǒng)的影響

答：主要作用體現(xiàn)在以下方面：

1.以信息技術為基礎的信息系統(tǒng)極大地提高了信息收集、傳遞與處理的效率和有效性，可為客戶、企業(yè)員工、經(jīng)營管理者、合作伙伴和企業(yè)的其他利益相關者提供良好的信息服務，從而增強企業(yè)對內外環(huán)境變化響應的敏捷性和靈活性，提高了管理決策的及時性和科學性，是實現(xiàn)企業(yè)目標與戰(zhàn)略的重要保證。

2.市場上圍繞產(chǎn)品與服務的企業(yè)競爭，實質上是形成這類產(chǎn)品與服務的供應鏈之間的競爭。

3.減少管理層次，下放權力，實現(xiàn)組織扁平化、網(wǎng)絡化、虛擬化，是企業(yè)改革的重要任務之一。

4.業(yè)務流程是企業(yè)在完成其使命、實現(xiàn)其目標過程中必需的，邏輯上相關的一組活動。

5.信息系統(tǒng)實現(xiàn)了對企業(yè)生產(chǎn)經(jīng)營信息的及時、統(tǒng)一管理，加強了企業(yè)控制能力，提高了信息處理的效率，從而降低了內部人員成本。

6.信息系統(tǒng)加強了業(yè)務、流程和數(shù)據(jù)的規(guī)范化，減少了隨意性和人為失誤，改善了管理者與員工的工作環(huán)境與學習條件，促進了員工之間的信息知識交流與協(xié)作，加強了組織的凝聚力，有利于形成具有本企業(yè)特色的團結、學習、創(chuàng)新的企業(yè)文化。

組織對信息系統(tǒng)的影響：信息系統(tǒng)是整個組織中的一部分，信息系統(tǒng)的使命、目標和運作機制與組織一致，才能發(fā)揮信息系統(tǒng)在組織中的應有作用。組織的目標、戰(zhàn)略、規(guī)模、結構、管理模式、運作機制、改革和發(fā)展進程以及人員素質、組織文化對信息系統(tǒng)的建立和應用都有重要的影響。

3、試述信息系統(tǒng)生命周期的階段劃分和各階段的主要活動

答：信息系統(tǒng)的生命周期可以分成四個階段：

1.系統(tǒng)規(guī)劃

2.系統(tǒng)開發(fā)

3.系統(tǒng)運營與維護

4.系統(tǒng)更新

各階段的主要活動有：

1、系統(tǒng)規(guī)劃：根據(jù)組織的整體目標和變革與發(fā)展戰(zhàn)略，確定信息系統(tǒng)的發(fā)展戰(zhàn)略，制定系統(tǒng)的數(shù)據(jù)規(guī)劃、應用系統(tǒng)規(guī)劃與技術基礎設施規(guī)劃。

2、系統(tǒng)開發(fā)：根據(jù)系統(tǒng)規(guī)劃階段確定的系統(tǒng)總體方案和開發(fā)項目的安排，分期、分批進行系統(tǒng)開發(fā)，這是系統(tǒng)建設中工作任務最為繁重的階段。

3、系統(tǒng)運營與維護：系統(tǒng)運營的組織與管理、信息服務提供管理、信息服務支持管理、系統(tǒng)維護、信息安全管理。

4、系統(tǒng)更新：現(xiàn)行系統(tǒng)問題分析、新系統(tǒng)的建設。

4、試述信息系統(tǒng)規(guī)劃的目標與任務

答：信息規(guī)劃的目標是：根據(jù)組織的目標與戰(zhàn)略制定出組織中信息系統(tǒng)建設的長期發(fā)展方案，決定信息系統(tǒng)在整個生命周期內的發(fā)展方向、規(guī)模和發(fā)展過程。

信息系統(tǒng)規(guī)劃的任務是：

1、需求分析：識別系統(tǒng)的各類用戶在他們的社會活動中需要系統(tǒng)為他們解決的問題、提供的服務。

2、業(yè)務規(guī)劃：根據(jù)組織的目標與戰(zhàn)略和用戶需求，制定業(yè)務規(guī)劃和業(yè)務流程改革與創(chuàng)新方案。

3、數(shù)據(jù)規(guī)劃：識別系統(tǒng)的主題數(shù)據(jù)，進行應用系統(tǒng)規(guī)劃。

4、應用系統(tǒng)規(guī)劃：確定系統(tǒng)的信息處理功能，進行應用系統(tǒng)規(guī)劃。

5、技術基礎設施規(guī)劃：確定保障信息系統(tǒng)正常、高效、安全運行的軟、硬件與網(wǎng)絡基礎設施，進行技術基礎設施規(guī)劃。

5、試述可行性研究的主要內容、工作步驟和可行性研究報告的主要內容

答：主要內容：進一步明確系統(tǒng)的目標、規(guī)模與功能、對系統(tǒng)開發(fā)背景、必要性和意義進行調查分析，并根據(jù)需要和可能提出擬開發(fā)系統(tǒng)的初步方案和計劃。

工作步驟：

1.確定系統(tǒng)的規(guī)模與目標

2.明確用戶主要作息要求

3.提出擬建系統(tǒng)初步方案

4.審查新系統(tǒng)

5.提出并評價可能的替代方案，并進行可行性研究（技術可行性、經(jīng)濟可行性、營運可行性），這里可行性研究要涉及物理方案，既解決問題的可能途徑，如軟、硬件的配置。

6.給出該項目做還是不做的選擇，同時確定方案。

7.制定項目開發(fā)計劃，包括人、財、物的安排。

8.撰寫可行性研究報告。

9.向用戶審查小組與指導委員會提交結果。

可行性研究報告的主要內容：

1.現(xiàn)行系統(tǒng)概況：包括組織結構、主要工作、任務和業(yè)務流程、人員、設備、費用狀況。

2.主要問題和主要信息需求

3.擬建新系統(tǒng)的方案：包括主要目標、規(guī)模、初步結構、實施計劃與投資方案、人員補充方案等。

4.經(jīng)濟可行性分析：包括建設費用、運行費用、經(jīng)濟效益及社會效益

5.技術可行性分析：包括現(xiàn)有可用技術的評估、使用現(xiàn)有技術開發(fā)系統(tǒng)的可行性、對技術發(fā)展可能產(chǎn)生的影響。

6.營運可行性分析：系統(tǒng)與組織目標、運行機制的匹配關系，各部門工作與系統(tǒng)運行的適應性、人員的適應性，人員計劃的可行性、環(huán)境條件的可行性。

7.結論：對可行性研究結果的簡要總結。

6、試述系統(tǒng)總體結構設計的內容

答：系統(tǒng)總體設計又稱系統(tǒng)總體結構設計或總體技術設計，是在預定的開發(fā)項目范圍內從總體上對組成系統(tǒng)的計算機各種硬件、各類軟件、數(shù)據(jù)存儲和網(wǎng)絡的結構進行技術設計。

7、試述信息系統(tǒng)開發(fā)項目管理的特征與工作階段的劃分

答：項目管理的特征：

1.項目管理的對象是項目

2.系統(tǒng)工程思想貫穿項目管理的全過程

3.項目管理的組織具有一定的特殊性

4.項目管理的體制是基于團隊管理的個人負責制，項目經(jīng)理是整個團隊中協(xié)調、控制的關鍵崗位。

5.項目管理的要點是創(chuàng)造和保持一個使項目順利進行的環(huán)境，使置身開這個環(huán)境的人們能在集體中協(xié)調工作以完成預定的目標。

6.項目管理的方法、工具和技術手段具有先進性。

工作階段的劃分：

一 立項與可行性研究階段

1.初步調查 2.可行性研究

二、項目實施管理階段

1.開發(fā)管理：制定文檔、預計需要的資源、費用估算、安排工作任務和日程、定期做評審質量保證管理、開發(fā)總結報告、處理意外情況等。

2.測試管理：制定測試計劃、測試分析報告、編制用戶手冊。

3.安裝與試運行管理：設備安裝、數(shù)據(jù)錄入、人員培訓與崗位設置、系統(tǒng)轉換和試運行計劃與實施以及系統(tǒng)交付管理。

4.項目后評價管理：技術水平與先進性評價、經(jīng)濟與社會效益分析、系統(tǒng)的內在質量評價、系統(tǒng)的推廣使用價值評價、系統(tǒng)的不足之處與改進意見等。

市場營銷 賴政恒 201040700090

第四篇：軟件系統(tǒng)分析與設計

第1章

軟件工程基礎知識 1.1軟件工程知識體系

? 軟件需求（Software Requirements）? 軟件設計（Software Design）

? 軟件構造（Software Construction）? 軟件測試（Software Testing）? 軟件維護（Software Maintenance）

? 軟件配置管理（Software Configuration Management）? 軟件工程管理（Software Engineering Management）? 軟件工程過程（Software Engineering Process）

? 軟件工程工具和方法（Software Engineering Tools and Methods）? 軟件質量（Software Quality）

1.2軟件生存周期與軟件開發(fā)模型

? 1.2.1 軟件生存周期

? Boehm定義的軟件生存周期模型

? GB 8566-1988定義的軟件生存周期模型

? GB/T 8566-1995定義的軟件生存周期過程模型 ? GB/T 8566-2001定義的軟件生存周期過程模型 ? UP定義的軟件生存周期模型

? 1.2.2 軟件開發(fā)模型

? 瀑布模型（waterfall model）

? 快速原型模型（rapid prototype model）? 演化模型（evolutionary model）? 增量模型（incremental model）? 螺旋模型（spiral model）

? 噴泉模型（water fountain model）

1.3軟件質量模型與軟件質量管理

? 1.3.1 軟件質量模型

? 軟件產(chǎn)品的內部質量、外部質量和使用質量 ? 質量特性、質量子特性和度量

? 功能性：適宜性、準確性、互用性、依從性、安全性 ? 可靠性：成熟性、容錯性、可恢復性 ? 可用性：可理解性、易學性、可操作性 ? 效率：時間特性、資源特性

? 可維護性：可分析性、可修改性、穩(wěn)定性、可測試性 ? 可移植性：適應性、易安裝性、一致性、可替換性

? 1.3.2 軟件質量管理

? 質量需求分析 ? 質量計劃 ? 質量保證 ? 質量控制 ? 質量改進

? 軟件質量管理體系

? ? ? ? ? ? ? ? ? ?

? ?

? ? ? ? ? ? ? ? ? ? ? ? ?

? ? ?

1.4軟件配置管理

? 1.4.1 軟件配置項與基線

計算機軟件配置項（CSCI）基線（baseline）

功能基線（functional baseline）指派基線（allocated baseline）產(chǎn)品基線（product baseline）

? 1.4.2 軟件配置管理過程

對象標識 版本控制 變化控制 配置審計 配置報告

1.5軟件過程管理

? 1.5.1 軟件能力成熟度模型（CMM）

CMM的5個等級：初始級、可重復級、已定義級、已管理級、優(yōu)化級 CMM的關鍵過程域（KPA）：需求管理、軟件項目計劃、軟件項目跟蹤和監(jiān)控、軟件子合同管理、軟件質量保證、軟件配置管理、組織級過程焦點、組織級過程定義、培訓大綱、集成軟件管理、軟件產(chǎn)品工程、組間協(xié)調、同行評審、定量過程管理、軟件質量管理、缺陷預防、技術變更管理、過程變更管理

? 1.5.2 軟件過程與軟件能力成熟度評估

第一步，建立評估組 第二步，填寫提問單 第三步，響應分析 第四步，現(xiàn)場考察

第五步，提出調查發(fā)現(xiàn)清單

第六步，制作關鍵過程域（KPA）剖面圖

? 1.5.3 軟件過程改進

第一步，比較“目標狀態(tài)”與“目前狀態(tài)”，找出所有差距 第二步，確定改進目標 第三步，制定改進計劃 第四步，執(zhí)行改進計劃

第五步，總結本輪改進經(jīng)驗，開始下一輪改進

1.6

小節(jié)

軟件工程學是研究如何有效地組織和管理軟件開發(fā)的工程學科。

軟件產(chǎn)品所要經(jīng)歷的計劃、分析、設計、編程、測試、維護直至被淘汰這樣一個全過程被稱為軟件生存周期。用不同的方式將軟件生命周期中的所有開發(fā)活動組織起來，可以形成不同的軟件開發(fā)模型。

軟件質量就是軟件與明確地和隱含地定義的需求相一致的程度。軟件質量管理是指軟件開發(fā)機構為保證軟件項目滿足客戶需求所要實施的質量活動。軟件配置管理是在軟件的整個生命期內管理變化的一組活動，目標是使變化更正確且更容易被適應。

軟件過程是指人們用于開發(fā)和維護軟件及其相關產(chǎn)品的一系列活動，包括軟件工程過程和軟件管理過程。軟件過程管理的目的就是提升軟件組織的提高軟件開發(fā)能力。

? 1.? 1.? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

第2章

項目管理基礎知識 2.1項目與項目管理 ? 2.1.1 項目

項目是在特定條件下、具有特定目標的一次性任務，是在一定時間內、滿足一系列特定目標的多項相關工作的總和。項目的臨時性 項目的獨特性 項目的漸進性

2.1.2 項目管理

項目管理就是將各種知識、技能、工具和技術應用于項目之中，以達到項目的要求。項目范圍 項目時間 項目成本 項目質量

2.2項目管理過程與過程組 ? 2.2.1 過程與過程組

過程就是一組為了完成一系列事先指定的產(chǎn)品、服務或成果而需執(zhí)行的互相聯(lián)系的行動和活動。軟件項目管理過程可歸納為五個過程組。啟動過程組（initiating process group）規(guī)劃過程組（planning process group）實施過程組（executing process group）

監(jiān)控過程組（monitoring and controlling process group）收尾過程組（closing process group）

? 2.2.2 項目管理過程的交互作用

項目管理過程并不是互不相干的一次性事件

項目管理過程組之間是一種前后銜接、承前啟后的關系

項目管理過程組之間有時又是一種時間交錯、空間并行的關系 項目管理過程組之間還是一種信息收集、存儲、處理和傳遞的關系 某些過程組的關聯(lián)具有重復迭代性

規(guī)劃過程組、執(zhí)行過程組和監(jiān)控過程組之間形成一種閉環(huán)的關系 過程組的交互作用往往還會跨越項目階段 項目階段和過程之間有相互聯(lián)系

? 2.2.3 項目管理過程的裁剪

不同類型的軟件項目應選用不同的項目管理過程 不同階段的軟件項目應選用不同的項目管理過程 不同軟件項目的管理過程會有不同的具體過程 不同軟件項目的管理過程會有不同的具體過程順序 不同軟件項目的管理過程會有不同的條件與約束 不同軟件項目的管理過程會有不同的簡化程度 不同軟件項目的管理過程需要不同的集成程度 項目變更會使項目管理過程隨之變化

2.3項目管理知識體系

項目綜合管理 項目范圍管理

? ? ? ? ? ? ? ? ? ? 項目時間管理 項目成本管理 項目質量管理 項目人力資源管理 項目溝通管理 項目風險管理 項目采購管理

2.4小節(jié)

項目管理就是將項目管理知識、技能、工具和技術應用于項目活動之中，可以將軟件項目管理活動視做一系列相互聯(lián)系的過程。

項目管理過程可歸納為5個過程組：啟動過程組、規(guī)劃過程組、實施過程組、監(jiān)控過程組與收尾過程組。

項目管理包括9個知識領域：項目綜合管理、項目范圍管理、項目時間管理、項目成本管理、項目質量管理、項目人力資源管理、項目溝通管理、項目風險管理與項目采購管理。

第3章

軟件開發(fā)技術 3.1軟件開發(fā)平臺

? 3.1.1 Microsoft.NET平臺

Microsoft.NET Framework：.NET CLR（通用語言運行環(huán)境）；.NET BCL（基礎類庫）；ASP.NET；ADO.NET。

Microsoft Visual Studio.NET：ADO.NET組件；XML數(shù)據(jù)組件；Windows表單組件；ASP.NET應用服務；ASP.NET Web表單；Web服務支持。

? 3.1.2 J2EE平臺

組件-容器：搭建體系架構平臺標準服務 多層應用模型

3.1.3 Microsoft.NET與J2EE的異同

類似的平臺基礎構造 相同的三層/多層體系 不同的移植、性能和擴展 在Web支持方面的比較 第三方廠商的支持 潛在的市場

3.2中間件技術 ? 3.2.1 中間件簡介

終端仿真/屏幕轉換中間件 數(shù)據(jù)訪問中間件 遠程過程調用中間件 消息中間件 交易中間件 對象中間件

Web服務器中間件 安全中間件

? 3.2.2 消息代理中間件 ? ?

? ? ? ? ? 1.? ? 1.? ? ? ? ? ? ? ?

? ? ? ? ? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

?

? 構件化的結構

可恢復性、易于管理、靈活性 具有數(shù)據(jù)轉換設施。可靠高效的通信 多樣的管理能力 豐富的應用開發(fā)環(huán)境

? 3.2.3 面向數(shù)據(jù)庫的中間件

ODBC JDBC 數(shù)據(jù)庫網(wǎng)關

3.3構件技術 ? 3.3.1 構件庫

構件的存儲

構件的分類與檢索機制 構件庫的編目

構件庫的管理和維護

? 3.3.2 構件模型

3C模型

刻面（Facet）模型 青鳥模型

? 3.3.3 構件的屬性與特點

構件是可獨立配置的單元，構件必須自包容。

構件強調與環(huán)境和其他構件的分離，因此構件的實現(xiàn)是嚴格封裝的，外界沒機會或沒必要知道構件內部的實現(xiàn)細節(jié)。

構件可以在適當?shù)沫h(huán)境中被復合使用，因此構件需要提供清楚的接口規(guī)范，可以與環(huán)境交互。

構件沒有個體特有的屬性，最多僅有特定構件的一份副本。

? 3.3.4 構件與中間件

中間件，本質上是對分布式應用的抽象，中間件與系統(tǒng)架構實際上是從兩種不同的角度看待軟件的中間層次。

中間件促進了構件化軟件，基于中間件開發(fā)的應用系統(tǒng)是構件化的，中間件提供了構件的體系結構，極大提高了構件化軟件開發(fā)的效率和質量。構件化的軟件設計思想在中間件發(fā)展中起到了重要的作用。

3.4小節(jié)

Microsoft.NET平臺和J2EE平臺是目前最常用的兩大軟件開發(fā)平臺。作為彼此競爭的應用平臺，Microsoft.NET平臺和J2EE平臺在目標和體系結構上極其相似，但在實現(xiàn)上又完全不同。二者總的關系是：異中有同，同中有異。中間件是處于操作系統(tǒng)和應用程序之間的軟件。中間件保持了平臺的透明性，抽象了典型的應用模式。應用軟件開發(fā)者可以基于標準的中間件進行再開發(fā)，而不必再考慮操作系統(tǒng)的問題。

構件是可復用的軟件成份，可被用來構造其他軟件。中間件促進了構件化軟件，應用系統(tǒng)在中間件提供的環(huán)境中可以更好地集中于業(yè)務邏輯上，并以構件的形式存在。構件思想也反過來推動了中間件的發(fā)展。

第4章

軟件項目規(guī)劃

4.1項目策劃

? 1.? 1.從政策導向中尋找項目機會 從市場需求中尋找項目機會 從技術發(fā)展中尋找項目機會 從特定事件中尋找項目機會

4.2項目可行性分析 4.2.1 技術可行性分析

? ? ? ? ? 1.? ? ? ? ? ? ? ? ? 項目的必要性分析

軟件組織水平與能力分析 項目技術來源分析 與項目相關的專利分析

項目負責人及技術骨干的資質分析 項目總體技術方案分析 項目創(chuàng)新點分析 項目技術風險分析 項目技術成熟性分析

? 4.2.2 項目投資及效益分析

項目投資預算分析 項目投資來源分析

市場需求與產(chǎn)品銷售額分析

產(chǎn)品成本、利潤與盈虧平衡點分析 投資回收期、投資收益率分析 社會效益分析

4.3項目論證、評估與立項

? 4.3.1 項目論證與評估的基本概念

項目論證是指對擬實施項目技術上的先進性、成熟性、適用性，經(jīng)濟上的合理性、盈利性，實施上的可能性、風險性進行全面科學的綜合分析，為項目決策提供客觀依據(jù)的一種技術經(jīng)濟研究活動。

項目評估指在項目可行性研究的基礎上，項目投資者或項目主管部門或其委托的第三方權威機構根據(jù)國家頒布的政策、法律、法規(guī)、標準和技術規(guī)范，對擬開發(fā)項目的市場需求、技術先進性和成熟性、預期經(jīng)濟效益和社會效益等進行評價、分析和論證，進而判斷其是否可行的過程。

項目論證與評估的內容、程序和依據(jù)大同小異，只是側重點稍有不同，有時不加區(qū)分或合并進行。

? 4.3.2 項目可行性報告的真實性評估

項目申請單位的資質真實性評估 項目申請單位的財務真實性評估 項目申請單位的技術真實性評估 其他事項的真實性評估

? 4.3.3 項目可行性報告的客觀性評估

技術創(chuàng)新點的客觀性評估

技術先進性與成熟性的客觀性評估 ?

?

?

? ? ? ? ? ?

? ? ? ? 信息安全措施的客觀性評估

采用標準、規(guī)范的先進性、合理性評估 項目風險及應對方案的客觀性評估 其他事項的客觀性評估

? 4.3.4 評估報告

? 項目概況 ? 評估目標 ? 評估依據(jù) ? 評估內容

? 評估機構與評估專家 ? 評估過程

? 詳細評估意見

? 存在或遺漏的重大問題 ? 潛在的風險 ? 評估結論

? 進一步的建議

? 4.3.5 項目立項

項目立項的決定應當由項目團隊之外的、適當級別的、并為項目出資的項目發(fā)起人或投資人作出，通常以項目立項決定（通知）書、項目批文、項目許可證書和項目任務書等形式發(fā)布。

4.4項目開發(fā)計劃

? 1．引言 ? 2．引用文件 ? 3．項目最終成果 ? 4．需求與約束

? 5．系統(tǒng)開發(fā)總體計劃 ? 6．項目開發(fā)詳細計劃 ? 7．進度表與活動網(wǎng)絡圖 ? 8．項目組織與資源 ? 9．培訓

? 10．項目估算 ? 11．風險管理 ? 12．支持條件 ? 13．注解 ? 14．附錄

4.5小節(jié)

? 軟件項目規(guī)劃的任務主要包括項目策劃、可行性研究、論證、評估、立項與項目開發(fā)計劃的制訂工作。

? 項目策劃，也稱項目機會研究，其目的是選擇投資機會、鑒別投資方向。

? 項目可行性分析的目的是確定以下問題：項目有無必要？能否完成？是否值得去做？ ? 項目論證與評估的目的是審查項目可行性研究的可靠性、真實性和客觀性，為項目主管部門或投資機構的立項決策提供科學依據(jù)。

? 項目開發(fā)計劃是項目規(guī)劃階段的重要成果，編寫軟件項目開發(fā)計劃時可依據(jù)《GB/T 8567-2006 計算機軟件文檔編制規(guī)范》中的軟件開發(fā)計劃模版。

? ?

? ? ? ? ?

?

?

?

?

? ? ? ? ? ? ? ? ?

第5章

系統(tǒng)分析方法學 5.1系統(tǒng)需求分析與軟件需求

系統(tǒng)需求：系統(tǒng)總體功能和業(yè)務結構；硬件系統(tǒng)需求；軟件系統(tǒng)需求；硬件系統(tǒng)和軟件系統(tǒng)之間的接口需求。軟件需求：軟件能力需求；軟件外部接口需求；軟件內部接口需求；軟件內部數(shù)據(jù)需求；適應性需求；安全性需求；保密性和私密性需求；軟件環(huán)境需求；計算機資源需求；軟件質量需求；設計和實現(xiàn)的約束；數(shù)據(jù)需求；操作需求；故障處理需求；算法需求；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求。

5.2結構化分析

結構化分析（SA）方法是一種面向數(shù)據(jù)流的需求分析方法，基本思想是自頂向下逐層分解。

數(shù)據(jù)流圖（DFD）和數(shù)據(jù)字典（DD）是結構化分析最常用的工具。數(shù)據(jù)流圖用來描述數(shù)據(jù)流從輸入到輸出的變換流程。

數(shù)據(jù)字典是關于數(shù)據(jù)的信息的集合，也就是對數(shù)據(jù)流圖中包含的所有元素的定義的集合。

數(shù)據(jù)流圖和數(shù)據(jù)字典共同構成系統(tǒng)的邏輯模型。

5.3原型化方法

? 5.3.1 原型化方法與結構化方法的比較

結構化方法的假設：所有的需求都能被預先定義；修改定義不完備的系統(tǒng)代價昂貴且實施困難；項目參加者之間能夠清晰進行準確的通信；靜態(tài)描述或圖形模型對應用系統(tǒng)的反映是充分的；結構化方法的生命周期的各階段都是固有正確的。

原型化方法的假設：并非所有的需求在系統(tǒng)開發(fā)以前都能準確地說明；有快速的系統(tǒng)建造工具；項目參加者之間通常都存在通信上的障礙；需要實際的、可供用戶參與的系統(tǒng)模型；需求一旦確定，就可以遵從嚴格的方法；大量的反復是不可避免的、必要的，應該加以鼓勵。

? 5.3.2 原型生命周期及其策略

原型生命周期劃分：選擇開發(fā)方法；識別基本需求；開發(fā)工作模型；模型驗證；修正和改進；判定原型完成；差別細部說明；嚴格說明細部；判定原型效果；整理原型和提供文檔。

原型化的策略：建立數(shù)據(jù)模型；利用組合工程；剪裁和粘貼；用系統(tǒng)舉例；字典驅動；文檔的自動化；小的原型化隊伍；交互式開發(fā)平臺；陳述性規(guī)格說明；終端用戶報表生成器；專業(yè)原型化人員；開發(fā)人員參加原型化。

5.4面向對象的分析

? 5.4.1 面向對象方法學概述

對象與封裝 類

繼承與多態(tài)性 消息通信

面向對象方法學的優(yōu)點

? 5.4.2 面向對象的分析方法

OMT方法簡介 建立對象模型 建立動態(tài)模型 建立功能模型

?

?

? ? ?

? ? ? ? ? ? ? 1.? ? 1.? ? ? ? ?

? ? ? ? ? ?

5.5小節(jié)

系統(tǒng)分析涉及系統(tǒng)需求的獲取、分析、規(guī)格說明和確認。系統(tǒng)需求可分為以下幾個方面：系統(tǒng)總體功能和業(yè)務結構、硬件系統(tǒng)需求、軟件系統(tǒng)需求、硬件系統(tǒng)和軟件系統(tǒng)之間的接口需求。

常用的系統(tǒng)分析方法包括結構化分析、原型化方法和面向對象的分析。

第7章

系統(tǒng)分析文檔

7.1系統(tǒng)/子系統(tǒng)需求規(guī)格說明

引言 引用文件

需求：要求的狀態(tài)和方式；需求概述；系統(tǒng)能力需求；系統(tǒng)外部接口需求；系統(tǒng)內部接口需求；系統(tǒng)內部數(shù)據(jù)需求；適應性需求；安全性需求；保密性和私密性需求；操作需求；可使用性、可維護性、可移植性、可靠性和安全性需求；故障處理需求；系統(tǒng)環(huán)境需求；計算機資源需求；系統(tǒng)質量需求；設計和構造的約束；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求；需求的優(yōu)先次序和關鍵程度 合格性規(guī)定 需求可追蹤性 非技術性需求 尚未解決的問題 注解 附錄

7.2接口需求規(guī)格說明

引言 引用文件 需求

合格性規(guī)定 需求可追蹤性 注解 附錄

7.3軟件需求規(guī)格說明

引言 引用文件

軟件需求：要求的狀態(tài)和方式；需求概述；需求規(guī)格；軟件能力需求；軟件外部接口需求；軟件內部接口需求；軟件內部數(shù)據(jù)需求；適應性需求；安全性需求；保密性和私密性需求；軟件環(huán)境需求；計算機資源需求；軟件質量需求；設計和實現(xiàn)的約束；數(shù)據(jù)需求；操作需求；故障處理需求；算法需求；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求；需求的優(yōu)先次序和關鍵程度 合格性規(guī)定 需求可追蹤性 尚未解決的問題 注解 附錄

7.4小節(jié)

根據(jù)《GB/T 8567-2006 計算機軟件文檔編制規(guī)范》（Specification for computer

? ? ?

? ?

? ? ? ? ? ?

? ? ? ? ?

?

? software documentation），系統(tǒng)分析文檔主要包括系統(tǒng)/子系統(tǒng)需求規(guī)格說明（SSS）、接口需求規(guī)格說明（IRS）和軟件需求規(guī)格說明（SRS）。系統(tǒng)/子系統(tǒng)需求規(guī)格說明（SSS）為一個系統(tǒng)或子系統(tǒng)指定需求以及保證每個需求得到確認所使用的方法。

接口需求規(guī)格說明（IRS）描述為實現(xiàn)一個或多個系統(tǒng)、子系統(tǒng)、硬件配置項（HWCI）、計算機軟件配置項（CSCI）、用戶

軟件需求規(guī)格說明（SRS）描述對計算機軟件的需求以及確保每個需求得到確認所使用的方法。

第8章

系統(tǒng)設計基礎 8.1系統(tǒng)設計概述

? 8.1.1 系統(tǒng)級設計決策

系統(tǒng)級設計決策，是指系統(tǒng)行為的設計決策（忽略其內部實現(xiàn)，從用戶角度出發(fā)，描述系統(tǒng)將怎樣運轉以滿足需求）和其他對系統(tǒng)部件的選擇和設計產(chǎn)生影響的的決策。系統(tǒng)級設計決策內容：有關系統(tǒng)接收的輸入和產(chǎn)生的輸出的設計決策；對每個輸入或條件進行響應的系統(tǒng)行為的設計決策；系統(tǒng)數(shù)據(jù)庫/數(shù)據(jù)文件如何呈現(xiàn)給用戶的設計決策；為滿足安全性、保密性和私密性需求所選用的方法；硬件或硬軟件系統(tǒng)的設計和構造選擇；為了響應需求而作出的其他系統(tǒng)級設計決策。

? 8.1.2 系統(tǒng)架構設計

總體設計

系統(tǒng)部件設計 動態(tài)交互設計 接口設計

? 8.1.3 運行設計

系統(tǒng)初始化——說明本系統(tǒng)的初始化過程。

運行控制——說明對系統(tǒng)施加不同的外界運行控制時所引起的各種不同的運行組件組合、每種運行所經(jīng)歷的內部組件和支持軟件、每一種外界運行控制的方式方法和操作步驟、每種運行組件組合將占用各種資源的情況以及系統(tǒng)運行時的安全控制。運行結束——說明本系統(tǒng)運行的結束過程。

? 8.1.4 系統(tǒng)出錯處理設計

出錯信息——包括出錯信息表、故障處理技術等。補救措施——說明故障出現(xiàn)后可能采取的補救措施。

? 8.1.5 系統(tǒng)維護設計

檢測點的設計——說明在系統(tǒng)中專門安排用于系統(tǒng)檢查與維護的檢測點。

檢測專用組件的設計——說明在系統(tǒng)中專門安排用于系統(tǒng)檢查與維護的專用組件。

8.2軟件設計概述

? 8.2.1 軟件級設計決策

軟件級設計決策是指軟件行為的設計決策（忽略其內部實現(xiàn)，從用戶角度出發(fā)，描述軟件將怎樣運轉以滿足需求）和其他影響組成該軟件的軟件配置項的選擇與設計的決策。

軟件級設計決策內容：有關軟件接收的輸入和產(chǎn)生的輸出的設計決策；對每個輸入或條件進行響應的軟件行為的設計決策；有關數(shù)據(jù)庫/數(shù)據(jù)文件如何呈現(xiàn)給用戶的設計決策；為滿足安全性、保密性和私密性需求所選用的方法；為響應需求而作出的其他軟件級設計決策。

? 8.2.2 軟件架構設計

? ? ? ? ? ? ? ? ? ? ? 程序結構設計

全局數(shù)據(jù)結構設計 軟件配置項設計 動態(tài)交互設計 接口設計

? 8.2.3 軟件詳細設計

軟件配置項設計決策

軟件配置項設計中的約束、限制或非常規(guī)特征 軟件配置項使用的編程語言考慮 軟件配置項使用的過程式命令選取

軟件配置項的局部數(shù)據(jù)與軟件配置項的輸入或輸出數(shù)據(jù)設計 軟件配置項的邏輯設計

8.3設計原則 ? 8.3.1 組件化

組件的可分解性 組件的可組裝性 組件的可理解性 組件的連續(xù)性 組件的保護性

? 8.3.2 抽象

抽象就是抽出事物的本質特性而暫時忽略其細節(jié)，使得不同的事物可以當作相同的事務來處理。

軟件工程過程的每一步都是對軟件解法的抽象層次的一次精化。

軟件設計中的抽象機制主要包括類、模板、過程抽象、數(shù)據(jù)抽象和控制抽象。

? 8.3.3 內聚與耦合

內聚是指一個組件內各個元素彼此結合的緊密程度 內聚種類（由低到高排列）：偶然內聚；邏輯內聚；瞬時內聚；過程內聚；通信內聚；順序內聚；功能內聚

耦合是指一個軟件結構內不同組件之間的互連程度 耦合種類（由高到低排列）：內容耦合；公共耦合；外部耦合；控制耦合；標記耦合；數(shù)據(jù)耦合；非直接耦合

組件的高內聚、低耦合原則稱為組件獨立原則

? 8.3.4 封裝與信息隱蔽

第一，組件是其全部屬性和全部服務緊密結合而形成的一個不可分割的整體。

第二，組件是一個不透明的黑盒子，表示組件狀態(tài)的數(shù)據(jù)和實現(xiàn)操作的代碼都被封裝在黑盒子里面。使用一個組件的時候，只需知道它向外界提供的接口形式，無須知道它的數(shù)據(jù)結構細節(jié)和實現(xiàn)操作的算法。

? 8.3.5 啟發(fā)式規(guī)則

深度、寬度、扇出與扇入 作用域和控制域 功能的可預測性

8.4設計視圖

? 8.4.1 架構視圖（靜態(tài)視圖）

架構描述語言（ADL）? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? ? ?

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? ? 類圖與對象圖 組件圖

協(xié)作責任卡（CRC）部署圖

實體-聯(lián)系圖（E-R圖）接口描述語言（IDL）結構圖

Jackson結構圖

? 8.4.2 行為視圖（動態(tài)視圖）

活動圖 協(xié)作圖 順序圖 數(shù)據(jù)流圖

決策表和決策圖

流程圖和結構化流程圖 狀態(tài)圖

形式化描述語言 偽碼

8.5小節(jié)

系統(tǒng)設計是定義一個系統(tǒng)或軟件的架構、組件、接口和其它特征的過程。包括系統(tǒng)級設計決策、系統(tǒng)架構設計、運行設計、系統(tǒng)出錯處理設計和系統(tǒng)維護設計。

軟件設計主要包括軟件級設計決策、軟件架構設計（概要設計）與詳細設計。軟件架構設計的主要任務是程序結構設計、全局數(shù)據(jù)結構設計、軟件配置項設計、動態(tài)交互設計和接口設計。軟件詳細設計是指每一個軟件配置項的具體設計。

組件化、抽象、高內聚與低耦和、封裝與信息隱蔽是軟件設計的基本原則。軟件設計視圖通?？煞譃榧軜嬕晥D（靜態(tài)視圖）和行為視圖（動態(tài)視圖）兩類。第9章

系統(tǒng)設計方法 9.1結構化設計

? 9.1.1 結構化設計方法概述

分析系統(tǒng)的總體需求，并將需求逐步分解為基本、具體的功能。確定每個功能應當記錄的數(shù)據(jù)。

列出系統(tǒng)中應提供的各項基本功能，并分析各項基本功能之間的耦合關系，根據(jù)高內聚、低耦和的原則分配到系統(tǒng)中適當?shù)哪K中。

? 9.1.2 系統(tǒng)結構圖

模塊 調用 數(shù)據(jù) 控制 轉接符號

? 9.1.3 系統(tǒng)結構圖分類

變換流與事務流 變換型系統(tǒng)結構圖 事務型系統(tǒng)結構圖 ? ? ?

? ? ? ? ? ? ? ?

? 混合型系統(tǒng)結構圖

9.2面向數(shù)據(jù)結構的設計

? 9.2.1 面向數(shù)據(jù)結構的設計概述

分析并建立適合系統(tǒng)的數(shù)據(jù)結構；

根據(jù)數(shù)據(jù)結構在相應的層次建立程序結構；

羅列出程序中用到的各種基本操作，并將這些基本操作分配到程序結構中合適的模塊中。

? 9.2.2 Jackson圖

順序結構 選擇結構 重復結構

改進的Jackson圖

? 9.2.3 Jackson方法

分析并確定輸入和輸出數(shù)據(jù)的邏輯結構，并利用Jackson 找出輸入和輸出數(shù)據(jù)結構中存在對應關系的數(shù)據(jù)單元。從描繪數(shù)據(jù)結構的Jackson圖導出描繪程序結構的Jackson

列出所有操作和條件(包括分支條件和循環(huán)結束條件)，并且把它們安排到程序結構圖的適當位置。用偽代碼表示。

9.3面向對象的設計

? 9.3.1 面向對象的設計概述

面向對象設計的基本思想是通過建立和客觀實際相對應的對象，并通過這些對象的組合來創(chuàng)建具體的應用。

面向對象設計具有基于抽象、信息隱藏、功能獨立和模塊性構造系統(tǒng)的能力。

對于面向對象的系統(tǒng)，可以定義一個四個層次的設計金字塔：子系統(tǒng)層；類及對象層；消息層；責任層。

? 9.3.2 面向對象設計技術

? Coad/Yourdon方法 ? Booch方法 ? OMT方法 ? ?

? 9.3.3 面向對象設計過程

系統(tǒng)設計過程：將分析模型劃分為子系統(tǒng)；子系統(tǒng)分配及與問題的并發(fā)性；任務管理；數(shù)據(jù)管理；資源管理；人機界面；子系統(tǒng)間通信

對象設計過程：對象描述；算法與數(shù)據(jù)結構設計；接口設計與模塊化

9.4設計模式

? 9.4.1 設計模式概述

設計模式就是將面向對象軟件的設計經(jīng)驗記錄下，可供設計者能夠復用的設計方案。設計模式極大提高了面向對象軟件開發(fā)的效率，降低了軟件的復雜度。

在軟件設計中使用設計模式，將使用開發(fā)出來的軟件更容易理解、更容易維護、更容易擴展，使用設計模式同時也能夠提高開發(fā)團隊和個人的開發(fā)能力。

? 9.4.2 設計模式基本組成

模式名稱：惟一標識一個設計模式。問題：描述應該在何時使用該模式。? ? ?

? ? ? ? ? ? ? ? ?

? ? ?

? ? ?

? ?

? 解決方案：描述設計的組成要素，以及它們之間的相互關系及各自的職責與相互之間協(xié)作的方式。

? 效果：描述應用設計模式的效果，以及使用設計模式必須考慮的限制和約束因素。

? 9.4.3 設計模式分類

? 面向對象模式 ? 代碼模式

? 框架應用模式

? 創(chuàng)建型模式、結構型模式與行為型模式 ? 類模式與對象模式

? 9.4.4 如何使用設計模式

? 針對接口編程，而不是針對實現(xiàn)編程 ? 優(yōu)先使用對象組合，而不是類繼承 ? 找出變化并封裝

9.5小節(jié)

? 系統(tǒng)設計是一系列迭代的過程，主要任務包括數(shù)據(jù)結構、體系結構、接口及過程細節(jié)的設計等，而設計方法是軟件設計活動中實現(xiàn)設計模型的方法。? 系統(tǒng)設計方法主要包括面向過程的結構化設計方法、面向數(shù)據(jù)結構的設計，以及面向對象的設計方法與設計模式。

第10章

數(shù)據(jù)庫設計 10.1數(shù)據(jù)建模

? 10.1.1 數(shù)據(jù)模型分類

? 概念數(shù)據(jù)模型 ? 結構數(shù)據(jù)模型 ? 物理數(shù)據(jù)模型

? 10.1.2 實體-聯(lián)系（E-R）模型

? 實體 ? 屬性 ? 聯(lián)系 ? 實體型 ? 實體集 ? 鍵 ? 域

? 10.1.3 數(shù)據(jù)模型

? 層次數(shù)據(jù)模型（hierarchical model）? 網(wǎng)狀數(shù)據(jù)模型（network model）? 關系數(shù)據(jù)模型（relational model）

? 面向對象模型（object oriented model）

10.2數(shù)據(jù)規(guī)范化

? 10.2.1 數(shù)據(jù)規(guī)范化的基本概念

? 函數(shù)依賴

? 非平凡函數(shù)依賴 ? 完全函數(shù)依賴 ? 部分函數(shù)依賴

? 傳遞函數(shù)依賴 ? 鍵

? 10.2.2 范式

? ? ? ? 第一范式（1NF）第二范式（2NF）第三范式（3NF）BC范式（BCNF）

10.3數(shù)據(jù)庫設計過程 ? 10.3.1 數(shù)據(jù)庫需求分析

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 數(shù)據(jù)邊界的確定 數(shù)據(jù)環(huán)境的確定 數(shù)據(jù)內部關系 數(shù)據(jù)字典

數(shù)據(jù)性能需求

數(shù)據(jù)需求分析說明書

? 10.3.2 數(shù)據(jù)庫概念設計

概念設計與概念模型 概念設計的主要方法 分解與抽象 局部概念模式 全局概念模式

? 10.3.3 數(shù)據(jù)庫邏輯設計

初始模式的形成 子模式設計

應用程序概要設計 模式評審 修正模式

? 10.3.4 數(shù)據(jù)庫物理設計

存儲記錄結構設計 確定數(shù)據(jù)存放位置 存取方法設計

完整性和安全考慮 程序設計

10.4小節(jié)

? 數(shù)據(jù)庫系統(tǒng)普遍采取數(shù)據(jù)模型表示和處理客觀事物的數(shù)據(jù)特征與信息。數(shù)據(jù)模型主要由數(shù)據(jù)結構、數(shù)據(jù)操作和完整性約束三部分組成，從抽象層次上描述和模擬了系統(tǒng)的靜態(tài)特征、動態(tài)行為和約束條件。

? 關系數(shù)據(jù)庫中的關系必須滿足一定的要求，即滿足不同的范式。目前關系數(shù)據(jù)庫中常用的范式包括：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）和BCNF。? 數(shù)據(jù)庫設計主要包括需求分析、概念設計、邏輯設計和物理設計等幾個階段。

第11章

用戶界面設計

11.1基本概念

? ? ?

? ? ? ? ? ? ? ? ? ?

? ? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ?

? 11.1.1 界面設計目標

可用性目標：可行性、有效性、易學性、易記性、安全性、通用性

用戶體驗目標：令人滿意、令人愉快、引人入勝、富有啟發(fā)、激發(fā)創(chuàng)造??

可用性目標主要從客觀角度來評價系統(tǒng)界面，而用戶體驗目標則是從用戶主觀感受的角度來評價系統(tǒng)界面。

? 11.1.2 界面設計原則

可視性：將系統(tǒng)功能呈現(xiàn)得一目了然。

反饋性：返回與活動相關的信息，以便用戶能夠繼續(xù)這個活動。限制性：將用戶的行為限制在一定的范圍內。

對應性：明確系統(tǒng)某個控制與其控制效果之間的對應關系。一致性：用相似的元素表現(xiàn)相似的操作或相似的任務。啟示性：界面元素應給予用戶某種提示。

? 11.1.3 界面設計過程

標識出用戶的真實需要并建立需求模型 設計出候選方案

構建或實現(xiàn)設計的原型版本 對界面設計進行評估

11.2界面設計技術

? 11.2.1 界面設計分析技術

GOMS模型及GOMS擊鍵層模型 Hick律 Fitts律

? 11.2.2 界面設計方法

原型設計方法

以用戶為中心的設計方法 用戶界面設計的支持工具

11.3界面設計評估

? 11.3.1 構造性評估與總結性評估

構造性評估：在設計過程中對所設計的系統(tǒng)或產(chǎn)品界面進行評估以確保其滿足用戶需求。

總結性評估：對已經(jīng)完成的產(chǎn)品或系統(tǒng)界面進行評估。

? 11.3.2 評估范型

快速評估 可用性測試 實地研究 預測性評估

? 11.3.3 評估方法與技術

觀察用戶

征求用戶意見 征求專家意見 用戶測試

用戶執(zhí)行情況的分析模型

? 11.3.4 評估框架

明確（Determine）

? ? ? ? ? ? ? ? ?

發(fā)掘（Explore）選擇（Choose）標識（Identify）決定（Decide）評估（Evalute）

11.5小節(jié)

用戶界面體現(xiàn)了用戶利用系統(tǒng)完成任務的方式以及系統(tǒng)對用戶行為的響應方式，一個沒有良好的用戶界面設計的系統(tǒng)很可能會成為一個沒有用戶的系統(tǒng)。可用性目標與用戶體驗目標。

界面設計的量化模型：GOMS模型及其子模型-擊鍵層模型，Hick律和Fitts律。構造性評估與總結性評估。

第12章

系統(tǒng)設計文檔

12.1系統(tǒng)/子系統(tǒng)（結構）設計說明

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 引言 引用文件

系統(tǒng)級設計決策

系統(tǒng)體系結構設計：總體設計；系統(tǒng)部件設計；動態(tài)交互設計；接口設計 運行設計

系統(tǒng)出錯處理設計 系統(tǒng)維護設計 尚未解決的問題 需求的可追蹤性 注解 附錄

12.2

接口設計說明

引言 引用文件 接口設計

需求的可追蹤性 注解 附錄

12.3

軟件（結構）設計說明

引言 引用文件

軟件級設計決策

軟件體系結構設計：程序結構設計；全局數(shù)據(jù)結構設計；軟件配置項設計；動態(tài)交互設計；接口設計 軟件詳細設計 需求的可追蹤性 注解 附錄

12.4數(shù)據(jù)庫設計說明

? ? ? ? ? ? ? ? ?

? ? ? ? ?

引言 引用文件

數(shù)據(jù)庫級設計決策 數(shù)據(jù)庫詳細設計

用于數(shù)據(jù)庫操縱或訪問的軟件配置項的詳細設計 需求的可追蹤性 注解 附錄

12.5

小節(jié)

根據(jù)《GB/T 8567-2006 計算機軟件文檔編制規(guī)范》，系統(tǒng)設計文檔主要包括系統(tǒng)/子系統(tǒng)設計（結構設計）說明（SSDD）、接口設計說明（IDD）、軟件（結構）設計說明（SDD）和數(shù)據(jù)庫設計說明（DBDD）。

系統(tǒng)/子系統(tǒng)設計（結構設計）說明（SSDD）描述了系統(tǒng)（或子系統(tǒng)）的系統(tǒng)級（或子系統(tǒng)級）設計決策與體系結構設計。

接口設計說明（IDD）描述了一個或多個系統(tǒng)、子系統(tǒng)、硬件配置項（HWCI）、計算機軟件配置項（CSCI）、用戶或其他系統(tǒng)部件的接口特性。

軟件（結構）設計說明（SDD）描述了計算機軟件系統(tǒng)的軟件級設計決策、軟件體系結構設計（概要設計）與詳細設計。

數(shù)據(jù)庫（頂層）設計說明（DBDD）描述了數(shù)據(jù)庫的設計。系統(tǒng)設計文檔可以使用自然語言，可以使用形式化語言，也可以根據(jù)具體的系統(tǒng)設計方法使用各種圖形工具，還可以根據(jù)實際情況混合使用多種表現(xiàn)形式。

第五篇：系統(tǒng)分析與設計 期末考試

10.在一個課程注冊系統(tǒng)中，定義了類CourseSchedule和類Course，并在類CourseSchedule中定義了方法add(c: Course)和方法remove(c: Course)，則類CourseSchedule和類Course之間的關系是：（）A.泛化（generalization）關系 B.組合（composition）關系 C.依賴（dependency）關系 D.包含（include）關系 13.進行企業(yè)系統(tǒng)規(guī)劃，哪種規(guī)劃方法使目標識別比較全面

A、企業(yè)系統(tǒng)規(guī)劃法 B、關鍵成功因素法

C、戰(zhàn)略目標集轉化法 D、成本效益分析法 14.系統(tǒng)開發(fā)的生命周期中不包括下列哪個階段（）A.系統(tǒng)規(guī)劃 B.系統(tǒng)分析 C.系統(tǒng)設計 D.系統(tǒng)實施

19.面向對象程序設計將描述事物的數(shù)據(jù)與()封裝在一起,作為一個相互依存、不可分割的整體來處理。A.信息 B.數(shù)據(jù)隱藏 C.對數(shù)據(jù)的操作 D.數(shù)據(jù)抽象 22.屬于系統(tǒng)設計階段的工具是（）：

A.數(shù)據(jù)流程圖 B.處理流程圖 C.系統(tǒng)流程圖 D.HIPO圖

23.進行企業(yè)系統(tǒng)規(guī)劃，哪種規(guī)劃方法可以形成一套完整的信息系統(tǒng)結構方案（）A.企業(yè)系統(tǒng)規(guī)劃法 B.關鍵成功因素法 C.戰(zhàn)略目標集轉化法 D.成本效益分析法

30.導出模塊結構圖的基礎是（）

A.業(yè)務流程圖 B.數(shù)據(jù)流程圖 C.處理流程圖 D.層次結構圖

32.（）是從用戶使用系統(tǒng)的角度描述系統(tǒng)功能的圖形表達方法。

A.類圖 B.對象圖 C.序列圖 D.用例圖

35.UML中，對象行為是通過交互來實現(xiàn)的，是對象間為完成某一目的而進行的一系列消息交換。消息序列可用兩種圖來表示，分別是（D）

A.狀態(tài)圖和順序圖 B.活動圖和協(xié)作圖

C.狀態(tài)圖和活動圖 D.順序圖和協(xié)作圖

36.用例（Use-case）用來描述系統(tǒng)在事件做出響應時所采取的行動。用例之間是具有相關性的。在一個“訂單輸入子系統(tǒng)”中，創(chuàng)建新訂單和更新訂單都需要檢查用戶帳號是否正確。那么，用例“創(chuàng)建新訂單”、“更新訂單”與用例“檢查用戶帳號”之間是（A）關系。

A.包含（include）B.擴展（extend）

C.分類（classification）D.聚集（aggregation）

1、組成UML有三種基本的建筑塊是：（A），事物和圖

A、關系 B、類 C、用例 D、實體

2、UML體系包括三個部分：UML基本構造塊，（A）和UML公共機制

A、UML規(guī)則 B、UML命名 C、UML模型 D、UML約束

4、（A）模型的缺點是缺乏靈活性，特別是無法解決軟件需求不明確或不準確的問題

A、瀑布模型 B、原型模型 C、增量模型 D、螺旋模型

5、下面哪個不是UML中的靜態(tài)視圖（A）

A.狀態(tài)圖 B.用例圖 C.對象圖 D.類圖

6、（A）技術是將一個活動圖中的活動狀態(tài)進行分組，每一組表示一個特定的類、人或部門，他們負責完成組內的活動。

A、泳道 B、分叉匯合 C、分支 D、轉移

7、下列關于狀態(tài)圖的說法中，正確的是（C）

A.狀態(tài)圖是UML中對系統(tǒng)的靜態(tài)方面進行建模的五種圖之一。B.狀態(tài)圖是活動圖的一個特例，狀態(tài)圖中的多數(shù)狀態(tài)是活動狀態(tài)

C.活動圖和狀態(tài)圖是對一個對象的生命周期進行建模，描述對象隨時間變化的行為。D.狀態(tài)圖強調對有幾個對象參與的活動過程建模，而活動圖更強調對單個反應型對象建模

8、對反應型對象建模一般使用（A）圖

A、狀態(tài)圖 B、順序圖 C、活動圖 D、類圖

12、（D）是系統(tǒng)中遵從一組接口且提供實現(xiàn)的一個物理部件，通常指開發(fā)和運行時類的物理實現(xiàn) A、部署圖 B、類 C、接口 D、組件

13、關于協(xié)作圖的描述，下列哪個不正確（B）

A.協(xié)作圖作為一種交互圖，強調的是參加交互的對象的組織； B.協(xié)作圖是順序圖的一種特例 C.協(xié)作圖中有消息流的順序號；

D.在ROSE工具中，協(xié)作圖可在順序圖的基礎上按“F5”鍵自動生成； 8定義大多數(shù)的需求和范圍的工作是在UP中的 B 階段完成的。A初始階段 B細化階段 C構造階段 D提交階段

1.信息系統(tǒng)設計是系統(tǒng)開發(fā)的重要階段，進行系統(tǒng)設計的主要依據(jù)應是（）。A、可行性研究報告B 系統(tǒng)分析報告

C、系統(tǒng)調查報告 D、系統(tǒng)規(guī)劃報告

3.在系統(tǒng)總體結構設計時，應采納什么樣的方法（）。A、程序設計 B、結構化設計 C、由里向外 D、自底向上 4.結構化設計的基本思想是（）。

A、模塊化 B、集成化 C、自底向上，逐步求精 D、規(guī)范化

5.在結構化生命周期法中，系統(tǒng)分析和系統(tǒng)實施之間的階段是（）。A、詳細設計 B系統(tǒng)設計 C、需求分析 D、編程調試 6.對于結構化設計思想的描述哪一項是錯誤的（）。

A、在結構化設計中，模塊的功能應當簡單明確，易于理解 B、自頂向下，逐步求精

C、設計者應先設計頂層模塊

D、越下層模塊，其功能越具體，越復雜 8.系統(tǒng)設計階段的主要目的是（）。

A、設計新系統(tǒng)的目標 B 將系統(tǒng)邏輯方案轉換成物理方案 C、代碼設計 D、程序設計 19.結構化設計方法中繪制模塊結構圖的基礎是（）。A 數(shù)據(jù)流程圖 B、數(shù)據(jù)關系圖 C、數(shù)據(jù)結構圖 D、業(yè)務流程圖 29.系統(tǒng)設計階段的主要工作內容之一是（）。

A、程序設計 B、購置計算機 C、畫出數(shù)據(jù)流程圖 B、規(guī)定處理過程 31.系統(tǒng)的呑吐量指的是（）。

A、每天的數(shù)據(jù)輸出量 B、每秒數(shù)據(jù)的處理量 C、每日數(shù)據(jù)的輸入量 D、每秒執(zhí)行的作業(yè)數(shù)

33.在系統(tǒng)物理配置方案的設計中，系統(tǒng)的（）可以用連續(xù)工作時間來表示。A、吞吐量 B、響應時間 C 可靠性 D、地域范圍 34.計算機和網(wǎng)絡系統(tǒng)配置說明，應包含在()中。

A、系統(tǒng)規(guī)劃說明書 B、系統(tǒng)設計說明書 C、系統(tǒng)實施說明書 D、系統(tǒng)分析說明書 35.屬于系統(tǒng)詳細設計工作的是（）。

A、輸入輸出設計 B、系統(tǒng)平臺設計 C、系統(tǒng)結構設計 D、程序設計 39.系統(tǒng)設計報告的主要作用是作為（）的依據(jù)。A、系統(tǒng)規(guī)劃 B、系統(tǒng)分析 C、系統(tǒng)實施 D、系統(tǒng)評價

1.B 3.B 4.A 5.B 6.D8.B 19.A 29.D 31.D 33.C 34.B 35.A 39.C 11.系統(tǒng)設計階段需要從數(shù)據(jù)流程圖導出模塊結構圖。B.生命周期結構(Lifecycle Architecture)里程碑 4．系統(tǒng)實施的主要活動包括（D）。C.初始功能(Initial Operational)里程碑 A、編程、系統(tǒng)調試 B、系統(tǒng)安裝 C、新舊系統(tǒng)轉換 D、以上都是 1．系統(tǒng)實施是以（B）為依據(jù)的。

A、系統(tǒng)分析文檔資料 B、系統(tǒng)設計文檔資料

C、系統(tǒng)分析和設計文檔資料 D、數(shù)據(jù)流程圖

7.一般子系統(tǒng)的劃分是在系統(tǒng)()階段,根據(jù)對系統(tǒng)的功能/數(shù)據(jù)分析的結果提出的.A.需求分析 B.邏輯階段 C.總體設計 D.詳細設計 答案: A 4.業(yè)務系統(tǒng)規(guī)劃法(BSP)的核心是()A.明確企業(yè)目標 B.定義(識別)業(yè)務過程 C.進行數(shù)據(jù)分析 D.確定信息結構 答案: C 7.一般子系統(tǒng)的劃分是在系統(tǒng)()階段,根據(jù)對系統(tǒng)的功能/數(shù)據(jù)分析的結果提出的.A.需求分析 B.邏輯階段 C.總體設計 D.詳細設計 答案: A 4.業(yè)務系統(tǒng)規(guī)劃法(BSP)的核心是()A.明確企業(yè)目標 B.定義(識別)業(yè)務過程 C.進行數(shù)據(jù)分析 D.確定信息結構 答案: C 12.RUP中的軟件生命周期在時間上被分解為四個順序的階段,分別是:初始階段(Inception),細化階段(Elaboration),構造階段(Construction)和交付階段(Transition),每個階段結束于一個主要的里程碑(Major Milestones).構建階段結束時是第三個重要的里程碑:初始功能(Initial Operational)里程碑.A.生命周期目標(Lifecycle Objective)里程碑

D.產(chǎn)品發(fā)布(Product Release)里程碑 答案: C

14.信息系統(tǒng)開發(fā)的結構化方法的一個主要原則是().A.自頂向下原則 B.自底向上原則 C.分步實施原則 D.重點突破原則 答案: A

16.一般來說,占維護工作比例最高的是().A.糾錯性維護 B.適應性維護 C.完善性維護 D.預防性維護 答案: C

17.用戶開發(fā)應用系統(tǒng)的主要手段是().A.生命周期法 B.原型法 C.第四代語言 D.面向對象方法 答案: A

19.系統(tǒng)規(guī)劃的主要任務包括().A.明確組織的信息需求,制定系統(tǒng)總體結構方案 B.對系統(tǒng)進行經(jīng)濟,技術和使用方面的可行性研究 C.選擇計算機和網(wǎng)絡系統(tǒng)的方案 D.確定軟件系統(tǒng)的模塊結構 答案: A

20.系統(tǒng)設計階段的主要成果是().A.用戶的決策方針 B.用戶的分析方案 C.系統(tǒng)設計說明書 D.系統(tǒng)總體設計方案

答案: C

21.信息系統(tǒng)建設的結構化方法中用戶必須參與的原則是用戶必須參與().A.系統(tǒng)建設中各階段工作 B.系統(tǒng)分析工作 C.系統(tǒng)設計工作 D.系統(tǒng)實施工作 答案: A

22.結構化生命周期法的主要缺點之一是().A.系統(tǒng)開發(fā)周期長 B.缺乏標準,規(guī)范

C.用戶參與程度低 D.主要工作集中在實施階段 答案: A 24.系統(tǒng)分析工作的全面總結和主要成果是().A.可行性研究報告B.數(shù)據(jù)詞典 C.系統(tǒng)說明書 D.系統(tǒng)詳細調查報告 答案: A 28.生命周期法的特點之一是().A.整個系統(tǒng)的開發(fā)工作是非勞動密集型的 B.系統(tǒng)開發(fā)時間短

C.對用戶需求的變更能做出迅速響應 D.適合大型復雜系統(tǒng) 答案: C 30.系統(tǒng)維護中要解決的問題來源于().A.系統(tǒng)分析階段 B.系統(tǒng)設計階段 C.系統(tǒng)實施階段 D.三者都包括

答案: D 38.下面哪一項不是系統(tǒng)設計階段的主要活動().A.系統(tǒng)總體設計 B.系統(tǒng)硬件設計 C.系統(tǒng)詳細設計 D.編寫系統(tǒng)實施計劃 答案: D 39.對于結構化設計思想的描述哪一項是錯誤的().A.在結構化設計中,模塊的功能應當簡單明確,易于理解

B.自頂向下,逐步求精

C.設計者應先設計頂層模塊

D.越下層模塊,其功能越具體,越復雜

答案: D 73.在系統(tǒng)生命周期的各階段中,花費費用和人力投入最多的階段是().A.分析與設計 B.編制程序 C.測試程序 D.系統(tǒng)維護

答案: A 78.在UML提供的圖中,()用于描述系統(tǒng)與外部系統(tǒng)及用戶之間的交互.A.用例圖 B.類圖 C.對象圖 D.部署圖

答案:A 79.在UML提供的圖中,()用于按時間順序描述對象間的交互.A.網(wǎng)絡圖 B.狀態(tài)圖 C.協(xié)作圖 D.序列圖（順序圖）答案:D 96.系統(tǒng)分析報告的主要作用是().A.系統(tǒng)規(guī)劃的依據(jù) B.系統(tǒng)實施的依據(jù) C.系統(tǒng)設計的依據(jù) D.系統(tǒng)評價的依據(jù) 答案:C 95.繪制系統(tǒng)流程圖的基礎是().A.數(shù)據(jù)關系圖 B.數(shù)據(jù)流程圖 C.數(shù)據(jù)結構圖 D.功能結構圖 答案:B

9.信息系統(tǒng)開發(fā)的步驟是:在系統(tǒng)規(guī)劃后,循進行_____, _____, _____ ,_____ 工作.答案: 系統(tǒng)分析 系統(tǒng)設計 系統(tǒng)構建與實施 系統(tǒng)評價 13.信息系統(tǒng)規(guī)劃有哪些方法

答:用于企業(yè)信息系統(tǒng)規(guī)劃的方法主要有戰(zhàn)略分析法,即關鍵成功因素法(Critical Success Factors,CSF);企業(yè)分析法,即企業(yè)系統(tǒng)規(guī)劃法(Business System Planning,BSP);基于BPR的信息系統(tǒng)戰(zhàn)略規(guī)劃方法.其他的方法還有戰(zhàn)略目標集轉化法(Strategy Set Transformation,SST),企業(yè)信息分析與集成技術(BIAIT),投資回收法(R01)等.12.RUP中的軟件生命周期在時間上被分解為四個順序的階段,分別是:初始階段(Inception),細化階段(Elaboration),構造階段(Construction)和交付階段(Transition),每個階段結束于一個主要的里程碑(Major Milestones).構建階段結束時是第三個重要的里程碑:初始功能(Initial Operational)里程碑.A.生命周期目標(Lifecycle Objective)里程碑 B.生命周期結構(Lifecycle Architecture)里程碑 C.初始功能(Initial Operational)里程碑 D.產(chǎn)品發(fā)布(Product Release)里程碑

答案: C

14.信息系統(tǒng)開發(fā)的結構化方法的一個主要原則是().A.自頂向下原則 B.自底向上原則 C.分步實施原則 D.重點突破原則 答案: A

16.一般來說,占維護工作比例最高的是().A.糾錯性維護 B.適應性維護 C.完善性維護 D.預防性維護 答案: C

17.用戶開發(fā)應用系統(tǒng)的主要手段是().A.生命周期法 B.原型法 C.第四代語言 D.面向對象方法

答案: A

19.系統(tǒng)規(guī)劃的主要任務包括().A.明確組織的信息需求,制定系統(tǒng)總體結構方案 B.對系統(tǒng)進行經(jīng)濟,技術和使用方面的可行性研究 C.選擇計算機和網(wǎng)絡系統(tǒng)的方案 D.確定軟件系統(tǒng)的模塊結構 答案: A

20.系統(tǒng)設計階段的主要成果是().A.用戶的決策方針 B.用戶的分析方案 C.系統(tǒng)設計說明書 D.系統(tǒng)總體設計方案 答案: C

21.信息系統(tǒng)建設的結構化方法中用戶必須參與的原則是用戶必須參與().A.系統(tǒng)建設中各階段工作 B.系統(tǒng)分析工作 C.系統(tǒng)設計工作 D.系統(tǒng)實施工作 答案: A 22.結構化生命周期法的主要缺點之一是().A.系統(tǒng)開發(fā)周期長 B.缺乏標準,規(guī)范

C.用戶參與程度低 D.主要工作集中在實施階段 答案: A 24.系統(tǒng)分析工作的全面總結和主要成果是().A.可行性研究報告B.數(shù)據(jù)詞典 C.系統(tǒng)說明書 D.系統(tǒng)詳細調查報告 答案: A 28.生命周期法的特點之一是().A.整個系統(tǒng)的開發(fā)工作是非勞動密集型的 B.系統(tǒng)開發(fā)時間短

C.對用戶需求的變更能做出迅速響應 D.適合大型復雜系統(tǒng) 答案: C 30.系統(tǒng)維護中要解決的問題來源于().A.系統(tǒng)分析階段 B.系統(tǒng)設計階段 C.系統(tǒng)實施階段 D.三者都包括 答案: D 38.下面哪一項不是系統(tǒng)設計階段的主要活動().A.系統(tǒng)總體設計 B.系統(tǒng)硬件設計 C.系統(tǒng)詳細設計 D.編寫系統(tǒng)實施計劃

答案: D 39.對于結構化設計思想的描述哪一項是錯誤的().A.在結構化設計中,模塊的功能應當簡單明確,易于理解

B.自頂向下,逐步求精

C.設計者應先設計頂層模塊

D.越下層模塊,其功能越具體,越復雜

答案: D 73.在系統(tǒng)生命周期的各階段中,花費費用和人力投入最多的階段是().A.分析與設計 B.編制程序 C.測試程序 D.系統(tǒng)維護

答案: A 78.在UML提供的圖中,()用于描述系統(tǒng)與外部系統(tǒng)及用戶之間的交互.A.用例圖 B.類圖 C.對象圖 D.部署圖 答案:A 79.在UML提供的圖中,()用于按時間順序描述對象間的交互.A.網(wǎng)絡圖 B.狀態(tài)圖 C.協(xié)作圖 D.序列圖（順序圖）

答案:D

96.系統(tǒng)分析報告的主要作用是().A.系統(tǒng)規(guī)劃的依據(jù) B.系統(tǒng)實施的依據(jù) C.系統(tǒng)設計的依據(jù) D.系統(tǒng)評價的依據(jù) 答案:C

95.繪制系統(tǒng)流程圖的基礎是().A.數(shù)據(jù)關系圖 B.數(shù)據(jù)流程圖 C.數(shù)據(jù)結構圖 D.功能結構圖 答案:B

9.信息系統(tǒng)開發(fā)的步驟是:在系統(tǒng)規(guī)劃后,循進行_____, _____, _____ ,_____ 工作.答案: 系統(tǒng)分析 系統(tǒng)設計 系統(tǒng)構建與實施 系統(tǒng)評價 13.信息系統(tǒng)規(guī)劃有哪些方法

答:用于企業(yè)信息系統(tǒng)規(guī)劃的方法主要有戰(zhàn)略分析法,即關鍵成功因素法(Critical Success Factors,CSF);企業(yè)分析法,即企業(yè)系統(tǒng)規(guī)劃法(Business System Planning,BSP);基于BPR的信息系統(tǒng)戰(zhàn)略規(guī)劃方法.其他的方法還有戰(zhàn)略目標集轉化法(Strategy Set Transformation,SST),企業(yè)信息分析與集成技術(BIAIT),投資回收法(R01)等.2.信息系統(tǒng)規(guī)劃是指對組織目標、組織現(xiàn)狀進行分析，從而制定指導信息系統(tǒng)建設的總體規(guī)劃和信息系統(tǒng)長期發(fā)展展望。在眾多的信息系統(tǒng)規(guī)劃方法當中，具有代表性的主要有 企業(yè)系統(tǒng)規(guī)劃法、戰(zhàn)略目標轉移法、關鍵成功因素法。

4.信息系統(tǒng)建設的特點決定了信息系統(tǒng)建設要做大量復雜和細致的工作。信息系統(tǒng)建設主要包括 信息系統(tǒng)規(guī)劃、信息系統(tǒng)開發(fā)、信息系統(tǒng)維護 和 信息系統(tǒng)管理 四方面的工作。

1． UML統(tǒng)一建模語言共定義了哪兩類、哪八種圖形？

答：（1）靜態(tài)結構圖：類圖，對象圖，構件圖，實施圖

（2）動態(tài)行為圖：用例圖，順序圖，協(xié)作圖，狀態(tài)圖，活動圖

2.在下圖所示的用例分析類圖中，請指出各個概念類屬于哪一類，并分別解釋三種概念類的特點及概念?！笆蹠幚怼钡挠美治鲱悎D書目售書員售書界面產(chǎn)生待售圖書待售圖書開書單打印進程架存圖書出售圖書售出圖書答：屬于實體類的有：書目、架存圖書、代售圖書、售出圖書。

屬于邊界類的有：售書界面。

屬于控制類的有：產(chǎn)生待售圖書、出售圖書、開書單。三種概念類的特點及概念：

特點：概念類面向功能需求，一般不考慮性能要求，具有突出業(yè)務領域、突出概念性及大粒度的特征。概念：（1）實體類是信息系統(tǒng)表示客觀實體的抽象要素。它一般對應著在業(yè)務領域中的客觀事物，或是具有較穩(wěn)定信息內容的系統(tǒng)元素。（2）邊界類是描述系統(tǒng)與參與者之間交互的抽象要素。邊界類只是對信息系統(tǒng)與參與者之間交互的抽象建模，并不表示交互的具體內容及交互界面的具體形式。

（3）控制類是表示信息系統(tǒng)對其他對象實施協(xié)調處理、邏輯運算的抽象要素。3．請根據(jù)下圖所示的概念模型，將其轉換為邏輯模型(即寫出其關系模式)。

編號姓名讀者職業(yè)電話住址郵編*待售圖書*類別單價出版日期書號架位架存冊數(shù)書號書名作者出版社1選書*架存圖書*11書目書單號冊數(shù)折扣率交款標記售書員答：根據(jù)其E-R圖，其關系模式為：

讀者(編號，姓名，職業(yè)，電話，住址，郵編)架存圖書(書號，架位，架存冊數(shù))

待售圖書(書單號，冊數(shù)，折扣率，交款標記，售書員)書目(書號，書名，作者，出版社，出版日期，類別，單價)9.如圖，是在網(wǎng)上商店系統(tǒng)經(jīng)理的用例圖如下：

網(wǎng)上購物系統(tǒng)顧客的功能用例

1.單一職責原則（Single Responsibility Principle, SRP）：

? There should never be more than one reason for a class to change.? 應該有且僅有一個原因引起類的變更 2.里氏替換原則 最正宗的定義：

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.（如果對每一個類型為S的對象o1，都有類型為T的對象o2，使得以T定義的所有程序P在所有的對象o1都代換成o2時，程序P的行為沒有發(fā)生變化，那么類型S是類型T的子類型。）里氏替換原則

通俗講，只要父類出現(xiàn)的地方子類就可以出現(xiàn)，而且替換為子類也不會產(chǎn)生任何錯誤或異常，使用者可能根本就不需要知道是父類還是子類。但是反過來就不行了，有子類出現(xiàn)的地方，父類未必就能適應。3.迪米特法則

迪米特法則的定義：

迪米特法則（Law of Demeter, LoD）也稱為最少知識原則，一個對象應該對其他對象有最少的了解。

一個類應該對自己需要耦合或調用的類知道得最少，被耦合或調用的類的內部如何復雜都和我沒有關系，那是你的事情，我就知道你提供的這么多public方法，我就調用這么多，其他的我一概不關心。4.開閉原則

開閉原則的定義：

一個軟件實體如類、模塊和函數(shù)應該對擴展開放，對修改關閉。

一個軟件實體應該通過擴展來實現(xiàn)變化，而不是通過修改已有的源代碼來實現(xiàn)變化。5.依賴倒置原則

依賴倒置原則包含三層含義：

? 高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象；

? ? 抽象不應該依賴細節(jié)； 細節(jié)應該依賴抽象。

在java語言中，抽象就是指接口或抽象類，兩者都是不能直接被實例化的；細節(jié)就是實現(xiàn)類，實現(xiàn)接口或繼承抽象類而產(chǎn)生的類就是細節(jié)，其特點就是可以直接被實例化，也就是可以加上一個關鍵字new產(chǎn)生一個對象。6.接口隔離原則

接口隔離原則定義：

? ? 客戶端不應該依賴它不需要的接口；

類間的依賴關系應該建立在最小的接口上。

建立單一接口，不要建立臃腫龐大的接口，接口盡量細化，同時接口中的方法盡量少。它要求“盡量使用多個專門的接口”。專門接口指提供給每個模塊的都應該是單一接口，提供給幾個模塊就應該有幾個接口，而不是建立一個龐大的臃腫接口，容納所有的客戶端訪問。

1.在RUP中，軟件開發(fā)生命周期根據(jù)時間和RUP的核心工作流劃分為二維空間。橫軸表示項目的時間維，縱軸以內容來組織為自然的邏輯活動。