《系統(tǒng)開發(fā)規(guī)范與文檔編寫》

課程輔導(dǎo)

徐惠民第一章在直播課堂中介紹了本課程特點、教材的特色、學習方法、教材的體系結(jié)構(gòu)和主要內(nèi)容。這一次則是對各章內(nèi)容中的重點和難點作一些具體的輔導(dǎo)。第一章第一章的重點：a.掌握軟件的定義b.掌握軟件工程基本概念c.掌握軟件生命周期的劃分和瀑布模型第一章軟件的定義：軟件是為了特定目的而開發(fā)的程序、數(shù)據(jù)和文檔的集合。特別需要強調(diào)的是：文檔也是軟件的重要組成部分。

第一章還需要了解：什么是軟件危機及其產(chǎn)生的原因。軟件危機是指在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題：

軟件往往不能按計劃、按預(yù)算、按時完成

已開發(fā)的軟件不能很好的使用，甚至很快就不用第一章美國政府AccountingOffice計算局1979年的統(tǒng)計：

正常使用的：2％

修改后使用的：3％

開發(fā)完了而不使用的：47％（不完善）

放棄開發(fā)的：19％

沒有遞交的：29％第一章軟件危機產(chǎn)生的原因u

軟件需求不充分u

軟件開發(fā)無計劃性u

軟件開發(fā)過程無規(guī)范性u軟件無評測手段第一章軟件工程的基本概念：什么是軟件工程；軟件工程的目標和研究對象；軟件工程的基本原理。第一章什么是軟件工程：

FritzBauer在NATO會議上給出的定義：建立并使用完善的工程化原則，以能夠經(jīng)濟地獲得能在實際機器上有效運行的可靠軟件（SoftwareEngineeringistheestablishment&useofsoundengineeringprinciplesinordertoobtaineconomicallysoftwarethatisreliable&workefficientlyonrealmachines）第一章軟件工程的目標：軟件產(chǎn)品的高質(zhì)量首先是軟件的正確性和可用性高可靠性易維護低成本及時投放市場第一章軟件工程的研究對象由三個具有層次關(guān)系的要素組成：過程、方法和工具。

過程方法工具第一章軟件工程的基本原理：指軟件工程專家B.W.Boehm提出的7條基本原理：用分階段的生命周期計劃嚴格管理堅持進行階段評審實行嚴格的產(chǎn)品控制第一章采用現(xiàn)代程序設(shè)計技術(shù)結(jié)果應(yīng)能清楚地審查開發(fā)小組的人員應(yīng)該少而精承認不斷改進軟件工程實踐的必要性第一章掌握軟件生命周期的劃分和瀑布模型生命周期方法學就是從時間角度對軟件開發(fā)和維護的復(fù)雜問題進行分解，把軟件生命的漫長周期依次劃分為若干個階段，每個階段都有相對獨立的任務(wù)，然后逐步完成每個階段的任務(wù)。

第一章軟件生命周期劃分為六個階段：計劃、需求分析、設(shè)計、編碼、測試、運行維護。有時稱為制造軟件產(chǎn)品的直接過程。第一章除了直接過程外，還需要一些貫穿于整個軟件開發(fā)過程的輔助過程。輔助過程包括項目管理過程，配置管理過程和質(zhì)量管理過程。制造軟件產(chǎn)品的過程直接過程間接過程第一章軟件過程可以通過軟件過程模型來表示。最經(jīng)典的過程模型是瀑布模型。第一章第一章瀑布模型的特征接收上一項活動的輸出作為本項活動的輸入；實施本項活動應(yīng)該完成的工作；將本項活動的工作成果輸出，作為下一項活動的輸入優(yōu)點：支持結(jié)構(gòu)化軟件開發(fā)、控制了軟件開發(fā)的復(fù)雜性、促進了軟件開發(fā)工程化第一章其他軟件工程模型：除了瀑布模型外，還有其他許多軟件工程模型（原型模型、快速應(yīng)用開發(fā)模型、演化模型等）。對于這些模型重點不在于模型的細節(jié)，而在于過程模型的發(fā)展。第一章就是要理解為什么要有新的模型的出現(xiàn)，了解不同過程模型之間的互相聯(lián)系又互有區(qū)別，只有理解了他們之間的聯(lián)系和區(qū)別才能在未來實踐中為不同的環(huán)境選擇合適的過程模型。各種新的模型幾乎都有一個共同的特點：迭代開發(fā)。第一章第一章還有一些需要關(guān)注的內(nèi)容：1.了解軟件工程知識體系2.了解軟件能力成熟度模型軟件能力成熟度模型，CMM，是衡量一個軟件開發(fā)組織開發(fā)能力的標準，它包括5個級別初始級、可重復(fù)級、確定級、可管理級、優(yōu)化級。

第二章第二章a.掌握需求工程的概念b.掌握結(jié)構(gòu)化需求分析c.面向?qū)ο笮枨蠓治鰀.理解各種需求獲取技術(shù)e.了解需求管理和支持工具第二章需求工程確定系統(tǒng)“做什么”，但并不涉及系統(tǒng)“怎么做”，需求工程的成果是軟件需求規(guī)格說明書。需求過程的全過程包括：需求獲取、需求建模、形成需求規(guī)格、需求驗證和需求管理。第二章需求工程的重要性

需求工程處于軟件工程過程的開始階段，是軟件工程其余部分得以順利進行的根基。

第二章需求獲取需求獲取是需求工程的第一步，獲取的需求是否正確、全面，決定所開發(fā)出來的軟件是否能夠滿足用戶的需要.需求獲取過程涉及到和用戶的交流，目前還缺乏一種規(guī)范的方法，并在很大程度上依賴于需求獲取者的專門知識。需求獲取既重要又困難。第二章需求分析（需求建模）目前已經(jīng)出現(xiàn)了很多種需求分析的方法，但最常使用的是傳統(tǒng)的結(jié)構(gòu)化需求分析方法和面向?qū)ο蟮姆治龇椒ā５诙陆Y(jié)構(gòu)化需求分析方法概述結(jié)構(gòu)化需求分析使用自頂向下、逐層分解的系統(tǒng)分析方法來定義系統(tǒng)的需求，適合于開發(fā)數(shù)據(jù)處理類型軟件的需求分析，特別是企業(yè)事業(yè)單位中有關(guān)數(shù)據(jù)管理類型應(yīng)用軟件的開發(fā)。第二章數(shù)據(jù)流圖是結(jié)構(gòu)化需求分析中使用的主要方法，需要掌握。數(shù)據(jù)流圖用一套簡單的符號來描繪信息在系統(tǒng)中流動和處理的情況，是軟件設(shè)計人員和用戶之間極好的通信工具，是結(jié)構(gòu)化分析方法的核心。

第二章數(shù)據(jù)流圖中有四種主要元素：數(shù)據(jù)源，加工，存儲和數(shù)據(jù)流。

第二章

數(shù)據(jù)源：數(shù)據(jù)的源點和終點分別代表數(shù)據(jù)的生產(chǎn)者和消費者，可以是系統(tǒng)之外的人、物、組織或別的系統(tǒng)。

數(shù)據(jù)的加工或處理將輸入的數(shù)據(jù)變換成輸出數(shù)據(jù)。當然，不可能只通過一個加工完成數(shù)據(jù)的變換。

數(shù)據(jù)流是一種成分已知的信息包，可以包含若干個已知的信息。是描述數(shù)據(jù)流圖中各個部件的接口。

數(shù)據(jù)存儲表示系統(tǒng)所需要保存的信息。

第二章分層數(shù)據(jù)流圖稍微復(fù)雜的實際問題，如果把所有的加工都畫在同一張圖上，一方面增加了畫圖的復(fù)雜性，另一方面，這樣的數(shù)據(jù)流圖看起來很不清楚，降低了數(shù)據(jù)流圖的可讀性。

第二章中間層數(shù)據(jù)流圖中間層數(shù)據(jù)流圖是對高層數(shù)據(jù)流圖（即父圖）中的加工的分解。在高層數(shù)據(jù)流圖中每一個需要分解的加工各對應(yīng)一個下一層數(shù)據(jù)流圖。頂層圖分解后的子圖就是0層圖。一個數(shù)據(jù)流圖中有幾個加工要分解，就有幾張低層數(shù)據(jù)流圖。要求能根據(jù)描述，畫出頂層圖和0層圖。第二章數(shù)據(jù)流圖實例：設(shè)備管理系統(tǒng)維護公司所有設(shè)備的基本資料對設(shè)備進行定期檢修報修管理設(shè)備維修的費用上報公司財務(wù)部門第二章第二章從頂層圖到0層圖：

第二章數(shù)據(jù)字典

數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結(jié)構(gòu)的精確定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。數(shù)據(jù)字典與數(shù)據(jù)流圖配合，能清楚地表達數(shù)據(jù)處理的要求。

第二章為了讓用戶、系統(tǒng)分析員和程序員都了解各個功能單元（最低層數(shù)據(jù)流圖的加工）的具體邏輯功能，還必須對各功能單元做出詳細的說明。

加工小說明的主要工具：結(jié)構(gòu)化語言、判定表和判定樹。第二章基于用例的需求獲取技術(shù)

用例方法引起了面向?qū)ο箢I(lǐng)域的極大關(guān)注。自1994年IvarJacobson的著作出版后，面向?qū)ο箢I(lǐng)域已廣泛接納了用例這一概念，并認為它是第二代面向?qū)ο蠹夹g(shù)的標志。第二章用例模型描述的是外部執(zhí)行者(Actor)所理解的系統(tǒng)功能。用例模型用于需求分析階段，它的建立是系統(tǒng)開發(fā)者和用戶反復(fù)討論的結(jié)果，表明了開發(fā)者和用戶對需求規(guī)格達成的共識。第二章用例模型的特點

首先，它描述了待開發(fā)系統(tǒng)的功能需求；其次，它將系統(tǒng)看作黑盒，從外部執(zhí)行者的角度來理解系統(tǒng)；第三，它驅(qū)動了需求分析之后各階段的開發(fā)工作。不僅在開發(fā)過程中保證了系統(tǒng)所有功能的實現(xiàn)，而且被用于驗證和檢測所開發(fā)的系統(tǒng)。第二章用例模型的最重要的兩個概念是：參與者和用例。也要表示參與者和用例的通信參與者是為了完成某個事件而與系統(tǒng)進行交互的實體，

用例描述系統(tǒng)完成的動作序列，產(chǎn)生對特定參與者有價值的結(jié)果。或者說，用例描述了用戶和系統(tǒng)之間的交互，并且它側(cè)重于系統(tǒng)為用戶“做什么”。

第二章用例，參與者及其關(guān)聯(lián)關(guān)系可以顯示在用例圖中。例如，電話的呼叫者可以撥打本地電話和長途電話，與被呼叫者通話。以下是撥打電話的用例圖。

第二章ATM自動柜員機用例圖第二章用例的擴展關(guān)系：表示系統(tǒng)的擴展功能；用例的包含關(guān)系：表示多個基本用例都可以使用的用例用例的泛化關(guān)系：從幾個用例中抽象出來的共同行為的父用例第三章第三章a.掌握結(jié)構(gòu)化軟件設(shè)計概念。b．掌握結(jié)構(gòu)化軟件設(shè)計方法。c．理解概要設(shè)計和詳細設(shè)計概念。d．了解Jackson軟件開發(fā)方法。第三章軟件需求解決“做什么”；軟件設(shè)計解決“如何做”；第三章結(jié)構(gòu)化軟件設(shè)計分為兩個階段概要設(shè)計：概要設(shè)計的任務(wù)和步驟包括：設(shè)計軟件系統(tǒng)結(jié)構(gòu)；數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫設(shè)計；可靠性設(shè)計；編寫概要設(shè)計文檔和概要設(shè)計評審。詳細設(shè)計：確定模塊內(nèi)部的算法和數(shù)據(jù)結(jié)構(gòu)，產(chǎn)生描述各模塊程序過程的詳細文檔。

第三章軟件設(shè)計中用到概念主要包括：抽象與逐步求精模塊化與信息隱藏軟件體系結(jié)構(gòu)軟件結(jié)構(gòu)與軟件過程等第三章模塊獨立性的概念模塊完成獨立的功能

符合信息隱藏和信息局部化原則模塊間關(guān)聯(lián)和依賴程度盡量小

第三章模塊獨立性的度量模塊之間的耦合性要越弱越好，即低耦合；模塊自身的內(nèi)聚性要越強越好，即高內(nèi)聚。目的是增加模塊的獨立性，減少模塊之間的依賴程度。

第三章耦合性由低到高的排列是：

非直接耦合、數(shù)據(jù)耦合、標記耦合、控制耦合、外部耦合、公共耦合、內(nèi)容耦合。

第三章非直接耦合：模塊間沒有直接關(guān)系；數(shù)據(jù)耦合：通過數(shù)據(jù)參數(shù)發(fā)生關(guān)系；標記耦合：通過一個公共的數(shù)據(jù)結(jié)構(gòu)發(fā)生聯(lián)系；控制耦合：通過控制信息發(fā)生聯(lián)系；外部耦合：一組模塊都訪問同一全局簡單變量公共耦合：通過公共的數(shù)據(jù)區(qū)發(fā)生聯(lián)系；內(nèi)容耦合：兩個模塊直接聯(lián)系。第三章內(nèi)聚星由高到低的排列是：

功能內(nèi)聚、信息內(nèi)聚、通信內(nèi)聚、過程內(nèi)聚、時間內(nèi)聚、邏輯內(nèi)聚、巧合內(nèi)聚。第三章概要設(shè)計的主要任務(wù)是建立軟件系統(tǒng)的體系結(jié)構(gòu)。

解決劃分多少模塊，模塊之間的層次結(jié)構(gòu)和調(diào)用關(guān)系是怎樣的。同時還要設(shè)計數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)庫結(jié)構(gòu)、人機接口等。

第三章結(jié)構(gòu)化設(shè)計方法是基于模塊化、自頂向下逐層細化、結(jié)構(gòu)化程序設(shè)計等程序設(shè)計技術(shù)基礎(chǔ)上發(fā)展起來的。它以結(jié)構(gòu)化分析產(chǎn)生的數(shù)據(jù)流圖為依據(jù)，將數(shù)據(jù)流圖按一定的步驟映射成軟件結(jié)構(gòu)。第三章結(jié)構(gòu)化設(shè)計的目的是要把數(shù)據(jù)流圖映射成軟件結(jié)構(gòu)，而不同的數(shù)據(jù)流圖具有不同的映射方法。一般來說無論數(shù)據(jù)流圖如何龐大復(fù)雜，都可以分為變換型數(shù)據(jù)流圖和事務(wù)型數(shù)據(jù)流圖兩類。第三章詳細設(shè)計完成概要設(shè)計后，已將系統(tǒng)劃分為多個模塊，確定了每個模塊的功能及模塊與模塊之間的外部接口。詳細設(shè)計是軟件設(shè)計的第二階段。

第三章詳細設(shè)計的主要任務(wù)確定每個具體執(zhí)行過程，正確實現(xiàn)每個模塊的功能為軟件結(jié)構(gòu)圖(SC)中的每一個模塊確定采用的算法和模塊內(nèi)數(shù)據(jù)結(jié)構(gòu)，用某種選定的表達工具給出清晰的描述。第三章詳細設(shè)計過程中采用的方法結(jié)構(gòu)化程序設(shè)計；采用程序流圖、PAD圖、PDL語言等工具來描述。

第三章JSP是一種面向數(shù)據(jù)結(jié)構(gòu)，以數(shù)據(jù)驅(qū)動的，主要為中小型數(shù)據(jù)處理系統(tǒng)設(shè)計程序結(jié)構(gòu)的一種開發(fā)方法。它的優(yōu)點是在建立了問題的數(shù)據(jù)結(jié)構(gòu)之后，可直接推導(dǎo)出相應(yīng)的程序結(jié)構(gòu)。

第三章JSD方法是JSP的擴充，主要是為了解決JSP針對設(shè)計較大系統(tǒng)時候會在輸入數(shù)據(jù)結(jié)構(gòu)和輸出數(shù)據(jù)結(jié)構(gòu)之間產(chǎn)生大量復(fù)雜的難以應(yīng)付的結(jié)構(gòu)沖突的問題。

第四章面向?qū)ο蠡A(chǔ)

對象（Object）

類（Class）繼承（Inheritance）消息（Message）多態(tài)性（Polymorphism）和動態(tài)綁定（dynamicbinding）第四章面向?qū)ο?/p>

=對象

+類

+繼承

+消息通信

什么是面向?qū)ο蠓椒?一種運用對象、類、繼承、聚合、消息傳送、多態(tài)性等概念來構(gòu)造系統(tǒng)的軟件開發(fā)方法

第四章面向?qū)ο蠓治龅哪繕?定義所有和被求解的問題相關(guān)的類，以及和這些類相關(guān)聯(lián)的關(guān)系和行為。

第四章步驟：

獲取用戶對OO系統(tǒng)的需求，包括表示場景或者用例；建造需求模型。

為每個系統(tǒng)對象標識屬性和操作。

定義組織類的結(jié)構(gòu)和層次。

建造對象-關(guān)系模型。

建造對象-行為模型。使用用例/場景復(fù)審OO分析模型。

第四章面向?qū)ο蠓治鲞^程

獲取用戶對系統(tǒng)的需求標識類和對象定義類的結(jié)構(gòu)和層次第四章面向?qū)ο笤O(shè)計（Object-OrientedDesign,OOD）是將OOA所創(chuàng)建的分析模型轉(zhuǎn)化為設(shè)計模型。與傳統(tǒng)的開發(fā)方法不同，OOD和OOA采用相同的符號表示，OOD和OOA沒有明顯的分界線，它們往往反復(fù)迭代進行。在OOA時，主要考慮系統(tǒng)做什么，而不關(guān)心系統(tǒng)如何實現(xiàn)。在OOD時，主要解決系統(tǒng)如何做第四章OOD是在OOA的基礎(chǔ)上進行的。它以O(shè)OA模型作為輸入，根據(jù)實現(xiàn)的要求對OOA作必要的修改與調(diào)整，或補充某些細節(jié)，其結(jié)果便是OOD模型的主要部分，稱問題域部分。此外，OOD還要補充幾個相對獨立，并且隔離了具體實現(xiàn)條件對問題域部分影響的外圍組成部分，如下圖所示。第四章OOD活動問題域部分的設(shè)計人機交互部分的設(shè)計控制驅(qū)動部分的設(shè)計數(shù)據(jù)接口部分的設(shè)計

第四章典型面向?qū)ο蠓椒ê喗?/p>

Coad/Yourdon面向?qū)ο蠓治雠c設(shè)計技術(shù)對象建模技術(shù)（OMT）

第四章Coad與Yourdon面向?qū)ο蠓治龅母拍钅Ｐ偷奈鍌€層次

類與對象層

屬性層

服務(wù)層

結(jié)構(gòu)層主題層

當五個層次的工作全部完成時，OOA的任務(wù)也就完成了。

第四章J.Rumbaugh和他的四位合伙者于1991年提出對象建模技術(shù)（ObjectModelingTechnique，OMT）。它把分析時收集的信息構(gòu)造在三類模型中，即對象模型、功能模型和動態(tài)模型。第四章對象模型是三個模型中最關(guān)鍵的模型。對象模型定義“對誰做”。

通過狀態(tài)圖和事件追蹤圖來描述動態(tài)模型。動態(tài)模型定義“何時做”。

功能模型定義“做什么”。

第四章統(tǒng)一建模語言90年代以來出現(xiàn)了多種面向?qū)ο蟮姆椒ǎ陀^上使面向?qū)ο蟮姆椒ê图夹g(shù)得到了廣泛的認可并逐漸成為當前軟件開發(fā)的主流方法。但是每種方法都有自己的表示方法，過程和工具，使軟件人員之間溝通交流形成了障礙。統(tǒng)一建模語言（UnifiedModelingLanguage，UML）正是鑒于這一情況，在吸收多種面向?qū)ο蠼７椒ǖ幕A(chǔ)上而形成的。第四章ULM簡介：一個現(xiàn)實的軟件系統(tǒng)我們可以從不同視角去觀察、剖析它，每一個角度觀察的結(jié)果構(gòu)成系統(tǒng)的一個視圖（view），每個視圖說明了系統(tǒng)的一個側(cè)面，是整個系統(tǒng)描述的一個投影。在UML中視圖是由若干個圖（diagram）組成的一種抽象。一個圖（diagram）描述了系統(tǒng)某個特殊方面的信息圖又是由若干個模型元素構(gòu)成。第四章第四章連接關(guān)系：

關(guān)聯(lián)（association）：連接模型元素及實例

泛化（generalization）：表示一般與特殊關(guān)系，即“一般”元素是“特殊”元素的泛化，“特殊”元素是“一般”元素的特化（specialization）

依賴（dependency）：表示一個元素以某種方式依賴另外一個元素

聚集（aggregation）：表示整體與部分，即：“部分”元素是“整體”元素的一部分第四章UML中有九種圖（diagram）和五種視圖（view）。九種圖包括：用例圖、類圖、對象圖、狀態(tài)圖、順序圖、協(xié)作圖、活動圖、構(gòu)件圖和部署圖。用來觀察系統(tǒng)的五種視圖有：用例視圖、邏輯視圖、構(gòu)件視圖、并發(fā)視圖和部署視圖。

第四章類圖：描述系統(tǒng)中所有類的類型，類所具有的屬性和操作，以及類與類之間的靜態(tài)的相互聯(lián)系。

對象圖：是類圖的實例

順序圖：順序圖顯示特定用例（也可以是用例的一部分）的詳細流程。

第四章用例圖:展示了各個類外部參與者與系統(tǒng)所提供的用例之間的連接。一個用例是系統(tǒng)所提供的一個功能。狀態(tài)圖：是對某個類可能所處的不同狀態(tài)和該類從一個狀態(tài)轉(zhuǎn)換到另外一個狀態(tài)的描述。

第四章協(xié)作圖：也展示對象間的動態(tài)協(xié)作關(guān)系。強調(diào)多個對象間的協(xié)作活動圖：描述完成一個操作所需要的活動。活動圖由動作狀態(tài)組成。

第四章構(gòu)件圖：構(gòu)件圖用于程序設(shè)計工作，顯示代碼本身的結(jié)構(gòu)。部署圖：顯示系統(tǒng)運行時刻的結(jié)構(gòu)，包括硬件結(jié)構(gòu)和軟件結(jié)構(gòu)。

第四章用例視圖：用例視圖從用戶角度描述系統(tǒng)功能，并指出各功能的操作者。邏輯視圖：展示了系統(tǒng)內(nèi)部如何提供系統(tǒng)功能的。該視圖通過類圖和對象圖來描述系統(tǒng)的靜態(tài)結(jié)構(gòu)；用狀態(tài)圖、順序圖、協(xié)作圖、活動圖來描述系統(tǒng)的動態(tài)行為。

第四章構(gòu)件視圖：展示了代碼構(gòu)件的組織（相互關(guān)系）。并發(fā)視圖：展示了系統(tǒng)的并發(fā)性（線程和它們的通信）。部署視圖：展示了系統(tǒng)的物理部署。

第四章UML建模用例模型：用于系統(tǒng)需求的獲取，描述系統(tǒng)的功能需求。靜態(tài)模型：它把問題域與應(yīng)用域有關(guān)的各種類、對象以及它們之間的相互關(guān)系進行適當?shù)某橄蠛头诸悾越沂鞠到y(tǒng)的結(jié)構(gòu)。使用類圖、對象圖。

第四章動態(tài)模型：描述系統(tǒng)的動態(tài)行為，顯示對象在系統(tǒng)運行期間不同時刻的動態(tài)交互，從而實現(xiàn)一組對象的相應(yīng)功能。UML中用狀態(tài)圖、順序圖、協(xié)作圖和活動圖來建立動態(tài)模型。

第四章實現(xiàn)模型：系統(tǒng)的實現(xiàn)模型包括構(gòu)件圖和配置圖。它們描述了系統(tǒng)實現(xiàn)時的一些特性。第四章使用UML的過程系統(tǒng)需求系統(tǒng)需求分析；靜態(tài)結(jié)構(gòu)模型動態(tài)結(jié)構(gòu)模型

第四章UML給出了面向?qū)ο蠼５谋硎竞鸵?guī)則，但并沒有指定應(yīng)用UML的過程和方法，因為它的設(shè)計初衷是為了在盡可能多的領(lǐng)域內(nèi)得到廣泛的應(yīng)用。盡管如此，要想成功的使用UML，科學的過程還是必要的。第四章使用UML的過程的基本特征是：以架構(gòu)為中心（architecture-centric）用例驅(qū)動（use-casedriven）迭代（iterative）增量式開發(fā)（incremental）。

第四章面向?qū)ο笠话惴椒?/p>

面向?qū)ο蟮能浖_發(fā)過程是一個迭代增量式的過程，它并沒有一個具體的、固定的格式，只是存在一個大致統(tǒng)一的過程框架。從大體上來講，面向?qū)ο蟮能浖_發(fā)過程仍可劃分為分析、設(shè)計、編程、測試等步驟，但各個步驟之間并沒有嚴格的邊界，而且允許有一定的相交和回朔。第四章考勤系統(tǒng)的分析與設(shè)計

在考勤系統(tǒng)中，雇員利用這個系統(tǒng)來記錄考勤時間，并能夠用它來瀏覽、更新和增加新的時間記錄；系統(tǒng)管理員能管理系統(tǒng)中的雇員，如添加、修改和刪除雇員，并且能夠?qū)?導(dǎo)出時間數(shù)據(jù)。

第四章參與者有：雇員（Employee）和管理員（Administrator）。

“記錄時間”(RecordTime)用例，“導(dǎo)入/導(dǎo)出系統(tǒng)數(shù)據(jù)”（In/ExportTimeEntries）用例，“創(chuàng)建雇員”（CreateEmployee）。

第四章第五章第五章a.掌握軟件配置管理的基本概念b.了解軟件配置管理的方法和過程第五章軟件配置管理（SoftwareConfigurationManagement,SCM）是一門應(yīng)用技術(shù)、管理和監(jiān)督相結(jié)合的學科，通過標識和文檔來記錄配置項的功能和物理特性，控制這些特性的變更，記錄和報告變更的過程和狀態(tài)，并驗證它們與需求是否一致。

第五章一個基本的軟件配置管理系統(tǒng)應(yīng)該提供版本控制功能變更管理功能狀態(tài)統(tǒng)計功能配置審核功能。第五章軟件配置項指的是一個硬件，軟件或者軟硬件的集合，配置項是為了配置管理而指定的，并在配置管理過程中被當作單一實體。

在軟件開發(fā)工程中的一切文檔都可以看作是配置項。第五章基線：是軟件生存期各開發(fā)階段末尾的特定點，也稱為里程碑。基線是軟件配置管理的一個重要概念，它幫助實現(xiàn)對變更的控制。

軟件開發(fā)是變更的過程，而基線則為變更提供了一個可以參考的目標，

第五章軟件配置管理方法

定制軟件配置管理計劃

規(guī)定配置管理職責

確定配置項標識的管理要求

確定配置項測試狀態(tài)的管理要求

確定配置項變更控制方法選擇配置管理使用的工具、技術(shù)和方法

第五章軟件配置標識

選擇接受軟件配置管理的配置項；確定配置項的命名和描述；配置項的存取。第五章軟件配置控制

軟件版本控制

軟件變更控制

軟件配置審核

配置狀態(tài)報告

第六章第六章a.掌握軟件質(zhì)量的基本概念b.了解影響軟件質(zhì)量的因素c.理解主要的質(zhì)量保障活動d.了解軟件測試的意義和方法第六章軟件質(zhì)量的概念

依靠特定的或隱含的能力滿足特定需要的產(chǎn)品或