壹、填空
1.系統軟件、應用軟件
2.流程、方法和工具
3.程序設計階段、程序系統階段和軟件工程階段。
4.規劃、需求分析、設計、編碼、測試、運營和維護。
5.項目管理過程、配置管理過程和質量管理過程
6.瀑布模型，螺旋模型，風險分析
7.結構化設計和編程
8.初始級別，可重復級別
9.需求獲取
10.系統分析師，用戶，軟件開發人員，軟件需求規格。
11.數據流圖，數據字典，結構化語言，決策表，決策樹。
12.決策樹，結構化語言
13.參與者，用例
14.擴展關系、包含關系和泛化關系
二、選擇題
1.B 2。A 3。D 4。C 5。A
6.D 7。D 8。B 9。A 10。B
11.C 12。D 13。C 14。A 15。A
16.D 17。C 18。A 19。C 20。C
三、簡答題
1.軟件工程
軟件工程是用工程學、科學和數學的原理和方法開發和維護計算機軟件的相關技術和管理方法。
2.軟件危機
軟件危機壹般是指計算機軟件在開發、維護和使用過程中遇到的壹系列嚴重問題。
3.軟件危機有哪些表現，原因是什麽？
軟件危機的表現:
從宏觀上講，軟件危機主要是指:
(1)軟件的發展跟不上計算機硬件的發展。
(2)軟件的發展跟不上社會對軟件需求的增長。
從具體的軟件來看，軟件危機是指:
(1)軟件經常不能按期、按預算、按時間完成。
(2)開發出來的軟件用不好，甚至用不久。
軟件危機的原因:
(1)軟件需求分析不足
(2)軟件開發的標準化程度不夠
(3)軟件開發計劃不夠科學。
(4)缺乏軟件評估方法。
4.數據字典
數據字典是對系統中使用的所有數據項和結構的準確定義，以確保開發人員使用統壹的數據定義。數據字典和數據流圖可以清晰地表達數據處理的需求。
5.軟件與其他產品相比有什麽特點？
(1)軟件是壹個邏輯實體，主要是人類腦力勞動的產物，它是抽象的。
(2)軟件復雜。
(3)軟件維護是長期的。
(4)軟件具有高質量的本質。
6.試述軟件工程的基本原理。
(1)分階段生命周期規劃嚴格管理。
(2)堅持階段復習。
(3)實施嚴格的產品控制。
(4)采用現代編程技術。
(5)應明確審查結果。
(6)應明確審查結果。
(7)承認持續改進軟件工程實踐的必要性。
7.瀑布模型的優缺點是什麽？
優點:它在支持結構化軟件開發、控制軟件開發的復雜性和促進軟件開發的工程化方面起著重要的作用。
缺點:首先，瀑布模型要求在軟件開發初期就要明確軟件系統的所有需求，這在實踐中是非常困難甚至不現實的。其次，使用瀑布模型開發軟件，用戶和項目經理必須等待很長時間才能得到軟件的初始版本。如果用戶對軟件提出了很大的改進建議，那麽整個項目將會遭受巨大的損失。
8.壹份優秀的需求陳述有什麽特點？
(1)完整性。需求說明書不能遺漏任何必要的需求信息。目前不能確定的，用“有確認”。
(2)沒有歧義。所有需求陳述的讀者只能有壹個清晰統壹的解釋。
(3)壹致性。它與其他軟件需求或高層(系統、業務)需求不沖突。
④可修改性。易於修改，修改後保持了需求的壹致性、完整性和模糊性。
(5)可追溯性。當進壹步生成和更改文檔時，引用每個需求是很方便的。
9.結構化需求分析方法包括哪些步驟？
(1)研究了現行制度的“物理環境”，得出了現行制度的具體模型。分析當前系統的輸入輸出，系統中的數據如何流經整個系統，畫出系統的數據流圖，用具體的模型表達妳對當前系統的理解。
(2)抽象出與當前系統模型等價的邏輯模型。對具體模型進行抽象，提取其壹般和本質因素，去除那些非本質因素，得到反映系統本質的邏輯模型。
(3)建立目標系統的邏輯模型。要明確當前系統需要做哪些改動，根據新系統要做的改動，參照當前系統的邏輯模型，畫出新的數據流圖。
(4)完善目標系統的邏輯模型。確定目標系統的人機界面，補充壹些沒有詳細考慮的細節。
10.繪制系統的層次數據流圖時需要註意哪些問題？
(1)加工的編號方法。根據流程的序號，應該可以知道流程屬於哪壹層，流程的父圖是從父圖中的哪個流程及時分解出來的。
(2)分解程度。分解應該是自然的，分解後的接口應該清晰有意義。
(3)父圖與子圖的平衡。子圖中的輸入輸出應與父圖中相應的加工輸入輸出保持壹致，以保持數據流的平衡，保證加工過程的連續性和壹致性。
(4)文件的位置。只有當文件成為兩個或兩個以上流程的接口時，才會出現在這壹層和下壹層的數據流圖上。
11.用例模型
用於描述特定系統的用例、參與者和用例-參與者關系的組合。
12.在建立系統的用例模型時，如何確定系統的參與者？
為了有效地找到參與者，必須回答以下問題:
(1)誰是系統的主要用戶，即誰使用系統的主要功能；
(2)誰從系統中獲取信息；
(3)誰向系統提供信息；
(4)誰來管理和維護系統，保證系統的正常運行；
(5)系統需要與哪些其他系統進行交互(包括其他計算機系統或應用程序)；
(6)為了完成系統的功能，需要哪些硬件設備的支持。
13.為了使開發組織能夠嚴格控制軟件項目，在需求變更中應該遵循哪些原則？
(1)仔細評估提議的變更；
(2)選擇合適的人員對變更做出決策；
(3)變更應及時通知所有相關人員；
(4)項目應按照壹定的程序采用需求變更。
四、應用題
1.
(1)圖2中的“租金單據”和“付款單據”是部分單據，不需要繪制。
(2)圖3中缺失的數據流如下:
(a)數據流程從"住戶基本信息檔案"到處理1.1；
(b)處理由1.4輸出的數據流“住戶收費通知”；
(c)處理從1.6輸出的數據流“住房分配表”。
(3)加工2的子圖如下:
2.
參與者:管理員、讀者(員工)
用例:新書錄入、圖書查詢、圖書借閱登記、圖書歸還登記、圖書歸還提醒。
TVU樂園系統開發規範及公文寫作正式考試作業2；
壹、多項選擇題
1.C 2。A 3。B 4。D 5。A
6.B 7。C 8。壹個9。D 10。B
第二，填空
1.數據流圖
2.過程抽象、數據抽象和控制抽象
分解和抽象
4.功能、邏輯和狀態
5.耦合、內聚
6.體系結構
7.系統設計目標
8.轉換數據流圖，事務數據流圖
9.詳細設計
10.算法設計和數據結構設計
11.圖形工具、表格工具和語言工具
12數據結構
13.結構性沖突
三、判斷題
對，錯，對，對
不對，對，不對，對
四、簡答題
1.結構化程序設計方法是由E. W. Dijkstra在20世紀60年代中期首先提出的。它有以下基本要點:
首先，采用自頂向下、分步編程的方法；
其次，使用了三種基本的控制結構構造過程:順序、選擇和重復。
第三，主程序員的組織。開發者應該由壹個主程序員、壹個備份程序員和壹個程序管理員組成，再加上壹些專家。
下圖顯示了流程圖的五種基本控制結構。
2.程序結構描述了整個程序的控制層次和各個部分的接口，而軟件過程則側重於各個模塊的處理細節。
軟件過程必須提供準確的處理指令，包括事件的順序、正確的決策點、重復操作、數據的組織和結構等等。程序結構與軟件過程相關。每個模塊的處理必須標明模塊所處的上下環境。軟件過程遵循程序結構的主從關系，所以也是分層次的。
3.信息隱藏是指對其他模塊隱藏每個模塊的實現細節。也就是說，模塊中包含的信息(包括數據和程序)不允許被其他不需要這些信息的模塊使用。
4.結構化方法總的指導原則是自上而下，逐步細化。其基本原理是功能的分解和抽象。逐步求精，也稱自頂向下，是指不要求壹步編譯壹個可執行程序，而是分幾個步驟進行。第壹步編譯的程序抽象度最高，第二步編譯的程序抽象度較低，最後壹步編譯的程序是可執行程序。用這種方式編程可以使程序易於讀寫、調試和維護，並且容易保證和驗證程序的正確性。隨著軟件設計的逐步發展，程序結構中的每壹層模塊都體現了某種程度的過程抽象的細化。
5.總體軟件設計的主要任務是建立軟件系統的架構，即軟件系統分為多少個模塊，模塊之間的層次結構和調用關系是什麽。同時要設計數據結構、數據庫結構和人機界面。概要設計階段需要完成的基本任務包括以下幾個方面:(1)采用壹定的設計方法，將壹個復雜的系統按照功能劃分為模塊的層次結構；確定各模塊的功能，並與確定的軟件需求建立對應關系；確定模塊之間的調用關系；確定模塊之間的接口，即模塊之間的信息，設計接口的信息結構；評估模塊劃分的質量和派生模塊結構的規則。
動詞 （verb的縮寫）申請問題
TVU樂園系統開發規範及公文寫作正式考試作業三；
壹、多項選擇題
1.A 2。D 3。C 4炸藥。C 5。D
6.B 7。壹個8。B 9。D 10。B
11.A 12。B 13。A 14。A 15。C
第二，填空
1.操作
2.信息繼承
3.屬性，操作
繼承更多
5.整體-部分
6.多態性
7.聯想、概括、依賴和提煉
8.命令
9.狀態
10.用例視圖和邏輯視圖
11.活動圖
三、判斷題
對，對，錯，對
對，錯，錯，錯
四、簡答題
1.物體是構成世界的獨立單位，它有自己的靜態和動態特征。
類是具有相同屬性和操作的對象的集合，它為屬於該類的所有對象提供了統壹的抽象描述，包括屬性和操作。
消息是壹個對象和另壹個對象之間的通信單元，它是壹種規範，要求對象執行類中定義的操作。發送給對象的消息被定義為壹個操作名和壹個參數表(可以是空的)。
2.類之間的關系是:關聯；聚集；構成和概括
關聯表示類之間的抽象關系。從解釋層的角度來看，聯想代表壹種責任。
聚合關系表示類之間的整體和局部關系；
組合關系是聚合關系的另壹種形式，有些對象只屬於壹個整體對象，有些對象和整體對象* * *存活；
泛化關系也叫繼承關系。
3.Coad和Yourdon給出了面向對象的定義:“面向對象=對象類繼承消息通信”。
面向對象技術是壹種非常實用的軟件開發方法，具有以下特點。壹是開發方法的獨特性，即綜合考慮軟件開發過程的各個階段而得出的方法。二是從生命的壹個階段到下壹個階段的高度連續性，即壹個階段使用的零件與下壹個階段使用的零件是相連的，使用的技術在生命的每個階段之後都不會改變。最後，將面向對象分析、面向對象設計和面向對象編程集成到生命周期的相應階段。
4.用例模型用於獲取系統需求和描述系統功能需求。
用例模型的主要組件是用例、參與者和系統。系統被認為是壹個提供用例的黑匣子。如何去做，如何實現用例以及如何在內部工作對於用例模型來說並不重要。創建用例模型的工作包括:定義系統，尋找參與者和用例，描述用例，定義用例之間的關系，最後確認模型。用例模型由用例圖組成。
5.面向對象分析的壹般步驟是:
1)獲取用戶對OO系統的需求，包括表示場景或用例；建立壹個需求模型。
2)識別每個系統對象的屬性和操作。
3)定義組織類的結構和層次結構。
4)建立對象關系模型。
5)建立壹個對象行為模型。
6)用用例/場景回顧OO分析模型。
動詞 （verb的縮寫）申請問題
TVU樂園系統開發及文檔撰寫的規範；
壹、多項選擇題
1.C 2。B 3。D 4。B 5。A
6.C 7。D 8。D 9。B 10。C
11.B 12。D 13。A 14。A 15。C
16.A 17。B 18。A 19。D 20。A
21.D 22。C 23。壹把24。B 25。D
26.壹把27。C 28。壹把29。D 30。A
第二，填空
1.應用技術、管理和監督
2.公司級，項目級，程序員級，應用級。
3.職能基線、分銷基線和產品基線
4.配置項目
5.配置項選擇、配置項命名和描述、配置項訪問
6.基線
7.解決軟件質量問題和技術測試的局限性。
8.黑盒測試和白盒測試
9.表演
10.壹致的
11.軟件開發計劃
12.基線已建立
13.含蓄的
14.軟件質量保證
15.復習；評審和管理評審；試驗
16.軟件規劃、軟件設計和軟件編碼
17.程序
18.程序錯誤
19.靜態和動態
20.結構檢查、流程圖分析和符號執行
21.分析，非分析
22 .風險
文件
24.管理文檔、開發文檔和用戶文檔。
25.程序風格、編寫格式和註釋格式
第三，法官
對，錯，錯，對。
對，對，錯，錯
對對錯對對。
錯對錯對錯對。
錯，錯，錯，對。
錯誤錯誤
四、簡答題
1.需要。原因是:a .配置管理系統是組織內部信息交換的中心；b .軟件配置管理在軟件生命周期的每個開發階段結束時定義壹個特定點作為基線，在整個軟件生命周期中實施變更控制。
2.軟件測試是根據軟件開發各階段的規範和程序的內部結構，即輸入數據及其預期輸出結果，精心設計壹批測試用例，並利用這些測試用例運行程序，發現程序錯誤的過程。
黑盒測試和白盒測試都是驗證程序正確性的壹種方式。黑盒測試不考慮程序的內部結構，只測試程序的外部接口；白盒測試考慮程序的內部結構，根據程序的內部邏輯進行測試。
3.這段話放在用戶手冊裏更合適。此文本應放在“錯誤處理和恢復”部分。
4.功能配置審計——驗證配置項的實際功效與其軟件需求壹致。物理配置審核—確保配置項目符合預期的物理特征，即特定的介質格式。
5.1.人為因素。2.軟件要求。3.發展所有環節的連接。4.測試的局限性。5.質量管理沒有得到足夠的重視。6.軟件開發的非工程化和開發人員的傳統習慣。7.開發沒有規範和標準。8.從技術上解決軟件質量問題的局限性。
6.1.用戶需求的定義。2.技術方法的應用。3.提高軟件開發的工程能力。4.軟件的重用。5.充分發揮每個開發者的能力。6.組織外部力量合作的方法。7.消除無效勞動。8.提高規劃和管理質量。
7.註釋根據其整體感知和功能可分為兩種:高級註釋:解釋程序的功能，描述程序各組成部分之間的關系；低級註釋:逐行解釋程序指令是如何工作的。