第一篇：軟件工程教案

劉

鵬

《軟件工程》教案

《軟件工程》教學案

一、課程的性質與任務

軟件工程課程是中央廣播電視大學計算機科學與技術專業的統設必修課，4學分，72學時，其中講課46學時，實驗26學時，開設一學期。

軟件工程課程主要研究如何將工程化方法應用于軟件的開發、運行和維護過程之中。根據培養計算機應用型人才的需要，本課程的任務是通過講述軟件的工程化開發方法和相關的開發工具、開發過程、開發規范，使學生了解軟件工程的本質，掌握常用的開發方法，并且能夠自覺地將軟件工程原理靈活地運用于實際的軟件開發和維護過程中，提高學生的專業素質。

二、與本課相關課程

先修課程：計算機基礎、數據庫原理、程序設計語言。

后續課程：畢業設計。

三、課程的學習要求

1．掌握軟件的特點和軟件工程的概念。

2．掌握結構化分析和設計方法。

3.掌握基于UML的面向對象分析和設計方法。

4．理解軟件測試的基本概念和測試策略。

6．理解可行性分析方法和軟件維護的基本方法。

7．了解良好的軟件編程風格和編程規范。

8．了解軟件項目管理、軟件配置管理的概念和方法。

四、課程教學要求的層次

本課程的教學要求分為掌握、理解和了解三個層次。掌握是在理解的基礎上加以靈活應用；理解是能正確表達有關概念和方法的含義，并且能夠進行簡單分析和判斷；了解即能正確判別有關概念和方法。

在期末考核試卷中（涵蓋實驗內容），掌握的內容約占總分數的60%，理解的內容約占30%，了解的內容約占10%。

五、教學環節

1．自學

自學是學生重要的學習手段，要求以文字教材為主，輔以錄像教材、CAI課件、網上教學資源進行學習。錄像教材和CAI課件強化課程的重點、難點內容，實驗的演示與交互，案例分析等，可加深學生對課程內容的理解，提高程序分析和設計能力。網上教學資源與教學進度同步，側重于對學生教學過程的輔導，也是師生、生生溝通的平臺，解決學生在學習過程中遇到的問題。自學可以采取個人和小組學習等方式，學生應注意自學能力的培養，保證必要的自學時間。

2．面授輔導

面授輔導由地方電大輔導教師擔任，由于本課程是一門理論性和實踐性均很強的課程，建議適當增加面授學時比例。各地輔導教師應以文字教材為依據，采用講解、分析、作業講評等方式，講解課程的重點和難點，思路與方法，進行程序設計討論和分析、解答作業、指導實驗等，培養學生學習、思考和分析解決問題的能力。

3．實驗

實驗是本課程的重要組成部分，由地方電大組織實施。學生應認真完成本課程所規定的實驗，未做實驗或實驗不及格者沒有資格參加本課程的期末考試。

4．作業

作業是鞏固和檢驗學習效果的有效手段，中央電大統一下發形成性考核作業冊，學生應根據學習進度認真完成。

5．考核

考核是對學生學習效果的檢查和驗收。本課程的考核采用期末終結性考核和形成性考核相結合的方式。具體考核要求詳見《軟件工程課程考核說明》。

第三部分 教學內容和教學要求

第1章概述

教學內容：

(1)本課程的學習目的、教學內容、學習方法簡介。

(2)軟件的特點、軟件危機現象。

(3)軟件工程定義、軟件工程7條基本原理。

(4)軟件工程發展簡史。

(5)軟件生存周期模型。

(6)軟件工程的相關標準、規范、資料介紹。

教學要求：

(1)掌握軟件的特點，軟件工程定義。

(2)理解軟件工程7條基本原理，軟件危機的現象和軟件生存周期模型。

(3)了解軟件工程發展簡史和軟件工程的相關標準、規范和資料。

第2章可行性研究

教學內容：

(1)可行性研究的任務和可行性分析的基本步驟。

(2)可行性分析要考慮的主要因素。

(3)成本/效益分析。

教學要求：

(1)掌握可行性研究的任務。

(2)理解可行性分析的基本步驟。

(3)了解成本/效益分析的估算模型和可行性分析要考慮的主要因素。

第3章結構化分析

教學內容：

(1)結構化分析的主要任務。

(2)結構化分析的各種工具：系統流程圖、數據流程圖、數據字典、IPO圖、功能結構圖、實體關系圖。

(3)結構化分析的步驟。

(4)需求分析規格說明書模板。

(5)結構化分析的實例——企業設備資產信息管理系統需求分析。

教學要求：

(1)掌握結構化分析的方法和步驟，能夠獨立完成小型系統的結構化分析。

(2)掌握數據流程圖、數據字典的應用。

(3)理解需求分析規格說明書的主要內容。

第4章結構化設計

教學內容：

(1)軟件設計的原則和影響設計的主要因素分析。

(2)結構化設計的基本概念。

(3)結構化設計的方法和步驟。

(4)結構化設計實例——企業設備資產信息管理系統概要設計。

教學要求：

(1)掌握結構化設計的基本概念、方法和步驟。

(2)理解軟件設計的原則。

(3)了解影響軟件設計的主要因素。

第5章面向對象基礎

教學內容：

(1)面向對象基本概念。

(2)軟件建模語言。

(3)常用的UML圖。

(4)RationalRose工具。

教學要求：

(1)掌握面向對象的基本概念。

(2)理解軟件建模語言。

(3)了解常用的UML圖，RationalRose工具。

第6章面向對象分析

教學內容：

(1)基于UML的面向對象分析方法和步驟。

(2)基于UML的面向對象分析實例——企業設備資產信息管理系統需求分析。

(3)基于UML的面向對象需求分析規格說明書模板。

教學要求：

(1)掌握基于UML的面向對象需求分析的方法、步驟。

(2)理解面向對象需求分析和結構化分析之間的本質區別。

(3)了解面向對象需求規格說明書的主要內容。

第7章面向對象設計

教學內容：

(1)面向對象設計的概念。

(2)基于UML的面向對象設計方法和步驟。

(3)基于UML的面向對象設計實例——企業設備資產信息管理系統設計。

(4)基于UML的面向對象設計規格說明書模板。

教學要求：

(1)掌握基于UML的面向對象設計方法和步驟。

(2)理解面向對象設計的概念。

(3)了解基于UML的面向對象設計規格說明書的主要內容。

第8章編程實現

教學內容：

(1)程序設計語言的特點、分類，如何選擇程序設計語言。

(2)良好的編程習慣。

(3)編程標準和過程。

教學要求：

(1)掌握程序設計語言的特點，培養良好的編程習慣。

(2)理解編程標準。

(3)了解選擇程序設計語言的一般原則。

第9章軟件測試

教學內容：

(1)軟件測試的概念。

(2)黑盒測試和白盒測試方法。

(3)單元測試。

(4)集成測試。

(5)系統測試。

(6)驗收測試。

(7)軟件的可靠性分析。

(8)軟件測試工具簡介。

教學要求：

(1)掌握軟件測試的概念。

(2)掌握黑盒測試和白盒測試方法。

(3)理解軟件可靠性分析的方法。

(4)了解軟件測試工具。

第10章軟件維護

教學內容：

(1)軟件維護的基本概念。

(2)軟件維護過程。

(3)提高軟件可維護性的方法。

教學要求：

(1)掌握軟件維護的基本概念。

(2)理解軟件的維護過程。

(3)了解提高軟件可維護性的方法。

第12章軟件工程管理

教學內容：

(1)軟件項目管理介紹。

(2)軟件配置管理介紹。

(3)軟件過程管理介紹。

教學要求：

(1)了解軟件項目管理的基本概念和主要內容。

(2)了解軟件配置管理的基本概念和主要內容。

(3)了解軟件過程管理的主要內容。

第二篇：教案軟件工程導論

授課日期： 11月13日

課程名稱： 軟件工程導論

教學目的：讓學生了解軟件以及軟件危機的概念

了解軟件危機出現的原因以及解決途徑

熟悉軟件工程產生的原因以及其生命周期各個階段的任務 教學重點：軟件危機的出現原因、軟件工程的基本原理、軟件生命周期 教學難點：生命周期各個階段的任務 教學過程：講解軟件的概念

通過軟件危機的表現及原因分析引入軟件工程的基本概念 分析消除軟件危機的途徑 講解軟件工程的基本原理

計算機系統發展迅速，但是人們仍然沒有徹底擺脫“軟件危機”的困擾，軟件已經成為限制計算機系統發展的瓶頸。計算機軟件工程學就是為了研究如何消除軟件危機而發展起來的。那么什么是軟件危機呢？

在開始講軟件危機時我要先提出一個概念：什么是軟件？（板書：軟件危機、什么是軟件）簡單來舉例像我們平時用的word、excel都是計算機軟件。

軟件就是計算機系統中與硬件相互依存的另一部分，它包括程序、相關數據及其說明文檔。（軟件的英文名為Software板書：software=program+data+document）

那它具有什么特性呢？在這里我向大家繪制兩幅圖，大家可以比較討論一下

硬件的失效率剛開始是降低的，這個階段就是磨合調整，通過調整失效率降低并達到一定時期的穩定，那為什么會失效率增高呢，硬件是物理實體它存在磨損用壞的問題。再來看軟件的失效圖像，我繪制了兩條，一條是理想情況下，另一天是實際情況下。大家可以看出來嗎？沒錯，開發出來的軟件并不是永遠有效的，隨著用戶的需求增大等情況失效率會增高。從圖中我們還可以看出在軟件的運行和使用期間，沒有硬件那樣的機械磨損，老化問題。因為軟件是一種邏輯實體，并非具體的物理實體。

另外呢，軟件復雜性很高，軟件技術的發展落后于需求，成本也相當昂貴。

講完軟件的概念，那么軟件危機就比較容易理解了，軟件危機就是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。那么大家思考一下，能夠正常運行的軟件可能會存在軟件危機嗎？答案是可能會。實際上，幾乎所有軟件都不同程度地存在這些問題。比方說，你在用QQ軟件時，它不能與你的計算機硬件環境兼容或是不能滿足你的要求。

總結下來，軟件危機需要應對兩方面的問題：

（1）如何開發軟件，以滿足對軟件日益增長的需求（2）如何維護數量不斷膨脹的已有軟件

軟件危機又有哪些典型表現呢？我們在進行一項工程時是不是經常會有一個工程預算，軟件工程也不例外，如果對軟件開發成本和進度的估計不準確，那么就很容易使用戶不滿。再來如果沒有和用戶進行很好的溝通就著手編寫程序，那么人家也不會滿意；軟件質量靠不住、軟件開發出來是不可維護的，也可以說是不能夠對其功能進行修改適應用戶需求；軟件開發供不應求都是軟件危機的表現。

那么出現軟件危機的原因是什么？在分析原因時我們就通常從內因外因來說，在前面我有講到軟件的特征，軟件復雜度高，成本昂貴等都與軟件危機的出現有關，外因則是由軟件開發和維護的方法不正確有關。

下面我將引入一個問題，大家思考一下，假設你是軟件公司的總工程師，當你告訴自己手下的工程師們及時發現并改正錯誤的重要性時，有人不同意這個觀點，認為要求在錯誤進入軟件之前就清楚它們是不現實的，并且還舉了一個例子：“如果一個故障是編碼錯誤造成的，那么，一個人又怎么能再設計階段就清除他呢？”你同意他的觀點嗎？

答：在軟件開發的不同階段進行修改需要付出的代價是很不一樣的，在早期引入變動，涉及的面比較少，代價也比較低當進入開發中期，軟件配置的許多東西都已經完成，引入一個變動要對所有已完成的配置成分都做相應地修改，不僅工作量大，而且邏輯上海很復雜，代價劇增啊，在軟件已經完成時在引入變動，當然需要付出更大的代價。況且軟件的開發是團體合作，并不是一個人，早發現早解決很重要！

那么如何消除軟件危機呢？這也是我們這門課永恒的課題啊

首先呢我們要對計算機軟件有一個正確的認識，軟件并不等于程序，這是很多學生出的問題

必須充分認識到軟件開發不是某種個體勞動的產物，而應該是一種組織良好、管理嚴密、各類人員協同配合、共同完成的工程項目。也就是我們所說的團隊合作

推廣使用在實踐中總結出來的開發軟件的成功技術和方法 開發和使用更好的軟件工具

那么軟件危機我們就講到這，下面開始介紹軟件工程：

什么是工程？我們平時經常聽到水利工程，建筑工程，工程就是對技術實體的分析、設計、建造、驗證和管理。那么我們知道軟件是一種邏輯產品，看不到摸不著而軟件工程就是把軟件當做一種工業產品，要求采用工程化的原理與方法對軟件進行計劃、開發和維護。是一種新興工程。

如何定義它呢？軟件工程就是為了經濟地獲得可靠地且能再實際機器上高效運行的軟件，而建立和使用完善的工作原理；另一個更全面更具體的定義：軟件工程是把系統的、規范的、可度量的途徑應用于軟件開發、運行和維護過程，也就是把工程應用于軟件。

下面就是本節課的重點，請大家認真聽講。軟件工程的基本原理：

1、用分階段的生命周期計劃嚴格管理 在軟件開發和維護的漫長的生命周期中，需要完成各種任務。因而就應該吧軟件生命周期劃分為若干個階段，并相應地制定出切實可行的計劃，并嚴格計劃開發，維護。

2、堅持進行階段評審

軟件的質量保證工作不能等到編碼階段結束后再進行，那么在每個階段都進行嚴格的評審可以更早的發現在開發過程中的錯誤，及時改正

3、實行嚴格的產品控制

大家都知道軟件開發成本很高，那就意味著不能隨意更改需求。要必須按照嚴格的規程進行評審，獲得批準以后才能實施修改。

4、采用現代程序設計技術

采用先進的技術不僅可以提高軟件開發和維護的效率，而且可以提高軟件產品的質量。

5、結果應能清楚的審查

軟件是看不到摸不著的邏輯產品，應該根據軟件開發項目的總目標及完成期限，規定產品的標準，從而使得所得到的的結果更容易被審查

6、開發小組的人員應該少而精 大家不是都在說人多力量大嗎，何況軟件開發是團隊協作嗎？在這里要注意到人員多交流情況討論問題也會增加，耗時耗力。所以軟件開發小組的組成人員應該要素質高，且不宜過高。

7、承認不斷改進軟件工程實踐的必要性

就是要積極主動的采納新的軟件技術，且要不斷總結經驗。大家可以想象一下，如果開發小組組長是一個固步自封的頑固派，那么后果將不堪設想 下面進行另一個知識點：軟件生命周期

概括地說，軟件生命周期由軟件定義、軟件開發和運行維護3個時期組成，但每個時期又進一步劃分成若干個階段；這里我幫大家總結了一下： 計劃---需求分析---設計---編碼---測試---運行、維護 在這里我解釋一下，在開發軟件時我們要制定計劃，做需求分析了解用戶想利用計算機軟件幫他們解決什么問題然后進行設計它類似于工程師經常使用的工程藍圖，它包含了詳細的設計每個模塊，確定實現模塊功能。接下來就是編碼實現功能，而測試則是使軟件達到預訂的要求，在這里并不是結束我們還要對其進行運行維護持續滿足用戶的需求。

那現在我們來說一下具體的軟件過程

軟件過程是為了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。這就好比我們要建一棟房子，必須要有廚房，臥室吧，那么我們就需要有一個任務表，第一步干什么第二步干什么來完成。軟件過程也是這樣。那有的同學會問我們前面不是講過軟件周期嗎，它不是也規定了先干什么后干什么嗎，對，沒錯，它也是一種過程模型。但實際上要根據項目的特點來劃分階段，這也就引出了我們下面要研究的瀑布模型

大家可以比較一下它和生命周期模型的異同，在下節課我希望大家能夠在課堂上舉手發言。

歸納小結：這節課呢，我們主要講了什么是軟件，軟件具有什么特性，有四點：邏輯實體、成本昂貴、技術落后于需求、復雜度高。在就是軟件危機的相關概念以及為什么出現軟件危機，以及解決軟件危機的途徑，也引入了軟件的生命周期等知識點，望同學課下做好復習。

課后作業：素材32 1、3

第三篇：軟件工程導論教案

計算機系統發展迅速，但是人們仍然沒有徹底擺脫“軟件危機”的困擾，軟件已經成為限制計算機系統發展的瓶頸。計算機軟件工程學就是為了研究如何消除軟件危機而發展起來的。那么什么是軟件危機呢？

在開始講軟件危機時我要先提出一個概念：什么是軟件？（板書：軟件危機、什么是軟件）簡單來舉例像我們平時用的word、excel都是計算機軟件。

軟件就是計算機系統中與硬件相互依存的另一部分，它包括程序、相關數據及其說明文檔。（軟件的英文名為Software板書：software=program+data+document）

那它具有什么特性呢？在這里我向大家繪制兩幅圖，大家可以比較討論一下

硬件的失效率剛開始是降低的，這個階段就是磨合調整，通過調整失效率降低并達到一定時期的穩定，那為什么會失效率增高呢，硬件是物理實體它存在磨損用壞的問題。再來看軟件的失效圖像，我繪制了兩條，一條是理想情況下，另一天是實際情況下。大家可以看出來嗎？沒錯，開發出來的軟件并不是永遠有效的，隨著用戶的需求增大等情況失效率會增高。從圖中我們還可以看出在軟件的運行和使用期間，沒有硬件那樣的機械磨損，老化問題。因為軟件是一種邏輯實體，并非具體的物理實體。

另外呢，軟件復雜性很高，軟件技術的發展落后于需求，成本也相當昂貴。

講完軟件的概念，那么軟件危機就比較容易理解了，軟件危機就是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。那么大家思考一下，能夠正常運行的軟件可能會存在軟件危機嗎？答案是可能會。實際上，幾乎所有軟件都不同程度地存在這些問題。比方說，你在用QQ軟件時，它不能與你的計算機硬件環境兼容或是不能滿足你的要求。總結下來，軟件危機需要應對兩方面的問題：（1）如何開發軟件，以滿足對軟件日益增長的需求（2）如何維護數量不斷膨脹的已有軟件

軟件危機又有哪些典型表現呢？我們在進行一項工程時是不是經常會有一個工程預算，軟件工程也不例外，如果對軟件開發成本和進度的估計不準確，那么就很容易使用戶不滿。再來如果沒有和用戶進行很好的溝通就著手編寫程序，那么人家也不會滿意；軟件質量靠不住、軟件開發出來是不可維護的，也可以說是不能夠對其功能進行修改適應用戶需求；軟件開發供不應求都是軟件危機的表現。

那么出現軟件危機的原因是什么？在分析原因時我們就通常從內因外因來說，在前面我有講到軟件的特征，軟件復雜度高，成本昂貴等都與軟件危機的出現有關，外因則是由軟件開發和維護的方法不正確有關。

下面我將引入一個問題，大家思考一下，假設你是軟件公司的總工程師，當你告訴自己手下的工程師們及時發現并改正錯誤的重要性時，有人不同意這個觀點，認為要求在錯誤進入軟件之前就清楚它們是不現實的，并且還舉了一個例子：“如果一個故障是編碼錯誤造成的，那么，一個人又怎么能再設計階段就清除他呢？”你同意他的觀點嗎？

答：在軟件開發的不同階段進行修改需要付出的代價是很不一樣的，在早期引入變動，涉及的面比較少，代價也比較低當進入開發中期，軟件配置的許多東西都已經完成，引入一個變動要對所有已完成的配置成分都做相應地修改，不僅工作量大，而且邏輯上海很復雜，代價劇增啊，在軟件已經完成時在引入變動，當然需要付出更大的代價。況且軟件的開發是團體合作，并不是一個人，早發現早解決很重要！

那么如何消除軟件危機呢？這也是我們這門課永恒的課題啊

首先呢我們要對計算機軟件有一個正確的認識，軟件并不等于程序，這是很多學生出的問題

必須充分認識到軟件開發不是某種個體勞動的產物，而應該是一種組織良好、管理嚴密、各類人員協同配合、共同完成的工程項目。也就是我們所說的團隊合作

推廣使用在實踐中總結出來的開發軟件的成功技術和方法 開發和使用更好的軟件工具

那么軟件危機我們就講到這，下面開始介紹軟件工程：

什么是工程？我們平時經常聽到水利工程，建筑工程，工程就是對技術實體的分析、設計、建造、驗證和管理。那么我們知道軟件是一種邏輯產品，看不到摸不著而軟件工程就是把軟件當做一種工業產品，要求采用工程化的原理與方法對軟件進行計劃、開發和維護。是一種新興工程。

如何定義它呢？軟件工程就是為了經濟地獲得可靠地且能再實際機器上高效運行的軟件，而建立和使用完善的工作原理；另一個更全面更具體的定義：軟件工程是把系統的、規范的、可度量的途徑應用于軟件開發、運行和維護過程，也就是把工程應用于軟件。

下面就是本節課的重點，請大家認真聽講。軟件工程的基本原理：

1、用分階段的生命周期計劃嚴格管理

在軟件開發和維護的漫長的生命周期中，需要完成各種任務。因而就應該吧軟件生命周期劃分為若干個階段，并相應地制定出切實可行的計劃，并嚴格計劃開發，維護。

2、堅持進行階段評審

軟件的質量保證工作不能等到編碼階段結束后再進行，那么在每個階段都進行嚴格的評審可以更早的發現在開發過程中的錯誤，及時改正

3、實行嚴格的產品控制

大家都知道軟件開發成本很高，那就意味著不能隨意更改需求。要必須按照嚴格的規程進行評審，獲得批準以后才能實施修改。

4、采用現代程序設計技術

采用先進的技術不僅可以提高軟件開發和維護的效率，而且可以提高軟件產品的質量。

5、結果應能清楚的審查

軟件是看不到摸不著的邏輯產品，應該根據軟件開發項目的總目標及完成期限，規定產品的標準，從而使得所得到的的結果更容易被審查

6、開發小組的人員應該少而精

大家不是都在說人多力量大嗎，何況軟件開發是團隊協作嗎？在這里要注意到人員多交流情況討論問題也會增加，耗時耗力。所以軟件開發小組的組成人員應該要素質高，且不宜過高。

7、承認不斷改進軟件工程實踐的必要性

就是要積極主動的采納新的軟件技術，且要不斷總結經驗。大家可以想象一下，如果開發小組組長是一個固步自封的頑固派，那么后果將不堪設想 下面進行另一個知識點：軟件生命周期

概括地說，軟件生命周期由軟件定義、軟件開發和運行維護3個時期組成，但每個時期又進一步劃分成若干個階段；這里我幫大家總結了一下： 計劃---需求分析---設計---編碼---測試---運行、維護

在這里我解釋一下，在開發軟件時我們要制定計劃，做需求分析了解用戶想利用計算機軟件幫他們解決什么問題然后進行設計它類似于工程師經常使用的工程藍圖，它包含了詳細的設計每個模塊，確定實現模塊功能。接下來就是編碼實現功能，而測試則是使軟件達到預訂的要求，在這里并不是結束我們還要對其進行運行維護持續滿足用戶的需求。

第四篇：軟件工程

2.2軟件開發的基本策略

人們都有自己的世界觀和方法論，能自然而然地運用于生活和工作中。同樣，程序員腦子里的軟件工程觀念會無形地支配其怎么去做事情。軟件工程三十年的發展，已經積累了相當多的方法，但這些方法不是嚴密的理論。實踐人員不應該教條地套用方法，更重要的是學會“選擇合適的方法”和“產生新方法”。有謀略才會有好的戰術。幾千年前，我們的祖先就在打鬧之際寫下了很多心得體會，被現代人很好地運用于工業和商業。本節講述軟件開發中的三種基本策略：“復用”、“分而治之”、“優化——折衷”。

2.2.1復用

復用就是指“利用現成的東西”，文人稱之為“拿來主義”。被復用的對象可以是有形的物體，也可以是無形的成果。復用不是人類懶惰的表現而是智慧的表現。因為人類總是在繼承了前人的成果，不斷加以利用、改進或創新后才會進步。所以當我們歡度國慶時，要搞清楚祖國遠不止50歲，我們今天享用到的財富還有上下五千年人民的貢獻。進步只是應該的，不進步則就可恥了。

復用的內涵包括了提高質量與生產率兩者。由經驗可知，在一個新系統中，大部分的內容是成熟的，只有小部分內容是創新的。一般地可以相信成熟的東西總是比較可靠的（即具有高質量），而大量成熟的工作可以通過復用來快速實現（即具有高生產率）。勤勞并且聰明的人們應該把大部分的時間用在小比例的創新工作上，而把小部分的時間用在大比例的成熟工作中，這樣才能把工作做得又快又好。

把復用的思想用于軟件開發，稱為軟件復用。據統計，世上已有1000億多行程序，無數功能被重寫了成千上萬次，真是浪費哪。面向對象（Object Oriented）學者的口頭禪就是“請不要再發明相同的車輪子了”。

將具有一定集成度并可以重復使用的軟件組成單元稱為軟構件(Software Component)。軟件復用可以表述為：構造新的軟件系統可以不必每次從零做起，直接使用已有的軟構件，即可組裝（或加以合理修改）成新的系統。復用方法合理化并簡化了軟件開發過程，減少了總的開發工作量與維護代價，既降低了軟件的成本又提高了生產率。另一方面，由于軟構件是經過反復使用驗證的，自身具有較高的質量。因此由軟構件組成的新系統也具有較高的質量。利用軟構件生產應用軟件的過程如圖1.5所示。

軟件復用不僅要使自己拿來方便，還要讓別人拿去方便，是“拿來拿去主義”。面向對象方法，Microsoft公司的COM規范 [Rogerson 1999]，都能很好地用于實現大規模的軟件復用。

2.2.2分而治之

分而治之是指把一個復雜的問題分解成若干個簡單的問題，然后逐個解決。這種樸素的思想來源于人們生活與工作的經驗，完全適合于技術領域。軟件人員在執行分而治之的時候，應該著重考慮：復雜問題分解后，每個問題能否用程序實現？所有程序最終能否集成為一個軟件系統并有效解決原始的復雜問題？

圖1.6表示了軟件領域的分而治之策略。諸如軟件的體系結構設計、模塊化設計都是分而治之的具體表現。軟件的分而治之不可以“硬分硬治”。不像為了吃一個西瓜或是一只雞，揮刀斬成n塊，再把每塊塞進嘴里粉碎攪拌，然后交由胃腸來消化吸收，象征復雜問題的西瓜或是雞也就此消失了。

2.2.3優化——折衷

軟件的優化是指優化軟件的各個質量因素，如提高運行速度，提高對內存資源的利用率，使用戶界面更加友好，使三維圖形的真實感更強等等。想做好優化工作，首先要讓開發人員都有正確的認識：優化工作不是可有可無的事情，而是必須要做的事情。當優化工作成為一種責任時，程序員才會不斷改進軟件中的算法，數據結構和程序組織，從而提高軟件質量。

著名的3D游戲軟件Quake，能夠在PC機上實時地繪制高度真實感的復雜場景。Quake的開發者能把很多成熟的圖形技術發揮到極致，例如把Bresenham畫線、多邊形裁剪、樹遍歷等算法的速度提高近一個數量級。我第一次看到Quake時不僅感到震動，而且深受打擊。這個PC游戲軟件的技術水平已經遠勝于我所見識到的國內領先的圖形學相關科研成果。這對我們日益盛行的點到完止的研發工作真是莫大的諷刺。所以當我們開發的軟件表現出很多不可救藥的病癥時，不要怨機器差。真的是我們自己沒有把工作做好，寫不好字卻嫌筆鈍。

就假設我們經過思想教育后，精神抖擻，隨時準備為優化工作干上六天七夜。但愿意做并不意味著就能把事情做好。優化工作的復雜之處是很多目標存在千絲萬縷的關系，可謂數不清理還亂。當不能夠使所有的目標都得到優化時，就需要“折衷”策略。

軟件中的折衷策略是指通過協調各個質量因素，實現整體質量的最優。就象黨支部副書記扮演和事佬的角色：“…為了使整個組織具有最好的戰斗力，我們要重用幾個人，照顧一些人，在萬不得已的情況下委屈一批人”。

軟件折衷的重要原則是不能使某一方損失關鍵的職能，更不可以象“舍魚而取熊掌”那樣拋棄一方。例如3D動畫軟件的瓶頸通常是速度，但如果為了提高速度而在程序中取消光照明計算，那么場景就會喪失真實感，3D動畫也就不再有意義了（如果人類全是色盲，計算機圖形學將變得異常簡單）。

人都有惰性，如果允許濫用折衷的話，那么一當碰到困難，人們就會用拆東墻補西墻的方式去折衷，不再下苦功去做有意義的優化。所以我們有必要為折衷制定嚴正的立場：在保證其它因素不差的前提下，使某些因素變得更好。

下面讓我們用“優化——折衷”的策略解決“魚和熊掌不可得兼”的難題。

問題提出：假設魚每千克10元，熊掌每千克一萬元。有個倔脾氣的人只有20元錢，非得要吃上一公斤美妙的“熊掌燒魚”，怎么辦？

解決方案：化9元9角9分錢買999克魚肉，化10元錢買1克熊掌肉，可做一道“熊掌戲魚”菜。剩下的那一分錢還可建立獎勵基金。

2.3一些不正確的觀念

本節例舉并分析一些不正確的軟件工程觀念，可幫助初學者少犯相似的錯誤。

觀念之一：我們擁有一套講述如何開發軟件的書籍，書中充滿了標準與示例，可以幫助我們解決軟件開發中遇到的任何問題。

客觀情況：好的參考書無疑能指導我們的工作。充分利用書籍中的方法、技術和技巧，可以有效地解決軟件開發中大量常見的問題。但實踐者并不能因此依賴于書籍，這是因為：（1）現實的工作中，由于條件千差萬別，即使是相當成熟的軟件工程規范，常常也無法套用。（2）軟件技術日新月異，沒有哪一種軟件標準能長盛不衰。祖傳秘方在某些領域很吃香，而在軟件領域則意味著落后。

觀念之二：我們擁有最好的開發工具、最好的計算機，一定能做出優秀的軟件。

客觀情況：良好的開發環境只是產出成果的必要條件，而不是充分條件。如果擁有好環境的是一群庸人，難保他們不干出南轅北轍的事情。

觀念之三：如果我們落后于計劃，可以增加更多的程序員來解決。

客觀情況：軟件開發不同于傳統的農業生產，人多不見得力量大。如果給落后于計劃的項目增添新手，可能會更加延誤項目。因為：（1）新手會產生很多新的錯誤，使項目混亂。（2）老手向新手解釋工作以及交流思想都要花費時間，使實際開發時間更少。所以科學的項目計劃很重要，不在乎計劃能提前多少，重在恰如其分。如果用“大躍進”的方式奔向共產主義，只會產生倒退的后果。

觀念之四：既然需求分析很困難，不管三七二十一先把軟件做了再說，反正軟件是靈活的，隨時可以修改。

客觀情況：對需求把握得越準確，軟件的修修補補就越少。有些需求在一開始時很難確定，在開發過程中要不斷地加以改正。軟件修改越早代價越少，修改越晚代價越大，就跟治病一樣道理。

2.4一些有爭議的觀念

本節探討一些有爭議的觀念，目的不在于得出“正確”或“錯誤”的評斷，而在于爭議會激發更多理性的思考。

爭議之一：如果軟件運行較慢，是換一臺更快的計算機，還是設計一種更快的算法？

作者觀點：如果開發軟件的目的是為了學習或是研究，那么應該設計一種更快的算法。如果該軟件已經用于商業，則需謹慎考慮：若換一臺更快的計算機能解決問題，則是最快的解決方案。改進算法雖然可以從根本上提高軟件的運行速度，但可能引入錯誤以及延誤進程。技術狂毫無疑問會選擇后者，因為他們覺得放棄任何可以優化的機會就等于犯罪。

類似的爭議還有：是買現成的程序，還是徹底自己開發？技術人員和商業人士常常會有不同的選擇。

爭議之二：有最好的軟件工程方法，最好的編程語言嗎？

作者觀點：在軟件領域永遠沒有最好的，只有更好的。能解決問題的都是好方法或是好語言。程序員在最初學習Basic、Fortran、Pascal、C、C++等語言時會感覺一個比一個好，不免有喜新厭舊之舉。而如今 的Visual Basic、Delphi、Visual C++、Java等語言各有所長，真的難分優劣。開發人員應該根據客觀條件，選擇自己熟悉的方法和語言，才能保證合格的質量與生產率。

程序設計是自由與快樂的事情，不要發誓忠于某某主義而自尋煩惱。

爭議之三：編程時是否應該多使用技巧？

作者觀點：就軟件開發而言，技巧的優點在于能另辟蹊徑地解決一些問題，缺點是技巧并不為人熟知。若在程序中用太多的技巧，可能會留下隱患，別人也難以理解程序。鑒于一個局部的優點對整個系統而言是微不足道的，而一個錯誤則可能是致命的。作者建議用自然的方式編程，少用技巧。

《狼三則》的故事告訴我們“失敗的技巧通常是技倆”。當我們在編程時無法判斷是用了技巧還是用了技倆，那就少用。《賣油翁》的故事又告訴我們“熟能生巧”，表明技巧是自然而然產生的，而不是賣弄出來的。賣油翁的絕技是可到中央電視臺表演的，而他老人家卻謙虛地說：“沒啥沒啥，用熟了而已”。

爭議之四：軟件中的錯誤是否可按嚴重程度分等級？

作者觀點：在定量分析時，可以將錯誤分等級，以便于管理。微軟的一些開發小組將錯誤分成四個等級 [Cusumano 1996]，如表1.1所示。

一級嚴重：錯誤導致軟件崩潰。

二級嚴重：錯誤導致一個特性不能運行并且沒有替代方案。

三級嚴重：錯誤導致一個特性不能運行但有替代方案。

四級嚴重：錯誤是表面化的或是微小的。

表1.1 錯誤的四個等級

上述分類是非常技術性的，并不是普適的。假設某個財務軟件有兩個錯誤：錯誤A使該軟件死掉，錯誤B導致工資計算錯誤。按表1.1分類，錯誤A屬一級嚴重，錯誤B屬二級嚴重。但事實上B要比A嚴重。工資算多了或者算少了，將會使老板或員工遭受經濟損失。而錯誤A只使操作員感到厭煩，并沒有造成經濟損失。另一個示例是操作手冊寫錯，按表1.1分類則屬四級嚴重，但這種錯誤可能導致機毀人亡。

開發人員應該意識到：所有的錯誤都是嚴重的，不存在微不足道的錯誤。這樣才能少犯錯誤。

2.5小 結

軟件工程學科發展到今天，已經有了很多方法和規范，學之不盡。本章只在宏觀上討論了軟件工程的一些

思想，更具體的內容將在后面的章節論述。無論是什么好方法，貴在理解與靈活運用，而不可當成靈丹妙藥，不象“吃了腦黃金或腦白金，就能使一億人先聰明起來”。

3程序員與程序經理

工作在第一線的軟件開發人員是程序員和程序經理，他們決定著軟件的命運。良好的程序員隊伍和出色的管理是軟件項目成功的必要條件。管理不是管制，不是去卡住人家的脖子，因為程序員不是一群野鴨子。管理的目的是讓大家一起把工作做好，并且讓各人獲得各自的快樂和滿足。當一個組織被出色地領導時，雇員甚至不知道他們已被領導。在項目完成時，他們會自豪地說：“看看我們通過努力取得的成績吧”。所以管理者不能老惦記著自己是一個官，而應時刻意識到自己是責任的主要承擔者。

我們經常會聽到有經理頭銜的人在高談闊論：“編程我不會，做個項目還不easy？派個人去搞系統分析，回頭再叫幾個程序員把需求譯成程序，不就OK了嗎？”

不懂英語的人準以為easy和OK是貶義詞。要讓軟件項目失敗很容易，只要符合下列條件之一即可：

（1）項目經理對軟件一無所知；

（2）技術負責人對編程不感興趣；

（3）真真編寫代碼的程序員是臨時雇用的。

如果上述三個條件同時具備，就請放心失敗好了。

讓我們少幻想自己是比爾·蓋茨，先當好程序員和程序經理再說。

3.1了解程序員

早期的程序員干活能從軟件直通硬件，個個生猛無比。又因他們的作息時間、言行舉止與常人不太一樣，久而久之就給人們留下了“神秘”、“孤僻”的印象。如今軟件行業被炒得熱火朝天，有能耐的程序員即便躲在大山岙的軍工廠里也能被挖出來。而更多原本不是程序員的人操起幾本“速成”、“二十一天通”等書籍也加入了這個行業。現在國內號稱有上百萬程序員，這支大軍魚龍混雜，已搞不清那些是正規軍，那些是民兵游擊隊了。

第五篇：《軟件工程》

《軟件工程》課程分析

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

一、課程分析

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

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

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

（二）教學方法分析

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

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

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

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

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

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

二、存在的問題與希望

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