壹、 填空題
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）壹致性。與其他軟件需求或高層（系統、業務）需求不相矛盾。
（4）可修改性。便於修改，並且在修改後維護需求的壹致性、完整性和無二義性。
（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．
參與者：管理員，讀者（員工）
用例：新書錄入，書籍查詢，借書登記，還書登記，催還。
電大天堂系統開發規範與文檔編寫形考作業二：
壹、單項選擇題
1．C 2．A 3．B 4．D 5．A
6．B 7．C 8．A 9．D 10．B
二、填空題
1. 數據流圖
2. 過程抽象，數據抽象，控制抽象
3. 分解，抽象
4. 功能，邏輯，狀態
5. 耦合，內聚
6. 體系結構
7. 系統設計目標
8. 變換型數據流圖，事務型數據流圖
9. 詳細設計
10. 算法設計、數據結構設計
11. 圖形工具、表格工具和語言工具
12. 數據結構
13. 結構沖突
三、判斷題
對 錯 錯 對 對
錯 對 錯 對 對
四、簡答題
1．結構化程序設計（SP）方法，最早是由E. W. Dijkstra在20世紀60年代中期提出的，它以下幾個基本要點：
第壹，采用自頂向下、逐步求精的程序設計方法；
第二，使用順序、選擇及重復三種基本控制結構構造程序；
第三，主程序員的組織方式。開發程序的人員應采用以壹個主程序員、壹個後備程序員和壹個程序管理員三人為核心，再加上壹些專家等組成小組。
下圖所給出的是流程圖的五種基本控制結構
2．程序結構描述了整個程序的控制層次關系和各個部分的接口情況，而軟件過程則著重描述各個模塊的處理細節。
軟件過程必須提供精確的處理說明，包括事件的順序、正確的判定點、重復的操作直至數據的組織和結構等等。程序結構與軟件過程是有關系的。對每個模塊的處理必須指明該模塊所在的上下級環境。軟件過程遵從程序結構的主從關系，因此它也是層次化的。
3．信息隱蔽是指每個模塊的實現細節對於其它模塊來說是隱蔽的。就是說，模塊中所包含的信息（包括數據和過程）不允許其它不需要這些信息的模塊使用。
4．結構化方法總的指導原則是自頂向下、逐步求精。它的基本原則是功能的分解與抽象。逐步求精，也稱為自頂向下是指：不要求壹步就編制成可執行的程序，而是分若幹步進行。第壹步編出的程序抽象程度最高，第二步編出的程序抽象程度有所降低，最後壹步編出的程序即為可執行的程序。用這種方法編程，可使程序易讀、易寫、易調試、易維護，也易於保證程序的正確性及驗證其正確性。隨著軟件設計的逐步展開，程序結構中每壹層模塊就體現了過程抽象某壹層次上的壹次細化。
5．軟件總體設計的主要任務是要建立軟件系統的體系結構，即軟件系統要劃分多少模塊，模塊之間的層次結構和調用關系是怎樣的。同時還要設計數據結構和數據庫結構、人機接口等。在概要設計階段需要完成的基本任務，有以下幾個方面：采用某種設計方法，將壹個復雜的系統按功能劃分成模塊的層次結構；確定每個模塊的功能，建立與已確定的軟件需求的對應關系；確定模塊之間的調用關系；確定模塊之間的接口，即模塊之間的信息，設計接口的信息結構；評價模塊劃分的質量及導出模塊結構的規則。
五、應用題
電大天堂系統開發規範與文檔編寫形考作業三：
壹、單項選擇題
1．A 2．D 3．C 4．C 5．D
6．B 7．A 8．B 9．D 10．B
11．A 12．B 13．A 14．A 15．C
二、填空題
1. 操作
2. 信息繼承
3. 屬性，操作
4. 多繼承
5. 整體-部分
6. 多態性
7. 關聯、泛化、依賴和細化
8. 順序
9. 狀態
10. 用例視圖、邏輯視圖
11. 活動圖
三、判斷題
對 對 錯 對 錯
對 錯 錯 錯 錯
四、簡答題
1．對象是構成世界的壹個獨立單元，它具有自己的靜態特征和動態特征。
類是具有相同屬性和操作的壹組對象的集合，它為屬於該類的全部對象提供了統壹的抽象描述，包括屬性和操作兩個部分。
消息是壹個對象與另壹個對象的通信單元，是要求某個對象執行類中定義的某個操作的規格說明。發送給壹個對象的消息定義為壹個操作名和壹個實參數表(可能是空的)。
2．類之間的關系有：關聯；聚集；組成和泛化
關聯表示類與類之間的壹種抽象關系，從說明層觀點看，關聯代表壹種職責；
聚集關系表示類和類之間的整體和部分的關系；
組成關系是另外壹種形式的聚集關系，部分對象僅屬於壹個整體對象，且部分對象與整體對象***存亡；
泛化關系也稱繼承關系。
3．Coad和Yourdon對面向對象給出了壹個定義：“面向對象 = 對象 + 類 + 繼承 + 消息通信”。
面向對象技術是壹個非常實用的軟件開發方法，具有以下特點。第壹，開發方法的唯壹性，即方法是對軟件開發過程所有階段進行綜合考慮而得到的。二是從生存期的壹個階段到下壹個階段的高度連續性，即在壹個階段所用到的部分與在下壹個階段所使用的部分是銜接的，所使用的技術經過生存期每壹階段後不改變。最後，把面向對象分析、面向對象設計和面向對象程序設計集成到生存期的相應階段。
4．用例模型用於系統需求的獲取，描述系統的功能需求。
用例模型的主要成分有用例、參與者和系統。系統被看作壹個提供用例的黑盒，系統如何做、用例如何實現、內部如何工作，這些對用例模型都是不重要的。創建用例模型的工作包括：定義系統，尋找參與者和用例，描述用例，定義用例之間的關系，最後確認模型，用例模型由用例圖組成。
5．面向對象分析的壹般步驟是：
1）獲取用戶對OO系統的需求，包括表示場景或者用例；建造需求模型。
2）為每個系統對象標識屬性和操作。
3）定義組織類的結構和層次。
4）建造對象-關系模型。
5）建造對象-行為模型。
6）使用用例/場景復審OO分析模型
五、應用題
電大天堂系統開發規範與文檔編寫形考作業四：
壹、單項選擇題
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．A 24．B 25．D
26．A 27．C 28．A 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. 風險
23. 文件
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. 註釋從其整體觀感和作用上可以分為兩種：高級註釋：說明程序功能並描述程序各組成部分相互關系；低級註釋：逐行解釋程序指令如何工作。