軟件工程的介紹

軟件？

• 軟件是一個產(chǎn)品。 顯示了由計算機硬件體現(xiàn)的計算能力。
• 軟件是產(chǎn)品生產(chǎn)的載體，軟件提供了計算機的控制，信息通信以及應(yīng)用程序開發(fā)和控制的基礎(chǔ)平臺。
• 軟件是指令的集合。通過這些指令可以滿足預(yù)期的特征，功能和性能需求。
• 軟件是數(shù)據(jù)結(jié)構(gòu)，使程序能夠合理的利用信息。
• 軟件描述信息，它以硬拷貝和虛擬的形式存在，用來描述程序的操作和使用。

軟件的特性，與硬件的區(qū)別？

• 軟件是設(shè)計開發(fā)的，而不是傳統(tǒng)意義上生產(chǎn)制造的。
• 軟件不會磨損，但是長期使用和修改會緩慢退化。
• 軟件是根據(jù)需求定制，并在不斷的變動。
• 軟件相對復(fù)雜。
• 而硬件是生產(chǎn)制造的，可以磨損和損壞，使用組件建造，與生產(chǎn)人員數(shù)量成正相關(guān)（軟件不是），不會像軟件一樣的“變”，相對簡單。

軟件退化

• 軟件不會磨損，但是在使用過程中，不斷的需求變更是軟件退化的根本原因。
• 因為每次變更都會引入新的錯誤，使得失效率上升。不斷的變更使得失效率整體逐漸上升。

軟件危機

• 第一次軟件危機。
  • 表現(xiàn)： 效率低下。軟件成本高。難以維護。
  • 原因： 人員知識結(jié)構(gòu)單一，code&fix 的模式。理論體系不成熟。開發(fā)管理不完善。
  • 解決： 理論體系的形成，它指導(dǎo)了 過程 和 項目管理。
• 第二次軟件危機
  • 表現(xiàn): 錯誤低質(zhì)量的產(chǎn)品。項目延時，違約。 工作時間太長。
  • 原因: 需求理解不充分。 黑盒模型，與客戶交流只是在開始和結(jié)束。
  • 解決： 白盒模型的引入。
• 第三次軟件危機
  • 需求變更，軟件質(zhì)量不能保證。 軟件演化，開發(fā)效率低下。 軟件重用和成本的問題。知識產(chǎn)權(quán)的問題。安全的問題。
  • 原因： 遺產(chǎn)系統(tǒng)的使用。開源軟件的使用。 不確定的需求。
  • 解決： 自動化，智能化。自適應(yīng)，自修復(fù)，自測試。 自主軟件。

過程綜述

軟件工程的概念

• 軟件工程是建立和使用一套合理的工程原則。以便于經(jīng)濟的獲得可靠的，可以在實際機器上運行的軟件。
• 將系統(tǒng)化的，嚴(yán)格約束的，可量化的方法運用于軟件開發(fā)，運行和維護，即將工程化方法應(yīng)用于軟件開發(fā)。
• 對上一條所定義的過程中的方法的研究。

軟件的層次

• 從上到下: 工具,方法，過程，質(zhì)量關(guān)注點。
• 軟件工程的基礎(chǔ)： 過程
• 軟件工程的根基： 質(zhì)量關(guān)注點。

軟件過程是工作產(chǎn)品構(gòu)建時所進行的一系列活動，動作，任務(wù)的集合。

過程框架 ： 溝通， 策劃， 建模， 構(gòu)建， 部署。

普適性活動： 軟件項目的跟蹤和控制。 風(fēng)險管理。 軟件質(zhì)量保證。 正式技術(shù)評審。 測量。 軟件配置管理。 可復(fù)用管理。 工作產(chǎn)品的準(zhǔn)備和生產(chǎn)。

過程模型分為： 慣用過程模型 和 敏捷過程模型。

過程模型[慣例模型]

軟件的生命周期。

• 同任何事物一樣，一個軟件產(chǎn)品或軟件系統(tǒng)也要經(jīng)歷孕育、誕生、成長、成熟、衰亡等階段，一般稱為軟件生存周期（軟件生命周期）。
• 分析，設(shè)計 ， 編碼 ，測試

軟件過程模型

瀑布模型（經(jīng)典的生命周期）

• 標(biāo)準(zhǔn)的軟件生命周期：分析 ，設(shè)計， 編碼 ，測試
• 特點：
  • 從上一項活動中接受該項活動的活動成果作為輸入
  • 利用這一輸入實施該項活動應(yīng)完成的內(nèi)容
  • 給出該項活動的工作成果，作為輸出傳給下一項活動
  • 對該項活動實施的工作進行評審。若其工作得到確認(rèn)，則繼續(xù)下一項活動。
• 優(yōu)點： 簡單，容易使用。 為項目提供了按階段劃分的檢查點，項目管理比較規(guī)范。每個階段必須提供文檔，而且每個階段必須進行正式嚴(yán)格的技術(shù)審查。
• 缺點：
  • 瀑布模型過于依賴早期進行的唯一一次需求調(diào)查，不能適應(yīng)需求的變化 。
  • 瀑布模型是單一流程，開發(fā)中的經(jīng)驗教訓(xùn)不能反饋應(yīng)用于本產(chǎn)品的過程。
  • 造成軟件錯誤的積累和放大效應(yīng)
• 適用：
  • 在實現(xiàn)之前清楚了解問題需求
  • 需求不會變更太大
  • 需求沒有無法解決的高風(fēng)險因素。
  • 需求對利益相關(guān)方來說是兼容的。
  • 實現(xiàn)需求的正確架構(gòu)已經(jīng)被很好的理解。
  • 有足夠的時間順序的進行項目。

增量模型

• 特點
  • 相當(dāng)于瀑布模型的迭代
  • 隨著日程時間的進展而交錯的線性序列
  • 與原型不同，強調(diào)每個增量均發(fā)布一個可操作產(chǎn)品
  • 典型應(yīng)用是同一產(chǎn)品的不同項目版本
• 優(yōu)點
  • 提高對用戶需求的響應(yīng)
  • 有計劃的管理技術(shù)風(fēng)險，如早期增量版本中避免采用尚未成熟的技術(shù)
  • 若開發(fā)前期找不到足夠的人員，早期的增量可以由少量人員完成，若核心產(chǎn)品口碑不錯，可以成為下個增量投入更多人員
• 缺點
  • 不能破壞原來構(gòu)造好的東西
  • 加入一個新的增量不是那么簡單。調(diào)節(jié)各個增量之間的關(guān)系也很難.
  • 至始至終開發(fā)者和客戶糾纏在一起，直到完成版本出來
  • 盡管其靈活性能適應(yīng)需求變化，但也容易退化成邊做邊改模型，使軟件過程控制缺乏整體性
• 適用： 需求經(jīng)常變化的軟件開發(fā)，市場急需而開發(fā)人員和資金不能再設(shè)定的市場期限之前實現(xiàn)一個完善的產(chǎn)品的軟件開發(fā)

演化過程模型

• 包括原型模型和螺旋模型。 是迭代的過程模型：一系列活動的重復(fù)應(yīng)用。

原型模型

• 特點 快速開發(fā)可以演示的系統(tǒng)原型。 有兩種使用方法： 1 作為最終產(chǎn)品的一部分。 2 作為需求分析的工具。
• 優(yōu)點
  • 快速的開發(fā)出可以演示的系統(tǒng)，便于與客戶溝通交流,及時獲得用戶的反饋。
  • 使用迭代技術(shù)能夠逐步弄清用戶的需求。
  • 可在項目早期就獲取項目的相關(guān)數(shù)據(jù)，盡早進行風(fēng)險管理和配置管理
  • 可使銷售工作提前進行
  • 心理：對開發(fā)人員鼓舞
• 缺點
  • 軟件的質(zhì)量和可維護性差。結(jié)構(gòu)不好。
  • 用戶可能混淆原型系統(tǒng)和最終系統(tǒng)。
  • 不加控制讓用戶接觸未穩(wěn)定功能，對開發(fā)人員和用戶不好
• 適用： 需求模糊的項目，質(zhì)量不能保證，是為定義需求而服務(wù)

螺旋模型[風(fēng)險驅(qū)動的過程模型]

• 特點： 結(jié)合了原型的迭代性質(zhì)和瀑布模型的系統(tǒng)性和可控性特點，在每個演進過程(四個：制定計劃、風(fēng)險分析、工程實施、客戶評估)要標(biāo)記里程碑，增加了風(fēng)險分析
• 優(yōu)點：
  • 結(jié)合了原型模型的迭代和瀑布模型的系統(tǒng)性，時空性。
  • 采用循環(huán)逐步加深系統(tǒng)的定義和實現(xiàn)深度。同時更好的理解，應(yīng)對降低風(fēng)險。
  • 確定一系列里程碑，確保各方都得到可行的解決方案。 強調(diào)各開發(fā)階段的質(zhì)量
  • 可操作性好，風(fēng)險驅(qū)動，支持現(xiàn)有軟件復(fù)用。
• 缺點
  • 必須引入非常嚴(yán)格的風(fēng)險識別，風(fēng)險分析和風(fēng)險控制，這對風(fēng)險管理的技能水平提出高要求
  • 需要人員、資金和時間的大量投入
• 適用： 大型開發(fā)系統(tǒng)和軟件

噴泉模型

• 特點：是軟件生命周期的各個階段是相互重疊和多次反復(fù)的，各階段沒有明顯的界線。 是一種線性開發(fā)模型，與瀑布模型類似，只是從串行改并行
• 優(yōu)點：提高軟件項目開發(fā)效率，節(jié)省開發(fā)時間
• 缺點：
  • 在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，不利于項目的管理
  • 要求嚴(yán)格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況
• 適用： 用于面向?qū)ο蠓椒ǎ嫦驅(qū)ο蟮姆治龊驮O(shè)計重疊，交叉、并行進行

統(tǒng)一過程

• 特點： 用例驅(qū)動，以架構(gòu)為核心，迭代并且增量，一種利用UML進行面向?qū)ο筌浖こ痰目蚣?，是一種增量模型。四個階段：初始inception，細(xì)化elaboration，構(gòu)造construction，交付transition
• 優(yōu)點：
  • 提高了團隊生產(chǎn)力，在迭代的開發(fā)過程、需求管理、基于組件的體系結(jié)構(gòu)、可視化軟件建模、驗證軟件質(zhì)量及軟件變更等方面，針對所有關(guān)鍵的開發(fā)活動為每個開發(fā)成員提供了必要的準(zhǔn)則、模板和工具指導(dǎo)，并確保全體成員共享相同的知識基礎(chǔ)。
  • 建立了簡潔和清晰的過程結(jié)構(gòu)，為開發(fā)過程提供較大的通用性。
• 缺點：在實際應(yīng)用上，需要更多的工具的支持和普及推廣工作
• 適用: 現(xiàn)代大型面向?qū)ο蠊こ獭?/li>

敏捷視角下的過程

敏捷開發(fā)

開發(fā)宣言：

• 個體交互勝過過程和工具
• 可工作軟件勝過寬泛的文檔
• 客戶合作勝過合同談判
• 響應(yīng)變化勝過遵循計劃

敏捷開發(fā)： 為了克服傳統(tǒng)的軟件過程中認(rèn)識和實踐的弱點而設(shè)計。

• 特點：
  • 適應(yīng)變更
  • 交流順暢
  • 客戶參與
  • 有效控制
  • 拉平了變更成本曲線。

極限編程

• 四個框架活動： 策劃， 設(shè)計，編碼， 測試。
• 適用面向?qū)ο蟮姆椒ㄗ鳛橥扑]的開發(fā)泛型。
• 適用： 小團隊，高風(fēng)險，快速變更的需求，強調(diào)可測試性。

系統(tǒng)工程

系統(tǒng)工程中的概念

• 系統(tǒng)： 開發(fā)軟件之前必須了解軟件所處的外界環(huán)境。 看樹也要看森林。
• 系統(tǒng)中的元素： 軟件，硬件，人員， 數(shù)據(jù)庫， 文檔，規(guī)程， 其他。
• 系統(tǒng)工程： 關(guān)注目標(biāo)系統(tǒng)各種相關(guān)要素的設(shè)計，并將其組織成有機的系統(tǒng)。

系統(tǒng)全局視圖由 多個領(lǐng)域組成，每個領(lǐng)域由多個要素組成， 每個要素由完成特定功能的構(gòu)件組成。

系統(tǒng)建模

• 建立模型
  • 定義在多考慮視圖中滿足需要的過程
  • 描述過程行為和該行為所依據(jù)的假設(shè)
  • 明確定義模型外在和內(nèi)在輸入
  • 描述有助于工程師理解視圖的全部聯(lián)系（包括輸出）
• 制約因素
  • 假設(shè)，簡化，限制，約束，客戶偏好。
• 本質(zhì)上傾向于分層分級。

系統(tǒng)模型的分類

Hatley-Prabhai建模：

• 利于用戶界面，輸入，系統(tǒng)功能和控制，輸出，維護和自檢的表達方式，可以建立一個系統(tǒng)構(gòu)建模型，為后面每個工程規(guī)范步驟建立良好的基礎(chǔ)

利用UML系統(tǒng)模型

• 部署圖：部署圖描述的是系統(tǒng)運行時的結(jié)構(gòu)，展示了硬件的配置及其軟件如何部署到網(wǎng)絡(luò)結(jié)構(gòu)中。一個系統(tǒng)模型只有一個部署圖，部署圖通常用來幫助理解分布式系統(tǒng)。
• 活動圖： 實現(xiàn)各種功能時的具體步驟。
• 類圖和用例圖。

需求工程

需求工程的任務(wù)

• 提供一種良好的機制：理解客戶需要什么，分析需求，評估可行性，協(xié)商合理方案，無歧義的詳細(xì)說明方案，確認(rèn)規(guī)格說明， 管理需求以至將這些需求轉(zhuǎn)化為可執(zhí)行的系統(tǒng)。
• 活動： 起始， 導(dǎo)出， 精化（是一個分析建模動作，最終結(jié)果是形成一個分析模型，定義問題提供的信息，功能和行為域），協(xié)商，規(guī)格說明， 確認(rèn)和需求管理。

需求工程的工作產(chǎn)品

• 必要性和可行性的陳述
• 系統(tǒng)或產(chǎn)品范圍的界限說明。
• 參與需求導(dǎo)出的客戶，用戶和其他共同利益者的列表
• 系統(tǒng)技術(shù)環(huán)境的說明。
• 需求列表（按照功能加以組織）。
• 一系列適用場景，有助于深入了解系統(tǒng)或者產(chǎn)品在不同運行環(huán)境下的使用。
• 任何能夠更好定義需求的原型。

需求開發(fā)的方法

• 需求獲?。?1開始過程： 與客戶建立初步交流。 2導(dǎo)出過程：通過訪問和調(diào)查，獲得需求的描述
• 需求分析： 精化過程，通過分析建模，建立精確的技術(shù)模型，說明軟件功能，特征和約束。
• 需求處理： 1協(xié)商過程 2形成規(guī)格說明 3需求確認(rèn)

構(gòu)建分析模型

分析模型的作用

• 分析建模使用文字和圖表的綜合形式，以相對容易理解的方式描繪需求的數(shù)據(jù)，功能和行為，更重要的是，可以更直接地評審他們的正確性，完整性和一致性。

分析模型的構(gòu)建原則

• 模型應(yīng)關(guān)注在問題域可見的需求，抽象級別應(yīng)該高一些。
• 分析模型的每一個元素應(yīng)該增加對軟件需求的整體理解。并提供對信息，功能，系統(tǒng)行為的深入理解。
• 基于結(jié)構(gòu)和其他非功能的模型應(yīng)推延到設(shè)計階段在考慮
• 最小化整個系統(tǒng)內(nèi)的關(guān)聯(lián)
• 確認(rèn)分析模型為所有共同利益者帶來好處。
• 盡可能保持模型簡潔。

方法

場景建模：從用戶角度描述軟件需求。

• 用例：參與者和原件之間的某個交互的敘述------是主要的建模元素。定義了特定的功能或者交互的關(guān)鍵步驟。為其他建?；顒犹峁┍仨毜妮斎?。
• 活動圖：描述在特定場景中的處理流。
• 泳道圖：顯示了處理流如何分配給不同的用戶和類.
• 用例圖: 從用戶的角度描述系統(tǒng)的功能,并指出各個功能操作者.
• 部署圖: 是用來顯示系統(tǒng)中軟件和硬件的物理架構(gòu).

類建模

• 使用基于場景和面向流的建模元素中提取信息,確定分析類,可以使用語法分析從文本敘述中提取候選類,屬性和操作,并制定用于定義類的標(biāo)準(zhǔn),CRC[類,職責(zé),協(xié)作]索引卡可以用于定義類之間的聯(lián)系. 使用UML建模符號定義類之間的層次.聯(lián)系,關(guān)聯(lián).聚合和依賴. 使用分析包將類分組. 為大型系統(tǒng)提供更好的管理.
• 類圖: 描述系統(tǒng)中類的靜態(tài)結(jié)構(gòu). 不僅定義了系統(tǒng)和分組,表示類之間的聯(lián)系,如關(guān)聯(lián)依賴聚合組合.也包括類的內(nèi)部結(jié)構(gòu).
• 協(xié)作圖: 描述對象間的協(xié)作關(guān)系. 和順序圖類似. 顯示對象間的動態(tài)合作關(guān)系.

行為建模

• 描述軟件的動態(tài)行為.使用基于場景,面向流和基于類的元素作為輸入,從整體上表現(xiàn)分析類和系統(tǒng)的狀態(tài).
• 狀態(tài)圖: 描述類的所有可能的狀態(tài)以及事件發(fā)生時狀態(tài)的轉(zhuǎn)移條件.
• 活動圖: 通過提供特定場景內(nèi)交互流的圖形化表示來補充用例.
• 順序圖: 顯示對象間的動態(tài)合作關(guān)系,強調(diào)對象間消息發(fā)送的順序,同時顯示對象間的交互.

設(shè)計工程

概念

抽象

* 數(shù)據(jù)抽象：將數(shù)據(jù)和施加于這些數(shù)據(jù)的操作抽象為對象。限定對象的取值范圍，只能通過這些操作來修改各觀察數(shù)據(jù)。
* 過程抽象(功能角度的抽象)： 將功能體作為單個功能看待。 該功能體實際上是由一系列更低級的功能或者代碼來實現(xiàn)的。     
* eg: 數(shù)據(jù)抽象： 門 ，過程抽象： 開門

體系結(jié)構(gòu)

• 軟件體系結(jié)構(gòu)關(guān)注系統(tǒng)的一個或者多個結(jié)構(gòu)，包含軟件部件，部件對外可見的屬性以及部件之間的關(guān)系。
• 體系結(jié)構(gòu)的作用
  • 方便利益相關(guān)人員的交流。
  • 有利于系統(tǒng)設(shè)計的前期決策
  • 可傳遞，易于理解的系統(tǒng)級抽象
• 體系結(jié)構(gòu)反映了軟件系統(tǒng)實現(xiàn)的高層方案
  • 軟件系統(tǒng)越來越復(fù)雜，需要將其劃分為若干部分分而治之---模塊化。
  • 不同的小組或開發(fā)者負(fù)責(zé)不同的部分。 最后在系統(tǒng)層面上集成。
  • 負(fù)責(zé)不同部分的開發(fā)者對于其他模塊需要理解的信息越少越好[抽象與信息隱藏]
  • 這些部分之間要定義清晰明確的接口。

模式[便于復(fù)用軟件]

• 每個模式都描述了一個在我們所處環(huán)境內(nèi)反復(fù)發(fā)生的問題。描述了該問題的核心解決方案。
• 模式的類型
  • 結(jié)構(gòu)模式[如：張翔老師講的MVC， 軟件體系結(jié)構(gòu)風(fēng)格]
    • 表達了軟甲系統(tǒng)的基本結(jié)構(gòu)組織形式。 包含一組預(yù)定義的子系統(tǒng)。規(guī)定這些系統(tǒng)的責(zé)任。同時提供了用于組織和管理這些子系統(tǒng)的規(guī)則和向?qū)А?/li>
  • 設(shè)計模式[如：適配器模式]
    • 為軟件系統(tǒng)的子系統(tǒng)，組件，或者組件之間的 關(guān)系提供一個精煉后的解決方案。
    • 它描述了在特定環(huán)境下，用于解決通用軟件設(shè)計問題的組件以及這些組件相互通信時的可重現(xiàn)結(jié)構(gòu)。
    • 如： 適配器模式。 適配器模式使得原本由于接口不兼容而不能一起工作的那些東西可以一起工作。
  • 編碼模式
    • 是特定于編程語言的低級模式，描述如何用給定的編程語言實現(xiàn)特定的組件或者組件之間的關(guān)系
    • 例如： 約定代碼縮進風(fēng)格， 變量命名規(guī)范等代碼層面上的問題。

模塊化(面向過程編程思想)

• 背景： 問題越復(fù)雜，解決問題花費的時間越多。
• 解決： 將復(fù)雜問題分解成多個子問題，解決起來會更加的容易。（模塊化思想的依據(jù)）
• 注意： 不要無限制的劃分軟件。 雖然劃分的越多，子模塊的工作量減少。 但是工作量還取決于模塊間接口的集成和負(fù)責(zé)不同模塊的人員的溝通。如果劃分的太多，集成和溝通的開銷將會很大。
• 結(jié)論： 尋找最佳模塊化成都的平衡點。（每個模塊成本和聯(lián)接成本的權(quán)衡問題）

信息隱藏

• 每個模塊隱藏自己的內(nèi)部實現(xiàn)細(xì)節(jié)。 模塊內(nèi)部的數(shù)據(jù)和過程不允許其他不需要這些信息的模塊使用。
• 定義和實施對模塊的過程細(xì)節(jié)和局部數(shù)據(jù)結(jié)構(gòu)的存去限制。
• [地位]信息隱藏是實現(xiàn)抽象/模塊化機制的基本支撐

功能獨立

• [地位]功能獨立是模塊化的根本要求

• 模塊各自完成獨立的功能，明確可辨識。

• 模塊獨立性的指標(biāo)：內(nèi)聚度，耦合度。

• 高內(nèi)聚：模塊內(nèi)部結(jié)構(gòu)緊密

• 低耦合： 模塊間的關(guān)聯(lián)依賴程度盡可能小。

• 符合信息隱藏和信息局部化的原則。

• [意義]：

  • 模塊的開發(fā)者只需要注重一個相對獨立的部分。
  • 不用過多的關(guān)心其他模塊。
  • 修改和Bug所影響的范圍被局部化。
  • 單個模塊特別容易復(fù)用。
  • 獨立的模塊更易于維護和測試。

• 內(nèi)聚度[由強到弱]

  • 功能內(nèi)聚[最高程度的內(nèi)聚]： 單個模塊內(nèi)部的各個部分都是為完成一項具體功能而協(xié)同工作緊密聯(lián)系不可分割的單個功能。
  • 分層內(nèi)聚： 高層能訪問底層的服務(wù)，反之不能。
  • 順序內(nèi)聚： 每個模塊內(nèi)部的各個組成部分必須順序執(zhí)行。 前一個模塊的動作的輸出是后一個模塊動作的輸入。
  • 通信內(nèi)聚： 模塊內(nèi)各個組成部分的處理使用相同的輸入數(shù)據(jù)或者具有相同的輸出數(shù)據(jù)。
  • 過程內(nèi)聚： 模塊內(nèi)多個任務(wù)，即使動作不相同，不相聯(lián)系，但是他們都受一個控制流支配，必須按照指定的過程執(zhí)行。
  • 時間內(nèi)聚：模塊內(nèi)個各個部分的處理與時間相關(guān)。如： 啟動時要進行的全部操作。
  • 實用內(nèi)聚： 每一個模塊中，某一方面相關(guān)，其他方面都不相關(guān)的構(gòu)建操作被分為一個組。

• 耦合度[由高到底]

  • 內(nèi)容耦合：一個模塊可以直接訪問另一個模塊的內(nèi)容或者內(nèi)部功能
  • 共用耦合： 多個模塊共同訪問某些公共數(shù)據(jù)環(huán)境。
  • 外部耦合： 一組模塊都訪問同一全局簡單變量，而不是同一全局?jǐn)?shù)據(jù)結(jié)構(gòu)，也不是通過參數(shù)表傳遞該全局變量的信息。
  • 控制耦合： 模塊間的交互參數(shù)包含控制信息，可影響另一個模塊的執(zhí)行邏輯。
  • 標(biāo)記耦合： 模塊間傳遞特定的數(shù)據(jù)結(jié)構(gòu)
  • 數(shù)據(jù)耦合： 模塊間只通過參數(shù)列表傳遞簡單的數(shù)據(jù)。
  • 非直接耦合： 兩個模塊可以相對獨立工作。
    • 例程調(diào)用耦合： 一個操作調(diào)用另一操作。 [需要減少]
    • 類型使用耦合： A使用B定義的一個數(shù)據(jù)類型.
    • 包含或者導(dǎo)入耦合

• 精化

  • 把問題的求解過程分解成若干步驟，每一步都比上一步更加精化，更接近實際問題的解法。
  • 常與分層抽象的思想結(jié)合：
    • 抽象使得設(shè)計者能夠描述過程和數(shù)據(jù)而忽略底層的細(xì)節(jié)。
    • 求精有助于設(shè)計者在設(shè)計過程中揭示底層的細(xì)節(jié)。
    • 高層抽象將在下層不斷精化，最終得到軟件的實現(xiàn)。

重構(gòu)

* 重構(gòu)是不改變外部功能的情況下改善代碼的內(nèi)部結(jié)構(gòu)。
* 重構(gòu)的目的是： 發(fā)現(xiàn)個修改冗余，未使用的元素，抵消的算法，垃圾的數(shù)據(jù)結(jié)構(gòu)，不好的設(shè)計。

軟件體系結(jié)構(gòu)

為什么進行體系結(jié)構(gòu)設(shè)計

• 可以讓軟件工程師在滿足軟件需求的情況下分析設(shè)計的有效性
• 工程師可以在設(shè)計變更相對容易的階段考慮架構(gòu)的替代方案
• 減少與軟件架構(gòu)相關(guān)的風(fēng)險。
• 軟件系統(tǒng)設(shè)計是開發(fā)者之間分工和合作的基礎(chǔ)，方便了人員之間的交流。
• 有利于系統(tǒng)的早期決策，設(shè)計方案是決定系統(tǒng)質(zhì)量的主要因素。
• 體系建構(gòu)構(gòu)建了一個可傳遞，易于理解的系統(tǒng)級抽象。

軟件體系結(jié)構(gòu)風(fēng)格

定義

• 體系結(jié)構(gòu)風(fēng)格定義了一系列系統(tǒng)的結(jié)構(gòu)組織模式，它是一類具有相似結(jié)構(gòu)的系統(tǒng)體系結(jié)構(gòu)的抽象。
• 換句話說， 一個問題有多種解決問題的模式，但我們根據(jù)經(jīng)驗，通常采取特定的模式，這就是風(fēng)格。
• 體系結(jié)構(gòu)描述： 構(gòu)件， 負(fù)責(zé)構(gòu)件之間通信協(xié)作的連接器， 定義構(gòu)建之間怎樣集成的系統(tǒng)約束， 使設(shè)計者能夠理解整個系統(tǒng)的語義模型。

軟件體系結(jié)構(gòu)風(fēng)格分類

• 數(shù)據(jù)為中心的體系結(jié)構(gòu)： 一些數(shù)據(jù)保存在整個結(jié)構(gòu)的中心，并且被其他部件頻繁的使用，添加，刪除，或者修改。
• 數(shù)據(jù)流風(fēng)格的體系結(jié)構(gòu)：適用于輸入數(shù)據(jù)被一系列計算或者處理構(gòu)件變換成輸出數(shù)據(jù)。
• 調(diào)用和返回的體系結(jié)構(gòu)： 這種風(fēng)格使一個軟件設(shè)計者設(shè)計出非常容易修改和擴充的體系結(jié)構(gòu)
  • 主程序/子程序分割： 傳統(tǒng)的程序結(jié)構(gòu)，功能分解為控制層次
  • 遠(yuǎn)程過程調(diào)用風(fēng)格的體系結(jié)構(gòu)：該體系結(jié)構(gòu)的構(gòu)建分布在網(wǎng)絡(luò)的多個計算機上。
  • 程序結(jié)構(gòu)的深度和寬度： 程序結(jié)構(gòu)的層數(shù)/同一層的的最大模塊數(shù)
  • 模塊的扇入和扇出： 扇出表示一個模塊直接調(diào)用或控制其他模塊的數(shù)目。 扇入表示調(diào)用一個給定模塊的模塊的數(shù)目。
• 面向?qū)ο箫L(fēng)格的體系結(jié)構(gòu)： 系統(tǒng)部件封裝數(shù)據(jù)和操作數(shù)據(jù)的方法。 部件之間的交互和協(xié)調(diào)通過消息來傳遞。
• 層次式風(fēng)格的體系結(jié)構(gòu)： 在這種結(jié)構(gòu)中，定義了不同的層次，每層都完成了相對外層更靠近機器指令的操作。 缺陷： 降低了系統(tǒng)的性能， 有時會導(dǎo)致級聯(lián)式修改。

軟件體系結(jié)構(gòu)的設(shè)計方法

• 結(jié)構(gòu)化設(shè)計： 主要解決如何將數(shù)據(jù)流圖映射為軟件體系結(jié)構(gòu)
  • 復(fù)審和精華數(shù)據(jù)流圖
  • 確定數(shù)據(jù)流圖的類型 1 事務(wù)型[數(shù)據(jù)流沿著輸入路徑到達一個事務(wù)中心] 2 變換型[數(shù)據(jù)流圖分為輸入變化和輸出]
  • 將數(shù)據(jù)流圖映射為初始結(jié)構(gòu)圖
  • 改善初始的結(jié)構(gòu)圖
• 面向?qū)ο笤O(shè)計：
  • 子系統(tǒng)設(shè)計。 OOD方法也采取了問題分解的方法。 定義若干個一致的類與對象，關(guān)系，行為，功能的集合，這樣一個集合就是一個子系統(tǒng)。
  • 對象設(shè)計： 對每一個對象的數(shù)據(jù)進行設(shè)計，基本上屬于構(gòu)件級別的設(shè)計階段。
  • 消息設(shè)計： 描述每個對象可以接收和發(fā)送的消息的接口。 具體的消息設(shè)計在構(gòu)件級設(shè)計階段完成。
  • 方法設(shè)計：進一步對對象的方法進行求精。 主要在構(gòu)件級設(shè)計階段完成。

構(gòu)件級別建模

什么是構(gòu)件

• 面向?qū)ο蟮挠^點： 構(gòu)件就是一些相互協(xié)作的類的集合。
• 傳統(tǒng)的觀點： 構(gòu)件是程序的一個基本元素。結(jié)合了過程邏輯，以及實現(xiàn)過程邏輯的數(shù)據(jù)結(jié)構(gòu)。 提供接口讓組件調(diào)用它。

構(gòu)件的設(shè)計原則[重要：原諒我在UML就背會了哈哈哈]

• 開閉原則： 構(gòu)件應(yīng)該對擴展是開放的，而對修改是封閉的。
• 替換原則： 所有引用基類的地方必須能透明地使用其子類的對象。通俗的講就是：只要父類能出現(xiàn)的地方子類就可以出現(xiàn)，而且替換為子類也不會產(chǎn)生任何錯誤或者異常，使用者可能根本就不需要知道是父類還是子類，但是，反過來就不行了，有子類出現(xiàn)的地方，父類未必就能適應(yīng)。因為子類有的東西父類不一定有。
• 依賴導(dǎo)致原則： 更多的去依賴抽象的類和接口，而不是依賴具體的類。
• 接口分離原則： 將通用的接口分離成多個功能獨立的子接口。

內(nèi)聚性和耦合性

• 內(nèi)聚性 是指： 類或者部件只封裝那些相互關(guān)聯(lián)緊密的，以及于構(gòu)件或類自身有有緊密聯(lián)系的屬性和操作。
• 耦合性 是指： 類之間彼此聯(lián)系程度的一種度量。

構(gòu)件設(shè)計的方法

• 畫軟件流程圖
• 決策表[四個部分]
  • 左上部列出所有條件
  • 右上部是可能組合的條件，每一列表示一種可能
  • 左下部是所有可能做的動作
  • 右下部是每一種條件組合對應(yīng)的應(yīng)作的工作
• PDL ： 是一種描述功能部件算法設(shè)計和處理細(xì)節(jié)的語言，成為設(shè)計性語言，是一種偽代碼

測試

• 測試是驗證和確認(rèn)的一部分。 驗證：我們做的程序正確嗎？ 確認(rèn)： 我門在做正確的產(chǎn)品嗎[需求]？

單元測試

• 單元測試時針對程序中的模塊或者部件的測試，主要揭露編碼階段產(chǎn)生的錯誤。
  • 單元測試側(cè)重于對軟件設(shè)計的最小單元進行測試
  • 單元測試的目的是 在開發(fā)環(huán)境中檢查單元程序模塊內(nèi)部的邏輯，算法和數(shù)據(jù)處理結(jié)果的正確性
  • 單元測試的內(nèi)容是 算法邏輯，數(shù)據(jù)定義的理解和使用，接口，各種控制路徑，邊界條件，錯誤處理。
• 面向?qū)ο蟮膯卧獪y試，最小的單元是方法。[由于繼承，多態(tài)等特性，對方法測試往往是無效的]
• 面向?qū)ο蟓h(huán)境中的單元測試主要是對類的測試。

集成測試

• 集成測試是構(gòu)造軟件體系結(jié)構(gòu)的系統(tǒng)化技術(shù)，同時也是進行一些旨在發(fā)現(xiàn)與結(jié)構(gòu)相關(guān)錯誤的測試。
• 為什么進行集成測試？
  • 數(shù)據(jù)可能在通過接口時丟失
  • 一個模塊可能對另一個模塊產(chǎn)生非故意的有害影響
  • 當(dāng)子功能結(jié)合起來時，可能達不到預(yù)期的主功能。
  • 單個模塊的可以接受的不精確性，結(jié)合起來時可能擴大到不可接受
  • 全局?jǐn)?shù)據(jù)結(jié)構(gòu)可能存在問題
• 傳統(tǒng)的集成測試策略
  • 一步到位的集成
  • 增量式集成
    • 自頂而下的集成： 從主控模塊開始，按照程序結(jié)構(gòu)圖的控制層次，采用深度優(yōu)先或者廣度優(yōu)先的方式逐個集成到整個結(jié)構(gòu)中，并對其測試。
    • 自底而上的集成： 從程序的結(jié)構(gòu)的最底層開始，或者原生的子模塊。 按照程序結(jié)構(gòu)圖的控制層次將上層的模塊集成到整個結(jié)構(gòu)中，并對其進行測試。
• 面向?qū)ο蟮募蓽y試
  • 面向?qū)ο鬀]有明顯的控制層次， 不能使用自頂而下，什么什么的方法。 類之間的相互作用，也不能每次只集成一個操作。
  • 方法
    • 基于線程的測試：集成響應(yīng)系統(tǒng)的一個輸入事件所需的一組類，每個線程單獨的集成和測試
    • 基于使用的測試：先測試獨立類，然和添加測試依賴類，直到整個系統(tǒng)集成成功
• 回歸測試： 對已經(jīng)測試過的子集重新執(zhí)行測試，確保對程序的修改沒有傳播非故意的副作用
• 冒煙測試： 盡可能早的發(fā)現(xiàn)可能造成項目延遲的業(yè)務(wù)阻塞

• 確認(rèn)測試 ： 發(fā)現(xiàn)軟件與需求不一致的地方

• 系統(tǒng)測試 : 對集成后的產(chǎn)品和解決方案進行測試，是評價系統(tǒng)對需求規(guī)格說明的功能和非功能的符合性的測試。

測試技術(shù)

白盒測試

• 也稱結(jié)構(gòu)測試，或者邏輯驅(qū)動測試。
• 基于內(nèi)部邏輯結(jié)構(gòu)，針對程序語句，路徑，變量狀態(tài)的測試。
• 確認(rèn)程序中各個分支條件是否有效，正確。

黑盒測試

• 也稱行為測試
• 把程序看出不能打開的盒子，不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性。 只考察數(shù)據(jù)的輸入，條件限制，和數(shù)據(jù)輸出。

靜態(tài)分析

對模塊的源代碼進行研讀。 不需要對代碼編譯運行。動態(tài)分析： 運行程序，發(fā)現(xiàn)錯誤。

手工測試

• 靜態(tài)分析只能進行手工測試，雖然有輔助工具，但是以人為主體。
• 特點：
  • 發(fā)現(xiàn)缺陷率高
  • 容易實施
  • 擁有創(chuàng)造性和靈活性
  • 覆蓋率量化困難
  • 效率低， 依賴人力

自動化測試

• 動態(tài)測試可以部分或全部自動化測試。
• 特點
  • 自動運行速度快
  • 測試結(jié)果準(zhǔn)確
  • 測試腳本的高復(fù)用
  • 永不疲勞
  • 可靠

項目管理

4P 模型

• 人員[people ] : 如何有效的組織人員
• 產(chǎn)品 [product ] ： 確定產(chǎn)品的范圍。獲得開發(fā)者和客戶的一致認(rèn)可
• 過程[process ] : 指定軟件開發(fā)的綜合計劃
• 項目 [project ] : 采用科學(xué)的方法和工具對項目進行管理

W5HH[5個問題]

• 為什么開發(fā)這個系統(tǒng)？
• 將要做什么？
• 什么時候做？
• 某功能由誰負(fù)責(zé)？
• 他們的機構(gòu)組織位于何處？
• 如何完成技術(shù)和管理工作？
• 每種資源需要多少

度量

對一個系統(tǒng)，構(gòu)建，過程具有給定屬性的量化測試程度

McCall的質(zhì)量因素

• 影響因素分為兩大類： 可以直接測量的因素[例如測試時發(fā)現(xiàn)的缺陷]。 只能間接測量的因素[易用性，可維護性。。].
• 內(nèi)容：正確性、可靠性、效率、完整性、易用性、可維護性、靈活性、可測試性、可移植性、可復(fù)用性、互操作性。

Measures, Metrics, Indicators

• 測度(measure)：為產(chǎn)品或過程的某些屬性的程度、數(shù)量、維數(shù)、容量或大小提供量化的指標(biāo)，而”測量(measurement)“是確定測度的動作
• 度量(Metrics): 度量是一個系統(tǒng)、構(gòu)件或過程具有給定屬性量化測量程度。
• Indicators指標(biāo)： 是一個度量或者多個度量的組合，它提供了對軟件過程，軟件項目或產(chǎn)品本身的深入理解

度量的作用

• 過程度量作用：提供能夠引導(dǎo)長期軟件過程改進的一組過程指標(biāo)。
• 項目度量作用：使得軟件管理者能夠（1）評估正在進行中的項目的狀態(tài)（2）跟蹤潛在的分險 （3）在問題造成不良影響前發(fā)現(xiàn)他們（4）調(diào)整工作流程或任務(wù)（5）評估項目團隊控制軟件工作產(chǎn)品質(zhì)量的能力
• 產(chǎn)品度量作用：為分析、設(shè)計、編碼和測試能更客觀的執(zhí)行和更定量的評估提供基礎(chǔ)

估算

項目計劃任務(wù)和內(nèi)容

項目計劃任務(wù)

• 規(guī)定項目范圍
• 確定可行性
• 分析風(fēng)險
• 確定需要的資源（a、確定需要的人力資源；b、確定可重用的軟件資源 c、標(biāo)識環(huán)境資源）
• 估算成本和工作量（a、分解問題b、使用規(guī)模，功能點，過程任務(wù)或用例等方法進行兩種以上恩德估算c、調(diào)和不同的估算）
• 制定項目進度計劃（a、建立一組有意義的任務(wù)集合b、定義任務(wù)網(wǎng)絡(luò)c、使用進度計劃工具指定時間表d、定義進度跟蹤機制）

項目計劃的內(nèi)容

• 項目計劃內(nèi)容估算，進度安排，風(fēng)險分析，質(zhì)量管理計劃和變更管理計劃

LOC & FP

LOC[面向規(guī)模的度量]

• LOC以代碼行作為其他測量的規(guī)范化因子

FP[面向功能的度量]

• FP(功能點)則是從信息域及對問題復(fù)雜度的主觀評估中導(dǎo)出的

二者共性

• 均以問題分解為基礎(chǔ)，LOP更甚，問題分解越詳細(xì)越好。
• 要求WBS(work breakdown structure)中每個工作包都是可以分別獨立估算的
• 每個工作包都有基線生產(chǎn)率度量值可以參考，或者可以預(yù)估其生產(chǎn)率。
• 基線生產(chǎn)率度量：根據(jù)LOC和FP的測量，計算出軟件開發(fā)組織對某類問題的生產(chǎn)率，LOC/pm或FP/pm

進度

項目工作量分配原則40-20-40

總體工作量的40%分配給前期的分析和設(shè)計，20%用于編碼，40%用于后期測試

任務(wù)網(wǎng)絡(luò)[數(shù)據(jù)結(jié)構(gòu)？]

活動網(wǎng)絡(luò)，是一個項目任務(wù)流程的圖形表示。

• 優(yōu)點 ： 很好地展示優(yōu)先關(guān)系；定義關(guān)鍵路徑的能力；執(zhí)行“如果”分析的能力
• 缺點：默認(rèn)模型假定資源是無限的，我們需要加緊資源依賴關(guān)系當(dāng)確定自己的“真正”的關(guān)鍵路徑；難以跟隨大的項目

關(guān)鍵路徑

• 機動時間：在不影響整個工期的情況下，當(dāng)前任務(wù)允許延遲的最長時間
• 關(guān)鍵路徑：由機動時間為0的任務(wù)組成的項目路徑。

里程碑

• 甘特圖： 項目進行的時間表， 就是項目進度表
• 在甘特圖中，每項任務(wù)的完成以必須交付的文檔和通過評審為標(biāo)準(zhǔn)，因此他們往往作為項目的里程碑
• 作用：敏捷、詳細(xì)、可度量、可分配、現(xiàn)實性、期間時限

風(fēng)險

被動和主動的風(fēng)險管理

• 被動：項目團隊在發(fā)生風(fēng)險時對其做出反應(yīng)；緩解 - 預(yù)計消防的額外資源計劃；(救火模式)修復(fù)失敗-當(dāng)風(fēng)險發(fā)生，才找到資源并應(yīng)用；危機管理 - 失敗不響應(yīng)應(yīng)用資源，項目處于危險之中
• 主動：執(zhí)行正式風(fēng)險分析；組織糾正風(fēng)險的根本原因③主動風(fēng)險管理過程：風(fēng)險識別，分析，規(guī)劃，監(jiān)控

RMMM[風(fēng)險規(guī)劃]

• 風(fēng)險避免[Risk Mitigation]
• 風(fēng)險監(jiān)測[Risk Monitoring] : 可以通過風(fēng)險知識，評估風(fēng)險是否真的發(fā)生了。 保證正確實施了各項緩解步驟。 收集相關(guān)有用的風(fēng)險分析信息。
• 風(fēng)險管理及應(yīng)急計劃[Risk Management]
  • 實施條件： 風(fēng)險避免和緩解工作已經(jīng)失敗。 風(fēng)險已經(jīng)發(fā)生、

質(zhì)量

軟件質(zhì)量的因素

• 軟件要符合明確規(guī)定的功能和性能需求，符合已清晰文檔化的開發(fā)標(biāo)準(zhǔn)，并且具有專業(yè)人員開發(fā)的軟件所應(yīng)有的隱含特征
• 當(dāng)根據(jù)對象的可測量特征考察一個對象時，可以有兩種不同質(zhì)量：（1）設(shè)計質(zhì)量：設(shè)計者為一個產(chǎn)品規(guī)定的特征，包括系統(tǒng)的需求，規(guī)格說明和設(shè)計（2）一致性質(zhì)量：在制造產(chǎn)品過程中遵守設(shè)計規(guī)格說明的制度。
• 質(zhì)量成本包括預(yù)防成本，失效成本，鑒定成本
• 用戶滿意度=合格的產(chǎn)品+好的質(zhì)量+按預(yù)算和進度安排交付
• 內(nèi)部質(zhì)量/外部質(zhì)量

質(zhì)量保證活動

• 指定SQA計劃
• 參與開發(fā)項目的軟件過程描述
• 評審各項軟件工程活動，以檢驗是否符合定義的軟件過程
• 審核指定的軟件工作產(chǎn)品，以驗證其是否符合定義的軟件過程中的相應(yīng)部分
• 確保軟件工作及工作產(chǎn)品中出現(xiàn)的偏差已文檔化，并按文檔化的規(guī)程進行了處理
• 記錄所有不符合的部分，報告高層管理者

正式技術(shù)評審:是一項由軟件工程師(以及其他人)進行的軟件質(zhì)量控制活動。

• 在軟件工程過程的每個活動的后期進行

• 采用正式的會議評審

• 通過正式評審意味著 里程碑 和 基線

• 目標(biāo)：

  • 發(fā)現(xiàn)軟件的任何一種表示形式中的功能、邏輯或?qū)崿F(xiàn)上的錯誤；
  • 驗證評審中的軟件是否滿足其需求。
  • 保證軟件表示符合預(yù)先定義的標(biāo)準(zhǔn)
  • 得到以統(tǒng)一的方式開發(fā)的軟件

• 作用:

  • 提供培訓(xùn)機會，使初級工程師能夠了解軟件設(shè)計和實現(xiàn)的不同方法
  • 使大量人員對軟件系統(tǒng)中原本不熟悉的部分更了解
  • 培訓(xùn)后備人員和促進項目連續(xù)性
  • 評審會議條件：（1）通常3-5人（2）提前準(zhǔn)備，占用每人工作時間不超過2小時（3）會議時間小于2小時

• 軟件質(zhì)量的成本

  • 預(yù)防成本： 包括質(zhì)量計劃，正式技術(shù)評審，測試設(shè)備及培訓(xùn)
  • 鑒定成本： 鑒定成本：包括為深入了解“首次通過”各個過程時的產(chǎn)品狀態(tài)而開展的那些活動
  • 失效成本：如果在將產(chǎn)品交付給客戶之前沒有缺陷的話就不會存在的成本。分為內(nèi)部失效成本和外部失效成本。
    • 內(nèi)部失效成本是指在產(chǎn)品交付給客戶之前發(fā)現(xiàn)了錯誤而引發(fā)的成本，包括返工、修復(fù)以及失效模式分析、
    • 外部失效成本是指與產(chǎn)品交付給客戶之后所發(fā)現(xiàn)的缺陷相關(guān)的成本，如解決客戶抱怨、退換產(chǎn)品、保修工作等。

變更

軟件配置項

• 在軟件工程過程中創(chuàng)建的信息。為配置管理設(shè)計的軟件工作產(chǎn)品的集合，它在配置管理過程中作為單個實體對待。
• 包括：計算機程序（源代碼和可執(zhí)行程序）：描述計算機程序的文檔（針對技術(shù)開發(fā)者和用戶）；數(shù)據(jù)（包含在程序內(nèi)部的數(shù)據(jù)，或程序外部的數(shù)據(jù)）、開發(fā)環(huán)境

版本

• 與計算機軟件配置項的完全按編篡或重編纂相關(guān)的計算機軟件配置項的初始發(fā)布或再發(fā)布

基線

• 已經(jīng)通過正式評審和批準(zhǔn)的規(guī)格說明或產(chǎn)品，它可以作為進一步開發(fā)的基礎(chǔ)，并且只有通過正式的變更控制規(guī)程才能修改它。

發(fā)布

• 一項配置管理行為，它說明某配置項的一個特定版本已準(zhǔn)備好用于特定的目的（例如發(fā)布測試產(chǎn)品）

軟件配置管理SCM流程

SCM 任務(wù)：SCM任務(wù)：標(biāo)識，版本控制，變更控制，配置審核

• 標(biāo)識： 為控制和管理軟件配置項，必須對每個配置項單獨命名，然后用面向?qū)ο蠓椒ㄟM行組織?？梢赃M行標(biāo)識的對象：基本對象和聚合對象。
• 版本控制：結(jié)合規(guī)程和工具，用來管理在軟件過程中所創(chuàng)建的配置對象的不同版本。
• 變更控制：
• 配置審核：通過正式技術(shù)評審或軟件配置審核來保證變更的有效性。是正式技術(shù)評審的補充。
• 報告：配置狀態(tài)報告CSR（狀態(tài)記錄），解答了問題，發(fā)生什么事，是誰做的，什么時候發(fā)生的，會影響到別的什么。可使管理者和開發(fā)人員可以評估重要的變更。