軟件工程復習題及答案_第1頁
軟件工程復習題及答案_第2頁
軟件工程復習題及答案_第3頁
軟件工程復習題及答案_第4頁
軟件工程復習題及答案_第5頁
已閱讀5頁,還剩1頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、1 2006-2007-22006-2007-2 軟件工程復習軟件工程復習 一、單項選擇題(20 選 10) 1. 結構化分析的主要描述手段有( B )。 A. 系統(tǒng)流程圖和模塊圖B. 圖、數(shù)據(jù)詞典、加工說明 C. 軟件結構圖、加工說明D. 功能結構圖、加工說明 2. 用于表示模塊間的調(diào)用關系的圖叫(D) 。 APADBSCCN-SDHIPO 3. 在(B)模型中是采用用例驅(qū)動和架構優(yōu)先的策略,使用迭代增量建造方法,軟件“逐漸”被開發(fā)出來的。 A快速原型B. 統(tǒng)一過程C瀑布模型D. 螺旋模型 4. 常用的軟件開發(fā)方法有面向?qū)ο蠓椒?、面? A )方法和面向數(shù)據(jù)方法。 A. 過程 B. 內(nèi)容 C

2、. 用戶 D. 流程 5 從工程管理的角度來看,軟件設計分兩步完成( D )。 A. 系統(tǒng)分析模塊設計B. 詳細設計概要設計 C. 模塊設計詳細設計D. 概要設計詳細設計 6. 程序的三種基本結構是(B) 。 A. 過程、子程序、分程序B順序、條件、循環(huán) C遞歸、堆棧、隊列D調(diào)用、返回、轉(zhuǎn)移 7. 程序的三種基本結構是(B) 。 A. 過程、子程序、分程序B順序、條件、循環(huán) C遞歸、堆棧、隊列D調(diào)用、返回、轉(zhuǎn)移 8. SD 方法衡量模塊結構質(zhì)量的目標是(C) 。 A. 模塊間聯(lián)系緊密,模塊內(nèi)聯(lián)系緊密B. 模塊間聯(lián)系緊密,模塊內(nèi)聯(lián)系松散 C. 模塊間聯(lián)系松散,模塊內(nèi)聯(lián)系緊密D. 模塊間聯(lián)系松散,

3、模塊內(nèi)聯(lián)系松散 9為提高軟件測試的效率,應該(C) 。 A隨機地選取測試數(shù)據(jù)B取一切可能的輸入數(shù)據(jù)作為測試數(shù)據(jù) C在完成編碼后制定軟件測試計劃D選擇發(fā)現(xiàn)錯誤可能性大的數(shù)據(jù)作為測試數(shù)據(jù) 10( D )測試用例發(fā)現(xiàn)錯誤的能力較大。 A.路徑覆蓋 B.條件覆蓋 C.判斷覆蓋 D.條件組合覆蓋 11軟件需求分析應確定的是用戶對軟件的( A )。 A. 功能需求和非功能需求 B. 性能需求C. 非功能需求D. 功能需求 12下列各種圖可用于動態(tài)建模的有( C ) 。 A用例圖B. 類圖C. 序列圖D. 包圖 13軟件過程模型有瀑布模型、( B )、增量模型等。 A. 概念模型 B. 原型模型 C. 邏輯

4、模型 D. 物理模型 14面向?qū)ο蟮姆治龇椒ㄖ饕墙⑷惸P?,?D)。 A. 系統(tǒng)模型、ER 模型、應用模型B. 對象模型、動態(tài)模型、應用模型 C. -模型、對象模型、功能模型D. 對象模型、動態(tài)模型、功能模型 15測試的分析方法是通過分析程序(B)來設計測試用例的方法。 A應用范圍B.內(nèi)部邏輯C.功能D.輸入數(shù)據(jù) 16. 軟件工程是研究軟件(B)的一門工程學科。 A. 數(shù)學B. 開發(fā)與管理C. 運籌學D. 工具 17. 需求分析可以使用許多工具,但(C)是不適合使用的。 A數(shù)據(jù)流圖B.判定表C.PAD 圖D.數(shù)據(jù)字典 18劃分模塊時,一個模塊內(nèi)聚性最好的是(A)。 A. 功能內(nèi)聚 B.

5、過程內(nèi)聚 C. 信息內(nèi)聚 D. 邏輯內(nèi)聚 19軟件可移植性是用來衡量軟件的(D)的重要尺度之一。 A效率B. 質(zhì)量C. 人機關系D. 通用性 20軟件配置管理是在軟件的整個生存周期內(nèi)管理(D)的一組活動。 A程序B.文檔C.變更D.數(shù)據(jù) 二、判定題(20 選 10) 1 統(tǒng)一過程是一種以用戶需求為動力,以對象作為驅(qū)動的模型,適合于面向?qū)ο蟮拈_發(fā)方法。() 2 當模塊中所有成分結合起來完成一項任務,該模塊的內(nèi)聚是偶然內(nèi)聚。() 3SD 方法衡量模塊結構質(zhì)量的目標是模塊間聯(lián)系松散,模塊內(nèi)聯(lián)系緊密() 4當模塊中所有成分結合起來完成一項任務,該模塊的內(nèi)聚是功能內(nèi)聚。() 5在進行需求分析時,就應該同

6、時考慮軟件的可維護性問題。 ( ) 6需求分析可以使用許多工具,但數(shù)據(jù)流圖是不適合使用的。 ( ) 2 7用白盒法測試時,測試用例是根據(jù)程序內(nèi)部邏輯設計的。 () 8一組測試用例是條件覆蓋,則一定是語句覆蓋。() 9用黑盒法測試時,測試用例是根據(jù)程序內(nèi)部邏輯設計的。() 10 因果圖法可以用于系統(tǒng)地設計測試用例。() 11 在了解被測試模塊的內(nèi)部結構或算法的情況下進行測試叫白盒測試。() 12 為提高軟件可移植性,應注意提高軟件的設備獨立性。() 13 在完成測試作業(yè)之后,為縮短源程序長度,應刪去源程序中的注解。() 14 有 GOTO 語句的程序一般無法機械地變成功能等價的無 GOTO 語句

7、的程序。() 15 快速原型模型是一種以用戶需求為動力,以對象作為驅(qū)動的模型,適合于面向?qū)ο蟮拈_發(fā)方法。() 16 好的程序不僅處理速度要快,而且易讀、易修改。() 17 應多使用 GOTO 語句。() 18 系統(tǒng)模塊的內(nèi)聚度應盡可能地小。() 19 信息隱藏原則禁止在模塊外使用在模塊接口說明中所沒有說明的、關于該模塊的信息。() 20 在完成測試作業(yè)之后,為縮短源程序長度,應刪去源程序中的注解。() 三、名詞解釋(十選 5) 四、簡答題(十選 5) 1 1 可行性研究有哪些步驟?可行性研究有哪些步驟? 1) 確定項目規(guī)模和目標; 2)研究現(xiàn)行系統(tǒng)(如果存在) ; 3)建立系統(tǒng)的高級邏輯模型,

8、用系統(tǒng)流程圖或數(shù)據(jù)流圖(DFD 圖)描述; 4)提高實現(xiàn)高層邏輯模型的 各種方案,并對各方案進行評價; 5)推薦可行的方案; 6)編寫可行性報告; 2 2 什么是軟件生存周期?軟件生存周期模型有哪些?什么是軟件生存周期?軟件生存周期模型有哪些? 答:軟件生存周期模型是描述軟件開發(fā)過程中各種活動如何執(zhí)行的模型。 主要模型包括:瀑布模型、增量模型、 螺旋模型、噴泉模型、變換模型和基于知識的模型。 3 3 軟件質(zhì)量保證措施有那些?軟件質(zhì)量保證措施有那些? 1) 以客戶對于質(zhì)量的需求為基礎,對項目開發(fā)周期的各個階段,建立質(zhì)量目標; 2) 定義質(zhì)量度量以衡量項目活動的結果,協(xié)助評價有關的質(zhì)量目標是否達到

9、; 3) 確定質(zhì)量活動; 4) 執(zhí)行已經(jīng)確定的質(zhì)量活動; 5) 評價質(zhì)量 4 4 什么是軟件開發(fā)方法?有哪些主要方法?什么是軟件開發(fā)方法?有哪些主要方法? 答:軟件開發(fā)方法是一種使用早已定義好的技術集及符號表示習慣來組織軟件生產(chǎn)過程的方法,其方法一般描述 成一系列的步驟,每一個步驟都與相應的技術和符號相關。主要方法有: 1) 結構化開發(fā)方法 2) 面向數(shù)據(jù)結構的開發(fā)方法 3) 原型化開發(fā)方法 4) 面向?qū)ο蟮拈_發(fā)方法 5 5 結構化分析的步驟有哪些?結構化分析的步驟有哪些? 1) 建立當前系統(tǒng)的具體模型 2) 抽象出當前系統(tǒng)的邏輯模型 3) 建立目標系統(tǒng)的邏輯模型 4) 為了對目標系統(tǒng)進行完整

10、的描述,考慮人機界面和其他一些問題 6 6 什么是軟件維護?它有哪些類型?什么是軟件維護?它有哪些類型? 軟件維護是指軟件系統(tǒng)交付使用以后,為了改正軟件運行錯誤,或者因新的需求而加入新功能的修改軟件的過程。它 的類型有:完善性維護,適應性維護,糾錯性維護,預防性維護。 7 7 軟件測試的步驟有哪些?軟件測試的步驟有哪些? 1 單元測試,分別完成每個單元的測試任務,以確保每個模塊能正常工作 2 集成測試,把已測試的模塊組裝起來,進 行集成測試 3 確認測試,完成集測試以后,要對開發(fā)工作初期制定的確認準則進行檢驗 4 系統(tǒng)測試,完成確認測試以后, 給出的應該是合格的軟件產(chǎn)品,為了檢驗能否與系統(tǒng)的其

11、他部分協(xié)調(diào)工作,需要進行系統(tǒng)測試 5 驗收測試,檢驗軟件產(chǎn)品 3 質(zhì)量的最后一道工序是驗收測試 8 8 試述用戶界面設計應考慮的因素。試述用戶界面設計應考慮的因素。 答: (1)可實用性。要求使用簡單,用戶界面中所用術語的標準化和一致性,具有 help 功能??焖俚南到y(tǒng)響應和低的 系統(tǒng)成本,具有容錯能力。 (2)靈活性??紤]用戶的特點,能力,知識水平;提供不同的系統(tǒng)響應時間,提供根據(jù)用戶需求制定和修改界面, (3)界面的復雜性與可靠性 9 9 評價模塊分割好壞的標準有哪些?評價模塊分割好壞的標準有哪些? 模塊分割好壞的標準有 2 個定性準則:藕合性和內(nèi)聚性。耦合性用于描述模塊之間聯(lián)系的緊密程度

12、;內(nèi)聚性用于描 述模塊內(nèi)部聯(lián)系的緊密程度。模塊分割時耦合越松越好,內(nèi)聚性愈強愈好 1010 UMLUML 有那些圖?有那些圖? 答:用例圖:從用戶角度描述系統(tǒng)功能,并指出各功能的操作者 靜態(tài)圖:表示系統(tǒng)的靜態(tài)結構,包括類圖,對象圖,包圖 行為圖:描述系統(tǒng)的動態(tài)模型和組成對象間的交互關系,包括狀態(tài)圖,活動圖 交互圖:描述對象間的交互關系,包括順序圖,合作圖 實現(xiàn)圖:用于描述系統(tǒng)的物理實現(xiàn),包括構件圖,部件圖 五、分析設計題(五、分析設計題(4 4 選選 1 1) 1、數(shù)字校園網(wǎng)上考試系統(tǒng)提供給教師的功能如下: (1)登錄 教師通過帳戶和密碼登錄到網(wǎng)上考試系統(tǒng)。 (2)題庫管理 對試題庫進行添加試

13、題、修改試題以及刪除試題等。 (3)試卷生成 教師從試題庫中抽題實現(xiàn)自動組卷或手工組卷,然后存入試卷庫中。 (4)試卷查詢 教師從試卷庫中選出符合要求的試題,被選中的題目將被加入新的試卷中去。 (5)答卷批改 當試卷中存在填空題或問答題,教師需參與答卷評分,系統(tǒng)統(tǒng)計成績存入成績庫。 (6)維護教學大綱 教師可對教學大綱庫中的教學大綱進行維護(修改、增加、刪除等)工作。 要求:畫出詳細的數(shù)據(jù)流圖或用例圖 2 、數(shù)字校園網(wǎng)上考試系統(tǒng)提供給學生的功能如下: (1)登錄:學生通過帳戶和密碼登錄到網(wǎng)上考試系統(tǒng)。 (2)在線練習:學生可以從試題庫中任意選擇各種題型的試題進行解答,系統(tǒng)將給出正確答案供學生參

14、照,并將學生 解答練習情況存入練習庫中。 (3)在線測試:為了對學生的學習效果進行考核,系統(tǒng)可從試卷庫中隨機組好試卷供學生進行考試并計時。考生保存 答卷到答卷庫。成績統(tǒng)計進入成績庫。 (4)在線學習:學生可在網(wǎng)上根據(jù)教學大綱的要求選擇課程庫中的課程進行學習。 (5)成績查詢:提供查詢考試成績功能,并可以查看答卷得分情況。 要求:畫出詳細的數(shù)據(jù)流圖或用例圖 3、圖書管理主要包括三類用戶:讀者、圖書管理員、系統(tǒng)管理員。其中,讀者是多個,圖書管理員是幾個,系統(tǒng)管理 員是一個。對于系統(tǒng),讀者可以查詢自己的借閱情況、分門別類的查詢圖書和在規(guī)定期限內(nèi)續(xù)借不能超過一次操作的 情況下進行自行登錄續(xù)借書等。圖書

15、管理員主要是日常操作以下幾個工作環(huán)節(jié):圖書訂購、新書驗證、書目錄入、圖 書登記、讀者信息管理、借閱書登記、圖書信息注銷和讀者信息注銷等,而系統(tǒng)管理員統(tǒng)籌管理圖書的系統(tǒng)相關事宜, 比如權限維護、日志維護、增刪用戶和管理系統(tǒng)后臺數(shù)據(jù)等。 要求:畫出詳細的數(shù)據(jù)流圖或用例圖 4、廣告管理系統(tǒng)操作業(yè)務人員角色包括:預訂員,財務,劃版員,系統(tǒng)管理員和報刊領導。各個角色承擔不同的系統(tǒng) 任務:預訂員管理預訂、劃版員負責劃版管理、財務員管理財務、業(yè)務員與客戶交流、系統(tǒng)管理員負責系統(tǒng)配置、領 導根據(jù)外部信息源進行決策。經(jīng)初步分析,該系統(tǒng)應該包括預訂子系統(tǒng)、財務子系統(tǒng)、劃版子系統(tǒng)、系統(tǒng)管理子系統(tǒng)、 客戶管理子系統(tǒng)和

16、決策支持子系統(tǒng)。劃版子系統(tǒng)和客戶管理子系統(tǒng)都需要使用財務子系統(tǒng)和預訂子系統(tǒng)的信息;財務 子系統(tǒng)需要使用預訂子系統(tǒng)的信息。 要求:畫出詳細的數(shù)據(jù)流圖或用例圖 六、測試用例設計六、測試用例設計 1、使用邏輯覆蓋測試法測試以下程序: 4 PROCEDURE EXAMPLE(A,B:REAL;VAR X:REAL) ; BEGIN IF(A2)AND(B0) THEN X:XA; IF(A4)OR(X1) THEN X:X1 END; 1)畫出程序流程圖; 2)分別以語句覆蓋、判定覆蓋、判定/條件覆蓋、條件組合覆蓋方法設計用例,并寫出每個測試用例的執(zhí)行路徑。 2、使用邏輯覆蓋測試法測試以下程序: PR

17、OCEDURE EXAMPLE(A,B:REAL;VAR X:REAL) ; BEGIN IF(A=1)OR(B1) THEN X:AB; IF(A2)OR(B=1) THEN X:A-2 END; 1) 畫出程序流程圖; 2) 分別以語句覆蓋、判定覆蓋、判定/條件覆蓋、條件組合覆蓋方法設計用例,并寫出每個測試用例的執(zhí)行路徑。 3、某城市的電話號碼由 3 個部分組成。這 3 個部分的名稱與內(nèi)容分別是: 地區(qū)碼:空白或 3 位數(shù)字 前綴:以大于等于5開頭的 4 位數(shù)字 后綴:4 位數(shù)字 要求:用等價分類法設計它的測試用例。 4、輸入三個數(shù)據(jù),判斷是否能構成三角形? 要求:用等價分類法設計它的測試

18、用例。 七、七、1 1 談談你學習軟件工程的理解和體會。談談你學習軟件工程的理解和體會。 軟件工程這門學科隨著發(fā)展越來越顯得重要,是一個專業(yè)的軟件開發(fā)人員所應該具有的品質(zhì),沒有需求分析就不可以有一個完整而 又經(jīng)濟的軟件出現(xiàn)和發(fā)展!這門學科特別的好,應該好好體會其中的理念,為你個人以后的成長和做人處事都是有幫助的!我們做什么事情都 應該事前做好需求分析才能立二不敗之地!特別你要是一個軟件開發(fā)人員更應該深入體會其中的奧秘! 2 2 談談你對參加需求分析或總體設計的體會。談談你對參加需求分析或總體設計的體會。 需求分析是要決定“做什么,不做什么”。 需求分析為什么困難?有幾種原因使需求分析變得困難:

19、 (1)客戶說不清楚需求; (2)需求 自身經(jīng)常變動; (3)分析人員或客戶理解有誤。 客戶說不清楚需求:有些客戶對需求只有朦朧的感覺,當然說不清楚具體的需求。有些客戶心里非常清楚想要什么,但卻說不明白。 事實上,用簡單的話來說明需求過程,就是確定系統(tǒng)該做些什么以及該符合什么條件。話雖然簡單,實現(xiàn)起來可沒有那么容易。所以 科學的需求過程有一整套完整的理論、工具、方法來實現(xiàn)。 需求分析最重要的是和用戶溝通, 可是用戶多半不是計算機的專業(yè)人士, 如果在需求分析中使用了行話, 就會造成用戶理解上的困難。 再也沒有什么比軟件開發(fā)接近完成時才發(fā)現(xiàn)遺漏了一項需求更糟的事情了。需求的完整性是非常非常重要的,

20、想象一下遺漏需求而不得不 返工,這簡直就是惡夢??墒橇钊诉z憾的是,需求的遺漏是很經(jīng)常發(fā)生的事情,不僅僅是你的問題,更多的問題發(fā)生在用戶那里,他們不 知道該做些什么。要做到需求的完整性是很艱難的一件事情,它涉及到需求分析過程的各方各面,貫穿了整個過程,從最初的計劃制定到 最后的需求評審。 3.談談你進行軟件項目開發(fā)的心得體會。談談你進行軟件項目開發(fā)的心得體會。 一、前期規(guī)劃: 我理解的前期規(guī)劃是:在市場人員們匯總一個需求提交給產(chǎn)品專家?guī)ьI的產(chǎn)品經(jīng)理團隊,然后經(jīng)過這個團隊根據(jù)公司具體情 況再次分析和規(guī)劃出一個最終需求文檔。 這個需求文檔應當首先提交給技術研發(fā)部門的負責人以及核心開發(fā)人員。由開發(fā)團隊

21、對其進行技術和風險分析。如果對此需 求統(tǒng)一有異議的地方,需要返回給產(chǎn)品團隊,重新修正需求。反復如此,直至需求完善準確,細致,清晰。 前期規(guī)劃就像高樓的地基,如果馬馬虎虎,就算是一塊磚塊沒擺好都可能導致整個高樓建設的失敗。在規(guī)劃中我認為,交流 永遠是需要雙方積極主動,能認真聽取每個人的建議。前期工作思維不慎重,不細致,不認真,不夠完善,將產(chǎn)生連鎖效應直接 導致整個工程和項目的失敗。 這種失敗可能表現(xiàn)為:第一種,軟件按需求實現(xiàn)但是功能根本不能滿足用戶需要。第二種,功能都有了,軟件沒有達到可用 性、易用性。 對于第一種,當然是因為前期規(guī)劃疏漏了某些細小功能,沒能把需求文檔做完善。應該是規(guī)劃工作做的還

22、不夠認真和細致。 對于第二種情況,我認為更多是在產(chǎn)品設計規(guī)劃方面經(jīng)驗還不夠成熟。這種問題應該是很難避免的。因為每種新產(chǎn)品對產(chǎn)品 團隊來說都很陌生。即使以前做過類似的東西,也難免面面俱到。這只能通過不斷努力和認真的態(tài)度來彌補。 前期規(guī)劃的交流涉及了市場、產(chǎn)品和技術研發(fā)等多個團隊之間。需要的不僅是團隊內(nèi)部的交流,更多需要協(xié)調(diào)好團隊之間的 交流??赡苡袝r候需要公司高層和中層參與協(xié)調(diào)。 目前,很多開發(fā)人員深感項目的需求文檔寫的都很單薄。大家可以想一想,如果沒有好的開始,怎么會有好的結束呢?需求 文檔單薄,不夠細致,由誰來繼續(xù)完善呢?難道讓程序員們自己去完善。我想程序員也可能沒有這種能力。對于程序員能把

23、代碼 寫的很健壯很穩(wěn)定就已經(jīng)是很不容易的事情了。 5 4 4 談談你參加軟件項目開發(fā)使用工具的心得體會。談談你參加軟件項目開發(fā)使用工具的心得體會。 6-3 解:第 1 步:劃分等價類: 輸入條 件 合理等價 類 不合理 等價類 地區(qū)碼 空白, 3 位數(shù)字 有非數(shù)字字符, 少于 3 為數(shù)字, 多于 3 為 數(shù)字 前綴 200 到 999 之間 有非數(shù)字字符, 起始位為 0, 起始位為 1, 11 少于 3 為數(shù)字,12 多于 3 為數(shù)字 后綴 4 為數(shù)字 13 有非數(shù)字字符, 14 少于 4 位數(shù)字, 15 多于 4 位數(shù)字 第 2 步:設計測試用例: 測試數(shù)據(jù) 測試范 圍 期望結 果 ()12

24、3 - 4567等價類,有效 (123)805 - 9876等價類,有效 (20A)123-4567等價類無效 (33)234-5678等價類無效 (1234)234-4567等價類無效 (123)2B3-1234等價類無效 (123)013-1234等價類無效 (123)123-1234等價類無效 (123)23-1234等價類 11無效 (123)2345-1234等價類 12無效 11 (123)234-1B34等價類 13無效 12 (123)234-34等價類 14無效 13 (123)234-23345等價類 15等價類 15 GUI:人機交互圖形化用戶界面設計GUI 就是屏幕產(chǎn)品

25、的視覺體驗和互動操作部分。 API:應用程序編程接口是一套用來控制 Windows 的各個部件(從桌面的外觀到為一個新進程分配的內(nèi)存)的外觀和行為的一套預先定 義的 Windows 函數(shù).用戶的每個動作都會引發(fā)一個或幾個函數(shù)的運行以告訴 Windows 發(fā)生了什么. CASE:computer assisted software engineering計算機輔助軟件工程幫助進行應用程序開發(fā)的軟件,包括分析、設計和 代碼生成。CASE 工具為設計和文件編制傳統(tǒng)結構編程技術,提供了自動的方法。 IDE:integrated development environment 集成開發(fā)環(huán)境一般包括代碼編

26、輯器、編譯器、調(diào)試器和圖形用戶界面工 具。該程序可以獨立運行,也可以和其它程序并用。 MDA:Model Driven Architecture模型驅(qū)動架構是由 OMG 定義的一個軟件開發(fā)框架。它是一種基于 UML 以及其 他工業(yè)標準的框架,支持軟件設計和模型的可視化、存儲和交換。 OLAP:online analytical processing聯(lián)機分析處理它是快速提供答案給在自然空間中分析查詢的一種方法。 OLTP:online transaction processing聯(lián)機事務處理 RUP:Rational Unified Process 6 UML:Unified Modeling

27、Language標準的統(tǒng)一的圖形化建模語言,是軟件工程中面向?qū)ο蟮哪P头椒ā?XP:xXtreme Programming DD:數(shù)據(jù)字典 詳細描述系統(tǒng)中的全部數(shù)據(jù) DFD:data flow diagrams 數(shù)據(jù)流圖是描述系統(tǒng)中數(shù)據(jù)流圖的圖形工具,它標識了他了一個西用的邏輯輸入和邏輯輸 出,以及把邏輯輸入轉(zhuǎn)換為邏輯輸出所需的加工處理。 ERD:entity-relationship diagram 實體關系圖 CPM: critical path method 關鍵路徑法 CSCW:computer-supported collaborative work PERT: Program Ev

28、aluation Review Technique 計劃評估和評審技術 AEM:Advertising Expenditure Measurement 廣告費用評估 BOM:business object model 業(yè)務對象模型 DOM:domain object model 領域?qū)ο竽P?UP:Unified Process 統(tǒng)一過程 CM:Contact Management 聯(lián)系人管理 EM:Email Management 電子郵件管理 APP:Acquaintance Package Principle 相識包原則 CEP:Cycle Elimination Principle循環(huán)消除原則 CNP:Class Namin

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論