軟件是計算機系統中與硬件相互依存的另一部分，它是包括程序，數據及其相關(guān)文檔的完整集合。注意與廣義軟件概念的區別（P1）。 程序是按事先設計的功能和性能要求執行的指令序列數據是使程序能正常操縱信息的數據結構 文檔是與程序開(kāi)發(fā)，維護和使用有關(guān)的圖文材料
軟件的特點(diǎn). 軟件是一種邏輯實(shí)體，而不是具體的物理實(shí)體。因而它具有抽象性 軟件的生產(chǎn)與硬件不同，在它的開(kāi)發(fā)過(guò)程中沒(méi)有明顯的制造過(guò)程，可以復制， 軟件的開(kāi)發(fā)和運行常受到計算機系統的限制，對計算機系統有著(zhù)不同程度的依賴(lài)性 軟件的開(kāi)發(fā)至今尚未完全擺脫手工藝的開(kāi)發(fā)方式 本身復雜 且 成本昂貴。
軟件功能分：系統，支撐，應用軟件。
軟件生存期的六個(gè)步驟，即制定計劃（確定要開(kāi)發(fā)軟件系統的總目標，給出功能、性能、可靠性以及接口等方面的要求，完成該軟件任務(wù)的可行性研究，制定出完成開(kāi)發(fā)任務(wù)的實(shí)施計劃）、需求分析（對待開(kāi)發(fā)軟件提出的需求進(jìn)行分析并給出詳細的定義）、設計（把各項需求轉換成軟件的體系結構，對每個(gè)模塊要完成的工作進(jìn)行具體的描述，為源程序編寫(xiě)打下基礎）、程序編碼（把軟件設計轉換成計算機可以接受的程序代碼）、測試（通過(guò)單元模塊測試和組裝測試，對各項需求進(jìn)行有效性測試）及運行維護 （改正性維護 適應性維護 完善性維護 ）
軟件：程序和所有使程序正確運行所需要的相關(guān)文檔和配置信息。
軟件工程：是一門(mén)工程學(xué)科，不僅涉及軟件開(kāi)發(fā)，也涉及軟件項目管理、支持軟件生產(chǎn)的工具、方法和理論的開(kāi)發(fā)等活動(dòng)。
軟件過(guò)程：指制作軟件產(chǎn)品的一組活動(dòng)及其結果。包括軟件描述（對軟件及其操作的一些約束）軟件開(kāi)發(fā)（軟件設計和編程實(shí)現）軟件有效性驗證（檢查保證客戶(hù)所需）軟件進(jìn)化（隨不同客戶(hù)和變化市場(chǎng)做修改）
軟件過(guò)程模型:從一特定角度提出的軟件過(guò)程的簡(jiǎn)化描述。1工作流模型（描述軟件過(guò)程中各種活動(dòng)的序列及其輸入輸出和相互依賴(lài)性）2數據流或活動(dòng)模型（軟件過(guò)程描述成一組活動(dòng)，每個(gè)活動(dòng)完成一定數據轉換）3角色/動(dòng)作模型（描述參與人員的不同角色和各自負責的活動(dòng)）
CASE是計算機輔助軟件工程的簡(jiǎn)寫(xiě)。它包括很多種類(lèi)的軟件工具，覆蓋面很廣，包括支持阮娟過(guò)程活動(dòng)，如需求分析、系統建模、調試和測試等。
1瀑布模型：采用一些基本過(guò)程活動(dòng)，并且使用單獨的過(guò)程階段表現活動(dòng)。包括：需求分析和定義（通過(guò)咨詢(xún)系統用戶(hù)建立系統的服務(wù)、約束和目標）系統和軟件設計（系統設計區分硬件和軟件系統的需求，軟件設計包括識別和描述一些基本的軟件系統的抽象及其之間的關(guān)系）實(shí)現和單元測試（檢驗每個(gè)單元是否符合描述）集成和系統測試（對系統整體測試確保滿(mǎn)足需求）運行和維護。優(yōu)勢在于每個(gè)階段生成文檔，并且與其他模型相一致，問(wèn)題在于將項目生硬分解成這些確切的階段。委托事項一定要在過(guò)程的早期階段清晰給出，意味它難以響應用戶(hù)需求的變更。
2迭代式模型：是軟件描述、開(kāi)發(fā)和有效性驗證活動(dòng)交替進(jìn)行的開(kāi)發(fā)方法。先開(kāi)發(fā)出一個(gè)原型給用戶(hù)使用，通過(guò)用戶(hù)反饋意見(jiàn)不斷修改系統直到最后成熟?；绢?lèi)型（探索式開(kāi)發(fā)和拋棄式原型）優(yōu)勢在于讓開(kāi)發(fā)活動(dòng)都能得到快速的反饋信息，缺點(diǎn)在于1過(guò)程不可見(jiàn)（管理者要經(jīng)常性交付把握進(jìn)度）2系統結構通常較差（連續的變更損壞系統結構）
3基于組件的軟件工程（CBSE ）假定系統的各個(gè)組件已經(jīng)存在，開(kāi)發(fā)過(guò)程焦點(diǎn)在于集成這些組件。階段：組件分析（給出需求描述，然后搜索能滿(mǎn)足需求的組件）需求修改（修改需求以反映可得到的組件）使用復用的系統設計（開(kāi)始設計系統的框架）開(kāi)發(fā)和集成（集成開(kāi)發(fā)的組件和現成的組件使之成為整體）優(yōu)勢在于減少需要開(kāi)發(fā)的軟件數量，降低軟件開(kāi)發(fā)成本和風(fēng)險。缺點(diǎn)在于需求妥協(xié)的不可避免，對系統進(jìn)化的控制不起作用。
Rational統一過(guò)程：是一個(gè)階段化了的模型，識別出軟件過(guò)程當中的四個(gè)階段——開(kāi)端（目標是建立系統的一個(gè)業(yè)務(wù)案例）細化（增進(jìn)對問(wèn)題域的理解，建立系統的體系框架）構造（關(guān)心系統設計、編程和測試）轉換（關(guān)注如何將系統從開(kāi)發(fā)單位轉移到用戶(hù)單位使之在真實(shí)環(huán)境工作）九個(gè)工作流 ——業(yè)務(wù)建模（用業(yè)務(wù)用例對業(yè)務(wù)過(guò)程建模）需求（完成對系統需求的建模）分析和設計（使用體系結構模型、組件模型、對象模型和序列模型來(lái)創(chuàng )建并記錄設計模型）實(shí)現（實(shí)現系統中的組件并將他們合理安排在子系統中）測試（它的執行與實(shí)現緊密聯(lián)系）部署（創(chuàng )建和分發(fā)產(chǎn)品版本并安裝到他們的工作場(chǎng)所）配置和變更管理（支持工作流管理對系統的變更）項目管理（支持工作流管理系統開(kāi)發(fā)）環(huán)境（用于提供軟件開(kāi)發(fā)團隊可用的合適軟件工具）六個(gè)基本實(shí)踐（反復的開(kāi)發(fā)軟件、管理需求、使用基于組件的體系結構、可視化模型軟件、驗證軟件質(zhì)量、控制對軟件的變更）
軟件系統需求常常分為功能需求、非功能需求和領(lǐng)域需求。1功能需求——包括對系統應該提供的服務(wù)、如何對輸入作出反應以及系統在特定條件下的行為的描述。應該即、既全面（用戶(hù)所需服務(wù)都給出描述）又具有一致性（描述不能前后矛盾）2非功能需求——對系統提供的服務(wù)或功能給出的約束。分類(lèi)：產(chǎn)品需求（敘述產(chǎn)品行為的需求，包括可移植性和可用性需求）機構需求（起源于客戶(hù)所在的機構和開(kāi)發(fā)者所在的機構中的政策和規定）外部需求（包括所有系統外部因素和開(kāi)發(fā)過(guò)程，如操作、法律、道德需求）3領(lǐng)域需求——來(lái)自系統的應用領(lǐng)域的需求，反映該領(lǐng)域的特點(diǎn)。
用戶(hù)需求是從用戶(hù)角度來(lái)描述系統功能和非功能需求，以便讓不具備專(zhuān)業(yè)技術(shù)知識的用戶(hù)能看懂。編寫(xiě)用戶(hù)需求的一些原則：1設計一個(gè)標準的格式，保證所有的需求定義按照該格式書(shū)寫(xiě)。2使用一致的語(yǔ)言。定義強制性需求要使用“必須”；定義希望性需求時(shí)使用“應該”。3對文本加亮來(lái)突出顯示關(guān)鍵性需求。4盡量避免用計算機專(zhuān)業(yè)術(shù)語(yǔ)。
系統需求：是用戶(hù)需求的擴展版，是軟件工程師開(kāi)始系統設計的起點(diǎn)。僅僅描述系統的外部行為和對它的操作上的限制，而不包括系統應該如何設計和實(shí)現。
信息持有者（對系統需求有直接或間接影響力的人）
需求導入和分析：軟件開(kāi)發(fā)技術(shù)人員要和客戶(hù)及系統最終用戶(hù)一起調查應用領(lǐng)域。包括：需求發(fā)現（收集準備建立的系統和正在使用的系統的信息，并從這些信息當中提取用戶(hù)和系統的需求）需求分類(lèi)和組織、優(yōu)先排序和沖突解決、需求文檔編制（記錄需求并將它作為螺旋下一循環(huán)的輸入，產(chǎn)生形式化的或非形式化的需求文檔）
視點(diǎn)：需求工程的面向視點(diǎn)的方法將導出過(guò)程和需求本身都用視點(diǎn)來(lái)組織。1交互者視點(diǎn)（代表與系統直接交互的人或其他系統）2間接視點(diǎn)（代表那些不使用系統本身但是以某種方式影響需求的信息持有者）3領(lǐng)域視點(diǎn)（代表領(lǐng)域和影響系統需求的那些約束）
場(chǎng)景：描述人如何與一個(gè)軟件系統交互。
用例：是一種基于場(chǎng)景的需求導出技術(shù)，識別與系統的單個(gè)交互。
需求管理是一個(gè)對系統需求變更了解和控制的過(guò)程，需要跟蹤各個(gè)需求并維護他們與所依賴(lài)需求之間的關(guān)聯(lián)關(guān)系。分持久和易變的需求。
在需求管理階段，必須決定一下內容——需求識別、需求管理過(guò)程、可追溯策略、CASE工具支持。3類(lèi)可追溯信息：1源可追溯性信息連接需求到提出需求的信息持有者和這些需求的基本原理2需求可追溯性信息連接需求文檔中 依賴(lài)的需求3設計可追溯性信息連接需求到其實(shí)現的設計模塊。需求變更管理三個(gè)階段：1問(wèn)題分析和變更描述階段（要對問(wèn)題或變更提議進(jìn)行分析以檢查它的有效性）2變更分析和成本計算（對被提議的變更產(chǎn)生的影響進(jìn)行評估并且估計系統設計和實(shí)現的成本）3變更實(shí)現。
體系結構設計是設法建立一個(gè)系統組成來(lái)滿(mǎn)足功能性和非功能性需求。
所開(kāi)發(fā)的體系結構模型會(huì )包括：靜態(tài)結構模型（給出子系統或組件，將其作為一個(gè)個(gè)獨立的單元開(kāi)發(fā)）動(dòng)態(tài)過(guò)程模型（給出系統在運行時(shí)的過(guò)程組成）接口模型（定義每個(gè)子系統從它們的公共接口能得到服務(wù)）關(guān)系模型（給出如子系統間的數據流這樣的關(guān)系）分布模型（給出子系統在多臺計算機上是如何分布的）
模塊化分解：將子系統分解為模塊，有兩種策略：1 面向對象的分解（將系統分解為一組相互通信的對象）一個(gè)面向對象的系統體系結構模型是將系統看成一組松散的對象結合，這些對象都有良好的接口定義，對象請求其他對象提供的服務(wù)。優(yōu)勢在于其對象間是松散耦合的，對對象實(shí)現的修改可以不影響其他對象，缺點(diǎn)在于對象必須明確地給出引用的其他對象的名字及其接口。2 面向功能的流水線(xiàn)操作（將系統分解為一些功能模塊，這些功能模塊接受輸入并轉換它們?yōu)檩敵鰯祿┖锰幵谟?支持換換的復用2直觀(guān)，能將它們的工作理解成輸入輸出處理3可以簡(jiǎn)單的再系統中增加新的轉換4無(wú)論作為順序的還是并發(fā)的系統，其實(shí)現容易。其主要缺點(diǎn)是需要一種適合于所有轉換的通用格式。
數據處理系統是批處理系統，數據的輸入和輸出時(shí)成批地從文件或數據庫中取出或存入，而不是對用戶(hù)終端進(jìn)行輸入和輸出。 形成輸入—處理—輸出結構。
事務(wù)處理系統是設計用來(lái)處理用戶(hù)對數據庫信息的查詢(xún)或者請求更新數據庫的。
快速軟件開(kāi)發(fā)的原因：新的軟件需要快速開(kāi)發(fā)來(lái)順應新的的機遇，響應競爭壓力。事實(shí)上很多業(yè)務(wù)都寧愿犧牲一些軟件的質(zhì)量并降低某些需求來(lái)贏(yíng)得快速軟件移交。還因為業(yè)務(wù)運營(yíng)于一個(gè)變化的環(huán)境中，因此實(shí)際上通常不可能導出一個(gè)完全的穩定的軟件需求。
基本特征：1描述、設計和實(shí)現過(guò)程是并發(fā)的2系統通過(guò)一系列增量開(kāi)發(fā)出來(lái)3系統用戶(hù)界面通常是采用交互式開(kāi)發(fā)系統開(kāi)發(fā)的。
敏捷方法的基本原則：客戶(hù)參與（客戶(hù)應該在開(kāi)發(fā)過(guò)程中始終緊密參與其中）增量式移交（軟件以增量的方式進(jìn)行開(kāi)發(fā)，客戶(hù)指定每個(gè)增量中的包含需求）人非過(guò)程（開(kāi)發(fā)團隊的技術(shù)應該得到承認和發(fā)揚）接收變更（設計系統使之適應這些變更）保持簡(jiǎn)單性（致力于所開(kāi)發(fā)的軟件和開(kāi)發(fā)過(guò)程的簡(jiǎn)單性）
極限編程的經(jīng)驗：增量式規劃（需求記錄在腳本上，開(kāi)發(fā)者將腳本分解為開(kāi)發(fā)任務(wù)）小版本（首先開(kāi)發(fā)能提供業(yè)務(wù)價(jià)值的一個(gè)最小有用集合）簡(jiǎn)單設計（只進(jìn)行有限需求設計）測試優(yōu)先開(kāi)發(fā)（功能實(shí)現之前，采用一個(gè)自動(dòng)單元測試框架來(lái)書(shū)寫(xiě)此新功能的測試）重構（保持代碼簡(jiǎn)單和可維護性）結對編程（檢查彼此工作提供支持）集體所有（配對的開(kāi)發(fā)人員參與系統的所有方面，所有開(kāi)發(fā)者享有全部代碼）連續集成（任務(wù)一完成，就將它集成到大系統中）可忍受速度（不能接受大量超時(shí)）在場(chǎng)客戶(hù)（系統最終用戶(hù)的代表應該全程滿(mǎn)時(shí)配合XP團隊）
檢驗和有效性驗證：實(shí)現過(guò)程之后，必須對所開(kāi)發(fā)的程序進(jìn)行驗證，它是對這些檢查和分析過(guò)程的總稱(chēng)。 檢驗的作用是檢查軟件是否符合它的描述。應該檢查系統是否滿(mǎn)足了需求所定義的功能的和非功能的需求。有效性驗證卻是一個(gè)更一般的過(guò)程，其目標是保證軟件系統能滿(mǎn)足客戶(hù)的期待。
V&V過(guò)程中，系統檢查和分析有兩種互補的方法：1軟件審查或配對審查——審查可以輔之以某些對系統源文本或者是相關(guān)文檔的自動(dòng)分析，是一種靜態(tài)的V&V技術(shù)，因為你無(wú)需再計算機上運行系統。2包括使用測試數據來(lái)運行軟件的實(shí)現，檢驗軟件的輸出和它的操作行為，測試是一種動(dòng)態(tài)的V&V技術(shù)。在軟件過(guò)程的不同階段，有2中截然不同的測試類(lèi)型：1有效性測試——試圖證明軟件是用戶(hù)所期望的即滿(mǎn)足需求2缺陷測試——試圖使缺陷暴露出來(lái)，而不是要仿真它在實(shí)際中的使用。發(fā)現程序和描述的不一致。
檢驗和有效性驗證過(guò)程試圖確定軟件系統中存在缺陷，程序調試時(shí)一個(gè)對缺陷定位和修正的過(guò)程。
軟件測試的目標：1向開(kāi)發(fā)者和用戶(hù)展示軟件滿(mǎn)足它的需求。2為了找出軟件中的缺陷和不足，即軟件的活動(dòng)室不正確的、所不希望的或不符合它的描述的。
測試過(guò)程：組件測試（單個(gè)程序組件的測試）—系統測試（對一組組件集成的系統進(jìn)行測試）
系統測試：兩個(gè)階段1集成測試（測試小組可以深入到系統源代碼）自上而下集成：首先開(kāi)發(fā)系統的框架，然后將組件加入到框架中。自下而上集成：集成基礎設施組件，然后添加功能組件.2發(fā)布測試（對要發(fā)布給用戶(hù)的系統版本進(jìn)行測試）
測試原則：是給測試團隊提示，以幫助他們選擇將揭示系統中的缺陷測試。
接口測試：目標是為了檢測由于接口的錯誤或無(wú)效的接口假設所造成的故障.
接口類(lèi)型1參數接口（數據從一個(gè)過(guò)程傳到另外一個(gè)過(guò)程）.2共享內存接口（內存塊為過(guò)程或函數所共享.）3程序接口（子系統封裝一組程序，這些程序為其他子系統調用.）4消息傳遞接口（子系統通過(guò)傳遞消息請求其他子系統上的服務(wù)）
劃分測試：由于類(lèi)中成員的這些等價(jià)行為，這些類(lèi)通常叫做等價(jià)劃分或者域.
結構化測試（白盒測試）：根據軟件的結構知識和實(shí)現知識導出測試的測試用例設計方法。
路徑測試：目標是要練習組件或程序中的每一條執行路徑。
要點(diǎn)：測試只能證明系統中存在錯誤，它不能說(shuō)明系統中不再有缺陷.；組件測試是組件開(kāi)發(fā)者的責任，獨立的測試團隊通常執行系統測試.；集成測試是最初的系統測試活動(dòng)，發(fā)布測試關(guān)心的是測試客戶(hù)版本，應該驗證所要發(fā)布的系統滿(mǎn)足了它的需求.；在缺陷測試時(shí)，應根據經(jīng)驗和準則來(lái)設計測試用例.；接口測試是要發(fā)現組合組件的接口中的缺陷.；等價(jià)劃分是導出測試用例的一個(gè)方法，需要找出輸入和輸出數據集合上的劃分并用這些劃分中的數據執行系統.；結構化分析依賴(lài)于分析一個(gè)程序由此來(lái)確定路徑.；測試自動(dòng)化通過(guò)使用一系列軟件工具支持測試過(guò)程，以減少測試過(guò)程的花費.
什么是黑盒測試和白盒測試？ 任何工程產(chǎn)品（注意是任何工程產(chǎn)品）都可以使用以下兩種方法之一進(jìn)行測試。 黑盒測試：已知產(chǎn)品的功能設計規格，可以進(jìn)行測試證明每個(gè)實(shí)現了的功能是否符合要求。 白盒測試：已知產(chǎn)品的內部工作過(guò)程，可以通過(guò)測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經(jīng)過(guò)檢查。 軟件的黑盒測試意味著(zhù)測試要在軟件的接口處進(jìn)行。這種方法是把測試對象看做一個(gè)黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說(shuō)明書(shū)，檢查程序的功能是否符合它的功能說(shuō)明。因此黑盒測試又叫功能測試或數據驅動(dòng)測試。黑盒測試主要是為了發(fā)現以下幾類(lèi)錯誤： 1、是否有不正確或遺漏的功能？ 2、在接口上，輸入是否能正確的接受？能否輸出正確的結果？ 3、是否有數據結構錯誤或外部信息（例如數據文件）訪(fǎng)問(wèn)錯誤？ 4、性能上是否能夠滿(mǎn)足要求？ 5、是否有初始化或終止性錯誤？ 軟件的白盒測試是對軟件的過(guò)程性細節做細致的檢查。這種方法是把測試對象看做一個(gè)打開(kāi)的盒子，它允許測試人員利用程序內部的邏輯結構及有關(guān)信息，設計或選擇測試用例，對程序所有邏輯路徑進(jìn)行測試。通過(guò)在不同點(diǎn)檢查程序狀態(tài)，確定實(shí)際狀態(tài)是否與預期的狀態(tài)一致。因此白盒測試又稱(chēng)為結構測試或邏輯驅動(dòng)測試。白盒測試主要是想對程序模塊進(jìn)行如下檢查： 1、對程序模塊的所有獨立的執行路徑至少測試一遍。 2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。 3、在循環(huán)的邊界和運行的界限內執行循環(huán)體。 4、測試內部數據結構的有效性，等等。 以上事實(shí)說(shuō)明，軟件測試有一個(gè)致命的缺陷，即測試的不完全、不徹底性。由于任何程序只能進(jìn)行少量（相對于窮舉的巨大數量而言）的有限的測試，在未發(fā)現錯誤時(shí)，不能說(shuō)明程序中沒(méi)有錯誤。
配置管理的重要性：涉及程序和標準的發(fā)展和應用來(lái)管理不斷發(fā)展的軟件產(chǎn)品；配置管理有時(shí)候被看做是軟件質(zhì)量管理過(guò)程的一部分；當進(jìn)行配置管理時(shí)，受控系統有時(shí)也稱(chēng)為基線(xiàn)，因為它們是受控進(jìn)化的一個(gè)起點(diǎn).
四種主要配置管理活動(dòng)：
配置管理規劃：描述配置管理應該使用的標準和規劃。1配置項識別（應該定義文檔命名規則，以便類(lèi)型相同的文檔命名也類(lèi)似）2配置數據庫（用于記錄與配置有關(guān)的所有信息）
變更管理：需求不斷發(fā)生變化，系統也相應作出變更。關(guān)注的是對變化保持跟蹤，并確保它們用最具成本效益的方式實(shí)施. 變更請求表（記錄了變更的建議、變更的請求、變更的原因以及變更的迫切性.它還記錄了變更評估、影響分析、變更成本和建議.）
版本和發(fā)布管理：是識別和追蹤一個(gè)系統的各個(gè)版本和發(fā)布的過(guò)程。
版本 一個(gè)系統版本就是一個(gè)系統實(shí)例，在某種程度上有別于其他系統實(shí)例.
變體 有一些版本可能在功能上沒(méi)有什么區別，只是為了不同的硬件或軟件配置而設計.
發(fā)布版本： 一個(gè)系統的發(fā)布版本就是要分發(fā)給客戶(hù)的版本.
版本管理規程應該規定明確的標識每個(gè)組件版本的方法.
三種基本的版本標識方法 1版本編號;2基于屬性的標識;3面向變更的標識.
系統構建：把軟件組件編譯和連接成一個(gè)程序并在特定目標配置上運行的過(guò)程.
CASE工具可用于支持所有的配置管理活動(dòng).
支持配置管理的CASE工具可以是一些獨立的工具分別用來(lái)支持變更管理、版本管理和系統構建，也可以是集成的系統，為所有的配置管理支持提供一個(gè)一致的接口.
聯(lián)系客服
