第一篇：軟件工程與文檔寫作

軟件的開發方法 面向過程的方法特點：程序的執行過程，不由用戶控制，完全由程序員控制。優點：簡單實用。缺點：維護困難。

面向對象的方法 特點：(1).程序的執行過程，不由程序員控制，完全由用戶控制。(2).分析設計時面向類，編程時面向對象。優點：易于維護。缺點：較難掌握。

面向數據的方法特點：程序的執行過程，有時由程序員控制，有時由用戶控制。優點：通俗易懂，適合數據層上的設計與實現。缺點：實現窗口界面較困難。

瀑布模型特點：(1)里程碑或基線驅動(2)過程逆轉性很差；選擇模型的條件：在開發時間內需求沒有或很少變化；分析設計人員對應用領域很熟悉；低風險項目；用戶使用環境很穩定；用戶除提出需求以外，很少參與開發。優點：開發階段清晰，便于評審、跟蹤、管理和控制； 缺點：可維護性差，表現在 由于逆轉性很差，所以返工會造成重大損失；由于文檔驅動，錯誤的傳遞，會采取發散擴大的方式。

增量模型特點：任務或功能模塊驅動，可以分階段提交產品；有多個任務單，這些多個任務單的集合，構成項目的一個總任務書；選擇模型的條件：在開發過程中，客戶接受分階段交付；開發人員對應用領域不熟悉，難以一步到位；工期過緊的中等或高風險項目；用戶可參與到整個軟件開發過程中；使用面向對象語言或第四代語言；軟件公司自己有較好的類庫、構件庫。優點將一個大系統分解為多個小系統，就等于將大風險分解為多個小風險，從而降低開發難度缺點：若軟件系統的組裝和拆卸性不強；或開發人員全局把握水平不高；或者客戶不同意分階段提交產品；或者開發人員過剩，都不宜采用這種模型。

原型模型特點：原型驅動。因此，開發者必須先有一個原型，至少要有一個原型的核心。選擇模型的條件：已有產品/產品原型，只需客戶化的項目；簡單而熟悉的行業或領域；有快速原型開發工具；進行產品移植或升級。優點：開發速度快，用戶意見反饋實時缺點：因為事先有一個展示性的產品原型，所以在一定程度上，不利于開發人員的創新

需求獲取為什么難1.用戶需求具有動態性，即需求的不穩定性。2.用戶需求具有模糊性，即需求不準確性。3.開發者和用戶要對需求達成完全一致的認識，用戶要在需求報告上簽字，要承擔責任。4.中國的國有企業正處在變動期，中國的民營企業正處在成長期。這就給信息系統的需求分析增加了難度系數。

軟件需求的主要屬性：可驗證性（基本）、優先級、唯一性

需求分析的任務1.畫出目標系統的組織結構圖2.畫出目標系統的業務操作流程圖3.畫出目標系統的數據流程圖4.列出目標系統的功能點列表5.列出系統的性能點列表6.列出目標系統的接口列表7.確定目標系統的運行環境8.目標系統的界面約定9.對目標系統的開發工期、費用、開發進度、系統風險等問題進行分析與評估

需求分析的方法：面向功能分析、面向對象分析、面向數據分析

風險分析5種是指對項目及團隊的政策風險、技術風險、技能風險、資源風險等因素，進行逐個分析與分解，制定用于跟蹤和監控風險的風險管理計劃。

模塊耦合程度由低到高的分級如下1.數據耦合(或參數傳遞耦合)，屬于低級別耦合2.控制耦合，屬于中級別耦合3.外部耦合(或共用耦合)，它屬于高級別耦合。4.內容耦合，它屬于最高級別耦合。

軟件建模中的三個模型是指業務模型、功能模型和數據模型。功能模型FM是描述系統能做什么，即對系統的功能、性能、接口和界面進行定義。業務模型OM是描述系統在何時、何地、由何角色、按什么業務規則去做，以及做的步驟或流程，即對系統的操作流程進行定義。數據模型DM是描述系統工作前的數據來自何處，工作中的數據暫存什么地方，工作后的數據放到何處，以及這些數據之間的關聯，即對系統的數據結構進行定義 數據庫設計包括數據庫需求分析、數據庫概念設計、數據庫物理設計三個階段

第一范式：1NF是對屬性的原子性約束，要求屬性具有原子性，不可再分解。

步驟設 計 內 容將原始單據分類整理，理清原始單據與輸出報表之間的數據轉換關系及算法，澄清一切不確定的問題

從原始單據出發，劃分出各個實體，給實體命名，初步分配屬性，標識出主鍵

或外鍵，理清實體之間的關系

進行數據庫概念數據模型CDM設計，畫出實體關系圖ERD，定義完整性約束 2 3步

4步 進行數庫物理數據模型PDM設計.將概念數模型CDM轉換為物理數模型PDM 5步在特定的數據庫管理系統上定義表空間，物理建表與建索引

6步

7步

8步

9步定義觸發器與存儲過程定義視圖，說明數據庫與應用程序之間的關系數據庫加載測試數據庫性能優化

10步數據庫設計評審

軟件實現原則

盡量簡單；易于驗證；適應變化；遵守某一編程規范；選擇項目組成員最熟悉的工具或語言。

測試階段是在代碼編寫完成以后，先作單元測試開始，然后是集成測試、系統測試和驗收測試。軟件測試的分類動態測試；靜態測試，黑盒測試；白盒測試；回歸測試；Alpha測試；Beta測試

客戶化是指按照客戶的實際需求，對軟件產品的功能、性能、接口做適當的改動； 初始化是指按照客戶的實際情況，對軟件產品的代碼表(又稱數據字典)進行初始化，即：將客戶的各種信息編碼錄入到相應的代碼表中。

軟件維護是在軟件產品安裝、實施并交付給用戶使用后，在新版本產品升級之前，這段時間里軟件廠商向客戶提供的服務工作

軟件的4類維護，糾錯性維護、適應性維護、完善性維護、預防性維護

維護副作用修改編碼使編碼更加混亂,程序結構更不清晰,可讀性更差,且有連鎖反應；修改數據結構,數據結構是系統的骨架,修改數據結構是對系統傷筋動骨的大手術，在數據冗余與數據不一致方面，可能顧此失彼；修改用戶數據,需要與用戶協商,一旦有疏忽,可使系統發生意外；修改文檔,對非結構化維護不適應,對結構化維護要嚴防程序與文檔的不匹配

軟件生存周期包括：需求、分析、設計、編碼、測試、運行和維護階段

CMMI5級初始級、重復級、已定義、已管理級、優化級

CMM模型共計18個關鍵過程域KPA，52個具體目標，316個關鍵實踐KP。

軟件配置管理是在開發過程中，將軟件的文檔、程序、數據進行分割與綜合，以利于軟件的定義、標識、跟蹤、管理，使其最終形成受控的軟件版本產品

存取控制通過配置管理中的3個庫來實現軟件開發庫、軟件基線庫、軟件產品庫

經正式評審和審計,并被批準后的階段性的軟件工作產品,稱為軟件配置管理中的一根基線。里程碑只是一個階段標記,基線是一個階段軟件工作產品,基線與里程碑一般表現為一對一的關系。程碑是檢查點,檢查點不一定是里程碑,因為檢查點還可以是時間、計劃和事件。

人們將“質量標準、配置管理、測試測量”，作為質量管理的三大支柱

項目是一次性的多任務工作，它具有確定的開始日期、結束日期、工作范圍、經費預算、質量標準，以及特定的功能、性能和接口要求。

項目管理是運用相關的知識、技能、方法與工具，對實現項目目標所必須做的計劃、進度、質量、成本、資源進行管理和控制的活動。

印度為什么強大？因為它軟件產業發達。為什么發達？原因有五：

1.印度屬于英語國家；2.印度人在美國定居者基本上溶入了美國社會；3.印度人報效祖國，承包美國的外包項目非常多；4.印度政府支持軟件產業，給予一系列優惠政策；5.印度的軟件公司特別重視軟件過程管理。上述五條原因，最重要的一條是用CMMI進行軟件項目管理。

第二篇：軟件工程職業寫作課題報告

《寫作思維》期末報告

軟件程序員工作總結

姓

名

原帥軍

學

院

計算機信息工程學院

班

級

2018級軟件工程二班

學

號

20***

授課教師

劉

慧

時

間

2019-2020

學年第二

學期

一、思路闡述

在開始寫之前我需要熟悉我模擬的人物工作背景和身份，同時圍繞這些條件而寫出文章的基本框架，確定文章的的主題，把握好寫作方向，其次，要確定文章的寫作類型，對整年工作進行總結，再討論這一年的事情對我的影響，以及下一步計劃。

二、具體文案

1.技術

在學校學習的是軟件工程，程序基礎僅限于c語言基礎課程和java以及網頁制作的一些知識，相信從面向過程轉向面向對象的同學都有一種感覺：面向對象開始真的有點別扭，涉及到屬性，尤其是類之間的各種關系，那時想用面向過程傳遞參數多方面。于是老在想對象這種東西，從概念中跳中來，以自己的方式去理解才逐漸體會到頁面對象的精華來，分層次展現、分級別訪問、封裝對象之間各種關系逐漸真正理解了，尤其是對象之間的關系，如對象a與對象b兩者之間的關系，有些需要完全公開，有些需要隱藏，有些需要通過第三方傳遞，有些需要給自己的下級可見，有些需要讓下級去完成具體操作——這不是現實的實際模型嗎？應該這么理解，面向對象來源于現實，它不是一種憑空空想出來的理論，這些對象之間的關系可以將其還原為父子、夫妻、領導下屬、同事、朋友之間的關系。相比之下，頁面過程往往像是一股腦全部推給用戶使用，其中的數據與數據訪問方法層次不清晰，在模擬現實上它與面向對象相比更易于入門理解，實質上難于準確直接地表述。

面向對象上另一方面是它的設計模式，在之前的面向過程中對這個設計模式并沒有清晰地提出來，面向過程優秀的代碼要求高內聚低耦合，從個人的理解上，這僅是對軟件開發方法“技”上理論總結；設計模式是達到了“道”的層次，因為它從更大的方向、更抽象的層次來去表述具體的代碼模塊之間的關系，可以認為設計模式是完全從實際的應用來不斷總結得來的經驗，之間并沒有這種術語，但相信前人肯定也使用到這種思想，它從實際應用于來，當然要應用于實際工作中，認真思考不斷總結每個人都會有自己的“設計模式”，可以借鑒前人的思想來去提升自己，不可去為“設計模式”而設計模式。

2.管理

對于工作責任心不夠的員工是尤其值得關注的，他們往往自我意識過于強烈，追求以自我為中心，很多時候伴隨著工作得不到認可、工作感覺不充實不開心，領導應該主動找他談話，我認識到：你管理的是一個實實在在的人，他不是一臺任你擺布的機器，人會有情緒往往是有心結，找到原因，多加開導，用心去關心每個成員。對于實在不適合在本團隊發展的員工要做好最壞打算。程序員這個職業與現在的大學生具有一致的特征，一個是從天之驕子淪為多余人，一個是從高智商人士成為今天中國通行的“it民工”。另一方面是程序員往往年齡集中在20-25之間的男性中，情緒化、失落感、心理不成熟等一系列問題都會出現。但這個階段的人往往也最易溝通，可塑性也較強，適當的引導、合理的方式會比野蠻的管理效果強上百倍。

3.下一年的規劃

利用工作之余的休息時間加強學習。平時注意收集有關pb方面的資料文件，提高自己的處理新問題和解決新問題的能力，并加強學習java及oa方面的知識，為后期的工作打好基礎。

三、思維導圖

第三篇：軟件工程與實踐課程設計

《軟件工程與實踐》課程設計方案

本課程屬專業必修課，是一門實踐性較強的計算機類課程，授課對象為計算機專業及相關專業的本科生。本課程是對軟件工程課程所述內容的進一步深化與具體應用，通過啟發式教學和大量實例的練習，引導學生完成不同類型系統的分析與設計工作，培養學生關于軟件工程理論的實際運用能力、軟件開發實踐動手與文檔編寫及組織管理能力，同時培養和提高學生在軟件開發過程中的團隊協作精神。

在課程設計過程中必須完成以下一些環節：

1、任務布置與說明，備有多個題目供學生選擇。

2、學生自主分組，并展開軟件項目的選題與論證，要求提交分組項目選題和組織分工。

3、進行可行性研究，編寫可行性分析報告和項目開發計劃，并進行審查。

4、獲取需求，編寫軟件需求規格說明書，并進行審查。

5、進行系統分析和設計，編寫軟件分析設計報告，并進行審查。

6、通過實現系統主要界面來模擬軟件實現，并進行審查。

7、編寫軟件測試計劃，編寫軟件測試分析報告，并進行審查。

8、編寫用戶使用說明書，并進行審查。

可供選擇的課程設計方案：

1、圖書館圖書預定系統的設計與實現

功能如下：（1）由供書部門提供書目給訂購組；（2）訂書組從各單位取得要訂的書目；（3）根據供書目錄和訂書書目產生訂書文檔留底；（4）將訂書信息（包括數目，數量等）反饋給供書單位；（5）將未訂書目通知訂書者；（6）對于重復訂購的書目由系統自動檢查，并把結果反饋給訂書者。

2、網絡考試系統的設計與實現

要求基于B/S模式來構建整個網絡考試系統，整個系統擬由試題庫管理子系統、學籍管理子系統、成績管理子系統、網絡考場四大模塊組成。系統用戶端劃分為學生端、教師端和管理員端，通過數據庫操作權限設定等機制來保證系統及相關數據的安全性。

3、網上購物系統的設計與實現

著重研究、設計與實現用戶管理、目錄管理、信息錄入管理、定單管理、瀏覽和查找、購物結帳等功能。

（1）會員注冊、登錄與管理模塊，包括新會員注冊、會員身份驗證、會員身份注銷和預定制商品。

（2）商品陳列上架模塊，實現商店所有商品的分類上架，供用戶瀏覽選擇。（3）為客戶提供各個商品信息細節展示模塊。

（4）為客戶提供所選擇商品的瀏覽、退貨等管理模塊。（5）購物車模塊，需要完成用戶選購商品，購物訂單生成功能。

4、病員監護系統的設計與實現 I．問題概述

本例為醫院特級護理病房的病員監視系統。1）在每一病床旁有一個監護器。

2）在病員身上附著各種傳感器，監測各種生理參數，諸如血壓、呼吸、體溫等，信號被送到監護器。

3）監護器帶有輸入鍵盤，用以輸入病員的病號的病歷號、各種監測的生理因素的安全范圍值（上下限值），以及監測頻率定期（監測周期）等。

4）各監測部件與中心計算機相連，后者按指定的監測頻率定期地對監視器進行檢查。5）檢查所得到的數據記錄在每個病員的記錄文件上。

6）如果發現病員的生理因數超出安全范圍時，在護理室有各病員的各種報警信號（燈光）出現。

7）每個監視器有一開關，用來控制監測工作。

8）本例中假設監視255個病員，每人設定4個因素。監視周期可從秒到小時變化，對每一病員進行24小時監視。

9）安全范圍為十進制數值，內部表示為浮點數。病歷號為9位整數。II．需要設計實時系統。

首先要確定按適當的頻率監測病員的辦法：一種是用中斷的方法，在每個監測器內設置一個定時器；另一種是對各病員進行巡回監視。

5、學籍管理系統的設計與實現

學生學籍管理系統由三部分組成，分別是學生檔案管理模塊、學生成績管理模塊、學生成績查詢模塊。學生檔案管理模塊主要是對學生檔案(如基本資料、學習情況、學籍變動、備注等)進行管理，本模塊又分為添加學生檔案、查詢學生檔案、修改/刪除學生檔案、打印學生檔案、數據庫管理五個子模塊。學生成績管理模塊主要是由教師對學生成績進行管理，本模塊又分為添加學生、學生管理、成績添加、成績管理、數據庫管理等子模塊。學生成績查詢模塊是指學生通過輸入自己的姓名和密碼登陸成績查詢系統，便可查詢各個科目的考試成績，同時也可以進行密碼修改。要求采用B/S結構，可以對不同角色進行權限管理。

6、內容管理系統的設計與實現

為了讓用戶能夠實現模塊共享，并考慮到安全性，需要開發一個平臺展示模塊的相關信息，并實現用戶申請、模塊的開發者上傳、管理員審核等功能。

該平臺需要完成的功能為：每個用戶可以對模塊的相關信息進行瀏覽，查找，若需要下載某個模塊，可向管理員提出申請；模塊的開發者可以上傳模塊的相關信息；管理員對用戶的申請進行審核。

具體需求如下：

用戶可以對模塊的相關信息進行瀏覽并申請使用某些模塊：

進行注冊、登錄；

能夠對模塊的相關信息進行瀏覽；

可按標題、內容、作者、時間、分類等方式進行查找；

將想要下載使用的模塊記錄下來，待瀏覽完畢后形成申請單，提交給管理員。模塊開發者能夠將自己制作的模塊的相關信息進行上傳：

將模塊的標題、圖片、作者、類別、日期、內容等信息進行上傳。管理員進行管理：

對新注冊的用戶信息進行統計察看；

對用戶的關于模塊使用的申請信息進行統計審核； 對開發者上傳的模塊信息進行統計察看； 對已經批準并提供模塊下載的用戶信息進行統計察看。

7、教學網站的設計與實現

網站主要面向三類人：老師、學生、管理員，包括一個BBS。三類人權限各不相同，老師可以布置作業、修改作業、登記成績；學生則可以通過這個網站看老師的通知、做作業、利用豐富的資源等等；管理員則主要做后臺的一些修改操作； BBS模塊主要用于師生之間、學生之間的交流。

學生端的功能包括：主頁、登入、作業模塊、查詢模塊、個人設置、交流、資料下載、BBS；教師端的功能包括：主頁、登入、查詢、通知管理、作業管理、上機管理、成績管理、收信箱、BBS、個人設置；管理員端包括：主頁、登入、數據初始化、學生管理、教師管理、BBS管理、修改個人信息。

課程設計評分標準：

1、按照參考的范例，完成規定的文檔。

2、2-3人一組，完成同一文檔的學生成績相同。

3、行文流暢，格式標點正確。

4、插圖必須是矢量圖。

5、涉及UML的內容資料必須完整。

6、文檔必須真實反映分析、設計、實現和測試的內容。

7、單獨完成所有文檔的學生加分。

第四篇：軟件工程

1.軟件危機的概念 系統的數據要求，功能需求，性能需求，顯示出程序的輪廓。

軟件危機是指在計算機軟件開發、使用與可靠性需求，可用性需求，出錯處理需求，混合方式

維護過程中遇到的一系列嚴重問題和難接口需求，約束，逆向需求以及將來可能優點：綜合了以上兩種策略的長處 題。提出的需求。9.確認測試

補充： 5.常使用的圖形工具 確認測試又稱有效性測試。有效性測試是

1．軟件危機的表現有哪些？ 實體-聯系圖，數據流圖，狀態轉換圖，在模擬的環境下，運用黑盒測試的方法，答：1）對軟件開發成本和進度的估計常層次方框圖，warnier圖，IPO圖。驗證被測軟件是否滿足需求規格說明書常很不準確。第五章 列出的需求。任務是驗證軟件的功能和性

2）用戶對已完成的軟件不滿意1.總體設計的任務 能及其他特性是否與用戶的要求一致。對的現象時有發生。劃分出組成系統的物理元素——程序、文軟件的功能和性能要求在軟件需求規格

3）軟件產品的質量往往是靠不件、數據庫、人工過程和文檔等等 說明書中已經明確規定，它包含的信息就住的。設計軟件的結構。也就是要確定系統中每是軟件確認測試的基礎。

4）軟件常常是不可維護的。個程序是由哪些模塊組成的，以及這些模10.什么是白盒測試，其測試技術有那些，5）軟件通常沒有適當的文檔資塊相互間的關系。覆蓋標準的強弱程度

料。2.模塊化思想 白盒測試是一種測試用例設計方法，盒子

6）軟件成本在計算機系統總成就是把程序劃分成獨立命名且可獨立訪指的是被測試的軟件，白盒指的是盒子是本中所占比例逐年上升。問的模塊，每個模塊完成一個子功能，把可視的,你清楚盒子內部的東西以及里面

7）軟件開發生產率提高的速度這些模塊集成起來構成一個整體，可以完是如何運作的。“白盒”法全面了解程序內遠跟不上日益增長的軟件需求。成指定的功能滿足用戶的需求。部邏輯結構、對所有邏輯路徑進行測試。

2．產生軟件危機的原因主要有哪些？ 3.衡量模塊獨立的標準（內聚和耦合的白盒測試的測試方法有代碼檢查法、靜態答：1）用戶對軟件需求的描述不精確。含義，種類）結構分析法、靜態質量度量法、邏輯覆蓋

2）軟件開發人員對用戶需求的內聚：標志著每一個模塊內各個元素彼此法、基本路徑測試法、域測試、符號測試、理解有偏差。結合的緊密程度，是信息隱藏和局部化概路徑覆蓋和程序變異。

3）缺乏處理大型軟件項目的經念的自然拓展。偶然內聚，邏輯內聚，時種覆蓋標準：語句覆蓋、判定覆蓋、條件驗。間內聚，功能內聚，順序內聚，通信內聚，覆蓋、判定/條件覆蓋、條件組合覆蓋和

4）開發大型軟件易產生疏漏和過程內聚。路徑覆蓋發現錯誤的能力呈由弱至強的錯誤。耦合：是對一個軟件結構內不同模塊之間變化。

5）缺乏有力的方法學的指導和互連程度的度量。數據耦合，控制耦合，11.什么時候黑盒測試，其測試技術有哪有效的開發工具的支持。特征耦合，公共環境耦合，內容耦合。些，（等價劃分，邊介值分析法）

6）面對日益增長的軟件需求，4.啟發式規則 黑盒測試也稱功能測試，它是通過測試來人們顯得力不從心。1.改進軟件結構提高模塊的獨立性檢測每個功能是否都能正常使用。

2軟件的概念 2.模塊規模應該適中等價類劃分的辦法是把程序的輸入域劃完成特點功能的程序以及數據結構和文 3.深度、寬度、扇出和扇入都應適當 分成若干部分（子集），然后從每個部分檔 4.模塊的作用范圍應在控制范圍之內中選取少數代表性數據作為測試用例

3.軟件工程的基本原理 5.力爭降低模塊接口的復雜程度 邊界值分析是通過選擇等價類邊界的測

1.用分階段的生命周期計劃嚴格管理 6.設計單入口單出口的模塊試用例。邊界值分析法不僅重視輸入條件

2.堅持進行階段評審 7.模塊功能應該可以預測 邊界，而且也必須考慮輸出域邊界。它是

3.實行嚴格的產品控制 5.面向數據流的設計方法把信息流映射對等價類劃分方法的補充。

4.采用現代程序設計技術 成軟件結構 12.軟件調試技術有哪些

5.結果應能清楚地審查 信息流：變換流，事物流 蠻干法，蠻干法可能是尋找軟件錯誤原因

6.開發小組的人員應該少而精 映射：變換分析，事物分析 的最低效的方法，僅當所有其他方法都

7.承認不斷改進軟件工程實踐的必要性失敗的情況下才使用。

4軟件生命周期分成哪幾個階段？各階第六章 回溯法，回溯法是一種相當常用的調試方段的任務是什么？ 1.詳細設計的基本任務 法，當調試小程序時很有效。從發現癥

1.問題定義： 1.為每個模塊確定采用的算法。2.確定狀的地方開始，人工沿程序的控制流往回

2.可行性研究：研究問題的范圍，探索這每一模塊使用的數據結構追蹤分析源程序代碼，知道找出錯誤原因個問題是否值得去解決，是否有可行的解3.確定模塊接口的細節，包括對系統外為止。

決方法。部的接口和用戶界面，對系統內部其 原因排除法，對分查找法、歸納法、演繹

3.需求分析：主要是確定目標系統必須具它模塊的接口，以及關于模塊輸入數據、法都屬于原因排除法。

備哪些功能 輸出數據及局部數據的全部細節。13.軟件可靠性（可靠性和可用性的含義）

4.總體設計： 4.為每一模塊設計出一組測試用例。

5.詳細設計：就是把解法具體化，設計出2.程序的三種基本結構

程序的詳細規格說明。順序結構，選擇結構，循環結構

6.編碼和單元測試：寫出正確的容易理解3.詳細設計的工具

容易維護的程序模塊。1．圖形工具

7.綜合測試：通過各種類型的測試使軟件2．表格工具

達到預定的要求 3．語言工具

8.軟件維護：通過各種必要的維護活動使4.jackson方法

系統持久地滿足用戶的需要。（改正性維5.復雜性度量的方法

護，適應性維護，完善性維護，預防性維Halstead方法：它根據程序中運算符和

護）操作數的總數來度量程序的復雜程度

5.瀑布模型，快速原型模型，增量模型，McCabe方法 ：McCabe方法根據程序控制

螺旋模型的特點 流的復雜程度定量度量程序的復雜程度，瀑布模型階:段時間具有順序性和依賴第七章

性。推遲現實的觀點。質量保證的觀點。1.選擇程序設計語言應考慮哪些因素

快速原型模型:軟件產品的開發基本上是1.系統用戶的要求

線性順序進行的，本質是“快速”加速軟2.可以使用的編譯程序

件的開發過程，節約軟件開發成本。3.可以得到的軟件工具

增量模型:能在較短時間內向用戶提交可4.工程規模

完成部分工作的產品。逐步增加產品功5.程序員的知識

能，可以使用戶有較充裕的時間學習和適6.軟件可移植性要求

應新產品，從而減少一個全新的軟件可能7.軟件的應用領域

給客戶組織帶來的沖擊。2.良好的編程風格包括哪些方面

螺旋模型:對可選方案和約束條件的強調1.程序內部的文檔2.數據說明 3.語句構

有利于已有軟件的重用，也有助于把軟件造4.輸入輸出 5.效率

質量作為軟件開發的一個重要目標。減少3軟件測試的目標

了過多的測試或測試不足帶來的風險。更目的:（1）測試是為了發現程序中的錯誤

重要的是在螺旋模型中維護只是模型的而執行程序的過程；

另一個周期，在維護和開發之間并沒有本（2）好的測試方案是極可能發現迄今為

質區別。風險驅動的。止尚未發現的錯誤的測試方案；

（3）成功的測試是發現了至今為止尚未

第二章 發現的錯誤的測試。

1.可行性研究的目的 定義:為了發現程序中的錯誤而執行程序

就是用最小的代價在盡可能短的時間內的過程。

確定問題是否能夠解決。補充：

補充： 軟件測試步驟 :

可行性研究的步驟 ：(1)模塊測試(2)子系統測試(3)系統

1.復查系統規模和目標。測試(4)驗收測試(5)平行運行

2.研究現有的系統。4.確定測試計劃是在哪個階段制定的3.導出新系統高層邏輯模型。5.黑盒測試和白盒測試的概念

4.進一步定義問題黑盒測試

5.導出和評價供選擇的解法。1把程序看作一個黑盒子，完全不考慮程

6.推薦行動方針序的內部結構和處理過程

7.草擬開發計劃2對程序接口進行測試，檢查程序功能是

8.書寫文檔提交審查 否能按規格說明書的規定正常使用；

程序是否能適當地接受輸入數據并產生

2.系統流程圖的作用 正確的輸出信息；

系統流程圖是描繪物理系統的傳統工具，程序運行過程中能否保持外部信息的完

它用圖形符號來表示系統中的各個部件。整性

它表達了系統中各個元素之間的信息流白盒測試

動的情況。1把程序堪稱裝在一個透明的白盒子里，3.數據流圖的概念 測試者完全知道程序的結構處理算法

數據流圖是一種圖形化技術，它描繪信息2按照程序內部的邏輯測試程序，檢測程

流和數據從移動到輸出的過程中所經受序中的主要執行通路是否都能按的變換。預定要求正確工作

4.數據流圖里面的符號，畫數據流圖。6.測試的步驟及每個步驟形成的文檔

5.數據字典最基本的功能，以及與數據流單元測試：（模塊測試）發現的往往是編

圖的關系。碼和詳細設計的錯誤

最基本的功能：在軟件分析和設計的過程集成測試：著重測試模塊的接口 中給人提供關于數據的描述信息。

關系：數據流圖和數據字典共同構成系統系統測試：發現的往往是軟件設計中的錯的邏輯模型，沒有數據字典，數據流圖就誤，也可能發現需要說明中的錯誤 不嚴格，然而沒有數據流圖，數據字典也驗收測試：（確認測試）往往發現需求說難于發揮作用。只有數據流圖和對數據流明書中的錯誤 圖中每個元素的精確定義放在一起，才能7.漸增式和非漸增式的區別 共同構成系統的規格說明。“非漸增式”，即先獨立地測試每一模塊，第三章 然后將所有這些模塊連接到一起運行； 1.需求分析屬于哪一個階段，任務是什“漸增式”，即在已測試過的N個模塊的么。基礎上再增加一個模塊，再對N十1個模需求分析是軟件定義時期的最后一個階塊進行測試。段.漸增式比非漸增式優越，因為用漸增式，1.確定對系統的綜合要求（功能需求，性如果是“由頂向下”則可利用前面已測試能需求，可靠性和可用性需求，出錯處理過的模塊，而不必另外準備驅動模塊，如需求，接口需求，約束，逆向需求，將來果是“由底向上”，也可利用已測試過的可能提出的要求）模塊，不必再準備樁模塊。漸增式可以較2.分析系統的數據要求早地發現模塊界面之間的錯誤，有利于排3.導出系統的邏輯模型 錯，檢查比較徹底 4.修正系統開發計劃2.需求分析的產品是什么 8.自頂向下，自下而上，以及混合策略的3.面向過程的分析方法主要是建立三類優缺點 模型 自頂向下數據模型（按照用戶的觀點對數據建立的優點：能較早顯示整個程序的輪廓，向用模型，把用戶的數據要求清楚，準確地描戶展示程序的概貌，取得用戶的理解與支述出來。描述了從用戶角度看到的數據，持。缺點：當測試上層模塊時因使用樁它反應了用戶的現實環境，屬性，聯系），模塊較多，很難模擬出真實模塊的全部功功能模型，行為模型（通過描繪系統的狀能，使部分測試內容被迫推遲，只能等待態及引起系統狀態轉換的事件來表示系換上真實模塊后再補充測試。統的行為）由底向上4.軟件需求規格說明書的內容 優點：測試從下層模塊開始，測試設計用通常用自然語言完整，準確，具體地描述例比較容易。缺點：在測試的早期不能

第五篇：《軟件工程》

《軟件工程》課程分析

本課程是軟件技術專業學生必修的一門專業必修課。根據培養軟件開發人員的需要，本課程的任務是使學生通過本課程的學習，了解軟件項目開發和維護的一般過程，掌握軟件開發的傳統方法和最新方法。能在軟件工程的理論指導下，開發一個小型管理系統，為今后從事軟件工程實踐打下良好的基礎。

一、課程分析

（一）教學計劃的制定和教學內容的選取

根據培養應用技能型人才的總目標，制訂本專業教學計劃，課程的教材配套，教學、實驗、實訓、課程設計大綱和指導書等教學文件齊全，近幾年來引入了現代教學技術手段，已初步建設、形成了具有特色的全套課堂教學和實驗教學課件。

根據該課程的基本教學要求和特點，結合學時的安排，從教材的整體內容出發，有側重地進行取舍，篩選出學生必須掌握的基本教學內容，較好地解決了教學中質量與數量的矛盾。

（二）教學方法分析

由于該課程是用于指導軟件開發的，和實踐聯系非常緊密。所以采用了理論聯系實際的方法進行授課。一方面，讓學生模擬軟件公司的項目小組進行軟件開發；一方面，對學生進行適時的理論指導。既調動了學生的積極性，又讓學生了解了該課程的理論內容，收到了一舉兩得的效果。具體教學過程如下：

第一步：模擬軟件公司的開發項目小組，分組，分設角色（項目經理、用戶、需求人員、設計人員、程序員、測試人員、軟件安裝培訓維護人員），確定開發題。讓每個小組的學生聚在一起，在項目經理的組織下通過調研、討論來制定自己小組的開發題目，大家感覺就象在軟件公司實習一樣，非常新鮮，感興趣。每個學生都積極主動的去完成自己應承擔的那部分工作。

第二步：模擬軟件項目開發全過程的各個階段，進行相關的理論授課和實際開發。即對軟件開發的每一階段，首先按照教材內容進行理論授課，然后讓學生參照授課內容進行實際的軟件開發實踐。

在此階段結束后，每班召開一個模擬方案論證會，由各開發小組選出代表上臺講解本組的開發方案，其他同學模擬用戶對開發方案提出意見。由于大家對模擬方案論證會非常感興趣，發言積極踴躍，論證會結束后，每個小組的設計方案都得到了很好的補充和完善。

第三步：學期末各小組提交各自完成的軟件系統及開發文檔，并進行總結演示，由任課教師進行講評。

抽象理論課的教學應理論聯系實際，讓學生在實際應用中掌握抽象的理論，在興趣中學習，達到我們高職的雙向型培養目標。

二、存在的問題與希望

在上述的教學中，雖然實現了理論聯系實際，但也存在著一些問題，比如每個項目小組中總有個別同學存在依賴心理，不參與項目開發，最后抄襲別的同學的項目成果，自己得不到實際的鍛煉，影響了大三的畢業設計和日后的軟件開發。另外，如果該課程只上課，沒有實訓的話，實驗課時太少，學生很難全面完成一個系統的開發。